BIND安全弱点及防范
BIND （Berkeley Internet Name Domain）软件包是一种域名解析服务（DNS）软件，是由BSDI（Berkeley Software Design，Inc。）开发的。现在Internet上存在的DNS服务器绝大多数是用BIND来架设的，也就是说，一提到DNS，你一定会马上想到BIND。正是由于BIND使用的广泛性，使得它成为众多攻击者感兴趣的目标。
目前大家比较常用的是BIND8.x版本，因此我们主要针对BIND8.x进行介绍。
DNS
首先我们简单介绍一下域名解析服务（DNS）。关键的一点是：当前我们都采用以名称（如www。netstd。com）作为Internet的定位体系，而不是用特殊的IP地址。而DNS就提供了计算机名与计算机地址的映射关系。举个例子，计算机名dns.netstd.com有三个IP地址：198.49.45.10、192.20.239.132和202.96.186.65。虽然多个IP地址能映射到一台单机，但最终可能每个IP地址映射到一台不同的计算机上。引起多对多、计算机名到地址的映射现象的原因是DNS允许系统管理员平衡计算机上的网络负荷。或许在整个网络上每天有成千上万人访问dns.netstd.com，因此它使用由多IP地址的多机为一个计算机名服务就显得很有意义。
弱点
BIND有两个重要特性：１.BIND会对所有已经经过查询的结果进行缓冲（Cache）
２. DNS使用随机的ID，但它总会在下一次询问时令ID+1。
正是由于以上特点，使得攻击者能进行下列攻击：
a. DNS欺骗（DNS Spoofing）
b. DoS （Denial of Service）
c. 偷取服务（Theft of Services）
d. 反向查询缓冲区超时（Inverse Query Buffer Overrun）
也许你对上述这些攻击方式有些迷惘，其实这些方式和一般直接攻击一样，仅仅是利用了DNS协议的漏洞，而且有可能具有很大的普遍性，造成较大的破坏。一个严峻的事实摆在我们面前：截止到2000年６月，Internet上所有DNS服务器中有50%还在运行存在漏洞的BIND。造成什么后果呢？在一次典型的对BIND的攻击中，入侵者删除了系统日志，安装了能获得管理权限的工具，接着编译并安装网络扫描工具，用这些工具在网络中大批量扫描运行有漏洞BIND的系统。几分钟之内他们利用已占领系统攻击了域外的成百上千台系统，又占领了很多其他系统。如此反复，其后果不堪设想！因此我们很需要加紧防范措施，特别是针对DNS Spoofing。
DNS Spoofing是指一台处于Internet中的计算机能为自己伪造一个IP地址。也就是说它能隐藏自身的IP地址，但它的作用何止这些。熟悉网络的人都知道，当客户向一台服务器请求服务时，服务器方一般都会根据客户的IP反向解析出IP对应的域名。这种反向域名解析是一个查DNS （Domain Name Service）的过程。如果客户的IP对应有域名，那么DNS查询会返回其域名。服务器端得到这一计算机名后会将其记录下来并传递给应用程序。
攻击实例
前面我们已经提到使用BIND的DNS服务器收到一条合法的DNS应答信息时它会接受这一返回包中的所有信息，并存入CACHE。举一个例子：在192。168。1。221的用户要TELNET到192.168.1.21上，192.168.1.21使用的DNS为202.96.199.133。三次握手后，192.168.1.21会向202.96.199.133发一个PTR类型的DNS查询（由IP查主机名）：
192.168.1.21 -> 202.96.199.133 [Query]
NQY： 1 NAN： 0 NNS： 0 NAD： 0
QY： 221.1.168.192.in-addr.arpa PTR
而202.96.199.133中没有关于用户IP对应域名的信息，于是它首先根据DNS协议及其配置查找出192.168.1.221的授权DNS服务器--192.168.1.1。然后向其发出查询包：
202.96.199.133 -> 192.168.1.1 [Query]
NQY： 1 NAN： 0 NNS： 0 NAD： 0
QY： 221.1.168.192.in-addr.arpa PTR
注意这里省略了Iterative与Recursive两种方式的区别，一般的DNS的默认设置为
Iterative，Recursive为可选项。（详细情况请参见RFC1034）
192.168.1.1收到查询信息后就可以返回192.168.1.221对应的域名：
192.168.1.1 -> 202.96.199.133 [Answer]
NQY： 1 NAN： 2 NNS： 1 NAD： 1
QY： 221.1.168.192.in-addr.arpa PTR
AN： 221.1.168.192.in-addr.arpa PTR yourname.host.com
AN： yourname.host.com A 192.168.1.221
NS： 221.1.168.192.in-addr.arpa NS ns.host.com
AD： ns.host.com A 192.168.1.1
返回的包中给出了192.168.1.221对应的域名为yourname.host.com，并指出yourname.host.com对应的IP为192.168.1.221（请注意这两个对应的是不同的概念！）。如果这个返回包能由我们给出，我们的目的就达到了。那么我们怎么做呢？如果局域网内有DNS服务器，那么可以通过监听、响应的方法实现DNS欺骗。具体步骤是：先嗅探传到局域网的DNS查询包，然后代替本网段的DNS服务器给出应答信息。但实际在实现时却碰到了问题，本网段的DNS服务器也会同时给出应答信息，而我们构造的包与它给出的包会有冲突，通常是我们的慢，这样的DNS欺骗注定会失败！为了获得比较好的DNS欺骗效果，我们就要利用在文章开头讲到的DNS实现的的第二个特点：当DNS服务器发查询包时，它在包内有一Query ID，应答信息只有Query ID及IP都吻合时才能被DNS服务器所接受。而这一ID每次加一，所以只要通过第一次向将要欺骗的DNS 服务器发一个查询包并监听其ID值，随后再发一查询，紧接着马上发送我们设计好的应答包，包内的Query ID为预测的Query ID值（我们可以指定一个范围，比如从Previous_ID+20到Previous_ID+200）。
接上例，如192.168.1.221的用户要欺骗192.168.1.21，他可以对202.96.199.133进行欺骗： 11.11.11.11 -> 202.96.199.133 [Query]
NQY： 1 NAN： 0 NNS： 0 NAD： 0
QY： aaaaa.host.com A
由于host.com的域名由192.168.1.1控制，202.96.199.133向192.168.1.1发查询包：
202.96.199.133 -> 192.168.1.1 [Query]
NQY： 1 NAN： 0 NNS： 0 NAD： 0 QID： 2345
QY： aaaaa.host.com A
192.168.1.221的用户可以监听到该包，得到QID： 1111。然后再向202.96.199.133发第二次查询：
11.11.11.11 -> 202.96.199.133[Query]
NQY： 1 NAN： 0 NNS： 0 NAD： 0
QY： bbbbb.host.com A
紧接着发带有预测QID的应答包：
192.168.1.1-> 202.96.199.133 [Answer]
NQY： 1 NAN： 0 NNS： 0 NAD： 0 QID： 2346
QY： 221.1.168.192.in-addr.arpa PTR
AN： 221.1.168.192.in-addr.arpa PTR as.your.wish（任何域名）
as.your.wish就是用户自己指定的域名。但请注意发这个包时应该用192.168.1.1这一IP地址。以上我们基本实现了对DNS服务器的欺骗。
注意限制
但上述过程的实现在实际操作中有一些限制 ，例如：对这些攻击，也有一定的限制。
首先，攻击者不能替换缓存中已经存在的记录。比如说，如果在202.96.199.133这个DNS服务器上已经有一条www.dot.com的CNAME记录，那么攻击者试图替换为www.dotdot.com将不会成功。但是在DNS服务器中一些记录可以累加，比如A记录，如果在DNS的缓存中已经存在一条www.dot.com的A记录为11.11.11.11，而攻击者却欺骗DNS服务器声称www.dot.com的A记录为22.22.22.22，那么www.dot.com将会有两个A记录，客户端查询时会随机返回其中一个，这样就有50%的成功机率。其次，DNS服务器还存在缓存（Cache）刷新时间问题，如果www.dot.com的TTL为7200，那么DNS服务器会把www.dot.com的信息缓存7200秒（两个小时）。如果攻击者放入一条TLL为259200的A记录，那么这条记录将会在缓存中保存三天时间，过了默认的两天后，这个DNS服务器就会到处散发攻击者假造的欺骗记录。
解决方案
那么我们能采取怎样的防范措施呢？可以有以下几点：
1. 安装最新版本的BIND：虽然最新版的软件不能完全保证您的域名服务器的安全，但是它能把受攻击的可能性降到最低。（而旧版本软件中存在大量广为人知的漏洞）。最好选择BIND8.2.2-p5或以上版本。
2. 限制BIND8.x中的Zone Transfers：
－在BIND8 中使用allow-transfer字句：
options{
allow-transfer{202.96.236.112};};};
－定制一个Zone：
zone \"netstd.com\"{
type master;
file \"db.netstd.com\";
allow-transfer{202.96.236.112;};
};
注意： 还应限制备用域名服务器的Zone Transfer，而不仅仅是主域名服务器。因为从备用域名服务器转换一个Zone和从主域名服务器上做一样简单。
３. 使用签名处理程序（TSIG）来加密验证和校验区的信息（注意在使用TSIG时需要域名服务器之间的时间同步）。
４. 限制动态升级：。动态升级很有用也很危险：一个经授权的升级者能删除和增加Zone中的记录。
５.为防止DNS欺骗：。－尽可能关闭递归。
－限制域名服务器作出响应的地址。
－限制域名服务器作出响应的递归请求地址。
－关闭Glue Fetching。
－限制发出请求的地址。
－限制递归请求。
发布人:sunshine 来自: