Configurare Apache per PHP in sicurezza

In breve: per configurare Apache per PHP in sicurezza, colleghi PHP tramite PHP-FPM e mod_proxy_fcgi, disattivi .htaccess con AllowOverride None e imposti ServerTokens Prod, ServerSignature Off, TraceEnable Off e Options -Indexes. LimitRequestBody lo adatti ai limiti di PHP, i moduli non necessari li disattivi. La configurazione non sostituisce un aggiornamento di PHP, ma riduce nettamente la superficie d'attacco.

Apache dopo PHP2Shell: più di un riavvio

Nell'ottobre 2026 i gestori di Apache erano sotto una pressione particolare. Il team PHP classifica il rischio come il più alto per mod_php, perché lì è stato dimostrato un exploit prima ancora che giri il codice dell'applicazione. I passi urgenti, cioè applicare la patch e riavviare completamente, li descrive la pagina Perché mod_php comporta il rischio più alto.

Dopo la patch resta la domanda su quanto sia buona la configurazione di Apache stessa. I server cresciuti nel tempo portano spesso impostazioni di molti anni: elenchi di directory, permessi .htaccess aperti, moduli che nessuno usa più. Ognuna può rendere un errore successivo più grave di quanto dovrebbe.

Questo articolo descrive una configurazione di base snella e sicura per Apache 2.4 con PHP-FPM. Gli esempi usano percorsi Debian e Ubuntu; nella famiglia RHEL i file si trovano in /etc/httpd/.

Collegare PHP tramite PHP-FPM invece di mod_php

Con PHP-FPM, PHP gira in processi propri, separati dal server web. Apache inoltra le richieste tramite mod_proxy_fcgi. Secondo la documentazione di Apache, il collegamento tramite SetHandler ha un vantaggio rispetto a ProxyPassMatch: Apache assegna prima da sé la richiesta a un file nel file system e solo poi la passa a PHP-FPM.

<FilesMatch "\.php$">
    SetHandler "proxy:unix:/run/php/seite1.sock|fcgi://localhost/"
</FilesMatch>

I moduli li attivi su Debian e Ubuntu con a2enmod proxy_fcgi. Chi passa da mod_php disattiva il modulo PHP e poi passa dall'MPM prefork all'MPM event. Lo sfondo della vecchia modalità di esercizio lo spiega mod_php spiegato: PHP nel processo Apache.

Sul lato PHP-FPM, security.limit_extensions = .php va in ogni pool. Secondo il manuale PHP, altrimenti FPM esegue anche i file .phar.

Configurare Apache per PHP in sicurezza: le opzioni di base

Alcune impostazioni valgono per l'intero server e vanno in un file di configurazione proprio, ad esempio /etc/apache2/conf-available/haertung.conf, attivato con a2enconf haertung.

# Ridurre le indicazioni di versione (possibile solo a livello di server)
ServerTokens Prod
ServerSignature Off

# Disattivare il metodo TRACE
TraceEnable Off

# In linea di principio non abilitare nulla, consentire i siti in modo mirato
<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>

La tabella seguente inquadra le opzioni più importanti. Valori predefiniti ed effetto provengono dalla documentazione di Apache.

Importante per AllowOverride: molte distribuzioni e istruzioni per CMS impostano per il webroot AllowOverride All. Così ogni file .htaccess può modificare regole di rewrite, handler e, con mod_php, perfino impostazioni PHP. Un aggressore con permessi di scrittura in una cartella di upload può collocarvi un proprio .htaccess. Con AllowOverride None questa via è preclusa.

Un VirtualHost come modello

Il VirtualHost seguente riunisce i punti per un singolo sito. Percorsi dei certificati, socket e directory li adatti. mod_ssl e mod_headers devono essere attivi.

<VirtualHost *:443>
    ServerName www.example.de
    DocumentRoot /var/www/seite1/public

    SSLEngine on
    SSLCertificateFile    /etc/ssl/seite1/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/seite1/privkey.pem

    <Directory /var/www/seite1/public>
        Options -Indexes +SymLinksIfOwnerMatch
        AllowOverride None
        Require all granted
    </Directory>

    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/run/php/seite1.sock|fcgi://localhost/"
    </FilesMatch>

    # Bloccare controllo di versione e file di ambiente
    <DirectoryMatch "/\.(git|svn|hg)">
        Require all denied
    </DirectoryMatch>
    <FilesMatch "^\.env">
        Require all denied
    </FilesMatch>

    # 32 MiB, in linea con post_max_size = 32M
    LimitRequestBody 33554432

    Header unset X-Powered-By
    Header always unset X-Powered-By
</VirtualHost>

Il doppio Header unset non è una svista. Secondo la documentazione di Apache, gli header di mod_proxy_fcgi finiscono in una tabella interna diversa rispetto agli header del server stesso; con entrambe le varianti coglie entrambi i casi. Altri header che proteggono attivamente i visitatori li descrive la guida Header di sicurezza per i siti web.

Le cartelle di upload e di cache richiedono inoltre un blocco dell'esecuzione. Come trovare e bloccare tutte le cartelle scrivibili lo spiega Vietare l'esecuzione di PHP nelle cartelle di upload.

Sfoltire i moduli e verificare il risultato

Ogni modulo caricato è codice che reagisce alle richieste. Verifichi quali moduli sono attivi e disattivi ciò che non Le serve. Candidati tipici sono autoindex, status senza restrizioni di accesso, cgi e userdir.

# Mostrare i moduli attivi
apachectl -M | sort
# Esempio Debian/Ubuntu: disattivare il modulo degli elenchi di directory
sudo a2dismod autoindex
# Verificare la configurazione e solo dopo ricaricare
sudo apachectl configtest && sudo systemctl reload apache2
# Test dall'esterno: TRACE deve restituire 405, .git 403
curl -s -o /dev/null -w "%{http_code}\n" -X TRACE https://www.example.de/
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/.git/HEAD

mod_status merita particolare attenzione. La pagina di stato mostra le richieste in corso con indirizzi e percorsi richiamati. Se serve, limiti l'accesso con Require ip alle Sue reti di amministrazione. Lo stesso vale per le pagine di stato di PHP-FPM rese raggiungibili tramite Apache.

Come ulteriore livello davanti all'applicazione può avere senso una Web Application Firewall propria; l'introduzione è in Usare ModSecurity e OWASP Core Rule Set.

Conclusione: l'ordine batte la singola misura

Una configurazione Apache sicura per PHP consiste di pochi elementi ben compresi. PHP gira tramite PHP-FPM separato dal server web, .htaccess non viene valutato, indicazioni di versione e TRACE sono disattivati, i limiti di dimensione sono coerenti con PHP e le cartelle scrivibili non eseguono script. Nessuno di questi punti è di per sé spettacolare. Insieme fanno sì che un errore in un punto non porti subito alla presa di controllo del server.

Per direzione e responsabili di progetto, una seconda caratteristica è quasi più importante: una configurazione in ordine è comprensibile. Se tutte le regole stanno nel VirtualHost invece che sparse in decine di file .htaccess, alla prossima vulnerabilità critica si può verificare in fretta quale sito sia collegato come. In una situazione come quella dell'ottobre 2026 questo fa risparmiare proprio il tempo che conta.

Pianifichi comunque il passaggio con calma e con un ambiente di test. Un cambio affrettato da mod_php a PHP-FPM poco prima di un fine settimana crea più problemi di quanti ne risolva.

Come aiuta PHP SOS in concreto?

• Verificare lo stato: leggiamo l'intera configurazione di Apache, tutti i moduli attivi e tutti i file .htaccess.
• Pianificare il passaggio: dove gira ancora mod_php, prepariamo il passaggio a PHP-FPM con pool propri per sito.
• Rafforzare la configurazione: impostiamo le opzioni di base, riportiamo le regole .htaccess nei VirtualHost e blocchiamo le cartelle scrivibili.
• Testare e documentare: dopo ogni modifica verifichiamo i siti dall'esterno e annotiamo lo stato nell'ambito dell'hardening del server.

Domande frequenti

Fonti

• Apache: funzioni di base (core)
• Apache: mod_proxy_fcgi
• Apache: mod_headers
• php.net: avvisi di sicurezza