Sicurezza delle reti IP Accesso remoto via canali dial-up

Transcript

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 )
#
##
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
IPsec
header
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 )
IPv4 header
( end-to-end )
IPv4 header
( end-to-end )

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
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 )
IPv4 header
( end-to-end )
#
IPv4 header
( tunnel )
ESP
header
IPv4 header
( 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)
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)
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
(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
(tunnel-mode SA)
LAN
IPsec
gateway
LAN
IPsec
IPsec
(transport-mode SA)
Secure gateway
WAN
IPsec
gateway
#
LAN
IPsec
Secure remote access
WAN
IPsec
gateway
LAN
IPsec
IPsec
(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).