Lühidalt: Plesk PHP-handler määrab, kuidas PHP veebisaidi jaoks töötab: FPM-rakendusena ühise pooliga, Dedicated FPM-na oma pooliga iga veebisaidi kohta, FastCGI rakendusena või Apache moodulina (mod_php). Turvalisuse vaatenurgast on Linuxis enamasti parim valik Dedicated FPM, halvim Apache moodul. Plesk ise nimetab seda aegunuks ehk ebaturvaliseks ja PHP2Shelli puhul näeb PHP meeskond suurimat riski just mod_php juures.
Miks handler on enamat kui jõudlusküsimus
Pleskis valite iga veebisaidi jaoks PHP versiooni ja handleri. Paljud peavad handlerit jõudluse ja mälu üksikasjaks. Kuid see otsustab ka selle, kui tugevalt on veebisaidid üksteisest eraldatud, kus turvasätted toimivad ja millised protsessid tuleb pärast uuendust taaskäivitada.
Pärast PHP2Shelli muutub see valik konkreetseks. Turvaaugud CVE-2026-109618 ja CVE-2026-109619 mõjutavad kõiki levinud töörežiime, kuid PHP meeskond hindab riski kõige suuremaks mod_php puhul. Kes veel oma Plesk-serveris domeene Apache mooduliga käitab, peaks seda nüüd muutma. Kuidas versioone kontrollida ja paikada, kirjeldab leht Plesk-server: PHP versioonide kontroll ja paikamine; siin on jutt töörežiimi valikust.
Plesk PHP-handlerite ülevaade
Järgmine ülevaade põhineb Plesk Obsidiani dokumentatsioonil, täiendatud turvalisuse vaatenurgaga. Linuxis saab FPM-handlereid Plesk andmetel edastada valikuliselt Apache'i või nginxi kaudu, FastCGI-d alati Apache'i kaudu.
| Handler | Edastatakse kaudu | Eraldatus | Soovitus Plesk järgi | Turvalisuse vaade |
|---|---|---|---|---|
| Dedicated FPM application | Apache või nginx | oma pool iga veebisaidi kohta | Linux jagatud majutusega | parim eraldatus, oma väärtused pooli kohta |
| FPM application | Apache või nginx | ühine pool PHP versiooni kohta | pühendatud Linuxi serverid | probleemne veebisait võib häirida teisi sama versiooniga saite |
| FastCGI application | Apache (Linux) | püsivad protsessid, hea eraldatus | Windowsi serverid | töökindel, Linuxis enamasti FPM-iga asendatud |
| Apache module (mod_php) | Apache | PHP veebiserveri protsessis | ei soovitata | suurim PHP2Shelli risk PHP meeskonna andmetel |
| CGI application | Apache | uus protsess iga päringu kohta | ei soovitata | aegunud |
Töörežiimide tausta selgitavad lehed PHP-FPM selgitatud ja Miks mod_php kannab suurimat riski.
Ühine või oma pool?
Vahet FPM-i ja Dedicated FPM-i vahel alahinnatakse sageli. Tavalise FPM-handleri puhul jagavad Plesk andmetel kõik sama PHP versiooniga veebisaidid ühte protsessipooli. See säästab mälu, kuid tähendab ka: probleeme tekitav veebisait võib kaasa tõmmata kõik teised sama versiooniga saidid ning ühine vahemälu on jagatud.
Dedicated FPM annab igale veebisaidile oma pooli. Plesk andmetel parandab see eraldatust ja jõudlust, kuid nõuab rohkem mälu. Turvalisuse mõttes on oma pool aluseks selleks, et sätteid nagu open_basedir, mälupiirangud või üleslaadimislimiidid saaks veebisaidi kaupa eraldi määrata. Kuidas pooli järjekindlalt eraldada, kirjeldab artikkel PHP-FPM poolide eraldamine veebisaidi kaupa.
nginx või Apache: .htaccessi lõks
Kui valite handleri, mida edastatakse nginxi kaudu, muutub midagi põhimõttelist: Plesk andmetel ignoreerivad need handlerid faili .htaccess. Mis seal seisab, ei toimi enam.
See on turvateema. Paljud rakendused ja administraatorid panevad kaitsereeglid faili .htaccess, näiteks keelu käivitada PHP faile üleslaadimiskataloogides või seadistusfailide blokeeringud. Pärast üleminekut nginxile on need reeglid vaikselt kehtetud. Kontrollige seetõttu enne vahetust, millised kaitsereeglid failis .htaccess seisavad, ja kandke need üle domeeni nginxi seadistusse.
Handleri vahetus on turvaseadistuse muudatus. Testige pärast sihipäraselt, kas blokeeritud teed on endiselt blokeeritud, mitte ainult seda, kas avaleht laeb.
Handleri kontrollimine ja ümberlülitamine
Esmalt hankige ülevaade, millised domeenid millist handlerit kasutavad. Käsud on puhtalt lugevad.
# Kõik registreeritud handlerid koos ID, versiooni ja tüübiga
plesk bin php_handler --list
# Domeenid, mis teatud handlerit kasutavad (ID nimekirjast)
plesk bin php_handler --get-usage -id <handler-id>
# Kas PHP töötab Apache'i protsessis? (Debian/Ubuntu: apache2ctl, RHEL-perekond: httpd)
apache2ctl -M 2>/dev/null | grep -i php
Ümberlülitamisel toimige domeeni kaupa:
- Kui uut handlerit edastatakse nginxi kaudu, koguge kokku
.htaccesskaitsereeglid. - Seadke uuele handlerile PHP2Shelli vastased üleminekuväärtused, näiteks
session.upload_progress.enabled=0. FPM-i puhul kuuluvad needphp_admin_value-na pooli lisadirektiividesse, FastCGI puhul toimivad muud teed. - Vahetage handler domeeni PHP seadetes, võimaluse korral esmalt koopial.
- Testige funktsioone ja kontrollige, kas domeeni teenindavad ajakohase koodiga protsessid.
- Kui Apache moodulit ei kasuta enam ükski domeen, deaktiveerige handler.
Millises järjekorras ümber lülitada?
Kasvanud Plesk-serveris ei saa harva kõike ühe päevaga ümber lülitada. Riski järgi järjestamine aitab napi aja mõistlikult kasutada:
- Esmalt Apache mooduliga domeenid, sest seal on PHP2Shelli risk PHP meeskonna andmetel suurim ja Plesk soovitab sellest niikuinii loobuda.
- Seejärel tundlike andmetega domeenid, näiteks poed, kliendiportaalid või tervise- või lepinguandmetega vormid. Siin tasub oma pool eriti.
- Siis aegunud PHP versioonidega domeenid, mis tuleb niikuinii ümber lülitada. Handleri ja versiooni saab vahetada koos ühes hooldusaknas.
- Viimasena üleminek ühiselt poolilt oma poolile ülejäänud domeenide jaoks, kui serveri mälu seda lubab.
Kontrollige enne viimast etappi mälukasutust. Plesk juhib tähelepanu, et Dedicated FPM vajab rohkem mälu, ja soovitab paljude veebisaitide puhul jälgimist. Server, mis pärast ümberlülitust mälu välja saadab, muutub aeglaseks ning napp mälu ei ole eriti PHP2Shelli ajal hea seisund.
Kuidas PHP SOS konkreetselt aitab?
- Koostame ülevaate, millised domeenid teie Plesk-serveris millist handlerit kasutavad, ja märgime Apache mooduliga domeenid.
- Lülitame üle Dedicated FPM-ile ning kanname vajaduse korral
.htaccesskaitsereeglid nginxi seadistusse. - Seame üleminekuväärtused ja piirangud pooli kaupa ning kontrollime, et need veebikontekstis toimivad.
- Serveri karastamise raames deaktiveerime aegunud handlerid ja dokumenteerime seadistuse.
Korduma kippuvad küsimused
Millist PHP-handlerit Plesk soovitab?
Plesk dokumentatsiooni kohaselt on FPM soovitatav handler pühendatud Linuxi serverites, Dedicated FPM jagatud majutuse Linuxi serverites ja FastCGI Windowsi serverites. Apache moodulit, CGI-d ja ISAPI-t nimetab Plesk tugevalt aegunuks ehk ebaturvaliseks.
Miks on Apache mooduli handler pärast PHP2Shelli eriti kriitiline?
Handler vastab mod_php-le. PHP meeskond hindab PHP2Shelli riski mod_php puhul kõige suuremaks, sest seal näidati ekspluateerimist enne rakenduse koodi käivitumist. Lisaks soovitab Plesk ise sellest handlerist loobuda.
Mis muutub, kui PHP edastatakse nginxi, mitte Apache'i kaudu?
Plesk andmetel ignoreerivad nginxi kaudu edastatavad handlerid .htaccess-faili. Seal asuvad turvareeglid, näiteks PHP blokeerimine üleslaadimiskataloogides, ei toimi siis enam ja need tuleb üle kanda nginxi reeglitesse.
Kas pean pärast handleri vahetust PHP uuesti käivitama?
Kontrollige pärast vahetust, millised PHP protsessid domeeni jaoks töötavad ja alates millal. Dedicated FPM puhul saab domeen oma pooli. Vana protsess aegunud koodiga ei tohiks pärast seda domeeni jaoks enam töötada.
Kas Dedicated FPM on alati parim valik?
Eraldatuse mõttes jah, sest iga veebisait saab oma pooli. Hind on suurem mälukasutus. Plesk soovitab paljude veebisaitidega servereid seejuures jälgida.