DNS拒絕服務攻擊與對策

文/章思宇 姜開達

DNS拒絕服務攻擊與對策

文/章思宇 姜開達

面對各種形式攻擊對DNS服務構成的威脅，要確保校園網DNS服務的安全可靠運行，需要從基礎架構開始進行全面的考慮。

DNS是互聯(lián)網最關鍵的基礎設施之一，它最主要的功能是將域名與IP地址進行映射。隨著互聯(lián)網應用的發(fā)展，DNS被賦予越來越多的職責。然而，由于DNS協(xié)議設計之初并沒有足夠的安全考慮，協(xié)議缺陷、實現(xiàn)和配置缺陷等一系列問題一直以來都威脅著DNS的安全運行。

2008年，Dan Kaminsky提出的一種DNS緩存中毒攻擊方法引起學術和企業(yè)界對DNS安全的廣泛關注，時至今日絕大多數(shù)DNS服務器都已實現(xiàn)了源端口隨機化以加強對緩存中毒攻擊的防御。2009年“暴風”事件造成全國多省網絡癱瘓，促使運營商重視并加大對DNS運行安全的投入。

盡管如此，DNS安全現(xiàn)狀依然不容樂觀。一方面，利用DNS發(fā)起的各種DDoS攻擊泛濫，對DNS服務的正常運行，乃至整個互聯(lián)網都構成了極大的威脅；另一方面，大量配置和維護不當?shù)腄NS服務器正在成為攻擊者的幫手。

DNS反射放大攻擊

DDoS攻擊可以說是目前最難防御的攻擊方式之一，如今大規(guī)模的DDoS攻擊流量都在100Gbps以上，DNS反射是攻擊者放大攻擊流量的常用手法。

DNS反射攻擊利用易于偽造的UDP源IP地址、互聯(lián)網上數(shù)量龐大的開放解析器和DNS回答尺寸的高放大比三個關鍵因素，達到了可觀的DDoS流量放大效果。事實上許多基于UDP的協(xié)議都可以用作反射攻擊，如NTP、SSDP等，近期都被攻擊者利用，但互聯(lián)網上DNS的反射源（開放解析器）數(shù)量是最多的。

Open Resolver Project持續(xù)探測互聯(lián)網上的開放DNS解析器，盡管近一年來開放解析器數(shù)量呈緩慢下降趨勢，但至今全球依然有超過2000萬個IP地址響應DNS請求。2014年5月我們做的教育網范圍內的調查也顯示，教育網內有2萬多個IP地址響應DNS查詢，其中6663個能夠提供正確的遞歸解析。

DNS反射攻擊主要利用以下幾個DNS技術和方法。首先，攻擊者發(fā)送的DNS請求通常啟用EDNS0擴展，以突破DNS消息通過UDP傳送時的512字節(jié)限制，使服務器向受害者發(fā)送更大尺寸的響應包。在利用現(xiàn)有正常域名進行反射攻擊時，攻擊者通常發(fā)送ANY類型的請求，要求服務器返回該域名所有類型的資源記錄。同時，攻擊者傾向于選擇支持DNSSEC的域名，利用RRSIG數(shù)字簽名記錄的大尺寸來達到較好的放大效果。DNS反射對流量的放大比例最高可達90倍以上。

圖1 TXT記錄反射攻擊域名示例

在我們的監(jiān)測中發(fā)現(xiàn)的另一現(xiàn)象是，一些攻擊者注冊了專門用于反射攻擊的域名。這些域名有的設置了上百個A記錄IP地址，有的在TXT或MX記錄中填入大量無意義內容用于增加回答尺寸，如圖1所示。利用自己注冊的域名進行反射放大，可以控制回答的尺寸，避免回答尺寸過大被截斷。

圖2 變前綴域名攻擊流量示例

互聯(lián)網上每一個開放的DNS服務器都可能成為攻擊者進行DNS反射攻擊的幫手，作為DNS服務的運行和管理者，有責任杜絕自己管理的DNS服務器被DDoS攻擊利用。

對于遞歸（緩存）服務器，其服務的對象通常是一定范圍內的，對于高校網絡而言，遞歸服務器一般只為校園網內的用戶服務。因此，可以配置ACL規(guī)則，只響應校園網IP地址范圍內的主機請求，對于來自其他源地址的DNS查詢，采取拒絕（回答REFUSED）或丟棄（無任何回應）的方式處理。

授權（權威）域名服務器同樣也會被DNS反射攻擊所利用。在授權域名服務器上無法進行源地址限制，因此，授權服務器首先應關閉遞歸解析功能。RRL（Response Rate Limiting）是授權服務器應對DNS反射攻擊的一種機制，當服務器收到來自同一IP地址或子網的對相同域名的大量請求時，將丟棄這些重復查詢。RRL能大幅降低DNS反射的流量，在BIND 9.9.4以上及NSD 3.2.15以上版本都已實現(xiàn)支持。

隨機前綴域名拒絕服務攻擊

在DNS反射攻擊中，盡管匯聚到受害者的攻擊流量是巨大的，但對單個DNS服務器而言流量和負載并不明顯。另一種采用隨機前綴的針對域名的拒絕服務攻擊，則會對遞歸服務器的正常運行產生嚴重干擾。

圖3 變前綴攻擊遞歸服務器響應狀態(tài)示例

圖4 BIND變前綴攻擊測試

這種拒絕服務，攻擊者向遞歸服務器發(fā)送目標域名下隨機的子域名查詢，如圖2所示，由于每個請求的前綴都不相同，遞歸服務器必須把每個請求都轉發(fā)給目標域名的授權服務器進行解析，攻擊者的目的即是讓目標域名的授權服務器癱瘓。當目標域名的授權服務器無法正常響應后，遞歸服務器對這些查詢的解析就會失敗，產生SERVFAIL的回答，如圖3所示。

通過對DNS流量的監(jiān)測，我們發(fā)現(xiàn)此類針對域名的拒絕服務攻擊幾乎每天都在發(fā)生，只是攻擊目標域名一直在變化。對特定域名的攻擊一般持續(xù)數(shù)小時，長的可能超過一天。此類攻擊的流量也非常巨大，在一個監(jiān)測點我們就記錄了多起單個域名超過1000萬QPS的拒絕服務。從被攻擊的域名來看，大多數(shù)目標都是游戲私服類網站，私服相互爭斗已從攻擊對手網站服務器轉向攻擊域名。2013年8月CN頂級域服務器的DDoS攻擊，也是起于私服網站域名的攻擊。

這種攻擊看起來和DNS反射放大攻擊有一定的相似性，為何它會對遞歸服務器也造成巨大的影響呢？究其原因，DNS反射攻擊的請求是對同一域名的，遞歸服務器可用緩存處理所有的查詢，而隨機前綴攻擊的每個查詢都必須經過遞歸解析，尤其在授權服務器無響應時，遞歸解析過程將等待很長一段超時時間，大量涌入的需要遞歸解析的查詢將耗盡所有的遞歸解析器資源，從而正常的遞歸域名解析請求無法被處理。

為了測試這種攻擊對DNS服務器的影響，我們選擇一個授權服務器無回應的域名，首先對其下一固定子域名進行大量重復查詢，此時BIND遞歸客戶端沒有明顯消耗（圖4-a）；當我們使用隨機生成的子域名進行測試時（圖4-b），BIND的遞歸客戶端則迅速耗盡。

這種攻擊不僅威脅域名授權服務器，被利用的遞歸服務器也會出現(xiàn)癱瘓現(xiàn)象，若不采取有效的防護措施可能造成區(qū)域網絡訪問故障，與2009年“暴風”事件中遞歸服務器過載有幾分相似。

一種方法是使用更高效的DNS服務器軟件。我們測試對比了BIND和Unbound兩個最常用的遞歸服務器軟件，選用10000個域名，正常情況下兩者的解析成功率都在98.7%左右。當施加了同樣的隨機前綴攻擊流量后，BIND對正常域名的解析成功率下降到51.3%，而Unbound所受影響輕微，解析成功率仍維持在97.8%。Unbound的良好表現(xiàn)得益于其處理服務器過載的競爭策略，以及服務器超時探測機制。

圖5 校園網DNS服務部署架構

之前應對反射攻擊時已提到遞歸服務器應只對服務范圍內的IP地址提供遞歸，但在實際運行中，我們發(fā)現(xiàn)有不少校園網內的IP地址正在發(fā)起隨機前綴攻擊。調查后我們排除了這些機器被攻擊者控制的可能性，它們一部分是開啟了DNS服務的服務器，并配置為轉發(fā)器，將請求轉發(fā)給校園網的DNS服務器，另一部分使用了特定型號的家用路由器，因設計缺陷其DNS轉發(fā)功能對外網開放，難以升級修復。由于一個IP地址轉發(fā)的攻擊流量就可能造成遞歸服務器過載，而校園網內服務器設備數(shù)量龐大難以控制，我們建議在校園網邊界丟棄除授權服務器以外的進校UDP 53端口報文。

校園網DNS部署和運行安全

面對各種形式攻擊對DNS服務構成的威脅，確保校園網DNS服務的安全可靠運行需要從基礎架構開始進行全面的考慮。

首先，從服務器角色上，應做授權、緩存、遞歸分離的設計。由于三者功能、服務對象和流量特性的不同，將三者部署在獨立的服務器上可以有針對性地采取安全防護和服務保障措施。以往對授權和遞歸功能的分離討論較多，而將緩存和遞歸分離則是借鑒了Web緩存的架構，能夠提高服務承載能力，更靈活地處理異常和擴展性能。無論緩存（遞歸）還是授權服務器，都應有足夠的冗余，避免單點故障的發(fā)生，對于有多個校區(qū)的高校，可考慮通過Anycast進行多點部署。

對于授權服務器，除了配置RRL防止被反射攻擊利用外，還應注意區(qū)傳送的配置。多個報告顯示互聯(lián)網上有眾多域名的授權服務器對任意IP開放區(qū)傳送，從而造成內部重要服務器地址暴露，為攻擊者尋找滲透目標提供便利。對此應采用ACL和TSIG確保區(qū)傳送安全，同時利用水平分割（Split-Horizon）的方法避免內部IP地址泄露到公網。由于授權服務器中的主服務器具有特殊的重要性，可將主服務器隱藏起來不直接對外服務（Hidden Master），僅為從服務器提供區(qū)傳送，避免其遭受直接攻擊。校園網DNS緩存與授權服務部署結構總結如圖5所示。

DNS部署時服務器軟件也應有一定的異構性，選擇兩種或以上的服務器軟件，以避免某個軟件出現(xiàn)漏洞影響到所有的服務器。例如，BIND作為最常用的DNS服務器軟件，每年都會被報告多個高危漏洞，且以遠程拒絕服務為主，遠多于其他常用DNS服務器軟件。對此可考慮遞歸和緩存使用Unbound和BIND混合部署，而授權服務器使用NSD和BIND混合部署，并注意軟件版本更新。

監(jiān)控是保障DNS服務穩(wěn)定運行、及時發(fā)現(xiàn)異常所必需的。對DNS服務的監(jiān)控，可采集服務器軟件自身提供的統(tǒng)計信息，服務器也可以配置成記錄所有的DNS請求，但過多的日志會降低服務器的性能。較好的方法是對DNS服務器的流量進行鏡像分析，利用dsc定制收集各種統(tǒng)計信息，并具有一定的圖形展示能力，dnstop則可顯示最近一段時間內查詢最多的域名和IP地址。利用鏡像流量還可自行開發(fā)各種分析工具，且不會影響到DNS服務器本身的工作。此外，學校域名和授權服務器配置，可使用DNSCheck工具進行檢查。

本文對困擾高校網絡DNS服務運行的兩類拒絕服務攻擊進行了分析，并提供了相應的應對措施，同時也探討了安全可靠部署和運行校園網DNS服務的一些思路和建議。DNS作為眾多互聯(lián)網應用的基礎支撐，其自身的安全性，以及在其之上出現(xiàn)的各種惡意應用，在未來很長一段時間都將是安全界關注的熱點。

（作者單位為上海交通大學網絡信息中心）