¿Qué es un ataque reflejado de ICMP/UDP? | Principio general de reflexión explicado

Un ataque reflejado de ICMP/UDP es una técnica de denegación de servicio en la que un atacante envía paquetes ICMP o UDP con una dirección IP de origen falsificada —la dirección de la víctima— a hosts o servicios de terceros, que entonces envían sus respuestas a la víctima en lugar de al atacante. A diferencia de los ataques de reflexión específicos de amplificación que dependen de protocolos que producen respuestas muchas veces más grandes que el request (DNS, NTP, SSDP), los ataques reflejados de ICMP/UDP pueden funcionar con tamaños de respuesta similares o solo modestamente más grandes que el request, derivando su impacto principalmente del IP spoofing y del volumen de reflectores usados en lugar de un factor de amplificación grande.

Resumen rápido — La reflexión abusa del hecho de que ICMP y UDP no requieren ningún handshake para validar la identidad de un emisor, así que un atacante puede forjar la IP de la víctima como origen de un request y dejar que la respuesta de un host de terceros aterrice en la víctima en lugar de en el atacante. La reflexión de ICMP Echo Reply (el mecanismo detrás del clásico ataque Smurf) y la reflexión UDP general contra servicios expuestos funcionan de esta forma, incluso cuando la respuesta del reflector no es dramáticamente más grande que el paquete original: el ataque igual concentra tráfico de muchos reflectores en una víctima y oculta la IP real del atacante. La mitigación se centra en el filtrado de dirección de origen BCP38 en el edge de la red, ya que eliminar el IP spoofing elimina por completo el mecanismo de reflexión, complementado con rate limiting, política de filtrado de ICMP/UDP, y capacidad de scrubbing upstream.

Última actualización: 2026-08-08

El principio general de reflexión

La reflexión y la amplificación se discuten frecuentemente juntas, pero son mecanismos distintos. La reflexión es el acto de usar una dirección IP de origen falsificada para redirigir la respuesta de un tercero hacia una víctima que nunca envió el request original. La amplificación es una propiedad separada y opcional: si la respuesta reflejada es significativamente más grande que el request que la disparó.

Protocolos como DNS, NTP y SSDP son populares para DDoS específicamente porque combinan ambas propiedades: son reflejables (sin conexión, sin validación de origen) y pueden producir respuestas muchas veces más grandes que la consulta, a veces por factores de 50x o más. Consulta ¿Qué es la amplificación DNS? para un protocolo que maximiza ambas propiedades.

La reflexión ICMP y la reflexión UDP general se ubican en el extremo de solo-reflexión de este espectro: la respuesta del reflector puede ser aproximadamente del mismo tamaño que el request, o solo modestamente más grande. Un atacante que usa estos vectores no está tratando de multiplicar el ancho de banda como lo hace un ataque de amplificación DNS o NTP; el valor está en la ocultación (la víctima ve tráfico de muchas IP de terceros inocentes, no del atacante) y en la agregación (muchos reflectores enviando cada uno una pequeña cantidad de tráfico igual pueden sumar un volumen significativo contra un objetivo).

Principio general de reflexión (agnóstico de protocolo):

Atacante → Reflector: Request packet, source IP spoofed to Victim's IP
Reflector: procesa el request normalmente, no tiene forma de detectar el spoofing
Reflector → Víctima: paquete de respuesta, dirigido a la IP de origen (falsificada)
Víctima: recibe una respuesta a un request que nunca envió

Repetido a través de muchos reflectores y muchos requests falsificados:
La víctima recibe tráfico convergente de muchas IP distintas y legítimas
La propia IP del atacante nunca aparece en ningún lugar del tráfico que llega a la víctima

Reflexión de ICMP Echo Reply

ICMP (Internet Control Message Protocol) se usa comúnmente para diagnóstico de red: el comando ping envía una solicitud de eco ICMP y espera una respuesta de eco ICMP del objetivo. Como ICMP, al igual que UDP, no tiene un handshake de establecimiento de conexión, un host que recibe una solicitud de eco no tiene forma de verificar que la IP de origen en el paquete sea genuina.

Flujo de un ataque ICMP reflejado:

Atacante → Host de terceros: solicitud de eco ICMP, IP de origen falsificada como la IP de la Víctima
Host de terceros: responde automáticamente, ya que así está diseñado el ICMP Echo Request/Reply
Host de terceros → Víctima: respuesta de eco ICMP
Víctima: recibe una respuesta de eco no solicitada que nunca pidió

El ataque Smurf es la variante históricamente significativa de la reflexión ICMP: en lugar de apuntar a un host de terceros por request, el atacante envía una sola solicitud de eco ICMP falsificada a la dirección de broadcast de una red, que muchas redes históricamente reenviaban a cada host de esa subred. Cada host que recibía el broadcast respondería a la IP falsificada de la víctima simultáneamente, convirtiendo un paquete en potencialmente cientos de respuestas reflejadas. Los routers modernos deshabilitan el reenvío de broadcast dirigido por defecto (una práctica formalizada en RFC 2644), lo que ha hecho que los ataques Smurf clásicos basados en broadcast sean raros hoy, aunque la reflexión ICMP directa uno-a-uno contra hosts individuales sigue siendo posible dondequiera que se permita ICMP Echo desde orígenes arbitrarios. Consulta ¿Qué es un ataque Smurf? para la variante de amplificación por broadcast en detalle.

Reflexión UDP sin un factor de amplificación grande

Muchos servicios basados en UDP más allá de los protocolos de amplificación conocidos responderán a un request desde cualquier IP de origen, incluyendo servicios con tamaños de consulta y respuesta aproximadamente comparables: un factor de amplificación modesto de quizás 1x a 5x, o incluso menos. El ataque igual funciona como técnica de denegación de servicio por dos razones independientes del factor de amplificación:

1. Ocultación de atribución. La víctima’s network sees inbound traffic from many distinct, often legitimate, third-party service IPs — not from the attacker. This complicates simple source-IP blocking and can implicate innocent operators.
2. Volumen agregado de muchos reflectores. Un atacante capaz de enviar requests falsificados a miles de servicios UDP expuestos puede agregar un gran volumen total de respuesta en la víctima incluso si la respuesta de cualquier reflector individual es solo ligeramente más grande que el request que la disparó.

Ejemplo de reflexión UDP (caso genérico, de baja amplificación):

Atacante → Servicio UDP expuesto A: request, origen falsificado = IP de la Víctima
Atacante → Servicio UDP expuesto B: request, origen falsificado = IP de la Víctima
Atacante → Servicio UDP expuesto C: request, origen falsificado = IP de la Víctima
...
[repetido a través de miles de servicios UDP expuestos]

Servicio A → Víctima: respuesta
Servicio B → Víctima: respuesta
Servicio C → Víctima: respuesta
...

La víctima recibe tráfico UDP convergente de miles de IP distintas,
ninguna de las cuales es el atacante

Esta es la razón por la que la reflexión sigue siendo una preocupación de defensa relevante incluso para servicios UDP que no son vectores de amplificación clásicos: cualquier servicio UDP que responda a un request no autenticado de un origen arbitrario puede, en principio, ser reclutado como reflector.

Reflexión vs. amplificación: una comparación clarificadora

La conclusión clave: eliminar los factores de amplificación (por ejemplo, deprecando el tipo de consulta DNS ANY bajo RFC 8482) reduce la severidad de la reflexión específica de amplificación, pero no hace nada contra los ataques de reflexión que nunca dependieron de una proporción grande de respuesta-a-request en primer lugar. El filtrado de origen estilo BCP38 es el control que aborda el mecanismo de reflexión en sí, sin importar el factor de amplificación.

Señales de detección y telemetría

El tráfico ICMP/UDP reflejado tiene características reconocibles distintas de una inundación directa que se origina en la propia infraestructura del atacante.

# Busca respuestas de eco ICMP no solicitadas que llegan sin una solicitud de
# eco saliente coincidente desde este host
tcpdump -i eth0 icmp and 'icmp[icmptype] == icmp-echoreply' -nn

# Verifica el volumen y la diversidad de origen del ICMP entrante
tcpdump -i eth0 icmp -nn -c 1000 | awk '{print $3}' | sort | uniq -c | sort -rn | head

# Respuestas UDP entrantes desde puertos de origen inesperados sin
# requests salientes correspondientes a esos hosts
tcpdump -i eth0 udp -nn | grep -v "<patrón de consulta saliente conocido>"

La señal individual más confiable a través de los ataques de reflexión en general es la ausencia de un request saliente coincidente para una respuesta entrante: una red con visibilidad completa de flujo bidireccional puede distinguir así las respuestas solicitadas de las reflejadas, aunque esta correlación depende de la visibilidad en ambas direcciones de tráfico, lo cual el enrutamiento asimétrico o el NAT pueden complicar.

Técnicas de mitigación

1. BCP38 / filtrado de ingreso-egreso (RFC 2827)

BCP38 es la corrección estructural: exige a las redes descartar paquetes salientes cuya IP de origen no pertenezca al bloque de direcciones asignado a esa red, y también se puede aplicar en el ingreso para descartar tráfico entrante obviamente falsificado. Como la reflexión depende por completo de la capacidad de falsificar una IP de origen, la adopción de BCP38 en la red del reflector —o en la propia red del atacante— evita que el paquete falsificado llegue a un reflector con una dirección forjada en primer lugar. La adopción sigue siendo incompleta a través de internet, que es por lo que los ataques de reflexión persisten a pesar de que BCP38 ha existido como guía desde 2000.

2. Restringir o limitar la tasa de ICMP donde no se requiera operativamente

# Ejemplo: limita la tasa de solicitud/respuesta de eco ICMP entrante en un
# dispositivo de edge de red (la sintaxis varía según la plataforma/proveedor)
policy icmp rate-limit 100pps

Muchas redes pueden limitar de forma segura la tasa de tráfico ICMP sin romper los diagnósticos normales, ya que el uso legítimo de ping típicamente es de bajo volumen y baja frecuencia comparado con la tasa sostenida de un ataque de reflexión.

3. Deshabilitar el reenvío de broadcast dirigido por IP

Siguiendo la guía de RFC 2644, los routers no deberían reenviar paquetes dirigidos a la dirección de broadcast de una subred desde fuera de esa subred. Esto cierra la ruta de amplificación que hacía efectivos a los ataques Smurf clásicos, independientemente de cualquier rate limiting de ICMP aplicado en otro lugar.

4. Auditar y cerrar servicios UDP innecesariamente expuestos

Los servicios que responden a requests UDP no autenticados desde orígenes de internet arbitrarios son reflectores potenciales sin importar el factor de amplificación. Restringir tales servicios a rangos de origen conocidos y autorizados —o deshabilitarlos por completo donde no se necesitan en interfaces orientadas a internet— los elimina del pool de reflectores usables.

5. Capacidad de scrubbing upstream y absorción distribuida

Como los ataques de reflexión pueden agregar tráfico de un número muy grande de reflectores, la capacidad on-premise frecuentemente es insuficiente sin importar el tamaño de respuesta modesto de cualquier reflector individual. La capacidad de scrubbing upstream, basada en cloud, o de edge distribuido absorbe el volumen agregado antes de que llegue al propio uplink de la red de origen.

6. Correlación con estado de respuestas a requests

Donde existe visibilidad bidireccional completa, los dispositivos de red o la infraestructura de scrubbing pueden correlacionar respuestas ICMP/UDP entrantes contra requests salientes previamente observados y descartar respuestas que no tengan ningún request correspondiente, filtrando el tráfico reflejado sin necesidad de bloquear ICMP o UDP por completo.

Errores comunes

Cómo implementarlo con Azion

La red distribuida de Azion se ubica antes del origen y puede absorber y filtrar tráfico ICMP/UDP reflejado antes de que llegue a la infraestructura de origen.

• DDoS Protection brinda detección siempre activa orientada a patrones de reflexión volumétrica, incluyendo tráfico reflejado basado en ICMP y UDP
• Network Shield puede ayudar a aplicar reglas de filtrado a nivel de red —incluyendo por ASN, rango IP/CIDR, o protocolo— dependiendo de las Network Lists y políticas configuradas
• Firewall permite reglas personalizadas para filtrar tráfico por protocolo y características de origen a nivel de red
• WAAP combina estos controles para equipos que quieren protección DDoS combinada con defensas de capa de aplicación

Como la red distribuida de Azion absorbe tráfico a través de muchas ubicaciones geográficamente dispersas, el tráfico ICMP/UDP reflejado que converge desde muchos orígenes de terceros se distribuye a través de la capacidad agregada del edge en lugar de concentrarse contra un único uplink de origen.

Recursos relacionados

• ¿Qué es la amplificación DNS?
• ¿Qué es un ataque Smurf?
• ¿Qué es un ataque DDoS?
• Blackhole Routing vs. Edge Scrubbing
• Azion DDoS Protection
• Azion Network Shield

Preguntas frecuentes

¿Qué es un ataque reflejado de ICMP/UDP? Un ataque reflejado de ICMP/UDP envía paquetes ICMP o UDP con una dirección IP de origen falsificada —la de la víctima— a hosts de terceros, que entonces envían sus respuestas a la víctima en lugar de al atacante. Depende del IP spoofing y de la naturaleza sin conexión de ICMP y UDP, no necesariamente de una proporción grande de tamaño respuesta-a-request.

¿Cómo se diferencia la reflexión de la amplificación? La reflexión es el uso de una IP de origen falsificada para redirigir una respuesta hacia una víctima que nunca envió el request. La amplificación es una propiedad separada y opcional que describe si esa respuesta es significativamente más grande que el request. Protocolos como DNS y NTP combinan ambas propiedades para máximo impacto, mientras que la reflexión general de ICMP y UDP puede ocurrir incluso cuando la respuesta es solo comparable en tamaño al request.

¿Qué es la reflexión de ICMP Echo Reply? Es una técnica de reflexión donde un atacante envía una solicitud de eco ICMP con la IP de la víctima forjada como origen hacia un host de terceros. Ese host, siguiendo el comportamiento ICMP normal, envía una respuesta de eco a la dirección falsificada —la víctima— que recibe una respuesta a un ping que nunca emitió.

¿Cómo se relaciona el ataque Smurf con la reflexión ICMP? El ataque Smurf es una variante específica y amplificada de la reflexión ICMP: en lugar de apuntar a hosts individuales, el atacante envía una solicitud de eco falsificada a la dirección de broadcast de una red, y históricamente cada host de esa subred respondía simultáneamente a la víctima, multiplicando un request en muchas respuestas. Los routers modernos deshabilitan este reenvío de broadcast por defecto bajo la guía de RFC 2644, lo que ha reducido significativamente los ataques Smurf clásicos.

¿La reflexión UDP puede funcionar sin un factor de amplificación grande? Sí. Cualquier servicio UDP que responda a un request no autenticado desde una IP de origen arbitraria puede usarse como reflector, incluso si su respuesta es solo similar en tamaño al request. El ataque igual funciona ocultando la IP real del atacante y agregando tráfico de muchos reflectores hacia una víctima.

¿Qué detiene al IP spoofing de habilitar ataques de reflexión? BCP38 (RFC 2827) es el control estructural principal: instruye a las redes a descartar paquetes salientes cuya dirección de origen no pertenezca a su rango de IP asignado. Si se adoptara universalmente, evitaría que los paquetes con origen falsificado salieran de la red del atacante en primer lugar, eliminando el mecanismo de reflexión sin importar el protocolo o factor de amplificación. La adopción sigue siendo incompleta a través de internet.

¿Por qué las organizaciones siguen viendo reflexión ICMP si los ataques Smurf están en gran medida mitigados? La amplificación basada en broadcast (Smurf clásico) está en gran medida cerrada por el comportamiento por defecto de los routers, pero la reflexión ICMP uno-a-uno —un atacante falsificando la IP de una víctima hacia hosts individuales de terceros en lugar de una dirección de broadcast— sigue siendo posible dondequiera que los hosts respondan a solicitudes de eco ICMP desde orígenes arbitrarios sin rate limiting.

¿Bloquear todo el tráfico ICMP es una buena defensa? Generalmente no se recomienda como medida general. ICMP sirve funciones legítimas de diagnóstico y salud de red (como Path MTU Discovery), y bloquearlo por completo puede causar otros problemas de red. Limitar la tasa de tráfico ICMP y deshabilitar el reenvío de broadcast dirigido son controles más específicos que abordan el riesgo de reflexión sin romper la funcionalidad ICMP normal.

¿Cómo puede una red distinguir el tráfico reflejado de respuestas legítimas? La señal más confiable es la correlación: una respuesta legítima corresponde a un request que la red local realmente envió. El tráfico reflejado llega sin ningún request saliente coincidente. Esta detección depende de visibilidad completa de flujo bidireccional, lo cual el enrutamiento asimétrico, el NAT, o la telemetría limitada pueden complicar.

¿Deshabilitar funciones específicas de amplificación (como las respuestas DNS ANY) detiene la reflexión en general? No. Medidas como las respuestas ANY mínimas de RFC 8482 reducen el factor de amplificación de un protocolo específico, disminuyendo la severidad de la reflexión específica de amplificación. No hacen nada contra técnicas de reflexión —incluyendo ICMP y reflexión UDP general— que nunca dependieron de una proporción grande de respuesta-a-request en primer lugar.

¿Qué rol juega el scrubbing upstream contra ataques ICMP/UDP reflejados? Como la reflexión puede agregar tráfico de un número muy grande de reflectores de terceros distintos, el volumen total puede exceder la capacidad de uplink propia de una red de origen incluso cuando ningún reflector individual amplifica mucho. El scrubbing upstream o de edge distribuido absorbe este volumen agregado antes de que llegue al origen, lo cual generalmente es más efectivo que depender de la capacidad propia y comparativamente limitada de la red de origen.

Fuentes

• IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP38).
• IETF. “Changing the Default for Directed Broadcasts in Routers.” RFC 2644.
• IETF. “Internet Control Message Protocol.” RFC 792.
• CISA. “Understanding Denial-of-Service Attacks.”
• CISA. “UDP-Based Amplification Attacks.”
• CAIDA. “Spoofer Project Results.”