(window.slotbydup=window.slotbydup || []).push({
id: '4016706',
container: s,
size: '800,80',
display: 'inlay-fix'
从1月7日到9日连续三天，工信部相关领导、IDC企业、电信运营商、互联网企业、设备厂商等各行业精英齐聚一堂，以&大变革 新生态&为主题煮酒论道。其中京东网银在线架构师刘斐然应邀出席本次大会并发表了&入侵检测系统搭建与优化&的演讲。
中国IDC圈1月12日，-9日，第九届中国IDC产业年度大典（IDCC2014）（）在北京国家会议中心隆重举行。本次大会由工信部通信发展司、中国信息通信研究院（工信部电信研究院）、发展与政策论坛、联盟指导，中国IDC产业年度大典组委会主办，中国IDC圈承办，作为国内IDC行业规模最大、最具权威性和影响力的盛会，此次大会再创辉煌，三天的会议参会人数超过8000人次。
从1月7日到9日连续三天，工信部相关领导、IDC企业、电信运营商、互联网企业、设备厂商等各行业精英齐聚一堂，以"大变革 新生态"为主题煮酒论道。其中京东网银在线架构师刘斐然应邀出席本次大会并发表了"入侵检测系统搭建与优化"的演讲。
京东网银在线架构师刘斐然
以下为刘斐然演讲实录：
刘斐然：各位下午好，我先做个自我介绍，我是刘斐然，最早在人人，后来去过P2P或者是众筹的互联网金融公司，现在是在网银在线。一直以来我的工作都是在安全方面的技术工作，一直工作在第一线。今天由我来为大家分享一些入侵检测系统，是比较实在的东西，可能这个涉及一些技术的点。
首先说一下我们的目标，首先要检测Web应用安全事件，这是最基本的事件。第二是检测用户异常操作，比如类似于EDI被登录，第三HTTP的日志存储，这个需求很简单，我们查到异常的IP，但是我们想知道这个IP之后做了什么，所以在这个系统中查询，而且需要提供实时查询的功能。第四对用户敏感操作做提取、存储、查询的功能，比如说登录、修改绑定的手机这些操作。做这个的目的，我们查到一个IP去扫号，查到来的登录的请求，比如说以前试过哪些帐号？哪些帐号失败了？哪些帐号成功了？接下来就是预警，这是最基本的功能，还有会话阻断，这是非常重要的功能，是我们安全的防止事态扩大的手段，比如说我们发现线上业务有漏洞，这个时候我们通过业务去改，在业务改完上线的阶段之间，有可能造成很大的影响，我们有了会话阻断的手段会立刻把涉及到危险的业务直接阻断掉，直到业务修改成功把这个功能再关掉，这样不但给业务提供了修改的时间，而且也保证了我们线上服务的安全，还有最后一点是从部署成本来说，需要成本少。尽可能的少的涉及到我们安全设备，就是我们线上服务器的改动。另外扩展性强，我们流量增加了一倍或者十倍要通过增加机器或者是扩带宽就能达到系统分析的需求。
有了那么几个要求，这是我们系统网络架构图，很简单，首先是业内比较普遍采用的方法，这个蓝色是线上正常的服务器。我们通过从核心交换设备，把流量到我们检测中心进行安全检测，这是主题部分。下面是可选部分，在每台应用服务器，做HIDS的分析。可以看到，因为设计成这样，如果仅搭建好这一部分，我们主题部分已经搭建好了，最主要的功能已经完善了，所以说改动的非常少，我们只需要把网络交换设备或者网络设备镜像到我们整个集群中，可以做整个安全工作。这是系统逻辑结构图。
首先流量镜像，大体上分四个模块，信息收集与提取，信息分析，商业步骤汲取的信息做一个安全分析，输出是做一数据存储，另外我们做的一个安全响应，中间有分布式消息队列，进行把各个部分组件联起来，接下来我会详细介绍这四个部分。
首先信息收集与提取，第一个比较主要是流量解析，现在很多涉及到HTTP加密，如果一个系统检测不了入侵检测系统会很失败，我们之前也尝试过用软件的方式实现，但是实现起来效率很低，可能完全不满足线上业务的需求，所以我们用的是硬件的实现方案。第二个是镜像流量重组，我们从流量中从底层到应用层把我们需要的信息组出来，组出来的信息，这是包括IP端口或者里面的一些方法，URL、UA、服务应答状态和时间，我们组出来的是非常全的日志。这是从应用服务器上取得的，因为这里面有很多信息应用服务器上是提取不到的，比如说UA，这个在安全分析中这些信息是非常重要的。最后一点是将重组后的HTTP日志打入消息队列，为下一步做安全分析。
信息分析，主要是两部分。一部分是普通的流量，就是我们没有处理的流浪，直接应用到安全事件检测Surieata，这是大家在工作中也用到的，能够检测XSS一系列的文件包含或者是文件包，服务端的漏洞攻击事态。我们还原HTTP日志，实时分析集群STORM.其实是对Suricata的一个补充，做应用层的分析是Suricata做不到的，比如说频率检测，是不是有异常的IP访问你的关键业务，关键字检测，这就是对Suricata的补充，是不是有一些渗透，之前没有检测到，还有平行权限检测、后门检测，一旦发现一个攻击，分析出攻击的行为特征，还有关键字可以直接配置检测的漏洞。最后做用户异常行为分析，这个稍候会讲到怎么做，有些信息在白名单里头提到的，有些信息在黑名单里。
重点说一下异常行为分析部分。这个部分有点复杂，尽量少的和业务交互，因为如果哪个业务做的交互多可能以后改版很困难，我们提炼出这么几个基本功能。通过Cookie确定具体用户，第二通过访问的URL量确定具体业务，第三通过参数确定具体行为，第四分析服务器应答，最后数据库存储。对于这些都是通过业务提供的接口去做的，通过这些我们可以检测恶意攻击、作弊、钓鱼、业务逻辑漏洞，扫号、盗号。这是在传统Suricata当中检测不到的。
说完检测说一下数据存储，我们把数据分为四种数据，有三种存储方式。首先普通流量，是全流量记录的方式PCAP包存到Hadoop或者分布式文件系统中，当然这个肯定是短期的，流量太大了不可能存长期的数据。还原HTTP日志分布式全文检索，因为ES本身是分布式的，而且只要输入关键字可以很快的把关键字符合的日志全部检测出来，这是中长期存储。下一步关键操作和报警信息，这个信息相对于上面还是很少的，我们直接存到数据库Mysql里面。最后对于关键操作和报警信息会全部存储，不强调存储的流通。这是ES的界面，因为直接提供前端，所以直接有图表，省得我们再去做二次开发，图表很全。包括统计一些流量、省份的分布，返回的对应情况，访问运营的饼图。下面是实时刷新的访问的情况。
说一下响应，分三步，一个是预警，预警是邮件预警、短信预警；黑名单这是给业务做的，比如我们会提供维护IP黑名单或者异常用户名单这么一个库、通知业务部门做一个参考；另外还有阻断功能，旁路阻断，这是直接用Serfat功能。刚才提到了只是一个基本的平行检测的架构，但是实际上搭建完之后可能这个系统的性能或者是各方面检测的体系内容都是不太理想，该怎么优化？这里面四个部分提了四组优化方法。首先信息收集与提取部分，捕包效率，如果用系统自带的捕包只能做到千兆，可能千兆还不全，那么万兆更别提了，所以我们优化是原先比较常用的，我们用业内常用的PRM，目前没有买他的许可，因为目前我们用PI直接做到捕包效率完全是够用的。
第二信息分析，Suricata检测准确度；数据存储存储与检索效率，对数据库优化数据效率，另外响应Suricata旁路阻断我们做了一个优化，之前默认强制设备双向阻断。如果一个恶意用户访问一个已经标明的，之前是直接给员工发IC包，我们感觉还是双向的，是既给用户也给服务器发一些包。
接下来主要讲Suricata检测准确度优化，这个优化一直想该怎么做？现在有一套实施起来比较简单的方案跟大家分享一下。首先说一下使用中的问题，导致两个，首先第一个无法智能判断服务器是否存在漏洞，这是最关键的问题；第二大量的安全预警，安全人员无法处理。一般一天报几万个报警是正常的，而且报警有人拿扫描扫你或者是想去渗透你，你要做这条规则不能下掉。第二个很难通过人工去确认。因为Suricata和Smolband只记攻击的，不会对服务器厂商做分析，你要人工去做分析你只能重放，重放一个没问题，你要重放一千个，而且要对服务器应答进行判断，你可能很头疼。这个其实在我使用过程中也亲身经历过，我收到报警，我就想是不是有这个服务，但是是使用场景不一样，这个用户自己的产品够用他可以会触发这个东西，因为业务逻辑很复杂，你用你的身份登录可能处罚不了这个。
接下来说一下我们怎么做的，一直想优化这个，能达到什么程度？可能有两点。第一个最简单的你来渗透我，你来测试我。第二点一旦当你渗透成功，当你验证服务器有漏洞我和你是同时发现的，我觉得这是检测最终的一个版本。之前考虑了好多方法，比如改Suricata的原码，或者在Suricata上做研究，但是后来发现这部分内容技术含量很高，而且成本也很高，而且Suricata是不断发展。现在是2.0.5，可能过段时间是2.1.几的版本。但是如果你停留在一个版本上不开发是不行的，而且你一个版本一个版本开发是非常耗费精力的工作，所以现在做了一层包装，把它的报警重新判断一下，有一个UVE，首先读出报警，它的格式量，包括几个关键字段。我们首先可以通过这三个做广义的开发，比如你不接受危害度，危害度1是最高的，你不接受2或者以下的危害度你可以做一个这个问题，接下来是不是报警？或者非运营产品有没有Web Server？当然还有一些其他的规则，是不是Web server你可以做基本的。这是第一步，第二步排查好之后我们要利用PCAP文件中，刚才报警中还原整个HTTP，包括整个原件，服务器洞察哪些东西，其实一般如果用开源的或者商业扫描器扫描一下一次链接有二十多个请求，这只是举了第一个请求。可以看到请求了Log.txt.然后有了AWS，传统的报警到这儿就没了，这个人访问了一下，安全人员不知道到底你服务器上有没有这个软件，接下来你看这里可以放心了，直接跳转，说明报了个错就没有这个文件。
接下来我们有了整个HTTP交互流量以后，比如说攻击者测试过，而且服务器应答过，接下来用同样的方法去测，服务器返回同样的应答，这个不会再报警。做法是从HTTP会话中去除IP信息，这些有特定含义的指标，接下来是检查此哈希的数量及时间。最后有一个危险度判定，通过刚才去除和会话判断到底这次渗透概率是多少，我们可以根据返回码，比如说有一次他尝试后台的操作，如果返回码是404或者是一些其他错误那说明没有这个漏洞，如果返回200或者301说明有服务器后台暴露。所以对于这种通过访问码可以确定服务器到底有没有漏洞？另外具体应答内容是否包含特定关键字，你要整理，你的服务器应答里包含哪些字段？证明有用的概率是多少？这里比较复杂一些。然后阈值，概率达到多少以后报警。
这是通过系统优化后的设定，首先邮件预警，是一个攻击视图，这儿有很多，24个请求，有很多尝试。首先这是403，服务器返回的403、服务器返回564，这是一个Post请求。这是他的请求，包括所有的内容。其实一般传统的IDC提供商可能去试一下，但是实际上报警还有后面部分，服务器应答。403直接返回，这是服务器应答的内容，所以可以直接忽略掉这个报警了。其实优化部分重要的讲的是这一点，接下来看一下HIDS，很多大的公司因为入侵检测做不到精准分析，所以他们最后一道防线是HIDS，是最重要的。
首先文件系统监控，这是Linux的监控，包括你改了什么？另外这个文件是不是一个后门，是不是一个原码，在这里做一个文件系统访问。另外进程监控，检测建立进程的用户是否合法，监控进程创建，一旦发现这种行为肯定有入侵发生。检测父进程是否合理，下面是敏感进程，服务器一系列的操作。第三个关键行为监控，这是我们通过日志分析方法做的，ssh等服务的登录登出。第四机器性能监控，通过流量异常监控出来的。这些异常我们可以把它报警直接恢复到之前的那套东西，比如说我发现一个用户有一个上传的请求，在我服务器端出现了问题，这可能是传输端出了问题，谢谢大家。
关注中国IDC圈官方微信：idc-quan或微信号： 我们将定期推送IDC产业最新资讯
京东很会玩营销，去年的“双十一”在宿迁玩了无人机配送，今年“6.18”在中国人民大学用机器人配送，吸引了许多人的眼球。毫无疑问，这比促销本身更吸引人。
如同其他购物节,“618”成为“剁手族”们“血拼”的一个节日。
6月13日晚间，据《财经》报道，新加坡知名资产管理公司毕盛资管创始人Wong Kok Hoi在一份报告指出，把京东比喻成中国的亚马逊是一个错误...
“一带一路”和大数据注定要产生互动、喜结良缘：大数据为连通“一带一路”提供助力，“一带一路”为大数据展现力量提供舞台。
曾几何时，中国的互联网产业发展是百度、阿里和腾讯三大巨头交替领先，三大公司的首字母组成了BAT，分别代表中国互联网搜索引擎、网上购物和互联网交际娱乐方面的领跑者。
热门会议：
我们的服务：在CentOS上配置基于主机的入侵检测系统（IDS）
-18%-27%-55%-67%76%-78%-81%-83%-90%
所有系统管理员想要在他们生产服务器上首先要部署的安全手段之一，就是检测文件篡改的机制&&不仅仅是文件内容，而且也包括它们的属性。
（&高级入侵检测环境&的简称）是一个开源的基于主机的入侵检测系统。AIDE通过检查大量文件属性的不一致性来检查系统二进制文件和基本配置文件的完整性，这些文件属性包括权限、文件类型、索引节点、链接数、链接名、用户、组、文件大小、块计数、修改时间、添加时间、创建时间、acl、SELinux安全上下文、xattrs，以及md5/sha校验值在内的各种特征。
AIDE通过扫描一台（未被篡改）的Linux服务器的文件系统来构建文件属性数据库，以后将服务器文件属性与数据库中的进行校对，然后在服务器运行时对被修改的索引了的文件发出警告。出于这个原因，AIDE必须在系统更新后或其配置文件进行合法修改后重新对受保护的文件做索引。
对于某些客户，他们可能会根据他们的安全策略在他们的服务器上强制安装某种入侵检测系统。但是，不管客户是否要求，系统管理员都应该部署一个入侵检测系统，这通常是一个很好的做法。
在 CentOS或RHEL 上安装AIDE
AIDE的初始安装（同时是首次运行）最好是在系统刚安装完后，并且没有任何服务暴露在互联网甚至局域网时。在这个早期阶段，我们可以将来自外部的一切闯入和破坏风险降到最低限度。事实上，这也是确保系统在AIDE构建其初始数据库时保持干净的唯一途径。（LCTT 译注：当然，如果你的安装源本身就存在安全隐患，则无法建立可信的数据记录）
出于上面的原因，在安装完系统后，我们可以执行下面的命令安装AIDE：
# yum install 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假定使用了--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"
测试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这样一个基于主机的入侵检测系统就会很有帮助了，因为它可以帮助你很快识别出哪些东西被改动过，而不是通过猜测来浪费宝贵的时间。
作者： 译者： 校对：
原创翻译， 荣誉推出
上一篇：下一篇：
共计翻译： 177 篇
| 共计贡献： 1033 天
贡献时间： -&
分享到微信
打开微信，点击顶部的“╋”，
使用“扫一扫”将网页分享至微信。
请将我们加入您的广告过滤器的白名单，请支持开源站点。谢谢您。如何在 Linux 系统上安装 Suricata 入侵检测系统-系统运维|Linux.中国-开源社区
如何在 Linux 系统上安装 Suricata 入侵检测系统
随着安全威胁的不断发生，入侵检测系统（IDS）在如今的数据中心环境中显得尤为必要。然而，随着越来越多的服务器将他们的网卡升级到10GB/40GB以太网，对如此线路上的硬件进行计算密集型的入侵检测越来越困难。其中一种提升入侵检测系统性能的途径是多线程入侵检测系统，它将 CPU 密集型的深度包检测工作并行的分配给多个并发任务来完成。这样的并行检测可以充分利用多核硬件的优势来轻松提升入侵检测系统的吞吐量。在这方面有两个知名的开源项目，分别是
这个教程里，我会向大家演示如何在 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 了。
下载 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:
PF_RING support:
NFQueue support:
NFLOG support:
IPFW support:
DAG enabled:
Napatech enabled:
Unix socket enabled:
Detection enabled:
libnss support:
libnspr support:
libjansson support:
Prelude support:
LUA support:
libluajit:
Non-bundled htp:
Old barnyard2 support:
CUDA enabled:
现在可以编译、安装了。
$ sudo make install
Suricata 源代码带有默认的配置文件。按照如下方法安装这些默认配置文件即可。
$ sudo make install-conf
正如你所料，如果没有IDS规则集的话，Suricata 什么用也没有。幸好 Makefile 为我们提供了 IDS 规则集的安装选项。安装方法如下。
$ sudo make install-rules
以上的规则安装命令会从
上下载可用的社区规则集快照，并且将其存储在 /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 流量。所以是不是正确指定端口就显得没那么重要了。
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-right: []
old-linux: []
# Make the default policy Linux.
linux: [0.0.0.0/0]
old-solaris: []
solaris: ["::1"]
hpux10: []
hpux11: []
windows2k3: []
在 threading 部分下，你可以为不同的 Suricata 线程指定 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处理的线程截图(由
Suricata 检测日志存储在 /var/log/suricata 目录下。
$ tail -f /var/log/suricata/fast.log
04/01/:12.559075
[**] [1:] SURICATA TCPv4 invalid checksum [**] [Classification: (null)] [Priority: 3] {TCP} 172.16.253.158:22 -& 172.16.253.1:46997
04/01/:06.565901
[**] [1:] SURICATA TCPv4 invalid checksum [**] [Classification: (null)] [Priority: 3] {TCP} 172.16.253.158:22 -& 172.16.253.1:46317
04/01/:06.566759
[**] [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":"T15: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":"T15: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 入侵检测系统。不同于单线程的
，Suricata 可以很容易的从多核硬件的多进程特性所带来的好处中获益。定制 Suricata 来最大化其效能和检测范围是一个很好的主意。Suricata 的粉丝们维护着一个 ，如果你打算将 Suricata 部署到你的环境中，我强烈建议你去那儿取取经。
如果你现在已经开始使用 Suricata 了的话，把你的经验也分享出来吧。
作者： 译者： 校对：
原创编译， 荣誉推出}