Na kratko: ModSecurity je požarni zid spletnih aplikacij, ki teče v spletnem strežniku; OWASP Core Rule Set (CRS) zanj prinaša prosto dostopna pravila proti razširjenim vrstam napadov. Za Apache projekt CRS priporoča ModSecurity v2, za Nginx pridejo v poštev konektor v3 ali Coraza. Začnite v načinu blokiranja z zelo visokimi pragovi anomalij, jih postopoma znižujte in lažne alarme obravnavajte s ciljnimi izjemami. Posodobitve PHP to ne nadomešča.
Lasten WAF kot dodatna plast
Od PHP2Shell se številna podjetja sprašujejo, ali potrebujejo požarni zid spletnih aplikacij. Kdor svoje spletne strani dostavlja prek Cloudflare, ima po navedbah Cloudflare od 21. oktobra 2026 samodejno aktivna zaščitna pravila. Kdor tega ne počne ali prometa ne želi usmerjati prek tretjega, lahko WAF upravlja neposredno na lastnem strežniku.
Najbolj znana kombinacija za to je ModSecurity z OWASP Core Rule Set. Oboje je odprtokodno in brezplačno. CRS je zbirka splošnih pravil za zaznavanje, na primer proti vbrizgavanju SQL, cross-site scriptingu ali vnašanju datotek. Projekt svoj cilj sam opisuje kot splošno zaznavanje napadov z čim manj lažnimi alarmi, kot en gradnik med več.
S tem je poimenovana tudi meja. WAF preverja zahteve in odgovore, ne popravlja ranljivosti v interpreterju PHP. Zakaj potrebujete oboje, opisuje WAF ali posodobitev: zakaj potrebujete oboje.
Kateri pogon ustreza vašemu spletnemu strežniku
Pravila potrebujejo pogon, ki jih izvaja. Po dokumentaciji CRS obstajajo tri združljive možnosti:
| Pogon | Spletni strežnik | Umestitev po projektu CRS |
|---|---|---|
| ModSecurity v2 | Apache (modul) | referenčna izvedba, priporočena za Apache |
| ModSecurity v3 (libModSecurity) | predvsem Nginx prek konektorja | resnično produktivno uporaben je samo konektor za Nginx; ne opravi 2 do 4 odstotkov testov CRS |
| Coraza | proxyji in integracije na osnovi Go | v celoti opravi testni nabor CRS v4 |
Za ozadje: ModSecurity je dolgo razvijal Trustwave. Trustwave je leta 2021 napovedal konec razvoja leta 2024. 25. januarja 2024 je projekt prešel na fundacijo OWASP. Pri novih namestitvah preverite, katero različico vaša distribucija dostavlja in kako aktualna je.
Kako deluje Core Rule Set
CRS v privzeti nastavitvi ne blokira ob prvi sumljivi nepravilnosti. Deluje s točkami anomalij: vsako sproženo pravilo prišteje točke glede na resnost, zahteva pa se zavrne šele, ko vsota preseže prag.
- Stopnje resnosti: kritična 5 točk, napaka 4, opozorilo 3, namig 2.
- Prag za zahteve:
tx.inbound_anomaly_score_threshold, privzeto 5. - Prag za odgovore:
tx.outbound_anomaly_score_threshold, privzeto 4. - Raven paranoje od 1 do 4 v
crs-setup.conf: raven 1 je osnovna zaščita za vsak strežnik v internetu, raven 2 po projektu ustreza aplikacijam z resničnimi podatki uporabnikov, kot so spletne trgovine, ravni 3 in 4 prinesejo bistveno več lažnih alarmov.
Višja raven paranoje prepozna več, a ustvari tudi več lažnih alarmov. Za večino podjetniških spletnih strani je začetek raven 1, raven 2 pa poznejši cilj.
Uvedba ModSecurity z OWASP CRS, ne da bi ohromili spletno stran
Projekt CRS za nove namestitve priporoča, da se način blokiranja vklopi od začetka, vendar z zelo visokimi pragovi, do 10000, ki se nato postopoma znižujejo. Tako zbirate izkušnje s pravimi dostopi, ne da bi uporabnike izključili. Pragove nastavite v crs-setup.conf:
# crs-setup.conf: začetna faza z zelo visokimi pragovi
SecAction \
"id:900110,\
phase:1,\
pass,\
t:none,\
nolog,\
setvar:tx.inbound_anomaly_score_threshold=10000,\
setvar:tx.outbound_anomaly_score_threshold=10000"
Vključitev pod Apache sledi vrstnemu redu, ki ga dokumentacija CRS predpisuje za vtičnike. Poti se po distribuciji razlikujejo:
<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>
Nato ovrednotite revizijski dnevnik, določen v SecAuditLog. Kako sistematično preiskujete dnevnike, opisuje Ovrednotenje dnevnikov spletnega strežnika po napadu. Pragove znižujte po stopnjah, na primer v več tednih, dokler ne pridete do privzete vrednosti.
Ciljna obravnava lažnih alarmov
Lažni alarmi so običajni, zlasti v zaledjih CMS z urejevalniki, ki shranjujejo HTML. Najslabši odziv je izklop WAF. Boljši sta dve orodji.
Prvič, vtičniki: projekt CRS vzdržuje vtičnike z izjemnimi pravili za razširjene aplikacije, na primer za WordPress. Skopirajo se v mapo vtičnikov in naložijo prek zgoraj prikazanih vrstic Include. Uradni seznam projekt vodi v svojem imeniku vtičnikov.
Drugič, lastne, ozko zastavljene izjeme. Namesto da pravilo izklopite povsod, ga izvzamete samo za pot, na kateri moti:
# Lastna izjema, naloži PRED pravili CRS (npr. v datoteki *-before.conf)
SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \
"id:1000010,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=941100"
ID pravila vzamete iz revizijskega dnevnika lažnega alarma. Vsako izjemo dokumentirajte z razlogom in datumom, da jo je mogoče pozneje preveriti.
Po vsaki spremembi pragov ali izjem preizkusite kritične poti svoje aplikacije: prijavo, naročilo, plačilo, kontaktni obrazec in uredništvo. WAF, ki blokira naročila, se hitro znova izklopi.
Pri strežnikih Apache se splača WAF lotiti skupaj s preostalo konfiguracijo; osnove so pod Varna konfiguracija Apache za PHP. Kako umestiti pravila Cloudflare v primerjavi, kaže Zaščitna pravila Cloudflare proti PHP2Shell. Prehodni ukrepi na samem strežniku so pod Takojšnji ukrepi, če popravka še ne morete namestiti.
Sklep: WAF potrebuje vzdrževanje
ModSecurity z OWASP Core Rule Set vam daje zmogljiv požarni zid spletnih aplikacij brez stroškov licence in brez odvisnosti od zunanje storitve. Cena je delo: pogon izbrati glede na spletni strežnik, začeti z visokimi pragovi, ovrednotiti lažne alarme, vzdrževati izjeme in pravila ohranjati aktualna.
Kdor tega napora ne zmore, je z dobro konfiguriranim oblačnim WAF pogosto na boljšem. Kdor ga zmore, dobi plast, ki ujame številne standardne napade in v revizijskih dnevnikih daje dragocene namige. V nobenem primeru ne nadomešča posodobitve: proti PHP2Shell varujejo samo PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 ali potrjen backport, ki mu sledi ponovni zagon vseh procesov PHP.
Kako PHP SOS pomaga konkretno?
- Izbira pogona: preverimo spletni strežnik, distribucijo in obstoječe pakete ter priporočimo ustrezno kombinacijo.
- Uvedba: namestimo CRS z visokimi začetnimi pragovi, vključimo ustrezne vtičnike in vzpostavimo beleženje.
- Uskladitev: več tednov ovrednotimo lažne alarme, ustvarimo ciljne izjeme in znižujemo pragove.
- Umestitev: v okviru WAF in virtualnega popravljanja WAF povežemo s prehodnimi ukrepi in potjo do rednega popravka.
Pogosta vprašanja
Ali OWASP CRS ščiti pred PHP2Shell?
Od tega ne bi smeli izhajati. Core Rule Set prepoznava splošne vzorce napadov in ni prirezan na določeno ranljivost. Cloudflare poleg tega opozarja, da pravila samo na podlagi podatkov zahteve pri PHP2Shell ne zadoščajo. Posodobitev PHP ostaja obvezna.
Kateri pogon naj vzamem za Nginx?
Po projektu CRS je pri ModSecurity v3 resnično produktivno uporaben samo konektor za Nginx, v3 pa ne opravi majhnega dela testov CRS. Alternativa je Coraza, ki po navedbah projekta v celoti opravi testni nabor CRS v4. Za Apache projekt priporoča ModSecurity v2.
Ali se ModSecurity še vzdržuje?
Po dokumentaciji CRS je Trustwave napovedal konec razvoja leta 2024. 25. januarja 2024 je bil projekt predan fundaciji OWASP in se od takrat tam nadaljuje.
Kako preprečim, da WAF ohromi mojo trgovino?
Začnite z zelo visokimi pragovi anomalij, kot priporoča projekt CRS, in jih postopoma znižujte. Pri tem ovrednotite dnevnike in ustvarite ciljne izjeme za svojo aplikacijo, namesto da pravila splošno izklopite.