Esta guía describe cómo configurar la solución sin eBPF de CSM Threats para entornos eBPF desactivados, como AWS Fargate. La solución sin eBPF utiliza un Datadog Agent basado en ptrace.
Esta guía también describe algunas ventajas de la solución ptrace.
La detección de amenazas para Linux sin soporte eBPF está en Vista previa. Para inscribirte, ponte en contacto con tu representante de Datadog.
Resumen de las opciones de Agent
CSM Threats incluye dos opciones de Agent para la detección y la respuesta ante amenazas:
Solución eBPF
Solución sin eBPF con ptrace: Esta versión sólo está disponible cuando eBPF no lo está (versiones 3.4 a 4.14 del kernel de Linux).
eBPF mejora la seguridad validando cada programa a través del verificador del kernel de Linux. Esto garantiza que un programa no pueda bloquearse, ingresar en bucles infinitos o dañar el sistema.
eBPF se compila como JIT (Just In Time) y el bytecode de salida se ejecuta en un sandbox de máquina virtual eBPF. Esto evita cualquier bloqueo del kernel y proporciona un rendimiento competitivo.
Fácil de depurar y mantener, puede cargar programas dinámicamente y tiene acceso a toda la información necesaria para rastrear el espacio de usuario.
Algunos entornos utilizan instancias con kernels antiguos que no tienen eBPF en absoluto. La solución ptrace se proporciona para estos entornos.
Las siguientes funciones no están disponibles en el Agent sin eBPF:
Perfiles de seguridad, proporcionando:
Detección de anomalías
Supresión automática del comportamiento normal para la clasificación de señales
Detección de malware
Detecciones de red
La implementación actual admite arquitecturas y ABI amd64 y arm64, pero puede extenderse a ABI de 32 bits.
Ventajas de la solución ptrace
Una solución basada en ptrace logra un equilibrio entre una sólida detección de amenazas y la disponibilidad absoluta de servicios. Algunas de las ventajas de la solución basada en ptrace son:
Control preciso de procesos: Ptrace proporciona una inspección detallada de la memoria y los registros, salvaguardando las cargas de trabajo críticas de las aplicaciones. Esta visibilidad granular es esencial para identificar amenazas sofisticadas. El analizador procfs (Process Filesystem) de Datadog monitoriza todas las ejecuciones en todo el sistema, lo que permite la finalización quirúrgica de programas maliciosos. procesos. Estas herramientas combinadas protegen de la actividad maliciosa.
Estabilidad operativa: Al operar en el espacio de usuario, ptrace evita las complejidades y los riesgos del espacio del kernel, proporcionando un enfoque más seguro y manejable. En caso de fallos, un Agent basado en ptrace pasa por defecto a un estado abierto a fallos en la capa del sistema operativo, lo que mantiene el sistema intacto, incluso si la aplicación se bloquea.
Rendimiento eficiente: Los tests de referencia realizados recientemente por el equipo de ingeniería de Datadog demuestran que la implementación basada en ptrace de Datadog muestra un rendimiento comparable al de las soluciones basadas en el kernel. En concreto, solo introduce una sobrecarga mínima de alrededor del 3% para las cargas de trabajo de PostgreSQL e impactos insignificantes para las operaciones de Redis, lo que la vuelve muy eficiente para la mayoría de los casos de uso.
Verificación de código abierto: Datadog ha colocado en código abierto el Agent eBPF basado en ptrace, lo que permite a los clientes y a la comunidad de seguridad verificar por sí mismos su seguridad y eficacia, lo que incentiva la transparencia y la confianza en la solución.
Configuración del Agent sin eBPF
Puedes configurar un Agent sin eBPF en varias plataformas, incluidos los hosts Docker y Linux.
El Agent sin eBPF está diseñado para entornos donde eBPF está deshabilitado, utilizando ptrace para la seguridad en tiempo de ejecución, y admite arquitecturas arm64/amd64.
Para desplegar el Agent sin eBPF se requieren comandos y configuraciones de instalación personalizados. En esta sección se proporcionan instrucciones específicas para las instalaciones de hosts Docker y Linux.
La solución sin eBPF incluye dos modos de rastreo para las aplicaciones:
Modo envolvente: Rastrea las aplicaciones desde el inicio.
Modo adjunto: Se adjunta a aplicaciones que ya se están ejecutando, pero conlleva más sobrecarga de rendimiento y limitaciones.
Pasos de la configuración sin eBPF
En Docker se requiere una variable de entorno adicional. Añade la siguiente línea a tu comando de instalación Docker:
Alternativamente, para instalar manualmente los paquetes de compilación personalizados proporcionados por .deb/.rmp, modifica el archivo /etc/datadog-agent/system-probe.yaml para habilitar el modo CWS y sin eBPF de la siguiente manera:
Especifica las configuraciones adicionales de las secciones de configuración del Agent sin eBPF anteriores para instalar la versión personalizada y activar el modo sin eBPF.
Verificar la configuración
Para confirmar tu instalación y configuración del Agent, conéctate a tu Linux host o contenedor Docker y ejecútalo:
sudo /opt/datadog-agent/embedded/bin/system-probe config|grep -A 1 ebpfless
Deberías ver el resultado:
ebpfless:
enabled: true
Configurar el rastreo de aplicaciones con el Agent sin eBPF
Una vez instalado el Agent sin eBPF y configurado para utilizar el modo eBPF-Free, puedes configurar cómo se rastrea tu aplicación. Esta sección te proporciona dos métodos diferentes:
Modo envolvente: (recomendado) En este modo, tu aplicación es lanzada por el envoltorio Datadog que la rastrea desde el inicio utilizando ptrace.
También se rastrean todos los elementos secundarios generados.
Se aplica un perfil seccomp para reducir drásticamente la sobrecarga de ptracing.
Modo adjunto: En este modo, puedes especificar una lista de PID para adjuntar a los procesos de tu aplicación. Esto debe hacerse rápidamente, ya que tu aplicación no será rastreada hasta que lo hagas.
En este modo, no se puede aplicar un perfil seccomp. En consecuencia, hay una pequeña sobrecarga de ptracing.
Ambos modos utilizan el binario *cws-instrumentation que viene en el paquete del Datadog Agent y se encuentra en /opt/datadog-agent/embedded/bin/cws-instrumentation.
Este rastreador se comunica con system-probe (parte del Datadog Agent) en localhost utilizando el puerto 5678. La dirección de system-probe se puede configurar con la opción cws-instrumentation --probe-addr=host:port. La dirección del lado del servidor se puede actualizar mediante la opción runtime_security_config.ebpfless.socket del archivo de configuración /etc/datadog-agent/system-probe.yaml del Agent.
En modo envolvente, el envoltorio de Datadog lanza la aplicación. He aquí un ejemplo:
Si ya dispones de un script init, aquí tienes un ejemplo sencillo de los cambios necesarios:
#!/bin/sh
set -e
### INICIO INFORMACIÓN INIT# Proporciona: my_app# Inicio requerido: $network# Finalización requerida: $network# Inicio predeterminado: 2 3 4 5# Finalización predeterminada: 0 1 6# Descripción breve: Mi aplicación# Descripción: Mi aplicación### FIN INFORMACIÓN INIT# Iniciar el serviciostart(){echo"Starting my app" /opt/datadog-agent/embedded/bin/cws-instrumentation trace -- /usr/bin/myapp &}# Detener el serviciostop(){echo"Stopping my app" pkill -f /usr/bin/myapp
}### lógica principal ###case"$1" in
start) start
;; stop) stop
;; restart) stop
start
;; *)echo $"Usage: $0 {start|stop|restart}"exit1esacexit0
Docker
Para los despliegues de aplicaciones Docker, debes modificar tu archivo Docker para envolver tu aplicación de la siguiente manera:
FROM gcr.io/datadoghq/agent:7 AS datadogagent
FROM ubuntu:latest
COPY --from=datadogagent /opt/datadog-agent/embedded/bin/cws-instrumentation .
ENTRYPOINT ["/cws-instrumentation", "trace", "--"]CMD ["/bin/bash", "-c", "while true; do sleep 1; echo my app is running; done"]
Cuando ejecutes tu aplicación Docker, es importante proporcionarle una capacidad adicional añadiendo --cap-add=SYS_PTRACE a tu comando docker run.
También tienes que conectar el contenedor a Datadog en el puerto 5678 realizando una de las siguientes acciones:
Inicia ambos contenedores con la opción de host --network.
Utiliza la función de [red Docker][6] para ejecutar ambos contenedores en el mismo puente de red.
Se recomienda el modo envolvente, ya que el modo adjunto tiene las siguientes limitaciones:
Se pierde toda la inicialización realizada por la aplicación hasta que Datadog se adjunta a ella.
Al adjuntarse, Datadog no puede configurar un perfil seccomp.
Más sobrecarga de rendimiento.
Si la aplicación rastreada se reinicia, Datadog debe asegurarse de que el rastreador también lo haga.
El modo adjunto se diferencia del modo envolvente en que adjunta directamente el rastreador en una aplicación que ya se está ejecutando, de esta manera:
Los siguientes ejemplos muestran cómo puede integrarse el rastreador en aplicaciones para distintos tipos de despliegue.
Servicio systemd Linux
Si ya dispones de un script init, aquí tienes un ejemplo de cómo integrar el envoltorio utilizando un nuevo servicio systemd:
[Unit]Description=Datadog CWS instrumentation attach to my application
After=datadog-agent-sysprobe.service my-app.service
[Service]ExecStart=/bin/bash -c "/opt/datadog-agent/embedded/bin/cws-instrumentation trace $(for pid in $(pidof myapp);doecho --pid $pid;done)"Restart=on-failure
[Install]WantedBy=multi-user.target
Servicio sysvinit Linux
Si ya dispones de un script init, aquí tienes un ejemplo de cómo integrar el rastreador utilizando un nuevo servicio sysvinit:
#!/bin/sh
set -e
### INICIO INFORMACIÓN INIT# Proporciona: dd_tracing_my_app# Inicio requerido: $network# Finalización requerida: $network# Inicio predeterminado: 2 3 4 5# Finalización predeterminada: 0 1 6# Descripción breve: Rastreo Datadog de mi aplicación# Descripción: Rastreo Datadog de mi aplicación### FIN INFORMACIÓN INIT# Iniciar el serviciostart(){echo"Starting tracing my app" /opt/datadog-agent/embedded/bin/cws-instrumentation trace $(for pid in $(pidof myapp);doecho --pid $pid;done)&}# Detener el serviciostop(){echo"Stopping my app" pkill -f /opt/datadog-agent/embedded/bin/cws-instrumentation
}### lógica principal ###case"$1" in
start) start
;; stop) stop
;; restart) stop
start
;; *)echo $"Usage: $0 {start|stop|restart}"exit1esacexit0
Docker
Para adjuntar el envoltorio a una imagen Docker que ejecute una aplicación, utiliza el siguiente archivo Docker:
FROM gcr.io/datadoghq/agent:7
ENTRYPOINT ["/opt/datadog-agent/embedded/bin/cws-instrumentation", "trace", "--pid", "$PID"]
A continuación, proporciona el PID de host para conectarse a Docker como variable de entorno.
Para adjuntarlo a una solicitud, necesitarás lo siguiente:
Cuando ejecutes la aplicación Docker, añade la capacidad requerida incluyendo --cap-add=SYS_PTRACE en tu comando docker run.
Asegúrate de que el contenedor de la aplicación puede llegar al contenedor Datadog en el puerto 5678 utilizando uno de los siguientes métodos:
Inicia ambos contenedores con la opción de host --network.
Utiliza la función de [red Docker][6] para ejecutar ambos contenedores en el mismo puente de red.
Para asegurarte de que el contenedor de la aplicación se ejecuta en el pid del host (al igual que el Datadog Agent), añada estas opciones: --cgroupns host --pid host.
