Tag: Security

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:

1. Mettere in sicurezza il sistema operativo;
2. Mettere in sicurezza il framework (Apache);
3. 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.

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