+− THE DAILY DIFFdev & AI news
SHIP IT

Une expression régulière a fait planter Cloudflare. 27 minutes.

2 juillet 2019, 13:42 UTC: une nouvelle règle pour le pare-feu d'applications web de Cloudflare est déployée dans plus de 180 villes en environ deux secondes.

2 juillet 2019, 13:42 UTC: une nouvelle règle pour le pare-feu d'applications web de Cloudflare est déployée dans plus de 180 villes en environ deux secondes. C'est une règle XSS en mode simulation, donc elle ne bloque rien, mais elle s'exécute toujours à chaque requête, et elle se termine par .*(?:.*=.*). PCRE effectue des retours en arrière (backtracks), chaque cœur de CPU servant des requêtes HTTP atteint 100 %, et chaque site proxifié par Cloudflare renvoie 502 pendant 27 minutes; le trafic chute de 82 %. Le coupe-circuit est derrière Cloudflare Access, qui est derrière Cloudflare. Postmortem, d'après la propre analyse de Cloudflare : la protection CPU retirée des semaines plus tôt lors d'un refactoring censé économiser du CPU, la procédure qui permettait à toute règle de sauter la mise en scène, le moteur sans garantie de complexité, les 11 causes et les 7 correctifs. Verdict sur le correctif : SHIP IT.

Lire l'édition écrite (anglais) ↗

Ce que cette vidéo couvre

  • 13:31–13:42 UTC: PR fusionné, CI vert (pas de test CPU), Quicksilver pousse la règle vers plus de 180 villes; les règles WAF sautent les étapes DOG → PIG → Canary
  • 13:45–14:07: première page; CPU 100 % mondial, trafic −82 %, 502 partout; le panneau de contrôle interne est derrière Cloudflare Access, qui est en panne; certaines identifiants ont expiré; un contournement rarement exercé
  • 14:07–14:09: terminaison globale du WAF; trafic et CPU normaux après 27 minutes; 14:52 WAF de retour moins la règle
  • 2 juil. (15:50 UTC) et 12 juil.: Cloudflare publie la note du jour même et le postmortem complet; la protection CPU est réajoutée, 3 868 règles sont relues, déploiements par étapes, passage à un moteur d'expressions régulières à temps linéaire

Transcription traduite

Traduit de la narration originale en anglais. L'audio et les sous-titres disponibles sont contrôlés par YouTube.

0:00 Une expression régulière est mise en ligne sur chaque serveur Cloudflare à la fois, et pendant les vingt-sept minutes suivantes, les sites derrière elle affichent une page 502, ce qui, pour un pare-feu, est le réglage le plus strict possible. 2 juillet 2019, 13:42 UTC. Cloudflare publie dans les deux heures: pas une attaque, un mauvais déploiement, trafic en baisse de 82 pour cent. Dix jours plus tard, le CTO John Graham-Cumming publie le postmortem complet, expression régulière incluse, et Hacker News lui donne 698 points,

0:26 ce qui pour une panne est une ovation. Comment cela se passe, pourquoi c'est possible, et qui est réellement à blâmer. Ceci est The Daily Diff, postmortem. 13:31. Une pull request est fusionnée: une nouvelle règle de pare-feu contre le cross-site scripting, en mode simulation, donc elle ne bloque rien. 13:37, les tests passent; aucun ne mesure le CPU. 13:42, la règle est envoyée à 180 villes en deux secondes, car les règles WAF sautent les étapes 'dog', 'pig' et 'canary' que les autres versions obtiennent.

0:54 13:45, la première page. 13:49, Hacker News a un fil sur la page de statut, qui indique toujours que tous les systèmes sont opérationnels. La règle se termine par point-étoile, point-étoile, égal, point-étoile: n'importe quoi, puis n'importe quoi, puis un signe égal. PCRE devine avec avidité, échoue et effectue des retours en arrière à travers chaque autre division. x égale x prend 23 étapes. Vingt x après le signe égal : 555.

1:15 Vingt x, pas de signe égal : 4 067 étapes pour ne rien trouver. Exécutez cela à chaque requête et chaque cœur est à cent pour cent, ne faisant rien, minutieusement. Deux gardes auraient dû l'intercepter. La limite CPU sur les règles a été supprimée par erreur des semaines plus tôt, dans un refactoring censé faire utiliser moins de CPU par le WAF. Et la procédure permet à toute règle de sauter la mise en scène, car les règles existent pour arrêter les attaques en direct; celle-ci n'était pas une urgence, et elle est quand même devenue globale.

1:37 14:00, le WAF est identifié; pas d'attaque. 14:02, quelqu'un propose la terminaison globale : un composant, éteint, mondial. L'interrupteur est derrière Cloudflare Access. Cloudflare Access est derrière Cloudflare. Certaines identifiants ont expiré par désuétude, de sorte que le réseau le plus rapide sur internet passe cinq minutes sur un contournement que personne n'a exercé. 14:07, arrêt. 14:09, trafic normal. git blame: un déploiement à une vitesse, globale; une protection CPU refactorisée par

2:04 accident; un moteur d'expressions régulières sans borne supérieure. Pas l'ingénieur qui a écrit la règle: le postmortem énumère onze causes et ne nomme personne. Rayon d'impact: 27 minutes, 82 pour cent du trafic, 100 pour cent d'utilisation CPU sur chaque cœur, dans chaque ville. Le tableau de bord et l'API sont derrière la même périphérie, donc les clients ne peuvent même pas le désactiver. Hacker News, sous le postmortem: ils avaient un problème, ont utilisé une expression régulière, maintenant ils en ont deux. Vieille blague. Se compile toujours.

2:28 Verdict, postmortem : SHIP IT. La protection CPU est de retour, toutes les 3 868 règles sont lues à la main, les règles passent par la mise en scène, et le moteur passe à un moteur avec des garanties de temps linéaire, publié par Ken Thompson en 1968. Lundi : pas de point-étoile point-étoile dans tout ce qui s'exécute par requête, et gardez l'interrupteur d'arrêt hors de la chose qu'il tue. Envoyez-moi l'incident dont vous n'êtes toujours pas autorisé à parler, dans les commentaires, ou à the daily diff dot dev.

2:53 Et c'est le diff pour aujourd'hui. Je suis Niko d'Axrisi. Fusionnez de manière responsable.

Sources

  1. John Graham-Cumming, "Details of the Cloudflare outage on July 2, 2019" (Jul 12, 2019)blog.cloudflare.com
  2. Matthew Prince, "Cloudflare outage caused by bad software deploy (updated)" (Jul 2, 2019)blog.cloudflare.com
  3. Matthew Prince on X, Jul 2, 2019, 14:22 UTCx.com
  4. Matthew Prince on X, Jul 2, 2019, 14:36 UTC ("No evidence yet attack related")x.com
  5. Hacker News, Jul 2, 2019, 13:49 UTC — "Cloudflare Network Performance Issues" (631 points)news.ycombinator.com
  6. Hacker News, Jul 2, 2019 — "Cloudflare outage caused by bad software deploy" (348 points)news.ycombinator.com
  7. Hacker News, Jul 12, 2019 — "Details of the Cloudflare outage on July 2, 2019" (698 points)news.ycombinator.com
  8. TechCrunch, Jul 2, 2019techcrunch.com

Vidéos similaires