在進行DNS查詢時，若是查詢的域名不在DNS服務器本機的緩存中，就會訪問互聯網進行查詢，而後返回結果，若是互聯網上有一臺定製的服務器，那麼依靠DNS協議便可進行數據包的交換。從DNS協議角度來看，這樣的操做只是在一次次的查詢某個特定的域名並獲得解析結果，但其本質問題是，預期的返回結果應該是一個IP，而事實上返回的可使任意字符，包括加密的C&C指令。html
DNS隧道根據實現方式大體可分爲兩種：
web
直連：用戶端直接和指定的目標DNS服務器創建鏈接，而後將須要傳輸的數據編碼封裝在DNS協議中進行通訊。這種方式的優勢是具備較高速度，但蔽性弱、易被探測追蹤的缺點也很明顯。另外直連方式的限制比較多，如目前不少的企業網絡爲了儘量的下降遭受網絡攻擊的風險，通常將相關策略配置爲僅容許與指定的可信任DNS服務器之間的流量經過。shell
中繼隧道：經過DNS迭代查詢而實現的中繼DNS隧道，這種方式及其隱祕，且可在絕大部分場景下部署成功。但因爲數據包到達目標DNS服務器前須要通過多個節點的跳轉，數據傳輸速度和傳輸能力較直連會慢不少。緩存
這兩種功方法雖然在工做原理上存在差別，可是從流量上看都是DNS協議，可是實際工程中也須要注意，旁路採集的方式可能會影響到你最終可否採集到的完整的通訊日誌，例如若是採用記錄dns解析的方法，則可能漏過upd-ip直連的通訊方式，若是直接在網關上進行「端口和協議解析」則可保證全流量採集。安全
在安全策略嚴格的內網環境中，常見的 C&C 通信端口都被衆多安全設備所監控。若是 攻擊者對目標內網的終端進行滲透時，發現該網段只容許白名單流量出站，同時其它端口都被屏蔽時，傳統 C&C 通信手段沒法成立，反彈 Shell 變得十分困難。在這種狀況下，攻擊者還有一個最後的選擇：使用 DNS 隱蔽隧道創建ReverseShell。
Dnscat2
Dnscat2是使用DNS協議建立加密的C&C通道，經過預共享密鑰進行身份驗證，使用shell及DNS查詢類型（TXT、MX、CNAME、A、AAAA），多個同時進行會話。服務器
Dnscat2也分爲兩種模式：微信
直連模式：客戶端直接向指定IP地址的DNS服務器發起DNS解析請求。網絡
中繼模式：DNS通過互聯網迭代解析，指向指定的DNS服務器。機器學習
流量分析
能夠看到dnscat2經過dns協議的請求包，封裝了加密後的指令執行結果。tcp
還能夠看到全部dns包的udp五元組都是相同的，受控端和C&C複用了同一個udp會話進行dns隧道通訊，dnscat2經過加密手段隱藏了CC服務器的域名，隱蔽性很好。
而且DNS請求包中名稱字段中包含了dnscat的工具標識。
通訊過程當中主要使用了MX、TXT、CNAME記錄的查詢。
檢測
l DNS請求包中的請求字段的名稱中包含了」dnscat」這個字符串，能夠做爲防火牆和入侵檢測的特徵。
l 由於全部dns包的udp五元組都是相同的，受控端和C&C複用了同一個udp會話進行dns隧道通訊，能夠利用這個特徵進行upd五元組聚類，在upd五元組會話的基礎上進行特徵工程。（機器學習）
l 不少DNS Tunneling使用TXT記錄類型發送請求和響應（例如文件上傳等大數據量功能），而在正常的DNS網絡流量中，TXT記錄的比例可能只有1%-2%，若是時間窗口內，TXT記錄的比例激增，那麼也意味着可能存在異常。
Reverse_DNS_Shell
Reverse_DNS_Shell使用 DNS 做爲 C2 通道的 Python 反向 Shell。
流量分析
能夠發現進行通訊的查詢類型都爲A類型，但在進行命令執行時，所用的爲TXT記錄報文。
在GitHub上的項目代碼中發現
def spawnShell(answer, payload): shellInput = raw_input(PROMPT) if shellInput == 'quit': EXIT = 1 if shellInput == '': spawnShell(answer, payload) out = base64.b64encode(shellInput) answer.add_answer( *dnslib.RR.fromZone('{}.com 60 TXT "{}"'.format(payload, out))) return answer
這一部分封裝的是對DNS的應答，payload裏是對上一次命令執行後的回顯，out是將這一次對被控端發送的命令進行編碼並封裝爲TXT應答包。
可是因爲工具是開源的，能夠進行多元化編譯，因此加解密方式不固定。
檢測
l 不少DNS Tunneling使用TXT記錄類型發送請求和響應（例如文件上傳等大數據量功能），而在正常的DNS網絡流量中，TXT記錄的比例可能只有1%-2%，若是時間窗口內，TXT或者A記錄的比例激增，那麼也意味着可能存在異常。
Iodine
iodine能夠經過一臺DNS服務器創造一個IPv4數據通道，特別適合在目標主機只能發送DNS請求的網絡環境中使用。
Iodine支持直接轉發和中繼兩種模式，原理是：經過TAP虛擬網卡，在服務端創建一個局域網；在客戶端，經過TAP創建一個虛擬網卡；二者經過DNS隧道鏈接，處於同一局域網。在客戶端和服務端創建鏈接後，客戶機上會多一塊名爲「dns0」的虛擬網卡。
流量分析
Iodine默認使用TXT和NULL類型發送數據,支持NULL,TXT,SRV,MX,CNAME,A等多種查詢請求類型
在test.com前的字段爲加密字段（Iodine支持base32，base64，base128等多種編碼規範），這裏使用了NULL查詢類型。
響應包中data字段是傳輸的加密數據。
同時發現傳輸的五元組也都是相同的，受控機和攻擊機是使用同一個udp會話進行DNS通訊。
檢測
l 若是必定時間內，NULL記錄的比例激增，那麼意味着可能存在異常。（可是iodine支持多種類型發送數據，因此多是NULL、TXT、SRV、MX、CNAME、A任意一種記錄比例激增）
l 由於數據包中的域名是明文傳輸，能夠檢測惡意域名。
Dns2tcp
dns2tcp使用C語言編寫。支持DNS協議KEY和TXT類型的請求。
流量分析
經過數據包發現使用的是TXT來傳輸，dns2tcp只能用兩種類型：TXT和KEY，默認是TXT。
域名前的是經過隧道加密傳輸的數據，用的base64加密。
請求包和迴應包的內容基本一致，除了迴應包比請求包多了一串base64加密後的數據。
檢測
l 若是必定時間內，TXT或KEY記錄的比例激增，那麼意味着可能存在異常。
DNS隧道傳輸數據時，會將數據切成若干個小單元依次發出，時間間隔很是小，當沒有數據交互的時候，隧道兩端仍然會發包保持通訊狀態，大概0.6s發出一個數據包，最大是3s。
能夠經過追蹤用戶DNS查詢次數，若是達到閾值就生成響應報告。
記錄TXT、NULL等查詢類型所佔比例，若是比例激增則懷疑攻擊。
查看DNS數據包字段內包含的域名是否爲惡意域名。
查看DNS數據包字段內是否包含惡意流量標籤（dnscat）
基本全部隱蔽隧道數據包中的五元組都是相同的，能夠經過五元組判斷是否存在隧道。
能夠結合協議自己，基於通訊行爲檢測隧道木馬，,採用 Winpcap 數據包捕獲技術的底層過濾機制，抓取 DNS 流量.將抓取的 DNS 流量按照五元組進行聚類,造成 DNS 會話數據流.將一個個 DNS 會話數據流提取成 DNS 會話評估向量,做爲分類訓練模塊和木馬流量監測的輸入。（機器學習）
【https://www.cnblogs.com/LittleHann/p/8656621.html】
將IP流量封裝進 IMCP 的 ping 數據包中，旨在利用 ping 穿透防火牆的檢測，由於一般防火牆是不會屏蔽 ping 數據包。
請求端的 Ping 工具一般會在 ICMP 數據包後面附加上一段隨機的數據做爲 Payload，而響應端則會拷貝這段 Payload 到 ICMP 響應數據包中返還給請求端，用於識別和匹配 Ping 請求（Windows 和 Linux 系統下的Ping 工具默認的 Payload 長度爲 64bit，但實際上協議容許附加最大 64K 大小的Payload）
在一些網絡環境中，若是攻擊者使用各種上層隧道（HTTP、DNS等）進行操做都失敗了，經常會經過ping命令訪問遠程計算機，嘗試創建icmp隧道，將TCP/UDP數據封裝到ICMP的ping數據包中從而穿過防火牆。
Icmpsh
Icmpsh使用簡單，跨平臺，運行時不須要管理員權限，在運行時會代替系統自己ping命令的應答程序。
流量分析
剛創建鏈接時是靶機不斷髮送icmp的請求包，區別於正常的icmp包，icmpsh的iIdentifier字段（至關於ping的進程號，winXP是0002）是默認寫死的0001。
正常的icmp數據包中的data字段應該是固定的，因爲icmpsh會進行傳輸數據和回顯數據因此date字段長度是不固定的。
icmptunnel
icmptunnel 能夠將 IP 流量封裝進 IMCP 的 ping 數據包中，旨在利用 ping 穿透防火牆的檢測。
對於隧道數據，icmptunnel 首先會指定客戶端和服務器端。隨後，客戶端會將 IP 幀封裝在 ICMP 請求數據包中發送給服務器，而服務器端則會使用相匹配的 ICMP 響應數據包進行回覆（icmptunnel 提供在狀態機防火牆和 NAT 網絡之間，更加可靠的鏈接）。
流量分析
能夠發如今每條請求包或者響應包中的date字段中都帶有TUNL標識。
一個正常的ping命令每秒最多發送兩個數據包，而使用ICMP隧道則會在很短期內產生上千個ICMP數據包，能夠檢測同一來源的ICMP數據包的數量。
記錄payload大於64bit的ICMP數據包（icmptunnel能夠控制payload長度不超過64bit）。
通常的ICMP數據包請求包和響應包中的payload字段應該相同，能夠經過對比payload字段來進行篩查。
檢查ICMP數據包中的協議標籤（如icmptunnel會在全部ICMP payload前面添加「TUNL」來標識隧道。）
本文分享自微信公衆號 - 小啦的學習筆記（woshiguolala）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。