分佈式拒絕服務攻擊(DDoS)原理及防範

 年 6 月 01 日
分佈式拒絕服務攻擊(DDoS)是目前黑客經常採用而難以防範的攻擊手段。本文從概念開始詳細介紹了這種攻擊方式,着重描述了黑客是如何組織併發起的DDoS攻擊,結合其中的Syn Flood實例,您可以對DDoS攻擊有一個更形象的瞭解。最後作者結合自己的經驗與國內網絡安全的現況探討了一些防禦DDoS的實際手段。

DDoS攻擊概念

DoS的攻擊方式有很多種,最基本的DoS攻擊就是利用合理的服務請求來佔用過多的服務資源,從而使合法用戶無法得到服務的響應。

DDoS攻擊手段是在傳統的DoS攻擊基礎之上產生的一類攻擊方式。單一的DoS攻擊一般是採用一對一方式的,當攻擊目標CPU速度低、內存小或者網絡帶寬小等等各項性能指標不高它的效果是明顯的。隨着計算機與網絡技術的發展,計算機的處理能力迅速增長,內存大大增加,同時也出現了千兆級別的網絡,這使得DoS攻擊的困難程度加大了 - 目標對惡意攻擊包的"消化能力"加強了不少,例如你的攻擊軟件每秒鐘可以發送3,000個攻擊包,但我的主機與網絡帶寬每秒鐘可以處理10,000個攻擊包,這樣一來攻擊就不會產生什麼效果。

這時侯分佈式的拒絕服務攻擊手段(DDoS)就應運而生了。你理解了DoS攻擊的話,它的原理就很簡單。如果說計算機與網絡的處理能力加大了10倍,用一臺攻擊機來攻擊不再能起作用的話,攻擊者使用10臺攻擊機同時攻擊呢?用100臺呢?DDoS就是利用更多的傀儡機來發起進攻,以比從前更大的規模來進攻受害者。

高速廣泛連接的網絡給大家帶來了方便,也爲DDoS攻擊創造了極爲有利的條件。在低速網絡時代時,黑客佔領攻擊用的傀儡機時,總是會優先考慮離目標網絡距離近的機器,因爲經過路由器的跳數少,效果好。而現在電信骨幹節點之間的連接都是以G爲級別的,大城市之間更可以達到2.5G的連接,這使得攻擊可以從更遠的地方或者其他城市發起,攻擊者的傀儡機位置可以在分佈在更大的範圍,選擇起來更靈活了。





被DDoS攻擊時的現象

  • 被攻擊主機上有大量等待的TCP連接
  • 網絡中充斥着大量的無用的數據包,源地址爲假
  • 製造高流量無用數據,造成網絡擁塞,使受害主機無法正常和外界通訊
  • 利用受害主機提供的服務或傳輸協議上的缺陷,反覆高速的發出特定的服務請求,使受害主機無法及時處理所有正常請求
  • 嚴重時會造成系統死機

攻擊運行原理



如圖一,一個比較完善的DDoS攻擊體系分成四大部分,先來看一下最重要的第2和第3部分:它們分別用做控制和實際發起攻擊。請注意控制機與攻擊機的區別,對第4部分的受害者來說,DDoS的實際攻擊包是從第3部分攻擊傀儡機上發出的,第2部分的控制機只發布命令而不參與實際的攻擊。對第2和第3部分計算機,黑客有控制權或者是部分的控制權,並把相應的DDoS程序上傳到這些平臺上,這些程序與正常的程序一樣運行並等待來自黑客的指令,通常它還會利用各種手段隱藏自己不被別人發現。在平時,這些傀儡機器並沒有什麼異常,只是一旦黑客連接到它們進行控制,併發出指令的時候,攻擊傀儡機就成爲害人者去發起攻擊了。

有的朋友也許會問道:"爲什麼黑客不直接去控制攻擊傀儡機,而要從控制傀儡機上轉一下呢?"。這就是導致DDoS攻擊難以追查的原因之一了。做爲攻擊者的角度來說,肯定不願意被捉到(我在小時候向別人家的雞窩扔石頭的時候也曉得在第一時間逃掉,呵呵),而攻擊者使用的傀儡機越多,他實際上提供給受害者的分析依據就越多。在佔領一臺機器後,高水平的攻擊者會首先做兩件事:1. 考慮如何留好後門(我以後還要回來的哦)!2. 如何清理日誌。這就是擦掉腳印,不讓自己做的事被別人查覺到。比較不敬業的黑客會不管三七二十一把日誌全都刪掉,但這樣的話網管員發現日誌都沒了就會知道有人幹了壞事了,頂多無法再從日誌發現是誰幹的而已。相反,真正的好手會挑有關自己的日誌項目刪掉,讓人看不到異常的情況。這樣可以長時間地利用傀儡機。

但是在第3部分攻擊傀儡機上清理日誌實在是一項龐大的工程,即使在有很好的日誌清理工具的幫助下,黑客也是對這個任務很頭痛的。這就導致了有些攻擊機弄得不是很乾淨,通過它上面的線索找到了控制它的上一級計算機,這上級的計算機如果是黑客自己的機器,那麼他就會被揪出來了。但如果這是控制用的傀儡機的話,黑客自身還是安全的。控制傀儡機的數目相對很少,一般一臺就可以控制幾十臺攻擊機,清理一臺計算機的日誌對黑客來講就輕鬆多了,這樣從控制機再找到黑客的可能性也大大降低。





黑客是如何組織一次DDoS攻擊的?

這裏用"組織"這個詞,是因爲DDoS並不象入侵一臺主機那樣簡單。一般來說,黑客進行DDoS攻擊時會經過這樣的步驟:

1. 蒐集瞭解目標的情況
下列情況是黑客非常關心的情報:

  • 被攻擊目標主機數目、地址情況
  • 目標主機的配置、性能
  • 目標的帶寬

對於DDoS攻擊者來說,攻擊互聯網上的某個站點,如http://www.mytarget.com,有一個重點就是確定到底有多少臺主機在支持這個站點,一個大的網站可能有很多臺主機利用負載均衡技術提供同一個網站的www服務。以yahoo爲例,一般會有下列地址都是提供http://www.yahoo.com服務的:
66.218.71.87
66.218.71.88
66.218.71.89
66.218.71.80
66.218.71.81
66.218.71.83
66.218.71.84
66.218.71.86

如果要進行DDoS攻擊的話,應該攻擊哪一個地址呢?使66.218.71.87這臺機器癱掉,但其他的主機還是能向外提供www服務,所以想讓別人訪問不到http://www.yahoo.com的話,要所有這些IP地址的機器都癱掉才行。在實際的應用中,一個IP地址往往還代表着數臺機器:網站維護者使用了四層或七層交換機來做負載均衡,把對一個IP地址的訪問以特定的算法分配到下屬的每個主機上去。這時對於DDoS攻擊者來說情況就更復雜了,他面對的任務可能是讓幾十臺主機的服務都不正常。

所以說事先蒐集情報對DDoS攻擊者來說是非常重要的,這關係到使用多少臺傀儡機才能達到效果的問題。簡單地考慮一下,在相同的條件下,攻擊同一站點的2臺主機需要2臺傀儡機的話,攻擊5臺主機可能就需要5臺以上的傀儡機。有人說做攻擊的傀儡機越多越好,不管你有多少臺主機我都用盡量多的傀儡機來攻就是了,反正傀儡機超過了時候效果更好。

但在實際過程中,有很多黑客並不進行情報的蒐集而直接進行DDoS的攻擊,這時候攻擊的盲目性就很大了,效果如何也要靠運氣。其實做黑客也象網管員一樣,是不能偷懶的。一件事做得好與壞,態度最重要,水平還在其次。

2. 佔領傀儡機
黑客最感興趣的是有下列情況的主機:

  • 鏈路狀態好的主機
  • 性能好的主機
  • 安全管理水平差的主機

這一部分實際上是使用了另一大類的攻擊手段:利用形攻擊。這是和DDoS並列的攻擊方式。簡單地說,就是佔領和控制被攻擊的主機。取得最高的管理權限,或者至少得到一個有權限完成DDoS攻擊任務的帳號。對於一個DDoS攻擊者來說,準備好一定數量的傀儡機是一個必要的條件,下面說一下他是如何攻擊並佔領它們的。

首先,黑客做的工作一般是掃描,隨機地或者是有針對性地利用掃描器去發現互聯網上那些有漏洞的機器,象程序的溢出漏洞、cgi、Unicode、ftp、數據庫漏洞…(簡直舉不勝舉啊),都是黑客希望看到的掃描結果。隨後就是嘗試入侵了,具體的手段就不在這裏多說了,感興趣的話網上有很多關於這些內容的文章。

總之黑客現在佔領了一臺傀儡機了!然後他做什麼呢?除了上面說過留後門擦腳印這些基本工作之外,他會把DDoS攻擊用的程序上載過去,一般是利用ftp。在攻擊機上,會有一個DDoS的發包程序,黑客就是利用它來向受害目標發送惡意攻擊包的。

3. 實際攻擊
經過前2個階段的精心準備之後,黑客就開始瞄準目標準備發射了。前面的準備做得好的話,實際攻擊過程反而是比較簡單的。就象圖示裏的那樣,黑客登錄到做爲控制檯的傀儡機,向所有的攻擊機發出命令:"預備~ ,瞄準~,開火!"。這時候埋伏在攻擊機中的DDoS攻擊程序就會響應控制檯的命令,一起向受害主機以高速度發送大量的數據包,導致它死機或是無法響應正常的請求。黑客一般會以遠遠超出受害方處理能力的速度進行攻擊,他們不會"憐香惜玉"。

老到的攻擊者一邊攻擊,還會用各種手段來監視攻擊的效果,在需要的時候進行一些調整。簡單些就是開個窗口不斷地ping目標主機,在能接到迴應的時候就再加大一些流量或是再命令更多的傀儡機來加入攻擊。





DDoS攻擊實例 - SYN Flood攻擊

SYN-Flood是目前最流行的DDoS攻擊手段,早先的DoS的手段在向分佈式這一階段發展的時候也經歷了浪裏淘沙的過程。SYN-Flood的攻擊效果最好,應該是衆黑客不約而同選擇它的原因吧。那麼我們一起來看看SYN-Flood的詳細情況。

Syn Flood原理 - 三次握手
Syn Flood利用了TCP/IP協議的固有漏洞。面向連接的TCP三次握手是Syn Flood存在的基礎。

TCP連接的三次握手


圖二 TCP三次握手
圖二 TCP三次握手

如圖二,在第一步中,客戶端向服務端提出連接請求。這時TCP SYN標誌置位。客戶端告訴服務端序列號區域合法,需要檢查。客戶端在TCP報頭的序列號區中插入自己的ISN。服務端收到該TCP分段後,在第二步以自己的ISN迴應(SYN標誌置位),同時確認收到客戶端的第一個TCP分段(ACK標誌置位)。在第三步中,客戶端確認收到服務端的ISN(ACK標誌置位)。到此爲止建立完整的TCP連接,開始全雙工模式的數據傳輸過程。

Syn Flood攻擊者不會完成三次握手


圖三 Syn Flood惡意地不完成三次握手
圖三 Syn Flood惡意地不完成三次握手

假設一個用戶向服務器發送了SYN報文後突然死機或掉線,那麼服務器在發出SYN+ACK應答報文後是無法收到客戶端的ACK報文的(第三次握手無法完成),這種情況下服務器端一般會重試(再次發送SYN+ACK給客戶端)並等待一段時間後丟棄這個未完成的連接,這段時間的長度我們稱爲SYN Timeout,一般來說這個時間是分鐘的數量級(大約爲30秒-2分鐘);一個用戶出現異常導致服務器的一個線程等待1分鐘並不是什麼很大的問題,但如果有一個惡意的攻擊者大量模擬這種情況,服務器端將爲了維護一個非常大的半連接列表而消耗非常多的資源----數以萬計的半連接,即使是簡單的保存並遍歷也會消耗非常多的CPU時間和內存,何況還要不斷對這個列表中的IP進行SYN+ACK的重試。實際上如果服務器的TCP/IP棧不夠強大,最後的結果往往是堆棧溢出崩潰---即使服務器端的系統足夠強大,服務器端也將忙於處理攻擊者僞造的TCP連接請求而無暇理睬客戶的正常請求(畢竟客戶端的正常請求比率非常之小),此時從正常客戶的角度看來,服務器失去響應,這種情況我們稱做:服務器端受到了SYN Flood攻擊(SYN洪水攻擊)。

下面是我在實驗室中模擬的一次Syn Flood攻擊的實際過程

這一個局域網環境,只有一臺攻擊機(PIII667/128/mandrake),被攻擊的是一臺Solaris 8.0 (spark)的主機,網絡設備是Cisco的百兆交換機。這是在攻擊並未進行之前,在Solaris上進行snoop的記錄,snoop與tcpdump等網絡監聽工具一樣,也是一個很好的網絡抓包與分析的工具。可以看到攻擊之前,目標主機上接到的基本上都是一些普通的網絡包。

…
…
           ? -> (broadcast)  ETHER Type=886F (Unknown), size = 1510 bytes
           ? -> (broadcast)  ETHER Type=886F (Unknown), size = 1510 bytes
           ? -> (multicast)  ETHER Type=0000 (LLC/802.3), size = 52 bytes
           ? -> (broadcast)  ETHER Type=886F (Unknown), size = 1510 bytes
192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]
192.168.0.210 -> 192.168.0.255 NBT Datagram Service Type=17 Source=ROOTDC[20]
192.168.0.247 -> 192.168.0.255 NBT Datagram Service Type=17 Source=TSC[0]
           ? -> (broadcast)  ETHER Type=886F (Unknown), size = 1510 bytes
192.168.0.200 -> (broadcast)  ARP C Who is 192.168.0.102, 192.168.0.102 ?
           ? -> (broadcast)  ETHER Type=886F (Unknown), size = 1510 bytes
           ? -> (broadcast)  ETHER Type=886F (Unknown), size = 1510 bytes
192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]
192.168.0.66 -> 192.168.0.255 NBT Datagram Service Type=17 Source=GU[0]
192.168.0.210 -> 192.168.0.255 NBT Datagram Service Type=17 Source=ROOTDC[20]
           ? -> (multicast)  ETHER Type=0000 (LLC/802.3), size = 52 bytes
           ? -> (broadcast)  ETHER Type=886F (Unknown), size = 1510 bytes
           ? -> (broadcast)  ETHER Type=886F (Unknown), size = 1510 bytes
…
…

接着,攻擊機開始發包,DDoS開始了…,突然間sun主機上的snoop窗口開始飛速地翻屏,顯示出接到數量巨大的Syn請求。這時的屏幕就好象是時速300公里的列車上的一扇車窗。這是在Syn Flood攻擊時的snoop輸出結果:

…
…
 127.0.0.178 -> lab183.lab.net AUTH C port=1352 
 127.0.0.178 -> lab183.lab.net TCP D=114 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=115 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net UUCP-PATH C port=1352 
 127.0.0.178 -> lab183.lab.net TCP D=118 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net NNTP C port=1352 
 127.0.0.178 -> lab183.lab.net TCP D=121 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=122 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=124 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=125 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=126 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=128 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=130 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=131 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=133 S=1352 Syn Seq=674711609 Len=0 Win=65535
 127.0.0.178 -> lab183.lab.net TCP D=135 S=1352 Syn Seq=674711609 Len=0 Win=65535
…
…

這時候內容完全不同了,再也收不到剛纔那些正常的網絡包,只有DDoS包。大家注意一下,這裏所有的Syn Flood攻擊包的源地址都是僞造的,給追查工作帶來很大困難。這時在被攻擊主機上積累了多少Syn的半連接呢?我們用netstat來看一下:

# netstat -an | grep SYN

…
…
192.168.0.183.9      127.0.0.79.1801          0      0 24656      0 SYN_RCVD
192.168.0.183.13     127.0.0.79.1801          0      0 24656      0 SYN_RCVD
192.168.0.183.19     127.0.0.79.1801          0      0 24656      0 SYN_RCVD
192.168.0.183.21     127.0.0.79.1801          0      0 24656      0 SYN_RCVD
192.168.0.183.22     127.0.0.79.1801          0      0 24656      0 SYN_RCVD
192.168.0.183.23     127.0.0.79.1801          0      0 24656      0 SYN_RCVD
192.168.0.183.25     127.0.0.79.1801          0      0 24656      0 SYN_RCVD
192.168.0.183.37     127.0.0.79.1801          0      0 24656      0 SYN_RCVD
192.168.0.183.53     127.0.0.79.1801          0      0 24656      0 SYN_RCVD
…
…

其中SYN_RCVD表示當前未完成的TCP SYN隊列,統計一下:
# netstat -an | grep SYN | wc -l
5273
# netstat -an | grep SYN | wc -l
5154
# netstat -an | grep SYN | wc -l
5267
…..

共有五千多個Syn的半連接存儲在內存中。這時候被攻擊機已經不能響應新的服務請求了,系統運行非常慢,也無法ping通。

這是在攻擊發起後僅僅70秒鐘左右時的情況。





DDoS的防範

到目前爲止,進行DDoS攻擊的防禦還是比較困難的。首先,這種攻擊的特點是它利用了TCP/IP協議的漏洞,除非你不用TCP/IP,纔有可能完全抵禦住DDoS攻擊。一位資深的安全專家給了個形象的比喻:DDoS就好象有1,000個人同時給你家裏打電話,這時候你的朋友還打得進來嗎?

不過即使它難於防範,也不是說我們就應該逆來順受,實際上防止DDoS並不是絕對不可行的事情。互聯網的使用者是各種各樣的,與DDoS做鬥爭,不同的角色有不同的任務。我們以下面幾種角色爲例:

  • 企業網管理員
  • ISP、ICP管理員
  • 骨幹網絡運營商

企業網管理員

網管員做爲一個企業內部網的管理者,往往也是安全員、守護神。在他維護的網絡中有一些服務器需要向外提供WWW服務,因而不可避免地成爲DDoS的攻擊目標,他該如何做呢?可以從主機與網絡設備兩個角度去考慮。

主機上的設置
幾乎所有的主機平臺都有抵禦DoS的設置,總結一下,基本的有幾種:

  • 關閉不必要的服務
  • 限制同時打開的Syn半連接數目
  • 縮短Syn半連接的time out 時間
  • 及時更新系統補丁

網絡設備上的設置
企業網的網絡設備可以從防火牆與路由器上考慮。這兩個設備是到外界的接口設備,在進行防DDoS設置的同時,要注意一下這是以多大的效率犧牲爲代價的,對你來說是否值得。

1.防火牆

  • 禁止對主機的非開放服務的訪問
  • 限制同時打開的SYN最大連接數
  • 限制特定IP地址的訪問
  • 啓用防火牆的防DDoS的屬性
  • 嚴格限制對外開放的服務器的向外訪問

第五項主要是防止自己的服務器被當做工具去害人。

2.路由器
以Cisco路由器爲例

  • Cisco Express Forwarding(CEF)
  • 使用 unicast reverse-path
  • 訪問控制列表(ACL)過濾
  • 設置SYN數據包流量速率
  • 升級版本過低的ISO
  • 爲路由器建立log server

其中使用CEF和Unicast設置時要特別注意,使用不當會造成路由器工作效率嚴重下降,升級IOS也應謹慎。路由器是網絡的核心設備,與大家分享一下進行設置修改時的小經驗,就是先不保存。Cisco路由器有兩份配置startup config和running config,修改的時候改變的是running config,可以讓這個配置先跑一段時間(三五天的就隨意啦),覺得可行後再保存配置到startup config;而如果不滿意想恢復原來的配置,用copy start run就行了。

ISP / ICP管理員

ISP / ICP爲很多中小型企業提供了各種規模的主機託管業務,所以在防DDoS時,除了與企業網管理員一樣的手段外,還要特別注意自己管理範圍內的客戶託管主機不要成爲傀儡機。客觀上說,這些託管主機的安全性普遍是很差的,有的連基本的補丁都沒有打就赤膊上陣了,成爲黑客最喜歡的"肉雞",因爲不管這臺機器黑客怎麼用都不會有被發現的危險,它的安全管理太差了;還不必說託管的主機都是高性能、高帶寬的-簡直就是爲DDoS定製的。而做爲ISP的管理員,對託管主機是沒有直接管理的權力的,只能通知讓客戶來處理。在實際情況時,有很多客戶與自己的託管主機服務商配合得不是很好,造成ISP管理員明知自己負責的一臺託管主機成爲了傀儡機,卻沒有什麼辦法的局面。而託管業務又是買方市場,ISP還不敢得罪客戶,怎麼辦?咱們管理員和客戶搞好關係吧,沒辦法,誰讓人家是上帝呢?呵呵,客戶多配合一些,ISP的主機更安全一些,被別人告狀的可能性也小一些。

骨幹網絡運營商

他們提供了互聯網存在的物理基礎。如果骨幹網絡運營商可以很好地合作的話,DDoS攻擊可以很好地被預防。在2000年yahoo等知名網站被攻擊後,美國的網絡安全研究機構提出了骨幹運營商聯手來解決DDoS攻擊的方案。其實方法很簡單,就是每家運營商在自己的出口路由器上進行源IP地址的驗證,如果在自己的路由表中沒有到這個數據包源IP的路由,就丟掉這個包。這種方法可以阻止黑客利用僞造的源IP來進行DDoS攻擊。不過同樣,這樣做會降低路由器的效率,這也是骨幹運營商非常關注的問題,所以這種做法真正採用起來還很困難。

對DDoS的原理與應付方法的研究一直在進行中,找到一個既有效又切實可行的方案不是一朝一夕的事情。但目前我們至少可以做到把自己的網絡與主機維護好,首先讓自己的主機不成爲別人利用的對象去攻擊別人;其次,在受到攻擊的時候,要儘量地保存證據,以便事後追查,一個良好的網絡和日誌系統是必要的。無論DDoS的防禦向何處發展,這都將是一個社會工程,需要IT界的同行們來一起關注,通力合作。



參考資料



關於作者

徐一丁,北京瑪賽網絡系統有限公司方案設計部高級工程師,從事IT工作多年。目前主要進行國內外安全產品評測與黑客攻擊的研究。有豐富的網絡安全設計與實施經驗,並給各大電信公司如中國電信、吉通公司、聯通公司等進行過系列安全培訓。




發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章