Trumpai: Daugelis PHP2Shell patarimų, kurie šiuo metu plinta forumuose ir socialiniuose tinkluose, neapsaugo arba net kenkia: blokuoti užklausas su sesijos slapuku, slėpti klaidų pranešimus, nustatymus nustatyti per .user.ini arba atnaujinti tik CMS. php.net yra nedviprasmiškas: pilnų pereinamųjų priemonių nėra, PHP atnaujinimas su visų procesų paleidimu iš naujo yra vienintelis saugus kelias.
Kodėl klaidingi patarimai tokioje padėtyje pavojingi
Kritinės spragos, sulaukiančios daug dėmesio, atveju atsiranda greitų sprendimų rinka. Patarimai dalijami, trumpinami ir perduodami toliau, dažnai be pirminio šaltinio apribojimų. Su PHP2Shell dar prisideda tai, kad detalės, pasak pranešimų, paaiškėjo dar prieš oficialų terminą, o pirmosiomis dienomis padėtis buvo neaiški.
Klaidingas patarimas kenkia dvigubai. Jis palieka spragą atvirą ir sukuria jausmą, kad kažkas padaryta. Būtent šis jausmas lemia, kad tikrasis atnaujinimas lieka nepadarytas. Kai kurie patarimai papildomai paralyžiuoja pačią svetainę.
Devyni patarimai faktų patikroje
Toliau pateikta lentelė apibendrina tai, ką pastarosiomis dienomis dažnai skaitėme, ir sugretina su pirminių šaltinių teiginiais.
| Plintantis patarimas | Kodėl netinka | Kas galioja vietoj to |
|---|---|---|
Blokuoti visas užklausas su PHPSESSID |
Specializuotų autorių aiškiai atmestas; paralyžiuoja prisijungimus ir krepšelius | Atnaujinti PHP |
session.upload_progress.enabled=0 pakanka |
Pasak specialistų pranešimų, neuždaro abiejų spragų | Prasminga pereinamoji priemonė, atnaujinimas lieka pareiga |
Reikšmes nustatyti per ini_set() ar .user.ini |
php.net aiškiai atkalbinėja | Serverio pusėje php.ini, FPM baseine ar serverio konfigūracijoje |
| Slėpti klaidų pranešimus | Pasak php.net, error_reporting, display_errors ar @ nepadeda |
Atnaujinimas; klaidų išvesties vis tiek viešai nerodyti |
Atmintį riboti per RLIMIT_AS ar RLIMIT_DATA |
php.net perspėja, kad būtent tai gali sukelti pažeidžiamą situaciją | Riba per konteinerį ar cgroup |
| Atnaujinti WordPress ar įskiepius | Spraga yra PHP interpretatoriuje, o ne CMS | Atnaujinti PHP vykdymo aplinką |
| Cloudflare ar kitos WAF pakanka | Apsauga tik srautui per paslaugą; tiesiogiai pasiekiami serveriai lieka atviri | WAF kaip papildomas sluoksnis, ne pakaitalas |
| Paslaugą perkrauti (reload), o ne paleisti iš naujo | Pasak Red Hat, perkrovimo (reload) nepakanka, esami worker gali išlaikyti senąją būseną | Visus worker visiškai paleisti iš naujo |
| Pataisyta reiškia švaru | Pataisa nepašalina anksčiau įterptos kenkėjiškos programinės įrangos | Žurnalus nuo 20.10. išsaugoti ir tikrinti dėl pėdsakų |
Trys dažniausios klaidos išsamiau
Slapukų draudimas
Patarimas atmesti visas užklausas su sesijos slapuku PHPSESSID skamba techniškai ir ryžtingai. Specializuoti autoriai jį aiškiai atmeta. Praktiškai jis sugriauna viską, kam reikia sesijos: klientų paskyras, krepšelius, administravimo zonas, formas su apsauga nuo klastojimo. Apsauga nuo spragos jis nėra.
Vienas nustatymas, kuris viską išsprendžia
session.upload_progress.enabled=0 yra php.net rekomendacijose ir yra nurodyta priemonė dėl CVE-2026-115560. Kai kuriuose straipsniuose iš to tapo „PHP2Shell išjungta“. Pasak specialistų pranešimų, vien šis nustatymas neuždaro abiejų spragų. Ir memory_limit=-1, pasak php.net, pašalina tik valdomą sukėlėją; gilesnio lygio atminties klaida vis tiek gali pasiekti pažeidžiamą kelią. Su PHP 8.5 fatal_error_backtraces=0, pasak php.net, blokuoja tik patvirtintą kelią per sekos pėdsakus (backtraces).
Kaip nustatymą vis tiek teisingai ir ilgam nustatyti, aprašo straipsnis session.upload_progress išjungimas. Pilną pereinamųjų priemonių sąrašą rasite skyrelyje Skubios priemonės be pataisos.
Apsauginis skydas prieš tai
Cloudflare, pasak jos pačios, nuo spalio 21 d. turi įjungtas apsaugos taisykles, taip pat nemokamo plano klientams. Tačiau pati Cloudflare nurodo ribas: apsauga veikia tik srautui, einančiam per Cloudflare. Jei šaltinio serveris pasiekiamas tiesiogiai, ji apeinama. Be to, Cloudflare papildomai tikrina serverio atsakymą, nes vien užklausos ne visada pakanka. Kodėl WAF atnaujinimo nepakeičia, paaiškina straipsnis WAF ar atnaujinimas.
Patarimas su rizika: įkėlimo užklausų filtravimas pakraštyje
Ne kiekvienas nepatogus patarimas yra klaidingas. Specializuoti autoriai kaip laikiną, neoficialią priemonę siūlo multipart/form-data užklausas už tikrųjų įkėlimo kelių ribų blokuoti tarpiniame serveryje (proxy) ar WAF. Tai gali sumažinti atakos paviršių, bet sugriauna formas ir įkėlimus, jei leidžiamų kelių sąrašas neišsamus.
Kas šį kelią renkasi, turėtų jį iš anksto išbandyti bandomojoje aplinkoje, suderinti su skyriais ir dokumentuoti kaip terminuotą priemonę. Atnaujinimo pakaitalas ir ji nėra.
Daugelis WAF sprendimų tam siūlo stebėjimo režimą, kuriame taisyklės iš pradžių tik žurnalina, o ne blokuoja. Leiskite naujai taisyklei kelias dienas taip veikti ir įvertinkite, kurios teisėtos užklausos būtų paveiktos. Tik po to perjunkite į blokavimą. Taip išvengsite, kad nepastebimai nustotų veikti paraiškų formos, klientų portalai ar paveikslėlių įkėlimas parduotuvėje.
Kaip patikrinti patarimą prieš jį taikant
Keturi klausimai atskiria naudingus patarimus nuo pavojingų:
- Šaltinis: ar rekomendacija kyla iš php.net, jūsų distribucijos, BSI ar vardu įvardinto specializuoto autoriaus?
- Pretenzija: ar priemonė aprašoma kaip pereinamoji, ar kaip sprendimas? Su PHP2Shell sprendimas yra tik atnaujinimas.
- Šalutinis poveikis: kas sulūžta, kai priemonė suveikia? Patarimas be nuorodos į šalutinį poveikį yra neišsamus.
- Įgyvendinimo vieta: ar nustatymas nustatomas serverio pusėje ir taip, kad nebūtų perrašomas, po to paleidžiant iš naujo visus worker?
Užfiksuokite, kokias pereinamąsias priemones kada nustatėte. Taip galėsite jas vėliau tikslingai peržiūrėti ir atpažinti, ar tariama apsauga nepaaiškino tikrojo atnaujinimo.
Kaip PHP SOS padeda konkrečiai?
- Patikriname priemones, kurios pas jus jau įgyvendintos, ir atskiriame veiksmingas nuo neveiksmingų.
- Įdiegiame PHP atnaujinimą, iš naujo paleidžiame visus procesus ir įrodome būklę.
- Kur atnaujinimas dar neįmanomas, pereinamąsias priemones pagal php.net taikome serverio pusėje ir dokumentuotai.
- Su WAF ir virtualiu pataisymu papildome apsaugą pakraštyje, nepakeisdami atnaujinimo.
Dažni klausimai
Ar apsaugo užklausų su PHPSESSID blokavimas?
Ne. Specializuoti autoriai šį plintantį patarimą aiškiai atmeta. Jis paralyžiuoja prisijungimus, krepšelius ir formas, neuždarydamas spragos interpretatoriuje.
Ar session.upload_progress.enabled=0 pakanka nuo PHP2Shell?
Ne. Nustatymas yra viena iš kelių pereinamųjų priemonių ir, pasak specialistų pranešimų, neuždaro abiejų spragų. Jis prasmingas, bet PHP atnaujinimo nepakeičia.
Ar padeda išjungti display_errors?
PHP2Shell atveju ne. php.net nurodo, kad diagnostikos slėpimas per error_reporting, display_errors ar @ operatorių nepadeda. Gamyboje display_errors vis tiek turėtų būti išjungtas kitais pagrindais.
Kaip atpažinti patikimą patarimą?
Patikimas patarimas nurodo savo šaltinį, aprašo ribas ir pereinamąsias priemones taip ir vadina. Kas žada, kad vienas nustatymas atnaujinimą daro nebereikalingu, su PHP2Shell klysta.