Archivi tag: masquerading

100 sfumature di NAT

Networking, , , , , ,

Si, avete ragione, il titolo è “leggermente” riciclato, ma se l’ho scelto avrò i miei buoni motivi. Uno su tutti è il fatto che qualunque dispositivo di rete in grado di operare con il NAT implementa una propria logica e lo usa come meglio crede. Vi sembro esagerato? Provate a leggere la continuazione di questo post ed alla fine non potrete che essere d’accordo con me.

 

nat.gif

Cos’è il NAT e perchè viene usato?

L’acronimo NAT sta per Network Address Translation e consente di tradurre un determinato indirizzo IP in un’altro. Tale tecnologia è stata introdotta poichè i classici indirizzi IP pubblici a 32 bit (leggasi IPv4) iniziavano a scarseggiare, ragion per cui si è deciso di fare in modo che i PC di una LAN (con spazio di indirizzamento privato, ovvero 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16) potessero “presentarsi” su Internet utilizzando uno o più indirizzi IP pubblici.

Il NAT è sufficiente?

Bhè, forse il NAT puro è stato sufficiente per i primi tempi, ma dopo un po’ ha cominciato a presentare qualche punto debole, soprattutto quando viene usato per tradurre indirizzi IP privati in pubblici. Infatti, se nella LAN sono presenti N PC con N indirizzi IP privati, sono necessari altrettanti indirizzi IP pubblici (NAT pool) per consentire loro di navigare su Internet contemporaneamente. Che fregatura, vero? Bene, per sopperire a tale limitazione si è scelto di implementare una tecnologia simile al NAT (poichè anche questa effettua una traduzione da privato in pubblico), ma, per certi versi, più performante, ovvero il PAT. Il PAT viene detto anche IP Maquerading (poichè consente di nascodenre l’IP privato dietro l’IP pubblico), NAT Overloading o IP overloading e vi assicuro che ciascun produttore di network device potrebbe utilizzare a piacere uno qualunque di questi appellativi, dunque tenete bene a mente tali sinonimi.

Cos’è il PAT?

Il termine PAT sta per Port Address Translation. A differenza del NAT non effettua una traduzione uno a uno (static NAT) o uno a molti (dynamic NAT, ovvero un indirizzo IP privato può essere mappato su uno degli N indirizzi IP pubblici del pool, a seconda della loro disponibilità) ma è in grado di tradurre più indirizzi IP privati in un unico indirizzo IP pubblico. La logica che segue è molto semplice: per ogni richiesta proveniente da un PC della LAN memorizza non solo l’IP sorgente, ma anche la porta sorgente. Ad esempio:

192.168.3.1:1025

viene tradotto in:

98.53.21.3:1025

dove 98.53.21.3 è l’IP pubblico utilizzato dai PC della LAN per uscire su Internet, mentre 1025 è la porta usata per inizializzare la connessione verso l’esterno.

Queste informazioni vengono inserite e mantenute (per un lasso di tempo variabile ma comunque limitato), all’interno di un’apposita tabella, detta appunto NAT table.

Nell’ambito dei sistemi *nix che fungono da firewall/router è possibile implementare il PAT mediante un semplice comando, ovvero:

#PAT

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Il MASQUERADE finale indica che stiamo utilizzando il PAT (aka IP Masquerading).

Inoltre, stiamo appendendo una regola (-A) alla chain POSTROUTING che fa riferimento alla tabella nat (-t nat).

Il PAT è supportato (ovviamente) anche dai router casalinghi di casa Cisco (in particolare la serie 800).

Per implementarlo è neccessario utilizzare le seguenti direttive:

Router# conf t
Router(config)# int dia0
Router(config-if)# ip nat outside
Router(config-if)# exit
Router(config)# int e0
Router(config-if)# ip nat outside
Router(config)# ip nat inside source list 1 interface Dialer0 overload

Stiamo semplicemente dicendo al router che l’interfaccia e0 è quella “affacciata” alla nostra LAN, mentre l’interfaccia Dia0 (virtuale), è quella a cui è associato il nostro IP pubblico. Con l’ultimo comando, infine, stiamo imponendo la traduzione degli IP della LAN nell’indirizzo pubblico (la keyword overload cosa vi ricorda? IP o NAT overloading, ovvero il PAT).

Quanti tipi di NAT esistono?

La risposta è un po’ lapidaria: molteplici. Infatti, il NAT generalmente viene suddiviso in due macro tipologie: source NAT e destination NAT. Nel primo caso è l’IP privato ad essere tradotto in IP pubblico, nel secondo caso accade il contrario. Il destination NAT viene utilizzato quando volete mettere in ascolto su Internet un PC della vostra LAN (alcuni router casalinghi chiamano tale operazione port forwarding o port mapping, altri ancora la chiamano virtual server).

Vediamo quali sono i comandi per implementare il destination NAT mediante iptables:

iptables -t nat -A PREROUTING -p tcp --dport 4711 -i eth0 -j DNAT --to 10.0.0.4

Come si implementa il destination NAT sui router Cisco serie 800? Semplice, basta usare il seguente comando:

Router(config)#ip nat inside source static tcp <indirizzo locale PC> 22 interface Dialer0 22

In particolare, stiamo nattando l’indirizzo locale del PC su cui è in ascolto un demone SSH sulla porta 22 dell’IP pubblico assegnato alla Dialer0. In soldoni, ciò significa che tutti i tentativi di connessioni provenienti da Internet e diretti al nostro indirizzo IP pubblico sulla porta 22, verranno “inoltrati” al PC della LAN su cui è in ascolto il demone SSH.

Per ragioni di sicurezza, potremmo modificare la porta pubblica su cui metterci in ascolto, utilizzando ad esempio la 2244 (non standard):

Router(config)# ip nat inside source static tcp <indirizzo locale PC> 22 interface Dialer0 2244

Quindi, chiunque si volesse connettere sulla porta 2244 del nostro IP pubblico, verrà “girato” sulla porta 22 del PC locale.

In questo caso parliamo di NAPT (Network And Port Translation).

Infine, è bene notare che abbiamo a che fare con lo static NAT, in quanto all’indirizzo IP pubblico viene associato staticamente l’IP locale del PC che funge da server SSH.

Oltre al source ed al destination NAT esiste anche il cosiddetto double NAT. Esso viene utilizzato nell’ambito delle VPN site-to-site, in grado cioè di interconnettere in modo sicuro due LAN dislocate in punti geografici differenti. Inoltre, affinchè si renda necessario l’uso del double NAT è indispensabile che entrambe le LAN utilizzino lo stesso spazio di indirizzamento privato. Infatti, non è possibile ruotare i pacchetti tra due LAN che usano la medesima classe di indirizzi IP privati, quindi per evitare che si effettui una rimappatura di tali indirizzi si utilizza il double NAT.

Ma il NAT/PAT serve solo per la traduzione di IP privati in pubblici?

No. Il NAT può tornare utile anche quando si vuole consetire ad un PC della LAN di accedere ad un server che sta in DMZ. Infatti, per default, le security appliance rendono impossibile la comunicazione tra la zona Interna e la DMZ, quindi, l’unico modo per riuscire a fare ciò è creare una entry NAT con relativa regola di firewalling.

E’ possibile visualizzare il contenuto delle tabelle NAT?

Certo che si. Per i sistemi *nix occorre installare un pacchetto apposito, ovvero netstat-nat:

nightfly@nightbox:~$ sudo apt-get install netstat-nat

e poi lanciare il comando sudo netstat-nat il cui output sarà simile al seguente:

Proto NATed Address                  Destination Address            State

tcp   nightflyvaio.*.*:8373   mil01s16-in-f23.1e100.ne:https ESTABLISHED
tcp   nightflyvaio.*.*:8440   mil01s17-in-f9.1e100.net:https ESTABLISHED
tcp   nightflyvaio.*.*:6033   78.141.*.*:12350            ESTABLISHED
tcp   nightflyvaio.*.*:8370   muc03s02-in-f17.1e100.ne:https ESTABLISHED
tcp   nightflyvaio.*.*:6349   pop.tiscali.it:imaps           ESTABLISHED
tcp   nightflyvaio.*.*:8372   muc03s02-in-f24.1e100.ne:https ESTABLISHED

Per i router Cisco serie 800, invece, è sufficiente utilizzare il comando:

Router# sh ip nat translations

il cui output sarà simile a:

Pro Inside global         Inside local          Outside local         Outside global

tcp 79.55.117.*:6881    192.168.*.*:6881      ---                   ---
tcp 79.55.117.*:6882    192.168.*.*:6882      ---                   ---
udp 79.55.117.*:52121   192.168.*.*:52121     208.67.222.222:53     208.67.222.222:53
udp 79.55.117.*:30171   192.168.*.*:30171     208.67.220.220:53     208.67.220.220:53
udp 79.55.117.*:58847   192.168.*.*:58847     208.67.220.220:53     208.67.220.220:53
tcp 79.55.117.*:6882    192.168.*.*:6882      151.62.35.107:54700   151.62.35.107:54700

Nei prossimi post (tempo permettendo) parlerò delle tecniche di NAT traversal.

A presto.

Bypassare il firewall della rete aziendale mediante OpenVPN

Sicurezza, , ,

Quanto di seguito, è il racconto di una mattina in ufficio, passata a dare una mano ad un amico. Non vuole essere assolutamente un how-to su OpenVPN, per il quale si trova dell’ottima documentazione su internet, a partire da quella presente sul sito ufficiale.
Poniamo il caso che un giorno un vostro amico vi telefoni e vi dica qualcosa del genere: “Ti prego, aiutami!!! Devo assolutamente entrare su LogmeIn per fare un’assistenza urgente, ma questa rete è completamente chiusa. Non so proprio come fare!!!”.
Ovviamente voi, spinti da irrefrenabile spirito di altruismo, non potrete rimanere indifferenti. L’unico abbozzo di soluzione che vi verrà in mente sarà quello di dirottare il traffico del vostro amico attraverso di voi, visto che, casualmente, avete una macchina Linux proprio lì sulla vostra scrivania.
LogMeIn rappresenta un esempio abbastanza interessante, non permettendo il passaggio attraverso Socks di nessun tipo. Pertanto, per risolvere il problema, la cosa migliore venutaci in mente è quella di bypassare e non utilizzare nessun tipo di proxy.
Armati di santa pazienza e di un buon auricolare, iniziate ad investigare. In primis perché il vostro amico non riesce ad accedere a LogMeIn, oltre che a tutta una serie di altri siti? Poi, quanta intelligenza ha l’attrezzo che gli tarpa le ali?
Rispondere alla prima domanda è piuttosto semplice: c’è un firewall, piuttosto che un proxy, piuttosto che qualche genere di apparato che in base ad una lista o ad un servizio, decide se l’URL che volete visitare è da considerarsi legittima oppure no.
Per quanto riguarda la seconda domanda, la riscrivo in maniera meno criptica: l’apparato che blocca, è un semplice firewall? Si limita a fare firewalling oppure fa anche content inspection? Cioè, se sulla porta 80 faccio viaggiare qualunque altra cosa che non sia HTTP, lui se ne accorge oppure no?
Boh, non rimane che provare. Per fare una prova veloce e “senza impegno” usiamo netcat (grazie di esistere!!):

netcat –l 80

ossia lo mettiamo in listening sulla porta 80 della nostra macchina, pronto ad accettare qualunque connessione da chicchessia. Ovviamente se siete anche voi, a vostra volta, dietro un firewall, dovete fare in modo che questi consenta che voi accettiate connessioni dall’esterno, o con port-forwarding o con un DNAT e relativa policy.
Fatto questo, fate un fischio al vostro amico che sta all’interno della rete protetta e ditegli di fare un bel:

telnet il.vostro.indirizzo.ip 80

Se tutto funziona a dovere, avete realizzato un piccolo tubo, di cui il vostro amico sta ad un’estremità e voi all’estremità opposta. A questo punto ogni carattere che lui inserirà sulla console, voi ve lo vedrete rispuntare dalla vostra parte del tubo. Quello che sta succedendo, ai fini del nostro test, è che l’apparato che sta ai bordi della rete non si accorge che la nostra comunicazione, benché sia sulla porta TCP 80, non è affatto HTTP. Questo ci suggerisce che l’attrezzo non è così cattivo come sembra, ed è disposto a far passare qualunque cosa purché sia sulla porta www e l’IP o il dominio non siano stato inseriti fra i suoi filtri.

 

schema1.png

 

A questo punto siamo pronti a mettere in piedi il resto della baracca: lato nostro installeremo OpenVPN e lo configureremo come server. Il nostro amico (che per ipotesi ha una macchina Windows) dovrà installare la versione client. Non entro nei dettagli di installazione del client che si trovano un po’ ovunque.
Per mettere a punto la configurazione sul server dovremo fare, più o meno tre macro passaggi:

1. abilitare il server sulla porta 80, pronto a ricevere connessioni con una chiave condivisa col nostro amico;

2. abilitare la nostra macchina a fare del routing;

3. nattare la macchina del nostro amico, in modo che sulla rete abbia lo stesso IP della nostra;

In merito al primo punto e all’utilizzo di una chiave condivisa, certo non è il modo migliore e più sicuro di utilizzare OpenVPN. Per una infrastruttura stabile e seria è assolutamente consigliato utilizzare i certificati. Ma questa non è né un’infrastruttura stabile, né tanto meno seria…

 

schema2.png

 

Per prima cosa, genereremo la chiave condivisa:

openvpn --genkey --secret key.txt

Io ho messo questo file nella directory

/etc/openvpn

Adesso configureremo il server OpenVPN:

 dev tun
 secret /etc/openvpn/key.txt
 ping 10
 verb 1
 mute 10
 ifconfig 10.0.1.1 10.0.1.2
 proto tcp-server
 lport 80

Di questa configurazione, ci interessano in particolare questi dettagli:

• dev tun: questo è il tipo di device che intendiamo utilizzare. Le scelte possibili sono tap e tun. Il device tun creerà un device di livello 3, creando delle interfacce punto-punto. Da manuale, è sempre consigliabile utilizzare questo tipo di device, a meno di situazioni in cui sia richiesto l’utilizzo di protocolli particolari o si faccia grande utilizzo di broadcast.
• ifconfig 10.0.1.1 10.0.1.2: queste sono le impostazioni della vostra interfaccia tun. Se date un’occhiata al manuale di OpenVPN, vi renderete conto di come, questa opzione, abbia due significati differenti a seconda che il device sia tun o tap. Nel nostro caso stiamo dicendo al server che la nostra interfaccia avrà indirizzo 10.0.1.1 mentre quella del nostro amico, sulla quale termineremo questo collegamento punto-punto, avrà indirizzo 10.0.1.2
• tcp-server e lport 80: questa sono un po’ il cuore di tutto il nostro discorso, infatti metteno in ascolto il server OpenVPN sulla porta TCP 80, piuttosto che su quella di default, alla stregua, quindi, di qualunque web-server.
La configurazione che dovrete inviare al vostro amico sarà speculare alla vostra, e, soprattutto, avrà la stessa chiave, che dovrete provvedere a passargli.

 remote il.vostro.ip.pubblico
 proto tcp-client
 rport 80
 dev tun
 ifconfig 10.0.1.2 10.0.1.1
 secret key.txt
 route-gateway 10.0.1.1
 redirect-gateway
 ping 10
 verb 1
 mute 10

Anche per questa configurazione, facciamo un paio di considerazioni:
• route-gateway e redirect-gateway: affinché il tutto funzioni, queste opzioni sono fondamentali, in quanto impongono al client di utilizzare come default gateway l’interfaccia tun appena creata. Pertanto, tutto il traffico in uscita dal client, non diretto alla sua sottorete, verrà instradato verso il server OpenVPN. A questo proposito va fatta una sottolineatura: quando si parla di tutto il traffico, si intende TUTTO il traffico, per cui, ad esempio, anche quello DNS. Se quindi, il vostro amico ha impostato come DNS uno interno alla sua rete, visto che passerà per voi, non riuscirà mai a raggiungerlo. Quindi o cambia DNS o potete fare in modo di mandargliene uno voi tramite il push. Per questo vi rimando al manuale.
• proto tcp-client e rport 80: protocollo e porta verso la quale il vostro amico dovrà connettersi.
Non rimane che tirare su il tutto, voi il server ed il vostro amico il client. Se tutto va come
dovrebbe, facendovi dei rispettivi ping dovrete avere delle risposte:

Lato server: ping 10.0.1.2
Lato client: ping 10.0.1.1

Rimangono da completare altri due task lato server: il routing ed il NAT.
Per quanto riguarda il routing, io solitamente faccio così:

echo 1 > /proc/sys/net/ipv4/ip_forward

Questa impostazione trasformerà il vostro computer in un router, permettendo, di fatto, il
fowarding dei pacchetti fra le vostre schede di rete.

Anche per quanto riguarda il nat, o meglio, il MASQUERADE ce la sbrigheremo
facilmente:

iptables -t nat -A POSTROUTING -s 10.0.1.2/32 -o eth0 -j MASQUERADE

Probabilmente, quella messa sopra, è la stringa di iptables più famosa del web, nonché una delle meravigliose “magie” di Linux e IPTABLES. In sostanza fa in modo che tutto il traffico che attraverserà in uscita l’interfaccia eth0 del server (nell’ipotesi che la eth0 sia l’interfaccia utilizzata dal server per connettersi alla LAN) dovrà essere mascherato con l’indirizzo dell’interfaccia stessa.
A questo punto tutta l’infrastruttura dovrebbe essere ok, e non rimane altro che provare. Un traceroute (o tracert su Windows) o un sito come www.myip.dk, potrebbero essere gli strumenti giusti per fare qualche test.
In bocca al lupo.