深刻淺出DDoS***

敵情篇 ——DDoS***原理

DDoS***基礎

DDoS（Distributed Denial of Service，分佈式拒絕服務）***的主要目的是讓指定目標沒法提供正常服務，甚至從互聯網上消失，是目前最強大、最難防護的***之一。

按照發起的方式，DDoS能夠簡單分爲三類。

第一類以力取勝，海量數據包從互聯網的各個角落蜂擁而來，堵塞IDC入口，讓各類強大的硬件防護系統、快速高效的應急流程無用武之地。這種類型的***典型表明是ICMP Flood和UDP Flood，如今已不常見。

第二類以巧取勝，靈動而難以察覺，每隔幾分鐘發一個包甚至只須要一個包，就可讓豪華配置的服務器再也不響應。這類***主要是利用協議或者軟件的漏洞發起，例如Slowloris***、Hash衝突***等，須要特定環境機緣巧合下才能出現。

第三類是上述兩種的混合，輕靈渾厚兼而有之，既利用了協議、系統的缺陷，又具有了海量的流量，例如SYN Flood***、DNS Query Flood***，是當前的主流***方式。

本文將一一描述這些最多見、最具表明性***方式，並介紹它們的防護方案。

SYN Flood

SYN Flood是互聯網上最經典的DDoS***方式之一，最先出現於1999年左右，雅虎是當時最著名的受害者。SYN Flood***利用了TCP三次握手的缺陷，可以以較小代價使目標服務器沒法響應，且難以追查。

標準的TCP三次握手過程以下：

• 客戶端發送一個包含SYN標誌的TCP報文，SYN即同步（Synchronize），同步報文會指明客戶端使用的端口以及TCP鏈接的初始序號；

• 服務器在收到客戶端的SYN報文後，將返回一個SYN+ACK（即確認Acknowledgement）的報文，表示客戶端的請求被接受，同時TCP初始序號自動加1；

• 客戶端也返回一個確認報文ACK給服務器端，一樣TCP序列號被加1。

  
  

經 過這三步，TCP鏈接就創建完成。TCP協議爲了實現可靠傳輸，在三次握手的過程當中設置了一些異常處理機制。第三步中若是服務器沒有收到客戶端的最終 ACK確認報文，會一直處於SYN_RECV狀態，將客戶端IP加入等待列表，並重發第二步的SYN+ACK報文。重發通常進行3-5次，大約間隔30秒 左右輪詢一次等待列表重試全部客戶端。另外一方面，服務器在本身發出了SYN+ACK報文後，會預分配資源爲即將創建的TCP鏈接儲存信息作準備，這個資源 在等待重試期間一直保留。更爲重要的是，服務器資源有限，能夠維護的SYN_RECV狀態超過極限後就再也不接受新的SYN報文，也就是拒絕新的TCP鏈接 創建。

SYN Flood正是利用了上文中TCP協議的設定，達到***的目的。***者假裝大量的IP地址給服務器發送SYN報文，因爲僞造的IP地址幾乎不可能存在，也 就幾乎沒有設備會給服務器返回任何應答了。所以，服務器將會維持一個龐大的等待列表，不停地重試發送SYN+ACK報文，同時佔用着大量的資源沒法釋放。 更爲關鍵的是，被***服務器的SYN_RECV隊列被惡意的數據包占滿，再也不接受新的SYN請求，合法用戶沒法完成三次握手創建起TCP鏈接。也就是說， 這個服務器被SYN Flood拒絕服務了。

對SYN Flood有興趣的能夠看看http://www.icylife.net/yunshu/show.php?id=367，這是我2006年寫的代碼，後來作過幾回修改，修改了Bug，並下降了***性，純作測試使用。

DNS Query Flood

做 爲互聯網最基礎、最核心的服務，DNS天然也是DDoS***的重要目標之一。打垮DNS服務可以間接打垮一家公司的所有業務，或者打垮一個地區的網絡服 務。前些時候風頭正盛的***組織anonymous也曾經宣佈要***全球互聯網的13臺根DNS服務器，不過最終沒有得手。

UDP ***是最容易發起海量流量的***手段，並且源IP隨機僞造難以追查。但過濾比較容易，由於大多數IP並不提供UDP服務，直接丟棄UDP流量便可。因此現 在純粹的UDP流量***比較少見了，取而代之的是UDP協議承載的DNS Query Flood***。簡單地說，越上層協議上發動的DDoS***越難以防護，由於協議越上層，與業務關聯越大，防護系統面臨的狀況越複雜。

DNS Query Flood就是***者操縱大量傀儡機器，對目標發起海量的域名查詢請求。爲了防止基於ACL的過濾，必須提升數據包的隨機性。經常使用的作法是UDP層隨機僞 造源IP地址、隨機僞造源端口等參數。在DNS協議層，隨機僞造查詢ID以及待解析域名。隨機僞造待解析域名除了防止過濾外，還能夠下降命中DNS緩存的 可能性，儘量多地消耗DNS服務器的CPU資源。

關於DNS Query Flood的代碼，我在2011年7月爲了測試服務器性能曾經寫過一份代碼，連接是http://www.icylife.net/yunshu/show.php?id=832。一樣的，這份代碼人爲下降了***性，只作測試用途。

HTTP Flood

上 文描述的SYN Flood、DNS Query Flood在現階段已經能作到有效防護了，真正令各大廠商以及互聯網企業頭疼的是HTTP Flood***。HTTP Flood是針對Web服務在第七層協議發起的***。它的巨大危害性主要表如今三個方面：發起方便、過濾困難、影響深遠。

SYN Flood和DNS Query Flood都須要***者以root權限控制大批量的傀儡機。收集大量root權限的傀儡機很花費時間和精力，並且在***過程當中傀儡機會因爲流量異常被管理 員發現，***者的資源快速損耗而補充緩慢，致使***強度明顯下降並且不可長期持續。HTTP Flood***則不一樣，***者並不須要控制大批的傀儡機，取而代之的是經過端口掃描程序在互聯網上尋找匿名的HTTP代理或者SOCKS代理，***者經過 匿名代理對***目標發起HTTP請求。匿名代理是一種比較豐富的資源，花幾天時間獲取代理並非難事，所以***容易發起並且能夠長期高強度的持續。

另外一方面，HTTP Flood***在HTTP層發起，極力模仿正經常使用戶的網頁請求行爲，與網站業務緊密相關，安全廠商很難提供一套通用的且不影響用戶體驗的方案。在一個地方工做得很好的規則，換一個場景可能帶來大量的誤殺。

最後，HTTP Flood***會引發嚴重的連鎖反應，不只僅是直接致使被***的Web前端響應緩慢，還間接***到後端的Java等業務層邏輯以及更後端的數據庫服務，增大它們的壓力，甚至對日誌存儲服務器都帶來影響。

有 意思的是，HTTP Flood還有個很有歷史淵源的暱稱叫作CC***。CC是Challenge Collapsar的縮寫，而Collapsar是國內一家著名安全公司的DDoS防護設備。從目前的狀況來看，不只僅是Collapsar，全部的硬件 防護設備都還在被挑戰着，風險並未解除。

慢速鏈接***

提起***，第一反應就是海量的流量、海量的報文。但有一種***卻反其道而行之，以慢著稱，以致於有些***目標被打死了都不知道是怎麼死的，這就是慢速鏈接***，最具表明性的是rsnake發明的Slowloris。

HTTP 協議規定，HTTP Request以\r\n\r\n結尾表示客戶端發送結束，服務端開始處理。那麼，若是永遠不發送\r\n\r\n會如何？Slowloris就是利用這 一點來作DDoS***的。***者在HTTP請求頭中將Connection設置爲Keep-Alive，要求Web Server保持TCP鏈接不要斷開，隨後緩慢地每隔幾分鐘發送一個key-value格式的數據到服務端，如a:b\r\n，致使服務端認爲HTTP頭 部沒有接收完成而一直等待。若是***者使用多線程或者傀儡機來作一樣的操做，服務器的Web容器很快就被***者佔滿了TCP鏈接而再也不接受新的請求。

很 快的，Slowloris開始出現各類變種。好比POST方法向Web Server提交數據、填充一大大Content-Length但緩慢的一個字節一個字節的POST真正數據內容等等。關於Slowloris攻 擊，rsnake也給出了一個測試代碼，參見http://ha.ckers.org/slowloris/slowloris.pl。

DDoS***進階

混合***

以上介紹了幾種基礎的***手段，其中任意一種均可以用來***網絡，甚至擊垮阿里、百度、騰訊這種巨型網站。但這些並非所有，不一樣層次的***者可以發起徹底不一樣的DDoS***，運用之妙，存乎一心。

高 級***者歷來不會使用單一的手段進行***，而是根據目標環境靈活組合。普通的SYN Flood容易被流量清洗設備經過反向探測、SYN Cookie等技術手段過濾掉，但若是在SYN Flood中混入SYN+ACK數據包，使每個僞造的SYN數據包都有一個與之對應的僞造的客戶端確認報文，這裏的對應是指源IP地址、源端口、目的 IP、目的端口、TCP窗口大小、TTL等都符合同一個主機同一個TCP Flow的特徵，流量清洗設備的反向探測和SYN Cookie性能壓力將會顯著增大。其實SYN數據報文配合其餘各類標誌位，都有特殊的***效果，這裏不一一介紹。對DNS Query Flood而言，也有獨特的技巧。

首 先，DNS能夠分爲普通DNS和受權域DNS，***普通DNS，IP地址須要隨機僞造，而且指明服務器要求作遞歸解析；但***受權域DNS，僞造的源IP 地址則不該該是純隨機的，而應該是事先收集的全球各地ISP的DNS地址，這樣才能達到最大***效果，使流量清洗設備處於添加IP黑名單仍是不添加IP黑 名單的尷尬處境。添加會致使大量誤殺，不添加黑名單則每一個報文都須要反向探測從而加大性能壓力。

另 一方面，前面提到，爲了加大清洗設備的壓力不命中緩存而須要隨機化請求的域名，但須要注意的是，待解析域名必須在僞造中帶有必定的規律性，好比說只僞造域 名的某一部分而固化一部分，用來突破清洗設備設置的白名單。道理很簡單，騰訊的服務器能夠只解析騰訊的域名，徹底隨機的域名可能會直接被丟棄，須要固化。 但若是徹底固定，也很容易直接被丟棄，所以又須要僞造一部分。

其次，對DNS的***不該該只着重於UDP端口，根據DNS協議，TCP端口也是標準服務。在***時，能夠UDP和TCP***同時進行。

HTTP Flood的着重點，在於突破前端的cache，經過HTTP頭中的字段設置直接到達Web Server自己。另外，HTTP Flood對目標的選取也很是關鍵，通常的***者會選擇搜索之類須要作大量數據查詢的頁面做爲***目標，這是很是正確的，能夠消耗服務器儘量多的資源。 但這種***容易被清洗設備經過人機識別的方式識別出來，那麼如何解決這個問題？很簡單，儘可能選擇正經常使用戶也經過APP訪問的頁面，通常來講就是各類Web API。正經常使用戶和惡意流量都是來源於APP，人機差異很小，基本融爲一體難以區分。

之 類的慢速***，是經過巧妙的手段佔住鏈接不釋放達到***的目的，但這也是雙刃劍，每個TCP鏈接既存在於服務端也存在於自身，自身也須要消耗資源維持 TCP狀態，所以鏈接不能保持太多。若是能夠解決這一點，***性會獲得極大加強，也就是說Slowloris能夠經過stateless的方式發動***， 在客戶端經過嗅探捕獲TCP的序列號和確認維護TCP鏈接，系統內核無需關注TCP的各類狀態變遷，一臺筆記本便可產生多達65535個TCP鏈接。

前 面描述的，都是技術層面的***加強。在人的方面，還能夠有一些別的手段。若是SYN Flood發出大量數據包正面強攻，再輔之以Slowloris慢速鏈接，多少人可以發現其中的祕密？即便服務器宕機了也許還只發現了SYN***想去增強 TCP層清洗而忽視了應用層的行爲。種種***均可以互相配合，達到最大的效果。***時間的選擇，也是一大關鍵，好比說選擇維護人員吃午餐時、維護人員下班 堵在路上或者在地鐵裏無線上網卡都沒有信號時、目標企業在舉行大規模活動流量飆升時等。

這裏描述的只是純粹的***行爲，所以不提供代碼，也不作深刻介紹。

來自P2P網絡的***

前面的***方式，多多少少都須要一些傀儡機，即便是HTTP Flood也須要搜索大量的匿名代理。若是有一種***，只須要發出一些指令，就有機器自動上來執行，纔是完美的方案。這種***已經出現了，那就是來自P2P網絡的***。

大 家都知道，互聯網上的P2P用戶和流量都是一個極爲龐大的數字。若是他們都去一個指定的地方下載數據，使成千上萬的真實IP地址鏈接過來，沒有哪一個設備能 夠支撐住。拿BT下載來講，僞造一些熱門視頻的種子，發佈到搜索引擎，就足以騙到許多用戶和流量了，但這只是基礎***。

應對篇 ——DDoS防護方案

防護基礎

***流量到底多大

談到DDoS防護，首先就是要知道到底遭受了多大的***。這個問題看似簡單，實際上卻有不少鮮爲人知的細節在裏面。

以SYN Flood爲例，爲了提升發送效率在服務端產生更多的SYN等待隊列，***程序在填充包頭時，IP首部和TCP首部都不填充可選的字段，所以IP首部長度剛好是20字節，TCP首部也是20字節，共40字節。

對 於以太網來講，最小的包長度數據段必須達到46字節，而***報文只有40字節，所以，網卡在發送時，會作一些處理，在TCP首部的末尾，填充6個0來知足 最小包的長度要求。這個時候，整個數據包的長度爲14字節的以太網頭，20字節的IP頭，20字節的TCP頭，再加上由於最小包長度要求而填充的6個字節 的0，一共是60字節。

但這尚未結束。以太網在傳輸數據時，還有CRC檢驗的要求。網卡會在發送數據以前對數據包進行CRC檢驗，將4字節的CRC值附加到包頭的最後面。這個時候，數據包長度已再也不是40字節，而是變成64字節了，這就是常說的SYN小包***，數據包結構以下：

|14字節以太網頭部|20字節IP頭部|20字節TCP|6字節填充|4字節檢驗|
|目的MAC|源MAC|協議類型| IP頭 |TCP頭|以太網填充 | CRC檢驗 |

到64字節時，SYN數據包已經填充完成，準備開始傳輸了。***數據包很小，遠遠不夠最大傳輸單元（MTU）的1500字節，所以不會被分片。那麼這些數據包就像生產流水線上的罐頭同樣，一個包連着一個包緊密地擠在一塊兒傳輸嗎？事實上不是這樣的。

以 太網在傳輸時，還有前導碼（preamble）和幀間距（inter-frame gap）。其中前導碼佔8字節（byte），即64比特位。前導碼前面的7字節都是10101010，1和0間隔而成。但第八個字節就變成了 10101011，當主機監測到連續的兩個1時，就知道後面開始是數據了。在網絡傳輸時，數據的結構以下：

|8字節前導碼|6字節目的MAC地址|6字節源MAC地址|2字節上層協議類型|20字節IP頭|20字節TCP頭|6字節以太網填充|4字節CRC檢驗|12字節幀間距|

也就是說，一個原本只有40字節的SYN包，在網絡上傳輸時佔的帶寬，實際上是84字節。

有 了上面的基礎，如今能夠開始計算***流量和網絡設備的線速問題了。當只填充IP頭和TCP頭的最小SYN包跑在以太網絡上時，100Mbit的網絡，能支 持的最大PPS（Packet Per Second）是100×106 / (8 * (64+8+12)) = 148809，1000Mbit的網絡，能支持的最大PPS是1488090。

SYN Flood防護

前文描述過，SYN Flood***大量消耗服務器的CPU、內存資源，並佔滿SYN等待隊列。相應的，咱們修改內核參數便可有效緩解。主要參數以下：

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_synack_retries = 2

分別爲啓用SYN Cookie、設置SYN最大隊列長度以及設置SYN+ACK最大重試次數。

SYN Cookie的做用是緩解服務器資源壓力。啓用以前，服務器在接到SYN數據包後，當即分配存儲空間，並隨機化一個數字做爲SYN號發送SYN+ACK數 據包。而後保存鏈接的狀態信息等待客戶端確認。啓用SYN Cookie以後，服務器再也不分配存儲空間，並且經過基於時間種子的隨機數算法設置一個SYN號，替代徹底隨機的SYN號。發送完SYN+ACK確認報文 以後，清空資源不保存任何狀態信息。直到服務器接到客戶端的最終ACK包，經過Cookie檢驗算法鑑定是否與發出去的SYN+ACK報文序列號匹配，匹 配則經過完成握手，失敗則丟棄。固然，前文的高級***中有SYN混合ACK的***方法，則是對此種防護方法的反擊，其中優劣由雙方的硬件配置決定

tcp_max_syn_backlog 則是使用服務器的內存資源，換取更大的等待隊列長度，讓***數據包不至於佔滿全部鏈接而致使正經常使用戶沒法完成握手。 net.ipv4.tcp_synack_retries是下降服務器SYN+ACK報文重試次數，儘快釋放等待資源。這三種措施與***的三種危害一一對 應，完徹底全地對症下藥。但這些措施也是雙刃劍，可能消耗服務器更多的內存資源，甚至影響正經常使用戶創建TCP鏈接，須要評估服務器硬件資源和***大小謹慎 設置。

除 了定製TCP/IP協議棧以外，還有一種常見作法是TCP首包丟棄方案，利用TCP協議的重傳機制識別正經常使用戶和***報文。當防護設備接到一個IP地址的 SYN報文後，簡單比對該IP是否存在於白名單中，存在則轉發到後端。如不存在於白名單中，檢查是不是該IP在必定時間段內的首次SYN報文，不是則檢查 是否重傳報文，是重傳則轉發並加入白名單，不是則丟棄並加入黑名單。是首次SYN報文則丟棄並等待一段時間以試圖接受該IP的SYN重傳報文，等待超時則 斷定爲***報文加入黑名單。

首 包丟棄方案對用戶體驗會略有影響，由於丟棄首包重傳會增大業務的響應時間，有鑑於此發展出了一種更優的TCP Proxy方案。全部的SYN數據報文由清洗設備接受，按照SYN Cookie方案處理。和設備成功創建了TCP三次握手的IP地址被斷定爲合法用戶加入白名單，由設備假裝真實客戶端IP地址再與真實服務器完成三次握 手，隨後轉發數據。而指定時間內沒有和設備完成三次握手的IP地址，被斷定爲惡意IP地址屏蔽必定時間。除了SYN Cookie結合TCP Proxy外，清洗設備還具有多種畸形TCP標誌位數據包探測的能力，經過對SYN報文返回非預期應答測試客戶端反應的方式來鑑別正常訪問和惡意行爲。

清洗設備的硬件具備特殊的網絡處理器芯片和特別優化的操做系統、TCP/IP協議棧，能夠處理很是巨大的流量和SYN隊列。

HTTP Flood防護

HTTP Flood***防護主要經過緩存的方式進行，儘可能由設備的緩存直接返回結果來保護後端業務。大型的互聯網企業，會有龐大的CDN節點緩存內容。

當 高級***者穿透緩存時，清洗設備會截獲HTTP請求作特殊處理。最簡單的方法就是對源IP的HTTP請求頻率作統計，高於必定頻率的IP地址加入黑名單。 這種方法過於簡單，容易帶來誤殺，而且沒法屏蔽來自代理服務器的***，所以逐漸廢止，取而代之的是JavaScript跳轉人機識別方案。

HTTP Flood是由程序模擬HTTP請求，通常來講不會解析服務端返回數據，更不會解析JS之類代碼。所以當清洗設備截獲到HTTP請求時，返回一段特殊JavaScript代碼，正經常使用戶的瀏覽器會處理並正常跳轉不影響使用，而***程序會***到空處。

DNS Flood防護

DNS***防護也有相似HTTP的防護手段，第一方案是緩存。其次是重發，能夠是直接丟棄DNS報文致使UDP層面的請求重發，能夠是返回特殊響應強制要求客戶端使用TCP協議重發DNS查詢請求。

特殊的，對於受權域DNS的保護，設備會在業務正常時期提取收到的DNS域名列表和ISP DNS IP列表備用，在***時，非此列表的請求一概丟棄，大幅下降性能壓力。對於域名，實行一樣的域名白名單機制，非白名單中的域名解析請求，作丟棄處理。

慢速鏈接***防護

Slowloris***防護比較簡單，主要方案有兩個。

第 一個是統計每一個TCP鏈接的時長並計算單位時間內經過的報文數量便可作精確識別。一個TCP鏈接中，HTTP報文太少和報文太多都是不正常的，過少多是 慢速鏈接***，過多多是使用HTTP 1.1協議進行的HTTP Flood***，在一個TCP鏈接中發送多個HTTP請求。

第二個是限制HTTP頭部傳輸的最大許可時間。超過指定時間HTTP Header尚未傳輸完成，直接斷定源IP地址爲慢速鏈接***，中斷鏈接並加入黑名單。

企業級防護

互聯網企業防護DDoS***，主要使用上文的基礎防護手段，重點在於監控、組織以及流程。

監 控須要具有多層監控、縱深防護的概念，從骨幹網絡、IDC入口網絡的BPS、PPS、協議分佈，負載均衡層的VIP新建鏈接數、併發鏈接數、BPS、 PPS到主機層的CPU狀態、TCP新建鏈接數狀態、TCP併發鏈接數狀態，到業務層的業務處理量、業務連通性等多個點部署監控系統。即便一個監控點失 效，其餘監控點也可以及時給出報警信息。多個點信息結合，準確判斷被***目標和***手法。

一 旦發現異常，當即啓動在虛擬防護組織中的應急流程，防護組織須要囊括到足夠全面的人員，至少包含監控部門、運維部門、網絡部門、安所有門、客服部門、業務 部門等，全部人員都須要2-3個備份。流程啓動後，除了人工處理，還應該包含必定的自動處理、半自動處理能力。例如自動化的***分析，肯定***類型，自動 化、半自動化的防護策略，在安全人員到位以前，最早發現***的部門能夠作一些緩解措施。

除 了DDoS到來之時的流程等工做以外，更多的工做是在***到來以前。主要包含CDN節點部署、DNS設置、流程演習等。對於企業來講，具有多個CDN節點 是DDoS防護容量的關鍵指標。當一個機房承擔不住海量數據時，能夠經過DNS輪詢的方式，把流量引導到多個分佈節點，使用防護設備分頭處理。所以DNS 的TTL值須要設置得足夠小，可以快速切換，每一個CDN節點的各類VIP設置也須要準備充分。

在 虛擬化時代，各類用戶的不一樣業務共處在相同的物理機平臺，遭受DDoS***的可能性愈來愈高，並且一個用戶被***可能牽扯到大量的其餘用戶，危害被顯著放 大，所以防護顯得尤其重要。阿里雲的虛擬化業務，平均天天遭受約20起DDoS***，最大流量達到接近20Gbit/s，全部這些***都在15分鐘內自動 處理完成，讓客戶遠離DDoS的威脅，專心發展業務。

總地來講，對DDoS防護，主要的工做是幕後積累。臺上十分鐘，臺下十年功，沒有充分的資源準備，沒有足夠的應急演練，沒有豐富的處理經驗，DDoS***將是全部人的噩夢。

相關連接：http://blog.aliyun.com/author/aliyun_blog?spm=0.0.0.0.qTzxdl