El desarrollo de servicios en la nube y soluciones IoT sin la debida atención a la seguridad de la información lleva a infecciones por botnets como Mirai. Según datos de Cloudflare, a principios de septiembre de 2025, varios proveedores de servicios IoT y servicios en la nube, incluido Google Cloud, fueron fuentes de un ataque UDP Flood con una potencia de 11,5 Tbps y una duración de 35 segundos. Esto es comparable a transmitir en streaming 10,000 horas de video de alta calidad en apenas medio minuto. Tales ataques demuestran claramente las capacidades de los atacantes: los ataques DDoS de cientos de Gbps ahora pueden llevarse a cabo con un esfuerzo mínimo, causando tiempos de inactividad empresarial de horas o incluso días.
¿En qué radica la fortaleza de estos ataques y cómo combatirlos? Lo explicamos en este artículo y sugerimos qué medidas tomar para mitigar las consecuencias.
Cómo funciona el UDP Flood
UDP Flood es un tipo de ataque DDoS volumétrico en la capa de transporte (L4) de la red, en el que el atacante envía una gran cantidad de paquetes UDP a puertos aleatorios o predefinidos del host de destino.
Originalmente, el protocolo UDP (User Datagram Protocol) fue diseñado como un transporte minimalista sobre IP para aplicaciones que no requieren mecanismos de entrega confiable: confirmación de recepción, retransmisiones ni control del orden de los paquetes. Por eso mismo, un atacante puede «inundar» continuamente el objetivo en una sola dirección sin esperar ninguna respuesta. Estas propiedades convirtieron posteriormente a UDP en una base conveniente para VoIP, streaming de video y videojuegos en línea, donde la pérdida de paquetes individuales no es crítica.
Otra característica del protocolo UDP es que el host de destino responde con un mensaje ICMP de «servicio no disponible» si el puerto está cerrado y ICMP no está restringido por políticas de seguridad. Este proceso carga al servidor atacado con el procesamiento de la solicitud, la verificación de si existe un servicio en el puerto indicado y la formulación de una respuesta. El mensaje de respuesta también cargaría la propia fuente del ataque, pero los atacantes comenzaron a utilizar la técnica de IP Spoofing, reemplazando la dirección IP del remitente en el paquete por una aleatoria. De esta manera, usando recursos mínimos, el atacante logra la saturación tanto del canal de comunicación descendente como del ascendente.
Anteriormente examinamos en detalle el SYN Flood, un ataque TCP clásico orientado a agotar las tablas de conexiones y los recursos del stack TCP.
Comparemos UDP Flood vs TCP SYN Flood.
| Criterio | UDP Flood | TCP SYN Flood |
| Costo computacional del atacante | Bajo | Alto |
| Escalabilidad | Alta | Limitada por el mantenimiento de conexiones semi-abiertas |
| Facilidad de suplantación de IP | Alta | Media |
| Agotamiento de recursos | Ancho de banda / límites de hardware (tablas TCAM, session tables, CPU del plano de control) / CPU del host de destino | Número de usuarios del servicio / CPU del host de destino |
| Impacto en el operador | Alto | Bajo |
| Método de detección | Anomalías en el perfil de tráfico (PPS/BPS, asimetría de flujo, aumento múltiple de fuentes) | Relación de paquetes SYN respecto al total (SYN ratio) |
| Método de protección en el host atacado | Limitación de flujo UDP (Rate-limiting), mecanismos de protección de servicios (DNS RRL, SIP rate control, QUIC Retry Token) | SYN Cookies |
Tipos de UDP Flood
Saber que un ataque opera en la capa de transporte mediante UDP es solo el primer paso. Para una protección efectiva, es importante identificar su tipo específico: el mecanismo, la fuente de tráfico y los protocolos de aplicación involucrados. Sin esto, las contramedidas pueden resultar excesivas o ineficaces. Veamos las principales variedades de UDP Flood con las que los operadores de telecomunicaciones se enfrentan con más frecuencia.
UDP Flood vía Botnet (non-spoofed)
Hoy en día este es el escenario más común. El creciente número de dispositivos IoT vulnerables, servidores obsoletos y routers domésticos crea una base masiva para las botnets. El tráfico proviene de IPs reales de dispositivos infectados, por lo que los paquetes parecen legítimos y se filtran con dificultad.
Los riesgos van más allá de la parte atacada: un operador cuya red contenga suscriptores infectados puede enfrentarse al desbordamiento de las tablas CG-NAT debido al masivo tráfico saliente. Como resultado, los usuarios regulares se ven afectados y el operador se convierte de facto en un participante involuntario del ataque.
UDP Flood Clásico (spoofed)
Un método antiguo pero aún vigente: se genera un flujo de paquetes UDP con direcciones de remitente falsificadas, frecuentemente con utilerías disponibles. El bajo umbral de entrada lo hace popular entre atacantes novatos.
Su prevalencia está disminuyendo gradualmente gracias a la implementación del filtrado BCP38 y la aparición de métodos de amplificación más efectivos. Sin embargo, con un filtrado débil, este tipo de ataque todavía puede saturar los canales.
Ambos tipos pueden atacar un solo puerto o muchos puertos aleatorios. En el segundo caso, el host objetivo se carga adicionalmente con el procesamiento de respuestas ICMP.
UDP Flood Reflejado (reflection/amplification)
Un subtipo especialmente peligroso que utiliza servicios reflectores abiertos. El atacante envía una pequeña solicitud con la dirección falsificada de la víctima, y el servidor devuelve una respuesta significativamente mayor a la víctima. El factor de amplificación puede alcanzar decenas, cientos e incluso miles de veces, lo que permite generar un tráfico enorme con recursos mínimos del atacante.
Ataques de Alfombra y Multivectoriales
Cualquiera de estos tipos puede dirigirse no a un solo host sino a una subred completa, el llamado carpet bombing, donde el tráfico se distribuye entre múltiples direcciones y es más difícil de detectar. En la práctica, los atacantes suelen combinar varios métodos simultáneamente, formando ataques multivectoriales que requieren protección integral.
Cómo detectar un UDP Flood
El primer paso para construir una protección es aprender a identificar oportunamente qué tipo de ataque ha afectado a la infraestructura.
El primer y más evidente signo es un aumento repentino y anómalo del tráfico entrante. A diferencia del crecimiento orgánico de carga característico de las horas pico, un ataque aparece como un pico vertical en el gráfico: el tráfico aumenta varias veces o por órdenes de magnitud en segundos. Al mismo tiempo, la carga de CPU del router fronterizo o firewall crece rápidamente, ya que el equipo se ve obligado a procesar cada paquete entrante.
Simultáneamente se registra degradación en la calidad del servicio: aumenta la latencia, crece la tasa de pérdida de paquetes para los usuarios legítimos, los servicios comienzan a responder con lentitud o dejan de responder. En el caso de un ataque a CG-NAT, el operador recibe quejas de suscriptores sobre la imposibilidad de establecer nuevas conexiones, señal inequívoca del agotamiento de las tablas de traducción.
Al analizar el tráfico se observa una imagen característica: alta proporción de paquetes UDP con tamaño mínimo o fijo, puertos de destino pseudoaleatorios o claramente repetidos, un número anómalamente alto de direcciones IP únicas de remitentes (en ataques spoofed) o, por el contrario, tráfico desde ciertos ASNs o regiones geográficas (en ataques de botnet). En ataques de reflexión, el tráfico provendrá de direcciones de servidores DNS o NTP públicos conocidos, lo que en sí mismo es una anomalía. La lista de servidores vulnerables suele distribuirse a través de plataformas de Threat Intelligence, proporcionando una lista lista para bloqueo o limitación de flujo.
Para la detección oportuna de ataques, los operadores de telecomunicaciones generalmente utilizan varias fuentes de monitoreo.
- NetFlow/sFlow/IPFIX — la telemetría de los routers sigue siendo la principal fuente de datos para el análisis de tráfico a nivel del operador. Los colectores permiten construir perfiles de tráfico en tiempo real y detectar anomalías por protocolo, puerto, volumen y geografía. Las alertas de umbral para el crecimiento repentino de tráfico UDP se configuran en base a las métricas de carga normal.
- Monitoreo SNMP de interfaces de routers mediante Zabbix, Prometheus con exportador SNMP o Grafana permite registrar la saturación de canales y el crecimiento anómalo de contadores de errores y paquetes descartados.
- DPI (Deep Packet Inspection) permite el análisis a nivel del contenido de los paquetes, identificando firmas características de ataques conocidos, incluido el tráfico de reflexión de tipos específicos de reflectores. Las soluciones basadas en DPI, como Stingray de VAS Experts, permiten no solo detectar un ataque, sino también aplicar de inmediato políticas de filtrado granular sin bloquear el tráfico legítimo.
- Sistemas de detección de anomalías (NBAD) — soluciones AntiDDoS especializadas que analizan el comportamiento del tráfico en relación con una línea base y activan automáticamente los procedimientos de mitigación cuando se detecta un ataque. El tiempo de respuesta de estos sistemas se mide en segundos, algo crítico durante ataques de alta intensidad. Stingray AntiDDoS es un ejemplo destacado de sistema de esta clase: al analizar datos de QoE mediante redes neuronales y algoritmos de machine learning, el detector identifica desviaciones de la norma, clasifica amenazas y determina sus fuentes.
Métodos de protección
La protección contra UDP Flood no es universal: un servidor DNS, una plataforma SIP y los servicios web son atacados de manera diferente y requieren distintas contramedidas. A continuación, recomendaciones prácticas para cada tipo de infraestructura con comandos y configuraciones específicas.
Protección de servidores DNS
El DNS es un objetivo doble: el servidor es atacado directamente y también utilizado como reflector para atacar a otros. Un resolver autoritativo con resolución recursiva abierta y sin rate limiting es un amplificador ideal para el atacante.
Cerrar la recursión para clientes externos
Un servidor DNS autoritativo no debe responder consultas recursivas de IPs externas. En BIND:
options { recursion yes; allow-recursion { 192.168.0.0/16; 10.0.0.0/8; }; allow-query-cache { 192.168.0.0/16; 10.0.0.0/8; }; };
En Unbound — denegar consultas de todos excepto subredes de confianza mediante access-control.
access-control: 192.168.0.0/16 allow access-control: 10.0.0.0/8 allow access-control: 0.0.0.0/0 refuse
Response Rate Limiting (RRL)
Limita el número de respuestas a una misma dirección IP por unidad de tiempo. Reduce la efectividad del DNS Amplification y protege contra la inundación directa de consultas. Ejemplo para BIND 9.18+:
rate-limit { responses-per-second 15; window 15; slip 2; };
Minimización de respuestas ANY
Las consultas ANY producen el mayor factor de amplificación. Las versiones modernas de BIND y Unbound devuelven minimal-any por defecto, pero conviene especificarlo explícitamente.
minimal-responses yes; // BIND minimal-any yes; // BIND 9.11+
Protección de infraestructura VoIP / SIP
SIP opera sobre UDP (puerto 5060) y es particularmente vulnerable a la inundación: cada paquete entrante requiere análisis a nivel de aplicación, lo que agota rápidamente los recursos del SBC (Session Border Controller) y de Asterisk/FreeSWITCH. Además, la infraestructura SIP frecuentemente sufre ataques combinados: la inundación se combina con spam de registro y Toll Fraud.
Rate limiting orientado a SIP en el SBC
El Session Border Controller debe limitar el número de mensajes SIP (INVITE, REGISTER, OPTIONS) desde una misma IP. Ejemplo de configuración en Kamailio:
modparam("pike", "sampling_time_unit", 2)
modparam("pike", "reqs_density_per_unit", 16)
modparam("pike", "remove_latency", 4)
El módulo pike bloquea una fuente cuando supera 16 solicitudes en 2 segundos. Para tráfico empresarial, el umbral debe calibrarse según la carga real.
Restricciones a nivel del subsistema del kernel de Linux
El filtrado a nivel del sistema operativo antes de que los paquetes lleguen al stack SIP reduce significativamente la carga. Con iptables:
iptables -A INPUT -p udp --dport 5060 -m hashlimit \ --hashlimit 50/sec --hashlimit-burst 100 \ --hashlimit-mode srcip --hashlimit-name SIP \ -j ACCEPT iptables -A INPUT -p udp --dport 5060 -j DROP
Con nftables:
table inet filter {
chain input {
type filter hook input priority 0;
ip protocol udp udp dport 5060 \
limit rate over 50/second burst 100 \
per ip saddr accept
ip protocol udp udp dport 5060 drop
}
}
El valor de 50/sec o 50/second se ajusta a la carga real — el valor actual es adecuado para un SBC corporativo pequeño. El límite debe aplicarse por IP, de lo contrario se puede descartar tráfico burst legítimo o interrumpir la negociación RTP.
Ocultar la infraestructura SIP detrás del SBC
Los servidores de medios (Asterisk, FreeSWITCH) no deben tener IPs públicas. El SBC recibe todo el tráfico SIP/RTP externo, lo termina y lo reenvía a la red interna. Esto elimina los ataques directos a los servidores de aplicaciones.
Ancho de banda separado para tráfico RTP
Los flujos de medios (RTP/UDP) deben asignarse a un rango de puertos separado y limitarse en ancho de banda a nivel de QoS. Durante un ataque, la inundación al puerto 5060 no debe competir con las sesiones de voz activas.
Importante: el SIP OPTIONS flood es un ataque popular que imita solicitudes keepalive legítimas. Asegúrese de que su SBC distinga OPTIONS de pares de confianza y fuentes aleatorias, y limite estrictamente a estas últimas.
Protección de servicios web y APIs
HTTP opera sobre TCP, pero el UDP Flood afecta la infraestructura web de forma indirecta: al saturar el canal y sobrecargar el equipo fronterizo, el ataque hace inaccesibles todos los servicios, incluidos los web. Una amenaza separada es QUIC (HTTP/3), que opera sobre UDP/443: los atacantes utilizan cada vez más reflectores QUIC o atacan directamente los endpoints QUIC.
Restricción de UDP/443 (QUIC) durante un ataque
Si el servidor web no usa HTTP/3, el puerto UDP/443 debe cerrarse completamente. Si se necesita QUIC, implemente rate limiting similar al de SIP.
ip protocol udp udp dport 443 \ limit rate over 500/second burst 1000 \ per ip saddr accept ip protocol udp udp dport 443 drop
Uso de QUIC connection migration con precaución
La migración de conexión en QUIC permite cambiar de IP sin interrumpir la conexión, útil para clientes móviles, pero puede usarse para amplificación. Controle los parámetros preferred_address y migration en la configuración del servidor.
Configuración de nginx para protección contra ataques QUIC
Además de los filtros de red, los parámetros de nginx pueden optimizarse para reducir la carga durante ataques UDP indirectos.
quic_retry on; quic_max_idle_timeout 30s; quic_max_packet_size 1350;
Asegúrese de que su versión de nginx soporte QUIC y las directivas correspondientes. Estas configuraciones no reemplazan la protección a nivel de red, sino que ayudan a reducir la carga en el servidor web.
Medidas de protección universales para el operador
uRPF (BCP38)
Filtra paquetes con direcciones falsificadas directamente en el router, antes de ingresar a la red del operador. El modo strict es más efectivo pero requiere enrutamiento simétrico; el modo loose es adecuado para multihoming. Ejemplo para Cisco IOS en una interfaz fronteriza:
ip verify unicast source reachable-via rx ! strict mode ip verify unicast source reachable-via any ! loose mode
BGP Flowspec
Permite distribuir reglas de filtrado en toda la red mediante anuncios BGP, bloqueando el tráfico de ataque más cerca de la fuente sin sobrecargar los nodos centrales. Ejemplo de regla para bloquear UDP Flood en un prefijo específico:
match destination 203.0.113.0/24 protocol udp dst-port 53 then discard
Para aplicar Flowspec, el equipo de la red debe soportar esta funcionalidad a nivel del plano de datos.
RTBH (Remotely Triggered Black Hole)
Medida de emergencia durante ataques de rango terabit: anunciar el prefijo atacado a la comunidad blackhole del proveedor upstream. El tráfico se descarta en el punto de interconexión, antes de llegar a su canal. La víctima queda temporalmente inaccesible, pero la infraestructura del operador queda protegida.
ip route 203.0.113.1/32 Null0 router bgp 65000 network 203.0.113.1/32 route-map BLACKHOLE
Centro de limpieza (Scrubbing Center)
Con un centro de limpieza de tráfico propio o arrendado, el prefijo atacado se redirige a través de él mediante BGP. El scrubbing center filtra el tráfico anómalo y devuelve el flujo limpio al operador a través de un túnel GRE o MPLS.
Protección de VAS Experts
El sistema Stingray AntiDDoS brinda protección integral contra UDP Flood a nivel de operador, combinando DPI, análisis de comportamiento y mitigación automática en una sola solución.
| Capacidad | Descripción |
| DPI a velocidad de línea | Análisis de tráfico hasta 5 Tbps sin degradación del rendimiento |
| Detección de packet rate (nivel Mpps) | Detección instantánea del crecimiento anómalo de PPS y protección contra ataques de packet rate que cargan la CPU y el plano de control del equipo |
| Filtrado granular | Por protocolo, puerto, tamaño de paquete, geografía — sin bloquear el tráfico legítimo |
| Protección CG-NAT | Control del flooding saliente, prevención del agotamiento de las tablas de traducción |
| Integración BGP | Inicio automático de RTBH y Flowspec al detectar un ataque |
| Detección de carpet bombing | Análisis agregado a nivel de AS — detecta ataques distribuidos en subredes |
| Filtrado inline en el plano de datos | Mitigación directamente en el nodo del operador sin redirigir el tráfico a un scrubbing center externo — ciclo completo de protección dentro de una sola plataforma |
Casos de estudio
El análisis de incidentes públicos permite no solo evaluar la escala de las amenazas modernas, sino también extraer lecciones prácticas para la propia infraestructura.
Caso 1 — GitHub, febrero de 2018
| Potencia del ataque | 1,35 Tbps (récord en ese momento) / 126,9 Mpps |
| Duración | ~10 minutos |
| Vector | Memcached UDP Amplification (puerto 11211), ~50,000 reflectores |
| Factor de amplificación | Hasta 51,000x (1 byte de solicitud → 51 KB de respuesta) |
| Consecuencias | GitHub estuvo inaccesible durante varios minutos antes de la conmutación a Akamai Prolexic |
| Lección clave | Memcached no debe ser accesible desde internet. UDP/11211 debe cerrarse globalmente |
| Cómo se mitigó | La redirección del tráfico a través del scrubbing center de Akamai absorbió el ataque en ~8 minutos |
Caso 2 — Cliente NDA de Microsoft Azure, noviembre de 2021
| Potencia del ataque | 3,47 Tbps / 340 millones de paquetes por segundo |
| Duración | ~15 minutos |
| Vector | UDP Reflection en el puerto 80 con uso simultáneo de cuatro protocolos amplificadores: SSDP, CLDAP, DNS y NTP. |
| Distribución | El ataque se originó desde aproximadamente 10,000 fuentes en 10 países: EE. UU., China, Corea del Sur, Rusia, Tailandia, India, Vietnam, Irán, Indonesia y Taiwán |
| Objetivo | Cliente corporativo de Microsoft Azure en Asia (no revelado públicamente) |
| Consecuencias | Ninguna; la mitigación automática se realizó sin intervención del operador |
| Lección clave | La amplificación multivectorial es la nueva norma; la protección debe ser automatizada |
| Cómo se mitigó | Azure DDoS Protection; luego protección inline mediante NVA con Gateway Load Balancer |
Caso 3 — Cliente NDA de Cloudflare, septiembre de 2024
| Potencia del ataque | 3,8 Tbps / 2,14 mil millones de paquetes por segundo |
| Duración | ~65 segundos |
| Vector | UDP Flood mediante botnet (routers ASUS, DVRs, servidores VPN) |
| Objetivo | Cliente de Cloudflare del sector financiero |
| Consecuencias | Ninguna; la mitigación automática se realizó sin intervención del operador |
| Lección clave | Los ataques de rango terabit se han vuelto cotidianos; la respuesta manual es imposible |
| Cómo se mitigó | Sistemas automáticos: Anycast + análisis de comportamiento + Flowspec instantáneo |
Caso 4 — DDoS Scrubbing en Europa Occidental, septiembre de 2025
| Potencia del ataque | 1,500 millones de paquetes/s — uno de los mayores por packet rate en la historia pública |
| Duración | ~65 segundos |
| Vector | UDP Flood mediante botnet de dispositivos CPE/IoT; más de 11,000 redes únicas en todo el mundo |
| Objetivo | Sitio web del proveedor europeo de DDoS scrubbing FastNetMon — intento de neutralizar el propio sistema de protección |
| Problema | El tráfico hacia una IP individual estaba por debajo de los umbrales de alerta, pero el backbone estaba saturado |
| Consecuencias | Nulas para los usuarios; el incidente fue revelado públicamente por FastNetMon |
| Lección clave | La alta frecuencia de paquetes UDP pequeños carga la CPU de los dispositivos de red más que los ataques volumétricos |
| Cómo se mitigó | FastNetMon Advanced detectó el pico en segundos y automáticamente redirigió y descartó el tráfico malicioso antes de la saturación del canal |
Conclusión
El UDP Flood no es el único, pero sí uno de los tipos más destructivos de ataques DDoS. La naturaleza sin conexión del protocolo UDP lo convierte en un vector de ataque ideal: no es necesario establecer una conexión, no hay protección integrada contra el spoofing y los mecanismos de amplificación pueden convertir los modestos recursos del atacante en terabits de tráfico basura.
Los ataques modernos se han vuelto automatizados, multivectoriales y de corta duración, lo que excluye la respuesta manual y requiere sistemas automáticos de detección y mitigación. Los ataques de carpet bombing, además, eluden el monitoreo clásico por umbrales. En estas condiciones, gana quien ha construido una defensa en profundidad, no un conjunto de herramientas aisladas.
Lista de verificación rápida: qué hay que hacer
- Implementar uRPF (BCP38) en todas las interfaces fronterizas — esta es la base;
- Configurar telemetría NetFlow/sFlow con análisis a nivel de AS, no solo de hosts individuales;
- Cerrar los resolvers DNS recursivos abiertos y aplicar RRL en los servidores autoritativos;
- Colocar la infraestructura SIP detrás de un SBC con rate limiting a nivel de aplicación;
- Restringir o cerrar UDP/443 (QUIC) donde no se use HTTP/3;
- Tener procedimientos listos para RTBH y BGP Flowspec — no configurarlos bajo la presión de un ataque;
- Considerar la implementación de una plataforma DPI para visibilidad del tráfico a nivel de paquete.
