Falco: deteccion de amenazas en tiempo de ejecucion con eBPF

Actualizado: 2026-05-03

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 es 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 clásico de dropper 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.

Reglas: el 80/20

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

1. Empezar con lo default. Ver qué genera ruido en tu entorno los primeros 2-3 días.
2. Silenciar falsos positivos comunes. Tu backup que copia archivos en /etc/cron.d dispara “escritura en ruta sensible” — pero es legítimo.
3. Añadir reglas específicas de tu stack, por ejemplo: “nadie ejecuta kubectl exec fuera de horario de oficina”.
4. 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 del nodo.

• 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 tiene 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 demasiado — 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.

1. Falco