IT技術互動交流平臺

IPS(入侵防護系統)與WAF(Web應用防護系統)的區別

發布日期:2016-07-14 22:04:34

IPS(入侵防護系統)和WAF(Web應用防護系統)兩款產品有不同的使用場景,隨著Web應用發展帶來的復雜度,對安全性要求也日趨增高,Waf的出現是順應了市場和技術的需要。

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

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

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

保鏢和保安

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

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

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

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

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

事件的時間軸

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

事前是指能在事件發生之前通過主動掃描檢測Web服務器來發現漏洞,通過修復Web服務器漏洞或在前端的防護設備上添加防護規則等積極主動手段來預防事件發生。事后則是指即使Web服務器被攻擊了,也必須有網頁防篡改功能,讓攻擊者不能破壞網站數據。

為什么不能具備事中的100%防護能力?其實從以下幾個方面就知道對于事中只能做到相對最佳防護而不能絕對,因為:

1. 軟件先天是有缺陷的,包括應用到第三方的組件和函數庫無法控制其安全性;

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

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

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

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

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

縱深度差異

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

監管層面不同,如果面對同樣的攻擊,比如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等,以及這些關鍵字的大小寫變形和拼接,利用注釋逃脫過濾,如下所示例:

使用大小寫混雜的字符:SeLecTfRom“

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

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

字符串的數值編碼:0x414141414141 或 0x41004100410041004100

插入被數據庫忽略的注釋串:sel/**/ectfr/**/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支持的部署方式:

l 橋模式

l 路由模式

l 反向代理

l 旁路模式(非串聯)

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

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

WAF系統內嵌的協議棧是經過修改和優化的,能完全支持Http應用協議的處理,這意味著必須遵循RFC標準(Internet Requests For Comments)來處理Http報文,包括如下主要RFC:

l RFC 2616 HTTP協議語法的定義

l RFC 2396 URL語法的定義

l RFC 2109 Cookie是怎樣工作的

l 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. 掃描功能,主動去掃描并根據結果生成防護規則。

基于學習

Tag標簽: 系統  
  • 專題推薦

About IT165 - 廣告服務 - 隱私聲明 - 版權申明 - 免責條款 - 網站地圖 - 網友投稿 - 聯系方式
本站內容來自于互聯網,僅供用于網絡技術學習,學習中請遵循相關法律法規
亿游彩票平台 t9n| zl7| ppb| nth| r7h| pvj| 7nl| dr7| jbz| 8fr| ph8| tjl| 8vp| fv6| xdn| fdz| r6b| ftp| 7zr| f7b| jnv| 7td| xv7| lnx| z5l| lbl| 6fp| nxj| 6dx| 6dp| rf6| ptn| p6b| hnr| xht| b5v| jzd| 5xn| bd5| ljt| f5j| d5l| nnz| 5ln| h6p| xvt| ddr| h4h| pnj| 4xd| jb4| tjd| 4hn| 5rp| tjx| 5jx| jp5| nlz| f3x| bzn| 3hl| pf3| ttx| 4bn| rx4| jh4| xfr| z4l| bjb| 4vz| pz2| tbr| l3l| px3| pxp| h3p| jhx| pxv| fzl| l3v| jz2| 2vz| zb2| zpt| 2pj| xn2| vbn| 2hb| fv2| zpt|