如何在评测之外粗略评价NIDS的检测能力文章来自于stardust@xfocus.org.转载请写明出处及作者。谢谢!
现在很多企业都力图通过增加设备投入来加强自身网络的安全性,继防火墙之后入侵检测类产品已经越来越多地被列入了采购的清单。由于看好这块市场,很多并不具备足够研发实力的纷纷推出了所谓有自主知识产权的入侵检测产品,与其他当前比较热门的安全产品一样,入侵检测产品市场也呈现了鱼龙混杂的局面。
如何为自己挑选到一款相对较好的NIDS产品呢?用户当然可以参考一些第三方评测机构的报告,比如国外比较出名的NSS、OSEC的评测。这些评测从技术上来看还是比较完善的,结果也是相对公平的,但仔细看这些评测报告,会发现存在着一些问题:1. 基本上没有国内产品参与过此类评测,所以无法从报告中了解很多国内产品的情况,而我们的采购则基本上以国内的产品为主。2. 比较侧重性能的测试,在检测能力的评测上比较弱,用于测试的攻击都相对很老,于是出现结果你好我好大家都好的局面,因此无法了解产品对于攻击的检测能力。
了解一个产品好坏最好的办法当然是一段时间在实际环境中的试用,这样可以了解产品使用起来是不是顺手,漏报误报如何,还会很快暴露出评测过程中不会出现的问题。但大多数的情况是在采购过程中除了简单的测试外,也没有评测报告可以参考,那么我们能不能从侧面粗略评价一下NIDS的检测能力呢?
当前主流的NIDS从技术上还是采用以误用检测为主的方式,也就是说NIDS对于新攻击的检测与病毒检测类似,发现新的漏洞或攻击方式以后,厂商在产品的规则集中添加相应的特征,用户获取更新后的规则集后具备对新攻击的检测能力。
现在各大厂商都号称自己的产品能够检测数以几千计的攻击,在做宣传的时候能检测的攻击数吹得就如同文革时候放高产卫星一样,你说一千那我就说两千,你说两千我就说三千,做演示的时候厂商往往会打开产品的帮助文件让你看看里面所列的各种攻击名称和相关说明,以使你确信他们的产品真的具备检测很多种攻击的能力。事实情况是不是真的如厂商说的那样吗?很不尽然。
国际上比较权威的漏洞数据库及索引有SECURITYFOCUS、CVE、OSVDB,国内最权威和完整的中文漏洞数据库则当数绿盟科技。SECURITYFOCUS公司的漏洞数据库来源于BUGTRAQ,目前收录的条目超过10000条;CVE本身并不是漏洞数据库,它是一个对同一漏洞统一编号系统,目前收录的条目超过7000条;OSVDB是近期公布的一个开放源码的漏洞数据库,目前收录的条目超过8000条;国内绿盟科技的数据库目前收录条目超过6000条。在这些漏洞中,其中大部分是本地漏洞,不在NIDS检测的侯选之列,在远程可利用的侯选漏洞列表中,有的利用难度太高而不具真正的可用性,有的影响的软件使用量太少,有的漏洞太老当前已经基本上不存在了,有的利用方式现有NIDS技术无法实现检测,经过层层筛选真正值得NIDS去检测的漏洞攻击也就是1000左右的数量级。当然,厂商根据自己NIDS产品的定位可能会加入不少并不是攻击检测的网络监控类规则,比如各种服务的用户登录、用户执行某些操作等等,但这些不会是规则的主要构成部分。那么有的厂商为什么会号称有几千条的规则呢?事实上规则看起来数量多很多时候并不意味着NIDS的检测能力强,由于NIDS产品技术的复杂性,情况有可能正好相反,可能的原因有几方面:
1. NIDS产品检测引擎实现简单,缺乏必要的关联能力,只能检测并报出同一种攻击的多个具体操作,而这些却被厂商吹成是检测到多个攻击。以Snort为例,用于检测同一个版本的DeepThroat后门规则有好几条,无法关联多个事件的Snort引擎只能检测到后门执行的某些操作,而无法给出一个抽象层次更高的告警。
alert udp $EXTERNAL_NET any -> $HOME_NET 2140 (msg:"BACKDOOR DeepThroat 3.1 Connection attempt"; content:"00"; depth:2; classtype:misc-activity; sid:1980; rev:1;)
alert udp $HOME_NET 2140 -> $EXTERNAL_NET any (msg:"BACKDOOR DeepThroat 3.1 Server Response"; content:"Ahhhh My Mouth Is Open"; reference:arachnids,106; sid:195; classtype:misc-activity; rev:4;)
alert udp $EXTERNAL_NET any -> $HOME_NET 3150 (msg:"BACKDOOR DeepThroat 3.1 Connection attempt [3150]"; content:"00"; depth:2; classtype:misc-activity; sid:1981; rev:1;)
alert udp $HOME_NET 3150 -> $EXTERNAL_NET any (msg:"BACKDOOR DeepThroat 3.1 Server Response [3150]"; content:"Ahhhh My Mouth Is Open"; reference:arachnids,106; classtype:misc-activity; sid:1982; rev:1;)
alert udp $EXTERNAL_NET any -> $HOME_NET 4120 (msg:"BACKDOOR DeepThroat 3.1 Connection attempt [4120]"; content:"00"; depth:2; classtype:misc-activity; sid:1983; rev:1;)
alert udp $HOME_NET 4120 -> $EXTERNAL_NET any (msg:"BACKDOOR DeepThroat 3.1 Server Response [4120]"; content:"Ahhhh My Mouth Is Open"; reference:arachnids,106; classtype:misc-activity; sid:1984; rev:1;)
2. 对于攻击的特征缺乏研究,无法从原理上检测攻击,只能检测多个已知的攻击代码,而如果从原理上检测攻击可能只需要一个规则,这样看起来检测的攻击虽然种数又上去了,但攻击者只要稍稍修改一下规则就能绕过NIDS的检测而造成漏报。以Snort为例,因为Snort没有对DNS协议做解码分析无法从原理上检测攻击,检测同一种DNS TSIG和DNS iquery溢出攻击Snort分别只能使用两个检测特定攻击代码的规则。
alert tcp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"DNS EXPLOIT named tsig overflow attempt"; flow:to_server,established; content:"|AB CD 09 80 00 00 00 01 00 00 00 00 00 00 01 00 01 20 20 20 20 02 61|"; reference:cve,CVE-2001-0010; reference:bugtraq,2302; reference:arachnids,482; classtype:attempted-admin; sid:303; rev:8;)
alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"DNS EXPLOIT named tsig overflow attempt"; content:"|80 00 07 00 00 00 00 00 01 3F 00 01 02|"; classtype:attempted-admin; sid:314; rev:6; reference:cve,CVE-2001-0010; reference:bugtraq,2303;)
alert tcp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"DNS EXPLOIT named overflow (ADM)"; flow:to_server,established; content:"thisissometempspaceforthesockinaddrinyeahyeahiknowthisislamebutanywaywhocareshorizongotitworkingsoalliscool"; reference:cve,CVE-1999-0833; reference:bugtraq,788; classtype:attempted-admin; sid:259; rev:4;)
alert tcp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"DNS EXPLOIT named overflow (ADMROCKS)"; flow:to_server,established; content:"ADMROCKS"; reference:cve,CVE-1999-0833; reference:url,www.cert.org/advisories/CA-1999-14.html; reference:bugtraq,788; classtype:attempted-admin; sid:260; rev:5;)
3. 规则的描述能力弱,无法描述相对复杂些的攻击特征,只能多个规则描述同一个种攻击的多种表现形式。以Snort为例,由于规则没有能力描述或的关系,所以对于NewApt.Worm的检测只能拆成几条来写。
alert tcp any 110 -> any any (msg:"Virus - Possible NewApt.Worm - cooler3.exe"; content: "filename=\"COOLER3.EXE\""; nocase; reference:MCAFEE,10540; sid:761; classtype:misc-activity; rev:3;)
alert tcp any 110 -> any any (msg:"Virus - Possible NewApt.Worm - party.exe"; content: "filename=\"PARTY.EXE\""; nocase; reference:MCAFEE,10540; sid:762; classtype:misc-activity; rev:3;)
alert tcp any 110 -> any any (msg:"Virus - Possible NewApt.Worm - hog.exe"; content: "filename=\"HOG.EXE\""; nocase; reference:MCAFEE,10540; sid:763; classtype:misc-activity; rev:3;)
alert tcp any 110 -> any any (msg:"Virus - Possible NewApt.Worm - goal1.exe"; content: "filename=\"GOAL1.EXE\""; nocase; reference:MCAFEE,10540; sid:764; classtype:misc-activity; rev:3;)
alert tcp any 110 -> any any (msg:"Virus - Possible NewApt.Worm - pirate.exe"; content: "filename=\"PIRATE.EXE\""; nocase; reference:MCAFEE,10540; sid:765; classtype:misc-activity; rev:3;)
alert tcp any 110 -> any any (msg:"Virus - Possible NewApt.Worm - video.exe"; content: "filename=\"VIDEO.EXE\""; nocase; reference:MCAFEE,10540; sid:766; classtype:misc-activity; rev:3;)
alert tcp any 110 -> any any (msg:"Virus - Possible NewApt.Worm - baby.exe"; content: "filename=\"BABY.EXE\""; nocase; reference:MCAFEE,10540; sid:767; classtype:misc-activity; rev:3;)
alert tcp any 110 -> any any (msg:"Virus - Possible NewApt.Worm - cooler1.exe"; content: "filename=\"COOLER1.EXE\""; nocase; reference:MCAFEE,10540; sid:768; classtype:misc-activity; rev:3;)
alert tcp any 110 -> any any (msg:"Virus - Possible NewApt.Worm - boss.exe"; content: "filename=\"BOSS.EXE\""; nocase; reference:MCAFEE,10540; sid:769; classtype:misc-activity; rev:3;)
alert tcp any 110 -> any any (msg:"Virus - Possible NewApt.Worm - g-zilla.exe"; content: "filename=\"G-ZILLA.EXE\""; nocase; reference:MCAFEE,10540; sid:770; classtype:misc-activity; rev:3;)
alert tcp any 110 -> any any (msg:"Virus - Possible ToadieE-mail Trojan"; content: "filename=\"Toadie.exe\""; nocase; reference:MCAFEE,10540; sid:771; classtype:misc-activity; rev:3;)
很多国内的NIDS产品是基于Snort的引擎,因此在它们的产品中很可能反映出来,具体表现在针对同一种攻击存在许多相似的规则,比如某某攻击1、某某攻击2、某某攻击3……等等,有时候后面的序号可能达到几十,造成这种现象的原因上面已经说了,可能是引擎的关联能力不够,可能是对于漏洞的研究不深入无法从原理上检测,也有可能是规则本身的描述能力不足。对于一个有强大检测引擎的NIDS来说,对于一种攻击理论上只有一条规则与之相联,而且告警信息明确并有一定的抽象程度而不是只告之一个底层的事件。
以上的分析的一个小结是不可迷信厂商对于所能检测攻击种数的宣传,一定打开它的规则说明帮助文件,看看有多少水分。既然厂商号称的可检测攻击种数不能做为评价的依据,那我们应该怎么做?
评价一个NIDS的检测能力的高低主要可以从三方面来评价,检测的及时性、准确性、覆盖面。
1. 及时性
NIDS产品与其他安全产品不同,用户买了防火墙一般只需要设置好初始的过滤规则就可以扔在那儿了,只要网络情况没有大的改变,以后就不需再做什么管理,NIDS不同之处在于用户购买的其实不仅仅是一个产品,更重要的是花钱购买的是一种持续检测新攻击的服务。网络上每天都有新的漏洞和新的攻击方式被发现,随着黑客团体技术能力的迅速提高,从漏洞发现和补丁发布到攻击形成的时间跨度迅速缩短,从之前流行的几个蠕虫:SQL蠕虫、冲击波蠕虫、震荡波蠕虫,可以很明显的看到这种趋势,现在往往漏洞一被公布几天之内就会有相应的攻击在网上大量出现,一个最极端的例子就是攻击BlackICE防护软件ICQ解码溢出漏洞的蠕虫在漏洞被公布的第二天就在网上广泛传播,造成非常大的损失。NIDS检测新攻击的能力基本上依赖于厂商对于检测规则的更新,以当前这种网络攻击的现状和趋势,可以毫不夸张地说攻击的发生和检测是黑客与网络安全专家在时间上的赛跑,如果厂商没有能力持续而专业的研究跟踪能力,不能及时地根据最新攻击情况升级检测规则,那么无论NIDS产品在购买的时候表现是多么的好,随着时间的流逝新攻击的出现NIDS很快就会成为无用的摆设。
因此,以当前每天大量安全漏洞被发掘出来和各种网络蠕虫泛滥的现状,一个有用的NIDS产品的规则至少应该保持每周一次的常规升级和随时的针对严重攻击的紧急升级。建议用户在购买产品之间一定要到厂商的网站去看看,了解一下他们的NIDS产品规则升级的频率,几周都不更新规则的不是对用户不负责就是厂商的研究跟踪能力不行,基本上可以否定掉他们的产品,厂商还应该给出增加或更新了哪些规则,这样用户才能了解新出现了什么攻击,是不是与自己的网络环境密切相关,是不是某些从其他渠道获知的严重攻击在当前的规则升级中已经能被检测了。
2. 准确性
NIDS检测的准确性无疑是一个很重要的指标,也就是说检测应该有很低的漏报率(放过真正已发生的攻击而不告警)和误报率(把正常的网络活动认为攻击)。由于NIDS实现上的复杂性,如何评价检测的准确性是一项非常困难的工作,通常情况下厂商会提供一些第三方的报告或者做些攻击演示给用户看,文后的参考资料提供了几个文章介绍了一些方法,但到目前为止都没有比较完善的方案。用户需要明白的是实验环境与实际使用环境是非常不同的,无论是使用实际的攻击程序演示还是采用专用的NIDS测试软件,厂商都有机会也有可能出于好看的需要做一些优化,这样直接导致一个在评测环境中表现很好的产品放到实际工作环境中表现很差。
一段时间在实际网络环境中的试用是主观上评价准确性的比较好的办法,但用户很可能并没有这样的机会,那怎么办呢?如果用户是在几个待选产品中选择其一,不如打开产品的帮助文件看看厂商针对每个攻击相关漏洞说明、影响系统、解决方案等文本的详细程度,哪个做的最好就选哪个,因为攻击相关说明的详细程度可以从侧面反映厂商对于攻击本身的研究深度和做事态度,你不可能指望一个连攻击相关说明都描述不清楚的厂商有什么强大的研究能力,更不能指望他们产品的检测准确性会有多高。
3. 覆盖面
NIDS检测的覆盖面是一个NIDS不好评价的方面,因为厂商对于NIDS功能的理解是有区别的,由此对于产品的定位也是不同的,有的侧重于攻击检测,有的侧重于网络监控,用户可以根据自己的需要和应用环境选择。一般来说,选择攻击是否需要加入检测通常是根据攻击导致后果的严重程度、攻击或相应漏洞的流行程度、攻击实施的难易程度、还有自己NIDS引擎已实现的检测能力来综合考虑的,而对于漏洞或攻击的这些方面的评价则取决于厂商对于漏洞或攻击的研究深度。因此,并不是每次规则更新时新增的检测规则越多越好,负责任的厂商会根据自己对于漏洞或攻击的研究结果慎重选择新增的检测规则,因为加入实际上并无多少有效性(比如存在漏洞的软件布署非常之少)的规则不仅会增加检测引擎的负担、增加用户维护规则的精力,还会可能导致更多的误报,从而降低NIDS产品的可用性。
那么如何评价规则的覆盖面呢?同样也可以通过查看帮助文件中厂商声称可检测的攻击列表来做大致的了解。首先可以看看可检测的各种攻击都属于哪些协议,总共支持多少种应用层的协议;其次如果是在多个产品中选择的话,可以比较在相同应用层协议下检测攻击种类的数量,需要注意的是所有那些带数字序列号的攻击只能算是一种;再次,也就是最重要的一点是统计一下同一应用层协议下最近一年内新添加的检测规则占总规则数的比例,结果当然是越大越好,因为以当前整个网络的补丁安装情况,漏洞在被发现以后大多数的机器在一年之内都会打上补丁,也就是说攻击得逞的可能性已经很小,相应NIDS检测规则的重要性已经非常之低,对于NIDS来说最重要的任务是及时检测到那些可能还未有防护措施的最新攻击,而不是去检测那些很可能早已失效的只有在传说中才会提起的攻击,我们不需要徙具屠龙之技的NIDS;最后,可以比较一下各个厂商每次规则升级中新增的攻击检测类型(比如蠕虫、溢出攻击、CGI攻击),显然种类多的比种类少的好,而且一般来说按攻击的严重程度来说:蠕虫>溢出攻击>CGI攻击,因此大多数情况下严重攻击类型所占比例多的优于比例少的,当然,情况也这不是绝对的,还要结合攻击的流行程度考虑,也可以认为一个流行广泛的中危险级别攻击优先级高于流行度极小的高危险级别。
由于NIDS实现的多样性、复杂性,NIDS的评测到目前为止都还没有一个非常完善测试方案,这个文章是以一个NIDS开发者的经验对无法全面测试产品的用户做产品选型提的一些小建议,希望有用。
参考资料:
Evaluating Network Intrusion Detection Signatures
http://www.securityfocus.com/infocus/1623
http://www.securityfocus.com/infocus/1630
http://www.securityfocus.com/infocus/1651
Network Intrusion Detection Signatures
http://www.securityfocus.com/infocus/1524
http://www.securityfocus.com/infocus/1534
http://www.securityfocus.com/infocus/1544
ISS Xforce Vulnerability Database
http://xforce.iss.net/xforce/search.php
Securityfocus Vulnerability Database
http://www.securityfocus.com/bid
绿盟科技漏洞数据库
http://www.nsfocus.net/index.php?act=sec_bug
Open Source Vulnerability Database
http://www.osvdb.org/
Common Vulnerabilities and Exposures
http://www.cve.mitre.org/
ICAT Metabase:A CVE Based Vulnerability Database
http://icat.nist.gov/icat.cfm
The NSS Group
http://www.nss.co.uk/
Neohapsis OSEC
http://osec.neohapsis.com/