studio ed analisi della sicurezza dei servizi voice over ip

Transcript

Università degli studi di Roma
“La Sapienza”
Facoltà di Ingegneria
Corso di Laurea in Ingegneria delle Telecomunicazioni
STUDIO ED ANALISI DELLA
SICUREZZA DEI SERVIZI VOICE
OVER IP CON SIP E RTP
Relatore
Candidato
Chiar.mo prof. Marco Listanti
Matteo Mogno
Co-relatore
Emilio Tonelli
Anno accademico 2003/2004
Alla mia famiglia
ed ai miei amici
Desidero ringraziare il Prof. Marco Listanti per avermi dato l’opportunità di
svolgere il presente lavoro di tesi al fianco di persone che mi hanno dato
molto sia dal punto professionale, sia da quello umano.
Ringrazio tutto il gruppo CONSEL per i bei momenti passati insieme, per i consigli
e l’aiuto che ognuno mi ha dato.
Inoltre ringrazio “la struttura” Telecom Italia, ed in particolare la funzione
IT Security di IT Telecom per aver messo a disposizione gli strumenti
tecnici per la realizzazione del presente lavoro.
Infine, un ringraziamento particolare ad Alessandro e Sebastiano per
l’aiuto ed il sostegno ricevuto.
INDICE
1 Introduzione ....................................................................... 1
1.1
Stato dell’arte ....................................................................................2
1.2
Struttura della tesi..............................................................................3
2 Visione d’insieme del Voice over IP .................................... 5
2.1
Voice over IP (VoIP) ...........................................................................5
2.1.1
2.2
Architettura del VoIP ...........................................................................................5
Session Initiation Protocol (SIP)...........................................................7
2.2.1
Architettura del SIP .............................................................................................8
2.2.2
Messaggi SIP ....................................................................................................10
2.2.3
Funzionalità del SIP ...........................................................................................13
2.2.3.1
Risoluzione degli indirizzi ............................................................................13
2.2.3.2
Funzioni legate alle chiamate ......................................................................15
2.2.3.3
Funzioni non legate alle chiamate ...............................................................15
2.3
Session Description Protocol (SDP) .................................................... 16
2.4
Real-Time Transfer Protocol (RTP)..................................................... 17
3 Aspetti di sicurezza nel Voice over IP ............................... 20
3.1
Vulnerabilità del VoIP ....................................................................... 21
3.2
Attacchi ad un’architettura VoIP ........................................................ 24
3.2.1
Confidenzialità...................................................................................................25
3.2.1.1
Switch Default Password Vulnerability .........................................................25
3.2.1.2
Classical Wiretap Vulnerability.....................................................................25
3.2.1.3
ARP Cache Poisoning e ARP Floods .............................................................25
3.2.1.4
Web Server Interfaces ...............................................................................26
3.2.1.5
IP Phone Netmask Vulnerability ..................................................................26
3.2.2
Integrità ...........................................................................................................26
3.2.2.1
DHCP Server Insertion Attack .....................................................................27
3.2.2.2
TFTP Server Insertion Attack ......................................................................27
3.2.3
Disponibilità e Negazione del Servizio ..................................................................27
3.2.3.1
CPU Resource Consumption Attack..............................................................28
3.2.3.2
Default Password Vulnerability ....................................................................28
3.2.3.3
Exploitable software flaws ..........................................................................29
3.2.3.4
Account Lockout Vulnerability .....................................................................29
i
Studio ed Analisi della Sicurezza dei Servizi Voice over IP con SIP e RTP
Indice
4 Vulnerabilità di SIP e RTP ................................................. 30
4.1
SIP ................................................................................................. 30
4.1.1
Hijacking ..........................................................................................................30
4.1.1.1
Registration Hijacking ................................................................................30
4.1.1.2
3XX Response code messages ....................................................................32
4.1.2
Man in the Middle..............................................................................................33
4.1.2.1
Impersonating a server: Proxy server ..........................................................33
4.1.2.2
302 Response code message ......................................................................36
4.1.2.3
305 Response code message ......................................................................37
4.1.2.4
Impersonating a server: Registrar server .....................................................39
4.1.3
Denial of Service ...............................................................................................40
4.1.3.1
Tearing down a session..............................................................................40
4.1.3.2
Modifying a session....................................................................................41
4.1.3.3
Cancelling a session...................................................................................43
4.1.3.4
SIP DoS attack and amplification.................................................................44
4.1.3.5
Response code messages ...........................................................................45
4.1.3.6
Toll Fraud .................................................................................................46
4.2
RTP................................................................................................. 47
4.2.1
Man in the Middle..............................................................................................47
4.2.1.1
4.2.2
Modifying IP address..................................................................................47
Denial of Service ...............................................................................................49
4.2.2.1
Fase di lancio ............................................................................................49
4.2.2.2
Malicious payload format............................................................................50
4.2.2.3
RTCP timing rules incorrectly ......................................................................51
4.2.2.4
Change Synchronization Source fileld ..........................................................53
4.2.2.5
BYE attack ................................................................................................55
4.2.2.6
Sequence Number and Timestamp higher....................................................55
4.2.2.7
Injecting malicious Reception Reports (RR)..................................................56
4.3
Implementazione degli attacchi ......................................................... 58
4.3.1
Man in the Middle in VoIP ..................................................................................58
4.3.1.1
Architettura...............................................................................................58
4.3.1.2
Strumenti..................................................................................................59
4.3.1.3
Risultati ....................................................................................................59
4.3.2
Tearing down a session......................................................................................61
4.3.2.1
Architettura...............................................................................................61
4.3.2.2
Strumenti..................................................................................................62
4.3.2.3
Risultati ....................................................................................................62
4.3.3
Cancelling a session...........................................................................................64
ii
Indice
4.3.3.1
Architettura...............................................................................................64
4.3.3.2
Strumenti..................................................................................................64
4.3.3.3
Risultati ....................................................................................................64
4.3.4
Modifying a session ...........................................................................................65
4.3.4.1
Architettura...............................................................................................65
4.3.4.2
Strumenti..................................................................................................65
4.3.4.3
Risultati ....................................................................................................67
5 Attraversamento di NAT e Firewall ................................... 68
5.1
Introduzione al NAT e Firewall........................................................... 68
5.1.1
Introduzione ai Firewall......................................................................................68
5.1.1.1
Packet Filtering Gateways...........................................................................68
5.1.1.2
Circuit-Level Gateways ...............................................................................68
5.1.1.3
Application Level Gateways ........................................................................69
5.1.2
Introduzione ai NAT...........................................................................................69
5.1.2.1
Static NAT.................................................................................................70
5.1.2.2
Dynamic NAT ............................................................................................70
5.1.2.3
Network Address and Port Translation (NAPT)..............................................71
5.2
Problematiche di attraversamento ..................................................... 71
5.2.1
Il problema Firewall ...........................................................................................71
5.2.2
Il problema NAT ................................................................................................72
5.2.3
Soluzioni proposte .............................................................................................73
5.2.3.1
Universal Plug and Play (UPnP) ...................................................................73
5.2.3.2
STUN........................................................................................................73
5.2.3.3
Configurazione manuale .............................................................................74
5.2.3.4
Tecniche di tunnel .....................................................................................74
5.2.3.5
Application Level Gateway ..........................................................................75
6 Progettazione del SIP ALG ................................................ 76
6.1
Sistema di gestione dei messaggi SIP ................................................ 76
6.1.1
Definizione astratta dei tipi .................................................................................78
6.1.2
Messaggi SIP uscenti .........................................................................................81
6.1.3
Messaggi SIP entranti ........................................................................................82
6.2
Processo NAT L7 .............................................................................. 83
6.2.1
Messaggi in ingresso..........................................................................................85
6.2.2
Messaggi in uscita .............................................................................................86
6.3
Processo Controllo Policies ................................................................ 88
iii
6.3.1
Indice
Messaggi in ingresso..........................................................................................90
6.3.1.1
REGISTER.................................................................................................91
6.3.1.2
OPTIONS ..................................................................................................92
6.3.1.3
INVITE .....................................................................................................93
6.3.1.4
BYE ..........................................................................................................99
6.3.2
Messaggi in uscita ........................................................................................... 101
6.3.2.1
REGISTER............................................................................................... 102
6.3.2.2
OPTIONS ................................................................................................ 103
6.3.2.3
INVITE ................................................................................................... 104
6.3.2.4
BYE ........................................................................................................ 110
6.3.3
Procedure comuni............................................................................................ 112
7 Risultati e conclusioni ..................................................... 114
Appendice A – SIP Generator .............................................. 116
Appendice B – SDL ............................................................... 118
Bibliografia .......................................................................... 120
iv
INDICE DELLE FIGURE
Figura 2.1 - Architettura del Voice over IP .................................................................................6
Figura 2.2 - Stack del Voice over IP ..........................................................................................8
Figura 2.3 - Parte delle risposte SIP ........................................................................................11
Figura 2.4 - Intestazione di RTP .............................................................................................17
Figura 4.1 - Registration Hijacking: flusso di messaggi dell'attacco ............................................31
Figura 4.2 - 3XX Response code messages: 301 Moved Permanently .........................................33
Figura 4.3 - Impersonating a Proxy server: l'attaccante modifica i record del DNS.......................35
Figura 4.4 - 302 Response code message: flusso dei messaggi di attacco ..................................37
Figura 4.5 - 305 Response code message: flusso dei messaggi di attacco ..................................38
Figura 4.6 - Impersonating a Registrar Server .........................................................................39
Figura 4.7 - Tearing down a session: BYE verso le due vittime ..................................................41
Figura 4.8 - Modifying a session: fase di attacco ......................................................................42
Figura 4.9 - Cancelling a session: fase di sniffing e attacco .......................................................43
Figura 4.10 - SIP DoS attack ..................................................................................................45
Figura 4.11 - DoS: response code messages............................................................................46
Figura 4.12 - Modifying IP address .........................................................................................48
Figura 4.13 - Malicious payload format....................................................................................51
Figura 4.14 - RTCP timing rules incorrectly ..............................................................................53
Figura 4.15 - Change Synchronization Source field ...................................................................54
Figura 4.16 - BYE attack ........................................................................................................55
Figura 4.17 - Sequence Number and Timestamp higher............................................................56
Figura 4.18 - Pacchetto Reception Report di RTCP ...................................................................57
Figura 5.1 - Il problema Firewall.............................................................................................72
Figura 5.2 - Il problema NAT..................................................................................................72
Figura 6.1 - SDL: Sistema di gestione dei messaggi SIP............................................................76
Figura 6.2 - SDL: Sistema di gestione dei messaggi SIP uscenti.................................................81
Figura 6.3 - SDL: Sistema di gestione dei messaggi SIP entranti................................................82
v
1
Introduzione
Superata la bolla speculativa di fine anni novanta legata alle tecnologie Internet, i primi
anni del nuovo millennio sono stati caratterizzati dal consolidamento delle innovazioni e delle
tecnologie maturate nel corso degli ultimi anni che hanno dimostrato le effettive potenzialità per
incrementare la produttività e fornire nuovi prodotti e servizi. In particolare, nell’ambito delle
telecomunicazioni sta iniziando il processo di migrazione delle reti esistenti verso il protocollo IP;
Telecom Italia è stato il primo operatore europeo ad avere spostato la quasi totalità del traffico
long-distance su una rete in tecnologia IP e si sta apprestando a spostare anche il traffico locale
sullo stesso protocollo IP. Quest’ultima sfida richiede l’introduzione di un nuovo protocollo
sufficientemente versatile per la comunicazione tra utente e rete che consenta la fornitura di servizi
multimediali avanzati. La scelta è caduta sul protocollo standard Session Initiation Protocol (SIP)
per le sue caratteristiche di apertura, semplicità e flessibilità.
La sostanziale apertura e semplicità del protocollo SIP pone però seri problemi relativi alla
sicurezza delle comunicazioni, in particolare in relazione alla riservatezza, all’integrità ed alla
disponibilità dei servizi erogati. Data la criticità dei servizi di telecomunicazione che SIP si appresta
a supportare, è necessario realizzare un’architettura di sicurezza che garantisca la sostanziale
immunità nei confronti dei potenziali devastanti impatti che ne potrebbero derivare.
Poiché il protocollo SIP nasce e si sviluppa con le tecnologie Internet e l’informatica in generale, la
funzione IT Security di IT Telecom ha manifestato la volontà di avviare uno studio strategico volto
ad identificare le vulnerabilità del protocollo SIP testandole in un’architettura di riferimento, le
soluzioni architetturali per le messa in sicurezza del protocollo e quelle tecnologiche necessarie per
garantire la riservatezza, l’integrità e la disponibilità delle informazioni.
Questa tesi si proporne di realizzare uno studio strategico sulla sicurezza del protocollo SIP,
comprendente l’analisi tecnologica volta ad identificare le vulnerabilità e le minacce alle quali sono
esposte le soluzioni realizzate in tecnologia SIP, l’identificazione di una architettura di riferimento
per l’erogazione in sicurezza dei servizi multimediali basati su SIP, la progettazione di un SIP
Application Level Gateway (SIP ALG) che garantisca le funzionalità di SIP con Firewall e Network
Address Translator (NAT).
1
Introduzione
1.1 Stato dell’arte
Negli anni precedenti alla diffusione di Internet, nel panorama delle Telecomunicazioni
mondiali, gli utenti e gli addetti ai lavori erano soliti ragionare su due tipi di reti distinte: una per la
voce ed una per i dati. Ognuna di esse poteva a sua volta essere divisa in molte varianti, spesso
tra loro incompatibili, caratterizzanti un paese o addirittura una piccola porzione di esso. Si era di
fronte, quindi, ad un vasto panorama di tecnologie differenti, per pianificazione numerica, per tipo
di segnalazione, per codifica audio, per tipo di quelle che le industrie di telecomunicazioni
chiamavano data networks – ognuna di essa incompatibile ed impossibile da integrare con le altre
in modo da formare un'unica rete globale.
Le data networks generate dalle industrie di telecomunicazioni si svilupparono in diverse forme,
come delle linee digitali proprietarie, X.25, ISDN, SMDS, frame relay e la rete ATM. Questo tipo di
reti furono sin dal principio influenzate dall’esperienza pregressa avuta con le rete commutata a
circuito per l’utenza telefonica. Il loro nome, data networks, deriva dalla proprietà di essere state
progettate e sviluppate per trasportare dati che non fossero segnali vocali. Al contrario le reti
telefoniche, dette appunto voice networks, sono state usate in passato e tuttora per trasportare
dati e fax. Il motivo di tale promiscuità è facilmente riscontrabile nella capillare diffusione che
hanno avuto negli anni. Resta comunque il fatto che tali reti hanno esaurito la loro spinta evolutiva,
poiché da tempo hanno raggiunto un livello soddisfacente per il trasporto del segnale vocale per
cui erano state pensate. Ovviamente entrambi i tipi di rete, data networks e voice networks, sono
caratterizzati da specifici dispositivi che non possono essere utilizzati in altre reti.
Tutt’oggi la maggior parte della telefonia fissa viene fatta sulla vecchia rete PSTN (Public Switched
Telephone Network). Questo significa che una singola chiamata occupa una connessione tra i due
utenti finali e tale connessione non può essere utilizzata fin quando la comunicazione non termina.
La differenza con la telefonia via Internet, anche conosciuta come Voice over IP (VoIP), consiste
proprio nel fatto che utilizzando una rete commutata a pacchetto è possibile comunicare
contemporaneamente con più utenti senza la necessità di riservare una connessione. Ciò avviene
grazie alla digitalizzazione del segnale vocale, registrato attraverso un’interfaccia audio del
computer, segnale che viene successivamente incapsulato in pacchetti che vengono spediti ai
rispettivi destinatari attraverso il protocollo IP. Dall’altro lato, i pacchetti vengono decapsulati e
replicano il messaggio originale dall’interfaccia audio di uscita. Inoltre, altri flussi multimediali, quali
video e applicazioni condivise, possono facilmente essere scambiati tra utenti senza che siano
necessari grandi cambiamenti.
Ma quando Internet si è diffusa, sebbene si sia rapidamente affermata come rete leader nella
diffusione e scambio di dati, nelle transazioni commerciali e distribuzione audio-video, l’uso della
2
Introduzione
voce su tale rete ha avuto difficoltà a svilupparsi. Questo fatto si è verificato per l’iniziale incapacità
di replicare su Internet la stessa qualità del segnale vocale che si riscontrava se trasportato su rete
telefonica. La Qualità del Servizio (QoS) risultava infatti scadente a causa dell’impossibilità di
garantire l’effettivo arrivo dei pacchetti entro certi limiti di ritardo e perdita. La rapida diffusione
della banda larga e l’introduzione di protocolli che garantiscano una Qualità del Servizio
soddisfacente per le reti IP hanno permesso di superare tali ostacoli. A favorire la diffusione del
VoIP ci sono inoltre motivazioni di carattere economico:
¾
Riduzione dei costi
¾
Standard open source
¾
Integrazione tra voice network e data network
Molti dei servizi e applicazioni multimediali, tra i quali la voce, che hanno luogo su Internet hanno
la necessità di creare e gestire una sessione multimediale. Per sessione multimediale si intende
un’associazione tra due o anche più partecipanti per lo scambio di dati di qualsiasi tipo: dati, voce,
video, testo…
Il Session Initiation Protocol (SIP) è una specifica dell’Internet Engineering Task Force (IETF),
l’organizzazione che si occupa della standardizzazione dei protocolli internet. Tale protocollo è stato
sviluppato con lo scopo di creare, modificare e terminare sessioni multimediali su reti IP. Le
caratteristiche di semplicità e scalabilità gli hanno permesso di guadagnarsi rapidamente il ruolo di
protocollo per la telefonia su Internet (VoIP).
1.2 Struttura della tesi
Durante lo sviluppo del protocollo SIP, la maggior parte dell’attenzione è stata rivolta verso
la possibilità di fornire uno strumento flessibile e scalabile, in grado di instaurare sessioni
multimediali tra diversi utenti contemporaneamente. A fronte di queste necessità, la sicurezza non
è stata sin dal principio una delle tematiche di maggior interesse. In seguito alla rapida diffusione
che tale protocollo ha avuto, i requisiti di sicurezza hanno assunto una rilevanza centrale e
rappresentano oggi un importante argomento di discussione.
In quest’ottica, l’attività della tesi ha avuto più di un obiettivo:
a) Comprendere ed analizzare i protocolli SIP ed RTP, in modo tale da individuare le
tematiche di sicurezza ad essi legate
b) Approfondire tali tematiche in una più ampia visione, quale la rete IP, studiando e
comprendendo i meccanismi che possono portare ad un attacco informatico
3
Introduzione
c) Individuare, in base alle conoscenze ottenute dagli studi dei passi precedenti, le
vulnerabilità insite in tali protocolli (SIP ed RTP) e testarle (solamente SIP) attraverso
un’implementazione reale
d) Proporre una soluzione a tali vulnerabilità, attraverso un nodo di rete SIP ALG, che possa
evitare attacchi informatici in ambiente VoIP
e) Definire dal punto di vista formale le modifiche NAT a livello applicativo e le politiche di
sicurezza che il SIP ALG deve apportare all’architettura
La tesi è quindi strutturata come segue. Il Capitolo 2 contiene una breve descrizione
dell’architettura di una rete Voice over IP, delle funzionalità e dei messaggi del protocollo SIP ed un
accenno al ruolo dei protocolli Session Description Protocol (SDP) e del Real-Time Transfer Protocol
(RTP). Nel Capitolo 3 si descrivono le minacce e gli attacchi che possono essere portati ad una rete
Voice over IP in cui è utilizzato SIP come protocollo di segnalazione e RTP come protocollo di
trasporto del flusso multimediale. Il Capitolo 4 investiga sulle vulnerabilità proprie dei due protocolli
SIP ed RTP, dimostrandole per il protocollo SIP attraverso un’attività sperimentale. Il Capitolo 5
descrive quali problemi si incontrano nella messa in sicurezza di un’architettura VoIP attraverso i
classici strumenti Firewall e NAT.
Nel Capitolo 6 viene proposta la soluzione alle vulnerabilità descritte nel Capitolo 4 e ai problemi
riscontrati nel Capitolo precedente attraverso la progettazione di un nodo di rete, un SIP ALG, che
introduca delle politiche di sicurezza e che permetta il funzionamento dell’architettura VoIP in
presenza di Firewall e NAT. Tali soluzioni sono state definite attraverso il linguaggio formale
orientato agli oggetti Specification and Description Language (SDL) definito dall’ITU-T
(International Telecommunications Union-Telecommunications Standardization Sector).
4
2
Visione d’insieme del Voice over IP
2.1 Voice over IP (VoIP)
La trasmissione della voce in reti IP commutate a pacchetto, detta Voice over IP (VoIP), è
tra le più importanti realtà che stanno emergendo nel mondo delle telecomunicazioni.
Analogamente a molte altre nuove tecnologie, il VoIP introduce, a fronte di bassi costi e grande
flessibilità, anche rischi e vulnerabilità. La visione di una rete pronta per essere in grado di
trasportare la voce senza alcun accorgimento aggiuntivo è un errore che gli amministratori di rete
non devono assolutamente commettere. Infatti, una delle maggiori fonti di confusione è la naturale
assunzione che, poiché la voce viaggia in pacchetti come gli altri dati, allora le architetture di rete
già esistenti sono sufficienti a trasportare il traffico VoIP. Sfortunatamente, il VoIP introduce un
notevole numero di complicanze alle esistenti tecnologie di rete e tra esse hanno gran rilievo le
questioni che riguardano la sicurezza e la qualità del servizio (Quality of Service – QoS).
La QoS è di fondamentale importanza per l’operatività di una rete VoIP che soddisfi le esigenze
degli utenti. Ad aggravare la situazione, va inoltre sottolineato, che il raggiungimento di alti livelli di
sicurezza può causare il deterioramento marcato dei livelli di QoS. Infatti, a causa della natura del
VoIP, con notevoli vincoli temporali, e della sua bassa tolleranza ai disturbi e alla perdita di
pacchetti, molte delle misure volte a garantire la sicurezza e la riservatezza delle comunicazioni
vocali rende le stesse comunicazioni poco comprensibili.
2.1.1 Architettura del VoIP
In un’architettura VoIP prendono parte tre diverse classi di protocolli:
¾
Protocolli di segnalazione
Questi protocolli devono svolgere cinque funzioni: localizzazione di un utente – è la possibilità di
localizzare un altro utente con il quale si desidera iniziare una comunicazione – instaurazione di
una sessione – è la volontà, da parte del chiamato, di accettare, rifiutare o re-indirizzare la
chiamata ad un’altra locazione – negoziazione delle impostazioni – è la possibilità delle due parti
coinvolte nella comunicazione di negoziare dei parametri da usare durante la sessione – modifica
della sessione – è la possibilità di modificare i parametri suddetti durante una comunicazione –
terminazione della sessione – è la possibilità di abbattere la comunicazione.
Il Session Initiation Protocol (SIP) è un protocollo di segnalazione sviluppato dall’IETF.
5
¾
Protocolli di trasporto del flusso multimediale
Questo tipo di protocolli ha il compito di trasportare da utente ad utente i campioni di voce. I
protocolli di trasporto dei media utilizzano dei codificatori per digitalizzare la voce e per
comprimerla in piccoli campioni che vengono incapsulati in un protocollo di trasporto (UDP o TCP)
e spediti attraverso una rete IP.
Il Real-Time Transfer Protocol (RTP) è un protocollo di trasporto di media sviluppato dall’IETF e
adottato anche dall’ITU-T.
¾
Protocolli di supporto
Quest’ultimo tipo di protocolli si occupano di tutti quei compiti che non riguardano direttamente la
gestione di una sessione o del trasporto dell’informazione. Ad esempio sono quelli che garantiscono
una certa qualità di servizio, come RSVP, IntServ, DiffServ, MPLS… Altri come il protocollo Domain
Naming System (DNS) che permettono la traduzione degli indirizzi logici in indirizzi fisici,
garantendo la raggiungibilità di utenti appartenenti a domini differenti…
Un’architettura VoIP che garantisca interoperabilità con la tradizionale rete telefonica PSTN può
essere del tipo in figura.
Signaling
Gateway
Controller
SS7
Signaling
Network
Media
Gateway
Controller
PSTN
PSTN
VoIP Gateway
IP Backbone
Network
VoIP Gateway
VoIP Gateway
Telephone
IP Phone
Telephone
IP Phone
Telephone
IP Phone
Figura 2.1 - Architettura del Voice over IP
6
2.2 Session Initiation Protocol (SIP)
Nella vastità di applicazioni che possono essere utilizzate su Internet, una parte di esse
richiede l’instaurazione e la gestione di una sessione. Per sessione si intende un’associazione tra
due o anche più partecipanti finalizzata allo scambio di dati di qualsiasi tipo: dati, voce, video,
testo… L’instaurazione di tale sessione è una pratica non semplice giacché viene resa difficile dalla
differente gestione che gli utenti possono avere del flusso informativo da scambiare, ad esempio
possono utilizzare diverse codifiche del segnale vocale, e dalla mobilità degli utenti stessi. Per
questo motivo SIP [1] è stato progettato in modo da fornire una localizzazione degli utenti che
partecipano ad una sessione ed in seguito garantire una negoziazione dei parametri del flusso
multimediale da scambiare. SIP quindi può essere visto come un potente strumento capace di
creare, modificare e terminare sessioni, indipendentemente dal tipo di protocollo di trasporto
utilizzato e senza alcuna dipendenza sulla natura della sessione che viene stabilita.
SIP è stato collocato tra i protocolli di strato applicativo ossia nel settimo livello della pila ISO-OSI.
Permette di invitare partecipanti a sessioni già instaurate, supporta servizi di redirezione
garantendo la mobilità dell’utente, consente l’utilizzo di un singolo identificatore per l’utente in tutta
la rete. Tale protocollo si basa su cinque aspetti:
¾
Localizzazione dell’utente: individuazione del sistema terminale da usare per la comunicazione
¾
Disponibilità dell’utente: determinazione della volontà del chiamato a partecipare alla
comunicazione
¾
Capacità dell’utente: determinazione dei parametri del flusso multimediale
¾
Instaurazione della sessione: negoziazione dei parametri tra i partecipanti alla sessione
¾
Gestione della sessione: trasferimento e terminazione della sessione, modifica dei parametri
della sessione e chiamate di alcuni servizi applicativi
Ovviamente SIP da solo non è sufficiente per una comunicazioni tra utenti, accanto ad esso devono
essere infatti instaurati altri protocolli per il trasporto del flusso multimediale e per l’interoperabilità
con altre tipologie di reti. Tra i primi è necessario citare il Real-Time Transport Protocol (RTP), che
consente di trasportare dati in tempo reale e fornisce dei riscontri sulla qualità del servizio fornito e
il Session Description Protocol (SDP), per la descrizione delle sessioni multimediali. Tra i secondi
appare doveroso citare il Media Gateway Control Protocol (MEGACO), che consente di controllare i
gateway che interconnettono la rete SIP con quella PSTN. SIP quindi non fornisce servizi, piuttosto
fornisce delle primitive che possono essere utilizzate per implementare differenti servizi.
Il SIP è un protocollo indipendente dallo strato di trasporto, può utilizzare sia lo User Datagram
Protocol (UDP) che Transmission Control Protocol (TCP) nonché lo Stream Control Transport
7
Protocol (SCTP). Nel caso in cui si utilizzi un protocollo inaffidabile come UDP, SIP implementa un
proprio meccanismo di ritrasmissione per assicurare l’affidabilità.
Media
Transport
Signaling
Physical
Link Network Transport
H.323
Media
Encapsulation
(H.261, MPEG)
Quality of
Service
SIP
RTSP
RSVP
TCP
RTCP
RTP
UDP
IPv4
PPP
AAL 3/4
Sonet
IPv6
AAL 5
ATM
PPP
Ethernet
V.34
Figura 2.2 - Stack del Voice over IP
Infine SIP opera sia con IPv4 che con IPv6.
2.2.1 Architettura del SIP
Come è stato già sottolineato, SIP ricalca in modo particolare la struttura del protocollo
HTTP [2], e come esso adotta un modello client-server. Di conseguenza tra le figure che
partecipano ad una sessione SIP ci sono degli apparati che hanno la funzione di client ed altri che
hanno la funzioni di server, tra di essi viene seguito un modello transazionale di richiesta e
risposta. Ogni transazione consiste infatti di una richiesta generata dal client che invoca un
particolare metodo, o funzione, sul server, e di almeno una risposta generata da tale server.
Una tipica rete di comunicazione che utilizza SIP come protocollo di segnalazione contiene quattro
tipi di entità: User Agent (UA), Proxy Server, Redirect Server e Registrar Server.
¾
User Agent: rappresenta un sistema terminale, hardware o software. Essi generano le richieste
SIP per stabilire sessioni multimediali e spediscono e ricevono flussi multimediali. Lo User
Agent Client (UAC) è la parte dello UA che genera le richieste, mentre uno User Agent Server
(UAS) è l’altra parte dello UA che genera le risposte alle richieste ricevute. Durante una
sessione, entrambe le parti vengono utilizzate, al contrario di quanto accade per una classica
architettura client/server.
¾
Proxy Server: è l’elemento della rete che instrada le richieste verso gli UAS e le risposte verso
gli UAC. Una richiesta può attraversare numerosi Proxy Server prima di giungere a
destinazione.
Ognuno
di
essi,
quando
coinvolto
nella
sessione,
prende
decisioni
sull’instradamento, modificando le richieste prima di inoltrarle verso l’entità successiva. Le
8
risposte a tali richieste viaggeranno in verso opposto, attraversando le stesse entità coinvolte
nella direzione delle richieste. Le azioni principali di un Proxy Server in una rete SIP sono
processare le richieste, autenticare gli utenti, risolvere gli indirizzi, cancellare le chiamate
pendenti, rilevare e abbattere dei loop ed infine biforcare le richieste. Tali compiti vengono
assolti con un preciso vincolo progettuale: i Proxy Server devono agire in modo da essere il più
possibile invisibile agli occhi degli UA.
Esistono due classi di questi server:
•
Stateless Proxy
•
Stateful Proxy
I primi, dopo aver controllato la correttezza dell’intestazione, inoltrano semplicemente i
messaggi. Questo significa che una volta che il messaggio è stato inoltrato, il Proxy Server
Stateless non conserva alcuna informazione riguardo ad esso. Questo tipo di server quindi
permette di costruire una rete altamente performante e scalabile, a discapito di una scarsa
conoscenza dello stato della rete e di un’impossibilità di ritrasmettere messaggi andati persi.
Al contrario i Proxy Server Stateful sono in grado di memorizzare informazioni sui messaggi che
hanno processato, in modo tale da rendersi conto di un’eventuale perdita degli stesso o di
ritrasmissioni inutili da parte degli UAC. La conservazione dello stato della sessione implica,
però, la possibilità di gestire un numero limitato di transazioni vista la disponibilità limitata di
memoria e un maggiore tempo di attraversamento del dispositivo a causa del tempo di
processamento dei messaggi.
¾
Redirect Server: è utilizzato in architetture in cui può essere utile ridurre il carico di lavoro dei
Server responsabili dell’instradamento delle richieste degli UAC e migliorare la robustezza dei
cammini di segnalazione sfruttando il reinstradamento delle richieste. Questo reinstradamento,
ottenuto proprio grazie ai Redirect Server, permette ai server di consegnare le informazioni di
routing di una richiesta direttamente a chi l’ha originata, evitando in tal modo di prendere
parte del percorso che si instaura tra UAC e UAS. Quando lo UAC riceve un messaggio di
redirezione, estrae da esso le informazioni necessarie a creare la nuova richiesta. Il propagarsi
di tali informazioni dal nucleo verso la periferia consente alla rete di essere maggiormente
scalabile rispetto ad una situazione in cui l’instradamento è compito esclusivo dei Proxy Server.
¾
Registrar Server: è un server che accetta solamente un tipo particolare di richieste, quelle che
hanno lo scopo di aggiornare il database di localizzazione a cui il dominio è associato con le
informazioni di localizzazione fornite dagli utenti. Il database di localizzazione, detto Location
Server, può essere interrogato anche dai Proxy Server e dai Redirect Server per ottenere le
informazioni di localizzazione di un utente. Bisogna sottolineare che il Location Server non è un
componente dell’architettura SIP.
9
2.2.2 Messaggi SIP
SIP è un protocollo basato su uno schema transazionale a richiesta e risposta, ciò significa
che i messaggi SIP sono o richieste da uno UAC ad un UAS o una risposta da un UAS ad un UAC.
Diversamente però da altri protocolli di segnalazione, come H.323 [3], SIP è un protocollo testuale
e in particolare il formato ricorda molto quello dell’HTTP.
La sintassi del protocollo è specificata attraverso la grammatica “Augmented Backus-Naur Form”
(ABNF) [4]. Sia le richieste che le risposte consistono di tre parti:
¾
una start-line, con cui inizia ogni messaggio SIP
¾
un blocco contenente uno o più campi dell’intestazione (header)
¾
opzionalmente il corpo del messaggio (message-body)
Per indicare la conclusione del blocco dei campi header si utilizza una linea bianca (blank-line), che
deve essere presente anche in assenza del corpo del messaggio. La start-line, ogni header del
messaggio e la blank-line devono essere terminati con una sequenza di carraige-return line-feed
(CRLF).
Start-Line
La start-line può essere una Request-Line oppure una Status-Line. Nel primo caso si tratta di un
messaggio di richiesta, e contiene il nome della richiesta (anche detta metodo), la Request-URI e la
versione del protocollo in uso, separati da un singolo spazio:
Request-Line = Method SP Request-URI SP SIP-Version CRLF
I messaggi SIP di risposta hanno una Status-line per start-line. Essa contiene la versione del
protocollo, un valore numerico detto Status-Code ed una frase testuale associata allo Status-Code:
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
Il significato dei vari campi è:
¾
Method: il metodo è la funzione primaria invocata da una richiesta su di un server. L’ultima
specifica del SIP elenca sei metodi:
•
REGISTER, per informare un Registar Server delle informazioni necessarie ad aggiornare il
Location Server
•
INVITE, per instaurare una sessione multimediale tra User Agent o per cambiare i
parametri di una sessione già instaurata
•
ACK, per confermare la ricezione di una risposta definitiva (si veda dopo) ad una richiesta
di INVITE
•
CANCEL, per terminare sessioni pendenti e quindi ancora non instaurate
•
BYE, per terminare una sessione multimediale precedentemente instaurata
10
•
¾
OPTIONS, per ricevere dai server informazioni sulla loro capacità e disponibilità
Request-URI: è una SIP URI (si veda dopo) o un URI di tipo generale, come indicato in [5].
Essa indica l’utente o il servizio a cui la richiesta è stata indirizzata. Gli indirizzi SIP sono URL
gerarchici costituiti dal numero di telefono dell’utente o l’host name (ad esempio
sip:[email protected]). Per la loro somiglianza, le SIP URL sono facilmente confondibili con
gli indirizzi email.
¾
Status-Code: è un valore numerico di tre cifre che indica il risultato di un tentativo di
comprendere e soddisfare una richiesta. La prima cifra indica la classe della risposta, che per
SIP versione 2.0 sono sei. Le rimanenti due cifre indicano il particolare tipo di risposta
appartenente a quella classe. Una risposta appartenente alla prima classe è detta provvisoria
(quindi di tipo 1xx), mentre una risposta appartenente alle altre cinque classi sono dette
definitive (quindi di tipo 2xx, 3xx, 4xx, 5xx e 6xx):
Informational
Success
200 OK
100 Trying
180 Ringing
181 Call Forwarded
182 Queued
183 Session Progress
Redirection
Request Failure
300 Multiple Choices
301 Moved Perm.
302 Moved Temp.
380 Alternative Serv.
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
405 Bad Method
486 Busy Here
500 Server Error
501 Not Implemented
503 Unaivalable
504 Timeout
600 Busy Everywhere
603 Decline
604 Doesn’t Exist
606 Not Acceptable
Server Failure
Global Failure
Figura 2.3 - Parte delle risposte SIP
•
1xx – Provisional: le risposte di questa classe sono utilizzate per indicare che la richiesta è
stata ricevuta e che i server contattati la stanno elaborando
•
2xx – Success: le risposte di questa classe sono utilizzate per indicare che la richiesta è
stata ricevuta, compresa ed elaborata con successo
•
3xx – Redirection: le risposte di questa classe sono utilizzate per fornire informazioni sulla
nuova localizzazione dell’utente o sui servizi alternativi che potrebbero essere in grado di
soddisfare la richiesta. Sono tipicamente utilizzate dai Redirect Server
•
4xx – Client Error: le risposte di questa classe sono utilizzate per indicare l’impossibilità da
parte del server di soddisfare una richiesta, seppur valida. La stessa richiesta potrebbe
essere soddisfatta da un altro server
•
5xx – Global Failure: le risposte di questa classe sono utilizzate per indicare l’impossibilità
di soddisfare la richiesta da parte di alcun server
11
¾
Reason-Phrase: fornisce una breve descrizione testuale dello Status-Code, è di uso
semplicemente dell’utente e non entra a far parte dell’elaborazione dello stack SIP.
¾
SIP-Version: è la versione del protocollo in uso. La più recente è la “SIP/2.0”.
Header
Gli header sono utilizzati per trasportare gli attributi dei messaggi e per modificare il significato dei
messaggi stessi. In questa sezione vengono descritti solo alcuni dei SIP header inclusi nell’ultima
specifica del protocollo, limitatamente alla pertinenza sull’argomento trattato. In generale si
distinguono quattro tipi di header: general-header, request-header, response-header e entità-
header.
I general-header sono di utilizzo generale, e per questo vengono usati sia nelle richieste che nelle
risposte. A questa classe appartengono:
•
To: indica il destinatario ‘logico’ della richiesta, che può o non può essere quello finale. Può
contenere un SIP URI o un URI di tipo generale;
•
From: indica l’origine ‘logica’ della richiesta. Può contenere un SIP URI o un URI di tipo
generale;
•
Call-ID: identifica univocamente e globalmente una sessione. E’ una sequenza alfanumerica
randomica a cui viene aggiunto il dominio dell’utente, ha quindi la forma “local-id@host “;
•
Cseq: è costituito da un numero di sequenza e dal metodo della richiesta. Il numero di
sequenza serve a distinguere eventuali ritrasmissioni e ad associare le risposte alle richieste;
•
Max-Forwards: indica, attraverso un intero, il numero massimo di nodi SIP attraverso cui una
richiesta può transitare prima di giungere a destinazione. Quando i nodi processano le richieste
decrementano di uno questo valore. Se dovesse raggiungere il valore zero, la richiesta
verrebbe scartata e verrebbe generata una risposta di errore 483 (Too Many Hops).
•
Via: questo campo è utilizzato per conservare il percorso che una richiesta ha effettuato dalla
sorgente alla destinazione e il percorso che una risposta ha effettuato dalla destinazione alla
sorgente. Ogni UA che genera una richiesta immette il proprio indirizzo nel campo Via, quando
il Proxy Server inoltra tale richiesta aggiunge anch’esso il proprio indirizzo in cima alla lista
degli indirizzi del campo Via. Questo metodo permette l’instradamento delle risposte verso il
mittente delle richieste.
I request-header sono intestazioni che si applicano unicamente alle richieste, con lo scopo di
fornire al server informazioni addizionali. Di questa classe fanno parte Authorization e Proxy-
Authorization. Anche l’header Route appartiene a questa classe ed ha lo scopo di forzare
l’instradamento di una richiesta attraverso una serie di nodi SIP. I response-header, al contrario, si
applicano solamente alle risposte. Alcuni esempi di intestazioni di questa classe sono il WWW-
Authenticate e Proxy-Authenticate. Infine gli entity-header sono intestazioni che permettono di
12
fornire informazioni riguardanti il corpo del messaggio. A tale classe appartengono Content-Length
e Content-Type.
Message Body
Sia le richieste che le risposte possono contenere un corpo del messaggio dopo l’intestazione. Tale
corpo è descritto attraverso i l’header Content-Type, che permette di specificare tramite i tipi MIME
[6] la tipologia del contentuto. L’header Content-Length specifica invece la lunghezza in bytes del
corpo del messaggio. Questa lunghezza è necessaria per individuare la fine di ogni messaggio SIP
in un flusso di dati nel caso in cui venga utilizzato un protocollo stream-oriented, come TCP o
SCTP.
Generalmente nel corpo del messaggio è contenuta una descrizione dei parametri della sessione
multimediale che si vuole instaurare o che si vuole modificare. Tali parametri vengono scambiati
tra UA attraverso il protocollo SDP.
2.2.3 Funzionalità del SIP
Nei prossimi paragrafi il protocollo SIP verrà descritto in base alle funzionalità che esso
fornisce all’utente: risoluzione degli indirizzi, funzioni legate alle chiamate (inizializzazione della
sessione, modificazione di una sessione, cancellazione e abbattimento di una sessione ed infine
controllo della qualità di servizio) e funzioni non legate alle chiamate (mobilità, trasporto di
messaggistica, notifica di eventi, autenticazione ed estensibilità a sviluppi futuri). Di tutti questi
aspetti che caratterizzano il SIP vengono di seguito descritti solamente quelli che interessano lo
studio di tesi.
2.2.3.1
Risoluzione degli indirizzi
La risoluzione degli indirizzi è una delle funzioni più importanti del protocollo SIP. Tale procedura,
descritta dettagliatamente in [7], permette ad un elemento SIP che desidera spedire una richiesta
di determinare a partire da un SIP URI, l’indirizzo IP, la porta e il protocollo di trasporto del nodo di
rete successivo, detto next hop, che può essere un Proxy Server oppure uno User Agent. Questa
traduzione da nome generico a utente finale è estremamente importante per garantire la mobilità e
la portabilità dell’utente e del suo traffico. La risoluzione di indirizzi può essere effettuata sia dagli
UA che dai server.
Il protocollo Domain Name System (DNS) fornisce due tipi di record rilevanti per le richieste SIP:
SRV e NAPTR. Alcune implementazioni utilizzano solamente record di tipo SRV [8].
¾
SRV Record: questo tipo di record sono nella forma
“_Service._Proto.Name TTL Class SRV Priorità Weight Port Target”
in cui il campo Service deve essere SIP; il campo Proto è il protocollo di trasporto utilizzato dal
server; Name è il nome del dominio in cui risiede il Proxy Server; TTL è il tempo di vita del
13
record espresso in secondi; SRV è il tipo di record; Class è sempre del valore IN; Priority indica
l’ordine in cui un client interroga i diversi Proxy, ossia più il valore è basso e più il Proxy sarà
utilizzato; Weight determina proporzionalmente quanto spesso un proxy viene interrogato se
ve ne sono alcuni a pari Priority, quelli con i valori più bassi sono interrogati dai client più
raramente; il valore di Port è 5060; Target è infine il nome simbolico del Proxy Server.
Ad esempio nel caso in cui si utilizzino due Proxy Server la configurazione del DNS Server avrà
i seguenti record:
_sip._udp.domain.com 43200 IN SRV 0 0 5060 sipserver1.domain.com
_sip._tcp.domain.com 43200 IN SRV 0 4 5060 sipserver1.domain.com
_sips._tcp.domain.com 43200 IN SRV 0 0 5060 sipserver1.domain.com
In questa configurazione del DNS Server una richiesta SIP su UDP sarà consegnata sempre al
sipserver1 del dominio domain.com perchè il valore della priorità è minore. Se questa richiesta
dovesse fallire, allora il sipserver2 riceverà la richiesta. Di conseguenza si intuisce che il ruolo
del sipserver2 è quello di sopperire ad un eventuale sovraccarico del primo. Nel caso venga
utilizzato TCP come protocollo di trasporto, allora le richieste che arriveranno al sipserver1
saranno il doppio di quelle che giungeranno al sipserver2 visto che il peso del primo è il doppio
del secondo. Nell’ultimo caso, in cui il protocollo di trasporto è TLS su TCP i due server,
sipserver1 e sipserver2, sono totalmente paritetici, visto che coincidono sia i valori di Priority
che di Weight.
Quando uno UA intende iniziare una sessione SIP verso sip:[email protected] manderà
inizialmente una richiesta DNS SRV lookup su domain.com. Dopo la ricezione di una risposta
dal
server
DNS,
il
SIP
UA
può
mandare
la
propria
richiesta
verso
sip:[email protected].
¾
NAPTR Record: forniscono un meccanismo per il dominio destinazione dei messaggi che
specifica quale protocollo di trasporto preferisce utilizzare. Questo tipo di record sono nella
forma:
“domain-name TTL Class NAPTR Order Preference Flags Service Regexp Target”
in cui il campo domain-name indica il nome del dominio che deve essere contattato dalla
richiesta SIP; il TTL indica il tempo di vita del record nel DNS Server; il campo Class è sempre
IN; NAPTR descrive il tipo di record; il campo Order specifica l’ordine in cui i record sono letti,
se viene trovata una corrispondenza di protocollo di trasporto tra chiamante e chiamato allora
deve essere utilizzato quel protocollo e gli altri record devono essere scartati; il campo
Preference viene utilizzato nel caso in cui il valore di Order coincida tra due o più record, valori
più bassi hanno priorità maggiore; il valore del Flag è specifico dell’applicazione a cui si
riferisce, per SIP vale s; il valore di Service specifica il protocollo di trasporto, i valori sono
SIP+D2U per SIP su UDP, SIP+D2T per SIP su TCP, SIP+D2S per SIP su SCTP e SIPS+D2T
14
per Secure SIP su TLS su TCP; il campo Regexp e quello Target sono usati per indicare il
server da contattare per inoltrare la richiesta, però uno solo dei due va specificato.
I record che si dovrebbero usare per completare l’esempio precedente sono:
domain.com IN NAPTR 0 0 “s” “SIPS+D2T” “” _sips._tcp.domain.com
domain.com IN NAPTR 1 0 “s” “SIP+D2T” “” _sip._tcp.domain.com
domain.com IN NAPTR 2 0 “s” “SIP+D2U” “” _sip._udp.domain.com
Come si può vedere la precedenza è data al trasporto su TLS su TCP, poi solo su TCP e infine
su UDP.
In pratica le implementazioni di BIND sono spesso sviluppate in modo da fornire come risposta i
record SRV e quelli A, allo scopo di non dover spedire DNS lookup addizionali. Il fatto di spedire
molte richieste DNS infatti rappresenta un problema, visto che l’instaurazione di una sessione SIP è
un processo che richiede vincoli temporali molto stringenti.
I passi che devono essere intrapresi da un SIP UAC per spedire una richiesta ad un SIP UAS sono
al massimo tre:
1) spedire una richiesta DNS NAPTR al dominio specificato nella Request-URI. Se come risposta
ottiene dei record validi allora in base ad essi decide il protocollo di trasporto da utilizzare.
2) se non ottiene alcun record NAPTR in risposta allora deve spedire una richiesta DNS SRV in base
al protocollo di trasporto che preferisce. Se ottiene una risposta, allora la richiesta viene inviata
attraverso quel protocollo di trasporto e verso il server specificato nella risposta.
3) se non vengono trovati record anche nel caso di DNS SRV allora viene spedita una richiesta di
tipo DNS A. Se come risposta ottiene un indirizzo IP valido, la richiesta viene spedita verso esso
attraverso il protocollo UDP.
2.2.3.2
Funzioni legate alle chiamate
La maggior parte delle funzioni di SIP sono coinvolte nella fase di instaurazione di una sessione. Di
esse fanno parte ad esempio l’instaurazione stessa di una sessione ex-novo, l’abbattimento e la
cancellazione di una sessione e la modifica di una sessione. Esempi di queste funzioni sono
descritte dettagliatamente in [9].
2.2.3.3
Funzioni non legate alle chiamate
Alcune funzioni SIP non si legano direttamente all’instaurazione di una sessione. Queste funzioni
possono essere eseguite infatti al di fuori di una sessione SIP.
¾
Mobilità: La possibilità di registrare l’URL su cui ricevere le proprie chiamate è una funzione di
SIP che permette di implementare la mobilità, aspetto che rende SIP molto appetibile rispetto
ad altri protocolli di segnalazione. E’ anche questo supporto della mobilità che ha portato
15
all’utilizzo del protocollo in molte delle nuove applicazioni ed è stato accettato per essere
applicato come protocollo di segnalazione per le reti mobili di terza generazione nell’IP
Multimedia Subsystem (IMS).
La registrazione permette di creare nel suddetto Location Server un’associazione (binding) tra il
SIP URI pubblico (Address-of-Record, AOR) di un utente e uno o più indirizzi dove l’utente può
essere disponibile. Gli indirizzi tipicamente sono SIP URI, ma possono anche essere usati altri
schemi URI, come un tel URL o mailto URL. Chiaramente ha senso registrare un AOR nel
Location Server di un dominio se le richieste per quell’AOR saranno instradate verso quel
dominio.
La registrazione crea quindi binding tra AOR e Contact Address in un Location Server che
gestisce un particolare dominio. Perciò, quando un Proxy Server di quel dominio riceve una
richiesta in cui la Request-URI coincide con l’AOR, il Proxy inoltra la richiesta al Contact
Address registrato per quell’AOR.
Una volta che un client ha generato un binding all’interno di un Registrar Server, può generare
ulteriori richieste di tipo REGISTER contenenti nuovi binding o modifiche a quelle esistenti. La
risposta del Registrar Server con un messaggio di tipo 2XX conterrà nel campo Contact
dell’intestazione una lista completa dei binding che sono registrati presso quel Server per
quell’address-of-record. Inoltre, quando un client genera delle richiesta REGISTER, di solito
indica un intervallo di validità della binding che crea all’interno del Registrar Server. Se il valore
dell’intervallo non è indicato dal client, sarà il server, secondo le proprie politiche locali, a
decidere autonomamente la cancellazione del binding all’interno della propria memoria. Ogni
UA è responsabile dell’aggiornamento dei propri binding da esso creati. Un UA non dovrebbe
infatti, secondo [1], aggiornare l’intervallo temporale di cancellazione di binding creati da altri
UA. Le registrazioni vengono cancellate dal Registrar Server quando l’intervallo di validità
scade, ma possono anche essere esplicitamente cancellate dall’utente. Nel secondo caso
l’utente infatti mandando una richiesta REGISTER con un intervallo di validità nullo, cancella
tutti i binding associati al proprio address-of-record [10].
2.3 Session Description Protocol (SDP)
Il Session Description protocol (SDP), definito da [11], è stato sviluppato dal gruppo di
lavoro MMUSIC dell’IETF. E’ il protocollo utilizzato per descrivere i parametri delle sessioni
multimediali durante le fase di three-way-handshake per instaurare una sessione. In questa fase il
messaggio SDP viene incapsulato in un messaggio SIP, che nel campo Content-Type
dell’intestazione contiene il valore application/sdp.
Le informazioni trasportate concernono:
¾
il nome e lo scopo della sessione
16
¾
la durata della sessione
¾
il modo in cui utilizzare la banda disponibile
¾
il tipo di dati trasmessi (audio, video, …)
¾
il protocollo di trasporto adottato (RTP/UDP/IP, H.320, …)
¾
il formato dei dati trasmesso (H.261 video, Mpeg video, …)
¾
Multicast Address e Transport Port, indirizzo e porta di destinazione del flusso dati, nel caso di
una sessione multicast
¾
Remote Address e Transport Port, indirizzo e porta di destinazione del flusso dati, nel caso di
una sessione unicast
2.4 Real-Time Transfer Protocol (RTP)
Il Real-Time Transfer Protocol [12] è stato sviluppato per consentire il trasporto in tempo
reale di pacchetti che contenessero voce, video o altre informazioni su una rete IP. RTP non
fornisce alcuna garanzia di qualità del servizio su una rete IP, i pacchetti RTP infatti vengono
trattati in modo indistinto da tutti gli altri pacchetti che viaggiano nella rete. Comunque RTP rileva
di alcune delle debolezze introdotte dalla natura delle reti IP, come:
¾
perdita di pacchetti (packet loss)
¾
variabilità del ritardo di trasporto
¾
arrivo dei pacchetti fuori sequenza
¾
instradamento asimmetrico
Dallo stack dei protocolli VoIP si può notare come RTP sia un protocollo di livello applicativo che
utilizza UDP come protocollo di trasporto. RTP non è codificato in testo come SIP, ma è orientato ai
bit, come UDP e IP del resto. In figura è rappresentata l’intestazione di un pacchetto della versione
due del protocollo RTP.
V
P
X
CC
M
PT
Sequence
Number
Timestamp
SSRC
CSRC
Figura 2.4 - Intestazione di RTP
17
RTP è stato progettato per essere il più generale possibile, molti dei campi dell’intestazione sono
solo vagamente descritti nello standard mentre i dettagli sono lasciati alle diverse implementazioni.
I dodici ottetti dell’intestazioni sono divisi in:
¾
Version (V): questi due bit sono impostati a 2, la versione corrente di RTP
¾
Padding (P): se questo bit è settato, allora c’è del padding (bit di riempimento) alla fine del
pacchetto per renderlo di dimensione fissa
¾
Extension (X): se il bit è settato, c’è un’estensione addizionale che segue l’intestazione
(portando a 14 gli ottetti totali dell’header). Le estensioni sono definite per particolari payload
¾
CSRC count (CC): questo campo di 4 bit contiene il numero del content source identifiers
(CSRC) che segue l’intestazione. Questo campo è usato solamente dai mixers che da diversi
flussi RTP ne creano uno singolo
¾
Marker (M): questo singolo bit è usato per indicare l’inizio di un nuovo frame video, o l’inizio di
un dialogo dopo dei momenti di silenzio
¾
Payload Type (PT): è un campo di 7 bit che definisce il codificatore (codec) utilizzato. Il valore
in questo campo deve coincidere con quello specificato nel corpo del messaggio SDP
¾
Sequence Number: questo campo di 16 bit è incrementato per ogni pacchetto RTP spedito ed
è usato per rilevare pacchetti mancanti o fuori sequenza
¾
Timestamp: è un campo di 32 bit che indica in termini relativi il tempo in cui il payload è stato
digitalizzato. Questo campo permette al ricevitore di eliminare il jitter e riprodurre il contenuto
dei pacchetti con l’intervallo corretto assumendo che ci sia un buffer sufficiente
¾
Synchronization Source Identifier (SSRCI): è un campo di 32 bit che identifica la sorgente dei
pacchetti RTP. All’inizio della sessione, ogni partecipante sceglie un SSRC randomico. Se due
partecipanti casualmente scegliessero lo stesso, devono cambiarlo per continuare la
trasmissione
¾
Contributing Source Identifier (CSRC): questo campo è presente solo se il pacchetto RTP è
stato generato da un mixer.
Bisogna notare che RTP attraverso il Sequence Number consente la rilevazione di un fuori
sequenza o della perdita di pacchetti, ma lascia la risoluzione di tali problemi ai codec utilizzati. Ad
esempio, un codec video può compensare la perdita di pacchetti ripetendo lo stesso frame, mentre
un codec audio può riprodurre un rumore di fondo. La variabilità del ritardo o il jitter invece
possono essere rilevati attraverso il campo Timestamp. Infatti un codec che ha un flusso di bit
continuo nel tempo, come il PCM, avrà un incremento lineare nel tempo del Timestamp.
In una sessione multimediale instaurata attraverso SIP, le informazioni necessarie sulla scelta dei
codec sono trasportate nel corpo di un messaggio SDP. In alcuni casi può essere necessario
cambiare i codec durante una sessione RTP. Poiché il pacchetto RTP contiene il campo Payload
Type nell’intestazione teoricamente è possibile cambiare al volo i codec senza alcuna informazione
18
di segnalazione tra i due partecipanti alla sessione. Ma da un punto di vista pratico, cambiare i
codec senza alcuna segnalazione potrebbe portare alla scelta di un codec che uno dei due
partecipanti non supporta e ciò causerebbe il fallimento della chiamata. Appare evidente quindi la
funzione del messaggio re-INVITE di SIP: permettere di cambiare i parametri della sessione senza
che i partecipanti ne risentano.
19
3 Aspetti di sicurezza nel Voice over IP
La sicurezza e la riservatezza sono requisiti obbligatori in una rete di fonia. Sebbene non
sia perfetta, con gli anni la tradizionale rete telefonica PSTN ha raggiunto un soddisfacente grado
di sicurezza. Dall’altra parte, il Voice over IP (VoIP), che potrebbe rappresentare il nucleo centrale
dell’infrastruttura di rete di fonia nel prossimo futuro, introduce vulnerabilità e problematiche di
sicurezza che la vecchia rete telefonica non aveva.
Quando si progetta una rete VoIP si devono tenere in considerazione differenti parametri, oltre alla
sicurezza e alla riservatezza. Di essi fanno parte:
Qualità della voce – senza un’accettabile qualità della voce la telefonia attraverso IP non può
essere adottata. La qualità della voce in VoIP è funzione di diversi fattori come la latenza, il ritardo,
il jitter, la perdita di pacchetti e altri… Con la tradizionale rete telefonica alcuni di questi aspetti non
rappresentano un problema data l’architettura commutata a circuito.
Qualità del servizio – quando un utente vuole effettuare una chiamata la rete dovrebbe riservare
per essa un’appropriata larghezza di banda. Se dovesse accadere che nel contempo si verifica il
trasferimento di una larga quantità di dati, la priorità deve essere data al traffico voce rispetto a
quello dati per prevenire l’accodamento, la latenza e la perdita di pacchetti. Anche se la rete
dovesse congestionarsi, il traffico voce non dovrebbe risentirne.
Disponibilità – deve essere garantita agli stessi livelli di quella della rete tradizionale. Per
esempio, i carrier devono garantire la funzionalità della rete PSTN per il 99.999% del tempo:
questo significa che la rete può essere fuori servizio per massimo 5 minuti l’anno. Analogamente, la
rete VoIP deve garantire la disponibilità del servizio esattamente come accade oggi, il 99.999% del
tempo.
Scalabilità – una rete VoIP necessita di essere scalabile, di supportare centinaia di migliaia di
connessioni contemporanee e di mantenere la possibilità di crescere secondo la domanda.
Sebbene i parametri descritti in questa sezione non sembrino direttamente inerenti agli aspetti di
sicurezza di una rete VoIP, l’abilità di un utente malintenzionato di interferire con le operazioni
della suddetta rete può minarne la qualità, la disponibilità e la scalabilità.
20
Aspetti di sicurezza nel Voice over IP
3.1 Vulnerabilità del VoIP
La tecnologia VoIP permette che termini come hacker e phreaker (coloro che tentano di
introdursi nella rete telefonica senza permesso) coincidano. Alcune proprietà della telefonia via IP
rendono facile il compito ad un phreaker/hacker di compromettere o addirittura controllare diversi
apparati di una rete VoIP. Le caratteristiche di sicurezza associate ad una rete VoIP inoltre sono
molto diverse da quelle che finora sono state studiate e sviluppate per una classica rete telefonica;
per questo motivo prima di implementare una rete di tale tipo bisogna tenere in considerazione
diversi fattori:
Utilizzo di IP
Poiché il VoIP utilizza IP come protocollo per trasportare le informazioni, allora eredita da
esso tutte le vulnerabilità conosciute e non conosciute.
Diffusione di IP
Le reti IP sono diffuse e facilmente accessibili. Ciò permette che molti utenti possano
investigare sulle tematiche di sicurezza ed eventualmente rendere di dominio pubblico le
vulnerabilità trovate.
Nessuna separazione di rete
Diversamente da quanto avviene per la rete PSTN, dove l’unico punto della rete in cui la
segnalazione (SS7) condivide il collegamento con il flusso audio è la linea che va dall’apparecchio
dell’utente al commutatore dell’operatore telefonico; nel VoIP non esiste isolamento o alcuna
separazione fisica tra informazioni di segnalazione e informazione dell’utente. Questo ovviamente
aumenta i rischi e le vulnerabilità di tale struttura.
Voce e dati condividono la stessa rete
Con la rete PSTN, voce e dati sono trasportate su reti fisicamente separate. Sebbene
diverse tecnologie possano essere utilizzate per separare virtualmente voce e dati quando
viaggiano sulla stessa rete (attraverso le Virtual LAN ad esempio), di solito queste possono
costituire un aumento del livello di rischio. Infatti, poiché entrambe le reti virtuali condividono gli
stessi apparati, è possibile attuare delle interferenze nella rete voce utilizzando la rete dati. Per
esempio, gli attacchi Denial of Service lanciati da una rete dati hanno di solito come obiettivo gli
switch della rete, che se colpiti provocano il deterioramento delle prestazioni sia per quanto
riguarda il traffico dati che quello voce.
Intelligenza dei dispositivi
21
Nella telefonia tradizionale gli apparecchi telefonici costituiscono dei dispositivi stupidi,
ossia sono semplicemente in grado di collegarsi ai commutatori telefonici, in cui risiede l’intera
intelligenza della rete. Con alcuni protocolli di segnalazione della rete VoIP, ed è il caso di SIP, i
dispositivi terminali d’utente gestiscono una parte o la totalità dell’intelligenza della rete. Cioè,
questi dispositivi terminali dispongono delle funzionalità e abilità di interagire con differenti
componenti e servizi della rete VoIP. Per questo motivo alcuni utenti possono sfruttare tale
intelligenza dei dispositivi terminali per perpetrare attacchi alla rete VoIP.
L’abilità di un dispositivo terminale di interagire attivamente con differenti elementi dell’architettura
VoIP favorisce grandi rischi per una rete telefonica via IP rispetto ad una rete telefonica
tradizionale in cui i commutatori, a cui i telefoni sono connessi, rappresentano il bersaglio preferito
per perpetrare degli attacchi.
Assenza di una singola autorità di controllo
In alcune architetture VoIP l’informazione di segnalazione e il segnale audio digitalizzato
attraversano differenti reti IP controllate da diverse entità. In molti casi non è possibile
determinare il livello di sicurezza che i differenti provider garantiscono nella propria rete,
trasformando tali reti un potenziale fattore di rischio e rendendo la sicurezza una questione
relativa.
Apparati di rete
Gli apparati di una rete VoIP sono dei tradizionali calcolatori, in alcuni casi utilizzano
addirittura sistemi operativi conosciuti. Gli apparati della rete VoIP interagiscono con altri apparati
della rete IP e per questo sono più vulnerabili rispetto a quelli della rete PSTN, che generalmente
sono proprietari ed utilizzano sistemi operativi sconosciuti alla maggior parte degli utenti.
Protocolli VoIP
Inizialmente molti dei protocolli VoIP sono stati progettati senza tenere conto delle
tematiche di sicurezza; inoltre se si considerano inevitabili difetti di progettazione ne scaturisce un
quadro interessante per ogni utente malintenzionato. Per esempio si consideri il caso di un
protocollo di segnalazione che non conserva la conoscenza dei cambiamenti apportati al flusso
multimediale durante una chiamata.
Protocolli di supporto
Non sono solo i protocolli VoIP a introdurre delle vulnerabilità per la telefonia via IP, ma
anche tutti i protocolli di supporto e tutte le tecnologie che fanno parte del mondo VoIP. Si
possono citare ad esempio i protocolli applicativi – ad esempio DNS, Quality of Service Protocols –
oppure le tecnologie di internetworking – Ethernet, Token Ring, Wi-Fi. Questa varietà di protocolli,
non essendo immune dagli attacchi apporta tali vulnerabilità alla tecnologia VoIP, permettendo ad
utenti maliziosi di controllare diversi aspetti o parti di una rete.
22
Accesso fisico
L’accesso diretto al collegamento, alla rete o addirittura all’apparato è di solito visto come il
pericolo maggiore per una rete di telecomunicazioni. Un utente malintenzionato che ottiene tale
accesso fisico può disporre di diversi vantaggi chiave che in un’analoga struttura PSTN non aveva. I
vantaggi derivano direttamente dal modo in cui una rete IP funziona, dal collocamento
dell’intelligenza nella rete VoIP nei terminali, e dalle barriere usuali in una rete PSTN per la
sicurezza e l’accesso fisico.
Per esempio, se un utente malizioso fosse in grado di ottenere un accesso fisico non autorizzato al
collegamento tra il terminale dell’utente e lo switch della rete, l’attaccante sarebbe in grado di
effettuare delle chiamate a spese dell’utente legittimo, senza interferire in alcun modo con il
traffico dell’utente legittimo. Uno scenario simile per la rete PSTN portava ad effetti differenti,
infatti se un utente malizioso si attacca alla rete di un altro utente, quest’ultimo sarebbe rimasto
isolato e sarebbe riuscito facilmente a rilevare l’attacco.
Affidabilità
L’affidabilità è uno degli aspetti di maggiore importanza per una rete telefonica. Si
consideri ad esempio il nodo cruciale dell’alimentazione degli apparati. Se da una parte i fornitori di
servizi (Carrier e Internet Telephony Service Provider - ITSP) possono garantire l’affidabilità
attraverso la ridondanza o attraverso generatori indipendenti dalla rete elettrica nazionale, per
quanto riguarda gli utenti finali il problema non è di facile risoluzione considerando il fatto che la
maggior parte di telefoni IP hanno bisogno di alimentazione.
Architettura di rete
In tutte le reti VoIP dovrebbero essere implementati alcuni meccanismi basilari di sicurezza
che rendano vano ogni tentativo di attacco abbastanza semplice. Ad esempio, si consideri il caso in
cui gli elementi non vengano autenticati dalla rete. Questa situazione rende agevole l’attacco di un
phreaker, che installando un dispositivo terminale appositamente modificato riesce a fare
telefonate gratuitamente.
Identità non fidate
In una rete VoIP senza configurazioni e meccanismi ad hoc, un utente non dovrebbe fidarsi
dell’identità dichiarata da un altro utente che partecipa alla chiamata. L’identità dell’utente, ad
esempio l’informazione contenuta nel campo Call-ID dell’intestazione di un messaggio SIP, è
facilmente falsificabile utilizzando semplici metodi.
La natura della voce
Senza un’adeguata qualità della riproduzione vocale, il VoIP non potrebbe avere futuro. La
qualità della voce, come è stato già sottolineato, è una funzione di diversi fattori come la latenza, il
23
ritardo, la variazione del ritardo (jitter), la perdita del pacchetto e altri… Con la rete PSTN tali
aspetti non rappresentano un problema. Si consideri ad esempio il jitter. Durante l’instaurazione di
una chiamata PSTN, viene creato un cammino di comunicazione dedicato tra i diversi commutatori
permettendo il passaggio della voce tra i partecipanti alla chiamata. Poiché c’è questo circuito
dedicato, il traffico voce impiegherà lo stesso tempo per raggiungere gli utenti in qualsiasi istante
della chiamata. Inoltre il jitter è praticamente assente. Sebbene la condizione di qualità della voce
inaccettabile possa essere categorizzata come un problema di disponibilità del servizio, in alcuni
casi l’abilità di creare tali condizioni è il risultato non della naturale congestione della rete ma di
un’azione volontaria, ad esempio i casi in cui degli utenti malintenzionati possano acquisire il
controllo di alcuni nodi della rete VoIP.
Tecnologie di sicurezza
Con lo scopo di sopperire alle mancanze di garanzie sulla sicurezza, per una rete VoIP si
possono adottare le tecnologie di sicurezza sviluppate per la rete IP. Sfortunatamente, di esse non
tutte sono adatte ad essere utilizzate in un ambito in cui i requisiti di qualità del servizio sono molto
stringenti, dovendo garantire la comunicazione di utenti in tempo reale. Si consideri ad esempio
l’utilizzo delle Virtual Private Network (VPN). Se utilizzate in una rete VoIP per crittografare le
informazioni di segnalazione e il flusso multimediale che gli utenti si scambiano, il processo di
crittografia da un lato e di decifrazione dall’altro introducono ulteriore latenza e degradano la
qualità della comunicazione. Una soluzione a tale problema potrebbe essere l’utilizzo della
crittografia direttamente tra i partecipanti della sessione, senza far intervenire gli elementi della
rete VoIP.
3.2 Attacchi ad un’architettura VoIP
Questa sezione introduce alcuni dei potenziali attacchi e vulnerabilità tipici di un ambiente
VoIP, includendo alcune delle vulnerabilità dei telefoni e switch VoIP. I rischi inerenti la sicurezza
delle informazioni possono essere classificate in senso lato nelle seguenti categorie: confidenzialità,
integrità e disponibilità. Ulteriori rischi rilevanti per gli switch sono rappresentati dalla frode e dalla
sicurezza fisica degli apparati di rete e dei dispositivi terminali.
Le reti a pacchetto devono parte del loro successo al largo numero di parametri configurabili:
indirizzo IP del dispositivo terminale, indirizzi dei router e dei firewall e software specifico – ad
esempio il Call Manager – utilizzato per gestire le chiamate. Molti di questi parametri vengono
definiti dinamicamente ogni qualvolta la rete viene avviata, o quando un telefono VoIP viene
accesso o aggiunto alla rete stessa. Poiché vi sono così tanti parametri configurabili
dinamicamente, un attaccante ha un’ampia gamma di potenziali punti vulnerabili da attaccare [13].
24
3.2.1 Confidenzialità
La confidenzialità consiste nel bisogno di mantenere le informazioni sicure e private. Per gli
utilizzatori domestici, questa categoria include dati personali, informazioni finanziarie e informazioni
riguardanti la sicurezza come le password. In ambito telecomunicazionistico, le intercettazioni
telefoniche sono una preoccupazione comune, ma la confidenzialità di altre informazioni deve
essere garantita per evitare frodi e attacchi che neghino il servizio. Gli indirizzi in una rete IP, il tipo
di sistema operativo, le estensioni del telefono per l’assegnazione dell’indirizzo IP e i protocolli di
comunicazione sono tutti esempi di quelle informazioni che, sebbene non facciano parte delle
informazioni riservate dell’utente, possono rendere la vita facile ad un attaccante.
Con la telefonia tradizionale, intercettare i dati dell’utente richiede o l’accesso fisico per mettere
sotto controllo una linea oppure l’accesso allo switch telefonico. Questa necessità di accedere
fisicamente alla rete da colpire aumenta notevolmente il rischio per l’intruso di essere scoperto.
Considerando che la telefonia PSTN ha molti meno punti di accesso di una rete VoIP, le
opportunità per un attaccante aumentano drammaticamente. Gli attacchi alla confidenzialità sono:
3.2.1.1
Switch Default Password Vulnerability
E’ frequente per gli switch avere configurata una password di accesso comune. Questa
vulnerabilità permette ad un attaccante che ottiene l’accesso di deviare le conversazioni verso altri
dispositivi e quindi di intercettare le chiamate. Dimenticarsi di cambiare le password di default è
uno degli errori più comuni tra gli utenti meno esperti.
3.2.1.2
Classical Wiretap Vulnerability
Utilizzare un programma di sniffing in un segmento della rete VoIP rende facile intercettare
il traffico voce. Una buona politica di sicurezza fisica riguardo l’installazione di apparati è il primo
passo verso il mantenimento della confidenzialità. Per esempio, il non utilizzare gli hub con i
telefoni IP o lo sviluppare un sistema di allarme che segnali all’amministratore quando un telefono
IP è stato disconnesso dalla rete permettono di rilevare questa classe di attacchi.
3.2.1.3
ARP Cache Poisoning e ARP Floods
Poiché l’accesso ad una rete VoIP può essere regolato attraverso un politica di
autenticazione, per aggirarlo l’attaccante può utilizzare dei messaggi ARP per avvelenare le ARP
cache dell’utente che vuole colpire. Un attacco di tipo ARP flood sullo switch può rendere la rete
vulnerabile agli attacchi che hanno lo scopo di origliare le comunicazioni altrui. Spedire in broadcast
messaggi di risposta ARP è sufficiente per corrompere molte ARP cache. Ciò permette di
reinstradare il traffico originalmente diretto verso un utente verso il dispositivo che si preferisce.
25
3.2.1.4
Web Server Interfaces
Sia gli switch che i dispositivi terminali VoIP dispongono tipicamente di un interfaccia web
server per la gestione locale o remota. Un attaccante potrebbe intercettare attraverso un
programma di sniffing per intercettare i messaggi HTTP che in chiaro e in maniera testuale
trasportano informazioni confidenziali. Questo potrebbe richiedere l’accesso alla rete locale oppure
alla rete in cui il server risiede. La soluzione a tale attacco consiste nell’utilizzare HTTPS come
protocollo per visualizzare le informazioni remote.
3.2.1.5
IP Phone Netmask Vulnerability
Un effetto del tutto simile all’ARP Cache Vulnerability può essere raggiunto assegnando la
maschera di rete e l’indirizzo IP di un gateway ad un IP Phone per fare in modo che molti o tutti i
pacchetti che esso trasmette passino attraverso il dispositivo in possesso dell’attaccante. Un
meccanismo di filtraggio dei pacchetti attraverso un firewall riduce di molto la probabilità di
successo di questo attacco.
3.2.2 Integrità
Mantenere integra un’informazione trasportata in una rete significa che l’informazione non
può essere alterata da utenti non autorizzati. Gli apparati di una rete di telecomunicazioni devono
proteggere l’integrità dei dati dei loro sistemi e le proprie relative configurazioni. A causa della
ricchezza di funzionalità disponibili su uno switch, un attaccante che dovesse compromettere la
configurazione del sistema potrebbe compiere facilmente ogni tipo di azione maliziosa. Per esempio
l’atto di modificare le informazioni utilizzate da una rete VoIP per la consegna dei pacchetti risulta
un attacco di negazione del servizio.
I sistemi di sicurezza, se violati, garantiscono ad un utente malintenzionato di utilizzare ed abusare
di un sistema. Cioè, la compromissione del sistema di sicurezza che protegge una rete non solo
consente l’utilizzo senza regole delle risorse, ma permette l’eliminazione di tutte quelle tracce che
potrebbero far risalire all’attaccante e permette anche l’installazione di trapdoors, ossia di falle del
sistema attraverso cui si può riottenerne il controllo nelle visite future. Per questa ragione, i sistemi
di sicurezza devono essere oculatamente gestiti.
Gli attacchi all’integrità delle informazioni possono essere frutto di azioni accidentali o veri e propri
atti intenzionali. Questo utilizzo improprio delle funzioni del sistema può essere causato da utenti
interni o intrusi. Un utente interno può effettuare una operazione incorretta o non autorizzata e
causare la modifica, distruzione o cancellazione dei dati o dei programmi di gestione della rete.
Questo attacco può essere causato da diversi fattori, tra i quali la possibilità che il livello dei
26
permessi assegnati a quel particolare utente è troppo alto rispetto a quello di cui l’utente avrebbe
effettivamente bisogno.
Mentre per quanto riguarda gli utenti non autorizzati, gli intrusi, possono cercare di mascherarsi da
utenti interni e accedere a tutte quelle operazioni che sono loro permesse. In questo caso vi sono
diversi attacchi estremamente pericolosi, alcuni dei quali costituiscono una vera e propria crisi del
sistema. Per esempio, un intruso può utilizzare il livello dei permessi garantiti all’utente legittimo e
danneggiare delle funzioni quali acquisire dati confidenziali, causare il deterioramento del servizio
attraverso la modifica del software degli switch, spegnere da remoto gli switch e rimuovere tutte le
tracce della propria intrusione.
3.2.2.1
DHCP Server Insertion Attack
Spesso è possibile cambiare la configurazione di un telefono sfruttando il protocollo DHCP
che viene utilizzato all’accensione. Infatti, nel momento in cui un telefono IP viene acceso, esso
genera una richiesta DHCP in broadcast affinché gli vengano assegnati dei parametri necessari al
proprio utilizzo, in questo momento un attaccante può consegnargli una risposta DHCP contenente
false informazioni.
Questo tipo di attacchi consentono di ottenere quello che viene definito un man in the middle
attack, ossia l’attaccante può essere un nodo che si interpone nella comunicazione di due utenti
ignari. Alcuni dei metodi che permettono tali attacchi si basano sul fatto che sia possibile riavviare
il telefono da remoto attraverso tecniche come il ping flood, MAC spoofing, etc…
3.2.2.2
TFTP Server Insertion Attack
E’ possibile cambiare le impostazioni di un telefono IP spacciandosi per il server TFTP che
fornisce i parametri di configurazione ai dispositivi terminali. Un TFTP server falso può fornire
informazioni maliziose prima che il server legittimo sia in grado di rispondere alla richiesta. Questo
metodo consente ad un attaccante di cambiare i parametri di configurazione di un telefono IP.
3.2.3 Disponibilità e Negazione del Servizio
La disponibilità consiste nel mantenere accessibili le informazioni e i servizi agli utenti. La
disponibilità è uno dei rischi maggiori per uno switch; gli attacchi che sfruttano le vulnerabilità
infatti nel software o nei protocolli di un apparato di rete possono portare alla degradazione delle
prestazioni e quindi alla negazione del servizio della porzione di rete servita. Una rete Voice over IP
presenta maggiori debolezze da questo punto di vista rispetto ad una normale rete dati.
Considerando infatti che i sistemi anti-intrusione (Intrusion Detection System – IDS) a volte
falliscono nell’intercettare degli attacchi allo stack TCP/IP, un attaccante può sfruttare questa
debolezza del sistema per colpire la rete VoIP.
27
Ogni rete può essere considerata vulnerabile agli attacchi Denial of Service, semplicemente
sovraccaricando le capacità del sistema. Con un sistema VoIP il problema è particolarmente grave,
poichè la qualità del servizio offerto dipende fortemente dalla perdita dei pacchetti e dal ritardo.
Quindi una rete che introduce un ritardo superiore ai 150msec per il traffico in una direzione [14] o
una perdita di pacchetti superiore al 3% [15] è considerata inaffidabile.
3.2.3.1
CPU Resource Consumption Attack
Un attaccante che abbia la possibilità di accedere da remoto ad un server può essere in
grado di forzare il riavvio del sistema (shutdown all/restart all) inserendo il massimo numero di
caratteri possibili per il login e password buffer in tentativi a ripetizione. Infatti alcuni telefoni IP si
riavviano dopo che viene eseguito un attacco di questo tipo.
Inoltre per provocare il riavvio di un sistema, la fase di ripristino delle impostazioni iniziale può
introdurre dei cambiamenti non voluti dall’amministratore o addirittura re-inizializzare alcune
proprietà, ad esempio le password di sistema. L’utilizzo di firewall che non permettono la
connessione da reti sconosciute rappresenta il primo passo per risolvere tale problema. Comunque
rimane la possibilità per l’attaccante di modificare l’indirizzo MAC e IP dei pacchetti che utilizza per
perpetrare l’attacco in modo che non siano scartati dal firewall.
3.2.3.2
Default Password Vulnerability
E’ comune trovare nei nodi di rete delle password di default (ad esempio admin o root).
Similmente i telefoni VoIP hanno spesso una sequenza di default come password e che può essere
utilizzata per sbloccare e poi modificare le informazioni contenute. Questa vulnerabilità permette
ad un attaccante di controllare la topologia della rete da remoto, consentendogli di perpetrare non
un attacco denial of service alla rete completa, ma attraverso un attacco di tipo port mirroring alla
singola locazione della vittima, può acquisire l’abilità di intercettare ogni comunicazione che ha
inizio dal terminale compromesso. Inoltre, lo switch della rete generalmente ha un’interfaccia web
attraverso cui è possibile configurare le impostazioni, ma essa rappresenta una vulnerabilità
giacché permette che anche utenti non esperti siano in grado di modificarle.
In molte architetture VoIP i telefoni IP scaricano la propria configurazione all’avvio da un server
TFTP o attraverso protocolli simili. Queste configurazioni specificano ad esempio l’indirizzo del Call
Manager o del SIP Proxy Server in modo che ogni utente sia in grado di instaurare una
comunicazione. Ma poiché il protocollo TFTP non ha alcuno strumento che ne garantisca la
sicurezza è facile per un attaccante spacciarsi per un server TFTP e caricare nei terminale che ha
scelto come vittime una configurazione in cui egli stesso risulta SIP Proxy Server. In questo modo
controlla il flusso delle chiamate delle vittime o può intercettarne il contenuto.
28
In conclusione, cambiare la password di default è cruciale, ma anche disabilitare l’interfaccia
grafica di gestione dei nodi di rete è una buona pratica di sicurezza, in quanto spesso le
informazioni di amministrazione gestite vengono trasmesse nella rete in chiaro.
3.2.3.3
Exploitable software flaws
E’ stato riscontrato [13] che i sistemi VoIP, sono sensibili a vulnerabilità di tipo “buffer
overflows” ed “improper packet header handling”. Questo tipo di imperfezioni sono causate da una
cattiva valutazione delle informazioni. Le imperfezioni software possono causare vulnerabilità
riconducibile principalmente a due tipi:
•
Denial of Service
•
Rivelazione di parametri critici sui sistemi
Attacchi di tipo DoS, sono attuabili anche da remoto, inviato pacchetti TCP, con header malformati,
producendo crash di sistema, memory dump in cui un aggressore puo’ rinvenire informazioni
rilevanti come password, ed indirizzamento IP di altri sistemi. Inoltre, buffer overflow che
permettono l’introduzione di codice malizioso sono stati scoperti in software VoIP [13], come del
resto in molte altre applicazioni.
3.2.3.4
Account Lockout Vulnerability
Un attacker, può tentare innumerevoli tentativi di login, con lo scopo di bloccare l’account
utente, compromettendo lo svolgimento regolare delle attività. Questa vulnerabilità è comune ai
sistemi protetti da password, poiché non consente ad un attaccante di accedere attraverso il
tentativo di tutte le possibili combinazioni di caratteri finché viene immessa la password corretta. In
questo modo l’accesso viene vietato anche all’utente legittimo se prova a collegarsi da remoto.
29
4
Vulnerabilità di SIP e RTP
SIP è un protocollo che richiede molti sforzi e implementazioni affinché lo si possa rendere
sicuro. L’utilizzo di dispositivi intermediari – come i Proxy Server, i Registrar Server e i Redirect
Server – le relazioni di fiducia con diverse sfaccettature tra componenti, l’utilizzo di elementi cui
non è richiesto alcuna relazione di fiducia e l’utilizzo da utente a utente rendono la sicurezza
difficile da implementare in una rete VoIP. Sono necessarie infatti delle soluzioni applicabili nei
molti scenari in cui il protocollo SIP è utilizzabile, si pensi ad esempio ad Internet, le reti IP wireline
o quelle wireless. La varietà di usi che si possono fare di questo protocollo quindi comportano la
necessità di uno studio di soluzioni alle esigenze di sicurezza. Per fare ciò, devono essere
identificati particolari meccanismi a seconda dei differenti aspetti e usi del SIP.
Un concetto molto importante da sottolineare è che la sicurezza della segnalazione SIP non inficia
in alcun modo la scelta delle implementazioni di sicurezza del protocollo di trasporto del flusso
multimediale utilizzato, ad esempio RTP (Real-Time Transfer Protocol). Cioè ogni flusso media può
essere
crittografato
dall’utente
sorgente
all’utente
destinatario
indipendentemente
dalla
segnalazione SIP ad esso associata.
4.1 SIP
4.1.1 Hijacking
4.1.1.1
Registration Hijacking
Scopo di questo attacco è modificare le associazioni nel Registrar Server di un dominio per
dirottare le successive richieste di instaurazione di sessioni verso l’attaccante.
Il meccanismo di registrazione di SIP permette ad uno UA di identificarsi come terminale sul quale
un utente con un particolare address-of-record desidera ricevere le chiamate. La richiesta SIP
REGISTER è utilizzata proprio a questo scopo, infatti contiene un campo addizionale
dell’intestazione (Contact) in cui è specificata l’URL che l’utente vuole registrare e quindi su cui
vuole essere raggiunto. L’operazione di registrazione crea quindi delle associazioni (binding) tra
address-of-record URI e Contact address in un Location Service che gestisce un particolare
dominio. Perciò quando un Proxy Server dello stesso dominio riceve una richiesta in cui la Request-
30
URI coincide con l’address-of-record registrata nel Location Service, il Proxy inoltrerà tale richiesta
al Contact address associato ad esso.
Poichè il Registrar Server si basa sull’address-of-record presente nel campo From della richiesta
REGISTER per verificare l’identità del mittente, allora l’attaccante modificando maliziosamente
questo campo può impersonare l’identità della vittima. Oppure l’attaccante può impersonare
l’identità di un utente che sia autorizzato a modificare le associazioni della vittima, secondo la
relazione della third-party registration, acquistando la possibilità di cancellare tutte le associazioni
presenti e inserire il proprio UAC come contatto appropriato, in modo da ricevere tutte le richieste
dirette alla vittima.
Se l’attaccante genera una richiesta REGISTER con campo To e From contenenti la SIP URI della
vittima e con il campo Contact contenente il proprio SIP URI, allora riesce a compromettere la
raggiungibilità della vittima sostituendosi ad essa. In [1] è specificato che i Registrar Server
dovrebbero accettare le registrazioni provenienti da un SIP URI se hanno sempre il valore del
campo Call-ID sempre uguale; ma tale raccomandazione non è vincolante. Quindi in questo caso
per l’attaccante non c’è la necessità di ricercare informazioni tramite sniffing poiché il Registrar
Server accetta le registrazioni con un qualsiasi valore del campo Call-ID.
Attacker
sip:[email protected]
192.0.3.103
Registrar Server /
Location Service
SIP Proxy
REGISTER sip:registrar.atlanta.com SIP/2.0
Via: SIP/2.0/UDP 192.0.1.101:5060
From: <[email protected]>;tag=12314534
To: <[email protected]>
Call-ID: [email protected]
CSeq: 1 REGISTER
Contact: <sip:[email protected]>
Content-Length: 0
Victim B
192.0.2.102
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.1.101:5060
To: <[email protected]>;tag=45243254
CSeq: 1 REGISTER
Content-Length: 0
INVITE sip:[email protected]
….
Query
Response
INVITE sip:victimA.atlanta.com SIP/2.0
Via: SIP/2.0/UDP proxy.atlanta.com
Via: SIP/2.0/UDP 192.0.2.102:5060
CSeq: 1 INVITE
Content-Type: application/sdp
Content-Length: 0
Figura 4.1 - Registration Hijacking: flusso di messaggi dell'attacco
31
Una volta inviato il REGISTER malizioso, ogni qual volta un utente cercherà di inviare un messaggio
di segnalazione alla vittima, il Proxy SIP riceverà come risposta alla query dal Location Server
l’indirizzo dell’attaccante. In questo modo quest’ultimo è in grado di intercettare tutte le chiamate
destinate alla vittima.
La traccia più evidente di questo attacco è il binding presente nel Location Server in cui è associato
come address-of-record della vittima la SIP URI dell’attaccante. La vittima può controllare
agevolmente i binding associati al proprio address-of-record inviando una richiesta REGISTER in cui
è assente il campo Contact, a cui il Registrar risponderà con un 200 OK in cui sono presenti tutti i
contatti associati al proprio address-of-record.
4.1.1.2
3XX Response code messages
Scopo di questo attacco è divenire l’utente chiamato, sostituendosi al legittimo destinatario
delle richieste SIP.
Le response di tipo 3XX forniscono informazioni sulla nuova localizzazione dell’utente, o su servizi
alternativi che possono aiutare ad instaurare la sessione SIP. In particolare la response 301 Moved
Permanently viene generata dai Server in risposta ad una richiesta la cui Request-URI indica un
indirizzo per cui un utente non può essere più trovato. Lo UAC quindi dovrebbe inviare una
richiesta analoga ma all’indirizzo fornito nel campo Contact della response 301 Moved Permanently.
Lo UAC inoltre dovrebbe aggiornare tutti i contatti che conserva in memoria con questo nuovo
valore e indirizzare tutte le future richieste a questo indirizzo.
Se da un lato la successione dei messaggi da inviare in questo tipo di attacco è abbastanza
semplice, dall’altro la tempestività con cui si generano riveste un ruolo molto importante. Un
secondo aspetto da sottolineare è che in questo caso la localizzazione dell’attaccante non
condiziona in alcun modo il successo dell’attacco, ossia può far parte indifferentemente della rete
del chiamante, della rete del chiamato che delle eventuali reti che si frappongono fra esse;
importante è comunque che l’attaccante riesca a sniffare il traffico delle vittime in modo da agire
tempestivamente. Nell’esempio mostrato in figura, l’attaccante riesce a captare un messaggio di
INVITE diretto al legittimo destinatario. Prima che questo risponda, l’attaccante genera una
risposta di tipo 301 Moved Permanently i cui valori dei campi From, To e Call-ID sono gli stessi
della richiesta intercettata. Ad essi aggiunge un nuovo campo Contact in cui specifica il proprio SIP
URI. Quando la vittima riceve tale risposta aggiornerà la lista dei contatti in modo l’attaccante sarà
il destinatario di tutte le richieste future dirette in realtà alla seconda vittima.
32
Attacker
192.0.3.103
4) 301 Moved Permanently
B
ictim
ITE V
V
N
I
6)
im B
Vict
VITE rying
N
I
1)
B
00 T
2) 1 E Victim
T
I
NV
5) I
3) INVITE Victim B
Victim B
192.0.2.102
Victim A
192.0.1.101
Figura 4.2 - 3XX Response code messages: 301 Moved Permanently
Si può ottenere un risultato analogo qualora l’attaccante generasse una risposta di tipo 302 Moved
Temporarily, caso in cui associato al contatto nel campo Contact può esserci un valore di validità
temporale. Sia i Proxy Server che gli UA possono memorizzare tale SIP URI per la durata
dell’intervallo temporale, scaduto il quale va scartato. Qualora non fosse specificato alcun intervallo
di validità, l’indirizzo sarebbe valido unicamente per la richiesta successiva di tale richiesta e non
dovrebbe assolutamente essere memorizzato.
Poiché gli UA sono progettati per gestire automaticamente le risposte di tipo 3XX, l’attacco avviene
in maniera del tutto trasparente alla vista dell’utente. L’unica traccia lasciata è costituita
dall’indirizzo IP dell’attaccante presente nel campo Contact della response 3XX e successivamente
memorizzata dall’UAC nella lista dei contatti. Poiché però un eventuale utilizzo del messaggio 302
Moved Temporarily, in cui non è specificato alcun intervallo di validità, non consente all’UAC di
memorizzare tale indirizzo, allora le tracce lasciate sarebbero nulle.
4.1.2 Man in the Middle
4.1.2.1
Impersonating a server: Proxy server
Scopo di quest’attacco è quello di impersonare il server del dominio di destinazione di una
richiesta per deviare la sessione verso l’attaccante.
Il dominio verso cui una richiesta è destinata è specificato nella Request-URI. Gli UA contattano
direttamente un server in questo dominio in modo che consegni esso stesso la richiesta al reale
destinatario. Bisogna considerare che c’è la possibilità che un attaccante riesca ad impersonare un
server remoto e quindi ad intercettare le richieste e le comunicazioni delle vittime. Mentre l’attacco
descritto nel paragrafo precedente, Registration Hijacking, compromette la correttezza delle
33
informazioni contenute nel Registrar Server, in attacchi di questo tipo, Man in the Middle, si
possono attaccare server di tipo Redirect o Proxy.
Come descritto in [7], si consideri il caso in cui uno UAC debba instaurare una sessione SIP con
uno UAS che si trova in un dominio differente, ad esempio domain.com. Per localizzare lo UAS, il
client o il Proxy Server che lo rappresenta deve fare una richiesta al DNS su quale protocollo, porta
ed indirizzo IP deve utilizzare per instradare la richiesta INVITE verso il dominio di destinazione. Se
il dominio di destinazione è servito da due Proxy SIP che supportano TCP, UDP e TLS su TCP allora
la risposta alla query DNS SRV sarà del tipo:
Quindi a seconda del protocollo prescelto, il client utilizzerà il Proxy Server sipserver1 o sipserver2
del dominio domain.com. Seguirà quindi una query DNS di tipo A per risolvere il nome simbolico in
indirizzo numerico.
domain.com
43200 IN A
10.0.0.30
sipserver1.domain.com
43200 IN A
10.0.0.31
43200 IN A
10.0.0.32
Se un attaccante riuscisse ad impersonare un server del dominio di destinazione, allora potrà
ricevere le richieste dirette allo UAS e, per operare da Man in the Middle, inoltrerà poi tali richieste
verso il legittimo destinatario con opportune modifiche, in modo da ricevere il flusso da entrambi i
versi di comunicazione.
Per perpetrare tale attacco l’attaccante deve avvelenare le tabelle del DNS server ad esempio
creando un nuovo server fittizio del dominio di destinazione che abbia priorità altissima, in modo
che sia scelto come prima risorsa:
34
In questo modo tutte le richieste destinate al domain.com passano attraverso il sipserver3. Per
completare l’opera, l’attaccante deve modificare anche i record di tipo A, in modo che il proprio
indirizzo IP sia associato al sipserver3:
domain.com
43200 IN A
10.0.0.30
43200 IN A
10.0.0.31
43200 IN A
10.0.0.32
43200 IN A
indirizzo IP attaccante
Quando la vittima, o il Proxy Server che la serve, interrogherà il DNS server riceverà come
destinatario per le richieste da inviare agli utenti del domain.com l’indirizzo dell’attaccante e quindi
manderà ad esso la richiesta di INVITE. Quando l’attaccante riceve tale messaggio SIP deve
modificarlo aggiungendo il campo Record-Route nell’intestazione con il proprio indirizzo IP. In
questo modo controllerà il flusso da entrambe le direzioni.
Victim A
192.0.1.101
DNS Server
2) Query
3) Response
Victim B
192.0.2.102
4) INVITE sip:
[email protected]
1) DNS Poisoning
Attacker
192.0.3.103
Figura 4.3 - Impersonating a Proxy server: l'attaccante modifica i record del DNS
Poiché però questo attacco funziona solamente se il protocollo di trasporto scelto dal client è TCP o
UDP, visto che un eventuale utilizzo di TLS su TCP vanificherebbe ogni sforzo dell’attaccante
essendo alcuni campi dell’intestazione crittografati, l’ultimo passo da compiere è quello di
scoraggiare l’utilizzo di TLS da parte dello UAC. Per fare ciò è necessario modificare i record NAPTR
del DNS in modo che TLS su TCP venga cancellato, ossia devono essere di questo tipo:
35
domain.com IN NAPTR 0 0 “s” “SIP+D2T” “” _sip._tcp.domain.com
domain.com IN NAPTR 0 0 “s” “SIP+D2U” “” _sip._udp.domain.com
In questo modo il client non potrà scegliere TLS visto che è assente il record NAPTR ad esso
associato e quindi tutta la sessione SIP sarà in chiaro.
In questo tipo di attacco le tracce lasciate sono molte. La prima è la modifica nel DNS server dei
record associati al dominio di destinazione delle richieste. Queste modifiche però non sono così
evidenti all’utilizzatore comune e quindi possono facilmente passare inosservate. Una seconda
traccia, molto più lampante, è costituita dal campo Record-Route aggiunto nella richiesta. Questo
campo, contenente l’indirizzo IP dell’attaccante, è visibile sia al legittimo destinatario della richiesta
che al suo mittente. A giocare a favore dell’attaccante c’è però il fatto che i campi Record-Route
sono frequentemente utilizzati dai Proxy Server che devono monitorare il traffico di un dominio, ad
esempio per questioni di tariffazione.
4.1.2.2
302 Response code message
Gli attacchi di tipo Man in the Middle descritti nei due prossimi paragrafi sfruttano la
semplice falsificabilità dei messaggi di risposta del tipo redirection (3XX). Infatti un utente
malizioso può facilmente far credere alla vittima che un messaggio SIP sia stato generato da un
SIP Registrar, da un Proxy Server, da un SIP Redirect Server o da un SIP UA.
In questo particolare caso l’attaccante genera un messaggio di tipo 302 Moved Temporarily in cui
si spaccia per l’utente destinatario della richiesta inviato dalla vittima.
Questo attacco ha quindi lo scopo di re-direzionare le richieste verso l’attaccante, che per agire da
Man in the Middle le inoltrerà poi verso il legittimo destinatario.
Analagomente al caso descritto nella sezione Hijacking, quando l’attaccante intercetta una richiesta
INVITE inviata dalla vittima, genera un risposta di tipo 302 Moved Temporarily. In particolare,
spacciandosi per l’utente chiamato, specifica nel campo Contact dell’intestazione che questi è
raggiungibile al proprio indirizzo IP. E’ importante notare che questa risposta deve essere ben
costruita dall’attaccante, cioè deve essere composta da tutti i parametri caratterizzanti la richiesta
originale inviata dall’utente chiamante: To, From e Call-ID. In questo modo quando l’utente
chiamante riceve questa risposta, lo UAC genera all’interno dello stesso dialogo un nuovo
messaggio di INVITE il cui destinatario a sua insaputa è proprio l’attaccante. Per operare da Man in
the Middle, quest’ultimo non deve far altro che inoltrare i messaggi che riceve verso il legittimo
destinatario e aggiungervi un campo di Record-Route in cui specifica il proprio indirizzo IP. Da
questo momento in poi tutte le richieste e le risposte relative a tale sessione SIP passeranno quindi
attraverso lo UA dell’attaccante.
36
Victim A
192.0.1.101
SIP Proxy
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.0.1.101:5060
CSeq: 1 INVITE
Contact: <sip:client1.atlanta.com>
Content-Length: 125
Attacker
192.0.3.103
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP 192.0.1.101:5060
CSeq: 1 INVITE
Content-Length: 125
Via: SIP/2.0/UDP 192.0.1.101:5060
CSeq: 1 INVITE
Content-Length: 125
Via: SIP/2.0/UDP 192.0.1.101:5060
CSeq: 1 INVITE
Record-Route: <sip:192.0.3.103;lr>
Content-Length: 125
Figura 4.4 - 302 Response code message: flusso dei messaggi di attacco
Quando l’attaccante genera un messaggio 302 Moved Temporarily indica in esso nel campo
Contact il proprio indirizzo IP, analogamente accade nel campo Record-Route del messaggio
inoltrato. Questi rappresentano le uniche tracce lasciate nella comunicazione dall’azione
dell’attaccante.
4.1.2.3
305 Response code message
Analogamente a quanto descritto nel paragrafo Impersonating a server: Proxy Server, scopo di
questo attacco è divenire il Proxy Server della vittima, utilizzando però unicamente messaggi SIP.
Quando uno UAC riceve una risposta di tipo 305 Use Proxy, significa che la risorsa che aveva
intenzione di contattare deve essere acceduta attraverso il Proxy specificato nel campo Contact.
37
Questo tipo di risposta può essere inviata solo da UAS e lo UAC che le riceve deve riformare un
nuova richiesta in base alle informazioni in essa contenute, ma tutte le successive richieste devono
essere generate normalmente.
L’attacco si svolge nelle seguenti fasi. Nel momento in cui la vittima genera un richiesta,
l’attaccante risponde con un messaggio 305 Use Proxy, spacciandosi per l’utente chiamato e
indicando nel campo Contact il proprio indirizzo IP come Proxy adatto ad inoltrare il messaggio. A
questo punto lo UAC della vittima rigenera una nuova richiesta indirizzandola verso l’attaccante,
che, analogamente ai casi visti precedentemente, deve inoltrare verso il legittimo destinatario.
Aggiungendovi inoltre il campo Record-Route nell’intestazione fa in modo che tutti i messaggi
relativi al dialogo passino attraverso di lui.
Victim A
192.0.1.101
SIP Proxy
Via: SIP/2.0/UDP 192.0.1.101:5060
CSeq: 1 INVITE
Content-Length: 125
Attacker
192.0.3.103
SIP/2.0 305 Use Proxy
Via: SIP/2.0/UDP 192.0.1.101:5060
CSeq: 1 INVITE
Contact: <sip:192.0.3.103>
Content-Length: 125
Via: SIP/2.0/UDP 192.0.1.101:5060
CSeq: 1 INVITE
Content-Length: 125
Via: SIP/2.0/UDP 192.0.1.101:5060
CSeq: 1 INVITE
Record-Route: <sip:192.0.3.103;lr>
Content-Length: 125
Figura 4.5 - 305 Response code message: flusso dei messaggi di attacco
38
Poiché la risposta 305 ha validità solamente per la richiesta a cui si riferisce, il client che la riceve
non memorizza assolutamente il campo Contact che indica l’indirizzo IP dell’attaccante. Per questo
motivo la vittima non dovrebbe accorgersi dell’attacco che sta avvenendo. L’unica traccia che indica
l’intrusione di un client non autorizzato nella comunicazione di segnalazione è costituita dal campo
Record-Route inserito dall’attaccante.
4.1.2.4
Impersonating a server: Registrar server
Scopo di quest’attacco è di impersonare lo UAS che riceve l’invito alla partecipazione ad
una comunicazione avvelenando il Location Service del dominio di appartenenza della vittima.
Un utente malizioso può inviare messaggi di risposta spacciandosi per il Registrar Server del
dominio cui appartiene la vittima. Agire da Man in the Middle in questo modo evita di prestare
continuamente attenzione al traffico di segnalazione che le due vittime si scambiano, mentre è
sufficiente concentrare l’attenzione unicamente nella fase preliminare di registrazione dello UAC
della vittima.
Nel momento in cui intercetta una richiesta REGISTER, l’attaccante tempestivamente deve
rispondere con un 301 Moved Permanently attraverso cui, spacciandosi per il reale Registrar
Server, specifica il proprio indirizzo come quello corretto per verso cui mandare le nuove richieste
di registrazione. Parallelamente a questi eventi, l’attaccante deve inoltre inviare una richiesta
REGISTER al reale Registrar Server, spacciandosi per la vittima.
Attacker
Location
Service
2) 301 Moved Permanently
6) 401 Unauthorized
7) REGISTER con
credenziali per
l’autenticazione
4) REGISTER’’
5) 401 Unauthorized
8) REGISTER con credenziali
della vittima
9) Store
3) REGISTER’
1) REGISTER
Victim A
Registrar
Server
Figura 4.6 - Impersonating a Registrar Server
39
I Registrar Server generalmente richiedono l’autenticazione dei client che si vogliono registrare ad
un dominio e quindi risponderà con un messaggio 401 Unauthorized in cui sono specificati tutti i
campi necessari a fare ciò – Nonce, Realm, Algorithm... A questo punto lo UAC della vittima,
credendo l’attaccante il Registrar Server del dominio, spedirà ad esso una nuova richiesta di
registrazione. All’attaccante non resta che inoltrare verso la vittima il messaggio 401 per ottenere
come risposta le credenziali necessarie a registrarsi a nome della vittima. Quando dunque
arriveranno al Proxy Server che gestisce il dominio delle richieste indirizzate verso la vittima, esso,
interrogando il Location Service, otterrà come risposta l’indirizzo dell’attaccante. Ad esso non basta
che inoltrare tali messaggi verso il reale destinatario per essere il Man in the Middle.
Le tracce lasciate in quest’attacco sono alquanto evidenti, dato che nel Location Service è
memorizzato il binding relativo al contact address dell’attaccante. Ovviamente però tali tracce non
sono permanenti, giacchè se tali binding non vengono aggiornati periodicamente, allo scadere di
un intervallo stabilito vengono cancellati definitivamente.
4.1.3 Denial of Service
4.1.3.1
Tearing down a session
L’obiettivo di questo attacco è abbattere un dialogo o una sessione SIP senza farne parte.
Si considera il caso in cui un utente malizioso riesce ad ottenere, attraverso un’attività di sniffing, i
parametri che i partecipanti ad un dialogo SIP si stanno scambiando nei messaggi di instaurazione:
Call-ID, To e From. La fase di instaurazione della comunicazione è costituita dalla richiesta di
INVITE generata dall’utente chiamante, dalla risposta – eventualmente affermativa – di tipo 200
OK generata dall’utente chiamato e infine dalla conferma di avvenuta ricezione e accettazione dei
parametri della sessione attraverso la richiesta ACK generata anch’essa dal chiamante. In questo
scambio di messaggi il chiamante stabilisce il valore del campo Call-ID dell’intestazione e del
campo Tag all’interno del campo From dell’intestazione. Il chiamato completa la tripletta che
identifica il dialogo SIP aggiungendo alla risposta 200 OK il campo Tag all’interno del campo To
dell’intestazione. Questi tre parametri identificano univocamente il dialogo SIP che è stato
instaurato, ed ogni messaggio che modifica tale dialogo deve avere questi parametri.
Per questo motivo, l’attaccante generando un messaggio di BYE – che termina i dialoghi SIP –
deve inserire i parametri della sessione che vuole abbattere. A questo punto l’abbattimento della
sessione è avvenuta solamente in una direzione perchè un client non ha ricevuto alcun messaggio
ed è quindi convinto che la comunicazione sia ancora in atto. Per abbattere completamente la
sessione e quindi evitare che rimanga pendente, l’attaccante deve mandare un messaggio di BYE al
40
chiamato ed uno al chiamante, spacciandosi per il chiamante nel primo caso e per il chiamato nel
secondo.
SIP Proxy
SIP Proxy
200 OK
200 OK
200 OK
200 OK
200 OK
200 OK
Victim B
Victim A
BYE da Victim B
Attacker
BYE da Victim A
Figura 4.7 - Tearing down a session: BYE verso le due vittime
In questa tipologia di attacco non vi sono tracce lasciate dall’utente malizioso, giacchè tutti gli
indirizzi – a livello IP e a livello applicativo (SIP) – sono falsificati.
4.1.3.2
Modifying a session
Lo scopo di questo attacco è fare in modo che i due partecipanti ad una sessione SIP,
attraverso una transazione di re-INVITE, non riescano più a fruire dei contenuti multimediali perchè
utilizzano codificatori audio differenti
Il three-way-handshake che inizializza un dialogo SIP – INVITE, 200 OK e ACK - consente agli UA
di negoziare i parametri della sessione multimediale. Questa negoziazione avviene attraverso lo
scambio di messaggi SDP [11] tra lo UAC e lo UAS. Ossia, lo UAC allega all’INVITE iniziale un
messaggio SDP in cui elenca tutti i media capabilities che è in grado di supportare, le porte per
RTP e RTCP su cui vuole ricevere il flusso multimediale ed altre informazioni. Lo UAS risponde con
un 200 OK in cui è impacchettato un messaggio SDP contenente la media capability che supporta e
le porte RTP/RTCP.
Il protocollo SIP prevede che questi parametri possano essere contrattati anche durante lo
svolgimento di una sessione, e non solo durante la fase iniziale, inviando una nuova richiesta di
INVITE all’interno del dialogo SIP esistente. Questo messaggio viene appunto detto re-INVITE. Sia
il chiamante che il chiamato possono inviare un re-INVITE. Qualora venissero proposti dei
parametri che la controparte non è in grado di supportare, la proposta viene rifiutata attraverso
una risposta di tipo 488 Not Acceptable Here. La sessione SIP non risentirebbe del fallimento del
re-INVITE perchè i parametri rimangono quelli nell’ultima proposta negoziata ed accettata. Se, al
contrario, i parametri vengono accettati dalla controparte la procedura si conclude con una risposta
200 OK e un ACK, analogamente a quanto accade nella fase di start-up.
41
Si considera anche in questo caso uno scenario in cui l’attaccante riesca a catturare il traffico che
inizializza la sessione SIP, in modo da carpire i parametri che caratterizzano il dialogo. Qualora lo
UAC proponesse più media capabilities allo UAS, l’attaccante può sfruttare queste informazioni una
volta che la sessione è instaurata inviando allo UAC un re-INVITE spacciandosi per lo UAS. In caso
contrario l’attaccante può notificare nella re-INVITE un cambio di porta o di protocollo di trasporto,
giungendo allo stesso esito. La vittima – lo UAC – accetterà tali cambiamenti inviando verso lo UAS
una risposta 200 OK all’INVITE. A questo punto l’attaccante per renderli effettivi, deve confermare
il tutto attraverso un messaggio di ACK, spacciandosi sempre per lo UAS. Da questo momento in
poi la rinegoziazione dei parametri rende incomprensibile o irraggiungibile il flusso multimediale ai
due partecipanti alla sessione.
Attacker
192.0.3.103
Victim A
192.0.1.101
Via: SIP/2.0/UDP 192.0.2.102:5060
CSeq: 1 INVITE
Contact: <sip:client1.biloxy.com>
Content-Length: 139
...
m=audio 49100 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 49172 RTP/AVP 32
a=video 0 49200 RTP/AVP 32
...
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.102:5060
CSeq: 1 INVITE
Contact: <sip:client.atlanta.com>
Content-Length: 125
Victim B
192.0.2.102
...
m=audio 44100 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 44200 RTP/AVP 32
a=video 0 49200 RTP/AVP 32
...
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.0.2.102:5060
CSeq: 1 ACK
Content-Length: 0
Figura 4.8 - Modifying a session: fase di attacco
Anche in questo attacco non vi sono tracce evidenti lasciata dall’azione dell’utente malizioso, visto
che la sua è un’azione completamente cieca. Ossia non può avere riscontro del successo del
proprio tentativo di attacco, perchè falsificando i propri indirizzi con quelli dei partecipanti alla
sessione ad esso non ritorna alcuna conferma o messaggio di risposta. Solo dall’attività di sniffing è
in grado di verificare l’avvenuto successo o meno della sua azione.
42
4.1.3.3
Cancelling a session
Lo scopo di questo tipo di attacchi è rendere irraggiungibile un particolare UA cancellando
le richieste di sessioni che gli pervengono o che vengono da esso generate.
La richiesta CANCEL, come lo stesso nome indica, è utilizzata dagli UAC per cancellare una richiesta
precedentemente inviata [1]. Specificatamente, è un comando indirizzato allo UAS destinatario
della prima richiesta di interrompere ogni operazione ad essa collegata e di generare come risposta
un messaggio di errore. La richiesta CANCEL non ha ovviamente alcun effetto su una richiesta per
cui lo UAS abbia già generato una risposta definitiva (non 1XX). Perchè quindi una CANCEL abbia
effetto, deve essere legata ad una richiesta che richiede molto tempo per essere processata. In [1]
viene specificato che l’unica richiesta che richiede molto tempo di processamento è l’INVITE.
Anche in questo caso l’azione di sniffing dell’attaccante sul traffico della vittima è basilare. Questa
fase è resa necessaria dall’importanza dei parametri che caratterizzano un dialogo SIP e dalla
necessità di tempestività che tale attacco richiede. Quando lo UAS vittima riceve una richiesta
INVITE da parte di un qualunque UAC, l’attaccante deve inviare una richiesta di CANCEL ad essa
riferita – e con ciò si intende che i parametri del dialogo delle due richieste devono coincidere – in
modo da rendere impossibile l’instaurazione di una sessione SIP.
Victim B
192.0.2.102
Victim A
192.0.1.101
Via: SIP/2.0/UDP 192.0.1.101:5060
CSeq: 1 INVITE
Content-Length: 139
Attacker
192.0.3.103
CANCEL sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.0.2.102:5060
CSeq: 2 CANCEL
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.102:5060
CSeq: 2 CANCEL
Content-Length: 0
Figura 4.9 - Cancelling a session: fase di sniffing e attacco
43
La tempestività è importante perchè lo UAS accetta tale CANCEL solo se non ha ancora inviato una
risposta definitiva (non 1XX) alla richiesta INVITE.
Un attacco Denial of Service attraverso il metodo CANCEL può essere diretto non solo verso chi
riceve degli inviti ad instaurare sessioni, ma anche verso chi li genera. Ossia, se il primo tipo di tale
attacco ha l’intento di rendere irraggiungibile uno UAS da tutti gli altri client, quest’altro tipo ha lo
scopo di far fallire tutti i tentativi di un particolare UAC di instaurare sessioni SIP. Per fare ciò,
l’attaccante deve sniffare il traffico generato da un particolare UAC e spedire delle CANCEL
falsificate dirette agli UAS che quell’UAC ha contattato.
Analogamente con alcuni attacchi descritti precedentemente, visto che la richiesta di cancellazione
contiene indirizzi falsificati non vi sono tracce lasciate dall’attaccante.
4.1.3.4
SIP DoS attack and amplification
Lo scopo di questo attacco è rendere inutilizzabile un elemento o l’intera rete.
Gli attacchi Denial of Service hanno lo scopo di rendere non disponibile un particolare elemento
della rete, generalmente indirizzando verso di esso una quantità di traffico che non riesce a
processare. Appare quindi evidente che l’esito di questo tipo di attacchi è strettamente legato alle
scelte implementative dello UA vittima.
Un attacco appartenente a questa classe consiste nell’inviare numerose richieste contraffatte
contenenti un indirizzo di sorgente falsificato ed un valore del campo Via dell’intestazione che
identifica l’host della vittima come uno dei nodi che ha processato tali richieste. Per creare un
Denial of Service dello UA vittima, l’attaccante deve inviare questa richiesta a diversi destinatari
esistenti – UA o server – i quali rispondendo creeranno una quantità di traffico tale da rendere la
macchina della vittima inutilizzabile.
In maniera del tutto simile l’attaccante può mandare delle richieste contraffatte in cui inserisce nel
campo Route dell’intestazione l’indirizzo della vittima ai Proxy Server che biforcano le richieste.
Infatti un Proxy Server, quando processa una richiesta, può inoltrarla a diverse location dell’utente
allo stesso tempo. Questo tipo di ricerca parallela è conosciuta come forking. La caratteristica del
forking è che ogni richiesta che viene inoltrata a più di una location deve essere gestita stateful,
ossia il Proxy Server deve mantenere uno stato della richiesta in memoria. In questo modo i Proxy
Server amplificano il numero di messaggi inviati alla vittima.
Anche il campo Record-Route dell’intestazione può essere utilizzato per questo tipo di attacchi.
Quando infatti un attaccante è certo che il dialogo SIP iniziato da una sua richiesta contraffatta
44
provoca un voluminoso traffico nel verso opposto, può inserire nel campo Record-Route l’indirizzo
della vittima, che quindi riceverà una quantità notevole di traffico indesiderato.
Una tipologia di attacchi appartenenti a questa tipologia hanno successo perchè le richieste
REGISTER non richiedono l’autenticazione di chi le genera. Un attaccante può infatti cancellare i
bindings della vittima o addirittura di tutti i componenti di un dominio per renderli completamente
irraggiungibili. Oppure si consideri il caso in cui un utente malizioso riesca a registrare il contact
address della vittima come address-of-record di numerosi utenti della rete, rendendo il Registrar
Server una sorta di amplificatore dei messaggi.
Visto che l’attaccante in ogni messaggio che genera falsifica l’indirizzo di sorgente, non vi sono
tracce evidenti dell’attaccante. Resta comunque il fatto che generare troppo traffico da una stessa
sorgente può risultare molto sospetto ad elementi di rete come IDS.
Via: SIP/2.0/UDP 192.0.1.101:5060
Via: SIP/2.0/UDP 0.0.0.0:5060
CSeq: 1 INVITE
Contact: <sip:client.site.com>
Content-Length: 139
Victim A
192.0.1.101
Attacker
192.0.3.103
Figura 4.10 - SIP DoS attack
4.1.3.5
Response code messages
Un attaccante può utilizzare diversi tipi di response allo scopo di introdurre delle condizioni
di Denial of Service di uno UA. In base alla classificazione specificata in [1] le classi di risposte che
possono essere utili a questo scopo sono le ultime tre, ossia:
¾
4XX Request Failure – sono messaggi inviati da un particolare server dopo che il
processamento di una richiesta, che contiene un errore di sintassi o non può essere processata
dal server stesso, fallisce
¾
5XX Server Failure – il server non è riuscito a processare una richiesta apparentemente
corretta
¾
6XX Global Failure – indica che un server ha delle particolari informazioni di un utente che
possono differire da quelle indicate nella richiesta
45
Questo tipo di risposte possono contenere un campo dell’intestazione – Contact – che indica la
locazione dove è possibile reperire ulteriori informazioni sull’errore segnalato.
Sniffando il traffico dello UAC scelto come vittima, l’attaccante per perpetrare tale tipo di attacco
deve inviare ad esso una risposta di errore ogni volta che generi una richiesta. Ovviamente a
seconda che si scelga risposte di tipo 4XX, 5XX o 6XX si deve falsificare l’indirizzo di sorgente delle
risposte o come quello del destinatario della richiesta o come di un Proxy Server che serve la
vittima. Inoltre tutti i parametri che caratterizzano il dialogo SIP, cioè il Tag locale e remoto, il CallID devono coincidere tra richiesta generata dallo UAC vittima e risposta dell’attaccante, altrimenti
la risposta maliziosa verrà scartata dallo UAC. La richiesta della vittima giungerà comunque alla
destinazione legittima, che dopo averla processata, produrrà una risposta. Questa quando giungerà
allo UAC vittima verrà considerata un errore e quindi scartata, visto che ha già ricevuto una
risposta definitiva – quella maliziosa dell’attaccante. Se viene ripetuto tale processo per ogni
richiesta, l’attaccante riuscirà ad isolare la vittima producendo un Denial of Service.
Victim A
1) Request SIP
2) 4XX, 5XX o
6XX Response
Attacker
Figura 4.11 - DoS: response code messages
Poichè l’attaccante falsifica l’indirizzo di sorgente delle rispose maliziose, la vittima non ha
possibilità di scoprire chi abbia mandato tali messaggi e quindi non può scoprire l’identità
dell’attaccante.
4.1.3.6
Toll Fraud
Generalmente per le operazioni di tariffazione – billing – si utilizzano Proxy Server Stateful,
quindi attaccare tali server può consentire di utilizzare il servizio a pagamento in maniera gratuita.
Attacchi di questo tipo sono specifici della particolare implementazione di billing. Si possono ad
esempio sfruttare delle vulnerabilità del software utilizzato per penetrare nel sistema e configurare
46
maliziosamente le politiche di billing. Scopo di questa sezione è quindi non descrivere tali attacchi,
ma sottolineare come i Proxy Server che afferiscono a tali scopi sono elementi della rete
particolarmente attraenti per gli attaccanti. Le informazioni di billing si basano sui Call Detail
Recording (CDR), ossia delle informazioni sulle chiamate. L’instaurazione e l’abbattimento delle
chiamate, che avvengono attraverso dei messaggi SIP che vengono processati dai Proxy Server del
dominio, aggiornano tali CDR per poter calcolare la tariffazione da applicare all’utente. Ovviamente
per fare ciò, la segnalazione deve passare per determinati Proxy Server che aggiornano i CDR. E’
importante sottolineare che il percorso che la segnalazione SIP impiega può essere diverso da
quello del flusso multimediale, e quindi i Proxy Server coinvolti nella segnalazione possono essere
evitati dal traffico voce – ad esempio pacchetti RTP/RTCP. Un modo semplice per evitare di
aggiornare i CDR è quello di incapsulare la segnalazione SIP in messaggi RTP o RTCP. Questo
ovviamente prevede che entrambi i terminali di comunicazione dispongano di applicazioni
particolari che sappiano decapsulare i messaggi SIP da quelli RTP o RTCP e successivamente
processarli. In questo modo il Proxy Server non processa alcun messaggio di segnalazione tra i due
partecipanti alla comunicazione e quindi non è disponibile alcuna informazione per aggiornare i
CDR.
4.2 RTP
4.2.1 Man in the Middle
4.2.1.1
Modifying IP address
L’obiettivo di questo attacco è interporsi tra gli utenti che partecipano ad una
comunicazione attraverso la generazione di un messaggio di re-INVITE in cui si modificano i
parametri del dialogo, in particolare l’indirizzo IP.
Più precisamente, un utente malizioso può iniziare una procedura di re-INVITE con un utente
coinvolto in una sessione SIP spacciandosi per la controparte e dichiarare che l’indirizzo IP in cui
desidera ricevere il flusso multimediale è cambiato e fornire il proprio come quello nuovo. Appare
evidente che se l’attaccante riuscisse a cambiare questi parametri con entrambe le parti coinvolte
nella sessione allora riceverebbe il flusso multimediale da entrambe le direzioni della
comunicazione. Per completare l’attacco di Man in the Middle deve ovviamente inoltrare il traffico
verso i legittimi destinatari in modo che l’intrusione non venga rilevata.
47
Anche questo attacco necessita una fase preliminare di sniffing dell’instaurazione della sessione
SIP, fase necessaria all’attaccante per carpire i parametri che caratterizzano il dialogo e sui quali
formerà le richieste di re-INVITE.
Una volta che la sessione è stata instaurata con successo dalle due vittime, l’utente malizioso deve
avviare una transazione di re-INVITE parallelamente con entrambe in cui dichiara, spacciandosi per
la controparte, che l’indirizzo su cui si vuole ricevere il flusso RTP, specificato nel campo c del
messaggio SDP, è cambiato ed il nuovo è quello proprio. Poiché è un attacco di tipo cieco, ossia
l’attaccante falsifica tutti gli indirizzi anche a livello IP, l’attaccante non può ricevere la risposta 200
OK alla richiesta di re-INVITE. Dopo che si è assicurato che tale risposta sia passata nella rete,
deve inviare un messaggio di ACK con cui termina la rinegoziazione dei parametri della sessione. A
questo punto è in grado di ricevere il flusso multimediale da entrambe le direzioni della
comunicazione e per rimanere trasparente alla vista degli utenti deve inoltrare il flusso RTP verso i
legittimi destinatari falsificando l’indirizzo di sorgente dei pacchetti IP in cui sono incapsulati.
Victim A
192.0.1.101
Victim B
192.0.2.102
flusso RTP tra Victim A e Victim B
Attacker
192.0.3.103
Via: SIP/2.0/UDP 192.0.2.102:5060
CSeq: 1 INVITE
Contact: <sip:client1.biloxi.com>
Content-Length: 125
Via: SIP/2.0/UDP 192.0.1.101:5060
CSeq: 2 INVITE
Content-Length: 125
...
c=IN IP4 192.0.3.103
...
...
c=IN IP4 192.0.3.103
...
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.102:5060
CSeq: 1 INVITE
Content-Length: 132
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.1.101:5060
CSeq: 2 INVITE
Contact: <sip:client1.biloxi.com>
Content-Length: 129
...
c=IN IP4 192.0.1.101
...
...
c=IN IP4 192.0.2.102
...
Via: SIP/2.0/UDP 192.0.2.102:5060
CSeq: 1 ACK
Via: SIP/2.0/UDP 192.0.1.101:5060
CSeq: 2 ACK
Figura 4.12 - Modifying IP address
48
Si noti che i due messaggi di INVITE generati dall’attaccante sono differenti, in quanto i tag locali e
remoti dei due client sono invertiti e quindi affinchè l’attacco abbia successo le richieste di reINVITE devono rispettare questa convenzione. Inoltre anche il CSeq è differente, poichè esso viene
gestito separatamente lato UAC e lato UAS, quindi quando l’utente malizioso si spaccia per il
chiamante deve aggiornare il campo CSeq del re-INVITE secondo quanto sniffato nella fase di
instaurazione della sessione. Nel verso opposto della comunicazione, se il chiamato non ha ancora
effettuato alcuna richiesta durante tale dialogo, il campo numerico del CSeq può assumere
qualsiasi valore.
In questo attacco le tracce lasciate dall’attaccante sono continuamente visibili, giacchè il proprio
indirizzo IP è il destinatario del flusso multimediale da entrambi i versi della comunicazione. Resta il
fatto che la procedura di cambiamento di indirizzo IP è considerata legale [9] e quindi non
dovrebbe destare alcun sospetto agli utilizzatori.
4.2.2 Denial of Service
Negli attacchi descritti in seguito ha un’importanza fondamentale la fase di lancio, che ora
verrà analizzata in maggior dettaglio per poi passare ad analizzare le diverse vulnerabilità che
possono essere sfruttate da utenti maliziosi.
4.2.2.1
Fase di lancio
La possibilità di effettuare un attacco di tipo Denial of Service è vincolata all’inizializzazione
delle sessioni RTP tramite SIP e RTSP, in quanto tali protocolli di segnalazione se manipolati in
maniera opportuna offrono all’attaccante la possibilità di indirizzare un flusso consistente di
pacchetti RTP da un server di rete, che appunto assumerà la funzione di trampolino di lancio verso
un bersaglio ben definito. Quindi affinchè sia possibilie effettuare un attacco del genere è
necessaria la presenza di server nella rete pubblica che, attraverso dei protocolli come SIP e RTSP,
forniscano la possibilità di creare un ampio numero di sessioni RTP dirette verso la vittima. Bisogna
infatti considerare che i flussi RTP potenzialmente necessitano di un’ampia quantità di banda e
quindi presentano già delle caratteristiche che facilitano il compito degli utenti maliziosi.
Nel caso di SIP, tutti i device che accettano in ingresso un ampio numero di chiamate, come i
server IVR (Interactive Voice Response), i gateway telefonici, i server per teleconferenze, i sistemi
voicemail, hanno un’importanza strategica perchè rappresentano una possibile fonte di traffico
indesiderato. Questa tipologia di traffico può essere portato a termine con successo anche in caso
sia necessaria un’autenticazione dell’utente, anche se ciò fornisce informazioni sulla tracciabilità.
49
Come definito in [16], invece, un server RTSP produce un ampio numero di sessioni RTP con i
client ad esso connessi. Per questo motivo molti attaccanti li utilizzano come trampolini di lancio
per attacchi Denial of Service.
Una volta noto l’indirizzo IP della vittima, l’aggressore instaura un numero notevole di sessioni RTP
attraverso i protocolli di segnalazione, a seconda del tipo di server: nel caso di SIP deve spedire un
messaggio di INVITE con un corpo SDP in cui viene specificato che l’indirizzo su cui si vuole
ricevere il flusso multimediale è quello della vittima, mentre nel caso RTSP si deve configurare il
campo Transport dell’intestazione del messaggio di richiesta. Se il server accetta automaticamente
la segnalazione ed instaura una sessione, il client può creare potenzialmente un ampio numero di
sessioni RTP indirizzate tutte verso un singolo bersaglio.
Con SIP è particolarmente semplice lanciare l’attacco in quanto non dispone di nessuna misura
specifica per controllare che l’indirizzo IP nel corpo SDP coincida con l’indirizzo sorgente dei
messaggi di segnalazione. Ciò non costituisce una svista, ma una presa di posizione in quanto non
è ritenuto corretto fare un controllo nella segnalazione di un sistema peer-to-peer [1].
4.2.2.2
Malicious payload format
Questo tipo di attacchi sfrutta le vulnerabilità delle implementaizioni software del protocollo
per saturare le capacità operative dell’apparato ricevente.
Infatti, per ogni soluzione implementata del protocollo è prevista l’esistenza di due tipologie di
documenti di accompagnamento:
•
documento di specifica del profile che definisce i payload type possibili, estensioni e campi
particolari dell’intestazione standard
•
documento di specifica del payload format che delinea come un particolare payload, ad
esempio una codifica audio o video, deve essere trasportato nel pacchetto RTP
Attraverso l’utilizzo di quei payload format che prevedono l’utilizzo della compressione, l’attaccante
deve inserire nel flusso dei pacchetti legali alcuni che hanno un carico computazionale non
uniforme con le specifiche del terminale ricevente. Quindi in presenza di particolare payload format
un utente malizioso ha la possibilità di inserire all’interno di un flusso RTP dei pacchetti infetti, che
sono complessi da decodificare e causano la degradazione delle prestazioni della macchina vittima.
Per inserirsi nella sessione RTP a cui partecipa la vittima, l’attaccante deve conoscerne i valori dei
parametri che la caratterizzano; tra essi il campo SSRC, le porte UDP utilizzate per il flusso RTP e
RTCP ed il payload type dell’intestazione.
50
Una volta all’interno della sessione, l’attaccante tramite tool specifici in grado di forgiare pacchetti
RTP con determinate caratteristiche invita flussi d’informazione (audio o video) ed all’interno
appunto introduce pacchetti maliziosi come descritto in precedenza.
Pacchetto
malicious
OK
OK
Flusso RTP
Flusso RTP
Victim A
Attacker
Overhead della
vittima
Figura 4.13 - Malicious payload format
4.2.2.3
RTCP timing rules incorrectly
Lo scopo di questo tipo di attacco è congestionare i collegamenti utilizzati in una
particolare sessione RTP sfruttando il traffico generato tramite il protocollo RTCP per informazioni
di controllo.
Le regole per la temporizzazione del traffico RTCP definite in [12] stabiliscono che l’intervallo di
emissione dei pacchetti RTCP da parte di ogni partecipante deve essere determinato in modo che:
•
ogni partecipante abbia a disposizione la stessa banda di controllo
•
il traffico di controllo complessivo non superi una piccola percentuale della banda assegnata
alla sessione, il valore suggerito è il 5%
•
almeno il 25% della banda RTCP deve essere riservato ai partecipanti attivi (emissione dei
messaggi SR), il restante 75% ai partecipanti non attivi (emissione dei messaggi RR)
L’algoritmo di calcolo dell’RTCP Transmission Interval permette la determinazione dell’intervallo di
tempo tra due trasmissioni consecutive di un pacchetto RTCP. Tale intervallo varia linearmente con
il numero di partecipanti alla sessione ed inoltre per evitare fenomeni di auto sincronizzazione dei
partecipanti il valore effettivo viene variato in modo casuale tra 0.5 e 1.5 volte il valore calcolato
concretamente dall’algoritmo matematico.
Quindi è fondamentale che il numero dei partecipanti ad una sessione sia continuamente
monitorato da ciascun componente della sessione stessa, infatti secondo [12] ogni partecipante
deve gestire una lista continuamente aggiornata degli utenti partecipanti alla sessione:
•
nuovi partecipanti sono aggiunti alla lista non appena sono rilevati tramite la ricezione di
pacchetti RTP – analizzando in essi il campo SSRC e CSRC
51
•
vecchi partecipanti sono eliminati dalla lista in corrispondenza della ricezione di un pacchetto
BYE o se nessun pacchetto RTP o RTCP viene ricevuto in un determinato intervallo di tempo
predefinito
Per analizzare nel dettaglio come è strutturato l’algoritmo e quale possibilità offre è necessario
introdurre le variabili che una sorgente standard RTCP deve gestire:
•
t_packet – istante di trasmissione dell’ultimo pacchetto RTCP
•
t – tempo corrente
•
t_next – istante previsto di trasmissione del successivo pacchetto RTCP
•
members_old – stima del numero di partecipanti ad una sessione all’istante in cui è stato
calcolato t_packet per l’ultima volta
•
members – ultima stima del numero di partecipanti ad una sessione
•
senders – ultima stima del numero di partecipanti attivi in una sessione
•
avg_rtcp_size – dimensione media dei pacchetti RTCP mediata su tutti i partecipanti alla
sessione
•
rtcp_bw – banda complessiva riservata al traffico RTCP
•
we_sent – è posto ad 1 se la sorgente è attiva, altrimenti è 0. La sorgente è considerata attiva
se ha emesso dati in un intervallo di tempo precedente di ampiezza uguale a 2 RTCP
Transmissione Interval
Per motivi di semplicità notazionale si considerano:
•
S – numero di senders
•
R – numero di receivers
•
M – numero di members
Allora l’intervallo tra due pacchetti RTCP consecutivi varia tra quattro opzioni:
If [s<=0.25 M] and [we_sent=1]
t_next=[avg_rtcp_size/0.25 rtcp_bw]
If [s<=0.25 M] and [we_sent=0]
t_next=[avg_rtcp_size/0.75 rtcp_bw]
If [s=>0.25 M] and [we_sent=1]
t_next=[avg_rtcp_size/(S/S+R)rtcp_bw]
If [s=>0.25 M] and [we_sent=0]
t_next=[avg_rtcp_size/(R/S+R)rtcp_bw]
Per realizzare questo attacco è necessario utilizzare strumenti tipici di un Distribuited Denial of
Service, in cui l’attaccante attraverso l’azione di nodi di rete detti master controlla l’azione di molti
altri dispositivi detti daemon. A questi ultimi è affidato il compito di condurre un’azione di Denial of
Service coordinata attraverso l’azione dei master contro la vittima, che in questo caso corrisponde
all’indirizzo di multicast della sessione RTP presa di mira.
I daemon nel momento in cui ricevono un segnale di avvio devono inviare pacchetti RTCP a ritmo
costante, senza curarsi del numero di partecipanti (t_next = cost). Quindi considerando che questo
comportamento anomalo viene replicato da un numero consistente di macchine tutte appartenenti
52
alla stessa sessione, allora è facile intuire che si raggiungerà una situazione di congestione
significante dei collegamenti visto che il traffico RTCP crescerà linearmente con il numero di
partecipanti.
Attacker
Sessione RTP
Traffico RTCP a
ritmo costante
Traffico RTCP
corretto
Master
Master
Master
Daemon
Multicast IP
Victim A
Figura 4.14 - RTCP timing rules incorrectly
4.2.2.4
Change Synchronization Source fileld
Questo attacco Denial of Service ha l’obiettivo di rendere inutilizzabile il servizio ad un
utente facente parte di una session RTP sfruttando le caratteristiche che riguardano la gestione
delle collisioni degli SSRC identifier.
Come descritto già in precedenza, il campo SSRC dell’intestazione del pacchetto RTP identifica la
sorgente di un flusso multimediale. Tutti i pacchetti con la stessa Synchronization Source devono
avere lo stesso riferimento temporale e lo stesso generatore di Sequence Number, in modo che il
ricevitore possa riordinare correttamente i pacchetti per la riproduzione. L’SSRC viene scelto dal
client RTP in maniera casuale in modo da essere probabilisticamente unico all’interno di una
sessione, per questo motivo tutte le implementazioni RTP e RTCP devono essere in grado di
rilevare e gestire le collisioni. In [12] è specificato che la rilevazione avviene attraverso un
algoritmo che si basa su due principi cardine:
•
pacchetti con medesimo SSRC identifier ma con indirizzo di sorgente differente sono spesso
caratteristici di una collisione
•
la presenza di pacchetti RTCP SDES con chunk caratterizzati da uno stesso SSRC ma da un
diverso CNAME identifica una collisione
53
L’algoritmo è articolato nel modo seguente:
•
ogni client RTP mantiene una tabella (Source Identifier Table) indicizzata in base agli SSRC
identifier a cui vengono associati i corrispondenti indirizzi di trasporto (indirizzo IP e porta UDP)
della sorgente. Queste informazioni vengono reperite dal primo pacchetto ricevuto, sia esso di
dati che di controllo
•
da ogni pacchetto RTP o RTCP ricevuto si estrae il valore del SSRC o CSRC e si accede alla
tabella. Qualora non fosse presente, viene creata una nuova associazione. Nel caso contrario,
l’indirizzo di trasporto del pacchetto viene comparato con quello memorizzato nella tabella e se
coincidenti il pacchetto viene considerato legittimo, altrimenti si è verificata una collisione od
un loop
•
le associazioni nella tabella vengono eliminate quando si riceve un pacchetto RTCP BYE oppure
dopo un lungo periodo di inattività
•
l’ultimo passo è rappresentato dalla creazione di una lista separata di tutti gli indirizzi di
trasporto delle sorgenti (distinguendo il traffico RTP da quello RTCP) che hanno
precedentemente causato conflitti
L’aspetto che un attaccante può sfruttare è che l’algoritmo prevede che i pacchetti provenienti
dalle sorgenti che hanno generato una collisione vengano scartati, in modo da evitare in
occorrenza di loop un flusso dilagante di pacchetti RTCP BYE.
L’obiettivo dell’attacco è fare in modo che la vittima veda continuamente all’interno della propria
sessione un traffico di pacchetti RTP con il suo stesso SSRC e quindi, dovendosi attenere alle
specifiche del protocollo [12], sia costretto ad inviare un pacchetto RTCP BYE con il vecchio SSRC
ed iniziare un nuovo flusso con SSRC differente. In questo modo il sender deve continuamente
evitare le collisioni create ad arte dall’attaccante e contemporaneamente il receiver deve scartare i
pacchetti legali perchè anch’esso, grazie alla Source Identifiers Table, si è accorto che è avvenuta
una collisione. L’attaccante quindi deve essere in grado di sniffare la rete su cui viaggiano le
informazioni trasportate dai protocolli RTP/RTCP per individuare continuamente quale SSRC viene
utilizzato dalla vittima.
Victim A
192.0.1.101
Attacker
192.0.3.103
Sessione RTP
RTP
RTP (spoofing)
SSRC = ABCD1234
SSRC = ABCD1234
IP = 192.0.1.101
IP = 192.0.1.199
RTCP BYE
SSRC = ABCD1234
RTP
RTP (spoofing)
SSRC = EFGH5678
SSRC = EFGH5678
IP = 192.0.1.101
IP = 192.0.1.199
...
...
Figura 4.15 - Change Synchronization Source field
54
E’ inoltre fondamentale conoscere le caratteristiche implementative dell’algoritmo utilizzato dal
client RTP per gestire le collisioni, in quanto possono verificarsi delle condizioni che causano lo
scarto dei pacchetti immediatamente, come nel caso di collisioni causate ripetutamente dalla stessa
sorgente. Ciò avviene perchè questa situazione viene associata all’esistenza di un loop tra sender e
receiver. Quindi l’attaccante deve essere abile nel camuffare volta per volta l’indirizzo di trasporto
della sorgente da cui farà partire il pacchetti RTP/RTCP maliziosi.
4.2.2.5
BYE attack
Questo attacco viene considerato come una variante del precedente, in quanto anch’esso
sfrutta una debolezza intrinseca del protocollo RTP con l’obiettivo di negare il servizio ad un
determinato partecipante ad una sessione RTP.
In questo caso però non viene sfruttata alcuna debolezza dell’algoritmo di gestione delle collisioni,
ma molto più semplicemente un utente malizioso, spacciandosi per la vittima, invia agli altri
partecipanti alla sessione un messaggio RTCP BYE terminando così ogni flusso multimediale.
Ripetendo questo procedimento tutte le volte che la vittima cerca di accedere nuovamente alla
sessione, si ottiene un attacco di tipo Denial of Service.
Victim A
192.0.1.101
Attacker
192.0.3.103
Sessione RTP
RTP
RTCP BYE (spoofing)
SSRC = ABCD1234
SSRC = ABCD1234
IP = 192.0.1.101
IP = 192.0.1.101
Port = 5004
Port = 5005
… la vittima rinizia il
processo di accesso …
RTP
RTCP BYE (spoofing)
SSRC = EFGH5678
SSRC = EFGH5678
IP = 192.0.1.101
IP = 192.0.1.101
Port = 5004
Port = 5005
Figura 4.16 - BYE attack
4.2.2.6
Sequence Number and Timestamp higher
Scopo di questo tipo di attacco è de-sincronizzare sender e receiver in modo da rendere
del tutto inutilizzabili i pacchetti che costituiscono il flusso multimediale RTP tra essi.
55
Perchè abbia successo l’attaccante deve operare inizialmente una fase di sniffing durante la quale
viene a conoscenza dei parametri che caratterizzano la sessione RTP necessari perchè riesca ad
intromettersi
nella
comunicazione.
Successivamente
deve
creare
dei
pacchetti
RTP
opportunamente falsificati in modo che sembrino generati dal sender ed inserirvi nei campi
Sequence Number e Timestamp dei valori molto più alti di quelli catturati durante la fase di
sniffing.
I pacchetti maliziosi quando vengono accettati dal ricevitore, giacché non è presente alcuna
anomalia, sincronizzano il client RTP sui valori specificati nei campi Timestamp e Sequence
Number. L’attacco ha effetto nel momento in cui al ricevitore giungono i pacchetti generati dal
sender, pacchetti che presentano un valore del Timestamp e del Sequence Number più bassi di
quelli su cui si è sincronizzato e quindi vengono considerati fuori sequenza e di conseguenza
scartati. Il successivo flusso da sender a receiver verrà quindi scartato, poiché il sender non ha
modo di conoscere i valori temporali che il receiver si aspetta di ricevere.
Victim A
192.0.1.101
Attacker
192.0.3.103
Victim B
192.0.1.102
RTP
RTP
SSRC = ABCD1234
SSRC = ABCD1234
IP = 192.0.1.101
IP = 192.0.1.101
Port = 5004
Port = 5004
seq_num = 10
seq_num = 100
timestamp = 11
timestamp = 101
RTP
SSRC = ABCD1234
IP = 192.0.1.101
Port = 5004
scartato perché
obsoleto
seq_num = 11
timestamp = 12
Figura 4.17 - Sequence Number and Timestamp higher
4.2.2.7
Injecting malicious Reception Reports (RR)
Scopo di questo attacco è forzare la vittima a cambiare la codifica audio e video durante la
sessione. Nel dettaglio, l’intento dell’attaccante è quello di mitigare la qualità della comunicazione
imponendo o l’utilizzo di un codificatore con bassa qualità, oppure uno di qualità maggiore rispetto
a quello in uso che provoca un intasamento della pila di memoria.
I messaggi utilizzati in questo attacco sono i Reception Report del protocollo RTCP.
56
Figura 4.18 - Pacchetto Reception Report di RTCP
Ponendo l’attenzione solo sui Report Block in cui sono contenute le informazioni sensibili, i campi
del pacchetto sono:
•
SSRC_n – indica la sorgente di streaming a cui si riferiscono le informazioni del report block
specifico
•
Fraction Lost – indica la frazione dei pacchetti RTP delle sorgente SSRC_n che non sono stati
ricevuti sino all’istante di emissione del pacchetto RR stesso
•
Cumulative number of packet lost – indica il numero totale di pacchetti RTP provenienti
dall’SSRC_n che non sono stati ricevuti. Tale numero è calcolato dalla differenza tra il numero
di pacchetti previsti e quelli attualmente ricevuti
•
Extended highest sequence number received – è diviso in due parti, i secondi 16 bit
contengono il valore più elevato ricevuto dal numero di sequenza di pacchetti RTP, mentre i
primi 16 bit contengono il numero di ciclo raggiunto dal contatore dall’inizio del conteggio
•
Interarrival Jitter – indica una stima della varianza statistica del tempo di interarrivo dei
pacchetti RTP
•
LSR Last SR Timestamp – è il valore del Timestamp del più recente pacchetto RTCP ricevuto da
SSRC_n
•
DLSR Delay Since Last SR – indica il ritardo che intercorre tra l’istante di ricezione dell’ultimo
pacchetto RTCP da parte di SSRC_n e l’istante di invio del presente pacchetto di Reception
Report
L’attaccante deve quindi iniettare all’interno di una sessione RTP, di cui ha catturato i parametri,
una serie di falsi RR indirizzati tutti al medesimo bersaglio, riportando:
•
una maggior perdita di pacchetti rispetto quella reale
•
un bit error maggiore di quello reale
57
Entrambe queste azioni possono causare in un codificatore adattativo ad utilizzare un codec di
minore qualità. Per iniettare tali pacchetti, l’utente malizioso deve camuffare la propria identità,
come mostrato già nei precedenti attacchi, ed inoltre deve reperire informazioni utili, come il tipo di
codec utilizzato, il Last SR Timestamp, la stima del Jitter e l’attuale Fraction Lost.
4.3 Implementazione degli attacchi
In questo paragrafo verranno descritti i passi intrapresi per realizzare all’atto pratico alcuni
degli attacchi descritti precedentemente. Tale lavoro di sperimentazione è stato principalmente
svolto presso il laboratorio multimediale di IT Telecom del gruppo Telecom Italia S.p.A.
Degli attacchi descritti precedentemente verranno presi in considerazione solo alcuni. Per quanto
riguarda gli attacchi ad un’architettura VoIP verrà dato esempio di un Man in the Middle che sfrutta
l’ARP Cache Poisoning (paragrafo 3.2.1.3). Per quanto riguarda gli attacchi che sfruttano delle
vulnerabilità proprie di SIP verranno descritti i casi di Tearing Down a Session (4.1.3.1), Cancelling
a Session (4.1.3.3) e Modifying a Session (4.1.3.2).
4.3.1 Man in the Middle in VoIP
4.3.1.1
Architettura
L’architettura di riferimento è quella descritta dalla figura seguente.
Live Communcation
Server 2003
IP: 10.10.81.107
Switch Catalist 2950
Client A
IP: 10.10.82.110
MAC: 00-50-DA-73-40-CE
Client B
Attacker
IP: 10.10.82.204
MAC: 00-54-DA-74-84-05
58
IP: 10.10.82.31
MAC: 00-08-C7-B3-6B-31
Di essa fanno parte un Server Microsoft Live Communication 2003, che ha funzioni di Outbound
Proxy, Redirect Server e Registrar Server, uno Switch Catalyst 2950 della Cisco System, due UA
Microsoft Messenger 5.0 ed una postazione dell’attaccante.
4.3.1.2
Strumenti
Le azioni previste per realizzare questo attacco sono diverse e devono essere eseguite
rispettando l’ordine temporale.
•
Entrare in possesso degli indirizzi MAC delle due vittime sfruttando l’utility ping
•
Avvelenare le tabelle ARP delle due vittime attraverso l’utiliy arpspoof di Dsniff [34]
•
Permettere l’inoltro dei messaggi verso i legittimi destinatari attraverso l’utility fragrouter di
Dsniff
•
Visualizzare i messaggi scambiati tra le due vittime attraverso un utility di sniffing, ad esempio
Ethereal® [35]
Client A
IP: 10.10.82.110
Attacker
IP: 10.10.82.31
Client B
IP: 10.10.82.204
Ping Req. 10.10.82.110
Ping Req.10.10.82.204
Ping Rep. 10.10.82.31
Ping Rep. 10.10.82.31
arpspoof -t 10.10.82.110 10.10.82.204
arpspoof -t 10.10.82.204 10.10.82.110
fragrouter -B1
UDP / RTP
UDP / RTP
Per chiarezza visiva
non sono inseriti tutti
i messaggi connessi
alla funzione arpspoof
che deve avvelenare
continuamente le
tabelle di ARP delle
due vittime
Questo è il tempo che
l’attacker impiega per
memorizzare il
pacchetto entrante e
per indirizzarlo verso
l’utente lecito
UDP / RTP
UDP / RTP
4.3.1.3
Risultati
In questa sezione vengono visualizzati i risultati conclusivi utilizzando delle capture
ottuenute dall’analizzatore di rete Ethereal® installato sulla macchina dell’attaccante.
59
Quindi, ricordando che gli indirizzi IP delle macchine delle vittime sono 10.10.82.204 e
10.10.82.110, è possibile riscontrare che l’attacco è riuscito visto che la macchina dell’attaccante
intercetta tutti i pacchetti RTP che i due client si scambiano, senza che essi si accorgano della sua
presenza. Una volta memorizzati tali pacchetti, utilizzando sempre Ethereal®, è possibile
estrapolare i dati che essi trasportano, come evidenzia la capture che segue.
Infatti tramite utilities, come VOMIT (Voice over Misconfigured Internet Telephones) [36] è
possibile riassemblare tutti i pacchetti RTP appartenenti ad una sessione e ricostruire la
conversazione originale – file audio – tra i due client vittime.
Nella prossima capture si sottolinea il fatto di come sia l’attaccante ad inviare il traffico dal Client B
(10.10.82.204) e non il Client A (10.10.82.110). Analizzando infatti gli indirizzi MAC si nota
facilmente che il pacchetto in realtà è generato dall’interfaccia di rete dell’attaccante (00-08-C7-B36B-31), che memorizza il flusso di dati proveniente del Client A e lo inoltra, dopo averlo
memorizzato, verso il Client B.
60
4.3.2 Tearing down a session
4.3.2.1
Architettura
Il primo passo prevede la realizzazione di un’architettura di riferimento che verrà utilizzata
durante tutta la durata della sperimentazione.
SIP-SERVER
IP: 10.10.82.112
HUB
Sebastiano
IP: 10.10.82.191
MAC: 00-50-DA-73-40-CE
Alessandro
Attacker
IP: 10.10.81.40
MAC: 00-50-DA-74-84-05
IP: 10.10.82.49
MAC: 00-08-C7-B3-6B-31
E’ necessario specificare anche le assegnazioni di indirizzi IP e di indirizzi MAC, in quanto
successivamente saranno utilizzati per dimostrare e valorizzare le tecninche utilizzate per protrarre
61
gli attacchi. Come si evince dalla figura precedente l’architettura è costituita da un SIP Server e tre
client, di cui uno malizioso.
Naturalmente i due client legittimi risultano registrati ad un servizio del server SIP con le SIP URI
sip:[email protected] e sip:[email protected].
4.3.2.2
Strumenti
Per realizzare tale attacco sono stati utilizzati strumenti open source, come il SIP Server
SER (SIP Express Router), fornito gratuitamente della IPTel [37], e gli UA SJphone della SJ Labs
[38]. Per quanto riguarda il client malizioso, è stato realizzato per questo scopo un generatore di
messaggi SIP nel linguaggio di programmazione C, che consente all’utente di gestire la costruzione
dell’intero pacchetto dal livello applicativo al livello di rete (per maggiori dettagli consultare
l’appendice A).
4.3.2.3
Risultati
La situazione di partenza prevede che i due client abbiano già instaurato una sessione SIP,
di cui l’utente malizioso abbia sniffato i messaggi iniziali della fase di instaurazione.
Client A
Client B
SIP-Server
IP: 10.10.81.40
MAC: 00-50-DA-74-84-05
IP: 10.10.82.191
MAC: 00-50-DA-73-40-CE
IP: 10.10.82.112
INVITE
100 TRYING
INVITE
180 RINGING
200 OK
180 RINGING
200 OK
ACK
ACK
Flusso RTP
Da questo flusso di messaggi l’attaccante preleva il Call-ID ed i due Tag, quello locale e quello
remoto.
62
To: <sip:[email protected]>;tag=325512562588
From: <sip:[email protected]>;tag=325319828183
Ora l’attaccante è in possesso di tutti i dati necessari per costruire il messaggio SIP BYE con il
quale abbatterà la comunicazione tra i client di Alessandro e Sebastiano. L’attaccante lo incapsula
quindi all’interno di un pacchetto IP spacciandosi per Alessandro e lo spedisce a Sebastiano.
BYE sip:[email protected]:5060 SIP/2.0
Via:SIP/2.0/UDP 10.10.81.40;rport;
branch=z9hG4bK0a0a52bf0131c9b141a3ba6000003f90000005h2
From: <sip:[email protected]>;tag= 325319828183
To: <sip:[email protected]>; tag=325512562588
CSeq: 2 BYE
Lo UA SJphone dell’indirizzo 10.10.82.191 non si accorge dell’attacco e risponde con un 200 OK,
abbattendo la sessione. Per confermare la realizzabilità di quest’attacco viene riportata in seguito
una schermata di Ethereal®, da cui si evince:
•
La richiesta BYE a livello IP ha come sorgente l’indirizzo 10.10.81.40 – client legittimo – ma
l’indirizzo MAC è quello del client dell’attaccante
•
Il flusso SIP non rivela alcuna anomalia, infatti la vittima che riceve la richiesta BYE risponde
con un 200 OK destinato alla controparte legittima. Quest’ultima riceve una risposta ad una
richiesta che non ha mai generato e risponde con un ACK. Quest’ultimo messaggio è frutto
delle scelte implementative dello UA e non risulta nello standard [1].
63
4.3.3 Cancelling a session
4.3.3.1
Architettura
Lo scenario di riferimento non è differente da quello descritto nella sezione precedente, ma
in questo caso la tempistica assume un ruolo fondamentale in quanto i messaggi maliziosi
dell’attaccante devono inserirsi nella fase di three-way-handshake di instaurazione del dialogo SIP.
4.3.3.2
Strumenti
Gli strumenti sono gli stessi utilizzati nell’attacco precedente.
4.3.3.3
Risultati
Tramite uno sniffer il client malizioso intercetta la richiesta INVITE che Sebastiano invia al
server SIP (SER) con l’intenzione di instaurare una sessione con Alessandro. Il client malizioso da
questo messaggio ricava tutti i parametri necessari per portare a buon termine l’attacco, infatti
sono necessari il valore del campo Call-ID, il valore del Branch del campo Via ed il valore del Tag
locale:
To: <sip:[email protected]>;
Giacché il client destinatario – Alessandro – non ha ancora accettato la comunicazione, quindi non
ha generato alcuna risposta all’invito, il tag remoto ancora non è stato scelto. Per questo motivo
l’attaccante genera una richiesta di CANCEL riferita all’INVITE con i parametri ottenuti dalla fase
preliminare di sniffing:
CANCEL sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.82.191;rport;
From: <sip:[email protected]>;tag= 325319828183
To: <sip:[email protected]>;
CSeq: 1 CANCEL
Attraverso l’analisi della figura seguente si possono trarre le conclusioni:
64
•
La richiesta CANCEL a livello IP ha sorgente l’indirizzo 10.10.82.191 – di Sebastiano – ma
l’indirizzo MAC è quello del client malizioso
•
Nella sequenza di messaggi appare una risposta 487 Request Terminated, questo messaggio
testimonia la buona riuscita dell’attacco in quanto lo UAS di Sebastiano non si accorge
dell’attacco subito e tenta di protrarre la procedura di instaurazione della sessione
Indirizzi IP dei due
client legittimi
Sequenza dei
messaggi SIP
Indirizzo MAC dell’ attacker,
prova dello spoofing a livello ip
4.3.4 Modifying a session
4.3.4.1
Architettura
L’architettura di riferimento è la stessa analizzata nell’attacco precedente.
4.3.4.2
Strumenti
Per realizzare questa tipologia di attacco è stato utilizzato uno tra i tanti generatori di
messaggi SIP disponibili in Internet, il SIPNess Messenger [39], che è stato installato su una
macchina i cui indirizzi sono IP: 10.10.81.107 e MAC: 00-50-DA-74-85-B4.
SIP-SERVER
IP: 10.10.82.112
HUB
Sebastiano
IP: 10.10.82.191
MAC: 00-50-DA-73-40-CE
SIPNess
Alessandro
IP: 10.10.81.40
MAC: 00-50-DA-74-84-05
65
IP: 10.10.81.107
MAC: 00-50-DA-74-85-B4
Il SIPNess Messenger, tramite un’interfaccia molto semplice, fornisce un metodo immediato ed
intuitivo per costruire ed inviare messaggi SIP conformi allo standard. Ma a differenza del
generatore di messaggi SIP utilizzato nell’attacco precedente, il SIPNess Messenger gestisce
autonomamente tutte le problematiche riguardo lo stack protocollare TCP/IP, impedendo di
conseguenza lo spoofing a livello IP.
Lo scenario iniziale prevede che i due utenti legittimi abbiano già instaurato una sessione SIP e che
il client malizioso, tramite l’utilizzo dello sniffer Ethereal®, abbia intercettato tutto il flusso dei
messaggi:
To: sip:[email protected]>;tag=426445129201
branch= z9hG4bK0a0a52bf0131c9b1419951ab00000fb20000008ih
L’attaccante deve quindi inviare con SIPNess un messaggio di INVITE all’interno della sessione già
instaurata, e quindi viene considerato un re-INVITE, inserendo un Message Body vuoto. Il client
SJphone in ascolto sulla porta 5060 all’indirizzo IP 10.10.81.40 riceve una richiesta INVITE in cui i
parametri caratterizzanti corrispondono a quelli di una sessione già instaurata, ma all’interno non è
presente alcun parametro SDP. Tale messaggio viene interpretato come un re-INVITE e lo UAS
SJphone invia una serie di messaggi 200 OK specificando i propri parametri della sessione RTP.
Scaduto il Timeout la
sessione viene abbattuta
Mentre i 200 ok sono inviati al 10.10.81.107,
il BYE è inviato al 10.10.82.191
66
Ovviamente l’attaccante non ha alcuna intenzione di concordare tali parametri e quindi ignora le
risposte della vittima.
4.3.4.3
Risultati
Una volta scaduto il timeout, il client SJphone utilizzato da Alessandro abbatte la sessione
inviando a Sebastiano una richiesta BYE a cui segue una risposta 200 OK.
Quindi ora la sessione è abbattuta e l’attaccante ha ottenuto l’obiettivo di rendere indisponibile il
servizio.
67
5
Attraversamento di NAT e Firewall
5.1 Introduzione al NAT e Firewall
5.1.1 Introduzione ai Firewall
I Firewall rappresentano il principale meccanismo di protezione per negare l’accesso ad
una rete al traffico proveniente dall’esterno. Infatti tutto ciò che proviene dall’interno – dal punto di
vista dell’utente della rete privata – o dall’esterno viene filtrato. Quel flusso di pacchetti che viola le
regole imposte dall’amministratore verranno scartati, allo scopo di far rispettare le politiche di
sicurezza impostate nei filtri [17].
Esistono diversi tipi di Firewall.
5.1.1.1
Packet Filtering Gateways
Questo tipo di Firewall opera sui campi dell’intestazione del datagramma IP, dei pacchetti
TCP e UDP. L’informazione più importante durante l’operazione di filtraggio è l’indirizzo IP – di
sorgente e di destinazione – e il numero di porta – di sorgente e di destinazione. Altra informazioni
come i flag SYN e ACK dell’intestazione TCP [19] sono considerate altrettanto essenziali perché
permettono di distinguere una connessione già instaurata da una che si vuole instaurare.
I Packet Filtering Gateways vengono distinti in stateful, che conservano lo stato di una sessione, e
gli stateless, che non lo fanno. I primi, durante il processo di filtraggio, utilizzano informazioni dalla
parte applicativa del flusso. Ciò implica che i filtri stateful sono in grado di riconoscere il protocollo
applicativo senza dover basare le proprie decisioni sul fatto che un certo pacchetto è destinato ad
un servizio che utilizza una porta nota o meno. La limitazione di questo tipo di Firewall è che non
hanno la possibilità di apportare cambiamenti al contenuto dei dati a livello applicativo dei
datagrammi IP.
Le funzioni di filtraggio, anche dette regole, vengono definite per ogni interfaccia del Firewall ed in
base al flusso uscente o entrante.
5.1.1.2
Circuit-Level Gateways
Come indica il nome, questo tipo di Firewall tratta i circuiti virtuali che vengono stabilito
con il protocollo TCP – le connessioni sono garantite e i pacchetti arrivano in sequenza. Lo scopo
del Circuit-Level Gateway è di stabilire un collegamento logico tra l’interfaccia esterna e quella
68
interna del Firewall. Quando un client interno tenta di aprire una connessione TCP su una porta del
gateway, esso apre un’altra connessione dalla propria interfaccia esterna verso il server esterno. Il
gateway non cerca di interpretare il contenuto dei pacchetti TCP, esso deve solamente collegare
ogni informazione ricevuta da un lato – interno o esterno – verso l’altro lato. Questa procedura è
stata resa standard in [20].
Gli indirizzi che i client utilizzano nella rete interna non sono visibili all’esterno, giacché essi
vengono rimpiazzati da quello pubblico dell’interfaccia esterna del gateway. Anche il numero di
porta nell’intestazione TCP viene sostituito.
5.1.1.3
Application Level Gateways
Gli Application Level Gateway (ALG) rappresentano il tipo di Firewall più sofisticato. Essi
lavorano in maniera simile ai Circuit-Level Gateway, ma ci sono delle differenze sostanziali che li
rendono più interessanti. Spesso vengono descritti come Proxy, ma altre volte come dei prodotti
software che collaborano con l’azione dei NAT dei Firewall, come descritto in [21]. Quest’ultima
definizione è quella assunta in questa tesi.
Alcune caratteristiche degli ALG sono:
¾
Gli ALG non sono generici come i Circuit-Level Gateway, essi infatti utilizzano dei codici specifici
per ogni particolare applicazione o servizio che supportano. Poiché essi riconoscono il
protocollo a livello applicativo che è contenuto nei pacchetti che stanno processando, essi
garantiscono una maggiore sicurezza per la rete interna.
¾
Gli ALG non hanno la limitazione di supportare solamente il protocollo di trasporto TCP, come i
Circuit-Level Gateway, ma anche UDP.
¾
Se l’ALG è utilizzato con un NAT – ed è il caso descritto in questa tesi – allora esso esamina i
dati a livello applicativo per sostituire eventuali occorrenze di indirizzi privati interni con
l’indirizzo pubblico dell’interfaccia esterna del gateway. Il capitolo successivo descrive
dettagliatamente l’implementazione di un ALG per SIP.
5.1.2 Introduzione ai NAT
Il NAT [22] è stato originariamente pensato come una soluzione a breve termine in attesa
di una a lungo termine al problema della mancanza di indirizzi IP. La soluzione a lungo termine è la
proposta di un nuovo Internet Protocol con uno spazio di indirizzamento maggiore – IPv6.
Il NAT è un processo utilizzato per sostituire un indirizzo con un altro. Esso viene comunemente
utilizzato dalle aziende per trasformare gli indirizzi interni privati [23] in indirizzi IP pubblici. Ciò è
reso necessario dal fatto che gli indirizzi privati non sono instradabili in un dominio pubblico come
Internet perché possono risultare in conflitto con altri reti privati che utilizzino lo stesso spazio di
indirizzamento.
69
Per ogni sessione instaurata tra un host della rete interna ed uno all’esterno, il NAT deve
aggiornare una tabella detta di traduzione. Ciò serve a rendere possibile il transito dei pacchetti nel
verso opposto.
Un ulteriore aspetto che caratterizza il NAT è che esso diminuisce la vulnerabilità degli host della
rete interna. Infatti, mascherando l’indirizzo IP degli utenti interni con uno o più indirizzi globali, li
rende anonimi all’esterno e quindi difficilmente attaccabili. D’altra parte è necessario proteggere in
maniera adeguata il NAT, perché esso rappresenta l’unico bersaglio attaccabile dall’esterno della
rete cui offre servizio.
Il NAT può essere implementato in diversi modi, come descritto in [21], ma l’attenzione in questo
caso viene focalizzata solo sulle seguenti categorie.
5.1.2.1
Static NAT
Questo tipo di NAT richiede lo stesso numero di indirizzi IP pubblici di quanti sono gli host
all’interno della rete privata. Come suggerisce il nome, l’associazione tra indirizzi locali e indirizzi
globali è statica e quindi viene configurata manualmente dall’amministratore di rete o attraverso il
protocollo DHCP [24] in fase di avvio della macchina. Il vantaggio di questo tipo di NAT è
rappresentato dal fatto che le sessioni iniziate dall’esterno non rappresentano un problema, in
quanto il rapporto uno ad uno nella tabella delle traduzioni tra host interni ed indirizzi globali non
introduce ambiguità. La limitazione, invece, è costituita dal limitato numero di host interni che
possono accedere contemporaneamente all’esterno della rete locale.
5.1.2.2
Dynamic NAT
In questa categoria il NAT elenca gli indirizzi IP pubblici in un pool di indirizzi, da cui ne
viene estratto uno ogni qualvolta un host interno vuole accedere ad una risorsa esterna. Questo
tipo di implementazione deve prevedere però un numero limitato di accessi contemporanei
all’esterno, giacché quando il pool è esaurito, qualora un ulteriore host facesse richiesta al NAT di
accedere all’esterno, il NAT negherebbe la connessione. Il pool si ripopola invece nel momento in
cui una connessione viene chiusa e quindi l’indirizzo globale è di nuovo disponibile.
Per questo motivo il Dynamic NAT deve poter controllare nell’intestazione del pacchetto TCP se i
flag FIN (orderly release) o RST (abortive release) [19] sono impostati. Al contrario, l’UDP crea dei
problemi poiché non prevede alcun segnale esplicito di chiusura della sessione [25].
Una soluzione a questo problema consiste nell’usare dei timeout. Quando un’associazione della
tabella delle traduzioni non viene consultata per un certo periodo di tempo, essa viene cancellata e
l’indirizzo globale reinserito nel pool di indirizzi disponibili. Questo schema è utile anche nel caso in
cui le connessioni TCP dovessero terminare senza alcun messaggio con i flag di terminazione
impostati. [19] suggerisce che una connessione TCP può essere considerata terminata se non
attiva per 24 ore. Per connessioni non TCP alcuni minuti sono sufficienti.
70
5.1.2.3
Network Address and Port Translation (NAPT)
NAPT costituisce un particolare caso del Dynamic NAT, caso del resto diffusamente
utilizzato. Ciò che rende questa soluzione molto popolare è che molti host interni possono
condividere pochi o addirittura un solo indirizzo globale. Infatti il NAPT utilizza il numero di porta
come base per la traduzione degli indirizzi. In questo modo il numero di connessioni per ogni
indirizzo IP globale sono limitate solamente dal numero di porte disponibili, ossia 216=65536.
Questo però è solamente un numero teorico poiché alcune di queste porte sono state assegnate
per servizi specifici, come riportato in [26]. E’ assunto inoltre che quanto una porta viene utilizzata
da una traduzione, allora sia le porte TCP che UDP vengono segnalate come utilizzate per una
questione di semplicità.
5.2 Problematiche di attraversamento
I Firewall e i NAT vengono installati ai confini di una rete privata. Poichè spesso versioni
software dei Firewall e NAT vengono offerti assieme ad un abbonamento DSL, i problemi che
vengono descritti in seguito riguardano tanto gli utenti aziendali che quelli residenziali.
Il problema consta di due componenti. Mentre oggi i Firewall sono in grado di aprire e chiudere
dinamicamente più porte come richiesto dai protocolli di segnalazione VoIP, ed è il caso di SIP, essi
purtroppo rimangono inefficaci per un flusso media entrante in una rete privata. Inoltre i NAT
impediscono la comunicazione voce o multimediale in due direzioni, poiché gli indirizzi IP privati e
le porte inserite dai dispositivi terminali VoIP nel contenuto applicativo dei pacchetti non sono
instradabili in reti pubbliche.
Le conseguenze di questi due problemi sono ad esempio che le proposte di instaurazione di una
sessione multimediali provenienti dall’esterno di una rete locale protetta da Firewall e NAT
falliscono perché bloccate, fatto del tutto inaccettabile per un servizio come il VoIP che si propone
di sostituire la rete PSTN in tutte le sue funzionalità [18].
5.2.1 Il problema Firewall
Come già accennato in precedenza, il ruolo del Firewall è di proteggere una rete
dall’accesso di traffico non autorizzato. Esso adempie a questo compito bloccando il traffico in base
a tre parametri: la sorgente, il destinatario e il tipo di traffico. I Firewall prendono decisioni in base
alla direzione del traffico che stanno esaminando. Tipicamente un flusso in entrata – ossia
proveniente dal lato pubblico – è permesso solamente nel caso in cui la sessione di cui fa parte è
stata iniziato da un host della rete privata. Le comunicazioni basate sul protocollo SIP, del resto
come le telefonate tradizionali, non possono prescindere da telefonate inattese provenienti
71
dall’esterno, da un’ampia gamma di sorgenti sconosciute e non fidate. Ciò però va contro le
politiche che sono alla base dell’implementazione di ogni Firewall.
Ogni soluzione a questo problema deve quindi garantire una comunicazione bi-direzionale tra
utenti interni ed esterni alla rete privata, ma nel contempo non aumentare il livello di sicurezza per
gli utenti interni assicurato dal Firewall.
Il client A inizia una
sessione uscente verso
il client X
Il Firewall permette
l’ingresso del flusso in
entrata
Client X
Client A
Il Firewall blocca il flusso
non previsto proveniente
dall’esterno
Client B
Il client Y tenta di
inizare una sessione
con il client B
Client Y
Figura 5.1 - Il problema Firewall
5.2.2 Il problema NAT
Si consideri il caso in cui venga utilizzato un NAPT. Il flusso di traffico uscente diretto ad un
terminale della rete pubblica verrà dinamicamente assegnato ad una specifica porta dell’indirizzo
pubblico del NAT. Il NAT mantiene queste associazioni nella tabella delle traduzioni, associazioni
che possono essere create, modificate e cancellate solamente attraverso l’azione di un flusso
uscente dal dominio privato. A complicare la situazione c’è il fatto che nella fase di inizializzazione
della sessione sia i messaggi SIP che quelli SDP contengono l’indirizzo privato del client su cui si
vuole ricevere il flusso multimediale.
1. Nel messaggio SDP la
sorgente è
192.168.1.100:8000
Client A
192.168.1.100
2. La segnalazione ed il
flusso media passano
attraverso il Firewall con
funzione di NAT
Segnalazione
Segnalazione
Media
Media
3. Nel messaggio SDP la
sorgente continua ad essere
192.168.1.100:8000
Client X
243.120.15.101:
9000
4. Ora il flusso multimediale
ha come sorgente
243.120.15.101:9000
Figura 5.2 - Il problema NAT
Le conseguenza sono molteplici. Quando il terminale esterno tenta di stabilire una sessione RTP
con l’indirizzo privato specificato la connessione verosimilmente fallirà, poiché tali indirizzi non sono
instradabili in un domino pubblico. Inoltre il terminale esterno se dal punto di vista della
72
segnalazione SIP vede come controparte un indirizzo privato, dal punto di vista del flusso
multimediale RTP vede come controparte un indirizzo pubblico, visto che a livello applicativo nei
messaggi SIP è presente l’indirizzo IP degli UA mentre nei messaggi RTP no.
Ogni soluzione a questo problema deve garantire una comunicazione bi-direzionale sicura – incluse
chiamate
entranti
inaspettate
–
e
minimizzare
la
dipendenza
dal
particolare
tipo
di
implementazione o soluzione del NAT stesso.
5.2.3 Soluzioni proposte
Appare evidente quindi quanto sia necessaria una soluzione sia ai problemi evidenziati nei
paragrafi immediatamente precedenti, ossia il problema Firewall e quello NAT, e sia ai problemi di
sicurezza legati agli attacchi descritti nei capitoli 3 e 4.
Per quanto riguarda i primi due, le soluzioni esistenti nel mercato odierno sono diverse. In questo
paragrafo ne verranno brevemente descritte alcune, ponendo l’accento sulle implicazioni
riguardanti la sicurezza.
5.2.3.1
Universal Plug and Play (UPnP)
UPnP è una tecnologia che permette alle applicazioni dei client di scoprire e configurare i
componenti di una rete, come NAT e Firewall, che sono forniti di software UPnP.
La necessità fondamentale nelle applicazioni VoIP consiste nello scoprire quale indirizzo IP e porta
il NAT ha selezionato per la segnalazione e per il flusso multimediale di una particolare sessione.
Una volta che tale informazione è nota, il client VoIP può modificare opportunamente i pacchetti
che genera in modo da poter stabilire una comunicazione bi-direzionale con l’esterno.
Per fare ciò, il NAT e i client VoIP devono supportare UPnP. Tutt’oggi ci sono pochi terminali VoIP,
NAT e Firewall disponibili sul mercato che lo supportano [18]. Inoltre il maggior svantaggio di
questa soluzione è che non risolve il problema Firewall.
5.2.3.2
STUN
Il protocollo Simple Traversal of UDP Through Network Address Translator (STUN)
permette ad uno UA SIP di scoprire se si trova dietro un NAT e determinare il tipo di NAT [27]. La
proposta STUN definisce un server dedicato – STUN server – da installare nello spazio di
indirizzamento pubblico per informare gli UA SIP che supportano STUN su quale indirizzo IP
pubblico e porta si sta utilizzando per quella particolare sessione. Avere uno UA che supporti STUN
o addirittura modificare quelli esistenti perché lo diventi rendono questa soluzione impopolare,
giacché pochi distributori hanno annunciato il supporto di STUN per i loro prodotti [18].
Bisogna inoltre considerare che il protocollo STUN è incompatibile con la maggior parte dei NAT
utilizzati tutt’oggi: i NAT simmetrici. Questo tipo di NAT crea un’associazione nella tavola delle
73
traduzioni in base non solo all’indirizzo IP e porta di sorgente, ma anche all’indirizzo IP e porta di
destinazione. L’indirizzo di destinazione del client VoIP e quello del server STUN sono differenti e
quindi il NAT simmetrico crea due associazioni, rendendo così inutilizzabile quella destinata alla
segnalazione VoIP. Lo stesso problema si riscontra nelle chiamate in ingresso.
L’IETF ha proposto un meccanismo addizionale – TURN [28]– sviluppato appositamente per
risolvere questo problema, ma oltre a considerare il fatto che queste soluzioni hanno un grande
impatto sull’architettura di rete e quindi non sono di facile implementazione, anche in questo caso
si nota una certa riluttanza dei produttori di UA a rendere i propri prodotti STUN e TURN friendly
[18].
5.2.3.3
Configurazione manuale
In questo metodo, il client SIP viene configurato manualmente con l’indirizzo IP pubblico e
porta che il NAT deve destinare ad esso. Ovviamente per questa soluzione è altrettanto necessario
configurare manualmente il NAT per ogni client SIP della rete.
Una limitazione ulteriore introdotta da questa soluzione è rappresentata dalla necessità di
mantenere lo stesso indirizzo IP per ogni client, in modo da non comprometterne la raggiungibilità.
Appare quindi evidente come questa rappresenti una soluzione per una rete di dimensioni limitate,
in cui l’utilizzatore abbia le capacità necessarie per configurare NAT e Firewall.
Da un punto di vista della sicurezza, inoltre, la configurazione manuale rende visibile all’esterno il
reale indirizzo IP del client interno, rendendolo di conseguenza vulnerabile ad attacchi diretti.
5.2.3.4
Tecniche di tunnel
Questo metodo permette l’attraversamento dei Firewall e NAT attraverso la costituzione di
un tunnel sia per la segnalazione che per il flusso multimediale. Le tecniche di tunnel necessitano
quindi dell’installazione di un nuovo server all’interno della rete privata e un altro nuovo server nel
lato pubblico, server che costituiscono l’inizio e la terminazione del tunnel. Il server esterno
modifica la segnalazione in modo da far apparire la propria interfaccia esterna, ciò permette quindi
al sistema VoIP di instaurare chiamate verso l’esterno e accettarne verso l’interno.
Sebbene questa soluzione non comporti cambiamenti alle politiche di sicurezza esistenti, esso però
introduce dei rischi. In particolare, il server esterno rappresenta un punto di vulnerabilità, che, se
compromesso, può garantire un facile accesso alla rete interna.
Inoltre questa struttura può introdurre ritardi addizionali al flusso multimediale, fatto che riduce la
qualità della voce.
74
5.2.3.5
Application Level Gateway
Questa tecnica consiste nell’installazione di un Firewall-NAT che interpreti i messaggi di
segnalazione e i loro legami con i flussi multimediali.
L’ALG processa i messaggi di segnalazione e il flusso multimediale modificando le informazioni in
essi contenute in modo da far apparire l’indirizzo IP e la porta esterna dell’ALG. Il vantaggio di
questa tecnica è che non intacca assolutamente le politiche di sicurezza definite nel Firewall ed
inoltre consente il mascheramento degli host interni attraverso la visualizzazione nei messaggi
uscenti del solo indirizzo esterno dell’ALG.
Considerando infine che molti produttori di Firewall-NAT consentono un aggiornamento software
dei loro prodotti per supportare le funzionalità di un ALG, questa soluzione è stata considerata la
più opportuna in questa tesi per risolvere il problema Firewall ed il problema NAT.
La progettazione dell’ALG e la sua interazione con il Firewall ed il NAT vengono dettagliatamente
descritti nel capitolo successivo.
75
6
Progettazione del SIP ALG
A fronte dei problemi riscontrati nei capitoli 3 e 4, sulle vulnerabilità di una rete VoIP
ereditati dal substrato IP e sulle vulnerabilità introdotte dal protocollo di segnalazione SIP, e quelli
descritti nel capitolo 5, riguardo la difficoltà di far conciliare un sistema VoIP ed apparati di rete che
garantiscano sicurezza come Firewall e NAT, in questo capitolo verrà proposta una soluzione
globale che consenta di proteggere la rete a livello IP attraverso l’azione di un Firewall ed un NAT e
a livello applicativo attraverso l’attuazione di politiche di sicurezza SIP.
La progettazione della soluzione proposta – un SIP ALG – viene descritta attraverso il linguaggio
formale Specification and Description Language (SDL) [30], di cui è disponibile una breve
descrizione in appendice.
6.1 Sistema di gestione dei messaggi SIP
Sistema di gestione dei messaggi SIP
Blocco: FW/NAT
Ch 1
Ch 18
Processo
Firewall
Ch 2
Processo
NAT L4
Blocco: DNS
Ch 5
Processo
DNS
Ch 6
Ch 7
Ch 8
Ch 4
Ch 3
Ch 17
Ch 9
Processo
SIP
Proxy
Processo
NAT L7
Ch 16
Ch 13
Processo
Controllo
Policies
Ch 10
Processo
SIP
Registrar
Ch 11
Ch 15
Blocco: SIP ALG
Ch 14
Ch 12
Blocco: SIP Server
Processo
Session
Database
Processo
Location
Service
Blocco: Database
Figura 6.1 - SDL: Sistema di gestione dei messaggi SIP
76
Il sistema di gestione dei messaggi SIP è costituito da:
¾
Il blocco FW/NAT: è composto dal processo Firewall, che consente di proteggere la rete interna
dall’intrusione di flusso IP indesiderato, e dal processo NAT L4, costituito da un NAPT che ha il
compito di tradurre i flussi entranti ed uscenti dal dominio e qualora fossero destinati alla porta
assegnata alla segnalazione SIP – la 5060 sia per UDP che per TCP – sia in ingresso che in
uscita deve inoltrarli verso il blocco SIP ALG.
¾
Il blocco SIP Server: è composto dal processo SIP Proxy, indispensabile per la raggiungibilità
dall’esterno degli utenti interni attraverso l’interazione con il processo Location Service del
blocco Database e per la raggiungibilità dall’interno degli utenti appartenenti ad un dominio
esterno attraverso l’interazione con il processo DNS, e dal processo SIP Registrar, necessario
alla gestione delle registrazioni degli utenti amministrativamente appartenenti al dominio.
¾
Il blocco DNS: costituito dal solo processo DNS esso consente la traduzione di indirizzi di tipo
mnemonico in indirizzi di tipo numerico, garantendo l’instradamento dei messaggi diretti
all’esterno del dominio.
¾
Il blocco Database: è composto dal processo Location Service, che viene aggiornato dal
processo SIP Registrar sulla registrazione o de-registrazione degli utenti appartenenti al
dominio e viene consultato dal processo SIP Proxy per garantire la raggiungibilità degli utenti
interni al dominio, e dal processo Session Database, che conserva le informazioni sui dialoghi
attivi nel dominio utili per il corretto funzionamento del blocco SIP ALG.
¾
Il blocco SIP ALG: è l’oggetto di questo capitolo. E’ costituito dal processo NAT L7, in grado di
modificare a livello applicativo i messaggi SIP in modo da risolvere il problema NAT descritto
nel capitolo precedente, e dal processo Controllo Policies, che consente di risolvere il problema
Firewall descritto nel capitolo precedente e che mantiene lo stato di un dialogo SIP in modo da
riconoscere ed eventualmente evitare un tentativo di attacco.
Appare quindi evidente che, per motivi di semplicità realizzativa, il Firewall, il NAPT, il SIP ALG, il
SIP Proxy, il SIP Registrar ed il Location Service costituiscono un unico nodo della rete, nodo che
consente l’interfacciamento con l’esterno. Il SIP Proxy, infatti, costituisce l’outbound proxy [1] del
dominio e quindi gestisce tutto il traffico di segnalazione SIP entrante o uscente. In questo modo il
SIP ALG può costituire una macchina a stati finiti che conserva lo stato di ogni dialogo o
transazione SIP che viene instaurata ed in questo modo rilevare o addirittura evitare gli attacchi
che sono stati studiati precedentemente.
Una seconda scelta realizzativa è il supporto unicamente per il protocollo di trasporto UDP. Essa
costituisce una limitazione, in quanto non consente l’utilizzo della crittografia basta su TLS [29],
che necessita TCP come protocollo di trasporto.
Infine, affinché il processo Controllo Policies ed il blocco SIP Server riescano a distinguere gli utenti
interni alla rete, devono lavorare sulle SIP URI in cui è presente l’indirizzo privato e quindi non
ancora tradotto dal processo NAT L7. Per questo motivo il sistema di gestione dei messaggi SIP
deve essere differenziato nel caso in cui debba gestire un messaggio in ingresso o in uscita.
77
6.1.1 Definizione astratta dei tipi
Alla descrizione generale del sistema segue ora una descrizione formale. Attraverso una
notazione ASN.1 [31] si evidenziano i dati scambiati per effettuare una comunicazione tra i vari
processi, con la specifica del sistema in SDL si descrive in maniera molto sintetica il
comportamento dei processi precedentemente elencati. Tale descrizione è stata limitata
unicamente all’interazione che coinvolgono i processi interni al blocco SIP ALG.
Sistema di Gestione dei Messaggi SIP DEFINITIONS ::=
Canale ::= [APPLICATION 0] CHOICE {ch1 Ch1
ch2 Ch2
ch3 Ch3
ch4 Ch4
ch5 Ch5
ch6 Ch6
ch7 Ch7
ch8 Ch8
ch9 Ch9
ch10 Ch10
ch11 Ch11
ch12 Ch12
ch13 Ch13
ch14 Ch14
ch15 Ch15
ch16 Ch16
ch17 Ch17
ch18 Ch18
}
Ch5 ::= [APPLICATION 5] IP
Ch8 ::= [APPLICATION 8] comandi FCP (Firewall Control Protocol)
Ch12 ::= [APPLICATION 12] CHOICE {
ParametriDialogo[0] SEQUENCE {
From FROM OPTIONAL,
To TO OPTIONAL,
Call-ID CALL-ID OPTIONAL,
CSeq CSEQ OPTIONAL,
ViaUA VIA OPTIONAL,
ViaProxy SEQUENCE OF VIA OPTIONAL,
Method METHOD OPTIONAL},
InitDialogo[1] IMPLICIT ENUMERATED{
78
InizInterna(0),
InizEsterna(1)}
}
Ch14 ::= [APPLICATION 14] CHOICE {
ParametriDialogo[0] SEQUENCE {
From FROM,
To TO,
Call-ID CALL-ID},
InitDialogo[1] IMPLICIT ENUMERATED{
InizInterna(0),
InizEsterna(1)}
}
IP ::= SEQUENCE {SourceAddr ADDRESS,
DestAddr ADDRESS,
udp UDP}
UDP ::= SEQUENCE {SourcePort PORT,
DestPort PORT,
sip SIP}
SIP ::= SEQUENCE {Start-Line CHOICE{
Request-Line[0] IMPLICIT SEQUENCE{
Method METHOD,
Request-URI REQ-URI,
SIP-Version SIP-VER},
Status-Line[1] IMPLICIT SEQUENCE{
SIP-Version SIP-VER,
Status-Code INTEGER,
Reason-Phrase PRINTABLE STRING}
},
ViaProxy SEQUENCE OF VIA OPTIONAL,
ViaUA VIA,
From FROM,
To TO,
Call-ID CALL-ID,
CSeq CSEQ,
Contact SIP-URI OPTIONAL,
Content-Type PRINTABLE STRING OPTIONAL,
Content-Length INTEGER,
sdp SDP OPTIONAL}
METHOD
::=
ENUMERATED
{REGISTER(0),
INVITE(1),
OPTIONS(5)}
SIP-URI ::= SEQUENCE {User PRINTABLE STRING,
Host ADDRESS,
79
ACK(2),
CANCEL(3),
BYE(4),
Port PORT OPTIONAL}
REQ-URI ::= SEQUENCE {Method METHOD,
uri SIP-URI}
VIA ::= SEQUENCE {Transport PRINTABLE STRING,
Host ADDRESS,
Port PORT OPTIONAL,
Branch PRINTABLE STRING}
FROM ::= SEQUENCE {uri SIP-URI,
Tag PRINTABLE STRING}
TO ::= SEQUENCE {uri SIP-URI,
Tag PRINTABLE STRING OPTIONAL}
CALL-ID ::= SEQUENCE {Numcall PRINTABLE STRING,
Host ADDRESS}
CSEQ ::= SEQUENCE {Numseq INTEGER,
Method METHOD}
SDP ::= SEQUENCE {o SEQUENCE {Username PRINTABLE STRING,
IdSession LONG INTEGER,
Version LONG INTEGER,
Net-Type PRINTABLE STRING,
Addr-Type PRINTABLE STRING,
Host ADDRESS},
c SEQUENCE {Net-Type PRINTABLE STRING,
Addr-Type PRINTABLE STRING,
Host ADDRESS},
m SEQUENCE {Media PRINTABLE STRING,
Port PORT,
Transport PRINTABLE STRING,
Fmt-List INTEGER}
}
ADDRESS ::= LONG INTEGER
PORT ::= INTEGER
SIP-Version SIP-VER ::= “SIP/2.0”
ALGAddr ADDRESS ::= indirizzo esterno del FW
LocalAddr ADDRESS ::= indirizzo interno del FW
SIPPort ::= porta esterna per cui passano i messaggi SIP
RTPPort ::= coppia di porte esterne per cui passano i messaggi RTP/RTCP
80
6.1.2 Messaggi SIP uscenti
La sequenza di canali attraversati da un messaggio generato all’interno e destinato
all’esterno viene descritta in questo paragrafo. I messaggi che transitano nel canale 1 giungono al
processo Firewall, che controlla eventuali violazioni delle politiche di sicurezza fino al livello di
trasporto dello stack TCP/IP. Se il pacchetto non viola alcuna politica viene consegnato al processo
NAT L4 attraverso il canale 2. Esso, come tutti i NAPT, modifica le intestazioni IP e UDP
sostituendo l’indirizzo IP e la porta UDP con quelle dell’interfaccia esterna del sistema. Se il
pacchetto ha la porta 5060 come destinazione il pacchetto viene consegnato al processo Controllo
Policies attraverso il canale 7. Esso agisce solamente a livello applicativo e poiché è una macchina
a stati finiti monitora continuamente lo stato del dialogo o della transazione SIP. Perché riesca ad
interagire con il processo NAT L7 deve continuamente aggiornare il database delle sessioni
attraverso il processo Session Database. Infine, se il messaggio SIP giunto non viola alcuna regola
viene instradato verso il processo SIP Proxy o SIP Registrar, attraverso il canale 10 o 11.
Ovviamente il processo SIP Registrar gestisce solamente richieste REGISTER, mentre il SIP Proxy
tutte le altre. Se questi due processi dovessero generare una risposta destinata al mittente del
messaggio giunto, la sequenza dei canali che essa dovrebbe percorrere è esattamente l’inverso di
quella che ha effettuato per giungere al blocco SIP Server. Il messaggio originale, invece, dopo
essere stato processato dal blocco SIP Server viene consegnato attraverso il canale 9 al processo
NAT L7, che, in base alle informazioni della sessione ottenute dal processo Session Database sul
canale 14, modifica i campi dell’intestazione del messaggio SIP e SDP se presente. Il pacchetto IP
viene quindi riconsegnato al processo Firewall che lo inoltra verso l’esterno.
Sistema di gestione dei messaggi SIP uscenti
Blocco: FW/NAT
Ch 1
Ch 18
Processo
Firewall
Ch 2
Processo
NAT L4
Blocco: DNS
Processo
DNS
Ch 6
Ch 7
Ch 8
Ch 4
Ch 3
Ch 17
Ch 9
Processo
SIP
Proxy
Processo
NAT L7
Ch 16
Processo
Controllo
Policies
Ch 10
Ch 11
Processo
SIP
Registrar
Ch 15
Blocco: SIP ALG
Ch 14
Ch 12
Blocco: SIP Server
Processo
Session
Database
Processo
Location
Service
Blocco: Database
Figura 6.2 - SDL: Sistema di gestione dei messaggi SIP uscenti
81
6.1.3 Messaggi SIP entranti
Come già accennato precedentemente, i messaggi entranti nel dominio di appartenenza
del sistema seguono un percorso diverso da quelli uscenti. In questo caso infatti i pacchetti IP
pervengono al processo Firewall attraverso il canale 18 e se non violano alcuna politica di sicurezza
vengono consegnati al processo NAT L4. In esso avviene la traduzione degli indirizzi IP e delle
porte di destinazione se già appartenenti ad un flusso, altrimenti il comportamento varia a seconda
del servizio a cui sono associati. Nel caso in cui, comunque, la porta di destinazione sia la 5060 o
una associata dal Firewall al servizio SIP, il processo NAT L4 attraverso il canale 5 passa il
pacchetto IP al processo NAT L7. E’ evidente quindi la differenza con il caso precedente, infatti
avviene subito la traduzione a livello applicativo degli indirizzi. E’ stata scelta questa soluzione
implementativa perché il processo Controllo Policies ed il blocco SIP Server abbiano una visibilità
‘interna’ dei dialoghi e transazioni SIP. In questo modo rimane evidente per essi chi internamente
ha originato o verso chi è destinato il messaggio SIP che stanno trattando. Dopo la traduzione a
livello applicativo il pacchetto IP passa attraverso il canale 13 al processo Controllo Policies. Se il
messaggio non viola alcuna politica di sicurezza viene instradato verso il blocco SIP Server
attraverso il canale 10 o 11, per giungere infine al processo Firewall attraverso il canale 3 o 4 e
entrare nel dominio attraverso il canale 1. Le eventuali risposte generate dal blocco SIP Server
seguono la sequenza di canali: 13, 5, 2 e 18.
Sistema di gestione dei messaggi SIP entranti
Blocco: FW/NAT
Ch 1
Ch 18
Processo
Firewall
Ch 2
Processo
NAT L4
Blocco: DNS
Processo
DNS
Ch 5
Ch 8
Ch 4
Ch 3
Ch 17
Processo
SIP
Proxy
Processo
NAT L7
Ch 16
Ch 13
Processo
Controllo
Policies
Ch 10
Ch 11
Processo
SIP
Registrar
Ch 15
Blocco: SIP ALG
Ch 14
Ch 12
Blocco: SIP Server
Processo
Session
Database
Processo
Location
Service
Blocco: Database
Figura 6.3 - SDL: Sistema di gestione dei messaggi SIP entranti
82
Nei paragrafi successivi verranno descritti dettagliatamente i processi appartenenti al blocco SIP
ALG: processo NAT L7 e processo Controllo Policies. Di essi verranno descritti inoltre le interazioni
con i blocchi adiacenti.
6.2 Processo NAT L7
Lo scopo di questo processo è sostituire ogni occorrenza di indirizzi privati all’interno dei
messaggi SIP e SDP con l’indirizzo pubblico dell’interfaccia esterna del Firewall, ed inoltre sostituire
ogni occorrenza di porte degli UA interni con quelle destinate dal Network Address and Port
Translator (o NAT L4) per il dialogo SIP e la sessione RTP.
I campi dell’intestazione dei messaggi SIP interessati a questo cambiamento sono molteplici: il
campo Via, Contact, To, From, la Request-URI, Call-ID, i campi c, o ed m del messaggio SDP…
Tuttavia sostituire semplicemente ogni occorrenza di indirizzi privati non è una soluzione efficace,
infatti è importante che l’ALG sappia non solo da quale parte – interna o esterna – la
comunicazione è stata iniziata, ma anche se si tratta di una richiesta o di una risposta. Si consideri
infatti il campo Call-ID. Esso è una URI formata da una sequenza randomica locale più l’indirizzo
dell’host: “local-id@host”. Il valore di questo campo viene stabilito dallo UAC che inizia il dialogo e
rimane inalterato per tutta la sua durata. E’ evidente quindi che se nella porzione host del Call-ID
c’è un indirizzo privato, esso va sostituito con quello pubblico dell’interfaccia esterna, ma solamente
nel caso in cui il messaggio sia in uscita dal dominio in cui è presente lo UAC. Il procedimento
inverso deve accadere per i messaggi in ingresso, da indirizzo pubblico deve essere trasformato in
indirizzo privato. Nessun cambiamento va invece effettuato all’ingresso del dominio dell’UAS, visto
che esso non deve modificare tale campo.
E’ stato quindi necessario distinguere dapprima i messaggi se entranti od uscenti dal dominio. Ciò è
riscontrabile da quale canale arrivano i messaggi al processo NAT L7: se dal canale 5 allora sono
entranti (inbound) se dal canale 9 allora sono uscenti (outbound) dal dominio. La distinzione
successiva riguarda il caso in cui i messaggi facciano parte di un dialogo iniziato dall’interno o
dall’esterno o addirittura non facciano parte di alcun dialogo. Questa informazione viene ottenuta
attraverso l’interazione con il processo Session Database, che viene aggiornato dal processo
Controllo Policies.
Infine l’ultima distinzione viene fatta in base al fatto che il messaggio che il NAT L7 sta trattando
sia una richiesta o una risposta SIP, visto che i campi dell’intestazione da modificare sono
differenti.
83
Inbound
request
Inbound
response
Outbound
request
Outbound
response
(I)
Campi
Dialogo iniaziato
dall’interno
Dialogo iniziato dall’esterno
Request-URI
ALG Address -> Local Address (V)
ALG Address -> Local Address (I) (V)
Via
Non modificare
Non modificare
To
ALG Address -> Local Address
ALG Address -> Local Address (I)
From
Non modificare
Non modificare
Call-ID
Non modificare
Contact
Non modificare
Non modificare
SDP
Non modificare
Non modificare
Request-URI
(II)
(II)
Via
To
Non modificare
Non modificare
From
Call-ID
Non modificare
Contact
Non modificare
Non modificare
SDP
Non modificare
Non modificare
Request-URI
Non modificare
Non modificare
Via
Local Address -> ALG Address
To
Non modificare
Non modificare
From
Call-ID
Non modificare
Contact
Local Address -> ALG Address (IV)
SDP
(III)
(III)
Request-URI
(II)
(II)
Via
Non modificare
Non modificare
To
Non modificare
From
Non modificare
Non modificare
Call-ID
Non modificare
Contact
SDP
(III)
(III)
In caso di REGISTER, INVITE e OPTIONS destinata al processo SIP Proxy non
modificare questo campo
(II)
Le risposte non hanno il campo Request-URI
(III)
Se il messaggio SIP ne contiene uno SDP, modificarne il campo o, c ed m e ricalcolare
il campo Content-Length.
(IV)
Modificare anche il valore della porta associata al campo Contact
(V)
Modificare anche il valore della porta associata al campo Request-URI
84
6.2.1 Messaggi in ingresso
Attesa
Messaggio
SIP
ch5.sip
ch14.ParametriDialogo.To ::= ch5.sip.To
ch14.ParametriDialogo.From ::= ch5.sip.From
ch14.ParametriDialogo.Call-ID ::= ch5.sip.Call-ID
ch14.ParametriDialogo
Attesa Risposta
DB Sessione
ch14.InitDialogo
INIZ_INTERNA
Request-Line
ch5.sip.Start-Line
- Inbound Request
Iniziata
dall’interno
ch14.InitDialogo
INIZ_ESTERNA
o NULL
Status-Line
Request-Line
- Inbound Response
Iniziata
dall’interno
- Inbound Request
Iniziata
dall’esterno
- Inbound Request
Iniziata
dall’interno
ch5.sip.Start-Line
- Inbound Response
Iniziata
dall’esterno
- Inbound Response
Iniziata
dall’esterno
ch5.sip.Request-Line.Request-URI.uri.Host ::= ch5.ip.DestAddr
ch5.sip.Request-Line.Request-URI.uri.Port ::= 5060
ch5.sip.To.uri.Host ::= ch5.ip.DestAddr
ch5.sip.Call-ID.Host ::= ch5.ip.DestAddr
ch5.sip.ViaUA.Host ::= ch5.ip.DestAddr
ch5.sip.From.uri.Host ::= ch5.ip.DestAddr
ch13.sip
ch13.sip
Attesa
Messaggio
SIP
Attesa
Messaggio
SIP
- Inbound Response
Iniziata
dall’interno
ch5.sip.ViaUA.Host ::= ch5.ip.DestAddr
ch5.sip.From.uri.Host ::= ch5.ip.DestAddr
ch5.sip.Call-ID.Host ::= ch5.ip.DestAddr
ch13.sip
Attesa
Messaggio
SIP
85
Status-Line
- Inbound Request
Iniziata
dall’esterno
REGISTER o
INVITE
ch5.sip.Request-Line.Method
altri
OPTIONS
ch5.sip.RequestLine.Request-URI
= ALGAddr
!= ALGAddr
ch5.sip.Request-Line.Request-URI.uri.Host ::= ch5.ip.DestAddr
ch5.sip.Request-Line.Request-URI.uri.Port ::= 5060
ch5.sip.To.uri.Host ::= ch5.ip.DestAddr
ch13.sip
Attesa
Messaggio
SIP
ch13.sip
Attesa
Messaggio
SIP
6.2.2 Messaggi in uscita
Nel caso di messaggi uscenti dal dominio di interesse, affinché il sistemi funzioni è
necessario modificare anche i messaggi SDP che descrivono la sessione multimediale da instaurare.
In essi infatti è contenuto sia l’indirizzo IP sia la porta su cui si vuole ricevere il flusso multimediale.
Attesa
Messaggio
SIP
ch9.sip
Attesa Risposta
DB Sessione
ch14.InitDialogo
INIZ_INTERNA
Request-Line
- Outbound Request
Iniziata
dall’interno
ch9.sip.Start-Line
ch14.InitDialogo
INIZ_ESTERNA
Status-Line
Request-Line
- Outbound Response
Iniziata
dall’interno
- Outbound Request
Iniziata
dall’esterno
86
ch9.sip.Start-Line
Status-Line
- Outbound Response
Iniziata
dall’esterno
- Outbound Request
Iniziata
dall’interno
ch9.sip.ViaUA.Host ::= ALGAddr
ch9.sip.From.uri.Host ::= ALGAddr
ch9.sip.Call-ID.Host ::= ALGAddr
ch9.sip.Contact.uri.Host ::= ALGAddr
ch9.sip.Contact.uri.Port ::= ch9.ip.udp.SourcePort
=0
ch9.sip.Content-Length
>0
ch6.sip
Application/SDP
ch7.sip.Content-Type
Attesa
Messaggio
SIP
- Outbound Cambiamento
SDP
- Outbound Response
Iniziata
dall’interno
ch9.sip.To.uri.Host ::= ALGAddr
ch9.sip.Call-ID.Host ::= ALGAddr
=0
>0
ch6.sip
Application/SDP
Attesa
Messaggio
SIP
SDP
- Outbound Request
Iniziata
dall’esterno
ch9.sip.ViaUA.Host ::= ALGAddr
ch9.sip.From.uri.Host ::= ALGAddr
=0
ch6.sip
Attesa
Messaggio
SIP
>0
Application/SDP
SDP
87
- Outbound Response
Iniziata
dall’esterno
ch9.sip.Contact.uri.Port ::= ALGPort
=0
ch6.sip
Attesa
Messaggio
SIP
>0
Application/SDP
SDP
Ecco infine le occorrenze di indirizzi IP e porte interne che devono essere sostituite con quelle
esterne pubbliche. La procedura che segue è quella di ricalcalo del numero di byte del messaggio
SDP, numero che deve essere inserito nel campo Content-Length del messaggio SIP.
SDP
ch9.sip.sdp.o.Host ::= ALGAddr
ch9.sip.sdp.c.Host ::= ALGAddr
ch9.sip.sdp.m.Port ::= RTPPort
Ricalcolare
ch6.sip
Attesa
Messaggio
SIP
6.3 Processo Controllo Policies
Lo scopo di questo processo è verificare che non avvengano gli attacchi descritti nel
paragrafo 4.1. Il processo Controllo Policies è una macchina a stati finiti che tiene memoria dello
stato di un dialogo SIP controllando e verificando ogni messaggio che transita attraverso di essa.
Essa garantisce le funzionalità descritte nello standard [1], accettando e gestendo tutti e sei i
metodi elencati: INVITE, ACK, REGISTER, BYE, CANCEL e OPTIONS.
Nel caso in cui il flusso di messaggi SIP non violi alcuna regola di sicurezza, allora il processo
Controllo Policies gestisce l’apertura e la chiusura delle porte sull’interfaccia esterna del Firewall, sia
88
per quanto riguarda la porta destinata ai messaggi di segnalazione SIP che la coppia di porte
destinata al flusso multimediale RTP/RTCP. Durante lo studio di questa tesi l’unico protocollo che è
stato individuato per l’interazione tra il SIP ALG e il Firewall è il Firewall Control Protocol (FCP)
[32]. Esula dagli obiettivi di questa tesi l’identificazione e l’analisi dei comandi FCP che il processo
Controllo Policies e il processo Firewall devono scambiarsi. Verranno semplicemente citati dei
‘metacomandi’ che consentano al processo Controllo Policies di aprire o chiedere le porte del
Firewall.
Compito del processo Controllo Policies è inoltre aggiornare il processo Session Database sui
dialoghi e transazioni che stanno avvenendo tra gli utenti, in modo tale da rendere disponibili al
processo NAT L7 le informazioni necessarie per il suo corretto funzionamento, ossia la verifica che i
messaggi che stanno transitando appartengano ad un dialogo iniziato dall’interno oppure
dall’esterno.
Diversamente dal caso del NAT L7, in cui la natura del processo era decisamente combinatoria, per
il processo Controllo Policies la sequenzialità dei messaggi assume un’importanza fondamentale.
Per verificare infatti che sta avvenendo un attacco, infatti, non è sufficiente verificare che il
messaggio SIP sia correttamente formato o che sia generato dallo UA legittimo, poiché le tecniche
di spoofing degli indirizzi consentono di mascherare totalmente l’identità di chi genera un pacchetto
IP. E’ apparso necessario, quindi, gestire e verificare la corretta sequenzialità dei messaggi di un
dialogo SIP, in modo da individuare eventuali messaggi maliziosi che tentino di perpetrare degli
attacchi insinuandosi nel normale flusso di segnalazione. Per fare ciò si è posta l’attenzione sui
flussi di chiamata descritti in [9].
Alla luce della precedente analisi, l’arrivo di risposte SIP esterne ad un dialogo è considerato un
tentativo di attacco decisamente malriuscito, giacché non è previsto dallo standard SIP [1] che
vengano generate risposte da uno UA senza che ricevi alcuna richiesta.
Quindi la suddivisione che è stata seguita per il processo Controllo Policies è in base al tipo di
richiesta che origina il dialogo – INVITE, REGISTER e OPTIONS, a cui si è aggiunto il metodo BYE
perché rimanga la compatibilità con la procedura di re-INVITE. Quindi richieste CANCEL o ACK
esterne ad un dialogo sono considerate alla stregua delle risposte a nessuna richiesta: tentativi di
attacco. Per quanto riguarda il metodo BYE, esso viene considerata una richiesta che origina un
dialogo perché la sua annessione al metodo INVITE avrebbe reso difficile la gestione della
procedura di re-INVITE. Infatti come descritto nello standard SIP [1], è plausibile che giungano
due transazioni di INVITE – di cui la seconda è considerata re-INVITE – all’interno dello stesso
dialogo, senza che la prima sia terminata da un BYE.
L’unica analogia con il processo NAT L7 è la suddivisione iniziale in messaggi uscenti e messaggi
entranti, da intendere come dialoghi iniziati da messaggi uscenti o entranti.
89
INVITE
Genera un
messaggio di
errore
Fuori Sequenza:
Possibile Attacco
Denial of Service
Fuori Sequenza:
Possibile Attacco
Man in the Middle
- Inbound BYE
- Inbound OPTIONS
- Inbound REGISTER
- Inbound INVITE
REGISTER
OPTIONS
ch13.sip.RequestLine.Method
BYE
Request-Line
CANCEL
ACK
ch13.sip.Start-Line
ch13.sip
Attesa
Messaggio
SIP
1XX
2XX
Status-Line
3XX
ch13.sip.StatusLine.Status-Code
4XX
5XX
6XX
6.3.1 Messaggi in ingresso
Le richieste CANCEL ed ACK, assieme ad ogni tipo di risposta che giungono al processo
Controllo Policies al di fuori di un dialogo vengono considerati dei tentativi di attacco perché fuori
sequenza. Da questa analisi quindi scaturiscono quattro tipi di dialoghi, ognuno caratterizzato dal
tipo di messaggio che ne dà origine: REGISTER, OPTIONS, INVITE e BYE.
90
6.3.1.1
REGISTER
In caso di richiesta di registrazione entrante nel dominio, l’unico destinatario può essere il
processo Registrar Server, altrimenti il messaggio è malformato e quindi va scartato. In caso
affermativo si deve controllare che le richieste siano generate in sequenza – ossia venga rispettato
il campo CSeq dell’intestazione – e che le richieste provenienti dallo stesso UA abbiano sempre lo
stesso valore del campo Call-ID, come richiesto in [1].
- Inbound REGISTER
= ALGAddr
Verifica sintattica del
messaggio SIP
- Inbound -
Transazione
iniziata dall’esterno
ch12.ParametriDialogo.Method ::= ch13.sip.RequestLine.Request-URI.Method
ch12.ParametriDialogo.From ::= ch13.sip.From.uri
!= ALGAddr
Scarta il
pacchetto
Possibile Attacco
Genera un
messaggio di
errore
Attesa Risposta
DB Sessione
!=
ch12.ParametriDialogo.
Call-ID.Numcall
ch13.sip.Call-ID.Numcall
= ch12.ParametriDialogo.Call-ID.Numcall
!=
(ch12.ParametriDialogo.
CSeq.Numseq) + 1
Messaggio malformato:
Possibile Attacco
Genera un
messaggio
di errore
ch13.sip.CSeq.Numseq
= (ch12.ParametriDialogo.CSeq.Numseq) + 1
- Inbound REGISTER
parte 2
Se la richiesta REGISTER rispetta questi vincoli, che garantiscono in minima parte l’autenticità del
mittente, essa viene inoltrata attraverso il canale 11 al processo SIP Registrar, il quale deve
necessariamente implementare un servizio di autenticazione HTTP Digest [33]. Per questo motivo,
le risposte ritenute plausibili alla richiesta di registrazione sono 200 OK, 401 Unauthorized e 403
Forbidden [9]. Qualora non dovesse giungere alcuna risposta un timeout libererebbe ogni risorsa
occupata dalla suddetta richiesta.
91
- Inbound REGISTER
parte 2
ch11.sip ::= ch13.sip
ch11.sip
Attesa Messaggio
SIP Risposta da Registrar
ch11.sip
timeout
200
ch11.sip.StartLine.Status-Line.StatusCode
403
401
ch13.sip
Attesa
Messaggio
SIP
6.3.1.2
OPTIONS
Il metodo OPTIONS di SIP permette ad uno UA di chiedere ad un altro UA o ad un Server
le capacità (capabilities) che supporta. Poiché tutti gli UA devono essere in grado di processare
richieste OPTIONS [1], allora anche il processo Controllo Policies deve poter gestire tale tipo di
messaggio. Si deve differenziare però il caso in cui destinatario della richiesta entrante nel dominio
sia il processo SIP Proxy oppure uno UA interno. Nel primo caso infatti tutto il dialogo transita
attraverso la porta 5060 dell’interfaccia esterna del Firewall, nel secondo caso invece si deve
assegnare attraverso il processo NAT L4 una porta al dialogo e far passare la segnalazione
attraverso essa. Questa distinzione avviene in base alla presenza o meno della porzione user nella
Request-URI. Se è assente allora il messaggio OPTIONS è destinato al server, altrimenti allo UA
che verrà raggiunto attraverso i dati memorizzati nel processo Location Service. In quest’ultimo
caso quindi il processo Controllo Policies deve gestire l’apertura e successivamente la chiusura delle
porte esterne attraverso comandi del protocollo FCP.
92
- Inbound OPTIONS
messaggio SIP
- Inbound -
Transazione
ch10.sip :== ch13.sip
ch10.sip
ch13.sip.Request-Line.RequestURI.User = NULL
no
si
Attesa Messaggio
SIP Risposta da UA interno
Attesa Messaggio
SIP Risposta da Proxy
ch7.sip
ch10.sip
timeout
timeout
200
200
4XX
messaggio SIP
- Outbound -
4XX
ch13.sip
ch8: con FCP aprire la
porta esterna per SIP
Attesa
Messaggio
SIP
ch10.sip
ch8: con FCP chiudere
la porta esterna per SIP
Attesa
Messaggio
SIP
6.3.1.3
INVITE
Le richieste INVITE che giungono alla porta 5060 dell’interfaccia esterna del Firewall
vengono accettate e processate dal processo Controllo Policies. Da esse ha inizio una procedura
molto più complessa rispetto a quelle viste nei due precedenti paragrafi, in cui è previsto il
fallimento del tentativo di instaurazione di chiamata causato dal processo SIP Proxy o dallo UA
interno, la cancellazione attraverso il metodo CANCEL ancora durante la fase di instaurazione o il
successo e di conseguenza il passaggio per le porte destinate a RTP/RTCP di flusso multimediale.
93
L’arrivo di messaggi di redirezione – come le risposte appartenenti alla classe 3XX – oppure
messaggi di conferma – come la risposta 200 OK – fuori sequenza da come indicato in [9] vengono
considerati attacchi, in quanto corrispondono al flusso di messaggi descritti nel capitolo 4.
- Inbound INVITE
messaggio SIP
- Inbound -
no
ch13.sip.Contact = NULL
Transazione
si
Messaggio
malformato
ch10.sip
Genera un
messaggio
di errore
Attesa Messaggio
ch10.sip
timeout
ch13.sip
100
Attesa Messaggio
4XX
5XX
6XX
Attesa Messaggio
SIP ACK da UA esterno
ch7.sip
ch10.sip
timeout
messaggio SIP
- Outbound -
timeout
messaggio SIP
- Inbound 4XX
5XX
6XX
180
ch10.sip
- Inbound INVITE
ringing
2XX
3XX
Sequenza Errata:
Possibile Attacco
dall’interno
Session Hijacking
Sequenza Errata:
Possibile Attacco
dall’interno
Man in the Middle
Genera un
messaggio di
errore
Attesa
Messaggio
SIP
- Inbound INVITE
UA failed
94
- Inbound INVITE
ringing
ch10.sip
Attesa Possibile Messaggio
SIP CANCEL da UA esterno
ch13.sip
timeout
ch13.sip.Request-Line.
Method = CANCEL
si
no
- Inbound CANCEL
Attesa Messaggio
ch7.sip
timeout
messaggio SIP
- Outbound -
Request-Line
ch7.sip.Start-Line
ch7.sip.Start-Line
altri
200
BYE
Sequenza Errata:
Possibile Attacco
dall’interno
Denial of Service
Status-Line
486
3XX
- Inbound INVITE
successful
Sequenza Errata:
Possibile Attacco
dall’interno
Man in the Middle
- Inbound INVITE
busy
Genera un
messaggio di
errore
Genera un
messaggio di
errore
Si vede quindi dal diagramma precedente come l’arrivo di una risposta 3XX viene considerato un
tentativo di attacco Man in the Middle, in quanto fuori sequenza e quindi è visto come un modo di
rubare la sessione SIP. Analogamente, poiché il chiamato non può generare un messaggio BYE
prima di ricevere il messaggio ACK, questa sequenza viene considerata un possibile attacco di
Denial of Service proveniente dall’interno.
95
Se lo UAS all’interno dovesse rispondere con un 200 OK allora, dopo l’arrivo dell’ACK dall’esterno il
processo Controllo Policies deve aprire la coppia di porte destinate al flusso multimediale
RTP/RTCP. In caso contrario il processo Controllo Policies deve chiedere la porta destinata alla
segnalazione SIP che il messaggio di risposta dello UAS uscendo aveva aperto.
- Inbound INVITE
successful
- Inbound INVITE
busy
- Inbound INVITE
UA failed
ch7.sip.Cseq.Method = INVITE
no
ch10.sip
si
Attesa Messaggio
Messaggio
malformato
ch10.sip
ch13.sip
timeout
Genera un
messaggio
di errore
Attesa Messaggio
SIP ACK da Proxy
messaggio SIP
- Inbound -
ch10.sip
ch8: con FCP aprire le
porte esterne per RTP
timeout
ch7.sip
ch10.sip
Attesa Messaggio
SIP ACK da UA interno
Attesa
Messaggio
SIP
ch10.sip
timeout
messaggio SIP
- Outbound -
ch7.sip
Attesa
Messaggio
SIP
La CANCEL è una richiesta allo UAS di interrompere il processamento di una richiesta
precedentemente inviata e generare per essa un messaggio di errore. La CANCEL non ha effetto su
richieste per cui lo UAS ha già generato una risposta definitiva, per questo motivo è utile cancellare
solo quelle richieste che causano un tempo di processamento accettabile. Di conseguenza la
richiesta CANCEL dovrebbe essere diretta solamente a richieste di tipo INVITE [1]. Per questo
96
motivo il processo Controllo Policies accetta richieste di cancellazione solamente se all’interno di un
dialogo iniziato da un INVITE.
- Inbound CANCEL
messaggio SIP
- Inbound -
Attesa Parametri
DB Sessione
ch12.InitDialogo
ch13.sip.To = ch12.To
ch13.sip.From.uri = ch12.From.uri
ch13.sip.From.Tag = NULL
ch13.sip.Request-URI = ch12.Request-URI
ch13.sip.CSeq.Numseq = ch12.CSeq.Numseq
ch13.sip.Call-ID = ch12.Call-ID
no
Messaggio Malformato:
Possibile Attacco
Denial of Service
si
Genera un
messaggio
di errore
ch10.sip
Attesa Messaggio
ch10.sip
timeout
ch13.sip
200
Attesa Messaggio
481
Genera un
messaggio
di errore
ch7.sip
timeout
- Inbound CANCEL
successful
Quando arriva una richiesta CANCEL deve essere verificato che essa si riferisca ad un INVITE già
processata dal processo Controllo Policies, altrimenti si tratta di una richiesta malformata e di
conseguenza va scartata. In caso affermativo il processo si aspetta di ricevere tutto il flusso
descritto in [9].
97
- Inbound CANCEL
successful
messaggio SIP
- Outbound -
200
si
481
Sequenza Errata:
Possibile Attacco
Denial of Service
ch7.sip.CSeq.
Method = CANCEL
no
Sequenza Errata:
Possibile Attacco
dall’interno
Man in the Middle
ch10.sip
Attesa Messaggio
Genera un
messaggio
di errore
Genera un
messaggio
di errore
ch13.sip
timeout
messaggio SIP
- Outbound -
481
487
ch13.sip.CSeq.
Method = INVITE
si
no
Possibile Attacco
ch10.sip
Genera un
messaggio
di errore
Attesa Messaggio
SIP ACK da Proxy
ch10.sip
timeout
ch13.sip
- Outbound CANCEL
Successful
parte 2
Anche in questo caso eventuali messaggi fuori sequenza che fanno parte di questo dialogo
vengono considerati attacchi provenienti o dall’interno o dall’esterno, a seconda dei casi specifici.
98
La procedura termina con la chiusura della porta esterna del Firewall destinata al flusso di
segnalazione SIP, e il processo ritorna nello stato di attesa di un messaggio SIP appartenente ad
un nuovo dialogo.
- Outbound CANCEL
Successful
parte 2
Attesa Messaggio
ch13.sip
timeout
messaggio SIP
- Inbound -
Method = ACK
no
si
Messaggio Errata:
Possibile Attacco
Ch10.sip ::= ch13.sip
Genera un
messaggio
di errore
ch10.sip
Tramite FCP chiudere
Attesa
Messaggio
SIP
6.3.1.4
BYE
La procedura che il messaggio BYE dà luogo ha l’obiettivo di verificare che effettivamente
esso si riferisca ad un dialogo esistente e che sia transitato già attraverso il processo Controllo
Policies, ed infine ha lo scopo di chiudere le porte che si riferiscono al dialogo sia per quanto
riguarda la segnalazione SIP sia per quanto riguarda il flusso multimediale RTP/RTCP.
Inoltre, secondo [1], se la risposta ad una richiesta di BYE è un messaggio 481 Call/Transaction
Does Not Exists oppure 408 Request Timeout o addirittura alcuna risposta, lo UAC deve
considerare la sessione ed il relativo dialogo terminato.
99
200
100
Attesa
Messaggio
SIP
Tramite FCP chiudere la
Tramite FCP chiudere le
ch10.sip
messaggio SIP
- Outbound -
ch7.sip
Attesa Messaggio
ch10.sip
- Inbound BYE
successful
408
481
timeout
- Inbound BYE
successful
si
no
= NULL
Genera un
messaggio
di errore
Procedura irregolare:
non esiste il dialogo che lo
UA vuole terminare
Possibile Attacco
Denial of Service
ch12.InitDialogo
ch13.sip.Via = ch12.ParametriDialogo.Via
ch12.ParametriDialogo.Via
Attesa ParametriDialogo
DB Sessione
!= NULL
ch12.InitDialogo
Attesa InitDialogo
DB Sessione
ch12.ParametriDialogo.Method ::= ch13.sip.Request-Line.Request-URI.Method
messaggio SIP
- Inbound -
- Inbound BYE
Genera un
messaggio di
errore
Fuori Sequenza:
Possibile Attacco
dall’interno
Man in the Middle
3XX
INVITE
- Outbound BYE
- Outbound OPTIONS
- Outbound INVITE
- Outbound REGISTER
BYE
REGISTER
OPTIONS
Request-Line
CANCEL
ACK
ch7.sip.Start-Line
ch7.sip
Attesa
Messaggio
SIP
1XX
2XX
Status-Line
4XX
5XX
Fuori Sequenza:
Possibile Attacco
dall’interno
Denial of Service
6XX
6.3.2 Messaggi in uscita
In maniera del tutto analoga ai messaggi entranti, le richieste di tipo ACK o CANCEL e le
risposte di qualsiasi classe vengono considerate fuori sequenza perché esterne ad un dialogo e
quindi vengono scartate. Anche in questo caso quindi i dialoghi hanno inizio attraverso quattro
richieste: REGISTER, OPTIONS, INVITE e BYE
101
6.3.2.1
REGISTER
Il processo Controllo Policies deve consentire la registrazione di utenti amministrativamente
appartenenti al dominio al processo Registrar Server e utenti fisicamente appartenenti al dominio a
Registrar Server di altri domini. Tutto ciò perché la mobilità è una delle caratteristiche di SIP che
deve essere garantita.
Nel primo caso i controlli sono analoghi a quelli descritti per le REGISTER entranti nel dominio,
ossia sui campi Call-ID e CSeq dell’intestazione. Se la richiesta è corretta, viene inoltrata al
processo Registrar Server attraverso il canale 11.
- Outbound REGISTER
= ALGAddr
messaggio SIP
- Outbound -
ch12.ParametriDialogo.Method ::= ch7.sip.RequestLine.Request-URI.Method
ch12.ParametriDialogo.From ::= ch7.sip.From.uri
!= ALGAddr
Transazione
iniziata dall’interno
ch10.sip
Attesa Risposta
DB Sessione
!=
ch12.ParametriDialogo.
Call-ID.Numcall
- Outbound REGISTER
parte 3
ch7.sip.Call-ID.Numcall
= ch12.ParametriDialogo.Call-ID.Numcall
!=
(ch12.ParametriDialogo.
CSeq.Numseq) + 1
ch7.sip.CSeq.Numseq
= (ch12.ParametriDialogo.CSeq.Numseq) + 1
Messaggio malformato:
Possibile Attacco
Genera un
messaggio
di errore
- Outbound REGISTER
parte 2
E le risposte plausibili generate dal processo Registrar Server sono 200 OK, 401 Unauthorized e
403 Forbidden [9], queste ultime due sono frutto del fatto che il Registrar Server deve
implementare l’HTTP Digest Authentication.
Nel caso in cui la richiesta REGISTER è destinata ad un dominio esterno, il processo Controllo
Policies deve aprire una porta destinata alla segnalazione SIP sull’interfaccia esterna del Firewall ed
inoltrare verso il processo Proxy Server sul canale 10 la richiesta di registrazione.
102
- Outbound REGISTER
parte 3
- Outbound REGISTER
parte 2
ch10.sip
Attesa Messaggio
SIP Risposta da Registrar esterno
ch11.sip
Attesa Messaggio
SIP Risposta da Registrar
messaggio SIP
- Inbound -
timeout
ch11.sip
ch13.sip
timeout
200
403
200
403
401
401
ch7.sip
Attesa
Messaggio
SIP
ch10.sip
Attesa
Messaggio
SIP
6.3.2.2
OPTIONS
Il destinatario di una richiesta OPTIONS che attraverso il sistema di gestione dei messaggi
SIP può essere o un server esterno – UAS o Server che sia – oppure il processo SIP Proxy del
blocco SIP Server.
Questa distinzione, effettuata in base alla Request-URI della richiesta, comporta una differente
gestione del messaggio stesso. Nel caso in cui il destinatario è esterno al dominio, il processo
Controllo Policies deve gestire l’apertura e la chiusura delle porte dell’interfaccia esterna del
Firewall destinate alla segnalazione SIP dello UAC che ha generato il messaggio OPTIONS.
103
- Outbound OPTIONS
messaggio SIP
- Outbound -
Transazione
ch7.sip.Request-Line.RequestURI.Host = LocalAddr
no
si
ch10.sip
Attesa Messaggio
ch10.sip
ch10.sip
Attesa Messaggio
SIP Risposta da UA esterno
timeout
200
ch13.sip
4XX
timeout
200
4XX
ch7.sip
messaggio SIP
- Inbound -
Attesa
Messaggio
SIP
ch10.sip
Attesa
Messaggio
SIP
6.3.2.3
INVITE
Il processo Controllo Policies è in grado di gestire richieste di INVITE dirette all’esterno del
dominio che serve. Di esse è inoltre in grado di garantire il corretto funzionamento anche in caso di
fallimento della fase di instaurazione, redirezione della richiesta di INVITE e risposta con segnale di
occupato del chiamato.
Scopo di questo processo nella fase di instaurazione è verificare e quindi segnalare eventuali
anomalie nel regolare flusso di messaggi, caratteristiche di un attacco visto nel paragrafo 4.1.
104
- Outbound INVITE
messaggio SIP
- Outbound -
Transazione
ch10.sip
Attesa Messaggio
ch10.sip
timeout
ch7.sip
100
407
Branch ::= ch7.ViaUA.Branch
Attesa Messaggio
Attesa Messaggio
ch13.sip
timeout
messaggio SIP
- Inbound -
ch7.sip
timeout
100
2XX
4XX
5XX
6XX
3XX
Sequenza Errata:
Possibile Attacco
Man in the Middle
altri
ACK
Branch = ch7.
sip.ViaUA.Branch
no
si
Messaggio
malformato
- Outbound INVITE
trying
Genera un
messaggio di
errore
- Outbound INVITE
redirected
- Outbound INVITE
failed
ch7.sip
Attesa
Messaggio
SIP
105
Genera un
messaggio
di errore
- Outbound INVITE
trying
ch10.sip
Attesa Messaggio
ch13.sip
timeout
messaggio SIP
- Inbound -
180
si
2XX
3XX
no
si
- Outbound INVITE
failed
Sequenza Errata:
Possibile Attacco
Man in the Middle
ch7.sip.To.Branch = NULL
no
Messaggio
malformato
4XX
5XX
6XX
Genera un
messaggio
di errore
Attesa Possibile Messaggio
SIP CANCEL da UA interno
ch7.sip
timeout
Genera un
messaggio
di errore
Method = CANCEL
no
si
- Outbound INVITE
Trying
parte 2
- Outbound CANCEL
Il normale flusso, può quindi lecitamente essere interrotto da una richiesta di cancellazione
proveniente dall’interno – caso che verrà descritto dettagliatamente in seguito – oppure proseguire
attraverso l’arrivo di un messaggio 100 Trying proveniente dall’esterno.
106
- Outbound INVITE
Trying
parte 2
Attesa Messaggio
ch13.sip
timeout
messaggio SIP
- Inbound -
Request-Line
ch13.sip.Start-Line
BYE
altri
Sequenza Errata:
Possibile Attacco
Denial of Service
Status-Line
3XX
Sequenza Errata:
Possibile Attacco
Man in the Middle
Genera un
messaggio
di errore
Genera un
messaggio
di errore
- Outbound INVITE
successful
si
no
ch7.sip.sdp = NULL
si
no
no
si
Messaggio
malformato
ch10.sip
Genera un
messaggio
di errore
Attesa Messaggio
ch7.sip
timeout
messaggio SIP
- Outbound -
ch8: con FCP aprire le
ch10.sip
Attesa
Messaggio
SIP
107
200
486
- Outbound INVITE
successful
- Outbound INVITE
busy
- Outbound INVITE
busy
- Outbound INVITE
failed
- Outbound INVITE
redirected
no
si
ch7.sip.ViaUA.Branch =
ch13.sip.ViaUA.Branch
si
no
no
si
Messaggio
malformato
Genera un
messaggio
di errore
ch10.sip
Attesa Messaggio
SIP ACK da Proxy
ch10.sip
timeout
ch13.sip
Attesa Messaggio
ch7.sip
timeout
messaggio SIP
- Outbound -
ch10.sip
Attesa
Messaggio
SIP
Quindi, nel caso in cui il tentativo di instaurazione della sessione SIP fallisca il processo Controllo
Policies deve chiudere la porta dell’interfaccia esterna del Firewall destinata alla segnalazione,
mentre nel caso in cui essa vada a buon fine, completando il three-way-handshake di SIP, il
processo Controllo Policies attraverso il protocollo FCP deve aprire una coppia di porte
dell’interfaccia esterna del Firewall per il flusso multimediale RTP/RTCP.
108
Si considera ora il caso in cui lo UAC che ha generato la richiesta di INVITE voglia interrompere
tale procedura generando una richiesta CANCEL ad essa riferita.
- Outbound CANCEL
messaggio SIP
- Outbound -
Attesa Parametri
DB Sessione
ch12.InitDialogo
ch7.sip.To = ch12.To
ch7.sip.From.uri = ch12.From.uri
ch7.sip.Request-URI = ch12.Request-URI
ch7.sip.CSeq.Numseq = ch12.CSeq.Numseq
ch7.sip.Call-ID = ch12.Call-ID
no
Possibile Attacco
dall’interno
Denial of Service
si
Genera un
messaggio
di errore
ch10.sip
Attesa Messaggio
ch10.sip
timeout
ch7.sip
200
Attesa Messaggio
481
Possibile Attacco
dall’interno
Denial of Service
ch13.sip
timeout
Genera un
messaggio
di errore
- Outbound CANCEL
successful
109
- Outbound CANCEL
successful
messaggio SIP
- Inbound -
si
ch13.sip.CSeq.
Method = CANCEL
no
Sequenza Errata:
Possibile Attacco
Man in the Middle
ch10.sip
Genera un
messaggio
di errore
Attesa Messaggio
ch13.sip
timeout
messaggio SIP
- Inbound -
487
481
ch13.sip.CSeq.
Method = INVITE
si
no
Possibile Attacco
ch10.sip
Genera un
messaggio
di errore
- Outbound CANCEL
Successful
parte 2
Attesa Messaggio
ch7.sip
timeout
messaggio SIP
- Outbound -
Attesa Messaggio
SIP ACK da Proxy
ch10.sip
timeout
ch10.sip
ch13.sip
- Outbound CANCEL
Successful
parte 2
6.3.2.4
Attesa
Messaggio
SIP
BYE
L’ultimo caso che rimane da analizzare è la richiesta BYE in uscita dal dominio. Per essa
non vengono effettuati molti controlli da parte del processo Controllo Policies poiché proviene
dall’interno, zona considerata fidata, al contrario di quanto si è visto nel caso di richiesta BYE
proveniente dall’esterno.
110
- Outbound BYE
successful
- Outbound BYE
messaggio SIP
- Outbound -
ch10.sip
ch12.ParametriDialogo.Method ::= ch7.sip.Request-Line.Request-URI.Method
Attesa Messaggio
ch13.sip
Attesa InitDialogo
DB Sessione
messaggio SIP
- Inbound -
timeout
ch12.InitDialogo
200
!= NULL
ch12.InitDialogo
Attesa ParametriDialogo
DB Sessione
= NULL
Procedura irregolare:
non esiste il dialogo che
lo UA vuole terminare
ch10.sip
ch12.ParametriDialogo.Via
ch7.sip.ViaUA =
ch12.ParametriDialogo.ViaUA
si
no
Genera un
messaggio
di errore
ch8: con FCP chiudere le
ch8: con FCP chiudere la
Possibile Attacco
dall’interno
Denial of Service
Attesa
Messaggio
SIP
- Outbound BYE
successful
111
408
481
6.3.3 Procedure comuni
Nelle analisi precedenti sono state utilizzate delle procedure comuni a più dialoghi. Esse
verranno brevemente descritte in questo paragrafo.
Quando una transazione viene iniziata dall’interno o dall’esterno del dominio, il processo Session
Database deve essere aggiornato sui parametri che la caratterizzano. Questa funzione è necessaria
sia a riconoscere se un messaggio appartiene ad un dialogo esistente o meno e sia a stabilire se il
dialogo di cui quel messaggio fa parte è stato iniziato da uno UA interno o esterno. Quest’ultima
caratteristica è necessaria per il corretto funzionamento del processo NAT L7 – come è stato già
sottolineato precedentemente.
Le procedure utilizzate a questi scopi sono Transazione iniziata dall’esterno e Transazione iniziata
dall’interno.
Transazione
Transazione
ch12.ParametriDialogo.Method ::= ch7.sip.Request-URI.Method
ch12.ParametriDialogo.CSeq ::= ch7.sip.CSeq
ch12.ParametriDialogo.ViaUA ::= ch7.sip.ViaUA
ch12.InitDialgo ::= INIZ_INTERNA
ch12.ParametriDialogo.Method ::= ch13.sip.Request-URI.Method
ch12.ParametriDialogo.CSeq ::= ch13.sip.CSeq
ch12.ParametriDialogo.ViaProxy ::= ch13.sip.ViaProxy
ch12.ParametriDialogo.ViaUA ::= ch13.sip.ViaUA
ch12.InitDialgo ::= INIZ_ESTERNA
ch12.InitDialogo
ch12.InitDialogo
Inoltre in [1] sono elencati i campi dell’intestazione che necessariamente devono far parte di un
qualsiasi messaggio SIP.
Per questo motivo attraverso le procedure Verifica sintattica del messaggio SIP - Outbound - e
Verifica sintattica del messaggio SIP - Inbound - viene eseguito un controllo sui messaggi che
transitano attraverso il processo Controllo Policies per scartare quelli malformati.
112
Verifica sintattica
del messaggio SIP
- Outbound -
ch7.sip.Via.Branch = NULL
Verifica sintattica
del messaggio SIP
- Inbound -
ch5.sip.Via.Branch = NULL
si
ch5.sip.From.uri = NULL
si
si
ch5.sip.To.uri = NULL
si
ch5.sip.To.Tag = NULL
no
ch5.sip.Call-ID = NULL
si
si
si
no
no
ch7.sip.Cseq.Method =
no
si
si
ch7.sip.Call-ID = NULL
si
no
no
ch7.sip.To.Tag = NULL
si
no
no
ch7.sip.To.uri = NULL
si
no
no
si
no
no
ch7.sip.From.uri = NULL
ch5.sip.Cseq.Method =
no
Messaggio
malformato
si
Genera un
messaggio
di errore
no
Messaggio
malformato
Genera un
messaggio
di errore
113
7
Risultati e conclusioni
Il lavoro di questa tesi è stato focalizzato sulla messa in sicurezza del servizio Voice over IP
con SIP come protocollo di segnalazione ed RTP come protocollo di trasporto. Sono state studiate
le diverse vulnerabilità di un’architettura VoIP, alcune ereditate dal substrato IP e altre introdotte
dai protocolli di più alto livello della pila protocollare.
Dopo una breve descrizione delle funzionalità di SIP, RTP e SDP, si è messo in luce come è
possibile attaccare una rete VoIP con delle sequenze di messaggi ritenute legali. In particolare per
il protocollo SIP, nel laboratorio multimediale di IT Telecom, è stata sviluppata un’architettura VoIP
sottoposta ai vari attacchi individuati teoricamente nella fase precedente. Si è evinto, da questo
studio, che negare la disponibilità di un servizio oppure rubare la sessione di un utente è possibile.
Per questo motivo il passo successivo è stato individuare quali elementi di rete potessero rendere
un’architettura VoIP più sicura. Si è reso infine necessario progettare un elemento di rete, detto
Sistema di gestione dei messaggi SIP, poiché gli elementi individuati sono Firewall e NAT, che non
permettono il regolare flusso della segnalazione ai confini di un dominio.
Quindi il lavoro di progettazione ha avuto un duplice scopo, da una parte rendere immune
l’architettura VoIP dagli attacchi SIP individuati e simulati nella prima fase di studio ed inoltre
rendere l’architettura compatibile con le limitazioni ed imposizioni introdotte da Firewall e NAT.
Dall’analisi effettuata è risultato che il protocollo SIP, piuttosto che definire nuovi e specifici
meccanismi di sicurezza, riutilizza modelli e servizi esistenti derivati da alcuni protocolli della IETF,
come ad esempio HTTP. L’adozione di tale approccio nella definizione dei suddetti meccanismi di
sicurezza è sembrata poco adatta per un aspetto cruciale quale la sicurezza del protocollo,
soprattutto per quanto riguarda il meccanismo di autenticazione. Infatti la maggior parte delle
minacce a cui il protocollo è sottoposto – descritte nel paragrafo 4.1 – riguardano proprio
debolezze nell’autenticazione. Il principale limite della procedura di autenticazione con lo schema
Digest è dato dall’impossibilità da parte del client di poter richiedere o comunque effettuare
l’autenticazione del server. Per poter sopperire a questa lacuna è necessario un meccanismo di
autenticazione che non è parte integrante del protocollo e che è implicitamente fornito dai
meccanismi, esterni al SIP, come TLS o IPSec, i quali però permettono l’autenticazione solamente
dei server adiacenti ai client, cioè dei soli server con i quali un client può avviare direttamente una
comunicazione di segnalazione – una comunicazione TCP/TLS oppure una Security Association
IPSec. Lo svantaggio introdotto da questi meccanismi di sicurezza esterni consiste nell’introdurre
risorse e tempo di elaborazione sensibilmente maggiori rispetto ad una situazione in cui essi sono
114
Risultati e conclusioni
assenti. Per un protocollo come il SIP, basato su scambi di messaggi, ciò è più di quanto
necessario e l’uso di un’autenticazione da effettuare per ogni messaggio di richiesta da questo
punto di vista è una scelta che sembrerebbe poco adatta, a meno che non sia strettamente
necessario assicurare la riservatezza della comunicazione di segnalazione.
In definitiva sembra necessaria la definizione di un nuovo meccanismo di autenticazione mutua,
cioè che permetta di verificare sia l’identità del client che del server, che inoltre sia in grado di
garantire la protezione d’integrità del corpo dei messaggi e di alcuni campi dell’intestazione che
non devono essere modificati o acceduti dai Proxy Server durante l’instradamento dei messaggi
stessi.
Dal lavoro svolto emergono alcune questioni che possono essere la base per studi futuri:
¾
valutazione delle prestazioni e controllo della qualità del servizio
¾
sviluppo della compatibilità con altri tipi di servizi garantiti da SIP, come ad esempio
l’Instant Messaging
¾
individuazione di un protocollo standard che permetta l’interazione tra processi SIP e
processi Firewall
¾
implementazione di un protocollo di autenticazione degli utenti
¾
progettazione di un blocco Controllo Policies anche per il protocollo RTP
115
Appendice A – SIP Generator
Il generatore di messaggi SIP utilizzato nella fase di implementazione degli attacchi è stato
scritto in C. Questo programma, realizzato in ambiente UNIX, permette la generazione e l’invio di
qualsiasi tipo di messaggio SIP, specificandone tutti i campi dell’intestazione che si vogliono
inserire e definendo sorgente e destinazione del messaggio stesso.
Si è ritenuto infatti necessario creare questo tipo di applicazione proprio perché a differenza della
maggior parte dei generatori di messaggi SIP reperibili gratuitamente su Internet, questo
programma fornisce ampia libertà di azione, consentendo addirittura di modificare, attraverso lo
spoofing. l’indirizzo IP sorgente del messaggio stesso.
In questa appendice verrà brevemente descritto il principio di funzionamento dell’applicazione SIP
Generator.
La comunicazione tra processi che risiedono in diversi sistemi è possibile attraverso le BSD IPC
(Berkeley Software Distribution Interprocess Communication) anche dette socket. Esse sono un
insieme di primitive che consentono la realizzazione di applicazioni secondo il modello logico di
comunicazione fra processi asimmetrico client-server, tipico di SIP. Una socket è un punto
terminale della comunicazione fra processi, completamente identificato dalla terna protocollo,
indirizzo IP e numero di porta; mentre una connessione è univocamente identificata da una coppia
di socket: protocollo, indirizzo IP locale, numero di porta locale, indirizzo IP remoto e numero di
porta remota.
Il programma SIP Generator prende come parametri appunto le socket locale e remota, attraverso
cui costruisce l’intestazione del pacchetto IP e UDP delle GNU (General Public License) C Library. I
messaggi SIP invece vengono accettati da un file di testo, in cui devono essere precedentemente
stati scritti specificando tutti i campi dell’intestazione che si vogliono includere. Questo metodo di
accettare il messaggio SIP da file di testo risulta veloce e funzionale, proprietà necessarie per gli
attacchi descritti nel paragrafo 4.1. Infine, il programma costruisce le socket di tipo raw, per cui il
protocollo IP fornisce la stessa modalità di comunicazione fornita da UDP: non orientata alla
connessione e non affidabile. Si è scelto di utlizzare le socket raw proprio perché permettono di
specificare tutti i campi dell’intestazione sia a livello di rete – per il protocollo IP – che a livello di
trasporto – per il protocollo UDP. In questo modo i messaggi generati sono falsificabili nella loro
interezza, specificando ad esempio l’indirizzo IP di un client coinvolto in una sessione come
sorgente del messaggio
116
Appendice A – SIP Generator
Denominatore comune di tutti gli attacchi descritti nel capitolo 4.1 è che l’attaccante agisca da
client, mentre la vittima da server. Questo implica che mentre l’attaccante ha un ruolo attivo, il
server ha un ruolo passivo.
client
fopen ()
payload := file
fclose()
sport := source_port
saddr := source_addr
server
dport := dest_port
daddr := dest_addr
socket()
socket()
bind()
ip_gen()
udp_gen()
recvfrom()
calcolo del
checksum
sendto()
Messaggio S
IP
close()
117
Bloccato in attesa di
connessione
Appendice B – SDL
Il linguaggio SDL è una FDT (Formal Description Techniques) definita dal CCITT (Comité
Consultativ
International
Télégraphique
et
Téléphonique),
ora
conosciuto
come
ITU-T
(Telecommunication Standardization Sector of the International Communication Union), la cui
semantica è basata sul concetto di macchina a stati finiti estesa (EFSM). Tale linguaggio esiste sia
in forma ‘program’ che in forma ‘graphic’. Nel primo caso si tratta di qualcosa di molto simile, sia
pure con alcune minime differenze semantiche, al linguaggio ESTELLE definito sempre dal CCITT.
Nella veste grafica, invece, si presenta come una sorta di diagramma di flusso in cui alcuni simboli
vengono utilizzati per descrivere azioni particolari.
Blocchi base per la descrizione del processo
Stato di attesa
Procedura
Riferimento
Segnale di Input
Elemento decisionale
Segnale di Output
Blocchi base per la descrizione del sistema
Processo
Blocco
…..
Lista di segnali
sul canale
Canale
Il vantaggio che si ottiene con questa forma è quello dell’immediatezza, a fronte dello svantaggio
della rapida espansione della descrizione.
Una specifica SDL di un sistema è suddivisa in tre parti distinte:
1) la definizione della struttura in termini di macchine e interconnessioni tra loro
118
Appendice B – SDL
2) la definizione del comportamento dinamico di ciascuna macchina, a livello di interazioni con
altre macchine e con l’ambiente
3) la definizione del dizionario delle interazioni, in termini di tipi di dato astratti
Per descrivere la definizione strutturale di un sistema vengono utilizzati i blocchi funzionali descritti
nella figura precedente; un sistema è visto come l’insieme di più blocchi funzionali, connessi tra
loro e con l’ambiente attraverso canali unidirezionali. La comunicazione tra blocchi avviene
mediante segnali, equivalenti a messaggi di interazione in ingresso e/o uscita scambiati in modo
asincrono.
La descrizione di un processo viene poi realizzata, con i blocchi presentati nella figura precedente,
in modo molto simile ad un diagramma di flusso. Tali blocchi consentono di descrivere il processo
come insieme di transizioni da uno stato di attesa ad un altro, a seguito di un segnale di ingresso
e/o una decisione su un predicato ed attraverso l’esecuzione di un’azione, eventualmente
comprendente l’emissione di un segnale di uscita.
A ciascuno dei segnali di ingresso e uscita può essere associata una lista di parametri, i cui tipi
sono tipi di dati astratti, che verranno descritti facendo uso del metalinguaggio ASN.1.
119
Bibliografia
[1]
J. Rosemberg, H. Schulzrinne, G. Camarillo et al., SIP: Session Inititation Protocol, IETF
RFC 3261, Giugno 2002
[2]
R. Fieldeng, J. Gettys, J. Mogul et al, Hypertext Transfer Protocol – HTTP/1.1, IETF RFC
2616, Giugno 1999
[3]
ITU-T Recommendation, H.323: Packet-based multimedia communication system, Luglio
2003
[4]
D. Crocker e P. Overell, Augmented BNF for Syntax Specification: ABNF, IETF RFC 2234,
Novembre 1997
[5]
T. Berners-Lee, R. Fielding e L. Masinter, Uniform Resource Identifiers (URI): Generic
Syntax, IETF RFC 2396, Agosto 1998
[6]
F. Feed e N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part Two: Media
Types, IETF RFC 2046, Novembre 1996
[7]
J. Rosenberg e H. Schulzrinne, SIP: Locating SIP Servers, IETF RFC 3263, Giugno 2002
[8]
Geremy George, http://mit.edu/sip/sip.edu/dns.shtml, Maggio 2003
[9]
A. Johnston, S. Donovan, R. Sparks et al., Session Inititation Protocol (SIP) Basic Call Flow
Examples, IETF RFC 3665, Dicembre 2003
[10]
A. Johnston, SIP: Understanding the Session Inititation Protocol, Artech House Boston London
[11]
M. Handley e V. Jacobson, SDP: Session Description Protocol, IETF RFC 2327, Aprile 1998
[12]
H. Schulzrinne, S. Casner, R. Frederick et al., RTP: A Transport Protocol for Real-Time
Applications, IETF RFC 3550, Luglio 2003
120
[13]
Bibliografia
D. Kuhn, T. Walsh e S. Fries, Security Considerations for Voice over IP Systems,
Recommendation of National Institute of Standards and Technology, Aprile 2004
[14]
ITU-T Recommendation, G.114: Delay, Settembre 1998
[15]
C-N Chua, Providing End-to-End QoS for IP based Latency sensitive Applications, Technical
Report, Dept. Of Electrical Engineering and Computer Science, University of California at
Berkeley, 2000
[16]
H. Schulzrinne, A. Rao e R. Lanphier, Real Time Streaming Protocol (RTSP), IETF RFC
2326, Aprile 1998
[17]
F. Thernelius, SIP, NAT, and Firewalls, Master’s Thesis, Maggio 2000
[18]
Newport Networks, Solving the Firewall and NAT Traversal Issues for Multimedia Services
over IP, White Paper, 2004
[19]
Information Sciences Institute University of Southern California, Transmission Control
Protocol, IETF RFC 793, Settembre 1981
[20]
M. Leech, M. Ganis, Y. Lee et al., SOCKS Protocol Version 5, IETF RFC 1928, Marzo 1996
[21]
P. Srisuresh e M. Holdrege, IP Network Address Translator (NAT) Terminology and
Considerations, IETF RFC 2663, Agosto 1999
[22]
K. Egevang e P. Francis, The IP Network Address Translator (NAT), IETF RFC 1631, Maggio
1994
[23]
Y. Rekhter, B. Moskowitz, D. Karrenberg et al., Address Allocation for Private Internets,
IETF RFC 1918, Febbraio 1996
[24]
R. Droms, Dynamic Host Configuration Protocol, IETF RFC 2131, Marzo 1997
[25]
J. Postel, User Datagram Protocol, IETF RFC 768, Agosto 1980
[26]
http://www.iana.org
[27]
J. Rosenberg, J. Weinberger, C. Huitema et al., STUN – Simple Traversal of User Datagram
Protocol (UDP) Through NAT, IETF RFC 3489, Marzo 2003
121
[28]
Bibliografia
J. Rosenberg, J. Weinberger, R. Mahy et al., Traversal Using Relay NAT (TURN), IETF
Internet-Draft, Marzo 2003
[29]
T. Dierks e C. Allen, The TLS Protocol Version 1.0, IETF RFC 2487, Gennaio 1999
[30]
ITU-T Recommendation, Z.100: Specification and description Language, Novembre 1999
[31]
ITU-T Recommendation, X.680: Abstract Syntax Notation One (ASN.1), 2002
[32]
J. Kuthan e J. Rosenberg, Middlebox Communication: Framework Requirements, IETF
Internet-Draft, Maggio 2001
[33]
J. Franks, P. Hallam-Barker, J. Hostetler et al., HTTP Authentication: Basic and Digest
Access Authentication, IETF RFC 2617, Giugno 1999
[34]
http://www.monkey.org/~dugsong/dsniff
[35]
http://www.ethereal.com/
[36]
http://vomit.xtdnet.nl/
[37]
http://www.iptel.org/ser/
[38]
http://www.sjlabs.com/
[39]
http://www.ortena.com/download.htm
122

studio ed analisi della sicurezza dei servizi voice over ip

Transcript

Documenti analoghi

grandstream bt200 caratteristiche principali

Voip convenzione

START UP IN RESPIRATORY MEDICINE

PBX | Datasheet

asterisk configurazione euteliavoip

Asterisk - Voicee.net

Yealink SIP-T48G Datasheet

TEMPLATE CONFIGURAZIONE ASTERISK PER

Yealink SIP-T46G Datasheet

ZyXEL Prestige 2602R GUIDA ALLA CONFIGURAZIONE