mod_php förklarat: PHP i Apache-processen

Kort sagt: mod_php är PHP som modul i Apache-webbservern. Varje Apache-process innehåller då en fullständig PHP-tolk och kör PHP-koden själv; SAPI:t heter apache2handler. Det är enkelt att installera men binder PHP till Apache, kräver oftast prefork-MPM och medger knappt någon åtskillnad mellan webbplatser. PHP-manualen avråder från det för nya installationer, och vid PHP2Shell bedömer PHP-teamet risken som högst vid mod_php.

Vad är mod_php?

Med mod_php laddar Apache PHP som egen modul i sina processer. Det finns ingen separat PHP-tjänst: När Apache ska leverera en .php-fil kör samma process som tog emot förfrågan också PHP-koden. Under många år var det standardsättet att driva PHP, och det är fortfarande utbrett på äldre servrar och i vissa Docker-avbilder.

Enligt PHP-manualen läser PHP som servermodul sin konfiguration bara en gång, vid webbserverns start. Ändringar i php.ini och uppdateringar av modulen verkar därför först efter en omstart av Apache.

Viktigt för förståelsen: Apache-processer lever länge. En process tar emot många anslutningar efter varandra innan den ersätts; hur många styr Apache-direktivet MaxConnectionsPerChild. Den inbyggda PHP-tolken förblir under tiden densamma. Den som byter ut biblioteket libphp på disken ändrar ingenting i de pågående processerna.

För ledning och projektansvariga kan det sammanfattas så: Med mod_php är webbserver och PHP en enhet. Den som rör det ena påverkar det andra. En PHP-uppdatering innebär en omstart av webbservern, ett fel i PHP körs med webbserverns rättigheter, och en åtskillnad mellan flera webbplatser på samma server är knappt möjlig.

Hur kopplas mod_php in?

PHP-manualen visar inkopplingen i två steg: ladda modulen och bestämma vilka filer PHP ska bearbeta.

LoadModule php_module modules/libphp.so

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

Manualen rekommenderar FilesMatch med SetHandler i stället för bara AddType, så att uppladdade filer som bild.php.jpg inte körs som PHP. Under Debian och Ubuntu sköter paket som libapache2-mod-php8.3 och kommandona a2enmod och a2dismod det arbetet.

Om mod_php är aktivt kan kontrolleras enbart läsande:

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

Prefork, Thread Safety och resurser

Apache fördelar förfrågningar via en multi-processing-modul (MPM). Enligt PHP-manualen kräver mod_php prefork-MPM, om inte PHP har byggts med Zend Thread Safety (--enable-zts). De flesta distributionspaket är byggda utan Thread Safety.

Prefork betyder: en process per samtidig anslutning, och varje process bär en komplett PHP-tolk. Även förfrågningar efter bilder eller CSS-filer upptar alltså en process med PHP i bagaget. Det kostar minne och begränsar den belastning en server kan bära.

Manualen rekommenderar därför för alla moderna installationer PHP-FPM med mod_proxy_fcgi: bättre resurshantering, processåtskillnad, omstart av PHP utan omstart av Apache och kompatibilitet med event-MPM, som är standard sedan Apache 2.4. Grunderna står under PHP-FPM förklarat.

Inställningar med .htaccess, php_value och php_admin_value

Med mod_php kan PHP-inställningar sättas direkt i Apache-konfigurationen. Manualen skiljer därvid mellan ändringslägen: Poster med INI_PERDIR får stå i php.ini, .htaccess eller httpd.conf, poster med INI_SYSTEM bara i php.ini eller httpd.conf.

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

# Möjligt i .htaccess, men kan skrivas över av applikationen
php_value max_execution_time 60

php_admin_value och php_admin_flag är bara tillåtna i serverkonfigurationen, inte i .htaccess. Just den här skillnaden är viktig för övergångsåtgärderna kring PHP2Shell, eftersom värden som session.upload_progress.enabled inte får kunna återställas av applikationen.

mod_php och PHP2Shell: varför risken är högst

PHP-teamet bedömer risken från PHP2Shell som högst vid mod_php: Där visades en exploit innan någon applikationskod alls körs. Säkerhetsplugin eller kontroller i CMS:et kommer därmed för sent. Dessutom körs PHP vid mod_php med webbserverns rättigheter och i webbserverns minne. Den utförliga bedömningen står under Varför mod_php bär den högsta risken.

För driftansvariga gäller därför:

1. Uppdatera PHP-modulen till 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 respektive en bekräftad backport.
2. Starta om Apache fullständigt, inte bara ladda om, och kontrollera processernas starttid.
3. Sätt övergångsvärden med php_admin_value i serverkonfigurationen om uppdateringen ännu inte är möjlig.
4. Planera därefter bytet till PHP-FPM, som beskrivs under Säkra Apache med mod_php.

Hur hjälper PHP SOS konkret?

• Känna igen: Vi kontrollerar på vilka servrar mod_php körs, med vilket MPM och från vilken paketkälla.
• Patcha: Vi uppdaterar PHP-modulen, startar om Apache fullständigt och styrker läget.
• Säkra övergången: Där uppdateringen är blockerad sätter vi åtgärderna från php.net låsta i serverkonfigurationen.
• Ställa om: Inom ramen för serverhärdning migrerar vi testat till PHP-FPM med egna pooler.

Vanliga frågor

Källor

• PHP-manualen: Apache 2 under Unix
• PHP-manualen: INI-ändringslägen
• Apache-dokumentationen
• php.net: säkerhetsmeddelanden