一谈到NIDS，这个产品最为人所诟病的往往就是大量的误报和漏报，满屏乱滚的误报使管理员麻木和厌烦，失去使用的兴趣，漏报则会使管理员怀疑NIDS的检测能力，明明主机已经被入侵了在NIDS的日志中却找不到有用的线索。对于NIDS产品，漏报和误报产生的原因是多方面，但其中最大的来源在于检测规则定义的不严谨。
针对已知的网络攻击，当前主流网络入侵检测检测及防护系统主要还是基于规则的，这是因为特定的攻击，特别是基于特定攻击代码的报文比较容易抽取其报文特征进行匹配，使用规则可以快速方便地实现检测能力的扩展。
网络攻击的本质就是利用目标系统设计或实现上的问题，从被攻击进程的角度看，攻击报文或在内容结构上，或在出现的时序上，或在流量的大小上，攻击报文一定是处于服务程序无法正确处理的畸形状态。限于篇幅，本文暂不讨论比较复杂的与时序及统计相关的攻击，只考虑相对比较简单的单请求攻击，要使攻击得以成功完成，网络攻击的报文的内容和结构必须满足某些必要的条件，这些必要的报文特征用于驱使受攻击进程的处理流程走到触发漏洞的操作，我们用特征集A表示这些必要的报文特征的集合。
攻击者通过编写攻击代码来实现对安全漏洞的利用，特定的攻击代码发出的报文除了必定包含的特征集A内的特征外一般还会包含一些本攻击代码特有的特征，比如特定的shellcode、特定的填充数据等，我们用特征集B表示特定攻击代码的报文特征。
基于规则的NIDS引擎实现一个基本检测框架，它提供给用户各种匹配选项和操作符作为应用接口，用户可以通过组合选项和操作符来描述关心的网络报文特征，对满足匹配条件的报文进行告警。NIDS厂商的规则支持部门通常会跟踪分析新出现的安全漏洞及攻击代码，提取特征编写出用于检测此攻击的NIDS规则，我们用特征集C表示用规则描述的攻击报文特征。
很明显特征集A和B的关系如下图：
+----------------+
| |
| +-------+ |
| | |<---- 特征集A：要实现攻击，报文所必须具有的内容或结构方面的特征
| | ============> 匹配特征增加，满足条件的报文减少
| | | |
| +-------+ |
| |<---- 特征集B：特定攻击代码发出的攻击报文特征
+----------------+
理想的攻击检测规则描述的特征集C应该与A完全重合，由于特征集A内的特征描述了所有攻击代码攻击报文所共有的特征，因而与特定的攻击代码无关，这样就避免了漏报。如果对于检测对象的协议类型所做假设正确，由于特征集A内的每个特征是造成攻击所必要的，缺一不可，这些特征中的只要有一个不满足都无法触发漏洞而完成攻击，所以也不存在误报的可能。图示如下：
+----------------+
| |
| +=======+ |
| " "<---- 特征集A：要实现攻击，报文所必须具有的内容
| " " | 或结构方面的特征
| " "<---- 特征集C：规则所描述的报文内容或结构的特征
| +=======+ |
| |<---- 特征集B：特定攻击代码发出的攻击报文特征
+----------------+
事实上由于规则描述能力的限制，大多数情况下规则无法完全描述出攻击报文内容和结构上的完成攻击所必需的特征，也就是说，特征集A与特征集C并不是完全重叠的，而是存在各种可能的关系：
如果特征集C是如下图中这样作为A的子集，那么规则将可能导致误报，但不会产生漏报：
+----------------+
| |
| +-------+ |
| | +---+ |<---- 特征集A：要实现攻击，报文所必须具有的内容或结构方面的特征
| | | |<------ 特征集C：规则所描述的报文内容或结构的特征
| | +---+ | |
| +-------+ |
| |<---- 特征集B：特定攻击代码发出的攻击报文特征
+----------------+
如果特征集C是如下图中这样包含了特征集A，那么规则将可能导致漏报，但不会产生误报：
+----------------+
| |
| +-------+ |
| | +---+ |<---- 特征集C：规则所描述的报文内容或结构的特征
| | | |<------ 特征集A：要实现攻击，报文所必须具有的内容或结构方面的特征
| | +---+ | |
| +-------+ |
| |<---- 特征集B：特定攻击代码发出的攻击报文特征
+----------------+
如果特征集C与A互不包含，只是如下图存在一个交集，那么规则将既可能产生误报也有可能导致漏报：
+----------------+
| |
| +-------+ |
| | |<---- 特征集C：规则所描述的报文内容或结构的特征
| | +---+--+ |
| | | | |<------ 特征集A：要实现攻击，报文所必须具有的内容或结构方面的特征
| +---+---+ | |
| | | |
| +------+ |<---- 特征集B：特定攻击代码发出的攻击报文特征
+----------------+
如果特征集C与A互不包含且没有交集，那么规则本身只是在检测特定的攻击代码发出的报文，而与攻击本身无关，通过简单修改攻击代码可以非常轻易地绕过这类规则的检测，要NIDS发生漏报还是误报完成掌握在攻击者手中：
+----------------+
| +-------+ |
| | | |
| | |<------- 特征集C：规则所描述的报文内容或结构的特征
| +-------+ |
| +------+ |
| | |<------ 特征集A：要实现攻击，报文所必须具有的内容或结构方面的特征
| | | |
| +------+ |<---- 特征集B：特定攻击代码发出的攻击报文特征
+----------------+
那么如何才能使特征集C与A尽可能地重合？这主要取决于两方面的努力：一、透彻地分析漏洞的成因和利用条件，目的是归纳出准确的特征集A；二、提高NIDS规则的描述能力，使之描述出的特征集C可以尽可能地接近特征集A。NIDS厂商的实力往往体现在这两方面的水准上，如果厂商没有持续而专业的漏洞及攻击的分析能力，在没有分析清楚漏洞细节的情况下胡乱设计NIDS规则必然会带来大量的漏报和误报，NIDS产品使用效果可想而知。下面通过分析一个实际漏洞攻击的NIDS规则设计来使上述看起来有些抽象的描述具体化，突显漏洞分析在设计NIDS规则过程中的极端重要性。
Serv-U是一个Windows平台下的FTP服务器软件，去年研究人员发现Serv-U服务器进程在处理MDTM命令的参数时存在一个栈溢出漏洞，远程攻击者只要能够登录进FTP服务器无需目录的写权限就可发动溢出攻击，在FTP服务器上执行任意指令从而实现对服务器的控制。由于Serv-U的使用非常广泛，几乎是Windows平台下首选的FTP服务程序，而且一般FTP服务器上保存有大量有价值的资料，所以对此漏洞的利用攻击非常流行。
如何检测针对此漏洞的攻击，开源的NIDS工具Snort给出了如下的检测规则：
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP invalid MDTM command attempt"; flow:to_server,established; content:"MDTM"; nocase; pcre:"/^MDTM \d+[-+]\D/smi"; reference:bugtraq,9751; reference:cve,2001-1021; reference:cve,2004-0330; classtype:attempted-admin; sid:2416; rev:5;)
此规则描述的报文特征：
1. 目标端口为21的TCP包
2. 包含MDTM命令
3. 参数以一个或多个数字开头
4. 数字字串后紧跟“+”或“-”字符
5. “+”或“-”字符后紧跟至少一个非数字字符
这些特征形成特征集C。
这个特征集C是否与真正的攻击特征有足够的切合度呢？通过漏洞分析我们自然会得到结论。czy82在NSFOCUS技术论坛上发表过对此漏洞的详细分析，原文见：http://bbs.nsfocus.net/index.php?act=SE&f=3&t=159298&p=299648
择其分析文章中对服务器处理命令及参数的代码分析片断如下：
====================================================================
[0]判断是否是"MDTM"命令
loc_434748: ; CODE XREF: .text:0043473A
.text:00434748 push 4 //比较四个字
.text:0043474A push edi //edi存放命令字串的首地址
.text:0043474B lea eax, [esi+354h]
.text:00434751 push eax // 得到命令列表
.text:00434752 call near ptr unk_59C008 // 相当于Strncmp
.text:00434757 add esp, 0Ch
.text:0043475A test eax, eax
.text:0043475C jnz short loc_43476D //不是MDTM的话比较下一个命令SITE
.text:0043475E push edi //第二个参数是命令字串的首地址
.text:0043475F push ebx
.text:00434760 call loc_41FAE8 //相同的话跳到MDTM命令处理函数
.text:00434765 add esp, 8
.text:00434768 jmp loc_434AC7
[2] 对时间区域进行处理检测
.text:0041FBB6 loc_41FBB6: ; CODE XREF: sub_41FAE8+9Bj
.text:0041FBB6 push 20h
.text:0041FBB8 lea edx, [ebp+var_9FC] //ebp-9fc中存放全部命令
.text:0041FBBE push edx
.text:0041FBBF call sub_59BEB1 //找命令中的空格找到后把空格后
//的地址放在ebp-78中，也就是找文件名
.text:0041FBC4 add esp, 8
.text:0041FBC7 mov [ebp+var_78], eax
.text:0041FBCA test eax, eax
.text:0041FBCC jz loc_41FE6D //没有找到文件名跳，跳过去将处理
//mdtm autoexec.bat这类看文件时间的命令
.text:0041FBD2 lea edx, [ebp+var_9FC]
.text:0041FBD8 push edx
.text:0041FBD9 call sub_59BDA4 //得到命令长度
.text:0041FBDE pop ecx
.text:0041FBDF cmp eax, 10h //命令长度小于16跳
.text:0041FBE2 jb loc_41FE6D
.text:0041FBE8 lea ecx, [ebp+var_9FC]
.text:0041FBEE mov eax, [ebp+var_78]
.text:0041FBF1 sub eax, ecx //得时间区域长度不要紧张这儿没洞洞
.text:0041FBF3 cmp eax, 0Eh
.text:0041FBF6 jl loc_41FE6D //必须是大于等于14字节
.text:0041FBFC mov [ebp+var_88], 1
.text:0041FC06 xor edi, edi
.text:0041FC08 lea esi, [ebp+var_9FC]
.text:0041FC0E
.text:0041FC0E loc_41FC0E: ; CODE XREF: sub_41FAE8+141j
.text:0041FC0E movsx eax, byte ptr [esi]
.text:0041FC11 push eax
.text:0041FC12 call sub_5A1304
.text:0041FC17 pop ecx
.text:0041FC18 test eax, eax
.text:0041FC1A jnz short loc_41FC24
.text:0041FC1C xor edx, edx
.text:0041FC1E mov [ebp+var_88], edx
.text:0041FC24
.text:0041FC24 loc_41FC24: ; CODE XREF: sub_41FAE8+132j
.text:0041FC24 inc edi
.text:0041FC25 inc esi
.text:0041FC26 cmp edi, 0Eh
.text:0041FC29 jl short loc_41FC0E
.text:0041FC2B cmp [ebp+var_88], 0
.text:0041FC32 jz loc_41FD99 //判断时间区域的前14个字
