《计算机网络安全原理》第8章 DNS安全

本PPT是电子工业出版社出版的教材《计算机网络安全原理》配套教学PPT（部分内容的深度和广度在教材的基础上有所扩展），作者：吴礼发本PPT可能直接或间接采用了网上资源、公开学术报告中的部分PPT页面、图片、文字，引用时我们力求在该PPT的备注栏或标题栏中注明出处，如果有疏漏之处，敬请谅解。同时对被引用资源或报告的作者表示诚挚的谢意！本PPT可免费使用、修改，使用时请保留此页。声明第八章DNS安全内容提纲DNSSEC2DNSSEC部署3DNS面临的安全威胁1DNS除了域名解析外，现代DNS还具有：应用层路由：DNS把用户的访问指向离用户最近的那个CDN服务器节点，负载均衡；Email服务器利用DNS服务器中的MX记录作为路由，找到企业内部真正的服务器DNS除了域名解析外，现代DNS还具有：DNS作为信任的基础：防伪造邮件、域名作为验证证书申请者身份的信任基础DNS除了域名解析外，现代DNS还具有：DNS作为PKI：防止CA在未经网站所有者授权的前提下签发非法的证书域名的层次结构DNS域名的层次结构DNSDNS域名递归查询过程递归查询以浏览网站为例说明域名解析过程浏览器导航栏中键入网站的域名或单击URL链接后，浏览器将启动DNS解析过程来查找这些IP地址浏览器会向“解析器”(resolver)发送一个查询，解析器会在本地保留以前查询过的问题的答案副本（缓存），如果存在直接响应浏览器。如果缓存中没有，则解析器会执行完整的DNS解析过程。以浏览网站为例说明域名解析过程向13个根服务器中的任意一个根服务器发送包含网站域名的查询，询问该网站对应的IP地址。收到查询请求的根服务器会返回一个“引荐”（referral）作为响应，包含网站域名TLD的名称服务器的列表。例如，如果您尝试访问网站，您的解析器将向其中一个根服务器发送一个查询，询问该域名的IP地址，此时，根服务器将返回一个列出了“.com”（我们示例中的TLD）的所有名称服务器的列表。以浏览网站为例说明域名解析过程将同一查询发送到引荐响应中收到的其中一个TLD的名称服务器。TLD名称服务器通常也只包含它们负责的域的名称服务器信息。因此，就像发送到根服务器的查询一样，发送到TLD名称服务器的查询也会收到引荐响应，提供一个有关所查询的二级域的名称服务器列表。如前例，解析器将向其中一个“.com”名称服务器发送对“”的查询，询问该域名的IP地址，“.com”名称服务器将返回一个列出“”的所有名称服务器的列表。以浏览网站为例说明域名解析过程此解析过程将一直继续，直到将查询发送到符合以下条件之一的域名服务器：拥有答案，即Web服务器的IP地址；或者域名服务器能够发布权威性声明，表示所查询的域名不存在。在示例中，解析器将向其中一个“”的名称服务器发送对“”的查询，该名称服务器可能知道与“”相关的IP地址，并返回这些地址。。以浏览网站为例说明域名解析过程根服务器系统（rootserversystem）由1000多台单独的计算机（称为根服务器“节点”【instance】）组成，这些计算机会保留DNS的根数据。这些节点通过引荐顶级域的名称服务器来响应来自互联网解析器的查询。根服务器镜像根域名服务器递归与迭代相结合的查询DNSDNS生态系统DNS面临的安全威胁DNS面临的安全威胁一、协议脆弱性域名欺骗：域名系统(包括DNS服务器和解析器)接收或使用来自未授权主机的不正确信息，事务ID欺骗和缓存投毒DNS安全威胁DNS缓存DNS安全威胁一、协议脆弱性域名欺骗：域名系统(包括DNS服务器和解析器)接收或使用来自未授权主机的不正确信息，事务ID欺骗和缓存投毒DNS安全威胁一、协议脆弱性USENIXSecurity2020：郑晓峰等，PoisonOverTroubledForwarders:A

cachePoisoningAttackTargetingDNSForwardingDevices。提出了针对DNS协议设计的一种新的攻击方法，可以针对广泛部署的DNS转发服务（如家用Wi-Fi路由器、公共Wi-Fi等场景）实现缓存污染攻击，D-Link、Linksys、微软DNS、开源软件dnsmasq等多个知名品牌的产品或系统可能受到该攻击的影响。DNS安全威胁一、协议脆弱性域名欺骗：域名系统(包括DNS服务器和解析器)接收或使用来自未授权主机的不正确信息，事务ID欺骗和缓存投毒DNS安全威胁DNS安全威胁阅读在线文档“真的黑客能让你分分钟开进沟里，但他们不屑于此”（/s/z-Qk0-uDchvEtGKQDw8wkQ），讨论2008年丹·卡明斯基发现的DNS缓存攻击方法和2020年段海新、钱志云等人发现的DNS缓存攻击方法的实现过程讨论一、协议脆弱性网络通信攻击：针对DNS的网络通信攻击主要是DDoS攻击、恶意网址重定向和中间人(man-in-the-middle,MITM)攻击DNS安全威胁2016，DNS服务Dyn被DDoS攻击2013，DNS被用于反射DDoS一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁段海新等USENIX2018一、协议脆弱性网络通信攻击：DNS域名解析过程劫持DNS安全威胁二、实现脆弱性DNS软件，BIND的漏洞和缺陷无疑会给DNS系统带来严重的威胁，其缓冲区溢出漏洞一度占据UNIX及Linux操作系统相关安全隐患的首位DNS安全威胁二、实现脆弱性

WindowsDNSServer实现安全漏洞（CVE-2020-1350）DNS安全威胁三、操作脆弱性由于人为操作或配置错误所带来的安全隐患：域名配置攻击、域名注册攻击和信息泄漏等DNS安全威胁攻击目标网站域名注册服务提供商

修改目标网站域名记录

申请网站证书

伪装成目标网站组合攻击实现网站假冒攻击目标网站域名注册服务提供商

修改目标网站域名记录

申请网站证书

伪装成目标网站组合攻击实现网站假冒攻击目标网站域名注册服务提供商

修改目标网站域名记录

申请网站证书

伪装成目标网站组合攻击实现网站假冒通过查看的域名系统（DNS）记录，发现指向的是马来西亚的Internet地址：9攻击者还从Let’sEncrypt获得了的免费加密证书。组合攻击实现网站假冒此外，IP被解析到域名组合攻击实现网站假冒DNS是互联网治理的焦点DNS是互联网治理的焦点，涉及技术标准、国际政治、法律经济等各种纠纷伊拉克战争期间，在美国政府授意下，伊拉克顶级域名“.iq”的申请和解析工作被终止，所有网址以“.iq”为后缀的网站从互联网蒸发中国部署了4台IPv6根域名服务器。打破垄断、突破封锁，中国彻底打破了没有根服务器的困境。关于伊拉克国家域名IQ被删除的事件:关于IPv6试验根项目:DNS是互联网治理的焦点JonPostel:互联网之神DNS是互联网治理的焦点内容提纲DNSSEC2DNSSEC部署3DNS面临的安全威胁1DNSSEC域名欺骗、恶意网址重定向和中间人攻击之所以能够成功，是因为DNS解析的请求者无法验证它所收到的应答信息的真实性和完整性。为应对上述安全威胁，IETF提出了DNS安全扩展协议（DNSSEC）。DNSSECDNSSEC基本思想依赖于数字签名和公钥系统去保护DNS数据的可信性和完整性：权威域名服务器用自身的私钥来签名资源记录，然后解析服务器用权威域名服务器的公钥来认证来自权威域名服务器的数据，如果认证成功，则表明接收到的数据确实来自权威域名服务器，则解析服务器接收数据，如果认证失败，则表明接收到的数据很可能是伪造的，则解析服务器抛弃数据DNSSECDNSSEC基本思想尽管DNSSEC的原理比较简单，但其标准的制定和部署面临着巨大的挑战：域名软件之父保罗·维克多（PaulVixie）的曲折经历DNSSECPaulVixiePaulVixiePaulVixie以得到广泛支持的RFC4033-4035版本为例简要介绍DNSSEC的基本内容提供数据来源验证：DNS数据来自正确的域名服务器；

提供数据完整性验证：数据在传输过程中没有任何更改；提供否定存在验证：对否定应答报文提供验证信息DNSSEC原理以得到广泛支持的RFC4033-4035版本为例简要介绍DNSSEC的基本内容提供数据来源验证：DNS数据来自正确的域名服务器；

提供数据完整性验证：数据在传输过程中没有任何更改；提供否定存在验证：对否定应答报文提供验证信息DNSSEC原理以得到广泛支持的RFC4033-4035版本为例简要介绍DNSSEC的基本内容DNSSEC原理DNSSEC中新增的四种类型的资源记录：DNSKEY(DNSPublicKey)、RRSIG（ResourceRecordSignature）、DS(DelegationSigner)、NSEC(NextSecure)DNSSEC资源记录DNSKEY：存储服务器的公开密钥DNSSEC资源记录标志(Flags)协议(Protocol)算法(Algorithm)公钥(Public

Key)2

octets1

octet1

octetDNSKEY：存储服务器的公开密钥DNSSEC资源记录DNSKEY：存储服务器的公开密钥DNSSEC资源记录在DNSSEC的实践中，权威域的管理员通常用两对密钥配合完成对区数据的签名第一对密钥用来对区内的DNS资源记录进行签名，称为区签名密钥（ZoneSigningKey,ZSK），由权威认证服务器生成、签名。另一对称为密钥签名密钥（KeySigningKey,KSK）的公私钥对，用来对包含密钥（如ZSK）的资源记录（DNSKEY）进行签名，并将签名结果放在DNSKEY的RRSIG记录中DNSSEC资源记录DNSKEY：存储服务器的公开密钥DNSSEC资源记录DNSSEC信任根信息可以查IANA的网站（/dnssec/files）信任链建立过程

RoottrustanchorsRRSIG：存储对资源记录集合（RRSets）的数字签名DNSSEC资源记录RRSIG：存储对资源记录集合（RRSets）的数字签名DNSSEC资源记录RRSIG：存储对资源记录集合（RRSets）的数字签名DNSSEC资源记录NSEC：为了应答那些不存在的资源记录而设计在区数据签名时，NSEC记录会自动生成。如在和之间会插入下面的两条记录DNSSEC资源记录涉及到所有者域名的排序问题DS：记录存储DNSKEY的散列值，用于验证DNSKEY的真实性，从而建立一个信任链DNSSEC资源记录DS：记录存储DNSKEY的散列值，用于验证DNSKEY的真实性，从而建立一个信任链DNSSEC资源记录示例：区DNS资源记录内容签名前后的变化情况DNSSEC资源记录DNSSEC新增的4种资源记录，这些记录的长度远远超过了最初的DNS协议标准规定的512字节，而要求DNS报文大小必须达到1220字节，甚至是4096字节。因此DNS服务器如果要支持DNSSEC，则首先需要支持扩展DNS机制（ExtensionMechanismsforDNS,EDNS）DNSSEC对DNS协议的修改1987年的RFC1035限制了DNS报文大小、新功能EDNS扩展DNS格式和功能IPv6、DNSSEC、ECS等向后兼容的Workaround尝试服务器不支持或被防火墙过滤DNSFlagday:2019/2/1日后，对EDNS实现不标准的授权服务器，Google等公共DNS将不再尝试访问，可能导致解析失败EDNS1987年的RFC1035限制了DNS报文大小、新功能EDNS扩展DNS格式和功能EDNS伪资源记录：DNSSEC对DNS协议的修改DNSSEC在协议报文头中增加了三个标志位：DO（DNSSECOK,参见RFC3225）标志位：支持DNSSEC标志位AD（AuthenticData）标志位：认证数据标志CD

（CheckingDisabled）标志：关闭检查标志位DNSSEC对DNS协议的修改伪资源记录（OPT）DNSSEC递归解析过程DNSSECDNSSEC递归解析过程DNSSECDNSSEC解析示例解析示例参见教材配套的实验指导书的8.2.3节查看DNSSEC域名解析过程/DNSSEC的安全性取决于PKI所用密钥的安全性DNSSEC选择RSA/SHA-n加密算法，即首先将要传送的数据通过SHA-n算法进行安全散列变换，然后利用RSA算法生成的私钥进行数字签名DNSSEC安全性分析DNSSEC通过数字签名保证域名信息的真实性和完整性，防止对域名服务信息的伪造、篡改DNSSEC并不保证机密性，因为它不对DNS记录进行加密也解决不了DNS服务器本身的安全问题，如被入侵、存储的Zone数据被篡改、拒绝服务攻击、DNS软件的实现问题等DNSSEC安全性分析由于DNSSEC的报文长度增加和解析过程繁复，在面临DDoS攻击时，DNS服务器承受的负担更为严重，抵抗攻击所需的资源要成倍增加DNSSEC安全性分析DNS加密(DNSCrypt)DNS加密(DNSCrypt)DNS加密(DNSCrypt)DNS加密（DoH）内容提纲DNSSEC2DNSSEC部署3DNS面临的安全威胁1DNSSEC的部署也面临着巨大挑战。1999年RFC2535发布后的近10年间，DNSSEC受限于技术、成本、网络性能等多方面因素的影响，一直未得到各方面的充分重视，部署进展缓慢。BIND9的开发主要用于支持DNSSEC协议。2000年，瑞典在其国家顶级域中首次尝试部署DNSSEC协议，但发现存在隐私和扩展方面的问题。随后几年，DNSSEC协议修修补补，部署实施进展缓慢DNSSEC部署DNSSEC部署DNSSEC部署截止2018年底，中美著名公共DNS服务器支持DNSSEC的情况DNSSEC部署DNSSEC部署DNSSEC部署DNSSEC部署DNSSEC部署中美三个行业权威服务器DNSSEC部署情况DNSSEC部署DNSSEC协议设计时并没有考虑增量式部署的情况，其安全功能是基于所有