序言
在我们 Detonate 系列的第一篇文章中，我们介绍了 Detonate 系统以及我们在 Elastic 中使用它的目的。我们还讨论了它在评估我们安全工件的性能时为我们的团队带来的好处。
在本文中，我们将分解 Detonate 的工作原理，并深入研究其技术实现。这包括我们如何在实践中创建这个沙箱环境、支持整个管道的技术，以及我们如何向管道提交信息和从管道读取信息。
对其他关于 Detonate 的文章感兴趣吗？请查看第一部分 - 点击，点击... 砰！，其中我们介绍了 Detonate、构建它的原因、Detonate 的工作原理、案例研究以及功效测试。
架构
下面是 Detonate 端到端架构的高级概述。
整个系统由一系列消息队列和 Python 工作进程组成。当 API 服务器接受一个请求时（请求中只有样本文件哈希值这样少的信息），就会创建 Detonate 任务。然后，任务从一个队列移动到另一个队列，由工作进程沿途执行各种操作。
服务器和工作进程在 Amazon ECS 上的容器中运行。该管道也可以使用 Docker Compose 在本地启动，用于早期开发和功能测试。
API 服务器
Detonate API 服务器是一个 FastAPI Python 应用程序，它接受各种执行目标请求：样本的哈希值、原生命令（在 bash 或 Powershell 中，带或不带参数）和上传的文件。该服务器还公开用于从 Elastic 集群获取警报和原始代理遥测数据的端点。
API 文档由 FastAPI 自动生成，并被纳入我们的全局 API 架构中。
与 API 服务器交互 - CLI
我们构建了一个自定义 Python CLI（命令行界面）工具，用于与我们的 Detonate 服务器交互。CLI 工具是使用 Python 库 click 以及 rich 构建的，以便在终端窗口中获得漂亮的格式化体验。该工具对于调试管道特别有用，因为它也可以针对本地管道设置运行。该工具使用 Poetry 进行安装和运行，Poetry 是我们用于管理依赖项和运行脚本的首选工具。
❯ DETONATE_CLI_API_ROOT_URL="${API_ENDPOINT_URL}" \
DETONATE_CLI_API_AUTH_HEADER="${API_KEY}" \
poetry run cli \
--hash "${MY_FILE_HASH}"与 API 服务器交互 - Web UI
在内部，我们托管一个名为“保护门户”（使用 Elastic UI 组件编写）的站点，以协助我们的团队进行研究。为了获得与 Detonate API 的更互动体验，我们在门户中构建了一个页面来与之交互。除了提交任务外，Web UI 还允许用户查看所有引爆的馈送和每个任务的详细信息。
可以展开每个任务以查看其完整详细信息。我们提供了在引爆期间收集的数据和遥测的链接。
与 API 服务器交互 - HTTP 客户端
如果我们的用户想要自定义他们与 Detonate API 交互的方式，他们也可以使用他们选择的 HTTP 客户端（例如 curl、httpie 等）运行命令。这允许他们在脚本中添加引爆，或作为他们自己的工作流末尾的最终步骤。
队列
该管道构建在一系列队列和工作进程之上。由于对消息队列引擎的要求非常基本，我们决定使用 Amazon SQS。使用 SQS 等流行服务的众多好处之一是可以使用我们可以构建的开源资源和库。例如，在本地运行管道时，我们使用 softwaremill/elasticmq Docker 镜像作为队列引擎。
队列使用 Terraform 代码进行配置和部署，该代码涵盖我们所有的生产和暂存基础设施。
工作进程
每个工作进程都是一个 Python 脚本，它既充当队列使用者，又充当队列生产者。这些工作进程是在我们自定义的微型框架中实现的，该框架内置了用于错误处理、重试和监视的样板代码。我们的基本工作进程很容易扩展，这使我们能够添加新的工作进程，并在出现其他要求时改进现有的工作进程。
对于监视，我们使用 Elastic APM 可观察性解决方案。它非常强大，使我们能够了解执行流程，并使调试管道问题变得轻而易举。在下面，我们可以看到 APM UI 中 Detonate 任务在工作进程之间移动
这些软件和基础设施组件为我们提供了执行引爆所需的提交、执行和数据收集的所有内容。
引爆
该管道可以在 Windows、Linux 和 macOS 虚拟机 (VM) 中执行命令和样本。对于 Windows 和 Linux 环境，我们使用 Google Compute Engine 中的 VM 实例。借助各种公共映像，我们可以配置具有不同版本 Windows、Debian、Ubuntu、CentOS 和 RHEL 的沙箱环境。
对于 macOS 环境，我们使用 AWS 中的 mac1.metal 实例和来自 Veertu 的按需 macOS VM 配置解决方案，称为 Anka。Anka 使我们能够快速轮换在同一 macOS 裸机实例上运行的多个 macOS VM。
Detonate 目前专注于我们的操作系统覆盖范围、可扩展性以及从管道收集上下文相关数据。目前正在研究和设计将复杂的反分析对策纳入 Detonate 中。
VM 配置
为了使我们在 VM 中的占用空间保持最小，我们使用启动脚本进行配置。最小化我们的占用空间非常重要，因为我们在 VM 中的活动包含在我们收集的事件中，这使得运行后的分析更加复杂。对于 Windows 和 Linux VM，使用以 Powershell 和 bash 编写的 GCP 启动脚本来配置系统；对于 macOS VM，我们编写了自定义的 bash 和 AppleScript 脚本。
启动脚本执行以下步骤
- 配置系统。例如，禁用 MS Defender、在 MS Office 中启用宏执行、禁用自动系统更新等。
- 下载并安装 Elastic 代理。该脚本验证代理是否已正确注册到 Fleet Server，并且策略已应用。
- 下载并引爆样本，或执行一组命令。执行在后台进程中进行，而主脚本收集 STDOUT / STDERR 数据流并休眠 N 秒。
- 从文件系统中收集文件（如果需要），并将它们上传到存储中。这使我们能够在引爆完成后进行任何额外的验证或调试。
虚拟机生命周期由 start_vm 和 stop_vm 工作进程管理。由于我们预期某些引爆会破坏启动脚本的执行流程（例如，在勒索软件的情况下），因此每个虚拟机都设置了 TTL，这使得 stop_vm 工作进程能够删除不再使用的虚拟机。
这种全新的方法，使用启动脚本来配置引爆所需的一切，使我们能够使用 Google Cloud 公共镜像目录中供应商提供的虚拟机镜像，而无需进行任何修改！
网络配置
我们引爆的一些样本是恶意的，可能会产生恶意流量，例如网络扫描、C2 回调等。为了保护我们的云资源和供应商的基础设施安全，我们限制了虚拟机的所有出站流量。这些实例被放置在一个锁定的 VPC 中，该 VPC 仅允许与预定义的目标列表建立出站连接。我们使用 Google Cloud 的 路由 和 防火墙规则，以及 AWS 的 安全组 来限制 VPC 中的流量流。
我们还在 GCE 中使用了 VPC 流日志。这些日志使我们能够看到沙箱虚拟机在我们的 VPC 中发起的私有网络流量。
遥测收集
为了观察引爆，我们使用 Elastic Agent，并安装了 Elastic Defend 集成，所有保护都处于“检测”（而不是“保护”）模式。这使我们能够尽可能多地从虚拟机收集信息，同时允许 Elastic Security 解决方案生成警报和检测。
我们使用此架构涵盖了两个用例：我们可以验证保护（比较针对不同操作系统版本、代理版本、部署的安全工件等生成的事件和警报），并同时收集遥测数据进行分析（针对新的样本或新型恶意软件）。收集的所有数据都保存在持久的 Elastic 集群中，供我们的研究人员使用。
生产环境运行
最近，我们完成了 Detonate 管道在生产环境中运行整整一个月，在多个数据集成负载下，同时通过 UI 为内部用户提供服务。我们迄今为止的记录是一天内进行了 1034 次引爆，到目前为止，我们还没有看到任何可扩展性或可靠性问题。
目前，大部分提交的内容都是特定于 Windows 的样本。我们也在努力增加对 Linux 和 macOS 的覆盖范围 – 请继续关注即将发布的研究博客文章！
我们不断改进对各种文件类型的支持，确保引爆尽可能接近预期的触发行为。
查看上个月的引爆情况，我们发现大多数任务在 13 分钟内完成（中位数为 515 秒）。此时间包括任务数据准备、虚拟机配置和清理、样本执行以及引爆后处理。
这仍然是该服务的早期阶段，因此看到异常值是正常的。由于任务中的大部分时间都花费在等待虚拟机配置上，因此我们可以通过使用自定义虚拟机镜像、预启动虚拟机实例以及优化启动脚本来提高整体执行时间。
下一步是什么？
现在您已经了解了 Detonate 的工作原理，我们接下来的文章将深入探讨 Detonate 的更详细的用例。我们将进一步探讨这些引爆如何转化为保护更多用户，包括我们 Elastic 的用户！