WAF im Protokollmodus: So aktivieren Sie den Schutz schrittweise, ohne legitimen Datenverkehr zu blockieren

Es wird allgemein angenommen, dass die Aktivierung von WAF eine binäre Entscheidung ist: ob es blockiert oder nicht. Teams, die an diesem Punkt beginnen, aktivieren die verwalteten Regelsätze im Blockmodus direkt in der Produktion, gehen davon aus, dass die Regeln konservativ genug sind, und stellen dann fest, dass das Vertrags-Upload-Formular nicht mehr funktioniert, dass die Integration mit Zahlungsgateway 403 zurückgibt und dass das Support-Team Beschwerden von Kunden erhält, die sich nicht anmelden können. Die WAF hatte nicht Unrecht – kannte aber auch die Anwendung nicht.

Was der Protokollmodus bewirkt und warum er existiert

Cloudflare WAF verfügt über drei mögliche Aktionen für jede Regel: Blockieren, was 403 zurückgibt und die Anfrage beendet; Herausforderung, die den Kunden vor eine Herausforderung stellt; und Protokoll, das das Ereignis aufzeichnet, ohne den Fluss zu beeinträchtigen. Der Protokollmodus ist der einzige, der es Ihnen ermöglicht, das Verhalten von Regeln im Vergleich zum realen Datenverkehr ohne Konsequenzen für Benutzer zu beobachten.

Wenn ein Regelsatz mit einer Protokollaktion konfiguriert ist, werden alle Regeln normal ausgelöst – Header, URI, Textkörper, Abfragezeichenfolge werden ausgewertet – aber anstatt zu blockieren, protokollieren sie das Ereignis nur. Firewall-Ereignisse im Cloudflare-Dashboard erfassen jeden Auslöser: die Ursprungs-IP, den vollständigen URI, die spezifische Regel-ID und den genauen Inhalt, der die Übereinstimmung verursacht hat. Die Anfrage erreicht den Ursprungsserver unversehrt. Der Benutzer merkt nichts.

Die Bereitstellungssequenz, die Vorfälle verhindert

Der Prozess beginnt mit der Aktivierung aller verwalteten Regelsätze, wobei die Aktion auf „Protokollieren“ festgelegt ist. Der OWASP-Paranoia-Level sollte von Anfang an auf 1 gesetzt werden: Dieser Level erfasst die offensichtlichsten Angriffsmuster mit der geringsten Menge an Fehlalarmen. Das Aufsteigen auf Stufe 2 oder 3 bei der ersten Aktivierung ist fast eine Garantie für übermäßiges Rauschen, das es schwierig macht, echte Angriffe von legitimem, fehlerhaft formatiertem Datenverkehr zu unterscheiden.

Mit den Regelsätzen im Protokoll muss das Firewall-Ereignis-Dashboard täglich überprüft werden. Das Ziel besteht darin, Regeln zu identifizieren, die konsistent bei legitimen Anfragen ausgelöst werden – der gleiche URI, das gleiche Anfragemuster, die gleiche Regel. Bei einem einzelnen Schuss kann es zu Rauschen kommen; Der gleiche Auslöser bei Tausenden von Anfragen von echten Benutzern ist ein falsch positives Ergebnis, das den Datenverkehr blockiert, wenn sich die Aktion in „Blockieren“ ändert.

Wenn ein falsch positives Ergebnis identifiziert wird, besteht die Reaktion darin, eine Skip-Regel zu erstellen: eine Firewall-Regel, die die WAF anweist, Regelsätze oder bestimmte Regeln zu ignorieren, wenn Kriterien wie URI und HTTP-Methode übereinstimmen. Ein Endpunkt /api/upload, der Regel 100035 auslöst, weil er Dateien mit der Erweiterung .php in seinem Namen akzeptiert, erhält eine Skip-Regel, die diesen Pfad von der Überprüfung durch diese Regel ausschließt. Der Ausschluss ist operativ: Der gesamte andere Datenverkehr wird weiterhin ausgewertet.

Nach ein bis zwei Wochen mit den Regelsätzen im Protokoll, der Behandlung von Fehlalarmen mit Skip-Regeln und keinen neuen Auslösern für legitimen Datenverkehr ändert sich die Aktion in „Blockieren“. Das Kriterium ist Stabilität, nicht die verstrichene Zeit.

Firewall-Ereignisse genau lesen

Das Dashboard „Firewall-Ereignisse“ zeigt jedes Ereignis mit genügend Details an, um eine Entscheidung zu treffen. Zusätzlich zu IP und URI zeigt das Ereignis die Regel-ID an, die ausgelöst wurde – eine Kennung wie 949110 oder 100035, die in der Cloudflare-Dokumentation eingesehen werden kann – und die übereinstimmenden Daten, den spezifischen Teil der Anfrage, der die Übereinstimmung verursacht hat.

Dieses übereinstimmende Datenfeld verwandelt die Untersuchung von einer falsch positiven Spekulation in eine konkrete Diagnose. Wenn Regel 100035 auf POST /api/upload ausgelöst wurde und die abgeglichenen Daten filename=relatorio.php anzeigen, ist klar, dass die Regel auf den Dateinamen und nicht auf schädliche Inhalte im Textkörper reagiert. Die resultierende Sprungregel ist präzise: Sie ignoriert Regel 100035 nur für diesen Pfad. Jeder andere Endpunkt, der ein wirklich verdächtiges .php erhält, wird weiterhin ausgewertet.

Benachrichtigungsalarme für neue WAF-Ereignisse schließen den Kreis der kontinuierlichen Erkennung. Wenn Cloudflare einer zirkulierenden CVE eine neue Signatur hinzufügt, benachrichtigt die Warnung das Team – und Firewall Events zeigt an, ob die neue Regel legitimen Datenverkehr berührt, bevor es zu spät ist.

WAF Analytics und SIEM-Integration

Für Teams mit etablierten Sicherheitsabläufen können Firewall-Ereignisdaten über Logpush exportiert werden. Logpush sendet WAF-Ereignisse mit dem vollständigen Feldsatz an R2, S3, Datadog oder Splunk: Zeitstempel, IP, Land, URI, Methode, Regel-ID, durchgeführte Aktion und abgeglichene Daten. Für ein Team mit einem aktiven SOC liefern diese Daten Korrelationen, die das Cloudflare-Dashboard nicht liefert: Angriffsmuster, die von mehreren IPs gegen denselben Endpunkt im Laufe von Stunden verteilt werden, Nutzlastvariationen, die testen, welche Regel umgangen werden kann.

WAF Analytics aggregiert diese Ereignisse in einer Zeitreihe innerhalb von Cloudflare. Wenn sich die Aktion von „Protokollieren“ zu „Blockieren“ ändert, weist ein unerwarteter Anstieg der 403-Antworten im normalen Datenverkehr auf ein falsch positives Ergebnis hin, das der Beobachtungsphase entgangen ist – und die Regel-ID im Ereignis sagt Ihnen genau, was zu tun ist.

Aufbau einer betrieblichen Gewohnheit

WAF ist keine einmalige Konfiguration. Anwendungen ändern sich: Neue Endpunkte werden hinzugefügt, Integrationen von Drittanbietern führen Anforderungsmuster ein, die WAF noch nie gesehen hat, und Cloudflare aktualisiert verwaltete Regelsätze regelmäßig.

Was funktioniert, ist die Zuweisung expliziter Verantwortung: Jemand auf der Plattform oder im Sicherheitsteam überprüft wöchentlich Firewall-Ereignisse. Die Überprüfung sucht nach neuen Mustern – Regeln, die in großem Umfang ausgelöst werden, die vorher nicht auftraten, ein Anstieg der Sperrungen zu Spitzenzeiten. Wenn ein neuer Endpunkt in Produktion geht, beginnt die Beobachtungssequenz für diesen Pfad erneut: Zuerst protokollieren, Regeln für Fehlalarme überspringen, später blockieren.