誰是最佳選擇？

        Web應用防護無疑是一個熱門話題。由於技術的發展成熟和人們對便利性的期望越來越高，Web應用成為主流的業務系統載體。在Web上“安家”的關鍵業務系統中蘊藏的資料價值引起攻擊者的青睞，網上流傳的Web漏洞挖掘和攻擊工具讓攻擊的門檻降低，也使得很多攻擊帶有盲目和隨機性。比如利用GoogleHacking原理的批量查詢具有已知漏洞的應用程式，還有SQL批量注入和掛馬等。但對於重要的Web應用（比如運營商或金融），始終有受利益驅動的黑客進行持續的跟蹤。

如果說傳統的“大而全”安全防護產品能抵禦大多數由工具產生的攻擊行為，那麼對於有針對性的攻擊行為則力不從心。而WAF正是應需求而生的一款高階專業安全產品，這也是市場需求細化的必然趨勢。但由於其部署和功能方面與IPS有類似，有人提出疑問，為什麼不能用IPS，或者說WAF與IPS有什麼異同？誰更適合保護Web伺服器？

這些疑問其實是有道理的，差異化的產生在於高階需求是不同的，從而需要細化功能貼合具體需求和符合應用現狀的產品，這也是使用者需求是隨著業務自身的發展所決定的。

保鏢和保安

為了更好的理解兩款產品差異性，我們先用這個保鏢（WAF）和保安（IPS）比喻來描述。

大樓保安需要對所有進出大樓人員進行檢查，一旦發現可疑人員則禁止他入內，但如果混進“貌似忠良”的壞人去撬保險櫃等破壞行為，大樓保安是無能為力的。

私人保鏢則是指高級別、更“貼身”的保護。他通常只保護特定的人員，所以事先需要理解被保護人的身份、習慣、喜好、作息、弱點等，因為被保護人的工作是需要去面對不同的人，去不同的場合，保鏢的職責不能因為危險就阻止、改變他的行為，只能去預見可能的風險，然後量身定做合適的保護方案。

這兩種角色的區別在於保安保護的是整個大樓，他不需要也無法知道誰是最需要保護的人，保鏢則是明確了被保護物件名單，需要深刻理解被保護人的個性特點。

圖 1.1 保鏢和保安

通過上面的比喻，大家應該明白兩者的之所以會感覺相似是因為職責都是去保護，但差異在於職能定位的不同。從技術原理上則會根據定位來實現。下面通過幾個層面來分析WAF和IPS的異同。

事件的時間軸

對於安全事件的發生，有三個時間點：事前、事中、事後。傳統的IPS通常只對事中有效，也就是檢查和防護攻擊事件，其他兩個時間點是WAF獨有的。

圖 1.2 事件時間軸

如上圖所示，事前是指能在事件發生之前通過主動掃描檢測Web伺服器來發現漏洞，通過修復Web伺服器漏洞或在前端的防護裝置上新增防護規則等積極主動手段來預防事件發生。事後則是指即使Web伺服器被攻擊了，也必須有網頁防篡改功能，讓攻擊者不能破壞網站資料。

為什麼不能具備事中的100%防護能力？其實從以下幾個方面就知道對於事中只能做到相對最佳防護而不能絕對，因為：

1. 軟體先天是有缺陷的，包括應用到第三方的元件和函式庫無法控制其安全性；

2. 應用程式在更新，業務是持續發展的、動態的，如果不持續監控和調整安全策略，也是會有疏漏的；

3. 攻擊者永遠在暗處，可以對業務系統跟蹤研究，查詢漏洞和防護缺陷，用各種變形繁雜的手法來探測，並用於攻擊；

4. 任何防護裝置都難以100%做到沒有任何缺陷，無論是各種演算法還是規則，都是把攻擊影響降低到最小化。

所以需要用一個可閉環又可迴圈的方式去降低潛在的威脅，對於事中疏漏的攻擊，可用事前的預發現和事後的彌補，形成環環相扣的動態安全防護。事前是用掃描方式主動檢查網站並把結果形成新的防護規則增加到事中的防護策略中，而事後的防篡改可以保證即使疏漏也讓攻擊的步伐止於此，不能進一步修改和損壞網站檔案，對於要信譽高和完整性的使用者來說，這是尤為重要的環節。

圖 1.3 WAF安全閉環

如果僅僅是對於事件的時間軸有區別，那麼還是可以採用其他產品來進行輔助，但關鍵的是事中的防護也是有深度的差異，那麼下面我們來談談對於事中的差異。

事中，也就是實時防護，兩者的區別在於一個是縱橫度，一個是深度。IPS凸顯的優勢在於縱橫度，也就是對於網路中的所有流量進行監管，它面對的是海量資料，下圖的TCP/IP模型中網路流量從物理層到應用層是逐層遞交，IPS主要定位在分析傳輸層和網路層的資料，而再往上則是複雜的各種應用層協議報文，WAF則僅提供對Web應用流量全部層面的監管。　

圖 1.4 資料結構圖

監管層面不同，如果面對同樣的攻擊，比如SQL注入，它們都是可以防護的，但防護的原理有區別，IPS基本是依靠靜態的簽名進行識別，也就是攻擊特徵，這只是一種被動安全模型。如下是一個Snort的告警規則：

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注入中提交的元字元，包括單引號（ ’ ）和雙橫（ – ），從而避免注入’1 or 1=1— 之類的攻擊發生，但同時又要考慮這些元字元轉換成Hex值來逃脫過濾檢查，於是又在規則裡增加了其對應的十六進位制編碼後的字串。

當然，要從簽名特徵來識別攻擊要考慮的東西還很多，不僅元字元還有SQL關鍵字，包括：select insert update等，以及這些關鍵字的大小寫變形和拼接，利用註釋逃脫過濾，如下所示例：

使用大小寫混雜的字元 ：SeLecT fRom“

把空格符替換為TAB符或回車符 ：select[TAB]from

關鍵詞之間使用多個空格 ：select from

字串的數值編碼 ：0×414141414141 或 0×41004100410041004100

插入被資料庫忽略的註釋串 ：sel/**/ect fr/**/om select/**/ from

使用資料庫支援的一些字串轉換功能 ：char（65） 或 chr（65）

使用資料支援的字串拼接操作 ：’sel’+'ect ’+'fr’+'om’” 、“‘sel’||’ect ’||’fr’||’om’可以設想一下，如果要檢測以上的變形字元後的攻擊則需要增加相應的簽名特徵，但更重要的是要充分考慮轉換編碼的種類，上面示例的snort的規則把可疑字元以及其轉換後的Hex值放入同一條規則裡檢查，如果對於變形後繁多的攻擊種類，這是滯後的並且會造成簽名臃腫。

對於比較粗淺的攻擊方式兩者都能防護，但市面上大多數IPS是無法對報文編碼做多重轉換的，所以這將導致攻擊者只需構建諸如轉換編碼、拼接攻擊語句、大小寫變換等資料包就可繞過輸入檢查而直接提交給應用程式。

而這恰恰又是WAF的優勢，能對不同的編碼方式做強制多重轉換還原成攻擊明文，把變形後的字元組合後在分析。那為什麼IPS不能做到這個程度？同樣還有對於HTTPS的加密和解密，這些我們在下節的產品架構中會解釋。

產品架構

大家知道IPS和WAF通常是串聯部署在Web伺服器前端，對於伺服器和客戶端都是透明的，不需要做任何配置，似乎都是一樣的組網方式，其實有很大差異。首先我們看看市面主流WAF支援的部署方式：

1、 橋模式

2、 路由模式

3、反向代理

4、旁路模式（非串聯）

這兩者串聯部署在Web伺服器前端時，市面上的大多數IPS均採用橋模式，而WAF是採用反向代理模式，IPS需要處理網路中所有的流量，而WAF僅處理與Web應用相關的協議，其他的給予轉發，如下圖：　

圖 1.5 多協議圖

橋模式和反向代理模式的差異在於：橋模式是基於網路層的包轉發，基本都沒有協議棧，或只能簡單的模擬部分協議棧，分析網路報文流量是基於單包的方式，所以要處理分片報文、資料流重組、亂序報文、報文重傳、丟包都不具備優勢。同時網路流量中包括的協議種類是非常多的，每種應用層協議都有自身獨特的協議特徵和格式要求，比如Ftp、SSH、Telnet、SMTP等，無法把各種應用流量放到應用層協議棧來處理。

綠盟科技WAF系統內嵌的協議棧是經過修改和優化的，能完全支援Http應用協議的處理，這意味著必須遵循RFC標準（Internet Requests For Comments）來處理Http報文，包括如下主要RFC：

◆ RFC 2616 HTTP協議語法的定義

◆ RFC 2396 URL語法的定義

◆ RFC 2109 Cookie是怎樣工作的

◆ RFC 1867 HTTP如何POST，以及POST的格式

RFC中對Http的request行長度、URL長度、協議名稱長度、頭部值長度等都是有嚴格要求的，以及傳輸順序和應用格式，比如Html引數的要求、Cookie的版本和格式、檔案上傳的編碼 multipart/form-data encoding等，這些應用層內容只能在具有完整應用層協議棧的前提下才可正確識別和控制，對於不完整的丟包，重傳包以及偽造的畸形包都會通過協議校驗機制來處理。

上一節提到的WAF對Https的加解密和多重編碼方式的解碼正是由於報文必須經過應用層協議棧處理。反之，IPS為什麼做不到？是由於其自身的橋模式架構，把Http會話”打碎“成多個數據包在網路層分析，而不能完整地從應用層角度來處理和組合多個報文，並且應用層協議繁多，全部去支援也是不現實的，產品的定位並不需要這樣。下一節的學習模式更是兩者的截然不同的防護機制，而這一機制也是有賴於WAF的產品架構。

基於學習的主動模式

在前面談到IPS的安全模型是應用了靜態簽名的被動模式，那麼反之就是主動模式。WAF的防禦模型是兩者都支援的，所謂主動模式在於WAF是一個有效驗證輸入的裝置，所有資料流都被校驗後再轉發給伺服器，能增加應用層邏輯組合的規則，更重要的是具備對Web應用程式的主動學習功能。

學習功能包括：

1. 監控和學習進出的Web流量，學習連結引數型別和長度、form引數型別和長度等；

2. 爬蟲功能，爬蟲主動去分析整個Web站點，並建立正常狀態模型；

3. 掃描功能，主動去掃描並根據結果生成防護規則。

基於學習的主動模式目的是為了建立一個安全防護模型，一旦行為有差異則可以發現，比如隱藏的表單、限制型的Listbox值是否被篡改、輸入的引數型別不合法等，這樣在面對多變的攻擊手法和未知的攻擊型別時能依靠安全防護模型動態調整防護策略。

結尾

WAF更多的特性，包括安全交付能力、基於cache的應用加速、掛馬檢查、抗DDOS攻擊、符合PCIDSS的防洩密要求等都表明這是一款不僅能攻擊防護，同時又必須在滿足客戶體驗和機密資料防護的高度整合的專業產品。本文僅從產品特徵的對比角度來分析了WAF的部分技術原理，但沒否定IPS的價值，畢竟兩者在部署場景和功能上具有很大差異。