Seguridad runtime en contenedores: Detecta syscalls sospechosas con Falco y eBPF - Dev.

Los contenedores Docker han transformado el despliegue de software, pero también han creado un punto ciego crítico: la visibilidad de lo que ocurre dentro del proceso en ejecución. Si un atacante logra vulnerar una aplicación web y obtiene una shell dentro del contenedor, las herramientas de seguridad perimetral tradicionales no detectarán el movimiento lateral o la exfiltración de datos. Aquí es donde la seguridad en tiempo de ejecución (Runtime Security) se vuelve obligatoria.

Este tutorial te enseña a implementar Falco, la herramienta de código abierto estándar de la Cloud Native Computing Foundation (CNCF), utilizando el driver moderno eBPF. Lograrás identificar intentos de escalada de privilegios, lectura de archivos sensibles y ejecución de binarios no autorizados en milisegundos.

En resumen — Configura Falco con el driver eBPF en Linux para monitorear llamadas al sistema (syscalls) de forma no intrusiva, permitiendo generar alertas inmediatas ante cualquier comportamiento que rompa el perfil de seguridad de tus contenedores.

Contenido

• Conceptos fundamentales de Falco y eBPF
• Cuándo implementar monitoreo de syscalls
• Guía paso a paso de implementación
• Errores comunes y cómo evitarlos
• Optimización y mejores prácticas
• Preguntas frecuentes

Conceptos fundamentales de Falco y eBPF

Para entender Falco, primero debes comprender qué es una llamada al sistema (syscall). Cada vez que una aplicación dentro de un contenedor necesita leer un archivo, abrir una conexión de red o crear un proceso, debe pedírselo al kernel de Linux a través de una syscall. Falco actúa como un sistema de detección de intrusiones (IDS) que "escucha" estas peticiones y las compara con un conjunto de reglas predefinidas.

💡 Analogía: Imagina que el Kernel de Linux es el recepcionista de un hotel de alta seguridad. Los contenedores son los huéspedes. Falco es el guardia de seguridad que revisa cada petición que los huéspedes le hacen al recepcionista (ej: "quiero la llave de la habitación de mantenimiento"). Si la petición es sospechosa, el guardia activa la alarma inmediatamente.

Históricamente, Falco utilizaba un módulo del kernel para interceptar estas señales, lo que podía comprometer la estabilidad del sistema si el módulo fallaba. Con la adopción de eBPF (extended Berkeley Packet Filter), Falco ahora puede ejecutar programas de monitoreo dentro del kernel de forma segura y eficiente. eBPF garantiza que el código de monitoreo no bloquee el sistema y tenga un impacto mínimo en el rendimiento (overhead), lo que lo hace ideal para entornos de producción de alta carga.

Cuándo implementar monitoreo de syscalls

El monitoreo de syscalls no es necesario para todas las aplicaciones, pero es indispensable en escenarios de alta criticidad. El primer caso de uso es la detección de Zero-Day exploits. Si una vulnerabilidad desconocida permite a un atacante ejecutar código, lo primero que intentará será descargar herramientas externas (como curl o wget) o modificar archivos en /etc/. Falco detecta estas acciones que la seguridad estática (escaneo de imágenes) ignora.

Otro escenario fundamental es el cumplimiento normativo (Compliance). Estándares como PCI-DSS, SOC2 o HIPAA exigen trazabilidad de quién accedió a qué datos. Falco proporciona un registro detallado de cada ejecución de binarios y acceso a archivos sensibles dentro de los contenedores, facilitando auditorías forenses tras un incidente. Si tu infraestructura maneja datos financieros o personales, el monitoreo runtime es una capa de defensa en profundidad obligatoria.

Guía paso a paso de implementación

Paso 1: Requisitos previos y entorno

Asegúrate de que tu sistema Linux tenga un kernel 4.14 o superior (recomendado 5.8+ para mejor soporte eBPF). Necesitas instalar las cabeceras del kernel para que Falco pueda cargar la sonda eBPF correctamente. En sistemas basados en Ubuntu/Debian, ejecuta:

sudo apt-get update
sudo apt-get install -y linux-headers-$(uname -r)

Paso 2: Instalación de Falco con soporte eBPF

Instalaremos Falco utilizando el repositorio oficial. Una vez instalado, configuraremos el driver para que utilice eBPF en lugar del módulo de kernel tradicional. Esto evita ensuciar el kernel con módulos de terceros y facilita las actualizaciones de seguridad.

# Agregar repositorio oficial
curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] https://download.falco.org/packages/deb stable main" | sudo tee /etc/apt/sources.list.d/falcosecurity.list
sudo apt-get update
sudo apt-get install -y falco

# Configurar driver eBPF
sudo falcoctl driver install --type ebpf
sudo systemctl enable falco
sudo systemctl start falco

Paso 3: Creación de una regla personalizada

Por defecto, Falco incluye reglas para detectar shells en contenedores. Vamos a crear una regla específica para detectar cuando alguien intente leer el archivo /etc/shadow desde un contenedor Docker, una señal clara de intento de robo de hashes de contraseñas.

Edita el archivo /etc/shadow/falco_rules.local.yaml:

- rule: Detectar Acceso a Shadow File en Contenedor
  desc: Detecta cualquier intento de lectura de /etc/shadow
  condition: >
    container.id != host and
    fd.name = "/etc/shadow" and
    evt.type = open
  output: >
    Alerta: Acceso no autorizado a archivo sensible (user=%user.name 
    command=%proc.cmdline file=%fd.name container_id=%container.id)
  priority: CRITICAL
  tags: [software_security, sensitive_files]

Después de guardar, reinicia el servicio: sudo systemctl restart falco. Para probarla, ejecuta un contenedor y trata de leer el archivo: docker run --rm -it alpine cat /etc/shadow. Verás la alerta en /var/log/syslog o mediante journalctl -u falco.

Errores comunes y cómo evitarlos

El error más frecuente es la saturación de CPU debido a reglas mal optimizadas. Si creas una regla que monitorea cada llamada read en un servidor de bases de datos de alto tráfico, Falco intentará procesar millones de eventos por segundo, degradando el rendimiento del host. Siempre utiliza filtros específicos (como fd.name o proc.name) para reducir el alcance de la inspección.

⚠️ Error frecuente: Olvidar actualizar las cabeceras del kernel (kernel-headers) tras una actualización del sistema. Si el kernel cambia y las cabeceras no coinciden, la sonda eBPF de Falco fallará al cargar y quedarás sin protección en runtime.

Otro problema común es ignorar los "falsos positivos" en las reglas por defecto. Herramientas de monitoreo legítimas o procesos de backup pueden activar alertas de "escritura en directorios sensibles". No desactives Falco; en su lugar, utiliza la sección exceptions en las reglas locales para añadir una lista blanca de procesos confiables basada en su hash o nombre de ejecutable.

Optimización y mejores prácticas

Para entornos productivos, no confíes solo en los logs locales. Implementa Falcosidekick, una herramienta complementaria que recibe los eventos de Falco y los reenvía a más de 50 destinos como Slack, Discord, Elasticsearch, Datadog o incluso funciones Lambda para respuesta automática (ej: matar el contenedor sospechoso automáticamente).

En cuanto al rendimiento, utiliza siempre el driver eBPF moderno (libscap con soporte de modern BPF) si tu kernel es 5.8+. Este driver es notablemente más rápido y estable bajo estrés que las versiones anteriores. Mantén una política de "reglas mínimas necesarias": empieza con el set de reglas stable y solo añade reglas personalizadas para archivos o sockets específicos de tu aplicación de negocio.

📌 Puntos clave:

• Falco detecta amenazas en tiempo real mediante syscalls.
• eBPF permite un monitoreo seguro sin riesgo de pánico en el kernel.
• La configuración correcta incluye instalar linux-headers y el driver eBPF.
• Las reglas deben ser específicas para evitar impacto en el rendimiento.
• Integra Falcosidekick para centralizar la respuesta ante incidentes.

Frequently Asked Questions

Q. ¿Cuál es el impacto real en el rendimiento al usar Falco con eBPF?

A. El overhead suele ser inferior al 1-3% de CPU en condiciones normales, mucho menor que las soluciones basadas en agentes en espacio de usuario.

Q. ¿Puede Falco detener un ataque automáticamente (IPS)?

A. Por sí solo es un IDS (detección), pero integrado con Falcosidekick y un controlador de respuesta, puede destruir pods o contenedores en respuesta a una alerta.

Q. ¿Funciona Falco en entornos de contenedores sin Docker, como containerd o Podman?

A. Sí, Falco escucha syscalls a nivel de kernel, por lo que es independiente del runtime de contenedores utilizado.