楊哥關注的華為官方的【華安解密之DDoS攻防】

非常實用，純純的乾貨，決定每天一篇分享給愛看頭條並且愛學習的條友們。

正文如下：

---

上一篇我們一起回顧了暴風影音攻擊和防禦的全過程，大家對DNS攻擊表現出了濃厚的興趣。近幾年DNS攻擊作為應用層DDoS攻擊的代表，每年發生的頻率都在大幅上升，DNS攻擊造成的影響面非常的大，是近幾年黑客的新寵。今天華安就帶著大家好好聊聊DNS相關的各種攻擊。

0x01 DNS協議基礎

要想弄明白DNS攻擊的原理，就要先明白DNS協議的基礎，我們還是從DNS協議本身講起。DNS由RFC1034、1035協議定義規範，屬於應用層協議。在前一篇中，我們也說了，DNS域名解析是互聯網上非常重要的一項服務，我們每天上網都伴隨著大量的DNS服務來支撐。在Internet上，用戶更容易記住的是域名，但是網絡中的計算機互相進行訪問是通過IP地址，DNS最常用的是給用戶提供域名解析服務，將用戶的域名解析成網絡上能夠訪問的IP地址。

上一篇我們介紹了案例，這裡我們深入細節，先來研究DNS報文的格式。

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交互

假設一個用戶要去華為商城買個手機，那麼從他在瀏覽器上敲下華為商城域名，到打開商城網頁，這短暫的一瞬間，其實發出的DNS請求報文已經經歷了下面這幾步查詢過程：

為了便於理解，我們簡化一下DNS報文交互的流程。像遞歸服務器這種有官方域名授權的服務器，我們暫且把它統一歸類為“授權服務器”。這樣DNS服務就可以分為兩大類：

• 一種是授權存儲域名和IP地址映射關係的授權服務。
• 一種是臨時存放域名和IP地址映射關係的緩存服務。

DNS查詢通常都是基於UDP協議的，這就導致了在查詢過程中缺少驗證機制，容易被黑客利用。下面，我們就分析一下這兩類服務可能面臨的DNS攻擊風險。

第一類：黑客偽造客戶端源IP發送大量的DNS請求報文，造成DNS request flood攻擊。DNS request flood是當前最常見的DNS攻擊，這類攻擊可以針對緩存服務器，也可以針對授權服務器。

第二類：黑客偽造成授權服務器發送大量的DNS回應報文，造成DNS reply flood攻擊。

第三類：篡改某些網站的域名和IP地址對應關係，導致用戶訪問被導向至釣魚網站、**網站等。

第四類：向DNS服務器發送大量錯誤格式的DNS異常報文，或者發送大量超長DNS報文，導致DNS服務器處理這些報文時出現異常，拒絕正常服務。

當然了，DNS的查詢過程主要是基於UDP協議的，少量基於TCP協議，所以除了應用層攻擊外，可能也會遭受傳輸層的TCP或UDP類攻擊，比如SYN flood、UDP flood等等。TCP和UDP類的攻防會在後續的專題中詳細介紹，今天我們只重點講解DNS類的攻擊和防禦。

上一節暴風影音案例中，我們介紹一些和案例本身相關的DNS攻擊，以及適合此場景的防禦措施。其實DNS的攻擊和防禦措施遠不止那些，今天我們就詳細介紹一下最常見的DNS request flood攻擊以及相應的防禦措施。

0x02 DNS request flood攻擊與防禦

DNS request flood攻擊原理其實很簡單，就是黑客控制殭屍網絡向DNS服務器發送大量的不存在域名的解析請求，最終導致服務器因大量DNS請求而超載，無法繼續響應正常用戶的DNS請求，從而達到攻擊的目的。

在DNS request flood攻擊過程中，攻擊的目標可能是DNS授權服務器，也可能是DNS緩存服務器。黑客偽造的客戶端IP地址可能是虛假源IP地址，也可能是現網真實存在的IP地址。如果攻擊的是DNS授權服務器，大量不存在的域名解析請求會導致服務器應接不暇，最終耗盡服務器性能；如果攻擊的是緩存服務器，同時會導致緩存服務器不停的向授權服務器發送這些不存在域名的解析請求，一收一發更加重服務器的負擔，直到最終導致服務器癱瘓。

對於緩存服務器和授權服務器，雖然都是DNS request flood攻擊，但由於請求的客戶端類型不同，所以防禦的手段也不同。對於緩存服務器，正常向它發送DNS請求的是上網的終端用戶，所以防禦過程中，需要判定的是這個DNS請求是否由真實、正常的瀏覽器客戶端發出；而對於授權服務器，向它發送DNS請求的可能就是緩存服務器了。所以對於不同的對象，認證方式當然也就不同了。

我們先從緩存服務器說起，看看華為Anti-DDoS系統是怎麼防禦DNS request flood攻擊的。Anti-DDoS系統最初防禦DNS request flood採用的方式是TC源認證方式。

TC源認證

前面我們也講過了，DNS查詢有TCP和UDP兩種方式，通常情況下，DNS查詢都是用的UDP協議，此時TC位置0，但是可以通過將TC位置1，將查詢協議改為TCP方式。Anti-DDoS系統利用的就是通過修改DNS報文中的TC標識位，對客戶端進行認證。

1. 當客戶端發送的DNS請求報文超過告警閾值後，Anti-DDoS系統啟動源認證機制。
2. Anti-DDoS系統攔截DNS請求，並進行回應，要求客戶端以TCP方式重新發起DNS查詢。
3. 如果這個源是虛假源，則不會正常響應這個DNS回應報文，更不會重新通過TCP方式重新進行DNS查詢。
4. 如果是真實客戶端，則會重新發送SYN報文，請求建立三次握手。
5. Anti-DDoS系統對客戶端源進行TCP層面的認證。源認證通過，客戶端源IP加入白名單。
6. 客戶端重新請求建立三次握手，Anti-DDoS系統將客戶端第二次發送的三次握手請求直接放行，送給服務器。
7. 客戶端與服務器之間建立三次握手成功，並通過TCP方式完成本次DNS查詢。

我們再來結合一組抓包看一下。

1、客戶端向DNS服務器發送DNS請求，從抓包中可以看到，DNS請求報文基於UDP協議，TC標記位是0，請求的域名是www.ddos.com。

2、Anti-DDoS系統代替服務器進行回應，並將TC標記位設置為1，希望客戶端通過TCP方式重新發起DNS查詢。

3、從這張圖可以看出客戶端重新用TCP方式進行了DNS查詢。

這種方式是防禦DNS request flood的一種基本的認證模式，適用於客戶端是瀏覽器的認證。隨著這種防禦方式在現網中的應用，其限制也漸漸的顯現出來。比如現網中有一些真實客戶端，並不支持通過TCP方式進行DNS查詢，這樣的話，這種防禦方式就不適用了。所以現在對於緩存服務器的DNS request flood已經逐漸被另一種“被動防禦”模式所取代。

被動防禦

其實被動模式，就是“以不變應萬變”，Anti-DDoS系統利用DNS協議的重傳機制，不對DNS查詢報文進行反彈，而是直接不處置，直接丟棄，然後看客戶端是否重傳。

1、Anti-DDoS系統在第一次收到DNS請求後，就會記錄DNS請求的域名、源IP等基本信息，並HASH成一個值，記錄到系統一張表裡。

2、後續一定時間戳內，如果再收到這個HASH值相同的DNS請求，就認定為重傳包，放行。時間戳會隨著收到的每一個相同HASH值的DNS請求包而不斷的刷新。

我們再來抓包看看：

1、第一次DNS請求。這個DNS查詢報文會被Anti-DDoS系統丟棄，並且不回應任何報文。

2、第二次DNS請求。客戶端一段時間內沒有收到DNS回應報文，重新發送DNS請求。

被動防禦模式是一種比較通用的防禦手段，適用於攻擊源不斷變換的DNS請求攻擊。對客戶端的類型沒有限制，無論緩存服務器還是授權服務器都適用。那麼對於授權服務器，除了被動模式外，還有一種常用的防禦模式CNAME。

CNAME模式

授權服務器通常直接服務的“客戶”是緩存服務器，是個服務器，而不是客戶端的瀏覽器。所以在源認證的時候，和緩存服務器的防禦機制不同。授權服務器利用的是DNS的CNAME（別名）機制。

DNS協議中，允許將多個域名映射到同一個IP地址，此時可以將一個域名做A記錄指向服務器IP，然後將其他域名作為別名，指向之前做A記錄的域名上。這樣類型的存在是為了解決IP地址變更時，不必一個一個域名做更改指向。只需要更改A記錄的那個域名到新IP上，其他別名將自動更改到新IP地址上。

下面我們就看看Anti-DDoS系統如何利用CNAME機制進行源認證，這種方式也就是我們上一篇中介紹過的重定向方式。

再來看一組抓包。

1、客戶端發送DNS查詢的請求，查詢的域名是www.ddos.com。

2、Anti-DDoS系統代替服務器進行回應，並將www.ddos.com的域名重定向為GksbtkNgmpldezpe.www.ddos.com，讓客戶端重新請求這個別名。

3、客戶端重新請求重定向後的新域名：GksbtkNgmpldezpe.www.ddos.com。客戶端正常響應這個重定向域名後，Anti-DDoS系統對客戶端的源認證就通過了。

4、Anti-DDoS系統第二次重定向，將GksbtkNgmpldezpe.www.ddos.com再衝定向回最初訪問的域名www.ddos.com。

5、客戶端重新請求www.ddos.com，這次發送的DNS請求會直接送到服務器。後續服務器會回應這個域名的解析地址，完成此次DNS查詢。

瞭解了這三種模式後，我們再來回顧一下。大家不難發現，無論是TC源認證、被動防禦還是CNAME模式，其實都是利用DNS協議對客戶端是否真實存在所做的源探測。其中，TC源認證利用的是DNS協議的TCP查詢方式；被動模式利用的是DNS協議的重傳機制；而CNAME則是利用DNS的別名機制。

好啦，這一期我們就先講到這裡，下一期，我們再繼續學習DNS reply flood攻擊的防禦。

---

上期連接：

---