Abstract.

L'Istituto zooprofilattico sperimentale dell'Abruzzo e del Molise "G. Caporale" ha usato software libero fin dal 1994. In questo articolo si riassume i vantaggi offerti da questa scelta e il sistema più importante attualmente gestito dall'I.Z.S.A.M: l'anagrafe bovina italiana.

L'ingresso dell'Opensource nell'I.Z.S.

Fin dalla fine del 1994 l'I.Z.S. ha dato credito al software libero grazie all'introduzione del server web Apache quale principale server web pubblico dell'istituto e grazie all'introduzione, nella INTRANET dell'istituto, di software quali Squid come proxy server e come Inn quale server di feed delle news.

Immediatamente successiva all'introduzione di tali servizi su prodotti opensource e alla naturale esigenza di dover fornire contenuti dinamici basati sulle basi dati che l'istituto gestiva e gestisce è nata l'esigenza di creare degli script di interfacciamento a questi DB.

Anche in questo caso la scelta è caduta su un prodotto opensource: il perl.

Nel 1998 la rete dell'I.Z.S. inizia ad essere un punto di riferimento per le informazioni veterinarie a livello nazionale. Oltre a questo, l'avanzare della cultura del cracking e il pericolo di intrusioni non desiderate fanno nascere un'esigenza sempre più pressante di sicurezza in ambito informatico. E' di quest'anno l'introduzione, nella border-line della connettività dell'IZS, di un firewall Linux basato su ipchains. [Inserire il discorso del transparent-bridging]

Nel 2000 (?) l'aggiornamento del firewall Linux alla suite netfilter + iproute2 dei kernel della versione 2.4.x di Linux e l'utilizzo delle funzionalità di "statefull inspection", "tracking connection"[1] permettono all'I.Z.S. l'utilizzo di una seconda linea di connettività senza la necessità di acquisto di un ulteriore router ed evitando la pratica per diventare Autonomus (??) System per la gestione del protocollo di routing di Internet: il BGP.

Le nuove funzionalità di source-NAT assieme al marking dei pacchetti nel processo di PREROUTING permettono la navigazione di determinati calcolatori tramite la nuova connettività, mentre la funzionalità di destination-NAT permette ad alcuni dei server pubblici dell'istituto di essere visibili anche attraverso la seconda linea.

L'anagrafe bovina entra nell'I.Z.S.

All'inizio del 2002 nasce l'esigenza di esportare su Internet parte dei dati presenti nell'anagrafe bovina italiane e questo porta alla necessità di risolvere problemi quali la sicurezza, la crittografia dei dati, l'alta affidabilità ed efficienza del servizio oltre alla necessità di dover garantire una scalabilità dell'architettura in termini di numero di richieste contemporaneamente soddisfabili.

La richiesta è quindi che l'architettura del sistema poggi le sue fondamenta sui seguenti capisaldi:

1. sicurezza, con l'adozione di un firewall e con la crittografia dei dati;

2. scalabilità in termini di efficienza e numero di richieste soddisfabili;

3. affidabilità cercando di limitare al minimo i punti di "single point of failure" ed il tempo di fermo macchina in caso di crash [trovare il nome esatto]

Sicurezza della rete dell'anagrafe bovina

Una naturale conseguenza dell'esperienza maturata è stata l'adozione della suite netfilter + iproute2 per la protezione della rete [mettere un po' di roba in più...dove è stato messo il fw, le regole, il routing].

Per la crittografia dei dati si è deciso di utilizzare il prodocollo sicuro HTTPS tramite l'utilizzo del modulo opensource OpenSSL per apache.

Scalabilità del servizio

Per l'attuazione di questo capisaldo si è deciso di costruire un'infrastruttura a quattro livelli così strutturata:

[disegno]

• un layer di bilanciatore

• un layer di server HTTPS

• un layer di server HTTP

• un layer per la base dati

La scelta di un'architettura a quattro livelli è stata fatta in base alle considerazioni di seguito esposte.

La separazione in due livelli tra lo strato di connessione TCP/IP e quello di applicativo HTTPS è stata dettata dalla dualità di dover apparire, da un lato, all'esterno, come un unico server web (indirizzo www univoco) e dall'altro lato, la necessità di dover scalare l'infrastruttura al crescere delle richieste distribuendo queste su più server.

A tal fine, il bilanciatore, basato su un server Linux RedHat con un applicativo opensource scritto in C, riceve le connessioni TCP/IP sulla porta HTTPS (443)  e distribuisce le richieste ad una lista di server tramite uno scheduler round-robin verificando anticipatamente la raggiungibilità del server escludendo quelli non attivi.

Il server HTTPS elabora la richiesta come si vedrà in seguito e restituisce la risposta al bilanciatore che la rimanda al client.

Relativamente ad una singola transazione HTTPS, il bilanciatore si comporta sostanzialmente come un proxy sock TCP/IP.

Questa divisione in due livelli del processo di connessione HTTPS tra client e server ha inoltre il vantaggio di poter spostare il layer 2 (i server HTTPS) su di una rete privata accessibile al solo bilanciatore che rimane l'unica macchina direttamente accessibile da Internet semplificando così la configurazione del firewall di border-line perchè dovrà proteggere il solo bilanciatore.

Per capire come mai lo stato di applicativo sia stato ulteriormente suddiviso in due livelli va tenuto conto del funzionamento standard di un server SSL la cui attività può essere macroscopicamente suddivisa in tre step:

1. verifica del certificato e decifratura della richiesta,

2. soddisfazione della richiesta,

3. cifratura della risposta.

Dato che una richiesta SSL è mediamente quattro volte più lenta di una corrispondente richiesta HTTP e la differenza risiede nei processi di cifratura e decifratura nel primo e nell'ultimo step, si è deciso di utilizzare due livelli di elaborazione: uno dedicato al primo e al terzo stepp e l'altro dedicato al processo centrale che equivale ad una usuale richiesta HTTP.

Questa separazione ha permesso di ridondare i servizi HTTPS con macchine low-cost ed avere un unico server HTTP in cluster con risorse di sistema adeguate all'esecuzione dei processi di interrogazione al database.

Un altro vantaggio è dato, nonostante la ridondanza e la scalabilità data dai server HTTPS, dalla centralizzazione dei contenuti nell'unico server HTTP, semplificando in tal modo la manutenzione del servizio.

Nel prosieguo analizzeremo in dettaglio l'infrastruttura tecnologica dei tre livelli in cui sono state utilizzate soluzioni opensource in quanto per motivi di high-availability, affidabilità ed efficienza dello strato DB e non offrendo il mercato una soluzione opensource, si è optato per un sistema Oracle in cluster.

Bilanciatore

[Da fare]

Server web HTTPS

Chiaramente, vista l'esperienza, si è scelto il server web Apache con modulo OpenSSL[2] e mod_perl[3]. Apachhe offre la possibilità di personalizzare e alterare il funzionamento interno del processo di elaborazione della richiesta tramite il modulo mod_perl.

Questo era per noi essenziale per poter realizzare la separazione tra la parte strettamente legata all' SSL (decifratura, verifica del certificato, cifratura) demandando la soddisfazione della richiesta ad un server remoto.

A tal fine, il funzionamento standard del server HTTPS doveva essere alterato nella parte relativa al recupero della richiesta (step 2). Il flusso di dati decifrato andava rediretto ad un server remoto su protocollo HTTP per l'effettivo recupero dell'informazione richiesta dal client. Nel caso di presenza di un certificato digitale nel flusso HTTPS si è deciso di alterare il flusso HTTP per comunicare al server remoto le credenziali dell'utente.

La realizzazione di questa processo ha comportato la realizzazione di un modulo di estensione di Apache, detto in gergo "handler"[4] scritto in perl che intercetta la richiesta epurata della parte SSL, ne analizza il contenuto alla ricerca della presenza di un eventuale certificato digitale, ne altera eventualmente il contenuto aggiungendo le credenziali dell'utente  come parametro CGI, invia la richiesta al server remoto attendendo la risposta che viene poi inviata al client (via bilanciatore).

Relativamente ad una singola richiesta HTTPS questo strato agisce quindi come un proxy HTTP convertendo le richieste HTTPS in HTTP, indirizzandole ad un server remoto e incapsulando poi le risposte HTTP nel protocollo HTTPS.

Server web HTTP

Anche questo è un server Apache con script in Perl. [Dire altro].

Conclusioni

Su questa infrastruttura sono stati eseguiti da una ditta specializzata dei stress-test prima di andare in produzione che ne hanno rilevato il corretto funzionamento, l'efficienza e la scalabilità.

Sempre con l'orientamento al software libero sono stati utilizzati gli strumenti di monitoring del sistema dell'anagrafe bovina italiana. E' stato infatti utilizzato Webalizer[5] per analisi dei log dei vari server e MRTG[6] per la visualizzazione grafica dell'utilizzo della banda della connettività ad Internet.

Dall'esperienza acquisita nello sviluppo di questo progetto e particolarmente dal modulo realizzato per i server HTTPS è stato elaborato e distribuito con licenza GPL[7] sul CPAN[8] il modulo Apache::Request::Redirect[9] per il forward di richieste HTTP a server remoti.