Web Application Firewall (WAF)¶

Die WAF prüft Anfragen an eine Website mit ModSecurity + OWASP Core Rule Set (CRS) und blockiert bekannte Angriffsmuster (SQL-Injection, XSS, Path-Traversal, Remote-Code-Execution) auf Nginx-Ebene, bevor sie die Anwendung erreichen. Sie ist pro Website opt-in — eine aktivierte WAF auf einer Site hat keinerlei Auswirkung auf andere Sites, auch nicht auf demselben Server.

Funktionsweise¶

Ein Admin oder — bei entsprechender Paket-Berechtigung — der Kunde selbst aktiviert die WAF für eine Website.
Der Agent stellt sicher, dass ModSecurity + OWASP-CRS auf dem Zielserver installiert sind, und trägt zwei Includes in den Nginx-Vhost der Site ein: die globale, enconf-kuratierte Regelbasis und eine per-Site-Konfigurationsdatei für Paranoia-Level, Ausnahmeregeln und den Detection-Only-Modus.
Jede Anfrage an die Website durchläuft die CRS-Regeln. Bei einem Treffer wird die Anfrage mit 403 abgewiesen und im Audit-Log protokolliert (außer im Detection-Only-Modus — dort wird nur geloggt).

Eigene, kuratierte Regel-Einbindung

enconf verlässt sich nicht auf die vom Debian-Paket mitgelieferte Standard-Verdrahtung (owasp-crs.load) — diese verwendet Direktiven, die vom Nginx-ModSecurity-Modul nicht unterstützt werden und nginx -t zum Scheitern bringen können. Stattdessen schreibt der Agent eine eigene, geprüfte Einbindung der CRS-Regeln und erzwingt SecRuleEngine On (das Debian-Paket liefert standardmäßig nur einen Log-Modus, der nichts blockiert).

WAF für eine Website aktivieren¶

Als Administrator¶

Navigieren Sie zu Websites und öffnen Sie die gewünschte Website
Im Bereich Performance & Sicherheit aktivieren Sie den Schalter WAF (ModSecurity)
Speichern — der Agent installiert ModSecurity bei Bedarf automatisch und rendert den Vhost neu

Zusätzlich steht unter System → WAF ein Button ModSecurity installieren zur Verfügung, um die Pakete auf einem Server vorab bereitzustellen, ohne eine Site zu aktivieren.

Als Kunde¶

Kunden mit der Paket-Berechtigung WAF sehen den Schalter im Website-Bearbeiten-Dialog und den Menüpunkt WAF in der Seitenleiste.

Berechtigung

Die WAF wird pro Paket über die Berechtigung WAF (perm_waf) freigeschaltet. Der maximal wählbare Paranoia-Level ist ebenfalls pro Paket begrenzbar (Max. WAF-Paranoia-Level, Standard 1) — Administratoren unterliegen dieser Grenze nicht.

Paranoia-Level¶

OWASP-CRS kennt vier Paranoia-Level. Ein höherer Level erkennt mehr Angriffsklassen, erhöht aber auch das Risiko von False Positives bei ungewöhnlichem, aber legitimem Traffic:

Level	Empfehlung
1 (Standard)	Für die meisten Websites geeignet — geringstes False-Positive-Risiko
2–3	Für Websites mit erhöhtem Schutzbedarf, nach kurzer Testphase im Detection-Only-Modus
4	Maximale Erkennung, spürbar höheres False-Positive-Risiko — nur mit sorgfältigem Monitoring

Detection-Only-Modus¶

Vor einer Umstellung auf einen höheren Paranoia-Level oder bei neu aktivierter WAF empfiehlt sich der Nur-Erkennung-Modus: Treffer werden protokolliert, aber nicht blockiert. So lässt sich anhand des Protokolls prüfen, ob legitimer Traffic der Website fälschlich anschlagen würde, bevor scharf geschaltet wird.

Regel-Ausnahmen¶

Erzeugt eine einzelne CRS-Regel einen False Positive (z. B. bei einer Anwendung mit ungewöhnlichem Eingabeformat), kann ihre Regel-ID gezielt für die betroffene Website ausgeschlossen werden, ohne den restlichen Schutz zu deaktivieren. Die Regel-ID eines Treffers findet sich in der Spalte Regel-ID des Protokolls.

Angriffsprotokoll¶

Der Tab Protokoll zeigt alle von ModSecurity ausgewerteten Ereignisse: Zeitpunkt, Client-IP, angefragte URI, Regel-ID, Meldungstext und Schweregrad. Administratoren können nach Website oder Domain filtern; Kunden sehen ausschließlich Ereignisse ihrer eigenen Websites.

Grenzen¶

Die WAF schützt vor bekannten Angriffsmustern auf Anfrage-Ebene. Sie ersetzt nicht Anwendungs-Updates, sichere Passwörter oder den Malware-Scanner, der bereits eingeschleusten Code im Dateisystem erkennt.
Eine fehlerhafte eigene Ausnahmeregel wird vor dem Übernehmen mit nginx -t geprüft — schlägt die Prüfung fehl, bleibt die vorherige, funktionierende Konfiguration aktiv statt eines Server-Ausfalls.