基于DNS的隱蔽通道流量檢測

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

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

1 引言

網絡隱蔽通道是攻擊者繞過網絡安全策略進行數據傳輸的重要途徑，而DNS（域名系統）則是實現應用層隱蔽通道的常用手段。

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

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

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

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

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

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

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

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

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

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

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

2 DNS隱蔽通道

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

2.1 基于域名的DNS隱蔽通道

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

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

基于域名的DNS隱蔽通道程序實現，有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隱蔽通道

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

3 檢測方法

3.1 定義DNS數據連接

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

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

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

3.2 數據分組特征

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

3.2.1 數據分組解析特征

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

DNS隱蔽通道在數據傳輸時，充分利用 DNS協議各字段或Raw UDP報文允許的最大長度，以提高帶寬利用率、減少數據分組數量?；谟蛎耐ǖ溃渖闲泻拖滦袛祿謩e存儲在 DNS消息的問題段和回答段，增加了 DNS消息本身的長度?；诜掌鞯乃淼溃捎跓o法將其作為 DNS報文解析，本文將 UDP載荷長度也作為數據分組解析特征之一。

3.2.2 請求域名特征

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

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

3.2.3 DNS消息特征

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

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

3.2.4 特征總結

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

表1 數據分組特征

3.3 DNS數據連接特征

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

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

表2 DNS數據連接特征集

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

圖1 DNS數據連接統計特征分布

3.4 檢測系統流程

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

圖2 DNS隱蔽通道檢測流程

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

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

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

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

4 實驗與評估

4.1 訓練數據采集

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

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

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

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

表3 訓練樣本集

4.2 分類器模型比較

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

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

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

表4 分類器模型比較

圖3 分類模型ROC曲線

4.3 特征評估

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

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

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

圖5 同域名查詢頻率分布

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

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

4.4 未知隱蔽通道模式檢測

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

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

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

4.5 實際環境評估

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

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

表6 實際環境測試結果

圖6 CipherTrust DNS隧道流量分析

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

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

表7 URL編碼的DNSBL示例

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

5 結束語

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