Kort sagt: ModSecurity är en Web Application Firewall som körs i webbservern; OWASP Core Rule Set (CRS) levererar fritt tillgängliga regler mot vanliga angreppstyper. För Apache rekommenderar CRS-projektet ModSecurity v2, för Nginx kommer v3-connectorn eller Coraza i fråga. Starta i blockeringsläge med mycket höga anomalitrösklar, sänk dem stegvis och hantera falsklarm med riktade undantag. En PHP-uppdatering ersätter det inte.
En egen WAF som extra lager
Sedan PHP2Shell frågar många företag om de behöver en Web Application Firewall. Den som levererar sina webbplatser via Cloudflare har enligt Cloudflare sedan den 21 oktober 2026 automatiskt skyddsregler aktiva. Den som inte gör det eller inte vill leda trafiken via en tredje part kan driva en WAF direkt på den egna servern.
Den mest kända kombinationen för det är ModSecurity med OWASP Core Rule Set. Båda är öppen källkod och gratis. CRS är en samling allmänna upptäcktsregler, till exempel mot SQL-injektion, cross-site scripting eller införande av filer. Projektet beskriver självt sitt mål som allmän angreppsupptäckt med så få falsklarm som möjligt, som en byggsten bland flera.
Därmed är också gränsen nämnd. En WAF kontrollerar förfrågningar och svar, den reparerar ingen sårbarhet i PHP-tolken. Varför ni behöver båda beskriver WAF eller uppdatering: varför ni behöver båda.
Vilken motor som passar er webbserver
Regelverket behöver en motor som kör det. Enligt CRS-dokumentationen finns tre kompatibla alternativ:
| Motor | Webbserver | Bedömning enligt CRS-projektet |
|---|---|---|
| ModSecurity v2 | Apache (modul) | Referensimplementation, rekommenderad för Apache |
| ModSecurity v3 (libModSecurity) | framför allt Nginx via connector | bara Nginx-connectorn är verkligen användbar i produktion; klarar inte 2 till 4 procent av CRS-testerna |
| Coraza | Go-baserade proxyer och integrationer | klarar CRS-v4-testsviten fullständigt |
Som bakgrund: ModSecurity utvecklades länge av Trustwave. Trustwave aviserade 2021 att avsluta utvecklingen 2024. Den 25 januari 2024 överfördes projektet till OWASP Foundation. För nya installationer kontrollerar ni vilken version er distribution levererar och hur aktuell den är.
Så fungerar Core Rule Set
CRS blockerar i standardinställningen inte vid den första misstänkta avvikelsen. Det arbetar med anomalipoäng: varje utlöst regel lägger till poäng efter sin allvarlighetsgrad, och först när summan överskrider en tröskel avvisas förfrågan.
- Allvarlighetsgrader: kritisk 5 poäng, fel 4, varning 3, notering 2.
- Tröskel för förfrågningar:
tx.inbound_anomaly_score_threshold, standard 5. - Tröskel för svar:
tx.outbound_anomaly_score_threshold, standard 4. - Paranoianivå 1 till 4 i
crs-setup.conf: nivå 1 är grundsäkringen för varje server på internet, nivå 2 passar enligt projektet applikationer med verkliga användardata som webbutiker, nivå 3 och 4 ger betydligt fler falsklarm.
En högre paranoianivå upptäcker mer men ger också fler falsklarm. För de flesta företagswebbplatser är nivå 1 starten, nivå 2 ett senare mål.
Införa ModSecurity med OWASP CRS utan att lamslå webbplatsen
CRS-projektet rekommenderar för nya installationer att slå på blockeringsläget från början men med mycket höga trösklar, upp till 10000, och sedan sänka dem stegvis. Så samlar ni erfarenhet från verkliga åtkomster utan att utestänga användare. Trösklarna sätter ni i crs-setup.conf:
# crs-setup.conf: startfas med mycket höga trösklar
SecAction \
"id:900110,\
phase:1,\
pass,\
t:none,\
nolog,\
setvar:tx.inbound_anomaly_score_threshold=10000,\
setvar:tx.outbound_anomaly_score_threshold=10000"
Inbindningen under Apache följer den ordning som CRS-dokumentationen föreskriver för plugins. Sökvägar skiljer sig mellan distributioner:
<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>
Därefter analyserar ni audit-loggen som anges i SecAuditLog. Hur ni systematiskt söker igenom loggar beskriver Analysera webbserverloggar efter ett angrepp. Sänk trösklarna i steg, till exempel över flera veckor, tills ni når standardvärdet.
Hantera falsklarm riktat
Falsklarm är normala, särskilt i CMS-backends med editorer som sparar HTML. Den sämsta reaktionen är att stänga av WAF. Bättre är två verktyg.
För det första plugins: CRS-projektet underhåller plugins med undantagsregler för vanliga applikationer, till exempel för WordPress. De kopieras till plugin-mappen och laddas via de Include-rader som visas ovan. Den officiella listan finns i projektets plugin-katalog.
För det andra egna, snävt avgränsade undantag. I stället för att stänga av en regel överallt tar ni bort den bara för den sökväg där den stör:
# Eget undantag, ladda FÖRE CRS-reglerna (t.ex. i en *-before.conf)
SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \
"id:1000010,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=941100"
Regel-ID:t hämtar ni ur falsklarmets audit-logg. Dokumentera varje undantag med skäl och datum, så att det kan granskas senare.
Testa efter varje ändring av trösklar eller undantag applikationens kritiska vägar: inloggning, beställning, betalning, kontaktformulär och redaktion. En WAF som blockerar beställningar stängs snabbt av igen.
För Apache-servrar lönar det sig att ta sig an WAF tillsammans med övrig konfiguration; grunderna står under Konfigurera Apache för PHP säkert. Hur Cloudflare-regler ska placeras i jämförelse visar Cloudflares skyddsregler mot PHP2Shell. Övergångsåtgärderna på själva servern står under Akuta åtgärder när ni ännu inte kan patcha.
Slutsats: en WAF behöver underhåll
ModSecurity med OWASP Core Rule Set ger er en kraftfull Web Application Firewall utan licenskostnader och utan beroende av en extern tjänst. Priset är arbete: välja motor som passar webbservern, börja med höga trösklar, analysera falsklarm, underhålla undantag och hålla reglerna aktuella.
Den som inte kan lägga ner den insatsen klarar sig ofta bättre med en välkonfigurerad moln-WAF. Den som gör det får ett lager som fångar många standardangrepp och ger värdefulla ledtrådar i audit-loggarna. I inget fall ersätter den uppdateringen: mot PHP2Shell skyddar bara PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 eller en bekräftad backport, följt av omstart av alla PHP-processer.
Hur hjälper PHP SOS konkret?
- Välja motor: Vi kontrollerar webbserver, distribution och befintliga paket och rekommenderar rätt kombination.
- Införa: Vi installerar CRS med höga starttrösklar, binder in lämpliga plugins och inrättar loggningen.
- Trimma: Över flera veckor analyserar vi falsklarm, lägger upp riktade undantag och sänker trösklarna.
- Placera rätt: Inom ramen för WAF och virtuell patchning kopplar vi ihop WAF med övergångsåtgärder och vägen till den ordinarie patchen.
Vanliga frågor
Skyddar OWASP CRS mot PHP2Shell?
Det bör ni inte utgå från. Core Rule Set upptäcker allmänna angreppsmönster och är inte skräddarsytt för en viss sårbarhet. Cloudflare påpekar dessutom att regler utifrån enbart förfrågningsdata inte räcker vid PHP2Shell. PHP-uppdateringen förblir obligatorisk.
Vilken motor ska jag ta för Nginx?
Enligt CRS-projektet är vid ModSecurity v3 bara Nginx-connectorn verkligen användbar i produktion, och v3 klarar inte en liten del av CRS-testerna. Alternativt finns Coraza, som enligt projektet klarar CRS-v4-testsviten fullständigt. För Apache rekommenderar projektet ModSecurity v2.
Underhålls ModSecurity fortfarande?
Enligt CRS-dokumentationen hade Trustwave aviserat att avsluta utvecklingen 2024. Den 25 januari 2024 överläts projektet till OWASP Foundation och drivs sedan dess vidare där.
Hur förhindrar jag att WAF lamslår min butik?
Börja med mycket höga anomalitrösklar, som CRS-projektet rekommenderar, och sänk dem stegvis. Analysera då loggarna och lägg upp riktade undantag för er applikation i stället för att stänga av regler generellt.