Comment Google a déjoué la plus grande cyberattaque de l’histoire

Avec un pic à 46 millions de requêtes par seconde, un client de Google Cloud a subi la plus grosse attaque par « déni de service » de l’histoire. C’était le 1^er juin dernier, et Google explique comment elle a été contrée.

 Des dizaines de millions. C’est le nombre de requêtes que reçoit chaque jour Wikipedia, l’un des sites les plus consultés au monde. C’est astronomique mais l’encyclopédie possède les serveurs et la bande passante idoines pour supporter de telles montées en charge. C’est l’exemple donné par Google après avoir contré la plus grosse cyberattaque de l’histoire sur son Cloud.

C’était début juin, et ce n’est qu’aujourd’hui que la firme a décidé de lever le voile sur cette attaque qui a touché un client de Google Cloud. Ce jour-là, Google a bloqué une attaque dite de « déni de service » (DDoS) dont le débit a atteint 46 millions de requêtes HTTPS par seconde !

« Il s’agit de la plus grande attaque DDoS de couche 7 signalée à ce jour, soit au moins 76 % de plus que le précédent record, explique un ingénieur Google. Pour donner une idée de l’ampleur de l’attaque, cela revient à recevoir toutes les requêtes quotidiennes de Wikipédia (l’un des 10 sites Web les plus fréquentés au monde) en seulement 10 secondes. »

Une protection « adaptive »

Le plus impressionnant, peut-être, c’est que Google a donc réussi à déjouer cette attaque. Pour cela, le client visé avait déjà configuré la « Protection adaptative dans sa politique de sécurité Cloud Armor ». Une méthode qui permet d’établir un modèle de référence des modèles de trafic normaux pour son service. Résultat, cette protection, qui agit comme un firewall, a pu détecter l’attaque DDoS au début de son cycle de vie, analyser son trafic entrant et générer une alerte avec une règle de protection recommandée. Le tout avant que l’attaque ne s’intensifie. Tout se joue en quelques secondes.

Pour limiter l’ampleur de l’attaque, l’outil de protection a automatiquement limité le débit, et Google explique que le client a préféré « étrangler » l’attaque plutôt que la « refuser ». Pourquoi ? Cette méthode permet ainsi de réduire l’impact sur le trafic entrant légitime, tout en isolant les requêtes malveillantes. En clair, le serveur du client, dont le nom n’a jamais été mentionné, n’a jamais été « inaccessible » comme c’est généralement le cas face à une attaque de type DDoS.

Des attaques en provenance de 132 pays

Google explique aussi qu’avant de déployer cette « règle », elle a d’abord été déployée en mode de prévisualisation. Le client a ainsi pu vérifier que seul le trafic indésirable serait refusé et que les utilisateurs légitimes pourraient continuer à accéder au service. Lorsque l’attaque a atteint son pic de 46 millions de rps (requêtes par seconde), la règle suggérée par Cloud Armor était déjà en place pour bloquer le gros de l’attaque et garantir que les applications et services ciblés restent disponibles.

Ce qui a sans doute facilité la tâche, c’est que le nombre d’adresses IP à l’origine des attaques n’était finalement pas si élevé. Google en a dénombré moins de 6.000 en provenance de 132 pays, dont quatre représentaient près d’un tiers des attaques. En les bloquant, le client a rapidement pu limiter leur impact.

futura