Sicurezza delle reti IP Accesso remoto via canali dial-up
Transcript
Sicurezza delle reti IP Accesso remoto via canali dial-up
LEZIONE 16 (37:40 - ...) Dopo aver visto tutta questa serie di soluzioni, si possono applicare a protezione delle reti IP. Sicurezza delle reti IP Antonio Lioy < lioy @ polito.it > Politecnico di Torino Dip. Automatica e Informatica 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 comunicazioNAS (Network ne per contattare un endpoint corrispondente all'interno dell' Access Internet Provider, il quale ha bisogno di un NAS (= trasformatore di segnali dal dominio delle comunicazioni al dominio InterServer) net, ossia trasformare collegamenti concettualmente puntopunto in collegamenti Internet) Accesso remoto via canali dial-up rete a commutazione di circuito (RTC / ISDN) rete IP (Internet) Autenticazione di canali PPP PPP è un protocollo ... ... p per incapsulare p p 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) t ffasi, tre i svolte lt in i sequenza: LCP (Link Control Protocol) autenticazione (opzionale; PAP, CHAP o EAP) L3 encapsulation (es. IPCP, IP Control Protocol) 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 fid simmetrica i ti EAP Extensible Authentication Protocol aggancio a meccanismi esterni (sfide, OTP, TLS) 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 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 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 hi suppor supporta support ta si sia ia CHAP si sia ia PAP PAP, d deve eve pri prima ima off offrire ffri ff ire CHAP perchè era il protocollo più sicuro 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 OTP generic token card altri tipi possono essere aggiunti: RFC-2716 “PPP EAP TLS authentication protocol” RFC-3579 “RADIUS support for EAP” 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) 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 è anEAP - incapsulamento cora attivo, EAP deve inventarsi un suo modo per fare cose che si farebbero a L3. per trasportare i dati di autenticazione usa un Il fatto che l'incapsulamento EAP (dammi i dati di autenticazioproprio protocollo di incapsulamento (perché il ne e io li trasporto in rete) supporti qualsiasi link layer è una sulivello 3 non è ancora attivo …)) perbomberata: EAP, nato per PPP, oggi si applica a reti 802 caratteristiche dell’incapsulamento EAP: (Ethernet, Token ring, Wireless...). Non avendo IP con tutte le sue cose di frammentazione, as indipendente da IP semblaggio e così via, bisogna fare ACK/NAK esplicito. Niente supporta qualsiasi link layer (es. PPP, 802, …) windowing, niente reordering (i pacchetti vengono ricevuti nel ACK/NAK esplicito (no windowing) la stessa sequenza di come sono stati inviati: vero fin quando siamo su link PPP, se invece siamo su un finto PPP ad esem assume no reordering (PPP ( è ordinato, UDP e pio appoggiato su UDP quest'ipotesi non è più vera, cosa sfrutIP non lo sono!) per non entrare in tabile da un attaccante per fare cose sporche). Avendo ACK/ ritrasmissione (max 3-4 volte) < un ciclo infinito NAK esplicito devo prevedere ritrasmissioni. Qualunque proto supporta la frammentazione (compito dei non collo di autenticazione che voglia essere trasportato da EAP deve definire una sua modalità per spezzare il payload. metodi EAP se payload > minima EAP MTU) base: Ipotesi EAP illink 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 EAP TTLS = tunnelled t ll d TLS (perme (permette ( tt di operare qualsiasi metodo EAP protetto da TLS) EAP-SRP (Secure Remote Password) GSS_API (include Kerberos) AKA-SIM (RFC-4186, RFC-4187) EAP - architettura TLS AKA SIM SRP method layer EAP layer EAP 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. 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, 802.5 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...) -------------------------------------------------------------------------------------Torniamo ora allo schema di base visto nelle prime slide, che 802.3 802.5 802.11 PPP 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 persone, si autenticano e c'è bisogno di sapere se queste Autenticazione per collegamenti dial-up delle 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 utente verifica a uno specifico authentication server (una cosa simile abilitato? 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 Network Authentication credenziali dell'utente, chiede se questo può accedere. AS ha Access rete IP Server un DB con gli utenti, le credenziali e le configurazioni di rete e Server sarà in grado di rispondere sì (+ configurazioni) o no. Se noi abbiamo un cattivo attestato sulla stessa rete IP dove ci sono i utenti NAS (che quindi può comunicare con AS, sniffare traffico e coSi / No, config. sì via), quali tipi di attacco può fare? Io potrei voler rubare l'acconfigurazione, cesso a qualcun altro per impersonificare qualcuno che ha par... ticolari privilegi o più semplicemente per fare cose losche con una maschera. protocol manager media layer 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 Accounting – si tracciano le risorse "consumate" ((es. d durata t d dell collegamento, llegament ttraffico ffico genera generato) t ) per vari motìvi (es. audit, costo, prestazioni) l’AS ricopre proprio queste tre funzioni dialogando con uno o più NAS tramite uno o più protocolli 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. Radius è stato pensato per un singolo dominio (un Internet Provider che deve gestire i suoi NAS), ma oggi come oggi si tenProtocolli di autenticazione via rete de a enfatizzare il roaming non solo per la telefonia mobile, ma (servono per il dialogo tra NAS e AS) anche per la mobilità su trasmissione dati. Per questo è stato RADIUS inventato Diameter. Per un certo tempo è stato utilizzato an il p più diffuso posso dunque che TACACS (evoluto in diverse forme): classico esempio di < usare più AS come non sempre vinca il migliore (protocollo proprietario di funzionalità di proxy verso altri AS Cisco). DIAMETER evoluzione di RADIUS enfasi su roaming tra ISP diversi (essendo recente) elevata l t attenzione tt i alla ll sicurezza i TACACS+ (TACACS, XTACACS) in origine tecnicamente migliore di RADIUS ma meno diffuso perché proprietario 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) amministrazione e accounting centralizzato sch schema hema cli client-server lient li t-server ttra ra NAS e AS port 1812/UDP (authentication) and 1813/UDP (accounting) ; unofficial ports: 1645 & 1646/UDP timeout e ritrasmissione server secondari 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!) RADIUS - RFC RFC-2865 (protocollo) RFC-2866 (accounting) ( g) 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) 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 NAS1 [email protected] server RADIUS NAS2 barbara barbara alice Windows domain controller 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 forma @... (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. (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 anti-replay replay of AS resp pwd enumeration (from fake NAS) authN of NAS req DoS (many NAS req from fake NAS) server scalability 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 (dopo averne fatto il padding a 128 bit con NUL): ((password password d || pad) d) ⊕ md5(k md5(key d5(k || aut d5(key autenticatore) tenti ticat ti tore)) Client: NAS 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 tt ib t Type T – Length L th – V Value l RADIUS - formato code identif autenticatore ... attributi ... length - Codice: 8 bit - Identificativo del pacchetto: 8 bit - Lunghezza complessiva: - Autenticatore (fondamentale per evitare replay) - Attributi in formato TLV RADIUS - pacchetti Per quanto riguarda il tipo di pacchetti, questi sono quelli fondamentali. ACCESS-REQUEST contiene le credenziali di accesso ((es. user + pwd) p ) pacchetto di risposta ACCESS-REJECT accesso negato (es. a causa di errato user/pwd) ACCESS-CHALLENGE richiede info addizionali dall’utente (es. un PIN, token code 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 Comprendendo nel Response Authenticator un md5 derivato anche dal Request Authenticator si tiene legata la risposta a una specifica richiesta: ammazzo gli attacchi replay. duplice scopo: autenticare la risposta p del server ed evitare replay p y mascherare la password unico scopo: avere in Access-Request: identificatore che si chiama Request Authenticator sta viaggiando sono 16 byte random generati dal NAS verso server iin nA Access-Accept ccess-A Acceptt / R Reject Rej ejectt / Ch Challenge Chall llenge ll si chiama Response Authenticator si calcola con un keyed-digest: md5 (code || ID || length || RequestAuth || attributes || secret) RADIUS - alcuni attributi type length value type = 1 (User-Name) DN: distinguished name value = text, network access identifier (NAI), DN type = 2 (User-Password) "cifrata" come visto prima 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 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. Esempio - CHAP + RADIUS NAS ------ PPP ------ RADIUS server CHAP / Challenge-Request CHAP / Challenge-Response RADIUS / Access-Request: - CHAP-Username - CHAP-Challenge - CHAP-Password RADIUS / Access-Accept: - parametri, … CHAP / Success 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". IPCP XXXXXXXXXXXXXXXX DIAMETER (voluto e spinto dai gestori di reti mobili) evoluzione di RADIUS particolare enfasi sul roaming p g 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 “Di RFC-4005 “Diameter t network t k access server application” RFC-4006 “Diameter credit-control application” RFC-4072 “Diameter EAP application” Sicurezza di DIAMETER specificato protezione obbligatoria con IPsec o TLS: nell'RFC client Diameter DEVE supportare pp IPsec e PUO’ supportare TLS server Diameter DEVE supportare IPsec e TLS configurazioni obbligatorie: (IPsec) ESP con algoritmi go 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 IEEE 802.1x Port-Based Network Access Control: architettura di autenticazione p per il livello 2 (MAC - Media Access Control) utile sugli switch di reti wired per bloccare l’accesso alla rete # indispensabile nel caso di reti wireless prime p implementazioni: p Windows-XP e access-point wireless Cisco grandissimo successo! http://standards.ieee.org/getieee802/download/802.1X-2001.pdf (nel PDF si descrive tutta l'architettura) 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. IPsec è 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. 802.1x 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) IEEE 802.1x framework per autenticazione e key-management 802.1x p 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) au aut ttenticazione+cifratura) ti i if t ) 802.1x - architettura semi-public network / enterprise edge enterprise or ISP network IP authentication server ((es. RADIUS)) RETE IP authenticator / etherNAS (es. Access Point or switch) supplicant 802.1x - vantaggi 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 # qui in sostanza si incapsula/deincapsula al bisogno 802.1x - messaggi Ethernet switch Ethernet laptop port connect server Radius access blocked EAPOL RADIUS # EAPOL-Start EAP-Request/Identity EAP-Response/Identity Radius-Access-Request Radius-Access-Challenge EAP-Request Radius-Access-Request EAP-Response (credentials) EAP-Success access allowed Radius-Access-Accept 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) -------------------------------------------------------------------------------------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 -------------------------------------------------------------------------------------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). A quale livello di rete è meglio realizzare la sicurezza? firewall? IPSEC? smart-card? apparati cifranti? guardie armate? Application Presentation 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. Session Transport Network Data Link Physical Livello ottimale? più si sale nello stack e più le funzioni saranno specifiche (es. possibile identificare l’utente, i comandi, coman comandi di, i dati) di d ti) ed d indipendenti i dipend ti dalle d ll reti ti sottostanti ma più saranno possibili attacchi di tipo DoS più si resta in basso nello stack e più sarà possibile “espellere” 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 pp trasmissivo degli amplificatori / ripetitori / convertitori tipicamente solo in reti chiuse (es. militari, governo, alta finanza) AMP e- CONV e- cavi elettrici e- 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) γ fibra ottica Misure di sicurezza a livello fisico 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ù 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) Inoltre, per cercare di minimizzare sin dalla progettazione della rete lo sniffing, si possono usare reti sniffing. 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 router t 011 ethernet router t 011 011 ISDN frame relay Sicurezza a livello data-link sebbene esistano schede cifranti da installare sui client, normalmente non si protegge il livello 2 sulle su sull lle stazioni ll t i i ma solo l su tratte t tt geografiche fi h puntot punto si comincia a pensare la gestione della LAN associata a quella della sicurezza: VLAN swit switch it h con port itch porte te prot protette tett tte tt ((es. es. 802 802.1x) 802.1 1x)) allarmi automatici al comparire di un nuovo MAC assegnazione statica degli indirizzi IP no a DHCP completamente dinamico 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. 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 forn ffornisco isco i configurazione figurazi con subnet b td da 2 bit + default gateway uguale alla macchina che vuole essere MITM facendo NAT si intercettano anche le risposte Protezione del DHCP 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). alcuni switch (es. Cisco) offrono: DHCPsnooping p g = solo risposte p da “trusted p 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” per autenticare i messaggi gg usa HMAC-MD5 p scarsamente adottato 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. 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). LEZIONE 19 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 rete IP A L3 dobbiamo controllare la sicurezza su client e server. server router 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 FIAT Melfi ENI Milano rete "pubblica" FIAT Torino 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). 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) 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-toconsumer) 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. 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? Tecniche di realizzazione di una VPN mediante reti nascoste mediante routing g protetto p (tunnel ( IP)) mediante protezione crittografica dei pacchetti rete (tunnel IP sicuro) ...ovvero come "colorare" i pacchetti 1. VPN mediante rete nascosta le reti da collegare utilizzano un indirizzamento non standard per non essere raggiungibili da altre reti ti ((es. reti ti nascoste t IANA secondo d RFC RFC-1918) 1918) è una protezione facilmente superabile se qualcuno: 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 ad hoc altro i router controllano l’accesso alle reti mediante ACL ((Access Control List)) La rete 10.x.x.x e la rete 192.168.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 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. border router VPN mediante tunnel IP del network provider v rete pubblica R1 A→B rete1 IPv4 header ( tunnel ) R2 R1 → R2 A→B A→B A B rete2 IPv4 header ( end-to-end ) TCP/UDP header + data IPv4 header ( end-to-end ) TCP/UDP header + data # ## Quando si fa IP in IP si corre il rischio della... Tunnel IP: frammentazione f ammentazione fr se il pacchetto da trasmettere ha la massima dimensione consentita, allora deve essere fframmentato rammenttatto 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 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. se gli algoritmi crittografici sono forti, allora l’unico attacco possibile è impedire le comunicazioni anche detta S-VPN (Secure VPN) 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 rete1 TAP1 TAP2 R2 TAP3 rete2 IPsec 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à, p g , autenticazione,, no replay p y 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. Servizi di sicurezza IPsec autenticazione dei pacchetti IP: integrità g 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? IPsec Security Association (SA) connessione logica unidirezionale protetta tra due sistemi IPsec ad ogni SA sono associabili caratteristiche di sicurezza diverse occorrono due SA per avere protezione completa di un canale bidirezionale SA (A, B) SA (B, A) 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à Database locali IPsec SPD (Security Policy Database) contiene le security yp policy y da applicare pp 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) Come funziona IPsec (spedizione) pacchetto IP SPD quale policy? regole di sicurezza SAD crea / legge SA algoritmi / parametri pacchetto IP con IPsec modulo IPsec 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. 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. IPsec - seconda versione Nella prima si erano scordati di fronteggiare replay. 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. novembre 1998 RFC-2411 = IPsec document roadmap p 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 RFC-2405 DES-CBC CBC con IV esplicito li it RFC-2406 = ESP RFC-2410 = cifratura nulla in IPsec RFC-2451 = algoritmi per ESP CBC IPsec - scambio chiavi RFC-2407 = interpretazione IPsec di ISAKMP RFC-2408 = ISAKMP RFC-2409 = IKE RFC-2412 = OAKLEY Servono per setup e scambio chiavi Header IPv4 0 4 Vers Vers. 8 IHL 16 TOS Identification TTL 19 Protocol 31 Total length Flags Fragment offset Header checksum Source IP address Destination IP Address Options Padding 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 may/don t fragment fragment, last/more fragments TTL (Time To Live): numero massimo di hop protocol: protocollo usato dal payload 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. Si poteva fare di meglio? Sì, ma ora non è proprio il momento di cambiare l'header dei pacchetti IP. IPsec in transport mode usato per fare sicurezza end-to-end, ossia usato dagli host, non dai gateway (eccezione: traffico destinato d esti tinat ti to all gat gateway, teway, es. SNMP SNMP, ICMP) vantaggio: computazionalmente leggero svantaggio: non protegge i campi variabili IPv4 header IP 4 @ IPv4 header TCP/UDP header + data IPsec header TCP/UDP header + data 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 in @ 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) # IPsec in tunnel mode usato per fare VPN, solitamente dai gateway vantaggio: gg protegge p gg anche i campi p variabili svantaggio: computazionalmente pesante IPv4 header ( tunnel ) IPv4 header ( tunnel ) IPsec header IPv4 header ( end-to-end ) TCP/UDP header + data IPv4 header ( end-to-end ) TCP/UDP header + data IPv4 header ( end-to-end ) TCP/UDP header + data AH Authentication Header meccanismo (p (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à i tegrità d deii d dati, ti autenticazione t ti i d dell mittente itt t e protezione da replay attack HMAC-MD5-96 < keyed digest ridotti HMAC-SHA-1-96 AH - formato (RFC-2402) Next Header Length reserved Security Parameters Index (SPI) Sequence number dati di autenticazione (ICV, Integrity Check Value) 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). 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. pacchetto IPsec ricevuto estrazione normalizzazione SAD SPI pacchetto IP normalizzato algoritmo, parametri AH estrazione calcolo del valore di autenticazione ICV valore di autenticazione ricevuto valore di autenticazione calcolato sì valori uguali? Si fa un confronto: se valori uguali mittente autentico e pacchetto integro, altrimenti mittente falso e/o pacchetto manomesso. no mittente falso e/o pacchetto manomesso mittente autentico e pacchetto integro Normalizzazione per AH IPv4 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 IPv6 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. Il keyed digest viene calcolato sull'intero pacchetto dopo averlo normalizzato. Quest'operazione la fanno sia mittente e destinatario. azzerare il campo TTL / Hop Limit se il p pacchetto contiene un Routing g Header,, allora: fissare il campo destinazione all’indirizzo del destinatario finale fissare il contenuto del routing header al valore che avrà a destinazione fissare il campo Address Index al valore che avrà a destinazione azzerare tutte le opzioni che hanno il bit C (change change en route) route attivo Keyed-MD5 in AH dato M normalizzarlo generando M’ allineare a 128 bit M’ ((aggiungendo gg g byte y 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: ICV = md5 d5 ( K Kp || M’ M’p || Kp K ) HMAC-MD5-96 dato M normalizzarlo generando M’ allineare a 128 bit M’ ((aggiungendo gg g byte y a zero)) generando così M’p allineare a 128 bit la chiave K (aggiungendo byte a zero) generando così Kp dati ip = 00110110 e op = 01011010 (ripetuti a formare 128 bit) calcolare la base di autenticazione: t 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. ESP Encapsulating Security Payload prima versione (RFC-1827), p ( ), 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 Posso usare altro oltre a DES, ma anche qui vale il discorso di prima (io solo contro Internet). Considerando ESP con la riservatezza attivata, in transport mode si cifra il payload del pacchetto iniziale. ESP in transport mode 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. usato dagli host, non dai gateway (eccezione: traffico destinato al gateway, es. SNMP, ICMP) svantaggio: non nasconde l’header IPv4 header IPv4 header ESP header TCP/UDP header + data TCP/UDP header + data ESP trailer parte cifrata 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. ESP in tunnel mode usato solitamente dai gateway vantaggio: gg nasconde anche gli g header IPv4 header ( tunnel ) IPv4 header ( end-to-end ) TCP/UDP header + data IPv4 header ( end-to-end ) TCP/UDP header + data # IPv4 header ( tunnel ) ESP header IPv4 header TCP/UDP header + data ( end-to-end ) ESP trailer parte cifrata - SPI: pacchetto protetto con questa SA - SN - dati crittografati. Se vogliamo sapere cosa c'è nella parte @ dobbiamo prendere SPI, andare in SA, scoprire algoritmi e chiavi e a quel punto si possono decifrare i dati crittografati. ESP - formato (RFC-2406) Security Parameters Index (SPI) Sequence number . . . @ dati crittografati . . . Nell'ipotesi di possedere algoritmo e chiavi giuste, la parte @ è 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 ESP-DES-CBC - formato (RFC-2406) Security Parameters Index (SPI) authenticated Sequence number . . . . . . Payload Padding Padding Length en ncrypted Initialization Vector (IV) Occhio alle frecce. IV, per dire, è in chiaro, perchè sennò non so come decifrare. Payload Type dati di autenticazione (ICV, Integrity Check Value) 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. Dettagli implementativi algoritmi NULL: p per autenticazione per crittografia (RFC-2410) offrono trade-off protezione - prestazioni sequence number: protezione (parziale) da replay fi finestra fines nesttra mi nes minima m inima di 32 pacc pacchetti pacch hetti ((cons (consigliati consiiglilia cons ati 64) Il fatto che il SN venga visto su una finestra è l'origine della protezione parziale Protezione da replay in IPsec Questo lavoro qui viene fatto a L3, i livelli superiori non sono 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 quando si raggiunge il sequence number 232-1, si negozia una nuova SA La finestra avanza sempre ogni volta che ricevo pck validi Grigi: ricevuti Bianchi: non ricevuti End-to-end security + Protezione completa dall'insicurezza del resto della rete - Complessità WAN gateway LAN IPsec gateway 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) LAN IPsec 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. Basic VPN WAN IPsec gateway canale virtuale sicuro (tunnel-mode SA) LAN IPsec gateway Serve a realizzare una VPN tra due o più sedi della stessa azienda. 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. LAN + 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 WAN IPsec gateway canale virtuale sicuro (tunnel-mode SA) LAN IPsec gateway LAN IPsec IPsec canale virtuale sicuro (transport-mode SA) Secure gateway WAN IPsec gateway # LAN IPsec Secure remote access WAN IPsec gateway LAN IPsec IPsec canale virtuale sicuro (transport-mode SA) 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. 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). 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. 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. IPsec key management componente fondamentale di IPsec fornisce ai sistemi IPsec comunicanti le chiavi simmetriche necessarie per l’autenticazione e/o la cifratura dei pacchetti distribuzione delle chiavi? OOB (es. manuale) automatica ISAKMP Internet Security Association and Key Management Protocol RFC-2408 definisce le procedure necessarie per negoziare, stabilire, modificare e cancellare le SA non indica il metodo da usare per lo scambio delle chiavi OAKLEY (RFC-2412): protocollo che realizza lo scambio autenticato delle chiavi simmetriche tra sistemi IPsec IKE Internet Key Exchange (RFC-2409) = ISAKMP + OAKLEY creazione di una SA per proteggere lo scambio ISAKMP con questa SA protegge la negoziazione della SA richiesta da IPsec la stessa SA ISAKMP p può essere riusata più p volte per negoziare altre SA IPsec IKE - funzionamento uno dei due nodi prende l'iniziativa (initiator) 1 initiator responder IKE phase 1 - negoziazione di una SA ISAKMP bidirezionale: “main mode” o “aggressive mode” ISAKMP SA 2 initiator / initiator / responder responder IKE phase 2 - negoziazione della SA IPsec: “quick mode” Tutte quante queste soluzioni devono gestire digest (per fare keyed-digest e sicurezza dei dati). Come distribuire le chiavi? Per reti piccole e ad alta sicurezza può convenire una distribuzione OOB (manuale): cose del genere ovviamente non vanno bene su Internet. IKE è un'architettura che comprende varie protocolli. ISAKMP serve a gestire le associazioni di sicurezza e le chiavi usate in IPSec. Protocollo agnostico (gestisce le SA senza dire come debbano essere gestite le chiavi). Spesso viene accoppiato con OAKLEY che realizza lo scambio delle chiavi simmetriche tra sistemi IPSec. Pesante dal punto di vista computazionale. Prima si crea una SA per proteggere lo scambio ISAKMP. Questo aspetto sembra essere un gatto che si morde la coda: ISAKMP serve per creare le SA ma io ho già bisogno di una SA. La prima SA che serve a proteggere lo scambio ISAKMP stesso può essere riusata più volte per negoziare altre SA. Nella fase 1 viene negoziata una SA ISAKMP bidirezionale (in main mode, che è il modo più sicuro e garantisce l'anonimato di chi sta comunicando oppure in aggressive mode, con meno carico computazionale, ma senza garanzia di anonimato). Una volta creata questa SA si passa alla fase 2 in cui ciascuno dei due nodi possono essere initiator o responder ("ho bisogno di un SA perchè sto per farti un trasferimento FTP"). Questo può essere fatto in quick mode perchè la SA viene negoziata in un canale già protetto. IKE: “modi” di funzionamento Main Mode: 6 messaggi gg protegge l’identità delle parti Aggressive Mode: 3 messaggi (ma non protegge l’identità delle parti) Quick Mode: 3 messaggii più leggeri della Aggressive Mode negoziazione solo della SA IPsec New Group Mode: 2 messaggi IKE: metodi di autenticazione Digital Signature non-repudiation p della negoziazione g IKE Public Key Encryption variante della Digital Signature protezione dell’identità nell’aggressive mode altra variante Revised Public Key Encryption meno costoso, solo 2 operazioni a chiave pubblica P Sh Pre-Shared d Key K l’ID della controparte può essere solo il suo indirizzo IP (problema per gli utenti mobili) Il main mode richiede lo scambio di 6 messaggi crittografici, è riservato alla parte ISAKMP ma ha il grosso vantaggio di proteggere l'identità delle parti e garantire l'anonimato. Solo due messaggi per New Group Mode perchè non crea una SA ma ne cambia solo i parametri. Nel momento in cui si creano le SA, è parte integrante di ISAKMP e IKE una parte di autenticazione. Occhio che questa è autenticazione dei peer e non dei pacchetti nel momento in cui vogliono creare SA. Pre-Shared Key: se io ho inserito delle chiavi nei vari nodi, posso usare IKE per selezionarle. La persona che va in giro sui gateway e configura le chiavi ne mette una decina, dopodichè con ISAKMP si può dire "prendi la 7°". L'ID della controparte però può essere solo un IP. Ottimo per nodi fissi, una schifezza per nodi mobili. VPN concentrator apparecchiature special-purpose che fungono da terminatori di tunnel IPsec: per accesso remoto di singoli client sicuro per creare VPN site-to-site prestazioni molto elevate in relazione ai costi (bassi) I gateway possono essere implementati su router e firewall. Un grande trend che si ha quando i gateway agiscono in tunnel mode è quello di avere delle macchine dedicate, che si chiamano VPN concentrator. Concettualmente creano IPSec. hanno implementato IPSec in HW con acceleratori crittografici dedicati appositamente ai calcoli necessari per IPSec Requisiti di sistema per IPsec su router: CPU p potente o acceleratore crittografico g non gestito in outsourcing a meno che non si dia anche la sicurezza in su firewall: outsourcing CPU potente su VPN concentrator: massima i iindipendenza di d d dalle ll altre lt misure i di sicurezza Quando vogliamo installare IPSec in modalità tunnel su dei gateway abbiamo diverse opzioni: - sui router: ottimo modo per ammazzare le prestazioni di un router. E' infatti ottimizzato per fare switching, la sua CPU non è particolarmente potente di solito. - discorso simile sui firewall, elementi che fanno filtraggio di rete sui pacchetti. - VPN concentrator: migliori prestazioni al più basso costo e crea potenzialmente un elemento indipendente Influenza di IPsec sulle prestazioni diminuizione del throughput di rete: maggiore gg dimensione dei p pacchetti transport mode AH: +24 byte transport mode ESP-DES-CBC: >= 32 byte maggior numero di pacchetti (per attivare la SA) di solito diminuizione contenuta eccezione: i link li k pun punto-punto to-punt iin cuii sii usava compressione a livello 2 che diventa inutile o dannosa se associata a pacchetti ESP possibile compensazione tramite IPComp (RFC-3173) o compressione applicativa IPsec tunnel mode/L2TP Windows rende sicuro l’accesso remoto dal client al gateway usando L2TP sicurizzato da IPsec MS dichiara di aver fatto questa scelta perché l’IPsec tunnel mode: non permette l’autenticazione dell’utente non supporta il multiprotocollo non supporta pp il multicast la scelta di L2TP causa: un calo di prestazioni problemi di interoperabilità tra sistemi diversi Siccome IPSec aumenta le dimensioni dei pacchetti c'è un impatto sulla sicurezza. Questa cosa non è da sottovalutare, perchè diminuisce un po' il throughput dei pacchetti. AH è il più leggero e quindi c'è un aumento di 24 byte, con ESP almeno 32 byte. Inoltre si scambiano più pacchetti per attivare la SA: c'è un delay nell'inizio della trasmissione. Diminuzione abbastanza contenuta specie se abbiamo pacchetti grossi. L'eccezione è il link punto-punto: se abilitiamo IPSec ricordiamoci di disabilitare le eventuali compressioni fatte ai livelli inferiori (tipicamente a L2). Compensabile in parte facendo compressione applicativa oppure usando un apposito protocollo (IPComp) a cui dare in pasto il pacchetto, che verrà compresso, prima di IPSec. Tunnel mode brutta bestia in IPSec. Microsoft fa tunnel mode in modo diverso rispetto al resto del mondo: non si usa IP in IP, ma L2TP. Di tutte le motivazioni fornite, la terza è seria: qualunque cosa che non sia unicast non si può proteggere con IPSec, perlomeno non banalmente. Con L2TP supero queste limitazioni ma ho una serie di problemi. Che cos’è L2TP? Layer-2 Tunnel Protocol (RFC-2661) p incapsula inca i pacchetti p PPP in IP vantaggio: possibilità di usufruire del supporto PPP per il multi-protocollo (es. anche per IPX, Netbeui e Appletalk) autenticazione dell’utente ((PAP / CHAP)) svantaggio: overhead con L2TP ciascun end-point mantiene una PPP state machine come se i due fossero connessi da una linea seriale mentre invece sotto c'è una rete IP Già il fatto di incapsulare pacchetti di L2 in L3 non è che sia proprio una chicca. Però se io ho un pacchetto PPP posso metterci dentro qualunque L3 e posso autenticare l'utente. Svantaggio in termini di overhead (a livello di pacchetti e di autenticazione del canale) completa # Trama PPP, con header PPP e un qualche payload di L3. IPsec over L2tp # I pacchetti PPP sono incapsulati 2 volte e poi trasmessi come pacchetti IPsec I pacchetti viaggiano normalmente come pacchetti IP anche se sono IPX o AppleTalk Abbiamo un pacchetto di L2 pronto per essere trasmesso su un L1. NO. Viene messo dentro un pacchetto di L5 (L2TP), il quale viene messo dentro un pacchetto di L4 (UDP). Questa roba viene messa dentro un pacchetto IPSec e poi dentro IP (L3) e poi la affidiamo a un L2 per la trasmissione. Da L2 siamo risaliti fino a L5 per poi scendere: overhead maggiore della dimensione del pacchetto trasportato. Applicabilità di IPsec solo pacchetti unicast (no broadcast, no multicast, no anycast di IPv6) IPv6 tra parti che hanno attivato una SA: tramite chiavi condivise tramite certificati X.509 … quindi in gruppi “chiusi” Sicurezza di IP indirizzi non autenticati pacchetti non protetti: p p integrità autenticazione riservatezza replay Le limitazioni sono date dal fatto che le parti devono avere attivato una SA. O abbiamo installato manualmente delle chiavi oppure abbiamo dei certificati X509 sulle varie macchine, i quali si portano dietro il concetto di fiducia. In ogni caso abbiamo a che fare con gruppi chiusi. IPSec va molto male per securizzare Internet "in the large" quando non ci si conosce tra mittente e destinatario. IPSec va un sacco bene ma non risolve tutti i problemi di sicurezza che si possono avere a livello IP. IP è insicuro per vari problemi. A livello applicativo non è così grave perchè le persone si pongono il problema della sicurezza. Ci sono però tutta una serie di protocolli vitali senza i quali le reti non funzionano e sono attaccabili perchè usano IP e ne ereditano l'insicurezza. sono quindi attaccabili tutti i protocolli che usano IP come trasporto, soprattutto quelli di “servizio” ossia non di livello applicativo (ICMP, IGMP, DNS, RIP, …) Sicurezza di ICMP Internet Control and Management Protocol vitale p per la gestione g della rete possibili moltissimi attacchi perché completamente privo di autenticazione funzioni ICMP: echo request / reply destination unreachable (network / host / protocol / port unreachable) maggior parte degli attacchi di tipo DoS source quence redirect time exceeded for a datagram Smurfing attack src = A dst = X.Y.255.255 ICMP echo request reflector (network X.Y) ultimate target (A) Dell'echo request/reply (ping flooding) se n'è già parlato. Ma si pensi ai pacchetti Destination Unreachable, con cui viene segnalata una destinazione non raggiungibile. Se io sono cattivo posso bloccare le comunicazioni verso una certa destinazione. Source quence: diminuzione della capacità trasmissiva del mittente quando i nodi intermedi tendono a essere pieni. Se mando pacchetti source quence falsi diminuisco la capacità del mittente. Redirect: no DoS, è mandato dai router per dirci che abbiamo sbagliato strada. Se mando redirect sono in grado di andare a cambiare il routing di una rete, e questo funziona anche sugli end node: MITM logico. Time exceeded: ci fa essere convinti che ci sia un loop e ci fa smettere di trasmettere. Gli attacchi che usano Echo Request/Reply possono prendere una forma devastante: attacco smurfing. Un nodo finge di essere un certo nodo A (in realtà A è la vittima) e manda un ICMP Echo Request all'indirizzo di broadcast di una rete. La rete riceve un pacchetto e risponde con (in questo caso) 65000 pacchetti verso il destinatario. Problemi sia per lui che per la rete che per i link. Contromisure anti-smurfing per attacchi dall’esterno: rifiutare il broadcast IP interface serial0 no ip i directed-broadcast di t db d t per attacchi dall’interno: identificare il responsabile tramite strumenti di network management Variante dello smurfing nata quando si è cominciato a prendere le prime contromisure. Il fraggle utilizza la stessa tecnica, ma con UDP, sfruttando i servizi integrati. Efficacia minore perchè non tutte le configurazioni dello stack TCP/IP comprendono i TCP small services Fraggle attack src = A dst = X.Y.255.255 UDP echo request reflector (network X.Y) ultimate target (A) ARP poisoning ARP = Address resolution Protocol (RFC-826) usato p per scoprire p l’indirizzo L2 di un nodo di cui è noto l’indirizzo L3 risultato memorizzato in ARP table ARP poisoning = inserire dati falsi in ARP table: nodi accettano ARP reply senza ARP request nodi sovrascrivono entry ARP statiche con quelle dinamiche (ottenute da ARP reply) il campo “ar$sha” (sender hw address) di ARP può differire dal campo src nel pacchetto 802.3 usato da strumenti di attacco (es. Ettercap) TCP SYN flooding SYN SYN/ACK ACK (?) client La contromisura più consigliabile è impedire il broadcast dall' esterno. Broadcast tipicamente fatto solo dentro la rete locale. Se il cattivo sta dentro la rete sono fregato. Oltretutto con IP spoofing non me ne accorgerei nemmeno, quindi buona norma attivare sistemi di monitoraggio. connessioni di rete SYN SYN SYN ACK Altro attacco fattibile a livello IP. Si basa sul fatto che anche ARP non è autenticato. ARP Poisoning: si mandano pacchetti di risposta ARP che non fanno seguito a una richiesta. Questo perchè un nodo anche se non fa ARP Request si memorizza i dati in modo da portarsi avanti col lavoro. Altro attacco interessante sferrabile verso server applicativi. Per attivare una connessione TCP ci va il three way handshaking. Il cattivo non manda l'ultimo ACK e manda SYN a ripetizione, creando collegamenti half-open. Visto che la tabella è di dimensioni non infinite si può saturare con facilità. Questo in parte è stato previsto: potrebbe esserci un problema di rete, quindi ogni 75'' parte un cleaner che se vede una riga half-open per più di quel tempo toglie la riga. 75'' però è un tempo bel lungo. server richieste multiple con IP spoofing si satura la tabella delle connessioni sino a quando non vanno in timeout (valore tipico: 75”) SYN flooding problemone per quei server esposti su Internet che non possono fare filtraggio. Difesa da SYN flooding abbassare il timeout rischio di eliminare client validi ma lenti aumentare le dimensioni della tabella aggirabile con invio di più richieste usare un router come “SYN interceptor”: sostituisce il server nella prima fase se l’handshake l’h d h k h ha successo, ttrasferisce f i il canale l al server timeout “aggressivi” (rischio!) usare un router come “SYN monitor”: uccide i collegamenti pendenti (RST) SYN cookie idea di D.J.Bernstein (http://cr.yp.to) unico sistema veramente efficace p per evitare completamente il SYN flooding usa il sequence number del pacchetto SYN-ACK per trasmettere un cookie al client e riconoscere così i client che hanno già inviato il SYN senza memorizzare niente sul server di disponibile ibil su Linux Li e Solaris S l i SYN interceptor (o firewall relay) http://www.cisco.com/web/about/ac123/ac147/archived_issues /ipj_9-4/syn_flooding_attacks.html SYN monitor (o firewall gateway) http://www.cisco.com/web/about/ac123/ac147/archived_issues /ipj_9-4/syn_flooding_attacks.html Abbassare timeout non è saggio perchè il RTT tra i due nodi più lontani della rete è attorno ai 75''. Piazzando router davanti al server possiamo usarli come SYN interceptor o SYN monitor. Nel primo caso "sposto" il problema, nel secondo anche. Esiste una soluzione che risolve il problema. Bernstein si è reso conto dell'esistenza di un errore di progettazione: il fatto che il server conservi la tabella serve a mantenere lo stato. L' attacco diventa impossibile nel momento in cui lo stato lo mantenga il client. Tabella delle connessioni eliminata: viene generato un SN crittografico con alcuni parametri caratteristici di client e server. Se tu sei un client valido mi manderai SN+1 e allora vuol dire che ti ho già visto, altrimenti no. Bernstein è stato attaccato a morte dai puristi del TCP, ma alla fine ha vinto lui. Anche in Windows c'è un'opzione attivabile per proteggersi (non è attiva di default).