DNS协议正在改变,你准备好了吗?

服务器
就互联网协议而言,我认为DNS协议是一个伟大的成功案例。DNS协议是为不同于我们今天的互联网而创建的,它假设运行在更友好的、和谐的互联网上,没有放大DDoS攻击,MITM攻击和DNS欺骗。总体而言,原始形式的DNS协议存活得很好,其中也包括小众的协议比如EDNS 0和DNSSEC(几乎没有人使用)。

前言

就互联网协议而言,我认为DNS协议是一个伟大的成功案例。DNS协议是为不同于我们今天的互联网而创建的,它假设运行在更友好的、和谐的互联网上,没有放大DDoS攻击,MITM攻击和DNS欺骗。总体而言,原始形式的DNS协议存活得很好,其中也包括小众的协议比如EDNS 0和DNSSEC(几乎没有人使用)。

但最近,特别是由于更多隐私的需要以及更加大胆、不受管制的数据交易ISP的参与,我们需要更多的隐私权。此外,DNSSEC未能获得广泛的领导力,导致其他更简单的想法提供甚至替代了DNSSEC的大部分优秀特性。

[[231716]]

在本文中,我想突出说明在DNS流量中正在出现的两个改变:

1 - DNS cookies

DNS cookies已经在RFC 7873中引入。它们试图解决DNSSEC试图解决的许多问题(比如缓存毒化问题),并且它们正在解决诸如DNSSEC无法阻止的欺骗性DNS放大攻击等问题。在某些情况下,DNSSEC可能会使这些攻击变得更糟。为了获得全面的“胜利”:DNS cookies比DNSSEC更容易实现。 DNS cookies提供的安全性应该与使用TCP替代UDP获得的安全性相似。要成功欺骗TCP,攻击者需要猜测32位序列号。 DNSSEC更难以猜测破解,所以DNS cookies安全性不如DNSSEC。但DNS cookies已经“足够”了。

那么DNS cookies是怎样工作的?

发送DNS请求的客户端将附加一个cookie选项。该cookie是客户端IP、服务器IP和一个secret的hash值。所以服务器会接收来自特定客户端的一致的cookie。 secret应该至少有64位长。只要cookie与特定的服务器/客户端一致,细节就无关紧要。

服务器cookie使用服务器IP地址、客户端cookie以及只有服务器才知道的secret。客户端IP由于NAT可能无法确定,所以使用客户端cookie代替客户端IP。这可以再一次保证服务端/客户端的一致性。

支持cookie的客户端发送的所有请求都包含cookie。这“应该”不会引起任何问题。不支持的选项将被忽略。但是,过去有些测试表明,存在不合规的DNS服务器可能会拒绝该请求。几年前的这个测试表明,10%的名称解析服务器存在问题。不知道现在是什么情况,但是比例应该已经减小很多了。

如果过去与此服务器通信过,客户端将包含服务器的cookie。

一旦服务器收到客户端cookie的请求,下面的一种情况可能发生:

1.  如果服务器不支持cookie,那么它会像普通模式一样忽略cookie。

2.  如果服务器确实支持cookie,并且客户端仅发送了一个包含客户端cookie的请求,那么服务器将响应,但它可能只包括除服务器cookie。现在,客户端可以重新发送查询并包含服务器cookie。服务器发送完整的响应,并针对无服务器cookie的请求使用不同的速率进行限制。对于不包含cookie的TCP请求,服务器也可能更加宽松。

3.  如果客户端包含服务器cookie,并且cookie是真实的,那么服务器将发送响应。

对于格式错误的cookie,会返回错误(FORMERR)。包含无效服务器cookie的请求被视为根本不包含服务器cookie的请求。此功能允许客户端在IP地址更改时或者服务器重新启动并选择新secret时DNS cookie机制自动恢复。

DNS cookies已经在BIND 9.11中实现。如果您安装了Ubuntu 18.04 LTS,您可能看到BIND使用它们。在BIND中,cookie默认是启用的,但默认情况下不会强制执行。此外,“dig”工具现在支持DNS cookie,只要使用+cookie选项即可。

这是一个示例数据包,显示DNS请求中的cookie选项。我还没有发现任何支持该选项的大型DNS提供商,但我没有对它们进行全部测试。

要过滤这些查询,可以使用Wireshark显示过滤器“dns.opt.code == 10”。它没有很好的BPF表达式,但是“tcpdump -r dns -n 'udp[18:2]>0 && udp[10]&0x80=0'”将显示所有带有DNS选项的查询(有些可能只是EDNS选项0)。

捕获的数据包:使用Ubuntu 18.04,带有cookie的DNS数据包。

2 - TLS上的DNS

我看到越来越多的DNS创新是基于TLS的DNS。与DNS cookie不同,TLS上的DNS尝试解决DNS中的隐私问题。在Cloudflare的“1.1.1.1”DNS服务开始支持它之后,它出现了更多的追随者。我在PFSense防火墙中设置它,并在下面包含一些示例数据包。

该协议非常“直接”:设置TCP TLS连接,然后通过此TLS隧道发送DNS查询。问题在于TLS连接需要相当多的开销来建立。但它可以重复使用多个查询来减小总开销。在现实生活中,我发现TLS连接只能持续很短的时间,因此只要交换的数据包数量很大,开销就会很大。另外请注意,TLS端点将能够查看您的所有查询。Cloudflare表示它们不会使用这些数据。

使用TLS实现DNS的棘手部分是,它使许多企业系统无法获取和监控DNS流量。最好的办法是阻止TLS上的DNS(它使用端口853/TCP)并要求用户使用内部递归DNS服务器。然后,您可以在该DNS服务器上分析所有的日志记录。相比您的ISP,如果您更信任CloudFlare的TLS DNS服务器,您甚至可以让内部递归DNS服务查询Cloudflare的DNS服务器,。根据我的观察,基于TLS的DNS也不使用TLS中的ALPN或SNI选项,这些选项由更多“常规”的TLS连接(比如HTTPS)使用。

责任编辑:武晓燕 来源: 千里目安全实验室
相关推荐

2012-10-25 09:47:01

BYOD

2010-08-25 15:49:04

面试

2016-05-31 16:50:33

2011-05-25 17:08:29

ibmdwLinux

2021-08-02 15:42:36

人工智能无人机无人驾驶

2011-05-25 10:15:47

开源

2015-10-19 16:51:01

2015-01-07 10:45:05

Dockerkubernetescontain

2013-01-28 16:51:45

2018-10-11 17:43:15

人脸识别人工智能AI

2011-01-12 09:37:59

2020-03-26 17:28:22

CIO观点MES系统制造企业

2018-10-16 18:26:52

人工智能AI

2015-06-24 16:03:24

大数据.SAS

2015-09-08 16:04:06

云灾备华为

2011-08-30 09:28:36

编程

2021-04-28 11:38:10

“熄灯”数据中心数据中心运维

2021-01-08 05:18:54

网络自动化运维

2014-06-04 12:50:43

转型IT转型

2019-05-20 10:28:29

IIoT边缘计算物联网设备
点赞
收藏

51CTO技术栈公众号