Lühidalt: ModSecurity on veebiserveris töötav Web Application Firewall; OWASP Core Rule Set (CRS) pakub selle jaoks vabalt kättesaadavaid reegleid levinud ründeliikide vastu. Apache'i jaoks soovitab CRS-projekt ModSecurity v2, Nginxi jaoks tulevad kõne alla v3 connector või Coraza. Alustage blokeerimisrežiimis väga kõrgete anomaaliakünnistega, langetage neid järk-järgult ja käsitlege valehäireid sihipäraste erandite abil. PHP uuendust see ei asenda.
Oma WAF täiendava kihina
Alates PHP2Shellist küsivad paljud ettevõtted, kas nad vajavad Web Application Firewalli. Kes väljastab oma veebisaite Cloudflare'i kaudu, sellel on Cloudflare'i andmetel alates 21. oktoobrist 2026 kaitsereeglid automaatselt aktiivsed. Kes seda ei tee või ei taha andmeliiklust kolmanda osapoole kaudu suunata, saab käitada WAF-i otse oma serveris.
Tuntuim kombinatsioon selleks on ModSecurity koos OWASP Core Rule Set'iga. Mõlemad on avatud lähtekoodiga ja tasuta. CRS on üldiste tuvastusreeglite kogum, näiteks SQL-injektsiooni, Cross-Site-Scriptingu või failide sissetoomise vastu. Projekt kirjeldab oma eesmärki ise kui üldist rünnete tuvastamist võimalikult väheste valehäiretega, ühe ehituskivina mitme seas.
Sellega on nimetatud ka piir. WAF kontrollib päringuid ja vastuseid, see ei paranda auku PHP interpretaatoris. Miks vajate mõlemat, kirjeldab WAF või uuendus: miks vajate mõlemat.
Milline mootor teie veebiserverile sobib
Reeglistik vajab mootorit, mis seda käivitab. CRS-i dokumentatsiooni järgi on kolm ühilduvat valikut:
| Mootor | Veebiserver | Hinnang CRS-projekti järgi |
|---|---|---|
| ModSecurity v2 | Apache (moodul) | etalonrealisatsioon, soovitatud Apache'i jaoks |
| ModSecurity v3 (libModSecurity) | peamiselt Nginx connectori kaudu | tõeliselt tootmises kasutatav on ainult Nginxi connector; ei läbi 2 kuni 4 protsenti CRS-i teste |
| Coraza | Go-põhised proxyd ja integratsioonid | läbib CRS v4 testikomplekti täielikult |
Taustaks: ModSecurity't arendas pikka aega Trustwave. Trustwave teatas 2021. aastal, et lõpetab arenduse 2024. aastal. 25. jaanuaril 2024 läks projekt üle OWASP Foundationile. Uute paigalduste puhul kontrollige, millise versiooni teie distributsioon tarnib ja kui ajakohane see on.
Kuidas Core Rule Set töötab
CRS ei blokeeri vaikesättega esimese kahtlase kõrvalekalde korral. See töötab anomaaliapunktidega: iga käivitunud reegel liidab punkte tõsiduse järgi ja alles kui summa ületab künnise, lükatakse päring tagasi.
- Tõsiduse tasemed: kriitiline 5 punkti, viga 4, hoiatus 3, märkus 2.
- Päringute künnis:
tx.inbound_anomaly_score_threshold, vaikimisi 5. - Vastuste künnis:
tx.outbound_anomaly_score_threshold, vaikimisi 4. - Paranoia-tasemed 1 kuni 4 failis
crs-setup.conf: tase 1 on põhikaitse igale internetiserverile, tase 2 sobib projekti järgi päris kasutajaandmetega rakendustele, nagu veebipoed, tasemed 3 ja 4 toovad märgatavalt rohkem valehäireid.
Kõrgem paranoia-tase tuvastab rohkem, kuid tekitab ka rohkem valehäireid. Enamiku ettevõtete veebisaitide jaoks on tase 1 algus, tase 2 hilisem eesmärk.
ModSecurity OWASP CRS-iga kasutusele võtta, veebisaiti halvamata
CRS-projekt soovitab uute paigalduste puhul lülitada blokeerimisrežiim sisse algusest peale, kuid väga kõrgete künnistega, kuni 10000, ja langetada neid seejärel järk-järgult. Nii kogute kogemusi päris pöördumistega, kasutajaid välja lukustamata. Künnised seate failis crs-setup.conf:
# crs-setup.conf: algusfaas väga kõrgete künnistega
SecAction \
"id:900110,\
phase:1,\
pass,\
t:none,\
nolog,\
setvar:tx.inbound_anomaly_score_threshold=10000,\
setvar:tx.outbound_anomaly_score_threshold=10000"
Ühendamine Apache'is järgib järjekorda, mille CRS-i dokumentatsioon pluginatele ette annab. Teed erinevad distributsiooniti:
<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>
Seejärel analüüsite auditilogi, mis on määratud sättes SecAuditLog. Kuidas protokolle süstemaatiliselt läbi otsida, kirjeldab Veebiserveri logide analüüs pärast rünnakut. Langetage künniseid etappide kaupa, näiteks mitme nädala jooksul, kuni jõuate vaikeväärtuseni.
Valehäirete sihipärane käsitlemine
Valehäired on normaalsed, eriti CMS-i tagaliidestes redaktoritega, mis salvestavad HTML-i. Halvim reaktsioon on WAF välja lülitada. Paremad on kaks tööriista.
Esiteks pluginad: CRS-projekt hooldab pluginaid erandireeglitega levinud rakenduste jaoks, näiteks WordPressi jaoks. Need kopeeritakse pluginate kausta ja laaditakse ülalnäidatud Include-ridade kaudu. Ametliku loendi pidab projekt oma pluginate kataloogis.
Teiseks oma, kitsalt piiritletud erandid. Selle asemel et reeglit kõikjal välja lülitada, võtate selle ära ainult tee jaoks, kus see segab:
# Oma erand, laadige ENNE CRS-reegleid (nt *-before.conf failis)
SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \
"id:1000010,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=941100"
Reegli ID võtate valehäire auditilogist. Dokumenteerige iga erand põhjuse ja kuupäevaga, et seda saaks hiljem üle vaadata.
Testige pärast iga künniste või erandite muudatust oma rakenduse kriitilisi teid: sisselogimine, tellimus, makse, kontaktivorm ja toimetus. WAF, mis blokeerib tellimusi, lülitatakse kiiresti taas välja.
Apache'i serverite puhul tasub WAF-iga tegeleda koos ülejäänud konfiguratsiooniga; alused on artiklis Apache PHP jaoks turvaliselt seadistamine. Kuidas Cloudflare'i reegleid võrdluses paigutada, näitab Cloudflare'i kaitsereeglid PHP2Shelli vastu. Üleminekumeetmed serveris endas on lehel Kiirmeetmed, kui te ei saa veel paikama hakata.
Kokkuvõte: WAF vajab hooldust
ModSecurity OWASP Core Rule Set'iga annab teile võimsa Web Application Firewalli ilma litsentsitasuta ja sõltuvuseta välisest teenusest. Hind on töö: valida veebiserverile sobiv mootor, alustada kõrgete künnistega, analüüsida valehäireid, hooldada erandeid ja hoida reeglid ajakohased.
Kes seda vaeva ei suuda teha, sõidab sageli paremini hästi seadistatud pilve-WAF-iga. Kes suudab, saab kihi, mis püüab kinni palju standardrünnakuid ja annab auditilogides väärtuslikke vihjeid. Ühelgi juhul ei asenda see uuendust: PHP2Shelli vastu kaitsevad ainult PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 või kinnitatud tagasiportimine, millele järgneb kõigi PHP protsesside taaskäivitamine.
Kuidas PHP SOS konkreetselt aitab?
- Mootor valida: kontrollime veebiserverit, distributsiooni ja olemasolevaid pakette ning soovitame sobiva kombinatsiooni.
- Kasutusele võtta: paigaldame CRS-i kõrgete algkünnistega, ühendame sobivad pluginad ja seadistame protokollimise.
- Häälestada: mitme nädala jooksul analüüsime valehäireid, loome sihipärased erandid ja langetame künniseid.
- Paigutada: WAF-i ja virtuaalse paikamise raames seome WAF-i üleminekumeetmete ja teega tavapärase paigani.
Korduma kippuvad küsimused
Kas OWASP CRS kaitseb PHP2Shelli vastu?
Sellest ei tohiks lähtuda. Core Rule Set tuvastab üldisi ründemustreid ja ei ole kitsalt ühele august tehtud. Cloudflare juhib lisaks tähelepanu, et reeglitest üksnes päringuandmete põhjal PHP2Shelli puhul ei piisa. PHP uuendus jääb kohustuslikuks.
Millist mootorit peaksin Nginxi jaoks võtma?
CRS-projekti järgi on ModSecurity v3 puhul tõeliselt tootmises kasutatav ainult Nginxi connector ja v3 ei läbi väikest osa CRS-i teste. Alternatiivina on Coraza, mis projekti andmetel läbib CRS v4 testikomplekti täielikult. Apache'i jaoks soovitab projekt ModSecurity v2.
Kas ModSecurity't veel hooldatakse?
CRS-i dokumentatsiooni järgi oli Trustwave teatanud arenduse lõpetamisest 2024. aastal. 25. jaanuaril 2024 anti projekt üle OWASP Foundationile ja seda jätkatakse seal.
Kuidas takistan, et WAF mu poodi halvaks?
Alustage väga kõrgete anomaaliakünnistega, nagu CRS-projekt soovitab, ja langetage neid järk-järgult. Analüüsige seejuures protokolle ja looge oma rakenduse jaoks sihipärased erandid, selle asemel et reegleid üldiselt välja lülitada.