【文章內(nèi)容簡(jiǎn)介】 發(fā)送服務(wù)器上的一個(gè)文件到客戶端。這種響應(yīng)方式和上一種類式，但通過文件的方式可以發(fā)送更多的信息到客戶端。比如在防止圖片的盜鏈的策略中，可以發(fā)送一個(gè)用來表明圖片為盜鏈的圖片文件到客戶端。如果是采用的發(fā)送信息的響應(yīng)方式，則客戶端看不到這條信息。 (6) 重定向 讓 Web Server 重定向客戶端的訪問。和前兩種響應(yīng)方式類似，區(qū)別是客戶端會(huì)檢測(cè)到所訪問的 Url 的發(fā)生跳轉(zhuǎn)。跳轉(zhuǎn)即可以是本服務(wù)器的地址，也可 以是外部服務(wù)器的地址。當(dāng)策略引擎檢測(cè)到策略返回的是這種響應(yīng)方式后也會(huì)停止調(diào)用策略鏈后面的其他策略 策略引擎的設(shè)計(jì) 策略引擎是整個(gè)系統(tǒng)的核心模塊，如圖 3 所示為策略引擎的結(jié)構(gòu)。策略引擎可以加載兩種格式的策略，或者說策略可以用兩種不同的方式實(shí)現(xiàn)，一種是使用C++編碼的 C++類，一種是使用策略腳本文件。雖然實(shí)現(xiàn)的方式不同，但策略引擎以同樣的方式調(diào)度。 C++的效率高，而腳本驅(qū)動(dòng)的策略修改和編寫都十分方便。這種體系結(jié)構(gòu)可以方便的把策略不同的實(shí)現(xiàn)方式擴(kuò)充進(jìn)來。 策略引擎的初始化過程為：讀取策略的屬性列表，根據(jù)屬性列表 加載策略。初始化完成后就可以等待客戶端發(fā)出訪問服務(wù)器的請(qǐng)求，為客戶端的訪問進(jìn)行策略調(diào)度。下面就將介紹策略的屬性及策略的加載和調(diào)度的過程。 策略的屬性 策略的屬性可以幫助策略引擎選擇合適的策略加載器加載策略和策略引擎按合適的方式調(diào)度策略。 (1) 策略的名稱 圖 3 策略引擎的結(jié)構(gòu) 用來標(biāo)示不同的策略，在加載過程中， C++加載器通過此名稱生成 C++策略的對(duì)象。在屬性列表中這一條不能省略。 (2) 描述 描述策略的功能?？梢允÷?。 (3) 類型 按類型可以把策略分為系統(tǒng)策略和用戶策略。系統(tǒng)策略永遠(yuǎn)都是在用戶策略前面調(diào)度。這兩種不同類別的策略都可以由 C++的類 或者以腳本的方式實(shí)現(xiàn)。此屬性的作用是在增加策略優(yōu)先級(jí)調(diào)度的粒度?？梢栽谂渲梦募性O(shè)置此值 (4) 加載器 表示策略該有什么樣的加載器加載，加載器會(huì)將該策略轉(zhuǎn)換成策略引擎能夠調(diào)度的策略對(duì)象。 (5) 開啟狀態(tài) 可以給策略的設(shè)置開啟狀態(tài)： Enable 和 Disable，當(dāng)一個(gè)策略處于 Disable 狀態(tài)時(shí)，策略引擎會(huì)跳過對(duì)其的加載。 (6) 加載狀態(tài) 策略的加載狀態(tài)： Unloaded/Loaded，當(dāng)策略的加載狀態(tài)不處于 Loaded 時(shí)，策略引擎不對(duì)其進(jìn)行調(diào)度。這個(gè)值不能在配置文件中設(shè)置，默認(rèn)為 Unloaded，當(dāng)策略引擎成功加載此策略時(shí)， 會(huì)將此值設(shè)置為 Loaded。 (7) 優(yōu)先級(jí) 通過優(yōu)先級(jí)可以控制策略調(diào)度的順序，優(yōu)先級(jí)得范圍是： 0255，值越低的優(yōu)先級(jí)越高。 (8) 路徑 記錄策略腳本的位置，加載時(shí)通過這個(gè)屬性找到相應(yīng)的策略文件的路徑。這個(gè)屬性只對(duì)腳本加載器有效。 策略的加載 策略引擎加載策略的步驟如下： (1) IPS 通過配置模塊讀取出策略屬性列表，去掉此列表中策略名稱重復(fù)的項(xiàng)，然后將此列表作為策略引擎初始化的參數(shù)或者作為策略引擎重新加載的參數(shù)。 (2) 策略引擎將由此列表中策略類型屬性和優(yōu)先級(jí)屬性，由系統(tǒng)策略到用戶策略，從高優(yōu)先級(jí)策略到低優(yōu)先級(jí)的策略的次序，進(jìn)行 排序。形成一個(gè)新的策略列表。 (3) 按后面的步驟依次加載這個(gè)策略列表中的屬性。 (4) 如果策略的開啟狀態(tài)屬性不為 Enable，則跳過該策略，繼續(xù)加載策略列 表中后面的策略。 (5) 如果加載器的屬性為 C++則交由 C++的策略加載器處理，如果是為腳本的就由相應(yīng)的腳本加載器處理。如果不能識(shí)別則跳過該策略。 C++的加載器為一個(gè)策略對(duì)象的工廠類，會(huì)根據(jù)策略的名稱生成不同的策略對(duì)象，如果找不到為該名稱的策略則返回 NULL 表示加載失敗。 腳本加載器會(huì)根據(jù)屬性中的路徑字段去讀取策略腳本，加載器要完成策略腳本語法檢測(cè)的步驟，加載成功時(shí)也是返回 一個(gè)策略對(duì)象，加載失敗返回NULL。 如上所述，加載器會(huì)將策略對(duì)象的初始化（ C++對(duì)象是通過調(diào)用構(gòu)造函數(shù)來實(shí)現(xiàn)）。所以在策略的調(diào)度前不需要再對(duì)策略做初始化。 (6) 加載成功后就將該策略的狀態(tài)屬性置為 Loaded，如果是加載失敗就保持該選項(xiàng)為 Unload。 (7) 直到策略列表中的所有項(xiàng)都處理結(jié)束后，重新遍歷這個(gè)列表，把 Loaded的項(xiàng)依次提取出來，形成策略調(diào)度用的策略列表。 策略的調(diào)度 策略對(duì)象中提供兩個(gè)接口供策略引擎調(diào)度，一個(gè)是 OnRecv，另一個(gè)是OnSend。當(dāng)策略引擎是為檢測(cè)客戶端的信息而調(diào)動(dòng)策略時(shí)，都是調(diào)用的策 略中的 OnRecv 接口，而當(dāng)策略引擎是為檢測(cè)服務(wù)器發(fā)送的數(shù)據(jù)是，都是調(diào)用策略中的 OnSend 接口。 策略引擎將按下面的步驟對(duì)策略鏈上的策略進(jìn)行調(diào)度： (1) 依次按步驟（ 2）（ 3）調(diào)動(dòng)策略鏈上的策略 (2) 如果策略返回的是一個(gè)“調(diào)用下一條策略”的響應(yīng)時(shí)，則調(diào)用下一條策略。 (3) 如果策略返回的不是“調(diào)用下一條策略”的響應(yīng)時(shí)，則停止調(diào)度策略鏈上后面的策略并返回該響應(yīng)。 (4) 重復(fù)步驟（ 2）（ 3）直到策略全部調(diào)度完，如果沒有任何策略響應(yīng)，則策略引擎返回一個(gè)“接受請(qǐng)求”的響應(yīng)。 策略的接口 (1) 策略調(diào)度的接口 為時(shí)策略引擎能調(diào)度策略對(duì)客戶端的 行為進(jìn)行檢測(cè)，策略為策略引擎的不同階段的調(diào)度提供三個(gè)接口： OnRecv、 OnSend 和 OnEnd。在檢測(cè)客戶端發(fā)出的請(qǐng)求時(shí)，策略引擎調(diào)用策略中的 OnRecv 接口；在檢測(cè)服務(wù)器端對(duì)客戶端的響應(yīng)時(shí)調(diào)用 OnSend 接口；當(dāng) Http 會(huì)話結(jié)束時(shí)，策略引擎調(diào)度 OnEnd 接口。策略調(diào)度時(shí)，策略引擎在調(diào)用這些接口時(shí)傳入的都是 client 對(duì)象。不同的方式實(shí)現(xiàn)的策略 中都要提供這幾個(gè)接口。 (2) 客戶端對(duì)象： client 策略調(diào)度接口的參數(shù)，策略引擎在調(diào)用 OnRecv 和 OnSend 時(shí)傳入的參數(shù)就是 client， client 中提供獲取客 戶端信息的方法： GetServerVariable。由 Http 解析模塊提供其具體實(shí)現(xiàn)。 (3) 獲取客戶端信息的接口： GetServerVariable Client 對(duì)象的方法。策略引擎需要為策略提供能獲取客戶端或服務(wù)器端的信息的方法，具體的實(shí)現(xiàn)是在 Http 解析與響應(yīng)層來完成的。 Http 解析與響應(yīng)層中會(huì)為每一個(gè)客戶端的請(qǐng)求生成一個(gè)對(duì)象，這個(gè)對(duì)象提供獲取客戶端和服務(wù)器端信息的訪問為 GetServerVariable。 此接口和 Web 腳本中的 GetServerVariable 的作用一致，用來獲得 ServerVariable。例如： REMOTE_ADDR 是客戶端的 IP；QUERY_STRING 是 查詢 HTTP 請(qǐng)求中問號(hào)（ ?）后的信息 ； HTTP_COOKIE 是客戶端發(fā)送的 Cookie，等等。可以在策略腳本中封裝這個(gè)接口，使腳本顯得更直觀。 (4) 響應(yīng)的接口： Response 和響應(yīng)的方式一一對(duì)應(yīng)： Disconnect、 SendMsg、 SendFile、 Redirect 和 Accept, Next Policy。策略引擎認(rèn)為策略的默認(rèn)響應(yīng)為“ Next Policy”。具體的實(shí)現(xiàn)是由Http 響應(yīng)層完成的。 以上描述的是本系統(tǒng)的體系結(jié)構(gòu) 、處理流程、功能框圖及各個(gè)模塊的詳細(xì)設(shè)計(jì)和接口，至此，設(shè)計(jì)工作就全部完成了，下面將根據(jù)此設(shè)計(jì)思想的來實(shí)現(xiàn) Web的入侵防御系統(tǒng)。 4 Web 的 入侵防御系統(tǒng)的 實(shí)現(xiàn) 按照前面介紹的體系結(jié)構(gòu)，整個(gè)系統(tǒng)分成了三層：解析及響應(yīng)、策略引擎、數(shù)據(jù)管理。在 Windows 平臺(tái)下的 IIS 服務(wù)器上， IIS 提供了 ISAPI 機(jī)制來實(shí)現(xiàn)服務(wù)器的擴(kuò)展和篩選器。我們可以利用 ISAPI 來實(shí)現(xiàn) Http 的解析與響應(yīng)。我們使用 C++編寫 ISAPI 的 DLL。在策略的實(shí)現(xiàn)上，除了提供 C++的策略，我們同時(shí)提供 Lua 腳本編寫的策略。在配置文件的管理上，我們通 過 xml 文件來實(shí)現(xiàn)。下面我們將詳細(xì)介紹這三層的實(shí)現(xiàn)。 基于 ISAPI 的解析及響應(yīng)模塊的實(shí)現(xiàn) 在這個(gè) Web 的入侵防御系統(tǒng)中，我們選擇 ISAPI 篩選器來實(shí)現(xiàn) Http 報(bào)文的解析與響應(yīng)。下面將分別介紹使用 ISAPI 獲取 Http 報(bào)文信息和利用 ISAPI 進(jìn)行響應(yīng)的具體實(shí)現(xiàn) 使用 ISAPI Filter 獲取 Http 報(bào)文信息 ISAPI Filter 提供兩個(gè)回調(diào)函數(shù)： GetFilterVersion 和 HttpFilterProc。下面是 這兩個(gè)回調(diào)函數(shù)的具體作用： (1) GetFilterVersion 當(dāng) IIS 加載 ISAPI Filter 的 DLL 時(shí)，會(huì)調(diào)用此函數(shù)。通過這個(gè)函數(shù)，可以設(shè)置 ISAPI Filter 的優(yōu)先級(jí)和確定請(qǐng)求的事件。根據(jù)系統(tǒng)的需求，我們需要在 IIS中注冊(cè)以下幾個(gè)事件： SF_NOTIFY_PREPROC_HEADERS SF_NOTIFY_SEND_RESPONSE SF_NOTIFY_END_OF_REQUEST 通過 SF_NOTIFY_PREPROC_HEADERS我們可以獲取客戶端所發(fā)送的 Http報(bào)文頭；通過 SF_NOTIFY_SEND_RESPONSE 我們可以獲取服務(wù)器發(fā)送的報(bào)文頭。通過 SF_NOTIFY_END_OF_REQUEST 我們可以知道請(qǐng)求已結(jié)束。 (2) HttpFilterProc 當(dāng)對(duì)應(yīng)的事件發(fā)生時(shí)，服務(wù)器通過調(diào)用 ISAPI Filter 的 HttpFilterProc 入口點(diǎn)通知為該事件注冊(cè)的每個(gè)篩選器?？梢酝ㄟ^ HttpFilterProc 以提供特殊的事件處理。當(dāng) :HttpFilterProc 被調(diào)用時(shí)，接收到的通知將確定將要如何處理該事件。 我們?cè)?GetFilterVersion 中注冊(cè)了 SF_NOTIFY_PREPROC_HEADERS 事件，所以當(dāng)服務(wù)器分析好客戶端所發(fā)送的 Http 報(bào)文頭時(shí) ，將通知我們的 ISAPI Filter處理該報(bào)文頭，并根據(jù)處理的結(jié)果進(jìn)行相應(yīng)的響應(yīng)。我們可以在 HttpFilterProc檢測(cè)當(dāng) SF_NOTIFY_PREPROC_HEADERS 事件發(fā)生時(shí)便調(diào)用 OnPreprocHeaders函數(shù)處理客戶端發(fā)送的報(bào)文頭。 相關(guān)的 C++聲明如下： DWORD WINAPI HttpFilterProc( PHTTP_FILTER_CONTEXT pfc, DWORD notificationType, LPVOID pvNotification )。 typedef struct _HTTP_FILTER_CONTEXT HTTP_FILTER_CONTEXT { DWORD cbSize。 DWORD Revision。 PVOID ServerContext。 DWORD ulReserved。 BOOL fIsSecurePort。 PVOID pFilterContext。 BOOL GetServerVariable。 BOOL AddResponseHeaders。 BOOL WriteClient。 VOID * AllocMem。 BOOL ServerSupportFunction。 } HTTP_FILTER_CONTEXT, * PHTTP_FILTER_CONTEXT。 BOOL WINAPI GetServerVariable( PHTTP_FILTER_CONTEXT pfc, LPSTR lpszVariableName, LPVOID lpvBuffer, LPDWORD lpdwSize )。 我們?cè)?OnPreprocHeaders 即可以獲得通過 GetServerVariable 函數(shù)就可以獲得客戶端發(fā)送的請(qǐng)求的 Http 報(bào)文頭部信息及服務(wù)器的變量。在這里我們將封裝成一個(gè) IClient 的對(duì)象。策略引擎會(huì)對(duì)不同的策略引擎把 IClient 重新封裝。 使用 ISAPI 進(jìn)行 Http 響應(yīng) (1) 拒絕訪問 當(dāng)在 ISAPI Filter 中直接返回 SF_STATUS_REQ_FINISHED 時(shí)， IIS 服務(wù)器就會(huì)斷開和客戶端的連接。 (2) 發(fā)送信息 發(fā)送信息的響應(yīng)中有兩個(gè)參數(shù)，一個(gè)是 報(bào)文響應(yīng)的狀態(tài)，例如： 狀態(tài) 200 表示正常； 狀態(tài) 403 表示拒絕訪問； 狀態(tài) 500 表示服務(wù)器錯(cuò)誤等等 。 另一 個(gè)參 數(shù)是 所發(fā) 送信 息的 內(nèi)容 。通 過 ISAPI Filter 中 提供的ServerSupportFunction API 可以設(shè)置響應(yīng)的 HTTP 報(bào)文的狀態(tài)，通過 WriteClient可以直接向客戶端寫數(shù)據(jù)。以下為發(fā)送信息響應(yīng)方式的部分實(shí)現(xiàn)代碼 void IISClient::SendMsg(const char *status, const char *msg) { uint32_t bufSize。 _pfcServerSupportFunction(SF_REQ_SEND_RESPONSE_HEADER