Vlastné zabezpečenie root servera a vServeru

Stručne: Kto spravuje root server alebo vServer sám, musí ho po PHP2Shell aj sám zabezpečiť: dostať balíky PHP na opravený stav, reštartovať všetky procesy PHP a skontrolovať výsledok. Prevádzkovateľ dátového centra sa spravidla stará iba o hardvér, virtualizáciu a sieť. Potom sa oplatí server trvalo spevniť.

Vaša zodpovednosť pri vlastnom serveri

Pri nespravovanom root serveri alebo vServeri si prenajímate výpočtový výkon, nie starostlivosť. Operačný systém, webový server, PHP, databáza, firewall, zálohy a monitorovanie sú vo vašich rukách. Pre vedenie a majiteľov to znamená: ak tieto úlohy výslovne neprevzal nikto vo firme ani externý dodávateľ, nevykoná ich nikto.

PHP2Shell to robí viditeľným. Obe zraniteľnosti CVE-2026-109618 a CVE-2026-109619 sú v samotnom PHP a umožňujú spustenie kódu bez prihlásenia. Projekt PHP zverejnil 21. 10. 2026 verzie 8.5.12, 8.4.27, 8.3.36 a 8.2.35. BSI (nemecký Spolkový úrad pre informačnú bezpečnosť) odporúča okamžitú aktualizáciu a, ak to nejde, webový server dočasne odpojiť od siete.

Zabezpečenie vServeru: skontrolujte stav a balíky

Najprv si urobte prehľad, aké verzie PHP sú nainštalované a z akého zdroja pochádzajú. Mnohé servery používajú popri balíkoch distribúcie ďalšie zdroje balíkov. Nasledujúce príkazy iba čítajú. Názvy balíkov sú príklady.

# Debian/Ubuntu: nainštalované balíky PHP a ich pôvod
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm

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

# Aké binárky PHP vôbec existujú?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null

Samotné číslo verzie nestačí. Distribúcie dodávajú bezpečnostné opravy často ako backport, zobrazené číslo potom zostáva staršie. Rozhoduje changelog balíka.

# Debian/Ubuntu (názov balíka ako príklad)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'

# Rodina RHEL (názov balíka ako príklad)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'

Podrobný návod nájdete na stránke Kontrola verzie PHP a stavu záplat.

Nasaďte aktualizáciu a obnovte všetky procesy

Aktualizácie nasaďte cez správcu balíkov a potom reštartujte každú službu, ktorá načítava PHP. Podľa architektúry je to PHP-FPM, Apache s mod_php, LiteSpeed alebo aplikačný server. Nové súbory na disku nestačia, kým v pamäti bežia staré procesy.

# Nájdenie služieb s PHP
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'

# Zobrazenie procesov s časom spustenia
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep

# Debian/Ubuntu: rozpoznanie programov so zastaranými knižnicami (ak je nainštalované)
needrestart -r l

Každý relevantný proces by mal byť spustený po aktualizácii. Užitočný je nástroj needrestart v systémoch Debian, ktorý zobrazí služby so zastaranými knižnicami. Podrobnosti o reštarte opisuje stránka Reštart PHP-FPM a všetkých workerov.

Na prvé hľadanie stôp sa hodí niekoľko kontrol, ktoré nič nemenia. Hľadajte súbory PHP, ktoré boli od 17. 10. 2026 v adresároch webu nanovo vytvorené alebo zmenené, neznáme záznamy v crontabs všetkých používateľov, nových systémových používateľov a kľúče SSH, ako aj procesy používateľa webového servera, ktoré držia odchádzajúce spojenia.

# Súbory PHP zmenené od 17. 10. 2026 (cesta ako príklad)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls

# Sieťové spojenia s príslušným procesom
ss -tupn

Žiadna z týchto kontrol sama osebe nepreukazuje vlámanie a prázdny výsledok nepreukazuje opak. Ukážu však, či je potrebné hlbšie vyšetrenie. Pracujte s kópiami logov a podozrivé súbory nemeňte, kým nie je stav zabezpečený. Pri nálezoch je bezpečnou cestou usporiadané vyšetrenie. Server v takom prípade jednoducho nevypínajte a ihneď ho neinštalujte nanovo, pretože tým sa strácajú stopy, ktoré sú dôležité pre posúdenie oznamovacích povinností a pre prípadné trestné oznámenie.

Server trvalo spevnite

Po akútnej záplate nasleduje základné zabezpečenie. Nezabráni každej zraniteľnosti, ale obmedzí škodu a skráti čas reakcie nabudúce. Osvedčili sa tieto body:

• Prístupy: SSH iba s kľúčom, žiadne priame prihlásenie root, správcovské rozhrania dostupné len zo známych sietí.
• Firewall: otvorte iba porty, ktoré sa skutočne potrebujú, odchádzajúce spojenia webového servera obmedzte.
• Konfigurácia PHP: vypnite nebezpečné funkcie, open_basedir pre každý web, samostatné pooly a používatelia pre každú aplikáciu.
• Práva k súborom: webový server nesmie zapisovať do programového kódu, adresáre na nahrávanie nespúšťajú PHP.
• Aktualizácie: bezpečnostné aktualizácie nasadzujte automaticky, reštart a kontrolu pevne naplánujte.
• Zálohy: zálohovanie podľa pravidla 3-2-1, aspoň jedna kópia mimo servera a chránená pred zmenou.
• Protokoly: logy zbierajte centrálne a uchovávajte dostatočne dlho.

Ako vyzerá spoľahlivá záloha, opisuje stránka Zálohy podľa pravidla 3-2-1. Ako rámec pre firmy sa hodí IT-Grundschutz od BSI.

Kedy je managed server lepšou voľbou

Vlastný server sa oplatí, ak údržbu spoľahlivo prevezme niekto: sledovať aktualizácie, posudzovať situácie ako PHP2Shell, vedieť reagovať aj v noci. Ak táto kapacita chýba, zmysel má buď managed server, alebo pevná zmluva o údržbe. Dôležité je v oboch prípadoch zachytiť zodpovednosti písomne. Viac nájdete na stránke Managed server: vyjasnenie zodpovednosti.

Ako konkrétne pomáha PHP SOS?

• Zaznamenáme všetky inštalácie PHP, zdroje balíkov a služby vášho servera a posúdime skutočný stav záplat.
• Nasadíme aktualizácie, reštartujeme všetky procesy a výsledok zdokumentujeme.
• Server skontrolujeme na stopy kompromitácie a zabezpečíme logy na neskoršie vyhodnotenie.
• V rámci nášho spevnenia servera (hardening) čisto nastavíme prístupy, firewall, pooly PHP a práva.
• Na požiadanie preberáme priebežnú starostlivosť cez zmluvu o bezpečnostnej údržbe.

Časté otázky

Zdroje

• php.net: bezpečnostné hlásenia
• PHP 8 ChangeLog
• php.net: podporované verzie
• BSI IT-Grundschutz