首先考慮到的是如何對付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編碼表示，例如：
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來說，可能造成不匹配。
首先考慮到的是如何對付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來說，可能造成不匹配。