La detección de amenazas ha vivido dos eras: perímetro (firewalls, IDS de red) y endpoint (EDR en laptops). Contenedores y Kubernetes rompen las asunciones de ambas: el perímetro se vuelve difuso, los endpoints son efímeros. Falco[1], proyecto graduado de la CNCF, ataca el problema desde otra dirección: observar el kernel y alertar cuando alguien ejecuta comportamientos que no encajan. Esta guía cubre qué hace Falco bien, qué no hace y qué necesita alrededor para ser útil en producción.

Puntos clave

  • Falco engancha el kernel de Linux vía eBPF y observa syscalls en tiempo real, sin instrumentar aplicaciones.

  • El driver eBPF moderno (CO-RE, desde Falco 0.34+) es portátil entre kernels y es el recomendado para Debian 12+, Ubuntu 22.04+ y RHEL 9+.

  • Falco no es antivirus ni WAF: es detección de anomalías en syscalls que complementa otras capas de seguridad.

  • Desplegar sin process de respuesta es teatro: las alertas sin triaje son ruido, no defensa.

  • Falcosidekick enruta eventos a Slack, PagerDuty, Loki y docenas de destinos más.

Qué mira Falco

Falco engancha el kernel de Linux (vía eBPF o un módulo tradicional) y observa syscalls en tiempo real. Cada syscall (open, execve, connect, setuid) pasa por sus reglas. Si alguna dispara, Falco emite un evento.

Ejemplos de reglas por defecto:

  • Shell en contenedor: se abre una shell interactiva dentro de un contenedor en producción.

  • Escritura en /etc: un proceso modifica archivos sensibles del sistema.

  • Binario ejecutado desde /tmp: patrón habitual de los cargadores de malware.

  • Conexión saliente inesperada: el contenedor llama a una IP desconocida.

  • Cambio de privilegios: un proceso escala a root sin ser su CMD habitual.

La potencia está en la granularidad: no es "el contenedor hizo algo malo", es "el PID 1234 llamó a execve con argv=/bin/sh dentro del namespace de este pod, y eso no coincide con la baseline".

Arquitectura eBPF vs módulo kernel

Falco soporta tres drivers:

  • eBPF moderno (CO-RE, desde Falco 0.34+): portátil entre kernels, sin compilación, sin módulo cargado. Es el recomendado.

  • eBPF legacy: requiere headers del kernel en build-time.

  • Módulo kernel: el más antiguo. Útil en kernels viejos (<5.8) pero cada vez menos relevante.

Para Debian 12+, Ubuntu 22.04+, Amazon Linux 2023 y RHEL 9+, el driver eBPF moderno funciona sin pelear.

Logotipo de eBPF, la tecnología del kernel de Linux que usa Falco para observar syscalls sin módulos cargados en modo CO-RE

Reglas: el 80/20

Falco incluye falco_rules.yaml con unas 80 reglas out-of-the-box. El camino razonable:

  • Empezar con lo default. Ver qué genera ruido en tu entorno los primeros 2-3 días.

  • Silenciar falsos positivos comunes. Tu backup que copia archivos en /etc/cron.d dispara "escritura en ruta sensible", aunque sea legítimo.

  • Añadir reglas específicas de tu stack, por ejemplo: "nadie ejecuta kubectl exec fuera de horario de oficina".

  • Invertir el resto en runbooks para los eventos reales.

Ejemplo de regla custom:

- rule: Acceso a credenciales AWS
  desc: Acceso al directorio .aws o al metadata EC2
  condition: (fd.name in (~/.aws/credentials) or fd.name=169.254.169.254)
  output: "Posible extracción de credenciales AWS (user=%user.name)"
  priority: WARNING

Salida: SIEM y notificación

Falco genera eventos JSON. Lo que haces con ellos define la utilidad:

  • Falcosidekick (companion oficial): router de eventos a Slack, PagerDuty, Elasticsearch, Loki, Alertmanager y decenas más.

  • Loki + Grafana: eventos como logs, alertas vía Grafana Alerting. Bueno para equipos que ya tienen la pila.

  • SIEM (Splunk, Sentinel, Elastic Security): Falco como fuente de detección entre otras.

El error común es dejar los eventos en /var/log/falco.log y nunca mirarlos. Sin ruteo a un lugar donde se revisen, Falco es ruido local.

Despliegue en Kubernetes

En Kubernetes, Falco se despliega como DaemonSet: un pod por nodo con acceso privilegiado al kernel.

  • Helm chart oficial: falcosecurity/falco, con opciones para driver, reglas y export de eventos.

  • Requiere securityContext privilegiado o hostPID + hostNetwork + capacidades específicas. Eso es superficie de riesgo. Falco acaba con más privilegios que casi cualquier otra cosa en el cluster.

  • Recursos: ~200 MB RAM, 0.1-0.5 CPU por nodo en reposo. Picos durante arranques masivos de pods.

  • Actualización frecuente: las reglas de amenazas cambian; mantén Falco al día.

Dónde Falco no llega

Ser honesto sobre los límites:

  • Ataques en memoria sin syscalls observables pasan por debajo del radar.

  • Comportamiento malicioso dentro de syscalls normales (exfil via HTTPS normal a un C2) requiere reglas específicas contra el destino.

  • Cryptojacking sofisticado puede evitar patrones obvios.

  • Zero-days en el kernel que subvierten eBPF.

Falco no es antivirus ni WAF. Es detección de anomalías en syscalls. Complementa otras capas; no las sustituye.

Integración con Kubernetes Audit

Además de syscalls, Falco puede consumir los logs del Kubernetes API audit log y aplicar reglas sobre acciones de API. Útil para detectar:

  • Cambios en RBAC fuera de horario.

  • Creación masiva de pods privilegiados.

  • Acceso inusual a Secrets.

Operación: lo que duele

Un año operando Falco en producción deja lecciones claras:

  • Actualizar reglas sin versionarlas es caótico. Mantén rulesets en Git con CI que los valida.

  • Drift entre Falco y kernel: cada actualización mayor del kernel puede romper eBPF CO-RE por edge cases.

  • Alert fatigue: si el 90% de alertas son benignas, el 10% importante se pierde. Invierte en refinar reglas.

  • Coste en nodos densos: con 200 pods/nodo el volumen de syscalls se nota en la CPU. Monitoriza el uso de CPU de Falco.

  • Turnover del equipo: si nadie entiende las reglas, nadie las refina. Documenta.

Cuándo adoptar Falco

Claramente útil:

  • Kubernetes en producción con pods de terceros o entornos multi-tenant.

  • Compliance que exige monitorización runtime (PCI DSS, SOC 2 maduro).

  • Equipos con SOC que pueden triaje los eventos.

Marginal o excesivo:

  • Un único nodo Docker. Falco es excesivo: un auditd bien configurado es más simple.

  • Equipos sin proceso de respuesta. Las alertas sin respuesta son teatro, no seguridad.

Relacionado: Falco complementa bien la firma de artefactos con Sigstore: uno protege el supply chain antes del despliegue, el otro detecta comportamientos anómalos en runtime. Y si usas service mesh con mTLS, ambas capas contribuyen a un modelo de seguridad Zero Trust más completo.

Conclusión

Falco es una pieza madura y open source para detección runtime en entornos cloud-native. Requiere inversión en operación (reglas afinadas, rutado de eventos, proceso de respuesta), pero a cambio ofrece visibilidad que las capas tradicionales no alcanzan. Antes de adoptar, pregunta si tu equipo tiene capacidad de procesar sus eventos; si la respuesta es no, priorízala antes que el despliegue. Detectar sin responder es ruido; detectar con respuesta es defensa real.

Fuentes:

  1. Documentación oficial de Falco[2]
  2. Repositorio de Falco en GitHub[3]
  3. Página del proyecto Falco en la CNCF[4]
  4. Kubernetes: Audit Logging en producción[5]

Preguntas frecuentes

¿Qué driver de Falco elijo: eBPF moderno, eBPF legacy o módulo kernel?

El eBPF moderno (CO-RE, disponible desde Falco 0.34+) es portátil entre kernels y no requiere compilación ni módulo cargado. Funciona sin pelear en Debian 12+, Ubuntu 22.04+, Amazon Linux 2023 y RHEL 9+. El eBPF legacy necesita los headers del kernel en build-time, y el módulo kernel solo tiene sentido en kernels viejos, anteriores a 5.8. Ten en cuenta que cada actualización mayor del kernel puede romper eBPF CO-RE por edge cases.

¿Cuántos recursos consume Falco por nodo en Kubernetes?

Unos 200 MB de RAM y entre 0,1 y 0,5 CPU por nodo en reposo, con picos durante arranques masivos de pods. Se despliega como DaemonSet con el Helm chart oficial falcosecurity/falco y necesita securityContext privilegiado o hostPID + hostNetwork con capacidades específicas, así que acaba con más privilegios que casi cualquier otra cosa del cluster. En nodos densos, con unos 200 pods, el volumen de syscalls obliga a monitorizar el uso de CPU de Falco.

¿Qué ataques no detecta Falco?

Los ataques en memoria sin syscalls observables y el comportamiento malicioso dentro de syscalls normales, como la exfiltración por HTTPS a un C2, que exige reglas específicas contra el destino. También el cryptojacking sofisticado que evita patrones obvios y los zero-days del kernel que subvierten eBPF. Falco no es antivirus ni WAF: es detección de anomalías en syscalls que complementa otras capas, por ejemplo la firma de artefactos con Sigstore, pero no las sustituye.

Fuentes

  1. Falco
  2. Documentación oficial de Falco
  3. Repositorio de Falco en GitHub
  4. Página del proyecto Falco en la CNCF
  5. Kubernetes: Audit Logging en producción