DNS缓存污染.docVIP

? DNS缓存污染 ■ 文档编号 ■ 密级 ■ 版本编号 1.1 ■ 日期 2009-08-04 ? 2009 绿盟科技  ■ 版权声明 本文中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属绿盟科技所有，受到有关产权及版权法保护。任何个人、机构未经绿盟科技的书面授权许可，不得以任何方式复制或引用本文的任何片断。 ■ 版本变更记录 时间 版本 说明 修改人 2009-07-30 1.0 初始版本 陈庆 2009-08-04 1.1 应tt要求改动，更可读一些 陈庆 ■ 适用性声明 本模板用于撰写绿盟科技内外各种正式文件，包括技术手册、标书、白皮书、会议通知、公司制度等文档使用。 目录 ? DNS缓存污染 1 一. DNS体系简介 1 1.1 常见域名解析过程 1 1.2 常见DNS布署 1 二. DNS缓存污染 2 2.1 什么是DNS缓存污染 2 2.2 DNS缓存污染攻击所受限制 3 2.3 Transaction ID 3 2.4 源端口 4 2.5 NAT对源端口随机化的干挠 5 2.6 生日攻击 6 2.7 Classic Glue Poison 7 2.8 Bailywick Check 8 2.9 Kaminski Attack 8 2.10 小结 10 三. 参考资源 10 DNS体系简介 常见域名解析过程 参看[RFC 1034 4.3.1]，DNS Server必须支持迭代查询模式，可选支持递归查询模式。但在现实世界中几乎所有的DNS Server都支持递归查询模式，同时几乎所有的DNS Client都默认使用递归查询模式。 图中的Step 2被简化了，实际情形是依次访问根服务器、com的权威服务器、的权威服务器，每次都有DNS请求、响应发生，这个过程就是所谓迭代查询。 常见DNS布署 常见DNS布署如下图([RFC 1035 2.2]): Recursive Server维护Central cache，以此降低网络与相关服务器的负载([RFC 1034 5.1])。 DNS缓存污染 什么是DNS缓存污染 在1.2中提到Recursive Server维护Central cache，就是将来自响应报文的各种RR以某种形式缓存起来，下次遇上Stub Resolver向自己发出请求时，先在本地缓存里寻找相应的RR，没有找到的情况下才向Foreign Name Server发出请求。 Internet上 攻击者有办法伪造一个报文，使之看起来像是从Foreign Name Server发往Recursive Server的响应报文，其中包含的RR是攻击者指定的恶意内容，这样的RR被Recursive Server接受并缓存，我们称之发生了DNS缓存污染。 假设是内网的DNS Server，客户机向请求解析，这个过程一般意味着请求解析的A RR。攻击者可以通过缓存污染攻击使得的缓存中出现 A ，结果所有使用做DNS Server的客户机访问时实际访问的是。 在缓存中置入伪造的A RR是最直接的攻击方式，还可以置入CNAME RR、NS RR、MX RR等各种RR，这完全取决于攻击者的最终目的。 DNS缓存污染攻击所受限制 一般都是通过伪造DNS响应报文进行DNS缓存污染攻击。在设计DNS协议之初，并未专门考虑对抗这种类型的攻击，但一些协议方面的要求客观上起到了阻碍攻击的效果。 分析响应报文时靠Transaction ID判断是否与请求报文匹配([RFC 1034 5.3.3])。 收取响应报文后需要检查其是否与请求报文相匹配，建议先检查Transaction ID是否匹配，再检查Question Section是否匹配([RFC 1035 7.3])。 如果没有请求报文与响应报文相匹配，响应报文不应被缓存。 攻击者一般主动向Cache Server提交A RR查询请求，然后伪造Auth Server到Cache Server的A RR响应报文。这个过程要求伪造响应报文时必须指定正确的Transaction ID，否则Cache Server认为响应报文无效，不予接受。 除去DNS协议层Transaction ID的限制外，还有一个UDP承载层的限制。Cache Server一般向Auth Server的53/UDP发送查询请求，假设这个请求报文的源端口是0x5121，Auth Server生成的响应报文其目标端口必然是0x5121/UDP。攻击者伪造响应报文时也必须将目标端