Google a réussi à contenir une attaque DDoS dont les chiffres ont de quoi donner le tournis : un pic à 46 millions de requêtes par seconde, dont 3 % provenant du réseau Tor. 5 256 adresses IP de 132 pays étaient impliquées, vraissembablement via un botnet de la famille Mēris.
Les attaques DDoS sont à la fois un fléau contre lequel il faut lutter pour éviter de paralyser tout ou partie d'une infrastructure, mais ils sont aussi un « formidable » outil de communication pour certains géants du cloud. En effet, lorsqu’ils parviennent à les bloquer c’est aussi l’occasion de s’en vanter et mettre en avant de gros chiffres et d’annoncer de nouveaux records.
L’intensité des attaques DDoS augmente…
En août 2021, CloudFlare revendiquait ainsi avoir bloqué une attaque DDoS avec pas moins de 17,2 millions de requêtes par seconde. Une attaque « presque trois fois plus importante que toutes les précédentes » dont la société avait alors connaissance.
Quelques semaines plus tard, Yandex était à son tour victime d’une cyberattaque avec 21,8 millions de requêtes. Rebelote chez CloudFlare en avril avec 15 millions avant un nouveau record à 26 millions en juin. A chaque fois, des billets de blogs pour expliquer comment l'infrastructure en était venue à bout ou revendiquer « la plus grosse attaque HTTPS DDoS de l’histoire ».
De son côté, Microsoft expliquait récemment que les attaques DDoS s’intensifiaient, à la fois en fréquence et en puissance. La société assurait avoir enregistré une attaque record à 2,4 Tb/s en octobre, puis un nouveau record à 3,47 Tb/s en novembre.
… pour atteindre 46 millions de requêtes par seconde
C’est donc au tour de Google Cloud de sortir du bois, confirmant évidemment les tendances de CloudFlare et Microsoft : « les attaques par déni de service distribué (DDoS) augmentent en fréquence et en volume de manière exponentielle ». L’entreprise revendique désormais la couronne de la plus grosse attaque avec 46 millions de requêtes par seconde, « soit au moins 76 % de plus » que celle de CloudFlare (26 millions).
Google propose une comparaison : « Pour donner une idée de l’ampleur de l’attaque, c’est comme recevoir toutes les demandes quotidiennes de Wikipédia (l’un des 10 sites Web les plus fréquentés au monde) en seulement 10 secondes ».
La société de Mountain View en profite évidemment pour mettre en avant sa solution Armor Adaptative Protection (on vous épargne le discours marketing), mais aussi donner une chronologie de l’attaque. Elle a commencé le 1er juin, à 18h45 heure française, avec 10 000 requêtes par seconde. Huit minutes plus tard, elle est passée à 100 000 requêtes par seconde.
Plus de 5 000 adresses IP de 132 pays, avec des nœuds Tor
Elle prend ensuite de l’ampleur pour atteindre 46 millions de requêtes par seconde quelques minutes plus tard, avant une accalmie et même un arrêt total un peu plus plus tard à 19h54 heure française. Selon Google, « l'attaquant a vraisemblablement déterminé que son attaque n’avait pas l'impact souhaité, alors qu’il engageait des dépenses importantes pour l’exécuter ».
5 256 adresses IP provenant de 132 pays auraient été impliquées dans cette attaque, toujours selon Google. Géographiquement, quatre pays – Brésil, Inde, Russie et Indonésie – ont contribué à hauteur de 31 %. Autre point intéressant : « Environ 22 % (1 169) des adresses IP correspondaient à des nœuds de sortie Tor, mais le volume provenant de ces nœuds ne représentait que 3 % du volume des requêtes ».
L’utilisation de Tor était « secondaire » précise Google, mais 3 % du trafic pendant le pic cela représente tout de même 1,3 million de requêtes par seconde. Pour l’entreprise, cela indique que « les nœuds de sortie de Tor peuvent envoyer une quantité importante de trafic indésirable vers des applications et services web ».
Quoi qu’il en soit, Google Cloud affirme avoir bloqué cette attaque avant qu’elle n’arrive jusqu’à son client, dont le nom n’est pas précisé. On imagine que si cela avait été le cas l’entreprise ne s’en serait pas vantée aussi ouvertement. Il reste que Google s’attend, comme ses camarades, à ce que « la taille des attaques continue de croître et les tactiques d’évoluer ».
Alors que revoilà Mēris
Étant donné la topologie de cette attaque, la société pense que les pirates ont utilisé un botnet de la famille Mēris, sans plus de précision.
Ce dernier était déjà derrière l’attaque de Yandex en septembre dernier. Qrator Labs avait alors consacré un billet de blog à ce botnet. On y apprenait notamment que trois principaux pays d’où venaient les adresses IP étaient le Brésil, l’Indonésie et l’Inde, trois pays qu'on retrouve dans le Top 4 de l’attaque visant Google.
En juin dernier, CloudFlare précisait que son attaque à 26 millions de requêtes par seconde était orchestrée par Mantis, une nouvelle évolution de Mēris. Il y a donc fort à parier que l’on entende de nouveau parler de cette famille de botnets dans les semaines et mois à venir.
Commentaires (20)
#1
Est-ce-que google a diffuser la liste des adresse IP attaquante ? Ou un site pour savoir si son adresse IP a été impliqué ?
#1.1
Pas bête !
#2
Un rapport avec Guillaume Mēris ?
#3
Je trouve fascinant que tout ce trafic ait été obtenu par seulement 5256 hôtes (adresses IP).
Ca fait un peu peur quand on pense au taux d’infection des machines il y a encore quelques années. Avec quelques millions de machines, tout Internet tombe.
#3.1
Ouais c clair. Si jamais des failles sont trouvées et exploitées sur des boxes opérateurs, a raison de millions de boxes, ça va faire de sacrées attaques lol.
Ça me paraît peu en nb de hosts..
#3.2
Pas forcément, on parle ici d’IP, pas de machines. Tu peux avoir une IP et 5 machines derrières NATées… Ça change la donne.
#4
Google Cloud attaqué … on est sûr que ce ne sont pas des DDOS depuis Azure et AWS ? :p
#5
Ca arrive déjà :
https://www.zdnet.com/article/botnets-competing-to-attack-vulnerable-gpon-fiber-routers/
En plus “grâce” au GPON des opérateurs, il n’y a plus que les box qui sont attaquable : les convertisseurs GPON aussi, qui sont de mini-linux en eux-même.
Sauf que contrairement aux box, comme ils sont considérés comme des éléments “unitaire” du réseau les FAI n’ont pas tellement de contrôle dessus, ils achètent l’appareil “tout fait” , hardware + firmware , dans une logique de moindre coûts.
Pas besoin de réfléchir longtemps aux conséquences en terme de sécurité informatique.
#6
L’article parle de routeur, pas d’ONT. Au moins en France, les ONT ne sont pas addressable depuis le réseau publique. Certaine ONT perdent même leur IP volontairement dès lors que le lien gpon est up.
#7
Quelle est le but recherché pour un attaquant de faire ce genre d’attaque DDOS sur Google Cloud ? Beaucoup de temps et d’argent dépensé mais pour quel gain ? Si quelqu’un peut m’éclairer ?
#8
ça ne visait probablement pas Google Cloud en tant que tel, mais un site web hébergé par Google Cloud
#9
Sauf que si ils sont infectés rien ne les empêches de garder leur IP et de récupérer des trames (ex : DHCP-Offer) pour émettre à leur tour du trafic DDOS, bien chiant a détecter (car ne provenant pas de la box, justement…)
J’ai vu des POF de ça :-/
(La seule chose qui sauve c’est que le CPU est anémique, donc en PPS ça monte pas trop haut)
Mais effectivement pas en France je l’admets.
#10
Puisqu’on joue à qui a la plus grosse, on compare comment les attaques à base de “millions de requêtes par seconde” vs celles à base de “Tb/s” ?
#11
Je vois pas comment c’est possible d’infecter un équipement qui n’a pas d’IP… Tout au mieux, lui faire transiter des paquets formatés de tel sorte que le routeur plante, mais de là à lui injecter du code, c’est quand même un peu de la science fiction la…
#11.1
Il est bien possible de réveiller une machine éteinte par le réseau (wake on lan), donc sans IP.
Infecter un équipement sans IP est donc potentiellement possible, bien que loin d’être trivial…
#12
OK, si tu le dit.
#13
Pour réveiller une machine sans IP:
#13.1
Je sais bien tout cela. L’idée s’était de souligner que le dialogue pouvait se faire sans passer par IP. Mais on est d’accord que l’IP reste le moyen le plus répandu (car traverse les différents équipements réseau).
Après, une grosse partie des hacks utilisent des failles dans des fonctionnalités disponibles, et il existe de nombreuses fonctionnalités qui n’utilisent pas IP (le wake on lan déjà cité, ARP, etc…)
#14
ils vont augmenter les tarifs à cause que c’est la guerre en Ukraine.
#15
Je suis bien d’accord, du arp poisining par exemple que je faisais en cité U sur un réseau avec une pauvre ADSL partagé, pour kicker les trous de balle qui faisait du torrent 24⁄7…
Mais pour revenir au sujet d’origine, on parle de botnet, donc il ne s’agit pas pour un attaquant d’entrer par effraction et aller brancher son hack en RJ45 sur 5000 ONT de Mme Michu tout autour du monde…