DNS攻防說明

針對ADS四種防護算法進行DNS攻防測試,防護算法如下:

1.默認算法(限速)

2.TC重傳

3.cname跳轉

4.首次query丟棄

重點針對攻擊原理、防護原理進行說明,針對測試提供參考方法。

 

DNS request flood攻擊

攻擊原理:

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

2、在DNS request flood攻擊過程中,攻擊的目標可能是DNS授權服務器,也可能是DNS緩存服務器。

3、黑客僞造的客戶端IP地址可能是虛假源IP地址,也可能是現網真實存在的IP地址。

如果攻擊的是DNS授權服務器,大量不存在的域名解析請求會導致服務器應接不暇,最終耗盡服務器性能。

4、如果攻擊的是緩存服務器,同時會導致緩存服務器不停的向授權服務器發送這些不存在域名的解析請求,一收一發更加重服務器的負擔,直到最終導致服務器癱瘓。

 

Request防禦原理:

TC防護算法

1、當客戶端發送的DNS請求報文超過告警閾值後,ADS系統啓動源認證機制。

ADS系統攔截DNS請求,並進行迴應,要求客戶端以TCP方式重新發起DNS查詢。

如果這個源是虛假源,則不會正常響應這個DNS迴應報文,更不會重新通過TCP方式重新進行DNS查詢。

2、如果是真實客戶端,則會重新發送SYN報文,請求建立三次握手。

ADS系統對客戶端源進行TCP層面的認證。源認證通過,客戶端源IP加入白名單。

3、客戶端重新請求建立三次握手,Anti-DDoS系統將客戶端第二次發送的三次握手請求直接放行,送給服務器。

4、客戶端與服務器之間建立三次握手成功,並通過TCP方式完成本次DNS查詢。

注意:

這種方式是防禦DNS request flood的一種基本的認證模式,適用於客戶端是瀏覽器的認證。

隨着這種防禦方式在現網中的應用,其限制也漸漸的顯現出來。比如現網中有一些真實客戶端,

並不支持通過TCP方式進行DNS查詢,這樣的話,這種防禦方式就不適用了。

所以現在對於緩存服務器的DNS request flood已經逐漸被另一種“被動防禦”模式所取代。

需考慮服務器的承受能力。對虛假源有效,對肉雞無效。反向探測包數量等於攻擊包數量,攻擊包數量大+反向探測回堵死上行帶寬。

 

被動防護算法

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

2、ADS系統在第一次收到DNS請求後,就會記錄DNS請求的域名、源IP等基本信息,並HASH成一個值,記錄到系統一張表裏。

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

 

4、被動防禦模式是一種比較通用的防禦手段,適用於攻擊源不斷變換的DNS請求攻擊。

對客戶端的類型沒有限制,無論緩存服務器還是授權服務器都適用。那麼對於授權服務器,除了被動模式外,還有一種常用的防禦模式CNAME。

 

cname防護算法

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

ADS系統代替服務器進行迴應,並將www.ddos.com的域名重定向爲GksbtkNgmpldezpe.www.ddos.com,讓客戶端重新請求這個別名。

2、客戶端重新請求重定向後的新域名:GksbtkNgmpldezpe.www.ddos.com。客戶端正常響應這個重定向域名後,ADS系統對客戶端的源認證就通過了。

3、ADS系統第二次重定向,將GksbtkNgmpldezpe.www.ddos.com再衝定向回最初訪問的域名www.ddos.com。

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

 

無論是TC源認證、被動防禦還是CNAME模式,其實都是利用DNS協議對客戶端是否真實存在所做的源探測。

其中,TC源認證利用的是DNS協議的TCP查詢方式;被動模式利用的是DNS協議的重傳機制;而CNAME則是利用DNS的別名機制。

 

Reply Flood攻擊篇

原理

DNS服務器收到DNS reply報文時,不管自己有沒有發出去過解析請求,都會對這些DNS reply報文進行處理。

DNS reply flood就是黑客發送大量的DNS reply報文到DNS緩存服務器,導致緩存服務器因爲處理這些DNS reply報文而資源耗盡,影響正常業務。

 

防護算法

1、針對dns緩存服務器,reply報文通常爲授權服務器發給緩存服務器。

2、ADS系統部署在防護目標前,並對到達防護目標的DNS reply報文進行統計。當到達防護目標的DNS reply報文超過告警閾值時,ADS系統啓動防禦。

3、ADS系統收到某個源IP地址發來的DNS reply報文後,會重新構造一個新的DNS request報文,然後記錄構造查詢報文的Query ID和源端口號。

4、如果是虛假源,則不會對這個DNS request報文進行迴應,認證不通過。

5、如果是真實DNS授權服務器,則會重新迴應DNS reply報文。

6、Anti-DDoS系統收到DNS reply報文後,會與之前記錄的Query ID和源端口號進行匹配。如果完全一致,則判定此DNS reply報文就是反彈DNS request報文的迴應,源認證成功,加入白名單。

7、後續這個源再發送的DNS reply報文,直接通過,直到白名單老化

DNS反射攻擊原理

1、DNS反射攻擊是DNS reply flood的一種變異,是一種更高級的DNS reply flood。

2、DNS服務器是互聯網最基礎的設施之一,網絡中有很多開放的免費DNS服務器。

3、DNS反射攻擊正是利用這些開放的DNS服務器製造的攻擊。這種DNS反射攻擊通常比普通的DNS reply flood攻擊性更強,追蹤溯源困難,更善於僞裝。

 

DNS反射攻擊防護原理

1、傳統DNS reply flood一般攻擊目標是DNS緩存服務器;而DNS反射攻擊一般攻擊目標是客戶端。

2、傳統DNS reply flood大多是虛假源攻擊,而DNS反射攻擊中,DNS請求是真實的,所以DNS迴應報文也都是真實的,是由網絡中真實的DNS服務器發出的,

屬於真實源攻擊。這種情況下,再使用前面剛講過的源認證方式,對於DNS反射攻擊就不適用了。

3、ADS系統借鑑防火牆的會話表機制,利用DNS交互交互過程中,DNS request報文首包建會話的機制,防禦DNS反射放大攻擊

 

限速防護

原理

除了源認證和會話檢查以外,對於DNS flood攻擊還可以通過限速的方式進行防禦。DNS限速有兩種,針對DNS request和DNS reply報文都生效。

限速防禦算法

1、如果某個域名的DNS請求或迴應報文速率過高,可以針對這個域名進行限速。通常某個域名在攻擊前訪問量並不算高,突然有一天訪問量是平時的好多倍,那這個域名可能就是受攻擊了。

2、源IP地址限速和域名限速相比,屬於另一個維度的限制。如果某個源IP地址域名解析的速率過大,就可以有針對性的對這個源IP地址進行限制,這樣也不會對其他源有影響。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章