PHP è la tecnologia che sottende all'esecuzione di codice server-side ed alla creazione delle pagine HTML che saranno inviate dal Web server (Apache) al client (browser come Firefox, Opera, IE) conformemente al protocollo HTTP.
Nella maggioranza dei casi a subire exploit non sono i Web server in senso stretto, ma le applicazioni (soprattutto Web) che grazie ad esso vengono eseguite. In questo scenario, se l'applicazione non è sicura, avere firewall ben impostati, sistemi Linux ad hoc configurati e via discorrendo non serve assolutamente a nulla (o quasi), al fine della protezione dai cracker.
Si dà in questa sede per scontata una buona e robusta progettazione del programma Web PHP in esecuzione sul server e suggerisco la Guida sicurezza di PHP pubblicata su Html.it come prima (ma non sufficiente) e semplice illustrazione delle tecniche da usarsi.
Bene. Avendo quindi installato nella directory www di Apache il programma PHP ci occuperemo ora di:
- verificare la corretta installazione dell'interprete PHP (come modulo di Apache);
- rendere più sicura l'installazione stessa del modulo: definiremo un comportamento globale "corretto" di PHP, attraverso il file
Php.ini; - testare l'effettiva sicurezza del/i programma/i attraverso strumenti software opportuni;
- infine, rendere gli script PHP sia più veloci ad esser interpretati che al riparo da "occhi indiscreti".
Ciò è utile al fine di preservare la proprietà intellettuale dell'autore in caso di furto dei sorgenti ed al fine di nascondere le password contenute (in chiaro) negli script.
Esistono anche tool per creare, da script PHP, programmi standalone (compilati), che però non tratteremo.
Corretta installazione dell'interprete
Una corretta installazione del modulo PHP protegge sia dallo sfruttamento di possibili bug di moduli aggiuntivi ("se non c'è non si rompe") sia da denial of service (DoS) del programma o modifica dei servizi attraverso la manomissione del file php.ini o di componenti fondamentali per il funzionamento di PHP, ad opera di utenti (reali o virtuali, quindi programmi bucati) interni.
A meno di necessità particolari, non devono esser installati sul server moduli PHP non usati (es.: modulo per database PostgreSQL, modulo GD,...) né la versione cli dello stesso.
Verifichiamo quanto installato tramite il gestore di pacchetti Synaptic (grafico) o, sempre come root, da shell tramite il comando:
dpkg -l | grep php libapache2-mod-php5 5.1.6-1 php5-cli 5.1.6-1 php5-common 5.1.6-1 php5-mysql 5.1.6-1
In questo caso, ad esempio, possiamo disinstallare il pacchetto php5-cli sempre tramite Synaptic (con l'opzione "marca per la rimozione completa") o via shell:
apt-get remove php5-cli
seguito da:
dpkg --purge php5-cli
in modo da rimuovere anche i file di configurazione.
Nessuno tra i moduli disinstallati dovrà essere richiamato dal file php.ini cosa che il processo di disinstallazione dovrebbe già provvedere a fare.
A "pulizia di primavera" completata, dobbiamo ora semplicemente assicurarci che il file php.ini non sia modificabile da tutti gli utenti del sistema; di default, il proprietario è root (che vi ha permessi rw) ed i rimanenti permessi sono solo in lettura per tutti gli altri. Sse così non fossero, è bene impostarli in tal maniera o, alternativamente, fare appartenere il file all'utente con cui gira il Web server e renderlo leggibile e scrivibile solo a questi, logica che Debian però non usa.
Verifichiamo ora i permessi del file, da shell con il comando
ls -l /etc/php5/apache2/php.ini -rw-r--r-- 1 [644] root root
Infine, i moduli PHP in /usr/lib/apache2/modules/ ed /etc/apache2/mods-available devono avere permessi: -rw-r--r-- [644] root root.
