https://newera17031.activehosted.com/index.php?action=social&chash=a60937eba57758ed45b6d3e91e8659f3.2219&nosocial=1
https://newera17031.activehosted.com/index.php?action=social&chash=a60937eba57758ed45b6d3e91e8659f3.2219&nosocial=1

觀點

試玉要燒三日滿 辨材須待七年期(下)

2009 / 08 / 24
編輯部
試玉要燒三日滿  辨材須待七年期(下)

繼上期的內容,本期將繼續針對幾個重要的入侵防禦系統重要功能項深入探討。

變造的攻擊也要能準確的阻擋


  1998年春天,Thomas H. Ptacek 和 Timothy N.Newsham發表了「Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection」這篇文章,裡頭詳述了怎麼利用不同作業系統間TCP/IP堆疊的實作差異,達到愚弄IDS的目的。作者實測當時火紅的四款IDS,結果沒有一家IDS能夠成功的通過測試。因為當時的IDS主要還是對每個封包單純的作字串比對,就算有IP Fragment重組的機制,但也不會考慮到當Fragment重疊的時候,不同的作業系統對新舊Fragment的取捨。以Snort來說,第四層TCP Segment的重組(Reassembly)也是直到2001年才有的功能。而且就算能處理TCP Segment Reassembly,對於不同系統之間對新舊Segment的取捨(Favour-Old, Favour-New, ?如圖1)也要處理得好,在當時來說還算是高超的技巧。所以在NSS 2001年的IDS Group Test中,仍然有IDS沒有辦法應付經由Fragroute這支程式所精心切割的封包。

  Fragroute這支程式,主要是實做出上述Thomas等人所著的那篇論文提到對於IP F r a g m e n t 和T C PSegment的刻意切割,再搭配上一些checksum錯誤或是PAWS有問題的封包,具造成IDS/IPS設備混淆的能力。例如,它可以把一個正常大小的封包,切成數百個1-byte大小的封包,其中某些封包還會有sequencenumber重疊的問題,所以IDS/IPS要能把這些碎片重組起來並且過濾掉那些刻意混淆的訊息。當時除了Fragroute以外,whisker也是很著名用來測試IDS/IPS的抗閃躲(anti evasion)能力的程式。不同於Fragroute的重點在於TCP/IP堆疊,whisker主要是測試網路設備對URL的變造是不是有能力解譯。比如說,IDS/IPS必須要能解析http://www.broadweb.com/r&d/和http://www.broadweb.com/./123/../r&d/兩者指向相同的目錄,只是後者利用directory traversal這個技巧企圖規避檢查。另外,NSS對於IDS/IPS anti evasion的測試還包括其他應用層的解譯,像是在ftp data stream裡面塞進telnet的控制字元,用ADMmutate將shell code編碼,或是更改HTTP server的port number看看IDS是否還能提供保護等。

  其實測試anti evasion往往要依賴測試工具的幫忙。試想,不借用工具要把一個網路攻擊切碎且變造其實是非常耗費時間。因此測試工具的演進也就促成了測試方法的進步。像是CANVAS這個Penetration Tool就有非常好的anti evasion功能。它不但能在第三層和第四層把封包切碎,甚至它也善用了第六層的SMB協定和第七層的RPC協定,使得攻擊更加難以偵測。透過MSRPC的漏洞在過去數年來層出不窮,至今於Microsoft Security Bulletin上已經有34個之多,其中也包括了一些大人物像是MS03-026、MS03-039的D C O M 漏洞( B l a s t e r 疾風病毒利用的弱點) 和MS04-011的LSASS漏洞(Sasser殺手病毒利用的弱點)。MSRPC是為了能提供分散式服務所設計的協定,但是由於架構其上的服務往往充滿了安全漏洞,加上這些服務往往具有系統權限,使得它變成了遠端入侵的溫床。MSRPC可以直接架構於TCP或是UDP之上, 也可以架構在Named Pipe(TCP + NetBIOS + SMB)之上,甚至是HTTP。MSRPC支援Fragmentation,SMB也是,再加上TCP和IP,一個專業的IDS/IPS可能得要重組四層才能找到一個精心隱藏的攻擊。那為什麼MIS不直接把MSRPC服務都關掉呢?因為像是網路硬碟或是網路印表機都是透過MSRPC來服務的,關掉整個port 135~139 可能會引起許多使用者的困擾。因此,大家都說IPS
處理的是第七層的問題而非傳統防火牆的第四層,但是不同的廠商還是有設計上的差別。如果一個IPS只能抓出第四層之後的payload做字串比對,無法應付目前攻擊工具的閃躲能力,一定還是要具有應用層解譯的能力才足夠。

防禦分散式阻斷攻擊要能明辨忠奸

  分散式阻斷攻擊(DDoS, Distributed Denial of Service)的防禦對網管人員來說是一個很重要的課題。通常企業內部伺服器被植入了後門,只要駭客不做出破壞的行為或是置換網頁等明目張膽的舉動,得花一段時間才會被發現。但是web server遭受DDoS攻擊或是內部的電腦被當成傀儡(Zombie)攻擊別人,且耗掉上傳頻寬,這就是即刻的切身之痛而必須馬上解決。事實上很多使用者測試IPS都從測試DDoS開始,因為架設環境相對容易。我先介紹ICSA和NSS對DDoS的測試,再討論一般使用者可以怎麼自行測試。

  目前ICSA還沒開始測試DDoS,而是使用一個網路上找得到的DoS工具Targa2。讀者使用google搜尋Targa2就可以找到一個targa2.c檔,在*nix環境下自行編譯即可。它其實是一個DoS工具的組合,裡面包含了bonk、land、teardrop、和winnuke等11種工具,這些DoS的攻擊大部份是針對Windows95/98和WindowsNT等比較舊的作業系統,只能說微軟之前的作業系統在IP Fragment的處理實在是漏洞太多了。ICSA會測試在80%背景流量的狀態下,IPS是否能全然阻擋或是減緩(mitigate)10%DoS的攻擊。NSS則是使用Spirent Avalanche產生10%流量的SYN Flood攻擊,並驗證在這樣的攻擊之下,IPS會不會讓網路封包的latency變大。

  其實使用者可以自行驗證IPS對DDoS的防禦力。因為一般DDoS都不是連線導向(connection-oriented),所以只需要架設一台沒上過patch的windows 95以及web server當被攻擊的對象即可。在PacketStorm上面有許多的DoS/DDoS原始碼,可以自行下載來玩。但是在所有DoS/DDoS的攻擊裡面,SYN flooding是最常發生也是最容易造成損失的一種。這一方面大陸同胞倒是研發了一些不錯的攻擊工具,像是HGod以及SynKiller等。這些攻擊工具可以輕易在一台PC上面執行,一秒中產生幾萬筆TCP連線,而且來源位址完全都是假造的。市面上許多的firewall或IPS都宣稱有防禦DoS/DDoS攻擊的能力,但是實際上他們只是去計算每個server每秒收到的TCP連線請求有多少個,超過就開始丟棄封包。這種忠奸不辨的方法對SYN flood攻擊來說是無效的。因為這樣的丟法也一樣會丟掉正常的封包,到時候雖然攻擊封包進不來,但使用者的正常流量(legitimate traffic)也一樣進不來,所謂阻斷服務的目的還是達到了。分辨攻擊的封包和合法的連線其實並不那麼容易,因為他們的長相完全一樣,設計完善的IPS廠商必須要能夠透過某些機制來分辨出攻擊的封包。如圖3所示,使用者可以架設這樣簡單的測試環境,先執行HGod一會兒,然後再試著從Client 建立HTTP連線看看是否會成功,以驗證IPS以及firewall是否能夠阻擋惡意的偽造連線並且讓合法的流量通行。

效能是inline設備必要的課題

  其實無論是IDS或是IPS,都必須要有良好的效能。IDS的效能不彰,會漏掉許多的攻擊;IPS的效能低落,則拖慢使用者的網路速度。但是要科學地衡量一個IPS的效能其實並不容易。因為同一個IPS的效能在不同的情形下可以差到數十倍之多。一般我們看到產品型錄上面所標示的效能,其實並不一定能夠反映使用者真實的情況。因為效能可以因為下面幾種情形而有很大的差別。

網路封包的大小

  尤其是PC架構的IPS。由於PCI bus或是網卡中斷處理(interrupt handling)的機制,一般PC架構的網路設備遇到小封包的時候效能都會降低。Router/firewall因為只處理封包表頭,因此效能對封包大小的差異更為明顯。而且在許多環境之下,並不是中型大小的封包佔大多數,而是很大的封包和很小的封包佔大多數,在P2P程式盛行的地方尤其如此。

流量類型的差異

  好的IPS需要對封包和網路行為做許多檢測。檢查SMTP或是HTTP等需要解碼(decoding)的流量和檢查不知名的UDP流量對IPS來說可能有倍數的效能差異。當然對那種不太做應用層解譯的IPS來說,差異就沒這麼大了,但也相對不安全。

封包內容和特徵碼的相關度。

  IPS一定要執行signature的比對。但是不管用哪一種比對演算法,一定都有其最差的狀況。比如說,當signature的內容是”0000000”,結果測試封包的內容正是”000000000...”,那麼可能就會得到很差的結果。相反地,要是測試封包的內容和signature的字串(pattern)一點關係也沒有,測試的效能就會很好。市面上有很多的IPS廠商,因為沒有自己的signature撰寫團隊,因此使用open source Snort的signature database。某種程度來說,也提高了被人透析signature pattern而導致遭受演算法攻擊(algorithmic attack)的風險。因此像是威播的BroadWeb Security ServiceTeam或是ISS的X-Force Team都是設備的靈魂。

  而且效能的測試必須包含throughput和latency才有意義。有些網路設備看起來是一個盒子,但是裡頭卻擺了很多子系統,並且利用內部交換器讓封包在子系統之間流動。雖然throughput可能不會很差,但卻增加了latency。要是每個封包都有數秒的延遲,網路的品質仍然無法接受。

  測試效能可以仰賴測試設備。事實上筆者服務的公司,在測試設備上的投資已經超過50萬美金了。使用測試設備的好處是準確-測試設備可以精準的依使用者的要求產生足夠的背景流量(background traffic)。但是一般來說測試設備的缺點是它有限的測試封包種類。以IXIA ixLoad為例,它可以播放使用者指定的封包內容,例如全是0或全是1,但這畢竟無法反應真實的狀況。它也可以播放一個錄好的packet trace,但是packet trace的大小有限制(32MB)。NSS是使用Spirent Avalanche和Reflector播放HTTP的封包來測試IPS效能,而ICSA決定使用母公司Cybertrust在某些大企業錄到的真實流量(real traffic)來測試。為了能夠順利播放這些realtraffic,ICSA還把Tomahawk給大修過了,而且還放在原本sourceforge的網站上讓人取用(http://tomahawk.sourceforge.net/)。用real traffic似乎比較能夠反映真實的狀況,但是不同的packet trace就會造成IPS有不同的表現。在ICSA今年的測試中,就有不少廠商抱怨ICSA所選用的packet trace對他們不利,但因為每一家廠商在實作上都有差異,而且signature的取法也一定不同(如果是自己撰寫 siganture database的話),所以似乎沒有什麼特別科學的方法來改善。

  但是效能的測試不單純指packet trace能夠順利以某個速度播放,或是測試設備傳送某個速度的封包不被阻擋,因為這些只是背景流量而已。以ICSA來說,廠商如宣稱它的效能為100Mbps,則tester會用上述的方法播放80Mbps的背景流量,而且是乾淨的流量。然後再播放2Mbps的攻擊封包,而且是每一個攻擊都必須在80%背景流量之下還要能被阻擋。假如IPS都能成功阻擋,那麼就開始變造攻擊,測試IPS在80%背景流量的狀況之下,是否還能完全的偵測出這些變造過的攻擊。之前提到的第三層一直到第七層的四階段重組,在這邊也會完全檢驗。以防IPS在背景流量很大的時候,就讓攻擊給溜了過去。畢竟效能雖然重要,但是使用者購買IPS的目的還是在於保護自己的網路,因此就算IPS效能再強,要是防守不夠嚴密,還是無法達到使用者的初衷。極端點說,layer-2 switch只看MAC header效能很棒,但那不會是使用者需要的安全產品。

總結

  經由以上的報告,希望能夠讓大家多了解一些目前專業的IPS在經過認證所需通過的評鑑項目及其由來。因為每個廠商的規格都大同小異,但是其間的深度以及廣度需要專業的知識來檢驗。在此總結一個的IPS評鑑的標準給各位參考:

1. 必須有精準的signature database,而且必須具有vulnerability-based的能力而非僅有 exploit-based的signature。

2. 預設的signature開啟了有多少?其中又有多少是會丟棄封包的?放在自家網路上會不會產生許多falsepositive?

3. 針對RPC、 HTTP等常見的服務,應該要有設計良好的應用程式解譯器。只做字串比對是絕對不夠的。

4. 要能夠做到四層的封包重組,才能夠有效地阻擋針對RPC服務的攻擊。

5. 效能不只是規格上面的一個數值,一定要實測才能作準。

6. 針對DoS/DDoS攻擊能分辨合理,及攻擊封包的差異,才能真正的保障使用者的安全。

7. 其他像是完整且彈性的報表系統、中央管理機制( C e n t r a l i z e d M a n a g e m e n t ) 、對I n s t a n tMessenge/Peer-to-Peer的管理能力等,皆視使用者的需求而定。