Trumpai: Pasak jos pačios, Cloudflare nuo 2026 m. spalio 21 d. 03:02 UTC turi įjungtas apsaugos taisykles nuo PHP2Shell, taip pat nemokamo plano klientams. Taisyklės sumažina riziką srautui, einančiam per Cloudflare. Jos neveikia, jei šaltinio serveris pasiekiamas tiesiogiai, ir PHP atnaujinimo nepakeičia. Kas naudoja Cloudflare, turėtų patikrinti taisyklių režimą, šaltinio apsaugą ir pataisų būseną.
Pradžia: apsauga dar prieš pataisą
Su PHP2Shell Cloudflare pasirodė neįprastai anksti. Pasak Cloudflare tinklaraščio, apsaugos taisyklės veikė jau kelias valandas prieš oficialų PHP atnaujinimų paskelbimą 14:00 UTC. Cloudflare dar pranešė pastebėjusi atakos bandymų prieš klientus ir kad užpuolikai keitė savo šablonus, kad apeitų taisykles.
Daugelis operatorių padarė išvadą: „Esame už Cloudflare, vadinasi, apsaugoti.“ Tai tik iš dalies tiesa. Šis straipsnis paaiškina, ką taisyklės iš tikrųjų apima. Bendrą užkardos ir atnaujinimo svarstymą pateikia straipsnis WAF ar atnaujinimas?.
Ką Cloudflare išleido prieš PHP2Shell
Pagal Cloudflare tinklaraščio duomenis yra trys dalys:
| Planas | Apsauga pagal Cloudflare | Ką turėtumėte daryti |
|---|---|---|
| Free | naujos taisyklės Managed Free Ruleset, įjungtos automatiškai | patikrinti, ar domenas veikia per Cloudflare |
| Pro, Business, Enterprise | atitinkamos taisyklės Managed Ruleset | užtikrinti, kad Ruleset būtų „Block“ režimu |
| visi planai | standartinė taisyklė naujoje atsakymų užkardoje (Response Firewall) | nieko neišjungti, stebėti įvykius |
Trečioji dalis nauja. Cloudflare ją vadina „full transaction detection“: WAF vertina ne tik užklausą, bet ir serverio atsakymą. Priežastis, pasak Cloudflare: vien užklausos ne visada pakanka patikimai atskirti ataką nuo įprasto srauto. PHP2Shell yra pirmas šios funkcijos panaudojimas valdomose taisyklėse.
Cloudflare taisyklių ribos
Kad ir kokios naudingos taisyklės, jos turi aiškias ribas, kurias iš dalies įvardija pati Cloudflare:
- Tik srautas per Cloudflare: Taisyklės tikrina tai, kas teka per Cloudflare. Jei šaltinio serveris pasiekiamas tiesiogiai jo IP adresu, užpuolikas gali apsaugą apeiti.
- Negalima atšaukti: Pasak Cloudflare, atsakymo pusės taisyklė gali sulaikyti atsakymą, bet negali anuliuoti to, kas serveryje jau įvyko.
- Kintantys atakų šablonai: Cloudflare taisykles nuolat derina, nes užpuolikai keičia savo užklausas. Tarp naujo varianto ir naujos taisyklės gali būti spraga.
- Ne atnaujinimo pakaitalas: Cloudflare aiškiai rekomenduoja PHP atnaujinti nepaisant WAF. Programos kodo ar įskiepių atnaujinimas spragų taip pat nepašalina.
- Ypatingas atvejis CVE-2026-115560: Pasak Cloudflare papildymo spalio 23 d., taisyklė neveikia, jei konfigūracijoje pakeistas sesijos įkėlimo eigos pavadinimas. Daugiau apie šį pranešimą skyrelyje CVE-2026-115560.
Ką blokuotos užklausos sako ir ko nesako
Daug klientų po pranešimo pažiūri į savo saugumo įvykius ir randa ten blokuotų užklausų. Tai iš pradžių rodo tik tai, kad jūsų domenas buvo tikrinamas ir taisyklė suveikė. Įsilaužimas tuo neįrodytas. Atvirkščiai, tuščias įvykių sąrašas nėra atoslūgis: jei ataka vyko tiesiai į šaltinio serverį arba iki spalio 21 d., Cloudflare jos išvis nerodys.
Patikimiau yra palyginimas su paties žiniatinklio serverio žurnalais. Užklausos, kurios ten pasiekia, bet nėra iš Cloudflare adresų, rodo tiesioginę prieigą. Šiuos žurnalus išsaugokite nuo spalio 20 d., kaip pataria specializuota spauda. Cloudflare taip pat nurodo, kad įkėlimų apribojimai gali sumažinti riziką, bet PHP atnaujinimo nepakeičia.
Dažniausias pažeidžiamumas už Cloudflare yra ne taisyklė, o kelias pro ją: šaltinio serveris, kuris atsako tiesiogiai savo IP adresu ar per neapsaugotą subdomeną.
Cloudflare klientų tikrinimo sąrašas
Šiuos žingsnius galite atlikti jūs arba jūsų paslaugų teikėjas per trumpą laiką:
- Patikrinti planą ir taisyklių režimą: mokamuose planuose valdymo skydelyje patikrinti, ar Managed Ruleset aktyvus „Block“ režimu.
- Peržiūrėti saugumo įvykius: Security Events skyriuje patikrinti, ar yra blokuotų užklausų. Tai rodo, ar jūsų domenai jau buvo taikinys.
- Peržiūrėti DNS įrašus: kiekvienas įrašas, rodantis į žiniatinklio serverį, bet neinantis per Cloudflare, yra galimas aplinkkelis. Tipiškos yra bandomųjų aplinkų (staging), FTP ar pašto subdomenos tame pačiame serveryje.
- Uždaryti šaltinį: sukonfigūruoti žiniatinklio serverį, kad HTTP ir HTTPS priimtų tik iš Cloudflare, pavyzdžiui, užkarda su Cloudflare paskelbtais adresų diapazonais arba tuneliu. Kaip tai daroma apskritai, aprašo straipsnis Žiniatinklio serverio užkarda.
- Išbandyti tiesioginę prieigą: iš išorės patikrinti, ar šaltinis atsako be Cloudflare.
- Atnaujinti PHP ir paleisti iš naujo: taisyklės yra antra gynybos linija. Pirma yra PHP ištaisytoje būsenoje su visų PHP procesų paleidimu iš naujo.
5 žingsniui pakanka nekenksmingo bandymo, užklausiančio tik antraštes. IP adresas yra vietos žymeklis jūsų šaltinio serveriui:
# Ar šaltinio serveris atsako tiesiogiai, apeidamas Cloudflare?
curl -sI --resolve www.example.de:443:203.0.113.10 https://www.example.de/
Jei čia ateina įprastas jūsų svetainės atsakymas, šaltinis pasiekiamas tiesiogiai ir Cloudflare apsaugą galima apeiti.
Kaip PHP SOS padeda konkrečiai?
- Konfigūracijos patikra: Tikriname taisyklių režimą, DNS įrašus ir tiesioginę prieigą prie šaltinio serverio.
- Šaltinio apsauga: Apribojame žiniatinklio serverį srautui per Cloudflare, nenutraukdami jūsų svetainės veikimo.
- Pataisa ir įrodymas: Atnaujiname PHP, iš naujo paleidžiame visus procesus ir dokumentuojame būklę.
- Įvykių vertinimas: Peržiūrime blokuotas užklausas ir lyginame jas su serverio žurnalais.
Kaip derename WAF taisykles ir pereinamąsias priemones, aprašo WAF ir virtualus pataisymas.
Išvada
Cloudflare taisyklės nuo PHP2Shell yra tikras laimėjimas, ypač todėl, kad atsirado anksti ir nemokamame plane. Bet tai yra skydas prieš duris, o ne spyna ant durų. Kas yra už Cloudflare, turėtų užtikrinti tris dalykus: taisyklės Block režimu, jokio kelio pro tarpinį serverį ir PHP ištaisytoje būsenoje.
Dažni klausimai
Ar su nemokamu Cloudflare planu esu apsaugotas nuo PHP2Shell?
Pasak Cloudflare, apsaugos taisykles automatiškai gauna ir nemokamo plano klientai. Bet jos veikia tik srautui, einančiam per Cloudflare, ir nepakeičia PHP atnaujinimo serveryje. Jei šaltinio serveris pasiekiamas tiesiogiai, apsauga neveikia.
Ką turiu nustatyti mokamuose Cloudflare planuose?
Cloudflare pataria Pro, Business ir Enterprise planų klientams patikrinti, ar Managed Ruleset veikia Block režimu. Jei jis nustatytas tik žurnalavimui, atakos fiksuojamos, bet nesustabdomos.
Kas yra full transaction detection?
Nauja Cloudflare WAF funkcija, kuri vertina ne tik užklausą, bet ir serverio atsakymą. Taip galima atpažinti, ar atakos bandymas turi poveikį, ir atsakymą galima sulaikyti. To, kas serveryje jau buvo įvykdyta, ji, pasak Cloudflare, neatšaukia.
Ar Cloudflare apima ir CVE-2026-115560?
Cloudflare spalio 23 d. papildė savo straipsnį apie CVE-2026-115560. Pasak Cloudflare, atitinkama taisyklė neveikia, jei PHP konfigūracijoje pakeistas sesijos įkėlimo eigos (session upload progress) pavadinimas. Nepriklausomai nuo to php.net rekomenduoja nustatyti session.upload_progress.enabled=0.