一.介紹攻擊系統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-bintest.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
㈤命令問題：許多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 /rfprfp
超過了IDS檢測的長度，這樣就會使IDS檢測不到后面的CGI。通常可以在請求中包涵1-2K個隨機字符，但是有一些IDS會根據某些協議請求的長度來判斷是否是緩沖區溢出，這時IDS就會對此類掃描誤報為緩沖區溢出！
㈧虛假的請求結束問題：對有些智能的IDS來說，為了提高效率上和減少占有系統資源，對客戶端發過來的數據,一般只會處理請求部分。例如發送如下請求：
GET /%20HTTP/1.0%0d%0aHeader:%20/../../cgi-bin/test.cgi HTT
P/1.0rnrn
解碼后是這樣的：
GET / HTTP/1.0rnHeader: /../../cgi-bin/test.cgi HTTP/1.0rnrn
這是一個正確的請求，但對某些智能的IDS只會截取GET的命令行，發現"HTTP/1.0rn"后就結束，然后對截取得部分進行操作，所以智能的IDS就不能正確報告基于此cgi的攻擊。
㈨大小寫敏感問題：DOS/Windows與unix不同，它對大小寫不敏感。例如：對IIS來說使用大小寫是一樣的，對有的老式IDS來說，可能造成不匹配。
針對HTTP請求進行欺騙的工具主要是Whisker，它采用了上面的一些技術進行WWW掃描，目前的IDS能發現絕大部分的欺騙方式，但對于采用URL編碼（尤其是unicode編碼）和不規則方式（如TAB替換空格）的掃描，有相當一部分IDS可能檢測不到！
2.我們來看看針對緩沖區溢出以繞過NIDS
一些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表示返回地址
