NAT e Firewall traversal
NAT: Network Address Translation

Motivazione: la rete locale usa un solo IP per comunicare con
l’esterno:

non è più necessario richiedere un IP per ogni host
collegato

posso cambiare gli indirizzi interni senza che il mondo
esterno ne risenta

posso cambiare ISP senza dover cambiare gli IP di
tutte le macchine

è una prima forma di firewalling: i dispositivi interni
non sono direttamente raggiungibili (192.168.0.1
Network Layer
oppure 10.0.0.1 non sono
indirizzi validi all’esterno). 4-2
NAT: Network Address Translation
2: Il router NAT
cambia i datagrammi
uscenti da
10.0.0.1, 3345 a
138.76.29.7, 5001,
e aggiorna la tabella
NAT translation table
WAN side addr
LAN side addr
1: l’host 10.0.0.1
manda datagramma a
128.119.40.186, 80
138.76.29.7, 5001 10.0.0.1, 3345
……
……
S: 10.0.0.1, 3345
D: 128.119.40.186, 80
10.0.0.1
1
2
S: 138.76.29.7, 5001
D: 128.119.40.186, 80
138.76.29.7
S: 128.119.40.186, 80
D: 138.76.29.7, 5001
3: Arriva risposta
destinata a:
138.76.29.7, 5001
3
10.0.0.4
S: 128.119.40.186, 80
D: 10.0.0.1, 3345
10.0.0.2
4
10.0.0.3
4: Il router NAT cambia
l’indirizzo e porta di destinazione
138.76.29.7, 5001 to 10.0.0.1, 3345
Network Layer
4-3
NAT: Network Address Translation
Implementazione: Un router NAT deve:

datagrammi uscenti: cambiare IP sorgente, numero di porta
con (Indirizzo router NAT, nuovo num. di porta)
i client remoti rispondono credendo di avere a che fare con
una connessione aperta su
(Indirizzo router NAT, nuovo num. di porta)

ricordare (in una tabella speciale detta NAT translation table)
ogni coppia (indirizzo interno, porta) <->(nuova porta)

datagrammi entranti: cambiare
(Indirizzo router NAT, nuova porta) nei campi destinazione in
base alla tabella di traduzione
Network Layer
4-4
NAT: Network Address Translation

Non più di 16 bit per indicare il num di porta:


Tutta la sottorete può avere al più 60000 porte
simultanee
Contraddizioni e incongruenze:



I router non dovrebbero alterare i protocolli di livello
4 (trasporto)
I P2P soffrono. In generale ci può essere un solo
server su ogni porta (e.g. un solo server web su
porta 80, ecc.)
Risolve temporaneamente il problema dei pochi
indirizzi
Network Layer
4-5
Port Forwarding
4: Il router NAT
cambia i datagrammi
uscenti da
10.0.0.1, 80 a
138.76.29.7, 80
NAT forwarding table
WAN side addr
LAN side addr
3: l’host 10.0.0.1
manda datagramma a
128.119.40.186, 501
138.76.29.7, 80 10.0.0.1, 80
……
……
S: 10.0.0.1, 80
D: 128.119.40.186,501
10.0.0.1
3
4
S: 138.76.29.7, 80
D: 128.119.40.186, 501
138.76.29.7
S: 128.119.40.186, 501
D: 138.76.29.7, 80
1: Arriva richiesta
destinata a:
138.76.29.7, 80
10.0.0.4
S: 128.119.40.186, 501
D: 10.0.0.1, 80
10.0.0.2
2
1
2: Il router NAT cambia
l’INDIRIZZO di destinazione
138.76.29.7 a 10.0.0.1
Questa tabella è fissata manualmente. Il server interno deve avere IP FISSATO.
10.0.0.3
NAT e altri protocolli di trasporto
NAT e ICMP

Non è possibile basarsi sul numero di porta, si
usa il campo “ident” proprio dei messaggi ICMP
NAT e GRE

Un solo tunnel GRE nei router più semplici
iptables –A FORWARD –p 47 –j ACCEPT
iptables –A FORWARD –i eth0 –p tcp –-dport 1723 –m state –state ESTABLISHED,
RELATED –j ACCEPT
iptables –FORWARD –o eth1 –p tcp –-sport 1723 –m state –state ESTABLISHED,
RELATED–j ACCEPT
NAT e connessioni P2P

Considerate due peer, Alice e Bob

Alice e Bob fuori NAT (con IP pubblico):


Alice e Bob dentro NAT (senza IP pubblico o Port
Forwarding):


Possono aprire liberamente connessioni reciproche
I due non possono aprire una mutua connessione TCP,
né dialogare direttamente via UDP
Alice dentro NAT, Bob fuori NAT

Alice può aprire connessioni verso Bob, non viceversa
(ma Bob può usare il “callback” via server)
Network Layer
4-8
Come Skype & Co. Riescono ad
aggirare un firewall/router NAT?
Firewall


Per assicurare protezione dalle possibili
minacce delle rete i computers vengono in
genere posizionati dietro un firewall, la cui
funzione è tipicamente svolta da un router
Questo implica che non è possibile per un
malintenzionato indirizzare un PC direttamente
dall'esterno (le connessioni devono essere
instaurate dall'interno)
Un Firewall è un problema…

Quando 2 computers (dietro firewalls NAT)
devono comunicare direttamente tra di loro

Ad esempio se i rispettivi utenti vogliono chiamarsi
usando software VoIP


chiunque tra le due parti avvii una chiamata, il firewall del
destinatario
bloccherà
l‘apparente
attacco
semplicemente ignorando i pacchetti di dati
Almeno questo è quanto un amministratore di rete si
aspetterebbe...
Firewall hole punching


In realtà sappiamo che Skype funziona anche
dietro un firewall NAT, così come se fosse
direttamente connesso ad internet
Il motivo è che questi tipi di software hanno
escogitato una soluzione per il problema..
Osservazioni

Un firewall deve normalmente far si che i pacchetti possano
attraversare la rete locale


Un firewall deve inoltrare i dati provenienti dall'esterno su una
workstation nella LAN


gli utenti devono poter visitare siti web, usare la posta etc..
fa questo solo se ha la certezza che un pacchetto è la risposta ad un
pacchetto di dati in uscita
Un router firewall/NAT mantiene informazioni su quali macchine
interne hanno comunicato con quale computer esterno e su
quali porte (connection tracking)
The trick


Il trucchetto usato dal software VoIP consiste nel
“convincere” il firewall che è stata stabilita una
connessione alla quale dovrebbe associare i
successivi pacchetti in ingresso
Il fatto che dati audio per VoIP siano inviati usando il
protocollo UDP (che non è orientato alla connessione)
costituisce un vantaggio per software come Skype

con UDP un firewall vede solo indirizzi e porte
sorgente/destinazione e se per un pacchetto UDP in
ingresso corrisponde una entry della tabella NAT, il
pacchetto viene inoltrato sul computer interno
Switching


Lo switching server, con cui ambo le parti sono in
costante contatto, gioca un ruolo rilevante
nell'instaurare una connessione tramite Skype

Ciò avviene tramite una connessione TCP che gli stessi
clients stabiliscono

Il server Skype perciò sa sempre sotto quale indirizzo un
utente Skype è in quel momento disponibile su internet
Ove possibile le connessioni telefoniche non vengono
effettuate tramite il server Skype (o tramite altri peer)
ma piuttosto i clients si scambiano i dati direttamente
Esempio

Alice vuole chiamare Bob

Il suo client Skype lo comunica al server Skype

Il server Skype conosce già qualcosa di Alice


Dalla richiesta in ingresso vede che Alice è registrata con
l'indirizzo IP 1.1.1.1 e un controllo rivela che i suoi dati audio
provengono sempre dalla porta UDP 1414
Il server Skype passa questa informazione al client
Skype di Bob

che in accordo al suo database, è registrato con l'indirizzo IP
2.2.2.2 e che utilizza la porta UDP 2828
Passo 1: Alice (visibile in rete con IP 1.1.1.1) vorrebbe chiamare Bob.
Bob viene notificato di questo tramite lo Skype Server
Step 2: Bob cerca di contattare Alice su IP e porta noti. Il
router/firewall di Bob consente questo marcando il datagramma
uscente come NEW. Successive risposte di Alice saranno
marcate come ESTABLISHED (legate al primo datagramma di
Bob)
Esempio


Il programma Skype di Bob a questo punto crea un
buco nel firewall della sua rete dovuto all’invio di un
pacchetto UDP all’indirizzo 1.1.1.1 sulla porta 1414
Quest’ultimo viene scartato dal firewall di Alice,
all’insaputa del firewall di Bob

a questo punto il firewall di Bob pensa che quel che proviene
dall’indirizzo 1.1.1.1 sulla porta 1414 ed è indirizzato a Bob
(indirizzo 2.2.2.2 e porta 2828) è legittimo (cioè deve essere
una risposta correlata alla conversazione iniziata da Bob)
Esempio


A questo punto il server Skype passa le
coordinate di Bob ad Alice, il cui programma
Skype cercherà di contattare Bob all'indirizzo
2.2.2.2:2828
Il firewall di Bob associa i datagrammi di Alice
ad una conversazione nota ed iniziata da Bob,
e invia la risposta sul PC di Bob (il cui telefono
Skype squilla)
Step 3: Alice finally reaches Bobs computer through the hole.
Nota

Questa descrizione semplificata dipende dalle
caratteristiche specifiche del firewall usato e
corrisponde al comportamento che si registra
durante il setup di una connessione tra due
clients Skype, ciascuno dietro un firewall Linux
(firewalls NAT per una LAN che consentono
traffico in uscita di tipo UDP)
Linux NAT

Le funzioni di Linux NAT hanno la proprietà VoIP friendly di non
modificare, almeno inizialmente, le porte dei pacchetti in uscita


Il router NAT semplicemente rimpiazza l'indirizzo IP locale con il proprio
indirizzo, mentre la porta sorgente UDP selezionata da Skype viene
mantenuta
Solo se più clients sulla rete locale usano la stessa porta
sorgente allora il router NAT resetta il valore della porta ad uno
non utilizzato in precedenza

ogni assegnamento di indirizzi IP e porte deve poter essere assegnato
attribuito in modo non ambiguo ad una connessione tra due computer

Il router deve ricostruire in seguito l'indirizzo IP interno del mittente
originario dalla porta di destinazione della risposta
Altri routers NAT

Altri routers NAT cercano di assegnare le porte
in un range di valori specifici


ad esempio si usano porte da 30.000 in poi e
trasformano la porta UDP 1414, se possibile, sulla
31414
Questo tuttavia non è un problema per Skype

La procedura descritta continua a funzionare senza
limitazioni, purchè sia possibile ricostruire dal valore
di porta di Alice il valore di porta sostituito dal suo
router.
Complicazione

Diventa più complesso se un firewall semplicemente
assegna le porte in sequenza

Check Point's FireWall-1: la prima connessione è asseganta
a 30001, poi 30002, etc.

Il server Skype è in grado di sapere che Bob sta parlando
con lui dalla porta 31234, ma la connessione con Alice verrà
effettuata tramite una porta diversa
NAT Testing
Come un router NAT commerciale rialloca le
porte?

http://nattest.net.in.tum.de/?mod=publications
Complicazione

Ma anche in questo caso Skype è in grado di superare
il firewall
1.
Tentando di attraversare tutte le porte sopra la 31234 in
sequenza, nella speranza di trovare quella giusta
2.
Se la prima strada fallisce, il programma Skype di Bob può
aprire una nuova connessione con il server Skype, la porta
sorgente del quale viene usata per una ulteriore sequenza
di probes
Skype can do port scans. Here it suceeds on port 38901 and
connects through the firewall.
Problema: necessità di predire i
due numeri di porta





Tuttavia, in una rete attiva Alice potrebbe non trovare
la giusta porta aperta
Lo stesso si verifica per un particolare tipo di firewall,
che assegna ogni nuova connessione a una porta
sorgente casuale
In questi casi il server Skype non è in grado di dire ad
Alice dove individuare un buco nel firewall di Bob
In questi casi un server Skype (o un cosiddetto superpeer) è usato come un relay
https://secure.wikimedia.org/wikipedia/en/wiki/Network
_address_translation
Server Skype come relay

Accetta le connessioni entranti sia da Alice che da
Bob e trasmette i pacchetti progressivamente

Questa soluzione è fattibile a patto che il firewall consenta
traffico UDP in uscita

Implica tuttavia un carico aggiuntivo sulla infrastruttura
perchè tutti i dati audio devono essere gestiti dai server di
Skype

Il tempo di trasmissione inoltre può anche provocare uno
sgradevole ritardo
UDP hole punching

Questo tipo di procedura non è limitata a Skype
ed è nota sotto il nome di "UDP hole punching“

Altri servizi di rete come l’applicazione VPN Hamachi
gaming, che si basa sulla comunicazione peer-to-peer tra
computers dietro firewalls usa procedure simili

RFC 3489 "Simple Traversal of UDP through NAT" (STUN)
descrive un protocollo che con 2 STUN clients può aggirare
le restrizioni di NAT con l’aiuto di un server STUN
DIY hole punching

Per provare UDP hole punching:

hping3 + netcat (Linux)

Local è un computer dietro un firewall Linux (local-
fw) con un firewall stateful che consente solo
connessioni in uscita UDP

Per semplicità, nel nostro esperimento il computer
di prova remote è direttamente connesso a internet
DIY hole punching

Avviare il listener UDP sulla porta UDP 14141 sulla
console local/1 dietro il firewall:
local/1# nc -u –l 14141 oppure
local/1# nc -u –l -p 14141

Un computer esterno remote tenta di contattarlo:
remote# echo "hello" | nc -p 53 -u local-fw 14141


Ovviamente nulla viene ricevuto su local/1 e, grazie al firewall,
nulla viene restituito a remote.
Ora su una seconda console, local/2, hping3 crea un buco nel
firewall:
local/2# hping3 -c 1 --udp -s 14141 -p 53 remote
DIY hole punching

Finchè remote non riuscirà ad effettuare il comando
nc, riceverà una risposta di "port unreachable" tramite
ICMP. Ma al secondo tentativo:
remote# echo "hello" | nc -p 53 -u local-fw 14141

Il listener netcat sulla console local/1 sputa un
"hello" (il pacchetto UDP che dall’esterno ha
attraversato il firewall ed è arrivato al calcolatore dietro
di esso)
DIY hole punching

Amministratori di rete che non gradissero
questo tipo di comportamento nei loro firewall o
preoccupati per eventuali abusi hanno una
unica opzione: bloccare il traffico UDP in uscita
o limitarlo a casi specifici

UDP non è essenziale per il normale traffico
internet (web, e-mail usano TCP, ma non DNS)

Streaming protocols (voIP, etc.) potrebbero avere
problemi perche utilizzano UDP

Resta possibile fare hole punching via TCP…
Sorpresa!





hole punching funziona anche con TCP
Dopo un pacchetto in uscita di tipo SYN il firewall o router NAT
inoltrerà i pacchetti in ingresso con gli opportuni indirizzi IP e
porte verso la LAN anche se non confermano, o confermano un
numero di sequenza errato (ACK).
I firewalls Linux non riescono a valutare questa informazione in
modo consistente
Instaurare una connessione TCP non è così semplice, perché
Alice non ha il numero di sequenza inviato nel primo pacchetto
di Bob
Il pacchetto contenente questa informazione è stato scartato
dal suo firewall