基于DNS協(xié)議的隱蔽通道原理及性能分析

王永杰，劉京菊

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

1 概述

隱蔽信道是指允許進(jìn)程以危害系統(tǒng)安全策略的方式傳輸信息的通信信道[1]。隱蔽信道在公開信道的掩蓋下，采用特殊的編碼方式，傳輸非法或私密的信息而不被人發(fā)現(xiàn)[2]。隱蔽信道廣泛存在于操作系統(tǒng)、網(wǎng)絡(luò)系統(tǒng)和應(yīng)用系統(tǒng)中，對網(wǎng)絡(luò)信息系統(tǒng)的安全構(gòu)成了嚴(yán)重威脅[3]。

在網(wǎng)絡(luò)安全領(lǐng)域通常將隱蔽信道稱為隱蔽通道，主要是利用網(wǎng)絡(luò)協(xié)議設(shè)計中存在的一些缺陷，通過某種算法，將隱蔽信息嵌入到合法的網(wǎng)絡(luò)數(shù)據(jù)流中[4]。傳統(tǒng)隱蔽通道主要基于傳輸層和網(wǎng)絡(luò)層協(xié)議實現(xiàn)，由于防火墻和IDS等網(wǎng)絡(luò)安全設(shè)備的存在，單純利用這2層構(gòu)造的隱蔽通道很容易被檢測出來，因此更多的研究者開始將目光投向HTTP,DNS,FTP等應(yīng)用層協(xié)議[5-7]。

DNS是互聯(lián)網(wǎng)上最為關(guān)鍵的基礎(chǔ)設(shè)施，也是互聯(lián)網(wǎng)上大部分服務(wù)和應(yīng)用正常運轉(zhuǎn)和實施的基礎(chǔ)，已經(jīng)深入到互聯(lián)網(wǎng)的各個方面，成為人們網(wǎng)絡(luò)生活中不可或缺的一環(huán)。正是因為DNS應(yīng)用的普及性和不可替代性，幾乎所有類型的網(wǎng)絡(luò)都會允許DNS協(xié)議類型的數(shù)據(jù)報文不受限制地訪問網(wǎng)絡(luò)，為基于DNS協(xié)議構(gòu)建隱蔽通道創(chuàng)造了有利條件?；诰W(wǎng)絡(luò)協(xié)議隱蔽通道技術(shù)的發(fā)展對網(wǎng)絡(luò)信息系統(tǒng)的安全構(gòu)成嚴(yán)重威脅。為此，本文基于DNS協(xié)議的隱蔽通道技術(shù)，分析了該技術(shù)采用不同編碼方式下的通信性能。

2 DNS協(xié)議的工作原理

DNS是一種可以將域名和IP地址相互映射的層次結(jié)構(gòu)的分布式數(shù)據(jù)庫系統(tǒng)[8]，主要包括如下3個組成部分：

(1)域名空間(domain name space)和資源記錄(resource record)；

(2)域名服務(wù)器(name server)；

(3)解析器(resolver)。

DNS的體系結(jié)構(gòu)如圖1所示。

圖1 DNS體系結(jié)構(gòu)

DNS系統(tǒng)采用遞歸查詢請求的方式來響應(yīng)用戶的查詢，其一般過程如下：

(1)客戶端首先向首選域名服務(wù)器查詢。

(2)首選域名服務(wù)器檢查本地資源記錄，如果存在則作權(quán)威回答，如果不存在，則檢查本地緩存，如果有記錄則直接返回結(jié)果。若本地資源記錄和緩存記錄都不存在，則向根域名服務(wù)器查詢。

(3)根域名服務(wù)器返回相應(yīng)頂級域的權(quán)威域名服務(wù)器的地址，首選域名服務(wù)器繼續(xù)向該頂級權(quán)威域名服務(wù)器查詢。

(4)頂級權(quán)威域名服務(wù)器返回次級域的權(quán)威域名服務(wù)器地址，首選域名服務(wù)器如此迭代查詢，直到得到對查詢域名的權(quán)威回答，保存在本地緩存中并返回給客戶端，完成此次查詢。

目前絕大多數(shù)的網(wǎng)絡(luò)都會開放DNS服務(wù)，DNS數(shù)據(jù)包不會被防火墻等網(wǎng)絡(luò)安全防護(hù)設(shè)備攔截，因此，可以基于DNS協(xié)議建立隱蔽通道，從而順利穿過防火墻，在客戶端和服務(wù)器之間隱蔽地傳輸數(shù)據(jù)。

3 DNS協(xié)議隱蔽通道的技術(shù)原理

3.1 DNS隱蔽通道的基本原理

DNS隱蔽通道技術(shù)的基本思想是利用一臺偽裝的DNS服務(wù)器為中轉(zhuǎn)節(jié)點，利用DNS查詢過程建立隱蔽通道，實現(xiàn)數(shù)據(jù)傳輸[9-10]。簡單DNS隱蔽通道的工作模式如圖2所示。

圖2 DNS隱蔽通道的基本工作模式

假設(shè)外部網(wǎng)絡(luò)控制主機(jī)的IP地址為X.Y.W.Z，同時在.com頂級域名服務(wù)器中將域名tmp.com注冊為該IP，即把主機(jī)X.Y.W.Z作為tmp.com域的權(quán)威域名服務(wù)器。內(nèi)部主機(jī)(被控端)通過DNS隱蔽通道與外部網(wǎng)絡(luò)控制主機(jī)(主控端)傳輸數(shù)據(jù)的過程如下：

(1)內(nèi)部主機(jī)把要發(fā)送的數(shù)據(jù)作為主機(jī)名構(gòu)造一個域名解析查詢請求，例如圖2中的查詢請求：updata.tmp.com。

(2)查詢請求首選發(fā)送到本地的首選DNS服務(wù)器，首選DNS服務(wù)器通過向.com頂級域名服務(wù)器查詢得到tmp.com域?qū)?yīng)的IP地址X.Y.W.Z。

(3)首選DNS服務(wù)器向主機(jī)X.Y.W.Z發(fā)送DNS查詢請求：updata.tmp.com。

(4)主機(jī)X.Y.W.Z從查詢請求中得到內(nèi)部主機(jī)上傳的數(shù)據(jù)updata。

(5)主機(jī)X.Y.W.Z將要傳送給內(nèi)部主機(jī)的數(shù)據(jù)downdata作為DNS查詢請求的響應(yīng)信息回送給本地首選DNS服務(wù)器。

(6)本地的首選DNS服務(wù)器將包含downdata的查詢結(jié)果返回給內(nèi)部主機(jī)，從而實現(xiàn)內(nèi)部主機(jī)與外部控制主機(jī)間的雙向通信。

上述的DNS隱蔽通道雖然能夠?qū)崿F(xiàn)簡單的雙向通信，但也存在著一些明顯的局限性，主要體現(xiàn)在以下方面：

(1)DNS數(shù)據(jù)包的長度有限，無法攜帶較多的數(shù)據(jù)，難以滿足文件傳送、遠(yuǎn)程桌面控制等大數(shù)據(jù)量密集通信應(yīng)用的需求。

(2)大數(shù)據(jù)量通信將產(chǎn)生大量的DNS查詢請求報文，很容易被入侵檢測系統(tǒng)發(fā)現(xiàn)并定位通信源。

3.2 DNS隱蔽通道的數(shù)據(jù)編碼技術(shù)

DNS隱蔽通道將上傳的數(shù)據(jù)作為DNS查詢的主機(jī)名字段。在有關(guān)DNS協(xié)議的標(biāo)準(zhǔn)RFC1034中規(guī)定[11]，整個域名的最大長度為253 Byte，域名的各部分之間用“.”分隔，各部分最大長度為63 Byte，每個字符可以是字母(不區(qū)分大小寫)、數(shù)字或連接符“-”。

對于上述例子中的域tmp.com，最長的主機(jī)名字段的格式可以表示為：

[63字符].[63字符].[63字符].[53字符].tmp.com

因此，在一個DNS查詢報文中最多可以攜帶242個字符，每個字符可以有37個不同的取值。如果要使用DNS隱蔽通道傳遞任意數(shù)據(jù)，則必須先對要傳輸?shù)臄?shù)據(jù)進(jìn)行編碼，使其滿足標(biāo)準(zhǔn)的要求。

一種常用的編碼策略是使用BASE-32編碼，每個字節(jié)編碼5個比特的原始數(shù)據(jù)。在此編碼方式下，一個DNS查詢報文最多可攜帶數(shù)據(jù)量為242×5/8≈151 Byte。

DNS隱蔽通道通常使用TXT類型的數(shù)據(jù)記錄來攜帶下傳數(shù)據(jù)，TXT記錄主要用來保存域名的附加文本信息[12]，為了方便傳輸通常使用BASE-64編碼對要傳輸?shù)臄?shù)據(jù)進(jìn)行編碼，每個字節(jié)編碼6個比特的原始數(shù)據(jù)。

在較新的RFC標(biāo)準(zhǔn)文檔RFC 2181[13]和RFC 4343[14]中規(guī)定域名記錄的各個部分都可以使用任何二進(jìn)制字符，而不再局限于RFC1034所規(guī)定的有限字符集合。測試結(jié)果表明，目前有部分DNS服務(wù)軟件已經(jīng)支持二進(jìn)制字符。使用二進(jìn)制方式編碼數(shù)據(jù)可以顯著提高DNS隱蔽通道的效率，但在使用前必須在主控端和被控端間協(xié)商確認(rèn)雙方都能夠支持二進(jìn)制編碼，否則仍需使用BASE-32等編碼方式編碼數(shù)據(jù)。

3.3 DNS隱蔽通道的躲避檢測技術(shù)

前面已經(jīng)提到，基本的DNS隱蔽通道在通信過程中會產(chǎn)生大量來自同一主機(jī)的DNS查詢網(wǎng)絡(luò)流量，流量分布特征十分明顯，很容易被入侵檢測系統(tǒng)檢測到異常。

為了降低DNS隱蔽通道被發(fā)現(xiàn)的風(fēng)險，一種有效的策略是采用蒙騙式通信。具體思路是利用DNS協(xié)議基于UDP協(xié)議工作的特點，在DNS隱蔽通道的內(nèi)部網(wǎng)絡(luò)源主機(jī)節(jié)點處隨機(jī)偽造內(nèi)部網(wǎng)絡(luò)其他主機(jī)IP地址發(fā)送偽裝的DNS查詢請求，從而平衡流量分布特征。雖然外部控制主機(jī)仍然能夠收到內(nèi)部主機(jī)上傳的數(shù)據(jù)，但是外部控制主機(jī)下傳的數(shù)據(jù)將發(fā)送給被偽造IP地址的主機(jī)。內(nèi)部主機(jī)將無法接收來自外部控制主機(jī)的數(shù)據(jù)，從而DNS隱蔽通道將變成一個單向通道。

為了解決此問題，可以采取將上傳通道與下傳通道分開的措施，將其變?yōu)?個獨立的通道。上傳通道使用偽造源IP地址數(shù)據(jù)包向管理控制端上傳數(shù)據(jù)，管理控制端只需對其回應(yīng)一個表示查詢記錄不存在的NXDOMAIN標(biāo)志。內(nèi)部主機(jī)再使用自己的真實IP地址發(fā)送一個帶特殊標(biāo)記但不包含上傳數(shù)據(jù)的DNS查詢請求到管理控制端，管理控制端在收到該特殊標(biāo)記后，將下傳數(shù)據(jù)封裝到應(yīng)答報文中回送到內(nèi)部主機(jī)，從而實現(xiàn)下傳通道。上傳通道與下傳通道分離后的DNS隱蔽通道的工作模式如圖3所示。

圖3 上傳通道與下傳通道分離后的DNS隱蔽通道

為了進(jìn)一步增強(qiáng)躲避檢測的效果，可以將偽造的源IP限制在內(nèi)部主機(jī)所在網(wǎng)絡(luò)鄰居主機(jī)IP地址的范圍內(nèi)，而且在偽造上行通道的DNS請求數(shù)據(jù)包時，將其源IP和MAC地址同時偽造為鄰居主機(jī)的IP和MAC地址。鄰居主機(jī)的IP與MAC對應(yīng)關(guān)系可以通過ARP掃描獲得。

3.4 DNS隱蔽通道的可靠通信技術(shù)

由于UDP協(xié)議本身不提供數(shù)據(jù)包的可靠傳輸機(jī)制，因此基于UDP協(xié)議的DNS隱蔽通道在工作時可能出現(xiàn)丟包現(xiàn)象。同時DNS隱蔽通道面臨著識別上傳數(shù)據(jù)包的源IP是否真實、協(xié)商數(shù)據(jù)編碼方式、多個被控主機(jī)節(jié)點標(biāo)識等問題。

為了解決上述問題，保證DNS隱蔽通道的可靠通信，可以借鑒TCP協(xié)議的工作機(jī)制，設(shè)計DNS隱蔽通道專用通信協(xié)議，具體數(shù)據(jù)報文格式如圖4所示。

圖4 DNS隱蔽通道專用通信協(xié)議數(shù)據(jù)報文格式

整個數(shù)據(jù)報文分為兩大部分，第一部分采用BASE-32編碼，主要包含4個標(biāo)識；第二部分采用BASE-32編碼或直接采用二進(jìn)制模式，主要包括節(jié)點ID號、數(shù)據(jù)的發(fā)送序號、確認(rèn)序號和數(shù)據(jù)內(nèi)容。其中，各字段的含義如下：

(1)標(biāo)識PSP表示數(shù)據(jù)包是否是偽造源地址，1：偽造，0：真實。

(2)標(biāo)識HND表示數(shù)據(jù)包是否是協(xié)商數(shù)據(jù)包，1：協(xié)商，0：正常。

(3)標(biāo)識STM表示被控端到主控端的編碼方式，1：BASE-32，0：二進(jìn)制。

(4)標(biāo)識MTS表示主控端到被控端的編碼方式，1：BASE-64，0：二進(jìn)制。

(5)字段NID表示被控端的ID編號，用來區(qū)分不同的被控端節(jié)點。

(6)字段SEQN和ACKN用來實現(xiàn)數(shù)的可靠傳輸。字段SEQN表示發(fā)送數(shù)據(jù)起始序號；字段ACKN表示接收并確認(rèn)的數(shù)據(jù)序號。

(7)字段DATA承載要傳輸?shù)挠行?shù)據(jù)，可能是原始二進(jìn)制數(shù)據(jù)，也可能是編碼后的數(shù)據(jù)。

3.5 DNS隱蔽通道的通信速率控制技術(shù)

通過心跳信號自適應(yīng)調(diào)整DNS隱蔽通道下行通道數(shù)據(jù)發(fā)送速率的原理如圖5所示。

圖5 DNS隱蔽通道的通信速率自適應(yīng)控制流程

DNS隱蔽通道的主控端只有在收到被控端的請求后才可以向被控端發(fā)送數(shù)據(jù)，但被控端并非總有數(shù)據(jù)要向主控端傳遞，在此情況下主控端的數(shù)據(jù)就不能及時地發(fā)送到被控端。為解決此問題，可以在被控端設(shè)置一個一個心跳信號，周期性地向控制端發(fā)送請求。心跳信號的周期可以設(shè)置為根據(jù)控制端待發(fā)送數(shù)據(jù)量進(jìn)行自適應(yīng)調(diào)整。

當(dāng)控制端有更多數(shù)據(jù)要發(fā)送時，在發(fā)送數(shù)據(jù)報文中設(shè)置更多數(shù)據(jù)標(biāo)志。當(dāng)被控端檢測到該標(biāo)志時，逐漸地減小心跳信號的發(fā)送周期，使發(fā)送端的剩余數(shù)據(jù)能夠盡快地發(fā)送出去。否則，當(dāng)檢測到該標(biāo)志未置位后，被控端則逐漸增加心跳信號的發(fā)送周期，降低隱蔽通道的數(shù)據(jù)流量。

4 基于DNS協(xié)議隱蔽通道的性能分析

根據(jù)前面對DNS隱蔽通道原理的分析，可知DNS隱蔽通道的上傳通道可以使用BASE-32和二進(jìn)制2種編碼方式，下傳通道可以使用BASE-64和二進(jìn)制2種編碼方式。BASE-32和BASE64編碼方式的通用性強(qiáng)，可以應(yīng)用于所有標(biāo)準(zhǔn)DNS系統(tǒng)，但通信效率較低。二進(jìn)制方式的通信效率較高，但是其通用性較差，部分DNS系統(tǒng)不支持二進(jìn)制數(shù)據(jù)。

DNS隱蔽通道的上行通道每個請求數(shù)據(jù)包可攜帶的編碼后有效數(shù)據(jù)長度大約240 Byte，下行通道每個應(yīng)答數(shù)據(jù)包可攜帶的編碼后有效數(shù)據(jù)長度大約250 Byte。相應(yīng)上行通道的BASE-32編碼前有效數(shù)據(jù)長度約150 Byte，下行通道的BASE-64編碼前有效數(shù)據(jù)長度約158 Byte。

如果系統(tǒng)支持二進(jìn)制編碼方式，則上行通道的容量可以比BASE-32編碼方式提高約(8–5)/5＝60%，而下行通道的容量可以比BASE-64編碼方式提高約(8–6)/6≈33%。因此，在隱蔽通道建立連接時，首先在被控端和主控端之間進(jìn)行協(xié)商，如果雙方都支持二進(jìn)制編碼方式，則優(yōu)先采用二進(jìn)制編碼方式，否則采用BASE-32或BASE-64編碼方式。

5 結(jié)束語

基于DNS協(xié)議隱蔽通道，利用作為網(wǎng)絡(luò)基礎(chǔ)設(shè)施的DNS系統(tǒng)來中轉(zhuǎn)數(shù)據(jù)，具有穿透力強(qiáng)、通信過程隱蔽等優(yōu)點，同時將上行通道與下行通道分離，對有效數(shù)據(jù)加密與編碼處理后通過自定義上層協(xié)議實現(xiàn)雙向的可靠傳輸。本文對一種隱蔽能力強(qiáng)、穩(wěn)定性好的基于DNS協(xié)議隱蔽通道的基本原理、工作模式、關(guān)鍵技術(shù)和性能等方面進(jìn)行分析。相對于傳統(tǒng)的ICMP協(xié)議隱蔽通道、HTTP代理隱蔽通道等容易受防火墻攔截過濾的缺陷，本文提出基于DNS協(xié)議的隱蔽通道技術(shù)具有通過率高，防火墻基本不攔截；隱蔽性好，檢測系統(tǒng)基本不檢查等優(yōu)點。

[1]U.S.Department of Defense.DoD 5200.28-STD-1985 Trusted Computer System Evaluation Criteria[S].1985.

[2]Zander S,Armitage G,Branch P.A Survey of Covert Channels and Countermeasures in Computer Network[J].IEEE Communications Surveys and Tutorials,2007,9(1-4):44-57.

[3]王永吉,吳敬征,曾海濤.隱蔽信道研究[J].軟件學(xué)報,2010,21(9):2262-2288.

[4]宋俊榮.基于多層協(xié)議的網(wǎng)絡(luò)隱通道研究[D].南京:南京理工大學(xué),2009.

[5]張 敏,張 彤.TCP/IP網(wǎng)絡(luò)中隱蔽信道的實現(xiàn)和特點[J].網(wǎng)絡(luò)安全技術(shù)與應(yīng)用,2007,(10):25-29.

[6]陳春生.基于網(wǎng)絡(luò)流的隱蔽通信技術(shù)研究[D].鎮(zhèn)江:江蘇科技大學(xué),2011.

[7]史 敏,劉 飛.淺析基于DNS協(xié)議的隱蔽通道及檢測技術(shù)[J].保密科學(xué)技術(shù),2011,(4):61-65.

[8]王 垚.域名系統(tǒng)安全性研究[D].哈爾濱:哈爾濱工業(yè)大學(xué),2007.

[9]谷傳征,王軼駿,薛 質(zhì).基于DNS協(xié)議的隱蔽信道研究[J].信息安全與通信保密,2011,(12):82-83.

[10]谷傳征.DNS協(xié)議隱蔽信道的構(gòu)建和檢測技術(shù)研究[D].上海:上海交通大學(xué),2012.

[11]Mockapetris P.Domain Names-concepts and Facilities[S].RFC 1034,1987.

[12]Mockapetris P.Domain Names-implementation and Specification[S].RFC 1035,1987.

[13]Elz R,Bush R.Clarifications to the DNS Specification[S].RFC 2181,1997.

[14]Eastlake D.Domain Name System(DNS)Case Insensitivity Clarification[S].RFC 4343,2006.