mod_php forklaret: PHP i Apache-processen

Kort sagt: mod_php er PHP som modul i Apache-webserveren. Hver Apache-proces indeholder så en komplet PHP-fortolker og udfører selv PHP-koden; SAPI'en hedder apache2handler. Det er enkelt at sætte op, men binder PHP til Apache, kræver som regel prefork-MPM og tillader næppe adskillelse mellem websites. PHP-manualen fraråder det til nye installationer, og ved PHP2Shell vurderer PHP-teamet risikoen ved mod_php som den højeste.

Hvad er mod_php?

Ved mod_php indlæser Apache PHP som eget modul i sine processer. Der findes ingen adskilt PHP-tjeneste: Når Apache skal levere en .php-fil, udfører den samme proces, som har modtaget forespørgslen, også PHP-koden. I mange år var det standardvejen til at drive PHP, og den er den dag i dag udbredt på ældre servere og i nogle Docker-images.

Ifølge PHP-manualen læser PHP som servermodul sin konfiguration kun én gang, når webserveren starter. Ændringer i php.ini og opdateringer af modulet virker derfor først efter en genstart af Apache.

Vigtigt for forståelsen: Apache-processer lever længe. En proces modtager mange forbindelser efter hinanden, før den erstattes; hvor mange, styrer Apache-direktivet MaxConnectionsPerChild. Den indlejrede PHP-fortolker forbliver i den tid den samme. Den, der udskifter biblioteket libphp på disken, ændrer intet ved de kørende processer.

For direktionen og projektansvarlige kan det opsummeres sådan: Ved mod_php er webserver og PHP én enhed. Den, der rører ved det ene, påvirker det andet. En PHP-opdatering betyder en genstart af webserveren, en fejl i PHP kører med webserverens rettigheder, og en adskillelse mellem flere websites på den samme server er næppe mulig.

Hvordan indbindes mod_php?

PHP-manualen viser indbindingen i to trin: indlæse modulet og fastlægge, hvilke filer PHP skal behandle.

LoadModule php_module modules/libphp.so

<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>

Manualen anbefaler FilesMatch med SetHandler frem for blot AddType, for at uploadede filer som bild.php.jpg ikke udføres som PHP. Under Debian og Ubuntu overtager pakker som libapache2-mod-php8.3 og kommandoerne a2enmod og a2dismod dette arbejde.

Om mod_php er aktivt, kan kontrolleres læsende:

apachectl -M 2>/dev/null | grep -i php    # Debian/Ubuntu
httpd -M 2>/dev/null | grep -i php        # RHEL-familien
apachectl -V | grep -i mpm               # aktivt MPM (prefork, worker, event)

Prefork, Thread Safety og ressourcer

Apache fordeler forespørgsler via et multi-processing-modul (MPM). Ifølge PHP-manualen kræver mod_php prefork-MPM, medmindre PHP er bygget med Zend Thread Safety (--enable-zts). De fleste distributionspakker er bygget uden Thread Safety.

Prefork betyder: én proces pr. samtidig forbindelse, og hver proces bærer en komplet PHP-fortolker. Også forespørgsler på billeder eller CSS-filer optager dermed en proces med PHP i bagagen. Det koster hukommelse og begrænser den belastning, en server kan bære.

Manualen anbefaler derfor til alle moderne installationer PHP-FPM med mod_proxy_fcgi: bedre ressourcestyring, procesadskillelse, genstart af PHP uden Apache-genstart og kompatibilitet med event-MPM, som siden Apache 2.4 er standard. Grundlaget står under PHP-FPM forklaret.

Indstillinger med .htaccess, php_value og php_admin_value

Med mod_php kan PHP-indstillinger sættes direkte i Apache-konfigurationen. Manualen skelner herved mellem ændringstilstande: Poster med INI_PERDIR må stå i php.ini, .htaccess eller httpd.conf, poster med INI_SYSTEM kun i php.ini eller httpd.conf.

# I VirtualHost-konfigurationen: låst for applikationen
php_admin_flag  display_errors off
php_admin_value upload_max_filesize 24M

# Muligt i .htaccess, men kan overskrives af applikationen
php_value max_execution_time 60

php_admin_value og php_admin_flag er kun tilladt i serverkonfigurationen, ikke i .htaccess. Netop denne skelnen er vigtig ved overgangsforanstaltningerne til PHP2Shell, fordi værdier som session.upload_progress.enabled ikke må kunne nulstilles af applikationen.

mod_php og PHP2Shell: hvorfor risikoen er højest

PHP-teamet vurderer risikoen ved PHP2Shell som højest for mod_php: Dér blev en exploit vist, før der overhovedet kører applikationskode. Sikkerhedsplugins eller kontroller i CMS'et kommer dermed for sent. Hertil kommer, at PHP ved mod_php kører med webserverens rettigheder og i dens hukommelse. Den udførlige vurdering står under Hvorfor mod_php bærer den højeste risiko.

For driftsansvarlige gælder derfor:

1. Opdatér PHP-modulet til 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 hhv. en bekræftet backport.
2. Genstart Apache fuldstændigt, ikke blot reload, og kontrollér processernes starttidspunkt.
3. Sæt overgangsværdier via php_admin_value i serverkonfigurationen, hvis opdateringen endnu ikke er mulig.
4. Planlæg derefter skiftet til PHP-FPM, som beskrevet under Sikring af Apache med mod_php.

Hvordan hjælper PHP SOS konkret?

• Genkende: Vi kontrollerer, på hvilke servere mod_php kører, med hvilket MPM og fra hvilken pakkekilde.
• Patche: Vi opdaterer PHP-modulet, genstarter Apache fuldstændigt og dokumenterer status.
• Sikre overgangen: Hvor opdateringen er blokeret, sætter vi foranstaltningerne fra php.net låst i serverkonfigurationen.
• Omstille: Som led i serverhærdningen migrerer vi testet til PHP-FPM med egne pools.

Ofte stillede spørgsmål

Kilder

• PHP-manualen: Apache 2 under Unix
• PHP-manualen: INI-ændringstilstande
• Apache-dokumentation
• php.net: Sikkerhedsmeddelelser