VoIP and Hacking | Consulenza Documentazione

Il NAT è una pratica comunemente usata per celare la presenza di hosts multipli dietro ad un differente arco di indirizzi IP.
Prima che un pacchetto originato dall’interno lasci il gateway, l’indirizzo sorgente viene riscritto, sostituendolo con un nuovo indirizzo esterno, cioè quello esterno del gateway stesso. Quando gli giunge il pacchetto di ritorno, il gateway sostituisce l’indirizzo di destinazione con quello del primo host prima di inoltrarglielo.

In una Internet ideale, tutti i devices dovrebbero essere in grado di comunicare tra loro senza necessitare di alcun tipo di intermediario ad eccezione dei routers. Cio’ implicherebbe che ciascun device possegga un indirizzo IP pubblico verso cui instradare l’opportuno traffico.
Nella realtà la maggior parte dei devices appartenenti ad una stessa LAN e connessi a Internet fanno uso della funzione di NAT presente nel router perimetrale.

Il NAT offre sia vantaggi che svantaggi:
Utilizzando il NAT diventa possibile infatti connettere ad Internet devices multipli utilizzando un solo indirizzo IP pubblico (in caso contrario gli indirizzi disponibili previsti dal protocollo IP versione 4 sarebbero da gran tempo esauriti).
Dato che tuttavia, in linea generale, esso impedisce ai nodi Internet esterni di iniziare connessioni nei confronti di quelli mascherati dal NAT, e questo è anche un bene in termini di sicurezza, nondimeno rappresenta un fattore negativo per la telefonia IP (ed in generale per altre forme di comunicazioni peer-to-peer).
Il NAT (Network Address Translation) costituisce infatti uno dei maggiori ostacoli per le comunicazioni VoIP basate su SIP (e su protocolli associati, come RTP).
Il problema viene ulteriormente complicato a causa della varietà di NATs esistenti ed anche a causa dell’ampio numero di possibili scenari operativi ed architetturali.

Possibili tipologie di NAT

Come anticipato, parte del problema inerente il NAT con VoIP risiede nelle diverse possibili tipologie di NAT, ciascuna richiedente un diverso approccio.

Vediamo quali sono queste tipologie:

# NAT di tipo Full Cone (Full Cone NAT), conosciuto anche come NAT “one-to-one”.
Una volta che un indirizzo interno (iX:iP) sia stato mappato ad un indirizzo esterno (eX:eP), ogni pacchetto originato da iX:iP verrà inviato attraverso eX:eP.
Qualsiasi host esterno può inviare dei pacchetti a iX:iP destinandoli a eX:eP.
Un NAT Full Cone mappa quindi le sessioni attive su di una coppia indirizzo interno/porta su una specifica coppia indirizzo esterno/porta. Tali sessioni possono venire iniziate sia da hosts interni che esterni.

# NAT di tipo Restricted Cone o (Address) Restricted Cone NAT
Una volta che un indirizzo interno (iX:iP) sia stato mappato ad un indirizzo esterno (eX:eP), ogni pacchetto originato da iX:iP verrà inviato attraverso eX:eP.
Un host esterno (hX:any), dove “any” sta per un numero di porta qualsiasi, può inviare pacchetti a iX:iP destinandoli a eX:eP solo se iX:iP abbia in precedenza inviato un pacchetto a hX:any.
Differentemente dal NAT di tipo full cone, un host esterno (con un dato indirizzo IP) può inviare un pacchetto all’host interno solamente nel caso in cui l’host interno abbia precedentemente inviato un pacchetto a quello stesso indirizzo IP (il numero di porta non ha importanza).
Di conseguenza, solamente hosts interni possono iniziare una sessione attraverso un NAT di tipo Restricted Cone.

# NAT di tipo Port Restricted Cone o Port-restricted cone NAT:
Un NAT di tipo Port Restricted Cone è simile a quello precedente, ma la restrizione è estesa ai numeri di porta.
Una volta che un indirizzo interno (iX:iP) sia stato mappato ad un indirizzo esterno (eX:eP), ogni pacchetto originato da iX:iP verrà inviato attraverso eX:eP.
Al contrario, un host esterno, con indirizzo di origine hX:hP, può inviare un pacchetto all’ host interno solamente nel caso in cui l’ host interno abbia già precedentemente inviato un pacchetto all’indirizzo hX:hP. In altri termini ancora, i pacchetti provenienti da hosts esterni devono contenere come indirizzo IP sorgente e numero di porta una coppia precedentemente utilizzata da un host interno.

# NAT di tipo simmetrico:
UN NAT di tipo simmetrico, chiamato anche NAT “stateful inspection” è quello dove tutte le richieste provenienti da un host con un certo indirizzo IP interno e una certa porta (iX:iP), vengono mappate su una unica specifica porta del corrispondente indirizzo IP esterno (eX:eP). Se lo stesso host invia un pacchetto con la stessa accoppiata indirizzo sorgente/porta, ma ad una differente destinazione, viene utilizzata una differente mappatura. Viene cioè assegnata una porta esterna univoca ad ogni sessione che un host interno inizia con un host esterno.

Tutta la terminologia appena esaminata ha dato origine a parecchia confusione, ed è di fatto inadeguata a descrivere l’utilizzo del NAT nella pratica reale. Molte implementazioni reali di NAT combinano queste tipologie, e pertanto risulta preferibile fare riferimento alle specifiche individuali caratteristiche di un device che effettui NAT anziche riferirsi alle rigide tpologie viste in precedenza. Nello specifico, la maggior parte dei devices che effettuano attualmente il NAT combinano il Symmetric NAT per connessioni in uscita con un port mapping statico, dove i pacchett in arrivo su eX:eP vengono rediretti ad una specifica coppia iX:iP. Alcuni prodotti sono in grado di reindirizzare i pacchetti a diversi hosts interni, ad esempio per suddividere il carico tra più server (load balancing). Questo schema tuttavia introduce problemi coi tipi di comunicazione più sofisticati, e perciò viene usato raramente.

Molte implementazioni NAT seguono il principio della “port preservation”. Per la maggior parte delle comunicazioni, essi usano gli stessi valori per indicare numeri di porta interni ed esterni.
Comunque, se due hosts interni tentassero di comunicare con lo stesso host esterno usando lo stesso numero di porta, il numero della porta esterna usato dal secondo host verrebbe scelto a caso, per assicurare che la connession possa venire identificata univocamente dal gateway. Tale NAT verrà talvolta rilevato come (Address) Restricted Cone NAT e talvolta come Symmetric NAT.
Questo ultimo scenario viene anche chiamato Port Address Translation (PAT), o IP masquerading.

Il NAT, come già anticipato, non opera in genere amichevolmente col VoIP, presentando spesso problemi. La soluzione di questi problemi richiede la comprensione del NAT, del VoIP e del setup di quest’ultimo.

Il Session Initiation Protocol (SIP) che controlla le communicazioni VoIP risente di questi problemi. SIP può fare uso di porte multiple per effettuare il set up di una connessione e trasmettere flussi voce tramite RTP. Indirizzi IP e numeri di porta sono codificati nel payload dati e pertanto devono essere conosciuti prima del NAT traversal. Senza speciali tecniche, come STUN, il comportamento del NAT risulterebbe inprevedibile e le comunicazioni potrebbero fallire.

Un problema con VoIP e NAT consiste nella necessità che entrambi i punti terminali di una conversazione siano in grado di iniziare una connessione con l’altro.
Consideriamo la semplificata sequenza di eventi che si verifica ogniqualvolta PhoneA chiama PhoneB coinvolgendo i rispettivi SIP servers, PBXA e PBXB.

1. PBXA invia un SIP INVITE a PBXB per conto di PhoneA. In tale messaggio, l’indirizzo IP è quello di PhoneA.
2. PBXB invita PhoneB alla conversazione specificando l’indirizzo IP di PhoneA come l’altra terminazione.
3. Se PhoneB accetta la chiamata, PBXB risponde a PBXA con una ricevuta che contiene l’indirizzo IP di PhoneB.
4. PBXA lo riferisce a PhoneA.
5. PhoneA invia il proprio audio a PhoneB utilizzando il Real-Time Protocol (RTP).
6. PhoneB invia il proprio audio a PhoneA utilizzando il Real-Time Protocol (RTP).

Il NAT può causare l’insorgenza di problemi in diversi punti di questo flusso. Se uno dei PBXs si trovasse dietro ad un NAT gateway, l’altro PBX non sarebbe in grado di contattarlo senza alcune impostazioni supplementari. Se uno o più phones si trovassero dietro ad un NAT gateway, l’altro phone cercherebbe di inviare il proprio audio ad un indirizzo non instradabile. Ciò si risolverebbe in una chiamata fallita o in assenza di audio.

Asterisk si svincola dalla chiamata al passo 4 in seguito a un re-invite o a un native bridge. I passi elencati in precedenza mostrano che il phone parla col proprio PBX locale, che a sua volta parla col PBX remoto. Il PBX locale quindi fa in modo che le due estremità della chiamata puntino direttamete tra loro, in modo che il phone locale comunichi direttamente con la controparte, lasciando il SIP server fuori dalla conversazione.

L’ alternativa ad un re-invite consiste nel lasciare che sia il PBX a inoltrare i pacchetti voce tra i punti terminali.

Uno scenario molto comune si verifica quando un SIP client che si trova dietro ad un NAT gateway si connette ad un server in Internet. Il client determina la mappatura per il traffico  SIP quando si registra la prima volta. Quanto più a lungo sussiste una comunicazione frequente tra i due hosts, come un pacchetto per minuto, il canale rimarrà aperto. L’unica configurazione necessaria consiste nel fare in modo che il client usi il proprio indirizzo esterno in tutti i pacchetti SDP. Su clients che lo supportano, occorre abilitare STUN (Simple Traversal of UDP through NAT), in modo che il client possa determinare l’indirizzo esterno dinamicamente, altrimenti occorre introdurlo manualmente.

Asterisk da parte sua non possiede ancora attualmente un supporto a STUN affidabile, pertanto tutta la configurazione NAT deve essere impostata manualmente. I comandi seguenti impostano il NAT correttamente in /etc/asterisk/sip.conf:

[general]
localnet=192.168.0.0/255.255.0.0 ; propria subnet
externip=x.x.x.x                 ; proprio indirizzo esterno

[peer_remoto]                    ; nome peer
nat=yes
qualify=yes                      ; Forza invio keepalives

Con questa configurazione Asterisk utilizza l’indirizzo definito da externip per tutte le chiamate ai peers configurati con nat=yes. La presenza di qualify=yes costringe Asterisk a testare la connessione frequentemente cosicché i mappaggi nat non vengano rimossi dal firewall. Con questi due comandi, vi sarà sempre un canale di comunicazione tra Asterisk ed il peer, ed Asterisk userà l’inirizzo esterno inviando messaggi SDP.

Con molteplici phones ed un Asterisk server dietro ad un NAT gateway, la soluzione diviene più complessa. Le chiamate tra i vari phones funzionerebbero bene, dato che non viene richiesto alcun NAT. Per le chiamate con altri sistemi su Internet tuttavia, si presenterbbero dei problemi. A meno di non registrarsi sul nodo opposto come client (o viceversa registrare il nodo opposto come client), non si sarebbe in grado di ricevere i messaggi SIP, pertanto non sarebbe possibile ricevere chiamate. Secondariamente, l’ indirizzo indicato nel call setup punterebbero all’indirizzo interno del phone, e si verificherebbe il caso di audio monodirezionale.

Sicuramente la soluzione più comoda sarebbe quella di evitare totalmente il NAT, nel senso di utilizzare un indirizzo IP pubblico per il proprio server Asterisk, avendolo a disposizione ovviamente. Se il server Asterisk si trovasse contemporaneamente connesso sia ad Internet che alla rete interna, la porta SIP risulterebbe raggiungibile sia dall’interno che dall’esterno, e l’unico problema resterebbe assicurarsi che RTP fluisca correttamente. Il PBX server non avrebbe bisogno di essere configurato per il routing tra interfacce o per fornire il masquerading; avrebbe solamente il compito di attuare un bridge fra chiamate vocali inbound ed outbound.

Come già anticipato, il PBX può sia rimanere nella “voice path” che tirarsene fuori. Nell’ultimo caso, il PBX fornisce a entrambi gli endpoints tutte le informazioni necessarie a contattare la controparte, dopodiché gli endpoints possono dialogare direttamente. Tuttavia, Asterisk potrebbe mantenere un ruolo di call setup con entrambi gli endpoints e inoltrare ad ognuno di essi i pacchetti RTP per conto dell’altro. L’host interno potrebbe dialogare con l’indirizzo interno, e l’host esterno con l’indizzo esterno. L’unixa configurazione richiesta per ottenere ciò consisterebbe nel disabilitare i re-invite in sip.conf:

[general]
canreinvite=no

o secondo una forma più cosona alle alle versioni più recenti di Asterisk:

mediadirect=no

Questa configurazione è in grado di operare bene dato che il server Asterisk pùò comunicare liberamente con Internet per originare e ricevere chiamate. Esso può anche dialogare con i phones interni, e con una semplice forma di bridging, ignorare completamente il NAT.

Com è logico questo comportamento è richiesto anche quando il server Asterisk dispone solamente di un indirizzo privato. Le porte RTP dovranno essere permesse a livello di filtraggio. RTP sceglie dei numeri di porta casuali basati su limiti impostati in sede di configurazione. Prima di configurare le porte, esse dovrebbero venire limitate nel range dei possibili valori. Configurare delle regole di firewall diviene più semplice se il range delle porte interessate è noto a priori.

Il range delle porte da utilizzare per RTP è definito in rtp.conf.
La configurazione seguente limiterebbe la scelta delle porte RTP usate da Asterisk a quelle comprese tra 15000 to 15200:

[general]
rtpstart=15000 ; prima porta da usare
rtpend=15200   ; ultima porta da usare (arrotondata per eccesso se dispari)

Asterisk necessita di diverse porte RTP per operare correttamente. Solo le porte pari vengono attualmente usate, e la disabilitazione dei re-invite provoca la generazione di due connessioni per ciascuna chiamata. Tali porte più la porta SIP dovrebbero essere inoltrate internamente dal firewall, la cui sintassi iptables, se fosse basato su Linux sarebbe:

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 15000:15200 -j DNAT --to-destination 172.16.1.100
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 5060 -j DNAT --to-destination 172.16.1.100

Dove eth0 rappresenta l’interfaccia esterna del firewall e 172.16.1.100 l’indirizzo del server Asterisk.
In pratica queste regole richiedono al kernel Linux di modificare l’indirizzo di destinazione di ogni pacchetto UDP compreso nel range specificato e che entri attraverso l’interfaccia esterna in quello del server Asterisk. Questo deve avvenire nella fase di PREROUTING. A questo punto, qualsiasi pacchetto SIP o RTP proveniente da Internet verrebbe inoltrato al server interno Asterisk per l’elaborazione.

Riassumendo, quando una postazione remota facesse una chiamata ad Asterisk per dialogare con una postazione locale, il pacchetto SIP verrebbe inoltrato a causa delle regole di iptables. Asterisk rimarrebbe nel flusso vocale a causa dell’impostazione canreinvite=no, ed esso farebbe uso dell’indirizzo esterno del firewall in ogni pacchetto SDP a causa dell’impostazione del NAT. Per finire, il flusso audio verrebbe inoltrato al server Asterisk in virtù della combinazioni a causa del reindirizzamento RTP di iptables RTP e del range di porte definito in rtp.conf.

Send post as PDF to