Zusammenfassung

  • Am 2. Juli 2019 erreichte eine funktional geprüfte WAF-Regel Cloudflares weltweiten Edge in Sekunden. Eine reguläre Expression geriet bei bestimmten Eingaben in massives Backtracking, die HTTP/HTTPS-Prozesse erschöpften ihre CPU und Kunden erhielten 27 Minuten lang 502-Fehler.
  • Nachhaltige Kontrolle bedeutet nicht, schnelle Abwehr abzuschaffen: Der globale Notfallpfad muss vom normalen Change getrennt, Rechenaufwand vorab begrenzt, Exposition schrittweise erhöht und ein Abschalt- und Kontrollpfad außerhalb des betroffenen Edge erhalten werden.

Ein kleiner Change erhielt weltweite Reichweite

Um 13:31 Uhr UTC wurde der geprüfte Pull Request eines Firewall-Ingenieurs zusammengeführt. Um 13:37 Uhr liefen Build und Tests in TeamCity. Um 13:42 Uhr begann der automatisierte Rollout einer kleinen Änderung an der XSS-Erkennung.

Die Verteilungsanlage funktionierte. Quicksilver war darauf ausgelegt, Konfiguration in Sekunden über Cloudflares Netz zu bringen. Der Bericht nennt mehr als 180 Städte, durchschnittlich etwa 350 Änderungen pro Sekunde und 2,29 Sekunden im 99. Perzentil für die weltweite Auslieferung. Eine spätere Architekturbeschreibung schildert denselben Anspruch für Hunderte Städte.

Diese Geschwindigkeit hatte einen Sicherheitszweck. Bei einer aktiv ausgenutzten Schwachstelle kann jede Verzögerung weitere Kunden exponieren. Cloudflare verwies auf die schnelle weltweite Reaktion auf eine schwere SharePoint-Lücke als Beleg für die Notwendigkeit.

Die Regel vom 2. Juli war jedoch kein Notfall. Der Standardprozess erlaubte auch ihr die unmittelbare globale Strecke. Die Tests zeigten, ob erwartete Angriffe blockiert und harmlose Requests zugelassen wurden. Sie zeigten nicht, welche maximale CPU-Zeit eine Eingabe erzwingen konnte.

Damit prüfte die Freigabe eine Aussage über Inhalte, verlieh aber eine zweite, unausgesprochene Befugnis: diese Aussage auf dem weltweiten Traffic auszuführen. Quicksilver verkürzte den Abstand zwischen Entscheidung und größtmöglicher Wirkung so stark, dass Beobachtung erst nach Konvergenz einsetzte.

Richtige Antworten können unvertretbar teuer sein

Die Expression lief in einer PCRE-basierten Backtracking-Engine. Eine solche Engine probiert mögliche Wege durch einen Ausdruck. Bei gewöhnlichen Mustern und Eingaben findet oder verwirft sie eine Übereinstimmung schnell. Mehrdeutige Wiederholungen können die Zahl der Pfade bei bestimmten Daten exponentiell anwachsen lassen.

Die endgültige Antwort kann weiterhin korrekt sein. Der Dienst fällt aus, während die Maschine sie ermittelt.

Eine Sicherheitsregel braucht deshalb zwei Nachweise. Semantische Korrektheit beantwortet, welcher Traffic blockiert werden soll. Operative Korrektheit begrenzt CPU, Speicher und Warteschlangenzeit, die jede Eingabe beanspruchen darf. Beispiele für Blockieren und Zulassen erfüllen nur den ersten Nachweis.

Cloudflares WAF lag im HTTP/HTTPS-Pfad und wertete Tausende Regeln über großes Volumen aus. Als die neue Expression bei bestimmten Requests enorme Arbeit auslöste, erschöpften die zuständigen Prozesse ihre Rechenkerne. Proxy-, CDN- und WAF-Funktionen waren gemeinsam betroffen.

Die vorderen Webserver hatten noch freie Kerne und konnten 502-Seiten erzeugen. Sie erreichten aber die Prozesse für HTTP/HTTPS nicht mehr. Nicht jeder Kern jeder Maschine war tot; die kritische Ausführungsschicht war unerreichbar.

Der Postmortem beschreibt weitere fehlende Grenzen. Ein CPU-Schutz hatte existiert, war jedoch bei einem früheren Performance-Refactoring versehentlich entfernt worden. Die Engine gab keine entsprechende Komplexitätsgarantie, die Tests erkannten keine außer Kontrolle geratene CPU und der Standardprozess sah keine Stufen für normale Regeln vor. Ein „schlechter Regex“ allein erklärt diese Kette nicht.

Der Alarm kam nach dem weltweiten Rollout

Um 13:45 Uhr löste ein externer synthetischer WAF-Test die erste PagerDuty-Meldung aus. Weitere Ende-zu-Ende-Tests scheiterten, der globale Traffic fiel, 502-Fehler verbreiteten sich und PoPs meldeten CPU-Erschöpfung. Die kurze Mitteilung beziffert den maximalen Rückgang von Cloudflare-Traffic auf 82 Prozent. Das sind nicht 82 Prozent des Internets.

Zunächst vermuteten Beteiligte eine unbekannte Angriffsform. Um 14:00 Uhr zeigten Performance-Daten, Logs und strace auf die WAF; ein Angriff wurde ausgeschlossen. Um 14:02 Uhr schlug das Team „global terminate“ vor – die weltweite Abschaltung einer Komponente.

Der reguläre Rollback war zu langsam. Die Rückkehr zum vorherigen Regelstand erforderte zwei vollständige WAF-Builds. Wirksam war zunächst nur der breitere Entzug: die gesamte WAF ausschalten, anschließend die Regel isolieren, prüfen und später wieder freigeben.

Auch der Kontrollzugang lag teilweise im Ausfallbereich. Cloudflare nutzte das eigene Access-Produkt zur internen Authentisierung. Das übliche Panel, Jira und das Build-System waren schwer erreichbar. Ein selten geübter Bypass wurde nötig; bei einigen SREs waren Anmeldedaten durch eine Sicherheitsfunktion nach Nichtbenutzung abgelaufen.

Um 14:07 Uhr wurde die globale Abschaltung ausgeführt. Um 14:09 Uhr lagen Traffic und CPU wieder im erwarteten Bereich, andere Schutzmechanismen liefen weiter. Danach entfernte Cloudflare den zahlenden Kundenverkehr aus einer Stadt und testete dort mit einem Teil des Traffics. Um 14:52 Uhr wurde die WAF weltweit reaktiviert.

Der ausführliche Bericht nennt 27 Minuten Nichtverfügbarkeit, die erste Meldung ungefähr 30 Minuten. Entscheidend ist die andere Differenz: Sekunden für die Erteilung, Minuten bis zur Diagnose, ein komponentenweiter Eingriff für den Entzug und mehr als eine Stunde bis zur geprüften Wiederherstellung.

Die Ausführungsumgebung kann Befugnis begrenzen

Cloudflare kündigte an, CPU-Schutz zurückzubringen, alle 3.868 Regeln zu untersuchen, Performance-Profile einzuführen und auf RE2 oder eine Rust-Engine umzusteigen. Im Juli 2020 schrieb das Unternehmen, die WAF sei bereits im Juli 2019 von einer PCRE-Basis zu einer von RE2 inspirierten Engine gewechselt.

RE2 macht Sicherheit zur Konstruktionseigenschaft. Die Laufzeit ist asymptotisch linear zur Eingabelänge, Speicher bleibt in einem konfigurierbaren Budget und Erschöpfung führt zu kontrolliertem Scheitern. Rückreferenzen und allgemeine Look-around-Konstrukte fehlen, wenn für sie nur Backtracking-Verfahren bekannt sind.

Diese Beschränkung ist organisatorisch wirksam. Autoren verlieren einige Ausdrucksmöglichkeiten oder müssen Regeln neu entwerfen. Dafür kann ein übersehener Ausdruck nicht mehr dieselbe exponentielle Suchmacht erhalten. Die Sprache selbst grenzt die Fähigkeit ein.

RE2 behauptet nicht, in jedem Fall schneller zu sein; komplexe Ausdrücke können größere konstante Kosten haben. PCRE2 dokumentiert seinerseits Match-, Tiefen- und Heap-Grenzen. Die Quellen belegen nicht, dass solche allgemeinen Schranken 2019 in Cloudflares Pfad aktiv waren.

Cloudflares spätere Messung zeigt den Zweck: Der Engine-Wechsel senkte die durchschnittliche CPU nicht messbar, reduzierte aber Ausreißer im 95. und 99. Perzentil der Ausführungszeit. Resilienz lag im Rand der Verteilung. Ein normaler Request musste nicht billiger werden; ein seltener durfte nicht unverhältnismäßig teuer sein.

Auch eine gebundene Regex-Engine begrenzt nicht automatisch Dekodierung, Normalisierung, Parser, Cache und Regelinteraktion. Das gesamte Verarbeitungssystem braucht Budgets und Tests unter repräsentativer sowie gegnerischer Last.

Schnelligkeit braucht zwei getrennte Pfade

Cloudflares Maßnahmen unterschieden fortan den gestuften Normalbetrieb von der weltweiten Sofortauslieferung während eines aktiven Angriffs. So bleibt die defensive Fähigkeit erhalten, ohne jedem Change dieselbe Vollmacht zu geben.

Eine normale Regel kann Komplexitätsprüfung, adversariale Eingaben und Messung der gesamten Verarbeitung durchlaufen, zunächst nur beobachten, dann eine Stadt, einen kleinen Traffic-Anteil und eine Region erreichen. Jede Stufe misst Trefferqualität, CPU pro Regel, Tail-Latenz, Fehler und Erreichbarkeit der Prozesse. Automatische Abbruchwerte verhindern die nächste Beförderung.

Der Notfallpfad verkürzt die Beobachtung, benötigt aber eine benannte Lage, eine Bedrohungsgrundlage, einen Verantwortlichen, ein Ablaufdatum, laufende Budgets und eine vom Antragsteller getrennte Person mit Entzugsrecht. Dringlichkeit ist eine dokumentierte Risikowahl, keine kontrollfreie Zone.

Ein Canary muss tatsächlich unabhängig sein. Fünf Prozent von Standorten, die dieselbe fragile Queue oder ausfallende Telemetrie teilen, begrenzen weder Schaden noch Erkenntnis. Repräsentativer Traffic, getrennte Kapazität und eine Kontrollgruppe gehören zur Stufe.

Der Entzug einer Regel darf keinen Doppel-Build verlangen. Ein Schalter deaktiviert die Regel, ein größerer die Komponente. Beide müssen geübt werden, wenn Dashboard, Identität und Build-Strecke nicht verfügbar sind.

Die Steuerung darf nicht mit dem Ziel verschwinden

Cloudflares Eigenabhängigkeit löste das Problem nicht aus, erschwerte aber die Wiederherstellung. Auch Kunden-Dashboard und API liefen über den betroffenen Edge. Im wichtigsten Moment sank die Handlungsfähigkeit.

Unabhängigkeit kann klein sein: Notfallanmeldung, Statusveröffentlichung, globale Abschaltung, minimale Konfiguration, Evidenzzugriff und Kundenkontrollen zur Schadensbegrenzung. Diese Überlebensfläche braucht isolierte Kapazität, Pfade und regelmäßig verwendete Zugangsdaten.

Heng Lus Running-Code Primacy trennt Prozess und Wirklichkeit. Review, Ticket und Rollback-Plan koordinieren. Sie begrenzen keine CPU. Wenn laufender Code die Maschine erschöpft und seinen Kontrollzugang abschneidet, erzeugt die Bezeichnung „freigegeben“ keine Sicherheit.

Technische Verfügung ist auch nicht praktische Kontrolle. Ein Abschaltbefehl im Inventar hilft wenig, wenn Authentisierung, Bediener, Konsole und Build vom abzuschaltenden System abhängen. Macht muss im Ausfall ausübbar sein.

Grenzen der Evidenz

Zeitlinie, interne Architektur, Ursachen und Maßnahmen stammen überwiegend von Cloudflare. Der detaillierte Bericht ist wertvoll, bleibt aber Selbstauskunft. Eine unabhängige vollständige Zahl betroffener Kunden, Domains, Requests oder wirtschaftlicher Schäden liegt in den verwendeten Quellen nicht vor.

Cloudflare erklärte ausdrücklich, es habe sich nicht um einen Angriff gehandelt. Hier wird weder feindliche Absicht noch gezielte Auslösung behauptet. Quicksilver schrieb den Ausdruck nicht und entfernte den CPU-Schutz nicht; das System vergrößerte die Folge, weil der normale Prozess seine gesamte Reichweite nutzen konnte.

Der Text von 2020 bestätigt den Engine-Wechsel und Messwerte am Verteilungsrand. Er beweist nicht die dauerhafte Vollständigkeit jeder 2019 angekündigten Maßnahme. Der Fall stützt ein Kontrollmodell, keine Zusicherung künftiger Fehlerfreiheit.

Quellen