|
|
Corso di Sicurezza su Reti IIProf. A. De Santis |
||||
Internet Service Provider 1Gruppo: ISP1
(Internet Service :Provider 1) |
|||||
|
Indice |
IntroduzioneIl corso di Sicurezza su Reti II tenutosi nell'anno accademico 2004/2005 ha portato alla simulazione di rete internet. A tale scopo sono stati formati quattro gruppi, ognuno dei quali aveva il compito di gestire particolari aspetti della simulazione, questi erano CA, ISP2, ISP1, CERT. Questo documento ha lo scopo di illustrare e dettagliare i compiti ed il lavoro svolto dal gruppo ISP1 all'interno della simulazione composto da Sacco Riccardo, Sementina Gaetano, Tufano Carmine. Verranno illustrati i servizi che sono stati offerti, i destinatari di
questi servizi, il modo in cui sono stati offerti e gli strumenti utilizzati
a questo scopo. ISP1 – Internet Service ProviderIl ruolo che svolge il gruppo all'interno della rete è quello di un Internet Service Privider (ISP) . Un'ISP ha lo scopo di fornire ad aziende o privati l'accesso ad internet fornendo loro servizi fondamentali e non per l'utilizzo della rete cui sono responsabili, come ad esempio l'accesso alla rete, la registrazione di domini, spazi web, hosting etc… Spesso capita che gli ISP siano organizzati in maniera gerarchica, cioè alcuni di questi che si trovano ad un “livello superiore”, offrano servizi ad altri ISP che fungono da intermediari con aziende e privati, in modo da smaltire la gestione di utenza.
Esempio di gerarchia di ISP
Nella figura è illustrato un esempio di gerarchia in una rete di ISP. L'ISP A gestisce la Rete A fornendo i servizi di rete agli ISP B e C che forniscono direttamente i servizi agli host collegati alle sottoreti B e C. Nella rete che è stata simulata nel laboratorio della sede di Lancusi, il gruppo dell'ISP1 ha avuto il ruolo dell'ISP A in figura, mentre il gruppo ISP2 ha avuto il ruolo degli altri due. La fruizione dei servizi presso gli “ipotetici” utenti è stata gestita cercando di garantire un margine di sicurezza ed affidabilità degli stessi cercando di inibire attacchi fraudolenti al sistema da parte di utenti “maliziosi”, rappresentati nella simulazione dal gruppo CERT, il quale più che simulare attacchi aveva il compito di testare la sicurezza dei sistemi. MissioneE' ora possibile entrare nel dettaglio illustrando i servizi che sono stati forniti dal gruppo all'interno della rete internet:
Oltre alla fornitura dei servizi sovra elencati il gruppo ha avuto il compito di “metter su” un sistema affidabile ed il più sicuro possibile per evitare attacchi DOS da parte di utenti maliziosi. 1. Scheda tecnica dei serviziI servizi principali offerti dal gruppo sono:
Il primo obbiettivo di un ISP è quello di fornire un’alta qualità dei servizi, si pensi ad una rete priva di DNS, l’utilizzo della stessa diventerebbe ostico a chiunque volesse utilizzarla. Per questo motivo è di fondamentale importanza la scelta di software robusti e contenenti il minor numero di bug e che spesso sono anche i più popolari nel loro campo. Il gruppo quindi si è orientato verso programmi open source ma che allo stesso tempo risultano essere molto popolari. In base a ricerche su internet e consigli offerti dal personale docente si sono fatte le seguenti scelte:
1.1. OverviewLa macchina assegnata al gruppo è stata utilizzata come server DNS all'interno del laboratorio e quindi interrogata da ogni postazione all'interno della rete per fornire i servizi, ben noti, di traduzione dei nomi in indirizzi (Es. https://sr2ca.org à 193.205.160.177). Al fine di fornire un meccanismo di erogazione del servizio semplice da utilizzare, per effettuare operazioni di richiesta di registrazione di un nuovo dominio, è stato sviluppato e pubblicato appositamente sul server web autonomo della macchina utilizzata, un portale web, accessibile all'indirizzo https://isp1.org per:
Requisito base considerato in fase di progettazione, consiste nell'immissione dei parametri riguardanti le informazioni generali sul responsabile del dominio, persona nominata dall'utente che richiede il servizio, ciò poiché tali informazioni verranno utilizzate per la gestione del dominio previsto dal servizio di Whois offerto in correlazione ai servizi di DNS. Il servizio whois viene erogato tramite la gestione di un database acceduto dal demone del servizio, che si occupa di restituire un insieme di informazioni utili associate ad un nome di dominio. Tra le più importanti si può evidenziare:
La modalità di erogazione del servizio, prevede l'utilizzo di un'applicazione client che invoca il demone whois sulla macchina ISP1. In particolare possono essere utilizzati diversi tool per l'invocazione del servizio, quali per esempio visualroute, oppure mediante l'invocazione da riga di comando dell'applicazione “whois -host” , dove -host indica l'indirizzo Ip o nome dell'host del server whois che si vuole utilizzare. Ritornando al servizio di DNS offerto dal sistema, le modalità di
erogazione del servizio si limitano a fare ciò di cui sopra, garantendo
certamente un buon funzionamento, ma solo in ambienti privi di utenze
maliziose. In assenza di contromisure gli attacchi di DNS spoofing e cache
poisoning ad esempio sono inevitabili. 1.2. Servizio DNSL'importanza del funzionamento dei server DNS è vitale ai fini del corretto funzionamento della rete, per questo motivo il sistema deve necessariamente essere gestito in modo semplice ed efficace. Al fine di fornire tutte le funzionalità di cui sopra, il gruppo dell'ISP1 ha utilizzato alcuni tool di gestione volti a migliorare e semplificare la configurazione e manutenzione del servizio. Di seguito saranno presentati oltre ai dettagli relativi al servizio, i manuali d'uso dei principali tool di gestione del server DNS e del sito sviluppato dal gruppo stesso.
1.2.1. Server DNS:Il servizio di server DNS è implementato, in termini di servizi offerti, su due livelli:
Livello di richiesta - Sito web: I manuali relativi il primo strato applicativo possono essere consultati cliccando qui.
Livello di applicazione L'interazione con bind è stata gestita tramite l'utilizzo di un particolare tool, Webmin. Questo tool fornisce un interfaccia grafica per la gestione e la configurazione di diverse funzionalità di sistemi linux/unix, e tra le altre permette una semplice ed efficace gestione del server DNS bind, previa istallazione dello stesso sul sistema. Inoltre Webmin permette l'interazione con bind anche da remoto, funzionalità questa particolarmente utilizzata dal gruppo di lavoro. Ovviamente prima di poter utilizzare Webmin per configurare bind è necessario istallarlo. Una volta fatto ciò si potrà utilizzare il comando named per avviare il servizio di DNS e configurarlo tramite Webmin.
Bind e Webmin: L'istallazione di Webmin avviene allo stesso modo di quella di bind. E' necessario scaricare gratuitamente dalla rete il software, istallarlo ed utilizzarlo per ciò che più ci serve. Da browser, inserendo nell'url dei nomi localhost:10000, poiché Webmin gira sulla porta 10000 del sistema, appare una schermata iniziale che ci permette di selezionare il tool da configurare. Nella sezione network ad esempio è possibile configurare iptables, come è stato fatto dal gruppo per ovvie ragioni di sicurezza. Mentre nella sezione server, che ora più ci interessa è possibile selezionare bind. La schermata iniziale mostra le master zone registrate presso il servizio, di seguito lo screenshot del server bind del gruppo sotto cui sono registrati due domini master.
I domini registrati sono .org e .edu . La zona .org viene detta anche master, e rappresenta un dominio sotto il quale se ne possono registrare altri in modo gerarchico, più avanti vedremo come il sistema mantiene le informazioni sui sottodomini presenti nella master zone org. La seconda invece è una forwarding zone. Spesso i service provider richiedono la gestione diretta di zone, evitando di sovraccaricare il peso del service provider principale. In questo caso il nostro host funge da service provider, e per questo motivo vengono create le forwarding zone. Quando il sistema riceve una richiesta per un sottodiminio di una zona di forwarding, come ad esempio www.sr2ca.edu , il sistema smista la richiesta al server provider presso cui sono registrate. Infatti alla richiesta di un dominio “.edu” il server bind controlla nel file di gestione principale dei domini alla ricerca di informazioni sul dominio richiesto, ma nel campo ad esso associato è presente l'etichetta “forwarding” ed un ip. Quest'ultimo indica al server di smistare le richieste per quel dominio all'ip presente nel campo. Le zone di forwarding a differenza delle master zone e slave zone (queste ultime sono sottozone delle master), diminuiscono le informazioni gestite dal server favorendo una “pseudo-decentralizzazione” delle stesse, in quanto comunque tutte le richieste dovranno passare la prima volta per il server. Uno dei problemi delle zone di forwarding riguarda la sicurezza, poiché, come si vedrà in seguito il protocollo dnssec, illustrato più avanti non permette di firmare richieste per zone di forwarding e non garantisce l'autenticità delle informazioni fornite. Nella seguente schermata è visualizzato il form che Webmin mette a disposizione per effettuare il setting di tutte le opzioni, creare zone di diversa topologia, come master, slave, forward oppure modificare e visualizzare le zone esistenti. La seguente figura è stata visualizzata selezionando la master zone .org.
Sono presenti tutti i domini registrati sotto la zone .org ( in questo caso sono due, ISP1.org e sr2ca.org ) che possono essere visualizzati nel dettaglio e modificati se necessario. Inoltre da qui è possibile creare nuovi domini che faranno parte della zone. 1.2.2. Erogazione del servizioLa registrazione del dominio avviene in due fasi separate, ed in particolare: un membro del gruppo (che assumerà il ruolo di amministratore del servizio di DNS) periodicamente provvederà ad interrogare i database del portale web, al fine di effettuare operazioni di inserimento, modifica e cancellazione dei domini. L'amministratore potrà ricevere tre tipologie di richieste che dovranno ovviamente essere gestite:
La prima richiesta, è gestita interamente dal sito, mentre le altre due non lo sono. Infatti, l'operazione di inserimento ( e cancellazione) di domini, sarà fatta in modo stand-alone, e non tramite sito web; implementazione adottata per favorire il mantenimento sia del portale web che delle infrastrutture che implementano realmente il servizio, nel nostro caso bind. In altre parole una soluzione più automatizzata avrebbe potuto alterare il corretto funzionamento del server DNS e avrebbe esposto ad un rischio maggiore le informazioni di bind. L'amministratore, quindi, inserirà, o rimuoverà i dati a “mano”, nei file di bind, mediante l'utilizzo dell'interfaccia grafica di interazione Webmin, a partire dalle informazioni dal sito illustrate. Oltre ad effettuare tali operazioni, lo stesso amministratore compilerà opportunamente il file contenente i record di whois, a partire dalle informazioni che sono pervenute al sito, riguardo i dati anagrafici del responsabile, in modo da fornire tale servizio, per ogni richiesta di registrazione accettata, sul sito sottomessa. Il portale pertanto rappresenta una sorta di meccanismo di gestione permanente dei dati, che mediante database propri, tiene traccia degli utenti e dei domini correntemente registrati (o sottoposti a richiesta di registrazione). Quindi se un utente ha registrato un dominio, e la procedura di registrazione stessa è andata a buon fine, può utilizzare la macchina assegnata al gruppo ISP1 come DNS, semplicemente impostandolo nei file di configurazione dell'interfaccia di rete che si vuole utilizzare nella navigazione. Sulla base delle affermazioni discusse, si può quindi affermare che, i tempi ed i costi delle elaborazioni necessari alla fruizione dei servizi di DNS dipendono unicamente dall'operatore umano che viene nominato come amministratore, poiché quelli relativi all'uso del portale sono pressoché nulli, ed in parte dalle operazioni che l'utenza deve necessariamente effettuare (setting delle proprietà dell'interfaccia di rete che si vuole utilizzare, effettuare operazioni sul portale web). Inoltre non sono da sottovalutare i costi relativi i software utilizzati, infatti la fornitura del servizio di DNS, necessita dell'esecuzione di Apache Tomcat, come web server per la gestione del portale, della Java Virtual Machine 1.5.04, come supporto al web server, di bind e Webmin per la gestione della risoluzione dei nomi in Ip, di un tool di scrittura nei file (emacs, vi, ecc.) per la scrittura dei file necessari per il servizio whois, delle risorse allocate dal demone whois.
1.2.3. Server WhoisPer quanto riguarda whois invece non è presente un interfaccia grafica, quindi il servizio è utilizzato in maniera testuale digitando da shell il comando whois <nome del dominio>, senza utilizzare nessuna applicazione aggiuntiva (visualroute, ecc.). L'istallazione del servizio viene effettuata scaricando il software ed istallandolo eseguendo gli script configure, make e make install che fanno parte del pacchetto di istallazione del programma. Per poter utilizzare come server whois la macchina del gruppo ISP1 è necessario specificare l'ip del server da interrogare. Di seguito è visualizzato il risultato del comando sul dominio sr2ca.org
L'utilizzo di una particolare macchina come server whois viene specificato utilizzando il parametro –h ed il nome dell'host o l'ip della macchina da interrogare, in questo caso è stato specificato l'ip 193.205.161.170, cioè l'ip della macchina del gruppo. Le informazioni visualizzate sono contenute in un file gestito dal demone swhoisd.conf, o meglio, il demone può solo leggere le informazioni presenti in esso. Il file non è altro che una sorta di database. In esso sono presenti tre tipi di record, ognuno dei quali contiene più informazioni. Questi sono:
Ognuno di questi record contiene più campi che sono informazioni relative al tipo di entità che identificano. In una ricerca possono essere restituiti più record appartenenti ad entità diverse. Questo dipende dal fatto che ad un dominio appartengono informazioni relative al dominio stesso e ai responsabili. In pratica il file può essere visto come tre tabelle, una per ogni tipo di record. Le chiavi di ricerca sono indicate con un punto esclamativo ( ! ) antecedente al campo, questo indica al demone che quando viene effettuata una ricerca può controllare quel campo. Inoltre per ogni campo contrassegnato da punto esclamativo del record viene effettuata una ricerca sugli altri record che hanno lo stesso valore nei loro campi resi visibili all'esterno. Per essere più chiari, ecco un esempio di record presenti in un file swhois.conf:
2. Fase di setupPrima di passare ad una descrizione più dettagliata dei servizi e di come vengono erogati, facciamo una piccola descrizione su dettagli più tecnici. In questa sezione verranno illustrati dettagli inerenti:
2.1. Organizzazione
Sacco Riccardo e Sementina Gaetano: Si sono occupati dell'istallazione dei software: dalla scelta, quasi obbligata, di un sistema operativo Unix-like, in particolare la scelta della distribuzione Mandrake 10.0, l'istallazione dei vari software, siano essi stati scelti per volontà dei singoli partecipanti sia per motivi di dipendenze per l'installazione degli altri software del sistema. I software istallati sono Bind 9.3.1 per la gestione del sevizio di DNS, swhois per la gestione delle informazioni sui responsabili dei domini. E' stato scelto di installare ed utilizzare Webmin, un software di interfacciamento grafico per diverse applicazioni di sistemi linux, tra cui Bind ed iptables. Inoltre si sono occupati della configurazione di iptables, che nonostante l'utilizzo di webmin per l'interfacciamento grafico, non è stata molto semplice.
Sacco Riccardo Update dei software alle versioni più aggiornate, dopo una prima analisi effettuata da parte del gruppo CERT, a pochi giorni dalla conclusione della fase di tuning.
Tufano Carmine Si è occupato della configurazione di Apache tomcat 5.0, della JVM 1.5.04, della configurazione di keytoll e openssl per l'utilizzo di ssl con Tomcat. 2.2. Risorse HardwareA disposizione della simulazione è stato concesso l'utilizzo di un laboratorio. Ad ogni gruppo è stata assegnata una macchina che i gruppi avrebbero potuto configurare come meglio credevano per la fornitura dei servizi richiesti in base al loro ruolo nella simulazione. In particolare l'hardware della macchina messa a disposizione del il gruppo ISP1, e similmente degli atri gruppi, aveva le seguenti caratteristiche:
Problemi riscontrati: Il lavoro di configurazione è stato notevolmente rallentato a causa di ben due rotture hardware che hanno reso indispensabile e difficile la manutenzione fisica del pc in dotazione al gruppo. La seconda rottura ha portato alla sostituzione dell'intero pc. Nonostante tutto il sistema istallato ha continuato a funzionare su una nuova architettura hardware. La fase di sviluppo inoltre è stata notevolmente rallentata dalle scarse risorse messe a disposizione, quali un processore Intel 400MHz e soli 128Mb di memoria RAM. Da un monitoraggio delle risorse risulta che il sistema necessita di almeno il doppio della memoria RAM, per non parlare delle performance in fase di compilazione, l'istallazione di openssl ha richiesto circa un'ora di compilazione! Data la divisione dei compiti effettuata internamente al gruppo, talvolta è stato necessario utilizzare la postazione assegnata come server di richieste SSH. In tal modo è stato possibile aumentare la produttività, ma sempre nei vincoli ben limitatamente delineati dall'HW a disposizione. 2.3. Strumenti Software
I software principali scelti dal gruppo per la fornitura dei servizi richiesti sono:
Per l'implementazione e la fornitura dei servizi di interfacciamento agli utenti sono state utilizzate tecnologie web quali servlet, jsp, xml, DTD, legati a motivi di competenza dei singoli partecipanti del gruppo. Al fine di fornire un portale il più completo possibile, sono state utilizzate alcune librerie aggiuntive, non presenti nel comune ambiente di runtime delle virtual machine di java, tra le quali:
2.3.1. Istallazione SoftwareOltre ai software sopra elencati sono stati istallati altri software aggiuntivi per diversi motivi: in primo luogo per fornire un sistema più sicuro ed affidabile, a questo scopo sono stati istallati OpenSSL 0.9.7g, che deve essere utilizzato per eseguire connessioni cifrate con il server web Apache Jakarta Tomcat., in secondo luogo per necessità dovute alle dipendenze dei software da utilizzare che richiedevano l'istallazione di altri.
3. Fase di tuningIn questo capitolo sono illustrate le operazione volte all'interazione del gruppo ISP1 con gli alti gruppi. 3.1. Servizi Richiesti Presso Gli Altri GruppiL'ISP1 necessita esclusivamente del rilascio di certificati da parte del gruppo CA , al fine di fornire un servizio sicuro di scambio di dati con gli utenti del sito, in particolare con le procedure di registrazione e di login previste. Inoltre ha usufruito spesso delle risorse umane del gruppo CERT, per effettuare fasi di testing ai servizi implementati. L'interazione con la CA è stato richiesto per il rilascio di un certificato da parte del gruppo, al fine di permettere di aumentare il livello di sicurezza del portale web, tale procedura viene di seguito discussa ed illustrata In primo luogo è stato utilizzato il tool incluso nella JVM, keytool, per la creazione di un keystore al quale tomcat si possa riferire per caricare i certificati, mediante l'esecuzione delle operazioni di seguito illustrate, che creano un file, di nome keystore nella current directory.
A questo punto è stato necessario alterare il contenuto del file server.xml di configurazione di Tomcat, in particolare è stato inserito l'elemento xml di seguito illustrato.
Dopodichè è stato necessario generare una nuovo certificato da far firmare alla CA, mediante l'utilizzo di openssl, come viene di seguito illustrato
L'esecuzione della precedente operazione provoca la creazione di due file REQ.pem e KEY.pem, il primo deve essere sottomesso alla CA per generare il certificato autenticato, ciò è stato fatto mediante l'utilizzo dell'interfaccia pubblica che la CA espone all'esterno, come viene di seguito illustrato, vengono prima immessi i dati del certificato, e caricato il file REQ.pem, tra i parametri deve essere evidenziato il ruolo, che nel caso di ISP1 risulta essere Web Server.
Sottomesso il form precedentemente illustrato, accedendo alla lista dei certificati validi è possibile scaricare il certificato in formato PEM, formato questo, richiesto dall'utilizzo di keystore.
Una volta registrato il certificato, è stato scaricato sempre dall'interfaccia pubblica della CA, chiamandolo certAuth, ed importato all'interno del keystore a cui tomcat fa riferimento, come segue.
Il certificato ottenuto, importato nel keystore e correntemente in uso, è di seguito illustrato
3.2. Servizi Richiesti Dagli Altri GruppiSono stati registrati su richiesta dei singoli gruppi i domini con gli ip assegnati alle rispettive macchine. In questo modo collegandosi alla rete locale, ed inserendo come DNS l'ip del gruppo ISP1, o anche quello di uno degli altri gruppi, è possibile visualizzare la pagine dei singoli gruppi inserendo il nome del dominio, invece dell'ip della macchina. Questi sono:
Tutti i domini sono stati registrati mediante l'utilizzo da entrambe le parti (richiedente e fornitore) del portale web, descritto nelle precedenti sezioni e per ognuno è stato creato un record nel file di configurazione di whois,. E' da evidenziare, inoltre, che il gruppo ISP2 gestisce domini di tipo www.loggiamassonica.edu , ciò deriva dalla necessità del gruppo ISP2 stesso di gestire risorse quali ftp.loggiamassonica.edu , mail.loggiamassonica.edu, e quindi di gestire domini di secondo livello, a questi, in particolare, non è stato possibile attuare la politica di gestione utilizzata per gli altri domini, poiché in questo caso è stato necessario ricorrere ad una relazione di delegazione opportunamente configurata con bind, il dominio .edu è stato gestito come una zona di forwarding, come detto in precedenza. Ai fini di testing, inoltre, sono state ricevute e servite diverse richieste di servizi NTP da ISP2 e CERT. 4. CommesseLe commesse sono richieste effettuate dai responsabili della rete. In realtà hanno il compito di simulare eventuali richieste di sviluppo, di studi di fattibilità o di rilascio di eventuali servizi. Ovviamente le commesse differiscono tra i vari gruppi, questo perché ognuno dei gruppi ha diverse competenze e responsabilità. 4.1. Commessa I
Come è possibile vedere dalla traccia, la commessa si divide nella descrizione di tre punti. Nel seguito viene presentata prima una breve descrizione del protocollo DNS, in cui saranno evidenziati i punti in cui il protocollo è vulnerabile ad attacchi da parte di utenti maliziosi, poi viene presentata una descrizione del protocollo Dnssec, in cui sono evidenziate le differenze, o meglio, “le aggiunte” al protocollo DNS. Nel paragrafo successivo invece viene fatta una prima distinzione tra lato server e lato client, e per ognuna delle due entità vengono sviluppati i punti richiesti dalla commessa, in particolare i primi due punti, cioè l'identificazione e la procedura dell'istallazione vengono sviluppati contemporaneamente nello stesso paragrafo, mentre in quello successivo sono mostrati degli esempi di utilizzo dello stesso.
4.1.1. DNS - Breve introduzioneIl servizio di DNS permette di risolvere i nomi di dominio in indirizzi ip. Questo è di fondamentale importanza per l'utilizzo di una rete da parte di utenti umani, si pensi all'idea di dover ricordare solo codici numerici per visualizzare sito web. Il servizio di DNS viene fornito principalmente tramite un meccanismo gerarchico o di delegazione, le richieste vengono inviate ad altri server fino a quando un server che riceve le richiesta non possiede le informazioni richieste. Ecco una richiesta da parte di un host per la risoluzione del nome di dominio www.ripe.net A
Richiesta di risoluzione di un nome La sequenza di numeri rappresentano i messaggi scambiati tra le varie entità per risolvere un indirizzo. Il Revolver fa una richiesta per l'indirizzo www.ripe.net A, questa viene inviata prima ad una cache, che controlla se il record è presente nella cache ed è valido, altrimenti ,come nel caso della figura, inoltra la richiesta ad un primo server DNS, il quale informa il caching forwarder di interrogare un altro server, in questo caso il gtld-server. Allo stesso modo, questo informa il caching farwarder di interrogare un altro server, che viene interrogato e fornisce la risposta al caching farwarder, che prima di inviare la risposta al revolver crea un record nella cache per memorizzare l'informazione che è appena stata ricavata. Naturalmente, come tutti i servizi offerti, anche questo protocollo presenta delle vulnerabilità alla sicurezza. Ci sono vari punti nel flusso di dati in cui un utente malizioso può agire ai danni del sistema.
Punti deboli di una richiesta Nella figura riportata sono illustrati i messaggi scambiati tra le varie entità per la risoluzione di un nome, mentre le frecce indicano i punti in cui può agire un utente malizioso per fornire informazioni errate. Come mostrato dalla figura, ci sono diversi modi in cui quest'utente può agire per fornire informazioni errate, questi sono causati da falle che possono essere sulla:
I dati DNS tra il master server ed il revolver o il forwarder quindi possono essere trafugati o contaminati. Il protocollo DNS non prevede meccanismi di controllo per la validità dei dati, e questo permette ad un utente malizioso di modificare i dati in modo tale che il client riceva informazioni errate oppure può raccogliere le richieste e ottenere tutte le informazioni che gli host si stanno scambiando (spoofing). Per evitare tutto questo e rendere il servizio sicuro si può utilizzare il protocollo dnssec che permette una comunicazione sicura e assicura integrità dei dati.
4.1.2. DNSSEC
Il protocollo DNS definisce le specifiche per fornire un servizio di risoluzione dei nomi, il quale, non avendo forme di autenticazione, è stato spesso oggetto di attacchi. Ad ogni nome di dominio sono associati dei resource record (RR). Questi possono essere di classi differenti e quindi mantenere informazioni differenti, tra i più importanti ci sono ad esempio l'ip della macchina corrispondente al nome di dominio, il TTL (time to live), ecc… Le risposte ottenute da una richiesta di DNS sono rappresentate da un insieme di questi record, che vengono interpretati dal client per ottenere le informazioni necessarie. Un utente malizioso cercherà come prima cosa di alterare i valori degli RR, fornendo così informazioni errate. Per ovviare a questi problemi è stata proposta una sua estensione: il protocollo DNSSEC. Questa soluzione è pensata come un metodo che possa fornire sia un sistema sicuro per mantenere l'integrità dei dati che come una forma di autenticazione per resolver o applicazioni sicure attraverso l'uso di firme digitali crittografate. Queste firme digitali sono incluse nelle zone sicure come nuovi (RR). In alcuni casi la sicurezza può essere fornita anche attraverso server non sicuri. Le estensioni offrono un metodo per la memorizzazione nel DNS di chiavi pubbliche autenticate. Questa memorizzazione di chiavi può supportare servizi di distribuzione di chiavi pubbliche generiche ed anche la sicurezza del DNS stesso. Le chiavi forniscono ai resolver sicuri la capacità di autenticare chiavi di zona oltre a quelle per cui sono stati inizialmente configurati. Le chiavi associate ai nomi del DNS possono essere recuperate per il supporto di altri protocolli. É stato previsto,infatti, il supporto per molti tipi di chiave ed algoritmi. Le estensioni sicure forniscono, infine, un metodo opzionale di autenticazione del protocollo DNS per le transazioni e le richieste. DNSSEC prevede che ogni insieme di RR (RRset) inviato in risposta ad una query, sia accompagnato da una firma digitale generata attraverso la chiave privata dell'origine. Il server DNS destinatario può verificare attraverso la firma digitale l'autenticità e l'integrità del messaggio.
DNSSEC specifica tre nuovi RR:
4.1.3. DNSSEC – Istallazione e UtilizzoL'implementazione del protocollo avviene lato server. La descrizione dell'implementazione descritta nel seguito presuppone l'istallazione del server DNS bind. Oltre a bind, per l'istallazione del protocollo è necessario eseguire alcune procedure per fornire al sistema gli strumenti adeguati, mentre l'utilizzo avviene lato client dove è necessario utilizzare dei comandi specifici del servizio.
4.1.3.1. Dettagli lato server:Il protocollo dnssec è stato implementato per evitare attacchi alla vulnerabilità del tradizionale protocollo di risoluzione dei nomi di dominio. Il gruppo dell'ISP1, a tal fine, ha dovuto ricompilare il software utilizzato come server DNS, cioè bind, aggiornato alla versione 9.3.1, con openssl 0.9.3g. La ricomplilazione del software permette quindi di utilizzare gli eseguibili dnssec-keygen e dnssec-signzone che vediamo ora in dettaglio insieme all'utilizzo fatto da parte del gruppo ISP1 insieme ad alcuni esempi.
Fase di generazione delle chiavi: dnssec-keygenGenera una coppia di chiavi, la chiave pubblica e la chiave privata. Naturalmente sono necessari alcuni parametri che bisogna specificare ed inoltre permette di selezionare alcune opzioni facoltative: dnssec-keygen -a
<alg> -b <bits> -n <type> [options] <keyname> Parametri obbligatori sono:
L'opzione –a permette di scegliere l'algoritmo da utilizzare per la crittografia, naturalmente si tratta di algoritmi asimmetrici che permettono la crittografia a chiave pubblica, tranne per l'ultimo, HMAC-MD5 che essendo un algoritmo di mac viene utilizzato per firmare i dati e permettere il controllo dell'integrità degli stessi. Il parametro –b permette di selezionare la lunghezza, in bit, della chiave di crittografia. L'opzione –n identifica il tipo di entità cui appartengono le chiavi generate, ed infine è necessario specificare il nome dell'entità, cioè il nome cui si riferisce l'entità proprietaria delle chiavi. Di seguito sono riportati i parametri facoltativi che si possono passare al binario. Opzioni facoltative:
L'output ottenuto dal commando dnssec-keygen consiste di due file, un file per la chiave privata ed un file la chiave pubblica. Nella simulazione, il gruppo ISP1 ha identificato la zona .org con il protocollo dnssec. Di seguito sono riportati i comandi eseguiti per generare le chiavi e l'output ottenuto che consiste di due file, uno .key che contiene la chiave pubblica e l'altro .private che contiene ovviamente la chiave privata. In realtà nella figura riportata sono state create due coppie di chiavi di lunghezza diversa.
I valori che compongono il nome dei file della chiave non sono casuali. Il primo valore indica l'algoritmo di crittografia utilizzato, mentre il secondo indica tag della chiave utilizzati. Per configurare una chiave si inserisce un record nel file di configurazione di bind named.conf come questo:
Questo record permette di configurare una chiave che può essere utilizzata per permettere il trasferimento aggiungendo nel record di un dominio l'opzione “allow transfer”, come ad esempio:
Fase di firma della zona: dnssec-signzone.Una volta generati i file delle chiavi si può firmare la zona. A questo scopo si utilizza l'eseguibile dnssec-signzone che assegna e firma le zone tramite chiavi che le vengono passate in input. Più precisamente, dnssec-signzone genera il record nxt e sig e produce una versione firmata della zona, in pratica genera un file org.hosts.signed dal file originale generato da bind org.hosts. Se è presente una chiave di autenticazione per la zona genitore, allora la firma della zona genitore viene incorporata nel file firmato della zona firmato che è stato generato. Dnssec-signzone necessità di due argomenti che sono: La zona da firmare, quindi il file che contiene i domini della zona da firmare; Il nome del file delle chiavi senza estenzione, in modo da prendere entrambi i file. Inoltre è possibile specificare altri parametri, in particolare il gruppo dell'ISP1 ha utilizzato l'opzione –o, per indicare che il nome del file passato non è una zone name. Di seguito è riportato il prompt dell'esecuzione dell'operazione di firma dei file
L'output dell'operazione è il file org.hosts.signed simile all'originale org.hosts, ma che a differenza di quest'ultimo contiene dei dati aggiuntivi, in particolare contiene la chiave di crittografia delle zone. In realtà nell'esempio riportato la zona è stata firmata con due chiavi.
Fase di pubblicazione delle zone firmate.L'ultima fase è quella di pubblicazione delle zone firmate che consiste nel modificare il file di bind “named.conf”. Questo contiene le informazioni sulle master zone e ogni zone possiede un record con informazioni su di essa ed il file della zona di bind. Nel caso del gruppo ISP1, cui è registrata la master-zone “.org”, il file named.conf contiene un record del tipo:
La pubblicazione consiste nel modificare il record file aggiungendo un .signed alla fine della stringa, in modo tale che ora il campo faccia riferimento al file che contiene anche le informazioni crittografiche sulla zone. Infine per settare il resolver name server per la verifica si devono settare le chiavi pubbliche che si ritengono sicure come entry point nel file named.conf. Per fare ciò si deve inserire il seguente record:
Questo indica che la chiave pubblica della zona org è quella che compare tra virgolette dopo i tre interi. Di seguito è riportato il contenuto del file named.conf dove è presente la chiave della zone “.sec”
Casi particolari:Il gruppo dell'ISP2 ha richiesto la delega di un particolare dominio, “.edu”, che gestisce direttamente. In questa situazione il ruolo del gruppo ISP1 e quello di delegare la gestione dei servizi di DNS al gruppo ISP2. La delega è un caso che non può essere gestito da dnssec direttamente sul gruppo dell'ISP1, in quanto non è possibile farlo, l'unica soluzione prevista è quella di incaricare il gruppo ISP2 della gestione della sicurezza delle zone auto-gestite, in pratica anche l'ISP2 dovrebbe implementare il servizio dnssec.
4.1.3.2. Dettagli Lato ClientL'utente necessita di utilizzare il comando dig lato client per verificare l'autenticità dei dati ed il livello di sicurezza fornito, come integrità dei dati, autenticità dei dati. I dettagli sull'utilizzo e interpretazione del risultato sono spiegati nel seguito della sezione.
Utilizzo del servizioPer testare la zona sicura lato client è necessario utilizzare il comando dig nel seguente modo:
Il campo server rappresenta l'indirizzo ip della macchina che il cliente deve interrogare per ottenere informazioni sul sito specificato. Di seguito è riportato parte del risultato del comando dig che interroga la macchina dell'ISP1 per ottenere informazioni sul sito ISP1 registrato presso la zona .org:
In realtà è possibile anche evitare di specificare l'opzione +dnssec nel comando dig, ma verranno restituite meno informazioni lato client.
Output del comando digL'output restituisce informazioni sulla query che vengono restituite dopo il tag flag. Questi specificano se i dati sono autenticati, se è richiesta la ricorsione per l'autenticazione, etc… 4.2. Commessa II
4.2.1. Cosa è NTP:Il Network Time Protocol (NTP) è un sistema per la sincronizzazione del tempo di orologio dei calcolatori attraverso la rete Internet. Ne sono state definite 3 versioni: la 1 nel 1988, la 2 nel 1989 e la 3 nel 1992. La versione corrente è la 3 che è compatibile con le precedenti.
4.2.1.1. Principali caratteristiche di NTP:
4.2.1.2. Principio di funzionamento:Un server primario NTP, detto anche di strato 1, è un calcolatore collegato ad un orologio di alta precisione di riferimento e dotato di un software NTP. Altri calcolatori, detti di strato 2, dotati di un software similare, chiedono la sincronizzazione del proprio tempo di sistema al server primario che risponde con dei messaggi di sincronizzazione, il tutto in modo automatico. I calcolatori di strato 2 possono a loro volta sincronizzare altri calcolatori, detti di strato 3, e così via fino a 16 strati. Man mano che ci si allontana dallo strato 1 la precisione della sincronizzazione diminuisce. In questa struttura, ciascun calcolatore può essere contemporaneamente server per le macchine di strato inferiore che si sincronizzano su di esso e client per la macchina di strato superiore a cui esso stesso si sincronizza. Ogni server può avere alcune centinaia di client, quindi il numero di macchine sincronizzabili indirettamente da un singolo server primario è praticamente illimitato. Per rendere il sistema più affidabile, un client può avere più di un server di strato superiore . In questo caso, il software NTP misura continuamente le caratteristiche di stabilità e precisione dei possibili server, scegliendo di volta in volta come riferimento quello con le migliori caratteristiche.
4.2.2. NTP – Istallazione e Utilizzo
4.2.2.1. Istallazione di NTP
Installazione Demone NTPDDopo aver scaricato da Internet il pacchetto NTP 4.2.0 in formato tar.gz è necessario scompattarlo con il comando
Ottenendo cosi una cartella contenente i sorgenti del demone. Dopo aver ottenuto i privilegi di root è necessario eseguire le seguenti operazioni:
In questo modo il demone viene installato sulla macchina in questione. Il pacchetto scaricato non fornisce il file di configurazione del demone, per questo motivo è stato necessario creare il file ntp.conf all'interno della directory /etc/. Il seguente listato rappresenta il file di configurazione di NTPD:
##################################################
##################################################
La prima riga serve ad indicare al demone che deve fornire il servizio all'interno della rete locale. La keyword status indica a che livello l'applicazione deve funzionare, ed in particolare più è alto il livello minori problemi si avranno nella sincronizzazione. Infatti come è possibile vedere dalla schermata seguente.
Brevi considerazioni:Il meccanismo di funzionamento, che è stato illustrato prima, non è semplice e spesso può creare alcuni problemi legati alla sicurezza o a mancate sincronizzazioni, però in alcuni casi diventa indispensabile avvalersi di un servizio di questo tipo come nel caso in cui due o più sistemi debbano avere sempre la medesima ora, come nel caso del salvataggio di documenti sul sistema la cui data deve essere considerata affidabile. Spesso l'utilizzo di questo servizio ha generato problemi di sicurezza, ecco perché alcuni timeserver consentono accessi autenticati e cifrati ed ecco perché se il nostro sistema fornisce questo servizio ad altri host è bene regimentarne l'accesso attraverso l'opportuna direttiva (restrict). Nel caso di studio non è stato però possibile restringere l'accesso al server in quanto tutti i pc della rete simulata in laboratorio hanno lo stesso indirizzo di rete, in particolare l'intenzione era quella di far accedere al servizio solo le macchine assegnate ai gruppo ISP2 e CA esculento la macchina assegnata al CERT.
GRUPPI COINVOLTIISP2, CERT, per la richiesta di aggiornamento dell'orario del loro sistema.
4.2.2.2. Utilizzo del ServizioL'utente usufruisce del servizio di Network Time Protocol in maniera differente a seconda del sistema operativo che utilizza. L'immagine sottostante raffigura l'avvenuta sincronizzazione dell'orario con la macchina assegnata al gruppo ISP1 ( indirizzo ip: 193.205.161.170). Il client in questione utilizzava in sistema operativo Windows XP.
Per poter raggiungere la seguente schermata è necessario andare nel Pannello di controllo di Windows->Data e ora->Ora Internet ed inserire l'indirizzo ip corretto. Per quanto riguarda i sistemi operativi Unix, la sincronizzazione avviene tramite terminale bash, ed in particolare eseguendo il comando:
Nel caso di utilizzo della macchina dell'ISP1 il comando completo è:
Da segnalare che è necessario possedere i privilegi di root per poter eseguire il comando. Bibliografia
• http://jakarta.apache.org/tomcat/tomcat-5.0-doc/ssl-howto.html Link del sito relativo al web server Jakarta ed alla configurazione dello stesso con ssl per l'utilizzo del protocollo https.
Link del sito relativo al web server tomcat. Su questo link è possibile scaricare il software ed è possibile trovare tutte le informazioni di supporto necessarie all'istallazione dello stesso.
• http://www.openssl.org/ OPENSSL : the Open Source toolkit for SSL/TLS Link relativo alla libreria di sistema openssl, in questa sezione è possibile recuperare informazioni relative all'istallazione ed alla configurazione per l'utilizzo della cifratura e l'esecuzione di transazioni sicure. Inoltre da questo link è possibile scaricare gratuitamente l'ultima versione di openssl.
Link relativo al tool Webmin. In questo link è presente una sezione tutorial per l'utilizzo del tool ed inoltre è possibile scaricare gratuitamente lo stesso.
• http://www.isc.org/index.pl?/sw/bind/ Link relative al software bind, da qui è possible scaricare gratuitamente l'ultima versione del server DNS, presenti link relativi agli rcf ed i bug riscontrati nelle varie versioni precedenti.
Link relativo al software swhois, da questa URL è possibile raggiungere la sezione di download del sostare, è possibile eseguire il software interrogando il sever del sito e sono presenti link alle sezioni tutorial.
Link relativo al software che implementa il servizio NTP. Sono presenti link alle sezioni di download, tutorial, e alle news relative alle varie release, come report dei bug.
Link relativo al servizio di DNSSEC. In questa URL sono presenti link agli rcf relativi al servizio di DNSSEC, un link alla sezione tutorial in pdf, una sezione riguardanti il servizio di DNS e news relative al protocollo. |
||||
