¿Qué es un ataque UDP Flood? | DDoS volumétrico de Capa 4 explicado

Un UDP Flood es un ataque volumétrico de Denegación de Servicio Distribuida (DDoS) que envía una alta tasa de paquetes User Datagram Protocol (UDP) a un host objetivo, forzándolo a procesar tráfico que consume ancho de banda, CPU, y recursos de seguimiento de conexión sin nunca requerir que el atacante complete un handshake o reciba una respuesta.

Resumen rápido — UDP no tiene conexión; no hay ningún handshake para validar que un emisor sea real antes de que el receptor procese un paquete. Un UDP Flood abusa de esto enviando volúmenes masivos de datagramas UDP, a menudo a puertos aleatorios o fijos, a menudo con IP de origen falsificadas. El objetivo o descarta los paquetes (consumiendo ancho de banda y CPU) o, si no hay ninguna aplicación escuchando en el puerto de destino, genera una respuesta ICMP Destination Unreachable para cada paquete, que se convierte en su propio drenaje de recursos a escala. La mitigación se apoya en rate limiting, filtrado de origen BCP38, reglas de descarte con estado, y scrubbing upstream, ya que UDP en sí no ofrece ningún mecanismo integrado para distinguir el tráfico legítimo del tráfico de inundación.

Última actualización: 2026-08-08

UDP Flood es una de las técnicas DDoS más antiguas que sigue en uso activo. Las primeras herramientas de ataque distribuido como Trinoo y Stacheldraht, documentadas por CERT/CC en 1999 y 2000, usaban el flooding de UDP como vector volumétrico principal porque no requería ninguna truco a nivel de protocolo; solo suficientes hosts comprometidos enviando suficientes paquetes. Más de dos décadas después, UDP Flood sigue siendo un componente base de la mayoría de los servicios de DDoS-por-encargo (“booter”/“stresser”) porque es trivial de generar y efectivo contra infraestructura sin protección.

Cómo funciona un UDP Flood

TCP requiere un handshake de tres vías antes de que se intercambie cualquier dato; una propiedad que los ataques SYN Flood abusan pero que también le da a los defensores una máquina de estados que inspeccionar. UDP no tiene equivalente. Un emisor transmite un datagrama; el host receptor lo entrega a una aplicación escuchando o lo descarta. No hay sesión, no hay número de secuencia, y ninguna forma integrada de verificar que la dirección de origen sea genuina.

Tráfico UDP normal (ej. consulta DNS):
Cliente (IP real) ──datagrama UDP──▶ Servidor:53
Servidor:53 ──respuesta UDP──▶ Cliente (IP real)

UDP Flood:
Bot 1 (IP falsificada: 198.51.100.5) ──UDP──▶ Objetivo:puerto_aleatorio
Bot 2 (IP falsificada: 198.51.100.9) ──UDP──▶ Objetivo:puerto_aleatorio
Bot 3 (IP falsificada: 203.0.113.2)  ──UDP──▶ Objetivo:puerto_aleatorio
... [millones de paquetes por segundo]

Por cada paquete sin ninguna aplicación escuchando en el puerto de destino:
Objetivo ──ICMP Tipo 3, Código 3 (Port Unreachable)──▶ IP falsificada (nunca el atacante real)

Resultado: enlace entrante saturado con tráfico UDP
        enlace saliente saturado con respuestas de error ICMP
        CPU consumida generando y enrutando esas respuestas

Mecanismo paso a paso:

1. El atacante (o botnet) genera datagramas UDP dirigidos a una o más direcciones IP en la red de la víctima, a alta tasa de paquetes por segundo (PPS) y/o alto ancho de banda.
2. Las direcciones IP de origen se falsifican frecuentemente, lo que evita que la víctima filtre por origen y evita que el tráfico de retorno (incluyendo cualquier error ICMP) llegue al atacante real.
3. El puerto de destino puede ser aleatorio, fijo, o rotado a través de una lista. Si ningún servicio está vinculado a ese puerto, el stack UDP del kernel responde con un mensaje ICMP Destination Unreachable (Tipo 3, Código 3) por cada datagrama rechazado, a menos que se limite la tasa.
4. A suficiente volumen, tres cosas ocurren aproximadamente de forma simultánea: el enlace entrante se satura con tráfico de ataque, el enlace saliente se satura con respuestas de error ICMP, y se consumen ciclos de CPU/interrupción clasificando y descartando paquetes.
5. Los servicios legítimos dependientes de UDP en el mismo enlace —DNS, VoIP, gaming, QUIC/HTTP3— se degradan o fallan porque sus paquetes compiten con el tráfico de inundación por el mismo ancho de banda finito y profundidad de cola.

Por qué el diseño de UDP habilita este ataque

Como UDP no requiere ninguna confirmación para considerarse entregado, un atacante no gana nada al recibir una respuesta y no pierde nada al falsificar el origen. Esta es también la propiedad que explotan la Amplificación DNS y otros ataques de reflexión; UDP Flood es la versión directa y no reflejada de la misma debilidad subyacente.

UDP Flood vs. ICMP Flood vs. SYN Flood

Variaciones del ataque

Flood de puerto aleatorio. El atacante apunta a puertos de destino aleatorios en el host víctima. Como la mayoría de los puertos no tienen ningún servicio vinculado, casi cada paquete dispara una respuesta ICMP Port Unreachable, duplicando el costo de recursos (procesar el paquete entrante y generar el error saliente).

Flood de puerto fijo. El atacante apunta a un solo puerto conocido como abierto, comúnmente un resolver DNS (53), un puerto de servidor de juego, o un puerto VoIP/SIP (5060). Esto evita disparar respuestas ICMP Unreachable pero en cambio fuerza a la aplicación escuchando a procesar (y típicamente descartar) cada paquete, cambiando el costo de la ruta de generación de ICMP del kernel al loop de lectura de la aplicación.

Flood UDP fragmentado. El atacante envía payloads UDP más grandes que el MTU de la ruta, forzando la fragmentación a nivel IP. El objetivo debe reensamblar los fragmentos antes de poder siquiera determinar si existe una aplicación escuchando, lo que aumenta el costo de CPU y memoria por paquete. Esta variante se superpone conceptualmente con los ataques de fragmentación IP; consulta ese artículo para el abuso específico de reensamblado como fragmentos diminutos y offsets superpuestos.

Flood UDP reflejado/amplificado. En lugar de enviar paquetes directamente, el atacante falsifica la IP de la víctima como origen de pequeños requests UDP a servidores de terceros (DNS, NTP, memcached, CLDAP) que responden con respuestas mucho más grandes. Esto es funcionalmente un UDP Flood en el enlace de la víctima pero se categoriza por separado porque el volumen de tráfico que el atacante debe generar es una fracción de lo que recibe la víctima. Consulta Amplificación DNS para la mecánica del factor de amplificación.

Señales de detección y telemetría

La detección de UDP Flood depende de anomalías de volumen y proporción en lugar de anomalías de estado de protocolo, ya que UDP no tiene estado que inspeccionar.

# Contadores de tráfico por protocolo
netstat -su
# Busca "packet receive errors" y "receive buffer errors" en aumento

# Resumen de estadísticas de sockets
ss -u -a -n

# Contadores UDP e ICMP a nivel de kernel
nstat -az | grep -iE "udp|icmp"

# Captura en vivo de tráfico UDP a un puerto sospechoso (usa muestreo en producción; la captura completa puede agregar carga)
tcpdump -i eth0 udp and dst port 53 -c 200

# Contador de nftables en una regla que coincide con tráfico UDP para monitorear volumen sin bloquear
nft add rule inet filter input udp counter

# Equivalente de iptables
iptables -I INPUT -p udp -j LOG --log-prefix "UDP-MONITOR: " -m limit --limit 5/min

NetFlow, IPFIX, o sFlow son preferibles a la captura completa de paquetes a PPS alto, ya que las propias herramientas de captura pueden agregar overhead de CPU durante una inundación activa.

Técnicas de mitigación

Como UDP Flood es fundamentalmente un problema de volumen, la mitigación on-premise está limitada por la capacidad del enlace local y el firewall; una vez que el volumen entrante excede el ancho de banda de uplink, ninguna regla local puede restaurar la disponibilidad. La defensa efectiva contra UDP Flood por lo tanto combina higiene local (límites de tasa, descarte de puertos no usados, rate limiting de ICMP) con capacidad de absorción upstream o basada en edge suficientemente grande para exceder los volúmenes de ataque realistas.

Errores comunes

Cómo implementarlo con Azion

La red distribuida de Azion puede ayudar a absorber y filtrar el tráfico de UDP Flood antes de que llegue a tu origen, dependiendo de los productos habilitados y cómo estén configurados:

• DDoS Protection brinda detección y mitigación siempre activa para tráfico volumétrico, incluyendo UDP floods, en el edge de red en lugar de en tu origen.
• Network Shield puede aplicar reglas a nivel de red como rate limiting y filtrado basado en protocolo para reducir el impacto de tráfico UDP anómalo antes de que llegue a la infraestructura de aplicación.
• Firewall permite reglas personalizadas para permitir, descartar, o limitar la tasa del tráfico UDP por puerto, patrón de origen, u otros criterios específicos de tu entorno.
• WAAP combina controles de red y de capa de aplicación cuando la presión volumétrica basada en UDP se combina con intentos de ataque a nivel de aplicación.

Como la red Anycast de Azion distribuye el tráfico entrante a través de muchos puntos de presencia, un UDP Flood dirigido a una sola IP se distribuye entre los centros de datos más cercanos a cada origen de tráfico, reduciendo la concentración de impacto en cualquier enlace individual, aunque la distribución real depende del enrutamiento, la topología, y las políticas configuradas.

Recursos relacionados

• ¿Qué es un ataque DDoS?
• Tipos de ataques DDoS
• ¿Qué es la protección y mitigación DDoS?
• ¿Qué es un ataque ICMP Flood?
• ¿Qué es un ataque de fragmentación IP?
• Azion DDoS Protection
• Azion Network Shield

Preguntas frecuentes

¿Qué es un ataque UDP flood? Un ataque UDP flood envía un gran volumen de paquetes User Datagram Protocol a un host objetivo o puertos específicos, explotando la falta de handshake de UDP para abrumar el ancho de banda, la capacidad de procesamiento de paquetes, o la capacidad del objetivo para generar respuestas de error ICMP. No requiere ningún truco de protocolo para lanzarse, que es por lo que sigue siendo uno de los vectores DDoS más comunes ofrecidos por servicios de booter y stresser.

¿En qué se diferencia un UDP flood de un SYN flood? Un UDP flood agota el ancho de banda y la capacidad de procesamiento de paquetes porque UDP no mantiene estado de conexión. Un SYN flood agota una estructura de datos específica del kernel —la tabla de conexión— abusando del estado semi-abierto del handshake TCP. Los UDP floods generalmente requieren alto volumen para ser efectivos; los SYN floods pueden tener éxito a ancho de banda relativamente bajo porque cada paquete es económico de enviar pero fuerza al servidor a reservar memoria.

¿Por qué los UDP floods a menudo apuntan a puertos aleatorios? Apuntar a puertos aleatorios maximiza la probabilidad de que ninguna aplicación esté escuchando, lo que fuerza al kernel del objetivo a generar una respuesta ICMP Destination Unreachable para casi cada paquete. Generar y transmitir esa respuesta consume CPU y ancho de banda saliente adicional más allá del costo de simplemente recibir el tráfico de inundación, aumentando el impacto del ataque por paquete enviado.

¿El rate limiting por sí solo puede detener un UDP flood? El rate limiting es efectivo cuando el tráfico de ataque se origina de un conjunto limitado o no falsificado de orígenes, pero tiene efecto limitado contra ataques que usan IP de origen ampliamente distribuidas y falsificadas, ya que cada paquete parece venir de un origen distinto, probablemente de un solo uso. El rate limiting es una capa necesaria pero debería combinarse con filtrado BCP38, validación de protocolo, y capacidad de scrubbing upstream para ataques volumétricos.

¿Deshabilitar las respuestas ICMP detiene los UDP floods? Deshabilitar las respuestas ICMP por completo detiene que el objetivo genere respuestas Port Unreachable, eliminando un costo de recursos, pero no detiene que la propia inundación entrante consuma ancho de banda y CPU. Deshabilitar ICMP por completo también rompe Path MTU Discovery para conexiones TCP en la misma red, lo que puede causar problemas de conectividad no relacionados. Limitar la tasa de generación de ICMP es preferible a deshabilitarlo por completo.

¿Cuál es la diferencia entre un flood de puerto aleatorio y un flood de puerto fijo? Un flood de puerto aleatorio rota a través de muchos puertos de destino, lo que usualmente dispara respuestas ICMP Unreachable ya que la mayoría de los puertos no se usan. Un flood de puerto fijo apunta a un solo puerto conocido como abierto, como un puerto DNS o de servidor de juego, forzando a la propia aplicación escuchando a procesar y descartar el tráfico de inundación en lugar de que el kernel genere errores ICMP.

¿Cómo se relaciona la fragmentación IP con los UDP floods? Un atacante puede enviar payloads UDP de tamaño excesivo que requieren fragmentación a nivel IP, forzando al objetivo a hacer buffer y reensamblar fragmentos antes de poder siquiera evaluar si existe una aplicación escuchando para ese paquete. Esta variante de UDP flood fragmentado aumenta el costo por paquete y puede interactuar con las técnicas de agotamiento de reensamblado descritas en los ataques de fragmentación IP.

¿Los UDP floods usualmente están falsificados? El spoofing es común pero no universal. El spoofing evita que el objetivo bloquee por IP de origen y evita que cualquier tráfico de retorno —incluyendo errores ICMP— llegue al atacante real, lo que también ayuda a ocultar el origen. Los UDP floods basados en botnet también pueden usar las IP reales de dispositivos comprometidos, en cuyo caso el rate limiting basado en origen y el filtrado de reputación se vuelven más efectivos.

¿Qué telemetría confirma mejor un UDP flood en progreso? La señal más fuerte es un aumento agudo en paquetes UDP entrantes por segundo o ancho de banda, correlacionado con un aumento en respuestas ICMP Destination Unreachable y alta diversidad de IP de origen, visto a través de NetFlow, sFlow, o contadores del kernel como nstat -az. Ninguna métrica individual es concluyente por sí sola; correlacionar volumen, proporción, y distribución de origen evita falsos positivos de picos de tráfico legítimos.

¿Una CDN o red edge puede detener un UDP flood dirigido directamente a una IP de origen? Una red edge solo puede absorber tráfico que se enruta a través de ella. Si el atacante apunta directamente a la dirección IP del origen en lugar de a un hostname que resuelve a través de la red edge, la protección depende de enrutar todo el tráfico —incluyendo UDP— a través de la infraestructura del proveedor o usar técnicas de protección del origen como enmascaramiento de IP y permitir en listas los rangos de la red edge en el firewall del origen.

Fuentes

• IETF. “User Datagram Protocol.” RFC 768. 1980.
• IETF. “Internet Control Message Protocol.” RFC 792. 1981.
• IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP 38). 2000.
• IETF. “Ingress Filtering for Multihomed Networks.” RFC 3704. 2004.
• CERT|CC. “Results of the Distributed-Systems Intruder Tools Workshop.” 1999.
• CISA. “Understanding and Responding to Distributed Denial-of-Service Attacks.”
• NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.