¿Qué es un ataque ICMP Flood? | Ping flood y DDoS estilo Smurf explicados

Un ICMP Flood (comúnmente llamado ping flood) es un ataque volumétrico de Denegación de Servicio Distribuida (DDoS) que envía una alta tasa de paquetes Internet Control Message Protocol —típicamente mensajes Echo Request (“ping”)— a un objetivo, consumiendo ancho de banda entrante, ancho de banda saliente para las respuestas, y ciclos de CPU necesarios para procesar cada paquete, sin requerir ningún estado de conexión.

Resumen rápido — ICMP es un protocolo de control a nivel de red usado para diagnóstico y reporte de errores, no un servicio con autenticación o handshakes. Un ping flood explota esto enviando paquetes Echo Request más rápido de lo que el objetivo (o su enlace) puede absorber, forzándolo a gastar ancho de banda y CPU generando Echo Replies o simplemente descartando el excedente. Una variante histórica relacionada, el ataque Smurf, amplifica esto falsificando la IP de la víctima y transmitiendo Echo Requests a toda una subred, causando que cada host de esa subred responda a la víctima a la vez. La mitigación se apoya en limitar la tasa de ICMP en el host y el edge, deshabilitar el reenvío de broadcast dirigido en los routers, y scrubbing upstream; nunca deshabilitar ICMP por completo, ya que eso rompe los diagnósticos legítimos y Path MTU Discovery.

Última actualización: 2026-08-08

ICMP Flood es una de las técnicas de denegación de servicio más antiguas documentadas, anterior a la mayoría de las herramientas DDoS modernas. El “ping of death” y el ping flood básico ya eran molestias bien conocidas a mediados de los años noventa, y el ataque Smurf —nombrado por la herramienta de exploit “smurf.c” de 1997— se hizo notorio más tarde esa década por su alto factor de amplificación contra redes mal configuradas. Aunque los floods ICMP puros son menos devastadores hoy contra infraestructura reforzada, la técnica sigue siendo un componente común de los kits de herramientas de DDoS-por-encargo y un caso de estudio de diagnóstico útil sobre por qué los protocolos a nivel de red necesitan posturas de default-deny y rate limiting.

Cómo funciona un ICMP Flood

ICMP opera directamente sobre IP (número de protocolo 1) sin puertos, sin handshake, y sin concepto de sesión. El par Echo Request/Echo Reply definido para la utilidad ping existe puramente para pruebas de alcanzabilidad; se espera que cualquier host que reciba un Echo Request responda de inmediato con un Echo Reply que porte el mismo payload.

Ping normal:
Cliente ──ICMP Echo Request (Tipo 8)──▶ Servidor
Cliente ◀──ICMP Echo Reply (Tipo 0)──── Servidor

ICMP Flood directo:
Bot 1 ──ICMP Echo Request──▶ Objetivo
Bot 2 ──ICMP Echo Request──▶ Objetivo
Bot 3 ──ICMP Echo Request──▶ Objetivo
... [millones de requests por segundo, a menudo con IP de origen falsificadas]

Objetivo: intenta generar un Echo Reply para cada request
Resultado: ancho de banda entrante saturado por requests
        ancho de banda saliente saturado por respuestas
        CPU consumida clasificando y respondiendo a cada paquete

Mecanismo paso a paso:

1. El atacante (directamente o vía botnet) genera paquetes ICMP Echo Request a alto volumen, dirigidos a la dirección IP de la víctima.
2. Las IP de origen pueden falsificarse para evitar que las respuestas lleguen al atacante real y para dificultar el filtrado basado en origen.
3. El stack de red del objetivo procesa cada Echo Request y, a menos que se limite la tasa o se filtre, genera un Echo Reply correspondiente, duplicando el tráfico en el enlace del objetivo (requests entrantes más respuestas salientes).
4. A suficiente volumen, el uplink del objetivo se satura, su CPU gasta ciclos desproporcionados en el stack de red, y el tráfico legítimo —incluyendo mensajes ICMP necesarios para funciones como Path MTU Discovery— se retrasa o descarta junto con la inundación.
5. Si la inundación es suficientemente grande en relación con la capacidad upstream, los routers y enlaces intermedios también pueden congestionarse, extendiendo el impacto más allá del objetivo inmediato.

El ataque Smurf: amplificación por broadcast

El ataque Smurf clásico convierte una cantidad modesta de ancho de banda del atacante en una inundación mucho más grande abusando del direccionamiento de broadcast dirigido IP.

Paso 1: El atacante falsifica la IP de origen = IP de la víctima
Paso 2: El atacante envía una solicitud de eco ICMP a la dirección de broadcast de una subred
Atacante (origen falsificado: víctima) ──Echo Request──▶ 203.0.113.255 (broadcast)

Paso 3: Cada host activo de esa subred recibe la solicitud transmitida
Host 1, Host 2, ... Host 250 procesan cada uno la Echo Request

Paso 4: Cada host responde — a la víctima, no al atacante
Host 1 ──Echo Reply──▶ Víctima
Host 2 ──Echo Reply──▶ Víctima
...
Host 250 ──Echo Reply──▶ Víctima

Factor de amplificación ≈ número de hosts activos en la subred de broadcast

Los ataques Smurf dependen de que los routers estén configurados para reenviar tráfico de “broadcast dirigido” (un paquete dirigido a la dirección de broadcast de una subred que llega desde fuera de esa subred), una práctica que RFC 2644 recomendó deshabilitar por defecto ya desde 1999. La mayoría de los routers y stacks IP modernos deshabilitan el reenvío de broadcast dirigido de fábrica, lo que ha hecho raros a los ataques Smurf clásicos en la práctica, aunque el equipo legado mal configurado todavía puede ser abusado de esta forma.

ICMP Flood vs. UDP Flood vs. SYN Flood

Variaciones del ataque

ICMP Flood directo. El atacante envía Echo Requests directamente a la víctima desde un solo origen o una botnet de muchos orígenes, con o sin spoofing. Esta es la forma más simple y todavía más común.

Flood de broadcast estilo Smurf. Como se describió arriba, el atacante falsifica la dirección de la víctima y envía Echo Requests a una dirección de broadcast de subred, causando que muchos hosts respondan simultáneamente a la víctima. La efectividad hoy depende de encontrar redes que todavía reenvíen broadcasts dirigidos, lo cual es poco común en routers modernos.

Flood ICMP fragmentado/de tamaño excesivo. El atacante envía paquetes ICMP que están fragmentados o exceden el tamaño máximo legal de datagrama IP, forzando al objetivo a gastar CPU y memoria adicionales en reensamblado antes de poder siquiera procesar el payload ICMP. Históricamente, el Ping of Death explotó bugs de manejo de buffer disparados al reensamblar Echo Requests ICMP de tamaño excesivo, un vector relacionado pero distinto de paquete malformado en lugar de una inundación puramente volumétrica.

ICMP reflejado vía otros tipos de error. En lugar de Echo Request/Reply, algunas variantes abusan de mensajes de error ICMP (como Time Exceeded o Destination Unreachable) generados por routers intermedios en respuesta a paquetes malformados o que expiran, redirigiendo ese tráfico de error hacia una víctima mediante spoofing. Esto es menos común que el flooding directo de Echo pero sigue el mismo principio subyacente: ICMP no tiene costo para el emisor y ninguna validación de origen integrada.

Señales de detección y telemetría

# Contadores ICMP por protocolo
netstat -s -p icmp
# Busca un aumento agudo en "ICMP messages received" y "Echo Requests received"

# Contadores ICMP a nivel de kernel
nstat -az | grep -i icmp

# Captura en vivo de tráfico ICMP (usa muestreo en producción para evitar overhead de captura)
tcpdump -i eth0 icmp -c 200

# Configuración actual de rate-limit de ICMP en Linux
sysctl net.ipv4.icmp_ratelimit
sysctl net.ipv4.icmp_ratemask

# Contador de nftables para monitorear volumen ICMP sin bloquear
nft add rule inet filter input icmp counter

# Equivalente de iptables con logging
iptables -I INPUT -p icmp --icmp-type echo-request -m limit --limit 10/s -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

NetFlow, IPFIX, o sFlow escalan mejor que la captura completa de paquetes durante inundaciones de PPS alto, ya que el volumen ICMP por sí solo rara vez requiere inspección de payload para confirmar el patrón.

Técnicas de mitigación

Por qué no deberías simplemente deshabilitar ICMP. ICMP no es un protocolo de conveniencia opcional. Path MTU Discovery depende de mensajes ICMP “Fragmentation Needed” (Tipo 3, Código 4) para que los emisores TCP conozcan el tamaño de segmento correcto para una ruta; bloquear todo el ICMP causa que esos mensajes se descarten silenciosamente, lo que se manifiesta como conexiones TCP que se cuelgan misteriosamente para ciertos tamaños de payload (PMTUD “agujereado negro”). La postura correcta es ICMP selectivo y con rate limiting, no un bloqueo general.

Errores comunes

Cómo implementarlo con Azion

La red distribuida de Azion puede ayudar a absorber y filtrar el tráfico de ICMP 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 de capa de red, incluyendo ICMP floods, en el edge en lugar de en tu origen.
• Network Shield puede aplicar reglas de rate limiting y filtrado basado en protocolo para reducir el impacto de tráfico ICMP anómalo antes de que llegue a la infraestructura de aplicación.
• Firewall permite reglas personalizadas para permitir, descartar, o limitar la tasa de tráfico ICMP por tipo, patrón de origen, o umbral de volumen específico de tu entorno.
• WAAP combina controles de red y de capa de aplicación cuando la presión volumétrica basada en ICMP acompaña 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 ICMP 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, 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 UDP Flood?
• ¿Qué es un ataque de fragmentación IP?
• Azion DDoS Protection
• Azion Network Shield

Preguntas frecuentes

¿Qué es un ataque ICMP flood? Un ICMP flood, o ping flood, envía un alto volumen de paquetes ICMP Echo Request a un objetivo, consumiendo su ancho de banda entrante y saliente y CPU mientras intenta procesar requests y generar respuestas. No requiere ningún estado de conexión ni complejidad a nivel de aplicación, lo que lo hace simple de lanzar y un componente común de los kits de herramientas de DDoS-por-encargo.

¿Qué es un ataque Smurf y cómo se relaciona con el flooding ICMP? Un ataque Smurf es una técnica de amplificación de Capa 3 que falsifica la dirección IP de una víctima y envía Echo Requests ICMP a la dirección de broadcast de una red, causando que cada host activo de esa subred envíe un Echo Reply a la víctima simultáneamente. Es una forma específica y amplificada de ICMP flood que depende de que los routers reenvíen tráfico de broadcast dirigido, una práctica que la mayoría de las redes modernas deshabilitan por defecto.

¿Por qué deshabilitar ICMP por completo no soluciona el riesgo de ICMP flood? ICMP porta mensajes de control esenciales más allá de Echo Request/Reply, incluyendo los mensajes “Fragmentation Needed” de los que depende Path MTU Discovery para determinar los tamaños de segmento TCP correctos. Bloquear todo el ICMP rompe PMTUD y herramientas de diagnóstico legítimas como traceroute, causando problemas de conectividad no relacionados que pueden ser más difíciles de diagnosticar que el riesgo de inundación original.

¿En qué se diferencia un ICMP flood de un UDP flood? Un ICMP flood opera a nivel de red sin concepto de puerto y típicamente involucra pares Echo Request/Reply, mientras que un UDP flood opera a nivel de transporte y apunta a puertos específicos, a menudo disparando respuestas ICMP Port Unreachable como efecto secundario cuando ningún servicio está escuchando. Ambos son volumétricos y sin estado, pero usan protocolos distintos y generan patrones de respuesta distintos para la detección.

¿Los ataques Smurf siguen siendo una amenaza real hoy? Los ataques Smurf clásicos son mucho menos efectivos hoy porque RFC 2644 ha llevado a la mayoría de los proveedores de routers a deshabilitar el reenvío de broadcast dirigido por defecto desde principios de los años 2000. La técnica sigue siendo relevante de entender porque el equipo legado mal configurado, ciertas redes privadas, y dispositivos IoT con stacks de red no estándar todavía pueden ser vulnerables a la amplificación basada en broadcast.

¿El rate limiting puede detener por completo un ICMP flood? El rate limiting es efectivo para contener el costo de recursos de procesar y responder al tráfico ICMP, y es la defensa estándar de primera línea, pero no detiene a una inundación volumétrica suficientemente grande de saturar el propio enlace entrante. El rate limiting debería combinarse con filtrado BCP38 y capacidad de scrubbing upstream para ataques que excedan el ancho de banda local.

¿Cuál es la diferencia entre un ICMP flood y el Ping of Death? Un ICMP flood es un ataque volumétrico que depende de la pura tasa de paquetes para agotar el ancho de banda y la CPU. El Ping of Death es un ataque de paquete malformado que envía paquetes ICMP Echo Request de tamaño excesivo o inválido diseñados para disparar bugs de manejo de buffer durante el reensamblado, históricamente causando colapsos en lugar de un simple agotamiento de recursos. Los sistemas operativos modernos han en gran medida parchado las vulnerabilidades específicas que explotaba el Ping of Death.

¿Cómo puedo distinguir un pico legítimo de ICMP de un ataque? Los picos legítimos de ICMP usualmente vienen de un conjunto pequeño e identificable de orígenes —sistemas de monitoreo, escaneos de red, o actividad de resolución de problemas— y muestran una proporción normal de 1:1 de Echo Requests a Echo Replies. El tráfico de ataque típicamente muestra alta diversidad de IP de origen, una proporción ICMP-a-tráfico-total desproporcionada, y, en ataques estilo Smurf, Echo Replies no solicitados que llegan sin requests salientes correspondientes.

¿El IP spoofing importa para los ICMP floods de la misma forma que para los UDP o SYN floods? El spoofing sirve los mismos propósitos en los tres: oculta la identidad real del atacante y evita que el tráfico de retorno consuma los propios recursos del atacante. Para ICMP específicamente, el spoofing también es el mecanismo que hace posible la amplificación estilo Smurf, ya que la dirección falsificada de la víctima es lo que causa que las respuestas de broadcast converjan en ella en lugar de en el emisor real.

¿Qué telemetría confirma mejor un ICMP flood en progreso? La señal más clara es un aumento agudo y sostenido en paquetes ICMP por segundo relativo a la línea base, combinado con una proporción ICMP-a-tráfico-total desproporcionada y alta diversidad de IP de origen, visible a través de NetFlow, sFlow, o contadores del kernel como nstat -az. Para actividad Smurf sospechada, vigila específicamente los Echo Replies no solicitados que llegan de muchos hosts de origen distintos sin ningún Echo Request saliente coincidente.

Fuentes

• IETF. “Internet Control Message Protocol.” RFC 792. 1981.
• IETF. “Changing the Default for Directed Broadcasts in Routers.” RFC 2644 (BCP 34). 1999.
• IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP 38). 2000.
• IETF. “Path MTU Discovery.” RFC 1191. 1990.
• CERT|CC. “CERT Advisory CA-1998-01: Smurf IP Denial-of-Service Attacks.” 1998.
• CISA. “Understanding and Responding to Distributed Denial-of-Service Attacks.”
• NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.