In questo articolo vedremo alcune informazioni avanzate di PHP, di interesse per chi possieda o voglia gestire un piano di hosting dedicato o VPS.
Quando si utilizza un modulo di PHP sul proprio webserver PHP funziona con l’utente nobody (ecco cosa significa) e non richiede l’abilitazione del flag di execute per funzionare: phpsuexec risolve questo genere di problematiche di sicurezza, imponendo che ad eseguire i file siano esclusivamente i proprietari (identificati da una username di sistema), mantenendo così un livello di protezione da eventuali attacchi potenziato rispetto al PHP standard.
Che cos’è phpsuexec?
phpsuexec si attiva sugli hosting di livello superiore ad un condiviso mediante cPanel; essa viene utilizzata qualora il modulo PHP sia installato come modulo CGI anziché Apache. Tutti gli hosting condivisi, essendo tale modulo deprecato, sono quindi aggiornati da phpsuexec al più moderno suPHP: queste informazioni interessano quindi tutti i webmaster che utilizzano ancora il vecchio modulo sulle loro VPS o server dedicati, considerando che anche solo phpsuexec consente un livello di sicurezza ulteriore rispetto al modo tradizionale in cui si usa PHP (si veda anche la nostra FAQ sugli handler). Gli elementi più importanti sono dettagliati di seguito.
- Come primo aspetto rilevante, l’uso del modulo phpsuexec permette di eseguire gli script PHP come utente con userid univoco piuttosto che “nobody“;
- non impone più la necessità di utilizzare CHMOD 777 (poco sicuro) per consentire l’upload dei file (si veda in proposito la FAQ sui permessi dei file);
- ogni file PHP deve appartenere all’utente in questione per poter essere eseguito;
- non è più richesto il permesso 755, poichè è sufficente un 644 (si veda anche qui la FAQ sui permessi dei file), mentre in linea di massima i permessi sui file contententi informazioni sensibili (file di configurazione/connessione al db ad esempio) un 400 o 600 possono essere sufficenti;
- non viene consentito l’uso di php_flag e php_value nel file .htaccess, ed ogni tentativo di farlo evolve in un errore di Internal Server (500);
- le impostazioni di eventuali flag possono essere, alla luce del punto precedente, riportate solo all’interno di un file PHP.ini, ovviamente avendo cura di tradurre dall’una all’altra sintassi (php_flag register_globals off diventa register_globals off, ad esempio);
- se l’utente dovesse dare un permesso 777 ad una cartella contenente un file PHP, ciò risulterà in un internal server error (visualizza tutti i codici di errore); i permessi ordinari dovrebbero essere pari a 755.
- alcune funzioni di Apache non sono abilitate (vedi link);
- se il file .htaccess dovesse contenere la direttiva “Options“, dovrebbe possedere l’opzione + o – in modo da tenere attivo il modulo ExecCGI;
- i link simbolici non potranno funzionare nei file PHP per ragioni di sicurezza;
- Alcune applicazioni web quali OS commerce e ZenCart verificano se il file configure.php sia scrivibile, e ciò dovrebbe essere effettivamente realizzato. Il permesso del file dovrebbe essere cambiato eventualmente a 444 via SSH se qualcosa non andasse, ad esempio chmod 444 /path/to/configure.php.
- l’autenticazione HTTP non è abilitata direttamente da codice PHP, tuttavia sarà possibile sfruttare la feature mediante il file .htaccess o proteggendo una cartella da pannello di controllo.
- Se si dovesse fare uno dell’opzione “AddType application/x-httpd-php” nel file .htaccess, dovrebbe essere riscritta come “AddHandler application/x-httpd-php”. Analogamente se si volesse usare il ForceType, sempre nello stesso file di configurazione, per forzare l’interpretazione di estensioni ulteriori come se fossero PHP, dovrete cambiare il comando con un SetHandler.
Che cos’è suPHP? Cosa cambia da phpsuexec a suPHP?
suPHP non è altro che un tool per abilitare l’esecuzione di script PHP con i relativi permessi dei rispetti proprietari: i webserver solitamente utilizzano questo genere di impostazione, che è del tutto simile a quanto visto per l’altro modulo, ma con qualche miglioramento sostanziale.
Qualora suPHP sia disponibile sul vostro server, sarà possibile verificarlo facendo login sul pannello di controllo alla voce “PHP Configuration” sotto “Software/Services”. Su tale pagine potrete
- fare switch da PHP 4 a PHP 5,
- visualizzare come configurare PHP e su come funzioni il modulo,
- scaricare un file php.ini e customizzarlo, se necessario, sulle vostre specifiche esigenze (dettate ad esempio dal CMS che state facendo funzionare): è tipico, in particolare, accedere a questo tipo di impostazioni in modo da sincronizzare il tutto, ad esempio dopo un upgrade del modulo Zend Optimizer.
I principali cambiamenti da phpsuexec a suPHP sono i seguenti:
1. Di default la CLI (Command Line Interface o Interfaccia da Linea di Comando) di PHP è php5, ed è raggiungibile con i seguenti path tipici:
- /usr/bin/php (php5 cgi)
- /usr/local/bin/php (php5 cli)
- /usr/php4/bin/php (php4 cgi)
- /usr/local/php4/bin/php (php4 cli)
2. Esistono ulteriori aspetti da tenere in considerazione quali:
- l’autenticazione mediante HTTP funziona anche da PHP;
- i link simbolici sono abilitati;
- i permessi della cartella public_html non richiedono di essere cambiati per far funzionare una SSL condivisa con PHP5;
- le pagine di errore 404 customizzate funzioneranno sia con la versione PHP 4 che con la 5;
3. sarà disponibile inoltre il modulo ionCube PHP Loader assieme al suddetto Zend Optimizer. Se si fa uso di un php.ini personalizzato avrete bisogno di aggiornarlo scaricandolo dal pannello di controllo, in modo tale che Zend Optimizer possa caricare gli script necessari in modo corretto.
4. se si stanno impostando ulteriori personalizzazioni di PHP, il file php.ini potrà risiede nella cartella dove è presente lo script PHP che si desidera attivare, oppure, in alternativa, piazzarlo all’interno di qualsiasi directory, ed inserire l’apposita direttiva in public_html/.htaccess:
suPHP_ConfigPath /home/username/php5-config
in cui username è il nome del vostro utente sotto cPanel, mentre php5-config è semplicemente il nome della cartella nella quale è contenuto il file PHP.ini di interesse. In generale è possibile inserire tale file di configurazione all’interno di qualsiasi path (si tratta di un aspetto che caratterizza specificatamente suPHP).
5. Se si desidera attivare php5 in una sottocartella specifica della vostra root, è possibile trovare la direttiva ulteriore in .htaccess:
AddHandler application/x-httpd-php5 .php .php3 .phtml
o similari. Essa dovrebbe quindi essere preceduta da un commento (#) per evitare che cPanel la modifichi in seguito:
# Use PHP5 as default AddHandler application/x-httpd-php5 .php .php3 .phtml
Sui server più aggiornati non è tuttavia necessario ricorrere a questo accorgimento.
Altri tipi di aggiornamenti di interesse sono:
- è possibile disporre del modulo ffmpeg (modulo cross-platform per registrare, convertire e fare streming audio e video in modalità nativa, cioè senza ricorrere a librerie esterne) sia su PHP4 che PHP5;
- è inoltre disponibile il modulo mod_gzip.
Quando si fa uso di un’installazione ordinaria di PHP, dunque, tale modulo funziona come utente “nobody” e non richiede il flag di execute per funzionare. Il problema è che se non viene installato l’ulteriore modulo mod_openbasedir, un utente arbitrario potrebbe leggere esternamente il contenuto dei vostri file PHP in quanto sta condividendo la medesima username (utente nobody). Come probabilmente saprete, i file PHP non sono intesi per una lettura dall’esterno bensì solo a scopo di parsing per eseguire operazioni come stampare tabelle, connettersi al database e così via: se diventa possibile leggerli senza disporre delle credenziali di accesso il problema è enorme, specie nel caso in cui vi siano memorizzati dati riservati (username e password MySQL).
phpsuexec elimina questo problema in quanto richiede che il PHP possa essere utilizzato esclusivamente da un utente con un nome specifico (ad esempio “pippo78”), e risolve anche alcuni problemi di ownership che affiggono alcune versioni di Joomla! e WordPress, rendendoli così meno sicuri. Il fatto di poter fare uso di permessi 600 o 700, impedendo l’uso del CHMOD 777, limita l’accesso ai file, obbligando il sistema a parserizzarli qualora un utente provi ad accedervi sui propri browser.
Un commento