2. 西安报业传媒集团, 陕西 西安 710002
2. Xi'an Newspaper Media Group, Xi'an 710002, China
DNS隧道技术是指利用DNS协议建立隐蔽信道, 实现隐蔽数据传输.自从2004年Dan Kaminsky在Defcon大会上发布的基于NSTX的DNS隐蔽隧道工具之后[1], 逐渐出现了不少DNS隐蔽通道工具, 如iodine、dns2tcp、tcp-over-dns、heyoka等.开发DNS隧道工具的初衷是跳过上网登录认证, 实现免费上网.然而危险的是, DNS隐蔽通道还可以被恶意利用, 一些渗透工具可以通过DNS隐蔽通道进行远程控制甚至窃取数据.Raman等[2]已经证明, 在Metasploit渗透测试平台下, 利用内网机缓冲区或者其他漏洞, 能建立功能完全的从专用内网到外网控制者的DNS隧道, 并且可以利用建立的DNS隧道进行控制攻击.2016年5月, Palo Alto曝光了一起APT攻击[3], Webky团队利用DNS请求应答机制作为攻击渗透的命令控制通道.攻击者把C & C服务器的指令巧妙地封装在DNS响应报文中, 以此躲避检测.基于DNS隧道的通信技术已逐渐成为黑客控制目标的关键技术手段.在2012的RSA会议上, 基于DNS协议的远程控制恶意软作被视为6种未来最危险的攻击之一[4].本文将基于DNS协议的远程控制软件称作DNS隧道木马.
DNS隧道木马带来的威胁很大, 而且DNS隧道木马难以得到有效的监控.一方面是因为DNS报文具有天然的穿透防火墙的能力；另一方面, 目前的杀毒软件、IDS等安全策略很少对DNS报文进行有效的监控管理.目前, DNS隧道木马的检测技术停留在基于DNS隧道工具的检测上, 主要分为两大类[5]：载荷分析和流量监测.
DNS载荷检测主要是针对DNS请求和响应, 对报文中的有效载荷进行分析.Patrick等[6]把主机名超过52个字符的DNS请求作为识别DNS隧道的特征.Kenton等[7-8]用信息熵来检测DNS隧道域名字母的混乱程度.Qi等[9]用二元语法来检测DNS报文中的域名字母频率, 发现正常的域名满足Zipf定律, 而走DNS隧道的域名遵循的是随机分布.基于DNS报文有效载荷特征的DNS隧道检测方法有很大的局限性, 原因是一些经过URL Encoding编码的合法域名比较长而且复杂, 很容易引起误报.
DNS流量监测手段主要是检测网络中的DNS流量变化情况.Ellens等[10]通过检测单位时间内DNS报文流速率来检测是否存在DNS隧道.Ichise等[11]利用检测txt类型的DNS报文来发现僵尸网络的通信情况.章思宇等[12]发现隐蔽隧道通信中的DNS流在单位时间内的回答数据的总字节数与合法请求具有明显的差异.随着时间的推移, DNS流量监测方法的局限性也逐渐暴露出来.一方面, 该检测手段忽视了DNS报文骤增异常也可能是由DNS Query Flood攻击等其他原因引起的；另一方面, 以隐蔽控制为主的DNS隧道木马的出现使得这种检测方法变得捉襟见肘, DNS隧道木马为了提高通信的隐蔽性往往会牺牲一些传输效率, 比如DNScat2的传输速率就在1 K/s左右[13].
针对目前DNS隧道检测误报率高且不能适用于高隐蔽性新型DNS隧道木马检测的问题, 本文另辟蹊径, 通过分析DNS隧道木马通信行为和正常DNS解析行为的差异性, 提出一种基于通信行为分析的DNS隧道木马检测方法, 并结合实验数据对该检测模型的有效性和实用性进行验证.
1 DNS隧道木马根据木马工作原理的不同, 将DNS隧道木马细分为IP直连型和域名型.
1.1 IP直连型DNS隧道木马如果DNS隧道木马的服务器可以与本地主机通过IP直接通信, 传输协议采用DNS协议, 则称为IP直连型DNS隧道木马.IP直连型DNS隧道木马的服务器端开放53端口, 被控端利用UDP socket套接字直接建立连接.在这种情况下, 两者传输的内容实际上是基于UDP服务, 这种木马与传统UDP木马的不同点就是利用53端口进行传输交互数据.IP直连型DNS隧道木马需要精心构造传输的载荷内容, 如果攻击者构造的UDP载荷内容不符合DNS报文格式, 在wireshark等流量分析工具的流量解析下, 很容易出现DNS报文异常的情况.
1.2 域名型DNS隧道木马对于域名型DNS隧道木马而言, 通信原理要相对复杂一些.域名型DNS隧道木马基本通信架构如图 1所示.被控端把要传输的内容封装在请求的域名中, 当被控端向任意一台DNS服务器请求该域名下的子域名时, 本地DNS服务器无论是通过递归查询还是迭代查询, 都会向外转发这个DNS请求, 最终这个DNS请求都会被送到DNS隧道服务器控制端中.控制端解析请求报文, 得到被控端传来的信息, 然后将攻击控制命令通过封装在DNS响应报文中, 从而实现双方通信.
|
图 1 域名型DNS隧道木马通信架构图 Fig. 1 Communication architecture of domain-type DNS tunnel Trojan |
域名型隧道木马和IP直连型DNS隧道木马虽然工作原理有差异, 但是从流量角度上来看都是基于DNS协议.IP直连型DNS隧道木马直接与DNS服务器通过UDP socket通信, 因此通信效率要比域名型DNS隧道木马高, 但是这种DNS隧道木马致命的弱点是直接把IP暴露在网络流量中, 如果客户端指定信任的DNS服务器解析DNS服务, 那么IP直连型DNS隧道木马就很容易被IP黑白名单封杀.对于域名型DNS隧道木马而言, 只要客户机能与任意一台外网的DNS服务器通信, 那么域名型
DNS隧道木马就可以工作, 因此域名型DNS隧道木马生存能力更强, 隐蔽性更高, 更适合进行隐蔽的控制渗透任务.基于以上考虑, 本文利用分析流量通信行为进行检测的主要对象是域名型DNS隧道木马.
2 DNS隧道木马通信行为分析在网络通信中, 由源IP地址、源端口、传输层协议、目的IP地址和目的端口这5个量组成的一个集合, 称之为五元组.任意一个数据包都可以将其表示为五元组.五元组能够区分不同会话, 并且对应的会话是唯一的.研究单个DNS报文并不能从时间维度刻画出完整的DNS隧道木马的行为, 因此本文通过拉长时间维度, 从DNS会话的角度分析隧道木马流量.基于通信行为的DNS隧道木马检测方法是根据DNS隧道木马通信过程中产生的流量进行检测, 其依据是DNS隧道木马在通信过程中通信双方所扮演的角色和通信模式与正常DNS解析行为具有显著的差异性.本文通过以下7个通信行为分析DNS隧道木马会话和正常DNS会话的特性.
2.1 DNS会话时长TCP会话在建立通信过程中存在“三次握手”和断开连接的“四次握手”行为, 因此TCP会话可以计算会话时长.DNS会话属于UDP会话的其中一种, 由于UDP无连接的特性, DNS没有会话时长的严格定义.
定义在一次DNS会话中, 最后一个DNS报文的时间和第一个DNS报文的时间差就作为这个DNS会话的时长.
正常情况下, 一次DNS解析过程首先由客户机在本地随机开启一个UDP端口, 然后向指定的DNS服务器53端口发送DNS请求报文, 两者由此建立一个UDP通道.客户机一旦得到相应DNS回复报文, 这个DNS解析过程就结束了, 如果没有后继的DNS解析任务, 创建的UDP套接字会保存一段时间然后关闭, 完成一次DNS会话.再次进行DNS解析的时候, 再随机开启另一个UDP端口, 重复上述过程.因此，正常域名解析DNS会话的时间短.对于DNS隧道木马而言, 创建的UDP套接字通常会等到木马下线或者木马生命结束才关闭, 导致DNS隧道木马的DNS会话时长远大于正常DNS会话时长.
2.2 DNS会话中数据包总数因为DNS隧道木马的会话一般随着木马生命周期的结束而结束, 在整个木马的生命周期里会向外发送心跳报文、传输本机敏感信息和资源文件等, 控制端会下达相关的远程控制指令等, 所以在DNS隧道木马会话中DNS报文数量大.然而, 正常客户端产生的DNS会话随着一次DNS解析任务结束而结束, DNS会话比较简短.在某实验室网络出口, 统计1 h流量中所有DNS会话对应的DNS报文数量, 发现大多数正常的DNS会话中数据包的个数为2个, 由1个DNS请求报文和1个DNS响应报文组成.具体结果如图 2所示, 其中NDNS_se表示DNS会话数, Npac表示DNS报文个数.
|
图 2 不同数量数据包的DNS会话数 Fig. 2 DNS session number of different numbers of packets |
在DNS请求报文中, 如果queries字段字节数大于50, 那么定义该DNS请求报文为上行大包.DNS隧道木马被控端把要传输的内容封装在queries字段的域名中, DNS隧道木马为了在一次传输过程中携带尽可能多的隐蔽信息, 往往造成queries字段中的域名长度偏长, 与正常DNS会话相比, DNS隧道木马会话中“上行大包”占请求报文总数的比例较大.
换个角度考虑, 如果攻击者为规避检测, 精心构造相对短小的域名, 从而减少每次发送的报文携带的隐蔽通信内容.当被控端传送某一固定的敏感资源文件, 由于传送的资源文件大小是固定的, 如果牺牲一次携带的隐蔽信息的内容, 势必造成整个DNS会话的DNS报文总数的增加.可知, 在一次DNS隧道木马的会话中, DNS报文总数和DNS报文长度是负相关的.
2.4 “下行小包”占响应报总数的比例因为域名型的DNS隧道木马把双方交互的信息封装在queries和answers字段中, 而且answers字段是附加在queries字段后面, 所以一个DNS响应报文总是比对应相同ID的DNS请求报文大.为了有效提取特征, 本文重新把DNS有效载荷部分提取出来, 重新定义如下：将DNS应答报文中answers字段字节数小于50的数据包称为“下行小包”.
DNS隧道木马在交互过程中, 控制端发送的控制命令一般有特定含义, 且短小精简, 因此DNS回复报文一般是“下行小包”.对于正常本机DNS解析请求而言, 客户机是资源请求者, DNS服务器返回的数据除了answers字段外, 还经常返回授权和额外信息字段信息, 因此正常的DNS响应报文相对较大.
2.5 有效载荷的上传下载比DNS会话报文中的有效载荷是指DNS报文中除去DNS报文头部剩下的queries字段和answers字段、授权和额外信息字段的内容.
DNS隧道木马在和控制端交互通信时, DNS隧道木马控制端向被控端发送少量的控制命令, 被控端需要回传大量的本机敏感资源文件数据.然而正常DNS解析情况刚好相反, 客户端DNS请求报文通常短小, 而DNS服务器返回的数据信息比较多.因此DNS隧道木马会话的上传下载比例比一般正常的DNS会话大.
2.6 有效载荷部分是否加密DNS协议是一种明文传输协议.DNS隧道木马出于提高通信内容隐蔽性的需要, 往往会对通信数据进行加密, 因此把加密的DNS数据作为可疑的DNS隧道木马通信的一个特征.本文采用文献[14]介绍的基于加权累积和检验的时延自适应加密流量盲识别算法EIWCT对DNS数据流有效载荷部分是否加密进行检测.该算法对网络数据报文实施累积和检验, 根据报文长度加权综合, 具有较高的精度和实时效率.
2.7 域名对应的主机名数量对于DNS隧道木马而言, 控制端在一次传输本机敏感资源文件时, 采用的域名是固定的, 造成在一次的DNS会话中, 域名中对应的主机名数量与DNS报文数量成正相关的关系.正常的域名中注册用的主机名是有限的, 本文利用开源工具subDomianBrute[15]穷举域名对应的主机名, 具体结果如图 3所示.其中NHost表示域名对应主机名的数量.结果显示：即使类似百度这样的知名域名, 对应的子域名个数也不超过1 100个.DNS隧道木马在传输数据时, 一个DNS请求报文中域名所能携带最大的字节数为253个字节.这意味着传输1 M的资源文件, 就会产生至少4 144个DNS报文, 域名对应的主机名数量就有4 144个, 这要远大于正常网站域名对应的主机名数量.
|
图 3 不同域名对应的主机名数量 Fig. 3 Number of host names corresponding to different domainnames |
根据第2章分析的DNS隧道木马通信行为的7个特征, 将DNS会话提取成评估向量：< 会话时长, 数据包总数, “上行大包”占请求包总数的比例, “下行小包”占响应报总数的比例, 有效载荷的上传下载比, 有效载荷部分是否加密, 域名的对应的主机名数量>.根据DNS会话评估向量判断一个DNS会话流量是否为恶意DNS隧道木马流量, 是一个典型的二分类问题.本文采用的随机森林是一种统计学习理论, 在对数据进行分类的同时, 还可以给出各个变量的重要性评分, 评估各个变量在分类中所起的作用, 能够有效处理非线性数据[16-17].
3.1 基于随机森林的DNS评估向量训练过程随机森林由多棵CART(classification and regression tree)构成.本文基于随机森林的DNS评估向量训练过程如图 4所示.
|
图 4 随机森林决策流程图 Fig. 4 Random forest decision flow chart |
(1) 假定训练集中的样本个数为n, 利用Bootstrap法[18]有放回采样, 随机生成k个子训练集{X1, X2, …, Xk}, 每个子训练集的样本个数也是n, 子训练集中的样本是可重复的.
(2) 每个训练样本集对应分类树的全部训练数据.在树的每个节点处从7个特征中随机挑选3个特征, 按照信息增益算法(详细求解算法见3.2节)从这3个特征中选出1个特征进行分裂生长；新生成的树节点将在剩余的2个特征采取信息增益算法进行分裂, 直到决策树1个叶子节点无法继续分裂为止.
(3) 随机森林是所有决策树的集合, 每棵决策树都会对输入变量输出一个决策结果E(Ti), 如果判定是DNS隧道木马流量, 则E(Ti)=1；否则, E(Ti)=0.统计所有k棵决策树的投票结果:
| $H(x) = \sum\limits_{i = 1}^k {E({T_i})} $ | (1) |
(4) 对于输入的DNS会话变量, 给出最终的DNS隧道木马判定公式：
| $Y = \left\{ {\begin{array}{*{20}{c}} 1&{H(x)/k > 0.5;}\\ { - 1} & \text{其他.} \end{array}} \right.$ | (2) |
若Y=1, 则判定DNS会话属于DNS隧道木马恶意流量；否则为正常流量.
3.2 信息增益过程的求解 3.2.1 符号定义说明(1) 记DNS会话训练集记为D, |D|表示训练集中样本的个数.
(2) 训练集D可分为DNS隧道木马类D*和正常DNS类D#.|D*|表示DNS隧道木马类D*中样本的个数, D#表示|D#|中样本的个数, 则
| $|D|=|D^*|+|D^\#|.$ | (3) |
(3) DNS会话训练集D有7个属性.记其中一个属性为A, A有n个不同的取值{a1, a2, …, an}, 根据特征A的取值可将D划分为n个子集{D1, D1，…，Dn}, |Di|表示子集Di中的样本个数, 其中i=1, 2, …, n.则有
| $\sum\limits_{i = 1}^n {|{D_i}| = |D|} $ | (4) |
(4) 记子集Di中属于DNS隧道木马类的样本的集合为Di*, |Di*|是Di*样本的个数；Di#表示子集Di中属于正常DNS类的样本的集合, |Di#|是Di#样本的个数, 其中i=1, 2, …, n.
3.2.2 信息增益求解信息增益表示得知特征A的信息而使得D类信息的不确定性减少的程度.属性A对训练集D的信息增益记为GD(A), GD(A)的计算方式为训练集D的熵与属性A给定条件下D的经验条件熵I(D|A)的差值.根据信息论的定义, 训练集D的信息熵为
| $I(D) = - \frac{{|{D^*}|}}{{|D|}}{\log _2}\frac{{|{D^*}|}}{{|D|}} - \frac{{|{D^\# }|}}{{|D|}}{\log _2}\frac{{|{D^\# }|}}{{|D|}}.$ | (5) |
特征在给定子集下的经验条件熵的计算公式为
| $I(D|A) = \sum\limits_{i = 1}^n {\left( {\frac{{|{D_i}|}}{{|D|}}I({D_i})} \right)} = - \sum\limits_{i = 1}^n {\left[ {\frac{{|{D_i}|}}{{|D|}}\left( {\frac{{|D_i^*|}}{{|{D_i}|}}{{\log }_2}\frac{{|D_i^*|}}{{|{D_i}|}} + \frac{{|D_i^\# |}}{{|{D_i}|}}{{\log }_2}\frac{{|D_i^\# |}}{{|{D_i}|}}} \right)} \right]} .$ | (6) |
将式(5)、(6) 代入式(7), 计算得到属性A的信息增益:
| ${G_D}(A) = I(D) - I(D|A)$ | (7) |
DNS隧道木马检测模型的总体结构设计如图 5所示.该检测模型主要包含数据包过滤整合模块、分类训练学习模块和木马流量检测模块.
|
图 5 DNS隧道木马检测流程框架 Fig. 5 Framework of DNS tunnel Trojan detectionprocess |
数据包过滤整合模块主要是从网卡处采集数据包, 采用Winpcap数据包捕获技术的底层过滤机制抓取DNS流量.将抓取的DNS流量按照五元组进行聚类, 形成DNS会话数据流.将一个个DNS会话数据流提取成DNS会话评估向量, 作为分类训练模块和木马流量监测的输入.本检测模型兼并考虑IP直连型DNS隧道木马, 如果DNS会话中出现不信任的外网地址, 直接将该IP和相关信息报警存入数据库.分类训练学习模块首先要标记训练样本.将DNS隧道木马DNS数据流和正常DNS数据流标记并且训练.根据提取的DNS隧道木马通信7个属性, 运用随机森林的分类学习方法, 生成一棵棵决策树, 并且对每棵决策树的分类结果进行投票表决.木马流量检测模块是整个模型的核心部分, 主要功能是对DNS会话数据流进行分类检测, 判断待检测的DNS会话是否为DNS隧道木马的通信数据.根据识别出来的DNS隧道木马流量进行标记汇总, 产生报警信息, 把结果存入数据库.
4 实验分析为了验证本文提出方法的有效性和实用性, 本文从2个方面进行试验：验证通过随机森林分类算法训练的DNS隧道木马检测分类器能够有效地在网络出口的流量数据中检测异常；验证该分类器针对未知的DNS隧道木马是否具有通用的检测能力并且保证误报率在可承受范围之内.
4.1 实验环境如图 6所示, DNS隧道窃密木马检测系统部署在某实验室局域网出口, 利用交换机的镜像端口采集局域网的DNS数据流量进行检测.实验室测试主机总共10台, 其中3台主机是植入DNS隧道木马的主机.实验室的局域网出口的网络带宽约为100 Mbps.实验样本采用的DNS隧道木马为DNScat2、DNShell v1.7[19].在局域网出口处随机采样10 000个正常DNS会话并标记采样1 000个DNS隧道木马会话作为训练样本.
|
图 6 DNS隧道木马检测程序环境示意图 Fig. 6 Diagram of DNS tunnel trojan detection program environment |
为了检测本方法对DNS隧道木马流量的识别和检测能力, 同时验证该方法对正常DNS数据流的误报情况, 设计以下测试方案：样本训练结束之后, 在内部局域网中的3台主机随机植入DNS隧道木马样本, DNS隧道木马控制端部署在具有外网IP的云主机上, 进行不定期的操作, 同时客户端保持日常的上网工作.DNS隧道窃密木马检测系统连续运行30 d, 以3 d作为一个测试周期, 分别进行10次检测率和误报率测试.为了检测未知DNS隧道木马的能力, 除了前5次采用之前训练用的DNScat2、DNShell v1.7之外, 后5次测试利用cobalt strike[20]渗透平台工具生成多个DNS隧道木马.为了方便标记DNS隧道木马流量, 手工标记记录DNS隧道木马的IP以及端口号.具体测试结果如表 1所示, 其中Ntest表示实验次数, NTrojan_se表示DNS隧道木马会话数, NTN表示检测出DNS隧道木马会话数, NFN表示未检测到木马的数量, RTN为DNS隧道木马会话检测率.
实验结果表明：一个测试周期的检测率都在95%以上, 平均检测率为98.47%.DNS隧道木马情况漏检的情况主要有以下几类：
1) DNS隧道木马未上线, 但是有规律向控制端发送心跳报文；
|
表 1 DNS隧道木马会话检测结果 Table 1 DNS tunnel Trojan sessions test results |
2) DNS隧道木马上线, 但木马很快下线, 造成会话持续时间短, 传输数据小.
存在这2种漏检情况是因为DNS隧道木马没有明显的交互通信行为.将正常DNS会话误报为木马的情况如表 2所示, 其中, Nnor_se表示正常DNS会话数, NFP表示正常DNS会话被误报为DNS隧道木马的数量, RFP为正常DNS会话误报率.
|
|
表 2 正常DNS会话误报情况 Table 2 Benign DNS sessions False alarm test results |
针对4.2节测试中误报率高的情况, 重点提取产生误报的DNS会话, 提取相关IP.统计查询发现, 绝大部分的误报来源于奇虎360的IP.表 3列举了其中一部分报警的IP信息, 图 7展示了其中一部分引起报警的DNS报文.
|
|
表 3 报警的IP信息 Table 3 IP information that caused alarm |
|
图 7 引起误报的DNS报文 Fig. 7 False alarm DNS message |
经过分析可知, 本局域网的所有主机都安装了奇虎360的安全产品, 每台主机会不定时地向奇虎360所属公司的IP发送格式异常的DNS报文, 被本系统误检为异常.针对这种情况, 采用白名单的方式过滤奇虎360公司IP的DNS报文, 将上述实验的DNS数据重新进行测试, 结果显示误报率大幅降低, 具体结果如表 4所示.
|
|
表 4 添加白名单后的误报情况测试结果 Table 4 Test results of false positive cases with white list |
实验结果表明, 过滤奇虎360公司的IP后的检测模型误报率降低至不足0.01%.这些少数情况误报的主要原因是有些客户机短时间地周期性请求某个固定域名, 由于网络拥塞等原因, 经过一段时间后才收到DNS响应报文.这种少见但正常DNS会话情况会被误检为DNS隧道木马流量.
5 结语实验测试结果表明：本文提出的基于通信行为分析的DNS隧道木马检测方法不仅能有效地检测出高隐蔽性DNS隧道木马, 误报率小, 漏报率低, 而且对未知的DNS隧道工具同样具有很高的检测能力, 证明了该方法的有效性和实用性.
进一步挖掘在DNS流量中包含的可用于DNS隧道木马检测的新特征、提高分类器的性能将是下一步研究的方向.
| [1] | KAMINSKY D. Black Ops of DNS[EB/OL]. (2004-12-27)[2016-09-05]. https://events.ccc.de/congress/2004/fahrplan/event/121.de.html. |
| [2] | RAMAN D, DE SUTTER B, COPPENS B, et al. DNS tunneling for network penetration[C]//Information Security and Cryptology:ICISC 2012. Berlin Heidelberg:Springer, 2012:65-77. https://link.springer.com/chapter/10.1007/978-3-642-37682-5_6 |
| [3] | GRUNZWEIG J, SCOTT M, LEE B, et al. New wekby attacks use DNS requests as command and control mechanism[EB/OL]. (2016-05-24)[2016-09-15]. http://researchcenter.paloaltonetworks.com/2016/05/unit42-new-wekby-attacks-use-dns-requests-as-command-and-control-mechanism. |
| [4] | SKOUDIS E. The six most dangerous new attack techniques and what's coming next[EB/OL]. (2012-08-29)[2016-09-05]. https://blogs.sans.org/pentesting/?les/2012/03/RSA-2012-EXP-108-Skoudis-Ullrich.pdf. |
| [5] | FARNHAM G, ATLASIS A. Detecting DNS tunneling[J]. SANS Institute InfoSec Reading Room, 2013(9): 1–32. |
| [6] | BUTLER P, XU K, YAO D D. Quantitatively analyzing stealthy communication channels[C]//International Conference on Applied Cryptography and Network Security. Berlin Heidelberg:Springer, 2011:238-254. https://link.springer.com/chapter/10.1007/978-3-642-21554-4_14. |
| [7] | BORN K, GUSTAFSON D. Detecting dns tunnelsusing character frequencyanalysis[J]. Corr, 2010, 4(358): 2567–2573. |
| [8] | BORN K, GUSTAFSON D. NgViz:detecting DNS tunnels through n-gram visualization and quantitative analysis[C]//Proceedings of the Sixth Annual Workshop on Cyber Security and Information Intelligence Research. Oak Ridge:ACM. 2010:1-4. http://adsabs.harvard.edu/abs/2010arXiv1004.4359B |
| [9] | QI C, CHEN X, XU C, et al. A bigram based real time DNS tunnel detection approach[J]. Procedia Computer Science, 2013, 17(110): 852–860. |
| [10] | ELLENS W, URANIEWSKI P, SPEROTTO A, et al. Flow-based detection of DNS tunnels[C]//IFIP International Conference on Autonomous Infrastructure, Management and Security. Barcelona:AIMS, 2013:124-135. https://hal.inria.fr/IFIP-LNCS-7943/hal-01489962 |
| [11] | ICHISE H, JIN Y, ⅡDA K. Analysis of via-resolver DNS TXT queries and detection possibility of botnet communications[C]//2015 IEEE Pacific Rim Conference on Communications, Computers and Signal Processing (PACRIM). Victoria:IEEE, 2015:216-221. http://ieeexplore.ieee.org/document/7334837/ |
| [12] |
章思宇, 邹福泰, 王鲁华, 等. 基于DNS的隐蔽通道流量检测[J].
通信学报, 2013, 34(5): 143–151.
ZHANG Si-yu, ZOU Fu-tai, WANG Lu-hua, et al. Detecting DNS-based covert channel on live traffic[J]. Journal on Communications, 2013, 34(5): 143–151. |
| [13] | RON. DNScat2[EB/OL]. (2016-09-07)[2016-9-15]. https://github.com/iagox86/dnscat2 https://github.com/iagox86/dnscat2 |
| [14] |
赵博, 郭虹, 刘勤让, 等. 基于加权累积和检验的加密流量盲识别算法[J].
软件学报, 2013, 24(6): 1334–1345.
ZHAO Bo, GUO Hong, LIU Qin-rang, et al. Protocol independent identification of encrypted traffic based on weighted cumulative sum test[J]. Journal of Software, 2013, 24(6): 1334–1345. |
| [15] | LI J J, subDomainBrute[EB/OL]. (2015-04-01)[2016-10-05]. https://github.com/lijiejie/subDomainsBrute. |
| [16] | YANG Z R. Classification and regression trees, random forest algorithm[M]//Machine Learning Approaches to Bioinformatics. 2015:120-132. http://www.worldscientific.com/doi/abs/10.1142/9789814287319_0009 |
| [17] | SVETNIK V, LIAW A, TONG C, et al. Random forest:a classification and regression tool for compound classification and QSAR modeling[J]. Journal of chemical information and computer sciences, 2003, 43(6): 1947–1958. DOI:10.1021/ci034160g |
| [18] | JOHNSON R W. An introduction to the bootstrap[J]. Teaching Statistics, 2001, 23(2): 49–54. DOI:10.1111/test.2001.23.issue-2 |
| [19] | AHHH, DNShell v1.7[EB/OL]. (2015-10-11)[2016-10-02]. https://github.com/ahhh/Reverse_DNS_Shell. |
| [20] | MUDGE R, Cobalt strike 3.4-operational details[EB/OL]. (2016-07-29)[2016-09-17]. http://blog.cobaltstrike.com/cate-gory/cobalt-strike-2. |