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

王永杰，劉京菊

(電子工程學院網絡工程系，合肥 230037)

1 概述

隱蔽信道是指允許進程以危害系統安全策略的方式傳輸信息的通信信道[1]。隱蔽信道在公開信道的掩蓋下，采用特殊的編碼方式，傳輸非法或私密的信息而不被人發現[2]。隱蔽信道廣泛存在于操作系統、網絡系統和應用系統中，對網絡信息系統的安全構成了嚴重威脅[3]。

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

DNS是互聯網上最為關鍵的基礎設施，也是互聯網上大部分服務和應用正常運轉和實施的基礎，已經深入到互聯網的各個方面，成為人們網絡生活中不可或缺的一環。正是因為DNS應用的普及性和不可替代性，幾乎所有類型的網絡都會允許DNS協議類型的數據報文不受限制地訪問網絡，為基于DNS協議構建隱蔽通道創造了有利條件。基于網絡協議隱蔽通道技術的發展對網絡信息系統的安全構成嚴重威脅。為此，本文基于DNS協議的隱蔽通道技術，分析了該技術采用不同編碼方式下的通信性能。

2 DNS協議的工作原理

DNS是一種可以將域名和IP地址相互映射的層次結構的分布式數據庫系統[8]，主要包括如下3個組成部分：

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

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

(3)解析器(resolver)。

DNS的體系結構如圖1所示。

圖1 DNS體系結構

DNS系統采用遞歸查詢請求的方式來響應用戶的查詢，其一般過程如下：

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

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

(3)根域名服務器返回相應頂級域的權威域名服務器的地址，首選域名服務器繼續向該頂級權威域名服務器查詢。

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

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

3 DNS協議隱蔽通道的技術原理

3.1 DNS隱蔽通道的基本原理

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

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

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

(1)內部主機把要發送的數據作為主機名構造一個域名解析查詢請求，例如圖2中的查詢請求：updata.tmp.com。

(2)查詢請求首選發送到本地的首選DNS服務器，首選DNS服務器通過向.com頂級域名服務器查詢得到tmp.com域對應的IP地址X.Y.W.Z。

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

(4)主機X.Y.W.Z從查詢請求中得到內部主機上傳的數據updata。

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

(6)本地的首選DNS服務器將包含downdata的查詢結果返回給內部主機，從而實現內部主機與外部控制主機間的雙向通信。

上述的DNS隱蔽通道雖然能夠實現簡單的雙向通信，但也存在著一些明顯的局限性，主要體現在以下方面：

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

(2)大數據量通信將產生大量的DNS查詢請求報文，很容易被入侵檢測系統發現并定位通信源。

3.2 DNS隱蔽通道的數據編碼技術

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

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

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

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

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

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

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

3.3 DNS隱蔽通道的躲避檢測技術

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

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

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

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

為了進一步增強躲避檢測的效果，可以將偽造的源IP限制在內部主機所在網絡鄰居主機IP地址的范圍內，而且在偽造上行通道的DNS請求數據包時，將其源IP和MAC地址同時偽造為鄰居主機的IP和MAC地址。鄰居主機的IP與MAC對應關系可以通過ARP掃描獲得。

3.4 DNS隱蔽通道的可靠通信技術

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

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

圖4 DNS隱蔽通道專用通信協議數據報文格式

整個數據報文分為兩大部分，第一部分采用BASE-32編碼，主要包含4個標識；第二部分采用BASE-32編碼或直接采用二進制模式，主要包括節點ID號、數據的發送序號、確認序號和數據內容。其中，各字段的含義如下：

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

(2)標識HND表示數據包是否是協商數據包，1：協商，0：正常。

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

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

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

(6)字段SEQN和ACKN用來實現數的可靠傳輸。字段SEQN表示發送數據起始序號；字段ACKN表示接收并確認的數據序號。

(7)字段DATA承載要傳輸的有效數據，可能是原始二進制數據，也可能是編碼后的數據。

3.5 DNS隱蔽通道的通信速率控制技術

通過心跳信號自適應調整DNS隱蔽通道下行通道數據發送速率的原理如圖5所示。

圖5 DNS隱蔽通道的通信速率自適應控制流程

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

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

4 基于DNS協議隱蔽通道的性能分析

根據前面對DNS隱蔽通道原理的分析，可知DNS隱蔽通道的上傳通道可以使用BASE-32和二進制2種編碼方式，下傳通道可以使用BASE-64和二進制2種編碼方式。BASE-32和BASE64編碼方式的通用性強，可以應用于所有標準DNS系統，但通信效率較低。二進制方式的通信效率較高，但是其通用性較差，部分DNS系統不支持二進制數據。

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

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

5 結束語

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

[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].軟件學報,2010,21(9):2262-2288.

[4]宋俊榮.基于多層協議的網絡隱通道研究[D].南京:南京理工大學,2009.

[5]張 敏,張 彤.TCP/IP網絡中隱蔽信道的實現和特點[J].網絡安全技術與應用,2007,(10):25-29.

[6]陳春生.基于網絡流的隱蔽通信技術研究[D].鎮江:江蘇科技大學,2011.

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

[8]王 垚.域名系統安全性研究[D].哈爾濱:哈爾濱工業大學,2007.

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

[10]谷傳征.DNS協議隱蔽信道的構建和檢測技術研究[D].上海:上海交通大學,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.