很多智能的IDS会把请求还原成正常的形式。

　　* 不规则方式：

　　#用tab替换空格（对IIS不适用）：智能的IDS一般在客户端的数据中取出URL请求，截去变量，然后按照HTTP的语法格式检查请求。在HTTP RFC 中，http v1.0的请求格式如下： Method URI HTTP/ Version CRLF CRLFHTTP是按照空格来把请求分成三部分的。但是，Apache 1.3.6和其以后的版本（早些时候的版本可能也是）允许用tab去请求： Method URI HTTP/ Version CRLF CRLF这会使那些根据RFC协议格式处理这个请求的程序失败。但有的IDS为了减少误报会在匹配时用上空格。如"/phf"会很容易在字符串中匹配，但 "/phf（空格）"会减少很多误报， 这时对用tab的请求就没法匹配了。

　　# NULL方式：构造如下的请求： GET%00 /cgi-bin/test.cgi HTTP/1.0，由于在C语言中很多字符串处理函数用NULL作为字符串的结尾，如果IDS是利用c函数处理字符串的话，IDS就不可匹配NULL后面的字符串了。这种方式适合IIS，Apache不能处理%00。

　　* 虚假的请求结束：对有些智能的IDS来说，为了提高效率上和减少占有系统资源，对客户端发过来的数据,一般只会处理请求部分。

　　如发送如下请求：GET /%20HTTP/1.0%0d%0aHeader:%20/../../cgi-bin/test.cgi HTTP/1.0\r\n\r\n

　　解码后是这样的：GET / HTTP/1.0\r\nHeader: /../../cgi-bin/test.cgi HTTP/1.0\r\n\r\n

　　这是一个正确的请求，但对某些智能的IDS只会截取GET的命令行，发现"HTTP/1.0\r\n"后就结束，然后对截取得部分进行操作，所以智能的IDS就不能正确报告基于此cgi的攻击。

　　* 长URL（Long URLs）：一些原始的IDS为了提高效率往往只检查前xx个字节，通常情况这样很正确，因为请求是在数据的最前面的，但是如果构造一个很长的请求： GET /rfprfprfprfp/../cgi-bin/test.cgi HTTP/1.0，超过了IDS检测的长度，这样就会使IDS检测不到后面的CGI。通常可以在请求中包涵1-2K个随机字符，但是有一些IDS会根据某些协议请求的长度来判断是否是缓冲区溢出，这时IDS就会对此类扫描误报为缓冲区溢出！

　　* 会话组合：把请求分开放在不同的包文中发出――注意不是分片，则IDS可能就不会匹配出攻击了。例如，请求"GET / HTTP/1.0"可以放在不同的包文中("GE", "T ", "/", " H", "T", "TP", "/1", ".0")，但不能逃过一些采用协议分析和会话重组技术的IDS。

　　* 大小写敏感：DOS/Windows与unix不同，它对大小写不敏感。例如：对IIS来说使用大小写是一样的，对有的老式IDS来说，可能造成不匹配。
 

针对HTTP请求进行欺骗的工具主要是Whisker，它采用了上面的一些技术进行WWW扫描，目前的IDS能发现绝大部分的欺骗方式，但对于采用URL编码（尤其是unicode编码）和不规则方式（如TAB替换空格）的扫描，有相当一部分IDS可能检测不到！

　　2.针对缓冲区溢出：一些NIDS检测远程缓冲区的主要方式是通过判断数据包的内容是否包括/bin/sh或者是否含有大量的NOP。针对IDS的这种检测办法，有的溢出程序的NOP考虑到用eb 02 代替，但这种方式目前也已经成为一些NIDS检测是否为缓冲区溢出时匹配的标志。不过，k2先生又写了一个加密shellcode的程序 ADMmutate，利用了名为多形态代码的技术，使攻击者能够潜在的改变代码结构来欺骗许多入侵检测系统，但它不会破坏最初的攻击性程序。溢出程序经它一改，就可以摇身一变，而且由于采用了动态改变的技术，每次伪装的shellcode都不相同,本来NIDS依靠提取公开的溢出程序的特征码来检测报警，特征码变了后NIDS就检测不到了。

　　伪装前的shellcode格式为：

　　[NNNNNNNNNNNNN][SSSS][RRRR]

　　伪装后的shellcode格式为：

　　[nnnnnnn][dddd][ssss][rrrr]

　　其中：

　　N表示NOP，S表示shellcode，R表示返回地址；

　　n表示经过编码的NOP，d为解码器，s表示经过编码的shellcode，r表示返回地址。

　　经过ADMmutate伪装的shellcode可以逃过使用模式匹配并且利用字符串匹配的大部分NIDS！不过如果NIDS还依靠长度，可打印字符等等综合判断，则ADMmutate还是不能逃脱NIDS的监视，但是依靠长度、可打印字符等判断未必准确，以此判断会造成IDS漏报或误报。不过，对于使用模式匹配的NIDS来说，目前仍只能通过长度等简单的判断！

　　3.针对木马：IDS检测木马和后门程序一般是通过端口来判断的，一般是通过后门程序的默认端口的连接来判断的，如Netspy的默认端口是7306， BO2k的默认端口是54320（1），所以只要后门程序不使用默认值就可以逃过一些IDS的法眼。目前大部分后门程序的通信都已采用加密的方式，所以目前的大部分NIDS只能通过非正常端口建立连接来判断，如果后门程序采用正常的端口进行通信，IDS就很有可能漏报！

　　4.其它方法：

　　缓慢扫描：一般的IDS是通过在一定时间内某个IP扫描过的端口数或IP数是否超过阀值来判断是否扫描，所以如果扫描的间隔超过IDS中指定的时间，而且采用多个IP协同扫描的话，IDS就不能判断攻击者是否扫描。

　　地址欺骗：利用代理或者伪造IP包进行攻击，隐藏攻击者的IP，使NIDS不能发现攻击者所在。目前的NIDS只能根据异常包中的地址判断攻击来源。

　　利用LLKM处理网络通信：利用LLKM简单、临时改变TCP/IP协议栈的行为，如更改出现在网络传输线路上的TCP标志位，躲避一些IDS的监视。

　　复杂的TCP/IP包处理：利用IDS不能正确模拟所有的TCP/IP栈的可能行为，对TCP/IP数据包进行特殊的处理以避过IDS。如将TCP/IP 包分成很小的碎片，或者是打乱包的发送顺序，或者是发送重叠的包，或者是包含有不正确校验和、不正确序列号等，正常的TCP/IP软件可以正确重组和处理包，而有相当多的NIDS不能正确处理这些包，所以会忽略基于这种特殊包的攻击。测试NIDS关于TCP/IP包的处理能力，可以使用 fragrouter 或者 Cybercop Scanner。

　　结论：

　　由于目前的NIDS绝大部分是采用sniffer形式抓包，以模式匹配的方式检测和分析入侵，不能处理和分析加密或伪装后的数据包，特别是在网络负载流量高的情况下，许多NIDS会出现丢包现象，所以NIDS仍然存在误报、漏报的可能。黑客如果将上面的一些方法巧妙的结合起来，仍可以逃避目前一些 NIDS的监视。