用DNS进行网络度量和安全分析
背景
今天为大家推荐由360网络安全研究院-安全分析资深专家分享的议题《用DNS进行网络度量和安全分析》，本课题简要阐述了DNS协议的历史和发展现状，在此基础上，结合360网络安全研究院的多年分析DNS数据的经验，介绍了我们利用DNS数据做过的一些关于大网方面的度量，并结合公司多维度的海量数据做的安全分析方面的一些工作。
DNS概述
DNS协议对互联网的从业者来说并不陌生，它是互联网的最古老也是最基础和最核心的协议之一。简单来说的话，它最主要的功能是完成域名和IP地址的映射，即互联网的电话簿。
但DNS协议能够完成的功能远远不止于完成域名和IP地址的映射，很多现代互联网的基础业务都要基于DNS协议才能够完成，可以认为跟域名相关的业务几乎都和DNS协议有关。根据dns-camel项目[1]统计，截止到2019年6月，共有150篇标准，建议，最佳实践方面的RFC，共有2637页，非常庞杂的内容。所以DNS协议实际的复杂度超出了大多数人对其的理解。
下图显示了DNS协议相关的RFC页数从1984年到2019年的变化量，可以看到从1996年开始，几乎以每四年500页的速度在稳定增加。
也正因为如此基础和复杂，几乎所有的互联网业务都会在DNS数据中留下痕迹。使用了DNS服务的恶意行为也不例外，对DNS数据进行安全分析，可以涵盖绝大多数的恶意行为。
本文从使用DNS数据角度来介绍一下可以做的事情。主要是两大类，分别为网络（业务的）度量和安全分析。
网络度量
DNS劫持情况
同大多数早期的互联网协议类似，DNS协议在设计之初是以明文形式传输，支持TCP和UDP两种传输协议，并且在实际使用过程中传输协议主要以UDP为主。
所以到现在，大多数的DNS请求和应答仍然是基于UDP协议的明文形式进行传输，因此DNS劫持是DNS在实际环境中非常普遍的问题，为了对这个问题有个精确的度量。清华大学网络科学与网络空间研究院和360公司合作，对全球范围内的DNS劫持情况做了一个定量的度量。测量方案通过请求随机化子域名（避免缓存服务器对请求域名的缓存）在不同的公共DNS服务器，从不同的请求类型，顶级域以及协议等维度的方式来探测DNS劫持的情况。
测量结果表明：
1.基于UDP的DNS数据包更容易遭到劫持。
2.A类型（IPv4地址）的DNS请求比其他类型稍高。
3.全球的8.5%的自治域存在DNS劫持，其中包括像中国移动这种较大的ISP。
4.推测DNS劫持的主要目的是为了减少财务结算和提高DNS相应的性能。
具体的测量详细过程和完整结果参见这里[2]。
小贴士：DNS加密传输的进展
为了解决DNS明文传输所引起的问题，相应的解决方案最近几年在业界已经积极的推动起来了，客户端方面来看，有更好安全意识的浏览器厂商（Firefox，Chrome，360浏览器等）和操作系统厂商（包括windows和macOS）逐步开始支持DoT/DoH；在服务器方面包括360安全DNS[3]在内的公共DNS服务提供商都开始DoT/DoH服务，有条件的用户可以尝试一下，应该可以极大的缓解由于DNS劫持所引起的安全风险。
用DNS数据来度量NTP pool的使用情况
NTP pool成立于2003年，是由志愿者提供的联网计算机组成的动态虚拟群集，可向全球数百万个系统提供高度准确的时间同步服务。它是大多数主要Linux发行版和许多联网设备的默认时间服务器。
由于它的特殊工作方式，在PDNS(参见下面的小贴士)中，它的域名和IP的映射关系在一定程度上是随机的，特别像之前非常流行的僵尸网络躲避攻击检测和防封堵使用的Fastflux[4]。
为了摸清楚NTP pool的实际工作情况，我们通过DNS数据对NTP pool做了一次度量。
主要有如下发现：
1.服务器方面
NTP pool服务器在4000左右，其中IPv6的占比在25%，IPv4占75%。
NTP pool服务器遍布全球97个国家，不过主要集中在美、德、法、英、荷、加等发达国家。
国内的服务器只占总服务器个数的2%，并且主要集中在香港，台湾，广东和北京等这些经济较为发达的地区。
2.子域名方面：
NTP pool的子域名主要有三种划分方式：按照大洲，按照国家/地区，按照供应商。
NTP pool的域名DNS请求中，大约3%的域名请求是无效的，主要是拼写错误或者系统的bug导致的。
按照供应商访问的NTP pool服务会在一定程度上暴露用户发起请求的客户端的类型。下图是我们对不同供应商的DNS请求次数的统计：
3.使用服务器效率方面：
a.NTP pool在轮询服务器方面理论上来说是均衡的
b.在实际操作中，收到地理位置以及不同服务器服务能力，服务策略的不同导致不同的IP提供服务的机会并不均等。
c.TOP4000的RRset(约占总数的1%)即可占总记录数的41.21%，不同RRset的CDF图如下：
完整的文章请参阅：https://blog.netlab.360.com/look-at-ntp-pool-using-dns-data/
小贴士：被动DNS系统
所谓被动DNS也即PassiveDNS(PDNS) 数据库是将历史DNS记录解析/融合/存储的系统。与主动扫描（探测）不同，可以利用大量的被动DNS数据进行大规模的基于DNS数据的度量。通过被动的收集DNS流量，构建域名和Rdata(域名的解析结果)之间的全量历史映射关系，实现域名和Rdata的互查，以及历史DNS记录的查询。
360的PDNS系统(https://passivedns.cn)是国内第一家公开的PDNS系统。系统建设于2014年，是国内目前规模最大和历史数据最久的PDNS系统。
其他的度量
利用PDNS可以完成很多其他的度量工作，比如：
1.不同CDN厂商规模的评估
2.黑灰色产业规模的评估
3.新通用顶级域名（new gTLD）使用情况/（在现实使用中的）冲突情况的评估
4.域名在注册，备案以及解析尤其是涉及到批量的域名处理时的相关情况的评估
5.国家（涉及域名方面）政策的执行情况的评估
6.……
总之在网络测量方面，只要涉及到域名，DNS数据几乎就是天然的基准数据，只要设计合理的测量方案，就能够得到准确的结果。
安全分析
面向DNS的安全分析，大体可分为两类：
·针对DNS协议和系统本身的安全问题的分析
DNS投毒
DNS劫持
伪随机前缀DoS攻击
NXNSAttack攻击
…
·使用DNS数据来分析相关的安全事件
DNS隧道
DNS反射放大
DGA
Fastflux
…
DNSMon——基于DNS数据的威胁检测和分析系统
在日常工作中，针对DNS协议和系统的攻击在DNS数据中有一定的体现，但并不是利用DNS数据威胁发现的主要目标。如前所述，只要互联网使用域名的业务就会在DNS数据中留下自身的痕迹，恶意程序也不例外。因此从威胁发现的角度来说，使用DNS数据检测，分析和阻断安全威胁是海量DNS数据发挥作用的主要场景。
为了能够更加及时高效的发现安全事件，360公司开发了DNSMon系统。该系统以DNS数据在统计维度上的异常为出发点筛选初始域名，综合web页面数据，证书数据，whois数据，沙箱以及蜜罐等多维度的数据，并结合高质量的IOC和word2vec，LSTM等深度学习算法，对发生异常的域名进行综合判断，标定其异常状态，给出较为确定性的标签。
对于标黑和高危域名可以录入威胁情报库供第三方使用。对于白和其他灰域名则录入标签库供第三方查询使用。
基本流程如下图：
系统的优势主要体现为如下三点：
·准实时的处理和关联海量的数据。目前在于能够在百万QPS的DNS请求的情况下，融合多维度的其他数据源进行处理，达到小时级别的输出。
·自动化程度高。每天能够自动产生千级别的黑域名和高危域名。
·无先验知识的情况下可以大规模的阻断黑，高危域名。例如：
永恒之蓝挖矿蠕虫及其系列变种
MSRAminer恶意挖矿程序及其系列变种
NuggetPhantom恶意程序及其系列变种
DGA.popad广告网络挖矿程序
Mylobot僵尸网络
Godlua后门
Burimi挖矿蠕虫
LSDMiner挖矿恶意程序
盗贼恶意SDK应用
恶意利用某大型互联网厂商的评论系统漏洞刷广告流量
Skidmap恶意程序
更多案例请参考：https://blog.netlab.360.com/tag/dnsmon/
安全分析的其他方面
在对PDNS数据进行深入分析之后，我们就会发现其实针对很多类型的攻击如果从DNS数据入口就会非常简单，能够达到事半功倍的效果。
1. 比如传统的采用DGA技术和fastflux技术的僵尸网络从DNS数据入手是非常容易的。
2. 再比如某些黑灰行业他们在不断的改进自己的攻击手法时，其所使用的基础设施却是不变的，以某一个或者几个IP/域名为入口通过DNS数据能够很快的将其他之前未发现的IOC关联出来。
3. 再比如一些恶意程序在运行时，在时序上有着非常稳定的顺序，这种非常强的关联关系也会在DNS中留下非常显著的特征。只要在时序上构建较好的模型，我们就能够对域名进行聚类和扩展分析，从而有效的提高分析效率。
4. …
总结
近年来DNS协议正向着更注重隐私性，安全性方面快速发展。而针对DNS数据的分析则在对度量DNS协议发展情况，对依托于DNS数据所做的安全分析方面，尤其是在威胁情报的生产方面发挥着越来越重要的作用。
毫无疑问，DNS协议对未来互联网的发展起着重要的作用，尽管我们还不知道它将走向何处，会给未来的网络带来哪些影响，现在是体验这个变化过程的最好时机。无论是对DNS数据做安全分析还是利用DNS做各种度量，DNS这个宝库都值得深入探索和挖掘。
参考资料
1. https://powerdns.org/dns-camel/
2. https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-liu_0.pdf
3. https://dns.360.cn/
4. https://en.wikipedia.org/wiki/Fast_flux#:~:text=Fast%20flux%20is%20a%20DNS,compromised%20hosts%20acting%20as%20proxies.
