誰(shuí)是最佳選擇？
Web應(yīng)用防護(hù)無(wú)疑是一個(gè)熱門話題。由于技術(shù)的發(fā)展成熟和人們對(duì)便利性的期望越來(lái)越高，Web應(yīng)用成為主流的業(yè)務(wù)系統(tǒng)載體。在Web上“安家”的關(guān)鍵業(yè)務(wù)系統(tǒng)中蘊(yùn)藏的數(shù)據(jù)價(jià)值引起攻擊者的青睞，網(wǎng)上流傳的Web漏洞挖掘和攻擊工具讓攻擊的門檻降低，也使得很多攻擊帶有盲目和隨機(jī)性。比如利用GoogleHacking原理的批量查找具有已知漏洞的應(yīng)用程序，還有SQL批量注入和掛馬等。但對(duì)于重要的Web應(yīng)用（比如運(yùn)營(yíng)商或金融），始終有受利益驅(qū)動(dòng)的黑客進(jìn)行持續(xù)的跟蹤。
如果說(shuō)傳統(tǒng)的“大而全”安全防護(hù)產(chǎn)品能抵御大多數(shù)由工具產(chǎn)生的攻擊行為，那么對(duì)于有針對(duì)性的攻擊行為則力不從心。而WAF正是應(yīng)需求而生的一款高端專業(yè)安全產(chǎn)品，這也是市場(chǎng)需求細(xì)化的必然趨勢(shì)。但由于其部署和功能方面與IPS有類似，有人提出疑問(wèn)，為什么不能用IPS，或者說(shuō)WAF與IPS有什么異同？誰(shuí)更適合保護(hù)Web服務(wù)器？
這些疑問(wèn)其實(shí)是有道理的，差異化的產(chǎn)生在于高端需求是不同的，從而需要細(xì)化功能貼合具體需求和符合應(yīng)用現(xiàn)狀的產(chǎn)品，這也是用戶需求是隨著業(yè)務(wù)自身的發(fā)展所決定的。
保鏢和保安
為了更好的理解兩款產(chǎn)品差異性，我們先用這個(gè)保鏢（WAF）和保安（IPS）比喻來(lái)描述。
大樓保安需要對(duì)所有進(jìn)出大樓人員進(jìn)行檢查，一旦發(fā)現(xiàn)可疑人員則禁止他入內(nèi)，但如果混進(jìn)“貌似忠良”的壞人去撬保險(xiǎn)柜等破壞行為，大樓保安是無(wú)能為力的。
私人保鏢則是指高級(jí)別、更“貼身”的保護(hù)。他通常只保護(hù)特定的人員，所以事先需要理解被保護(hù)人的身份、習(xí)慣、喜好、作息、弱點(diǎn)等，因?yàn)楸槐Ｗo(hù)人的工作是需要去面對(duì)不同的人，去不同的場(chǎng)合，保鏢的職責(zé)不能因?yàn)槲ｋU(xiǎn)就阻止、改變他的行為，只能去預(yù)見(jiàn)可能的風(fēng)險(xiǎn)，然后量身定做合適的保護(hù)方案。
這兩種角色的區(qū)別在于保安保護(hù)的是整個(gè)大樓，他不需要也無(wú)法知道誰(shuí)是最需要保護(hù)的人，保鏢則是明確了被保護(hù)對(duì)象名單，需要深刻理解被保護(hù)人的個(gè)性特點(diǎn)。
圖 1.1 保鏢和保安
通過(guò)上面的比喻，大家應(yīng)該明白兩者的之所以會(huì)感覺(jué)相似是因?yàn)槁氊?zé)都是去保護(hù)，但差異在于職能定位的不同。從技術(shù)原理上則會(huì)根據(jù)定位來(lái)實(shí)現(xiàn)。下面通過(guò)幾個(gè)層面來(lái)分析WAF和IPS的異同。
事件的時(shí)間軸
對(duì)于安全事件的發(fā)生，有三個(gè)時(shí)間點(diǎn)：事前、事中、事后。傳統(tǒng)的IPS通常只對(duì)事中有效，也就是檢查和防護(hù)攻擊事件，其他兩個(gè)時(shí)間點(diǎn)是WAF獨(dú)有的。
圖 1.2 事件時(shí)間軸
如上圖所示，事前是指能在事件發(fā)生之前通過(guò)主動(dòng)掃描檢測(cè)Web服務(wù)器來(lái)發(fā)現(xiàn)漏洞，通過(guò)修復(fù)Web服務(wù)器漏洞或在前端的防護(hù)設(shè)備上添加防護(hù)規(guī)則等積極主動(dòng)手段來(lái)預(yù)防事件發(fā)生。事后則是指即使Web服務(wù)器被攻擊了，也必須有網(wǎng)頁(yè)防篡改功能，讓攻擊者不能破壞網(wǎng)站數(shù)據(jù)。
為什么不能具備事中的100%防護(hù)能力？其實(shí)從以下幾個(gè)方面就知道對(duì)于事中只能做到相對(duì)最佳防護(hù)而不能絕對(duì)，因?yàn)椋?div style="height:15px;">
1. 軟件先天是有缺陷的，包括應(yīng)用到第三方的組件和函數(shù)庫(kù)無(wú)法控制其安全性；
2. 應(yīng)用程序在更新，業(yè)務(wù)是持續(xù)發(fā)展的、動(dòng)態(tài)的，如果不持續(xù)監(jiān)控和調(diào)整安全策略，也是會(huì)有疏漏的；
3. 攻擊者永遠(yuǎn)在暗處，可以對(duì)業(yè)務(wù)系統(tǒng)跟蹤研究，查找漏洞和防護(hù)缺陷，用各種變形繁雜的手法來(lái)探測(cè)，并用于攻擊；
4. 任何防護(hù)設(shè)備都難以100%做到?jīng)]有任何缺陷，無(wú)論是各種算法還是規(guī)則，都是把攻擊影響降低到最小化。
所以需要用一個(gè)可閉環(huán)又可循環(huán)的方式去降低潛在的威脅，對(duì)于事中疏漏的攻擊，可用事前的預(yù)發(fā)現(xiàn)和事后的彌補(bǔ)，形成環(huán)環(huán)相扣的動(dòng)態(tài)安全防護(hù)。事前是用掃描方式主動(dòng)檢查網(wǎng)站并把結(jié)果形成新的防護(hù)規(guī)則增加到事中的防護(hù)策略中，而事后的防篡改可以保證即使疏漏也讓攻擊的步伐止于此，不能進(jìn)一步修改和損壞網(wǎng)站文件，對(duì)于要信譽(yù)高和完整性的用戶來(lái)說(shuō)，這是尤為重要的環(huán)節(jié)。
圖 1.3 WAF安全閉環(huán)
如果僅僅是對(duì)于事件的時(shí)間軸有區(qū)別，那么還是可以采用其他產(chǎn)品來(lái)進(jìn)行輔助，但關(guān)鍵的是事中的防護(hù)也是有深度的差異，那么下面我們來(lái)談?wù)剬?duì)于事中的差異。
事中，也就是實(shí)時(shí)防護(hù)，兩者的區(qū)別在于一個(gè)是縱橫度，一個(gè)是深度。IPS凸顯的優(yōu)勢(shì)在于縱橫度，也就是對(duì)于網(wǎng)絡(luò)中的所有流量進(jìn)行監(jiān)管，它面對(duì)的是海量數(shù)據(jù)，下圖的TCP/IP模型中網(wǎng)絡(luò)流量從物理層到應(yīng)用層是逐層遞交，IPS主要定位在分析傳輸層和網(wǎng)絡(luò)層的數(shù)據(jù)，而再往上則是復(fù)雜的各種應(yīng)用層協(xié)議報(bào)文，WAF則僅提供對(duì)Web應(yīng)用流量全部層面的監(jiān)管。
圖 1.4 數(shù)據(jù)結(jié)構(gòu)圖
監(jiān)管層面不同，如果面對(duì)同樣的攻擊，比如SQL注入，它們都是可以防護(hù)的，但防護(hù)的原理有區(qū)別，IPS基本是依靠靜態(tài)的簽名進(jìn)行識(shí)別，也就是攻擊特征，這只是一種被動(dòng)安全模型。如下是一個(gè)Snort的告警規(guī)則：
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS （msg:“SQL Injection - Paranoid”; flow:to_server, established;uricontent:“.asp”;pcre:“/ （\%27）|（\‘）|（\-\-）|（%23）|（#）/i”; classtype:Web-application-attack; sid:9099; rev:5;）
這里主要是檢查在SQL注入中提交的元字符，包括單引號(hào)（ ' ）和雙橫（ -- ），從而避免注入'1 or 1=1— 之類的攻擊發(fā)生，但同時(shí)又要考慮這些元字符轉(zhuǎn)換成Hex值來(lái)逃脫過(guò)濾檢查，于是又在規(guī)則里增加了其對(duì)應(yīng)的十六進(jìn)制編碼后的字符串。
當(dāng)然，要從簽名特征來(lái)識(shí)別攻擊要考慮的東西還很多，不僅元字符還有SQL關(guān)鍵字，包括：select insert update等，以及這些關(guān)鍵字的大小寫(xiě)變形和拼接，利用注釋逃脫過(guò)濾，如下所示例：
使用大小寫(xiě)混雜的字符 ：SeLecT fRom“
把空格符替換為TAB符或回車符 ：select[TAB]from
關(guān)鍵詞之間使用多個(gè)空格 ：select from
字符串的數(shù)值編碼 ：0x414141414141 或 0x41004100410041004100
插入被數(shù)據(jù)庫(kù)忽略的注釋串 ：sel/**/ect fr/**/om select/**/ from
使用數(shù)據(jù)庫(kù)支持的一些字符串轉(zhuǎn)換功能 ：char（65） 或 chr（65）
使用數(shù)據(jù)支持的字符串拼接操作 ：'sel'+'ect '+'fr'+'om’” 、“‘sel'||'ect '||'fr'||'om'可以設(shè)想一下，如果要檢測(cè)以上的變形字符后的攻擊則需要增加相應(yīng)的簽名特征，但更重要的是要充分考慮轉(zhuǎn)換編碼的種類，上面示例的snort的規(guī)則把可疑字符以及其轉(zhuǎn)換后的Hex值放入同一條規(guī)則里檢查，如果對(duì)于變形后繁多的攻擊種類，這是滯后的并且會(huì)造成簽名臃腫。
對(duì)于比較粗淺的攻擊方式兩者都能防護(hù)，但市面上大多數(shù)IPS是無(wú)法對(duì)報(bào)文編碼做多重轉(zhuǎn)換的，所以這將導(dǎo)致攻擊者只需構(gòu)建諸如轉(zhuǎn)換編碼、拼接攻擊語(yǔ)句、大小寫(xiě)變換等數(shù)據(jù)包就可繞過(guò)輸入檢查而直接提交給應(yīng)用程序。
而這恰恰又是WAF的優(yōu)勢(shì)，能對(duì)不同的編碼方式做強(qiáng)制多重轉(zhuǎn)換還原成攻擊明文，把變形后的字符組合后在分析。那為什么IPS不能做到這個(gè)程度？同樣還有對(duì)于HTTPS的加密和解密，這些我們?cè)谙鹿?jié)的產(chǎn)品架構(gòu)中會(huì)解釋。
產(chǎn)品架構(gòu)
大家知道IPS和WAF通常是串聯(lián)部署在Web服務(wù)器前端，對(duì)于服務(wù)器和客戶端都是透明的，不需要做任何配置，似乎都是一樣的組網(wǎng)方式，其實(shí)有很大差異。首先我們看看市面主流WAF支持的部署方式：
l 橋模式
l 路由模式
l 反向代理
l 旁路模式（非串聯(lián)）
這兩者串聯(lián)部署在Web服務(wù)器前端時(shí)，市面上的大多數(shù)IPS均采用橋模式，而WAF是采用反向代理模式，IPS需要處理網(wǎng)絡(luò)中所有的流量，而WAF僅處理與Web應(yīng)用相關(guān)的協(xié)議，其他的給予轉(zhuǎn)發(fā)，如下圖：
圖 1.5 多協(xié)議圖
橋模式和反向代理模式的差異在于：橋模式是基于網(wǎng)絡(luò)層的包轉(zhuǎn)發(fā)，基本都沒(méi)有協(xié)議棧，或只能簡(jiǎn)單的模擬部分協(xié)議棧，分析網(wǎng)絡(luò)報(bào)文流量是基于單包的方式，所以要處理分片報(bào)文、數(shù)據(jù)流重組、亂序報(bào)文、報(bào)文重傳、丟包都不具備優(yōu)勢(shì)。同時(shí)網(wǎng)絡(luò)流量中包括的協(xié)議種類是非常多的，每種應(yīng)用層協(xié)議都有自身獨(dú)特的協(xié)議特征和格式要求，比如Ftp、SSH、Telnet、SMTP等，無(wú)法把各種應(yīng)用流量放到應(yīng)用層協(xié)議棧來(lái)處理。
綠盟科技WAF系統(tǒng)內(nèi)嵌的協(xié)議棧是經(jīng)過(guò)修改和優(yōu)化的，能完全支持Http應(yīng)用協(xié)議的處理，這意味著必須遵循RFC標(biāo)準(zhǔn)（Internet Requests For Comments）來(lái)處理Http報(bào)文，包括如下主要RFC：
l RFC 2616 HTTP協(xié)議語(yǔ)法的定義
l RFC 2396 URL語(yǔ)法的定義
l RFC 2109 Cookie是怎樣工作的
l RFC 1867 HTTP如何POST，以及POST的格式
RFC中對(duì)Http的request行長(zhǎng)度、URL長(zhǎng)度、協(xié)議名稱長(zhǎng)度、頭部值長(zhǎng)度等都是有嚴(yán)格要求的，以及傳輸順序和應(yīng)用格式，比如Html參數(shù)的要求、Cookie的版本和格式、文件上傳的編碼 multipart/form-data encoding等，這些應(yīng)用層內(nèi)容只能在具有完整應(yīng)用層協(xié)議棧的前提下才可正確識(shí)別和控制，對(duì)于不完整的丟包，重傳包以及偽造的畸形包都會(huì)通過(guò)協(xié)議校驗(yàn)機(jī)制來(lái)處理。
上一節(jié)提到的WAF對(duì)Https的加解密和多重編碼方式的解碼正是由于報(bào)文必須經(jīng)過(guò)應(yīng)用層協(xié)議棧處理。反之，IPS為什么做不到？是由于其自身的橋模式架構(gòu)，把Http會(huì)話”打碎“成多個(gè)數(shù)據(jù)包在網(wǎng)絡(luò)層分析，而不能完整地從應(yīng)用層角度來(lái)處理和組合多個(gè)報(bào)文，并且應(yīng)用層協(xié)議繁多，全部去支持也是不現(xiàn)實(shí)的，產(chǎn)品的定位并不需要這樣。下一節(jié)的學(xué)習(xí)模式更是兩者的截然不同的防護(hù)機(jī)制，而這一機(jī)制也是有賴于WAF的產(chǎn)品架構(gòu)。
基于學(xué)習(xí)的主動(dòng)模式
在前面談到IPS的安全模型是應(yīng)用了靜態(tài)簽名的被動(dòng)模式，那么反之就是主動(dòng)模式。WAF的防御模型是兩者都支持的，所謂主動(dòng)模式在于WAF是一個(gè)有效驗(yàn)證輸入的設(shè)備，所有數(shù)據(jù)流都被校驗(yàn)后再轉(zhuǎn)發(fā)給服務(wù)器，能增加應(yīng)用層邏輯組合的規(guī)則，更重要的是具備對(duì)Web應(yīng)用程序的主動(dòng)學(xué)習(xí)功能。
學(xué)習(xí)功能包括：
1. 監(jiān)控和學(xué)習(xí)進(jìn)出的Web流量，學(xué)習(xí)鏈接參數(shù)類型和長(zhǎng)度、form參數(shù)類型和長(zhǎng)度等；
2. 爬蟲(chóng)功能，爬蟲(chóng)主動(dòng)去分析整個(gè)Web站點(diǎn)，并建立正常狀態(tài)模型；
3. 掃描功能，主動(dòng)去掃描并根據(jù)結(jié)果生成防護(hù)規(guī)則。
基于學(xué)習(xí)的主動(dòng)模式目的是為了建立一個(gè)安全防護(hù)模型，一旦行為有差異則可以發(fā)現(xiàn)，比如隱藏的表單、限制型的Listbox值是否被篡改、輸入的參數(shù)類型不合法等，這樣在面對(duì)多變的攻擊手法和未知的攻擊類型時(shí)能依靠安全防護(hù)模型動(dòng)態(tài)調(diào)整防護(hù)策略。
結(jié)尾
WAF更多的特性，包括安全交付能力、基于cache的應(yīng)用加速、掛馬檢查、抗DDOS攻擊、符合PCIDSS的防泄密要求等都表明這是一款不僅能攻擊防護(hù)，同時(shí)又必須在滿足客戶體驗(yàn)和機(jī)密數(shù)據(jù)防護(hù)的高度集成的專業(yè)產(chǎn)品。本文僅從產(chǎn)品特征的對(duì)比角度來(lái)分析了WAF的部分技術(shù)原理，但沒(méi)否定IPS的價(jià)值，畢竟兩者在部署場(chǎng)景和功能上具有很大差異。
本文轉(zhuǎn)自綠盟科技的技術(shù)月刊
