從07年的愛沙尼亞DDoS信息戰，到2009年廣西南寧30個網吧遭受到DDoS勒索，再到新浪網遭受DDoS***無法提供對外服務500多分鐘。DDoS愈演愈烈，***事件明顯增多，***流量也明顯增大，形勢十分嚴峻，超過1G的***流量頻頻出現，CNCERT/CC掌握的數據表明，最高時達到了12G，這樣流量，甚至連專業的機房都無法抵擋。更爲嚴峻的是：利用DDoS***手段敲詐勒索已經形成了一條完整的產業鏈！並且，***者實施成本極低，在網上可以隨便搜索到一大堆***腳本、工具工具，對***者的技術要求也越來越低。相反的是，專業抗DDoS設備的價格十分昂貴，而且對於***源的追查難度極大，防護成本遠遠大於***成本。
本文將對DDoS***的原理做一個剖析，並提供一些解決方法。
一. DDoS***
什麼是DDoS？DDoS是英文Distributed Denial of Service的縮寫，意即"分佈式拒絕服務",DDoS的中文名叫分佈式拒絕服務***，俗稱洪水***。首先，我們來了解一下相關定義。
服務：系統提供的，用戶在對其使用中會受益的功能
拒絕服務：任何對服務的干涉如果使其可用性降低或者失去可用性均稱爲拒絕服務。
拒絕服務***：是指***者通過某種手段，有意地造成計算機或網絡不能正常運轉從而不能向合法用戶提供所需要的服務或者使得服務質量降低
分佈式拒絕服務***：處於不同位置的多個***者同時向一個或者數個目標發起***，或者一個或多個***者控制了位於不同位置的多臺機器並利用這些機器對受害者同時實施***，由於***的發出點是分佈在不同地方的，這類***稱爲分佈式拒絕服務***。
 |
| 圖 |
如圖所示，DDoS***將造成網絡資源浪費、鏈路帶寬堵塞、服務器資源耗盡而業務中斷。這種***大多數是由***非法控制的電腦實施的。***非法控制一些電腦之後，把這些電腦轉變爲由地下網絡遠程控制的“bots”，然後用這些電腦實施DDoS***。***還以每臺爲單位，低價出租這些用於***的電腦，真正擁有這些電腦的主人並不知道自己的計算機已經被用來***別人。由於有數百萬臺電腦現在已經被***變成了“bots”，因此這種***將非常猛烈。被DDoS***時的現象：
網絡中充斥着大量的無用的數據包；
製造高流量無用數據，造成網絡擁塞，使受害主機無法正常和外界通訊；
利用受害主機提供的服務或傳輸協議上的缺陷，反覆高速的發出特定的服務請求，使受害主機無法及時處理所有正常請求；
嚴重時會造成系統死機。
由於網絡層的拒絕服務***有的利用了網絡協議的漏洞，有的則搶佔網絡或者設備有限的處理能力，使得對拒絕服務***的防治成爲了一個令管理員非常頭痛的問題。尤其是目前在大多數的網絡環境骨幹線路上普遍使用的防火牆、負載均衡等設備，在發生DDoS***的時候往往成爲整個網絡的瓶頸，造成全網的癱瘓。
二. 數據包結構
要了解DDoS的***原理，就要首先了解一下數據包的結構，才能知根知底，追本溯源。首先來回顧一下數據包的結構。
2.1 IP報文結構
 |
| 圖 |
2.2 TCP報文結構
 |
| 圖 |
一個TCP報頭的標識（code bits）字段包含6個標誌位：
SYN：標誌位用來建立連接，讓連接雙方同步序列號。如果SYN＝1而ACK=0，則表示該數據包爲連接請求，如果SYN=1而ACK=1則表示接受連接
FIN：表示發送端已經沒有數據要求傳輸了，希望釋放連接。
RST：用來複位一個連接。RST標誌置位的數據包稱爲復位包。一般情況下，如果TCP收到的一個分段明顯不是屬於該主機上的任何一個連接，則向遠端發送一個復位包。
URG：爲緊急數據標誌。如果它爲1，表示本數據包中包含緊急數據。此時緊急數據指針有效。
ACK：爲確認標誌位。如果爲1，表示包中的確認號時有效的。否則，包中的確認號無效。
PSH：如果置位，接收端應儘快把數據傳送給應用層, 不必等緩衝區滿再發送 。
2.3 UDP報文結構
 |
| 圖 |
2.4 ICMP報文結構
 |
| 圖 |
 |
| 圖 |
三. DDoS***方式
3.1 SYN Flood***
SYN-Flood***是當前網絡上最爲常見的DDoS***，也是最爲經典的拒絕服務***，它利用了TCP協議實現上的一個缺陷，通過向網絡服務所在端口發送大量的僞造源地址的***報文，就可能造成目標服務器中的半開連接隊列被佔滿，從而阻止其他合法用戶進行訪問。這種***早在1996年就被發現，但至今仍然顯示出強大的生命力。很多操作系統，甚至防火牆、路由器都無法有效地防禦這種***，而且由於它可以方便地僞造源地址，追查起來非常困難。它的數據包特徵通常是，源發送了大量的SYN包，並且缺少三次握手的最後一步握手ACK回覆。
3.1.1 原理
例如，***者首先僞造地址對服務器發起SYN請求（我可以建立連接嗎？），服務器就會迴應一個ACK+SYN（可以+請確認）。而真實的IP會認爲，我沒有發送請求，不作迴應。服務器沒有收到迴應，會重試3-5次並且等待一個SYN Time（一般30秒-2分鐘）後，丟棄這個連接。
如果***者大量發送這種僞造源地址的SYN請求，服務器端將會消耗非常多的資源來處理這種半連接，保存遍歷會消耗非常多的CPU時間和內存，何況還要不斷對這個列表中的IP進行SYN+ACK的重試。最後的結果是服務器無暇理睬正常的連接請求—拒絕服務。在服務器上用netstat –an命令查看SYN_RECV狀態的話，就可以看到：
 |
| 圖 |
如果我們抓包來看：
 |
| 圖 |
可以看到大量的SYN包沒有ACK迴應。
3.1.2 SYN Flood防護
目前市面上有些防火牆具有SYN Proxy功能，這種方法一般是定每秒通過指定對象（目標地址和端口、僅目標地址或僅源地址）的SYN片段數的閥值，當來自相同源地址或發往相同目標地址的SYN片段數達到這些閥值之一時，防火牆就開始截取連接請求和代理回覆SYN/ACK片段，並將不完全的連接請求存儲到連接隊列中直到連接完成或請求超時。當防火牆中代理連接的隊列被填滿時，防火牆拒絕來自相同安全區域（zone）中所有地址的新SYN片段，避免網絡主機遭受不完整的三次握手的***。但是，這種方法在***流量較大的時候，連接出現較大的延遲，網絡的負載較高，很多情況下反而成爲整個網絡的瓶頸；
Random Drop：隨機丟包的方式雖然可以減輕服務器的負載，但是正常連接的成功率也會降低很多；
特徵匹配：IPS上會常用的手段，在***發生的當時統計***報文的特徵，定義特徵庫，例如過濾不帶TCP Options 的syn 包等；
早期***工具（例如synkiller，xdos，hgod等）通常是發送64字節的TCP SYN報文，而主機操作系統在發起TCP連接請求時發送SYN 報文是大於64字節的。因此可以在關鍵節點上設置策略過濾64字節的TCP SYN報文，某些宣傳具有防護SYN Flood***的產品就是這麼做的。隨着工具的改進，發出的TCP SYN 報文完全模擬常見的通用操作系統，並且IP頭和TCP頭的字段完全隨機，這時就無法在設備上根據特定的規則來過濾***報文。這時就需要根據經驗判斷IP 包頭裏TTL值不合理的數據包並阻斷，但這種手工的方法成本高、效率低。 圖是某***工具屬性設置。
 |
| 圖 |
SYN Cookie：就是給每一個請求連接的IP地址分配一個Cookie，如果短時間內連續受到某個IP的重複SYN報文，就認定是受到了***，以後從這個IP地址來的包會被丟棄。但SYN Cookie依賴於對方使用真實的IP地址，如果***者利用SOCK_RAW隨機改寫IP報文中的源地址，這個方法就沒效果了。
3.1.3 商業產品的防護算法
syn cookie/syn proxy類防護算法：這種算法對所有的syn包均主動迴應，探測發起syn包的源IP地址是否真實存在；如果該IP地址真實存在，則該IP會迴應防護設備的探測包，從而建立TCP連接；大多數的國內外抗拒絕服務產品採用此類算法。
safereset算法：此算法對所有的syn包均主動迴應，探測包特意構造錯誤的字段，真實存在的IP地址會發送rst包給防護設備，然後發起第2次連接，從而建立TCP連接；部分國外產品採用了這樣的防護算法。
syn重傳算法：該算法利用了TCP/IP協議的重傳特性，來自某個源IP的第一個syn包到達時被直接丟棄並記錄狀態，在該源IP的第2個syn包到達時進行驗證，然後放行。
綜合防護算法：結合了以上算法的優點，並引入了IP信譽機制。當來自某個源IP的第一個syn包到達時，如果該IP的信譽值較高，則採用syncookie算法；而對於信譽值較低的源IP，則基於協議棧行爲模式，如果syn包得到驗證，則對該連接進入syncookie校驗，一旦該IP的連接得到驗證則提高其信譽值。有些設備還採用了表結構來存放協議棧行爲模式特徵值，大大減少了存儲量。
3.2 ACK Flood***
3.2.1 原理
ACK Flood***是在TCP連接建立之後，所有的數據傳輸TCP報文都是帶有ACK標誌位的，主機在接收到一個帶有ACK標誌位的數據包的時候，需要檢查該數據包所表示的連接四元組是否存在，如果存在則檢查該數據包所表示的狀態是否合法，然後再向應用層傳遞該數據包。如果在檢查中發現該數據包不合法，例如該數據包所指向的目的端口在本機並未開放，則主機操作系統協議棧會迴應RST包告訴對方此端口不存在。
這裏，服務器要做兩個動作：查表、迴應ACK/RST。這種***方式顯然沒有SYN Flood給服務器帶來的衝擊大，因此***者一定要用大流量ACK小包衝擊纔會對服務器造成影響。按照我們對TCP協議的理解，隨機源IP的ACK小包應該會被Server很快丟棄，因爲在服務器的TCP堆棧中沒有這些ACK包的狀態信息。但是實際上通過測試，發現有一些TCP服務會對ACK Flood比較敏感，比如說JSP Server，在數量並不多的ACK小包的打擊下，JSP Server就很難處理正常的連接請求。對於Apache或者IIS來說，10kpps的ACK Flood不構成危脅，但是更高數量的ACK Flood會造成服務器網卡中斷頻率過高，負載過重而停止響應。可以肯定的是，ACK Flood不但可以危害路由器等網絡設備，而且對服務器上的應用有不小的影響。抓包：
 |
| 圖 |
如果沒有開放端口，服務器將直接丟棄，這將會耗費服務器的CPU資源。如果端口開放，服務器迴應RST。
3.2.2 ACK Flood防護
利用對稱性判斷來分析出是否有***存在。所謂對稱型判斷，就是收包異常大於發包，因爲***者通常會採用大量ACK包，並且爲了提高***速度，一般採用內容基本一致的小包發送。這可以作爲判斷是否發生ACK Flood的依據，但是目前已知情況來看，很少有單純使用ACK Flood***，都會和其他***方法混合使用，因此，很容易產生誤判。
一些防火牆應對的方法是：建立一個hash表，用來存放TCP連接“狀態”，相對於主機的TCP stack實現來說，狀態檢查的過程相對簡化。例如，不作sequence number的檢查，不作包亂序的處理，只是統計一定時間內是否有ACK包在該“連接”(即四元組)上通過，從而“大致”確定該“連接”是否是“活動的”。
3.3 UDP Flood***
3.3.1 原理
UDP Flood是日漸猖厥的流量型DoS***，原理也很簡單。常見的情況是利用大量UDP小包衝擊DNS服務器或Radius認證服務器、流媒體視頻服務器。 100k pps的UDP Flood經常將線路上的骨幹設備例如防火牆打癱，造成整個網段的癱瘓。由於UDP協議是一種無連接的服務，在UDP FLOOD***中，***者可發送大量僞造源IP地址的小UDP包。但是，由於UDP協議是無連接性的，所以只要開了一個UDP的端口提供相關服務的話，那麼就可針對相關的服務進行***。
正常應用情況下，UDP包雙向流量會基本相等，而且大小和內容都是隨機的，變化很大。出現UDP Flood的情況下，針對同一目標IP的UDP包在一側大量出現，並且內容和大小都比較固定。***工具：
 |
| 圖 |
53端口的UDP Flood***抓圖：
 |
| 圖 |
UDP Flood大包***（佔帶寬，分片）：
 |
| 圖 |
3.3.2 UDP Flood防護
UDP協議與TCP 協議不同，是無連接狀態的協議，並且UDP應用協議五花八門，差異極大，因此針對UDP Flood的防護非常困難。其防護要根據具體情況對待：
判斷包大小，如果是大包***則使用防止UDP碎片方法：根據***包大小設定包碎片重組大小，通常不小於1500。在極端情況下，可以考慮丟棄所有UDP碎片。
***端口爲業務端口：根據該業務UDP最大包長設置UDP最大包大小以過濾異常流量。
***端口爲非業務端口：一個是丟棄所有UDP包，可能會誤傷正常業務；一個是建立UDP連接規則，要求所有去往該端口的UDP包，必須首先與TCP端口建立TCP連接。不過這種方法需要很專業的防火牆或其他防護設備支持。
3.4 ICMP Flood***
3.4.1 原理
ICMP Flood 的***原理和ACK Flood原理類似，屬於流量型的***方式，也是利用大的流量給服務器帶來較大的負載，影響服務器的正常服務。由於目前很多防火牆直接過濾ICMP報文，因此ICMP Flood出現的頻度較低。比較下面兩幅圖，就應該可以看出是否有ICMP Flood***。
正常ICMP包：
 |
| 圖 |
大包***的時候：
 |
| 圖 |
3.4.2 ICMP Flood防護
其防禦也很簡單，直接過濾ICMP報文。
3.5 Connection Flood***
3.5.1 原理
Connection Flood是典型的並且非常的有效的利用小流量衝擊大帶寬網絡服務的***方式，這種***方式目前已經越來越猖獗。這種***的原理是利用真實的IP地址向服務器發起大量的連接，並且建立連接之後很長時間不釋放，佔用服務器的資源，造成服務器服務器上殘餘連接(WAIT狀態)過多，效率降低，甚至資源耗盡，無法響應其他客戶所發起的連接。
其中一種***方法是每秒鐘向服務器發起大量的連接請求，這類似於固定源IP的SYN Flood***，不同的是採用了真實的源IP地址。通常這可以在防火牆上限制每個源IP地址每秒鐘的連接數來達到防護目的。但現在已有工具採用慢速連接的方式，也即幾秒鐘才和服務器建立一個連接，連接建立成功之後並不釋放並定時發送垃圾數據包給服務器使連接得以長時間保持。這樣一個IP地址就可以和服務器建立成百上千的連接，而服務器可以承受的連接數是有限的，這就達到了拒絕服務的效果。
另外，蠕蟲大規模爆發的時候，由於蠕蟲代碼則比較簡單，傳播過程中會出現大量源IP地址相同的包，對於 TCP 蠕蟲則表現爲大範圍掃描行爲。這是在判斷Connection Flood時需要注意的。
在受***的服務器上使用netstat –an來看：
 |
| 圖 |
存在大量連接狀態，來自少數的幾個源。如果統計的話，可以看到連接數對比平時出現異常。並且增長到某一值之後開始波動，說明此時可能已經接近性能極限。因此，對這種***的判斷：在流量上體現並不大，甚至可能會很小；大量的ESTABLISH狀態；新建的ESTABLISH狀態總數有波動。
3.5.2 Connection Flood防護
主動清除殘餘連接。
對惡意連接的IP進行封禁。
限制每個源IP的連接數。
可以對特定的URL進行防護。
反查Proxy後面發起HTTP Get Flood的源。
3.6 HTTP Get***
3.6.1 原理
這種***主要是針對存在ASP、JSP、PHP、CGI等腳本程序，並調用MSSQLServer、MySQLServer、Oracle等數據庫的網站系統而設計的，特徵是和服務器建立正常的TCP連接，並不斷的向腳本程序提交查詢、列表等大量耗費數據庫資源的調用，典型的以小博大的***方法。一般來說，提交一個GET或POST指令對客戶端的耗費和帶寬的佔用是幾乎可以忽略的，而服務器爲處理此請求卻可能要從上萬條記錄中去查出某個記錄，這種處理過程對資源的耗費是很大的，常見的數據庫服務器很少能支持數百個查詢指令同時執行，而這對於客戶端來說卻是輕而易舉的，因此***者只需通過Proxy代理向主機服務器大量遞交查詢指令，只需數分鐘就會把服務器資源消耗掉而導致拒絕服務，常見的現象就是網站慢如蝸牛、ASP程序失效、PHP連接數據庫失敗、數據庫主程序佔用CPU偏高。這種***的特點是可以完全繞過普通的防火牆防護，輕鬆找一些Proxy代理就可實施***，缺點是對付只有靜態頁面的網站效果會大打折扣，並且有些Proxy會暴露***者的IP地址。***工具：
 |
| 圖 |
在遭受***的服務器上抓包，大量不同IP在請求資源。在實際情況中，也有可能使用代理地址連接。
 |
3.6.2 HTTP Get防護
對是否HTTP Get的判斷，要統計到達每個服務器的每秒鐘的GET 請求數，如果遠遠超過正常值，就要對HTTP協議解碼，找出HTTP Get及其參數（例如URL等）。
然後判斷某個GET 請求是來自代理服務器還是惡意請求。並回應一個帶key的響應要求請求發起端作出相應的回饋。如果發起端並不響應則說明是利用工具發起的請求，這樣HTTP Get請求就無法到達服務器，達到防護的效果。
3.7 UDP DNS Query Flood***
3.7.1 原理
UDP DNS Query Flood***實質上是UDP Flood的一種，但是由於DNS服務器的不可替代的關鍵作用，一旦服務器癱瘓，影響一般都很大。
UDP DNS Query Flood***採用的方法是向被***的服務器發送大量的域名解析請求，通常請求解析的域名是隨機生成或者是網絡世界上根本不存在的域名，被***的DNS 服務器在接收到域名解析請求的時候首先會在服務器上查找是否有對應的緩存，如果查找不到並且該域名無法直接由服務器解析的時候，DNS 服務器會向其上層DNS服務器遞歸查詢域名信息。域名解析的過程給服務器帶來了很大的負載，每秒鐘域名解析請求超過一定的數量就會造成DNS服務器解析域名超時。
根據微軟的統計數據，一臺DNS服務器所能承受的動態域名查詢的上限是每秒鐘9000個請求。而我們知道，在一臺P3的PC機上可以輕易地構造出每秒鐘幾萬個域名解析請求，足以使一臺硬件配置極高的DNS服務器癱瘓，由此可見DNS 服務器的脆弱性。同時需要注意的是，蠕蟲擴散也會帶來大量的域名解析請求。
3.7.2 UDP DNS Query Flood防護
在UDP Flood的基礎上對 UDP DNS Query Flood ***進行防護
根據域名 IP 自學習結果主動迴應，減輕服務器負載（使用 DNS Cache）
對突然發起大量頻度較低的域名解析請求的源 IP 地址進行帶寬限制 在***發生時降低很少發起域名解析請求的源 IP 地址的優先級
限制每個源 IP 地址每秒的域名解析請求次數
四. 總結
看完這篇文章，您已經瞭解了7種主流的DDoS***方式，並且也瞭解了相應的解決方法。雖然道高一尺，魔高一丈，新的***方法也在源源不斷出現。但是，只要您掌握了相應的原理，破解DDoS***並非難事，不過其前提是您在掌握原理的基礎上，還需要有相應的軟件、硬件來對抗。本文的最後，給出幾個小題目，幫您回憶一下前面所說的內容。
1. 對上述方法的總結。
2. 如果您的主要業務是UDP音頻應用，爲了維護利益，儘可能降低***對其業務的影響，您平時應該如何關注？
3. 殭屍網絡是個無堅不摧的矛嗎？如何緩解來自殭屍網絡的***帶來的影響？如果一次ACK-Flood的***流量是通過殭屍網絡發出來的，那麼它通常會帶有什麼特徵。