Röviden: A fejlesztői háttér nélküli adminoknak öt alapismeret elég a PHP biztonságos üzemeltetéséhez: a PHP több programból áll (parancssor, PHP-FPM, Apache-modul), mindegyiknek saját verziója van; a beállítások szintekben hatnak a php.ini-től az alkalmazásig; a PHP-FPM a kéréseket poolokban lévő workerekre osztja el; egy frissítés csak az összes folyamat újraindítása után hat; a naplók pedig a legfontosabb jelzések, ha valami nincs rendben. Aki ezeket a pontokat ismeri, az olyan réseket, mint a PHP2Shell, gyorsan és igazolhatóan bezárhatja.
Miből áll a PHP egy szerveren
A PHP nem egyetlen program. Egy tipikus Linux-szerveren több változat található, amelyek mindegyike egy szerverfelületen (SAPI) keresztül csatlakozik:
| Változat | Tipikus név | Mire való |
|---|---|---|
| Parancssor (CLI) | php, php8.3 |
cronjobok, Composer, karbantartó szkriptek |
| PHP-FPM | php-fpm, php-fpm8.3 |
webkérések Nginx vagy Apache mögött |
| Apache-modul | mod_php, libphp |
webkérések közvetlenül az Apache-folyamatban |
| CGI | php-cgi |
régebbi felépítések |
Minden változatnak lehet más verziója és más php.ini-je. Sok szerveren emellett több PHP-verzió fut párhuzamosan, például a 8.2 és a 8.4. Frissítésnél mindegyiket külön kell megvizsgálni. Hogyan működnek a felületek, azt A PHP-FPM elmagyarázva oldal magyarázza.
Hogy melyik változat szolgálja ki ténylegesen a weboldalait, azt a futó folyamatokból és a webszerver-konfigurációból tudhatja meg:
ps -eo pid,user,lstart,cmd | grep -E "php|httpd|apache2" | grep -v grep
apachectl -M 2>/dev/null | grep -i php # betölt az Apache PHP-modult?
ls /run/php/ 2>/dev/null # FPM-socketek, gyakran verziónként és poolonként
Az indítási időt tartalmazó oszlop később az újraindításnál fontos: az összes PHP-folyamatnak a frissítés időpontja után kellett elindulnia. Ha a folyamatok különböző felhasználók alatt futnak, az különálló poolokra utal, ami jó. Ha egy PHP-modul megjelenik az Apache-ban, noha az összes weboldalnak FPM-en keresztül kellene futnia, az egy eltávolítandó régi teherre utal. A tárhelyfelületekre, mint a Plesk vagy a cPanel, ugyanez az elv érvényes, csak hogy a felület weboldalanként mutatja a verziókat és a kezelőket; mérvadó azonban az marad, ami ténylegesen folyamatként fut.
A legfontosabb parancsok adminoknak
php -v # a parancssor verziója
php --ini # betöltött php.ini és további beolvasott könyvtárak
php --ini=diff # a PHP 8.5-től: eltérések az alapértelmezéstől
php -m # befordított és betöltött modulok
php --ri session # egy bővítmény beállításai
php -l datei.php # szintaxisellenőrzés futtatás nélkül
php-fpm8.3 -v # az FPM-bináris verziója (a név disztribúciónként eltér)
php-fpm8.3 -t # az FPM-konfiguráció tesztelése újraindítás nélkül
systemctl status php8.3-fpm
Két megjegyzés a kézikönyvből: a php -l szintaktikai hibákat talál, de nem azokat a hibákat, amelyek csak végrehajtáskor lépnek fel. A php -i pedig a phpinfo()-t hívja meg; a kimenet nem való a webkönyvtárban lévő nyilvános fájlokba.
Hogyan hatnak a PHP-beállítások
Egy beállítás több helyen is megadható. Hogy ki hol mit módosíthat, azt minden direktíva módosítási módja szabályozza:
- php.ini és conf.d: változatonkénti alapkonfiguráció, induláskor olvassa be.
- FPM-pool:
php_valueésphp_admin_valuepoolonként. Aphp_admin_value-val megadott értékeket az alkalmazás a kézikönyv szerint nem írhatja felül azini_set()-tel. - Könyvtárszint:
.user.iniaz FPM-nél vagy.htaccessa mod_php-nál, csak azINI_PERDIRvagyINI_ALLmódú direktívákhoz. - Alkalmazás:
ini_set()futásidőben, csak azINI_ALLmódú direktívákhoz.
Egy példa: a memory_limit módja INI_ALL, tehát az alkalmazás módosíthatja. A post_max_size módja INI_PERDIR, és nem módosítható az ini_set()-tel. Ezért követeli meg a php.net a PHP2Shell átmeneti intézkedéseinél, hogy az értékeket úgy állítsák be, hogy az alkalmazások ne írhassák felül őket. A szintek részleteit A php.ini elmagyarázva oldal magyarázza.
A PHP-FPM-poolok dióhéjban
A pool workerek csoportja saját felhasználóval, saját sockettel és saját beállításokkal. A legfontosabb direktívák a kézikönyv szerint:
[shop]
user = shop
group = shop
listen = /run/php/shop.sock
pm = dynamic ; static, dynamic vagy ondemand
pm.max_children = 20 ; legfeljebb 20 egyidejű kérés
pm.max_requests = 500 ; a worker megújítása 500 kérés után
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/shop-slow.log
php_admin_value[error_log] = /var/log/php-fpm/shop-error.log
php_admin_flag[log_errors] = on
A weboldalankénti saját pool saját felhasználóval elválasztja egymástól a weboldalakat. A security.limit_extensions alapértelmezés szerint .php .phar, és megakadályozza, hogy az FPM más fájlkiterjesztéseket PHP-ként hajtson végre. A clear_env alapértelmezés szerint be van kapcsolva, és távol tartja a környezeti változókat a workertől.
Naplók: hová nézzenek az adminok
A PHP a hibákat az error_log-gal megadott célra írja, a PHP-FPM emellett a saját naplójába, a lassú kéréseket pedig backtrace-szel a slowlogba. Ehhez jönnek a webszerver hozzáférési és hibanaplói. Ügyeljen arra, hogy a display_errors éles üzemben ki, a log_errors pedig be legyen kapcsolva: a hibák a naplóba valók, nem a weboldalra. A naplókat emellett rotálni kell, és meghatározott ideig meg kell őrizni, hogy éles helyzetben még meglegyenek. A PHP2Shell után a szaksajtó azt ajánlja, hogy a szervernaplókat 2026. október 20-tól őrizzék meg. Erős figyelmeztető jel egy olyan PHP-FPM- vagy webszerver-folyamat, amely shellt indít; hogyan ismeri fel ezt, azt a Figyelmeztető jel: a webszerver shellt indít cikk írja le.
Ellenőrzőlista adminoknak a PHP2Shell után
- Sorolja fel a szerveren lévő összes PHP-változatot és -verziót, a nem használtakat is.
- Ellenőrizze a csomagállapotot; a disztribúció backportjainál keresse át a changelogot a CVE-2026-109618 és a CVE-2026-109619 után.
- Frissítsen a 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verzióra, illetve a megerősített backportra.
- Indítsa újra a PHP-FPM-et, az Apache-ot és a LiteSpeedet, és ellenőrizze a folyamatok indítási idejét.
- Ellenpróba a
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'paranccsal; abool(false)a kézikönyv szerint érintett verziót jelent. - Biztosítsa a naplókat, és vizsgálja át őket feltűnő jelenségek szempontjából.
Hogyan igazolhatja megbízhatóan a verziót és a javítási állapotot, azt a PHP-verzió és javítási állapot helyes ellenőrzése oldal írja le.
Hogyan segít konkrétan a PHP SOS?
A biztonsági karbantartási szerződés keretében a PHP alapgondozását a csapatával együtt átvesszük:
- Leltár: az összes PHP-változat, -verzió, pool és konfigurációs hely szerverenként.
- Konfiguráció: a biztonsági szempontból releváns értékek
php_admin_value-val beállítva, a poolok weboldalanként elválasztva. - Frissítések: telepítés, újraindítás, ellenőrzés és dokumentálás minden biztonsági kiadásnál.
- Tudás átadása: Elmagyarázzuk az adminjainak, mit változtattunk és miért.
Gyakori kérdések
Miért mutat a php -v más verziót, mint a weboldal?
A parancssor, a PHP-FPM és az Apache-modul különálló programok saját verzióval és saját php.ini-vel. A php -v csak a parancssort mutatja. A weboldalnál a ténylegesen kéréseket feldolgozó bináris verziója számít.
Melyik php.ini érvényes a szerveremen?
A parancssorra a php --ini mutatja meg. A PHP-FPM-nek többnyire saját php.ini-je és további pool-fájljai vannak. A PHP 8.5 óta a php --ini=diff megmutatja, mely értékek térnek el az alapértelmezéstől.
Mi a különbség a php_value és a php_admin_value között?
Mindkettő beállításokat rögzít egy FPM-poolban. A php_admin_value-val megadott értékeket az alkalmazás a kézikönyv szerint nem írhatja felül az ini_set()-tel. A biztonsági szempontból releváns beállításokhoz ezért a php_admin_value a helyes választás.
Elég egy frissítés újraindítás nélkül?
Nem. A futó PHP-folyamatok megtartják a régi kódot a memóriában. Frissítés után a PHP-FPM-et, az Apache-ot mod_php-val vagy a LiteSpeedet újra kell indítani, különben a sebezhető verzió fut tovább.