Verwaltete Regeln im Vergleich zu benutzerdefinierten Regeln in WAF: Wann Sie Ihre eigenen Regeln schreiben sollten

Es besteht die allgemeine Überzeugung, dass die Aktivierung des Cloudflare Managed Ruleset und des OWASP Core Ruleset ausreicht, um eine geschützte Anwendung zu haben. Die Prämisse ignoriert, wozu diese Regelsätze entwickelt wurden – und was sie absichtlich nicht tun.

Verwaltete Regelsätze bieten einen umfassenden Schutz. Sie wurden entwickelt, um mit jeder Webanwendung zu funktionieren, von einem WordPress-Blog bis hin zu einer Zahlungs-API, ohne zu wissen, was ihre Anwendung von anderen unterscheidet. Genau das begrenzt sie.

Was verwaltete Regelsätze abdecken und wo sie Reibung verursachen

Der von Cloudflare verwaltete Regelsatz wird automatisch aktualisiert, wenn Cloudflare neue Exploit-Kits, groß angelegte Angriffssignaturen und eine aktive Ausnutzung von CVEs in beliebter Software erkennt. Für ein Team ohne eigenes Sicherheitsteam ist dies ein echter Wert – eine kontinuierliche Abdeckung ohne manuelle Wartung.

Das OWASP Core Ruleset funktioniert mit katalogisierten Angriffsklassen: SQL-Injection, XSS, File Inclusion, unsichere Deserialisierung. Das Bewertungsmodell sammelt Punkte, wenn Regeln bei derselben Anforderung ausgelöst werden, und es erfolgt eine Aktion, wenn die Gesamtsumme einen konfigurierbaren Schwellenwert überschreitet. Dieses Design reduziert Fehlalarme aus sehr sensiblen isolierten Regeln, beseitigt sie jedoch nicht.

Falsch positive Ergebnisse treten vorhersehbar in drei Kontexten auf. API-Endpunkte, die JSON mit Anführungszeichen, Apostrophen oder Klammern akzeptieren, kollidieren mit SQLi-Regeln – die Engine sieht die Form, nicht den Kontext. Verwaltungspanels mit Rich-Text-Editoren lösen XSS-Regeln aus, wenn der Benutzer legitimes HTML in einem POST speichert. Binäre Upload-Endpunkte ermöglichen textkalibrierte Körperinspektionsregeln. Bei keinem davon handelt es sich um Angriffe; Bei allen handelt es sich um legitimes Anwendungsverhalten.

Welche benutzerdefinierten Regeln ermöglichen es Ihnen?

Benutzerdefinierte Regeln basieren auf Erkenntnissen, über die verwaltete Regelsätze niemals verfügen werden: das spezifische Verhalten Ihrer Anwendung, das Profil des legitimen Datenverkehrs und die für Ihren Anwendungsfall relevanten Bedrohungen.

Die Ausdruckssprache von Cloudflare unterstützt zusammengesetzte Bedingungen mit and, or und not. Eine Sperrung nach Herkunftsland ip.geoip.country eq "RU" kombiniert mit http.request.uri.path eq "/api/register" schränkt nur den Registrierungsendpunkt ein, ohne den Rest zu berühren. Feld cf.threat_score gt 10 blockiert IPs mit schlechter Reputation, ohne dass manuelle Blacklists erforderlich sind.

Zulassungslisten für vertrauenswürdige Quellen sind ebenso wichtig wie Blockierungsregeln. Überwachungs-IPs, CI/CD und interne Operatoren müssen von allen Inspektionen ausgeschlossen werden, indem vor den anderen eine Zulassungsregel angewendet wird. Ohne dies gibt eine Integritätsprüfung 403 zurück und eine Staging-Bereitstellung bleibt bei der Ratenbegrenzung hängen – stundenlange Untersuchung eines Problems, das nicht existieren sollte.

Die Ratenbegrenzung für sensible Endpunkte gehört zu den benutzerdefinierten Regeln. Anmeldungen, Passwortwiederherstellung und OTP-Endpunkte haben ganz andere Verkehrsprofile als der Rest der Anwendung. Eine Regel, die /auth/login bis 5 Anfragen pro Minute und IP begrenzt, schützt vor Credential Stuffing, ohne einen anderen Pfad zu beeinträchtigen.

Auch das Blockieren bösartiger Scraper-Benutzeragenten passt hierher: http.user_agent contains "Scrapy" oder http.user_agent eq "" sind Filter, die ein allgemeiner Regelsatz nicht implementiert, da sie von Ihrer Entscheidung abhängen, welche Quellen ausgeschlossen werden sollen.

So beheben Sie Fehlalarme, ohne Lücken zu öffnen

Wenn ein verwalteter Regelsatz fehlerhaft ausgelöst wird, wird durch die globale Deaktivierung der Regel der Schutz für alle anderen Pfade entfernt, auf denen er funktioniert hat. Die richtige Antwort ist eine Skip-Regel mit präzisem Gültigkeitsbereich: http.request.uri.path eq "/api/content" and cf.waf.rule_id eq "100016" deaktiviert die Regel 100016 nur für diesen Pfad und behält die Abdeckung für die gesamte Anwendung bei. Der Unterschied zwischen einer chirurgischen Ausnahme und einem Loch besteht darin, den Umfang nach cf.waf.rule_id statt nach Regelgruppe zu bestimmen.

Regelkennungen erscheinen in Aktivitätsprotokollen, wenn die Regel im Protokollmodus ausgelöst wird – ein weiterer Grund, warum der Beobachtungszeitraum vor jeder Blockierung obligatorisch ist.

So kalibrieren Sie Pläne entsprechend den verfügbaren Daten

Der kostenlose Plan bietet 5 benutzerdefinierte Regeln und keinen Zugriff auf verwaltete Regelsätze. Mit 5 Regeln ist die Priorität klar: Zulassungsliste interner IPs, Blockierung durch hohe cf.threat_score, Ratenbegrenzung auf dem kritischsten Endpunkt. Der Versuch, alles mit fünf Regeln abzudecken, führt zu zu weit gefassten Regeln mit unvorhersehbaren Nebenwirkungen.

Der Pro-Plan umfasst bis zu 20 Regeln und schaltet verwaltete Regelsätze frei. Der Business-Plan erreicht 100 – was Ihnen die Erstellung unterschiedlicher Schutzprofile pro Gruppe von Endpunkten ermöglicht: öffentliche APIs mit freizügigerer Ratenbegrenzung, Verwaltungspanels mit aggressiverer Inspektion, Partner-Webhooks mit Zulassungslisten nach Quell-IP. Mit 20 Regeln treffen Sie Entscheidungen; Mit 100 macht man Politik.

Der Kalibrierungsprozess, der in der Praxis funktioniert

Die Reihenfolge der Vorgänge ist wichtiger als die spezifische Konfiguration jeder Regel. Mit der aktiven Blockierung in einer Produktionsanwendung ohne Traffic-Baseline zu beginnen, ist ein Rezept, um echte Benutzer zu stören.

Die Sequenz beginnt damit, dass alle Regelsätze sieben bis vierzehn Tage lang im Protokollmodus verwaltet werden. Das WAF-Aktivitäts-Dashboard sammelt reale Daten: Welche Regeln würden mit welcher Häufigkeit und auf welchen Pfaden ausgelöst. Mit dieser Zuordnung identifizieren Sie falsch positive Kandidaten, bevor sie zu Vorfällen werden, schreiben Überspringregeln mit dem richtigen Umfang und konfigurieren benutzerdefinierte Zulassungslisten- und Blockierungsregeln.

Nur dann ist es sinnvoll, zu Managed Challenge oder Block überzugehen, beginnend mit den Regeln mit dem geringsten Falsch-Positiv-Risiko – spezifische CVEs – und mit zunehmendem Vertrauen zu den umfassenderen Regeln (OWASP SQLi, OWASP XSS) überzugehen. Die Kalibrierung des Schwellenwerts des OWASP-Kernregelsatzes ist die letzte Entscheidung, da sie davon abhängt, die tatsächliche Verteilung der Bewertungen im Datenverkehr Ihrer Anwendung zu sehen.