WAF + Ratenbegrenzung + Bot-Management: der Dreiklang des Kantenschutzes

Die häufigste Annahme von Teams, die Cloudflare WAF gerade aktiviert haben, ist, dass die Anwendung jetzt geschützt ist. Diese Schlussfolgerung ist technisch falsch – nicht weil WAF nicht funktioniert, sondern weil die Angriffe, die es blockiert, nur eine Teilmenge der Angriffe sind, die Sie erhalten. Die anderen beiden Untergruppen verfügen über unterschiedliche Produkte mit völlig unterschiedlicher Erkennungslogik, und die drei werden selten von Anfang an gemeinsam konfiguriert.

Was jede Ebene tatsächlich sieht

Der klarste Weg, die Aufteilung zu verstehen, besteht darin, über drei Dimensionen der Anfrage nachzudenken: was sie enthält, wie viele eintreffen und wer sie sendet.

WAF bearbeitet Inhalte – prüft die Anforderungsnutzlast und prüft, ob sie mit bekannten Angriffsmustern übereinstimmt. Eine ' OR 1=1 -- in einem Abfrageparameter, ein Skript-Tag in einem Formularfeld, eine ../../../etc/passwd-Sequenz in einem Pfad: Dies sind Signaturen, die die Engine erkennt und blockiert. Die WAF ist in der Que-Dimension chirurgisch und in den anderen beiden Dimensionen blind.

Die Geschwindigkeitsbegrenzung wirkt sich auf die Geschwindigkeit aus. Es spielt keine Rolle, was die Anfrage enthält – wenn eine IP innerhalb von zehn Sekunden 50 Anmeldeversuche sendet, stimmt etwas nicht. WAF kann dies nicht erkennen, da jede einzelne Anfrage formal gültig ist: Die SQL-Abfrage ist korrekt, es liegt keine schädliche Nutzlast vor, die HTTP-Anfrage würde von jedem Server ohne Widerspruch akzeptiert werden. Das Problem ist nicht das Format, sondern die Häufigkeit.

Bot Management basiert auf der Verhaltensidentität. Ein hochentwickelter Bot, der die Intervalle zwischen Anfragen zufällig anordnet, einen rotierenden IP-Pool verwendet und die Raten innerhalb der in der Ratenbegrenzung konfigurierten Grenzen hält, durchläuft die ersten beiden Schichten ohne Reibung. Was diese Art von Datenverkehr liefert, ist der Verhaltens-Fingerabdruck: Navigationsmuster, die es in menschlichen Sitzungen nicht gibt, Fehlen von Mausereignissen vor der Übermittlung, Anforderungssequenzen ohne die Hilfsressourcen, die ein echter Browser laden würde, Verwendung von TLS-Fingerabdrücken, die mit Automatisierungsstapeln verknüpft sind. Das Bot-Management bewertet jede Sitzung in dieser Verhaltensdimension und reagiert auf die Bewertung, unabhängig von Nutzlast und Geschwindigkeit.

Wie Credential Stuffing die WAF durchläuft und warum sich Rate Limiting durchsetzt

Der Angriff, der die Notwendigkeit der drei Schichten am besten verdeutlicht, ist Credential Stuffing mit kontrollierter Kadenz. Der Angreifer verfügt über eine Liste geleakter Anmeldeinformationen von anderen Diensten und testet jedes Paar mit dem Anmeldeendpunkt Ihrer Anwendung – nicht in Schüben, sondern methodisch mit 3 bis 5 Versuchen pro Minute und IP. Es verwendet private Proxys zur Verteilung der Versuche und stellt sicher, dass keine einzelne IP die offensichtlichen Grenzen überschreitet.

Aus Sicht der WAF ist dieser Angriff unsichtbar. Die Anmeldeanfrage ist ein POST mit E-Mail- und Passwortfeldern, der strukturell mit dem identisch ist, was ein legitimer Benutzer senden würde. Das falsche Passwort ist keine böswillige Nutzlast – es handelt sich lediglich um Text, der die Authentifizierung fehlschlägt. Es gibt keine Signatur, die WAF erkennen kann.

Mit Rate Limiting konfigurieren Sie eine Regel auf Endpunkt /login mit einem Zeitfenster und einer Begrenzung der Versuche pro IP. Fünf Anfragen in zehn Sekunden lösen Block aus. Drei Anfragen in fünfzehn Minuten am Passwort-Wiederherstellungsendpunkt, dito. Der Angreifer, der Ihren Bot so kalibriert hat, dass er unter diesem Schwellenwert liegt, kommt immer noch durch, aber Sie haben die billigste Ebene des Credential Stuffing eliminiert – die Skripte, die einfach ohne Rhythmuskontrolle ausgelöst werden.

Was Rate Limiting nicht löst, ist, dass der Angreifer es auf genügend IPs verteilt, um bei jeder IP unter dem Limit zu bleiben. Hier kommt Bot Management ins Spiel: Selbst wenn jede einzelne IP nur zwei Versuche unternimmt, weist der Verhaltensscore der Sitzung auf eine Automatisierung hin.

Die Produktarchitektur und was jeder Plan freischaltet

Rate Limiting ist ein von WAF getrenntes Produkt – es handelt sich nicht um Regeln innerhalb desselben Systems, sondern um Systeme mit unabhängiger Logik und Konfigurationen. Diese Unterscheidung ist bei der Konfiguration wichtig, da Teams, die es gewohnt sind, nur mit WAF-Regeln zu arbeiten, oft an der falschen Stelle in der Benutzeroberfläche nach Rate Limiting suchen.

Zu den in der Ratenbegrenzung verfügbaren Kontrolldimensionen gehören IP, Kombination aus IP und Pfad, spezifisches Cookie und Benutzeragent. Die Aktionen sind „Blockieren“, „Herausfordern“ und „Protokollieren“, wobei „Protokollieren“ dem Überwachungsmodus von WAF entspricht und zum Kalibrieren von Schwellenwerten vor der Aktivierung der Blockierung in der Produktion nützlich ist.

Der kostenlose Plan von Cloudflare ermöglicht eine einzige Rate-Limiting-Regel. Pro (20 $/Monat) umfasst bis zu fünf Regeln. Das Geschäft stoppt einhundert. Enterprise entfernt das Regellimit und schaltet das vollständige Bot-Management frei, einschließlich Zugriff auf cf.bot_management.score als Variable in Regelausdrücken – eine Zahl zwischen 0 und 99, wobei niedrigere Werte auf mehr automatisierten Datenverkehr hinweisen.

Bei Pro ist das Bot-Management-Äquivalent der Super-Bot-Kampfmodus: eine vereinfachte Einstellung, die automatisierte Bots blockiert, möglicherweise automatisierte Bots herausfordert und verifizierten Datenverkehr durchlässt. Sie greifen nicht auf die numerische Bewertung zu und schreiben keine darauf basierenden Regeln, aber die Abdeckung gegen die gängigsten Bot-Kategorien ist aktiv.

Was die Pro-Plan-Kombination in der Praxis abdeckt

Für 20 US-Dollar pro Monat kann eine Webanwendung mit minimaler Aufmerksamkeit für die Konfiguration den größten Teil der automatisierten Angriffsfläche abdecken. WAF mit von Cloudflare verwalteten Regelsätzen im Blockmodus für OWASP Level 1 fängt SQLi, XSS, Pfaddurchquerung und die Ausnutzung bekannter CVEs ab. Die fünf Ratenbegrenzungsregeln decken kritische Endpunkte ab: Anmeldung mit einem Limit von fünf Anfragen in zehn Sekunden pro IP, Passwortwiederherstellung mit drei Anfragen in fünfzehn Minuten, Kontoregistrierung mit zehn Anfragen in einer Stunde, Zahlungsendpunkt mit zehn Anfragen in einer Stunde und API-Root mit einhundert Anfragen pro Minute. Der aktive Super-Bot-Kampfmodus blockiert die Anzahl der Bots, die nicht über genügend Raffinesse verfügen, um ihr Verhalten zu verschleiern.

Was diese Kombination nicht abdeckt, sind Bots mit wirklich menschlichem Verhalten – Sitzungen, die mit plausibler Geschwindigkeit surfen, mit synthetischen, aber überzeugenden Maus- und Tastaturmustern und Heim-IPs mit sauberen Verlaufsdaten. Dieser Grad an Raffinesse ist für den Angreifer teuer und selten bei Angriffen, die auf Anwendungen abzielen, bei denen es sich nicht um hochwertige Ziele handelt. Für die meisten Webanwendungen ist die in Pro verbleibende Lücke akzeptabel.

Wo ist eine Skalierung auf Business oder Enterprise sinnvoll?

Die Entscheidung für ein Upgrade ist eine Gleichung von Risiko und Kosten, nicht von technologischem Ehrgeiz. Das Geschäft rechtfertigt den Sprung, insbesondere wenn Sie mehr als fünf Ratenbegrenzungsregeln benötigen – eine Anwendung mit Dutzenden sensiblen Endpunkten wird das Pro-Limit schnell erschöpfen. Einhundert Regeln in Business lösen dieses Problem, ohne dass die Enterprise-Investition erreicht wird.

Unternehmen sind dann sinnvoll, wenn das Bedrohungsprofil Angreifer umfasst, die die vereinfachte Erkennung umgehen können: ausgefeilter Finanzbetrug, Wettbewerber, die mit Bots, die menschliches Verhalten nachahmen, systematisch Preise kürzen, oder stark verteiltes Credential Stuffing gegen einen hochwertigen Dienst. Durch den Zugriff auf den numerischen Score von Bot Management können Sie Regeln mit einer Granularität erstellen, die der Super Bot Fight Mode nicht bietet – blockieren über 30, herausfordern zwischen 30 und 60, zulassen über 60, mit zusätzlicher Logik über Pfad oder HTTP-Methode. Diese Aussagekraft ist mit Kosten verbunden, und die Kosten sind nur dann gerechtfertigt, wenn das geminderte Risiko verhältnismäßig ist.