Wie man die Azure Web Application Firewall richtig einführt
Die Einführung, Konfiguration und Optimierung der Azure Web Application Firewall kann kompliziert sein. Aus diesem Grund behandeln wir in diesem Blog-Beitrag die konkreten Schritte und Empfehlungen, um eine Web Application Firewall korrekt zu konfigurieren.

Einführung
Webanwendungen sind heute die primären Schnittstellen zwischen Unternehmen und Kunden. Mit der steigenden Anzahl von Bedrohungen, von SQL-Injection bis hin zu Cross-Site-Scripting (XSS), wächst der Bedarf an Schutzmechanismen, die direkt auf Anwendungsebene ansetzen.
Microsoft Azure bietet hierfür die Web Application Firewall (WAF), die sich nahtlos in Dienste wie Application Gateway, Azure Front Door und Azure CDN integrieren lässt.
Warum wird eine Web Application Firewall benötigt?
Eine Web Application Firewall (WAF) ist eine Sicherheitskomponente, die speziell den HTTP(S)-Traffic zwischen Clients und Webanwendungen überwacht, filtert und im Bedarfsfall blockiert. Sie arbeitet typischerweise auf der Ebene von Layer 7 (Anwendungsschicht) im OSI-Modell und erkennt Angriffe anhand von vordefinierten Regeln, Signaturen oder auch durch anomalie-basiertes Verhalten.
Sie schützt beispielsweise vor folgenden Angriffen:
-
Injection-Angriffe: Die WAF analysiert Parameter, Header und Payloads von HTTP-Requests. Verdächtige Eingaben wie UNION SELECT oder Path-Traversal-Attacken werden blockiert oder mit speziellen Escape-Mechanismen neutralisiert, bevor sie die Backend-Anwendung erreichen.
-
Cross-Site-Scripting: Die WAF filtert zusätzlich schädliche Payloads in Eingabefeldern oder URL-Parametern, sodass sie nicht an den Browser anderer Nutzer weitergegeben werden können.
-
Session Hijacking: Durch die Inspektion von Cookies und Session-IDs kann die WAF ungewöhnliche Nutzungsmuster feststellen. Sie kann Token validieren oder manipulierte Requests blockieren.
-
Datenexfiltration über unsichere APIs: Die WAF überwacht den Datenfluss und erkennt, wenn übermäßige oder sensible Informationen über API-Endpunkte abgegriffen oder in großen Mengen exfiltriert werden sollen.
-
DDoS-Angriffe auf Applikationsebene: Im Gegensatz zu klassischen Netzwerk-Firewalls kann eine WAF applikationsspezifische Anomalien erkennen. Sie begrenzt dann Requests pro IP oder aktiviert Rate Limiting, um den Service vor Überlastung zu schützen.
Wie kann eine Web Application Firewall eingerichtet werden?
Die Einrichtung einer Azure Web Application Firewall (WAF) kann auf verschiedene Arten erfolgen, bspw. über das Azure-Portal, per Azure CLI oder automatisiert über Infrastructure-as-Code (IaC).
Je nach Anforderung können für regionale Anwendungen ein Azure Application Gateway mit Lastverteilung oder ein Azure Front Door für globale Anwendungen verwendet werden. Für beide Lösungen kann anschließend die Azure Web Application Firewall aktiviert werden.
Vorbereitungsphase
Bevor eine Web Application Firewall (WAF) in den aktiven Prevention Mode gestellt wird, ist eine strukturierte Planungs- und Testphase notwendig.
In dieser Phase wird die WAF zunächst im Detection Mode betrieben. Im Detection Mode werden verdächtige Anfragen protokolliert, aber nicht blockiert. Dadurch lässt sich der eingehende Traffic detailliert analysieren, ohne den laufenden Betrieb oder legitime Benutzer zu beeinträchtigen. Auf Basis der Logs können False Positives identifiziert und die Rule Sets angepasst werden.
Identifikation des Blast-Radius
Bevor eine WAF im Prevention Mode produktiv geschaltet wird, sollte der Blast Radius, also die potenziellen Auswirkungen auf den Betrieb bewertet werden. Dazu sollten zunächst alle zu schützenden Webanwendungen und APIs identifiziert werden:
- Bestehende Endpunkte: Anwendungen und Dienste, die bereits im Application Gateway oder in Front Door integriert sind.
- Zukünftige Endpunkte: Geplante Webanwendungen und APIs, die perspektivisch ebenfalls geschützt werden sollen.
Diese vollständige Übersicht ermöglicht damit:
- Auswirkungsanalyse: Für jede Anwendung lässt sich prüfen, wie sich die Aktivierung des Prevention Mode auf den Live-Traffic auswirken könnte.
- Dokumentation: Während der Test- und Umstellungsphase können alle beobachteten Effekte (z. B. False Positives, Performance-Implikationen) dokumentiert werden.
- Kommunikation: Konkrete Beobachtungen und Verbesserungsvorschläge können gezielt an die jeweiligen Workload-Teams zurückgespielt werden, sodass Applikationen frühzeitig angepasst oder Whitelists und Custom Rules ergänzt werden können.
Rule-Set Definition
Die Azure Web Application Firewall (WAF) unterstützt Managed Rule Sets (MRS) und Custom Rules.
Managed Rule Sets basieren auf dem OWASP Core Rule Set (CRS) und decken eine breite Palette typischer Angriffsvektoren wie SQL-Injection, Cross-Site-Scripting oder Remote Code Execution ab. Jede Regel ist dabei einer bestimmten Kategorie zugeordnet, beispielsweise beginnen SQL-Injection-Regeln mit der ID 942xxx, während XSS-Angriffe unter 941xxx geführt werden.
In der Praxis ist es wichtig, diese Regeln nicht nur zu aktivieren, sondern auch zu kontrollieren, da False Positives auftreten können. Deshalb erlaubt Azure, einzelne Regeln gezielt zu deaktivieren oder über sogenannte Exclusions bestimmte Header, Felder oder Parameter von der Prüfung auszuschließen. Auf diese Weise kann der Schutz beibehalten werden, ohne dass legitimer Traffic blockiert wird. Azure stellt zusätzlich verschiedene CRS-Versionen bereit, die je nach Teststatus und Kompatibilität mit der Anwendung ausgewählt werden können.
Während Managed Rule Sets generische Bedrohungen abwehren, sind Custom Rules das Werkzeug, um die WAF auf die jeweilige Applikation maßzuschneidern. Jede benutzerdefinierte Regel besitzt eine Priorität, die festlegt, in welcher Reihenfolge sie im Vergleich zu anderen Regeln ausgewertet wird. Als Aktionen stehen Allow, Block, Log oder im Fall von Front Door auch Redirect zur Verfügung. Über verschiedene Operatoren lässt sich das Verhalten sehr granular steuern. IPMatch filtert auf Basis von IP-Bereichen oder CIDR-Blöcken, GeoMatch greift auf IP-Geolocation zu, StringMatch und RegexMatch prüfen Inhalte in Query-Strings, Headern oder URIs, während SizeConstraint Regeln nach der Größe von Requests erlaubt. Mit RateLimitRule können Anfragen pro IP-Adresse limitiert werden, um Layer-7-DDoS-Angriffe abzuwehren.
In der Praxis kommen dabei unterschiedliche Parameter zum Einsatz. Häufig werden IP-Adressbereiche definiert, um bestimmte Netzwerke explizit zuzulassen oder bekannte Angreifer-Quellen konsequent zu sperren. Ebenso relevant sind HTTP-Header-Prüfungen, so lässt sich etwa sicherstellen, dass nur Requests mit einem erwarteten Content-Type wie application/json akzeptiert werden oder dass verdächtige User-Agents blockiert werden. Bei Webanwendungen mit klar definierten API-Strukturen können Query-Strings und URL-Pfade gefiltert werden, etwa indem Admin-Endpunkte nur für interne Netze verfügbar sind oder verdächtige Dateiendungen wie .php in einer .NET-Umgebung grundsätzlich blockiert werden.
Die Best Practice für die Regeldefinition folgt dem Detection-first-Ansatz, sodass neue Regeln zunächst im Detection Mode ausgerollt werden, um deren Verhalten zu beobachten und False Positives zu identifizieren. Erst nach einer ausreichenden Validierung sollten sie im Prevention Mode aktiviert werden. Dabei empfiehlt sich ein Least-Privilege-Vorgehen. sodass zunächst restriktiv konfiguriert und anschließend gezielt Ausnahmen zugelassen werden. Damit die Konfiguration nachvollziehbar bleibt, sollten alle Anpassungen versioniert werden. Auf diese Weise entsteht ein kontrolliertes und reproduzierbares Sicherheitssetup, das nicht nur vor Angriffen schützt, sondern auch eine klare Governance-Struktur einhält.
Wie Rule-Sets Requests bewerten
Eine WAF entscheidet anhand von Rule-Sets, ob eingehende HTTP(S)-Requests erlaubt, protokolliert oder blockiert werden. Diese Regelwerke bestehen aus vordefinierten Standardregeln sowie optionalen Custom Rules, die spezifisch auf die jeweilige Anwendung zugeschnitten sind. Um die Funktionsweise der Request-Bewertung nachvollziehen zu können, möchte ich nachfolgend die Bewertungsmechanismen aufzeigen:
Signatur- und Mustererkennung:
- Eingehende Requests werden mit bekannten Angriffsmustern abgeglichen.
- Verdächtige Sequenzen im URL-Query, im Body, in Headern oder Cookies werden erkannt.
Positives Sicherheitsmodell (Whitelist):
- Nur explizit als erlaubt definierte Requests werden durchgelassen. Alles andere wird blockiert oder protokolliert.
- Eignet sich vor allem für stark regulierte APIs oder hochsensible Anwendungen.
Negatives Sicherheitsmodell (Blacklist)::
- Bekannte schädliche Requests werden blockiert.
- Legitime, aber auch neue oder untypische Requests können durchrutschen, falls sie nicht abgedeckt sind.
- Wird in der Praxis meist in Kombination mit Whitelisting eingesetzt.
Custom Rules:
- Regeln können auf Basis von IP-Adressen, Geo-Location, Header-Informationen, Request-Methoden oder Rate Limits definiert werden.
Anomalie-Scoring im OWASP CRS (Funktionsweise & Tuning):
CRS vergibt für jede erkannte Auffälligkeit Punkte (Anomaly Score) statt sofort zu blockieren. Jede Regel hat eine Severity, die zum Score beiträgt: Critical = 5, Error = 4, Warning = 3, Notice = 2. Die Summe pro Transaktion entscheidet gegen Schwellwerte. Standardmäßig unterscheidet CRS inbound (Request) und outbound (Response).
Standard-Schwellwerte (CRS Defaults):
- Inbound: blockiert ab Score ≥ 5
- Outbound: blockiert ab Score ≥ 4
Bewertungsablauf (vereinfacht):
-
Regeln feuern in den Request/Response-Phasen und erhöhen TX:inbound_anomaly_score bzw. TX:outbound_anomaly_score gemäß Severity. Viele Angriffserkennungen addieren 5 Punkte, kleinere Protokollverstöße weniger.
-
Blocking-Evaluation vergleicht die Summen mit den Schwellwerten und entscheidet, ob Requests erlaubt, nur geloggt (Detection) oder blockiert (Prevention) werden. Technisch erfolgt dies in den CRS-Dateien REQUEST-949-BLOCKING-EVALUATION.conf (Inbound) und RESPONSE-959-BLOCKING-EVALUATION.conf (Outbound).
-
In Logs sieht man häufig Korrelations-/Evaluationsregeln, z. B. Inbound Anomaly Score Exceeded (Rule ID 949110) und Anomaly score correlation (980130), die die finale Entscheidung protokollieren.
Beispiel-Bewertung:
- Treffer 1: XSS-Regel (Critical → +5)
- Treffer 2: kleinere HTTP-Anomalie (Warning → +3)
- Gesamt: 8 → ≥ 5 (Inbound-Threshold) → Block in Prevention, nur Logging in Detection.
Paranoia Level (PL): CRS aktiviert je nach PL1–PL4 zunehmend strengere Regeln. Welche Regeln in die Blockentscheidung eingehen, wird über das blocking paranoia level gesteuert. Höhere Paranoia Level führen zu strengeren Regeln und damit auh zur höheren Wahrscheinlichkeit für die Erreichung der Schwellenwerte.
Aktivierung des Detection Modus
Im Detection Mode arbeitet die WAF ausschließlich überwachend, sodass verdächtige Requests anhand der aktiven Rule-Sets analysiert und protokolliert werden, aber nicht blockiert.
Zweck und Vorteile:
-
Erkennen von False Positives: Requests, die fälschlicherweise als Angriff eingestuft würden, lassen sich identifizieren, ohne den produktiven Datenverkehr zu stören. Dadurch können Regeln gezielt angepasst oder Ausnahmen (Exclusions) definiert werden.
-
Analyse realer Angriffsmuster: Die Logs liefern erste Einblicke, welche Angriffsversuche tatsächlich auf die Anwendung gerichtet sind. Damit lässt sich einschätzen, welche Bedrohungen relevant sind.
-
Risikofreie Einführung: Da im Detection Mode kein aktives Blockieren erfolgt, können Workload-Teams die Auswirkungen einer WAF-Einführung beobachten, ohne dass produktiver Traffic beeinträchtigt wird.
Umstellungsphase
Die Umstellungsphase beschreibt den Übergang von einer rein beobachtenden WAF im Detection Mode hin zu einer aktiv eingreifenden Konfiguration im Prevention Mode. Sie ist entscheidend, um die Balance zwischen effektiver Angriffserkennung und minimaler Beeinträchtigung legitimen Traffics sicherzustellen.
Analyse der Findings im Detection Modus
Während der Detection-Phase werden alle verdächtigen Requests geloggt. Die Auswertung dieser Daten bildet die Grundlage für Anpassungen der Regelwerke.
In Azure Monitor oder Log Analytics werden WAF-Events zentral gesammelt. Typische Parameter sind Request-URL, Header, IP-Adresse, User-Agent, betroffene Regel-ID und Anomalie-Score. Häufig auftretende Muster (z. B. SQL-Injection-Versuche auf Login-Endpunkte, XSS auf Suchfelder) lassen Rückschlüsse auf die Angriffsoberfläche zu. Manche Treffer sind für die jeweilige Anwendung irrelevant oder führen zu False Positives.
Konfiguration von Custom Rules
Wenn die Standard-Regeln (z. B. OWASP CRS) nicht ausreichen oder zu restriktiv sind, können Custom Rules definiert werden. Diese greifen vor den Managed Rule Sets und erlauben gezielte Anpassungen.
Mögliche Szenarien:
- Whitelisting von internen API-Clients: Requests aus internen IP-Ranges oder bekannten Service-Identitäten werden zugelassen, auch wenn sie Regelverstöße enthalten.
- Blockieren spezifischer User-Agents: Bots, Crawler oder Scraper können anhand ihres User-Agent-Headers ausgeschlossen werden.
- Geo-Blocking: Einschränkung des Zugriffs auf bestimmte geografische Regionen, falls die Anwendung nur in ausgewählten Märkten verfügbar sein soll.
- Rate Limiting: Schutz vor Missbrauch durch Beschränkung der Anzahl an Requests pro Client/IP innerhalb eines Zeitfensters.
Technisch werden Custom Rules in Azure über die WAF-Policy konfiguriert. Jede Regel enthält Bedingungen (Match-Kriterien) und eine Aktion (Allow, Block, Log).
Aktivierung des Prevention Modus
Nach erfolgreicher Analyse und Konfiguration erfolgt die Umschaltung in den Prevention Mode:
- Aktive Blockierung: Verdächtige Requests, die definierte Thresholds überschreiten oder durch Custom Rules erfasst werden, werden jetzt direkt blockiert.
- Feintuning im Betrieb: Auch nach der Aktivierung sollten Logs weiterhin regelmäßig geprüft werden, um neue False Positives oder Angriffsmuster frühzeitig zu erkennen.
- Schrittweises Vorgehen: In kritischen Umgebungen kann der Wechsel endpunkt- oder anwendungsbasiert erfolgen, um den Blast Radius klein zu halten.
Ab diesem Zeitpunkt dient die WAF nicht mehr nur als Frühwarnsystem, sondern als aktive Schutzschicht zwischen Clients und Anwendung.
Kontinuierliche Optimierung
Die Einführung einer WAF ist kein einmaliges Projekt, sondern der Beginn eines fortlaufenden Sicherheitsprozesses. Durch regelmäßige Analyse, Visualisierung und Automatisierung wird sichergestellt, dass die Schutzwirkung dauerhaft hoch bleibt und neue Angriffsmuster berücksichtigt werden.
Visualisierung der Ergebnisse
Die FrontDoorAccessLogs und FrontDoorAuditLogs können auf unterschiedliche Art und Weise dargestellt werden:
- Azure Workbooks: Erstellung von interaktiven Dashboards, die Angriffsstatistiken aufbereiten.
- Dashboards für Security-Teams: Einheitliche Übersicht über Blockierungen, Häufigkeit von Angriffsmustern und potenziell kompromittierte Endpunkte.
- Langfristige Trendanalysen: Unterstützung bei Budget- und Kapazitätsplanung.
Benachrichtigungen bei ungewöhnlichem Verhalten
- Azure Monitor Alerts: Automatisierte Warnmeldungen bei Überschreiten definierter Schwellenwerte (z. B. Anzahl geblockter Requests pro Minute).
- Microsoft Sentinel Integration: Erweiterte Analyse durch Korrelation mit anderen Sicherheitsereignissen wie Anmeldeanomalien oder Netzwerkangriffen.
- SIEM-Anbindung: Vollständige Integration in bestehende Security Operation Center (SOC)-Workflows. So können Angriffe im Kontext anderer Ereignisse (z. B. Endpoint-Security, IDS/IPS) bewertet werden.
Fazit
Die Azure Web Application Firewall (WAF) ist ein zentrales Sicherheitswerkzeug für moderne Webanwendungen und APIs. Sie bietet Schutz vor einer Vielzahl von Angriffen wie SQL Injection, XSS, Session Hijacking und Datenexfiltration und das direkt auf Anwendungsebene.
Der Schlüssel zum erfolgreichen Einsatz liegt in einem strukturierten Vorgehen:
- Planung: Identifikation aller relevanten Workloads und Definition des Blast Radius.
- Testphase: Betrieb im Detection Mode zur Analyse von Angriffen und False Positives.
- Umstellung: Einführung von Custom Rules und schrittweise Aktivierung des Prevention Mode.
- Optimierung: Kontinuierliches Monitoring, Visualisierung und Anpassung der Regelwerke.
Unternehmen, die diese Vorgehensweise befolgen, reduzieren ihr Risiko signifikant, verhindern Betriebsunterbrechungen durch Fehlkonfigurationen und schaffen zugleich Transparenz über Bedrohungen, die ihre Anwendungen betreffen.