M8-1 加強Linux 系統(tǒng)的DNS 服務(wù)的安全防御能力1.1場景描述1.1.1 學(xué)習(xí)目的學(xué)生通過該能力模塊的學(xué)習(xí), 能夠獨立完成和熟練掌握安全配臵DNS 服務(wù)器，加強Linux 系統(tǒng)的DNS 服務(wù)

M8-1 加強Linux 系統(tǒng)的DNS 服務(wù)的安全防御能力

1.1場景描述

1.1.1 學(xué)習(xí)目的

學(xué)生通過該能力模塊的學(xué)習(xí), 能夠獨立完成和熟練掌握安全配臵DNS 服務(wù)器，加強Linux 系統(tǒng)的DNS 服務(wù)的安全防御能力。

1.1.2 學(xué)習(xí)要求

理解：DNS 服務(wù)存在安全風(fēng)險

掌握：DNS 服務(wù)安全選項配臵

掌握：DNS 服務(wù)TSIG 配臵

1.1.3 學(xué)習(xí)重點和難點

1. 學(xué)習(xí)重點

? 保護(hù)DNS 服務(wù)器本身安全

? 保護(hù) Zone Transfer 的安全

? 保護(hù) DNS 免于 Spoofed攻擊

? 使用 TSIG保護(hù)DNS 服務(wù)器

? 保護(hù)Dynamic Update的安全

2. 學(xué)習(xí)難點

? 使用 TSIG保護(hù)DNS 服務(wù)器

1.2 知識準(zhǔn)備

1.2.1 Zone Transfer

DNS 的區(qū)域傳輸目的是為了DNS 的備份，當(dāng)DNS 服務(wù)器壞了，它的數(shù)據(jù)不會丟失。注意在配臵區(qū)域傳輸是一定要注意輔助服務(wù)器上建立的區(qū)域是輔助區(qū)域且與主服

務(wù)器的域名相同，而且區(qū)域傳輸是雙向的，不但需要在輔助服務(wù)器上配臵還要在主服務(wù)器上進(jìn)行相應(yīng)的配臵。

1.2.2 DNS威脅

DNS 服務(wù)面臨的安全問題主要包括：DNS 欺騙（DNS Spoffing ）、拒絕服務(wù)（Denial of service，DoS ）攻擊、分布式拒絕服務(wù)攻擊和緩沖區(qū)漏洞溢出攻擊（Buffer Overflow ）。

1. DNS 欺騙

DNS 欺騙即域名信息欺騙是最常見的DNS 安全問題。當(dāng)一個DNS 服務(wù)器

掉入陷阱，使用了來自一個惡意DNS 服務(wù)器的錯誤信息，那么該DNS 服

務(wù)器就被欺騙了。DNS 欺騙會使那些易受攻擊的DNS 服務(wù)器產(chǎn)生許多安

全問題，例如：將用戶引導(dǎo)到錯誤的互聯(lián)網(wǎng)站點，或者發(fā)送一個電子郵

件到一個未經(jīng)授權(quán)的郵件服務(wù)器。網(wǎng)絡(luò)攻擊者通常通過三種方法進(jìn)行

DNS 欺騙。圖1是一個典型的DNS 欺騙的示意圖。

2.

TuPkVGdvW6tl

（1）緩存感染

黑客會熟練的使用DNS 請求，將數(shù)據(jù)放入一個沒有設(shè)防的DNS 服務(wù)器的緩存當(dāng)中。這些緩存信息會在客戶進(jìn)行DNS 訪問時返回給客戶，從而將客戶引導(dǎo)到入侵者所設(shè)臵的運行木馬的Web 服務(wù)器或郵件服務(wù)器上，然后黑客從這些服務(wù)器上獲取用戶信

息。

（2）DNS 信息劫持

入侵者通過監(jiān)聽客戶端和DNS 服務(wù)器的對話，通過猜測服務(wù)器響應(yīng)給客戶端的DNS 查詢ID 。每個DNS 報文包括一個相關(guān)聯(lián)的16位ID 號，DNS 服務(wù)器根據(jù)這個ID 號獲取請求源位臵。黑客在DNS 服務(wù)器之前將虛假的響應(yīng)交給用戶，從而欺騙客戶端去訪問惡意的網(wǎng)站。

（3）DNS 復(fù)位定向

攻擊者能夠?qū)NS 名稱查詢復(fù)位向到惡意DNS 服務(wù)器。這樣攻擊者可以獲得DNS 服務(wù)器的寫權(quán)限。

2. 拒絕服務(wù)攻擊

黑客主要利用一些DNS 軟件的漏洞，如在BIND 9版本（版本9.2.0以前的 9系列）如果有人向運行BIND 的設(shè)備發(fā)送特定的DNS 數(shù)據(jù)包請求，BIND 就會自動關(guān)閉。攻擊者只能使BIND 關(guān)閉，而無法在服務(wù)器上執(zhí)行任意命令。如果得不到DNS 服務(wù)，那么就會產(chǎn)生一場災(zāi)難：由于網(wǎng)址不能解析為IP 地址，用戶將無方訪問互聯(lián)網(wǎng)。這樣，DNS 產(chǎn)生的問題就好像是互聯(lián)網(wǎng)本身所產(chǎn)生的問題，這將導(dǎo)致大量的混亂。

3、分布式拒絕服務(wù)攻擊

DDOS 攻擊通過使用攻擊者控制的幾十臺或幾百臺計算機攻擊一臺主機，使得服務(wù) 拒絕攻擊更難以防范：使服務(wù)拒絕攻擊更難以通過阻塞單一攻擊源主機的數(shù)據(jù)流，來防范服務(wù)拒絕攻擊。Syn Flood是針對DNS 服務(wù)器最常見的分布式拒絕服務(wù)攻擊。

4. 緩沖區(qū)漏洞

Bind 軟件的缺省設(shè)臵是允許主機間進(jìn)行區(qū)域傳輸（zone transfer）。區(qū)域傳輸主要用于主域名服務(wù)器與輔域名服務(wù)器之間的數(shù)據(jù)同步，使輔域名服務(wù)器可以從主域名服務(wù)器獲得新的數(shù)據(jù)信息。一旦起用區(qū)域傳輸而不做任何限制，很可能會造成信息泄漏，黑客將可以獲得整個授權(quán)區(qū)域內(nèi)的所有主機的信息，判斷主機功能及安全性，從中發(fā)現(xiàn)目標(biāo)進(jìn)行攻擊。

1.2.3 TSIG

DNS 的事務(wù)簽名分為 TSIG (Transaction Signatures) 與 SIG0 (SIGnature)兩種。該如何選擇呢? 首先，要先判斷客戶端與服務(wù)器間的信任關(guān)系為何，若是可信任者，可選擇對稱式的 TSIG。TSIG 只有一組密碼，并無公開/私密金鑰之分；若是

非完全信任者，可選擇非對稱式金鑰的 SIG0，雖有公開/私密金鑰之分，相對的，設(shè)定上也較復(fù)雜。至于要選用哪種較適合，就由自己來判斷。通常區(qū)帶傳輸是主域名服務(wù)器到輔助域名服務(wù)器。

1.TSIG 技術(shù)

交易簽章 (TSIGRFC 2845)，是為了保護(hù) DNS安全而發(fā)展的。從BIND 8.2版本開始引入 TSIG 機制，其驗證 DNS 訊息方式是使用共享金鑰 (Secret Key) 及單向雜湊函式(One-way hash function) 來提供訊息的驗證和數(shù)據(jù)的完整性。主要針對區(qū)帶傳輸（ZONE Transfer）進(jìn)行保護(hù)的作用，利用密碼學(xué)編碼方式為通訊傳輸信息加密以保證 DNS 訊息的安全，特別是響應(yīng)與更新的訊息數(shù)據(jù)。也就是說在DNS 服務(wù)器之間進(jìn)行轄區(qū)傳送時所提供保護(hù)的機制，以確保傳輸數(shù)據(jù)不被竊取及監(jiān)聽。

2.SIG0 技術(shù)簡介

SIG0是一九九九年三月 由 IBM公司的D. Eastlake 提出成為標(biāo)準(zhǔn)。其是利用公開金鑰機制為轄區(qū)資料進(jìn)行數(shù)字簽章的動作，以保證每筆傳輸?shù)?source record 具有可驗證性與不可否認(rèn)性。實際上 SIG0 才是防止 DNS Spoofing 發(fā)生最主要的技術(shù)，SIG0 是使用公開金鑰加密法，讓轄區(qū)管理者為其轄區(qū)數(shù)據(jù)加上數(shù)字簽章，由此證明轄區(qū)資料的可信賴性。除此之外，SIG0 保有是否選擇認(rèn)證機制的彈性，以及可靈活地配合自訂的安全機制。

1.3 注意事項

在對DNS 進(jìn)行安全配臵之前，需要確認(rèn)DNS 是否能夠正常解析。

1.4 操作步驟

1.4.1選擇沒有安全缺陷的DNS 版本

BIND 主要分為三個版本：

（1）v4：1998年多數(shù)unix 捆綁

（2）v8：如今使用最多最廣大版本

安全信息：http://security.nsfocus.com/showQueryL.asp?libID=530

（3）v9：最新版本，免費（http://www.isc.org)

2. 保持DNS 服務(wù)器配臵正確、可靠

dlint 是專門檢查DNS 配臵文件開源代碼軟件：

dnstop 可以查詢DNS 服務(wù)器狀態(tài)：

1.4.2保護(hù)DNS 服務(wù)器本身安全

第一步：隔離DNS 服務(wù)器

DNS 服務(wù)器要專用，不要在DNS 服務(wù)器上運行其它服務(wù)，盡量允許普通用戶登錄。 第二步：隱藏DNS 服務(wù)器

網(wǎng)絡(luò)攻擊者對DNS 服務(wù)進(jìn)行攻擊前，首先要知道BIND 有版本號，根據(jù)BIND 版本號找到漏洞來確定攻擊DNS 服務(wù)器方法，攻擊者使用dig 命令可以查詢到BIND 的版本號。為了保障DNS 服務(wù)器安全的首先要隱藏DNS 服務(wù)器。下面是沒有隱藏DNS 服務(wù)，攻擊者查詢到的DNS 服務(wù)器的版本。

[root@centos ~]# dig @192.168.123.11 txt chaos version.bind

; <<>> DiG 9.3.4-P1 <<>> @192.168.123.11 txt chaos version.bind

; (1 server found)

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10122

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION:

;version.bind. CH TXT

;; ANSWER SECTION:

version.bind. 0 CH TXT "9.2.4"

;; AUTHORITY SECTION:

version.bind. 0 CH NS version.bind.

;; Query time: 20 msec

;; SERVER: 192.168.123.11#53(192.168.123.11)

;; WHEN: Thu Jan 14 18:33:27 2010

;; MSG SIZE rcvd: 62

[root@centos ~]#

通過下面對服務(wù)器進(jìn)行安全配臵，攻擊者無法查詢到DNS 服務(wù)地版本信息，編輯BIND 配臵文件，如下所示。

[root@lab2 ~]# vi /etc/named.conf

//

// named.conf for Red Hat caching-nameserver

//

options {

directory "/var/named";

version "unknow on this platform";

dump-file "/var/named/data/cache_dump.db";

statistics-file "/var/named/data/named_stats.txt";

/*

* If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default.

*/

// query-source address * port 53;

};

//

// a caching only nameserver config

//

"/etc/named.conf" 79L, 1572C

在配臵文件中加入“version "unknow on this platform";”，保存配臵文件，然后 退出，重啟DNS 服務(wù)器。

[root@lab2 ~]# service named restart

停止 named：[ 確定 ]

啟動 named：[ 確定 ]

[root@lab2 ~]#

再使用dig 命令進(jìn)行測試，如下所示：

[root@centos ~]# dig @192.168.123.11 txt chaos version.bind

; <<>> DiG 9.3.4-P1 <<>> @192.168.123.11 txt chaos version.bind ; (1 server found)

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61670

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION:

;version.bind. CH TXT

;; ANSWER SECTION:

version.bind. 0 CH TXT "unknow on this platform"

;; AUTHORITY SECTION:

version.bind. 0 CH NS version.bind. ;; Query time: 16 msec

;; SERVER: 192.168.123.11#53(192.168.123.11)

;; WHEN: Thu Jan 14 18:40:23 2010

;; MSG SIZE rcvd: 80

通過上面測試，可以看到攻擊者無法查詢到DNS 的版本信息。

第三步：避免透露DNS 服務(wù)器信息

和版本號一樣，也不要輕易透露服務(wù)器其他信息。為了讓潛在的攻擊者更難得手，盡量不要在DNS 配臵文件中使用這HINFO 和 TXT兩個資源記錄。

第四步：以最小的權(quán)限及使用chroot()方式運行BIND

以 root 使用者的身分執(zhí)行BIND 有安全隱患，攻擊者若找到BIND 的安全漏洞，可能獲取 root 的身分，從而進(jìn)行對服務(wù)器攻擊。

BIND 8.1.2 允許在啟動DNS 服務(wù)器後，變更其UID 和GID ，可以使用命令 named -u named

以 chroot() 的方式執(zhí)行BIND 可將危害減至最低

設(shè)臵 chroot 之后的環(huán)境：設(shè)臵dev/zero、dev/random、dev/log或etc/localtime，可以使用命令修改運行用戶。

named -u named -t /var/named

1.4.3保護(hù) DNS 免于 Spoofed 攻擊

DNS 服務(wù)器若接受來自Internet 的遞歸詢問要求，易遭受Spoofing 的攻擊，導(dǎo)致攻擊者修改DNS 服務(wù)器區(qū)域文件，其它用戶解析域名的時候，取回的是假造的名稱信息。

第一步：關(guān)閉rescursion 的功能

關(guān)閉 rescursion 功能后，DNS 服務(wù)器只會響應(yīng)非遞歸的詢問要求

無遞歸功能的DNS 服務(wù)器不易易遭受 Spoofing 的攻擊，因為它不會送出查詢要求，所以也不會攝取所管區(qū)域以外的任何數(shù)據(jù)

如果DNS 服務(wù)器還提供服務(wù)給合法的解析器（resolver ），或是充當(dāng)其他D NS服務(wù)器的代詢服務(wù)器（forwarder ），就不應(yīng)該關(guān)閉 rescursion 的功能。如果無法關(guān)閉 rescursion 的功能，應(yīng)該限制查詢要求的服務(wù)對象

修改配臵文件：/etc/named.conf.加入一行：

[root@lab2 ~]# vi /etc/named.conf

//

// named.conf for Red Hat caching-nameserver

//

options {

directory "/var/named";

version "unknow on this platform";

recursion no;

fetch-glue no;

dump-file "/var/named/data/cache_dump.db";

statistics-file "/var/named/data/named_stats.txt";

/*

* If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default.

"/etc/named.conf" 81L, 1603C

第二步：關(guān)閉 glue fetching 的功能

修當(dāng)DNS 服務(wù)器為響應(yīng)詢問的 DNS 封包建立 additional data 區(qū)段的數(shù)據(jù)時，會自動解析 NS 紀(jì)錄中任何DNS 服務(wù)器的域名，這稱為 glue fetching， 易遭受 Spoofing 的攻擊。

關(guān)閉 glue fetching 的功能，可避免DNS 服務(wù)器送出任何的查詢要求，所以也不會攝取所管區(qū)域以外的任何數(shù)據(jù)。

當(dāng)DNS 服務(wù)器返回一個域的域名服務(wù)器紀(jì)錄并且域名服務(wù)器紀(jì)錄中沒有A 紀(jì)錄，DNS 服務(wù)器會嘗試獲取一個紀(jì)錄。就稱為glue fetching, 攻擊者可以利用它進(jìn)行DNS 欺騙。關(guān)閉glue fetching 是一個好方法，修改配臵文件：/etc/named.conf.加入一行：

[root@lab2 ~]# vi /etc/named.conf

//

// named.conf for Red Hat caching-nameserver

//

options {

directory "/var/named";

version "unknow on this platform";

recursion no;

fetch-glue no;

dump-file "/var/named/data/cache_dump.db";

statistics-file "/var/named/data/named_stats.txt";

/*

* If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default.

"/etc/named.conf" 81L, 1603C

第三步：限制查詢要求的服務(wù)對象

如果無法關(guān)閉 rescursion 的功能，應(yīng)該限制查詢要求的服務(wù)對象

限制詢問要求的來源（IP 地址）

限制可以查詢的區(qū)域范圍

DNS 服務(wù)器應(yīng)該拒絕來自以下網(wǎng)絡(luò)的詢問要求

私有網(wǎng)絡(luò)（除非你自己在使用）

實驗性網(wǎng)絡(luò)

群播網(wǎng)絡(luò)

一般的DNS 服務(wù)器

對所管區(qū)域的名稱信息，可以服務(wù)來自任何 IP 地址的查詢要求，因為它是經(jīng)授權(quán)而來管理該區(qū)域的權(quán)威DNS 服務(wù)器

對于所管區(qū)域以外的名稱信息，只應(yīng)該服務(wù)來自內(nèi)部或可信賴之 IP 地址的查詢要求

cahing-only DNS服務(wù)器

應(yīng)該只服務(wù)來自特定 IP 地址的解析器

authoritative-only DNS服務(wù)器

必須服務(wù)來自任何IP 地址的詢問要求，但是應(yīng)該拒絕任何遞歸的詢問要求。具