Antes de eBPF, instrumentar el kernel para detectar amenazas implicaba elegir entre dos malas opciones: módulos del kernel (LKMs) que podían provocar pánicos del sistema y romper la firma del kernel, o agentes en espacio de usuario que perdían eventos y podían ser evadidos con relativa facilidad. Ninguna de las dos era ideal, y muchas veces acababas eligiendo "la menos mala".
eBPF resuelve este dilema porque:
- Verifica el código antes de ejecutarlo: el verificador del kernel rechaza cualquier programa que pueda causar bucles infinitos, accesos inválidos o violaciones de memoria.
- Es portable (CO-RE): "Compile Once Run Everywhere" permite que un mismo binario funcione en kernels distintos sin recompilar.
- Tiene baja sobrecarga: el filtrado y la agregación ocurren dentro del kernel, evitando el coste de copiar grandes volúmenes de eventos al espacio de usuario.
- Soporta hardening: funciona en imágenes endurecidas que prohíben módulos del kernel o lockdown estricto.
El resultado es una telemetría profunda del sistema —syscalls, accesos a archivos, conexiones de red, ejecuciones de procesos— con un coste de rendimiento medible en milisegundos y porcentajes de CPU bajos. La primera vez que vi un dashboard de Falco corriendo en un clúster con 200 nodos y consumiendo apenas un 2% de CPU, me costó creérmelo.
Por qué la seguridad estática no es suficiente en 2026
Escáneres de imágenes, RBAC, network policies y admission controllers son controles preventivos. Útiles, sí, pero con una limitación crucial: una vez que un atacante consigue ejecución dentro de un pod o servidor, ninguno de esos mecanismos detecta el comportamiento posterior. Ni un shell inverso, ni la lectura de /etc/shadow, ni una conexión a un dominio C2, ni la inyección de un binario en memoria.
En 2026, los atacantes utilizan cada vez más malware fileless, técnicas de living-off-the-land y exploits zero-day que modifican procesos en memoria sin tocar el disco. La única forma fiable de detectar y contener estas técnicas es observar el comportamiento del sistema en tiempo real desde el kernel. Lo demás es esperar que tengas suerte.
Las tres herramientas en una frase
- Falco (CNCF, graduado): motor de detección con un DSL de reglas YAML maduro, enfocado en alertar comportamientos anómalos.
- Tetragon (Cilium / Isovalent): observabilidad y enforcement dentro del kernel, capaz de bloquear acciones en el momento exacto en que ocurren.
- Tracee (Aqua Security): captura de eventos de bajo nivel con foco forense y alineación fuerte con MITRE ATT&CK.
Comparativa detallada
Modelo de detección y enforcement
Falco y Tracee son herramientas detection-only: capturan el evento, lo evalúan contra reglas y emiten una alerta. La respuesta queda en manos de tu pipeline (Falcosidekick, SOAR, scripts varios).
Tetragon añade enforcement en el kernel: puede matar el proceso ofensivo, bloquear una syscall o impedir una conexión TCP antes de que se complete. Y eso, en la práctica, convierte la detección en prevención efectiva.
Rendimiento (benchmarks 2025-2026)
Los estudios comparativos publicados en 2025 y los datos públicos de 2026 muestran lo siguiente:
| Métrica | Falco | Tetragon | Tracee |
|---|
| Tipo | Detección | Detección + enforcement | Detección |
| Uso de CPU | Bajo | El más bajo | El más alto |
| Uso de memoria | El más bajo | Bajo | El más alto |
| Latencia añadida | ~10 ms | 5–26 ms | 110–114 ms |
| Detección container escape | Buena | La mejor | Más lenta |
| Detección DoS | La mejor | Buena | Más lenta |
| Forense MITRE ATT&CK | Parcial | Parcial | Fuerte |
| Ecosistema | Independiente | Cilium / Hubble | Aqua |
La ventaja de rendimiento de Tetragon viene de su filtrado agresivo dentro del kernel: en lugar de copiar todos los eventos a espacio de usuario para evaluarlos, las políticas se compilan a programas eBPF que descartan eventos irrelevantes en el origen. Es un detalle técnico, pero marca una diferencia enorme cuando trabajas a escala.
Modelo de eventos y entrega kernel→userspace
- Falco (modern eBPF probe): usa
BPF_MAP_TYPE_RINGBUF para entregar eventos al motor de reglas en espacio de usuario.
- Tetragon: combina ring buffers y
perf events según el componente; las TracingPolicies se compilan a programas eBPF que ya filtran en kernel.
- Tracee: prioriza captura amplia de eventos vía perfbuffer/ring buffer, lo que explica su mayor consumo y latencia, pero también su riqueza forense.
Instalación y configuración de Falco con eBPF moderno
Desde Falco 0.43, el legacy eBPF probe está deprecado. La opción recomendada en 2026 es el modern eBPF probe, que se incrusta en el binario y aprovecha CO-RE: no requiere headers del kernel ni compilar nada en el host. Un alivio para quienes hemos sufrido con DKMS más de la cuenta.
Instalación en un host Linux (Debian/Ubuntu)
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 update
sudo apt install -y falco
Editar /etc/falco/falco.yaml para activar el driver moderno:
engine:
kind: modern_ebpf
modern_ebpf:
cpus_for_each_buffer: 2
buf_size_preset: 4
drop_failed_exit: true
Iniciar el servicio:
sudo systemctl enable --now falco-modern-bpf.service
sudo journalctl -u falco-modern-bpf -f
Despliegue en Kubernetes como DaemonSet
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm upgrade --install falco falcosecurity/falco \
--namespace falco --create-namespace \
--set driver.kind=modern_ebpf \
--set tty=true \
--set falcosidekick.enabled=true \
--set falcosidekick.webui.enabled=true
Reglas Falco: estructura recomendada
La regla siguiente detecta intentos de leer /etc/shadow fuera de procesos legítimos:
- rule: Lectura sospechosa de /etc/shadow
desc: Un proceso no autorizado intento leer /etc/shadow
condition: >
open_read and fd.name=/etc/shadow and not proc.name in
(sshd, login, su, sudo, passwd, chage, useradd, usermod)
output: >
Lectura de /etc/shadow por proceso inusual
(user=%user.name proc=%proc.name cmd=%proc.cmdline container=%container.name)
priority: CRITICAL
tags: [filesystem, mitre_credential_access, T1003.008]
Buenas prácticas para reglas en producción:
- Personaliza siempre en
falco_rules.local.yaml para sobrevivir a actualizaciones.
- Etiqueta cada regla con la técnica MITRE ATT&CK correspondiente para correlacionar en tu SIEM.
- Usa
macros y lists para excluir tu propio stack de observabilidad y evitar falsos positivos.
- Mide la tasa de alertas: un objetivo razonable es <5 alertas/día por clúster tras tuning.
Tetragon: detección y bloqueo dentro del kernel
Tetragon se distribuye como parte de Cilium o de forma independiente. Su modelo de políticas se llama TracingPolicy y permite hookear funciones del kernel, syscalls, uprobes y más. La curva de aprendizaje, eso sí, no es plana —pero merece la pena.
Instalación standalone
helm repo add cilium https://helm.cilium.io
helm install tetragon cilium/tetragon -n kube-system \
--set tetragon.enableProcessCred=true \
--set tetragon.enableProcessNs=true \
--set export.stdout.enabled=true
Política de bloqueo de ejecuciones sospechosas
Esta política bloquea cualquier ejecución de /usr/bin/nc o /bin/bash dentro de pods marcados con la etiqueta app=payments:
apiVersion: cilium.io/v1alpha1
kind: TracingPolicyNamespaced
metadata:
name: deny-shells-in-payments
namespace: payments
spec:
podSelector:
matchLabels:
app: payments
kprobes:
- call: "security_bprm_check"
syscall: false
args:
- index: 0
type: "linux_binprm"
selectors:
- matchArgs:
- index: 0
operator: "Postfix"
values:
- "/bin/bash"
- "/usr/bin/nc"
matchActions:
- action: Sigkill
El kernel mata el proceso (SIGKILL) en el momento exacto del execve(), antes de que el binario malicioso ejecute una sola instrucción de su main(). Es difícil exagerar lo importante que es ese matiz: no se trata de detectar y reaccionar, sino de impedir que ocurra.
Detección de container escape
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: detect-namespace-escape
spec:
kprobes:
- call: "switch_task_namespaces"
syscall: false
args:
- index: 0
type: "task_struct"
- index: 1
type: "nsproxy"
selectors:
- matchActions:
- action: Post
Tracee: foco forense y mapping a MITRE ATT&CK
Tracee destaca cuando necesitas capturar el contexto completo de un evento para análisis forense posterior, no solo alertar. Trae más de 100 firmas precompiladas alineadas con técnicas concretas de MITRE, así que si tu equipo de respuesta a incidentes vive en ATT&CK Navigator, te va a encantar.
Ejecución en un host Linux
docker run --name tracee --rm --pid=host --cgroupns=host \
--privileged \
-v /etc/os-release:/etc/os-release-host:ro \
-v /var/run:/var/run:ro \
aquasec/tracee:latest \
--output json --events container_create,anti_debugging,proc_mem_code_injection
Detección de inyección de código en memoria
Tracee identifica patrones como ptrace(PTRACE_POKETEXT) sobre procesos remotos o uso de process_vm_writev contra binarios privilegiados, marcando el evento con la técnica T1055 Process Injection. Esta es justamente la clase de actividad fileless que escapa a herramientas EDR tradicionales —y es donde Tracee brilla.
¿Cuál elegir? Decisión por escenario
Escenario 1: empezar desde cero en un clúster pequeño/mediano
Empieza con Falco + Falcosidekick. Tienes la curva de aprendizaje más suave, una comunidad enorme y reglas listas para uso. Cuando el equipo madure, añade Tetragon para enforcement quirúrgico. Es el camino que recomiendo siempre que me preguntan.
Escenario 2: ya usas Cilium como CNI
Activa Tetragon directamente. La integración con Hubble te da una vista única de red + comportamiento del proceso, y aprovechas el mismo plano de control. La capacidad de bloquear en el kernel es decisiva en sectores regulados (banca, salud, infraestructura crítica).
Escenario 3: respuesta a incidentes y threat hunting
Despliega Tracee bajo demanda durante investigaciones. Su salida estructurada con técnicas MITRE acelera la creación de timelines y la atribución. No es ideal como agente permanente en nodos sensibles a la latencia, pero como herramienta de forensia en caliente es brillante.
Escenario 4: defensa en profundidad
La combinación más potente en 2026 es Falco para detección amplia + Tetragon para enforcement de políticas críticas. Falco cubre el "qué pasa" en todo el clúster con un coste muy bajo, y Tetragon refuerza los pods de mayor valor (bases de datos, secretos, payments) con bloqueo en kernel. Sí, es más complejidad operativa, pero los equipos serios acaban llegando aquí.
Limitaciones y modelo de amenazas
Las herramientas eBPF asumen que el kernel es un observador confiable. Si un atacante consigue cargar un módulo del kernel malicioso o explotar un fallo del verificador, puede cegar a Falco, Tetragon y Tracee. Por eso:
- Habilita
kernel.modules_disabled=1 y lockdown=confidentiality en hosts críticos.
- Restringe
CAP_SYS_MODULE y CAP_BPF dentro de contenedores.
- Mantén el kernel actualizado: el verificador eBPF ha tenido CVEs históricos que permiten escapes.
- Combina runtime security con telemetría externa (syslog remoto, Wazuh) para detectar el silencio de los agentes locales.
Integración con tu pipeline DevSecOps
El valor de un agente runtime se multiplica cuando sus eventos llegan rápido al sitio correcto. De nada sirve la mejor regla del mundo si la alerta acaba en un canal de Slack que nadie lee.
- Falcosidekick: enruta alertas Falco a Slack, PagerDuty, Loki, Elasticsearch, Kafka, OpenFaaS, etc.
- Tetragon JSON exporter: emite eventos en formato JSON a stdout, ideales para Vector, Fluent Bit o el agente OpenTelemetry.
- Tracee gRPC: expone eventos a procesadores externos (Splunk, Wazuh, Elastic Security).
Define umbrales de severidad y rutas distintas: CRITICAL al on-call inmediato, WARNING al canal de Slack del equipo, INFO al almacén de larga duración para auditoría. Suena obvio, pero te sorprendería cuántos equipos lo mezclan todo en un único firehose.
Checklist de despliegue para producción
- Driver:
modern_ebpf en Falco; Tetragon o Tracee en su versión más reciente.
- DaemonSet en cada nodo con tolerations para nodos de control.
- Reglas/políticas customizadas versionadas en Git, no editadas in situ.
- Falcosidekick o equivalente con enrutado por severidad.
- Allowlist documentada para tu stack de observabilidad y CI/CD.
- Runbook de triage probado en simulacro, con SLOs explícitos.
- Retención: eventos >= 30 días, logs de auditoría >= 90 días.
- Tasa de falsos positivos medida y < 5 alertas/día tras tuning.
- Hardening del host:
modules_disabled, lockdown, capacidades restringidas.
- Backup de los manifiestos de TracingPolicy y rules YAML en repositorio firmado.
Preguntas frecuentes
¿Qué versión mínima de kernel necesito para usar Falco con eBPF moderno?
El modern eBPF probe de Falco requiere kernel 5.8 o superior con BTF habilitado (CONFIG_DEBUG_INFO_BTF=y). En distribuciones modernas como Ubuntu 22.04+, RHEL 9+, Debian 12+ y openSUSE Leap 15.5+ esto está activado por defecto. Si tu kernel es más antiguo, puedes seguir usando el driver eBPF clásico mientras planificas la actualización (que, por cierto, deberías planificar pronto).
¿Tetragon puede reemplazar a Falco en producción?
Tetragon ofrece detección y enforcement, pero su modelo de políticas TracingPolicy es más bajo nivel y exige más conocimiento del kernel que las reglas YAML de Falco. En la práctica, muchos equipos usan ambos: Falco como red de seguridad amplia y Tetragon para reforzar puntos específicos donde el bloqueo en kernel justifica la complejidad operativa.
¿eBPF tiene impacto medible en el rendimiento de mis aplicaciones?
Sí, pero es bajo. Los benchmarks de 2025-2026 muestran latencias añadidas de 5 a 26 ms con Tetragon, ~10 ms con Falco modern eBPF y 110-114 ms con Tracee en cargas pesadas. El consumo de CPU rara vez supera el 5% en nodos típicos. La clave es el filtrado en kernel: cuanto más específica sea tu política, menor el coste.
¿Puedo usar estas herramientas en hosts hardened o sin permitir módulos del kernel?
Sí, y esa es justo una de las grandes ventajas de eBPF: los programas se verifican y ejecutan en una máquina virtual sandboxed dentro del kernel, sin necesidad de cargar módulos. Falco, Tetragon y Tracee funcionan en imágenes con kernel.modules_disabled=1, lockdown estricto y firma de módulos obligatoria, siempre que el kernel exponga las APIs eBPF necesarias.
¿Cómo evito que los falsos positivos saturen al equipo de seguridad?
Tres prácticas son esenciales: (1) personalizar reglas en falco_rules.local.yaml y desactivar las que no apliquen a tu entorno, (2) crear macros que excluyan tu propio stack de observabilidad y CI/CD, y (3) instrumentar la propia tubería de alertas con métricas (alertas/día, tiempo medio de triage) para detectar reglas ruidosas y refinarlas iterativamente.
Conclusión
En 2026, la seguridad runtime con eBPF ya no es una novedad: es el estándar. Falco, Tetragon y Tracee resuelven el mismo problema desde ángulos complementarios. Falco ofrece el mejor punto de partida y la mayor amplitud de reglas, Tetragon convierte la detección en prevención dentro del kernel, y Tracee aporta la profundidad forense que el threat hunting moderno necesita.
La elección correcta no suele ser una sola herramienta, sino una combinación alineada con tu modelo de amenazas, tus requisitos de cumplimiento y la madurez operativa de tu equipo. Mi consejo: empieza por desplegar una en producción esta semana, mide su tasa de alertas y úsalo como base para escalar tu programa de detección y respuesta. Lo perfecto puede esperar; lo necesario, no.
