為什麼要寫這篇文章?第一個原因當然就是前段時間出現的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(如果達到或超這一數值,直到該文件被再次打開前,
將不再記錄任何日志消息。缺省(省略)時是沒有大小限制。)
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域名服務器的一個有用功能(慎用!!!):
控制管理接口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!)
來對區域記錄數據進行驗證和校驗。它要求在主域名服務器和輔助域名服務器上配
置好加密密鑰,並通知服務器使用該密鑰與其它域名服務器通訊。(注意,TSIG的
使用要求域名服務器必須進行時鐘同步!)
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 auwxgrep syslogd
root 5896 0.0 1.7 896 508 ?? Ss 9:44PM 0:00.10 syslogd -s -p
/chroot/bind/var/run/log
# ps auwxgrep 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 -angrep 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(還有其它應用服務)進行安全增強配置的基礎上,安全管理
員仍然需要密切關注最新的安全公告、安全補丁和安全技術,經常與專業的計算機
安全專家交流知識和經驗,再輔以必要的安全產品和安全服務,才能更充分地保護
好自己的網絡和計算機用戶,抵御各種惡意攻擊。
方法實現,關於具體的實現過程我會在另外的文章中說明。
---[[ 結束語 ]]---------------------------------------------------------
安全增強配置的文章寫完了,但並不是說只要你按本文提到的方法和技術實施
就能萬無一失,高枕無憂了。其實以上設置對NXT和TSIG遠程漏洞攻擊並不沒太多
的防御作用,充其量只不過是要編寫更多的shellcode代碼來突破chroot環境的限
制。即使用allow-query等極其嚴格地限制查詢客戶端(實際上在互聯網上並不現
實),基於UDP協議的TSIG攻擊技術也只需構造偽造IP地址的數據包即可繞過其限
制。
所以,在對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(還有其它應用服務)進行安全增強配置的基礎上,安全管理
員仍然需要密切關注最新的安全公告、安全補丁和安全技術,經常與專業的計算機
安全專家交流知識和經驗,再輔以必要的安全產品和安全服務,才能更充分地保護
好自己的網絡和計算機用戶,抵御各種惡意攻擊。