1. Introduzione

Questo articolo mostra passo dopo passo, come installare e configurare il web server Apache 1.3.x e avere un certo livello di sicurezza, anche se in futuro saranno trovate nuove vulnerabilità per questo software.

1.1 Funzionalità

Prima che cominciamo a mettere in sicurezza il nostro web server Apache, dobbiamo specificare le funzionalità che vogliamo ottenere dal nostro web server. La diversità d'uso di Apache, e quindi i diversi modi di configurazione, lo rendono nello stesso tempo molto performante e molto funzionale, ma soprattutto anche molto vulnerabile. Infatti, come prima cosa, fisseremo dei punti cardini in base a quali si sviluppera la compilazione, l'installazione e la configurazione del nostro web server.

• Il web server sarà accessibile da Internet;
• Saranno elaborate soltanto le pagine HTML
• Il server supporterà il meccanismo di name-based virtual hosting
• Alcune pagine web possono essere accessibili dagli indirizzi IP specificati o da utenti (basic authentication)
• Il server memorizzerà tutte le richieste effettuate al server web (informazioni comprese sui browsers web)

Bisogna dire che questo tipo di installazione non prevede l'uso di script lato-server come Perl, PHP, JSP, cgi, cioè tutto ciò che permette di interagirsi con i servizi web. L'uso di tali tecnologie può creare una grande minaccia per la sicurezza. Infatti, anche uno script piccolo può fare diminuire radicalmente il livello di sicurezza del nostro server. Perchè? Soprattutto, le applicazioni ASP/cgi possono contenere le vulnerabilità di sicurezza (per esempio iniezione di codice SQL, cross-site-scripting). Secondariamente, la tecnologia in se può essere pericolosa (vulnerabilità di PHP, moduli Perl, ecc.). Ecco perchè suggerisco vivamente di usare tali tecnologie soltanto quando un'interazione con un sito web è assolutamente necessaria.

1.2 Presupposti di sicurezza

Uno degli elementi più importanti di un progetto su un computer è l'aspetto che riguarda la sicurezza, e quindi ciò che vogliamo mettere in sicurezza. Questi punti cardini, come già detto in precedenza, bisogna fissarli prima che si inizi l'installazione. I presupposti di sicurezza per il nostro web server sono i seguenti:

• Il sistema operativo deve essere protetto sia contro gli attacchi che provengono da remoto che da quelli locali;
• Il nostro server non deve offrire altri servizi eccetto quelli HTTP: (80/TCP);
• L'accesso da remoto deve essere controllato da un firewall, bloccando tutte le connessioni in uscita (outbound), e permettendo le connessioni in entrata (inbound) solo sulla porta 80/TCP del Web server;
• Il Web server Apache deve essere l'univo servizio attivo sul nostro server (con eccezione logica dei servizi base che il nostro sistema operativo usa);
• Solo se è necessario si possono attivare i modululi Apache;
• Qualsiasi diagnositca effettuata tramite pagina web e la visualizzazione automatica dell'elenco dei contenuti dele directory deve essere inibita;
• Il server deve comunicare la minima informazione in suo merito (security by obscurity);
• Il server web Apache deve essere avviato unicamente da un UID/GID, che non venga condiviso con alcun processo;
• Il processo di Apache deve avere accesso limitato soltanto nella zona del filesystem a lui dedicata (chrooting);
• Nessun programma shell deve essere presente nell'ambiente di lavoro/sviluppo di Apache (/bin/sh, /bin/csh etc.).

2 Installazione del sistema di sicurezza

Prima dell'installazione di Apache dobbiamo scegliere un sistema operativo, su cui far funzionare il nostro web server. Vi è una vasta serie di sistemi operativi su cui è possibile compilare e installare il nostro Apache. Il resto dell'articolo si baserà sull'installazione e sulla messa in sicurezza del nostro web server su Linux (distribuzione Slackware), comunque i metodi descritti sono compatibili con la maggior parte dei sistemi operativi UNIX/Linux. L'unico sistema operativo che non suggerisco di usare è MS WINDOWS - pricipalmente a causa delle limitate possibilità di messa in sicurezza di Apache.

Il primo punto nel mettere in sicurezza il nostro web server sta nel rafforzare il sistema operativo. Una discussione sul come mettere in sicurezza il nostro sistema operativo è oltre la portata di questo articolo. Tuttavia, ci sono sulla rete documenti che descrivono come effettuare questa operazione. Pertanto, prima di continuare con la lettura di questo articolo, vi consiglio vivamente di aggiornare e di controllare la sicurezza del proprio sistema operativo.

Dopo che sono stati fatti i dovuti accorgimenti riguardanti la sicurezza del sistema operativo, si proceda con la creazione di un gruppo e di uno user chiamati entrambi "apache", come segue:

groupadd apache useradd apache -c "Apache Server" -d /dev/null -g apache -s /sbin/nologin

Di default, il processo di Apache è eseguito con i privilegi dello user nobody (eccetto il processo madre, che è eseguito con i privilegi dello user root) e GID del gruppo nogroup. Tutto ciò può essere una minaccia significativa alla sicurezza del web server. Nel caso in cui avviene un'intrusione, l'intruso può ottenere l'accesso a tutti gli altri processi che funzionano sotto lo stesso UID/GID. Quindi, la soluzione ottimale è quella di far funzionare Apache sotto uno UID/GID di uno user/group normale unico, il quale è dedicato solo ed esclusivamente ad Apache.

2.1 Preparazione del Software

Il prossimo passo è quello di scaricare l'ultima versione del Web server Apache. Alcuni parametri di Apache sono impostabili soltanto all'atto della compilazione del sorgente, perciò è importante effettuare il download del codice sorgente anzichè della versione binaria (già compilata con parametri di default).

Dopo ch'è stato scaricato il software, si proceda con l'operazione di scompattamento. Ora bisogna decidere quali moduli si vogliono rimanere e quali no. Per ogni modulo che Apache permette di applicare sono consultabili le relative informazioni presso il sito http://httpd.apache.org/docs/mod/.

2.2 Moduli Apache

La scelta dei moduli è uno dei punti fondamentali per mettere in sicurezza Apache. Dovremmo seguire la regola: «meno metto e meglio è!». Per soddisfare questa regola ed avere buone premesse di sicurezza, bisogna che rimangamo abilitati solo i seguenti moduli:

Nome del Modulo	Descrizione
httpd_core	Il cuore di Apache, è sempre richiesto in ogni installazione di Apache.
mod_access	Fornisce il controllo di accesso basato sul hostname del client, sull'indirizzo IP, o su altre caratteristiche del client. Poichè a questo modulo è necessario fornire delle direttive che possono essere "order", "allow" e "deny", esso deve rimanere attivo.
mod_auth	Necessario per implementare l'autenticazione da parte di utenti (HTTP Basic Authentication), ch'è stato specificato nei presupposti di sicurezza.
mod_dir	Necessario per fornire i file indice di ogni directory: "index.html", "default.htm", etc.
mod_log_config	Necessario per effettuare il loggin delle richieste effettuate al server.
mod_mime	Necessario per settare i set di caratteri, content-encoding, handler, content-language, e tipi di MIME dei documenti.

Tutti gli altri moduli di Apache sono disattivati. Ciò è fattibile in quanto non ci servono. Inoltre è giusto disattivare i moduli che non ci necessitano in quanto sono dei potenziali "target" per le loro vulnerabilità future. Meno target abbiamo e meno possiamo essere delle potenziali vittime in futuro.

2.3 Per installare

Bisogna anche dire che due dei numerosi moduli di Apache sono più pericolosi di molti altri, questi sono: mod_autoindex e mod_info. Il primo modulo provvede a creare un indice della directory, ed è attivo nelle installazioni di default. Questo modulo è semplice da utilizzare per controllare se Apache funziona su un server (es. http://nome_server/icons/) e per ottenere il contenuto delle directory del server web, quando non vi è un file indice (es. index.html). Il secondo modulo, mod_info, non deve essere mai accessibile da internet, in quanto questo modulo permette di visualizzare in output sul web la configurazione del proprio web server.

La prossima domanda è come compilare i moduli. Il metodo statico sembra essere una scelta raggionevole. Ma, nel caso in cui vengono trovate delle vulnerabilità per un modulo compilato, bisogna ricompilare l'intero software. Però, scegliendo il modo di compilazione statico, non sarà necessario l'integrazione di un ulteriore modulo, quale - mod_so.

3 Compilare il software

Prima di tutto - se esistono - bisogna applicare le patch di sicurezza. Per compilare il software e installarlo correttamente bisogna procedere come segue:

./configure --prefix=/usr/local/apache \ --disable-module=all \ --server-uid=apache \ --server-gid=apache \ --enable-module=access \ --enable-module=log_config \ --enable-module=dir \ --enable-module=mime \ --enable-module=auth make su umask 022 make install chown -R root:sys /usr/local/apache

4 Chrooting del server

Il prossimo passo è quello di limitare l'accesso nel filesystem dei processi di Apache. Possiamo realizzare ciò usando la tecnica di chrooting per il nostro servizio(httpd). In generale, la tecnica chrooting significa: generare una nuova struttura della directory di radice. A raggion per cui, tutti i files a cui il sevizio fa riferimento, bisogna modificarli e quindi adeguarli al nuovo ambiente di sviluppo/lavoro. Grazie a tutto ciò, il servizio (e tutti i processi figli) avranno accesso soltanto alla struttura della nuova directory.

Inizieremo il "chrooting" generando una nuova struttura della directory radice sotto /produzione/httpd:

mkdir -p /produzione/httpd/dev mkdir -p /produzione/httpd/etc mkdir -p /produzione/httpd/var/run mkdir -p /produzione/httpd/usr/lib mkdir -p /produzione/httpd/usr/libexec mkdir -p /produzione/httpd/usr/local/apache/bin mkdir -p /produzione/httpd/usr/local/apache/logs mkdir -p /produzione/httpd/usr/local/apache/conf mkdir -p /produzione/httpd/www

Il proprietario di tutte le directory è lo user root, e l'accesso è settato 0755. Successivamente, dovreste creare il device /dev/null:

ls -al /dev/null crw-rw-rw- 1 root wheel 2, 2 Mar 14 12:53 /dev/null mknod /produzione/httpd/dev/null c 2 2 chown root:sys /produzione/httpd/dev/null chmod 666 /produzione/httpd/dev/null

Un metodo differente deve essere usato per creare il device /produzione/httpd/dev/log, il quale è necessario per un corretto funzionamento del server. Nel caso si utilizzi quale sistema operativo FreeBSD, la seguente riga dovrebbe essere aggiunta al file /etc/rc.conf:

syslogd_flags="-l /produzione/httpd/dev/log"

Ora bisogna riavviare il compiuter oppure riavviare il servizio syslogd per rendere effettive le modifiche. Per creare il dvice /produzione/httpd/dev/log in un altro sistema operativo, date un'occhiata al manuale (man syslogd).

Il passo successivo è quello di copiare il software httpd all'interno della nuova struttura con i file necessari (binari e librerie). Per fare tutto ciò, dobbiamo elaborare una lista di tutti i files che ci necessitano Possiamo creare tale elenco usando i seguenti comandi (la loro presenza dipende dal sistema operativo):

Esempio di utilizzo di ldd, con relativo output:

ldd /usr/local/apache/bin/httpd /usr/local/apache/bin/httpd: libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x280bd000) libc.so.4 => /usr/lib/libc.so.4 (0x280d6000) strings /usr/local/apache/bin/httpd | grep lib /usr/libexec/ld-elf.so.1 libcrypt.so.2 libc.so.4 strace /usr/local/apache/bin/httpd | grep open (...) open("/var/run/ld-elf.so.hints",0,00) = 3 (0x3) open("/usr/lib/libcrypt.so.2",0,027757775370) = 3 (0x3) open("/usr/lib/libc.so.4",0,027757775370) = 3 (0x3) open("/etc/spwd.db",0,00) = 3 (0x3) open("/etc/group",0,0666) = 3 (0x3) open("/usr/local/apache/conf/httpd.conf",0,0666) = 3 (0x3) (...)

I suddetti comandi dovrebbero essere applicati non solo al programma httpd, ma anche a tutte le libbrerie ed eseguibili richiesti (le libbrerie richiedono spesso altre libbrerie). Nel caso del sistema Linux, i seguenti file devono essere copiate nella nuova struttura:

cp /usr/local/apache/bin/httpd /produzione/httpd/usr/local/apache/bin/ cp /var/run/ld-elf.so.hints /produzione/httpd/var/run/ cp /usr/lib/libcrypt.so.2 /produzione/httpd/usr/lib/ cp /usr/lib/libc.so.4 /produzione/httpd/usr/lib/ cp /usr/libexec/ld-elf.so.1 /produzione/httpd/usr/libexec/

Usando i comandi di supporto ci accorgiamo che i seguenti file di configurazione devono essere presenti nell'ambiente di sviluppo/lavoro (chrooted):

cp /etc/hosts /produzione/httpd/etc/ cp /etc/host.conf /produzione/httpd/etc/ cp /etc/resolv.conf /produzione/httpd/etc/ cp /etc/group /produzione/httpd/etc/ cp /etc/shadow /produzione/httpd/etc/passwords cp /usr/local/apache/conf/mime.types /produzione/httpd/usr/local/apache/conf/

Note, all'interno di /produzione/httpd/etc/passwords bisogna rimuovere tutte le linee eccetto "nobody" e "apache". In modo simile, bisogna anche rimuovere tutte le righe eccetto le righe "apache" e "nogroup" all'interno di /produzione/httpd/etc/group. Successivamente, bisogna creare il database di password nel seguente modo:

cd /produzione/httpd/etc pwd_mkdb -d /produzione/httpd/etc/passwords rm -rf /produzione/httpd/etc/master.passwd

Il prossimo passo è quello di testare il server httpd all'interno del nuovo ambiente di lavoro. Per effettuare questo test, prima bisogna copiare il file di default di configurazione di Apache e il file di esempio index.html:

cp /usr/local/apache/conf/httpd.conf /produzione/httpd/usr/local/apache/conf/ cp /usr/local/apache/htdocs/index.html.en /produzione/httpd/www/index.html

Dopo che sono stati copiati i seguenti file, si deve cambiare la direttiva DocumentRoot che è presente nel file di configurazione (in /produzione/httpd/usr/local/apache/conf/httpd.conf):

DocumentRoot "/www"

Successivamente sarà possibile avviare il test del server:

chroot /produzione/httpd /usr/local/apache/bin/httpd

Se si riscontrano problemi, si raccomanda di analizzare i file di log (/produzione/httpd/usr/local/apache/logs). In alternativa è possibile eseguire il seguente comando:

truss chroot /produzione/httpd /usr/local/apache/bin/httpd

Il comando truss vi visualizzerà la causa del problema. Dopo aver eliminato eventuali errori, è possibile procedere con la configurazione del server Apache.

3 Configurazione di Apache

Il passo successivo è quello di rimuovere il file /produzione/httpd/usr/local/apache/conf/httpd.conf e crearne uno nuovo all'interno della stessa directory, che però contenga le informazioni di seguito riportate:

# ================================================= # Settaggi Base (Basic settings) # ================================================= ServerType standalone ServerRoot "/usr/local/apache" PidFile /usr/local/apache/logs/httpd.pid ScoreBoardFile /usr/local/apache/logs/httpd.scoreboard ResourceConfig /dev/null AccessConfig /dev/null # ================================================= # Settaggi in base alle proprie # necessità di performance # (Performance settings) # ================================================= Timeout 300 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15 MinSpareServers 5 MaxSpareServers 10 StartServers 5 MaxClients 150 MaxRequestsPerChild 0 # ================================================= # Moduli Apache (Apache's modules) # ================================================= ClearModuleList AddModule mod_log_config.c AddModule mod_mime.c AddModule mod_dir.c AddModule mod_access.c AddModule mod_auth.c # ================================================= # Settaggi Generali (General settings) # ================================================= Port 80 User apache Group apache ServerAdmin Webmaster@www.ebank.lab UseCanonicalName Off ServerSignature Off HostnameLookups Off ServerTokens Prod <IfModule mod_dir.c> DirectoryIndex index.html </IfModule> DocumentRoot "/www/vhosts" # ================================================= # Controllo di accesso (Access control) # ================================================= <Directory /> Options None AllowOverride None Order deny,allow Deny from all </Directory> <Directory "/www/vhosts/www.ebank.lab"> Order allow,deny Allow from all </Directory> <Directory "/www/vhosts/www.test.lab"> Order allow,deny Allow from all </Directory> # ================================================= # MIME encoding # ================================================= <IfModule mod_mime.c> TypesConfig /usr/local/apache/conf/mime.types </IfModule> DefaultType text/plain <IfModule mod_mime.c> AddEncoding x-compress Z AddEncoding x-gzip gz tgz AddType application/x-tar .tgz </IfModule> # ================================================= # Settaggio per i file di log (Logs) # ================================================= LogLevel warn LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined LogFormat "%h %l %u %t \"%r\" %>s %b" common LogFormat "%{Referer}i -> %U" referer LogFormat "%{User-agent}i" agent ErrorLog /usr/local/apache/logs/error_log CustomLog /usr/local/apache/logs/access_log combined # ================================================= # Virtual hosts # ================================================= NameVirtualHost * <VirtualHost *> DocumentRoot "/www/vhosts/www.ebank.lab" ServerName "www.ebank.lab" ServerAlias "www.e-bank.lab" ErrorLog logs/www.ebank.lab/error_log CustomLog logs/www.ebank.lab/access_log combined </VirtualHost> <VirtualHost *> DocumentRoot "/www/vhosts/www.test.lab" ServerName "www.test.lab" ErrorLog logs/www.test.lab/error_log CustomLog logs/www.test.lab/access_log combined </VirtualHost>

- www.ebank.lab (www.e-bank.lab) - www.test.lab

I contenuti dei Web site di cui sopra sono fisicamente presenti nelle directory seguenti:

- /produzione/httpd/www/vhosts/www.ebank.lab - /produzione/httpd/www/vhosts/www.test.lab

Entrambi i siti web hanno i loro file di log, che sono presenti nelle seguenti dire directories:

- /produzione/httpd/usr/local/apache/logs/www.ebank.lab - /produzione/httpd/usr/local/apache/logs/www.test.lab

Le directory sopra elencate devono essere generate prima del primo avvio del nostro web server - Altrimenti Apache riscontrerà eventuali problemi all'avvio. Il proprietario delle directory deve essere root:sys, e devono essere settate nel modo 0755.

Controlla il file di configurazione di Apache Compared with the default Apache configuration file, se le seguenti modifiche sono state apportate:

• Il numero di moduli attivi è significativamente ridotto
• Apache non divulga le informazioni sul relativo numero di versione (direttive: ServerTokens, ServerSignature)
• I processi di Apache (eccetto il processo di root) sono settati da essere eseguiti da un unico utente/gruppo (Direttive: User, Group)
• Apache permette l'accesso esclusivamente alle directory, sottodirectory e file, con le specifiche direttive inserite all'interno del file di configurazione (direttive: Directory, Allow); tutte le altre richieste sono negate di default
• Apache logghera tutte le informazioni più importanti sulle richieste HTTP

5 Passo finale

Alla fine dovreste creare uno script per l'avvio/stop del nostro web server ("rc.httpd"), i cui contenuti dovranno essere simili al seguente script:

#!/bin/sh CHROOT=/produzione/httpd/ HTTPD=/usr/local/apache/bin/httpd PIDFILE=/usr/local/apache/logs/httpd.pid echo -n " apache" case "$1" in start) /usr/sbin/chroot $CHROOT $HTTPD ;; stop) kill `cat ${CHROOT}/${PIDFILE}` ;; *) echo "" echo "Sintassi: `basename $0` {start|stop}" >&2 exit 64 ;; esac exit 0

Questo script deve essere copiato in una directory appropriata (dipende dal tipo di sistema UNIX o UNIX-Like che noi usiamo), cioè dove sono posizionati tutti gli script che si attivano all'avvio. Nel caso di Linux (Slackware) è la directory /etc/rc.d.

6 Sommario

Gli accorgimenti adottati nell'installazione e nella messa in produzione del nostro Web Server, fanno si che il nostro server raggiunga e mantenga un certo livello di sicurezza, che non è offerto da un'installazione di default.

Grazie al fatto che abbiamo attivato solo i moduli di Apache che a noi interessano, quando si troverà una nuova vulnerabilità nei moduli che non abbiamo incluso, e che però di default vengono normalmente inclusi, il nostro web server non è soggetto a queste vulnerabilità. Nascondere il numero di versione di Apache, disattivando il servizio di indicizzazione delle directory, attivando un ambiente di sviluppo/produzione dedicato al nostro web server e limitando la configurazione, rende il nostro web server difficoltoso d'attaccare. L'ambiente di sviluppo (chrooted) ha anche un importante vantaggio - immunità da un grosso numero di exploits, e principalmente dalla mancanza delle shell (/bin/sh, /bin/csh etc.). Anche se un'intruso avrà successo con l'eseguire dei comandi di sistema, questi avrà difficoltà ad uscire dall'ambiente di sviluppo/produzione