DNS[, ]是互联网最重要、最基本的服务之一, 提供了方便记忆的域名与复杂的IP地址的相互映射. 万维网发展得如此迅速, 离不开DNS系统的广泛应用. 然而, 随着互联网技术的不断发展, DNS因其协议设计的脆弱性, 成为违法分子发动网络攻击的跳板, 使互联网在可用性、安全性及完整性等方面受到严重威胁. 如何提供DNS防护成为ISP (Internet service provider)及监管机构的重要关切.
根据EfficientIP和IDC共同研究发布的“IDC 2020 Global DNS Threat Report”显示, 2019年有79%的组织受到DNS攻击[]. DNS不仅仅是黑客的攻击的目标, 同时也是其实施攻击的重要手段. 最常见的DNS攻击类型包括[]:
(1) DNS hijacking, 域名劫持. 此类攻击手段有多种, 如攻击者通过攻击域名注册系统, 获得修改域名对应记录的权限. 一旦域名被劫持, 攻击者就可以通过篡改记录, 将用户引导至病毒网址、钓鱼网站等, 从而获得用户的敏感数据. 2010年百度境外的DNS服务器被攻击, 攻击者修改了解析记录, 导致长达11小时的服务中断[, ].
(2) DNS flood attack, 泛洪攻击. 这是最基本的DNS攻击类型之一, 在这种分布式拒绝服务(ddos)中, 攻击者将攻击DNS服务器. 其主要目的为造成服务器过载, 使其无法继续为正常的DNS请求提供服务[, ].
(3) Distributed reflection denial of service, 分布反射式拒绝服务(DRDos). DDoS中的一种, 此类攻击最终目的就是使用大量数据包或者大量占用带宽的请求使设备或者网络过载, 实现拒绝服务的目的. DRDos相较于DDoS的攻击更为致命, 该类攻击将请求发送至正常的DNS服务器, 但是源地址为被攻击者的, 如此, 被攻击者将收到大量的无效响应报文, 从而资源被耗尽[, 10].
(4) Cache poisoning, 缓存投毒攻击, 最常见的DNS攻击之一, 一般利用系统漏洞, 攻击者尝试向DNS服务器的缓存中注入恶意数据, 以达到其将用户重定向到另一个远程服务器的目的[11, 12].
(5) DNS tunneling, DNS隧道攻击, 这是一种网络攻击, 通过在DNS响应和请求中包含恶意的应用数据, 当与DNS服务器建立链接以后, 攻击者向服务器传递恶意数据, 以获得控制权限[13, 14].
针对DNS的攻击, 不少相关文献进行了研究, 如王文通等提到的从协议增强、系统增强、检测监控和去中心化的域名系统4个方面来应对[15]. 郝帅等针对反射放大型ddos攻击, 同时对DNS、SNMP、SSDP、NTP、Memcache和CLDAP这6种协议存在的安全漏洞进行分析, 从受害者和服务器两个角度给出防范策略[16]. Cooney推荐使用CISA (cybersecurity and infrastructure security agency) 安全措施以缓解受到攻击的威胁[17]等.
2017年5月, WannaCry蠕虫通过MS17-010漏洞在全球范围内感染了大量设备, 该蠕虫感染计算机后会向设备中植入勒索病毒, 导致设备中大量文件被加密. 受害者设备被黑客锁定后, 需要支付的一定价值的比特币才可解锁[18]. 而这一病毒有个关于域名的隐藏开关, 通过RPZ技术对特定域名的访问进行干预, 即可遏制病毒的进一步大规模传播.
现今, 无法通过某一种技术手段解决所有攻击类型, 结合RPZ技术设计的防护系统在一定程度上可以防范和化解域名劫持、以及不法分子试图通过DNS系统, 将用户引至恶意站点. 除此之外, 系统还可以辅助ISP控制未备案等不合法的站点被访问.
目前, 多数ISP或者银行、电力等大型企业组织并没有部署通过干预域名解析来提升DNS安全的系统, 少数可能部署了域名黑名单解析功能. 但是基本上都没有部署自动化的解析干预系统, 结合运营商或者大型组织的实际情况, 整个安全防护系统需要满足以下必要功能.
(1) DNS递归解析功能, 最核心的功能, 需要满足ISP用户或者大型组织内部递归解析请求, 该功能一般需要从13个DNS根服务器开始, 递归访问至授权服务器, 获取DNS响应结果, 并进行短时间的缓存.
(2) DNS缓存功能, 业内常见做法是将缓存与递归分开, 该模块直接接受用户请求, 优先查找本模块内部缓存, 以响应用户. 无缓存的情况下, 会将请求转发给DNS递归服务器. 一般情况下, 多台缓存设备会转发至一台递归设备.
(3) DNS安全防护功能, 当系统检测到有恶意的域名请求时, 或者DNS响应报文中含有恶意的IP地址时. 需要能够根据用户的设定返回特定结果, 如返回NXDOMAIN, 或者返回特定的IP地址, 将用户重定向至警告页面.
(4) 综合管理平台, 常规功能包含设备性能监控、告警监控等. 核心功能要求协调所有设备之间的信息交互, 进行统一管理, 如数据收集、控制指令下发、控制指令反馈等.
与传统的提供DNS解析功能的系统相比, 构建RPZ安全防护系统, 极大提高整个系统拦截恶意域名或者IP地址的效率.
RPZ由Paul Vixie主导的ISC (internet systems consortium)机构于2010年提出, 目前是IETF (Internet engineering task force)的互联网草案[19]. 是一种针对DNS的网络安全解决方案, 可以防止互联网用户和系统访问到已知的恶意域名或者IP, 可以有效地预防威胁发生, 通过阻止访问受感染或者恶意的站点, 进而阻断进一步的安全威胁. 能够主动检测到已被感染的用户, 并且防止病毒进一步扩散. 图1为用户通过常用的通讯软件收到包含恶意信息的链接场景下, RPZ参与的工作过程.
(1) 不法分子通过电子邮件或即时通讯软件, 将包含恶意软件或者域名的链接发送给用户.
(2) 用户点击收到的链接, 终端设备首先要做的就是进行DNS解析. 将DNS请求发送至DNS解析服务器.
(3) 具有RPZ功能的DNS解析服务器, 向其他系统同步RPZ规则, 判断当前请求解析的域名是否为恶意域名, 或者解析到的IP是否为恶意IP, 若是, 则会进行干预, 干预的结果则是由用户下发的规则决定的.
(4) 在RPZ的防护下, DNS请求无法获得正常结果, 或者获得由ISP提供的警告页面结果, 从而成功阻止了用户访问恶意站点.
图1中RPZ规则下发阶段的数据, 一般由ISP通过多种方式进行收集, 包括但不限于恶意域名检测系统、被举报的赌博网站、色情网站、钓鱼网站以及其他被监管机构禁止的站点.
整个系统涉及多种类型设备, 核心DNS解析功能需要满足负载均衡设计. 系统总体结构如图2所示, 系统最基本组成部分共包含6个子系统, 以及各子系统所需最小组成模块. 根据实际情况, 可添加其他辅助系统, 如防火墙、入侵检测系统等. 子系统之间数据传递、控制指令下发都是通过局域网完成, 只有缓存系统和递归系统需要接入互联网.
负责解析用户的DNS请求并完成响应, 当接受到请求后, 会首先查找本地系统是否已缓存过相应记录且TTL尚未过期, 对于无法利用已有缓存完成响应的情况下, 将请求转发至递归服务器.
一般只接受特定缓存服务器的请求, 不直接对终端用户开放, 可以具备一定的缓存能力, 但是缓存时间不宜过长. 正常情况下, 会从根服务器开始进行递归处理, 直至到达授权服务器, 获取到用户所需数据. RPZ模块就是工作在该系统中.
负责接收来自递归系统的DNS请求响应日志, 进行归档以便后续审计, 同时负责将日志发送至其他系统.
该系统接受到DNS日志后, 需要进行分析, 当前针对恶意域名的检测有不少相关论文, 也有部分公司有偿提供检测到的恶意域名或者设备的地址, 如DissectCyber提供的RPZone.us服务.
负责存储所有规则, 提供接口供其他系统动态更新规则, 更新后, 系统会通知递归系统获取最新的规则数据. 递归系统本身也会定期查询是否有规则数据变更.
负责所有系统的运行配置、监控、规则下发, 向其他外部系统提供接口等. 典型的应用就包括, 恶意站点检测系统一旦检测到恶意域名或者IP, 会向该系统提供的接口上报, 由管理系统向RPZ系统下发规则.
RPZ的规则可以在请求到来之前进行预置, 也可以通过前序的日志进行分析检测得出. 针对第一种预置的情况, 当请求到达时, 在递归系统就会被成功拦截. 第二种场景下, 前序请求会拿到恶意域名结果, 但是后续请求会被拦截.
图3为系统工作时, 某特定场景下信息交互的时序图示例. 实际工作时, 因系统分布式部署, 可能存在的网络数据丢失, 导致接口调用超时, 接口需要提供重试、异常处理的能力.
实验所使用的系统为Linux系统(CentOS Linux release 7.8.2003), 使用NSD 4.3.6作为RPZ系统的核心软件, 使用Unbound 1.13.1作为缓存系统和递归系统的核心软件. 所使用的网络拓扑图, 如图4.
递归服务器内网地址配置为172.171.1.16/24. RPZ服务器内网地址配置172.171.1.16/24. 硬件CPU为Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20 GHz. 内存为16 GB.
Unbound配置位于/etc/unbound/unbound.conf中, 部分核心内容如下:
01 server:
02 interface: 0.0.0.0@53
03 access-control: 0.0.0.0/0 allow
04 logfile: “/etc/unbound/unbound.log”
05 module-config: “respip validator iterator”
06 rpz:
07 name: rpz.test
08 master: 172.171.1.15
09 allow-notify: 172.171.1.15
10 zonefile: /etc/unbound/rpz.test.zone
第2行表示在所有地址上监听端口53. 第3行表示不对源地址访问控制. 第4行指示日志存储位置. 第5行中的配置了rpz所需要的respip模块. 第6行为rpz模块配置起始位置. 第7行表示rpz的zone名称为rpz.test. 第8行指示RPZ系统的地址. 第9行表示允许RPZ系统主动通知规则变更. 第10行表示同步到的规则文件会存储在rpz.test.zone文件中.
NSD配置位于/etc/nsd/nsd.conf中, 部分核心内容如下:
01 server:
02 logfile: “/var/log/nsd.log”
03 pidfile: “/var/run/nsd.pid”
04 xfrdfile: “/var/db/nsd/xfrd.state”
05 zone:
06 name: rpz.test
07 zonefile: /etc/nsd/rpz.test.zone
08 notify: 172.171.1.16 NOKEY
09 provide-xfr: 172.171.1.16 NOKEY
第2行表示日志文件位置, 第3行表示进程号文件存放位置. 第4行指示规则同步过程中, 状态文件的位置, 该文件由软件自动生成和维护. 第6行表示RPZ的zone名称为rpz.test, 该名称需要与递归系统中一致. 第7行指示规则文件存放位置. 第8行表示若规则变更时, 会通知notify配置的IP, 可配置多行. 第9行用于进行同步控制, 只有允许的递归服务器才能够进行RPZ规则同步.
假设example.com域名的子域名都为恶意域名. 针对该域名进行多种常见场景的测试验证.
/etc/nsd/rpz.test.zone规则文件的配置如下, 其中第11–13行通过分号被注释, 修改此文件后, 第4行的序列号也需要修改, 否则不会同步至递归系统.
01 $ORIGIN rpz.test.
02 $TTL 3600
03 @ IN SOA ns admin (
04 2021042102 ; serial
05 3600 ; refresh (1 hours)
06 600 ; retry (10 minutes)
07 604800 ; expire (1 week)
08 600 ; minimum (1 day)
09 )
10 *.example.com CNAME .
11 ; *.example.com CNAME *.
12 ; *.example.com A 127.0.0.1
13 ; 32.34.216.184.93.rpz-ip A 127.0.0.2
启用第6.2.1节配置文件中的第10行, 注释11–13行. 使用dig www.example.com @172.171.1.16命令测试结果如图5.
根据dig显示的结果表明验证通过, 终端得到的响应为NXDOMAIN.
启用第6.2.1节配置文件中的第11行, 注释10和12–13行. 使用dig命令测试结果如图6.
根据dig显示的结果表明验证通过, 终端得到的响应为NODATA.
启用第6.2.1节配置文件中的第12行, 注释10–11和13行. 使用dig命令测试结果如图7.
根据dig显示的结果表明验证通过, 终端得到的响应为127.0.0.1.
启用第6.2.1节配置文件中的第13行, 注释10–12行. 配置文件的中32.34.216.184.93.rpz-ip, 其中, 第1个数字32表示掩码, 34.216.184.93是www.example.com真实解析IP地址反序, 其真实地址为93.184.216.34.rpz-ip为固定字段. 第14行的含义就是当递归响应结果中的地址为93.184.216.34/32时, 就被替换成127.0.0.2. 使用dig命令测试结果如图8.
实验结果符合预期, 另外针对IP的NXDOMAIN和NODATA的实验与第6.2.2节和第6.2.3节相似.
本文构建的DNS的RPZ安全防护系统, 采用NSD和Unbound等相关核心软件, 进行配置与实践. 验证结果表明, 系统对于防护用户访问到恶意域名或IP效果较为明显. 具有良好的实际应用意义与技术参考价值.
系统所采用的检测子系统是基于较常用的关键字识别. 一个良好的规则库, 对于整个防护系统具有重要意义. 现有不少组织已经开始有偿提供规则库, 如何快速、有效地通过各种手段构建规则库将是下一步的研究重点.
原文链接：http://www.c-s-a.org.cn/html/2022/3/8367.html
原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/21774
