Web Application Firewall: ModSecurity, Cloudflare oder eigene Lösung?\n\n> Key Takeaways\n> - Eine WAF schützt Webanwendungen auf Schicht 7 (HTTP) vor Angriffen wie SQL Injection, XSS und Path Traversal – klassische Firewalls können das nicht.\n> - ModSecurity mit OWASP CRS ist mächtig und kostenlos, erfordert aber aktive Pflege und technisches Know-how.\n> - Cloudflare WAF ist in Minuten aktiv, skaliert automatisch und erfordert keine Serveradministration – aber Ihre Requests laufen durch Cloudflare-Infrastruktur.\n> - Azure Application Gateway WAF v2 ist die natürliche Wahl, wenn Ihre Infrastruktur bereits in Azure liegt.\n> - Für NIS-2-pflichtige Unternehmen ist eine WAF mit nachweisbarem Logging kein Nice-to-have, sondern Teil der Nachweispflicht.\n\n---\n\n## Warum eine normale Firewall nicht ausreicht\n\nEine klassische Netzwerk-Firewall arbeitet auf den Schichten 3 und 4 des OSI-Modells: Sie filtert nach IP-Adressen, Ports und Protokollen. Das ist notwendig, aber für Webanwendungen nicht hinreichend.\n\nAngriffe auf Web-Frontends wie SQL Injection, Cross-Site Scripting (XSS), Remote File Inclusion oder Command Injection verstecken sich in HTTP-GET- und POST-Parametern – also im erlaubten Traffic auf Port 443. Für eine klassische Firewall sieht das wie normaler HTTPS-Verkehr aus.\n\nGenau hier setzt die Web Application Firewall (WAF) an: Sie terminiert den TLS-Stream, liest den HTTP-Request auf Anwendungsebene und prüft Header, Cookies, Query-Strings und Request-Body gegen bekannte Angriffsmuster.\n\nDas OWASP Top 10 – die etablierte Liste der häufigsten Webanwendungs-Schwachstellen – beschreibt exakt die Bedrohungsklassen, die eine WAF adressieren soll:\n\n- A03: Injection (SQL, NoSQL, LDAP)\n- A07: Identification and Authentication Failures\n- A03/A01: XSS und Broken Access Control\n\nKein Produkt blockiert alle Angriffe automatisch. Aber ohne WAF ist das Angriffsrisiko auf Webanwendungen deutlich höher – insbesondere bei veralteten CMS-Installationen oder Custom-Code mit wenig Security-Review.\n\n---\n\n## Option 1: ModSecurity mit OWASP Core Rule Set\n\n### Was ist ModSecurity?\n\nModSecurity ist ein Open-Source-WAF-Modul, das als Plugin für Apache, Nginx und IIS läuft. Es wurde 2002 veröffentlicht und ist heute unter dem Dach der OWASP Foundation aktiv. Die eigentliche Schutzwirkung entsteht nicht durch ModSecurity allein, sondern durch das OWASP Core Rule Set (CRS) – eine umfangreiche Regelsammlung, die aktiv gepflegt und regelmäßig auf neue Angriffsvektoren erweitert wird.\n\n### Installation und Grundkonfiguration (Nginx)\n\nBei Debian/Ubuntu-Systemen mit Nginx:\n\nbash\napt install libmodsecurity3 libnginx-mod-security\n\n\nDas OWASP CRS einbinden:\n\nbash\ngit clone https://github.com/coreruleset/coreruleset /etc/nginx/modsec/crs\ncp /etc/nginx/modsec/crs/crs-setup.conf.example /etc/nginx/modsec/crs/crs-setup.conf\n\n\nMinimale modsecurity.conf:\n\nnginx\nmodsecurity on;\nmodsecurity_rules_file /etc/nginx/modsec/modsec-includes.conf;\n\n\nmodsec-includes.conf:\n\n\nInclude /etc/nginx/modsec/modsecurity.conf\nInclude /etc/nginx/modsec/crs/crs-setup.conf\nInclude /etc/nginx/modsec/crs/rules/*.conf\n\n\n### Paranoia Level und Detection Mode\n\nDer CRS kennt vier Paranoia Level (PL). PL1 aktiviert grundlegende Regeln mit wenigen False Positives, PL4 ist für hochsensible Anwendungen gedacht und blockiert aggressiv.\n\nEmpfohlener Einstieg: SecDefaultAction auf detection only setzen, Logs zwei Wochen analysieren, dann schrittweise auf deny umstellen:\n\n```apache\n# In crs-setup.conf:\nSecDefaultAction \