觀點

Windows 2000 技術論壇

2005 / 03 / 01
廖邦彥
Windows 2000  技術論壇

為何要保護DNS?
http://searchwin2000.techtarget.com/tip/1,289483,sid1_gci991415,00.html AD (Active Directory) 很多的功能都靠DNS(Domain Name System) 來做到,像是決定網域控制器的位置、系統、服務、使用者,以及其他物件;大家應該可以很明顯地感覺到保護DNS幾乎跟保護AD 一樣重要了。

可能有些人會覺得在保護DNS上所花的時間、金錢跟努力會不如花在保護AD上來的有保障,如果是這樣的話,請考慮以下事件 :
AD以及DNS是在分散式的環境下運作。數台伺服器掌管這些服務還有服務彼此之間的溝通,並且資訊環境讓這些伺服器提供網路上最重要的服務(也就是目錄服務以及名稱解析)。這樣子就解決了只仰賴單一點提供服務的問題,有效提供共享資源,並且能夠配合公司組織架構來進行這些服務的架構規劃。

然而,這種分散式的架構提供了攻擊者很多的方法來影響正常的運作,甚至不只是攻擊者,這樣的架構也會導致如以下列出服務誤用的情況:
●DNS伺服器之間的通訊可能會中斷
●DNS伺服器之間的通訊可能會被阻隔
●DNS的資料庫可能會毀損
●DNS的資料庫可能會因被故意的放入錯誤資料而被”污染”
●DNS伺服器可能會被停用或者關機
●DNS伺服器可能會成為阻斷式攻擊的目標
●DNS伺服器的實體連線可能會被破壞
如果任何一種以上的攻擊或者非預期的情況發生,可能會造成客戶與網域伺服器對非授權的DNS 伺服器進行溝通,或者更直接的就是使得客戶與網域伺服器無法找到對方並溝通。

如果要建立一個真正安全的網路環境,以保護DNS 來對AD 網域控制器提供多一層的保護是很重要的,以下我會陸續談到一些技巧來改善DNS 的安全性與可靠性。

Part 1
http://searchwin2000.techtarget.com/tip/1,289483,sid1_gci992363,00.html

保護DNS伺服器
前面我們已經提到,如果你的DNS 架構被損壞或者被攻擊,你的整個AD 架構也有可能會跟著DNS 一起損壞。保護你的DNS伺服器需要採取多方進行的方式。現在就為你的DNS伺服器設計一套與你的 AD 網域控制器相同安全等級的規劃、實施跟佈署步驟,這也是最重要的。

接下來,試著實施與DNS伺服器間的安全通訊,監控所有網路流量,和重新評估你防火牆上打開的端口。

藉著加密所有在DNS伺服器與全部DNS用戶之間的通訊(不只是用戶端的客戶,還有AD 網域控制器和其他伺服器),將會減少或者是消除資料被截取與被竄改的機會。其中一個最好的辦法就是透過 IPSec來實施。除了資料傳輸的加密之外,IPSec一個最大的好處就是在DNS資料流通被許可之前,藉由一個公開金鑰基礎架構 (PKI)為溝通的兩端,提供雙向認證 (也就是DNS伺服器與DNS客戶)。要實施這個計畫,所有的 DNS 伺服器都將需要實施強制的IPSec 群組原則,所有的DNS客戶端也都需要有一個客戶端IPSec 群組原則。這樣一來,所有DNS的溝通將會受到 IPSec的保護,可是不屬於DNS的溝通 (或者跟沒有管理任何DNS伺服器的溝通)都將不會受到IPSec的保護。

全面實施針對所有系統的IPSec,會因為加密與解碼所需要的額外通訊,而大大降低網路通訊的效能。然而,所提高的安全性對於輸貫量稍稍減少的補償應該算是划得來的。 在下一部分,我將會討論另外兩個在 AD網域上增加DNS 安全性的方式。

Part2
http://searchwin2000.techtarget.com/tip/1,289483,sid1_gci993767,00.html

保護DNS就要增強AD安全性
我們已經討論過,為你的DNS系統提供多一層保護的終極目標,就是增強AD的安全性。第一個考量就是要求所有跟DNS伺服器之間的通訊皆需經過加密。接下來兩個考量,分別是網路流量的監控跟防火牆開放埠的重新評估。

在監控網路流量的時候,當有不合法或異常的資料傳輸模式開始進入你網路的時候,你應該能馬上察覺。你必須選擇是要展開即時偵測或是仰賴事件紀錄(historical reviews)來監測攻擊,即時偵測將需要有一個能主動偵測攻擊的自動化 IDS系統或者是稽核掃描系統。事件紀錄則是重新檢視DNS封包或是稽核事件的紀錄檔,第一個提出的方法是較被推薦的,不過花費也較高。第二個方法,只能在事件後提供,既不即時也不具預防性的偵測。

不論你選擇哪一個監測的方法,都要小心注意特殊針對DNS的拒絕服務 (DoS)攻擊,DNS系統大量流量攻擊(flooding),嘗試污染DNS資料的攻擊,異常大量的資料傳輸量,單一主機間不尋常的資料傳輸量,和單一型態協定的異常流量 (TCP 的子協定,像是服務協定或是應用協定)。

如果你沒有使用防火牆來保護你的網路的話,你現在就有比增加DNS安全性更重要的事情需要處理了。當在防火牆上處理DNS流量時,要留意DNS查詢把FQDN解析成IP位址和 DNS伺服器之間的通訊(像是zone transfers)都是經由 UDP port 53。這個埠應該要被阻隔、停用或是關閉除非有以下情形:
●Zone transfers一定要經過防火牆
●在防火牆另一區有一台DNS 負責一個授權的zone
●DNS客戶與DNS伺服器通過防火牆來進行溝通
●DNS轉發者一定要經過防火牆,來跟在DNS名稱空間(namespace)裡較高階的
●DNS伺服器溝通

一但DNS資料傳輸受到保護,就可以開始確認DNS資料本身的安全性。而這就是下一個內容的重點。

Part 3
http://searchwin2000.techtarget.com/tip/1,289483,sid1_gci996455,00.html

杜絕不當遠端存取強化DNS安全
目前為止,我們已經討論過以杜絕DNS不必要的遠端存取來加強DNS的安全性。然而,就算是作了所有我提出的建議事項,你的DNS伺服器還是很有可能會被惡意使用者試圖取得伺服器的管理權限。如果這種情形發生的話,你就必須仰賴DNS內部的安全機制,包括:

●保護動態更新 (Secure dynamic updates)
●DNS資源紀錄註冊配額設定 (DNS resource record registration quotas )
●DNS 管理分權 (Delegate DNS administration)
●使用安全的路由 (Use secured routing)
●將DNS名稱空間拆開來進行維護 (Maintain a split DNS namespace)
●停用遞迴 (Disable recursion)
很顯然的,如果你沒有辦法信任你的管理者,那跟DNS被遠端攻擊的問題比起來,你就有更嚴重的事情等著去處理了。你要先處理你們內部管理的問題才行。不過如果你的管理者是可以被信賴的,而且他們也很努力地在主動維護整個企業的安全架構,而這六個DNS的安全機制就可以加強你的最後安全防線。以下分別是每一個DNS安全機制改善方式的詳細說明。

保護動態更新,是一個需要使用者先提供身分認證並且被系統許可,他們才可以更改與更新,或是輸入DNS資料的安全機制。這個安全機制對錯誤的登入資訊不會有任何回應,所以可以避免沒有被認可的使用者竄改破壞DNS系統的資料。如果沒有保護動態更新的話,駭客可以在zone檔案中輸入錯誤的資料。如果zone檔案的資料被損毀,那依據錯誤的域名解析傳送的資料也是錯誤的。而這同時也有利於拒絕服務(DoS)的攻擊,駭客可以一直傳送一連串不間斷的錯誤訊息,到最後用盡儲存空間並影響zone 的複製。

不過還好保護動態更新是Windows 2000 Server和 Window Server 2003 DNS 系統的預設值。可是,你還是要確定這個功能並沒有被停止。

DNS資源紀錄註冊配額設定可以限制一個使用者或是一個階段所允許的DNS登入次數,所以可以減少DoS的攻擊。通常把應用程式註冊和網域目錄的次數限制在10次以下,可以有效減少DoS的攻擊。領域控制器或是其他種類的伺服器有可能需要更大的配額,像是300次 或是400次,來讓他們可以毫無阻礙的運行。因為DHCP伺服器是負責DNS的資源紀錄的註冊,所以他們不應該有最大登入次數的限制。可以利用命令模式工具像是 dsadd、dsmod和 dsquery 來更改配額的限制。如果想要查詢這些指令的詳細資料,在 Help 和 Support Center 中以關鍵字輸入 dsadd,dsmod和 dsquery 來取得詳細資料。以下我將會討論DNS的其他安全機制。

Part 4
http://searchwin2000.techtarget.com/tip/0,289483,sid1_gci998996,00.html?track=NL-23&ad=488864

管理分權和路由使用的設定
在前面的文章裡,我已經討論過以下 DNS 安全機制的前兩點 :
●保護動態更新 (Secure dynamic updates)
●DNS資源紀錄註冊配額設定 (DNS resource record registration quotas )
●DNS 管理分權 (Delegate DNS administration)
●使用安全的路由 (Use secured routing)
●將DNS名稱空間拆開來進行維護 (Maintain a split DNS namespace)
●停用遞迴 (Disable recursion)

接下來,兩個改良DNS安全性的方法就是DNS管理分權和使用安全的路由。 用來儲存DNS資訊的zone 容器具有預先定義的存取限制。你應該要先檢查這些容器上面的 ACLs 的目前佈署的情況,來確保他們能為你的環境提供最安全的保護。使用者對zone資訊只有讀的權利。在預設的情況下,只有在本機的管理者,以及在AD內的網域管理者(Domain Admins),企業管理者(Enterprise Admins)和DNS管理者(DNS Admins)對所有的 DNS物件具有完全的存取權;其他的使用者皆預設為只有讀的權利。

另外一個值得考慮的事情是使用安全的路由。你可以透過不同的路由來傳送請求給DNS伺服器,有可能用條件來選擇傳送路由、從secondary zone傳送,或是從 root hint傳送。依據你網路中DNS伺服器跟防火牆不同的配置方法,就有不同的傳送設定方法。

當兩個被不同DNS伺服器所管理的AD名稱空間被防火牆給隔開的時候,只需要許可對當作正向傳送的DNS伺服器的存取權就可以了。不然的話,如果子名稱空間(secondary zones)或是授權委任空間(delegated zones)是架構在跨防火牆使用,雙向的DNS溝通就都必須開啟了。

在子名稱空間(secondary zones)跟DNS查詢轉送(forwarding)之間作選擇並不容易。名稱空間(secondary zones)的資訊並不是儲存在AD裡。相反的,它是儲存在文字檔案裡。這使得子名稱空間設定很容易遭受攻擊。Forwarding並沒有把資料儲存在文件檔案裡,可是它卻會增加你網路上名稱解析的流量。DNS查詢轉送者同時也減低整個DNS架構容錯的程度。這個容錯程度降低的原因是因為你會依賴並沒有包含具有DNS資料的DNS查詢轉送者,而不是依賴可以提供DNS備份資料的DNS伺服器。還有,DNS查詢轉送者不會利用暫存資料回答DNS 查詢。如果那個被查詢的DNS伺服器沒有在線上或是無法聯繫的話,轉送同樣也會失敗。

如果你內部有一個主DNS,那麼就設定所有的DNS伺服器的 root hint 都指向你內部的主DNS。千萬不要讓它們指向位於公共網路的主DNS伺服器。不然的話,當用外部的DNS來進行域名解析的時候,你環境的資料就會被傳送到外部網路。