ModSecurity und das OWASP CRS — die WAF-Regeln, die wir tatsächlich auf Apache ausliefern
14. Mai 2026 · 1 Min. Lesezeit · von Sudhanshu K.
Dies ist ein Auszug. Der vollständige Artikel liegt auf Medium.
ModSecurity ist eines dieser Werkzeuge, das fast jeder installiert hat und kaum jemand getunt hat. Das Muster in Audits ist konsistent: Das Modul ist geladen, das OWASP Core Rule Set ist mit Default-Einstellungen abgelegt, die Logs füllen sich mit Tausenden Alerts, die niemand liest, und entweder (a) läuft es seit Jahren still im DetectionOnly-Modus, oder (b) blockiert legitimen Traffic, und der Kunde weiß es nicht.
Beide Modi bedeuten, dass das WAF nichts Nützliches tut.
Warum sich 2026 bemühen, wenn Cloudflare existiert?
Drei Gründe, warum wir immer noch ModSecurity auf Origin-Level hinter einem Cloud-WAF deployen:
- Defense in Depth. Das Cloud-WAF ist eine Schicht. Wenn es falsch klassifiziert, oder der Kunde ein Regel-Paket nicht aktiviert hat, oder jemand die Origin-IP entdeckt, fängt die innere Schicht, was Edge verpasst hat.
- Anwendungsspezifische Regeln. Cloudflare weiß nicht, dass Ihr
/admin/export-Endpunkt niemals einSELECT-Schlüsselwort sehen sollte. ModSecurity am Origin schon. - Forensik. Das ModSecurity-Audit-Log gibt Ihnen die vollständige Anfrage, die die Regel ausgelöst hat. Cloud-WAFs geben gesampelte, verlustbehaftete Daten.
Die Basis-Konfiguration
ModSecurity 3 (libmodsecurity) mit dem Apache-Connector — nicht das Legacy-v2:
<IfModule security2_module>
SecRuleEngine On
SecRequestBodyAccess On
SecRequestBodyLimit 13107200
SecAuditEngine RelevantOnly
SecAuditLogParts ABIJDEFHZ
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/rules/*.conf
</IfModule>Dann die eigentliche Tuning-Arbeit — den richtigen Paranoia-Level wählen, Regeln auf die Allowlist setzen, die auf normalem Anwendungs-Traffic feuern, und die per-Route-Regeln schreiben, die Cloudflare nicht kann. Der vollständige Medium-Beitrag behandelt:
- Paranoia Level 1 → 4 — was jedes hinzufügt, und das Level, das wir standardmäßig ausliefern
- Den „False-Positive-Triage"-Workflow, den wir zwei Wochen lang fahren, bevor wir auf Block-Modus umschalten
- Custom-Regeln für gängige Anwendungspfade (Admin, API-Endpunkte, File-Uploads)
- Das Audit-Log an das SIEM senden und die Dashboards, die wir beobachten
- Die Regeln, die wir immer deaktivieren (und warum)
Weiter auf Medium.
Geht auf Medium weiter
Vollständigen Artikel auf Medium lesen