STUDIO ED ANALISI DELLA SICUREZZA DEI SERVIZI VOICE …teca.elis.org/1608/Matteo Mogno.pdf ·...

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

Chiar.mo prof. Marco Listanti

Co-relatore

Emilio Tonelli

Candidato

Matteo Mogno

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.

i

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 Architettura del VoIP ...........................................................................................5

2.2 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

Studio ed Analisi della Sicurezza dei Servizi Voice over IP con SIP e RTP Indice

ii

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 Modifying IP address..................................................................................47 4.2.2 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


iii

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


iv

6.3.1 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

v

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

1

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).

Studio ed Analisi della Sicurezza dei Servizi Voice over IP con SIP e RTP Introduzione

2

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


3

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


4

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).

5

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.

Studio ed Analisi della Sicurezza dei Servizi Voice over IP con SIP e RTP Visione d’insieme del Voice over IP

6

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.

VoIP Gateway

VoIP Gateway

VoIP Gateway

MediaGatewayController

SignalingGatewayController

SS7 Signaling Network

PSTNPSTN

IP Backbone Network

Telephone

Telephone

TelephoneIP Phone

IP Phone

IP Phone

Figura 2.1 - Architettura del Voice over IP


7

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


8

Protocol (SCTP). Nel caso in cui si utilizzi un protocollo inaffidabile come UDP, SIP implementa un

proprio meccanismo di ritrasmissione per assicurare l’affidabilità.

UDPTCP

H.323 SIP RTPRTCPRSVPRTSP

Media Encapsulation(H.261, MPEG)

PPP AAL 3/4 AAL 5 PPP

Sonet ATM Ethernet V.34

Phys

ical

Link

Net

wor

kTr

ansp

ort

Signaling Quality of Service

Media Transport

IPv4 IPv6

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


9

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.


10

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


11

• 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):

100 Trying180 Ringing181 Call Forwarded182 Queued183 Session Progress

200 OK 300 Multiple Choices301 Moved Perm.302 Moved Temp.380 Alternative Serv.

400 Bad Request401 Unauthorized403 Forbidden404 Not Found405 Bad Method486 Busy Here

500 Server Error501 Not Implemented503 Unaivalable504 Timeout

600 Busy Everywhere603 Decline604 Doesn’t Exist606 Not Acceptable

Informational Success Redirection Request Failure

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


12

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


13

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


14

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


15

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


16

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


17

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

SequenceNumber

Timestamp

SSRC

CSRC

Figura 2.4 - Intestazione di RTP


18

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


19

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.

20

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à.

Studio ed Analisi della Sicurezza dei Servizi Voice over IP con SIP e RTP Aspetti di sicurezza nel Voice over IP

21

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


22

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.


23

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


24

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].


25

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.


26

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


27

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.


28

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.


29

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.

30

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-

Studio ed Analisi della Sicurezza dei Servizi Voice over IP con SIP e RTP Vulnerabilità di SIP e RTP

31

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.

Attackersip:[email protected]

192.0.3.103Registrar Server /Location Service

SIP Proxy

Victim Bsip:[email protected]

192.0.2.102

REGISTER sip:registrar.atlanta.com SIP/2.0Via: SIP/2.0/UDP 192.0.1.101:5060From: <[email protected]>;tag=12314534To: <[email protected]>Call-ID: [email protected]: 1 REGISTERContact: <sip:[email protected]>Content-Length: 0

SIP/2.0 200 OKVia: SIP/2.0/UDP 192.0.1.101:5060From: <[email protected]>;tag=12314534To: <[email protected]>;tag=45243254Call-ID: [email protected]: 1 REGISTERContact: <sip:[email protected]>Content-Length: 0

INVITE sip:[email protected]….

Query

Response

INVITE sip:victimA.atlanta.com SIP/2.0Via: SIP/2.0/UDP proxy.atlanta.comVia: SIP/2.0/UDP 192.0.2.102:5060From: <[email protected]>;tag=42314534To: <[email protected]>Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>Content-Type: application/sdpContent-Length: 0

Figura 4.1 - Registration Hijacking: flusso di messaggi dell'attacco


32

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.


33

Victim Asip:[email protected]

192.0.1.101


192.0.2.102


192.0.3.103

1) INVITE Victim B

2) 100 Trying3) INVITE Victim B

4) 301 Moved Permanently

5) INVITE Victim B

6) INVITE Victim B

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


34

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


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:







35





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



sipserver3.domain.com 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.


192.0.1.101


192.0.2.102


192.0.3.103

1) DNS Poisoning

DNS Server

2) Query

3) Response

4) INVITE sip:[email protected]

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:


36

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.


37

SIP Proxy


192.0.1.101


192.0.3.103

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.0.1.101:5060From: <[email protected]>;tag=12314534To: <[email protected]>Call-ID: [email protected]: 1 INVITEContact: <sip:client1.atlanta.com>Content-Type: application/sdpContent-Length: 125

SIP/2.0 302 Moved TemporarilyVia: SIP/2.0/UDP 192.0.1.101:5060From: <[email protected]>;tag=12314534To: <[email protected]>;tag=46453645Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>Content-Type: application/sdpContent-Length: 125


INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.0.1.101:5060From: <[email protected]>;tag=12314534To: <[email protected]>Call-ID: [email protected]: 1 INVITEContact: <sip:client1.atlanta.com>Record-Route: <sip:192.0.3.103;lr>Content-Type: application/sdpContent-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.


38

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.

SIP Proxy


192.0.1.101


192.0.3.103


SIP/2.0 305 Use ProxyVia: SIP/2.0/UDP 192.0.1.101:5060From: <[email protected]>;tag=12314534To: <[email protected]>;tag=46453645Call-ID: [email protected]: 1 INVITEContact: <sip:192.0.3.103>Content-Type: application/sdpContent-Length: 125


INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.0.1.101:5060From: <[email protected]>;tag=12314534To: <[email protected]>Call-ID: [email protected]: 1 INVITEContact: <sip:client1.atlanta.com>Record-Route: <sip:192.0.3.103;lr>Content-Type: application/sdpContent-Length: 125

Figura 4.5 - 305 Response code message: flusso dei messaggi di attacco


39

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.

Victim A

Attacker

Registrar Server

LocationService

1) REGISTER

2) 301 Moved Permanently

3) REGISTER’

4) REGISTER’’5) 401 Unauthorized

6) 401 Unauthorized

7) REGISTER con credenziali per l’autenticazione 8) REGISTER con credenziali

della vittima 9) Store

Figura 4.6 - Impersonating a Registrar Server


40

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


41

chiamato ed uno al chiamante, spacciandosi per il chiamante nel primo caso e per il chiamato nel

secondo.

Victim A Victim B

Attacker

SIP ProxySIP Proxy

BYE da Victim ABYE da Victim B

200 OK 200 OK 200 OK

200 OK200 OK200 OK

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.


42

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.


192.0.1.101


192.0.3.103

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.0.2.102:5060From: <[email protected]>;tag=12314534To: <[email protected]>;tag=5345324Call-ID: [email protected]: 1 INVITEContact: <sip:client1.biloxy.com>Content-Type: application/sdpContent-Length: 139

...m=audio 49100 RTP/AVP 0a=rtpmap:0 PCMU/8000m=video 49172 RTP/AVP 32a=video 0 49200 RTP/AVP 32...

SIP/2.0 200 OKVia: SIP/2.0/UDP 192.0.2.102:5060From: <[email protected]>;tag=12314534To: <[email protected]>;tag=5345324Call-ID: [email protected]: 1 INVITEContact: <sip:client.atlanta.com>Content-Type: application/sdpContent-Length: 125

...m=audio 44100 RTP/AVP 0a=rtpmap:0 PCMU/8000m=video 44200 RTP/AVP 32a=video 0 49200 RTP/AVP 32...


192.0.2.102

ACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.0.2.102:5060From: <[email protected]>;tag=12314534To: <[email protected]>;tag=5345324Call-ID: [email protected]: 1 ACKContact: <sip:client1.biloxy.com>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.


43

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.


192.0.1.101


192.0.3.103

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.0.1.101:5060From: <[email protected]>;tag=12314534To: <[email protected]>Call-ID: [email protected]: 1 INVITEContact: <sip:client1.biloxy.com>Content-Type: application/sdpContent-Length: 139


192.0.2.102

CANCEL sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.0.2.102:5060From: <[email protected]>;tag=12314534To: <[email protected]>Call-ID: [email protected]: 2 CANCELContent-Length: 0

SIP/2.0 200 OKVia: SIP/2.0/UDP 192.0.2.102:5060From: <[email protected]>;tag=12314534To: <[email protected]>;tag=42353245Call-ID: [email protected]: 2 CANCELContent-Length: 0

Figura 4.9 - Cancelling a session: fase di sniffing e attacco


44

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


45

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.


192.0.1.101Attackersip:[email protected]

192.0.3.103

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.0.1.101:5060Via: SIP/2.0/UDP 0.0.0.0:5060From: <[email protected]>;tag=12334To: <[email protected]>Call-ID: [email protected]: 1 INVITEContact: <sip:client.site.com>Content-Type: application/sdpContent-Length: 139

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


46

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 Call-

ID 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

Attacker

1) Request SIP

2) 4XX, 5XX o 6XX Response

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


47

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.


48

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.


192.0.2.102


192.0.1.101


192.0.3.103

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.0.1.101:5060From: <[email protected]>;tag=5432532To: <[email protected]>;tag=12314534Call-ID: [email protected]: 2 INVITEContact: <sip:client1.atlanta.com>Content-Type: application/sdpContent-Length: 125

...c=IN IP4 192.0.3.103...

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.0.2.102:5060From: <[email protected]>;tag=12314534To: <[email protected]>;tag=5432532Call-ID: [email protected]: 1 INVITEContact: <sip:client1.biloxi.com>Content-Type: application/sdpContent-Length: 125

...c=IN IP4 192.0.3.103...

SIP/2.0 200 OKVia: SIP/2.0/UDP 192.0.2.102:5060From: <[email protected]>;tag=12314534To: <[email protected]>;tag=5432532Call-ID: [email protected]: 1 INVITEContact: <sip:client1.atlanta.com>Content-Type: application/sdpContent-Length: 132

...c=IN IP4 192.0.1.101...

flusso RTP tra Victim A e Victim B

SIP/2.0 200 OKVia: SIP/2.0/UDP 192.0.1.101:5060From: <[email protected]>;tag=5432532To: <[email protected]>;tag=12314534Call-ID: [email protected]: 2 INVITEContact: <sip:client1.biloxi.com>Content-Type: application/sdpContent-Length: 129

...c=IN IP4 192.0.2.102...

ACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.0.1.101:5060From: <[email protected]>;tag=5432532To: <[email protected]>;tag=12314534Call-ID: [email protected]: 2 ACK

ACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 192.0.2.102:5060From: <[email protected]>;tag=12314534To: <[email protected]>;tag=5432532Call-ID: [email protected]: 1 ACK

flusso RTP tra Victim A e Victim B flusso RTP tra Victim A e Victim B

Figura 4.12 - Modifying IP address


49

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 re-

INVITE 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à.


50

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.


51

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.

Victim AAttacker

Pacchetto malicious

Flusso RTP Flusso RTP

OK

OK

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


52

• 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


53

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

MasterMasterMaster

Daemon

Multicast IP

Victim A

Sessione RTP

Traffico RTCP a ritmo costante

Traffico RTCP corretto

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


54

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 A192.0.1.101

Attacker192.0.3.103

RTP

SSRC = ABCD1234

IP = 192.0.1.101

Sessione RTP

RTP (spoofing)

SSRC = ABCD1234

IP = 192.0.1.199

RTCP BYE

SSRC = ABCD1234

RTP

SSRC = EFGH5678

IP = 192.0.1.101

RTP (spoofing)

SSRC = EFGH5678

IP = 192.0.1.199

... ...

Figura 4.15 - Change Synchronization Source field


55

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 A192.0.1.101

Attacker192.0.3.103

RTP

SSRC = ABCD1234

IP = 192.0.1.101

Sessione RTP

Port = 5004

RTCP BYE (spoofing)

SSRC = ABCD1234

IP = 192.0.1.101

Port = 5005

RTP

SSRC = EFGH5678

IP = 192.0.1.101

Port = 5004

… la vittima rinizia il processo di accesso …

RTCP BYE (spoofing)

SSRC = EFGH5678

IP = 192.0.1.101

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.


56

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 A192.0.1.101

Attacker192.0.3.103

RTP

SSRC = ABCD1234

IP = 192.0.1.101

Port = 5004

seq_num = 10

timestamp = 11

RTP

SSRC = ABCD1234

IP = 192.0.1.101

Port = 5004

seq_num = 100

timestamp = 101

RTP

SSRC = ABCD1234

IP = 192.0.1.101

Port = 5004

seq_num = 11

timestamp = 12

scartato perché obsoleto

Victim B192.0.1.102

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.


57

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


58

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.

IP: 10.10.82.110MAC: 00-50-DA-73-40-CE

IP: 10.10.81.107

Live CommuncationServer 2003

Client A

IP: 10.10.82.204MAC: 00-54-DA-74-84-05

Client B

IP: 10.10.82.31MAC: 00-08-C7-B3-6B-31

Attacker

Switch Catalist 2950


59

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 AIP: 10.10.82.110

AttackerIP: 10.10.82.31

Client BIP: 10.10.82.204

Ping Req.10.10.82.204Ping Req. 10.10.82.110

arpspoof -t 10.10.82.204 10.10.82.110arpspoof -t 10.10.82.110 10.10.82.204

fragrouter -B1

UDP / RTP

UDP / RTP

UDP / RTP

UDP / RTP

Questo è il tempo che l’attacker impiega per memorizzare il pacchetto entrante e per indirizzarlo verso l’utente lecito

Ping Rep. 10.10.82.31 Ping Rep. 10.10.82.31

Per chiarezza visiva non sono inseriti tutti i messaggi connessi alla funzione arpspoof che deve avvelenare continuamente le tabelle di ARP delle due vittime

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.


60

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-B3-

6B-31), che memorizza il flusso di dati proveniente del Client A e lo inoltra, dopo averlo

memorizzato, verso il Client B.


61

4.3.2 Tearing down a session


Il primo passo prevede la realizzazione di un’architettura di riferimento che verrà utilizzata

durante tutta la durata della sperimentazione.

IP: 10.10.82.191MAC: 00-50-DA-73-40-CE

IP: 10.10.82.112

IP: 10.10.81.40MAC: 00-50-DA-74-84-05

SIP-SERVER

HUB

Sebastiano Alessandro Attacker

IP: 10.10.82.49MAC: 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


62

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 BIP: 10.10.82.191MAC: 00-50-DA-73-40-CE

Client AIP: 10.10.81.40MAC: 00-50-DA-74-84-05

SIP-ServerIP: 10.10.82.112

INVITE

100 TRYING INVITE

180 RINGING

180 RINGING200 OK

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.

Call-ID: [email protected]


63

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].


64

4.3.3 Cancelling a session


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:


65

• 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

Sequenza dei messaggi SIPIndirizzi IP dei due

client legittimi

Indirizzo MAC dell’ attacker, prova dello spoofing a livello ip

4.3.4 Modifying a session


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.

IP: 10.10.82.191MAC: 00-50-DA-73-40-CE

IP: 10.10.82.112

IP: 10.10.81.40MAC: 00-50-DA-74-84-05

IP: 10.10.81.107MAC: 00-50-DA-74-85-B4

SIP-SERVER

HUB

Sebastiano Alessandro SIPNess


66

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


67

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.

68

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

Studio ed Analisi della Sicurezza dei Servizi Voice over IP con SIP e RTP Attraversamento di NAT e Firewall

69

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.


70

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.


71

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


72

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.

Client A

Client B Client Y

Client X

Il client A inizia una sessione uscente verso

il client XIl Firewall permette

l’ingresso del flusso in entrata

Il client Y tenta di inizare una sessione

con il client B

Il Firewall blocca il flusso non previsto proveniente

dall’esterno

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.

Client A192.168.1.100

Client X

Segnalazione

Media

Segnalazione

Media

1. Nel messaggio SDP la sorgente è

192.168.1.100:8000

2. La segnalazione ed il flusso media passano

attraverso il Firewall con funzione di NAT

3. Nel messaggio SDP la sorgente continua ad essere

192.168.1.100:8000

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


73

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


74

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.


75

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.

76

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

Blocco: FW/NAT

Blocco: SIP ALG Blocco: SIP Server

Ch 1

Ch 2

Ch 3Ch 4

Ch 5

Ch 13

Ch 9

Ch 10

Ch 11

Ch 15

Ch 16

Ch 17

Ch 18

Sistema di gestione dei messaggi SIP

Ch 8

Blocco: Database

Blocco: DNS

Ch 12

Ch 7

Ch 14

Ch 6

ProcessoFirewall

ProcessoSession

Database

ProcessoNAT L4

ProcessoNAT L7

ProcessoDNS

ProcessoSIP

Proxy

ProcessoSIP

Registrar

ProcessoLocationService

ProcessoControlloPolicies

Figura 6.1 - SDL: Sistema di gestione dei messaggi SIP

Studio ed Analisi della Sicurezza dei Servizi Voice over IP con SIP e RTP Progettazione del SIP ALG

77

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.


78

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{


79

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), ACK(2), CANCEL(3), BYE(4),

OPTIONS(5)}

SIP-URI ::= SEQUENCE {User PRINTABLE STRING,

Host ADDRESS,


80

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


81

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.

Blocco: FW/NAT


Ch 1

Ch 2

Ch 3Ch 4

Ch 9

Ch 10

Ch 11

Ch 15

Ch 16

Ch 17

Ch 18

Sistema di gestione dei messaggi SIP uscenti

Ch 8

Blocco: Database

Blocco: DNS

Ch 12

Ch 7

Ch 14

Ch 6

ProcessoFirewall

ProcessoSession

Database

ProcessoNAT L4

ProcessoNAT L7

ProcessoDNS

ProcessoSIP

Proxy

ProcessoSIP

Registrar



Figura 6.2 - SDL: Sistema di gestione dei messaggi SIP uscenti


82

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.

Blocco: FW/NAT


Ch 1

Ch 2

Ch 3Ch 4

Ch 5

Ch 13

Ch 10

Ch 11

Ch 15

Ch 16

Ch 17

Ch 18

Sistema di gestione dei messaggi SIP entranti

Ch 8

Blocco: Database

Blocco: DNS

Ch 12

Ch 14

ProcessoFirewall

ProcessoSession

Database

ProcessoNAT L4

ProcessoNAT L7

ProcessoDNS

ProcessoSIP

Proxy

ProcessoSIP

Registrar



Figura 6.3 - SDL: Sistema di gestione dei messaggi SIP entranti


83

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.


84

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 ALG Address -> Local Address Non modificare

Contact Non modificare Non modificare

Inbound request

SDP Non modificare Non modificare

Request-URI (II) (II)

Via ALG Address -> Local Address ALG Address -> Local Address

To Non modificare Non modificare

From ALG Address -> Local Address ALG Address -> Local Address

Call-ID ALG Address -> Local Address Non modificare

Contact Non modificare Non modificare

Inbound response

SDP Non modificare Non modificare

Request-URI Non modificare Non modificare

Via Local Address -> ALG Address Local Address -> ALG Address

To Non modificare Non modificare

From Local Address -> ALG Address Local Address -> ALG Address

Call-ID Local Address -> ALG Address Non modificare

Contact Local Address -> ALG Address (IV) Local Address -> ALG Address (IV)

Outbound request

SDP (III) (III)

Request-URI (II) (II)

Via Non modificare Non modificare

To Local Address -> ALG Address Non modificare

From Non modificare Non modificare

Call-ID Local Address -> ALG Address Non modificare

Contact Local Address -> ALG Address (IV) Local Address -> ALG Address (IV)

Outbound response

SDP (III) (III)

(I) 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


85

6.2.1 Messaggi in ingresso

AttesaMessaggio

SIP

ch5.sip

ch14.InitDialogoINIZ_INTERNA INIZ_ESTERNA o NULL

ch5.sip.Start-LineRequest-Line Status-Line Status-Line

- Inbound -RequestIniziata

dall’interno

ch14.ParametriDialogo

Attesa RispostaDB Sessione

ch14.InitDialogo

ch14.ParametriDialogo.To ::= ch5.sip.Toch14.ParametriDialogo.From ::= ch5.sip.From

ch14.ParametriDialogo.Call-ID ::= ch5.sip.Call-ID

ch5.sip.Start-LineRequest-Line

- Inbound -Response

Iniziata dall’interno


dall’esterno

- Inbound -Response

Iniziata dall’esterno

ch5.sip.Request-Line.Request-URI.uri.Host ::= ch5.ip.DestAddrch5.sip.Request-Line.Request-URI.uri.Port ::= 5060

ch5.sip.To.uri.Host ::= ch5.ip.DestAddrch5.sip.Call-ID.Host ::= ch5.ip.DestAddr

ch13.sip

AttesaMessaggio

SIP


dall’interno

ch13.sip

ch5.sip.ViaUA.Host ::= ch5.ip.DestAddrch5.sip.From.uri.Host ::= ch5.ip.DestAddr

AttesaMessaggio

SIP

- Inbound -Response


ch13.sip

ch5.sip.ViaUA.Host ::= ch5.ip.DestAddrch5.sip.From.uri.Host ::= ch5.ip.DestAddrch5.sip.Call-ID.Host ::= ch5.ip.DestAddr

AttesaMessaggio

SIP

- Inbound -Response



86

ch13.sip

AttesaMessaggio

SIP

ch5.sip.Request-Line.Method altri

ch5.sip.Request-Line.Request-URI.uri.Host ::= ch5.ip.DestAddrch5.sip.Request-Line.Request-URI.uri.Port ::= 5060

ch5.sip.To.uri.Host ::= ch5.ip.DestAddr

ch13.sip

REGISTER o INVITE

ch5.sip.Request-Line.Request-URI= ALGAddr

OPTIONS

!= ALGAddr

AttesaMessaggio

SIP


dall’esterno

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.

AttesaMessaggio

SIP

ch9.sip

ch14.InitDialogoINIZ_INTERNA INIZ_ESTERNA

ch9.sip.Start-LineRequest-Line Status-Line Status-Line



ch14.InitDialogo

ch14.ParametriDialogo.To ::= ch9.sip.Toch14.ParametriDialogo.From ::= ch9.sip.From

ch14.ParametriDialogo.Call-ID ::= ch9.sip.Call-ID

ch9.sip.Start-LineRequest-Line

- Outbound -RequestIniziata

dall’interno

- Outbound -Response



dall’esterno




87

ch6.sip

ch9.sip.Content-Length= 0 > 0

ch9.sip.ViaUA.Host ::= ALGAddrch9.sip.From.uri.Host ::= ALGAddrch9.sip.Call-ID.Host ::= ALGAddr

ch9.sip.Contact.uri.Host ::= ALGAddrch9.sip.Contact.uri.Port ::= ch9.ip.udp.SourcePort

ch7.sip.Content-TypeApplication/SDP


dall’interno

AttesaMessaggio

SIP- Outbound -

Cambiamento SDP

ch9.sip.To.uri.Host ::= ALGAddrch9.sip.Call-ID.Host ::= ALGAddr


ch6.sip





- Outbound -Cambiamento

SDP

AttesaMessaggio

SIP

ch9.sip.ViaUA.Host ::= ALGAddrch9.sip.From.uri.Host ::= ALGAddr


ch6.sip




dall’esterno


SDP

AttesaMessaggio

SIP


88

ch9.sip.Contact.uri.Host ::= ALGAddrch9.sip.Contact.uri.Port ::= ALGPort

ch6.sip






SDP

AttesaMessaggio

SIP

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.

ch6.sip

Ricalcolare ch9.sip.Content-Length

ch9.sip.sdp.o.Host ::= ALGAddrch9.sip.sdp.c.Host ::= ALGAddrch9.sip.sdp.m.Port ::= RTPPort


SDP

AttesaMessaggio

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


89

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.


90

6.3.1 Messaggi in ingresso

Atte

saM

essa

ggio

SIP

ch13

.sip

ch13

.sip

.Sta

rt-Li

neR

eque

st-L

ine

Sta

tus-

Line

ch13

.sip

.Req

uest

-Li

ne.M

etho

dIN

VIT

E

REG

ISTE

R

OP

TIO

NS

- Inb

ound

-IN

VIT

E- I

nbou

nd -

RE

GIS

TER

- Inb

ound

-O

PTI

ON

S

BYE

- Inb

ound

-B

YE

AC

K

CA

NC

EL

ch13

.sip

.Sta

tus-

Line

.Sta

tus-

Cod

e1X

X

2XX

3XX

6XX

5XX

4XX Fu

ori S

eque

nza:

P

ossi

bile

Atta

cco

Den

ial o

f Ser

vice

Gen

era

un

mes

sagg

io d

i er

rore

Fuor

i Seq

uenz

a:

Poss

ibile

Atta

cco

Man

in th

e M

iddl

e

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.


91

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

ch13.sip.Request-Line.Request-URI= ALGAddr != ALGAddr

Messaggio malformato: Possibile Attacco

Registration Hijacking

Genera un messaggio

di errore

ch13.sip.CSeq.Numseq

ch13.sip.Call-ID.Numcall

= ch12.ParametriDialogo.Call-ID.Numcall

!= ch12.ParametriDialogo.

Call-ID.Numcall




!= (ch12.ParametriDialogo.

CSeq.Numseq) + 1

= (ch12.ParametriDialogo.CSeq.Numseq) + 1

ch12.ParametriDialogo.Method ::= ch13.sip.Request-Line.Request-URI.Method

ch12.ParametriDialogo.From ::= ch13.sip.From.uri

- Inbound -REGISTER

parte 2

Possibile Attacco

Genera un messaggio di

errore

Scarta il pacchettoVerifica sintattica del

messaggio SIP- Inbound -

Transazione iniziata dall’esterno

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.


92

- Inbound -REGISTER

parte 2

ch11.sip

ch11.sip.Start-Line.Status-Line.Status-

Code403200

401

ch13.sip

AttesaMessaggio

SIP

Attesa MessaggioSIP Risposta da Registrar

ch11.sip ::= ch13.sip

ch11.sip

ch13.sip ::= ch11.siptimeout

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.


93

Verifica sintattica del messaggio SIP

- Inbound -

ch13.sip.Request-Line.Request-URI.User = NULLno si

Attesa MessaggioSIP Risposta da Proxy

ch10.sip.Status-Line.Status-Code

ch10.sip

200 4XX

timeout

Attesa MessaggioSIP Risposta da UA interno

ch13.sip :== ch10.sip

ch13.sip

ch7.sip

timeout

ch7.sip.Status-Line.Status-Code200 4XX


ch10.sip


- Outbound -

AttesaMessaggio

SIP

AttesaMessaggio

SIP

- Inbound -OPTIONS


ch10.sip

ch8: con FCP aprire la porta esterna per SIP

ch8: con FCP chiudere la porta esterna per 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.


94

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


- Inbound -


ch10.sip



ch10.sip

1004XX5XX6XX

timeout


ch7.sip

timeoutVerifica sintattica del

messaggio SIP- Outbound -


ch13.sip

ch7.sip.Status-Line.Status-Code180

4XX5XX6XX

3XX

Sequenza Errata: Possibile Attacco

dall’internoMan in the Middle


errore

- Inbound -INVITEringing

2XX


dall’internoSession Hijacking

- Inbound -INVITE

UA failed

Messaggio malformato

Genera un messaggio di errore

ch13.sip.Contact = NULL sino

Attesa MessaggioSIP ACK da UA esterno

ch10.sip

timeout


ch10.sip


- Inbound -

AttesaMessaggio

SIP



95

- Inbound -INVITEringing


ch7.siptimeout


- Outbound -

ch7.sip.Status-Line.Status-Code200 486

3XX




errore

- Inbound -INVITE

busy

ch7.sip.Start-LineRequest-Line Status-Line

ch7.sip.Start-Line

BYE


dall’internoDenial of Service


errore

altri


ch10.sip


- Inbound -INVITE

successful

si

- Inbound -CANCEL

Attesa Possibile MessaggioSIP CANCEL da UA esterno

ch13.sip

ch13.sip.Request-Line.Method = CANCEL

no

timeout

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.


96

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.


ch10.sip


ch13.siptimeout


- Inbound -

ch10.sip

ch8: con FCP aprire le porte esterne per RTP


AttesaMessaggio

SIP

- Inbound -INVITE

successful

- Inbound -INVITE

UA failed



ch7.sip.Cseq.Method = INVITE no

si


ch10.sip

Attesa MessaggioSIP ACK da Proxy

timeout

ch10.sip


AttesaMessaggio

SIP

ch7.sip

Attesa MessaggioSIP ACK da UA interno

timeout

ch10.sip

Verifica sintattica del messaggio SIP- Outbound -


ch7.sip


- Inbound -INVITEbusy

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


97

motivo il processo Controllo Policies accetta richieste di cancellazione solamente se all’interno di un

dialogo iniziato da un INVITE.

- Inbound -CANCEL


- Inbound -

ch13.sip.To = ch12.Toch13.sip.From.uri = ch12.From.uri

ch13.sip.From.Tag = NULLch13.sip.Request-URI = ch12.Request-URI

ch13.sip.CSeq.Numseq = ch12.CSeq.Numseqch13.sip.Call-ID = ch12.Call-ID

Genera un messaggio

di errore

no

Messaggio Malformato: Possibile AttaccoDenial of Servicesi


ch10.sip


ch10.sip

200 481

timeout


ch13.sip



ch7.siptimeout

- Inbound -CANCEL

successful

Genera un messaggio

di errore

ch12.InitDialogo

Attesa ParametriDB Sessione

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].


98

- Inbound -CANCEL

successful


ch7.sip.CSeq.Method = CANCELsi no



Genera un messaggio

di errore


ch13.siptimeout


487ch10.sip.Status-Line.Status-Code

481 ch13.sip.CSeq.Method = INVITE no

Messaggio Malformato: Possibile Attacco

Genera un messaggio

di errore

si


ch10.sip


ch10.sip


ch10.sip

timeoutch13.sip ::= ch10.sip

ch13.sip

- Outbound -CANCEL

Successfulparte 2

200 481ch10.sip.Status-Line.Status-Code

Sequenza Errata: Possibile AttaccoDenial of Service


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.


99

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

Successfulparte 2


ch13.siptimeout

Ch10.sip ::= ch13.sip

ch10.sip


- Inbound -

ch13.sip.Request-Line.Method = ACK

si

no

Messaggio Errata: Possibile Attacco


Tramite FCP chiudere la porta esterna per SIP

AttesaMessaggio

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.


100

- Inb

ound

-B

YE

Verif

ica

sint

attic

a de

l m

essa

ggio

SIP

- Inb

ound

-

ch12

.Par

amet

riDia

logo

.Met

hod

::= c

h13.

sip.

Req

uest

-Lin

e.R

eque

st-U

RI.M

etho

dch

12.P

aram

etriD

ialo

go.F

rom

::=

ch13

.sip

.Fro

mch

12.P

aram

etriD

ialo

go.T

o ::=

ch1

3.si

p.To

ch12

.Par

amet

riDia

logo

.Cal

l-ID

::=

ch13

.sip

.Cal

l-ID

ch12

.Par

amet

riDia

logo

Atte

sa In

itDia

logo

DB

Ses

sion

e

ch12

.InitD

ialo

go

ch12

.InitD

ialo

go!=

NU

LL=

NU

LL

Proc

edur

a irr

egol

are:

non

esis

te il

dia

logo

che

lo

UA

vuol

e te

rmin

are

Gen

era

un

mes

sagg

io

di e

rrore

Atte

sa P

aram

etriD

ialo

goD

B Se

ssio

ne

ch12

.Par

amet

riDia

logo

.Via

ch13

.sip

.Via

= c

h12.

Par

amet

riDia

logo

.Via

si

no

Mes

sagg

io M

alfo

rmat

o:

Poss

ibile

Atta

cco

Den

ial o

f Ser

vice

- Inb

ound

-B

YE

succ

essf

ul

- Inb

ound

-B

YE

succ

essf

ul

ch7.

sip.

Stat

us-

Line

.Sta

tus-

Cod

e20

040

848

1

Tram

ite F

CP

chiu

dere

le

porte

est

erne

per

RTP

Atte

saM

essa

ggio

SIP

ch10

.sip

ch10

.sip

::=

ch7.

sip

Tram

ite F

CP

chiu

dere

la

porta

est

erna

per

SIP

ch10

.sip

:==

ch13

.sip

ch10

.sip

Atte

sa M

essa

ggio

SIP

Ris

post

a da

UA

inte

rno

ch7.

sip

Verif

ica

sint

attic

a de

l m

essa

ggio

SIP

- Out

boun

d -

timeo

ut


101

6.3.2 Messaggi in uscita

Atte

saM

essa

ggio

SIP

ch7.

sip

ch7.

sip.

Sta

rt-Li

neR

eque

st-L

ine

Sta

tus-

Line

ch7.

sip.

Req

uest

-Li

ne.M

etho

dIN

VIT

E

RE

GIS

TER

OP

TIO

NS

ch7.

sip.

Sta

tus-

Line

.Sta

tus-

Cod

e1X

X

2XX

3XX

6XX

5XX

4XX

- Out

boun

d -

INV

ITE

- Out

boun

d -

REG

ISTE

R- O

utbo

und

-O

PTI

ON

S

Fuor

i Seq

uenz

a:

Poss

ibile

Atta

cco

dall’

inte

rno

Den

ial o

f Ser

vice

Gen

era

un

mes

sagg

io d

i er

rore

- Out

boun

d -

BY

E

BY

E

Fuor

i Seq

uenz

a:

Pos

sibi

le A

ttacc

o da

ll’in

tern

oM

an in

the

Mid

dle

ACK

CA

NC

EL

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


102

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

ch7.sip.Request-Line.Request-URI= ALGAddr != ALGAddr

Messaggio malformato: Possibile Attacco

Registration Hijacking


ch7.sip.CSeq.Numseq

ch7.sip.Call-ID.Numcall

= ch12.ParametriDialogo.Call-ID.Numcall

!= ch12.ParametriDialogo.

Call-ID.Numcall




!= (ch12.ParametriDialogo.

CSeq.Numseq) + 1

= (ch12.ParametriDialogo.CSeq.Numseq) + 1

ch12.ParametriDialogo.Method ::= ch7.sip.Request-Line.Request-URI.Method

ch12.ParametriDialogo.From ::= ch7.sip.From.uri

ch10.sip


parte 3


parte 2


- Outbound -


Transazione iniziata dall’interno

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.


103


parte 2

ch11.sip

ch11.sip.Status-Line.Status-Code 403200

401

ch7.sip

AttesaMessaggio

SIP

Attesa MessaggioSIP Risposta da Registrar


ch11.sip

ch7.sip ::= ch11.siptimeout


parte 3

ch13.sip

ch13.sip.Status-Line.Status-Code 403200

401

ch10.sip

AttesaMessaggio

SIP

Attesa MessaggioSIP Risposta da Registrar esterno


ch10.sip


timeout



- Inbound -

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.


104

- Outbound -OPTIONS


- Outbound -

ch7.sip.Request-Line.Request-URI.Host = LocalAddrno si



ch10.sip


ch10.sip



ch10.sip

200 4XX

timeout

Attesa MessaggioSIP Risposta da UA esterno


ch7.sip

ch13.sip

timeout

ch13.sip.Status-Line.Status-Code200 4XX


ch10.sip


- Inbound -

AttesaMessaggio

SIP

AttesaMessaggio

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.


105

- Outbound -INVITE


- Outbound -


ch10.sip



ch10.sip

100 407


ch7.sip

ch7.sip.Request-Line.Method

ACK

altri

Branch = ch7.sip.ViaUA.Branch

si

no


ch7.sip


Genera un messaggio

di errore


ch13.sip


3XX

4XX5XX6XX

2XX

Sequenza Errata: Possibile AttaccoMan in the Middle


errore

- Outbound -INVITE

redirected

- Outbound -INVITEtrying

timeout

timeout

timeout


- Inbound -



AttesaMessaggio

SIP

Branch ::= ch7.ViaUA.Branch


ch7.sip

- Outbound -INVITEfailed



106

- Outbound -INVITEtrying


Genera un messaggio

di errore

ch7.sip.Contact = NULL

no

si

ch7.sip.To.Branch = NULLsi

no


ch10.sip


ch13.sip


4XX5XX6XX

2XX3XX


timeout


- Inbound -



Attesa Possibile MessaggioSIP CANCEL da UA interno

ch7.sip

ch7.sip.Request-Line.Method = CANCEL

si

no

- Outbound -CANCEL

- Outbound -INVITETryingparte 2

timeout

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.


107


timeout


ch13.sip

200 486

- Outbound -INVITE

successful

- Outbound -INVITEbusy


- Inbound -

ch13.sip.Start-LineRequest-Line Status-Line

ch13.sip.Request-Line.Method

Sequenza Errata: Possibile AttaccoDenial of Service

BYE


altri

3XX


Genera un messaggio

di errore

- Outbound -INVITETryingparte 2

- Outbound -INVITE

successful


Genera un messaggio

di errore

ch7.sip.Contact = NULL si

no

ch7.sip.sdp = NULL si

no


si


ch10.sip


timeoutch7.sip


ch10.sip

ch8: con FCP aprire le porte esterne per RTP


AttesaMessaggio

SIP


108

- Outbound -INVITE

redirected



ch13.sip.Contact = NULL sino

ch7.sip.ViaUA.Branch = ch13.sip.ViaUA.Branch nosi


si


ch10.sip


timeout

ch10.sip


AttesaMessaggio

SIP

ch13.sip


timeout

ch7.sip



ch10.sip

- Outbound -INVITE

busy



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.


109

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


- Outbound -

ch7.sip.To = ch12.Toch7.sip.From.uri = ch12.From.uri

ch7.sip.From.Tag = NULLch7.sip.Request-URI = ch12.Request-URI

ch7.sip.CSeq.Numseq = ch12.CSeq.Numseqch7.sip.Call-ID = ch12.Call-ID

Genera un messaggio

di errore

no



si


ch10.sip


ch10.sip

200 481

timeout


ch7.sip



ch13.siptimeout

- Outbound -CANCEL

successful



Genera un messaggio

di errore

ch12.InitDialogo

Attesa ParametriDB Sessione


110

- Outbound -CANCEL

successful


- Inbound -

ch13.sip.CSeq.Method = CANCELsi no


Genera un messaggio

di errore


ch13.sip

timeout


- Inbound -

487ch10.sip.Status-Line.Status-Code

481 ch13.sip.CSeq.Method = INVITE no


Genera un messaggio

di errore

si


ch10.sip


ch10.sip


ch10.siptimeout


ch13.sip

- Outbound -CANCEL

Successfulparte 2

- Outbound -CANCEL

Successfulparte 2


ch7.siptimeout


ch10.sip



AttesaMessaggio

SIP

6.3.2.4 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.


111

- Outbound -BYE


ch12.ParametriDialogo.Method ::= ch7.sip.Request-Line.Request-URI.Methodch12.ParametriDialogo.From ::= ch7.sip.From

ch12.ParametriDialogo.To ::= ch7.sip.Toch12.ParametriDialogo.Call-ID ::= ch7.sip.Call-ID


Attesa InitDialogoDB Sessione

ch12.InitDialogo

ch12.InitDialogo!= NULL = NULL

Procedura irregolare:non esiste il dialogo che lo UA vuole terminare


Attesa ParametriDialogoDB Sessione

ch12.ParametriDialogo.Via

ch7.sip.ViaUA = ch12.ParametriDialogo.ViaUA

si

no



- Outbound -BYE

successful


ch10.sip


ch13.sip

ch13.sip.Status-Line.Status-Code200 408

481

timeout


- Inbound -

ch8: con FCP chiudere le porte esterne per RTP

AttesaMessaggio

SIP

ch10.sip



- Outbound -BYE

successful


112

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.

ch12.ParametriDialogo.Method ::= ch13.sip.Request-URI.Methodch12.ParametriDialogo.From ::= ch13.sip.From

ch12.ParametriDialogo.To ::= ch13.sip.Toch12.ParametriDialogo.Call-ID ::= ch13.sip.Call-IDch12.ParametriDialogo.CSeq ::= ch13.sip.CSeq

ch12.ParametriDialogo.ViaProxy ::= ch13.sip.ViaProxych12.ParametriDialogo.ViaUA ::= ch13.sip.ViaUA

ch12.InitDialgo ::= INIZ_ESTERNA

ch12.ParametriDialogoch12.InitDialogo


ch12.ParametriDialogo.Method ::= ch7.sip.Request-URI.Methodch12.ParametriDialogo.From ::= ch7.sip.From

ch12.ParametriDialogo.To ::= ch7.sip.Toch12.ParametriDialogo.Call-ID ::= ch7.sip.Call-ID

ch12.ParametriDialogo.CSeq ::= ch7.sip.CSeqch12.ParametriDialogo.ViaUA ::= ch7.sip.ViaUA

ch12.InitDialgo ::= INIZ_INTERNA

ch12.ParametriDialogoch12.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.


113

ch7.sip.From.uri = NULL si

no




- Outbound -

ch7.sip.To.uri = NULL

si

ch7.sip.Call-ID = NULL

no

si

si

ch7.sip.Cseq.Method = ch7.sip.Request-Line.Method

si

no

ch7.sip.From.Tag = NULL si

no

no

ch7.sip.To.Tag = NULL no

ch7.sip.Via.Branch = NULL

no

si

ch5.sip.From.uri = NULL si

no




- Inbound -

ch5.sip.To.uri = NULL

si

ch5.sip.Call-ID = NULL

no

si

si

ch5.sip.Cseq.Method = ch5.sip.Request-Line.Method

si

no

ch5.sip.From.Tag = NULL si

no

no

ch5.sip.To.Tag = NULL no

ch5.sip.Via.Branch = NULL

no

si

114

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

Studio ed Analisi della Sicurezza dei Servizi Voice over IP con SIP e RTP Risultati e conclusioni

115

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

116

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

Studio ed Analisi della Sicurezza dei Servizi Voice over IP con SIP e RTP Appendice A – SIP Generator

117

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.

fopen ()

client

server

recvfrom()

bind()

socket()

close()

sendto()

calcolo del checksum

ip_gen()udp_gen()

socket()

sport := source_portsaddr := source_addr

fclose()

payload := file

dport := dest_portdaddr := dest_addr

Bloccato in attesa di connessione

Messaggio SIP

118

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

Segnale di Input

Segnale di Output

Riferimento

Elemento decisionale

Blocchi base per la descrizione del sistema

…..

Lista di segnali sul canale

Canale

ProcessoBlocco

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

Studio ed Analisi della Sicurezza dei Servizi Voice over IP con SIP e RTP Appendice B – SDL

119

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.

120

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

Studio ed Analisi della Sicurezza dei Servizi Voice over IP con SIP e RTP Bibliografia

121

[13] 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

Studio ed Analisi della Sicurezza dei Servizi Voice over IP con SIP e RTP Bibliografia

122

[28] 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

STUDIO ED ANALISI DELLA SICUREZZA DEI SERVIZI VOICE …teca.elis.org/1608/Matteo Mogno.pdf ·...

Documents

Transcript of STUDIO ED ANALISI DELLA SICUREZZA DEI SERVIZI VOICE …teca.elis.org/1608/Matteo Mogno.pdf ·...