Firewall eBPF: Protege tu servidor sin overhead

Un desarrollador cansado de que iptables colapse durante ataques HTTP flood construyó un firewall en Rust usando eBPF/XDP que procesa tráfico sin consumir CPU adicional. El código maneja 24 millones de paquetes por segundo en un single core, versus los 10 millones máximos que iptables soporta, evitando los crashes clásicos durante DDoS intensos.

¿Qué es eBPF y por qué importa?

eBPF (extended Berkeley Packet Filter) es una máquina virtual que corre dentro del kernel de Linux, permitiéndote ejecutar código de seguridad sin modificar el kernel ni cargar módulos compilados. Diseñado originalmente para filtrado de paquetes, evolucionó hasta convertirse en la base de firewalls, monitores de rendimiento, y detección de amenazas en los data centers más grandes del planeta. La ventaja: instalas el código, Linux lo verifica, corre en modo JIT (just-in-time compiled), y obtés rendimiento casi nativo sin overhead.

XDP (eXpress Data Path) es el complemento perfecto. Es un hook que opera en el driver de la NIC, no en el kernel. Los paquetes llegan a la tarjeta de red, XDP los intercepta antes de que el kernel siquiera se entere que existe tráfico, decide DROP o PASS en microsegundos, y listo. (Spoiler: esto es lo que hace que no hayas visto tu CPU al 100% durante un DDoS real si usás Cloudflare.)

El problema clásico: iptables colapsando durante floods

Ponele que tu servidor recibe 50.000 paquetes por segundo durante un ataque HTTP flood. Subís la regla limit en iptables, probás local, funciona bárbaro, lo mandás a producción y de repente ves ESTABLISHED connections caídas, la load average en 300, y el servidor respondiendo en 30 segundos a requests legítimas.

¿Por qué? iptables procesa paquetes después que llegaron al kernel. Cada regla es evaluada secuencialmente en la cadena INPUT, después que el kernel ya hizo context switch, ya copió los datos del paquete a memoria kernel, ya incremented counters. Con 50.000 paquetes/seg, la máquina se gasta el 90% del CPU solo moviendo bytes, evaluando reglas, y el módulo ‘limit’ no fue diseñado para defenderse de inundaciones genuinas, solo para rate-limiting suave. Para más detalles técnicos, mirá ejecuta código localmente sin dependencias.

El resultado es predecible: pérdida de paquetes legítimos, timeouts de conexión, bases de datos sobrecargadas tratando de reconectar, y chaos. Iptables típicamente soporta ~10 millones de paquetes por segundo máximo antes de saturar en un single core. Después, es un despelote.

Cómo eBPF/XDP cambia el juego

En lugar de procesar paquetes en el kernel después de que llegaron, eBPF + XDP los captura en el driver de la NIC. El paquete llega a la tarjeta → XDP corre el programa eBPF compilado → decisión DROP/PASS en nanosegundos → siguiente paquete. Sin context switch, sin copia de datos a kernel, sin evaluación secuencial de cadenas. Solo decisión binaria a la velocidad del hardware.

El flujo real es así:

• Paquete llega a NIC
• XDP invoca programa eBPF en modo JIT (just-in-time compiled)
• eBPF consulta BPF maps (almacenamiento kernel, estructura HashMap) para IP blocklist
• Si IP está en mapa, retorna XDP_DROP → paquete descartado en la NIC
• Si es legítima, retorna XDP_PASS → sigue al kernel como siempre
• Todo ocurre ANTES que el kernel vea el paquete

El resultado: Cloudflare logra procesar millones de paquetes por segundo sin consumir CPU del kernel, porque el trabajo lo hace el driver de la NIC, que es hardware especializado.

Rendimiento demostrado: números reales

Los benchmarks no son teoría:

La diferencia no es un 10%. eBPF procesa 2.4x más volumen que iptables con CPU 0. Cloudflare, en producción 2024, mitigó un ataque de 3.8 Tbps usando eBPF L4Drop sin que sus servidores de origen se enteraran. Meta procesa tráfico de millones de usuarios en data centers con eBPF. F5 NGINX App Protect DoS también usa eBPF para detección inline.

¿Qué significa eso? Que si estás corriendo Kubernetes, un load balancer, o un CDN propio en 2026, eBPF no es una “opción futura”, es la realidad del mercado. iptables está obsoleto para DDoS mitigation en escala.

Implementación práctica en Rust con Aya

El lenguaje de elección para eBPF es Rust con el framework Aya, que genera bytecode eBPF verificado por el kernel. La estructura básica:

Lado kernel (eBPF): HashMap en espacio kernel que almacena IPs bloqueadas. Al recibir un paquete, XDP consulta ese mapa. Si la IP fuente está bloqueada, retorna XDP_DROP. Si no, XDP_PASS.

Lado userspace (Rust): Tu aplicación carga el programa eBPF en el kernel usando bpftool o la biblioteca Aya, llena dinámicamente la HashMap con IPs bloqueadas (desde una base de datos, API externa, detección en tiempo real), y monitorea eventos. Ya lo cubrimos antes en capas críticas de seguridad.

Proyecto referencia: Aegis-eBPF en GitHub es un firewall open-source escrito en Rust que hace exactamente esto. Versión 1.0 con soporte full para connection tracking, análisis de tráfico, y reglas dinámicas. El código es limpio, verificable, y listo para producción.

Casos de uso en producción 2024-2026

Cloudflare L4Drop: Sistema de mitigación DDoS que corre eBPF en los servidores edge de Cloudflare. Genera fingerprints de tráfico malicioso, inyecta programas eBPF dinámicamente en tiempo real, y descarta millones de paquetes falsificados por segundo sin afectar tráfico legítimo.

Meta: Procesa tráfico de millones de usuarios con eBPF en sus data centers. Cada paquete pasa por verificación eBPF. Sin ello, el CPU sería insostenible.

F5 NGINX App Protect DoS: Usa eBPF para detección inline de patrones de ataque. Funciona a velocidad de línea (hasta 400 Gbps en algunos modelos).

Red Hat / Kubernetes: Los firewalls CNI (Container Network Interface) en Kubernetes 2026 ya cuentan con opciones eBPF como Cilium y Calico, que ofrecen política de red a nivel kernel sin overhead.

eBPF vs iptables vs nftables: comparativa técnica

La razón por la que eBPF gana es simple: todo ocurre en el espacio del driver NIC o kernel, sin context switch a userspace, sin copia de datos, sin evaluación de múltiples reglas. iptables necesita pasar por cadenas PREROUTING, FORWARD, INPUT, evaluando cada regla. nftables es más legible que iptables, pero sigue siendo kernel-space sin ventaja de XDP. Relacionado: exponé herramientas CLI como servicios.

Limitaciones técnicas y cuándo usar qué

Requisitos para eBPF/XDP:

• Kernel Linux 4.15+ (XDP base). 5.8+ recomendado para estabilidad
• NIC moderna con soporte XDP nativo (Intel 82599, Mellanox ConnectX, Netronome, Broadcom)
• Permisos root o CAP_SYS_ADMIN para cargar programas eBPF
• No requiere compilación de kernel ni módulos adicionales

Casos donde eBPF es overkill:

Si tu servidor recibe tráfico predecible, pocas reglas, y nunca fue atacado, iptables todavía funciona. El overhead de aprender eBPF no lo justifica. Pero si estás en producción con tráfico creciente, Kubernetes, o edge computing, eBPF es el estándar 2026.

Casos donde seguir con iptables:

Servidores viejos con kernel 3.x que no podés actualizar. A esa altura, el overhead de iptables es lo de menos; tenés problemas mayores. Pero si podés actualizar kernel, eBPF no cuesta nada.

Cuándo nftables es suficiente:

Si necesitás reglas L7 (inspección de protocolo de aplicación), firewalls de aplicación (WAF), o casos donde la sintaxis legible de nftables vale más que el rendimiento de eBPF. Pero para DDoS mitigation y tráfico de alto volumen, eBPF gana sin competencia.

Errores comunes al implementar eBPF

1. Asumir que XDP es “gratis” en términos de complejidad

eBPF requiere debugging diferente. No podés poner printf() y revisar logs como en aplicaciones normales. El bytecode eBPF se ejecuta adentro del kernel. Esto significa: aprender bpftool, entender mapas BPF, testear localmente primero en loopback. La curva de aprendizaje es real. Solución: usá Aya (wrapper Rust) que abstrae la complejidad, o consultá la documentación de RedHat antes de meterte en kernel space. Más contexto en automatiza tests en tu pipeline.

2. Cargar programas eBPF sin verificar que el kernel tenga soporte XDP

No todos los kernels 4.15+ tienen XDP en la NIC. Algunos tienen XDP genérico (generic XDP en software, más lento) pero no native XDP. Ojo con esto si estás en VPS compartido o cloud no configurado. Solución: antes de implementar, corré `ip link show` y buscá “xdpoffload” o “xdp”. Si no está, tu proveedor no lo soporta.

3. Olvidar sincronizar la blocklist entre kernel y userspace

Actualizás tu HashMap de IPs bloqueadas en userspace, pero el kernel no se entero. Los paquetes viejos siguen pasando. Solución: eBPF maps se sincronizan automáticamente si usás la API correcta (libbpf o Aya), pero tené cuidado con race conditions. Si cargás IPs desde una API externa, hacelo en un thread separado que actualice el mapa atómicamente.

Preguntas Frecuentes

¿Qué diferencia hay entre eBPF genérico y XDP offload?

eBPF genérico corre en software dentro del kernel (más lento, ~10M paquetes/seg). XDP nativo corre en el driver de la NIC (24M paquetes/seg). XDP offload corre directamente en el hardware de la tarjeta (100+ millones de paquetes/seg, pero solo en NICs especializadas tipo Netronome). Empezá con XDP nativo; offload es para infraestructura gigante tipo Cloudflare.

¿Cloudflare realmente usa eBPF para todos sus ataques DDoS?

No para todos, pero sí para los más grandes. Cloudflare L4Drop es su sistema eBPF que manejó el ataque de 3.8 Tbps en 2024. Para ataques más pequeños, usan reglas iptables/nftables tradicionales. El punto: cuando el volumen es gigante, eBPF es la única opción que no quema el CPU.

¿Necesito Rust para escribir eBPF?

No obligatoriamente. Podés escribir eBPF en C puro y compilarlo con clang, o usar frameworks como libbpf. Rust (con Aya) es más seguro porque chequea tipos en compiletime. Pero si preferís C, funciona igual. La ventaja de Rust es que el compilador te atrapa errores antes de correr.

¿Puedo migrar desde iptables a eBPF sin downtime?

Sí. Cargás el programa eBPF sin desactivar iptables. Los paquetes se deciden en eBPF (XDP) primero; si pasan, luego iptables los evalúa. Cuando estés seguro de que eBPF funciona, desactivás iptables. Pero es una buena idea testear en staging primero, porque eBPF es más rápido y podrías descubrir comportamientos ocultos en iptables.

¿eBPF funciona dentro de contenedores Docker?

El programa eBPF corre en el host (kernel del host), no dentro del contenedor. Los contenedores pueden usar eBPF si el kernel del host lo soporta, pero no pueden cargarlo. Si estás en Kubernetes, la solución es CNI eBPF (Cilium, Calico) que maneja eBPF en el host y expone políticas a nivel pod. No intentes cargar eBPF desde dentro de un contenedor; no funcionará.

Conclusión

eBPF y XDP no son conceptos teóricos de 2024 esperando adopción. Son la tecnología de producción que Cloudflare, Meta, y proveedores cloud usaron durante 2025-2026 para sobrevivir ataques DDoS masivos. Si tu infraestructura corre en kernel Linux 5.x o superior y tenés NIC moderna, tenés acceso a la tecnología más avanzada de mitigación de seguridad disponible.

iptables sigue siendo válido para configuraciones simples, pero en escala web o bajo ataque, es combatir con espadas de madera. Rust + Aya + eBPF/XDP es el camino. El overhead de aprender es bajo comparado con la ganancia de rendimiento y seguridad. Empezá con Aegis-eBPF en GitHub o los tutoriales de RedHat si querés código listo, o escribí tu propio firewall en Rust si necesitás lógica customizada. De cualquier forma, eBPF es lo que deberías estar usando en 2026.

Fuentes

• Cloudflare L4Drop: XDP-eBPF Based DDoS Mitigations — Arquitectura de mitigación de ataques DDoS masivos usando eBPF en tiempo real
• Aegis-eBPF en GitHub — Firewall open-source en Rust con eBPF/XDP, listo para producción
• Harnessing eBPF and XDP for DDoS Mitigation with Rust y Aya — Tutorial práctico de implementación en Rust
• RedHat: Getting Started with XDP and eBPF — Documentación oficial de configuración y debugging
• Mitigación de DDoS con iptables: limitaciones y alternativas — Análisis de por qué iptables falla bajo floods intensos