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

劉陽洋　阮樹驊　曾雪梅

摘 要：針對DNS隱蔽信道（DCC）流量變形策略對現(xiàn)有檢測方法的繞過性問題，提出了一種基于流量切片的DCC檢測方法。該方法首先將實驗環(huán)境出口流量基于滑動窗口分批，再基于主機端聚合形成流量切片，每個切片包含一個較短時間跨度中歸屬同一主機的DNS報文與Web報文，再對切片內(nèi)DNS報文的數(shù)據(jù)量、請求行為、響應行為以及與Web報文的關聯(lián)行為實施面向DCC檢測的特征工程，并在此基礎上建立DCC檢測模型。對比實驗表明，所構(gòu)建的DCC檢測模型在常規(guī)DCC流量切片集上檢測準確性達到99.83%，誤報率僅0.08%，在6類不同流量變形策略的變形DCC流量切片集上有平均95%以上的檢出能力，遠優(yōu)于其他檢測方案，證明了所提出的方法應對DCC流量變形的有效性。同時，該方法能在主機單個流量切片上對DCC通信作出有效檢測，是一種具有良好實時性的檢測方法。

關鍵詞：DNS隱蔽通道；流量變形；主機流量切片；行為分析

中圖分類號：TP309 文獻標志碼：A 文章編號：1001-3695（2023）10-039-3138-06

doi：10.19734/j.issn.1001-3695.2023.02.0040

DNS covert channel detection based on traffic slice

Liu Yangyanga，b，Ruan Shuhuaa，b，Zeng Xuemeib

（a.School of Cyber Science & Engineering，b.Cyber Science Research Institute，Sichuan University，Chengdu 610065，China）

Abstract：In order to solve the problem of bypassing detection methods for DNS covert channel（DCC） traffic deformation strategies，this paper proposed a DCC detection method based on traffic slice.In this method，the traffic of the experimental environment was firstly divided into batches based on the sliding window，and then obtained the traffic slice based on the aggregation of each host-end IP.Each slice contains DNS packets and Web packets belonging to the same host in a short time span.Then，for the DNS data volume，DNS request behavior，DNS response behavior，and association behavior correlation behavior with WEB of DNS in the slice，it implement DCC-detection-oriented feature engineering and create detection models on this basis.Comparative experiments show that the detection accuracy of the constructed DCC detection model on the conventional DCC traffic datasets is 99.83%，and the false positive rate is only 0.08%.On the deformed DCC traffic datasets with six types of different traffic deformation strategies，the detection ability of the DCC detection model is more than 95% on average，which is better than the other detection schemes.It proves that the proposed method is effective in dealing with DCC traffic deformation.Moreover，the proposed method，which can effectively detect DCC communication within a single traffic slice，is a detection method with good real-time performance.

Key words：DNS covert channel；traffic deformation；host traffic slice；behavior analysis

0 引言

DNS隱蔽通道（DCC）［1］作為一種隱匿C&C通信與數(shù)據(jù)竊取行為的隧道技術被廣泛集成于各種攻擊軟件，活躍在網(wǎng)絡安全事件中。2019年Lab Dookhtegan在Telegram上曝光的APT34組織的攻擊數(shù)據(jù)包中發(fā)現(xiàn)了利用異常長域名傳輸數(shù)據(jù)的DNS報文；2021年PYSA勒索團伙將DCC集成到遠程訪問木馬程序ChaChi中用于數(shù)據(jù)竊?。?022年Malwarebytes披露出一款針對約旦政府的惡意軟件Saitama，其將DCC作為唯一控制命令傳輸通道，DCC嚴重危害網(wǎng)絡安全。

流量異常檢測是目前公認最有效的DCC檢測手段，根據(jù)防御方在檢測中關注的異常點不同，可將目前的DCC檢測方法分為基于報文內(nèi)容分析的DCC檢測、基于流行為分析的DCC檢測和基于域行為分析的DCC檢測三類。

基于報文內(nèi)容分析的DCC檢測方法［2～10］，依據(jù)DCC報文與正常DNS報文在內(nèi)容表現(xiàn)上存在的差異性進行檢測。Ahmed等人［2］認為DCC報文會在全限定域名FQDN表現(xiàn)出明顯差異，提取了字符數(shù)、域名級數(shù)、各級域名熵等6維特征用于檢測DCC。Born等人［7］認為DCC報文的請求域名不符合zipf定律，通過分析域的unigram、bigram和trigram字符頻率來進行DCC的檢測。Preston［8］提取子域長度、信息熵、字符串平均相似度等內(nèi)容特征進行DCC檢測。文獻［9，10］將DNS報文中的字節(jié)序列轉(zhuǎn)碼為高維的字節(jié)級特征，結(jié)合深度學習算法進行DCC檢測，本質(zhì)上仍然是基于DNS報文內(nèi)容的異常檢測。

基于流行為分析的DCC檢測方法［11～16］，將DNS報文以五元組進行流聚合，依據(jù)DCC流與正常DNS流在通信行為表現(xiàn)上存在的差異性進行檢測。Ellens等人［11］提出DCC會維持通信流并持續(xù)傳輸數(shù)據(jù)，提取DNS流持續(xù)時間、通信包數(shù)等特征，通過設立閾值的方式進行DCC流的判斷。Jiang等人［15］提出一種流級和包級特征結(jié)合分析的方法，提取持續(xù)時間、請求域名信息熵等13維特征來識別DCC。Bai等人［13］在DNS流還原前提下，利用時間bin切分流片段，分析包間隔時間的均值、方差、偏斜、峰度、百分位數(shù)等指標，用三種機器學習算法將DCC流進行細分識別。

基于域行為分析的DCC檢測方法［17～21］，是針對中繼模式［22］的DCC。中繼DCC服務端通常偽裝為權威域名服務器加入DNS系統(tǒng)，運行時需要借助域來實現(xiàn)DCC報文的轉(zhuǎn)發(fā)定向，會產(chǎn)生較多針對同一個域的非重復子域名查詢報文。因此，此類DCC檢測方法先將網(wǎng)絡中的DNS報文基于二級域名進行聚合，再進行域行為異常分析。如Nadler等人［17］針對每個域的所有請求報文提取字符熵、唯一查詢比率、非IP查詢類型率等6維特征來識別DCC。Liu等人［18］提取唯一子域名個數(shù)、子域名熵值、查詢類型為A/AAAA類型的比例等7維特征來區(qū)分識別DCC。Chen等人［21］設計了一種兩級結(jié)構(gòu)，先將FQDN子域的字節(jié)序列作為LSTM算法的輸入進行一級DCC檢測，再基于域分組來進行二級DCC識別。

然而，隨著攻擊的組織化，DCC攻擊方越來越注重攻擊的隱蔽性，各種流量變形策略用于進一步偽裝DCC流量，從而繞過相關的檢測模型。例如：針對報文內(nèi)容層面，攻擊者常采用的流量變形策略有編碼方式變化、數(shù)據(jù)包長度限制、設置更具迷惑性的域名結(jié)構(gòu)等；針對流行為層面，攻擊者改變了早期DCC單五元組會話的通信方式，采用多個流進行數(shù)據(jù)傳輸；針對域行為層面，攻擊者可基于多個域構(gòu)建隧道，分擔需要傳輸?shù)臄?shù)據(jù)，或采用直連DCC通信模式，F(xiàn)QDN就不會受到域名結(jié)構(gòu)的限制。這些流量變形策略使得攻擊者可以繞過現(xiàn)行的檢測方法。

為了應對DCC繞過性問題，本文對當前DCC流量變形策略進行了分析，發(fā)現(xiàn)如下流量行為關系：a）不論如何改變報文內(nèi)容與會話方式，DCC運行就會有相當量的DNS報文；b）DCC產(chǎn)生的DNS流量，沒有后續(xù)的HTTP或TLS會話流量，與正常網(wǎng)絡行為有較大差異；c）以上兩種行為具有瞬時性。由此，本文提出了一種基于流量切片的DCC檢測方法，在對DCC變形策略充分分析的基礎上，綜合分析主機流量切片中的DNS的數(shù)據(jù)量行為、請求行為、響應行為以及與Web流量關聯(lián)行為來進行DCC行為識別。實驗表明，相較于三類應用較廣的DCC檢測方法，本文方法在6類變形DCC數(shù)據(jù)集上均具備極好的檢測能力，在應對DCC流量變形表現(xiàn)上遠優(yōu)于其他檢測方法，并具有良好的實時性。

1 DCC變形策略

為了更好地認識DCC可采取的流量變形策略，本文對目前應用較多的DCC軟件進行了分析，包括DET［23］、Dns-cat2［24］、Iodine［25］、dns2tcp［26］、TCP-over-DNS［27］、dnsShell［28］、DNSExfiltrator［29］、DNSlivery［30］、goDoH-raw［31］。目前DCC流量變形主要分為報文內(nèi)容層面的流量變形和DCC通信行為層面的流量變形。攻擊者在報文內(nèi)容上的變形策略主要體現(xiàn)在：

a）選用不同類型的請求/響應報文來構(gòu)建隧道，將數(shù)據(jù)編碼在A、NULL、TXT、MX、AAAA等類型的DNS報文中。不同類型的DNS報文承載了不同的功能性，在結(jié)構(gòu)和內(nèi)容表現(xiàn)上有更大的自由度。

b）調(diào)整DCC的編碼方式，常見的有base32、base64，而iodine還可選擇base64u、base128編碼方式，tcp-over-dns還可選擇hexhack37以及base16編碼方式。不同的編碼方式下，數(shù)據(jù)包大小寫字符頻率、數(shù)字占比、長度特征指標會發(fā)生變化。

c）限制DCC報文攜帶信息的容量，使得DCC報文的長度、域名長度處于常見DNS數(shù)據(jù)包長度范圍。

d）個性化編輯策略差異，如構(gòu)建的DCC報文的域名級數(shù)、外傳數(shù)據(jù)的加密方式、響應報文的資源結(jié)構(gòu)等。

攻擊者在通信行為上的變形策略主要體現(xiàn)在：

a）流行為的變形，早期DCC通道如TCP-over-DNS、Dns-cat2、Iodine會維持單個五元組會話流來進行數(shù)據(jù)傳輸，使得DCC流表現(xiàn)出明顯的流特征異常。然而改良之后的DCC通道能夠采用多五元組會話的方式進行數(shù)據(jù)傳輸，使得DCC流表現(xiàn)出類似于正常DNS流的行為。

b）域行為的變形，直連模式DCC，無須借助DNS轉(zhuǎn)發(fā)機制，只要正常的路由轉(zhuǎn)發(fā)實現(xiàn)通信，其產(chǎn)生的DNS報文編碼時不必設置相同的二級域名，這會使得基于域行為的檢測方式失效。同時，攻擊者可以利用多域來分擔傳輸數(shù)據(jù)，這也使得單個域的DCC行為表現(xiàn)正常。

2 檢測方法

根據(jù)第1章分析，當前DCC報文的內(nèi)容與行為的表現(xiàn)可隨著攻擊者調(diào)整變形策略而發(fā)生變化。對目前應用較廣的三類DCC檢測方法，均存在針對性的變形策略，使得相應的DCC檢測機制失效。為了應對DCC流量變形策略，本文進行了如下考慮：a）DCC運行時，雖然可以作出內(nèi)容與行為的流量變形，但會有相當量的DNS協(xié)議流量產(chǎn)生，以傳遞數(shù)據(jù)，這種流量行為異于正常的DNS網(wǎng)絡訪問；b）目前DCC變形策略只涉及到DNS流量，然而DNS協(xié)議并不是單獨工作的協(xié)議，在正常的DNS網(wǎng)絡訪問中，域名解析之后通常建立HTTP或TLS會話，而DCC的DNS流量會缺失這種行為；c）考慮前兩點的時間瞬時性特征，即由DCC導致的DNS數(shù)據(jù)量異常具有瞬時性，DNS協(xié)議與Web協(xié)議的流量關聯(lián)具有瞬時性。

綜上，本文提出一種基于流量切片的DCC檢測方案，通過關注主機瞬時的DNS與Web流量特征，應對現(xiàn)有的DCC變形策略。方案包括主機流量切片構(gòu)建、切片特征工程以及DCC檢測模型，總體架構(gòu)如圖1所示。

2.1 流量切片

獲取流量切片需經(jīng)過三個步驟：a）基于滑動窗口的流量分批；b）每批窗口流量基于主機IP聚合形成流量切片；c）過濾不含DNS包的流量切片。

a）基于滑動窗口對原始流量分批，在實驗環(huán)境的出口流量處，以λ為周期對DNS和Web相關協(xié)議流量實現(xiàn)流量分批。λ的大小會影響檢測效果，由于DNS協(xié)議與Web協(xié)議的流量關聯(lián)具有瞬時性，λ理論上值較小，具體情況在模型有效性驗證實驗中進行討論。

b）對每一批滑動窗口中的數(shù)據(jù)包，通過源、目的端口號對數(shù)據(jù)包進行方向判斷，標記數(shù)據(jù)包的主機端與服務端，再通過主機端IP將窗口中流量進行主機級聚合形成流量切片。第k個批次窗口流量的所有主機流量切片集表示為：Sprek={Sh1k，Sh2k，…，Shik，…，Shpk}（p表示實驗場景活躍主機數(shù)量），其中，第k個批次的第i個主機流量切片表示為Shik=〈Dreq，Dres，W，λ〉。假設滑動窗口從0時刻開始如圖1所示，λ表示窗口時間跨度，k表示窗口的批次，Dreq和Dres分別表示λ時間跨度內(nèi)，所有該IP的請求和響應DNS數(shù)據(jù)包，W表示λ時間跨度內(nèi)，所有該IP發(fā)出和接收到的Web通信數(shù)據(jù)包。

c）對每批次流量切片Sprek進行過濾。考慮主機訪問部分視頻網(wǎng)站時，在較長時間段中只有Web流量，不產(chǎn)生DNS流量，因此需要過濾掉Sprek中不包含DNS流量的切片來減少計算量，過濾后每批次流量切片為Sfilterk。

2.2 特征工程

流量切片的特征工程分如下四個維度展開：

a）DNS數(shù)據(jù)量特征。DNS協(xié)議承擔域名解析功能，主機發(fā)出的DNS報文個數(shù)、字節(jié)數(shù)與主機操作次數(shù)正相關。在切片的短時跨度內(nèi)DNS數(shù)據(jù)量通常較少，而DCC報文用途在于數(shù)據(jù)通信，不論采取何種流量變形策略，在DCC運行的時段內(nèi)會呈現(xiàn)出相對較高的數(shù)據(jù)量通信行為。因此，對每個切片中D（D=Dreq ∪ Dres）計算如下特征：DNS包總數(shù)Pd、DNS總字節(jié)數(shù)Bd、DNS總請求字節(jié)數(shù)Brd。

b）DNS請求行為特征。網(wǎng)絡中DNS請求包的請求類型約有96%為A和AAAA，而DCC為追求高吞吐量，會運用其他請求資源類型，如TXT、NULL。如果僅基于內(nèi)容分析，報文的類型并不能成為DCC的判定條件，但本文的分析視角是流量切片，DCC的這種行為會導致切片內(nèi)DNS請求類型的比例發(fā)生變化。從DNS請求類型行為角度，本文先對切片Dreq解析獲取到請求類型序列DTreq，再計算請求類型行為特性：非IP類型請求數(shù)據(jù)包個數(shù)NIr、非IP類型請求數(shù)據(jù)包占比RNIr如下：

c）DNS響應行為特征。實驗過程中發(fā)現(xiàn)部分誤報來自主機訪問一些大型域，諸如baidu.com、cloudflare等，由于CDN及負載均衡配置影響，主機訪問到這部分域相關網(wǎng)絡資源時會在幾秒內(nèi)產(chǎn)生十幾個針對同一個域的不同F(xiàn)QDN請求，導致切片中正常的DNS請求包表現(xiàn)出類似中繼形DCC的請求行為。針對這類問題，可以從響應報文結(jié)構(gòu)來區(qū)分這部分流量，大型域中每個FQDN承載不同功能并且一般都配置了多個IP來實現(xiàn)負載均衡，不同F(xiàn)QDN請求的響應包資源記錄數(shù)量更具隨機性。而DCC響應包的資源記錄為攜帶數(shù)據(jù)通常統(tǒng)一設計響應結(jié)構(gòu)，其記錄數(shù)量與格式相對統(tǒng)一且簡單，因此，本文對響應包的資源數(shù)提取特征減少這部分誤報。首先通過獲取切片中響應報文Dres的響應資源數(shù)序列記做RR={rrN1，rrN2，…，rrNb}（b表示該切片內(nèi)響應包個數(shù)） 再通過RR計算響應行為部分特征：切片內(nèi)響應結(jié)構(gòu)簡單度RRS；切片內(nèi)響應結(jié)構(gòu)熵值RRE，公式為

d）DNS/Web關聯(lián)行為特征。通常情況下DNS流量與Web會話建立行為存在正相關的關系，這一行為在主機流量切片上的表現(xiàn)為：訪問資源越豐富，請求解析的域名就越多，需要發(fā)出的DNS包就越多，對應DNS流就會增加，對應建立的Web鏈接就越多。而與DCC相關的DNS流量具有Web流量缺失的特點，這就會導致正相關關聯(lián)失敗或比值異常。本文用Web流量中SYN報文表征主機建立Web會話的行為，用DNS包數(shù)、流數(shù)、FQDN數(shù)表征請求解析行為。同時考慮到Firefox與Google等瀏覽器采用的并行TCP連接加速資源獲取的技術（這意味著單次域名解析行為會對應多個Web會話建立，因此引入通信對概念對SYN報文進行去重）。綜上，本文通過跨流量層級正相關比值來表征這種關聯(lián)行為，首先對每個切片Shik獲取所有Web流量的syn報文記做Wsyn，再結(jié)合切片中的DNS流量相關報文信息計算如下關聯(lián)特征：FQDN個數(shù)與Web通信對個數(shù)比值RFwc，DNS流數(shù)與Web通信對個數(shù)比值Rdfwc，DNS包數(shù)與Web 通信對個數(shù)比值Rpdwc，DNS流數(shù)與Web流數(shù)比值Rdfwf ，公式如下：

其中：triplet代表獲取通信對三元組（源IP、目的IP、服務端口）。

至此，對流量切片完成面向DCC行為異常表征的向量化，共計14維特征。

2.3 DCC檢測模型

基于前兩節(jié)流量切片與特征工程流程。接下來介紹本文對流量切片數(shù)據(jù)集的標注、模型的訓練、驗證流程。在構(gòu)建模型的分類算法選擇上，本文選用惡意流量識別領域常用分類算法邏輯回歸（LG）、gradient boost decision tree（GBT）、隨機森林（RF）算法。模型構(gòu)建與驗證總體流程如圖2所示。

a）構(gòu)建階段，僅采用常規(guī)DCC流量和背景良性流量完成檢測模型訓練。本文在實驗園區(qū)可控網(wǎng)絡環(huán)境下部署運行默認設置的DCC客戶端來獲取常規(guī)DCC主機流量。由于DCC流量切片是混合流量（即同時存在正常行為DNS和DCC產(chǎn)生的DNS報文），所以在標記時，為避免誤標，人工記錄DCC運行時段、運行設置的二級域名、 DCC服務端IP進行切片標記（即當前切片DNS報文中存在記錄的中繼DCC通信二級域名或存在直連DCC通信的目的DCC服務端IP則標記為DCC切片）。再經(jīng)由特征工程完成常規(guī)DCC向量標注，結(jié)合良性切片構(gòu)建的背景向量完成模型訓練。

b）驗證階段，驗證本文DCC檢測方法對常規(guī)DCC以及變形DCC的檢測能力。其中，對于變形DCC，需改變部署DCC的報文變形策略并記錄運行時段與設置，激活DCC運行形成具備DCC變形代表意義的主機流量，再以a）中的標記方式進行變形DCC切片標記，經(jīng)由特征工程構(gòu)建驗證集。

同時，考慮到流量切片的粒度λ可能對檢測準確性造成影響，在實驗時進行多輪變更，構(gòu)建不同λ粒度DCC檢測模型進行對比分析。

3 實驗

3.1 實驗環(huán)境與設置

1）良性切片 以實驗園區(qū)中近兩周所有正常主機（約200臺）的出口DNS和Web流量作為正常背景流量用于生成良性切片。共采集正常主機背景DNS和Web報文存儲為pcap格式文件共計約800 GB（正常DNS數(shù)據(jù)包800萬個），以預設滑動窗口λ為5 s，生成良性流量切片數(shù)據(jù)樣本130萬條。

2）常規(guī)DCC切片 DCC流量切片通過三臺運行了DCC客戶端的主機DNS和Web流量生成。依次運行的DCC客戶端包括第1章提及的9種DCC軟件，執(zhí)行DCC功能包括文件上傳、文件下載、CC交互命令、靜默。同時，在三臺主機上，人工間歇運行常見網(wǎng)絡軟件包括QQ、影音、FireFox、IE瀏覽器、WPS等來模擬正常工作行為，以保證DCC主機流量具備真實的背景DNS和Web流量。再根據(jù)運行DCC時段是否設置流量變形策略規(guī)則，區(qū)分DCC切片類型。將默認設置下DCC運行時段的DCC主機流量經(jīng)由2.3節(jié)標記為常規(guī)DCC切片，以λ窗口設置為5 s為例，訓練集測試集劃分如表1所示。

3）變形DCC切片 經(jīng)由2.3節(jié)對采用變形策略時段DCC切片進行標記。策略記錄示例如：12月9日11時到12月9時15時，主機172.XX.XX.99，運行DCC軟件DET|Iodine|其他，DCC發(fā)出的DNS報文類型為：默認|A|TXT|CNAME|其他，單個數(shù)據(jù)包攜帶字節(jié)數(shù)：8|15|60|其他，Base編碼類型：默認|Base16|Base32|其他，會話模式：單流|多流，DCC通信模式：中繼單域名 |直連多域名。根據(jù)第1章變形策略對DCC內(nèi)容和行為理論分析影響，以λ值為5 s將變形策略時段的DCC流量切片樣本歸類到表2中6個類別變形樣本集中（由于變形策略的復合使用，樣本存在復用分類）。

4）實驗環(huán)境 根據(jù)不同DCC軟件需求進行相關的軟硬件的環(huán)境配置，采用的客戶端包括兩臺Windows 10主機和一臺Linux CentOS 7系統(tǒng)主機，DCC服務端包括Windows 10和兩臺公網(wǎng)云服務器Linux CentOS 7雙核2 MB帶寬，并注冊了一個“ourDomain.top”域?qū)崿F(xiàn)DNS中繼通信，機器學習框架采用SparkML。

3.2 實驗與分析

本文利用構(gòu)建的標簽數(shù)據(jù)集、驗證集進行檢測方法對常規(guī)DCC識別的有效性、對流量變形DCC的適用性評估，以及驗證窗口λ可能帶來的性能和準確率影響，共設置三組實驗，并通過表3中的指標進行模型評估。

3.2.1 常規(guī)DCC識別有效性驗證

依據(jù)流量切片和特征工程提取方法，本節(jié)實驗用標記時段中生成的25 000個常規(guī)切片和均衡抽樣的25 000良性切片進行模型訓練，并通過測試集驗證對9種DCC的常規(guī)形式進行識別能力。不同算法模型在本文流量切片方法下對常規(guī)DCC識別準確率如表4所示。可以看出，在不同算法模型下，本文方法對9種常規(guī)DCC均取得了超過98%的識別率，其中RF算法取得了平均超過99.7%的有效識別率，證明了在DCC不進一步偽裝自身流量行為的常規(guī)情況下，本文檢測方法具備極好的有效性與泛化性。

3.2.2 變形DCC識別有效性驗證

為了驗證方法應對DCC流量變形策略的有效性，在本節(jié)實驗中，僅基于常規(guī)DCC流量和良性流量切片進行模型構(gòu)建，再利用變形DCC流量進行檢測模型有效性驗證，算法模型為實驗1中表現(xiàn)最好的RF。

同時，本文選取了三種不同分析視角的DCC檢測方法［2，15，21］進行對比。Chen等人［21］提出一種基于LSTM深度學習算法并結(jié)合域分組分析進行DCC識別的檢測方法，為了橫向?qū)Ρ?，采用本文的流量?shù)據(jù)訓練LSTM模型，樣本中良性流量為實驗環(huán)境出口處DNS隨機抽樣的18萬個報文，訓練DCC流量為抽樣選取的18萬個常規(guī)DCC數(shù)據(jù)包，訓練測試集設置為9：1復現(xiàn)其檢測方法；Ahmed等人［2］提出一種基于內(nèi)容的DCC檢測方法，根據(jù)其檢測算法孤立森林算法的特性，污染率設置為其指出的最優(yōu)值0.05，抽取95萬個正常DNS報文和5萬個常規(guī)DCC報文作為訓練集； Jiang等人［15］使用了基于流的DCC檢測方法，采用了隨機森林算法作為檢測模型，復現(xiàn)時先將良性和常規(guī)DNS數(shù)據(jù)進行流聚合處理再構(gòu)建對應的檢測模型。隨后利用6類變形流量進行驗證。檢測結(jié)果如表5所示。

從表5檢測結(jié)果分析：基于流的DCC檢測方法在早期采用單流通信的DCC中取得最好的檢測率，但在應對較新的DCC工具如dnsShell、DNSlivery等采取了多流會話方式的DCC通道中識別效果較差；三類對比檢測方法在應對數(shù)據(jù)字節(jié)限制的DCC變形策略時，均只有百分之30即以下的召回率，經(jīng)分析是由于三種檢測方法在特征分析時都將較大的包長作為DCC識別的關鍵特征，字節(jié)限制策略規(guī)避了這一異常表現(xiàn)；基于包內(nèi)容的DCC檢測方法最容易受到流量變形的影響，在由多種DCC軟件生成的常規(guī)DCC流量中也并未取得很好的檢測效果，這是由于不同DCC流量之間存在加密方式、壓縮方式以及域名結(jié)構(gòu)等差異。根據(jù)調(diào)研，大部分基于內(nèi)容的DCC檢測研究往往局限于較少類型的DCC流量，這就導致其特征工程缺乏普適性；基于域分組分析的檢測方法在面臨多域通信時的DCC流量時幾乎是失效的。相較于目前的檢測方法，本文方法在構(gòu)建的6類表征變形策略的DCC中實現(xiàn)了平均超過95%的識別率，具備對抗DCC流量變形策略的優(yōu)勢。

3.2.3 切片滑動窗口分析驗證

在隱蔽信道識別領域，如何在通道初期就做到有效檢測，是當下研究者們關注的重點問題。本文所提出的DCC檢測方法基于固定時長的主機流量切片，切片窗口λ的設置會對檢測方法的準確性和時效性產(chǎn)生影響。為分析窗口λ對檢測方法的影響并尋求最優(yōu)λ值，本文對原始流量進行了多輪次處理，設置λ為1 s，3 s，5 s，10 s，…，40 s，良性切片和DCC切片設置比例為1：1，訓練集測試集劃分為9：1，不同粒度λ下的檢測模型準確率與誤報率結(jié)果如圖3、4所示。

從圖3和4結(jié)果分析，當λ設置過小時如λ=1 s，準確率會有明顯下降，誤報率會明顯上升，原因是過小的λ形成的流量切片在檢測DCC時容易受到網(wǎng)絡延遲的影響，由良性切片關聯(lián)行為失效而導致誤判。但隨著λ持續(xù)增大，準確率也會下降，經(jīng)分析，原因是當λ設置過大如λ=40 s，部分切片會包含較多正常網(wǎng)絡訪問產(chǎn)生的流量，若同時切片時間范圍內(nèi)的DCC運行時間很短且通信量極少時，這種微弱的DCC流量行為會被過大的流量切片忽略進而導致準確率下降。根據(jù)實驗結(jié)果，λ在設置為3～10 s時是最優(yōu)選擇，在三種分類算法中均取得了超過98.5%的準確率和低于1.2%的誤報率，其中利用隨機森林算法建立的檢測模型在λ設置為5 s時取得99.83%的準確率和0.08%的誤報率。

4 結(jié)束語

針對DCC流量變形策略的對當前檢測方法的繞過性問題，本文提出了一種基于流量切片的DCC檢測方法，該方法采用主機級流量分析視角，并將DNS流行為與Web流行為的關聯(lián)特征融入到DCC檢測模型中。多個對比實驗表明本文方法對常規(guī)DCC具有更高識別率、泛化性，對良性流量具備更低的誤報率，同時具備對變形DCC流量的顯著檢出優(yōu)越性，具備一定的理論價值和實用價值。隨著網(wǎng)絡攻擊的組織化發(fā)展，流量變形、流量混淆策略的應用也越發(fā)廣泛。本文采用的主機流量切片多協(xié)議行為關聯(lián)的分析方法對其他隱蔽通信和變形流量識別具備一定的借鑒意義。未來工作包括兩方面：第一，本文在調(diào)研后采用了惡意流量檢測領域常用算法來進行檢測研究，未來可以嘗試更為先進的智能算法；第二，未來可以探索流量切片多協(xié)議關聯(lián)分析方法對其他類型網(wǎng)絡隱蔽信道檢測的應用。

參考文獻：

［1］刁嘉文，方濱興，崔翔，等.DNS隱蔽信道綜述［J］.通信學報，2021，42（5）：164-178.（Diao Jiawen，F(xiàn)ang Binxing，Cui Xiang，et al.Survey of DNS covert channel［J］.Journal on Communications，2021，42（5）：164-178.）

［2］Ahmed J，Gharakheili H H，Raza Q，et al.Real-time detection of DNS exfiltration and tunneling from enterprise networks［C］//Proc of IFIP/IEEE Symposium on Integrated Network and Service Management.Piscataway，NJ：IEEE Press，2019：649-653.

［3］Cheng Qi，Chen Xiaojun，Cui Xu，et al.A bigram based real time DNS tunnel detection approach［J］.Procedia Computer Science，2013，17：852-860.

［4］Farnham G，Atlasis A.Detecting DNS tunneling［J］.SANS Institute InfoSec Reading Room，2013，9：1-32.

［5］刁嘉文，方濱興，田志宏，等.基于攻擊流量自生成的DNS隱蔽信道檢測方法［J］.計算機學報，2022，45（10）：2190-2206.（Diao Jiawen，F(xiàn)ang Binxing，Tian Zhihong，et al.DNS covert channel detection method based on attack traffic self generation［J］.Chinese Journal of Computers，2022，45（10）：2190-2206.）

［6］Das A，Shen Minyi，Shashanka M，et al.Detection of exfiltration and tunneling over DNS［C］//Proc of the 16th IEEE International Confe-rence on Machine Learning and Applications.Piscataway，NJ：IEEE Press，2017：737-742.

［7］Born K，Gustafson D.Detecting DNS tunnels using character frequency analysis［EB/OL］.（2010）.https：//arxiv.org/abs/1004.4358.

［8］Preston R.DNS tunneling detection with supervised learning［C］//Proc of IEEE International Symposium on Technologies for Homeland Security.Piscataway，NJ：IEEE Press，2019：1-6.

［9］Wu Kemeng，Zhang Yongzheng，Yin Tao.CLR：a classification of DNS tunnel based on logistic regression［C］//Proc of the 38th IEEE International Performance Computing and Communications Conference.Piscataway，NJ：IEEE Press，2019.

［10］Chen Yang，Li Xiaoyang.A high accuracy DNS tunnel detection me-thod without feature engineering［C］//Proc of the 16th International Conference on Computational Intelligence and Security.Piscataway，NJ：IEEE Press，2020：374-377.

［11］Ellens W，Z·uraniewski P，Sperotto A，et al.Flow-based detection of DNS tunnels［C］//Proc of IFIP International Conference on Autonomous Infrastructure，Management and Security.Berlin：Springer，2013：124-135.

［12］DAngelo G，Castiglione A，Palmieri F.DNS tunnels detection via DNS-images［J］.Information Processing & Management，2022，59（3）：102930.

［13］Bai Huiwen，Liu Weiwei，Liu Guangjie，et al.Application behavior identification in DNS tunnels based on spatial-temporal information［J］.IEEE Access，2021，9：80639-80653.

［14］Zhan Mengqi，Li Yang，Yu Guangxi，et al.Detecting DNS over HTTPS based data exfiltration［J］.Computer Networks，2022，209：108919.

［15］Jiang Kui，Wang Fei.Detecting DNS tunnel based on multidimensional analysis［C］//Proc of the 5th International Conference on Mechanical，Control and Computer Engineering.Piscataway，NJ：IEEE Press，2020：272-275.

［16］Bai Huiwen，Liu Guangjie，Zhai Jiangtao，et al.Refined identification of hybrid traffic in DNS tunnels based on regression analysis［J］.ETRI Journal，2021，43（1）：40-52.

［17］Nadler A，Aminov A，Shabtai A.Detection of malicious and low throughput data exfiltration over the DNS protocol［J］.Computers & Security，2019，80：36-53.

［18］Liu Yong，Gou Xiangnan.Research on application of feature analysis method in DNS tunnel detection［C］//Proc of the 5th Annual International Conference on Information System and Artificial Intelligence.[S.l.]：IOP Publishing，2020：012069.

［19］沈傳鑫，王永杰，熊鑫立.基于圖注意力網(wǎng)絡的DNS隱蔽信道檢測［J］.信息網(wǎng)絡安全，2023，23（1）：73-83.（Shen Chuanxin，Wang Yongjie，Xiong Xinli.DNS covert channel detection based on graph attention networks［J］.Netinfo Security，2023，23（1）：73-83.）

［20］Ishikura N，Kondo D，Vassiliades V，et al.DNS tunneling detection by cache-property-aware features［J］.IEEE Trans on Network and Service Management，2021，18（2）：1203-1217.

［21］Chen Shaojie，Lang Bo，Liu Hongyu，et al.DNS covert channel detection method using the LSTM model［J］.Computers & Security，2021，104：102095.

［22］Wang Yue，Zhou Anmin，Liao Shan，et al.A comprehensive survey on DNS tunnel detection［J］.Computer Networks，2021，197：108322.

［23］Data exfiltration toolkit［EB/OL］.（2016-06-13）［2017-11-03］.https：//github.com/sensepost/DET.

［24］Dnscat2［EB/OL］.（2014）［2018-06-26］.https：//github.com/iagox86/dnscat2.

［25］Iodine［EB/OL］.（2010）［2014-06-16］.https：//code.kr yo.se/iodine/.

［26］dns2tcp［EB/OL］.（2016）［2020-03-07］.https：//github.com/zf l9/dns2tcp.

［27］TCP-over-DNS［EB/OL］.（2008）［2008-07-27］.https：//analogbit.com/software/tcp-over-dns.

［28］Reverse_DNS_Shell［EB/OL］.（2014）［2015-12-11］.https：//github.com/ahhh/Reverse_DNS_Shell.

［29］DNSExfiltrator［EB/OL］.（2017）［2018-04-06］.https：//github.com/Arno0x/DNSExfiltrator.

［30］DNSlivery［EB/OL］.（2018）［2019-02-01］.https：//github.com/no0be/DNSlivery.

［31］goDoH［EB/OL］.（2018）［2022-06-26］.https：//github.com/sensepost/godoh.

收稿日期：2023-02-06；修回日期：2023-03-17 基金項目：國家自然科學基金區(qū)域基金重點項目（U19A2081）；中央高?；A研究基金資助項目（2022SCU12116）；四川大學理工科發(fā)展計劃項目（2020SCUNG129）

作者簡介：劉陽洋（1998-），男，四川成都人，碩士，主要研究方向為網(wǎng)絡流量識別、網(wǎng)絡行為分析；阮樹驊（1966-），女（通信作者），四川成都人，副教授，碩導，碩士，主要研究方向為云計算與大數(shù)據(jù)安全、區(qū)塊鏈安全（ruanshuhua@scu.edu.cn）；曾雪梅（1976-），女，四川成都人，工程師，博士，主要研究方向為網(wǎng)絡流量識別、網(wǎng)絡行為分析、 IPv6網(wǎng)絡安全．