Brug ModSecurity og OWASP Core Rule Set

Kort sagt: ModSecurity er en web application firewall, der kører i webserveren; OWASP Core Rule Set (CRS) leverer hertil frit tilgængelige regler mod udbredte angrebstyper. Til Apache anbefaler CRS-projektet ModSecurity v2, til Nginx kommer v3-connectoren eller Coraza i betragtning. Start i blokeringstilstand med meget høje anomaligrænser, sænk dem trinvis, og behandl falske alarmer med målrettede undtagelser. En PHP-opdatering erstatter det ikke.

En egen WAF som ekstra lag

Siden PHP2Shell spørger mange virksomheder, om de har brug for en web application firewall. Den, der leverer sine websites via Cloudflare, har ifølge Cloudflare siden den 21. oktober 2026 automatisk beskyttelsesregler aktive. Den, der ikke gør det, eller som ikke vil lede datatrafikken gennem en tredjepart, kan drive en WAF direkte på sin egen server.

Den mest kendte kombination hertil er ModSecurity med OWASP Core Rule Set. Begge dele er open source og gratis. CRS er en samling af generelle genkendelsesregler, f.eks. mod SQL-injection, cross-site scripting eller indsmugling af filer. Projektet beskriver selv sit mål som generel angrebsgenkendelse med så få falske alarmer som muligt, som én byggesten blandt flere.

Dermed er også grænsen nævnt. En WAF kontrollerer forespørgsler og svar, den reparerer ingen sårbarhed i PHP-fortolkeren. Hvorfor I har brug for begge dele, beskriver WAF eller opdatering: Hvorfor I har brug for begge dele.

Hvilken engine der passer til jeres webserver

Regelsættet har brug for en engine, der udfører det. Ifølge CRS-dokumentationen findes der tre kompatible muligheder:

Til baggrund: ModSecurity blev længe udviklet af Trustwave. Trustwave varslede i 2021 at afslutte udviklingen i 2024. Den 25. januar 2024 gik projektet over til OWASP Foundation. Til nyinstallationer kontrollerer I, hvilken version jeres distribution leverer, og hvor aktuel den er.

Sådan arbejder Core Rule Set

CRS blokerer i standardindstillingen ikke ved den første mistænkelige påfaldenhed. Det arbejder med anomalipoint: Hver udløst regel lægger point til efter sin alvorsgrad, og først når summen overskrider en grænse, afvises forespørgslen.

1. Alvorsgrader: kritisk 5 point, fejl 4, advarsel 3, henvisning 2.
2. Grænse for forespørgsler: tx.inbound_anomaly_score_threshold, standard 5.
3. Grænse for svar: tx.outbound_anomaly_score_threshold, standard 4.
4. Paranoia-niveau 1 til 4 i crs-setup.conf: Niveau 1 er grundsikringen for hver server på internettet, niveau 2 passer ifølge projektet til applikationer med ægte brugerdata som onlineshops, niveau 3 og 4 giver tydeligt flere falske alarmer.

Et højere paranoia-niveau genkender mere, men giver også flere falske alarmer. For de fleste virksomhedswebsites er niveau 1 starten, niveau 2 et senere mål.

Indfør ModSecurity med OWASP CRS uden at lamme websitet

CRS-projektet anbefaler ved nyinstallationer at slå blokeringstilstanden til fra begyndelsen, men med meget høje grænser, op til 10000, og derefter sænke dem trinvis. Så høster I erfaringer med ægte adgange uden at lukke brugere ude. Grænserne sætter I i crs-setup.conf:

# crs-setup.conf: startfase med meget høje grænser
SecAction \
    "id:900110,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    setvar:tx.inbound_anomaly_score_threshold=10000,\
    setvar:tx.outbound_anomaly_score_threshold=10000"

Indbindingen under Apache følger den rækkefølge, som CRS-dokumentationen foreskriver for plugins. Stier afviger fra distribution til distribution:

<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>

Derefter analyserer I audit-logget, som er fastlagt i SecAuditLog. Hvordan I gennemsøger protokoller systematisk, beskriver Analysér webserverlogs efter et angreb. Sænk grænserne i trin, f.eks. over flere uger, til I ender ved standardværdien.

Håndtér falske alarmer målrettet

Falske alarmer er normale, især i CMS-backends med editorer, der gemmer HTML. Den dårligste reaktion er at slå WAF'en fra. Bedre er to værktøjer.

For det første plugins: CRS-projektet vedligeholder plugins med undtagelsesregler for udbredte applikationer, f.eks. til WordPress. De kopieres ind i plugin-mappen og indlæses via de ovenfor viste Include-linjer. Den officielle liste fører projektet i sit plugin-katalog.

For det andet egne, snævert afgrænsede undtagelser. I stedet for at slå en regel fra overalt tager I den kun ud for den sti, hvor den generer:

# Egen undtagelse, indlæs FØR CRS-reglerne (f.eks. i en *-before.conf)
SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \
    "id:1000010,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleRemoveById=941100"

Regel-id'et finder I i audit-logget for den falske alarm. Dokumentér hver undtagelse med årsag og dato, så den senere kan gennemgås.

For Apache-servere er det umagen værd at gribe WAF'en an sammen med den øvrige konfiguration; grundlaget står under Konfigurér Apache sikkert til PHP. Hvordan Cloudflare-regler indordnes i sammenligning, viser Cloudflare-beskyttelsesregler mod PHP2Shell. Overgangsforanstaltningerne på selve serveren står under Akutforanstaltninger, hvis I endnu ikke kan patche.

Konklusion: En WAF kræver pleje

ModSecurity med OWASP Core Rule Set giver jer en effektiv web application firewall uden licensomkostninger og uden afhængighed af en ekstern tjeneste. Prisen er arbejde: at vælge engine passende til webserveren, begynde med høje grænser, analysere falske alarmer, vedligeholde undtagelser og holde reglerne aktuelle.

Den, der ikke kan yde denne indsats, kører ofte bedre med en velkonfigureret cloud-WAF. Den, der yder den, får et lag, der opfanger mange standardangreb og leverer værdifulde fingerpeg i audit-logs. Under ingen omstændigheder erstatter den opdateringen: Mod PHP2Shell beskytter kun PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 eller en bekræftet backport, efterfulgt af genstart af alle PHP-processer.

Hvordan hjælper PHP SOS konkret?

• Vælg engine: Vi kontrollerer webserver, distribution og eksisterende pakker og anbefaler den passende kombination.
• Indfør: Vi installerer CRS med høje startgrænser, indbinder passende plugins og opsætter protokolleringen.
• Afstem: Over flere uger analyserer vi falske alarmer, opretter målrettede undtagelser og sænker grænserne.
• Indordn: Inden for rammerne af WAF og virtuel patching forbinder vi WAF'en med overgangsforanstaltninger og vejen til den ordinære patch.

Ofte stillede spørgsmål

Kilder

• OWASP CRS: Dokumentation
• OWASP Top 10
• Cloudflare-blog
• php.net: Sikkerhedsmeddelelser