Sicurezza delle reti IP Sicurezza delle reti IP Reti private Classi per

Transcript

Sicurezza delle reti IP
(netsec - dic'01)
Reti private
Sicurezza
Sicurezza delle
delle reti
reti IP
IP
Antonio Lioy
< lioy @ polito.it >
Politecnico di Torino
Dip. Automatica e Informatica
Classi per le reti private
classe A (una sola rete)
rete: 10.x.x.x = 10/8
classe B (16 reti adiacenti)
reti: 172.16.x.x ... 172.31.x.x = 172.16/12
classe C (256 reti adiacenti)
reti: 192.168.0.x ... 192.168.255.x = 192.168/16
anche dette 24 / 20 / 16-bit blocks
Organizzazione di una rete privata
Network address translator (NAT)
traduzione degli indirizzi IP privati in indirizzi
pubblici in modo automatico:
in modo statico (uno a uno)
in modo dinamico (uno per molti)
svantaggi:
limite di prestazioni
servizi pubblici richiedono indirizzo fisso
problemi con UDP e quando gli indirizzi IP sono
usati a livello applicativo
vantaggi:
non richiede modifica degli applicativi
© Antonio Lioy - Politecnico di Torino (1997-2001)
molte organizzazioni non hanno bisogno che
alcuni loro indirizzi siano visibili globalmente (es.
display TCP/IP degli aereoporti)
per evitare di sprecare indirizzi la IANA ha
definito delle reti private, ossia non uniche a
livello mondiale
(RFC-1918)
si possono usare senza chiedere l’autorizzazione
purché si garantisca che siano limitate alla rete
interna
host pubblici con indirizzo IANA
host privati con indirizzi privati
due soluzioni per accedere da host privati a
servizi pubblici:
application gateway (proxy) sugli host pubblici
network address translator (NAT)
RFC per NAT
RFC-2663 “IP Network Address Translator (NAT)
terminology and considerations”
RFC-2766 “Network Address Translation Protocol Translation (NAT-PT)”
RFC-2993 “Architectural implications of NAT”
RFC-3022 “Traditional IP Network Address
Translator (traditional NAT)”
RFC-3027 “Protocol complications with the IP
Network Address Translator”
1
(netsec - dic'01)
NAT
Application gateway (proxy)
implementazione software:
processo su un dual-homed host
es. per Linux, NT
implementazione hardware:
nei router
Accorgimenti pratici
Organizzazione dei nameserver
cablaggio separato per la parte pubblica e
privata (problemi di routing e netmask)
stessa sottorete per host con stesso destino (o
tutti pubblici o tutti privati)
filtri sui router verso le reti pubbliche (evita la
propagazione di informazioni circa la rete
privata)
NS pubblico e privato
Internet
Pri1
Pri2
rete a commutazione
di circuito
(RTC / ISDN)
IP(www.ibm.com)
public NS
(pub + inet)
router
pub1
(WWW)
private NS
(pri + pub + inet/forw)
NS pubblico
con indirizzo ufficiale IANA
nomi e indirizzi degli host pubblici
collegato al DNS mondiale
NS privato
con indirizzo privato
nomi e indirizzi degli host pubblici e privati
usa NS pubblico come forwarder
tutti gli host (sia pubblici sia privati) usano il NS
privato
Accesso remoto via canali dial-up
D
N
S
IP(pubX)
funzionamento:
riceve richiesta da Hpri
inoltra richiesta col proprio IP (pubblico)
riceve risposta
inoltra risposta a Hpri
richiede consapevolezza dell’esistenza del proxy
da parte del richiedente
permette di far passare selettivamente solo certi
protocolli / richieste / utenti
protocollo di proxy
pub2
(SMTP)
router
NAS
(Network
Access
Server)
rete IP
(Internet)
2
(netsec - dic'01)
Autenticazione di canali PPP
PPP è un protocollo ...
... per incapsulare pacchetti di rete (L3, es. IP) ...
... e trasportarli su un collegamento punto-punto
reale (es. RTC, ISDN)
virtuale L2 (es. xDSL con PPPOE)
virtuale L3 (es. L2TP su UDP/IP)
tre fasi, svolte in sequenza:
LCP (Link Control Protocol)
autenticazione (opzionale, PAP, CHAP o EAP)
L3 encapsulation (es. IPCP, IP Control Protocol)
PAP
CHAP
EAP
RFC-1994 “PPP Challenge Handshake
Authentication Protocol (CHAP)”
meccanismo a sfida
sfida iniziale obbligatoria, possibile ripetere la
richiesta (con sfida diversa) durante la
comunicazione a discrezione dell’NAS
chi supporta sia CHAP sia PAP, deve prima
offrire CHAP
Autenticazione per collegamenti dial-up
protocol
manager
rete IP
Authentication
Authentication
Server
Server
RFC-2284
“PPP Extensible Authentication Protocol (EAP)”
autenticazione esterna a PPP
tipi predefiniti:
MD5-challenge (simile a CHAP)
OTP
generic token card
altri tipi possono essere aggiunti:
RFC-2716 “PPP EAP TLS authentication protocol”
Le tre A
utente
abilitato?
Network
Network
Access
Access
Server
Server
Password Authentication Protocol
RFC-1334
user-id e password inviate in chiaro
autenticazione solo all’attivazione del
collegamento
molto pericoloso!
i produttori di NAS dicono che la sicurezza
richiede tre funzioni:
Autenticazione
Autorizzazione
Accounting
l’AS ricopre proprio queste tre funzioni
dialogando con uno o più NAS tramite uno o più
protocolli
Si / No,
configurazione,
...
3
(netsec - dic'01)
Collocazione dell’AS
in caso di outsourcing della rete IP
presso il fornitore del servizio di accesso
velocità
minor sicurezza
spazio per contestazioni
presso il cliente che richiede il servizio
minor velocità
maggior sicurezza
nessun spazio per contestazioni
RADIUS
RADIUS
RADIUS
il server può fungere da proxy verso altri server
integrità ed autenticazione dei pacchetti tramite
keyed-MD5:
key = shared-secret
client senza key sono ignorati
password crittografata con MD5:
password ⊕ md5(key+autenticatore)
RADIUS - formato
code
identif
Remote Authentication Dial-In User Service
Livingston Technologies
RFC-2138 (protocollo)
RFC-2139 (accounting)
obsoleti: RFC-2058/9
UDP, porta 1812 (errore: UDP/1645)
schema client-server tra NAS e AS
timeout e ritrasmissione
server secondari
length
RADIUS - pacchetti
autenticatore
autenticazione dell’utente tramite PAP, CHAP o
token-card
CISCO fornisce server per CryptoCard
altri offrono SecurID
formato facilmente estendibile senza modificare
l’installato:
attribute - length - value
ACCESS-REQUEST
ACCESS-REJECT
ACCESS-CHALLENGE
ACCESS-ACCEPT ( parametri ):
SLIP/PPP: IPaddr, netmask, MTU, ...
terminal: host, port
... attributi ...
4
(netsec - dic'01)
TACACS
Terminal Access Controller Access Control
System
CISCO
RFC-1492
UDP, porta 49
oggi evoluto verso XTACACS e TACACS+
TACACS
TACACS - connessioni
TACACS - request
AUTH (user, pass, line, style)
LOGIN (user, pass, line)
LOGOUT (user, pass, line, reason)
CONNECT (user, pass, line, destIP, destPort)
SLIPADDR
SLIPON (user, pass, line, SLIPaddr)
SLIPOFF (user, pass, line, reason)
SUPERUSER (user, pass, line)
TACACS - versione TCP
contemplata dall’RFC-1492
porte non preassegnate (configurabili sia sul
client che sul server)
protocollo ASCII con codici di errore tipo RFC821 (SMTP)
autenticazione pura:
AUTH
login ad un host:
LOGIN
CONNECT
LOGOUT
collegamento SLIP:
LOGIN
CONNECT
SLIPADDR
CONNECT
SLIPON + LOGOUT
SLIPOFF
TACACS+
request - reply
tra client (=NAS) e server (=AS)
reply = (r1, r2, r3)
semantica specifica del costruttore
password in chiaro nei pacchetti
CISCO
draft RFC: draft-grant-tacacs-00.txt
TCP, porta 49
pacchetti tra NAS e AS autenticati tramite MD5,
autenticatore da 16 byte ed un segreto condiviso
crittografia di tutto il pacchetto (XOR)
permette la separazione delle A
es. autenticazione con Kerberos
5
(netsec - dic'01)
Sicurezza a livello fisico
A quale livello di rete è meglio
realizzare la sicurezza?
Application
firewall? IPSEC?
smart-card?
apparati cifranti?
guardie armate?
protezione fisica:
del supporto trasmissivo
degli amplificatori / ripetitori / convertitori
tipicamente solo in ambiente militare
Presentation
Session
AMP
Transport
Network
e-
CONV
e-
γ
e-
Data Link
cavi elettrici
Physical
Sicurezza a livello data-link
Sicurezza a livello fisico
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
apparati cifranti per proteggere i dati a
livello 2 (MAC)
solo per segmenti con tecnologia omogenea
LAN
spezzoni di WAN
router
011
ethernet
Sicurezza a livello data-link
sebbene esistano schede cifranti da installare
sui client, normalmente non si protegge il livello
2 sulle stazioni
si comincia a pensare la gestione della LAN
associata a quella della sicurezza:
VLAN
switch / hub con porte protette
allarmi automatici al comparire di un nuovo MAC
assegnazione statica degli indirizzi
no a DHCP completamente dinamico
fibra ottica
router
011
011
ISDN
frame relay
Sicurezza del DHCP
protocollo non autenticato
facilissimo attivare shadow server
attacchi possibili:
denial-of-service (fornisco configurazione di rete
sbagliata)
intercettazione di tutte le comunicazioni (fornisco
configurazione con default gateway uguale alla
macchina che vuole effettuare lo sniffing)
6
(netsec - dic'01)
Che cos’è una VPN?
Sicurezza a livello network
protezione end-to-end per reti omogenee a livello
logico (es. IP)
permette di creare VPN (Virtual Private Network)
una tecnica (hardware e/o software) per
realizzare una rete privata ...
... utilizzando canali e apparati di trasmissione
condivisi
rete IP
server
FIAT
FIAT
Melfi
Melfi
ENI
ENI
Milano
Milano
router
rete pubblica
router
client
FIAT
FIAT
Torino
Torino
Dove si applica una VPN?
quando si attraversa una rete pubblica e/o non
fidata ...
... 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?
mediante reti nascoste
mediante routing protetto (tunnel IP)
mediante protezione crittografica dei pacchetti
rete (tunnel IP sicuro)
quando si attraversa una rete pubblica e/o non
fidata ...
... per comunicazioni interaziendali senza accordi
precedenti
... per comunicazioni con clienti non noti a priori
(commercio elettronico di tipo business-toconsumer)
1. VPN mediante rete nascosta
Tecniche di realizzazione di una VPN
ENI
ENI
Roma
Roma
le reti da collegare utilizzano un indirizzamento
non standard per non essere raggiungibili da
altre reti (es. reti nascoste IANA secondo RFC1918)
è una protezione facilmente superabile se
qualcuno:
scopre gli indirizzi usati
può leggere i pacchetti in transito
ha accesso all’infrastruttura di comunicazione
7
(netsec - dic'01)
2. VPN mediante tunnel IP
VPN mediante tunnel IP
i router provvedono ad incapsulare i pacchetti di
rete all’interno di altri pacchetti
i router controllano l’accesso alle reti mediante
ACL (Access Control List)
esempio: la rete Arcipelago di Telecom Italia
rete pubblica
R1
protezione superabile da chi gestisce i router o
da chi può leggere i pacchetti in transito
IPv4 header
( tunnel )
TCP/UDP header + data
IPv4 header
( end-to-end )
se gli algoritmi crittografici sono forti, allora
l’unico attacco possibile è impedire le
comunicazioni
Tunnel IP: compatibilità
TAP2 R2
IPv4 header
( end-to-end )
Internet
rete1
rete2
prima di essere incapsulati i pacchetti di rete
vengono protetti con:
digest (per integrità ed autenticazione)
crittografia (per riservatezza)
numerazione (per evitare replay)
TAP3
B
VPN mediante tunnel IP sicuro
TAP1
A
3. VPN mediante tunnel IP sicuro
se il pacchetto da trasmettere ha la massima
dimensione consentita, allora deve essere
frammentato
massimo degrado = 50%
soffrono maggiormente gli applicativi con
pacchetti grandi (tipicamente non interattivi)
R1
A→B
A→B
rete1
Tunnel IP: frammentazione
R2
R1 → R2
A→B
rete2
esistono diversi protocolli per realizzare il tunnel:
IP in IP (RFC-1853)
swIPe
IPsec = ESP+AH (IPv4 e IPv6)
altri
anche il meccanismo di negoziazione del tunnel
non è standard
8
(netsec - dic'01)
IPsec
Servizi di sicurezza IPsec
proposta IETF per fare sicurezza al livello 3 sia in
IPv4 sia in IPv6
usabile per creare VPN su reti pubbliche o per
fare sicurezza end-to-end
definisce due formati particolari:
AH (Authentication Header)
per integrità, autenticazione, no replay
ESP (Encapsulating Security Payload)
per riservatezza (+AH)
usa un protocollo per scambio chiavi:
IKE (Internet Key Exchange)
autenticazione dei pacchetti IP:
integrità dei dati
identificazione del mittente
protezione da attacchi di tipo “replay”
riservatezza dei pacchetti IP:
cifratura dei dati
IPsec Security Association (SA)
Database locali IPsec
connessione logica unidirezionale tra due
sistemi IPsec
ne occorrono due per avere protezione completa
di un canale bidirezionale
SA (A, B)
SA (B, A)
Come funziona IPsec (spedizione)
pacchetto IP
IPsec - prima versione
SPD
regole di sicurezza
SAD
quale policy?
crea / legge SA
modulo
IPsec
SAD (SA Database)
elenco delle SA attive e delle loro
caratteristiche (algoritmi, chiavi,
parametri)
SPD (Security Policy Database)
contiene le security policy da applicare ai
diversi tipi di comunicazione
deve essere configurato a priori (es.
manualmente) oppure essere agganciato
ad un sistema automatico (es. ISPS,
Internet Security Policy System)
agosto 1995
RFC-1825 = architettura
RFC-1826 = AH
RFC-1827 = ESP
algoritmi / parametri
pacchetto IP
con IPsec
9
(netsec - dic'01)
IPsec - seconda versione
IPsec - scambio chiavi
novembre 1998
RFC-2411 = IPsec document roadmap
RFC-2401 = architecture
RFC-2402 = AH
RFC-2403 = HMAC-MD5-96 in ESP e AH
RFC-2407 = interpretazione IPsec di ISAKMP
RFC-2408 = ISAKMP
RFC-2409 = IKE
RFC-2412 = OAKLEY
RFC-2404 = HMAC-SHA-1-96 in ESP e AH
RFC-2405 = ESP DES-CBC con IV esplicito
RFC-2406 = ESP
RFC-2410 = cifratura nulla in IPsec
RFC-2451 = algoritmi per ESP DES-CBC
Header IPv4
Header IPv4
0
4
Vers.
8
16
IHL
TOS
31
Total length
Identification
TTL
19
Flags
Protocol
Fragment offset
Header checksum
Source IP address
Destination IP Address
Options
indirizzi IP (32 bit) del mittente e del destinatario
IHL (Internet Header Length) in 32-bit word
TOS (Type Of Service): mai usato (!)
Length: n. di byte del pacchetto IP
Identification: ID del pacchetto (per i frammenti)
Flags: may/don’t fragment, last/more fragments
TTL (Time To Live): numero massimo di hop
protocol: protocollo usato dal payload
Padding
Header IPv6
0
4
Version
8
16
Priorit.
IPsec in transport mode
24
31
Flow Label
Payload Length
Next Header
Hop Limit
Source Address
usato dagli host, non dai gateway
(eccezione: traffico destinato al gateway,
es. SNMP, ICMP)
vantaggio: computazionalmente leggero
svantaggio: non protegge i campi variabili
IPv4
header
Destination Address
IPv4
header
IPsec
header
10
(netsec - dic'01)
AH
IPsec in tunnel mode
usato solitamente dai gateway
vantaggio: protegge anche i campi variabili
svantaggio: computazionalmente pesante
IPv4 header
( end-to-end )
IPv4 header
( end-to-end )
IPv4 header
( end-to-end )
IPv4 header
( tunnel )
IPv4 header
( tunnel )
IPsec
header
Authentication Header
meccanismo (prima versione, RFC-1826):
integrità dei dati ed autenticazione del
mittente
obbligatorio keyed-MD5 (RFC-1828)
opzionale keyed-SHA-1 (RFC-1852)
meccanismo (seconda versione, RFC-2402):
integrità dei dati, autenticazione del mittente
e protezione da replay attack
HMAC-MD5-96
HMAC-SHA-1-96
AH in transport mode
AH in tunnel mode
es. SNMP, ICMP)
vantaggio: computazionalmente leggero
svantaggio: non protegge i campi variabili
IPv4
header
IPv4
header
AH
IPv4 header
( tunnel )
IPv4 header
( tunnel )
AH - posizionamento in IPv6
IPv6
header
AH
vantaggio: protegge anche i campi variabili
svantaggio: computazionalmente pesante
AH
IPv4 header
( end-to-end )
IPv4 header
( end-to-end )
IPv4 header
( end-to-end )
AH - formato (RFC-1826)
Next Header
Length
reserved
Security Parameters Index (SPI)
IPv6
header
Routing
header
IPv6
header
AH
AH
end-to-end
options
.
.
.
dati di autenticazione
(ICV, Integrity Check Value)
.
.
.
11
(netsec - dic'01)
AH - formato (RFC-2402)
pacchetto IPsec ricevuto
estrazione
normalizzazione
SAD
Next Header
Length
SPI
reserved
pacchetto IP
normalizzato
algoritmo,
parametri
AH
estrazione
Sequence number
calcolo del valore
di autenticazione
ICV
.
.
.
.
.
.
valore di
autenticazione
ricevuto
valore di
autenticazione
calcolato
sì
valori
uguali?
mittente falso e/o
pacchetto manomesso
mittente autentico e
pacchetto integro
Normalizzazione per AH
azzerare il campo TTL / Hop Limit
se il pacchetto contiene un Routing 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 en route) attivo
Keyed-MD5 in AH
dato M normalizzarlo generando M’
allineare a 128 bit M’ (aggiungendo byte 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:
B = md5 (
(Kp ⊕ op) || md5 ( (Kp ⊕ ip) || M’p ) )
ICV = 96 leftmost bit di B
dato M normalizzarlo generando M’
allineare a 128 bit M’ (aggiungendo byte a zero)
generando così M’p
allineare a 128 bit la chiave K (aggiungendo byte
a zero) generando così Kp
calcolare il valore di autenticazione:
ICV = md5 ( Kp || M’p || Kp )
HMAC-MD5-96
no
ESP
Encapsulating Security Payload
prima versione (RFC-1827)
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
12
(netsec - dic'01)
ESP in tunnel mode
ESP in transport mode
es. SNMP, ICMP)
svantaggio: non nasconde l’header
IPv4
header
IPv4
header
IPv4 header
( tunnel )
ESP
header
vantaggio: nasconde anche gli header
ESP
trailer
IPv4 header
( tunnel )
ESP
header
IPv4 header
( end-to-end )
IPv4 header
( end-to-end )
IPv4 header
( end-to-end )
parte cifrata
parte cifrata
ESP - posizionamento in IPv6
parte in chiaro
IPv6 Header
Next Header =
...
ESP - formato (RFC-1827)
parte crittografata
... Extension
Header ...
Header ESP
ESP
trailer
payload crittografato
ESP - formato (RFC-2406)
.
.
.
dati crittografati
.
.
.
ESP-DES-CBC - formato (RFC-1827)
Sequence number
.
.
.
Initialization Vector (IV)
.
.
.
.
.
.
Payload
.
.
.
dati crittografati
Padding
Padding Length
Payload Type
13
(netsec - dic'01)
ESP-DES-CBC - formato (RFC-2406)
Sequence number
.
.
.
Initialization Vector (IV)
.
.
.
.
.
.
Payload
.
.
.
Padding
.
.
.
.
Padding Length
Dettagli implementativi
Payload Type
.
.
.
.
sequence number:
non deve essere strettamente sequenziale
(protezione solo da replay)
finestra minima di 32 pacchetti (consigliati 64)
algoritmi NULL:
per autenticazione
per crittografia (RFC-2410)
offrono trade-off protezione - prestazioni
End-to-end security
Basic VPN
WAN
WAN
gateway
gateway
LAN
LAN
IPsec
canale virtuale sicuro
(transport-mode SA)
IPsec
gateway
LAN
LAN
IPsec
WAN
IPsec
gateway
LAN
(transport-mode SA)
LAN
Secure remote access
WAN
(tunnel-mode SA)
IPsec
gateway
IPsec
End-to-end security with basic VPN
IPsec
gateway
(tunnel-mode SA)
IPsec
IPsec
i curo
ale s
virtu e SA)
le
a
can nel-mod
(tun
(transport-mode SA)
IPsec
gateway
LAN
IPsec
14
(netsec - dic'01)
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
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 può essere riusata più volte
per negoziare altre SA IPsec
IKE - funzionamento
1
initiator
responder
1 - negoziazione di una SA ISAKMP bidirezionale:
“main mode” o “aggressive mode”
ISAKMP SA
2
initiator /
initiator /
responder
responder
2 - negoziazione della SA IPsec: “quick mode”
IKE: “modi” di funzionamento
Main Mode:
6 messaggi
protegge l’identità delle parti
Aggressive Mode:
3 messaggi
Quick Mode:
3 messaggi
negoziazione solo della SA IPsec
New Group Mode:
2 messaggi
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: metodi di autenticazione
Digital Signature: non-repudiation della
negoziazione IKE
Public Key Encryption: protezione dell’identità
nell’aggressive mode
Revised Public Key Encryption: meno costoso,
solo 2 operazioni a chiave pubblica
Pre-Shared Key: l’ID della controparte pùo essere
solo il suo indirizzo IP (problema per gli utenti
mobili)
15
(netsec - dic'01)
IPsec nei sistemi operativi
IPsec è implementato in tutti gli Unix più recenti
SUN l’ha implementato con SKIP, tutti gli altri
con ISAKMP+OAKLEY (SUN si allinea con
Solaris 8)
IPsec nei router
Microsoft lo ha introdotto nei suoi prodotti a
partire da Windows-2000
IPsec nei firewall
alcuni produttori di firewall (es. IBM, Checkpoint)
hanno recentemente introdotto IPsec all’interno
dei loro prodotti di tunnel sicuro
forniscono gratuitamente il client per Windows
che però può creare un canale IPsec solo col
proprio firewall
Posizionamento di tunnel IPsec
IPsec in Windows 2000
Microsoft ha implementato IPsec in Windows
2000 in modo nativo:
negoziazione delle chiavi tramite IKE
gestione delle policy IPsec tramite Active
Directory (permette di definire un’unica policy per
tutto il dominio)
problemi di interoperabilità
tutti i principali fornitori di router (Cisco, 3COM,
Nortel, ...) hanno IPsec sui router
tipicamente è usato solo per creare canali
protetti tra i router ma non con gli end-node
Cisco ha anche l’autenticazione a chiave
pubblica con certificati X.509
sul router:
router potente o con scheda crittografica
non gestito in outsourcing
sul firewall:
CPU potente
su box IPsec:
posto in serie al router e/o firewall
indipendente dalle altre misure di sicurezza
Windows 2000 IPsec
nominalmente aderente allo standard
implementando numerosi RFC e draft (RFC:
1825...1829,1851,1852,2085,2104)
autenticazione basata su Kerberos v5, certificati
X.509 o pre-shared key
algoritmi: DES, 3DES, MD5 e SHA1
Security Association negoziata tramite IKE
16
(netsec - dic'01)
Windows 2000 IPsec implementato
alcuni degli RFC che MS dichiara di aver
implementato sono obsoleti
Win2000 IPsec tunnel mode non rispetta lo
standard (!!!) ma si appoggia su L2TP, rendendo
impossibile l’interoperabilità con altri sistemi
autenticazione con Kerberos non sempre
funziona
algoritmi per l’esportazione sono DES, MD5, SHA1
... ma il sistema non dice niente all’utente (si
sceglie 3DES ma Win2000 usa poi DES)
problemi di interoperabilità con gli altri sistemi
provati per quando riguarda IKE
IPsec tunnel mode/L2TP
Windows 2000 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’autentificazione dell’utente
non supporta il multiprotocollo
non supporta il multicast
la scelta di L2TP causa problemi di
interoperabilità tra sistemi diversi
Che cos’è L2TP?
IPsec over L2tp
Layer-2 Tunnel Protocol (RFC-2661)
incapsula i pacchetti 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
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
Sicurezza di IP
indirizzi non autenticati
pacchetti non protetti:
integrità
autenticazione
riservatezza
Sicurezza di ICMP
Internet Control and Management Protocol
vitale per la gestione della rete
possibili moltissimi attacchi perché
completamente privo di autenticazione
funzioni ICMP:
echo request / reply
destination unreachable (network / host /
protocol / port unreachable)
source quence
redirect
time exceeded for a datagram
17
(netsec - dic'01)
Smurfing attack
src = A
dst = X.Y.255.255
ICMP echo request
Contromisure anti-smurfing
per attacchi dall’esterno: rifiutare il broadcast IP
interface serial0
no ip directed-broadcast
per attacchi dall’interno: identificare il
responsabile tramite strumenti di network
management
reflector
(network X.Y)
ultimate target
(A)
Fraggle attack
src = A
dst = X.Y.255.255
UDP echo request
TCP SYN flooding
SYN
reflector
(network X.Y)
connessioni
di rete
SYN/ACK
SYN
ACK (?)
SYN
SYN
client
ultimate target
(A)
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 ha successo, trasferisce il canale
al server
timeout “aggressivi” (rischio!)
usare un router come “SYN monitor”:
uccide i collegamenti pendenti (RST)
ACK
server
richieste multiple con IP spoofing
si satura la tabella delle connessioni sino
a quando non vanno in timeout (valore
tipico: 75”)
Sicurezza del DNS
DNS (Domain Name System)
traduzione:
da nomi ad indirizzi IP
da indirizzi IP a nomi
servizio indispensabile
UDP/53 per le query
TCP/53 per zone transfer
nessun tipo di sicurezza
in corso di sviluppo DNS-SEC
18
(netsec - dic'01)
Architettura del DNS
DNS shadow server
root
root NS
NS (.)
(.)
NS
NS (de.)
(de.)
NS
NS (it.)
(it.)
sniffing per intercettare le query
spoofing per generare risposte false
(DoS o ridirezione del traffico su siti falsi)
nameserver
(local)
(local) NS
NS
utente
NS
NS
(polito.it.)
(polito.it.)
NS
NS
(fiat.it.)
(fiat.it.)
(shadow)
nameserver
DNS
nameserver
client
client
IP (www.aipa.it)?
DNS cache poisoning
BIND
attirare la vittima a fare una query sul proprio NS
fornire risposta anche a query non effettuate per
forzare / sovrascrivere la cache della vittima
IP (www.lioy.net)?
(bandit)
nameserver
www.lioy.net = 7.2.1.5
www.ibm.com = 7.2.1.5
www.microsoft.com = 7.2.1.5
(victim)
nameserver
Sicurezza del routing
bassa sicurezza nell’accesso ai router per
configurarli (telnet, SNMP)
bassa sicurezza nello scambio delle tabelle di
routing
vari produttori stanno lavorando per usare
certificati X.509 nell’autenticazione delle tabelle
di routing
variazioni dinamiche del routing anche sugli endnode tramite ICMP
per la sicurezza del DNS si raccomanda l’uso (e
l’aggiornamento periodico!) di BIND
Berkeley Internet Name Domain server
gratis
per Unix e Windows-NT
http://www.isc.org
Protezione fisica dei router
limitare l’accesso fisico ai router solo alle
persone autorizzate
porta di console:
aggancio diretto di un terminale o PC
permette accesso diretto coi massimi privilegi
proteggerla tramite una password (per default
non c’è!)
19
(netsec - dic'01)
Protezione logica dei router
attivare le ACL più comuni
proteggere l’accesso al file di configurazione
(ovunque conservato) perché esso contiene:
le password (spesso in chiaro!)
le ACL basate su indirizzi IP
Esempi protezione console
Esempi protezione accesso via telnet
password per l’accesso via telnet (sulle VTY
di default 0...4):
line vty 0 4
login
password Pippo
limitazione in base all’indirizzo del client:
access-list 12 permit 132.5.2.0 0.0.0.255
line vty 0 4
access-class 12 in
Esempio gestione password via TACACS
non-privileged mode:
line console 0
login
password Pippo
attivazione di timeout (default: 10’)
line console 0
exec-timeout 4 30
per disattivare il timeout (sconsigliato!)
line console 0
exec-timeout 0 0
! oppure: no exec-timeout
Esempi sulla gestione delle password
privileged mode:
enable-password SuperPippo
per evitare di mantenere le password in chiaro
nel file di configurazione usare:
service password-encryption
(attenzione: il sistema non è molto forte)
password diverse per ogni utente (0 per lasciarle
in chiaro, 7 per cifrarle):
username lioy password 7 antonio
username rossi password 0 semplice
Protezione da IP spoofing
cosa fare quando il server TACACS non è
raggiungibile?
richiedere una password locale
permettere l’accesso comunque (!)
tacacs-server host 132.5.1.3
tacacs-server last-resort succeed
! oppure: tacacs-server last-resort password
! richiede tacacs per l’autenticazione sulle VTY
line vty 0 4
login tacacs
Internet
per proteggere i
sistemi esterni dai
nostri impostori
per proteggere i
nostri sistemi da
impostori esterni
router
rete 132.5.1
rete 132.5.2
20
(netsec - dic'01)
Esempio protezione da IP spoofing
access-list 101 deny ip
132.5.0.0 0.0.255.255 0.0.0.0 255.255.255.255
interface serial 0
ip access-group 101 in
access-list 102 permit ip
132.5.1.0 0.0.0.255 0.0.0.0 255.255.255.255
interface ethernet 0
Sicurezza di SNMP
pacchetti UDP/161
SNMP (v1, v2, v3):
protezione di default tramite segreto condiviso
trasmesso in chiaro
(stringa di “community”)
nessuna autenticazione dei client
nessuna protezione dei messaggi
access-list 103 permit ip
132.5.2.0 0.0.0.255 0.0.0.0 255.255.255.255
interface ethernet 1
Estensioni sicure di SNMP
RFC-1352
“SNMP security protocols” (his)
RFC-1446
“Security protocols for SNMPv2” (his)
RFC-1910
“User-based security model for SNMP”
digest authentication protocol (richiede
sincronizzazione dei clock)
symmetric privacy protocol
entrambi richiedono chiavi simmetriche
(problema: distribuzione/aggiornamento)
poco usate
Esempio protezione accessi SNMP
access-list 10 permit 132.5.1.1
access-list 10 permit 132.5.1.2
snmp-server community public RO 1
snmp-server community private RW 1
Sicurezza a livello applicativo
completamente indipendente dalla rete
autenticazione basata sull’utente, non sul nodo
di rete
indispensabile per quei canali che attraversano
un firewall
F
W
21

Sicurezza delle reti IP Sicurezza delle reti IP Reti private Classi per

Transcript

Documenti analoghi

Accesso remoto ad impianti domotici Problemi legati alla sicurezza

6x - Politecnico di Torino

3x - Politecnico di Torino

I router e VPN gateway professionali per l`accesso ad Internet ad

Titolo: Configurazione del client TGB (TheGreenBow - Atlantis-Land

Introduzione alle VPN

Aprire le porte (Tcp/Udp) SENZA l`uso del Router

KEYWORD DOMINATION KEYWORD DOMINATION

Depliant Zyxel USG 20

IPSEC SA security association definizione