Lyhyesti: Joka hallinnoi root-palvelinta tai vServeriä itse, joutuu myös suojaamaan sen PHP2Shellin jälkeen itse: PHP-paketit korjattuun tilaan, kaikki PHP-prosessit uudelleenkäynnistykseen ja lopputulos tarkistukseen. Palvelinkeskuksen ylläpitäjä huolehtii yleensä vain laitteistosta, virtualisoinnista ja verkosta. Sen jälkeen palvelin kannattaa koventaa pysyvästi.
Vastuusi omasta palvelimesta
Hallitsemattoman root-palvelimen tai vServerin kanssa vuokraat laskentatehoa, et ylläpitoa. Käyttöjärjestelmä, verkkopalvelin, PHP, tietokanta, palomuuri, varmuuskopiot ja valvonta ovat sinun käsissäsi. Johdolle ja omistajille tämä tarkoittaa: jos kukaan talossa tai palveluntarjoajalla ei ole nimenomaisesti ottanut näitä tehtäviä vastuulleen, kukaan ei tee niitä.
PHP2Shell tekee tämän näkyväksi. Haavoittuvuudet CVE-2026-109618 ja CVE-2026-109619 ovat itse PHP:ssä ja sallivat koodin suorittamisen ilman kirjautumista. PHP-projekti julkaisi 21.10.2026 versiot 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. BSI (Saksan liittovaltion tietoturvavirasto) suosittelee välitöntä päivitystä ja, jos se ei ole mahdollista, verkkopalvelimen ottamista tilapäisesti pois verkosta.
vServerin suojaus: tarkista kanta ja pakettitila
Hanki ensin yleiskuva siitä, mitkä PHP-versiot on asennettu ja mistä lähteestä ne tulevat. Monet palvelimet käyttävät jakelun pakettien rinnalla ylimääräisiä pakettilähteitä. Seuraavat komennot vain lukevat. Pakettien nimet ovat esimerkkejä.
# Debian/Ubuntu: asennetut PHP-paketit ja niiden alkuperä
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm
# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'
# Mitä PHP-binäärejä ylipäätään on?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
Pelkkä versionumero ei riitä. Jakelut toimittavat tietoturvakorjaukset usein backport-korjauksina, jolloin näytetty numero pysyy vanhempana. Ratkaisevaa on paketin muutosloki.
# Debian/Ubuntu (paketin nimi esimerkkinä)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'
# RHEL-perhe (paketin nimi esimerkkinä)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
Yksityiskohtainen ohje on sivulla PHP-version ja korjaustilan tarkistus.
Asenna päivitys ja uudista kaikki prosessit
Asenna päivitykset paketinhallinnan kautta ja käynnistä sen jälkeen uudelleen jokainen palvelu, joka lataa PHP:n. Rakenteesta riippuen näitä ovat PHP-FPM, Apache mod_php:n kanssa, LiteSpeed tai sovelluspalvelin. Uudet tiedostot levyllä eivät riitä, niin kauan kuin vanhat prosessit pyörivät muistissa.
# Etsi PHP:tä käyttävät palvelut
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'
# Näytä prosessit käynnistysaikoineen
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep
# Debian/Ubuntu: tunnista ohjelmat, joilla on vanhentuneita kirjastoja (jos asennettu)
needrestart -r l
Jokaisen olennaisen prosessin pitäisi olla käynnistetty päivityksen jälkeen. Hyödyllinen on Debian-järjestelmissä needrestart-työkalu, joka näyttää palvelut, joilla on vanhentuneita kirjastoja. Uudelleenkäynnistyksen yksityiskohdat kuvaa sivu PHP-FPM ja kaikki worker-prosessit uudelleen.
Korjaus ei poista haittaohjelmaa, joka asennettiin ennen päivitystä. Säilytä verkkopalvelimen lokit 20.10.2026 alkaen ja tarkista palvelimen jäljet, ennen kuin luokittelet sen puhtaaksi.
Ensimmäiseen jälkien etsintään sopivat muutamat tarkistukset, jotka eivät muuta mitään. Etsi PHP-tiedostoja, jotka on luotu tai muutettu verkkohakemistoissa 17.10.2026 jälkeen, tuntemattomia merkintöjä kaikkien käyttäjien crontabeissa, uusia järjestelmäkäyttäjiä ja SSH-avaimia sekä verkkopalvelimen käyttäjän prosesseja, jotka pitävät yllä lähteviä yhteyksiä.
# 17.10.2026 jälkeen muutetut PHP-tiedostot (polku esimerkkinä)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
# Verkkoyhteydet ja niihin kuuluva prosessi
ss -tupn
Mikään näistä tarkistuksista ei yksin todista murtoa, eikä tyhjä tulos todista päinvastaista. Ne kuitenkin osoittavat, tarvitaanko syvällisempää tutkintaa. Työskentele lokien kopioilla äläkä muuta epäilyttäviä tiedostoja, ennen kuin tila on turvattu. Löydösten tapauksessa hallittu tutkinta on turvallinen tie. Älä tässä tapauksessa yksinkertaisesti sammuta palvelinta äläkä pystytä sitä heti uudelleen, sillä silloin katoaa jälkiä, jotka ovat tärkeitä ilmoitusvelvollisuuksien arvioinnille ja mahdolliselle rikosilmoitukselle.
Palvelimen pysyvä koventaminen
Akuutin korjauksen jälkeen tulee perussuojaus. Se ei estä jokaista haavoittuvuutta, mutta rajoittaa vahinkoa ja lyhentää reagointiaikaa seuraavalla kerralla. Seuraavat kohdat ovat osoittautuneet toimiviksi:
- Pääsyt: SSH vain avaimella, ei suoraa root-kirjautumista, hallintakäyttöliittymät tavoitettavissa vain tunnetuista verkoista.
- Palomuuri: avaa vain portit, joita todella tarvitaan, rajoita verkkopalvelimen lähteviä yhteyksiä.
- PHP-konfiguraatio: poista vaaralliset funktiot käytöstä,
open_basedirjokaiselle verkkosivustolle, omat poolit ja käyttäjät sovellusta kohden. - Tiedosto-oikeudet: verkkopalvelin ei saa kirjoittaa ohjelmakoodiin, latauskansiot eivät suorita PHP:tä.
- Päivitykset: asenna tietoturvapäivitykset automaattisesti, suunnittele uudelleenkäynnistys ja tarkistus kiinteästi.
- Varmuuskopiot: varmuuskopiot 3-2-1-säännön mukaan, vähintään yksi kopio palvelimen ulkopuolella ja suojattuna muutoksilta.
- Lokit: kerää lokit keskitetysti ja säilytä ne riittävän pitkään.
Millainen kestävä varmuuskopio on, kuvaa sivu Varmuuskopiot 3-2-1-säännön mukaan. Yrityksille sopiva kehys on BSI:n IT-Grundschutz.
Milloin hallinnoitu palvelin on parempi valinta
Oma palvelin kannattaa, jos joku hoitaa ylläpidon luotettavasti: seuraa päivityksiä, arvioi PHP2Shellin kaltaisia tilanteita ja pystyy reagoimaan yöllä. Jos tätä kapasiteettia ei ole, järkevää on joko hallinnoitu palvelin tai kiinteä huoltosopimus. Tärkeintä on molemmissa tapauksissa kirjata vastuut kirjallisesti. Lisää aiheesta sivulla Hallinnoitu palvelin: vastuun selvittäminen.
Miten PHP SOS auttaa konkreettisesti?
- Kartoitamme palvelimenne kaikki PHP-asennukset, pakettilähteet ja palvelut ja arvioimme todellisen korjaustilan.
- Asennamme päivitykset, käynnistämme kaikki prosessit uudelleen ja dokumentoimme tuloksen.
- Tarkistamme palvelimelta murron jäljet ja turvaamme lokit myöhempää analyysia varten.
- Palvelimen koventamisemme puitteissa asetamme pääsyt, palomuurin, PHP-poolit ja oikeudet kuntoon.
- Halutessanne otamme jatkuvan ylläpidon tietoturvahuoltosopimuksella.
Usein kysytyt kysymykset
Korjaako palvelinkeskus vServerini automaattisesti?
Hallitsemattomien root-palvelinten ja vServerien kohdalla yleensä ei. Palveluntarjoaja tarjoaa laitteiston tai virtualisoinnin ja verkon, mutta käyttöjärjestelmää ja kaikkia sen palveluita hallinnoit itse. Tarkista epäselvässä tapauksessa sopimuksesi.
Riittävätkö automaattiset tietoturvapäivitykset?
Ne auttavat, mutta eivät korvaa tarkistusta. Automaattiset päivitykset eivät aina käynnistä käynnissä olevia PHP-prosesseja uudelleen, eivätkä ne usein kata ulkopuolisista lähteistä tulevia paketteja. Tarkista jokaisen tietoturvapäivityksen jälkeen pakettitila ja prosessien käynnistysajat.
Mistä tiedän, sisältääkö pakettini backport-korjauksen?
Paketin muutoslokista ja jakelusi tietoturvatiedotteista. Jos CVE-numero on siellä, korjaus on mukana, vaikka versionumero näyttäisi vanhemmalta. Jos merkintä puuttuu, selvitä tila ennen kuin luokittelet palvelimen korjatuksi.
Mitä teen, jos PHP-versiolleni ei tule korjausta?
PHP 8.1 ja vanhemmat eivät saa enää virallisia päivityksiä. Aseta php.net:n mukaiset väliaikaiset toimenpiteet, suunnittele nopeasti siirtyminen tuettuun versioon ja ota palvelin tarvittaessa tilapäisesti pois verkosta BSI:n suosituksen mukaisesti.