25 Passi per rendere sicura una rete VoIP

Credo sia ottimo questo post del blog Voip Lowdown riguardo la sicurezza di una rete VoIP: 25 sintetici e semplici passi. Non sono un esperto in materia, devo ancora studiare bene gli aspetti di queste reti, mi piacerebbe però sapere cosa ne pensa chi lavora sul campo.

Author: Dario Salvelli

Growth Hacker, Digital Marketing expert. I work as the Global Social Media Manager of Automobili Lamborghini. Contact me

8 thoughts on “25 Passi per rendere sicura una rete VoIP”

  1. Ciao, ti rispondo velocemente. In effetti, il documento che citi riporta un mx di regole di buon senso e di precauzioni già adottate ampiamente per la rete tradizionale. Come ogni servizio esposto verso l’esterno, il VoIP è suscettibile di attacchi.

    Se proprio devo muovere un appunto al post cui ti riferisci, critico la confusione con cui sono citati i “rimedi”: vengono mescolate precauzioni la cui adozione compete a un provider con quelle da adottare fra le quattro mura domestiche.

    Inoltre, se il VoIP vuole diventare un utility end user non si può nemmeno pensare di demandare all’utente inesperto la gestione di una vlan, la segmentazione della rete, l’audit su pattern, l’implementazione di layer di crittazione, il QoS sui servizi.

    Semplicemente impensabile. Oltretutto, penso che nemmeno la maggior parte degli utenti esperti implementerebbe tutti i consigli elencati.

    Più che il singolo ATA, pur valida soluzione, io vedo con maggiore favore una soluzione integrata alla Fritz! in cui modem, router, VoiP e wlan sono integrate. Ed è lì che dovrebbe agire il produttore, implementando meccanismi di gestione che aumentino la sicurezza lato utente.

    Poi, se anche dal lato del fornitore della connettività si imparasse a fornire e a pubblicizzare meccanismi di crittazione, non sarebbe male.

  2. Infatti non sono “semplici” Passi, spesso si fa confusione tra chi offre il servizio e chi invece ne usufruisce, sarà perchè il VoIP non è ancora molto diffuso, o non c’è abbastanza informazione ed offerta.
    Neanche gli utenti esperti, e questo è vero, adottano misure così complete riguardo la sicurezza (per chi legge e non conosce l’ATA legga su wikipedia: .
    Della buona soluzione Fritz!Box Fon WLAN 7050, della quale ne parlai sul blog (purtroppo non trovo il post,spero di non averlo perso nel trasferimento del blog), c’è un probabile rischio di trusting computing derivante proprio dal fatto che il dispositivo possiede probabilmente il chip Fritz! (http://it.wikipedia.org/wiki/Fritz-chip). Vada per le implementazioni, ma cosa ne pensi di questi sistemi ?

  3. Io possiedo un Fritz!Wlan e lo trovo molto semplice da utilizzare ed efficiente. Non ho approfondito, ma non penso che Fritz! si riferisca al vecchio Palladium o, più in generale, al TC. Sul sito di avm leggo:

    When you use FRITZ!Box Fon for Internet telephony, you are protected even against eavesdroppers in your own network. When you connect your analog telephones or ISDN terminal equipment to FRITZ!Box Fon or FRITZ!Box Fon WLAN, no voice data enters the local-area network that you set up with the FRITZ!Box Fon router. This means that even a computer directly connected to FRITZ!Box Fon cannot eavesdrop on Internet phone calls.

    Il che è già una buona cosa. Sempre se si ha una wlan, è consigliabile crittografare i dati con WPA2, ma per il segnale, una volta lasciato il router, c’è poco da fare se il fornitore del servizio non ha implementato un qualche tipo di connessione protetta.

    Il che, però, pone di fronte allo stesso problema che si ha con una connessione SMTP criptata: i dati sono protetti dal router al server, ma non si sa mai cosa si ha fra server e il destinatario della comunicazione.

    Una soluzione potrebbe essere quella adottata dai mixmaster, con pacchetti armored a dimensione fissa, ma è inapplicabile così com’e’, dato che non assicurerebbe una comunicazione realtime.

    In realtà si dovrebbe avere un circuito chiuso crittografato e forse, man in the middle a parte, qualcosa in piu’ si avrebbe, ma rimarrebbe aperto il problema della privacy: il contenuto non sarebbe leggibile, ma la connessione tracciabile fra gli end point.

  4. Si, in effetti è una ottima soluzione, ricevetti tempo fa sul blog alcune segnalazioni in tal senso per il chip ma non ne posso ovviamente verificare l’esattezza.
    Il problema quindi secondo te è nettamente a monte ed a quanto pare difficilmente risolvibile se non con implementazioni rigide. I Pacchetti a dimensione fissa sono davvero inapplicabili, sono usati nei remailer vero ? Mi farebbe piacere se sviluppassi nel tuo blog, insieme magari ad Andrea questi temi: rendere più semplici queste tematiche può facilitare gli utenti (magari con qualche graph), non solo nell’acquisto, ma anche nel farsi un idea propria su quali sono i problemi da affrontare. Se hai GTalk aggiungimi pure, ti ringrazio per i contributi preziosi.

  5. E dire che Andrea mi aveva suggerito di preparare in intervento sul VoIP per il Barcaamp di Torino.

    Si, i remailer anonimi adottano, fra le altre, un paio di tecniche per mascherare chi ha spedito cosa: da una parte pacchetti di dimensioni fisse, in modo da annullare qualsiasi tentativo di applicare una statistica sulle dimensioni tipiche, dall’altra i pacchetti vengono deserializzati e spediti in tempi diversi, in modo che non sia possibile ricostruire una catena, seppure crittata, di pacchetti appartenenti a uno stesso messaggio.

    In un ambiente in cui si privilegia un protocollo come UDP, poco performante e molto “intasatore”, per consentire la velocità piu’ spinta per i pacchetti multimediali, mi sembra difficile deserializzare una comunicazione, mantenendone la qualità.

    Il problema consiste nell’affrontare almeno 2 ordini di problemi:

    1. Riconoscimento dei punti finali: per garantire la privacy delle chiamate, bisognerebbe rendere impossibile ricondurre un circuito a due endpoint precisi. Aspetto, però, che non viene affrontato nemmeno nella telefonia tradizionale, nella quale almeno l’operatore sa chi chiama chi. Nei remailer anonimi nessun nodo ha un orizzonte di visibilità che supera il nodo che lo precede e che quindi gli ha fornito il pacchetto e quello che lo segue, cui consegnerà il pacchetto.

    2. Chiusura del circuito in uno strato isolato. Le tecniche sono differenti, ma il discorso è simile a una vpn road warrior: la rete va considerata insicura a ogni punto finale e va chiusa in uno strato che la isoli e la cripti, in modo da garantire la riservatezza delle informazioni.

    3. Se poi vogliamo usare le chiavi asimmetriche per stabilire univocamente l’identità dei punti finali, avremmo un canale riservato e autenticato, il che consentirà di assicurarci della identità dell’estremo con cui si è in contatto, grazie all’utilizzo di chiavi firmate.

    Ci si dovrebbe riflettere sopra.

  6. Eheh un intervento al Barcamp sarebbe stato di certo prezioso. Forse i problemi di cui parliamo non si risolveranno così tanto presto proprio per il carattere progettuale del Net: in che punto infatti chiudere ed isolare ? Vedo più le chiavi asimmetriche come soluzione più vicina ed attuabile soprattutto per il VoIP, algoritmi di codifica: chissà cosa ne pensa Phil Zimmermann che sta sviluppando da tempo Zfone.
    C’è poi un ulteriore aspetto: parlerò di un tema abbastanza interessante,ovvero di come intercettare il VoIP, di alcune regolamentazioni ed aspetti. A tal proposito mi farebbe piacere una tua mano per affrontare meglio il problema.

Comments are closed.