# Plesk: PHP-handlerien ymmärtäminen (FPM, FastCGI, Apache-moduuli) > Plesk PHP-handlerit vertailussa: FPM, Dedicated FPM, FastCGI ja Apache-moduuli tietoturvan kannalta, huomioita PHP2Shellistä, nginxistä ja .htaccessista. Lähde: https://phpsos.de/fi/blog/plesk-php-handler/ Tilanne: 25.10.2026 Palveluntarjoaja: PHP SOS, PHP-hätäapu ja palvelimen tietoturva. Pikaapu WhatsAppilla: https://wa.me/491736494914?text=Hei%20PHP%20SOS%2C%20tarvitsemme%20apua%20PHP-palvelimemme%20kanssa.%20Yritys%3A%20%E2%80%A6%20Verkkosivusto%3A%20%E2%80%A6 **Lyhyesti:** Pleskin PHP-handler määrää, miten PHP toimii verkkosivustolle: FPM-sovelluksena yhteisellä poolilla, Dedicated FPM:nä omalla poolilla sivustoa kohti, FastCGI-sovelluksena tai Apache-moduulina (mod_php). Tietoturvan kannalta Dedicated FPM on Linuxissa yleensä paras valinta ja Apache-moduuli huonoin. Plesk itse kuvaa sen vanhentuneeksi tai turvattomaksi, ja PHP2Shellissä PHP-tiimi näkee suurimman riskin juuri mod_php:ssä. ## Miksi handler on muutakin kuin suorituskykykysymys Pleskissä valitsette jokaiselle verkkosivustolle PHP-version ja handlerin. Monet pitävät handleria suorituskyvyn ja muistin yksityiskohtana. Se ratkaisee kuitenkin myös sen, kuinka vahvasti verkkosivustot on erotettu toisistaan, missä tietoturva-asetukset vaikuttavat ja mitkä prosessit on päivityksen jälkeen käynnistettävä uudelleen. PHP2Shellin jälkeen tämä valinta käy konkreettiseksi. Aukot CVE-2026-109618 ja CVE-2026-109619 koskevat kaikkia yleisiä ajotapoja, mutta PHP-tiimi arvioi riskin suurimmaksi mod_php:ssä. Jos Plesk-palvelimellanne on yhä domaineja, jotka käyttävät Apache-moduulia, se kannattaa muuttaa nyt. Miten versiot tarkistetaan ja korjataan, kuvaa sivu [Plesk-palvelin: PHP-versioiden tarkistus ja korjaus](https://phpsos.de/fi/server/plesk/); tässä käsitellään ajotavan valintaa. ## Pleskin PHP-handlerit yleiskatsauksena Seuraava yleiskatsaus perustuu Plesk Obsidianin dokumentaatioon, täydennettynä tietoturvanäkökulmalla. Linuxissa FPM-handlerit voidaan Pleskin mukaan tarjota valinnaisesti Apachen tai nginxin kautta, FastCGI aina Apachen kautta. | Handler | Tarjotaan | Erottelu | Suositus Pleskin mukaan | Tietoturvanäkökulma | |---|---|---|---|---| | Dedicated FPM application | Apache tai nginx | oma pooli sivustoa kohti | Linux jaetussa hostingissa | paras erottelu, omat arvot poolia kohti | | FPM application | Apache tai nginx | yhteinen pooli PHP-versiota kohti | dedikoidut Linux-palvelimet | virheellinen sivusto voi häiritä muita samaa versiota käyttäviä | | FastCGI application | Apache (Linux) | pysyvät prosessit, hyvä erottelu | Windows-palvelimet | luotettava, Linuxissa FPM on yleensä korvannut sen | | Apache module (mod_php) | Apache | PHP verkkopalvelimen prosessissa | ei suositella | suurin PHP2Shell-riski PHP-tiimin mukaan | | CGI application | Apache | uusi prosessi pyyntöä kohti | ei suositella | vanhentunut | Itse ajotapojen taustoja selittävät sivut [PHP-FPM selitettynä](https://phpsos.de/fi/php/php-fpm-erklaert/) ja [Miksi mod_php kantaa suurimman riskin](https://phpsos.de/fi/php2shell/mod-php-risiko/). ## Yhteinen vai oma pooli? FPM:n ja Dedicated FPM:n eroa aliarvioidaan usein. Tavallisessa FPM-handlerissa kaikki samaa PHP-versiota käyttävät verkkosivustot jakavat Pleskin mukaan yhden prosessipoolin. Se säästää muistia, mutta tarkoittaa myös: ongelmia aiheuttava sivusto voi vetää mukanaan kaikki muut samaa versiota käyttävät, ja yhteinen välimuisti jaetaan. Dedicated FPM antaa jokaiselle verkkosivustolle oman poolin. Pleskin mukaan se parantaa erottelua ja suorituskykyä mutta vie enemmän muistia. Tietoturvan kannalta oma pooli on perusta sille, että asetukset kuten `open_basedir`, muistirajat tai upload-rajat voi asettaa sivustokohtaisesti. Miten poolit erotetaan johdonmukaisesti, kuvaa artikkeli [PHP-FPM-poolien erottaminen sivustoittain](https://phpsos.de/fi/blog/php-fpm-pools-isolieren/). ## nginx vai Apache: .htaccess-ansa Jos valitsette handlerin, joka tarjotaan nginxin kautta, jokin perustavanlaatuinen muuttuu: Pleskin mukaan nämä handlerit ohittavat `.htaccess`-tiedoston. Sen sisältö ei enää vaikuta. Tämä on tietoturvakysymys. Monet sovellukset ja ylläpitäjät tallentavat suojasääntöjä `.htaccess`-tiedostoon, esimerkiksi kiellon ajaa PHP-tiedostoja upload-kansioissa tai asetustiedostojen estot. Nginxiin siirryttäessä nämä säännöt lakkaavat äänettömästi vaikuttamasta. Tarkistakaa siksi ennen vaihtoa, mitä suojasääntöjä `.htaccess`-tiedostossa on, ja siirtäkää ne domainin nginx-konfiguraatioon. > **Tärkeää:** > Handlerin vaihto on muutos tietoturvakonfiguraatioon. Testatkaa sen jälkeen kohdennetusti, ovatko estetyt polut yhä estettyinä, eikä vain sitä, latautuuko etusivu. ## Handlerin tarkistus ja vaihto Ensin selvitätte, mitkä domainit käyttävät mitäkin handleria. Komennot vain lukevat. ```bash # Kaikki rekisteröidyt handlerit tunnuksen, version ja tyypin kanssa plesk bin php_handler --list # Domainit, jotka käyttävät tiettyä handleria (tunnus luettelosta) plesk bin php_handler --get-usage -id # Toimiiko PHP Apache-prosessissa? (Debian/Ubuntu: apache2ctl, RHEL-perhe: httpd) apache2ctl -M 2>/dev/null | grep -i php ``` Vaihdon teette domain kerrallaan: 1. Kirjatkaa `.htaccess`-tiedoston suojasäännöt ylös, jos uusi handler tarjotaan nginxin kautta. 2. Asettakaa PHP2Shell-väliaikaisarvot, esimerkiksi `session.upload_progress.enabled=0`, uudelle handlerille. FPM:ssä ne kuuluvat `php_admin_value`-direktiivinä poolin lisädirektiiveihin, FastCGI:ssä vaikuttavat muut tavat. 3. Vaihtakaa handler domainin PHP-asetuksissa, mieluiten ensin kopiolla. 4. Testatkaa toiminnot ja tarkistakaa, palvelevatko domainia prosessit, joissa on ajantasainen koodi. 5. Jos mikään domain ei enää käytä Apache-moduulia, poistakaa handler käytöstä. ## Missä järjestyksessä siirtyä? Vuosien mittaan kasvaneella Plesk-palvelimella kaikkea harvoin ehtii vaihtaa yhdessä päivässä. Riskin mukainen järjestys auttaa käyttämään niukan ajan järkevästi: - **Ensin domainit, joilla on Apache-moduuli**, sillä siellä PHP2Shellin riski on PHP-tiimin mukaan suurin ja Plesk ei muutenkaan suosittele sitä. - **Sitten domainit, joilla on arkaluonteista dataa**, esimerkiksi verkkokaupat, asiakasportaalit tai terveys- tai sopimustietoja sisältävät lomakkeet. Oma pooli kannattaa erityisesti täällä. - **Sen jälkeen domainit vanhoilla PHP-versioilla**, jotka on joka tapauksessa vaihdettava. Handlerin ja version voi vaihtaa yhdessä huoltoikkunassa. - **Viimeisenä siirto yhteisestä omaan pooliin** muille domaineille, jos palvelimen muisti sen sallii. Tarkistakaa muistin käyttö ennen viimeistä vaihetta. Plesk huomauttaa, että Dedicated FPM tarvitsee enemmän muistia, ja neuvoo seuraamaan tilannetta, kun sivustoja on paljon. Palvelin, joka vaihdon jälkeen alkaa käyttää muistin vaihtoa levylle, hidastuu, ja niukka muisti ei ole PHP2Shellin kohdalla hyvä tila. ## Miten PHP SOS auttaa konkreettisesti? - Selvitämme, mitkä domainit Plesk-palvelimellanne käyttävät mitäkin handleria, ja merkitsemme domainit, joilla on Apache-moduuli. - Siirrämme Dedicated FPM:ään ja siirrämme `.htaccess`-tiedoston suojasäännöt nginx-konfiguraatioon tarvittaessa. - Asetamme väliaikaisarvot ja rajat poolikohtaisesti ja tarkistamme, että ne vaikuttavat verkkokontekstissa. - [Palvelimen koventamisen](https://phpsos.de/fi/leistungen/server-haertung/) puitteissa poistamme vanhentuneet handlerit käytöstä ja dokumentoimme konfiguraation. ## Usein kysytyt kysymykset **Mitä PHP-handleria Plesk suosittelee?** Plesk-dokumentaation mukaan FPM on suositeltu handler dedikoiduilla Linux-palvelimilla, Dedicated FPM Linux-palvelimilla jaetussa hostingissa ja FastCGI Windows-palvelimilla. Apache-moduulin, CGI:n ja ISAPI:n Plesk kuvaa vahvasti vanhentuneiksi tai turvattomiksi. **Miksi Apache-moduuli-handler on PHP2Shellin jälkeen erityisen kriittinen?** Handler vastaa mod_php:tä. PHP-tiimi arvioi PHP2Shellin riskin suurimmaksi mod_php:ssä, koska siinä on esitetty hyökkäys, joka toimii ennen kuin sovelluskoodia ajetaan. Lisäksi Plesk itse ei suosittele tätä handleria. **Mikä muuttuu, jos PHP tarjotaan nginxin eikä Apachen kautta?** Pleskin mukaan nginxin kautta tarjottavat handlerit ohittavat .htaccess-tiedoston. Siellä olevat turvasäännöt, esimerkiksi PHP:n esto upload-kansioissa, eivät enää toimi, ja ne on siirrettävä nginx-sääntöihin. **Pitääkö PHP käynnistää uudelleen handlerin vaihdon jälkeen?** Tarkistakaa vaihdon jälkeen, mitkä PHP-prosessit ovat käynnissä domainille ja mistä lähtien. Dedicated FPM:ssä domain saa oman poolin. Vanhan koodin sisältävän prosessin ei pitäisi sen jälkeen enää palvella domainia. **Onko Dedicated FPM aina paras valinta?** Erottelun kannalta kyllä, sillä jokainen verkkosivusto saa oman poolin. Hintana on suurempi muistinkulutus. Plesk neuvoo seuraamaan palvelimia, joilla on paljon verkkosivustoja. ## Lähteet - [Plesk-dokumentaatio: Choosing the PHP Handler](https://docs.plesk.com/en-US/obsidian/administrator-guide/75145/) - [Plesk-dokumentaatio: php_handler](https://docs.plesk.com/en-US/obsidian/cli-linux/using-command-line-utilities/php_handler-php-handlers.72490/) - [php.net: tietoturvailmoitukset](https://www.php.net/)