Wikipedia

IPsec: differenze tra le versioni

Naviga nella cronologia in modo interattivo
← Differenza precedente
annulla93.151.246.49 (discussione)
Contenuto cancellato Contenuto aggiunto
VisualeWikitesto
Nessun oggetto della modifica
Etichette: Modifica da mobile Modifica da web per mobile
fix
 
(23 versioni intermedie di 14 utenti non mostrate)
Riga 1:
In [[telecomunicazioni]] e [[informatica]] '''IPsec''', abbreviazione di '''IP Security''', è uno [[standard (informatica)|standard]] per [[rete informatica|reti]] a [[commutazione di pacchetto|pacchetto]] che si prefigge di ottenere [[connessione (informatica)|connessioni]] sicure su [[Rete informatica|reti]] [[Internet Protocol|IP]].
Tale [[sicurezza informatica|sicurezza]] viene raggiunta attraverso l'aggiunta di funzionalità di [[autenticazione]], [[cifratura]] e controllo di [[integrità dei dati|integrità]] dei [[pacchetto (reti)|pacchetti]] IP ([[datagramma|datagrammi]]). La capacità di fornire protezione o sicurezza viene dunque fornita quindi a [[livello di rete]] (diversamente da [[HTTPS]], [[Transport Layer Security|SSL/TLS]]), fatto che rende questo [[protocollo di rete|protocollo]] trasparente al [[livello applicazioni|livello delle applicazioni]] che quindi non devono quindi essere modificate.
 
== Panoramica dello standard ==
=== Scopo del progetto ===
IPsec è stato progettato per rendere sicure sia comunicazioni ''portal-to-portal'' sia comunicazioni ''end-to-end''. Nella prima configurazione il traffico viene reso "''sicuro''" a diversi computer (in alcuni casi ad un'intera [[LAN]]); nella seconda solo i ''peer'' che stabiliscono la connessione scambiano pacchetti protetti.
Tuttavia l'uso predominante di IPsec è la creazione di VPN ([[virtualRete privata virtuale|reti private networkvirtuali]]); per conseguire tale scopo possono essere utilizzati entrambi i metodi prima esposti.
 
=== Introduzione ===
IPsec è una collezione di [[protocollo di rete|protocolli]] formata da:
* Protocolli che implementano lo scambio delle chiavi per realizzare il flusso crittografato.
* Protocolli che forniscono laautenticazione, cifraturaintegrità e riservatezza del flusso di dati.
 
Attualmente esisteEsiste un solo protocollo per lo scambio delle chiavi, il protocollo '''[[Internet key exchange|IKE]]'''.
IPsec è parte integrante di [[IPv6]], mentre è opzionale in [[IPv4]]. Di conseguenza, ci si aspetta che sarà maggiormente utilizzato quando IPv6 acquisterà popolarità.
Il protocollo è definito negli [[Request for Comments|RFC]] 2401-2412.
Riga 19:
Per quanto riguarda il secondo aspetto, esistono due protocolli: [[Authentication Header]] (AH) e [[Encapsulating Security Payload]] (ESP).
 
'''AH''' fornisce autenticazione e [[integrità dei dati|integrità del messaggio]], ma non offre la [[confidenzialità]]riservatezza ed è il protocollo IP 51.<br />
'''ESP''' fornisce invece autenticazione, [[confidenzialità]]riservatezza e controllo di [[integrità dei dati|integrità del messaggio]] ed è il protocollo IP 50. Per questi motivi ESP è molto più usato di AH.
 
=== Dettagli tecnici ===
IPsec supporta due modalità di funzionamento:
* ''Transport mode''
Riga 44:
IPsec può essere utilizzato anche per connessioni tra gateway e host.
 
==== Security Association e Security Policy ====
Il concetto di '''Security Association''' (in breve '''SA''') è alla base del funzionamento di IPsec. Una SA è un "contratto" fra le due entità coinvolte nella comunicazione; in essa vengono stabiliti i meccanismi di protezione e le chiavi da utilizzare durante il successivo trasferimento dei dati. Nell'ambito di IPsec, stabilire le security association è compito del protocollo [[Internet key exchange|IKE]], sebbene sia possibile anche impostarle manualmente; ovviamente la procedura manuale è sconsigliata in quanto può introdurre errori che indeboliscono il tunnel.
 
Una peculiarità delle SA è che individuano una comunicazione unidirezionale; quindi durante la creazione della connessione le entità coinvolte creano e gestiscono una SA per ognuno dei versi della comunicazione, quindi 2 SA individuano un canale [[full-duplex]]. Al fine di semplificare la gestione delle SA, viene utilizzato un apposito [[database]] detto '''SAD''' ('''S'''ecurity '''A'''ssociation '''D'''atabase), dove viene tenuta traccia delle SA attive.
Riga 60:
Una volta stabilita la ''security association'' e la ''security policy'', può cominciare la comunicazione che sfrutterà il protocollo AH o il protocollo ESP cui verrà passato il parametro SPI, che permetterà di risalire alle tecniche crittografiche da utilizzare per la trasmissione.
 
== Protocolli di IPsec ==
=== IKE ===
{{vedi anche|Internet key exchange}}
====Descrizione====▼
 
[[Internet key exchange|IKE]] è un [[acronimo]] per '''I'''nternet '''k'''ey '''e'''xchange ed è il protocollo usato per stabilire una '''security association''' nella suite di protocolli '''IPsec'''. Questo protocollo è definito in RFC 4306. È un protocollo di [[livello applicazioni|livello applicazione]] e utilizza il protocollo [[User Datagram Protocol|UDP]] come [[Livello di trasporto|protocollo di trasporto]]; la [[Porta (reti)|porta]] su cui viene stabilita la [[connessione (informatica)|connessione]] è 500.▼
▲==== Descrizione ====
▲[[Internet key exchange|IKE]] è un [[acronimo]] per '''I'''nternet '''k'''ey '''e'''xchange ed è il protocollo usato per stabilire una '''security association''' nella suite di protocolli '''IPsec'''. Questo protocollo è definito in RFC 4306. È un protocollo di [[livello applicazioni|livello applicazione]] e utilizza il protocollo [[User Datagram Protocol|UDP]] come [[Livello di trasporto|protocollo di trasporto]]; la [[Porta (reti)|porta]] su cui viene stabilita la [[connessione (informatica)|connessione]] è 500.
 
L'obiettivo di IKE è stabilire uno ''shared session secret'', ossia una chiave condivisa corrispondente alla sessione da instaurare e a tal fine utilizza l'algoritmo di [[Scambio di chiavi Diffie-Hellman|Diffie-Hellman]]; dallo ''shared secret'' vengono successivamente derivate le chiavi crittografiche che verranno utilizzate per la successiva comunicazione.
Al fine di autenticare le entità coinvolte nella comunicazione possono essere utilizzate tecniche a chiave simmetrica o, alternativamente, a chiave asimmetrica; in quest'ultimo caso si fa ricorso a [[infrastrutture a chiave pubblica]] (PKI) e all'uso di [[Certificato digitale|certificati digitali]].
 
=== Authentication Header (AH) ===
==== Descrizione ====
'''Authentication Header''' (abbreviato '''AH'''), è un protocollo che fa parte della suite IPsec. Il suo compito è quello di fornire un controllo di integrità pacchetto per pacchetto, verifica dell'autenticità del mittente e protezione contro i [[replay attack]]. AH non garantisce in alcun modo la confidenzialità del messaggio.
 
Riga 78 ⟶ 80:
queste modifiche devono essere necessariamente consentite, per cui prima di calcolare il checksum, i campi cui è permesso variare vengono posti a '''0'''.
 
==== Formato del pacchetto ====
Di seguito viene illustrata la struttura del pacchetto AH (ogni casella rappresenta 1 [[byte]]).
{| border="1" cellspacing="0" cellpadding="2px"
| style="text-align:center;border:0;width:25%" | 0
| style="text-align:center;border:0;width:25%" | 1
| style="text-align:center;border:0;width:25%" | 2
| style="text-align:center;border:0;width:25%" | 3
|--
<!-- | 0 1 2 3 4 5 6 7 -->
Riga 97 ⟶ 99:
| colspan="4" style="text-align:center;" | Security Parameter Index (SPI)
|--
| colspan="4" style="text-align:center;" | NumeroSequence di SuccessioneNumber
|--
| colspan="4" style="text-align:center;" |
Riga 106 ⟶ 108:
; RISERVATO: Spazio lasciato per sviluppi futuri. Tutti i bit di questo campo vengono impostati a 0.
; Security Parameter Index: Questo campo identifica i parametri di sicurezza in combinazione con l'indirizzo IP. In genere è un numero pseudo-casuale che identifica la [[security association]] cui fa parte questo pacchetto.
; NumeroSequence di successioneNumber: Una successione di numeri [[Funzione monotona|monotonicamente]] crescenti. Per impedire i [[replay attack]], il numerosequence di successionenumber quando raggiunge il valore massimo (2^{32}-1) non deve ritornare a 0, ma una nuova SA deve essere creata.
; Dati per l'autenticazione: Contiene l'Integrity Check Value (ICV) e rappresenta l'[[HMAC]] calcolato dal mittente del messaggio. L'HMAC viene calcolato utilizzando i campi dell'header IP (con il [[Time to live|TTL]] originario), i campi dell'header AH tranne i dati dell'autenticazione (viene considerato a 0) e infine tutti i dati degli header di livello superiore, compresi quelli applicativi, che non vengono modificati durante il trasporto.
 
==== Transport mode e Tunnel mode ====
AH supporta nativamente sia il ''transport mode'' che il ''tunnel mode''. In transport mode vengono protetti solo i protocolli di livello superiore a quello di rete ([[Transmission Control Protocol|TCP]], [[User Datagram Protocol|UDP]], etc); in tunnel mode il pacchetto IP originale viene incapsulato in un nuovo pacchetto IP, dopo essere stato elaborato da AH. Ne spieghiamo il funzionamento con l'ausilio di alcuni disegni.
Il metro di confronto è senza dubbio il pacchetto IP originale; in presenza di un collegamento basato su IPsec il pacchetto viene, ovviamente, alterato.
Riga 147 ⟶ 149:
Questi campi vengono posti a '''0''' prima di calcolare la [[funzione di hash]], necessaria per la protezione del pacchetto. Da quanto appena detto si evince subito che il protocollo AH è incompatibile con le varie tecniche di [[Network address translation|NAT]]; difatti se vengono alterati i campi indirizzo nell'header IP (in entrambe le modalità), in ricezione la checksum fallisce subito.
 
=== Encapsulating Security Payload (ESP) ===
==== Descrizione ====
'''Encapsulating Security Payload''', denotato con l'[[acronimo]] '''ESP''', è un protocollo che fa parte della suite IPsec. Il suo obiettivo è fornire autenticità, confidenzialità e controllo di integrità alla comunicazione. Contrariamente a quanto fa [[Authentication Header|AH]], l'header IP non viene coperto dai controlli. Al pari di AH, però, supporta sia il tunnel mode che il transport mode.
 
==== Formato del pacchetto ====
Di seguito viene riportato il formato del pacchetto '''ESP''' (ogni casella rappresenta 1 [[byte]]).
{| border="1" cellspacing="0" cellpadding="2px" width="50%"
| style="text-align:center;" width="25%"| '''0'''
| style="text-align:center;" width="25%"| '''1'''
| style="text-align:center;" width="25%"| '''2'''
| style="text-align:center;" width="25%"| '''3'''
|--
<!-- | 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7
Riga 171 ⟶ 173:
Payload * (variable)
|--
| style="border-top:none;" | &nbsp;
| colspan="3" style="text-align:center;border-bottom:none;" | Padding (0-255 byte)
|--
| style="border-right:none;" | &nbsp;
| style="border-left:none;border-top:none;" | &nbsp;
| style="text-align:center;" | Pad Length
| style="text-align:center;" | Next Header
|--
| colspan="4" style="text-align:center;" |
Riga 191 ⟶ 193:
Come si può vedere dalla struttura del pacchetto (ma sarà illustrato meglio in seguito), ESP "''avvolge''" i dati dei protocolli di livello superiore, contrariamente a quanto fa AH che antepone un header.
 
==== Tunnel mode e Transport mode ====
Essendo un protocollo per il trasferimento dati della suite IPsec, ESP supporta sia il Tunnel mode che il Transport mode. A seconda della modalità tratta i dati in modo differente. Prima di descrivere l'incapsulamento dei dati mostriamo il pacchetto IP originale, che transiterebbe sulla rete in assenza di IPsec
{| border="1" width="50%" cellspacing=0
|style="width:2523%;background-color:gainsboro"| Header IP
|style="width:25%;background-color:gainsboro"| Header TCP
|style="width:5052%;background-color:gainsboro"| Dati
|}<small>Pacchetto IP originale</small>
{| border="1" width="85%" cellspacing="0"
|style="width:13%;border:1;background-color:gainsboro" | Header IP
|style="width:13%;background-color:orange;font-weight:bold" | Header ESP
|style="width:13%;background-color:limegainsboro" | Header TCP
|style="width:35%;background-color:limegainsboro" | Dati
|style="width:13%;background-color:orange;font-weight:bold" | Trailer ESP
|style="width:13%;background-color:orange;font-weight:bold" | ESP auth
|}
{| width="85%"
|style="width:26%;"| &nbsp;
|style="background-color:lime;text-align:center"| Dati crittografati
|style="width:13%;"| &nbsp;
|}
{| width="85%"
Riga 212 ⟶ 219:
|}<small>ESP in Transport mode</small>
 
{|width="9095%" cellspacing="0" border="1"
|style="width:1112%;background-color:yellow" | Nuovo Header IP
|style="width:11%;background-color:orange;font-weight:bold" | Header ESP
|style="width:1611%;background-color:limegainsboro" | Header IP interno
|style="width:1612%;background-color:limegainsboro" | Header TCP
|style="width:2432%;background-color:limegainsboro" | Dati
|style="width:11%;background-color:orange;font-weight:bold" | Trailer ESP
|style="width:11%;background-color:orange;font-weight:bold" | ESP auth
|}
{|width="9095%"
|style="width:23%"| &nbsp;
| style="background-color:lime;text-align:center;"| Dati crittografati
|style="width:11%"| &nbsp;
|}
{|width="95%"
|style="width:12%"| &nbsp;
| style="background-color:cyan;text-align:center;"| Dati autenticati
|style="width:11%"| &nbsp;
|} <small>ESP in Tunnel mode</small>
 
Le linee verdi sottendono la parte di pacchetto che viene sottoposta a crittografia, mentre le linee azzurre sottendono la parte di pacchetto che viene sottoposta a controllo di autenticità e integrità;. leNella zonemodalità verditrasporto indicanol'header leIP zoneoriginale dirimane in chiaro (quindi non protetto) per l'instradamento del pacchetto fino all'endpoint destinatario che vengonosarà anche responsabile di processare l'autenticazione e la decrittazione del payload ESP. Diversamente, nella modalità tunnel l'header IP originale viene crittografato (quindi protetto) assieme all'header TCP e ai dati, ed è quindi necessario introdurre un nuovo IP header (in giallo) con le informazioni necessarie per l'instradamento fino al dispositivo delegato ( [[Gateway (informatica)|gateway]] / [[firewall]] ) alla chiusura del tunnel IPsec con decrittazione del payload ESP, dispositivo che provvederà a sua volta ad inoltrare il pacchetto autenticato e decifrato verso l'endpoint dichiarato nell'header protetteIP tramiteoriginale algoritmi(in crittograficigrigio). Per quanto riguarda gli algoritmi di cifratura possono essere utilizzati [[Data Encryption Standard]] (DES), [[3DES]], [[Advanced Encryption Standard|AES]] e [[Blowfish]].
Il controllo di integrità e autenticità viene eseguito tramite [[HMAC]] (funzioni di hash);
l'hash viene calcolato tramite una funzione di hash ([[MD5]] o [[SHA1]]), utilizzando una chiave condivisa; l'hash ottenuto viene allegato al messaggio e inviato. In ricezione viene controllata l'integrità del messaggio. Come illustrato negli schemi, l'indirizzo IP più esterno non viene coperto dal controllo di integrità. Tale opzioni rende il protocollo ESP adatto ad essere utilizzato in alcuni tipi di [[Network address translation|NAT]], in particolare in quelli statici. Tuttavia esistono soluzioni ''ad-hoc'' per il funzionamento congiunto di IPsec e NAT, come il NAT traversal.
 
=== NAT traversal ===
==== Descrizione ====
[[Attraversamento NAT|NAT traversal]] (o più in breve NAT-T) è il nome di un protocollo facente parte della suite IPsec e standardizzato in diversi [[Request for Comments|RFC]], di cui quello ufficiale è RFC 3947. L'obiettivo di questo protocollo è fornire la possibilità di stabilire un tunnel IPsec anche quando uno dei due ''peer'' coinvolti subisce un'operazione di NAT per raggiungere l'altra entità coinvolta nella comunicazione.
 
==== Scenario ====
Il [[Network address translation|NAT]] è una tecnica molto utilizzata per il riuso degli [[indirizzi IP]]. Tuttavia gli host dietro un [[router]] (o un [[firewall]]) che effettua operazioni di NAT non godono di [[connettività end-to-end]]. Sebbene esistano diversi tipi di NAT, l'obiettivo generale è l'alterazione degli header del pacchetto. Questo comportamento è in netto contrasto con IPsec che ha tra i suoi obiettivi il controllo dell''''integrità''' del pacchetto.
In particolare il NAT è incompatibile con AH sia in tunnel mode che in transport mode, in quanto AH verifica l'integrità di tutto il pacchetto IP. ESP, invece, non copre l'header IP con controlli di sorta né in Tunnel mode né in Transport mode, per cui risulta adatto nel caso in cui il NAT eseguito sia di tipo [[SNAT]]; in altre parole, la modifica apportata dal router deve coinvolgere '''solamente''' l'header IP e non anche la [[Porta (reti)|porta]] del livello superiore.
Riga 273 ⟶ 285:
I campi segnati in <span style="background-color:green;font-weight:bold">verde scuro</span> sono quelli relativi al NAT-T; questi campi vengono inseriti subito dopo l'header IP esterno, che non viene alterato, così come non vengono alterati i campi successivi. In ricezione viene fatta l'operazione inversa.
 
== Elenco degli RFC relativi ad IPsec ==
* RFC 4301: Security Architecture for the Internet Protocol
* RFC 2402: Authentication Header
Riga 285 ⟶ 297:
* RFC 3947: Negotiation of NAT-Traversal in the IKE
 
== Voci correlate ==
* [[Sicurezza informatica]]
* [[HTTPS]]
Riga 292 ⟶ 304:
* [[IP spoofing]]
 
== Altri progetti ==
==Collegamenti esterni==▼
{{interprogetto}}
 
▲== Collegamenti esterni ==
*http://www.ipsec-howto.org/italian/x151.html
*{{cita web|https://www.linux.it/~davide/doc/tesi_html/index.html|IPsec e TLS a confronto: funzioni, prestazioni ed estensioni}}
*{{cita web | 1 = http://www.isaserver.org/articles/IPSec_Passthrough.html | 2 = How to pass IPSec traffic through ISA Server | accesso = 4 luglio 2005 | dataarchivio = 3 maggio 2005 | urlarchivio = https://web.archive.org/web/20050503121918/http://www.isaserver.org/articles/ipsec_passthrough.html | urlmorto = sì }}
 
{{IPstack}}
Riga 302 ⟶ 317:
 
[[Categoria:Standard Internet]]
[[Categoria:ProtocolliInternet di InternetProtocol]]
[[Categoria:Protocolli livello rete]]
[[Categoria:Sicurezza di rete]]
Estratto da "https://it.wikipedia.org/wiki/IPsec"