綠盟科技 何坤

0 前言

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

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

1 DNS架構(gòu)及安全風(fēng)險

1.1 DNS系統(tǒng)架構(gòu)與性能

國內(nèi)運營商的省級DNS系統(tǒng)為少數(shù)幾家廠商所建設(shè)，架構(gòu)較為固定。典型的DNS系統(tǒng)架構(gòu)有以下三種：

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

1.2 DNS安全風(fēng)險

DNS具有如下特點：

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

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

（3）整個互聯(lián)網(wǎng)對DNS的依賴不言而喻，反過來也同樣，一旦網(wǎng)絡(luò)出現(xiàn)故障，DNS對外也將無法提供服務(wù)，兩者的安全性緊密相連。

DNS主要具有如下風(fēng)險：

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

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

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

具體來說，DNS協(xié)議與DDoS相關(guān)的缺陷主要有如下：

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

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

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

圖1 DNS系統(tǒng)架構(gòu)

以上缺陷導(dǎo)致DNS成為目前最脆弱的互聯(lián)網(wǎng)基礎(chǔ)設(shè)施，DNS服務(wù)中斷后的很短時間內(nèi)，屬于該區(qū)域的用戶能夠很快感知到，因而DNS服務(wù)是否能夠正常運行極為重要和敏感。

2 應(yīng)對策略分析

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

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

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

2.1 流量分析及監(jiān)控--NTA

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

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

當(dāng)然，NTA除了在攻擊的時候可以發(fā)揮其應(yīng)有的作用，在風(fēng)平浪靜的時候，NTA還可提供詳細的數(shù)據(jù)報表，方便管理員進行數(shù)據(jù)分析。

2.2 流量清洗--Defender

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

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

（2）ICMP可以不必完全禁止，但不等于說完全放行，可設(shè)定合理的清洗閥值，當(dāng)DNS服務(wù)遭遇DDoS攻擊挑戰(zhàn)時，清洗設(shè)備自動對ICMP進行清洗。

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

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

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

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

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

2.3 Defender DNS防護算法

基于DNS的特點，Defender內(nèi)置了兩種DNS防護算法。

簡單的說，一種是通過分析DNS查詢內(nèi)容，基于流量模型的防護算法，Defender通過自學(xué)習(xí)DNS查詢內(nèi)容，根據(jù)自身算法得出一個流量模型，一旦Defender發(fā)現(xiàn)DNS流量異常則會啟用防護，不符合流量模型的DNS請求將會被丟棄，這是一種基于復(fù)雜數(shù)學(xué)統(tǒng)計的防護算法。

圖2 網(wǎng)絡(luò)拓撲

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

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

3 小結(jié)

本文主要關(guān)注了現(xiàn)有DNS架構(gòu)及風(fēng)險情況，以及如何使用黑洞Defender與NTA應(yīng)對。需要指出的是，除了使用清洗設(shè)備進行DDoS攻防之外，還可以將清洗設(shè)備與其他技術(shù)相結(jié)合，比如清洗設(shè)備與“Anycast”DNS分布技術(shù)相結(jié)合，在清洗設(shè)備進行流量清洗的同時，進行DNS流量的負載均衡。

總之，在DNS面臨越來越多的挑戰(zhàn)下，相應(yīng)的防護技術(shù)會越來越多，也越來越成熟。而這一切，都是為了創(chuàng)造一個和平寧靜的網(wǎng)上環(huán)境。

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

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