一、參考鏈接

? ? ? ??http://https://www.cnblogs.com/milantgh/p/3603127.html

? ? ? ? 1.1 內容

? ? ? ? ? ? ? ?對于安全事件的發(fā)生，有三個時間點:事前、事中、事后。傳統(tǒng)的IPS通常只對事中有效，也就是檢查和防護攻擊事件，其他兩個時間點是WAF獨有的。（這里用一下鏈接中的圖，謝謝）

? ? ? ? ? ? ? ?

? ? ? ? ? ? ? ?這里舉事中來說，事中，也就是實時防護，兩者的區(qū)別在于一個是縱橫度，一個是深度。IPS凸顯的優(yōu)勢在于縱橫度，也就是對于網絡中的所有流量進行監(jiān)控，它面對的是海量數(shù)據，下圖的TCP/IP模型中網絡流量從物理層到應用層是逐層遞交，IPS主要定位在分析傳輸層和網絡層的數(shù)據，而再往上則是負責的各種應用層協(xié)議報文，WAF則僅提供對Web應用流量全部層面的監(jiān)管。(再次用一下圖，謝謝)

? ? ? ? ? ? ??

? ? ? ? ? ? ? 監(jiān)管的層面不同，如果面對同樣的攻擊，比如SQL注入，它們都是可以防護的，但防護的原理有區(qū)別，IPS基本是依靠靜態(tài)的簽名進行識別，也就是攻擊特征，這只是一種被動安全模型。如下是一個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注入中提交的元字符，包括單引號(')和雙橫(-),從而避免注入'1 or 1=1-- 之類的攻擊發(fā)生，同時又要考慮這些元字符轉換成hex值來逃脫過濾檢查，于是又在規(guī)則里增加了其對應的十六進制編碼后的字符串。

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

? ? ? ? ? ? ? ? ?使用大小寫混雜的字符:SeLecT fRom"

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

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

? ? ? ? ? ? ? ? ?字符串的數(shù)值編碼:0x414141414141或0x41004100410041004100

? ? ? ? ? ? ? ? ?插入被數(shù)據庫忽略的注釋串:sel/**/ect fr/**/om select/**/ from

? ? ? ? ? ? ? ? ?使用數(shù)據庫支持的一些字符串轉換功能:char(65) 或chr(65)

? ? ? ? ? ? ? ? ?使用數(shù)據支持的字符串拼接操作:'sel'+'ect'+'fr'+'om'"、"'sel'||'ect\||'fr'||'om'可以設想一下，如果要檢測以上的變形字符后的攻擊則需要增加相應的簽名特征，但更重要的是要充分考慮轉換編碼的種類，上面示例的snort的規(guī)則把可疑字符以及其轉換后的Hex值放入同一條規(guī)則里檢查，如果對于變形后繁多的攻擊種類，這是滯后的并且會造成臃腫。

? ? ? ? ? ? ? ? ?對于比較粗淺的攻擊方式兩者都能防護，但市面上大多數(shù)IPS是無法對報文編碼做多重轉換的，所以這將導致攻擊者只需構建諸如轉換編碼、拼接攻擊語句、大小寫變換等數(shù)據包就可繞過輸入檢查而直接提交給應用程序。而這恰恰是WAF的優(yōu)勢，能對不同的編碼方式做強制多重轉換還原成攻擊明文，把變形后的字符組合后再分析。

? ? ? ? ? ? ? ? ?IPS和WAF通常是串聯(lián)部署在Web服務器前端，對于服務器和客戶端都是透明的，不需要做任何配置，似乎都是一樣的組網方式，其實有很大差異。首先我們看看市面主流WAF支持的部署方式:?

? ? ? ? ? ? ? ? ?a.橋模式? ? ? ? b.路由模式? ? ? ? ?c.反向代理? ? ? ? ?4.旁路模式(非串聯(lián))

? ? ? ? ? ? ? ? ?這兩者串聯(lián)部署在Web服務器前端時，市面上的大多數(shù)IPS均采用橋模式，而WAF是采用反向代理模式，IPS需要處理網絡中所有的流量，而WAF僅處理與Web應用相關的協(xié)議，其他的給予轉發(fā)，如下圖:

? ? ? ? ? ? ? ? ??

? ? ? ? ? ? ? ? ? ?橋模式和反向代理模式的差異在于:橋模式是基于網絡層的包轉發(fā)，基本都沒有協(xié)議棧，或只能簡單的模擬部分協(xié)議棧，分析網絡報文流量是基于單包的方式，所以要處理分片報文、數(shù)據流重組、亂序報文、報文重傳、丟包都不具備優(yōu)勢。同時網絡流量中包括的協(xié)議種類是非常多的，每種應用層協(xié)議都有自身獨特的協(xié)議特征和格式要求，比如Ftp、SSH、Telnet、SMTP等，無法把各種應用流量放到應用層協(xié)議棧來處理。

? ? ? ? ? ? ? ? ? ?綠盟科技WAF系統(tǒng)內嵌的協(xié)議棧是經過修改和優(yōu)化的，能完全支持Http應用協(xié)議的處理，這意味著必須遵循RFC標準來處理Http報文，包括如下主要RFC:

? ? ? ? ? ? ? ? ? ?a.RFC 2616 HTTP協(xié)議語法的定義? ? ? ? b.RFC 2396 URL語法的定義? ? ? ? ?c.RFC 2109 Cookie是怎樣工作的? ? ?d.RFC 1867 HTTP如何POST,以及POST的格式

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

? ? ? ? ? ? ? ? ? ?WAF對https的加解密和多重編碼方式的解碼正是由于報文必須經過應用層協(xié)議處理。IPS由于其自身的橋模式架構，把HTTP會話"打碎"成多個數(shù)據包在網絡層分析，而不能完整地從應用層角度來處理和組合多個報文，并且應用層協(xié)議繁多，全部去支持也是不現(xiàn)實的，產品的定位并不需要這樣。

? ? ? ? ? ? ? ? ? ? 在前面談到IPS的安全模式是應用了靜態(tài)簽名的被動模式，那么反之就是主動模式。WAF的防御模式是兩者都支持的，所謂主動模式在于WAF是一個有效驗證輸入的設備，所有數(shù)據流都被校驗后再轉發(fā)給服務器，能增加應用層邏輯組合的規(guī)則，更重要的是具備對Web應用程序的主動學習功能。

? ? ? ? ? ? ? ? ? ? 學習功能包括:

? ? ? ? ? ? ? ? ? ? a)監(jiān)控和學習進出的Web流量，學習鏈接參數(shù)類型和長度、form參數(shù)類型和長度等;

? ? ? ? ? ? ? ? ? ? b)爬蟲功能，爬蟲主動去分析整個Web站點，并建立正常狀態(tài)模型;

? ? ? ? ? ? ? ? ? ? c)掃描功能，主動去掃描并根據結果生成防護規(guī)則。

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

? ? ? ? ? ? ? ? ? ? WAF更多的特性，包括安全交付能力、基于cache的應用加速、掛馬檢查、防DDOS攻擊、符合PCIDSS的防泄密要求等都表明這是一款不僅能攻擊防護，同時又必須在滿足客戶體驗和機密數(shù)據防護的高度集成的專業(yè)產品。

? ? ? ? ? ? ? ? ? ?

? ? ? ? ??

總結

以上是生活随笔為你收集整理的读WAF与IPS的区别总结之摘抄的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。