0x00、业务需求

伴随着公有云大规模在现代商业数字化转型中的应用，上云后针对于底层的数据无法获取，导致传统安全策略无法部署等云安全问题一直困扰的CSO们，从公有云云安全责任共担模型上看，这就需要公有云提供更强有力的底层安全检测能力。当我们已经把传统的网络入侵检测引擎、威胁情报以及动态行为检测都部署上的时候，我们发现还是有很多云主机中招，而且在持续的泄密，那么，经过hunting Team分析后，我们发现80%高级的入侵手段是通过隐藏隧道方式。而这里使用最多的就是DNS隐藏隧道。

0x01、DNS隐藏隧道的前世今生

1.DNS协议介绍

大家可以上图流程，了解一下DNS请求的流程。当然也可以知道搭建DNS隧道服务器的物理位置。您需要一个域名、一个域名服务器（gsgsoft.com）来承载该域名的名称解析（一个“真正的DNS服务器”），以及一个假DNS服务器来使用人工DNS查询和响应通过隐蔽通道与客户机通信。

2.DNS隧道原理

DNS隧道是一种滥用域名系统（DNS）将另一个协议的数据编码为一系列DNS查询和响应消息的技术，DNS隧道在黑客世界中主要使用DNS隧道作为命令和控制（C&C），同时窃取隐私数据。

（1）黑客大规模应用的技术优势

    ·DNS无处不在

        防火墙允许DNS流量在两个方向上传递，并且DNS流量混杂在必须开放的正常流量中，传统的安全手段很难发现，因此DNS隐蔽通道对于绕过这些访问控制非常有用。

    ·DNS隧道的性能比较好

        如果你使用DNS隧道传输数据，可以达到800k/s.延时低等特征。

    ·黑客基础设施建设成本低

        一台vps

        一个域名控制权限

        一台云主机肉鸡权限

        使用开源dnscat2 https://github.com/iagox86/dnscat2

（2）DNS隧道传输技术原理

试图隐藏C＆C流量，以避免检测。通常，僵尸网络的C&C设计会导致消息被混淆或加密，从而更难检测和理解某些类型的C&C流量的语义。

恶意软件使用有效的DNS语法通讯。它的C＆C消息很有可能由具有TXT资源记录的DNS消息组成。此外，查询域名用于将某些参数从bot传输到C&C服务器，例如用于密钥派生的参数。

·检测手段

（3）传统安全检测手段无效

·IDS规则无法检测

传统的入侵检测引擎的对外可疑连接和恶意软件行为检测规则是无法检测到这类威胁

#alert udp $HOME_NET any -> $EXTERNAL_NET 53 (msg:"ET POLICY nstx DNS Tunnel Outbound"; content:"cT"; offset:12; depth:3; content:"|00 10 00 01 00 00 29 08|"; within:255; reference:url,savannah.nongnu.org/projects/nstx/; reference:url,nstx.dereference.de/nstx; reference:url,doc.emergingthreats.net/2002676; classtype:bad-unknown; sid:2002676; rev:3; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

·统计学分析方法

使用基线分析方法做统计，发现传输异常的情况，但是如果黑客不大规模传输数据的话，是无法发现异常的。

（4）机器学习手段的瓶颈

·传统机器学习算法

通常DNS异常检测是一个二分类的问题，

·误报挑战

DNS隧道将二进制数据编码为ASCII格式，然后在DNS查询中作为域名进行传输。从编码的二进制数据生成的这种域名具有高熵。此外，为了实现高带宽，DNS隧道对每个分组中最大可能的二进制数据块进行编码，从而产生大的DNS分组。因此，给定来自DNS隧道的DNS流量流，可以观察到注册域下的大量长子域，每个子域具有高熵。高熵，大量子域和大数据包大小似乎是DNS隧道的可靠指标。但是这种方法现在产生了无法控制的误报量。

其中一个主要原因是公有云CDN网络有可能和公有云共有一个机房，传输流量混杂在一起。考虑托管在大型CDN上的域。内容传递机制通常通过为每个托管客户域创建CNAME记录（即别名）来工作，以获得CDN域的唯一的，通常是随机的子域。给误报增加了可能性。

0x02、公有云检测架构&实现方式

为了降低运营成本，一般来说CDN网络和公有云网络会同时使用一套网络环境，这种情况要求我们的DNS隧道分类问题，要能识别CDN网络中 CNAME的流量（通常都是随机别名），但是这种是正常流量，也就是说我们需要把机器学习分类问题变成三分类：恶意DNS流量、CDN流量、普通正常DNS流量。

解决方案逻辑图

根据以上的逻辑图，大家可以清楚的了解公有云机房DNS数据流转情况，主要有DNS解析通道：

@1、当用户默认使用公有云DNS服务器的时候，DNS解析路径为：云主机->VPC网络NAT转换->DNS服务器->通过AZ的虚拟路由转换->到POP点->出公网

@2、当用户指定外网DNS服务器的时候，DNS解析路径：云主机->VPC网络-floatingIP->通过AZ的虚拟路由转换->到POP点->出公网，也就是说这里会经过我们的IDS探针。

针对这两种情况，我们需要两种解决方案：

@1、需要在默认DNS解析服务器上对DNS数据包劫持做机器学习检测。

@2、需要在IDS探针中恢复DNS协议，并且抓取流量吐给kafka，使用spark MLlib实时检测DNS解析流量。

·机器学习3分类实现

这部分，由于网上有很多成功的案例，我也不在这里多说，思路还是：

样本数据获取

@1、在正常的DNS服务器解析过程当中把cdn正常流量标记成cdn—label，

@2、在外网搭建DNS环境，把市面上的DNS隐藏隧道的程序跑一边（例如:前面提到的dnscat2，当然还有很多。。。）black_label

@3、在上述两个通道获取正常DNS解析样本，重点关注TXT、Cname。

训练离线/在线模型（当然可以尝试深度学习）

把预测模型加载到实时传输的数据量和离线的DNS服务上运行（根据误报结果不断调整特征）

0x03、总结

应用到公有云的恶意DNS流量检测解决方案，虽然环境复杂一些，但是检测原理大致不会改变，只是要双管齐下，如果模型再小点速度再快点，我们完全把它加载到云主机EDR Agent中，省去网络层检测的复杂度。