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

一、“阻止會(huì)話”機(jī)制簡介：
阻止會(huì)話到目前為止，是最I(lǐng)DS供應(yīng)商最常用的方式。這種方式之所以流行，是因?yàn)樗恍枰獠吭O(shè)備的支持（如防火墻），而且它易于實(shí)現(xiàn)。這一機(jī)制非常簡單，下面我們將逐步剖析這種機(jī)制，并揭示如何繞過它，我希望我的評價(jià)不會(huì)引起廠商們的反感。
下面我們以IIS的Unicode橫向目錄遍歷***為例子，來講解這一機(jī)制的工作方式。***者發(fā)出如下的請求，這個(gè)請求共51個(gè)字節(jié)，將這51個(gè)字節(jié)變成分段的破碎IP包，每個(gè)包長為20個(gè)字節(jié)，如下所示：

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

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

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

+---+---?---+-+
　?已交給應(yīng)用的數(shù)據(jù)?　?未處理的數(shù)據(jù)?　?空?區(qū)?　
+---+--+-+
^

當(dāng)前指針(CP)

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

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

當(dāng)前指針(CP)

無序的數(shù)據(jù)包到達(dá)情況

　?已交給應(yīng)用的數(shù)據(jù)?　?未處理的數(shù)據(jù)?　后到的位置靠前的數(shù)據(jù)　先到的位置靠后的數(shù)據(jù)?　?空?區(qū)?　

^
當(dāng)前指針(CP)

數(shù)據(jù)包到達(dá)后CP指針一次性移動(dòng)

在絕大數(shù)TCP實(shí)現(xiàn)中，RESET包必須與CP指針相符合，否則RESET包將會(huì)被拋棄。好了，一切徹底明朗了，只要我們能夠構(gòu)造一串連續(xù)的數(shù)據(jù)包，修改當(dāng)前的CP。比如在上面我們的例子中，我們在第三個(gè)包之后構(gòu)造第四個(gè)包，比如包含一個(gè)空格或者別的什么，只要不影響***的效果。我們以非常快的速度連續(xù)發(fā)出這兩個(gè)包，則當(dāng)IDS抓到第三個(gè)包的時(shí)候，它會(huì)產(chǎn)生RESET包，不過此時(shí)第四個(gè)包已經(jīng)到達(dá)了目標(biāo)主機(jī)，修改
了CP指針。當(dāng)IDS發(fā)出的RESET包到達(dá)目標(biāo)主機(jī)時(shí)，這個(gè)RESET包就被忽略了。（我們前面說過IDS都是有延遲的）。同時(shí)我們可以有一個(gè)更好的辦法，我們在構(gòu)造數(shù)據(jù)包的時(shí)候，先發(fā)送第四個(gè)數(shù)據(jù)包，再發(fā)送第3個(gè)數(shù)據(jù)包，則第四個(gè)數(shù)據(jù)包先到達(dá)，它進(jìn)入到緩沖區(qū)中，不過此時(shí)的CP并沒有改變，當(dāng)?shù)?個(gè)包到達(dá)時(shí)，CP將移動(dòng)到第4個(gè)數(shù)據(jù)包之后，這樣一來無論IDS產(chǎn)生的RESET能夠以多快的速度發(fā)出，此RESET的確認(rèn)序列總是
根據(jù)第3個(gè)包產(chǎn)生的，則它肯定被忽略。因?yàn)镃P指針早就改變了。

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

轉(zhuǎn)載于:https://blog.51cto.com/helloeveryone/1228711

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的理解IDS的主动响应机制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。