Rizika VoIP, bezpečnostní pravidla Asterisku

Rizika VoIP, bezpečnostní pravidla Asterisku VoIP hazard, Asterisk security rules Vysoká dostupnost internetu umoţňuje zneuţívat IP telefonii způsobem, který nebyl u standardních analogových a časově přepínaných okruhů (TDM) moţný nebo technicky neproveditelný, z důvodu technologické náročnosti. Protoţe IP telefonie funguje na principu předávání paketů, je značně exponovaná a platí u ní vše, co se dá aplikovat v paketových IP sítích. Několik typických příkladů útoků v IP telefonii: Vyřazení sluţby z provozu Zahlcení zařízení DoS a DDoS útoky Implementační chyby Zahlcení Lámání hesel pro konfiguraci účtů Přerušení spojení Krádeţ účtu Vysoké riziko u nešifrované komunikace Zneuţití účtu ke generování volání CID spoofing Manipulace s ID (v ČR nemoţné) Odposlech Neautorizovaný odposlech dekódováním RTP VoIP SPAM Spam over Internet Telefony - SPIT Abychom se útočníkům IP telefonie mohli bránit, je potřeba pochopit některé principy zneuţití IP telefonní sluţby. Pokud stavíme vlastní VoIP server zaloţený na ústředně Asterisk, měli bychom se vyvarovat mnoha konfiguračních chyb. Proto zde budou některé tyto principy a chyby konfigurace vysvětleny. Seznámení s VoIP Pro správné pochopení bezpečnosti VoIP se nejdříve seznámíme se samotnou technologií přenosu hlasu pomocí IP. Voice over IP je technologie, která významně ovlivnila oblast telekomunikací, a pokud bychom hledali podobné milníky evoluce telefonie, tak bychom IP telefonii mohli postavit na stejnou úroveň jako digitalizaci. Přenášet hlas v paketových sítích má své nesporné výhody, které jsou ve dvou rovinách. Jednak je to vyuţití jediné přenosové infrastruktury a tím zefektivnění jejího uţití a dále zavedení nových pokročilých sluţeb, které v klasické přepínané telefonní síti jsou podstatně sloţitěji realizovatelné, anebo zcela nemoţné. Kaţdopádně pohlíţíme na telefonii jako na sluţbu v sítích s protokolem IP a hovoříme o IP telefonii jako o aplikaci, která vyuţívá standardní transportní protokoly Internetu. VoIP je progresivní technologií, která je vyuţívaná v sítích nové generace, její vývoj je stále otevřený [2]. Pro přenos hlasu se pouţívá na třetí vrstvě OSI modelu protokol IP, na čtvrté vrstvě protokol UDP (někdy i TCP) [3]. Pomocí levného přenosového média jménem Internet lze pomocí relativně jednoduchých signalizačních protokolů vytvořit systémy vzájemně hlasově (i multimediálně) propojených uţivatelů. Přenášet hlas v paketových sítích má své nesporné výhody i nevýhody. Výhodou je pouţití jediné přenosové datové infrastruktury (efektivní vyuţití), snadná 1

implementace, atd. Nevýhodou je moţná manipulace a zneuţití sluţby VoIP, způsobené velkou dostupností mezinárodní internetové sítě, které jde znalostí infrastruktury VoIP a její správnou konfigurací předcházet. Kaţdopádně pohlíţíme na IP telefonii jako na sluţbu v sítích s protokolem IP a hovoříme o IP telefonii jako o aplikaci, která vyuţívá standardní transportní protokoly Internetu [4]. Obr. 1 Základní schéma VoIP spojení Přenos hlasu v sítích IP V sítích s protokolem IP se hlas přenáší v paketech RTP, které na transportní vrstvě pouţívají protokol UDP a na síťové vrstvě protokol IP. Výjimkou je pouze protokol IAX, který má vlastní řešení přenosu hlasových paketů. Formát RTP paketu je dán doporučením IETF z roku 1996 s označením RFC 1889/1890. Přenos signalizačních informací v sítích IP Obdobně, jako v sítích s přepínáním okruhů, je kaţdý hovor provázen signalizačními informacemi při sestavení spojení v jeho průběhu a ukončení. V sítích s protokolem IP se signalizační informace mohou přenášet v transportních protokolech UDP nebo TCP. V sítích IP se pouţívá více protokolových modelů, a to H.323, SIP, MGCP, Skinny a další proprientální protokoly. Tato práce je zaměřená na zdůraznění bezpečnosti a počítá se základní znalostí čtenáře s VoIP. Pro hlubší porozumění a seznámení s technologií VoIP telefonie doporučuji [6]. Protokol RTP Real-time Transport Protocol je protokol standardizující paketové doručování zvukových i obrazových (video) dat po internetu. Publikován jako standard RFC 1889, později nahrazeným RFC 3550. Protokol se často pouţívá v systémech proudového přenosu, jako je telefonie, videokonference atd. Přenáší pro ně datové toky vyjednané signálními protokoly, jako jsou H.323 nebo SIP), čímţ je jedním z technických základů VoIP technologií. Data RTP jsou nejčastěji přenášena pomocí UDP protokolu. Shodně s RFC 1889, sluţby pracující s RTP zahrnují určení uţitečného zatíţení, číslování sekvencí, časové razítkování a sledování přenosu [7]. 2

Protokol SIP SIP je řídící protokol pracující na aplikační vrstvě. Byl navrţen tak, aby byl snadno implementovatelný, rozšiřitelný a dostatečně flexibilní. Slouţí k sestavení, ukončení, změny stavu relace mezi UA. Jedná se o textově orientovaný protokol podobný HTTP protokolu. Veškerá logika spojení je v koncových zařízeních (end-to-end), která znají jednotlivé stavy komunikace. Komunikace je zaloţena na poţadavcích a odpovědích pomocí údajů hlaviček paketů From, To nebo Subjekt. SIP UA jsou identifikování pomocí SIP URI podobné emailové adrese [2]: sip:userpassword@host:port;uri-parameters?headers zjednodušený zápis :sip:user@host (např: sip:+420800123456@voip.isp.cz) SIP protokol pouţívá metody (ţádosti), související se sestavením zrušení a dohledem nad spojením. Základní metody jsou INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS [2]. Protokol IAX (IAX2) Protokol IAX je nyní nahrazen vylepšenou druhou verzí s označením IAX2 (dále jen IAX). IAX je protokol VoIP, který nese signalizaci i hlasový tok součastně v jednom datovém paketu. Příkazy a parametry jsou posílány v binárním formátu. Protokol pouţívá jediný UDP port (obvykle 4569). Díky tomu snadno prochází firewally a NATem. Podporuje multiplexování kanálů, to znamená, ţe data z více hovorů jsou sloučena do jednoho proudu paketů mezi dvěma koncovými body, čímţ se sniţuje IP reţie, aniţ by vzniklo další zpoţdění [8]. Systém vyuţívá binárního protokolu, který je mnohem odolnější proti útokům typu buffer overrun [9]. IAX umoţňuje autentizaci uţivatele pomocí několika metod: MD5 a RSA. Bezpečnost protokolů SRTP šifrovaný přenos RTP V roce 2004 byl konečně standardizován protokol umoţňující šifrování obsahu realtime komunikace RTP v IP síti. Přesto dnes najdeme spoustu implementací bez pouţití šifrování. Týká se to především starších zařízení. Pouţitím nešifrovaného přenosu zvyšujeme riziko odposlechu hovoru. Pomocí analyzátoru Wireshark umí nešifrované RTP toky s kódováním PCM po zachycení přehrát, a některé profesionální analyzátory umí pracovat i s jinými kodeky. SRTP případně SRTCP rozšiřují o bezpečnostní mechanismy protokol RTP případně RTCP. Konkrétně těmito bezpečnostními mechanismy máme na mysli podporu integrity, ověření autenticity, zaručení důvěrnosti a je také zavedena ochrana proti přeposílání. Protokolu SRTP byl jako výchozí přidělen komunikační port 5004, SRTCP port 5005. Obr. 2 Kódování obsahu paketu v SRTP dle RFC 3711 3

Důvěrnost přenášených dat v paketu zajišťuje kryptografický primitiv AES viz obr 1. Autentizace je zajištěna pomocí algoritmu HMAC-SHA-1, který provede součet hlavičky a obsahu SRTP paketu, součet poté uloţí do pole autentication tag. Při pouţití výše uvedených algoritmů je nutné, aby všechny komunikující strany znaly tajný symetrický klíč tzv. session key. Objevuje se ale problém, jak klíč generovat a distribuovat. V praxi se pouţívá generování jednotlivých potřebných session klíčů pomocí jednoho master klíče. Master klíč můţe mít 128,192 nebo 256 bitů. Pro distribuci se pouţívá protokol SDP, ten ale není tak, jako většina dalších protokolů, chráněn proti případným útokům [2]. Obr. 3 Zabezpečení hlasové streamu pomocí SRTP ZRTP šifrovaný přenos RTP dle Phila Ziemmermanna Protokol ZRTP byl představen jako nástavba pro jiţ zavedený a vyuţí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. Ziemmermann si všiml nedostatku v SRTP, kde je master klíč distribuován v nechráněných SDP, z master klíče se odvozují ostatní, a tak by mohlo dojít k prolomení šifrované komunikace třetí stranou. 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, který nahlas přečtou volající strany. Tato vypočtená hodnota je pouţita pouze jednou, její část se však ukládá pro budoucí spojení. V zásadě ZRTP uţívá tři fáze k tomu, aby zjistil a nastavil SRTP master klíče a přešel na SRTP mód: Detekce, zdali účastníci podporují ZRTP implementaci Výměna symetrických klíčů Přepnutí do SRTP módu a úspěšné pouţívání SRTP Obr. 4 Zabezpečení hlasového streamu nejdříve ZRTP, následně SRTP Kombinace několika klíčových údajů dělá tento způsob zabezpečení účinným proti většině případných útoků. Jakmile ZRTP vypočítá klíčová data, nastaví v SRTP kryptografickou souvislost a přepne RTP do SRTP módu. Nakonec ZRTP změní některé kontrolní informace, aby mohl ověřit, zda celá operace proběhla úspěšně [2]. 4

Zabezpečení v SIPu Principy způsobu komunikace SIPu jsou podobné HTTP a díky této podobnosti se vyuţívají stejné bezpečnostní mechanismy, které pouţívá právě HTTP. HTTP Basic Authentication Je prvním mechanismem, který zajišťuje autentizaci pomocí sdíleného hesla [2]. HTTP Digest Authentication Vychází z předchozí metody s tím rozdílem, ţe místo přenosu otevřeného hesla ho šifruje pomocí hashovací funkce MD5 nebo SHA. 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 [2]. V roce 1996 byla objevena vada v návrhu MD5, a i kdyţ nebyla zásadní, kryptologové začali raději doporučovat jiné algoritmy, jako je například SHA (i kdyţ ani ten jiţ dnes není povaţován za bezchybný). V roce 2004 byly nalezeny daleko větší chyby a od pouţití MD5 v bezpečnostních aplikacích se upouští [10]. Secure MIME (S/MIME) Tato metoda zabezpečí obsah zprávy a zaručí její integritu. Existují dva způsoby šifrování obsahu dat. První aplication/pkcs7-mime dokáţe digitálně podepsat a zašifrovat data. Druhý způsob 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é primitivy (DES, 3DES, AES) [10]. SIPS URI (TLS) Zde se vyuţívá architektury veřejných klíčů pro ověření autentizace. Při pouţití této metody se mění prefix identifikační hlavičky na sips. sips:user@host Aby byla zaručena bezpečná komunikace, pouţívá tato metoda šifrovaný protokol TLS. Tento protokol vyuţívá asymetrické šifrování, symetrické algoritmy a hashovaní funkce. 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 [10]. Obr. 5 Zabezpečeni signalizace a hlasového streamu (SIPS / ZRTP) 5

Protokol IAX IAX pouţívá binární protokol, který dle RFC, nabízí ochranu proti útokům buffer overrun attacks. IAX nabízí ověřování veřejných klíčů pomocí RSA a utajení volání pomocí AES. Tyto funkce zabezpečení jsou důleţité, nicméně, často chybí v koncovém zařízení, kde se protokol IAX aplikuje. Proto je v tomto případě IAX stejně zranitelný jako nechráněný SIP nebo H.323 protokol. Protokol běţně pouţitá MD5 hash, který ale nepřináší dostatečné zabezpečení proti slovníkovým útokům. IAX má potenciál stát se velmi populárním protokolem pro VoIP. Zatímco IAX má mnoho provozních a funkčních výhod před SIP nebo H.323, nemá lepší zabezpečení ve srovnání s ověřováním a šifrováním konkurenčních protokolů. Ověřovací nedostatky SIP a H.323 se zrcadlí v IAX. Kromě toho, pokud jde o hlasovou komunikaci, nedostatek protokolu IAX je podobný protokolu RTP. V současné době se bezpečnost protokolu IAX drţí na stejné úrovni s protokoly SIP, H.323, a RTP [11]. Moţné bezpečnostní přínosy IAX, které jsou uvedeny v RFC, můţou být dosaţeny, jakmile se rozšíří podpora pro řádnou implementaci ověřování a šifrování v koncových bodech a ústřednách. Shrneme-li vlastnosti protokolu, můţe vyuţít podporu RSA pro autentizaci a AES k šifrování komunikace s médii, bránící útočníkům odposlechnutí hovoru. Nicméně zatímco v řádně zašifrovaném přenosu bude odposlechu zabráněno, stále bude IAX náchylný k útokům typu Denial of Service [11]. Jednoduchý odposlech Jednoduchý odposlech lze jednoduše provést programem Wireshark. Tímto programem můţeme analyzovat RTP,SIP, IAX atd. Nutná podmínka odposlechu je přístup k paketům nesoucí hledanou informaci, např. pomocí hubu místo switche. Obr. 6 Analýza hlasového streamu pomocí programu Wireshark VoIP server jako ústředna Asterisk VoIP server / pbx Asterisk je světový populární open source projekt řešící VoIP komunikaci, který přemění běţný počítač na server pro hlasovou komunikaci. Asterisk umoţňuje snadno vytvořit a nasadit širokou škálu telefonních aplikací a sluţeb, včetně IP PBX, VoIP brány, call centra ACD a IVR systémů atd. Asterisk je jako stavebnice, něco jako stavebnice Lego, s kterou lze vytvářet komunikační aplikace. Asterisk zahrnuje všechny základní stavební kameny potřebné k vytvoření telefonního systému, IVR systému nebo k jakémukoli jinému druhu komunikačního řešení. Asterisk ve verzi 1.6 podporuje TLS. SRTP je podporováno od verze 1.8. 6

Systém konfigurace ústředny je pomocí konfiguračních souborů umístěných v adresářovém systému serveru běţící pod OS Linux / Unix. Ovládání ústředny probíhá zadáváním jednoduchých příkazu v konzole Asterisku. Existuje mnoho modifikací jako je Trixbox, FreePBX, atd., které ale vycházejí ze stejného jádra. Některá rozšíření systému Asterisk lze konfigurovat a ovládat pomocí webového prohlíţeče. V následujících odstavcích se nebudeme zabývat konfigurací ústředny jako takové, ale zaměříme se na konfiguraci součástí související s bezpečností Asterisku. Dále se podíváme, jakým moţným způsobem je moţné chránit ústřednu proti slovníkovým útokům. Pro hlubší porozumění doporučuji [1]. Jednoduchá ukázka konfiguračního souboru sip.conf [general] port = 5060 context = default disallow = all allow = alaw dtmfmode = auto language = cz [user_102] type = friend username = user_102 userid = user_102 <102> host = dynamic secret = heslo123456 context = in_comming Bezpečnostní pravidla VoIP ústředen Pouţití bezpečných hesel, tedy dostatečně dlouhá, a ne jednoduchá slova. Délka hesel minimálně 8 znaků, kombinace malých, velkých písmen, číslic a dalších znaků (tečky, čárky, středníky aj.) Nelze pouţít běţná slova, jména, postavy ze seriálů, filmů atd. Tato jména bývají velmi často pouţívána ke slovníkovým útokům. Pouţití firewallu podporující VoIP. Povolení pouze těch spojení, která jsou bezpodmínečně nutná pro funkci systému. Globálně zamezit přístupu pro všechna VoIP zařízení a explicitně povolení pouze těch, která mají oprávnění volat prostřednictvím VoIP systému. Nastavení limitů pro provoz na jednotlivé účty. Povolit pouze ty systémové sluţby, které jsou nezbytně nutné pro provoz poţadovaných aplikací. Zakázání nepotřebných sluţeb FTP, TFTP, TELNET, SSH a další. Eliminace moţnosti vzdáleného přístupu do databází. Monitorování a sledování provozu IP ústředen. Všechny VoIP účty musí bezpodmínečně vyţadovat ověření od svých VoIP klientů. Zamezení volání prostřednictvím jakýchkoliv implicitních či defaultních SIP účtů. Převedení všech VoIP dat do VLAN, aby bylo moţno dát VoIP paketům vyšší prioritu pro plynulost komunikace. Tímto se získá ochrana proti DoS útokům, odposlouchávání a přebírání konverzace. Současně při dostatečně rezervované kapacitě pro VLAN nevznikají problémy s dostupností sluţby [13]. Studovat informační tutoriály o přerušení HW. Zálohovat instalační soubory pro moţnost rychlého obnovení. 7

Základní nastavení Asterisku z hlediska bezpečnosti [general] port = 5060 context = nothing bindaddr = 192.168.54.1/24 allowguests = no ;komunikační port ;Není li definován uživatel, začíná volání ;v tomto kontextu v dialplánu. Špatné ;nastavení vede k velkému nebezpečí ;zneužití ;Rozsah IP adres, ze kterých je povolená ;VoIP komunikace se serverem ;Zakazuje přihlášení anonymních uživatelů [user_102] type = peer username = user_102 userid = user_102 <102> host = 192.168.54.48 secret = heslo123456 context = in_comming ;Typ registrace: peer, friend, user ;Uživatel se může registrovat jen ;z definované IP adresy ;Registrační heslo. Není-li zadáno, ;uživatel se může registrovat bez ;autentizace!!! ;Přiřazení kontextu v dialplánu Parametr type má moţné tři moţnosti nastavení: peer, friend a user. Peer porovnává registrační IP adresu při ţádosti o spojení. Nesouhlasí-li, je spojení směrováno do výchozího kontextu. User vyţaduje ověření heslem při sestavování spojení v hlavičce s SIP URI. Koncové přístroje ho ale nepodporují. Vhodné pro propojení více ústředen. Parametr friend je kombinace předchozích typů. Chyby v konfiguraci Asterisku (konfigurační stupidity) Uživatel může volat jakékoliv číslo v aktuálním kontextu [internal] exten => intro,1,backgound(welcome) exten => 1,1,Goto(Spanich) exten => 2,1,Goto(English) exten => _XX.,1,Dial(DAHDI/g1/${EXTEN})!!!! Nevhodné použití patern matchingu _.. Útočník může volat cokoliv!!! exten => _.,1,Dial(DAHDI/g1/${EXTEN})!!!! Použití demo kontextu Nejedná se o skutečné nebezpečí, ale kdokoliv si můţe hrát s vaším systémem a vyuţívat tak celou šířku pásma. Nepoužívat defaultní kontext Uţivatelé guest mohou zneuţít volání při nevhodném nastavení kontextu default. Např. default kontext = internal, viz výše. Dodržování použití kontextu na všech kanálech Nastavení konkrétního kontextu na všech kanálech, jako jsou sip.conf, h323.conf, iax.conf, dahdi.conf, atd. 8

Nastavení maximálního počtu hovorů Nastavení maximálního počtu současně sestavených hovorů jednoho uţivatele. Bindaddres Jestliţe uţivatelé komunikují jen ve vnitřní síti, nenastavujte bindaddres = 0.0.0.0. Nepoužívat registraci hostů Allowquest = no Použití MD5 hash Pouţití MD5 hashe místo zadání hesla secret v otevřené formě. Nejedná se o úplné zabezpečení, ale zkomplikuje hádání hesel. Změna default hesel v manager.conf V konfiguračním souboru manager.conf změnit všechna defaultní hesla. Spouštění Asterisku Nespouštět Asterisk pomocí příkazu safe_asterisk, protoţe se otevře konzole tty9, která má přístup superuţivatele bez hesla! Správně by měl startovací skript vypadat takto: asterisk start Slovníkové útoky - obrana proti nim Pokouší-li se o přístup k systému útočník, který zkouší zcizit libovolný VoIP účet slovníkovou metodou, posílá serveru registrační poţadavek s náhodně generovaným jménem. Uhodnout uţivatelské jméno není obtíţné, protoţe se často pouţívá číslo v rozmezí 1 9999. Uţivatelské jméno jako číslo, vychází ze skutečnosti, ţe se jedná o telefonní systém. Dojde li při shodě čísla s některým účtem, vyţádá si server zadání hesla. Zde útok pokračuje slovníkovou metodou lámání hesel. Pokud není server chráněný, můţe tento útok trvat do doby, neţ útočník heslo prolomí, nebo jej odradí sloţitost hesel. Při útoku se samozřejmě zvýší zatíţení serveru a můţe dojít k omezení dalších sluţeb. Řešením je odpojit takového útočníka od serveru pomocí aplikace IPTTABLES. Asterisk při neúspěšné registraci zapíše do log souboru hodnotu No matching peer found při neshodě uţivatele a Wrong password při špatném heslu, včetně IP adresy útočníka. Registration from '<sip:116@pbx.cz>' failed for '81.136.249.66' - No matching peer found Registration from '<sip:388@pbx.cz>' failed for '188.95.127.235' - Wrong password Pro tuto sluţbu můţeme vyuţít program Fail2ban, běţící jako sluţba na pozadí serveru. Tento program čte jednotlivé řádky a setká-li se s výše popsaným útokem, přidá útočníka do tabulky IPTABLES a znemoţní mu přístup k serveru. Další funkcí tohoto programu je vyčištění tabulky po uplynulé době. Vyčištění tabulky je z důvodu umoţnění registrace autorizovaného uţivatele, který vícekrát zadal špatně své uţivatelské heslo. 9

Závěr Seznámení s internetovou telefonií nám ukazuje její zranitelnost ve srovnání s klasickými pevnými linkami. Internet, jako přenosové médium, je mnohem dostupnější všem moţným útočníkům. Samotné protokoly mají jednoduchou strukturu, kterou je potřeba rozšířit o bezpečnostní prvky. Zabezpečený VoIP přenos ale zvyšuje reţii přenosové cesty. Pouţívání VoIP proto vyţaduje hlubší znalosti implementace, kde nestačí jen samotná znalost protokolů, ale i systém útoků a tím pádem obrana proti nim. Neméně důleţitá je znalost konfigurace VoIP telefonních ústředen, kde chyby v konfiguraci z větší části ovlivňuje lidský faktor. Špatně nakonfigurovaný telefonní systém vede k vyřazení sluţby, v horším případě k velkému finančnímu úniku. Seznam použité literatury [1] JIM, Van Meggelen, LEIF, Madsen, JARED, Smith. Asterisk : The Future of Telephony. Mike Loukides; Robert Romano and Jessamzn Read. 2nd enl. edition. Sebastopol : O Reilly Media, 2007. xxv, 574 s. ISBN 978-0-596-51048-0. [2] VOZŇÁK, Miroslav. Voice over IP. 1.vydání. Ostrava : Ediční středisko VŠB - TU Ostrava, 2009. 176 s. ISBN 978-80-248-1828-3. [3] Voice over Internet Protocol [online]. Wikipedia, 2009, Editováno 28. 4. 2009 v 14:57 [cit. 2009-05-10]. Dostupný z WWW: <http://cs.wikipedia.org/wiki/voip>. [4] LUDÍK, Martin. Domácí VoIP ústředna s připojením do GSM sítí. Zlín, 2009. 61 s. Bakalářská práce. Univerzita Tomáše Bati - Fakulta aplikované informatiky. [5] VOŢŇÁK, Miroslav. TECHNICKÉ PRINCIPY IP TELEFONIE. Teorie a praxe IP telefonie [online]. 2004 [cit. 2009-05-10]. Dostupný z WWW: <http://www.iptelefon.cz/archiv/dok_osta/ipt-2004_principy_iptel.pdf>. [6] Voice over Internet Protocol [online]. 2010, 6. 11. 2010 [cit. 2010-11-15]. Dostupné z WWW: <http://cs.wikipedia.org/wiki/voice_over_internet_protocol>. [7] Real-time Transport Protocol [online]. 2010, 23. 9. 2010 [cit. 2010-11-15]. Dostupné z WWW: <http://cs.wikipedia.org/wiki/real-time_transport_protocol>. [8] Wikipedia The Free Encyclopedia [online]. 2010 [cit. 2010-11-17]. Inter-Asterisk exchange. Dostupné z WWW: <http://en.wikipedia.org/wiki/inter-asterisk_exchange>. [9] PETR, Kovář, KAROL, Molnár. Vyuţití protokolu IAX pro spojení mezi ústřednami. Elektrorevue [online]. 2008 [cit. 2009-05-10]. Dostupný z WWW: <http://www.elektrorevue.cz/cz/clanky/komunikacni-technologie/0/vyuziti-protokolu-iax-prospojeni-mezi-ustrednami/>. ISSN 1213-1539. [10] Wikipedia The Free Encyclopedia [online]. 2010 [cit. 2010-11-17]. Message-Digest algorithm. Dostupné z WWW: <http://cs.wikipedia.org/wiki/message-digest_algorithm>. [11] Isecpartners [online]. 2010 [cit. 2010-11-19]. IAX Voice Over-IP Security1. Dostupné z WWW: <https://www.isecpartners.com/files/isec_dwivedi_lackey_voip_bh07.pdf>. [12] VOŢŇÁK, Miroslav. TELEFONNÍ ÚSTŘEDNY ASTERISK [online]. 2008 [cit. 2009-05- 16]. Dostupný z WWW: <http://www.ip-telefon.cz/archiv/dok_osta/ipt- 2008_Telefonni_ustredny_Asterisk.pdf>. [13] Zákaznická podpora [online]. 2009 [cit. 2010-11-19]. Desatero doporučení k zabezpečení VoIP ústředen a telefonie. Dostupné z WWW: <https://podpora.volny.cz/chrante-sip.php>. 1 0