Telefonia IP to atrakcyjny pomysł na obniżkę kosztów lub wprowadzenie usług uniwersalnej komunikacji. Źle zabezpieczone usługi głosowe w sieci IP to jednak tykająca bomba.

Motorem obserwowanego obecnie dynamicznego rozwoju telefonii IP jest chęć obniżenia kosztów telekomunikacji. Dążenie do oszczędności na skróty może jednak łatwo prowadzić do strat. Telefonia IP nie jest, wbrew temu, co chcielibyśmy o niej myśleć, rozwiązaniem bezpiecznym. Dotyczy to zarówno sfery czysto telefonicznej, jak i faktu, że telefonia IP wykorzystuje sieci transmisji danych. Oczywiste konsekwencje dla bezpieczeństwa ma także fakt, że telefonia IP zasadza się w dużej mierze na rozwiązaniach programowych.

Groźnie na każdym kroku

Zabezpieczenie usług telefonii IP działających wewnątrz firmowego intranetu jest stosunkowo łatwe - pod warunkiem wykorzystania architektury sieci przełączanych oraz odpowiedniego zabezpieczenia dostępu do przełączników. Telefonia IP jest jednak wykorzystywana głównie do łączności ze światem zewnętrznym i zabezpieczenie tej właśnie sfery stanowi największe wyzwanie.

Ponadto usługi VoIP są często uruchamiane na powszechnie znanych, a ponadto w pełni funkcjonalnych (nieokrojonych do minimum) systemach operacyjnych. To wręcz jawne zaproszenie do ataku.

Wykorzystywany przez telefonię IP do transportu głosu protokół IP powoduje, że usługi telekomunikacyjne nowej generacji są narażone na wszystkie znane ataki wymierzone w ten protokół. Prawdopodobieństwo włamania do sieci IP jest większe niż w przypadku sieci PSTN - choćby z tego powodu, że sieci IP są znacznie bardziej dostępne dla potencjalnych włamywaczy. W sieciach tych kryje się ponadto dużo więcej zasobów interesujących potencjalnych włamywaczy niż w sieciach telefonicznych.

W kontekście telefonii IP można jak najbardziej mówić o atakach uniemożliwiających korzystanie z usług (denial of service), podszywaniu się (spoofing), przejmowaniu sesji (man in the middle), a nawet złośliwych atakach na mechanizmy QoS, powodujących zakłócenia transmisji przez wprowadzenie zmiennych opóźnień czy też prowadzących do rozsynchronizowania sesji. Oprócz tego możliwa jest kradzież tożsamości użytkowników i urządzeń, np. w celu nieautoryzowanego korzystania z usług telefonicznych na koszt ofiary.

Do tego dochodzą ataki skierowane przeciw specyficznym dla telefonii IP protokołom sygnalizacyjnym - H.323 i SIP i protokołom kontrolującym przepływ danych - RTS (Realtime Transport Protocol), RTCP (Realtime Control Protocol) i SCTP (Stream Control Transmission Protocol). Zagrożenie polega tu na możliwości podsłuchania komunikacji lub nieautoryzowanym korzystaniu z usług telefonicznych na koszt organizacji-ofiary, ale również na wykorzystaniu luki w rozwiązaniu telefonicznym do ataku na inne usługi, systemy i dane.

We sieciach PSTN informacje sterujące (sygnalizacja) są przesyłane na większej części dystansu między komunikującymi się stronami poprzez oddzielne łącza fizyczne. W telefonii IP strumień danych jest również oddzielony od sygnalizacji, jednak w większości przypadków oba strumienie płyną tym samym łączem fizycznym, co stwarza zagrożenie.

Bezpieczeństwu usług telefonii IP nie służą: konstrukcja i sposób działania sieci IP. Dane sterujące sesją oraz treść komunikacji w telefonii IP podczas przebywania drogi do wskazanego adresata będą wędrować przez sieci IP kontrolowane przez różne organizacje - dostawców Internetu, firmy telekomunikacyjne oraz wiele odcinków "niczyich".

Protokoły a bezpieczeństwo

Podczas projektowania protokołów wykorzystywanych w telefonii IP bezpieczeństwo ich użytkowania często nie było priorytetowym ani nawet jednym z głównych celów ich twórców. Część ewidentnych braków w kwestii bezpieczeństwa usunięto w nowszych wersjach, jednak nie wszystkie.Weźmy np. szyfrowanie. Każdy algorytm szyfrujący wprowadza do strumienia głosowego dodatkowe dane, których odsiewanie po stronie odbiorcy pogarsza jakość głosu - także poprzez fakt, że zwiększa się opóźnienie. W tym świetle zalecenie IETF, aby strumień danych szyfrować za pomocą mało efektywnego (zwłaszcza w rozwiązaniach czysto programowych) algorytmu 3DES, stoi w sprzeczności z potrzebą komunikacji w czasie rzeczywistym. Stworzenie kanału VPN - nawet opartego na rozwiązaniach sprzętowych - niewiele tu pomoże. Kilka równoległych strumieni RTP/IPsec skutecznie obniża jakość dźwięku.