# Root szerver és vServer saját védelme

> vServer védelme a PHP2Shell után: PHP-csomagok ellenőrzése, backportok felismerése, az összes worker újraindítása, a root szerver tartós megerősítése adminoknak.

Forrás: https://phpsos.de/hu/server/root-server-vserver/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** Aki root szervert vagy vServert maga kezel, annak a PHP2Shell után maga kell megvédenie is: a PHP-csomagokat javított állapotra kell hozni, az összes PHP-folyamatot újra kell indítani, és ellenőrizni kell az eredményt. A számítóközpont üzemeltetője általában csak a hardverrel, a virtualizációval és a hálózattal foglalkozik. Ezután érdemes a szervert tartósan megerősíteni.

## Az Ön felelőssége a saját szervernél

Nem menedzselt root szervernél vagy vServernél számítási kapacitást bérel, nem gondozást. Az operációs rendszer, a webszerver, a PHP, az adatbázis, a tűzfal, a mentések és a felügyelet az Ön kezében van. Ügyvezetők és tulajdonosok számára ez azt jelenti: ha a cégen belül vagy egy szolgáltatónál senki nem vállalta át kifejezetten ezeket a feladatokat, akkor senki nem végzi el őket.

A PHP2Shell ezt láthatóvá teszi. A CVE-2026-109618 és a CVE-2026-109619 rés magában a PHP-ban van, és bejelentkezés nélküli kódfuttatást tesz lehetővé. A PHP-projekt 2026. október 21-én kiadta a 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verziót. A BSI (a német Szövetségi Információbiztonsági Hivatal) azonnali frissítést javasol, és ha az nem lehetséges, a webszerver ideiglenes leválasztását a hálózatról.

## vServer védelme: a készlet és a csomagállapot ellenőrzése

Először szerezzen áttekintést arról, mely PHP-verziók vannak telepítve, és honnan származnak. Sok szerver a disztribúció csomagjai mellett további csomagforrásokat is használ. A következő parancsok csak olvasnak. A csomagnevek példák.

```bash
# Debian/Ubuntu: a telepített PHP-csomagok és eredetük
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm

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

# Egyáltalán milyen PHP-binárisok vannak?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
```

A verziószám önmagában nem elég. A disztribúciók a biztonsági javításokat gyakran backportként szállítják, a megjelenített szám ilyenkor régebbi marad. A döntő a csomag változásnaplója.

```bash
# Debian/Ubuntu (a csomagnév példa)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'

# RHEL-család (a csomagnév példa)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
```

Részletes útmutatót a következő oldalon talál: [A PHP-verzió és a javítási állapot ellenőrzése](https://phpsos.de/hu/php2shell/php-version-pruefen/).

## A frissítés telepítése és az összes folyamat megújítása

Telepítse a frissítéseket a csomagkezelőn keresztül, majd indítson újra minden szolgáltatást, amely betölti a PHP-t. Felépítéstől függően ez a PHP-FPM, az Apache mod_php-vel, a LiteSpeed vagy egy alkalmazásszerver. A lemezen lévő új fájlok nem elegendők, amíg régi folyamatok futnak a memóriában.

```bash
# PHP-t futtató szolgáltatások keresése
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'

# Folyamatok megjelenítése indulási idővel
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep

# Debian/Ubuntu: elavult könyvtárakat használó programok felismerése (ha telepítve van)
needrestart -r l
```

Minden érintett folyamatnak a frissítés után kellett elindulnia. Hasznos a `needrestart` eszköz Debian-rendszereken, amely megmutatja az elavult könyvtárakat használó szolgáltatásokat. Az újraindítás részleteit a következő oldal írja le: [A PHP-FPM és az összes worker újraindítása](https://phpsos.de/hu/php2shell/php-fpm-neustart/).

> **Fontos:**
> A javítás nem távolítja el a frissítés előtt bejuttatott kártevőt. Őrizze meg a webszerver naplóit 2026. október 20-tól, és ellenőrizze a szervert nyomokra, mielőtt tisztának minősíti.

Az első nyomkereséshez néhány olyan ellenőrzés kínálkozik, amely nem módosít semmit. Keressen olyan PHP-fájlokat, amelyeket 2026. október 17. óta hoztak létre vagy módosítottak a webes könyvtárakban, ismeretlen bejegyzéseket az összes felhasználó crontabjaiban, új rendszerfelhasználókat és SSH-kulcsokat, valamint a webszerver-felhasználó olyan folyamatait, amelyek kimenő kapcsolatokat tartanak fenn.

```bash
# 2026. október 17. óta módosított PHP-fájlok (az útvonal példa)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls

# Hálózati kapcsolatok a hozzájuk tartozó folyamattal
ss -tupn
```

Ezen ellenőrzések egyike sem bizonyít önmagában betörést, és az üres eredmény sem bizonyítja az ellenkezőjét. Megmutatják viszont, hogy szükség van-e mélyebb vizsgálatra. A naplók másolatain dolgozzon, és a gyanús fájlokat ne módosítsa, amíg az állapotot nem mentette. Lelet esetén a rendezett vizsgálat a biztos út. Ilyenkor ne kapcsolja ki egyszerűen a szervert, és ne telepítse azonnal újra, mert így elvesznek azok a nyomok, amelyek a bejelentési kötelezettségek értékeléséhez és egy esetleges feljelentéshez fontosak.

## A szerver tartós megerősítése

Az akut javítás után az alapvédelem következik. Nem akadályoz meg minden rést, de korlátozza a kárt, és lerövidíti a reakcióidőt legközelebb. Ezek a pontok váltak be:

- **Hozzáférések:** SSH csak kulccsal, közvetlen root bejelentkezés nélkül, a kezelőfelületek csak ismert hálózatokból legyenek elérhetők.
- **Tűzfal:** csak azokat a portokat nyissa meg, amelyekre valóban szükség van, korlátozza a webszerver kimenő kapcsolatait.
- **PHP-konfiguráció:** veszélyes függvények letiltása, weboldalanként `open_basedir`, alkalmazásonként saját poolok és felhasználók.
- **Fájljogosultságok:** a webszerver ne írhassa a programkódot, a feltöltési könyvtárakban ne fusson PHP.
- **Frissítések:** a biztonsági frissítések automatikus telepítése, az újraindítás és az ellenőrzés fix beütemezése.
- **Mentések:** mentés a 3-2-1 szabály szerint, legalább egy másolat a szerveren kívül és módosítás ellen védve.
- **Naplók:** a naplók központi gyűjtése és kellően hosszú megőrzése.

Hogyan néz ki egy megbízható mentés, azt a következő oldal írja le: [Mentések a 3-2-1 szabály szerint](https://phpsos.de/hu/ratgeber/backups-3-2-1/). Vállalkozások számára keretként a BSI IT-Grundschutz (német IT-alapvédelem) ajánlható.

## Mikor jobb választás a menedzselt szerver

A saját szerver akkor éri meg, ha valaki megbízhatóan átveszi a gondozását: követi a frissítéseket, értékeli az olyan helyzeteket, mint a PHP2Shell, és éjszaka is tud reagálni. Ha ez a kapacitás hiányzik, vagy menedzselt szerver, vagy fix karbantartási szerződés a célszerű. Mindkét esetben fontos az illetékességeket írásban rögzíteni. Erről többet itt talál: [Menedzselt szerver: a felelősség tisztázása](https://phpsos.de/hu/server/managed-server/).

## Hogyan segít konkrétan a PHP SOS?

- Felmérjük a szerver összes PHP-telepítését, csomagforrását és szolgáltatását, és értékeljük a tényleges javítási állapotot.
- Telepítjük a frissítéseket, újraindítjuk az összes folyamatot, és dokumentáljuk az eredményt.
- Ellenőrizzük a szervert a kompromittálódás nyomaira, és mentjük a naplókat egy későbbi kiértékeléshez.
- A [szerver-megerősítésünk](https://phpsos.de/hu/leistungen/server-haertung/) keretében rendezetten beállítjuk a hozzáféréseket, a tűzfalat, a PHP-poolokat és a jogosultságokat.
- Kérésre átvesszük a folyamatos gondozást [biztonsági karbantartási szerződés](https://phpsos.de/hu/leistungen/security-wartungsvertrag/) keretében.


## Gyakori kérdések

**Automatikusan javítja a vServeremet a számítóközpont?**  
A nem menedzselt root szervereknél és vServereknél általában nem. A szolgáltató a hardvert vagy a virtualizációt és a hálózatot biztosítja, az operációs rendszert és az összes rajta futó szolgáltatást Ön maga kezeli. Kétség esetén nézze meg a szerződését.

**Elegendők az automatikus biztonsági frissítések?**  
Segítenek, de az ellenőrzést nem helyettesítik. Az automatikus frissítések nem mindig indítják újra a futó PHP-folyamatokat, és a külső forrásból származó csomagokat gyakran nem fedik le. Minden biztonsági frissítés után ellenőrizze a csomagállapotot és a folyamatok indulási idejét.

**Hogyan tudom meg, hogy a csomagom tartalmaz-e backportot?**  
A csomag változásnaplójából és a disztribúció biztonsági közleményeiből. Ha ott szerepel a CVE-szám, a javítás benne van, akkor is, ha a verziószám régebbinek tűnik. Ha a bejegyzés hiányzik, tisztázza az állapotot, mielőtt a szervert javítottnak minősíti.

**Mit tegyek, ha a PHP-verziómhoz nem jön javítás?**  
A PHP 8.1-hez és a régebbiekhez már nem adnak ki hivatalos frissítést. Állítsa be a php.net szerinti átmeneti intézkedéseket, tervezze meg mielőbb az áttérést egy támogatott verzióra, és a BSI ajánlása szerint szükség esetén ideiglenesen vegye le a szervert a hálózatról.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: támogatott verziók](https://www.php.net/supported-versions.php)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)