Browser-Flood-Angriff: Wie er funktioniert – und wie Sie Ihre Abwehr dagegen prüfen

Die meisten Abwehrmechanismen gegen Layer-7-DDoS-Angriffe suchen nach etwas, das ein echter Browser nie tun würde. Ein fehlender Header. Ein TLS-Fingerprint, den kein ausgelieferter Chrome-Build erzeugt. Ein Client, der das HTML anfordert und das Stylesheet danach nie abholt. Wer diese Lücke findet, hat einen Ansatzpunkt.

Ein Browser-Flood schliesst diese Lücke. Er steuert einen echten Chromium-Tab: Der lädt Ihre Seite, parst das HTML, holt jedes Stylesheet, jedes Skript und jedes Bild, das die Seite anfordert, führt Ihr JavaScript aus, löst Ihre Analytics aus und scrollt anschliessend. Nichts daran ist gefälscht, also gibt es auch keine Lücke zu finden. Hier hat die Frage «Ist das ein echter Nutzer?» keine saubere Antwort mehr – und hier muss Ihre Bot-Mitigation beweisen, was sie leistet.

Dieser Beitrag gehört zu einer Serie über die zehn Simulationstypen, die Obsidio durchführt. Sie setzen an ganz unterschiedlichen Stellen an – deshalb braucht ein Testprogramm Abdeckung über alle Kategorien hinweg und nicht Volumen in einer einzigen. Wie die Typen zusammengehören, erklärt unser Leitfaden DDoS-Schutz testen.

Was ein Browser-Flood tatsächlich macht

Die Simulation lädt die Ziel-URL immer wieder mit voller Browser-Semantik. Nicht nur das Hauptdokument, sondern den gesamten Baum an Sub-Ressourcen: HTML, CSS, JavaScript, Bilder und jeden XHR- oder Fetch-Aufruf, den die Seite absetzt, sobald ihre Skripte laufen. Auf Workern mit WebView-Laufzeitumgebung steuert Obsidio über puppeteer-core.connect() einen echten Chromium-Tab und überlässt es der Seite, jede Anfrage zu stellen, die ein Browser von sich aus stellen würde.

Genau darin liegt der Unterschied zum HTTP-Flood: Dort ist eine Anfrage etwas, das das Werkzeug zusammengesetzt und abgeschickt hat. Hier ist eine Anfrage etwas, das der Browser von sich aus angefordert hat. Nach jedem Seitenaufruf führt der Worker eine gewichtete Aktion auf der Seite aus: in der Hälfte der Fälle scrollen, in drei von zehn Fällen klicken, sonst warten. Die Session in Ihren Analytics hat einen Page View, eine Verweildauer und eine Interaktion, weil alle drei tatsächlich stattgefunden haben.

Stellen Sie sich statt Bots, die auf einen einzelnen Endpunkt einhämmern, einen Raum voller unauffälliger Menschen vor, die Ihre Startseite immer wieder öffnen, scrollen, Links anklicken und Ihre Skripte ausführen.

Welche Ihrer Schutzmassnahmen das hätte auffangen müssen

Es lohnt sich, die ganze Kette durchzugehen, denn die Antwort liegt hier selten bei der Massnahme, an die man zuerst denkt.

Bei einem langsamen Angriff bleibt diese dritte Zone stumm. Hier schlägt dagegen alles an – die Frage ist nur, ob es innerhalb der ersten Stunde jemand richtig deutet.

Zwei Ausführungspfade, und warum sie nicht austauschbar sind

Ein Browser-Flood läuft auf einem von zwei Wegen, und zu wissen, welcher Ihren Bericht erzeugt hat, ist wichtiger als jeder Parameter im Formular.

• Der echte Browser-Pfad. Steht die WebView-Laufzeitumgebung zur Verfügung, läuft genau ein Chromium-Tab pro Worker, gesteuert über das DevTools-Protokoll. Jede gemeldete Anfrage ist eine Sub-Ressource, die der Browser geladen hat. Die Einstellungen für parallele Schleifen und Keep-Alive bleiben hier wirkungslos, weil der Browser seine Verbindungen selbst verwaltet.
• Der HTTP-Fallback. Fehlt diese Laufzeitumgebung, fällt die Simulation auf einen parallelen Pool einfacher GET-Anfragen gegen die Haupt-URL zurück, standardmässig zwanzig Schleifen pro Worker, mit Verbindungswiederverwendung. Keine Sub-Ressourcen, kein JavaScript, keine Aktionen auf der Seite. Eine vernünftige Rückfallebene – aber ein anderer Test: Er kann Ihnen nicht sagen, wie Ihre Bot-Mitigation echten Browser-Verkehr bewertet.

Jeder Worker hält eine laufende Chromium-Instanz, und Browser verbrauchen viel Arbeitsspeicher. Ein Browser-Flood setzt deshalb auf Realitätsnähe statt auf reines Volumen – gegenüber moderner Abwehr am Netzrand ist das der bessere Kompromiss.

Die Abgrenzung zu den benachbarten Typen ist sauber. Ein HTTP-Flood schickt Methode, URL und Body genau so, wie sie konfiguriert wurden, und zielt auf Ihren Verarbeitungspfad für Anfragen. GoldenEye erzwingt den Weg zum Ursprungsserver, indem er zufällige Cache-Buster-Parameter anhängt, damit der Cache am Netzrand nicht antworten kann. Ein Browser-Flood braucht keinen dieser Kniffe: Er fordert genau die Ressourcen an, die die Seite wirklich braucht, der Cache beantwortet davon, was er kann, und der Rest kommt am Ursprungsserver an – wie bei einem echten Besucher.

Wie man einen Layer-7-DDoS-Angriff mit echten Browsern abwehrt

Misstrauen Sie jedem, der hier eine einzige Antwort anbietet, uns eingeschlossen. Diesen Verkehr von echten Nutzern zu unterscheiden ist die ganze Schwierigkeit; jede Massnahme weiter unten bleibt deshalb unvollständig. Was folgt, ist das, was die Hersteller dokumentieren – einschliesslich der Grenzen, die sie selbst einräumen.

• Bot-Management: wissen, was es leistet. Cloudflares Bot-Score entsteht überwiegend aus Machine Learning über Header, Session-Merkmale und Browser-Signale, ergänzt um Heuristiken für bekannte Fingerprints. Er ist hier Ihre stärkste Massnahme – und liefert eine Wahrscheinlichkeit, kein Urteil. Cloudflare benennt die Grenzen offen: Die erste Anfrage eines neuen Clients enthält in der Regel keine Daten aus den JavaScript Detections, und die JavaScript Detections garantieren keinen bestimmten Bot-Score.
• Challenges: wissen, was sie prüfen. Eine Managed Challenge wählt ihren Typ anhand der Signale, die der Browser mitbringt. Eine nicht-interaktive Challenge löst der Browser, indem er das eingeschleuste JavaScript verarbeitet, meist in unter fünf Sekunden und ohne menschliches Zutun. Sie filtert damit Clients aus, die kein JavaScript ausführen können. Einen Browser unter Software-Steuerung von einem Browser unter menschlicher Bedienung unterscheidet sie nicht. Interaktive Challenges brauchen einen Menschen – Cloudflare rät davon ab, sie zum Standard zu machen.
• Wissen, was Ihr Schwellenwert für den Score bewirkt. reCAPTCHA v3 liefert für jede Anfrage einen Score, ohne den Nutzer zu behelligen; Google empfiehlt, im Hintergrund zu reagieren, statt Verkehr zu blockieren. Ein vernünftiger Rat – der die Entscheidung zu Ihnen verschiebt: Irgendjemand muss aufgeschrieben haben, was jedes Score-Band auf jeder Route auslöst.
• Rate Limiting an etwas Besserem festmachen als an einer IP-Adresse. Die Rate-Limiting-Regeln von Cloudflare können statt der Absenderadresse einen Cookie-Wert, einen Header-Wert oder einen JA3- oder JA4-TLS-Fingerprint zählen. Das ist stärker – mit dem Vorbehalt, dass ein echtes Chromium einen echten Chromium-Fingerprint mitbringt.
• So cachen, dass Ihr Ursprungsserver nur beantwortet, was nur er beantworten kann. Die standardmässig von Cloudflare gecachten Typen decken CSS, JS und die gängigen Bildformate ab; HTML und JSON sind ausgenommen. Der Grossteil eines Browser-Floods erreicht Sie also nie – die Dokumentrate und die API-Rate schon. Lässt sich Ihr HTML gefahrlos am Netzrand cachen, verändert das diesen Angriff grundlegend. Wenn nicht, dimensionieren Sie Ihren Ursprungsserver für die Dokumentrate; und Sie müssen diese Zahl vorher kennen.

Eines behaupten wir nicht: In keiner Herstellerdokumentation, die wir gefunden haben, steht, dass irgendeine einzelne Massnahme einen von Software gesteuerten echten Browser zuverlässig von einem von Menschen bedienten unterscheidet. Behauptet ein Hersteller das von seiner, ist das eine Aussage, die man prüfen sollte, und keine, die man abheftet.

Was Sie selbst prüfen können, und wo das Ergebnis täuscht

Lesen Sie die Konfiguration. Welcher Bot-Management-Modus aktiv ist, was jedes Score-Band auslöst, ob Challenges die relevanten Pfade abdecken und was Ihre Cache-Regeln mit HTML machen. Das sagt Ihnen, was die Einstellungen behaupten – nicht, wie sie echten Browser-Verkehr bewerten.

Proben Sie die Triage, nicht die Alarmierung. Das Problem ist hier die Deutung, nicht das Ausbleiben von Alarmen. Zeigen Sie Ihrem Pikettdienst eine Grafik mit vierzigfachem Verkehr bei normalen Fehlerraten und fragen Sie ihn, was er tun würde. Das kostet eine Stunde und keine einzige Anfrage.

Fahren Sie einen Lasttest gegen die Staging-Umgebung, mit Freigabe aus dem Change Management, auf Infrastruktur, die Ihnen gehört. Legitim und nützlich – und von allen Angriffstypen dieser Serie ist dies der, bei dem eine billige Prüfung am weitesten in die Irre führt.

Ein synthetischer Lastgenerator schickt die Anfragen, die Sie ihm auftragen: eine Liste von URLs, in der Rate Ihrer Wahl, mit einem eingetippten User-Agent-String. Er parst Ihr HTML nicht, um herauszufinden, was die Seite überhaupt braucht. Er führt Ihr JavaScript nicht aus, setzt also nie die XHR-Aufrufe ab, von denen Ihr Dashboard abhängt, und er erzeugt keines der Browser-Signale, auf die jede der oben genannten Erkennungen angewiesen ist.

Das Ergebnis ist deshalb in zwei Richtungen zugleich falsch. Bei der Erkennung fällt es zu pessimistisch aus: Ihr synthetischer Client ist genau das, wofür Bot-Management existiert, er wird erkannt, und Sie schliessen daraus, gegen etwas geschützt zu sein, das Sie nie geschickt haben. Bei der Kapazität fällt es zu optimistisch aus: Sie haben Ihren Ursprungsserver an Anfragen bemessen, die Ihren Rendering-Pfad nie berührt haben, während der echte Angriff sechzig Anfragen stellt, wo Sie eine geprüft haben – und die teure sechzigste ist eine Datenbankabfrage.

Zwei Fehler in entgegengesetzte Richtungen: Kein anderer Test dieser Serie täuscht ein Bestehen so gründlich vor. Das Ergebnis gilt als bestanden, beide Hälften der Begründung sind falsch, und nichts im Bericht weist darauf hin.

Wie Obsidio einen Browser-Flood testet

Die Autorisierung kommt vor dem Verkehr. Die Domain-Inhaberschaft wird per DNS-TXT-Eintrag verifiziert, bevor auch nur eine einzige Anfrage verschickt wird; Durchläufe steigern die Last schrittweise, statt bei Volllast zu beginnen, und jeder Durchlauf lässt sich im laufenden Betrieb abbrechen.

Die Last kommt von über 100’000 weltweit verteilten echten Geräten – echte Hardware in echten Endkundennetzen, rechtmässig und mit Zustimmung der Nutzer eingebunden. Realitätsnähe ist kein Trick, um Ihre Massnahmen zu umgehen; sie ist der einzige Weg herauszufinden, was diese Massnahmen tun, wenn der Verkehr echt ist. Eine Abwehr, die nur gegen offensichtlich synthetischen Verkehr validiert wurde, ist nicht validiert.

Worauf Sie während des Zeitfensters achten sollten:

• Trennen Sie Ihre Dokumentrate von der Gesamtanfragerate. Gecachte Sub-Ressourcen dominieren die Summe. Die Zahl, die einen Ausfall vorhersagt, sind ungecachte Dokumentanfragen pro Sekunde am Ursprungsserver.
• Beobachten Sie die Datenbank, nicht die Web-Schicht. Die Grenze liegt meist bei der Sättigung des Connection-Pools und bei der Latenz der Abfragen. Behalten Sie Cache-Trefferquote und Skalierungskosten daneben im Blick.
• Halten Sie fest, wie das Bot-Management entschieden hat. Nicht nur, ob Anfragen blockiert wurden, sondern auch die Verteilung der Scores und die ergriffene Massnahme.

Bleiben Sie realistisch, was ein Bericht belegen kann. Obsidio misst, wie Ihr Netzrand reagiert hat und wie sich die Verbindungszahlen verhalten haben, denn das ist von ausserhalb Ihres Perimeters sichtbar. Ob Ihr SIEM etwas korreliert hat, ob ein Alarm den richtigen Pikettdienst erreicht hat und ob die Person am anderen Ende den richtigen Schluss gezogen hat: Diese Antworten stehen nur in Ihren eigenen Konsolen. Lassen Sie während des Durchlaufs jemanden davorsitzen, denn diese Hälfte lässt sich später nicht rekonstruieren.

Stärke wird bewiesen, nicht versprochen. Ein Browser-Flood fragt nicht, ob Sie Verkehr absorbieren können. Er fragt, ob Sie den Unterschied erkennen – und ob es überhaupt jemandem auffiele, wenn nicht.

Wo der Browser-Flood in ein Testprogramm gehört

Der Browser-Flood gehört mit HTTP-Flood, GoldenEye und Apache Killer zur Kategorie der Floods auf der Anwendungsschicht, und zwar an deren realistischem Ende. Am nächsten verwandt ist ihm ein Typ aus einer anderen Kategorie: Puppeteer Script, die andere Simulation, die bis in Ihre Datenbank reicht, führt ein von Ihnen geschriebenes Skript in einem echten Browser aus und belastet damit einen einzelnen Ablauf, etwa einen Login. Ein Browser-Flood fragt, was passiert, wenn viele echte Browser Ihre Seite laden. Puppeteer Script stellt dieselbe Frage für einen einzelnen Ablauf.

Keiner der beiden ersetzt die übrigen. Ein HTTP-Flood konzentriert die Last auf Ihren Verarbeitungspfad für Anfragen, ohne den Overhead eines Browsers. Slowloris und RUDY erreichen Ihre Applikation gar nicht erst. Entscheidend ist die Abdeckung über alle zehn Simulationstypen hinweg, nicht das Volumen in einem davon.

Für regulierte Institute muss der Test ausserdem einen Nachweis hinterlassen. Obsidio erstellt kryptografisch attestierte Berichte, bei denen jede nachträgliche Änderung erkennbar ist, zugeordnet zu FINMA, DORA und NIS2 und erzeugt in Trusted Execution Environments – am Ende steht ein Beleg, den Sie ablegen können, und kein Screenshot, für den Sie bürgen müssen.

Um den Prüfumfang für eine autorisierte Browser-Flood-Simulation gegen Ihre eigene Infrastruktur festzulegen, sehen Sie sich die Obsidio-Plattform an oder nehmen Sie Kontakt auf. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.