DNSSEC(DNS安全扩展)
Date:
DNS 是在 30 多年前设计的,当时安全并不是互联网的主要关注点。如果没有额外的保护,MITM 攻击者就有可能欺骗记录并将用户引导到网络钓鱼站点。著名的GFW 最早开始干的就是这事情。
DNS的工作原理
在讲DNSSEC这个功能之前,让我们先来看看DNS的工作原理。我们每个用户,在进行网页浏览的时候,都会输入域名,来打开相应的网页,比如要打开淘宝,我们在浏览器中输入http://www.taobao.com,浏览器就会将淘宝的页面呈到我们的眼前。当电脑在访问某一个页面的时候,是需要指定IP地址才能进行访问,那么输入域名后,到页面展示中间,发生了一些什么事情呢?首先会去本地DNS服务器去查询,是否存在http://www.taobao.com这个域名的解析记录,如果能查到,那么就直接将结果返回给用户了。可是如果没有查到怎么办,就需要本地DNS进行递归的流程,依次去根服务器、.com服务器、http://taobao.com服务器、http://www.taobao.com服务器上查询,最终获得http://www.taobao.com 的IP地址,从而浏览器可以展示出淘宝页面。
DNS并非无懈可击
(1)递归链路有被劫持的风险
通过工作原理中的例子我们可以看出,在进行一次递归查询的时候,需要对链路上每一个权威服务器进行请求,接收到应答后再去下一个权威服务器进行查询。有攻击者利用了其中的漏洞:当本地DNS去请求某一个权威DNS服务器的时候,中间的请求很容易就被攻击者冒充或伪造,返回给本地DNS一个错误的解析结果。而由于没有验证手段,此时本地DNS就会拿到错误的解析结果去进行后续的解析,从而网站被重定向到可能有潜在危险的恶意网站。
(2)Local DNS有被投毒的风险
递归解析器可以从权威服务器中接收到DNS数据,并将其进行缓存,当有后续请求时,可以使用缓存数据进行应答,从而加速解析流程。当缓存数据被攻击者模拟权威DNS响应而被递归解析器接收后,缓存中的数据就会变为攻击者的数据。那么后续再进行解析的时候,就都是具有危险性的解析结果了。比如此地址指向了一个钓鱼网站,用户就会在在不知情的情况下丢失了用户密码,给用户和企业带来损失。
如何来确定解析结果是真正权威的结果呢?DNSSEC技术顺势而生,有效保障了解析结果的正确性。
DNS 安全问题所在
DNS 系统没有内置方法来验证对请求的响应不是伪造的,或者过程的任何其他部分没有被攻击者中断。
这是一个问题,因为每当用户想要连接到您的网站时,他们都必须进行 DNS 查找以将您的域名转换为可用的 IP 地址。如果用户从不安全的地方(例如咖啡店)进行连接,则恶意攻击者可能会坐在中间并欺骗 DNS 记录。这种攻击可能允许他们通过修改 IP 地址 A 记录将用户重定向到恶意页面。
递归解析器向权威域名服务器发送查询时,解析器无法验证响应真实性。解析器仅可检查权威域名服务器IP地址。但是,依赖响应对应的源IP地址并非强验证机制,因为DNS响应数据包的源IP地址很容易仿冒或伪造。
幸运的是,有一个解决方案——DNSSEC,也称为 DNS 安全扩展,可以解决这些问题。它通过使用公钥签署您的 DNS 记录来保护 DNS 查找。启用 DNSSEC 后,如果用户收到恶意响应,他们的浏览器可以检测到。攻击者没有用于签署合法记录的私钥,无法再伪造。
什么是DNSSEC?
DNS安全扩展是Internet工程任务组(IETF)提供的一系列DNS安全认证的机制。
它是DNS提供给DNS客户端的DNS数据来源进行认证,保证Local DNS(resolver)和权威之间的数据不被篡改(中间人攻击)。当解析数据被篡改后,开启DNSSEC功能的域名,会对获取到的解析数据上的签名进行验签,在验签的过程中,如果失败,则说明获取的解析数据是异常的,则不会使用此解析结果,从而保证用户拿到的解析结果一定是真实可信的。
DNSSEC如何工作
DNSSEC 采用基于公共密钥加密的数字签名,从而增强DNS验证强度。
DNSSEC并非对DNS查询和响应本身进行加密签名,而是由数据所有者对DNS数据自身进行签名。
签名验证的位置:解析器
工作方式:每一个 DNS 区均包含一个公私秘钥对。DNS 区所有者使用该区域的私钥对区域内的 DNS 数据进行签名,为这些数据生成数字签名。顾名思义,"私钥"是指 DNS 区所有者会对这些密钥材料保密。但是,该区域的公钥则在区域内公开发布,供全体用户检索。凡在区域内查找数据的递归解析器,还必需检索区域公钥,从而使用公钥验证 DNS 数据的真实性。
DNSSEC 在 DNS 协议中新增了两项重要功能:
数据来源验证 - 解析器可以通过加密的方式验证收到的数据是否确实来自其认定的数据传送区域。
数据完整性保护 - 解析器可以确信,自区域所有者使用区域私钥初次进行数据签名以来,数据在传输过程中并未遭到修改。
区域公钥本身可靠性
每个区域公钥也经过签名。由父区域私钥签名。例如,http://icann.org zone 的公钥由 org 区域进行签名。每一个区域的公钥均由其父区域签名,但根区除外:没有可供进行密钥签名的父区域。
因此,根区公钥是验证 DNS 数据的重要出发点。如果解析器信任根区公钥,则可信任经根区私钥签名的顶级区域公钥,如 org 区域公钥。由于解析器可以信任 org 区域公钥,因而可以信任经其各自私钥签名的公钥,如 http://icann.org 公钥。
DNSSEC 的密钥签名一直沿链而上。当您连接到 时example.com,您的浏览器首先连接到由 IANA 管理的 DNS 根区域,然后连接到扩展的目录(.com例如),然后连接到您的域的名称服务器。当您连接到 DNS 根区域时,您的浏览器将检查由 IANA 管理的根区域签名密钥以验证它是否正确,然后是.com 目录签名密钥(由根区域签名),然后是您站点的签名密钥,即由.com 目录签名,不可伪造。
对其他加密密钥进行签名的加密密钥序列称为信任链。信任链最前端的公钥称为信任锚。大部分解析器仅配置一个信任锚:根区公钥。通过信任 DNS 层次结构顶端的这个密钥,只要对路径中的每一个区域均进行签名,则解析器可以为 DNS 域名空间的任意位置构建信任链。
如何启用 DNSSEC
目前腾讯云阿里云都支持这个服务
腾讯云的开启DNSEC服务,教程:https://cloud.tencent.com/document/product/242/52521
这些找客服问一下就好,cloudflare 也有,么有啥好说的。
安利:
参考文章:
DNSSEC(DNS安全扩展) https://zhuanlan.zhihu.com/p/139889234
保护网站访问安全--阿里云DNS正式支持DNSSEC https://zhuanlan.zhihu.com/p/107552714
转载本站文章《DNSSEC(DNS安全扩展)》,
请注明出处:https://www.zhoulujun.cn/html/tools/NetTools/throughGFW/8787.html