11.2. Server web (HTTP)

Gli amministratori della Falcot Corporation hanno deciso di utilizzare il server HTTP Apache, versione 2.2.16, incluso in Debian Squeeze.

11.2.1. Installare Apache

In via predefinita installare il pacchetto apache2 causa l'installazione della versione apache2-mpm-worker di Apache. Il pacchetto apache2 è un guscio vuoto, serve unicamente ad assicurare che una delle versioni di Apache sia installata.

Le differenze tra le varianti di Apache2 sono relative alla politica di gestione adottata per elaborare parallelamente più richieste. Questa politica è implementata da un MPM (appreviazione per Multi-Processing Module). Tra gli MPM disponibili il pacchetto apache2-mpm-worker utilizza i thread (processi leggeri) mentre il pacchetto apache2-mpm-prefork utilizza un insieme di processi creati anticipatamente (è il metodo tradizionale oltre che l'unico disponibile in Apache 1.3). apache2-mpm-event utilizza a sua volta i thread ma questi vengono terminati subito dopo aver evaso la richiesta mentre la connessione in ingresso è mantenuta aperta unicamente dalla funzione keep-alive di HTTP.

Gli amministratori della Falcot installano anche libapache2-mod-php5 per includere anche il supporto PHP di Apache. Questo causa la rimozione di apache2-mpm-worker e l'installazione di apache2-mpm-prefork al suo posto poiché PHP può funzionare unicamente con questo tipo di MPM.

SICUREZZA Esecuzione con l'utente www-data

In via predefinita Apache gestisce le richieste in arrivo come fosse l'utente www-data. Questo significa che una vulnerabilità in uno script CGI eseguito da Apache (per una pagina dinamica) non comprometterebbe l'intero sistema, ma solo i file di proprietà di questo particolare utente.

Usare i moduli suexec permette di eludere questa regola per permettere ad alcuni script CGI di essere eseguiti con l'identità di un altro utente. Questo è configurato con una direttiva SuexecUserGroup utentegruppo nel file di configurazione di Apache.

Un'altra possibilità è l'utilizzo di un MPM dedicato come quello fornito da apache2-mpm-itk che ha un comportamento leggermente differente: permette di «isolare» gli host virtuali in modo che possano essere eseguiti ciascuno con un utente differente. Una vulnerabilità in un sito non potrà quindi compromettere i file appartenenti al proprietario di un altro sito.

Apache è un server modulare e molte funzionalità sono implementate da moduli esterni che il programma principale carica durante la fase di inizializzazione. La configurazione predefinita abilita solo i moduli più comuni ma abilitare un modulo è semplice: basta eseguire a2enmod modulo. Per disabilitare un modulo il comando è a2dismod modulo. Questi programmi non fanno altro che creare (o rimuovere) i collegamenti simbolici in /etc/apache2/mods-enabled/ che puntano ai file (conservati in /etc/apache2/mods-available/).

Con la sua configurazione predefinita il server web rimane in ascolto sulla porta 80 (come configurato in /etc/apache2/ports.conf) e serve le pagine dalla directory /var/www/ (come configurato in /etc/apache2/sites-enabled/000-default).

11.2.2. Configurare gli host virtuali

Un host virtuale è una identità aggiuntiva per il server web.

Apache considera due tipologie differenti di host virtuali: quelli che sono basati sull'indirizzo IP (o sulla porta) e quelli che si affidano al nome di dominio del server web. Il primo metodo richiede di allocare indirizzi IP (o porte) differenti per ogni sito, mentre il secondo metodo può funzionare con un singolo IP (ed una sola porta) e i siti vengono differenziati dal nome host inviato dal client HTTP (cosa che funziona unicamente con la versione 1.1 del protocollo HTTP che comunque è fortunatamente abbastanza vecchia da essere attualmente utilizzata su tutti i client).

La (crescente) carenza di indirizzi IPv4 favorisce in genere il secondo metodo anche se questo è reso più complesso qualora gli host virtuali necessitino di fornire anche HTTPS poiché il protocollo SSL non è sempre disponibile in caso di host virtuali basati sul nome. L'estensione SNI (Server Name Indication) che permette questo genere di combinazione non è supportata da tutti i browser. Quando più siti HTTPS necessitano di girare sullo stesso server vengono spesso differenziati utilizzando una porta o un indirizzo IP differente (IPv6 in questo caso può essere d'aiuto).

La configurazione predefinita per Apache 2 abilita gli host virtuali basati sul nome (con la direttiva NameVirtualHost *:80 nel file /etc/apache2/ports.conf). Inoltre è definito un host virtuale predefinito nel file /etc/apache2/sites-enabled/000-default: questo host virtuale viene utilizzato qualora non venga trovato alcun host che corrisponde alla richiesta inviata dal client.

APPROFONDIMENTO Apache supporta SNI

A partire da Debian Squeeze il server Apache supporta un'estensione del protocollo SSL chiamata Server Name Indication (SNI). Questa estensione permette al browser di inviare il nome host del server web durante l'avvio di una connessione SSL, cioè molto prima della stessa richiesta HTTP che veniva precedentemente utilizzata per identificare l'host virtuale richiesto tra quelli ospitati sullo stesso server (con lo stesso indirizzo IP e la stessa porta). Questo permette ad Apache di selezionare il certificato SSL più appropriato per la connessione da stabilire.

Prima di SNI, Apache avrebbe sempre utilizzato il certificato definito nell'host virtuale predefinito. I client che tentavano di accedere ad un altro host virtuale visualizzavano degli avvertimenti poiché il certificato ricevuto non corrispondeva al sito web a cui avevano tentato di accedere. Fortunatamente oggi la maggior parte dei browser supportano SNI: tra questi Microsoft Internet Explorer a partire dalla versione 7.0 (iniziando da Vista), Mozilla Firefox dalla versione 2.0, Apple Safari dalla versione 3.2.1 e Google Chrome in tutte le sue versioni.

Il pacchetto Apache fornito in Debian è compilato con il supporto per SNI: non sono richieste particolari configurazioni oltre all'abilitazione degli host virtuali basati sul nome nella porta 443 (SSL) così come nella classica porta 80. È sufficiente modificare il file /etc/apache2/ports.conf affinché includa quanto segue:

<IfModule mod_ssl.c>
    NameVirtualHost *:443
    Listen 443
</IfModule>

Dev'essere prestata attenzione per assicurare che la configurazione del primo host virtuale (quello predefinito) abiliti TLSv1. Apache utilizza i parametri di questo primo host virtuale per stabilire connessioni sicure ed è bene che tali parametri siano impostati per consentirle!

Ogni host virtuale aggiuntivo viene descritto da un file conservato in /etc/apache2/sites-available/. Quindi impostare un sito web per il dominio falcot.org richiede semplicemente la creazione del file seguente e l'abilitazione dell'host virtuale con a2ensite www.falcot.org.

Esempio 11.16. Il file /etc/apache2/sites-available/www.falcot.org

<VirtualHost *:80>
ServerName www.falcot.org
ServerAlias falcot.org
DocumentRoot /srv/www/www.falcot.org
</VirtualHost>

Il server Apache, configurato come visto, utilizza gli stessi file di log per tutti gli host virtuali (anche se questo può essere modificato inserendo direttive CustomLog nelle definizioni degli host virtuali). Questo è un buon motivo per personalizzare il formato di questo file di log perché includa il nome dell'host virtuale. Questo può essere fatto creando un file /etc/apache2/conf.d/customlog che definisce un nuovo formato per tutti i file di log (con la direttiva LogFormat). La riga CustomLog dev'essere quindi rimossa (o commentata) dal file /etc/apache2/sites-available/default.

Esempio 11.17. Il file /etc/apache2/conf.d/customlog

# Nuovo formato di log che include il nome dell'host (virtuale)
LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost

# Quindi utilizziamo questo formato "vhost" in via predefinita
CustomLog /var/log/apache2/access.log vhost

11.2.3. Direttive comuni

Questa sezione esamina brevemente alcune delle direttive di configurazione frequentemente utilizzate per Apache.

Il file di configurazione principale include generalmente diversi blocchi Directory che consentono di specificare diversi comportamenti per il server in base alla posizione del file che dev'essere servito. Un blocco generalmente include le direttive Options e AllowOverride.

Esempio 11.18. Blocco Directory

<Directory /var/www>
Options Includes FollowSymlinks
AllowOverride All
DirectoryIndex index.php index.html index.htm
</Directory>

La direttiva DirectoryIndex contiene una lista di file da provare quando la richiesta del client corrisponde ad una directory. Il primo file nella lista che esiste viene inviato come risposta.

La direttiva Options è seguita da una lista di opzioni da abilitare. Il valore None disabilita tutte le opzioni così come All le abilita tutte ad eccezione di MultiViews. Le opzioni disponibili includono:

ExecCGI indica che gli script CGI possono essere eseguiti.
FollowSymlinks informa il server che i collegamenti simbolici possono essere seguiti e che la risposta deve contenere i contenuti della destinazione indicata dai collegamenti.
SymlinksIfOwnerMatch comunica al server di seguire i collegamenti simbolici, ma solo quando il collegamento e la sua destinazione hanno lo stesso proprietario.
Includes abilita le inclusioni lato server (abbreviato con SSI in lingua inglese). Queste sono direttive incorporate nelle pagine HTML ed eseguite in tempo reale ad ogni richiesta.
Indexes comunica al server di elencare i contenuti di una directory se la richiesta HTTP inviata dal client punta ad una directory senza file di indice (cioè quando in questa directory non esiste alcun file menzionato dalla direttiva DirectoryIndex).
MultiViews abilita la negoziazione del contenuto: questa opzione può essere utilizzata dal server per fornire una pagina web che corrisponda alla lingua preferita configurata nel browser.

La direttiva AllowOverride elenca tutte le opzioni che possono essere abilitate o disabilitate attraverso un file .htaccess. Un utilizzo comune di questa opzione riguarda la limitazione di ExecCGI per permettere all'amministratore di scegliere quali utenti sono autorizzati ad eseguire programmi con l'identità del server web (l'utente www-data).

11.2.3.1. Richiedere un'autenticazione

In alcune circostanze l'accesso a parte dei contenuti di un sito web deve essere ristretto ai soli utenti autorizzati che forniscono un nome utente ed una password.

Esempio 11.19. Richiedere l'autenticazione con un file .htaccess

Require valid-user
AuthName "Directory privata"
AuthType Basic
AuthUserFile /etc/apache2/authfiles/htpasswd-private

Il file /etc/apache2/authfiles/htpasswd-private contiene una lista di utenti e password che sono generalmente manipolati con il comando htpasswd. Per esempio il seguente comando è utilizzato per aggiungere un utente o cambiare la sua password:

# htpasswd /etc/apache2/authfiles/htpasswd-private utente
New password:
Re-type new password:
Adding password for user user

11.2.3.2. Limitare l'accesso

Le direttive Allow from e Deny from controllano le restrizioni d'accesso per una directory (e, ricorsivamente, le sue sottodirectory).

La direttiva Order comunica al server l'ordine con cui le direttive Allow from e Deny from devono essere applicate: l'ultima che corrisponde ha la precedenza. In parole povere, Order deny,allow consente l'accesso se nessuna direttiva Deny from è soddisfatta oppure se lo è una direttiva Allow from. Al contrario Order allow,deny rifiuta l'accesso se nessuna direttiva Allow from è soddisfatta (oppure se lo è una direttiva Deny from).

Le direttive Allow from e Deny from possono essere seguite da un indirizzo IP, da una rete (come 192.168.0.0/255.255.255.0, 192.168.0.0/24 o anche 192.168.0), un nome host oppure un nome di dominio, o ancora dalla parola chiave all che indica tutti.

Esempio 11.20. Rifiutare in via predefinita ma autorizzare la rete locale

Order deny,allow
Allow from 192.168.0.0/16
Deny from all

11.2.4. Analizzatori di log

Nel server web viene spesso installato un analizzatore di log: quest'ultimo fornisce agli amministratori una idea precisa riguardo le modalità d'utilizzo cui è sottoposto.

Gli amministratori della Falcot Corporation hanno scelto AWStats (Advanced Web Statistics) per analizzare i loro file log di Apache.

Il primo passo per la configurazione è la creazione del file /etc/awstats/awstats.conf. Il modello /usr/share/doc/awstats/examples/awstats.model.conf.gz è un punto di partenza raccomandato e gli amministratori della Falcot lo mantengono così com'è modificando solo i parametri seguenti:

LogFile="/var/log/apache2/access.log"
LogFormat = "%virtualname %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"
SiteDomain="www.falcot.com"
HostAliases="falcot.com REGEX[^.*\.falcot\.com$]"
DNSLookup=1
DirData="/var/lib/awstats"
DirIcons="/awstats-icon"
DirLang="/usr/share/awstats/lang"
LoadPlugin="tooltips"

Tutti questi parametri sono documentati dai commenti nel file modello. In particolare i parametri LogFile e LogFormat descrivono la posizione ed il formato del file di log e le informazioni che contiene: SiteDomain e HostAliases elencano i vari nomi con cui il sito web principale viene indicato.

Per siti con molto traffico, DNSLookup non dovrebbe essere impostato a 1 ma per i siti minori, come quello della Falcot descritto in precedenza, questa impostazione permette di avere dei resoconti più leggibili che includono il nome completo delle macchine anziché il semplice indirizzo IP.

AWStats sarà anche attivato per gli altri host virtuali: ogni host virtuale richiede il proprio file di configurazione, come /etc/awstats/awstats.www.falcot.org.conf.

Esempio 11.21. File di configurazione di AWStats per un host virtuale

Include "/etc/awstats/awstats.conf"
SiteDomain="www.falcot.org"
HostAliases="falcot.org"

Questo funzionerà solo se il file /etc/awstats/awstats.conf non contiene alcuna direttiva Include poiché AWStats non può gestire inclusioni multi-livello: sfortunatamente il file predefinito fornito da Debian contiene questa direttiva.

Perché questo nuovo host virtuale sia preso in considerazione il file /etc/cron.d/awstats dev'essere modificato per contenere un richiamo come segue: /usr/lib/cgi-bin/awstats.pl -config=www.falcot.org -update

Esempio 11.22. Il file /etc/cron.d/awstats

0,10,20,30,40,50 * * * * www-data [ -x /usr/lib/cgi-bin/awstats.pl -a -f /etc/awstats/awstats.conf -a -r /var/log/apache2/access.log ] && /usr/lib/cgi-bin/awstats.pl -config=awstats -update >/dev/null && /usr/lib/cgi-bin/awstats.pl -config=www.falcot.org -update >/dev/null

AWStats usa molte delle icone conservate nella directory /usr/share/awstats/icon/. Perché queste icone siano disponibili sul sito web la configurazione di Apache dev'essere adattata per includere la seguente direttiva:

Alias /awstats-icon/ /usr/share/awstats/icon/

Dopo qualche minuto (e una volta che lo script è stato eseguito qualche volta) i risultati saranno visibili online:

→ http://www.falcot.com/cgi-bin/awstats.pl

→ http://www.falcot.org/cgi-bin/awstats.pl

ATTENZIONE Rotazione dei file di log

Perché le statistiche prendano in considerazione tutti i log AWStats necessita di essere eseguito subito prima che i file di log di Apache siano ruotati. Questo si può ottenere aggiungendo la direttiva prerotate al file /etc/logrotate.d/apache2:

/var/log/apache2/*.log {
  weekly
  missingok
  rotate 52
  compress
  delaycompress
  notifempty
  create 644 root adm
  sharedscripts
  prerotate
    su - www-data -c "/usr/lib/cgi-bin/awstats.pl -config=awstats -update > /dev/null"
    su - www-data -c "/usr/lib/cgi-bin/awstats.pl -config=www.falcot.org -update > /dev/null"
  endscript
  postrotate
    if [ -f /var/run/apache2.pid ]; then
      /etc/init.d/apache2 restart > /dev/null
    fi
  endscript
}

Notare inoltre che i file di log creati da logrotate devono essere leggibili da chiunque, specialmente da AWStats. Nell'esempio visto prima questo è assicurato dalla riga create 644 root adm.