DDoS對DNS的安全挑戰

綠盟科技 何坤

0 前言

2009不平凡的一年。全球各種DDoS事件頻發，國內有“5.19”斷網事件，國外有韓國總統官邸青瓦臺、國防部、國會、新韓銀行、韓國外換銀行“7.7”事件，7.28日，BIND又爆出最新的漏洞。

DDoS的影響已經上升到運營商網絡、甚至國家網絡安全的層面。在本文中，我們將會分析DNS在DDoS下的安全情況及應對策略。

1 DNS架構及安全風險

1.1 DNS系統架構與性能

國內運營商的省級DNS系統為少數幾家廠商所建設，架構較為固定。典型的DNS系統架構有以下三種：

早期建設的DNS系統架構如圖1(a)，DNS服務器集群均連接于一臺四層交換機之上，由四層交換機負責DNS查詢請求的負載均衡，每臺DNS Server的DNS 查詢請求負載能力約為10kpps，單臺四層性能交換機的極限性能約為40～50kpps左右；由于四層交換機性能的限制，(a)圖所示的架構并不能充分發揮DNS Server集群的負載能力，因此有了如圖1(b)的架構。此種架構需要在未連接四層交換機的DNS Server上運行一個可以實現OSPF路由協議的軟件，與上連的Cisco 6509通過OSPF實現負載均衡，注意如圖所示的結構實際上是6路負載均衡，即整個DNS系統的極限性能約為60kpps，屬于過渡性架構；由于四層交換機的存在，還是限制了DNS系統的性能的提升，最新的DNS系統建設開始采用如圖1(c)所示的架構。所有的DNS Server均與上連的Cisco 6509通過OSPF實現負載均衡。由于三層交換機的性能遠超過四層交換機，DNS集群的可擴展性大大增強。

1.2 DNS安全風險

DNS具有如下特點：

（1） DNS是開放的協議，無驗證機制，并且在傳輸過程中未加密。

（2） 絕大多數DNS使用BIND，而BIND代碼是開放的。

（3）整個互聯網對DNS的依賴不言而喻，反過來也同樣，一旦網絡出現故障，DNS對外也將無法提供服務，兩者的安全性緊密相連。

DNS主要具有如下風險：

（1） DNS cache投毒。參見BUGTRAQ ID: 30131；CVE(CAN) ID: CVE-2008-1447。

（2）漏洞頻出，幾個針對BIND漏洞的惡意包就可以癱瘓整個DNS服務。參見CVE CAN ID：CVE-2009-0696。

（3）DDoS攻擊。除了針對DNS服務器的DDoS攻擊，若網絡架構設計不合理，針對網絡設備或其他應用的DDoS也可能會造成DNS癱瘓。筆者就曾經遇到由于網絡設計不合理，網絡出現一點擁塞，DNS服務器本身沒有Down掉，上面的交換機帶寬就已經被堵滿的案例。

具體來說，DNS協議與DDoS相關的缺陷主要有如下：

（1）缺乏合法性驗證，客戶端程序主要通過收到的DNS響應序列號及端口號來確認與查詢是否匹配，卻沒有機制來認證應答內容的合法性；同樣，服務器端也無法驗證客戶端發出的請求是否合法。

（2）UDP無連接，每次DNS訪問都是獨立的，客戶端與DNS服務器之間的UDP訪問沒有三次握手階段，這在加快了數據傳輸的同時，也是造成防御措施匱乏的一個重要原因。

（3）開放的體系，大多DNS服務器的各類數據未進行加密且沒有訪問控制，不同地區的客戶都可以訪問各個DNS服務器。據統計互聯網中75%的DNS服務器允許遞歸查詢，40%的DNS服務器允許區域傳送。

圖1 DNS系統架構

以上缺陷導致DNS成為目前最脆弱的互聯網基礎設施，DNS服務中斷后的很短時間內，屬于該區域的用戶能夠很快感知到，因而DNS服務是否能夠正常運行極為重要和敏感。

2 應對策略分析

DNS服務本身需要對公眾開放，不可能網絡隱身。甚至連禁止Ping包都需要做部分考量，要知道，一般網民想了解DNS是否存活的時候，都是發幾個Ping包來驗證(而不是使用nslookup)，如果發現無法Ping通，而此時恰好網絡有些“卡”，這時候公眾的矛頭很可能就會指向DNS。正因為這些特點，對DNS的保護并不是架兩臺防火墻，封幾個端口就能做的事情，必須要做到深層次的檢測和防護。

我們看下面的拓撲圖(如圖2)，這是一個典型的省網DNS的部署架構，為了最大可能的避免網絡瓶頸，我們“恨不得”將DNS服務器直接掛在網絡出口處，這樣可保證帶寬足夠；更“恨不得”架設無數臺DNS服務器，做超級DNS集群，這樣可保證冗余性及處理性能。然而，現實中，當出現針對性的DDoS攻擊的時候，通常會攻擊流量巨大，即使是強大的DNS集群，在攻擊時都會顯得弱不禁風，且部署DNS的成本是不得不考慮的，增加DNS服務器的投資應以自身業務增長的量為基石，而不是僅為了防御DDoS攻擊。

基于以上考慮，在拓撲中，我們部署了黑洞NTA及黑洞ADS設備(又稱Defender)，其中黑洞NTA用于實時DNS流量監控，一旦發現存在異常流量行為將會通知黑洞ADS進行動態流量牽引防護，兩者分工明確，一個用于檢測分析、一個用于DDoS攻擊防護。

2.1 流量分析及監控--NTA

NTA信息來源為Netflow信息，NTA的部署極為簡單，只需要網絡可達，Netflow由路由器從現網流量中采樣獲取，然后發送給NTA進行信息分析；NTA上線之后，會自動學習現網DNS的流量情況，動態生成流量模型曲線，通過比對當前流量情況及行為判斷是否存在攻擊。同時，NTA還內置了各類蠕蟲特征庫，可直接檢測到網絡中蠕蟲的情況。

一旦發現NTA發現攻擊，可自動的通知Defender進行流量牽引和清洗，又或是通過Email告警、短信告警的方式通知管理員，讓管理員人工操作流量清洗，管理操作方式十分靈活。

當然，NTA除了在攻擊的時候可以發揮其應有的作用，在風平浪靜的時候，NTA還可提供詳細的數據報表，方便管理員進行數據分析。

2.2 流量清洗--Defender

之前我們提到，對DNS的保護并不是架兩臺防火墻，封幾個端口就能做的事情。這不是說封端口沒有作用，根據DNS服務的幾個特點，黑洞Defender(流量清洗設備)可設置如下清洗防護策略：

（1）DNS服務器幾乎不會開啟除DNS服務以外的服務，TCP應用很少。除TCP53、及UDP53端口，在Defender上大可對其余端口設置非常嚴格的清洗策略，或是直接禁掉。

（2）ICMP可以不必完全禁止，但不等于說完全放行，可設定合理的清洗閥值，當DNS服務遭遇DDoS攻擊挑戰時，清洗設備自動對ICMP進行清洗。

（3）DNS請求報文的平均長度通常約為100字節，基本上都小于500字節，可以限制500字節以上的DNS報文。

（4）每一個區域DNS提供商，大可限制只允許本區域的用戶可以訪問其DNS。

（5）限制每一個源IP的DNS請求發包數量，正常情況下，一個用戶的DNS請求數量是有限的。

（6）利用清洗設備的DNS防護算法，對DNS流量進行精細清洗。

（7）通常情況下，DNS管理員對自己服務器中，哪些域名請求量最多十分清楚。一旦發現DNS請求中出現大量非這些“知名域名”的請求，或是這些“知名域名”請求量出現了陡增，基本上可以判定出現異常，“5.19”就是一個很明顯的例子，這時，大可在清洗設備中人工干掉異常的域名。

2.3 Defender DNS防護算法

基于DNS的特點，Defender內置了兩種DNS防護算法。

簡單的說，一種是通過分析DNS查詢內容，基于流量模型的防護算法，Defender通過自學習DNS查詢內容，根據自身算法得出一個流量模型，一旦Defender發現DNS流量異常則會啟用防護，不符合流量模型的DNS請求將會被丟棄，這是一種基于復雜數學統計的防護算法。

圖2 網絡拓撲

另外一種是通過反向探測客戶端協議行為，判定客戶端是否正常的防護算法。UDP是面向無連接的協議，從技術上來說，清洗設備很難做到只通過UDP報文就能夠判定源IP的真假性，而TCP是面向連接的。通常情況下，客戶端都是使用UDP進行DNS查詢，實際上，DNS協議支持TCP查詢，正是基于這一點，Defender在使用反向探測DNS算法的時候，巧妙的將原本是UDP的查詢請求轉成TCP查詢請求，從而可以通過使用TCP協議對客戶端進行真假性驗證，達到防范的目的。

任何防護技術都有其相應的局限性，Defender集成了兩種防護算法，可以在攻防中靈活應對。

3 小結

本文主要關注了現有DNS架構及風險情況，以及如何使用黑洞Defender與NTA應對。需要指出的是，除了使用清洗設備進行DDoS攻防之外，還可以將清洗設備與其他技術相結合，比如清洗設備與“Anycast”DNS分布技術相結合，在清洗設備進行流量清洗的同時，進行DNS流量的負載均衡。

總之，在DNS面臨越來越多的挑戰下，相應的防護技術會越來越多，也越來越成熟。而這一切，都是為了創造一個和平寧靜的網上環境。

[1] 易鑫.DNS防護參考.綠盟科技.2009.

[2] 張小妹.基于DNS的拒絕服務攻擊研究與防范.解放軍信息工程大學.2009.