Cloudflare WAF: Was verwalteter Schutz wirklich blockiert und was er durchlässt

Die meisten Teams aktivieren Cloudflare WAF wie die Installation eines Antivirenprogramms: Sobald es konfiguriert ist, ist das Problem gelöst. Diese Prämisse ist falsch, und der Preis, sie nicht zu verstehen, ist ein falsches Sicherheitsgefühl, das gefährlicher sein kann als überhaupt kein Schutz.

WAF ist eine wirksame Schicht gegen eine bestimmte Klasse von Bedrohungen. Gegenüber einer anderen Klasse sorgt es für Reibung, nicht für Barriere. Die Kenntnis des Unterschieds bestimmt, wie Sie das System kalibrieren und was auf Anwendungsebene erstellt werden muss.

Was verwaltete Regelsätze tatsächlich tun

Verwaltete Regeln decken die häufigsten Angriffsklassen ab: SQL-Injection, Cross-Site-Scripting, Directory Traversal, Web-Shell-Upload, Ausnutzung bekannter CVEs in gängigen Frameworks. Sie funktionieren durch Signaturabgleich – die Engine prüft die Anfrage und prüft, ob Muster mit den in den Regeln registrierten Mustern übereinstimmen.

Dieses Modell weist eine inhärente Einschränkung auf: Es basiert auf der Form der Anfrage und nicht auf deren Bedeutung für die Anwendung. Eine Regel, die ' OR 1=1 -- in einem Abfrageparameter erkennt, löst sowohl einen SQLi-Angriff als auch einen legitimen Benutzer aus, der nach SQL-Tutorials sucht. Die Regel kann nicht wissen, was dieser Parameter im Kontext Ihrer Anwendung darstellt – sie sieht nur Bytes.

Dies führt zu vorhersehbaren Fehlalarmen. In Anwendungen mit Rich-Text-Editoren stürzen Endpunkte, die HTML als legitime Eingabe akzeptieren, aufgrund von XSS-Regeln ab. APIs, die JSON mit Sonderzeichen empfangen, kollidieren mit SQLi-Regeln. Der Schutz ist real, aber nicht chirurgisch.

Was ein geduldiger Angreifer tun kann

Verwaltete Regelsätze eignen sich hervorragend gegen Massenangriffe: automatisierte Scanner, Tools wie sqlmap im Standardmodus, Skript-Kiddies, die generische Payloads auslösen. Jeder, der diese Vektoren ohne Anpassung verwendet, wird auf WAF klicken und dort aufhören.

Das andere Szenario besteht darin, dass der Angreifer weiß, welche WAF das Ziel schützt – häufig öffentliche Informationen über Header, Cookies oder Antwortverhalten. Mit diesem Wissen testet er systematisch Umgehungstechniken: ungewöhnliche Kodierung (URL-Kodierung auf mehreren Ebenen, Unicode-Normalisierung, gemischte Groß- und Kleinschreibung in SQL-Schlüsselwörtern), fragmentierte Nutzlasten in großen Körpern, Kombinationen, die die Verarbeitungsgrenzen der Engine ausnutzen.

Gegen einen entschlossenen Angreifer, der Nutzlasten für das spezifische Ziel anpasst, bedeutet WAF, dass es Arbeit bedeutet und nicht Unmöglichkeit. Dies hat immer noch seinen Wert: Wenn die Kosten eines Angriffs steigen, verringert sich die Zahl der Angreifer, die bereit sind, dafür zu zahlen. Es handelt sich jedoch nicht um ein absolutes Hindernis und es ist gefährlich, es als solches zu behandeln.

Es gibt eine Schwachstellenkategorie, in die WAF einfach nicht passt: Geschäftslogik. Wenn Ihre Anwendung einem Benutzer ermöglicht, die Daten eines anderen Benutzers anzuzeigen, indem er IDs in der URL (IDOR) manipuliert, erkennt WAF dies nicht. Die Anfrage ist formal gültig, ohne schädliche Nutzlast. Das Problem liegt in der Anwendungslogik und der einzige wirksame Schutz liegt im Code.

Stufen und was jeder Plan tatsächlich abdeckt

Der DDoS-Schutz der Schichten 3 und 4 ist in allen Plänen verfügbar, immer eingeschaltet und ohne Konfiguration: volumetrische Abschwächung am Rande, bevor der Datenverkehr Ihre Infrastruktur erreicht.

Layer 7 WAF – mit verwalteten Regeln – beginnt im Pro-Plan bei 20 $ pro Monat. Diese Stufe schaltet Cloudflare Managed Ruleset und OWASP Core Ruleset frei. Der kostenlose Plan erlaubt nur 5 benutzerdefinierte Regeln, ohne Zugriff auf verwaltete Regelsätze. Für die meisten Anwendungen mit echten Sicherheitsanforderungen ist Pro der minimal akzeptable Bodenbelag.

Die pro Regel verfügbaren Aktionen sind: Blockieren (gibt sofort 403 zurück), Herausforderung (zeigt eine JavaScript-Herausforderung an, die Bots nicht lösen können), verwaltete Herausforderung (Cloudflare entscheidet automatisch über die Stufe der Herausforderung), Protokollieren (protokolliert, ohne Maßnahmen zu ergreifen), Überspringen (überspringt bestimmte Regeln oder ganze Gruppen) und Zulassen (lässt ohne Prüfung bestehen). In der Zusammensetzung dieser Aktionen findet ein Großteil der Kalibrierung statt.

Ein Detail, das alles ungültig macht

Es gibt eine Voraussetzung, die in der ersten Dokumentation nicht offensichtlich ist: WAF funktioniert nur für DNS-Einträge mit aktivem Cloudflare-Proxy – was die Schnittstelle als „orangefarbene Wolke“ bezeichnet. Als Nur-DNS-Einträge konfigurierte Einträge (graues Symbol) verweisen direkt auf die Quell-IP. Der Datenverkehr läuft nicht über Cloudflare, daher gelten keine WAF-Regeln, keine Edge-DDoS-Abwehrmaßnahmen und keine JavaScript-Herausforderungen.

Dies betrifft Subdomains, die der Einfachheit halber als Nur-DNS-Domänen belassen wurden: Staging-Umgebungen, interne APIs, auf die von außen zugegriffen wird, Zusatzdienste. Wenn der Angreifer diese Subdomains entdeckt – und DNS-Enumerationstools machen dies trivial – hat er einen direkten Weg zum Ursprung, ohne über die WAF gehen zu müssen. Die Zuordnung Ihrer DNS-Einträge und deren Status muss Teil der Sicherheitsüberprüfung sein.

Was Ihr Team vor der Aktivierung entscheiden muss

Die Aktivierung verwalteter Regelsätze ohne Beobachtungszeitraum ist ein Rezept zum Blockieren legitimen Datenverkehrs in der Produktion. Der betriebssichere Weg beginnt mit allen Regeln im Protokollmodus: Sie sehen, was blockiert würde, ohne etwas zu blockieren, analysieren das Auslösemuster und identifizieren Fehlalarme, bevor Sie zu „Blockieren“ oder „Challenge“ wechseln.

Die wichtigste Entscheidung ist der Umgang mit Regeln, die falsch ausgelöst werden. Durch die globale Deaktivierung der Regel entsteht eine Lücke für den eigentlichen Angriff, vor dem sie geschützt ist. Die richtige Antwort ist eine Skip-Regel mit präzisem Gültigkeitsbereich: diese spezifische verwaltete Regel, auf diesem spezifischen Pfad, für diese spezifische Bedingung. Durch den geschlossenen Bereich bleibt die Abdeckung im gesamten Rest der Anwendung erhalten.

Es lohnt sich auch, die Empfindlichkeitsschwelle für das OWASP Core Ruleset im Voraus festzulegen. Es funktioniert nach der akkumulierten Punktzahl – jede Regel, die ausgelöst wird, fügt Punkte hinzu, und die Aktion wird ausgeführt, wenn die Gesamtpunktzahl einen konfigurierbaren Grenzwert überschreitet. Ein zu niedriger Grenzwert blockiert legitimen Datenverkehr. zu hoch, es verfehlt ausgefeilte Angriffe. Der Break-Even-Punkt hängt von der Art Ihrer Anwendung und dem beobachteten Verkehrsprofil ab.