Google ha bloqueado el mayor ataque DDoS de la historia

Así lo ha señalado en un post en el blog de Google Cloud, en el que Emil Kilner, Responsable de producto de Cloud Armor, y Satya Kondory, Responsable técnico de Cloud, especifican que se trata del mayor ataque DDoS de capa 7 hasta el momento.

El ataque tuvo su pico en 46 millones de peticiones por segundo, lo que lo hace un 76% más potente que el ataque de este tipo que tenía el record hasta ahora. Para que nos hagamos una idea, los expertos de Google Cloud que firman el post señalan que «es comparable a recibir todas las peticiones que recibe en un día la Wikipedia, una de las webs con más tráfico del mundo, en solo 10 segundos«.

Este ataque alcanzó su pico en unos 10 minutos y empezó a disminuir progresivamente hasta detenerse. El ataque DDoS completo duró más de una hora: 69 minutos en total. Los investigadores de Google Cloud especulan con que los atacantes pararon cuando vieron que sus esfuerzos no estaban dando los resultados que esperaban,

En cuanto al aspecto técnico del ataque, parece que la red de bots utilizada en el ataque era bastante potente. Para el ataque se utilizaron 5.256 IPs fuente, de un total de 132 países. El tipo de ataque efectuado empleaba peticiones cifradas, de tipo HTTPS, lo que significa que necesitó recursos de computación adicionales, por lo que probablemente se trató de una operación bastante cara de realizar.

De las IPs utilizadas como fuente, casi la cuarta parte, un 22%, correspondían a nodos finales de salida de Tor: 1.169 en total. Eso sí, su volumen de peticiones fue solo el 3% del total de tráfico de ataque. Los expertos apuntan que aunque creen que «la participación de Tor en el ataque fue casual, dada la naturaleza de los servicios vulnerables, incluso con un 3% del pico, lo que implicó a más de 1,3 millones de peticiones por segundo, nuestro análisis muestra que los nodos de salida de Tor pueden enviar un número significativo de tráfico no deseado a servicios y aplicaciones web«. En cuanto a los países que participaron en el ataque, los cuatro que más lo hicieron fueron Brasil, India, Rusia e indonesia. En total generaron el 31% del tráfico que intervino en el ataque.

Los expertos no han podido concretar quién es el atacante, o el grupo de atacantes, que hay detrás del ataque. Pero según sus impresiones, para realizarlo se ha empleado un ataque de la familia M?ris. Lo creen sobre todo por la distribución geográfica de las IPs, así como por los tipos de servicios no seguros que aprovecharon en el ataque.

Todo, en suma, es idéntico a los patrones de ataque que utiliza dicha familia, que es responsable de ataques de enorme envergadura que han roto habitualmente los records de los de tipo DDoS. Los ataques M?ris utilizan proxies sin securizar para ofuscar el origen real de los ataques.

El ataque se detuvo en el edge de la red de Google, bloqueando las peticiones maliciosas que llegaban desde la aplicación del cliente. Antes de que empezase el ataque, el cliente ya había configurado Protección adaptatitva en su política de seguridad Cloud Armor, de manera que el sistema de protección podía aprender y establecer un modelo base de los patrones de tráfico normal para su servicio.

Debido a esto, el sistema de Protección adaptativa fue capaz de detectar el ataque DDoS al principio de su ciclo de vida, analizar su tráfico entrante y generar un aviso con una regla de protección recomendada. Todo antes de que e ataque se intensificase. El cliente actuó sobre la alerta desplegando lo recomendado, que aprovechaba su recientemente lanzada función de limitación de tasa para acabar mediante «estrangulación» con el tráfico de ataque. Eligió esta opción, en vez de la de denegación, para reducir la posibilidad de impactar en el tráfico legítimo limitando la capacidad de ataque desactivando la mayoría del volumen de ataque en el edge de la red de Google.

Antes de desplegar la regla en modo de refuerzo, se desplegó en modo de vista previa. De esta manera, el cliente pudo validar que solo el tráfico no deseado quedase bloqueado, mientras que los usuarios legítimos podían seguir accediendo al servidor. A medida que el ataque subía hasta su pico, la norma sugerida por cloud Armor ya estaba en vigor, y se dedicó a bloquear el grueso del ataque y a asegurar que las aplicaciones y servicios objetivo del mismo seguían disponibles.