Reverse Proxy und WAF: Webanwendungen vor Angriffen schützen

Was ein Reverse Proxy tut

Ein Reverse Proxy ist ein Server, der zwischen dem Internet und deinen Backend-Webservern sitzt. Jede Anfrage aus dem Internet geht zuerst an den Reverse Proxy. Der Reverse Proxy prüft die Anfrage, verarbeitet sie gegebenenfalls und leitet sie an den zuständigen Backend-Server weiter. Die Antwort des Backend-Servers geht den gleichen Weg zurück.

Aus Sicht des Nutzers kommuniziert er mit dem Reverse Proxy, nicht mit dem Backend-Server. Der Backend-Server ist aus dem Internet nicht direkt erreichbar. Das allein ist bereits ein erheblicher Sicherheitsgewinn.

Funktionen eines Reverse Proxy

Load Balancing. Verteilung der Anfragen auf mehrere Backend-Server. Wenn ein Server ausfällt, leitet der Reverse Proxy die Anfragen automatisch an die verbleibenden Server um.

SSL/TLS-Terminierung. Der Reverse Proxy übernimmt die Verschlüsselung und Entschlüsselung des HTTPS-Verkehrs. Die Backend-Server kommunizieren unverschlüsselt mit dem Reverse Proxy (oder über ein internes Zertifikat). Das vereinfacht die Zertifikatsverwaltung und entlastet die Backend-Server.

Caching. Häufig angefragte Inhalte (statische Dateien, API-Antworten) werden vom Reverse Proxy zwischengespeichert und direkt ausgeliefert, ohne den Backend-Server zu belasten.

Header-Manipulation. Der Reverse Proxy kann HTTP-Header hinzufügen, entfernen oder ändern: Security-Header setzen (Content-Security-Policy, Strict-Transport-Security), interne Server-Header entfernen (X-Powered-By, Server), Client-IP-Adressen weiterleiten (X-Forwarded-For).

Zugangskontrolle. Rate Limiting (Begrenzung der Anfragen pro IP), Geo-Blocking (Anfragen aus bestimmten Ländern blockieren), IP-Whitelisting/Blacklisting.

Web Application Firewall. Die für diesen Artikel zentrale Funktion: Der Reverse Proxy analysiert jede Anfrage auf bösartige Inhalte und blockiert Angriffe, bevor sie den Backend-Server erreichen.

Was eine WAF tut

Eine Web Application Firewall (WAF) arbeitet auf der Anwendungsschicht (Layer 7 des OSI-Modells). Während eine Netzwerk-Firewall IP-Adressen, Ports und Protokolle prüft, analysiert eine WAF den Inhalt der HTTP/HTTPS-Anfragen und -Antworten: URLs, Query-Parameter, Formulardaten, Cookies, HTTP-Header, Request-Body.

Bedrohungen, vor denen eine WAF schützt

Die OWASP Top 10 sind der Maßstab für Web-Sicherheitsrisiken. Eine gut konfigurierte WAF schützt vor den meisten dieser Bedrohungen:

SQL-Injection (A03). Der Angreifer schleust SQL-Befehle in Eingabefelder ein, um die Datenbank zu manipulieren oder auszulesen. Beispiel: ' OR '1'='1 in einem Login-Feld. Die WAF erkennt SQL-Syntax in HTTP-Parametern und blockiert die Anfrage.

Cross-Site-Scripting / XSS (A03). Der Angreifer injiziert JavaScript-Code in Webseiten, der im Browser anderer Nutzer ausgeführt wird. Beispiel: <script>document.cookie</script> in einem Kommentarfeld. Die WAF erkennt Script-Tags und Event-Handler in Eingabefeldern.

Path Traversal (A01). Der Angreifer manipuliert Dateipfade, um auf Dateien außerhalb des vorgesehenen Verzeichnisses zuzugreifen. Beispiel: ../../etc/passwd in einem Datei-Parameter. Die WAF erkennt Directory-Traversal-Muster.

Remote Code Execution (A08). Der Angreifer schleust ausführbaren Code in die Anwendung ein. Die WAF erkennt verdächtige Payloads, die auf Code-Ausführung hindeuten.

Server-Side Request Forgery / SSRF (A10). Der Angreifer bringt den Server dazu, Anfragen an interne Ressourcen zu senden. Die WAF erkennt Anfragen, die interne IP-Adressen oder localhost-URLs enthalten.

Brute-Force-Angriffe. Automatisierte Login-Versuche mit gestohlenen Credentials. Die WAF erkennt und limitiert wiederholte fehlgeschlagene Login-Versuche.

Bot-Traffic. Automatisierte Zugriffe durch Scraper, Crawler und bösartige Bots. Die WAF erkennt Bot-Signaturen und ungewöhnliche Zugriffsmuster.

WAF-Regelwerke

OWASP Core Rule Set (CRS)

Das OWASP Core Rule Set ist ein frei verfügbares, community-gepflegtes Regelwerk für WAFs. Es ist der De-facto-Standard für Open-Source-WAFs und wird von ModSecurity, Coraza, Caddy-WAF und mehreren kommerziellen WAFs unterstützt.

Das CRS arbeitet mit einem Scoring-System: Jede Regel, die eine Anomalie in einer Anfrage erkennt, vergibt Punkte. Wenn die Gesamtpunktzahl einer Anfrage einen konfigurierbaren Schwellwert überschreitet (Standard: 5 für eingehende Anfragen), wird die Anfrage blockiert.

Dieses System hat einen entscheidenden Vorteil gegenüber dem einfachen Pattern-Matching: Eine einzelne verdächtige Zeichenfolge in einem langen Formular löst nicht sofort eine Blockierung aus. Erst die Kombination mehrerer verdächtiger Indikatoren führt zur Blockierung. Das reduziert False Positives erheblich.

Paranoia-Level

Das CRS kennt vier Paranoia-Level (PL1 bis PL4), die die Empfindlichkeit der Erkennung steuern:

PL1 (Standard): Grundlegende Regeln, die die offensichtlichsten Angriffe erkennen. Wenige False Positives. Empfohlen als Startpunkt.

PL2: Zusätzliche Regeln, die subtilere Angriffsmuster erkennen. Mehr False Positives, die getunt werden müssen.

PL3: Aggressive Erkennung, hohe False-Positive-Rate. Für Anwendungen mit hohem Schutzbedarf.

PL4: Maximale Erkennung, viele False Positives. Nur für besonders kritische Anwendungen nach umfangreichem Tuning.

Beginne mit PL1 und steigere schrittweise, nachdem du die False Positives auf jeder Stufe bearbeitet hast.

Deployment-Optionen

Option 1: Nginx + ModSecurity / Coraza

Die klassische Open-Source-Lösung. Nginx als Reverse Proxy, ModSecurity (oder dessen Nachfolger Coraza) als WAF-Engine, OWASP CRS als Regelwerk.

Nginx ist der am weitesten verbreitete Reverse Proxy und Webserver. Er ist leichtgewichtig, performant und extrem gut dokumentiert.

ModSecurity ist die traditionsreiche WAF-Engine, die mit dem OWASP CRS zusammenarbeitet. Achtung: ModSecurity 3 (libmodsecurity) wird seit 2024 nicht mehr aktiv weiterentwickelt. Der empfohlene Nachfolger ist Coraza, eine in Go geschriebene WAF-Engine, die vollständig kompatibel mit dem OWASP CRS ist und aktiv weiterentwickelt wird.

Typisches Setup:

1. Nginx als Reverse Proxy vor deinen Webanwendungen
2. Coraza als WAF-Modul in Nginx integriert
3. OWASP CRS als Regelwerk geladen
4. SSL-Terminierung mit Let's Encrypt Zertifikaten (automatische Erneuerung via certbot)
5. Logging an zentrales Log-Management

Option 2: Traefik + CrowdSec

Eine modernere Alternative, besonders für Container-basierte Umgebungen.

Traefik ist ein Reverse Proxy, der speziell für dynamische Infrastrukturen entwickelt wurde (Docker, Kubernetes). Er erkennt Backend-Services automatisch und konfiguriert sich selbst.

CrowdSec ist eine Open-Source-Sicherheitsplattform, die als WAF-Ergänzung funktioniert. Sie analysiert Logs und Zugriffsmuster, erkennt bösartiges Verhalten und blockiert Angreifer. Besonderheit: CrowdSec teilt Bedrohungsinformationen zwischen allen Teilnehmern der Community. Wenn eine IP-Adresse bei einem anderen CrowdSec-Nutzer als bösartig erkannt wird, wird sie auch bei dir blockiert.

Option 3: Firewall-integrierte WAF

Viele NGFWs bieten eine integrierte WAF-Funktion: Fortinet FortiWeb, Sophos WAF (in der XGS-Serie), Barracuda WAF, F5 BIG-IP ASM.

Vorteile: Zentrale Verwaltung, keine zusätzliche Infrastruktur, Integration mit dem vorhandenen Firewall-Ökosystem. Nachteile: Oft weniger flexibel als dedizierte Lösungen, Performance-Einbußen auf der Firewall, teilweise eingeschränkte Regelwerk-Anpassung.

Option 4: Cloud-WAF

Cloud-basierte WAFs sitzen vor deiner gesamten Web-Infrastruktur und filtern den Datenverkehr, bevor er dein Netzwerk überhaupt erreicht. Du änderst deine DNS-Einträge, sodass der Datenverkehr zuerst durch die Cloud-WAF läuft.

Cloudflare WAF: Der Marktführer für Cloud-WAF. Einfache Einrichtung (DNS-Änderung), umfangreiches Regelwerk, DDoS-Schutz inklusive, Bot-Management. Kostenlose Stufe verfügbar, Pro- und Business-Pläne für erweiterte WAF-Funktionen.

AWS WAF: Für Anwendungen, die auf AWS laufen. Flexible Regelkonfiguration, Integration mit CloudFront und Application Load Balancer.

Azure Front Door + WAF: Für Azure-basierte Anwendungen. Managed-Regelwerk basierend auf OWASP CRS.

Vorteile von Cloud-WAFs:

• Keine eigene Infrastruktur nötig
• Automatische Signatur-Updates
• DDoS-Schutz oft inklusive
• Globales Netzwerk reduziert Latenz
• Einfache Einrichtung

Nachteile von Cloud-WAFs:

• Dein gesamter Webverkehr läuft über einen Drittanbieter
• Datenschutz-Bedenken (insbesondere bei US-Anbietern und DSGVO)
• Abhängigkeit vom Cloud-Anbieter (Ausfälle des Anbieters betreffen deine Website)
• Laufende Kosten, die bei steigendem Traffic wachsen
• Weniger Kontrolle über das Regelwerk

SSL/TLS-Terminierung: Best Practices

Der Reverse Proxy übernimmt typischerweise die SSL/TLS-Terminierung. Das hat mehrere Vorteile:

• Zentrale Zertifikatsverwaltung an einer Stelle statt auf jedem Backend-Server
• Automatische Zertifikaterneuerung mit Let's Encrypt / ACME
• Performance-Entlastung der Backend-Server
• Möglichkeit zur SSL-Inspektion (WAF kann den entschlüsselten Traffic analysieren)

TLS-Konfiguration

Konfiguriere den Reverse Proxy mit aktuellen TLS-Einstellungen:

• Mindestens TLS 1.2, idealerweise TLS 1.3 (TLS 1.0 und 1.1 sind veraltet und unsicher)
• Cipher Suites: Nur starke Cipher Suites zulassen. TLS 1.3 verwendet ausschließlich AEAD-Cipher (AES-256-GCM, ChaCha20-Poly1305). Für TLS 1.2: ECDHE-basierte Cipher Suites bevorzugen.
• HSTS (HTTP Strict Transport Security): Header setzen, der dem Browser mitteilt, die Website nur über HTTPS aufzurufen. Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
• OCSP Stapling: Beschleunigt die Zertifikatvalidierung und reduziert die Abhängigkeit von externen OCSP-Servern.

Security-Header

Der Reverse Proxy ist die ideale Stelle, um Security-Header zu setzen, die die Backend-Anwendungen nicht selbst setzen:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; style-src 'self' 'unsafe-inline'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

Diese Header schützen vor XSS, Clickjacking und anderen browserseitigen Angriffen.

WAF-Tuning: Der kritische Erfolgsfaktor

Eine WAF im Default-Modus wird legitime Anfragen blockieren. Ein Online-Shop, dessen Produktbeschreibungen HTML-Fragmente enthalten, ein CMS, dessen Editor JavaScript-Code in Formularen sendet, ein API-Endpunkt, der JSON-Payloads mit Sonderzeichen verarbeitet: all das kann WAF-Regeln auslösen.

Schrittweises Vorgehen

Phase 1: Detection Mode (2 bis 4 Wochen). Die WAF analysiert den Datenverkehr und loggt verdächtige Anfragen, blockiert aber nichts. Du sammelst Daten und verstehst, welche Regeln bei deiner spezifischen Anwendung feuern.

Phase 2: False-Positive-Analyse. Gehe die geloggten Alerts durch und identifiziere False Positives. Typische Quellen:

• Formularfelder, die HTML oder SQL-ähnliche Syntax enthalten (z. B. CMS-Editoren)
• API-Endpunkte, die Base64-kodierte Daten übertragen
• Upload-Funktionen, die Dateien mit verdächtigen Inhalten akzeptieren
• Monitoring- und Health-Check-Anfragen

Phase 3: Ausnahmen konfigurieren. Für jede bestätigte False Positive konfigurierst du eine Ausnahme:

• Bestimmte Regeln für bestimmte URLs deaktivieren (z. B. SQL-Injection-Regeln für den CMS-Editor-Endpunkt)
• Bestimmte Parameter von der Prüfung ausnehmen (z. B. den Content-Parameter des WYSIWYG-Editors)
• Den Anomalie-Schwellwert für bestimmte Pfade anpassen

Phase 4: Prevention Mode aktivieren. Schalte die WAF schrittweise in den Blocking-Modus. Beginne mit den unkritischsten Anwendungen und erweitere schrittweise. Überwache die Logs intensiv in den ersten Tagen nach der Umschaltung.

Phase 5: Kontinuierliches Monitoring. Überwache dauerhaft die WAF-Logs auf neue False Positives (z. B. nach einem Application-Update) und auf tatsächliche Angriffe. In ISMS Lite dokumentierst du die WAF-Konfiguration als technische Maßnahme und trackst die Tuning-Zyklen als wiederkehrende Aufgabe. Aktualisiere das Regelwerk regelmäßig (OWASP CRS veröffentlicht mehrmals jährlich Updates).

Rate Limiting und DDoS-Schutz

Neben der WAF-Funktion bietet der Reverse Proxy eine weitere wichtige Schutzschicht: Rate Limiting. Du begrenzst die Anzahl der Anfragen, die ein Client (identifiziert über IP-Adresse) in einem bestimmten Zeitraum senden darf.

Typische Rate Limits:

• Login-Endpunkte: 5 Anfragen pro Minute pro IP (Schutz vor Brute Force)
• API-Endpunkte: 100 Anfragen pro Minute pro API-Key
• Allgemeine Seiten: 60 Anfragen pro Minute pro IP

Rate Limiting schützt vor Brute-Force-Angriffen, einfachen DDoS-Angriffen und automatisiertem Scraping. Gegen verteilte DDoS-Angriffe mit tausenden IP-Adressen ist Rate Limiting allein nicht ausreichend, dafür brauchst du einen vorgelagerten DDoS-Schutz (Cloudflare, AWS Shield oder ähnliche).

Architektur: Reverse Proxy in der DMZ

Der Reverse Proxy gehört in die DMZ, nicht ins interne Netzwerk. Die Architektur:

1. Internet-Traffic erreicht den Reverse Proxy in der DMZ
2. Der Reverse Proxy terminiert SSL, prüft die WAF-Regeln und leitet legitime Anfragen weiter
3. Die Weiterleitung erfolgt über die Firewall in die Server-Zone
4. Die Firewall erlaubt nur definierten Traffic vom Reverse Proxy zu den Backend-Servern (Port 80/443, nur die IP des Reverse Proxy)
5. Die Backend-Server sind aus dem Internet nicht direkt erreichbar

Wenn der Reverse Proxy kompromittiert wird, hat der Angreifer Zugriff auf die DMZ, aber nicht auf die Server-Zone. Die Firewall zwischen DMZ und Server-Zone verhindert eine laterale Bewegung.

Monitoring und Alerting

Was du überwachen solltest

• Blockierte Anfragen pro Stunde: Ein plötzlicher Anstieg kann auf einen gezielten Angriff hindeuten
• Top-10 blockierte Regeln: Zeigt die häufigsten Angriffstypen
• Top-10 angegriffene URLs: Zeigt, welche Endpunkte am meisten attackiert werden
• Top-10 angreifende IPs: Zeigt die aktivsten Angreifer
• Response-Zeiten der Backend-Server: Ein Anstieg kann auf einen Application-Layer-DDoS hindeuten
• Fehlerrate (5xx-Antworten): Kann auf Probleme hinweisen, die durch WAF-Blocking verursacht werden

Alerting

Konfiguriere Alarme für:

• Mehr als X blockierte Anfragen pro Minute von einer einzelnen IP (gezielter Angriff)
• Mehr als X verschiedene Angreifer-IPs pro Stunde (verteilter Angriff)
• Neue Angriffsmuster, die bisher nicht beobachtet wurden
• Backend-Server nicht erreichbar (Ausfall)
• SSL-Zertifikat läuft in weniger als 14 Tagen ab

Weiterführende Artikel

• Firewall-Konfiguration für KMU: Regeln, Zonen und Best Practices
• Intrusion Detection und Prevention (IDS/IPS) für den Mittelstand
• DNS-Sicherheit: DNS-Filtering, DNSSEC und DNS over HTTPS
• Schwachstellenmanagement aufbauen: Scannen, bewerten, beheben
• Netzwerksegmentierung für KMU: Warum und wie du dein Netz aufteilst

Ein Reverse Proxy mit WAF ist keine Garantie für die Sicherheit deiner Webanwendungen. SQL-Injection-Schwachstellen müssen trotzdem im Code behoben werden, und ein Secure Development Lifecycle ist weiterhin unverzichtbar. Aber eine WAF bietet eine zusätzliche Verteidigungsschicht, die Angriffe blockiert, während die Schwachstellen behoben werden, und die Zero-Day-Exploits abfängt, für die es noch keinen Patch gibt. In einer Zeit, in der Webanwendungen das häufigste Angriffsziel sind, ist diese Schicht nicht optional.