Lühidalt: Kes haldab root-serverit või vServerit ise, peab selle pärast PHP2Shelli ka ise turvama: tooma PHP paketid parandatud seisu, käivitama kõik PHP protsessid uuesti ja kontrollima tulemust. Andmekeskuse operaator hoolitseb reeglina ainult riistvara, virtualiseerimise ja võrgu eest. Seejärel tasub server püsivalt karastada.
Teie vastutus oma serveri eest
Haldamata root-serveri või vServeri puhul rendite arvutusvõimsust, mitte hooldust. Operatsioonisüsteem, veebiserver, PHP, andmebaas, tulemüür, varukoopiad ja seire on teie käes. Juhtkonna ja omanike jaoks tähendab see: kui keegi majas või teenusepakkuja juures pole neid ülesandeid selgesõnaliselt üle võtnud, ei tee neid keegi.
PHP2Shell teeb selle nähtavaks. Kaks turvaauku CVE-2026-109618 ja CVE-2026-109619 asuvad PHP-s endas ning võimaldavad koodi käivitamist ilma sisselogimata. PHP projekt avaldas 21.10.2026 versioonid 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. BSI soovitab kohest uuendust ja, kui see ei ole võimalik, veebiserveri ajutist võrgust lahtiühendamist.
vServeri turvamine: kontrollige olemasolevat ja paketi seisu
Hankige kõigepealt ülevaade, millised PHP versioonid on paigaldatud ja millisest allikast need pärinevad. Paljud serverid kasutavad lisaks distributsiooni pakettidele täiendavaid paketiallikaid. Järgmised käsud ainult loevad. Paketinimed on näited.
# Debian/Ubuntu: paigaldatud PHP paketid ja nende päritolu
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm
# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'
# Millised PHP binaarid üldse olemas on?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
Üksnes versiooninumbrist ei piisa. Distributsioonid tarnivad turvaparandusi sageli backportina, kuvatav number jääb siis vanemaks. Otsustav on paketi muudatuslogi.
# Debian/Ubuntu (paketi nimi on näide)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'
# RHEL-i perekond (paketi nimi on näide)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
Põhjaliku juhendi leiate lehelt PHP versiooni ja paigatud seisu kontroll.
Paigaldage uuendus ja uuendage kõik protsessid
Paigaldage uuendused paketihalduse kaudu ja käivitage seejärel uuesti iga teenus, mis PHP-d laadib. Need on olenevalt ülesehitusest PHP-FPM, Apache koos mod_php-ga, LiteSpeed või rakendusserver. Uutest failidest kettal ei piisa, kuni mälus töötavad vanad protsessid.
# PHP-d kasutavad teenused üles leida
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'
# Näidata protsesse koos käivitusajaga
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep
# Debian/Ubuntu: tuvastada aegunud teekidega programmid (kui paigaldatud)
needrestart -r l
Iga oluline protsess peaks olema pärast uuendust käivitatud. Abiks on Debiani süsteemides tööriist needrestart, mis näitab aegunud teekidega teenuseid. Taaskäivituse üksikasjad kirjeldab leht PHP-FPM-i ja kõigi tööprotsesside taaskäivitus.
Paik ei eemalda pahavara, mis toodi sisse enne uuendust. Säilitage veebiserveri logid alates 20.10.2026 ja kontrollige serverit jälgede suhtes, enne kui peate seda puhtaks.
Esimeseks jälgede otsinguks sobivad mõned kontrollid, mis midagi ei muuda. Otsige PHP faile, mis on veebikataloogides alates 17.10.2026 uuesti loodud või muudetud, tundmatuid kirjeid kõigi kasutajate crontab'ides, uusi süsteemikasutajaid ja SSH-võtmeid ning veebiserveri kasutaja protsesse, millel on väljuvaid ühendusi.
# Alates 17.10.2026 muudetud PHP failid (tee on näide)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
# Võrguühendused koos neid kasutava protsessiga
ss -tupn
Ükski neist kontrollidest ei tõesta üksi sissemurdmist ja tühi tulemus ei tõesta vastupidist. Need näitavad aga, kas on vaja põhjalikumat uurimist. Töötage logide koopiatega ja ärge muutke kahtlasi faile, kuni seis on kindlustatud. Leidude korral on turvaline tee korraldatud uurimine. Ärge sel juhul serverit lihtsalt välja lülitage ega paigaldage seda kohe uuesti, sest nii lähevad kaotsi jäljed, mis on olulised teavitamiskohustuste hindamiseks ja võimalikuks avalduseks.
Karastage server püsivalt
Pärast ägedat paikamist järgneb põhikaitse. See ei takista iga turvaauku, kuid piirab kahju ja lühendab reageerimisaega järgmisel korral. Tõestatud on järgmised punktid:
- Ligipääsud: SSH ainult võtmega, ei otsest root-sisselogimist, haldusliidesed kättesaadavad ainult tuntud võrkudest.
- Tulemüür: avage ainult need pordid, mida tõesti vajatakse, piirake veebiserveri väljuvaid ühendusi.
- PHP seadistus: keelake ohtlikud funktsioonid,
open_basediriga veebisaidi jaoks, eraldi poolid ja kasutajad iga rakenduse jaoks. - Failiõigused: veebiserver ei tohi programmikoodi kirjutada, üleslaadimiskataloogid ei käivita PHP-d.
- Uuendused: paigaldage turvauuendused automaatselt, planeerige taaskäivitus ja kontroll kindlalt ette.
- Varukoopiad: varukoopiad 3-2-1 reegli järgi, vähemalt üks koopia väljaspool serverit ja muutmise eest kaitstud.
- Protokollid: koguge logid keskselt ja säilitage neid piisavalt kaua.
Kuidas näeb välja töökindel varukoopia, kirjeldab leht Varukoopiad 3-2-1 reegli järgi. Ettevõtete raamistikuna sobib BSI IT-baaskaitse (IT-Grundschutz).
Millal on hallatav server parem valik
Oma server tasub end ära, kui keegi võtab hoolduse usaldusväärselt enda peale: uuenduste jälgimine, PHP2Shelli-sarnaste olukordade hindamine, öösel reageerimise võimalus. Kui seda võimekust ei ole, on mõistlik kas hallatav server (Managed Server) või kindel hooldusleping. Mõlemal juhul on oluline panna vastutusalad kirja. Lisateavet leiate lehelt Hallatav server: vastutuse selgitamine.
Kuidas PHP SOS konkreetselt aitab?
- Kaardistame teie serveri kõik PHP paigaldused, paketiallikad ja teenused ning hindame tegelikku paikamise seisu.
- Paigaldame uuendused, käivitame kõik protsessid uuesti ja dokumenteerime tulemuse.
- Kontrollime serverit kompromiteerimise jälgede suhtes ja kindlustame logid hilisemaks analüüsiks.
- Oma serveri karastamise raames seadistame korralikult ligipääsud, tulemüüri, PHP poolid ja õigused.
- Soovi korral võtame jooksva hoolduse üle turvahoolduslepinguga.
Korduma kippuvad küsimused
Kas minu andmekeskus paikab vServeri automaatselt?
Haldamata root-serverite ja vServerite puhul reeglina mitte. Pakkuja annab riistvara või virtualiseerimise ja võrgu, operatsioonisüsteemi ja kõiki sellel töötavaid teenuseid haldate ise. Kahtluse korral kontrollige oma lepingut.
Kas automaatsed turvauuendused piisavad?
Need aitavad, kuid ei asenda kontrolli. Automaatsed uuendused ei käivita töötavaid PHP protsesse alati uuesti ja kolmandate allikate pakette need sageli ei kata. Kontrollige pärast iga turvauuendust paketi seisu ja protsesside käivitusaegu.
Kuidas ma saan teada, kas minu pakett sisaldab backporti?
Paketi muudatuslogist ja oma distributsiooni turvateadetest. Kui seal on CVE-number, on parandus sees, isegi kui versiooninumber paistab vanem. Kui kirje puudub, selgitage seis välja, enne kui peate serveri paigatuks.
Mida teha, kui minu PHP versiooni jaoks paika ei tule?
PHP 8.1 ja vanemad ei saa enam ametlikke uuendusi. Seadke php.net-i ajutised meetmed, planeerige kiiresti üleminek toetatud versioonile ja võtke server BSI soovituse kohaselt vajaduse korral ajutiselt võrgust lahti.