freeBuf
主站

分类

云安全 AI安全 开发安全 终端安全 数据安全 Web安全 基础安全 企业安全 关基安全 移动安全 系统安全 其他安全

特色

热点 工具 漏洞 人物志 活动 安全招聘 攻防演练 政策法规

点我创作

试试在FreeBuf发布您的第一篇文章 让安全圈留下您的足迹
我知道了

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

基于流量特征DNS隐蔽信道分析方法总结
FlowDefender 2022-01-26 11:29:46 410337
所属地 安徽省

一、     概述

隐蔽信道是指允许进程以危害系统安全策略的方式传输倍息的通信通道。隐蔽信道在公开的信道掩盖下,采用特殊的编码方式,传输非法或私密的信息而不被人发现。其广泛存在于操作系统、网络系统和应用系统中。对网络信息系统的安全构成了严重威胁。

在网络安全领域通常将隐蔽信道称为隐蔽通道,主要是利用网络协议设计中存在的一些缺陷,通过某种算法,将隐蔽信息嵌入到合法的网络数据流中。传统隐蔽通道主要依靠传输层和网络层协议实现。由于防火墙和IDS等网络安全设备的存在,单纯利用这两层构造的隐蔽通道很容易被检测出来。因此HTTP、 DNS、FTP等网络协议开始被隐蔽信道利用。

DNS协议是互联网最为关键的基础协议,也是互联网大部分服务和应用正常运转和实施的基础。 正是因为DNS协议的广泛性和不可替代性,基于DNS协议的隐蔽信道对网络安全构成了严重威胁。

二、DNS隐蔽信道基本原理

DNS信道主要由被控端和控制端两部分组成,其基本思想是,利用1台伪装的DNS服务器作为中转节点,利用DNS査询过程建立除蔽通道,实现数据传输。其基本结构如下图所示:

DNS隐蔽信道基本结构

1643165473_61f0b7211c4e11469d63b.png!small?1643165472774

DNS Tunneling可通过通信的方式分为直接和中继两种模式,直连指客户端直接和指定的DNS服务器地址直接通信,通过将数据编码封装在DNS协议中,特点:速度快,但限制较高(很多场景不允许指定DNS Server)。

中继指有DNS迭代查询的过程,特点较为隐蔽,但由于数据包到达目标DNS Server前需要经过多个节点,所以速度上较慢。

1643165786_61f0b85a8075cf270cf2d.png!small?1643165786133

图1 DNS隐蔽信道基本结构

假设目标主机IP为1.1.1.1,并在顶级域名服务器中将域名temp.com注册为该IP。内部主机(被控端)与目标主机(控制端)通过DNS隐蔽信道通信基本过程如下:

1、内部主机把要发送的数据作为主机名构造一个域名解析查询请求,例如,上传数据update,查询请求:updata. temp.com;

2、査询请求通过本地的DNS服务器,向顶级域名服务器查询得到temp.com域名对应的IP地址1.1.1.1;

3、本地的DNS服务器向1.1.1.1发送DNS査询请求: updata. temp.com;

4、目标主机(控制端)1.1.1.1从查询请求中,得到内部主机上传的数据;

5、目标主机将要传送给内部主机的非法数据作为DNS查询请求的响应信息发送给本地DNS服务器;

6、本地的DNS服务器将包含非法数据的查询结果返冋给内部主机。从而实现内部主机与外部控制主机间的双向通信。

2.2 DNS隐蔽信道编码

DNS隐蔽通道将上传的数裾作为DNS查询的主机名字段。在有关DNS协议的标准中规定单个域名的最大长度为253 Byte,域名的各部分之间用“.”分隔,各部分最大长度为63 Byte,毎个字符可以是字母(不区分大小写)、数字或连接符。

因此,在一个DNS查询报文中,最多可以携带242个字符,每个字符可以有37个不冋的取值。如果使用DNS隐蔽通道传递数据,则必须先对要传输的数据进行编码,使其满足标准的要求。

BASE-32、BASE-64、BASE-128编码

一种常用的编码策略是使BASE-32编码,每个字节编码5个比特的原始数据。在此编码方式下,一个DNS查询拫文最多可携带数据显为151 Byte.

DNS隐蔽通道通常使用TXT类型的数据记录来携带下传数据,TXT记录主要用来保存域名的附加文本信息,为了方便传输通常使用BASE-64编码对下传传输的数据进行编码,每个字节编码6个比特的原始数据。

BASE-128编码是基于BASE-64编码的一种编码方式。

二进制编码

在较新的RFC标准文档RFC 2181和RFC 4343中规定域名记录的各个部分都可以使用任何二进制字符,而不再局限与RFC 1034所规定的有限字符集合。使用二进制方式编码数据可以显著提高DNS隐蔽通道的效率,但在使用前必须在控制端和被控制端间协商确认双方都能够支持二进制编码,否则扔使用BASE-32等编码方式编码数据。

三、DNS隐蔽信道可行性检测方法

由于受到DNS协议规范的限制, DNS数据包长度有限,无法携带较多数据。若要满足文件传输、远程桌面控制等需求,则需要进行大量DNS报文传输。因此,可以通过对一个或多个DNS的请求和响应报文的有效载荷分析,检测DNS隐蔽信道;或者持续对多个DNS报文的大小、频率等属性进行统计分析进行DNS隐蔽信道检测。

3.1      DNS有效载荷分析

DNS隐蔽信道传输时,为了传输数据,控制端会在DNS请求和响应报文中放入尽可能多的数据,并且编码后的数据通常会含有较多的数字,因此,可以通过以下几方面进行检测:

主机名长度检测:通常DNS隐蔽隧道用上传数据作为主机名,所以DNS隐蔽信道的主机名一般较长,通常建议将主机名超过52个字符的DNS请求作为DNS隐蔽信道检测的一个指标;

利用域名的熵值:正常的DNS域名常常使用字典中的单同或其他有意义的字符串。而DNS隐蔽信道编码的域名一般具较高的熵,并会很均匀地使用字符集的各种字符。因此,可以把较高熵的 DNS域名作为识別DNS隐蔽信道的一个指标;

域名中数字占比及词频检测:合法的DNS域名较少使用数字,而经过编码的DNS域名会有很多数字,因此可以通过域名中数字字符占比进行DNS隐蔽信道检测;

下传数据非典型记录类型检测:上文提到DNS隐蔽信道下传数据通常使用TXT记录,也可以作为DNS隐蔽信道检测指标;

DNS信道中FQDN检测;

特征匹配法:某些DNS隐蔽信道也会含有特征字符串,可以使用DPI技术进行检测;

3.2      统计分析法

由于DNS报文的长度限制,为了传输非法数据,通常需要大量DNS请求及响应报文通过DNS隐蔽信道进行通信,可以对以下几个方面进行统计分析来检测DNS隐蔽信道。

不同IP的DNS流量总量:可以通过检测单个IP的DNS流量总量是否超过正常数量进行DNS隐蔽信道检测;

不同域名的DNS流量总量:检测方式与上一种类似,不过由于DNS隐蔽信道可能配置多个域名进行传输,因此可能存在识别率低问题;

DNS流速率及持续时间检测:DNS隐蔽信道的数据流通常持续时间较长、速率较快,也可以作为一个检测指标;

不存在关联的DNS请求检测: 正常的DNS请求通常在另一个请求之前,例如,HTTP请求,而DNS隐蔽信道通常没有与之关联的其他请求,因此也可以作为一个检测指标;

上面给出的几种DNS隐蔽信道检测方法,通常要多种检测指标一起使用,来弥补单一方法的不足。

3.3 总结方法

由于检测设备的限制、平台的实现方式、以上方法的总结(经测试),提出一套综合实现方法。根据目前应用审计日志的现况,更改了原始方法(下面只介绍现行的方法)。

根据2.1DNS有效载荷分析和2.2统计分析法归纳总结,搭建DNS隐秘隧道工具分析流量报文(目前比较活跃dns2tcp、iodine、dnscat2),抓取正常DNS流量报文对比分析。根据对DNS隧道工具分析,得到其原理相似结论,总结和验证了2.1和2.2方法特征。

具体的工具原理实现是基于DNS域名查询方式,具体见图2所示:

注册域名com

客户端Client B在内网环境下发起com,在本地服务器进行递归查询

查询不到,转各个顶级域名查询,寻找目标主机

需注意:减小注册域名影响、设备syslog日志还原DNS域名

1643165844_61f0b894c393d811003e7.png!small?1643165844480

图2 拓扑图

根据以上DNS隧道查询原理和先平台的特性,总结出:可用于域名进行区别的方法,对于提到的关于域名的区分特征如下:熵值、数字占比、词频等都可以用CNN方法获取其特征,并且还可以对深层次的特征和未知特征进行提取,具体实现过程参考实施案例。

四、     CNN深度学习方法

根据第三节进行实际方法论证,获取公开平台和本机的DNS正常流量报文,搭建DNS隐秘隧道获取流量报文,同时获取公开DNS隧道流量报文(人工验证)。验证2.1和2.2原理是否可行,叙述新方法可行性和实验过程。

4.1环境搭建

列举iodine、dns2tcp隧道工具进行分析。首先进行dns隧道环境搭建并抓包(此处省略)。图3和图4表示在使用工具时抓的流量报文,标黄部分表示请求域名。

列举抓取的正常DNS流量包,如图5和图6所示(qq和baidu)。

1643165936_61f0b8f07153af3b579c8.png!small?1643165936551

图3 Iodine流量报文

1643165944_61f0b8f8286363dd4aa2e.png!small?1643165944235

图4 dns2tcp流量报文

1643165951_61f0b8ffa5f9e04ed5592.png!small?1643165951417

图5 qq流量报文

1643165959_61f0b907201ddee64b011.png!small?1643165959025

图6 baidu流量报文

正常设备出现的问题整理如下:

实际域名内容:

paayk1va.abdcd.com

syslog日志显示:

\08paayk1va\05abdcd\03com

实际域名内容:

M56BgAABADE5NEVGOTMyRUIwRjhBODlEOTVCNzZEMDdDQkFBRDlEODI4NTg4ODk.=auth.ns.strage.lxw

syslog日志显示:

?M56BgAABADE5NEVGOTMyRUIwRjhBODlEOTVCNzZEMDdDQkFBRDlEODI4NTg4ODk\05=auth\02ns\06strage\03lxw

实际域名内容:

0aeby82\3122hb\276\356Y\326ok\374\333\340\3364ywZr\360\337c\276\302Xj\310\330\335q\315\346w\310\325TN\351\335\341b\356\346\306zR\325\352\344Zb\276\342\3604.gZ\353\323\310\333\345\304\334\362Z\306B\276cavF\2773m.abdcd.com

syslog日志显示:

>0aeby82\ca2hb\be\eeY\d6ok\fc\db\e0\de4ywZr\f0\dfc\be\c2Xj\c8\d8\ddq\cd\e6w\c8\d5TN\e9\dd\e1b\ee\e6\c6zR\d5\ea\e4Zb\be\e2\f04\15gZ\eb\d3\c8\db\e5\c4\dc\f2Z\c6B\becavF\bf3m\05abdcd\03com

注明:需要的显示:实际域名内容

针对以上问题已经向软件提交相关需求,由于时间问题,自己对以上出现的问题进行处理还原(目前看来可行)。

4.2 原理验证

域名熵值验证:根据以上抓的包,验证只使用熵值会误报(图7实例说明),利用多数据熵值平均值验证其是特征(有区分度)。

域名长度验证:单长度验证较明显会误报。

域名特殊字符验证:同上

域名词频验证:同上

1643166007_61f0b93725b7f9ef4d4f1.png!small?1643166006831

图7 计算信息熵

如果将这几种方法同时用于判断是否是DNS隐秘隧道流量(准确率提高),但几种方法之间的相互关系如何衡量(权重)是难题。

4.3 算法论证寻找权重

由于以上方法的论证和报文分析,如何将域名部分的复杂度、长度、特殊字符、词频、进行合理的系数分配,现在成了检查DNS隐秘隧道的关键点(syslog日志无法获取req/res时间间隔,记录类型、统计分析法中流量相关特征等(态感可结合))。

下面重点介绍下实现过程,结合图8流程图理解:

  • 获取的DNS隐秘隧道流量报文和正常的DNS流量报文进行解析成文本格式。根据以上分析方法,和现实情况,获取报文文本中请求域名部分。
  • 请求域名部分:去除一级域名部分,保留由DN隧道工具引起特殊编码部分。例如(=auth.ns.strage.lxw)去除strage.com部分,保留M56BgAABADE5NEVGOTMyRUIwRjhBODlEOTVCNzZEMDdDQkFBRDlEODI4NTg4ODk.=auth.ns部分;其中strage.com可匹配情报库。
  • 判断注册域名是否相同,相同则进行计数,不相同则进行再次运行计数。
  • 判断该域名是否是通过DNS隐秘隧道进行通信操作:对保留的域名部分进行数据处理;进该部分进行长度计数,并将DNS隧道流量报文文本中出现的域名进行列表标记({'+': 1, '-': 2, '/': 3, '.': 4, '1': 5, '0': 6, '3': 7, '2': 8, '5': 9, '4': 10, '7': 11, '6': 12, '9': 13, '8': 14, '=': 15, '\\': 16, 'a': 17, 'c': 18, 'b': 19, 'e': 20, 'd': 21, 'g': 22, 'f': 23, 'i': 24, 'h': 25, 'k': 26, 'j': 27, 'm': 28, 'l': 29, 'o': 30, 'n': 31, 'q': 32, 'p': 33, 's': 34, 'r': 35, 'u': 36, 't': 37, 'w': 38, 'v': 39, 'y': 40, 'x': 41, 'z': 42})利用数字来表示字符特征。
  • 通过算法进行数字特征学习(特征简单),浅层特征:可以对一串字符串的列表进行词频和复杂度比较,深层特征:例如特殊字符,提取出DNS隧道请求域名和DNS正常请求域名的特殊字符列表。
  • 通过CNN算法进行数据训练后,可有效对相关特征进行权重分配(model.fit()函数训练定义的CNN框架参数),自动提取域名特征并保存训练结果。通过提取特征权重参数保存模型进行对未知请求域名判断。为了更好的可解释性可使用传统的机器学习算法。
  • 未知域名的预测,先进行域名数据部分处理,去除一级注册域名;输入处理后域名部分进行模型预测(predict(url))通过feed_dict函数中输入进行模型参数查询,其次对输入域名进行处理(如训练过程中数据处理一致),利用模型中训练结果进行判断该域名和DNS隧道域名以及正常域名的相似度,例如:输入域名和模型对比结果如[0.985462,0.254868],可知:该域名是DNS隧道请求域名部分。
  • 判别结果进行计数操作,判断同一个注册域名可能是DNS隐秘隧道通信的可能性

1643166067_61f0b973942f12ce251c5.png!small?1643166067162

图8部分流程图(需要请留言私信)

4.4 代码核心部分

syslog日志处理过程:

1643166374_61f0baa6e7a9c5534735d.png!small?1643166374459

(部分代码,需要请留言私信)

注:由于实现方法的需要,对DNS应用审计的syslog日志进行数据处理。出现的三种惊恐进行了总结(过程见DNS隐秘隧道问题总结和解析.txt文档)。利用Python进行解析代码编写。

数据处理过程:

1643166460_61f0bafc1bca94db42b6b.png!small

(部分代码,需要请留言私信)

训练过程:1643166506_61f0bb2a23e9d86e8005d.png!small?1643166505745

(部分代码,需要请留言私信)

注明:整个过程的数据处理部分和训练部分,本文的第四部分已进行了详细的叙述。

五、传统方法+算法(决策树)

5.1 方法介绍:

由于以上原理,构造出特征数据,利用传统的决策树算法进行计算;具体过程如下:

将提出域名部分进行计算:第一,域名长度;第二,域名熵值;第三,域名中数字和特殊字符占比。利用通用算法计算出以上数值,利用决策树算法进行训练该三组的数据(利用现有的数据(2W))。

结果是:三组数据权重[0.30657039 0.25415164 0.43927797],从决策树算法保存文件中可获取:域名长度判断条件:21,域名熵值判断条件:3.062,域名中数字和特殊字符占比判断条件:0.303;超出各判断指标可判断是隐秘隧道。

数据计算过程:

1643166204_61f0b9fc6ed53f4d8bdd1.png!small?1643166204129

数据处理后结果:

1643166217_61f0ba0946fb68fdf5c3a.png!small?1643166217024

决策树方法(tree.DecisinTreeClassifier)

1643166270_61f0ba3e8157476e0a511.png!small?1643166270072

(部分代码,需要请留言私信)

5.2  话外篇:

上述方法如在大数据平台上使用,要考虑数据量和平台处理速度,为了提高可行性可使用以下方法+第五节方法。

根据文献查询和测试,总结简单特征方法:

DNS隐秘隧道对外传输数据时,最长的子域名往往在25字节以上,而合法域名请求中仅2%的子域名超过25个字符;但DNS隧道在空闲状态下的子域名通常小于10byte,与合法请求相似。

DNS会话在5min内回答数据总字节数分布:4%的合法DNS通信在5min内回答数据小于20kb,而DNS隐秘通道活跃时5min的下行数据通常在50kb以上。

# 渗透测试 # 黑客 # 数据安全 # 网络安全技术
本文为 FlowDefender 独立观点,未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件,请联系 FreeBuf 客服小蜜蜂(微信:freebee1024)
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
FlowDefender LV.3
网络安全贡献,信息安全守护
  • 6 文章数
  • 3 关注者
NPS隧道工具流量识别分析
2024-08-16
绕过PDO模块的SQL注入的思路
2021-11-26
“2021湖湘杯”网络安全大赛Web- easy will
2021-11-24
文章目录