2012年4月13日 星期五

DDoS攻擊手法與防禦對策-DDoS網災來襲 政府準備好了嗎?<攻防技術篇之二>


DDoS攻擊手法與防禦對策-DDoS網災來襲 政府準備好了嗎?<攻防技術篇之二>

DDoS攻擊通常會伴隨Botnet(殭屍網路)進行,攻擊者透過對大量遭植入控制程式的殭屍電腦發送命令,使其同時間對目標發動指定類型的攻擊。也因此DDoS的追查難度非常的高,遇到高明的攻擊者利用Botnet控制Botnet,透過技術層次幾乎不可能確認其身份。而雖然DoS、DDoS已經存在十幾年了,但許多人常存在不當的誤解,例如「只要加大頻寬就好了」、「叫ISP擋啊!」、「買最高貴的設備擋就對了」、「用『機海戰術』跟它拼了!」…等。

DDoS表示由多重來源發起攻擊而導致目標服務癱瘓,而並不單指特定某種攻擊手法。由於攻擊手法繁多,因此也沒有統一的標準解決方案。本文僅就「網路行為」造成的D D o S 攻擊進行探討,其他針對程式弱點的攻擊如B u f f e rO v e r f l o w 使服務停止運作,或Injection類植入特定命令使服務或主機關閉等,雖說同樣可造成Denial of Service結果,但不於本文中說明。

攻擊分類
依攻擊之層次,可分為以下幾種-

(1) Network Layer:利用常見之標準協定如TCP/UDP/ICMP進行攻擊。其中某些Stateless類之攻擊可偽造位址,因此無法以阻擋來源的方式防禦。而Stateful之完整建立連線類的攻擊通常會與Botnet結合,不斷變換、並來自大量的真實位址,使防守者疲於奔命。目的為使目標頻寬滿載、或使網路設備或主機無法負荷而停止服務。

(2) Service Layer:介於網路層與應用層之間,於服務層進行資料交換處理時、但仍未至應用層實際執行動作前,使其處理錯誤引發例外情況(例如Buffer Overflow)、或因大量進行協議交換處理而無法負荷。

(3) Application Layer:利用製造模擬大量之正常請求至目標主機應用層,使其因無法服務過量使用者而負荷超載。而大多傳統設備可防護之DoS/DDoS攻擊手法如Teardrop、Land、Smurf、Fraggle、Ping of Death…等,由於作業系統均已修正,即使不防護亦無法生
效。

以DDoS攻擊之結果而言,常見之徵兆為-
(1) 網路頻寬滿載:被大量網路封包湧入而使網路出口頻寬滿載,影響服務正常使用者之品質。
(2) 網路設備不堪負載:因發揮功能為後方服務抵擋攻擊,使自身處理能力或記憶體空間滿載而停止運作,常見症狀為設備處理速度變慢、記憶體空間
堆滿、甚至當機或重新啟動等。
(3) 作業系統負荷超載:前方防禦設備未發揮效用(或無防禦設備),讓作業系統接到攻擊流量而使處理能力或儲存空間滿載,常見情形為CPU負荷升高、連線數大量上升、狀態表(Session Table)滿載…等。
(4) 服務負荷超載:超過伺服器可處理之正常請求進入,使主機負荷過重而無法負擔,常見情形為CPU負荷升高、記憶體使用量升高等。

 攻擊手法分析

1. UDP/ICMP Flood
原理分析
發送大量的UDP/ICMP封包(亦可假造來源)至攻擊目標,以使其頻寬滿載、或設備處理不及,是最常見的攻擊手法之一。

因多數攻擊程式在客製UDP/ICMP封包時的overhead較TCP為低,且目前的作業系統大多未作限制,故封包發送速度快、內容也易客製,可作到完全不具攻擊封包特徵。當發送大量小封包時,可使PacketPer Second處理能力較低之路由器、防火牆,因此而無法負荷;當發送大量大封包時,可使Throughput處理能力不足之路由器、防火牆,因此而無法承載。當攻擊者可控制之殭屍主機夠多時,可直接將攻擊目標的頻寬塞爆,難以再服務其他正常使用者。筆者於實驗室中測試,於區域網路中,單台伺服器級主機之小封包攻擊速度可達每秒600,000個封包,大封包之攻擊量可至接近線速(1Gbps或100Mbps)。此種攻擊手法之量可到非常巨大,國際間到 3,000,000 ~ 5,000,000 pps、5 ~10 Gbps流量都曾發生,端視攻擊者之殭屍網路集團數量。

防禦對策
由於大多數服務均使用TCP協定,因此受到攻擊時可直接請ISP協助過濾掉UDP、ICMP協定之封包,避免頻寬滿載。如需開放特定服務(例如DNS),則可僅開放UDP:53 port,但以IPS設備過濾不合協定的封包,以防止攻擊者針對該缺口攻擊。大部份具ACL功能之防護設備皆可處理,如Firewall、IPS等。

2. SYN Flood
原理分析
發送大量的SYN封包(多數為假造來源IP),但不傳遞完成連線之ACK封包,使網路設備、或伺服器的Session Table連線狀態永遠無法建立而滿載,無法接受新連線。
且只要發送速率(pps) >Timeout速率,即可讓服務一直處於癱瘓,是最常見攻擊手法之一。但近年來由於微軟限制Windows XP作業系統winsock api中RAW Socket封包發送速率,因此大幅降低殭屍機的攻擊能力,攻擊者需以winpcap library設計的windows平台攻擊程式、或以其他作業系統如Linux或Windows 2000等,才可進行較大量封包發送速率。當主機直接遭遇SYNFlood攻擊時,netstat狀態可見均陷入SYN_RECV(見圖3),且來源均為任意假造之位址。此種攻擊手法,於目前的臺灣網路環境中,較大的量約為1,000,000~2,000,000 pps、600 Mbps~1.2 Gbps左右。筆者於實驗室中測試,於區域網路中,單台伺服器級Linux主機,配合客製過之特殊攻擊程式,速度可達每秒150,000個SYN封包(Fast Ethernet環境下)、或500,000個SYN封包(Giga Ethernet環境下),足以攻垮許多中低階之設備。

防禦對策
若無防護設備,於主機端的調校原則是加大Session Table、SYN Table、以及縮短SYN_RECV Timeout。如果封包客製得當,可做到完全沒有特徵,IPS無法根據封包特徵辨識是否為正常連線,因此資安設備需以SYN Proxy、或SYNCookie機制,代替後方主機先確認連線建立完成後,才傳遞給後方服務。代表性防護設備為Firewall(部份)、IPS、Application Delivery Controller等。

 3. ACK/RST Flood
原理分析
發送大量的TCP ACK封包(或RST)至攻擊目標,使其間的Stateful設備或主機接到每個封包,均需消耗處理能力檢查狀態表是否存在該連線,以決定是否放行、或丟棄封包、或回應RST。此攻擊通常不會單獨出現,也難完全以此使目標服務癱瘓,常見情況為合併S Y NFlood使用,使受攻端較難辨識攻擊手法。
防禦對策
使用高效能之Stateful資安設備於主機前端過濾,將未連立連線之封包直接丟棄,但需考量設備之狀態檢查處理能力、以及Concurrent Session數,以免前端之資安設備反而成為故障點。代表性防護設備為Firewall、IPS、Application Delivery Controller等。

4. Connection Flood
原理分析
Connect Flood以真實來源,與目標服務反覆高速大量建立正常TCP連線並關閉,網路設備或服務主機將虛耗資源於連線處理,若CPS(Connection Per Second)效能不足,則將使後續連線處理效率大幅降低。此攻擊常與Zombie Connection同時發動,與目標服務持續建立TCP連線並保持不切斷,網路設備或服務主機將因連線表滿載而導致無法再處理後續連線。此攻擊量可非常巨大,1,000,000~3,000,000之同時建立正常連線都可能發生,端視殭屍網路集團數量。當主機直接遭受Connect Flood攻擊時,netstat會看到大量E S T A B L I S H E D、T I M E _ W A I T、CLOSE_WAIT等狀態,若作業系統之TCP/IPStack運作機制不佳,則很快就無法處理新連線。當主機直接遭受Zombie Connections攻擊,netstat狀態可見增加許多已建立連線。

防禦對策
若無設備可於主機端加大Session Table、開啟TCP reuse/recycle機制、縮短close/fin timeout
等,以提升自身承受能力。使用高效能資安設備,分析、並限制每秒鐘允許建立連線數、以及相同來源總連線數,將超過門檻連線阻擋、丟棄、或延遲發送至後端主機,以避免主機耗費過多資源於處理連線。由於連線為完整建立,因此可追蹤真實攻擊者來源位址直接予以阻擋。部份應用層ADC設備可在接到正確應用層請求後,才與伺服器建立連線,則可更有效防止此類攻擊。代表性防護設備為Firewall(部份)、IPS、ADC。

5. SSL Flood
原理分析
以大量之真實來源,對提供SSL加密服務(如https、pop3s、smtps…等)之目標主機不斷進行SSL Handshake,但不發送後續之應用層請求(如HTTP Request)。受攻擊主機將因不斷進行SSL協議連線,而使負荷升高,但因未進行實際應用層行為,通常不會有正常存取記錄。

防禦對策
於網路層限制SSL連線之建立速度,或以硬體卸載拆除SSL封包至後端為明碼協定(例如 https→http)。如攻擊者實際進行Request動作,使主機端消耗大量運算能力於加解密上,亦可安裝SSL加速卡以處理加解密動作。由於連線為完整建立,因此亦可追蹤真實之攻
擊者來源位址直接予以阻擋。代表性防護設備為IPS、SSL Proxy、SSL Accelerator、部份ADC。

6. Application Flood
原理分析
以真實來源不斷發送針對應用層之正常請求,如HTTP、POP3、SMTP等請求或針對各客製化協定(如線上遊戲)之正常動作,使服務主機無法負荷過多之使用者而過載。當中最常發生的為HTTP Flood攻擊,由於其屬正常的網頁請求,因此大多數Firewall、IPS不會予以阻擋,當超過網頁伺服器可承載之量時,網站便會因此而減慢或甚至停止服務。

防禦對策
若為客製化協定,通常較少有設備可支援處理,僅能於網路層攔截過快速之連線建立行為。由於連線為完整建立,因此亦可追蹤真實之攻擊者來源位址,直接予以阻擋。若為標準協定如HTTP,可使用應用層機制確認來源為瀏覽器或工具發起,例如辨識Header、進行cookie check、javascript challenge等,於前方攔截非瀏覽器之行為。由於應用層之機制較複雜,若短時間無法正常辨識出攻擊者,可多加主機進行負載平衡,以維持服務的正常運作,再謀求解決方案。代表性防護設備為IPS、ADC。

攻擊處理流程

1. 前置作業:要在遭受DDoS攻擊時,馬上可掌握狀況,知道是哪一種攻擊類型,要在平常時就作好一些前置作業。而在產生流量圖、趨勢圖時,需選擇良好的工具,傳統工具如mrtg具有許多缺點,在後續分析事件時的幫助較小,建議選用可追蹤任意時段資訊的網管工具,如免費的cacti、opennms、nagios…等,或整合更完善的商
業軟體等。以下簡列必要記錄之資訊。

(1) 主機狀態記錄:C P U使用率、記憶體使用率(因目前多數作業系統會將空閒之記憶體作為buffer/cache,因此最好可將實際用量、Cached、Buffered、以及SWAP等皆加以記錄。)、網路連線數、各網路介面之流量及封包數、應用程式存取記錄(如web access log)
(2) 網路設備狀態記錄:系統負荷(CPU、Memory…etc)、Session量、各網路介面之流量及封包數、各VLAN之流量及封包數、各協定(TCP/SYN/UDP/ICMP/…etc)佔用之流量&封包數(部份L4以上設備支援)、負載平衡機制下各服務之連線狀況、每秒事件數(例如ACL、FW Policy、IPS Event)
(3) 日誌記錄集中收集:以Log Server、SIEM(Security Information and Event Management)、SOC(Security Operation Center)等機制,收進各設備日誌作分析,以免受DDoS時因設備負載過高無法察看、將失去第一時間資訊

2. 收集資訊:懷疑受到攻擊時,儘速調閱受影響系統、及前方相關設備之-運作效能狀態、網路流量、日誌記錄、應用程式存取記錄及其他前置作業中有收集之資訊。通常若準備工作充份、加上判斷攻擊之專業能力足夠,於資訊齊全之情況下應可判斷所有的攻擊類型,再採取相對應的措施。

3. 側錄封包:若既有之資訊不足以判斷遭受何種攻擊,則於系統進出口處之路由器或交換器上,啟動Port Mirror機制,並以封包側錄軟體如tcpdump、wireshark等,收集一定量封包後,交由專業人員進行分析。

4. 請ISP或IDC協助:如湧入之封包流量,已超出既有之線路頻寬,則自家的防護設備再怎麼阻擋都沒有用,需儘快請ISP或IDC協助過濾攻擊之封包、或加大頻寬。但如果攻擊者之初始行為與正常連線無異、或無特徵(如SYN Flood、HTTP Flood…等),則通常ISP/IDC可處理的範圍仍有限,需雙方配合,前面過濾、後方也擋,才
可有效防禦。

5. 進行阻擋:判斷出攻擊的手法後,採取相對應的阻擋措施。若既有主機、或設備無功能可防禦,則儘快協調專業廠商借調設備作防禦。

6. 報案:於事件處理告一段落後,收集相關資訊(如網路流量圖、設備運作統計圖、側錄封包…等),向檢調單位報案。(目前台灣環境中所遭遇到較大的攻擊量,尤以中國大陸居多,因此國內檢調單位偵辦得到的結果,通常難有實質幫助。)

7. 事件檢討:於攻擊事件結束後,將所發生的原因、過程、處理方式,撰寫為事件記錄簿,供後續發生類似情況時有處理方式可遵循。若原有之資訊建設無法阻擋遇到的攻擊類型,則告知管理階層需增加適當之防禦設備,否則往後同樣的事件仍可能再度發生。

結論
本文探討了目前網際網路環境中常見的DoS/DDoS攻擊手法,及說明各類處理方式,希望可使讀者有初步的認識。惟「道高一尺、魔高一丈」,這是一場不會止息的戰爭,設備是死的、人卻是活的,唯有不斷精進自身的知識,才能在愈來愈紛亂的網際網路環境中提供穩定的服務。

轉載自《資安人科技網

沒有留言:

張貼留言