同一个域名,两个不同的答案
首次请求
解析为公网 IP
校验
通过,看起来安全
TTL 过期
数秒之后
第二次请求
解析为 127.0.0.1
什么是 DNS 重绑定?为什么值得关注
大多数涉及域名的安全检查,都假定域名的 IP 地址足够稳定,验证一次之后就可以一直信任。DNS 重绑定利用的正是这一假设。攻击者控制某个域名的 DNS,起初把它配置为解析到一个正常的公网 IP 地址,从而通过目标系统所做的任何验证;等检查已经通过之后,在后续请求中再把应答改成内部地址(如 127.0.0.1,或内部的 10.x.x.x 网段)。
为什么这不只是纸上谈兵
极短的 TTL 让这种攻击变得切实可行:攻击者把记录设置为几秒后过期,于是一次验证检查和紧随其后的实际请求,可能在相隔数毫秒的时间内看到两个不同的应答,而受害系统对底层的变化毫无察觉。任何只解析一次域名、并在多个操作中重复使用该 IP 的系统,或者更糟的,验证时解析一次、真正请求时又让其他组件再解析一次的系统,都有可能受到影响。
唯一可靠的防御
只验证主机名字符串是不够的,只验证一次 IP 同样不够。唯一稳妥的防御,是在真正建立连接的那一刻,把实际解析出的地址与私有及内部网段黑名单进行比对,而且每一次都要比对,不能只在最初的输入验证时做一次。这样就消除了重绑定所依赖的时间差,因为在“已检查”与“被使用”之间,不再有任何窗口可供应答改变。
- 屏蔽私有网段(10.0.0.0/8、172.16.0.0/12、192.168.0.0/16)、环回地址(127.0.0.0/8)、链路本地地址(169.254.0.0/16)以及云元数据端点,IPv4 和 IPv6 都要覆盖。
- 每次使用时都重新检查,而不是只在输入验证时检查一次。
- 把 IPv4 映射的 IPv6 地址(如 ::ffff:127.0.0.1)视同其内嵌的 IPv4 地址,重绑定攻击有时正是利用这种编码来绕过只针对 IPv6 的简单检查。
| 做法 | 能否消除重绑定窗口? |
|---|---|
| 只验证一次主机名字符串 | 不能,它无法说明该名称解析到哪里 |
| 只解析一次,之后的请求复用该 IP | 不能,复用之前记录可能已经改变 |
| 每次使用时都解析并比对黑名单 | 能,应答再没有可供改变的窗口 |
它在现实中造成过哪些影响
DNS 重绑定并非小众的学术话题,它屡次被用来攻击家用路由器、智能家居中枢,以及其他暴露了无需认证的本地管理界面的设备,这些设备默认只有可信的本地流量才能访问到管理界面。一个恶意网页只要在同一网络内的普通浏览器标签页中打开,就能借助重绑定,让受害者自己的浏览器(仅凭身处本地网络,就已被路由器信任)代表攻击者直接向该管理界面发起请求。在整个过程中,浏览器始终以为自己是在与最初的那个公网域名通信,改变的只是底层的 DNS 应答。
更隐蔽的变种:多应答重绑定
更高明的版本根本不需要等 TTL 过期。一个 DNS 响应按规范可以包含多条 A 记录,有些客户端软件会按顺序逐个尝试,甚至在不同请求之间轮流使用。攻击者可以在同一个响应中同时返回一个合法的公网地址和一个内部地址,指望客户端最终会尝试第二个条目:既不用等待,也没有时间窗口,只是利用了 DNS 从未保证多应答响应中的每个地址同样可信这一点。这也再次提醒我们,“检查返回的第一个地址”永远不够,响应中的每个地址都需要同样的审视。
需要查看某个域名的公网 DNS 地址?使用 Domain IP Lookup 工具。
相关阅读
几乎每个 DNS 区域都会遇到的记录
什么是 CAA 记录?控制哪些 CA 可以签发证书
了解 DNS 证书颁发机构授权(CAA)记录如何指定被允许的证书签发机构,以及发布限制之前该如何规划,避免常见的 CAA 配置错误。
一次递归 DNS 查询,逐跳详解
浏览器
想访问 example.com
解析器
运营商 / 1.1.1.1
根 + TLD
谁负责 .com?
权威服务器
真正的答案
这条链路上的每一跳本身都是一次 DNS 查询,之后都会被缓存
DNSSEC 详解:DNS 应答如何被认证
了解 DNSSEC 签名、DS 与 DNSKEY 记录的作用,验证流程如何运作,以及配置失误为何会导致 SERVFAIL 响应。
每个 IPv4 地址段都有对应的 IPv6 地址段
不容忽视的 IPv6 安全考量
从安全角度看,IPv6 并不只是“地址更多的 IPv4”,它的几处差异确实改变了威胁模型,值得认真对待。