了解亚马逊 GuardDuty 实时监控 Amazon EC2 安全博客

了解 Amazon GuardDuty 的运行时监控功能

由斯科特沃德撰写于2024年9月18日，发布于 Amazon GuardDuty，中级(200)， 安全、身份与合规，技术如何做永久链接 评论 分享

关键点总结

本文深入探讨了 Amazon GuardDuty 对于 EC2 实例的运行时监控功能，以及该功能的关键能力。通过这篇文章，您将了解运行时监控的部署策略，并详细了解它如何通过检测威胁，为您的 Amazon Elastic Compute Cloud (Amazon EC2) 实例及其上运行的工作负载提供安全价值。这篇文章基于 Channy Yun 的文章，详述了如何启用运行时监控、查看生成的发现和监控覆盖范围。

Amazon Web Services (AWS) 在 2017 年 reInvent 大会上推出了 Amazon GuardDuty，旨在为客户的 AWS 账户和工作负载提供托管的威胁检测能力。启用后，GuardDuty 会自动处理必要的日志数据。自推出以来，GuardDuty 不断扩展其威胁检测能力，包括识别可能影响客户环境的新威胁类型和扩展 GuardDuty 可处理的日志源，以检测 AWS 资源的威胁。

GuardDuty 此外还推出了运行时监控功能，最初支持 Amazon Elastic Kubernetes Service (Amazon EKS) 工作负载。运行时监控为 GuardDuty 提供了操作系统层面的洞察，以检测可能对 AWS 上的工作负载构成威胁的情况，并满足客户对操作系统可见性的需求。在 2023 年的 reInvent 大会上，GuardDuty 将运行时监控的扩展范围覆盖至 Amazon Elastic Container Service (Amazon ECS)，包括在 AWS Fargate 上运行的无服务器工作负载，并提供对 Amazon EC2 的预览支持。

功能与作用

GuardDuty 的 EC2 运行时监控依赖于一个轻量级的安全代理，收集来自 EC2 实例的操作系统 事件，如文件访问、进程、命令行参数和网络连接，然后将其发送给 GuardDuty。在 GuardDuty 接收到操作系统事件后，这些事件将被评估，以识别与 EC2 实例相关的潜在威胁。在本节中，我们探讨了 GuardDuty 如何评估收到的运行时事件，以及它如何呈现识别的威胁信息。

命令参数与事件关联

运行时安全代理使 GuardDuty 能够创建无法使用 VPC 流日志、DNS 日志和 CloudTrail 日志等 基础数据源 创建的发现。安全代理可以收集实例操作系统级别上发生的详细信息，这些信息在基础数据源中是没有的。

随着 EC2 运行时监控的推出，运行时代理和 GuardDuty 增加了额外功能，包括收集命令参数和关联 EC2 实例的事件。这些新功能有助于排除良性事件，并准确生成与潜在威胁相关的发现。

GuardDuty 的安全代理会收集操作系统运行命令例如 curl、systemctl、cron 等的信息，并利用此信息生成发现。安全代理现在还收集运行命令时使用的命令参数。这种额外信息为 GuardDuty 提供了更多检测威胁的能力，因为这增加了与运行命令相关的额外上下文。

例如，代理不仅会识别出 systemctl用于管理 Linux 实例上的服务被运行，但也会识别出运行命令时使用的参数停止、启动、禁用等以及为哪个服务发出命令。这种详细程度有助于识别出威胁行为者可能正在改变安全或监控服务，从而逃避检测。

GuardDuty 现在还可以关联使用运行时代理收集的多个事件，以识别对您的环境构成威胁的场景。一些在实例上发生的事件单独来看可能不会明显显示为威胁。这些事件被称为弱信号。然而，当这些弱信号一起考虑并且命令的序列与恶意活动相符合时，GuardDuty 将利用这些信息生成发现。例如，下载文件本身可能表现为一个弱信号。如果该下载的文件随后被重定向到一个 shell 命令，并且该 shell 命令开始与额外的操作系统文件或网络配置进行交互，或运行已知的恶意软件可执行文件，则所有这些事件的相关性可以导致 GuardDuty 生成发现。

GuardDuty 发现类型

当前，GuardDuty 运行时监控支持 41 种 发现类型，用于指示基于主机和容器的操作系统级行为的潜在威胁。这些发现是基于安全代理收集并发送给 GuardDuty 服务的 事件类型。

其中五种发现类型利用了之前部分提到的运行时代理和 GuardDuty 的新能力。这五种新的发现类型如下：

每个 GuardDuty 发现都以威胁目的开始，与 MITRE ATTampCK 战术 对齐。Execution 发现类型专注于对实际命令或进程运行的观察威胁，这些威胁与恶意活动相符。DefenseEvasion 发现类型则专注于运行旨在禁用实例上防御机制的命令的情况，这些防御机制通常用于识别或帮助防止恶意行为者在您的实例上的活动。

在接下来的部分中，我将详细介绍新的运行时监控发现类型以及它们识别的恶意活动类型。

可疑活动的 SuspiciousTool、SuspiciousCommand 和 PtraceAntiDebugging 发现类型专注于那些被用来逃避检测的活动。识别这些活动的方式是类似的。SuspiciousTool 发现类型专注于后门工具、网络扫描器和网络嗅探器等工具。GuardDuty 有助于识别在实例上与这些工具相关的恶意活动案例。

SuspiciousCommand 发现类型识别可疑命令，其威胁目的为 DefenseEvasion 或 Execution。DefenseEvasion 发现是未授权用户试图隐藏其行为的指示。这些行为可能包括禁用本地防火墙、修改本地 IP 表或删除 crontab 条目。Execution 发现则识别在您的 EC2 实例上运行的可疑命令。与 Execution 相关的发现可能是单个可疑命令或一系列命令，这些命令与其他命令结合在一起，结合上下文，成为明显的可疑活动的指示。例如，与多个命令结合相关的一个 Execution 发现可能是文件被下载，然后在一系列与已知恶意模式相符的步骤中运行。

对于 PtraceAntiDebugging 发现，GuardDuty 查找在您的实例上使用 ptrace 系统调用的情况，并且使用 PTRACETRACEME 选项导致附加调试器从运行的进程中分离。这是一种可疑活动，因为它允许进程使用 ptrace 逃避调试，这是恶意软件用来逃避检测的已知技术。

更新后的 GuardDuty 安全代理还可以识别何时运行了恶意文件。借助 MaliciousFileExecuted 发现类型，GuardDuty 可以识别何时可能运行了已知的恶意文件，为您提供一个强烈的指示，表明您的实例上存在恶意软件。这种能力尤为重要，因为它允许您识别在上次恶意软件扫描后可能已经引入的已知恶意软件。

发现详情

到目前为止提到的所有发现均可通过 GuardDuty 的 AWS 管理控制台、GuardDuty API、Amazon EventBridge 消息或通过 AWS Security Hub 进行访问。GuardDuty 生成的发现不仅用于向您报告在您的实例上观察到可疑事件，而且还提供足够的上下文，以帮助您制定响应发现的方法。

GuardDuty 安全代理收集了多种来自操作系统的事件用于威胁检测。当 GuardDuty 根据观察到的运行时活动生成发现时，它将包括这些观察到的事件的详细信息，这可以帮助确认威胁的性质并为可能的漏洞修复步骤提供路径。GuardDuty 运行时发现中提供的信息可以分为三个主要类别：

受影响的 AWS 资源

在 GuardDuty 生成的每一个发现中，都会包括有关受影响 AWS 资源的信息。对于 EC2 运行时监控，关键的信息包括 EC2 实例的信息如名称、实例类型、AMI 和 AWS 区域、分配给实例的标签、网络接口和安全组。这些信息将有助于您对具体实例的响应和调查，以确认观察到的威胁。此外，它还有助于评估实例的关键网络配置，以确认其网络配置是否正确，或评估网络配置如何对响应产生影响。

进程详情

对于每个运行时发现，GuardDuty 包括有关与威胁相关的进程的观察详情。您应期望看到的一些常见项目包括生成所识别发现的可执行文件的名称和路径、操作系统进程的 ID、进程开始的时间以及哪个操作系统用户运行了该进程。此外，发现中还包含进程传承信息。进程传承有助于识别相互关联的操作系统进程，并提供有关引发所识别进程的父进程的洞察。了解进程传承能为您提供有价值的见解，例如识别哪些其他命令最终导致生成在发现中识别出的可执行文件或命令。如果与发现相关的进程正在容器内运行，则发现还会提供有关该容器的详细信息，例如容器 ID 和映像。

运行时上下文

运行时上下文提供有关文件系统类型的洞察、用于控制事件行为的标志、潜在可疑工具的名称、生成发现的脚本路径以及被禁用的安全服务名称。发现中的上下文信息旨在帮助您进一步了解被识别为威胁的运行时活动，并确定其潜在影响及可能的响应。例如，使用 systemctl 命令禁用 apparmor 工具被检测出时，将报告与运行 systemctl 命令相关的进程信息，然后运行时上下文将包含实际受到影响的服务的名称和与命令相关的选项。

请参阅 运行时监控发现详情 以获取您可能在运行时发现中看到的完整进程和上下文详情列表。

响应运行时发现

使用 GuardDuty 发现时，最佳实践是启用基于事件的响应，能够在每次生成运行时发现时立即调用响应。这一做法同样适用于与运行时相关的发现。对于 GuardDuty 生成的每个运行时发现，都会将该发现的一份副本发送到 EventBridge。如果您使用 Security Hub，发现的副本也将发送到 Security Hub。通过 EventBridge，您可以定义一个与您希望优先处理和响应的发现属性匹配的规则模式。此模式可以非常宽泛，查找所有与运行时相关的发现；也可以更具针对性，仅查找某些发现类型、特定严重性级别的发现，或者甚至与发现的进程或运行时上下文相关的某些属性。

一旦建立了规则模式，您就可以定义发现应发送的目标。该目标可以是超过 20 种 AWS 服务之一，这在将发现路由到您公司使用的操作工具或流程中提供了极大的灵活性。目标可以是负责评估发现的 AWS Lambda 函数，向发现添加一些附加数据，然后将其发送到工单或聊天工具。目标也可以是 AWS Systems Manager 运行手册，这将在实际的操作系统上执行额外的取证，或隔离或禁用发现中所识别的任何进程。

许多客户对 GuardDuty 发现采取分步响应的方法。第一步可能是确保发现被丰富为尽可能多的支持细节，然后将其发送给相关个人或团队。这能够帮助调查发现的人确认发现是否为真实的阳性，进一步决定应采取什么行动。

除了针对 GuardDuty 发现启用事件驱动响应外，您还可以在 GuardDuty 或 Security Hub 控制台中调查每个 GuardDuty 运行时发现。通过控制台，您可以研究发现的具体细节，并利用这些信息来确定后续步骤，响应或补救发现。

检测速度

由于与您的工作负载的紧密连接，GuardDuty 安全代理可以比处理 VPC 流日志和 DNS 日志等日志源更快速地生成发现。安全代理收集操作系统事件并直接将其转发到 GuardDuty 服务，快速检查事件并生成发现。这有助于您尽快制定响应，从而能及时隔离和阻止对 EC2 实例的已识别威胁。

我们来看看一个可以通过运行时安全代理和基础日志源如 AWS CloudTrail、VPC 流日志和 DNS 日志检测到的发现类型。BackdoorEC2/C ampCActivityB!DNS 和 BackdoorRuntime/C ampCActivityB!DNS 是相同的发现，前者来源于 DNS 日志，后者来自运行时安全代理。虽然 GuardDuty 对于处理日志源或安全代理的发现所需时间没有服务级别协议 (SLA)，但测试这些发现类型表明，运行时发现生成仅需几分钟。而基于日志文件的发现则需大约 15 分钟，因为日志文件的传输和处理存在延迟。最终，这两个发现意味着同样的事情，但运行时发现将更快到达，并附带更多的进程和上下文信息，帮助您更早实施对威胁的响应，有效提高您隔离、控制和停止威胁的能力。

运行时数据和流日志数据

在探索运行时监控功能及其对您组织的实用性时，了解您账户和工作负载的基础保护等级至关重要。在启用 GuardDuty 时，基础数据源 VPC 流日志、DNS 日志和 CloudTrail 日志也会启用，且无法在完全禁用 GuardDuty 的情况下关闭这些源。运行时监控提供的上下文信息能够生成更精确的发现，帮助进行针对性的补救措施，相较于 VPC 流日志所提供的信息。启用运行时监控代理发布在实例上时，GuardDuty 服务仍会处理该实例的 VPC 流日志和 DNS 日志