Résumé

  • Une règle WAF fonctionnellement approuvée a été distribuée sur le réseau mondial de Cloudflare le 2 juillet 2019 ; une expression régulière déclenchait un retour arrière catastrophique, privant de CPU les processus HTTP/HTTPS et provoquant vingt-sept minutes d’erreurs 502.
  • La bonne réponse n’est pas de sacrifier la vitesse face à une attaque active, mais de distinguer l’autorité d’urgence du changement ordinaire, d’imposer une enveloppe de ressources, de progresser par exposition mesurée et de conserver un arrêt et un plan de commande qui survivent à la panne de l’edge.

Le changement était mineur, son mandat ne l’était pas

À 13 h 31 UTC, un ingénieur de l’équipe pare-feu de Cloudflare a fusionné une demande de modification approuvée. TeamCity a lancé la construction et les tests à 13 h 37. À 13 h 42, le processus automatique a commencé à déployer une légère modification d’une règle de détection XSS.

La règle n’a pas été bloquée en chemin. Elle est arrivée là où on l’envoyait.

Quicksilver, le système de configuration de Cloudflare, avait pour fonction d’abolir la distance opérationnelle. Le récit de l’incident lui attribue alors plus de 180 villes, quelque 350 changements traités chaque seconde en moyenne et une diffusion mondiale au 99e centile en 2,29 secondes. Une présentation ultérieure de l’architecture confirme l’ambition : rendre une configuration présente dans des centaines de villes en quelques secondes.

Cette vitesse est une qualité de sécurité. Lorsqu’une vulnérabilité est activement exploitée, une WAF qui progresse trop lentement laisse une fenêtre à l’assaillant. Cloudflare rappelle à ce propos une règle distribuée rapidement contre une vulnérabilité importante de SharePoint.

La règle du 2 juillet ne répondait pourtant pas à une urgence. La procédure normale l’autorisait à emprunter le chemin mondial immédiat. Les tests demandaient si des requêtes dangereuses étaient bloquées et si des requêtes admises passaient. Ils ne demandaient pas combien de temps processeur une entrée hostile ou rare pouvait faire consommer.

L’approbation portait donc sur la sémantique, tandis que le déploiement accordait une puissance d’exécution. En quelques secondes, un prédicat validé pour son résultat obtenait le droit de solliciter les ressources partagées de chaque point de présence. Le système de distribution a comprimé l’intervalle d’observation jusqu’à ce que l’effet mondial précède sa mesure.

Un résultat exact peut avoir un prix fatal

L’expression fonctionnait dans un moteur dérivé de PCRE. Un moteur à retours arrière explore successivement les chemins possibles d’une expression. Dans le cas courant, il trouve ou exclut rapidement la correspondance. Certaines constructions ambiguës, appliquées à certaines chaînes, multiplient les chemins au point que le temps d’exécution devient exponentiel.

Le verdict peut rester juste. Le service disparaît pendant que la machine cherche à le produire.

Une règle de sécurité possède ainsi deux formes d’exactitude. L’exactitude fonctionnelle détermine si elle bloque ce qui doit l’être. L’exactitude opérationnelle exige que le coût maximal d’un verdict reste compatible avec le service. La première ne prouve pas la seconde.

Chez Cloudflare, la WAF faisait partie du trajet normal des requêtes HTTP et HTTPS et appliquait des milliers de règles. Quand la nouvelle expression a monopolisé le calcul sur certaines entrées, les processus de service ont épuisé leurs cœurs. Les fonctions de proxy, de CDN et de pare-feu ont été touchées ensemble.

Une nuance du rapport évite un raccourci trompeur. Les serveurs Web de première ligne disposaient encore de cœurs pour produire les pages 502 ; ils n’arrivaient plus à joindre les processus chargés du trafic HTTP/HTTPS. Le réseau n’était pas uniformément éteint. Le niveau critique d’exécution était inaccessible.

Cloudflare a aussi reconnu qu’une protection contre la consommation excessive du CPU existait auparavant, mais avait été retirée par accident lors d’une refonte destinée à améliorer les performances. Le moteur n’offrait pas de garantie de complexité, les tests n’inspectaient pas la dérive du CPU et la procédure autorisait l’exposition mondiale sans étape. Réduire l’événement à une mauvaise expression exonérerait ces frontières disparues.

Quand l’alerte est venue, la convergence était achevée

À 13 h 45, trois minutes après le début du déploiement, un test synthétique externe de la WAF a déclenché la première alerte PagerDuty. D’autres vérifications de bout en bout ont échoué, le trafic mondial a chuté, les 502 se sont généralisées et des PoP ont signalé l’épuisement des CPU.

La note initiale indique une baisse de 82 % du trafic au pire de l’événement. Il s’agit du trafic vu sur le réseau de Cloudflare, non de 82 % de l’Internet.

Les premières minutes ont fait envisager une attaque inédite. À 14 h 00, les données de performance, les journaux et strace avaient isolé la WAF ; la piste de l’attaque a été écartée. À 14 h 02, le groupe a envisagé une « global terminate », commande capable de désactiver un composant partout.

La voie normale de retour était trop lente. Revenir précisément à la version antérieure exigeait deux constructions complètes de la WAF. Le geste efficace a été plus large : retirer mondialement la WAF, puis trouver la règle, la corriger, la tester et restaurer le composant.

Le plan de commande dépendait lui-même des services atteints. L’authentification interne utilisait Cloudflare Access. Avec l’edge défaillant, le panneau habituel, Jira et le système de construction étaient difficiles d’accès. Il a fallu activer un contournement peu exercé. Certains ingénieurs de fiabilité avaient en outre des identifiants expirés, une mesure de sécurité les ayant désactivés faute d’usage récent.

La terminaison mondiale a été exécutée à 14 h 07. À 14 h 09, le CPU et le trafic avaient retrouvé leur niveau attendu ; les autres protections de Cloudflare continuaient de fonctionner. L’entreprise a ensuite retiré le trafic des clients payants d’une ville, puis y a utilisé un échantillon pour des tests positifs et négatifs. À 14 h 52, elle a réactivé la WAF partout.

Le rapport complet compte vingt-sept minutes d’indisponibilité ; la première note parle d’une trentaine de minutes. La différence n’est pas substantielle. L’asymétrie l’est : quelques secondes pour accorder le pouvoir mondial, plusieurs minutes pour voir le dommage, un arrêt de composant pour le contenir, puis plus d’une heure depuis le déploiement pour une restauration examinée.

Le moteur peut limiter le pouvoir de l’auteur

Cloudflare a annoncé le rétablissement de la protection CPU, le contrôle des 3 868 règles, le profilage des performances et une migration vers RE2 ou un moteur Rust. Son bilan de juillet 2020 indique que la WAF avait quitté en juillet 2019 le moteur dérivé de PCRE au profit d’une conception inspirée de RE2.

RE2 place la sécurité dans ses propriétés d’exécution. Il garantit un temps asymptotiquement linéaire dans la longueur de l’entrée, travaille dans un budget mémoire réglable et échoue proprement quand celui-ci est épuisé. Il renonce, en contrepartie, aux références arrière et aux assertions généralisées lorsqu’elles exigent un algorithme de retour arrière.

Ce choix restreint une capacité avant qu’elle arrive au réviseur. L’auteur ne peut plus exprimer certains motifs pratiques, mais son oubli ne peut plus créer le même arbre de recherche exponentiel. La politique de ressources devient une propriété du langage d’exécution.

RE2 ne prétend pas être le plus rapide partout. Des expressions complexes gardent des facteurs constants plus élevés, et une migration peut obliger à réécrire des règles. PCRE2 documente de son côté des limites de correspondance, de profondeur et de mémoire. L’existence de ces mécanismes généraux ne prouve pas leur activation sur le chemin Cloudflare de 2019.

Le résultat publié en 2020 est révélateur : la migration n’a pas produit de différence mesurable sur le CPU moyen, mais a réduit les valeurs aberrantes aux 95e et 99e centiles du temps d’exécution. La résilience ne demandait pas d’abord de réduire la requête moyenne ; elle demandait qu’une requête ne puisse plus réclamer une part extravagante de la machine.

Le moteur ne borne cependant ni le décodage, ni les transformations, ni la tokenisation, ni le cache, ni les interactions entre règles. Les limites doivent donc être testées sur toute la chaîne, avec des entrées adverses et des charges représentatives.

Garder la voie rapide en la rendant exceptionnelle

La réponse annoncée par Cloudflare sépare deux usages. Les changements ordinaires avancent par étapes. Une attaque active peut encore justifier une diffusion mondiale immédiate.

Cette séparation vaut mieux qu’un ralentissement uniforme. Une voie d’urgence reste nécessaire, mais elle doit porter un incident nommé, un responsable, une hypothèse de menace, une échéance, des budgets surveillés et une personne indépendante capable de retirer l’autorité. L’urgence raccourcit l’observation ; elle n’abolit pas le contrôle.

Pour le trajet ordinaire, une règle peut subir une analyse de complexité et des entrées adverses, fonctionner sans enforcement en observation, puis atteindre un site, une petite part du trafic et une région. À chaque étape, le système mesure les bonnes détections, le CPU par règle, la latence de queue, les erreurs et la joignabilité des processus. Un seuil doit arrêter automatiquement la promotion.

Une étape ne vaut que si elle isole réellement le risque. Cinq pour cent des sites ne forment pas un bon canari s’ils partagent la file fragile ou la télémétrie que l’incident peut abattre. Il faut un trafic représentatif, une capacité séparée, un groupe témoin et des instruments survivants.

La révocation doit être plus rapide qu’une construction complète. Une clé peut désactiver la nouvelle règle ; une autre, plus large, peut retirer le composant. L’exercice doit réussir sans le tableau de bord, le fournisseur d’identité ou la chaîne de construction habituels. Sinon, la capacité existe dans l’inventaire technique, mais pas dans la réalité d’une crise.

Un plan de commande ne doit pas disparaître avec sa cible

L’usage des propres services de Cloudflare n’a pas créé l’expression, mais a ralenti l’action. Le tableau de bord et l’API des clients traversaient eux aussi l’edge atteint. Au moment où le système réclamait le plus de contrôle, les opérateurs et les clients en avaient moins.

L’indépendance n’exige pas une seconde plateforme entière. Il faut une surface de survie étroite : authentification d’urgence, publication d’état, arrêt mondial, modification minimale, accès aux preuves et commandes permettant aux clients de réduire leur dommage. Sa capacité, son routage et ses identifiants doivent être séparés et testés.

La primauté du code en fonctionnement, formulée par Heng Lu, donne ici un critère de réalité. Une revue approuvée, un ticket et un plan de retour sont des moyens de coordination. Ils ne protègent le service que si le code exécuté respecte leurs hypothèses. Quand la production consume tout le CPU et ferme son propre accès de secours, la déclaration d’approbation perd toute force opérationnelle.

De même, le contrôle technique ne suffit pas au contrôle pratique. Posséder une commande d’arrêt n’est pas exercer un pouvoir si l’authentification, les personnes et l’interface nécessaires dépendent du composant à arrêter. La capacité se mesure au moment de son usage, pas sur un diagramme au repos.

Limites de la preuve

La chronologie, l’architecture interne et les causes proviennent surtout de Cloudflare. Leur précision rend l’examen possible, mais il s’agit d’un récit de l’entreprise. Les sources consultées ne donnent pas de comptage indépendant et complet des clients, domaines, requêtes ou pertes économiques touchés.

Cloudflare a explicitement exclu une attaque. Rien ne permet ici d’attribuer une intention ou un déclenchement hostile. Quicksilver n’a ni écrit l’expression ni retiré la protection CPU ; il a amplifié la portée parce que l’approbation ordinaire pouvait appeler toute sa capacité.

Le texte de 2020 confirme la migration du moteur et des effets mesurés sur la queue de distribution. Il ne vérifie pas à lui seul la permanence de chaque engagement pris en 2019. Le cas établit une discipline de contrôle, non l’infaillibilité future d’une entreprise ou d’un moteur.

Sources