从规则集看IDS网络探测器的检测能力

随着企业和组织对网络安全的日益重视，网络IDS产品以其强大的检测攻击的能力已经成为必要的防火墙、防病毒产品后又一个安全组件设备。从检测方式看IDS产品可分为基于规则（基于误用）和基于异常。基于规则的IDS技术相对成熟，检测准确性可以做的很高，但致命弱点是和反病毒产品一样只能检测已知攻击。基于异常的检测技术还不太成熟，检测准确性不太高，但其最大的优势是通过分析异常检测某些未知攻击，是当前理论界和工业界的研究热点[1]，随着研究的深入在不久的将来很可能逐步取得突破（实际上以协议分析技术为基础协议异常分析已经相当成熟了）。

从IDS检测引擎的实现上主要有两种，一种是简单的ngrep类型的引擎，这种检测引擎对数据包作基本的IP/TCP/UDP/ICMP等三、四层协议解码后就结合数据包数据区的内容匹配来检测攻击，这种实现方式的优点是实现简单，加入规则容易，在规则总数较少的情况下效率较高。ngrep类型的引擎缺点也非常明显，由于只对数据包内容做生硬的匹配无法抵抗多种的变形攻击，非常容易受到愚弄而被绕过，也因为数据匹配的范围很大，在规则总数大量增加的情况下引擎的效率会极剧下降。为了减少ngrep类检测引擎与生俱来的缺陷，当今主流IDS网络探测器普遍使用了高层协议分析技术，也就是加入了对第七层应用层协议的解码和状态分析，这样做虽然很大程度上加大了检测引擎的复杂性，但极大的提高了检测的准确性并能检测检测到某些协议异常的未知攻击，由于匹配区间的减小，在大量加载规则的情况下也不会造成性能太大下降，因此基于协议分析的引擎比单纯的ngrep类型的检测要高级的多。

目前市面上充斥了大量的IDS产品，都号称自己是优秀的产品，拥有强大的检测能力，是否真如厂商所称的那样呢？当然你可以读各种各样的厂商或第三方的产品测试报告来试图了解个大概，但IDS产品的测试非常复杂，涉及到各种技术和环境的影响，因为IDS技术从整体上还不成熟，所以应该说当前大多数的IDS评测也是极不完善的，从测试方法上就存在很多先天的缺陷，其结果并不能真实反映产品实际环境下的能力，有时候评测结果甚至完全是误导性的。

现在主流的IDS产品是采用完全基于规则的或者基于规则与基于异常结合的检测方式。如果厂商允许用户查看或定制IDS的规则集，那么我们可以从此侧面大致了解清楚IDS探测器的实际能力，因为IDS规则的描述方式及提供的检测选项直接反映了IDS探测器对检测内容及方法的支持能力。

下面我们来分析几个公开了规则集的IDS产品（Snort 1.8.6、Dragon IDS 6.0、NFR NID-100、天阗IDS 5.31）的规则定义，由此来从一定程度上评价IDS探测器的检测能力。

Snort

=====

Snort是最出名的开放源码的IDS系统，它的规则集[2]是一些大致以应用层协议分类的.rules文本文件，比如dos.rules文件存放拒绝服务攻击类的规则；ftp.rules文件存放FTP服务相关的规则；telnet.rules文件存放FTP服务相关的规则。规则文件中每行定义一种攻击检测，例子如下：

alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP SITE CPWD overflow attempt"; flow:established,to_server; content:"SITE "; nocase; content:" CPWD "; nocase; content:!"|0a|"; within:100; reference:bugtraq,5427; reference:cve,CAN-2002-0826; classtype:misc-attack; sid:1888; rev:3;)

一条Snort规则可以分为前后两个部分，规则头和后面的选项部分。规则头包含有匹配后的动作命令、协议类型、以及选择流量的四元组（源目的IP及源目的端口）。规则的选项部分是由一个或几个选项的符合，所有主要选项之间是与的关系。选项之间可能有一定的依赖关系，选项主要可以分为四类，第一类是数据包相关各种特征的描述选项，比如：content、flags、dsize、ttl等；第二类是规则本身相关一些说明选项，比如：reference、sid、classtype、priority等；第三类是规则匹配后的动作选项，比如：msg、resp、react、session、logto、tag等；第四类是选项是对某些选项的修饰，比如从属于content的nocase、offset、depth、regex等。

总的来说，Snort的规则相当有特色，简单高效，体现在规则选项概念清楚明确，选项之间没什么从属关系，规则所提供了丰富的选项用以匹配各种包特征，通过对选项加以组合基本上就能清楚地描述出基于单包的攻击，绝大多数规则只需要一行代码就行。

Snort设计之初是一个ngrep类型的IDS，合适检测基于单包的攻击，是在基本TCP/IP解码的基础上对数据包的数据区进行匹配，对规则选项也不允许复杂的逻辑组合，这种粗糙的检测方式存在很高的漏报误报而且极容易受到反IDS手段（比如变形shellcode）的愚弄。新的高层协议分析技术可以很大程度地避免此类问题，提高检测准确率。Snort逐渐加入一些高层协议（当前支持最常用的HTTP和TELNET）的部分解码，比如在下面的规则使用了较新版的Snort引擎提供的uricontent选项用来匹配HTTP URI请求中的文件名。

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-CGI HyperSeek hsx.cgi directory traversal attempt"; uricontent:"/hsx.cgi"; content:"../../"; content:"%00"; flow:to_server,established; reference:bugtraq,2314; reference:cve,CAN-2001-0253; classtype:web-application-attack; sid:803; rev:6;)

以上规则检测HTTP请求的URI中是否包含“hsx.cgi”文件名，并检查数据区是否包含“../../”字串，如果攻击者企图利用hsx.cgi脚本的目录遍历漏洞，应该会在同个数据包的数据区搜索到“../../”这个表示遍历上级目录的字串序列。

Snort在全世界志愿者的努力支持开发下，一直在不停地改进中，基本每个新版都会增强一定的引擎的检测能力，同时在规则集中也加入了新的选项。但从总体看由于Snort初始的框架设计限制，其技术水平与主流的商业IDS产品相比还是越拉越大，相对越来越落后。

Dragon IDS

==========

Dragon IDS是Enterasys Networks公司开发的入侵检测系统，它获得了不少的奖项，包括Network Computing杂志的2003年度产品奖。作为一个完整的IDS产品，Dragon现在拥有网络探测器和主机探测器，网络探测器部分它开放了全部的规则集并提供了详细的文档说明如何解释和设置检测规则。

Dragon IDS网络探测器的规则集一般存放在名为dragon.sigs的文本文件中，文件中每行一条规则，示例如下：

[root@ /usr/dragon/sensor/conf]> head dragon.sigs

# Copyright 2000 Network Security Wizards

# Wed Nov 29 12:13:52 2000

U D A B 10 20 H BACK-ORIFICE:DIR /ce/63/d1/d2/16/e7/13/cf/3c/a5/a5/86

U D A B 10 20 H BACK-ORIFICE:INFO /ce/63/d1/d2/16/e7/13/cf/39/a5/a5/86

U D A B 10 20 H BACK-ORIFICE:SCAN /ce/63/d1/d2/16/e7/13/cf/38/a5/a5/86

T S A B 100 20 5600 BLADE-RUNNER Blade/20Runnner/20

T D A S 50 40 W CARBO:COMMAND /2fcarbo.dll/3ficatcommand

T D A B 15 2 7161 CISCO:5000-DOS /0a

T S A B 5 6 1999 CISCO:IDENT-SCAN cisco

每条规则一般由多个或单个的空格相隔的九个字段构成，对每个字段含义解释如下（整理自Dragon提供的手册）：

T D A S 10 20 80 WEB:CGI-PHF get/20/2fcgi-bin/2fphf

| | | | | | | | |

| | | | | | | | 匹配的字串（/开头的为十六进制值）

| | | | | | | 事件名

| | | | | | 端口（TCP或UDP包的端口）

| | | | | |

| | | | | 比较的字节数（数据包数据区的前多少字节，也就是比较深度）

| | | | |

| | | | 动态记录包数（给后续规则处理的数据包数）

| | | |

| | | 二进制或文本（S:匹配文本，匹配时大小写不敏感，要匹配的字串必须全部小写形

| | | 式; B:匹配二进制串，匹配过程大小写敏感）

| | |

| | 针对的网络流量（A:所有流量; T:去往受保护网络的流量; F:去往受保护网络的流量;

| | I:受保护网络内部的流量; X:受保护网络外的流量; D:先前规则处

| | 理的后续流量）

| |

| 方向（A:匹配源目的中的任意一个端口; B:两者都匹配; D:匹配目的端口; S:匹配源端口）

|

协议（T:TCP; U:UDP; I:ICMP; 其他IP协议:数字）

可以看到Dragon规则是很简单的，基本上就是几个数据包特性选项的与关系组合，匹配特定网络流量的特定数据特征。规则只提供了储如数据包网络层协议、端口、方向及数据区的字串匹配选项给用户，很明显这些特征对于描述日益复杂的网络攻击是远远不够的。比如用户无法指定一些如包数据区大小、包的标志位及TTL等细节特征，对于数据区的匹配指示也非常的弱，只能指定匹配数据区的前多少字节，而无法指定具体匹配数据区的哪几个字节，同样也无法组合数据区的多个特征进行综合判断。这样差劲的数据包描述能力必然会带来很大的漏报和误报，比如Whisker CGI扫描器[3]的一种流行的变形方式（GET /长随机字串/../vulnerable.cgi）可以很轻松的躲过上例规则的检测，而且很多的攻击根本就无法描述，因为规则描述能力上的限制可以肯定的说Dragon IDS攻击检测能力上连Snort都不如。从规则集的整体来看，因为没有深入分析到高层协议，可以很有把握的判断Dragon IDS网络探测器基本上是一种ngrep类型的检测引擎，这种简单粗放的检测引擎已经是处于淘汰行列的技术。