Nginx védelme PHP-FPM-mel

Röviden: Nginx és PHP-FPM esetén a PHP2Shell rése a PHP-FPM-ben van, nem az Nginxben. Javítsa az összes PHP-FPM-verziót, indítsa újra teljesen minden FPM-szolgáltatást, és igazolja ezt a folyamatok indulási idejével. Az Nginx PHP-FPM biztonsághoz tartósan az elkülönített poolok, a felülírhatatlan értékek és egy olyan Nginx-konfiguráció számít, amely nem futtat feltöltött fájlokat.

Hogyan működik együtt az Nginx és a PHP-FPM

Az Nginx a statikus fájlokat maga szolgálja ki, a PHP-szkriptekre irányuló kéréseket pedig FastCGI-n keresztül adja tovább a PHP-FPM-nek. A PHP-FPM egy master folyamatból és több worker folyamatból áll, poolokba csoportosítva. Egy worker egymás után sok kérést dolgoz fel.

Pontosan ez lényeges a PHP2Shell szempontjából. A CVE-2026-109619 esetében egy kérés belső állapota a memória felszabadítása után is megmaradhat, és ugyanabban a workerben egy későbbi kérés felhasználhatja. A CVE-2026-109618 esetében egy memóriahiányos állapot (out-of-memory) megszakíthatja a PHP-t egy kérés inicializálása közben. Mindkét rés CVSS v4.0 9,2 értékű, és a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verzióban javították.

A készlet ellenőrzése: verziók, poolok, folyamatok

Sok szerveren több PHP-FPM-verzió fut párhuzamosan. A következő parancsok csak olvasnak; a csomag- és szolgáltatásnevek példák Debian/Ubuntu és az RHEL-család rendszerekre.

# Mely FPM-szolgáltatások futnak?
systemctl list-units --type=service | grep -i fpm

# Melyik verzió áll mögötte? (példa Debian/Ubuntu)
php-fpm8.3 -v
# RHEL-család
php-fpm -v

# Mely socketekre vagy portokra adja tovább az Nginx?
nginx -T 2>/dev/null | grep -E 'fastcgi_pass'

# Poolok és felhasználóik
grep -RhE '^\[|^user|^listen' /etc/php/*/fpm/pool.d/ 2>/dev/null

Vesse össze az összes fastcgi_pass bejegyzést egy futó poollal. Így látja, melyik PHP-verzió melyik weboldalt szolgálja ki. Disztribúciós csomagoknál a CVE-számokat tartalmazó változásnapló igazolja a javítást, nem pusztán a verziószám.

Az ilyen készletfelméréseknél gyakori lelet az olyan szerver, amelyen az évek során több PHP-verziót telepítettek, és közülük csak egy van ténylegesen használatban. A többi FPM-szolgáltatás ennek ellenére tovább fut, gyakran alapértelmezett poolokkal, amelyek helyi socketen vagy porton figyelnek. Kívülről többnyire nem közvetlenül elérhetők, de szükségtelen kockázatot jelentenek, és meghosszabbítanak minden sürgősségi frissítést. A weboldal által nem használt verziókat tiltsa le és távolítsa el, miután a fastcgi_pass bejegyzéseken keresztül ellenőrizte a hozzárendelést.

Ugyanígy érdemes megnézni a poolok felhasználóját. Ha az összes pool www-data vagy nginx felhasználóként fut, a weboldalak közötti elválasztás csak papíron létezik. Aki átvesz egy weboldalt, ilyenkor olvashatja az összes többi fájljait, például az adatbázisjelszavakat tartalmazó konfigurációs fájlokat. Poolonként saját rendszerfelhasználók és megfelelő fájljogosultságok valódi határt húznak. Ez nem elhárítása a PHP2Shellnek, de jelentősen korlátozza egy sikeres támadás lehetséges kárát.

A javítás telepítése és az összes worker megújítása

A csomagfrissítés után indítson újra minden PHP-FPM-szolgáltatást. Az újratöltés ugyan lecseréli a workereket, a teljes újraindítás azonban a master folyamatot is megújítja, és biztonsági frissítések után ez a biztos út.

# Példa Debian/Ubuntu, telepített verziónként
systemctl restart php8.3-fpm
# RHEL-család
systemctl restart php-fpm

# Ellenőrzés: a master és a workerek indulási ideje
ps -eo pid,lstart,cmd | grep -E 'php-fpm' | grep -v grep

Minden folyamatnak a frissítés után kellett elindulnia. Részletesen leírja a következő oldal: A PHP-FPM és az összes worker újraindítása.

Átmeneti értékek beállítása a poolban

Amíg egy verzió nincs javítva, a php.net átmeneti intézkedéseket javasol. Ezek nem nyújtanak teljes védelmet. A PHP-FPM-ben az értékeket a poolban php_admin_value, illetve php_admin_flag segítségével adja meg, így az alkalmazások nem írhatják felül őket ini_set()-tel.

; Példa: /etc/php/8.3/fpm/pool.d/website.conf
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M

Feltöltési funkció nélkül a php.net post_max_size = 8M értéket nevezi meg. A PHP 8.5-nél ehhez jön a fatal_error_backtraces=0. A memory_limit=-1 megjegyzéshez cgroup-szintű memóriakorlát kell, például a MemoryMax segítségével az FPM-szolgáltatás systemd-kiegészítésében. Az Nginxben igazítsa a client_max_body_size értékét az új post_max_size értékhez, hogy a felhasználók érthető hibaüzeneteket kapjanak. Utána indítsa újra az FPM-et.

Az Nginx PHP-FPM biztonság tartós javítása

Az akut esetén túl néhány alapszabály segít korlátozni a kárt a jövőbeli rések esetén:

• Weboldalanként egy pool saját rendszerfelhasználóval, saját sockettel és saját open_basedir határral. Többet itt talál: open_basedir és weboldalankénti elkülönítés.
• A socket jogosultságait úgy állítsa be, hogy csak az Nginx férjen hozzá, ne nyisson meg FPM-portokat kifelé.
• Csak létező szkripteket futtasson: a PHP-location blokkban állítsa be a try_files $uri =404; sort, hogy az Nginx ne adjon át a PHP-nek nem létező útvonalakat.
• A feltöltéseket ne futtassa: a feltöltési könyvtárakban tiltsa le a PHP-futtatást. Ehhez útmutatás a következő oldalon van: Fájlfeltöltések biztonságos megvalósítása.
• Az állapotoldalakat védje: a pm.status_path és a ping.path csak belsőleg legyen elérhető.

# Példa: nincs PHP-futtatás a feltöltési könyvtárban
location ~* ^/uploads/.*\.php$ {
    deny all;
}

Minden módosítást ellenőrizzen az nginx -t paranccsal, mielőtt újratölti az Nginxet. Rögzítse emellett, mely poolok, verziók és különleges szabályok vannak a szerveren. Ez a rövid dokumentáció a következő kritikus résnél értékes időt takarít meg, mert senkinek nem kell először keresnie, melyik weboldal melyik poolhoz tartozik.

Hogyan segít konkrétan a PHP SOS?

• Minden weboldalt hozzárendelünk a poolhoz és a PHP-verziójához, és ellenőrizzük a tényleges csomagállapotot.
• Javítunk, újraindítjuk az összes FPM-szolgáltatást, és a folyamatok indulási idejét dokumentáljuk igazolásként.
• A javításig az átmeneti értékeket poolonként állítjuk be, és cgroupokkal korlátozzuk a memóriát.
• A szerver-megerősítés keretében rendezetten szétválasztjuk a poolokat, a jogosultságokat és a feltöltési könyvtárakat.
• Betörés gyanúja esetén átvesszük az Incident Response feladatát.

Gyakori kérdések

Források

• php.net: biztonsági közlemények
• PHP 8 ChangeLog
• OWASP Cheat Sheets
• BSI