UNIVERSITÀ DEGLI STUDI DI SALERNO Dipartimento di Informatica. SIPAttack

Transcript

1 UNIVERSITÀ DEGLI STUDI DI SALERNO Dipartimento di Informatica CORSO DI LAUREA MAGISTRALE IN INFORMATICA SICUREZZA DEI DATI SIPAttack Docenti: Ch.mo Prof. Alfredo De Santis Ch.mo Prof. Francesco Palmieri Candidati: Francesco Genio Amedeo Leo Carmine Scala ANNO ACCADEMICO

2 Sommario Introduzione... 6 Overview... 9 Capitolo I: Il mondo Asterisk Cosa si intende con Asterisk? Cos è un PBX? Cos è il VoIP? Come può essere utile Asterisk? Come PBX Come un Gateway VoIP Chi usa Asterisk oggi? Capitolo II: Una panoramica sui protocolli VoIP Introduzione I protocolli VoIP Protocollo IAX (Inter-Asterisk exchange) Protocollo SIP (Session Initial Protocol) Tipologie di pacchetti Registrazione SIP Protocollo H Protocollo MGCP (Media Gateway Control Protocol) Protocollo RTP (Real-time Transport Protocol) Capitolo III: Configurazione Asterisk Introduzione File di configurazione Asterisk Configurazione Connessione Sip Esempio di sip.conf Configurazione Dialplan Configurazione Manager.conf Tipi di messaggio Libreria Asterisk-Java Connessione al Manager e comunicazione con Asterisk Modulo Voice Mail Configurazione Setting Voice Mail Configurazione Mailbox Lasciare e recuperare messaggi Capitolo IV: Attacchi al PBX Asterisk

3 Introduzione Attacchi Denial of Service SIPVicious Capitolo V: SIPAttack Introduzione Caratteristiche Contesto Interfaccia Sequence e class diagram Primo passaggio Ricerca server SIP Secondo passaggio Ricerca interni Terzo passaggio Ricerca Password Alert Approfondimento su SIP Digest authentication Capitolo VI: Migliorare la sicurezza di Asterisk Introduzione Perfezionare SIP Proteggere il server Firewall Introduzione IPTables fail2ban Installazione e configurazione di fail2ban con IPTables Sicurezza e SIPAttack SecAst Conclusioni Perché usare Asterisk? Cosa è stato fatto Riferimenti

4 Indice delle figure Figura 1: Commutazione di circuito Figura 2: Commutazione di pacchetto Figura 3: Infrastruttura VoIP Figura 4: Asterisk Figura 5: Un esempio di PBX Figura 6: VoIP Figura 7: Un esempio di connessione Figura 8: Esempio di scambio di pacchetti IAX Figura 9: Trunk IAX Figura 10: Trapezio SIP Figura 11: Rete SIP Figura 12: Setup di una sessione SIP Figura 13: Esempio di messaggio INVITE Figura 14: Esempio di risposta Figura 15: Esempio di REGISTER Figura 16: Registrazione server SIP - Primo passaggio Figura 17: Registrazione server SIP - Secondo passaggio Figura 18: Registrazione server SIP - Terzo passaggio Figura 19: Registrazione server SIP - Quarto passaggio Figura 20: Architettura e componenti di una rete H Figura 21: File di configurazione di Asterisk Figura 22: Alcuni file di configurazione e relative caratteristiche Figura 23: Rappresentazione del collegamento tra i file sip.conf e extensions.conf Figura 24: Rappresentazione grafica del dialplan Figura 25: Rappresentazione del dialplan tramite automa Figura 26: Dialplan reload Figura 27: ManagerConnectionFactory Figura 28: Metodo onmanagerevent Figura 29: Effettuare una chiamata Figura 30: Flussi di traffico tra host e server Figura 31: Un DoS distribuito Figura 32: DoS interno Figura 33: Esempio di utilizzo di svmap Figura 34: Esempio di utilizzo di svwar Figura 35: Esempio di utilizzo di svcrack Figura 36: Mockup ricerca server Figura 37: Mockup ricerca interni Figura 38: Mockup ricerca password Figura 39: Sequence diagram per ricerca server Figura 40: Sequence diagram per ricerca interni Figura 41: Sequence diagram per ricerca password Figura 42: Class diagram Figura 43: Prima interfaccia - Ricerca server SIP Figura 44: Prima interfaccia - Esempio di Ricerca server SIP Figura 45: Prima interfaccia - Costruzione di un pacchetto REGISTER Figura 46: Prima interfaccia - Stampa del pacchetto creato Figura 47: Prima interfaccia - Stampa del pacchetto ricevuto

5 Figura 48: Seconda interfaccia - Ricerca interni Figura 49: Seconda interfaccia - Esempio di Ricerca Interni Figura 50: Seconda interfaccia - Costruzione di un pacchetto REGISTER Figura 51: Seconda interfaccia - Stampa del pacchetto ricevuto (401) Figura 52: Seconda interfaccia - Stampa del pacchetto ricevuto (404) Figura 53: Terza interfaccia - Ricerca password Figura 54: Terza interfaccia Esempio di ricerca password (password non trovata) Figura 55: Terza interfaccia Esempio di ricerca password (password trovata) Figura 56: Terza interfaccia - Costruzione primo pacchetto REGISTER Figura 57: Terza interfaccia - Stampa del pacchetto ricevuto (401) Figura 58: Terza interfaccia - Costruzione secondo pacchetto REGISTER Figura 59: Terza interfaccia - Stampa del pacchetto ricevuto (200) Figura 60: Terza interfaccia - Algoritmo md Figura 61: Info ricerca server SIP Figura 62: Info ricerca interni Figura 63: Info ricerca password Figura 64: Risposta all'autenticazione Figura 65: Parametro "alwaysauthreject" impostato a "no" Figura 66: Parametro "alwaysauthreject" impostato a "yes" Figura 67: Esempio di utilizzo di IPTables prima della configurazione Figura 68: Fail2ban Figura 69: Esempio di utilizzo di IPTables dopo la configurazione Figura 70: Funzionamento di SIPAttack con il firewall IPTables disattivato Figura 71: Funzionamento di SIPAttack con il firewall IPTables attivato Figura 72: SecAst logo Figura 73: Phone inside wall Figura 74: Esempio di architettura

6 Introduzione Nel 1995 un team di ricercatori israeliani eseguì la prima chiamata telefonica trasmessa sul protocollo IP: crearono un nuovo modo di comunicare. Tale tecnologia, in seguito, fu chiamata Voice over IP (VoIP), proprio dal fatto che la voce degli interlocutori non avrebbe viaggiato più sulle reti analogiche PSTN ma, digitalizzata, sarebbe stata inviata sulla rete Internet. In questa parte introduttiva sono analizzati i vantaggi e gli svantaggi della rete PSTN; quindi l attenzione sarà spostata sulla tecnologia VoIP e sull argomento principale, Asterisk. La rete PSTN (Public Switched Telephony Network) è stata pensata e progettata per il trasporto della voce ed adotta la tecnologia a commutazione di circuito: quando inizia una comunicazione, gli switch interni della rete commutano per creare un circuito "fisico" diretto fra la parte chiamante e quella chiamata. Ciò significa che per la durata della connessione gli interlocutori dispongono di un canale dedicato. L allocazione è dunque statica, ed ogni circuito garantisce una banda di 64 kbps bidirezionale (full duplex). La banda costante e il collegamento diretto tra le due parti permettono al segnale vocale di avere qualità garantita per tutta la durata della comunicazione, ma al tempo stesso si ha una bassa percentuale di utilizzazione della rete; in altre parole non si trae vantaggio dal fenomeno del multiplexing statistico. Infatti, durante una comunicazione vocale, un interlocutore passa più della metà del tempo in silenzio, in quanto i due interlocutori non parlano contemporaneamente: quando uno parla l'altro (normalmente) resta in silenzio; inoltre anche tra una parola e l'altra ci sono degli istanti di silenzio. I 64 kbps (full-duplex) allocati sono, perciò, usati per meno della metà del periodo della conversazione e la banda libera rimane inutilizzata. Il costo di una chiamata tramite PSTN è basato sulle risorse riservate, dunque in base al tempo d'utilizzo e alla lunghezza del collegamento, e non in base alle risorse effettivamente impiegate. Figura 1: Commutazione di circuito. Un altro limite della rete telefonica è l'utilizzo di un codec standard e predeterminato a priori, il PCM64. Questo fattore è limitante sia nel momento in cui si volesse utilizzare la rete telefonica per il trasporto di audio compresso con una maggiore efficienza, sia se si volesse trasportare audio ad alta qualità (ad esempio aumentando il bitrate oppure utilizzando un codec con caratteristiche migliori). Questi motivi portano a concludere che, tecnicamente, la tecnologia su cui si basa la telefonica classica può essere migliorata, ed è proprio su questo punto che andrà a puntare la tecnologia VoIP. La totalità delle reti dati oggi esistenti si basa sul concetto di commutazione di pacchetto, ossia la creazione di un'unità elementare di trasporto che sia in grado di viaggiare in maniera più o meno autonoma sulla rete, recapitando a destinazione il suo contenuto informativo. La architettura di rete dati allo stato attuale è la rete IP, caratterizzata da un servizio di tipo best effort, senza meccanismi di prenotazione di risorse. Gli 6

7 apparati intermedi (nodi) non creano un circuito fisico tra le parti, ma instradano il pacchetto nella giusta direzione in base all'informazione contenuta nell'intestazione dello stesso. In questo modo non si ha allocazione di risorse riservata; su una linea di collegamento (link) possono transitare contemporaneamente anche pacchetti appartenenti a flussi diversi, aumentando notevolmente la percentuale d'utilizzazione della rete rispetto a quella telefonica. Alcuni pacchetti di uno stesso flusso, però, possono percorrere cammini diversi, possono arrivare a destinazione fuori sequenza, oppure possono perdersi. In tali casi, l'apparato terminale (ad esempio il PC) ha il compito di ordinare i pacchetti nella sequenza corretta e richiedere eventualmente la ritrasmissione di quelli persi, rendendo il trasporto affidabile. Quest'operazione può però non essere opportuna nel caso di trasmissione della voce, poiché introduce notevoli ritardi ai quali i flussi voce sono particolarmente sensibili. Figura 2: Commutazione di pacchetto. Quali sono i vantaggi di una rete dati? Il costo di una "chiamata" in tecnologia dati è normalmente determinato dalla quantità di dati che passano, indipendentemente dalla durata della comunicazione. La rete IP non ha il call setup, rendendo la gestione della chiamata decisamente meno onerosa. Tuttavia questa scelta impone dei vincoli non indifferenti per la gestione della qualità del servizio spettante alla singola chiamata: questo è il motivo per cui altre tecnologie di reti dati mantengono il concetto di call setup. Come si vedrà in seguito, uno dei problemi principali della rete IP è proprio la fornitura di determinate garanzie di qualità alla telefonata. La prima volta in cui il termine VoIP è arrivato al grande pubblico è stato quando, nel 1995, la Vocaltec ha rilasciato la prima versione dell'applicazione "Internet Phone". Questo software, installato sul proprio personal computer, abilitava gli utenti a comunicare tramite audio e testo e permetteva di trasmettere e condividere immagini e grafici tramite una whiteboard mediante l'impiego di normalissimi dispositivi quali un microfono, le casse e, per il video, una videocamera. In mancanza di questi oggetti hardware il prodotto instaurava una comunicazione al meglio delle sue possibilità. Ad esempio, in mancanza di una telecamera il software consentiva di ricevere immagini ma (ovviamente) non di inviarle. Il VoIP era quindi inteso come uno strumento che permettesse di poter effettuare chiamate vocali da un personal computer all'altro, rendendo possibile una comunicazione in tempo reale con l'aggiunta di funzionalità avanzate quali video, lavagna condivisa, e altro. Non ultimo, la possibilità di poter condividere il proprio desktop sul PC offriva la possibilità di operare direttamente su una macchina remota (ad esempio per risolvere problemi di configurazione), funzionalità molto comoda in determinate occasioni. Il VoIP si basa sulla conversione di un segnale analogico (la voce umana) in un segnale digitale in grado di viaggiare sulla rete IP mediante un ADC (convertitore analogico-digitale); il segnale digitale generato viene 7

8 trasmesso tramite la rete Internet, e trasformato di nuovo in formato analogico mediante un DAC (convertitore digitale-analogico). Figura 3: Infrastruttura VoIP. Il segnale digitale, sotto forma di pacchetti di segnali IP, transita attraverso la rete Internet e raggiunge gli altri utenti (telefoni VoIP, telefoni standard oppure telefoni cellulari). Il pacchetto è inviato tramite due tipi di protocolli: Signaling( segnalazione ) della conversazione (ricostruzione del frame audio, sincronizzazione, identificazione del chiamante). Il protocollo più comune è RTP. Trasporto dei dati (pacchetti voce su IP). Il protocollo più usato è SIP. Asterisk è oggi il principale software per la realizzazione di centralini VoIP: si tratta di un software open source che funziona in ambiente Linux ed è in grado di attribuire ad un normale PC le funzionalità tipiche di un centralino telefonico evoluto. Asterisk abbraccia il concetto di conformità agli standard, ma al tempo stesso concede la libertà di sviluppare le proprie idee. Qualsiasi cosa si sceglie di implementare, Asterisk non impone limiti. Ha dimostrato che gli utenti non hanno bisogno di contare su operatori telefonici commerciali per i propri sistemi. Anzi, è possibile utilizzare standard aperti o modificare il software secondo le proprie esigenze. Asterisk è stato progettato per sostituire il tradizionale PBX: ha la capacità di memorizzare la segreteria telefonica, di effettuare chiamate in conferenza, di gestire la musica di attesa e di parlare con una vasta gamma di apparecchi telefonici. Inoltre è scalabile, in grado di gestire sia un piccolo ufficio che una grande impresa. Naturalmente, questa incredibile flessibilità ha un prezzo: Asterisk non è semplice da configurare. Questo non perché è un sistema criptico o confusionario; anzi è molto sensibile e pratico. Ma ci sono troppi modi diversi per raggiungere un unico risultato; risulta difficile contemplare le possibilità, a meno di tanto studio e pratica. 8

9 Overview Nel Capitolo 1 è descritto in dettaglio Asterisk e le sue funzionalità, mentre nel Capitolo 3 l attenzione viene focalizzata sulla configurazione di particolari file per gestire voic , dialplan e molto altro. Nel Capitolo 2 è fornita una panoramica sui protocolli VoIP necessari per il corretto funzionamento di una chiamata. Nel Capitolo 4 sono affrontati alcuni tipi di attacchi al PBX Asterisk; tra questi è descritto SIPVicious, un insieme di strumenti utile a controllare i sistemi VoIP basati su SIP: permette di testare la sicurezza del proprio centralino SIP tramite la costruzione di un attacco. Nel Capitolo 5 è descritto SIPAttack, il tool realizzato che si ispira a SIPVicious: a differenza del primo, è sviluppato in Java e consente a chiunque l utilizzo, essendo dotato di un interfaccia grafica semplice ed intuitiva. Nel Capitolo 6 vengono presentati alcuni metodi per poter migliorare la sicurezza del proprio PBX e per poter impedire al tool SIPAttack di funzionare correttamente. 9

10 Capitolo I: Il mondo Asterisk Cosa si intende con Asterisk? Asterisk è un implementazione software di un sistema PBX. È un software libero che permette la gestione di una rete telefonica e la connessione a servizi di telefonia PSTN o VoIP. La sua creazione è dovuta a Mark Spencer, un ingegnere informatico statunitense: poiché aveva fondato una società che sviluppa schede d interfaccia FXS 1 e FXO 2, era particolarmente interessato a facilitarne la diffusione; diede quindi vita ad Asterisk nel 1999 e ne permise la libera distribuzione. Asterisk ricopre oggi un ruolo importante nel settore della telefonia; ad esempio, in applicazioni come la mediazione RTG/IP (centralini telefonici che utilizzano sia le linee telefoniche tradizionali sia i canali IP) o sistemi Centrex (PBX "virtuali" e centralizzati), applicazioni per la gestione di Call Center e molto altro. Figura 4: Asterisk. Cos è un PBX? Asterisk, innanzitutto, è un Private Branch Exchange. Un PBX è una centrale telefonica per uso privato, utilizzata soprattutto nelle organizzazioni per fornire una rete telefonica interna, allacciandola a quella esterna. Inizialmente impiegati negli Stati Uniti, i PBX erano comodi per medio-grandi imprese che avevano necessità di generare un vasto traffico telefonico all interno della stessa ubicazione. Sono dispositivi hardware che possono gestire sia piccoli uffici che un vasto sistema. Il vantaggio è quindi di risparmiare sul numero di canali di fonia da chiedere in gestione ad un provider, senza la necessità di linee dedicate. 1 Un Foreign Exchange Station è un dispositivo che fornisce il servizio telefonico agli apparecchi telefonici, chiamati Foreign Exchange Office. 2 Un Foreign Exchange Office è l'interfaccia che riceve il servizio di telefonia da una rete POTS; genera i segnali di aggancio e rilascio della linea telefonica, che vengono interpretati dall'fxs all'altro capo della linea. Un esempio sono i fax o i modem. 10

11 Figura 5: Un esempio di PBX. Asterisk è un PBX completo. Implementa tutte le caratteristiche principali della maggior parte dei PBX disponibili in commercio. Ogni centralino, infatti, svolge di base tre compiti: 1. Crea un circuito fra i telefoni di due utenti, mappando il numero chiamato in un telefono fisico (se non occupato). 2. Mantiene la connessione attraverso un meccanismo di segnalazione. 3. Fornisce informazioni utili, come durata e costo. I centralini possono anche essere associati a servizi con più numeri in entrata, o configurati perché ve ne sia uno solo che abilita i cosiddetti interni, ovvero diversi numeri di utenza, ciascuno con un proprio suffisso da aggiungere a quello base del centralino. Implementa anche, gratuitamente, caratteristiche che spesso sono a pagamento: Chiamate in teleconferenza. Code di chiamata. Direct Inward System Access 3. Cos è il VoIP? Voice over Internet Protocol è una delle nuove parole d'ordine dei media oggi. Diverse aziende si sono imposte sul mercato vendendo servizi e software VoIP, mentre i servizi di messaggistica istantanea stanno iniziando a includere funzionalità VoIP. Ma che cosa è esattamente il VoIP? È una tecnologia che permette di instaurare una conversazione telefonica sfruttando una connessione Internet o una rete a commutazione di pacchetto. In realtà, è l insieme di protocolli di comunicazione che rendono possibile la telefonata. Grazie a diversi provider VoIP è possibile effettuare chiamata anche verso la PSTN 4. 3 Consente a un chiamante esterno di accedere ad un abbonato locale utilizzando codici DTMF (senza necessità di un operatore umano allo scambio telefonico). 4 Public Switched Telephone Network, è la rete telefonica generale che offre telefonia, videotelefonia e trasmissione dati. 11

12 Figura 6: VoIP. Il vantaggio principale è nella scelta di sfruttare l allocazione dinamica delle risorse, optando per una commutazione di pacchetto a scapito di una commutazione di circuito (senza dunque riservare banda per ogni telefonata). I pacchetti vengono instradati sulla rete e contengono le informazioni vocali, naturalmente codificate in digitale. Gli altri benefici riguardano: Minore costo per chiamata; le telefonate sono gratuite tra utenti con medesimo provider. Minore costo per la rete (se è già disponibile una rete IP, è possibile usare la stessa). Possibilità di mantenere diversi numeri su un singolo collegamento. Eliminazione della distinzione tra chiamate locali e a lunghe distanze. Le conversazioni non devono inoltre viaggiare obbligatoriamente su Internet: possono usare come mezzo trasmissivo una qualsiasi rete privata basata sul protocollo IP. VoIP si è affermato per una serie di motivi; il più significativo è la sua capacità di utilizzare una rete esistente per le chiamate vocali, le quali usano meno banda rispetto alla rete telefonica. Tale risparmio, derivato da una compressione migliore, comporta tuttavia un degrado della qualità della voce. Un altro motivo predominante è la mobilità: le telefonate possono essere inviate e ricevute ovunque sia disponibile una connessione dati. Naturalmente, il VoIP non è esclusiva di Asterisk. Vi è un mercato in crescita di PBX basati su software che hanno come VoIP una caratteristica importante. Figura 7: Un esempio di connessione. 12

13 Come può essere utile Asterisk? Come PBX Asterisk è, prima di tutto, un PBX. Possiede numerose caratteristiche, alcune comuni a gran parte dei PBX, altre presenti solo in modelli di fascia alta: Teleconferenza: il sistema MeetMe comprende una larga gamma di peculiarità, come la protezione delle conferenza tramite PIN, la moderazione (per permettere solo a determinati utenti di parlare), la registrazione delle chiamate, con costi contenuti. Segreteria telefonica: incorpora pressoché tutto ciò che ci si può aspettare da un tale sistema; un elenco completo di segreteria, l'inoltro e la possibilità di creare diversi messaggi in uscita a seconda che l utente sia già al telefono o sia fuori per un lungo periodo di tempo. Le caratteristiche più avanzate includono la facoltà di inviare il messaggio vocale come allegato ad un indirizzo mail. Chiamata in coda: è possibile avere risposta a seconda dell arrivo o in maniera casuale. Permette anche di assegnare priorità, in modo che determinati chiamanti siano serviti prima. Come un Gateway VoIP La più grande caratteristica di Asterisk è la sua capacità in ambito VoIP. Grazie all espansione della banda larga in quasi tutte le società e ad un numero sempre crescente di utenti, il VoIP si è diffuso ampiamente negli ultimi anni. Asterisk si è rivelato essere uno strumento di cui nessuno sapeva di averne bisogno, che ha preso sempre più spazio a scapito del tradizionale setup telefonico, grazie anche a numerosi provider di Internet-to-PSTN a basso costo. Asterisk e VoiP provvedono a diversi scenari: Call Center virtuali: le sole presenze fisiche che un call center necessita sono server per gestire il routing delle chiamate e per terminare le chiamate in entrata, come ad esempio un provider VoIP. Le persone che rispondono alle chiamate possono sia utilizzare il loro computer con un softphone 5 e una cuffia, sia un Analog Telephone Adapter 6 per collegare una connessione VoIP ad un telefono fisico. È possibile anche contattare i dipendenti non in sede come se fossero in ufficio: quando un telefono accede ad Asterisk, non importa la posizione in cui si trova, perché diventa un estensione del PBX, con tutti i vantaggi associati. Bypassare le compagnie telefoniche: un altra caratteristica di Asterisk è la capacità di creare la propria rete telefonica solo VoIP, senza la necessità di utilizzare la rete PSTN. In più, grazie a MeetMe, è possibile effettuare chiamate in teleconferenza con facilità. Asterisk può essere utilizzato per inviare conversazioni vocali sui data-link in contrasto con le linee telefoniche, risparmiando denaro e lasciando le linee telefoniche libere per altri scopi. Chi usa Asterisk oggi? Asterisk si è diffuso in rete alla fine del 2003, quando divenne abbastanza stabili e i primi utenti si interessarono al VoIP. Poiché la maggior parte di questi erano tecnofili alla ricerca di un programma che era libero o economico, e facilmente configurabile per qualsiasi scopo, trovarono facile risposta. Oggi piccoli gruppi sono specializzati per la creazione di server Asterisk sia per uso pubblico che privato, uno dei quali è il Collector s Net (o C*NET): è stato uno dei primi gruppi a chiedersi, poiché il VoIP era 5 Un softphone è un programma software per effettuare chiamate telefoniche via Internet usando un computer general purpose, piuttosto che un hardware dedicato. Di solito è usato con un auricolare collegato alla scheda audio del PC, o con un telefono USB. 6 Un ATA è un dispositivo usato per connettere dei telefoni analogici standard in modo da utilizzarli mediante altri sistemi (ad esempio VoIP). Sono generalmente forniti per permettere agli utenti di collegare il proprio telefono isolandolo dal cavo tradizionale. 13

14 diventato praticabile, come connettere i loro switch tramite la rete. Crearono, nel 2004, uno schema di commutazione centrale, con un metodo automatico di routing delle chiamate. Esistono anche dei gruppi di pirati telematici (cosiddetti phreaker), come Bell s Mind e Telephreak: per essi, l abilità di sfruttare il sistema telefonico all insaputa dell utente è altrettanto stimolante di quando i primi computer diventarono disponibili per gli hacker. In ambito didattico, invece, è importante il caso di un università in Texas che ha rimpiazzato il suo grande sistema, potente mix di PBX Nortel e Cisco Call Manager, con Asterisk. Le ragioni fondamentali sono state sia il costo della licenza di ciascun telefono sia per motivi di sicurezza su Windows Asterisk non rende solo facile alle aziende sostituire i loro sistemi, ma permette anche alle compagnie telefoniche di gestire il VoIP. Numerosi Competitive Local Exchange Carriers (o CLEC) 7 stanno favorendo la diffusione del VoIP, fornendo al consumatore un servizio aggiuntivo e a basso costo. 7 Negli Stati Uniti e in Canada, sono società di provider in competizione con altre già forti sul mercato. 14

15 Capitolo II: Una panoramica sui protocolli VoIP Introduzione La base del funzionamento del VoIP è la pacchettizzazione dei flussi audio per il trasporto su reti. Se i pacchetti vengono persi o ritardati, la comunicazione sarà disturbata e non permetterà una normale conversazione. I protocolli di trasporto che costituiscono Internet non erano in origine progettati per avere uno streaming come quello della mente umana; gli endpoint aspettavano i pacchetti mancanti, o nei casi più gravi richiedevano la ritrasmissione. In una tipica conversazione vocale, questi meccanismi non servono. La rete PSTN tradizionale è stata progettata specificamente per lo scopo della trasmissione vocale, ed è perfettamente adatta al compito da un punto di vista tecnico. Ma i suoi difetti sono lampanti quando si parla di flessibilità. Il problema con la trasmissione vocale basata su pacchetti deriva dal fatto che il modo in cui si parla è totalmente incompatibile con il modo in cui IP trasporta dati. Parlare e ascoltare consiste nell invio di un flusso audio, mentre i protocolli Internet sono progettati per incapsulare i bit in migliaia di pacchetti e inoltrare gli stessi verso la destinazione. I protocolli VoIP Il meccanismo per il trasporto di una connessione VoIP generalmente comporta una serie di transazioni di segnali tra endpoint, che porta alla creazione di due flussi multimediali, uno per ciascuna direzione, che costituiscono la conversazione reale. Esistono diversi protocolli per la gestione della comunicazione. Protocollo IAX (Inter-Asterisk exchange) IAX è un protocollo free ma non è ancora uno standard; è stato sviluppato da Digium allo scopo di abilitare connessioni VoIP tra i server Asterisk (da qui il senso del nome) e tra server e client che utilizzano lo stesso protocollo (è dunque peer-to-peer). Tuttavia non è affatto limitato a Asterisk: il protocollo è open source per chiunque voglia utilizzarlo ed è supportato da molti altri progetti open source di telecomunicazioni, così come da diversi produttori di hardware. È un protocollo di trasporto (molto simile a SIP) che utilizza una singola porta UDP (la 4569) sia per la trasmissione del segnale che per i flussi multimediali. È stato progettato e ottimizzato per trasportare chiamate multimediali usando IP. L unità di comunicazione di base è il Frame ; ne esistono di diversi tipi: I Full Frame trasportano dati di controllo o di signaling; racchiudono, opzionalmente, Information Element (IE), che descrivono vari tipi di chiamate. I Mini Frame inoltrano flussi di dati multimediali. I Meta Frame sono utilizzati per il call trunking o la trasmissione di stream video. Una chiamata di base consiste di diversi segmenti, ognuno implementato usando diversi protocolli. IAX è responsabile della creazioni di uno o più segmenti di un percorso di chiamata completo. Per instaurare una chiamata, l host A invia un frame NEW all host B, il quale risponde con un messaggio ACCEPT, seguito da un ACK nel senso opposto. Quindi un frame RINGING B informa A che il suo telefono sta squillando. Segue un ACK da A a B. La comunicazione inizia quando B invia un messaggio di ANSWER a cui A risponde con un ACK. A questo punto una sessione full-duplex è instaurata. Lo scambio del frame HANGUP e relativo ACK denota la fine della chiamata. 15

16 Figura 8: Esempio di scambio di pacchetti IAX. IAX, come accennato, ha la peculiarità di effettuare dei trunk di più sessioni in un unico flusso di dati: ciò è un vantaggio enorme per larghezza di banda per l'invio di diversi canali simultanei; infatti il trunking consente di rappresentare con un singolo datagram flussi multipli multimediali, in modo da ridurre il numero degli header e quello dei pacchetti, minimizzando la latenza. Si può utilizzare in due configurazioni: trunk oppure no-trunk; nella prima si ottimizza la segnalazione trasmettendo in un pacchetto IP/UDP i campioni relativi a più canali voce; nella seconda tali canali utilizzano diversi pacchetti IP. Dal momento che IAX è stato ottimizzato per la voce, ha ricevuto qualche critica per non sostenere al meglio i video; in realtà, ha il potenziale di trasmettere praticamente tutti i tipi di stream desiderati. IAX include la possibilità di autenticare in tre modi: testo semplice, MD5 e scambio di chiavi RSA. Ciò, naturalmente, non fa nulla per crittografare il percorso o gli header tra gli endpoint. Molte soluzioni includono l'utilizzo di una rete privata virtuale (VPN) o di software per crittografare il flusso. Tuttavia, IAX è anche in grado di cifrare i flussi tra endpoint con scambio di chiavi dinamico al setup della chiamata. Figura 9: Trunk IAX2. In realtà, il protocollo originale è diventato obsoleto ed è stato disapprovato in funzione di IAX2. Quest ultimo è stato volutamente progettato per funzionare dietro una rete con NAT. 16

17 L'uso di una singola porta UDP sia per la segnalazione che per la trasmissione mantiene il numero di passaggi necessari nel firewall al minimo. Queste considerazioni hanno contribuito a rendere IAX uno dei protocolli più semplici da attuare in reti sicure. Protocollo SIP (Session Initial Protocol) È un protocollo di controllo del livello applicativo utilizzato per gestire sessioni tra uno o più utenti. Ha di fatto sostituito il protocollo H.323, diventando una prima scelta come protocollo VoIP. Si tratta di un protocollo relativamente semplice, con una sintassi simile a quella di altri protocolli come HTTP e SMTP. In accordo a SIP, ogni estremità di una connessione è un peer. SIP è stato originariamente presentato alla Internet Engineering Task Force (IETF) nel mese di febbraio del Il progetto iniziale era completamente diverso da come è oggi, e conteneva un solo tipo di richiesta: il setup della chiamata. Nel marzo del 1999, dopo 11 revisioni, SIP RFC 2543 è stato finalmente diffuso. In un primo momento, SIP è stato quasi ignorato, data la rilevanza di H.323. Gran parte del merito della crescita della sua popolarità è dovuto alla sua specifica open source. SIP è un protocollo di application-layer che utilizza la porta nota 5060 per la comunicazione. Si può appoggiare sui protocolli del livello di trasporto UDP o TCP. Asterisk non dispone attualmente di un implementazione di TCP per il trasporto di messaggi SIP; è tuttavia possibile che le future versioni lo supporteranno. SIP è usato per creare, modificare e terminare sessioni multimediali come le chiamate di telefonia via Internet. Non fornisce dei servizi, ma delle primitive per implementarli; ad esempio, per la comunicazione trasparente in real-time si può usare il protocollo RTP, mentre per il controllo della consegna di dati in streaming il protocollo RTSP. Una topologia comune per illustrare SIP e RTP è comunemente indicata come "trapezio SIP": quando A vuole chiamare B, il suo telefono contatta il proprio proxy server, che a sua volta cerca di trovare B (spesso connettendosi attraverso il proxy di quest ultimo). Quando la chiamata ha inizio, i dispositivi comunicano direttamente tra loro, in modo da non dover esaurire le risorse del proxy. Figura 10: Trapezio SIP. Un messaggio SIP può essere una REQUEST o una RESPONSE. Una sequenza costituita da una richiesta e una o più risposte è definita transazione, ciascuna distinguibile attraverso un identificativo che specifica sorgente, destinazione e sequence number. Gli utenti, invece, sono localizzabili tramite URI, le quali contengono le informazioni necessarie per poterli raggiungere. Le componenti principali per il funzionamento sono: SIP User Agent (UA): dispositivo che accetta o richiede una comunicazione, fungendo da client o da server in maniera dinamica (può cambiare il proprio ruolo nel corso della sessione). User Agent Client (UAC): crea una nuova richiesta e la inoltra. User Agent Server (UAS): genera una risposta ad una richiesta SIP. 17

18 SIP Server: accetta e risponde a richieste SIP fornendo agli UA servizi di diversa natura. Figura 11: Rete SIP. Più in dettaglio, un utente (Alice) usa un applicazione SIP per chiamarne un altro (Bob) attraverso la rete. I proxy sono utilizzati per facilitare la costruzione della sessione. Entrambi hanno una SIP URI per definire la propria identità; tali URI hanno un aspetto simile a quello di un indirizzo , con username, host name e dominio. La transazione inizia con l invio, da parte di Alice, di un INVITE alla SIP URI di Bob; questo contiene anche un numero che determina i campi dell header (che fornisce informazioni addizionali ad un messaggio). Figura 12: Setup di una sessione SIP. 18

19 Figura 13: Esempio di messaggio INVITE. Tra i campi più interessanti: Via contiene l indirizzo a cui Alice aspetta le risposte ( branch identifica la transazione). To è l URI del destinatario. From identifica chi ha inviato la richiesta. Call-ID è un identificatore unico della chiamata. Il corpo di un messaggio SIP contiene la descrizione della sessione, codificata in formati di altri protocolli, come, ad esempio, SDP (Session Description Protocol). Dal momento che il softphone non conosce la posizione di Bob o del SIP server, l INVITE è girato al proxy server del dominio di Alice. In questo esempio, il server proxy riceve l INVITE e invia una risposta Trying, la quale indica che lo stesso sta lavorando per instradare il messaggio. Quindi individua il proxy server all altro estremo della comunicazione, eventualmente con un particolare tipo di ricerca DNS per trovarlo. Prima di inoltrare la richiesta, aggiunge un altro campo Via che contiene il suo indirizzo. Il server biloxi.com risponde con un Trying indicando che instraderà a sua volta il messaggio, consultando il database location service per individuare l indirizzo di Bob. Il telefono SIP di quest ultimo riceve l'invito e lo avverte della chiamata in arrivo. La risposta di Bob è Ringing, perché effettuerà il cammino nella direzione opposta attraversando i due proxy. Bob decide anche di rispondere e invia la risposta 200 ( OK ), che conterrà la descrizione del tipo di sessione che si aspetta di stabilire. Figura 14: Esempio di risposta 200. Al termine della chiamata, Bob si disconnette e genera un messaggio BYE. Alice ne conferma la ricezione con un messaggio OK. Il tipo di attacco più comune su comunicazioni VoIP è il Denial of Service (DoS): può verificarsi quando un gran numero di invalide richieste INVITE vengono inviate a un server proxy nel tentativo di confondere il sistema. Questi attacchi sono relativamente semplici da implementare e i loro effetti sugli utenti del 19

20 sistema sono immediati. SIP ha diversi metodi per ridurre al minimo gli effetti degli attacchi DoS; tuttavia, questi sono spesso impossibili da prevenire. SIP garantisce che un meccanismo di trasporto sicuro e criptato (vale a dire Transport Layer Security, o TLS) venga utilizzato per stabilire la comunicazione tra il chiamante e il dominio del chiamato. Oltre a ciò, la richiesta viene inviata in modo sicuro al dispositivo sulla base dei criteri di protezione locali della rete. La crittografia del media, ovvero del flusso RTP, deve invece essere trattata separatamente. Tipologie di pacchetti Per le richieste SIP, la RFC 3261 definisce i seguenti metodi: REGISTER: usato da un UA per registrarsi. INVITE: usato per stabilire una sessione tra UA. ACK: conferma l avvenuto scambio di messaggio. CANCEL: termina una richiesta in sospeso. BYE: termina una sessione esistente. OPTIONS: è una richiesta di informazioni circa le capacità di un UA senza la necessità di creare una sessione. REFER: indica che il destinatario, identificato dalla Request-URI, deve contattare una terza parte usando le informazioni del contatto fornite. PRACK: è un nuovo metodo introdotto nella RFC 3262; migliora l affidabilità della rete aggiungendo un sistema di acknowledgement alle risposte 1xx. Di seguito sono invece definite le risposte: Provisional (1xx): la richiesta è stata ricevuta ed è in fase di esecuzione. Success (2xx): la richiesta è stata ricevuta, interpretata e accettata con successo. Redirection (3xx): indica che devono essere compiute ulteriori azioni (tipicamente dal mittente) per completare la richiesta. Client Error (4xx): la richiesta contiene una sintassi errata o non può essere realizzata dal server. Server Error (5xx): il server non può adempiere ad una richiesta apparentemente valida. Global Failure (6xx): la richiesta non può essere realizzata da qualsiasi server. Registrazione SIP Di seguito viene descritto il metodo di registrazione che utilizza SIP; tale sezione sarà particolarmente utile per la descrizione del funzionamento del progetto. La registrazione lega la particolare Contact URI del dispositivo ad un contatto con un AOR (Address Of Record) di un utente SIP. La URI prende il nome di: contact-address (indirizzo reale): se permette di ricostruire gli indirizzi di trasporto dell entità SIP. address-of-record (indirizzo pubblico): se permette di ricostruire gli indirizzi di trasporto di un server in grado di localizzare l entità SIP. Sono URI che puntano ad un dominio con un location service che può mappare l'uri ad un'altra dove l'utente sembra essere disponibile (per questo indirizzo pubblico). 20

21 Figura 15: Esempio di REGISTER. Bob invia una richiesta SIP REGISTER al server SIP. La richiesta comprende la lista dei contatti dell'utente. Il flusso mostra l'uso di HTTP Digest 8 per l'autenticazione usando il trasporto TLS; quest ultimo è utilizzato a causa della mancanza di protezione dell'integrità in HTTP Digest e il pericolo di hijacking della registrazione senza di essa. Tuttavia, Bob ha richiesto una pagina che ha bisogno di autenticazione. Nel caso specifico, ha semplicemente digitato l indirizzo desiderato, senza fornire username o password. Quindi, il server SIP nega l accesso e determina una sfida per Bob. Bob inserisce ID utente e password, entrambi validi. Il client SIP di Bob codifica le informazioni dell'utente secondo la sfida lanciata dal server SIP e invia la risposta al server. Il server convalida le credenziali dell'utente; quindi lo registra nel suo database di contatti e restituisce una risposta (200 OK) al client SIP di Bob. Quest ultima include la lista dei contatti dell'utente. Il formato dell'autenticazione mostrata è HTTP Digest. Si presume che Bob non si sia precedentemente registrato a questo server. Figura 16: Registrazione server SIP - Primo passaggio. 8 Digest access authentication è un metodo concordato che un web server usa per negoziare le credenziali di un utente che utilizza un browser; in particolare, viene applicata una funzione hash alla password prima di inviarla sulla rete. 21

22 Figura 17: Registrazione server SIP - Secondo passaggio. Ritornando al secondo passaggio, il server sfida l utente con un realm (o protection domain ) e un nonce ; se l utente ha un username in questo protection domain, allora calcola la risposta basata su diverse informazioni, incluso il segreto. Il realm è una stringa che indica il dominio di protezione a cui si cerca di accedere; serve solo per ricordare all utente quale username deve usare in quel dominio. Il nonce, invece, serve a calcolare la Digest Authentication Response. Figura 18: Registrazione server SIP - Terzo passaggio. Figura 19: Registrazione server SIP - Quarto passaggio. 22

23 Protocollo H.323 È un protocollo creato nel 1996 dallo ITU (International Telecommunication Union), originariamente progettato per fornire un meccanismo di trasporto IP per videoconferenze. Oggi è in gran parte deprecato a favore di IAX e SIP. È stato progettato come un mezzo per trasmettere voce, video, dati e fax attraverso una rete basata su IP mantenendo la connettività con la rete PSTN; dunque, in reti non orientate alla connessione e dove non è garantita la Quality of Service. Dall anno della sua ideazione è passato attraverso diverse versioni che aggiungono funzionalità al protocollo, permettendo così di operare in reti VoIP e reti ampiamente distribuite. Uno dei fattori che ha reso impopolare H.323 è la sua complessità, anche se molti sostengono che il SIP, inizialmente celebre per la sua semplicità, sta iniziando a soffrire dello stesso problema. Tuttavia, trasporta ancora la maggior parte del traffico VoIP. In realtà comprende a sua volta una serie di protocolli; tra i più importanti, H Registration, Admission e Status (RAS): è utilizzato tra un endpoint H.323 e un gatekeeper per risoluzione dell indirizzo e servizi di controllo. H Call Signaling: permette di stabilire una comunicazione tra due entità H.323. H.245: è un protocollo di controllo per comunicazioni multimediali; descrive una serie di procedure per la trasmissione. Real-time Transport Protocol (RTP): è utilizzato per inviare o ricevere informazioni multimediali (voce, video, testo) tra due dispositivi. I componenti fondamentali di un sistema H.323 sono: I terminali: sono endpoint interconnessi alla rete che offrono diverse funzionalità, come controllo del sistema, formattazione dei flussi di dati, codifica. Permettono la comunicazione in maniera bidirezionale real-time. I gateway: sono dispositivi situati al confine tra la rete H.323 ed un'altra rete che traducono i vari formati di trasmissione audio, video e dati. Un gatekeeper: dirige un gruppo di dispositivi H.323 e traduce i loro indirizzi in indirizzi IP. Fornisce un metodo di autenticazione delle precedenti componenti, gestisce la banda e esegue il routing delle chiamate. MCU (Multipoint Control Unit): si tratta del sistema che permette di estendere la trasmissione da punto-punto a multi-punto. È suddiviso in: o MC (Multipoint Controller), che gestisce il controllo della comunicazione. o MP (Multipoint Processor), che effettua l elaborazione dei flussi. 23

24 Figura 20: Architettura e componenti di una rete H.323. H.323 è un protocollo relativamente sicuro e non richiede molte considerazioni sulla sicurezza, oltre a quelle comuni a qualsiasi rete di comunicazione con Internet. Dal momento in cui è stato integrato il protocollo RTP per le comunicazioni multimediali è stato fatto senza criptare il traffico. L'uso di una VPN o di altri tunnel crittografati tra endpoint è la scelta comune di incapsulare in modo sicuro le comunicazioni. Naturalmente, ciò ha lo svantaggio di richiedere la costruzione di tali tunnel, che può non essere sempre conveniente (o possibile). Se esistono diversi utenti schermati dal NAT, è necessario usare un gatekeeper in modalità proxy. Il gatekeeper richiede un'interfaccia collegata alla sottorete privata e Internet. Il client H.323 sulla rete privata deve registrarsi al gatekeeper, il quale delega le chiamate per suo conto. Si noti che i client esterni che desiderano chiamare dovranno registrarsi presso il server proxy. Asterisk non può agire come un gatekeeper H.323. Occorre utilizzare un applicazione separata, come, ad esempio, OpenH323 Gatekeeper. Protocollo MGCP (Media Gateway Control Protocol) Il Media Gateway Control Protocol è un implementazione dell omonima architettura per controllare i gateway dei dati su reti IP connessi alla PSTN. Un media gateway è un elemento di una rete che fornisce una conversione tra i segnali audio su circuiti telefonici e i pacchetti di dati trasmessi su Internet. MGCP presuppone un'architettura di controllo delle chiamate in cui quest ultima è al di fuori dei gateway e gestita da elementi di una chiamata esterna noti come Call Agent. Il funzionamento implica che questi si sincronizzino per inviare comandi coerenti e risposte ai gateway sotto il loro controllo. MGCP non definisce un meccanismo per la sincronizzazione dei Call Agent. A differenza di SIP, MGCP utilizza un modello centralizzato. I telefoni non possono chiamare direttamente altri telefoni MGCP, ma devono passare attraverso i Call Agent. 24

25 Protocollo RTP (Real-time Transport Protocol) RTP è un protocollo di rete che fornisce funzioni di trasporto end-to-end, adatte per applicazioni che trasmettono dati real-time, come audio e video. È spesso utilizzato con un protocollo di segnalazione come SIP. Tra i vari compiti: Identificazione. Sequence numbering. Monitoraggio della consegna. Supporta il trasferimento dati verso destinazioni multiple, offrendo multicasting se fornito dalla rete sottostante. Tuttavia, non fornisce alcun meccanismo per assicurare una tempestiva consegna o garanzie di QoS, ma si affida sui servizi di livello inferiore per farlo; non assume che la sottostante rete sia affidabile e non garantisce che i pacchetti siano in sequenza. Solo attraverso la numerazione dei pacchetti il ricevitore può ricostruire l ordine. Poiché TCP predilige l affidabilità alla tempestività, la maggior parte delle implementazioni RTP sono costruite su UDP. È costituito dal protocollo RTCP (RTP Control Protocol), che ha i compiti di: Monitoraggio della consegna dei dati in maniera scalabile per grandi reti. Identificazione. Sincronizzazione dei flussi. Funzioni di controllo. La parte di trasporto dati, invece, fornisce il controllo di tutte le proprietà real-time della consegna, inclusa la ricostruzione temporale dei pacchetti. Una sessione RTP viene stabilita per ciascun flusso multimediale. Essa consiste di un indirizzo IP con due porte, una per RTP e una per RTCP; ad esempio, gli stream audio e video usano sessioni separate. Tra le possibili applicazioni, le più importanti sono conferenza audio multicast, o audio e video. Nella prima, ogni partecipante invia dei flussi audio in piccoli chunk, ognuno dei quali incapsulato in un pacchetto RTP. Tale pacchetto è composto da un header e dei dati; nell header viene stabilito il tipo di codifica audio, che può essere modificata da ogni partecipante, in modo da essere adeguato alla banda disponibile. Per sopperire alla potenziale perdita dei pacchetti e ai ritardi, l header contiene anche delle informazioni temporali e un numero di sequenza che permettono al ricevitore di ricostruire il flusso dati iniziale. 25

26 Capitolo III: Configurazione Asterisk Introduzione La configurazione di Asterisk può risultare un compito abbastanza gravoso; può variare a seconda del funzionamento desiderato del proprio PBX, e soprattutto da quali caratteristiche si desidera rendere disponibili per gli utenti. Asterisk, come molte utility Unix, offre molti file di configurazione interconnessi tra loro, che possono creare confusione se non si dispone di una conoscenza adeguata dell ambiente. File di configurazione Asterisk Entrati nella directory di configurazione, tramite il comando cd /etc/asterisk sono mostrati i file di configurazione. Figura 21: File di configurazione di Asterisk. Alcuni file di configurazione possono essere ignorati se non si dispone di un certo hardware o se non si ha bisogno di attivare alcune funzioni specifiche di Asterisk. 26

27 Nome del file cdr_tds.conf codecs.conf enum.conf extensions.conf features.conf rtp.conf manager.conf queues.conf sip.conf users.conf voic .conf zapata.conf sip_notify.conf Ruolo Impostazioni per l'archiviazione dei CDR in una Database FreeTDS Impostazioni dei codec Numeri di telefono, connessioni e impostazioni Impostazioni del dialplan Impostazioni per il controllo delle chiamate Impostazioni del Real-Time-Protocol Impostazioni per l'interfaccia di gestione Asterisk Impostazioni per le code di chiamata Impostazioni e le connessioni SIP Impostazioni per una facile manutenzione da parte dell utente Impostazioni di posta vocale e dettagli della mail postale Impostazioni per l hardware Zapata Impostazioni per le notifiche Figura 22: Alcuni file di configurazione e relative caratteristiche. Configurazione Connessione Sip SIP è il protocollo VoIP più utilizzato oggi. Si tratta di uno standard ufficiale Internet ed è supportato da quasi tutti i dispositivi VoIP. Il file sip.conf di Asterisk contiene: La configurazione per il driver del canale chan_sip.so che permette la generazione dei canali SIP. Le informazioni sui dispositivi telefonici (nome, password, contesto ecc). Le informazioni sul driver di canale sono contenute in cima al file nella sezione [general]; essa comprende le informazioni di default per la configurazione dei dispositivi, che possono essere sovrascritte dalla sezione [template]. Lo scopo principale di questo file è quello di registrare un interno sul server; quindi Asterisk gestirà tutti gli interni contenuti in questo file. Ad ogni telefono è associato un contesto che si trova nel file extensions.conf (o dialplan); tale contesto determina le istruzioni che un determinato interno dovrà eseguire quando accadono particolari eventi, come, ad esempio, quando su un telefono si digita il numero 101. Figura 23: Rappresentazione del collegamento tra i file sip.conf e extensions.conf. 27

28 La figura7 mostra il telefono ooooffffooo1 con contesto uguale a LocalSets ; l utente digita sulla tastiera 101; quindi il server Asterisk nel file sip.conf individua il telefono che ha compiuto l azione e accede al suo contesto, presente nel file extensions.conf, per eseguire le relative istruzione. Nell esempio viene chiamato l interno ooooffffooo2 utilizzando l applicazione dial. Esempio di sip.conf [general] context=unauthenticated allowguest=no udpbindaddr= tcpenable=no [office-phone] type=friend context= LocalSets host=dynamic nat=yes secret=cl#ass2013 dtmfmode=auto disallow=all allow=ulaw allow=alaw L esempio mostra la registrazione di due interni, il 200 e il 201. Nella sezione [general] sono presenti i settaggi generali validi per tutti gli interni registrati: context=unauthenticated : indica il contesto di default, in cui si trovano i telefoni non registrati sul centralino o i telefoni registrati nei quali non viene specificato un contesto. allowguest=no : non permette a chiamanti anonimi di effettuare chiamate ad Asterisk. udpbindaddr= : indica che il centralino è in ascolto su tutte le interfacce di rete. tcpenable=no : disabilita il protocollo TCP e permette l utilizzo di quello UDP. Nella sezione [office-phone] vengono inserite le caratteristiche da associare a determinati interni: type=friend : il telefono può ricevere ed effettuare chiamate. context=localsets : indica che le istruzioni da seguire quando il telefono compie una determinata azione si trovano nel contesto LocalSets del dialplan. host=dynamic : si accettano connessioni da qualsiasi dispositivo con un qualsiasi IP. nat=yes : permette ad un utente connesso in un'altra rete di comunicare con un interno del centralino. secret=cl@ss2012 : indica la password associata al telefono. dtmfmode=auto : permette la gestione dei toni di chiamata. disallow=all : disabilita tutti i codec audio usati. allow=ulaw : abilita il codec ulaw. allow=alaw : abilita il codec alaw. Da notare che queste istruzioni non sono associate ancora a nessun dispositivo; per associarle c è bisogno di inserirle in questo modo: [200](office-phone) [201](office-phone) Questo tipo di associazione è utile quando i telefoni hanno delle caratteristiche in comune; invece se hanno anche proprietà diverse tra loro c è bisogno di inserirle dopo il nome dell interno. 28

29 [200](office-phone) Context=LocalSets1 [201](office-phone) Context=LocalSets2 Nell ultimo passaggio si suppone che in [office-phone] non venga specificato il contesto perché risulta diverso per i due telefoni. Configurazione Dialplan Il dialplan (ovvero "piano di chiamata") è la parte più interessante della configurazione di Asterisk: è l entità che instrada ogni chiamata nel sistema, dal mittente al destinatario finale, passando per le varie applicazioni. Esso è composto da un gruppo (generalmente connesso) di contesti che contengono una serie di estensioni, ovvero istruzioni. I contesti suddividono il dialplan in varie parti che possono interagire tra di loro. Per definirne uno occorre inserire il nome tra parentesi quadre. Tutte le istruzioni inserite dopo la definizione di un contesto fanno parte di esso, fino alla definizione del contesto successivo. All interno del dialplan è presente un primo contesto general che specifica le impostazioni dell intero piano di chiamata. Le estensioni sono istruzioni definite all interno dei contesti e specificano cosa succede alle chiamate nel loro percorso attraverso il dialplan. La sintassi utilizzata per le estensioni è exten => seguita di regola da tre componenti: Il nome dell estensione. La priorità (ogni estensione può includere vari step ; il numero di step è appunto la priorità). L applicazione, che mette in atto qualche azione sulla chiamata. Un contesto si presenta dunque in questo modo: [from-internal] exten => 999,1,Applicazione1 exten => 999,2,Applicazione2 exten => 999,3,Applicazione3 Dal momento, però, che è generalmente più comodo listare in sequenza le estensioni che si intende utilizzare in risposta ad un evento, Asterisk introduce anche la priorità speciale n, che indica "usa la prossima priorità disponibile"; tale priorità è fondamentale nel caso in cui c è bisogno di apportare modifiche (eliminazione o spostamento di un estensione) perché evita la riconfigurazione di tutte le priorità del contesto. Quindi in modo analogo il precedente dialplan può anche essere scritto come: [from-internal] exten => 999,1,Applicazione1 exten => 999,n,Applicazione2 exten => 999,n,Applicazione3 Come risulta chiaro dall'esempio, l'unico requisito della priorità n è quello di avere una priorità precedente da cui partire. È inoltre necessario, per ogni estensione definita, fare in modo che il punto d'inizio sia la priorità 1. Grazie al file extensions.conf, Asterisk è programmabile. È possibile analizzare il precedente contesto e notare che in effetti non è altro che una macchina a stati finiti, la quale possiede uno stato e, in risposta a determinati input, può restare nel suo attuale stato o muoversi in uno nuovo. 29

30 Figura 24: Rappresentazione grafica del dialplan. A questo punto, il file extensions.conf può essere visto come un insieme di macchine a stati finiti: ogni insieme è un contesto in cui ci si può muovere. Diversi canali di comunicazione possono essere assegnati a diversi contesti, così come diversi utenti all'interno dello stesso canale possono avere o non avere accesso a determinate aree del dialplan. Ecco un esempio di extensions.conf più completo: [general] static = yes writeprotect = yes [localsets] exten => 500,1,Answer() exten => 500,n,Playback(demo-echotest) exten => 500,n,Echo() exten => 500,n,Playback(demo-thanks) exten => 500,n,Hangup() La sezione [general], in questo caso, specifica che il file è statico e protetto dalla scrittura, in modo che non venga modificato dinamicamente nel corso dell'esecuzione di Asterisk (ad esempio, tramite il comando "savedialplan"). La seconda sezione, [localsets], è quella a cui appartengono i due utenti SIP definiti in precedenza, e contiene un estensione che è possibile chiamare, la 500. Il suo funzionamento è abbastanza intuitivo; infatti, si limita ad eseguire in cascata le seguenti operazioni: Rispondi alla chiamata. Riproduci un suono di benvenuto che avvisa sull'imminente inizio del test dell'eco. Avvia il test dell'eco finché non viene digitato il cancelletto (ripete ciò che viene pronunciato). Al termine del testo, riproduci un suono che saluta l'utente. Riaggancia. Ci sono due particolari da notare in questo esempio: il primo è l'utilizzo di argomenti per l'applicazione Playback (nel caso specifico, nomi di file) e la loro assenza per le altre applicazioni (se non sono necessari parametri, è possibile non scrivere le parentesi dopo il nome dell'applicazione); il secondo è che tutte le applicazioni di questo dialplan eseguono un operazione e terminano immediatamente la loro esecuzione: l'applicazione echo in ciò differisce poiché prende il possesso del canale aperto finché la comunicazione non viene interrotta (o normalmente, con l'uscita dell'applicazione in seguito alla pressione del cancelletto, o con il riaggancio del ricevitore da parte del chiamante). 30

31 Figura 25: Rappresentazione del dialplan tramite automa. Ogni qualvolta vengono applicate modifiche al file extensions.conf c è bisogno di utilizzare il comando dialplan reload per rendere definitive le modifiche. Figura 26: Dialplan reload. Configurazione Manager.conf Asterisk Manager consente ad un programma client di connettersi ad una istanza Asterisk e di impartire comandi o rilevare eventi del PBX su una connessione TCP/IP. Gli sviluppatori possono basare su questa interfaccia diversi tipi di applicazione, da quelle relative al monitoraggio dello stato delle chiamate, ad applicazioni CRM basate sul click-to-call. La comunicazione tra client e server Asterisk, attraverso l'interfaccia manager, avviene tramite un semplice protocollo testuale di tipo request/response basato su linee strutturate come "chiave: valore". Il protocollo ha le seguenti caratteristiche: E' necessario, prima di tutto, stabilire una sessione. I messaggi possono essere trasmessi in ciascuna direzione in qualsiasi momento una volta avvenuta l'autenticazione. La prima linea di un messaggio contiene una chiave "Action" quando inviata dal client, una chiave "Event" o "Response" quando inviata invece da Asterisk. L'ordine delle linee all'interno di un messaggio è irrilevante. Tipi di messaggio Il tipo di un messaggio viene determinato dalla presenza di una delle chiavi appena citate: Action: Un messaggio inviato dal client ad Asterisk, con la richiesta che venga effettuata una particolare azione. Esiste un certo (estendibile) set di azioni a disposizione del client, determinato dai moduli attualmente caricati nell'engine Asterisk. Solo un azione alla volta può essere invocata. Il messaggio Action contiene il nome della operazione da attuarsi con tutti i parametri necessari. Tali messaggi costituiscono le API dell'interfaccia manager. Response: La risposta inviata da Asterisk relativamente al messaggio Action inviato dal client. Event: Un messaggio riguardante un evento generato dal nucleo di Asterisk o da un suo modulo. 31

32 In genere il client invia dei messaggi Action al server Asterisk, il quale esegue l operazione e restituisce il risultato (spesso solamente Success oppure Failure) in un messaggio Response. Dal momento che non esiste alcuna garanzia circa l'ordine di ricezione dei messaggi Response, il client di solito include un parametro ActionID in ogni messaggio Action, il quale viene rispedito indietro da Asterisk nel corrispondente messaggio Response. In tal modo il client può facilmente relazionare richieste e risposte continuando ad inviare messaggi Action al ritmo desiderato, senza dover aspettare la risposta del precedente. I messaggi Event vengono usati in due differenti ambiti: da un lato informano i client circa i cambiamenti di stato in Asterisk (come il passaggio di un telefono da disponibile ad occupato), dall'altro sono usati per trasportare il contenuto delle risposte per azioni che restituiscono una lista di dati (azioni che generano eventi). Per accedere all'interfaccia Asterisk Manager un utente necessita di stabilire una sessione con la richiesta di una connessione TCP/IP ad una porta (di solito la 5038) sulla quale l'istanza Asterisk si trova in ascolto, e quindi di autenticarsi tramite la action Login. Ovviamente l utente deve avere un account, precedentemente registrato presso il server Asterisk. Gli account degli utenti sono configurati in /etc/asterisk/manager.conf. Un account consiste in un insieme di host o IP, di una password di autenticazione e di una lista di permessi, compresi in un set determinato, ciascuno definito tramite una capacità di "read", "write", oppure "read/write". Se ad un client viene assicurata la capacità di leggere una determinata classe, Asterisk gli notificherà gli eventi relativi a tale classe. Se ad un client viene assicurata la capacità di scrivere una data classe, potrà inviare messaggi Action di tale classe. Viene dunque mostrato un semplice esempio di manager.conf: [general] port= 5038 binaddr= [admin] secret=art222 deny= / permit= / permit= / read = system,call,log,verbose,command,agent,user,config,command,dtmf,reporting,cdr,dialplan,originate write = system,call,log,verbose,command,agent,user,config,command,dtmf,reporting,cdr,dialplan,originate Il codice mostrato rappresenta un generico file manager.conf, la cui struttura presenta una sezione [general] dove sono indicati la porta sulla quale l istanza di Asterisk è in ascolto e la proprietà bindaddr, la quale stabilisce che il server è in ascolto su tutte le interfacce di rete. La sezione [admin] contiene invece le credenziali e i permessi per collegarsi al manager. Le proprietà descritte sono: secret=art22 : rappresenta la password per connettersi al manager. deny= / : impedisce a tutte le reti di connettersi al manager. permit= / : indica l intervallo di rete accettato per la connessione. permit= / : stabilisce l intervallo di rete accettato per la connessione. read= : determina i permessi concessi in lettura. write= : assegna i permessi in scrittura. Infine il nome utente per collegarsi al manager è admin, ovvero il nome della sezione. Il file manager.conf può contenere anche altre sezioni che indicano altre alternative di connessione al manager, dove si possono specificare ad esempio restrizioni di lettura o scrittura per determinati utenti. 32

33 Libreria Asterisk-Java La libreria Asterisk-Java consente di comunicare con il Manager di Asterisk. E una libreria Java che permette di ricevere eventi per avere informazioni sugli interni registrati ed anche informazioni sul sistema Asterisk. Esempi di eventi sono: ExtensionStatusEvent : inviato dal server ogni qualvolta lo stato di un telefono cambia. BridgeEvent : inviato dal server quando si è stabilita una chiamata. DialEvent : inviato dal server quando si avvia una chiamata, ma i telefoni non sono ancora in comunicazione. HangupEvent : inviato dal server quando termina una chiamata. Oltre a ricevere eventi, con questa libreria è anche possibile invocare azioni sul server: ad esempio, far terminare una chiamata o ricevere lo stato dei telefoni in un determinato momento. Connessione al Manager e comunicazione con Asterisk Figura 27: ManagerConnectionFactory. La classe ManagerConnectionFactory permette di ottenere nuove ManagerConnections. Essa crea nuove connessioni in stato INITIAL ; prima di poter utilizzare tali connessioni occorre chiamare il metodo login() con ManagerConnection.login() ; tale metodo prende in input quattro parametri fondamentali: L indirizzo IP generato dal server Asterisk. Il numero di porta dove è in ascolto il server. L username e la password inseriti nel file manager.conf. Se i dati sono stati inseriti correttamente lo stato del managerconnection diventerà CONNECTED. Infine, per essere aggiornati in tempo reale sugli eventi del centralino Asterisk, è necessario implementare un ManagerEventListener che intercetta gli eventi ricevuti nel metodo onmanagerevent(). Tale metodo intercetta vari tipi di eventi sui quali dovrà essere effettuato un cast opportuno in base al tipo. Una volta definito quanto descritto sarà possibile ricevere eventi e inviare azioni al server. Figura 28: Metodo onmanagerevent. 33

34 Il parametro ManagerEvent, opportunamente utilizzato, permette di catturare l evento interessato. È anche possibile estrapolare informazioni relative all evento. La stessa figura mostra infatti l intercettazione dell evento ExtensionStatus. I metodi getexten() e getstatus() permettono di ottenere il numero dell interno che ha subito il cambiamento di stato e il nuovo stato in cui si trova. Il metodo getstatus() può restituire: 0 se il telefono si trova in uno stato disponibile. 1 se il telefono è in uno stato occupato. 8 se il telefono sta squillando. 4 se il telefono non è connesso. Oltre ad intercettare eventi, come ExtensionStatusEvent, è anche possibile eseguire azioni su Asterisk, ad esempio effettuare una telefonata. Figura 29: Effettuare una chiamata. L esempio mostra come effettuare una telefonata verso l interno 300 utilizzando la classe Originate. Il metodo setchannel() specifica il canale del mittente (in questo caso l interno 200) mente setexten() specifica il numero del destinatario. Con il metodo setcontext() viene specificato il contesto da prendere come riferimento. Modulo Voice Mail La voic ha giocato un ruolo chiave nel business degli ultimi venti anni: infatti, è spesso considerata più importante delle . I settaggi del voic vengono riportati all interno del file voic .conf, che si trova nella directory di configurazione di Asterisk. Configurazione Setting Voice Mail Esistono vari tipi di settaggi che possono essere configurati in una voice mail, come: Time zone. Voice mail. . Esistono anche opzioni che permettono di personalizzare il formato dell orario. Escluso il caso in cui la richiesta di personalizzazione sia troppo pretenziosa, la maggior parte dei settaggi risultano efficaci per soddisfare tutti i tipi di richiesta. Un opzione abbastanza comune che necessita molto frequentemente di essere settata in tale ambito è il maxmsg, che definisce il numero massimo di messaggi che un utente può avere nella propria voic box. Un altra opzione rilevante è la tz, che controlla la time zone dei relativi messaggi salvati nella propria mailbox. Ciò è comunemente usato se le time zone dei vari server sono differenti rispetto alla time zone della compagnia proprietaria dei server. L opzione tz di default può essere settata solamente nella specifica sezione [zonemessages], che di default assume il valore seguente: 34

35 [zonemessages] eastern=mamerica/new_york 'vm-received' Q 'digits/at' IMp central=america/chicago 'vm-received' Q 'digits/at' IMp central24=america/chicago 'vm-received' q 'digits/at' H N 'hours' military=zulu 'vm-received' q 'digits/at' H N 'hours' 'phonetic/z_p' european=europe/copenhagen 'vm-received' a d b 'digits/at' HM La sintassi che viene seguita per tale opzione è: ZONENAME = TIMEZONE DATESTRING L assegnazione prevede tre parametri: ZONENAME è il nome che si vuole dare al settaggio. TIMEZONE è la time-zone di Linux che il sistema deve utilizzare per il settaggio. DATESTRING è una stringa che definisce le variabili della data e i file musicali di Unix. Non è sintatticamente la soluzione più elegante, ma risulta molto personalizzabile. Se ad esempio si vuole aggiungere la time-zone del Pacifico, occorre inserire la seguente riga: pacific=america/los_angeles 'vm-received' Q 'digits/at' Imp Tale riga crea una pacific-zone basata sulla time-zone dell America/Los Angeles. Configurazione Mailbox Le Mailbox vengono configurate nella sezione [default]. Una mailbox tipica per un ipotetico utente potrebbe essere qualcosa di simile a questo: 867 => 5309, Steve Example,steve@example.net Tale riga setta una mailbox 867 per Steve Example, con password Ogni messaggio vocale lasciato nella mailbox sarà allegato a un inviata a steve@example.net, permettendo l ascolto del messaggio senza doversi connettere direttamente al server. Sebbene questa impostazione è adattabile a molti utenti, esistono anche molte opzioni associabili alle mailbox. Asterisk offre la possibilità di inviare un secondo messaggio senza l allegato, che è molto utile per i messaggi testuali, o nelle per smartphone. Di seguito è mostrato un esempio: 867 => 5309, Steve Example,steve@example.net, @defuniactelephone.com Questo risulta davvero utile in quanto permettere all utente di ricevere una notifica sul proprio dispositivo mobile riguardo i messaggi della voic senza dover scaricare file audio molto grandi. Tale applicazione risulta utile nel momento in cui la connessione a disposizione del dispositivo mobile è abbastanza lenta. Inoltre esiste la possibilità di specificare dei settaggi specifici per gli utenti: se ad esempio Steve non ha un cellulare, e non vuole ricevere il messaggio vocale sulla sua , ma bensì soltanto una notifica, può utilizzare l opzione attach. 867 => 5309,Steve Example,steve@example.net,, attach=no E da notare in tale riga lo spazio vuoto relativo al campo pager in quanto Steve non ha esigenza di una notifica sul suo cellulare. E possibile inoltre definire più opzioni separandole dal carattere pipe. Se ad esempio Steve vuole ricevere il messaggio vocale con un tempo relativo a quello della Central time-zone, è possibile scrivere qualcosa di simile: 867 => 5309,Steve Example,steve@example.net,, attach=no tz=central 35

36 Si può dunque creare una specifica mailbox per ogni tipo di utente, in base alle esigenze di ognuno. Lasciare e recuperare messaggi Tutte le funzionalità della voic sono espletate mediante due applicazioni di Asterisk: Voic () che gestisce la funzionalità che permettono all utente di poter lasciare messaggi in una casella vocale, e Voic Main() che consente a un utente di un PBX di accedere alla propria casella voice mail, e quindi ascoltare i messaggi vocali in entrata. Di seguito un esempio di dialplan dove è presente l utilizzo di tali applicazioni: [default] exten=>s,1,answer() exten=>s,2,background(thank-you-for-calling-conglomocorp) exten=>s,3,background(conglomocorp-mainmenu) exten=>100,1,voic (u100) exten=>200,1,voic (b200) exten=>300,1,voic main() exten=>400,1,voic main(${callerid(num)}) Questo esempio ha 4 differenti estensioni per la voic L estensione 100 invia la propria voce e la lascia come messaggio alla mailbox 100. La "u" prima del numero di mailbox indica ad Asterisk di usare un saluto che notifichi al mittente la non disponibilità del destinatario. L estensione 200 ha una funzione simile, eccetto che per la "b" che precede il numero della mailbox, che suggerisce ad Asterisk di usare un saluto che dica al mittente che il destinatario è momentaneamente occupato. Entrambe prendono il messaggio vocale generato e lo inoltrano alla casella definita in fase di configurazione (voic .conf). L estensione 300 invece ridirige l utente al sistema di voic del centralino, assumendo che l utente che digiti 300 sia del sistema. In tale caso, scriverà il proprio numero di mailbox e la password definiti nel file di configurazione, in maniera tale da essere abilitato ad ascoltare i suoi messaggi presenti nella mailbox personale. L estensione 400 ha lo stesso compito, ma ridirige direttamente alla casella vocale relativa al CALLERID-NUMBER. In tale caso occorrerà digitare soltanto la password. Muoversi all interno del sistema è come navigare in un normale sistema di voice mail. La chiave di default 1 è per ascoltare il messaggio, 6 per passare al messaggio successivo, 4 per tornare al messaggio precedente, e 7 per eliminare il messaggio corrente. Sono previste altre opzioni per inoltrare i messaggi ad altri utenti oppure per salvare il messaggio audio in altre cartelle di Asterisk. Le chiavi per navigare nel sistema di voice mail non sono personalizzabili a meno che non si vuole ricodificare da capo l applicazione voice mail. 36

37 Capitolo IV: Attacchi al PBX Asterisk Introduzione Trasmettere la voce e i dati sullo stesso stream, indipendentemente dai protocolli utilizzati, aumenta gli sforzi da parte degli amministratori di rete. Una conseguenza di questa unione può implicare, nel caso di un attacco, il rischio del funzionamento dell intera rete. Garantire il corretto funzionamento dell'intera infrastruttura VoIP richiede pianificazione, analisi e conoscenze dettagliate sulle specifiche dell implementazione che si sceglie di utilizzare. I livelli generali che possono essere sotto attacco sono: Infrastruttura IP: le vulnerabilità di relativi sistemi non-voip presenti nel sistema possono portare alla compromissione di infrastrutture VoIP. Sistema operativo sottostante: i dispositivi VoIP ereditano le stesse vulnerabilità del firmware o del sistema su cui si poggiano. Configurazione: spesso i dispositivi navigano con una sovrabbondanza di servizi aperti. Il servizi predefiniti in esecuzione sulle porte aperte possono essere esposti ad attacchi DoS, buffer overflow, o bypassing dell'autenticazione. Livello applicativo: tecnologie non perfettamente sviluppate possono essere attaccate per interrompere o manipolare il servizio offerto; è spesso il caso di applicazioni legacy. Attacchi Denial of Service Gli attacchi Denial of Service (DoS) possono colpire qualsiasi rete basata su IP. L impatto di un tale attacco può variare da un lieve degrado alla completa perdita del servizio. Esistono diversi classi di attacchi DoS; un tipo di attacco in cui i pacchetti possono semplicemente inondare la rete da più fonti esterne è chiamato DoS distribuito (o DDoS). Figura 30: Flussi di traffico tra host e server. 37

38 Figura 31: Un DoS distribuito. La seconda grande classe di DoS comprende i casi in cui i dispositivi nella rete interna sono mirati da una quantità enorme di pacchetti, in maniera tale da negare il servizio. Tale distruzione deriva dall esaurimento delle risorse, in primis larghezza di banda e CPU. 38

39 Figura 32: DoS interno. Ad esempio, alcuni telefoni IP andrebbero in stallo qualora ricevessero un pacchetto UDP più grande di byte sulla porta Né i controlli di integrità né la crittografia possono prevenire questi attacchi. Essi sono caratterizzati semplicemente dal volume di pacchetti inviati verso la vittima; non è rilevante per l attacco se tali pacchetti: Sono firmati da un server. Contengono indirizzi IP reali (o contraffatti). Sono cifrati con una chiave fittizia. È difficile fronteggiare attacchi DoS, data la natura del VoIP (è solo un altro servizio di rete IP). I virus e i worm sono inclusi in questa categoria poiché sono spesso fonte di DoS o DDoS a causa dell'aumento del traffico di rete che generano come parte dei loro sforzi per replicarsi e diffondersi. Come è possibile difendersi da tali attacchi? Alcune soluzioni permettono di limitare le conseguenze. Ad esempio, poiché l'autenticazione a più fattori (o strong authentication) è raramente utilizzata in ambienti VoIP, è necessario che i messaggi siano costruiti in maniera fidata; infatti, l elaborazione di messaggi fasulli esaurisce le risorse del server e porta ad un DoS. SIP o H.323 Registration Flooding ne è un esempio. In tal caso, i server di elaborazione dei messaggi possono ridurre questa minaccia specifica, limitando il numero di registrazioni che accetteranno al minuto per un indirizzo particolare (e/o da un indirizzo IP specifico). Un IPS 9 può essere utile nel difendersi da certi tipi di attacchi. Tali dispositivi monitorano il passaggio del traffico, e quando rilevano pacchetti anonimi (sia confrontando con un database di firme di attacco o abbinando i risultati di un algoritmo per rilevare le anomalie) bloccano il traffico sospetto. 9 Un Intrusion Prevention System sono sviluppati impedire ad un programma non autorizzato e malevolo di entrare in esecuzione. 39

40 Inoltre, gli amministratori di sicurezza possono ridurre al minimo le probabilità di DoS garantendo che i telefoni IP e i server siano aggiornati all'ultima versione stabile, poiché, quando un attacco è annunciato da una bugtraq 10, il vendor rapidamente corregge il software incriminato. I sistemi VoIP devono soddisfare requisiti di disponibilità di servizio rigorosi. Di seguito sono riportati alcuni esempi di minacce DoS che possono causare la negazione intera o parziale, impedendo l inoltro della chiamata, scollegando comunicazioni esistenti, ostacolando il collocamento della chiamata effettuata (compresa quella di emergenza), inibendo l'utilizzo dei relativi servizi come la segreteria telefonica. TLS Connection Reset: non è difficile creare un connection reset su una connessione TLS (usata per identificare lo stato della connessione tra terminali VoIP e gateway); occorre semplicemente inviare il giusto pacchetto spazzatura che provocherà l annullamento della connessione. VoIP Packet Replay Attack: si basa su cattura e rinvio di pacchetti VoIP fuori sequenza tra endpoint, creando ritardo nella chiamata in corso. Ne è un esempio il campo SSRC-SSRC di RTP, che sta per Synchronization Source. QoS Modification Attack: determina una modifica dei campi di controllo non specificamente VoIP in pacchetti VoIP tra endpoint per degradare o negare il servizio voce. Ad esempio, se un utente malintenzionato dovesse cambiare il tag 802.1Q VLAN come man-in-the-middle, potrebbe disturbare la qualità del servizio. Subordinando il traffico voce a quello dati si può ritardare la consegna dei pacchetti voce. VoIP Packet Injection: è determinato dall invio di pacchetti contraffatti VoIP agli endpoint, immettendo rumore nella chiamata in corso. Ad esempio, quando viene utilizzato RTP senza autenticazione di pacchetti RTCP (e senza campionamento SSRC), un attacker può inviare pacchetti RTCP in un gruppo multicast, ognuno con un diverso SSRC, che possono aumentare esponenzialmente la dimensione del gruppo. DoS against Supplementary Services: consiste nell attivare un attacco DoS contro altri servizi di rete su cui il servizio VoIP poggia (ad esempio, DHCP, DNS, BOOTP). Per esempio, nelle reti in cui gli endpoint VoIP si basano sugli indirizzi assegnati da DHCP, disabilitare il server DHCP impedisce ad essi di acquisire indirizzamento e informazioni di routing per utilizzare i servizi VoIP. Control Packet Flood: si basa sull inondare i server o gli endpoint con pacchetti di controllo non autorizzati (ad esempio, pacchetti H.323 GRQ, RRQ inviati sulla porta UDP/1719). L'intento di un hacker è di esaurire il dispositivo, il sistema o le risorse di rete. Qualsiasi porta di manutenzione per elaborazione delle chiamate può essere un bersaglio per questo tipo di attacco. Wireless DoS: consiste nella creazione un attacco DoS contro endpoint VoIP wireless inviando frame o 802.1X; questi possono infatti creare disconnessione della rete (come 802,11 Deauthenticate Flood, 802.1X EAP-Failure, WPA MIC Attack). Per esempio, un attacco Message Integrity Code sfrutta una situazione standard per cui un access point dissocia le stazioni quando riceve due frame non validi entro 60 secondi, causando la perdita di la connettività di rete per un minuto. Bogus Message DoS: si basa sull invio ai server VoIP o agli endpoint di pacchetti validi ma contraffatti in grado di provocare la disconnessione della chiamata. Tali attacchi costringono il telefono ad elaborare un messaggio fasullo e a terminare in modo non corretto una connessione, o inducono il chiamante a credere, erroneamente, che la linea del chiamato è occupata. 10 Bugtraq è una electronic mailing list dedicata a discussioni nell ambito della sicurezza informatica. 40

41 Immature Software DoS: softphone palmari e hardphone 11 VoIP di prima generazione sono particolarmente vulnerabili perché non sono stati correttamente analizzati. I call server VoIP e gli IP PBX sono spesso eseguiti anche su piattaforme con noti identificatori CVE 12. Qualsiasi porta amministrativa o di controllo aperta, come HTTP, SNMP, Telnet, o qualsiasi interfaccia vulnerabile (ad esempio, XML o Java) possono diventare una possibilità di attacco. VoIP Protocol Implementation DoS: si basa sull invio agli endpoint di pacchetti non validi per sfruttare una vulnerabilità di implementazione del protocollo VoIP verso un attacco DoS. Molti di questi exploit sono identificate nel database MITRE 13 CVE. Ad esempio, CVE utilizza pacchetti H.323 malformati per sfruttare la perdita di memoria e l esaurimento delle risorse del server Windows ISA (Internet Security and Acceleration Server). Packet of Death DoS: è costituito dal flooding ai server VoIP di una serie enorme di pacchetti per esaurire CPU, larghezza di banda, sessioni TCP e altro. Per esempio, si può iniziare un attacco TCP Out of Band DoS inviando un gran numero di pacchetti TCP marcati con flag Urgent per indicare la priorità elevata. Durante qualsiasi flood, il maggior lavoro del carico interferisce con la capacità del sistema di ricezione di elaborare il traffico reale, ritardando inizialmente elaborazione del traffico voce, ma, infine, interrompendo il servizio. IP Phone Flood DoS: è l invio di una notevole quantità di chiamate dati verso un singolo endpoint per esaurire risorse. Sistemi di risposta vocale interattiva, gateway di telefonia, server per conferenze e sistemi di posta sono in grado di generare più chiamate di quelle che un singolo endpoint è in grado di gestire, e così potrebbe essere sfruttati per inondare un server. SIPVicious La suite SIPVicious è un insieme di strumenti che possono essere utilizzati per controllare i sistemi VoIP basati su SIP. Il suo utilizzo consente una rapida configurazione e diagnosi di una installazione VoIP; è infatti possibile testare la sicurezza del proprio centralino SIP tramite la costruzione di un attacco. Consiste in: Svmap. Svwar. Svcrack. Svreport. Svcrash. Svmap è un SIP scanner, ovvero permette di individuare tutti i server SIP presenti in un range di IP. Serve per verificare se sulla rete alla quale si è collegati è disponibile un server VoIP e a quale indirizzo lo si può trovare. 11 Un hardphone è un dispositivo tangibile, simile per molti aspetti ad un telefono analogico tradizionale. L'eccezione è che si collega alla rete IP domestica o aziendale rispetto a una linea telefonica analogica. Consente la connessione tramite un provider VoiP con altri utenti. Un hardphone si inserisce in una porta Ethernet su un router e può comunicare direttamente con un servizio di VoIP; ne esistono tuttavia anche wireless. I softphone sono generalmente più popolari perché non richiedono hardware aggiuntivo, ma gli hardphone sono più affidabili e offrono un significativo miglioramento esperienza di comunicazione. 12 Il Common Vulnerabilities and Exposures è un dizionario di vulnerabilità e falle di sicurezza pubblicamente conosciute. È mantenuto dalla MITRE Corporation. Gli identificatori CVE determinano in modo univoco le vulnerabilità note, e possono essere voci o candidati ad essere tali. 13 Organizzazione no profit che determina e certifica le CVE. È lo standard di settore per le vulnerabilità che fornisce punti di riferimento per lo scambio di dati in modo che i prodotti e servizi di informazioni di sicurezza possano interoperare tra loro. 41

42 Tra le opzioni possibili da inserire dopo svmap: --version: mostra il numero di versione del programma ed esce. -h, --help: mostra un messaggio di aiuto ed esce. -v, --verbose: aumenta il livello di dettaglio. -p PORT, --port=port: permette di specificare il numero di porta del centralino o il range di porte; ad esempio -p5060,5061, x IP, --externalip=ip; consente di determinare l indirizzo da utilizzare come IP esterno. -t SELECTTIME, --timeout=selecttime: permette di specificare la velocità con cui vengono inviati i pacchetti. -m METHOD, --method=method: consente di determinare il metodo della richiesta; di default è di tipo OPTIONS. --randomscan: permette di fare una scansione su IP scelti in modo random. --maximumtime=maximumtime: tempo massimo di attesa di una risposta. -d, --debug: stampa i messaggi SIP ricevuti. Di seguito è mostrato l invio del comando svmap. Questo sarà il primo step del progetto realizzato. In particolare, è possibile indicare un indirizzo IP con maschera 24 per indicare l appartenenza alla classe C di indirizzi. Nell output è possibile notare il dispositivo SIP relativo con l indirizzo di porta; se non specificato, come in questo caso, l indirizzo di porta è di default In User Agent, invece, è indicato la tipologia di server SIP (ad esempio, FPBX è il centralino Asterisk). Figura 33: Esempio di utilizzo di svmap. 42

43 Svwar identifica le estensioni attive su un centralino PBX (quelle che nel centralino tradizionale si chiamano interni). Prevede alcune opzioni molto utili: --version: mostra il numero di versione del programma ed esce. -h, --help: mostra un messaggio di aiuto ed esce. -v, --verbose: aumenta il livello di dettaglio. p PORT, --port=port: permette di specificare il numero di porta del centralino o il range di porte; ad esempio -p5060,5061, x IP, --externalip=ip; consente di determinare l indirizzo da utilizzare come IP esterno. -t SELECTTIME, --timeout=selecttime: permette di specificare la velocità con cui vengono inviati i pacchetti. -d DICTIONARY, --dictionary=dictionary: permette di specificare un possibile file di estensioni; -m OPTIONS, --method=options: consente di indicare il metodo della richiesta. Di default è REGISTER. Altri possibili metodi sono OPTIONS e INVITE. -e RANGE, --extensions=range: specifica il range di estensioni da ricercare; ad esempio: -e , ,9999. Di seguito è mostrato l invio del comando svwar. Questo sarà il secondo step del progetto realizzato. In particolare, è possibile visualizzare il relativo numero dell estensione. Figura 34: Esempio di utilizzo di svwar. 43

44 Svcrack permette di effettuare un attacco di forza bruta leggendo da un file contenente combinazioni di password. Per ogni password presente nel file viene creato un pacchetto SIP di richiesta ad Asterisk per provare l autenticazione ad una determinata estensione. Tra le opzioni: --version: mostra il numero di versione del programma ed esce. -h, --help: mostra un messaggio di aiuto ed esce. -v, --verbose: aumenta il livello di dettaglio. -p PORT, --port=port: permette di specificare il numero di porta del centralino o il range di porte; ad esempio -p5060,5061, x IP, --externalip=ip; consente di determinare l indirizzo da utilizzare come IP esterno. -t SELECTTIME, --timeout=selecttime: permette di specificare la velocità con cui vengono inviati i pacchetti. -u USERNAME, --username=username: indica l username dell estensione da attaccare. -d DICTIONARY, --dictionary=dictionary: specifica il file di password. Di seguito è mostrato l invio del comando svcrack. Questo sarà il terzo e ultimo step del progetto realizzato. In particolare, è possibile visualizzare il numero dell estensione scelto e la relativa password. Figura 35: Esempio di utilizzo di svcrack. Svreport, invece, gestisce le sessioni e consente di esportare file di report in vari formati. Svcrash, infine, tenta di fermare scansioni svwar e svcrack non autorizzate. Ma perché distribuire un tale tool che può essere utilizzato per attaccare un sistema VoIP? La risposta la danno gli stessi programmatori: L idea che sta dietro agli strumenti di aiuto e di sicurezza per amministratori è che le persone prendano decisioni informate nel momento in cui valutano la sicurezza dei loro server VoIP. Gli strumenti sono destinati ad essere utilizzati a fini didattici e dimostrativi. Si tratta dunque di uno strumento particolarmente utile, sia come aiuto alla configurazione che come tool di test della sicurezza. 44

45 Capitolo V: SIPAttack Introduzione In questo capitolo è descritto il tool da noi realizzato, che si ispira ai tre passaggi di SIPVicious analizzati nel capitolo precedente, ovvero svmap, svwar e svcrack. Il tool è definito completamente in Java ed è corredato da un interfaccia semplice e intuitiva, a differenza di SIPVicious, utilizzabile esclusivamente tramite shell. Il tool permette di simulare attacchi per valutare il livello di sicurezza del proprio PBX Asterisk. Caratteristiche Il tool, realizzato in Java, è costituito da tre passaggi che seguono un ordine logico sequenziale. Tali funzionalità però possono anche essere utilizzate singolarmente. SIPAttack, come già detto, si ispira al tool SIPVicious; in particolare: Il primo step è analogo a svmap: permette di individuare tutti i server SIP presenti in un range di IP dato in input dall utente. Serve per verificare se sulla rete alla quale si è collegati è disponibile un server VoIP e a quale indirizzo lo si può trovare. Il secondo step è analogo a svwar: identifica le estensioni (o interni) attive su un centralino PBX. Occorre specificare l indirizzo IP e la porta del PBX trovato; quindi un range di valori per determinare gli interni da ricercare. Il terzo step è analogo a svcrack: consente di effettuare un attacco di forza bruta leggendo da un dizionario le password presenti. Per ognuna viene creato un pacchetto SIP per tentare l autenticazione ad una determinata estensione. Occorre inserire l indirizzo IP del server, la relativa porta, l interno da attaccare e l url locale in cui si trova il dizionario. Contesto Il progetto si pone nell ambito del vulnerability assessment, ovvero un attività dedicata a individuare le vulnerabilità di un sistema di rete e a comprendere quali elementi dello stesso possano essere oggetto di attacchi o tentativi di intrusione. Ogni sistema informatico in generale presenta una serie di vulnerabilità, le quali possono essere insite nella sua architettura o causate da eventuali anomalie o bug; se opportunamente sfruttate, ne compromettono il livello di sicurezza. Al tempo stesso, capire e conoscere le falle di sicurezza del proprio sistema conduce ad un attenta analisi degli elementi necessari per predisporre un adeguato sistema di sicurezza. Un esame delle vulnerabilità consiste appunto nell identificare potenziali debolezze, che possono essere sfruttate da soggetti che mirano, per fini economici o personali, di prendere possesso dei sistemi o renderli inservibili. Le valutazioni sono tipicamente eseguite secondo le seguenti fasi: Catalogazione dei mezzi e delle capacità (risorse) in un sistema. Assegnazione di un valore quantificabile all'importanza di tali risorse. Identificazione delle vulnerabilità o potenziali minacce per ogni risorsa. Eliminazione delle più gravi vulnerabilità per le risorse più preziose. 45

46 Interfaccia Prima di realizzare l applicazione sono stati definiti alcuni mockup per delineare il reale funzionamento della nostra applicazione. Si è preventivato di creare un interfaccia semplice e intuitiva per permettere a chiunque di utilizzare il tool. I mockup realizzati sono risultati particolarmente utili in fase implementativa. Di seguito viene mostrato il mockup realizzato per la funzionalità di Ricerca Server Sip. Tale mockup rappresenta il primo step della nostra applicazione. Il funzionamento è molto semplice: nella parte superiore l utente inserisce l IP iniziale del range di ricerca dei server SIP e la relativa porta del processo. Cliccando sul bottone Cerca verranno mostrati gli eventuali server SIP trovati nella relativa form. Tale funzionalità emula dunque il comportamento del tool svmap di SIPVicious. Figura 36: Mockup ricerca server. 46

47 Di seguito viene mostrato il mockup realizzato per la funzionalità di Individuazione Interni. Tale mockup rappresenta il secondo step della nostra applicazione. Tale funzionalità può essere utilizzata singolarmente, oppure dopo l esecuzione della funzionalità descritta precedentemente. Il funzionamento è molto semplice: nella parte superiore l utente inserisce l IP iniziale del range di ricerca dei server SIP, la relativa porta del processo, e il range di estensioni da ricercare. Cliccando sul bottone Cerca verranno mostrati le eventuali estensioni trovate sui server SIP indicati. Tale funzionalità quindi emula il comportamento del tool svwar di SIPVicious. Figura 37: Mockup ricerca interni. 47

48 Infine viene mostrato il mockup realizzato per la funzionalità di Ricerca Sip Password. Tale mockup rappresenta il terzo step della nostra applicazione. Tale funzionalità può essere utilizzata singolarmente, oppure dopo l esecuzione delle funzionalità descritte precedentemente. Il funzionamento è molto intuitivo: nella parte superiore l utente inserisce l IP iniziale del server SIP scelto, la relativa porta del processo, l estensione da ricercare e il path locale del dizionario contenente le password. Cliccando sul bottone Cerca verrà mostrata la password trovata se presente nel dizionario di password. Tale funzionalità quindi emula il comportamento del tool svcrack di SIPVicious. Figura 38: Mockup ricerca password. 48

49 Sequence e class diagram Oltre ai vari mockup realizzati, per la fase implementativa è risultata utile la definizione di sequence diagram per determinare in modo chiaro l interazione dell utente con il sistema realizzato. I sequence diagram sono stati quindi necessari per evidenziare la sequenza temporale dei messaggi che gli oggetti del sistema e l utente scambiano per portare a termine l esecuzione di una certa funzionalità. In particolare, è stato realizzato un sequence diagram per ogni step della nostra applicazione: Ricerca dei server SIP. Ricerca degli interni su un server SIP. Ricerca password di un estensione su un server SIP. Il sequence diagram di seguito mostra l interazione che si verifica nel primo step dell applicazione: vengono creati pacchetti SIP di richiesta al server SIP successivamente alla compilazione della form dei dati (come descritto nel primo mockup del paragrafo precedente). Il server SIP, sollecitato da una richiesta SIP, risponde alla richiesta con un altro pacchetto SIP destinato all applicazione dal quale vengono estrapolate informazioni per l identificazione del server stesso. Figura 39: Sequence diagram per ricerca server. 49

50 Il sequence diagram di seguito mostra l interazione che si verifica nel secondo step dell applicazione: vengono creati pacchetti SIP di richiesta al server SIP successivamente alla compilazione della form dei dati (come descritto nel secondo mockup del paragrafo precedente). Il relativo server risponde alla richiesta con un altro pacchetto SIP destinato all applicazione, dal quale verranno estrapolate informazioni per l identificazione di un estensione sul server, se presente. Figura 40: Sequence diagram per ricerca interni. 50

51 Il sequence diagram di seguito mostra l interazione che si verifica nel terzo step dell applicazione: vengono creati pacchetti SIP di richiesta al server SIP successivamente alla compilazione della form dei dati (come descritto nel terzo mockup del paragrafo precedente). Il relativo server risponde alla richiesta con un altro pacchetto SIP destinato all applicazione, dal quale verranno estrapolate informazioni per effettuare una nuova richiesta di registrazione attingendo le password dal dizionario indicato. Il server risponde a sua volta con un pacchetto SIP che determina il successo o meno dell operazione. Figura 41: Sequence diagram per ricerca password. La descrizione più dettagliata dei pacchetti SIP utilizzati verrà delineata nei paragrafi successivi. 51

52 Infine, per concludere la prefazione all applicazione, viene mostrato il class diagram. Oltre a descrivere i vari boundary, control e object per la definizione dei sequence diagram, offre una visione statica del sistema, ovvero mostra schematicamente le varie feature dell applicazione. Figura 42: Class diagram. 52

53 Primo passaggio Ricerca server SIP La prima interfaccia permette la ricerca di un qualsiasi server SIP, sebbene l obiettivo è quello di trovare un PBX Asterisk. In particolare, occorre specificare un indirizzo IP e un numero di porta. Ad esempio, se si inserisce l indirizzo , la ricerca degli host viene fatta da questo indirizzo fino a (255 escluso poiché indirizzo di broadcast). Il range massimo possibile, chiaramente, è definito da a La porta, invece, è nella maggior parte dei casi 5060, ovvero quella di default dei PBX Asterisk. Cliccando su Cerca, il sistema inserisce i risultati nelle due liste, Server e IP : nella prima sono inseriti i relativi nomi (ad esempio, Asterisk Free PBX ), mentre nella seconda i corrispondenti indirizzi. Figura 43: Prima interfaccia - Ricerca server SIP. 53

54 L interfaccia compilata si presenta in questo modo. Figura 44: Prima interfaccia - Esempio di Ricerca server SIP. Nell esempio si è cercato un PBX all interno di una rete locale: inserendo il sistema cerca da a In questo caso il sistema ha trovato un Free PBX (con la relativa versione) e il corrispondente indirizzo IP. Di seguito viene descritto come è stato sviluppato tale primo step. Viene creato il pacchetto per cercare un server; il pacchetto è di tipo REGISTER e viene inviato al range di indirizzo IP scelto, sulla porta specificata. Se esiste un server SIP, si ottiene una risposta che permette di riconoscerlo come centralino; quindi si inserisce all interno della lista descritta in precedenza. È possibile anche specificare un interno di ricerca, in questo caso 700; qualora non corrispondesse a un centralino, invierebbe un pacchetto di errore. Ciò non rappresenta un problema, perché è necessaria solo la risposta. Figura 45: Prima interfaccia - Costruzione di un pacchetto REGISTER. 54

55 La costruzione del pacchetto creato si presenta in questo modo; il codice mostrato in precedenza consente la costruzione di tale pacchetto; è possibile notare: Il pacchetto è di tipo REGISTER. L indirizzo e la porta da cui è partita la richiesta. L indirizzo e la porta contattata. Il tag per identificare il pacchetto, è un numero casuale. L utilizzo del protocollo di trasporto UDP. Figura 46: Prima interfaccia - Stampa del pacchetto creato. Di seguito è mostrato un esempio di pacchetto ricevuto dal server, qualora esistesse. In questo caso, il server Asterisk ha risposto con 404 Not found per indicare che l interno cercato non esiste. Come già detto, è di fondamentale interesse ottenere una risposta dal server per capire la sua presenza; in particolare, il campo Server indica che è un FPBX (con la relativa versione); quest ultimo permette di comprendere la tipologia del server contattato. Figura 47: Prima interfaccia - Stampa del pacchetto ricevuto. 55

56 Secondo passaggio Ricerca interni Il secondo step consente di individuare un interno nel PBX, dopo essere riusciti a trovare un server. In particolare, occorre specificare l indirizzo IP e la porta del centralino trovato; quindi un range di valori per determinare gli interni da ricercare. Chiaramente, se il range di valori non è determinato correttamente (ad esempio, Intervallo iniziale 200 e Intervallo finale 100) o se vengono inseriti caratteri alfabetici, il sistema risponde con un errore. Al click di Cerca, il sistema cerca gli interni nell intervallo specificato e li inserisce in Risultati. Figura 48: Seconda interfaccia - Ricerca interni. 56

57 Nell esempio si è specificato l indirizzo e la porta del server, quindi gli interni compresi tra 100 e 700. Il sistema, al click di Cerca, inserisce i risultati nella relativa lista. Figura 49: Seconda interfaccia - Esempio di Ricerca Interni. Di seguito viene descritto come è stato sviluppato tale secondo step. 57

58 Viene creato un pacchetto di richiesta molto simile al precedente, con la differenza che, in questo caso, si è specificato l interno cercato di volta in volta. Dunque, prima era un interno fittizio poiché era importante solo la risposta circa la presenza del server SIP; ora invece il range di valori è specificato; quindi nel comando sip si specifica l interno desiderato tramite la variabile interno evidenziata. In questa situazione sarà di particolare interesse la risposta del server. Figura 50: Seconda interfaccia - Costruzione di un pacchetto REGISTER. Un esempio di risposta del server Asterisk è 401 Unauthorized : indica che l interno cercato esiste, ma non siamo autorizzati a connetterci. Questa situazione è tipica ed è stata affrontata nella descrizione della registrazione ad un server SIP. Il server sfida l utente tramite il campo nonce : occorre applicare l algoritmo md5 per inviare l username e la password in maniera corretta. Il campo to con sip:200 indica che l interno appartiene al centralino. Figura 51: Seconda interfaccia - Stampa del pacchetto ricevuto (401). Un altro esempio di risposta è 404 Not found : indica che il server Asterisk non ha l interno 203 specificato nel campo to. Chiaramente, questo interno non sarà mostrato nel campo Risultati dell interfaccia. Figura 52: Seconda interfaccia - Stampa del pacchetto ricevuto (404). 58

59 Terzo passaggio Ricerca Password Il terzo step consente di ricercare la password: dopo aver trovato il server e scelto un interno, si cerca di determinarne la password (tramite un dizionario). L interfaccia prevede: L inserimento dell indirizzo IP del server. La relativa porta. L interno da attaccare. L url locale in cui si trova il dizionario. Figura 53: Terza interfaccia - Ricerca password. 59

60 Al click di Cerca il sistema analizza il dizionario; se non trova la password il risultato sarà Password non trovata. Figura 54: Terza interfaccia Esempio di ricerca password (password non trovata). 60

61 Se invece la password viene trovata, verrà mostrata all utente. Figura 55: Terza interfaccia Esempio di ricerca password (password trovata). Qualora riuscisse ad ottenere tale informazione, l utente può registrarsi su quell interno e effettuare chiamate malevoli grazie al PBX. Di seguito viene descritto come è stato sviluppato tale terzo step. 61

62 Viene creato un pacchetto di richiesta di tipo REGISTER (identico al precedente), in cui si specifica l interno cercato; nel pacchetto non sono specificati né password né username, poiché è necessario ottenere un pacchetto dal server in cui si dovrà analizzare il realm e il nonce. Figura 56: Terza interfaccia - Costruzione primo pacchetto REGISTER. Un esempio di risposta del server è 401 Unauthorized : il server indica all utente che non è autorizzato alla connessione, perché la password non è codificata; infatti, risponde specificando il realm, il nonce e l algorithm=md5 ; l utente deve utilizzare i primi due per darli in input all algoritmo md5. Tuttavia, realm e nonce variano continuamente: se si riprovasse la connessione in un secondo momento, si troverebbero diversi da quelli precedenti. Come nei casi precedenti, la prima risposta è solo per poter individuare il realm e il nonce. Figura 57: Terza interfaccia - Stampa del pacchetto ricevuto (401). Ottenuti realm e nonce dalla risposta precedente, occorre applicare l algoritmo md5. L algoritmo prende in input tre stringhe: La prima è la concatenazione tra interno, realm e la password (quest ultima così come la si sta cercando). La seconda è il tipo di richiesta ( REGISTER:sip: ) con il relativo indirizzo IP. La terza è il risultato dell algoritmo md5 applicato alla prima stringa, di nonce e del risultato dell algoritmo md5 applicato alla seconda stringa. La stringa finale, ha3, rappresenta il formato della password richiesto dal server Asterisk. Il pacchetto di registrazione, in questo caso, prevede un campo Authorization in cui è descritto: L username (ovvero l interno). Il realm (ottenuto precedentemente). Il nonce (ottenuto precedentemente). L URI (ovvero l indirizzo IP di connessione). La risposta (ovvero ha3 ). Quindi si invia il pacchetto al PBX Asterisk. 62

63 Figura 58: Terza interfaccia - Costruzione secondo pacchetto REGISTER. La risposta ottenuta dopo l invio del pacchetto è 200 OK ; l algoritmo md5 è stato applicato correttamente e l utente si è registrato al centralino. La password cercata è dunque quella corretta. Figura 59: Terza interfaccia - Stampa del pacchetto ricevuto (200). Di seguito viene descritta la classe MD5 utilizzata: il metodo md5digest() prende in input una stringa e esegue queste linee di codice per generare la stringa hash. Figura 60: Terza interfaccia - Algoritmo md5. 63

64 Alert Sono stati realizzati dei semplici alert che forniscono un aiuto all utente sul riempimento dei campi in ciascuna sezione. Figura 61: Info ricerca server SIP. Figura 62: Info ricerca interni. Figura 63: Info ricerca password. 64

65 Approfondimento su SIP Digest authentication Digest access authentication è un metodo concordato che un web server può usare per negoziare le credenziali di un utente di un browser; il meccanismo prevede di applicare una funzione hash alla password prima di applicare in rete, a differenza di basic access authentication (che la invia in testo semplice). La prima specifica, descritta nell RFC 2069, prevede uno schema di autenticazione tradizionale, in cui la sicurezza è garantita tramite un nonce generato lato server. La risposta all autenticazione è formata in questo modo: Figura 64: Risposta all'autenticazione. L RFC 2069 è stato sostituito da RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication). Quest ultima introduce una serie di miglioramenti opzionali di sicurezza all autenticazione digest: "quality of protection" (qop). Contatore nonce incrementato dal client. Un nonce generato casualmente dal client. Come fa quindi un client SIP a comunicare le proprie credenziali di autenticazione al server? Quasi tutti i dispositivi inviano un pacchetto REGISTER al SIP Proxy Server; la risposta è 401 Unauthorized. In questo pacchetto di risposta vi è una riga ( header field ) costituita da: WWW-Authenticate: Digest realm= voip.eutelia.it, nonce= da1af55bfd20e7e55d8d2bb81eba54e377, qop= auth. Il client che vuole registrarsi estrae: Il realm di riferimento (ovvero il dominio, gruppo logico degli account SIP). Il tipo di autenticazione ( auth ). Una chiave random necessaria all encryption ( nonce ). A questo punto invia di nuovo il pacchetto REGISTER, ma con un nuovo campo dove è contenuta la password criptata: Authorization: Digest username= ,realm= voip.eutelia.it, nonce= da1af55bfd20e7e55e8d2bb81eba54e377, response= 6f00b8e7c da9a8c044ecd, uri= sip:voip.eutelia.it,qop=auth, cnonce= B18606FEE42246E39B068D3210CCC691, algorithm=md5, qop=auth, nc=

66 La password dell account è contenuta in response: il server ha tutte le informazioni (conoscendo a sua volta la password) per calcolare la response e confrontarla con quella mandata dal client. Come si calcola dunque la response? È la somma MD5 della sequenza: response = MD5 (HA1:nonce:nonceCount:clientNonce:qop:HA2) I due parametri HA1 e HA2 si calcolano rispettivamente come segue: HA1 = MD5 (username:realm:password) HA2 = MD5 (method:digest uri) Dunque con i parametri ricevuti nel 401 Unauthorized il client calcola HA1 e HA2, e quindi la response. Il server può farlo solo dopo aver ricevuto il secondo REGISTER con il campo Authorization ; effettuato il confronto, se coincidono risponde con 200 OK. 66

67 Capitolo VI: Migliorare la sicurezza di Asterisk Introduzione La tecnologia VoIP è ampiamente utilizzata oggi, al punto tale da attrarre l'attenzione dei cyber-criminali. Era inevitabile, e ampiamente previsto, che il VoIP sarebbe diventato un bersaglio preferito per gli hacker, data la sua popolarità e la larga diffusione. Sia il livello di sofisticazione che il numero di attacchi contro i server VoIP e PBX si sono progressivamente intensificati nel corso degli anni e sono notevolmente incrementati negli ultimi 12 mesi. Security probing 14 e port scanning 15 si manifestano più volte al giorno, anche sugli indirizzi IP che non fanno parte di un qualsiasi servizio del protocollo SIP. Per di più, ogni nuovo tentativo sembra provenire da un indirizzo IP diverso. Questo rende più difficile bloccarli solo a livello di firewall e indica che gli aspiranti hacker stanno utilizzando una botnet 16. Un'altra possibilità è che l'indirizzo sorgente viene deliberatamente falsificato: ciò renderebbe difficile rilevare l'indirizzo di origine reale che viene mascherato dal "rumore" di molti indirizzi generati casualmente. Esistono diversi modi per difendersi al meglio, migliorando la sicurezza del proprio PBX e facendo fallire i tentativi di attacco di SIPAttack e SIPVicious. Perfezionare SIP Recentemente gli attacchi agli endpoint SIP sono notevolmente incrementati. Una serie di nuovi strumenti hanno reso semplice, da parte degli hacker, frodare tali endpoint (sistemi basati su Asterisk inclusi). La scelta di utilizzare una blacklist condivisa nella comunità è ormai superata; occorre trovare una soluzione integrata in Asterisk. Alcuni tra metodi e strumenti più comuni per aumentare la protezione sono: Non accettare richieste di autenticazione SIP da tutti gli indirizzi IP. Utilizzare "permit =" e "deny =" nel file sip.conf per consentire solo un sottoinsieme ragionevole di indirizzi IP di raggiungere ogni utente elencato nello stesso file. Anche se si accettano chiamate in ingresso da "ovunque" (tramite [default]) non lasciare che gli utenti raggiungano elementi autenticati. Aprire le porte in ingresso solo per i servizi necessari: 22/tcp per ssh. 4569/tcp per IAX /udp per registrazione /udp per RTP. Impostare "alwaysauthreject = yes" nel file sip.conf. Il valore predefinito è "no", che determina la perdita di informazioni di estensione. L'impostazione a "yes" respingerà le richieste di autenticazione negative su username validi, negando agli aggressori remoti la capacità di individuare le estensioni esistenti con attacchi a forza bruta. Cambiare tutte le password di default. Utilizzare password complesse per le entità SIP. È uno dei passi fondamentali. Un errore comune è concatenare semplicemente due parole. Occorre invece utilizzare un mix di simboli, numeri, minuscole, maiuscole, con lunghezza di almeno 12 cifre. Bloccare le porte AMI. Utilizzare "permit =" e "deny =" in manager.conf per ridurre le connessioni in ingresso ai soli host conosciuti. Utilizzare password complesse. Permettere solo una o due chiamate alla volta per utente. Ciò limita l esposizione alle frodi. 14 Azione effettuata dall esterno allo scopo di imparare qualcosa sullo stato della rete. 15 Tecnica utilizzata per raccogliere informazioni su un computer connesso ad una rete, stabilendo quali porte sono in ascolto. 16 Rete formata da dispositivi connessi ad Internet e infettati da malware, in maniera tale da controllare il sistema da remoto. Sono spesso sfruttare per scagliare attacchi DDoS. 67

68 Utilizzare un username diverso rispetto al numero dell estensione. È quello che gli hacker si aspettano; utilizzare l'indirizzo MAC del dispositivo, o una sorta di combinazione di una frase comune e estensione hash MD5. Verificare che il [default] context sia sicuro. Negare ai chiamanti non autenticati di raggiungere tutti i context che permettono le chiamate interurbane. Consentire solo un numero limitato di chiamate attive tramite il contesto di default. Un importante approfondimento va fatto sull ultimo punto. Se il server Asterisk necessita di accettare richieste legittime da indirizzi IP che non si conoscono in anticipo, occorre modificare correttamente la configurazione, interpretando quali contesti di dial plan sono associati ad ogni tipo di chiamata in entrata. Un contesto specifico deve essere definito per ogni peer nel file sip.conf usando context=<context_name> nella definizione del peer. Così facendo si può quindi essere certi che richieste INVITE da tutte le altre fonti utilizzino il default context. Un ulteriore analisi è necessaria per il parametro alwaysauthreject all interno del file sip.conf. Impostando questo parametro a yes il tool SIPAttack non riesce ad individuare nessun interno presente sul centralino. Figura 65: Parametro "alwaysauthreject" impostato a "no". La figura mostra come, con l impostazione alwaysauthreject = no, SIPAttack è in grado di individuare gli interni compresi tra 100 e 700. Tuttavia, assegnando questo parametro a yes, il centralino non fornisce informazioni precise sugli interni. 68

69 Figura 66: Parametro "alwaysauthreject" impostato a "yes". Dalla figura è possibile notare come Asterisk ha indicato come interni tutti i numeri che vanno da 100 a 700. Tali accortezze proteggeranno dalla maggior parte degli attacchi. Altre soluzioni utili sono, ad esempio, tool di sicurezza aggiuntivi come fail2ban, che consente di effettuare il ban di endpoint in base al volume di richieste. Proteggere il server La maggior parte delle truffe telefoniche fatte ai danni dei possessori di centralini IP si basa sull autenticarsi al PBX come interno, per poi chiamare numeri a tariffazione aggiuntiva, rivendere il traffico e altro. La miglior linea di difesa è rendere il PBX invulnerabile dall esterno. Riguardo la configurazione del PBX, per difendersi al meglio occorre: Proteggere la LAN, evitando connessioni ad Internet non protette. Tutelare le applicazioni CTI 17, che accettano connessioni TCP su porte non standard per operare sul telefono dal computer. Controllare le chiamate effettuate: se sono dirette verso destinazioni sconosciute, ci si può facilmente accorgere che il proprio PBX è stato violato. Particolare attenzione dunque al cartellino di traffico (o CDR). Impostare il barring: diversi provider offrono la possibilità di rendere non raggiungibili determinate destinazioni (ad esempio, le chiamate internazionali). 17 Con Computer Telephony Integration si denota qualsiasi tecnologia che permetta interazioni tra un telefono e un computer, consentendone dunque il coordinamento integrato. 69

70 Controllare i registri regolarmente: anche se si dispone di un sistema intelligente di registrazione o di fatturazione delle chiamate, è ragionevole controllare i file di log dell'applicazione abbastanza spesso. Il file di registro principale per Asterisk è: /var/log/asterisk/messages. /var/log/asterisk/full. In tale file si potrebbero vedere numerosi tentativi falliti di registrazione, mostrando la dimensione del problema, gli account nei quali gli hacker stanno cercando di intrufolarsi, il tipo di attacco e, a volte, gli indirizzi IP da cui l'attacco proviene. È anche possibile aggiungere software o hardware al PBX per migliorare la sicurezza tramite: L installazione di un firewall. L attivazione di IPTables: è il firewall generico incluso in Linux. Non è PBX-aware, ma è un ottima aggiunta al miglioramento della sicurezza. Aggiungere semplicemente regole statiche per ogni fonte non è una soluzione: non si può conoscere le azioni o le intenzioni di qualcuno connesso al PBX. Firewall Introduzione Se si sta cercando di proteggere il PBX sono disponibili diverse opzioni, che possono essere attuate singolarmente o in combinazione: Configurazione: regolare le impostazioni del PBX per ridurre al minimo le situazioni di attacco evidenti. Sicurezza perimetrale: aggiungere software/hardware al PBX per migliorare la sicurezza. Sicurezza integrata: annettere software che si integra con il PBX specifico per incrementare il livello di sicurezza. L ultimo punto è ciò che fa davvero la differenza nella protezione del PBX. IPTables IPTables è il firewall, da linea di comando, installato in modo predefinito su Ubuntu. È classificato come un firewall administrator. Un computer connesso ad internet scambia continuamente dati col resto del mondo. Tali dati creano un traffico dati che può avere finalità malevoli o meno. Il compito del firewall è saper riconoscere la natura del traffico dati mediante alcune metriche di valutazione. Per indicare quali sono le metriche di valutazione da utilizzare, un firewall ha bisogno di regole che ne definiscono il numero di controlli da effettuare sul traffico dati. IPTables raggruppa tutti i controlli che il sistema può fare sul traffico in entrata, nella cosiddetta chain INPUT. I controlli sul traffico in uscita sono invece raggruppati nella chain OUTPUT. La chain FORWARD è utilizzata per il traffico dati da reindirizzare. Ognuna di queste catene definisce una policy, cioè un'azione predefinita da eseguire qualora i controlli della chain fallissero nel riconoscere il dato malevolo. Per visualizzare in ogni momento la configurazione del firewall IPTables, è sufficiente digitare da terminale: sudo iptables L Avendo il firewall attivo (lo è di default) ciò che compare alla prima configurazione è: 70

71 Figura 67: Esempio di utilizzo di IPTables prima della configurazione. La figura mostra una mancanza di una vera configurazione, poiché IPTables non indica delle regole firewall e lascia passare tutto grazie alla dicitura Policy Accept. Grazie ad IPTables è possibile impostare le policy di base provenienti dai diversi canali. Se ad esempio sorge la necessità di voler bloccare tutto il traffico proveniente dall esterno, è possibile impostare una policy che rifiuti tutti i pacchetti in entrata mediante il comando: sudo iptables -P INPUT DROP Con tale policy è impossibile navigare sul web, e più in generale il sistema non considererà nessun dato in arrivo. È possibile riattivare il traffico in entrata mediante il comando: sudo iptables -A INPUT ACCEPT In linea generale una policy che è bene settare è quella relativa al forward mediante il comando: sudo iptables -P FORWARD DROP Tale comando impedisce il funzionamento del canale di forward nel sistema. fail2ban fail2ban è uno strumento standard di Linux utilizzato per la scansione dei file di log, e quindi per bloccare gli indirizzi IP trovati con IPTables. Dipende completamente dall'applicazione (in questo caso, Asterisk) per rilevare eventuali intrusioni e registrare i dati degli utenti: non fornisce alcun tipo di rilevamento degli attacchi. Figura 68: Fail2ban. 71

72 fail2ban opera monitorando i file di log (ad esempio /var/log/auth.log, /var/log/apache/access.log) per le voci selezionate e l'esecuzione di script basati su di esse. Più comunemente è usato per bloccare gli indirizzi IP selezionati che possono appartenere a host che stanno cercando di violare la sicurezza del sistema. Si può vietare l accesso a qualsiasi IP host che fa troppi tentativi di ingresso o esegue qualsiasi altra azione indesiderata in un arco di tempo definito dall'amministratore. È in genere impostato per eliminare il ban ad un host bloccato entro un certo periodo di tempo, in modo da non "bloccare" i collegamenti autentici che possono essere stati temporaneamente configurati in maniera scorretta. Tuttavia, un tempo di unban di alcuni minuti è generalmente sufficiente a bloccare una connessione di rete, essendoci la possibilità di essere inondati da connessioni dannose. fail2ban è in grado di eseguire più azioni ogni volta che viene rilevato un IP illecita: Aggiornare Netfilter/IPTables o le regole di Packet Filter. Respingere l'indirizzo IP di un aggressore. Inviare notifiche . Qualsiasi azione definita dall'utente che può essere effettuata da uno script Python. La configurazione standard è basata con filtri per Apache, Lighttpd, sshd, vsftpd, Qmail, Postfix e Courier Mail Server. I filtri vengono definiti da espressioni regolari Python, che possono essere facilmente personalizzate. Una combinazione di un filtro e un'azione è conosciuta come "jail" ed è ciò che causa lo sbarramento di un host dannoso ai servizi di rete specificati. Così come gli esempi che sono distribuiti con il software, un "jail" può essere creato per qualsiasi processo di rete che crea un file di log degli accesso. fail2ban è simile a DenyHosts, ma a differenza di DenyHosts, che si concentra su SSH, può essere configurato per monitorare qualsiasi servizio che scrive tentativi di accesso ad un file di log, e invece di usare solo /etc/hosts.deny per bloccare gli indirizzi IP, può utilizzare Netfilter/iptables e TCP Wrapper 18 /etc/hosts.deny. Tuttavia, fail2ban ha alcune carenze: Non riesce a proteggere il PBX nei confronti di un DDoS. Non vi è alcun supporto IPv6. Non vi è alcuna interazione con specifiche per le applicazioni API/AGI. Tra le caratteristiche della versione 0.8.x: Architettura client/server. Multi-thread. Altamente configurabile. Supporto Gamin/Pyinotify. Analizza i file di log e cerca determinati pattern. Esegue comandi quando un pattern è stato rilevato per lo stesso indirizzo IP per più di X volte. X può essere modificato. Dopo un determinato periodo di tempo, esegue un altro comando per togliere il ban all'indirizzo IP; Utilizza Netfilter/IPTables di default ma può anche utilizzare il protocollo TCP Wrapper (/etc/hosts.deny) e molti altri firewall. Gestisce la rotazione dei file di log. Coordina il servizio multiplo (sshd, apache, vsftpd, ecc). 18 TCP Wrapper è un sistema di rete di Access Control List basato su host, utilizzato per filtrare l'accesso alla rete ai server Internet Protocol su sistemi operativi come GNU/Linux o BSD. Permette agli indirizzi IP host o di sottorete fi essere utilizzati come filtri per il controllo degli accessi. 72

73 Risolve DNS da hostname a IP (da utilizzare con cautela; si può disabilitare con usedns = no ). Invece, tra le feature aggiunte nella versione 0.9.x: Azioni Python di base. Supporto database. Parsing multilinee nei filtri. Consapevolezza del fuso orario. Timeout sui comandi di ban. Ampia scelta del set di caratteri nei file di log. Supporto Python3+. Installazione e configurazione di fail2ban con IPTables Il firewall file2ban è installabile mediante il comando: apt-get -t unstable install fail2ban Al termine dell installazione il firewall risulta già in esecuzione come processo demone. Prima di inserire fail2ban all interno di IPTables è necessario configurarlo. Il file di configurazione di file2ban si trova in /etc/fail2ban.conf. Tale file di configurazione segue le logiche già descritte dei file di Asterisk. Per poter inserire le proprie configurazioni in tale file risulta necessario modificare, ad esempio, la sezione [default] come segue: [default] maxfailures = 3 bantime = 900 findtime = 600 L attributo maxfailures indica che dopo tre tentativi di accesso falliti rilevati da un unico indirizzo IP all interno dei 600 secondi( findtime ) l indirizzo sarà bloccato per 900 secondi ( bandtime ). Spesso i tentativi sono effettuati da un bot; in tal caso, viene ostacolato e si sposterà su un altro PBX. Per ricevere una notifica via ogni qual volta viene bloccato un indirizzo IP è possibile editare la sezione mail come segue: [mail] enabled = true to = root@localhost Un altra sezione essenziale per la corretta scansione dei log è la sezione [ssh]; può essere aggiunta come segue: [ssh] enabled = true logfile = /var/log/auth.log Grazie a tale indicazioni fail2ban controlla il file auth.log per analizzare i tentativi di accesso al sistema. Il processo demone di file2ban resta in esecuzione sulla porta SSH numero 22, che sarà protetta da potenziali attacchi di brute-force. Le azioni prese in carico dal processo demone sono presenti nel log di file2ban in /var/log/fail2ban.log. Una volta configurato file2ban è necessario aggiungere una regola firewall all interno di IPTables. Ciò è possibile mediante il comando: 73

74 fwstart = iptables -N fail2ban-ssh iptables -A fail2ban-ssh -j RETURN iptables -I INPUT -p tcp --dport ssh -j fail2ban-ssh La prima riga crea una nuova chain chiamata fail2ban-ssh. La seconda riga aggiunge una istruzione di return alla fine della chain fail2ban-ssh. La terza riga inserisce una regola all inizio della INPUT chain di IPTables che redirige i pacchetti SSH alla chain fail2ban-ssh. Terminato questo processo tale regola sarà aggiunta in IPTables. Per appurarsi dell effettivo successo dell operazione è possibile lanciare il comando iptables L. Ciò che compare sul terminale è: Figura 69: Esempio di utilizzo di IPTables dopo la configurazione. Poiché nella chain fail2ban non esistono regole, i tentativi di connessione con SSH rilevati dal sistema sono reindirizzati dalla chain INPUT alla chain fail2ban, la quale a sua volta fornisce nuovamente il controllo alla chain INPUT. Ciò significa che il processo demone fail2ban è in grado di inserire nuove regole in qualsiasi momento. Tali regole saranno quindi applicate a tutto il traffico ssh in entrata. Sicurezza e SIPAttack Dopo un attenta analisi di fail2ban e una descrizione di IPTables, è necessario verificare cosa cambia nel funzionamento del tool SIPAttack dopo la configurazione di fail2ban con IPTables. Effettuando la ricerca delle password senza il firewall IPTables, il sistema, per ogni password presente nel dizionario, tenta la registrazione. 74

75 Figura 70: Funzionamento di SIPAttack con il firewall IPTables disattivato. Nell esempio, la ricerca è andata a buon fine, poiché nel dizionario era presente la password telefono200 corrispondente all interno 200. Effettuando la ricerca delle password con il firewall IPTables attivo con il firewall file2ban, il sistema blocca la connessione, impedendo così le richieste di registrazione. 75

76 Figura 71: Funzionamento di SIPAttack con il firewall IPTables attivato. SecAst SecAst è un sistema di firewall e di intrusion detection e prevention, progettato specificamente per proteggere i sistemi telefonici basati su Asterisk contro gli attacchi e la frode. Utilizza una varietà di tecniche per rilevare tentativi di intrusione, fermare gli attacchi in corso e prevenirne futuri. Inoltre, usa tecniche avanzate per rilevare credenziali valide che sono state compromesse. Usufruisce di algoritmi euristici per rilevare attività fraudolente in base a schemi di attacco noti. Al rilevamento blocca l'attaccante dall' Asterisk host a livello di rete. Figura 72: SecAst logo. SecAst è una soluzione software che comunica con Asterisk principalmente tramite la AMI (Asterisk Management Interface), ma anche attraverso il monitoraggio dei log di sicurezza per le informazioni utili; permette inoltre lo scambio di informazioni con le interfacce di rete di Linux. I dati da queste fonti consentono di monitorare: 76

77 La connessione. I tentativi di comporre una chiamata con credenziali non valide. Il tasso a cui gli utenti chiamano. Il numero di canali in uso da parte dell'utente attraverso tutti i protocolli. L indirizzo IP di utenti remoti. Combinando tali dati può fermare efficacemente gli attacchi e avvisare l'amministratore con i dettagli di ognuno. SecAst offre dettagliate regole geografiche di accesso (geofencing) senza complesse regole del firewall. L utilizzo del geofencing riduce drasticamente il numero e il rischio di attacchi, consentendo agli amministratori di eliminare rapidamente continenti, paesi, regioni o città dove i rispettivi utenti non potrebbero mai trovarsi. Il firewall offre ampie interfacce per interagire con altri programmi, utility, firewall esterni e molto altro, consentendo una notevole personalizzazione. Figura 73: Phone inside wall. Tra le feature più importanti: Compatibilità: è compatibile con una vasta gamma di versioni e distribuzioni Asterisk. SecAst funziona con le versioni da 1.4 a 13, sia a 32-bit e 64-bit. È anche compatibile con una vasta gamma di distribuzioni Asterisk, dalla Digium a FreePBX, PBX in Flash e TrixBox, Thirdlane e altro ancora. Rilevamento attacchi a forza bruta: sono attacchi innescati da numerosi tentativi di accesso attraverso varie combinazioni di nomi utente e password. A differenza di altri software, è in grado di rilevare questi attacchi, anche se distribuiti su diversi giorni (gli aggressori cercano di eseguire attacchi sottili per bypassare programmi di rilevazione come fail2ban). Può rispondere a questi attacchi bloccandoli a livello di rete, impedendo ogni ulteriore tentativo. Questi blocchi possono durare per ore, giorni o indefinitamente. Detenzione di credenziali violate: può rilevare i pattern di traffico inusuale di credenziali violate (trapelate o in qualche modo scoperte da un utente malintenzionato). Questo include il monitoraggio del numero di chiamate in corso, quanto velocemente le chiamate sono create, la velocità con cui l'utente sta componendo le cifre del numero. Come detto prima, sono bloccati a livello di rete, anche indefinitamente. Euristica per rilevamento degli attacchi: può imparare nuovi schemi di attacco e, di conseguenza, regolarne la rilevazione. Lo scanner controlla una varietà di traffici di rete per rilevare attività 77

78 sospette, correlarli con regole che indicano il probabile attacco, e bloccare dunque l'attaccante al network layer, impedendone i successivi. Geofencing: incorpora un database di indirizzi IPv4 e IPv6 di tutto il mondo, includendo il continente/paese/regione/città di ognuno. Può essere configurato per consentire o negare l'accesso a qualsiasi combinazione di queste caratteristiche geografiche. Se un hacker tenta di utilizzare il server Asterisk da una posizione negata, ne viene subito scollegato. Ciò crea dunque una recinzione geografica (o geofence). Fiducia negli endpoint: può essere istruito a fidarsi di particolari trunk, endpoint (utenti o telefoni), o indirizzi IP in modo che siano esenti da controlli di sicurezza. Ciò consente agli amministratori di concedere particolari accessi agli utenti, indipendentemente dalla posizione, volumi di chiamate, ecc. Può essere particolarmente utile per personale continuamente in viaggio; consente inoltre di marcare alcuni percorsi come affidabili e altri come non attendibili. Interfaccia telnet: gli amministratori possono controllare facilmente telnet con un'interfaccia semplice e potente. Il sistema di sicurezza può essere gestito e controllato sia da PC, tablet o telefono cellulare. L'interfaccia include la guida in linea e semplice terminale. Threat Level Management: controlla il numero e la frequenza di attacchi contro il server, e, sulla base di soglie definite, consente di impostare il livello di minaccia del sistema. Interfaccia Browser: il sistema di sicurezza può essere gestito e controllato da qualsiasi browser. L'interfaccia include blocco/sblocco di indirizzi IP, controllo dei livelli di minaccia, la visualizzazione della cronologia degli attacchi e molto altro. SecAst viene eseguito come un service su Linux, normalmente in esecuzione sullo stesso server di Asterisk. Questo design permette ad esso l'accesso immediato agli eventi di sicurezza sul server, così come l'accesso all'interfaccia di rete per il monitoraggio. Inoltre evita l'introduzione di un singolo punto di failure sul critical path del traffico VoIP. 78

79 Figura 74: Esempio di architettura. Si interfaccia con una varietà di sottosistemi per raccogliere informazioni sullo stato della rete, di Asterisk e delle attività svolte dagli utenti VoIP (o da eventuali aggressori). Questo approccio unico consente a SecAst di osservare attentamente in profondità le azioni specifiche eseguite dagli utenti, la loro correlazione con i dati di rete, e li confronta con le risposte attese da Asterisk. 79