Product SiteDocumentation Site

11.2. Server web (HTTP)

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

11.2.1. Installare Apache

L'installazione del pacchetto apache2 è tutto ciò che è necessario. Contiene tutti i moduli, compresi Multi-Processing Modules (MPMs), che influenzano il modo in cui Apache gestisce l'elaborazione in parallelo di numerose richieste, che precedentemente erano fornire in pacchetti separati apache2-mpm-*). Installerà anche apache2-utils contenente le utilità a riga di comando che scopriremo dopo.
L'MPM in uso influenza in modo significativo il modo in cui Apache gestirà richieste simultanee. Con il worker MPM, utilizza threads (processi leggeri), mentre con il prefork MPM utilizza una serie di processi creati in anticipo. Con event MPM anche utilizza i threads, ma le connessioni inattive (in particolare quelle tenute aperte dalla funzione HTTP keep-alive) vengono consegnate ad una gestione dedicata del thread.
Gli amministratori della Falcot installano anche libapache2-mod-php per includere il supporto a PHP 7.4 all'interno di Apache. Questo fa si che venga disabilitato il modulo predefinito MPM event e che invece al suo posto venga usato prefork. Per usare MPM event è possibile installare il pacchetto php-fpm.
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/html/ (come configurato in /etc/apache2/sites-enabled/000-default.conf).

11.2.2. Aggiungere il supporto per SSL

Apache 2.4 include, già pronto per essere usato, il modulo SSL (mod_ssl) necessario per rendere sicuro HTTP (HTTPS). È sufficiente attivarlo con a2enmod ssl e aggiungere le direttive necessarie ai file di configurazione. Un esempio di configurazione è fornito in /etc/apache2/sites-available/default-ssl.conf.
Se si desidera generare certificati attendibili, è possibile vedere la sezione Sezione 10.2.1, «Creazione di certificati attendibili gratuiti» e regolare le seguenti variabili:
SSLCertificateFile      /etc/letsencrypt/live/DOMAIN/fullchain.pem
SSLCertificateKeyFile   /etc/letsencrypt/live/DOMAIN/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/DOMAIN/chain.pem
SSLCACertificateFile    /etc/ssl/certs/ca-certificates.crt
Qualche accortezza in più deve essere presa se si vuole permettere connessioni SSL con Perfect Forward Secrecy (queste connessioni utilizzano chiavi di sessione effimere assicurando così che la compromissione della chiave segreta del server con comporti anche la compromissione del traffico di dati criptato, precedentemente effettuato, che potrebbe essere stato memorizzato durante lo sniffing sulla rete). Dare un'occhiata alle raccomandazioni Mozilla, in particolare:
In alternativa al modulo SSL standard, esiste il modulo mod_gnutls, fornito con il pacchetto libapache2-mod-gnutls ed abilitato con il comando a2enmod gnutls. Sfortunatamente, la versione pacchettizzata per Debian, aveva seri problemi ed implicazioni di sicurezza e pertanto non fa parte del rilascio di Debian Bullseye.

11.2.3. 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. Inoltre, è definito un host virtuale predefinito nel file /etc/apache2/sites-enabled/000-default.conf: questo host virtuale viene utilizzato qualora non venga trovato alcun host che corrisponde alla richiesta inviata dal client.
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.13. Il file /etc/apache2/sites-available/www.falcot.org.conf

<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-available/customlog.conf che definisce un nuovo formato per tutti i file di log (con la direttiva LogFormat) ed abilitandolo con a2enconf customlog. La riga CustomLog dev'essere quindi rimossa (o commentata) dal file /etc/apache2/sites-available/000-default.conf.

Esempio 11.14. Il file /etc/apache2/conf-available/customlog.conf

# 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.4. Direttive comuni

Questa sezione esamina brevemente alcune delle direttive di configurazione di uso comune di 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.15. Blocco Directory

<Directory /srv/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 indica al server che i collegamenti simbolici possono essere seguiti e che la risposta deve contenere il contenuto della destinazione di tali collegamenti.
  • SymlinksIfOwnerMatch indica al server di seguire i collegamenti simbolici, ma solo quando il collegamento e la sua destinazione hanno lo stesso proprietario.
  • Includes abilita Server Side Includes (SSI in breve). Si tratta di direttive incorporate nelle pagine HTML ed eseguite al volo per ogni richiesta.
  • IncludesNOEXEC permette Server Side Includes (SSI) ma disabilita il comando exec e limita la direttiva include ai file di testo/markup.
  • Indexes indica al server di elencare il contenuto 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 consente la negoziazione dei contenuti; può essere utilizzata dal server per restituire una pagina web corrispondente 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.4.1. Richiedere un'autenticazione

In alcune circostanze, l'accesso a parte dei contenuti di un sito web deve essere ristretto, così che solo ai utenti legittimi che forniscono un nome utente ed una password venga garantito l'accesso ai contenuti. Queste funzionalità sono fornite dai moduli mod_auth*.

Esempio 11.16. 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.4.2. Limitare l'accesso

La direttiva Require controlla le restrizioni di accesso per una directory (e le sue sottodirectory, in modo ricorsivo).
Può essere usata per limitare l'accesso in base a molti criteri; ci soffermeremo alla descrizione delle limitazioni di accesso in base all'indirizzo IP del client, ma possono essere apllicate politiche ancora più restrittive, in particolare quando più direttive Require sono combinate all'interno di un blocco RequireAll.

Esempio 11.17. Consenti solo dalla rete locale

Require ip 192.168.0.0/16

11.2.5. 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 è personalizzazione del file /etc/awstats/awstats.conf.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
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.18. File di configurazione di AWStats per un host virtuale

Include "/etc/awstats/awstats.conf"
SiteDomain="www.falcot.org"
HostAliases="falcot.org"
AWStats usa molte delle icone presenti nella directory /usr/share/awstats/icon/. Affinché queste icone siano disponibili sul sito web la configurazione di Apache dev'essere adattata per includere la seguente direttiva (per esempi più dettagliati vedere /usr/share/doc/awstats/examples/apache.conf):
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: