La frecuencia y fuerza de los ataques de denegación de servicio distribuido (DDoS) van en aumento. Mediante la explotación de millones de dispositivos inseguros del Internet de las cosas (IoT), la creación de redes de robots (botnets) que realizan ataques volumétricos altamente distribuidos es más fácil e impactante que nunca. Además de los volúmenes de ataque más grandes, los esfuerzos cambian de la red y las capas de transporte a la capa de aplicación (Capa 7). Los ataques de la capa de aplicación son mucho más sofisticados, a menudo requieren menos recursos para derribar un sitio web o aplicación, y pueden interrumpir las operaciones con un impacto aún mayor.
Los ataques DDoS interrumpen las operaciones comerciales normales degradando el funcionamiento y la disponibilidad del sitio web y las aplicaciones, dejándolos, a veces, sin conexión por completo. El coste promedio por hora de inactividad debido a un fallo de infraesetructura es de 100 000 $ por hora. Es probable que los ataques de esta naturaleza generen pérdida de clientes, degradación de la marca y descenso de los negocios.
Los sitios web y las aplicaciones requieren la capacidad de resistencia y la inteligencia de una red escalable para combatir los ataques más grandes y nuevos. La protección contra amenazas no debe degradar el funcionamiento causado por las latencias inducidas por la seguridad y los servicios de seguridad deben ser fáciles de configurar para eliminar los errores de configuración, que introducen nuevas vulnerabilidades.
Empiece hoy
Defensa de los ataques más grandes
La capacidad de red de Cloudflare es un 15x más grande que el ataque DDoS más grande jamás registrado. Con una capacidad de 30 Tbps, puede gestionar cualquier ataque distribuido, incluidos los que se dirigen a la infraestructura DNS.
Inteligencia de red compartida
Con cada nueva propiedad, la red de Cloudflare se vuelve más inteligente. La base de datos de reputación de IP de Cloudflare identifica y bloquea nuevas y cambiantes amenazas en los 7 millones de propiedades en la red.
Sin concesiones de funcionamiento
Elimina las latencias inducidas por la seguridad mediante la integración con los servicios de funcionamiento incluidos de Cloudflare: CDN, enrutamiento inteligente, optimizaciones de sitio web y los últimos estándares web.
Al interrumpir la resolución DNS, un ataque de inundación DNS hará que un sitio web, API o aplicación web no funcione o no esté completamente disponible.
Un atacante aprovecha la funcionalidad de los resolvers DNS o NTP abiertos para saturar un servidor o red objetivo con tráfico de solicitudes amplificadas, donde el tamaño de la carga es mayor que el tamaño de la solicitud de origen.
Los ataques de inundación HTTP generan grandes volúmenes de solicitudes HTTP, GET o POST de múltiples fuentes dirigidas a la capa de aplicación, provocando la degradación o la falta de disponibilidad del servicio.
El enfoque de seguridad a capas de Cloudflare combina múltiples capacidades de seguridad en un solo servicio. Evita las interrupciones causadas por un mal tráfico, a la vez que permite un buen tráfico y mantiene los sitios web, aplicaciones y API con alta disponibilidad y funcionamiento.
Resultados clave
226 500 000
ataques bloqueados entre agosto de 2015 y noviembre de 2016 —500 000 ataques al día— y ninguno tuvo éxito.
95 %
de ahorro total de ancho de banda.
250 000 $
Lea el caso práctico
Brad Parscale
Presidente de Giles-Parscale
Director digital de la campaña de Trump
Todos los planes de Cloudflare ofrecen mitigación ilimitada y sin medida de los ataques de denegación de servicio distribuido (DDoS), independientemente del tamaño del ataque y sin coste adicional. Ningún cliente debería ser penalizado por los picos de tráfico de red asociados con un ataque distribuido. La protección DDoS de Cloudflare garantiza que todas las propiedades de Internet permanezcan en línea, mientras que los costes de infraestructura siguen siendo predecibles.
Los ingenieros de Cloudflare han sido testigos de algunos de los ataques más grandes de la historia. Descubra cómo los gestionamos en nuestro blog de desarrolladores.
En el invierno de 2016, Cloudflare mitigó su mayor ataque distribuido de Capa 3 hasta la fecha. No solo lo detuvo, sino que lo midió y analizó con precisión. Leer más
Los ataques distribuidos son de todas formas y maneras. En este ataque de amplificación de 400 Gb/s, un atacante utilizó 4529 servidores NTP para amplificar un ataque desde un simple servidor de origen de 87 Mb/s.
Leer más
Cloudlfare ha estado luchando contra ataques distribuidos históricos durante más de 7 años. En 2013, los 120 Gb en Spamhaus fue considerado un gran ataque, y Cloudflare fue capaz de mantener su sitio web en línea. Leer más
Empiece hoy
Evita que los atacantes pongan en peligro datos confidenciales de los clientes, como las credenciales de usuarios, información de tarjeta de crédito y otra información de identificación personal.
Bloquea a los bots abusivos para que no dañen las propiedades de Internet a través del raspado de contenido, pago fraudulento y adquisición de cuentas.
Los servicios de seguridad y funcionamiento de Cloudflare trabajan conjuntamente para reducir la latencia de los sitios web, las aplicaciones móviles y las API de extremo a extremo, a la vez que protegen contra ataques DDoS, bots abusivos y violaciones de datos.
Los servicios de funcionamiento de Cloudflare mejoran las conversaciones, reducen el abandono y mejoran las experiencias de los visitantes al acelerar el rendimiento web y móvil, a la vez que mantienen las aplicaciones disponibles.
Los servicios de seguridad de Cloudflare reducen el riesgo de pérdida de clientes, disminución de ingresos y degradación de la marca mediante la protección contra ataques DDoS, bots abusivos y violaciones de datos.
Dado que Cloudflare sirve como un proxy para todo el tráfico de su red, podemos protegerle de cualquier tipo de ataque de denegación de servicio distribuido, incluido todo lo siguiente:
La mayoría de ataques se dirigen a las capas de transporte y red de un sistema de comunicación. Estas capas se representan como las capas 3 y 4 del modelo OSI. La llamada capa de «transporte» de la pila de red especifica el protocolo (ej.: TCP o UDP) mediante el cual dos hosts se comunican entre sí en una red. Los ataques dirigidos a las capas 3 y 4 están diseñados para inundar una interfaz de red con tráfico de ataque para desbordar sus recursos y denegarle la capacidad de responder al tráfico legítimo. Más específicamente, los ataques de esta naturaleza pretenden saturar la capacidad de un conmutador de red, de la tarjeta de red de un servidor o la posibilidad de su CPU para gestionar el tráfico de ataque.
Los ataques de Capa 3 y 4 son difíciles, si no imposibles, de mitigar con una solución local. Si un atacante puede enviar más tráfico del que puede manejar un enlace de red, ninguna cantidad de recursos de hardware adicionales ayudará a mitigar dicho ataque. Por ejemplo, si tiene un enrutador con un puerto de 10 Gb/s y un atacante le envía 11 Gb/s de tráfico de ataque, ninguna cantidad de software o hardware inteligente le permitirá detener el ataque si el enlace de red está completamente saturado.
Los ataques de capa 3/4 muy grandes casi siempre se originan a partir de varias fuentes. Cada una de ellas envía tráfico de ataque a una única ubicación de Internet, creando un maremoto que sobrepasa los recursos del objetivo. En este sentido, el ataque se distribuye. Las fuentes de tráfico de ataque pueden ser un grupo de personas que trabajan en conjunto, una red de robots (botnet) de ordenadores o servidores comprometidos, resolvers DNS mal configurados o incluso enrutadores de Internet domésticos con contraseñas débiles.
Debido a que el atacante que lanza un ataque de Capa 3/4 no se preocupa por recibir una respuesta a las solicitudes que envía, los paquetes que componen el ataque no tienen que ser precisos ni estár formateados correctamente. Los atacantes falsificarán regularmente toda la información de los paquetes de ataque, incluida la IP de origen, haciendo que parezca que el ataque proviene de un número prácticamente infinito de fuentes. Como los datos de los paquetes se pueden aleatorizar por completo, incluso las técnicas como el filtrado de IP en sentido ascendente se vuelven prácticamente inútiles.
Con Cloudflare, todo el tráfico de ataque que, de otra manera, afectaría a la infraestructura de su servidor, se enruta automáticamente a la red Anycast global de centros de datos de Cloudflare. Una vez que se ha cambiado el tráfico de ataque, podemos aprovechar la importante capacidad global de nuestra red, así como la infraestructura de servidores, para absorber las inundaciones de tráfico en nuestro extremo de la red. Esto significa que Cloudflare puede evitar que incluso un solo paquete de tráfico de ataque procedente de un ataque tradicional de Capa 3/4 llegue a un sitio protegido por Cloudflare.
Los ataques de amplificación DNS, una forma de DRDoS, están en aumento y se han convertido en la mayor fuente de ataques de Capa 3/4. Cloudflare mitiga rutinariamente ataques que superan los 100 Gb/s, y recientemente protegió a un cliente de un ataque que excedió los 300 Gb/s, un ataque que el New York Times consideró el «mayor ataque DDoS anunciado públicamente de la historia de Internet».
En un ataque de reflexión DNS, el atacante envía una solicitud para un gran archivo de zona DNS, con la dirección IP de origen falsificada como la dirección IP de la víctima, a un gran número de resolvers DNS abiertos. Los resolvers responden a la solicitud enviando la gran respuesta de zona DNS a la dirección IP de la víctima. Las solicitudes del atacante en sí mismas solo son una fracción del tamaño de las respuestas, lo que permite al atacante amplificar su ataque muchas veces el tamaño de los recursos de ancho de banda que controlan.
Un atacante reúne recursos, como redes de robots (botnets) o recursors DNS no seguros, e imita la dirección IP del objetivo. Los recursos envían una avalancha de respuestas al objetivo, dejándolo fuera de línea.
Un atacante reúne recursos, como redes de robots (botnets) o recursors DNS no seguros, e imita la dirección IP del objetivo. Los recursos envían una avalancha de respuestas al objetivo, pero son bloqueadas regionalmente por los centros de datos de Cloudflare. El tráfico legítimo aún puede acceder a la propiedad web.
Hay dos criterios para un ataque de amplificación: 1. Se puede enviar una consulta con una dirección de origen falsificada (ej.: a través de un protocolo como ICMP o UDP que no requiere un establecimiento de conexión); y 2. La respuesta a la consulta es significativamente mayor que la propia consulta. DNS es una plataforma de Internet central y omnipresente que cumple con estos requisitos y, por lo tanto, se ha convertido en la mayor fuente de ataques de amplificación.
Las consultas DNS generalmente se transmiten a través de UDP, lo que significa que, al igual que las consultas ICMP utilizadas en un ataque SMURF (descrito a continuación), se disparan y olvidan. Como resultado, el atributo de origen de una consulta DNS puede ser falsificado y el receptor no tiene forma de determinar su veracidad antes de responder. La DNS también es capaz de generar una respuesta mucho mayor que la solicitud: por ejemplo, puede enviar la siguiente consulta (minúscula), donde x.x.x.x es la IP de un resolver DNS abierto:
dig ANY isc.org @x.x.x.x +edns=0
Y recibir la siguiente respuesta gigantesca:
; <<>> DiG 9.7.3 <<>> ANY isc.org @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5147
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 4, ADDITIONAL: 5
;; QUESTION SECTION:
;isc.org. IN ANY
;; ANSWER SECTION:
isc.org. 4084 IN SOA ns-int.isc.org. hostmaster.isc.org. 2012102700 7200 3600 24796800 3600
isc.org. 4084 IN A 149.20.64.42
isc.org. 4084 IN MX 10 mx.pao1.isc.org.
isc.org. 4084 IN MX 10 mx.ams1.isc.org.
isc.org. 4084 IN TXT "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org. 4084 IN TXT "$Id: isc.org,v 1.1724 2012-10-23 00:36:09 bind Exp $"
isc.org. 4084 IN AAAA 2001:4f8:0:2::d
isc.org. 4084 IN NAPTR 20 0 "S" "SIP+D2U" "" _sip._udp.isc.org.
isc.org. 484 IN NSEC _kerberos.isc.org. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY SPF
isc.org. 4084 IN DNSKEY 256 3 5 BQEAAAAB2F1v2HWzCCE9vNsKfk0K8vd4EBwizNT9KO6WYXj0oxEL4eOJ aXbax/BzPFx+3qO8B8pu8E/JjkWH0oaYz4guUyTVmT5Eelg44Vb1kssy q8W27oQ+9qNiP8Jv6zdOj0uCB/N0fxfVL3371xbednFqoECfSFDZa6Hw jU1qzveSsW0=
isc.org. 4084 IN DNSKEY 257 3 5 BEAAAAOhHQDBrhQbtphgq2wQUpEQ5t4DtUHxoMVFu2hWLDMvoOMRXjGr hhCeFvAZih7yJHf8ZGfW6hd38hXG/xylYCO6Krpbdojwx8YMXLA5/kA+ u50WIL8ZR1R6KTbsYVMf/Qx5RiNbPClw+vT+U8eXEJmO20jIS1ULgqy3 47cBB1zMnnz/4LJpA0da9CbKj3A254T515sNIMcwsB8/2+2E63/zZrQz Bkj0BrN/9Bexjpiks3jRhZatEsXn3dTy47R09Uix5WcJt+xzqZ7+ysyL KOOedS39Z7SDmsn2eA0FKtQpwA6LXeG2w+jxmw3oA8lVUgEf/rzeC/bB yBNsO70aEFTd
isc.org. 4084 IN SPF "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org. 484 IN RRSIG NS 5 2 7200 20121125230752 20121026230752 4442 isc.org. oFeNy69Pn+/JnnltGPUZQnYzo1YGglMhS/SZKnlgyMbz+tT2r/2v+X1j AkUl9GRW9JAZU+x0oEj5oNAkRiQqK+D6DC+PGdM2/JHa0X41LnMIE2NX UHDAKMmbqk529fUy3MvA/ZwR9FXurcfYQ5fnpEEaawNS0bKxomw48dcp Aco=
isc.org. 484 IN RRSIG SOA 5 2 7200 20121125230752 20121026230752 4442 isc.org. S+DLHzE/8WQbnSl70geMYoKvGlIuKARVlxmssce+MX6DO/J1xdK9xGac XCuAhRpTMKElKq2dIhKp8vnS2e+JTZLrGl4q/bnrrmhQ9eBS7IFmrQ6s 0cKEEyuijumOPlKCCN9QX7ds4siiTIrEOGhCaamEgRJqVxqCsg1dBUrR hKk=
isc.org. 484 IN RRSIG MX 5 2 7200 20121125230752 20121026230752 4442 isc.org. VFqFWRPyulIT8VsIdXKMpMRJTYpdggoGgOjKJzKJs/6ZrxmbJtmAxgEu /rkwD6Q9JwsUCepNC74EYxzXFvDaNnKp/Qdmt2139h/xoZsw0JVA4Z+b zNQ3kNiDjdV6zl6ELtCVDqj3SiWDZhYB/CR9pNno1FAF2joIjYSwiwbS Lcw=
isc.org. 484 IN RRSIG TXT 5 2 7200 20121125230752 20121026230752 4442 isc.org. Ojj8YCZf3jYL9eO8w4Tl9HjWKP3CKXQRFed8s9xeh5TR3KI3tQTKsSeI JRQaCXkADiRwHt0j7VaJ3xUHa5LCkzetcVgJNPmhovVa1w87Hz4DU6q9 k9bbshvbYtxOF8xny/FCiR5c6NVeLmvvu4xeOqSwIpoo2zvIEfFP9deR UhA=
isc.org. 484 IN RRSIG AAAA 5 2 7200 20121125230752 20121026230752 4442 isc.org. hutAcro0NBMvKU/m+2lF8sgIYyIVWORTp/utIn8KsF1WOwwM2QMGa5C9 /rH/ZQBQgN46ZMmiEm4LxH6mtaKxMsBGZwgzUEdfsvVtr+fS5NUoA1rF wg92eBbInNdCvT0if8m1Sldx5/hSqKn8EAscKfg5BMQp5YDFsllsTauA 8Y4=
isc.org. 484 IN RRSIG NAPTR 5 2 7200 20121125230752 20121026230752 4442 isc.org. ZD14qEHR7jVXn5uJUn6XR9Lvt5Pa7YTEW94hNAn9Lm3Tlnkg11AeZiOU 3woQ1pg+esCQepKCiBlplPLcag3LHlQ19OdACrHGUzzM+rnHY50Rn/H4 XQTqUWHBF2Cs0CvfqRxLvAl5AY6P2bb/iUQ6hV8Go0OFvmMEkJOnxPPw 5i4=
isc.org. 484 IN RRSIG NSEC 5 2 3600 20121125230752 20121026230752 4442 isc.org. rY1hqZAryM045vv3bMY0wgJhxHJQofkXLeRLk20LaU1mVTyu7uair7jb MwDVCVhxF7gfRdgu8x7LPSvJKUl6sn731Y80CnGwszXBp6tVpgw6oOcr Pi0rsnzC6lIarXLwNBFmLZg2Aza6SSirzOPObnmK6PLQCdmaVAPrVJQs FHY=
isc.org. 484 IN RRSIG DNSKEY 5 2 7200 20121125230126 20121026230126 4442 isc.org. i0S2MFqvHB3wOhv2IPozE/IQABM/eDDCV2D7dJ3AuOwi1A3sbYQ29XUd BK82+mxxsET2U6hv64crpbGTNJP3OsMxNOAFA0QYphoMnt0jg3OYg+AC L2j92kx8ZdEhxKiE6pm+cFVBHLLLmXGKLDaVnffLv1GQIl5YrIyy4jiw h0A=
isc.org. 484 IN RRSIG DNSKEY 5 2 7200 20121125230126 20121026230126 12892 isc.org. j1kgWw+wFFw01E2z2kXq+biTG1rrnG1XoP17pIOToZHElgpy7F6kEgyj fN6e2C+gvXxOAABQ+qr76o+P+ZUHrLUEI0ewtC3v4HziMEl0Z2/NE0MH qAEdmEemezKn9O1EAOC7gZ4nU5psmuYlqxcCkUDbW0qhLd+u/8+d6L1S nlrD/vEi4R1SLl2bD5VBtaxczOz+2BEQLveUt/UusS1qhYcFjdCYbHqF JGQziTJv9ssbEDHT7COc05gG+A1Av5tNN5ag7QHWa0VE+Ux0nH7JUy0N ch1kVecPbXJVHRF97CEH5wCDEgcFKAyyhaXXh02fqBGfON8R5mIcgO/F DRdXjA==
isc.org. 484 IN RRSIG SPF 5 2 7200 20121125230752 20121026230752 4442 isc.org. IB/bo9HPjr6aZqPRkzf9bXyK8TpBFj3HNQloqhrguMSBfcMfmJqHxKyD ZoLKZkQk9kPeztau6hj2YnyBoTd0zIVJ5fVSqJPuNqxwm2h9HMs140r3 9HmbnkO7Fe+Lu5AD0s6+E9qayi3wOOwunBgUkkFsC8BjiiGrRKcY8GhC kak=
isc.org. 484 IN RRSIG A 5 2 7200 20121125230752 20121026230752 4442 isc.org. ViS+qg95DibkkZ5kbL8vCBpRUqI2/M9UwthPVCXl8ciglLftiMC9WUzq Ul3FBbri5CKD/YNXqyvjxyvmZfkQLDUmffjDB+ZGqBxSpG8j1fDwK6n1 hWbKf7QSe4LuJZyEgXFEkP16CmVyZCTITUh2TNDmRgsoxrvrOqOePWhp 8+E=
isc.org. 4084 IN NS ns.isc.afilias-nst.info.
isc.org. 4084 IN NS ams.sns-pb.isc.org.
isc.org. 4084 IN NS ord.sns-pb.isc.org.
isc.org. 4084 IN NS sfba.sns-pb.isc.org.
;; AUTHORITY SECTION:
isc.org. 4084 IN NS ns.isc.afilias-nst.info.
isc.org. 4084 IN NS ams.sns-pb.isc.org.
isc.org. 4084 IN NS ord.sns-pb.isc.org.
isc.org. 4084 IN NS sfba.sns-pb.isc.org.
;; ADDITIONAL SECTION:
mx.ams1.isc.org. 484 IN A 199.6.1.65
mx.ams1.isc.org. 484 IN AAAA 2001:500:60::65
mx.pao1.isc.org. 484 IN A 149.20.64.53
mx.pao1.isc.org. 484 IN AAAA 2001:4f8:0:2::2b
_sip._udp.isc.org. 4084 IN SRV 0 1 5060 asterisk.isc.org.
;; Query time: 176 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Oct 30 01:14:32 2012
;; MSG SIZE rcvd: 3223
Es una consulta de 64 bytes que ha dado como resultado una respuesta de 3223 bytes. En otras palabras, un atacante es capaz de logar una amplificación de 50 veces sobre cualquier tráfico que puedan iniciar en un resolver DNS abierto.
La red Anycast de Cloudflare fue diseñada específicamente para detener ataques masivos de Capa 3/4. Al utilizar difusión por proximidad (anycast) podemos anunciar las mismas direcciones IP desde cada uno de nuestros 194 centros de datos en todo el mundo. La red en sí misma carga las solicitudes de equilibrio en la instalación más cercana. En circunstancias normales, esto nos ayuda a garantizar que los visitantes de su sitio se dirijan automáticamente al centro de datos más cercano de nuestra red para garantizar el mejor funcionamiento. Cuando hay un ataque, Anycast sirve para dispersar y diluir de manera eficaz todo el tráfico de ataque a través de nuestra red de centros de datos. Como cada centro de datos anuncia la misma dirección IP para cualquier cliente de Cloudflare, el tráfico no puede dirigirse a ninguna ubicación. De esta manera, el ataque pasa de ser de muchos contra uno a muchos contra muchos, sin un solo punto de fallo en la red.
Una nueva clase de ataques tiene como objetivo la Capa 7 del modelo OSI, la capa de «aplicación». Estos ataques se centran en las características específicas de las aplicaciones web que crean cuellos de botella. Por ejemplo, el llamado ataque de lectura envía paquetes lentamente a través de múltiples conexiones. Debido a que Apache abre un nuevo hilo para cada conexión, y como las conexiones se mantienen siempre que se siga enviando tráfico, un atacante puede sobrecargar un servidor web agotando su grupo de subprocesos de forma relativamente rápida.
Cloudflare tiene protecciones contra muchos de estos ataques, y en las experiencias del mundo real, hemos reducido el tráfico de ataque HTTP en un 90 %. Para la mayoría de ataques, y de clientes, esto es suficiente para mantenerles en línea. Sin embargo, el 10 % del tráfico que atraviesa las protecciones tradicionales puede ser abrumador para clientes con recursos limitados o en ataques muy grandes. En este caso, Cloudflare ofrece una configuración llamada modo «I'm Under Attack» (IUAM), que significa «Estoy sufriendo un ataque».
IUAM es un nivel de seguridad que puede configurar para su sitio cuando está sufriendo un ataque. Cuando se activa el modo IUAM, Cloudflare añadirá una capa adicional de protección para evitar que el tráfico HTTP malicioso llegue a su servidor. Mientras se realizan una serie de controles adicionales en segundo plano, se presenta una página intersticial a los visitantes de su sitio durante 5 segundos, para que se completen las comprobaciones. Piense en ello como un desafío donde las pruebas son automáticas y los visitantes nunca tendrán que rellenar un CAPTCHA.
Después de que las pruebas automatizadas verifiquen a sus visitantes como legítimos, podrán navegar por su sitio sin problemas. Se requiere JavaScript y cookies para las pruebas, y para registrar que estas se pasaron con éxito. La página que ven sus visitantes durante el modo IUAM puede personalizarse para que refleje su marca. Este modo no bloquea los rastreadores del motor de búsqueda o su lista blanca existente de Cloudflare.
Uno de los primeros ataques de amplificación se denominó ataque SMURF. En un ataque SMURF, un atacante envía solicitudes ICMP (es decir, solicitudes de ping) a una dirección de difusión de red (ej.: X.X.X.255) anunciada desde un enrutador configurado para transmitir ICMP a todos los dispositivos detrás del enrutador. El atacante suplanta el origen de la solicitud ICMP para que sea la dirección IP de la víctima. Como el ICMP no incluye establecimiento de conexión, el destino no tiene medios para verificar si la dirección IP de origen es legítima. El enrutador recibe la solicitud y la pasa a todos los dispositivos que se encuentran detrás de él. Cada uno de estos dispositivos responde con el ping. El atacante puede amplificar el ataque en un múltiplo igual al número de dispositivos por detrás del enrutador (ej.: si tiene 5 dispositivos detrás del enrutador, el atacante podrá amplificar el ataque por 5, consulte el siguiente diagrama).
Los ataques SMURF suelen ser cosa del pasado. La mayoría de operarios de red han configurado sus enrutadores para desactivar la transmisión de solicitudes ICMP enviadas a la dirección de difusión de red.
