Un ataque Smurf es una técnica DDoS a nivel de red que combina el IP spoofing con solicitudes de eco ICMP enviadas a la dirección de broadcast IP de una red, causando que cada host de esa red envíe una respuesta de eco simultáneamente a la dirección falsificada de la víctima, multiplicando un solo paquete del atacante en potencialmente cientos de paquetes de respuesta que inundan al objetivo.
Resumen rápido — Un ataque Smurf falsifica la dirección IP de una víctima como origen de una solicitud de eco ICMP (ping) enviada a la dirección de broadcast de una red. Cada host activo de esa red responde al ping, y como el origen fue forjado, todas las respuestas convergen en la víctima en lugar de en el atacante, convirtiendo un paquete en una inundación proporcional al número de hosts en la red de broadcast. Fue muy efectivo en los años noventa porque los routers reenviaban los broadcasts dirigidos por defecto. Los routers modernos deshabilitan el reenvío de broadcast dirigido por defecto, lo que ha neutralizado en gran medida el ataque clásico, aunque las variantes y las redes legadas mal configuradas todavía pueden ser abusadas.
Última actualización: 2026-08-08
Los ataques Smurf se nombraron por el archivo de código fuente smurf.c, que circuló ampliamente en comunidades hacker a partir de 1997. En su apogeo, Smurf fue una de las técnicas DDoS más disruptivas disponibles, capaz de generar tráfico de ataque muy por encima de lo que el propio ancho de banda del atacante podría producir, porque la amplificación venía de cada host que respondía en la red de otra persona en lugar de en la propia infraestructura del atacante. La técnica contribuyó a interrupciones importantes a lo largo de finales de los años noventa e impulsó uno de los primeros valores por defecto de refuerzo de red ampliamente adoptados: deshabilitar el reenvío de broadcast dirigido por IP en los routers, un cambio formalizado como valor por defecto recomendado en Cisco IOS a partir de la versión 12.0 en 1999 y reflejado posteriormente en la mayoría de los proveedores de routers.
Cómo funciona un ataque Smurf
El ataque encadena tres mecanismos: solicitudes de eco ICMP, direccionamiento de broadcast dirigido IP, e IP spoofing.
La solicitud/respuesta de eco ICMP es el mecanismo detrás del comando ping: un host envía una solicitud de eco ICMP (Tipo 8) y espera una respuesta de eco ICMP (Tipo 0) del destino.
El broadcast dirigido IP es una dirección de destino especial (la dirección más alta en una subred, ej. 203.0.113.255 para la red 203.0.113.0/24) que, cuando se enruta hacia esa subred, se entrega como un broadcast de capa de enlace a cada host en ella, no solo a uno.
El IP spoofing le permite al atacante fijar la dirección de origen de la solicitud de eco ICMP como la dirección de la víctima en lugar de la propia, de modo que cada respuesta generada por el broadcast se envíe a la víctima.
Paso 1: El atacante envía una sola solicitud de eco ICMP a la dirección de broadcast de una red, con la IP de origen falsificada como la dirección de la víctima
Atacante (198.51.100.50) ──Solicitud de eco ICMP──▶ 203.0.113.255 (broadcast) [origen=192.0.2.10 (víctima), destino=203.0.113.255]
Paso 2: El router reenvía el broadcast dirigido hacia la LAN destino como un broadcast de capa de enlace; cada host activo de esa subred lo recibe
Router ──broadcast──▶ Host A, Host B, Host C, ... Host N (todos en 203.0.113.0/24)
Paso 3: Cada host responde con una respuesta de eco ICMP dirigida a la dirección de origen falsificada — la víctima, no el atacante
Host A ──Respuesta de eco ICMP──▶ 192.0.2.10 (víctima)Host B ──Respuesta de eco ICMP──▶ 192.0.2.10 (víctima)Host C ──Respuesta de eco ICMP──▶ 192.0.2.10 (víctima)... [N respuestas por 1 paquete enviado por el atacante]
Resultado: la víctima recibe N respuestas ICMP por cada paquete falsificado que envía el atacante, donde N = número de hosts en la red que amplificaEl factor de amplificación es directamente proporcional al número de hosts activos que responden a ping en la red intermediaria (de “rebote”). Una red /24 con 250 hosts que responden podría convertir un solo paquete del atacante en 250 paquetes convergiendo en la víctima; un atacante que repite esto a través de múltiples redes de broadcast en paralelo, o a una tasa sostenida, podría generar volúmenes de tráfico muy superiores a su propia capacidad de uplink, la misma asimetría de principio que reutilizaron después DNS, NTP, y otros ataques de reflexión.
Smurf vs. Fraggle: amplificación por broadcast ICMP vs. UDP
El ataque Fraggle, que apareció poco después de Smurf, es funcionalmente idéntico pero sustituye paquetes de eco UDP (históricamente dirigidos al puerto UDP 7, “echo”, o puerto 19, “chargen”) por solicitudes de eco ICMP.
| Característica | Ataque Smurf | Ataque Fraggle |
|---|---|---|
| Protocolo abusado | ICMP (solicitud/respuesta de eco) | UDP (servicios echo/chargen) |
| Mecanismo de broadcast | Broadcast dirigido IP | Broadcast dirigido IP |
| IP spoofing requerido | Sí | Sí |
| Factor de amplificación típico | Proporcional a los hosts que responden en la subred | Proporcional a los hosts que responden en la subred |
| Prevalencia hoy | Rara — mitigado por la configuración de routers por defecto | Rara — los servicios echo/chargen están deshabilitados por defecto en sistemas modernos |
| Causa raíz | Reenvío de broadcast dirigido + respuestas ICMP | Reenvío de broadcast dirigido + respuestas UDP echo/chargen |
Ambos ataques comparten la misma debilidad subyacente: el reenvío de broadcast dirigido IP combinado con un servicio que responde de forma confiable a requests no solicitados, y ambos fueron neutralizados por el mismo tipo de corrección.
Por qué Smurf era efectivo en los años noventa
Dos condiciones, ambas comunes en las redes de finales de los años noventa, hicieron a Smurf viable a escala:
- Los routers reenviaban broadcasts dirigidos por defecto. Un paquete dirigido a la dirección de broadcast de una subred, llegando desde fuera de esa subred, se enrutaba hacia la LAN y se entregaba a cada host; un diseño deliberado pensado para usos legítimos como anuncios a nivel de red, pero sin restricción integrada sobre quién podía dispararlo desde el exterior.
- La mayoría de los hosts respondían a solicitudes de eco ICMP no solicitadas por defecto. Los firewalls y el filtrado ICMP a nivel de host eran mucho menos comunes que hoy, así que casi cada host alcanzable en una red de broadcast respondía.
Los atacantes buscaban y catalogaban específicamente redes “amplificadoras” —aquellas con broadcast dirigido habilitado y grandes cantidades de hosts que respondían a ping— y compartían listas de estas redes para maximizar el impacto del ataque.
Por qué Smurf es raro hoy
La corrección definitoria contra Smurf no requería ninguna acción por parte de la víctima; requería que las redes intermediarias (de rebote) dejaran de reenviar broadcasts dirigidos, y esto se convirtió en un valor por defecto, no en una configuración opcional, a través de prácticamente todas las plataformas de router:
Configuración de Cisco IOS para deshabilitar el reenvío de broadcast dirigido (por defecto desde IOS 12.0):interface GigabitEthernet0/0 no ip directed-broadcastComo no ip directed-broadcast se convirtió en el valor de fábrica por defecto en lugar de una configuración que los administradores tenían que recordar aplicar, la población de redes amplificadoras usables colapsó con el tiempo a medida que se reemplazaba el equipo legado. Combinado con el rate limiting de ICMP a nivel de host y el firewall generalizados, los ataques Smurf clásicos ahora son en gran medida una nota histórica al pie, aunque el principio subyacente (amplificación basada en broadcast vía spoofing) sigue siendo conceptualmente importante porque es el ancestro directo de las técnicas modernas de reflexión y amplificación.
Señales de detección
Para organizaciones que todavía corren segmentos de red legados, o que investigan tráfico ICMP sospechoso, las siguientes señales son relevantes:
| Señal | Qué observar | Herramienta |
|---|---|---|
| Inundación repentina de respuestas de eco ICMP entrantes sin solicitudes de eco salientes coincidentes | Gran volumen de paquetes ICMP Tipo 0 llegando sin un historial correspondiente de pings enviados por la víctima | NetFlow/IPFIX, tcpdump -n icmp |
| Diversidad de IP de origen consistente con una sola subred | Respuestas llegando desde muchos hosts dentro de un bloque CIDR simultáneamente | Análisis de flujo, agregación de IP de origen |
| Tráfico de broadcast dirigido observado en el egress de una red intermediaria | Patrón de tráfico ICMP saliente consistente con actuar como un amplificador involuntario | Registro de ACL de router, NetFlow |
| Anomalías de tasa ICMP en relación con la línea base | Volumen ICMP muy por encima de las normas históricas para el segmento de red | nstat, contadores de interfaz SNMP |
# Inspecciona el tráfico ICMP en busca de un pico de respuestas de eco sin solicitudes de eco localestcpdump -n icmp and 'icmp[icmptype] == icmp-echoreply'
# Verifica los contadores de interfaz por volumen ICMP anómalonstat -az | grep -i icmp
# Verifica que la configuración de broadcast dirigido del router esté deshabilitadashow running-config interface <interfaz> | include directed-broadcastTécnicas de mitigación
Deshabilitar el broadcast dirigido IP en todos los routers
La corrección más efectiva y completa: configura cada interfaz de router que enfrenta una subred para que rechace reenviar broadcasts dirigidos (no ip directed-broadcast en Cisco, o el equivalente en otras plataformas). Este es un valor por defecto en prácticamente todo el software de router moderno, pero el equipo legado o mal configurado debería auditarse explícitamente.
BCP38 / Filtrado de ingreso (RFC 2827)
Como Smurf depende por completo del IP spoofing para redirigir las respuestas a la víctima en lugar de al atacante, el filtrado de ingreso BCP38 (RFC 2827) en la red del atacante evitaría que el paquete falsificado llegara siquiera a la red amplificadora en primer lugar. Como con todos los ataques que dependen de spoofing, esta defensa tiene que aplicarse upstream, no por la víctima.
Limitar la tasa y filtrar ICMP no solicitado en el edge de red
Los firewalls y dispositivos de edge pueden limitar la tasa o filtrar respuestas de eco ICMP no solicitadas que llegan sin una solicitud de eco iniciada localmente, reduciendo el impacto de cualquier tráfico residual de amplificación por broadcast que llegue a una red.
Refuerzo de ICMP a nivel de host
Configurar los hosts para que no respondan a solicitudes de eco ICMP dirigidas a broadcast (una configuración común de sysctl en sistemas tipo Unix, net.ipv4.icmp_echo_ignore_broadcasts = 1) elimina hosts individuales del pool de amplificadores usables, incluso si el reenvío de broadcast dirigido de alguna forma siguiera habilitado upstream.
Scrubbing upstream y absorción distribuida
Para cualquier tráfico residual de flood ICMP —ya sea de una variante genuina de Smurf o de un flood ICMP de alto volumen no relacionado— una red distribuida con suficiente capacidad de absorción evita que la inundación llegue al origen. Consulta Blackhole Routing vs. Scrubbing para enfoques arquitectónicos.
Errores comunes
| Error | Impacto | Solución correcta |
|---|---|---|
| Asumir que Smurf es completamente obsoleto y no requiere verificación de configuración | Los routers legados o mal configurados todavía pueden tener el reenvío de broadcast dirigido habilitado, especialmente en equipo de red industrial y embebido más antiguo | Audita explícitamente las configuraciones de router por no ip directed-broadcast en lugar de asumir que los valores de fábrica ya están en su lugar |
| Bloquear todo el ICMP entrante como respuesta general | Rompe herramientas de diagnóstico legítimas (ping, traceroute, Path MTU Discovery vía ICMP) en las que confían los operadores y algunos protocolos | Limita la tasa y filtra el ICMP no solicitado selectivamente en lugar de bloquear el protocolo por completo |
| Tratar a Smurf y a los floods ICMP genéricos como idénticos | Un flood ICMP moderno de alto volumen desde una botnet con IP de origen reales es un problema distinto de la amplificación por broadcast y requiere contramedidas diferentes | Distingue los patrones de amplificación por broadcast (muchas respuestas de una subred, sin request saliente coincidente) de los floods con origen en botnet (muchas IP de origen distintas, requests directos) |
| Creer que el refuerzo ICMP a nivel de host por sí solo previene Smurf | Si el reenvío de broadcast dirigido todavía está habilitado upstream, el tráfico de ataque igual llega a la LAN aunque no todos los hosts respondan | Corrige la causa raíz a nivel de router (no ip directed-broadcast), y trata el refuerzo de host como una capa secundaria |
| Ignorar la relevancia conceptual de Smurf porque es históricamente raro | El principio de reflexión más spoofing detrás de Smurf subyace a todo ataque de amplificación moderno (DNS, NTP, SSDP, CLDAP) | Entiende a Smurf como el ancestro conceptual de los vectores de amplificación actuales al diseñar una política más amplia anti-spoofing y anti-reflexión |
Cómo implementarlo con Azion
Aunque los ataques Smurf clásicos son raros contra orígenes modernos debido al filtrado de broadcast dirigido generalizado, la plataforma de Azion brinda protección en capas contra el tráfico residual de flood ICMP y cualquier variante relacionada de amplificación por broadcast que sí llegue a la red:
- DDoS Protection brinda detección y mitigación siempre activa para tráfico volumétrico de flood ICMP y UDP, absorbiéndolo a través de la infraestructura distribuida de Azion antes de que llegue a tu origen.
- Network Shield puede aplicar reglas a nivel de red para identificar y filtrar patrones de tráfico ICMP anómalos, dependiendo de la configuración.
- Firewall permite reglas personalizadas para limitar la tasa de ICMP y otros protocolos a nivel de red.
Como la red distribuida de Azion se ubica entre el internet público y tu origen, el tráfico de flood ICMP —ya sea de una red de amplificación estilo Smurf legada o de una botnet moderna— se filtra en el edge en lugar de consumir el ancho de banda y la capacidad de procesamiento de tu origen.
Recursos relacionados
- ¿Qué es un ataque DDoS?
- Tipos de ataques DDoS
- ¿Qué es el IP spoofing?
- ¿Qué es la amplificación DNS?
- Azion DDoS Protection
Preguntas frecuentes
¿Qué es un ataque Smurf? Un ataque Smurf es una técnica DDoS que envía una solicitud de eco ICMP a la dirección de broadcast IP de una red con la dirección de origen falsificada como la IP de la víctima. Cada host de esa red responde a la dirección falsificada de la víctima en lugar de al atacante, multiplicando un paquete en una inundación proporcional al número de hosts que responden en la red amplificadora.
¿Por qué se llama ataque Smurf? El nombre viene de smurf.c, el archivo de código fuente de la herramienta de ataque original, que circuló en comunidades hacker y de seguridad a partir de 1997. El nombre no tiene ningún significado técnico más allá del nombre de archivo de la herramienta.
¿Smurf sigue siendo un ataque viable hoy? Rara vez. El software de router moderno deshabilita el reenvío de broadcast dirigido IP por defecto (un cambio formalizado en Cisco IOS 12.0 en 1999 y reflejado posteriormente en la mayoría de los proveedores), lo que elimina el mecanismo del que depende Smurf para alcanzar a cada host en una subred objetivo. El equipo de red legado o mal configurado teóricamente todavía podría ser abusado, pero la población de redes amplificadoras viables ha colapsado.
¿Cuál es la diferencia entre los ataques Smurf y Fraggle? Smurf usa solicitud/respuesta de eco ICMP; Fraggle usa paquetes UDP dirigidos a servicios echo (puerto 7) o chargen (puerto 19). Ambos dependen del mismo mecanismo subyacente —broadcast dirigido IP más IP spoofing— y ambos fueron neutralizados por la misma corrección: deshabilitar el reenvío de broadcast dirigido en los routers.
¿Cómo habilita el IP spoofing un ataque Smurf? Sin IP spoofing, las respuestas de eco ICMP generadas por el broadcast regresarían a quien realmente envió el request: el atacante. Al forjar la dirección de origen como la IP de la víctima, el atacante redirige cada respuesta a la víctima en su lugar, que es lo que convierte al ataque en una denegación de servicio contra un tercero en lugar de contra la propia conexión del atacante.
¿Un firewall puede detener un ataque Smurf? Un firewall en la red de la víctima puede filtrar o limitar la tasa de respuestas de eco ICMP no solicitadas una vez que llegan, reduciendo el impacto, pero no puede prevenir que el ataque se genere en primer lugar; eso requiere que la red intermediaria (de rebote) rechace reenviar el broadcast dirigido. La corrección más efectiva ocurre upstream, a nivel de router de la red amplificadora, no en el firewall de la víctima.
¿Cuál es el factor de amplificación máximo para un ataque Smurf? No hay un factor fijo; la amplificación es proporcional al número de hosts activos que responden a ping en la subred de broadcast objetivo en el momento del ataque. Una red con 250 hosts que responden podría convertir un paquete del atacante en aproximadamente 250 paquetes de respuesta; subredes más grandes y densamente pobladas producen amplificación proporcionalmente más alta.
¿BCP38 previene los ataques Smurf? Sí, en principio. Como Smurf requiere IP spoofing para redirigir las respuestas a la víctima, el filtrado de ingreso BCP38 (RFC 2827) en la red del atacante bloquearía el paquete falsificado antes de que llegara a la red amplificadora. En la práctica, deshabilitar el reenvío de broadcast dirigido en los routers ha sido la corrección más universalmente efectiva, ya que no depende de la cooperación del ISP del atacante.
¿Cómo se relaciona Smurf con los ataques de amplificación modernos como DNS o NTP? Smurf estableció el patrón conceptual que reutilizan los ataques de amplificación posteriores: combinar IP spoofing con un servicio que responde a requests no solicitados, y dejar que el volumen de respuesta (o el número de hosts que responden) haga el trabajo de abrumar a una víctima. Amplificación DNS y Amplificación NTP reemplazan el multiplicador de red de broadcast con la respuesta desproporcionadamente grande de un solo servidor, pero el principio de spoofing más reflexión es idéntico.
¿Los ataques Smurf pueden lanzarse sobre redes IPv6? No, no en la misma forma. IPv6 no define direcciones de broadcast dirigido de la forma en que lo hace IPv4; se usa multicast en su lugar, y la membresía y el comportamiento de reenvío de grupo multicast de IPv6 están diseñados de forma distinta, lo que elimina el mecanismo específico del que depende Smurf. Las redes IPv6 siguen expuestas a otros ataques que dependen de spoofing, pero no a un equivalente directo de Smurf.
Fuentes:
- CERT|CC. “Advisory CA-1998-01: Smurf IP Denial-of-Service Attacks.” Enero de 1998.
- IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP38). 2000.
- IETF. “Internet Control Message Protocol.” RFC 792. 1981.
- Cisco Systems. “Configuring IP Directed Broadcast.” Documentación de Cisco IOS.
- CISA|US-CERT. “Understanding Denial-of-Service Attacks.”
- NIST SP 800-94. “Guide to Intrusion Detection and Prevention Systems (IDPS).”