DNS Cache Poisoning Attack Reloaded: Revolutions with Side Channels

标题：重载DNS缓存投毒攻击：侧信道革命

作者：Keyu Man、Zhiyun Qian、Zhongjie Wang、Xiaofeng Zheng、Youjun Huang、Haixin Duan

网页：SAD DNS

全文翻译

摘要

在本文中，我们报告了软件栈中的一系列缺陷，这些缺陷导致了DNS缓存投毒攻击的复兴。DNS缓存投毒攻击是一种可以在实践中通过简单而有效的基于随机化的防御措施，如随机化的源端口来缓解的攻击方式。

为了成功污染典型服务器上的DNS缓存，非中间人的攻击者需要同时发送2^{32}个欺骗性的响应，猜测正确的源端口（16位）和事务ID（16位），这是不切实际的数量。

令人惊讶的是，我们发现了一些弱点，允许对手通过先猜测源端口，然后猜测事务ID来“分割和征服”空间，导致只需要发送 2^{16}+2^{16} 个欺骗性的响应。

更糟糕的是，我们展示了对手扩展攻击窗口的一些方法，这极大地提高了成功的几率。

该攻击影响到DNS基础设施中的所有缓存层，如DNS转发器和解析器缓存，以及广泛的DNS软件栈，包括最流行的BIND、Unbound和dnsmasq，运行在Linux和潜在的其他操作系统之上。

受害者受到攻击的主要条件是，操作系统及其网络被配置为允许ICMP错误回复。

从我们的度量结果来看，我们发现互联网上超过34%的开放式解析器存在漏洞（特别是85%的流行DNS服务，包括谷歌的8.8.8.8）。

此外，我们在受控实验和生产性DNS解析器（有授权）中，针对各种可能影响攻击成功的服务器配置和网络条件，用积极的结果全面验证了所提出的攻击。

关键词

DNS缓存投毒，侧信道，非中间人攻击，ICMP速率限制

1 介绍

域名系统（DNS）是互联网的一个重要部分，最初是为了将人类可读的名字翻译/转换成IP地址。

如今，DNS也已经被许多其他的安全关键应用所淹没，如反垃圾邮件防御，路由安全（如RPKI）。

此外，DNS在引导TLS的信任方面也起着关键作用。现在，TLS证书通常通过证明一个域名的所有权来获得。因此，对DNS记录的完整性作出承诺可能导致灾难性的安全故障，包括签发欺诈性证书，从而破坏公钥密码的基础。

---

从历史上看，第一个被广泛宣传的DNS缓存投毒攻击是由Kaminsky在2008年发现的，他证明了非中间人的攻击者可以注入欺骗性的DNS响应并让它们被DNS解析器缓存。

这导致了许多DNS防御措施被广泛部署，包括源端口随机化和“生日保护”。

其他防御措施，如0x20编码和DNSSEC也获得了一些吸引力。不幸的是，由于缺乏激励和兼容性等原因，这两种防御措施远没有被广泛部署，正如最近的研究报告所述。

总而言之，源端口随机化成为成功发起DNS缓存投毒攻击需要克服的最重要障碍。事实上，在过去，已经有先前的攻击试图取消DNS请求的源端口随机化。

到目前为止，它们只被认为是不错的概念性攻击，但不是很实用。具体来说，要求攻击者轰炸源端口并使套接字接收缓冲区过载，这不仅是缓慢和不切实际的（不太可能及时成功），而且只能在有严格RTT要求的本地环境中才能实现。在中，假定解析器位于允许其外部源端口被去随机化的NAT后面，但是这种情况不适用于拥有公共IP的解析器。

---

相比之下，我们发现的漏洞既严重得多，又普遍适用于广泛的场景和情况。具体来说，我们能够对现代DNS基础设施中普遍存在的所有层次的缓存发起攻击，包括应用层DNS缓存（如浏览器中）、操作系统范围内的缓存、DNS转发器缓存（如家用路由器中），以及最广泛被针对的DNS解析器缓存。

这些漏洞还影响到几乎所有流行的DNS软件栈，包括BIND、Unbound和dnsmasq，这些软件运行在Linux和潜在的其他操作系统之上，主要的要求是允许受害者的操作系统产生传出的ICMP错误信息。有趣的是，这些漏洞是由UDP标准的设计缺陷或微妙的实现细节造成的，基于ICMP错误信息的全局速率限制这一共享资源的侧信道允许攻击者很稳妥的完成源端口的去随机化。

为了证明这种影响，我们设计了针对两个主要场景的攻击方法，包括运行在家用路由器上的DNS转发器，以及运行BIND/Unbound的DNS解析器。在获得授权的基础上，我们还对每天为7000万用户提供查询服务的生产环境DNS解析器进行了攻击测试，克服了一些实际的挑战，如干扰、必须等待缓存超时/过期、在解析器前端IP后面的多个后端服务器IP，以及多个权威域名服务器。在我们的压力测试中，我们还在更具挑战性的网络条件下评估了该攻击，并报告了积极的结果。

在本文中，我们做出了以下贡献。

• 我们系统地分析了应用程序和操作系统级别的表现之间的相互作用，从而发现了一般的UDP源端口去随机化策略，其中的关键是一个由出站ICMP错误信息的全局速率限制引入的侧信道漏洞。

• 我们研究了源端口去随机化策略对各种攻击模型的适用性。此外，为了在进行去随机化攻击时有足够的时间，我们开发了新的方法来大幅扩展攻击窗口，其中一个方法再次利用了速率限制功能（这次是在应用层）。

• 我们针对各种各样的服务器软件、配置和网络条件进行了广泛的评估，并报告了积极的结果。我们表明，在大多数情况下，攻击者只需要几分钟就能成功地进行端到端的投毒攻击。我们还讨论了最简单且有效的缓解措施。

2 DNS缓存投毒攻击的现状

2008年，经典的DNS缓存投毒攻击针对DNS解析器，让非中间人的攻击者欺骗脆弱的DNS解析器，向上游权威域名服务器发出查询。然后，攻击者试图冒充域名服务器的IP注入恶意响应。如果恶意响应在任何合法响应之前到达，并且它与查询中的“秘密”相匹配，那么解析器将接受并缓存恶意结果。

具体来说，攻击者需要猜测正确的源/目的地IP、源/目的地端口和查询的事务ID（TxID）。事务ID为16位长。在源端口和目的端口（即53）都固定的时候，16位的事务ID是唯一的随机数。因此，一个非中间人的攻击者可以简单地用65536个恶意响应来强制测试所有可能的值，此外，如生日攻击等优化方法，可以进一步加速攻击。

2.1 最先进的防御措施

此后，一些防御措施被推广，以减轻DNS缓存投毒的威胁。它们有效地使原来的攻击不再可行。我们在下面描述最广为人知和广泛部署的防御措施。

• 源端口的随机化也许是最有效和最广泛部署的防御，因为它将随机数从16位增加到32位。作为一个非中间人的攻击者必须同时猜测源端口和TxID。

• 对域名中的字母大写进行随机化，即0x20编码。所提供的随机性取决于字母的数量，也可以是相当有效的，特别是对于长域名。不幸的是，尽管这是对协议的一个简单改变，但在实践中，它与互联网上的权威域名服务器间有很大的兼容性问题。因此，大多数流行的公共解析器现在默认不使用0x20编码。例如，谷歌DNS只对一组白名单上的域名服务器使用它；Cloudflare最近甚至完全禁用0x20编码。在撰写本文时，我们发现在我们检测的16个流行的公共DNS服务中，只有两个（即openNIC和Verisign）对我们设置的测试域名服务器默认使用它（其他14个见表2）。而这个结果与最近的一项研究中观察到的情况大致相符。

• 域名服务器选择的随机化（服务器IP地址）。提供的随机性取决于域名服务器的数量。在实践中，大多数域名采用不到10个域名服务器，在随机性上只相当于2到3位。此外，已经表明，攻击者可以诱导对某些域名服务器的查询失败，从而有效地将解析器“钉”在剩下的一个域名服务器上。

• DNSSEC。DNSSEC的成功取决于解析器和权威域名服务器的支持。然而，只有一小部分域名被签名——根据2017年的报告，.com域名为0.7%，.org域名为1%，Top Alexa 10K域名为1.85%。在同一研究中，还报告了只有12%启用了DNSSEC的解析器实际尝试验证收到的记录。因此，DNSSEC的总体部署率远远不能令人满意。

2.2 DNS结构中的新攻击面

正如前面所提到的，现代DNS基础设施有多层缓存。图1提供了一个简明的示意：客户端应用程序通常发起一个DNS查询（通过一个API调用，如gethostbyname()函数）到一个操作系统存根解析器——通常是一个单独的系统进程，维护一个操作系统范围的DNS缓存。存根解析器不执行任何迭代查询，它总是将请求转发到上一层，即一个DNS转发器，该转发器也负责向其上游的递归解析器查询。DNS转发器通常存在于Wi-Fi路由器中，它们也维护一个专门的DNS缓存。递归解析器做真正的工作：反复查询权威域名服务器。然后，答案被返回并缓存在各层。

从技术上讲，所有层次的缓存都会受到DNS缓存投毒的攻击。不幸的是，大多数新提出的攻击都集中在解析器上，而对存根解析器和转发器的研究非常有限。

图1：具有多层缓存的DNS基础设施

[Stub Resolver 存根解析器]⇄[Forwarder 转发器]⇄[Recursive Resolver 递归解析器]⇄(迭代)[Authoritative name servers 权威域名服务器]

3 攻击概述

我们提出了一种通用的、新颖的攻击方式，适用于所有现代DNS软件栈，影响到DNS缓存的所有层次。其关键特征是，它击败了最有效和最普遍的防御——源端口的随机化。

威胁模型

在本文中，我们专注于针对DNS转发器和解析器的攻击，因为它们的影响很大。与经典的DNS缓存投毒攻击类似，我们假设攻击者非中间人（无法窃听转发器和解析器之间的流量），并且有能力进行IP欺骗。根据2019年的一项最新研究，30.5%的应用服务器不阻止带有欺骗性源IP地址的数据包。在实践中，攻击者只需要找到一个可以进行IP欺骗的节点来进行攻击。为了证明这一点的容易性，我们租用了一个专门公开宣传为具有IP欺骗能力的防弹托管节点（50美元/月，数据无限），发现它确实可以冒充“任意IP”。

此外，攻击者需要控制一台能够触发转发器或解析器的请求的机器。转发器攻击可能会在攻击者位于一个由无线路由器管理的局域网中时发生。例如，攻击者可以加入一个咖啡馆、购物中心或机场的公共无线网络。攻击者还可以控制一台傀儡机，其作用是在无法直接进入局域网的情况下，向转发器发送查询请求来发动攻击。而在解析器攻击中，这可以包括任何网络（企业、组织或机构），其中攻击者是内部人员或拥有一台被入侵控制的机器。此外，互联网上的任何公共解析器也满足这一要求。

攻击工作流程

上图为攻击流程的示意，攻击者首先向受害者发出查询请求并使上游服务器静默，以获得较长的攻击窗口，然后对源端口进行扫描推断，得到正确的源端口后再对事务ID进行猜测，最终注入恶意响应。

不管是转发器还是解析器，如图2所示，我们新提出的攻击总是从触发其中一个发送DNS查询开始，然后是下面概述的两个关键步骤：

1. 推断源端口。为了克服源端口的随机性，我们利用网络栈中一个新的通用侧信道来扫描和发现哪些源端口被用来启动DNS查询，速度最多为每秒1000次猜测。
2. 扩展攻击窗口。通常，一个未完成的查询会在几十或几百毫秒内收到上游服务器的回复。这是不够的，因为攻击者需要时间来推断源端口和注入恶意的DNS回复。我们发现了有效和新颖的策略（对转发器和解析器的攻击是不同的），可以大大延长攻击窗口到至少几秒钟（甚至超过10秒），允许真实的缓存投毒机会。我们将在第5节讨论这个问题。

一旦知道了源端口号，攻击者只需注入大量欺骗性的DNS回复来破解TxID，鉴于大多数服务器有足够的网络带宽，这可以高速完成。

4 推断dns查询的源端口

在本节中，我们将描述推断DNS源端口的想法和程序。在可行的情况下，我们还将度量易受攻击的软件和非实验环境中的人群。

4.1 UDP源端口的可扫描性分析

UDP是一个无状态协议，因此与TCP有根本的不同。更具体地说，在UDP编程指南（RFC 8085）中指出：“UDP数据包可以直接发送和接收，而不需要任何连接设置。使用套接字API，应用程序可以在一个UDP套接字上接收来自一个以上的IP源地址的数据包。”此外，为了确保应用程序只从一个特定的源地址接收数据，“这些应用程序必须在应用层实现相应的检查，或明确要求操作系统过滤收到的数据包。”

这些声明令人惊讶地没有得到充分的验证。乍一看，它们可能被解释为只适用于UDP服务器，它们可以绑定到一个本地端口，然后接收来自“任何远程IP”的数据包。令人惊讶的是，从我们的实验来看，它也适用于UDP客户端——一个客户端在一个特定的远程IP上调用sendto()函数，随后在同一个套接字上调用recvfrom()函数，从技术上讲，也可以接收来自“任何其他IP”的数据包。我们已经在所有现代操作系统上验证了这种表现，包括Windows、Linux和MacOS。

这种表现对攻击者通过简单的UDP端口扫描所能了解到的信息有着深远的影响——当DNS服务器发出查询时，其源端口就会对公众开放。这使得攻击者可以用任何UDP数据包简单地扫描很短的端口范围，在访问正确的端口时不会触发任何东西（因为操作系统会接受探测包，但在应用层会被丢弃），或者在错过时触发ICMP端口不可达消息。

接下来，UDP编程指南（RFC 8085）进一步指出，“许多操作系统也允许UDP套接字被连接，即把UDP套接字与一对特定的地址和端口绑定”。事实上，现代套接字API允许在UDP套接字上进行connect()，但“这只是一个本地操作，用于简化本地发送/接收功能和过滤流量”。因此，当从一个源端口向一个特定的终点IP地址和端口发出DNS查询时，操作系统将只接受来自同一远程IP和端口的传入数据包。具体来说，当在真实的网络栈上测试该表现时，我们发现它们会拒绝带有错误IP或端口的数据包，并以ICMP端口不可达消息进行响应（就像该数据包是一个端口扫描尝试）。这有效地防止了DNS查询的源端口被直接扫描。

总之，源端口的可扫描性取决于DNS软件的实现，即是否在UDP套接字上发出connect()的API调用。有趣的是，我们发现，在三个最流行的DNS转发和解析软件BIND、Unbound和dnsmasq中，只有BIND使用connect()。尽管如此，我们还是开发了不同的扫描方法，可以适用于每一种软件（在4.3节和4.4节中描述，克服了下一节中概述的挑战。）

4.2 ICMP速率限制的挑战

有效扫描UDP源端口的一个主要障碍是普遍部署在终端主机上的出站ICMP错误信息的速率限制。即使是在源端口面向公共并且可以被任何IP地址直接扫描的简单情况下，攻击者的扫描速度也受到每秒允许的ICMP包数的限制（一个表明源端口未被使用的信号）。

从历史上看，ICMP速率限制首先被推荐用于限制路由器的资源消耗（在RFC 1812中描述），攻击者可以强迫它产生大量的ICMP错误信息。今天，速率限制机制已被所有主要的操作系统普遍实施。这里我们重点讨论Linux的ICMP速率限制，因为它是最流行的服务器操作系统，但之后会简要介绍其他操作系统的表现。

对于Linux来说，对于每秒可以发送多少个ICMP错误数据包，有每个IP和全局的速率限制。每个IP的速率限制在历史上是在Linux的早期版本中引入的，也就是说，在内核2.4.10中出现。全局速率限制是在内核3.18中引入的，以减轻开销很大的每个IP的速率限制检查（例如，红黑树操作）。

默认情况下，每个IP的速率限制是每秒一个（累积的最大突发次数为6），这将严重限制扫描速度；全局速率限制是每秒1000个（但累积的最大突发次数为50）。两者都是以令牌桶的方式实现的，每个IP的令牌以每秒一个的速度恢复，全局令牌以每毫秒一个的“名义”速度恢复（但实际的令牌恢复只发生在距离上次恢复至少20ms之后）。可用令牌的数量在任何时候上限都为50个。

我们还测试了Windows Server 2019（版本1809）、MacOS 10.15和FreeBSD 12.1.0，它们都有全局ICMP速率限制。具体来说，它们的限制分别为200、250和200。此外，它们都没有每个IP的速率限制。

4.3 面向公共的源端口扫描方法

即使一个源端口可以被任何攻击者的IP直接探测到，在unbound和dnsmasq中，也必须绕过每个IP的速率限制（主要存在于Linux中），以达到更快的扫描速度。我们开发了三种不同的探测方法，可以克服ICMP速率限制的挑战。

1. 如果攻击者拥有多个IP地址，如多个机器人机器，或是一台拥有IPv6地址的机器，那么绕过每个IP的限制是很容易的。IPv6地址分配规定，每个局域网都有一个/64前缀，实际上允许任何网络使用2^{64}个公共IP地址。我们在一个支持IPv6的住宅网络中的一台机器上进行了测试，在/64中挑选了几个IP，成功地发送和接收了流量。

2. 如果一个攻击者只拥有一个IPv4地址，仍然有可能使用DHCP请求获得多个地址。我们验证了在一个家庭网络中可以获得多个私有IPv4地址。此外，我们还在一个教育网络中进行了测试，一台物理机器也能够通过这种方法获得多个公共IPv4地址。

3. 如果攻击者只拥有一个IPv4地址，而上述方法由于某种原因而失败（例如静态分配的IP），那么最后一种方法就是利用IP欺骗来绕过每个IP的速率限制，并将全局速率限制作为一个侧信道来推断被欺骗的探测是否击中了正确的源端口，即无论是否有ICMP响应。正如最近在TCP背景下所显示的，全局速率限制可以引入严重的副作用。在这里，我们利用ICMP的全局速率限制来促进UDP端口扫描，我们接下来会介绍。

上图为对开放性的源端口的扫描过程示意，如果50个包中有一个包击中了正确的端口，那么ICMP端口不可达信息的令牌就会有剩余，这就会在验证包的响应结果中体现，而这50个包是用不同的源IP获得的。

图3说明了这一点。观察Linux中允许的全局最大突发的50个ICMP数据包，攻击者首先发送50个欺骗性的UDP探测数据包，每个数据包有不同的源IP（绕过每个IP的速率限制）。如果受害者服务器在这50个端口中没有开放任何源端口，那么就会触发50个ICMP端口不可达信息（但攻击者无法直接观察到这些信息）。如果受害者服务器有n个开放的端口，那么只有50-n个ICMP报文会被触发（因为n个UDP探测报文会在应用层被悄悄丢弃）。

完成上一阶段后，攻击者使用其真实的IP地址发送一个验证包，例如，一个UDP包，目的地是已知的封闭端口，如1端口。它要么没有得到响应（如果全局速率限制被耗尽），要么得到一个ICMP回复。

如果在第一阶段中没有发现端口，攻击者会等待至少50ms，让速率限制计数器恢复，然后开始下一轮。扫描速度将被限制在每秒1000个。因此，需要60多秒来列举由65536个端口组成的整个端口范围。尽管如此，这是一场胜利之战，因为攻击者可以简单地重复实验，一次实验成功的概率急剧增加（我们注意到这是一个简单的伯努利试验）。

时间考虑

这种方法有很强的时间要求。攻击者唯一要确保的是在一个突发的时间窗口中发送50个欺骗的探测包和验证包，使它们在20ms的窗口内被全部处理；否则，受害者可能开始恢复额外的令牌。另一个要求是，攻击者必须等待足够长的时间来恢复50个最大令牌。如果网络条件不理想，攻击者可以简单地等待超过50ms。

二分搜索，缩小到一个确切的端口

假设在一个特定的探测回合中，50个端口中有一个是开放的，那么我们就可以采用简单的二分搜索来快速缩小到确切的端口。在每一轮的二分搜索中，我们总是先探测范围的左半部分。如果是匹配的，即50个欺骗性的探测包触发了49个回复，并且攻击者可以观察到对其验证包的一个回复，那么我们继续搜索其左半部分。否则，我们假定该端口位于右半部，并将在那里进行二分搜索。请注意，我们将需要发送 "填充包"，以确保在50个猜测中没有一个击中正确的端口时，全局速率限制被耗尽。填充数据包是欺骗性的数据包，其目的地是已知的关闭的UDP端口，如1端口，这保证会触发ICMP回复。

处理干扰

DNS服务器通常同时为多个客户提供服务，产生多个未完成的DNS查询和源端口。因此，源端口扫描将可能发现许多不相关的端口。然而，大多数这样的查询是短暂的，端口扫描过程可以迅速发现一个开放的源端口在二分搜索中消失，并返回到线性搜索。相比之下，我们假设攻击者触发的DNS查询将持续更长的时间，例如，在秒级而不是毫秒级（见第5节）。

干扰的另一个来源是数据包丢失和包乱序。这可能导致假阳性结果：如丢失探测数据包或其回复，验证和探测数据包之间的乱序；以及假阴性结果：如丢失验证数据包或其回复（尽管在实践中非常罕见）。为了减少包乱序（如果抖动很大，可能会经常发生），我们在探测包和验证包之间插入一个延迟，根据经验确定该延迟大于两倍的抖动。当误报发生时，它们在二分搜索过程中被自动处理——程序将检测到没有真正的端口被打开，并返回到线性搜索。

即使它们可以被处理，过多的误报将迅速耗尽每个IP的速率限制。具体来说，鉴于令牌是以每秒一个的缓慢速度恢复的，高于这个速度的假阳性率将迫使扫描停止，直到令牌被恢复。实际上，每个IP的令牌是一个“扫描通行证”。为了解决这个问题，攻击者可以使用两个或更多的真实IP来获得更多的“通行证”。

此外，DNS服务器本身可能受到随机的UDP端口探测，因此产生ICMP不可达信息。这将导致假阴性结果：我们可能会误以为没有开放的端口，但实际上是有的，但因为由于干扰耗尽了速率限制，验证包将不会触发任何ICMP不可达的回复。幸运的是，并不是所有的ICMP回复都受到速率限制。例如，最常触发的ICMP回环回复不受限制。

4.4 私有的源端口扫描方法

如第4.1节所述，如果在一个UDP套接字上执行connect()函数，那么端口就有效地成为了远程对端的“私有”端口，从而使之前的方法失效。

我们的想法是用上游DNS服务器的源IP来发送欺骗性的UDP数据包。在DNS解析器成为受害者的例子中，我们可以发送UDP数据包，用权威域名服务器的伪造IP探测不同的源端口。如果它击中了正确的源端口，那么就不会产生ICMP回复。否则，就会有。然后，我们可以使用相同的全局ICMP速率限制作为一个侧信道来推断是否有这样的ICMP消息被触发。乍一看，这种方法可以工作，但由于ICMP消息的每个IP的速率限制，其速度很低，只有每秒一个端口。

令人惊讶的是，在我们分析了ICMP速率限制实现的源代码后，我们发现全局速率限制是在每个IP的速率限制之前被检查的。这意味着，即使每个IP的速率限制最终可能决定不发送ICMP回复，数据包仍然会受到全局速率限制的检查，并被扣除一个令牌。具有讽刺意味的是，这样的决定是Linux开发者有意识地做出的，以避免调用开销昂贵的每个IP速率限制的检查，这种检查涉及到一个搜索过程来定位每个IP的数据结构。

上图为对私有的源端口的扫描过程示意，与开放性源端口的区别仅在于需要伪装成上游服务器的IP，但由于全局速率限制的判定与消耗均在单个IP的速率限制判定之前进行，所以用侧信道信息探测端口的方法不会受到影响。

这实际上意味着，对于我们基于侧信道的扫描来说，每个IP的速率限制可以不被考虑，因为它只决定是否产生最终的ICMP回复，而与全局速率限制计数器的递减无关。因此，我们可以继续使用与以前大致相同的扫描方法，达到每秒1000个端口的效率。图4展示了稍作修改的扫描工作流程。与图3类似，攻击者首先发送了50个探测包，这次所有的探测包都使用了上游服务器的欺骗IP。由于每个IP的速率限制，只要至少有一个非活动端口被扫描，受害者服务器就会一直只产生一个ICMP回复（在稳定状态下），图中的左右两边都是这种情况。在50个探测包击中n个私有开放端口（对上游服务器）的情况下，全局速率限制计数器仍然减到n，因为受害者试图产生50-n个ICMP回复。相比之下，当所有50个探测包都击中非活动端口时（图中左侧），计数器减为0。

其余的程序与之前相同，可以启动二分搜索来缩小到一个特定的端口。

对面向公共的源端口扫描的影响

有了这个知识，我们可以对4.3节中的方法3进行如下改进：在每一轮探测中，我们不需要伪造50个不同的IP，而只需要使用一个伪造的IP（或攻击者拥有的第二个IP），而不是许多不同的IP（有时这可能是一个障碍）。

处理干扰

我们指出，与面向公共的源端口的扫描相比，这种扫描中的干扰本来就少。 这是因为每个源端口现在实际上只对最初在connect()中指定的一个单一的远程IP "开放"。 因此，假设受害者是一个解析器，它的大多数查询（即干扰）将被发送到不同的域名服务器而不是特定的攻击目标。其他干扰条件，如丢包和包乱序仍然适用。同样，干扰处理技术也适用（例如，使用一个以上的IP来减轻每个IP的ICMP速率限制）。

4.5 有漏洞的DNS转发器和解析器数量

如果一个DNS查询请求的UDP源端口可以被成功推断，或者更具体地说，如果转发器或解析器支持全局ICMP速率限制，和/或它不使用connect()（使端口公开），则可被认为有漏洞。

有漏洞的转发器

我们调查了六台家用路由器设备，它们都是默认支持DNS缓存的转发器。它们的表现总结于表1中。

只有一个路由器（华为A1）甚至没有响应ICMP端口不可达消息，这是端口扫描的一个基本要求。Verizon网关没有受到攻击，因为它是唯一使用connect()但没有全局速率限制的路由器。我们发现，所有的路由器都在运行2.6到3.10范围内的旧Linux内核版本，这就是没有观察到全局速率限制的原因。 我们确实相信，新一代的路由器最终会继承全局速率限制。尽管如此，由于它们中的大多数没有在UDP套接字上使用connect()，因此可以很容易地探测到DNS查询的源端口，而不需要利用基于全局ICMP速率限制的旁路。此外，我们还度量了局域网内的IP欺骗能力。具体来说，如果攻击者能够从通常在私有IP范围内运行的局域网内对解析器进行公共IP欺骗，那么端到端攻击就可以单独从局域网内的一台机器上进行，不需要任何外部合作者。结果显示，有三台路由器属于这一类（Y1），有一台可以从能够对解析器进行IP欺骗的外部机器中进行攻击（Y2）。

有漏洞的解析器

我们研究了表2所示的14个流行的DNS供应商，发现其中12个存在漏洞，这是非常严重的。有趣的是，我们发现，由于在几个供应商中遇到的防火墙政策，探测数据包的源端口必须设置为53，目的端口也应在较短的端口范围内，以在一些服务器上触发ICMP响应。

请注意，我们还报告了在任播的前端IP后面的后端服务器IP的数量（例如，8.8.8.8）。这些后端IP对应于我们可以扫描端口的可达服务器。多个这样的IP的存在增加了攻击的难度，因为我们需要决定扫描哪个或哪些IP。为了发现后端IP，我们只需从同一台机器向前端发送100次查询，并在我们拥有的权威域名服务器上记录观察到的IP。对于我们只遇到几个IP的情况，我们可以简单地同时扫描所有的IP。对于OpenDNS和AliDNS有超过100个的情况，我们在后面的第6节讨论可能的处理技术。请注意，OpenDNS和AliDNS表现出超过100个IP，是因为我们的权威域名服务器有意丢弃传入的查询，它们决定在放弃之前每次都用潜在的新IP重试。

此外，我们还测量了开放解析器的总体情况。与公共解析器相比，开放解析器通常是广告性的，旨在为公众提供服务，然而，开放解析器通常是未列出的，旨在为较小数量的客户提供服务。我们从Censys获得了一个开放解析器的列表，并设法探测了一组138,924个可用的IP，其中有70,503个的后端和前端IP是相同的，表明没有任何任播的情况。此外，138,924个案例中的41.3%产生了ICMP回复（遵循探测数据包中使用源端口53的相同做法），其中67.56%表现出全局速率限制，53.93%在套接字上使用connect()。总的来说，34.36%的案例存在漏洞，因为它们要么支持全局速率限制，要么没有使用connect())。他们中的大多数没有受到攻击，只是因为缺乏ICMP回复。

5 扩展攻击窗口

攻击窗口越长，攻击者就可以扫描更多的端口，也有更多的时间来注入恶意记录。因此，我们的目标是使上游服务器“静默”，防止它们对攻击者引发的DNS查询作出反应。根据攻击目标（即转发器或解析器），我们想出了两种新的策略。具有讽刺意味的是，其中一个策略再次利用了通常部署在应用层的“速率限制”功能，这可以转为攻击者的优势。

5.1 在转发器攻击中扩展窗口

我们提出了一个新颖的策略：攻击者首先向转发器发送他自己域名的查询，例如www.attacker.com，这将最终触发上游解析器查询攻击者控制的权威域名服务器。该域名服务器被故意配置为无响应，以便转发者在留下一个开放端口的同时，尽可能多地等待（因为解析器也被停止了）。乍一看，这是毫无意义的，因为我们不需要对攻击者自己的域名投毒。然而，由于DNS转发器的独特作用，它们完全依赖上游解析器来对响应进行验证。

更具体地说，根据RFC 8499，递归解析器的责任是处理一个域名的完整解析，并向其客户提供“最终答案”。这包括递归处理转介和CNAME，并集合一个最终答案，包括设计的任何CNAME重定向。更重要的是，解析器被重新要求执行完整性检查，如bailiwick检查，而转发器则没有。这意味着转发器在设计上信任上游的解析器和它的响应。这不是一个安全缺陷，而是一个设计选择，以防止转发器重复解析器的工作。在最近关于DNS转发器安全的研究中也提出了这一观点。

图5：转发器可接受的恶意响应示例（受害者域名记录也被缓存）

图中用CNAME记录将受害者域名链入查询的记录中，最后附上受害者域名的恶意A记录，受到攻击的转发器就会将该域名记录缓存。

因此，图5所示的恶意响应（可能是攻击者从局域网或外部注入的）将被转发器接受，攻击者和受害者的域名记录都将被缓存。这种策略非常有效，因为我们可以对转发器施加最大的等待时间（即创造最大的攻击窗口）。具体来说，大多数转发器都有一个非常宽松的超时时间（有时接近一分钟，例如在dnsmasq中），并将主要因为上游解析器先产生（范围从5到30秒不等）一个SERVFAIL响应（或NXDOMAIN）消息的失败而停止。为了防止解析器过早地产生这样的消息，我们还采用了一种技术，有时可以让解析器参与更长时间。这个技巧是让攻击器拥有的权威域名服务器用一连串的CNAME记录以缓慢的速度响应，制造一种它正在取得进展的假象。在某些情况下，这可以使解析器的响应延迟超过一分钟（例如，CloudFlare）。

5.2 在解析器攻击中扩展窗口

我们提出利用权威域名服务器的速率限制的安全功能，作为在解析器攻击中静默域名服务器和扩展窗口的一种方式。现代DNS域名服务器软件，如BIND、NSD、PowerDNS，都支持一个共同的安全功能，称为响应速率限制（RRL），作为对DNS放大攻击的缓解。这种攻击中大量冒充受害者IP地址的恶意DNS查询被发送到权威域名服务器。为了限制放大的DNS回复数据包的数量，RRL功能允许配置每个IP、每个前缀、甚至是全局的触发回复的限制。具体来说，如果达到限制，那么响应要么被截断，要么被丢弃。也有专门的DNS防火墙具有类似的功能。

参考：DNS放大攻击

具有讽刺意味的是，如果攻击者能够以高于配置限制的速度注入欺骗性的DNS查询（使用目标解析器的IP），那么这一功能可以被恶意利用，使域名服务器静默。根据实际限制（有些被配置为非常低），造成一个足够高的“丢包率”可能是轻松的，这样解析器的合法查询获得响应的概率极低。为了了解这种策略成功的可能性有多大，我们进行了一项实验，测量前10K Alexa网站使用的域名服务器的响应率。

测量方法

为了触发RRL，我们每秒发送1K次查询，持续15秒，然后向每个域名服务器IP发送另一轮4kpps的测试，持续15秒；这两个测试之间有两秒的间隔，以避免干扰。如果一个给定的域名有多个域名服务器，我们挑选第一个。在这两种情况下，查询都是均匀分布的（而不是突发发送），都试图询问www子域的A记录。其原因是，1kpps和4kpps代表足够低的吞吐量，大约分别为0.6Mbps和2.5Mbps，这是互联网上任何攻击者都可以轻易实现的。

伦理上的考虑

我们有意识地采取了一些措施来限制对这些服务器运行的影响。首先，我们在查询中要求提供A记录，这通常会得到较小的响应，以节省目标网络的资源；而且，先前的报告表明，速率限制行为通常与查询的类型无关（因此这不会影响我们的测量结果）。第二，查询中的域名总是相同的，使服务器上的处理开销最小（结果可能被缓存在内存中，容易获取）。第三，我们选择均匀地发送查询（而不是突发），以避免给服务器带来压力。一般来说，4kpps的流量与一个顶级Alexa网站的域名服务器所承载的正常负载相比是很小的。最后，我们在用于进行探测的IP地址上设置了一个网络服务器，提供一个带有退出指示的网页（我们还配置了该IP的反向DNS域名，以引导访问者进入我们的网页）。总之，我们完成了这四点要求。

结果

我们按照在4kpps测试中观察到的丢包率对域名进行降序排序，并在图6中展示结果。总的来说，大约有25%的域名的域名服务器呈现了高于1%的丢包率。这与最近的测量结果一致，报告了大约17%的丢包行为的案例。差异可能是由于他们在500pps的查询率较低。

我们现在试图分析这些域名中有多大一部分是脆弱的（可以被成功静默）。在这里，如果一个域名的服务器表现出66.7%或更高的诱导丢包率，我们就将其定义为易受攻击的域名；这个阈值是根据经验确定的，将在第7.2节中讨论。具体来说，有13110个域名已经满足了这个标准，并成为4kpps速率的简单拒绝服务攻击的受害者。

此外，我们还检查了其余的从1kpps测试到4kpps测试中丢包率增加的案例。大约有5000个案例，其差异为2%或更高。我们认为，鉴于探测速率的增加，其中大部分可以进一步增加，因此也有可能是脆弱的。因此，在10万的案例中，我们认为共有18110（13110+5000）（18%）个案例是脆弱的。

最后，在1kpps和4kpps测试都没有丢包的75%的案例中，我们相信可能还有许多脆弱的案例，但由于探测速度相对较低，我们无法发现。然而，出于道德方面的考虑，我们避免了以更高的速度进行探测。为了观察这些情况，我们设法从一个合作者那里获得许可，测试一个为非营利性网站配置的权威域名服务器。我们能够以更高的速度探测该服务器（在深夜以避免干扰）。最初，当以4kpps的速率探测时，没有观察到丢包。有趣的是，当探测速率增加到25kpps时，它开始出现丢包。具体来说，当速率增加到50kpps时，丢包率跳升到75%。我们向我们的合作者核实了服务器是否确实被配置为使用如此高的速率限制。令我们惊讶的是，他们的服务器完全没有配置速率限制。为了理解这种情况，我们在本地复制了一个BIND服务器（复制了配置），并验证了在相当的探测速度下确实很容易触发高丢包率。 我们发现这是因为应用程序（即BIND）从套接字队列中读取的速度不够快，从而导致溢出。事实上，历史上与此类似的拒绝服务攻击，例如，通过用随机域名淹没查询，在实践中已经被观察到。为了减轻这种威胁，官方的BIND明确指南推荐了速率限制，这就矛盾地使它反而容易受到我们的攻击。

此外，我们可以利用这一技术来扩展针对转发器的攻击窗口，因为RRL也被部署在解析器上，以限制传入查询的速率。遵循之前测量中的相同程序和道德标准，针对从Censys获得的解析器IP，使用4kpps的探测速率，我们观察到136547个解析器中竟然有121195个显示出超过66.7%的丢包率，这表明在互联网上将解析器静默是普遍可行的。

6 实际的攻击考虑

绕过缓存记录的TTL

如果攻击者试图通过在解析器上直接触发www.victim.com的DNS查询来向一个良性域名投毒，它可能会缓存不符合攻击者预期的合法A记录，例如，由于偶然不能成功令其上游服务器静默。这迫使攻击者在启动下一次攻击尝试之前等待缓存超时。

然而，根据最近的一项研究，www.victim.com的缓存A记录可以通过注入一个不存在的NS记录来覆盖www.victim.com。具体来说，攻击者总是发送查询，要求获得具有随机前缀的域名的A记录，例如，{nonce}.www.victim.com，其中{nonce}是一个随机值。这迫使解析器向victim.com的权威域名服务器发起新的查询，因为该记录没有被缓存。然后攻击者试图注入一个恶意响应，如图7所示，声称www.victim.com是一个独立的区域，有自己的权威域名服务器ns.attacker.com。然后，在原始缓存记录过期后，解析器未来的所有请求向ns.attacker.com查询，以获取www.victim.com的A记录。这是因为攻击有效地插入了www.victim.com域名的一个新NS记录。而解析器在设计上被建议使用它在缓存中的最准确的授权，在这种情况下，它是www.victim.com的NS记录，而不是victim.com的记录。我们已经验证了这种方法在BIND和Unbound的最新版本中都是有效的。

超时和重传的查询

当DNS查询在转发器或解析器上被触发，并且没有从其上游收到合法的回复时，它们不会永远等待。它们中的大多数都有一个超时器，决定何时关闭当前的套接字（以及相应的源端口）并重新传输。这意味着其中一些源端口可能是短暂的，很难被我们获取。因此，更深入地了解它们的行为表现很重要。

在大多数DNS软件中，如BIND和Unbound，我们在文档和源代码分析的帮助下进行了实验，并总结了它们的表现（这些行为表现通常与我们在真实解析器中观察到的情况相匹配）。具体来说，转发器的表现与解析器相似，但通常有更长的超时时间（而且一般来说，使用不同的策略更容易延长它们的攻击窗口）。因此，我们在下面集中讨论解析器的表现。

在没有故障的情况下，BIND和Unbound都保持一个默认的重传超时（RTO）——对于BIND是0.8s，对于Unbound是一个基于RTT的动态计算值（到权威域名服务器）。如果发生超时（例如，域名服务器无响应或静默），如果有多个域名服务器可用，他们将以循环方式联系另一个域名服务器。如果所有的服务器都没有响应，他们将通过加倍RTO的方式进行指数级的退避（BIND只在3次有结果的失败后才开始退避，而Unbound在每次失败后都会进行退避）。最后，还有一个硬停止条件——BIND默认10s的总等待时间，Unbound默认16到32次试验（取决于查询的类型）。如果满足硬停止条件，一个SERVFAIL将被送回给客户。

这里我们把RTO称为“攻击窗口”，因为它代表一个源端口保持不变的时间。当窗口结束时，将选择一个不同的源端口，使之前的任何端口扫描进度无效——一个新的端口可能碰巧弹回到刚刚扫描过的范围。需要注意的是，当攻击窗口太小时（如1s），即使端口被正确识别，仍然需要时间来注入64K的恶意DNS记录（在100kpps的数据流速率下，可能仍然需要几百毫秒），这可能在窗口关闭前无法完成。

一般来说，如果权威域名服务器在较长的时间内处于静默状态，我们确实希望看到更大的攻击窗口（因为RTO在失败的尝试中翻倍）。由于BIND在翻倍RTO方面比较困难，并且有一个比较严格的硬停止条件（默认10s），我们认为它是一个比较困难的攻击目标。我们在第8节中描述了一个针对这种困难情况的实验。

处理多个权威域名服务器

在实践中，为了冗余和安全，许多域都配置了多个权威域名服务器IP。有些人认为这是对解析器受DNS缓存投毒攻击的一种特殊防御措施（称为“IP随机化”），因为它增加了DNS查询的随机性。根据最近的一项测量研究，在.com、.net和.org等顶级域名下，像example.com这样的二级域名只有2个NS的中位数（平均数为2.3、2.4和2.4）；因此这本身不是一个很有效的防御。

有两种方法来处理这个问题。首先，一个一般的策略是同时使所有的权威域名服务器静默，因为平均来说，这些服务器很少存在。这将有助于RTO在解析器与所有域名服务器联系时经历反复失败后呈指数级增长。

第二，如果一个解析器是Unbound，它有一个独特的行为，即如果它多次未能听到最初联系的服务器的消息，它将停止联系一个域名服务器（将该服务器列入黑名单），并“永久”（即几分钟）切换到其他可用的服务器。 因此，可以利用这一行为来执行他们所说的“域名服务器固定”。在我们的案例中，我们需要周期性的允许成功响应（通过暂停静默过程）；这是为了避免其余域名服务器也被封锁。

处理DNS解析器后面的多个后端服务器

正如第4.5节所述，许多公共DNS解析器有多个后端服务器（有不同的IP）来执行实际查询。有趣的是，我们发现后端服务器的选择通常严重偏向于少数几个（即使我们看到一些供应商总共有100多个），可能是基于位置和过去的性能测量而决定的。这允许我们只需要同时关注几个IP，考虑到每个IP只需要1kpps的扫描流量，这是很容易实现的。

7 端到端攻击

在本节中，我们在真实环境中评估了我们的攻击，包括在家庭中使用的转发器，以及具有真实配置和网络条件的生产环境中的解析器。

7.1 攻击一个转发器（家庭路由器）

实验设置

鉴于大多数易受攻击的路由器具有表1所示的相当类似的表现，我们选择小米R3（一个Wi-Fi家庭路由器）作为一个代表性的案例研究，以发起端到端的攻击。它被用作实际家庭中唯一的网关，有10到15台设备一直通过无线路由器连接到互联网。此外，小米R3的上游DNS服务器被设置为CloudFlare DNS（1.1.1.1）。它的DHCP服务器默认配置为在/24网络中提供253个IPv4地址。 最后，攻击机器是Raspberry Pi，它也以无线方式连接到路由器上。

由于小米R3没有部署全局ICMP速率限制，其转发软件也没有在UDP套接字上调用connect()，我们使用4.3节中的策略2（通过DHCP获得多个IP）来绕过其每个IP的速率限制。对于扩展攻击窗口，我们使用5.1节中描述的策略1，并使用一个恶意的域名服务器。

攻击过程

攻击分为两个阶段，在第一阶段，攻击者尝试使用DHCP策略获得240个IP地址。之后，攻击进入第二阶段，重复以下过程：攻击者向转发器发出查询，要求提供一个任意的子域，例如nonce.attacker.com。如果收到SERVFAIL/NXDOMAIN，或者攻击者等待时间超过1分钟，表明有问题，我们将通过发出另一个查询重复攻击过程。否则，如果收到NOERROR响应，就意味着成功地注入了一个伪造的响应。在第二阶段，攻击者使用获得的IP地址来扫描路由器上的开放端口。我们在可用的IP之间进行轮换，并确保我们永远不会超过每个IP的速率限制（在稳定状态下是1pps）。在发现一个开放的端口后，我们通过重复探测同一端口，确认它至少保持一秒钟的开放。如果它是这样，我们就开始注入恶意响应。该实验重复了20次，我们报告了成功率、平均成功时间和其他统计结果。

结果

总的来说，该攻击非常有效，在20次实验中，成功率为100%（如果攻击在30分钟内完成，我们认为是成功的）。平均成功时间为271s，其中第一阶段为103s，第二阶段为168s。第二阶段的标准偏差为109s，最大为739s，最小为83s。

差异很大的原因是攻击时间主要由攻击窗口大小决定，也就是5.1节中提到的解析器决定放弃并返回SERVFAIL/NXDOMAIN之前的超时时间，而CloudFlares的解析器的超时时间变化很大（从几秒钟到超过一分钟，原因不明）。另外，该攻击平均需要扫描36325个端口才能成功；平均端口扫描速度为210pps，这与使用240个IP进行扫描时的预期速度240pps大致相符。此外，该攻击产生了78MB的流量。

7.2 攻击生产环境的解析器

尽管该攻击理论上可以对很大一部分公共DNS解析器起作用，但由于明显的法律和道德原因，我们避免针对其中任何一个解析器。幸运的是，我们获得了授权，对一个由合作者管理的生产环境的解析器进行攻击测试。

实验设置

该解析器每天处理约7000万次查询，涉及多个机构的数千名真实用户，并被配置为一个开放式解析器。正因如此，它是嘈杂的，代表了一个具有挑战性的攻击目标。另一个值得注意的表现是，它有两个后端服务器，这两个服务器似乎都在UDP套接字上使用connect()。有趣的是，我们被告知他们正在运行Unbound，我们怀疑类似connect()的行为可能是由于负责过滤非状态数据包的有状态UDP防火墙。我们在相邻的网络中得到了一台攻击机——离解析器4跳，它有一个1Gbps的以太网，可以进行IP欺骗。

同时，我们设置了一个测试域名，并将其托管在由我们控制的权威服务器上，这样我们就只污染我们自己的测试域名。我们将BIND软件的响应速度限制配置为10pps的低速率，以减少对网络的影响。

当达到该速度限制时，我们在每5个响应中允许1个——有效丢包率为80%。这构成了基线实验的设置，我们进行了20轮实验，其中一轮是在白天，另一轮是在当地时间午夜之后（如表3所示）。此外，为了了解响应速率限制对权威域名服务器的影响，我们通过配置75%、66.7%和50%的丢包率来改变静默水平——丢包率越低，攻击就越困难。

作为比较，我们还通过在同一台攻击机上施加额外的延迟、抖动和丢失，模拟了更现实的网络条件。确切的数字见表3，其中基线代表未修改的网络条件，其余代表模拟的条件。我们参考了最近的互联网测量结果来计算这些数字。我们相信攻击者很可能可以找到条件更好的网络。为了处理由模拟网络条件引起的假阳性的增加，我们在改变的实验中使用了两个IP来发动攻击；这是为了降低由于每个IP的令牌被耗尽而停止扫描的频率（参考4.3节）。

最后，我们有兴趣探究参数“域名服务器静默水平”对攻击可行性的影响，并将进行一个实验，改变“静默水平”，所有其他参数与基线参数相同。

攻击过程

这个过程同样从攻击者生成询问nonce.attacker.com的查询开始。由于解析器有两个后端服务器IP，我们同时对两个IP进行端口扫描。同时，我们以20pps的速度使所有权威域名服务器的查询静默，这样解析器将保持80%的恒定丢包率。该实验对基线和改变后的实验分别重复20次和5次。

结果

如表3所示，我们在第一个基线实验Base(D)中取得了完美的100%成功率（在白天），平均成功时间为504s。标准偏差为399s，最大为1404s，最小为13s（只是由于幸运）。平均来说，只产生了69MB的攻击流量，尽管解析器攻击需要更长的时间才能成功，但结果与转发器攻击中的流量相似。这是因为转发器攻击更有可能进入TxID破解阶段（6次比2次），每次都会产生约10MB的流量。具体来说，在转发器攻击中使用的策略2没有二分搜索阶段，一个开放的端口在进入TxID破解阶段之前被简单地确认两次，而在解析器攻击中使用的二分搜索阶段则反复检查一个开放端口的存在。

在检查了详细的日志后，我们发现，即使Base(D)实验有一个近乎完美的网络条件，但相比转发器攻击发送了更多的数据包。这是因为解析器重试（即RTO）或攻击者发起的新查询（如果解析器恰好收到合法的响应）所引起的源端口的频繁变化，产生了许多碎片化的攻击窗口。事实上，我们发现这些零散的攻击窗口中有一半以上小于1秒，这使得它们不符合期望。有趣的是，我们确实发现了相当一部分大的攻击窗口（其中10%的攻击窗口有30秒或更大）。这样长的攻击窗口符合Unbound解析器的特征——最大允许16次重传，每次都将RTO倍增。在第8节，我们证明了通过小很多的攻击窗口对BIND进行攻击似乎仍然是可行的，但需要更长的时间才能成功。

如表3所示，Base(M)实验的设置与Base(D)实验完全相同，只是在午夜之后进行，背景流量和干扰普遍较低。我们观察到同样的100%的成功率和平均成功时间从504s减少到410s。这是符合预期的，因为我们的攻击对干扰很敏感。

此外，对于表3所示的静默水平实验，除了50%的静默水平（即丢包率），其他都还能达到近乎完美的成功率，一般能在一小时内完成（注意66.7%的静默水平的成功阈值是3小时）。对于50%的静默水平，在20个案例中，攻击只成功了9个。此外，所花的平均时间是8985s，也即2.5小时。

最后，对于改变后的实验，我们也取得了100%的完美成功率。具体来说，成功的时间分别为2005s、538s、792s、1287s和29s。平均而言，攻击时间为930s，产生131MB的流量。请注意，改变后的实验中的扫描速度高于基线实验。这是因为我们在改变后的实验中使用了两个IP，减少了扫描过程中的停止频率。

我们还发现，丢包率和抖动的增加导致了更多的假阳性结果，即我们错误地认为发现了一个端口（因为验证包成功地取得了一个ICMP回复）。这通常是由探测数据包的丢失引起的，这会造成两个问题：（1）我们在二分搜索阶段浪费了很多时间来过滤这些假阳性结果，降低了有效的扫描速度；（2）由于每个IP的ICMP令牌频繁耗尽，即使我们使用了两个IP，扫描仍然可能被停止。

8 讨论

针对Unbound与BIND的攻击

如前所述，对BIND攻击将比对Unbound艰难得多，因为大多数碎片化的攻击窗口一般都比较小，因为BIND更不愿意将RTO翻倍，并且有一个更严格的硬停止条件（如第6节所述）。为了了解攻击BIND解析器是否可行，我们构建了一个极端的实验，有4个名字服务器，BIND解析器的默认硬停止条件是10秒的等待时间，结果解析器几乎总是保持在0.8秒的小攻击窗口，因为查询4个名字服务器3轮已经需要9.6秒（在RTO退避之前）。这个实验是在一个与基线实验类似的网络环境中进行的。令人惊讶的是，我们运行了两次实验，都成功了（一次在0.54小时，另一次在1.25小时）。我们发现，确实有可能在0.8秒的时间内成功扫描一个端口，并注入恶意记录。我们检查的一次攻击显示，端口扫描花了600ms，记录注入花了200ms。

其他操作系统上的UDP源端口推断

除了Linux，我们还验证了其他主要的操作系统内核也有漏洞，尽管其全局速率限制较低——Windows和FreeBSD为200，MacOS为250。令人担忧的是，没有一个操作系统意识到全局速率限制的侧信道潜力，尽管最近有严重的侧信道专门利用了TCP中的挑战ACK全局速率限制。我们认为，网络堆栈中的所有全局速率限制都需要被仔细检查，无论其最初的设计目标如何。我们相信这项工作可以作为另一个有价值的参考。

其他脆弱的协议

任何基于UDP的协议都会受到源端口推断的影响。一个突出的例子是QUIC和HTTP/3，它们准备用一个更有效的基于UDP的协议来取代传统的基于TCP的网络协议。它们已经被广泛部署在谷歌的网络服务中。此外，VoIP、视频流和对延迟敏感的在线游戏也可能使用UDP，这些都会受到端口推断，甚至是非中间人的数据包注入攻击。

配置响应速度限制（RRL）的最佳做法

尽管权威域名服务器的响应速率限制是对DNS反射/放大攻击的重要缓解措施，但如果不小心，它可以允许在DNS缓存投毒攻击中扩展攻击窗口。我们赞同RRL行为（该行为可配置，但并不总是使用），即当达到速率限制时，服务器仍以截断的信息进行响应，而不是沉默。这样，放大系数就不再对DDoS攻击者有利了。然而，它向解析器发出了一个强烈的信号，表明发生了一些不好的事情，解析器应该立即做出反应，例如，要么切换源端口并发送一个新的查询，要么完全退回到TCP。与服务器完全静默（100%丢包）的情况相比，这种策略可以减少RRL被恶意利用的可能性。不幸的是，正如我们在解析器攻击中所显示的那样，即使是66.7%的丢失率也已经使服务器变得脆弱，更不用说拥有更多资源的坚定的攻击者可以简单地用昂贵的查询来淹没服务器（例如对不存在的域名）。

8.1 防御措施

我们所提出的攻击从根本上说是一种非中间人攻击，因此可以通过额外的随机性和加密措施来缓解。除了DNSSEC和0x20编码，还有一个新兴的功能，称为DNS cookie，在2016年的RFC 7873中得到了标准化。在更高层级上，它要求客户端和服务器交换一些非中间人攻击者不知道的额外秘密；因此，它有可能击败大多数（如果不是全部）非中间人的DNS攻击。请注意，这项功能要求解析器和权威域名服务器都要升级才能有收益。到目前为止，只有BIND实现了这一功能，并在9.11.0 forward（2016年发布）中默认开启了它。

我们发现，在我们测量的开放式解析器中，约有5%默认启用了这一功能。然而，就像任何其他未经证实的技术一样（关于0x20的教训），兼容性等问题是否会阻止它被广泛采用，还有待观察。有趣的是，我们已经发现DNSPod（由腾讯运营）和一家私营公司的解析器都放弃了带有DNS cookie选项的查询，可能是出于兼容性的考虑。

此外，我们的攻击依赖于两个基本组成部分：(1) 推断DNS查询的源端口；(2) 扩展攻击窗口。它们中的每一个都可以单独成为安全威胁，因此我们讨论如何解决这两个问题。

对于(1)，最简单的缓解措施是完全不允许向外发送ICMP回复（正如许多服务器所做的那样），其潜在的代价是失去一些网络故障排除和诊断功能。否则，我们需要解决全局速率限制。与TCP全局计数器的补丁一样，我们建议采用随机化的ICMP全局速率限制，包括可能随机化的最大允许突发数（目前为50）、每次恢复的最小令牌数（目前为20）、恢复令牌的最小空闲时间（目前为20ms）和每时间单位恢复的令牌数（目前为每毫秒1个）。当侧信道的问题被缓解时，我们也建议解析器在他们的UDP套接字上采用connect()，这样他们的源端口就不会面向公共并可直接扫描。

对于(2)，我们已经讨论了使用RRL的最佳做法，以防止攻击者轻易地使权威域名服务器失效。其他简单的缓解策略包括。(1) 更积极地设置DNS查询的超时（例如，总是低于1s）。这样，源端口将是短暂的，并在攻击者开始注入流氓响应之前消失。然而，缺点是有可能引入更多的重传查询和整体性能更差。(2) 采用任播，使攻击者更难对受害者解析器使用的特定权威性域名服务器进行DoS。

9 相关工作

DNS盲目伪造攻击和高速缓存投毒

在2008年提出的DNS缓存投毒攻击之后，许多防御措施已经被应用，使得这种盲目的非中间人攻击变得更加困难。例如，Herzberg和Shulman提出了一种方法，通过占用NAT上除一个端口以外的所有端口，在与解析器相同的网络中，对NAT后面的解析器的源端口进行去随机化，并且还提出了一种利用IP碎片的域名服务器固定方法。不幸的是，这种攻击不适用于拥有公共IP广播的解析器（我们认为这是一种常见的情况）。Alharbi等人进行了类似的攻击，用尽了客户机上的本地端口，并污染了整个操作系统的DNS缓存。

后来，Herzberg和Shulman的另一项工作提出了一种新的IP分片技术来针对解析器。这项技术消除了猜测随机化源端口号、服务器地址和查询域名等的要求。相反，只有IPID成为需要被猜测的秘密。关键的假设是受害者域名的响应是自愿分片的（例如，当DNSSEC被启用时）。Brandt等人的一项更近期的工作通过向权威域名服务器注入ICMP分片所需的错误消息，主动降低其MTU（相对于解析器而言）并诱导分片，从而放松了该约束条件。攻击取决于具体的服务器配置，因为许多服务器只是拒绝这样的ICMP数据包，或坚持一个大于DNS响应碎片的最小MTU。此外，随着时间的推移，更多的随机性被引入，因此精确预测IPID变得更加具有挑战性。尽管如此，Wang等人通过使用攻击者拥有的权威域名服务器强迫分片，开发了一种针对DNS转发器的新型攻击。

总的来说，与以前的工作不同，我们利用了一个基于ICMP全局速率限制的通用网络侧信道，我们显示它是普遍存在的。此外，我们的攻击对所有层的DNS缓存（不仅仅是解析器）都有完美的效果。

网络侧信道漏洞

几十年来，研究人员一直在使用网络侧信道来推断敏感的网络信息，例如，端口扫描，TCP序列号推断等。

唯一可以被归类为DNS源端口推断的工作是Herzberg和Shulman的。作者提出使用低速率的突发数据包，使解析器上的特定源端口过载，这有可能导致以这些端口为目的地的合法DNS回复被放弃。这创造了一个计时侧信道——较长的端到端响应时间（由触发请求的恶意客户端观察）表明一个端口被使用，而较短的则表明它没有被使用。不幸的是，这需要攻击者和解析器共同位于低延迟的网络环境中，例如局域网，因为它对网络噪音很敏感。相比之下，我们的源端口扫描技术更加直接和可靠，因此可以在远处进行。

此外，利用网络协议中的全局速率限制作为一个侧信道的概念已经被记录在一些重要的工作中。例如，TCP RST速率限制，TCP挑战ACK速率限制在过去已经被证明和报告。ICMP速率限制原则上没有什么不同，尽管它可能更微妙，因为它在跨层（即UDP和ICMP）的互动中显示出来。

10 结论

本文提出了一种基于全局ICMP速率限制的新颖而通用的侧信道，普遍应用于所有现代操作系统。这允许对DNS查询中的UDP源端口进行有效扫描。结合扩展攻击窗口的技术，它导致了DNS缓存中毒攻击的强大复兴，并在现实的服务器配置和网络条件下通过真实世界的实验进行了证明。最后，我们提出了实用的缓解措施，可以用来提高攻击者进行这类攻击的门槛。

REFERENCES 参考文献

1 D. Eastlake 3rd and M. Andrews. 2017. RFC 7873, Domain Name System (DNS) Cookies. https://tools.ietf.org/html/rfc7873.

2 Josh Aas, Richard Barnes, Benton Case, Zakir Durumeric, Peter Eckersley, Alan Flores-López, J. Alex Halderman, Jacob Hoffman-Andrews, James Kasten, Eric Rescorla, Seth Schoen, and Brad Warren. 2019. Let’s Encrypt: An Automated Certificate Authority to Encrypt the Entire Web. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (CCS ’19).

3 G. Alexander and J. R. Crandall. 2015. Off-path round trip time measurement via TCP/IP side channels. In 2015 IEEE Conference on Computer Communications (INFOCOM).

4 Geoffrey Alexander, Antonio M. Espinoza, and Jedidiah R. Crandall. 2019. Detecting TCP/IP Connections via IPID Hash Collisions. In PoPETS.

5 Fatemah Alharbi, Jie Chang, Yuchen Zhou, Feng Qian, Zhiyun Qian, and Nael Abu-Ghazaleh. 2019. Collaborative Client-Side DNS Cache Poisoning Attack. In IEEE INFOCOM 2019-IEEE Conference on Computer Communications. IEEE, 1153–1161.

6 D. Atkins and R. Austein. 2004. RFC 3833: Threat Analysis of the Domain Name System (DNS). Technical Report. https://tools.ietf.org/html/rfc3833

7 F. Baker. 1995. Requirements for IP Version 4 Routers. Technical Report. https://tools.ietf.org/html/rfc1812

8 Adib Behjat. 2011. DNS Forwarders. https://www.isc.org/blogs/dns-forwarders/.

9 Markus Brandt, Tianxiang Dai, Amit Klein, Haya Shulman, and Michael Waidner. 2018. Domain validation++ for MitM-resilient PKI. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2060–2076.

10 R. Bush and R. Austein. 2017. RFC 8210: The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1. Technical Report. https://tools.ietf.org/html/rfc8210

[11] Yue Cao, Zhiyun Qian, Zhongjie Wang, Tuan Dao, Srikanth V. Krishnamurthy, and Lisa M. Marvel. 2016. Off-Path TCP Exploits: Global Rate Limit Considered Dangerous. In Proceedings of the 25th USENIX Conference on Security Symposium (Austin, TX, USA) (SEC’16). USENIX Association, USA, 209–225.

[12] Yue Cao, Zhongjie Wang, Zhiyun Qian, Chengyu Song, Srikanth V. Krishnamurthy, and Paul Yu. 2019. Principled Unearthing of TCP Side Channel Vulnerabilities. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (London, United Kingdom) (CCS ’19). Association for Computing Machinery, New York, NY, USA, 211–224. https://doi.org/10.1145/3319535.3354250

[13] Taejoong Chung, Roland van Rijswijk-Deij, Balakrishnan Chandrasekaran, David Choffnes, Dave Levin, Bruce M. Maggs, Alan Mislove, and Christo Wilson. 2017. A Longitudinal, End-to-End View of the DNSSEC Ecosystem. In 26th USENIX Security Symposium (USENIX Security 17). USENIX Association, Vancouver, BC, 1307–1322. https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/chung

[14] CloudFlare. [n.d.]. Shield Your DNS Infrastructure From DDoS Attacks With Cloudflare’s DNS Firewall. https://www.cloudflare.com/dns/dns-firewall/.

[15] European Commision. 2014. Quality of Broadband Services in the EU. http://ec.europa.eu/newsroom/dae/document.cfm?action=display&doc_id=10816.

[16] Cloudflare community. 2018. Case randomization recently disabled? https://community.cloudflare.com/t/ase-randomization-recently-disabled/61376.

[17] Cloudflare community. 2018. Incorrect resolution for my domain. https://community.cloudflare.com/t/ncorrect-resolution-for-my-domain/17966.

[18] Internet Systems Consortium. 2020. BIND 9. https://www.isc.org/bind/.

[19] David Dagon, Manos Antonakakis, Paul Vixie, Tatuya Jinmei, and Wenke Lee. 2008. Increased DNS Forgery Resistance through 0x20-Bit Encoding: Security via Leet Queries. In Proceedings of the 15th ACM Conference on Computer and Communications Security (CCS ’08).

[20] Casey Deccio, Derek Argueta, and Jonathan Demke. 2019. A Quantitative Study of the Deployment of DNS Rate Limiting. In 2019 International Conference on Computing, Networking and Communications (ICNC). IEEE, 442–447.

[21] Google Public DNS. 2019. Introduction: DNS security threats and mitigations. https://developers.google.com/speed/public-dns/docs/security.

[22] Eric Dumazet. 2014. icmp: add a global rate limitation. https://github.com/torvalds/linux/commit/cdf507d54525842dfd9f6313fdafba039084046.

[23] Zakir Durumeric, David Adrian, Ariana Mirian, Michael Bailey, and J. Alex Halderman. 2015. A Search Engine Backed by Internet-Wide Scanning. In 22nd ACM Conference on Computer and Communications Security.

[24] L. Eggert, G. Fairhurst, and G. Shepherd. 2017. RFC 8085: UDP Usage Guidelines. Technical Report. https://tools.ietf.org/html/rfc8085

[25] R Elz and R Bush. 1997. RFC 2181: Clarifications to the DNS specification. https://tools.ietf.org/html/rfc2181.

[26] Roya Ensafi, Jong Chun Park, Deepak Kapur, and Jedidiah R. Crandall. 2010. Idle Port Scanning and Non-Interference Analysis of Network Protocol Stacks Using Model Checking. In Proceedings of the 19th USENIX Conference on Security (Washington, DC) (USENIX Security’10). USENIX Association, USA, 17.

[27] FCC. 2018. Eighth Measuring Broadband America Fixed Broadband Report. https://www.fcc.gov/reports-research/reports/measuring-broadband-america/measuring-fixed-broadband-eighth-report#_Toc512944594.

[28] Suzanne Goldlust, Cathy Almond, and Mark Andrews. 2017. DNS Cookies in BIND 9. https://kb.isc.org/docs/aa-01387.

[29] Amir Herzberg and Haya Shulman. 2011. Unilateral antidotes to DNS poisoning. In International Conference on Security and Privacy in Communication Systems. Springer, 319–336.

[30] Amir Herzberg and Haya Shulman. 2012. Security of Patched DNS. In ESORICS 2012, Sara Foresti, Moti Yung, and Fabio Martinelli (Eds.).

[31] Amir Herzberg and Haya Shulman. 2013. Fragmentation considered poisonous, or: One-domain-to-rule-them-all. org. In 2013 IEEE Conference on Communications and Network Security (CNS). IEEE, 224–232.

[32] Amir Herzberg and Haya Shulman. 2013. Socket Overloading for Fun and Cache-Poisoning. In Proceedings of the 29th Annual Computer Security Applications Conference (ACSAC ’13).

[33] R. Hinden and S. Deering. 2006. IP Version 6 Addressing Architecture. Technical Report. https://tools.ietf.org/html/rfc4291

[34] P. Hoffman, A. Sullivan, and K. Fujiwara. 2019. RFC 8499: DNS Terminology.Technical Report. https://tools.ietf.org/html/rfc8499

[35] A. Hubert and R. van Mook. 2009. RFC 5452: Measures for Making DNS More Resilient against Forged Answers. Technical Report. https://tools.ietf.org/html/rfc5452

[36] Geoff Huston. 2019. The state of DNSSEC validation. https://blog.apnic.net/2019/03/14/the-state-of-dnssec-validation/.

[37] Ed. J. Iyengar, Ed. andM. Thomson. 2020. QUIC: A UDP-Based Multiplexed and Secure Transport. Technical Report. https://tools.ietf.org/html/draft-ietf-quic-transport-27

[38] A. J. Kalafut, C. A. Shue, and M. Gupta. 2011. Touring DNS Open Houses for Trends and Configurations. IEEE/ACM Transactions on Networking 19, 6 (2011), 1666–1675.

[39] Dan Kaminsky. 2008. Black ops 2008: It’s the end of the cache as we know it. Black Hat USA (2008).

[40] Simon Kelley. 2020. Dnsmasq - network services for small networks. http://www.thekelleys.org.uk/dnsmasq/doc.html.

[41] Amit Klein, Haya Shulman, and Michael Waidner. 2017. Internet-wide study of DNS cache injections. In IEEE INFOCOM 2017-IEEE Conference on Computer Communications. IEEE, 1–9.

[42] Jeffrey Knockel and Jedidiah R. Crandall. 2014. Counting Packets Sent Between Arbitrary Internet Hosts. In 4th USENIX Workshop on Free and Open Communications on the Internet (FOCI 14). USENIX Association, San Diego, CA. https://www.usenix.org/conference/foci14/workshop-program/presentation/knockel

[43] NLnet Labs. 2020. Unbound DNS Resolver. https://nlnetlabs.nl/projects/unbound/about/.

[44] Cricket Liu. 2015. A new kind of DDoS threat: The “Nonsense Name” attack. https://www.networkworld.com/article/2875970/a-new-kind-of-ddos-threat-the-nonsense-name-attack.html.

[45] lkm. 2007. Blind TCP/IP Hijacking is Still Alive. http://phrack.org/issues/64/13.html.

[46] Chaoyi Lu, Baojun Liu, Zhou Li, Shuang Hao, Haixin Duan, Mingming Zhang, Chunying Leng, Ying Liu, Zaifeng Zhang, and Jianping Wu. 2019. An End-to-End, Large-Scale Measurement of DNS-over-Encryption: How Far Have We Come?. In Proceedings of the Internet Measurement Conference (Amsterdam, Netherlands) (IMC ’19). Association for Computing Machinery, New York, NY, USA, 22–35. https://doi.org/10.1145/3355369.3355580

[47] Matthew Luckie, Robert Beverly, Ryan Koga, Ken Keys, Joshua A. Kroll, and k claffy. 2019. Network Hygiene, Incentives, and Regulation: Deployment of Source Address Validation in the Internet. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (London, United Kingdom) (CCS ’19). Association for Computing Machinery, New York, NY, USA, 465–480. https://doi.org/10.1145/3319535.3354232

[48] Ed. M. Bishop. 2020. Hypertext Transfer Protocol Version 3 (HTTP/3). Technical Report. https://datatracker.ietf.org/doc/draft-ietf-quic-http/

[49] Moritz Müller, Giovane C. M. Moura, Ricardo de O. Schmidt, and John Heidemann. 2017. Recursives in the Wild: Engineering Authoritative DNS Servers. In Proceedings of the 2017 Internet Measurement Conference (London, United Kingdom) (IMC ’17). Association for Computing Machinery, New York, NY, USA, 489–495. https://doi.org/10.1145/3131365.3131366

[50] Zhiyun Qian and Z Morley Mao. 2012. Off-path TCP sequence number inference attack-how firewall middleboxes reduce security. In 2012 IEEE Symposium on Security and Privacy. IEEE, 347–361.

[51] Alan Quach, Zhongjie Wang, and Zhiyun Qian. 2017. Investigation of the 2016 Linux TCP Stack Vulnerability at Scale. SIGMETRICS Perform. Eval. Rev. (2017).

[52] Vicky Ris, Suzanne Goldlust, and Alan Clegg. 2020. BIND Best Practices - Authoritative. https://kb.isc.org/docs/bind-best-practices-authoritative.

[53] Paul Schmitt, Anne Edmundson, Allison Mankin, and Nick Feamster. 2019. Oblivious DNS: Practical Privacy for DNS Queries. In PoPETS.

[54] Kyle Schomp, Tom Callahan, Michael Rabinovich, and Mark Allman. 2013. On measuring the client-side DNS infrastructure. In Proceedings of the 2013 conference on Internet measurement conference. ACM, 77–90

[55] Kyle Schomp, Tom Callahan, Michael Rabinovich, and Mark Allman. 2014. DNS Record Injectino Vulnerabilities in Home Routers. http://www.icir.org/mallman/talks/schomp-dns-security-nanog61.pdf . Nanog 61.

[56] Sergio De Simone. [n.d.]. The Status of HTTP/3. https://www.infoq.com/news/2020/01/http-3-status//.

[57] US-Cert. 2019. Alert (TA13-088A) - DNS Amplification Attacks. https://www.us-cert.gov/ncas/alerts/TA13-088A.

[58] Paul Vixie. 2019. On the Time Value of Security Features in DNS. http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/.

[59] Paul Vixie and Vernon Schryver. 2012. DNS Response Rate Limiting (DNS RRL). https://ftp.isc.org/isc/pubs/tn/isc-tn-2012-1.txt.

[60] Xiaofeng Zheng, Chaoyi Lu, Jian Peng, Qiushi Yang, Dongjie Zhou, Baojun Liu, Keyu Man, Shuang Hao, Haixin Duan, and Zhiyun Qian. 2020. Poison Over Troubled Forwarders: A Cache Poisoning Attack Targeting DNS Forwarding Devices. In 29th USENIX Security Symposium (USENIX Security 20). USENIX Association, 577–593. https://www.usenix.org/conference/usenixsecurity20/presentation/zheng

个人分析报告

论文概述

为了成功污染典型服务器上的DNS缓存，路径外的攻击者需要同时发送2^{32}个欺骗性的包，猜测正确的源端口（16位）和事务ID（16位）。

本文通过先猜测源端口，然后猜测事务ID的方式，将随机性由2^{32}降为2^{16}+2^{16}，该攻击影响到DNS基础设施中的所有缓存层，如DNS转发器和解析器缓存，以及广泛的DNS软件栈，包括最流行的BIND、Unbound和dnsmasq，运行在Linux和潜在的其他操作系统之上。

受到攻击的主要条件是：操作系统及其网络被配置为允许ICMP错误回复。

从测量结果来看，作者发现互联网上超过34%的开放式解析器存在漏洞。

主要贡献

1. 由出站ICMP错误信息的全局速率限制引入的侧信道漏洞，由此提出一般的UDP源端口去随机化策略。

2. 研究了源端口去随机化策略对各种攻击模型的适用性，为了在执行去随机化策略时有足够的时间，开发了新的方法来大幅扩展攻击窗口，其中一个方法再次利用了速率限制功能。

3. 针对各种各样的服务器软件、配置和网络条件进行了广泛的评估，并报告了积极的结果。

相关概念

侧信道

侧信道攻击利用的不是系统实现上的脆弱性，而是系统原理设计上的信息泄漏。

本文中利用的侧信道本质上就是攻击者和受害者之间共享着某些资源，资源的信息状态反映了受害者的其他相关信息。

利用网络协议中的全局速率限制作为一个侧信道的概念已经被记录在一些重要的工作中，例如TCP RST速率限制，TCP Challenge ACK速率限制在过去已经被证明和报告。

侧信道攻击的流程：

1. 侧信道泄漏的截取
2. 信息的恢复

非中间人(off-path)攻击

非中间人(off-path)攻击，即不能对两台主机之间连接的内容进行监听或篡改，攻击者具有一定的IP欺骗能力。

攻击成功需要：消息合法，且恶意消息比受害者所需要的消息先到达。

研究背景

DNS系统

DNS系统，即域名系统，自发明以来，一直是互联网的关键组成部分。DNS的本质是发明了一种层次的、基于域的命名方案，并用一个分布式数据库系统加以实现。其主要用途是将主机名映射成IP地址，RFC1034、RFC1035、RFC2181给出了其定义。

具体来说，DNS的使用方法如下所述：为了将一个名字映射成IP地址，应用程序将名字作为参数调用一个名为解析器(resolver)的库程序，如gethostbyname()函数。解析器向本地DNS服务器发送一个包含该名字的请求报文；本地DNS服务器查询该名字，并且返回一个包含该名字对应IP地址的响应报文给解析器，然后解析器再将IP地址返回给调用方。查询报文和响应报文都作为UDP数据包发送。

DNS缓存投毒/污染

一、传统的DNS缓存投毒攻击

主要针对DNS解析器，让路径外的攻击者欺骗存在漏洞的DNS解析器，使其向上游权威域名服务器发出查询。然后，攻击者试图冒充域名服务器的IP注入恶意响应。如果恶意响应在任何合法响应之前到达，并且它与查询中的“秘密”相匹配，那么解析器将接受并缓存恶意结果。由于解析器当时源端口和目的端口都固定为53，因此随机性只由16位事务ID提供，很容易被暴力破解。

二、防御措施

• 源端口随机化，使随机性变成32位，是最广泛有效的部署。
• 对域名中的字母大写进行随机化，即0x20编码，但由于兼容性问题，很少被使用。
• 域名服务器选择的随机化。实际大多数域名采用不到10个域名服务器，在随机性上只相当于2到3位。
• DNSSEC，但DNSSEC的部署率极低。

解决的问题

互联网中域名系统有着非常重要的作用，而由于全局速率限制等设计，利用侧信道的非中间人DNS缓存投毒攻击重新兴起，互联网域名系统中的转发器和解析器具有严重的安全隐患。本文对这种攻击方法进行了论证和检验，并评估了互联网域名系统中各类转发器、解析器存在漏洞的比例，最后提出了相关的缓解措施。

攻击的工作流程

1. 推断源端口

利用新的侧信道推断，速度最多为1000次猜测/s

2. 扩展攻击窗口

为了能有足够的时间进行攻击，需要令攻击的时间窗口扩大。

一旦获得了源端口号，攻击者只需要对16位的事务ID进行猜测。

实验原理分析

源端口扫描

UDP端口的可扫描性分析

从UDP原理上，当一台主机开启一个UDP套接字向外发送消息时，也会在该端口接收UDP消息。

因此，当DNS服务器发出查询时，其源端口就会对公众开放。这使得攻击者可以用任何UDP数据包简单地扫描很短的端口范围，在访问正确的端口时不会触发任何东西（因为操作系统会接受探测包，但在应用层会被丢弃），而在不是正确端口时会触发ICMP端口不可达消息。

此外，如果使用connect()这一API，主机从一个源端口向一个特定的终点IP地址和端口发出DNS查询时，操作系统将只接受来自同一远程IP和端口的传入数据包。这对防止DNS查询的源端口被直接扫描是有效的。

然而最流行的DNS转发和解析软件BIND、Unbound和dnsmasq中，只有BIND使用connect()。

ICMP速率限制

ICMP是Internet控制报文协议，而本论文中用到的是它的错误信息的速率限制，即ICMP端口不可达报文，用于告知客户端该端口未开放。

而现代操作系统都对该消息实施了速率限制机制，本文主要讨论Linux系统的表现。

对于Linux来说，对于每秒可以发送多少个ICMP错误数据包，有每个IP和全局的速率限制。默认情况下，每个IP的令牌恢复速度是每秒一个（累积的最大突发次数为6），这将严重限制扫描速度；全局令牌恢复速度是每秒1000个（但累积的最大突发次数为50），但实际的令牌恢复只发生在距离上次恢复至少20ms之后，因此全局速率限制是50个。

面向公共的源端口扫描方法

一个UDP端口未使用connect()开启时，就不会对接收的报文的IP地址进行检查，因此，这种端口是开放的，面向公共的。

本文提出了三种方法进行扫描：

1. 攻击者拥有多个IP地址，或是一台拥有IPv6地址的机器（IPv6地址包含64位可分配的接口ID），那么很容易绕过每个IP的限制。
2. 如果一个攻击者只拥有一个IPv4地址，仍然有可能使用DHCP请求获得多个地址。
3. 使用IP欺骗发送探测包，然后使用真实的地址发送验证包。

私有的源端口扫描方法

一个UDP端口使用connect()开启时，端口就成为了远程对端的“私有”端口，因此，需要使用IP欺骗，伪造上游DNS服务器的数据包，因此这时需要处理每个IP的速率限制。

令人惊讶的是，ICMP速率限制的全局速率限制是在每个IP速率限制之前被检查的，因此，即使因为IP速率限制导致不发送ICMP回复，全局速率限制的资源依然会被消耗。

因此，只需要使用伪造的IP就可以很容易地对私有的源端口进行扫描。

具体操作

针对面向公共的源端口：

(1)攻击者首先发送50个欺骗性的UDP探测数据包，每个数据包有不同的源IP（绕过每个IP的速率限制）。如果受害者服务器在这50个端口中没有开放任何源端口，那么就会触发50个ICMP端口不可达信息（但攻击者无法直接观察到这些信息）。如果受害者服务器有n个开放的端口，那么只有50-n个ICMP报文会被触发（因为n个UDP探测报文会在应用层被悄悄丢弃）。

(2)攻击者使用其真实的IP地址发送一个验证包，例如，一个UDP包，目的地是已知的封闭端口，如1端口。它要么没有得到响应（如果全局速率限制被耗尽），要么得到一个ICMP回复。

如果在第一阶段中没有发现端口，攻击者会等待至少50ms，让速率限制计数器恢复，然后开始下一轮。扫描速度将被限制在每秒1000个。因此，需要60多秒来列举由65536个端口组成的整个端口范围。

针对私有的源端口：

只需要用上游服务器的IP对探测包进行伪装，其他流程与上面的操作基本相同。

一些细节

1. 时间考虑

• 需要在开始恢复令牌前完成一轮操作，时间窗口为20ms。

2. 二分搜索以确定端口

• 当发现开放端口时，首先需要对探测的全部50个端口进行一次验证。
• 搜索时需要向已知的关闭的端口发送填充包。

3. 处理干扰

• 如时延、抖动等问题，以及其余非目标的业务所开放的端口，这些问题会在二分搜索中很容易被排除，而后面扩展攻击窗口的方法也可以让目标源端口开放时间由毫秒级上升到秒级。

扩展攻击窗口

攻击窗口越长，攻击者就可以扫描更多的端口，也有更多的时间来注入恶意记录。

因此，我们的目标是使上游服务器“静默”，防止它们对攻击者引发的DNS查询作出反应。

在转发器攻击中扩展窗口

攻击者可以首先向转发器发送他自己域名的查询，例如www.attacker.com，这将最终触发上游解析器查询攻击者控制的权威域名服务器，而该服务器会有极大的延迟，甚至可以用连续的CNAME重定向制造一种“正在取得进展”的假象，以使上游解析器迟于回应转发器的响应，留出充足的攻击时间窗口（因为转发器的超时时间往往非常宽松，因此主要限制在于上游解析器的响应时间）。

而转发器从设计上不会对解析器返回的结果进行完整性检验，因此，攻击者在找到源端口和事务ID后，将如图所示的恶意响应返回，受害者的域名记录也会被转发器缓存。

在解析器攻击中扩展窗口

可以利用权威域名服务器的速率限制的安全功能作为在解析器攻击中静默域名服务器和扩展窗口的一种方式。

响应速率限制(RRL)，是对DNS放大攻击的一种缓解措施。然而，如果攻击者能够以高于配置限制的速度注入欺骗性的DNS查询（使用目标解析器的IP），那么这一功能可以被恶意利用，使域名服务器静默。

测量方法：每秒发送1K次查询，持续15秒，然后向每个域名服务器IP发送另一轮4kpps的测试，持续15秒，查询都是均匀分布的（而不是突发发送），都试图询问www子域的A记录。

在10万的案例中，作者认为共有18110（13110+5000）（18%）个案例是脆弱的，13110是4kpps流量下丢包率超过66.7%的案例数量，而5000是在两次实验间差异超过2%的案例，这样的案例很可能会随着流量升高而被诱导足够高的丢包率。

此外，在获得许可的情况下，作者针对一个未配置速率限制的生产环境服务器进行了更高速率的探测，出乎意料的是，当探测速率增加到25kpps时，它开始出现丢包。具体来说，当速率增加到50kpps时，丢包率跳升到75%。作者发现这是因为应用程序（即BIND）从套接字队列中读取的速度不够快，从而导致溢出。

这一技术同样可以应用到扩展转发器攻击的窗口上。因为解析器也普遍配置了RRL策略，使用4kpps的探测速率，作者观察到136547个解析器中有121195个显示出超过66.7%的丢包率，表明在互联网上将解析器静默是普遍可行的。

实际的攻击考虑

1. 绕过缓存记录的TTL

• 对一个随机前缀的域名发送查询，使解析器向victim.com的权威域名服务器发起新的查询，然后注入如图所示的恶意响应，声称www.victim.com是一个独立的域，有自己的权威域名服务器ns.attacker.com，即可将该记录缓存到解析器中。 如此，缓存过期后，对www.victim.com的查询均会向ns.attacker.com发送。

2. 超时重传的时间窗口

• 一般来说，转发器与解析器表现类似，且转发器的超时时间往往很长，因此主要讨论解析器。
• 如BIND或Unbound，在没有得到上游服务器响应的情况下会根据一定条件将重传时间翻倍，而在达到硬停止条件前，该操作会持续扩展攻击窗口。

1. 处理多个域名服务器

• 平均来说，一个域名对应的域名服务器仅约为2个，因此很容易使这些服务器全部静默。
• 此外，由于Unbound的独特策略，我们需要周期性地暂停静默过程，以避免全部域名服务器被封锁。

4. DNS解析器后面的多个后端服务器

• 虽然有些解析器对应的后端服务器可能达到上百个，但实际应用中其选择具有很强的偏向性，因此只需要关注其中几个IP。

实验安排

作者进行了对转发器(模拟家庭路由器网络)和解析器(针对获得许可的生产环境DNS解析器)的实验。

对转发器的实验是简单的，目标模拟家庭路由器，没有部署全局ICMP速率限制，其转发软件也没有在UDP套接字上调用connect()。第一阶段采用DHCP获取多个IP，第二阶段向转发器发出查询，要求提供一个任意的子域，例如nonce.attacker.com。然后使用获得的IP地址扫描端口，当发现一个开放的端口后，通过重复探测同一端口，确认它至少保持一秒钟的开放，然后注入恶意响应。在20次实验中，成功率为100%（如果攻击在30分钟内完成，我们认为是成功的），平均成功时间为271s。

而对解析器的实验对比安排较为复杂。目标为生产环境中获得授权的域名解析器，测试域名托管在作者控制的权威服务器下，并将软件的响应速度限制设为10pps，以减少对网络的影响。当达到速率限制时，服务器将在每五个响应中允许一个，以模拟80%的丢包率，这构成了基线实验的配置。此外，为了了解响应速率限制对权威域名服务器的影响，作者通过配置75%、66.7%和50%的丢包率来改变静默水平——丢包率越低，攻击就越困难。作为比较，作者还通过在同一台攻击机上施加额外的延迟、抖动和丢失，模拟了更现实的网络条件。

这个过程同样从攻击者生成询问nonce.attacker.com的查询开始。由于解析器有两个后端服务器IP，作者同时对两个IP进行端口扫描。同时作者以20pps的速度使所有权威域名服务器的查询静默，这样解析器将保持80%的恒定丢包率。该实验对基线和模拟现实网络条件的实验分别重复20次和5次。

实验结果显示大部分实验都取得了近乎完美的成功率，在白天(Base(D))和夜晚(Base(M))的平均用时体现了干扰对攻击的影响；丢包率的下降会很大程度增加攻击用时，因为这让受害者更容易收到上游服务器的回复而结束查询状态，但一定时间内的攻击成功率证明攻击依然是非常有效的。而模拟现实网络条件的5次实验也都取得了成功，只是丢包率和抖动的增加导致了更多的假阳性结果，这通常是探测包的丢失引起的。

防御措施

本文所提出的攻击从根本上说是一种非中间人攻击，因此可以通过额外的随机性和加密措施来缓解。而由于攻击由两个阶段组成：推断DNS查询的源端口及扩展攻击窗口，防御措施也是针对这两个阶段的。

对于第一阶段：

1. 不允许ICMP回复。最简单有效，但会使服务器失去一些功能。
2. 解决全局速率限制。采用随机化的速率限制，防止攻击者通过侧信道获得信息。
3. 在侧信道问题被缓解后，建议使用connect()，以避免端口被直接大范围扫描。

对于第二阶段：

1. 更好地配置响应速度限制。让权威域名服务器在被攻击时不是保持静默而是有一定回应。
2. 设置更短的DNS查询超时时间。
3. 使用任播，让攻击者更难使服务器静默。

工作的优点

作者提出了利用全局速率限制的侧信道进行的DNS缓存投毒攻击这种新的非中间人攻击方法，并进行了详细的分析和实验，整篇论文叙述非常清晰，条理性逻辑性很强，实验验证过程也在学术道德的基础上安排的非常充分，有效验证了论文提出的攻击方法是广泛可用的，互联网中有大量存在漏洞的主机，最后也提出了详细的防御这类攻击的措施，无论是对网络安全领域的学术发展还是对域名系统实际安全应用都有很大的好处。

参考文献

1Man, K. Y., Qian, Z. Y., Wang, Z. J., Zheng, X. F., Huang, Y. J., & Duan, H. X. (2020). DNS Cache Poisoning Attack Reloaded: Revolutions with Side Channels. Ccs '20: Proceedings of the 2020 Acm Sigsac Conference on Computer and Communications Security, 1337-1350. https://doi.org/10.1145/3372297.3417280

2 Dan Kaminsky. 2008. Black ops 2008: It’s the end of the cache as we know it. Black Hat USA (2008).

3 Amit Klein, Haya Shulman, and Michael Waidner. 2017. Internet-wide study of DNS cache injections. In IEEE INFOCOM 2017-IEEE Conference on Computer Communications. IEEE, 1–9.

off-path

anycast

DNS放大攻击

专有名词翻译对照

Poisoning -> 投毒，污染

Side Channels ->旁路，侧信道

transaction -> 事务

forwarder -> 转发器

resolver -> 解析器

derandomization -> 去随机化

anycast -> 任播或选播，指同一个IP地址分流到不同的服务器。参考：anycast

off-path attacker/adversary -> 非中间人的攻击者/对手，即不直接对客户端与服务器间的连接进行攻击。

---

参考：off-path 非中间人攻击/偏离路径攻击/off-path attack 通信线路之外，攻击者看不到双方的消息，没办法截获和发送通信包。智能伪造成一方给另一方发消息。

攻击成功需要：消息合法+最先到达 防御措施：challenge-response/询问-应答机制 双方在通信前交换一个随机数，这个随机数在每次的通信中都要被附带，而中间人看不见这个随机数，因此伪造的消息被认为不合法。 攻击者如何得到这个随机数：侧信道

---

Global Rate Limit

USENIX 2016 : Off-Path TCP Exploits: Global Rate Limit Considered Dangerous

侧信道： 所有的侧信道，本质上就是攻击者和受害者之间共享着某些资源，如之前的全局TCP计数器。这里使用的侧信道是服务器上的共享资源，限速器（RFC 5961）限制某一种包的发送速率（默认100p/s）

如何利用共享限速器：

先判断是否建立了连接。然后伪造TCP包，需要猜测源端口，如果猜测正确，服务器会返回一个challenge，攻击者不断触发，一共可以收到99个（还有一个发给了客户端）；如果猜测错误，则一共可以收到100个challenge。