Progettazione e Realizzazione di uno Sniffer VoIP

Sviluppo di uno strumento per intercettazione di Voice over IP. In questo caso si chiede di partire da uno studio dei problemi, proporre e realizzare una soluzione.

Indice

  1. 0 - Background
    1. 0.1 - Introduzione al mondo VoIP
      1. 0.1.1 - Scenari d'impiego di VoIP
      2. 0.1.2 - Funzionamento della tecnologia VoIP
    2. 0.2 - SIP
      1. 0.2.1 - Due parole su H.323
      2. 0.2.2 - Breve descrizione di SIP
      3. 0.2.3 - Esempio di sessione SIP
      4. 0.2.4 - Componenti nelle architetture SIP
  2. 1 - Introduzione al progetto
    1. 1.1 - Quale è lo scopo dell'applicazione e collocazione nell'ambito della sicurezza
    2. 1.2 - Breve descrizione dello stack su cui lavora JVoIP e scelte implementative
    3. 1.3 - Presentazione di un caso di studio in cui inserire JVoIP
  3. 2 - Descrizione dell'applicazione
    1. 2.1 - Analyser
      1. 2.1.1 - Architettura
      2. 2.1.2 - Presentazione dei diagrammi di collaborazione
      3. 2.1.3 - Diagramma delle Classi
      4. 2.1.4 - Diagramma degli Stati
    2. 2.2 - Player
  4. 3 - Bibliografia
    1. 3.1 - RFC
    2. 3.2 - Releted Papers
  5. Appendice A - JavaDoc

0 - Background [Indice]

0.1 - Introduzione al mondo VoIP: [Indice]


VoIP (Voice Over IP) è una teconologia che si basa su IP(Internet Protocol) il cui scopo è quello di trasmettere segnali vocali digitalizzati sulla rete, VoIP può quindi essere introdotto in ogni rete che usa IP come protocollo.

VoIP appartiene al gruppo di tecnoligie MoIP (Multimedia over IP), progettate per integrare applicazione multimediali in un unico servizio usando il protocollo IP.
Lo sviluppo massiccio della tecnologia VoIP è stato determinato dalla possibilità di avere i seguenti vantaggi:

L'aspetto economico è stato determinate per la produzione di soluzioni commercialmete valide, basti pensare che usando tecnologie VoIP il costo di chiamate internazionali in USA si riduce fino ad 1/5 della tariffa corrente.
Esitono tuttavia alcune classi di problemi da non sottovalutare:


0.1.1 - Scenari d'impiego di VoIP [Indice]

La tecnologia VoIP può essere impiegata in alcuni scenari, ad esempio:

Immagine del 1░ Caso di Studio
Fig.1: Host appertenente ad una rete IP collegata tramite gateway ad una rete PSTN tradizionale
Immagine del 2░ Caso di Studio
Fig.2: Un ipotetico Call Center

Lo scenario di Fig.2 presenta una situazione più complessa, tipica dei Call Center. Come si vede, abbiamo una rete IP aziendale alla quale sono collegati server per servizi di posta elettronica e fax (mail e fax Server), un gatekeeper(entità della rete che gestisce le chiamate, il QoS e i diritti degli utenti a fare traffico MoIP, traduzione da indirizzi alias in indirizzi IP), un directory Server e un Help Desk Data Base per la gestione del Call Center. I costumer possono usare sia reti PSTN che IP per comunicare con il call center che ha un gateway in entrata.

Immagine del 3░ Caso di Studio
Fig.3: Azienda con un Branch Office distaccato dalla sede centrale

Le due sedi comunicano sia tramite linee PSTN/ISDN che con rete IP; in particolare fax, telefoni usano un PBX (Private Branch eXchanges, che fornisce un canale in ricezione e trasmissione di 64kbps) usando PSTN/ISDN mentre i PC comunicano tramite una WAN su rete IP.

0.1.2 - Funzionamento di VoIP [Indice]

Voice (source)  - - ADC - - - - Internet - - - DAC  - - Voice (dest)

Lo schema mostra il funzionamento della tecnologia VoIP: partendo da sinistra verso destra, il segnale viene convertito da analogico a digitale usando un convertitore(ADC) quindi viene inviato sulla rete e successivamente riportato da digitale ad analogico usando un secondo covertitore (DAC). Una volta che il segnale è stato digitalizzato occorre un protocollo che permetta di inviare lo stream digitale sulla rete; tipicamente viene usato RTP (Real Time Protcol).

Voice )) ADC - Compression Algorithm -  Assembling RTP in TCP/IP -----
                                                         ---->      |
                                                         <----      |
Voice (( DAC - Decompress. Algorithm -  Disass. RTP from TCP/IP  -----

Come citato precedentemente IP non è stato progettato per implementare meccanismi real time, per questo motivo vengono sfruttati meccanismi che garantiscano la qualità del servizio(QoS), alcuni di questi sono:

0.2 - SIP [Indice]

0.2.1 - Due parole su H.323 [Indice]

Le prime soluzioni VoIP erano basate su protocolli proprietari che non hanno avuto un notevole successo. ITU-T ha prodotto invece uno stack di protocolli di rete: H.323 in grado di implementare servizi MoIP.

Immagine del 1░ Caso di Studio
Fig.5: Una visione dello stack di H.323
Immagine del 1░ Caso di Studio
Fig.6: Una possibile in frastruttura di rete con H.323

L'architettura dello stack H.323(fig.5) mostra come ITU-T abbia prodotto un'architettura veramante complessa e completa.

0.2.2 - Breve descrizione di SIP [Indice]

IETF invece ha prodotto SIP(Session Initation Protocol, RFC 3261 ), un protocollo di controllo che può stabilire, modificare o terminare sessioni multimediali, ad esempio telefonate via Internet. La flessibilità e la scalabilità di SIP potrebbe permettere in futuro la migrazione da linee PSTN a linee digitali SIP-based. SIP quindi non offre servizi, bensì offre primitive che possono essere usate per implementare servizi differenti(cfr. RFC3261 SIP:Session Initiation Protocol).

SIP non è un sistema di comunicazione verticale integrato, ma una componente che può essere affiancata da altri protocolli per la realizzazione di un'architettura multimediale completa. Tra questi protocolli citiamo:

SIP è un protocollo HTTP-like ovvero usa molti elementi tipici di HTTP, questo permette una maggiore integrazione con i servizi Web. Gli elementi comuni ad entrambi i protocolli sono:

SIP può essere trasportato sia da TCP che UDP, anche se viene sconsigliato TCP per la sua maggiore "pesantezza". L'uso di UDP non rapprenseta un limite per SIP, infatti il protocollo prevede una serie di meccanismi per renderlo affidabile.Le Trasazioni hanno proprio questo compito. Per implementare l'affidabilità si fa uso di:

Le funzionalità che SIP mette a disposizione sono :

SIP si basa su uno scambio di messaggi: Request/Response. Le Request sono costituite da una Request-Line contenente:

Il metodo: contenuto nella Request-Line può essere: REGISTER per registrare informazioni presso un Registar, INVITE, ACK, CANCEL per fare il setup della sessione, BYE per terminare la sessione e OPTIONS per interrogare i server circa i servizi a disposizione.

Il Request-URI contiene un SIP o SIPS URI che indica l'utente o il servizio al quale è indirizzata la Request:SIP:user:password@host:port;options (Es.: sip:bob@geminiy33.com)

SIP-Version indica la versione del protocollo SIP utilizzata.

Le Response invece di avere una Request-Line hanno una Status-line composta da :

Status Code: indica il codice di risposta alla Request ed è un codice di 3 cifre il cui significato è diviso per classi:

Reason Phrase: descrizione testuale dello Status-Code, questo campo è pensato per poter essere facilmente compreso dall'uomo.

Sia le Respone che le Request hanno una serie di Header ciascuno dei quali ha uno specifico significato. Anche in questo caso gli Header hanno una forte somiglianza con gli header HTTP, la generica forma di un header SIP è:

header = "header-name" HCOLON header-value *(COMMA header-value)

Il protocollo SIP prevede la possibilità di trasportare nel┬á body informazioni riguardanti le caratteristiche della sessione multimediale.(Ad esempio SDP)

0.2.3 - Esempio di Session SIP [Indice]

Qui di seguito riportiamo un esempio di sessione SIP, l'esempio è tratto dal RFC 3261:

                    atlanta.com  . . . biloxi.com
                 .      proxy              proxy     .
               .                                       .
       Alice's  . . . . . . . . . . . . . . . . . . . .  Bob's
      softphone                                        SIP Phone
         |                |                |                |
         |    INVITE F1   |                |                |
         |--------------->|    INVITE F2   |                |
         |  100 Trying F3 |--------------->|    INVITE F4   |
         |<---------------|  100 Trying F5 |--------------->|
         |                |<-------------- | 180 Ringing F6 |
         |                | 180 Ringing F7 |<---------------|
         | 180 Ringing F8 |<---------------|     200 OK F9  |
         |<---------------|    200 OK F10  |<---------------|
         |    200 OK F11  |<---------------|                |
         |<---------------|                |                |
         |                       ACK F12                    |
         |------------------------------------------------->|
         |                   Media Session                  |
         |<================================================>|
         |                       BYE F13                    |
         |<-------------------------------------------------|
         |                     200 OK F14                   |
         |------------------------------------------------->|
         |                                                  |

Alice, registrata presso atlanta.com, vuole contattare Bob registrato presso biloxi.com. Alice per contattare Bob dovrà usare un indirizzo ovvero un SIP URI nella forma sip:alice@atlanta.com e analogamente Bob risponderà con il suo SIP URI sip:bob@biloxy.com. Quando Alice decide di chiamare Bob il suo softphone invierà una Request del tipo:

	INVITE sip:bob@biloxi.com SIP/2.0 //Request-Line
	Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
	Max-Forwards: 70
	To: Bob <sip:bob@biloxi.com>
	From: Alice <sip:alice@atlanta.com>;tag=1928301774
	Call-ID: a84b4c76e66710@pc33.atlanta.com
	CSeq: 314159 INVITE
	Contact: <sip:alice@pc33.atlanta.com>
	Content-Type: application/sdp
	Content-Length: 142

come si può vedere sono presenti molti header per inizializzare la sessione con Bob. La Request verrà recapitata al proxy server di Alice atlanta.com che emetterà una Response verso Alice con codice 100 il cui significato è quello di Trying, ovvero il proxy ha riceuto l'INVITE e la sta inoltrando al destinatario. A questo punto il proxy di Alice dovrà spedire la Request all'URL indicato nella INVITE ovvero biloxy.com:

	INVITE sip:bob@biloxi.com SIP/2.0
	...

Per prima cosa verrà fatta una query DNS per risolvere l'hostname, successivamente verrà aggiunto nell'header VIA l'URL del proxy di Alice e quindi inoltrata la Requet. I proxy aggiungono il loro hostname nell'header VIA per far si che i messaggi SIP attraversino gli host nell'ordine indicato.
Quando biloxy.com riceve il messaggio emetterà un 100 Trying, aggiungerà il suo URL nell'header Via ed invierà la Requet a Bob.
Finalemente la Requet è giunta fino a Bob, il suo softphone riceve l'INVITE ed emetterà un 180 Ringing.
A questo punto Bob, se decide di rispondere, invierà un 200 OK per Alice per segnalare che la chiamata è stata accettata con successo:

	SIP/2.0 200 OK //Status-Line
	Via: SIP/2.0/UDP server10.biloxi.com
		;branch=z9hG4bKnashds8;received=192.0.2.3
	Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
		;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
	Via: SIP/2.0/UDP pc33.atlanta.com
		;branch=z9hG4bK776asdhds ;received=192.0.2.1
	To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
	From: Alice <sip:alice@atlanta.com>;tag=1928301774
	Call-ID: a84b4c76e66710@pc33.atlanta.com
	CSeq: 314159 INVITE
	Contact: <sip:bob@192.0.2.4>
	Content-Type: application/sdp
	Content-Length: 131

Come si può vedere, allo stato attuale l'header VIA contiene 3 campi, questo impone una route per i messaggi SIP attraverso gli hosts specificati rispettando l'ordine. La strada che seguirà il 200 OK di Bob sarà dunque:

server10biloxy.com -> bigbox3.site3.atlanta.com -> pc33.atlanta.com -> Alice

Solitamente nell'INVITE che emette Alice viene aggiunto un body SDP (Session Description Protocol) che rappresenta l'offerta fatta da Alice circa il modo con cui può comunicare(nome sessione, informazioni sulla sessione, connessione, bandwidth, descrizione sul media ecc...). A questa offerta deve seguire una risposta fatta da Bob, che sarà contenuta nel 200 OK.
Non appena Alice riceve il 200 OK contente la risposta SDP di Bob, risponderà con un ACK, da questo momento in poi i due potranno aprire una Media Session ed inviare e ricevere stream audio e/o video usando i parametri negoziati con i messaggi SDP. Nella sforatuna ipotesi in cui Alice non avrà nessuna capacità di streming (codec) in comune con Bod, Alice dovrà chiudere la sessione appena creata inviando una richiesta di tipo BYE.
Nel nostro caso Bob decide di riagganciare per primo inviando una Request di BYE, Alice la riceverà e produrrà un 200 OK.
Durante la Media Session Bob e Alice possono decidere di cambiare le caratterisctiche della sessione, questo verrà fatto inviando una una nuova richiesta di tipo INVITE("re-INVITE") alla quale si potrà rispondere con un 200 OK. Nel caso che la re-INVITE non venga accettata, il destinatario invierà un messaggio con codice 488 (Not Acceptable Here), ciò non causa l'interruzione della sessione esistente.(Per maggiorni informazioni circa il funzionamento di SIP rimandiamo al RFC 3261 SIP:Session Initation Protocol, mirror ZVon formato HTML).

0.2.4 - Componenti nelle architetture SIP [Indice]

Esistono una serie di componenti tipici nelle architetture SIP:

1 - Introduzione al progetto [Indice]

1.1 - Quale è lo scopo dell'applicazione e collocazione nell'ambito della sicurezza [Indice]

L'applicazione è stata progettata per analizzare traffici VoIP basati su protocollo SIP e riprodurre le sessioni audio/video individuate dall'applicazione.
JVoIP basa le sue ricerche sull'analisi di un file in formato libpcap ottenuto usando uno sniffer(ad esempio: Ethereal, Dsniff, Tcpdump, etc.) da un punto di ascolto affidabile.
Partendo da questo file l'applicazione estraee tutte le informazioni utili per poter riprodurre le conversazioni avvenute tra gli hosts.
JVoIP quindi si colloca nell'ambito della sicurezza come uno sniffer di sessione audio/video tra utenti SIP presenti su una rete IP.

1.2 - Breve descrizione dello stack su cui lavora JVoIP e scelte implementative [Indice]

Lo stack su cui lavora JVoIP è quello riportato di seguito:


Fig.6: Il flusso di dati nella fase di Analis di JVoIP

JVoIP è stato realizzato usando Java, questo perchè tale linguaggio offre una serie di librerie utili allo sviluppo dell'applicazione e facilemente integrabile tra loro inoltre anche perchè il know-how di partezza su tale linuguaggio era maggiore e ha rihicesto in minore tempo di start-up. Le librerie utilizzate sono:

JVoIP è stato progettato in maniera modulare, per due motivi:

1.3 - Presentazione di un caso di studio in cui inserire JVoIP [Indice]

Supponiamo che gli utenti Alice e Bob lavorino presso un'azienda e che Bill sia il loro datore di lavoro. La ditta ha fatto di recente una migrazione da linee PSTN ad un servizio VoIP basato su SIP(Fig. 7). Bill si è accorto che da un pò di tempo a questa parte Bob e Alice hanno avuto un calo di rendimento, decide quindi di tenerli d'occhio e di verificare se il traffico telefonico tra i due rigurardi esclusivamente temi di lavoro. Bill attiva uno sniffer su un host sul quale passa il traffico telfonico tra Alice e Bob. Una volta sniffato il traffico Bill usando JVoIP può riascoltare le sessioni audio/video individuate.

Un uso pratico di JVoIP
Fig.7: Un uso pratico di JVoIP

2 - Descrizione dell'applicazione [Indice]

Come abbiamo precedentemente citato JVoIP è stato progettato in due moduli distinti un Analyser e un Player.Il primo analizza e mostra le sessioni esistenti , il secondo riproduce quest'ultime.

2.1 - Analyser [Indice]

2.1.1 - Architettura [Indice]

Il sistema è composto da quattro entità: SniffReader, DialogManger, ReinviteDialogManger, SessionManager. SniffReader è l'entità che estrae dal file libpcap i pacchetti e poi li smista ai Manager(fig.8). DialogManger è il primo a ricevere i pacchetti, lui gestisce sia la creazione di Dialog che l'assegnamento dei pacchetti a ciascun Dialog. La creazione di Dialog avviene quando il pacchetto ricevuto è un messaggio SIP che contiene le caratteristiche necessarie per instaurare una nuova comunicazione. Altrimenti se il messaggio fa parte di una comunicazione in corso, la sua gestione verrà delegata al Dialog opportuno. La gestione dei messaggi SIP da parte del Dialog comporta l'aggiornamento del suo stato interno ed eventualmente la creazione o aggiornamento di una Session(gestisce un insieme di Stream, uno per ogni media utilizzato nella comunicazione) attraverso il SessionManager attivo. Il secondo a ricevere i pacchetti è ReinviteDialogManger che ha il compito di individuare le comunicazione pre-esistenti l'attivazione della sonda di rete.
Il terzo Manager è SessionManager il cui compito è quello di inoltrare i pacchetti che fanno parte degli stream multimediali alle Session e implementa i metodi per poter creare e aggiornare le Session. Session individua lo stream di apparteneza, attraverso il matching di IP e Port, per ogni pacchetto che riceve e memorizza il pacchetto nello stream. Una Session ha un numero di Stream pari al numero di media utilizzati durante la comunicazione; questo significa che se abbiamo una comunicazione dove il peer A utilizza audio/video con il peer B e viceversa, allora vi saranno in gioco 4 media: video A->B, audio A->B, video B->A, audio B->A.
Finita la fase di analisi del file, l'applicazione permette di riprodurre la comunicazione desiderata attraverso un player interno oppure di inviare la comunicazione ad un host utilizzando protocollo RTP.

Schema rappresentate del flusso dei dati nella fase Analyzer
Fig.8: Schema rappresentate del flusso dei dati nella fase Analyzer

2.1.2 - Presentazione dei diagrammi di collaborazione [Indice]

Di seguito abbiamo riportato i diagrammi di collaborazione prodotti:

2.1.3 - Diagramma delle Classi [Indice]

Qui di seguito è riportato il collegamento al diagramma delle classi. Diagramma UML delle classi relative al Analyzer

2.1.4 - Diagramma degli Stati [Indice]

Qui di seguito è riportato il collegamento al diagramma degli stati del Dialog. Diagramma UML degli stati della classe Dialog. Il diagramma degli stati per la classe ReinviteDialog non è presente perchè è del tutto simile a quello della classe Dialog dove lo stato di partenza e ReInvite.

2.2 - Player [Indice]

Il player è concretizzato nella classe MultiMediaPlayer, la sua realizzazione sfrutta il JMF(Java Media Framework), un insieme di classi orientate al multimedia. Questa scelta è stata intrapresa per la facile integrazione con il resto dell'applicazione. Il compito del player e quello di presentare gli stream multimediali, appena inizia il flusso dei dati per ogni stream appare una toolbar con la quale è possibile reperire alcune informazioni riguardanti lo stream.

3 - Bibliografia [Indice]

3.1 - RFC [Indice]

3.2 - Related Papers [Indice]

Appendice A - JavaDoc [Indice]

La JavaDoc dell'applicazione è consultabile al seguente indirizzo JavaDoc