L’Internet moderne repose sur des couches d’abstraction si nombreuses qu’on finit parfois par oublier la nature profondément fragile de l’édifice. La panne récente qui a frappé Cloudflare en est la démonstration brutale. Un fichier interne, dédié à la gestion des bots, a soudainement doublé de taille et déclenché une réaction en chaîne qui a perturbé une part importante du trafic mondial.Pour les experts de l’infrastructure et de la cybersécurité, cet incident offre une leçon essentielle : dans un écosystème numérique hyper-centralisé, la plus petite erreur de configuration peut devenir l’origine d’un séisme global.
Lorsque Cloudflare a connu la panne qui a perturbé un grand nombre de sites Web et de services en ligne, l'entreprise a d'abord pensé qu'elle était victime d'une attaque DDoS (déni de service distribué) « à très grande échelle ».
« Je crains que ce soit le botnet qui se montre », a écrit Matthew Prince, cofondateur et PDG de Cloudflare, dans un forum de discussion interne, alors que lui et d'autres discutaient pour savoir si Cloudflare était victime d'attaques du prolifique botnet Aisuru.
À ce sujet, Microsoft a expliqué que le botnet a créé « la plus grande attaque DDoS jamais observée dans le cloud » :
« Le 24 octobre 2025, Azure DDOS Protection a automatiquement détecté et atténué une attaque DDoS multivectorielle atteignant 15,72 Tbps et près de 3,64 milliards de paquets par seconde (pps). Il s'agissait de la plus grande attaque DDoS jamais observée dans le cloud, qui visait un seul point de terminaison en Australie.
« Grâce à l'infrastructure de protection DDoS distribuée à l'échelle mondiale d'Azure et à ses capacités de détection continue, des mesures d'atténuation ont été mises en place. Le trafic malveillant a été efficacement filtré et redirigé, ce qui a permis de maintenir la disponibilité ininterrompue des services pour les charges de travail des clients.
« L'attaque provenait du botnet Aisuru. Aisuru est un botnet IoT de type Turbo Mirai qui provoque fréquemment des attaques DDoS record en exploitant des routeurs et des caméras domestiques compromis, principalement chez des FAI résidentiels aux États-Unis et dans d'autres pays.
« L'attaque consistait en des inondations UDP à très haut débit ciblant une adresse IP publique spécifique, lancées à partir de plus de 500 000 adresses IP sources dans différentes régions. Ces rafales UDP soudaines comportaient un minimum d'usurpation d'adresse source et utilisaient des ports source aléatoires, ce qui a simplifié le traçage et facilité l'intervention des fournisseurs.
« Les attaquants évoluent au même rythme que l'internet lui-même. À mesure que les débits de la fibre optique à domicile augmentent et que les appareils IdO deviennent plus puissants, la taille des attaques ne cesse de croître. »
Une corruption interne invisible… jusqu’à l’embrasement
Mais après une enquête plus approfondie, le personnel de Cloudflare s'est rendu compte que le problème avait une cause interne : un fichier important avait doublé de taille de manière inattendue et s'était propagé sur le réseau. Cela a causé des problèmes aux logiciels qui doivent lire le fichier pour maintenir le système de gestion des bots Cloudflare, qui utilise un modèle d'apprentissage automatique pour protéger contre les menaces de sécurité. Le CDN principal de Cloudflare, ses services de sécurité et plusieurs autres services ont été affectés.
« Après avoir initialement soupçonné à tort que les symptômes que nous observions étaient causés par une attaque DDoS à très grande échelle, nous avons correctement identifié le problème principal et avons pu arrêter la propagation du fichier de fonctionnalités plus volumineux que prévu et le remplacer par une version antérieure du fichier », a écrit Prince dans un compte rendu post-mortem de la panne.
Prince a expliqué que le problème « a été déclenché par une modification des autorisations de l'un de nos systèmes de base de données, qui a conduit la base de données à générer plusieurs entrées dans un "fichier de fonctionnalités" utilisé par notre système de gestion des bots. Ce fichier de fonctionnalités a alors doublé de taille. Le fichier de fonctionnalités plus volumineux que prévu s'est ensuite propagé à toutes les machines qui composent notre réseau. »
Ces machines exécutent un logiciel qui achemine le trafic sur le réseau Cloudflare. Le logiciel « lit ce fichier de fonctionnalités afin de maintenir notre système de gestion des bots à jour face à des menaces en constante évolution », a écrit Prince. « Le logiciel avait une limite de taille pour le fichier de fonctionnalités qui était inférieure à sa taille doublée. Cela a provoqué la défaillance du logiciel. »
Des répercussions sur Internet
Après avoir remplacé le fichier de fonctionnalités surchargé par une version antérieure, le flux du trafic principal est « en grande partie » revenu à la normale, a écrit Prince. Mais il a fallu encore deux heures et demie « pour atténuer la charge accrue sur différentes parties de notre réseau alors que le trafic reprenait en ligne ».
Tout comme Amazon Web Services, Cloudflare est utilisé par de nombreux services en ligne et peut paralyser une grande partie du Web lorsqu'il rencontre un problème technique. « Au nom de toute l'équipe de Cloudflare, je tiens à m'excuser pour les désagréments que nous avons causés à Internet aujourd'hui », a écrit Prince, ajoutant que toute interruption de service est inacceptable en raison de « l'importance de Cloudflare dans l'écosystème Internet ».
Le système de gestion des bots de Cloudflare classe les bots comme bons ou mauvais à l'aide « d'un modèle d'apprentissage automatique que nous utilisons pour générer des scores de bots pour chaque requête traversant notre réseau », a écrit Prince. « Nos clients utilisent les scores des bots pour contrôler quels bots sont autorisés à accéder à leurs sites, ou non. »
Prince a expliqué que le fichier de configuration sur lequel repose ce système décrit les « caractéristiques », ou traits individuels « utilisés par le modèle d'apprentissage automatique pour prédire si la requête était automatisée ou non ». Ce fichier est mis à jour toutes les cinq minutes « et publié sur l'ensemble de notre réseau, ce qui nous permet de réagir aux variations du trafic sur Internet. Il nous permet de réagir aux nouveaux types de bots et aux nouvelles attaques de bots. Il est donc essentiel qu'il soit déployé fréquemment et rapidement, car les acteurs malveillants changent rapidement de tactique.
Quand la redondance amplifie la panne
Chaque nouvelle version du fichier est générée par une requête exécutée sur un cluster de bases de données ClickHouse, explique Prince. Lorsque Cloudflare a apporté une modification accordant des autorisations supplémentaires aux utilisateurs de la base de données, la réponse à la requête a soudainement contenu plus de métadonnées qu'auparavant.
Le personnel de Cloudflare a supposé « que la liste des colonnes renvoyées par une requête comme celle-ci ne comprendrait que la base de données "par défaut". Mais la requête ne comprenait pas de filtre pour le nom de la base de données, ce qui a entraîné le renvoi de doublons de colonnes », note Prince.
C'est le type de requête que le système de gestion des bots de Cloudflare utilise « pour construire chaque "fonctionnalité" d'entrée pour le fichier », écrit-il. Les métadonnées supplémentaires ont plus que doublé le nombre de lignes dans la réponse, « affectant finalement le nombre de lignes (c'est-à-dire les fonctionnalités) dans le fichier final », écrit Prince.
Le service proxy de Cloudflare a des limites pour éviter une consommation excessive de mémoire, le système de gestion des bots ayant « une limite sur le nombre de fonctionnalités d'apprentissage automatique pouvant être utilisées au moment de l'exécution ». Cette limite est de 200, bien au-dessus du nombre réel de fonctionnalités utilisées.
« Lorsque le fichier corrompu contenant plus de 200 fonctionnalités a été propagé à nos serveurs, cette limite a été atteinte, ce qui a provoqué une panique du système » et généré des erreurs, écrit Prince.
La pire panne de Cloudflare depuis 2019
Le nombre de codes d'état HTTP 5xx renvoyés par le réseau Cloudflare est normalement « très faible », mais il a grimpé en flèche après la propagation du fichier corrompu sur le réseau. « Le pic, et les fluctuations qui ont suivi, montrent que notre système a échoué en raison du chargement d'un fichier de fonctionnalités incorrect », a écrit Prince. « Il est à noter que notre système s'est ensuite rétabli pendant un certain temps. Il s'agissait d'un comportement très inhabituel pour une erreur interne. »
Ce comportement inhabituel s'explique par le fait « que le fichier était généré toutes les cinq minutes...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
