Google Cloud bloque la plus grande attaque DDoS et bat facilement le précédent record de Cloudflare

En juin, Cloudflare a signalé qu’il avait stoppé la plus grande attaque par déni de service distribué (DDoS) sur HTTPS, qui était estimée à 26 millions de requêtes par seconde (rps). C’est plus que son précédent record de 15,3 millions de rps en avril. Avance rapide jusqu’en août et Google a annoncé qu’il porte désormais la couronne pour avoir bloqué la plus grande attaque DDoS de l’histoire.

Dans un article de blog Google Cloud, la société affirme avoir été en mesure de bloquer une attaque DDoS qui a atteint 46 millions de requêtes par seconde, soit 76 % de plus que Cloudflare. Pour vous donner un contexte sur l’ampleur de cette attaque, imaginez toutes les requêtes envoyées quotidiennement à Wikipédia dans le monde, imaginez maintenant qu’elles sont envoyées en 10 secondes, plutôt que réparties tout au long de la journée.

Une attaque DDoS a été organisée sur un client Google Cloud à l’aide de Cloud Armor. Google indique que dès que le service a détecté des signes de menace, il a alerté le client et recommandé une règle de protection pour prévenir le danger. Cette règle a ensuite été déployée avant que les demandes ne culminent, ce qui signifie que le client a continué à rester en ligne pendant que Cloud Armor protégeait son infrastructure et ses charges de travail.

Google rapporte que l’attaque a commencé tôt le matin du 1er juin à un rythme de 10 000 requêtes par seconde, mais en huit minutes, elle est passée à 100 000 requêtes par seconde, après quoi la protection adaptative de Cloud Armor a fonctionné. Deux minutes plus tard, les requêtes par seconde sont passées à 46 millions, mais le client était désormais en sécurité et en état de marche. L’attaque s’est arrêtée en 69 minutes, probablement parce qu’elle n’a pas eu l’effet escompté en raison de l’interférence de Google Cloud Armor.

Dans son analyse de l’attaque globale, Google a noté que :

En plus du volume de trafic étonnamment important, l’attaque avait d’autres caractéristiques remarquables. L’attaque a impliqué 5256 adresses IP sources de 132 pays. Comme vous pouvez le voir dans la figure 2 ci-dessus, les 4 premiers pays représentent environ 31 % de l’ensemble du trafic d’attaque. L’attaque a utilisé des requêtes chiffrées (HTTPS), dont la génération nécessiterait des ressources informatiques supplémentaires. Alors que l’arrêt du chiffrement était nécessaire pour inspecter le trafic et atténuer efficacement l’attaque, l’utilisation du pipelining HTTP obligeait Google à effectuer un nombre relativement faible de poignées de main TLS.

Environ 22% (1169) des adresses IP source correspondaient à des nœuds de sortie Tor, bien que le volume de requêtes provenant de ces nœuds ne représentait que 3% du trafic d’attaque. Bien que nous pensions que l’implication de Tor dans l’attaque était accidentelle en raison de la nature des services vulnérables, même à un pic de 3 % (plus de 1,3 million de requêtes par seconde), notre analyse montre que les nœuds de sortie de Tor peuvent envoyer une quantité importante de trafic indésirable à le web – applications et services.

La répartition géographique et les types de services non sécurisés utilisés pour mener à bien l’attaque sont cohérents avec la famille d’attaques Mēris. Célèbre pour ses attaques massives qui ont battu des records DDoS, la méthode de Meris utilise des serveurs proxy non sécurisés pour masquer la véritable origine des attaques.

Google a averti que les attaquants utilisent souvent DDoS pour compromettre les charges de travail critiques. L’entreprise a donc recommandé une stratégie de protection détaillée et évidemment l’utilisation de Google Cloud Armor.