Actualizado: 2026-07-07

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 muy 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-RELogotipo 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: 200 pods/nodo equivale a muchos syscalls. 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. 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