Īsi sakot: ModSecurity ir Web Application Firewall, kas darbojas tīmekļa serverī; OWASP Core Rule Set (CRS) tai piegādā brīvi pieejamus noteikumus pret izplatītiem uzbrukumu veidiem. Apache CRS projekts iesaka ModSecurity v2, Nginx apsverami v3 savienotājs vai Coraza. Sāciet bloķēšanas režīmā ar ļoti augstiem anomāliju sliekšņiem, pakāpeniski tos pazeminiet un kļūdainas trauksmes apstrādājiet ar mērķtiecīgiem izņēmumiem. PHP atjauninājumu tas neaizstāj.
Sava WAF kā papildu slānis
Kopš PHP2Shell daudzi uzņēmumi jautā, vai viņiem vajadzīga Web Application Firewall. Kas savas vietnes piegādā caur Cloudflare, tam saskaņā ar Cloudflare kopš 2026. gada 21. oktobra automātiski ir aktīvi aizsardzības noteikumi. Kas to nedara vai nevēlas datplūsmu vadīt caur trešo pusi, var darbināt WAF tieši savā serverī.
Pazīstamākā kombinācija tam ir ModSecurity ar OWASP Core Rule Set. Abi ir ar atvērtu pirmkodu un bezmaksas. CRS ir vispārīgu atpazīšanas noteikumu krājums, piemēram, pret SQL injekcijām, Cross-Site Scripting vai failu ielikšanu. Projekts savu mērķi pats apraksta kā vispārīgu uzbrukumu atpazīšanu ar pēc iespējas mazāk kļūdainu trauksmju, kā vienu elementu starp vairākiem.
Ar to nosaukta arī robeža. WAF pārbauda pieprasījumus un atbildes, tā neizlabo ievainojamību PHP interpretatorā. Kāpēc vajag abus, apraksta WAF vai atjauninājums: kāpēc vajag abus.
Kurš dzinējs der jūsu tīmekļa serverim
Noteikumu kopai vajadzīgs dzinējs, kas tos izpilda. Saskaņā ar CRS dokumentāciju ir trīs saderīgas iespējas:
| Dzinējs | Tīmekļa serveris | Ierindojums saskaņā ar CRS projektu |
|---|---|---|
| ModSecurity v2 | Apache (modulis) | references implementācija, ieteicama Apache |
| ModSecurity v3 (libModSecurity) | galvenokārt Nginx caur savienotāju | tikai Nginx savienotājs ir patiešām izmantojams produkcijā; neiztur 2 līdz 4 procentus CRS testu |
| Coraza | uz Go balstīti starpniekserveri un integrācijas | pilnībā iztur CRS v4 testu komplektu |
Par fonu: ModSecurity ilgi izstrādāja Trustwave. Trustwave 2021. gadā paziņoja par izstrādes beigšanu 2024. gadā. 2024. gada 25. janvārī projekts pārgāja OWASP Foundation. Jaunām instalācijām pārbaudiet, kuru versiju jūsu distributīvs piegādā un cik tā ir aktuāla.
Kā darbojas Core Rule Set
CRS pēc noklusējuma nebloķē pie pirmās aizdomīgās pazīmes. Tas darbojas ar anomāliju punktiem: katrs iedarbinātais noteikums pievieno punktus pēc savas smaguma pakāpes, un tikai tad, kad summa pārsniedz slieksni, pieprasījums tiek noraidīts.
- Smaguma pakāpes: kritiska 5 punkti, kļūda 4, brīdinājums 3, norāde 2.
- Slieksnis pieprasījumiem:
tx.inbound_anomaly_score_threshold, noklusējums 5. - Slieksnis atbildēm:
tx.outbound_anomaly_score_threshold, noklusējums 4. - Paranojas līmeņi 1 līdz 4 failā
crs-setup.conf: 1. līmenis ir pamata drošība katram serverim internetā, 2. līmenis saskaņā ar projektu der lietojumprogrammām ar īstiem lietotāju datiem, piemēram, interneta veikaliem, 3. un 4. līmenis nes ievērojami vairāk kļūdainu trauksmju.
Augstāks paranojas līmenis atpazīst vairāk, bet rada arī vairāk kļūdainu trauksmju. Lielākajai daļai uzņēmumu vietņu 1. līmenis ir sākums, 2. līmenis vēlāks mērķis.
ModSecurity ar OWASP CRS ieviešana, neparalizējot vietni
CRS projekts jaunām instalācijām iesaka bloķēšanas režīmu ieslēgt uzreiz, bet ar ļoti augstiem sliekšņiem, līdz 10000, un tos pēc tam pakāpeniski pazemināt. Tā jūs uzkrājat pieredzi ar īstām piekļuvēm, neizslēdzot lietotājus. Sliekšņus iestatiet failā crs-setup.conf:
# crs-setup.conf: sākuma fāze ar ļoti augstiem sliekšņiem
SecAction \
"id:900110,\
phase:1,\
pass,\
t:none,\
nolog,\
setvar:tx.inbound_anomaly_score_threshold=10000,\
setvar:tx.outbound_anomaly_score_threshold=10000"
Iekļaušana zem Apache seko secībai, ko CRS dokumentācija nosaka spraudņiem. Ceļi atšķiras pa distributīviem:
<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>
Pēc tam izvērtējiet audita žurnālu, kas noteikts SecAuditLog. Kā sistemātiski pārmeklēt protokolus, apraksta Tīmekļa servera žurnālu izvērtēšana pēc uzbrukuma. Sliekšņus pazeminiet pakāpēs, piemēram, vairāku nedēļu laikā, līdz nonākat pie noklusējuma vērtības.
Kļūdainu trauksmju mērķtiecīga apstrāde
Kļūdainas trauksmes ir normālas, īpaši CMS aizmugurēs ar redaktoriem, kas saglabā HTML. Sliktākā reakcija ir WAF izslēgšana. Labāki ir divi rīki.
Pirmkārt, spraudņi: CRS projekts uztur spraudņus ar izņēmumu noteikumiem izplatītām lietojumprogrammām, piemēram, WordPress. Tos iekopē spraudņu mapē un ielādē ar augstāk parādītajām Include rindām. Oficiālo sarakstu projekts uztur savā spraudņu katalogā.
Otrkārt, savi, šauri formulēti izņēmumi. Nevis noteikumu izslēgt visur, bet izņemt to tikai ceļam, kurā tas traucē:
# Savs izņēmums, ielādēt PIRMS CRS noteikumiem (piem., *-before.conf)
SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \
"id:1000010,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=941100"
Noteikuma ID ņemiet no kļūdainās trauksmes audita žurnāla. Katru izņēmumu dokumentējiet ar iemeslu un datumu, lai to vēlāk varētu pārskatīt.
Pēc katras sliekšņu vai izņēmumu izmaiņas testējiet savas lietojumprogrammas kritiskos ceļus: pieteikšanos, pasūtījumu, maksājumu, kontaktformu un redakciju. WAF, kas bloķē pasūtījumus, tiek ātri atkal izslēgta.
Apache serveriem ir vērts WAF risināt kopā ar pārējo konfigurāciju; pamati atrodami sadaļā Apache droša konfigurēšana PHP. Kā Cloudflare noteikumi ir ierindojami salīdzinājumā, parāda Cloudflare aizsardzības noteikumi pret PHP2Shell. Pārejas pasākumi pašā serverī atrodami sadaļā Tūlītēji pasākumi, ja vēl nevarat ielāpot.
Secinājums: WAF vajag kopšanu
ModSecurity ar OWASP Core Rule Set dod jums jaudīgu Web Application Firewall bez licenču izmaksām un bez atkarības no ārēja pakalpojuma. Cena ir darbs: izvēlēties dzinēju, kas der tīmekļa serverim, sākt ar augstiem sliekšņiem, izvērtēt kļūdainas trauksmes, uzturēt izņēmumus un turēt noteikumus aktuālus.
Kas šo piepūli nevar nodrošināt, tam ar labi konfigurētu mākoņa WAF bieži klājas labāk. Kas to nodrošina, saņem slāni, kas pārtver daudzus standarta uzbrukumus un audita žurnālos sniedz vērtīgas norādes. Nevienā gadījumā tā neaizstāj atjauninājumu: pret PHP2Shell aizsargā tikai PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 vai apstiprināts backport, kam seko visu PHP procesu pārstartēšana.
Kā PHP SOS palīdz konkrēti?
- Izvēlēties dzinēju: mēs pārbaudām tīmekļa serveri, distributīvu un esošās pakotnes un iesakām piemērotu kombināciju.
- Ieviest: mēs instalējam CRS ar augstiem sākuma sliekšņiem, iekļaujam piemērotus spraudņus un ieviešam protokolēšanu.
- Noregulēt: vairāku nedēļu laikā mēs izvērtējam kļūdainas trauksmes, izveidojam mērķtiecīgus izņēmumus un pazeminām sliekšņus.
- Ierindot: WAF un virtuālās ielāpošanas ietvaros mēs WAF savienojam ar pārejas pasākumiem un ceļu uz regulāro ielāpu.
Biežāk uzdotie jautājumi
Vai OWASP CRS aizsargā pret PHP2Shell?
No tā nevajadzētu pieņemt. Core Rule Set atpazīst vispārīgus uzbrukumu paraugus un nav pielāgots konkrētai ievainojamībai. Cloudflare turklāt norāda, ka noteikumi tikai pēc pieprasījuma datiem PHP2Shell gadījumā nav pietiekami. PHP atjauninājums paliek obligāts.
Kuru dzinēju izvēlēties Nginx?
Saskaņā ar CRS projektu ModSecurity v3 gadījumā tikai Nginx savienotājs ir patiešām izmantojams produkcijā, un v3 neiztur nelielu daļu CRS testu. Alternatīva ir Coraza, kas pēc projekta datiem pilnībā iztur CRS v4 testu komplektu. Apache projekts iesaka ModSecurity v2.
Vai ModSecurity vēl tiek uzturēts?
Saskaņā ar CRS dokumentāciju Trustwave bija paziņojis par izstrādes beigšanu 2024. gadā. 2024. gada 25. janvārī projekts tika nodots OWASP Foundation un kopš tā laika tiek tur turpināts.
Kā novērst, ka WAF paralizē manu veikalu?
Sāciet ar ļoti augstiem anomāliju sliekšņiem, kā iesaka CRS projekts, un pakāpeniski tos pazeminiet. Pie tam izvērtējiet protokolus un izveidojiet mērķtiecīgus izņēmumus savai lietojumprogrammai, nevis noteikumus vispārīgi izslēdziet.