Aprire una porta su internet, lasciare che ignoti visitatori entrino e diano uno sguardo nell’anticamera del vostro server è sicuramente un’operazione affascinante e, spesso, utile. Un server web dovrebbe proprio servire a questo, a creare uno spazio destinato ad accogliere le richieste più diverse, a mostrare le informazioni che si vogliono condividere. Con il tempo, però, le esigenze sono cresciute, sono divenute più sofisticate, tanto che il semplice HTML è diventato un linguaggio inadeguato ai nuovi scopi: pagine dinamiche, applicazioni su web, portali, weblog e tutta la teoria di strumenti interattivi ha reso più sofisticati i siti e più complessi i server web alle loro spalle.
Apache è un ottimo esempio di server versatile, potente e, tutto sommato, semplice da configurare: può essere utilizzato da un utente di media esperienza per gestire il proprio sito Internet, come lo si può riscontrare in portali o siti di classe enterprise a servire intranet ed extranet più simili a vere e proprie applicazione browser-driven che a pagine di consultazione. Proprio la notevole interattività delle applicazioni che possono essere costruite attorno a un web server ha portato all’emergere, nel corso degli anni, di una serie di problematiche legate alla sicurezza sia del framework, Apache, che dei programmi, scritti nei più disparati linguaggi, dal Perl o C, per esempio, alle pagine PHP o JavaScript. Insomma, all’aumentare dell’interattività delle pagine web è corrisposta una crescita considerevole dei problemi legati alla sicurezza e delle contromisure che un amministratore di sistema deve essere in grado di porre in campo per assicurare una discreta sicurezza alle proprie installazioni.
Sicurezza stratificata
Cosa comporta mettere in sicurezza un web server? Il problema, come spesso accade, si riflette su diversi livelli di amministrazione su un server:
- Mettere in sicurezza il sistema operativo;
- Mettere in sicurezza il framework (Apache);
- Mettere in sicurezza le applicazioni.
In questa occasione tralasceremo la sicurezza relativa al sistema operativo, un’operazione decisamente complessa che richiederebbe un intero ciclo di articoli a se stante. Di passaggio possiamo solo fornire un suggerimento: una prima soluzione potrebbe consistere nel ricompilare il kernel utilizzando le patch grsecurity (www.grsecurity.net), impostando un alto livello di protezione. Non è la soluzione ottimale, dato che la difesa di un sistema operativo si basa anch’essa su più livelli di intervento, che vanno dalla ricompilazione dei sorgenti degli applicativi alle operazioni, almeno le più elementari, di auditing; però, l’installazione di grsecurity può essere un primo punto di approccio al problema, dal quale partire e approfondire in seguito.
Ciò che qui ci interessa è, primariamente, rendere più affidabile Apache, partendo dalle “radici” del problema, iniziando a lavorare a livello di sorgente, per assicurarci della bontà del programma e per mettere in gioco qualche diversivo in grado di disorientare i malintenzionati meno ferrati in materia di sicurezza.
Il nostro primo passo sarà, quindi scaricare i sorgenti di Apache: è indifferente quale si decida di utilizzare, se appartenente alla versione 1.x o alla 2.x.
Verifichiamo i sorgenti
La prima buona pratica da tenere a mente è quella di preferire i server ufficiali del progetto Apache come fonte dalla quale scaricare i sorgenti sui quali si vuole lavorare. E’ una semplice questione di sicurezza: è decisamente più difficile per qualche malintenzionato penetrare in queste macchine piuttosto che in un computer gestito in maniera amatoriale da qualche volenteroso.
Una volta ottenuti i sorgenti, proseguiamo con una verifica della loro bontà: ogni sorgente fornito ufficialmente dal progetto Apache viene firmato digitalmente dal gestore della versione rilasciata e quindi bisognerà provvedere a scaricare sia le firme PGP che gli hash MD5.
Nel nostro esempio utilizzeremo i sorgenti contenuti nell’archivio:
httpd-2.0.54.tar.gz
Una volta scaricato il sorgente, dobbiamo prelevare anche la relativa firma PGP e l’hash MD5:
httpd-2.0.54.tar.gz.md5
httpd-2.0.54.tar.gz.asc
Provvediamo a confrontare la firma ottenuta con i sorgenti scaricati, utilizzando un tool di gestione quale potrebbe essere GNU Privacy Guard:
~$ gpg httpd-2.0.54.tar.gz.asc
gpg: Signature made lun 11 apr 2005 23:06:14 CEST using DSA key ID DE885DD3
gpg: Impossibile controllare la firma: chiave pubblica non trovata
Qui incontriamo il primo ostacolo. Non possiamo controllare la bontà dei sorgenti, dato che non abbiamo la chiave pubblica corrispondente. Da notare che l’identificativo della chiave pubblica messa a disposizione dal gestore di questa versione dei sorgenti per verificare la loro integrità è:
DE885DD3
Il problema è di facile soluzione: basterà utilizzare un gestore pubblico di chiavi per scaricare quella corrispondente all’identificativo indicato. Nel nostro caso useremo keyserver.linux.it, il quale è fornito anche di una comoda interfaccia web che facilita notevolmente il compito a chi si trova un po’ a disagio nell’utilizzo di gpg:
~$ gpg –keyserver keyserver.linux.it –recv-key DE885DD3
gpg: requesting key DE885DD3 from hkp server keyserver.linux.it
gpg: key DE885DD3: public key “Sander Striker ” imported
gpg: non è stata trovata alcuna chiave definitivamente affidabile
gpg: Numero totale esaminato: 1
gpg: importate: 1
Abbiamo installato la chiave pubblica che ci interessa, prendendola da keyserver.linux.it: dato che i key server sono interconnessi fra di loro e si scambiano le chiavi, ognuno può scegliere quello che ritiene migliore e più affidabile.
Possiamo ora verificare che la firma apposta ai sorgenti sia buona e lo faremo utilizzando la chiave fornita da Sander Striker tramite il key server:
$ gpg httpd-2.0.54.tar.gz.asc
gpg: Signature made lun 11 apr 2005 23:06:14 CEST using DSA key ID DE885DD3
gpg: Good signature from “Sander Striker ”
gpg: aka “Sander Striker ”
gpg: ATTENZIONE: questa chiave non è certificata con una firma fidata!
gpg: Non ci sono indicazioni che la firma appartenga al proprietario.
Impronta digitale della chiave primaria: 4C1E ADAD B4EF 5007 579C 919C 6635 B6C0 DE88 5DD3
Attenzione. Abbiamo una buona e una cattiva notizia:
La buona notizia consiste nel fatto che la firma sui sorgenti è buona;
La cattiva è che la chiave con cui abbiamo gestito la verifica non è affidabile.
Chiunque potrebbe creare un chiave pubblica corrispondente a una firma falsa sui sorgenti scaricati e indurci a credere che sia tutto a posto. Dobbiamo fare un passo ulteriore: siamo costretti a verificare che la chiave connotata dall’identificativo DE885DD3 sia stata creata davvero da Sander Striker, ovvero dobbiamo validarla:
$ gpg –fingerprint DE885DD3
pub 1024D/DE885DD3 2002-04-10
Key fingerprint = 4C1E ADAD B4EF 5007 579C 919C 6635 B6C0 DE88 5DD3
uid Sander Striker
uid Sander Striker
sub 2048g/532D14CA 2002-04-10
In questo caso abbiamo verificato l’impronta della chiave che abbiamo scaricato, ma nemmeno questo è sufficiente. Ciò che ci potrebbe aiutare è entrare in un web of trust, ovvero costruire una rete di referenti affidabili, da cui abbiamo ricevuto direttamente l’impronta delle loro chiavi e quindi siamo sicuri della loro identità. Se una delle maglie di questa rete ci porta a qualcuno che ha firmato la chiave di Sander Striker, potremo considerare affidabile la chiave di quest’ultimo e tutte le chiavi da lui firmate. Il metodo più affidabile per verificare la chiave di qualcuno è scambiare l’impronta “de visu”, in modo da essere sicuri di chi ci sta fornendo l’informazione, ma questo è possibile solo per i nostri referenti diretti. Per poter ovviare al problema di incontrare faccia a faccia Sander Striker, operazione difficile e scomoda, possiamo scaricare dal sito del progetto Apache il file
http://www.apache.org/dist/httpd/KEYS
contenente le chiavi pubbliche degli sviluppatori di Apache. Dato che gli sviluppatori hanno firmato reciprocamente le loro chiavi, considerando valide le chiavi pubbliche di uno, verranno considerate valide tutte:
$ gpg –edit-key DE885DD3
gpg (GnuPG) 1.4.1; Copyright (C) 2005 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
gpg: controllo il trustdb
gpg: non è stata trovata alcuna chiave definitivamente affidabile
pub 1024D/DE885DD3 created: 2002-04-10 expires: mai usage: CSA
trust: undefined validity: sconosciuto
sub 2048g/532D14CA created: 2002-04-10 expires: mai usage: E
[ unknown] (1). Sander Striker
[ unknown] (2) Sander Striker
Comando> trust
pub 1024D/DE885DD3 created: 2002-04-10 expires: mai usage: CSA
trust: undefined validity: sconosciuto
sub 2048g/532D14CA created: 2002-04-10 expires: mai usage: E
[ unknown] (1). Sander Striker
[ unknown] (2) Sander Striker
Please decide how far you trust this user to correctly verify other users’ keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don’t know or won’t say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Cosa hai deciso? 5
Do you really want to set this key to ultimate trust? (y/N) y
pub 1024D/DE885DD3 created: 2002-04-10 expires: mai usage: CSA
trust: ultimate validity: sconosciuto
sub 2048g/532D14CA created: 2002-04-10 expires: mai usage: E
[ unknown] (1). Sander Striker
[ unknown] (2) Sander Striker
Nota che la validità della chiave indicata non sarà necessariamente corretta
finchè non eseguirai di nuovo il programma.
Comando> quit
A questo punto, la chiave di Sander Strike è considerata valida a tutti gli effetti. Proviamo ora a verificare i sorgenti:
$ gpg –verify httpd-2.0.54.tar.gz.asc
gpg: Signature made lun 11 apr 2005 23:06:14 CEST using DSA key ID DE885DD3
gpg: controllo il trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model
gpg: depth: 0 valid: 1 signed: 3 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1 valid: 3 signed: 9 trust: 3-, 0q, 0n, 0m, 0f, 0u
gpg: Good signature from “Sander Striker ”
gpg: aka “Sander Striker
La firma è considerata valida ed è stata utilizzata una chiave valida. Ovviamente, se riuscite a farvi dare l’impronta della chiave di prima mano, anche tramite un vostro buon web of trust, l’operazione è da considerarsi ancora più sicura.
Un secondo metodo per controllare l’integrità dell’archivio contenente i file sorgente è costituito nella verifica della sua firma MD5. Senza addentrarci troppo nei dettagli tecnici, possiamo definire la firma MD5 come una stringa a 128 bit (hash) generato in base a una stringa di partenza variabile. Data la stessa stringa di partenza, si otterrà sempre la stessa stringa di arrivo, ma non è vero il contrario: dal codice ottenuto non si può risalire alla stringa di partenza. Quindi, siamo di fronte a un algoritmo definito one way, che non consente praticamente a un malintenzionato di alterare i dati di partenza senza che questi si riflettano nel codice di controllo. E nemmeno è praticamente fattibile creare due stringhe di partenza che diano lo stesso hash finale. Insomma, data l’alta improbabilità di poter alterare la stringa di partenza senza che ciò alteri anche il codice di controllo, è possibile usare la l’algoritmo MD5, dandogli come input l’archivio contenente i file sorgente di Apache, per poi controllarne la stringa di hash con quella generata fornita tramite il sito del progetto: se i due hash corrispondono vi è una probabilità molto alta, talmente alta da dare una certezza pratica, che il file in nostro possesso non sia stato alterato. Controlliamo quindi la firma del nostro file, generandola tramite l’utility md5sum, contenuta nel pacchetto textutils, riversandola in un file temporaneo che confronteremo tramite diff con il file scaricato dal sito di Apache:
$ cat httpd-2.0.54.tar.gz.md5
772503748ffb85301385d47fb2b96eca httpd-2.0.54.tar.gz
$ md5sum httpd-2.0.54.tar.gz > verifica
$ diff verifica httpd-2.0.54.tar.gz.md5
$
L’output generato da diff è nullo, quindi i due file sono identici e ciò significa che la firma generata dal file in nostro possesso è identica alla firma generata con la copia ufficiale di Apache, quindi vi è un’alta probabilità che anche i due file di partenza siano identici.
Patchwork
Una volta ottenuti dei sorgenti affidabili, è necessario assicurarsi che questi siano privi di bachi sensibili.
Il primo accorgimento per evitare problemi nascosti nei sorgenti, consiste puntare all’URL http://archive.apache.org/dist/httpd/patches/ o a un mirror affidabile e aggiornato e controllare se per la versione in proprio possesso esiste una patch critica, che va quindi scaricata nella directory dei sorgenti e applicata utilizzando il comando:
patch -s < nome_patch.patch Questo primo passo è necessario ma non sufficiente a garantire che i sorgenti siano privi di bachi importanti, dato che questi spesso vengono rilevati a distanza dal loro rilascio, evidenziati durante l’utilizzo su numerose installazioni. Per evitare di rimanere con un server afflitto da bachi è necessario rimanere sempre aggiornati sullo sviluppo dei sorgenti, iscrivendosi alla mailing list announce@httpd.apache.org (che è più bollettino che mailing list vera e propria, dato che vi circolano solo gli annunci di nuove versioni o di patch, inviati dalla Fondazione). Se vi saranno aggiornamenti critici, una volta iscritti questi arriveranno comodamente nella vostra casella postale, mettendovi al riparo da future, sgradite sorprese. Mistificazioni Resistere all’attacco di un malintenzionato in gamba è decisamente difficile, ma togliersi di torno l’improvvisato di turno non è un’operazione che richieda grandi sforzi. Un semplice trucco per confondere le acque a chi stia cercando di collezionare più informazioni possibile sul nostro server, come per esempio la versione utilizzata (utile per cercare bachi non patchati), quale PHP o libreria SSL vengano implementate, è abbastanza semplice e richiede la modifica di un solo file header nei sorgenti.
Apache 1.x
Nella configurazione standard, Apache è decisamente “chiacchierone” e rivela fin troppo facilmente la propria versione e i vari moduli compilati, consentendo a chiunque, semplicemente richiamando una pagina esistente, di sapere se sono installati i moduli PHP e SSL e le relative versioni, per esempio. Troppo semplice e troppo invitante soprattutto per uno “script kiddie”, uno smanettone senza troppe competenze ma fornito all’inverosimile di script e programmi in grado di condurre autonomamente una vasta serie di attacchi.
Il nostro scopo, ora, consiste non solo e non tanto nell’ammutolire Apache, ma nel renderlo menzognero, facendogli dire qualche piacevole fandonia. Per raggiungere questo risultato, con i sorgenti della versione 1.x, basterà modificare il file
httpd.h
Nel nostro esempio, utilizzeremo i sorgenti contenuti nell’archivio
apache_1.3.33.tar.gz
Una volta decompresso, entriamo nella directory
apache_1.3.33/src/include
e apriamo in file httpd.h, nel quale troveremo alcune righe interessanti:
#define SERVER_BASEVENDOR “Apache Group”
#define SERVER_BASEPRODUCT “Apache”
#define SERVER_BASEREVISION “1.3.33”
#define APACHE_RELEASE 10333100
#define SERVER_SUPPORT “http://www.apache.org/”
Sono le informazioni contenute in queste direttive a essere utilizzate per generare i messaggi “di sistema” mostrati ai navigatori. Modifichiamoli leggermente:
#define SERVER_BASEVENDOR “Suppa Lovva Group”
#define SERVER_BASEPRODUCT “Lovva Server”
#define SERVER_BASEREVISION “1.2.3.4.x.x.x”
#define APACHE_RELEASE 99887766554433221100
#define SERVER_SUPPORT “http://www.suppalovva.net”
Ora basterà lanciare un semplice
./configure
make
make install
dalla directory radice dei sorgenti, avviare il server, richiamare una pagina inesistente e il risultato sarà quello visibile nella figura sottostante.
Il nostro server appare decisamente strano. Suppa Lovva?
Apache 2.x
In Apache 2.x si può ottenere lo stesso risultato modificando un differente file. Nel nostro esempio, abbiamo decompresso l’archivio httpd-2.0.54.tar.gz, editando il file
httpd-2.0.54/include/ap_release.h
Al suo interno, ritroviamo delle stringhe decisamente familiari:
#define AP_SERVER_BASEVENDOR “Apache Software Foundation”
#define AP_SERVER_BASEPRODUCT “Apache”
#define AP_SERVER_MAJORVERSION “2”
#define AP_SERVER_MINORVERSION “0”
#define AP_SERVER_PATCHLEVEL “54”
Modifichiamole a piacere:
#define AP_SERVER_BASEVENDOR “Free Love Foundation”
#define AP_SERVER_BASEPRODUCT “StupidCupid”
#define AP_SERVER_MAJORVERSION “99”
#define AP_SERVER_MINORVERSION “00”
#define AP_SERVER_PATCHLEVEL “11”
Compiliamo i sorgenti, installiamoli, lanciamo Apache e richiamiamo una pagina inesistente. Il risultato sarà quello mostrato nella figura sottostante.
Volendo giocare con gli header si possono apportare parecchie modifiche
Gli amministratori con uno spiccato senso dello humor potrebbero avere già inteso cosa si può fare giocando con gli header: basta modificare poche righe per simulare le risposte di IIS o di qualche altro server web a piacere.
La direttiva ServerTokens
Se vogliamo rendere la vita ancora più difficile al malintenzionato di turno, possiamo giocare un po’ con la configurazione del file httpd.conf, abilitando la direttiva ServerTokens, che gestisce la quantità di informazioni sul server restituite dagli header inviati da Apache ai client. Questa direttiva, però, è disponibile solo dalla versione 1.3 del server – ovviamente esiste anche nella 2.x, e accetta una serie di modificatori:
ServerTokens Prod(uctOnly)
Viene inviato solo il nome del web server, per es: Server: Apache Server;
ServerTokens Min(imal)
Viene inviata anche la versione, per es.: Apache/1.3.33 Server;
ServerTokens OS
Viene inviato anche il tipo di sistema operativo: per es. : Apache/1.3.33 (Unix);
ServerTokens Full (o senza argomento)
Vengono inviati tutti i dati possibili, compresi quelli relativi ai moduli compilatiServer sends (e.g.): Server: Apache/1.3.33 (Unix) PHP/5.0.5
Attenzione però: questa direttiva può essere abilitata solo a livello di server e non può essere modificata nei singoli host virtuali eventualmente configurati.
Prima di compilare
Questo primo articolo sulla sicurezza in Apache si chiude con un consiglio di buona condotta al momento di configurare i sorgenti per la compilazione del server. Seguendo il sempre valido motto KISS, Keep It Simple Stupid, cerchiamo di mantenere il più semplice possibile i binari installati sul nostro sistema. Certo, compilare monoliticamente o a moduli dinamici tutte le funzioni aggiuntive di Apache può risultare comodo: prima o poi potrebbero servire e non bisogna nemmeno ricompilare. Per una maggiore sicurezza, però, è meglio non avere in giro funzionalità che non vengono utilizzate, magari lasciate attivate per una dimenticanza: meglio non compilare nemmeno ciò che non serve. Già, ma cosa serve? Quali sono i moduli di base, il minimo indispensabile per avere un server web funzionale? Ecco quale è l’insieme minimo di moduli da installare per poter servire pagine senza troppi fronzoli:
httpd_core
Modulo con le funzionalità di base, necessarie all’avvio di Apache;
mod_access
Modulo che presiede alle direttive Allow, Deny e Order per l’accesso condizionato ai namespace;
mod_auth
Modulo che offre l’autenticazione HTTP di base;
mod_dir
Modulo che consente di implementare la direttiva DirectoryIndex, per indicare il file index di una directory;
mod_log_config
Modulo per l’mplementazione delle funzioni di logging;
mod_mime
Gestisce i set di caratteri l’encoding dei contenuti, il linguaggio predefinito delle pagine da servire e i tipi MIME dei documenti e altro ancora. Insomma, gestisce tutte le meta informazioni riguardanti le pagine servite.
Da disabilitare assolutamente, se non utilizzati:
mod_auto_index
Consente di visualizzare il contenuto di una directory priva di file di indice;
mod_info
Fornisce una lista di informazioni sul server, sui moduli compilati e sulle direttive di configurazione.
Conclusioni
Per ora abbiamo finito. Siamo arrivati fino alla configurazione dei sorgenti e compilazione del server. Nel prossimo articolo, approfondiremo quelle direttive di configurazione di Apache, che ci consentiranno di applicare delle direttive sufficientemente restrittive per limitare ragionevolmente la maggior parte degli attacchi più triviali. Una volta configurato in maniera sicura il nostro server, lo sbatteremo in cella, in una chroot jail, dal quale un eventuale aggressore non uscirà molto facilmente.
