Trumpai: Kas pats valdo root serverį ar vServerį, po PHP2Shell turi jį ir pats apsaugoti: PHP paketus pakelti iki ištaisytos būsenos, iš naujo paleisti visus PHP procesus ir patikrinti rezultatą. Duomenų centro operatorius paprastai rūpinasi tik technine įranga, virtualizacija ir tinklu. Po to verta serverį nuolat sutvirtinti.
Jūsų atsakomybė už savo serverį
Nevaldomo root serverio ar vServerio atveju nuomojate skaičiavimo galią, o ne priežiūrą. Operacinė sistema, žiniatinklio serveris, PHP, duomenų bazė, ugniasienė, atsarginės kopijos ir stebėsena yra jūsų rankose. Vadovybei ir savininkams tai reiškia: jei niekas įmonėje ar pas paslaugų teikėją šių užduočių aiškiai nėra perėmęs, jų nevykdo niekas.
PHP2Shell tai išryškina. Abu pažeidžiamumai, CVE-2026-109618 ir CVE-2026-109619, yra pačiame PHP ir leidžia vykdyti kodą be prisijungimo. 2026-10-21 PHP projektas paskelbė versijas 8.5.12, 8.4.27, 8.3.36 ir 8.2.35. BSI (Vokietijos Federalinė informacijos saugumo tarnyba) rekomenduoja nedelsiant atnaujinti, o jei tai neįmanoma, laikinai atjungti žiniatinklio serverį nuo tinklo.
vServerio apsauga: patikrinkite esamą būklę ir paketų būseną
Pirmiausia susidarykite vaizdą, kokios PHP versijos įdiegtos ir iš kokio šaltinio. Daugelis serverių greta distribucijos paketų naudoja papildomus paketų šaltinius. Toliau pateiktos komandos tik skaito. Paketų pavadinimai yra pavyzdžiai.
# Debian/Ubuntu: įdiegti PHP paketai ir jų kilmė
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm
# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'
# Kokie apskritai yra PHP vykdomieji failai?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
Vien versijos numerio nepakanka. Distribucijos saugumo pataisymus dažnai pateikia kaip backport, o rodomas numeris tuomet lieka senesnis. Lemia paketo pakeitimų žurnalas.
# Debian/Ubuntu (paketo pavadinimas kaip pavyzdys)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'
# RHEL šeima (paketo pavadinimas kaip pavyzdys)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
Išsamią instrukciją rasite puslapyje PHP versijos ir pataisų būsenos patikra.
Įdiekite atnaujinimą ir atnaujinkite visus procesus
Atnaujinimus įdiekite per paketų tvarkyklę ir po to iš naujo paleiskite kiekvieną tarnybą, kuri įkelia PHP. Priklausomai nuo sąrankos tai PHP-FPM, Apache su mod_php, LiteSpeed arba programų serveris. Vien naujų failų diske nepakanka, kol atmintyje veikia seni procesai.
# Raskite tarnybas su PHP
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'
# Parodykite procesus su paleidimo laiku
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep
# Debian/Ubuntu: atpažinkite programas su pasenusiomis bibliotekomis (jei įdiegta)
needrestart -r l
Kiekvienas svarbus procesas turėtų būti paleistas po atnaujinimo. Debian sistemose naudingas įrankis needrestart, rodantis tarnybas su pasenusiomis bibliotekomis. Paleidimo iš naujo detales aprašo PHP-FPM ir visų darbinių procesų paleidimas iš naujo.
Pataisa nepašalina kenkėjiškos programinės įrangos, įterptos prieš atnaujinimą. Išsaugokite žiniatinklio serverio žurnalus nuo 2026-10-20 ir prieš priskirdami serverį prie švarių patikrinkite jį dėl pėdsakų.
Pirmajai pėdsakų paieškai tinka kelios patikros, kurios nieko nekeičia. Ieškokite PHP failų, kurie nuo 2026-10-17 sukurti ar pakeisti žiniatinklio kataloguose, nežinomų įrašų visų naudotojų crontab, naujų sistemos naudotojų ir SSH raktų bei žiniatinklio serverio naudotojo procesų, laikančių išeinančius ryšius.
# PHP failai, pakeisti nuo 2026-10-17 (kelias kaip pavyzdys)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
# Tinklo ryšiai su atitinkamu procesu
ss -tupn
Nė viena iš šių patikrų pati savaime neįrodo įsilaužimo, o tuščias rezultatas neįrodo priešingo. Tačiau jos parodo, ar reikia gilesnio tyrimo. Dirbkite su žurnalų kopijomis ir nekeiskite įtartinų failų, kol būsena neišsaugota. Radus ką nors, saugiausias kelias yra tvarkingas tyrimas. Tokiu atveju serverio nereikia tiesiog išjungti ir nedelsiant diegti iš naujo, nes taip prarandami pėdsakai, svarbūs vertinant pranešimo pareigas ir galimą pareiškimą policijai.
Nuolat sutvirtinkite serverį
Po ūmaus pataisymo seka bazinė apsauga. Ji neužkerta kelio kiekvienam pažeidžiamumui, bet riboja žalą ir sutrumpina reagavimo laiką kitą kartą. Pasiteisino šie punktai:
- Prieigos: SSH tik su raktu, jokio tiesioginio prisijungimo kaip root, valdymo sąsajos pasiekiamos tik iš žinomų tinklų.
- Ugniasienė: atidarykite tik tuos prievadus, kurių tikrai reikia, apribokite žiniatinklio serverio išeinančius ryšius.
- PHP konfigūracija: išjunkite pavojingas funkcijas,
open_basedirkiekvienai svetainei, atskiri baseinai (pool) ir naudotojai kiekvienai programai. - Failų teisės: žiniatinklio serveris negali rašyti į programos kodą, įkėlimų kataloguose PHP nevykdomas.
- Atnaujinimai: saugumo atnaujinimus diekite automatiškai, paleidimą iš naujo ir kontrolę numatykite iš anksto.
- Atsarginės kopijos: kopijos pagal 3-2-1 taisyklę, bent viena kopija ne serveryje ir apsaugota nuo pakeitimo.
- Žurnalai: žurnalus renkite centralizuotai ir saugokite pakankamai ilgai.
Kaip atrodo patikima atsarginė kopija, aprašyta puslapyje Atsarginės kopijos pagal 3-2-1 taisyklę. Įmonėms kaip pagrindas tinka BSI IT-Grundschutz.
Kada valdomas serveris yra geresnis pasirinkimas
Savas serveris apsimoka, kai kas nors patikimai perima priežiūrą: seka atnaujinimus, vertina tokias padėtis kaip PHP2Shell, gali reaguoti naktį. Jei tokių pajėgumų nėra, prasminga arba valdomo serverio (managed server) paslauga, arba nuolatinė priežiūros sutartis. Abiem atvejais svarbu raštu užfiksuoti atsakomybes. Daugiau apie tai puslapyje Valdomas serveris: išsiaiškinkite atsakomybę.
Kaip PHP SOS padeda konkrečiai?
- Surašome visus jūsų serverio PHP diegimus, paketų šaltinius ir tarnybas ir įvertiname tikrąją pataisų būseną.
- Įdiegiame atnaujinimus, paleidžiame iš naujo visus procesus ir dokumentuojame rezultatą.
- Tikriname serverį dėl kompromitavimo pėdsakų ir išsaugome žurnalus vėlesnei analizei.
- Pagal mūsų serverio sutvirtinimą tvarkingai sutvarkome prieigas, ugniasienę, PHP baseinus ir teises.
- Pageidaujant perimame nuolatinę priežiūrą pagal saugumo priežiūros sutartį.
Dažni klausimai
Ar mano duomenų centras vServerį pataiso automatiškai?
Nevaldomų root serverių ir vServerių atveju paprastai ne. Teikėjas suteikia techninę įrangą ar virtualizaciją ir tinklą, o operacinę sistemą ir visas joje veikiančias tarnybas valdote patys. Abejodami patikrinkite savo sutartį.
Ar pakanka automatinių saugumo atnaujinimų?
Jie padeda, bet kontrolės nepakeičia. Automatiniai atnaujinimai ne visada paleidžia iš naujo veikiančius PHP procesus ir dažnai neapima paketų iš trečiųjų šalių šaltinių. Po kiekvieno saugumo atnaujinimo patikrinkite paketų būseną ir procesų paleidimo laiką.
Kaip sužinoti, ar mano pakete yra backport?
Paketo pakeitimų žurnale ir jūsų distribucijos saugumo pranešimuose. Jei ten nurodytas CVE numeris, pataisa įtraukta, net jei versijos numeris atrodo senesnis. Jei įrašo nėra, išsiaiškinkite būseną, prieš priskirdami serverį prie pataisytų.
Ką daryti, jei mano PHP versijai pataisa nebus išleista?
PHP 8.1 ir senesnės versijos oficialių atnaujinimų nebegauna. Nustatykite pereinamąsias priemones pagal php.net, greitai suplanuokite perėjimą prie palaikomos versijos, o prireikus, pagal BSI rekomendaciją, laikinai atjunkite serverį nuo tinklo.