Prerequisiti per il supporto delle EC2 istanze Amazon - Amazon GuardDuty

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Prerequisiti per il supporto delle EC2 istanze Amazon

Questa sezione include i prerequisiti per il monitoraggio del comportamento di runtime delle EC2 istanze Amazon. Una volta soddisfatti questi prerequisiti, consulta. Abilitazione del monitoraggio del GuardDuty runtime

Rendi EC2 le istanze gestite tramite SSM (solo per la configurazione automatica degli agenti)

GuardDuty utilizza AWS Systems Manager (SSM) per distribuire, installare e gestire automaticamente il security agent sulle tue istanze. Se si prevede di installare e gestire manualmente l' GuardDuty agente, l'SSM non è necessario.

Per gestire le tue EC2 istanze Amazon con Systems Manager, consulta Configurazione di Systems Manager per EC2 le istanze Amazon nella Guida per l'AWS Systems Manager utente.

Convalida i requisiti architettonici

L'architettura della distribuzione del sistema operativo potrebbe influire sul comportamento del GuardDuty Security Agent. È necessario soddisfare i seguenti requisiti prima di utilizzare Runtime Monitoring per EC2 le istanze Amazon:

  • Il supporto del kernel include eBPF eTracepoints. Kprobe Per le architetture CPU, Runtime Monitoring supporta AMD64 (x64) e ARM64 (Graviton2 e versioni successive). 1

    La tabella seguente mostra la distribuzione del sistema operativo che è stata verificata per supportare il GuardDuty security agent per EC2 le istanze Amazon.

    distribuzione del sistema operativo 2 Versione del kernel 3
    Amazon Linux 2

    5.4 4, 5.10, 5.15 4

    Amazon Linux 2023

    5.4 4, 5.10, 5.15, 46.1, 6.5, 6.8, 6,12

    Ubuntu 20.04 e Ubuntu 22.04

    5.4 4, 5.10, 5.15, 46.1, 6.5, 6.8

    Ubuntu 24.04

    6.8

    Debian 11 e Debian 12

    5.4 4, 5.10, 5.15, 46.1, 6.5, 6.8

    RedHat 9.4

    5,14

    Fedora 34.0

    5.11, 5.17

    Fedora 40

    6.8

    Fedora 41

    6.12

    CentOS Stream 9

    5,14

    Oracle Linux 8.9

    5.15

    Oracle Linux 9.3

    5.15

    Rocky Linux 9.5

    5.14

    1. Runtime Monitoring for Amazon EC2 Resources non supporta le istanze Graviton di prima generazione come i tipi di istanze A1.

    2. Supporto per vari sistemi operativi: GuardDuty ha verificato il supporto del Runtime Monitoring per la distribuzione operativa elencata nella tabella precedente. Sebbene il GuardDuty security agent possa funzionare su sistemi operativi non elencati nella tabella precedente, il GuardDuty team non può garantire il valore di sicurezza previsto.

    3. Per qualsiasi versione del kernel, è necessario impostare il CONFIG_DEBUG_INFO_BTF flag su y (che significa true). Ciò è necessario per consentire al GuardDuty Security Agent di funzionare come previsto.

    4. Per le versioni del kernel 5.10 e precedenti, il GuardDuty security agent utilizza la memoria bloccata nella RAM (RLIMIT_MEMLOCK) per funzionare come previsto. Se il RLIMIT_MEMLOCK valore del sistema è impostato su un valore troppo basso, si GuardDuty consiglia di impostare i limiti rigidi e morbidi su almeno 32 MB. Per informazioni sulla verifica e la modifica del RLIMIT_MEMLOCK valore predefinito, vedere. Visualizzazione e aggiornamento dei valori RLIMIT_MEMLOCK

  • Requisiti aggiuntivi: solo se disponi di Amazon ECS/Amazon EC2

    Per Amazon ECS/Amazon EC2, ti consigliamo di utilizzare la versione più recente ottimizzata per Amazon ECS AMIs (datata 29 settembre 2023 o successiva) o di utilizzare la versione dell'agente Amazon ECS v1.77.0.

Visualizzazione e aggiornamento dei valori RLIMIT_MEMLOCK

Quando il RLIMIT_MEMLOCK limite del sistema è troppo basso, il GuardDuty Security Agent potrebbe non funzionare come previsto. GuardDuty raccomanda che sia i limiti rigidi che quelli flessibili siano di almeno 32 MB. Se non aggiorni i limiti, non GuardDuty sarà possibile monitorare gli eventi di runtime della risorsa. Quando RLIMIT_MEMLOCK supera i limiti minimi indicati, l'aggiornamento di tali limiti diventa facoltativo.

È possibile modificare il RLIMIT_MEMLOCK valore predefinito prima o dopo l'installazione del GuardDuty Security Agent.

Per visualizzare RLIMIT_MEMLOCK i valori
  1. Esegui ps aux | grep guardduty. Questo produrrà l'ID del processo (pid).

  2. Copia l'ID del processo (pid) dall'output del comando precedente.

  3. Esegui grep "Max locked memory" /proc/pid/limits dopo averlo sostituito pid con l'ID di processo copiato dal passaggio precedente.

    Verrà visualizzata la quantità massima di memoria bloccata per l'esecuzione del GuardDuty Security Agent.

Per aggiornare RLIMIT_MEMLOCK i valori
  1. Se il /etc/systemd/system.conf.d/NUMBER-limits.conf file esiste, commenta la riga DefaultLimitMEMLOCK di questo file. Questo file imposta un valore predefinito RLIMIT_MEMLOCK con priorità alta, che sovrascrive le impostazioni nel /etc/systemd/system.conf file.

  2. Apri il /etc/systemd/system.conf file e decommenta la riga che contiene. #DefaultLimitMEMLOCK=

  3. Aggiorna il valore predefinito fornendo RLIMIT_MEMLOCK limiti rigidi e flessibili di almeno 32 MB. L'aggiornamento dovrebbe assomigliare a questo:DefaultLimitMEMLOCK=32M:32M. Il formato è soft-limit:hard-limit.

  4. Esegui sudo reboot.

Convalida della politica di controllo dei servizi della tua organizzazione in un ambiente con più account

Se hai impostato una policy di controllo dei servizi (SCP) per gestire le autorizzazioni nella tua organizzazione, verifica che il limite delle autorizzazioni consenta l'azione. guardduty:SendSecurityTelemetry È necessario per supportare il monitoraggio del runtime GuardDuty su diversi tipi di risorse.

Se sei un account membro, connettiti con l'amministratore delegato associato. Per informazioni sulla gestione SCPs dell'organizzazione, consulta le politiche di controllo del servizio (SCPs).

Quando si utilizza la configurazione automatica degli agenti

Per Utilizza la configurazione automatica degli agenti (scelta consigliata) farlo, Account AWS è necessario soddisfare i seguenti prerequisiti:

  • Quando utilizzi tag di inclusione con configurazione automatica degli agenti, per GuardDuty creare un'associazione SSM per una nuova istanza, assicurati che la nuova istanza sia gestita tramite SSM e venga visualizzata in Fleet Manager nella console. https://console.aws.amazon.com/systems-manager/

  • Quando si utilizzano i tag di esclusione con la configurazione automatica degli agenti:

    • Aggiungi il false tagGuardDutyManaged: prima di configurare l'agente GuardDuty automatico per il tuo account.

      Assicurati di aggiungere il tag di esclusione alle tue EC2 istanze Amazon prima di avviarle. Dopo aver abilitato la configurazione automatizzata degli agenti per Amazon EC2, qualsiasi EC2 istanza che viene avviata senza un tag di esclusione sarà coperta dalla configurazione GuardDuty automatizzata dell'agente.

    • Abilita l'opzione Consenti tag nell'impostazione dei metadati per le tue istanze. Questa impostazione è necessaria perché GuardDuty deve leggere il tag di esclusione dall'Instance Metadata Service (IMDS) per determinare se escludere l'istanza dall'installazione dell'agente. Per ulteriori informazioni, consulta Abilita l'accesso ai tag nei metadati dell'istanza nella Amazon EC2 User Guide.

Limite di CPU e memoria per l'agente GuardDuty

Limite della CPU

Il limite massimo di CPU per il GuardDuty security agent associato alle EC2 istanze Amazon è pari al 10% del totale dei core vCPU. Ad esempio, se l' EC2 istanza ha 4 core vCPU, il security agent può utilizzare al massimo il 40 percento del 400 percento totale disponibile.

Memory limit (Limite memoria)

Dalla memoria associata alla tua EC2 istanza Amazon, c'è una memoria limitata che il GuardDuty Security Agent può utilizzare.

La tabella seguente mostra il limite di memoria.

Memoria dell' EC2 istanza Amazon

Memoria massima per l' GuardDuty agente

Meno di 8 GB

128 MB

Meno di 32 GB

256 MB

Maggiore o uguale a 32 GB

1 GB

Approfondimenti

Il passaggio successivo consiste nella configurazione del Runtime Monitoring e nella gestione del security agent (automaticamente o manualmente).