来源：《Machine Learning for Encrypted Malware Traffic Classification：Accounting for Noisy Labels and Non-Stationarity》KDD 2017 Applied Data Science Paper， KDD’17, August 13–17, 2017, Halifax, NS, Canada
1介绍
通过被动地监控网络流量来发现威胁在部署的易用性方面有很多优势，在工业和学术文献中都有研究[32,35]。除了被动的监视需求之外，还需要准确地识别基于会话级别的恶意网络流量，因为它允许网络设备(比如路由器和交换机)有效地执行网络策略。为了使潜在的解决方案更加复杂，使用加密的网络流量的百分比一直在快速增长，而且，正如预期的那样，恶意软件作者也利用这种趋势来规避基于签名的检测。使用中间人对交通进行解密，然后利用传统技术来检测威胁并不理想，这是由于隐私问题，而且由于法律和技术原因，这并不总是可行的。
考虑到以上的约束条件，在加密的网络会话的元数据上进行机器学习是一种自然的解决方案。虽然不直接用于检测加密交通中的威胁，但这一机器学习和网络元数据的基本公式已经得到了充分的研究[6,24,31]。不幸的是，这些解决方案在现实世界的威胁检测中作为可行的方法已经变得非常缓慢，一些批评家已经正确地质疑了机器学习在这个问题领域的适用性[25,37]。
在对新的威胁上仍然保持着很高的正确识别率同时，保持适当的误识率，一直是困难的。在本文中，我们重点介绍了这一情况的两个主要原因:网络数据中不准确的实际情况和非平稳性。最直接的方法是使用一个沙箱环境来运行恶意软件，并收集样本的相关数据包捕获文件，以获取有正标记的恶意数据，并监控网络，并收集所有负标记的、无害的数据的连接。对于良性的情况，即使使用IP黑名单过滤数据集[13]，通常会有不可忽略的网络流量百分比，这将被认为是可疑的。对于恶意的案例，恶意软件样本经常执行连通性检查，或其他固有的良性活动。要识别所有这些情况几乎是不可能的，在使用监督学习时必须考虑到这一点。
影响分类精度的第二个因素是网络数据的非平稳特性。在用户层面上，网站和服务的受欢迎程度经常发生变化。例如，将云托管存储从box.com转移到google.com/drive/将对所观察到的加密传输模式产生影响。在网络和协议级别上，当新协议如TLS 1.3[34]或HTTP/2[3]发布时，可以引入变更点。这些修改可以明显地影响握手和应用层消息的结构，影响用于分类的数据特性。
我们设计并进行了实验，测试六种常见的算法在面对不准确的真实情况和在网络安全域中演进的数据流时的表现。我们发现，一些算法更容易受到加密网络流量分类的挑战。例如，我们展示了逻辑回归的性能随着时间的变化是不稳定的，而标准的支持向量机在网络流量和损坏的标签的情况下表现不佳。
除了研究几种算法之外，我们还提供了一个用于此问题的标准特性集与自定义特性集之间的比较，该特性集是在领域专家的帮助下开发的。对可用特征的迭代经常被忽略，但典型地提供最显著的性能提高[19]。进一步遵循这一思路，我们发现修改数据收集过程来生成专家指导的、更具表达性的特性集对测试的所有分类器的性能都有显著影响。例如，使用更具表达性的特性集的线性回归在我们所考虑的所有标准上使用标准网络连接表示[39]的情况下，很容易胜过随机森林方法。总的来说，对数据的深入理解和对数据生成过程的迭代是非常有价值的。
另外值得注意的是，额外的数据特性可以减轻一些关于精确地真相标签的负担。恶意软件通常通过访问一个标准网站来执行连通性检查，例如https://www.google.com。使用标准的特征表示，这是不可能区别于一个良性客户端到https://www.google.com。但是，如果包含关于连接的其他特性，比如TLS握手元数据，那么就可以区分这两种情况，因为TLS特性提供了关于原始客户机的信息。
最后，考虑到网络安全领域所带来的现实挑战以及我们在实验中所观察到的有效性，我们针对算法和数据特征提供了具体的建议，以正确和有力地对加密的恶意软件通信进行分类。我们的分析是基于从一个商业恶意软件沙箱和两个地理上截然不同的大型企业网络中收集的数百万个TLS加密会话。我们将重点放在传输层安全(TLS)协议[18]，因为它被广泛采用。
2、背景
TLS[18]是确保许多明文应用程序协议的主要协议，例如，HTTPS是对TLS的明文HTTP协议。图1提供了一个简单的TLS会话的图形表示。客户端首先发送一个ClientHello消息，该消息为服务器提供了一个cipher套件列表和客户端支持的一组TLS扩展。cipher套件列表是由客户端的优先级排序的，每个密码套件定义了一组用于TLS操作的加密算法。扩展的集合向服务器提供了附加的信息，以方便扩展的功能，例如，服务器名称指示扩展指示客户端试图连接的服务器的主机名，这对于虚拟主机非常重要。如第4节所述，本文使用的所有TLS数据特性都取自未加密的ClientHello消息。
在ClientHello之后，服务器发送一个ServerHello消息，其中包含所选的密码套件，从客户的报价列表中选择，它定义了一组加密算法，用于保护交换的应用程序数据。ServerHello消息还包含一个服务器支持的扩展列表，其中这个列表是客户端支持的一个子集。此时，服务器还发送包含服务器证书链的证书消息，该证书链可用于对服务器进行身份验证。
然后客户端发送一个ClientKeyExchange消息，该消息建立了TLS会话的premaster secret。然后，客户端和服务器交换ChangeCipherSpec消息，指示将来的消息将通过协商的加密参数进行加密。最后，客户机和服务器开始交换应用程序数据。在图1中，红色文本表示未加密的消息，蓝色文本表示加密消息。当前的TLS 1.2握手协议提供了许多有趣的、未加密的信息。为了增强隐私，TLS 1.3将对更多的握手进行加密，例如，证书消息将被加密，但是本文中使用的数据特性仍然可用。为了简洁起见，省略了许多重要的细节，但是相关的RFC提供了完整的规范[18,34]。
由于TLS对许多特定于应用程序的特性进行了加密，因此使得传统的深度数据包检查变得不可行的，许多研究人员利用侧向通道信息对TLS通信进行了有用的推断[38]。这些数据特性通常是由加密会话的单个包长度和包的跨到达时间构造的。通常使用的特性包括数据包长度的平均值，n-gram或Markov链的特性，这些特征来自于数据包长度的序列，或者类似于时间信息的构造特征。
4、数据
4.1收集环境和工具。
我们为我们的数据收集利用了三个环境:两个企业网络，每个都有500- 1000个活跃用户和一个恶意软件分析沙箱。对于企业网络，我们被动地实时监控所有出站网络流量。我们使用HTTP用户代理来确定这些网络中45%的机器运行Windows 7和Windows 10, 40%的机器运行OS X 10。剩下的机器要么是移动设备，要么运行各种各样的Linux或Windows XP。这些网络中大约50%的端点是未管理的。
恶意软件分析沙箱允许用户提交可疑的可执行文件，并且每个提交的样本被允许运行5分钟。为每个示例收集并存储完整的包捕获。由于硬件的限制，这些示例只允许在Windows XP或Windows 7(32位或64位)的虚拟机中运行5分钟。用户选择操作系统，默认为Windows XP。我们收集的恶意软件流量中有75%是使用Windows XP，剩下的样本使用的是Windows 7的变种。
这些数据收集方法很简单，但是可能会导致我们的实验中出现一些偏差，我们现在已经明确地说明了这一点。这两个企业网络位于不同的大陆上，但都是同一家公司的分支机构。因此，虽然网络流量具有许多独特的地理特征，但由于类似的端点配置，也会有许多重叠的会话。因为恶意软件沙箱将样本运行时间限制为5分钟，因此在此初始窗口之后的任何活动都不会被捕获。另外，任何与选定的Windows版本不兼容或缺乏关键依赖的恶意软件样本都不会运行。
我们编写了一个基于libpcapc的开源包，Joy[30]，来处理实时通信和包捕获文件。Joy将网络数据转换为JSON格式，其中包含所有相关的数据特性，这使得用标准工具分析这些数据变得微不足道。对于所有的实验，我们仅使用完成了完全TLS握手并且发送了应用数据的TLS会话。Joy匿名化了企业流量的所有内部IP地址，我们没有保留未处理的原始数据。
4.2数据集
表1提供了我们收集的、按月分割的数据的摘要。我们从2015年8月开始收集恶意pcap文件，每月收集1-3万次TLS会话。我们在2016年4月开始监控一个企业网络，Ent1。我们在2016年9月开始监测第二种，地理上不同的企业网络，Ent2。我们使用一个受欢迎的黑名单来过滤企业流量[13]，其中黑名单每天都在更新。尽管如此，一些恶意的会话无疑仍然存在于企业数据集中。我们将在第6节中进一步研究这一结果。最后，对于每个企业网络，我们随机抽取数据，而不进行替换，以创建最终的数据集。
5数据特性
我们在实验中引入了一个额外的轴:由领域专家开发的更具表现力的特性集的效果。与机器学习算法相结合的一组标准网络流量特征的变化已经用于上一工作[6,39]。这些特性通常来自IPFIX[15]或NetFlow[14]，可以通过传统的网络设备导出。增强的特性获得的效率较低，但也可以通过网络设备导出[29]。所有特征归一化，均为零均值和单位方差。标准和增强集分别有22个和319个数据特性。
5.1标准
对于标准的特性集，我们使用了文献中常见的特性，特别是Williams等人提出的工作。这22个特征包括最小、平均、最大值和标准偏差:
•客户->服务器的数据包长度
•服务器->客户端包长度
•客户->服务器包inter-arrival
•服务器->客户端包inter-arrival
网络连接的协议和连接时间，客户－>服务器数据包数量和大小，以及服务器数量－>客户端数据包数量和大小也被使用。Williams等[39]在其附录C中提供了这些特性的完整列表:特征表。虽然大多数这些特性都存在于标准的NetFlow记录中，但是数据包大小的信息却不是。为了保持一致性，我们在实验中包含了从包大小中提取的特性。
5.2增强
增强的特性集通过合并单独的包长度和时间来扩展以前的工作，它提供了应用程序的行为概要的更详细的视图，以及TLS元数据，它提供了应用程序使用TLS库的信息。为了提供一种直观感受，在TLS恶意软件检测的背景下，领域专家用来确定哪些特性是有趣的，bestafera，一个以keylogging和data exfilter而闻名的特殊恶意软件样本，在我们描述深度增强的特性时呈现。
5.2.1数据包长度。图2显示了两个不同TLS会话的包长度和间隔:图2a中的谷歌搜索和图2b中的bestafera启动连接。x轴表示时间，向上的线表示从客户机发送到服务器的数据包的大小，而向下的行表示从服务器发送到客户机的数据包的大小。红线代表未加密的消息，黑线是加密的application_data记录的大小。
谷歌的搜索遵循了一个典型的模式:客户的初始请求是在一个小的出站包里，然后是大量的mtu大小的数据包的响应。在用户还在输入的时候，谷歌试图自动完成搜索，这是几个交替的数据包。一旦谷歌对自动完成的结果有充分的信心，它就发送了一组更新的结果，结果显示的是另一组mtu大小的数据包的响应。bestafera的服务器通过发送包含自签名证书的包开始通信，这可以被看作是图2b中的第一个向下的、细的红线。在握手之后，客户端立即开始向服务器发送数据。有个停顿，然后服务器发送了一个定时指令和控制信息。包长度和到达时间不能对会话的内容提供深入的了解，但它们确实有助于推断会话的行为方面。
对于特定的特性，我们记录一个会话的前50个包的有效负载的大小。然后我们将这些大小表示为一阶马尔可夫链。我们假设了一个1500字节的MTU，并创建了10个150字节的状态，并估计了不同收集的数据包大小状态之间的转换概率。
5.2.2 TLS握手的元数据。TLS ClientHello消息提供了两个特别有趣的信息片段，可以用来区分不同的TLS库和应用程序。客户端为服务器提供了一个适合客户端排序的合适的密码套件列表。每个密码套件定义了一组方法，例如加密算法和伪随机函数，它们将需要使用TLS建立连接和传输数据。客户端还可以为一组TLS扩展做广告，这些扩展可以为服务器提供密钥交换所需的参数，例如[8]。
所提供的密码套件可以在提供的唯一密码套件的数量和每个密码套件的优选组件中变化。类似地，扩展列表根据连接的上下文变化。因为大多数应用程序通常有不同的优先级，这些列表可以并且在实践中包含大量的可区别信息。举个例子，桌面浏览器倾向于更重量级，更安全的加密算法，移动应用程序更倾向于更高效的加密算法，而默认的密码套件提供了与TLS库捆绑的客户端，通常提供更广泛的密码套件来帮助测试服务器配置。
大多数用户级应用程序，以及通过扩展在野生环境中看到的大量TLS连接，使用流行的TLS库，如BoringSSL (Chrome)、NSS (Firefox)或SChannel (Internet Explorer)。这些应用程序通常具有独特的TLS指纹，因为开发人员将修改库的默认值以优化其应用程序。为了更加明确，默认的OpenSSL 1.0.1r客户端(s_client)的TLS指纹将很可能与使用OpenSSL 1.0.1r库进行通信的应用程序不同。这也是为什么bestafera的TLS指纹既有趣又独特:它使用OpenSSL 1.0.1r的默认设置来创建TLS连接。
在这个工作中，我们从提供的密码套件和扩展列表中获得特性。同样，这些特性特别有趣，因为它们提供了启动会话的客户机的信息，即，两个相同的会话可以基于客户端应用程序进行区分。我们在数据中观察了197个独特的密码套件和扩展。我们创建了一个长度为197的二进制向量，如果TLS会话支持相关的密码套件或扩展，则将一个1分配给适当的条目。
