前言
在 Detonate 系列的第一篇文章中，我们介绍了 Detonate 系统以及我们在 Elastic 中使用它的用途。 我们还讨论了它在评估我们的安全工件的性能时为我们的团队带来的好处。
在本出版物中，我们将分解 Detonate 的工作原理并深入研究技术实现。 这包括我们如何在实践中创建这个沙盒环境、支持整个管道的技术，以及我们如何向管道提交信息和从管道读取信息。
对 Detonate 上的其他帖子感兴趣？ 查看第 1 部分 - 咔哒，咔哒…轰隆！ 我们在这里介绍 Detonate、我们构建它的原因、探索 Detonate 的工作原理、描述案例研究并讨论功效测试。
架构
以下是 Detonate 端到端架构的高层概述。
整个系统由一系列消息队列和 Python 工作程序组成。 当 API 服务器接受包含与样本文件哈希一样少的信息的请求时，就会创建引爆任务。 然后，任务从一个队列移动到另一个队列，由沿途执行各种操作的工作人员接收。
服务器和工作程序在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安装和运行，这是我们管理依赖项和运行脚本的首选工具。
❯ 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
在内部，我们托管一个名为 Protections Portal（使用Elastic UI组件编写）的网站来协助我们的团队进行研究。 为了获得与 Detonate API 更具交互性的体验，我们在门户中构建了一个页面来与其进行交互。 除了提交任务之外，Web UI 还允许用户查看所有爆炸的反馈和每个任务的详细信息。
每个任务都可以展开以查看其全部详细信息。 我们提供爆炸期间收集的数据和遥测的链接。
与 API 服务器交互 - HTTP 客户端
如果我们的用户想要自定义与 Detonate API 交互的方式，他们也可以使用他们选择的 HTTP 客户端（例如curl 、 httpie等）运行命令。 这使得他们能够将爆炸添加到脚本中或作为其自己的工作流程结束时的最后步骤。
Queues
管道建立在一系列队列和工作者之上。 由于对消息队列引擎的要求非常基本，我们决定使用Amazon SQS 。 使用 SQS 等流行服务的众多好处之一是，我们可以利用开源资源和库进行构建。 例如，我们在本地运行管道时使用softwaremill/elasticmq Docker 镜像作为队列引擎。
队列使用涵盖我们所有生产和登台基础设施的 Terraform 代码进行配置和部署。
工人
每个工作者都是一个 Python 脚本，既充当队列消费者，又充当队列生产者。 这些工作程序是在我们定制的迷你框架中实现的，其中内置了用于错误处理、重试和监控的样板代码。 我们的基础工作程序可以轻松扩展，如果有额外需求，我们可以添加新的工作程序并改进现有的工作程序。
对于监控，我们使用Elastic APM可观察性解决方案。 它非常强大，让我们可以了解执行流程并轻松调试管道问题。 下面，我们可以看到 Detonate 任务在 APM UI 中的工作人员之间移动：
这些软件和基础设施组件为我们提供了执行爆炸所需的提交、执行和数据收集的一切。
爆炸
该管道可以在 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 配置
为了将虚拟机中的占用空间降至最低，我们使用启动脚本进行配置。 尽量减少我们的足迹非常重要，因为我们在虚拟机内的活动包含在我们收集的事件中，这使得运行后的分析变得更加复杂。 对于 Windows 和 Linux VM，使用 Powershell 和 bash 编写的GCP 启动脚本来配置系统；对于 macOS VM，我们编写了自定义 bash 和 AppleScript 脚本。
启动脚本执行以下步骤：
- 配置系统。 例如，禁用 MS Defender、在 MS Office 中启用宏执行、禁用自动系统更新等。
- 下载并安装 Elastic 代理。 该脚本验证代理是否正确注册到 Fleet Server以及是否应用了策略。
- 下载并引爆样本，或者执行一组命令。 执行发生在后台进程中，而主脚本收集 STDOUT / STDERR 数据流并休眠 N 秒。
- 从文件系统收集文件（如果需要）并将其上传到存储中。 这使得我们能够在爆炸完成后进行任何额外的验证或调试。
VM 生命周期由start_vm和stop_vm工作程序管理。 由于我们预计某些爆炸会破坏启动脚本执行流程（例如，在勒索软件的情况下），因此每个虚拟机都设置了一个 TTL，这允许stop_vm工作程序删除不再使用的虚拟机。
这种全新的方法，使用启动脚本来配置爆炸所需的一切，让我们可以使用来自 Google Cloud 公共映像目录中供应商的 VM 映像，而无需进行任何修改！
网络配置
我们引爆的一些样本是恶意的，可能会产生恶意流量，例如网络扫描、C2 呼叫等。 为了保证我们的云资源和供应商基础设施的安全，我们限制了来自虚拟机的所有传出流量。 这些实例被放置在锁定的 VPC 中，该 VPC 仅允许与预定义的目标列表建立传出连接。 我们使用 Google Cloud 的路由和防火墙规则以及 AWS 的安全组来限制 VPC 中的流量。
我们还在 GCE 中使用了VPC Flow Logs 。 这些日志使我们能够看到由我们的 VPC 中的沙盒虚拟机发起的私有网络流量。
遥测收集
为了观察爆炸，我们使用安装了 Elastic Defend 集成的 Elastic Agent ，并将所有保护措施置于“检测”（而不是“保护”）模式。这使我们能够从虚拟机收集尽可能多的信息，同时允许Elastic Security解决方案生成警报和检测。
我们使用此架构涵盖两种用例：我们可以同时验证保护措施（比较针对不同操作系统版本、代理版本、部署的安全工件等生成的事件和警报）并收集遥测数据进行分析（针对新样本或新型恶意软件）。 所有收集到的数据都保存在持久的 Elastic 集群中，可供我们的研究人员使用。
正在生产中运行
最近，我们在生产中完成了 Detonate 管道的整整一个月运行，在多个数据集成的负载下，同时通过 UI 为内部用户提供服务。 我们目前的记录是一天内发生 1034 次爆炸，到目前为止，我们还没有发现任何可扩展性或可靠性问题。
目前，大部分提交的内容都是针对 Windows 的特定示例。 我们正在努力扩大对 Linux 和 macOS 的覆盖范围——敬请关注即将发布的研究博客文章！
我们不断改进对各种文件类型的支持，确保爆炸尽可能接近预期的触发行为。
查看上个月的爆炸情况，我们发现大多数任务都在 13 分钟内完成（中位数为 515 秒）。 这段时间包括任务数据准备、VM 配置和清理、样本执行和爆炸后处理。
该服务还处于早期阶段，因此出现异常值是正常的。 由于任务中的大部分时间都花在等待 VM 配置上，因此我们可以通过使用自定义 VM 映像、预启动 VM 实例和优化启动脚本来改善总体执行时间。
下一步是什么？
现在您已经了解了 Detonate 的工作原理，我们的下一篇文章将深入探讨 Detonate 的更详细的用例。 我们将进一步探讨这些爆炸如何保护更多的用户，包括 Elastic 的用户！