基于DNS的隱蔽通道流量檢測(cè)

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

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

1 引言

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

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

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

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

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

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

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

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

本文提出了一種在 DNS流量中全面檢測(cè)各種類型 DNS隱蔽通道的方法，利用機(jī)器學(xué)習(xí)的分類器對(duì)合法請(qǐng)求和隱蔽通信特征進(jìn)行判別。本文的貢獻(xiàn)如下。

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

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

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

2 DNS隱蔽通道

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

2.1 基于域名的DNS隱蔽通道

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

客戶端向服務(wù)器發(fā)送的數(shù)據(jù)編碼為域名的子域名字符串。DNS域名標(biāo)簽允許包含英文字母、數(shù)字和連字符，且不區(qū)分大小寫，因此，DNS隱蔽通道通常將數(shù)據(jù)進(jìn)行Base32編碼。服務(wù)器返回的數(shù)據(jù)則包含在DNS回答的資源記錄中，其中最常用的資源記錄類型是NULL和TXT，前者可包含任意長的二進(jìn)制數(shù)據(jù)，后者則要求為可打印字符。A記錄（IPv4地址）、MX記錄（郵件交換）和AAAA記錄（IPv6地址）的請(qǐng)求在互聯(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 基于服務(wù)器的DNS隱蔽通道

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

3 檢測(cè)方法

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

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

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

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

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

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

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

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

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

3.2.2 請(qǐng)求域名特征

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

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

3.2.3 DNS消息特征

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

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

3.2.4 特征總結(jié)

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

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

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

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

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

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

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

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

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

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

圖2 DNS隱蔽通道檢測(cè)流程

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

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

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

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

4 實(shí)驗(yàn)與評(píng)估

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

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

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

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

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

表3 訓(xùn)練樣本集

4.2 分類器模型比較

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

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

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

表4 分類器模型比較

圖3 分類模型ROC曲線

4.3 特征評(píng)估

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

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

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

圖5 同域名查詢頻率分布

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

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

4.4 未知隱蔽通道模式檢測(cè)

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

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

表5 檢測(cè)訓(xùn)練集以外的DNS隱蔽通道

4.5 實(shí)際環(huán)境評(píng)估

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

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

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

圖6 CipherTrust DNS隧道流量分析

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

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

表7 URL編碼的DNSBL示例

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

5 結(jié)束語

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

[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.