Nginx mit Modsecurity Whitelists

Voraussetzungen

• Webserver mit ModSecurity (z. B. NGINX + ModSecurity v3)
• OWASP CRS kann verwendet werden, aber nicht erforderlich
• Pfad zur Hauptregeldatei z. B.: /etc/modsecurity/main.conf

Ziel

• Nur definierte Methoden und Pfade zulassen
• Alles andere standardmäßig ablehnen
• Pfad-Whitelist aus externer Datei laden

Datei mit erlaubten URIs

Pfad: /etc/modsecurity/allowed_post_uris.txt

Inhalt:

/safe/upload
/safe/form
/safe/login

Regelwerk (Whitelist-Ansatz)

Datei: /etc/modsecurity/custom-rules/default-deny.conf

# Erlaube POST nur für explizit freigegebene URIs
SecRule REQUEST_METHOD "@streq POST" "chain,id:2000,phase:1,deny,status:403,msg:'POST not allowed on this URI'"
    SecRule REQUEST_URI "!@pmFromFile /etc/modsecurity/allowed_post_uris.txt"

# Erlaube GET auf bestimmte Pfade
SecRule REQUEST_METHOD "@streq GET" "chain,id:2001,phase:1,pass,nolog,ctl:ruleEngine=Off"
    SecRule REQUEST_URI "@beginsWith /safe/"

# Optional: weitere erlaubte Methoden einfügen
# z. B. HEAD, OPTIONS, PUT usw. je nach Bedarf

# Marker zur Trennung von Erlaubnis und Default-Ablehnung
SecMarker ALLOWLIST_DONE

# Alles andere wird abgelehnt
SecRule REQUEST_URI ".*" "id:2999,phase:1,deny,status:403,msg:'Blocked by default policy',skipAfter:ALLOWLIST_DONE"

Einbindung in Hauptregeldatei

Pfad: /etc/modsecurity/main.conf

# Optional: OWASP CRS laden
Include /usr/share/modsecurity-crs/crs-setup.conf
Include /usr/share/modsecurity-crs/rules/*.conf

# Eigene Regeln einbinden
Include /etc/modsecurity/custom-rules/default-deny.conf

NGINX-Integration

In der vHost-Konfiguration oder nginx.conf:

modsecurity on;
modsecurity_rules_file /etc/modsecurity/main.conf;

Neustart / Reload

• systemctl reload nginx
• Fehlerprüfung mit: nginx -t

Testbeispiele

Methode	URI	Erwartung
POST	/safe/upload	200 OK
POST	/badpath	403 Forbidden
GET	/safe/form	200 OK
GET	/admin	403 Forbidden

Hinweise

• @pmFromFile lädt zeilenweise rohe Pfadstrings ohne Regex.
• Jede Methode (POST, GET, PUT, ...) benötigt eigene Allow-Regel.
• Die Catch-All-Regel am Ende macht daraus eine echte Default-Deny-Policy.
• Die Regel-ID 2999 muss höher sein als alle anderen.

Erweiterung

• Cookie-Integritätsschutz: REQUEST_COOKIES validieren
• CSRF-Token-Validierung über eigene Variablen
• Separate Whitelist-Dateien für verschiedene Methoden

Fazit

Diese Konfiguration erreicht eine vergleichbare Zugriffskontrolle wie die Sophos XG Webserver Protection – vollständig transparent, erweiterbar und ohne GUI-Zwang.