Samostojna zaščita root strežnika in strežnika vServer

Na kratko: Kdor root strežnik ali strežnik vServer upravlja sam, ga mora po PHP2Shell tudi sam zaščititi: pakete PHP dvigniti na odpravljeno stanje, znova zagnati vse procese PHP in preveriti rezultat. Upravljavec podatkovnega centra praviloma skrbi samo za strojno opremo, virtualizacijo in omrežje. Nato se splača strežnik trajno utrditi.

Vaša odgovornost pri lastnem strežniku

Pri neupravljanem root strežniku ali strežniku vServer najamete računsko moč, ne oskrbe. Operacijski sistem, spletni strežnik, PHP, zbirka podatkov, požarni zid, varnostne kopije in nadzor so v vaših rokah. Za vodstvo in lastnike to pomeni: če teh nalog nihče v podjetju ali pri izvajalcu izrecno ni prevzel, jih ne opravi nihče.

PHP2Shell to naredi vidno. Obe ranljivosti, CVE-2026-109618 in CVE-2026-109619, sta v samem PHP in omogočata izvajanje kode brez prijave. Projekt PHP je 21. 10. 2026 objavil različice 8.5.12, 8.4.27, 8.3.36 in 8.2.35. BSI priporoča takojšnjo posodobitev in, če to ni mogoče, začasen odklop spletnega strežnika z omrežja.

Zaščita strežnika vServer: preverite zalogo in stanje paketov

Najprej si ustvarite pregled, katere različice PHP so nameščene in iz katerega vira izvirajo. Mnogi strežniki poleg paketov distribucije uporabljajo dodatne vire paketov. Spodnji ukazi samo berejo. Imena paketov so primeri.

# Debian/Ubuntu: nameščeni paketi PHP in njihov izvor
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm

# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'

# Katere binarne datoteke PHP sploh obstajajo?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null

Številka različice sama ne zadošča. Distribucije varnostne popravke pogosto dostavijo kot backport, prikazana številka pa ostane starejša. Odloča dnevnik sprememb paketa.

# Debian/Ubuntu (ime paketa kot primer)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'

# Družina RHEL (ime paketa kot primer)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'

Podrobna navodila so na strani Preverjanje različice PHP in stanja popravkov.

Namestite posodobitev in obnovite vse procese

Posodobitve namestite prek upravitelja paketov in nato znova zaženite vsako storitev, ki nalaga PHP. Glede na zgradbo so to PHP-FPM, Apache z mod_php, LiteSpeed ali aplikacijski strežnik. Nove datoteke na disku ne zadoščajo, dokler v pomnilniku tečejo stari procesi.

# Poiščite storitve s PHP
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'

# Prikažite procese s časom zagona
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep

# Debian/Ubuntu: prepoznajte programe s zastarelimi knjižnicami (če je nameščeno)
needrestart -r l

Vsak pomemben proces bi moral biti zagnan po posodobitvi. Na sistemih Debian pomaga orodje needrestart, ki prikaže storitve z zastarelimi knjižnicami. Podrobnosti ponovnega zagona opisuje stran Ponovni zagon PHP-FPM in vseh delavcev.

Za prvo iskanje sledi je primernih nekaj preverjanj, ki ničesar ne spreminjajo. Poiščite datoteke PHP, ki so bile v spletnih imenikih ustvarjene ali spremenjene od 17. 10. 2026, neznane vnose v crontab vseh uporabnikov, nove sistemske uporabnike in ključe SSH ter procese uporabnika spletnega strežnika, ki imajo odprte odhodne povezave.

# Datoteke PHP, spremenjene od 17. 10. 2026 (pot kot primer)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls

# Omrežne povezave s pripadajočim procesom
ss -tupn

Nobeno od teh preverjanj samo zase ne dokazuje vloma, prazen rezultat pa ne dokazuje nasprotnega. Pokažejo pa, ali je potrebna globlja preiskava. Delajte na kopijah dnevnikov in sumljivih datotek ne spreminjajte, dokler stanje ni zavarovano. Ob najdbah je varna pot urejena preiskava. Strežnika v tem primeru ne ugašajte kar tako in ga ne postavljajte takoj znova, saj bi izgubili sledi, ki so pomembne za presojo obveznosti prijave in za morebitno kazensko ovadbo.

Strežnik trajno utrdite

Po akutnem popravku sledi osnovna zaščita. Ne prepreči vsake ranljivosti, vendar omeji škodo in skrajša odzivni čas ob naslednjem primeru. Obnesle so se te točke:

• Dostopi: SSH samo s ključem, brez neposredne prijave root, upravljalni vmesniki dosegljivi samo iz znanih omrežij.
• Požarni zid: odprite samo vrata, ki so res potrebna, omejite odhodne povezave spletnega strežnika.
• Konfiguracija PHP: onemogočite nevarne funkcije, open_basedir za vsako spletno stran, lastni pooli in uporabniki za vsako aplikacijo.
• Pravice za datoteke: spletni strežnik ne sme pisati v programsko kodo, imeniki za nalaganje ne izvajajo PHP.
• Posodobitve: varnostne posodobitve nameščajte samodejno, ponovni zagon in kontrolo trdno načrtujte.
• Varnostne kopije: kopije po pravilu 3-2-1, vsaj ena kopija zunaj strežnika in zaščitena pred spremembami.
• Dnevniki: dnevnike zbirajte osrednje in jih hranite dovolj dolgo.

Kako je videti zanesljiva varnostna kopija, opisuje stran Varnostne kopije po pravilu 3-2-1. Kot okvir za podjetja je primerna osnovna zaščita IT (IT-Grundschutz) urada BSI.

Kdaj je upravljani strežnik boljša izbira

Lasten strežnik se splača, če nekdo vzdrževanje zanesljivo prevzame: spremljanje posodobitev, ocenjevanje položajev, kot je PHP2Shell, možnost odziva ponoči. Če te zmogljivosti ni, je smiseln bodisi upravljani strežnik bodisi stalna pogodba o vzdrževanju. V obeh primerih je pomembno, da odgovornosti zapišete. Več o tem na strani Upravljani strežnik: razjasnitev odgovornosti.

Kako PHP SOS konkretno pomaga?

• Popišemo vse namestitve PHP, vire paketov in storitve vašega strežnika ter ocenimo dejansko stanje popravkov.
• Namestimo posodobitve, znova zaženemo vse procese in rezultat dokumentiramo.
• Strežnik preverimo glede sledi kompromitacije in zavarujemo dnevnike za poznejšo analizo.
• V okviru naše utrditve strežnika čisto postavimo dostope, požarni zid, poole PHP in pravice.
• Na željo prevzamemo tekoče vzdrževanje prek varnostne pogodbe o vzdrževanju.

Pogosta vprašanja

Viri

• php.net: varnostna obvestila
• PHP 8 ChangeLog
• php.net: podprte različice
• BSI IT-Grundschutz (osnovna zaščita IT)