Bezpečnostní prvky IP telefonů Cisco se signalizací SIP a jejich kompatibilita

Bezpečnostní prvky IP telefonů Cisco se signalizací SIP a jejich kompatibilita Filip Řezáč, František Šimoňák Abstrakt: Tento dokument pojednává obecně o momentálně nejvíce rozšířených metodách zabezpečení IP telefonie a zkoumá, jak tyto metody a technologie podporují IP telefony Cisco. Je zde stručně vysvětlen princip těchto bezpečnostních metod a jak jsou tyto metody rozšířeny prakticky. V praktické části je poté vyzkoušena podpora bezpečnostních mechanismů na telefonu Cisco 7911G s podporou SIP protokolu oproti jiným koncovým zařízením pro IP telefonii. Klíčová slova: Cisco, VoIP, SCCP, SIP, RTP, SRTP, ZRTP, autentizace, integrita, bezpečnost 1 Úvod.............................................................................................................................2 2 Signalizační protokoly..................................................................................................2 2.1 SIP (Session Initiation Protocol)...........................................................................2 2.2 SCCP (Skinny Call Control Protocol)..................................................................6 3 Bezpečnostní mechanismy...........................................................................................6 3.2 Zabezpečení transportních protokolů....................................................................7 4 Flash firmwaru na SIP signalizaci................................................................................8 5 Testování zabezpečení a kompability telefonu.............................................................9 5.1 Připojení k ústředně přes zabezpečenou signalizaci...........................................10 5.2 Připojení k ústředně přes nezabezpečenou signalizaci a test šifrování data streamu........................................................................................................................12 5.3 Připojení přes Direct Call....................................................................................14 6 Závěr...........................................................................................................................15 7 Použitá literatura.........................................................................................................15 A) Příloha – Konfigurační soubor SEP <mac adresa telefonu> .cnf.xml .......................15

2.12.2008

1/18

1 Úvod VoIP – tato technologie se v dnešní době stává trendem v oblasti telekomunikačních a internetových služeb a tím pádem i středem zájmu různých internetových providerů. Ale co si vlastně pod pojmem VoIP představit? Po globálním nástupu Internetu v 90. letech se objevily různé komunikační technologie pro přenos dat, které tuto obrovskou datovou síť využívaly. Největší výhodou těchto přenosů bylo a je, že jsou zdarma. Po přenosu textu přes nám známé technologie jako je e-mail, Instant Messaging a podobné, přišel konečně na řadu přenos hlasu a telefonování přes Internet. Jenomže stejně jako u jiných technologií nám musí být známa i určitá pravidla a bezpečnost, bez kterých se provoz této technologie neobejde. V tomto projektu máme za úkol otestovat, jakým způsobem a v jakém rozsahu jsou bezpečnostní mechanismy podprorovány u IP telefonů firmy Cisco a to po nahrání firmwaru podporujícího signalizaci SIP. Dále máme za úkol zjistit jak je takový telefon s novým SIP firmwarem kompatibilní s ostatními koncovými zařízeními v rámci bezpečnostních technik. V druhé kapitole se zaměříme na popis základních charakteristik a rozdílů v signalizaci používané u Cisco telefonů (SCCP) a signalizace SIP. Třetí kapitola bude obsahovat popis nejpoužívanějších metod pro zabezpečení signalizace a samotných dat. Ve čvrté kapitole bude popsáno nahrání firmwaru do telefonu Cisco s podporou signalizace SIP a v páté kapitole provedeme samotné testy kompatibility a podpory zabezpečení.

2 Signalizační protokoly Signalizační protokoly ve VoIP slouží ke komunikaci mezi jednotlivými komponenty v síti jako jsou VoIP servery, koncové terminály, brány a zařízení pro multimediální konference. Tyto protokoly domlouvají způsob přenosu dat, jaký kodek bude využit a také jaké zabezpečení bude implementováno. V praxi se používá několik signalizačních protokolů, ale tím nejznámějším a nejvíce podporovaným v oblasti volně šířítelných je protokol SIP. Na druhé straně potom stojí protokol vlastněný společnosti Cisco - SCCP.

2.1 SIP (Session Initiation Protocol) Strukturově je SIP [1, 2] protokol hodně podobný například SMTP (Simple Mail Transfer Protocol). Je mnohem jednodušší než jiný signalizační protokol H.323, který ke své funkci potřebuje další protokoly. SIP je textový protokol, což napomáhá nejen jednoduchému ladění, ale především je snadno rozšiřitelný. Protokol SIP je typu klient-server, to znamená, že komunikace probíhá výměnou dvou typů zpráv, požadavků a odpovědí. Pod slovem klient si můžeme představit IP telefon nebo softwarovou aplikaci na počítači u uživatele a pojmem server je označen aplikační server služeb. Pod tímto pojmem si můžeme představit různá softwarová či hardwarová řešení VoIP ústředen jako například: Asterisk, OpenSER atd.. SIP lze využít i jako protokol na provoz síťových her či Instant Messagingu, ale převážně se používá ve službách VoIP. Typy požadavků - První položka požadavku je takzvaná metoda, poté je uvedeno, zda budeme posílat požadavek klientovi (v případě odpovědi) nebo serveru (Request-URI) a verze protokolu (obr 2.4). Jednotlivé důležité metody požadavku: INVITE: Metoda INVITE slouží k přizvání uživatele nebo služby k podílení se na relaci. Tělo zprávy obsahuje popis relace (spojení). ACK: Metoda ACK potvrzuje, že klient v pořádku přijal odpověď na INVITE dotaz. BYE: Klient používá metodu BYE k oznámení protistraně, že hodlá ukončit hovor. Metoda BYE může být vyslána jak volaným, tak volajícím. CANCEL: Metoda CANCEL ukončuje nevyřízený požadavek se stejnou identifikací, tedy položkami Call-ID, To, From a pořadovým číslem požadavku Cseq. Vyřízené požadavky již metoda CANCEL neovlivní (požadavek je vyřízen, pokud byla odeslána konečná odpověď, např. 200 OK). REGISTER: Metoda REGISTER je používána k registraci současné adresy klienta u SIP serveru, 2.12.2008

2/18

který jí předá lokalizační službě. Typy odpovědí – odpovědi jsou kódy, kdy každý označuje nějakou událost či na šest kategorií podle události, kterou signalizují:

potvrzení. Odpovědi se dělí

1xx: Prozatímní odpovědi jako požadavek přijat, vyzvání, informační sdělení. 2xx: Úspěch. Požadavek je přijat, pochopen a akceptován. 3xx: Přesměrování. Je třeba vytvořit nový upravený požadavek. 4xx: Chyba klienta. Špatná syntaxe požadavku, nebo požadavek nemůže být proveden. 5xx: Chyba serveru. Server není schopen provést platný požadavek. 6xx: Globální chyba. Požadavek nelze provést na žádném serveru. Odpovědi s kódem 200 a výše jsou konečné, jejich přijetí ukončuje transakci. Ukázkovou transakci SIP protokolu můžeme vidět na obrázku 1.

Obrázek 1. Ukázková transakce protokolu SIP Důležité hlavičky SIP – Pakety se skládají z hlavičky a vlastních dat. Hlavička paketu obsahuje informace o spojení (použití protokol, TTL, zdrojová a cílová adresa atd..)Existuje mnoho různých hlaviček, toto je výběr těch nejpoužívanějších. To: Adresa volaného From: Adresa volajícího klienta Via: Adresa klienta, který vysílá požadavek nebo adresa serverů, přes něž požadavek prošel a kudy se bude vracet odpověď Call-Id: Unikátní identifikace volání Contact: Aktuální skutečná adresa klienta Record-Route: Seznam adres serverů, přes které probíháji transakce Route: Posloupnost adres serverů, přes které je požadavek směrován, a klienta, ke kterému má požadavek dorazit Request-URI: Aktuální adresát požadavku. Údaj se vyskytuje v první řádce požadavku za metodou (typem požadavku) Ukázka struktury SIP sítě je na obrázku 2.

2.12.2008

3/18

Obrázek 2. Struktura SIP sítě Registrace – Proces registrace začíná požadavkem REGISTER a pokud je úspěšný, dostane se mu odpovědi 200 - OK (obrázek 3.). Adresa v položce To s adresou v položce Contact vytvoří v registračním serveru časově omezený záznam, který se předá lokalizační službě.Tato informace nám zaručí, že lokalizační služba najde uživatele nezávisle na poloze klienta.

Obrázek 3. Registrace na protokolu SIP Navázání a ukončení spojení - Spojení je navazováno pomocí procedury, která je označována jako „threeway handshake“. Pokud chce klient A komunikovat s klientem B, pošle požadavek INVITE (1), který obsahuje popis spojení. Pokud zpráva dojde v pořádku k B, klient B pošle takzvaný vyzváněcí tón uživateli A (100 TRYING, 180 RINGING), jinak také prozatímní odpověď. Pokud se klient B rozhodne hovor přijmout, vyšle zpět odpověď 200 OK. Odpověď OK obsahuje kodeky, adresy IP a čísla portů, na kterých bude klient B očekávat data od protistrany. Závěrem pošle klient A potvrzení odpovědi klientu B a to zprávou ACK. Navazování spojení je hotovo a může začít samotný hovor. Pokud chce některý z účastníků hovor ukončit, pošle protistraně požadavek BYE (4), který bude potvrzen odpovědí 200 OK (5) (Obrázek 4).

2.12.2008

4/18

Obrázek 4. Navázání spojení mezi dvěma body Pokud spojení probíhá za účasti serveru SIP, předpokládáme, že je účastník u serveru registrován. Klient A v tomto případě posílá INVITE na server a ten se snaží zjistit aktuální polohu volaného B. Když je zjištěna poloha, server podle toho, v jakém pracuje módu (redirect nebo proxy), buď pošle informaci o poloze klienta B klientovi A a klient sám naváže spojení bez pomoci serveru (redirect mód) anebo server zprávu INVITE upraví a posílá ji směrem ke klientovi B sám (proxy mód). Odpověď 200 OK se vrací ještě přes server, ale všechny další zprávy už si A a B vyměňují přímo (Obrázek 5). Pro dohodnutí parametrů přenosu se používá SDP.

Obrázek 5. Navázání spojení přes server

2.12.2008

5/18

2.2 SCCP (Skinny Call Control Protocol) Skinny Call Control Protocol [3] je patentovaný protokol původně vytvořený společností Selsius. Na rozdíl od SIP je SCCP vlastněn společností Cisco a tento protokol slouží pro komunikaci mezi SCCP klientem (Cisco telefony) a Cisco CallManagerem. CallManager je IP ústředna společnosti Cisco. Tento protokol je často označován také jako Skinny. Setkáme se s ním u většiny IP produktů firmy Cisco. Call Manager je alfou a omegou Cisco IP telefonie. Veškeré požadavky a komunikaci mezi Cisco IP telefony s SCCP protokolem řídí právě Call Manager. Taktéž veškerá nastavení, ať už bezpečnostní či jiná jsou iniciována touto ústřednou. Call Manager také dokáže vytvářet konfigurační a jiné potřebné soubory pro Cisco IP telefony. Obsah těchto souboru a jejich funkce je uvedena níže v kapitole 4.

3 Bezpečnostní mechanismy Protokoly používané ve VoIP jsou ve své základní podobě nechráněny a neobsahují žádné zabezpečující mechanizmy, které by zamezily útočníkovi v přístupu k údajům či datovému obsahu přenosu. Proto bylo nutností navrhnout různé techniky zabezpečení, jak pro transportní, tak i pro signalizační protokoly. V této kapitole stručně popíšeme a charakterizujeme nejpoužívanější z těchto metod.

3.1 Zabezpečení signalizačních protokolů Signalizační protokoly slouží k vytvoření, správě a řízení telefonní komunikace mezi účastníky. Samotné signalizační protokoly nemají žádné bezpečnostní ochrany proti případným útokům. Jsou však definovány bezpečnostní mechanismy, které využívají již jednou vytvořené standardy. Jelikož jsme testovali zabezpečení pouze signalizačního protokolu SIP, budou uvedeny bezpečnostní metody pouze pro tento protokol [4].

3.1.1 HTTP Digest Authentication Využívá metody Basic Authentication s tím rozdílem, že místo přenosu otevřeného hesla přenáší otisk vytvořený pomocí hashovací funkce MD5. Ta funguje tak, že heslo vytvoří z náhodně generovaného řetězce, loginu a hesla. Tato metoda ověřuje autenticitu na základě sdíleného hesla. Obsah zprávy se však nijak nešifruje.

3.1.2 Secure MIME (S/MIME)

Z názvu vyplývá, že se jedná o zabezpečení tzv. MIME (Multipurpose Internet Mail Extension). Konkrétně tato metoda zabezpečí obsah zprávy a zaručí i její integritu. Existuji dva způsoby šifrování obsahu dat MIME. První : application/pkcs7-mime dokáže digitálně podepsat a zašifrovat data. Druhý : multipart/signed je podobný jako první, s tím rozdílem, že zpráva obsahuje šifrovaná i nešifrovaná data. K ověření autentizace se používá architektura veřejných klíčů (PKI). Pro utajení obsahu zprávy jsou využity symetrické kryptografické algoritmy (DES, 3DES, AES).

3.1.3 SIPS URI (TLS) Další metoda využívající architektury veřejných klíčů pro ověření autentizace je tzv. metoda SIPS (SIP Security). Při použití této metody se mění prefix identifikační hlavičky na sips. To znamená, že při volání SIP adresy telefonu zadáme: sips:. Aby byla zaručená bezpečná komunikace, používá tato metoda šifrovaný protokol Transfer Layer Security (TLS). Tento protokol využívá asymetrické šifrování (RSA), symetrické algoritmy (DES, 3DES, AES) a hashovací funkce SHA1 a MD5. Při použití této metody je kladena podmínka, že protokol TLS je použit na celé cestě zprávy a pro SIP musí být použit protokol TCP.

2.12.2008

6/18

3.2 Zabezpečení transportních protokolů U transportních protokolů a jejich zabezpečení musíme hlavně brát zřetel na to, že komunikace pomocí těchto protokolů probíhá v reálném čase, proto i zabezpečovací techniky musí byt implementovány tak, aby vznikalo minimální časové zpoždění. Stejně jako u signalizačních protokolů, tak ani nejpoužívanější transportní protokol Real-time Transport Protocol (RTP) neobsahuje ve svém základu žádné ochranné metody či mechanizmy, proto byl definován protokol SRTP (Secure Real-time Transport Protocol), který již tyto metody má implementovány. Zmíníme i poměrně nový protokol ZRTP (Zimmermann Real-time Transport Protocol), který má sloužit jako nadstavba pro SRTP a jeho snadnější použití a implementaci.

3.2.1 SRTP SRTP [5] není protokol sám o sobě, ale pouze rozšiřuje o bezpečnostní mechanismy protokol RTP. Konkrétně těmito bezpečnostními mechanismy máme na mysli podporu kontroly integrity, ověření autenticity, zaručení důvěrnosti a je také zavedena ochrana proti přeposílání (replay). Protokolu SRTP byl přidělen komunikační port 5004, SRTCP port 5005. Strukturu SRTP paketu vidíme na obrázku 6.

Obrázek 6.Struktura paketu SRTP Důvěrnost přenášených dat v paketu zajišťuje kryptografický algoritmus AES, a autentizaci algoritmus HMAC-SHA-1. Prakticky SRTP přidává ochranu k nezabezpečenému transportnímu protokolu RTP a jak už bylo napsáno výše, zaručuje jeho integritu, důvěru a ověření autenticity.

3.2.2 ZRTP Protokol ZRTP (Zimmermann Real-time Transport Protocol) [6] byl představen poměrně nedávno jako nástavba pro již zavedený a hojně používaný SRTP. ZRTP rozšiřuje tento protokol o mechanismy pro počáteční výměnu symetrických klíčů a dokáže chránit i proti útokům zvaných jako „Man in the middle“. ZRTP při výměně klíčů používá Diffie-Hellmanův algoritmus. Ten funguje tak, že vypočte hashe několika utajovaných hodnot včetně krátkého autentizačního řetězce. Tato vypočtená hodnota je použita pouze jednou, její část se však ukládá pro budoucí spojení.

2.12.2008

7/18

4 Flash firmwaru na SIP signalizaci Po nastudování potřebného „know-how“ jsme se rozhodli přikročit k pratkické části našeho projektu. Pro nahrání firmwaru a pro následné testování jsme si vybrali IP telefon Cisco 7911G [7]. Jedná se o typického zástupce nižší řady VoIP Cisco koncových zařízení, který podporuje signalizaci na protokolu SCCP a jako VoIP ústřednu upřednostňuje Cisco Call Manager. Abychom na zařízení mohli otestovat zabezpečení a kompatibilitu s ostatními telefony, bylo nutné nejprve nahrát nový firmware telefonu, který podporuje signalizaci přes protokol SIP. Pro testování jsme použili akruálně dostupnou verzi sip.8-4-1ES2.

Obrázek 7. IP telefon Cisco 7911 Pokud má telefon nastavenou adresu TFTP serveru, kontroluje po každém restartu, zda se na TFTP nenachází verze novejšího firmwaru a pokud ano, začne s aktualizací. Verzi firmwaru zjišťuje s pomocí XML konfiguračního souboru, který si opět po každém restartu nahrává z TFTP serveru. Dále je popsán postuppřehrání firmwaru z SCCP na verzi SIP. Postup flashnutí firmwaru:

1.

Nejprve si musíme v naší síti nainstalovat nějaký TFTP server, na kterém bude uložen soubor s firmwarem a konfigurační soubory. My jsme využili TFTP server pod OS Windows s názvem PumpKIN TFTP server (obrázek 8) . 2. Poté je nutné stáhnout z webových stránek Cisco příslušný firmware, v našem případě to byla verze: 7911 sip.8-4-1ES2 . 3. Kromě firmwaru je dobré mít na TFTP serveru nahrané konfigurační soubory. Jejich příklady můžeme nalézt na různých fórech zabývajících se touto problematikou a příklad konfiguračního souboru je uveden i v příloze: 1. SEP <mac adresa telefonu> .cnf.xml – základní soubor s konfigurací telefonu 2. DRdialplan.xml – číslovací plán 3. CTLSEP <mac adresa telefonu>.tlv - seznam serveru pro které bude použito zabezpečení a pro které ne a jaký typ 4. tc-sip.jar , g3-tones.xml – konfiguracní soubory pro nastavení lokalizace a místních tónů telefonu (nepovinný) 4. Nastavíme telefonu IP adresu,masku a bránu ze stejné podsítě jako je TFTP server, ať máme jistotu, že se zařízení k TFTP bez problémů připojí. Menu->Setting->Network->IPv4->IP Address 5. Nastavíme v telefonu IP adresu TFTP serveru Menu->Setting->Network->IPv4->TFTP Server (Je nutné odemknout změny telefonu pomocí kombinace na klávesnici: **# ) 6. Telefon vyresetujeme vytažením napájecího konektoru a znovu zasunutím do napájecí zdířky.

7.

Při restartu si telefon stáhne z TFTP nejprve soubor SEP <mac adresa telefonu> .cnf.xml a poté začne stahovat firmware. Průběh instalace můžeme sledovat na displeji telefonu. 8. Telefon se po stáhnutí nového firmwaru restartuje a instalace proběhne ještě jednou z námi neznámého důvodu. 9. Po druhém restartu je však telefon flashnutý a připraven k provozu. 2.12.2008

8/18

Obrázek 8. TFTP server PumpKIN a přehled stahování konf. souborů telefonem Nyní již můžeme v konfiguračním souboru nastavit samotnou adresu SIP proxy serveru, a SIP účty. Při našem testu se však bohužel ukázalo, že jsme přehrátím softwaru ztratili možnost upravovat některá nastavení zařízení přímo na telefonu. Konfigurace byla možná pouze pomocí editace již zmíněného konfiguračního souboru SEP <mac adresa telefonu> .cnf.xml.a opětovného nahrátí přes TFTP server do telefonu. Telefon si soubor nahraje automaticky po restartování (vytažení a opětovné zasunutí napájecího konektoru). Adresu SIP proxy serveru nastavíme v následujících položkách konfiguračního souboru: <processNodeName>

a

<proxy>

A SIP účty v těchto položkách: jméno které se bude zobrazovat na displeji název účtu jméno které se bude zobrazovat volanému login účtu heslo

5 Testování zabezpečení a kompability telefonu Prvním z našich úkolů bylo otestovat, zda se Cisco telefon přihlásí přes zabezpečenou autentizaci ke školní ústředně Asterisk. Druhým úkolem bylo otestování nešifrovaného hovoru a potom případně hovoru šifrovaného. Při testech hovorů byl na druhé straně účastníka zastoupen jiný telefon než Cisco, abychom vyzkoušeli kompatibilitu zařízení. Nakonec jsme testovali přímé volání bez využití VoIP SIP ústředny. K testování jsme kromě telefonu Cisco využili SW IP telefon SJphone a HW IP telefon Grandstream GXP 2000. Všechny telefony byly propojeny přes hub, abychom mohli pomocí programu Wireshark sledovat provoz v síti. Všechny telefony byly navíc nastaveny, aby komunikovaly přes SIP proxy server a ústřednu v jednom stroji – Asterisk. Ten se nachází na adrese asterisk.vsb.cz a slouží jako školní ústředna pro IP telefonii. K síti byl navíc připojen počítač, který sloužil jako TFTP server a notebook pro sledování síťového provozu. Topologii můžeme vidět na obrázku 9.

2.12.2008

9/18

Obrázek 9. Topologie sítě Na obrázku nejsou záměrně uvedeny IP adresy jednotlivých zařízení (kromě Asterisk PBX), jelikož se topologie postupem testování měnila a IP adresy by né vždy odpovídaly skutečnosti. Našim cílem bylo pozorovat komunikaci v této síti a převážně komunikaci Cisco IP telefonu.

5.1 Připojení k ústředně přes zabezpečenou signalizaci V prvním testu jsme náš Cisco telefon chtěli registrovat k SIP proxy tak, aby dostal předem vytvořený účet. Ústředna má nastavené zabezpečení SIP signalizace přes Digest Authentication. Na našem telefonu jsme chtěli zatím nechat zabezpečení vypnuté, proto jsme museli v konfiguračním souboru SEP <mac adresa telefonu> .cnf.xml nastavit hodnotu zabezpečení na 0 (Obrázek 10) .

Obrázek 10. Nastavení zabezpečení Cisco telefonu Dále bylo nutné v konfiguračním souboru nastavit pro telefon účet, heslo a adresu SIP ústředny , aby se telefon mohl úspěšně zaregistrovat. Obsah celého použitého konfiguračního souboru je uveden v příloze A. Poté jsme zařízení restartovali a telefon si nahrál konfigurační soubor z TFTP serveru.Hned poté se snažil registrovat k ústředně, jak můžeme vidět na odchycených paketech:

2.12.2008

10/18

Obrázek 11. Snaha Cisco telefonu o registraci na ústřednu Telefon se samozřejmě k ústředně neregistruje, protože posílá stále nezabezpečený paket s metodou REGISTER a ústředna vyžaduje zabezpečení typu Digest Authentication.To, jaký typ zabezpečení ústředna vyžaduje posílá telefonu v paketu 401 Unauthorized. Zkusili jsme se připojit k ústředně i se SW telefonem SJPhone, který měl podporu zabezpečené signalizace povolen (Obrázek 12).

Obrázek 12. Úspěšná registrace Sjphonu na ústřednu Vidíme, že ústředná odmítne první pokus o registraci Sjphonu, ale druhý pokus již přijme a telefon registruje. Co se změnilo? Druhý SIP paket s metodou REGISTER obsahoval již zabezpečenou autentizaci pomocí hashovací funkce MD5, tak jak to vyžadovala ústředna. Tuto zabezpečenou autentizaci můžeme vidět na obrázku 13. V paketu REGISTER vidíme povolenou autentizaci pomocí metody Digest. Vidíme dále login účtu 7081 ,doménu asterisk a autentizační adresu asterisk.vsb.cz.

Obrázek 13. Autentizace pomocí metody Digest Authentication My jsme samozřejmě chtěli otestovat, zda Cisco telefon ze SIP firmwarem toto zabezpečení taky umí. Proto jsme v konfiguračním souboru v kolonce DeviceSecurityMode nastavili pro zabezpečení hodnotu 2 (Obrázek 14). Proč zrovna dva? Jelikož jsme popis k danné tématice (nastavení zabezpečení) nikde nenašli, byli jsme nuceni metodou pokus a omyl zjistit, jakým hodnotám odpovídá jaké nastavení zabezpečení telefonu. 0 – žádné 1 – žádné 2 – zabezpečená signalizace 3 – zabezpečený transport dat

2.12.2008

11/18

Obrázek 14. Nastavení zabezpečení Cisco telefonu Telefon jsme opět restartovali, počkali až si z TFTP serveru nahraje konfigurační soubor a poté jsme začali odchytávat registraci na ústřednu. Bohužel jsme dostali stejný výsledek jako na obrázku 11. Telefon stále posílal nezabezpečené autentizační údaje přes metodu REGISTER. Rozhodli jsme se proto projít logy, které si telefon vytváří právě z důvodu případného řešení problému. V logu jsme našli mimo jiné tuto informaci:

To znamená, že telefon nemohl nastavit zabezpečenou autentizaci, jelikož nemá soubor CTL. Tento soubor, jak už bylo řečeno výše, obsahuje záznamy, ke kterým serverům se má telefon přihlašovat nezabezpečeným způsobem a ke kterým použít zabezpečení. Tento soubor si také telefon při restartu vyžaduje stáhnout z TFTP serveru. Pokud ho nemáme (jako v našem případě) telefon nabootuje bez něho. Zapátrali jsme na Internetu jak by obsah tohoto souboru měl vypadat, ale bohužel ani na stránkách Cisco, ani na všemožných fórech jsme nenašli jakoukoliv stopu, jak by měl obsah vypadat. Někteří přispěvatelé píší, že tento soubor není potřeba a pokud ho telefon vyžaduje vytvořte ho, ale ponechte ho bez obsahu tj. prázdný. Vyzkoušeli jsme tuto možnost a vytvořili soubor CTLSEP <mac adresa telefonu>.tlv . Bohužel telefon tento prázdný soubor při bootu ignoroval a napsal, že na TFTP serveru soubor nenašel. Tímto jsme se dostali do slepé uličky, jelikož jsme nedokázali telefon donutit, aby vysílal v paketech zabezpečenou signalizaci.

5.2 Připojení k ústředně přes nezabezpečenou signalizaci a test šifrování data streamu Protože jsme se nechtěli tak brzo vzdát, rozhodli jsme se, že budeme pokračovat jinou cestou a nainstalujeme si svou vlastní ústřednu u které vypneme zabezpečenou autentizaci. Cisco telefon se na tuto ústřednu registruje a vyzkoušíme alespoň nešifrovaný hovor s jiným zařízením – v našem případě HW IP telefonem Grandstream GXP 2000, nebo SW klientem Sjphone. V plánu bylo i po úspěšném nešifrovaném hovoru vyzkoušet hovor šifrovaný pomocí SRTP. Jelikož jsme se v předchozím kroku nepřipojili na školní ústřednu, která vyžaduje šifrovanou autentizaci, zkusíme se připojit na námi vytvořenou ústřednu, kde bude autentizace vypnuta. Prvním krokem bylo tedy nainstalovat novou SIP ústřednu a zároveň SIP proxy server, u kterého bychom mohli editovat nastavení. Zvolili jsme komplexní balík Trixbox, jenž obsahuje operační systém Linux CentOS, ústřednu Asterisk a webové rozhraní Trixbox pro její nastavení. Využili jsme počítač, kde nám běžel Wireshark a nainstalovali jsme tento systém jako virtuální PC pomocí aplikace VMware. Kompletní návod na instalaci Trixboxu a nakonfigurování ústředny naleznete zde:

2.12.2008

12/18

http://homel.vsb.cz/~voz29/files/TRIXBOX/Trixbox-navod.html V ústředně jsme si vytvořili několik zkušebních účtů, na které se mohly telefony přihlašovat.V konfiguračním souboru Cisco telefonu jsme museli změnit adresu SIP ústředny a SIP proxy na adresu počítače a nové ústředny. Konkrétně to jsou položky: <processNodeName>

a

<proxy>

Nyní jsme opět restartovali telefon, nechali si ho nahrát konfiguraci z TFTP serveru a čekali co, provede. Ústředna opravdu přijala požadavek na registraci a telefon zaregistrovala. Jednalo se o první pozitivní krok v našich testech.

Obrázek 15. Registrace Cisco telefonu na nezabezpečenou ústřednu Telefon sice zaregistroval, ale vůbec neodpovídal na další komunikaci s ústřednou. Pouze stále dokola posílal SIP zprávy s metodou REGISTER a snažil se opětovně registrovat. To můžeme vidět na obrázku 15, kdy je telefon na adrese 158.196.81.104 a ústředna na 158.196.81.107 . Když jsme se podívali na logy ústředny, viděli jsme, že telefon je sice přihlášeny, ale jelikož neodpovídá na jakoukoliv komunikaci ze strany ústředny, je označen jako UNREACHABLE (nedostupný)(Obrázek 16). Můžeme si ještě všímnout, že oproti ostatním připojeným telefon k ústředně používá Cisco telefon pro SIP signalizaci port 49159 místo standardně používaného 5060. To však nemá na komunikaci žádný vliv.

Obrázek 16. Přehled registrovaných a dostupných telefonů na ústředně Asterisk Tímto výsledkem jsme lidově nad SIP firmwarem v telefonu Cisco 7911 zlomili hůl, jelikož je očividně špatně implementovaný. Telefon nedokáže nic jiného než „tupě“ posílát stále dokola metody REGISTER a není schopen odpovídat ústředně a domluvit s ní další parametry a nastavení přenosu. Při procházení různých diskuzních fór jsme se setkali také převážně s neúspěchem, a proto bychom řešení Cisco Telefon se SIP firmwarem nikomu nedoporučili při vytváření nové VoIP sítě, či rozšíření té stávající. Pokud Cisco IP telefon, tak i s ústřednou Call Manager, nebo zkusit řešení Asterisk s podporou SCCP signalizace. Jelikož jsme chtěli realizovat a zobrazit alespoň jeden šifrovaný přenos, rozhodli jsme se vyzkoušet a odchytnout, jak vypadá šifrovaný přenos data streamu přes jiné zařízení pomocí SRTP. Zapojili jsme místo Cisco telefonu IP telefon Grandstream GXP 2000, který podporu SRTP přímo podporuje.

2.12.2008

13/18

Můžeme vidět jak se telefon bez problémů registroval a připojil na naší ustřednu:

Obrázek 17. Přehled registrovaných a dostupných telefonů na ústředně Asterisk A samotnou odchycenou komunikaci:

. . .

Obrázek 18. Šifrovaná komunikace dvou HW IP telefonů Grandstream GXP 2000 Na obrázku 18 můžeme vidět sestavení šifrovaného hovoru, kde volající posílá nejprve volanému SIP zprávu s metodou INVITE, ten odesílá odpověď 200 OK a posílá parametry pro sestavení hovoru (použitý kodek, zabezpečení atd...). Po odpovědi ACK ze strany volajícího je hovor spojen a začínají se přenášet šifrovaná data pomocí protokolu SRTP. Pro ukončení hovoru posílá volající SIP zprávu BYE a na tu dostává odpověď od volaného 200 OK. Hovor je ukončen.

5.3 Připojení přes Direct Call Posledním testem, který ještě připadal v úvahu, bylo vytočit SIP Cisco telefon přes tzv. Direct Call (přímé volání) bez použití ústředny. Volající telefon vytáčí přímo IP adresu volaného telefonu a jedná se o obdobu příkazu ping v klasických počítačových sítích. Pokud volaný telefon odpoví, je navázán hovor napřímo bez využití proxy serveru. Volajícím telefonem byl v tomto případě Grandstream GXP 2000 a volaným náš Cisco telefon. Po vytočení IP adresy volající telefon nedostal žádnou odpověď od volaného a ohlásil, že vzdálený uživatel není dostupný. Tím se nám potvrdilo naše předchozí tvrzení, že Cisco telefon se SIP firmwarem nedokáže odpovídat na přijaté požadavky ať už od ústředny, či od jiného IP telefonu.

2.12.2008

14/18

6 Závěr Našim úkolem bylo otestovat, jakou podporu zabezpečení mají IP telefony Cisco s podporou SIP signalizace. Konkrétně jsme testovali IP telefon Cisco 7911g s firmwarem sip.8-4-1ES2. Po několika testech, kdy jsme se snažili telefon registrovat, jak přes zabezpečenou signalizaci ke školní ústředně Asterisk, tak přes nezabezpečenou signalizaci k námi nainstalované ústředně, jsme došli bohužel k závěru, že SIP firmware pro tento typ telefonu je špatně naimplementován a nejenom, že nedomlouvá komunikaci podle standardu ITU-T, ale nedokáže s ústřednou či jiným telefonem komunikovat vůbec. Tím se naše testování zabezpečení spíše zvrtlo na testování schopnosti komunikace samotného telefonu. Jelikož jsme použili poslední vydanou verzi firmwaru, bylo naše očekávání na funkčnost daleko větší. Neřekl bych ani, že se jednalo o naše pochybení v určitých bodech průběhu testování, jelikož na internetových fórech, které se této problematice věnují, jsme našli také spoustu neúspěchu při realizaci provozuschpné VoIP sítě s tímto řešením. Jak už bylo napsáno výše, z těchto důvodů bychom řešení Cisco Telefon se SIP firmwarem nikomu nedoporučili při vytváření nové VoIP sítě, či rozšíření té stávající. Pokud Cisco IP telefon, tak i s jejich ústřednou Call Manager, nebo zkusit řešení Asterisk s podporou SCCP signalizace. Do budoucna bychom rádi ještě podrobili testům i jiné typy IP telefonů Cisco s SIP firmwarem například typy (7941,7960,7961), které jsou přece jenom více rozšířené, a proto se dá očekávat, že i podpora a kvalita firmwaru bude větší.

7 Použitá literatura [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M.Handley, and E.Schooler. SIP: Session Initiation Protocol, 2002. RFC 3261. [2] Sinnreich, H.: SIP Beyond VoIP. VON Publishing LLC, New York, 2005, ISBN: 0974813001. [3] http://en.wikipedia.org/wiki/Skinny_Client_Control_Protocol [4] A. Steffen, D. Kaufmann, and A. Stricker. SIP Security. http://security.zhwin.ch , 2004. [5] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. Norrman. The Secure Real-time Transport Protocol (SRTP), 2004. RFC 3711. [6] P. Zimmermann, A. Johnston, J.Callas, ZRTP: Media Path Key Agreement for Secure RTP. http://zfoneproject.com/docs/ietf/draft-zimmermann-avt-zrtp-03.txt , 2007 [7] http://www.voip-info.org/wiki/view/Asterisk+phone+cisco+79x1+xml+configuration+files+for+SIP

A) Příloha – Konfigurační soubor SEP <mac adresa telefonu> .cnf.xml <device> <deviceProtocol>SIP <sshUserId>cisco <sshPassword>cisco <devicePool> D-M-YA Central Europe Standard/Daylight Time <members> <member priority="0"> <ports> 2.12.2008

15/18

<ethernetPhonePort>2000 <sipPort>5060 <securedSipPort>5061 <processNodeName>158.196.146.12 <sipProfile> <sipProxies> <emergencyProxy> <emergencyProxyPort> true <sipCallFeatures> true x--serviceuri-cfwdall x-cisco-serviceuri-pickup x-cisco-serviceuri-opickup x-cisco-serviceuri-gpickup <meetMeServiceURI>x-cisco-serviceuri-meetme x-cisco-serviceuri-abbrdial false 2 true <semiAttendedTransfer>true 2 2 0 true <sipStack> <sipInviteRetx>6 <sipRetx>10 180 3600 5 120 120 5 500 4000 <maxRedirects>70 false <userInfo>None 1 false true false <enableVad>false 101 3 avt 2.12.2008

16/18

ts>

false false 3 SIP <stutterMsgWaiting>1 false <silentPeriodBetweenCallWaitingBursts>10false <startMediaPort>16384 <stopMediaPort>32766 <sipLines> 9 7014 <proxy>158.196.146.12 <port>5060 7014 7014 2 3 7014 hr714

<sharedLine>false <messageWaitingLampPolicy>1 <messagesNumber>700 4 5 1109 true false false true 21 speed dial name goes here <speedDialNumber>speed dial actual number goes in here 5060 184 0 dialplan.xml true 2 SIP11.8-4-1SR1S

2.12.2008

17/18

false false 0 <settingsAccess>1 0 0 0 0 <webAccess>0 1,2,3,4,5,6,7 00:00 00:00 00:00 <spanToPCPort>1 1 1143565489-a3cbf294-7526-4c29-8791-c4fce4ce4c37 New_Zealand New_Zealand 5.0(2) <deviceSecurityMode>0 158.196.146.12 <messagesURL> <proxyServerURL>proxy:3128 <servicesURL> 96 0 96 4 0 3804 <encrConfig>false

2.12.2008

18/18