Cloudflare Rate Limiting Rules, die wirklich greifen

Eine Rate-Limiting-Regel von Cloudflare greift nur, wenn sie genau den teuren Pfad trifft und ein Merkmal zählt, das der Angreifer nicht bei jeder Anfrage wechselt. Im Free-Tarif gibt es eine Regel, die pro IP-Adresse in einem Zeitfenster von 10 Sekunden zählt und Anfragen nur nach Pfad auswählen kann; ab Pro stehen zwei Regeln und Abgleich auf Query-String zur Verfügung¹. Das reicht, um eine einzelne teure Route zu schützen, solange wenige Adressen viele Anfragen senden. Es reicht nicht, wenn jede Anfrage von einer anderen Adresse kommt. Gehen Sie so vor: Pfad bestimmen, Schwelle aus dem Normalverkehr ableiten, Aktion wählen und danach in den Sicherheitsereignissen prüfen, ob die Regel auslöst.

Welche Regel Sie schreiben können, hängt vom Tarif ab, nicht von Ihrem Wunsch. Cloudflare erlaubt in Free, Pro, Business und Enterprise 1, 2, 5 und bis zu 100 Regeln; bei Enterprise hängt die Zahl vom Vertrag ab, und Rate Limiting setzt dort Application Security im Vertrag voraus¹. Pro kostet 20 US-Dollar im Monat bei jährlicher Zahlung (25 US-Dollar monatlich), Business 200 (250), jeweils pro Domain².

Zählen nach Pfad, Header, Cookie oder ASN ist laut Cloudflares Verfügbarkeitstabelle erst im Tarif Enterprise mit Advanced Rate Limiting möglich; Enterprise mit Application Security zählt wie Business nach IP¹. Je nach WAF-Plan sind einige dieser Felder nicht verfügbar, JA3/JA4 setzt Bot Management voraus¹. Cache-Ausnahme und eigener Zählausdruck gibt es ab Business¹. Das ist wichtig, weil aus dem Cache beantwortete Anfragen standardmäßig mitgezählt werden und sich das in Free und Pro nicht abschalten lässt¹³.

Beginnen Sie mit dem Pfad, den Sie als teuer gemessen haben. Ein Ausdruck für den Pfad allein, der auch im Free-Tarif funktioniert:

http.request.uri.path eq "/suche"

Ab Pro lässt sich der Query-String hinzunehmen. Cloudflare zeigt in seinen Best Practices ein Muster mit contains⁴; übertragen auf eine WordPress-Suche auf der Startseite:

http.request.uri.path eq "/" and http.request.uri.query contains "s="

Der Operator contains in einer Cloudflare-Regel prüft nur, ob eine Zeichenfolge irgendwo im Query-String vorkommt; der Ausdruck mit s= trifft daher auch Parameter wie class=. Prüfen Sie einen solchen Ausdruck gegen Ihre echten Zugriffe, bevor Sie ihn scharf schalten. Danach legen Sie die Schwelle fest. Als Beispielwert für eine Suche, die normale Nutzer vielleicht zwei- bis dreimal pro Minute aufrufen: 20 Anfragen je 10 Sekunden und IP. Die 20 Anfragen je 10 Sekunden sind ein Platzhalter; leiten Sie den Wert aus dem 99. Perzentil Ihres echten Verkehrs ab und setzen Sie ihn deutlich darüber.

Als Aktion steht Block zur Verfügung. Die Standardantwort auf eine geblockte Anfrage ist 429; einen eigenen Statuscode oder Text setzen Sie erst ab Pro⁵. Im Free-Tarif ist die Sperrdauer auf 10 Sekunden festgelegt¹. Challenge-Aktionen drosseln in Free, Pro und Business immer und erlauben keine freie Dauer³. Wenn Sie unsicher sind, ob die Schwelle echte Nutzer trifft, setzen Sie im Free-Tarif zunächst die kurze Sperre von 10 Sekunden und beobachten Sie die Sicherheitsereignisse der Zone; eine reine Log-Aktion haben wir für diese Tarife nicht bestätigt gefunden.

Drei Eigenheiten erklären, warum eine richtige Regel trotzdem Last durchlässt.

Die Zähler einer Cloudflare-Rate-Limiting-Regel sind lokal. Cloudflare schreibt: „Counters are not shared across data centers", ausgenommen Rechenzentren am selben Ort; ein globaler Zähler existiert nicht⁶. Verteilt sich ein Angriff auf viele Rechenzentren, bleibt jeder Zähler unter der Schwelle.

Die Zähler sind außerdem verzögert. Zwischen Erkennen einer Anfrage und Aktualisieren des Zählers können „up to a few seconds" liegen¹. Die ersten Anfragen einer Welle erreichen Ihren Server also immer, und die Regel verhindert nur die Fortsetzung.

Eine Rate-Limiting-Regel schützt den Origin nicht vor allem. Sie wirkt nur auf Verkehr, der über Cloudflare kommt. Wer die Origin-Adresse kennt, umgeht sie (siehe Cloudflare ist aktiv, trotzdem geht die Seite down).

Prüfen Sie nach dem Aktivieren einer Rate-Limiting-Regel die Sicherheitsereignisse der Zone: Sie sollten Treffer sehen, und die Last am Origin muss im selben Moment sinken. Tut sie das nicht, trifft der Ausdruck den falschen Pfad oder die Last kommt nicht über das Muster, das die Regel zählt.

Eine Zählung pro IP-Adresse hilft nur, solange Adressen mehrfach auftreten. In einem von uns dokumentierten Fall, einer von IT4OWL selbst betriebenen Vergleichsplattform, verteilten sich am 6. Oktober rund 470.000 filterförmige Datensätze (Stichprobe) auf rund 367.000 verschiedene Quelladressen: 1,28 Anfragen pro Adresse, 80 % der Adressen tauchten an dem Tag genau einmal auf, die lauteste sendete 69. Eine Schwelle pro Adresse, die echte Nutzer nicht trifft, löst bei solchem Verkehr nie aus. Zugleich sind Quelladressen oft Ausgänge von Mobilfunk- oder Firmennetzen, also keine Einzelpersonen; eine zu scharfe Schwelle trifft dann Unbeteiligte, auch bei der Business-Variante „IP with NAT support"¹.

Im von uns dokumentierten Fall hielt eine schmale Edge-Regel rund die Hälfte der filterförmigen Datensätze ab (50,6 %, 5. Okt. 18:00 bis 6. Okt. 16:59 UTC); die andere Hälfte änderte ihre Merkmale und erreichte den Origin. Ein Zähler, der etwas anderes zählt als die IP-Adresse, etwa Pfad, Header oder Cookie, setzt Enterprise mit Advanced Rate Limiting voraus¹. Für kleinere Tarife bleibt der Weg, die Antwort am Origin billig zu machen: Im dokumentierten Fall endeten die Fehler, als der Webserver erkannte Anfragen mit einer vorgerenderten statischen Seite beantwortete. In den folgenden rund 23 Stunden Angriff gab es einen Upstream-Fehler. Wie ein Budget für teure Pfade im Webserver aussieht, steht in Teure Endpunkte.