Lühidalt: Paljud PHP2Shelli näpunäited, mis praegu foorumites ja sotsiaalvõrgustikes levivad, ei kaitse või isegi kahjustavad: sessiooniküpsisega päringute blokeerimine, veateadete peitmine, sätete seadmine .user.ini kaudu või ainult CMS-i uuendamine. php.net on ühemõtteline: täielikke ajutisi meetmeid ei ole, PHP uuendus koos kõigi protsesside taaskäivitusega on ainus kindel tee.
Miks valenõuanded on selles olukorras ohtlikud
Kriitilise ja suure tähelepanuga turvaaugu puhul tekib kiirete lahenduste turg. Nõuandeid jagatakse, lühendatakse ja antakse edasi, sageli ilma algse allika piiranguteta. PHP2Shelli puhul lisandub, et üksikasjad said aruannete kohaselt teatavaks juba enne ametlikku tähtaega ja olukord oli esimestel päevadel ülevaatamatu.
Vale nõuanne kahjustab kahekordselt. See jätab turvaaugu lahti ja loob tunde, et midagi on tehtud. Just see tunne viib selleni, et tegelik uuendus jääb tegemata. Mõned nõuanded halvavad lisaks oma veebisaidi.
Üheksa nõuannet faktikontrollis
Järgmine tabel võtab kokku selle, mida oleme viimastel päevadel sageli lugenud, ja asetab sellele vastu esmaallikate väited.
| Levinud nõuanne | Miks see ei kanna | Mis selle asemel kehtib |
|---|---|---|
Blokeerida kõik päringud PHPSESSID-ga |
Erialaautorid lükkavad selgesõnaliselt tagasi; halvab sisselogimised ja ostukorvid | PHP uuendada |
session.upload_progress.enabled=0 piisab |
Erialaaruannete kohaselt ei sulge mõlemat turvaauku | Mõistlik ajutine meede, uuendus jääb kohustuslikuks |
Seada väärtused ini_set() või .user.ini kaudu |
php.net soovitab sellest selgesõnaliselt loobuda | Serveri poolel php.ini-s, FPM-poolis või serveri seadistuses |
| Veateated peita | php.net-i andmetel error_reporting, display_errors või @ ei aita |
Uuendus; veaväljundit ei tohi siiski avalikult näidata |
Piirata mälu RLIMIT_AS või RLIMIT_DATA kaudu |
php.net hoiatab, et just see võib haavatava olukorra esile kutsuda | Piir konteineri või cgroupi kaudu |
| Uuendada WordPressi või pluginaid | Turvaauk asub PHP interpretaatoris, mitte CMS-is | PHP käitusaega uuendada |
| Cloudflare või mõni muu WAF piisab | Kaitse ainult teenuse kaudu käiva liikluse jaoks; otse kättesaadavad serverid jäävad lahti | WAF täiendava kihina, mitte asendajana |
| Teenus uuesti laadida, mitte uuesti käivitada | Red Hati andmetel ei piisa laadimisest, olemasolevad töötajad võivad vana seisu säilitada | Kõik töötajad täielikult uuesti käivitada |
| Paigatud tähendab puhas | Paik ei eemalda varem sisse toodud pahavara | Logid alates 20.10. kindlustada ja jälgi kontrollida |
Kolm sagedasemat eksiarvamust täpsemalt
Küpsiste keeld
Nõuanne tagasi lükata kõik päringud sessiooniküpsisega PHPSESSID kõlab tehniliselt ja otsustavalt. Erialaautorid lükkavad selle selgesõnaliselt tagasi. Praktikas rikub see kõik, mis sessiooni vajab: kliendikontod, ostukorvid, administraatoriosad, võltsimiskaitsega vormid. Kaitset turvaauku vastu see ei paku.
Üks säte, mis kõik lahendab
session.upload_progress.enabled=0 seisab php.net-i soovitustes ja on CVE-2026-115560 vastu nimetatud abinõu. Mõnes artiklis sai sellest „PHP2Shell välja lülitatud“. Erialaaruannete kohaselt see säte üksi mõlemat turvaauku aga ei sulge. Ka memory_limit=-1 kõrvaldab php.net-i andmetel ainult juhitava päästiku; sügavamal tasandil tekkiv mäluviga võib haavatava teeni siiski jõuda. PHP 8.5 puhul blokeerib fatal_error_backtraces=0 php.net-i andmetel ainult kinnitatud tee backtrace'ide kaudu.
Kuidas säte siiski õigesti ja püsivalt seada, kirjeldab artikkel session.upload_progress väljalülitamine. Ajutiste meetmete täielik loend seisab lehel Kohesed meetmed ilma paigata.
Kaitsekilp ees
Cloudflare'i enda andmetel on alates 21. oktoobrist aktiivsed kaitsereeglid, ka tasuta paketi klientidele. Cloudflare ise juhib aga tähelepanu piiridele: kaitse rakendub ainult Cloudflare'i kaudu käivale liiklusele. Kui origin-server on otse kättesaadav, minnakse sellest mööda. Lisaks kontrollib Cloudflare täiendavalt serveri vastust, sest päringust üksi ei piisa alati. Miks WAF uuendust ei asenda, selgitab artikkel WAF või uuendus.
Risk nõuandega: üleslaadimispäringute filtreerimine serval
Mitte iga ebamugav nõuanne ei ole vale. Erialaautorid pakuvad ajutise mitteametliku meetmena blokeerida multipart/form-data päringud väljaspool tegelikke üleslaadimisteid puhverserveris või WAF-is. See võib ründepinda vähendada, kuid rikub vormid ja üleslaadimised, kui lubatud teede loend on poolik.
Kes seda teed läheb, peaks seda enne testkeskkonnas kontrollima, erialaosakondadega kooskõlastama ja ajutise meetmena dokumenteerima. Ka see ei ole uuenduse asendaja.
Paljud WAF-lahendused pakuvad selleks jälgimisrežiimi, kus reeglid esialgu ainult logivad, mitte ei blokeeri. Laske uuel reeglil mõni päev nii töötada ja analüüsige, millised õiguspärased päringud oleksid mõjutatud. Alles pärast seda lülitage blokeerimisele. Nii väldite, et kandideerimisvormid, kliendiportaalid või piltide üleslaadimine poes märkamatult välja langevad.
Nii kontrollite nõuannet enne selle rakendamist
Neli küsimust eristavad kasutatavaid nõuandeid ohtlikest:
- Allikas: Kas soovitus pärineb php.net-ist, teie distributsioonilt, BSI-lt või nimeliselt nimetatud erialaautorilt?
- Väide: Kas meedet kirjeldatakse üleminekuna või lahendusena? PHP2Shelli puhul on lahendus ainult uuendus.
- Kõrvalmõju: Mis katki läheb, kui meede rakendub? Nõuanne ilma viiteta kõrvalmõjudele on puudulik.
- Rakenduskoht: Kas säte seatakse serveri poolel ja üle kirjutamatult, millele järgneb kõigi töötajate taaskäivitus?
Pange kirja, milliseid ajutisi meetmeid te millal seadsite. Nii saate neid hiljem sihipäraselt kontrollida ja tunda ära, kas näiline kaitse on tegeliku uuenduse viivitanud.
Kuidas PHP SOS konkreetselt aitab?
- Kontrollime teil juba ellu viidud meetmeid ja eristame toimivad toimimatutest.
- Paigaldame PHP uuenduse, käivitame kõik protsessid uuesti ja tõendame seisu.
- Kus uuendus ei ole veel võimalik, seame php.net-i järgi ajutised meetmed serveri poolel ja dokumenteeritult.
- WAF-i ja virtuaalse paikamisega täiendame kaitset serval, uuendust asendamata.
Korduma kippuvad küsimused
Kas päringute blokeerimine PHPSESSID-ga kaitseb?
Ei. Erialaautorid lükkavad selle levinud nõuande selgesõnaliselt tagasi. See halvab sisselogimised, ostukorvid ja vormid, sulgemata interpretaatori turvaauku.
Kas session.upload_progress.enabled=0 piisab PHP2Shelli vastu?
Ei. Säte on üks mitmest ajutisest meetmest ja erialaaruannete kohaselt ei sulge see mõlemat turvaauku. See on mõistlik, kuid ei asenda PHP uuendust.
Kas display_errors väljalülitamine aitab?
PHP2Shelli puhul mitte. php.net juhib tähelepanu, et diagnostika peitmine error_reporting, display_errors või @-operaatori kaudu ei aita. Tootmises peaks display_errors muudel põhjustel siiski väljas olema.
Millest ma usaldusväärset nõuannet tunnen?
Usaldusväärne nõuanne nimetab oma allika, kirjeldab piire ja märgib ajutised meetmed ajutisteks. Kes lubab, et üksik säte teeb uuenduse üleliigseks, eksib PHP2Shelli puhul.