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

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

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

引言

12

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

12.1

緩沖區(qū)溢出

12.2

SQL注入攻擊

12.3

基于腳本的DDos攻擊

22.4

其他的不平安因素

33

Web的入侵防御系統(tǒng)的設(shè)計(jì)

43.1

體系構(gòu)造

43.2

處理流程

53.3

對(duì)客戶(hù)端的響應(yīng)

73.4

策略引擎的設(shè)計(jì)

83.4.1

策略的屬性

83.4.2

策略的加載

93.4.3

策略的調(diào)度

103.4.4

策略的接口

104

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

114.1

基于ISAPI的解析及響應(yīng)模塊的實(shí)現(xiàn)

114.1.1

使用ISAPIFilter獲取報(bào)文信息

114.1.2

使用ISAPI進(jìn)展響應(yīng)

134.1.3

在效勞器上的安裝配置ISAPIFilter

144.2

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

154.2.1

對(duì)策略的封裝

154.2.2

Lua策略腳本例如

154.3

基于*ml的策略管理

165

系統(tǒng)運(yùn)行過(guò)程及測(cè)試

16結(jié)

論

18參考文獻(xiàn)

18致

謝

19聲

明

201

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

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

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

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

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

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

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

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

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

防止客戶(hù)端的快速刷新，可以通過(guò)Cookie或者Session來(lái)實(shí)現(xiàn)(2)

對(duì)消耗較大的頁(yè)面進(jìn)展識(shí)別碼認(rèn)證，確保是人而不是惡意的自動(dòng)化程序在這個(gè)頁(yè)面。(3)

限制每個(gè)客戶(hù)端的線(xiàn)程數(shù)2.4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

日志模塊日志模塊的作用是對(duì)系統(tǒng)運(yùn)行時(shí)產(chǎn)生的日志或?qū)θ肭址烙袨榈倪M(jìn)展記錄。使用統(tǒng)一的格式將日志信息記錄在文本文件中。由于系統(tǒng)采用分層的體系構(gòu)造，所以這一模塊可以方便的替換成其他格式的日志記錄方式。3.3

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

調(diào)度下一條策略這是策略的默認(rèn)響應(yīng)方式，策略引擎將為客戶(hù)端調(diào)度下一條策略。當(dāng)一個(gè)策略中沒(méi)有對(duì)客戶(hù)端的行為做出任何響應(yīng)，則策略引擎認(rèn)為該客戶(hù)端調(diào)用策略鏈上的下一條策略。(2)

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

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

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

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

重定向讓W(xué)ebServer重定向客戶(hù)端的。和前兩種響應(yīng)方式類(lèi)似，區(qū)別是客戶(hù)端會(huì)檢測(cè)到所的Url的發(fā)生跳轉(zhuǎn)。跳轉(zhuǎn)即可以是本效勞器的地址，也可以是外部效勞器的地址。當(dāng)策略引擎檢測(cè)到策略返回的是這種響應(yīng)方式后也會(huì)停頓調(diào)用策略鏈后面的其他策略3.4

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

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

策略的名稱(chēng)用來(lái)標(biāo)示不同的策略，在加載過(guò)程中，C++加載器通過(guò)此名稱(chēng)生成C++策略的對(duì)象。在屬性列表中這一條不能省略。(2)

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

類(lèi)型按類(lèi)型可以把策略分為系統(tǒng)策略和用戶(hù)策略。系統(tǒng)策略永遠(yuǎn)都是在用戶(hù)策略前面調(diào)度。這兩種不同類(lèi)別的策略都可以由C++的類(lèi)或者以腳本的方式實(shí)現(xiàn)。此屬性的作用是在增加策略?xún)?yōu)先級(jí)調(diào)度的粒度。可以在配置文件中設(shè)置此值(4)

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

開(kāi)啟狀態(tài)可以給策略的設(shè)置開(kāi)啟狀態(tài)：Enable和Disable，當(dāng)一個(gè)策略處于Disable狀態(tài)時(shí)，策略引擎會(huì)跳過(guò)對(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è)置為L(zhǎng)oaded。(7)

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

路徑記錄策略腳本的位置，加載時(shí)通過(guò)這個(gè)屬性找到相應(yīng)的策略文件的路徑。這個(gè)屬性只對(duì)腳本加載器有效。3.4.2

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

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

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

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

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

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

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

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

策略的調(diào)度策略對(duì)象中提供兩個(gè)接口供策略引擎調(diào)度，一個(gè)是OnRecv，另一個(gè)是OnSend。當(dāng)策略引擎是為檢測(cè)客戶(hù)端的信息而調(diào)動(dòng)策略時(shí)，都是調(diào)用的策略中的OnRecv接口，而當(dāng)策略引擎是為檢測(cè)效勞器發(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)度完，如果沒(méi)有任何策略響應(yīng)，則策略引擎返回一個(gè)“承受請(qǐng)求〞的響應(yīng)。3.4.4

策略的接口(1)

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

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

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

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

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

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

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

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

FilterProc當(dāng)對(duì)應(yīng)的事件發(fā)生時(shí)，效勞器通過(guò)調(diào)用ISAPIFilter的FilterProc入口點(diǎn)通知為該事件注冊(cè)的每個(gè)篩選器?？梢酝ㄟ^(guò)FilterProc以提供特殊的事件處理。當(dāng):FilterProc被調(diào)用時(shí)，接收到的通知將確定將要如何處理該事件。我們?cè)贕etFilterVersion中注冊(cè)了SF_NOTIFY_PREPROC_HEADERS事件，所以當(dāng)效勞器分析好客戶(hù)端所發(fā)送的報(bào)文頭時(shí)，將通知我們的ISAPIFilter處理該報(bào)文頭，并根據(jù)處理的結(jié)果進(jìn)展相應(yīng)的響應(yīng)。我們可以在FilterProc檢測(cè)當(dāng)SF_NOTIFY_PREPROC_HEADERS事件發(fā)生時(shí)便調(diào)用OnPreprocHeaders函數(shù)處理客戶(hù)端發(fā)送的報(bào)文頭。相關(guān)的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);我們?cè)贠nPreprocHeaders即可以獲得通過(guò)GetServerVariable函數(shù)就可以獲得客戶(hù)端發(fā)送的請(qǐng)求的報(bào)文頭部信息及效勞器的變量。在這里我們將封裝成一個(gè)IClient的對(duì)象。策略引擎會(huì)對(duì)不同的策略引擎把IClient重新封裝。4.1.2

使用ISAPI進(jìn)展響應(yīng)(1)

拒絕當(dāng)在ISAPIFilter中直接返回SF_STATUS_REQ_FINISHED時(shí)，IIS效勞器就會(huì)斷開(kāi)和客戶(hù)端的連接。(2)

發(fā)送信息發(fā)送信息的響應(yīng)中有兩個(gè)參數(shù)，一個(gè)是報(bào)文響應(yīng)的狀態(tài)，例如：狀態(tài)200表示正常；狀態(tài)403表示拒絕；狀態(tài)500表示效勞器錯(cuò)誤等等。另一個(gè)參數(shù)是所發(fā)送信息的內(nèi)容。通過(guò)ISAPIFilter中提供的ServerSupportFunctionAPI可以設(shè)置響應(yīng)的報(bào)文的狀態(tài)，通過(guò)WriteClient可以直接向客戶(hù)端寫(xiě)數(shù)據(jù)。以下為發(fā)送信息響應(yīng)方式的局部實(shí)現(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ā)送文件的實(shí)現(xiàn)和發(fā)送信息的實(shí)現(xiàn)類(lèi)似。第二個(gè)參數(shù)換成了要發(fā)送文件的路徑。發(fā)送的文件內(nèi)容從該路徑指定的文件中讀取。以下為發(fā)送文件響應(yīng)的實(shí)現(xiàn)的局部實(shí)現(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)

重定向?qū)⑿谄鞫隧憫?yīng)的報(bào)頭中的狀態(tài)碼設(shè)置為“302MovedPermanently〞，同時(shí)設(shè)置報(bào)頭中的Location為要轉(zhuǎn)向的地址?？蛻?hù)端的瀏覽器在收到這樣的報(bào)文后會(huì)重新去新的地址。重定向的局部實(shí)現(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)

翻開(kāi)IIS管理器(2)

展開(kāi)左側(cè)的目錄樹(shù)，選擇，單擊鼠標(biāo)右鍵，選擇屬性(3)

選擇ISAPI篩選器一欄(4)

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

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

4.2

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

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

Lua策略腳本例如使用Lua語(yǔ)言編寫(xiě)策略腳本非常簡(jiǎn)單，下面是一段用來(lái)過(guò)濾SQL注入關(guān)鍵字的Lua策略腳本例如：warning_msg=[[

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

<meta-equiv="Content-Type"content="te*t/html;charset=gb2312"><title>請(qǐng)你自重</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