Wie Sie eine Website mit einer WAF schützen

Was ist WAF (Web Application Firewall)

Eine Web Application Firewall (WAF) ist ein Sicherheitssystem, das bösartigen HTTP-Verkehr zu Ihrer Webanwendung filtert, überwacht und blockiert. Im Gegensatz zu einer klassischen Netzwerk-Firewall, die auf der Ebene von IP-Adressen und Ports arbeitet, versteht eine WAF das HTTP-Protokoll und kann den Inhalt der Anfragen analysieren – URL-Parameter, POST-Daten, Cookies, HTTP-Header und Anfrage-Body. Dies ermöglicht es ihr, Angriffe zu erkennen und zu blockieren, die eine klassische Firewall passieren würden.

Stellen Sie sich eine WAF wie einen Türsteher am Eingang eines Restaurants vor, der jeden Gast überprüft. Eine klassische Firewall prüft nur, ob der Gast eine Einladung hat (richtige IP und Port). Eine WAF prüft, ob der Gast Waffen, gefälschte Dokumente oder böse Absichten hat – sie analysiert das Verhalten, nicht nur die Identität. In einer Welt, in der täglich etwa 2.800 Cyberangriffe stattfinden, ist eine WAF eine kritische Schutzebene für jede Website.

Wie eine WAF funktioniert

Die WAF wird zwischen dem Nutzer und dem Webserver platziert und analysiert jede HTTP-Anfrage, bevor sie Ihre Anwendung erreicht. Entscheidungen werden auf Basis vordefinierter Regeln und Algorithmen getroffen.

Erkennungsmodelle

Eine WAF verwendet zwei Hauptmodelle zur Angriffserkennung. Das Negative Security Model (Blacklisting) blockiert Anfragen, die bekannte bösartige Muster enthalten – SQL-Injection-Strings, XSS-Payloads, Path-Traversal-Sequenzen und Ähnliches. Dies ist der häufigste Ansatz, weil er einfacher zu implementieren ist, aber er kann keine neuen, unbekannten Angriffe (Zero-Day) erkennen. Das Positive Security Model (Whitelisting) definiert, was erlaubt ist, und blockiert alles andere. Dieses Modell ist sicherer, erfordert aber eine detaillierte Konfiguration für jede Anwendung, da Sie jeden legitimen Parameter, URL und Datenformat definieren müssen.

Wovor eine WAF schützt

Die WAF schützt vor den häufigsten Webangriffen, die in der OWASP Top 10-Liste definiert sind: SQL Injection (Einschleusen von SQL-Code über Formulare und URL-Parameter, um auf die Datenbank zuzugreifen oder sie zu ändern), Cross-Site Scripting – XSS (Einschleusen von bösartigem JavaScript-Code, der im Browser anderer Nutzer ausgeführt wird), Cross-Site Request Forgery – CSRF (Zwingen eines authentifizierten Nutzers zu einer unerwünschten Aktion), Local/Remote File Inclusion (Laden bösartiger Dateien über den PHP-Include-Mechanismus), Path Traversal (Zugriff auf Dateien außerhalb des Web-Roots mit ../-Sequenzen), Command Injection (Ausführung von Systembefehlen über die Webanwendung) und Brute-Force-Angriffe auf Login-Formulare.

Aktionen, die eine WAF ergreifen kann

Wenn die WAF eine verdächtige Anfrage erkennt, kann sie verschiedene Aktionen ergreifen: die Anfrage blockieren und einen 403 Forbidden-Fehler zurückgeben, die Anfrage zulassen, aber zur späteren Analyse loggen (Monitoring-Modus), eine CAPTCHA-Prüfung auslösen, um festzustellen, ob der Nutzer ein Mensch oder Bot ist, Anfragen von einer bestimmten IP-Adresse rate limitieren oder eine IP-Adresse, die viele bösartige Anfragen sendet, temporär blockieren. Moderne WAF-Systeme kombinieren diese Aktionen je nach Schweregrad der Bedrohung.

WAF-Typen

WAF-Lösungen unterscheiden sich nach Implementierungsort und Architektur.

Cloud-basierte WAF

Eine Cloud-WAF wird durch Änderung der DNS-Einträge implementiert – der Traffic wird über einen Cloud-Anbieter geleitet, der bösartige Anfragen herausfiltert, bevor sie Ihren Server erreichen. Beispiele: Cloudflare WAF, Sucuri, AWS WAF, Akamai. Vorteile sind die einfache Implementierung (keine Server-Änderungen erforderlich), Skalierbarkeit (Cloud-Infrastruktur absorbiert DDoS-Angriffe), automatische Regel-Updates und CDN-Vorteile (schnelleres Laden der Website). Nachteile sind die Abhängigkeit von Drittanbietern, potenzielle Latenz (zusätzlicher Hop) und monatliche Kosten.

Host-basierte WAF

Eine Host-basierte WAF wird direkt auf dem Webserver als Modul oder Anwendung installiert. Das bekannteste Beispiel ist ModSecurity, das sich mit Apache-, Nginx- und LiteSpeed-Webservern integrieren lässt. Vorteile sind die vollständige Kontrolle über die Konfiguration, kein zusätzlicher Netzwerk-Hop, Zugriff auf detaillierte Logs auf dem Server und keine monatlichen Kosten für einen Cloud-Dienst. Nachteile sind, dass technisches Wissen für Konfiguration und Wartung erforderlich ist, Serverressourcen für die Analyse von Anfragen verbraucht werden und die Aktualisierung von Regeln Ihre Verantwortung ist.

Hybrid-Ansatz

Der beste Schutz ist eine Kombination aus Cloud- und Host-basierter WAF. Die Cloud-WAF (Cloudflare) filtert volumetrische Angriffe und bekannte Bedrohungen, bevor sie den Server erreichen, während die Host-basierte WAF (ModSecurity) eine tiefe Inspektion der Anfragen bietet, die die Cloud-Ebene passieren. Diese Defense-in-Depth-Strategie stellt sicher, dass selbst wenn eine Ebene einen Angriff durchlässt, die andere Ebene ihn abfängt.

Cloudflare WAF – Konfiguration

Cloudflare ist die beliebteste Cloud-WAF für kleine und mittlere Websites aufgrund des kostenlosen Plans, der grundlegenden Schutz beinhaltet, und erschwinglicher kostenpflichtiger Pläne mit erweiterten WAF-Funktionen.

Grundeinrichtung

Um die Cloudflare WAF zu nutzen, müssen Sie ein Cloudflare-Konto erstellen, Ihre Domain hinzufügen und die Nameserver auf die von Cloudflare ändern. Nach der DNS-Propagation (meist 24–48 Stunden) läuft der gesamte Traffic zu Ihrer Website über das Cloudflare-Netzwerk. Der kostenlose Plan bietet DDoS-Schutz, ein kostenloses Zertifikat zur Verschlüsselung, CDN und grundlegenden Bot-Schutz. WAF-Regeln sind ab dem Pro-Plan (20 $/Monat) verfügbar.

Managed Rules

Cloudflare Managed Rules sind vorkonfigurierte Regeln, die vor bekannten Schwachstellen schützen. Der Cloudflare Managed Ruleset deckt die OWASP Top 10-Angriffe ab, das Cloudflare WordPress Ruleset ist speziell für WordPress-Schwachstellen konzipiert, und Cloudflare Leaked Credentials Detection prüft, ob Nutzer kompromittierte Passwörter verwenden. Diese Regeln werden automatisch aktualisiert, wenn neue Bedrohungen entdeckt werden.

Custom Rules

Neben den Managed Rules können Sie eigene WAF-Regeln für die spezifischen Bedürfnisse Ihrer Website erstellen. Zum Beispiel: Zugriff auf die wp-admin-Seite nur für Ihre IP-Adresse erlauben, Zugriff auf xmlrpc.php einschränken, Anfragen aus bestimmten Ländern blockieren, CAPTCHA für die Login-Seite verlangen oder User Agents bekannter Bots und Scanner blockieren. Custom Rules werden im Cloudflare-Dashboard mit einem visuellen Editor oder der Wire-Format-Expression-Syntax erstellt.

Rate Limiting

Cloudflare Rate Limiting ermöglicht die Begrenzung der Anzahl von Anfragen pro IP-Adresse in einem bestimmten Zeitraum. Dies ist ein effektiver Schutz vor Brute-Force-Angriffen und API-Missbrauch. Zum Beispiel: Login-Seite auf 5 Anfragen pro Minute pro IP-Adresse begrenzen, API-Endpoints auf 100 Anfragen pro Minute begrenzen. Anfragen, die das Limit überschreiten, können blockiert werden, eine CAPTCHA auslösen oder auf eine Fehlerseite umgeleitet werden.

ModSecurity – Konfiguration

ModSecurity ist eine Open-Source-WAF-Engine, die als Modul auf Apache-, Nginx- und LiteSpeed-Servern läuft. Es ist die am häufigsten eingesetzte Host-basierte WAF in der Hosting-Branche.

Installation und Grundeinrichtung

Auf cPanel-Servern wird ModSecurity über WHM (Web Host Manager) mit einem Klick installiert. Auf Linux-Servern ohne cPanel wird es aus dem Paket installiert (apt install libapache2-mod-security2 auf Ubuntu/Debian). Nach der Installation läuft ModSecurity im Detection-Only-Modus – verdächtige Anfragen werden geloggt, aber nicht blockiert. Dies wird zu Beginn empfohlen, um False Positives zu identifizieren, bevor in den Enforcing-Modus gewechselt wird.

OWASP Core Rule Set (CRS)

ModSecurity an sich enthält keine Regeln – es benötigt ein Rule Set. Das OWASP Core Rule Set (CRS) ist das meistgenutzte Regelwerk, das die OWASP Top 10-Schwachstellen abdeckt. CRS verwendet ein Anomaly-Scoring-System, bei dem jedes verdächtige Element einer Anfrage Punkte hinzufügt, und die Anfrage wird erst blockiert, wenn der Gesamtscore einen Schwellenwert überschreitet (Standard ist 5). Dies reduziert False Positives, weil ein verdächtiges Element allein nicht zur Blockade führt – es müssen mehrere Indikatoren für bösartiges Verhalten vorliegen.

Feinabstimmung der Regeln

ModSecurity-Regeln generieren oft False Positives – sie blockieren legitime Anfragen. Häufige Beispiele sind: WordPress-Editor, der HTML/CSS-Code sendet (sieht aus wie XSS), Firewall-Plugins, deren Kontrollpanel-Formulare Sicherheitsbegriffe enthalten, und Kontaktformulare mit spezifischem Inhalt. Zur Lösung von False Positives können Sie: eine spezifische Regel für eine bestimmte URL oder ein Verzeichnis deaktivieren, den Anomaly-Scoring-Schwellenwert erhöhen oder eine Whitelist-Regel für bekannte sichere Anfragen hinzufügen. Überprüfen Sie das ModSecurity-Audit-Log, um zu identifizieren, welche Regeln False Positives generieren.

ModSecurity auf LiteSpeed

LiteSpeed Web Server hat integrierte Unterstützung für ModSecurity-Regeln ohne ein externes Modul. LiteSpeed verarbeitet ModSecurity-Regeln schneller als Apache, weil es eine optimierte Engine verwendet, die für die Event-Driven-Architektur von LiteSpeed konzipiert ist. Die Konfiguration ist identisch wie bei Apache – gleiche Regeln, gleiche Direktiven, aber bessere Leistung.

WAF für WordPress – spezifische Regeln

WordPress-Websites sind das häufigste Angriffsziel und erfordern neben generischen auch spezifische WAF-Regeln.

Schutz des Adminbereichs

Beschränken Sie den Zugriff auf /wp-admin/ und /wp-login.php auf bekannte IP-Adressen oder fordern Sie zusätzliche Authentifizierung. Blockieren Sie den Zugriff auf sensible Dateien: wp-config.php, xmlrpc.php, wp-cron.php (erlauben Sie nur serverseitigen Zugriff). Verhindern Sie die Nutzerenumeration, indem Sie Anfragen mit dem ?author=-Parameter blockieren, der Benutzernamen preisgibt.

Schutz vor Plugin-Schwachstellen

WordPress-Plugins sind der häufigste Angriffsvektor. WAF-Regeln sollten blockieren: direkten Zugriff auf PHP-Dateien im Verzeichnis wp-content/plugins/ (außer für AJAX-Handler), Upload bösartiger Dateitypen (.php, .phtml, .pht getarnt als Bild) und Ausnutzung bekannter Schwachstellen in beliebten Plugins (Cloudflare und ModSecurity CRS haben spezifische Regeln für WordPress-Plugin-Schwachstellen).

Bot-Schutz

Ein großer Prozentsatz des Traffics auf WordPress-Websites kommt von Bots – guten (Google Bot, Bing Bot) und schlechten (Schwachstellen-Scanner, Content-Scraper, Brute-Force-Bots). Die WAF sollte: bekannte gute Bots basierend auf User Agent und IP-Bereichen zulassen, bekannte schlechte Bots blockieren oder rate-limitieren, CAPTCHA für verdächtige Bots auslösen und die Crawl-Rate für alle Bots begrenzen, damit sie den Server nicht überlasten.

Monitoring und Wartung der WAF

Eine WAF ist keine „Set and forget"-Lösung. Sie erfordert regelmäßiges Monitoring und Anpassung.

Log-Analyse

Überprüfen Sie regelmäßig WAF-Logs, um zu identifizieren: False Positives, die legitime Nutzer blockieren (und passen Sie Regeln an), Angriffsmuster, die auf einen gezielten Angriff hinweisen können, IP-Adressen oder Bereiche, die viele bösartige Anfragen generieren, und neue Angriffstypen, die möglicherweise nicht von bestehenden Regeln abgedeckt sind. Cloudflare bietet ein visuelles Dashboard zur Analyse, während ModSecurity Textlogs verwendet, die Sie mit Tools wie GoAccess oder dem ELK-Stack analysieren können.

Aktualisierung der Regeln

Neue Schwachstellen werden täglich entdeckt, und WAF-Regeln müssen aktualisiert werden, um sie abzudecken. Cloud-WAF-Lösungen (Cloudflare) aktualisieren Regeln automatisch. Für ModSecurity mit OWASP CRS aktualisieren Sie das Rule Set mindestens einmal im Monat. Verfolgen Sie Sicherheits-Newsletter für WordPress, Plugins und Themes, die Sie verwenden, und fügen Sie spezifische Regeln für neu entdeckte Schwachstellen hinzu, bevor ein Patch verfügbar ist (Virtual Patching).

Häufige Fehler bei der Verwendung von WAF

• Zu aggressive Regeln: Eine WAF, die legitime Nutzer blockiert, ist schlimmer als gar keine WAF, weil sie Besucher und Kunden von der Website vertreibt. Beginnen Sie im Monitoring-Modus und verschärfen Sie die Regeln schrittweise.
• Verlassen nur auf die WAF: Die WAF ist eine Schutzebene, kein Ersatz für aktualisierte Software, starke Passwörter, Sicherheitskonfiguration und Backups. Defense-in-Depth-Strategie ist der einzig richtige Ansatz.
• Ignorieren der Logs: WAF-Logs sind Gold wert – sie zeigen Ihnen genau, wer was auf Ihrer Website versucht. Logs zu ignorieren bedeutet, wichtige Bedrohungssignale zu verpassen.
• Veraltete Regeln: Eine WAF mit jahrealten Regeln ist wie ein Antivirus mit veralteter Datenbank – sie erkennt keine neuen Bedrohungen.
• Kein Testen nach Änderungen: Jede Änderung an WAF-Regeln muss getestet werden, um zu bestätigen, dass sie keine legitimen Website-Funktionen blockiert.

Fazit

Eine WAF ist eine essenzielle Schutzebene für jede Website, insbesondere für WordPress-basierte Websites, die das häufigste Angriffsziel sind. Die Kombination aus Cloud-WAF (Cloudflare) für den Schutz vor volumetrischen Angriffen und DDoS mit einer Host-basierten WAF (ModSecurity) für die tiefe Inspektion der Anfragen bietet umfassenden Schutz. Beginnen Sie im Monitoring-Modus, verfolgen Sie Logs, passen Sie die Regeln für Ihre Website an und aktualisieren Sie regelmäßig die Rule Sets. Bei BeoHosting kommen alle Hosting-Pakete mit vorkonfigurierter ModSecurity-WAF mit OWASP Core Rule Set, optimiert für WordPress, und wir empfehlen, den kostenlosen Cloudflare-Plan für eine zusätzliche Schutzebene und CDN-Vorteile zu nutzen.