In breve: mod_php è PHP come modulo nel server web Apache. Ogni processo Apache contiene allora un interprete PHP completo ed esegue da solo il codice PHP; la SAPI si chiama apache2handler. È semplice da configurare, ma lega PHP ad Apache, richiede di solito il MPM prefork e consente a stento la separazione tra siti web. Il manuale PHP lo sconsiglia per le nuove installazioni e con PHP2Shell il team PHP classifica per mod_php il rischio più alto.
Che cos'è mod_php?
Con mod_php Apache carica PHP come modulo proprio nei suoi processi. Non esiste un servizio PHP separato: quando Apache deve consegnare un file .php, lo stesso processo che ha accettato la richiesta esegue anche il codice PHP. Per molti anni è stato il modo standard di gestire PHP ed è tuttora diffuso sui server meno recenti e in alcune immagini Docker.
Secondo il manuale PHP, come modulo del server PHP legge la propria configurazione una sola volta, all'avvio del server web. Le modifiche al php.ini e gli aggiornamenti del modulo hanno quindi effetto solo dopo un riavvio di Apache.
Importante per capire: i processi Apache vivono a lungo. Un processo accetta una dopo l'altra molte connessioni prima di essere sostituito; quante lo regola la direttiva Apache MaxConnectionsPerChild. L'interprete PHP incorporato in questo periodo resta lo stesso. Chi sostituisce sul disco la libreria libphp non cambia nulla nei processi in esecuzione.
Per la direzione e i responsabili di progetto si può riassumere così: con mod_php server web e PHP sono un'unità. Chi tocca l'uno coinvolge l'altro. Un aggiornamento di PHP significa un riavvio del server web, un errore in PHP gira con i permessi del server web e una separazione tra più siti web sullo stesso server è appena possibile.
Come si integra mod_php?
Il manuale PHP mostra l'integrazione in due passaggi: caricare il modulo e stabilire quali file PHP debba elaborare.
LoadModule php_module modules/libphp.so
<FilesMatch \.php$>
SetHandler application/x-httpd-php
</FilesMatch>
Il manuale raccomanda FilesMatch con SetHandler invece del solo AddType, in modo che file caricati come bild.php.jpg non vengano eseguiti come PHP. Su Debian e Ubuntu pacchetti come libapache2-mod-php8.3 e i comandi a2enmod e a2dismod svolgono questo lavoro.
Se mod_php sia attivo si può verificare in sola lettura:
apachectl -M 2>/dev/null | grep -i php # Debian/Ubuntu
httpd -M 2>/dev/null | grep -i php # famiglia RHEL
apachectl -V | grep -i mpm # MPM attivo (prefork, worker, event)
Prefork, Thread Safety e risorse
Apache distribuisce le richieste tramite un modulo di multi-processing (MPM). Secondo il manuale PHP, mod_php richiede il MPM prefork, a meno che PHP non sia stato compilato con Zend Thread Safety (--enable-zts). La maggior parte dei pacchetti delle distribuzioni è compilata senza Thread Safety.
Prefork significa: un processo per connessione simultanea, e ogni processo porta con sé un interprete PHP completo. Anche le richieste di immagini o file CSS occupano così un processo con PHP al seguito. Ciò costa memoria e limita il carico che un server può sostenere.
| Caratteristica | mod_php | PHP-FPM |
|---|---|---|
| Dove gira PHP? | in ogni processo Apache | in un servizio proprio |
| MPM di Apache | di solito prefork |
event possibile |
| Utente per ogni sito | no, tutto come utente Apache | sì, per ogni pool |
| Riavviare PHP | solo con Apache | indipendente da Apache |
| Impostazioni per directory | php_value in .htaccess |
pool o .user.ini |
Il manuale raccomanda perciò per tutte le installazioni moderne PHP-FPM con mod_proxy_fcgi: migliore gestione delle risorse, separazione dei processi, riavvio di PHP senza riavviare Apache e compatibilità con il MPM event, che è lo standard da Apache 2.4. Le basi sono in PHP-FPM spiegato.
Impostazioni con .htaccess, php_value e php_admin_value
Con mod_php le impostazioni PHP si possono definire direttamente nella configurazione di Apache. Il manuale distingue qui le modalità di modifica: le voci con INI_PERDIR possono stare in php.ini, .htaccess o httpd.conf, quelle con INI_SYSTEM solo in php.ini o httpd.conf.
# Nella configurazione del VirtualHost: bloccato per l'applicazione
php_admin_flag display_errors off
php_admin_value upload_max_filesize 24M
# Possibile in .htaccess, ma sovrascrivibile dall'applicazione
php_value max_execution_time 60
php_admin_value e php_admin_flag sono consentiti solo nella configurazione del server, non in .htaccess. Proprio questa distinzione è importante per le misure transitorie contro PHP2Shell, perché valori come session.upload_progress.enabled non devono poter essere reimpostati dall'applicazione.
mod_php e PHP2Shell: perché il rischio è il più alto
Il team PHP classifica per mod_php il rischio maggiore legato a PHP2Shell: lì è stato dimostrato un exploit prima ancora che giri qualsiasi codice dell'applicazione. I plugin di sicurezza o i controlli nel CMS arrivano quindi troppo tardi. Si aggiunge che con mod_php PHP gira con i permessi e nella memoria del server web. La classificazione dettagliata è in Perché mod_php porta il rischio più alto.
Per chi gestisce i sistemi vale perciò:
- Aggiornare il modulo PHP a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 oppure a un backport confermato.
- Riavviare Apache completamente, non solo ricaricarlo, e controllare l'ora di avvio dei processi.
- Impostare i valori transitori tramite
php_admin_valuenella configurazione del server, se l'aggiornamento non è ancora possibile. - Poi pianificare il passaggio a PHP-FPM, come descritto in Mettere in sicurezza Apache con mod_php.
Come aiuta concretamente PHP SOS?
- Riconoscere: verifichiamo su quali server gira mod_php, con quale MPM e da quale repository di pacchetti.
- Aggiornare: aggiorniamo il modulo PHP, riavviamo Apache completamente e documentiamo lo stato.
- Mettere in sicurezza la fase transitoria: dove l'aggiornamento è bloccato, impostiamo le misure di php.net in forma bloccata nella configurazione del server.
- Migrare: nell'ambito dell'hardening del server migriamo, con test, a PHP-FPM con pool propri.
Domande frequenti
Perché si chiama mod_php se il modulo si chiama php_module?
mod_php è il nome colloquiale di PHP come modulo Apache. Nella configurazione viene caricato con LoadModule; il manuale PHP cita come esempio LoadModule php_module modules/libphp.so. Le versioni più vecchie usavano nomi come php7_module o php5_module.
Perché mod_php richiede il MPM prefork?
Secondo il manuale PHP, mod_php richiede il MPM prefork, a meno che PHP non sia stato compilato con Zend Thread Safety. La maggior parte dei pacchetti delle distribuzioni è compilata senza Thread Safety. Prefork avvia un processo proprio per ogni connessione simultanea, il che richiede più memoria.
Le righe php_value in .htaccess funzionano anche con PHP-FPM?
No. php_value e php_flag in .htaccess sono direttive Apache del modulo PHP e hanno effetto solo con mod_php. Con PHP-FPM tali impostazioni vanno nel pool oppure, per i valori consentiti, in un .user.ini.
Devo abbandonare subito mod_php?
Prima viene l'aggiornamento di PHP con riavvio completo di Apache. Il passaggio a PHP-FPM è sensato dopo, ma va pianificato e testato. Non chiude PHP2Shell, perché anche PHP-FPM è interessato.