Sophos的ATP模組能在traffic透過XG做routing時,即時的過濾攔阻有害連線,
但在網域環境中,最頭痛的就是DNS Client的解析問題。
雖然惡意domain的DNS解析被XG的ATP攔下來了,
不過網域中client的DNS是指向內部的DNS Server,
當client欲連到惡意domain時,第一步的DNS解析工作會交給內部DNS Server來進行,
內部DNS Server沒有惡意domain的IP對應資訊,因此會再向上層DNS主機要求解析,
以至於ATP攔截事件中,攔的來源IP往往都是內部的DNS Server,而不是直正的DNS Client...
ATP事件中找不到真正的DNS Client,不是DNS Server的問題,也不是ATP的問題,
它們都有正常的執行交付的工作.這是網域架構中的限制。
那麼在網域架構下,究竟有沒有辦法揪出真正的DNS Client呢?
順子想到了一個做法,不過它需要DNS Server的配合。
既然DNS解析工作是由內部的DNS Server來進行,那麼我們就直接在DNS Server上建立一筆該惡意domain的IP對應record,
例如將惡意domain msdnupdate.com 對應到 10.199.199.2 這個內部環境中沒在使用的IP。
如何設定?Windows的DNS主機可以參考 這一篇 的做法。
然後在XG上啟用一個閒置介面,配置一個zone與這個假IP同網段的IP,例如 10.199.199.1/30,
接著在XG中建立內部到這個zone(或IP)的阻擋規則,並勾選log記錄,
這樣當內部電腦欲連到這個惡意domain時,DNS Server就會指向這個假IP,
而內部電腦依照DNS解析出來的結果,透過XG routing要連到這個假IP時,就會被XG上的阻擋規則所記錄下來,
這時我們只要去查看log,就可以清楚知道有哪些內部IP試圖連到這個惡意domain,揪出真正的DNS client!
為了避免連線被ATP所攔截,無法在阻擋的防火牆規則上留下記錄,
請將ATP改為僅記錄,但不阻擋的設定,
或是將這個惡意domain加到ATP的exception中,允許例外放行;
這樣連線才會進行,進而被阻擋規則攔阻,並在log中留下記錄。
另外,這個ATP陷阱在實做上有幾個重點要注意。
- XG上用來綁假IP的閒置網卡必需為up狀態,
這樣介面路由才會運作,導向假IP的traffic才會routing到這個介面,進而被防火牆規則阻擋而留下記錄。
若只是設定好IP資訊,但網卡介面為down,則介面routing不會生效。
網卡介面可以是一般網卡、VLAN或是Alias IP,
若使用Alias IP來設定,那封鎖記錄的防火牆規則需小心定義,以免連帶擋掉所有正常流量。
- 用來補抓DNS Client IP的防火牆規則必需是阻擋類型,
若採用放行規則,則該網卡介面必需真的接到一台設定假IP的主機才會留下記錄,
大大的增加複雜度。
♥順子老婆的網拍,請多關照∼
If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!
|