dns缓存中毒攻击与防护

《dns缓存中毒攻击与防护》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、DNS缓存中毒攻击与防护互联X是一个脆弱的X络系统，其中的DNS基础设施就存在一种缓存漏洞，由于其设计的缺陷，尤其在去年，引发了几起大范围的X络瘫痪。而这个漏洞主要针对递归查询服务器，我们针对这个问题进行简单的论述与探讨。关键词：X络安全；DNS缓存中毒；攻击；防护　　在互联X初期，为了便于进行主机标识，采用了Hosts文件来进行这种与IP地址的对应关系。但是随着X络的迅速发展，已经不可能再继续使用Hosts主机文件来保存这种映射关系，于是产生了DNS。　　DNS是用于管理主机名称和地址信息映射的分布式数据库系统，将这个巨大的映射信息划分成许

2、多较小的部分，并把每一部分存储在不同的计算机上，需要映射的计算机可以查询一个最近的持有所需要信息的计算机。DNS目前已经成为大部分X络应用的基础，一旦遭受攻击，用户将不能进行正常的X络访问，因此DNS的安全影响巨大。　　在DNS攻击中，危害比较大的当属DNS缓存中毒。我们分析一下缓存中毒的攻击原理和过程，以及防护办法。一、DNS缓存中毒攻击原理　　首先来了解一下DNS的工作过程。DNS被设计成C/S应用程序，需要把地址映射为名字或把名字映射为地址的主机调用DNS解析程序，向最近的DNS服务器发出查询请求，此时，DNS服务器可以有两种方式来响应

3、客户的请求，一种叫递归解析，另一种叫迭代解析。DNS缓存中毒攻击主要是针对递归解析方式工作并缓存非本域的解析结果的DNS服务器。下面就主要分析递归解析过程。　　（1）应用程序需要解析一个域名时，本机会发起域名解析请求，解析程序会向首选DNS服务器DNS-A发起域名解析请求；　　（2）DNS-A收到解析请求后会去查询自己的管辖域，如果请求的是自己管辖域的域名就会直接将查询结果返回给解析程序，如果不在DNS-A的管辖域内，DNS-A就向它的上级服务器DNS-B发起解析请求，等待DNS-B的查询结果；　　（3）如果DNS-B解析不了，就会告诉DNS

4、-A，我解析不了，DNS-C可能会知道；　　（4）DNS-A就会给DNS-C发出解析请求，等到DNS-C的查询结果；　　DNS服务器不是对收到的任何DNS响应数据包都会接受，它会解码数据包，检查数据包是否符合接受的标准，那DNS服务器会检查数据包中的哪些数据来判断该数据包是不是它所希望的包呢？　　1、在DNS服务器发出的查询请求包中包含了它的UDP端口号，返回的响应数据包的目的端口号不对，X络协议栈就会直接丢弃该数据包。　　2、DNS服务器收到响应数据包后，可以通过检查问题域与发出的查询包中的问题域是否一致来判断响应数据包的合法性。　　3、D

5、NS服务器每发出一个查询请求都会分配对应的一个查询ID号，在内部对应是某一个域名查询请求，在DNS服务器内部区分不同的查询就是TID号，如果DNS服务器收到的响应数据包中的TID号不在DNS服务器等待响应数据的TID中，服务器就会丢弃该数据包。　　4、响应数据包中的授权域和附加域　　授权域和附加域中的域名必须和问题域中的域名是同属于某个域名下的子域名。　　如果上述所有条件都满足了，DNS域名服务器就会确定该响应数据包是对它发出的某个查询请求的响应，接受使用相应数据包中的数据，并缓存结果。　　如果某个攻击者可以预测和伪造响应数据包，他就可以对D

6、NS服务器发起缓存中毒攻击了。由于DNS服务器发送的数据包中的TID只有16位，而且大部分的DNS实现发出的请求中的源端口都是固定不变的。因此，攻击者就可以伪造DNS响应包，DNS服务器在收到响应包后就会将解析结果保存在自己的缓存中，进而实现了缓存中毒攻击。二、DNS缓存中毒的防护　　及时检查自己的DNS服务器是否存在DNS缓存中毒漏洞，如果发现了自己的DNS服务器存在该漏洞就可以在被攻击前采取措施修补，避免攻击事件的发生。　　目前检查DNS服务器是否存在缓存中毒漏洞的主要方法是模拟攻击过程中的一部分。检查的具体过程是首先需要搭建一个自己可以

7、控制的DNS服务器，与扫描器协同工作，让扫描器向要检查的DNS服务器查询只有控制的DNS服务器才能解析的域名请求，被检查的DNS服务器需要解析该域名就会向别的DNS服务器请求解析，根据前边介绍的DNS服务器解析原理，最终被检查的服务器发出的查询请求可以被导向到我们控制的DNS服务器，这样，控制的服务器就可收到检查服务器的请求，进而可以收集到检查服务器发出请求包的特征，被控服务器就可以将收集到的特征信息作为查询的响应数据返回给检查的DNS服务器，进而可以返回给扫描器，这样扫描器就可以根据收集的特征来判断检查的DNS服务器是否存在缓存中毒漏洞。　

8、　技术层面的防护措施有如下方法：　　UDP源端口随机化选择是一种比较有用的防护举措，不应该再是默认的53,而是应该在UDP端口范围内随机选择，使得投毒命中的概率极大