章思宇，鄒福泰，王魯華，陳銘

（1.上海交通大學 信息安全工程學院，上海 200240；2.國家計算機網(wǎng)絡與信息安全管理中心，北京 100017；3.上海交通大學 密西根學院，上海 200240）

1 引言

網(wǎng)絡隱蔽通道是攻擊者繞過網(wǎng)絡安全策略進行數(shù)據(jù)傳輸?shù)闹匾緩剑鳧NS（域名系統(tǒng)）則是實現(xiàn)應用層隱蔽通道的常用手段。

DNS是互聯(lián)網(wǎng)最為關鍵的基礎設施之一，將域名與IP地址相互映射。由于其在網(wǎng)絡運行中的重要地位，DNS協(xié)議幾乎不會被防火墻策略阻攔，即使在一個內(nèi)部網(wǎng)絡中，也需要架設 DNS服務器進行主機名解析。DNS是一個全球分布的數(shù)據(jù)庫，域名遞歸解析需要本地 DNS服務器與互聯(lián)網(wǎng)上其他服務器通信，這也就為基于 DNS協(xié)議構建隱蔽通道創(chuàng)造了條件。通過域名遞歸解析的 DNS隱蔽通道客戶端只需請求本地 DNS服務器，而不必與通道的另一方直接通信，大大增加了訪問控制策略制定的難度。

過去幾年的研究已提出多種 DNS隱蔽通信方法，且有成熟的軟件實現(xiàn)，應用于 IP或 TCP隧道、木馬和僵尸網(wǎng)絡的控制通信。建設無線城市部署的 Wi-Fi熱點，用戶認證前通常已開放DNS服務，利用 DNS隧道可繞過認證自由訪問互聯(lián)網(wǎng)，對網(wǎng)絡運營商造成損失。而在信息安全要求較高的組織，隱蔽通道則可能造成機密信息泄露等嚴重的安全事件。文獻[1]提出了利用DNS傳輸文件和封裝SSH隧道的方法。文獻[2～4]對現(xiàn)有的DNS隧道實現(xiàn)在帶寬、延遲和可靠性上進行了比較，實驗在低延遲網(wǎng)絡中達到了500kbit/s的吞吐量。文獻[5]利用二進制編碼域名進一步提高隧道帶寬，文獻[6]通過 DNS數(shù)據(jù)分組松弛空間數(shù)據(jù)注入，實現(xiàn)對DNS解析器和安全工具透明的被動DNS隧道。

相對于層出不窮的 DNS隱蔽通道傳輸和隱藏手段，相應的檢測技術仍存在諸多不足。目前，對應用層隱蔽通道檢測的研究大多針對HTTP和SSH協(xié)議[7,8]，檢測DNS隱蔽通道的方法只有如下幾類。

1) 請求量、長子域名統(tǒng)計。DNSBL（DNS黑名單）等頻繁請求同一域中大量子域名的情況在實際環(huán)境中較為常見，這一方法易產(chǎn)生誤報，同時又忽略低頻率、低帶寬的隱蔽通道。文獻[5]提出偽造源地址分散通道的方法，也能繞過這一檢測機制，適合構建泄密和遠程控制類的非對稱通道。

2) 特殊資源記錄類型統(tǒng)計。該方法檢測 DNS隱蔽通道常用的TXT和NULL資源記錄，Iodine[9]等使用A記錄請求即會使此方法失效。

3) Born等人提出的域名字符頻率分析[10,11]。該檢測方法同樣存在對DNSBL等服務的誤判，因為DNSBL的子域名一般為IP地址或MD5散列值，不符合英語單詞的字符頻率特性。文獻[10, 11]實驗中合法流量產(chǎn)自Alexa排名前百萬網(wǎng)站的爬蟲，僅代表Web服務的域名特征，與實際DNS流量特性差異較大。此外，字符頻率分析未考慮文獻[5]在域名中包含二進制數(shù)據(jù)的隱蔽通道。

上述 DNS隱蔽通道檢測方法均只適用于基于域名遞歸解析的通道，而尚未解決隱藏在 UDP/53流量中客戶端與服務器直接通信的通道，如文獻[6]的數(shù)據(jù)注入、Iodine的Raw UDP隧道[9]等。如何設計一種適合各種類型 DNS隱蔽通道檢測要求、不依賴于特定的通道設計模式假定的 DNS隱蔽通道檢測方法，成為亟待解決的問題。

本文提出了一種在 DNS流量中全面檢測各種類型 DNS隱蔽通道的方法，利用機器學習的分類器對合法請求和隱蔽通信特征進行判別。本文的貢獻如下。

1) 對DNS隱蔽通道的構建方法進行了總結(jié)，全面分析了 DNS隱蔽通信流量的數(shù)據(jù)分組特征及會話連接的統(tǒng)計特性。

2) 實驗驗證了本文的算法能夠識別訓練涉及的全部 22種隱蔽通道，并且具有識別未經(jīng)訓練的新型 DNS隱蔽通道的能力，解決了現(xiàn)有檢測算法在可檢測的通道類型上的局限性。

3) 本文的算法可應用于實時DNS流量分析，并且實現(xiàn)了相應的檢測系統(tǒng)，在上海交通大學校園網(wǎng)進行了部署測試，檢測到多個實際存在的隱蔽通道并進行了分析。

2 DNS隱蔽通道

DNS協(xié)議的隱蔽通道可分為2類：第一類利用 DNS的遞歸域名解析，在本文中稱為基于域名的隱蔽通道；另一類需要客戶端與隱蔽通道服務器直接通信，在本文中稱為基于服務器的隱蔽通道。

2.1 基于域名的DNS隱蔽通道

攻擊者注冊一個域名，并將其域名服務器（NS）設置為隱蔽通道的服務器。隱蔽通道客戶端向任意一臺 DNS遞歸服務器請求該域下子域名，均可實現(xiàn)與服務器通信。

客戶端向服務器發(fā)送的數(shù)據(jù)編碼為域名的子域名字符串。DNS域名標簽允許包含英文字母、數(shù)字和連字符，且不區(qū)分大小寫，因此，DNS隱蔽通道通常將數(shù)據(jù)進行Base32編碼。服務器返回的數(shù)據(jù)則包含在DNS回答的資源記錄中，其中最常用的資源記錄類型是NULL和TXT，前者可包含任意長的二進制數(shù)據(jù)，后者則要求為可打印字符。A記錄（IPv4地址）、MX記錄（郵件交換）和AAAA記錄（IPv6地址）的請求在互聯(lián)網(wǎng)DNS流量中所占比例最大，盡管帶寬利用率低于NULL/TXT，但它們?nèi)詾樽⒅仉[蔽性的DNS隧道的首選。

基于域名的DNS隱蔽通道程序?qū)崿F(xiàn)，有IP over DNS 隧道：NSTX[12]、Iodine[9]、DNSCat[13]以及 TCP over DNS 隧 道 ： OzyManDNS[1]、 Dns2tcp[14]、TCP-over-DNS[15]和 Heyoka[5]等。

2.2 基于服務器的DNS隱蔽通道

當網(wǎng)絡安全策略允許主機與任意一臺 DNS服務器通信時，可使用基于服務器的DNS隱蔽通道。攻擊者將基于UDP的服務（如OpenVPN）運行在53端口，從客戶端直接建立連接。Iodine發(fā)現(xiàn)客戶端能與隧道域名 NS直接通信時，也會自動轉(zhuǎn)入Raw UDP模式。在此模式下，整個UDP載荷均為隱蔽通道數(shù)據(jù)，通信效率大幅提升。然而，由于這些報文不是有效的 DNS消息，流量分析工具解析這些報文時會出現(xiàn)格式異常（malformed），從而引起懷疑。文獻[6]在現(xiàn)有 DNS消息末尾的松弛空間注入數(shù)據(jù)的方法，不影響 DNS服務器和流量分析工具對數(shù)據(jù)分組的解析，可解決上述Raw UDP隧道的缺陷。

3 檢測方法

3.1 定義DNS數(shù)據(jù)連接

為了判斷各個客戶端的域名請求行為是否存在隱蔽通信的可能，本文對 DNS流量中的“數(shù)據(jù)連接”進行定義，以確定各個消息的通信雙方。

對截獲的UDP/53數(shù)據(jù)分組作DNS協(xié)議解析，如果解析中無任何錯誤發(fā)生，并且解析完畢時指針位于 UDP載荷的末尾，表明該數(shù)據(jù)分組是一個無注入的合法DNS報文。本文將這類數(shù)據(jù)分組的DNS連接雙方定義為。client_ip為DNS客戶端地址，即DNS查詢報文的源，或回答報文的目的IP地址。pure_domain為DNS請求域名（QNAME）的純域名部分，即將QNAME去除由同一NS授權的子域名標簽。

如果將數(shù)據(jù)分組解析為 DNS時發(fā)生錯誤，或者解析完畢后指針未處于 UDP載荷末尾，表明該數(shù)據(jù)分組可能為Raw UDP隧道，或存在松弛空間數(shù)據(jù)注入。這類數(shù)據(jù)分組的通信雙方直接取其 IP地址，網(wǎng)絡邊界監(jiān)控時認為內(nèi)網(wǎng)主機地址為client_ip。

3.2 數(shù)據(jù)分組特征

通過對DNS隱蔽通道構造方法和流量的分析，本文從 DNS數(shù)據(jù)分組中提取了一系列可用于區(qū)別DNS隱蔽通道的特征。

3.2.1 數(shù)據(jù)分組解析特征

如3.1節(jié)所述，對采集的數(shù)據(jù)分組進行DNS協(xié)議解析時若出現(xiàn)格式異?；蛴凶⑷霐?shù)據(jù)，則可能為基于服務器的 DNS隱蔽通道。對于數(shù)據(jù)注入的情況，本文計算注入數(shù)據(jù)長度，即協(xié)議解析完畢時指針與 UDP載荷末尾的距離，作為表示松弛空間注入量的特征參數(shù)。

DNS隱蔽通道在數(shù)據(jù)傳輸時，充分利用 DNS協(xié)議各字段或Raw UDP報文允許的最大長度，以提高帶寬利用率、減少數(shù)據(jù)分組數(shù)量。基于域名的通道，其上行和下行數(shù)據(jù)分別存儲在 DNS消息的問題段和回答段，增加了 DNS消息本身的長度?；诜掌鞯乃淼?，由于無法將其作為 DNS報文解析，本文將 UDP載荷長度也作為數(shù)據(jù)分組解析特征之一。

3.2.2 請求域名特征

請求域名特征針對基于域名的隱蔽通道。DNS問題段除 QNAME以外的字段只能容納4byte數(shù)據(jù)，因此，基于域名的通道上行數(shù)據(jù)通常只能存儲在QNAME中，提取QNAME的特征：標簽數(shù)量和子域名長度。DNS協(xié)議限制域名最長為255byte，每個標簽不超過63byte，因此，DNS隱蔽通道將上行數(shù)據(jù)編碼為長域名之后，必須分割為多個標簽。

文獻[5]在域名中使用二進制數(shù)據(jù)以提高傳輸效率，也是QNAME的特征之一。實驗發(fā)現(xiàn)大多數(shù)DNS隱蔽通道使用了DNS協(xié)議允許的字符集以外的字符。對于使用二進制編碼的子域名，請求中所包含的信息量與子域名長度相等；僅使用 DNS協(xié)議允許的字符，則必須Base32編碼，QNAME包含的信息量等于子域名長度的60%。

3.2.3 DNS消息特征

編碼域名中使用前向指針是文獻[6]提出的提高數(shù)據(jù)注入檢測難度的手段，前向指針在一般的DNS解析器和服務器實現(xiàn)中幾乎不會被采用，因而是否存在前向指針是識別隱蔽通道的特征之一。隱蔽性較高的隧道的A記錄請求，一般采用CNAME（規(guī)范名稱）記錄來攜帶較多的下行數(shù)據(jù)，本文將回答含CNAME記錄作為第二個DNS消息特征。

基于域名的隱蔽通道，下行數(shù)據(jù)存儲在資源記錄中，尤其是回答段的資源記錄中，因此，本文計算回答段資源記錄數(shù)據(jù)長度（RDLENGTH）之和，以及整個報文包括授權和附加段在內(nèi)全部資源記錄RDLENGTH之和，作為表示DNS回答所容納的隧道下行數(shù)據(jù)量的2個參數(shù)。

3.2.4 特征總結(jié)

通過對數(shù)據(jù)分組3類特征的分析，總共提取了12個數(shù)據(jù)分組特征用于區(qū)別合法DNS請求與隱蔽通信，總結(jié)如表1所示。

表1 數(shù)據(jù)分組特征

3.3 DNS數(shù)據(jù)連接特征

僅依據(jù)一個數(shù)據(jù)分組的特征難以判斷是否為DNS隱蔽通信，因此，算法對屬于同一數(shù)據(jù)連接的數(shù)據(jù)分組特征進行統(tǒng)計分析，再依據(jù)數(shù)據(jù)連接的統(tǒng)計特性進行分類器判別。

如表2所示，DNS數(shù)據(jù)連接的統(tǒng)計特征分為3類：特征集FS1包含一定時間段內(nèi)該連接傳入和傳出的數(shù)據(jù)分組總數(shù)；FS2統(tǒng)計了該連接中具有前向指針、CNAME記錄，以及QNAME含二進制數(shù)據(jù)的特殊報文數(shù)量；特征集FS3是對數(shù)據(jù)分組特征F2、F3、F4、F5、F6、F8、F11、F12的統(tǒng)計，計算該連接所有數(shù)據(jù)分組上述參數(shù)的均值、最大值、最小值及求和。其中，數(shù)據(jù)分組長度特征（F2,F3,F4）對傳出和傳入2個方向分別統(tǒng)計；請求域名特征（F5,F6,F8）只對 DNS請求報文統(tǒng)計，因為回答報文與請求中的QNAME保持完全一致；資源記錄特征F11和F12僅在DNS回答報文中有意義，因此僅對回答進行統(tǒng)計。

表2 DNS數(shù)據(jù)連接特征集

特征集FS3共含42個特征，主要代表了DNS請求與應答報文、域名、資源記錄的平均長度和變化范圍，以及雙向的數(shù)據(jù)傳輸量。利用合法 DNS流量樣本及DNS隧道流量樣本對FS3中特征分布進行分析，其中隧道流量樣本含50%的活躍傳輸?shù)乃淼兰?0%空閑、保持連接狀態(tài)的隧道。如圖1(a)所示，DNS隱蔽通道對外傳輸數(shù)據(jù)時，最長的子域名往往在25個字符以上，而合法域名請求中僅2%的子域名超過25個字符；但是，DNS隧道在空閑狀態(tài)下的子域名通常小于10byte，與合法請求相似。圖1(b)顯示了DNS會話在5min內(nèi)回答數(shù)據(jù)總字節(jié)數(shù)分布，98.4%的合法DNS通信在5min內(nèi)的回答數(shù)據(jù)小于20KB，而DNS隱蔽通道活躍時5min的下行數(shù)據(jù)通常在50KB以上。

圖1 DNS數(shù)據(jù)連接統(tǒng)計特征分布

3.4 檢測系統(tǒng)流程

本文提出的DNS隱蔽通道檢測流程如圖2所示。DNS流量探針監(jiān)測所有的UDP/53流量。對于DNS探針采集到的數(shù)據(jù)分組，計算其12個數(shù)據(jù)分組特征參數(shù)，并進行初步數(shù)據(jù)分組過濾，去除明顯不符合隱蔽通道特征的DNS報文。

圖2 DNS隱蔽通道檢測流程

研究了 DNS隱蔽通信的必備要素之后，本文確定了如下的初步過濾規(guī)則

符合該條件，即無格式異常、無數(shù)據(jù)注入、子域名長度不超過 4字符且回答資源記錄總長不超過1byte的，將被數(shù)據(jù)分組過濾模塊丟棄。對余下的數(shù)據(jù)分組，根據(jù)3.1節(jié)的定義，識別其所屬DNS數(shù)據(jù)連接的通信雙方，然后將該數(shù)據(jù)分組特征更新至DNS連接特征統(tǒng)計表，以計算 3.3節(jié)提出的 DNS數(shù)據(jù)連接統(tǒng)計特征。

一個DNS數(shù)據(jù)連接在DNS連接特征統(tǒng)計表中跟蹤監(jiān)測的時間達到統(tǒng)計時限T后，進入判別為合法或隱蔽通信的流程。如果其數(shù)據(jù)分組速率達到Rm，則將DNS數(shù)據(jù)連接特征集FS1、FS2和FS3的全部特征輸入一個機器學習的分類器，應用預先訓練好的分類模型，判斷是否為 DNS 隱蔽通道。對數(shù)據(jù)分組速率低于Rm的連接，認為其請求頻率對隱蔽通信而言過小，直接判定為合法的DNS請求。

系統(tǒng)參數(shù)T決定了隱蔽通信開始到系統(tǒng)響應的最大延遲，提高T的取值可增強對低速通道的數(shù)據(jù)分組采集，但將延長響應時間。Rm取決于安全策略所能容忍的最大隱蔽通道帶寬。單個DNS請求攜帶的最大上行數(shù)據(jù)DUM小于QNAME長度，即DUM＜ 2 55。DNS請求與應答分組成對出現(xiàn)，分析隱蔽信道的泄密風險時，上行帶寬。本文實驗及系統(tǒng)原型實現(xiàn)采用參數(shù)T= 5 min 及Rm=4byte/min，考慮到BU＜ 5 12byte/min對泄密與遠程控制等應用均太小，而 5min的監(jiān)測足夠?qū)Φ退俾释ǖ啦杉辽?0次請求用于統(tǒng)計分析。實驗將比較幾種常用的分類器模型在本算法中應用時的分類效果。

4 實驗與評估

4.1 訓練數(shù)據(jù)采集

對 DNS數(shù)據(jù)連接分類器進行訓練和評估，需采集一系列合法DNS流量樣本，以及DNS隱蔽通道的流量樣本。實驗使用的合法流量樣本取自上海交通大學校園網(wǎng)的DNS流量，在1h的流量截取文件中，提取單一客戶端對同一純域名請求次數(shù)最多的 6 890個 DNS數(shù)據(jù)連接，并確認了其均不屬于DNS隱蔽通信。

為了獲得 DNS隱蔽通道樣本，實驗運行了多個現(xiàn)有的 DNS隧道軟件，截取其產(chǎn)生的流量。測試的DNS隧道程序包括Iodine、Dns2tcp、DNSCat、tcp-over-dns和 PSUDP。對于支持多種資源記錄類型的Iodine、Dns2tcp和DNSCat，分別截取了其在NULL、TXT、SRV、MX、CNAME、KEY等資源記錄，以及Raw UDP模式下的流量。

為使訓練產(chǎn)生的模型既能識別數(shù)據(jù)傳輸中的大吞吐量隱蔽通道，又可檢測低頻交互、小流量的通道，對上述DNS隧道軟件的實驗中，分別截取其活動狀態(tài)（有數(shù)據(jù)通過隧道傳輸）和空閑狀態(tài)（隧道保持連接）時的流量。隧道傳輸?shù)臄?shù)據(jù)采用 Web瀏覽器自動加載網(wǎng)頁的方法產(chǎn)生。PSUDP采用在已有DNS流量中注入數(shù)據(jù)的被動工作方式，自身不產(chǎn)生DNS請求，因此，PSUDP的實驗，以1次/秒的頻率發(fā)送DNS請求，使PSUDP能夠進行數(shù)據(jù)傳輸。

上述DNS隧道程序的實驗總共涵蓋22種隱蔽通信模式。實驗對每種模式分別截取6個時間段，產(chǎn)生總共132個DNS隱蔽通道流量樣本（如表3所示）。

表3 訓練樣本集

4.2 分類器模型比較

本文使用 Weka[16]軟件，對 J48決策樹、樸素貝葉斯（Na?ve Bayes）和邏輯回歸（LR, logistic regression）算法進行比較，分類器模型采用十折交叉驗證進行測試。

分類器模型比較結(jié)果如表4所示，J48決策樹和LR算法的模型正檢率（true positive rate）相同，均為95.6%。樸素貝葉斯算法的準確率明顯較低J48和LR算法，因此不適用于本文研究的場景。LR算法的誤報率（false positive rate）低于決策樹算法，而決策樹算法ROC曲線（如圖3所示）區(qū)域面積（AUC）最大，即其平均性能最優(yōu)。

J48決策樹算法在實驗比較中取得了較為準確的分類結(jié)果，并且該算法效率高，輸出的模型直觀明了。J48算法采用自頂向下、分而治之的的決策樹構造方法，選擇信息增益率最大的屬性進行分裂，遞歸直至決策樹各節(jié)點樣本均為相同類別或無屬性可分裂。決策樹構造過程中對分類信息增益最大的屬性進行了選擇，模型實際使用的特征數(shù)量較少，在實時流量處理時可降低資源開銷。因此，在后續(xù)的實驗及實時流量檢測系統(tǒng)的實現(xiàn)中，采用了J48決策樹作為機器學習的分類器算法。

表4 分類器模型比較

圖3 分類模型ROC曲線

4.3 特征評估

在不同的特征選取的情況下，分別建立分類器模型進行比較，采用全樣本集和十折交叉驗證評估，各個模型的誤報率均在0.15%至0.30%的范圍內(nèi)，因此著重比較其漏檢率（false negative rate）。由于FS3包含的特征數(shù)量眾多，進一步將FS3分為報文解析特征統(tǒng)計（FS3PP）、請求域名特征統(tǒng)計（FS3DN）和資源記錄特征統(tǒng)計（FS3RR）3部分進行了評估，不同特征選取時模型漏檢率如圖4所示。結(jié)果表明FS3和全部特征集（ALL）均取得了較低的漏檢率，而FS1和FS2的漏檢率較高。

圖4 各類特征集下的漏檢率

與本文算法相比，傳統(tǒng)的基于高請求頻率判斷DNS隱蔽通道的方法，僅僅依賴于統(tǒng)計同一客戶端對同一純域名的請求量，即僅使用本文算法的特征集FS1中的特征，而缺乏應用層深入分析產(chǎn)生的特征集FS2和FS3。圖5對比了合法請求與隱蔽通道樣本的報文數(shù)量分布，DNS隧道程序在保持連接和低速率傳輸時的請求頻率與合法應用難以區(qū)分，34.5%的隧道樣本5min報文數(shù)小于150，而有17.2%的合法樣本報文數(shù)超過該值。根據(jù)此參數(shù)設定閾值，為使誤報率保持在合理范圍內(nèi)，將不可避免地忽略低帶寬的隱蔽通信。因此，特征評估實驗利用FS1特征集建立決策樹模型的漏檢率達30%左右。

圖5 同域名查詢頻率分布

特征集FS2分析含前向指針、CNAME記錄和二進制域名的流量異常，符合標準規(guī)范實現(xiàn)的DNS隱蔽通道避免產(chǎn)生上述特殊報文，因此，僅依據(jù)特征集FS2能夠檢測的隱蔽通道類型較少，在特征評估實驗中的漏檢率高達50%以上。

特征集FS3對協(xié)議報文尺寸、QNAME特征和資源記錄特征的統(tǒng)計特性分析能夠準確區(qū)分合法與隱蔽通道。如圖 4所示，根據(jù)交叉驗證評價，F(xiàn)S3PP、FS3DN和FS3RR分別建立模型的漏檢率為7.1%、4.4%和 12.4%。3.3節(jié)提取的全部特征中，對J48算法分類信息增益率最大的特征為 max(F8)，即 QNAME所攜帶的最大信息量，因而其所屬的FS3DN分類準確率高于FS3PP與FS3RR。特征集FS1對報文數(shù)量的計數(shù)np與FS3PP協(xié)議報文尺寸求和∑Li在報文尺寸Li一定的前提下呈正相關性；FS2檢測的 CNAME和二進制域名特殊報文，則在FS3RR的回答資源記錄尺寸及FS3DN的 QNAME信息量中對應地進行了計算。從而，F(xiàn)S3部分攜帶了FS1與FS2特征所含的信息，依據(jù)FS3建立的決策樹模型取得了與全特征集相同的準確率。

4.4 未知隱蔽通道模式檢測

為驗證決策樹模型的檢測能力，對訓練使用的隱蔽通道模式重新截取新的流量，測試結(jié)果表明該模型能檢出全部22種已知的DNS隱蔽通道。進一步地，本文實驗檢驗模型對訓練未涉及的“未知”DNS隱蔽通道的檢測能力。實驗另外測試了 3個DNS隧道程序，分別為OzyManDNS、Heyoka，以及作者自行設計的DNS隱蔽通道NSChan。NSChan使用 Base32域名編碼，下行數(shù)據(jù)采用了與其他隧道均不同的設計，將數(shù)據(jù)編碼為多個IPv4地址，通過A記錄返回。對于上述3個未經(jīng)訓練的DNS通道程序，檢測結(jié)果如表5所示。

模型成功檢測活動和空閑狀態(tài)的 OzyManDNS與Heyoka，以及活動狀態(tài)下的NSChan。模型未能檢測空閑狀態(tài)的 NSChan，對其流量分析后發(fā)現(xiàn)，兩方面因素導致了漏檢的產(chǎn)生。首先，NSChan在空閑、保持連接狀態(tài)下的請求頻率fidle= 0 .2，低于訓練使用的 Iodine的fidle= 0 .33，以及 DNSCat、Dns2tcp和tcp-over-dns的1.0、2.0和6.0，從而，其 5min對外報文數(shù)no=Tfidle= 6 0恰好低于決策樹模型在該參數(shù)的閾值68，被判為合法。其次，本文作者實現(xiàn)NSChan時，對封裝報文頭部長度未作優(yōu)化，空閑時子域名長度與其他隧道活躍時相當，使決策樹在請求報文最小長度節(jié)點處進入了適用于活躍隧道的分支。盡管如此，NSChan在數(shù)據(jù)傳輸時，不可避免地出現(xiàn)頻率提高及域名長度增加的隱蔽通信特征，活動狀態(tài)依然無法躲避本算法檢測。作為改進方案，模型訓練時可添加將隧道程序fidle參數(shù)減小后采集的樣本，截取報文量接近系統(tǒng)參數(shù)Rm（如3.4節(jié)）的流量，以增強模型對請求頻率低至下界fm= 2/Rm的隧道的檢測。

表5 檢測訓練集以外的DNS隱蔽通道

4.5 實際環(huán)境評估

本文對 DNS隱蔽通道檢測算法進行了實現(xiàn)，處理實時的 DNS流量發(fā)現(xiàn)其中的隱蔽通信行為。將檢測系統(tǒng)在上海交通大學網(wǎng)絡中心的 DNS流量監(jiān)控服務器上進行了部署，檢驗算法在實際環(huán)境中的效果。系統(tǒng)監(jiān)測的DNS請求來自約30萬個源IP地址，DNS請求量約3 000次/秒。

流量經(jīng)數(shù)據(jù)分組過濾后，DNS數(shù)據(jù)連接統(tǒng)計表中暫存的記錄為11萬條，內(nèi)存使用最大50MB。經(jīng)過持續(xù)10h的運行和檢測，實際環(huán)境測試結(jié)果如表6所示。系統(tǒng)共產(chǎn)生了30萬個樣本進入分類器，其中310個被檢出的樣本確認屬于隱蔽通信，系統(tǒng)總共檢測到7個獨立的隱蔽通道的存在。

表6 實際環(huán)境測試結(jié)果

圖6 CipherTrust DNS隧道流量分析

在誤報方面，分類器對樣本的誤報率為0.107%，10h內(nèi)誤報的客戶端IP地址為38個，誤報的域名僅23個。DNS流量進入分類器前，經(jīng)過了初步數(shù)據(jù)分組過濾、DNS數(shù)據(jù)連接過濾2個過濾器，前者濾除了27.5%的合法DNS報文，后者則將約91%的DNS會話直接判為合法而無需經(jīng)過分類器判別。2個過濾器使得最終進入分類器判決的會話數(shù)與系統(tǒng)輸入的DNS流量相比大幅減少，因此，系統(tǒng)對全部流量的誤報率遠低于表6中分類器模塊的誤報率。

對檢測系統(tǒng)的誤報分析發(fā)現(xiàn)，系統(tǒng)的誤報主要來自于異常的客戶端程序?qū)崿F(xiàn)，如29%的誤報產(chǎn)生自某主機以5s為周期對a.root-servers.net的重復請求，由于該請求產(chǎn)生的回答含大量授權和附加段資源記錄，被認為是隧道下行流量。對于DNSBL服務，模型訓練中已學習的以MD5或IP地址為前綴的DNSBL在實際環(huán)境部署時沒有任何誤報，但在實際流量中誤檢了2個以URL Encoding編碼的網(wǎng)址為前綴的 DNSBL域名：ph.bdaph.com和html.ph.bdrbl.com。這 2個域名由 BitDefender（比特梵德，反病毒軟件公司）注冊，網(wǎng)址經(jīng)過 URL編碼，再用減號替代百分號后作為子域名字串（如表7所示）。該DNSBL子域名長度比MD5和IP地址大得多，因而被本系統(tǒng)誤檢。

表7 URL編碼的DNSBL示例

在對本系統(tǒng)檢測到的DNS隱蔽通道的分析中，也發(fā)現(xiàn)了 DNS隧道在一些合法軟件中的應用。McAfee（麥克菲）的軟件利用DNS隧道技術將用戶電子郵件的部分信息傳送到服務器，用于其聲望評分系統(tǒng)。其 DNS隧道利用域名 ciphertrust.net，抓包分析顯示其DNS請求符合典型的DNS隱蔽通信模式（如圖6所示）。

5 結(jié)束語

本文通過對 DNS隱蔽通道構建方法的研究和總結(jié)，提出了基于機器學習的檢測算法，能夠全面檢測利用域名遞歸解析和服務器直接通信的多種DNS隱蔽通道模型，解決了現(xiàn)有算法在通道類型上的局限性。經(jīng)過實驗比較，本文選擇利用J48決策樹分類器對 DNS數(shù)據(jù)連接的特征進行判別。分類器模型可檢測訓練涉及的全部22種隱蔽通道模式，以及多種未經(jīng)訓練的新型隱蔽通道。本文實現(xiàn)了在實時 DNS流量中檢測隱蔽通道的系統(tǒng)，在校園網(wǎng)環(huán)境中進行了部署測試，成功檢測到7個隱蔽通道的存在，并探討了實際運行中發(fā)現(xiàn)的一些特殊的DNS隧道的應用。

[1] KAMINSKY D.The black OPS of DNS[A].Proceedings of the Black Hat USA 2004[C].Las Vegas, 2004.

[2] LEIJENHORST T V, CHIN K-W, LOWE D.On the viability and performance of DNS tunneling[A].Proceedings of the 5th International Conference on Information Technology and Applications[C].Cairns,Australia, 2008.

[3] NUSSBAUM L, NEYRON P, RICHARD O.On robust covert channels inside DNS[A].Proceedings of the 24th IFIP International Security Conference[C].Pafos, Cyprus, 2009.

[4] MERLO A, PAPALEO G, VENEZIANO S,et al.A comparative performance evaluation of DNS tunneling tools[A].Proceedings of the 5th International Conference on Complex, Intelligent, and Software Intensive Systems[C].Seoul, Korea, 2011.84-91.

[5] REVELLI A, LEIDECKER N.Introducing heyoka: DNS tunneling 2.0[A].Proceedings of the SOURCE Conference Boston[C].Boston,2009.

[6] BORN K.PSUDP: a passive approach to network-wide covert communication[A].Proceedings of the Black Hat USA 2010[C].Las Vegas, 2010.

[7] ZANDER S, ARMITAGE G, BRANCH P.A survey of covert channels and countermeasures in computer network protocols[J].Communications Surveys & Tutorials, IEEE, 2007, 9 (3): 44-57.

[8] DUSI M, CROTTI M, GRINGOLI F,et al.Tunnel hunter: detecting application-layer tunnels with statistical fingerprinting[J].Computer Networks, 2009, 53 (1): 81-97.

[9] ANDERSSON B, EKMAN E.Iodine[EB/OL].http://code.kryo.se/iodine/, 2011.

[10] BORN K, GUSTAFSON D.NgViz: detecting DNS tunnels through N-gram visualization and quantitative analysis[A].Proceedings of the Sixth Annual Workshop on Cyber Security and Information Intelligence Research[C].Oak Ridge, Tennessee, 2010.1-4.

[11] BORN K, GUSTAFSON D.Detecting DNS tunnels using character frequency analysis[A].Proceedings of the 9th Annual Security Conference[C].Las Vegas, Nevada, 2010.

[12] GIL T M.NSTX (IP-over-DNS)[EB/OL].http://thomer.com/ howtos/nstx.html.

[13] PIETRASZEK T.DNScat[EB/OL].http://tadek.pietraszek.org/ projects/DNScat/, 2011.

[14] DEMBOUR O.Dns2tcp[EB/OL].http://www.hsc.fr/ressources/ outils/dns2tcp/index.html.en, 2011.

[15] VALENZUELA T.Tcp-over-dns[EB/OL].http://analogbit.com/ software/tcp-over-dns, 2011.

[16] HALL M, FRANK E, HOLMES G,et al.The WEKA data mining software: an update[J].SIGKDD Explorations, 2009, 11 (1): 10-18.