网络安全之数据分析 101：数据外泄的检测

本文最初发布于 Towards Data Science 博客，经原作者 Pepe Berba 授权，由 InfoQ 中文站翻译并分享。

本文既是对最近 2019 年 Trend Micro 网络攻防抢旗赛 （Capture The Flag，CTF）中的 Wildcard 400 挑战解决方案的演练，也是关于网络安全监控的一些笔记心得。我建议你先到 Kaggle 尝试一下这些挑战。解决方案的所有实现都可以在 Kaggle 内核 中找到。

前提

假设你是中小型企业 XYZ 公司的网络安全管理员。你经常 使用网络流数据来发现异常安全事件 。本文这一挑战提供了一些关于流的聚合数据示例，并使用来自异常事件的应答来构建标记。

本文涉及的数据都是合成的，并非对典型的网络协议和行为进行建模而得。因此，应对这些挑战，无需深入了解网络协议。

我们要找什么？

这项挑战中的所有问题都与 Post-Exploitation 活动 有关，Post-Exploitation 活动构成了 网络杀伤链 的后半部分。

译注：Post-Exploitation，指攻陷目标中的某一台或者多台主机之后做的一些事情，包括但不限于：识别已经拿下主机的价值以及维持访问。主机对于攻击者来说是否具有一定的价值、具有多大的价值主要从以下两个个方面考虑：是否有敏感信息、数据，是否能够在后期的渗透中发挥价值。比如被攻陷的主机是否是组织中的关键人物、高层领导、系统管理员，被攻陷的主机是否能够尽可能的有内网不同网段的访问权限等等。

现代的网络安全方法并不仅仅局限于阻止网络被利用。利用只是攻击的第一步，最终目标通常是数据窃取。

注：这里不包括勒索软件攻击之类的攻击。

攻击者如何从最初的立足点到达你的数据？

1. 为了获取数据， 攻击者需要将数据外泄。
2. 为了使数据外泄， 攻击者需要接触到数据 （ 内网漫游 ）
3. 为了能够进行内网漫游， 攻击者需要与他们的立足点（命令和控制）进行协调 。

译注：内网漫游，Lateral Movement，亦称横向渗透攻击技术，是复杂网络攻击中广泛使用的一种技术，攻击者可以利用这些技术，以被攻陷的系统为跳板，访问其他主机，获取包括邮箱、共享文件夹或者凭证信息在内的敏感资源。攻击者可以利用这些敏感信息，进一步控制其他系统、提升权限或窃取更多有价值的凭证。借助此类攻击，攻击者最终可能获取域控的访问权限，完全控制基于 Windows 系统的基础设施或与业务相关的关键账户。

如果我们能够在这些阶段中的任何一个阶段发现并阻止攻击者，那么我们就可以认为这是一场胜利！

“预防是理想的，但检测是必须的。”—— Eric Cole 博士

当然，这是更复杂的事件链的简化版本。如果你想了解更多关于这方面的内容，可以查阅 ATT&CK 矩阵 。

数据外泄

数据外泄是数据盗窃的另一种说法。 从某一角度来说，数据必须从网络内部流向攻击者。

注：当然也有例外，比如物理上的数据外泄。

公然外泄

我们的知识产权正在大量流失。内部的一台机器被用来发送我们所有的部件设计。一台主机从企业发出的数据比其他主机多得多，它的 IP 地址是哪个？

在本文中，我们可以假设攻击者并没有试图隐藏其攻击行为。他们试图传输尽可能多的数据，而不会对数据传输设置限制。让我们来看看出站网络流量最大的主机。

我们将 13.37.84.125 标识为有问题的 IP，并查看其出站流量的分布，发现这是非典型的情况。

这是你可以发出的最简单的警报。查看你的出站流量的日常分布，并找出一个警报阈值。如果攻击者在一小时内将 50GB 的数据上传到他的 Google Drive，过了三天才被发现数据外泄，这将是一件非常尴尬的事情。

然而，你可能会发现有些异常值是正常的！ 作为异常值来讲，不一定就意味着存在恶意攻击。 你可以找到网络中比其他主机的出站流量都要大的主机，但却发现它们都是正常的。

假设你的公司使用的是 Web 代理服务器，并且需要通过该服务器来代理 HTTPS 流量。然后，我们就会期望这个代理服务器的流量比网络的其余部分大几个数量级。我们从中观察到的流量是数百个用户的 HTTPS 流量的组合。

在这种情况下，你应该记录这些特殊的服务器，并分别对它们进行分析。同时，你可能还需要检查那些生成或试图生成直接出站 HTTPS 流量的桌面，即使它们不消耗高带宽，因为它们也应该是通过代理出站的。

公余时间的活动

另一名攻击者有一个导出我们内部 Wiki 内容的作业计划。在企业的公余时间中，一台主机发送的数据比其他主机还要多。看看它的 IP 地址是什么？

通常，我们应该对工作时间和公余时间有一些概念。为了应对这一挑战，我们首先必须推断工作时间是哪个时段。

现在，我们已经确定了公司的工作时间，我们就可以只对 0:00~16:00 之间产生的流量进行筛选，并查看在公余时间里出站流量最大的主机。

这一次，我们发现 12.55.77.96 可能就是有问题的 IP 地址。我们查看了公余时间的总出站流量大小的分布，我们还发现，这是一个异常值。

只关注公余时间的流量非常重要，因为如果我们只关注整个出站流量的话，我们可能就会无法检测到这一异常。

很明显，我们应该分别对工作时间和公余时间分别进行建模。这是非常直观的，你期望在白天看到的活动类型，与晚上看到的有所不同。这包括周末和特殊假期。

这些公余时间也是你建立基准线的一个很好的起点。你对你的网络“背景辐射”有了一个概念。

糟糕的流量状况通常会在工作时间出现，在空余时间才有可能凸显出来。

你也有可能还会发现内部威胁。“在休假、生病期间或在非正常时间远程访问网络”，以及“未经授权在公余时间内进行工作”，都是内部威胁的行为指标。人们对物理监视更敏感；当周围没有人的时候，他们更有可能试图干坏事，而没有意识到他们的行为，在网络层面上对安全团队而言是显而易见的。

— Michael Collins

尽管如此，如果你去“狩猎”的话，你会发现有很多合法（可能是未公开的）的业务流程，比如那些试图在夜间卸货，以便在白天对业务产生最小影响的流程。例如，你可能会发现，数据库团队已计划每隔午夜 12 点将数据库每周备份到 Amazon S3 存储桶中。这些绝对是你应该能够检测到的东西。

使用通用协议进行隧道传输

一些攻击者抓取了所有员工和供应商的电子邮箱地址，并将其发送到通常保留给其他用途的频道。这类似于攻击者滥用 DNS 进行数据外泄。一台主机在某个端口上，从企业发送的数据比其他主机还要多。它的端口是哪个？

DNS 隧道是一种通过 DNS 协议的特性来进行数据外泄的技术。如果一个主机试图通过 DNS 进行数据外泄，那么我们预计，端口 53 的请求数量必将远远大于其他只使用 DNS 来解析域名的 IP 地址的主机。因此，我们所要寻找的，就是那个特定端口的异常流量。

实际上，我们可以使用与前面部分类似的方法，通过查看流量的主要来源，并根据端口的单变量分布来查看它们是否为异常值。然而，当你必须查看很多端口时，这种方法就不能很好地扩展到许多端口。

让我们首先看几个端口，我们看到它们中的大多数都是“不错”（也许是太好了），但具有不同的均值和方差。

在查看一些分布之后，它们看起来是呈钟型的正态分布，因此使用 Z 分数可能比较合适。然而，如果你发现分布呈高度偏斜，那么你可能需要进行一些转换，如对数转换，以使分布的形状更呈钟型。

在调查端口 124 的分布情况时，我们发现， 12.30.96.87 看起来像是那个有问题的 IP 地址。

如果我们将端口 124 的总出站流量与其他端口进行比较，我们就会发现，如果使用全局阈值，那么就无法检测到这一点。

如果只看长尾的话，那么也许就是这样的结果。

那么，我们要如何才能检测到这一点呢？与前述类似，这里有一个反复强调的主题：分别对不同类型的网络活动进行建模。如果你能在网络流量中识别出不同的组，那么就试着分别对它们进行分析。如果数据的分布相同，则更容易检测出异常值。

另外， 我们还应该考虑分析长尾。 如果你发现不常用的端口存在出站流量，那么你就应该去调查它究竟是怎么回事。如果它是合法用途的话，就将其记录下来。否则， 你一开始就不应该允许到未知端口的出站连接。

但是，对于 DNS 流量之类的协议，它们是必不可少的。因此，你将会发现这些端口都是对外开放的。类似于 Web 代理，为了使我们的工作更简单，你应该要求所有 DNS 查询都通过内部的 DNS 服务器进行，并在端口 53 上对内部 DNS 服务器之外的所有出站流量进行阻塞。通过查阅 DNS 服务器的日志，你就可以获得丰富的信息，从而使 DNS 隧道等检测技术变得更容易。你不必仅仅限制警报的频率和链接大小，因为你可以使用唯一子域的数量或查询的唯一域的数量。

如果你想了解更多关于 DNS 隧道的信息，你可以阅读 Akamai 的博文：《 DNS 数据外泄简介 》（ Introduction to DNS Data Exfiltration ）。另一种类似且有趣的隧道方式是通过 ICMP 。

保护你的数据

当你检测到出站流量中的数据外泄时，可能为时已晚，想到这一点，不由让人觉得有些可笑！对我们来说，要能够检测到较高的出站流量，攻击者必须先窃取大量数据。

为缓解这种情况，你必须考虑你真正关心的数据：

• 数据在哪里？
• 谁能访问这些数据？
• 他们如何访问这些数据？

比方说，一个攻击者想用从你的 SQL 数据库中窃取 50GB 的数据。他首先必须将 SQL 服务器的表转储到他的主机上，然后将这些表上传到外部某个云存储。

如果你能在以下任一情况下发出警报，你甚至可以做到在攻击者能够窃取数据之前就发现他：

• 未经授权的 SQL 数据库转储。
• 从 SQL 服务器传输的流量异常高。

例如，你可以查看 SQL 服务器通常执行的操作，并发现 SQL 服务器大部分流量通常与 Web 应用服务器、一些 ETL 进程，也许还有一些备份进程有关。然后，从 SQL 服务器到 SQL 管理工作站的大量数据传输可能被认为是异常的。

与其监视网络中的所有流量一发现“任何奇怪的东西”，还不如进行一些分析，你可以将经理集中在网络的几个组件上。

减少一些关键用户或系统的警报范围，可以使模型更加高效，并能够检测到更微妙的、影响更大的攻击。

作者介绍：

Pepe Berba，专注统计、安全和加密。拥有 SANS/GIAC Continuous Monitoring Certification（GMON）认证。曾在 SOC 工作，现正攻读数据科学硕士学位。

原文链接：

Data Analysis for CyberSecurity 101: Detecting Data Exfiltration