英语原文共 6 页，剩余内容已隐藏，支付完成后下载完整资料

关于Suricata和Snort入侵检测系统的实验性对比

摘要

摘要------监测计算机网络的Suricata入侵检测系统相对于流行了将近十年之久的Snort来说是一个开源方面的改进。Suricata支持多线程处理，这使它在这方面优于Snort。之前对于这两个产品的比较都没有用现实中的机器设备，我们这次做到了这点并且评估了它们的速度，内存需要，以及检测引擎在这三个实验条件下的精准度：（1）在我们的学校满通讯量的主干网络上进行实时监控。（2）在超级计算机中监测主干网络的数据包。（3）对red-teaming产品发送的恶意包的反应情况。除了一些缺失了功能的特殊地方，我们都用同样的规则来设置这两个项目。实验后我们得到结论，Suricata可以在保证同等的准确率的同时比Snort处理更大的流量，它的表现和处理器的个数在48个处理器以内都呈现正相关。我们察觉到在目前的状况下Suricata并没有在速度或者准确性方面比Snort有很明显的优势，但是Suricata还在开发阶段中。我们的实验方法对于比较两个入侵检测系统来讲还是有用的。

关键字： 检测， 计算机网络， Snort， Suricata， 性能

Ⅰ. 引言

网络安全监测需要建立在深入防御策略上的入侵检测技术和入侵防御技术[1,2]，所以大量的产品都是可以使用的。开源项目Snort（www.snort.org）已经成为了基于签名的网络入侵检测引擎的工业标准[3]。OISF组织于2009年发布了一个名叫Suricata的（www.openinfosecfoundation.org）新的基于签名的网络入侵检测引擎。Suricata是一个开源项目，并且它被期待成为“新生代的入侵检测/IPS系统”。Suricata有一个与生俱来的多线程处理机制，这是一个在网络带宽快速增长的情况下很有用的特点。Suricata也在Snort的基础上改进了状态分析能力，这对于HTTP流量来说是极为重要的。传统的Snort安装可以以100-200M/S的速度处理网络流量，为了不达到单核CPU的处理极限，Snort需要以丢包的方式来补偿这个缺陷[4]，并且现在很多网络流量已经超过了那个界限了。所以开源产品Suricata的出现预示了它会成为一个更受欢迎的产品，因此对于它们的评估比较是很重要的。

Ⅱ.之前的工作

入侵检测是很难去完美的实现的[5]。事实上优秀的规则是很罕见的，因为大部分规则都比较简单，而且很多规则都是较为模糊的，因为一个攻击并没有很明确的签名。入侵检测引擎自身的性能问题也可能导致误判。如果硬件被过度的使用了，它就有可能会发生丢包现象并且让恶意包从网络通过，这些问题都使得对入侵检测系统的测试变的十分具有挑战性。

之前的工作对比了Snort2.8.5.2和Suricata1.0.2[7]之间的性能差异。他们的测试包括一个2.8GHz 四核intel CPU，3GB内存的机子上的VMWARE Workstation上搭建的ubuntu虚拟机虚拟环境。他们测试了在不同的网络及处理器层次下入侵检测引擎的速度和精准度。报警触发用注入六个由Metasploit（www.metasploit.com）框架开发的已知的恶意文件来模拟的，结果表明了Snort会比Suricata更有效的利用系统资源，当涉及到多核环境时，Suricata则因为有更少的错误警报而显得更加精准。然而他们得出了一个结论：当处理2GB的网络数据包时，在四核环境下的Suricata比在单核环境下的Snort的处理速度更慢。

另一个报告对比了Suricata和Snort在检测大量恶意文件和可疑动作时的精准度[8]。用一个专门设计来发送恶意包的Python应用来对入侵检测系统从不同角度检测漏洞，这项工作的目的是对比两个引擎的精准度。结果表明VRT和ET规则表现很好，但这需要把系统调整为最高效的模式。

另一个研究测试了Suricata在多线程处理下的性能，通过修改这个运行在六核，并且允许超线程处理的CPU系统上的Suricata的配置文件来调整线程比和CPU事务变量，他们把线程比降低到了0.125后得到了最佳的处理性能，这正好对应到Suricata上是三个线程，他们也发现了超线程处理的配置导致了性能结果的变化（运行中出现的30%的差异），并且这其实对于在同一硬件CPU上配置多线程处理来说是最好的结果。接着他们决定用一个叫做perf-tool（code.google.com/p/google-perftools）的工具来实现随时间增加可能出现的线程锁的情况。他们得出的结论是，将Suricata设置为RunModeFilePcapAutoFP模式会导致它的性能稳定增长，然而RunModeFilePcapAutoFP一开始会增长，后来即出现了每秒处理包的数量的性能上的下降。

对于之前的研究工作，[7]是最有野心的。然而，他们只用了一个简单的服务器流量结构，六个发掘方式，和一个四核的处理器。这就使得将他们的实验结果扩展到更高性能的设备上时变的困难，所以我们的目标就是在[8]和[9]的基础上做更多的测试。细节都在[10]中详细给出。

Ⅲ. 实验描述

关于一个控制器（这个例子中是Snort）的全面的多线程处理的测试需要：（a）在一个和大众安装环境差不多的环境中做速度测试比较。（b）关于在多线程中速度改善的测试。（c）关于检测已知攻击的精准度的测试。因此我们组织了三个实验。如果Suricata像Snort一样在每一个测试中都表现良好，那我们就会强烈推荐使用它，这三个实验也可用来评估任何多线程的产品。

实验环境搭建

我们的实验网络流量来自于美国海军研究生院的网络流量，ERN。这里有一个20Gbps的网络宽带，并且有每天200Mbps的平均数据流量。签名信息主要来自以下两个源：VRT规则库（Snort的官方规则（SourceFire2011））和ET规则（www.emgergingthreats.net）。这两个入侵检测系统都支持VRT和ET规则。

大多数的实验都是在一个叫VMware ESXi4.1的虚拟机环境下完成的。服务器的硬件条件是拥有96GB的内存的戴尔R710四核处理器，每一个CPU都是2.4GHz的Intel Xenon E5630，这些数据存储是通过三个光纤通道磁盘阵列配置阵列完成的，服务器上安装了1Gbps的网卡，用于各种管理服务以及虚拟机服务。在我们的实验中，服务器配置有2个接口，一个用于系统管理，一个用于捕捉网络流量，连接到网络的接口卡设置成了混杂模式，这样就允许它接收到所有的网络流量。我们用的是四核CPU和16GB内存的虚拟机。考虑到CentOS为企业所应用的普遍性以及它与Red Hat的紧密关系，我们选择CentOS5.6操作系统。

Suricata的安装是很简单的，但我们需要自己编译配置Suricata，需要安装一系列在CentOS5.6发行版中没有包括的软件依赖，这其中有PERL编译库（PCRE），让操作系统可以捕获到所有网络流量的抓包函数库（Libpcap），以及YAML库（yaml.org）。在实验过程中，Suricata发布了beta2的版本更新，我们及时的切换了所用版本。尽管Suricata和Snort都兼容这些规则，我们还是发现了一些例外情况，在Suricata中加载VRT规则的时候我们收到了一些错误信息。

Snort2.9.0.5与CentOS6.6之前的发行版中的Libpcap库存在兼容性问题，还好Vincent Cojot维护了这一系列的ROM包（为红帽系列Linux发行版而生的软件预编译安装包），因为我们的PCAP文件太大，所以我们想跟新到Snort2.9.1版本，但是Cojot的软件管理并不支持。

32位操作系统的内存上限意味着我们不能在我们的32位CentOS5.6操作系统上加载超过30000条的全部ET和VRT规则，所以我们的实验减少到了16996条规则。

实验中也用到了Pytbull，这是一个用发送它的样本流量的方式去检测IDS系统的检测恶意流量能力的工具（pytbull.sourceforge.net），为了捕捉网络上实时流量和重复流量，我们用到了Tcpdump（tcpdump.org）和Tcpreplay（tcpreplay.synfin.net）。实验中关于系统性能的数据是通过Collet1收集的（Collet1.sourceforge.net）。

三个实验

第一个实验在Snort和Suricata实时监测ERN主干网络的时候评估了它们的实时监测能力，CPU，RAM以及网卡的性能都被测试，比较并且记录了下来。第一个实验一开始比较了Suricata和Snort监测内部路由的网络流量（图1）。我们同时在虚拟机上运行了实验，用来比较在哪个运行环境中检测引擎的精准度更高。

图1.第一次实验的环境搭建

第二个实验持续了四个小时，用一个安装了Suricata的超级计算机来监视网络流量。这种类型的任务对我们的信息技术部门来说是很重要的，因为他们经常常规性的回顾分析一些出现过的攻击。每一个检测引擎都设置成了默认性能参数。第二个实验首先用Tcpdump观测一个来自于NPS ERN的PCAP大文件，这个文件大概有6GB，它包含了大概四个小时的网络流量数据，我们用这个安装在48个CPU的超级计算机上的Suricata来处理这个大文件，来和实验一中设置了性能参数的Suricata进行对比。

第三个实验是Suricata和Snort识别恶意文件以及不规则数据的精准度测试。我们用Pytbull向检测系统发送了54个恶意包，以此来触发警报，这里面包括了9种测试：客户端攻击，常规规则检测，恶意流量包分析，认证失败，隐蔽的入侵检测系统，反向shell，拒绝服务，恶意认证。完成此实验需要一个可以生成测试报告并且支持HTTP和FTP服务的机器和一个受害机器。我们选择vsftpd作为我们的FTP客户端，用已经在CentOS中安装好的浏览器作为网络服务器。这个网络服务器因研究的需要从一些网络安全相关的网站上提前加载了很多破碎的文件和恶意文件，我们选择了四个PDF文件和一个XLS文件。

Ⅳ.实验结果

实验一

从收集的数据可以看出，在同一网络流量中，Suricata比Snort更能消耗计算资源，数次运行Suricata和Snort之后发现，Snort用了一个CPU的60%-70%的同时Suricata占用了四个CPU中每个CPU的50%-60%，Suricata也比Snort有更强的记忆能力，并且系统内存的需求也随着系统环境的变化在稳定增加（图2），Snort的内存占用率一直稳定在0.9gigabytes。

图2 Suricata内存占用

尽管我们使用的是多核处理器，这个系统想要实时的跟上网络流量还是有一些困难，在使用Tcpdump的时候我们发现处理Suricata和Snort的日志丢包率已经上升到了50%。鉴于这个丢包率在两个引擎中是相似的，我们总结出问题的原因是EXSi服务器的虚拟环境和默认内核缓冲区的设置太小了，所以我们将net，core，netdev_max_backog都设置到了10000，rmem_default设置为16777216，remex_mx设置为33554432，tcp_mem为194688 259584 389376lsquo;，tcp_rmem为1048576 4194304 33554432，tcp_no_metrics_save设为1。这样就将Tcpdump中的丢包率降低到了1%以下。

然而即使我们做了这些设置，Snort还是产生了丢包率53%的报告，Suricata则产生了丢包率7%的报告，Snort日志文件中将丢掉的包分类为“够不到的包”，这说明这些包在接收到之前就被包处理引擎丢掉了[11]，我们的数据表明够不到的包的数量与Snort中丢包数量一致，这说明了这些数据包在被处理引擎捕捉到之前就已经丢失了，所以这并不是入侵检测引擎的问题。Suricata和Snort一样并没有破坏这些被丢掉的包的结构，所以这个推理也不能仅凭它们的日志文件来得出，另外应该有一个专门的调查来明确为什么在Tcpdump，Suricata和Snort之间会有不一致的丢包率。

第一个实验的第二部分就是同时运行Suricata和Snort时观察比较它们产生的警报，并且观察此时的数据流量。对于大部分规则来说，Suricata都比Snort在同一网络流量中产生了更多的警报（0%-30%或更多）。尽管两个检测引擎都加载了同样的规则设置，我们还是接收到了一些错误报告，一些规则也没有成功的加载。

实验二

第二个实验是在一个拥有144叶和1152个CPU核的高性能的太阳6048操作系统上运行的Suricata。这个操作系统是CentOS5.4，Suricata和Snort的安装是很简单明了的，为了做这个实验我们运用了一个之前由NPS主干网络生成的平均803.6bytes大小的总共为6GB的Libpcap文件，我们在这个实验中没有研究警报产生的精准度，只研究了相关处理速度的不同之处。

我们根据性能调整了Suricata配置文件中的三个参数：detect_thread_ratio， max-pending-packets，和run mode。Detect_thread_ratio的值决定了Suricata可以产生的线程的数量，它的值乘以CPU数量则是线程数，我们一般取值为0.1到0.2。max_pending_packet的值决定了检测引擎可以同时处理的最大包数量，在实验中我们一般取值为50,500,5000和50000。Runmode参数决定了Suricata怎样处理各个线程的方式，可选的选项有单一方式（单线程），自动（多线程）和AutoFP（不分流的多线程）。

结果表明在48CPU中，Auto run

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[153282]，资料为PDF文档或Word文档，PDF文档可免费转换为Word