Wie eine einzelne Computerdatei gestern versehentlich 20 % des Internets lahmlegte – einfach erklärt

Der gestrige Ausfall zeigte, wie abhängig das moderne Web von einer Handvoll zentraler Infrastrukturanbieter ist.

Tatsächlich ist die Abhängigkeit so groß, dass ein einziger Konfigurationsfehler große Teile des Internets für mehrere Stunden völlig unerreichbar machte.

Viele von uns arbeiten im Kryptobereich, weil wir die Gefahren der Zentralisierung im Finanzwesen verstehen, doch die Ereignisse von gestern waren eine deutliche Erinnerung daran, dass die Zentralisierung im Kern des Internets ein ebenso dringendes Problem ist, das gelöst werden muss.

Die offensichtlichen Giganten wie Amazon, Google und Microsoft betreiben riesige Teile der Cloud-Infrastruktur.

Ebenso kritisch sind jedoch Unternehmen wie Cloudflare, Fastly, Akamai, DigitalOcean sowie CDN-Anbieter (Server, die Webseiten weltweit schneller ausliefern) oder DNS-Anbieter (das „Adressbuch“ des Internets) wie UltraDNS und Dyn.

Die meisten Menschen kennen ihre Namen kaum, doch ihre Ausfälle können ebenso lähmend sein, wie wir gestern gesehen haben.

Hier zunächst eine Liste von Unternehmen, von denen Sie vielleicht noch nie gehört haben, die jedoch entscheidend dafür sind, dass das Internet wie erwartet funktioniert.

Kategorie Unternehmen Was sie kontrollieren Auswirkungen bei Ausfall

Kern-Infrastruktur (DNS/CDN/DDoS)	Cloudflare	CDN, DNS, DDoS-Schutz, Zero Trust, Workers	Große Teile des weltweiten Web-Traffics fallen aus; Tausende Seiten werden unerreichbar.
Kern-Infrastruktur (CDN)	Akamai	Enterprise-CDN für Banken, Logins, Handel	Wichtige Unternehmensdienste, Banken und Login-Systeme fallen aus.
Kern-Infrastruktur (CDN)	Fastly	CDN, Edge-Computing	Potenzial für weltweite Ausfälle (wie 2021: Reddit, Shopify, gov.uk, NYT).
Cloud-Anbieter	AWS	Compute, Hosting, Storage, APIs	SaaS-Anwendungen, Streaming-Plattformen, Fintech und IoT-Netzwerke fallen aus.
Cloud-Anbieter	Google Cloud	YouTube, Gmail, Unternehmens-Backends	Massive Störungen bei Google-Diensten und abhängigen Apps.
Cloud-Anbieter	Microsoft Azure	Enterprise- & Regierungs-Clouds	Office365, Teams, Outlook und Xbox Live fallen aus.
DNS-Infrastruktur	Verisign	.com- & .net-TLDs, Root-DNS	Katastrophale weltweite Routing-Fehler für große Teile des Webs.
DNS-Anbieter	GoDaddy / Cloudflare / Squarespace	DNS-Verwaltung für Millionen Domains	Komplette Unternehmen verschwinden aus dem Internet.
Zertifizierungsstelle	Let’s Encrypt	TLS-Zertifikate für den Großteil des Webs	HTTPS bricht weltweit; Nutzer sehen überall Sicherheitsfehler.
Zertifizierungsstelle	DigiCert / GlobalSign	Enterprise-SSL	Große Unternehmensseiten verlieren HTTPS-Vertrauen.
Sicherheit / CDN	Imperva	DDoS, WAF, CDN	Geschützte Seiten werden unerreichbar oder verwundbar.
Load Balancer	F5 Networks	Enterprise-Load-Balancing	Banken, Krankenhäuser und Regierungsdienste können landesweit ausfallen.
Tier-1-Backbone	Lumen (Level 3)	Globales Internet-Backbone	Routing-Probleme verursachen weltweite Latenzspitzen und regionale Ausfälle.
Tier-1-Backbone	Cogent / Zayo / Telia	Transit und Peering	Regionale oder landesweite Internetstörungen.
App-Distribution	Apple App Store	iOS-App-Updates & Installationen	Das iOS-App-Ökosystem friert effektiv ein.
App-Distribution	Google Play Store	Android-App-Verteilung	Android-Apps können weltweit nicht installiert oder aktualisiert werden.
Zahlungen	Stripe	Web-Zahlungsinfrastruktur	Tausende Apps verlieren die Möglichkeit, Zahlungen zu akzeptieren.
Identität / Login	Auth0 / Okta	Authentifizierung & SSO	Logins funktionieren bei Tausenden Apps nicht mehr.
Kommunikation	Twilio	2FA-SMS, OTP, Messaging	Ein großer Teil der weltweiten 2FA- und OTP-Codes schlägt fehl.

Was gestern passiert ist

Der Schuldige gestern war Cloudflare, ein Unternehmen, das fast 20% des gesamten Web-Traffics routet.

Cloudflare gibt nun an, dass der Ausfall mit einer kleinen Datenbank-Konfigurationsänderung begann, die versehentlich dazu führte, dass eine Bot-Erkennungsdatei doppelte Einträge enthielt.

Diese Datei wuchs plötzlich über ein striktes Größenlimit hinaus. Als die Server von Cloudflare versuchten, sie zu laden, schlugen sie fehl, und viele Webseiten, die Cloudflare nutzen, begannen, HTTP-5xx-Fehler (Fehlercodes, die Nutzer sehen, wenn ein Server ausfällt) zurückzugeben.

Hier ist die einfache Kette:

Chain of events

Eine kleine Datenbank-Änderung löst eine große Kettenreaktion aus.

Das Problem begann um 11:05 UTC, als ein Berechtigungs-Update das System dazu brachte, beim Erstellen der Datei zur Bot-Bewertung zusätzliche, doppelte Informationen zu ziehen.

Diese Datei enthält normalerweise etwa sechzig Einträge. Die Duplikate überschritten die harte Grenze von 200. Als Maschinen im gesamten Netzwerk die übergroße Datei luden, konnte die Bot-Komponente nicht starten und die Server gaben Fehler zurück.

Laut Cloudflare waren sowohl der aktuelle als auch der ältere Serverpfad betroffen. Einer gab 5xx-Fehler zurück. Der andere wies einen Bot-Score von Null zu, was dazu geführt haben könnte, dass Traffic fälschlicherweise für Kunden blockiert wurde, die auf Basis des Bot-Scores filtern (Cloudflares Bot-vs.-Mensch-Erkennung).

Die Diagnose war schwierig, weil die fehlerhafte Datei alle fünf Minuten aus einem Datenbank-Cluster, der Stück für Stück aktualisiert wurde, neu gebaut wurde.

Wenn das System aus einem aktualisierten Teil zog, war die Datei fehlerhaft. Wenn nicht, war sie in Ordnung. Das Netzwerk erholte sich, fiel dann wieder aus, als die Versionen wechselten.

Laut Cloudflare sah dieses An-Aus-Muster zunächst wie ein möglicher DDoS-Angriff aus, zumal auch eine Statusseite eines Drittanbieters ungefähr zur gleichen Zeit ausfiel. Der Fokus verlagerte sich, als die Teams die Fehler mit der Bot-Erkennungskonfiguration in Verbindung brachten.

Bis 13:05 UTC setzte Cloudflare einen Bypass für Workers KV (Login-Prüfungen) und Cloudflare Access (Authentifizierungssystem) ein, um das fehlerhafte Verhalten zu umgehen und die Auswirkungen zu verringern.

Die Hauptlösung bestand darin, dass die Teams aufhörten, neue Bot-Dateien zu generieren und zu verteilen, eine bekannte gute Datei einspielten und die Kernserver neu starteten.

Cloudflare gibt an, dass ab 14:30 der Kern-Traffic wieder floss und alle nachgelagerten Dienste bis 17:06 wiederhergestellt waren.

Der Ausfall verdeutlicht einige Design-Kompromisse.

Die Systeme von Cloudflare erzwingen strikte Grenzen, um die Performance vorhersehbar zu halten. Das hilft, einen ausufernden Ressourcenverbrauch zu vermeiden, bedeutet aber auch, dass eine fehlerhafte interne Datei einen harten Stopp auslösen kann, statt eines sanften Fallbacks.

Da die Bot-Erkennung im Hauptpfad vieler Dienste sitzt, führte der Ausfall eines Moduls zu Kaskadeneffekten im CDN, bei Sicherheitsfunktionen, Turnstile (CAPTCHA-Alternative), Workers KV, Access und Dashboard-Logins. Cloudflare stellte zudem eine erhöhte Latenz fest, da Debugging-Tools während der Fehleranalyse CPU verbrauchten.

Auf der Datenbankseite hatte eine kleine Berechtigungsänderung weitreichende Auswirkungen.

Die Änderung ließ das System mehr Tabellen „sehen“ als zuvor. Der Job, der die Bot-Erkennungsdatei baut, filterte nicht eng genug, sodass doppelte Spaltennamen aufgenommen wurden und die Datei über das 200-Elemente-Limit hinauswuchs.

Der Ladefehler löste dann Serverausfälle und 5xx-Antworten auf betroffenen Pfaden aus.

Die Auswirkungen variierten je nach Produkt. Zentrale CDN- und Sicherheitsdienste warfen Serverfehler.

Workers KV verzeichnete erhöhte 5xx-Raten, weil Anfragen an dessen Gateway durch den fehlerhaften Pfad liefen. Cloudflare Access hatte Authentifizierungsfehler bis zum Bypass um 13:05, und Dashboard-Logins schlugen fehl, wenn Turnstile nicht geladen werden konnte.

Cloudflare Email Security verlor vorübergehend eine IP-Reputationsquelle, was die Genauigkeit der Spam-Erkennung für eine Zeit verringerte, wobei das Unternehmen angab, dass es keine kritischen Auswirkungen für Kunden gab. Nachdem die gute Datei wiederhergestellt war, belastete ein Rückstau an Login-Versuchen kurzzeitig interne APIs, bevor sich die Lage normalisierte.

Der Zeitablauf ist klar.

Die Datenbankänderung wurde um 11:05 UTC eingespielt. Erste für Kunden sichtbare Fehler traten um 11:20–11:28 auf.

Die Teams eröffneten um 11:35 einen Vorfall, setzten um 13:05 den Workers-KV- und Access-Bypass ein, stoppten um 14:24 die Verbreitung neuer Dateien, spielten eine bekannte gute Datei ein und sahen um 14:30 eine globale Erholung, die vollständige Wiederherstellung wurde um 17:06 markiert.

Laut Cloudflare meldeten automatisierte Tests um 11:31 Anomalien, und die manuelle Untersuchung begann um 11:32, was die schnelle Umstellung von einem vermuteten Angriff auf ein Konfigurations-Rollback innerhalb von zwei Stunden erklärt.

Zeit (UTC) Status Aktion oder Auswirkung

11:05	Änderung eingespielt	Datenbank-Berechtigungsupdate führte zu doppelten Einträgen
11:20–11:28	Auswirkungen beginnen	HTTP-5xx-Anstieg, da die Bot-Datei das 200-Elemente-Limit überschreitet
13:05	Abmilderung	Bypass für Workers KV und Access reduziert Fehleroberfläche
13:37–14:24	Rollback-Vorbereitung	Verbreitung fehlerhafter Dateien stoppen, bekannte gute Datei validieren
14:30	Kern-Wiederherstellung	Gute Datei eingespielt, Kern-Traffic läuft normal
17:06	Gelöst	Nachgelagerte Dienste vollständig wiederhergestellt

Die Zahlen erklären sowohl Ursache als auch Eindämmung.

Ein fünfminütiger Wiederaufbauzyklus führte dazu, dass fehlerhafte Dateien wiederholt eingeführt wurden, als verschiedene Datenbankteile aktualisiert wurden.

Eine 200-Elemente-Grenze schützt die Speichernutzung, und eine typische Anzahl von etwa sechzig ließ ausreichend Spielraum, bis die doppelten Einträge auftauchten.

Die Grenze funktionierte wie vorgesehen, aber das Fehlen eines toleranten „Safe Load“ für interne Dateien verwandelte eine schlechte Konfiguration in einen Absturz, statt in einen sanften Fehler mit Fallback-Modell. Laut Cloudflare ist das ein zentraler Punkt, der gehärtet werden muss.

Cloudflare sagt, man werde die Validierung interner Konfigurationen verstärken, mehr globale Not-Aus-Schalter für Feature-Pipelines einführen, verhindern, dass Fehlerberichte bei Vorfällen große CPU-Ressourcen verbrauchen, das Fehlerhandling in allen Modulen überprüfen und die Verteilung von Konfigurationen verbessern.

Das Unternehmen bezeichnete dies als seinen schlimmsten Vorfall seit 2019 und entschuldigte sich für die Auswirkungen. Laut Cloudflare gab es keinen Angriff; die Wiederherstellung erfolgte durch das Stoppen der fehlerhaften Datei, das Wiederherstellen einer bekannten guten Datei und das Neustarten der Serverprozesse.

Der Beitrag How a single computer file accidentally took down 20% of the internet yesterday – in plain English erschien zuerst auf CryptoSlate.