stringtranslate.com

Ataque de pitufos

Un ataque Smurf es un ataque distribuido de denegación de servicio en el que se transmiten grandes cantidades de paquetes del Protocolo de mensajes de control de Internet (ICMP) con la dirección IP de origen falsificada de la víctima a una red informática mediante una dirección de difusión IP . [1] La mayoría de los dispositivos de una red responderán, de forma predeterminada, enviando una respuesta a la dirección IP de origen. Si la cantidad de máquinas de la red que reciben y responden a estos paquetes es muy grande, la computadora de la víctima se inundará de tráfico. Esto puede ralentizar la computadora de la víctima hasta el punto en que se vuelva imposible trabajar en ella.

Historia

La herramienta original para crear un ataque Smurf fue escrita por Dan Moschuk (alias TFreak) en 1997. [2] [3]

A finales de los años 90, muchas redes IP participaban en ataques Smurf si se les solicitaba (es decir, respondían a solicitudes ICMP enviadas a direcciones de difusión). El nombre proviene de la idea de que atacantes muy pequeños, pero numerosos, abrumen a un oponente mucho más grande (véase Smurfs ). Hoy en día, los administradores pueden hacer que una red sea inmune a este tipo de abuso; por lo tanto, muy pocas redes siguen siendo vulnerables a los ataques Smurf. [4]

Método

Un amplificador Smurf es una red informática que se presta a ser utilizada en un ataque Smurf. Los amplificadores Smurf actúan para empeorar la gravedad de un ataque Smurf porque están configurados de tal manera que generan una gran cantidad de respuestas ICMP a la víctima en la dirección IP de origen falsificada.

En DDoS, la amplificación es el grado de mejora del ancho de banda que sufre el tráfico de un ataque original (con la ayuda de amplificadores Smurf) durante su transmisión hacia el equipo víctima. Un factor de amplificación de 100, por ejemplo, significa que un atacante podría lograr crear 100 Mb/s de tráfico utilizando solo 1 Mb/s de su propio ancho de banda. [5]

Suponiendo que no se tomen contramedidas para atenuar el efecto de un ataque Smurf, esto es lo que sucede en la red de destino con n hosts activos (que responderán a las solicitudes de eco ICMP). Los paquetes de solicitud de eco ICMP tienen una dirección de origen falsificada (el objetivo de los Smurfs) y una dirección de destino (el chivo expiatorio; la fuente aparente del ataque). Ambas direcciones pueden adoptar dos formas: unicast y broadcast .

La forma de unidifusión dual es comparable a un ping normal: se envía una solicitud de eco ICMP al receptor (un único host), que envía una única respuesta de eco ICMP (un Smurf) de vuelta al objetivo (el único host en la dirección de origen). Este tipo de ataque tiene un factor de amplificación de 1, lo que significa: sólo un único Smurf por ping.

Cuando el objetivo es una dirección unicast y el destino es la dirección broadcast de la red del objetivo, todos los hosts de la red recibirán una solicitud de eco. A cambio, cada uno de ellos responderá al objetivo, por lo que el objetivo se verá inundado de n Smurfs. Factor de amplificación = n . Si n es pequeño, un host puede verse obstaculizado, pero no paralizado. Si n es grande, un host puede detenerse.

Si el objetivo es la dirección de difusión y el chivo expiatorio una dirección de unidifusión, cada host de la red recibirá un único Smurf por ping, por lo que el factor de amplificación será de 1 por host, pero el factor n será para la red. En general, una red podría hacer frente a esta forma de ataque, si el valor n no es demasiado grande.

Cuando tanto la dirección de origen como la de destino del paquete original se configuran en la dirección de difusión de la red de destino, las cosas comienzan a salirse de control rápidamente. Todos los hosts reciben una solicitud de eco, pero todas las respuestas a esa solicitud se transmiten nuevamente a todos los hosts. Cada host recibirá un ping inicial, transmitirá la respuesta y obtendrá una respuesta de todos los n-1 hosts. Un factor de amplificación de n para un solo host, pero un factor de amplificación de n 2 para la red.

Las solicitudes de eco ICMP se envían normalmente una vez por segundo. La respuesta debe contener el contenido de la solicitud; normalmente, unos pocos bytes. Un solo ping (doble difusión) a una red con 100 hosts hace que la red procese 10 000 paquetes. Si la carga útil del ping aumenta a 15 000 bytes (o 10 paquetes completos en Ethernet ), ese ping hará que la red tenga que procesar 100 000 paquetes grandes por segundo. Si se envían más paquetes por segundo, cualquier red colapsaría bajo la carga. Esto hará que cualquier host de la red sea inaccesible mientras dure el ataque.

Efecto

Un ataque Smurf puede saturar los servidores y las redes. El ancho de banda de la red de comunicación puede agotarse y provocar que la red de comunicación quede paralizada. [6]

Mitigación

La solución es doble:

  1. Configurar hosts y enrutadores para ignorar paquetes donde la dirección de destino es una dirección de difusión; y
  2. Configurar los enrutadores para que no reenvíen paquetes dirigidos a direcciones de difusión. Hasta 1999, los estándares exigían que los enrutadores reenviaran dichos paquetes de forma predeterminada. Desde entonces, el estándar predeterminado se modificó para que no reenvíen dichos paquetes. [7]

También es importante que los ISP implementen un filtrado de ingreso , que rechace los paquetes atacantes basándose en la dirección de origen falsificada. [8]

Mitigación en un enrutador Cisco

Un ejemplo de configuración de un enrutador para que no reenvíe paquetes a direcciones de difusión, para un enrutador Cisco , es:

Router(config-if)# no ip directed-broadcast[9]

(Este ejemplo no protege a una red de convertirse en el objetivo de un ataque Smurf; simplemente evita que la red participe en un ataque Smurf).

Ataque Fraggle

Un ataque Fraggle (llamado así por las criaturas de la serie de televisión de marionetas Fraggle Rock ) es una variación de un ataque Smurf en el que un atacante envía una gran cantidad de tráfico UDP a los puertos 7 ( Echo ) y 19 ( CHARGEN ). Funciona de manera similar al ataque Smurf en el sentido de que muchas computadoras en la red responderán a este tráfico enviando tráfico de regreso a la IP de origen falsificada de la víctima, inundándola con tráfico. [10]

Fraggle.c, el código fuente del ataque, también fue publicado por TFreak. [11]

Véase también

Referencias

  1. ^ Sun, Fei Xian (2011). "Modelo de evaluación de riesgos basado en la teoría del peligro para ataques de pitufos". Materiales de ingeniería clave . 467–469: 515–521. doi :10.4028/www.scientific.net/KEM.467-469.515. ISSN  1662-9795. S2CID  110045205.
  2. ^ "Tfreak". Hackepedia. 28 de marzo de 2013. Consultado el 13 de noviembre de 2019 .
  3. ^ Pramatarov, Martin (9 de septiembre de 2021). "¿Qué es un ataque DDoS Smurf?". Blog de ClouDNS . Consultado el 15 de septiembre de 2022 .
  4. ^ Por ejemplo, netscan.org (Web Archive) mostró 122.945 redes rotas al 25 de enero de 1999, pero sólo 2.417 al 6 de enero de 2005.
  5. ^ S. Kumar (5 de julio de 2007). Kumar, Sanjeev (2007). "Amplificación de ataques de denegación de servicio distribuidos (DDoS) basados ​​en Smurf en Internet". Segunda Conferencia Internacional sobre Monitoreo y Protección de Internet (ICIMP 2007) . pág. 25. doi :10.1109/ICIMP.2007.42. ISBN 978-0-7695-2911-0. S2CID  14876546 . Consultado el 30 de diciembre de 2020 . {{cite book}}: |website=ignorado ( ayuda )
  6. ^ Hartanto, Sri (30 de julio de 2023). "El impacto del ataque Smurf en el servidor web de la red de comunicaciones y sus prevenciones". Revista internacional de ciencias aplicadas sostenibles (IJSAS) . 1 (1). Sri Hartanto: 35–46. ISSN  3025-5597.
  7. ^ D. Senie (agosto de 1999). Cambio de los valores predeterminados para las transmisiones dirigidas en los enrutadores. Grupo de trabajo de redes. doi : 10.17487/RFC2644 . BCP 34. RFC 2644. Mejores prácticas comunes. Actualizaciones RFC 1812.
  8. ^ Ferguson, P.; Senie, D. (mayo de 2000). Filtrado de entrada a la red: cómo vencer los ataques de denegación de servicio que emplean suplantación de direcciones IP de origen. IETF . doi : 10.17487/RFC2827 . BCP 38. RFC 2827. Mejor práctica común.
  9. ^ "Guía de Cisco para la defensa contra ataques distribuidos de denegación de servicio". Cisco . Consultado el 26 de septiembre de 2019 .
  10. ^ Hendric, William (23 de marzo de 2016). "Ataque Fraggle".
  11. ^ Anónimo (2003). Máxima seguridad. Sams Publishing. ISBN 978-0-672-32459-8.

Enlaces externos