中場休息完畢，今天來探討一個應用題：如果公司企業網路環境中的IPS偵測到有惡意的DNS查詢，前往C2 Server或是勒索軟體網站，仔細研究IPS警示資訊後發現惡意DNS查詢封包的來源IP竟然是公司內部的DNS伺服器，該怎麼辦？難道是DNS伺服器中毒、被入侵了嗎？

通常不是的，因為公司網路環境內DNS伺服器和IPS的位置，當用戶端電腦發出DNS查詢，向DNS伺服器查詢，迴遞DNS伺服器在快取中找不到查詢目標，它會向網際網路的主要根源名稱主機重複該查詢並依循來自權威伺服器的轉介進行詢問，直到找到能回應查詢的名稱伺服器。以下面範例公司網路示意圖為例，D區的用戶端電腦發出DNS查詢，E區的DNS伺服器在快取內找不到查詢目標，便往外向主要根源名稱主機重複查詢，當IPS看到這個向外往主要根源名稱主機的查詢，發現是前往惡意網站或者C2 Server，便會發出警示，因為IPS只看到向外往主要根源名稱主機的查詢，所以來源IP會是公司內的DNS伺服器。那我們要怎麼找到真正的來源IP呢？

*範例公司網路環境示意圖

檢視DNS Log日誌

熟悉日誌分析的老手，通常馬上會想到要檢視DNS伺服器上的log日誌，DNS Log確實能提供我們所需的資料，運用SIEM﹝Security Information and Event Management安全資訊事件管理系統﹞可以簡化分析的過程，藉由比對IPS警示資料和DNS Log，找出惡意DNS查詢的原始來源IP。但是DNS Log有時候可不是那麼容易取得，為什麼呢？

首先，DNS Log預設是沒有開啟的，算是一種debug的手段要另外設定，而且還要考慮開啟DNS Log會耗用資源的問題，Microsoft官方文章上警告對於DNS伺服器的效能和資源有所影響，很多網管對於Windows Server 2012 R2之前版本的伺服器如Windows 2008幾乎是不願意開啟DNS Logging ，即使是Windows Server 2012 R2之後的伺服器對於DNS Logging效能問題已經有改善，安裝Hotfix後可以開啟DNS Logging and Analytic，如果常態一直維持DNS Logging，很多網管人員也不一定同意，尤其是為了資安分析需要在每一台DNS伺服器都開啟DNS Logging，如果公司規模較大，上班時間每秒DNS查詢很多，效能的問題更需要考慮。

再者，一般SIEM會吃/讀取Windows主機log的位置多半是主要的三個Application、Security、System日誌，但是DNS Log儲存的位置隨伺服器版本會不同，都不在三個主要日誌內，SIEM讀取log 的能力和如何設定也是一個考驗。

移動IPS位置

既然看不到流量，那麼山不來，我們就往山過去吧？改變IPS佈署的位置，無論是改換TAP位置或運用SPAN、RSPAN等方法，讓IPS能直接看到D區用戶端電腦發出DNS查詢的網路流量，就可以比對IPS的惡意DNS查詢警示資料，找出真實來源IP位置；或是不移動IPS，另外佈署NSM平台監控從D區用戶端電腦發出DNS查詢的網路流量。

網路安全監控NSM

現在次世代防火牆NGFW和UTM蔚為主流，若IPS就是和防火牆綁在一起，或是UTM本身，位在公司網路最邊緣，無法移動IPS位置怎麼辦？

*網路截圖自VMWare Blog

這種情況下，我們可以另外佈署一個輕量的NSM，專門監控、分析DNS流量進行分析，或將資料傳回SIEM與IPS警示資料比對。以範例公司網路為例，DNS伺服器為虛擬主機上的VM，我們可以在vSwitch設置Port Mirroring/SPAN，專門監控DNS伺服器流量。