胡宗輝， 甘 剛

(成都信息工程大學信息安全工程學院，四川成都610225)

0 引言

計算機網(wǎng)絡從1969年美國開始建立ARPANet開始，到現(xiàn)在短短幾十年中，計算機網(wǎng)絡技術的發(fā)展和普及可謂是“一日千里”，網(wǎng)絡發(fā)展的早起，網(wǎng)絡的使用限制于一個比較小的范圍內，對網(wǎng)絡的安全缺乏足夠的重視。當時設計之初的主要目的是“方便共享資源和交換信息”，而在于保障信息安全方面的設計也非常有限?；ヂ?lián)網(wǎng)自身的特征是方便、自由開放，這就顯示出互聯(lián)網(wǎng)的軟弱性特征，在互聯(lián)網(wǎng)使用過程中受到各方面的襲擊［1］。由于在早起網(wǎng)絡協(xié)議的開放性和共享性，協(xié)議在設計的時候在安全方面考慮不足，比如:缺乏認證機制和加密機制，使計算機網(wǎng)絡在設計之初就存在一些安全隱患。隨著計算機網(wǎng)絡的爆發(fā)式發(fā)展，網(wǎng)絡不在被地理位置限制，到現(xiàn)在計算機網(wǎng)絡已經(jīng)遍布全世界。由于網(wǎng)絡開放的環(huán)境，如果要在網(wǎng)絡上傳遞一些敏感信息的時候，信息安全就會受到很大的威脅。因此確保信息在使在網(wǎng)絡中安全傳輸變得越來越重要［2］。

隨著2013年斯諾登事件的爆發(fā)，信息安全已經(jīng)被提升為一個國家戰(zhàn)略層的高度。由于網(wǎng)絡的普及，網(wǎng)絡安全已經(jīng)成為計算機技術中一個重要的研究領域。隨著網(wǎng)絡攻擊的發(fā)展，防火墻技術也是“日新月異”，我們平時在訪問網(wǎng)絡的時候，一般都會使用防火墻。一般公司內使用的防火墻從大的方面來講分為內部防火墻和外部防火墻。當訪問網(wǎng)絡的時候，一般都會使用防火墻進行網(wǎng)絡訪問的限制;比如:進行端口過濾，IP過濾等限制。

文中探討使用DNS隧道，在DNS隧道中封裝數(shù)據(jù)，來打破防火墻的限制［3］。當訪問互聯(lián)網(wǎng)的時候，大多數(shù)的防火墻和網(wǎng)絡都開放DNS服務［4］;就是利用防火墻對DNS協(xié)議的信任關系建立DNS隧道，以達到數(shù)據(jù)傳輸?shù)哪康摹?/p>

1 DNS協(xié)議基本原理

域名系統(tǒng)(Doain Name System，DNS)是一種把計算機名解析為對應的IP地址的服務［5］。

圖1 dns解析示意圖

DNS解析原理:

(1)當輸入域名，按下enter鍵訪問網(wǎng)址的時候，客戶端先向本地的DNS服務器發(fā)送查詢請求。

(2)本地DNS服務器收到請求，先查詢緩存是否有該域名的記錄;有的話，就直接返回;沒有就向配置的根DNS發(fā)送請求;根DNS會先查詢得到頂級域名DNS服務器的IP地址，然后返回給本地DNS服務器［6］。

(3)本地DNS服務器就根據(jù)返回的IP，繼續(xù)請求頂級域名服務器;頂級域名服務器也做類似的過程:先查緩存，沒有就返回二級域名DNS服務器的地址給本地DNS服務器。

(4)然后本地域名服務器就向二級域名DNS發(fā)送請求，繼續(xù)類似的過程。

(5)直到最后權威DNS服務器向本地服務器返回對應的IP地址。

(6)然后本地DNS服務器返回給主機，然后主機在訪問這個IP地址。

DNS解析就是這樣逐層遞歸的方式，最終把域名的對應的IP地址返回到本機。

例如:當主機首次訪問www.baidu.com時，就會按照上邊的遞歸查詢方式進行遞歸查詢。

(1)當首次訪問的時候，主機先向本地DNS服務器發(fā)送查詢請求。

(2)本地域名服務器收到請求后，先查詢緩存是否有該域名的記錄;有的話，就直接返回;沒有就向配置的根DNS發(fā)送請求;根DNS先查詢得到頂級域名DNS服務器(.com)的IP地址，然后返回給本地DNS服務器［6］。

(3)本地域名服務器就根據(jù)返回的IP，繼續(xù)請求頂級域名服務器;頂級域名服務器也會做類似的過程:先查緩存，沒有就返回二級域名DNS服務器(baidu.com)的地址給本地DNS服務器。

(4)然后本地DNS服務器就向二級域名DNS服務器發(fā)送請求;二級域名DNS服務器就先查詢自己的緩存，發(fā)現(xiàn)有www.baidu.com對應的IP地址;就直接返回給本地DNS服務器。

(5)本地DNS服務器把查詢到的IP地址返回給主機。

(6)主機獲得了www.baidu.com域名的IP地址，就可以訪問該網(wǎng)站了。

2 DNS隧道傳輸數(shù)據(jù)的具體實現(xiàn)

2．1 DNS隧道建立的原理

根據(jù)DNS查詢過程，利用專門解析某種類型域名的DNS服務器，在DNS的查詢過程中建立起DNS隧道。

圖2 dns隧道通信示意圖

假設運行在內部主機上的客戶端，想與外網(wǎng)的DNS服務器進行通信;在內部網(wǎng)絡中存在一個本地DNS服務器，所有想上網(wǎng)進行域名查詢的主機都要經(jīng)過這個本地DNS服務器;在網(wǎng)絡邊緣存在一個防火墻;外網(wǎng)的定制的DNS服務器相當于服務端，負責某種所有定制類型的域名的解析(比如:定制的testuu.com這種類型的域名)。

由于防火墻的限制，一般邊界防火墻都會限制內部網(wǎng)絡的提供的服務:比如對ftp服務的20和21端口過濾，對telnet服務的23端口進行過濾;而對從外部網(wǎng)絡訪問內部網(wǎng)絡可能會對IP地址的限制。但是如果內部網(wǎng)絡要上網(wǎng)，那么就要使用DNS服務，那么防火墻一般對DNS服務是信任的。利用DNS服務的查詢和遞歸解析的過程，建立起這個DNS隧道。

過程如下:

(1)首先要注冊個域名，比如在美橙域名注冊機構中注冊一個qh.cn的域名，然后設置qh.cn的域名服務器的IP地址為自己的主機IP地址。這樣類似于*.qh.cn域名查詢都會到自己的主機中［4］。

(2)配置定制服務器，在服務器上設置監(jiān)聽DNS的53端口，接受DNS請求，并且只解析類似于qh.cn這樣的域名。

(3)運行在網(wǎng)絡內部主機上的客戶端，查詢定制類型的域名*.up.qh.cn(表示上行數(shù)據(jù));由于這個域名是定制的;在查詢的時候，本地DNS是查詢不到的;那么根據(jù)上邊的DNS遞歸查詢過程，本地DNS就先通過邊界防火墻，然后從根域名服務器一層一層的去查詢;最終會傳遞給定制的DNS;定制DNS通過域名解析，得到這個域名中存儲的信息。

(4)然后定制DNS，把要返回的信息封裝成DNS報文*.down.qh.cn(表示下行數(shù)據(jù))返回給內部網(wǎng)絡的客戶端。

(5)這樣通過DNS域名查詢和返回，就建立起DNS隧道了。

2．2 DNS數(shù)據(jù)報文格式

如果要把傳輸?shù)臄?shù)據(jù)封裝到DNS隧道中，就要知道DNS協(xié)議數(shù)據(jù)包的結構，DNS報文的基本格式如圖3所示。

圖3 dns報文格式

在圖3，Header是DNS報文的報頭部分。報頭部分的第一個字段是ID，表示是DNS每次查詢的時候分配的一個16位的標識符;第二個字段是“標識字段”，由 QR，Opcode，AA，TC，RD，RA，000，Rcode 這些標識符組成。QR是報文類型標志，請求報文QR=0，應答報文QR=1。Opcode是操作碼標志位，主要用于設置查詢的種類。AA授權應答標志位，僅在應答報文中有意義。TC截斷標志位，表示報文是否被分段。RD期望遞歸標志位，在請求報文中有意義;表示建議域名使用遞歸查詢方法。RA在應答報文中設置，表示服務器是否支持遞歸查詢。Rcode是應答碼標志位，在應答報文中設置。QDcount表示報文數(shù)據(jù)部分的查詢消息字段中的問題條數(shù)。ANcount表示報文數(shù)據(jù)部分應答消息字段中的資源記錄數(shù)。NScount表示表示報文數(shù)據(jù)部分授權應答字段中的名稱服務器資源記錄數(shù)。ARcount表示報文數(shù)據(jù)部分附加消息字段中的資源記錄數(shù)。

Query是DNS請求報文中的請求消息部分，包含QName、Qtype、QClass。QName 表示請求的域名，以ASCII碼表示;Qtype表示查詢的資源記錄類型;QClass表示查詢類別。

Response、Authority、Additional是 DNS 應答報文中顯示所應答的記錄信息，這些記錄格式是一樣的。NAME表示記錄對應的域名，與請求報文中的QName一致;TYPE是記錄類型;CLASS是記錄數(shù)據(jù)的類型;TTL表示該記錄信息緩存的時間;Rdlength表示Rdata字段的長度;Rdata表示具體的記錄數(shù)據(jù)。

在RFC1023中規(guī)定:為和現(xiàn)有的域名相互兼容，域名以分隔號分開，并且各個分隔號之間的長度(labels)小于63個字符，并且一個域名的總長度不能超過255個字符［7］，因此一個QName最多能夠攜帶200多個字符;并且還需要對存放的信息進行編碼(base32/base64編碼);比較新的 RFC2181和RFC4343中規(guī)定，域名部分還可以使用二進制編碼的方式。

QName的格式如圖4所示。

圖4 QName(請求域名)的格式

由圖4中可以看出域名都是由一系列:域名長度對應的域名ASCII碼，這種類似的標簽(labels)組成。

當DNS中出現(xiàn)重復的域名的時候，為了減小報文的長度，DNS使用一種壓縮方式來壓縮報文，這種壓縮方式可以消除域名中重復的報文;使用這種方式，后邊重復出現(xiàn)的域名就變成之前重復出現(xiàn)的域名偏移位置的指針(pointer)，以wireshark抓包結果為例，如圖5所示。

圖5 DNS報文壓縮的格式

由于DNS壓縮的時候，把重復的labels變?yōu)檫@些域名出現(xiàn)的位置相對于DNS報文開始的偏移值(pointer)。

labels和pointer的區(qū)別是，由于labels最大長度為63［8］，因此長度字段的前2bit位一定0;而pointer是由2個字節(jié)組成，并且前2bits為11，后邊的14bits是偏移值。這樣labels就與偏移指針區(qū)分開來了。

2．3 DNS報文存儲數(shù)據(jù)原理

當DNS報文中出現(xiàn)重復的域名，DNS報文就使用壓縮方式;在DNS壓縮報文中可以利用pointer指向的偏移位置，來構造松弛空間(松弛空間的作用就是存放要通信的數(shù)據(jù))。

圖6 DNS報文存儲數(shù)據(jù)原理圖

按照圖6的格式，通過操作pointer指針的指向位置，在DNS數(shù)據(jù)包中創(chuàng)建松弛空間，然后把通信的數(shù)據(jù)(Injected data)放到這部分松弛空間中［1］;這樣就把數(shù)據(jù)封裝到DNS數(shù)據(jù)包中了，然后在經(jīng)過DNS隧道的傳遞，就能實現(xiàn)信息的交互。

松弛空間的構造過程如下:

(1)先根據(jù)圖5的DNS協(xié)議的報文格式，構造原始DNS請求數(shù)據(jù)，格式如圖6上半部分表格的樣子，如下:

(2)然后把原始DNS請求數(shù)據(jù)按照圖6中下本部分表格的樣式修改，如下:

(3)這樣按照圖6的指針偏移位置就形成了松弛空間。

(4)然后把要傳輸?shù)臄?shù)據(jù)經(jīng)過編碼等變形之后，放到松弛空間中，如下:

(5)這樣就利用DNS隧道的方式實現(xiàn)了數(shù)據(jù)的傳輸。

3 環(huán)境搭建與實現(xiàn)

3．1 實現(xiàn)方法

在linux下使用C語言實現(xiàn)

(1)搭建環(huán)境，首先要建立一個域名服務器，比如在美橙域名注冊機構中注冊一個定制的的域名，然后設置這個域名服務器的IP地址為自己的主機IP地址。這樣查詢這個域名的時候，最終訪問這個定制的域名服務器。

(2)然后利用C語言按照下邊的程序流程圖編寫程序。

圖7 程序實現(xiàn)流程

3．2 測試結果與分析

圖8 訪問端

下面對前面研究所提出的訪問程序的有效性與可行性，配置了一個虛擬環(huán)境進行研究與分析，虛擬環(huán)境為Windows XP、Windows 7，代碼使用C編寫。

通過實驗測試，服務端和客戶端成功連接，可以瀏覽目標主機的目錄，進行相應的訪問操作。結果如圖2所示。

同時，實驗通過在不同環(huán)境下進行測試，可以成功通過安裝有表1中3種防火墻環(huán)境的內網(wǎng)。并且實現(xiàn)了在XP、WIN7等不同操作系統(tǒng)下的訪問。

表1 穿透內網(wǎng)防火墻測試結果

4 結束語

主要介紹通過DNS的查詢和應答過程建立起DNS隧道，結合DNS報文壓縮的格式，通過操作pointer指針來存儲數(shù)據(jù)，然后利用防火墻對DNS的信任關系;以達到穿透防火墻進行通信的目的。隨著網(wǎng)絡技術的不斷發(fā)展，相關研究領域的技術也在發(fā)生深刻變化。一方面要求提供更高的穩(wěn)定性;另一方面要求提供高的兼容性，為了支持更高的傳輸速率和可靠性，以滿足多種需求，該技術具有良好的應用前景［8］。

［1］ 劉西青.淺談計算機網(wǎng)絡安全問題［J］.軟件，2013，34(12)：239.

［2］ 黃存東.關于計算機網(wǎng)絡信息安全問題的技術研究［J］.軟件，2011.

［3］ Dusi M，Crotti M，Gringoli F，et al.Tunnel hunter：Detecting application-layer tunnels with statistical fingerprinting［J］. Computer Networks.2009.

［4］ 谷傳征，王軼駿，薛質.基于DNS協(xié)議的隱蔽信道研究［J］.信息安全與通信保密.2011.

［5］ Eastlake D.Domain name system security extensinas［J］.RFC 2535，1999.

［6］ 李海明，蘇開宇.DNS安全威脅與防護［J］.計算機安全.2011.

［7］ 王永杰，劉京菊.基于DNS協(xié)議的隱蔽通道原理及性能分析［J］.計算機工程2014，(7).

［8］ 章思宇，鄒福泰，王魯華，等.基于DNS的隱蔽通道流量檢測［J］.通信學報.2013.

［9］ Born K，Gustafson D.Detecting DNS tunnels u-sing character frequency analysis［C］.Proceedings of the 9th Annual Security Conference.2010.

［10］ 孔政，姜秀柱.DNS欺騙原理及其防御方案［J］.計算機工程.2010.

［11］ 劉曉麗.基于DNS代理的網(wǎng)絡訪問控制系統(tǒng)的實現(xiàn)［J］.華東科技：學術版.2013.

［12］ 蔡昭權，王美珍，梅松，等.一種新的基于DNS協(xié)議的IPSec隱蔽通信研究［J］.計算機應用.2008，(7).

［13］ 吳其祥，李祖猛，馬華.基于HTTP協(xié)議的隱蔽信道研究［J］.信息安全與通信保密.2009.

［14］ 史曉敏，劉飛.淺析基于DNS協(xié)議的隱蔽通道及監(jiān)測技術［J］.保密科學技術.2011.

［15］ 劉靜，裘國永.基于反向連接、HTTP隧道和共享DNS的防火墻穿透技術［J］.鄭州輕工業(yè)學院學報2007，(10).