域名系统(domain name system, 简称DNS)作为互联网的重要基础设施, 其主要功能是提供域名解析服务.随着互联网的发展, DNS也被赋予了其他的应用功能, 如DKMI(domain keys identified mail)标准[]、负载均衡[]、域名封锁[]等方面.互联网的大多数应用都需要依赖DNS才能正常工作, 一旦DNS系统受到攻击, 整个互联网将会受到严重影响.
目前实际使用的DNS协议主要遵循RFC 1034和RFC 1035规范, 为了弥补DNS协议缺乏信息校验的不足, RFC 4034引入了基于PKI技术的DNSSEC增强方案.然而, DNS系统的安全威胁并未因此减弱.近年来的各种DNS安全事件[], 不仅对被攻击的组织和公司造成严重的经济损失, 也给整个互联网的稳定性带来严重的影响.随着一些新型攻击方法的出现, DNS的安全环境变得更加严峻, 例如:利用物联网设备对DNS系统发起ddos(distributed denial-of-attack)攻击[, ]、利用DNS报文分析用户的隐私信息[]、利用DNS建立隧道攻击[].
针对DNS的各种安全威胁, 截止至2017年12月, 有关DNS的RFC文档多达256篇[].国内外学者针对DNS安全问题提出了许多新颖的思路.本文针对近10年来DNS安全威胁与防护相关研究工作进行了分析和综述, 总结了DNS威胁的种类和原因, 并侧重介绍DNS在协议、系统实现、诊断监测、隐私保护、体系结构方面的安全增强方法和研究进展, 并结合区块链技术的不易篡改、多方维护、可溯源等特点, 列举利用区块链技术设计去中心的域名系统的相关研究, 并希望为未来的研究工作提供帮助和参考.
本文第1节介绍DNS的安全现状.第2节对DNS的威胁进行分类, 总结归纳DNS系统脆弱性的根本原因.第3节针对DNS系统脆弱性, 列举各种安全增强方案, 并进行比较分析.第4节对DNS安全研究工作提出热点和展望.最后给出简要总结.
随着网络技术的不断发展, 攻击DNS的技术也变得更加丰富, 手段更加复杂.美国Coleman Parkes公司调查了来自北美、亚太、欧洲共1 000个组织的DNS系统安全状况后发现[10], 在2017年有76%的组织受到了DNS攻击, 在这些攻击中, 恶意软件攻击占35%、ddos攻击占32%、缓存投毒占23%、DNS隧道占22%、零日漏洞攻击占19%.超过90%的恶意软件使用DNS协议与恶意软件的命令和控制(command and control, 简称C & C)中心保持联系, 以此获取攻击命令、下载软件更新、获取隐私信息.DDoS攻击也变得越来越复杂, 攻击者使用广泛的技术手段, 从基本的方法(如:放大/转发、泛洪), 到涉及僵尸网络、连锁反应等高度复杂的攻击, 这些攻击可能来自内部或外部DNS服务器.根据Arbor Network发布的调查报告[11]显示, 有84%的反射和放大攻击[12]采用DNS协议, 是所有调查协议中占比最高的.此外, 报告中还显示DNS的服务器是DDoS攻击的首要目标, 有78%的DDoS攻击对DNS的应用层服务进行攻击.
攻击DNS有利可图, 商业利益驱动促使攻击行为加剧.有攻击者通过攻击DNS服务器, 造成企业服务中断, 损坏企业信誉, 造成用户流失.如2016年10月在Dyn域名服务供应商受到大规模DDoS攻击之后, Dyn公司失去了8%的域名客户.DNS攻击还会造成关键数据泄露和经济损失.根据EfficientIP的调查报告, 在调查的1 000个公司和组织中, 有三分之一的公司因DNS攻击数据被盗, 这些数据中16%是用户敏感信息, 15%是知识产权信息.此外, DNS攻击每年会给受害公司造成200万美元的经济损失.
DNS攻击技术越来越丰富, 但是与之应对的检测技术则比较匮乏.据Cisco的研究报告[13]显示, 攻击者通过恶意软件, 在24小时内可以控制超过10万台物联网设备, 通过这些物联网设备可以发动大规模的DDoS攻击.因为这些恶意软件被存储在受害设备的内存中, 设备关机后就自动清除, 很难收集恶意程序的样本, 服务器软件的零日漏洞存在使检测难度增大, 有83%的公司没有及时安装安全补丁, 导致攻击效果进一步加剧.
DNS主要由3部分组成, 分别是:(1)域名空间(domain name space)和资源记录(resource record), 包括树形结构的命名空间和与名称相关联的数据; (2)名字服务器(name server), 包含域树结构信息和设置信息的服务器程序; (3)解析器(resolver), 响应请求并从名称服务器获取查询结果.DNS通常提供两种域名解析方式, 分别是:递归式查询和迭代式查询.在通常情况下, 应用系统主机向本地域名服务器请求域名解析时, 采用递归查询.在递归查询模式下, 本地域名服务器直接向应用系统主机返回域名解析结果.当地域名服务器需要向根域名服务器请求域名解析服务时, 采用迭代查询.在迭代查询模式下, 本地域名服务器需要与多台域名服务器交互, 直至返回域名解析结果.DNS的基本结构和工作原理如图 1所示.
为了分析DNS不同服务器层级和协议的安全问题, 本文对CVE漏洞信息库623条DNS相关漏洞进行对比分类, 针对不同类型的DNS系统漏洞对攻击目标及攻击后果进行总结归纳, 统计结果见表 1.
基于DNS漏洞和相关文献资料[14–18], 本文将DNS的脆弱性概括为协议脆弱性、系统实现脆弱性、体系结构脆弱性.
DNS协议在设计之初没有充分考虑网络安全问题, 采用UDP协议传输信息, 在消息传输的过程中, 数据未经过加密处理, 资源记录也不进行签名等防伪造保护.因此DNS协议很容易遭受缓存投毒、数据窃听、数据篡改等恶意攻击.
对DNS记录缓冲区投毒是非常普遍的攻击方式[19].互联网中存在大量的开放式解析器, 为攻击者提供了更多的攻击目标, 相关实验表明, 有7%~9%的解析器容易受到注入攻击.
DNS协议还存在隐私泄露问题[20, 21].由于DNS查询时包含许多敏感信息, 在域名解析的过程中, 可能会泄露用户身份和设备类型等个人隐私信息.有许多公司利用这一DNS缺陷, 搜集用户信息, 通过分析和分类后, 给用户发送相关广告[22].通过跟踪DNS流量分析用户行为, 这种方法的准确率可达88%[23].这说明, 攻击者完全可以利用DNS查询流量窃取用户隐私.
利用DNS漏洞的攻击手段还有很多[24], 如:(1)中间人攻击(MITM), 由于DNS不提供数据的真实性和完整性校验, 解析器无法判断收到数据的真实性和完整性, 攻击者可以利用这个漏洞进行中间人攻击, 如数据包伪造、事务ID欺骗(transaction ID spoofing); (2)缓存攻击, 使用缓存降低了访问时间, 但是会导致数据一致性问题, 如攻击者将虚假信息注入到DNS缓存中; (3)分布式拒绝服务攻击(DDoS), 如对根服务器进行DDoS攻击, 给全局DNS解析带来严重影响.
DNS系统的脆弱性源于DNS系统的实现、构成和管理方式.互联网中大量开放式DNS服务器没有遵守最佳配置原则, 也没有进行必要的安全验证, 域名解析存在严重的安全隐患.DNS服务软件也存在大量的漏洞, 利用DNS服务软件的零日漏洞发起的攻击已是攻击DNS的重要手段.
大量的开放式第三方DNS服务器管理不规范是DNS系统脆弱性的原因之一.DNS系统经过多年的发展, 系统越来越复杂, 服务器数目也越来越庞大, 其中包含了许多开放的DNS服务器.除了熟知的Google DNS和Public DNS等开放式DNS服务器外, 仍有大量的由非政府组织和个人等第三方机构架设的开放式DNS服务器.但是这些开放式DNS服务器存在严重的安全隐患.在域名解析的过程中, 可能会涉及不同层级、地域的域名服务器和解析器, 但在数据传输的过程中没有建立安全链接, 数据的真实性和完整性也得不到保障.用户的个人信息和浏览记录会泄露给这些开放式DNS服务器提供商.
DNS系统没有遵守最佳配置原则, 导致系统存在安全隐患.目前网络上开放式解析器的数目为10×106~32×106个[25], 解析器采用复杂的解析策略, 如在树形结构中采用大型共享解析池.这些解析器可以分为3类:(1) “入口”服务器, 负责接收用户的解析请求; (2) “出口”服务器, 负责与域名服务器交互, 返回解析结果; (3)中间人服务器, 负责转发各种解析请求.其中, 后两类解析器对终端用户并不可见.但是这些开放式解析器存在严重的安全隐患, 其中只有19%的解析器能够返回正确的TTL[26].此外, 网络中存在大量用户无法访问的解析器, 这些解析器负责缓存解析结果, 提高解析效率.但是这些由第三方机构管理的服务器, 在部署和配置管理方面不够规范, 存在安全隐患[27].
DNS实现软件存在漏洞也是系统脆弱性的主要原因.互联网系统协会(Internet Systems Consortium, 简称ISC)调查了DNS服务器分布情况[28], 其中, 使用数量最多的前5个服务器软件见表 2.从表 2可以发现, BIND和Microsoft服务器软件数量占据了95%以上.漏洞信息库CVE披露[29], BIND软件漏洞高达102项, 涉及BIND 8、BIND 9和BIND 4.9等主要版本, 漏洞主要包括DoS、缓冲区溢出、权限漏洞等.Microsoft官网发布DNS服务器受到缓存嗅探攻击[30], 除了在配置上进行限制外, 没有好的修改办法.Bishop Fox公司发现Windows DNS客户端存在缓存区溢出漏洞[31], 在Win 8/Server 2012或者更高版本的计算机上, 可能会导致恶意DNS应答.攻击者利用这个漏洞在应用发送DNS请求时可以执行恶意代码.如果攻击者控制了DNS服务器(如通过中间人攻击), 就可以访问被攻击者的系统.此外, Microsoft DNS服务器也受到DoS攻击[32]、缓冲区投毒攻击[33].
DNS体系结构的脆弱性在于DNS根服务器存在单点失效的缺陷, DNS根服务器的分布也存在严重的失衡, 域名检索和控制过于中心化.
DNS系统虽然采用分层结构设计, 但其核心还是由根服务器管理整个DNS系统.根服务器负责维护顶级域名(top level domain, 简称TLD)的位置信息, 所有缓存在没有命中的情况下也都是从根服务器开始查询.目前全球共有13台根服务器, 这13台根服务器中有10台位于美国、2台位于英国和瑞典、1台位于日本.随着互联网的发展, 各国都有在本国设立根服务器的期望, 以此加强互联网核心基础设施的参与度, 并加强本地DNS服务器性能.2015年6月23日, 基于全新技术架构的全球下一代互联网(IPv6)根服务器测试和运营实验项目——“雪人计划”[34]发布, 该计划在原有13台根服务器的基础上, 在全球16个国家中再配置25台IPv6根服务器, 以期望实现全球互联网的多边共治, 但是这只是增加了根服务器的数量, 并没有从根本上解决DNS体系结构脆弱性问题.
根服务器作为整个DNS系统的核心, 如果发生单点故障, 整个系统将不能正常运行, 整个互联网也会受到严重影响.美国东部时间2002年10月21日, 13台根服务器受到有史以来最严重规模也是最大的DDoS攻击, 超过常规30~40倍的数据量攻击使其中的9台根服务器瘫痪.2007年2月6日, DNS根服务器再次受到DDoS攻击, 攻击持续近8小时, 攻击源遍布全球.2012年2月, 著名的黑客组织Anonymous宣布将会对全球13个根服务器进行DDoS攻击, 通过让根服务器过载而使全球网络瘫痪.
在域名检索过程中, 本地DNS服务器没有缓存记录的域名信息都需要访问根服务器, 以此获得下一步域名服务器的请求地址.域名验证过程中, 部署DNSSEC协议的根服务器作为信任锚, 存储顶级名称服务器的秘钥和签名记录, 为域名验证提供最终的权威认证.根服务器控制域名的解析和验证控制过于集中, 这是DNS体系结构脆弱性的根本原因.
综合各类DNS安全威胁, 表 3总结了DNS相关威胁方式和具体攻击实例.
针对DNS安全威胁的根本原因, 本节对近年来在协议、系统、检测监控、体系结构方面的增强方案进行了总结和分析.
为了解决DNS系统在数据传输过程中真实性和完整性保护问题, IETF(the Internet Engineering Task Force)提出了DNS安全增强方案DNSSEC[35].DNSSEC通过对资源记录进行签名, 用户在收到相关请求域名信息时也会收到该记录的签名, 用户可以根据签名来检测数据的真实性和完整性.DNSSEC在DNS的基础上, 增加了4种安全记录:(1) DNSKEY记录, 存储验证DNS数据的公钥; (2) RRSIG记录, 存储DNS资源记录的数字签名; (3) DS记录, 用于DNSKEY验证, 存储密钥标签, 加密算法和对应DNSKEY的摘要信息; (4) NSEC记录, 存储和对应所有者相邻的下一记录, 用于否定存在验证.
虽然DNSSEC在理论上能够很好地解决虚假域名信息的问题, 但在其实际的部署过程中却没有达到很好的效果.虽然有89%的顶级域名部署了DNSSEC, 但是二级域名的部署率仅为3%, .com域名部署率只有0.5%[36]. DNSSEC配置繁琐, 每个域将自身的DS记录上传到父域并由父域签名, 然后再依次上传直至根服务器.客户端可以对每个DNSSEC签名的记录构建一条信任链:根域签名顶级域, 顶级域签名二级域, 依次构建一条信任链.然而, 仅有大约1%的.com、.net和.org域名部署了DNSSEC, 在这些部署了DNSSEC的域名中, 有超过30%的域名由于缺少DS记录造成配置错误.
在部署了DNSSEC的客户端中, 仍有许多客户端出现解析故障.有研究机构对50多万个客户端使用DNSSEC名字解析情况进行了大规模测量, 测量结果发现, 仅小部分的用户受到DNSSEC验证保护, DNSSEC部署会导致端到端解析失败, 平均每10台部署DNSSEC的客户端中, 有大约1台客户端无法访问域名[37].此外, DNSSEC难以解决不同域之间的互操作和信息引用问题[38].
DNSSEC使用公钥密码体系, 在加密过程中也会引入额外的开销.由于DNSSEC消息加密开销, 大量的DNS请求导致服务器频繁计算签名, 增加了服务器响应时间, 大量的包含数字签名的报文也会占据带宽资源[39].
为DNS系统提供链路层安全保护, DNSCurve[40]通过椭圆曲线加密算法和密钥分发机制, 加密传输过程中所有的DNS数据包, 提供机密性和完整性保护.DNSCurve的工作过程如下:(1) DNSCurve服务器首先通过编码机制将公钥嵌入到NS资源记录(NS resource record)中, 客户端查找NS记录, 结合预定的编码机制, 找到对应的公钥; (2)客户端将DNSCurve的公钥和一次性随机数(nonce)一起放到密码箱中(cryptographic box), 并将这些进行编码后作为扩展DNSCurve的查询数据包; (3) DNSCurve名称服务器首先会校验客户端的请求数据包, 如果是正确的数据, 则将响应数据包通过密码箱进行加密, 作为扩展的响应数据包, 发送给客户端; 否则, DNSCurve服务器根据请求数据包的出错原因发送给客户端, 客户端收到响应数据包后, 进行重新修改或丢弃.虽然DNSCurve在DNS协议的基础上提供传输过程中的机密性和完整性保护, 但是采用DNSCurve的递归解析器没有办法通知名称服务器关于响应的有效性, 因此名称服务器只能盲目信任本地递归解析器.此外, DNSCurve需要对DNS协议进行修改, 导致DNSCurve的增量部署受到限制[41].
当前DNS协议使用UDP协议传输数据, 信息没有进行真实性和完整性验证, 因此对DNS传输协议进行增强是提高DNS安全性的一种手段.T-DNS[42]使用TCP和TLS协议替代UDP传输DNS消息, 解析器与服务器首先需要建立TCP连接, 然后使用TLS协议对DNS消息的内容进行加密保护, 防止内容泄露和恶意篡改.T-DNS利用TCP连接的数量限制机制, 能够防止恶意服务器主动推送虚假应答信息, 同时使用TLS协议保护数据传输安全, 解决了数据泄露[43]和恶意篡改问题.这种方式的局限性是建立TCP连接的时间开销会影响解析效率, T-DNS采用TCP和TLS协议, 与传统的DNS不兼容, 很难大范围部署.
多个DNS服务器协同工作, 可以在单个服务器解析失败时请求其他服务器, 提高系统的健壮性和可用性.多个DNS服务器的查询结果进行协商, 也会提高域名解析的真实性.
多个DNS服务器协同工作, 来完成域名解析过程, 是提高系统健壮性和可靠性的一种途径.CoDNS[44]系统采用局部和邻近感知的设计思想来分发DNS请求, 并实现低延迟、低开销的名称解析.当本地DNS服务器失效(丢包、过载或配置错误)时, CoDNS自动地将请求重定向到健康的协同服务器, 有效地减少了延迟, 提高了查询服务的可靠性.虽然协同DNS提高了可靠性和性能, 但是系统的安全性也会降低, 单点失效和故障会很容易传播到整个系统.为了解决这个问题, ConfiDNS系统[45]利用多站点协定(multi-site agreement)和每个站点的查询历史, 来解决合作查询过程的缺陷.
将多个DNS服务器软件查询结果进行对比, 以降低DNS软件缺陷或漏洞对查询结果准确性的影响. DR-DNS系统[46]可以同时运行多个不同的DNS服务器软件副本.用户首先将DNS请求发送给DR-DNS, DR-DNS将请求分发给不同的DNS软件副本, 各种DNS服务器软件将查询结果返回给DR-DNS.DR-DNS使用投票机制, 选择出现次数最多的记录, 返回给客户端.这种设计的好处是在某种DNS软件漏洞攻击和软件缺陷引起的解析错误下, 仍然能够对客户端做出正确响应.但是, 由于存在投票机制处理开销和不同DNS服务器的响应速度问题, DR-DNS的解析效率较低.
当前DNS协议并未对传输的信息进行加密和签名, 域名查询结果的真实性和隐私性得不到保障, 存在查询结果被篡改和隐私泄露的风险[47].在现有DNS系统的基础上, 可通过改变DNS系统的组织结构和传输协议来提高解析结果的真实性, 保护用户隐私.
为了阻止对顶级域名服务器的恶意攻击, OnionDNS[48]隐藏顶级域名(TLD), 并引入了镜像服务器和.o域作为OnionDNS的顶级域, 镜像服务器通过Tor网络与根服务器管理的.o域同步更新.镜像服务器位于客户端与根服务器之间, 客户端首先通过开放的网络或者Tor网络将请求发送到镜像服务器, 然后镜像服务器首先查找缓存的.o域记录, 如果有缓存记录, 则返回查询结果.如果缓存记录过期或者没有缓存记录, 镜像服务器也不会向隐藏的根服务器发起查询请求, 以防止攻击者将流量注入到Tor网络, 影响匿名化服务.镜像服务器通过周期性地从隐藏的根服务器获得对应的.o域的更新记录, 并将结果返回给客户端.由于镜像服务器采用DNSSEC协议, 在与隐藏的根服务器通信时, 真实性可以得到保证.通过这种方式, 以达到对匿名的根服务器提供安全保护的目的.为了防止恶意流量注入, 镜像服务器在缓存未命中时也不询问根服务器, 而是周期性地更新资源记录, 从而导致解析效率降低.
为了解决第三方DNS解析器造成的隐私泄露问题, 在传统的DNS解析器和DNS服务器中引入一个附加的服务器, 起到隐私保护的效果.作为一种传统DNS的替代方案, EncdnS[49]基于DNSCurve协议, 在标准的DNS消息中封装加密查询内容并在解析器(conventional resolver, 简称CR)与DNS服务器之间增设EncDNS服务器.CR向EncDNS服务器发送解析请求, EncDNS服务器获得解密后的域名信息, 向授权服务器发起查询, 然后将查询结果加密封装后, 通过CR返回给客户端.由于客户端发起的查询信息中, 查询内容被加密.CR不知道查询内容, CR将查询内容转发给EncDNS服务器后, EncDNS服务器解密得到查询内容, 但这条查询请求的IP地址是CR的地址信息, EncDNS并不知道具体的用户IP地址, 因此EncDNS和CR共同完成解析过程, 且不知道用户完整的请求内容, 达到了隐私保护的目的.EncDNS的局限性在于需要修改DNS协议来传输加密的查询信息, 不利于广泛部署.
随着互联网的发展, 技术在不断进步, 攻击手段也在不断变化, 仅仅依靠协议的增强和系统的改变不一定能够抵御所有的攻击.因此, 在现有系统的基础上, 进行有效的监控诊断, 保护DNS系统的正常运行, 也是一种重要的安全增强保障.对DNS系统进行诊断监控不需要改变现有DNS实现方式, 具有良好的渐进部署能力, 同时能够有效监测各种攻击.检测监控的核心思想是对DNS的查询流量进行分析和检测, 构造检测系统并运用如机器学习、信息熵等技术对检测结果进行学习和分类, 提高检测精度.本节根据检测流量的层级不同分为监测DNS用户端与递归服务器间流量以及检测DNS服务器间流量.
BotGAD[50, 51]通过分析僵尸主机和控制中心、DNS服务器以及其他主机间的流量, 以此检测僵尸网络. BotGAD将组活动映射为向量, 计算向量间的相似性, 判断组活动中的成员是否参与了恶意活动.映射方法是在每个时间间隔中, 生成一组活动, 引入一个二元关系表, 表的横行表示每个时间间隔, 表的纵列表示组成员的IP地址.如果某个时间间隔内, 某个组成员的IP参与了活动, 则此时间间隔和IP地址对应的数据为1, 否则为0, 将表的每个列信息提取出来, 这列向量就代表每个时间间隔内各IP地址参与组活动的情况, 然后计算向量间的平均相似度, 若超过了阈值, 则表明组活动参与了僵尸网络的组活动.
Seguio[52]利用用户端和ISP网络的本地DNS解析器的通信流量, 构建了一个机器-域名的二分图模型, 图中的每个节点代表主机和域, 边表示主机在观察阶段查询了该域名.每个域节点附有注释, 包括IP地址、域活动(如第1次被查询的时间).将与已知恶意节点有连接的节点被标记为恶意节点, 将属于域名白名单(如根据alexa.com)的域标记为良性域.对于其中无法标记的未知节点, 通过“谁查询了谁”的特征来分类, 如果一个恶意主机查询了一个未知域, 或一个未知主机查询了一个已知的恶意域, 则该节点有很大概率为恶意节点.
此外, 监测下层DNS流量还可以用来检测利用DNS流量控制的僵尸网络和DNS隧道.对DNS流量特征利用聚类算法分类, 处于僵尸网络中的节点, 在同一类中彼此相似, 但与其他类中的节点有着明显的区别, 通过这种方式检测僵尸网络的存在[53].利用DNS查询流量中的时间和空间分布关系与信息熵特征结合, 也是检测DNS流量控制的僵尸网络的一种手段[54, 55].检测DNS隧道目前主要采用DNS流量特征匹配、统计分析流量分析的检测技术[56].
根据从多个递归服务器上收集DNS的历史信息, Notos[57]系统利用网络特征、区域特征和黑名单证据特征, 来构建一个网络资源合法分配和操作的模型, 并运用这些模型为新的域名计算信誉分.如果信誉分过低, 则说明这个新的域名参与了恶意活动.
与Notos相比, EXPOSURE[58]不基于历史DNS流量, 而是检测实时的真实流量信息, 并定义了15种恶意域名行为特征, 并将这些特征分为基于时间、DNS应答、TTL值、域名字面信息4类, 这些特征被存储到特征分类模块中.数据采集模块收集DNS数据, 特征分类模块将这些数据按照预先设定的15个恶意特征进行分类; 域名采集模块和数据采集模块同时运行, 然后用域名采集模块采集的已知非法与合法域名对分类模块分类后的数据进行标记, 对于能够判断合法或非法的域名, 则作为训练模块的输入进行训练, 分类器模块则根据训练模块的检测模型来判断未标记的数据是合法还是非法.其中, 分类器模块使用J48决策树算法, 并应用信息熵的概念使用标记后的数据构造决策树.在本地递归服务器上进行DNS流量的检测方案的局限性在于需要在递归服务器上设置大量的数据采集器才能获得一个域的全局信息, 但是, 由于数据的隐私性和采集器部署原因, 很难在实际中得到应用.
通过监控高层DNS流量来获得DNS域的全局视图, 以此来检测恶意域名, 基于这种思路的研究成果有Kopis[59].Kopis与Notos、EXPOSURE的明显区别是监控的层级不同, Notos和EXPOSURE监控的是递归服务器, 而Kopis监控的是顶级名字服务器和授权名字服务器, 并通过划分不同的时序监控DNS数据.Kopis有两种操作模式:训练模式和操作模式.训练模式中, 训练模块将已知的合法与非法域名集合KB在m天内的DNS数据作为输入, 生成特征向量集合Vtrain, 每个KB中的域名对应Vtrain中的一个标签合法或非法, 然后使用监督学习技术[60]构造一个DNS合法与非法查询特征的统计分类模型S, 这些查询数据来自于DNS的上层流量.在操作模式中, 则应用分类模型S在某时序内为未知域名设定可信分数, 为了给出最终的分数, 模型S将会计算m个连续时序内的平均可信分数, 若低于预先设定的阈值θ, 则判断该域名非法.Kopis的优点是可以独立配置, 不需要从其他网络共享数据, 从而不必考虑不同组织和区域信息共享的安全和隐私问题.Kopis的局限性在于对于生存时间较短的域名, 如用DGA算法生成的域名, 检测效率很低.
为了检测ISP主干网中威胁用户安全的僵尸网络、钓鱼网站以及垃圾邮件等恶意活动, DAOS[61]实时检测流经主干网边界的DNS流量, 并从域名依赖性和使用位置两个方面来刻画DNS活动特征.其中, 依赖性从用户角度观察域名的外在使用情况, 而位置则关注区域文件中记录的域名内部资源配置, 并分别使用有监督的机器学习算法进行检测, 然后通过加权平均融合两方面的检测结果, 及时、准确地识别恶意域名.
DNS根服务器作为DNS系统的核心, 负责DNS主目录的维护和管理, 这种方式存在单点故障、易受攻击等缺陷.为了解决DNS中心化问题, 有学者提出设计去中心化的DNS系统.DNS系统去中心后, 每个服务器节点都是平等的, 单点故障和DoS攻击造成的影响将会降低.DNS的解析过程不再受限于根服务器, 不会因为管理等因素对域名进行封锁, 也解决了根服务器部署数量有限的问题.
随着P2P网络结构的出现, 利用P2P网络的容错性和负载均衡等特点, 有学者提出了基于P2P网络的域名解析服务.采用P2P结构的域名系统, 节点间相互平等, 不会发生传统DNS服务器单点失败的中心化问题.
建立全分布式DNS的一种方案是用分布式哈希表[62]技术构造一个去中心化的网络, 利用分布式哈希表容错和负载均衡的特性实现对现有DNS系统的改进, 如基于Chord[63]的DDNS[64]、基于Kademlia[65]的P- DONAS[66].DDNS在传统的DNS服务器上对资源记录进行查找, DNS记录的检索和存储通过分布式哈希表来完成.DDNS的特点是继承了DHash的容错和负载均衡等特性.在负载均衡方面, 使用一致性哈希来给每个阶段平均分配秘钥, 在每个节点被检索的同时, 缓存查询路径, 这种查询方法的时间复杂度为O(logN).在鲁棒性方面, 随着服务器的加入和退出, 分布式哈希表自动转移数据, 所以这些数据总会存储在固定数量的服务器上.由于这些服务器以伪随机的方式进行选取, 只有所有的服务器同时瘫痪后, 数据才会发生丢失.P-DONAS将每个域名供应商(ISP)的站点作为接入节点AN(access node).这些AN负责与客户端交互, 并且也负责存储资源记录.经常被用户访问的AN被称为触发节点(triggering node), 当收到用户请求时, 触发节点首先查找自己的缓存记录, 如果没有找到就在P2P网络上进行查找, 如果仍没有找到, P-DONAS就会查询传统的DNS服务, 如果查询到结果, 则将结果返回给AN, AN将结果返回给客户端, 并在缓冲区进行缓存.如果在传统DNS服务器上仍未找到结果, 则返回记录不存在或超时结束查询.当P-DONAS系统内没有缓存记录时, 就查找传统DNS服务器, 因此, P- DONAS与传统的DNS服务器也是兼容的.
为了提高基于分布式哈希表域名系统的检索效率, 基于Beehive[67]主动缓存机制可以实现平均查找时间复杂度为O(1), 并支持快速更新.CoDoNS[68]系统采用这种设计思想, 并可与传统的DNS系统兼容, 实现平滑过渡. CoDoNS由全球的分布式节点组成, 这些节点自组织形成一个P2P网络, 通过家点(home node)来缓存域名记录, 如果家节点失效, 则其相邻节点就会成为家节点.CoDoNS采用与传统DNS一样的协议和传输形式, 客户端解析器不需要修改.CoDoNS将命名空间的管理从传统DNS中分离, 域名拥有者只需从域名提供商那里购买名字证书, 域名供应商就可以将他们加入到CoDoNS, 域名拥有者也不需要为域名提供专用的服务器.CoDoNS的查询解析过程很简单, 客户端向CoDoNS发送DNS查询请求, CoDoNS在家节点获得记录或在中间节点获得缓存记录, 向客户端发送应答信息.除此之外, 家节点会与传统的DNS服务器进行交互, 保持存储的记录是最新的, 并更新缓存信息.
基于P2P的DNS系统易受网络环境影响, 当网络波动时查询效率会降低.为了解决传统DNS的结构问题和基于P2P网络的效率问题, HDNS[69]将P2P与传统DNS系统结合, 提出一种混合结构DNS系统的方案.该系统分为两个部分:共有区(public zone), 节点用P2P网络组织; 内部区(internal zone), 节点用传统DNS的树形结构组织.所有的共有区中的节点被分配一个唯一标识符, 内部区树形结构中的根节点也分配一个唯一标识符, 并将根节点标识符与共有区的标识符进行映射.以这种方式, 每个内部区和共有区进行关联.鉴于效率和安全性能, 在公有区存储顶级域名和二级域名, 其余部分存储在内部区.查询时首先在共有区查询顶级域名和二级域名的标识符, 通过映射得到内部区的根节点的标识, 然后在该根节点下查找其余部分的记录, 最终将查询结果返回. HDNS由于采用混合结构, 安全性比传统DNS要高, 且查询速率比完全基于P2P网络的域名系统要快.虽然基于P2P网络的域名系统具有鲁棒性和负载均衡等优点, 但是基于P2P网络的域名系统同样存在如下的局限性.
● 最坏情况下的查询延迟则不能接受:P2P网络由于底层实现的不同有不同的处理延迟, 但是最坏情况下的查询延迟则不能接受, 如一条查询请求可能会在多个高延迟的网络上进行多次传播才被处理, 解析效率明显降低.
● 节点信息更新导致状态不一致:P2P网络允许任何节点修改数据.当一个节点修改完数据没有进行广播时就断开连接, 将导致网络节点状态不一致, 有些节点存储的还是过期的域名信息.
● 数据伪造:P2P网络没有数据写入速率限制和接入控制机制, 攻击者可以向整个P2P网络泛洪大量的垃圾数据, 也可以伪造一些虚假的域名信息传播到整个网络.
区块链是分布式数据存储、点对点传输、共识机制、加密算法等技术的新型应用模式.利用区块链去中心化、不可篡改、可追溯、高可信和多方维护的特点[70], 为设计去中心化DNS提供了新思路.
Namecoin[71]是基于Bitcoin[72]开发的DNS系统, 在Bitcoin系统的基础上, 将区块链存储的交易信息替换为名称-数值映射数据.因此, Namecoin和Bitcoin有大多数共有的功能和机制, 但Namecoin是一个更加通用的名称——数值对解析系统, 而不是当前DNS系的替代.Namecoin通过使用不同的前缀来匹配其他类型的名称——数值对.如“d/”前缀被用在域名, “id/”前缀被用在注册身份.Namecoin使用虚拟.bit顶级域名, 但是这个域名没有被官方注册到当前的DNS系统中, Namecoin和DNS系统是隔离的, 如果不安装附加的解析软件, 则DNS系统不能解析.bit中的域名.
Namecoin底层由Bitcoin系统实现, 只是将存储信息由交易数据替换为名称-数值映射信息, 在扩展上存在局限性.为了解决Namecoin的扩展性问题, Blockstack[73]提出了将域名数据和控制分层的方案, 域名记录存储在外部数据库中, 而底层控制由区块链实现.Blockstack在区块链中仅仅保存少量的元数据(即数据哈希和状态转变), 并使用外部存储来存储实际大块数据.控制平面定义了注册协议、可读名字信息、创建名字哈希绑定和秘钥绑定.数据平面负责数据的存储和可用性保证.Blockstack由4层组成, 控制平面中包含区块链层、虚拟链层, 数据平面中包含路由层和数据存储层.第1层的区块链层, 负责存储区块链操作序列, 并提供操作写入顺序的共识.第2层是虚拟化层, 定义了新的操作, 但并不需要更改底层的区块链层, 只有Blockstack节点知道这些操作, 而底层的区块链节点并不知道.此外, Blockstack操作的接受和拒绝规则也定义在虚拟化层.第3层是路由层, Blockstack从实际的存储数据中分离出路由请求, 这避免了系统从一开始就采用任何特定的存储服务, 取而代之的是允许多个存储提供商共存, 包括商业云存储和P2P系统.如传统DNS使用区域文件(zone file)一样, Blockstack也使用区域文件来存储路由信息.第4层的存储层在最顶层, 它存储名称-数值对的实际数据.所有的数据被各自所有者的秘钥签名.用户不需要信任存储层, 因为它们可以验证控制平面中数据值的完整性.存储层有两种存储方式:可变存储和不可变存储, 这两种方式的区别在于数据的完整性验证方面, Blockstack支持这两种方式同时运行.此外, 仍有多种基于区块链技术的比特币衍生系统, 这些系统同样提供名字解析服务, 如基于ethereum的ens[74]、peername[75]、Emercoin的EMCDNS[76].基于区块链的域名系统也存在如下局限性.
● 与传统的DNS系统不兼容, 客户端浏览器必须安装插件才能访问域名系统, 因此基于区块链的域名系统很难大范围部署.
● Namecoin和Blockstack的底层实现都是Bitcoin.由于Bitcoin采用“one-CPU-one-vote”机制.如果某组织控制了整个系统51%的算力, 即51%攻击, 将会对系统造成严重的安全隐患.虽然51%攻击是理论上的存在, 但是如果拥有25%的算力就可以威胁系统安全[77].
● 由于区块链存储所有历史信息, 整个系统会变得越来越庞大, 移动设备或个人电脑很难有足够的硬盘空间存下所有的记录信息.虽然有学者提出SNV(simple name verification)协议[78], 但是需要设置提供全部记录的服务器, 服务器与客户端之间的通信安全又是一个需要解决的问题.
DNS系统的中心化解析蕴含着权利滥用的风险, 即一个顶级域可能被删除, 导致整个顶级域名下的子域名无法解析.为了解决DNS根服务器中心化问题, 应从结构和解析机制两方面进行改进.
在根服务器结构方面, 主要采用以下技术将根服务器去中心化[79]:(1)递归根:在递归服务器上直接进行根区解析; (2)伪装根:将到根区查询引导到镜像根服务解析; (3)开放根:建立一组独立运作的根服务器, 使用IANA的根区数据作为解析数据源; (4)全球根:通过增加根服务器数量, 采用任播技术, 将13个根服务器扩展到更大规模.这4种方案中根区数据依然来自IANA, 权利滥用分析仍然存在.
在解析机制方面, 采用域名对等扩散[80]的方式, 即让各个顶级域名所有者向其他国家顶级域名掌握者报告顶级服务器的地址.域名对等扩散体系下的自主根和国际根服务器处于混合工作的状态, 自主根将目前根服务器的中心化问题转移到了顶级域名服务器, 但是, 如果.com一类的顶级域名服务器拒绝将权威信息转交给自主根, 那么自主根将会受到很大限制.
将根服务器权利弱化为多个子节点, DDNS系统[81]采用这种方式限制根服务器权利.DDNS基于Paxos[82]分布式一致性算法, 分级分区域管理域名.根区的事务请求要得到过半根节点的投票才能通过, 从而不依赖主根服务器.这种方案的本质是将根服务器的权限下放为各个子根, 通过投票机制决定事务请求, 但是这种设计的局限性是子根服务器会相互结盟, 投票选举的结果受结盟的控制, 从而影响正常的事务请求.
DNS的安全形势严峻, 为了应对各种DNS安全威胁, 本节从协议增强、系统增强、检测监控、去中心化的域名系统4个方面对当前DNS安全方案进行了总结.为了更加直观地分析并对比各种增强方案的优点和局限性, 进行了比较分析.表 4围绕客户端兼容性、协议向后兼容性、隐私性、抗DoS攻击、抵御缓存投毒攻击、延迟方面进行了归纳总结.
针对DNS的各种安全问题, 虽然涌现了大量的解决办法, 但是近年来的各种攻击事件表明, DNS安全问题仍然十分严峻.通过分析发现, 现有的研究成果仍存在不足, 未来的研究工作可以更多地关注以下几个方面.
DNS系统之所以受到各种攻击, 与DNS树形结构、根服务器管理整个系统有重要关系.这种体系架构存在单点失效问题, 而历史上有多次攻击根服务器的案例, 致使整个DNS服务瘫痪.因此, 设计一种去中心化的DNS系统是一项具有重要意义的研究课题[74–79, 82, 83].目前, 针对去中心化DNS设计主要包含以下两个方向.
(1) 基于区块链技术.区块链技术的出现为去中心化设计提供技术和框架, 利用区块链技术设计去中心化DNS系统也是一个新的研究思路.目前, 该方式面临的主要挑战包括:
● 高效的P2P网络设计, P2P网络面临的问题包括容易受到网络波动的影响, 在网络波动剧烈的环境下, 查询效率将会大大降低; 数据伪造和缺乏接入控制使一些虚假信息传播到P2P网络[84].设计一种高效、安全的P2P网络是一个基于区块链去中心化DNS设计的重要课题.
● 高效的共识算法设计.目前主要的共识算法包括基于工作量证明、权益证明的方式, 但是这些共识算法共识效率低, 共识过程中会出现分叉, 并不适合DNS数据的实时更新和维护, 共识算法的设计需要结合DNS的应用场景设计, 共识效率高、共识过程保证中保证强一致性, 保证每个节点存储数据一致.
(2) 基于根服务器联盟的方式.这种方案的主要研究思路是不同国家或不同的顶级服务器通过联盟的方式, 降低根服务器中心化控制.这种方式面临的挑战包括国家根联盟体系结构设计、根联盟系统的控制、根联盟与主根服务器的同步问题.
虽然开放式服务器提供了各种便利, 如可以应答外部资源的DNS请求, 但是这些开放系统给网络的安全性和稳定性带来了极大的隐患.一些开放的服务器容易被攻击者控制, 实施放大攻击、投毒攻击等恶意行为.据调查发现, 在3 200万个开放式解析器中有2 800万存在严重的安全隐患.开放式会给攻击者进行DoS/DDoS、缓冲投毒、DNS ID劫持等攻击带来便利.现有的研究中很少有对这些开放式系统进行规范和研究, 如何识别和监控这些恶意的开放式服务器, 也是一个重要的研究课题.目前面临的主要挑战包括:
(1) 现有的大多数检测系统检测对象单一, 在实际应用中不能为检测某种恶意行为就配置一种检测系统, 因此有必要构建一种综合的检测系统, 能够有效地监测各种安全威胁.
(2) 当前无论是基于机器学习、信息熵, 还是统计分析等理论方法, 都难以抵御特殊类型的攻击, 如利用软件的零日漏洞发起的攻击.现有的检测系统检测效率还有待提高, 对于像DNS隧道、隐私泄露等检测并不能在信息泄露时得到及时发现, 因此新的检测系统也要满足及时性要求.
由于DNS系统的广泛应用, 有学者虽然提出了改进方案, 但与现有的DNS系统仍不够兼容, 也很难被大范围部署.DNSSEC虽然在1997年就已被提出, 但是目前仍未广泛部署, 截至2016年12月, 虽然DNSSEC在顶级域的部署率达到了89%, 但在二级域的部署率仅为3%[85].有很多新型的名字服务系统和架构均已提出, 但与当前DNS系统仍不够兼容, 因此, 这些研究成果很难被网络运营商和大型公司所采用.因此在设计防护方案的部署方式时, 应考虑防护方案要避免修改现有DNS协议.
互联网基础设施正迅速向私有/公共云混合模型转变.云服务正被广泛使用, 有93%的组织使用软件、基础设施或平台作为服务对象.虽然云服务带来了很大的便利, 但是仍有42%的组织受到了直接来自DNS的云应用宕机攻击, 这种攻击对象包括共有云和私有云.在云环境下, DNS安全面临以下问题.
(1) 云环境下的DNS安全检测.目前DNS检测主要针对ISP下DNS服务器之间的流量, 对于云环境中的DNS服务器的检测研究成果较少, 但是近年来, 云环境下的DNS安全十分严峻, 因此, 如何设计和检测云服务下DNS安全问题是一个可探索的方向.
(2) 云环境下基于DNS的隐私泄露检测.云环境用户隐私数据泄露十分严重[86], 如利用DNS隧道的方式进行隐私数据的传输和窃取.如何检测云环境下DNS数据隐私泄露问题也非常值得关注.
DNS作为互联网重要的基础设施, 从早期的DNS协议安全增强, 到现在的体系结构改进, 其安全防护问题一直是学术界和工业界所关心的问题.本文对DNS安全防护技术进行了全面的分析和总结, 同时对未来可能的研究热点进行了介绍, 为进一步研究提供参考.
致谢 感谢本文的匿名评阅专家对文章内容、分类方法的完善提出的许多建设性意见和建议, 同时对《软件学报》编辑老师的工作一并表示感谢
原文链接：http://www.jos.org.cn/html/2020/7/6046.htm
原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/22918
