【正文】 aders函數(shù)處理客戶端發(fā)送的報(bào)文頭。當(dāng):HttpFilterProc 被調(diào)用時，接收到的通知將確定將要如何處理該事件。(2) HttpFilterProc當(dāng)對應(yīng)的事件發(fā)生時，服務(wù)器通過調(diào)用ISAPI Filter的 HttpFilterProc 入口點(diǎn)通知為該事件注冊的每個篩選器。根據(jù)系統(tǒng)的需求，我們需要在IIS中注冊以下幾個事件：SF_NOTIFY_PREPROC_HEADERSSF_NOTIFY_SEND_RESPONSESF_NOTIFY_END_OF_REQUEST通過SF_NOTIFY_PREPROC_HEADERS我們可以獲取客戶端所發(fā)送的Http報(bào)文頭；通過SF_NOTIFY_SEND_RESPONSE我們可以獲取服務(wù)器發(fā)送的報(bào)文頭。下面是這兩個回調(diào)函數(shù)的具體作用：(1) GetFilterVersion當(dāng)IIS加載ISAPI Filter的DLL時，會調(diào)用此函數(shù)。 基于ISAPI 的解析及響應(yīng)模塊的實(shí)現(xiàn)在這個Web的入侵防御系統(tǒng)中，我們選擇ISAPI篩選器來實(shí)現(xiàn)Http報(bào)文的解析與響應(yīng)。在配置文件的管理上，我們通過xml文件來實(shí)現(xiàn)。我們使用C++編寫ISAPI的DLL。在Windows平臺下的IIS服務(wù)器上，IIS提供了ISAPI機(jī)制來實(shí)現(xiàn)服務(wù)器的擴(kuò)展和篩選器。以上描述的是本系統(tǒng)的體系結(jié)構(gòu)、處理流程、功能框圖及各個模塊的詳細(xì)設(shè)計(jì)和接口，至此，設(shè)計(jì)工作就全部完成了，下面將根據(jù)此設(shè)計(jì)思想的來實(shí)現(xiàn)Web的入侵防御系統(tǒng)。策略引擎認(rèn)為策略的默認(rèn)響應(yīng)為“Next Policy”?？梢栽诓呗阅_本中封裝這個接口，使腳本顯得更直觀。此接口和Web腳本中的GetServerVariable的作用一致，用來獲得ServerVariable。策略引擎需要為策略提供能獲取客戶端或服務(wù)器端的信息的方法，具體的實(shí)現(xiàn)是在Http解析與響應(yīng)層來完成的。由Http解析模塊提供其具體實(shí)現(xiàn)。不同的方式實(shí)現(xiàn)的策略中都要提供這幾個接口。在檢測客戶端發(fā)出的請求時，策略引擎調(diào)用策略中的OnRecv接口；在檢測服務(wù)器端對客戶端的響應(yīng)時調(diào)用OnSend接口；當(dāng)Http會話結(jié)束時，策略引擎調(diào)度OnEnd接口。(4) 重復(fù)步驟（2）（3）直到策略全部調(diào)度完，如果沒有任何策略響應(yīng)，則策略引擎返回一個“接受請求”的響應(yīng)。策略引擎將按下面的步驟對策略鏈上的策略進(jìn)行調(diào)度：(1) 依次按步驟（2）（3）調(diào)動策略鏈上的策略(2) 如果策略返回的是一個“調(diào)用下一條策略”的響應(yīng)時，則調(diào)用下一條策略。 策略的調(diào)度策略對象中提供兩個接口供策略引擎調(diào)度，一個是OnRecv，另一個是OnSend。(6) 加載成功后就將該策略的狀態(tài)屬性置為Loaded，如果是加載失敗就保持該選項(xiàng)為Unload。如上所述，加載器會將策略對象的初始化（C++對象是通過調(diào)用構(gòu)造函數(shù)來實(shí)現(xiàn)）。C++的加載器為一個策略對象的工廠類，會根據(jù)策略的名稱生成不同的策略對象，如果找不到為該名稱的策略則返回NULL表示加載失敗。(5) 如果加載器的屬性為C++則交由C++的策略加載器處理，如果是為腳本的就由相應(yīng)的腳本加載器處理。(3) 按后面的步驟依次加載這個策略列表中的屬性。(2) 策略引擎將由此列表中策略類型屬性和優(yōu)先級屬性，由系統(tǒng)策略到用戶策略，從高優(yōu)先級策略到低優(yōu)先級的策略的次序，進(jìn)行排序。這個屬性只對腳本加載器有效。(7) 優(yōu)先級通過優(yōu)先級可以控制策略調(diào)度的順序，優(yōu)先級得范圍是：0255，值越低的優(yōu)先級越高。(6) 加載狀態(tài)策略的加載狀態(tài)：Unloaded/Loaded，當(dāng)策略的加載狀態(tài)不處于Loaded時，策略引擎不對其進(jìn)行調(diào)度?？梢栽谂渲梦募性O(shè)置此值(4) 加載器表示策略該有什么樣的加載器加載，加載器會將該策略轉(zhuǎn)換成策略引擎能夠調(diào)度的策略對象。這兩種不同類別的策略都可以由C++的類或者以腳本的方式實(shí)現(xiàn)。(3) 類型按類型可以把策略分為系統(tǒng)策略和用戶策略。(2) 描述描述策略的功能。(1) 策略的名稱用來標(biāo)示不同的策略，在加載過程中，C++加載器通過此名稱生成C++策略的對象。下面就將介紹策略的屬性及策略的加載和調(diào)度的過程。圖 3 策略引擎的結(jié)構(gòu)策略引擎的初始化過程為：讀取策略的屬性列表，根據(jù)屬性列表加載策略。C++的效率高，而腳本驅(qū)動的策略修改和編寫都十分方便。策略引擎可以加載兩種格式的策略，或者說策略可以用兩種不同的方式實(shí)現(xiàn)，一種是使用C++編碼的C++類，一種是使用策略腳本文件。跳轉(zhuǎn)即可以是本服務(wù)器的地址，也可以是外部服務(wù)器的地址。(6) 重定向讓W(xué)eb Server重定向客戶端的訪問。比如在防止圖片的盜鏈的策略中，可以發(fā)送一個用來表明圖片為盜鏈的圖片文件到客戶端。(5) 發(fā)送文件發(fā)送服務(wù)器上的一個文件到客戶端。這是一種比較友好的交互行為，其效果為客戶端的瀏覽器上會顯示發(fā)送的這段信息。由于響應(yīng)是在Http響應(yīng)模塊中完成，這個模塊使用的是Web 服務(wù)器提供的接口，響應(yīng)的過程是在策略調(diào)度之后，所以客戶端再次發(fā)送的Http報(bào)文請求還是會通過Http報(bào)文的解析及策略的調(diào)度，如果“拒絕連接”的響應(yīng)方式是由Web服務(wù)器外的方式實(shí)現(xiàn)的，比如操作系統(tǒng)的IP訪問策略或硬件防火墻等，則客戶端再次發(fā)送的訪問請求不會再被Http報(bào)文解析模塊接收到，也不會再被引擎策略調(diào)度。(3) 拒絕連接讓W(xué)eb Server直接斷開和客戶端的連接，這是一種最嚴(yán)重的響應(yīng)方式，在客戶端所看到的結(jié)果就是瀏覽器報(bào)告說找不到服務(wù)器。策略引擎將不會調(diào)用后面的策略。當(dāng)一個策略中沒有對客戶端的行為做出任何響應(yīng)，則策略引擎認(rèn)為該客戶端調(diào)用策略鏈上的下一條策略。下面將詳細(xì)介紹每一種響應(yīng)方式的效果和作用。 對客戶端訪問的響應(yīng)在一個策略中，可以返回對客戶端的行為做出的響應(yīng)，或什么都不返回。使用統(tǒng)一的格式將日志信息記錄在文本文件中。策略引擎需要封裝Http報(bào)文的解析和響應(yīng)模塊，及日志記錄模塊，供策略中調(diào)用。如果有策略返回響應(yīng)，則通知Http響應(yīng)模塊完成客戶端的響應(yīng)，并停止調(diào)動策略鏈后面的策略。在策略中，可以檢測客戶端請求的各個字段，并對客戶端的行為進(jìn)行分析或記錄，通過定義好的規(guī)則對客戶端不同的行為進(jìn)行響應(yīng)。(5) 策略引擎模塊首先策略引擎對策略腳本進(jìn)行解析，根據(jù)策略的屬性和優(yōu)先級組裝策略鏈。提供以下幾種響應(yīng)方式：調(diào)用下一條策略、接受請求、斷開鏈接、發(fā)送信息、發(fā)送文件和重定向。在一般的Web腳本（例如：ASP、PHP等等）中也會有這樣一種獲取客戶端信息的接口。(3) Http報(bào)文的解析模塊利用Web服務(wù)器提供的接口，對客戶端訪問Web服務(wù)器時提交的原始數(shù)據(jù)進(jìn)行解析，并通知IPS管理模塊收到客戶端的訪問請求，請求策略引擎檢測客戶端的訪問行為。原始數(shù)據(jù)報(bào)weHttp報(bào)文的解析模塊策略引擎Http報(bào)文響應(yīng)模塊配置文件策略腳本日志模塊圖2 Web IPS的處理過程圖(2) 配置文件模塊主要完成配置文件的讀取及保存。依據(jù)Web IPS系統(tǒng)的體系結(jié)構(gòu)及處理流程，系統(tǒng)主要模塊和作用如下：(1) IPS管理模塊負(fù)責(zé)管理和連接各個模塊，管理數(shù)據(jù)流，讀取配置文件后完成整個系統(tǒng)的初始化，對整個系統(tǒng)的狀態(tài)進(jìn)行管理：運(yùn)行，停止，重新加載。下面將介紹具體的處理流程。每一層都完成相對獨(dú)立的功能，當(dāng)某一層的實(shí)現(xiàn)發(fā)生變化時，只要提供的接口沒有變化，對其他幾層就沒有影響。(3) 數(shù)據(jù)管理這一層提供日志記錄、配置管理及策略腳本解析的功能。(2) 策略引擎Http報(bào)文的解析及響應(yīng)策略引擎日志記錄配置管理策略腳本解析圖1 Web IPS的體系結(jié)構(gòu)解析及響應(yīng)策略引擎數(shù)據(jù)管理這一層的作用是策略的調(diào)度，在策略中通過“解析及響應(yīng)”層提供的接口獲取客戶端的信息，具體的響應(yīng)也交給“解析及響應(yīng)”層完成。當(dāng)有客戶端訪問服務(wù)器時，通知策略引擎調(diào)度策略檢測客戶端的訪問信息，并為策略引擎提供響應(yīng)的實(shí)現(xiàn)。圖1為本系統(tǒng)的體系結(jié)構(gòu)圖。多層的結(jié)構(gòu)比單層的結(jié)構(gòu)具有良好的擴(kuò)展性，而單層結(jié)構(gòu)可以模塊間的交互更加高效。 體系結(jié)構(gòu)通常一個系統(tǒng)會采用多層或者單層的體系結(jié)構(gòu)。這樣，這套入侵防御系統(tǒng)的核心便是其策略引擎， 通過強(qiáng)大而靈活的策略引擎來實(shí)現(xiàn)特征檢測或者異常檢測。一次完整的Http會話既然包括客戶端發(fā)送請求和服務(wù)器端對請求的響應(yīng)，那么只有監(jiān)控服務(wù)器端響應(yīng)的內(nèi)容后，才能知道這次Http會話何時結(jié)束。方式(1)可以提供比方式(2)更好的移植性，但這種報(bào)文解析的方式需要一種截獲下層原始報(bào)文的能力，這可以通過截獲傳輸層或網(wǎng)際層報(bào)文的實(shí)現(xiàn)，由于我們將這套系統(tǒng)定位于僅針對Web訪問的入侵防御，我們對Http協(xié)議外的報(bào)文并不關(guān)心，所以我們選擇方式（2）作為我們的Http報(bào)文解析方案，即通過Web服務(wù)器提供的接口僅僅截獲應(yīng)用層的Http報(bào)文。下面將介紹對Web服務(wù)器進(jìn)行入侵防御系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)。上面所介紹的這些對Web服務(wù)器的威脅，雖然只是對Web服務(wù)器眾多攻擊方式中的某幾種，但我們可以看出，對Web服務(wù)器的攻擊行為往往都具有和普通的訪問