Con Apache gli script PHP possono essere interpretati essenzialmente in due modi: attraverso un modulo apposito (mod_php) o richiamando l’interprete PHP con FastCGI.
In molti casi si utilizza mod_php perché è l’opzione di default preconfigurata, ma ci sono delle alternative, con vantaggi e svantaggi che vanno valutati con attenzione.
mod_php è in genere (ma anche qui ci potrebbero essere eccezioni) più veloce e permette di personalizzare alcune direttive di configurazione all’interno del file .htacess; il rovescio della medaglia è che l’interprete PHP viene caricato assieme ad ogni istanza di Apache, anche quando non serve perché viene richiesto un file di testo o un file con un’immagine, e viene eseguito nel suo stesso contesto di sicurezza.
Utilizzando FastCGI il codice eseguito dall’interprete PHP è completamente separato da quello del web server, quindi si può definire un contesto di sicurezza differente da quello utilizzato dal server e l’interprete viene eseguito solamente quando è necessario. Nel 2012 è stata scoperta una vulnerabilità di PHP eseguito via CGI tale per cui richiamando una pagina mettendo nell’URL ?-s (esempio: http://www.example.com/index.php?-s) viene visualizzato il sorgente dello script al posto del risultato. Il baco è stato corretto, ma vale la pena di eseguire un test se si passa da mod_php a FastCGI.
Dalla versione 5.3 PHP ha introdotto FastCGI Process Manager (FPM), una tecnologia per demonizzare l’interprete PHP e richiamarlo da server HTTP differenti anche, volendo, da host diversi. FPM crea uno o più pool di server, ciascuno con un proprio contesto di sicurezza e una propria configurazione, in questo modo il numero di worker che interpretano il codice PHP può essere diverso dai worker del server HTTP.
Vediamo come passare da mod_php a FPM su un’installazione CentOS 6.