BIND 8+ 域名服務器安全增強 zt

為什么要寫這篇文章？第一個原因當然就是前段時間出現的BIND 8.2.x TSIG 
安全漏洞（還有去年公布的BIND 8.1.x/8.2.x NXT安全漏洞），直到目前為止，國 
內也還沒有關于DNS服務安全配置方面的較為完整的文章（即使是國外也不多見）。 
另一個原因是經過調查發現，幾乎任何一種UNIX家族的操作系統，都使用BIND軟件 
作為其DNS的唯一實現，比起其它諸如ftp/http/pop3等網絡服務有各種各樣的發行 
版本，所以一旦被發現有安全問題，則受影響的主機之多也是其它漏洞很難比擬的。 
所以覺得應該寫一份針對BIND DNS服務軟件的安全配置資料，充分利用BIND自身已 
經實現的保護功能，加強BIND安全性，從而能抵御目前已知的BIND安全漏洞，并使 
潛在的安全漏洞所可能對服務器造成的影響盡可能地減少。 

配置環境： 
        FreeBSD 4.1-RELEASE 
        BIND 8.2.3 


---[[ 啟動安全選項 ]]--------------------------------------------------- 

　　named進程啟動選項： 

-r：關閉域名服務器的遞歸查詢功能（缺省為打開）。該選項可在配置文件的 
    options中使用"recursion"選項覆蓋。 

-u <user_name>和-g <group_name>：定義域名服務器運行時所使用的UID和GID。 
                                 這用于丟棄啟動時所需要的root特權。 

-t <directory>：指定當服務器進程處理完命令行參數后所要chroot()的目錄。 


---[[ 配置文件中的安全選項 ]]------------------------------------------- 

1、假如希望記錄安全事件到文件中，但同時還希望保持原有的日志模式，可以添 
   加以下內容： 

logging { 
        channel my_security_channel { 
                file "my_security_file.log" versions 3 size 20m; 
                severity info; 
        }; 
        category security { 
                my_security_channel; 
                default_syslog; default_debug; }; 
} 

　　其中my_security_channel是用戶自定義的channel名字，my_security_file.log 
是安全事件日志文件，可包含全路徑（否則是以named進程工作目錄為當前目錄）。 
安全事件日志文件名為my_security_file.log，保存三個最近的備份 
（my_security_file.log0、my_security_file.log1、my_security_file.log2）， 
日志文件的最大容量為20MB（如果達到或超這一數值，直到該文件被再次打開前， 
將不再記錄任何日志消息。缺?。ㄊ÷裕r是沒有大小限制。） 


2、在options節中增加自定義的BIND版本信息，可隱藏BIND服務器的真正版本號。 

version "Who knows?"; 
// version 9.9.9; 

　　此時如果通過DNS服務查詢BIND版本號時，返回的信息就是"Who knows?"。^_^ 


3、要禁止DNS域名遞歸查詢，在options（或特定的zone區域）節中增加： 

recursion no; 
fetch-glue no; 


4、要增加出站查詢請求的ID值的隨機性，在options節中增加： 

use-id-pool yes; 

　　則服務器將跟蹤其出站查詢ID值以避免出現重復，并增加隨機性。注意這將會 
使服務器多占用超過128KB內存。（缺省值為no） 


5、要限制對DNS服務器進行域名查詢的主機，在options（或特定的zone區域）節 
   中增加： 

allow-query { <address_match_list> }; 

address_match_list是允許進行域名查詢的主機IP列表，如"1.2.3.4; 5.6.7/24;"。 


6、要限制對DNS服務器進行域名遞歸查詢的主機，在options（或特定的zone區域） 
   節中增加： 

allow-recursion { <address_match_list> }; 

    address_match_list是允許進行域名遞歸查詢的主機IP列表，如 
"1.2.3.4; 5.6.7/24;"。 


7、要指定允許哪些主機向本DNS服務器提交動態DNS更新，在options（或特定的 
   zone區域）節中增加： 

allow-update { <address_match_list> }; 

    address_match_list是允許向本DNS服務器提交動態DNS更新的主機IP列表，如 
"1.2.3.4; 5.6.7/24;"。 
    缺省時為拒絕所有主機的提交。 


8、要限制對DNS服務器進行區域記錄傳輸的主機，在options（或特定的zone區域） 
   節中增加： 

allow-transfer { <address_match_list> }; 

    address_match_list是允許進行區域記錄傳輸的主機IP列表，如"1.2.3.4; 
5.6.7/24;"。 


9、要指定不接受哪些服務器的區域記錄傳輸請求，在options（或特定的zone區域 
   ）節中增加： 

blackhole { <address_match_list> }; 

    address_match_list是不接受區域記錄傳輸請求的主機IP列表，如"1.2.3.4; 
5.6.7/24;"。 


10、在options節中還有一些資源限制選項，不同用戶可根據實際情況靈活設置， 
    但一定要注意不當的設置會損失DNS服務的性能。 

coresize <size_spec> ;        // core dump的最大值。缺省為default。 

datasize <size_spec> ;        // 服務器所使用的最大數據段內存。缺省為 
default。 

files <size_spec> ;        // 服務器能同時打開的最大文件數。缺省為 
                        // unlimited（不限制）。 
                        // （注意，并非所有操作系統都支持這一選項。） 

max-ixfr-log-size <size_spec> ;        // （目前版本暫不使用。）限制增量區域 
記 
                                   錄傳輸時會話日志的大小。 

stacksize <size_spec> ;        // 服務器所使用的最大堆棧段內存。缺省為 
default。 


11、定義ACL地址名（即用于上面的<address_match_list>）。注意，如果要使用 
    這里定義的列表名，必須先定義，后使用！ 
    例如： 

acl intranet { 
        192.168/16; 
}; 
acl partner { 
        !172.16.0.1; 
        172.16/12;        // 除172.168.0.1外172.16.0.0/12網絡中其它主機 
}; 

BIND已內置以下四個ACL： 

all                // 允許所有主機 
none                // 禁止所有主機 
localhost        // 本機的所有網絡接口 
localnets        // 本機所在網絡 


12、BIND域名服務器的一個有用功能（慎用?。。。?nbsp;

    控制管理接口controls節語法格式： 

     controls { 
       [ inet ip_addr 
         port ip_port 
         allow { <address_match_list>; }; ] 
       [ unix path_name 
         perm number 
         owner number 
         group number; ] 
     }; 


    controls節提供管理接口。如果使用第一種(inet)，則在指定IP（接口）和端 
口上監聽，但只允許在allow中限定允許與其連接的IP地址列表。如果使用第二種 
(unix)，則產生一個FIFO的控制管道，權限、屬主和用戶組都由其參數限定。 


---[[ 通過TSIG對區域記錄傳輸進行認證和校驗 ]]--------------------------- 

    首先請確保你的BIND域名服務器軟件已更新到最新版本！ 
    在BIND 8.2+中，能夠使用事務簽名（Transaction Signatures，即TSIG?。?nbsp;
來對區域記錄數據進行驗證和校驗。它要求在主域名服務器和輔助域名服務器上配 
置好加密密鑰，并通知服務器使用該密鑰與其它域名服務器通訊。（注意，TSIG的 
使用要求域名服務器必須進行時鐘同步?。?nbsp;


A、如果需要用TSIG簽名來進行安全的DNS數據庫手工更新，具體操作步驟很簡單： 

1、使用BIND自帶的dnskeygen工具生成TSIG密鑰。 

# dnskeygen -H 128 -h -n tsig-key. 

則會生成兩個文件。'Ktsig-key.+157+00000.key'內容如下： 

tsig-key. IN KEY 513 3 157 awwLOtRfpGE+rRKF2+DEiw== 

'Kvip-key.+157+00000.private'內容如下： 

Private-key-format: v1.2 Algorithm: 157 (HMAC) Key: awwLOtRfpGE+rRKF2+DEiw== 

注意這些密鑰都已經過BASE64編碼了。將它們放到本地域名服務器的配置文件中。例如 
： 

key tsig-key. { algorithm hmac-md5; secret "awwLOtRfpGE+rRKF2+DEiw=="; }; 

zone "dns.nsfocus.com" { 
        ... 
        ... 
        allow-update { key tsig-key. ; }; 
} 

記住要重啟named守護進程。 


　　然后將這兩個密鑰文件復制到客戶端系統（或輔助域名服務器），例如為/var 
/named/tsig目錄。最后運行如下命令即可： 

nsupdate -k /var/named/tsig:tsig-key. 


B、如果需要對區域記錄傳輸（自動或手工）進行TSIG簽名，則： 

1、用dnskeygen生成TSIG密鑰，方法同上。 

2、主域名服務器配置文件的內容（節選）如下： 

// 定義認證的方法和共享密鑰 
key master-slave { 
        algorithm hmac-md5; 
        secret "mZiMNOUYQPMNwsDzrX2ENw=="; 
}; 
// 定義輔助域名服務器的一些特性 
server 192.168.8.18 { 
        transfer-format many-answers; 
        keys { master-slave; }; 
}; 
// 區域記錄定義 
zone "nsfocus.com" { 
        type master; 
        file db.nsfocus.com; 
        allow-transfer { 192.168.8.18; }; 
}; 

3、輔助域名服務器配置文件的內容（節選）如下： 

// 定義認證的方法和共享密鑰 
key master-slave { 
        algorithm hmac-md5; 
        secret "mZiMNOUYQPMNwsDzrX2ENw=="; 
}; 
// 定義與主域名服務器通訊時的一些特性 
server 192.168.8.19 { 
        transfer-format many-answers; 
        keys { master-slave; }; 
}; 
// 區域記錄定義 
zone "nsfocus.com" { 
        type slave; 
        file "bak.db.nsfocus.com"; 
        masters { 192.168.8.19; }; 
        allow-transfer { none; }; 
}; 


---[[ 實施DNSSec功能 ]]------------------------------------------------- 

說實在的，我一直在考慮需不需要在目前的版本中實施DNSSec功能。因為雖然ISC 
早已在BIND 8.1.x版本后增加了DNSSec的實現，但實際的應用卻不常見，而且去年 
公布的NXT遠程安全漏洞和DNSSec有關（實際上NXT就屬于DNSSec實現的功能之一）。 
最后我決定在本文不討論如何實施DNSSec安全功能。 
但不可否認，DNSSec確實是一項很好的安全技術，它通過加密DNS數據來提高了DNS 
服務的安全性。主加密密鑰用于對第一級域名的加密密鑰進行加密簽字，第一級域 
名(.com, .cn等)密鑰用于對自身數據及其子域名密鑰進行加密簽名，以此類推。 
例如，nsfocus.com的域名服務器由.com域密鑰簽名，nsfocus.com域密鑰則用于對 
www.nsfocus.com域名進行加密簽名。 


---[[ 實現BIND的chroot ]]--------------- 

（以FreeBSD系統平臺為例） 

步驟一：BIND-8的最新源代碼版本獲取和安裝 

    請到ISC FTP站點下載BIND的最新版本。 
    BIND 8：http://www.isc.org/products/BIND/bind8.html 
    BIND 9：http://www.isc.org/products/BIND/bind9.html 

步驟二：構造靜態(static)的named和named-xfer二進制文件 

    在編譯和安裝后，你需要構造可執行文件的靜態鏈接版本。只要對%BIND%/src 
/port/freebsd目錄下的Makefile.set文件稍加修改后即可。 
　　修改文件內容： 

'CDEBUG= -O2 -g' 

替換為： 

'CDEBUG= -O2 -static' 

    切換到BIND的源代碼路徑，執行"make clean"和"make"命令。在下面的步驟中 
將會把這些文件復制到chroot()目錄下。 

# cd /tmp/bind/src 
# make clean ; make 

    本步驟構造的靜態鏈接執行文件在運行時無需裝載動態鏈接庫。在chroot()環 
境中，這種“獨立”可執行文件可避免出現缺少鏈接庫文件問題。它在chroot()環 
境中無需任何靜態鏈接庫，可使服務配置簡單化。其它所有的網絡守護進程也可以 
編譯和使用這種靜態鏈接版本。 


步驟三：構造BIND目錄 

    為chroot()環境構造BIND目錄。這個目錄將在chroot()環境中被BIND當作系統 
    根目錄。在這里我使用/chroot/bind作為chroot后的根目錄。 

# cd /chroot/bind 
# mkdir /chroot 
# mkdir /chroot/dev 
# mkdir /chroot/etc 
# mkdir /chroot/etc/namedb 
# mkdir /chroot/usr 
# mkdir /chroot/usr/sbin 
# mkdir /chroot/var 
# mkdir /chroot/var/run 

　　需要復制以下文件到其下的相應子目錄中，和進行一些必要的處理： 

# cp /etc/namedb/named.conf /chroot/bind/etc/ 
# cp /etc/localtime /chroot/bind/etc/ 
# grep bind /etc/group > /chroot/bind/etc/group 
# cp -R /etc/namedb/ /chroot/bind/etc/namedb/ 
# mknod /chroot/bind/dev/null c 2 2 
# chmod 666 /chroot/bin/dev/null 
# cp /tmp/bind/src/bin/named/named /chroot/bind/usr/sbin/ 
# cp /tmp/bind/src/bin/named-xfer/named-xfer /chroot/bind/ 

    另外還可根據需要指定日志記錄目錄（如/var/log），請參考下面的章節或 
named.conf的手冊頁。 


步驟四：添加bind用戶和組（如果沒有的話。如果已經有bind或named之類的用戶 
        和組，請跳過本步驟。） 

    在/etc/passwd和/etc/group文件中添加bind用戶和組。它們是DNS服務器運行 
時的UID/GID。 

    此時，你可以到chroot環境中執行"chown -R bind.bind /chroot/bind/etc/ 
namedb"命令。這樣當你向系統發送中斷信號(kill -INT 時，named進程能夠保存 
服務器緩存和統計信息。如果該目錄為root所有則named進程無法將輸出寫到目錄 
中，但不會影響named服務器功能。另一個選擇是僅改變目錄權限（使named用戶具 
有寫權限），而屬主仍然是root。這種方法也是可行的，但必須小心設置，確保其 
它用戶不會修改named記錄！ 

*** 重要警告*** 
    不要用一個已存在的UID/GID（如"nobody"）運行named。記住，以chroot環境 
中使用任何已存在的UID/GID都可能會影響到服務的安全性。必須養成在chroot環 
境中為每一個守護進程提供獨立的UID/GID的習慣。 


步驟五：其它必要調整 

　　如果在named.conf中還指定了另外的目錄和文件，也要相應地在chroot()環境 
中（在本例中即/chroot/bind/目錄）進行設置。 


步驟六：調試 

1、終止系統中原有的syslogd和named守護進程。 

# killall syslogd named 

2、用適當的參數重新啟動syslogd守護進程。 

# syslogd -s -p /chroot/bind/var/run/log 

3、用適當參數重新啟動named守護進程。 

# /chroot/bind/named -u bind -g bind -t /chroot/bind 

4、檢查syslogd/named守護進程、監聽端口是否正常，和/var/log/messages文件 
   中named進程啟動時是否正常。 

# ps auwx|grep syslogd 
root     5896  0.0  1.7   896  508  ??  Ss    9:44PM   0:00.10 syslogd -s -p 
/chroot/bind/var/run/log 
# ps auwx|grep named 
bind     5941  0.0  4.9  1652 1444  ??  Is    9:52PM   0:00.01 
/chroot/bind/usr/sbin/named -u bind -g bind -t /chroot/bind 
# netstat -an|grep 53 
tcp4       0      0  127.0.0.1.53           *.*                    LISTEN 
tcp4       0      0  192.168.8.19.53        *.*                    LISTEN 
udp4       0      0  127.0.0.1.53           *.* 
udp4       0      0  192.168.8.19.53        *.* 

步驟七：修改系統啟動腳本 

　　對于FreeBSD系統，在/etc/rc.conf文件中增加如下內容即可： 

syslogd_enable="YES" 
# 如果希望禁止向外發送日志，將-s換成-ss。 
syslogd_flags="-s -p /chroot/bind/var/run/log" 

named_enable="YES" 
named_program="/chroot/bind/usr/sbin/named" 
named_flags="-u bind -g bind -t /chroot/bind" 

　　注：如果在其它系統平臺，如OpenBSD、Linux、Solaris，則可能會稍有不同。 
主要是不同平臺上的syslog實現不盡相同。例如對于OpenBSD和Linux系統，打開日 
志別名socket的命令是"syslogd -a /chroot/bind/var/run/log"，而Solaris的 
syslogd守護進程則不支持別名。因此Solaris系統平臺上的chroot需要通過另外的 
方法實現，關于具體的實現過程我會在另外的文章中說明。 


---[[ 結束語 ]]--------------------------------------------------------- 

　　安全增強配置的文章寫完了，但并不是說只要你按本文提到的方法和技術實施 
就能萬無一失，高枕無憂了。其實以上設置對NXT和TSIG遠程漏洞攻擊并不沒太多 
的防御作用，充其量只不過是要編寫更多的shellcode代碼來突破chroot環境的限 
制。即使用allow-query等極其嚴格地限制查詢客戶端（實際上在互聯網上并不現 
實），基于UDP協議的TSIG攻擊技術也只需構造偽造IP地址的數據包即可繞過其限 
制。 
　　所以，在對BIND（還有其它應用服務）進行安全增強配置的基礎上，安全管理 
員仍然需要密切關注最新的安全公告、安全補丁和安全技術，經常與專業的計算機 
安全專家交流知識和經驗，再輔以必要的安全產品和安全服務，才能更充分地保護 
好自己的網絡和計算機用戶，抵御各種惡意攻擊。

luke3399 回復于：2003-07-31 16:31:18

Goooooooooooooooooood!

原文轉自：http://www.kjueaiud.com