此篇文章為轉載!
一、DNS服務器的重要性
DNS是因特網建設的基礎,幾乎所有的網絡應用,都必須依賴DNS系統做網址查詢的指引動作。如果DNS系統運作不正常,即使Web服務器都完好如初,防火墻系統都善盡其職,相關的后端應用服務器以及數據庫系統運作正常,因為無法在期限時間內查得到網址,將會導致電子郵件無法傳遞,想要使用網域名稱去連接某個網頁,也會因查不出網絡地址,以致聯機失敗。2001年1月24日,美國微軟公司所管理的相關網絡系統,遭受網絡黑客的拒絕服務攻擊后導致全球各地的用戶接近24小時的時間無法連上該公司相關的網站,造成該公司相當嚴重的商業損失。根據以往的經驗之中,網絡攻擊的對象多數主要集中在控制網絡路由的設備(路由器,防火墻等)和各類應用服務器(Web、郵件等)。因此,目前多數的網絡系統安全保護,通常都集中在路由設備和應用服務器本身。然而,這一次的微軟公司被攻擊事件,與以往其它網站攻擊事件的最大不同,就在于這一次被攻擊的對象是DNS服務器而不是WEB服務器本身。這次的事件宣告另一種新型的網絡攻擊類別,往后將可能成為常態。
互聯網上DNS服務器的事實標準就是ISC(http://www.isc.org/ )公司的Berkeley Internert Name Domain(BIND),它具有廣泛的使用基礎,互聯網上的絕大多數DNS服務器都是基于這個軟件的。Netcraft在域名服務器上的統計(http://www.netcraft.com/ )顯示 2003年第二季度進行的一個調查發現,在互聯網上運行著的DNS服務器中,ISC的BIND占據了95%的市場份額。互聯網是由很多不可見的基礎構件組成。這其中就包含了DNS,它給用戶提供了易于記憶的機器名稱(比如sina.com),并且將它們翻譯成數字地址的形式。對于那些用于公共服務的機器一般還提供“反向查詢”的功能,這種功能可以把數字轉換成名字。由于歷史的原因,這種功能使用的是被隱藏的“in-addr.arpa”域。對in-addr域的調查,可以讓我們更加了解整個Internet是如何運作的。Bill Manning對in-addr域的調查發現,有95%的域名服務器(2的2000次方個服務器中)使用的是各種版本的“bind”。這其中包括了所有的DNS根服務器,而這些根服務器對整個服務器的正常運轉起著至關重要的作用。如何能加強確保 DNS 系統的運作正常, 或者當DNS系統在遭受網絡攻擊時候, 能夠讓管理者及早發現是日益重要的系統安全的課題。首先我們要了解DNS服務面臨的安全問題。
二、DNS服務面臨的安全問題:
DNS服務面臨的安全問題主要包括:DNS欺騙(DNS Spoffing)、拒絕服務(Denial of service,DoS)攻擊、分布式拒絕服務攻擊和緩沖區漏洞溢出攻擊(Buffer Overflow)。
1、DNS欺騙
DNS欺騙即域名信息欺騙是最常見的DNS安全問題。當一個DNS服務器掉入陷阱,使用了來自一個惡意DNS服務器的錯誤信息,那么該DNS服務器就被欺騙了。DNS欺騙會使那些易受攻擊的DNS服務器產生許多安全問題,例如:將用戶引導到錯誤的互聯網站點,或者發送一個電子郵件到一個未經授權的郵件服務器。網絡攻擊者通常通過三種方法進行DNS欺騙。圖1是一個典型的DNS欺騙的示意圖。

圖1 典型DNS欺騙過程
(1)緩存感染
黑客會熟練的使用DNS請求,將數據放入一個沒有設防的DNS服務器的緩存當中。這些緩存信息會在客戶進行DNS訪問時返回給客戶,從而將客戶引導到入侵者所設置的運行木馬的Web服務器或郵件服務器上,然后黑客從這些服務器上獲取用戶信息。
(2)DNS信息劫持
入侵者通過監聽客戶端和DNS服務器的對話,通過猜測服務器響應給客戶端的DNS查詢ID。每個DNS報文包括一個相關聯的16位ID號,DNS服務器根據這個ID號獲取請求源位置。黑客在DNS服務器之前將虛假的響應交給用戶,從而欺騙客戶端去訪問惡意的網站。
(3)DNS復位定向
攻擊者能夠將DNS名稱查詢復位向到惡意DNS服務器。這樣攻擊者可以獲得DNS服務器的寫權限。
2、拒絕服務攻擊
黑客主要利用一些DNS軟件的漏洞,如在BIND 9版本(版本9.2.0以前的 9系列)如果有人向運行BIND的設備發送特定的DNS數據包請求,BIND就會自動關閉。攻擊者只能使BIND關閉,而無法在服務器上執行任意命令。如果得不到DNS服務,那么就會產生一場災難:由于網址不能解析為IP地址,用戶將無方訪問互聯網。這樣,DNS產生的問題就好像是互聯網本身所產生的問題,這將導致大量的混亂。
3、分布式拒絕服務攻擊
DDOS 攻擊通過使用攻擊者控制的幾十臺或幾百臺計算機攻擊一臺主機,使得服務拒絕攻擊更難以防范:使服務拒絕攻擊更難以通過阻塞單一攻擊源主機的數據流,來防范服務拒絕攻擊。Syn Flood是針對DNS服務器最常見的分布式拒絕服務攻擊。
4、緩沖區漏洞
Bind軟件的缺省設置是允許主機間進行區域傳輸(zone transfer)。區域傳輸主要用于主域名服務器與輔域名服務器之間的數據同步,使輔域名服務器可以從主域名服務器獲得新的數據信息。一旦起用區域傳輸而不做任何限制,很可能會造成信息泄漏,黑客將可以獲得整個授權區域內的所有主機的信息,判斷主機功能及安全性,從中發現目標進行攻擊。
應對以上這些安全問題有兩個比較有效方法:TSIG和DNSSEC技術。
二、TSIG技術
DNS的事務簽名分為 TSIG (Transaction Signatures) 與 SIG0 (SIGnature)兩種。該如何選擇呢? 首先,要先判斷客戶端與服務器間的信任關系為何,若是可信任者,可選擇對稱式的 TSIG。TSIG 只有一組密碼,并無公開/私密金鑰之分;若是非完全信任者,可選擇非對稱式金鑰的 SIG0,雖有公開/私密金鑰之分,相對的,設定上也較復雜。至于要選用哪種較適合,就由自己來判斷。通常區帶傳輸是主域名服務器到輔助域名服務器。通常在主域名服務器配置文件/etc/named.conf的dns-ip-list的訪問控制列表(ACL,access control list)會列出一些IP地址,它們只能為主域進行傳輸區帶信息。一個典型例子如下:
以下為引用的內容:
acl “dns-ip-list” {
172.20.15.100;
172.20.15.123;
};
zone “yourdomain.com” {
type master;
file “mydomain.dns”;
allow-query { any; };
allow-update { none; };
allow-transfer { dns-ip-list; }; };
都是黑客會利用IP欺騙一個DNS服務器,迫使其進行非法區帶傳輸。TSIG技術可以進行有效防范。
1、TSIG技術
交易簽章 (TSIGRFC 2845),是為了保護 DNS安全而發展的。從BIND 8.2版本開始引入 TSIG 機制,其驗證 DNS 訊息方式是使用共享金鑰(Secret Key) 及單向雜湊函式(One-way hash function) 來提供訊息的驗證和數據的完整性。主要針對區帶傳輸(ZONE Transfer)進行保護的作用,利用密碼學編碼方式為通訊傳輸信息加密以保證 DNS 訊息的安全,特別是響應與更新的訊息數據。也就是說在DNS服務器之間進行轄區傳送時所提供保護的機制,以確保傳輸數據不被竊取及監聽。下面以BIND 9.21為例:
首先在開始設置,必須為主域名服務器(master DNS)和輔助域名( slave DNS) 進行時間同步,否則會造成區帶傳輸的失敗。可以使用ntp或者rdate工具進行服務器時間同步。
假設要限制yourdomain.com的主域到IP地址分別是172.20.15.100 (ns1.yourdomain. com) 和 172.20.15.123 (ns2.yourdomain.com). 的兩個輔助域名服務器之間進行區帶傳輸。在此將詳述 TSIG 的實際操作,可以防止DNS服務器和黑客的DNS服務器之間不會發生IP欺騙。
步驟一:執行 dnssec-keygen function 產生加密金鑰,一個為 public key 文件,另一個為 private key 文件:
產生加密金鑰:
dnssec-keygen -a hmac-md5 -b 128 -n HOST zone-xfr-key
該文件中公開金鑰(public key)是: Kzone-xfr-key.+157+08825.key;私有金鑰(private key)是Kzone-xfr-key.+157+08825.private。此時查看文件通常包括以下內容:
以下為引用的內容:
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: YH8Onz5x0/twQnvYPyh1qg==
步驟二:使用TSIG 金鑰在主域名服務器和輔助域名服務器的設置文件named.conf設定:
以下為引用的內容:
key zone-xfr-key {
algorithm hmac-md5;
secret “YH8Onz5x0/twQnvYPyh1qg==”;
};
步驟三:將下面的聲明加入服務器ns1.yourdomain.com的設置文件/etc/named.conf中:
以下為引用的內容:
server 172.20.15.123 {
keys { zone-xfr-key; };
};
步驟四:將下面的聲明加入服務器ns2.yourdomain.com的設置文件/etc/named.conf中:
以下為引用的內容:
server 172.20.15.100 {
keys { zone-xfr-key; };
};
步驟五:為主域名服務器ns1.yourdomain.com的yourdomain.com區帶的設置文件/etc/named.conf寫入以下配置:
以下為引用的內容:
acl “dns-ip-list” {
172.20.15.100;
172.20.15.123;
};
key zone-xfr-key {
algorithm hmac-md5;
secret “YH8Onz5x0/twQnvYPyh1qg==”;
};
server 172.20.15.123 {
keys { zone-xfr-key; };
};
zone “yourdomain.com” {
type master;
file “mydomain.dns”;
allow-query { any; };
allow-update { none; };
allow-transfer { dns-ip-list; };
};
步驟六:為輔助域名服務器ns2.yourdomain.com的yourdomain.com區帶的設置文件/etc/named.conf寫入以下配置:
以下為引用的內容:
acl “dns-ip-list” {
172.20.15.100;
172.20.15.123;
};
key zone-xfr-key {
algorithm hmac-md5;
secret “YH8Onz5x0/twQnvYPyh1qg==”;
};
server 172.20.15.100 {
keys { zone-xfr-key; };
};
zone “yourdomain.com” {
type master;
file “mydomain.dns”;
allow-query { any; };
allow-update { none; };
allow-transfer { dns-ip-list; };
};
步驟七:再次重新啟動主域名服務器和輔助域名服務器。
說明為確保安全性的問題,TSIG 可確認 DNS 之信息是由某特定 DNS Server 所提供。通常TSIG 應用于域名服務器間的區帶傳輸,確保數據不會被篡改或產生 dns spoofing。
步驟八:
驗證TSIG技術是否生效,步驟如下:
刪除輔助域名服務器(ns2.yourdomain.com)的區帶文件。
重新啟動輔助域名服務器。
檢查輔助域名服務器的區帶文件是否自動建立。輔助域名服務器用來從主服務器中轉移一整套域信息。區帶文件是從主服務器轉移出的,作為磁盤文件保存在輔助域名服務器中。
注意事項:如果為域名服務器配置了TSIG,那么要確保普通用戶不能接觸主域名服務器和輔助域名服務器的配置文件/etc/named.conf。另外也不能修改兩臺服務器的共享的TSIG密鑰。
2、SIG0 技術簡介
SIG0是一九九九年三月 由 IBM公司的D. Eastlake 提出成為標準。其是利用公開金鑰機制為轄區資料進行數字簽章的動作,以保證每筆傳輸的 source record 具有可驗證性與不可否認性。實際上 SIG0 才是防止 DNS Spoofing 發生最主要的技術,SIG0 是使用公開金鑰加密法,讓轄區管理者為其轄區數據加上數字簽章,由此證明轄區資料的可信賴性。除此之外,SIG0 保有是否選擇認證機制的彈性,以及可靈活地配合自訂的安全機制。
三、DNSSEC技術
DNS欺騙是對目前網絡應用,最大的沖擊在于冒名者借著提供假的網域名稱與網址的對照信息,可以將不知情用戶的網頁聯機,導引到錯誤的網站,原本屬于用戶的電子郵件也可能因而遺失,甚而進一步空開成為阻斷服務的攻擊。所幸,目前較新的 BIND 版本,針對這一類問題,已經有加入許多改進的方法,不過真正的解決方案,則有賴封包認證機制的建立與推動。DNSSEC就是試圖解決這一類問題的全新機制, BIND9 已經完整加以設計并完成。DNSSEC引入兩個全新的資源記錄類型:KEY和SIG,允許客戶端和域名服務器對任何DNS數據的來源進行密碼驗證。
DNSSEC主要依靠公鑰技術對于包含在DNS中的信息創建密碼簽名。密碼簽名通過計算出一個密碼hash數來提供DNS中數據的完整性,并將該hash 數封裝進行保護。私/公鑰對中的私鑰用來封裝hash數,然后可以用公鑰把hash數譯出來。如果這個譯出的hash值匹配接收者剛剛計算出來的hash樹,那么表明數據是完整的。不管譯出來的hash數和計算出來的hash數是否匹配,對于密碼簽名這種認證方式都是絕對正確的,因為公鑰僅僅用于解密合法的hash數,所以只有擁有私鑰的擁有者可以加密這些信息。下面我們看看如何為名稱是domain.com的域建立DESSEC配置。
步驟一:為 domain.com 域建立一對密鑰。在 /var/named 目錄下,使用命令: “/usr/local/sbin/dnssec-keygen -a DSA -b 768 -n ZONE domain.com” 這個命令產生一對長度768位DSA算法的私有密鑰(Kdomain.com.+003+29462.private)和公共密鑰(Kdomain.com.+003+29462.key)。其中29462稱作密鑰標簽( key tag)。
步驟二:使用命令:“ /usr/local/sbin/dnssec-makekeyset -t 3600 -e now+30 Kdomain.com.+003+29462“建立一個密鑰集合。該命令以3,600 seconds 的生存時間(time-to-live)建立密鑰集合,有效期限三十天,并且創建一個文件:domain.com.keyset。
步驟三:使用命令“ /usr/local/sbin/dnssec-signkey domain.com.keyset Kdomain.com.+003+29462 “為密鑰集合簽字。然后建立一個簽字文件:domain.com.signedkey。
步驟四:使用命令 “/usr/local/sbin/dnssec-signzone -o domain.com domain.db command, where domain.db ”為區帶文件簽字。然后建立一個簽字文件: domain.db.signed。
步驟五:替換 配置文件/etc/named.conf中 domain.com的區帶文件部分。清單如下:
以下為引用的內容:
zone “domain.com” IN {
type master;
file “domain.db.signed”;
allow-update { none; }; };
從上面的配置過程我們也看到DNSSEC的一些缺點:
除了配置負責,還有標記和校驗DNS數據顯然會產生額外的開銷,從而影響網絡和服務器的性能。簽名的數據量很大,這就加重了域名服務器對互聯網骨干以及一些非骨干連接的負擔。產生和校驗簽名也占用了很多中央處理器的時間。有時候,不得不把單處理器的DNS服務器換成多處理器的DNSSEC服務器。簽名和密鑰占用的磁盤空間和RAM容量達到它們表示的數據所占容量的10倍。同時數據庫和管理系統也不得不進行相應的升級和擴容。
總結:域名系統的配置和管理是一項比較復雜和繁瑣的系統管理任務,它對整個網絡的運行影響極大。為了保證DNS服務器的安全運行,不僅要使用可靠的服務器軟件版本,而且要對DNS服務器進行安全配置,本文介紹了TISG和DNSSEC技術有助于減少 DNS Spoofing 攻擊的發生,增進網絡使用者對因特網使用的信任,杜絕信息系統遭受入侵與攻擊的產生。