提供DNSSEC会暴露哪些类型的安全漏洞?


28

我打算用DNSSEC签名我的DNS区域。我的区域,注册商和我的DNS服务器(BIND9)都支持DNSSEC。唯一不支持DNSSEC的人是我的辅助名称服务器提供商(即buddyns.com)。

他们在其网站上声明有关DNSSEC的信息:

BuddyNS不支持DNSSEC,因为它暴露了一些不适用于高容量DNS服务的漏洞。

好吧,我认为DNSSEC的使用目前存在某种问题,因为大多数解析器不会检查记录是否正确签名。我不知道的是-根据他们的说法-似乎提供它会暴露某种安全漏洞。

那些“脆弱生物”是什么?


8
找到一个更聪明的DNS提供商-他们的借口是虚假的。
Alnitak

Answers:


103

DNSSEC具有一些风险,但它们与反射或放大没有直接关系。在这种情况下,EDNS0邮件大小扩展为红色鲱鱼。让我解释。

不依赖于以前的身份证明的任何数据包交换都会受到DDoS攻击者的滥用,攻击者可以将未经身份验证的数据包交换用作反射器,也可能用作放大器。例如,可以以这种方式滥用ICMP(“ ping”后面的协议)。就像TCP SYN数据包一样,TCP SYN数据包也可请求多达40个SYN-ACK数据包,即使SYN被欺骗是来自某些不希望这些SYN-ACK数据包的受害者。当然,所有UDP服务都容易受到此攻击,包括NTP,SSDP,uPNP,并且如此处其他响应所指出的,也包括DNS。

大多数入侵检测,入侵防御和负载平衡器设备都是瓶颈,无法跟上“线路速率”流量。同样,许多路由器不能以线速运行,有些交换机也不能。这些瓶颈(在路径中)是最小的,并且比链接本身小,它们是基于拥塞的DDoS攻击的实际目标。如果您可以让某人的防火墙忙于攻击流量,那么即使链接未满,也不会通过良好的流量。减慢防火墙速度的不是每秒的位数(可以通过使用更大的消息来增加,而EDNS0和DNSSEC可以增加),而是每秒的数据包总数。

由于DNSSEC的邮件大小较大,关于DNSSEC如何使DDoS变得更糟,这方面有许多都市传说,尽管这具有直觉性和“听起来不错”,但这完全是错误的。但是,如果这个传说有真相,那么真正的答案仍然会摆在其他地方-[因为DNSSEC始终使用EDNS0,但是EDNS0可以不使用DNSSEC使用],并且许多常规的非DNSSEC响应都和DNSSEC一样大。回应会。考虑用于表示SPF策略或DKIM密钥的TXT记录。或者只是任何大型地址或MX记录集。简而言之,无需攻击就可以使用DNSSEC,因此,将DNSSEC作为DDoS风险的任何关注都是浪费精力。

DNSSEC确实有风险!它很难使用,而且很难正确使用。通常,它需要新的工作流程来进行区域数据更改,注册商管理以及新服务器实例的安装。所有这些都必须经过测试和记录,并且每当与DNS相关的问题出现故障时,都必须对DNSSEC技术进行调查,作为可能的原因。如果您做对了所有事情,最终结果将是,作为区域签名者,您自己的在线内容和系统对客户而言将更加脆弱。作为远程服务器运营商,结果将是,其他人的内容和系统对您来说都将更脆弱。人们通常认为这些风险超过了收益,因为唯一的好处是保护DNS数据免于进行中的修改或替换。这种攻击非常罕见,因此不值得所有这些努力。我们都希望DNSSEC有一天会成为主流,因为它将启用新的应用程序。但是事实是,今天,DNSSEC完全是成本,没有收益,而且风险很高。

因此,如果您不想使用DNSSEC,那是您的特权,但是不要让任何人混淆DNSSEC的问题是其作为DDoS放大器的作用。DNSSEC无需充当DDoS放大器;还有其他更便宜的更好方法将DNS用作DDoS放大器。如果您不想使用DNSSEC,请放开它,因为您还没有喝醉Kool Aid,并且想要成为后一个行动者(后来)而不是第一个行动者(现在)。

必须防止DNS内容服务器(有时称为“权威服务器”)被滥用为DNS反射放大器,因为DNS使用UDP,并且UDP可被欺骗性源数据包滥用。保护您的DNS内容服务器免遭这种滥用的方法既不是阻止UDP,也不是强制TCP(使用TC = 1技巧),也不是阻止ANY查询,也不选择退出DNSSEC。这些东西都不会帮助您。您需要DNS响应速率限制(DNS RRL),这是一种完全免费的技术,目前已在包括BIND,Knot和NSD在内的数个开源名称服务器中使用。您无法解决防火墙的DNS反射问题,因为只有内容感知中间箱(例如DNS服务器本身(添加了RRL))对请求了解得足够多,才能准确地猜测什么是攻击,什么不是攻击。我想再次强调:DNS RRL是免费的,每个授权服务器都应运行它。

最后,我想揭露我的偏见。我写了大多数BIND8,发明了EDNS0,并共同发明了DNS RRL。自1988年以来,我从事DNS的工作已有20余年,而现在我脾气暴躁的是50余年,对于半生半熟的被误解的解决方案的耐心越来越少。如果此消息听起来太像“嘿,孩子们,请从我的草坪上走出去!”,请接受我的歉意。


7
确认这是Real Paul™。
安德鲁B

1
@AndrewB不能成为Real Paul™,他的帖子中有大写字母!;-)
Alnitak

6
@kasperd请参阅“草稿-ietf-dnsop-cookies”,该文件目前正在通过IETF进行。
Alnitak

4
kasperd:[进行速率限制的DNS服务器本身将更容易成为DDoS攻击的目标。]我知道我是个白痴,但我不是那个白痴。dns rrl绝对不会降低您的安全性。这并不是针对所有已知攻击的防御措施,而是没有新攻击的创建者。
Paul Vixie

2
@kasperd的已安装基础始终是一个问题-没有解决方案即使在符合标准的已安装基础上也无法使用,更不用说那里的不符合标准的系统了。好消息是BIND 9.11的代码库中已经有EDNS cookie支持,并且默认情况下(AIUI)将打开。
Alnitak

7

我知道两个特定的漏洞。霍坎提到了反射/放大。并且存在区域枚举的可能性。

反射/放大

反射表示攻击,其中具有欺骗性源IP的请求被发送到DNS服务器。被欺骗的主机是攻击的主要受害者。DNS服务器将在不知不觉中将答复发送到从未要求过的主机。

放大是指任何反射攻击,其中反射响应比原始请求包含更多字节或更多数据包。在DNSSEC + EDNS0之前,以这种方式放大只会允许最多发送512个字节。使用DNSSEC + EDNS0,可以发送4096个字节,通常跨越3-4个数据包。

有可能缓解这些攻击的方法,但我不知道有任何实施这些攻击的DNS服务器。

当尚未确认客户端IP时,DNS服务器可以发送截断的响应以强制客户端切换到TCP。截断的响应可以和请求一样短(如果客户端使用EDNS0而响应没有,则更短),这可以消除放大。

任何可以完成TCP握手并在连接上发送DNS请求的客户端IP都可以暂时列入白名单。一旦列入白名单,IP便可以发送UDP查询和接收UDP响应,最大512字节(如果使用EDNS0,则为4096字节)。如果UDP响应触发了ICMP错误消息,则会再次从白名单中删除IP。

该方法也可以使用黑名单来逆转,这意味着默认情况下允许客户端IP通过UDP查询,但是任何ICMP错误消息都会将IP列入黑名单,而需要进行TCP查询才能摆脱黑名单。

覆盖所有相关IPv4地址的位图可以存储在444MB的内存中。IPv6地址将必须以其他方式存储。

区域枚举

首先,区域枚举是否是易受攻击的话题。但是,如果您不希望您所在区域的所有名称成为公众知识,那么您可能会认为这是一个漏洞。可以通过使用NSEC3记录来减轻区域枚举。

即使使用NSEC3,仍然存在的问题是,攻击者可以通过简单地查询随机名称来找到每个标签的哈希。一旦攻击者拥有了所有哈希,就可以对这些哈希执行离线暴力攻击。

对区域枚举的适当防御将要求攻击者针对每次猜测对权威服务器执行查询。但是,DNSSEC中不存在此类防御。


2
但是,区域枚举似乎不是服务提供商所关心的?(根据他们的观点和偏好,可能更关心“所有者”区域。)
HåkanLindqvist

@HåkanLindqvist是的。也许我的问题比我想的更具体。我发现此信息非常有趣。
约翰·鲍尔

已经考虑将尝试过TCP的客户端列入白名单的想法,但显然已获得专利。
Alnitak

4

想到的实际上不是DNSSEC特定的,而是DNSSEC依赖的EDNS0扩展。

EDNS0允许使用更大的UDP负载,而更大的UDP负载可以允许更糟的流量反射/放大攻击。


我不知道验证解析器的百分比是多少,但是流行的名称服务器软件似乎默认情况下已启用验证,并且人们会很容易找到一些著名的服务提供商,他们愿意进行验证,例如Comcast和Google公共解析器。

基于此,我认为验证解析器的百分比可能比签名区域的百分比好得多。


是的,我当时在想,EDNS也可能确实存在。但是,如果选择DNSSEC代替它,那真是太奇怪了。
Andrew B
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.