Die Web Application Firewall (WAF) ist eines dieser Tools, über das man oft spricht, das man aber selten in vollem Umfang ausschöpft. In vielen Fällen wird sie übereilt installiert, mit Standardregeln aktiviert und dann als einfacher passiver Schild belassen.
Dieser Blogbeitrag soll erklären, wie Sie das Beste aus einer WAF herausholen können: verstehen, was sie tatsächlich tut, ihre Gesamtkosten abzuschätzen, häufige Fehler zu vermeiden und vor allem einen messbaren Ansatz für ihre Effizienz aufzubauen.
Warum und wann Sie eine WAF einsetzen sollten?
Eine WAF wird unerlässlich, sobald eine Webanwendung sensible Daten verarbeitet (Kundenkonto, Zahlung, Gesundheit), kritische APIs (mobil, Partner, Back-Office) bereitstellt, Compliance-Anforderungen (PCI-DSS, RGPD) unterliegt oder wiederkehrenden Angriffen (credential stuffing, bots, aggressive Scans) ausgesetzt ist. Ihre typischen Anwendungen umfassen:
die Reduzierung der Exposition gegenüber den Top 10 OWASP-Schwachstellen (injections, XSS, RCE),
das virtuelle Patching zur Minderung eines zero-day oder eines ausstehenden Anwendungs-Patchs,
die Abwehr von bots (Scraping, Kontoübernahme, anormale Volumetrie auf sensiblen endpoints).
Im Gegensatz dazu bringt eine WAF auf einer rein statischen Website, die von einem CDN bedient wird, wenig Wert und kann bei Fehlkonfiguration sogar Latenz hinzufügen. Der Kontext muss daher ihre Verwendung bestimmen: Geschäftswert der endpoints, Datensensibilität, Exposition gegenüber Dritten und Reifegrad des Teams.
Die folgenden Abschnitte beantworten die drei Schlüsselherausforderungen: die WAF korrekt in der Infrastruktur zu platzieren, eine kostengerechte und bedarfsgerechte Lösung zu wählen und einen aktiven Ansatz zu verfolgen, anstatt «alles standardmässig zu blockieren».
Was ist eine WAF?
Technisch gesehen ist eine Web Application Firewall eine Komponente, die auf Schicht 7 des OSI-Modells (d.h. der Anwendungsschicht) agiert. Sie fängt den HTTP(S)-Verkehr ab und entscheidet für jede Anfrage, ob sie:
sie zulassen,
sie blockieren,
sie herausfordern (CAPTCHA, JavaScript-Challenge),
oder sie zur Überprüfung markieren (Status «Counted» auf AWS).
Moderne Engines kombinieren mehrere Signale:
Klassische Signaturen (Muster für SQL-Injections, XSS, etc.),
Heuristiken und Verhalten (Anfragerate, Anomalien in den headers, atypische payloads),
Reputation (IPs, die für Scans oder Angriffe bekannt sind, Tor, proxys, etc.),
Kontext (Land, autonomous system (AS), User-Agent, cookie, session).
Eine effiziente WAF ist nicht nur eine Regel-Engine, das für diesen Sicherheitsbaustein zuständige Team muss in der Lage sein, zu:
Einen echten Angriffsversuch durch einen böswilligen Akteur inmitten des Rauschens automatischer Scans zu erkennen,
Defensive Massnahmen basierend auf dem Verkehrstrend der Anwendung zu ergreifen,
Die Filterrichtlinie basierend auf Erfahrungen und in der Produktion erkannten False Positives kontinuierlich weiterzuentwickeln.
Wo soll sie in der Infrastruktur positioniert werden?
Gerade hier ist es möglich, die Effizienz einer WAF zu ruinieren. Der Standort der WAF in Ihrer Architektur bestimmt sowohl ihre Leistung als auch ihre Effizienz.
Option 1: WAF auf dem CDN
In einigen Projekten wird die WAF einfach auf die CDN-Schicht aufgepfropft (Beispiel AWS unten):
Das ist praktisch und schnell, aber ein Trugschluss:
Die Regeln werden auf den gesamten CDN-Verkehr angewendet, einschliesslich statischer assets,
Manche Regeln (tiefe Inspektion, aufwändige regex) können die Cache-Effizienz reduzieren, manchmal sogar vollständig,
Echte interessante Angriffe zielen selten auf /assets/smile.webp, sondern eher auf die API-endpoints.
Dennoch kann diese Architektur in den folgenden Fällen sinnvoll sein:
für sehr volumetrische öffentliche Websites,
für eine erste breite Filterschicht (geo-IP, Reputation, einfacher DDoS L7, geo-blocking).
Es ist jedoch eine schlechte Idee:
wenn die gesamte Geschäftslogik hinter einer separaten API liegt, die auf einer anderen Domain / endpoint exponiert ist,
wenn sehr feine Regeln (OWASP, Prüfungen auf Ebene des payload einer Anfrage) direkt auf CDN-Ebene angewendet werden müssen.
Option 2: WAF auf Ebene des load balancer
Eine weitere, häufigere Möglichkeit: die WAF auf Ebene des load balancer anzubringen, direkt vor dem Anwendungs-origin:
In diesem Fall behält man die volle Effizienz der WAF bei, während dem CDN seine natürliche Rolle belassen wird: Es gewährleistet weiterhin das Caching statischer assets, die Minifizierung des JS-bundles und andere Transformationen am Rand.
Die Filter-Gateway wird am nächsten zum Server platziert, der sich hinter der WAF befindet, dort wo passieren:
die authentifizierten Anfragen,
die Datenmutationen,
die kritischen Prozesse (login, Zahlungen, Administration).
Diese Platzierung bringt zwei wesentliche Vorteile:
Die Kosten konzentrieren sich weiterhin auf die Analyse des tatsächlich anwendungsbezogenen Verkehrs, da nur Anfragen, die den origin erreichen, die WAF passieren und nicht der gesamte CDN-Fluss.
Die Regeln können fein auf Listener- oder Pfadbasis angepasst werden, was es ermöglicht, spezifische Richtlinien auf interne APIs, sensible Prozesse oder Back-Office-Schnittstellen anzuwenden, ohne den Rest der Website zu stören.
Option 3: WAF auf API Gateway-Ebene
Schliesslich ist der WAF in sehr API-/Mikroservice-Architekturen oft direkt auf dem Gateway integriert:
Diese Organisation macht dann Sinn, wenn:
der Grossteil des Datenverkehrs JSON / REST / SOAP / gRPC ist,
das Ziel ist, die Kontrollen über die API-Pfade zu zentralisieren (autorisierte Methoden, DTO, Kontingente, etc.).
Der Schutz wird dann eine Kombination aus:
WAF-Regeln, die bösartige Anfragen filtern und blockieren (Injektionen, XSS, Bots, etc.) auf der HTTP(S)-Verkehrsebene
API-Richtlinien, die die funktionale Nutzung der Endpoints regeln (quotas, rate limiting, Schema-Validierung, Payload-Transformation, Fehlerverwaltung)
Zugangskontrollen, die sicherstellen, dass nur autorisierte Identitäten die sensiblen APIs aufrufen können (Authentifizierung, feingranulare Autorisierung, scopes, Rollen)
Umgehungswege eliminieren
Ein HTTP-Schutz ist nutzlos, wenn der Angreifer den durch den WAF geschützten Server direkt erreichen kann.
Um dies zu vermeiden, gibt es mehrere Lösungen:
Der Origin befindet sich in einem privaten Netzwerk (Subnetz, das nicht über das Internet routbar ist),
Nur der CDN / WAF kann darauf zugreifen:
über eingeschränkte Quell-IP-CIDRs,
oder über private Origin-Mechanismen (PrivateLink, VPC endpoint, etc.),
Die Firewalls / Security Groups sind so konfiguriert, dass sie jeglichen anderen Datenverkehr ablehnen.
Um dies zu vermeiden, besteht eine gängige Praxis auf AWS darin:
ALB in öffentlichem Subnetz, aber:
Security Group, die nur CloudFront-Quell-IPs erlaubt,
Gegebenenfalls eine fixe Admin-Bastion-IP
Origin-Typ EC2/ECS/Fargate in privatem Subnetz, nur über den ALB erreichbar.
Es ist auch möglich, einen „secret“-Header zwischen CDN und Origin mit einem shared secret als Wert hinzuzufügen und jede Anfrage abzulehnen, die ihn nicht enthält. Dies ist nützlich, um Szenarien von host header poisoning zu begrenzen (wenn ein Angreifer den Host-Header fälscht, um eine andere Anwendung hinter dem Reverse Proxy anzuzielen, das ordnungsgemässe Funktionieren des Caches zu verhindern, …). Allerdings verkompliziert dies die Konfiguration.
Was kostet eine WAF?
Eine Bereitstellung über einen cloud provider (AWS, GCP, …) bedeutet eine Abrechnung pro Anfrage (mit einem degressiven Tarif je nach Anfragevolumen), während eine Bereitstellung on-premise eher auf einer Lizenz zu fixen Kosten basiert und einer höheren Anfangsinvestition.
In beiden Fällen muss man in TCO (Total Cost of Ownership) denken, unter Einbeziehung von Bandbreite, Wartung, Governance und den versteckten Kosten einer Fehlkonfiguration (wie Fehlalarme, Latenz oder Überlastung der Logs).
WAF Cloud
Die Angebote cloud-native (AWS WAF, Azure Front Door, Google Cloud Armor, etc.) basieren auf Modellen der Abrechnung pro Anfrage. Man bezahlt in der Regel nach:
der Anzahl der verarbeiteten Anfragen (Abrechnung in Millionen-Anfragen-Schritten pro Monat),
dem Volumen aktiver Regeln oder erweiterter Module (bot management, IP reputation, rate limiting, etc.),
dem ausgehenden Datenverkehr (Bandbreite) und manchmal der Anzahl der Distributionen (oder geschützten Domains).
Diese Lösungen bieten den Vorteil eines minimalen Wartungsaufwands und einer direkten Integration in die Dienste des cloud providers, aber ihre Kosten können schnell steigen, wenn der Datenverkehr hoch ist oder die Regeln schlecht optimiert sind. Sie eignen sich besonders für elastische Architekturen, bei denen die Last stark variiert.
WAF on-premise
Die Lösungen on-premise basieren eher auf einem fixen Lizenzmodell, oft indexiert nach:
dem maximal zulässigen Durchsatz,
der Anzahl der Instanzen oder Knoten,
manchmal zusätzlichen Modulen (analytics, Ressourcen-Monitoring, etc.).
Sie erfordern eine höhere Anfangsinvestition, ermöglichen aber eine vollständige Kontrolle über den Datenverkehr, die Logs und die Regelanpassung. Im Gegenzug erfordern sie mehr Personalressourcen für den Betrieb und Sicherheitsupdates.
ModSecurity bleibt die Referenz-Open-Source-Option, integrierbar mit NGINX oder Apache, und dient oft als Basis für eine WAF on-premise Bereitstellung.
Die Optimierung eines WAF ist Teil eines kontinuierlichen Verbesserungsprozesses. Es geht nicht nur darum, ein Produkt zu installieren, sondern eine Verteidigungsstrategie aufzubauen.
Lernphase
Es wird empfohlen, systematisch im Beobachtungsmodus zu starten ("count" auf AWS, "log only" anderswo). Das Ziel ist noch nicht zu blockieren, sondern alle verdächtigen Anfragen zu verfolgen und deren Art zu klassifizieren.
Man exportiert die Logs in eine Security Information and Event Management (SIEM) Lösung oder einen data lake, man kennzeichnet wiederkehrende Muster (automatisierte Scans, interne Audit-Tools, tatsächliche Exploitationsversuche) und erstellt Baselines: Volumen pro endpoint, Verteilung der Methoden, übliche headers. Diese Momentaufnahme dient als Referenz für die folgenden Phasen.
Progressive Härtung
Sobald die Normalität bekannt ist, aktiviert man positive Richtlinien auf kritischen Pfaden (Authentifizierung, Zahlungen, Administration). Konkret beschreibt man die autorisierten "input contracts": zugelassene HTTP-Methoden, erwartete JSON-Schemas, tolerierte headers-Sets, bekannte IP-Bereiche oder Client-App-Fingerabdrücke.
Alles, was ausserhalb dieses Bereichs liegt, wird blockiert oder hinterfragt. Man geht API für API vor, um Fehlalarme zu begrenzen, man speist einen Interventionsplan, der genau festlegt, welche Massnahmen im Alarmfall zu ergreifen sind (temporäre Deaktivierung, Erstellung einer Ausnahmeregel, Eskalation an das Product Team).
Automatisierung und Governance
Der WAF wird nachhaltig, wenn er als Code verwaltet wird. Die Regeln werden in einem IaC-Repository (wie Terraform) beschrieben, Änderungen durchlaufen eine Code-Überprüfung und automatisierte Tests (z.B. terraform plan, Anfragesammlungen curl oder k6 die kritische Fälle reproduzieren) validieren, dass eine Änderung keinen legitimen Ablauf unterbricht.
Wir versionieren auch die hausinternen Signatur-Wörterbücher, wir taggen jede Regel mit einem Ticket oder einem Incident, um die Nachvollziehbarkeit zu gewährleisten, und wir dokumentieren die Abhängigkeiten (betroffene APIs, verantwortliche Teams), um diese im Falle einer Änderung benachrichtigen zu können.
KPI-Nachverfolgung
Um die Verschärfung der Regeln zu verfolgen, sind diese KPIs am relevantesten:
Falsch-Positiv-Rate (Ziel <0,1%) : Vergleicht ausgelöste Regeln und tatsächliche Incidents.
Verhältnis beobachtet vs. blockiert : Misst den Anteil der Regeln, die sich noch im Erkennungsmodus befinden, und den schrittweisen Übergang zur Blockierung.
Zusätzliche Latenz (Ziel <30 ms P95) : Überwacht die Performance-Kosten des WAF.
Funktionale Abdeckung : Prozentsatz der APIs, die durch eine positive Richtlinie geschützt sind.
Zusätzlich messen wir die durchschnittliche Reaktionszeit zur Erstellung einer Regel nach einem Incident und die durchschnittliche Zeit zum Löschen oder Lockern einer überflüssig gewordenen Regel, um sicherzustellen, dass das System agil bleibt.
Galadrim-Unterstützung
Bei Galadrim betreiben wir bereits WAFs in der Produktion für verschiedene Branchen: E-Commerce, der starken Lastschwankungen unterliegt, regulierte Fintechs, SaaS-Anbieter, die kritische APIs exponieren, Akteure im Gesundheitswesen, etc.
Unser MSSP-Team entwickelt die positiven Richtlinien, implementiert die IaC, überwacht die KPIs und interveniert bei Incidents.
Fazit
Ein WAF ist nicht unfehlbar: Er kann weder eine anfällige Anwendung korrigieren noch gute Entwicklungspraktiken ersetzen. Er ist jedoch ein wertvolles Werkzeug, um den Verkehr besser zu kontrollieren und Incidents besser zu verstehen. Richtig konfiguriert, hilft er, anomales Verhalten früher zu erkennen, die Auswirkungen eines Angriffs zu reduzieren und die Verfügbarkeit der Dienste aufrechtzuerhalten.
Sein Wert entfaltet sich vollständig, wenn er mit einer soliden Applikationshygiene : einer reduzierten Angriffsfläche, schnell angewendeten Patches und einer strikten Verwaltung von Identitäten und Zugriffen. In diesem Rahmen wird der WAF zu einem Verbündeten der operationellen Resilienz, einem Mittel, um das Unvorhersehbare aufzunehmen und gleichzeitig die Kontrolle über die eigene Risikoexposition zu behalten.
Zum Schluss behalten Sie diese zu vermeidenden Fehler im Hinterkopf:
Den WAF vor dem CDN platzieren: Dies macht die Vorteile des Caches zunichte und erhöht die Latenz.
Den Origin zugänglich lassen: Die Anwendung darf ausschliesslich über den CDN oder den WAF erreichbar sein. Jeder direkte Zugriff kann eine Schwachstelle darstellen.
Das Blockieren ohne Beobachtungszeitraum aktivieren: Es ist zwingend, im Erkennungsmodus zu beginnen, um die Regeln anzupassen und falsch positive Meldungen zu eliminieren.
Manuell konfigurieren: Ohne IaC häufen sich die Konfigurationsabweichungen an und die Nachvollziehbarkeit verschwindet.
