Dieser Leitfaden behandelt die Funktion, die Komponenten und die praktische Implementierung einer Web Application Firewall (WAF).

Definition einer Web Application Firewall

Eine Web Application Firewall (WAF) ist ein Sicherheitssystem zur Überwachung, Filterung und Blockierung von HTTP-Datenverkehr zu und von einer Webanwendung. Im Gegensatz zu einer traditionellen Netzwerk-Firewall, die auf den Netzwerk- und Transportschichten (Layer 3 und 4) des OSI-Modells operiert und den Verkehr primär anhand von IP-Adressen und Ports filtert, arbeitet eine WAF auf der Anwendungsebene (Layer 7).

Diese Positionierung erlaubt es der WAF, den Inhalt der Kommunikation zu analysieren. Sie prüft GET- und POST-Anfragen auf Angriffsmuster, die auf die Logik der Anwendung abzielen. Dazu gehören unter anderem Cross-Site Scripting (XSS) und SQL-Injection.

Die Rolle von OWASP

Die Effektivität einer WAF ist von der Qualität ihres Regelwerks abhängig. Das Open Web Application Security Project (OWASP) ist eine Organisation, die Standards im Bereich der Webanwendungssicherheit etabliert.

• OWASP Top 10: Dies ist ein regelmäßig aktualisiertes Dokument, das die zehn kritischsten Sicherheitsrisiken für Webanwendungen auflistet. Eine WAF ist darauf ausgelegt, Angriffe entgegenzuwirken, die diese Schwachstellen ausnutzen.
• OWASP ModSecurity Core Rule Set (CRS): Das CRS ist ein quelloffener Satz von Angrifferkennungsregeln für WAFs. Es stellt eine standardisierte, von Experten geprüfte Basis zur Erkennung von Bedrohungen bereit. Eine WAF-Engine wie ModSecurity nutzt das CRS, um Anfragen zu bewerten.

Das OWASP Core Rule Set (CRS) stellt eine Sammlung vordefinierter Regeln bereit, die typische Angriffe wie SQL-Injection, Cross-Site Scripting oder Remote Code Execution erkennen und abwehren sollen. Jede Regeldatei deckt dabei einen bestimmten Angriffsvektor oder Sicherheitsbereich ab und kann je nach Bedarf aktiviert oder angepasst werden.

Vorteile und Nachteile einer WAF

Vorteile

• Schutz vor bekannten Angriffsmustern: Eine WAF bietet Schutz vor den in der OWASP Top 10 gelisteten und weiteren Angriffsvektoren.
• Virtuelles Patching: Bei Bekanntwerden einer Schwachstelle im Anwendungscode kann eine WAF-Regel erstellt werden, um Angriffe auf diese Lücke zu blockieren. Dies dient als temporäre Schutzmaßnahme, bis der Quellcode korrigiert ist.
• Protokollierung und Überwachung: Angriffsversuche werden protokolliert. Diese Daten sind für Sicherheitsanalysen und die Erkennung von Angriffsmustern relevant.
• Unterstützung bei Compliance: Der Einsatz einer WAF ist oft Bestandteil von Sicherheitsstandards wie dem PCI DSS (Payment Card Industry Data Security Standard).

Nachteile

• False Positives: Legitime Anfragen können fälschlicherweise als bösartig eingestuft und blockiert werden. Dies erfordert eine Anpassung des Regelwerks („Tuning“).
• False Negatives: Komplexe oder unbekannte Angriffsvektoren können unter Umständen nicht erkannt werden. Eine WAF bietet keinen hundertprozentigen Schutz.
• Performance-Beeinträchtigung: Die Analyse von Anfragen führt zu einer Latenz in der Verarbeitung.
• Konfigurations- und Wartungsaufwand: Eine WAF erfordert eine sorgfältige Konfiguration und regelmäßige Wartung, um effektiv zu sein und False Positives zu minimieren.

Anleitung zum praktischen Showcase

Dieser Abschnitt beschreibt den Aufbau einer Testumgebung zur Demonstration einer WAF.

Benötigte Komponenten

• Docker: Eine Containerisierungsplattform zur isolierten und reproduzierbaren Bereitstellung von Softwarekomponenten.
• DVWA (Damn Vulnerable Web Application): Eine für Sicherheitsdemonstrationen entwickelte Webanwendung, die bekannte Schwachstellen enthält.
• Nginx: Ein Webserver, der als Reverse Proxy eingesetzt wird, um Anfragen zu empfangen und zu prüfen, bevor sie an die Zielanwendung weitergeleitet werden.
• ModSecurity: Eine Open-Source-WAF-Engine, die als Modul in Nginx integriert wird.

Schritt 1: Start der Zielanwendung (DVWA)

Ein Terminal wird geöffnet und der folgende Befehl ausgeführt:

docker run --rm -it -p 8080:80 vulnerables/web-dvwa

Die Anwendung ist anschließend unter http://localhost:8080 erreichbar.

Schritt 2: Konfiguration der WAF

Es wird ein lokaler Ordner für die Konfigurationsdateien erstellt.

nginx-Konfiguration (nginx.conf)

Dieser Codeblock ist eine Konfigurationsanweisung für den Webserver Nginx. Er definiert, wie Nginx auf Anfragen reagieren soll, die es empfängt. Im Wesentlichen richtet er Nginx als eine schützende Weiterleitungsstation (Reverse Proxy) mit einer integrierten Web Application Firewall (WAF) ein.

Der Code konfiguriert Nginx so, dass er auf Port 80 als Web Application Firewall und Reverse Proxy agiert. Jede eingehende Anfrage wird zuerst von ModSecurity auf Angriffsmuster geprüft. Wenn die Anfrage als sicher eingestuft wird, leitet Nginx sie an die eigentliche Webanwendung weiter, die auf Port 8080 läuft.

#Dieser Block startet die Definition für einen virtuellen Server. Alles innerhalb dieser geschweiften Klammern gilt für Anfragen, die an diesen speziellen Server gerichtet sind.
server {
    # Diese Zeile weist Nginx an, auf Port 80 auf eingehende Verbindungen zu "lauschen". Port 80 ist der weltweite Standard für unverschlüsselten HTTP-Verkehr. Jede Anfrage an http://localhost landet also bei diesem Server.
    listen 80;

    # Hier wird die Web Application Firewall ModSecurity für diesen Server-Block aktiviert. Ab diesem Punkt wird jede Anfrage, die dieser Server verarbeitet, von ModSecurity geprüft.
    modsecurity on;
    # Diese Anweisung teilt ModSecurity mit, welche Regeldatei es laden soll. In dieser Datei (setup.conf) stehen Verweise auf das eigentliche Regelwerk (z.B. das OWASP Core Rule Set), das die Logik zur Erkennung von Angriffen enthält.
    modsecurity_rules_file /etc/nginx/modsecurity.d/setup.conf;

    # Dieser Block definiert, was mit Anfragen für einen bestimmten URL-Pfad passieren soll. Das einzelne / (Schrägstrich) ist ein Platzhalter, der alle Anfragen abfängt, egal welcher Pfad aufgerufen wird (z.B. /login.php, /images/logo.png etc.).
    location / {
        # Das ist die Kernfunktion des Reverse Proxy. proxy_pass leitet jede Anfrage, die in diesem location-Block ankommt, an eine andere Adresse weiter.
        # http://host.docker.internal:8080 ist die Zieladresse. host.docker.internal ist eine spezielle Netzwerkadresse, die innerhalb eines Docker-Containers auf den Host-Computer verweist. Die Anfrage wird also an den Dienst weitergeleitet, der auf dem Host-Computer (in unserem Fall der DVWA-Container) auf Port 8080 läuft.
        proxy_pass http://host.docker.internal:8080; 
        # Diese Zeile sorgt dafür, dass der ursprüngliche Host-Name aus der Anfrage des Benutzers (z.B. localhost) an den Backend-Server (DVWA) weitergereicht wird. Das ist wichtig, damit die Zielanwendung weiß, für welche Domain sie die Anfrage bearbeitet.
        proxy_set_header Host $host;
    }
}

Proxy-Konfiguration (dvwa.conf)

Eine Datei mit dem Namen dvwa.conf wird erstellt. Sie enthält die Anweisung für Nginx, Anfragen an den DVWA-Container weiterzuleiten und ModSecurity zu aktivieren.

server {
    listen 80;

    # ModSecurity für diesen Server-Block einschalten (das reicht!)
    modsecurity on;

    location / {
        proxy_pass http://host.docker.internal:8080; 
        proxy_set_header Host $host;
    }
}

Ausnahmeregel (rule-exclusion.conf)

Eine Datei namens rule-exclusion.conf wird erstellt, um einen False Positive zu beheben, der durch beispielsweise ein Browser-Cookie ausgelöst wurde.

SecRuleRemoveById 942290

Schritt 3: Start des WAF-Containers

Im Terminal wird in den Ordner mit den Konfigurationsdateien navigiert und der WAF-Container mit folgendem Befehl gestartet:

docker run –rm -it -p 80:80 -v „%cd%\dvwa.conf:/etc/nginx/conf.d/dvwa.conf“ -v „%cd%\rule-exclusion.conf:/etc/modsecurity.d/owasp-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf“ owasp/modsecurity-crs:nginx

Durchführung des Tests

Nach Abschluss der Installation ist die WAF unter http://localhost erreichbar.

Test ohne WAF: Ein Angriff wird gegen http://localhost:8080 ausgeführt. Auf der Seite „XSS (Reflected)“ wird nach dem Login und dem Setzen der Sicherheitsstufe auf „low“ das Payload eingegeben. Ergebnis: Ein JavaScript-Alert wird im Browser ausgeführt.

<script>alert('Ohne die WAF ist die Seite verwundbar!')</script>

Test mit WAF: Der gleiche Angriff wird gegen http://localhost ausgeführt. Ergebnis: Der Browser zeigt die Fehlerseite 403 Forbidden. Die WAF-Logs im Terminal zeigen eine Meldung, die den erkannten XSS-Angriff protokolliert.

Moderne Entwicklungen im Bereich WAF

Automatisierte Regelaktualisierung

Traditionelle WAFs arbeiten mit statischen Regelwerken, die von Administratoren manuell gepflegt werden müssen. Dieses Vorgehen ist fehleranfällig und führt dazu, dass neue Angriffsmuster häufig erst mit Verzögerung erkannt werden. Moderne Systeme nutzen automatisierte Updates, die ihre Regelbasis kontinuierlich mit den neuesten Bedrohungsinformationen abgleichen. Damit wird das Risiko verringert, dass Zero-Day-Angriffe unbemerkt bleiben. Zusätzlich sinkt der Wartungsaufwand, da weniger manuelle Eingriffe erforderlich sind. Diese Automatisierung ist vergleichbar mit Antiviren-Software, die regelmäßig Signaturdatenbanken aktualisiert, nur dass hier der Schutz speziell auf Webanwendungen ausgerichtet ist

Machine-Learning-Verstärkungen

Klassische WAFs erkennen Angriffe vor allem durch den Abgleich mit bekannten Mustern. Dieser Ansatz stößt an Grenzen, sobald ein Angriff neuartig oder leicht abgewandelt ist. Machine-Learning-gestützte Systeme gehen einen Schritt weiter: Sie analysieren den typischen Datenverkehr einer Anwendung und lernen, was normales Verhalten bedeutet. Abweichungen von diesem Muster können als Anomalien erkannt werden, auch wenn sie nicht in den klassischen Regelwerken hinterlegt sind. So lassen sich etwa schleichende Angriffe identifizieren, die sich in kleinen Schritten über mehrere Anfragen aufbauen. ML-Verfahren ergänzen damit die klassischen Regeln, indem sie dynamisch auf Veränderungen reagieren können.

Vom WAF zum WAAP

Mit dem Begriff Web Application and API Protection (WAAP) wird die Entwicklung klassischer WAFs hin zu umfassenderen Schutzplattformen beschrieben. Da moderne Anwendungen immer stärker auf APIs setzen, reicht es nicht mehr aus, nur den klassischen HTTP-Verkehr einer Webanwendung zu überwachen. WAAP-Lösungen vereinen WAF-Funktionalität mit API-Schutz, Bot-Management und DDoS-Abwehr in einem integrierten Paket. Dadurch werden nicht nur Webseiten, sondern auch Schnittstellen und automatisierte Zugriffsmuster abgesichert. Für Unternehmen bedeutet das einen ganzheitlicheren Schutz, der den aktuellen architektonischen Gegebenheiten moderner Anwendungen besser entspricht.

Über den Autor

aaron

Administrator

Besuchen Sie die Website Alle Beiträge anzeigen