Requisitos previos para la compatibilidad con instancias de Amazon EC2
En esta sección se incluyen los requisitos previos para supervisar el comportamiento en tiempo de ejecución de las instancias de Amazon EC2. Una vez cumplidos estos requisitos previos, consulte Habilitar la Supervisión en tiempo de ejecución de GuardDuty.
Temas
Haga que SSM administre las instancias de EC2 (solo para la configuración automatizada de agentes)
GuardDuty usa AWS Systems Manager (SSM) para implementar, instalar y administrar de manera automática el agente de seguridad en sus instancias. Si planea instalar y administrar de manera manual el agente GuardDuty, no necesitará SSM.
Para administrar las instancias de Amazon EC2 con Systems Manager, consulte Configurar Systems Manager para instancias de Amazon EC2 en la Guía del usuario de AWS Systems Manager.
Validar los requisitos de arquitectura
La arquitectura de la distribución del sistema operativo puede afectar el comportamiento del agente de seguridad de GuardDuty. Debe cumplir los siguientes requisitos antes de utilizar la Supervisión en tiempo de ejecución para instancias de Amazon EC2:
-
La compatibilidad del kernel incluye
eBPF,TracepointsyKprobe. Para las arquitecturas de CPU, Runtime Monitoring admite AMD64 (x64) y ARM64 (Graviton2 y versiones posteriores)1.En la siguiente tabla aparece la distribución del sistema operativo que se ha verificado que es compatible con el agente de seguridad de GuardDuty para las instancias de Amazon EC2.
Distribución del sistema operativo2 Versión del kernel3 Amazon Linux 2 Amazon Linux 2023 Ubuntu 20.04 y Ubuntu 22.04 Debian 11 y Debian 12 Ubuntu 24.04 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
-
Runtime Monitoring para recursos de Amazon EC2 no es compatible con la primera generación de instancias de Graviton, como los tipos de instancia A1.
-
Compatibilidad con varios sistemas operativos: GuardDuty ha verificado que Runtime Monitoring es compatible con la distribución operativa que figura en la tabla anterior. Si bien el agente de seguridad de GuardDuty puede funcionar en sistemas operativos que no figuran en la tabla anterior, el equipo de GuardDuty no puede garantizar el valor de seguridad esperado.
-
Para cualquier versión del kernel, debe establecer el marcador
CONFIG_DEBUG_INFO_BTFeny(que significa verdadero). Esto es necesario para que el agente de seguridad de GuardDuty pueda funcionar como se espera. -
En las versiones 5.10 y anteriores del kernel, el agente de seguridad GuardDuty utiliza la memoria bloqueada en la RAM (
RLIMIT_MEMLOCK) para funcionar según lo previsto. Si el valorRLIMIT_MEMLOCKdel sistema es demasiado bajo, GuardDuty recomienda establecer los límites duros y flexibles en al menos 32 MB. Para obtener información sobre cómo comprobar y modificar el valorRLIMIT_MEMLOCKpredeterminado, consulte Visualización y actualización de los valores RLIMIT_MEMLOCK. -
Para Ubuntu 24.04, las versiones 6.13 y 6.14 del kernel solo admiten las versiones 1.9.0 y superiores del agente EC2.
-
-
Requisitos adicionales: solo si dispone de Amazon ECS/Amazon EC2
En el caso de Amazon ECS/Amazon EC2, recomendamos que utilice las AMI optimizadas para Amazon ECS más recientes (con fecha del 29 de septiembre de 2023 o posterior), o que utilice la versión v1.77.0 del agente de Amazon ECS.
Visualización y actualización de los valores RLIMIT_MEMLOCK
Si el límite RLIMIT_MEMLOCK del sistema es demasiado bajo, es posible que el agente de seguridad GuardDuty no funcione según lo diseñado. GuardDuty recomienda que tanto los límites rígidos como los límites flexibles sean de 32 MB como mínimo. Si no actualiza los límites, GuardDuty no podrá supervisar los eventos de tiempo de ejecución de su recurso. Cuando RLIMIT_MEMLOCK supere los límites mínimos establecidos, la actualización de estos límites pasa a ser opcional.
Puede modificar el valor RLIMIT_MEMLOCK predeterminado antes o después de instalar el agente de seguridad GuardDuty.
Para ver los valores RLIMIT_MEMLOCK
-
Ejecuta
ps aux | grep guardduty. Esto generará el ID del proceso (pid). -
Copie el ID del proceso (
pid) del resultado del comando anterior. -
Ejecute
grep "Max locked memory" /proc/después de reemplazar elpid/limitspidcon el ID de proceso copiado del paso anterior.Esto mostrará la cantidad máxima de memoria bloqueada para ejecutar el agente de seguridad GuardDuty.
Para actualizar los valores RLIMIT_MEMLOCK
-
Si el archivo
/etc/systemd/system.conf.d/existe, comente la líneaNUMBER-limits.confDefaultLimitMEMLOCKde este archivo. Este archivo establece un valor predeterminadoRLIMIT_MEMLOCKcon alta prioridad, que sobrescribe la configuración del archivo/etc/systemd/system.conf. -
Abre el archivo
/etc/systemd/system.confy quita el comentario de la línea que contiene#DefaultLimitMEMLOCK=. -
Actualice el valor predeterminado proporcionando límites
RLIMIT_MEMLOCKfijos y flexibles de al menos 32 MB. La política actualizada debería ser así:DefaultLimitMEMLOCK=32M:32M. El formato essoft-limit:hard-limit. -
Ejecuta
sudo reboot.
Validación de la política de control de servicios de la organización en un entorno de varias cuentas
Si ha configurado una política de control de servicio (SCP) para administrar los permisos en la organización, valide que el límite de permisos permita la acción guardduty:SendSecurityTelemetry. Se necesita para que GuardDuty admita la Supervisión en tiempo de ejecución en diferentes tipos de recursos.
Si es una cuenta de miembro, contacte al administrador delegado asociado. Para obtener información sobre cómo administrar SCP para la organización, consulte Políticas de control de servicios (SCP).
Al utilizar la configuración automatizada de agentes
Para Utilice la configuración automatizada de agentes (opción recomendada), la Cuenta de AWS debe cumplir con los siguientes requisitos previos:
-
Cuando se utilizan etiquetas de inclusión con configuración automatizada del agente, para que GuardDuty cree una asociación SSM para una nueva instancia, asegúrese de que la nueva instancia sea administrada por SSM y aparezca bajo el Administrador de flotas en la consola https://console.aws.amazon.com/systems-manager/
. -
Al utilizar etiquetas de exclusión con configuración automatizada del agente
-
Agregue la etiqueta
GuardDutyManaged:falseantes de configurar el agente automatizado de GuardDuty para la cuenta.Asegúrese de agregar la etiqueta de exclusión a las instancias de Amazon EC2 antes de lanzarlas. Una vez que haya habilitado la configuración automatizada del agente para Amazon EC2, cualquier instancia de EC2 que se lance sin una etiqueta de exclusión estará cubierta por la configuración automatizada del agente de GuardDuty.
-
Activa la opción Permitir etiquetas en los metadatos de las instancias. Esta configuración es necesaria porque GuardDuty necesita leer la etiqueta de exclusión del servicio de metadatos de instancias (IMDS) para determinar si debe excluir la instancia de la instalación del agente. Para obtener más información, consulte Habilitar el acceso a etiquetas de instancia en los metadatos de la instancia en la Guía del usuario de Amazon EC2.
-
Límite de CPU y memoria para el agente de GuardDuty
- Límite de CPU
-
El límite máximo de CPU para el agente de seguridad GuardDuty asociado a instancias de Amazon EC2 es el 10 por ciento del total de núcleos vCPU. Por ejemplo, si la instancia de EC2 tiene 4 núcleos vCPU, el agente de seguridad puede utilizar un máximo del 40 por ciento del 400 por ciento total disponible.
- Límite de memoria
-
De la memoria asociada a la instancia de Amazon EC2, existe una memoria limitada que el agente de seguridad de GuardDuty puede utilizar.
En la siguiente tabla aparece el límite de memoria.
Memoria de la instancia de Amazon EC2
Memoria máxima para el agente de GuardDuty
Menos de 8 GB
128 MB
Menos de 32 GB
256 MB
Mayor o igual que 32 GB
1 GB
Siguiente paso
El siguiente paso consiste en configurar la Supervisión en tiempo de ejecución y también administrar el agente de seguridad (automática o manualmente).