Chapter 7. BIND 9 安全

目录

7.1. 存取控制表

7.2. chroot 和setuid (UNIX服务器使用)

7.3. 动态更新安全

存取控制表

存取控制表 (ACLs), 是自己建立的地址匹配表并且取一名字以便 以后在allow-notify, allow-query, allow-recursion, blackhole, allow-transfer等中使用。

使用存取控制表可以精确的控制谁可以使用你的域名服务器，而不需要使用一大堆IP地址从而把配置文件弄的很乱。

使用 ACLs是个好主意，限制外部地址使用你的服务器可以帮助避免欺骗（spoofing） 和DoS（访问拒绝攻击）。

下面是一个如何使用ACLs的例子：

// Set up an ACL named "bogusnets" that will block RFC1918 space,

// which is commonly used in spoofing attacks.

acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };

// Set up an ACL called our-nets. Replace this with the real IP numbers.

acl our-nets { x.x.x.x/24; x.x.x.x/21; }; 

options {

  ...

  ...

  allow-query { our-nets; };

  allow-recursion { our-nets; };

  ...

  blackhole { bogusnets; };

  ...

};

zone "example.com" {

  type master;

  file "m/example.com";

  allow-query { any; };

};

这将允许外部服务器的递归查询除非递归查询前面已经被禁止。

更多有关ACLs 来保护服务器的信息，参见AUSCERT ，在 中提供。

和 setuid (UNIX服务器使用)

在UNIX服务器中，可以通过chrooted 环境来运行BIND (chroot())，（通过指定-t" 选项），把BIND放在一个"sandbox" 中会提升系统的安全性，如果系统不强壮，会减少有伤害的操作。

另一个在UNIX中有用的特性是把程序作为一个非特权部分（使用-u user ），我们建议在使用choot特性时使用非特权的用户。

下面是一个范例命令，它在choot()中载入BIND，运行/var/named并运行named setuid 使用用户 202：

/usr/local/bin/named -u 202 -t /var/named

环境

为了使chroot()工作正常 ，它通常要工作在一个特定的目录，例如： /var/named，这就需要建立一个BIND运行时需要所有的东西的环境，从BIND的观点看，/var/named 是系统的根目录，这样也就需要调整directory和pid-file来适应它。

不像早期版本的BIND，不需要静态编译named 或者在“新的根目录下”安装共享库，然而，根据不同的操作系统，可能需要建立比如/dev/zero, /dev/random, /dev/log, 和/或 /etc/localtime等目录。

使用setuid功能

优先运行named 程序，使用touch 工具（用来改变文件存取和修改时间）或者chown 工具（设置用户id和/或 组id），来修改BIND需要改写的文件。注意如果named 程序作为非特权用户运行，系统重启时它不会绑定新的限制端口。

7.3. 动态更新安全

对动态安全更新的存取应该被严格限制，在早期BIND版本中，唯一的办法是通过IP地址，在allow-update中设定一个允许更新的IP地址或地址前缀，这个方法是不安全的，因为UDP包容易造假。也要注意如果IP地址在allow-update 中，从属服务器执行转发的动态更新，管理服务器就会无能的被从属服务器发送的更新请求攻击，它会使用自己的IP地址转发包到管理服务器，管理服务器就认为是合法的请求而不验证。

因此，强烈推荐 使用密码授权更新机制 (TSIG)，那是因为allow-update选项只能列出TSIG 密钥名，不是IP地址或IP前缀。也可以选择新的update-policy 选项。

Some sites choose to keep all dynamically updated DNS data in a subdomain and delegate that subdomain to a separate zone. This way, the top-level zone containing critical data such as the IP addresses of public web and mail servers need not allow dynamic update at all.