BLOG

Entendiendo el último mes de ataques DDoS

Miniatura F5
F5
Publicado el 27 de octubre de 2016

En este artículo, analizaremos brevemente el impacto de los ataques #DDoS sin precedentes de septiembre y octubre de 2016 y brindaremos orientación para aquellos interesados en mejorar su resiliencia.

¡Celebremos que el Internet de las Cosas ha llegado! Sabemos que finalmente está aquí porque se utilizó como arma cibernética tres veces a partir de septiembre. Todo comenzó con un ataque masivo contra el periodista bloguero Brian Krebs, cuyo sitio web krebsonsecurity.com estaba alojado y protegido por la CDN Akamai. El ataque fue lo suficientemente grave como para afectar a otros clientes de Akamai, por lo que abandonaron su defensa pro bono del bloguero.

Los investigadores de la industria (incluido F5) fueron alertados sobre una nueva botnet compuesta por DVR, cámaras de video y otras “cosas”. Pero los DVR y las cámaras de vídeo son importantes porque tienen una gran capacidad de CPU (que, por lo tanto, puede albergar malware sofisticado) y enlaces ascendentes de gran ancho de banda (desde los que lanzaron ataques de hasta 100 Mbs cada uno). El tráfico de ataque total dirigido a Krebs fue de 620 Gbs, lo que en ese momento fue el ataque DDoS más grande del mundo.

El segundo ataque dejó fuera de servicio a OVH, el mayor proveedor de hosting francés (el tercero del mundo, si creemos en la literatura) durante gran parte del día. Muchos informes de los medios de comunicación estimaron que el ataque de OVH tuvo un tamaño casi el doble del ataque de Krebs: un terabit por segundo.

El tercer y posiblemente peor ataque fue contra Dyn, la empresa de servicios DNS. Dyn es el proveedor de DNS de muchos sitios web importantes, incluidos Twitter, Spotify y GitHub (donde irónicamente se publicó el código de la botnet IoT).

Entonces ¿quién lo hizo?

Por una extraña coincidencia, la luminaria de la industria Bruce Schneier había estado en el circuito de entrevistas el mes anterior advirtiendo sobre ataques DDoS masivos por parte de estados nacionales que estaban por venir. Su información privilegiada provenía de fuentes anónimas de la industria que estaban detectando ataques DDoS de calibración contra la infraestructura central de Internet.

Pero resulta que esos ataques de investigación pueden haber sido mera coincidencia. El propio Schneier admitió en su blog que no cree en absoluto que el ataque a Dyn fuera un Estado-nación. Pero quizá ese Estado-nación simplemente esté observando y esperando.

La clave de la atribución en los casos Krebs, OVH y Dyn probablemente provenga del propio Brian Krebs .

El ataque a DYN se produjo apenas horas después de que el investigador de DYN , Doug Madory, presentara una charla sobre ataques DDoS en Dallas, Texas, durante una reunión del Grupo de Operadores de Red de Norteamérica (NANOG). El ataque DDoS récord de 620 Gbps contra KrebsOnSecurity.com se produjo apenas horas después de que publicara el artículo en el que colaboramos Madory.

Es muy probable que el adversario sea un individuo (o un pequeño grupo) con una agenda contra Brian Krebs o Doug Madory, o ambos.

Todos podríamos comprender que millones de usuarios se verían afectados por una ciberguerra a gran escala entre China y Estados Unidos. ¿Pero qué pasa si resulta ser una agenda personal de un solo individuo contra otro solo individuo? Esto es aún más aterrador que un ataque por parte de un estado-nación. ¿Qué clase de Internet hemos construido cuando una sola persona con rencor hacia otra puede interrumpir servicios críticos para millones de personas?

¿Cómo llegamos aquí?

F5 ha estado monitoreando la búsqueda de dispositivos de Internet de las cosas (IoT) durante más de un año. Nuestro primer informe sobre este problema se publicó en julio de 2016 y mostró un aumento del 140 % año tras año en los escaneos de fuerza bruta de Telnet y SSH. Telnet y SSH son puertos de administración remota ampliamente utilizados y a menudo quedan expuestos sin que se sepa a Internet con nombres de usuario y contraseñas predeterminados del proveedor (o fáciles de adivinar).

Los ataques DDoS sin precedentes contra Krebs, OVH y Dyn en octubre de 2016 utilizaron exactamente esta técnica (escanear puertos telnet y contraseñas predeterminadas de proveedores en dispositivos IoT) para crear una botnet con una capacidad única.

Todos son nuevamente un objetivo. Los pastores de bots no tienen miedo de usar su arma cibernética contra algunos de los proveedores más grandes del mundo: objetivos que antes se consideraban intocables.

Si bien estos ataques pueden parecer que ocurrieron de la noche a la mañana, en realidad, el pastor del bot ha estado buscando, encontrando y comprometiendo lentamente dispositivos IoT vulnerables durante al menos un año.

Profundicemos en lo que sabemos

En realidad, tenemos una idea bastante clara de las capacidades de la botnet IoT, Mirai. Los investigadores de F5 escribieron un análisis técnico del bot Mirai poco después de que su autor publicara el código fuente en hackforums.net.

Es probable que la potencia de fuego colectiva sea un orden de magnitud mayor que la de las botnets anteriores: más de terabits por segundo.

La botnet IoT incluye (pero no se limita a) las siguientes técnicas DDoS avanzadas. La siguiente sección de orientación prescriptiva proporcionará recomendaciones sobre cómo mitigar estos problemas, cuando sea posible.

Inundaciones HTTP GET resistentes a la redirección

Las inundaciones de HTTP GET ya eran perniciosas. Durante años, los atacantes han podido desactivar sitios web enviando una avalancha de solicitudes HTTP para objetos grandes o consultas lentas a bases de datos. Normalmente, estas solicitudes fluyen directamente a través de un firewall estándar porque se parecen a las solicitudes HTTP normales para la mayoría de los dispositivos con procesamiento de paquetes de hardware. El código de ataque de Mirai va un paso más allá al identificar los depuradores DDoS basados en la nube y luego evitar cualquier redirección 302 que envíen los depuradores. Las redirecciones solían ser una buena forma de frustrar a los bots simples, pero este no es simple .

Tortura del agua DNS

El bot Mirai incluye un ataque de “tortura de agua” contra un proveedor de DNS objetivo. Esta técnica es diferente del ataque de amplificación de DNS porque requiere que el bot envíe significativamente menos consultas, lo que permite que el servidor DNS recursivo del ISP realice el ataque en el servidor DNS autorizado de destino. En este ataque, el bot envía una consulta DNS bien formada que contiene el nombre de dominio de destino a resolver, mientras agrega un prefijo generado aleatoriamente al nombre. El ataque se vuelve efectivo cuando el servidor DNS de destino se sobrecarga y no responde. Los servidores DNS del ISP luego retransmiten automáticamente la consulta para probar otro servidor DNS autorizado de la organización objetivo, atacando así esos servidores en nombre del bot.

Dyn confirmó en su blog, Resumen del análisis de Dyn del ataque del viernes 21 de octubre , que efectivamente se utilizó la tortura del agua contra ellos.

“Por ejemplo, el impacto del ataque generó una tormenta de actividad de reintento legítima a medida que los servidores recursivos intentaban actualizar sus cachés, creando un volumen de tráfico entre 10 y 20 veces superior al normal en una gran cantidad de direcciones IP. Cuando se produce una congestión del tráfico de DNS, los reintentos legítimos pueden contribuir aún más al volumen de tráfico.

Parece que los ataques maliciosos tuvieron su origen en al menos una red de bots, y la tormenta de reintentos proporcionó un indicador falso de un conjunto de puntos finales significativamente más grande de lo que ahora sabemos que es. Todavía estamos trabajando en el análisis de los datos, pero la estimación al momento de este informe es de hasta 100.000 puntos finales maliciosos”.

El investigador de F5, Liron Segal, había detallado la mecánica del ataque Tortura de Agua del bot en su publicación semanas antes: Mirai, el bot que derrotó a Krebs.

Ataques de capa 4 actualizados

Según el creador del bot, el llamado ataque “TCP STOMP” es una variación de la simple inundación de ACK destinada a eludir los dispositivos de mitigación. Al analizar la implementación real de este ataque, parece que el bot abre una conexión TCP completa y luego continúa inundando con paquetes ACK que tienen números de secuencia legítimos para mantener activa la conexión.

Dada nuestra comprensión de los vectores de amenaza individuales con el nuevo bot de IoT, podemos brindar cierta orientación para la mitigación de esos vectores de amenaza individuales.

Seamos claros antes de comenzar con la orientación. Los ataques Krebs, OVH y Dyn son una clase aparte. Está claro que las técnicas de mitigación de DDoS existentes no lograron hacer retroceder fácilmente a los atacantes, de ahí las interrupciones y la cobertura mediática en los titulares. Sin embargo, en muchos casos las medidas de mitigación finalmente surtieron efecto. Y una arquitectura adecuada, como el uso de Anycast y centros de datos dispersos, también ayudó. Cabe señalar que la Costa Oeste y las regiones occidentales de los EE. UU. prácticamente no se vieron afectadas por el ataque de Dyn.

Orientación prescriptiva

Nuestra orientación viene de nuestros propios clientes. F5 ha estado entregando aplicações para las marcas más importantes del mundo durante veinte años, y muchos de esos clientes sufren ataques DDoS todos los días. Nuestros clientes más experimentados dividen sus defensas en tres o cuatro zonas:

  • Limpieza de nubes
  • Defensa de la red
  • Defensa de aplicaciones
  • DNS, cuando corresponda

Una arquitectura superlativa resistente a DDoS se ve así:

Esta es la arquitectura de referencia de protección DDoS, que ha sido ampliamente utilizada por los clientes de F5 durante años. La arquitectura de referencia completa y las prácticas recomendadas se pueden encontrar en F5.com. Sin embargo, para un consumo más rápido, la orientación relevante a estos ataques se detalla a continuación.

Defensa volumétrica

La empresa de hosting francesa OVH fue víctima de un ataque volumétrico de 990 Gb. Hubo informes de que el ataque de Dyn alcanzó un máximo de 1,2 terabits. Los ataques de ese tamaño generalmente solo pueden mitigarse mediante depuradores de nubes que se especializan en defensa a escala. Los depuradores de nubes, incluido Silverline DDoS Protection de F5, interceptan el tráfico de ataque, lo limpian y envían solo el tráfico bueno al objetivo a través de túneles preestablecidos.

Guía: Las organizaciones deben asegurarse de tener acuerdos con uno o más depuradores de nubes antes de ser atacadas. Configurar los túneles preestablecidos no es algo que pueda hacerse fácilmente en medio de un ataque volumétrico. Contrate un servicio de defensa DDoS con limpieza de nubes como parte de su estrategia DDoS.

Guía: La difusión de ataque puede ser tu amiga para los ataques volumétricos. Recuerde que el DNS también puede ser su amigo; Anycast a sus centros de datos globales para contenido replicado para difundir ataques DDoS cuando ocurran. Cada centro de datos que participa con Anycast puede ayudar a dividir el ataque.

Materiales relevantes:

Defensa de la red

El bot Mirai incluye varios ataques de capa 4 en su arsenal: inundaciones SYN estándar, inundaciones TCP e inundaciones UDP. Estos antiguos vectores de amenaza se deben mitigar ya sea en un depurador de nubes o, si son suficientemente pequeños, en el nivel de defensa de la red en el centro de datos. El nivel de defensa de la red se construye alrededor del firewall de la red. Está diseñado para mitigar ataques computacionales como inundaciones SYN e inundaciones de fragmentación ICMP. Este nivel también mitiga los ataques volumétricos hasta la congestión del punto de ingreso (normalmente entre el 80 y el 90 por ciento del tamaño nominal de la tubería).

Guía: Muchos firewalls no son resistentes a ataques DDoS a menos que estén configurados correctamente. Consulte con el proveedor de su firewall de red la configuración. Algunos clientes colocarán dispositivos anti-DDoS delante de sus firewalls para repeler ataques de capa 4.

Guía: El módulo de firewall F5 (BIG-IP Advanced Firewall Manager (AFM)), fue diseñado específicamente para repeler ataques de capa 4. Algunos arquitectos utilizan BIG-IP AFM precisamente para este caso, ya sea delante o reemplazando los firewalls de red convencionales. Los dispositivos de hardware con AFM utilizan matrices de puertas programables en campo para repeler más de 30 tipos de inundaciones de paquetes y descargar el trabajo de la CPU.

Materiales relevantes:

Defensa de aplicaciones

El bot Mirai puede generar impresionantes inundaciones HTTP GET y manejar direcciones. Dado que las inundaciones GET parecen tráfico normal para los dispositivos de defensa de la red, deben manejarse en el nivel de aplicação . Las inundaciones GET son por lejos el tipo de ataque de capa de aplicação más común que F5 ve, y hay muchas formas de mitigarlas, dependiendo de la cartera de productos que utilice el cliente.

Guía: Para los bots que pueden manejar redirecciones simples, F5 recomienda limitar las conexiones en función de su métrica de solicitudes por segundo o utilizar lo que se denomina un "muro de inicio de sesión". Un muro de inicio de sesión requiere que se autentique una conexión con la aplicação antes de que pueda consumir recursos no almacenados en caché o dinámicos, como consultas de base de datos.

Materiales relevantes:

Defensa del DNS

Hay dos cuestiones de DNS que vale la pena discutir en relación con el ataque Dyn. Lo primero y más sencillo es qué hacer si su proveedor de DNS queda fuera de línea debido a uno de los nuevos tipos de ataques. Dyn era el proveedor de servicios de nombres para Twitter, GitHub y Spotify, por lo que cuando Dyn fue bloqueado, los usuarios finales no pudieron encontrar direcciones IP para estos servicios.

Guía: Incorpore resiliencia a su plan de DNS que incluya, entre otras cosas, múltiples proveedores de DNS para brindar direcciones para sus aplicações críticas. De esta forma, si uno de los proveedores sucumbe a un ataque temporalmente, el otro proveedor podrá servir sus direcciones. Esto puede ralentizar a sus usuarios finales unos pocos milisegundos, pero sus aplicações y servicios seguirán estando disponibles.

La segunda cuestión es qué hacer si su propio servidor DNS es atacado. DNS es el servicio más objetivo, seguido por HTTP. Cuando se interrumpe el DNS, todos los servicios externos del centro de datos (no solo una aplicação) se ven afectados. Este único punto de falla total, junto con una infraestructura de DNS a menudo insuficientemente abastecida, hace del DNS un objetivo tentador para los atacantes.

Recuerde que incluso si su propio servidor no está bajo ataque, una interrupción aguas abajo del suyo podría provocar que un conjunto diferente de servidores DNS inunden sus servidores DNS con solicitudes mientras intentan llenar sus propios cachés. Dyn reportó entre 10 y 20 veces más solicitudes de lo normal cuando esto les sucedió, y eso fue por parte de servidores DNS legítimos que intentaban lidiar con la situación.

Guía: Un porcentaje significativo de servicios DNS tienen un suministro insuficiente hasta el punto de no poder resistir ni siquiera ataques DDoS de tamaño pequeño a mediano. Los cachés de DNS se han vuelto populares porque pueden mejorar el rendimiento percibido de un servicio de DNS y proporcionar cierta resistencia contra ataques de consultas de DNS estándar. Los atacantes han optado por lo que se denomina ataques “sin dominio” (o NXDOMAIN), que agotan rápidamente los beneficios de rendimiento proporcionados por la memoria caché.

Para los clientes de F5, F5 recomienda integrar los servicios DNS con el módulo proxy DNS llamado F5 DNS Express™. DNS Express actúa como un solucionador absoluto frente a los servidores DNS existentes. Carga la información de la zona de los servidores y resuelve cada solicitud o devuelve NXDOMAIN. No es un caché y no se puede vaciar mediante inundaciones de consultas NXDOMAIN.

Guía: Recuerde que el DNS puede ser su amigo durante un ataque DDoS; Anycast a sus centros de datos globales para contenido replicado para difundir los ataques DDoS cuando ocurran.

Guía: Considere la ubicación de los servicios DNS. A menudo, el servicio DNS existe como su propio conjunto de dispositivos aparte del primer perímetro de seguridad. Esto se hace para mantener el DNS independiente de las aplicações a las que sirve.

Algunas grandes empresas con múltiples centros de datos proporcionan el servicio DNS fuera del perímetro de seguridad principal utilizando una combinación de BIG-IP DNS con DNS Express y el módulo de cortafuegos BIG-IP AFM. La principal ventaja de este enfoque es que los servicios DNS siguen estando disponibles incluso aunque el nivel de defensa de la red se desconecte debido a ataques DDoS.

Materiales relevantes:

CONCLUSIÓN

Los ataques Krebs, OVH y Dyn marcan una nueva fase en DDoS. Al mismo tiempo, marcan la llegada de la edad de oro de la Internet de las cosas.

Como puede ver, F5 tiene mucha experiencia investigando, combatiendo y escribiendo sobre DDoS y queremos trabajar con los clientes para mantener sus aplicações disponibles. Esto requerirá vigilancia de todos nuestros colaboradores: desde F5 hasta nuestros socios y clientes.

Si usted es cliente, o incluso si no lo es, y sufre un ataque, recuerde que F5 Silverline DDoS Protection está a solo una llamada de distancia: 866-329-4253.

En cuanto a la amenaza IoT, los blackhats comparten entre sí todo el tiempo (compartieron Mirai después de que atacara a Krebs y OVH, y se usó en el ataque a Dyn). Nosotros, en la comunidad InfoSec, debemos tomar ejemplo de ellos y unirnos para resolver este problema global de IoT. No tenemos otra opción que hacerlo. Es parte de la naturaleza humana comprender los problemas, solucionarlos y, por lo tanto, evolucionar.

Sin duda habrá contratiempos en los próximos años a medida que los ataques aumentan en tamaño, los servicios de depuración aumentan en ancho de banda para dar cabida a estos grandes ataques y los fabricantes de dispositivos IoT descubren cómo lidiar con las inseguridades de sus dispositivos. Las organizaciones y los consumidores tienen que acostumbrarse a esta amenaza en evolución, como a todos los demás problemas importantes anteriores a éste.