Sicurezza delle reti IP. Accesso remoto via canali dial-up. Autenticazione di canali PPP. Autenticazione degli accessi remoti

Transcript

1 LEZIONE 16 (37: ) Sicurezza delle reti IP Dopo aver visto tutta questa serie di soluzioni, si possono applicare a protezione delle reti IP. Antonio Lioy < polito.it > Politecnico di Torino Dip. Automatica e Informatica Accesso remoto via canali dial-up rete a commutazione di circuito (RTC / ISDN) rete IP (Internet) Autenticazione di canali PPP NAS (Network Access Server) PPP è un protocollo per incapsulare pacchetti di rete (L3, es. IP) e trasportarli su un collegamento punto-punto reale (es. RTC, ISDN) virtuale L2 (es. xdsl con PPPOE) virtuale L3 (es. L2TP su UDP/IP) tre fasi, svolte in sequenza: LCP (Link Control Protocol) autenticazione (opzionale; PAP, CHAP o EAP) L3 encapsulation (es. IPCP, IP Control Protocol) Cominciamo da un problema: quando io ho un oggetto personale (tablet, smartphone, desktop...) io devo poter accedere alla rete in qualche modo. Questo è uno dei primi punti di controllo in cui posso implementare della sicurezza. - controllare che chi si collega abbia il diritto di usare la rete - se la rete è aperta magari ho necessità di tracciare chi la usa per fini di controllo Una volta esisteva il concetto di dialup. Ora no, ma la storia è identica: abbiamo un client, usiamo un sistema di comunicazione per contattare un endpoint corrispondente all'interno dell' Internet Provider, il quale ha bisogno di un NAS (= trasformatore di segnali dal dominio delle comunicazioni al dominio Internet, ossia trasformare collegamenti concettualmente puntopunto in collegamenti Internet) Per aprire canali di questo genere molto spesso viene utilizzato PPP (Point to Point Protocol). Era nato come protocollo di L2. < Questa in teoria è una forte violazione dei livelli OSI (trasporta un L2 all'interno di un L4) LCP: attivazione dei segnali di controllo per vedere che il flusso di bit avvenga correttamente Per l'incapsulamento si utilizzano protocolli specifici a seconda di quello che vogliamo trasportare Autenticazione degli accessi remoti per accessi dial-up ma anche wireless o virtuali PAP Password Authentication Protocol password in chiaro CHAP Challenge Handshake Authentication Protocol sfida simmetrica i EAP Extensible Authentication Protocol aggancio a meccanismi esterni (sfide, OTP, TLS) PAP trasmette password in chiaro: aveva senso solo su link fisici nell'ipotesi che nessuno riesca a sniffarli CHAP un pochino meglio EAP è lo standard de facto: è un metaprotocollo, una sorta di framework che può trasportare meccanismi di autenticazione diversi

2 PAP Password Authentication Protocol RFC-1334 (oggi siamo a 6000, superold!) user-id e password inviate in chiaro autenticazione solo all attivazione del collegamento molto pericoloso! non dovrebbe dunque mai essere usato CHAP RFC-1994 PPP Challenge Handshake Authentication Protocol (CHAP) meccanismo a sfida simmetrico (basato sulla password) sfida iniziale obbligatoria, possibile ripetere la richiesta (con sfida diversa) durante la comunicazione a discrezione dell NAS chi supporta sia CHAP sia PAP, deve prima offrire CHAP perchè era il protocollo più sicuro Sfida inizale obbligatoria all'apertura del canale. Possibile ripetere la sfida successivamente: indice che si è cominciato a pensare alla sicurezza. Il cattivo si accorge che uno sta usando un sistema a sfida e dunque non riesce a sniffare la password? Fino a prima non importava: il buono si autenticava e il cattivo faceva da MITM cambiando i dati e così via. Da qui la possibilità, in caso di "dubbio", di mandare a sorpresa richieste di autenticazione (MITM intelligenti ovviamente si tirano indietro e lasciano fare di nuovo al buono, ma intanto è un primo passo avanti) OTP generic token card EAP RFC-3748 (esteso da RFC-5247) PPP Extensible Authentication Protocol (EAP) un framework flessibile di autenticazione a livello data-link tipi di autenticazione predefiniti: MD5-challenge (simile a CHAP) keyed-digest altri tipi possono essere aggiunti: RFC-2716 PPP EAP TLS authentication protocol RFC-3579 RADIUS support for EAP EAP - incapsulamento per trasportare i dati di autenticazione usa un proprio protocollo di incapsulamento (perché il livello 3 non è ancora attivo ) caratteristiche dell incapsulamento EAP: indipendente da IP supporta qualsiasi link layer (es. PPP, 802, ) ACK/NAK esplicito (no windowing) assume no reordering (PPP è ordinato, UDP e IP non lo sono!) per non entrare in < un ciclo infinito ritrasmissione (max 3-4 volte) non supporta la frammentazione (compito dei metodi EAP se payload > minima EAP MTU) PAP e CHAP ora caduti in disuso, bisognerebbe trovare EAP dappertutto. Protocollo di autenticazione estendibile per accettare vari tipi di autenticazione: quindi è un framework, più che un protocollo vero e proprio, per fare autenticazione a L2. Ci sono dunque tre tipi di autenticazione predefiniti, ma esistono tanti altri tipi che possono essere aggiunti (ad esempio TLS e RADIUS) Per capire questa slide è bene ricordarsi che siamo a L2, non abbiamo ancora L3 e vogliamo sapere se l'utente Tizio ha il diritto ad entrare in rete oppure no. Proprio perchè L3 non è ancora attivo, EAP deve inventarsi un suo modo per fare cose che si farebbero a L3. Il fatto che l'incapsulamento EAP (dammi i dati di autenticazione e io li trasporto in rete) supporti qualsiasi link layer è una superbomberata: EAP, nato per PPP, oggi si applica a reti 802 (Ethernet, Token ring, Wireless...). Non avendo IP con tutte le sue cose di frammentazione, assemblaggio e così via, bisogna fare ACK/NAK esplicito. Niente windowing, niente reordering (i pacchetti vengono ricevuti nella stessa sequenza di come sono stati inviati: vero fin quando siamo su link PPP, se invece siamo su un finto PPP ad esempio appoggiato su UDP quest'ipotesi non è più vera, cosa sfruttabile da un attaccante per fare cose sporche). Avendo ACK/ NAK esplicito devo prevedere ritrasmissioni. Qualunque protocollo di autenticazione che voglia essere trasportato da EAP deve definire una sua modalità per spezzare il payload.

3 EAP Ipotesi base: il link non è considerato fisicamente sicuro i metodi EAP devono provvedere ai necessari servizi di sicurezza alcuni metodi EAP: EAP-TLS (RFC-5216) EAP-MD5 (RFC-3748) solo autenticazione del client ma non del server EAP-TTLS = tunnelled TLS (permette di operare qualsiasi metodo EAP protetto da TLS) EAP-SRP (Secure Remote Password) GSS_API (include Kerberos) AKA-SIM (RFC-4186, RFC-4187) EAP accetta solo metodi di autenticazione che abbiano sicurezza intrinseca: quindi per intenderci non posso trovare scambio di username e password (PAP). Con EAP TTLS posso teoricamente superare queste limitazioni: potenzialmente, dunque, potrei anche trasmettere username e password in chiaro. Un altro modo è offerto da EAP SRP. E' possibile usare EAP per fare autenticazione basata su dispositivi mobili: EAP sta dunque diventando il protocollo di convergenza tra reti IP tradizionali e reti IP mobili usate nel dominio TLC. TLS EAP - architettura AKA SRP SIM EAP method layer EAP layer L2 di trasporto: dal vecchio PPP, all'802.x. EAP dunque non viene più usato per autenticarsi da casa (802.11: mi autentico su una rete wireless, su reti token ring...). EAP sta dunque diventando un qualcosa di trasversale secondo la filosofia "dammi un livello 2, ti autentico e ti dò accesso al livello 3". E' dunque una sorta di middleware. Non ho bisogno di diventare matto, dunque, per autenticarmi a una rete wireless: se ho fatto degli access point che supportano EAP, tutti i metodi usabili di EAP sono utilizzabili per autenticarmi al wireless (quindi TLS, piuttosto che SIM, piuttosto che SRP...) PPP media layer Autenticazione per collegamenti dial-up Network Access Server utente abilitato? rete IP Si / No, configurazione,... protocol manager Authentication Server utenti config. Accounting si tracciano le risorse "consumate" (es. durata del collegamento, traffico generato) l AS ricopre proprio queste tre funzioni protocolli Le tre A i produttori di NAS dicono che la sicurezza richiede tre funzioni: Autenticazione il richiedente viene autenticato in base alle sue credenziali (es. password, OTP) Autorizzazione si decide se l'azione o il tipo di accesso è permesso al richiedente per vari motìvi (es. audit, costo, prestazioni) dialogando con uno o più NAS tramite uno o più Torniamo ora allo schema di base visto nelle prime slide, che può essere generalizzato. Una volta c'era l'utente col modem ADSL, da qualche parte ci dev'essere un terminatore di comunicazione (l'isp ha una batteria di modem). Questi terminatori sono tutti accentrati sul NAS. Il NAS ha un problema: arrivano delle persone, si autenticano e c'è bisogno di sapere se queste credenziali sono valide o meno. Se io avessi un unico NAS non ci sarebbe problema, se sono un ISP decente ho più di qualche NAS. Ecco allora che i NAS delegano la funzione di verifica a uno specifico authentication server (una cosa simile alla verifica dei token RSA). Il NAS parla con l'as tramite uno specifico protocollo su rete IP (il protocol manager serve dunque perchè AS può parlare vari protocolli). Il NAS, ricevute le credenziali dell'utente, chiede se questo può accedere. AS ha un DB con gli utenti, le credenziali e le configurazioni di rete e sarà in grado di rispondere sì (+ configurazioni) o no. Se noi abbiamo un cattivo attestato sulla stessa rete IP dove ci sono i NAS (che quindi può comunicare con AS, sniffare traffico e così via), quali tipi di attacco può fare? Io potrei voler rubare l'accesso a qualcun altro per impersonificare qualcuno che ha particolari privilegi o più semplicemente per fare cose losche con una maschera. Esattamente come si era parlato di CIA, triade di sicurezza base per le organizzazioni, le aziende che vendono sistemi NAS dicono che la triade di sicurezza è AAA. Autorizzazione: decidere, una volta autenticato l'utente, che cosa può fare l'utente nel sistema.

4 Protocolli di autenticazione via rete (servono per il dialogo tra NAS e AS) RADIUS il più diffuso posso dunque funzionalità di proxy verso altri AS < usare più AS DIAMETER evoluzione di RADIUS enfasi su roaming tra ISP diversi elevata attenzione alla sicurezza (essendo recente) TACACS+ (TACACS, XTACACS) in origine tecnicamente migliore di RADIUS ma meno diffuso perché proprietario Radius è stato pensato per un singolo dominio (un Internet Provider che deve gestire i suoi NAS), ma oggi come oggi si tende a enfatizzare il roaming non solo per la telefonia mobile, ma anche per la mobilità su trasmissione dati. Per questo è stato inventato Diameter. Per un certo tempo è stato utilizzato anche TACACS (evoluto in diverse forme): classico esempio di come non sempre vinca il migliore (protocollo proprietario di Cisco). amministrazione e accounting centralizzato schema client-server tra NAS e AS (accounting) ; unofficial ports: 1645 & 1646/UDP timeout e ritrasmissione server secondari RFC-2865 (protocollo) RADIUS Remote Authentication Dial-In User Service Livingston Technologies (1991) poi IETF supporta autenticazione, autorizzazione e accounting per l'accesso alla rete: all'inizio per porte fisiche (analogiche, ISDN, IEEE 802) esteso poi su porte virtuali (tunnel, accessi wireless) port 1812/UDP (authentication) and 1813/UDP (accounting) ; unofficial ports: 1645 & 1646/UDP RFC-2866 (accounting) RADIUS - RFC RFC-2867/2868 (accounting e attributi per tunnel) RFC-2869 (estensioni) RFC-3579 (RADIUS support for EAP) RFC-3580 (guidelines for 802.1X with RADIUS) Le porte non ufficiali venivano usate da alcune soluzioni. Utilizzando UDP non ho tutta una serie di cose che avrei con TCP, quindi RADIUS implementa timeout e ritrasmissione. Inoltre utilizza server secondari per evitare DoS e per implementare fault tolerance (ogni client RADIUS è configurato per parlare con più RADIUS server: se a un certo punto un RADIUS server non risponde in un tot. di tempo si prova la ritrasmissione e se questa non avviene si decide che il server è guasto o sovraccarico. Bilanciatore di carico automatico!) Si continua a evolvere! Ogni volta che esce qualcosa di nuovo, anche RADIUS viene aggiornato per poter parlare con queste nuove tecnologie. RADIUS proxy il server può fungere da proxy verso altri server di autenticazione NAS 1 NAS 2 alice@win.polito.it barbara server RADIUS alice Windows domain controller barbara UNIX NIS server local RADIUS DB Una delle principali features di RADIUS è quella di poter fare da proxy. Nell'esempio abbiamo due NAS: nel momento in cui un utente cerca di autenticarsi su un NAS manda le sue credenziali in una forma specifica. Se l'utente manda solo il proprio login, questo vuol dire implicitamente che l'utente è definito direttamente sul server RADIUS (quindi il server consulta il proprio DB locale di credenziali). Se la credenziale invece è nella (occhio che non è un indirizzo di posta elettronica ma un identificativo di rete) si ha, come nell'esempio, che l'utente alice è definito nel dominio di sicurezza WIN.polito.it. Il server RADIUS dunque capisce che non può fare il controllo ma deve richiederlo a WIN.polito.it. Ovviamente WIN.polito.it deve essere un dominio che ha avuto una relazione di fiducia con il server. In questo senso dunque si splittano le tre A: autorizzazione e accounting sono fatte direttamente dal server RADIUS, autenticazione può essere demandata a un terzo.

5 (Quali funzionalità di sicurezza ci servono per RADIUS?) Quali funzionalità di sicurezza per Radius? sniffing NAS req (se contiene pwd) confidentiality, privacy fake AS resp (to block valid or allow invalid user) changing AS resp (Y > N or N > Y) authn & integrity of AS resp replay of AS resp (if not properly tied to NAS req) anti-replay of AS resp pwd enumeration (from fake NAS) authn of NAS req DoS (many NAS req from fake NAS) server scalability (dopo averne fatto il padding a 128 bit con NUL): (password pad) md5(key autenticatore) ticatore) t Client: NAS RADIUS: protezione dei dati integrità ed autenticazione dei pacchetti tramite keyed-md5: key = shared-secret tra client e server client senza key sono ignorati password trasmessa crittografata con MD5 Server: AS (slide che è un po' un modo di procedere quando si vuole fare l'analisi di sicurezza di un protocollo) 1. Possibile sniffare: posso sniffare la richiesta del NAS verso l'as. Se c'è una password posso avere problemi. Necessarie confidenzialità (non devo far conoscere la password) e privacy (se uso un sistema a sfida non mi serve confidenzialità, ma già solo sapere che Tizio si è collegato al server non è bello). 2. Sniffo la rete, vedo risposte dall'as, posso provare a mandarne di fasulle. 3. Se non protette opportunamente, si possono cambiare le risposte (sì diventa no). 2+3 li paro facendo autenticazione e integrità. 4. Se una volta ho visto una risposta che mi dice solo "sì", la posso usare per un'altra macchina. Necessario che le risposte siano indirizzate a una specifica richiesta. 5. Mi sostituisco al NAS: so che c'è un utente rossi, comincio a provare tutte le possibili pwd. Necessaria autenticazione del NAS. 6. Mando tonnellate di false richieste NAS per sovraccaricare i server. La scalabilità è implicita nell'architettura RADIUS. LEZIONE 17 Adesso vediamo se RADIUS offre queste caratteristiche di sicurezza o meno. Lo scopo è quello di calcolare il rischio residuo, in quanto non possiamo MAI avere sicurezza del 100%. Cominciamo con la protezione dei dati trasmessi tra NAS e AS. E' vero che oggi molti usano EAP (quindi di per sè sarebbero metodi applicativi abbastanza sicuri), ma RADIUS è abbastanza generalizzato e può trasportare anche PAP. Per questo motivo i pacchetti vengono protetti con keyed MD5. La password, se trasmessa nel pacchetto, viene cifrata o per meglio dire offuscata (ossia si fa quello che viene descritto nella formula, che ci facilita la decifratura in quanto l'operazione inversa dell'xor è ancora l'xor). C'è dunque confidenzialità (insomma) e zero privacy (sniffando il traffico di rete so chi si sta collegando) RADIUS autenticazione dell utente tramite PAP, CHAP, token-card e EAP CISCO fornisce server per CryptoCard altri offrono SecurID formato degli attributi TLV (facilmente estendibile senza modificare l installato): All'inizio c'erano accoppiamenti obbligati. In generale RADIUS è molto estendibile perchè utilizza attributi nel formato TLV. Questo ci permette, in caso di evoluzione, che vecchi server possano continuare a funzionare perchè anche se non sanno trattare i nuovi attributi ne conoscono la lunghezza e quindi è possibile scartarli. attribute t Type Length Value RADIUS - formato code identif length - Codice: 8 bit - Identificativo del pacchetto: 8 bit - Lunghezza complessiva: - Autenticatore (fondamentale per evitare replay) - Attributi in formato TLV autenticatore... attributi...

6 RADIUS - pacchetti ACCESS-REQUEST contiene le credenziali di accesso (es. user + pwd) ACCESS-REJECT pacchetto di risposta accesso negato (es. a causa di errato user/pwd) ACCESS-CHALLENGE richiede info addizionali dall utente (es. un PIN, token code, pwd secondaria) ACCESS-ACCEPT ( parameters ): pacchetto di risposta accesso consentito con specifici parametri di rete per SLIP/PPP : IPaddr, netmask, MTU,... in passato per terminali: host, port RADIUS - autenticatore duplice scopo: autenticare la risposta del server ed evitare replay mascherare la password in Access-Request: unico scopo: avere identificatore che si chiama Request Authenticator sta viaggiando sono 16 byte random generati dal NAS verso server in Access-Accept A / Reject ect / Challenge si chiama Response Authenticator si calcola con un keyed-digest: md5 (code ID length RequestAuth attributes secret) type length value RADIUS - alcuni attributi type = 1 (User-Name) DN: distinguished name value = text, network access identifier (NAI), DN type = 2 (User-Password) value = password md5 (key RequestAuthent.) type = 3 (Chap-Password) risposta a una sfida value = user CHAP response (128 bit) type = 60 (CHAP-Challenge) value = sfida fatta dal NAS all utente "cifrata" come visto prima Per quanto riguarda il tipo di pacchetti, questi sono quelli fondamentali. Comprendendo nel Response Authenticator un md5 derivato anche dal Request Authenticator si tiene legata la risposta a una specifica richiesta: ammazzo gli attacchi replay. NAI (Network Access Identifier) RFC-2486 NAI = username realm ] tutti dispositivi devono supportare almeno NAI lunghi 72 byte la sintassi esatta di username e realm è descritta nell RFC (si noti che include solo i caratteri ASCII < 128 ma li include tutti) notare che lo username è quello usato per l autenticazione PPP (che può non coincidere con quello applicativo) Già visto in precedenza, assomiglia a un indirizzo mail. Tra parentesi quadre indicati parametri opzionali. Nota che l'utilizzo della parola realm (reame) non si traduce in un supporto automatico di Kerberos, sarebbe più corretto parlare di "dominio di sicurezza". Idealmente nel NAI, nonostante la restrizione sui caratteri ASCII < 128, ci potrebbero essere anche caratteri non stampabili.

7 Esempio - CHAP + RADIUS PPP CHAP / Challenge-Request CHAP / Challenge-Response CHAP / Success IPCP NAS RADIUS / Access-Request: - CHAP-Username - CHAP-Challenge - CHAP-Password RADIUS / Access-Accept: - parametri, XXXXXXXXXXXXXXXX RADIUS server Vediamo un esempio di come si mischia RADIUS a una sfida CHAP: 1) l'utente cerca di collegarsi: il NAS gli manda una CHAP Challenge Request 2) l'utente manda la sua CHAP Challenge Response 3) NAS costruisce un pacchetto di Access-Request che contiene al suo interno tanti attributi). In particolare, si presti attenzione alla CHAP-Password: il NAS può verificare solo il contenuto della sfida, ma non può spingersi oltre... 4)... dunque deve chiedere al RADIUS Server. RADIUS allora manda un pacchetto "tutto ok" coi parametri di rete da configurare per quel client 5) I parametri vengono deincapsulati e mandati dentro al pacchetto CHAP Success. Il dialogo XXX è un dialogo "non sicuro". DIAMETER (voluto e spinto dai gestori di reti mobili) evoluzione di RADIUS particolare enfasi sul roaming tra ISP diversi RFC-3588 Diameter base protocol RFC-3589 Commands for the 3GPP RFC-3539 AAA transport profile RFC-4004 Diameter mobile IPv4 application RFC-4005 Diameter network access server application RFC-4006 Diameter credit-control application RFC-4072 Diameter EAP application Sicurezza di DIAMETER protezione obbligatoria con o TLS: client Diameter DEVE supportare e PUO supportare TLS server Diameter DEVE supportare e TLS configurazioni obbligatorie: () ESP con algoritmi non nulli sia per autenticazione sia p per riservatezza (TLS) mutua autenticazione (client DEVE avere un certificato a chiave pubblica) X509 (TLS) DEVE supportare RSA+RC4_128/3DES+ MD5/SHA1 e PUO usare RSA+AES_128+SHA1 indispensabile nel caso di reti wireless prime implementazioni: grandissimo successo! IEEE 802.1x Port-Based Network Access Control: architettura di autenticazione per il livello 2 (MAC - Media Access Control) utile sugli switch di reti wired per bloccare l accesso alla rete # Windows-XP e access-point wireless Cisco (nel PDF si descrive tutta l'architettura) specificato nell'rfc Comprendere ora la sicurezza di DIAMETER non è facilissimo, in quanto serve a rendere sicuro L2, ma si utilizzano protocolli dei livell 3, 4 e 5. è la soluzione standard proposta da IETF per fare sicurezza a L3. TLS è il sistema di sicurezza standard per il Web (HTTP ma non solo). Al posto di inventare soluzioni nuove, come aveva fatto RADIUS, DIAMETER si basa su soluzioni già definite ai livelli superiori. ESP: formato cifratura pacchetti IP. Fornisce autenticazione, integrità e sicurezza a livello 3. La prima tripla è abbastanza vecchiotta. Si può usare la seconda che è un po' meglio. Tutto quanto abbiamo visto rientra in un quadro più generale (non è obbligatorio da usare in questo quadro) che si chiama IEEE 802.1x. x non è un numero a caso, ma sta a indicare la soluzione definita dall'ietf per Port-Based Network Access Control, ossia fare controllo degli accessi in rete basato su porte distinte. # quando oggi si fa il cablaggio di un nuovo edificio, in ciascuna stanza si mettono n punti rete, magari non tutti usati. Magari una stanza che prima era un ufficio ora diventa una sala d'aspetto, in cui ci sono delle prese Ethernet. E io, stronzo da fuori, mi prendo un bel cavo e faccio l'amico di tutti x dunque si propone di rispondere alla domanda "chi c'è dietro il cavo?". Utile per le reti wired (magari le prese non portano alla rete), INDISPENSABILE per reti Wireless (non esiste modo per limitare chi cerca di accedere agli Access Point)

8 IEEE 802.1x framework per autenticazione e key-management 802.1x può derivare chiavi di sessione da usare per autenticazione, integrità e segretezza dei pacchetti sfrutta algoritmi standard per la derivazione delle chiavi (es. TLS, SRP, ) servizi di sicurezza opzionali (autenticazione o autenticazione+cifratura) ti i if t 802.1x è un framework generale (un qualcosa che ospita vari tipi di soluzioni): * autenticazione (sapere chi si sta collegando, dargli il permesso oppure no) * key-management (fondamentale fatto a questo livello nel caso di reti Wireless perchè la tratta tra lo user terminal e l'access point è intercettabile facilmente) semi-public network / enterprise edge supplicant 802.1x - architettura authenticator / ethernas (es. Access Point or switch) 802.1x - vantaggi enterprise or ISP network RETE IP authentication server (es. RADIUS) sfrutta il livello applicativo per l effettiva implementazione dei meccanismi di sicurezza conversazione diretta tra supplicant e AS # NIC e NAS agiscono come pass-through ## device nessun cambiamento su NIC e NAS per ### implementare nuovi meccanismi di autenticazione perfetta integrazione con AAA IP Da un punto di vista architetturale, 802.1x non inventa nuovi protocolli ma dice come implementare protocolli esistenti per implementare questa visione. C'è un punto di accesso alla rete: un access point Wireless, uno switch per rete cablata. Prende il nome di autenticatore o semplicemente ethernas (concetto di NAS applicato a reti 802 in generale). Si chiama autenticatore perchè siede su un confine: a destra ho una rete fidata, a sinistra una rete semipubblica o una rete aziendale, coi terminali degli utenti. I terminali non a caso si chiamano supplicant, perchè "supplicano" di collegarsi. A seconda dell'utilizzo di Wireless o LAN userà un tipo particolare di EAP. Quando il pacchetto giunge sull'autenticatore lui fa solo da passacarte ma deincapsula e reincapsula la richiesta (tira fuori il pacchetto EAP dal L2 e incapsula dentro RADIUS). In questo modo dialoga con l'authentication server. Al ritorno si fa il procedimento inverso. Fin quando l'autenticatore non riceve un OK, l'autenticatore scambia solo pacchetti dei tipi riportati a SX. Questo oltre a essere un meccanismo di autenticazione, diventa un meccanismo di audit anche per i buoni. # concettualmente ## devono solo incapsulare e deincapsulare ### facilmente estendibile # qui in sostanza si incapsula/deincapsula al bisogno 802.1x - messaggi laptop Ethernet port connect switch Ethernet server Radius access blocked EAPOL # RADIUS EAPOL-Start EAP-Request/Identity EAP-Response/Identity Radius-Access-Request EAP-Request Radius-Access-Challenge EAP-Response (credentials) Radius-Access-Request EAP-Success Radius-Access-Accept access allowed Un laptop desidera collegarsi via Ethernet alla porta di uno switch, già collegato in Ethernet verso un server RADIUS. 1) Aggancio il cavo ma lo switch mi sbertuccia: porta bloccata Lo switch però nota che c'è attività elettrica, quindi inizia uno scambio EAPOL: 2) Il laptop manda EAPOL-Start 3) Lo switch chiede "Ok, dimmi chi sei" (request identity) 4) "Sono l'utente Tizio, voglio collegarmi" (response identity) Il pacchetto viene deincapsulato dallo switch e reincapsulato... 5)... in una Access-Request RADIUS 6) AS manda una sfida (messa in un EAP request) 7) Il client risponde con le credenziali 8) Credenziali mandate in una nuova access request (più ricca) 9) Il server accetta (dall'altra parte arrivano i parametri di rete) Nel momento in cui io scollego il cavo lo switch potrebbe accorgersi che manca segnale e quindi cessare automaticamente il collegamento. Rispetto allo schema CHAP-RADIUS il NAS è un po' più stupido (prima era lui a mandare la sfida).

9 A quale livello di rete è meglio realizzare la sicurezza? Application Presentation Session Transport Network Data Link Physical firewall? IPSEC? smart-card? apparati cifranti? guardie armate? Fin qui abbiamo esaminato i primi due livelli, ovvero come collegarci in rete facendo un controllo di autenticazione e anche un minimo di sicurezza (802.1x è in grado di generare chiavi simmetriche per proteggere il canale). L'amministratore di rete è parecchio in crisi quando gli chiedono di implementare nuove soluzioni. Livello Presentation ingrigito, perchè siccome fa semplicemente una "trasformazione" dei dati è l'unico livello in cui non si prevedono meccanismi di sicurezza. più si resta in basso nello stack e più sarà Livello ottimale? più si sale nello stack e più le funzioni saranno specifiche (es. possibile identificare l utente, i comandi, i dati) ed indipendenti d dalle reti sottostanti ma più saranno possibili attacchi di tipo DoS possibile espellere in fretta gli intrusi ma i dati su cui basare questa decisione saranno più scarsi (es. solo indirizzo MAC o IP, no utenti, no comandi) Sicurezza a livello fisico protezione fisica: del supporto trasmissivo degli amplificatori / ripetitori / convertitori tipicamente solo in reti chiuse (es. militari, governo, alta finanza) AMP CONV e - e - e - γ Prima di iniziare questo excursus, facciamo una considerazione generale: esiste un livello ottimale in cui implementare la sicurezza? La risposta è NO. In generale più saliamo nello stack di rete, più le funzionalità disponibili sono specifiche: se posiziono i miei livelli di sicurezza troppo in alto, gli attaccanti possono agire indisturbati nei livelli inferiori (es.: DoS). Viceversa, se seguo la filosofia opposta (voglio cacciare i cattivi il prima possibile) ho pochissime informazioni disponibili per scacciare i cattivi. Il rischio è quello di prendere decisioni errate e cacciare via anche i buoni. Un buon compromesso è quello di fare qualcosa ai livelli inferiori per "sgrossare" via i pivelli: le decisioni migliori però le possiamo fare solo quando ho più In tantissimi se ne sbattono altamente del livello fisico, che invece non è da sottovalutare. Pericoli sui cavi, sugli amplificatori, sui convertitori... insomma, qualunque cosa è attaccabile! Ha senso proteggere questi oggetti? Sì, potrebbero tagliarmeli, metterci accoppiatori induttivi, piegare la fibra (in caso di fibre ottiche) in modo da leggere i dati trasmessi mediante accoppiatore ottico. Chiaramente non posso proteggere tutto il livello fisico, ma posso comunque farlo all'interno della mia organizzazione. Non è dunque un'idea del cazzo prevedere lucchetti ai tombini, oppure fare tubi con gas (se vengono aperti li sgamiamo al volo) cavi elettrici fibra ottica Misure di sicurezza a livello fisico Inoltre, per cercare di minimizzare sin dalla progettazione della rete lo sniffing, si possono usare reti sniffing. usare reti switched (ossia 10baseT o 100baseT) per eliminare lo sniffing: evitare gli hub evitare derivazioni multiple sulla stessa porta dello switch proteggere gli armadi / locali che contengono le apparecchiature di rete proteggere i cavedi / pozzetti norme TEMPEST (ambienti militari) per la progettazione di apparecchiature ed edifici per eliminare le radiazione elettromagnetiche emesse (corridoi a spirale: radiazioni rimbalzano, deboli quando escono)

10 Sicurezza a livello data-link apparati cifranti per proteggere i dati a livello 2 (MAC) possibile farlo... solo per segmenti con tecnologia omogenea LAN spezzoni di WAN Saliamo a L2. Se noi abbiamo fatto sicurezza a L1, boh, basta, amen, lo consideriamo sicuro (o non ce ne frega niente). Se io ad esempio cifro i dati me li puoi anche intercettare, tanto non capisci niente. Il pericolo resta quando dal L2 si passa al L3: il L2, infatti, può non essere omogeneo. All'interno di una LAN sì, c'è omogeneità. Collegando diversi L2 un po' meno (gli apparati deincapsulano e incapsulano quando si trovano a maneggiare protocolli diversi, togliendo protezione ai dati). router router ethernet ISDN frame relay Sicurezza a livello data-link sebbene esistano schede cifranti da installare sui client, normalmente non si protegge il livello 2 sulle stazioni i ma solo su tratte tt geografiche puntopunto si comincia a pensare la gestione della LAN associata a quella della sicurezza: VLAN switch con porte protette tte (es x) allarmi automatici al comparire di un nuovo MAC assegnazione statica degli indirizzi IP no a DHCP completamente dinamico Sicurezza del DHCP protocollo non autenticato facilissimo attivare shadow server attacchi possibili da parte del falso server: denial-of-service fornisco configurazione di rete sbagliata MITM logico fornisco configurazione i con subnet da 2 bit + default gateway uguale alla macchina che vuole essere MITM facendo NAT si intercettano anche le risposte In generale queste schede non si usano molto. Il L2 viene protetto solo su tratte geografiche punto-punto. Si tenga presente che ogni volta che un cavo passa sul suolo pubblico, questo viene considerato esterno all'organizzazione. Le VLAN, ad esempio, possono essere utili per segmentare la rete al fine di aggiungere sicurezza. Chi usa come unico meccanismo le VLAN però è estremamente attaccabile. Si fa poca attenzione ai MAC (bisognerebbe segnalare quando si collega un dispositivo con MAC sconosciuto). Inoltre, ai fini di forensic analysis, l'assegnazione statica sarebbe meglio rispetto all'assegnazione dinamica dell'indirizzi. Dunque bello DHCP per assegnare gli indirizzi, ma sarebbe meglio che a un MAC taldeitali venga dato un IP taldeitali. L'alternativa è tenere un log per anni. Parliamo un po' di DHCP. Protocollo usatissimo (lo usa il router ADSL per darti gli indirizzi a casa), ma fa cagare. Intanto perchè non è autenticato e quindi è facile che qualcuno faccia finta di essere il vero DHCP (shadow server). Fornire una configurazione di rete sbagliata alla lunga è sgamabile (uno si allarma, chiama e riceve la configurazione di rete corretta). Un attacco figo è quello di mandare una configurazione per la quale io, MITM, entro nella stessa sottorete del buono. PROBLEMA FONDAMENTALE, tutti continuano ad ignorarlo. Protezione del DHCP alcuni switch (es. Cisco) offrono: DHCPsnooping = solo risposte da trusted port IP guard = solo IP ottenuti da DHCP (ma ci sono limitazioni sul numero di indirizzi che si riesce a trattare) RFC-3118 Authentication for DHCP messages usa HMAC-MD5 per autenticare i messaggi scarsamente adottato Il DHSCPsnooping presuppone che il sistemista abbia identificato con precisione a che porte sono attaccati i DHCP. RFC-3118 sarebbe LA soluzione. L'idea è quella di usare un keyed digest per autenticare i messaggi. C'è, esiste una implementazione per Linux ma è scarsamente adottato. Inoltre c'è il problema della key distribution (bisognerebbe usare tante chiavi distinte per evitare il problema che a sua volta un client si spacci da server).

11 Sicurezza a livello network protezione end-to-end per reti omogenee a livello logico (es. IP) possibile anche creare VPN (Virtual Private Network) per proteggere solo una parte del path server rete IP router LEZIONE 19 Concentriamoci ora sul L3. Particolarmente interessante perchè è il primo livello dove incontriamo delle reti omogenee a livello end to end (IP). Posso fare sicurezza di rete perchè non ho più il problema di cambio protocollo come su L2. Interessante anche per la creazione di VPN (proteggere la comunicazione tra due reti fidate quando il traffico passa per reti non fidate). A L3 dobbiamo controllare la sicurezza su client e server. router client Che cos è una VPN? una tecnica (hardware e/o software) per realizzare una rete privata utilizzando canali e apparati di trasmissione condivisi o comunque non fidati ENI Milano FIAT Torino rete "pubblica" FIAT Melfi ENI Roma Le VPN dal punto di vista commerciale sono di grande interesse. Le aziende infatti comprano facilmente HW ma hanno difficoltà a installare nuovo SW. Per realizzare sicurezza end 2 end è necessario installare dei software su tutti i peer che stanno comunicando, ragion per cui molte aziende preferiscono demandare a terzi la protezione della tratta esterna realizzando una VPN. Nell'esempio per "rete pubblica" si intende una rete non direttamente gestita dall'ente che vuole fare sicurezza. FIAT può voler collegare le proprie sedi in Italia: il gestore della rete pubblica "colora" i pacchetti in uscita dalle sedi con lo stesso colore e sui propri router mette regole di instradamento per far scambiare pacchetti di un certo colore solo tra chi ne ha diritto. Va da sè che non si può colorare il pacchetto: il modo in cui verranno colorati ci aiuta a fare considerazioni di sicurezza. Dove si applica una VPN? quando si attraversa una rete pubblica e/o non fidata... nei seguenti due casi:... per comunicazioni intra-aziendali tra sedi remote (Intranet)... per comunicazioni inter-aziendali chiuse tra aziende che si sono previamente accordate (Extranet) Si applicano solo in questi casi proprio perchè come abbiamo visto i pacchetti vanno colorati: - se siamo all'interno della stessa azienda il gestore "assegna" il colore - in una Extranet abbiamo comunque accordi a priori. Dove NON si applica una VPN? quando si attraversa una rete pubblica e/o non fidata per comunicazioni inter-aziendali senza accordi precedenti... per comunicazioni con clienti non noti a priori (commercio elettronico di tipo business-to- consumer) In questo caso cambiano gli scenari applicativi. - se non concordiamo il colore prima non possiamo fare comunicazioni sicure - ho aperto un sito web e accetto clienti da tutto il mondo: come faccio a dire ai clienti (che nemmeno conosco) il colore da usare in maniera sicura?

12 Tecniche di realizzazione di una VPN mediante reti nascoste mediante routing protetto (tunnel IP) mediante protezione crittografica dei pacchetti rete (tunnel IP sicuro)...ovvero come "colorare" i pacchetti qualcuno: 1. VPN mediante rete nascosta le reti da collegare utilizzano un indirizzamento non standard per non essere raggiungibili da altre reti (es. reti nascoste IANA secondo RFC-1918) è una protezione facilmente superabile se scopre gli indirizzi usati può leggere i pacchetti in transito ha accesso all infrastruttura di comunicazione 2. VPN mediante tunnel i router provvedono ad incapsulare i pacchetti di rete all interno di altri pacchetti IP in IP IP over MPLS altro ad hoc i router controllano l accesso alle reti mediante ACL (Access Control List) La rete 10.x.x.x e la rete x.x non sono state assegnate dalla IANA. Non essendo univocamente assegnate, chiunque le può usare: non esistendo instradamento univoco non sono raggiungibili, se non localmente. Alcuni network provider, all'interno della loro infrastruttura di rete, ritagliano spazi di indirizzi corrispondenti ai colori. PRO: - semplice CONTRO: - facilmente superabile se scopro gli indirizzi usati - chi controlla l'infrastruttura può leggere i pacchetti in transito Estremamente debole dal punto di vista della sicurezza. Per evitare il problema in cui uno dei clienti fa il furbo e si assegna un indirizzo non appartenente alla sua rete, ma a quella di un'altra azienda, è possibile realizzare le VPN mediante tunnel. Tu nella tua rete fai pure quello che vuoi, quando il mio pacchetto arriva a me, router, io ti apro un tunnel verso le altre tue sedi. Diverse tecniche. In questo modo il provider è più protetto rispetto ai clienti furbacchioni, ma non vale il viceversa. Inoltre se gli attaccanti riescono a intrufolarsi nel provider, i problemi restano. protezione superabile da chi gestisce i router o da chi può comunque leggere i pacchetti in transito border router del network provider v A B R1 VPN mediante tunnel IP rete pubblica R1 R2 A B R2 A B R1, quando incapsula, verifica nella ACL che B sia all'interno della rete2 a cui A ha il diritto di accedere. In caso affermativo si tratta tutto il pacchetto # come payload e viene aggiunto un altro header (##) con indirizzo di destinazione pari a quello di R2. Quando si arriva su R2 si deincapsula e si smista. rete1 A B rete2 IPv4 header ( end-to-end ) TCP/UDP header + data # IPv4 header ( tunnel ) IPv4 header ( end-to-end ) TCP/UDP header + data ##

13 Quando si fa IP in IP si corre il rischio della... Tunnel IP: frammentazione se il pacchetto da trasmettere ha la massima dimensione consentita, allora deve essere frammentato t massimo degrado = 50% soffrono maggiormente gli applicativi con pacchetti grandi (tipicamente non interattivi) In teoria dunque da un pacchetto possiamo averne due. Maggior sofferenza su pacchetti grandi (file transfer, download). Non è un problema di sicurezza ma è bene notare che implementando questa soluzione di sicurezza posso avere problemi di prestazioni. 3. VPN mediante tunnel IP sicuro prima di essere incapsulati i pacchetti di rete vengono protetti con: digest (per integrità ed autenticazione) cifratura (per riservatezza) numerazione (per evitare replay) se gli algoritmi crittografici sono forti, allora l unico attacco possibile è impedire le comunicazioni anche detta S-VPN (Secure VPN) Se vogliamo protezione bidirezionale tra client e fornitore si deve realizzare il tunnel in maniera sicura. Questo vuol dire che il cliente prima di dare il proprio pacchetto al network provider lo protegge adeguatamente a seconda delle funzionalità che vuole applicare. La soluzione più corretta. Le altre due fanno un po' cagare. VPN mediante tunnel IP sicuro I TAP (Tunnel Access Point) identificano i punti in cui vengono fatte le operazioni crittografiche. Le frecce che rimbalzano raffigurano il fatto che il tunnel non è attaccabile. rete pubblica R1 TAP1 TAP2 R2 rete1 TAP3 rete2 architettura IETF per fare sicurezza al livello 3 sia in IPv4 sia in IPv6: creare VPN su reti non fidate fare sicurezza end-to-end se implementato sugli definisce due formati particolari: end node AH (Authentication Header) per integrità, autenticazione, no replay ESP (Encapsulating Security Payload) per riservatezza (+AH) usa un protocollo per scambio chiavi: IKE (Internet Key Exchange) Come realizzare sicurezza end to end? Essendo IP un protocollo standard, gestito da IETF, IETF stessa ha definito uno specifico protocollo per proteggere IP. Fare sicurezza end to end significa non domandarla più al fornitore di servizi. Per fare questo vengono definiti due nuovi tipi di header IP. ESP fa quasi tutte le funzioni di AH e in più aggiunge riservatezza. Esistono due formati perchè pochi pacchetti hanno bisogno di riservatezza, ma tutti hanno bisogno di integrità e autenticazione. Cosi quando voglio tolgo la riservatezza che è computazionalmente pesante. Per fare autenticazione, integrità e riservatezza ovviamente servono delle chiavi, tipicamente simmetriche. Mi serve dunque un protocollo diverso per gestire le chiavi, definito nell'architettura IPSec, ovvero IKE.

14 Servizi di sicurezza autenticazione dei pacchetti IP: integrità dei dati identificazione del mittente protezione (parziale) da attacchi di tipo replay riservatezza dei pacchetti IP: cifratura dei dati Identificare il mittente non si può fare con l'ip, esiste l'ip spoofing. Cifratura dei dati ok, ma in che senso? Payload? Pacchetto? Security Association (SA) connessione logica unidirezionale protetta tra due sistemi ad ogni SA sono associabili caratteristiche di sicurezza diverse occorrono due SA per avere protezione completa di un canale bidirezionale di un canale bidirezionale Se si vuole fare sicurezza con IPSec bisogna creare delle SA. Due SA, una per ogni verso di comunicazione, per proteggere un canale bidirezionale. Se B deve dare solo degli ACK ad A implementiamo riservatezza su A,B e tutto il resto su B,A. Ecco perchè si usano due SA: così abbiamo più flessibilità SA (A, B) SA (B, A) Database locali SPD (Security Policy Database) contiene le security policy da applicare ai diversi tipi di comunicazione configurato a priori (es. manualmente) oppure agganciato ad un sistema automatico (es. ISPS, Internet Security Policy System) SAD (SA Database) elenco delle SA attive e delle loro caratteristiche (algoritmi, chiavi, parametri) Per gestire le SA ogni nodo IPSec ha bisogno di 2 database, tipicamente un file con un indice associato (solo concettualmente un a base dati). Ogni pacchetto trasmesso in rete ha l'indicazione di appartenenza a una certa SA. Consultando il SAD conosco le caratteristiche di una particolare SA. Come funziona (spedizione) SPD SAD pacchetto IP quale policy? regole di sicurezza crea / legge SA algoritmi / parametri pacchetto IP con modulo Vediamo come vengono usati SAD e SPD in fase di spedizione. Da L7 stiamo pian piano scendendo verso il fondo. Se si usa IPSec il pacchetto di L3 non va direttamente a L2 ma viene intercettato. Il modulo IPSec intercetta tutti i pacchetti IP in uscita e si chiede: - che policy è da applicare? (= il pck è da proteggere?) * se no, vado a L2 * se sì guardo che regole di sicurezza sono da applicare * se è il primo scambio di pacchetti tra due nodi devo creare un SA e memorizzarlo per non crearlo di nuovo in futuro, altrimenti la leggo * il SAD mi restituisce algoritmi e parametri da applicare Dopo averli applicati ho pronto un pacchetto da mandare a L2.

15 - seconda versione Nella prima si erano scordati di fronteggiare replay. novembre 1998 RFC-2411 = document roadmap RFC-2401 = architecture RFC-2402 = AH RFC-2403 = HMAC-MD5-96 in ESP e AH RFC-2404 = HMAC-SHA-1-96 in ESP e AH RFC-2405 = ESP DES-CBC con IV esplicito it RFC-2406 = ESP RFC-2410 = cifratura nulla in RFC-2451 = algoritmi per ESP CBC La cifratura nulla serve per chi non vuole implementare sia AH che ESP. Si implementa dunque ESP che fa tutto, ma si usa una cifratura nulla. In questo modo mi riconduco ad AH. Servono per setup e scambio chiavi - scambio chiavi RFC-2407 = interpretazione di ISAKMP RFC-2408 = ISAKMP RFC-2409 = IKE RFC-2412 = OAKLEY Header IPv Vers. IHL TOS Total length Identification Flags Fragment offset TTL Protocol Header checksum Source IP address Breve reminder. Si noti che si sta parlando di autenticazione e integrità: per fare questo genere di protezione si calcola un digest sui dati. Il dramma è che, ad esempio, il campo TTL cambia tra mittente e destinatario. Prestare dunque attenzione a quali dati includere quando si calcola il digest. Notare, inoltre, il campo protocol: il suo significato è stato esteso. Se usiamo IPSec possiamo trovare come protocollo, per esempio, ESP. Un trucco per dire che nella parte di payload ci sarà anche la parte di ESP. Ovviamente da qualche parte c'è scritto il vero protocollo di L4. Destination IP Address Options Padding Si poteva fare di meglio? Sì, ma ora non è proprio il momento di cambiare l'header dei pacchetti IP. Header IPv4 indirizzi IP (32 bit) del mittente e del destinatario IHL (Internet Header Length) in 32-bit word TOS (Type Of Service): mai usato (!) Length: n. di byte del pacchetto IP Identification: ID del pacchetto (per i frammenti) Flags: may/don t fragment, last/more fragments TTL (Time To Live): numero massimo di hop protocol: protocollo usato dal payload

16 in transport mode usato per fare sicurezza end-to-end, ossia usato dagli host, non dai gateway (eccezione: traffico destinato t al gateway, es. SNMP, ICMP) vantaggio: computazionalmente leggero svantaggio: non protegge i campi variabili IPv4 header IPv4 header header TCP/UDP header + data TCP/UDP header + data in tunnel mode usato per fare VPN, solitamente dai gateway vantaggio: protegge anche i campi variabili svantaggio: computazionalmente pesante IPv4 header ( tunnel ) IPv4 header ( tunnel ) # IPv4 header ( end-to-end ) IPv4 header ( end-to-end ) IPv4 header ( end-to-end ) AH TCP/UDP header + data TCP/UDP header + data TCP/UDP header + data Authentication Header meccanismo (prima versione, RFC-1826): integrità dei dati ed autenticazione del mittente obbligatorio keyed-md5 (RFC-1828) opzionale keyed-sha-1 (RFC-1852) meccanismo (seconda versione, RFC-2402): integrità ità dei dati, autenticazione ti i del mittente t e protezione da replay attack HMAC-MD5-96 < keyed digest ridotti HMAC-SHA-1-96 IPSec, quando applicato a un pacchetto IP, si può applicare in due modalità diverse. Questa è la prima. Associata al concetto end 2 end: TM applicato tra due peer che vogliono comunicare direttamente gestendo loro stessi la sicurezza. Applicato tra host (o tra gateway che si comportano da host, come in ICMP). Si prende il pacchetto originale, si "apre" tra l'header e il payload, si inserisce un ulteriore header (#) e si modifica il campo Protocol scrivendo "Io trasporto IPSec". Il vero protocollo sta nel campo Protocol di #. Campi variabili non includibili nel calcolo del digest. Inoltre, se applichiamo cifratura, la cifratura si applica solo al payload (altrimenti i router non possono applicare correttamente gli algoritmi di routing) Se invece vogliamo protezione completa dobbiamo applicare IPSec in tunnel mode. Tipico nelle VPN, ma nulla vieta che lo facciano anche 2 peer. Calcolo un po' più complesso. 1) Prendo il pacchetto originale 2) Lo incapsulo in IP 3) Applico la protezione IPSec al pacchetto del punto 2. La dimensione cresce molto. Inoltre devo creare un tunnel e dunque gestire tutto quello che ne deriva. Proteggo TUTTO quanto il pacchetto originale, ma le modifiche sono più onerose. Ovviamente si può fare tunnel + sicurezza in un colpo solo, ma siccome sono due funzioni diverse ci sono implicazioni tecniche e gestionali (si assume che chi gestisce la rete stia gestendo anche la sicurezza). Passiamo a vedere i formati definiti per implementare le funzioni appena discusse. Nell'RFC base è definito questo. Ovviamente ci sono degli aggiornamenti che ti dicono che è consigliabile usare SHA2, ma in Internet non ci sei solo tu (qualche nodo magari implementa solo SHA1 e quindi non saprebbe cosa fare). AH - formato (RFC-2402) Next Header Length reserved Security Parameters Index (SPI) Sequence number dati di autenticazione (ICV, Integrity Check Value) Questo è quello che viene aggiunto al pacchetto. Ogni riga 32 bit - Next Header (8 bit, per compatibilità con IPv6, contiene il protocollo originale) - Lunghezza del pacchetto - 16 bit riservati - SPI: indice dentro la tabella SAD. Per evitare a ciascun pacchetto di doversi portare dietro tutte le informazioni - SN: da non confondere col TCP SN, serve per evitare gli attacchi replay ma non protegge da cancellazione - 96 bit ICV: forniscono autenticazione e integrità del pacchetto calcolati con un opportuno HMAC.

17 estrazione AH estrazione ICV valore di autenticazione ricevuto mittente autentico e pacchetto integro SPI pacchetto ricevuto sì SAD algoritmo, parametri valori uguali? no normalizzazione pacchetto IP normalizzato calcolo del valore di autenticazione valore di autenticazione calcolato mittente falso e/o pacchetto manomesso Consideriamo il caso in cui un pacchetto protetto con AH venga ricevuto dal destinatario 1) prende il pacchetto IPSec ricevuto e con un'operazione di estrazione tira fuori AH 2) AH contiene lo SPI da considerare 3) Con SPI vado in SAD e conosco algoritmo (MD5, SHA1) e parametri usati (chiave per fare calcolo digest) 4) Il pacchetto ricevuto viene anche normalizzato (metterlo nelle stesse condizioni in cui si trovava sul nodo mittente) 5) Il destinatario calcola il suo ICV. 6) ICV viene anche estratto da AH Si fa un confronto: se valori uguali mittente autentico e pacchetto integro, altrimenti mittente falso e/o pacchetto manomesso. Il mittente viene identificato non con l'ip, ma con lo SPI troviamo la chiave che avevo concordato con qualcun altro. Per questo si parla di autenticazione crittografica. fissare il contenuto del routing header al valore fissare il campo Address Index al valore che avrà a destinazione (change en route) attivo Normalizzazione per AH IPv4 IPv6 azzerare il campo TTL / Hop Limit se il pacchetto contiene un Routing Header, allora: fissare il campo destinazione all indirizzo del destinatario finale che avrà a destinazione azzerare tutte le opzioni che hanno il bit C (change en route) attivo Keyed-MD5 in AH dato M normalizzarlo generando M allineare a 128 bit M (aggiungendo g byte a zero) generando così M p allineare a 128 bit la chiave K (aggiungendo byte a zero) generando così Kp calcolare il valore di autenticazione: Il keyed digest viene calcolato sull'intero pacchetto dopo averlo normalizzato. Quest'operazione la fanno sia mittente e destinatario. ICV = md5 ( Kp M p Kp ) HMAC-MD5-96 dato M normalizzarlo generando M allineare a 128 bit M (aggiungendo g byte a zero) generando così M p allineare a 128 bit la chiave K (aggiungendo byte a zero) generando così Kp dati ip = e op = (ripetuti a formare 128 bit) calcolare la base di autenticazione: ti i B = md5 ( (Kp op) md5 ( (Kp ip) M p ) ) ICV = 96 leftmost bit di B Si prendono i bit risultanti dal particolare algoritmo scelto e si riconducono a 96. Questo perchè sennò si avrebbero header IPSec a fisarmonica. Siccome molti smistamenti si fanno in HW e diventa complicato farglielo gestire, tronchiamo a 96 bit. Cozza un po' con la teoria dei digest lunghi, ma è compensato dal fatto che l'algoritmo viene usato 2 volte. Attualmente i criptomatematici non la considerano una riduzione di sicurezza.

18 ESP Encapsulating Security Payload prima versione (RFC-1827), solo riservatezza meccanismo base: DES-CBC (RFC-1829) possibili anche altri meccanismi seconda versione (RFC-2406): anche autenticazione (ma esclude l header IP, quindi non dà la stessa copertura di AH) riduce la dimensione del pacchetto e risparmia una SA ESP è l'altro tipo di header (pseudoprotocollo) associato per realizzare AH con in più riservatezza. In principio forniva solo riservatezza, per cui bisognava usare due header e avere due Security Association. Poi siccome ci si è resi conto che solo riservatezza non serve a niente, si è passati all'esp di oggi. Posso usare altro oltre a DES, ma anche qui vale il discorso di prima (io solo contro Internet). ESP in transport mode Considerando ESP con la riservatezza attivata, in transport mode si cifra il payload del pacchetto iniziale. usato dagli host, non dai gateway (eccezione: traffico destinato al gateway, es. SNMP, ICMP) svantaggio: non nasconde l header IPv4 header TCP/UDP header + data IPv4 header ESP header TCP/UDP header + data ESP trailer parte cifrata ESP in tunnel mode usato solitamente dai gateway vantaggio: nasconde anche gli header In questo caso invece si cifra il payload del pacchetto finale, ma siccome il payload del pacchetto finale include anche gli header del pacchetto iniziale, riesco a nascondere i peer che stanno comunicando. Sniffando la rete il cattivo riesce a vedere #, vede che stiamo comunicando tra Europa e Stati Uniti ma null'altro. IPv4 header ( end-to-end ) TCP/UDP header + data IPv4 header ( tunnel ) IPv4 header ( end-to-end ) TCP/UDP header + data # IPv4 header ( tunnel ) ESP header IPv4 header ( end-to-end ) TCP/UDP header + data parte cifrata ESP trailer ESP - formato (RFC-2406) Security Parameters Index (SPI) Sequence number - SPI: pacchetto protetto con questa SA - SN - dati crittografati. Se vogliamo sapere cosa c'è nella dobbiamo prendere SPI, andare in SA, scoprire algoritmi e chiavi e a quel punto si possono decifrare i dati crittografati.... dati

19 authenticated ESP-DES-CBC - formato (RFC-2406) Security Parameters Index (SPI) Sequence number Initialization Vector (IV)... Payload... Padding Padding Length Payload Type en ncrypted Nell'ipotesi di possedere algoritmo e chiavi giuste, la è qui espansa. - IV (64 bit) in quanto stiamo usando DES-CBC - Payload: visto che DES è a blocchi può servire del padding per rendere tutto multiplo di 64 bit - Nella parte cifrata deve esserci sia la lunghezza del padding -... sia il vero Payload Type - ICV Occhio alle frecce. IV, per dire, è in chiaro, perchè sennò non so come decifrare. dati di autenticazione (ICV, Integrity Check Value) sequence number: protezione (parziale) da replay finestra minima i ma di 32 pacchetti (consigliati 64) Dettagli implementativi algoritmi NULL: per autenticazione per crittografia (RFC-2410) offrono trade-off protezione - prestazioni Protezione da replay in entrati in gioco. Problemi se L4 è connectionless. quando si crea una SA, il mittente inizializza il sequence number a 0 quando si invia un pacchetto, si incrementa il sequence number gateway LAN Il fatto che il SN venga visto su una finestra è l'origine della protezione parziale Questo lavoro qui viene fatto a L3, i livelli superiori non sono quando si raggiunge il sequence number , si negozia una nuova SA La finestra avanza sempre ogni volta Grigi: ricevuti che ricevo pck Bianchi: non ricevuti validi End-to-end security + Protezione completa dall'insicurezza del resto della rete - Complessità WAN Se ci sono attivi sistemi di monitoraggio sulle LAN per vedere se ci sono cattivi dentro l'azienda NON possiamo più vederli! canale virtuale sicuro (transport-mode SA) gateway LAN IPSec permette di avere algoritmi NULL, che servono per usare ESP facendo solo riservatezza. I sistemi Microsoft non sono più in grado di operare con algoritmi AH. In reti IP si possono perdere pacchetti o duplicarli, senza per questo essere sotto attacco. Inoltre ci possono essere arrivi fuori sequenza. Impossibile dunque proteggersi da cancellazione: non posso sapere se non è ancora arrivato o se sono sotto attacco. Sul replay c'è una disgrazia. Siccome i pacchetti possono arrivare con ordine diverso non posso solo tenere traccia dell'ultimo pacchetto ricevuto, perchè potrebbe arrivare prima il 5 e poi il 4. Dovrei avere un DB gigantesco. Per questo si ricorre a finestre. Se io però ricevo un replay di un pacchetto fuori dalla finestra non ho modo di sapere se l'ho già ricevuto o meno: sta all'implementazione decidere cosa fare o meno. Se non mi stanno sferrando attacchi replay potrei dunque avere penalizzazione nelle prestazioni. Se invece accetto a caso ho rischi se L4 è connectionless, a meno che non siano robusti (ovvero si autoproteggano da pacchetti duplicati) Malintenzionati non possono far avanzare finestra a piacimento perchè non possono autenticarlo. LEZIONE 20 Avendo considerato i componenti base di IPSec passiamo ora ad analizzare le modalità applicative di alto livello, ovvero le cosiddette architetture IPSec. IPSec è infatti un componente di un'architettura di sicurezza utilizzabile per varie configurazioni Vedremo 5 configurazioni base. Affinchè un sistema sia IPSec complained dev'essere in grado di creare almeno queste 5 configurazioni. 1a configurazione: end to end security. IPSec viene caricato sui due peer che hanno interesse a proteggere la comunicazione. I pacchetti che passano sopra possono essere attaccati ma è ininfluente, perchè avendo creato un canale virtuale sicuro abbiamo protezione completa (fatti salvi gli attacchi DoS). Prezzo da pagare: se devo rendere sicuri N nodi, devo installare IPSec su N nodi. Problema di gestione sistemistica non indifferente. Va bene per reti con pochi nodi che hanno bisogno di protezione.

20 gateway LAN Basic VPN WAN canale virtuale sicuro (tunnel-mode SA) gateway LAN Serve a realizzare una VPN tra due o più sedi della stessa a- zienda. Modulo IPSec installato sui gateway (scrivi router all' esame e prendi -1: il gateway è il punto di accesso, la porta, tra il mondo sicuro e quello non sicuro. Può eventualmente essere implementato su dei router, ma potrebbe essere implementato su firewall e macchine dedicate). In questa ipotesi ipotizziamo di avere una rete locale sicura e dunque non necessitiamo di protezione end 2 end: le grosse rogne di sicurezza derivano dunque da terzi che potrebbero attaccare la tratta geografica. + Protezione della sola tratta geografica: i sistemi di monitoraggio funzionano bene (- e purtroppo anche per i cattivi) + Basta mettere il modulo IPSec solo sui gateway - I gateway gestiscono le comunicazioni per un tot. di nodi, potrebbero dunque diventare il collo di bottiglia. Necessario HW dedicato - Problema di gestione End-to-end security with basic VPN gateway LAN WAN canale virtuale sicuro (tunnel-mode SA) canale virtuale sicuro (transport-mode SA) gateway LAN E' anche possibile mischiare le due architetture precedenti, installando i moduli IPSec sia sui gateway che sugli end node. Può sembrare ridondante, ma si rispettano alcuni principi fondamentali: * meglio avere due linee di difesa anzichè solo una (defense in depth) * se vogliamo fare sicurezza in transport-mode ma abbiamo problemi a fare la cifratura sui nodi perchè troppo pesante computazionalmente, possiamo mettere nel transport mode solo la parte di AH (auth + int) e di delegare la cifratura sui gateway (questo perchè è più facile che qualcuno sniffi sulla rete geografica) Soluzione molto più dispendiosa della precedente. Secure gateway WAN gateway Una delle architetture più usate. Questo perchè gli utenti sono sempre più "nomadi": il dipendente non sta in azienda, ma presso i clienti a fare business e può avere bisogno di collegarsi alla rete aziendale in maniera sicura. Dare accesso diretto alla rete aziendale può essere non sicuro, quindi si installa sul dispositivo mobile del dipendente un modulo IPSec. L'altro verrà installato su un gateway e si instaura un tunnel mode un po' anomalo (è creato tra un singolo nodo e un gateway). # LAN Il nodo mittente, quando deve parlare col server, prepara il pacchetto come se niente fosse. Prima di mandarlo fuori crea un pacchetto di tunnel da lui al gateway. Questo viene protetto con IPSec. Il gateway non solo ha il compito di securizzare con cifratura il canale esterno, ma ha anche un compito di autenticazione (forte) crittografica verso la rete aziendale. La rete locale è passibile di attacchi ma possiamo fare più monitoraggio. Più carico sull'end node del nomade. Il vero problema è la natura della macchina # che potrebbe essere uno smartphone o un laptop. Secure remote access WAN gateway Si cerca di fare il massimo. Non soltanto tunnel mode con funzioni di autenticazione, ma anche un transport mode direttamente verso il nodo finale. Si potrebbe anche invertire e fare la parte di cifratura direttamente sul nodo finale, se magari non voglio che in LAN vengano letti i dati mandati. LAN canale virtuale sicuro (transport-mode SA)