Yandex Cloud Ausfall: Bots wechseln innerhalb von 24 Stunden zu anderen Hostern – Was bedeutet das für das Crawlen?

Vom 8. bis 11. Oktober 2026 verlor Yandex drei Rechenzentren: Sasovo und Wladimir wurden vollständig gestoppt, Kaluga arbeitete mit Einschränkungen. Yandex Cloud ging in den Notfallmodus und riet den Kunden direkt, eigene Notfallwiederherstellungspläne zu aktivieren. Das Interessanteste geschah danach. Cloudflare untersuchte, was mit den Bots geschah, die in dieser Cloud lebten, und stellte fest: Sie verschwanden nicht, sondern zogen innerhalb eines Tages zu anderen Hostern um. Und sie blieben an ihrem gleichen TLS-Fingerabdruck JA4 erkennbar. Für alle, die sich mit Parsing und Automatisierung beschäftigen, ist das ein seltener praktischer Versuch zu zwei Fragen: Was tun, wenn die Infrastruktur ausfällt, und warum ändert sich die „Identität“ des Bots nicht bei einem Wechsel der IP und des Hostings.

Was mit Yandex passiert ist

Laut BleepingComputer berichtete Yandex von Schäden an drei Rechenzentren durch Angriffe von Drohnen. Yandex nannte den Schuldigen nicht; die Medien, unter Berufung auf die BBC, bringen die Angriffe mit der Ukraine in Verbindung. Der Zeitrahmen ist folgender:

• 8. Oktober — Sasovo (Region Rjasan): Feuer, Standort vollständig gestoppt;
• 9. Oktober — Kaluga: Betrieb mit Einschränkungen, keine vollständige Stilllegung;
• 11. Oktober — Wladimir: vollständig gestoppt.

Auf der Statusseite von Yandex Cloud waren einige Dienste (Konsole, API, IAM, Datenbanken, S3, Kubernetes) mit Leistungsproblemen weiterhin verfügbar, Compute und AI Studio arbeiteten teilweise. Das Unternehmen schrieb, dass es keine verlässlichen Wiederherstellungszeiten nennen könne, die verbleibende Ressourcen-Konfiguration als instabil betrachte und den Kunden empfehle, alternative Notfallwiederherstellungspläne zu nutzen. Zum Zeitpunkt der Veröffentlichung von BleepingComputer (12. Oktober) gab es keine Wiederherstellungszeiten und keine Klarheit über mögliche Datenverluste.

Was Cloudflare sah: Der Traffic fiel, die Bots nicht

Am 14. Oktober veröffentlichte Cloudflare eine Analyse des Vorfalls aus der Sicht ihres Netzwerks. Die wichtigsten Zahlen:

• Am 11. Oktober fiel der Traffic aus dem Yandex-Suchnetzwerk (AS13238) um 99 % von der Norm, aus Yandex.Cloud (AS200350) um 90 %;
• 99,5 % der Anfragen aus AS13238 waren vor dem Vorfall automatisiert, wobei 93,6 % der Bot-Anfragen verifizierte Crawler von Yandex waren. Dieses Netzwerk lieferte etwa 7 % aller Bot-Anfragen aus russischen IPs;
• In Yandex.Cloud waren etwa 95 % der geschätzten Anfragen Bots, und keiner von ihnen war verifiziert. Das sind etwa 2 % des russischen Bot-Traffics;
• Der Bot-Traffic aus Yandex.Cloud sank um etwa 40 %, das Scannen von WordPress-Plugins aus diesem Netzwerk um 90 %.

Und dann das Wichtigste. Fast alle Bot-Anfragen aus Yandex.Cloud richteten sich an ein Cloudflare-Konto eines Kunden aus der Glücksspielbranche. Unmittelbar nach dem Ausfall am 8. Oktober fielen die Anfragen aus Yandex.Cloud an dieses Konto auf null — und sofort tauchten identische Anfragen aus den Netzwerken anderer russischer Hoster, Radist und Selectel, auf. Mit dem gleichen JA4-TLS-Fingerabdruck, den gleichen seltenen Pfaden und Headern und den gleichen nicht standardmäßigen User-Agent-Zeilen. Das Ergebnis nach einer Woche: Der russische Bot-Traffic zu Glücksspielkonten fiel nicht, sondern stieg — von 167,7 auf 170,1 Millionen Anfragen (+1,4 %).

Cloudflares Fazit ist klar formuliert: Die physische Infrastruktur ist statisch, während bösartige Automatisierung so aufgebaut ist, dass sie umziehen kann. Der Rückgang des HTTP-Traffics zeigt den Vorfall, bedeutet jedoch nicht, dass die Bots gestoppt wurden.

Die laute Version und die Daten: Warum „die Bots verstummten“ übertrieben war

Parallel erklärte das ukrainische Zentrum zur Bekämpfung von Desinformation (CPD), dass nach dem Schlag gegen Sasovo die Anzahl der Meldungen über verdächtige Konten auf Facebook und Telegram innerhalb eines Tages um 83,6 % gesunken sei — von 4.032 auf 660. Doch wie TechRadar analysierte, kehrte die Aktivität bereits am 10. Oktober auf 4.585 Meldungen zurück und überschritt am 11. Oktober das Niveau vor dem Schlag. Cloudflare fand keinen signifikanten Rückgang: Der Bot-Traffic aus russischen IPs zu den Endpunkten „Post, Antwort, Like“ eines sozialen Netzwerks sank nur um 5,7 %. Auch Graphika stellte keinen Verlust aktiver Konten in den beobachteten Gemeinschaften fest. Die Forscherin Renée DiResta nannte die Geschichte schön, aber eher wie eine Fiktion als eine Tatsache.

Eine Lektion für Analysten: Am 8. Oktober fielen in ganz Russland Banken, Einzelhandel, Betreiber und Medien aus, daher kann man jeglichen Rückgang der „Aktivität“ an diesem Tag nicht ohne Vorbehalte den Bots zuschreiben. Aggregierter Traffic kann leicht irreführen.

Erste Lektion: IP und Hosting sind nicht die Identität des Bots

Die Verbindung „Yandex.Cloud → Radist/Selectel“ erkannte Cloudflare nicht an den Adressen — die Adressen und ASN änderten sich vollständig. Sie erkannten sie am Verhalten und dem Fingerabdruck des Clients:

• JA4 — Hash des TLS ClientHello: Cipher Suites, Erweiterungen, Protokollversionen. Er beschreibt das Programm, nicht das Netzwerk. Das gleiche Python-Skript auf einem neuen Server gibt den gleichen JA4;
• seltene Pfade und Header — die Reihenfolge und Menge der HTTP-Header, die bei normalen Browsern nicht vorkommen;
• eigenes User-Agent — eine einzigartige Zeile, die selbst als Etikett dient.

Praktische Schlussfolgerung für legales Parsing: Ein Wechsel des Rechenzentrums oder des IP-Pools macht Sie nicht „neu“ für den Anti-Bot, wenn der gesamte Client-Stack gleich bleibt. Und umgekehrt: Wenn Ihr Crawler sich ehrlich präsentiert, sich vorsichtig verhält und nicht auf sensible Endpunkte schlägt, ist ein stabiler Fingerabdruck kein Problem. Probleme treten auf, wenn der Stack wie etwas aussieht, das es bei echten Nutzern nicht gibt: angegebener Chrome mit TLS-Fingerabdruck der Bibliothek requests, exotischer UA, nicht standardmäßige Header. Detailliert, wie diese Detektionsschicht funktioniert, haben wir in der Analyse JA4 und TLS-Fingerprinting beim Scraping beschrieben.

Beachten Sie noch ein Detail: Die Bots zogen von einem Rechenzentrum in andere Rechenzentren um. Für Cloudflare gehört das alles zur gleichen Kategorie von Hosting-ASNs, denen viele Websites im Voraus misstrauen. Ein anderes Netzwerk — das Risikoprofil bleibt dasselbe.

Zweite Lektion: Infrastruktur muss innerhalb von Stunden umgezogen werden können

Die Angreifer zogen innerhalb eines Tages um, weil ihre Automatisierung von Anfang an portabel war. Ehrliche Teams, die Preise sammeln, die Ausgabe überwachen oder Analysen durchführen, benötigen eine solche Portabilität nicht weniger. Die Empfehlung von Yandex Cloud „verwenden Sie alternative Notfallwiederherstellungspläne“ ist nur dann gut, wenn ein solcher Plan bereits vorhanden ist. Die minimale Checkliste:

1. Code und Konfigurationen — außerhalb der Cloud. Repository, Container-Images, Umgebungsvariablen sollten so gespeichert werden, dass der Parser bei einem anderen Hoster mit einem Befehl bereitgestellt werden kann.
2. Zweiter Hoster im Voraus. Ein Konto, Zahlung und ein Testserver bei einem alternativen Anbieter in einer anderen Jurisdiktion und Region. Sich am Tag des Vorfalls zu registrieren und die Überprüfung zu durchlaufen — zu spät.
3. Ausgabeschicht getrennt von Berechnungen. Wenn Anfragen an die Zielwebsites über einen Proxy-Anbieter und nicht direkt von der IP des Servers erfolgen, ändert sich durch den Umzug der Berechnungen weder das Geo noch der Typ der IP noch die Sitzungshistorie. Der Server kann umgezogen werden, aber für die Website bleiben Sie derselbe Kunde.
4. Daten und Warteschlangen — mit Replikation. Die Ergebnisse des Parsings und der Status der Aufgaben werden in einem anderen Speicher kopiert, sonst muss nach einem Vorfall von vorne begonnen werden.
5. Backup-Anbieter — wirklich anders. Der Backup-Hosting- oder Proxy-Anbieter sollte nicht die gleiche Infrastruktur unter einem anderen Markennamen sein. Wie man das bei Proxys überprüft, haben wir in dem Material über warum ein Backup-Proxy-Anbieter dasselbe Pool sein kann behandelt.
6. Übungseinsatz. Einmal im Quartal den Parser auf einer Backup-Plattform hochfahren und eine reale Aufgabe durchlaufen. Ein Plan, der noch nie getestet wurde, funktioniert in der Praxis normalerweise nicht.

Welcher Proxy-Typ was in einer solchen Situation löst

Proxys retten nicht vor einem schlechten Fingerabdruck — das zeigt das Beispiel aus der Analyse von Cloudflare. Sie entkoppeln jedoch das „Gesicht“ Ihrer Anfragen von dem, wo der Code physisch läuft:

• Residential Proxys — für Websites, bei denen Hosting-ASNs im Voraus blockiert oder mit Captchas belegt werden. Bei einem Serverwechsel bleibt der Ausgang auf den heimischen IPs des gewünschten Landes.
• Datacenter-Proxys — für APIs und loyale Websites, bei denen Geschwindigkeit und Preis wichtig sind. Diese sollten ebenfalls bei einem Anbieter gehalten werden, der unabhängig von Ihrer Cloud ist, damit ein Hosting-Ausfall nicht auch die Ausgangs-IPs mitnimmt.

Proxys sind jedoch nur eine Schicht. Wenn der TLS-Stack, die Header und das Verhalten Ihres Clients auffallen, werden sie an jeder IP erkannt, so wie die Bots, die zu Radist und Selectel umgezogen sind.

Was das für Website-Besitzer bedeutet

Cloudflare zieht auch den umgekehrten Schluss: ASN und Traffic-Volumen sind unzuverlässige Anzeichen für Bots. Die Blockierung eines „schlechten“ Netzwerks funktioniert bis zum ersten Umzug. Zuverlässiger ist es, das Verhalten zu betrachten: gemeinsame JA4-Fingerabdrücke bei verschiedenen Netzwerken, anomale Anfragefrequenzen und WAF-Regeln an sensiblen Endpunkten, unabhängig davon, woher die Anfrage kam. Die Kehrseite ist ebenfalls vorhanden: 40,5 % der Cloudflare-Kunden antworteten dem Yandex-Crawler mit dem Code 403, und der Traffic aus Yandex-Netzwerken zu Nachrichtenwebsites fiel während des Vorfalls um 44 % — das bedeutet, dass vor allem die legitime Indizierung betroffen war.

Fazit

Der Vorfall bei Yandex wurde zu einem lebendigen Test zweier einfacher Wahrheiten. Erstens: Infrastruktur kann innerhalb eines Tages verschwinden, und derjenige gewinnt, der sie innerhalb von Stunden umziehen kann — mit Code außerhalb der Cloud, einem zweiten Hoster und einer Ausgabeschicht, die nicht an den Server gebunden ist. Zweitens: Für den Anti-Bot sind Sie Ihr Client-Stack, nicht Ihre IP. Ein neues Rechenzentrum mit dem gleichen JA4 und dem gleichen User-Agent ist derselbe Bot an einer neuen Adresse. Gestalten Sie das Parsing so, dass es einen Plattformwechsel übersteht und dabei auf jeder IP gleich ordentlich aussieht.