攻击入侵检测NIDS是怎样的？
首先考虑到的是如何对付IDS，攻击主要采用,一我们如何攻击IDS,二,是我们如何绕过IDS的监视。本文将详细介绍当前的主要NIDS分析。
一。介绍攻击系统NIDS
攻击系统的NIDS主要有两种方式:直接攻击和间接攻击,我们来看:
1。 如何直接攻击NIDS
直接对NIDS进行攻击。因为NIDS是安装在一定的操作系统之上，而且本身也是一个 复杂的TCP/IP操作系统，这意味着NIDS本身可能受到smurf、synflood或jolt2等攻击。 如果安装IDS的操作系统本身存在漏洞或IDS自身防御力差，此类攻击很有可能造成IDS的探测器丢包、失效或不能正常工作。但是随着IDS技术的发展，一...全部
首先考虑到的是如何对付IDS，攻击主要采用,一我们如何攻击IDS,二,是我们如何绕过IDS的监视。本文将详细介绍当前的主要NIDS分析。
一。介绍攻击系统NIDS
攻击系统的NIDS主要有两种方式:直接攻击和间接攻击,我们来看:
1。
如何直接攻击NIDS
直接对NIDS进行攻击。因为NIDS是安装在一定的操作系统之上，而且本身也是一个 复杂的TCP/IP操作系统，这意味着NIDS本身可能受到smurf、synflood或jolt2等攻击。
如果安装IDS的操作系统本身存在漏洞或IDS自身防御力差，此类攻击很有可能造成IDS的探测器丢包、失效或不能正常工作。但是随着IDS技术的发展，一些NIDS采用了双网卡的技术，一个网卡绑定IP，用来与console（控制台）通信，另外一个网卡无IP，用来收集网络数据包，其中连在网络中的是无IP的网卡，因为没有IP，所以不能直接攻击，而且新的IDS一般采用了协议分析的技术，提高了IDS捕捉和处理数据包的性能，所以直接攻击NIDS这种方法已经行不通了。
2。如何间接攻击NIDS
一般的NIDS都有入侵响应的功能，如记录日志，发送告警信息给console、发送警告邮件，防火墙互动等，我们可以利用IDS的响应进行间接攻击，使入侵日志迅速增加，塞满硬盘；发送大量的警告信息，使管理员无法发现真正的攻击者，并占用大量的cpu资源；发送大量的告警邮件，占满告警信箱或硬盘，并占用接收警告邮件服务器的系统资源；发送虚假的警告信息，使防火墙错误配置，造成一些正常的IP无法访问等！
在目前来看，攻击NIDS最有效的办法是利用Coretez Giovanni写的Stick程序，Stick使用了很巧妙的办法，它可以在2秒内模拟450次攻击，快速的告警信息的产生会让IDS反应不过来、产生失去反应甚至死机现象。
由于Stick发出多个有攻击特征（按照snort的规则组包）的数据包，所以IDS匹配了这些数据包的信息时，就会频繁发出警告，造成管理者无法分辨哪些警告是针对真正的攻击发出的，从而使IDS失去作用。
当有攻击表现的信息包数量超过IDS的处理能力的话，IDS会陷入拒绝服务状态。Stick对许多IDS有影响，ISS公司的产品也不例外，该公司的产品中曾有"RealSecure Network Sensor 5。
0"的Windows NT/2000版受到了影响，后来ISS发布了补丁，好像已经解决了这个问题。但其它一些公司的IDS，如snort，因为Stick发送的是按snort规则组成的包，所以用Stick攻击装有snort的网络时，会产生大量的日志记录。
二。介绍绕过IDS的监视
当黑客在攻击时可以伪装自己，饶过IDS的检测，主要是针对IDS模式匹配所采用的方法来逃避IDS的监视。我们来详细看一下:
1。针对HTTP请求以绕过IDS监视
㈠URL编码问题,将URL进行编码，可以避开一些采用规则匹配的NIDS。
二进制编码中HTTP协议允许在URL中使用任意ASCII字符，把二进制字符表示成形如"%xx" 的十六进制码，有的IDS并不会去解码。 如"cgi-bin"可以表示成"%63%67%69%2d%62%69%6e"，有些IDS的规则匹配不出，但web服务器可以正确处理。
不过现在大多数IDS已经是在匹配规则之前解码，目前这个手段已经不适用了，一般的IDS都可以检测到的！# %u编码，是用来代表Unicode/wide特征字符，但微软IIS web服务器支持这种非标准的web请求编码方式由于%u编码不是标准的编码，IDS系统不能解码%u，所以可以绕过IDS的检测。
例如:
我们使用下列的编码方式就可以绕过一些NIDS对"。ida"的攻击的检测。
GET /abc。id%u0061 HTTP/1。0
不过，snort1。8可以检测到这种编码后的攻击，但有一些公司的IDS没注意到这个问题。
解决办法主要就是在规则匹配前对URL内容的%u编码进行解码后匹配。 #unicode编码，主要针对IIS，将URL中的一些特定的字符或字符串（主要是针对一些IDS匹配的规则内容）用unicode编码表示，例如：
我们使用下列的编码方式就可以绕过一些NIDS对"。
ida"的攻击的检测。
GET /abc。id%c1%01 HTTP/1。0
snort1。8目前好象不能检测到这种编码后的攻击。采用通配符如"*string*"匹配的很多IDS应该都存在此类问题。
解决办法就是在规则匹配前对URL内容的unicode编码进行解码后匹配。
㈡网络中斜线问题即"/"和"\"。# "/" 问题：如果在HTTP的提交的请求中把'/' 转换成 '//'，如"/cgi-bin/test。
cgi"转换成"//cgi-bin//test。cgi"，虽然两个字符串不匹配，但对许多web服务器的解释是一样的。如果把双斜线换成三斜线或更多效果也是一样的。目前有些IDS无法检测到这种类型的请求。
# "\"问题：Microsoft用'\'来分隔目录，Unix用'/'来分隔，而HTTP RFC规定用'/'， Microsoft的web服务器如IIS 会主动把'/' 转换成 '\'。例如发送"/cgi-bin\test。
cgi"之类的命令，IIS可以正确识别，但这样IDS就不会匹配"/cgi-bin/test。cgi"了，此法可以逃避一些IDS。
㈢增加目录问题：插入一些无用的特殊字符，使其与IDS的检测内容不匹配。
如'。。'意思是父目录，'。'意思是子目录，window下的"c:\tmp\。\。\。\。\"的意思就是"c:\tmp\"；相应的unix下的"/tmp/。/。/。/。/"和"/tmp/"等价。
对"/cgi-bin/phf"可以任意变化成"/。/cgi-bin/。/。/phf等形式。 例如：
GET /cgi-bin/blahblah/。。/test。cgi HTTP/1。0实际和"/cgi-bin/test。
cgi"一样
目前一般IDS都能识别。 很多智能的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提交的，如GET /cgi-bin/test。cgi。但是相同的请求用HEAD命令也能实现，如用HEAD发送：HEAD /cgi-bin/test。
cgi，则有些依靠get方法匹配的IDS系统就不会检测到这个扫描。
㈥会话组合问题：把请求分开放在不同的包文中发出――注意不是分片，则IDS可能就不会匹配出攻击了。例如，请求"GET / HTTP/1。
0"可以放在不同的包文中("GE", "T ", "/", " H", "T", "TP", "/1", "。0")，但不能逃过一些采用协议分析和会话重组技术的IDS。
㈦长URL（Long URLs）问题：一些原始的IDS为了提高效率往往只检查前xx个字节，通常情况这样很正确，因为请求是在数据的最前面的，但是如果构造一个很长的请求：
GET /rfprfprfprfp/。
。/cgi-bin/test。cgi HTTP/1。0，
超过了IDS检测的长度，这样就会使IDS检测不到后面的CGI。通常可以在请求中包涵1-2K个随机字符，但是有一些IDS会根据某些协议请求的长度来判断是否是缓冲区溢出，这时IDS就会对此类扫描误报为缓冲区溢出！
㈧虚假的请求结束问题：对有些智能的IDS来说，为了提高效率上和减少占有系统资源，对客户端发过来的数据,一般只会处理请求部分。
例如发送如下请求：
GET /%20HTTP/1。0%0d%0aHeader:%20/。。/。。/cgi-bin/test。cgi HTT
P/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的攻击。
㈨大小写敏感问题：DOS/Windows与unix不同，它对大小写不敏感。例如：对IIS来说使用大小写是一样的，对有的老式IDS来说，可能造成不匹配。
收起
