◆魏 遠 張 平
(信息工程大學 河南 450001)
典型的DNS威脅與防御技術研究
◆魏 遠 張 平
(信息工程大學 河南 450001)
DNS是互聯(lián)網(wǎng)中最重要的基礎設施,但由于其自身設計缺陷,針對其安全漏洞的網(wǎng)絡攻擊事件層出不窮。本文介紹了DNS協(xié)議基礎框架和其存在的安全漏洞,討論了基于這些漏洞實現(xiàn)的典型攻擊方式,包括反射放大攻擊,DNS劫持,緩存投毒攻擊,DNS隧道等,在分析攻擊實現(xiàn)原理和危害的基礎上,給出了相應的抗攻擊方法和建議。
DNS;域名系統(tǒng)威脅;反射放大攻擊;緩存投毒;DNSSEC
互聯(lián)網(wǎng)已經(jīng)成為我們生活中必不可少的一部分,而 DNS(Domain Name System,域名系統(tǒng))[1,2]是互聯(lián)網(wǎng)運行的最重要的基礎設施,在全球互聯(lián)網(wǎng)的運轉(zhuǎn)中扮演基礎性作用。互聯(lián)網(wǎng)中的任何一個事件幾乎都開始于一次 DNS查詢,盡管這一切都是無形中完成的。DNS的最主要的功能是將人類更好辨識的域名轉(zhuǎn)換為數(shù)字化的IP地址。DNS在設計之初,互聯(lián)網(wǎng)規(guī)模并沒有如今這么龐大,但隨著計算機和互聯(lián)網(wǎng)技術的逐步發(fā)展,DNS固有的安全缺陷逐步暴漏出來,由此引發(fā)越來越多的網(wǎng)絡安全問題。DNS最主要問題在于通信雙方缺乏來源數(shù)據(jù)真實性和完整性的認證機制,系統(tǒng)無法確認數(shù)據(jù)發(fā)送方是否是合法的發(fā)送方,也無法驗證數(shù)據(jù)報是否被篡改,攻擊者很容易實現(xiàn)源地址和數(shù)據(jù)內(nèi)容的欺騙。
本文的重點討論DNS所面臨的典型的威脅,包括基于DNS的分布式拒絕服務攻擊,DNS劫持,DNS緩存投毒,DNS隧道等,在分析在典型DNS的攻擊技術的實現(xiàn)原理和危害程度的基礎上,給出了相應的防御措施和緩解措施,如 DNS安全擴展,任撥,響應率限制等。
DNS是一個全球性的龐大系統(tǒng),其核心的原件主要包含域名空間(Name Space)、名稱服務器(Name Server)、資源記錄(Resource Record)、解析器(Resolver)。
DNS域名空間類似于Unix文件系統(tǒng),是一種自上而下的樹狀組織方式[3],如圖1所示。根節(jié)點在最頂層,樹狀結構的第一層包含有“.com”,“.net”等頂級域名,第二層包含通用域名如“baidu.com”,第三層是子域名或者具體主機,當然也可以有第四層甚至更多的層。需要注意的是,每個域名都可以被劃分為多個子域名。
圖1 域名空間結構
除了域名空間自身,域名空間所代表的信息需要被存儲在某些載體上,名稱服務器正是存儲這些域名空間的信息的載體。名稱服務器通常被劃分為權威名稱服務器和遞歸名稱服務器。對于一個特定的域名空間,如果一個名稱服務器有這個域名空間的所有的信息,則將這個名稱服務器稱為這個域名空間的權威名稱服務器,否則稱為遞歸名稱服務器。
在 DNS系統(tǒng)中,解析器也是一個重要的角色,通常用戶所直接使用的也是解析器,例如,谷歌的“8.8.8.8”,國內(nèi)的“114.114.114.114”等都是最常用的解析器。解析器在用戶和名稱服務器之間扮演橋梁的作用,其最重要的任務是,接受用戶的查詢請求,向名稱服務器查詢具體地址,解析來自于名稱服務器的響應,然后再返回結果給用戶。對于用戶來說,解析器是服務器端,對于名稱服務器而言,解析器又是客戶端。
資源記錄包含和域名相關的各項數(shù)據(jù),資源記錄包含很多種類,但常用的是internet類(IN類),這種類包含多種不同的數(shù)據(jù)類型,表1給出了最常見的幾種IN類資源記錄。
表1 常見資源記錄
為了更加直觀展現(xiàn)DNS工作流程,下面以訪問baidu.com為例說明DNS運轉(zhuǎn)過程:
(1)當用戶想要接入baidu.com時,問解析器,“請告訴我baidu.com的IP地址?”。
(2)解析器接到用戶查詢請求后,解析器首先會查詢自身的緩存記錄是否有baidu.com的地址記錄,如果有并且尚未過期,則直接返回給用戶,如果沒有,則解析器會轉(zhuǎn)向根名稱服務器,詢問根名稱服務器,“請告訴我baidu.com的IP地址?”。
(3)根名稱服務器收到請求后,會根據(jù)域名的頂級名稱空間判斷,發(fā)現(xiàn) baidu.com的頂級名稱空間是.com,則會通知解析器,“請詢問.com名稱服務器”。
(4)解析器再次轉(zhuǎn)向.com名稱服務器,然后問同樣的問題。
(5).com名稱服務器會根據(jù)域名判斷,發(fā)現(xiàn)baidu.com這個域名的權威名稱服務器是ns.baidu.com,它會給解析器回答,“請詢問ns.baidu.com名稱服務器”。
(6)解析器再次轉(zhuǎn)向ns.baidu.com名稱服務器,然后問同樣的問題,ns.baidu.com屬于 baidu.com的權威服務器,它擁有baidu.com的所有的信息,當然也知道baidu.com的地址,直接回答出baidu.com的IP地址。
(7)最終,解析器得到了baidu.com的IP地址,轉(zhuǎn)發(fā)給用戶,在自身緩存表中存入或更新,以便下次查詢。
圖2 DNS工作流程
值得一提的是,一定要注意到緩存記錄,當解析器中有對應域名的緩存記錄,并且緩存沒有過期時,它會直接將緩存記錄中的域名返回給用戶,而無需再向其他名稱服務器詢問,緩存記錄可以增強整個系統(tǒng)的可擴展性和減少解析延遲,但同時由于缺乏安全保護,也隱藏著其他安全問題。
DNS在設計之初的核心關注點在于系統(tǒng)的穩(wěn)定性,容錯性,可擴展性等,并沒有考慮安全的問題,這種固有的設計缺陷滋生了多種安全漏洞,概括而言,DNS主要存在以下幾個問題:
(1)無論是查詢請求還是查詢響應,數(shù)據(jù)都是通過既沒有簽名,也沒有加密的 UDP協(xié)議來傳送的,很容易遭到竊聽和篡改。
(2)對通信雙方而言,都沒有辦法驗證對方數(shù)據(jù)來源的真實性和完整性。
(3)DNS使用緩存來加快解析進度,但同時也因為緩存沒有足夠保護機制,導致緩存數(shù)據(jù)成為重點攻擊對象。
DNS的這些安全漏洞,致使它面臨的威脅主要集中在兩大方向:拒絕服務攻擊,數(shù)據(jù)欺騙攻擊。
拒絕服務攻擊(DOS:Denial Of Service),是一種使合法的用戶不能正常接入系統(tǒng)或者網(wǎng)絡資源,或者使得系統(tǒng)或者網(wǎng)絡自身無法正常提供服務的攻擊手段。分布式拒絕服務攻擊(Distributed Denial Of Service:DDoS)是大規(guī)模分布式實現(xiàn)DOS的一種方式。DDoS攻擊可能會涉及到成千上萬臺設備,通常來自于僵尸網(wǎng)絡,或者機器人網(wǎng)絡等。DNS協(xié)議是DDoS攻擊最常用的一種UDP協(xié)議,它幾乎具備發(fā)動DDoS攻擊所需要的所有條件,因此也最為DDoS攻擊者青睞。數(shù)據(jù)欺騙攻擊通常指以某種方式篡改 DNS數(shù)據(jù),獲取域名的解析控制權,以達到欺騙接收者的目的,包括緩存投毒,DNS劫持等方式,下面討論幾種最為典型的DNS威脅。
DNS反射攻擊是最常見的一種利用DNS的攻擊方式,實現(xiàn)這種攻擊需要具備兩個條件,一個是攻擊者要偽造 DNS查詢的源地址,第二是有開放的遞歸解析服務器。DNS是典型的 UDP傳輸協(xié)議,源地址可以輕易偽造,并且缺乏源地址真實性的認證機制,現(xiàn)實中也存在大量的開放的遞歸解析服務器,恰好滿足上述兩個條件。攻擊者通過向開放的遞歸解析服務器發(fā)送大量的偽造源地址的DNS查詢請求,以此將DNS響應流量導向攻擊者偽造的源地址,也就是受害者,當響應流量足夠大時,這種攻擊會對受害者造成拒絕服務攻擊,致使受害者系統(tǒng)癱瘓。
反射放大攻擊是在反射攻擊的基礎上再增加一個條件:查詢響應流量成倍的大于查詢請求流量,DNS正好具備這個能力,例如,可以通過查詢僅有 64字節(jié)的“ANY”資源記錄,就可以得到512字節(jié)的查詢響應,以此來實現(xiàn)響應流量放大,典型的反射放大攻擊如圖3所示。
圖3 DNS反射放大攻擊
近年來,利用 DNS實現(xiàn)反射放大攻擊案例比比皆是,2013年,反垃圾郵件組織Spamhaus遭遇了一次峰值為300Gbps的DNS反射放大攻擊[4],攻擊者發(fā)出長為36字節(jié)的DNS查詢數(shù)據(jù)包,卻得到了長為3000字節(jié)的響應數(shù)據(jù)包,直接導致大量合法用戶不能訪問該機構網(wǎng)站,這也是最具影響力的一次反射放大攻擊。另據(jù)Arbor Networks記錄,2016年里約奧運會期間,攻擊者利用DNS及其他協(xié)議,針對巴西政府發(fā)動了峰值為540Gbps的DDoS攻擊[5]。
隨機子域(Random Subdomain)攻擊,在這種攻擊中,攻擊者通過向開放遞歸解析服務器查詢合法域名的隨機子域名或者根本就不存在的子域名來實現(xiàn)攻擊,例如,查詢xxxxx.google.com,這種域名不會得到正確的響應,攻擊者可以通過控制僵尸網(wǎng)絡來自動大量發(fā)送這些查詢請求,以此來耗盡 DNS權威服務器的帶寬和資源,造成這些權威服務器無法向合法用戶提供正常的服務。
非存在域名(NXDomain Name),是指由攻擊者設置和控制的一些解析非常緩慢或者根本得不到正確解析的域名。非存在域名攻擊類似于隨機子域名攻擊,攻擊者向開放遞歸服務器發(fā)送大量非存在域名的查詢請求,但這些域名解析緩慢或者不能解析,以此來讓 DNS解析服務器一直在等待解析響應,以達到消耗解析服務器資源,實現(xiàn)拒絕服務攻擊的目的。
緩存投毒是最流行的 DNS欺騙方式,盡管緩存投毒的攻擊理論早已存在[6],但由于實施困難,成功率低并沒有得到足夠重視,2008年,Dan Kaminsky在Black Hat的演講讓緩存投毒攻擊成為一種切實可行的攻擊方式[7]。
緩存投毒攻擊是指攻擊者將“污染”的緩存記錄插入到正常的DNS名稱服務器的緩存記錄中,所謂污染的緩存記錄指DNS解析服務器中域名所對應的 IP地址不是真實的地址,而是由攻擊者篡改的地址,這些地址通常對應著由攻擊者控制的服務器,下面詳述緩存投毒實現(xiàn)方式:
用戶A向解析器R請求查詢xxxxx.google.com的IP地址,R中并不會緩存 xxxxx.google.com的資源記錄,R將會轉(zhuǎn)向google.com的權威名稱服務器,假設 R合法解析得來的地址是IP1,但是攻擊者會在該響應到達前,偽造大量解析地址為 IP2響應包發(fā)送給R(其中要在TTL內(nèi)成功猜測transaction ID,若猜測不成功,則更換隨機域名重新發(fā)動,詳見文獻[8]),而IP2是攻擊者控制的服務器,通常為釣魚網(wǎng)站等,由于R很難檢測來源響應的真實性,并且根據(jù) DNS接收策略,當接收到第一個響應包后會丟棄隨后的響應,隨后 R會將該條記錄存入到自身緩存中,這樣就完成了緩存投毒的過程。當其他合法用戶查詢時,R由于緩存中已經(jīng)存入IP2且尚未過期,會直接將IP2響應給用戶,致使用戶訪問攻擊者控制的站點,結合社會工程學,攻擊者利用偽造的網(wǎng)站頁面誘使受害者下載病毒和木馬,以此達到控制受害者機器,盜取受害者敏感信息的目的。
緩存投毒攻擊是最危險的一種 DNS攻擊方式,利用它可以實現(xiàn)中間人攻擊和拒絕服務攻擊,導致用戶隱私泄露和財產(chǎn)損失,使合法用戶不能正常接入站點,站點不能為用戶提供正常服務。
DNS劫持是另外一種常見的DNS欺騙攻擊,從攻擊結果來看,DNS劫持(重定向)和緩存投毒很相似,攻擊想要實現(xiàn)的目的都是控制特定域名的解析記錄,導致域名對應的 IP地址被篡改為由攻擊者控制的假的站點。攻擊者通常會通過兩種方式實現(xiàn)DNS劫持,一種是直接攻擊域名注冊商或者域名站點獲取控制域名的賬戶口令,這樣可以修改域名對應的 IP地址,另外一種方式是攻擊權威名稱服務器,直接修改區(qū)域文件內(nèi)的資源記錄。
對于企業(yè)和機構客戶而言,遭遇 DNS劫持是非常嚴重的問題,它會導致機構失去對域名的控制,一旦攻擊實現(xiàn),機構的站點將不能訪問,或者用戶可能會訪問到偽造的站點。當用戶接入如支付寶,銀行等合法站點時遭遇域名劫持,用戶將面臨個人賬戶和敏感信息泄露,財產(chǎn)損失等風險。
DNS查詢請求通常被視為安全的數(shù)據(jù)類型,防火墻和入侵檢測設備一般不會攔截。DNS隧道正是利用這一特點,將其他的數(shù)據(jù)和協(xié)議(如 shellcode)編碼為 DNS查詢請求,以此方式來躲避防火墻和入侵檢測設備。
DNS隧道最初被設計用來繞過WIFI Web認證,但是,在攻擊者眼里,DNS隧道被視為實現(xiàn)遠程控制的一種方式,也就是說,通過DNS隧道,攻擊者可以通過DNS服務器去遠程執(zhí)行命令和控制數(shù)據(jù)傳輸。
攻擊者想要實現(xiàn) DNS隧道,必須控制一個內(nèi)網(wǎng)的客戶端,客戶端不需要連接外網(wǎng),能夠向內(nèi)部的 DNS服務器發(fā)送和接收外部站點的 DNS請求和響應即可。由于防火墻和入侵檢測設備很少攔截 DNS查詢和響應,因此,被控客戶端可以將數(shù)據(jù)編碼為DNS請求,通過DNS服務器發(fā)送給攻擊者,攻擊者同樣可以將控制命令編碼為 DNS響應發(fā)送給被控客戶端,這樣就可以在被控客戶端和攻擊者之間安全傳輸命令和數(shù)據(jù)[9,10]。多種工具可以輕易實現(xiàn)DNS隧道,比如DNSCat[11],Iodine,DNS2TCP等。
針對 DNS所暴露的問題,相關研究人員已提出很多安全建議,工業(yè)界也引入了大量的對抗 DNS攻擊的安全產(chǎn)品,但所采用的防御和緩解措施大致有以下幾種。
DNSSEC (Domain Name System Security Extensions,DNS 安全擴展)[12],目前來看,最有希望解決DNS安全問題的安全措施就是DNSSEC。簡而言之,DNSSEC依賴于數(shù)字簽名和公鑰系統(tǒng)去保護 DNS數(shù)據(jù)的可信性和完整性。權威名稱服務器用自身的私鑰來簽名資源記錄,然后解析服務器用權威名稱服務器的公鑰來認證來自權威名稱服務器的數(shù)據(jù),如果認證成功,則表明接收到的數(shù)據(jù)確實來自權威名稱服務器,則解析服務器接收數(shù)據(jù),如果認證失敗,則表明接收到的數(shù)據(jù)很可能是偽造的,則解析服務器拋棄數(shù)據(jù)。文獻[13]提供了DNSSEC的具體的相關的概念和安全特色。
DNSSEC確實也存在一些問題,由于認證過程涉及到公鑰運算的加解密過程,它會增加系統(tǒng)的消耗,延長 DNS解析時間,并且要完成認證的話,需要部署從根域名服務器到站點域名服務器的信任鏈,正因如此,很多機構不愿部署DNSSEC。此外,由于DNSSEC的響應包放大倍數(shù)顯著大于正常DNS響應包,如果部署不當,恰好為放大攻擊所濫用[14]。
Anycast(任撥)[15]是一種網(wǎng)絡路由方式,通過部署Anycast,提供相同服務的一組服務器可以使用相同的 IP地址, 客戶端的請求數(shù)據(jù)將會被轉(zhuǎn)發(fā)到這組服務器中路由拓撲結構最近的一臺主機上。不難發(fā)現(xiàn),Anycast可以用來抵抗DDoS攻擊[16],當攻擊者通過僵尸網(wǎng)絡發(fā)動DDoS攻擊時候,由于僵尸網(wǎng)絡的主機具有不同的 IP地址和地理位置,這些來自僵尸網(wǎng)絡的流量會被發(fā)送到的不同的主機,正因如此,幾乎所有的根域名服務器都已經(jīng)部署了 Anycast,這種方式可以理解為用分布式防御對抗分布式攻擊。
響應率限制是指允許權威服務器可以統(tǒng)計自身所發(fā)送的來源于相同的DNS查詢所對應的DNS響應的頻次,權威服務器可以設置一個發(fā)送次數(shù)的閾值,規(guī)定在某一段時間內(nèi),若發(fā)送響應的頻次超過設定的閾值,權威名稱服務器會停止發(fā)送響應,并且持續(xù)一段時間,若在這段時間內(nèi),權威名稱服務器沒有收到同樣頻次的查詢,則取消限制。因此,權威名稱服務器將不會發(fā)送高于這個閾值的DNS響應,這樣將有效保護DNS權威名稱服務器原理 DDoS攻擊。響應率限制可以緩解DNS 放大攻擊的影響,但是同樣存在幾點問題,它僅僅對于權威名稱服務器有效,對于公開遞歸服務器無效,攻擊者也可以通過發(fā)送一組不同的查詢而不是一個查詢發(fā)送多次來繞過,另外,響應率限制也可能會影響合法用法使用。
利用DNS來實現(xiàn)DDoS攻擊之所以能夠輕易成功的關鍵原因之一是,大部分的開放式遞歸服務器可以讓任何人執(zhí)行 DNS查詢請求,而一個安全的 DNS遞歸服務器不應該向任何人開放查詢權限,DNS服務器管理者應當控制接入權限,保證授權的用戶可以執(zhí)行DNS查詢。
DNS是互聯(lián)網(wǎng)正常運轉(zhuǎn)的基石,但是它的自身安全被大部分用戶忽視。近年來,由于它先天的設計缺陷,DNS被攻擊者利用發(fā)動各種類型攻擊。本文研究了 DNS面臨的典型威脅,討論了這些威脅的實現(xiàn)原理和方式,并且給出了一些有效的防御和緩解措施。
[1] Mockapetris P.V.Domain names: Concepts and Facilities RFC1034[S],1987.
[2] Mockapetris P.V.Domain names: Implementation and Specification RFC1035[S],1987.
[3] Liu Cricket and Albitz Paul.DNS and BIND[M]. 5th. CA.O'Reilly Media Inc,2006.
[4] Matthew Prince.The DDoS That Knocked Spamhaus Offline.2013.https://blog.cloudflare.com/the-ddos-that-knocke d-spamhaus-offline-and-ho/.
[5] Cimpanu Catalin.ddos attacks during rio olympics peaked at 540 gbps,2016.
[6] Jiang Jian,Liang Jinjin,Li Kang,Li Jun,Duan Haixinand Wu Jianping.Ghost Domain Names: Revoked Yet Still Resolvable [C]//Network and Distributed System Security Symposium,2012.
[7] Tom Olzak.DNS Cache Poisoning: Definition and Prevention,2006.
[8] Kaminsky D.Black ops 2008-it’s the end of the cache as we know it [C]//BlackHat, 2008.
[9] Sooel Son and Vitaly Shmatikov.The Hitchhiker’s Guide to DNS Cache Poisoning [C]//Security and Privacy in Communication Networks - Iternational ICST Conference,SECURECOMM 2010, Singapore, September 7-9, 2010.Proceedings,2010.
[10] Cian Lynch,Dimiter Andonov and Claudiu Teodorescu.MULTIGRAIN-Point of Sale Attackers Make an Unhealthy Addition to the Pantry.2016.https:// www.fireeye.com/blog/threat-research/2016/04/multigrain_pointo.html.
[11] E.Skoudis.The six most dangerous new attack techniques and what’s coming next 2012. https://blogs.sans.org/pentesting/files/2012/03/ RSA-2012-EXP-108-Skoudis-Ullrich.pdf.
[12] Bowes Ron.Weaponizing dnscat with shellcode and Metasploit.2010.https://blog.skullsecurity.org/2010/weaponizingdnscat-with-shellcode-and-metasploit.
[13] Giuseppe Ateniese and Stefan Mangard.A new approach to DNS security (DNSSEC) [C]//In Proceedings of the 8th acm conference on Computer and Communications Security,2001.
[14] NIST.DNS Security Introduction and Requirem ents RFC 4033[S],2005.
[15] Rijswijk-Deij Roland Van,Sperotto Anna and Pras Aiko.DNSSEC and its potential for DDoS attacks:a comprehensive measurement study [C]//Conference on Internet Measurement Conference,ACM,2014.
[16] Abley J,Canada Afilias and Lindqvist K.Operation of anycast services [J].RFC 4786,2006.
[17] Giovane C. M. Moura,Ricardo O.Schmidt De,John Heidemann,Wouter B.Vries De,Moritz Müller,Lan Wei and Cristian Hesselman.Anycast vs.DDoS:Evaluating the November 2015 Root DNS Event,2016.