Plesk: Forstå PHP-handlere (FPM, FastCGI, Apache-modul)

Kort sagt: Plesk PHP-handleren fastlægger, hvordan PHP kører for et website: som FPM-applikation med fælles pool, som Dedicated FPM med egen pool pr. website, som FastCGI-applikation eller som Apache-modul (mod_php). Set med sikkerhedsøjne er Dedicated FPM under Linux som regel det bedste valg, Apache-modulet det dårligste. Plesk betegner det selv som forældet henholdsvis usikkert, og ved PHP2Shell ser PHP-teamet den højeste risiko netop ved mod_php.

Hvorfor handleren er mere end et ydelsesspørgsmål

I Plesk vælger I for hvert website en PHP-version og en handler. Mange behandler handleren som en detalje for ydelse og hukommelse. Men den afgør også, hvor stærkt websites er adskilt fra hinanden, hvor sikkerhedsindstillinger virker, og hvilke processer der skal genstartes efter en opdatering.

Efter PHP2Shell bliver dette valg konkret. Sårbarhederne CVE-2026-109618 og CVE-2026-109619 berører alle gængse driftsformer, men PHP-teamet vurderer risikoen ved mod_php som højest. Den, der på sin Plesk-server stadig driver domæner med Apache-modulet, bør ændre det nu. Hvordan I kontrollerer og patcher versioner, beskriver siden Plesk-server: Kontrollér og patch PHP-versioner; her handler det om valget af driftsform.

Plesk PHP-handlerne i overblik

Følgende oversigt bygger på Plesk-dokumentationen til Plesk Obsidian, suppleret med sikkerhedssynspunktet. Under Linux kan FPM-handlere ifølge Plesk efter valg leveres via Apache eller nginx, FastCGI altid via Apache.

Baggrunden for selve driftsformerne forklarer siderne PHP-FPM forklaret og Hvorfor mod_php bærer den højeste risiko.

Fælles eller egen pool?

Forskellen på FPM og Dedicated FPM undervurderes ofte. Ved den almindelige FPM-handler deler ifølge Plesk alle websites med samme PHP-version en procespool. Det sparer hukommelse, men betyder også: Et website, der giver problemer, kan rive alle andre med samme version med sig, og den fælles cache deles.

Dedicated FPM giver hvert website en egen pool. Ifølge Plesk forbedrer det isolation og ydelse, men koster mere hukommelse. Set med sikkerhedsøjne er den egne pool grundlaget for at sætte indstillinger som open_basedir, hukommelsesgrænser eller uploadgrænser adskilt pr. website. Hvordan I konsekvent adskiller pools, beskriver indlægget Isolér PHP-FPM-pools pr. website.

nginx eller Apache: .htaccess-fælden

Vælger I en handler, der leveres via nginx, ændrer noget grundlæggende sig: Ifølge Plesk ignorerer disse handlere .htaccess-filen. Det, der står dér, virker ikke længere.

Det er et sikkerhedsspørgsmål. Mange applikationer og administratorer lægger beskyttelsesregler i .htaccess, f.eks. et forbud mod at udføre PHP-filer i upload-mapper eller spærringer af konfigurationsfiler. Efter et skifte til nginx er disse regler stille sat ud af kraft. Kontrollér derfor før skiftet, hvilke beskyttelsesregler der står i .htaccess, og overfør dem til domænets nginx-konfiguration.

Kontrollér og omstil handleren

Først skaffer I jer overblik over, hvilke domæner der bruger hvilken handler. Kommandoerne er rent læsende.

# Alle registrerede handlere med ID, version og type
plesk bin php_handler --list

# Domæner, der bruger en bestemt handler (ID fra listen)
plesk bin php_handler --get-usage -id <handler-id>

# Kører PHP i Apache-processen? (Debian/Ubuntu: apache2ctl, RHEL-familien: httpd)
apache2ctl -M 2>/dev/null | grep -i php

Til omstillingen går I frem domæne for domæne:

1. Registrér beskyttelsesregler fra .htaccess, hvis den nye handler leveres via nginx.
2. Sæt overgangsværdier mod PHP2Shell, f.eks. session.upload_progress.enabled=0, for den nye handler. Ved FPM hører de som php_admin_value hjemme i poolens yderligere direktiver, ved FastCGI virker andre veje.
3. Skift handler i domænets PHP-indstillinger, helst først på en kopi.
4. Test funktionerne, og kontrollér, om domænet betjenes af processer med aktuel kode.
5. Bruges Apache-modulet ikke længere af noget domæne, så deaktivér handleren.

I hvilken rækkefølge skal der omstilles?

På en gammel, organisk vokset Plesk-server kan sjældent alt omstilles på én dag. En rækkefølge efter risiko hjælper med at bruge den knappe tid fornuftigt:

• Først domæner med Apache-modulet, for dér er risikoen ved PHP2Shell ifølge PHP-teamet højest, og Plesk fraråder det under alle omstændigheder.
• Dernæst domæner med følsomme data, f.eks. shops, kundeportaler eller formularer med sundheds- eller kontraktdata. Her er den egne pool særligt umagen værd.
• Derefter domæner på gamle PHP-versioner, som alligevel skal omstilles. Handler og version kan skiftes sammen i et vedligeholdelsesvindue.
• Til sidst skiftet fra fælles til egen pool for de øvrige domæner, hvis serverens hukommelse tillader det.

Kontrollér hukommelsesbelastningen før det sidste trin. Plesk gør opmærksom på, at Dedicated FPM kræver mere hukommelse, og anbefaler overvågning ved mange websites. En server, der efter omstillingen swapper, bliver langsom, og knap hukommelse er netop ved PHP2Shell ikke nogen god tilstand.

Hvordan hjælper PHP SOS konkret?

• Vi registrerer, hvilke domæner på jeres Plesk-server der bruger hvilken handler, og markerer domæner med Apache-modul.
• Vi omstiller til Dedicated FPM og overfører beskyttelsesregler fra .htaccess til nginx-konfigurationen, hvor det er nødvendigt.
• Vi sætter overgangsværdier og grænser pr. pool og kontrollerer, at de virker i webkonteksten.
• Som led i serverhærdningen deaktiverer vi forældede handlere og dokumenterer konfigurationen.

Ofte stillede spørgsmål

Kilder

• Plesk-dokumentation: Choosing the PHP Handler
• Plesk-dokumentation: php_handler
• php.net: Sikkerhedsmeddelelser