理解IDS的主動響應機制

　                                             理解IDS的主動響應機制
    在開發者的團體內，關于“什么是檢測***的最有效的方法？”的問題的爭論還在激烈的進行著，不過IDS的用戶對目前的IDS技術還是感到滿意的，為了獲得更有優勢的競爭，很多的IDS產品提供商，都在其產品中加入了主動響應的功能。這個功能的概念就是說IDS將檢測***者的***行為，并組織***者繼續進行***。不過，問題是稍有一點TCP/IP知識的***者都可以輕易的直接擊敗這些響應機制；或者利用這些機制實現阻斷網絡的功能，管理員將不得不關閉這些功能。對于管理員來說，明白主動響應的局限性將有助于管理員盲目的相信那些產品提供商。絕大多數響應機制是以下兩種形式中的一種：
1.阻止會話
2.防火墻聯動

一、“阻止會話”機制簡介：
阻止會話到目前為止，是最IDS供應商最常用的方式。這種方式之所以流行，是因為它不需要外部設備的支持（如防火墻），而且它易于實現。這一機制非常簡單，下面我們將逐步剖析這種機制，并揭示如何繞過它，我希望我的評價不會引起廠商們的反感。
下面我們以IIS的Unicode橫向目錄遍歷***為例子，來講解這一機制的工作方式。***者發出如下的請求，這個請求共51個字節，將這51個字節變成分段的破碎IP包，每個包長為20個字節，如下所示：

Data: /scripts/..%c0%af../winnt/systme32/cmd.exe/c+dir+foo
+----+----++
Offset: 0 20 40 51
Sec Num: 100 120 140 151

本文中提到的IDS是具有如下功能的產品：
1.有關于“system32/cmd.exe”這個***特征信號
2.能夠重組所有的破碎包和流信息
3.能夠進行unicode、hexcode（16進制編碼）、escape和base64的解碼
如果***者僅僅是簡單的重復這樣的行為，而不做任何變化的化，IDS將捕獲到這樣的***行為，并生成一個報警信息。一般說來，操作系統在處理時，會對以上所示的IP包在IP堆棧生成一個隨機的ISN值，然后將數據用三個數據包發出。（當然，我們都知道簡單的通過瀏覽器是無法實現這個情況的，這里只是一個例子而已）
有些系統的IP堆棧在每發出一個數據包以后，會等待一會兒以便收到來自接受方的確認信息，確認收到發出的那個數據包。而有的系統的IP堆棧會一次發出所有的三個包，然后在重發那些接受方沒有確認收到的數據包。盡管不同的操作系統在一個會話建立以后（Established狀態）處理IP堆棧的方式不一樣，不過這里的關鍵是說明了堆?？隙梢酝瑫r處理一定數量的數據包。在本例中，我們的IDS將會在收到第三個包的時候報警，因為它已經收到了第1個和第2個數據包，此時它已經可以重組整個會話，并匹配出合適的信號了。這時候，如果IDS具有會話阻斷的功能，那么IDS將會向通信的兩端各發送一個TCP RESET包，從而實現主動切斷連接的目的，此時通信雙方的堆棧將會把這個RESET包解釋為另一端的回應，然后停止整個通信過程，釋放緩沖區并撤銷所有TCP狀態信息。這個時候，***數據包可能還在目標主機操作系統TCP/IP堆棧緩沖區中，沒有被提交給應用程序，由于緩沖區被清空了，所以***不會發生。
對于RESET包來說，IDS發出的RESET包的前提是知道整個會話當前的序列號和確認號，否則這個RESET包將會被忽略。本例中確認號必須為152（比最后的一個序列號大1）如果你發送的RESET包的確認號為142，那么堆棧將會認為這是一個無效的數據包或者被破壞的數據包而將它忽略掉。（嗯，好像問題開始變得明朗了）

二、繞過“會話阻止”
會話阻止的機制可以被***者所繞過，繞過這一機制的很多方法都是依靠時間選擇方式。
如果***不需要一個交互式的會話過程，則***者可以通過簡單設置TCP/IP數據包的PUSH堆棧來實現時間選擇。TCP/IP堆棧一般不會立即將收到的大塊數據送給應用程序處理。絕大多數時候，這樣將造成應用程序花費比較高的系統中斷調用和內容交換的代價來提高對小數據包的處理能力，堆棧將所有數據放在一個緩沖區中，當緩沖區滿了以后，堆棧才將堆棧中所有的數據一次性提交給應用層的程序。在上面的例子中，所有的51字節的數據全部收到以后才會被一次性提交給應用層。
某些應用程序希望盡可能快的獲得數據，因此這些程序將會付出額外的開銷以便盡可能獲得較高的處理速度。PUSH標志的設置實際上是通知TCP/IP堆棧收到數據以后，立即提交給應用層。但是如果你需要獲得一個目錄列表，就不能采用這種設置PUSH標志位的方式，因為當數據被傳遞給應用程序以后，這個會話就立即終止了。你無法得到一個交互式的過程，不過若你只是想copy一個文件到web服務器路徑下面，以便通過瀏覽器下載這個文件的話，你就可以采用這種方法，因為整個過程無需任何交互，你就可以完成你的操作。（比如復制SAM文件到Web路徑下）。
如果你需要一個會話能夠保持，以便你獲得一個交互式的過程，本文將介紹一組技術來實現這一目標，這里的竅門就是讓目標主機忽略RESET數據包。此時讓IDS以為它已經終止了會話，實際上***者依然工作得很好。
首先的有利條件是所有的IDS在響應***時都有延遲時間，因為IDS從抓取數據包，監測***，產生RESET包，到最后發出RESET整個過程都要消耗一定的時間。很多的IDS使用libpcap庫來抓包，大部分IDS構建在類BSD的系統上，BSD系統下是利用BPF（Berkeley Packet Filters）進行抓包，BPF默認將會開一個很大的緩沖區，在一個典型的網絡中，IDS發出RESET包的過程大約會延遲半秒。在Linux和Solaris平臺上，性能要稍微好一點，但是肯定也有延遲時間。
要使得IDS發送的RESET失效，我們必須能夠保證一個會話中出現***特征以后，其后續的包比RESET包先到達目的主機。下面我們將通過TCP工作機制來簡要介紹如何實現讓目標主機忽略IDS的RESET數據包。
在TCP中，大家都知道有一個Window窗的概念。系統接受到的數據中，有的已經被提交給應用程序，有的則存儲在緩沖區中，等待被提交給應用程序，同時系統中還留有一個空的空間以便接受新到達的數據。如下所示：

+---+--- ---+-+
　 已交給應用的數據 　 未處理的數據 　 空 區 　
+---+--+-+
^

當前指針(CP)

　<----窗體---->　

所有在緩沖區中的數據和空區就構成了TCP中的窗，只有在窗體中的數據才可執行send或者receive或者reset操作，在窗體之前的數據（也就是上面說得已經提交給應用層的數據）是被處理過的數據，窗體之后的數據將被忽略。如上圖所示，TCP堆棧同時還用一個當前指針CP來定位目前的空區的起始位置。CP指針指向下一個要收到的數據包的起始位置，其值等于確認值。比如當前的堆棧獲得了76字節的數據，則確認值為77。如果下一個數據包到達，則CP指針將會移動到下一個數據包的結束位置＋1的地方。
由于TCP中不一定所有的數據包都要按照順序到達，因此，有可能后面的數據包比前面的數據包先到，比如從90字節開始的數據包可能比從77字節開始的數據包先到。所有到達的數據包都會進入緩沖區，不過CP指針將停留在77的位置直到從77字節開始的數據包到達，當從77字節開始的數據包到達以后，CP指針此時將會一次性的移動到所收的數據包末尾，如下圖所示：
+---+--+ +--+---+
　 已交給應用的數據 　 未處理的數據 　 空 區 　先到的位置靠后的數據 　 空 區 　
+---+--+-+--+---+
^

當前指針(CP)

無序的數據包到達情況

　 已交給應用的數據 　 未處理的數據 　后到的位置靠前的數據　先到的位置靠后的數據 　 空 區 　

^
當前指針(CP)

數據包到達后CP指針一次性移動

在絕大數TCP實現中，RESET包必須與CP指針相符合，否則RESET包將會被拋棄。好了，一切徹底明朗了，只要我們能夠構造一串連續的數據包，修改當前的CP。比如在上面我們的例子中，我們在第三個包之后構造第四個包，比如包含一個空格或者別的什么，只要不影響***的效果。我們以非?？斓乃俣冗B續發出這兩個包，則當IDS抓到第三個包的時候，它會產生RESET包，不過此時第四個包已經到達了目標主機，修改
了CP指針。當IDS發出的RESET包到達目標主機時，這個RESET包就被忽略了。（我們前面說過IDS都是有延遲的）。同時我們可以有一個更好的辦法，我們在構造數據包的時候，先發送第四個數據包，再發送第3個數據包，則第四個數據包先到達，它進入到緩沖區中，不過此時的CP并沒有改變，當第3個包到達時，CP將移動到第4個數據包之后，這樣一來無論IDS產生的RESET能夠以多快的速度發出，此RESET的確認序列總是
根據第3個包產生的，則它肯定被忽略。因為CP指針早就改變了。

三、結論
本文主要講述了RESET包阻止TCP會話的IDS主動響應機制，至于防火墻聯動的機制，我們其實可以通過欺騙，跳轉（如FTP跳轉等，請參看phrack 51）等方式，造成防火墻錯誤的拒絕某些重要的地址，比如網關路由的地址，DNS地址等等，這樣也可以給使用者帶來很大的干擾，同時一般來說防火墻聯動機制會有1至2秒的延遲，這個時間完全夠***者給目標主機安插一個后門，如此以來，什么樣的防御都可能很輕松的突破了。通過本文的講述，我們可以看到IDS提供了一種主動響應的機制，這比單純的報警而沒有響應好了很多，也很吸引用戶，甚至這一點成了很多廠商的宣傳武器，讓很多消費者以為這時非常高超的技術，其實一個稍據TCP/IP知識的***者，就可以讓這種響應機制失效