ips和waf功能介紹
入侵防御系統簡介
Intrusion Prevention System：IPS
位于防火墻和網絡的設備之間，依靠對數據包的檢測進行防御(檢查入網的數據包，確定數據包的真正用途，然后決定是否允許其進入內網)。
能夠監視網絡或網絡設備的網絡資料傳輸行為的計算機網絡安全設備，能夠及時的中斷、調整或隔離一些不正常或是具有傷害性的網絡資料傳輸行為。
防火墻可以攔截底層攻擊行為，但對應用層的深層攻擊行為無能為力。IPS是對防火墻的補充。
IPS是串行部署，部署后會對網絡造成一定的延時影響，因此，對網絡要求高的公司，可能會選擇部署IDS(IDS是旁路部署)。
當IPS出現故障，系統崩掉了，會自動啟用軟件Bypass，即此時不對所有的包進行檢測，也不對所有的包進行攔截，全部放過。
入侵防御系統功能
在ISO/OSI網絡層次模型中，防火墻主要在第二到第四層起作用，它的作用在第四到第七層一般很微弱。而防病毒軟件主要在第五到第七層起作用。
為了彌補防火墻和防病毒軟件二者在第四到第五層之間留下的空檔，幾年前，工業界已經有入侵檢測系統(IDS：Intrusion Detection System)投入使用。入侵檢測系統在發現異常情況后及時向網路安全管理人員或防火墻系統發出警報?？上н@時災害往往已經形成。雖然，亡羊補牢，猶未為晚，但是，防衛機制最好應該是在危害形成之前先期起作用。
隨后應運而生的入侵響應系統(IRS：Intrusion Response Systems)作為對入侵檢測系統的補充能夠在發現入侵時，迅速作出反應，并自動采取阻止措施。而入侵防御系統則作為二者的進一步發展，汲取了二者的長處。
WAF功能介紹
WAF全稱叫Web Application Firewall，和傳統防火墻的區別是，它是工作在應用層的防火墻，主要對web請求/響應進行防護。那么WAF有什么功能呢?
防火墻都是防御性的產品，有防就有攻，要了解WAF有什么功能，就要從攻擊者的角度去思考。
攻擊的目的要么是為了利益，要么是為了炫技。目前攻擊者大多都是悶聲發大財，很少會為了炫技而惹上麻煩。那么，攻擊目標越大，越有價值。
一個攻擊者的目標由大到小，往往是這樣 ：
全網
網絡上某一主機
某一主機的數據庫
某一主機WEB系統的管理員
某一主機WEB系統其它用戶
假設一個WEB網絡大致如下，圖中為目前能得到僅有信息，下文會一步步完善。
WEB服務器與瀏覽器之間已經用傳統防火墻防護起來，也就是說，對http://www.a.com進行端口掃描之類的攻擊行為已經沒用了。攻擊者可以通過下面步驟來得到這個網絡的信息：
1)通過OPTIONS,TRACE方法來探測里面的拓撲。如果webserver支持并允許這兩個方法，通過檢查響應包的Via或Max-forwards字段，可以得到各個節點的域名。
2)通過檢查響應包的Server字段或X-Powered-By字段來確定各個節點的http服務器軟件版本和腳本語言解釋器版本。同時由第一步得到的域名，也可以到相應域名注冊網站(如站長之家)上查找IP。而且有時候，由于網絡管理員的疏忽，通向其它節點的路徑并沒有禁止端口掃描，那樣通過端口掃描，可以得到系統信息，如操作系統類型，版本，開啟了什么服務。然后在CVE上查詢相應版本漏洞和exploit-db上下載相應的payload來攻擊，獲取主機的控制權。
3)如果第二步不奏效，也可以通過HTTP的OPTIONS方法來獲取網站支持的方法，比如允許DELETE方法，或者PUT方法，那么攻擊者可以上傳一個腳本獲取整個站點的源代碼和數據庫數據甚至獲取整個站點所有主機的權限，或者把認證的腳本給刪除。
4)如果第三步也不奏效，攻擊者可能就會掃描所有網頁，看是否存在文件路徑遍歷，文件包含注入，API注入，命令注入之類的漏洞，來獲取整個站點的系統信息甚至獲取webshell。
5)如果第四步也不奏效，繼續掃描所有頁面，看是否有sql注入的漏洞，看能否獲取站點的數據庫數據或是否可通過數據庫執行系統命令，獲取主機權限。
6)如果第五步也不奏效，只能看有沒有XSS，url注入等漏洞，能否騙到其它合法用戶的權限?；蛘呖茨芊裆蟼鲪阂馕募?/p>
再思考多一點，如果攻擊者并沒有打算攻陷a.com或從它偷取數據，而是頻繁向a.com發送消耗大量資源的請求，比如請求會使用大量數據庫查詢的接口，或上傳大量文件，導致正常服務無法響應。這種方式叫做CC攻擊(ChallengeCollapsar)。
那么，WAF必須具備防護CC攻擊能力，也就是說，WAF具備限制對某些URI請求次數的能力和限制文件上傳功能的能力。
從性能角度來看，由于HTTP是應用層的協議，每次WAF都要解析它，會造成很大性能損耗。而對于某些經常發惡意請求的IP或進行CC攻擊的IP，如果能夠在網絡層就把它們攔截了，對WAF性能是有很大的提升。所以WAF還必須具備IP黑名單的能力。
有黑名單就有白名單，對于某些資源，如圖像，影音，css，js文件，WAF對它們應用規則，只會浪費計算資源和降低服務的響應速度，所以，需要把一些資源URL放在白名單里。
關于IP黑名單，再從安全運維角度來看，如果是IP黑名單是通過手工輸入，那么，當攻擊者使用IP池攻擊，可能會導致IP黑名單的防護攻擊失效。那么，如果WAF是支持動態黑名單，就可以很好解決這個問題。如果是由WAF本身產生黑名單，會對WAF性能有很大影響，所以WAF需要能夠對接實時計算平臺，由實時計算平臺產生黑名單回饋給WAF。那么WAF就必須支持與實時計算平臺對接的能力。
總體來說，WAF功能有如下：
禁止HTTP協議的非安全方法
偽裝Web服務的特征
防止API和命令注入
防止路徑遍歷和文件包含注入，對敏感的系統路徑進行保護
防止sql注入
防止XSS攻擊
防止網頁掛馬
防護CC攻擊
文件上傳的防護
動態IP黑名單
白名單
與實時計算平臺對接
誰是最佳選擇？
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應用流量全部層面的監管?！?/p>
圖 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的價值，畢竟兩者在部署場景和功能上具有很大差異。
浙公網安備 33010602011771號