¿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, un proxy inverso, un servicio de juegos u otra carga de trabajo expuesta 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 puede manejar usuarios reales. Falla porque el host está gastando tiempo de CPU recibiendo, analizando, clasificando y llevando paquetes basura más profundo en Linux antes de que algo diga “no”. Muchos problemas anti-DDoS comienzan ahí: no como una historia de ancho de banda, sino como una historia de costo de procesamiento de paquetes.

Eso importa más allá de los especialistas en kernel. Desarrolladores, auto-alojadores, operadores de VPS y servidores dedicados, e incluso lectores empresariales que comparan opciones de resiliencia se topan con la misma pregunta básica: ¿qué tan pronto puede rechazarse el tráfico malo antes de que consuma tiempo y recursos que deberían pertenecer al trabajo real? Algunos ataques saturan el enlace de subida 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 upstream, un firewall ni controles conscientes de la aplicación. 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 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 objetivo de este glosario no es convertir el artículo en una lección de internos de Linux. Es solo el lenguaje suficiente para ayudar a que el resto de la explicación aterrice claramente.

Si solo conservas 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 al sistema ejecutar 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 manera definida. Para este artículo, la parte importante es simple: XDP puede decir “déjalo pasar” o “detenerlo 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. Por lo tanto, XDP no es otra palabra para eBPF. Es una herramienta basada en eBPF con un rol muy específico.

Ese rol es lo que hace útil a XDP para el trabajo anti-DDoS. XDP se ejecuta antes de que los paquetes pasen por las partes normales y más pesadas de la ruta de red de Linux. Por lo tanto, Linux puede decidir sobre cierto tráfico antes de gastar más esfuerzo en firewall, seguimiento de conexiones, sockets y finalmente la aplicación misma. Por eso la ventaja real de XDP no es solo el filtrado — es el filtrado más temprano.

Además, XDP es útil para más que anti-DDoS. También puede soportar dirección 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 mirar exactamente dónde se ubica XDP en la ruta de recepción de paquetes.

El Modelo Mental: XDP es la Puerta, No el Mostrador de Recepción

La forma más fácil de visualizar XDP es como un guardia de seguridad en la puerta, no como un recepcionista más adentro del edificio. Si un visitante claramente 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 lleva por el pasillo. Si esperas hasta el mostrador de 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 el NIC y el driver, alcanza XDP, y solo entonces continúa hacia la pila de red del kernel más rica que alimenta conntrack, firewall, 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 native mode, XDP puede actuar antes de que Linux asigne y llene la estructura habitual sk_buff — el objeto de paquete del kernel más rico que espera el resto de la pila. Ese detalle suena pequeño, pero es el corazón de la historia de rendimiento. Si el paquete es claramente no deseado, descartarlo antes de que Linux construya esa estructura normal significa menos trabajo de CPU, menos presión de memoria y menos presión descendente. XDP_PASS existe porque no todos los paquetes son malos; es la acción de “continuar” 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. También existen otras acciones como REDIRECT, pero no son fundamentales para esta explicación.

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

Cómo XDP Ayuda en Anti-DDoS — y Dónde Comienzan Sus Límites

El caso anti-DDoS para XDP es sencillo: es una forma económica de rechazar basura obvia antes de que Linux gaste recursos en conntrack, manejo de sockets y entrega al espacio de usuario. Si un host está siendo bombardeado con tráfico de alta tasa que nunca debería llegar a la aplicación de todos modos, 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 en las que ya no confí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, un servicio con mucho UDP, o una API pública puede volverse lenta mucho antes de que el enlace de subida esté completamente saturado si el host está ocupado clasificando tonterías. 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 upstream saturado. Si el enlace hacia el 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 estar en un pedestal. La siguiente tabla es la versión práctica de XDP vs nftables vs mitigación upstream/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 usada 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 firewall completo. Si necesitas seguimiento de conexiones, listas de permitidos en capas, manejo de estado de respuesta, o reglas conscientes de la aplicación, ya estás describiendo problemas que pertenecen más profundo que esta utilidad de demostración.

Los operadores de producción usan el descarte estilo XDP porque el descarte temprano reduce el trabajo descendente. 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: rechazar el tráfico malo antes para que el resto de la máquina pueda seguir sirviendo tráfico real por más tiempo.

Los resultados del mundo real dependen en gran medida del entorno. El soporte de NIC y driver, si XDP se ejecuta en native mode o en modo skb, y la forma del tráfico entrante afectan cuánto beneficio obtienes realmente. Por eso las cifras de paquetes por segundo de los titulares de proveedores o hiperescaladores 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 capturas de pantalla seguras de operador.

Cómo se Ve XDP en la Práctica — Capturas de Comandos

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

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

ip -br link

Instala los requisitos previos.

sudo apt update
sudo apt install -y xdp-tools

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

sudo xdp-filter load -m skb <ifname>

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

El tercer comando luego carga xdp-filter en modo skb con la política allow predeterminada. En el host Ubuntu usado 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 driver, lo que lo convierte en la ruta más segura 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 el XDP genérico está activo en esa interfaz.

⚠️ Advertencia: No pruebes políticas de deny-default ni reglas de descarte amplias en una interfaz remota activa que lleva tu sesión SSH a menos que tengas recuperación por 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 el NIC y el driver 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. Indicadores adicionales como soporte de redirección son útiles, pero no son necesarios para una prueba de concepto anti-DDoS simple.

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

sudo xdp-loader status

En un sistema funcionando, 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. El indicador -s es útil porque imprime el estado de la 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 usa 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 por 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 descarte temprano: el tráfico de una fuente que no quieres puede rechazarse antes de que el resto del host invierta mucho trabajo en él.

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 activa de xdp-filter, el conjunto de características efectivo y el estado del contador por regla en un solo comando. XDP_ABORTED, si aparece, es principalmente un bucket de error/depuración en lugar de la acción que planeas. Más importante aún, si el contador de descarte se mantiene en 0, eso no significa que el filtro falló. Solo significa que ningún paquete coincidente golpeó la regla durante la ventana de captura.

💡 Conclusión: Trata xdp-filter como una herramienta simple de prueba de concepto sin estado, no como un reemplazo de nftables. También ten en cuenta que los paquetes descartados en la capa XDP pueden nunca aparecer en la ruta habitual de tcpdump, lo que hace que la salida de estado nativo de XDP y los contadores 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 que esa salida sea útil.

Ver una demostración segura hace que la idea sea 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 gestionas.

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

XDP se vuelve interesante cuando una carga de trabajo orientada al público 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 con mucho 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 más temprano puede recuperar espacio real en el servidor.

También hay muchos casos donde el filtrado más simple es suficiente. Un sitio web de bajo tráfico, una herramienta interna, un servidor de staging, o un servicio cuyo requisito real es un firewall 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 notable en la ruta de paquetes, agregar otra capa puede crear más partes móviles que valor.

Como un marco de decisión rápido:

• El firewall 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 con suficiente frecuencia como para que el descarte temprano pueda proteger la CPU, conntrack y la capacidad de sockets.
• La mitigación upstream sigue siendo obligatoria cuando el modo de fallo real es la saturación del enlace del proveedor o inundaciones volumétricas más grandes antes de que los paquetes lleguen siquiera 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 native mode 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 significativo de native mode son mejores allí — pero incluso en bare metal, XDP sigue siendo una capa, no la respuesta completa. Si estás evaluando AlexHost o cualquier otro proveedor, haz tres preguntas separadas en lugar de combinarlas: ¿qué manejo de DDoS upstream existe, cuánto espacio en el host te 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 primer punto de control rápido para tráfico malo obvio e inundaciones de paquetes, lo que significa que protege los recursos del servidor mejor de lo que protege un enlace upstream saturado. Por eso XDP importa en las conversaciones anti-DDoS. No reemplaza la mitigación upstream, el firewall con estado ni 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 evaluarlo como una capa de descarte temprano. Si el problema principal es un enlace de subida lleno o una política que depende del estado y la lógica de la aplicación, XDP pertenece detrás de la mitigación upstream y el filtrado más profundo en lugar de estar frente a ellos como una respuesta completa. Un siguiente paso natural desde aquí sería un seguimiento sobre cómo escribir programas XDP personalizados o construir una defensa en capas más rica alrededor de la misma idea de descarte temprano.