章思宇,鄒福泰,王魯華,陳銘
(1.上海交通大學(xué) 信息安全工程學(xué)院,上海 200240;2.國家計算機(jī)網(wǎng)絡(luò)與信息安全管理中心,北京 100017;3.上海交通大學(xué) 密西根學(xué)院,上海 200240)
網(wǎng)絡(luò)隱蔽通道是攻擊者繞過網(wǎng)絡(luò)安全策略進(jìn)行數(shù)據(jù)傳輸?shù)闹匾緩?,而DNS(域名系統(tǒng))則是實(shí)現(xiàn)應(yīng)用層隱蔽通道的常用手段。
DNS是互聯(lián)網(wǎng)最為關(guān)鍵的基礎(chǔ)設(shè)施之一,將域名與IP地址相互映射。由于其在網(wǎng)絡(luò)運(yùn)行中的重要地位,DNS協(xié)議幾乎不會被防火墻策略阻攔,即使在一個內(nèi)部網(wǎng)絡(luò)中,也需要架設(shè) DNS服務(wù)器進(jìn)行主機(jī)名解析。DNS是一個全球分布的數(shù)據(jù)庫,域名遞歸解析需要本地 DNS服務(wù)器與互聯(lián)網(wǎng)上其他服務(wù)器通信,這也就為基于 DNS協(xié)議構(gòu)建隱蔽通道創(chuàng)造了條件。通過域名遞歸解析的 DNS隱蔽通道客戶端只需請求本地 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),對網(wǎng)絡(luò)運(yùn)營商造成損失。而在信息安全要求較高的組織,隱蔽通道則可能造成機(jī)密信息泄露等嚴(yán)重的安全事件。文獻(xiàn)[1]提出了利用DNS傳輸文件和封裝SSH隧道的方法。文獻(xiàn)[2~4]對現(xiàn)有的DNS隧道實(shí)現(xiàn)在帶寬、延遲和可靠性上進(jìn)行了比較,實(shí)驗在低延遲網(wǎng)絡(luò)中達(dá)到了500kbit/s的吞吐量。文獻(xiàn)[5]利用二進(jìn)制編碼域名進(jìn)一步提高隧道帶寬,文獻(xiàn)[6]通過 DNS數(shù)據(jù)分組松弛空間數(shù)據(jù)注入,實(shí)現(xiàn)對DNS解析器和安全工具透明的被動DNS隧道。
相對于層出不窮的 DNS隱蔽通道傳輸和隱藏手段,相應(yīng)的檢測技術(shù)仍存在諸多不足。目前,對應(yīng)用層隱蔽通道檢測的研究大多針對HTTP和SSH協(xié)議[7,8],檢測DNS隱蔽通道的方法只有如下幾類。
1) 請求量、長子域名統(tǒng)計。DNSBL(DNS黑名單)等頻繁請求同一域中大量子域名的情況在實(shí)際環(huán)境中較為常見,這一方法易產(chǎn)生誤報,同時又忽略低頻率、低帶寬的隱蔽通道。文獻(xiàn)[5]提出偽造源地址分散通道的方法,也能繞過這一檢測機(jī)制,適合構(gòu)建泄密和遠(yuǎn)程控制類的非對稱通道。
2) 特殊資源記錄類型統(tǒng)計。該方法檢測 DNS隱蔽通道常用的TXT和NULL資源記錄,Iodine[9]等使用A記錄請求即會使此方法失效。
3) Born等人提出的域名字符頻率分析[10,11]。該檢測方法同樣存在對DNSBL等服務(wù)的誤判,因為DNSBL的子域名一般為IP地址或MD5散列值,不符合英語單詞的字符頻率特性。文獻(xiàn)[10, 11]實(shí)驗中合法流量產(chǎn)自Alexa排名前百萬網(wǎng)站的爬蟲,僅代表Web服務(wù)的域名特征,與實(shí)際DNS流量特性差異較大。此外,字符頻率分析未考慮文獻(xiàn)[5]在域名中包含二進(jìn)制數(shù)據(jù)的隱蔽通道。
上述 DNS隱蔽通道檢測方法均只適用于基于域名遞歸解析的通道,而尚未解決隱藏在 UDP/53流量中客戶端與服務(wù)器直接通信的通道,如文獻(xiàn)[6]的數(shù)據(jù)注入、Iodine的Raw UDP隧道[9]等。如何設(shè)計一種適合各種類型 DNS隱蔽通道檢測要求、不依賴于特定的通道設(shè)計模式假定的 DNS隱蔽通道檢測方法,成為亟待解決的問題。
本文提出了一種在 DNS流量中全面檢測各種類型 DNS隱蔽通道的方法,利用機(jī)器學(xué)習(xí)的分類器對合法請求和隱蔽通信特征進(jìn)行判別。本文的貢獻(xiàn)如下。
1) 對DNS隱蔽通道的構(gòu)建方法進(jìn)行了總結(jié),全面分析了 DNS隱蔽通信流量的數(shù)據(jù)分組特征及會話連接的統(tǒng)計特性。
2) 實(shí)驗驗證了本文的算法能夠識別訓(xùn)練涉及的全部 22種隱蔽通道,并且具有識別未經(jīng)訓(xùn)練的新型 DNS隱蔽通道的能力,解決了現(xiàn)有檢測算法在可檢測的通道類型上的局限性。
3) 本文的算法可應(yīng)用于實(shí)時DNS流量分析,并且實(shí)現(xiàn)了相應(yīng)的檢測系統(tǒng),在上海交通大學(xué)校園網(wǎng)進(jìn)行了部署測試,檢測到多個實(shí)際存在的隱蔽通道并進(jìn)行了分析。
DNS協(xié)議的隱蔽通道可分為2類:第一類利用 DNS的遞歸域名解析,在本文中稱為基于域名的隱蔽通道;另一類需要客戶端與隱蔽通道服務(wù)器直接通信,在本文中稱為基于服務(wù)器的隱蔽通道。
攻擊者注冊一個域名,并將其域名服務(wù)器(NS)設(shè)置為隱蔽通道的服務(wù)器。隱蔽通道客戶端向任意一臺 DNS遞歸服務(wù)器請求該域下子域名,均可實(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地址)的請求在互聯(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]等。
當(dāng)網(wǎng)絡(luò)安全策略允許主機(jī)與任意一臺 DNS服務(wù)器通信時,可使用基于服務(wù)器的DNS隱蔽通道。攻擊者將基于UDP的服務(wù)(如OpenVPN)運(yùn)行在53端口,從客戶端直接建立連接。Iodine發(fā)現(xiàn)客戶端能與隧道域名 NS直接通信時,也會自動轉(zhuǎn)入Raw UDP模式。在此模式下,整個UDP載荷均為隱蔽通道數(shù)據(jù),通信效率大幅提升。然而,由于這些報文不是有效的 DNS消息,流量分析工具解析這些報文時會出現(xiàn)格式異常(malformed),從而引起懷疑。文獻(xiàn)[6]在現(xiàn)有 DNS消息末尾的松弛空間注入數(shù)據(jù)的方法,不影響 DNS服務(wù)器和流量分析工具對數(shù)據(jù)分組的解析,可解決上述Raw UDP隧道的缺陷。
為了判斷各個客戶端的域名請求行為是否存在隱蔽通信的可能,本文對 DNS流量中的“數(shù)據(jù)連接”進(jìn)行定義,以確定各個消息的通信雙方。
對截獲的UDP/53數(shù)據(jù)分組作DNS協(xié)議解析,如果解析中無任何錯誤發(fā)生,并且解析完畢時指針位于 UDP載荷的末尾,表明該數(shù)據(jù)分組是一個無注入的合法DNS報文。本文將這類數(shù)據(jù)分組的DNS連接雙方定義為
如果將數(shù)據(jù)分組解析為 DNS時發(fā)生錯誤,或者解析完畢后指針未處于 UDP載荷末尾,表明該數(shù)據(jù)分組可能為Raw UDP隧道,或存在松弛空間數(shù)據(jù)注入。這類數(shù)據(jù)分組的通信雙方直接取其 IP地址
通過對DNS隱蔽通道構(gòu)造方法和流量的分析,本文從 DNS數(shù)據(jù)分組中提取了一系列可用于區(qū)別DNS隱蔽通道的特征。
3.2.1 數(shù)據(jù)分組解析特征
如3.1節(jié)所述,對采集的數(shù)據(jù)分組進(jìn)行DNS協(xié)議解析時若出現(xiàn)格式異?;蛴凶⑷霐?shù)據(jù),則可能為基于服務(wù)器的 DNS隱蔽通道。對于數(shù)據(jù)注入的情況,本文計算注入數(shù)據(jù)長度,即協(xié)議解析完畢時指針與 UDP載荷末尾的距離,作為表示松弛空間注入量的特征參數(shù)。
DNS隱蔽通道在數(shù)據(jù)傳輸時,充分利用 DNS協(xié)議各字段或Raw UDP報文允許的最大長度,以提高帶寬利用率、減少數(shù)據(jù)分組數(shù)量?;谟蛎耐ǖ溃渖闲泻拖滦袛?shù)據(jù)分別存儲在 DNS消息的問題段和回答段,增加了 DNS消息本身的長度?;诜?wù)器的隧道,由于無法將其作為 DNS報文解析,本文將 UDP載荷長度也作為數(shù)據(jù)分組解析特征之一。
3.2.2 請求域名特征
請求域名特征針對基于域名的隱蔽通道。DNS問題段除 QNAME以外的字段只能容納4byte數(shù)據(jù),因此,基于域名的通道上行數(shù)據(jù)通常只能存儲在QNAME中,提取QNAME的特征:標(biāo)簽數(shù)量和子域名長度。DNS協(xié)議限制域名最長為255byte,每個標(biāo)簽不超過63byte,因此,DNS隱蔽通道將上行數(shù)據(jù)編碼為長域名之后,必須分割為多個標(biāo)簽。
文獻(xiàn)[5]在域名中使用二進(jìn)制數(shù)據(jù)以提高傳輸效率,也是QNAME的特征之一。實(shí)驗發(fā)現(xiàn)大多數(shù)DNS隱蔽通道使用了DNS協(xié)議允許的字符集以外的字符。對于使用二進(jìn)制編碼的子域名,請求中所包含的信息量與子域名長度相等;僅使用 DNS協(xié)議允許的字符,則必須Base32編碼,QNAME包含的信息量等于子域名長度的60%。
3.2.3 DNS消息特征
編碼域名中使用前向指針是文獻(xiàn)[6]提出的提高數(shù)據(jù)注入檢測難度的手段,前向指針在一般的DNS解析器和服務(wù)器實(shí)現(xiàn)中幾乎不會被采用,因而是否存在前向指針是識別隱蔽通道的特征之一。隱蔽性較高的隧道的A記錄請求,一般采用CNAME(規(guī)范名稱)記錄來攜帶較多的下行數(shù)據(jù),本文將回答含CNAME記錄作為第二個DNS消息特征。
基于域名的隱蔽通道,下行數(shù)據(jù)存儲在資源記錄中,尤其是回答段的資源記錄中,因此,本文計算回答段資源記錄數(shù)據(jù)長度(RDLENGTH)之和,以及整個報文包括授權(quán)和附加段在內(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ù)分組特征
僅依據(jù)一個數(shù)據(jù)分組的特征難以判斷是否為DNS隱蔽通信,因此,算法對屬于同一數(shù)據(jù)連接的數(shù)據(jù)分組特征進(jìn)行統(tǒng)計分析,再依據(jù)數(shù)據(jù)連接的統(tǒng)計特性進(jìn)行分類器判別。
如表2所示,DNS數(shù)據(jù)連接的統(tǒng)計特征分為3類:特征集FS1包含一定時間段內(nèi)該連接傳入和傳出的數(shù)據(jù)分組總數(shù);FS2統(tǒng)計了該連接中具有前向指針、CNAME記錄,以及QNAME含二進(jìn)制數(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回答報文中有意義,因此僅對回答進(jìn)行統(tǒng)計。
表2 DNS數(shù)據(jù)連接特征集
特征集FS3共含42個特征,主要代表了DNS請求與應(yīng)答報文、域名、資源記錄的平均長度和變化范圍,以及雙向的數(shù)據(jù)傳輸量。利用合法 DNS流量樣本及DNS隧道流量樣本對FS3中特征分布進(jìn)行分析,其中隧道流量樣本含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)計特征分布
本文提出的DNS隱蔽通道檢測流程如圖2所示。DNS流量探針監(jiān)測所有的UDP/53流量。對于DNS探針采集到的數(shù)據(jù)分組,計算其12個數(shù)據(jù)分組特征參數(shù),并進(jìn)行初步數(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)測的時間達(dá)到統(tǒng)計時限T后,進(jìn)入判別為合法或隱蔽通信的流程。如果其數(shù)據(jù)分組速率達(dá)到Rm,則將DNS數(shù)據(jù)連接特征集FS1、FS2和FS3的全部特征輸入一個機(jī)器學(xué)習(xí)的分類器,應(yīng)用預(yù)先訓(xùn)練好的分類模型,判斷是否為 DNS 隱蔽通道。對數(shù)據(jù)分組速率低于Rm的連接,認(rèn)為其請求頻率對隱蔽通信而言過小,直接判定為合法的DNS請求。
系統(tǒng)參數(shù)T決定了隱蔽通信開始到系統(tǒng)響應(yīng)的最大延遲,提高T的取值可增強(qiáng)對低速通道的數(shù)據(jù)分組采集,但將延長響應(yīng)時間。Rm取決于安全策略所能容忍的最大隱蔽通道帶寬。單個DNS請求攜帶的最大上行數(shù)據(jù)DUM小于QNAME長度,即DUM< 2 55。DNS請求與應(yīng)答分組成對出現(xiàn),分析隱蔽信道的泄密風(fēng)險時,上行帶寬。本文實(shí)驗及系統(tǒng)原型實(shí)現(xiàn)采用參數(shù)T= 5 min 及Rm=4byte/min,考慮到BU< 5 12byte/min對泄密與遠(yuǎn)程控制等應(yīng)用均太小,而 5min的監(jiān)測足夠?qū)Φ退俾释ǖ啦杉辽?0次請求用于統(tǒng)計分析。實(shí)驗將比較幾種常用的分類器模型在本算法中應(yīng)用時的分類效果。
對 DNS數(shù)據(jù)連接分類器進(jìn)行訓(xùn)練和評估,需采集一系列合法DNS流量樣本,以及DNS隱蔽通道的流量樣本。實(shí)驗使用的合法流量樣本取自上海交通大學(xué)校園網(wǎng)的DNS流量,在1h的流量截取文件中,提取單一客戶端對同一純域名請求次數(shù)最多的 6 890個 DNS數(shù)據(jù)連接,并確認(rèn)了其均不屬于DNS隱蔽通信。
為了獲得 DNS隱蔽通道樣本,實(shí)驗運(yùn)行了多個現(xiàn)有的 DNS隧道軟件,截取其產(chǎn)生的流量。測試的DNS隧道程序包括Iodine、Dns2tcp、DNSCat、tcp-over-dns和 PSUDP。對于支持多種資源記錄類型的Iodine、Dns2tcp和DNSCat,分別截取了其在NULL、TXT、SRV、MX、CNAME、KEY等資源記錄,以及Raw UDP模式下的流量。
為使訓(xùn)練產(chǎn)生的模型既能識別數(shù)據(jù)傳輸中的大吞吐量隱蔽通道,又可檢測低頻交互、小流量的通道,對上述DNS隧道軟件的實(shí)驗中,分別截取其活動狀態(tài)(有數(shù)據(jù)通過隧道傳輸)和空閑狀態(tài)(隧道保持連接)時的流量。隧道傳輸?shù)臄?shù)據(jù)采用 Web瀏覽器自動加載網(wǎng)頁的方法產(chǎn)生。PSUDP采用在已有DNS流量中注入數(shù)據(jù)的被動工作方式,自身不產(chǎn)生DNS請求,因此,PSUDP的實(shí)驗,以1次/秒的頻率發(fā)送DNS請求,使PSUDP能夠進(jìn)行數(shù)據(jù)傳輸。
上述DNS隧道程序的實(shí)驗總共涵蓋22種隱蔽通信模式。實(shí)驗對每種模式分別截取6個時間段,產(chǎn)生總共132個DNS隱蔽通道流量樣本(如表3所示)。
表3 訓(xùn)練樣本集
本文使用 Weka[16]軟件,對 J48決策樹、樸素貝葉斯(Na?ve Bayes)和邏輯回歸(LR, logistic regression)算法進(jìn)行比較,分類器模型采用十折交叉驗證進(jìn)行測試。
分類器模型比較結(jié)果如表4所示,J48決策樹和LR算法的模型正檢率(true positive rate)相同,均為95.6%。樸素貝葉斯算法的準(zhǔn)確率明顯較低J48和LR算法,因此不適用于本文研究的場景。LR算法的誤報率(false positive rate)低于決策樹算法,而決策樹算法ROC曲線(如圖3所示)區(qū)域面積(AUC)最大,即其平均性能最優(yōu)。
J48決策樹算法在實(shí)驗比較中取得了較為準(zhǔn)確的分類結(jié)果,并且該算法效率高,輸出的模型直觀明了。J48算法采用自頂向下、分而治之的的決策樹構(gòu)造方法,選擇信息增益率最大的屬性進(jìn)行分裂,遞歸直至決策樹各節(jié)點(diǎn)樣本均為相同類別或無屬性可分裂。決策樹構(gòu)造過程中對分類信息增益最大的屬性進(jìn)行了選擇,模型實(shí)際使用的特征數(shù)量較少,在實(shí)時流量處理時可降低資源開銷。因此,在后續(xù)的實(shí)驗及實(shí)時流量檢測系統(tǒng)的實(shí)現(xiàn)中,采用了J48決策樹作為機(jī)器學(xué)習(xí)的分類器算法。
表4 分類器模型比較
圖3 分類模型ROC曲線
在不同的特征選取的情況下,分別建立分類器模型進(jìn)行比較,采用全樣本集和十折交叉驗證評估,各個模型的誤報率均在0.15%至0.30%的范圍內(nèi),因此著重比較其漏檢率(false negative rate)。由于FS3包含的特征數(shù)量眾多,進(jìn)一步將FS3分為報文解析特征統(tǒng)計(FS3PP)、請求域名特征統(tǒng)計(FS3DN)和資源記錄特征統(tǒng)計(FS3RR)3部分進(jìn)行了評估,不同特征選取時模型漏檢率如圖4所示。結(jié)果表明FS3和全部特征集(ALL)均取得了較低的漏檢率,而FS1和FS2的漏檢率較高。
圖4 各類特征集下的漏檢率
與本文算法相比,傳統(tǒng)的基于高請求頻率判斷DNS隱蔽通道的方法,僅僅依賴于統(tǒng)計同一客戶端對同一純域名的請求量,即僅使用本文算法的特征集FS1中的特征,而缺乏應(yīng)用層深入分析產(chǎn)生的特征集FS2和FS3。圖5對比了合法請求與隱蔽通道樣本的報文數(shù)量分布,DNS隧道程序在保持連接和低速率傳輸時的請求頻率與合法應(yīng)用難以區(qū)分,34.5%的隧道樣本5min報文數(shù)小于150,而有17.2%的合法樣本報文數(shù)超過該值。根據(jù)此參數(shù)設(shè)定閾值,為使誤報率保持在合理范圍內(nèi),將不可避免地忽略低帶寬的隱蔽通信。因此,特征評估實(shí)驗利用FS1特征集建立決策樹模型的漏檢率達(dá)30%左右。
圖5 同域名查詢頻率分布
特征集FS2分析含前向指針、CNAME記錄和二進(jìn)制域名的流量異常,符合標(biāo)準(zhǔn)規(guī)范實(shí)現(xiàn)的DNS隱蔽通道避免產(chǎn)生上述特殊報文,因此,僅依據(jù)特征集FS2能夠檢測的隱蔽通道類型較少,在特征評估實(shí)驗中的漏檢率高達(dá)50%以上。
特征集FS3對協(xié)議報文尺寸、QNAME特征和資源記錄特征的統(tǒng)計特性分析能夠準(zhǔn)確區(qū)分合法與隱蔽通道。如圖 4所示,根據(jù)交叉驗證評價,F(xiàn)S3PP、FS3DN和FS3RR分別建立模型的漏檢率為7.1%、4.4%和 12.4%。3.3節(jié)提取的全部特征中,對J48算法分類信息增益率最大的特征為 max(F8),即 QNAME所攜帶的最大信息量,因而其所屬的FS3DN分類準(zhǔn)確率高于FS3PP與FS3RR。特征集FS1對報文數(shù)量的計數(shù)np與FS3PP協(xié)議報文尺寸求和∑Li在報文尺寸Li一定的前提下呈正相關(guān)性;FS2檢測的 CNAME和二進(jìn)制域名特殊報文,則在FS3RR的回答資源記錄尺寸及FS3DN的 QNAME信息量中對應(yīng)地進(jìn)行了計算。從而,F(xiàn)S3部分?jǐn)y帶了FS1與FS2特征所含的信息,依據(jù)FS3建立的決策樹模型取得了與全特征集相同的準(zhǔn)確率。
為驗證決策樹模型的檢測能力,對訓(xùn)練使用的隱蔽通道模式重新截取新的流量,測試結(jié)果表明該模型能檢出全部22種已知的DNS隱蔽通道。進(jìn)一步地,本文實(shí)驗檢驗?zāi)P蛯τ?xùn)練未涉及的“未知”DNS隱蔽通道的檢測能力。實(shí)驗另外測試了 3個DNS隧道程序,分別為OzyManDNS、Heyoka,以及作者自行設(shè)計的DNS隱蔽通道NSChan。NSChan使用 Base32域名編碼,下行數(shù)據(jù)采用了與其他隧道均不同的設(shè)計,將數(shù)據(jù)編碼為多個IPv4地址,通過A記錄返回。對于上述3個未經(jīng)訓(xùn)練的DNS通道程序,檢測結(jié)果如表5所示。
模型成功檢測活動和空閑狀態(tài)的 OzyManDNS與Heyoka,以及活動狀態(tài)下的NSChan。模型未能檢測空閑狀態(tài)的 NSChan,對其流量分析后發(fā)現(xiàn),兩方面因素導(dǎo)致了漏檢的產(chǎn)生。首先,NSChan在空閑、保持連接狀態(tài)下的請求頻率fidle= 0 .2,低于訓(xùn)練使用的 Iodine的fidle= 0 .33,以及 DNSCat、Dns2tcp和tcp-over-dns的1.0、2.0和6.0,從而,其 5min對外報文數(shù)no=Tfidle= 6 0恰好低于決策樹模型在該參數(shù)的閾值68,被判為合法。其次,本文作者實(shí)現(xiàn)NSChan時,對封裝報文頭部長度未作優(yōu)化,空閑時子域名長度與其他隧道活躍時相當(dāng),使決策樹在請求報文最小長度節(jié)點(diǎn)處進(jìn)入了適用于活躍隧道的分支。盡管如此,NSChan在數(shù)據(jù)傳輸時,不可避免地出現(xiàn)頻率提高及域名長度增加的隱蔽通信特征,活動狀態(tài)依然無法躲避本算法檢測。作為改進(jìn)方案,模型訓(xùn)練時可添加將隧道程序fidle參數(shù)減小后采集的樣本,截取報文量接近系統(tǒng)參數(shù)Rm(如3.4節(jié))的流量,以增強(qiáng)模型對請求頻率低至下界fm= 2/Rm的隧道的檢測。
表5 檢測訓(xùn)練集以外的DNS隱蔽通道
本文對 DNS隱蔽通道檢測算法進(jìn)行了實(shí)現(xiàn),處理實(shí)時的 DNS流量發(fā)現(xiàn)其中的隱蔽通信行為。將檢測系統(tǒng)在上海交通大學(xué)網(wǎng)絡(luò)中心的 DNS流量監(jiān)控服務(wù)器上進(jìn)行了部署,檢驗算法在實(shí)際環(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的運(yùn)行和檢測,實(shí)際環(huán)境測試結(jié)果如表6所示。系統(tǒng)共產(chǎn)生了30萬個樣本進(jìn)入分類器,其中310個被檢出的樣本確認(rèn)屬于隱蔽通信,系統(tǒng)總共檢測到7個獨(dú)立的隱蔽通道的存在。
表6 實(shí)際環(huán)境測試結(jié)果
圖6 CipherTrust DNS隧道流量分析
在誤報方面,分類器對樣本的誤報率為0.107%,10h內(nèi)誤報的客戶端IP地址為38個,誤報的域名僅23個。DNS流量進(jìn)入分類器前,經(jīng)過了初步數(shù)據(jù)分組過濾、DNS數(shù)據(jù)連接過濾2個過濾器,前者濾除了27.5%的合法DNS報文,后者則將約91%的DNS會話直接判為合法而無需經(jīng)過分類器判別。2個過濾器使得最終進(jìn)入分類器判決的會話數(shù)與系統(tǒng)輸入的DNS流量相比大幅減少,因此,系統(tǒng)對全部流量的誤報率遠(yuǎn)低于表6中分類器模塊的誤報率。
對檢測系統(tǒng)的誤報分析發(fā)現(xiàn),系統(tǒng)的誤報主要來自于異常的客戶端程序?qū)崿F(xiàn),如29%的誤報產(chǎn)生自某主機(jī)以5s為周期對a.root-servers.net的重復(fù)請求,由于該請求產(chǎn)生的回答含大量授權(quán)和附加段資源記錄,被認(rèn)為是隧道下行流量。對于DNSBL服務(wù),模型訓(xùn)練中已學(xué)習(xí)的以MD5或IP地址為前綴的DNSBL在實(shí)際環(huán)境部署時沒有任何誤報,但在實(shí)際流量中誤檢了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隧道在一些合法軟件中的應(yīng)用。McAfee(麥克菲)的軟件利用DNS隧道技術(shù)將用戶電子郵件的部分信息傳送到服務(wù)器,用于其聲望評分系統(tǒng)。其 DNS隧道利用域名 ciphertrust.net,抓包分析顯示其DNS請求符合典型的DNS隱蔽通信模式(如圖6所示)。
本文通過對 DNS隱蔽通道構(gòu)建方法的研究和總結(jié),提出了基于機(jī)器學(xué)習(xí)的檢測算法,能夠全面檢測利用域名遞歸解析和服務(wù)器直接通信的多種DNS隱蔽通道模型,解決了現(xiàn)有算法在通道類型上的局限性。經(jīng)過實(shí)驗比較,本文選擇利用J48決策樹分類器對 DNS數(shù)據(jù)連接的特征進(jìn)行判別。分類器模型可檢測訓(xùn)練涉及的全部22種隱蔽通道模式,以及多種未經(jīng)訓(xùn)練的新型隱蔽通道。本文實(shí)現(xiàn)了在實(shí)時 DNS流量中檢測隱蔽通道的系統(tǒng),在校園網(wǎng)環(huán)境中進(jìn)行了部署測試,成功檢測到7個隱蔽通道的存在,并探討了實(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.