随着安全威胁的不断发生，入侵检测系统（IDS）在如今的数据中心环境中显得尤为必要。然而，随着越来越多的服务器将他们的网卡升级到10GB/40GB以太网，对如此线路上的硬件进行计算密集型的入侵检测越来越困难。其中一种提升入侵检测系统性能的途径是多线程入侵检测系统，它将 CPU 密集型的深度包检测工作并行的分配给多个并发任务来完成。这样的并行检测可以充分利用多核硬件的优势来轻松提升入侵检测系统的吞吐量。在这方面有两个知名的开源项目，分别是 Suricata 和 Bro。

这个教程里，我会向大家演示如何在 Linux 服务器上安装和配置 Suricata 入侵检测系统。

在 Linux 上安装 Suricata IDS

让我们从源文件来构建 Suricata，但在此之前，需要按如下所示先安装几个依赖包。

在 Debian, Ubuntu 或者 Linux Mint 操作系统上安装依赖包

$ sudo apt-get install wget build-essential libpcre3-dev libpcre3-dbg automake autoconf libtool libpcap-dev libnet1-dev libyaml-dev zlib1g-dev libcap-ng-dev libjansson-dev

在 CentOS, Fedora 或者 RHEL 操作系统上安装依赖包

$ sudo yum install wget libpcap-devel libnet-devel pcre-devel gcc-c++ automake autoconf libtool make libyaml-devel zlib-devel file-devel jansson-devel nss-devel

一旦将所有依赖包安装完毕，我们就可以继续安装 Suricata 了。

首先从 http://suricata-ids.org/download/ 下载 Suricata 源代码，然后构建它。撰写这篇文章的时候，其最新版本号为 2.0.8 。

$ wget http://www.openinfosecfoundation.org/download/suricata-2.0.8.tar.gz
$ tar -xvf suricata-2.0.8.tar.gz
$ cd suricata-2.0.8
$ ./configure --sysconfdir=/etc --localstatedir=/var

以下是配置信息的样例。

Suricata Configuration:
  AF_PACKET support:                       yes
  PF_RING support:                         no
  NFQueue support:                         no
  NFLOG support:                           no
  IPFW support:                            no
  DAG enabled:                             no
  Napatech enabled:                        no
  Unix socket enabled:                     yes
  Detection enabled:                       yes

  libnss support:                          yes
  libnspr support:                         yes
  libjansson support:                      yes
  Prelude support:                         no
  PCRE jit:                                yes
  LUA support:                             no
  libluajit:                               no
  libgeoip:                                no
  Non-bundled htp:                         no
  Old barnyard2 support:                   no
  CUDA enabled:                            no

现在可以编译、安装了。

$ make
$ sudo make install

Suricata 源代码带有默认的配置文件。按照如下方法安装这些默认配置文件即可。

$ sudo make install-conf

正如你所料，如果没有IDS规则集的话，Suricata 什么用也没有。幸好 Makefile 为我们提供了 IDS 规则集的安装选项。安装方法如下。

$ sudo make install-rules

以上的规则安装命令会从 EmergingThreats.net 上下载可用的社区规则集快照，并且将其存储在 /etc/suricata/rules 目录下。

首次配置 Suricata IDS

现在到了配置 Suricata 的时候了。配置文件的位置是 /etc/suricata/suricata.yaml。参照以下命令，用文本编辑器打开这个文件。

$ sudo vi /etc/suricata/suricata.yaml

文件中有一些运行所需的基本配置。

为default-log-dir关键字指定 Suricata 日志文件所在的位置。

default-log-dir: /var/log/suricata/

在vars部分下方，你会发现几项对 Suricata 来说很重要变量。HOME_NET变量需要指定 Suricata 检查的网络。被分配给 EXTERNAL_NET 变量的 !$HOME_NET 代表除本地网络之外的其他网络。XXX_PORTS变量用来辨别不同服务所用到的端口号。需要注意的是无论使用什么端口，Suricata 都可以自动检测 HTTP 流量。所以是不是正确指定端口就显得没那么重要了。

vars:
    HOME_NET: "[192.168.122.0/24]"
    EXTERNAL_NET: "!$HOME_NET"
    HTTP_PORTS: "80"
    SHELLCODE_PORTS: "!80"
    SSH_PORTS: 22

host-os-policy 部分用于防御利用操作系统网络栈的自身行为来逃避检测的一些知名攻击手段（例如：TCP reassembly）。作为对策，通过针对目标操作系统而对检测引擎算法进行微调，现代 IDC 提供了“基于目标”的检测手段。因此，如果你知道某台主机运行了什么操作系统的话，将这个信息提供给 Suricata 就可以大幅提高检测的成功率。这就是 host-os-policy 存在的意义。本例中，默认的 IDC 策略是 Linux 系统。如果针对某个 IP 地址没有指定操作系统信息，Suricata 会默认应用基于 Linux 系统的检测策略。如下，当捕获到对 192.168.122.0/28 和 192.168.122.155通讯时，Suricata 就会应用基于 Windows 系统的检测策略。

host-os-policy:
  # These are Windows machines.
  windows: [192.168.122.0/28, 192.168.122.155]
  bsd: []
  bsd-right: []
  old-linux: []
  # Make the default policy Linux.
  linux: [0.0.0.0/0]
  old-solaris: []
  solaris: ["::1"]
  hpux10: []
  hpux11: []
  irix: []
  macos: []
  vista: []
  windows2k3: []

在 threading 部分下，你可以为不同的 Suricata 线程指定 CPU 关联。默认状态下，CPU 关联 是被禁止使用的 (set-cpu-affinity: no)，这意味着 Suricata 会分配其线程到所有可用的 CPU 核心上。Suricata 会默认为每一个 CPU 核心创建一个检测线程。你可以通过指定 detect-thread-ratio: N 来调整此行为。此处会创建 N*M 个检测线程，M 代表 CPU 核心总数。

threading:
  set-cpu-affinity: no
  detect-thread-ratio: 1.5

通过以上对线程的设置，Suricata 会创建 1.5*M 个检测线程，M 是系统的 CPU 核心总数。

如果你想对 Suricata 配置有更多的了解，可以去翻阅默认配置文件。里边配有有大量的注释以供你清晰理解。

使用 Suricata 进行入侵监控

现在是时候让 Suricata 跑起来了，但在这之前还有一个步骤需要去完成。

当你使用 pcap 捕获模式的时候，强烈建议关闭 Suricata 监听网卡上的任何的包卸载（例如 LRO/GRO）功能。这些功能会干扰包的实时捕获行为。

按照以下方法关闭 eth0 接口的 LRO/GRO 功能。

$ sudo ethtool -K eth0 gro off lro off

这里要注意，在使用某些网卡的情况下，你会看到如下警告信息。忽略它们就行了，这些信息只不过告诉你你的网卡不支持 LRO 功能而已。

Cannot change large-receive-offload

Suricata 支持许多运行模式。运行模式决定着 IDC 会使用何种线程。以下命令可以查看所有 可用的运行模式。

$ sudo /usr/local/bin/suricata --list-runmodes

Suricata 使用的默认运行模式是 autofp（ auto flow pinned load balancing （ 自动流绑定负载均衡 ） 的缩写）。这个模式下，来自某一个流的包会被分配到一个单独的检测线程中。这些流会根据未被处理的包的最低数量来分配相应的线程。

最后，让我们将 Suricata 运行起来，看看它表现如何。

$ sudo /usr/local/bin/suricata -c /etc/suricata/suricata.yaml -i eth0 --init-errors-fatal

本例中，我们在一个8核心系统中监控 eth0 网络接口。如上所示，Suricata 创建了13个包处理线程和3个管理线程。包处理线程中包括一个 PCAP 包捕获线程，12个检测线程(由8*1.5得出)。这表示 IDS 内的1个包捕获线程均衡负载到12个检测线程中。管理线程包括1个流管理和2个计数/统计相关线程。

以下是一个关于Suricata处理的线程截图(由 htop 绘制)。

Suricata 检测日志存储在 /var/log/suricata 目录下。

$ tail -f /var/log/suricata/fast.log

04/01/2015-15:47:12.559075  [**] [1:2200074:1] SURICATA TCPv4 invalid checksum [**] [Classification: (null)] [Priority: 3] {TCP} 172.16.253.158:22 -> 172.16.253.1:46997
04/01/2015-15:49:06.565901  [**] [1:2200074:1] SURICATA TCPv4 invalid checksum [**] [Classification: (null)] [Priority: 3] {TCP} 172.16.253.158:22 -> 172.16.253.1:46317
04/01/2015-15:49:06.566759  [**] [1:2200074:1] SURICATA TCPv4 invalid checksum [**] [Classification: (null)] [Priority: 3] {TCP} 172.16.253.158:22 -> 172.16.253.1:46317

日志也可以提供 Json 格式以便导入：

$ tail -f /var/log/suricata/eve.json

{"timestamp":"2015-04-01T15:49:06.565901","event_type":"alert","src_ip":"172.16.253.158","src_port":22,"dest_ip":"172.16.253.1","dest_port":46317,"proto":"TCP","alert":{"action":"allowed","gid":1,"signature_id":2200074,"rev":1,"signature":"SURICATA TCPv4 invalid checksum","category":"","severity":3}}
{"timestamp":"2015-04-01T15:49:06.566759","event_type":"alert","src_ip":"172.16.253.158","src_port":22,"dest_ip":"172.16.253.1","dest_port":46317,"proto":"TCP","alert":{"action":"allowed","gid":1,"signature_id":2200074,"rev":1,"signature":"SURICATA TCPv4 invalid checksum","category":"","severity":3}}

总结

这篇教程中，我为大家演示了如何在一台多核 Linux 服务器上安装 Suricata 入侵检测系统。不同于单线程的 Snort IDS ，Suricata 可以很容易的从多核硬件的多进程特性所带来的好处中获益。定制 Suricata 来最大化其效能和检测范围是一个很好的主意。Suricata 的粉丝们维护着一个 在线 Wiki，如果你打算将 Suricata 部署到你的环境中，我强烈建议你去那儿取取经。

如果你现在已经开始使用 Suricata 了的话，把你的经验也分享出来吧。

via: http://xmodulo.com/install-suricata-intrusion-detection-system-linux.html

作者：Dan Nanni 译者：mr-ping 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

对于网络安全而言入侵检测是一件非常重要的事。入侵检测系统（IDS）用于检测网络中非法与恶意的请求。Snort是一款知名的开源的入侵检测系统。其 Web界面（Snorby）可以用于更好地分析警告。Snort使用iptables/pf防火墙来作为入侵检测系统。本篇中，我们会安装并配置一个开源的入侵检测系统snort。

Snort 安装

要求

snort所使用的数据采集库（DAQ）用于一个调用包捕获库的抽象层。这个在snort上就有。下载过程如下截图所示。

解压并运行./configure、make、make install来安装DAQ。然而，DAQ要求其他的工具，因此，./configure脚本会生成下面的错误。

flex和bison错误

libpcap错误

因此在安装DAQ之前先安装flex/bison和libcap。

如下所示安装libpcap开发库

安装完必要的工具后，再次运行./configure脚本，将会显示下面的输出。

make和make install 命令的结果如下所示。

成功安装DAQ之后，我们现在安装snort。如下图使用wget下载它。

使用下面的命令解压安装包。

#tar -xvzf  snort-2.9.7.3.tar.gz

创建安装目录并在脚本中设置prefix参数。同样也建议启用包性能监控（PPM）的sourcefire标志。

#mkdir /usr/local/snort

#./configure --prefix=/usr/local/snort/ --enable-sourcefire

配置脚本会由于缺少libpcre-dev、libdumbnet-dev 和zlib开发库而报错。

配置脚本由于缺少libpcre库报错。

配置脚本由于缺少dnet（libdumbnet）库而报错。

配置脚本由于缺少zlib库而报错

如下所示，安装所有需要的开发库。

# aptitude install libpcre3-dev

# aptitude install libdumbnet-dev

# aptitude install zlib1g-dev

安装完snort需要的库之后，再次运行配置脚本就不会报错了。

运行make和make install命令在/usr/local/snort目录下完成安装。

# make

# make install

最后，从/usr/local/snort/bin中运行snort。现在它对eth0的所有流量都处在promisc模式（包转储模式）。

如下图所示snort转储流量。

Snort的规则和配置

从源码安装的snort还需要设置规则和配置，因此我们需要复制规则和配置到/etc/snort下面。我们已经创建了单独的bash脚本来用于设置规则和配置。它会设置下面这些snort设置。

• 在linux中创建用于snort IDS服务的snort用户。
• 在/etc下面创建snort的配置文件和文件夹。
• 权限设置并从源代码的etc目录中复制数据。
• 从snort文件中移除规则中的#(注释符号)。

#!/bin/bash#
# snort源代码的路径
snort_src="/home/test/Downloads/snort-2.9.7.3"
echo "adding group and user for snort..."
groupadd snort &> /dev/null
useradd snort -r -s /sbin/nologin -d /var/log/snort -c snort_idps -g snort &> /dev/null#snort configuration
echo "Configuring snort..."mkdir -p /etc/snort
mkdir -p /etc/snort/rules
touch /etc/snort/rules/black_list.rules
touch /etc/snort/rules/white_list.rules
touch /etc/snort/rules/local.rules
mkdir /etc/snort/preproc_rules
mkdir /var/log/snort
mkdir -p /usr/local/lib/snort_dynamicrules
chmod -R 775 /etc/snort
chmod -R 775 /var/log/snort
chmod -R 775 /usr/local/lib/snort_dynamicrules
chown -R snort:snort /etc/snort
chown -R snort:snort /var/log/snort
chown -R snort:snort /usr/local/lib/snort_dynamicrules
###copy  configuration and rules from  etc directory under source code of snort
echo "copying from snort source to /etc/snort ....."
echo $snort_src
echo "-------------"
cp $snort_src/etc/*.conf* /etc/snort
cp $snort_src/etc/*.map /etc/snort##enable rules
sed -i 's/include \$RULE\_PATH/#include \$RULE\_PATH/' /etc/snort/snort.conf
echo "---DONE---"

改变脚本中的snort源目录路径并运行。下面是成功的输出。

上面的脚本从snort源中复制下面的文件和文件夹到/etc/snort配置文件中

snort的配置非常复杂，要让IDS能正常工作需要进行下面必要的修改。

ipvar HOME_NET 192.168.1.0/24  # LAN side

ipvar EXTERNAL_NET !$HOME_NET   # WAN side

var RULE_PATH /etc/snort/rules     # snort signature path
var SO_RULE_PATH /etc/snort/so_rules        #rules in shared libraries
var PREPROC_RULE_PATH /etc/snort/preproc_rules  # Preproces path
var WHITE_LIST_PATH /etc/snort/rules        # dont scan
var BLACK_LIST_PATH /etc/snort/rules        #  Must scan

include $RULE_PATH/local.rules   # file for custom rules

移除ftp.rules、exploit.rules前面的注释符号(#)。

现在下载社区规则并解压到/etc/snort/rules。启用snort.conf中的社区及紧急威胁规则。

进行了上面的更改后，运行下面的命令来检验配置文件。

# snort -T -c /etc/snort/snort.conf

总结

本篇中，我们关注了开源IDPS系统snort在Ubuntu上的安装和配置。通常它用于监控事件，然而它可以被配置成用于网络保护的在线模式。snort规则可以在离线模式中可以使用pcap捕获文件进行测试和分析

via: http://linoxide.com/security/install-snort-usage-ubuntu-15-04/

作者：nido 译者：geekpi 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

所有系统管理员想要在他们生产服务器上首先要部署的安全手段之一，就是检测文件篡改的机制——不仅仅是文件内容，而且也包括它们的属性。

AIDE （“高级入侵检测环境”的简称）是一个开源的基于主机的入侵检测系统。AIDE通过检查大量文件属性的不一致性来检查系统二进制文件和基本配置文件的完整性，这些文件属性包括权限、文件类型、索引节点、链接数、链接名、用户、组、文件大小、块计数、修改时间、添加时间、创建时间、acl、SELinux安全上下文、xattrs，以及md5/sha校验值在内的各种特征。

AIDE通过扫描一台（未被篡改）的Linux服务器的文件系统来构建文件属性数据库，以后将服务器文件属性与数据库中的进行校对，然后在服务器运行时对被修改的索引了的文件发出警告。出于这个原因，AIDE必须在系统更新后或其配置文件进行合法修改后重新对受保护的文件做索引。

对于某些客户，他们可能会根据他们的安全策略在他们的服务器上强制安装某种入侵检测系统。但是，不管客户是否要求，系统管理员都应该部署一个入侵检测系统，这通常是一个很好的做法。

在 CentOS或RHEL 上安装AIDE

AIDE的初始安装（同时是首次运行）最好是在系统刚安装完后，并且没有任何服务暴露在互联网甚至局域网时。在这个早期阶段，我们可以将来自外部的一切闯入和破坏风险降到最低限度。事实上，这也是确保系统在AIDE构建其初始数据库时保持干净的唯一途径。（LCTT 译注：当然，如果你的安装源本身就存在安全隐患，则无法建立可信的数据记录）

出于上面的原因，在安装完系统后，我们可以执行下面的命令安装AIDE：

 # yum install aide 

我们需要将我们的机器从网络断开，并实施下面所述的一些基本配置任务。

配置AIDE

默认配置文件是/etc/aide.conf，该文件介绍了几个示例保护规则（如FIPSR，NORMAL，DIR，DATAONLY），各个规则后面跟着一个等号以及要检查的文件属性列表，或者某些预定义的规则（由+分隔）。你也可以使用此种格式自定义规则。

FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256
NORMAL = FIPSR+sha512

例如，上面的例子说明，NORMAL规则将检查下列属性的不一致性：权限（p）、索引节点（i）、链接数（n）、用户（u）、组（g）、大小（s）、修改时间（m）、创建时间（c）、ACL（acl）、SELinux（selinux）、xattrs（xattr）、SHA256/SHA512校验和（sha256和sha512）。

定义的规则可灵活地用于不同的目录和文件（用正则表达式表示）。

条目之前的感叹号（！）告诉AIDE忽略子目录（或目录中的文件），对于这些可以另外定义规则。

在上面的例子中，PERMS是用于/etc机器子目录和文件的默认规则。然而，对于/etc中的备份文件（如/etc/.*~）则不应用任何规则，也没有规则用于/etc/mtab文件。对于/etc中的其它一些选定的子目录或文件，使用NORMAL规则替代默认规则PERMS。

定义并应用正确的规则到系统中正确的位置，是使用AIDE最难的一部分，但作一个好的判断是一个良好的开始。作为首要的一条规则，不要检查不必要的属性。例如，检查/var/log或/var/spool里头的文件的修改时间将导致大量误报，因为许多的应用程序和守护进程经常会写入内容到该位置，而这些内容都没有问题。此外，检查多个校验值可能会加强安全性，但随之而来的是AIDE的运行时间的增加。

可选的，如果你使用MAILTO变量指定电子邮件地址，就可以将检查结果发送到你的邮箱。将下面这一行放到/etc/aide.conf中的任何位置即可。

MAILTO=root@localhost

首次运行AIDE

运行以下命令来初始化AIDE数据库：

 # aide --init 

根据/etc/aide.conf生成的/var/lib/aide/aide.db.new.gz文件需要被重命名为/var/lib/aide/aide.db.gz，以便AIDE能读取它：

 # mv /var/lib/aide/aide.db.new.gz /var/lib/aide.db.gz 

现在，是时候来将我们的系统与数据库进行第一次校对了。任务很简单，只需运行：

 # aide 

在没有选项时，AIDE假定使用了--check选项。

如果在数据库创建后没有对系统做过任何修改，AIDE将会以OK信息来结束本次校对。

生产环境中管理AIDE

在构建了一个初始AIDE数据库后，作为不断进行的系统管理活动，你常常需要因为某些合法的理由更新受保护的服务器。每次服务器更新后，你必须重新构建AIDE数据库，以更新数据库内容。要完成该任务，请执行以下命令：

 # aide --update 

要使用AIDE保护生产系统，可能最好通过任务计划调用AIDE来周期性检查不一致性。例如，要让AIDE每天运行一次，并将结果发送到邮箱：

 # crontab -e 

0 0 * * * /usr/sbin/aide --check | /usr/bin/mail -s "AIDE run for $HOSTNAME" [email protected]

测试AIDE检查文件篡改

下面的测试环境将演示AIDE是如何来检查文件的完整性的。

测试环境 1

让我们添加一个新文件（如/etc/fake）。

# cat /dev/null > /etc/fake 

测试环境 2

让我们修改文件权限，然后看看它是否被检测到。

 # chmod 644 /etc/aide.conf 

测试环境 3

最后，让我们修改文件内容（如，添加一个注释行到/etc/aide.conf）。

echo "#This is a comment" >> /etc/aide.conf 

上面的截图中，第一栏显示了文件的属性，第二栏是AIDE数据库中的值，而第三栏是更新后的值。第三栏中空白部分表示该属性没有改动（如本例中的ACL）。

结尾

如果你曾经发现你自己有很好的理由确信系统被入侵了，但是第一眼又不能确定到底哪些东西被改动了，那么像AIDE这样一个基于主机的入侵检测系统就会很有帮助了，因为它可以帮助你很快识别出哪些东西被改动过，而不是通过猜测来浪费宝贵的时间。

via: http://xmodulo.com/host-intrusion-detection-system-centos.html

作者：Gabriel Cánepa 译者：GOLinux 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出