我们需要什么样的入侵检测系统
入侵检测系统在国内已经出现一段时间了，作为大多数技术人员来说，介绍ids的资料还是很少，面对众多公司的产品不知如何选择。本文从使用的角度介绍选择ids的几个关键点，大家可以对这几个角度看ids的产品。这些地方做的好的产品会很实用。当然这不是一个产品好坏的
全部。好的产品还会带很多附属功能让用户好用。但是如果基本的功能做的不好的话，这个产品应该不是入侵检测系统，不在我们讨论范围之内。本文局限在讨论网络入侵检测系统。以下描述中用ids代替。
一、检测入侵
二、远程管理
三、抗欺骗能力
四、自身安全性
一、检测入侵
ids最主要的功能当然是检测入侵。如何智能的报告出入侵者的动作就成了检验ids功能的首要条件。用户安装上ids后缺省情况下，ids就应该对经典的对各个服务的攻击作出告警。比如一些远程溢出攻击，那些都是成功后就完全控制机器的攻击。对一个ids产品可以先试试这个，如果ids产品没有反应，那么附加功能再多，我们也不能说这是一个有用的ids。
二、远程管理
网络ids的机制是监视网络上的流量，这样决定了如果所要监视的网络不止一个hub或交换机的话就要在每个hub或交换机上面安装网络引擎。这样我们就需要一个控制台和日志分析程序来管理和分析多个网络引擎及它们产生的告警。坐在办公室中实时查看和管理机房里的入侵检测系统，用户有权要求这样的功能。不过要注意把这个功能和ids的另一个功能区分开，ids还会提供各种各样的告警方式，打电话呀，发邮件呀什么的，这样用户也可以远程得到告警。不过这个交流是单向的，用户只能被动的得到信息，而不能主动的控制远程的网络引擎。
三、抗欺骗能力
ids要抓住入侵者，入侵者就会想方设法逃避ids。逃避ids的方法很多。总结起来可以分成两大类：让ids漏报和让ids误报。
1、ids误报：
ids误报的初衷是明明没有这个攻击，但是入侵者让ids拼命告警，让不断增长告警日志塞满硬盘，让翻滚的告警屏幕把管理者的眼睛绕花。这样真正的攻击就可以夹杂在数不清的虚假告警中蒙混过关了。因为这个时候已经没有精力从众多的告警中发现真正的入侵了。
今年三月,Coretez Giovanni发现了让ids误报的另外一个功能：快速的告警信息的产生会让ids反应不过来产生失去反应甚至死机现象。Coretez写了个叫做stick的程序。本来是就是作为ids产品的测试用例的。这个程序读入snort(www.snort.org)的规则,然后按照snort的规则组包，因为snort的规则函盖了大多数的攻击，所以ids匹配了这些报文就告警。比较有名的ids如iss和snort首当其冲被披露能造成30秒以上的停顿。然后iss就发布了补丁。这条安全新闻也被不止一家网站译成中文。新浪的相关连接是：http://tech.sina.com.cn/s/n/58376.shtml不过iss的补丁打的好像不怎么样，补丁出来后，在www.securityfocus.com的focus-ids邮件
列表里有对Coretez iss补丁测试后的印象：
ISS released an update to handle the alarm flooding from stick. I took a quick look at the ISS update. It generated alarms for most of the packets,but
1) ISS Sensor/Console relationship maintained its integrity
2) The alarms caused by stick were clustered into four alarms, mostly UDP Bomb and PNG. Though smurf and stacheldraht also were alarming at a lower rate.I tool targeted to go against ISS would generate more, but I have little interest in reverse engineering the ISS rule set. Glad to see the quick response by ISS.
Tezstick在securityfocus的主页(www.securityfocus.com)上可以下载：
http://www.securityfocus.com/frames/?content=/templates/tools.html%3Fid%3D1974编译起来不麻烦，注意看帮助即可。只是此人写此类发包程序的风格有点与众不同，看程序时记着并不是作者有什么高深的东西，表达方式不同而已。绝大多数的ids都从snort多有借鉴，都可以用stick试一下。
2、ids漏报
和ids误报相比，漏报其实更有危险性。要ids干什么呀，还不是有入侵就产生告警。如果入侵者入侵成功而让ids不告警，则ids就是摆设了。phrack magamine的54－10文章：《Defeating Sniffers and Intrusion Detection Systems》对利用tcp连接的特点让ids做漏报进行了详细的描述。并且给出了一些实现。这实际上给我们提供了一种思路。就是ids想要防止欺骗，就要尽可能的模仿tcp/ip栈的实现。但是从效率和实现的复杂性考虑，ids是不能做到完全模仿的，所以我们只有思考tcp/ip的实现什么难做，那ids估计就没有实现。我们就可以通过这个告诉ids这不是一个连接，但是对服务器来说，是一个连接，正常处理。这样攻击就可以逃脱ids的监视了。
这种方法适合那些智能的ids，好的ids一般为了减少误报，会象现在一些高端的防火墙一样基于状态进行判断，而不是根据单个的报文。这样上面的stick实际上对这种ids就不起作用了。对基于单个报文的ids来说，反而不会受到phrack magamine的54－10文章所描述方法的影响。但是考虑一下这种简单的ids只是字符串匹配，匹配上就报警。攻击者可以控制自己所发送的字符串，让能够报警的字符分在两个数据包中发送。因为tcp的连接是流格式的，所以数据在几个报文中发送对连接来说是没有影响的。但是ids可是被欺骗过了。
今年四月，又出了一个让ids漏报的程序ADMmutate，据说是可以动态改变shellcode，溢出程序经它一改，就可以摇身一变，本来ids依靠提取公开的溢出程序的特征码来报警。特征码变了后ids就报不出来了。但是程序还一样起作用，服务器一样被黑。这个程序的作者是k2(www.ktwo.ca)他的主页上有下载：
http://www.ktwo.ca/c/ADMmutate-0.7.3.tar.gz这个程序只能对依靠检查字符串匹配告警的ids起作用，如果ids还依靠长度呀，可打印字符呀等等综合判断，则ADMmutate还是不能逃脱ids的监控。这里有k2在在www.securityfocus.com
的focus-ids邮件列表中对目前ids检测shellcode的手段的一些看法：
Just to straighten some things out. I have tested ISS RealSecure 5,fully updated, it can detect suspicious packets with respect to protocols that it understands (FTP/POP/IMAP) as overly long commands (eg. USER AAAA[1024]). However for many other protocols that this luxury is not present (HTTP/RPC/DNS), RealSecure can definitely NOT
detect polymorphic shellcode. I have put it through some testing and have found that it most definitely is vulnerable to these techniques.
This feature of detecting suspicious packets is also implemented in Dragon off the shelf, and I believe on the road map for snort. However, for protocols where a simple length calculation cannot be used to determine the hostile intent of some data, detection is not currently possible
ids的实现总是在漏报和误报中徘徊，漏报率降低了，误报率就会提高，同样误报率降低了，漏报率就会提高。产品一般会在两者中取一个折中，并且要能进行调整以适应不同的网络环境。
四、自身安全性
毫无疑问，ids程序本身的健壮性是ids系统好坏的重要指标。象上面所说stick的程序能让ids停止响应，这个ids的健壮性就值得怀疑。
ids的健壮性体现在两个方面：一是程序本身在各种网络环境下都能正常工作。二是程序各个模块之间的通信能够不被破坏，不可仿冒。ids因为是各个模块间远程通信和控制的，如果通信被假冒，比如假冒一个停止远程探测器的命令或者假冒告警信息都是釜底抽薪的狠招。这就需要在模块间的通信过程中引入加密和认证的机制。并且这个加密和认证的机制的健壮性也要受到考验。如果模块间的通信被切断，则需要良好的恢复重传机制。告警信息暂时没有发送出去并不是丢弃，而要本地保存，适当的时候再发送。
