一、背景

DNS协议提供了域名与IP地址转换的服务，是必不可少的网络通信协议之一，也是整个互联网运行的基础。然而，传统的流量检测设备很少对DNS协议传输数据的有效性、安全性进行深度分析和检查。思科在其安全研究报告中形象地称之为“DNS盲点”。恶意软件正是利用此机会，通过DNS协议构建隐蔽隧道，进而实现命令控制C&C、数据外发等攻击。EfficientIP发布的《全球DNS威胁报告2018》指出，2018年77%的组织至少经历过一次基于DNS的网络攻击，并且DNS隧道占据了绝大比例。DNS隐秘隧道技术是MITRE ATT&CK命令与控制矩阵(Command and Control）中的子技术，其ID为T1071.004。ATT&CK中记录有30多个目前已知的APT工具使用DNS隧道实施C&C攻击，比如：OilRig组织使用的Helminth和ISMAgent、OceanLotus使用的Denis等。

当前，针对DNS隧道的检测方法很多，如基于阈值、统计或专家规则的方法以及基于机器学习的方法等。实践证明，相比其他类方法，基于机器学习的DNS隧道检测方法在检测效果、防绕过、泛化能力等方面具有较大的优势。

本文将从DNS隧道基础知识、DNS隧道检测方法现状及DNS隧道检测实践三个方面介绍相关内容。

二、DNS隧道基础知识

2.1 DNS隧道简介

DNS隧道是一种隐蔽隧道，即通过将数据或命令封装到DNS协议进行数据、命令等传输的隧道，DNS隧道提供了宿主机与其C&C服务器之间低速但隐蔽的双向通信通道。

DNS隧道从用途上可以分为定时隐蔽隧道和存储隐蔽隧道两种。前者使用定时属性将相同结构的DNS请求发送到C&C，这类消息通常为心跳；而后者则使用DNS协议封装编码的信息，这类信息通常为传输的敏感数据。与定时隐蔽隧道相比，存储隐蔽隧道可以提供更高的带宽，因此存储隐蔽隧道使用更为广泛。无论哪种隧道类型都使用DNS请求的子域将数据传输到C&C，并使用这些请求的响应从C&C接收数据。因此，DNS隧道中传输的数据必须遵守DNS协议规范，请求的域名必须具有label，并且必须以字母或数字开头和结尾，每个label的长度不超过63个字符，整个域名的长度不超过255个字符。

2.2 DNS隧道原理

DNS隧道在通信方式上又分为直连和中继两种模式。直连是宿主机直接与指定的目标DNS Server(Authoritative NS Server)连接，通过将编码数据封装在DNS协议中进行通信。这种方式速度快，但是隐蔽性比较差，很容易被探测到，另外限制比较多，很多场景不允许自己指定DNS Server。而通过DNS迭代查询实现的中继隧道则更为隐蔽，但同时因为数据包到达目标DNS Server前需要经过多个节点，所以速度上比直连慢。

中继DNS隧道工作原理如图1[1]所示，具体如下：

Step1: 攻击者首先注册一个域名，如ex.fil，域名指向攻击者控制的服务器，并在该服务器上安装恶意隧道服务器端程序。

Step2: 攻击者利用恶意软件感染公司内网中的主机，之后受感染主机向DNS解析服务器发送请求，DNS解析服务器将请求中继到根域名服务器和顶级域服务器。

Step3: 各级DNS解析服务器最终将请求路由到被攻击者控制的安装了隧道程序的C&C服务器。

最终宿主机和C&C之间通过DNS解析服务器建立了连接，并使用该隧道泄露数据或实现其他恶意目的。由于宿主机和C&C之间没有直接连接，因此追踪攻击者更加困难。

图 1 DNS隧道原理

2.3 DNS隧道工具

目前有很多开源DNS隧道工具，比如：iodine、DNSCat2、dns2tcp等等，我们称之为通用DNS隧道工具。这些工具开源并且支持二次开发，例如基于Iodine开发的Android DNS隧道工具MagicTunnel，它们支持多种平台、语言以及记录类型。

很多APT组织使用的恶意软件也具有DNS隧道功能，我们称之为APT工具。相对于通用DNS隧道工具，很多APT工具支持特定的硬编码命令，其数据封装更精巧，支持的记录类型更广泛，检测也更加困难，比如很多APT工具支持A和AAAA记录类型。

表 2 具有DNS隧道功能的APT工具

2.4 典型DNS隧道样例

DNS隧道的使用非常广泛，除了一些通用的开源DNS隧道工具之外，很多APT工具也使用了DNS隧道技术。接下来将对部分通用DNS隧道工具和APT工具进行举例说明。

2.4.1 Iodine

Iodine是基于C语言实现的开源DNS隧道工具。Iodine在默认情况下使用NULL记录类型，同时可以支持PRIVATE、TXT、SRV、MX、CNAME和A（返回CNAME）类型。Iodine在外发数据时首先会使用GZIP对数据进行压缩然后再编码发送，其支持Base32、Base64和Base128编码。

2.4.2 Dns2tcp

Dns2tcp也是基于C语言实现的开源DNS隧道工具，并且已预装在Kali Linux和BlackArch Linux系统。在默认情况下，Dns2tcp使用TXT记录类型，但它也可以支持KEY记录类型。在通信时双向数据都使用Base64编码进行传输。

2.4.3 Dnscat2

Dnscat2是基于JAVA实现的开源DNS隧道工具。Dnscat2可以使用TXT、CNAME和MX记录类型，但是如果仅将数据从客户端发送到服务端时它还支持A和AAAA记录类型。在通信时双向数据均使用十六进制编码进行传输。

2.4.4 ISMAgent

ISMAgent是OilRig组织所使用的具有DNS隧道功能的恶意软件。通过Wireshark抓包展示ISMAgent发送初始信标并将数据发送到C&C服务器的过程。首先木马使用DNS请求向C&C发送包含会话ID的初始信标，C&C使用特定的IPv6地址作为响应指示隧道建立连接，然后木马继续发送包含数据编号、随机数和编码数据的DNS请求，C&C使用特定IPv6响应这些请求以指示木马继续发送数据直到所有数据都发送到C&C服务器，C&C使用包含请求数的IPv6响应以指示数据传输完毕。

2.4.5 Helminth

Helminth是OilRig组织在攻击活动中开发的具有DNS隧道功能的恶意软件。Helminth有两种版本，一种是可执行可移植的版本，另一种是Power Shell版本，这两种版本都通过DNS隧道与C&C进行通信。两个版本的DNS隧道运行方式相同，仅对生成的子域进行更改，使它们看起来不同以逃避检测。

Helminth PowerShell接收C&C指令的过程如下：首先，Helminth木马发出DNS请求启动与C&C服务器的会话，C&C用IPv4地址响应此信标，木马从该IPv4中获得唯一的系统标识符；然后Helminth发送带有系统标识的DNS请求，C&C用一个IPv4地址来响应该请求，Helminth将IPv4转换为字符作为下载脚本的文件名；最后，Helminth继续发出其他的DNS请求，并将响应中的IPv4视为命令写入脚本文件，C&C以特定IPv4响应以指示命令传输完毕。

Helminth PowerShell外发数据的过程如下：当收到指示IPv4后，Helminth执行脚本同时将执行结果写入到与脚本同名的文本文件中，最后该文件通过DNS请求发送到C&C，C&C以固定的IPv4响应。

2.4.6 Denis

Denis是Ocean Lotus组织最常用的特种木马，是一个全功能的后门，攻击者使用DNS隧道实现了一种更加隐秘的C&C通信方法。为了确保DNS流量不被过滤，攻击者将后门配置为与Google和OpenDNS 的DNS服务器通信，因为大多数组织和安全产品都不会过滤发送到到这两个主要DNS服务器的流量。

Denis首先向Google DNS服务器发送包含会话ID的初始信标，并由各级域名服务器路由到攻击者控制的C&C服务器以建立连接，然后C&C以数据字节数和硬编码指令响应该请求，Denis接收到响应后执行特定的命令并将命令执行结果通过Google DNS服务器发送到C&C。Denis总共支持16条硬编码指令，大多数指令涉及与被攻击计算机文件系统的交互，另外还具有获取有关打开窗口的信息、调用任意API和获取有关系统简要信息的功能。

三、DNS隧道检测现状

目前业界提出了各种DNS隧道检测方法，总体来说可以分为两类：一类为基于规则的检测方法，一类为基于机器学习的检测方法。

基于规则的方法是通过阈值来识别DNS隧道，比如监控终端请求域名的长度，如果域名长度超过设定阈值，则会发出警报。此外，寻找不常用的DNS记录类型（例如TXT、NULL记录）是另一种常用的检测方法[3]。基于阈值的检测方法不够灵活、泛化能力差，并可以通过修改域名长度、请求频率等特征轻易绕过检测。

基于机器学习的方法通过学习历史数据特征，可以准确地识别未知的DNS隐蔽隧道，同时兼具误报率低、不易被绕过等优点。基于机器学习的DNS隧道检测方法可以总结为两类：一类为负载分析，这类方法是受DGA检测研究的启示[4]，主要关注DNS负载的随机性、字符频率等特征；另一类为基于时间窗口的流量分析，这类方法关注DNS请求或响应随着时间变化的统计特征，包括时间窗内每个域名的主机名数量、各种记录类型（A、AAAA、TXT等）的频率、子域N-Gram均值和方差、请求和响应时间间隔的均值和方差等等。

文献[5]根据齐夫定律提出了NgViz方法，该方法使用多条正常DNS流量统计其负载的字符频率以及字符排名，在推理阶段计算输入的多条DNS请求与正常DNS流量的字符排名和字符频率的加权匹配度，通过既定的阈值来判别DNS隧道，但该方法检测效果不佳。文献[6]使用DNS请求和响应负载的字符熵和长度以及DNS数据包包长等特征构建随机森林模型，该实验表明使用DNS请求和响应特征比单独使用请求或响应的特征检测准确率更高，但是该方法对于未知隧道工具召回率较低，且只能检测使用TXT、NULL等记录类型的隧道工具，无法检测使用A、AAAA记录类型的新型隧道工具。文献[7]使用DNS请求的七个特征，包括FQDN中的字符总数、子域中字符数、大写字母和数字字符的数量、字符熵以及DNS请求域名的最大标签长度和平均标签长度特征构建孤立森林模型以检测DNS隧道。这种方法不涉及任何特定的DNS记录类型，但由于使用无监督的模型，该方法召回率较低。文献[8]使用DNS请求和响应的统计特征，例如：DNS请求和响应负载的平均长度、编码的有效载荷和唯一请求的数量等，该方案也使用孤立森林算法，但是该方法仅考虑A和AAAA两种记录类型，而且在实验中也仅考虑了Iodine和dns2tcp两个开源隧道工具。文献[9]指出，DNS隧道用于在宿主机和C&C交换数据时，通常将编码数据封装到DNS请求和响应的负载部分。作者提出了两种基于机器学习的方法：(i)逻辑回归模型和(ii) k-means聚类，这两种方法都是从编码的有效载荷中提取语法特征，例如：字符熵和字符（大写、小写、数字、破折号）数量，但是该方案也仅仅针对使用TXT记录的隧道工具dnscat2。文献[10]分析了几个开源DNS隧道工具的流量，提取了四种类型的特征：请求和响应时间间隔的均值和方差、请求数据包大小、域名熵和记录类型（例如A、TXT、MX等）比例等特征。作者使用了多个DNS隧道工具生成的数据训练分类模型，但测试数据仍然是由参与训练的隧道工具产生。

四、DNS隧道检测实践

现有的基于机器学习的DNS隧道检测方案使用多种DNS隧道工具生成的数据训练模型，以使模型可以识别更多的隧道工具，但是这种方案对未参与训练的隧道工具和未知隧道工具的检测效果不佳，也即模型泛化性能差；另外，在缺少多种隧道工具数据的现状下，一些方案为了提高模型的泛化能力使用统计分析的方法，但这种方案无法实现实时检测。基于对上述两个问题的考虑，本文提出了仅使用DNS请求特征的DNS隧道实时检测方案，

方案分为四个模块：第一个模块为数据处理模块，该模块主要是解析DNS流量数据并提取相关字段内容；第二个模块为特征提取模块，该模块基于数据处理模块的结果创建并提取DNS隧道检测相关的特征；第三个模块为模型训练模块，该模块使用提取的相关特征训练机器学习模型，对模型进行调优并持久化；第四个模块为模型推理模块，该模块加载已经训练好的模型并对未知DNS流量进行推理预测。

4.1 特征创建

DNS隧道通过DNS请求的负载携带编码或加密数据，其很多特征的分布均与正常DNS请求有差异，接下来将通过部分特征来分析DNS隧道。

4.1.1 子域长度

正常域名每个label的长度不超过63个字符，整个域名的长度不超过255个字符，正常域名长度往往远不及255个字符，但DNS隧道为了增加带宽，其负载往往会携带更多的信息。其次由于DNS隧道通常会对数据进行编码，因此其长度比正常域名更长。

4.1.2 最大label长度

与子域长度特征一样，由于DNS隧道负载携带更多的数据，因此与正常域名相比其每个label都较长。

4.1.3 字符比例

大写小写字母、数字、特殊字符等在域名中所占的比例也是区分正常或隧道的重要特征。因为DNS隧道在传输数据之前往往使用base32、base64、自定义加密算法等对数据进行编码或加密，因此负载中大写字母和数字的比例较高，但正常域名不区分大小写，其几乎不含有大写字母，且域名中数字所占比例也较低。

4.1.4 连续字符比例

由于DNS隧道负载为编码数据，因此其连续数字、连续辅音的比例与正常域名有较大的差异。

4.1.5 熵

编码的DNS隧道会使用更广泛的字符，其字符分布的熵值更高。然而正常域名有较高的可读性，其字符分布与正常英文语料一致，熵值相对较低。因此n-gram熵被视为可以指示DNS隧道活动的重要因素之一。

4.1.6 字符转移概率

基于正常域名可读性的特征，可以使用正常DNS流量或者英文语料统计N-Gram的转移概率。对于DNS隧道负载，其编码后的数据更随机，N-Gram转移概率与正常语料差异较大。因此N-Gram转移概率也是区分正常DNS和隧道的重要特征。

4.2 模型

通过分析各隧道工具生成样本的特征向量，各隧道工具生成的黑样本在各特征上均与白样本存在显著差异，但不同隧道工具样本之间也存在显著差异。因此需要对所使用的特征进行一系列优化，否则模型仅能检测出参与模型训练的隧道工具生成的数据，也就是说模型泛化能力差，不能发现未知隧道工具的数据。为了验证本文所述方法，训练集仅使用一种隧道工具产生的数据，通过检测未参与训练的隧道工具数据来测试模型的泛化能力。经过调节参数后模型达到最好的检测效果，模型在验证集AP 为 100%。

4.3 模型评估

目前的方案对检测参与训练的隧道工具都具有较高的准确率和召回率，但是对于未参与训练的工具或者未知工具的隧道数据检测效果较差。为了验证本文所述方案对于参与训练和未知工具隧道数据的检测效果，对多个通用开源DNS隧道工具和APT工具进行单独测试，最终检测结果显示本方案所述模型可以检测绝大多数的通用开源DNS隧道工具和APT隧道工具，而未检出的样本均为定时隐蔽隧道数据。具体检测效果如下：

五、 总结

基于机器学习的DNS隧道检测优于传统基于阈值、统计或专家规则的方法。本文提出的基于机器学习的DNS隧道检测方案优于同类方案，仅通过DNS请求的负载部分进行DNS隧道检测，同时对使用的特征进行了多项优化，可以支持多种工具和多种记录类型。当然，所提出的方案对于检测定时隐蔽隧道还有局限性，后续将进一步完善方案以适应更多场景。

参考文献

[1] Nadler A , Aminov A , Shabtai A . Detection of malicious and low throughput data exfiltration over the DNS protocol[J]. Computers & Security, 2019.

[2] Robert Falcone. DNS Tunneling in the Wild: Overview of OilRig’s DNS Tunneling[Online].https://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/,2020.

[3] S. Jaworski. Using splunk to detect dns tunneling[J]. SANS Institute InfoSec Reading Room, 2016.

[4] L. Bilge, E. Kirda, C. Kruegel, and M. Balduzzi. Exposure: Finding malicious domains using passive dns analysis[J]. NDSS,2011.

[5] K.Born, D.Gustafson.NgViz:detecting DNS tunnels through N-gram visualization and quantitative analysis[A]. Proceedings of the Sixth Annual Workshop on Cyber Security and Information Intelligence Research[C]. Oak Ridge, Tennessee, 2010. 1-4.

[6] A. Berg and D. Forsberg, "Identifying DNS-tunneled traffic with predictive models", Jun. 2019, [online] Available: http://arxiv.org/abs/1906.11246.

[7] M. Lyu, H. Habibi Gharakheili, C. Russell. “Mapping an Enterprise Network by Analyzing DNS Traffic,” in Proc. Passive and Active Measurement (PAM), Puerto Varas, Chile, Mar 2019.

[8] A. Nadler, A. Aminov, and A. Shabtai. Detection of malicious and low throughput data exfiltration over the dns protocol. Computers & Security, 80:36–53, 2019.

[9] A. Das, M.-Y. Shen, M. Shashanka, and J. Wang. Detection of exfiltration and tunneling over dns. In Machine Learning and Applications (ICMLA), 2017 16th IEEE International Conference on, pages 737–742. IEEE, 2017.

[10] J. Liu, S. Li, Y. Zhang, J. Xiao, P. Chang, and C. Peng. Detecting dns tunnel through binary-classification based on behavior features. In Trustcom/BigDataSE/ICESS, 2017 IEEE,pages 339–346. IEEE, 2017.

版权声明

转载请务必注明出处

版权所有，违者必究