Google propose également le service Cloud Armor dans ses services cloud. Ceci est destiné à protéger les clients contre les attaques DDoS. En juin, le réseau a repoussé la plus grande attaque DDoS jamais réalisée (couche 7) avec 46 millions de requêtes par seconde.
Ces dernières années, Google a observé que les attaques par déni de service distribué (DDoS) augmentaient de façon exponentielle en fréquence et en taille. Les charges de travail d'aujourd'hui faisant face à Internet sont exposées à un risque constant d'attaque. L'impact dégrade les performances des utilisateurs légitimes. De plus, les coûts d'exploitation et d'hébergement augmentent jusqu'à l'indisponibilité totale des charges de travail critiques pour l'entreprise.
46 millions de visites PAR seconde !
🔎 DDoS record : 46 millions de requêtes par seconde
Le 1er juin, un client de Google Cloud Armor est devenu la cible d'une série d'attaques HTTPS DDoS, culminant à 46 millions de requêtes par seconde. Il s'agit du plus grand DDoS de couche 7 signalé à ce jour - au moins 76 % plus grand que le record précédemment signalé. Pour donner une idée de l'ampleur de l'attaque, cela équivaut à peu près à envoyer toutes les requêtes quotidiennes à Wikipédia en seulement 10 secondes.
Cloud Armor Adaptive Protection a pu détecter et analyser le trafic au début du cycle de vie de l'attaque. Cloud Armor a alerté le client avec une règle de protection recommandée, qui a ensuite été déployée avant que l'attaque n'atteigne sa pleine ampleur. Cloud Armor a bloqué l'attaque et s'est assuré que le service du client restait en ligne et continuait à servir ses utilisateurs finaux.
Botnet avec des appareils de 132 pays
En plus du volume de trafic étonnamment élevé, l'attaque avait d'autres caractéristiques notables. 5.256 132 adresses IP sources de 4 pays ont contribué à l'attaque. Ces 31 pays, l'Indonésie, le Brésil, l'Inde et la Russie ont contribué à eux seuls à environ XNUMX % du trafic total des attaques. L'attaque a utilisé des requêtes cryptées (HTTPS), dont la génération aurait nécessité des ressources informatiques supplémentaires. Bien que l'arrêt du chiffrement ait été nécessaire pour inspecter le trafic et atténuer efficacement l'attaque, l'utilisation par Google du pipelining HTTP a nécessité relativement peu de poignées de main TLS.
Environ 22 % (1.169 3) des IP sources correspondaient à des nœuds de sortie Tor, même si le volume de requêtes 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 aléatoire en raison de la nature des services vulnérables, notre analyse montre que même à 1,3 % du pic (plus de XNUMX million d'U/s), les nœuds de sortie de Tor ont connu une importante croissance des applications et des services Web. peut envoyer beaucoup de trafic indésirable à Tor.
Plus sur Google.com