Network Security teoria

TCPI pacchetti TCP posseggono un campo SYN, che serve per quando si vuole inizializzare una connessione, ed un campo SEQ, che è un numero di sequenza; i numeri SEQ, all'inizio della connessione, dovrebbero essere definiti in maniera casuale, nonostante questo le vecchie implementazioni dello stack TCP/IP di BSD usavano numeri SEQ deterministici e facilmente prevedibili.

L'autenticazione del client viene fatta in base al suo indirizzo IP ed al numero di sequenza: Se i numeri di sequenza successivi al primo risultano sbagliati, allora la connessione verrà rifiutata (o i messaggi sbagliati saranno scartati); in teoria, soltanto il client ed il server (e tutti coloro che sono sul percorso dei pacchetti) dovrebbero essere a conoscenza del numero di sequenza: questo è un meccanismo di autenticazione e protezione della connessione mirato ad impedire che chi non si è collegato al server possa sfruttare la connessione altrui per far eseguire dei comandi al server.

Stessa protezione avviene nel senso inverso, dove il client rifiuterà i pacchetti non corretti, impedendo per esempio che venga caricata una pagina web falsa. Ipotizziamo che un attaccante voglia far sì che un server esegua dei comandi, facendo in modo di non essere scoperto (e facendo ricadere la colpa su qualcun'altro). Il primo passo da fare, come anche nel caso di connessioni con protezione crittografica, è studiare il bersaglio, aprendo e chiudendo un numero sufficiente di connessioni a capire qual è la logica con cui il server assegna i numeri che dovrebbero essere casuali SEQ. A questo punto, una volta che l'attaccante ha capito la logica ed ha una ragionevole probabilità di successo, farà sì che il client da incolpare non sia più in grado di operare nella rete, per esempio con un attacco DoS. Lo step successivo è inizializzare una connessione con il server, facendo IP spoofing con l'indirizzo del client:

Potendo prevedere i numeri di sequenza assegnati dal server, riuscirà a bypassare il meccanismo di autenticazione e potrà impartire dei comandi al server TCP. È da notare che tutti i messaggi di risposta dei comandi saranno mandati all'indirizzo del client vittima dell'attacco DoS che, proprio a causa dell'attacco, non potrà mandare un pacchetto RST per chiudere la connessione fittizia, né accorgersi del fatto che qualcuno sta usando il suo indirizzo per portare attacchi nella rete. Di conseguenza, nemmeno l'attaccante potrà avere un riscontro diretto degli effetti del suo attacco, non può sapere se sono andati a buon fine. Quando invece l'attaccante è sul percorso tra il suo bersaglio e l'IP che vuole simulare, allora può tranquillamente aprire una connessione con il server senza preoccuparsi di nulla: sarà in grado di intercettare (e bloccare) tutti i pacchetti e potrà ricevere le

Erano le vecchie versioni di BIND, bastava una semplice richiesta DNS (legittima) per avere tutte le informazioni necessarie per preparare l'attacco. Passiamo all'attacco vero e proprio. Trudy fa una richiesta DNS al resolver, chiedendo per esempio un dominio celebre (e redditizio) come poste.it; prima ancora che il server root DNS possa aver risposto, Trudy invierà una serie di pacchetti con IP spoofing e i valori di porta e transaction ID corretti: in questo modo, il resolver DNS accetterà come valido l'IP fornito da Trudy, sul quale lei ha preventivamente installato un server che simula il sito in questione. Il risultato di questo attacco è che, per un tempo arbitrariamente lungo (scelto da Trudy stessa), il resolver DNS risponderà a tutte le richieste DNS per poste.it indirizzando gli utenti verso il sito-truffa di Trudy, invece che verso il vero sito richiesto dagli utenti.

cache la risposta di Trudy non fa che accentuare, a questo punto, la portata dell'attacco, dirottando un numero probabilmente elevato di utenti verso il sito truffa. Quindi, in conclusione, è preferibile non usare l'autenticazione non crittografica, o almeno è utile affiancarla ad un firewall che divida in maniera chiara chi ha diritto ad accedere ai servizi di un server e chi, invece, non può accedervi.

2c- Servizi di sicurezza nelle reti IP (SSL, TLS, IPSec)

Vogliamo creare dei servizi che rendano la rete più sicura, e vogliamo che questi servizi diventino come i livelli dello stack protocollare TCP/IP: il più possibile indipendenti dagli altri livelli. Gli strumenti che ci permettono di raggiungere questo scopo sono IPSec e TLS, due livelli che si inseriscono nello stack protocollare TCP/IP classico. IPSec è un servizio che si poggia direttamente su IP, è di livello 3; può essere implementato direttamente in hardware, oppure in

software: nel caso di implementazioni hardware, sarà completamente trasparente alla macchina, alle applicazioni e al sistema operativo, mentre nel caso di implementazione software, si deve modificare il sistema operativo. Al contrario, TLS è un protocollo che non prevede modifiche del sistema operativo: deve essere implementato nelle applicazioni. Il problema principale è che TLS è posizionato sopra al TCP, quindi soffre di tutti i difetti del TCP, come l'esposizione agli attacchi DoS e l'esposizione all'attacco del tipo IP spoofing.

Transport Layer Security (TLS)

Il TLS è un insieme di protocolli di sicurezza che lavora, nello stack TCP/IP, sopra a TCP e UDP. L'idea è quella di creare un canale sicuro, che permetta la PFS attraverso delle chiavi effimere, sfruttando come sempre delle credenziali di lungo periodo per l'autenticazione, quali possono essere i certificati X.509, delle chiavi fornite dal KDC Kerberos oppure delle

semplici pre-shared key.

Il protocollo TLS record offre gli stessi servizi del TCP, aggiungendo la sicurezza. All'interno dei suoi pacchetti (trasportati dal record protocol) possono essere veicolati sia dati che i messaggi del protocollo TLS come:

• Handshake protocol è protocollo deputato alla trasmissione di tutti i parametri e le impostazioni dei sistemi di cifratura; si occupa sia della negoziazione dei criptosistemi da usare, sia del calcolo delle chiavi, sia dell'autenticazione;
• Change CipherSpec, un singolo bit che segnala la fine delle trasmissioni dei dati in chiaro;
• Alert protocol, usato per segnalare condizioni di errore.

TLS Handshake protocol: Lo scopo di questo protocollo di handshake è l'autenticazione del server ad Alice ed, eventualmente, anche di Alice al server; oltre a questo, il TLS handshake si occupa di derivare la chiave principale (Master Secret) e le chiavi delle singole connessioni.

Il primo messaggio per instaurare una

connessione lo manda Alice, all'interno del quale vi sono lalista dei protocolli di cifratura che vuole usare ed un numero casuale ; a questo messaggio seguela risposta del server, all'interno del quale viene inserito il criptosistema scelto, un numero casuale, il certificato di del server ed un numero, un session ID.

A questo punto, Alice può scegliere di autenticarsi a sua volta oppure no: se si vuole autenticare, manda il suo certificato digitale e la sua firma su tutti i messaggi precedenti; se invece non vuole autenticarsi, allora manda solo i campi obbligatori del protocollo, cioè la versione cifrata con la chiave pubblica di Bob del pre-shared master secret PMS e la versione cifrata, usando come chiave il PMS, dell'MDC dei pacchetti precedenti.

La risposta finale da parte del responder sarà la versione cifrata, con il PMS come chiave, dell'hash dei messaggi precedenti.

Una volta che questi messaggi sono stati scambiati ed accettati, tra i due

calcolatori è instaurata unasessione TLS. L'autenticazione di Bob nei confronti di Alice è possibile grazie al fatto che Bob hadimostrato di conoscere la , la chiave derivata dal pre-shared master secret; la è lunga384 bit. 42Dalla chiave principale possono essere derivate tutte le chiavi necessarie per instaurare unnumero a piacere di connessioni TLS, usando chiavi secondarie diverse; è da notare che la PFS èopzionale, dipende da come viene derivata la chiave . Il traffico dell'utente sarà protetto daqueste connessioni TLS, all'interno del protocollo record TLS.L'autenticazione di Bob ad Alice avviene attraverso un certificato digitale; quando questo certificatoviene mandato, viene anche mandata un insieme di certificati digitali di tutte le certificationauthority CA che potrebbero essere utili ad Alice per risalire ad una CA di cui si fida e, quindi, perfidarsi del certificato di Bob; allo stesso modo, se è

richiesta l'autenticazione anche di Alice a Bob, quest'ultimo comunica, assieme alla richiesta di certificato, anche l'elenco delle CA ammesse, cioè di quelle CA di cui Bob si fida.

Quando è attiva una connessione tra Alice e Bob, allora è presente anche una sessione: per questo motivo, quando è necessario aprire una nuova connessione, non serve ricavare una nuova chiave privata, si può semplicemente rinegoziare il criptosistema da usare e derivare delle nuove chiavi temporanee, sfruttando la sessione già esistente: questo può accadere quando si vuole iniziare una nuova connessione, ma anche quando si è usata troppo una chiave temporanea ed è giunto il momento di crearne una nuova, per non rischiare di esporre tutto il traffico alla crittanalisi.

Come avviene la cifratura dei dati? Partiamo da un blocco di dati che arriva dal livello applicativo e deve essere trasmesso, tramite TLS, nella rete. Il primo passaggio da fare è quello di