Entendiendo el último mes de ataques DDoS

F5

En este artículo, analizaremos brevemente el impacto de los ataques #DDoS sin precedentes de septiembre y octubre de 2016 y ofreceremos orientación a quienes deseen mejorar su resiliencia.

¡Celebremos la llegada del Internet de las cosas! Sabemos que por fin está aquí porque, desde septiembre, se ha utilizado tres veces como arma cibernética. Todo comenzó con un ataque masivo contra el periodista y bloguero Brian Krebs, cuyo sitio web krebsonsecurity.com estaba alojado y protegido por la CDN de Akamai. El ataque fue tan grave que llegó a afectar a otros clientes de Akamai, por lo que la empresa dejó de prestar al bloguero sus servicios de protección gratuitos.

Los investigadores del sector (incluidos los de F5) fueron alertados de una nueva botnet compuesta por grabadores de vídeo digital (DVR), cámaras de vídeo y otras «cosas». Los DVR y las cámaras de vídeo son especialmente relevantes porque cuentan tanto con una gran capacidad de procesamiento (por lo que pueden alojar malware sofisticado) como con conexiones de subida de gran ancho de banda (desde las que lanzaron ataques de hasta 100 Mb/s cada una). El tráfico total del ataque dirigido contra Krebs alcanzó los 620 Gb/s, lo que en aquel momento lo convirtió en el mayor ataque DDoS del mundo.

El segundo ataque dejó fuera de servicio durante gran parte del día a OVH, el mayor proveedor de alojamiento web de Francia (y el tercero del mundo, si damos crédito a las publicaciones). Muchos medios informaron de que el ataque contra OVH fue casi el doble de grande que el ataque contra Krebs: un terabit por segundo completo.

El tercer ataque, y posiblemente el peor, tuvo como objetivo a Dyn, la empresa de servicios DNS. Dyn es el proveedor de DNS de muchos sitios web de renombre, como Twitter, Spotify y GitHub (donde, irónicamente, se publicó el código de la red de bots del IoT).

Entonces, ¿quién lo hizo?

Por una extraña coincidencia, el mes anterior, Bruce Schneier, una figura destacada del sector, había estado concediendo entrevistas en las que advertía de la inminencia de ataques DDoS masivos perpetrados por Estados. Su información privilegiada procedía de fuentes anónimas del sector que habían detectado ataques DDoS de calibración contra la infraestructura central de Internet.

Pero, por lo que parece, puede que esos ataques de sondeo fueran una mera coincidencia. El propio Schneier admitió en su blog que no cree que el ataque contra Dyn fuera obra de un Estado. Pero quizá ese Estado se limite a observar y esperar.

La clave para determinar la autoría de los casos de Krebs, OVH y Dyn probablemente la tenga el propio Brian Krebs.

«El ataque contra DYN se produjo apenas unas horas después de que el investigador de DYN Doug Madory diera una charla sobre ataques DDoS en Dallas, Texas, durante una reunión del Grupo Norteamericano de Operadores de Redes (NANOG). …el ataque DDoS récord de 620 Gbps contra KrebsOnSecurity.com se produjo apenas unas horas después de que publicara el artículo en el que Madory y yo colaboramos»

Es muy probable que el adversario sea una persona (o un grupo pequeño) con algún tipo de animadversión contra Brian Krebs, Doug Madory o ambos.

Todos podríamos entender que millones de usuarios se vieran afectados por una ciberguerra a gran escala entre China y Estados Unidos. Pero ¿y si resulta que todo responde a una vendetta personal de un solo individuo contra otro? Eso da aún más miedo que un ataque de un Estado. ¿Qué clase de Internet hemos construido para que una sola persona, movida por el rencor hacia otra, pueda interrumpir servicios esenciales para millones de personas?

¿Cómo hemos llegado hasta aquí?

F5 lleva más de un año haciendo un seguimiento de la búsqueda de dispositivos del Internet de las cosas (IoT). Nuestro primer informe sobre este asunto se publicó en julio de 2016 y mostró un aumento interanual del 140 % en los escaneos de fuerza bruta de Telnet y SSH. Telnet y SSH son puertos de administración remota muy utilizados y, a menudo, quedan expuestos a Internet sin que se sepa, con el nombre de usuario y las 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 precisamente esta técnica (el escaneo de puertos telnet y contraseñas predeterminadas por los proveedores en dispositivos IoT) para crear una botnet con capacidades únicas.

Todo el mundo vuelve a ser un objetivo. Los responsables de las redes de bots no temen dirigir su arma cibernética contra algunos de los mayores proveedores del mundo, objetivos que antes se consideraban intocables.

Aunque pueda parecer que estos ataques se produjeron de la noche a la mañana, en realidad, el responsable de la red de bots lleva al menos un año buscando, localizando y poniendo en riesgo dispositivos IoT vulnerables.

Análisis en profundidad de lo que sabemos

En realidad, conocemos bastante bien las capacidades de Mirai, la red de bots del IoT. Los investigadores de F5 publicaron un análisis técnico detallado del bot Mirai poco después de que su autor publicara el código fuente en hackforums.net.

La potencia de ataque conjunta probablemente sea un orden de magnitud superior a la de las botnets anteriores: más de un terabit por segundo.

La botnet de IoT incluye, entre otras, las siguientes técnicas avanzadas de DDoS. La sección de directrices prácticas que figura a continuación ofrecerá recomendaciones sobre cómo mitigarlas cuando sea posible.

Inundaciones de solicitudes HTTP GET resistentes a la redirección

Las inundaciones de solicitudes HTTP GET ya eran perniciosas. Durante años, los atacantes han podido inutilizar sitios web enviando una avalancha de solicitudes HTTP de objetos de gran tamaño o consultas lentas a bases de datos. Por lo general, estas solicitudes atraviesan sin problemas un cortafuegos estándar porque, para la mayoría de los dispositivos con procesamiento de paquetes por hardware, parecen solicitudes HTTP normales. El código de ataque de Mirai va un paso más allá: identifica los sistemas de mitigación de DDoS basados en la nube y sortea cualquier redirección 302 que estos le devuelvan. Las redirecciones solían ser una buena forma de frustrar a los bots sencillos, pero este no es sencillo.

Tortura de agua DNS

El bot Mirai incluye un ataque de «tortura de agua» contra un proveedor de DNS objetivo. Esta técnica difiere de los ataques habituales de reflexión y amplificación de DNS porque el bot necesita enviar muchas menos consultas, lo que permite que el servidor DNS recursivo del ISP lleve a cabo el ataque contra el servidor DNS autoritativo objetivo. En este ataque, el bot envía una consulta DNS correctamente formada que contiene el nombre de dominio objetivo que se desea resolver y le añade un prefijo generado aleatoriamente. El ataque se vuelve efectivo cuando el servidor DNS objetivo se sobrecarga y deja de responder. A continuación, los servidores DNS del ISP retransmiten automáticamente la consulta para probar con otro servidor DNS autoritativo de la organización objetivo, atacando así esos servidores en nombre del bot.

Dyn confirmó en su publicación del blog, Resumen del análisis de Dyn sobre el ataque del viernes 21 de octubre, que efectivamente se utilizó contra ellos el ataque de «tortura de agua».

«Por ejemplo, el impacto del ataque generó una avalancha de reintentos legítimos mientras los servidores recursivos intentaban actualizar sus cachés, lo que generó un volumen de tráfico entre 10 y 20 veces superior al habitual desde un gran número de direcciones IP. Cuando se produce una congestión del tráfico DNS, los reintentos legítimos pueden aumentar aún más el volumen de tráfico.

Parece que los ataques maliciosos procedían de al menos una botnet, y que la avalancha de reintentos dio una falsa impresión de que el conjunto de puntos finales era significativamente mayor de lo que ahora sabemos que fue. Seguimos analizando los datos, pero, en el momento de redactar este informe, se estima que hubo hasta 100.000 puntos finales maliciosos.”

El investigador de F5 Liron Segal había explicado en detalle el funcionamiento del ataque Water Torture del bot en un artículo publicado semanas antes: «Mirai, el bot que tumbó a Krebs».

Ataques de capa 4 actualizados

Según el creador del bot, el denominado ataque «TCP STOMP» es una variante de la inundación ACK simple diseñada para eludir los dispositivos de mitigación. Al analizar la implementación real de este ataque, parece que el bot establece una conexión TCP completa y, a continuación, continúa inundándola con paquetes ACK que contienen números de secuencia legítimos para mantener activa la conexión.

Dado nuestro conocimiento de los distintos vectores de amenaza del nuevo bot de IoT, podemos ofrecer algunas recomendaciones para mitigarlos.

Dejemos algo claro antes de empezar con las recomendaciones. Los ataques contra Krebs, OVH y Dyn constituyen una categoría aparte. Evidentemente, las técnicas existentes de mitigación de DDoS no lograron repeler fácilmente a los atacantes, de ahí las interrupciones del servicio y los titulares en los medios. Sin embargo, en muchos casos, las medidas de mitigación finalmente sí surtieron efecto. Una arquitectura adecuada, como el uso de Anycast y de centros de datos distribuidos, también ayudó. Cabe señalar que la costa oeste y las regiones occidentales de EE. UU. apenas se vieron afectadas por el ataque contra Dyn.

Directrices prescriptivas

Nuestras recomendaciones proceden de nuestros propios clientes. F5 lleva veinte años ofreciendo aplicaciones para las marcas más prestigiosas del mundo, y muchos de esos clientes sufren ataques DDoS a diario. Nuestros clientes con más experiencia dividen sus defensas en tres o cuatro zonas:

• Mitigación de ataques en la nube
• Defensa de la red
• Defensa de aplicaciones
• DNS, cuando corresponda

Por tanto, una arquitectura con una resistencia excepcional a los ataques DDoS presenta este aspecto:

Esta es la arquitectura de referencia para la protección contra DDoS, que los clientes de F5 llevan años utilizando ampliamente. La arquitectura de referencia completa y las prácticas recomendadas pueden consultarse en F5.com. No obstante, para facilitar una consulta más rápida, a continuación se detallan las directrices pertinentes para estos ataques.

Defensa volumétrica

La empresa francesa de alojamiento OVH sufrió un ataque volumétrico de 990 Gbps. Según algunos informes, el ataque contra Dyn alcanzó un pico de 1,2 terabits. Por lo general, los ataques de esta magnitud solo pueden mitigarse mediante servicios de limpieza de tráfico en la nube especializados en la defensa a gran escala. Estos servicios, entre los que se incluye Silverline DDoS Protection de F5, interceptan el tráfico del ataque, lo depuran y envían únicamente el tráfico legítimo al objetivo a través de túneles configurados previamente.

Recomendación: Las organizaciones deben asegurarse de tener acuerdos con uno o varios servicios de mitigación en la nube antes de sufrir un ataque. Configurar los túneles previamente acordados no es algo que pueda hacerse fácilmente en pleno ataque volumétrico. Contrate un servicio de protección contra DDoS con mitigación en la nube como parte de su estrategia contra ataques DDoS.

Orientación: La dispersión de ataques puede ser una gran aliada frente a los ataques volumétricos. Recuerde que el DNS también puede ser su aliado; utilice Anycast en sus centros de datos globales para el contenido replicado a fin de dispersar los ataques DDoS cuando se produzcan. Cada centro de datos que participe mediante Anycast puede ayudar a distribuir el ataque.

Materiales relevantes:

• F5 Silverline DDoS – Métodos de implementación
• El manual de estrategias de F5 contra los ataques DDoS: diez pasos para combatirlos en tiempo real
• Prácticas recomendadas de protección contra DDoS de F5
• Arquitectura de referencia de protección DDoS de F5

Defensa de la red

El bot Mirai incluye en su arsenal varios ataques de capa 4: inundaciones SYN estándar, inundaciones TCP e inundaciones UDP. Estos antiguos vectores de amenaza deben mitigarse mediante un servicio de limpieza de tráfico en la nube o, si son lo suficientemente pequeños, en la capa de defensa de red del centro de datos. La capa de defensa de red se articula en torno al cortafuegos de red. Está diseñada para mitigar ataques computacionales, como las inundaciones SYN y las inundaciones por fragmentación ICMP. Esta capa también mitiga los ataques volumétricos hasta alcanzar la saturación del punto de entrada (normalmente, entre el 80 % y el 90 % de la capacidad nominal del enlace).

Recomendación: Muchos cortafuegos no son resistentes a los ataques DDoS si no están configurados correctamente. Consulte al proveedor de su cortafuegos de red para conocer los ajustes adecuados. Algunos clientes colocan dispositivos anti-DDoS delante de sus cortafuegos para repeler los ataques de capa 4.

Orientación: El módulo de firewall de F5 (BIG-IP Advanced Firewall Manager (AFM)) se diseñó específicamente para repeler ataques de capa 4. Algunos arquitectos utilizan BIG-IP AFM precisamente para este fin, ya sea delante de los firewalls de red convencionales o en sustitución de estos. 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 este trabajo de la CPU.

Materiales relevantes:

• Mitigación de DDoS con BIG-IP AFM
• Ficha técnica de F5 BIG-IP Advanced Firewall Manager
• Las diez funciones avanzadas de seguridad de F5 más destacadas en BIG-IP 12.1
• Prácticas recomendadas para la protección contra DDoS de F5

Defensa de aplicaciones

El bot Mirai puede generar impresionantes inundaciones de solicitudes HTTP GET y gestionar redirecciones. Dado que estas inundaciones parecen tráfico normal para los dispositivos de defensa de red, deben gestionarse en la capa de aplicación. Son, con diferencia, el tipo de ataque más habitual en la capa de aplicación que detecta F5, y existen muchas formas de mitigarlas, en función de la cartera de productos que utilice el cliente.

Recomendación: Para los bots capaces de gestionar 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». Este muro exige que la conexión se autentique en la aplicación antes de poder consumir recursos dinámicos o no almacenados en caché, como las consultas a bases de datos.

Materiales relevantes:

• Prácticas recomendadas de protección contra DDoS de F5
• Protección de la página de inicio de sesión con ASM
• DevCentral: muro de inicio de sesión sencillo con iRule

Defensa de DNS

Hay dos cuestiones relacionadas con el DNS que merece la pena comentar a propósito del ataque a Dyn. La primera, y la más evidente, es qué hacer si uno de estos nuevos tipos de ataque deja fuera de servicio a tu proveedor de DNS. Dyn era el proveedor de servicios de nombres de Twitter, GitHub y Spotify, por lo que, cuando Dyn quedó bloqueado, los usuarios finales no pudieron encontrar las direcciones IP de estos servicios.

Recomendación: incorpore resiliencia a su estrategia de DNS incluyendo, entre otras medidas, varios proveedores de DNS que proporcionen las direcciones de sus aplicaciones críticas. De este modo, si uno de los proveedores queda temporalmente fuera de servicio debido a un ataque, el otro podrá proporcionar sus direcciones. Esto puede aumentar en unos milisegundos el tiempo de respuesta para los usuarios finales, pero sus aplicaciones y servicios seguirán estando disponibles.

La segunda cuestión es qué hacer si su propio servidor DNS sufre un ataque. DNS es el servicio más atacado, seguido de HTTP. Cuando se interrumpe el servicio DNS, todos los servicios externos del centro de datos (no solo una aplicación) se ven afectados. Este único punto de fallo total, junto con una infraestructura DNS que a menudo cuenta con recursos insuficientes, convierte a DNS en un objetivo tentador para los atacantes.

Recuerde que, aunque su propio servidor no esté siendo atacado, una interrupción en un punto posterior de la red podría provocar que otro conjunto de servidores DNS inundara sus servidores DNS con solicitudes al intentar llenar sus propias cachés. Dyn informó de un volumen de solicitudes entre 10 y 20 veces superior al habitual cuando esto les ocurrió, y procedían de servidores DNS legítimos que intentaban hacer frente a la situación.

Orientación: Un porcentaje significativo de los servicios DNS dispone de recursos insuficientes, hasta el punto de no poder resistir ni siquiera ataques DDoS de tamaño pequeño o mediano. Las cachés DNS se han popularizado porque pueden mejorar el rendimiento percibido de un servicio DNS y ofrecer cierta resistencia frente a los ataques de consultas DNS convencionales. Los atacantes han pasado a utilizar los denominados ataques de «dominio inexistente» (o NXDOMAIN), que agotan rápidamente las ventajas de rendimiento que ofrece la caché.

Para los clientes de F5, F5 recomienda anteponer a los servicios DNS el módulo proxy DNS denominado F5 DNS Express™. DNS Express actúa como un solucionador autoritativo delante de los servidores DNS existentes. Carga la información de zona de los servidores y resuelve todas las solicitudes o devuelve NXDOMAIN. No es una caché y no puede vaciarse mediante avalanchas de consultas NXDOMAIN.

Recomendación: Recuerde que el DNS puede ser su aliado durante un ataque DDoS; utilice Anycast en sus centros de datos globales para el contenido replicado, a fin de dispersar los ataques DDoS cuando se produzcan.

Orientación: Tenga en cuenta la ubicación de los servicios DNS. A menudo, el servicio DNS se aloja en un conjunto de dispositivos independiente, fuera del primer perímetro de seguridad. Esto se hace para mantener el DNS independiente de las aplicaciones a las que presta servicio.

Algunas grandes empresas con varios centros de datos prestan servicios DNS fuera del perímetro de seguridad principal mediante 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 si la capa de defensa de la red queda fuera de servicio debido a un ataque DDoS.

Materiales relevantes:

• Viernes de F5: ¿Sin DNS? Sin… nada
• Ficha técnica de F5 DNS
• DevCentral: DNS Express y transferencias de zona
• DevCentral: DNS Express - Parte 1
• La infraestructura de DNS dinámico
• Prácticas recomendadas de F5 para la protección contra DDoS
• Arquitectura de referencia de F5 para la protección contra DDoS

Conclusión

Los ataques contra Krebs, OVH y Dyn marcan una nueva fase en los ataques DDoS. Al mismo tiempo, señalan la madurez del Internet de las cosas.

Como puede ver, F5 cuenta con una amplia experiencia en la investigación y la lucha contra los ataques DDoS, así como en la publicación de contenidos sobre ellos, y queremos colaborar con los clientes para mantener sus aplicaciones disponibles. Esto exigirá que todos nos mantengamos alerta: desde F5 hasta los socios y los clientes.

Si 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 del IoT, los hackers de sombrero negro comparten información constantemente (compartieron Mirai después de que atacara a Krebs y OVH, y se utilizó en el ataque a Dyn). Quienes formamos parte de la comunidad de la seguridad de la información debemos seguir su ejemplo y unirnos para resolver este problema global del IoT. No nos queda más remedio. Es propio de la naturaleza humana comprender los problemas, solucionarlos y, de ese modo, evolucionar.

Sin duda, habrá contratiempos durante los próximos años a medida que aumente la magnitud de los ataques, los servicios de mitigación amplíen su ancho de banda para hacer frente a estos ataques de gran envergadura y los fabricantes de dispositivos IoT descubran cómo abordar las vulnerabilidades de sus dispositivos. Las organizaciones y los consumidores tendrán que acostumbrarse a esta amenaza en constante evolución, como ya hicieron con todos los grandes problemas anteriores.

Sobre el autor

F5

Más artículos de F5