Amazon EC2 实例支持的先决条件 - Amazon GuardDuty
将 EC2 实例设为 SSM 托管验证架构要求验证组织服务控制策略使用自动代理配置时CPU 和内存限制后续步骤
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

Amazon EC2 实例支持的先决条件

本节包括监控 Amazon EC2 实例运行时行为的先决条件。满足这些先决条件后，请参阅启用 GuardDuty 运行时监控。

将 EC2 实例设为 SSM 托管

您 GuardDuty 要监控其运行时事件的 Amazon EC2 实例必须由 Amazon Systems Manager (SSM) 托管。无论您是使用 GuardDuty 自动管理安全代理还是手动管理安全客户端，这都是如此。但是，当您使用手册手动管理代理时方法 2 – 使用 Linux 软件包管理器，无需使用 SSM 管理您的 EC2 实例。

要使用管理您的亚马逊 EC2 实例 Amazon Systems Manager，请参阅Amazon Systems Manager 用户指南中的为亚马逊 EC2 实例设置 Systems Manager。

基于 Fedora 的实例 EC2 的注意事项

Amazon Systems Manager 不支持 Fedora 操作系统发行版。启用运行时监控后，使用手动方法 (方法 2 – 使用 Linux 软件包管理器) 在基于 Fedor EC2 a 的实例中安装安全代理。

有关支持的平台的信息，请参阅《Amazon Systems Manager 用户指南》中的支持的软件包平台和架构。

验证架构要求

操作系统分发的架构可能会影响 GuardDuty 安全代理的行为。在对 Amazon EC2 实例使用运行时监控之前，您必须满足以下要求：

  • 下表显示了经验证可支持 Amazon EC2 实例 GuardDuty安全代理的操作系统分布。

    操作系统发行版1 内核版本2 内核支持 CPU 架构
    x64 () AMD64 Graviton () ARM64

    AL2 还有 AL2 023

    Ubuntu 20.04 和 Ubuntu 22.04

    Debian 11 和 Debian 12

    5.4 3、5.10 3、5.15、6.1、6.5、6.8

    eBPF、Tracepoints、Kprobe

    支持

    支持

    Ubuntu 24.04

    		 6.8

    RedHat 9.4

    5.14

    Fedora 34.0 4

    5.11、5.17

    CentOS Stream 9

    5.14

    1. 对各种操作系统的支持- GuardDuty 已验证支持在上表中列出的操作系统上使用运行时监控。在使用不同的操作系统时，您可能会获得 GuardDuty 已验证在列出的操作系统发行版中提供的所有预期安全值。

    2. 对于任何内核版本，都必须将该CONFIG_DEBUG_INFO_BTF标志设置为y（意思是 true）。这是必需的，这样 GuardDuty 安全代理才能按预期运行。

    3. 对于内核版本 5.10 及更早版本， GuardDuty 安全代理使用 RAM (RLIMIT_MEMLOCK) 中的锁定内存来按预期运行。如果您的系统RLIMIT_MEMLOCK值设置得太低， GuardDuty 建议将硬限制和软限制都设置为至少 32 MB。有关验证和修改默认RLIMIT_MEMLOCK值的信息，请参见查看和更新RLIMIT_MEMLOCK值。

    4. Fedora 不是支持自动代理配置的平台。你可以使用方法 2 – 使用 Linux 软件包管理器在 Fedora 上部署 GuardDuty安全代理。

  • 其他要求-仅当你有 Amazon ECS/Amazon 时 EC2

    对于亚马逊 ECS/Amazon EC2，我们建议您使用最新的亚马逊 ECS 优化版 AMIs （日期为 2023 年 9 月 29 日或之后），或者使用亚马逊 ECS 代理版本 v1.77.0。

查看和更新RLIMIT_MEMLOCK值

当您的系统RLIMIT_MEMLOCK限制设置得太低时， GuardDuty 安全代理可能无法按设计运行。 GuardDuty 建议硬限制和软限制都必须至少为 32 MB。如果您不更新限制， GuardDuty 将无法监控资源的运行时事件。RLIMIT_MEMLOCK当超过规定的最低限额时，您可以选择更新这些限制。

您可以在安装 GuardDuty 安全客户端之前或之后修改默认RLIMIT_MEMLOCK值。

查看RLIMIT_MEMLOCK值

  1. 运行 ps aux | grep guardduty。这将输出进程 ID (pid)。

  2. 从上一个命令的输出中复制进程 ID (pid)。

  3. 将pid替换为从上一步中复制的进程 ID grep "Max locked memory" /proc/pid/limits 后运行。

    这将显示运行 GuardDuty 安全代理时的最大锁定内存。

更新RLIMIT_MEMLOCK值

  1. 如果该/etc/systemd/system.conf.d/NUMBER-limits.conf文件存在，则DefaultLimitMEMLOCK从该文件中注释掉该行。此文件将默认设置RLIMIT_MEMLOCK为高优先级，这会覆盖您在/etc/systemd/system.conf文件中的设置。

  2. 打开/etc/systemd/system.conf文件并取消注释包含的行。#DefaultLimitMEMLOCK=

  3. 更新默认值，将硬限制和软RLIMIT_MEMLOCK限制设置为至少 32MB。更新应该是这样的:DefaultLimitMEMLOCK=32M:32M. 格式为 soft-limit:hard-limit。

  4. 运行 sudo reboot。

验证组织服务控制策略

如果您设置了服务控制策略（SCP）来管理组织中的权限，请验证权限边界未限制 guardduty:SendSecurityTelemetry。它是支持跨不同资源类型的运行时监控所必需的。 GuardDuty

如果您是成员账户，则连接到关联的委派管理员。有关为您的组织 SCPs 进行管理的信息，请参阅服务控制策略 (SCPs)。

使用自动代理配置时

为使用自动代理配置（推荐）此，您 Amazon Web Services 账户 必须满足以下先决条件：

  • 在自动代理配置中使用包含标签时， GuardDuty 要为新实例创建 SSM 关联，请确保新实例由 SSM 管理并显示在控制台的 Fleet Manager 下。https://console.aws.amazon.com/systems-manager/

  • 将排除标签与自动代理配置结合使用时

    • 在为您的账户配置 GuardDuty 自动代理之前，请添加GuardDutyManaged:false标签。

      在启动 Amazon EC2 实例之前，请务必将排除标签添加到这些实例。在您为 Amazon 启用自动代理配置后 EC2，任何在没有排除标签的情况下启动的 EC2 实例都将包含在 GuardDuty 自动代理配置中。

    • 要使排除标签生效，请更新实例配置，以便实例身份文档在实例元数据服务（IMDS）中可用。执行此步骤的过程已经是为账户启用运行时监控的一部分。

GuardDuty 代理的 CPU 和内存限制

CPU 限制

与 Amazon EC2 实例关联 GuardDuty 的安全代理的最大 CPU 限制为 vCPU 内核总数的 10%。例如，如果您的 EC2 实例有 4 个 vCPU 内核，则安全代理最多可以使用 400% 的可用核心。

内存限制

从与您的 Amazon EC2 实例关联的内存中， GuardDuty 安全代理可以使用的内存有限。

具体内存限制详见下表。

Amazon EC2 实例的内存

GuardDuty 代理的最大内存

小于 8 GB

128MB

小于 32 GB

256 MB

大于等于 32 GB

1 GB

后续步骤

下一步是配置运行时监控并管理安全代理（自动或手动）。