Röviden: A Plesk PHP-handlere határozza meg, hogyan fut a PHP egy weboldalhoz: FPM-alkalmazásként közös poolban, Dedicated FPM-ként weboldalankénti saját poolban, FastCGI-alkalmazásként vagy Apache-modulként (mod_php). Biztonsági szempontból Linux alatt többnyire a Dedicated FPM a legjobb választás, az Apache-modul a legrosszabb. A Plesk maga is elavultnak, illetve nem biztonságosnak nevezi, és a PHP2Shell esetében a PHP-csapat éppen a mod_php-nál látja a legnagyobb kockázatot.
Miért több a handler teljesítménykérdésnél
A Pleskben minden weboldalhoz PHP-verziót és handlert választ. Sokan a handlert a teljesítmény és a memória részletkérdésének tekintik. Pedig az is eldönti, mennyire vannak elválasztva egymástól a weboldalak, hol hatnak a biztonsági beállítások, és mely folyamatokat kell frissítés után újraindítani.
A PHP2Shell után ez a választás konkréttá válik. A CVE-2026-109618 és CVE-2026-109619 rések az összes elterjedt üzemmódot érintik, a PHP-csapat azonban a mod_php esetében értékeli a legmagasabbra a kockázatot. Aki a Plesk-szerverén még Apache-modullal üzemeltet domaineket, most változtasson ezen. Hogyan ellenőrzi és javítja a verziókat, azt a Plesk-szerver: PHP-verziók ellenőrzése és javítása oldal írja le; itt az üzemmód kiválasztásáról van szó.
A Plesk PHP-handlerei áttekintésben
Az alábbi áttekintés a Plesk Obsidian Plesk-dokumentációján alapul, kiegészítve a biztonsági szemponttal. Linux alatt az FPM-handlerek a Plesk szerint tetszés szerint Apache-on vagy nginxen keresztül szolgálhatók ki, a FastCGI mindig Apache-on keresztül.
| Handler | Kiszolgálás | Izoláció | A Plesk ajánlása | Biztonsági szempont |
|---|---|---|---|---|
| Dedicated FPM application | Apache vagy nginx | weboldalankénti saját pool | Linux megosztott tárhellyel | a legjobb elválasztás, poolonként saját értékek |
| FPM application | Apache vagy nginx | PHP-verziónként közös pool | dedikált Linux-szerverek | egy hibás weboldal zavarhatja a többit ugyanazon a verzión |
| FastCGI application | Apache (Linux) | tartós folyamatok, jó elválasztás | Windows-szerverek | megbízható, Linux alatt többnyire az FPM váltotta fel |
| Apache module (mod_php) | Apache | PHP a webszerver folyamatában | nem ajánlott | a PHP-csapat szerint a legmagasabb PHP2Shell-kockázat |
| CGI application | Apache | új folyamat minden kéréshez | nem ajánlott | elavult |
Az üzemmódok hátterét a A PHP-FPM magyarázata és a Miért a mod_php viseli a legmagasabb kockázatot oldal ismerteti.
Közös vagy saját pool?
Az FPM és a Dedicated FPM közötti különbséget gyakran alábecsülik. A normál FPM-handlernél a Plesk szerint az azonos PHP-verziójú összes weboldal egy folyamat-poolon osztozik. Ez memóriát takarít meg, de azt is jelenti: egy problémát okozó weboldal magával rántja az összes többit ugyanazon a verzión, és a közös gyorsítótár is osztott.
A Dedicated FPM minden weboldalnak saját poolt ad. A Plesk szerint ez javítja az izolációt és a teljesítményt, de több memóriát igényel. Biztonsági szempontból a saját pool az alapja annak, hogy az olyan beállításokat, mint az open_basedir, a memóriakorlátok vagy a feltöltési limitek, weboldalanként külön lehessen megadni. Hogyan választja el következetesen a poolokat, azt a PHP-FPM-poolok izolálása weboldalanként cikk írja le.
nginx vagy Apache: a .htaccess-csapda
Ha nginxen keresztül kiszolgált handlert választ, valami alapvető megváltozik: a Plesk szerint ezek a handlerek figyelmen kívül hagyják a .htaccess fájlt. Ami ott áll, többé nem hat.
Ez biztonsági téma. Sok alkalmazás és rendszergazda a védelmi szabályokat a .htaccess fájlban tartja, például a PHP-fájlok futtatásának tiltását a feltöltési mappákban vagy a konfigurációs fájlok zárolását. Az nginxre váltás után ezek a szabályok csendben hatályukat vesztik. Ellenőrizze ezért a váltás előtt, mely védelmi szabályok szerepelnek a .htaccess fájlban, és vigye át őket a domain nginx-konfigurációjába.
A handler cseréje a biztonsági konfiguráció módosítása. Utána célzottan tesztelje, hogy a lezárt útvonalak továbbra is le vannak-e zárva, és ne csak azt, hogy a nyitóoldal betöltődik-e.
A handler ellenőrzése és átállítása
Először áttekintést kell szereznie arról, mely domainek melyik handlert használják. A parancsok kizárólag olvasnak.
# Az összes regisztrált handler azonosítóval, verzióval és típussal
plesk bin php_handler --list
# Egy adott handlert használó domainek (az azonosító a listából)
plesk bin php_handler --get-usage -id <handler-id>
# Fut a PHP az Apache-folyamatban? (Debian/Ubuntu: apache2ctl, RHEL-család: httpd)
apache2ctl -M 2>/dev/null | grep -i php
Az átállításnál domainről domainre haladjon:
- Gyűjtse össze a
.htaccessvédelmi szabályait, ha az új handlert nginxen keresztül szolgálják ki. - Állítsa be az új handlerhez a PHP2Shell elleni átmeneti értékeket, például a
session.upload_progress.enabled=0értéket. FPM esetén ezekphp_admin_valueformában a pool kiegészítő direktívái közé tartoznak, FastCGI esetén más utak hatnak. - Váltson handlert a domain PHP-beállításaiban, lehetőleg először egy másolaton.
- Tesztelje a funkciókat, és ellenőrizze, hogy a domaint aktuális kódú folyamatok szolgálják-e ki.
- Ha az Apache-modult már egyetlen domain sem használja, kapcsolja ki a handlert.
Milyen sorrendben állítson át?
Egy kinőtt Plesk-szerveren ritkán lehet mindent egy nap alatt átállítani. A kockázat szerinti sorrend segít a szűkös időt értelmesen felhasználni:
- Először az Apache-modult használó domainek, mert ott a PHP-csapat szerint a legnagyobb a PHP2Shell kockázata, és a Plesk amúgy is eltanácsol tőle.
- Aztán az érzékeny adatokat kezelő domainek, például webshopok, ügyfélportálok vagy egészségügyi vagy szerződéses adatokat tartalmazó űrlapok. Itt különösen megéri a saját pool.
- Ezután a régi PHP-verziókon lévő domainek, amelyeket amúgy is át kell állítani. A handler és a verzió egy karbantartási ablakban együtt cserélhető.
- Végül a közös poolról a saját poolra váltás a többi domainnél, ha a szerver memóriája engedi.
Az utolsó lépcső előtt ellenőrizze a memóriakihasználtságot. A Plesk arra figyelmeztet, hogy a Dedicated FPM több memóriát igényel, és sok weboldalnál a figyelést javasolja. Az a szerver, amely az átállítás után memóriát lapoz ki, lassúvá válik, és a szűkös memória éppen a PHP2Shell idején nem jó állapot.
Hogyan segít konkrétan a PHP SOS?
- Felmérjük, a Plesk-szerverén mely domainek melyik handlert használják, és megjelöljük az Apache-modult használó domaineket.
- Átállítunk Dedicated FPM-re, és a
.htaccessvédelmi szabályait szükség esetén átültetjük az nginx-konfigurációba. - Poolonként beállítjuk az átmeneti értékeket és korlátokat, és ellenőrizzük, hogy a webes környezetben érvényesülnek.
- A szerver megerősítése keretében kikapcsoljuk az elavult handlereket, és dokumentáljuk a konfigurációt.
Gyakori kérdések
Melyik PHP-handlert ajánlja a Plesk?
A Plesk-dokumentáció szerint az FPM az ajánlott handler dedikált Linux-szervereken, a Dedicated FPM megosztott tárhelyet kiszolgáló Linux-szervereken, a FastCGI pedig Windows-szervereken. Az Apache-modult, a CGI-t és az ISAPI-t a Plesk erősen elavultnak, illetve nem biztonságosnak minősíti.
Miért különösen kritikus az Apache-modul handler a PHP2Shell után?
A handler a mod_php-nak felel meg. A PHP-csapat a PHP2Shell kockázatát a mod_php esetében értékeli a legmagasabbra, mert ott még az alkalmazáskód futása előtt bemutattak egy exploitot. Emellett a Plesk maga is eltanácsol ettől a handlertől.
Mi változik, ha a PHP-t nginxen keresztül szolgálják ki Apache helyett?
A Plesk szerint az nginxen keresztül kiszolgált handlerek figyelmen kívül hagyják a .htaccess fájlt. Az ott szereplő biztonsági szabályok, például a PHP tiltása a feltöltési mappákban, ilyenkor már nem érvényesülnek, és nginx-szabályokká kell átültetni őket.
Újra kell indítani a PHP-t a handler cseréje után?
A csere után ellenőrizze, mely PHP-folyamatok futnak a domainhez, és mióta. Dedicated FPM esetén a domain saját poolt kap. Egy elavult kódú régi folyamat ezután már ne dolgozzon a domainnek.
A Dedicated FPM mindig a legjobb választás?
Az izoláció szempontjából igen, mert minden weboldal saját poolt kap. Ennek ára a nagyobb memóriaigény. A Plesk azt javasolja, hogy sok weboldalt kiszolgáló szervereket ilyenkor figyeljen.