基于DNS的隐蔽通道流量检测
2013-01-06章思宇邹福泰王鲁华陈铭
章思宇，邹福泰，王鲁华，陈铭
（1.上海交通大学 信息安全工程学院，上海 200240；2.国家计算机网络与信息安全管理中心，北京 100017；3.上海交通大学 密西根学院，上海 200240）
1 引言
网络隐蔽通道是攻击者绕过网络安全策略进行数据传输的重要途径，而DNS（域名系统）则是实现应用层隐蔽通道的常用手段。
DNS是互联网最为关键的基础设施之一，将域名与IP地址相互映射。由于其在网络运行中的重要地位，DNS协议几乎不会被防火墙策略阻拦，即使在一个内部网络中，也需要架设 DNS服务器进行主机名解析。DNS是一个全球分布的数据库，域名递归解析需要本地 DNS服务器与互联网上其他服务器通信，这也就为基于 DNS协议构建隐蔽通道创造了条件。通过域名递归解析的 DNS隐蔽通道客户端只需请求本地 DNS服务器，而不必与通道的另一方直接通信，大大增加了访问控制策略制定的难度。
过去几年的研究已提出多种 DNS隐蔽通信方法，且有成熟的软件实现，应用于 IP或 TCP隧道、木马和僵尸网络的控制通信。建设无线城市部署的 Wi-Fi热点，用户认证前通常已开放DNS服务，利用 DNS隧道可绕过认证自由访问互联网，对网络运营商造成损失。而在信息安全要求较高的组织，隐蔽通道则可能造成机密信息泄露等严重的安全事件。文献[1]提出了利用DNS传输文件和封装SSH隧道的方法。文献[2～4]对现有的DNS隧道实现在带宽、延迟和可靠性上进行了比较，实验在低延迟网络中达到了500kbit/s的吞吐量。文献[5]利用二进制编码域名进一步提高隧道带宽，文献[6]通过 DNS数据分组松弛空间数据注入，实现对DNS解析器和安全工具透明的被动DNS隧道。
相对于层出不穷的 DNS隐蔽通道传输和隐藏手段，相应的检测技术仍存在诸多不足。目前，对应用层隐蔽通道检测的研究大多针对HTTP和SSH协议[7,8]，检测DNS隐蔽通道的方法只有如下几类。
1) 请求量、长子域名统计。DNSBL（DNS黑名单）等频繁请求同一域中大量子域名的情况在实际环境中较为常见，这一方法易产生误报，同时又忽略低频率、低带宽的隐蔽通道。文献[5]提出伪造源地址分散通道的方法，也能绕过这一检测机制，适合构建泄密和远程控制类的非对称通道。
2) 特殊资源记录类型统计。该方法检测 DNS隐蔽通道常用的TXT和NULL资源记录，Iodine[9]等使用A记录请求即会使此方法失效。
3) Born等人提出的域名字符频率分析[10,11]。该检测方法同样存在对DNSBL等服务的误判，因为DNSBL的子域名一般为IP地址或MD5散列值，不符合英语单词的字符频率特性。文献[10, 11]实验中合法流量产自Alexa排名前百万网站的爬虫，仅代表Web服务的域名特征，与实际DNS流量特性差异较大。此外，字符频率分析未考虑文献[5]在域名中包含二进制数据的隐蔽通道。
上述 DNS隐蔽通道检测方法均只适用于基于域名递归解析的通道，而尚未解决隐藏在 UDP/53流量中客户端与服务器直接通信的通道，如文献[6]的数据注入、Iodine的Raw UDP隧道[9]等。如何设计一种适合各种类型 DNS隐蔽通道检测要求、不依赖于特定的通道设计模式假定的 DNS隐蔽通道检测方法，成为亟待解决的问题。
本文提出了一种在 DNS流量中全面检测各种类型 DNS隐蔽通道的方法，利用机器学习的分类器对合法请求和隐蔽通信特征进行判别。本文的贡献如下。
1) 对DNS隐蔽通道的构建方法进行了总结，全面分析了 DNS隐蔽通信流量的数据分组特征及会话连接的统计特性。
2) 实验验证了本文的算法能够识别训练涉及的全部 22种隐蔽通道，并且具有识别未经训练的新型 DNS隐蔽通道的能力，解决了现有检测算法在可检测的通道类型上的局限性。
3) 本文的算法可应用于实时DNS流量分析，并且实现了相应的检测系统，在上海交通大学校园网进行了部署测试，检测到多个实际存在的隐蔽通道并进行了分析。
2 DNS隐蔽通道
DNS协议的隐蔽通道可分为2类：第一类利用 DNS的递归域名解析，在本文中称为基于域名的隐蔽通道；另一类需要客户端与隐蔽通道服务器直接通信，在本文中称为基于服务器的隐蔽通道。
2.1 基于域名的DNS隐蔽通道
攻击者注册一个域名，并将其域名服务器（NS）设置为隐蔽通道的服务器。隐蔽通道客户端向任意一台 DNS递归服务器请求该域下子域名，均可实现与服务器通信。
客户端向服务器发送的数据编码为域名的子域名字符串。DNS域名标签允许包含英文字母、数字和连字符，且不区分大小写，因此，DNS隐蔽通道通常将数据进行Base32编码。服务器返回的数据则包含在DNS回答的资源记录中，其中最常用的资源记录类型是NULL和TXT，前者可包含任意长的二进制数据，后者则要求为可打印字符。A记录（IPv4地址）、MX记录（邮件交换）和AAAA记录（IPv6地址）的请求在互联网DNS流量中所占比例最大，尽管带宽利用率低于NULL/TXT，但它们仍为注重隐蔽性的DNS隧道的首选。
基于域名的DNS隐蔽通道程序实现，有IP over DNS 隧道：NSTX[12]、Iodine[9]、DNSCat[13]以及 TCP over DNS 隧 道 ： OzyManDNS[1]、 Dns2tcp[14]、TCP-over-DNS[15]和 Heyoka[5]等。
2.2 基于服务器的DNS隐蔽通道
当网络安全策略允许主机与任意一台 DNS服务器通信时，可使用基于服务器的DNS隐蔽通道。攻击者将基于UDP的服务（如OpenVPN）运行在53端口，从客户端直接建立连接。Iodine发现客户端能与隧道域名 NS直接通信时，也会自动转入Raw UDP模式。在此模式下，整个UDP载荷均为隐蔽通道数据，通信效率大幅提升。然而，由于这些报文不是有效的 DNS消息，流量分析工具解析这些报文时会出现格式异常（malformed），从而引起怀疑。文献[6]在现有 DNS消息末尾的松弛空间注入数据的方法，不影响 DNS服务器和流量分析工具对数据分组的解析，可解决上述Raw UDP隧道的缺陷。
3 检测方法
3.1 定义DNS数据连接
为了判断各个客户端的域名请求行为是否存在隐蔽通信的可能，本文对 DNS流量中的“数据连接”进行定义，以确定各个消息的通信双方。
对截获的UDP/53数据分组作DNS协议解析，如果解析中无任何错误发生，并且解析完毕时指针位于 UDP载荷的末尾，表明该数据分组是一个无注入的合法DNS报文。本文将这类数据分组的DNS连接双方定义为
如果将数据分组解析为 DNS时发生错误，或者解析完毕后指针未处于 UDP载荷末尾，表明该数据分组可能为Raw UDP隧道，或存在松弛空间数据注入。这类数据分组的通信双方直接取其 IP地址
3.2 数据分组特征
通过对DNS隐蔽通道构造方法和流量的分析，本文从 DNS数据分组中提取了一系列可用于区别DNS隐蔽通道的特征。
3.2.1 数据分组解析特征
如3.1节所述，对采集的数据分组进行DNS协议解析时若出现格式异常或有注入数据，则可能为基于服务器的 DNS隐蔽通道。对于数据注入的情况，本文计算注入数据长度，即协议解析完毕时指针与 UDP载荷末尾的距离，作为表示松弛空间注入量的特征参数。
DNS隐蔽通道在数据传输时，充分利用 DNS协议各字段或Raw UDP报文允许的最大长度，以提高带宽利用率、减少数据分组数量。基于域名的通道，其上行和下行数据分别存储在 DNS消息的问题段和回答段，增加了 DNS消息本身的长度。基于服务器的隧道，由于无法将其作为 DNS报文解析，本文将 UDP载荷长度也作为数据分组解析特征之一。
3.2.2 请求域名特征
请求域名特征针对基于域名的隐蔽通道。DNS问题段除 QNAME以外的字段只能容纳4byte数据，因此，基于域名的通道上行数据通常只能存储在QNAME中，提取QNAME的特征：标签数量和子域名长度。DNS协议限制域名最长为255byte，每个标签不超过63byte，因此，DNS隐蔽通道将上行数据编码为长域名之后，必须分割为多个标签。
文献[5]在域名中使用二进制数据以提高传输效率，也是QNAME的特征之一。实验发现大多数DNS隐蔽通道使用了DNS协议允许的字符集以外的字符。对于使用二进制编码的子域名，请求中所包含的信息量与子域名长度相等；仅使用 DNS协议允许的字符，则必须Base32编码，QNAME包含的信息量等于子域名长度的60%。
3.2.3 DNS消息特征
编码域名中使用前向指针是文献[6]提出的提高数据注入检测难度的手段，前向指针在一般的DNS解析器和服务器实现中几乎不会被采用，因而是否存在前向指针是识别隐蔽通道的特征之一。隐蔽性较高的隧道的A记录请求，一般采用CNAME（规范名称）记录来携带较多的下行数据，本文将回答含CNAME记录作为第二个DNS消息特征。
基于域名的隐蔽通道，下行数据存储在资源记录中，尤其是回答段的资源记录中，因此，本文计算回答段资源记录数据长度（RDLENGTH）之和，以及整个报文包括授权和附加段在内全部资源记录RDLENGTH之和，作为表示DNS回答所容纳的隧道下行数据量的2个参数。
3.2.4 特征总结
通过对数据分组3类特征的分析，总共提取了12个数据分组特征用于区别合法DNS请求与隐蔽通信，总结如表1所示。
表1 数据分组特征
3.3 DNS数据连接特征
仅依据一个数据分组的特征难以判断是否为DNS隐蔽通信，因此，算法对属于同一数据连接的数据分组特征进行统计分析，再依据数据连接的统计特性进行分类器判别。
如表2所示，DNS数据连接的统计特征分为3类：特征集FS1包含一定时间段内该连接传入和传出的数据分组总数；FS2统计了该连接中具有前向指针、CNAME记录，以及QNAME含二进制数据的特殊报文数量；特征集FS3是对数据分组特征F2、F3、F4、F5、F6、F8、F11、F12的统计，计算该连接所有数据分组上述参数的均值、最大值、最小值及求和。其中，数据分组长度特征（F2,F3,F4）对传出和传入2个方向分别统计；请求域名特征（F5,F6,F8）只对 DNS请求报文统计，因为回答报文与请求中的QNAME保持完全一致；资源记录特征F11和F12仅在DNS回答报文中有意义，因此仅对回答进行统计。
表2 DNS数据连接特征集
特征集FS3共含42个特征，主要代表了DNS请求与应答报文、域名、资源记录的平均长度和变化范围，以及双向的数据传输量。利用合法 DNS流量样本及DNS隧道流量样本对FS3中特征分布进行分析，其中隧道流量样本含50%的活跃传输的隧道及50%空闲、保持连接状态的隧道。如图1(a)所示，DNS隐蔽通道对外传输数据时，最长的子域名往往在25个字符以上，而合法域名请求中仅2%的子域名超过25个字符；但是，DNS隧道在空闲状态下的子域名通常小于10byte，与合法请求相似。图1(b)显示了DNS会话在5min内回答数据总字节数分布，98.4%的合法DNS通信在5min内的回答数据小于20KB，而DNS隐蔽通道活跃时5min的下行数据通常在50KB以上。
图1 DNS数据连接统计特征分布
3.4 检测系统流程
本文提出的DNS隐蔽通道检测流程如图2所示。DNS流量探针监测所有的UDP/53流量。对于DNS探针采集到的数据分组，计算其12个数据分组特征参数，并进行初步数据分组过滤，去除明显不符合隐蔽通道特征的DNS报文。
图2 DNS隐蔽通道检测流程
研究了 DNS隐蔽通信的必备要素之后，本文确定了如下的初步过滤规则
符合该条件，即无格式异常、无数据注入、子域名长度不超过 4字符且回答资源记录总长不超过1byte的，将被数据分组过滤模块丢弃。对余下的数据分组，根据3.1节的定义，识别其所属DNS数据连接的通信双方，然后将该数据分组特征更新至DNS连接特征统计表，以计算 3.3节提出的 DNS数据连接统计特征。
一个DNS数据连接在DNS连接特征统计表中跟踪监测的时间达到统计时限T后，进入判别为合法或隐蔽通信的流程。如果其数据分组速率达到Rm，则将DNS数据连接特征集FS1、FS2和FS3的全部特征输入一个机器学习的分类器，应用预先训练好的分类模型，判断是否为 DNS 隐蔽通道。对数据分组速率低于Rm的连接，认为其请求频率对隐蔽通信而言过小，直接判定为合法的DNS请求。
系统参数T决定了隐蔽通信开始到系统响应的最大延迟，提高T的取值可增强对低速通道的数据分组采集，但将延长响应时间。Rm取决于安全策略所能容忍的最大隐蔽通道带宽。单个DNS请求携带的最大上行数据DUM小于QNAME长度，即DUM＜ 2 55。DNS请求与应答分组成对出现，分析隐蔽信道的泄密风险时，上行带宽。本文实验及系统原型实现采用参数T= 5 min 及Rm=4byte/min，考虑到BU＜ 5 12byte/min对泄密与远程控制等应用均太小，而 5min的监测足够对低速率通道采集至少10次请求用于统计分析。实验将比较几种常用的分类器模型在本算法中应用时的分类效果。
4 实验与评估
4.1 训练数据采集
对 DNS数据连接分类器进行训练和评估，需采集一系列合法DNS流量样本，以及DNS隐蔽通道的流量样本。实验使用的合法流量样本取自上海交通大学校园网的DNS流量，在1h的流量截取文件中，提取单一客户端对同一纯域名请求次数最多的 6 890个 DNS数据连接，并确认了其均不属于DNS隐蔽通信。
为了获得 DNS隐蔽通道样本，实验运行了多个现有的 DNS隧道软件，截取其产生的流量。测试的DNS隧道程序包括Iodine、Dns2tcp、DNSCat、tcp-over-dns和 PSUDP。对于支持多种资源记录类型的Iodine、Dns2tcp和DNSCat，分别截取了其在NULL、TXT、SRV、MX、CNAME、KEY等资源记录，以及Raw UDP模式下的流量。
为使训练产生的模型既能识别数据传输中的大吞吐量隐蔽通道，又可检测低频交互、小流量的通道，对上述DNS隧道软件的实验中，分别截取其活动状态（有数据通过隧道传输）和空闲状态（隧道保持连接）时的流量。隧道传输的数据采用 Web浏览器自动加载网页的方法产生。PSUDP采用在已有DNS流量中注入数据的被动工作方式，自身不产生DNS请求，因此，PSUDP的实验，以1次/秒的频率发送DNS请求，使PSUDP能够进行数据传输。
上述DNS隧道程序的实验总共涵盖22种隐蔽通信模式。实验对每种模式分别截取6个时间段，产生总共132个DNS隐蔽通道流量样本（如表3所示）。
表3 训练样本集
4.2 分类器模型比较
本文使用 Weka[16]软件，对 J48决策树、朴素贝叶斯（Naïve Bayes）和逻辑回归（LR, logistic regression）算法进行比较，分类器模型采用十折交叉验证进行测试。
分类器模型比较结果如表4所示，J48决策树和LR算法的模型正检率（true positive rate）相同，均为95.6%。朴素贝叶斯算法的准确率明显较低J48和LR算法，因此不适用于本文研究的场景。LR算法的误报率（false positive rate）低于决策树算法，而决策树算法ROC曲线（如图3所示）区域面积（AUC）最大，即其平均性能最优。
J48决策树算法在实验比较中取得了较为准确的分类结果，并且该算法效率高，输出的模型直观明了。J48算法采用自顶向下、分而治之的的决策树构造方法，选择信息增益率最大的属性进行分裂，递归直至决策树各节点样本均为相同类别或无属性可分裂。决策树构造过程中对分类信息增益最大的属性进行了选择，模型实际使用的特征数量较少，在实时流量处理时可降低资源开销。因此，在后续的实验及实时流量检测系统的实现中，采用了J48决策树作为机器学习的分类器算法。
表4 分类器模型比较
图3 分类模型ROC曲线
4.3 特征评估
在不同的特征选取的情况下，分别建立分类器模型进行比较，采用全样本集和十折交叉验证评估，各个模型的误报率均在0.15%至0.30%的范围内，因此着重比较其漏检率（false negative rate）。由于FS3包含的特征数量众多，进一步将FS3分为报文解析特征统计（FS3PP）、请求域名特征统计（FS3DN）和资源记录特征统计（FS3RR）3部分进行了评估，不同特征选取时模型漏检率如图4所示。结果表明FS3和全部特征集（ALL）均取得了较低的漏检率，而FS1和FS2的漏检率较高。
图4 各类特征集下的漏检率
与本文算法相比，传统的基于高请求频率判断DNS隐蔽通道的方法，仅仅依赖于统计同一客户端对同一纯域名的请求量，即仅使用本文算法的特征集FS1中的特征，而缺乏应用层深入分析产生的特征集FS2和FS3。图5对比了合法请求与隐蔽通道样本的报文数量分布，DNS隧道程序在保持连接和低速率传输时的请求频率与合法应用难以区分，34.5%的隧道样本5min报文数小于150，而有17.2%的合法样本报文数超过该值。根据此参数设定阈值，为使误报率保持在合理范围内，将不可避免地忽略低带宽的隐蔽通信。因此，特征评估实验利用FS1特征集建立决策树模型的漏检率达30%左右。
图5 同域名查询频率分布
特征集FS2分析含前向指针、CNAME记录和二进制域名的流量异常，符合标准规范实现的DNS隐蔽通道避免产生上述特殊报文，因此，仅依据特征集FS2能够检测的隐蔽通道类型较少，在特征评估实验中的漏检率高达50%以上。
特征集FS3对协议报文尺寸、QNAME特征和资源记录特征的统计特性分析能够准确区分合法与隐蔽通道。如图 4所示，根据交叉验证评价，FS3PP、FS3DN和FS3RR分别建立模型的漏检率为7.1%、4.4%和 12.4%。3.3节提取的全部特征中，对J48算法分类信息增益率最大的特征为 max(F8)，即 QNAME所携带的最大信息量，因而其所属的FS3DN分类准确率高于FS3PP与FS3RR。特征集FS1对报文数量的计数np与FS3PP协议报文尺寸求和∑Li在报文尺寸Li一定的前提下呈正相关性；FS2检测的 CNAME和二进制域名特殊报文，则在FS3RR的回答资源记录尺寸及FS3DN的 QNAME信息量中对应地进行了计算。从而，FS3部分携带了FS1与FS2特征所含的信息，依据FS3建立的决策树模型取得了与全特征集相同的准确率。
4.4 未知隐蔽通道模式检测
为验证决策树模型的检测能力，对训练使用的隐蔽通道模式重新截取新的流量，测试结果表明该模型能检出全部22种已知的DNS隐蔽通道。进一步地，本文实验检验模型对训练未涉及的“未知”DNS隐蔽通道的检测能力。实验另外测试了 3个DNS隧道程序，分别为OzyManDNS、Heyoka，以及作者自行设计的DNS隐蔽通道NSChan。NSChan使用 Base32域名编码，下行数据采用了与其他隧道均不同的设计，将数据编码为多个IPv4地址，通过A记录返回。对于上述3个未经训练的DNS通道程序，检测结果如表5所示。
模型成功检测活动和空闲状态的 OzyManDNS与Heyoka，以及活动状态下的NSChan。模型未能检测空闲状态的 NSChan，对其流量分析后发现，两方面因素导致了漏检的产生。首先，NSChan在空闲、保持连接状态下的请求频率fidle= 0 .2，低于训练使用的 Iodine的fidle= 0 .33，以及 DNSCat、Dns2tcp和tcp-over-dns的1.0、2.0和6.0，从而，其 5min对外报文数no=Tfidle= 6 0恰好低于决策树模型在该参数的阈值68，被判为合法。其次，本文作者实现NSChan时，对封装报文头部长度未作优化，空闲时子域名长度与其他隧道活跃时相当，使决策树在请求报文最小长度节点处进入了适用于活跃隧道的分支。尽管如此，NSChan在数据传输时，不可避免地出现频率提高及域名长度增加的隐蔽通信特征，活动状态依然无法躲避本算法检测。作为改进方案，模型训练时可添加将隧道程序fidle参数减小后采集的样本，截取报文量接近系统参数Rm（如3.4节）的流量，以增强模型对请求频率低至下界fm= 2/Rm的隧道的检测。
表5 检测训练集以外的DNS隐蔽通道
4.5 实际环境评估
本文对 DNS隐蔽通道检测算法进行了实现，处理实时的 DNS流量发现其中的隐蔽通信行为。将检测系统在上海交通大学网络中心的 DNS流量监控服务器上进行了部署，检验算法在实际环境中的效果。系统监测的DNS请求来自约30万个源IP地址，DNS请求量约3 000次/秒。
流量经数据分组过滤后，DNS数据连接统计表中暂存的记录为11万条，内存使用最大50MB。经过持续10h的运行和检测，实际环境测试结果如表6所示。系统共产生了30万个样本进入分类器，其中310个被检出的样本确认属于隐蔽通信，系统总共检测到7个独立的隐蔽通道的存在。
表6 实际环境测试结果
图6 CipherTrust DNS隧道流量分析
在误报方面，分类器对样本的误报率为0.107%，10h内误报的客户端IP地址为38个，误报的域名仅23个。DNS流量进入分类器前，经过了初步数据分组过滤、DNS数据连接过滤2个过滤器，前者滤除了27.5%的合法DNS报文，后者则将约91%的DNS会话直接判为合法而无需经过分类器判别。2个过滤器使得最终进入分类器判决的会话数与系统输入的DNS流量相比大幅减少，因此，系统对全部流量的误报率远低于表6中分类器模块的误报率。
对检测系统的误报分析发现，系统的误报主要来自于异常的客户端程序实现，如29%的误报产生自某主机以5s为周期对a.root-servers.net的重复请求，由于该请求产生的回答含大量授权和附加段资源记录，被认为是隧道下行流量。对于DNSBL服务，模型训练中已学习的以MD5或IP地址为前缀的DNSBL在实际环境部署时没有任何误报，但在实际流量中误检了2个以URL Encoding编码的网址为前缀的 DNSBL域名：ph.bdaph.com和html.ph.bdrbl.com。这 2个域名由 BitDefender（比特梵德，反病毒软件公司）注册，网址经过 URL编码，再用减号替代百分号后作为子域名字串（如表7所示）。该DNSBL子域名长度比MD5和IP地址大得多，因而被本系统误检。
表7 URL编码的DNSBL示例
在对本系统检测到的DNS隐蔽通道的分析中，也发现了 DNS隧道在一些合法软件中的应用。McAfee（麦克菲）的软件利用DNS隧道技术将用户电子邮件的部分信息传送到服务器，用于其声望评分系统。其 DNS隧道利用域名 ciphertrust.net，抓包分析显示其DNS请求符合典型的DNS隐蔽通信模式（如图6所示）。
5 结束语
本文通过对 DNS隐蔽通道构建方法的研究和总结，提出了基于机器学习的检测算法，能够全面检测利用域名递归解析和服务器直接通信的多种DNS隐蔽通道模型，解决了现有算法在通道类型上的局限性。经过实验比较，本文选择利用J48决策树分类器对 DNS数据连接的特征进行判别。分类器模型可检测训练涉及的全部22种隐蔽通道模式，以及多种未经训练的新型隐蔽通道。本文实现了在实时 DNS流量中检测隐蔽通道的系统，在校园网环境中进行了部署测试，成功检测到7个隐蔽通道的存在，并探讨了实际运行中发现的一些特殊的DNS隧道的应用。
[1] KAMINSKY D.The black OPS of DNS[A].Proceedings of the Black Hat USA 2004[C].Las Vegas, 2004.
[2] LEIJENHORST T V, CHIN K-W, LOWE D.On the viability and performance of DNS tunneling[A].Proceedings of the 5th International Conference on Information Technology and Applications[C].Cairns,Australia, 2008.
[3] NUSSBAUM L, NEYRON P, RICHARD O.On robust covert channels inside DNS[A].Proceedings of the 24th IFIP International Security Conference[C].Pafos, Cyprus, 2009.
[4] MERLO A, PAPALEO G, VENEZIANO S,et al.A comparative performance evaluation of DNS tunneling tools[A].Proceedings of the 5th International Conference on Complex, Intelligent, and Software Intensive Systems[C].Seoul, Korea, 2011.84-91.
[5] REVELLI A, LEIDECKER N.Introducing heyoka: DNS tunneling 2.0[A].Proceedings of the SOURCE Conference Boston[C].Boston,2009.
[6] BORN K.PSUDP: a passive approach to network-wide covert communication[A].Proceedings of the Black Hat USA 2010[C].Las Vegas, 2010.
[7] ZANDER S, ARMITAGE G, BRANCH P.A survey of covert channels and countermeasures in computer network protocols[J].Communications Surveys & Tutorials, IEEE, 2007, 9 (3): 44-57.
[8] DUSI M, CROTTI M, GRINGOLI F,et al.Tunnel hunter: detecting application-layer tunnels with statistical fingerprinting[J].Computer Networks, 2009, 53 (1): 81-97.
[9] ANDERSSON B, EKMAN E.Iodine[EB/OL].http://code.kryo.se/iodine/, 2011.
[10] BORN K, GUSTAFSON D.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.
[11] BORN K, GUSTAFSON D.Detecting DNS tunnels using character frequency analysis[A].Proceedings of the 9th Annual Security Conference[C].Las Vegas, Nevada, 2010.
[12] GIL T M.NSTX (IP-over-DNS)[EB/OL].http://thomer.com/ howtos/nstx.html.
[13] PIETRASZEK T.DNScat[EB/OL].http://tadek.pietraszek.org/ projects/DNScat/, 2011.
[14] DEMBOUR O.Dns2tcp[EB/OL].http://www.hsc.fr/ressources/ outils/dns2tcp/index.html.en, 2011.
[15] VALENZUELA T.Tcp-over-dns[EB/OL].http://analogbit.com/ software/tcp-over-dns, 2011.
[16] HALL M, FRANK E, HOLMES G,et al.The WEKA data mining software: an update[J].SIGKDD Explorations, 2009, 11 (1): 10-18.
