如何防禦DDOS攻擊？
阿新 • • 發佈：2019-01-17
一、DDos簡介
DDoS（Distributed DenialofService，分散式拒絕服務）攻擊的主要目的是讓指定目標無法提供正常服務，甚至從網際網路上消失，是目前最強大、最難防禦的攻擊之一。這是一個世界級的難題並沒有解決辦法只能緩解.
按照發起的方式，DDoS可以簡單分為三類。
第一類以力取勝，海量資料包從網際網路的各個角落蜂擁而來，堵塞IDC入口，讓各種強大的硬體防禦系統、快速高效的應急流程無用武之地。這種型別的攻擊典型代表是ICMP Flood和UDP Flood，現在已不常見。
第二類以巧取勝，靈動而難以察覺，每隔幾分鐘發一個包甚至只需要一個包，就可以讓豪華配置的伺服器不再響應。這類攻擊主要是利用協議或者軟體的漏洞發起，例如Slowloris攻擊、Hash衝突攻擊等，需要特定環境機緣巧合下才能出現。
第三類是上述兩種的混合，輕靈渾厚兼而有之，既利用了協議、系統的缺陷，又具備了海量的流量，例如SYN Flood攻擊、DNS Query Flood攻擊，是當前的主流攻擊方式。
本文將一一描述這些最常見、最具代表性攻擊方式，並介紹它們的防禦方案。
二、DDOS基礎攻擊
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拒絕服務了。
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攻擊會引起嚴重的連鎖反應，不僅僅是直接導致被攻擊的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下載來說，偽造一些熱門視訊的種子，釋出到搜尋引擎，就足以騙到許多使用者和流量了，但這只是基礎攻擊。 高階P2P攻擊，是直接欺騙資源管理伺服器。如迅雷客戶端會把自己發現的資源上傳到資源管理伺服器，然後推送給其他需要下載相同資源的使用者，這樣，一個連結就釋出出去。通過協議逆向，攻擊者偽造出大批量的熱門資源資訊通過資源管理中心分發出去，瞬間就可以傳遍整個P2P網路。更為恐怖的是，這種攻擊是無法停止的，即使是攻擊者自身也無法停止，攻擊一直持續到P2P官方發現問題更新伺服器且下載使用者重啟下載軟體時為止。
CC攻擊
ChallengeCollapsar的名字源於挑戰國內知名安全廠商綠盟的抗DDOS裝置-“黑洞”，通過botnet的傀儡主機或尋找匿名代理伺服器，向目標發起大量真實的http請求，最終消耗掉大量的併發資源，拖慢整個網站甚至徹底拒絕服務。
網際網路的架構追求擴充套件性本質上是為了提高併發能力，各種SQL效能優化措施：消除慢查詢、分表分庫、索引、優化資料結構、限制搜尋頻率等本質都是為了解決資源消耗，而CC大有反其道而行之的意味，佔滿伺服器併發連線數，儘可能使請求避開快取而直接讀資料庫，讀資料庫要找最消耗資源的查詢，最好無法利用索引，每個查詢都全表掃描，這樣就能用最小的攻擊資源起到最大的拒絕服務效果。
網際網路產品和服務依靠資料分析來驅動改進和持續運營，所以除了前端的APP、中介軟體和資料庫這類OLTP系統，後面還有OLAP，從日誌收集，儲存到資料處理和分析的大資料平臺，當CC攻擊發生時，不僅OLTP的部分受到了影響，實際上CC會產生大量日誌，直接會對後面的OLAP產生影響，影響包括兩個層面，一個當日的資料統計完全是錯誤的。第二個層面因CC期間訪問日誌劇增也會加大後端資料處理的負擔。
CC是目前應用層攻擊的主要手段之一，在防禦上有一些方法，但不能完美解決這個問題。
反射型攻擊
2004年時DRDOS第一次披露，通過將SYN包的源地址設定為目標地址，然後向大量的真實TCP伺服器傳送TCP的SYN包，而這些收到SYN包的TCP server為了完成3次握手把SYN|ACK包“應答”給目標地址，完成了一次“反射”攻擊，攻擊者隱藏了自身，但有個問題是攻擊者製造的流量和目標收到的攻擊流量是1:1，且SYN|ACK包到達目標後馬上被回以RST包，整個攻擊的投資回報率不高。
反射型攻擊的本質是利用“質詢-應答”式協議，將質詢包的源地址通過原始套接字偽造設定為目標地址，則應答的“回包”都被髮送至目標，如果回包體積比較大或協議支援遞迴效果，攻擊流量會被放大，成為一種高性價比的流量型攻擊。
反射型攻擊利用的協議目前包括NTP、Chargen、SSDP、DNS、RPC portmap等等。
四、DDOS 攻擊防禦 攻擊流量到底多大，這是一個關鍵問題。攻擊量的大小。用的防護方法不一樣。下面給你講一講，1G之內的防護方式。費用在，<1萬，每月
談到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攻擊很難通過某一種手段做到完全防禦，很多中小型企業，沒有能力也沒有財力來對抗DDOS攻擊。但通過下面的幾點，還是可以做到簡單的防禦：
保證伺服器系統的安全
首先要確保伺服器軟體沒有任何漏洞，防止攻擊者入侵。確保伺服器採用最新系統，並打上安全補丁。在伺服器上刪除未使用的服務，關閉未使用的埠。對於伺服器上執行的網站，確保其打了最新的補丁，沒有安全漏洞。
隱藏伺服器真實IP
伺服器前端加CDN中轉（免費的有百度雲加速、360網站衛士、加速樂、安全寶等），如果資金充裕的話，可以購買高防的盾機，用於隱藏伺服器真實IP，域名解析使用CDN的IP，所有解析的子域名都使用CDN的IP地址。此外，伺服器上部署的其他域名也不能使用真實IP解析，全部都使用CDN來解析。 另外，防止伺服器對外傳送資訊洩漏IP，最常見的是，伺服器不使用傳送郵件功能，如果非要傳送郵件，可以通過第三方代理（例如sendcloud）傳送，這樣對外顯示的IP是代理的IP。 總之，只要伺服器的真實IP不洩露，10G以下小流量DDOS的預防花不了多少錢，免費的CDN就可以應付得了。如果攻擊流量超過20G，那麼免費的CDN可能就頂不住了，需要購買一個高防的盾機來應付了，而伺服器的真實IP同樣需要隱藏。
DDoS（Distributed DenialofService，分散式拒絕服務）攻擊的主要目的是讓指定目標無法提供正常服務，甚至從網際網路上消失，是目前最強大、最難防禦的攻擊之一。這是一個世界級的難題並沒有解決辦法只能緩解.
按照發起的方式，DDoS可以簡單分為三類。
第一類以力取勝，海量資料包從網際網路的各個角落蜂擁而來，堵塞IDC入口，讓各種強大的硬體防禦系統、快速高效的應急流程無用武之地。這種型別的攻擊典型代表是ICMP Flood和UDP Flood，現在已不常見。
第二類以巧取勝，靈動而難以察覺，每隔幾分鐘發一個包甚至只需要一個包，就可以讓豪華配置的伺服器不再響應。這類攻擊主要是利用協議或者軟體的漏洞發起，例如Slowloris攻擊、Hash衝突攻擊等，需要特定環境機緣巧合下才能出現。
第三類是上述兩種的混合，輕靈渾厚兼而有之，既利用了協議、系統的缺陷，又具備了海量的流量，例如SYN Flood攻擊、DNS Query Flood攻擊，是當前的主流攻擊方式。
本文將一一描述這些最常見、最具代表性攻擊方式，並介紹它們的防禦方案。
二、DDOS基礎攻擊
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拒絕服務了。
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
最後，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下載來說，偽造一些熱門視訊的種子，釋出到搜尋引擎，就足以騙到許多使用者和流量了，但這只是基礎攻擊。 高階P2P攻擊，是直接欺騙資源管理伺服器。如迅雷客戶端會把自己發現的資源上傳到資源管理伺服器，然後推送給其他需要下載相同資源的使用者，這樣，一個連結就釋出出去。通過協議逆向，攻擊者偽造出大批量的熱門資源資訊通過資源管理中心分發出去，瞬間就可以傳遍整個P2P網路。更為恐怖的是，這種攻擊是無法停止的，即使是攻擊者自身也無法停止，攻擊一直持續到P2P官方發現問題更新伺服器且下載使用者重啟下載軟體時為止。
CC攻擊
ChallengeCollapsar的名字源於挑戰國內知名安全廠商綠盟的抗DDOS裝置-“黑洞”，通過botnet的傀儡主機或尋找匿名代理伺服器，向目標發起大量真實的http請求，最終消耗掉大量的併發資源，拖慢整個網站甚至徹底拒絕服務。
網際網路的架構追求擴充套件性本質上是為了提高併發能力，各種SQL效能優化措施：消除慢查詢、分表分庫、索引、優化資料結構、限制搜尋頻率等本質都是為了解決資源消耗，而CC大有反其道而行之的意味，佔滿伺服器併發連線數，儘可能使請求避開快取而直接讀資料庫，讀資料庫要找最消耗資源的查詢，最好無法利用索引，每個查詢都全表掃描，這樣就能用最小的攻擊資源起到最大的拒絕服務效果。
網際網路產品和服務依靠資料分析來驅動改進和持續運營，所以除了前端的APP、中介軟體和資料庫這類OLTP系統，後面還有OLAP，從日誌收集，儲存到資料處理和分析的大資料平臺，當CC攻擊發生時，不僅OLTP的部分受到了影響，實際上CC會產生大量日誌，直接會對後面的OLAP產生影響，影響包括兩個層面，一個當日的資料統計完全是錯誤的。第二個層面因CC期間訪問日誌劇增也會加大後端資料處理的負擔。
CC是目前應用層攻擊的主要手段之一，在防禦上有一些方法，但不能完美解決這個問題。
反射型攻擊
2004年時DRDOS第一次披露，通過將SYN包的源地址設定為目標地址，然後向大量的真實TCP伺服器傳送TCP的SYN包，而這些收到SYN包的TCP server為了完成3次握手把SYN|ACK包“應答”給目標地址，完成了一次“反射”攻擊，攻擊者隱藏了自身，但有個問題是攻擊者製造的流量和目標收到的攻擊流量是1:1，且SYN|ACK包到達目標後馬上被回以RST包，整個攻擊的投資回報率不高。
反射型攻擊的本質是利用“質詢-應答”式協議，將質詢包的源地址通過原始套接字偽造設定為目標地址，則應答的“回包”都被髮送至目標，如果回包體積比較大或協議支援遞迴效果，攻擊流量會被放大，成為一種高性價比的流量型攻擊。
反射型攻擊利用的協議目前包括NTP、Chargen、SSDP、DNS、RPC portmap等等。
四、DDOS 攻擊防禦 攻擊流量到底多大，這是一個關鍵問題。攻擊量的大小。用的防護方法不一樣。下面給你講一講，1G之內的防護方式。費用在，<1萬，每月
談到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攻擊很難通過某一種手段做到完全防禦，很多中小型企業，沒有能力也沒有財力來對抗DDOS攻擊。但通過下面的幾點，還是可以做到簡單的防禦：
保證伺服器系統的安全
首先要確保伺服器軟體沒有任何漏洞，防止攻擊者入侵。確保伺服器採用最新系統，並打上安全補丁。在伺服器上刪除未使用的服務，關閉未使用的埠。對於伺服器上執行的網站，確保其打了最新的補丁，沒有安全漏洞。
隱藏伺服器真實IP
伺服器前端加CDN中轉（免費的有百度雲加速、360網站衛士、加速樂、安全寶等），如果資金充裕的話，可以購買高防的盾機，用於隱藏伺服器真實IP，域名解析使用CDN的IP，所有解析的子域名都使用CDN的IP地址。此外，伺服器上部署的其他域名也不能使用真實IP解析，全部都使用CDN來解析。 另外，防止伺服器對外傳送資訊洩漏IP，最常見的是，伺服器不使用傳送郵件功能，如果非要傳送郵件，可以通過第三方代理（例如sendcloud）傳送，這樣對外顯示的IP是代理的IP。 總之，只要伺服器的真實IP不洩露，10G以下小流量DDOS的預防花不了多少錢，免費的CDN就可以應付得了。如果攻擊流量超過20G，那麼免費的CDN可能就頂不住了，需要購買一個高防的盾機來應付了，而伺服器的真實IP同樣需要隱藏。