Pe scurt: ModSecurity este un Web Application Firewall care rulează în serverul web; OWASP Core Rule Set (CRS) furnizează reguli liber disponibile împotriva tipurilor răspândite de atac. Pentru Apache, proiectul CRS recomandă ModSecurity v2, pentru Nginx vin în discuție conectorul v3 sau Coraza. Porniți în modul de blocare cu praguri de anomalie foarte ridicate, reduceți-le treptat și tratați alarmele false cu excepții țintite. O actualizare PHP nu este înlocuită de aceasta.
Un WAF propriu ca strat suplimentar
De la PHP2Shell, multe firme se întreabă dacă au nevoie de un Web Application Firewall. Cine își livrează site-urile prin Cloudflare are, potrivit Cloudflare, reguli de protecție active automat din 21 octombrie 2026. Cine nu face asta sau nu vrea să direcționeze traficul prin terți poate opera un WAF direct pe propriul server.
Cea mai cunoscută combinație pentru aceasta este ModSecurity cu OWASP Core Rule Set. Ambele sunt open source și gratuite. CRS este o colecție de reguli generale de recunoaștere, de exemplu împotriva SQL-Injection, Cross-Site-Scripting sau introducerii de fișiere. Proiectul își descrie el însuși obiectivul ca detectare generală a atacurilor cu cât mai puține alarme false, ca un element printre mai multe.
Astfel este numită și limita. Un WAF verifică cereri și răspunsuri, nu repară vulnerabilități din interpretorul PHP. De ce aveți nevoie de ambele descrie WAF sau actualizare: de ce aveți nevoie de ambele.
Ce motor se potrivește cu serverul dumneavoastră web
Setul de reguli are nevoie de un motor care să îl execute. Potrivit documentației CRS, există trei opțiuni compatibile:
| Motor | Server web | Încadrare conform proiectului CRS |
|---|---|---|
| ModSecurity v2 | Apache (modul) | implementare de referință, recomandat pentru Apache |
| ModSecurity v3 (libModSecurity) | mai ales Nginx prin conector | doar conectorul Nginx poate fi folosit cu adevărat în producție; nu trece 2 până la 4 la sută din testele CRS |
| Coraza | proxy-uri și integrări bazate pe Go | trece complet suita de teste CRS v4 |
Pentru context: ModSecurity a fost dezvoltat mult timp de Trustwave. Trustwave a anunțat în 2021 că încheie dezvoltarea în 2024. La 25 ianuarie 2024, proiectul a trecut la OWASP Foundation. Pentru instalări noi, verificați ce versiune livrează distribuția dumneavoastră și cât de actuală este.
Cum lucrează Core Rule Set
În setarea implicită, CRS nu blochează la prima anomalie suspectă. Lucrează cu puncte de anomalie: fiecare regulă declanșată adaugă puncte în funcție de gravitate, și abia când suma depășește un prag, cererea este respinsă.
- Niveluri de gravitate: critic 5 puncte, eroare 4, avertisment 3, notă 2.
- Pragul pentru cereri:
tx.inbound_anomaly_score_threshold, implicit 5. - Pragul pentru răspunsuri:
tx.outbound_anomaly_score_threshold, implicit 4. - Niveluri de paranoia de la 1 la 4 în
crs-setup.conf: nivelul 1 este securizarea de bază pentru orice server din internet, nivelul 2 se potrivește, potrivit proiectului, aplicațiilor cu date reale ale utilizatorilor, precum magazinele online, nivelurile 3 și 4 aduc considerabil mai multe alarme false.
Un nivel de paranoia mai ridicat recunoaște mai mult, dar produce și mai multe alarme false. Pentru majoritatea site-urilor de firmă, nivelul 1 este startul, iar nivelul 2 o țintă ulterioară.
Introducerea ModSecurity cu OWASP CRS fără a paraliza site-ul
Proiectul CRS recomandă, pentru instalări noi, activarea modului de blocare încă de la început, dar cu praguri foarte ridicate, până la 10000, reduse apoi treptat. Astfel acumulați experiență cu accesări reale, fără a exclude utilizatori. Pragurile le stabiliți în crs-setup.conf:
# crs-setup.conf: faza de pornire cu praguri foarte ridicate
SecAction \
"id:900110,\
phase:1,\
pass,\
t:none,\
nolog,\
setvar:tx.inbound_anomaly_score_threshold=10000,\
setvar:tx.outbound_anomaly_score_threshold=10000"
Includerea sub Apache urmează ordinea pe care documentația CRS o prescrie pentru pluginuri. Căile diferă în funcție de distribuție:
<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>
Apoi evaluați jurnalul de audit, stabilit în SecAuditLog. Cum căutați sistematic în jurnale descrie Evaluarea jurnalelor serverului web după un atac. Reduceți pragurile în trepte, de exemplu pe parcursul mai multor săptămâni, până ajungeți la valoarea implicită.
Tratarea țintită a alarmelor false
Alarmele false sunt normale, în special în backend-urile CMS cu editoare care salvează HTML. Cea mai proastă reacție este dezactivarea WAF. Mai bune sunt două unelte.
În primul rând, pluginurile: proiectul CRS întreține pluginuri cu reguli de excepție pentru aplicații răspândite, de exemplu pentru WordPress. Ele se copiază în dosarul de pluginuri și se încarcă prin rândurile Include arătate mai sus. Lista oficială o ține proiectul în directorul său de pluginuri.
În al doilea rând, excepții proprii, strict delimitate. În loc să dezactivați o regulă peste tot, o scoateți doar pentru calea la care deranjează:
# Excepție proprie, de încărcat ÎNAINTE de regulile CRS (de ex. într-un *-before.conf)
SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \
"id:1000010,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=941100"
ID-ul regulii îl aflați din jurnalul de audit al alarmei false. Documentați fiecare excepție cu motiv și dată, pentru ca ea să poată fi reverificată ulterior.
După fiecare modificare a pragurilor sau a excepțiilor, testați căile critice ale aplicației dumneavoastră: autentificare, comandă, plată, formular de contact și redacție. Un WAF care blochează comenzi este repede dezactivat la loc.
Pentru serverele Apache merită abordarea WAF împreună cu restul configurației; bazele se găsesc la Configurarea sigură a Apache pentru PHP. Cum se încadrează regulile Cloudflare în comparație arată Regulile de protecție Cloudflare împotriva PHP2Shell. Măsurile provizorii de pe serverul însuși se găsesc la Măsuri imediate dacă nu puteți încă aplica patchul.
Concluzie: un WAF are nevoie de îngrijire
ModSecurity cu OWASP Core Rule Set vă oferă un Web Application Firewall performant, fără costuri de licență și fără dependență de un serviciu extern. Prețul este munca: alegerea motorului potrivit pentru serverul web, începutul cu praguri ridicate, evaluarea alarmelor false, întreținerea excepțiilor și menținerea actuală a regulilor.
Cine nu poate depune acest efort se descurcă adesea mai bine cu un WAF în cloud bine configurat. Cine îl depune obține un strat care oprește multe atacuri standard și oferă indicii valoroase în jurnalele de audit. În niciun caz nu înlocuiește actualizarea: împotriva PHP2Shell protejează doar PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 sau un backport confirmat, urmat de repornirea tuturor proceselor PHP.
Cum ajută PHP SOS concret?
- Alegerea motorului: Verificăm serverul web, distribuția și pachetele existente și recomandăm combinația potrivită.
- Introducere: Instalăm CRS cu praguri de pornire ridicate, includem pluginurile potrivite și configurăm jurnalizarea.
- Reglare: Pe parcursul mai multor săptămâni evaluăm alarmele false, creăm excepții țintite și reducem pragurile.
- Încadrare: În cadrul WAF și patching virtual legăm WAF de măsurile provizorii și de calea spre patchul regulat.
Întrebări frecvente
Mă protejează OWASP CRS de PHP2Shell?
Nu ar trebui să presupuneți asta. Core Rule Set recunoaște tipare generale de atac și nu este croit pentru o vulnerabilitate anume. Cloudflare atrage în plus atenția că, la PHP2Shell, regulile bazate doar pe datele cererii nu sunt suficiente. Actualizarea PHP rămâne obligatorie.
Ce motor să aleg pentru Nginx?
Potrivit proiectului CRS, la ModSecurity v3 doar conectorul Nginx poate fi folosit cu adevărat în producție, iar v3 nu trece o mică parte din testele CRS. Alternativ există Coraza, care, potrivit proiectului, trece complet suita de teste CRS v4. Pentru Apache, proiectul recomandă ModSecurity v2.
Mai este ModSecurity întreținut?
Potrivit documentației CRS, Trustwave anunțase încheierea dezvoltării în 2024. La 25 ianuarie 2024, proiectul a fost predat OWASP Foundation și este continuat de atunci acolo.
Cum împiedic WAF să-mi paralizeze magazinul?
Porniți cu praguri de anomalie foarte ridicate, așa cum recomandă proiectul CRS, și reduceți-le treptat. Evaluați în acest timp jurnalele și creați excepții țintite pentru aplicația dumneavoastră, în loc să dezactivați regulile în bloc.