传统基于UDP DNS Tunnel特征
1、DNS攻击建模
- 密集请求型：例如随机子域名DDoS、反射型DDoS。其特征为QPS高、时序特征强，一般能够可视化观察到波峰。
- 漏洞攻击型：例如针对DNS server的已知漏洞攻击。其特征为数量少、受DNS type影响，适合分类统计。如果批量PoC的话，则特征同1。
- 数据传输型：例如DNS Tunnel、Malware DGA、PoC中的DNS回显、SSRF重绑定等。其特征在于域名文本特征明显、适用于规则匹配。
将DNS日志的Request和Response join到一起，然后做统计特征和文本特征：
- DNS请求时序分布
- QPS min/max/avg
- QPS均值
- QPS波动性
- 连接成功率
- DNS响应率
- TCP报文占比
- 请求响应比
- 单域名平均访问次数
- 单目标高频访问
- 多级子域名变化率
- DNS type时序分布
- DNS type源IP分布
- 长随机域名
- DNS Tunnel特征
- 部分DNS RCE
- 心跳包
2、为什么要做DNS隧道检测
企业内网环境中，DNS协议是必不可少的网络通信协议之一，为了访问互联网和内网资源，DNS提供域名解析服务，将域名和IP地址进行转换。网络设备和边界防护设备在一般的情况下很少对DNS进行过滤分析或屏蔽，因此将数据或指令藏匿于DNS协议中进行传输是一种隐蔽且有效的手段。在实际场景中，当攻击者拿下某台服务器权限，或服务器被恶意软件、蠕虫、木马等感染之后，通过建立DNS隧道从而达到敏感信息盗窃、文件传输、回传控制指令、回弹Shell等目的。
DNS隧道，即利用DNS请求和响应来承载经过编码或加密的数据内容，攻击者需要接管某个域名的NS服务器，使得对该域名的所有子域解析请求最终到达该台NS服务器上，最终，一条通信信道将在受控机器和攻击者的NS服务器之间建立（中间可能经过更多的NS节点），信道的建立、维持和通信基于DNS查询的请求和响应。为了便于了解DNS隧道，我们先通过一张图简单看一下DNS的工作原理。（DNS隧道每次终端发起请求只改变子域部分）
目前安全产品多是基于监控终端请求异常长度的域名等规则方式进行DNS隧道检测，攻击者可以使用商业渗透套件如Metasploit、Cobalt Strike等，或一些开源软件iodine、ozymandns、dns2tcp、dnscat2等快速轻易地构建DNS隐蔽隧道，并且可以通过修改域名长度、请求频率等特征轻易绕过传统基于规则的DNS隧道的检测模型。相比于基于规则的静态阈值检测误报高，易被绕过等问题，可以使用机器学习技术从历史数据中学习出一个DNS隧道模式用于检测。
目前，机器学习技术已被成功应用到语音识别、图像识别等领域，并有很好的效果。但目前在网络安全行业能成功应用机器学习的案例较少，主要由于无法获取到大数据量的异常样本。在DNS隧道检测场景中，业内同样存在异常样本数据稀缺问题。在机器学习算法模型选择方面，具体算法可分为基于特征的浅层学习（如逻辑回归）和自动提取特征的深度学习（如CNN），鉴于在安全检测类产品中要求模型具有高效性、结果便于解释性等特点，在模型选取上更侧重选用一些基于特征的浅层学习模型。具体，首先需对包含DNS隧道流量和正常DNS流量数据结合领域专家知识进行统计分析，挖掘出区分性强的特征集。其次使用多种模型训练特征并评估选取最佳效果模型。后续使用某行业客户内网真实环境验证了模型的有效性。
《Indentifying DNS-tunneled Traffic with Predictive Models》一文指出，同时使用DNS Querry和Respond比单独使用Query或者Respond更加有效。同时，以下特征中部分特征不能应用于实时的DNS隧道检测，只能在接收到DNS Respond的后进行机器学习算法检测，达到近似实时监测，但第一次不合法的DNS请求可能会放行。
3、特征分析
1、齐夫定律
在Detecting DNS Tunnels Using Character Frequency Analysis论文中，证明了还可以通过词频的检测识别DNS Tunneling的流量，根据Zipf定律，在自然语言的语料库里，词频往往会集中于某些小子集中，并且高频词到低频次的频率逐渐下降。而在这篇论文中，证明了DNS Tunneling中由于域名做了编码，不符合Zipf定律（例如dns2tcp），整个分布趋于平稳。
2、请求响应时间间隔
根据安全知识，正常DNS由于有RTT控制（Round-Trip time 往返时延）的本地缓存机制，请求包和响应包时间间隔通常较短。DNS隧道每次请求的subdomain都有变动，不会命中本地缓存。安全专家会将DNS的req/res时间间隔可作为鉴别依据，进一步在已经构建的数据集(正负样本均30万条左右)做统计分析结果如下图所示，正常DNS流量req/res时间间隔的均值和方差都低于DNS隧道的req/res时间间隔的均值和方差，因此req/res时间间隔可以作为一个机器学习模型特征。
TCP会话在建立通信过程中存在“三次握手”和断开连接的“四次握手”行为，因此TCP会话可以计算会话时长。
DNS会话属于 UDP 会话的其中一种，由于UDP无连接的特性，DNS没有会话时长的严格定义。定义在一次DNS会话中，最后一个DNS报文的时间和第一个DNS报文的时间差就作为这个 DNS会话的时长。
正常情况下，一次DNS解析过程首先由客户机在本地随机开启一个 UDP 端口，然后向指定的DNS服务器53端口发送DNS请求报文，两者由此建立一个 UDP通道。客户机一旦得到相应DNS回复报文，这个 DNS解析过程就结束了，如果没有后继的DNS解析任务，创建的 UDP套接字会保存一段时间然后关闭，完成一次 DNS 会话，再次进行DNS解析的时候，再随机开启另一个UDP端口，重复上述过程。因此，正常域名解析DNS会话的时间短；
3、查询/响应域名长度
根据安全知识，正常DNS请求包中会提交查询域名，此域名是正常网站访问域名，长度适中。DNS隧道为了最大效率使用带宽传输更多信息，通常DNS隧道的请求包域名较长。安全专家会将DNS查询域名长度作为鉴别依据，进一步在已经构建的数据集(正负样本均30万条左右)做统计分析结果如上图所示，正常DNS流量请求域名长度的均值和方差都低于DNS隧道的请求域名长度的均值和方差，因此DNS请求域名长度可以作为一个机器学习模型特征。
4、回答RR数/问题数之比 （Answer RRs / Quentions） （待确认）
DNS查询IP地址（A）可能会响应多个域名服务区别名（CNAME），因此一个请求可能就收多个响应。DNS隧道一个请求对应一个响应数。
5、查询域名熵（有效载荷部分是否加密， 同特征一）
DNS协议是一种明文传输协议，DNS隧道木马出于提高通信内容隐蔽性的需要，往往会对通信数据进行加密，因此把加密的DNS数据作为可疑的DNS隧道木马通信的一个特征。为了提高特征工程速度，我们可以使用信息熵作为是否存在加密的衡量标准。
根据安全知识，正常DNS查询中的subdomain的编写规范通常符合RFC规范，以字母开始以字母或数字结尾，中间可以出现格式包括：小写字母 a-z，大写字母A-Z,数字0-9，以及分隔符’-‘共63种字符。在DNS隧道中，通常会对传输数据做加密处理（如base64、base32、base128、RAW等）,并且会大量使用63种字符集以外的字符。安全专家会将这种编写规范性作为鉴别依据，进一步使用熵去度量subdomain的编写规范性并在已经构建的数据集(正负样本均30万条左右)做统计分析结果如下图所示，图中分别展示了使用unigram、trigram、bigram做单元切分后熵值计算的均值和方差，从图可知正常DNS的subdomain熵均值相比于DNS隧道subdomain熵均值要低很多。
6、n-gram文本统计特征（DNS隧道）
通过2-gram/3-gram提取恶意DNS query的文本特征，参与训练。
7、总的Query 报文Payload载荷量（Data Length）
查询类型为A（IPv4地址），则Data Length固定为4，但是DNS隧道 Data Length普遍比较大，且使用A记录类型的也比较少。 若含有多个Respond，计算平均长度 。
同时，如果是正常的DNS交互，在一个会话中的总的数据data总量应该不会非常大。但是由于DNS隧道需要进行指令和数据的传输，因此总的数据载荷会远大于正常水平。
8、可读性（数字比、元音比、辅音比、重复字符比、特殊符号比、马尔科夫转移概率）
使用DGA检测时使用的一些特征提取子域名的可读性特征。
9、记录类型
在正常的DNS流量中。A记录类型的流量占20%-30%，CNAME记录为38%-48%，AAAA记录占25%，NS记录只有5%，TXT记录只有1%-2%。然而为了获取更高的带宽，一部分的DNS隐蔽信道工具如Iodine。在默认配置下会使用TXT或NULL等不常用的记录类型。
10、有效载荷的上传下载比 （Query Subdmain / Data Length）
DNS会话报文中的有效载荷是指DNS报文中除去DNS报文头部剩下的queries字段和answers字段、授权和额外信息字段的内容。
DNS隧道木马在和控制端交互通信时，DNS隧道木马控制端向被控端发送少量的控制命令，被控端需要回传大量的本机敏感资源文件数据。
然而，正常DNS解析情况刚好相反，客户端DNS请求报文通常短小，而DNS服务器返回的数据信息比较多。因此DNS隧道木马会话的上传下载比例比一般正常的DNS会话大。
数据包length可以作为时序特征
11、Query/Answer的长度特征
DNS隧道工具产生的DNS query会比较长，因为要附带客户端的信息回传；而DNS answer会比较短，因为只要传输指令，甚至指令action code即可。
12、域名对应的主机名数量
对于DNS隧道木马而言，控制端要不断借助DNS qury的query_name来承载要传输的内容，所以从主机数量这个维度来看，在一个DNS tunnel会话中，域名对应的主机名数量会明显大于正常的DNS通信。
13、FQDN数异常检测
域名有全称和简称的区别。全称的域名，直译为"完全的合格的域名"(FQDN，Fully Qualified Domain Name)，表现为由 “·” 隔开的点分式层次结构，叫名称空间， 它指定了一台主机和它所属域的隶属关系，而简称通常就是这台主机的计算机名，在域名的最左边。
可以这么说FQDN(完全合格的域名)，是域加计算机名的总称。比如: http://www.microsoft.com 这个FQDN 中，www 是主机名，http://microsoft.com 是域。 www+http://microsoft.com 组合在一块就成了一个完整的域名(FQDN)。
可以通过分析一定时间窗口内所产生的FQDN数，通常DNS Tunneling的FQDN数在一定时间窗口内会远高于正常的DNS流量。
14、DNS会话中数据包总数
因为DNS隧道木马的会话一般随着木马生命周期的结束而结束，在整个木马的生命周期里会向外发送心跳报文、传输本机敏感信息、资源文件等，控制端会下达相关的远程控制指令等。所以在 DNS 隧道木马会话中 DNS报文数量大。然而，正常客户端产生的DNS会话随着一次DNS解析任务结束而结束，DNS会话比较简短。大多数情况是2个，由1个DNS请求报文和1个DNS响应报文组成。
这个回话持续时间可以当作时序特征输入
15、“上行大包”占请求报文总数的比例
在DNS请求报文中，如果queries字段字节数大于50，那么定义该DNS请求报文为上行大包。DNS隧道木马被控端把要传输的内容封装在queries字段的域名中，DNS隧道木马为了在一次传输过程中携带尽可能多的隐蔽信息，往往造成queries字段中的域名长度偏长。与正常DNS会话相比，DNS隧道木马会话中“上行大包”占请求报文总数的比例较大。
另一方面，如果攻击者为规避检测，强制split拆分构造相对短小的域名，从而减少每次发送的报文携带的隐蔽通信内容。当被控端传送某一固定的敏感资源文件，由于传送的资源文件大小是固定的,如果牺牲一次携带的隐蔽信息的内容，势必造成整个DNS会话的DNS报文总数的增加。
可知,在一次 DNS隧道木马的会话中，DNS报文总数和DNS报文长度是负相关的。因此我们基于该规律构造复合特征，即 DNS报文总数 * 平均报文长度 = 总的报文length。
16、“下行小包”占响应报总数的比例
我们定义如下：将 DNS应答报文中answers字段字节数小于50的数据包称为“下行小包”。
DNS隧道木马在交互过程中，控制端发送的控制命令一般有特定含义，且短小精简，因此DNS隧道回复报文一般是“下行小包”。对于正常本机DNS解析请求而言，客户机是资源请求者，DNS服务器返回的数据除了answers字段外，还经常返回授权和额外信息字段信息，因此正常的 DNS响应报文相对较大。
这两个特征可以定义一些特征，通信方向上的长度特征。但是好像不适用啊，还得试一试实验做出来看看效果。
17、基于多个DNS报文分析（基于无监督的分析）
在网络通信中，由【源IP地址、源端口、传输层协议、目的IP地址、目的端口】这5个量组成的一个集合，称之为五元组，任意一个数据包都可以将其表示为五元组。五元组能够区分不同会话，并且对应的会话是唯一的。
研究单个DNS报文并不能从时间区间维度刻画出完整的DNS隧道木马的行为，我们可以通过对五元组进行归并聚类，从DNS会话的角度分析隧道木马流量。
其依据是DNS隧道木马在通信过程中通信双方所扮演的角色和通信模式与正常DNS解析行为具有显著的差异性（数据中包含一定的规律）
参考https://zhuanlan.zhihu.com/p/143220945、https://blog.csdn.net/weixin_30675247/article/details/95581667
1400
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
