Web Application Firewalls (WAF)

Bisher haben wir einzelne Schutzmaßnahmen auf Code- und Konfig-Ebene betrachtet. Aber was, wenn eine Schwachstelle übersehen wurde? Oder wenn ein Angreifer eine Lücke schneller findet als dein Team sie patchen kann? Genau dafür gibt es eine zusätzliche Schutzschicht, die verdächtige Anfragen erkennt und blockiert, bevor sie überhaupt bei der Anwendung ankommen – die Web Application Firewall, kurz: WAF.

„Oh man, hätte ich mal vorher gewusst, dass wir einfach die WAF einschalten können…“

„Ganz so einfach ist es leider nicht. Die WAF alleine reicht nicht! Wenn sie mal ausfällt oder selbst Schwachstellen hat, darf die Anwendung dahinter nicht sofort in sich zusammenklappen! Die WAF ist wie ein Sicherheitsdienst vor dem Gebäude. Es ist gut, wenn jemand verdächtige Personen schon am Eingang abfängt. Trotzdem sollten alle Türen und Fenster verriegelt sein.“

Eine Web Application Firewall (WAF) analysiert HTTP/HTTPS-Verkehr auf Anwendungsebene und blockiert verdächtige Anfragen. Im Gegensatz zu einer Netzwerk-Firewall (die du aus Modul B5 kennst), die auf IP- und Port-Ebene filtert, versteht eine WAF den Inhalt der Anfragen und versucht Payloads für SQL-Injection, XSS und andere Webangriffe zu erkennen und herauszufiltern. Etwas salopp formuliert:

• Die WAF sieht: Anfrage auf Port 443, der URL-Parameter enthält ' OR 1=1 --. Achtung, das ist ein SQL-Injection-Muster –> blockiert
• Die Netzwerk-Firewall sieht: Anfrage auf Port 443 von IP 203.0.113.5, erlaubt. Die Anfrage wird durchgelassen, weil Port 443 für HTTPS geöffnet ist. Was in der Anfrage steht, ist der Netzwerk-Firewall egal.

💡 WAF heißt: Eine zusätzliche Schutzschicht, die Angriffe auf Anwendungsebene erkennt, aber niemals ein Ersatz für sichere Programmierung. Ein Entwickler, der sich auf die WAF verlässt, statt z.B. Prepared Statements zu verwenden, baut auf Treibsand.

Wie funktioniert eine WAF technisch?

Eine WAF wird als Reverse Proxy vor die Webanwendung geschaltet. Das bedeutet: Alle eingehenden Anfragen gehen zuerst an die WAF, die sie analysiert, und nur saubere Anfragen werden an den eigentlichen Webserver weitergeleitet. Die grundlegende Kommunikation verläuft folgendermaßen:

Client → [WAF / Reverse Proxy] → Webserver → Anwendung

Vereinfacht gesagt: Die WAF sitzt zwischen dem Internet und deiner Webanwendung und prüft jede eingehende Anfrage, bevor sie die Anwendung erreicht.

Deployment-Modelle

Es gibt verschiedene Arten, wie eine WAF in die IT-Infrastruktur integriert werden kann. Nachfolgend betrachten wir die wichtigsten:

On-Premises (im eigenen Rechenzentrum)

Bei diesem Modell läuft die WAF in einer eigenen Infrastruktur. Typischerweise ist das als Modul in einem bestehenden Webserver wie Apache oder Nginx. Das bekannteste Open-Source-Werkzeug dafür ist ModSecurity: eine WAF-Engine, die als Modul in Apache, Nginx oder IIS eingebunden wird und jede eingehende HTTP-Anfrage gegen ein Regelwerk prüft (siehe Praxistipp weiter unten).

Professionelle und kommerzielle Produkte, wie z.B. F5 WAF for Big-IP können aber auch z.B. als eigenständige Appliance vor den Webserver geschaltet sein.

Bei NovaHealth könnte der Nginx-Server, der das Patientenportal ausliefert, ModSecurity als Modul installiert haben. Die IT-Abteilung hätte volle Kontrolle über die Regeln und könnte sie an die Anwendung anpassen, wie z.B. bestimmte API-Endpunkte anders konfigurieren, die von der mobilen App genutzt werden.

• Vorteil: Volle Kontrolle über Konfiguration und Regelwerk. Daten verlassen das eigene Netzwerk nicht, was für eine Gesundheitsanwendung mit Patientendaten und Datenschutz ein Argument sein könnte.
• Nachteil: Erfordert Know-how und Personal für Konfiguration, Regel-Updates, Log-Auswertung und False-Positive-Analyse. Der Administrationsaufwand ist eher hoch.

Cloud WAF (WAF als Dienst)

Bei einer Cloud WAF betreibst du keine eigene Infrastruktur. Stattdessen leitest du deinen Web-Traffic über den Anbieter, der ihn filtert und nur saubere Anfragen an deinen Server weiterleitet. Der größte Anbieter ist hier wohl Cloudflare.

Technisch funktioniert das über eine DNS-Änderung: Der A-Record von portal.novahealth-solutions.de zeigt nicht mehr direkt auf den eigenen Webserver (z.B. 203.0.113.10), sondern auf eine IP-Adresse des Cloud-WAF-Anbieters. Der Anbieter prüft den Traffic und leitet ihn dann an den echten Server weiter.

• Vorteil: Schnelle Einrichtung (eine DNS-Änderung, kein Server-Umbau). Der Anbieter pflegt das Regelwerk und neue Angriffsmuster werden automatisch erkannt. Integrierter DDoS-Schutz: Das globale Netzwerk des Anbieters kann Angriffe mit Millionen von Anfragen pro Sekunde abfangen, bevor sie deinen Server erreichen.
• Nachteil: Dein gesamter Traffic fließt über einen Drittanbieter inklusive aller Benutzerdaten. Außerdem entsteht eine Abhängigkeit: Hat der Anbieter eine Störung, ist auch deine Anwendung nicht erreichbar.

💡 Für kleinere Teams ohne dediziertes Security-Personal ist eine Cloud WAF oft trotz der Nachteile und Abhängigkeit ein pragmatischer Einstieg, weil sie weniger Betriebsaufwand verursacht und DDoS-Schutz gleich mitbringt.

WAF in Container- und Kubernetes-Umgebungen

In modernen Umgebungen, die auf Containern und Kubernetes basieren, kann eine WAF in die Kubernetes-Infrastruktur integriert werden, beispielsweise in Verbindung mit einem Ingress Controller. Dadurch lässt sich der Schutz flexibel an dynamische und skalierbare Anwendungen anpassen. Die Herausforderung: Einrichtung und Betrieb erfordern zusätzliches Container- und Kubernetes-Know-how, das über das hinausgeht, was wir in diesem Modul behandeln.

WAF-Regelwerke: OWASP Core Rule Set

Egal welches Deployment-Modell eingesetzt wird, die WAF ist nur so gut wie ihre Regeln. Das wichtigste und am weitesten verbreitete Regelwerk ist das OWASP Core Rule Set (CRS). Das OWASP Projekt kennst du wahrscheinlich schon von der Top 10-Liste.

Das CRS ist Open Source, kostenlos und funktioniert mit ModSecurity und vielen kommerziellen WAFs. Es enthält z.B. Regeln für die Erkennung von:

• SQL-Injection: z.B. ' OR 1=1 -- in URL-Parametern (in der Praxis natürlich komplexer, denn kein Angreifer schickt einfach nur 1=1)
• XSS – z.B. <script>-Tags in Formulareingaben
• Path Traversal – Zugriff auf Dateien außerhalb des vorgesehenen Verzeichnisses (z.B. ../../etc/passwd)
• Remote Code Execution – Versuche, Systembefehle über die Webanwendung auszuführen

Ein wichtiges Konzept im CRS ist das Anomaly Scoring: Statt eine Anfrage bei einem einzigen verdächtigen Merkmal sofort zu blockieren, sammelt die WAF Punkte. Jede verdächtige Eigenschaft erhält einen Punktwert. Erst wenn der Gesamtscore einen konfigurierbaren Schwellenwert überschreitet, wird die Anfrage blockiert.

Dieses Prinzip hast du bereits bei der Spam-Abwehr kennengelernt: Der Spam Score bestimmt dort, für wie wahrscheinlich eine Mail als Spam erachtet wird.

Warum ist das besser als „ein Treffer = blockiert“? Ein Benutzer sucht zum Beispiel im NovaHealth-Portal nach „health select“. Das Wort SELECT allein ergibt z.B. 5 Punkte, liegt aber unter dem Schwellenwert von 15 Punkten. Die Anfrage wird durchgelassen. Enthält eine andere Anfrage dagegen SELECT, UNION, FROM und ein Hochkomma, summiert sich der Score schnell über den Schwellenwert und die Anfrage wird blockiert. Das versucht False Positives (fälschlicherweise blockierte legitime Anfragen) zu reduzieren.

Praxis-Beispiel: ModSecurity für Apache2

Das folgende Beispiel ist kein Praxis-Lab im eigentlichen Sinne. Stattdessen zeigen wir dir hier beispielhaft, wie ModSecurity für einen bereits installierten Apache2-Webserver auf einem Debian-System installiert, grundsätzlich konfiguriert und getestet werden kann. Wenn du möchtest, kannst du es mit etwas Eigeninitiative natürlich auch gleich nachbauen:

Zunächst kannst du die WAF Module für Apache2 installieren mit dem folgenden Befehl:

sudo apt install libapache2-mod-security2 modsecurity-crs

Die empfohlende Konfiguration befindet sich in der Datei modsecurity.conf-recommended. Du kannst sie folgendermaßen aktivieren:

sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Grundlegend musst du in dieser Datei nicht viel ändern. Zunächst arbeitet ModSecurity im Modus DetectionOnly:

SecRuleEngine DetectionOnly

In diesem Modus erkennt und protokolliert die WAF verdächtige Anfragen, blockiert sie aber noch nicht. Das ist insbesondere bei der erstmaligen Einrichtung sinnvoll: So kannst du zunächst beobachten, welche Requests die Regeln auslösen, ohne durch mögliche False Positives die Funktion der Website zu beeinträchtigen.

Wenn du die WAF später aktiv schalten möchtest, änderst du die Einstellung auf:

SecRuleEngine On

Danach muss die Apache-Konfiguration neu geladen werden, damit die Änderung wirksam wird:

sudo systemctl reload apache2

Die von ModSecurity erzeugten Meldungen kannst du anschließend beispielsweise live im Apache-Error-Log beobachten:

sudo tail -f /var/log/apache2/error.log

Für einen einfachen Funktionstest rufst du deine Website auf und hängst eine auffällige Eingabe als URL-Parameter an, beispielsweise:

?test=<script>alert(1);</script>

Dabei spielt es keine Rolle, ob die Anwendung den Parameter test tatsächlich verwendet. Die Anfrage enthält ein typisches XSS-Muster, das von entsprechenden WAF-Regeln erkannt werden kann. Im Log sollte daraufhin ein neuer Eintrag mit security2:error erscheinen. Der nachfolgende Screenshot zeigt einen Auszug des Logfiles. Maximiere die Ansicht für bessere Lesbarkeit:

Solange SecRuleEngine DetectionOnly gesetzt ist, wird die Anfrage lediglich protokolliert. Mit SecRuleEngine On kann eine passende Regel die Anfrage dagegen blockieren. Im Browser wäre dann nur noch eine Fehlermeldung zu sehen:

WAF im Betrieb: Tuning und Pflege

Eine WAF ist kein System, das einmal eingerichtet und anschließend vergessen werden kann. Regeln und Konfiguration müssen zur geschützten Anwendung passen und regelmäßig überprüft werden. Andernfalls kann die WAF entweder Angriffe übersehen oder den legitimen Betrieb der Anwendung beeinträchtigen.

Grundlegende Aufgaben

Wichtige Aufgaben im laufenden Betrieb sind:

• False Positives reduzieren: Eine WAF kann legitime Anfragen fälschlicherweise als Angriff einstufen. Ein typisches Beispiel ist ein Rich-Text-Editor, in dem Benutzer HTML eingeben dürfen. Inhalte wie <p>, <a> oder andere HTML-Elemente können dabei XSS-Regeln auslösen. Solche Fehlalarme sollten analysiert und möglichst gezielt durch eine Rule Exclusion (Ausnahme) entschärft werden – beispielsweise nur für eine bestimmte Regel, einen bestimmten Parameter oder Endpunkt. Regeln einfach vollständig abzuschalten, würde den Schutz unnötig reduzieren.
• Regeln aktuell halten: Angriffstechniken und Webanwendungen entwickeln sich weiter. Regelwerke wie das OWASP Core Rule Set (CRS) werden deshalb regelmäßig aktualisiert. Neue Versionen und Sicherheitsupdates sollten zeitnah eingespielt, aber vor dem produktiven Einsatz getestet werden, da sich durch neue oder geänderte Regeln auch neue False Positives ergeben können.
• Logs überwachen: WAF-Logs sollten regelmäßig ausgewertet werden. Sie zeigen nicht nur blockierte oder verdächtige Requests, sondern helfen auch dabei, wiederkehrende Fehlalarme, auffällige Angriffsmuster und notwendige Anpassungen der Konfiguration zu erkennen.

Erst beobachten, dann blockieren

Bei der Einführung solltest du eine WAF zunächst im Monitoring-Modus betreiben. Bei ModSecurity entspricht dies der bereits bekannten Direktive:

SecRuleEngine DetectionOnly

Die WAF wertet die Requests anhand ihrer Regeln aus und protokolliert Treffer, blockiert die Anfragen aber noch nicht. Dadurch kannst du die Logs analysieren, False Positives erkennen und gezielte Ausnahmen konfigurieren. Erst wenn die Konfiguration ausreichend abgestimmt ist, wird der Blocking-Modus aktiviert:

SecRuleEngine On

Auch danach ist das Tuning nicht abgeschlossen. Änderungen an der Webanwendung oder am Regelwerk können neue Fehlalarme verursachen und weitere Anpassungen erforderlich machen.

Das Prinzip kennst du bereits von der Content Security Policy (CSP) mit Content-Security-Policy-Report-Only: erst beobachten und abstimmen, dann durchsetzen.

Lass uns prüfen, ob du die Konzepte rund um Web Application Firewalls verstanden hast.