Kort gezegd: ModSecurity is een Web Application Firewall die in de webserver draait; het OWASP Core Rule Set (CRS) levert daarbij vrij beschikbare regels tegen verbreide aanvalstypen. Voor Apache adviseert het CRS-project ModSecurity v2, voor Nginx komen de v3-connector of Coraza in aanmerking. Start in blokkeermodus met zeer hoge anomaliedrempels, verlaag die stapsgewijs en behandel valse alarmen met gerichte uitzonderingen. Een PHP-update vervangt dat niet.
Een eigen WAF als extra laag
Sinds PHP2Shell vragen veel bedrijven zich af of ze een Web Application Firewall nodig hebben. Wie zijn websites via Cloudflare uitlevert, heeft volgens Cloudflare sinds 21 oktober 2026 automatisch beschermingsregels actief. Wie dat niet doet of het dataverkeer niet via een derde wil laten lopen, kan een WAF rechtstreeks op de eigen server draaien.
De bekendste combinatie daarvoor is ModSecurity met het OWASP Core Rule Set. Beide zijn open source en gratis. Het CRS is een verzameling algemene detectieregels, bijvoorbeeld tegen SQL-injectie, cross-site scripting of het inbrengen van bestanden. Het project beschrijft zijn doel zelf als algemene aanvalsdetectie met zo min mogelijk valse alarmen, als één bouwsteen onder meerdere.
Daarmee is ook de grens benoemd. Een WAF controleert verzoeken en antwoorden, ze herstelt geen kwetsbaarheid in de PHP-interpreter. Waarom u beide nodig hebt, beschrijft WAF of update: waarom u beide nodig hebt.
Welke engine bij uw webserver past
Het regelwerk heeft een engine nodig die het uitvoert. Volgens de CRS-documentatie zijn er drie compatibele opties:
| Engine | Webserver | Duiding volgens het CRS-project |
|---|---|---|
| ModSecurity v2 | Apache (module) | Referentie-implementatie, aanbevolen voor Apache |
| ModSecurity v3 (libModSecurity) | vooral Nginx via connector | alleen de Nginx-connector is werkelijk productief bruikbaar; haalt 2 tot 4 procent van de CRS-tests niet |
| Coraza | Go-gebaseerde proxy's en integraties | haalt de CRS-v4-testsuite volledig |
Ter achtergrond: ModSecurity werd lang door Trustwave ontwikkeld. Trustwave kondigde in 2021 aan de ontwikkeling in 2024 te beëindigen. Op 25 januari 2024 ging het project over naar de OWASP Foundation. Bij nieuwe installaties controleert u welke versie uw distributie levert en hoe actueel die is.
Zo werkt het Core Rule Set
Het CRS blokkeert in de standaardinstelling niet bij de eerste verdachte afwijking. Het werkt met anomaliepunten: elke geactiveerde regel telt punten op naar ernst en pas als de som een drempel overschrijdt, wordt het verzoek geweigerd.
- Ernstniveaus: kritiek 5 punten, fout 4, waarschuwing 3, opmerking 2.
- Drempel voor verzoeken:
tx.inbound_anomaly_score_threshold, standaard 5. - Drempel voor antwoorden:
tx.outbound_anomaly_score_threshold, standaard 4. - Paranoia-niveau 1 tot 4 in de
crs-setup.conf: niveau 1 is de basisbeveiliging voor elke server op internet, niveau 2 past volgens het project bij applicaties met echte gebruikersgegevens zoals webwinkels, niveau 3 en 4 brengen aanzienlijk meer valse alarmen.
Een hoger paranoia-niveau herkent meer, maar veroorzaakt ook meer valse alarmen. Voor de meeste bedrijfswebsites is niveau 1 de start, niveau 2 een later doel.
ModSecurity met OWASP CRS invoeren zonder de website lam te leggen
Het CRS-project adviseert voor nieuwe installaties de blokkeermodus meteen in te schakelen, maar met zeer hoge drempels, tot 10000, en die daarna stapsgewijs te verlagen. Zo doet u ervaring op met echte toegangen zonder gebruikers buiten te sluiten. De drempels stelt u in de crs-setup.conf in:
# crs-setup.conf: startfase met zeer hoge drempels
SecAction \
"id:900110,\
phase:1,\
pass,\
t:none,\
nolog,\
setvar:tx.inbound_anomaly_score_threshold=10000,\
setvar:tx.outbound_anomaly_score_threshold=10000"
De inbedding onder Apache volgt de volgorde die de CRS-documentatie voor plug-ins voorschrijft. Paden verschillen per distributie:
<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>
Analyseer daarna het auditlog dat in SecAuditLog is vastgelegd. Hoe u logboeken systematisch doorzoekt, beschrijft Webserverlogs na een aanval analyseren. Verlaag de drempels in stappen, bijvoorbeeld over meerdere weken, tot u bij de standaardwaarde uitkomt.
Valse alarmen gericht behandelen
Valse alarmen zijn normaal, vooral in CMS-backends met editors die HTML opslaan. De slechtste reactie is de WAF uit te schakelen. Beter zijn twee hulpmiddelen.
Ten eerste plug-ins: het CRS-project onderhoudt plug-ins met uitzonderingsregels voor verbreide applicaties, bijvoorbeeld voor WordPress. Ze worden naar de pluginmap gekopieerd en geladen via de hierboven getoonde Include-regels. De officiële lijst beheert het project in zijn pluginoverzicht.
Ten tweede eigen, nauw gedefinieerde uitzonderingen. In plaats van een regel overal uit te schakelen, haalt u haar alleen weg voor het pad waar ze hindert:
# Eigen uitzondering, VÓÓR de CRS-regels laden (bijv. in een *-before.conf)
SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \
"id:1000010,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=941100"
De regel-ID haalt u uit het auditlog van het valse alarm. Documenteer elke uitzondering met reden en datum, zodat ze later kan worden beoordeeld.
Test na elke wijziging van drempels of uitzonderingen de kritieke routes van uw applicatie: aanmelding, bestelling, betaling, contactformulier en redactie. Een WAF die bestellingen blokkeert, wordt snel weer uitgeschakeld.
Voor Apache-servers loont het om de WAF samen met de overige configuratie aan te pakken; de basis staat onder Apache veilig configureren voor PHP. Hoe Cloudflare-regels in vergelijking zijn te plaatsen, toont Cloudflare-beschermingsregels tegen PHP2Shell. De overbruggingsmaatregelen op de server zelf staan onder Noodmaatregelen als u nog niet kunt patchen.
Conclusie: een WAF vraagt onderhoud
ModSecurity met het OWASP Core Rule Set geeft u een krachtige Web Application Firewall zonder licentiekosten en zonder afhankelijkheid van een externe dienst. De prijs is werk: de engine passend bij de webserver kiezen, met hoge drempels beginnen, valse alarmen analyseren, uitzonderingen onderhouden en de regels actueel houden.
Wie die inspanning niet kan leveren, vaart vaak beter met een goed geconfigureerde cloud-WAF. Wie haar wel levert, krijgt een laag die veel standaardaanvallen opvangt en in de auditlogs waardevolle aanwijzingen levert. In geen geval vervangt ze de update: tegen PHP2Shell beschermen alleen PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 of een bevestigde backport, gevolgd door de herstart van alle PHP-processen.
Hoe helpt PHP SOS concreet?
- Engine kiezen: wij controleren webserver, distributie en aanwezige pakketten en adviseren de passende combinatie.
- Invoeren: wij installeren het CRS met hoge startdrempels, voegen passende plug-ins toe en richten de logging in.
- Afstemmen: over meerdere weken analyseren wij valse alarmen, leggen gerichte uitzonderingen aan en verlagen de drempels.
- Plaatsen: in het kader van WAF en virtual patching verbinden wij de WAF met overbruggingsmaatregelen en de weg naar de reguliere patch.
Veelgestelde vragen
Beschermt het OWASP CRS tegen PHP2Shell?
Daar moet u niet van uitgaan. Het Core Rule Set herkent algemene aanvalspatronen en is niet op een bepaalde kwetsbaarheid toegesneden. Cloudflare wijst er bovendien op dat regels op basis van alleen de verzoekgegevens bij PHP2Shell niet volstaan. De PHP-update blijft verplicht.
Welke engine moet ik voor Nginx nemen?
Volgens het CRS-project is bij ModSecurity v3 alleen de Nginx-connector werkelijk productief bruikbaar en haalt v3 een klein deel van de CRS-tests niet. Alternatief is Coraza, dat volgens het project de CRS-v4-testsuite volledig haalt. Voor Apache adviseert het project ModSecurity v2.
Wordt ModSecurity nog onderhouden?
Volgens de CRS-documentatie had Trustwave aangekondigd de ontwikkeling in 2024 te beëindigen. Op 25 januari 2024 is het project overgedragen aan de OWASP Foundation en wordt het sindsdien daar voortgezet.
Hoe voorkom ik dat de WAF mijn webwinkel lamlegt?
Begin met zeer hoge anomaliedrempels, zoals het CRS-project adviseert, en verlaag ze stapsgewijs. Analyseer daarbij de logboeken en leg gerichte uitzonderingen voor uw applicatie aan in plaats van regels algemeen uit te schakelen.