公有云DNS隱藏隧道通訊檢測實踐
0x00、業務需求
伴隨著公有云大規模在現代商業數字化轉型中的應用，上雲後針對於底層的資料無法獲取，導致傳統安全策略無法部署等雲安全問題一直困擾的CSO們，從公有云雲安全責任共擔模型上看，這就需要公有云提供更強有力的底層安全檢測能力。當我們已經把傳統的網路入侵檢測引擎、威脅情報以及動態行為檢測都部署上的時候，我們發現還是有很多雲主機中招，而且在持續的洩密，那麼，經過hunting Team分析後，我們發現80%高階的入侵手段是通過隱藏隧道方式。而這裡使用最多的就是DNS隱藏隧道。
0x01、DNS隱藏隧道的前世今生
1.DNS協議介紹
大家可以上圖流程，瞭解一下DNS請求的流程。當然也可以知道搭建DNS隧道伺服器的物理位置。您需要一個域名、一個域名伺服器（gsgsoft.com）來承載該域名的名稱解析（一個“真正的DNS伺服器”），以及一個假DNS伺服器來使用人工DNS查詢和響應通過隱蔽通道與客戶機通訊。
2.DNS隧道原理
DNS隧道是一種濫用域名系統（DNS）將另一個協議的資料編碼為一系列DNS查詢和響應訊息的技術，DNS隧道在黑客世界中主要使用DNS隧道作為命令和控制（C&C），同時竊取隱私資料。
（1）黑客大規模應用的技術優勢
·DNS無處不在
防火牆允許DNS流量在兩個方向上傳遞，並且DNS流量混雜在必須開放的正常流量中，傳統的安全手段很難發現，因此DNS隱蔽通道對於繞過這些訪問控制非常有用。
·DNS隧道的效能比較好
如果你使用DNS隧道傳輸資料，可以達到800k/s.延時低等特徵。
·黑客基礎設施建設成本低
一臺vps
一個域名控制權限
一臺雲主機肉雞許可權
使用開源dnscat2 https://github.com/iagox86/dnscat2
（2）DNS隧道傳輸技術原理
試圖隱藏C＆C流量，以避免檢測。通常，殭屍網路的C&C設計會導致訊息被混淆或加密，從而更難檢測和理解某些型別的C&C流量的語義。
惡意軟體使用有效的DNS語法通訊。它的C＆C訊息很有可能由具有TXT資源記錄的DNS訊息組成。此外，查詢域名用於將某些引數從bot傳輸到C&C伺服器，例如用於金鑰派生的引數。
·檢測手段
（3）傳統安全檢測手段無效
·IDS規則無法檢測
傳統的入侵檢測引擎的對外可疑連線和惡意軟體行為檢測規則是無法檢測到這類威脅
#alert udp $HOME_NET any -> $EXTERNAL_NET 53 (msg:"ET POLICY nstx DNS Tunnel Outbound"; content:"cT"; offset:12; depth:3; content:"|00 10 00 01 00 00 29 08|"; within:255; reference:url,savannah.nongnu.org/projects/nstx/; reference:url,nstx.dereference.de/nstx; reference:url,doc.emergingthreats.net/2002676; classtype:bad-unknown; sid:2002676; rev:3; metadata:created_at 2010_07_30, updated_at 2010_07_30;)
·統計學分析方法
使用基線分析方法做統計，發現傳輸異常的情況，但是如果黑客不大規模傳輸資料的話，是無法發現異常的。
（4）機器學習手段的瓶頸
·傳統機器學習演算法
通常DNS異常檢測是一個二分類的問題，
·誤報挑戰
DNS隧道將二進位制資料編碼為ASCII格式，然後在DNS查詢中作為域名進行傳輸。從編碼的二進位制資料生成的這種域名具有高熵。此外，為了實現高頻寬，DNS隧道對每個分組中最大可能的二進位制資料塊進行編碼，從而產生大的DNS分組。因此，給定來自DNS隧道的DNS流量流，可以觀察到註冊域下的大量長子域，每個子域具有高熵。高熵，大量子域和大資料包大小似乎是DNS隧道的可靠指標。但是這種方法現在產生了無法控制的誤報量。
其中一個主要原因是公有云CDN網路有可能和公有云共有一個機房，傳輸流量混雜在一起。考慮託管在大型CDN上的域。內容傳遞機制通常通過為每個託管客戶域建立CNAME記錄（即別名）來工作，以獲得CDN域的唯一的，通常是隨機的子域。給誤報增加了可能性。
0x02、公有云檢測架構&實現方式
為了降低運營成本，一般來說CDN網路和公有云網路會同時使用一套網路環境，這種情況要求我們的DNS隧道分類問題，要能識別CDN網路中 CNAME的流量（通常都是隨機別名），但是這種是正常流量，也就是說我們需要把機器學習分類問題變成三分類：惡意DNS流量、CDN流量、普通正常DNS流量。
解決方案邏輯圖
根據以上的邏輯圖，大家可以清楚的瞭解公有云機房DNS資料流轉情況，主要有DNS解析通道：
@1、當用戶預設使用公有云DNS伺服器的時候，DNS解析路徑為：雲主機->VPC網路NAT轉換->DNS伺服器->通過AZ的虛擬路由轉換->到POP點->出公網
@2、當用戶指定外網DNS伺服器的時候，DNS解析路徑：雲主機->VPC網路-floatingIP->通過AZ的虛擬路由轉換->到POP點->出公網，也就是說這裡會經過我們的IDS探針。
針對這兩種情況，我們需要兩種解決方案：
@1、需要在預設DNS解析伺服器上對DNS資料包劫持做機器學習檢測。
@2、需要在IDS探針中恢復DNS協議，並且抓取流量吐給kafka，使用spark MLlib實時檢測DNS解析流量。
·機器學習3分類實現
這部分，由於網上有很多成功的案例，我也不在這裡多說，思路還是：
樣本資料獲取
@1、在正常的DNS伺服器解析過程當中把cdn正常流量標記成cdn—label，
@2、在外網搭建DNS環境，把市面上的DNS隱藏隧道的程式跑一邊（例如:前面提到的dnscat2，當然還有很多。。。）black_label
@3、在上述兩個通道獲取正常DNS解析樣本，重點關注TXT、Cname。
訓練離線/線上模型（當然可以嘗試深度學習）
把預測模型載入到實時傳輸的資料量和離線的DNS服務上執行（根據誤報結果不斷調整特徵）
0x03、總結
應用到公有云的惡意DNS流量檢測解決方案，雖然環境複雜一些，但是檢測原理大致不會改變，只是要雙管齊下，如果模型再小點速度再快點，我們完全把它載入到雲主機EDR Agent中，省去網路層檢測的複雜度。