一、 概述
隐蔽信道是指允許程序以危害系統安全政策的方式傳輸倍息的通信通道。隐蔽信道在公開的信道掩蓋下，采用特殊的編碼方式，傳輸非法或私密的資訊而不被人發現。其廣泛存在于作業系統、網絡系統和應用系統中。對網絡資訊系統的安全構成了嚴重威脅。
在網絡安全領域通常将隐蔽信道稱為隐蔽通道，主要是利用網絡協定設計中存在的一些缺陷，通過某種算法，将隐蔽資訊嵌入到合法的網絡資料流中。傳統隐蔽通道主要依靠傳輸層和網絡層協定實作。由于防火牆和IDS等網絡安全裝置的存在，單純利用這兩層構造的隐蔽通道很容易被檢測出來。是以HTTP、 DNS、FTP等網絡協定開始被隐蔽信道利用。
DNS協定是網際網路最為關鍵的基礎協定，也是網際網路大部分服務和應用正常運轉和實施的基礎。 正是因為DNS協定的廣泛性和不可替代性，基于DNS協定的隐蔽信道對網絡安全構成了嚴重威脅。
二、DNS隐蔽信道基本原理
DNS信道主要由被控端和控制端兩部分組成，其基本思想是，利用1台僞裝的DNS伺服器作為中轉節點，利用DNS査詢過程建立除蔽通道，實作資料傳輸。其基本結構如下圖所示：
DNS隐蔽信道基本結構
DNS Tunneling可通過通信的方式分為直接和中繼兩種模式，直連指用戶端直接和指定的DNS伺服器位址直接通信，通過将資料編碼封裝在DNS協定中，特點：速度快，但限制較高（很多場景不允許指定DNS Server）。
中繼指有DNS疊代查詢的過程，特點較為隐蔽，但由于資料包到達目标DNS Server前需要經過多個節點，是以速度上較慢。
圖1 DNS隐蔽信道基本結構
假設目标主機IP為1.1.1.1，并在頂級域名伺服器中将域名temp.com注冊為該IP。内部主機（被控端）與目标主機（控制端）通過DNS隐蔽信道通信基本過程如下：
1、内部主機把要發送的資料作為主機名構造一個域名解析查詢請求，例如，上傳資料update，查詢請求：updata. temp.com；
2、査詢請求通過本地的DNS伺服器，向頂級域名伺服器查詢得到temp.com域名對應的IP位址1.1.1.1；
3、本地的DNS伺服器向1.1.1.1發送DNS査詢請求: updata. temp.com；
4、目标主機（控制端）1.1.1.1從查詢請求中，得到内部主機上傳的資料；
5、目标主機将要傳送給内部主機的非法資料作為DNS查詢請求的響應資訊發送給本地DNS伺服器；
6、本地的DNS伺服器将包含非法資料的查詢結果返冋給内部主機。進而實作内部主機與外部控制主機間的雙向通信。
2.2 DNS隐蔽信道編碼
DNS隐蔽通道将上傳的數裾作為DNS查詢的主機名字段。在有關DNS協定的标準中規定單個域名的最大長度為253 Byte，域名的各部分之間用“.”分隔，各部分最大長度為63 Byte,毎個字元可以是字母(不區分大小寫)、數字或連接配接符。
是以，在一個DNS查詢封包中，最多可以攜帶242個字元，每個字元可以有37個不冋的取值。如果使用DNS隐蔽通道傳遞資料，則必須先對要傳輸的資料進行編碼，使其滿足标準的要求。
BASE-32、BASE-64、BASE-128編碼
一種常用的編碼政策是使BASE-32編碼，每個位元組編碼5個比特的原始資料。在此編碼方式下，一個DNS查詢拫文最多可攜帶資料顯為151 Byte.
DNS隐蔽通道通常使用TXT類型的資料記錄來攜帶下傳資料，TXT記錄主要用來儲存域名的附加文本資訊，為了友善傳輸通常使用BASE-64編碼對下傳傳輸的資料進行編碼，每個位元組編碼6個比特的原始資料。
BASE-128編碼是基于BASE-64編碼的一種編碼方式。
二進制編碼
在較新的RFC标準文檔RFC 2181和RFC 4343中規定域名記錄的各個部分都可以使用任何二進制字元，而不再局限與RFC 1034所規定的有限字元集合。使用二進制方式編碼資料可以顯著提高DNS隐蔽通道的效率，但在使用前必須在控制端和被控制端間協商确認雙方都能夠支援二進制編碼，否則扔使用BASE-32等編碼方式編碼資料。
三、DNS隐蔽信道可行性檢測方法
由于受到DNS協定規範的限制， DNS資料包長度有限，無法攜帶較多資料。若要滿足檔案傳輸、遠端桌面控制等需求，則需要進行大量DNS封包傳輸。是以，可以通過對一個或多個DNS的請求和響應封包的有效載荷分析，檢測DNS隐蔽信道；或者持續對多個DNS封包的大小、頻率等屬性進行統計分析進行DNS隐蔽信道檢測。
3.1 DNS有效載荷分析
DNS隐蔽信道傳輸時，為了傳輸資料，控制端會在DNS請求和響應封包中放入盡可能多的資料，并且編碼後的資料通常會含有較多的數字，是以，可以通過以下幾方面進行檢測：
主機名長度檢測：通常DNS隐蔽隧道用上傳資料作為主機名，是以DNS隐蔽信道的主機名一般較長，通常建議将主機名超過52個字元的DNS請求作為DNS隐蔽信道檢測的一個名額；
利用域名的熵值：正常的DNS域名常常使用字典中的單同或其他有意義的字元串。而DNS隐蔽信道編碼的域名一般具較高的熵，并會很均勻地使用字元集的各種字元。是以，可以把較高熵的 DNS域名作為識別DNS隐蔽信道的一個名額；
域名中數字占比及詞頻檢測：合法的DNS域名較少使用數字，而經過編碼的DNS域名會有很多數字，是以可以通過域名中數字字元占比進行DNS隐蔽信道檢測；
下傳資料非典型記錄類型檢測：上文提到DNS隐蔽信道下傳資料通常使用TXT記錄，也可以作為DNS隐蔽信道檢測名額；
DNS信道中FQDN檢測；
特征比對法：某些DNS隐蔽信道也會含有特征字元串，可以使用DPI技術進行檢測；
3.2 統計分析法
由于DNS封包的長度限制，為了傳輸非法資料，通常需要大量DNS請求及響應封包通過DNS隐蔽信道進行通信，可以對以下幾個方面進行統計分析來檢測DNS隐蔽信道。
不同IP的DNS流量總量：可以通過檢測單個IP的DNS流量總量是否超過正常數量進行DNS隐蔽信道檢測；
不同域名的DNS流量總量：檢測方式與上一種類似，不過由于DNS隐蔽信道可能配置多個域名進行傳輸，是以可能存在識别率低問題；
DNS流速率及持續時間檢測：DNS隐蔽信道的資料流通常持續時間較長、速率較快，也可以作為一個檢測名額；
不存在關聯的DNS請求檢測： 正常的DNS請求通常在另一個請求之前，例如，HTTP請求，而DNS隐蔽信道通常沒有與之關聯的其他請求，是以也可以作為一個檢測名額；
上面給出的幾種DNS隐蔽信道檢測方法，通常要多種檢測名額一起使用，來彌補單一方法的不足。
3.3 總結方法
由于檢測裝置的限制、平台的實作方式、以上方法的總結（經測試），提出一套綜合實作方法。根據目前應用審計日志的現況，更改了原始方法（下面隻介紹現行的方法）。
根據2.1DNS有效載荷分析和2.2統計分析法歸納總結，搭建DNS隐秘隧道工具分析流量封包（目前比較活躍dns2tcp、iodine、dnscat2），抓取正常DNS流量封包對比分析。根據對DNS隧道工具分析，得到其原理相似結論，總結和驗證了2.1和2.2方法特征。
具體的工具原理實作是基于DNS域名查詢方式，具體見圖2所示：
注冊域名com
用戶端Client B在内網環境下發起com，在本地伺服器進行遞歸查詢
查詢不到，轉各個頂級域名查詢，尋找目标主機
需注意：減小注冊域名影響、裝置syslog日志還原DNS域名
圖2 拓撲圖
根據以上DNS隧道查詢原理和先平台的特性，總結出：可用于域名進行差別的方法，對于提到的關于域名的區分特征如下：熵值、數字占比、詞頻等都可以用CNN方法擷取其特征，并且還可以對深層次的特征和未知特征進行提取，具體實作過程參考實施案例。
四、 CNN深度學習方法
根據第三節進行實際方法論證，擷取公開平台和本機的DNS正常流量封包，搭建DNS隐秘隧道擷取流量封包，同時擷取公開DNS隧道流量封包（人工驗證）。驗證2.1和2.2原理是否可行，叙述新方法可行性和實驗過程。
4.1環境搭建
列舉iodine、dns2tcp隧道工具進行分析。首先進行dns隧道環境搭建并抓包（此處省略）。圖3和圖4表示在使用工具時抓的流量封包，标黃部分表示請求域名。
列舉抓取的正常DNS流量包，如圖5和圖6所示（qq和baidu）。
圖3 Iodine流量封包
圖4 dns2tcp流量封包
圖5 qq流量封包
圖6 baidu流量封包
正常裝置出現的問題整理如下：
實際域名内容：
paayk1va.abdcd.com
syslog日志顯示：
\08paayk1va\05abdcd\03com
實際域名内容：
M56BgAABADE5NEVGOTMyRUIwRjhBODlEOTVCNzZEMDdDQkFBRDlEODI4NTg4ODk.=auth.ns.strage.lxw
syslog日志顯示：
?M56BgAABADE5NEVGOTMyRUIwRjhBODlEOTVCNzZEMDdDQkFBRDlEODI4NTg4ODk\05=auth\02ns\06strage\03lxw
實際域名内容：
0aeby82\3122hb\276\356Y\326ok\374\333\340\3364ywZr\360\337c\276\302Xj\310\330\335q\315\346w\310\325TN\351\335\341b\356\346\306zR\325\352\344Zb\276\342\3604.gZ\353\323\310\333\345\304\334\362Z\306B\276cavF\2773m.abdcd.com
syslog日志顯示：
>0aeby82\ca2hb\be\eeY\d6ok\fc\db\e0\de4ywZr\f0\dfc\be\c2Xj\c8\d8\ddq\cd\e6w\c8\d5TN\e9\dd\e1b\ee\e6\c6zR\d5\ea\e4Zb\be\e2\f04\15gZ\eb\d3\c8\db\e5\c4\dc\f2Z\c6B\becavF\bf3m\05abdcd\03com
注明：需要的顯示：實際域名内容
針對以上問題已經向軟體送出相關需求，由于時間問題，自己對以上出現的問題進行處理還原（目前看來可行）。
4.2 原理驗證
域名熵值驗證：根據以上抓的包，驗證隻使用熵值會誤報（圖7執行個體說明），利用多資料熵值平均值驗證其是特征（有區分度）。
域名長度驗證：單長度驗證較明顯會誤報。
域名特殊字元驗證：同上
域名詞頻驗證：同上
圖7 計算資訊熵
如果将這幾種方法同時用于判斷是否是DNS隐秘隧道流量（準确率提高），但幾種方法之間的互相關系如何衡量（權重）是難題。
4.3 算法論證尋找權重
由于以上方法的論證和封包分析，如何将域名部分的複雜度、長度、特殊字元、詞頻、進行合理的系數配置設定，現在成了檢查DNS隐秘隧道的關鍵點（syslog日志無法擷取req/res時間間隔，記錄類型、統計分析法中流量相關特征等（态感可結合））。
下面重點介紹下實作過程，結合圖8流程圖了解：
- 擷取的DNS隐秘隧道流量封包和正常的DNS流量封包進行解析成文本格式。根據以上分析方法，和現實情況，擷取封包文本中請求域名部分。
- 請求域名部分：去除一級域名部分，保留由DN隧道工具引起特殊編碼部分。例如（=auth.ns.strage.lxw）去除strage.com部分，保留M56BgAABADE5NEVGOTMyRUIwRjhBODlEOTVCNzZEMDdDQkFBRDlEODI4NTg4ODk.=auth.ns部分；其中strage.com可比對情報庫。
- 判斷注冊域名是否相同，相同則進行計數，不相同則進行再次運作計數。
- 判斷該域名是否是通過DNS隐秘隧道進行通信操作：對保留的域名部分進行資料處理；進該部分進行長度計數，并将DNS隧道流量封包文本中出現的域名進行清單标記（{'+': 1, '-': 2, '/': 3, '.': 4, '1': 5, '0': 6, '3': 7, '2': 8, '5': 9, '4': 10, '7': 11, '6': 12, '9': 13, '8': 14, '=': 15, '\\': 16, 'a': 17, 'c': 18, 'b': 19, 'e': 20, 'd': 21, 'g': 22, 'f': 23, 'i': 24, 'h': 25, 'k': 26, 'j': 27, 'm': 28, 'l': 29, 'o': 30, 'n': 31, 'q': 32, 'p': 33, 's': 34, 'r': 35, 'u': 36, 't': 37, 'w': 38, 'v': 39, 'y': 40, 'x': 41, 'z': 42}）利用數字來表示字元特征。
- 通過算法進行數字特征學習（特征簡單），淺層特征：可以對一串字元串的清單進行詞頻和複雜度比較，深層特征：例如特殊字元，提取出DNS隧道請求域名和DNS正常請求域名的特殊字元清單。
- 通過CNN算法進行資料訓練後，可有效對相關特征進行權重配置設定(model.fit()函數訓練定義的CNN架構參數)，自動提取域名特征并儲存訓練結果。通過提取特征權重參數儲存模型進行對未知請求域名判斷。為了更好的可解釋性可使用傳統的機器學習算法。
- 未知域名的預測，先進行域名資料部分處理，去除一級注冊域名；輸入處理後域名部分進行模型預測（predict(url)）通過feed_dict函數中輸入進行模型參數查詢,其次對輸入域名進行處理（如訓練過程中資料處理一緻），利用模型中訓練結果進行判斷該域名和DNS隧道域名以及正常域名的相似度，例如：輸入域名和模型對比結果如[0.985462,0.254868]，可知：該域名是DNS隧道請求域名部分。
- 判别結果進行計數操作，判斷同一個注冊域名可能是DNS隐秘隧道通信的可能性
圖8部分流程圖（需要請留言私信）
4.4 代碼核心部分
syslog日志處理過程：
（部分代碼，需要請留言私信）
注:由于實作方法的需要，對DNS應用審計的syslog日志進行資料處理。出現的三種驚恐進行了總結（過程見DNS隐秘隧道問題總結和解析.txt文檔）。利用Python進行解析代碼編寫。
資料處理過程：
（部分代碼，需要請留言私信）
訓練過程：
（部分代碼，需要請留言私信）
注明：整個過程的資料處理部分和訓練部分，本文的第四部分已進行了詳細的叙述。
五、傳統方法+算法（決策樹）
5.1 方法介紹：
由于以上原理，構造出特征資料，利用傳統的決策樹算法進行計算；具體過程如下：
将提出域名部分進行計算：第一，域名長度；第二，域名熵值；第三，域名中數字和特殊字元占比。利用通用算法計算出以上數值，利用決策樹算法進行訓練該三組的資料（利用現有的資料（2W））。
結果是：三組資料權重[0.30657039 0.25415164 0.43927797],從決策樹算法儲存檔案中可擷取：域名長度判斷條件：21，域名熵值判斷條件：3.062，域名中數字和特殊字元占比判斷條件：0.303；超出各判斷名額可判斷是隐秘隧道。
資料計算過程：
資料處理後結果：
決策樹方法（tree.DecisinTreeClassifier）
（部分代碼，需要請留言私信）
5.2 話外篇：
上述方法如在大資料平台上使用，要考慮資料量和平台處理速度，為了提高可行性可使用以下方法+第五節方法。
根據文獻查詢和測試，總結簡單特征方法：
DNS隐秘隧道對外傳輸資料時，最長的子域名往往在25位元組以上，而合法域名請求中僅2%的子域名超過25個字元；但DNS隧道在空閑狀态下的子域名通常小于10byte，與合法請求相似。
DNS會話在5min内回答資料總位元組數分布：4%的合法DNS通信在5min内回答資料小于20kb，而DNS隐秘通道活躍時5min的下行資料通常在50kb以上。
#我要上 頭條##什麼技術用了就回不去##頭條##頭條創作挑戰賽#