Pe scurt: Cloudflare are active, potrivit propriilor declarații, din 21 octombrie 2026, ora 03:02 UTC, reguli de protecție împotriva PHP2Shell, inclusiv pentru clienții din planul gratuit. Regulile reduc riscul pentru traficul care trece prin Cloudflare. Ele nu acționează dacă serverul de origine este accesibil direct și nu înlocuiesc actualizarea PHP. Cine folosește Cloudflare ar trebui să verifice modul regulilor, protecția originii și nivelul de patch.
Punctul de plecare: protecție încă dinaintea patchului
Cloudflare a fost neobișnuit de devreme la PHP2Shell. Potrivit blogului Cloudflare, regulile de protecție funcționau cu mai multe ore înaintea publicării oficiale a actualizărilor PHP, la ora 14:00 UTC. Cloudflare a relatat, de asemenea, că a observat încercări de atac asupra clienților și că atacatorii și-au schimbat tiparele pentru a ocoli regulile.
Mulți operatori au tras concluzia: „Suntem în spatele Cloudflare, deci suntem protejați.” Aceasta este adevărat doar în parte. Acest articol explică ce acoperă efectiv regulile. O cântărire generală între firewall și actualizare oferă articolul WAF sau actualizare?.
Ce a lansat Cloudflare împotriva PHP2Shell
Potrivit blogului Cloudflare, există trei elemente:
| Plan | Protecție conform Cloudflare | Ce ar trebui să faceți |
|---|---|---|
| Free | reguli noi în Managed Free Ruleset, active automat | verificați că domeniul rulează prin Cloudflare |
| Pro, Business, Enterprise | reguli corespunzătoare în Managed Ruleset | asigurați-vă că ruleset-ul este pe „Block” |
| toate planurile | regulă standard în noul firewall de răspunsuri | nu dezactivați nimic, observați evenimentele |
Al treilea element este nou. Cloudflare îl numește „full transaction detection”: WAF-ul analizează nu doar cererea, ci și răspunsul serverului. Motivul, potrivit Cloudflare: cererea singură nu este întotdeauna suficientă pentru a distinge cu certitudine un atac de traficul normal. PHP2Shell este prima utilizare a acestei funcții în regulile gestionate.
Limitele regulilor Cloudflare
Oricât de utile sunt regulile, ele au limite clare, pe care Cloudflare însuși le menționează în parte:
- Doar traficul prin Cloudflare: Regulile verifică ce trece prin Cloudflare. Dacă serverul de origine este accesibil direct la adresa sa IP, un atacator poate ocoli protecția.
- Fără anulare: Potrivit Cloudflare, o regulă pe partea de răspuns poate reține răspunsul, dar nu poate anula ce s-a întâmplat deja pe server.
- Tipare de atac în schimbare: Cloudflare adaptează regulile continuu, deoarece atacatorii își modifică cererile. Între varianta nouă și regula nouă poate exista un decalaj.
- Nu înlocuiesc actualizarea: Cloudflare recomandă explicit actualizarea PHP în pofida WAF. Nici o actualizare a codului aplicației sau a pluginurilor nu remediază vulnerabilitățile.
- Caz special CVE-2026-115560: Potrivit completării Cloudflare din 23 octombrie, regula nu se aplică dacă numele pentru session upload progress a fost modificat în configurație. Mai multe despre acest anunț la CVE-2026-115560.
Ce spun cererile blocate și ce nu
Mulți clienți se uită după anunț în evenimentele lor de securitate și găsesc acolo cereri blocate. Aceasta arată inițial doar că domeniul dumneavoastră a fost verificat și regula a acționat. O intruziune nu este dovedită prin aceasta. Invers, o listă goală de evenimente nu este o încetare a alertei: dacă un atac a mers direct către serverul de origine sau înainte de 21 octombrie, el nu apare deloc la Cloudflare.
Mai fiabilă este compararea cu logurile serverului web însuși. Cererile care ajung acolo, dar nu provin de la adrese Cloudflare, indică un acces direct. Salvați aceste loguri începând cu 20 octombrie, așa cum recomandă presa de specialitate. Cloudflare atrage atenția, de asemenea, că restricțiile pentru upload-uri pot reduce riscul, dar nu înlocuiesc actualizarea PHP.
Cea mai frecventă slăbiciune în spatele Cloudflare nu este regula, ci calea pe lângă ea: un server de origine care răspunde direct la adresa sa IP sau printr-un subdomeniu neprotejat.
Listă de verificare pentru clienții Cloudflare
Acești pași îi puteți face dumneavoastră sau prestatorul dumneavoastră pe termen scurt:
- Verificați planul și modul regulilor: La planurile plătite, controlați în dashboard că Managed Ruleset este activ în modul „Block”.
- Priviți evenimentele de securitate: Verificați în Security Events dacă apar cereri blocate. Aceasta arată dacă domeniile dumneavoastră au fost deja o țintă.
- Parcurgeți intrările DNS: Orice intrare care indică spre serverul web, dar nu trece prin Cloudflare, este o ocolire posibilă. Tipice sunt subdomeniile pentru staging, FTP sau e-mail pe același server.
- Închideți originea: Configurați serverul web astfel încât să accepte HTTP și HTTPS doar de la Cloudflare, de exemplu prin firewall cu intervalele de adrese publicate de Cloudflare sau printr-un tunel. Cum se face acest lucru în general descrie articolul Firewall pentru serverul web.
- Testați accesul direct: Verificați din exterior dacă originea răspunde fără Cloudflare.
- Actualizați PHP și reporniți: Regulile sunt a doua linie. Prima este PHP într-o versiune corectată, cu repornirea tuturor proceselor PHP.
Pentru pasul 5 este suficient un test inofensiv, care interoghează doar antetele. Adresa IP este un înlocuitor pentru serverul dumneavoastră de origine:
# Răspunde serverul de origine direct, pe lângă Cloudflare?
curl -sI --resolve www.example.de:443:203.0.113.10 https://www.example.de/
Dacă aici vine un răspuns obișnuit al site-ului dumneavoastră, originea este accesibilă direct, iar protecția Cloudflare poate fi ocolită.
Cum ajută PHP SOS concret?
- Verificarea configurației: Verificăm modul regulilor, intrările DNS și accesul direct la serverul de origine.
- Securizarea originii: Restricționăm serverul web la traficul prin Cloudflare, fără a vă întrerupe site-ul.
- Patch și dovadă: Actualizăm PHP, repornim toate procesele și documentăm starea.
- Evaluarea evenimentelor: Analizăm cererile blocate și le comparăm cu logurile serverului.
Cum combinăm regulile WAF și măsurile provizorii descrie WAF și patch virtual.
Concluzie
Regulile Cloudflare împotriva PHP2Shell sunt un câștig real, mai ales pentru că au venit devreme și și în planul gratuit. Ele sunt însă un scut în fața ușii, nu o broască la ușă. Cine se află în spatele Cloudflare ar trebui să se asigure de trei lucruri: reguli în modul Block, nicio cale pe lângă proxy și PHP într-o versiune corectată.
Întrebări frecvente
Sunt protejat împotriva PHP2Shell cu planul gratuit Cloudflare?
Potrivit Cloudflare, și clienții Free primesc automat regulile de protecție. Ele acționează însă doar pentru traficul care trece prin Cloudflare și nu înlocuiesc actualizarea PHP de pe server. Dacă serverul de origine este accesibil direct, protecția nu se aplică.
Ce trebuie să setez la planurile Cloudflare plătite?
Cloudflare recomandă clienților cu planurile Pro, Business și Enterprise să verifice dacă Managed Ruleset rulează în modul Block. Dacă este setat doar pe înregistrare în jurnal, atacurile sunt consemnate, dar nu sunt oprite.
Ce este full transaction detection?
O funcție nouă a WAF-ului Cloudflare, care analizează nu doar cererea, ci și răspunsul serverului. Astfel se poate recunoaște dacă o încercare de atac are efect, iar răspunsul poate fi reținut. Ce a fost deja executat pe server nu se anulează, potrivit Cloudflare.
Acoperă Cloudflare și CVE-2026-115560?
Cloudflare și-a completat articolul pe 23 octombrie cu privire la CVE-2026-115560. Potrivit Cloudflare, regula corespunzătoare nu se aplică dacă numele pentru session upload progress a fost modificat în configurația PHP. Independent de aceasta, php.net recomandă setarea session.upload_progress.enabled=0.