Kurz gesagt: ModSecurity ist eine Web Application Firewall, die im Webserver läuft; das OWASP Core Rule Set (CRS) liefert dazu frei verfügbare Regeln gegen verbreitete Angriffsarten. Für Apache empfiehlt das CRS-Projekt ModSecurity v2, für Nginx kommen der v3-Connector oder Coraza infrage. Starten Sie im Blockiermodus mit sehr hohen Anomalie-Schwellen, senken Sie diese schrittweise und behandeln Sie Fehlalarme mit gezielten Ausnahmen. Ein PHP-Update ersetzt das nicht.
Eine eigene WAF als zusätzliche Schicht
Seit PHP2Shell fragen viele Unternehmen, ob sie eine Web Application Firewall brauchen. Wer seine Websites über Cloudflare ausliefert, hat seit dem 21. Oktober 2026 laut Cloudflare automatisch Schutzregeln aktiv. Wer das nicht tut oder den Datenverkehr nicht über einen Dritten leiten will, kann eine WAF direkt auf dem eigenen Server betreiben.
Die bekannteste Kombination dafür ist ModSecurity mit dem OWASP Core Rule Set. Beides ist quelloffen und kostenlos. Das CRS ist eine Sammlung allgemeiner Erkennungsregeln, etwa gegen SQL-Injection, Cross-Site-Scripting oder das Einschleusen von Dateien. Das Projekt beschreibt sein Ziel selbst als allgemeine Angriffserkennung mit möglichst wenigen Fehlalarmen, als ein Baustein unter mehreren.
Damit ist auch die Grenze benannt. Eine WAF prüft Anfragen und Antworten, sie repariert keine Lücke im PHP-Interpreter. Warum Sie beides brauchen, beschreibt WAF oder Update: Warum Sie beides brauchen.
Welche Engine zu Ihrem Webserver passt
Das Regelwerk braucht eine Engine, die es ausführt. Laut CRS-Dokumentation gibt es drei kompatible Optionen:
| Engine | Webserver | Einordnung laut CRS-Projekt |
|---|---|---|
| ModSecurity v2 | Apache (Modul) | Referenzimplementierung, empfohlen für Apache |
| ModSecurity v3 (libModSecurity) | vor allem Nginx über Connector | nur der Nginx-Connector ist wirklich produktiv nutzbar; besteht 2 bis 4 Prozent der CRS-Tests nicht |
| Coraza | Go-basierte Proxys und Integrationen | besteht die CRS-v4-Testsuite vollständig |
Zum Hintergrund: ModSecurity wurde lange von Trustwave entwickelt. Trustwave kündigte 2021 an, die Entwicklung 2024 zu beenden. Am 25. Januar 2024 ging das Projekt an die OWASP Foundation über. Für Neuinstallationen prüfen Sie, welche Version Ihre Distribution ausliefert und wie aktuell sie ist.
So arbeitet das Core Rule Set
Das CRS blockiert in der Standardeinstellung nicht bei der ersten verdächtigen Auffälligkeit. Es arbeitet mit Anomalie-Punkten: Jede ausgelöste Regel addiert Punkte nach ihrem Schweregrad, und erst wenn die Summe eine Schwelle überschreitet, wird die Anfrage abgewiesen.
- Schweregrade: kritisch 5 Punkte, Fehler 4, Warnung 3, Hinweis 2.
- Schwelle für Anfragen:
tx.inbound_anomaly_score_threshold, Standard 5. - Schwelle für Antworten:
tx.outbound_anomaly_score_threshold, Standard 4. - Paranoia-Level 1 bis 4 in der
crs-setup.conf: Level 1 ist die Grundsicherung für jeden Server im Internet, Level 2 passt laut Projekt zu Anwendungen mit echten Nutzerdaten wie Onlineshops, Level 3 und 4 bringen deutlich mehr Fehlalarme.
Ein höheres Paranoia-Level erkennt mehr, erzeugt aber auch mehr Fehlalarme. Für die meisten Unternehmenswebsites ist Level 1 der Start, Level 2 ein späteres Ziel.
ModSecurity mit OWASP CRS einführen, ohne die Website lahmzulegen
Das CRS-Projekt empfiehlt für neue Installationen, den Blockiermodus von Anfang an einzuschalten, aber mit sehr hohen Schwellen, bis zu 10000, und diese dann schrittweise zu senken. So sammeln Sie Erfahrungen mit echten Zugriffen, ohne Nutzer auszusperren. Die Schwellen setzen Sie in der crs-setup.conf:
# crs-setup.conf: Startphase mit sehr hohen Schwellen
SecAction \
"id:900110,\
phase:1,\
pass,\
t:none,\
nolog,\
setvar:tx.inbound_anomaly_score_threshold=10000,\
setvar:tx.outbound_anomaly_score_threshold=10000"
Die Einbindung unter Apache folgt der Reihenfolge, die die CRS-Dokumentation für Plugins vorgibt. Pfade weichen je Distribution ab:
<IfModule security2_module>
SecRuleEngine On
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/plugins/*-config.conf
Include /etc/modsecurity/crs/plugins/*-before.conf
Include /etc/modsecurity/crs/rules/*.conf
Include /etc/modsecurity/crs/plugins/*-after.conf
</IfModule>
Danach werten Sie das Audit-Log aus, das in SecAuditLog festgelegt ist. Wie Sie Protokolle systematisch durchsuchen, beschreibt Webserver-Logs nach einem Angriff auswerten. Senken Sie die Schwellen in Stufen, etwa über mehrere Wochen, bis Sie beim Standardwert ankommen.
Fehlalarme gezielt behandeln
Fehlalarme sind normal, besonders in CMS-Backends mit Editoren, die HTML speichern. Die schlechteste Reaktion ist, die WAF abzuschalten. Besser sind zwei Werkzeuge.
Erstens Plugins: Das CRS-Projekt pflegt Plugins mit Ausnahmeregeln für verbreitete Anwendungen, etwa für WordPress. Sie werden in den Plugin-Ordner kopiert und über die oben gezeigten Include-Zeilen geladen. Die offizielle Liste führt das Projekt in seinem Plugin-Verzeichnis.
Zweitens eigene, eng gefasste Ausnahmen. Statt eine Regel überall abzuschalten, nehmen Sie sie nur für den Pfad heraus, an dem sie stört:
# Eigene Ausnahme, VOR den CRS-Regeln laden (z. B. in einer *-before.conf)
SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \
"id:1000010,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=941100"
Die Regel-ID entnehmen Sie dem Audit-Log des Fehlalarms. Dokumentieren Sie jede Ausnahme mit Grund und Datum, damit sie später überprüft werden kann.
Testen Sie nach jeder Änderung an Schwellen oder Ausnahmen die kritischen Wege Ihrer Anwendung: Anmeldung, Bestellung, Zahlung, Kontaktformular und Redaktion. Eine WAF, die Bestellungen blockiert, wird schnell wieder abgeschaltet.
Für Apache-Server lohnt es, die WAF zusammen mit der übrigen Konfiguration anzugehen; die Grundlagen stehen unter Apache für PHP sicher konfigurieren. Wie Cloudflare-Regeln im Vergleich einzuordnen sind, zeigt Cloudflare-Schutzregeln gegen PHP2Shell. Die Übergangsmaßnahmen auf dem Server selbst stehen unter Sofortmaßnahmen, wenn Sie noch nicht patchen können.
Fazit: Eine WAF braucht Pflege
ModSecurity mit dem OWASP Core Rule Set gibt Ihnen eine leistungsfähige Web Application Firewall ohne Lizenzkosten und ohne Abhängigkeit von einem externen Dienst. Der Preis ist Arbeit: die Engine passend zum Webserver wählen, mit hohen Schwellen beginnen, Fehlalarme auswerten, Ausnahmen pflegen und die Regeln aktuell halten.
Wer diesen Aufwand nicht leisten kann, fährt mit einer gut konfigurierten Cloud-WAF oft besser. Wer ihn leistet, erhält eine Schicht, die viele Standardangriffe abfängt und in den Audit-Logs wertvolle Hinweise liefert. In keinem Fall ersetzt sie das Update: Gegen PHP2Shell schützen nur PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder ein bestätigter Backport, gefolgt vom Neustart aller PHP-Prozesse.
Wie hilft PHP SOS konkret?
- Engine wählen: Wir prüfen Webserver, Distribution und vorhandene Pakete und empfehlen die passende Kombination.
- Einführen: Wir installieren CRS mit hohen Startschwellen, binden passende Plugins ein und richten die Protokollierung ein.
- Abstimmen: Über mehrere Wochen werten wir Fehlalarme aus, legen gezielte Ausnahmen an und senken die Schwellen.
- Einordnen: Im Rahmen von WAF und virtuelles Patching verbinden wir die WAF mit Übergangsmaßnahmen und dem Weg zum regulären Patch.
Häufige Fragen
Schützt das OWASP CRS vor PHP2Shell?
Davon sollten Sie nicht ausgehen. Das Core Rule Set erkennt allgemeine Angriffsmuster und ist nicht auf eine bestimmte Lücke zugeschnitten. Cloudflare weist zudem darauf hin, dass Regeln anhand der Anfragedaten allein bei PHP2Shell nicht genügen. Das PHP-Update bleibt Pflicht.
Welche Engine soll ich für Nginx nehmen?
Laut CRS-Projekt ist bei ModSecurity v3 nur der Nginx-Connector wirklich produktiv nutzbar, und v3 besteht einen kleinen Teil der CRS-Tests nicht. Alternativ gibt es Coraza, das nach Angaben des Projekts die CRS-v4-Testsuite vollständig besteht. Für Apache empfiehlt das Projekt ModSecurity v2.
Ist ModSecurity noch gepflegt?
Laut CRS-Dokumentation hatte Trustwave angekündigt, die Entwicklung 2024 zu beenden. Am 25. Januar 2024 wurde das Projekt an die OWASP Foundation übergeben und wird seitdem dort weitergeführt.
Wie verhindere ich, dass die WAF meinen Shop lahmlegt?
Starten Sie mit sehr hohen Anomalie-Schwellen, wie es das CRS-Projekt empfiehlt, und senken Sie sie schrittweise. Werten Sie dabei die Protokolle aus und legen Sie gezielte Ausnahmen für Ihre Anwendung an, statt Regeln pauschal abzuschalten.