¿Qué es XDP y cómo puede ayudar a construir protección anti-DDoS?

Introducción a XDP y cómo puede ayudar a construir protección anti-DDoS

Si ejecutas una API pública, proxy inverso, servicio de juegos u otra carga de trabajo orientada a Internet, puedes llegar a un punto doloroso donde el servidor está ocupado con tráfico que nunca fue útil en primer lugar. La aplicación no necesariamente falla porque no pueda manejar usuarios reales. Falla porque el host está gastando tiempo de CPU recibiendo, analizando, clasificando y llevando paquetes basura más profundamente en Linux antes de que algo diga “no”. Muchos problemas anti-DDoS comienzan allí: no como una historia de ancho de banda, sino como una historia de costo de procesamiento de paquetes.

Eso importa a más que especialistas en kernel. Desarrolladores, auto-hospedadores, operadores de VPS y servidores dedicados, e incluso lectores de negocios comparando opciones de resiliencia, todos se encuentran con la misma pregunta básica: ¿qué tan temprano se puede rechazar el tráfico malo antes de que queme tiempo y recursos que deberían pertenecer al trabajo real? Algunos ataques aplastan el enlace ascendente en sí, pero muchas situaciones dañinas aparecen antes como presión de paquetes por segundo en el host mucho antes de que la línea esté completamente saturada.

Ahí es donde XDP vale la pena entender. No reemplaza la mitigación ascendente, un firewall o controles conscientes de aplicaciones. Lo que ofrece es un punto de control mucho más temprano en la ruta de paquetes de Linux. Este artículo explica qué es XDP, por qué esa posición “más temprana” importa para el trabajo anti-DDoS, y dónde encaja en una pila realista. Para seguir el resto, solo necesitas un conjunto de vocabulario muy pequeño primero.

Palabras clave de XDP que necesitas en 2 minutos

Varios de los términos alrededor de XDP se superponen, y al principio suenan más intimidantes de lo que realmente son. Eso es normal. El punto de este glosario no es convertir el artículo en una lección de Linux internals. Es solo el lenguaje suficiente para ayudar a que el resto de la explicación sea clara.

Si conservas solo un atajo mental de esa tabla, que sea este: eBPF es el mecanismo programable, y XDP es un lugar específico donde ese mecanismo puede ejecutarse. Con eso en su lugar, el siguiente paso es una pregunta más simple y útil: ¿qué está haciendo realmente XDP?

Qué es realmente XDP

XDP es un gancho de procesamiento de paquetes temprano en Linux. Permite que el sistema ejecute un pequeño programa eBPF en un paquete tan pronto como ese paquete llega a una interfaz de red. En ese momento, Linux puede tomar una decisión rápida: dejar que el paquete continúe (XDP_PASS), descartarlo inmediatamente (XDP_DROP), o manejarlo de otra forma definida. Para este artículo, la parte importante es simple: XDP puede decir “déjalo pasar” o “detenlo aquí” muy temprano.

Linux usa eBPF en varios contextos, no solo en redes. XDP es la versión enfocada en redes construida para el manejo muy temprano de paquetes entrantes. Así que XDP no es otro nombre para eBPF. Es una herramienta basada en eBPF con un rol muy específico.

Ese rol es lo que hace que XDP sea útil para el trabajo anti-DDoS. XDP se ejecuta antes de que los paquetes pasen por las partes más pesadas del camino de redes normal de Linux. Por lo tanto, Linux puede decidir sobre cierto tráfico antes de gastar más esfuerzo en firewalling, seguimiento de conexiones, sockets y eventualmente la aplicación misma. Por eso la verdadera ventaja de XDP no es solo filtrado — es filtrado más temprano.

Además, XDP es útil para más que anti-DDoS. También puede soportar enrutamiento de tráfico y otras tareas de manejo de paquetes. Pero anti-DDoS es el lugar más fácil para ver su valor, porque el beneficio se reduce a una idea práctica: cuanto antes se rechace el tráfico malo, menos trabajo inútil tiene que hacer el servidor. Y para entender por qué eso importa tanto, el siguiente paso es ver exactamente dónde se sitúa XDP en la ruta de recepción de paquetes.

El Modelo Mental: XDP Es la Puerta, No la Recepción

La forma más fácil de imaginar XDP es como un guardia de seguridad en la puerta, no como un recepcionista más adentro del edificio. Si un visitante obviamente no deseado es rechazado en la puerta, el edificio evita una larga cadena de trabajo inútil. Nadie abre la puerta interior, lo registra en un sistema, ni lo acompaña por el pasillo. Si esperas hasta la recepción para rechazarlo, el edificio ya gastó tiempo y atención en la persona equivocada.

El manejo de paquetes de Linux funciona de la misma manera. En una ruta de recepción simplificada, el paquete llega desde la NIC y el controlador, llega a XDP, y solo entonces continúa en el stack de redes del kernel más rico que alimenta conntrack, firewalling, sockets y finalmente la aplicación. Visualmente, la ruta se ve así:

NIC / driver
    ↓
XDP  ← earliest checkpoint
    ↓
kernel networking stack
    ↓
conntrack / firewall
    ↓
socket
    ↓
application

En modo nativo, XDP puede actuar antes de que Linux asigne y complete la estructura sk_buff habitual — el objeto de paquete del kernel más rico que el resto del stack espera. Ese detalle suena pequeño, pero es el corazón de la historia de rendimiento. Si el paquete es obviamente no deseado, descartarlo antes de que Linux construya esa estructura normal significa menos trabajo de CPU, menos movimiento de memoria y menos presión descendente. XDP_PASS existe porque no todos los paquetes son malos; es la acción “continúa” que permite que el tráfico legítimo siga moviéndose. XDP_DROP es la estrella anti-DDoS porque termina el viaje antes de que comience la parte costosa. Otras acciones como REDIRECT también existen, pero no son fundamentales para esta explicación.

Una vez que la ubicación es clara, el valor anti-DDoS — y las limitaciones — se vuelven mucho más fáciles de juzgar de manera realista.

Cómo XDP ayuda contra DDoS — y dónde comienzan sus límites

El caso anti-DDoS para XDP es directo: es una forma económica de rechazar basura obvia antes de que Linux gaste recursos en conntrack, manejo de sockets y entrega en espacio de usuario. Si un host está siendo bombardeado con tráfico de alta velocidad que nunca debería llegar a la aplicación de todas formas, cada paquete descartado temprano es trabajo que el servidor ya no tiene que hacer después. Por eso XDP es más fuerte en el borde L3/L4 del problema: direcciones de origen que ya desconfías, protocolos que no quieres, o patrones de tráfico que claramente no son legítimos para la carga de trabajo.

Esto importa más durante inundaciones de basura donde la parte dolorosa no es el volumen de datos bruto sino el manejo repetido de paquetes. Un proxy inverso, servicio pesado en UDP, o API pública puede volverse lento mucho antes de que el enlace ascendente esté completamente saturado si el host está ocupado clasificando sin sentido. XDP te da una forma de cortar parte de ese desperdicio cerca de la puerta.

📝 Nota: XDP protege los recursos del host mejor de lo que protege un enlace ascendente saturado. Si el enlace que enfrenta al proveedor ya está lleno, el descarte temprano a nivel de host es demasiado tarde para arreglar la ruta de red por sí solo.

Esa distinción es la razón principal por la que XDP pertenece a un diseño en capas en lugar de en un pedestal. La siguiente tabla es la versión práctica de XDP vs nftables vs mitigación ascendente/del proveedor:

En otras palabras, XDP y nftables no son enemigos. Resuelven diferentes partes de la ruta. nftables es más rico y con estado. xdp-filter — la herramienta de demostración utilizada en este artículo — es intencionalmente simple y sin estado, que es exactamente por qué es útil para mostrar el modelo XDP sin pretender reemplazar un cortafuegos completo. Si necesitas seguimiento de conexiones, listas de permitidos en capas, manejo de estado de respuesta, o reglas conscientes de aplicaciones, ya estás describiendo problemas que pertenecen más profundo que esta utilidad de demostración.

Los operadores de producción sí usan descarte de estilo XDP porque el descarte temprano reduce el trabajo posterior. La historia de L4Drop de Cloudflare es un ejemplo bien conocido de por qué ese modelo se volvió atractivo en operaciones reales. Pero la lección importante no es solo el número de paquetes por segundo del titular. Es la lógica de diseño: rechaza el tráfico malo más temprano para que el resto de la máquina pueda seguir sirviendo tráfico real más tiempo.

Los resultados del mundo real dependen mucho del entorno. El soporte de NIC y controlador, si XDP se ejecuta en modo nativo o skb, y la forma del tráfico entrante afectan cuánto beneficio realmente obtienes. Por eso las cifras de paquetes por segundo del titular de proveedores o hiperscalers se tratan mejor como prueba de que el modelo de descarte temprano funciona, no como números que cada VPS debería esperar. Con eso en mente, la siguiente sección muestra cómo se ve XDP en un host Ubuntu real a través de algunas instantáneas de operador seguras.

Cómo se ve XDP en la práctica — Snapshots de comandos

Esta sección es un snapshot de prueba de concepto. El objetivo es hacer que XDP se sienta real en Ubuntu 24.04 con el conjunto relevante de comandos: lo suficiente para cargar un filtro, inspeccionar qué se adjuntó, agregar una regla de bajo riesgo y leer los contadores que importan.

Antes de proceder con la configuración de XDP, primero necesitas descubrir y seleccionar el nombre de la interfaz.

ip -br link

Instala los requisitos previos.

sudo apt update
sudo apt install -y xdp-tools

En el comando siguiente, reemplaza <ifname> con el nombre real de tu interfaz de red, como eth0 o ens3.

sudo xdp-filter load -m skb <ifname>

Los dos primeros comandos son responsables de instalar las herramientas requeridas, asegurando que el entorno tenga todo lo necesario para ejecutar la demostración.

El tercer comando carga xdp-filter en modo skb con la política allow predeterminada. En el host Ubuntu utilizado para este artículo, eso produjo la variante xdpfilt_alw_all con el conjunto completo de características tcp,udp,ipv6,ipv4,ethernet,allow. Elegir -m skb evita asumir soporte XDP nativo en tu NIC o controlador, lo que lo hace más seguro para una primera prueba de concepto.

Para verificar que el programa realmente se adjuntó, ejecuta:

sudo xdp-filter status
ip -details link show dev <ifname>

En xdp-filter status, quieres ver tu interfaz listada con skb mode; en el host de prueba aquí, el conjunto de características cargado mostró tcp,udp,ipv6,ipv4,ethernet,allow. En ip -details link show, un adjunto xdpgeneric y el programa xdp_dispatcher confirman que XDP genérico está activo en esa interfaz.

⚠️ Advertencia: No pruebes políticas de negación predeterminada o reglas de caída amplias en una interfaz remota activa que está llevando tu sesión SSH a menos que tengas recuperación de consola. Este artículo se mantiene con una política allow y una regla de dirección de documentación exactamente por esa razón.

A continuación, inspecciona el descubrimiento de capacidades. Esto te dice qué exponen la NIC y el controlador en la superficie XDP, no cuál será tu rendimiento final.

sudo xdp-loader features <ifname>

La salida exacta varía según el hardware, pero un resultado representativo a menudo contiene líneas como estas:

Lo que más importa aquí es NETDEV_XDP_ACT_BASIC, porque eso te dice que la ruta expone el modelo de acción XDP principal. Banderas adicionales como soporte de redirección son útiles, pero no son necesarias para una simple prueba de concepto anti-DDoS.

A continuación, verifica cómo el cargador XDP está administrando el programa y en qué modo se está ejecutando.

sudo xdp-loader status

En un sistema que funciona, una vista de estado puede verse así:

Esta es una verificación de operador pequeña pero importante. Confirma que XDP no es solo un concepto de regla que vive en el espacio de usuario — hay un programa cargado en la interfaz, y la columna de modo te dice si estás mirando native o skb.

Ahora agrega una regla de ejemplo segura usando una dirección IP de documentación. La bandera -s es útil porque imprime el estado de regla resultante inmediatamente en lugar de dejarte con un éxito silencioso.

sudo xdp-filter ip -s -m src 192.0.2.1

Una respuesta representativa puede verse así:

📝 Nota: xdp-filter utiliza por defecto una política allow. En otras palabras, los paquetes que coinciden con la regla se descartan, y los paquetes que no coinciden con la regla continúan a través de la ruta normal.

Este ejemplo es intencionalmente aburrido. En términos anti-DDoS, también muestra la versión más simple posible de una regla de caída temprana: el tráfico de una fuente que no deseas puede rechazarse antes de que el resto del host invierta mucho trabajo en ello.

Finalmente, inspecciona el estado general en un solo lugar.

sudo xdp-filter status

En un sistema típico, el patrón de salida es el más informativo.

Esta vista de estado es donde la prueba de concepto se vuelve operacionalmente útil. Puedes ver la interfaz cargada, el modo activo, la variante xdp-filter activa, el conjunto de características efectivo y el estado del contador por regla en un comando. XDP_ABORTED, si aparece, es principalmente un depósito de error/depuración en lugar de la acción que planificas. Más importante aún, si el contador de caída permanece en 0, eso no significa que el filtro haya fallado. Solo significa que ningún paquete coincidente golpeó la regla durante la ventana de captura.

💡 Conclusión: Trata xdp-filter como una herramienta simple y sin estado de prueba de concepto, no como un reemplazo para nftables. También ten en cuenta que los paquetes descartados en la capa XDP pueden nunca aparecer en la ruta tcpdump habitual, lo que hace que la salida de estado y los contadores nativos de XDP sean el método de validación más confiable. Si quieres una vista en vivo más tarde, sudo xdp-filter poll -i 2000 es un siguiente paso opcional sensato — pero solo cuando la interfaz ya tiene suficiente tráfico interesante para hacer esa salida útil.

Ver una demostración segura hace la idea concreta. La decisión real, sin embargo, no es si los comandos se ejecutan. Es si esta capa adicional vale la complejidad operacional en el tipo de infraestructura que realmente administras.

Cuándo Vale la Pena Considerar XDP para VPS y Servidores Dedicados

XDP se vuelve interesante cuando una carga de trabajo pública está perdiendo tiempo de CPU significativo en paquetes no deseados antes de que la aplicación pueda responder normalmente. Los buenos candidatos incluyen APIs públicas, proxies inversos, gateways, servicios UDP expuestos a Internet y hosts que regularmente ven suficiente tráfico basura para estresar la ruta de red incluso cuando la aplicación en sí no es el cuello de botella. En esos entornos, el rechazo temprano puede recuperar espacio real del servidor.

También hay muchos casos en los que el filtrado más simple es suficiente. Un sitio web de bajo tráfico, una herramienta interna, una caja de staging o un servicio cuyo requisito real es firewalling de host con estado en lugar de alivio de tasa de paquetes generalmente no necesita XDP primero. Si nftables ya cubre el riesgo sin presión visible en la ruta de paquetes, agregar otra capa puede crear más componentes móviles que valor.

Como marco de decisión rápida:

• El firewalling generalmente es suficiente cuando el tráfico es ligero, la política necesita estado o lógica de servicio más rica, y el host no está visiblemente quemando CPU en paquetes basura.
• XDP vale la pena evaluar cuando el tráfico no deseado llega al host lo suficientemente a menudo como para que el descarte temprano pudiera proteger CPU, conntrack y capacidad de socket.
• La mitigación ascendente sigue siendo obligatoria cuando el modo de fallo real es saturación de enlace del proveedor o inundación volumétrica más grande antes de que los paquetes lleguen a tu servidor.

Los usuarios de VPS deben tener en cuenta una advertencia: las rutas de NIC virtual y la abstracción del proveedor pueden limitar las expectativas de modo nativo incluso cuando el modo skb funciona bien para una demostración. Los servidores dedicados generalmente te dan más control sobre drivers, hardware y observabilidad, por lo que las probabilidades de soporte nativo significativo son mejores allí — pero incluso en metal desnudo, XDP sigue siendo una capa, no la respuesta completa. Si estás evaluando AlexHost u otro proveedor, haz tres preguntas separadas en lugar de combinarlas: qué manejo DDoS ascendente existe, cuánto espacio de host da el plan, y qué controles a nivel de host son realistas en esa plataforma?

Conclusión: XDP es una capa de descarte temprano, no el escudo completo

La forma más clara de pensar en XDP es esta: le da a Linux un punto de control rápido para el tráfico obviamente malo e inundaciones de paquetes, lo que significa que protege mejor los recursos del servidor que protege un enlace ascendente saturado. Por eso XDP es importante en conversaciones anti-DDoS. No reemplaza la mitigación ascendente, el cortafuegos con estado o los controles conscientes de la aplicación. Ayuda haciendo que el host haga menos trabajo inútil.

Entonces la regla general es simple. Si el tráfico no deseado está desperdiciando CPU del host antes de que las cargas de trabajo reales puedan responder, XDP vale la pena evaluar como una capa de descarte temprano. Si el problema principal es un enlace completo o una política que depende del estado y la lógica de la aplicación, XDP debe estar detrás de la mitigación ascendente y el filtrado más profundo en lugar de estar frente a ellos como una respuesta completa. Un siguiente paso natural sería un seguimiento sobre la escritura de programas XDP personalizados o la construcción de una defensa en capas más rica alrededor de la misma idea de descarte temprano.