+48 501 250 220

Ein kleiner Shop, ein Server monatelang bei 100 Prozent, und Zehntausende Besucher pro Stunde, die keine Kunden waren

Ein WooCommerce-Shop mit 52 Produkten lud langsam oder gar nicht. Die Ursache war ein bezahltes Netz von Bots: Zehntausende Anfragen pro Stunde, jede von einer anderen Privatadresse, und jeder Bot für sich vorbildlich. Unsere Ingenieure haben den Verkehr am Rand des Netzes gestoppt. Als die Bots einen Monat später die Taktik wechselten, nahm die zweite Regel die Last in zwei Minuten weg.

Erstgespräch vereinbaren Die Leistung Absicherung von Webanwendungen
  • CPU des Shops von 926 % auf 16 %
  • 57 622 verschiedene Adressen in einer Stunde
  • Kein Kunde hat etwas bemerkt
Ein Feld aus vielen kleinen Punkten steht für die Adressen; drei Bahnen daraus enden an einer orangen Mauer mit der Beschriftung WAF, während eine Bahn von einem Laptop durch eine Lücke in der Mauer zu einer Ladenfront führt

Ein kleiner Onlineshop für Arbeitskleidung auf WooCommerce, 52 Produkte, von einem früheren Dienstleister übernommen

Ausgangslage

Nach Angabe des Inhabers bestand das Problem schon Monate, bevor der Shop zu uns kam: der Server dauerhaft bei 100 Prozent, Seiten, die sehr langsam luden, und zeitweise Fehler, weil der Server nicht rechtzeitig antwortete. Standardmaßnahmen waren versucht worden und hatten nichts geändert.

Eine Stunde Logs erzählte die Geschichte. Von 172 057 Anfragen gingen 68 110 an eine einzige Kategorieadresse mit Filterparametern, in 68 238 verschiedenen Kombinationen aus Farbe und Größe. Sie kamen von 57 622 verschiedenen Adressen, von denen die meisten zwischen einer und fünf Anfragen schickten: private Internetanschlüsse in vielen Ländern, geleitet durch ein kommerzielles Netz aus Residential Proxies. Die Browserkennung war gefälscht, und der geschätzte Transfer von etwa 90 GB am Tag hieß, dass jemand für die Operation bezahlte.

Lösung

Zuerst die Messung: Was eine Anfrage jeder Art den Server kostet. Eine statische Datei 0,65 Millisekunden, jede Anfrage an WordPress 90 bis 120 Millisekunden, eine gefilterte Produktliste 257 Millisekunden. Die statischen Dateien waren der Großteil der Anfragen und 0,4 Prozent der Kosten; die Filteranfragen waren die ganze Last.

Dann eine Regel am Rand des Netzes: Die Firewall vor dem Shop weist den Bot-Verkehr in ihrer frühesten Phase ab, bevor eine Anfrage WordPress erreicht. Eine Anfrage abzuweisen kostet etwa eine Millisekunde, eine Liste zu rendern 257. Wir erkennen den Verkehr daran, wie er sich durch den Shop bewegt, nicht daran, woher er kommt. Als die Bots einen Monat später nachzogen, stand eine zweite Regel auf Basis des Navigationsverhaltens eines echten Browsers Minuten nach der Diagnose. Jede Änderung wurde gegen echte Kunden geprüft: Filtern, Suche, Warenkorb, Bestellung und Besuche aus Suchmaschinen funktionieren wie zuvor.

Ergebnisse

Server des Shops
Von 926 % auf 16 % CPU nach der ersten Regel
Server des Shops, nachdem die Bots nachgezogen hatten
Von 905 % auf 1 % innerhalb von zwei Minuten nach der zweiten Regel
Datenbankserver
Von 123 % auf 0,01 % CPU
Filteranfragen, die den Shop erreichen
Von 68 110 pro Stunde auf einige Hundert, alle von Menschen
Am Rand abgewiesene Anfragen
Etwa 90 pro Sekunde
Änderungen, die Kunden bemerkt haben
Keine: Filter, Suche, Warenkorb und Besuche aus Suchmaschinen unverändert

So sind wir vorgegangen

  1. Messen statt raten

    Produktionslogs einer Stunde, aufgeteilt nach Anfrageart und Adresse, und die Prozessorkosten jeder Art von Anfrage einzeln gemessen.

  2. Die echte Ursache finden

    Nicht die Bilder, nicht der Code, nicht die Kunden: 68 110 Filteranfragen pro Stunde von 57 622 Adressen, jede für sich höflich.

  3. Eine Regel am Rand des Netzes

    Die Firewall vor dem Shop weist den Bot-Verkehr in ihrer frühesten Phase ab, bevor er WordPress erreicht. Die CPU des Shops fiel von 926 Prozent auf 16.

  4. Schwellen aus den Daten

    Kunden und Bots unterscheiden sich deutlich darin, wie sie die Filter benutzen; die Regel ist so gesetzt, dass kein Kunde von ihr getroffen werden kann.

  5. Eine zweite Schicht, als die Bots nachzogen

    Einen Monat später kam der Verkehr knapp unter der Schwelle der ersten Regel zurück und wich auf andere Seiten aus. Eine Regel auf Basis des Navigationsverhaltens eines echten Browsers nahm die Last innerhalb von zwei Minuten weg.

  6. Nebenwirkungen geprüft

    Filtern, Suche, Warenkorb, Bestellung und Besuche aus Suchmaschinen wurden nach jeder Änderung getestet, und der Betreiber hat schriftlich, was die Regeln tun.

Herausforderungen, die wir gelöst haben

Das meiste, was nach Schutz oder Lösung aussah, funktionierte in diesem Fall nicht.

Die Bilder waren nicht das Problem, obwohl sie der meiste Verkehr waren

Die meisten Anfragen galten statischen Dateien, also waren die Bilder der naheliegende Verdächtige. Sie kosteten 2 Prozent eines Prozessorkerns. Die ganze Last kam von Anfragen an WordPress, und jede davon, auch ein 404 oder eine Anfrage nach robots.txt, startet den ganzen Shop mit seinen Plugins.

Ein Cache hätte nicht geholfen, und er lief ohnehin nicht

Ein Cache-Plugin war installiert, und seine Konfigurationsdatei behauptete, alles sei eingeschaltet. In der Praxis lief er nicht: Es fehlten Dateien und eine Einstellung, ohne die WordPress ihn ignoriert. Wichtiger: Auch ein laufender Cache hätte nichts geändert. Ein Cache beschleunigt wiederholte Adressen, und hier war fast jede Adresse anders.

Ratenlimits und automatische Sperren konnten nicht greifen

Die Firewall begrenzt die Anfragerate je Adresse und sperrt Adressen, die Fehlerantworten sammeln. Beide Mechanismen schauen auf den Absender. Ein Bot schickte etwa drei Anfragen pro Stunde von einer Adresse, bei einem Limit von zwei pro Sekunde, und bekam jedes Mal eine korrekte Antwort. In den Augen der Firewall war er ein Mustergast. Kein Schutz auf Basis der Absenderadresse konnte hier greifen.

Die Adress-Sperrliste sah die Parameter nicht

Die Firewall kann nach Adressmuster sperren. Es stellte sich heraus, dass sie nur den Pfad vergleicht, nicht die Parameter hinter dem Fragezeichen, und der Bot-Verkehr unterschied sich genau in den Parametern. So eine Regel sieht angewendet aus und tut nichts. Wir haben das im Quellcode der Firewall gefunden, bevor sich jemand darauf verlassen hat.

Die Bots zogen innerhalb eines Monats nach

Die erste Regel wies den Verkehr nach der Form der Adresse ab. Einen Monat später war er zurück: dasselbe Volumen, fast 30 000 Adressen in zehn Minuten, genau unter der Schwelle der Regel, und von den Kategorien auf die Seiten der Produkt-Tags verlagert. Jemand beobachtete die Antworten und stimmte den Angriff ab. Ein Merkmal reicht nicht lange; Regeln müssen schwer zu umgehen sein und nicht nur den heutigen Verkehr fangen.

Das beste Merkmal steckte von Anfang an in den Daten

Die zweite Regel stützt sich auf ein Verhalten, das ein echter Browser nicht auslässt, wenn ein Kunde einen Filter anklickt. Dieses Merkmal war schon in der ersten Stunde Logs sichtbar, in 67 113 der 68 110 Anfragen. Beim ersten Mal hatten wir das auffälligste Merkmal gewählt statt des am schwersten zu fälschenden. Heute laufen beide Schichten zusammen.

Die Website sperrte sich selbst

WordPress führt seine geplanten Aufgaben aus, indem es seine eigene öffentliche Adresse aufruft. Während der Flut löste jeder Bot-Besuch diese Aufgaben aus, mehr als 1 300 Aufrufe in zehn Minuten von der eigenen Adresse des Servers. Die Firewall behandelte das als Angriff und sperrte den eigenen Server der Website für einen Tag. Mailversand und Shop-Aufgaben standen, und unsere Tests vom Server wurden abgewiesen, was für einen Moment nach einem Fehlalarm der neuen Regel aussah.

Bots zu blocken darf keine Kunden sperren

Eine abgewiesene Anfrage zählt für die automatische Sperre. Wäre die Regel zu streng gewesen, hätte ein Kunde, der im Filter „alle auswählen“ anklickt, eine Tagessperre bekommen. Die Schwellen kamen aus den Daten: Kunden wählten wenige Werte, Bots viel mehr, und die beiden Gruppen überschnitten sich nicht.

Oben ein Haus mit drei kurzen Pfeilen und einer Anzeige, deren Zeiger sich kaum bewegt; darunter ein Feld aus zwölf Häusern, ein breiter Pfeil und eine Anzeige, deren oranger Zeiger am Anschlag steht

Vorher und nachher

Messgröße Vorher Nachher
CPU des Shops, erster Vorfall 926 % (9,3 von 12 Kernen) 16 %
Filteranfragen, die den Shop erreichen 68 110 pro Stunde Etwa 360 pro Stunde, von Menschen
CPU des Shops, nachdem die Bots nachgezogen hatten 905 % 1,1 %
CPU der Datenbank 123 % 0,01 %
Am Rand abgewiesene Anfragen 0 Etwa 90 pro Sekunde
Zeit von der zweiten Regel bis zur Wirkung Etwa 2 Minuten

Was wir daraus mitnehmen

  • Messen, bevor man etwas anfasst. Die Bilder waren der meiste Verkehr und keine Last; der Cache war „an“ und tat nichts; die Limits funktionierten und waren belanglos.
  • Filter sind eine fast unendliche Zahl von Adressen. Mit 36 Farben und 11 Größen stellt die geschichtete Navigation mehr Adressen bereit, als ein Cache halten kann. Für Suchmaschinen als nicht zu indexieren markieren und mit Missbrauch rechnen.
  • Limits nach Adresse schützen nicht vor Netzen aus Residential Proxies. Jede Adresse ist höflich; nur die Summe ist ein Angriff. Der Verkehr muss daran erkannt werden, wie er sich durch den Shop bewegt.
  • Am Rand abweisen. Eine von der Firewall abgewiesene Anfrage kostet etwa eine Millisekunde, eine gerenderte Liste 257. Deshalb läuft die Regel, bevor WordPress überhaupt startet.
  • Mit der Anpassung rechnen. Die Betreiber der Bots lesen die Antworten. Eine Regel muss schwer zu umgehen sein, und eine zweite Schicht sollte bereitliegen, bevor sie gebraucht wird.

Für Shopbetreiber ist die einfache Probe diese: Wenn der Server immer beschäftigt ist und der Umsatz sich nicht geändert hat, finden Sie heraus, wer den Shop wirklich besucht.

Zwei Bahnen, deren Länge die Kosten sind: Die obere Anfrage endet nach 1 ms an einer orangen Mauer mit der Beschriftung WAF, darunter ein oranges Kreuz; die untere passiert eine gestrichelte Mauer und läuft weiter bis zu einer Ladenfront, beschriftet mit 257 ms

Verwandte Ausgangslagen

  • Website gehackt?

    Google warnt vor Ihrer Website, Besucher landen auf fremden Seiten, oder der Hoster hat das Konto gesperrt? Wir schirmen die Website ab, schließen die Lücke und bereinigen sie innerhalb von 24 Stunden ab Zugang, auch am Wochenende. Danach erhalten Sie einen schriftlichen Bericht.

  • Altsystem ohne Doku übernehmen

    Ihr System läuft, aber niemand kennt es genau. Wir erfassen Anwendung, Datenbank, Server und E-Mail, bewerten Risiken, empfehlen schriftlich den weiteren Weg und übernehmen auf Wunsch den Betrieb.

Weitere Projekte

  • Eine Punkteskala mit gestrichelter Schwelle: Der Phishing-Umschlag wandert in einem orangen Bogen über die Schwelle

    Ein Spamfilter, der lief, aber nicht schützte

    Dienste liefen, die Konfiguration war gültig, im Systemstatus stand kein Fehler. Trotzdem landete Phishing im Posteingang, während Newsletter von Partnern im Spam lagen. Unsere Ingenieure haben gemessen, welche Erkennungsmechanismen tatsächlich ansprangen, die Ursachen behoben und drei Monate später eine Regression gefunden und behoben, die sich nur stundenweise zeigte.

  • Vier Briefumschläge passieren die Tore SPF, DKIM und DMARC, jeweils orange abgehakt, auf dem Weg in den Posteingang

    E-Mail-Zustellbarkeit für vier Firmendomains

    Ein Mailserver für vier Firmendomains signierte nichts, veröffentlichte keine DMARC-Richtlinie und wurde von Microsoft abgewiesen. Unsere Ingenieure haben ihn geprüft, die Änderung an einer Domain erprobt und in Gruppen ausgerollt. Das Ergebnis: Alle drei Prüfungen bestehen bei Gmail, die Microsoft-Sperre ist aufgehoben, und die Nutzer haben nichts bemerkt.

In 20 Minuten klären wir, welcher erste Schritt zu Ihrem System passt

Sie schildern Ziel und Stand, wir sagen offen, ob und wie wir helfen können. Antwort innerhalb eines Werktags, unverbindlich.

Erstgespräch vereinbaren So arbeiten wir
Telefon (Deutsch, Polnisch, Englisch) +48 501 250 220
E-Mail E-Mail

Erreichbar: Montag bis Freitag, 9:00 bis 17:00 Uhr (MEZ); Support und Notfälle rund um die Uhr (24/7)