Comment un seul fichier informatique a accidentellement mis hors service 20 % d'internet hier – en termes simples
L’incident d’hier a montré à quel point le web moderne dépend d’une poignée de fournisseurs d’infrastructures essentiels.
En réalité, cette dépendance est telle qu’une simple erreur de configuration a rendu de vastes parties d’internet totalement inaccessibles pendant plusieurs heures.
Beaucoup d’entre nous travaillent dans la crypto parce que nous comprenons les dangers de la centralisation dans la finance, mais les événements d’hier rappellent clairement que la centralisation au cœur d’internet est un problème tout aussi urgent à résoudre.
Les géants évidents comme Amazon, Google et Microsoft exploitent d’énormes pans de l’infrastructure cloud.
Mais des entreprises comme Cloudflare, Fastly, Akamai, DigitalOcean, ainsi que les fournisseurs de CDN (serveurs qui accélèrent la livraison des sites web dans le monde entier) ou de DNS (le « carnet d’adresses » d’internet) tels qu’UltraDNS et Dyn, sont tout aussi critiques.
La plupart des gens connaissent à peine leurs noms, pourtant leurs pannes peuvent être tout aussi paralysantes, comme nous l’avons vu hier.
Pour commencer, voici une liste d’entreprises dont vous n’avez peut-être jamais entendu parler mais qui sont essentielles au bon fonctionnement d’internet.
| Infra centrale (DNS/CDN/DDoS) | Cloudflare | CDN, DNS, protection DDoS, Zero Trust, Workers | D’immenses portions du trafic web mondial échouent ; des milliers de sites deviennent inaccessibles. |
| Infra centrale (CDN) | Akamai | CDN d’entreprise pour banques, connexions, commerce | Les services majeurs d’entreprise, banques et systèmes de connexion sont perturbés. |
| Infra centrale (CDN) | Fastly | CDN, edge computing | Potentiel de panne mondiale (comme en 2021 : Reddit, Shopify, gov.uk, NYT). |
| Fournisseur cloud | AWS | Calcul, hébergement, stockage, APIs | Les applications SaaS, plateformes de streaming, fintech et réseaux IoT échouent. |
| Fournisseur cloud | Google Cloud | YouTube, Gmail, backends d’entreprise | Disruption massive sur les services Google et les applications dépendantes. |
| Fournisseur cloud | Microsoft Azure | Clouds d’entreprise & gouvernementaux | Pannes d’Office365, Teams, Outlook et Xbox Live. |
| Infrastructure DNS | Verisign | TLD .com & .net, DNS racine | Défaillances catastrophiques du routage mondial pour une grande partie du web. |
| Fournisseurs DNS | GoDaddy / Cloudflare / Squarespace | Gestion DNS pour des millions de domaines | Des entreprises entières disparaissent d’internet. |
| Autorité de certification | Let’s Encrypt | Certificats TLS pour la majorité du web | HTTPS tombe en panne à l’échelle mondiale ; les utilisateurs voient des erreurs de sécurité partout. |
| Autorité de certification | DigiCert / GlobalSign | SSL d’entreprise | Les grands sites d’entreprise perdent la confiance HTTPS. |
| Sécurité / CDN | Imperva | DDoS, WAF, CDN | Les sites protégés deviennent inaccessibles ou vulnérables. |
| Load Balancers | F5 Networks | Répartition de charge d’entreprise | Les services bancaires, hospitaliers et gouvernementaux peuvent échouer à l’échelle nationale. |
| Backbone Tier-1 | Lumen (Level 3) | Backbone internet mondial | Des problèmes de routage provoquent des pics de latence mondiaux et des pannes régionales. |
| Backbone Tier-1 | Cogent / Zayo / Telia | Transit et peering | Perturbations internet régionales ou nationales. |
| Distribution d’applications | Apple App Store | Mises à jour & installations d’apps iOS | L’écosystème d’apps iOS se fige effectivement. |
| Distribution d’applications | Google Play Store | Distribution d’apps Android | Les apps Android ne peuvent pas s’installer ou se mettre à jour dans le monde entier. |
| Paiements | Stripe | Infrastructure de paiement web | Des milliers d’apps perdent la capacité d’accepter des paiements. |
| Identité / Connexion | Auth0 / Okta | Authentification & SSO | Les connexions échouent pour des milliers d’apps. |
| Communications | Twilio | 2FA SMS, OTP, messagerie | Une grande partie des codes 2FA et OTP mondiaux échouent. |
Ce qui s’est passé hier
Le responsable d’hier était Cloudflare, une entreprise qui achemine près de 20 % de tout le trafic web.
Elle indique désormais que la panne a commencé par un petit changement de configuration de base de données qui a accidentellement provoqué l’inclusion d’éléments dupliqués dans un fichier de détection de bots.
Ce fichier a soudainement dépassé une limite de taille stricte. Lorsque les serveurs Cloudflare ont tenté de le charger, ils ont échoué, et de nombreux sites utilisant Cloudflare ont commencé à renvoyer des erreurs HTTP 5xx (codes d’erreur que voient les utilisateurs quand un serveur tombe en panne).
Voici la chaîne d’événements :
Un petit ajustement de base de données déclenche une grande réaction en chaîne.
Le problème a commencé à 11h05 UTC lorsqu’une mise à jour des permissions a amené le système à extraire des informations supplémentaires et dupliquées lors de la construction du fichier utilisé pour noter les bots.
Ce fichier inclut normalement environ soixante éléments. Les doublons l’ont fait dépasser un plafond strict de 200. Lorsque les machines du réseau ont chargé le fichier surdimensionné, le composant bot n’a pas pu démarrer et les serveurs ont renvoyé des erreurs.
Selon Cloudflare, les chemins serveur actuels et anciens ont été affectés. L’un renvoyait des erreurs 5xx. L’autre attribuait un score bot de zéro, ce qui aurait pu faussement signaler du trafic pour les clients qui bloquent selon le score bot (détection bot vs humain de Cloudflare).
Le diagnostic était compliqué car le mauvais fichier était reconstruit toutes les cinq minutes à partir d’un cluster de base de données mis à jour morceau par morceau.
Si le système tirait d’une partie mise à jour, le fichier était mauvais. Sinon, il était bon. Le réseau se rétablissait puis retombait en panne, au gré des versions.
Selon Cloudflare, ce schéma on-off ressemblait initialement à une possible attaque DDoS, d’autant plus qu’une page de statut tierce est aussi tombée en panne au même moment. L’attention s’est déplacée une fois les erreurs reliées à la configuration de détection de bots.
À 13h05 UTC, Cloudflare a appliqué un contournement pour Workers KV (vérifications de connexion) et Cloudflare Access (système d’authentification), contournant le comportement défaillant pour limiter l’impact.
La correction principale est intervenue lorsque les équipes ont cessé de générer et de distribuer de nouveaux fichiers bots, ont poussé un fichier sain connu et redémarré les serveurs centraux.
Cloudflare indique que le trafic principal a recommencé à circuler à 14h30, et que tous les services en aval étaient rétablis à 17h06.
L’incident met en lumière certains compromis de conception.
Les systèmes de Cloudflare appliquent des limites strictes pour garantir des performances prévisibles. Cela permet d’éviter une utilisation excessive des ressources, mais signifie aussi qu’un fichier interne mal formé peut provoquer un arrêt brutal au lieu d’un repli gracieux.
Parce que la détection des bots se situe sur le chemin principal de nombreux services, la défaillance d’un module s’est propagée au CDN, aux fonctions de sécurité, à Turnstile (alternative CAPTCHA), à Workers KV, à Access et aux connexions au tableau de bord. Cloudflare a également noté une latence accrue car les outils de débogage consommaient du CPU en ajoutant du contexte aux erreurs.
Côté base de données, une modification étroite des permissions a eu des effets étendus.
Le changement a fait que le système « voyait » plus de tables qu’avant. Le job qui construit le fichier de détection de bots ne filtrait pas assez strictement, il a donc récupéré des noms de colonnes en double et gonflé le fichier au-delà du plafond de 200 éléments.
L’erreur de chargement a alors déclenché des pannes serveur et des réponses 5xx sur les chemins affectés.
L’impact variait selon les produits. Les services CDN et de sécurité principaux renvoyaient des erreurs serveur.
Workers KV a vu des taux de 5xx élevés car les requêtes vers sa passerelle passaient par le chemin défaillant. Cloudflare Access a connu des échecs d’authentification jusqu’au contournement de 13h05, et les connexions au tableau de bord ont échoué lorsque Turnstile ne pouvait pas se charger.
Cloudflare Email Security a temporairement perdu une source de réputation IP, réduisant la précision de détection du spam pendant un temps, bien que l’entreprise ait indiqué qu’il n’y avait pas d’impact critique pour les clients. Après la restauration du bon fichier, un arriéré de tentatives de connexion a brièvement mis sous tension les APIs internes avant un retour à la normale.
La chronologie est simple.
Le changement de base de données a été appliqué à 11h05 UTC. Les premières erreurs visibles par les clients sont apparues vers 11h20–11h28.
Les équipes ont ouvert un incident à 11h35, appliqué le contournement Workers KV et Access à 13h05, arrêté la création et la propagation de nouveaux fichiers vers 14h24, poussé un fichier sain connu et constaté un rétablissement global à 14h30, et marqué la restauration complète à 17h06.
Selon Cloudflare, les tests automatisés ont signalé des anomalies à 11h31, et l’enquête manuelle a commencé à 11h32, ce qui explique le passage d’une suspicion d’attaque à un retour de configuration en moins de deux heures.
| 11:05 | Changement déployé | Mise à jour des permissions de la base de données a mené à des entrées dupliquées |
| 11:20–11:28 | Début de l’impact | Poussée de HTTP 5xx lorsque le fichier bot dépasse la limite de 200 éléments |
| 13:05 | Atténuation | Contournement pour Workers KV et Access réduit la surface d’erreur |
| 13:37–14:24 | Préparation du rollback | Arrêt de la propagation du mauvais fichier, validation d’un fichier sain connu |
| 14:30 | Rétablissement central | Bon fichier déployé, le trafic principal circule normalement |
| 17:06 | Résolu | Les services en aval sont entièrement restaurés |
Les chiffres expliquent à la fois la cause et la maîtrise de l’incident.
Un cycle de reconstruction de cinq minutes réintroduisait à plusieurs reprises de mauvais fichiers à mesure que différentes parties de la base de données étaient mises à jour.
Un plafond de 200 éléments protège l’utilisation de la mémoire, et un nombre typique proche de soixante laissait une marge confortable, jusqu’à l’arrivée des entrées dupliquées.
Le plafond a fonctionné comme prévu, mais l’absence d’un « chargement sécurisé » tolérant pour les fichiers internes a transformé une mauvaise configuration en crash au lieu d’un échec doux avec un modèle de repli. Selon Cloudflare, c’est un point clé à renforcer.
Cloudflare indique qu’il va renforcer la validation de la configuration interne, ajouter plus d’interrupteurs globaux pour les pipelines de fonctionnalités, empêcher le reporting d’erreurs de consommer beaucoup de CPU lors d’incidents, revoir la gestion des erreurs dans tous les modules, et améliorer la distribution de la configuration.
L’entreprise a qualifié cet incident de pire depuis 2019 et s’est excusée pour l’impact. Selon Cloudflare, il n’y a pas eu d’attaque ; la reprise est venue de l’arrêt du mauvais fichier, de la restauration d’un fichier sain connu et du redémarrage des processus serveur.
L’article How a single computer file accidentally took down 20% of the internet yesterday – in plain English est apparu en premier sur CryptoSlate.
Avertissement : le contenu de cet article reflète uniquement le point de vue de l'auteur et ne représente en aucun cas la plateforme. Cet article n'est pas destiné à servir de référence pour prendre des décisions d'investissement.
Vous pourriez également aimer
Les revenus et les profits du troisième trimestre d'Adobe dépassent les attentes, l’IA propulse le nombre d'utilisateurs actifs mensuels au-delà de 1 milliard, les prévisions du quatrième trimestre manquent de « surprises » | Revue des résultats financiers
Au troisième trimestre, Adobe a enregistré un chiffre d'affaires de 6,76 milliards de dollars, en hausse de 13 % sur un an, dépassant la prévision moyenne des analystes de 6,7 milliards de dollars. Le bénéfice par action ajusté non-GAAP s'élève à 6,13 dollars, supérieur à l'estimation du marché de 6,08 dollars. La société a relevé sa fourchette de prévision du BPA ajusté annuel à 24,45–24,50 dollars et a légèrement augmenté la limite supérieure de son objectif de chiffre d'affaires annuel. Cependant, la prévision de chiffre d'affaires pour le quatrième trimestre est légèrement inférieure aux attentes des analystes, et le cours de l'action a chuté d'environ 2 % après la clôture.
Les Houthis s'emparent d'un port stratégique de la mer Rouge, les conflits s'intensifient en Arabie Saoudite, l'Iran aurait repris la production de missiles balistiques, le cours du pétrole grimpe de plus de 7 % en séance.
Un officier de l'armée gouvernementale du Yémen a déclaré que Mouha, une ville portuaire stratégique de la mer Rouge située dans la province de Taëz, au sud-ouest du Yémen, a été capturée jeudi par les forces houthis. Les Houthis ont affirmé le même jour que l'Arabie Saoudite avait mené 64 frappes aériennes sur plusieurs zones du Yémen en 24 heures ; la navigation en mer Rouge "n'est pas menacée" et leurs opérations militaires relèvent de la défense. Selon des acteurs du secteur maritime, la prise de Mouha permettrait aux Houthis de continuer leur progression vers le sud et de "presque contrôler totalement" le détroit de Bab-el-Mandeb. La perte de Mouha "aura sans aucun doute un impact sur la sécurité maritime de la région".
SpaceX procède à une révision complète du modèle de construction de centres de données IA : expansion ralentie, renforcement de la fiabilité
Selon les médias, Elon Musk a procédé à une importante réorganisation de la direction des centres de données, nommant un vétéran du secteur des fusées comme responsable. La nouvelle équipe de gestion exige que des tests plus approfondis soient réalisés avant la mise en service des centres de données, et que davantage de systèmes de secours pour l'électricité et le refroidissement soient installés, sacrifiant ainsi la vitesse de construction au profit d’une fiabilité accrue. La semaine dernière, une panne d'électricité au centre de données de Memphis a entraîné la mise hors ligne de certains modèles Grok, ce qui a eu un effet domino sur les clients de location de puissance de calcul tels qu’Anthropic et Google.
Le Trésor américain réalise un rachat d'obligations à long terme de plus de 5 milliards de dollars, la vente massive d'obligations américaines se poursuit, le rendement à 10 ans approche les 5%.
60 milliards de dollars restent limités par rapport au marché américain des bons du Trésor, qui pèse environ 32 000 milliards de dollars, et n’atteignent pas l’“effet choc” attendu par certains investisseurs. Les stratèges de Deutsche Bank ont directement déclaré que c’est comme si le Trésor avait “créé un monstre qu’il faut désormais nourrir en permanence”.
Prix des cryptos
Plus
