背景：
在近期的安全工作中，由於被DDOS搞的有點煩，計划上一批抗DDOS設備，所以需要學習梳理和總結DDOS攻防相關的內容。
DDoS是Distributed Denial of Service的簡稱，中文是分布式拒絕服務。
先說下什么是拒絕服務：DoS（Denial of Service），DoS攻擊就是攻擊者通過發送大量正常或不正常服務請求，來占用服務器資源，導致服務器資源被占滿從而無法再為新的合法用戶提供服務響應。尤其是當目標服務器資源性能不高的時候（例如CPU速度低、內存小或者網絡帶寬小等等），DoS攻擊非常容易執行並且效果顯著。
隨着計算機與網絡技術的發展，計算機的處理能力與網絡帶寬迅速增長。這使得DoS攻擊的困難程度大大增加了，因為攻擊目標對這些惡意服務請求的“消化能力”加強了很多。既然一個攻擊者無法使目標“拒絕服務”，那么就需要多個攻擊者同時發起分布式攻擊了，這時DDoS攻擊也就應運而生了。DDoS攻擊是指攻擊者控制僵屍網絡中的大量僵屍主機（肉雞）向攻擊目標發送大流量數據，耗盡攻擊目標的系統資源，導致其無法響應正常的服務請求。
一張圖生動的描繪出DDOS的攻擊過程：
DDoS攻擊按TCP/IP協議分層划分有：網絡層攻擊、傳輸層攻擊、應用層攻擊。具體如下：
| 分層 |
DDoS攻擊 |
| 網絡層 |
IP地址掃描攻擊、大部分特殊控制報文攻擊、Teardrop攻擊、Smurf攻擊、IP分片報文攻擊、ICMP Flood攻擊 |
| 傳輸層 |
SYN Flood、SYN-ACK Flood、ACK Flood、FIN/RST Flood、TCP連接耗盡攻擊、UDP Flood（包括各種反射攻擊）、TCP/UDP分片報文攻擊、DNS Flood、DNS緩存投毒、其余各種與TCP、UDP報文和端口相關的攻擊 |
| 應用層 |
HTTP Flood、HTTP慢速攻擊、HTTPS Flood、SSL DDoS攻擊、SIP Flood |
目前全球范圍內占比比較大的攻擊類型一般是SYN Flood、UDP Flood（包括UDP類反射放大攻擊）、HTTP Get Flood、DNS Query Flood
下面根據實例來逐個分析下每個ddos攻擊類型原理：
說起DNS Flood，就要想起“519暴風斷網”的嚴重事件。
“暴風”這件事兒的起因是兩個游戲私服互相競爭，來回發動DDoS攻擊。在達不到預期效果的情況下，干脆直接向對方的域名服務器下手了。
5月18日開始，DNS服務提供商DNSPod的6台服務器開始受到攻擊。
18日晚20點33分，在史無前例的大流量攻擊下，DNSPod的6台服務器開始陸續失效，大量網站開始間歇性無法訪問。第一波攻擊的流量在21點30分左右達到高峰，流量超過了10Gbps。要知道那可是2009年，奧運會才開過一年，北京的房價還是可以接受的，一個電信核心機房的帶寬最多也只有幾十G。
18日當晚，由於DNSPod耗盡了整個機房近乎三分之一的帶寬資源，為了不影響機房其他用戶，DNSPod服務器被運營商下線。
如果事情到此為止，其實也不會造成多大的影響。可是發動攻擊的黑客忘了，運營商的管理員也忘了，DNSPod並不僅僅為這個被攻擊的網游私服提供域名解析服務，還支持數十萬其他的網站，這其中就包括大名鼎鼎的暴風影音。普通用戶遇到上網失敗，試幾次就放棄了；暴風影音軟件的設計，使它在請求失敗后持續不斷地重新發起請求。再考慮到暴風影音巨大的裝機量，悲劇發生了。
19日晚，由於DNSPod網絡服務被中斷，致使其無法為包括baofeng.com在內的域名提供域名解析服務，諸多采用DNSPod服務的網站無法訪問，DNS請求涌向了本地DNS緩存服務器，DNS緩存服務終於頂不住了，發生了大面積的堵塞。
19日晚21點左右，浙江電信DNS緩存服務開始癱瘓，之后的兩個小時內天津、北京、上海、河北、山西、內蒙古、遼寧、吉林、江蘇、黑龍江、浙江、安徽、湖北、廣西、廣東等地區的DNS緩存服務器也陸續癱瘓。全國各省市出現大面積斷網。
事件中涉及的幾個關鍵角色
DNSPod
DNSPod是國內最大的一家免費DNS解析服務提供商，暴風影音和前面惡性競爭的游戲私服都是DNSPod的客戶。
運營商
由於中國特色的運營商市場，導致DNSPod這樣的網絡基礎服務提供商無法獨立承建數據中心，只能租用運營商IDC的機房和服務器資源。
暴風影音
影音軟件起家，后來向媒體提供商轉型。暴風影音軟件中，有一項強制隨機啟動的名為stormliv.exe的進程，只要用戶安裝了暴風影音，該進程就會自動運行，並不斷連接暴風影音網站，下載廣告或升級。
私服與黑客
這個就很容易理解了，一個是為了一己私欲，策划這場攻擊事件的背后指示者；一個是為了牟取暴利的攻擊事件執行者。
從事件整個過程來看，一共有幾個關鍵點：
1、游戲私服攻擊競爭對手DNS服務，打蛇打七寸，間接攻擊了整個DNSPod的業務。
2、運營商對DNSPod流量進行了阻斷，粗暴的對流量進行了黑洞處理。
3、幾億安裝了暴風影音客戶端的PC充當“肉雞”，導致運營商DNS緩存服務器無法提供服務，進而導致大面積斷網。
如果把這次事件看成是“多米諾骨牌”效應，那被推倒的第一張“骨牌”是DNSPod服務器；第二張“骨牌”毫無疑問就是暴風影音充當“肉雞”導致服務耗盡的運營商DNS緩存服務器；而第三張“骨牌”就是全國范圍癱瘓的網絡了。如果想深入理解這次互聯網災難，就要了解下DNS DDOS攻擊的分類和原理。
(author https://www.cnblogs.com/Shepherdzhao/)
要想弄明白DNS攻擊的原理，就要先明白DNS協議的基礎，我們還是從DNS協議本身講起。DNS由RFC1034、1035協議定義規范，屬於應用層協議。在前一篇中，我們也說了，DNS域名解析是互聯網上非常重要的一項服務，我們每天上網都伴隨着大量的DNS服務來支撐。在Internet上，用戶更容易記住的是域名，但是網絡中的計算機互相進行訪問是通過IP地址，DNS最常用的是給用戶提供域名解析服務，將用戶的域名解析成網絡上能夠訪問的IP地址。
DNS報文格式：
下面結合DNS查詢報文和響應報文的抓包信息來看理解一下報文格式中的幾個關鍵字段，先看一下DNS查詢報文的抓包：
DNS報文由12字節長的首部和4個長度可變的字段組成。標識字段由客戶端程序設置並由服務器返回結果，客戶端通過標識來確定響應與查詢是否匹配。報文中涉及的字段很多，我們重點解釋幾個和本節相關的字段。
- UDP：表示DNS查詢基於UDP協議傳輸數據。DNS服務器支持TCP和UDP兩種協議的查詢方式。
- Destination port：目的端口默認是53。
- QR：0表示查詢報文；1表示回應報文。
- TC：表示“可截斷的”。如果使用UDP時，當應答報文超過512字節時，只返回前512個字節。
通常情況下，DNS查詢都是使用UDP查詢，UDP提供無連接服務器，查詢速度快，可降低服務器的負載。當客戶端發送DNS請求，並且返回響應中TC位設置為1時，就意味着響應的長度超過512個字節，而僅返回前512個字節。這種情況下，客戶端通常采用TCP重發原來的查詢請求，並允許返回的響應報文超過512個字節。直白點說，就是UDP報文的最大長度為512字節，而TCP則允許報文長度超過512字節。當DNS查詢超過512字節時，協議的TC標志位會置1，這時則使用TCP發送。
- Queries：表示DNS請求的域名和類型。
再來看一下DNS回應報文的抓包：
- 在回應報文中，比查詢報文多了后三個字段：回答字段、授權字段和附加信息字段。其中回答字段是放置的域名對應的IP地址等信息。
- Name：DNS查詢中的請求域名。
- Type：每一個查詢都有一個查詢類型，每一個響應也都有一個類型。這個類型大約有20多種，但是很多種類型現在已經過時了。最常用的查詢類型是A類型，表示期望獲得查詢域名的IP地址。查詢類型也可以是CNAME，這個在后面的詳細介紹。
- TTL：生存時間，表示客戶端保留該解析資源記錄的時間。
DNS request flood攻擊原理其實很簡單，就是黑客控制僵屍網絡向DNS服務器發送大量的不存在域名的解析請求，最終導致服務器因大量DNS請求而超載，無法繼續響應正常用戶的DNS請求，從而達到攻擊的目的。
在DNS request flood攻擊過程中，攻擊的目標可能是DNS授權服務器，也可能是DNS緩存服務器。黑客偽造的客戶端IP地址可能是虛假源IP地址，也可能是現網真實存在的IP地址。如果攻擊的是DNS授權服務器，大量不存在的域名解析請求會導致服務器應接不暇，最終耗盡服務器性能；如果攻擊的是緩存服務器，同時會導致緩存服務器不停的向授權服務器發送這些不存在域名的解析請求，一收一發更加重服務器的負擔，直到最終導致服務器癱瘓。
對於緩存服務器和授權服務器，雖然都是DNS request flood攻擊，但由於請求的客戶端類型不同，所以防御的手段也不同。對於緩存服務器，正常向它發送DNS請求的是上網的終端用戶，所以防御過程中，需要判定的是這個DNS請求是否由真實、正常的瀏覽器客戶端發出；而對於授權服務器，向它發送DNS請求的可能就是緩存服務器了。所以對於不同的對象，認證方式當然也就不同了。
對於DNS request flood攻擊的防御，目前典型的抗DDOS設備比如華為的Anti-DDoS系統一般是采用被動防御的模式。
被動防御
被動模式，就是“以不變應萬變”，利用DNS協議的重傳機制，不對DNS查詢報文進行反彈，而是直接不處置，直接丟棄，然后看客戶端是否重傳，
1、抗DDOS設備在第一次收到DNS請求后，就會記錄DNS請求的域名、源IP等基本信息，並HASH成一個值，記錄到系統一張表里。
2、后續一定時間戳內，如果再收到這個HASH值相同的DNS請求，就認定為重傳包，放行。時間戳會隨着收到的每一個相同HASH值的DNS請求包而不斷的刷新。
抓包看看：
1、第一次DNS請求。這個DNS查詢報文會被丟棄，並且不回應任何報文。
2、第二次DNS請求。客戶端一段時間內沒有收到DNS回應報文，重新發送DNS請求。
被動防御模式是一種比較通用的防御手段，適用於攻擊源不斷變換的DNS請求攻擊。對客戶端的類型沒有限制，無論緩存服務器還是授權服務器都適用。
DNS查詢過程通常都是基於UDP協議的，UDP協議是無連接狀態的。所以這一弱點很容易被黑客所利用，DNS服務器收到DNS reply報文時，不管自己有沒有發出去過解析請求，都會對這些DNS reply報文進行處理。DNS reply flood就是黑客發送大量的DNS reply報文到DNS緩存服務器，導致緩存服務器因為處理這些DNS reply報文而資源耗盡，影響正常業務。
DNS reply flood大多都是虛假源攻擊，黑客控制僵屍主機發出的DNS reply報文的源IP地址通常都是偽造的，是不存在的。所以在防御的時候，就可以從回應源IP地址的真假性入手，判定這個源IP是否是真實源。
針對這種攻擊行為，抗DDOS設備一般可使用源認證方式進行防御。源認證的方法就是構造一個DNS request報文，看客戶端是否能正常回應。此處依然是用華為的anti-ddos設備舉例
1、Anti-DDoS系統部署在防護目標前，並對到達防護目標的DNS reply報文進行統計。當到達防護目標的DNS reply報文超過告警閾值時，Anti-DDoS系統啟動防御。
2、Anti-DDoS系統收到某個源IP地址發來的DNS reply報文后，會重新構造一個新的DNS request報文，然后記錄構造查詢報文的Query ID和源端口號。
3、如果是虛假源，則不會對這個DNS request報文進行回應，認證不通過。
4、如果是真實DNS授權服務器，則會重新回應DNS reply報文。
5、Anti-DDoS系統收到DNS reply報文后，會與之前記錄的Query ID和源端口號進行匹配。如果完全一致，則判定此DNS reply報文就是反彈DNS request報文的回應，源認證成功，加入白名單。
6、后續這個源再發送的DNS reply報文，直接通過，直到白名單老化。
近幾年，還有一種升級版的DNS reply flood攻擊，因為殺傷力巨大，而備受安全界的關注，那就是DNS反射攻擊。
DNS反射攻擊
DNS反射攻擊是DNS reply flood的一種變異，是一種更高級的DNS reply flood。
DNS服務器是互聯網最基礎的設施之一，網絡中有很多開放的免費DNS服務器。DNS反射攻擊正是利用這些開放的DNS服務器制造的攻擊。這種DNS反射攻擊通常比普通的DNS reply flood攻擊性更強，追蹤溯源困難，更善於偽裝。
從圖中我們可以看到，黑客將自己的源IP地址偽造成被攻擊目標的IP地址，然后向一系列網絡中開放的DNS服務器發送大量的查詢請求。通過偽造DNS請求報文的源IP地址，控制DNS回應報文的流向，這些DNS回應報文就會都被引導到被攻擊目標，導致被攻擊目標的網絡擁塞，拒絕服務。而開放式的DNS服務器在全球有超過幾千萬台，這些服務器接入帶寬往往都比較高，而且，DNS reply報文大小通常也是DNS request報文的幾倍甚至幾十倍，還可達到放大攻擊的效果。對於控制成千上萬台僵屍主機的黑客來說，制造幾G乃至數十G的DNS攻擊流量並不太困難。
DNS反射攻擊和前面介紹的傳統DNS reply flood有兩點本質的不同：
1、傳統DNS reply flood一般攻擊目標是DNS緩存服務器；而DNS反射攻擊一般攻擊目標是客戶端。
2、傳統DNS reply flood大多是虛假源攻擊，而DNS反射攻擊中，DNS請求是真實的，所以DNS回應報文也都是真實的，是由網絡中真實的DNS服務器發出的，屬於真實源攻擊。這種情況下，再使用前面剛講過的源認證方式，對於DNS反射攻擊就不適用了。
目前對於DNS反射攻擊的應對方法一般是會話檢查，會話表五元組信息包含：源IP地址、目的IP地址、源端口、目的端口和協議。當DNS request報文經過抗DDOS設備時，設備會創建一張會話表，記錄DNS請求報文的這五元組信息。當再收到DNS reply報文時，就會查會話表：
- 如果匹配會話表，就判定是真實的DNS reply報文，允許通過。
- 如果沒有匹配會話表，則判定這個DNS reply報文為攻擊報文，禁止通過。
DNS緩存投毒，是一種典型的DNS攻擊。
前面也講過，緩存服務器並不知道域名和IP地址的映射關系，一旦從授權服務器獲取了映射關系后，會存儲在內存中一段時間。直到記錄老化。老化時間由DNS reply報文中的TTL決定。在這個有效期內如果再有客戶端請求這個相同域名的解析，緩存服務器就會直接用緩存中的IP地址進行回應。老化以后，如果有客戶端再次請求這個域名時，緩存服務器就會重新向授權服務器請求。
緩存投毒攻擊就是黑客偽造了惡意的DNS reply報文，導致緩存服務器無意中將惡意的域名和IP地址映射關系存儲到自己的緩存中。當客戶端再通過緩存服務器請求這個域名解析時，就會被指向惡意主機。
1. 黑客向DNS緩存服務器發送一個不存在的子域名（gh1.ddos.com），請求解析。
2. 緩存服務器查找本地緩存項查不到，就會向授權服務器發起查詢請求。
3. 在授權服務器回應這個請求前，黑客就會偽造大量的DNS reply報文發向緩存服務器。
為了達到攻擊的目的，黑客偽造的DNS reply報文的源IP地址必須是授權服務器的源IP地址；目的端口也必須是緩存服務器的源端口；同時DNS reply報文的Query ID和DNS request報文的Query ID也要一致。
源IP地址和目的端口都很好偽造，但是Query ID偽造成功是有一定難度的。所以黑客偽造大量DNS reply報文時，會不斷變換Query ID字段。可能就會有一個Query ID字段命中DNS request的Query ID。一旦先於授權服務器發送給緩存服務器，緩存服務器就會將黑客發送的偽解析IP地址作為解析地址，保存到本地的緩存表中。
4. 后續當授權服務器再將真正的回應報文發送到緩存服務器時，緩存服務器也不會接收，直接丟棄。
在DNS緩存服務器中，如果僅僅gh1.ddos.com的解析地址是假的，這個其實也沒有多大影響。畢竟黑客利用投毒的這個子域名gh1.ddos.com通常都是不存在的，正常客戶端也不會請求這個不存在的子域名。
但是我們再仔細看一下下面這個DNS reply報文就會發現，藍框內是對子域名gh1.ddos.com的解析地址，而紅框內則是主域名ddos.com所在的DNS授權服務器和IP地址的對應關系。授權服務器在回答緩存服務器請求時，也會將這部分內容一起發送過去。而緩存服務器不僅僅存儲子域名的解析地址，還會將主域名的解析地址一並更新到自己的緩存列表中。
這樣后續再有客戶端請求這個主域名時，也會一並被指向虛假的IP地址。
對於緩存投毒，Anti-DDoS系統采用會話檢查模式進行防御。在防御過程中，檢查DNS reply報文的會話五元組信息（源IP地址、目的IP地址、源端口號、目的端口號、協議），Query ID和域名是否和緩存服務器發出的DNS request報文一致。
1. 當緩存服務器向授權服務器發出域名查詢請求時，Anti-DDoS系統記錄會話信息及請求報文中的Query ID和域名。
2. 當Anti-DDoS系統收到回應報文時，檢查會話五元組、回應報文中的Query ID和域名與請求報文中的Query ID和域名是否匹配。
a. 如果命中會話五元組，並且Query ID和域名與記錄的請求報文中的Query ID和域名匹配，則放行該報文。
b. 如果沒有命中會話，則丟棄該報文。
c. 如果命中會話，但是域名或Query ID與請求報文不匹配，則丟棄該報文，同時要刪除該會話，以免后續投毒報文完成投毒。