[人工智能]基于机器学习和背景流量数据的加密恶意流量检测

一、加密流量现状

1.1 加密流量检测的必要性

在当今的网络设置中，安全传输层协议是为网络流量提供加密的一个主要协议。网络中的流量实际上是以比特流的形式存在，经过各类协议封装成不同格式的数据包之后，再在网络中进行传输。常见的网络协议有以下几类：

• 应用层协议：HTTP-超文本传输协议，定义了用户在客户端与Web服务器之间进行报文交换的形式，提供网页通信；DNS-域名系统，提供主机名转换到IP地址的域名解析服务；FTP-文件传输协议；
• 安全加密协议：TLS-传输层安全性（其前身为SSL-安全套接字层），提供加密通信；IPsec-IP安全协议，提供网络层安全性保证；
• 网络层和传输层协议：IP-网际协议，进行网络编址；ICMP-因特网控制报文协议，在主机和路由器之间传递控制消息，进行网络差错控制；UDP-用户数据报协议，提供不可靠、无连接的实时数据传输服务；TCP-传输控制协议，提供可靠、面向连接的数据传输服务。

本文关注的是以TLS/SSL协议加密的网络恶意流量的检测问题。TLS（Transport Layer Security）称为传输层安全性，SSL（Secure Sockets Layer）称为安全套接层，SSL是TLS的前身，两者都属于安全传输层协议，作用在网络体系中的传输层和应用层之间，用来提供客户端与服务器之间的加密通信。

上图显示的是使用Wireshark抓取的一条加密流的报文，我们从中选取一条TLS报文消息，从下图的解析结果中可以看到，TLS实际上就是通过在传输层之上新增了一个安全套接层来实现安全加密功能的。

近年来，合法的流量大多都已经采用了TLS标准。比如通过google、百度检索返回的网页都已经大规模使用了HTTPS。

• Google，《Chrome中的HTTPS加密情况》，2019年10月，Chrome加载网页中启用加密的比例已经达到了95%；
• 百度，近年来一直强制网站更换HTTPS，使用HTTPS的网站占比预计超过60%；
• …

注：HTTPS顾名思义，就是在HTTP的基础上应用了TLS/SSL协议。当你打开浏览器访问一个网页，该网页的url以这样的形式开头，就说明你正在使用这类安全传输层协议提供的加密服务。

与此同时，越来越多的恶意软件也开始采用TLS加密来伪装成看起来正常的流量，企图逃避安全检测。这一类恶意软件几乎覆盖了所有类型，包括特洛伊木马、勒索软件、感染式病毒、蠕虫病毒、下载器等。Gartner公司曾给出预测，直到2020年，仍然会有超过60%的企业无法有效解密HTTPS流量，但加密流量中将会隐藏超过70%的恶意软件。因此，实现加密恶意流量的有效检测是非常有必要的。

1.2 加密恶意流量的检测方法

现有的针对加密恶意流量的检测方法主要分为以下两类：

本文重点关注基于机器学习和背景流量数据的流量检测方法，在介绍该方法前需要了解以下几个概念：

• 深度包检测（DPI, Deep Packet Inspection）技术：通过解密来检查数据包中的数据内容来判断流量的性质；

• Data omnia：主张通过扩展流记录将与加密流相关的所有背景流量数据都包含在内；

• 背景流量数据：广义上说，除了数据内容之外其余与加密流相关的数据都可以视为背景流量数据。具体可以分为三类数据：

  • 可观察的元数据：具体包括头部字段中的源目的IP和端口，以及数据流的总字节数和数据包数等。因为流量加密操作只会加密数据内容而不会改变流量的统计特征；
  • TLS流头部数据：对于TLS加密流而言，它的头部字段是未被加密的，这意味着可以通过获取TLS头部字段中的一些参数来推断流量的性质；
  • 上下文数据：与加密流的某些属性相关联的其它协议数据，比如HTTP和DNS报文流。

因此，基于机器学习和背景流量数据的流量检测方法的工作流程可以简要概括如下：首先对前面提到的几类背景流量数据进行采集，然后基于这些数据对加密流量的特征进行分析，将分析得到的特征输入机器学习分类模型，基于分类模型来对加密流量进行正常或恶意的属性判定。这一方法所要完成的任务实际上就是一个二分类问题。

二、加密流量特征分析

这一部分主要基于第一部分中讨论的三类背景流量数据对加密流量的三大类特征展开分析。这三类特征分别为：

• 可观察的数据元统计特征：包括传统流数据、字节分布以及分组长度和分组到达时间间隔的序列；
• 未加密的TLS头部信息特征：包括基于客户端和服务器的特定TLS特征；
• 上下文数据特征：包括DNS和HTTP上下文流。

我们希望能够通过分析这些特征，最终得到这样一个1*n维的特征向量，便于输入到后续的机器学习分类器中。

2.1 可观察的数据元统计特征

2.1.1 传统流数据

• 流入和流出的字节数和数据包数（宏观上表现为上行流量和下行流量）
• 源端口和目的端口
• 流量总持续时间（以秒为单位）

像这类数值型特征，我们可以直接将原数值不加处理地添加到特征向量之中。

2.1.2 字节分布

字节分布是指数据包有效负载中遇到的每个字节值的计数，也就是计算一个字节可能取到的256个数值在数据流中出现的频次。选取这一特征是因为它能够提供大量的数据编码和数据填充的信息，很多恶意流量的非法行为往往就隐藏在这些信息中。将字节分布计数除以在分组的有效载荷中的总字节数，可以得到字节分布频率，进而近似得到字节分布概率，最终将这一特征表示为一个1*256维的字节分布概率序列。

2.1.3 分组长度和分组到达间隔时间的序列

在正常的网络环境中，大部分服务提供商会针对不同的业务类型对数据流中的数据包大小和发送频率进行处理，以此提高用户的体验。基于这一思想，我们考虑恶意软件在试图进行不同于正常业务类型的攻击行为时，是不是也会在这类时序特征上与正常流量表现出一定的差异呢？

对于这类特征，我们使用了马尔可夫链进行建模。在介绍马尔可夫链之前，我们需要先了解一下马尔可夫性质是什么。马尔可夫性质也叫无记忆性，这一性质表达的含义是指，一个随机过程的下一个状态，永远只由它当前的状态决定，而与它过去的任何状态都无关。如果一个随机过程满足马尔可夫性质，那么它就构成了一个马尔可夫链中的一环。

而在具体处理这类时序特征时，马尔可夫链起到的作用就是：首先它将序列中的每个值映射成一个状态（往往是一个多对一的映射，即多个值可能同时对应于一个状态），同时将这些值之间的时序关系映射成各个状态之间的转移行为，将这些转移行为存储在一个状态转移矩阵，再经过一系列归一化和扁平化处理，最终得到了一个状态转移概率序列。

对于分组长度，忽略零长度有效载荷（如ACK）和重传，数据包长度被视为UDP、TCP或ICMP数据包有效负载的大小，如果数据包文不是这三种类型之一，则将长度设置为IP数据包的大小。最大传输单元MTU一般为1500字节，因此上述协议数据包的有效负载区间为：TCP - (0, 1460B], UDP/ICMP - (0, 1472B], IP - (0, 1480B]。对于分组到达间隔时间，其分辨率为毫秒级。
在这类特征中，我们是将分组长度序列和分组到达间隔时间序列的值分别离散化为10个相同大小的“箱子”，表示10个不同的状态。

• 长度数据：其马尔可夫链有10个箱子，每个箱子150字节
• 时间数据：其马尔可夫链有10个箱子，每个箱子50ms

然后构造转移矩阵A，其中每一项A[i,j]表示第i和第j个箱子之间的转换次数。最后，对矩阵A的行进行归一化得到转移概率矩阵，再进行扁平化处理得到两个1*100维的状态转移概率序列，即最终的马尔可夫链。所有序列项将被用作后续机器学习算法的特征。

2.2 未加密的TLS头部信息特征

2.2.1 TLS协议

TLS及在此之前的SSL都是安全传输层协议，它位于传输层和应用层之间，
用于在两个通信应用程序之间提供安全通信，保证数据的完整性和保密性。TLS协议自顶向下由握手协议和记录协议共两层子协议组成。其中，TLS握手协议用于通信客户端和服务器之间协商安全参数，以建立起一个有状态连接进行数据传输。通过握手协商过程，通信双方需要确认使用的协议版本、加密算法、证书和会话密钥等信息。

对于未加密的TLS头部信息特征，我们主要关注TLS握手协议中的信息。因为TLS握手协议有两个特点：一是TLS虽然加密了明文，但并没有加密握手过程；二是在协议的版本更新过程中，基本的握手参数都不曾有过改变，这就意味着我们可以通过分析TLS握手协议中的一些参数来对流量属性进行合理的推测。

上图显示的是TLS v1.2定义的一个握手过程。其中包含一些关键的消息流：

1. 客户端发送Client Hello消息，可以从中获取到客户端提供的参数信息，包括：

   • 列出的密码套件列表（Cipher Suites）
     • 密钥交换算法、加密算法
     • 报文认证消息码（MAC）算法
   • 支持的扩展列表（Extensions）：提供额外功能或设定

2. 服务器发送Server Hello消息，可以从中获取到服务器给出的参数信息，包括选定的密码套件和TLS扩展。

   下图是一条加密流中的Server Hello消息报文，可以从中看到服务器选定的密码套件，并且每个密码套件都有一个与之对应的十六进制数值。图中Cipher Suite字段表达的含义是：基于TLS协议，密钥交换算法选用RSA，加密算法选用RC4（密钥长度为128位），哈希算法选用MD5，这个密码套件对应的值为0x0004。

   

3. 服务器发送Certificate消息，其中含有服务器签发的证书信息。如下图所示，完整的证书信息会显示在消息流中的SignedCertificate字段中，包括证书签名算法、签发机构、证书有效期、证书主题等。

   

4. 密钥交换消息，可以从Client Key Exchange消息中获取到密码套件中设定的密钥交换算法的一些参数。

因此，在具体的特征提取过程中，我们可以从客户端和服务器两个角度来展开。

2.2.2 基于客户端的特定TLS特征

通过统计分析，我们可以发现基于客户端的以下特征在正常流量和恶意流量中存在着明显的差异。这些特征为：

• 客户端在密钥交换算法中选用的公钥长度：从Client Key Exchange消息中收集的，表示为单个整数值
• 客户端列出的密码套件列表：从Client Hello消息中收集，取其十六进制代码组成特定长度的二进制向量
• 客户端支持的扩展列表：与密码套件列表类似

下图为针对上述特征的统计分析图。

注：图中蓝色表示正常流量，红色表示恶意流量，横坐标表示该特征的不同取值，纵坐标表示流所占的百分比。

其中，公钥长度可以直接以数值形式表示，而密码套件和TLS扩展则分别以一个二进制向量的形式存储，向量中的1和0表示当前加密流中是否存在该位置所代表的密码套件或TLS扩展。

2.2.3 基于服务器的特定TLS特征

通过统计分析，我们可以发现基于服务器的以下特征在正常流量和恶意流量中存在着明显的差异。这些特征为：

• 服务器选定的密码套件：从Server Hello消息中收集
• 服务器选定的TLS扩展：与密码套件类似
• 服务器签发的证书信息：从Certificate消息中收集，包含证书的数量、SAN名称数量、有效天数以及是否有自签名证书

注：SAN是指主题备用名称，用来补充证书主题的缺失信息；恶意流量数据中使用自签名证书的TLS服务器的频率比良性数据大约高出一个数量级。

下图为针对上述特征的统计分析图。

其中，选定的TLS扩展列表同样可以采用二进制向量的特征表示形式来表示，而其余三个数值型特征可以直接添加到特征向量之中。

2.3 上下文数据特征

2.3.1 DNS上下文流

DNS上下文流是指基于目标IP地址与TLS相关的DNS响应，它提供加密流使用的地址，以及与名称关联的TTL，同时能够补充加密流中可能缺失的一些信息。比如，DNS响应报文中提供了目的IP与域名的对应关系，而从签名的角度来看，DNS提供域名的动态性是低于它关联的IP地址的，因此这个信息能够提供一个强大的黑名单机制（记录那些已经标记为恶意的流量都倾向于访问哪些域名）。

基于上述思想，我们首先对DNS上下文流特征进行统计分析，最后发现以下特征在正常流量和恶意流量中存在着明显的差异：

• 域名长度
• DNS响应返回的IP地址数
• DNS TTL值：一条域名解析记录在DNS服务器上的缓存时间（32个最常见TTL值的列表和一个“其他”选项）
• 域名在Alexa榜单的排名：用来评价网站访问热度的一个常用指标

注：域名在Alexa榜单的排名实际上是一个第三方白名单的机制，选取这一特征的原因是考虑到恶意流量关联的域名其访问热度往往是比较低的。

下图为针对上述特征的统计分析图。

对于前三类数值类特征，无需处理可以直接添加到特征向量中，而域名在Alexa榜的排名情况则需通过一个1*6维的二进制向量来表示，这6个维度分别表示域名是否在Alexa榜的前100/1000/10000/100000/1000000以及不在榜单中的情况，然后这一特征会为每个域名选择相应的类别，属于哪一类就将该类所在的位置标记为1。

2.3.2 HTTP上下文流

HTTP上下文流是指在TLS流 5 min窗口内由相同源IP地址发出的所有HTTP流。恶意软件可能利用HTTP头部的某些字段（比如content-type, server等）来发起一些恶意活动，这说明HTTP字段能够很好地指示一些恶意活动。

基于这样的思想，我们同样选取了以下能够反映正常流量和恶意流量之间差异性的HTTP上下文流特征：

• 流入和流出HTTP字段的种类：有一个二进制变量的特征向量表示所有观察到的HTTP头，如果任何HTTP流具有特定的标头值，则无论其他HTTP流如何，该特征都将为1
• HTTP特定字段（Content-Type、Server、Code）的取值

下图为针对上述特征的统计分析图。

对于这两类特征我们同样采取二进制向量的形式予以表示。

至此，我们就已经完成了加密流量特征分析的整个过程，最终得到了这样一个1*n维的特征向量。需要说明的是，不管是正常流量还是恶意流量，我们都可以通过前面的特征分析过程得到这样的一个特征向量。而n的具体取值还要取决于实际使用的加密流量数据格式。

三、实验与评估

这一部分介绍一个基于真实数据集的加密流量分类实验。

3.1 数据集

这个实验采用的数据集分为黑白样本两个部分，所有实验数据都是在经过TLS握手完整性和上下文数据完整性两重过滤得到的无缺失数据。

• 黑样本——恶意数据集
  • 13542个同时具有DNS和HTTP上下文的恶意TLS流；
  • 从2016年1月到4月，在商业沙箱环境中收集；
  • 在这一环境中，用户可以提交可疑的可执行文件，每个提交的样品可运行5 min，随后由环境收集并存储每个样本的完整数据包捕获。
• 白样本——良性数据集
  • 42927个同时具有DNS和HTTP上下文的良性TLS流；
  • 2016年4月的5天内，在大型企业网络中收集。

3.2 分类模型

实验使用逻辑回归分类器，对所有分类结果都有L1正则化惩罚（L1-logistic）。

L1-logistic回归模型实际上就是一种使用了sigmoid函数作为联系函数的广义线性模型。而L1正则化主要通过在损失函数中添加L1正则化项，从而产生稀疏模型来达到防止过拟合的目的。研究发现这种分类器非常有效，并且对网络数据特征分类表现非常好。

对于输入特征$x$，输出标记$y$，假设线性回归模型预测值$z=h(x)={\omega }^{T}x+b$，则logistic回归模型满足：$$y=\frac{1}{1+e^{?z}}$$

在此基础上，带L1正则化的损失函数为：$$J(\omega )=?[\frac{1}{m}\sum _{i=0}^m{y}^{(i)}\log h(x^{(i)})+(1?y^{(i)})\log (1?h(x^{(i)}))]+\lambda \Vert \omega {\Vert }_1$$

3.3 实验过程

在本次实验提供的数据集下，利用第二部分介绍的加密流量特征分析方法，得到一个800维左右的特征向量，并且所有数据特征都会被归一化为零均值和单位方差的形式。同时，所有分类结果都使用了十折交叉验证：通过划分10次9:1的训练集和验证集，获得10次不同的分类结果，最后取10次分类结果的平均指标进行评估。

3.4 评估结果

实验结果以不同的特征组合和总体准确度两个维度来展示，如下图所示。总体准确度是指所有正确分类的样本在总样本所占的比例。可以看到，从单独使用未加密的TLS头部信息特征，到加入可观察的数据元统计特征，再到最终加入上下文数据特征，流量分类的总体准确度是在不断提升的。

实验结果表明，仅使用加密流中未加密的TLS头部信息，能够实现96.335%的总精度；使用来自加密流本身SPLT+BD+TLS的信息，能够实现99.933%的总精度；使用与加密流的所有背景数据，最终能够实现99.993%的总精度。

四、总结与展望

4.1 总结

本文介绍的基于机器学习和背景流量数据的加密恶意流量检测方法，它的核心在于基于data omnia思想的特征提取：通过收集和关联与加密流相关的所有背景流量数据，发现并提取出在黑白样本存在明显差异的特征（包括三大类：可观察的数据元统计特征、未加密的TLS头部信息特征和上下文数据特征），并将其用于加密流量的分类任务。

4.2 展望

对于基于机器学习和背景流量数据的加密恶意流量检测方法的后续研究，我有以下几点展望：

1. 在真实情况下加密流量中经常会出现字段信息缺失的现象，比如在TLS会话恢复的情况下，证书将不存在。因此需要通过实验去验证不同的特征处理方式或特征组合会达到什么样的分类效果；
2. 实验中用到的黑样本数据都是在沙箱中采集的恶意软件通过加密通信产生的流量，这只是加密恶意流量中的一种表现形式，我们前面分析的特征在这一类恶意流量中的表现很可能是高度近似的，这也解释了实验结果中最终分类的总体准确度达到了99.99%以上的原因。这就迫使我们后续去关注加密恶意流量的其它表现形式（一是加密通道中的恶意攻击流量，如CC攻击；二是恶意或非法加密应用的通信流量，如非法VPN），通过实验去验证使用当前特征对其它形式的加密流量进行分类是否仍然能够达到较好的效果；
3. 后续可以尝试进行多种机器学习分类模型（比如随机森林、XGBoost等）的对比与验证，去探索进一步提升检测效果的可能。

参考文献

[1] Anderson B, McGrew D. Identifying encrypted malware traffic with contextual flow data[C]//Proceedings of the 2016 ACM workshop on artificial intelligence and security. 2016: 35-46.
[2] Korczyński M, Duda A. Markov chain fingerprinting to classify encrypted traffic[C]//IEEE INFOCOM 2014-IEEE Conference on Computer Communications. IEEE, 2014: 781-789.
[3] Anderson B, Paul S, McGrew D. Deciphering malware’s use of TLS (without decryption)[J]. Journal of Computer Virology and Hacking Techniques, 2018, 14(3): 195-211.