WAF einführen: Die praktische Checkliste für Auswahl, Test und Betrieb

Eine WAF sollte nicht direkt mit einem möglichst großen Regelpaket in den Blockiermodus gehen. Der belastbare Weg beginnt mit dem Datenpfad, den kritischen Anwendungsabläufen und einer messbaren Ausgangslage. Danach folgen Tests im Beobachtungsmodus, eng begrenzte Ausnahmen, eine stufenweise Aktivierung und ein Rollback, das vor der ersten Blockierregel praktisch erprobt wurde.

Die WAF-Checkliste in 90 Sekunden

• Schutzbedarf, Anwendungen, APIs, Hostnamen und verantwortliche Personen sind benannt.
• Es ist klar, ob die WAF nur eigene Regeln oder zusätzlich gepflegte Managed Rules liefern muss.
• Der vollständige Anfragepfad einschließlich TLS-Endpunkt, Proxy-Kette und möglichem direkten Ursprungspfad ist dokumentiert.
• Login, Suche, Upload, Webhooks, API-Aufrufe, Checkout und Administration sind als kritische Abläufe erfasst.
• Größenlimits, unterstützte Protokolle und das Verhalten bei Störungen sind getestet, nicht nur im Datenblatt gelesen.
• Neue Regeln können beobachten beziehungsweise protokollieren, bevor sie blockieren.
• Regel-ID, Aktion, Anwendung und Zeitpunkt eines Treffers sind auswertbar.
• Ausnahmen haben einen engen Geltungsbereich, einen Grund, eine verantwortliche Person und einen Prüftermin.
• Blockierregeln werden einzeln oder in kleinen Gruppen aktiviert.
• Technische und fachliche Signale für einen Rollback sind definiert.
• Änderungen und Regelversionen lassen sich nachvollziehen und zurücknehmen.
• Die WAF wird als zusätzliche Schutzschicht betrieben, nicht als Ersatz für sichere Softwareentwicklung, Tests oder Schwachstellenbehebung.

Das BSI empfiehlt, eine WAF auf die konkrete Webanwendung oder den Webservice anzupassen und ihre Konfiguration nach Anwendungsupdates erneut zu prüfen. OWASP weist ebenfalls darauf hin, dass diese Anpassung erheblichen Aufwand verursachen kann und mit Änderungen an der Anwendung gepflegt werden muss. Eine WAF ist damit kein einmal aktiviertes Kästchen, sondern ein dauerhaftes Betriebsobjekt.

1. Vor der Produktauswahl: das Schutzziel festlegen

„Wir brauchen eine WAF“ ist noch keine Anforderung. Zuerst muss feststehen, welches Problem sie im eigenen System lösen soll. Typische Ziele sind:

• bekannte Angriffsmuster vor der Anwendung erkennen oder blockieren;
• besonders kritische Pfade mit eigenen Regeln begrenzen;
• kurzfristig eine konkrete Schwachstelle abschirmen, bis der Code korrigiert ist;
• nicht deklarierte API-Routen oder Methoden erkennen;
• automatisierten Missbrauch an Login-, Such- oder Formularrouten begrenzen;
• Sicherheitsentscheidungen für Betrieb und Vorfallanalyse nachvollziehbar machen.

Diese Ziele brauchen unterschiedliche Funktionen. Ein gepflegtes Managed Ruleset hilft bei generischen Angriffsmustern. Eine Custom-Rule-WAF eignet sich für bekannte Pfade, Methoden, Header oder Quellen. Ein positiver API-Schutz erlaubt nur deklarierte Routen, Methoden und gegebenenfalls Schemas. Rate Limits begrenzen Volumen, erkennen aber nicht automatisch den Inhalt eines Angriffs.

Eine einzelne Produktbezeichnung deckt diese Fähigkeiten nicht verlässlich ab. Deshalb gehört zu jeder Anforderung ein Test, den der Anbieter in der späteren Zielarchitektur bestehen muss.

Geplanter Rollout oder akuter Vorfall?

Für eine normale Einführung gilt: erst beobachten, dann gezielt blockieren. Bei einem laufenden Angriff kann eine sofortige, eng begrenzte Blockierregel trotzdem richtig sein. Diese Notfallregel braucht von Beginn an eine verantwortliche Person, einen Gültigkeitszeitraum, beobachtbare Nebenwirkungen und einen Rückfallpfad. Eine unter Zeitdruck erstellte Regel darf nicht unbemerkt zur dauerhaften Produktionskonfiguration werden.

2. Auswahlkriterien mit belastbarem Nachweis

Die folgende Entscheidungstabelle trennt Produktversprechen von überprüfbaren Eigenschaften:

Nicht jede Organisation braucht in jeder Zeile die umfangreichste Lösung. Sie braucht aber für jede relevante Zeile eine bewusste Entscheidung. Wer zum Beispiel Managed Rules voraussetzt, sollte Update-Frequenz, Regelversionen, Ausnahmen und das Verhalten bei einem Ruleset-Upgrade prüfen. Wer nur wenige, anwendungsspezifische Regeln benötigt, sollte nicht für eine vermeintliche Funktionsbreite bezahlen, die im Betrieb niemand auswertet oder pflegt.

3. Den Datenpfad vor den Regeln prüfen

Eine korrekt konfigurierte Regel hilft wenig, wenn ein Angreifer den geschützten Hostname umgehen und den Ursprung direkt ansprechen kann. Vor dem ersten Regeltest müssen deshalb diese Punkte geklärt sein:

1. Öffentliche Einstiegspunkte: Welche Domains, Subdomains, IP-Adressen, Load Balancer und API-Endpunkte sind erreichbar?
2. TLS-Terminierung: Wo wird TLS beendet, und welche Teile der Anfrage kann die WAF dort tatsächlich lesen?
3. Proxy-Vertrauen: Welches System setzt vertrauenswürdige Client-IP-Header, und wo werden vom Client gelieferte Forwarding-Header entfernt?
4. Ursprungsschutz: Akzeptiert die Anwendung Verkehr nur aus dem vorgesehenen Schutzpfad oder bleibt ein Bypass offen?
5. Protokolle: Funktionieren WebSockets, Server-Sent Events, große Uploads, Streaming, Webhooks und lange API-Anfragen innerhalb der dokumentierten Grenzen?
6. Fehlerverhalten: Welche Antwort sieht ein Nutzer bei Blockierung, Zeitüberschreitung, Überlast und nicht erreichbarer WAF?
7. Kapazität: Bleiben Antwortzeit und Fehlerrate unter realistischer Last im vereinbarten Rahmen?

Ein Architekturtest sollte außerdem unterscheiden, ob die WAF selbst für Netzwerk-DDoS-Abwehr, CDN, DNS oder Caching zuständig ist. Eine Anwendungsschicht-WAF ist nicht automatisch ein volumetrischer DDoS-Scrubber. Diese Fähigkeiten können zusammen angeboten werden, müssen aber getrennt bewertet werden.

4. Eine Testmatrix aus realen Abläufen bauen

Ein synthetischer Angriffstest allein findet keine geschäftskritischen False Positives. Die Testmatrix braucht deshalb legitime und unerwünschte Varianten desselben Ablaufs:

Die konkreten Fälle kommen aus Support-Tickets, Browser- und API-Tests, bekannten Integrationen und den häufigsten Produktionsabläufen. Testdaten dürfen keine echten Zugangsdaten, Tokens oder personenbezogenen Inhalte in freigegebenen Artefakten hinterlassen.

Vor der Umstellung wird eine Ausgangslage festgehalten: Anfragevolumen, Antwortzeiten, Statuscodes, fachliche Erfolgsraten und bekannte Fehler. Nur dann lässt sich nach einer Regeländerung unterscheiden, ob die WAF eine Störung verursacht hat oder ein bereits bestehendes Problem sichtbar wurde.

5. WAF-Rollout in fünf Freigabestufen

AWS empfiehlt für WAF-Änderungen zunächst Tests in einer Testumgebung und danach einen Count-Modus mit Produktionsverkehr. Microsoft beschreibt denselben Grundsatz als Detection vor Prevention. Die Bezeichnungen unterscheiden sich; der betriebliche Zweck ist gleich: reale Treffer prüfen, bevor eine Regel reale Anfragen stoppt.

Ein „repräsentativer Geschäftszyklus“ ist anwendungsspezifisch. Bei einem Shop kann er Kampagnen, Zahlungsläufe und Wochenendverkehr enthalten; bei einer B2B-Anwendung Monatsabschluss oder Bulk-Import. Eine pauschale Zahl von Tagen beweist keine ausreichende Abdeckung.

Freigabe von Log auf Block

Eine Regel wechselt erst in den Blockiermodus, wenn:

• ihre Treffer einer konkreten Regel und Anwendung zugeordnet werden können;
• legitime Treffer für kritische Abläufe untersucht wurden;
• die notwendige Ausnahme enger ist als eine globale Deaktivierung;
• fachlich und technisch Verantwortliche zugestimmt haben;
• die Blockantwort und ihre Wirkung auf Browser, API-Clients und Retries getestet sind;
• Monitoring und Alarmierung die vereinbarten Rollback-Signale abdecken;
• die letzte Änderung ohne Anwendungsdeployment zurückgenommen werden kann.

Diese Freigabe gilt pro Regel oder kleiner Regelgruppe. Ein komplettes Regelpaket erhält keine pauschale Freigabe, nur weil sein Beobachtungsmodus insgesamt wenig Auffälligkeiten gezeigt hat.

6. False Positives mit einem Ausnahmeregister beherrschen

Generische Regeln kennen den Kontext einer Anwendung nicht. Das OWASP Core Rule Set beschreibt genau dieses Problem: Legitime Eingaben können wie ein Angriffsmuster aussehen. Die empfohlene Reaktion ist eine gezielte Regelausnahme, nicht die direkte Änderung des gelieferten Rulesets und nicht die globale Abschaltung einer ganzen Schutzklasse. Auch die aktuelle Cloudflare-Dokumentation rät bei einem False Positive dazu, nur die verursachende Regel statt des gesamten Rulesets zu deaktivieren.

Ein Ausnahmeregister kann als Tabelle im vorhandenen Ticketsystem oder Konfigurations-Repository geführt werden:

Die engste wirksame Ausnahme ist normalerweise einer globalen Ausnahme vorzuziehen: ein Parameter für eine Regel auf einer Route ist enger als die gesamte Regel auf dem Host; eine Route ist enger als die ganze Anwendung. Welche Abstufungen technisch möglich sind, hängt vom gewählten Produkt ab und muss im Auswahltest belegt werden.

Ausnahmen sind technische Schulden mit Ablaufdatum. Bei jeder Änderung an Route, Payload oder Anwendung wird geprüft, ob die ursprüngliche Begründung noch gilt. Eine nicht mehr zugeordnete Verantwortung oder eine nicht mehr reproduzierbare Ausnahme ist ein Review-Signal, kein Grund, sie still weiterlaufen zu lassen.

7. Rollback vor der ersten Blockierregel schreiben

Ein WAF-Rollback beginnt nicht mit „WAF ausschalten“. Er nimmt zuerst die kleinste verursachende Änderung zurück.

Mögliche Rollback-Signale

• ein kritischer Ablauf wie Login, Upload, Webhook oder Checkout schlägt fehl;
• 403- oder andere Blockantworten steigen nach einer Regeländerung unerwartet;
• fachliche Erfolgsraten fallen, obwohl die Anwendung selbst unverändert ist;
• Support oder Monitoring meldet einen reproduzierbaren legitimen Block;
• die Zuordnung von Treffern zu Regel und Anwendung funktioniert nicht;
• die WAF verursacht nicht akzeptierte Latenz oder Fehler.

Die Schwellenwerte werden vor dem Rollout aus der eigenen Ausgangslage abgeleitet. Ein allgemeingültiger Prozentwert wäre Scheingenauigkeit.

Rückfall in sechs Schritten

1. Zeitpunkt, betroffene Anwendung und letzte Regeländerung festhalten.
2. Die verdächtige Regel von block auf log/count zurückstellen oder nur diese Änderung deaktivieren.
3. Den kritischen Ablauf mit dem vereinbarten Testfall erneut ausführen.
4. Block-, Fehler-, Latenz- und fachliche Erfolgsindikatoren beobachten.
5. Ursache, Auswirkung und Entscheidung im Änderungs- oder Vorfallprotokoll dokumentieren.
6. Die Regel erst nach engerem Geltungsbereich, korrigierter Ausnahme oder Anwendungspatch erneut zur Freigabe vorlegen.

Nur wenn die Störung nicht auf eine einzelne Änderung begrenzt werden kann, ist ein breiterer Rückfall sinnvoll. Auch dann müssen Ursprungsschutz und andere Kontrollen berücksichtigt werden: Ein unkontrollierter Bypass kann ein größeres Risiko erzeugen als die vorübergehende Einschränkung.

8. Welche WAF-Logs im Betrieb wirklich helfen

Ein hoher Zähler „Angriffe blockiert“ beantwortet keine Betriebsfrage. Für Triage, Ausnahme und Rollback sollten – abhängig von Datenschutz- und Aufbewahrungskonzept – mindestens folgende Informationen verfügbar sein:

• Zeitpunkt und Zeitzone;
• Anwendung, Host und Umgebung;
• stabile Regel-ID, Regelversion beziehungsweise Ruleset-Version;
• Aktion wie log, count, block oder skip;
• HTTP-Methode und betroffener Pfad beziehungsweise eine datensparsame Pfadklassifikation;
• Request- oder Correlation-ID für den Abgleich mit Anwendungslogs;
• Antwortstatus und, falls relevant, Verarbeitungsdauer;
• Konfigurationsänderung, verantwortliche Person und Zeitpunkt der Aktivierung.

Header, Query-Strings und Bodies können Zugangsdaten, Tokens oder personenbezogene Daten enthalten. „Alles protokollieren“ ist daher kein Qualitätsmerkmal. Vor dem Rollout werden benötigte Felder, Maskierung, Zugriffsrollen, Aufbewahrung und Löschung festgelegt. Für eine Untersuchung muss außerdem klar sein, ob Ereignisse vollständig oder nur als Stichprobe beziehungsweise aggregierter Zähler vorliegen.

Sinnvolle Betriebskennzahlen sind zum Beispiel:

• bestätigte False Positives je Regel und kritischem Ablauf;
• Zeit von der ersten Meldung bis zur eingegrenzten Ursache;
• aktive und überfällige Ausnahmen;
• Anteil der Regeln mit verantwortlicher Person, Reviewtermin und getestetem Rollback;
• ungeklärte Blockantworten nach einer Anwendungs- oder Ruleset-Änderung;
• Abweichungen zwischen dokumentierter und wirksamer Konfiguration.

Die maximale Zahl blockierter Requests ist dagegen kein sinnvolles Optimierungsziel. Ein Bot kann sie beliebig erhöhen, ohne dass der Schutz geschäftlich besser wird.

9. Regelbetrieb nach der Einführung

Die WAF-Konfiguration wird überprüft, wenn sich ihr Kontext ändert:

• nach relevanten Releases der Anwendung oder API;
• nach Änderungen an Login, Upload, Webhooks, Checkout oder Adminfunktionen;
• vor und nach einem Managed-Ruleset-Upgrade;
• wenn eine Ausnahme ihren Prüftermin erreicht;
• nach einem Vorfall oder bestätigten False Positive;
• wenn Datenpfad, Proxy, TLS-Endpunkt oder Ursprungsschutz geändert werden;
• wenn Aufbewahrung, Export oder Bereitschaftsprozess geändert werden.

Zusätzlich braucht es einen risikobasierten regelmäßigen Review. Die Frequenz richtet sich nach Änderungsrate, Kritikalität und Regeltyp. Das Review umfasst nicht nur Treffer, sondern auch Regeln ohne Treffer: Sie können überflüssig, falsch gescoped oder technisch unwirksam sein.

Wo Obhut bei diesem Ablauf hilft – und wo nicht

Obhut ist für einen begrenzten Teil dieser Checkliste ausgelegt: eigene WAF-Regeln pro Anwendung im kontrollierten Anfragepfad. Aktuell können Regeln Pfad, Header, HTTP-Methode oder IP/CIDR prüfen. Neben exakten, Präfix- und Enthält-Vergleichen ist eine optionale zweite UND-Bedingung möglich. Jede Regel arbeitet im Modus log oder block; eine Blockierung liefert 403. Aggregierte Zähler zeigen Treffer pro Regel, und WAF-Blockierungen werden als abgelehnte Zugriffsereignisse erfasst.

Damit lässt sich ein kleiner Geltungsbereich zunächst beobachten, anschließend bewusst blockieren und bei Problemen wieder auf log zurückstellen oder entfernen. Das passt zu Teams, die bekannte Anwendungspfade mit wenigen nachvollziehbaren Regeln absichern und deren Wirkung gemeinsam prüfen wollen.

Die Grenzen sind ebenso wichtig: Obhut liefert derzeit kein Managed OWASP CRS, keine Regex-Regeln, keine eigene Allow-/Skip-Ausnahme für WAF-Regeln, keine Geo-/ASN- oder Reputationserkennung und keine verwalteten Threat-Intelligence-Regeln. Die WAF-Drilldowns sind aggregiert; sie enthalten keine einzelnen Requests, IP-Adressen, Header oder Bodies. Obhut ersetzt zudem kein CDN, kein globales Anycast-Netz und keine volumetrische DDoS-Abwehr.

Quellen

Stand der Quellen: 14. Juli 2026.

• BSI IT-Grundschutz APP.3.1: Webanwendungen und Webservices
• OWASP: Web Application Firewall
• OWASP Core Rule Set: False Positives and Tuning
• AWS: Testing and tuning your AWS WAF protections
• Microsoft: Recommended approach to enabling Azure WAF
• Cloudflare: Troubleshoot managed WAF rules