分散式拒絕服務攻擊(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 SYN標誌置位。客戶端告訴服務端序列號區域合法，需要檢查。客戶端在TCP報頭的序列號區中插入自己的ISN。服務端收到該TCP分段後，在第二步以自己的ISN迴應(SYN標誌置位)，同時確認收到客戶端的第一個TCP分段(ACK標誌置位)。在第三步中，客戶端確認收到服務端的ISN(ACK標誌置位)。到此為止建立完整的TCP連線，開始全雙工模式的資料傳輸過程。

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設定的同時，要注意一下這是以多大的效率犧牲為代價的，對你來說是否值得。

　　１.防火牆

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

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

　　２.路由器

　　以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界的同行們來一起關注，通力合作。