Na kratko: Pri oblačnih ponudnikih in ponudnikih PaaS popravka ne izvede samodejno ponudnik. Če izvajalno okolje PHP upravlja on, ga posodablja, pogosto pa šele z naslednjo namestitvijo. Če slike ali gradnje izdelujete sami ali platformo upravljate sami, morate graditi znova in uvesti. Merodajno je vedno izvajalno okolje, ki ga vaša spletna stran trenutno streže.
Posodobitev PHP pri PaaS: čigavo je izvajalno okolje?
Platformne storitve, v strokovnem žargonu PaaS (Platform as a Service), podjetjem odvzamejo upravljanje strežnikov. Naložite kodo, platforma jo zgradi in upravlja. Pri PHP2Shell iz tega nastane tipična negotovost: kdo naj sploh posodobi PHP?
Vercel v svojem biltenu o PHP2Shell stvar povzame: posodobitev lokalnega razvojnega okolja, kode aplikacije ali vtičnikov ne zadošča. Odločilno je izvajalno okolje PHP namestitve, ki dejansko odgovarja na zahteve. Ali je to izvajalno okolje popravljeno, je odvisno od tega, kdo ga zagotavlja in kdaj je bilo nazadnje zgrajeno.
Štirje modeli delovanja v primerjavi
Poimenovanja ponudnikov se razlikujejo. Za vprašanje popravkov je večino ponudb mogoče uvrstiti v enega od teh modelov:
| Model | Kdo posodablja PHP? | Kaj morate storiti |
|---|---|---|
| Izvajalno okolje, ki ga upravlja ponudnik | Ponudnik | Pridobite potrditev, po potrebi znova uvedite, da nova različica začne veljati |
| Izvajalno okolje na podlagi gradnje (buildpack) | Ponudnik zagotovi novo različico, vaša gradnja jo zaklene | Sprožite novo gradnjo, različico preverite v dnevniku gradnje |
| Lastna slika vsebnika | Vi | Sliko z odpravljenim PHP znova zgradite in uvedite |
| Platforma, ki jo upravljate sami | Vi, za platformo in aplikacije | Popravite platformo in vsako aplikacijo posebej |
Mnoga podjetja uporabljajo več modelov hkrati, na primer upravljano izvajalno okolje za spletno stran in lastne vsebnike za notranja orodja. Vsaka aplikacija zato potrebuje svoj odgovor.
Past je v besedi „upravljano“. Tudi če izvajalno okolje vzdržuje ponudnik, že uvedena aplikacija pogosto teče naprej s stanjem, s katerim je bila zgrajena. Nova različica potem začne veljati šele ob naslednji gradnji ali namestitvi. Nekatere platforme poleg tega starejše namestitve ali predogledna okolja ohranjajo dosegljiva na lastnih naslovih. Zato ne vprašajte samo, ali je ponudnik popravil, ampak tudi, od kdaj vaši tekoči primerki popravek uporabljajo in kaj se zgodi s starimi namestitvami.
Kaj o PHP2Shell pravita Vercel in Coolify
Dva ponudnika sta svoja navodila javno objavila. Poučna sta, ker jasno poimenujeta meje lastnih zaščitnih ukrepov.
Vercel je po lastnem biltenu pred objavo aktiviral zaščitna pravila v svojem spletnem požarnem zidu (WAF), filtru za spletne zahteve. Veljajo samodejno za funkcije PHP na Vercelu in za zahteve, ki jih Vercel posreduje zunanjim strežnikom PHP. Hkrati Vercel zahteva, da se izvajalno okolje PHP takoj posodobi na odpravljeno različico. Namestitve vsebnikov je treba znova zgraditi s posodobljeno osnovno sliko PHP in uvesti. Zahtev, ki Vercel zaobidejo in gredo neposredno na zunanji strežnik PHP, WAF ne pokriva.
Coolify, platforma, ki jo je mogoče upravljati samostojno, je bil po lastnem obvestilu sam prizadet: vse veje različice 4. Kot prva odpravljena stanja Coolify navaja 4.0.1, 4.1.3, 4.2.1, 4.3.24 in 4.4.7 ter priporoča 4.4.7. Pomemben je dodatek: posodobitev Coolify ne posodobi aplikacij PHP, ki jih prek njega upravljate. Njihova izvajalna okolja ali slike morate posodobiti ločeno ter jih znova zgraditi ali uvesti. To po Coolifyju velja tudi za stranke Coolify Cloud in tudi za Cloudflare, ker pravila Cloudflare preverjajo samo promet, ki teče prek Cloudflare.
Kaj pravila Cloudflare zmorejo, umešča prispevek Zaščitna pravila Cloudflare proti PHP2Shell.
Kako preverite izvajalno okolje, ki streže
Naslednji koraki delujejo neodvisno od ponudnika. Ciljajo na dokaz, ne na občutek.
- Naštejte vsa okolja: produkcija, staging, predogledne namestitve in storitve v ozadju, kot so delavci čakalnih vrst. Vsako okolje ima lahko drugo izvajalno okolje.
- Preberite različico izvajalnega okolja za vsako okolje: v konzoli ponudnika, v dnevniku gradnje ali v konfiguracijski datoteki projekta.
- Preverite datum zadnje namestitve: če je pred 21. 10. 2026, z veliko verjetnostjo še teče staro izvajalno okolje, razen če ponudnik izrecno ne potrdi drugače.
- Poglejte v tekoči primerek: če platforma ponuja konzolo, naslednji ukaz pokaže različico primerka.
- Vključite zunanje strežnike PHP: strežniki, na katere platforma posreduje zahteve, potrebujejo lastno posodobitev in ne smejo biti neposredno dosegljivi z interneta.
# V konzoli tekočega primerka (če jo ponudnik ponuja)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
Pričakovane so 8.5.12, 8.4.27, 8.3.36 ali 8.2.35 ali backport, ki ga potrdi ponudnik. Upoštevajte, da ukazna vrstica primerka ne uporablja vedno istega izvajalnega okolja kot spletni proces. Za preverjanje ne ustvarjajte javno dosegljive datoteke phpinfo. Kako pravilno razumete številko različice in stanje backportov, opisuje Preverjanje različice PHP in stanja popravkov.
Nova namestitev ne odstrani škodljive programske opreme, ki je prej prišla v trajne shrambe, kot so nosilci za nalaganje ali podatkovna baza. Ta področja preverite posebej.
Odgovornost zapišite
PHP2Shell kaže, kako nejasna je pogosto meja med platformo in stranko. Za vsako aplikacijo določite, kdo zagotavlja izvajalno okolje, kdo ob varnostnih obvestilih gradi znova in kako ponudnik napoveduje popravke. K temu sodi tudi, kdo ima dostop do konzole platforme, kadar je nujno, in kdo lahko zunaj delovnega časa sproži novo gradnjo.
Za lastno dokumentacijo zadošča kratka tabela za vsako aplikacijo: platforma, model delovanja, veja PHP, datum zadnje gradnje, odgovorna oseba. Kdor ima ta seznam ob naslednjem obvestilu pri roki, prihrani dneve, ki so jih mnoge ekipe po 21. oktobru porabile za iskanje. Pri aplikacijah v vsebnikih sodi zraven tudi, kdo vzdržuje osnovno sliko; ozadje pojasnjuje PHP v vsebnikih.
Za upravljane strežnike brez značaja PaaS veljajo podobna vprašanja, ki smo jih povzeli pod Upravljani strežnik: razjasnitev odgovornosti.
Kako PHP SOS pomaga konkretno?
- Razvrstitev: Vsako vašo aplikacijo uvrstimo v model delovanja in razjasnimo, kdo zagotavlja izvajalno okolje PHP.
- Dokaz: Preverimo izvajalno okolje, datum gradnje in namestitev za vsako okolje ter rezultat dokumentiramo.
- Nova gradnja in uvedba: Prek storitve popravljanja PHP posodobimo slike in gradnje ter jih nadzorovano uvedemo.
- Zapiranje vrzeli: Preverimo, ali so zunanji strežniki PHP neposredno dosegljivi, in omejimo dostop.
Pogosta vprašanja
Ali moj ponudnik PaaS PHP popravlja samodejno?
To je odvisno od modela. Če izvajalno okolje upravlja ponudnik, ga posodablja, pogosto pa šele za nove namestitve (deployments). Če slike ali gradnje izdelujete sami, morate graditi znova in znova uvesti. Stanje za svojo aplikacijo si dajte potrditi.
Ali WAF mojega ponudnika platforme zadošča proti PHP2Shell?
Ne. Vercel in Coolify izrecno pišeta, da zaščitna pravila ne nadomestijo posodobitve izvajalnega okolja PHP. Poleg tega delujejo samo na promet, ki teče prek platforme.
Ali moram po popravku znova uvesti aplikacijo?
Pogosto da. Vercel za namestitve vsebnikov navaja ponovno gradnjo s posodobljeno osnovno sliko PHP in novo namestitev. Pri platformah, ki temeljijo na gradnji, se izvajalno okolje ob gradnji zaklene; popravek prevzame šele nova gradnja.
Uporabljam Coolify. Ali zadošča posodobitev Coolify?
Ne. Po obvestilu Coolify posodobitev posodobi samo Coolify sam. Izvajalna okolja PHP ali slike vsebnikov vaših aplikacij morate posodobiti ločeno in jih znova zgraditi oziroma znova uvesti.