|
|
|
|
移动端

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

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

作者:Victor来源:千里目安全实验室|2018-06-05 10:22

技术沙龙 | 邀您于8月25日与国美/AWS/转转三位专家共同探讨小程序电商实战

前言

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

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

在本文中,我想突出说明在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)使用。

【编辑推荐】

  1. IDC:2018年Q1全球服务器增长38.6%,DELL、HPE和浪潮分列前三
  2. IDC:第一季度全球服务器市场收入增长38.6%
  3. Netcraft 5 月 Web 服务器排名,Microsoft 大幅下跌
  4. 游戏服务器框架之网关
  5. 云服务器建站的几点好处,你知道吗?
【责任编辑:武晓燕 TEL:(010)68476606】


点赞 0
分享:
大家都在看
猜你喜欢
24H热文
一周话题
本月最赞

视频课程+更多

热门职位+更多

读 书 +更多

Head First 设计模式(中文版)

本书共有14章,每章都介绍了几个设计模式,完整地涵盖了四人组版本全部23个设计模式。前言先介绍这本书的用法;第1章到第11章陆续介绍的设...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊