==============================================================================
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
--------------------[ previous ]---[ index ]---[ next ]---------------------
------------------------------[ i P S E C ]-----------------------------------
-------------------------[ ARCHiTETTURA Di BASE ]-----------------------------
--------------------------------[ FuSyS ]-------------------------------------
NO(C)1999 FuSyS
#############################################################################
DISCLAIMER
Ragazzi ve lo dico. Preparatevi ad un overflow di acronimi, molti sono di
tipo TLA, quindi fuori le aspirine, l'acutil fosforo o le vostre sostanze
preferite. Questo e' un sunto tecnico di RFC, white papers e testi letti
in giro su IPSec. No. Non sulle brochures dei firewall allo SMAU :)
#############################################################################
Questo articolo vuole descrivere l'architettura base di IPSec. Proposto e
creato per far fronte alle richieste di sicurezza emerse nel RFC1636, IPSec
dovrebbe porre fine ai problemi che sembrano affliggere (guarda un po' :)
la rete da ormai qualche anno.
La proposta e' tutto fuorche' recente. I vari RFC sono stati avanzati nel
lontano 1995 dalla IETF e sono: RFC1825, RFC1826, RFC1827, RFC1828 ed
RFC1829. Eppure questo articolo NON e' affatto in ritardo. Questo perche'
l'implementazione pratica dell'architettura non e' uno standard ed anzi
viene lasciato ai produttori largo spazio alla creativita' e disponibilita'
all'utilizzo di diverse caratteristiche, che facciano comunque capo agli RFC.
Infatti IPSec e' da ritenersi obbligatorio solo per IPv6 ed appena opzionale
per IPv4. Fatto che sta comunque permettendo a vari prodotti di router e
firewall di presentare soluzioni per VPN che si basino su IPSec.
I servizi di base vengono forniti al livello del layer IP. Cosa vuol dire
questo? Semplicemente trasparenza nei confronti delle applicazioni.
Pensiamo ad esempio alla crittografia dei dati in corso di trasmissione,
come con SSH. In questo caso c'e' bisogno di un protocollo apposito, ma
anche e soprattutto di un'architettura client/server differente dalla
usuale telnet o rlogin. Quindi le diverse parti possono trasmettere solo
se tutte siano in possesso dei servizi SSH.
SSL invece si trasferisce a livello del layer di trasporto. Infatti noi
possiamo usare un browser quale Netscape indipendentemente per server
normali o sicuri, utilizzando un sistema di crittografia mediante chiavi
che critta lo stream TCP. Ma in questo caso NON posso ad esempio usare un
server sicuro con lynx. Ho quanto meno bisogno di un modulo o patch per
lynx perche' possa usare SSL. Esistono, e' vero, implementazioni gratuite
di SSL, quali SSLeay dell'autore di libdes. Ma ogni codice deve essere
linkato alla libreria opportuna.
Spostandoci a livello IP con IPSec, invece, potremo continuare ad usare il
nostro caro vecchio telnet, da bravi utenti pigroni, senza che il nostro
admin si debba mai preoccupare (si spera :) delle password inviate.
A dire il vero per gli utenti comuni e le loro applicazioni non cambiera'
proprio un accidenti, almeno finche' non si parla di possibili argomenti
tipo policy, uso/scambio di chiavi user/user piuttosto che host/host (vedi
dopo). Potranno lavorare come prima, lasciando che sia il layer base ad
occuparsi di:
-controllo degli accessi
-integrita' dei dati
-autenticazione dell'origine della trasmissione
-rifiuto di pacchetti ritrasmessi (tipico attacco contro Kerberos e PPTP)
-confidenzialita' dei dati (crittazione)
IPSec dovrebbe garantire tutto questo mediante l'utilizzo di due nuovi
protocolli: uno di autenticazione basato sull'header AH, Authentication
Header; l'altro di autenticazione e crittografia basato sull'header ESP,
Encapsulating Security Payload.
SA - Associazioni di Sicurezza
Questo e' un concetto chiave dell'implementazione. Un SA e' una relazione
univoca tra originante e destinatario che permette l'uso dei sistemi di
sicurezza per il flusso di dati della loro trasmissione. Nel caso ci debba
essere una relazione di tipo peer si dovranno usare due SA, una per verso
della trasmissione. Ogni SA e' definito da tre parametri:
1) SPI - Security Parameters Index
Si tratta semplicemente di una stringa di bit presente su ogni
pacchetto inviato, che permetta di far riferimento alla SA in uso.
2) indirizzo IP di destinazione
3) Security Protocol Identifier
Questo indica se sia in uso una SA con AH o con ESP.
Come vengono gestite o scelte queste SA? In ogni implementazione deve
essere presente, anche se non viene bene spiegato come, [e' praticamente
evidente che ogni produttore abbia le mani libere] un database di SA, o
SAD :), che definisca per ogni SA questi parametri:
Sequence Number Counter
Un valore a 32bit usato per generare il numero di sequenza negli
header AH e ESP
Sequence Number Overflow
Una flag per indicare se dopo overflow del numero di sequenza si
debba generare un log e prevenire ulteriori trasmissioni di
pacchetti nella SA in corso
Anti-Replay Window
Usata per capire se un pacchetto inbound di tipo AH o ESP sia un
reinvio invece di un originale
AH Info
Algoritmi di autenticazione, chiavi, validita' delle stesse, e
parametri relativi.
ESP info
Idem come sopra, con marcato riguardo alla crittografia
Lifetime
Intervallo di tempo o di byte dopo il quale sia necessario variare
SA o terminare la connessione.
IPSec Protocol Mode
Tunnel, trasporto o *
MTU
Ora che siamo parecchio nella melma, relativamente a tutti questi
parametri, cerchiamo di capire come effettivamente vengano utilizzati o
finalizzati allo scopo di "Servire e Proteggere"(C).
IPSec fornisce all'amministratore notevole flessibilita' di spceifica
relativamente alle SA. Esiste una sorta di database delle policy, o SPD,
Security Policy Database, che gestisce dei record ognuno dei quali puo'
associare un determinato flusso di dati IP ad una o piu' SA insieme per
fornire la protezione ed integrita' desiderata ai nostri dati.
Un po' come le rules dei firewall, in grado di avere dei positivi o
negativi a seconda del tipo di traffico, ed in base a questi agire secondo
le rules stesse. Ogni record dentro al SPD contiene i selettori delle SA,
che devono essere comparati con quelli contenuti nei pacchetti della
trasmissione e la serie di SA associate a quei selettori. Dopodiche' il
sistema sara' in grado di operare il processo IPSec.
I selettori usati per l'associazione delle SA sono:
- indirizzi IP sorgente/destinazione
Abbastanza ovviamente, come per i firewall possiamo discriminare
in base ai punti base del traffico. Potremo specificare indirizzi
unicast, wildcard e range di indirizzi. Se useremo delle wildcard
o dei range potremo ovviamente mappare piu' SA a seconda di
ulteriori altri selettori discriminanti.
- UserID
Ehi questo e' interessante davvero. Poter finalmente discriminare
in base agli sgarbi subiti :). Cioe' no, in base alle richieste o
necessita' di singoli utenti, piuttosto che di interi sistemi.
- Data Sensivity Level
WOW. Non solo utenti, ma anche tipo di dati maneggiati, divisibile
in Secret o Unclassified.
- Transport Layer Protocol
Ehi il solito campo ip->protocol del caro IPv4 o ip->nexthdr
del novello IPv6.
- IPSec Protocol
AH o ESP
- porte sorgente/destinazione
univoche, range o wildcard ovviamente :)
- IPv6 Class e Flow Label
Ottenuti dall'header IPv6
- IPv4 TOS
Type Of Service
Ok. Ora sappiamo, piu' o meno, come dovrebbe decidere lo stack IPSec sul
da farsi. Ma una volta deciso? Esistono due modalita' principali di
funzionamento: trasporto e tunnel.
TRASPORTO
Questa modalita' gestisce protezione in primo luogo solo per i protocolli
dei layer soprastanti. Ovvero si associa al cosiddetto payload, carico
dei pacchetti IP. Questo vuol dire, ad esempio, gli header TCP/UDP, quelli
ICMP, ed i dati ad essi connessi. Quindi usando AH o ESP verranno
protetti, autenticati o criptati solo i dati dopo l'header IP, in IPv4
subito dopo, in IPv6 dopo gli header estesi. ESP cripta solo il carico,
laddove AH lo autentica occupandosi anche di alcuni campi dell'header IP.
TUNNEL
In questo modo invece e' possibile fornire ed estendere la protezione
all'intero pacchetto IP. Questo perche' viene incapsulato all'interno di
un nuovo stream punto punto in nuovi pacchetti IP, dopo che gli originali
siano stati sottoposti ad AH o ESP. Questo incapsulamento e' alla base
delle cosiddette VPN, o Virtual Private Networks. Vediamo uno schema:
IP prima
---------------------------
| IPHDR | PAYLOAD A/B |
---------------------------
HOST A <-----> FIREWALL/GATEWAY1
|
| INCAPSULAMENTO PER VPN
|
|
--------------FIREWALL/GATEWAY2 <-----> HOST B
IP durante l'incapsulamento operato dai gateway
-----------------------------------------
| IPHDR GW<>GW | IPHDR | PAYLOAD A/B |
-----------------------------------------
payload dell'IP incapsulato
Come possiamo vedere ora il pacchetto IP e' stato rinchiuso all'interno
di un nuovo pacchetto, che mostra i dati relativi alla connessione tra i
due gateway e NON quelli relativi ad A<>B ... il GW dell'host destinatario
si adoprera' per decapsulare il pacchetto e trasmetterlo al legittimo
destinatario. Ovviamente, se protetto con ESP non sara' possibile capire che
il payload del secondo pacchetto sia in realta' un pacchetto IP incapsulato.
Conseguenze prime: riservatezza e possibilita' di non divulgare all'esterno
nomi ed indirizzi di sistemi privati. Questo almeno finche' i gateway non
siano compromessi.
AH - AUTHENTICATION HEADER
Questo header fornisce un supporto per l'integrita' e l'autenticazione dei
dati trasmessi e delle parti in causa nella trasmissione. La prima
dovrebbe garantire che i pacchetti non siano stati in alcun modo alterati
durante il loro tragitto, mentre la seconda fornisce un aiuto per il
riconoscimento del sistema od utente remoto, oltre ad IMPEDIRE attacchi di
spoofing. Oltretutto garantisce contro attacchi di replay dei pacchetti.
Questi tipi di autenticazione sono basati su di un codice di
autenticazione dei messaggi, o MAC, che richiede l'uso di una chiave
segreta per entrambe le parti.
Vediamo ora questo AH:
0 8 16 31
---------------------------------------------------------
| next header | payload len | RESERVED |
---------------------------------------------------------
| Security Parameters Index (SPI) |
---------------------------------------------------------
| Sequence Number |
---------------------------------------------------------
| |
| Authentication DATA |
| variable |
---------------------------------------------------------
NextHeader, 8bit per identificare il tipo di header successivo ad AH.
PayLoad len, 8bit per specificare la lunghezza in parole a 32bit meno 2.
16bit riservati per usi futuri.
SPI, di cui abbiamo gia' parlato
Sequence Number, un numero di sequenza necessario per il rifiuto di
pacchetti gia' trasmessi.
Authentication Data, variabile, ma deve comunque essere un numero di
parole a 32bit che contiene il MAC del pacchetto.
AH fornisce un servizio AntiReplay per poter discriminare tra pacchetti
gia' ricevuti in modo da proteggersi da attacchi di ritrasmissione dei
dati. Questo servizio e' mediato dal numero di sequenza contenuto in AH.
Questo viene generato uguale a 0 ed incrementato per ogni pacchetto
generato all'interno della stessa SA. Di default il servizio antireplay e'
attivo, per cui chi trasmette non deve permettere al suo numero di
sequenza di superare 2^32-1, altrimenti ci sarebbero piu' numeri validi.
Per ovviare a cio' si scarta la SA in corso e se ne inizia una nuova.
Ricordiamo che IP puo' andare incontro a perdita o mancato ricevimento
sequenziale dei pacchetti. IPSec non fa eccezione, quindi la finestra di
accettazione dei pacchetti dovra' essere flessibile, ovvero di una
dimensione uguale a 64, col numero a destra come il piu' alto numero di
sequenza ricevuto. Ogni numero compreso tra N (il numero stesso) - 64 + 1
viene marchiato come ricevuto. Se viene ricevuto un pacchetto alla destra
della finestra e se il MAC corrisponde, la finestra avanza di uno. Se
viene ricevuto a sinistra viene scartato, cosi' come nel caso che il MAC
non sia valido e viene generato un log.
Ma come viene autenticato ogni pacchetto? Con il MAC per l'appunto.
Ovvero?! :)
Gli RFC specificano che si usi uno di questi due algoritmi per la gestione
del MAC: HMAC-MD5-96 e HMAC-SHA1-96. Non sta a me delucidarvi su questi
due algoritmi (ne avrei bisogno anche io :) ma posso dirvi con quali
elementi siano usati per autenticare il pacchetto.
Sostanzialmente usa elementi dell'header IP che siano immutabili o
prevedibili, poi tutto l'header AH ed infine il payload, che puo' essere
un semplice header di trasporto come TCP + dati, oppure tutto il pacchetto
IP nel caso di modalita' tunnel.
Gli elementi dell'header che non variano sono ihl e version e l'IP sorgente
ad esempio. Prevedibile e' l'IP destinatario. Campi variabili sono invece
il ttl ed il checksum che quindi vengono azzerati prima di essere
computati nel MAC. Dal momento che gli indirizzi IP vengono utilizzati per
il computo destinato all'autenticazione dei pacchetti, e' evidente come
questo possa proteggere dallo spoofing gli host che ne facessero uso. Per
IPv6 invece sono utilizzati la Versione (che non varia), l'indirizzo di
destinazione (variabile, ma prevedibile dalle tabelle di routing ad
esempio); mentre viene azzerato il Flow Label che e' invece totalmente
variabile.
MODALITA' DI TRASPORTO E TUNNEL
Per quanto riguarda IPv4 in modalita' trasporto, l'AH viene inserito dopo
l'header IP originale e prima del payload, comprensivo dei layer superiori;
L'autenticazione copre l'intero pacchetto, tranne che per quei campi
variabili suddetti che vengono azzerati nel computo del MAC.
---------------------------------
prima | IP Hdr | TCP Hdr | Data |
---------------------------------
-----------------------------------------
dopo | IP Hdr | AH | TCP Hdr | Data |
-----------------------------------------
per IPv6 invece, l'AH viene posto dopo gli header originali, anche quelli
estesi (tranne quello di opzioni per la destinazione che puo' essere prima
o dopo), ma non viene considerato o processato dai router intermedi, anzi
viene visto come normale payload punto-punto. Anche in questo caso
l'autenticazione copre l'intero pacchetto.
-----------------------------------------
prima | IP Hdr | Xtnd | TCP Hdr | Data |
-----------------------------------------
-------------------------------------------------
dopo | IP Hdr | Xtnd | AH | TCP Hdr | Data |
-------------------------------------------------
In modalita' tunnel invece, tutto il pacchetto e' si autenticato, ma l'AH
viene posto tra l'header originale ed il nuovo ed esterno header
incapsulante.
ESP - Encapsulating Security Payload
Questo protocollo permette ad IPSec di fornire servizi di confidenzialita'
dei dati. Puo' anche fornire opzionalmente gli stessi servizi di AH in
merito all'autenticazione dei dati stessi.
Ecco l'header ESP:
0 16 24 31
-------------------------------------------------
| Security Parameters Index (SPI) |
-------------------------------------------------
| Sequence Number |
-------------------------------------------------
| |
| |
| Payload Data (variable) |
| ---------------------------------
| | |
----------------- -------------------------
| Padding (0-255) | Pad Len | Next HDR |
-------------------------------------------------
| Authentication Data (variable) |
-------------------------------------------------
Beh, l'SPI l'abbiamo ormai visto e rivisto, identifica le SA.
Anche il numero di sequenza dovrebbe esser chiaro.
Payload data non e' altro che il segmento di trasporto o, nel caso di
modalita' tunnel, il pacchetto IP incapsulato.
Il PADDING e' importante. Serve a tre scopi:
- se un algoritmo per la crittografia dei dati richiede che il testo in
chiaro sia un multiplo di qualche valore, possiamo aumentare i dati fino a
renderli tali
- ESP richiede che i campi successivi siano allineati in una parola di
32bit. Oltretutto il testo cifrato dev'essere un multiplo intero di 32
- puo' essere usato per aumentare la confidenzialita' dei dati, oscurando
la reale lunghezza dei dati, una volta che siano stati cifrati
Pad len indica il numero di byte precedenti questo campo.
Next header identifica il tipo di dati contenuti nel payload, una volta
che sia stato cifrato.
Authentication data contiene il MAC computato su tutto il resto
dell'header ESP.
Gli algoritmi utilizzati nella crittografia dei pacchetti IP o dei payload
nel caso di semplice trasporto sono: triploDES con 3 chiavi, RC5, IDEA,
triploIDEA con 3 chiavi, CAST e Blowfish.
Per algoritmi che richiedano dati specifici come l'IV, initialization
vector, questi possono essere inseriti all'inizio del payload. La
specifica base richiede almeno il DES in CBC, cipher block chaining. Ogni
prodotto che sia stato certificato come IPSec compliant deve rispondere a
questi requisiti.
MODALITA' DI TRASPORTO E TUNNEL
In modalita' trasporto, ESP puo' essere utilizzato per criptare ed
autenticare i dati trasportati da IP, come con TCP. In questo caso
l'header ESP si trova tra l'originale IP e quello dei layer superiori.
Come avrete immaginato, se TCP e dati vanno nel campo payload di ESP, dove
finiranno gli altri campi di ESP? Semplicemente in un suffisso DOPO il
pacchetto IP originale. Avremo ad esempio per IPv4:
--------------------------------------------------
| IP hdr | ESP hdr | TCP hdr | data | ESPe | ESPa|
--------------------------------------------------
dove ESPe include Padding, PAD len, next hdr ed ESPa invece
l'authentication data. Le operazioni di trasporto di ESP consistono in:
- alla sorgente il payload (TCP e dati) ed il suffisso ESP, o trailer,
vengono crittati. Nel caso di autenticazione si aggiunge il campo apposito
e si calcola il MAC.
- ogni hop puo' esaminare l'header, ma NON il payload cifrato
- alla destinazione, in possesso delle chiavi, il payload viene decrittato
in base all'SPI dell'header ESP.
La modalita' tunnel e' diventata famosa con l'avvento delle VPN. In questo
caso viene criptato TUTTO il pacchetto IP e poi incapsulato in un altro
con gli indirizzi dei gateway. In questo caso l'ESP si trova prima dell'
header originale, ma DOPO il nuovo header IP.
In questo caso il peso dei processi criptograffici investe solo i sistemi
che si occupano del routing in internet, laddove gli host sulle LAN
protette possono inviare tranquillamente i loro pacchetti in chiaro,
sicuri che il firewall mediante la gestione delle SA, incapsuli le loro
connessioni tra un gateway e l'altro.
- la sorgente preleva il pacchetto, gli prepende un ESP, postpende il
trailer e cripta tutto il pacchetto, dopodiche' lo incapsula in un altro
IP e lo invia
- gli hop intermedi possono solo processare gli header esterni aggiunti
dal router IPSec e non i dati criptati.
- alla destinazione il pacchetto viene liberato dall'incapsulamento e
decriptato per essere poi inviato in chiaro nella LAN protetta.
E' chiaro che le varie SA possano essere combinate per venire incontro
alle esigenze delle varie configurazioni di rete. In due modi
sostanzialmente: mediante adiacenza o tunnel iterativo. Nel primo caso si
decide di utilizzare l'AH e l'ESP indipendentemente sullo stesso
pacchetto, in maniera sequenziale, mentre nel secondo modo si inseriscono
tunnel uno dentro l'altro, un po' come per i remailer cipherpunk.
GESTIONE DELLE CHIAVI
Come abbiamo visto sono necessarie chiavi segrete sia per il MAC dell'AH
che per gli algoritmi dell'ESP. Ebbene e' inutile girarci intorno. :) Ci
sono in pratica solo due modi: o gestirle in un database statico, nel caso
le comunicazioni siano limitate a pochi sistemi, oppure mediante un
sistema sicuro di presentazione dinamica delle chiavi.
Per questo secondo metodo si usano due protocolli specificati negli RFC:
ISAKMP e Oakley.
Il primo non si occupa letteralmente della gestione delle chiavi. In
realta' serve a negoziare tra le parti in modo da poter gestire le chiavi
con il protocollo Oakley. Questo e' una modifica dell'algoritmo
Diffie-Hellman. Tale modifica si basa sull'uso di gruppi di calcolo di
cookie utilizzati per l'estrapolazione di una comune chiave di sessione
cercando di proteggersi da attacchi tipo man-in-the-middle. Eventualmente
le parti in gioco possono anche utilizzare firme digitali basate su hash
ottenibili da userid ed altri parametri, oppure mediante crittazione a
chiave pubblica ....
Non e' compito di questo articolo la presentazione degli algoritmi per lo
scambio e la gestione delle chiavi, quanto presentare una introduzione
all'architettura di IPSec.
Per chi volesse saperne di piu' e' consigliabile rivolgersi a testi di un
certo calibro e peso :) tipo Applied Cryptography di B.Schneier o
Cryptography and Network Security di W.Stallings.
Questo e' in soldoni un primo "what's!??!" su IPSec. Ovviamente non deve
bastarvi questo se siete realmente interessati. Gli RFC che ho nominato
possono fare per voi. Come al solito un buon libro potra' di certo esser
d'aiuto per TCP/IP in generale, e saprete ormai a memoria quale suggerirei,
vero?! :P
Per gli aspetti relativi alla sicurezza sull'uso delle chiavi rifatevi ai
libri che ho nominato piu' sopra per la criptografia.
ED IL CODICE ?!
Sorry, ma non c'e' codice in questo articolo. Iiiiihhhhhh!
Lo so :) ma non c'e' molto in giro. Anche per Linux sono dolori al
momento. Dovreste patcharvi il kernel per usare il modulo x-kernel su cui
stanno sviluppando un applicazione IPSec free. Cercate su altavista
ipsec+xkernel+linux e ci arriverete. Al momento vi dovete accontentare di
IPv6. Cercate nella dir /usr/src/linux/net/ipv6 del kernel 2.2.x e
guardate anche in /usr/src/linux/Documentation .
Ma ci sara' sicuramente tempo per i codici e gli attacchi/difese. Non
manca ancora molto ad IPv6 ed IPSec: arriveranno prima che tutti voi vi
siate stufati di questi giochi :) ed allora per ballare bisognera' capire
e codare, come sempre...
See you there,
FuSyS
--------------------[ previous ]---[ index ]---[ next ]---------------------
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
==============================================================================