許成喜，胡榮貴，施 凡，張巖慶

(電子工程學(xué)院網(wǎng)絡(luò)系，合肥 230037)

1 概述

域名系統(tǒng)(Domain Name System, DNS)是一個多層次的分布式系統(tǒng)，其基本功能是提供域名和 IP地址之間的映射關(guān)系，并存儲與域名相關(guān)的附加信息。DNS是當今互聯(lián)網(wǎng)最重要的基礎(chǔ)設(shè)施之一，早在2005年，互聯(lián)網(wǎng)治理問題工作組就將 DNS和根域名服務(wù)器系統(tǒng)列為關(guān)鍵互聯(lián)網(wǎng)資源[1]，其安全性備受關(guān)注。

由于協(xié)議設(shè)計上的缺陷、DNS軟件漏洞及部署過程中不恰當?shù)呐渲茫珼NS自應(yīng)用以來就不斷遭受多種安全威脅。文獻[2]綜述了DNS面臨的安全威脅，主要有數(shù)據(jù)包截獲、ID猜測和查詢預(yù)測、緩存投毒、拒絕服務(wù)攻擊等。DNS緩存投毒通過偽造應(yīng)答報文替換緩存服務(wù)器中的域名-IP的對應(yīng)關(guān)系達到污染緩存的目的，具有容易實施、攻擊隱蔽、防御難度大的特點。但傳統(tǒng)的緩存投毒由于受TTL (Time To Live)的限制而很難成功[3]。Dan Kaminsky提出的新型緩存投毒方法成功繞過了 TTL的限制，能在很短的時間內(nèi)(10 s)投毒成功[4]。

當前，針對 Kaminsky緩存投毒的防御主要有2種思路：

(1)通過增加DNS報文的信息熵提高投毒難度。

文獻[5]提出使用0x20比特編碼的防御策略，即通過隨機化查詢請求中字符的大小寫來增加查詢報文的信息熵，從而降低投毒成功的概率。這種方法的缺點是對于短小域名提供的保護很有限。最新的方法是源端口隨機化(Source Port Randomization, SPR)[6]技術(shù)，通過采用隨機化的源端口來增加 DNS報文的信息熵。這種方法的缺點在于不能抵御持續(xù)的Kaminsky投毒。

(2)修改當前的DNS體系。

IETF提出通過部署 DNS擴展協(xié)議 DNSSEC[7-9]來徹底防御類似攻擊。DNSSEC從概念、協(xié)議設(shè)計、報文格式、加密算法及密鑰管理等方面完善了原有DNS體系的不足，依靠公鑰基礎(chǔ)體系為DNS解析服務(wù)提供數(shù)據(jù)源身份認證和數(shù)據(jù)完整性驗證，能夠有效防止各種欺騙攻擊。但截止目前，DNSSEC尚未全面部署，不能提供應(yīng)有的安全防護。因此，有必要為當前的緩存DNS服務(wù)器部署更為有效的防御措施。

針對Kaminsky攻擊所具有的可以繞過TTL限制及多次嘗試的特點，本文提出基于應(yīng)答報文檢查的防御策略，在增加 DNS報文信息熵的同時明顯降低投毒者的有效嘗試次數(shù)，從而達到增加投毒難度的目的，并通過概率模型檢查工具 PRISM對該策略的有效性進行驗證。

2 DNS遞歸解析過程

DNS服務(wù)器分為權(quán)威 DNS服務(wù)器和緩存 DNS服務(wù)器2種。其中，權(quán)威服務(wù)器擁有其所管轄的域名的權(quán)威記錄，并只負責這些域名的解析，按 DNS層次結(jié)構(gòu)可分為根服務(wù)器、頂級服務(wù)器等。根服務(wù)器處于 DNS層次結(jié)構(gòu)最頂端，只負責解析頂級域名，頂級服務(wù)器負責解析與之相關(guān)的域名。緩存 DNS服務(wù)器是為了提高查詢效率、均衡負載而提出的，對外提供遞歸解析服務(wù)。遞歸解析是指解析器將用戶查詢請求發(fā)送給緩存DNS服務(wù)器，如果緩存DNS服務(wù)器中存在對應(yīng)的資源記錄，則直接返回給用戶；否則，緩存DNS服務(wù)器向權(quán)威DNS服務(wù)器發(fā)起遞歸查詢，直到解析出查詢域名，再將結(jié)果返回給用戶。以查詢www.baidu.com為例，當緩存服務(wù)器中沒有相應(yīng)的緩存時，一個典型的域名遞歸解析過程如圖1所示。

圖1 DNS遞歸解析過程

具體的解析步驟如下：

(1)用戶解析器向本地緩存DNS服務(wù)器發(fā)送域名查詢請求。

(2)本地緩存DNS服務(wù)器無相應(yīng)資源記錄，向根DNS服務(wù)器發(fā)送查詢請求。

(3)根DNS服務(wù)器無相應(yīng)資源記錄，返回頂級域名權(quán)威DNS服務(wù)器的IP地址。

(4)緩存DNS服務(wù)器向頂級域名權(quán)威DNS服務(wù)器發(fā)送查詢請求。

(5)頂級域名權(quán)威DNS服務(wù)器無相應(yīng)資源記錄，返回baidu.com權(quán)威DNS服務(wù)器的IP地址。

(6)緩存DNS服務(wù)器向baidu.com權(quán)威DNS服務(wù)器發(fā)送查詢請求。

(7)baidu.com權(quán)威 DNS服務(wù)器找到相應(yīng)資源記錄，返回www.baidu.com的IP地址。

(8)本地緩存DNS服務(wù)器將結(jié)果返回給用戶，并將資源記錄緩存到本地數(shù)據(jù)庫，直到該資源記錄的TTL到期。

若攻擊者能夠在步驟(6)之后、步驟(7)之前偽造出應(yīng)答報文并發(fā)送至緩存 DNS服務(wù)器，則有可能修改緩存服務(wù)器的緩存記錄，這種攻擊就是 DNS緩存投毒。

3 Kaminsky投毒過程與分析

3.1 Kaminsky投毒過程

傳統(tǒng)的DNS緩存投毒受TTL的限制，即一次投毒失敗后需要等待服務(wù)器緩存資源記錄的 TTL過期后才能發(fā)起新一輪投毒[10]。

Kaminsky投毒則繞過了TTL的約束，主動向緩存DNS服務(wù)器查詢不存在的隨機化域名，這種域名在緩存 DNS服務(wù)器中必然沒有緩存，從而不存在TTL約束。因此，投毒者可以持續(xù)地進行投毒與嘗試。此外，Kaminsky投毒還利用了額外資源記錄中ns的glue記錄，即使是查詢不存在的域名，也會返回這些額外資源記錄，并且這些記錄能夠緩存在緩存 DNS服務(wù)器中。這種投毒為投毒者贏得大量連續(xù)的投毒時間和多次嘗試的機會，從而大大提高了投毒成功的概率。

Kaminsky投毒流程如圖2所示。

圖2 Kaminsky投毒流程

具體投毒步驟如下：

(1)投毒者向目標服務(wù)器發(fā)送一個 DNS查詢請求，該查詢請求中的域名使用目標域名和隨機序列的組合。如圖2所示，www.domain.com為目標域名，13481984是隨機生成的序列。顯然，這個查詢域名所對應(yīng)的主機是不存在的，正常返回的應(yīng)答報文中應(yīng)答資源記錄部分應(yīng)為NXDOMAIN，表示該域名主機不存在。

(2)目標服務(wù)器會按第2節(jié)中的DNS解析過程進行解析。投毒者在發(fā)送查詢請求后立即偽造大量應(yīng)答報文并發(fā)送至目標服務(wù)器(圖2中以實線標出)。在投毒者偽造的應(yīng)答報文中，應(yīng)答資源記錄部分與權(quán)威應(yīng)答一樣，但是權(quán)威資源記錄部分增加了一個偽造的NS記錄，并且在額外資源記錄部分含有相應(yīng)的偽造IP地址。

(3)若該報文能在權(quán)威應(yīng)答之前到達目標服務(wù)器，并能成功匹配原查詢報文的發(fā)送 IP地址、端口號和查詢 ID，則投毒成功。一旦投毒成功，該資源記錄將被寫入目標服務(wù)器的緩存中。在該記錄有效期內(nèi)，對名字服務(wù)器 ns1.domain.com管轄的所有域名的查詢都將被發(fā)送到投毒者控制的IP中。

(4)當權(quán)威DNS服務(wù)器的應(yīng)答報文到達緩存服務(wù)器時，將會被忽略，直接丟棄(圖2中以虛線標出)。

3.2 投毒成功概率與投毒時間的內(nèi)在聯(lián)系

Kaminsky投毒機會窗口如圖3所示。

圖3 投毒機會窗口示例

為了分析投毒成功概率與投毒時間的內(nèi)在聯(lián)系，將緩存服務(wù)器向權(quán)威服務(wù)器發(fā)送查詢請求與緩存服務(wù)器收到權(quán)威服務(wù)器應(yīng)答之間的時間間隔定義為一個投毒機會窗口[10]。投毒者偽造的應(yīng)答報文必須在投毒窗口內(nèi)，即先于權(quán)威應(yīng)答報文到達緩存服務(wù)器，才有可能被緩存DNS服務(wù)器所接受。

定義 Psuc為一個投毒機會窗口內(nèi)投毒成功的概率，則有：

其中，B為投毒者占用的網(wǎng)絡(luò)帶寬；W為投毒機會窗口的大??；N為一個域名的權(quán)威服務(wù)器數(shù)量；I為DNS報文中的ID域范圍；P為UDP報文中的源端口號范圍；D為攻擊者發(fā)送報文的平均大小。

由于 Kaminsky投毒可以持續(xù)投毒，因此前后2次Kaminsky投毒可以看成獨立事件。定義Pk為持續(xù)Kaminsky投毒成功的概率，則下列等式成立：

其中，Psuc為一個投毒機會窗口內(nèi)攻擊成功的概率；T為持續(xù)投毒的時間。

由式(2)可知，對于給定的 T和 W，Psuc和 Pk具有相同的增減性。

結(jié)合式(1)不難發(fā)現(xiàn)，要降低Kaminsky投毒的成功概率，可以考慮以下 2種方法：一種是通過擴大式(1)中I和P的變化范圍來增加DNS報文的信息熵；另一種是減少一個投毒機會窗口內(nèi)投毒者的有效嘗試次數(shù)，使投毒者即使擁有很大的帶寬，也不能增加投毒成功的概率。本文綜合運用這2種方法，提出了基于應(yīng)答報文檢查的防御策略。

4 基于應(yīng)答報文檢查的防御策略

4.1 策略描述

通過以上分析可知，Kaminsky投毒成功的概率很大程度上依賴于以下2個條件：

(1)這種投毒能夠繞過 TTL的限制持續(xù)地進行投毒嘗試，直到投毒成功。

(2)在一個投毒機會窗口內(nèi)，投毒者可以向目標發(fā)送多個偽造應(yīng)答報文，提高投毒成功的概率。若按投毒者占用100 Mb/s的帶寬、DNS應(yīng)答報文平均大小為80 Byte、投毒機會窗口為100 ms來計算，在一次投毒中投毒者可以進行 15 625次嘗試，大大提高了投毒成功的概率。

針對以上2點，本文對緩存服務(wù)器發(fā)出的查詢設(shè)置一個attack狀態(tài)，以標識該查詢是否受到攻擊。同時監(jiān)聽并檢測應(yīng)答數(shù)據(jù)報文，若沒有檢測到錯誤的應(yīng)答報文，則執(zhí)行正常的解析過程；否則，將 attack狀態(tài)置為TRUE，重新查尋被攻擊的域名，并將2次的查詢結(jié)果進行比對。為了避免循環(huán)進行重查而降低服務(wù)器效率，對已經(jīng)重查的域名不再發(fā)起重查。

該策略的流程如圖4所示。

圖4 應(yīng)答報文檢查策略流程

策略具體描述如下：

(1)監(jiān)聽緩存服務(wù)器端網(wǎng)卡上所有目的地址是自身IP的數(shù)據(jù)包，若其UDP源端口為53端口，則可判定該報文為DNS應(yīng)答報文。

(2)若接收到一個DNS應(yīng)答報文，但其目的端口號與緩存服務(wù)器向外發(fā)送的查詢的源端口號不匹配，表示是惡意形成的報文，則轉(zhuǎn)到步驟(6)。

(3)若接收到一個DNS應(yīng)答報文，與源端口匹配，但與DNS報文ID域不匹配，則轉(zhuǎn)到步驟(6)。

(4)若接收到一個DNS應(yīng)答報文，與源端口和交易ID均匹配，但TTL>threshold，則轉(zhuǎn)到步驟(6)，其中，threshold是當前緩存中已有記錄的最大TTL值。

(5)若上述條件均匹配，但源 IP地址不匹配，則轉(zhuǎn)到步驟(6)，否則，接收應(yīng)答報文。

(6)將attack狀態(tài)置為TRUE。保留當前查詢的合法應(yīng)答報文，不更新緩存，重查該問題(對已經(jīng)重查的問題，不再發(fā)起新的重查)。將得到的合法應(yīng)答報文與當前應(yīng)答進行比對，若應(yīng)答部分相同，則接收該應(yīng)答；否則，丟棄2次應(yīng)答報文。

(7)將 attack狀態(tài)置為 FALSE，執(zhí)行正常的解析過程。

4.2 策略分析

理論上，部署了基于應(yīng)答報文檢查的防御策略后，在一個投毒窗口中，攻擊者只有一次性猜中應(yīng)答報文才能不進入安全模式；若系統(tǒng)進入安全模式，投毒者則需要連續(xù)2次猜對應(yīng)答報文才能攻擊成功。

設(shè)攻擊者一次性猜中應(yīng)答報文的概率為P1，則：

其中，N為一個域名的權(quán)威服務(wù)器數(shù)量；I為DNS報文中的ID域范圍；P為UDP報文中的源端口號范圍。

設(shè)攻擊者連續(xù) 2次猜對應(yīng)答報文的概率為 P2，那么：

由于這2種情況不會同時出現(xiàn)，因此一個機會窗口內(nèi)攻擊的成功概率為：

由式(3)可以看出，第1種情況下攻擊者實際只有一次有效的嘗試機會。

由式(4)可知，第2種情況下投毒者需要猜測的報文空間呈指數(shù)級上升。

綜合上述2種情況，可使持續(xù)的投毒更難成功。

為了討論基于應(yīng)答報文檢查的防御策略對 DNS服務(wù)器性能的影響，考慮以下2個場景：

(1)未進入安全模式

此時，只是進行常規(guī)的應(yīng)答報文內(nèi)容的匹配，系統(tǒng)不需要額外的開銷。

(2)進入安全模式

此時，報文檢查策略只對被攻擊的域名有影響，而不會影響到其他域名的查詢與解析。

因此，當服務(wù)器沒有遭到攻擊之前，正常的應(yīng)答報文都能夠一次匹配成功，不需要額外開銷。可見，該防御策略既能降低 Kaminsky投毒成功的概率，又能將防御控制在最小范圍內(nèi)，避免波及其他正常的查詢與解析。

4.3 概率模型檢查

為了驗證上述模型的正確性，利用廣泛應(yīng)用的概率模型檢查工具 PRISM建立持續(xù)時間的馬爾可夫鏈模型，對 Kaminsky投毒和防御策略進行驗證和檢查。

實驗考慮以下4個場景：

(1)DNS服務(wù)器采用固定源端口。

(2)DNS服務(wù)器采用固定源端口，采用基于應(yīng)答報文檢查的策略。

(3)DNS服務(wù)器采用隨機化源端口。

(4)DNS服務(wù)器采用隨機化源端口，采用基于應(yīng)答報文檢查的策略。

模型的參數(shù)設(shè)置為：投毒者帶寬為100 Mb/s，投毒機會窗口為 0.1 s。模型的檢查結(jié)果如圖 5～圖 8所示。

圖5 采用固定端口的防御策略成功概率

圖6 采用固定端口和應(yīng)答報文檢查的防御策略成功概率

圖7 采用SPR的防御策略成功概率

圖8 采用SPR和應(yīng)答報文檢查的防御策略成功概率

由模型檢查的結(jié)果得出以下結(jié)論：

(1)若緩存服務(wù)器采用固定端口，而沒有采取任何防御措施，則投毒者在3s之內(nèi)成功概率可到到50%，在10 s左右即可投毒成功，可見Kaminsky投毒的危害性。

(2)若在固定端口的基礎(chǔ)上部署應(yīng)答報文檢查的策略，則投毒者需要持續(xù)投毒3 h以上，才能獲得50%的成功概率。與單純采用固定源端口相比，攻擊難度增加3600倍。

(3)若采用SPR技術(shù)，投毒者則需要持續(xù)投毒12 h以上，才能獲得50%的成功概率，但對于一個有恒心的投毒者來說，持續(xù)投毒十幾個小時是可以接受的，因此也不安全。

(4)若將SPR技術(shù)和應(yīng)答報文檢查策略結(jié)合使用，則可以獲得更高的安全性。典型地，投毒者需要攻擊20年，才可獲得 50%的成功概率。與單純采用 SPR技術(shù)相比，攻擊難度增加 14 600倍。這顯然是投毒者接受不了的。

綜上所述，無論基于哪種條件部署應(yīng)答報文檢查策略，都能大幅度降低攻擊成功的概率。這是因為應(yīng)答報文檢查策略將攻擊者置于一個兩難選擇：要么只有一次嘗試機會，要么連續(xù)2次匹配應(yīng)答報文。任何一種情況都使攻擊成功的概率大幅降低。

5 結(jié)束語

本文從概率學(xué)角度對Kaminsky投毒進行分析，提出了基于應(yīng)答報文檢查的防御策略，與當前防御策略相比，其顯著降低了投毒窗口內(nèi)投毒者的有效嘗試次數(shù)并使投毒成功的難度呈指數(shù)級上升。在現(xiàn)有防御措施基礎(chǔ)上，能夠大大增強服務(wù)器抵抗持續(xù)Kaminsky投毒的能力。但是，現(xiàn)有的 DNS仍然十分脆弱，要從機制上保證 DNS的安全，還需要部署 DNSSEC。因此，研究DNSSEC的安全性及其對DNS協(xié)議的影響，將是下一步研究的課題。

[1]Internet Governance Landscape Background Paper[EB/OL].(2010-08-11).http://www.intgovforum.org/cms/2010/Back ground/Chinese-IGF-Background-Paper.pdf.

[2]Atkins D, Austein R.Threat Analysis of the Domain Name System(DNS)[S].RFC 3833, 2004.

[3]靳 沖, 郝志宇, 吳志剛.DNS緩存投毒攻擊原理與防御策略[J].中國通信, 2009, 6(4): 17-22.

[4]Doughety C R.Multiple DNS Implementations Vulnerable to Cache Poisoning[EB/OL].(2008-08-13).http://www.kb.cert.org/Vuis/id/800113.

[5]Dagon D, Antonakakis M, Vixie P.Increased DNS Forgery Resistance Through 0x20-Bit Encoding[C]//Proceedings of ACM CCS’08.[S.l.]: ACM Press, 2008: 211-222.

[6]Larsen M, Gont F.Transport Protocol Port Randomization Recommendations[S].RFC 6056, 2010.

[7]Arends R, Austein R, Larson M.DNS Security Introduction and Requirements[S].RFC 4033, 2005.

[8]Arends R, Austein R, Larson M.Resource Records for the DNS Security Extensions[S].RFC 4034, 2005.

[9]Arends R, Austein R, Larson M.Protocol Modifications for the DNS Security Extensions[S].RFC 4035, 2005.

[10]Petr E.An Analysis of the DNS Cache Poisoning Attack[EB/OL].(2009-11-02).http://labs.nic.cz/files/labs/DNS-cache-poisoning-attack-analysis.pdf.