Mike Zhang

DNS DevOps CISSP CISA Security+ 摄影 程序员 北京

RFC 5452 增强DNS抵御伪造响应的措施

26 Nov 2018 » dns, rfc

概述

当前的互联网环境新增了很多针对DNS的安全威胁。 在充分保护DNS协议之前的这段过渡时期,可以采取一些措施来加固DNS,从而使得像是”欺骗”DNS递归服务器这种威胁的实施难度增加。

对于实施安全加密的DNS系统可以通过快速的丢弃伪造的响应信息,从而节省大量的计算资源。

本篇文档通过描述一些之前没有标准化但确实存在的行为,阐述了DNS系统如何能够在接收到不正确的响应时候变得更加安全可靠, 本篇系统也是对于RFC2181的一个更新补充。

1. 介绍

本篇文档描述了一些DNS实施中常见的问题, 尽管这些问题之前已经被发现,但是大部分仍旧没有得到解决。除了简要地回顾这些问题之外,本文档还包含一些安全规则,如果实施了这些规则,则会使得解析器对所描述的攻击类型具有更强的抵抗力,本篇文档的目标是使得现有的协议实施的DNS系统能够变得尽可能的安全可靠。

下面的一些内容主要针对解析器的开发人员,而对于运行DNS的人员可以自行决定在哪些域名服务器上去实施或者启用配置措施。同时操作上的约束可能会超出下面描述的安全问题,但软件实施上应该允许操作人员可以启动一些本文档中所描述的功能。

几乎每一个互联网上的安全交易都会涉及这个通过RFC1034,RFC1035以及其他的多个文档所描述的DNS系统。

此外,通过DNS用来传递路由信息,也使得不需要身份验证就可以获取到SSL/TLS证书的可能性超过了响应一个通过SMTP协议发送的验证邮件的概率。 换句话说,任何控制了DNS协议的攻击方都可以重新路由任何的互联网流量,包括SSL、TLS对于一个域名的验证。 因此尽管安全交易可以通过SSL、TLS保护,但是利用DNS的安全漏洞这些都可以被跳过。

这些重新路由的安全问题可以肯定的是对于互联网用户来说是非常不利的。 这些问题的出现使得DNS安全和可信的重要性重新被认识到,尽管DNS社区一直在不断的独立去实施一个加密增强的DNS协议,但是也需要确保当前的DNS系统在相关标准情况下仍旧能够尽可能的保持安全可靠。

应当注意的是,由于当前仍旧存在大量的解析器无法针对涉及到的安全问题,采用更加合适的处理手段,因此显得本篇文档迫切重要。

RFC3833中包含了针对DNS系统的全面的安全风险分析内容,可供参考。

本篇文档扩展了一些RFC3833所提及到的安全问题,特别是那些在文章内容中提及到的ID猜测和查询预测以及命名链。同时,它也强调了已经存在大量的安全规则和实施建议应用到最近的DNS协议规范中, 下文还制定了一些新的要求,确保在安全协议标准化和部署之前可以更加安全的使用DNS系统

应该注意的是,即便是应用了文档中所有的策略措施,协议用户也仍旧会遭受那些有能力去观察,修改或者注入包到解析器的第三方的攻击。对于提供针对这些场景进行安全保护的协议扩展,可以参考RFC4033以及其他的相关文档。

2. 要求和定义

2.1 定义

Client客户端: 一般指的是用户的计算机或者一个终端解析器

Resolver解析器: 域名服务器提供给客户端递归查询服务,同时也被称为缓存服务器,或一个完整的服务解析器

Stub Resolver终端解析器:客户端电脑上安装的非常有限的解析器,一般只是将递归请求传递至一个完整的解析器。

Query查询:从解析器(Stub Resolver或者Resolver)发送的查询请求,一般是一个UDP数据包

Response响应:域名服务器发送的响应消息,一般是一个UDP数据包

Third party第三方:任何除了解析器或者接受DNS响应信息的实体。他们可能具有访问权威域名服务器的能力,但是没有权限去访问解析器和权威服务器之间的数据包传输。

Attacker攻击者:恶意的第三方

Spoof欺骗:尝试通过伪造数据包来破坏DNS查询流程的行为。

Authentic Response 权威响应:正确的来自权威服务器的响应

Target Domain Name目标域名:攻击者希望去伪造的域名

Fake Data 虚假数据:攻击者构造的响应数据

2.2 关键词

参考RFC2119获得关于描述中的一些关键词的定义,比如:Must必须,Must Not 不可以,Required 要求等等。

3. DNS欺骗

通过一些手段去精心设计和构造的DNS数据包,可以欺骗当前部署的大部分的递归服务器。一旦递归服务器遭到“欺骗”攻击,缓存服务器在应答客户端响应的时候重复使用这些数据,导致客户端去联系错误的或者恶意的服务器。

理解怎样让解析器接收这个响应的流程是至关重要的,下面的部分来自于RFC1034的5.3.3章节,预感到了当前的问题。

解析器在解析响应的时候十分小心,应当通过使用响应中的ID域来检查这个响应是否匹配查询的内容

DNS数据仅仅在以下条件下才能被接受:

  1. 响应包中的查询字段应当等于当前处于等待的查询包中的查询内容。
  2. 查询和响应的包中ID域应该匹配
  3. 响应的服务器地址应该和查询包发送的地址相同
  4. 响应和查询的网络地址信息应该一致,包括查询的端口号匹配。

所有四个条件都匹配的第一个响应消息会被服务器接受。如果一个第三方成功的满足了四个条件,那么就有可能将构造的数据传递到解析服务器中,我们可以认定这是一个攻击者,尝试利用虚假的数据实施DNS欺骗攻击。第三方理论上可以满足所有的条件,但是困难程度依赖于解析器的实施和区配置等方面。

4. 欺骗攻击的细节描述

上述章节介绍了一些攻击者实施欺骗攻击需要满足的条件,本章节则讨论下相对的困难度,以及怎样实施来增加攻击者为了实现攻击所需要付出的工作量。

一些细节信息可以查看RFC3833的第2.2章节

4.1 强制查询

一般来讲,域名服务器应该仅仅提供给操作人员,客户或者更通用点的用户访问使用,但是最近,大量的递归服务器被用来实施一个放大DNS拒绝服务攻击。

提供完全开放的服务,使得第三方可以发送一些倾向于进行欺骗的域名查询信息给目标解析器。 当解析器接收到这个查询的时候,如果没有查询到任何相关的缓存信息,解析器将发送查询信息到权威域名服务器进行查询,这就给了攻击者可能将伪造信息发送给解析器的窗口时间。

查询可能是非直接的查询,比如通过邮件服务器去实施DNS查询。

一些运行人员通过限制只有授权的IP地址可以进行递归查询,而非授权的则只能响应缓存信息。这对于攻击来说,的确会增加它实施的困难度,但并非完全不可能,考虑到递归服务器会发布资源在缓存中的生存时间,这个时间也描述了为了刷新过期的资源记录,而重新发送的新的查询的时间范围。

设置短的TTL会使得攻击更加的容易实施,因为较短的TTL增加了攻击可以尝试的次数和频率。

同时需要注意的是,攻击者可能会具有访问目标解析服务器的权限,比如作为雇员或者客户的角色。或者是利用RFC5358中所使用的反射器来完成访问。

4.2 匹配查询字段

DNS数据包中,不管是查询还是响应都具有一个查询字段,接收到的响应消息应当验证是否和发送的查询中相匹配的查询字段信息。

4.3 匹配ID域

DNS ID是一个16位的数值,如果设置随机值的话,攻击者尝试猜测的次数大约平均32768次,一些迹象表秒充分利用的仅仅使用了14位的大小,意味着约8192次尝试即可满足。

此外,如果目标域名服务器可以被强制设置同时向外发送多个相同查询,则生日攻击意味着任何攻击者发送的伪造数据可以同时匹配多个查询的内容,显著的增加了攻击成功的概率,详见第五部分。

4.4 匹配权威应答的源地址

需要注意的是,符合条件需要同时满足传输的数据包需要来自于权威的域名服务器。尽管当前两个最佳实施文档RFC2827和RFC3013已经指示ISP需要阻止那些数据包中源地址不是已分配的地址的情况,但是这些建议并未大范围的被采用。

许多区只有两个或者三个权威域名服务器,这使得匹配权威响应的源地址即便是随机选择也具有较高的成功率。

大部分递归服务器存储不同的权威域名服务器的性能情况,这使得很容易预测哪一个域名服务器将会在下一次被查询使用(一般是那些响应最快的服务器)

一般来说,这些条件要求最多需要2-3次尝试去完成匹配。

4.5 匹配目的地址和端口号

权威响应的目的地址和查询的源地址是一致的,实际的递归服务器地址是已知的,查询DNS使用的端口则是很难获得的。当前大部分的解析器在启动的时候获得一个随机的端口,并在接下来的查询中使用,在很多情况下,出现问题的源端口都被固定在了端口53上。

如果这原始查询的源端口尽管是随机选择的,但是一直保持不变,则攻击者通过观察权威域名服务器的响应则可以获得需要的端口信息,这意味着匹配端口信息就不需要任何猜测了。

如果多个端口被用来发送响应,这就会使得有效的ID空间需要在原来的基础上乘以端口的数量来获得整个猜测空间。

很少有解析服务器为每一个查询都选择随机的端口,如果执行这种策略,端口号也可以作为另外一个ID, 毕竟端口号也是一个16位的信息。

如果使用整个的端口空间域,则需要进行平均32256个端口尝试(1024以内的不去使用,剩余64512)。一般来说,对于DNS,可以安全的使用范围为1024-49152范围内的端口,即便是这些端口也被用于其他的协议。DNS解析器不可能去使用任何已经被占用的端口。如果一个DNS解析器需要获得一个端口,它将在一段时间之后释放该端口并转移到另外一个端口上, 仅仅对于那些查询比较大的解析器,可能会出现端口被长时间占用无法使用的情况。

需要注意的是,防火墙不会阻止地址的匹配,它将会接收来自于正确的地址,防火墙本身也不会提供额外的安全措施。

4.6 使响应消息在权威应答之前到达

一旦任何的数据包已经匹配之前的四个条件,不会再去接收任何新的数据包。这就意味着,第三方只有有限的时间可以注入伪造的信息。一般我们假设这个窗口时间最多100ms(依赖于到达权威服务器的网络距离)

这个时间周期可能对于那些正在接收大量查询的权威服务器(来自于攻击者的大量查询)来说会变得更长。

5. 生日攻击

生日悖论指的是一个包含23个人的小组足以有两个或更多的成员具有相同的生日。同样如果一个攻击者可以使得解析器能够在同一时间外发多个相同的查询到权威服务器,则可以获得类似于生日悖论相同的概率优势。

由于只需要匹配多个之中的一个即可,因此任何攻击者发送的包都会具有一个相对于传统的暴力攻击更高的几率被目标服务器接收。对比上面的生日问题,一组查询和响应中任何具有一个相同ID的概率都会迅速的升高。

发送少量的查询情况下,欺骗攻击成功的概率和递归服务器向外发送特定域名到特定域名服务器的请求数量呈现线性增长,对于大量的查询,则这样的影响趋势就不会太明显了

更多细节,可以参考US-CERT vu-457875Cert-Org的介绍。

攻击者需要猜测同时发送查询达到50%成功概率的需要的数据包数量
16位ID随机132.7k
16位ID随机410.4k
16位ID随机200427
16位ID随机n/a426
16位ID和端口随机121亿
16位ID和端口随机46.83亿
16位ID和端口随机2001500万
16位ID和端口随机n/a10万

6. 仅接收域内的记录

来自于权威域名服务器的响应经常包含一些不属于这些区的信息,比如一个MX记录的查询可能包含一个属于另外一个区的域名的邮件交换服务器地址,以及额外的邮件交换服务器的IP地址

如果不加判断的直接接受的话,解析器就将有机会接收到来自未信任的数据源的数据。应该仅仅接收那些针对查询的QName或者QName的父域来说是权威的数据

一个最简单的方式就是只接受那些和查询的域名相关联的数据信息。

7. 困难度

给定一个已知的或者静态端口,匹配ID区域,源和目的地址。 如果当前区具有两个权威的域名服务器,则需要平均 2* 2^15 = 65000 个数据包。

如果窗口空间大约100ms, 则攻击者需要每秒传输65万个数据包的情况下才能实现50%的概率使得第一次尝试就能获得成功。

一个最小的DNS响应包含大约80字节, 则为了实现上面的传输,需要大约每秒416Mb的带宽。

对于一个可以同时控制多个服务器的攻击者,这些流量要求在当前也不算是太高。

如果能够同时给权威服务器增加一些负载,将整个的响应窗口时间增大到1秒,则带宽的需求就被降低到40Mb/s

同时如果攻击者可以尝试不止一次,且允许60分钟内成功即可,则对于一个TTL为300秒的记录,最小的带宽可以降低到4Mb/s来获得一个50%的成功率。

7.1 计算中需要的符号

  • I: 可用的ID的数量(最大为65535)
  • P: 端口使用的数量(最大64000,由于1024以下的端口是不可用的)
  • N: 权威域名服务器的数量(平均2.5个)
  • F: 发送的伪造的数据包数量
  • R: 攻击者每秒发送的数据包数量
  • W: 攻击窗口的大小,单位是秒(一般权威服务器的响应时间为0.1s)
  • D: 平均解析器发送的查询的数量,一般为1
  • A:一次攻击窗口内尝试的次数

7.2 计算

欺骗一个递归服务器的概率等价于在一个攻击窗口时间内,发送的伪造数据包的个数除以可能的数据包的个数。当一个递归服务器同时外发多个请求时候,每一个伪造的数据包都会具有更高的匹配概率。如下欺骗的可能性用P_s标示:

              D * F
   P_s =    ---------
            N * P * I

如果攻击者可以每秒钟发送R个数据包, 则发送的伪造的数据包的数量可以用下面的标示:

                          D * R * W
   F = R * W  ->   P_s  = ---------
                          N * P * I

为了计算在时间范围T内的总体的概率P_cs, 同时依赖于记录的TTL,在该段时间内攻击者可有多次攻击窗口时间,尝试的次数A=T/TTL。为了实施至少一次的成功,下面的公式:


                                                        (T / TTL)
                         A          (       D * R * W )
   P_cs = 1 - ( 1 - P_s )    =  1 - ( 1  -  --------- )
                                    (       N * P * I )

带入常用的配置信息

                              (T / TTL)
              (         R    )
   P_cs = 1 - ( 1 -  ------- )
              (      1638400 )

从这个公式可以看到,如果名称服务器实现没有发生变化的话,只要提高TTL就可以显著的降低成功的概率,而提升权威服务器的数量,仅仅数量很少的话概率变化不大。

对于0秒的TTL, 窗口时间则是对于每一个查询都是可用的,使得有效的缓存时间等于窗口时间。最后一种情况也使得欺骗技术不需要依赖于TTL过期,而是使用重复和不断修改的查询。

8. 讨论

上面的计算描述了DNS数据被伪造是相对容易实现的,比如使用上面的公式,对于一个TTL为3600秒的记录,攻击者每秒发送7000个查询包(大约4.5Mb/s)就可以在24小时内获得10%的成功概率,一周成功率就会达到50%

对于一个RRSet, 一个TTL是60s, 则可以使得24分钟获得10%的成功率, 三小时内获得50%的成功率,以及9小时候达到90%的成功率

对于攻击者来说,最有效的TTL时间是0

因此对于任何服务运行人员,如果一个攻击流量超过4.5Mb/s则要小心是否是此类攻击。当然这些计算都是基于静态的地址和端口,如果考虑到端口的随机化,则可能的空间需要乘以64000, 导致攻击者需要至少285Gb/s的攻击来实施相同的成功率。

尽管这类攻击不太常见,但是不确定未来是否更加容易实现。

同时需要注意的是,对于当前仅仅允许单一的DNS源端口的外发查询请求需要对于防火墙规则重新进行配置

8.1 针对一个域名的重复欺骗攻击

如果一个TTL设置为0,重复发送针对某一个域名的欺骗攻击,使用上面的速率(7000pbs)仅仅需要7秒中就可以达到50%的概率。

如果使用64000个随机端口,则在116小时候达到50%概率。

9 实施对策

9.1 查询匹配规则

解析器实施匹配响应消息需要完成下面的所有步骤:

  • 源地址和查询目的地址匹配
  • 目的地址和查询源地址匹配
  • 目的端口和查询源端口
  • 查询ID
  • 查询名称
  • 查询类别和类型

如果上述的匹配失效,则认为响应的消息是无效的。

9.2 使用端口和地址来扩展Q-ID空间

解析器实施必须满足:

  • 使用一个无法预测的源端口(范围53,1024-65535)
  • 使用如果外发多个请求则设置多个不同的源端口
  • 使用一个无法预测的ID值(范围0-65535)

解析器具有多个IP地址应当以一种无法预测的方式使用这些IP地址外发查询,解析器同时应当均匀的使用所有可用端口。

解析器应当优先已经建立安全信任关系的权威服务器进行查询,并且终端解析器应当使用TSIG或者IPSec来进行递归查询。

如果在响应验证中可以基于加密算法验证的话,解析器可以不去实施上面的规则,而依赖于这个加密算法实施的安全保证。

RFC4086提供了一种高质量的随机算法可以使用。

9.2.1

由于攻击者可以强制一个DNS解析器去发送查询到攻击者自己的域名服务器,因此可以测量很多针对解析器的一些状态信息,解析器实现必须确保对于其内部状态的任何反向工程都是很困难的,因为这种反向工程的方式可能提供一些低成本高精度的状态预测。

DNS递归服务器使用固定的IP源地址和端口号查询,对于攻击者来说比较容易预测,应该尽量避免这种配置。

使用逐步增加的ID来说也是一种非常容易预测的,也是很容易遭受欺骗攻击的模式。

最后,对于任何弱的随机生成器,都是很容易实现破解从而获得下一个预测的值,一个随机数字生成器,应该不管观察多少个数值都是无法预测下一个值的情况。

9.3 欺骗侦测和对策

如果一个解析器侦测到尝试欺骗的攻击的发生,可能是发现了很多包的查询都无法满足匹配规则,它可以放弃使用UDP查询而转而使用TCP查询,由于TCP序列号的特性,使得更加容易抵御这样的攻击发生,

10 安全考虑因素

本篇文档提供了一些DNS规范来降低DNS响应被伪造的可能性。上面的建议措施应当考虑结合可用的DNS加密算法实施(这些加密措施可以预防更多攻击的场景)

本篇文档推荐使用UDP源端口随机化来扩展DNS事务ID16位的可用范围。

一个解析器不能实现上面推荐的措施的话,很可能会遭受到DNS欺骗攻击,导致用户使用DNS服务器的时候被转移到恶意设置的网站。

本篇文档直接涉及DNS的安全问题,推荐尽快实施相关推荐措施。

大部分的安全考虑可以参考第四和第五部分,相关的对策可以参考第九部分。

文档并没有给出具体操作人员需要使用算法,但是却给出了一些需要或者必须满足的特定算法。

同时需要注意的是,NAT设备可能会极大的削弱端口随机化的效果。主要是NAT会极大的限制UDP端口可用的空间。一台高负载的DNS递归服务器设定在NAT服务器后面,或者一个状态防火墙后面,进行端口映射可能会消耗掉所有的映射资源,端口随机将导致比固定查询端口在使用转换条目上面消耗的更快。

为了减少端口或者状态耗尽攻击,推荐服务器为每一个连接设定一定的限速处理措施,这尤其适用于邮件服务器。

11. 致谢

端口随机化最早使用或者发明的人是Dan J. Bernstein。同时感谢以下人员给予的帮助和贡献:

      Stephane Bortzmeyer
      Alfred Hoenes
      Peter Koch
      Sean Leach
      Norbert Sendetzky
      Paul Vixie
      Florian Weimer
      Wouter Wijngaards
      Dan Wing