Amazon EC2 執行個體支援的先決條件 - Amazon GuardDuty
讓 EC2 執行個體 SSM 受管驗證架構需求驗證您的組織服務控制政策使用自動代理程式組態時CPU 和記憶體限制下一步驟

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

Amazon EC2 執行個體支援的先決條件

本節包含監控 Amazon EC2 執行個體執行時間行為的先決條件。符合這些先決條件後，請參閱 啟用 GuardDuty 執行期監控。

讓 EC2 執行個體 SSM 受管

您希望 GuardDuty 監控執行期事件的 Amazon EC2 執行個體必須 AWS Systems Manager 受 (SSM) 管理。無論您使用 GuardDuty 自動管理安全代理程式，還是手動管理安全代理程式，這都是無關緊要的。不過，當您使用手動 手動管理代理程式時方法 2 - 使用 Linux 套件管理員，不需要 SSM 管理 EC2 執行個體。

若要使用 管理您的 Amazon EC2 執行個體 AWS Systems Manager，請參閱AWS Systems Manager 《 使用者指南》中的為 Amazon EC2 執行個體設定 Systems Manager。

Fedora 型 EC2 執行個體的注意事項

AWS Systems Manager 不支援 Fedora 作業系統分佈。啟用執行期監控後，請使用手動方法 (方法 2 - 使用 Linux 套件管理員) 在以 Fedora 為基礎的 EC2 執行個體中安裝安全代理程式。

如需支援平台的相關資訊，請參閱AWS Systems Manager 《 使用者指南》中的支援套件平台和架構。

驗證架構需求

作業系統分佈的架構可能會影響 GuardDuty 安全代理程式的行為。您必須先符合下列需求，才能使用 Amazon EC2 執行個體的執行期監控：

  • 下表顯示已驗證的作業系統分佈，以支援 Amazon EC2 執行個體的 GuardDuty 安全代理程式。

    作業系統發行版本1 核心版本2 核心支援 CPU 架構
    x64 (AMD64) Graviton (ARM64)

    AL2 和 AL2023

    Ubuntu 20.04 和 Ubuntu 22.04

    Debian 11 和 Debian 12

    5.43、5.103、5.15、6.1、6.5、6.8

    eBPF、Tracepoints、Kprobe

    支援

    支援

    Ubuntu 24.04

    		 6.8

    RedHat 9.4

    5.14

    Fedora4 34.0

    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 不支援自動化代理程式組態的平台。您可以使用 在 Fedora 上部署 GuardDuty 安全代理程式方法 2 - 使用 Linux 套件管理員。

  • 其他要求 - 僅當您有 Amazon ECS/Amazon EC2 時

    對於 Amazon ECS/Amazon EC2，我們建議您使用最新的 Amazon ECS 最佳化 AMIs （日期為 2023 年 9 月 29 日或更新版本），或使用 Amazon ECS 代理程式版本 1.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. 透過提供至少 32MB 的硬限制和軟RLIMIT_MEMLOCK限制來更新預設值。更新應該如下所示：DefaultLimitMEMLOCK=32M:32M。格式是 soft-limit:hard-limit。

  4. 執行 sudo reboot。

驗證您的組織服務控制政策

如果您已設定服務控制政策 (SCP) 來管理組織中的許可，請確認許可界限並未限制 guardduty:SendSecurityTelemetry。GuardDuty 需要支援不同資源類型的執行期監控。

如果您是 成員帳戶，請與相關聯的委派管理員連線。如需有關管理組織 SCPs的資訊，請參閱服務控制政策 SCPs)。

使用自動代理程式組態時

若要 使用自動代理程式組態 （建議），您的 AWS 帳戶 必須滿足下列先決條件：

  • 使用具有自動代理程式組態的包含標籤時，GuardDuty 會為新執行個體建立 SSM 關聯，請確保新執行個體受到 SSM 管理，並在 https://console.aws.amazon.com/systems-manager/ 主控台的 Fleet Manager 下顯示。

  • 搭配自動代理程式組態使用排除標籤時：

    • 在為您的帳戶設定 GuardDuty 自動化代理程式之前，請先新增 GuardDutyManaged：false 標籤。

      在啟動排除標籤之前，請務必將排除標籤新增至 Amazon EC2 執行個體。啟用 Amazon EC2 的自動代理程式組態後，任何在沒有排除標籤的情況下啟動的 EC2 執行個體都會包含在 GuardDuty 自動代理程式組態中。

    • 若要讓排除標籤運作，請更新執行個體組態，讓執行個體身分文件可在執行個體中繼資料服務 (IMDS) 中使用。執行此步驟的程序已是啟用執行期監控您 帳戶的一部分。

GuardDuty 代理程式的 CPU 和記憶體限制

CPU 限制

與 Amazon EC2 執行個體相關聯的 GuardDuty 安全代理程式的 CPU 上限是總 vCPU 核心的 10%。例如，如果您的 EC2 執行個體有 4 個 vCPU 核心，則安全代理程式最多可以使用可用總數 400% 的 40%。

Memory limit (記憶體限制)

從與 Amazon EC2 執行個體相關聯的記憶體中，GuardDuty 安全代理程式可以使用的記憶體有限。

下表顯示記憶體限制。

Amazon EC2 執行個體的記憶體

GuardDuty 代理程式的最大記憶體

小於 8 GB

128 MB

小於 32 GB

256 MB

大於或等於 32 GB

1 GB

下一步驟

下一個步驟是設定執行期監控，以及管理安全代理程式 （自動或手動）。