基于Web的入侵防御系統(tǒng)的設計及實現(xiàn)

-.z基于Web的入侵防御系統(tǒng)的設計與實現(xiàn)摘

要Web效勞器往往得不到傳統(tǒng)防御方式的有效保護，使其成為整個網(wǎng)絡環(huán)境中平安最薄弱的地方。緩沖區(qū)溢出、SQL注入、基于腳本的DDos、盜鏈和跨站等攻擊行為對Web效勞器的平安和穩(wěn)定造成極大的威脅，而目前缺少有效的防御和保護的方式。本課題中首先調(diào)研了當前Web效勞器所面對的威脅，然后針對這些平安威脅設計了一套入侵防御系統(tǒng)，并通過ISAPI實現(xiàn)了對Windows平臺下的IIS效勞器的保護。在這套入侵防御系統(tǒng)中，可以通過制定策略來檢測所有Web效勞器的行為，可以有效地阻止惡意攻擊從而保護Web效勞器的平安。這套入侵防御系統(tǒng)的策略引擎可以加載和調(diào)用Lua語言編寫的策略腳本，使策略腳本的編寫更加簡單。關鍵詞：入侵防御；網(wǎng)絡平安；ISAPI；LuaDesignandImplementationofWebIntrusionPreventionSystemAbstractWebservercannotoftengettheeffectiveprotectionoftraditionaldefensemechanism,makesitbeetheweakestareainthewholenetwork.Theattacks,suchasBufferoverflow,SQLinjection,DDosbasedonscript,ResourcestealandCross-site,causethegreatthreattothesecurityandstabilityofWebserver,andlackeffectivedefenseandprotectionwayatpresent.ThispaperintroducesthedifferentattackwaystoaWebserveratfirst,thendesignsanintrusionpreventionsystemfortheWebserverandimplementstheprotectionofIISserverunderWindowsplatformthroughISAPI.TheintrusionpreventionsystemcanmeasurethebehaviorsofallvisitingWebserversthroughthestrategiesandprotecttheWebServeragainstthemaliciousattacks.ThesecuritystrategiesengineofthesystemcanloadandtransferthestrategyscriptswritteninLualanguage,Itmakestrategyscriptswritingmoresimpler.Keywords:Intrusionsprevention;networksecurity;ISAPI;Lua目

錄論文總頁數(shù)：20頁1

引言

12

Web效勞器所受的威脅及防御

12.1

緩沖區(qū)溢出

12.2

SQL注入攻擊

12.3

基于腳本的DDos攻擊

22.4

其他的不平安因素

33

Web的入侵防御系統(tǒng)的設計

43.1

體系構造

43.2

處理流程

53.3

對客戶端的響應

73.4

策略引擎的設計

83.4.1

策略的屬性

83.4.2

策略的加載

93.4.3

策略的調(diào)度

103.4.4

策略的接口

104

Web的入侵防御系統(tǒng)的實現(xiàn)

114.1

基于ISAPI的解析及響應模塊的實現(xiàn)

114.1.1

使用ISAPIFilter獲取報文信息

114.1.2

使用ISAPI進展響應

134.1.3

在效勞器上的安裝配置ISAPIFilter

144.2

基于Lua的策略實現(xiàn)

154.2.1

對策略的封裝

154.2.2

Lua策略腳本例如

154.3

基于*ml的策略管理

165

系統(tǒng)運行過程及測試

16結

論

18參考文獻

18致

謝

19聲

明

201

引言連接入互聯(lián)網(wǎng)中的每一臺效勞器每時每刻都會受到來自病毒蠕蟲的侵擾和黑客的入侵。目前，很多針對Web效勞器的攻擊都是通過協(xié)議發(fā)起的，所以傳統(tǒng)的防火墻對諸如SQL注入這種攻擊方式不能提供很好的保護。在很多網(wǎng)絡環(huán)境中，正是由于Web效勞器同時對內(nèi)部網(wǎng)絡和外部網(wǎng)絡提供效勞，使其成為整個網(wǎng)絡中最常被攻擊的目標。惡意的攻擊者往往通過Web效勞器上的突破口，來進一步對內(nèi)部網(wǎng)絡進展?jié)B透。所以，Web效勞器的平安顯得尤為重要。本課題的首先對Web效勞器所受到的威脅及相應的防御方式做了一些調(diào)研，然后針對Web效勞器所受的這些威脅設計了一套專門針對Web效勞器平安的輕量級的入侵防御系統(tǒng)，并通過ISAPI實現(xiàn)了Windows平臺環(huán)境下保護IIS效勞器的系統(tǒng)。這套系統(tǒng)通過策略來控制Web效勞器的行為，它的策略引擎可以加載Lua腳本編寫的策略，所以策略的編寫十分容易。通過對這套系統(tǒng)的運行檢測可以發(fā)現(xiàn)它能有效的保護Web效勞器的平安。2

Web效勞器所受的威脅及防御Web效勞器在互聯(lián)網(wǎng)環(huán)境中會遭受格式各樣的平安威脅，下面列出的是一些當前主流的針對Web效勞器的攻擊方式，它們有的會導致效勞器被非法控制，有的會使效勞器無法提供正常的效勞，而有的甚至會對者的機器造成破壞。2.1

緩沖區(qū)溢出緩沖區(qū)溢出[1]主要是因為Web效勞器程序對客戶端提交的數(shù)據(jù)缺少平安必要的長度檢測，效勞器程序的堆棧被惡意數(shù)據(jù)填充，導致效勞器程序執(zhí)行非法的指令或產(chǎn)生拒絕效勞。如曾經(jīng)造成十分大危害的蠕蟲“紅色代碼〔RedCode〕〞和“尼姆達〔Nimda〕〞都是利用IIS的緩沖區(qū)溢出的漏洞而傳播的。目前，緩沖區(qū)溢出是很難杜絕的，因為Web效勞器程序開發(fā)的測試階段無法對所有客戶端可能提交的數(shù)據(jù)進展測試，所以不能確保Web效勞器程序完全沒有緩沖區(qū)溢出威脅的存在。因為Web效勞器程序提供專有的效勞，所以我們可以通過協(xié)議確定客戶端提交數(shù)據(jù)中每個字段的長度的合理*圍，通過對所有用戶提交的數(shù)據(jù)都進展嚴格的長度檢測是對緩沖區(qū)溢出攻擊的有效防御方式。2.2

SQL注入攻擊SQL注入攻擊[2]是近幾年非常流行的攻擊方式。對一個內(nèi)部網(wǎng)絡的滲透往往是從Web效勞腳本入手〔如ASP，PHP等〕，而SQL注入漏洞通常是Web效勞腳本中最容易找到的。目前互聯(lián)網(wǎng)上仍然存在很多有此風險的效勞器。SQL注入同樣也是對客戶端提交的數(shù)據(jù)沒有進展必要的檢測過濾造成的。構造特殊的數(shù)據(jù)提交到存在此缺陷的Web效勞器上后，可以導致惡意的SQL語句注入到Web腳本的SQL調(diào)用中，從而泄露敏感信息或者執(zhí)行威脅的SQL指令。無論是何種Web腳本語本語言或何種數(shù)據(jù)庫，如果編碼人員缺乏相關的平安意識，都可能會導致此缺陷的存在。目前對SQL注入攻擊提出的防御方案有：(1)

在效勞端正式處理之前對提交數(shù)據(jù)的合法性進展檢查；(2)

封裝客戶端提交信息；(3)

替換或刪除敏感字符/字符串；(4)

屏蔽出錯信息。方案(1)被公認是最根本的解決方案，在確認客戶端的輸入合法之前，效勞端拒絕進展關鍵性的處理操作，不過這需要開發(fā)者能夠以一種平安的方式來構建網(wǎng)絡應用程序，雖然已有大量針對在網(wǎng)絡應用程序開發(fā)中如何平安地數(shù)據(jù)庫的文檔出版，但仍然有很多開發(fā)者缺乏足夠的平安意識，造成開發(fā)出的產(chǎn)品中依舊存在注入漏洞；方案(2)的做法需要RDBMS的支持，目前只有Oracle采用該技術；方案(3)則是一種不完全的解決措施，例如，當客戶端的輸入為“…ccmdmcmdd…〞時,在對敏感字符串“cmd〞替換刪除以后，剩下的字符正好是“…cmd…〞；方案(4)是目前最常被采用的方法，很多平安文檔都認為SQL注入攻擊需要通過錯誤信息收集信息，有些甚至聲稱*些特殊的任務假設缺乏詳細的錯誤信息則不能完成，這使很多平安專家形成一種觀念，即注入攻擊在缺乏詳細錯誤的情況下不能實施。2.3

基于腳本的DDos攻擊當一個入侵者無法找到目標Web效勞器的有效滲透方式時，很可能選擇DDos這種攻擊方式。傳統(tǒng)的DDos攻擊方式在一臺硬件防火墻面往往失去了它的威力，而基于腳本的DDos攻擊在近幾年里逐漸成為對Web效勞器發(fā)起拒絕效勞的有效方式。和傳統(tǒng)的DDos攻擊針對效勞器操作系統(tǒng)本身或網(wǎng)絡帶寬的消耗而言，基于腳本的攻擊方式是針對應用程序的消耗來到達拒絕效勞攻擊的目的。對靜態(tài)網(wǎng)頁來說，這種攻擊方式往往達不到它的攻擊效果，而動態(tài)網(wǎng)頁中，都會有一些對資源占用比擬多的頁面，比方包含復雜查詢語句的頁面，很可能在一次過程中會有較長時間數(shù)據(jù)庫的行為，通過多線程，分布式的這個頁面就可以造成拒絕效勞的效果。目前，流行的CC工具就是利用這個原理來實現(xiàn)基于腳本的DDos攻擊?；谀_本的DDos的另一種攻擊方法是利用Web系統(tǒng)**息提交的功能提交垃圾數(shù)據(jù)。防御這種攻擊方式的方法有以下幾種：(1)

防止客戶端的快速刷新，可以通過Cookie或者Session來實現(xiàn)(2)

對消耗較大的頁面進展識別碼認證，確保是人而不是惡意的自動化程序在這個頁面。(3)

限制每個客戶端的線程數(shù)2.4

其他的不平安因素除了上面所列的幾種Web效勞器常見的攻擊威脅外，還存在一些其他的不平安因素。(1)

缺少經(jīng)歷的系統(tǒng)管理員往往沒有正確的設置效勞器文件系統(tǒng)的權限當一個入侵者獲得到Web效勞器上的較低的權限時，他通常會想方設法的提升自己的權限，而效勞器文件系統(tǒng)的權限系統(tǒng)沒有正確設置時，可以通過較低的權限下獲取到效勞器上的敏感信息，為提升權限提供了條件。(2)

盜鏈盜鏈雖然不是一種攻擊手段，但因其消耗了大量的效勞器資源和帶寬，所以也是對當前Web效勞器的穩(wěn)定影響比擬大的因素。盜鏈的定義是：此內(nèi)容不在自己效勞器上，而通過技術手段，繞過別人放廣告有利益的最終頁，直接在自己的有廣告有利益的頁面上向最終用戶提供此內(nèi)容。常常是一些名不見經(jīng)傳的小來盜取一些有實力的大的地址〔比方一些音樂、圖片、軟件的下載地址〕然后放置在自己的中，通過這種方法盜取大的空間和流量。另外一種盜鏈是像訊雷這樣的P2SP的下載軟件，可以讓客戶端以類似BT的方式同時從多臺效勞器上下載文件。對盜鏈的防御往往是通過設定一些策略來實現(xiàn)，如檢查客戶端報頭的refer字段等。(3)

腳本自身的BugWeb效勞器上所運行的動態(tài)腳本〔ASP、ASP.NET、JSP和PHP等等〕自身所帶的Bug也會給Web效勞器的平安帶來極大的威脅。例如前面所提的SQL注入也是屬于Web腳本的Bug。惡意的攻擊者可能可以利用這些腳本中的Bug輕易的獲得Web效勞器的權限。很多Web效勞器上采用的是開源的系統(tǒng)，而有的管理員因為設置上的疏忽〔例如編輯源碼后產(chǎn)生的bak文件，數(shù)據(jù)庫的路徑?jīng)]有保護等等〕，給攻擊者入侵翻開了方便之門。對于這類來自腳本自身的平安威脅，好的防御方式是時常關注源碼站點的補丁信息，對Web效勞器的環(huán)境進展平安配置，防止數(shù)據(jù)庫這樣會透露敏感信息的文件被下載等等。上面所介紹的這些對Web效勞器的威脅，雖然只是對Web效勞器眾多攻擊方式中的*幾種，但我們可以看出，對Web效勞器的攻擊行為往往都具有和普通的不同的行為。我們可以通過這些非正常的行為鑒別出惡意的攻擊。下面將介紹對Web效勞器進展入侵防御系統(tǒng)的設計和實現(xiàn)。3

Web的入侵防御系統(tǒng)的設計由于系統(tǒng)要對客戶端發(fā)送的報文進展分析，這需要對報文進展解析，報文解析的方式主要有兩種：(1)自解析：系統(tǒng)對原始數(shù)據(jù)報文自行解析；(2)由Web效勞器進展解析，需要時系統(tǒng)通過Web效勞器提供的接口查詢。方式(1)可以提供比方式(2)更好的移植性，但這種報文解析的方式需要一種截獲下層原始報文的能力，這可以通過截獲傳輸層或網(wǎng)際層報文的實現(xiàn)，由于我們將這套系統(tǒng)定位于僅針對Web的入侵防御，我們對協(xié)議外的報文并不關心，所以我們選擇方式〔2〕作為我們的報文解析方案，即通過Web效勞器提供的接口僅僅截獲應用層的報文。要對客戶端發(fā)起的請求進展完全的監(jiān)控光靠檢測客戶端的行為是不夠的，因為這樣我們只知道客戶端發(fā)起什么樣的請求但無法知道效勞器端是如何對客戶端進展響應的。一次完整的會話既然包括客戶端發(fā)送請求和效勞器端對請求的響應，則只有監(jiān)控效勞器端響應的內(nèi)容后，才能知道這次會話何時完畢。如果Web效勞器提供報文封裝的接口，則在對客戶端進展響應時我們也盡量調(diào)用Web效勞器的這些接口而不是自己組裝報文。這樣，這套入侵防御系統(tǒng)的核心便是其策略引擎，通過強大而靈活的策略引擎來實現(xiàn)特征檢測或者異常檢測。下面將介紹這個Web的入侵防御系統(tǒng)的具體體系構造和處理流程。3.1

體系構造通常一個系統(tǒng)會采用多層或者單層的體系構造。多層的構造將不同功能的模塊進展了劃分，層與層之間靠定義好的接口進展通信，單層的構造將模塊都緊耦合在一起，模塊與模塊間有穿插調(diào)用。多層的構造比單層的構造具有良好的擴展性，而單層構造可以模塊間的交互更加高效。為了能使系統(tǒng)適合不同的Web效勞器平臺，綜合以上的因素考慮后，本系統(tǒng)采用分層的體系構造。這個Web的入侵防御系統(tǒng)主要分層了以下三層：(1)

解析及響應層這一層為整個防御系統(tǒng)提供對客戶端發(fā)送的報文請求的解析及效勞器響應時報文封裝的接口。當有客戶端效勞器時，通知策略引擎調(diào)度策略檢測客戶端的信息，并為策略引擎提供響應的實現(xiàn)。按照前面的分析，這一層是由效勞器提供的接口封裝實現(xiàn)。(2)

策略引擎這一層的作用是策略的調(diào)度，在策略中通過“解析及響應〞層提供的接口獲取客戶端的信息，具體的響應也交給“解析及響應〞層完成。同時策略引擎還需要調(diào)度數(shù)據(jù)管理層完成策略的加載，以及日志記錄的功能。(3)

數(shù)據(jù)管理這一層提供日志記錄、配置管理及策略腳本解析的功能。所以對數(shù)據(jù)進展處理的過程都是在這一層里完成。每一層都完成相對獨立的功能，當*一層的實現(xiàn)發(fā)生變化時，只要提供的接口沒有變化，對其他幾層就沒有影響。這樣整個構造就有很大的擴展性，例如：我們可以把解析和響應層的具體實現(xiàn)是由調(diào)用Web效勞器自身接口的方式替換為直接截獲傳輸層網(wǎng)絡層封包的方式等等。下面將介紹具體的處理流程。3.2

處理流程WebIPS的具體處理流程如下：當客戶端發(fā)送請求時，原始的數(shù)據(jù)報文經(jīng)報文解析模塊解析，報文解析模塊會通知策略引擎模塊對客戶端的信息進展檢測，策略引擎會依據(jù)策略腳本中編寫的策略，通知響應模塊對客戶端的行為做出響應，并依據(jù)策略腳本中的策略，通知日志記錄模塊記錄相應的日志。依據(jù)WebIPS系統(tǒng)的體系構造及處理流程，系統(tǒng)主要模塊和作用如下：(1)

IPS管理模塊負責管理和連接各個模塊，管理數(shù)據(jù)流，讀取配置文件后完成整個系統(tǒng)的初始化，對整個系統(tǒng)的狀態(tài)進展管理：運行，停頓，重新加載。當報文解析模塊通知有客戶端的時，調(diào)用策略引擎對客戶端的行為及信息進展檢測，對策略引擎返回的結果通知響應模塊進展響應。(2)

配置文件模塊主要完成配置文件的讀取及保存。提供統(tǒng)一的接口，具體實現(xiàn)可以根據(jù)需要而作修改。(3)

報文的解析模塊利用Web效勞器提供的接口，對客戶端Web效勞器時提交的原始數(shù)據(jù)進展解析，并通知IPS管理模塊收到客戶端的請求，請求策略引擎檢測客戶端的行為。報文的解析模塊中會為每一個客戶端生成一個實現(xiàn)了能檢測客戶端相關信息的接口的對象。在一般的Web腳本〔例如：ASP、ASP.NET、PHP等等〕中也會有這樣一種獲取客戶端信息的接口。(4)

響應模塊當需要對客戶端的行為進展響應時，在這一模塊中對數(shù)據(jù)報文進展組裝。提供以下幾種響應方式：調(diào)用下一條策略、承受請求、斷開、發(fā)送信息、發(fā)送文件和重定向。除了“調(diào)用下一條策略〞需要策略引擎繼續(xù)調(diào)用其他策略外，其他的響應完畢后都表示客戶端的一次請求過程的完畢，策略引擎將不會繼續(xù)調(diào)用策略鏈上的其它策略。(5)

策略引擎模塊首先策略引擎對策略腳本進展解析，根據(jù)策略的屬性和優(yōu)先級組裝策略鏈。當IPS管理模塊通知策略引擎對*一個客戶端的信息進展檢測時，策略引擎利用報文解析模塊提供的接口獲取所需的客戶端得信息，分析客戶端得行為，通過依次調(diào)度策略來控制客戶端的。在策略中，可以檢測客戶端請求的各個字段，并對客戶端的行為進展分析或記錄，通過定義好的規(guī)則對客戶端不同的行為進展響應。當一個策略中沒有對客戶端的行為做出響應時，策略引擎調(diào)用策略鏈中的下一條，直到全部調(diào)用完。如果有策略返回響應，則通知響應模塊完成客戶端的響應，并停頓調(diào)動策略鏈后面的策略。如果沒有任何策略對客戶端的行為做出響應，策略引擎則返回承受請求的響應。策略引擎需要封裝報文的解析和響應模塊，及日志記錄模塊，供策略中調(diào)用。(6)

日志模塊日志模塊的作用是對系統(tǒng)運行時產(chǎn)生的日志或對入侵防御行為的進展記錄。使用統(tǒng)一的格式將日志信息記錄在文本文件中。由于系統(tǒng)采用分層的體系構造，所以這一模塊可以方便的替換成其他格式的日志記錄方式。3.3

對客戶端的響應在一個策略中，可以返回對客戶端的行為做出的響應，或什么都不返回。如果返回的是除“調(diào)度下一條策略〞外的其他響應，則策略引擎停頓調(diào)動策略鏈中后面的策略，否則策略引擎依次調(diào)度策略鏈上的策略直到全部策略調(diào)度完成。下面將詳細介紹每一種響應方式的效果和作用。(1)

調(diào)度下一條策略這是策略的默認響應方式，策略引擎將為客戶端調(diào)度下一條策略。當一個策略中沒有對客戶端的行為做出任何響應，則策略引擎認為該客戶端調(diào)用策略鏈上的下一條策略。(2)

承受請求承受客戶端的。策略引擎將不會調(diào)用后面的策略。這種響應方式通常用于白，即對特定的客戶端的做出的特別響應處理，由Web效勞器處理客戶端的請求，而不受發(fā)出這個響應的策略后面的策略的影響。(3)

拒絕連接讓WebServer直接斷開和客戶端的連接，這是一種最嚴重的響應方式，在客戶端所看到的結果就是瀏覽器報告說找不到效勞器。當策略引擎已經(jīng)確認客戶端的是惡意的攻擊行為時，可以直接斷開和客戶端的連接。由于響應是在響應模塊中完成，這個模塊使用的是Web效勞器提供的接口，響應的過程是在策略調(diào)度之后，所以客戶端再次發(fā)送的報文請求還是會通過報文的解析及策略的調(diào)度，如果“拒絕連接〞的響應方式是由Web效勞器外的方式實現(xiàn)的，比方操作系統(tǒng)的IP策略或硬件防火墻等，則客戶端再次發(fā)送的請求不會再被報文解析模塊接收到，也不會再被引擎策略調(diào)度。(4)

發(fā)送信息直接發(fā)送一段文本信息到客戶端，通常是一段提示或警告信息。這是一種比擬友好的交互行為，其效果為客戶端的瀏覽器上會顯示發(fā)送的這段信息。當策略引擎檢測到策略返回的是這種響應方式后會停頓調(diào)用策略鏈后面的其他策略。(5)

發(fā)送文件發(fā)送效勞器上的一個文件到客戶端。這種響應方式和上一種類式，但通過文件的方式可以發(fā)送更多的信息到客戶端。比方在防止圖片的盜鏈的策略中，可以發(fā)送一個用來說明圖片為盜鏈的圖片文件到客戶端。如果是采用的發(fā)送信息的響應方式，則客戶端看不到這條信息。(6)

重定向讓WebServer重定向客戶端的。和前兩種響應方式類似，區(qū)別是客戶端會檢測到所的Url的發(fā)生跳轉。跳轉即可以是本效勞器的地址，也可以是外部效勞器的地址。當策略引擎檢測到策略返回的是這種響應方式后也會停頓調(diào)用策略鏈后面的其他策略3.4

策略引擎的設計策略引擎是整個系統(tǒng)的核心模塊，如圖3所示為策略引擎的構造。策略引擎可以加載兩種格式的策略，或者說策略可以用兩種不同的方式實現(xiàn)，一種是使用C++編碼的C++類，一種是使用策略腳本文件。雖然實現(xiàn)的方式不同，但策略引擎以同樣的方式調(diào)度。C++的效率高，而腳本驅動的策略修改和編寫都十分方便。這種體系構造可以方便的把策略不同的實現(xiàn)方式擴大進來。策略引擎的初始化過程為：讀取策略的屬性列表，根據(jù)屬性列表加載策略。初始化完成后就可以等待客戶端發(fā)出效勞器的請求，為客戶端的進展策略調(diào)度。下面就將介紹策略的屬性及策略的加載和調(diào)度的過程。3.4.1

策略的屬性策略的屬性可以幫助策略引擎選擇適宜的策略加載器加載策略和策略引擎按適宜的方式調(diào)度策略。(1)

策略的名稱用來標示不同的策略，在加載過程中，C++加載器通過此名稱生成C++策略的對象。在屬性列表中這一條不能省略。(2)

描述描述策略的功能?？梢允÷?。(3)

類型按類型可以把策略分為系統(tǒng)策略和用戶策略。系統(tǒng)策略永遠都是在用戶策略前面調(diào)度。這兩種不同類別的策略都可以由C++的類或者以腳本的方式實現(xiàn)。此屬性的作用是在增加策略優(yōu)先級調(diào)度的粒度?？梢栽谂渲梦募性O置此值(4)

加載器表示策略該有什么樣的加載器加載，加載器會將該策略轉換成策略引擎能夠調(diào)度的策略對象。(5)

開啟狀態(tài)可以給策略的設置開啟狀態(tài)：Enable和Disable，當一個策略處于Disable狀態(tài)時，策略引擎會跳過對其的加載。(6)

加載狀態(tài)策略的加載狀態(tài)：Unloaded/Loaded，當策略的加載狀態(tài)不處于Loaded時，策略引擎不對其進展調(diào)度。這個值不能在配置文件中設置，默認為Unloaded，當策略引擎成功加載此策略時，會將此值設置為Loaded。(7)

優(yōu)先級通過優(yōu)先級可以控制策略調(diào)度的順序，優(yōu)先級得*圍是：0-255，值越低的優(yōu)先級越高。(8)

路徑記錄策略腳本的位置，加載時通過這個屬性找到相應的策略文件的路徑。這個屬性只對腳本加載器有效。3.4.2

策略的加載策略引擎加載策略的步驟如下：(1)

IPS通過配置模塊讀取出策略屬性列表，去掉此列表中策略名稱重復的項，然后將此列表作為策略引擎初始化的參數(shù)或者作為策略引擎重新加載的參數(shù)。(2)

策略引擎將由此列表中策略類型屬性和優(yōu)先級屬性，由系統(tǒng)策略到用戶策略，從高優(yōu)先級策略到低優(yōu)先級的策略的次序，進展排序。形成一個新的策略列表。(3)

按后面的步驟依次加載這個策略列表中的屬性。(4)

如果策略的開啟狀態(tài)屬性不為Enable，則跳過該策略，繼續(xù)加載策略列表中后面的策略。(5)

如果加載器的屬性為C++則交由C++的策略加載器處理，如果是為腳本的就由相應的腳本加載器處理。如果不能識別則跳過該策略。C++的加載器為一個策略對象的工廠類，會根據(jù)策略的名稱生成不同的策略對象，如果找不到為該名稱的策略則返回NULL表示加載失敗。腳本加載器會根據(jù)屬性中的路徑字段去讀取策略腳本，加載器要完成策略腳本語法檢測的步驟，加載成功時也是返回一個策略對象，加載失敗返回NULL。如上所述，加載器會將策略對象的初始化〔C++對象是通過調(diào)用構造函數(shù)來實現(xiàn)〕。所以在策略的調(diào)度前不需要再對策略做初始化。(6)

加載成功后就將該策略的狀態(tài)屬性置為Loaded，如果是加載失敗就保持該選項為Unload。(7)

直到策略列表中的所有項都處理完畢后，重新遍歷這個列表，把Loaded的項依次提取出來，形成策略調(diào)度用的策略列表。3.4.3

策略的調(diào)度策略對象中提供兩個接口供策略引擎調(diào)度，一個是OnRecv，另一個是OnSend。當策略引擎是為檢測客戶端的信息而調(diào)動策略時，都是調(diào)用的策略中的OnRecv接口，而當策略引擎是為檢測效勞器發(fā)送的數(shù)據(jù)是，都是調(diào)用策略中的OnSend接口。策略引擎將按下面的步驟對策略鏈上的策略進展調(diào)度：(1)

依次按步驟〔2〕〔3〕調(diào)動策略鏈上的策略(2)

如果策略返回的是一個“調(diào)用下一條策略〞的響應時，則調(diào)用下一條策略。(3)

如果策略返回的不是“調(diào)用下一條策略〞的響應時，則停頓調(diào)度策略鏈上后面的策略并返回該響應。(4)

重復步驟〔2〕〔3〕直到策略全部調(diào)度完，如果沒有任何策略響應，則策略引擎返回一個“承受請求〞的響應。3.4.4

策略的接口(1)

策略調(diào)度的接口為時策略引擎能調(diào)度策略對客戶端的行為進展檢測，策略為策略引擎的不同階段的調(diào)度提供三個接口：OnRecv、OnSend和OnEnd。在檢測客戶端發(fā)出的請求時，策略引擎調(diào)用策略中的OnRecv接口；在檢測效勞器端對客戶端的響應時調(diào)用OnSend接口；當會話完畢時，策略引擎調(diào)度OnEnd接口。策略調(diào)度時，策略引擎在調(diào)用這些接口時傳入的都是client對象。不同的方式實現(xiàn)的策略中都要提供這幾個接口。(2)

客戶端對象：client策略調(diào)度接口的參數(shù)，策略引擎在調(diào)用OnRecv和OnSend時傳入的參數(shù)就是client，client中提供獲取客戶端信息的方法：GetServerVariable。由解析模塊提供其具體實現(xiàn)。(3)

獲取客戶端信息的接口：GetServerVariableClient對象的方法。策略引擎需要為策略提供能獲取客戶端或效勞器端的信息的方法，具體的實現(xiàn)是在解析與響應層來完成的。解析與響應層中會為每一個客戶端的請求生成一個對象，這個對象提供獲取客戶端和效勞器端信息的為GetServerVariable。此接口和Web腳本中的GetServerVariable的作用一致，用來獲得ServerVariable。例如：REMOTE_ADDR是客戶端的IP；QUERY_STRING是查詢請求中問號〔?〕后的信息；_COOKIE是客戶端發(fā)送的Cookie，等等?？梢栽诓呗阅_本中封裝這個接口，使腳本顯得更直觀。(4)

響應的接口：Response和響應的方式一一對應：Disconnect、SendMsg、SendFile、Redirect和Accept,Ne*tPolicy。策略引擎認為策略的默認響應為“Ne*tPolicy〞。具體的實現(xiàn)是由響應層完成的。以上描述的是本系統(tǒng)的體系構造、處理流程、功能框圖及各個模塊的詳細設計和接口，至此，設計工作就全部完成了，下面將根據(jù)此設計思想的來實現(xiàn)Web的入侵防御系統(tǒng)。4

Web的入侵防御系統(tǒng)的實現(xiàn)按照前面介紹的體系構造，整個系統(tǒng)分成了三層：解析及響應、策略引擎、數(shù)據(jù)管理。在Windows平臺下的IIS效勞器上，IIS提供了ISAPI機制來實現(xiàn)效勞器的擴展和篩選器。我們可以利用ISAPI來實現(xiàn)的解析與響應。我們使用C++編寫ISAPI的DLL。在策略的實現(xiàn)上，除了提供C++的策略，我們同時提供Lua腳本編寫的策略。在配置文件的管理上，我們通過*ml文件來實現(xiàn)。下面我們將詳細介紹這三層的實現(xiàn)。4.1

基于ISAPI的解析及響應模塊的實現(xiàn)在這個Web的入侵防御系統(tǒng)中，我們選擇ISAPI篩選器來實現(xiàn)報文的解析與響應。下面將分別介紹使用ISAPI獲取報文信息和利用ISAPI進展響應的具體實現(xiàn)4.1.1

使用ISAPIFilter獲取報文信息ISAPIFilter提供兩個回調(diào)函數(shù)：GetFilterVersion和FilterProc。下面是這兩個回調(diào)函數(shù)的具體作用：(1)

GetFilterVersion當IIS加載ISAPIFilter的DLL時，會調(diào)用此函數(shù)。通過這個函數(shù)，可以設置ISAPIFilter的優(yōu)先級和確定請求的事件。根據(jù)系統(tǒng)的需求，我們需要在IIS中注冊以下幾個事件：SF_NOTIFY_PREPROC_HEADERSSF_NOTIFY_SEND_RESPONSESF_NOTIFY_END_OF_REQUEST通過SF_NOTIFY_PREPROC_HEADERS我們可以獲取客戶端所發(fā)送的報文頭；通過SF_NOTIFY_SEND_RESPONSE我們可以獲取效勞器發(fā)送的報文頭。通過SF_NOTIFY_END_OF_REQUEST我們可以知道請求已完畢。(2)

FilterProc當對應的事件發(fā)生時，效勞器通過調(diào)用ISAPIFilter的FilterProc入口點通知為該事件注冊的每個篩選器?？梢酝ㄟ^FilterProc以提供特殊的事件處理。當:FilterProc被調(diào)用時，接收到的通知將確定將要如何處理該事件。我們在GetFilterVersion中注冊了SF_NOTIFY_PREPROC_HEADERS事件，所以當效勞器分析好客戶端所發(fā)送的報文頭時，將通知我們的ISAPIFilter處理該報文頭，并根據(jù)處理的結果進展相應的響應。我們可以在FilterProc檢測當SF_NOTIFY_PREPROC_HEADERS事件發(fā)生時便調(diào)用OnPreprocHeaders函數(shù)處理客戶端發(fā)送的報文頭。相關的C++聲明如下：DWORDWINAPIFilterProc(P_FILTER_CONTE*Tpfc,DWORDnotificationType,LPVOIDpvNotification);typedefstruct__FILTER_CONTE*T_FILTER_CONTE*T{

DWORDcbSize;DWORDRevision;PVOIDServerConte*t;DWORDulReserved;BOOLfIsSecurePort;PVOIDpFilterConte*t;

BOOLGetServerVariable;BOOLAddResponseHeaders;BOOLWriteClient;VOID*AllocMem;BOOLServerSupportFunction;}_FILTER_CONTE*T,*P_FILTER_CONTE*T;BOOLWINAPIGetServerVariable(P_FILTER_CONTE*Tpfc,

LPSTRlpszVariableName,

LPVOIDlpvBuffer,

LPDWORDlpdwSize);我們在OnPreprocHeaders即可以獲得通過GetServerVariable函數(shù)就可以獲得客戶端發(fā)送的請求的報文頭部信息及效勞器的變量。在這里我們將封裝成一個IClient的對象。策略引擎會對不同的策略引擎把IClient重新封裝。4.1.2

使用ISAPI進展響應(1)

拒絕當在ISAPIFilter中直接返回SF_STATUS_REQ_FINISHED時，IIS效勞器就會斷開和客戶端的連接。(2)

發(fā)送信息發(fā)送信息的響應中有兩個參數(shù)，一個是報文響應的狀態(tài)，例如：狀態(tài)200表示正常；狀態(tài)403表示拒絕；狀態(tài)500表示效勞器錯誤等等。另一個參數(shù)是所發(fā)送信息的內(nèi)容。通過ISAPIFilter中提供的ServerSupportFunctionAPI可以設置響應的報文的狀態(tài)，通過WriteClient可以直接向客戶端寫數(shù)據(jù)。以下為發(fā)送信息響應方式的局部實現(xiàn)代碼voidIISClient::SendMsg(constchar*status,constchar*msg){uint32_tbufSize;_pfc->ServerSupportFunction(SF_REQ_SEND_RESPONSE_HEADER,

const_cast<char*>(status),

NULL,NULL);

bufSize=uint32_t(strlen(msg));

_pfc->WriteClient(const_cast<char*>(msg),&bufSize);

}(3)

發(fā)送文件發(fā)送文件的實現(xiàn)和發(fā)送信息的實現(xiàn)類似。第二個參數(shù)換成了要發(fā)送文件的路徑。發(fā)送的文件內(nèi)容從該路徑指定的文件中讀取。以下為發(fā)送文件響應的實現(xiàn)的局部實現(xiàn)代碼IISClient::SendFile(constchar*status,constchar*filename){constDWORDBUF_SIZE=10*1024;

charbuffer[BUF_SIZE]={0};

_pfc->ServerSupportFunction(SF_REQ_SEND_RESPONSE_HEADER,

const_cast<char*>(status),

NULL,NULL);

ifstreamin(filename,ios_base::binary);

if(in)

{

DWORDnCount=0;

for(;;)

{in.read(buffer,BUF_SIZE);

nCount=in.gcount();

if(nCount==0)

break;

_pfc->WriteClient(buffer,&nCount);

}

}

}(4)

重定向將效勞器端響應的報頭中的狀態(tài)碼設置為“302MovedPermanently〞，同時設置報頭中的Location為要轉向的地址?？蛻舳说臑g覽器在收到這樣的報文后會重新去新的地址。重定向的局部實現(xiàn)代碼如下voidIISClient::Redirect(constchar*url){

charbuf[256];

sprintf(buf,"Location:%s\r\n",url);

_pfc->AddResponseHeaders(buf);_pfc->ServerSupportFunction(SF_REQ_SEND_RESPONSE_HEADER,"302MovedPermanently",

NULL,NULL);return;}4.1.3

在效勞器上的安裝配置ISAPIFilter正確的配置ISAPIFilter才能保證系統(tǒng)能夠正常工作。在Windows2003的效勞器上配置IIS的ISAPIFilter的步驟如下：(1)

翻開IIS管理器(2)

展開左側的目錄樹，選擇，單擊鼠標右鍵，選擇屬性(3)

選擇ISAPI篩選器一欄(4)

點擊添加按鈕，篩選器名稱填“WebIPS〞，可執(zhí)行文件選擇WebIPS所在的路徑，單擊確定添加完畢。(5)

如果需要重新加載ISAPI，需要重啟IIS效勞。在完成上述步驟后，通過瀏覽器下效勞器所在的，如果狀態(tài)欄變?yōu)榫G色向上箭頭，說明系統(tǒng)已經(jīng)可以正常工作，否則說明ISAPIFilter沒有加載成功。

4.2

基于Lua的策略實現(xiàn)在這個Web的入侵防御系統(tǒng)的設計中，策略引擎可以加載C++實現(xiàn)的策略和腳本實現(xiàn)的策略腳本。C++實現(xiàn)的策略效率高但因為采用硬編碼的方式集成到系統(tǒng)中，除了少量的數(shù)據(jù)信息可以通過配置文件在加載時動態(tài)配置外，其策略的邏輯無法靈活的修改。而腳本由于其動態(tài)解析的特點，策略的邏輯可以很方便的通過修改策略腳本完成，也可以通過策略腳本提供更多的策略。雖然腳本方式的策略在效率方面低于C++實現(xiàn)的策略，我們可以根據(jù)效勞器的配置及需求在C++實現(xiàn)的策略高效和腳本的方便靈活上找到一個平衡點。在考察了各種腳本引擎的特點后，我們?yōu)楸鞠到y(tǒng)采用Lua語言作為它的策略腳本語言。4.2.1

對策略的封裝要讓Lua作為策略的腳本語言首先得完成對策略的封裝。在前面的設計局部已經(jīng)介紹了策略實現(xiàn)中需要提供的幾個接口。由于Lua的特性，可以在C++中很方便的調(diào)用Lua編寫的函數(shù)，所以可以在Lua策略腳本中，通過Lua函數(shù)的方式提供策略引擎所需要的OnRecv和OnSend接口。當策略引擎調(diào)用Lua策略時，會向Lua腳本中的OnRecv和OnSend函數(shù)傳遞client對象這個參數(shù)。我們需要將此對象封裝成Lua腳本能識別的形式。4.2.2

Lua策略腳本例如使用Lua語言編寫策略腳本非常簡單，下面是一段用來過濾SQL注入關鍵字的Lua策略腳本例如：warning_msg=[[

<html><head><meta-equiv="Content-Language"content="zh-">

<meta-equiv="Content-Type"content="te*t/html;charset=gb2312"><title>請你自重</title></head><bodybgcolor="*D6D3CE">

<p><b><fontsize="2">你的攻擊行為已經(jīng)被記錄</font></b></p><hr><p><b><fontsize="2"><spanlang="en-us">BY林海峰</span>所有</font></b></p></body></html>]]functionOnRecv(request)url=request:GetServerVariable("QUERY_STRING")Logger.Append("AntiSQLInject",url)ifCheckSqlKey(url)thenreturnResponse.SendMsg(request,"200OK",warning_msg);endendfunctionCheckSqlKey(str)

localtest_key={"and","or"}

str=string.lower(str)

fori,vinipairs(tes