ÚVOD DO PROBLEMATIKY PREPOJENIA PRIVÁTNYCH SIETÍ A SIETÍ PROVIDEROV NA BÁZE IP Moderná konvergovaná telekomunikačná sieť dnes poskytuje svojim zákazníkom nespočetné množstvo možností a služieb. Poskytuje komfortné využívanie všetkých komunikačných služieb (hlas, video a dáta). Základom takejto siete je výkonné jadro (core), teda nosná širokopásmová chrbticová sieť, ku ktorej sú popripájané všetky periférie (rozhrania). Trend vo svete ukazuje, že je snaha o budovanie nosných (chrbticových) sietí na báze IP. Rozhrania potom robia konverziu protokolu IP/ (hlasové služby, dátové služby, mobilné služby a iné). Tým sa podstatne zjednoduší manažovanie takejto siete (na rozdiel od hybridných sietí tvorených PSTN, ATM, IP, FR...). Na druhej strane je ale dôležité definovať štandardy konverzie IP/(ostatné služby). V tejto práci sa budem venovať problematike IP/hlasová služba, inak povedané prenosom hlasu po IP sieti VoIP (Voice over IP), bezpečnostným problémom hlasovej služby v IP sieti ako aj ich riešeniam. Na začiatok je nutné povedať, že prenos hlasu po IP sieti (VoIP) je krok vpred smerom k intergrácii služieb, ale ako bude spomenuté v tejto práci, existujú isté riziká (bezpečnostné, implementačné). Napríklad stačí spomenúť, že je viacero štandardov (protokolov), ktoré podporujú VoIP. Samozrejme je nutné si tento fakt uvedomiť a uvažovať, ktorý zo štandardov implementovať, či už z hľadiska bezpečnosti, kompatibility a budúceho vývoja sietí. Cieľom mojej práce bude navrhnúť prepojenia privátnych sietí zákazníkov ku konvergovaným sieťam operátorov (ďalej providerov), pričom sa zamerám na bezpečnosť prepojenia a na hlasovú službu v IP prostredí (VoIP). 1. DEFINOVANIE SIGNALIZAČNÝCH PROTOKOLOV VoIP SIP (a príbuzné štandardy) a H.323 (a príbuzné štandardy) 1.1 Protokoly rodiny H.323 Štandard H.323 [ 1 ] [ 2 ] zatiaľ prešiel piatimi verziami: H.323v1, H.323v2, H.323v3, H.323v4 a H.323v5. Verzia 1 nazývaná Vizuálne telefónne systémy a - 1 -
zariadenia pre LAN, ktoré neposkytujú zaručenú kvalitu služieb bola prijatá ITU skupinou 16. októbra 1996. Táto verzia neposkytovala garantovanú kvalitu služieb. Zariadenia vyrábané v tejto dobe pre VoIP (Voice over IP) komunikáciu boli nekompatibilné z dôvodu neexistencie doporučení, ktorými by sa mali výrobcovia riadiť. S rozširovaním VoIP prišli požiadavky uskutočňovať spojenie medzi klasickými telefónnymi sieťami PSTN a prístrojmi založenými na technológií VoIP. Z týchto dôvodov bola v januári 1998 vytvorená H.323 verzia 2 nazývaná Systémy paketovej multimediálnej komunikácie. Verzia 3 bola prijatá v septembri 1999. Táto verzia priniesla len niekoľko dôležitých vylepšení do hlavného doporučenia. Väčšina zmien sa týkala doplnkov H323. Oproti tomu verzia 4 priniesla mnoho vylepšení, týkajúcich sa hlavne spoľahlivosti, rozšíriteľnosti a pružnosti. Táto verzia bola prijatá v novembri 2000. V septembri roku 2003 sa prijala zatiaľ posledná 5. verzia H.323, ktorá je v dnešnej dobe stále upravovaná a obohacovaná o doteraz nešpecifikované časti, ako je napr. komunikácia medzi gatekeepermi, prenos faxov po paketových sieťach a mechanizmy rýchleho zostavovania spojenia. H.323 je množina štandardov ITU pre hlasovú, dátovú a obrazovú komunikáciu prostredníctvom paketových sietí. H.323 špecifikuje, akým spôsobom by mali terminály vzájomne komunikovať v IP prostredí. H.323 bol vyvinutý s cieľom zabezpečiť dostupnosť garantovanej úrovne služieb pre multimediálnu komunikáciu cez LAN. Štandard je do istej miery odvodený od multimediálneho štandardu H.320 pre ISDN a využíva tieto štyri typy zariadení: terminál, brána, Gatekeeper a konferenčná jednotka (Multipoint Control Unit MCU). Tieto elementy sú popísané v kap. 1.1.1 1.1.5. Obr. 1.1.1 - Komponenty H.323 siete - 2 -
1.1.1 H.323 terminály Sú to terminály na báze LAN a koncové body na prenos hlasu. Napríklad môžu byť reprezentované ako: Software bežiaci na počítači alebo Ethernetový telefón. H.323 terminály podporujú prenos hlasu v reálnom čase a umožňujú duplexný prenos. H.323 terminály implementujú prenos hlasu a ich súčasťou sú kodeky posielajúce a prijímajúce paketizovaný hlas. Podporované kodeky sú: G.711, G.723, G.729A a GSM. Každý kodek sa vyznačuje určitými špecifickými vlastnosťami, ktoré sú popísané v prílohe 1. Terminály samozrejme potrebujú byť vybavené signalizačnými funkcionalitami, ktoré sú nutné pre zostavenie volania, rozpojenie a iné procedúry. Aplikačné štandardy sú H.255.0 signalizácia, ktorá je časťou signalizácie Q.931; H.245 nutný na výmenu informácii medzi H.323 entitami o prenosových schopnostiach terminálov; a RAS spájajúci terminál ku Gatekeeper-u. terminály môžu mať implementované video a dátové komunikačné schopnosti. Obr. 1.1.2 - H.323 terminál 1.1.2 Gateways (Brány) Slúžia ako rozhranie medzi sieťou H.323 a inou sieťou (napr. TDM). Z jednej strany sa pripájajú k tradičnej hlasovej sieti a z druhej strany k paketovo-orientovanej sieti. Kedže tvoria rozhranie, musia prekladať signalizačné správy medzi oboma stranami a komprimovať/ dekomprimovať hlas. Príklad takejto brány je na obrázku 1.1.3. - 3 -
Obr. 1.1.3 - Funkcionalita brán (SCN Switched Circuit Network okruhovo spínaná sieť) Dnes existuje veľa druhov brán, počnúc od malých firemných riešení po veľké riešenia schopné spojovať niekoľko tisícok spojení. 1.1.3 Zóna Je množina zariadení (terminálov, brán a MCU) riadených jedným Gatekeeperom. Musí obsahovať aspoň jeden terminál a môže obsahovať viacero brán a MCU. Obsahuje však len jeden Gatekeeper. Zóna môže byť nezávislá od topológie siete a môže sa skladať z viacero sieťových segmentov pospájaných navzájom smerovačmi či inými zariadeniami. 1.1.4 Gatekeeper Gatekeeper musí plniť niektoré funkcie. Gatekeeper manažuje H.323 zónu, napríklad zónu zariadení, ktorým prislúcha IP subnet. V sieti môže byť zastúpených viacero Gatekeeperov, ktoré majú napríklad funkcionalitu rovnomerného spravovania záťaže alebo ako záložné riešenie pri výpadku (BACK UP). Filozofia definície Gatekeepera je povoliť H.323 dizajnérom separovať prvotný proces telefónie z inteligentnej časti siete na Gatekeepere. Typickým príkaldom Gatekeepera je PC, kde Gateways sú reprezentované nejakou hardwarovou platformou. Gatekeeper robí preklad adries a routing (smerovanie) pre zariadenia v jeho zóne. Môže to byť napríklad medzi interným a externým číslovacím systémom. Ďalšou dôležitou funkciou Gatekeepera je kontrola prístupu, teda ktoré zariadenia majú oprávnenie volať a aké čísla môžu volať. Medzi ďalšie funkcie patrí SNMP manažovanie siete. - 4 -
Gatekeeper je schopný participovať na množstve signalizačných modelov. Signalizačný model pritom hovorí o tom, ktoré signalizačné správy pôjdu cez Gatekeeper a ktoré mimo neho, priamo len medzi entitami ako Gateway a terminál. Na obrázku 1.1.4 sú znázornené dva signalizačné modely (vľavo priamy signalizačný model, vparvo Gatekeeperom smerovaná signalizácia). Obr. 1.1.4 - Signalizačné modely v H.323 sieti 1.1.5 MCU (Multipoint Control Unit) Zostavujú konferencie medzi tromi a viacerými terminálmi. Logicky sa skladajú z dvoch častí: - MC (Multipoint Controler), ktorý má na starosti signalizáciu a kontrolné správy nevyhnutné pre inicializovanie a manažovanie konferencie - MP (Multipoint Processor), ktorý akceptuje streamy z koncových bodov, replikuje ich a smeruje ich na príslušné terminály 1.1.6 H.323 a model OSI štandardy v H.323 Na obrázku 1.1.5 sú v modeli OSI znázornené štandardy, ktoré využíva H.323. - 5 -
Obr. 1.1.5 Štandardy používané v H.323 1.1.7 Popis štandardov audia, dát a videa (Príloha 1) 1.1.8 Popis používaných portov a protokolov v H.323 a niektoré bezpečnostné riešenia v H.323 (Príloha 2) 1.2 SIP (Session Initiation Protocol) a príbuzné protokoly Protokol SIP [ 1 ] [ 4 ] bol vytvorený v roku 2000 cez MMUSIC (Multiparty Multimedia Session Control) pracujúcí pod správou IETF. Štandard SIP zostal originálne projektovaný pre služby internetových multimediálnych konferencií a je stavaný na základe jazyka HTML. Protokol SIP vznikol neskôr ako H.323 a svojou textovou a mnemotechnickou podobou pripomína rozšírené protokoly SMTP pre prenos elektronickej pošty a protokolu HTTP pre prenos obsahu na Webe. Vlastná komunikácia prebieha formou výmeny textových správ ako pri protokole HTTP. Na rozdiel od HTTP protokol SIP môže bežať nad TCP, ako aj nad UDP. V SIP je jednoduchšie riešenie prechodu cez Firewally ako v H.323 a umožňuje pridávať nové vlastnosti a funkcie jednoduchým rozšírením syntaxe. - 6 -
Oproti H.323 má SIP mnoho výhod. Protokol je celkovo jednoduchší a nadväzovanie spojenia je veľmi rýchle. Na rozdiel od H.323 sa dá adresovať nie len vzdialený počítač, ale aj konkrétny užívateľ na ňom. Protokol H.323 vie adresovať len terminál a aliasy, ale tie sa musia prekladať cez Gatekeeper. V príslušnom RFC je SIP charakterizovaný ako signalizačný protokol slúžiaci k zostaveniu, modifikácii a ukončeniu spojenia medzi dvoma alebo viacerými účastníkmi. Spojenie môže predstavovať obecne akýkoľvek multimediálny prenos, v praxi je ale SIP najčastejšie využívaný pre telefonovanie po IP sieti. Sila protokolu SIP sa prejaví hlavne v spolupráci s protokolmi SOAP (Simple Object Access Protocol) pre prístup k webovým službám (webovým stránkam) a SIMPLE (SIM for Instant Messaging and Presence Leveraging Extensions). Protokol SIMPLE rozširuje protokol SIP o pokročilé funkcie instant messagingu (transport krátkych správ v reálnom čase). Protokoly SIP, SOAP a SIMPLE bývajú dohromady nazývané ako Triple- S, Trojité S. SIP poskytuje nasledujúce služby: lokalizáciu užívateľa určenie koncového systému pre danú komunikáciu, naviazanie spojenia stanovenie parametrov pre volajúcu a volanú stranu, dostupnosť užívateľa zistenie dostupnosti volanej strany a sledovane jej prítomnosti, užívateľské možnosti určenie média a jeho parametrov. SIP naproti tomu : neuskutočňuje manažment interaktívnych relácií po ich naviazaní, nedokáže zaistiť požadovanú kvalitu služby (QoS), pretože nevie uprednostňovať prevádzku ani rezervovať potrebné sieťové prostriedky, ale môže spolupracovať s protokolmi, ktoré sa o zaistenie kvality môžu postarať (napr. RSVP) nieje protokol určený k prenosu veľkého objemu dát, ako napr. HTTP, namiesto toho prenáša iba malý objem dát potrebný pre naviazanie interaktívnych relácií a okrem toho je ešte schopný prenášať krátke textové správy. - 7 -
1.2.1 Architektúra protokolu SIP SIP nie je závislý na topológii sietí a môže spolupracovať s niekoľkými protokolmi napr. UDP, TCP, IPX alebo PPP. Súčasťou základu architektúry protokolu SIP sú tieto protokoly SDP, SAP, RTP, RTCP, RTSP a RSVP. Obr. 1.2.1 - Začlenenie SIP v architektúre protokolov pre VoIP SDP slúži k popisu možností a typu posielaných implementovaných médií v termináli. Správy sú zasielané pomocou textových správ, rovnako ako v SIP. SDP posiela informácie o možnostiach a podpore funkcií terminálu (popisuje použité kódovanie, čísla portov a parametre). SAP sa používa k informovaniu väčšieho počtu osôb (verejné konferencie, televízia alebo rozhlas cez internet). SIP rovnako ako H.323 využíva protokoly transportnej vrstvy (RTP a RTCP). Dodatočne SIP zahrňuje RTSP, ktorý plní kontrolné funkcie nad inicializáciou spojení a prenosu toku multimediálnych dát s multimediálnymi servermi, a protokol RSVP rezervuje požadovanú kapacitu pre spojenie v sieťových prostriedkoch a tým zabezpečuje požadovanú QoS. INVITE sip:jozko@vrable.sk SIP/2.0 Via: SIP/2.0/UDP 195.113.147.120:1912 Date: Wed, 1 Feb 2006 10:56:34 GMT From: <sip:jozko@vrable.sk> To: <sip:pichlos@vinice.sk> Subject: Hovor 1 Priority: normal Expires: 3600 CSeq: 1691095645 INVITE Call-ID: 884664559@195.113.147.210 Contact: <sip:jozko@195.113.147.120:5060> Content-Type: application/sdp Content-Length: 143 v=0 o=jozko 987504994 987504994 IN IP4 195.113.147.120 s=hovor 1 c=in IP4 195.113.147.120 t=3196493794 3196497394 m=audio 10000 RTP/AVP 0 Obr. 1.2.2 - Správa protokolu SIP s enkapsulovanou správou SDP - 8 -
1.2.2 Popis protokolu SDP Protokol SDP [ 3 ] je dôležitým elementom v správach SIP. Má na starosti dohodnutie portov a protokolov na prenos dát medzi koncovými bodmi. Prenos dát potom výhradne prebieha medzi terminálmi, teda medzi volajúcim a volaným. Z hľadiska bezpečnosti komunikácie je veľmi dôležité sledovať, ktoré protokoly a porty SDP dohodne pri SIP signalizácii. Zápis SDP v SIP správe je typ=hodnota (obr. 1.2.2): v verzia protokolu SDP o pôvodca (originator) spojenia, udáva jeho užívateľské meno, identifikátor spojenia a IP adresu s meno (subject) spojenia c adresa spojenia (connection), na ktorú majú byť posielané dáta, obvykle ide o multicastovú IP adresu, za ktorou môže nasledovať lomítko a hodnota TTL (Time To Live) definujúca rozsah šírenia paketov v sieti a atribút prenášajúci doplnkové informácie, môže byť v tvare hodnota alebo meno:hodnota, napríklad recvonly znamená, že odosielateľ tejto správy bude jedine prijímať dáta m popis toku dát (media), udáva typ dát (audio, video, atď.), číslo portu na adrese udanej riadkom c, na ktorom bude tento prúd dát posielaný, transportný protokol (RTP, UDP, atď.) a kódovanie, obvykle ako číslo definované ako typ dát v protokole RTP 1.2.3 Architektúra siete SIP Architektúra siete SIP sa skladá zo štyroch základných elementov: terminálov, serverov proxy a serverov pre presmerovanie a registráciu. Funkcie terminálu SIP sú rovnaké ako pri termináli H.323. Server SIP zahrňuje časť funkcie Gatekeepera zo štandardu H.323. Prihlásenie nemusí byť realizované priamo cez server. Servery sú užívané hlavne pre smerovanie a presmerovanie prihlásenia. Môžu realizovať aj overovaciu funkciu, v tom prípade ide o registračný server. Server typu redirect informuje klienta, aby sa bezprostredne skontaktoval s iným serverom. Server proxy predáva prihlásenie do ďalšieho servera. Nadviazanie spojenia je menej komplikované a je kratšie ako v prípade štandardu H.323. Úspešné spojenie pomocou SIP sa skladá z dvoch príkazov: INVITE a ACK na strane volajúceho. Hovor je prerušený po príkaze BYE. - 9 -
Obr. 1.2.3 - Architektúra SIP siete 1.2.4 Signalizácia SIP je protokol typu klient-server. Klient nadväzuje spojenie so serverom. Jedno zariadenie môže pracovať súčasne ako klient i server. Napríklad telefón pracuje ako klient pre odchádzajúce volania a ako server pre prichádzajúce volania. Fakt, že protokol je typu klient-server neznamená, že komunikácia môže byť iba dvojbodová. Hovor, ktorý môže byť hlasový alebo multimediálny, môže prebiehať medzi viacerými účastníkmi. Multimediálne dáta sú potom prenášané naraz pre všetkých účastníkov spojením typu multicast, spojením typu unicast medzi každou dvojicou účastníkov alebo ako kombinácia týchto metód. Správy protokolu SIP sú dva typy REQUEST (požiadavka) a RESPONSE (odpoveď). Správy SIP: SIP Request (požiadavky) správy INVITE žiadosť o nadviazanie spojenia alebo o zmenu parametrov už existujúceho spojenia BYE žiadosť o rozpojenie spojenia ACK žiadosť, ktorou klient potvrdzuje, že obdržal odpoveď na žiadost INVITE REGISTER žiadosť o registráciu klienta na register server CANCEL žiadosť o zrušenie prebiehajúcej žiadosti INVITE OPTIONS žiadosť o zaslanie podporovaných funkcií na serveri INFO prenos informácií počas hovoru (rozšírenie protokolu SIP popísané v RFC2976) - 10 -
1 2 3 4 5 6 7 8 9 * 8 # 1 2 3 4 5 6 7 8 9 * 8 # Žilinská univerzita v Žiline SIP Response (odpoveď) správy 1xx informačná odpoveď, napr. 180 ringing (vyzváňanie) 2xx úspešná odpoveď, napr. 200 ok 3xx odpoveď presmerovania, napr. 302 moved temporarily (dočasné presmerovanie) 4xx odpoveď, že požiadavka zlyhala, napr. 404 not found (nenájdené) 5xx odpoveď, že server nepodporuje službu, napr. 503 service unavailable (služba neprípustná) 6xx odpoveď o globálnej chybe, napr. 600 busy everywhere (neprípustné všade) Volajúci klient môže kontaktovať volaný server priamo alebo prostredníctvom iného servera, ktorý pracuje ako tzv. proxy alebo redirect server. Priame volanie sa používa, ak klient vie IP adresu serveru, na ktorom sa nachádza volaný užívateľ. Priebeh spojenia je znázornený na obr. 1.2.4. Obr. 1.2.4 - Priame volanie (volajúci-volaný) Častejší prípad je keď klient nevie IP adresu servera, na ktorom sa nachádza volaný užívateľ. V tom prípade klient naviaže spojenie cez proxy alebo redirect server. Ten cez lokalizačnú službu zistí IP adresu volaného severa. Lokalizačná služba najčastejšie pracuje na inom protokole ako SIP, väčšinou ide o protokol typu LDAP, rwho či finger. Lokalizačná služba môže vrátiť niekoľko IP adries, preto proxy server musí kontaktovať všetky servery a čakať od nich odpoveď. Ak niektorý odpovie, ostatné žiadosti môžu byť stornované správou CANCEL. Na obrázku 1.2.5 a 1.2.6 sú znázornené možné priebehy spojenia cez proxy a redirect server. - 11 -
1 2 3 4 5 6 7 8 9 * 8 # 1 2 3 4 5 6 7 8 9 * 8 # 1 2 3 4 5 6 7 8 9 * 8 # IDC IDC 1 2 3 4 5 6 7 8 9 * 8 # 1 2 3 4 5 6 7 8 9 * 8 # 1 2 3 4 5 6 7 8 9 * 8 # 1 2 3 4 5 6 7 8 9 * 8 # Žilinská univerzita v Žiline Obr. 1.2.5 - Nadviazanie spojenia cez proxy server Lokalizačná služba INVITE from: pichlos@vinice.sk to: jozo@vinice.sk Request-URI: jozo@vinice.sk pichlos@vinice.sk 100 trying ACK 1. 2. 3. jozo@vinice.sk 302 Moved jozo@vrable.sk 6. 180 ringing 5. 4. Redirect server 8. jozo@vrable.sk INVITE from: pichlos@vinice.sk 7. to: jozo@vinice.sk Request-URI: jozo@vrable.sk 200 ok ACK 9. 10. SIP žiadosť SIP odpoveď Iný protokol jozo@vrable.sk Obr. 1.2.6 - Nadviazanie spojenia cez redirect server (podrobný popis správ je na obr. 1.2.8) Obr. 1.2.7 - Registrácia užívateľa na register server a rozpad spojenia - 12 -
Obr. 1.2.8 - Podrobný popis správ výstavby spojenia cez redirect server 1.2.5 Adresácia v SIP SIP URL majú rôzne formy (obecne sip: user@domain) a môžu obsahovať telefónne čísla. Napr. sip:abc@ferko.sk adresa počítača užívateľa abc v doméne ferko.sk sip:+421-212345678@ferko.sk telefónne číslo užívateľa dosiahnuteľného prostredníctvom brány. Podpora webovej adresácie, ako aj telefónnych čísel umožňuje IP komunikácii bez väčších problémov prechádzať medzi telefónnou sieťou a Internetom. Užívatelia v ktorejkoľvek sieti tak môžu komunikovať s kýmkoľvek v telefónnej sieti, alebo v Internete a nemusia pritom vymeniť svoje zariadenia. IP zariadenia s podporou SIP (telefóny, počítače) môžu komunikovať priamo, pokiaľ poznajú URL druhej strany. Čo sa týka adries tak najdôležitejšie adresy v SIP správach sú: FROM (v hlavičke od koho správa prichádza), TO (v hlavičke komu je správa adresovaná) a REQUEST-URI (väčšinou zhodná adresa s TO). Ale REQUEST-URI môže byť aj odlišná od adresy TO a to v prípade, ak je správa posielaná cez proxy server. Vtedy je správa prepísaná proxy serverom na adresu nasledujúceho serveru. Hlavička TO sa pri prechode proxy serverom nemení (obr. 1.2.5). V žiadostiach REGISTER je REQUEST-URI vždy adresa register servera jeho doménové meno (obr. 1.2.7). IP adresa proxy servera alebo redirect servera môže byť priamo nakonfigurovaná v zariadení volajúceho, alebo je získaná pomocou - 13 -
DNS servera. Vtedy je poslaná na DNS server požiadavka na vrátenie SRV záznamov. Ako odpoveď je vrátený zoznam IP adries a portov SIP serverov. 1.2.6 Prenos správ SIP v TCP/ UDP paketoch a popis štandartne používaných portov Na obrázku 1.2.9 je znázornený priebeh zapúzdrenia správy SIP do transportnej vrstvy [ 5 ] INVITE sip:jozko@vrable.sk SIP/2.0 Via: SIP/2.0/UDP 195.113.147.120:1912 Date: Wed, 1 Feb 2006 10:56:34 GMT From: <sip:jozko@vrable.sk> To: <sip:pichlos@vinice.sk> Subject: Hovor 1 Priority: normal Expires: 3600 CSeq: 1691095645 INVITE Call-ID: 884664559@195.113.147.210 Contact: <sip:jozko@195.113.147.120:5060> Content-Type: application/sdp Content-Length: 143 v=0 o=jozko 987504994 987504994 IN IP4 195.113.147.120 s=hovor 1 c=in IP4 195.113.147.120 t=3196493794 3196497394 m=audio 10000 RTP/AVP 0 obr. 1.2.9 Zapúzdrenie SIP správy do transportnej vrstvy SIP verzií 1 a 2 používa štandartne protokol UDP a port 5060 pre signalizáciu, kontrolu a SIP správy. Vyššie verzie už používajú protokol TCP a port 5060. SDP potom cez SIP správy dohoduje porty a protokol pre prenos dát v reálnom čase. Štandartne sú vyberané porty z dynamického rozsahu 1024-65535, pričom prenos dát zabezpečuje štandartne protokol UDP (vyššie verzie SIP uvažujú o prenose dát v reálnom čase cez TCP). Paketizáciu dát v reálnom čase zabezpečujú protokoly RTP a RTCP. Paketizované dáta (napr.hlas) sú potom prenášané ako užitočná informácia v UDP paketoch. Príklad takejto komunikácie je na obr. 1.2.10. - 14 -
Obr. 1.2.10 Problematické miesta vo VoIP Na obr. 1.2.10 je viditeľné, kde nastávajú otázky povolenia a zakázania protokolov a portov pri službách VoIP. Tieto miesta sú aj zdanlivo najcitlivejšími bodmi komunikácie VoIP. Sú však aj iné miesta v sieťovej hierarchii, ktoré je nutné sledovať (napr. NAT). Týmto problematickým miestam bude venovaný priestor v ďalších kapitolách tejto práce (3.2 a 3.3). 1.2.7 Kvalita a bezpečnosť hlasovej služby pri použití protokolu SIP SIP podporuje interaktívne aplikácie, ktoré sú citlivé na oneskorenie a jeho kolísanie a taktiež sú citlivé na stratu datagramov, ku ktorej dochádza pri vysokom v zaťažení siete. Tie nemusia vystačiť iba s bežnou úrovňou služby typu best effort, poskytovanou v IP sieťach a môžu vyžadovať konkrétnejšiu a vyššiu úroveň prenosovej služby na prenos užívateľských dát a signalizácie. SIP je taktiež zabezpečený z hľadiska autentifikácie a ochrany dát (RFC 3323, 3325, 3329) a spolupracuje s bezpečnostnými prvkami na Internete, ako je napr. firewall. Zabezpečenie SIP signalizácie a mediálneho prenosu je rozpracované v kapitolách 4.1, 4.2, 4.3 a 4.4. - 15 -
1.3 SIP T (Session Initiation Protocol for Telephones) [ 6 ] Dôležitou vlastnosťou každej SIP sieťovej štruktúry je rešpektovanie architektúry PSTN a zabezpečenie transparentnosti medzi sieťami. Tradičné telekomunikačné služby ako CALL WAITING (čakanie volania) či FREEPHONE NUMBERS (bezplatné čísla) a pod., implementované v signalizačných protokoloch PSTN sietí, ako napr. SS7 by mali byť dostupné aj v SIP sieti. Je nevyhnutné, aby SIP podporoval všetky základné funkcie a aby bol schopný rozlišovať medzi SIP terminálmi a SS7 terminálmi. Je podstatné, aby Gateway (brány) mali informácie o oboch stranách siete (SIP aj SS7), pretože práve brána tvorí rozhranie medzi oboma sieťami. SIP T predstavuje nosnú štruktúru pri integrácii prenosu starších typov signalizácií (v PSTN) cez SIP signalizačné správy. SIP T robí dve techniky nazývané ako: enkapsulácia (encapsulation - zapúzdrenie) a translácia (translation - preklad). Na SIP ISUP bráne sú SS7 ISUP správy enkapsulované do SIP správy, tak aby neboli stratené dôležité informácie o službách. Rozhrania ako proxy server, ktorý smeruje SIP REQUEST (požiadavku), nerozumie správam typu ISUP. Správy typu ISUP sú prekladané do hlavičiek protokolu SIP, tak aby bolo jasné ako bude SIP REQUEST smerovaná. Čisté správy typu SIP obsahujú všetky mechanizmy na zostavovanie a rozpad spojenia, ale nemajú definované mechanizmy na prenos informácií počas SIP session (spojenia) ako je to v ISUP (INF/INR query). Tieto medzistavové informácie by neovplyvnili nadviazané SIP spojenie. Ale prenos podobných správ aplikačnej vrstvy je vo väčšine prípadov žiadúci. 1.3.1 Popis problémov pri zabezpečení transparentnosti prenosu správ SIP SS7 SS7 - SIP požiadavky na spoluprácu transparentnosť prenosu ISUP signalizácie smerovateľnosť SIP správ v závislosti na ISUP prenos signalizačných správ ISUP počas spojenia SIP - T funkcie enkapsulácia ISUP správ do SIP preklad informácií správ ISUP do hlavičky SIP použitie metódy INFO pre takúto signalizáciu Tabuľka 1-16 -
Obr. 1.3.1 - Príklad SIP správy obsahujúcej ISUP správu 1.3.2 Typy SIP ISUP spojení Reálne v telekomunikačných sieťach môžeme uvažovať o troch prípadoch, kdey bude užitočné použiť protokol SIP T: 1, ak hovor začína v PSTN sieti a smeruje do IP sieti, teda ak volajúci volá z PSTN sieti užívateľa v IP sieti (podporujúcej SIP) 2, ak hovor začína v IP sieti a smeruje do PSTN sieti, teda ak volaný terminál je v PSTN sieti a volajúci v IP sieti 3, ak volanie smeruje z PSTN sieti do PSTN sieti ale cez veľkú IP sieť Popis SIP ISUP spojení z hľadiska výstavby a rozpadu spojenia 1, hovor smerujúci z PSTN siete do IP siete - 17 -
2, hovor smerujúci z IP siete do PSTN siete 3, hovor smerujúci z PSTN do PSTN siete cez IP sieť 1.4 Porovnanie protokolov H.323 a SIP [ 7 ] 1.4.1 SIP verzus H.323 H.323 protokol vníma IP telefóniu ako aplikáciu multimediálnych konferenčných služieb. Štandard rozširuje rodinu protokolov vyvinutých organizáciou ITU-T. SIP je novší signalizačný protokol aplikačnej vrstvy, určený na budovanie, modifikáciu a ukončenia hlasových a multimediálnych relácií medzi dvoma alebo viacerými účastníkmi vyvinutý organizáciou IETF. Architektúra protokolu je typu klient/server, je podobná HTTP, nezávislá od transportnej vrstvy, so silnou podporou SDP. Tábor podporovateľov SIP protokolu zastáva názor, že H.323 je veľmi komplexný protokol a práve SIP dokáže využiť dynamickú povahu IP sietí. - 18 -
1.4.2 Spoľahlivosť spojenia Protokol H.323 obsahuje viacero mechanizmov, pomocou ktorých je schopný vyrovnať sa s výpadkami komunikačných elementov. Napríklad ak nastane výpadok správcu brány, protokol je schopný využiť služby iného dostupného správcu. Rovnako aj v prípade, že je hovor smerovaný cez komunikačný element, ktorá zlyhal, je ho možné presmerovať cez iný dostupný element, bez nutnosti prerušenia hovoru. SIP protokol nemá definované žiadne procedúry, ktoré by umožňovali ošetrenie takýchto výpadkov. Neexistujú žiadne prostriedky na detekciu výpadku niektorého z komunikačných elementov. Jedinou výnimkou je detekcia výpadku UA, kedy pri vyslaní správy INVITE, proxy serverom, vyprší časový interval pre odpoveď od UA. To môže signalizovať jeho nedostupnosť. Protokol neumožňuje presmerovanie prebiehajúceho spojenia v prípade výpadku niektorého z aktívnych komunikačných elementov. 1.4.3 Kódovanie správ Oba protokoly prenášajú samotné hlasové a obrazové dáta v binárnej forme, komprimované pomocou niektorého z kodekov. Majú však rozdielnu reprezentáciu svojich riadiacich správ. Nároky na prenos riadiacich správ sú však neporovnateľne nižšie ako nároky na prenos samotných komunikačných dát. H.323 je binárnym protokolom, to znamená, že svoje signalizačné správy kóduje v binárnom formáte pomocou špecifikácie ASN.1. Takto zakódované správy sú v kompaktnom formáte. Ten vyžaduje menšie prenosové pásmo ako v prípade prenosu ich textovej formy. Jedinou výnimkou je komunikačný protokol H.248, ktorý umožňuje reprezentovať svoje správy rovnako v textovej, ako aj binárnej forme. Existujú štúdie, zaoberajúce sa výskumom efektivity prenosu oboch foriem správ tohto protokolu, ktoré uvádzajú, že neexistuje podstatný rozdiel v prenosových nárokoch na prenos oboch typov správ. Správy protokolu SIP sú kódované v textovej forme podľa štandardu ANSI, vďaka čomu sú čitateľné pre človeka, na rozdiel od binárnej formy správ protokolu H.323. Rovnako aj implementácia funkcií na ich tvorbu a rozoznávanie v rôznych programovacích jazykoch je omnoho jednoduchšia. Textovo kódované správy sú však väčšie ako v prípade ich binárnej reprezentácie, takže sú menej vhodné na prenos v úzkopásmovom prostredí. Organizácia IETF definovala viacero návrhov pre rôzne typy kompresie takto reprezentovaných správ. Ich použitie zaznamenalo zmenšenie veľkosti správ, avšak ich implementácia - 19 -
predstavovala omnoho väčšie výpočtové zaťaženie pre systém. Z dôvodu, že sa prenosové kapacity stále zvyšujú, je rozdiel medzi náročnosťou prenosu textových a binárnych správ oboch protokolov zanedbateľný. Naopak, práve rozdiel vo výpočtovej náročnosti a jednoduchosti implementácie sa dostáva v poslednej dobe čoraz viac do popredia a hovorí v prospech textovej reprezentácie riadiacich správ. 1.4.4 Rozšíriteľnosť štandardov a spätná kompatibilita Podpora štandardov na implementáciu novovznikajúcich požiadaviek a vlastností je zásadným znakom každého z protokolov. Návrh protokolu H.323 umožňuje pridávanie nových vlastností a služieb, a to len pomocou vydania novej verzie tohto protokolu. Ich vydávanie riadi organizácia ITUT, ktorá definuje nové funkcie, ktoré bude protokol poskytovať a zároveň dbá na spätnú kompatibilitu jednotlivých verzií. Prináša to však so sebou veľkú zložitosť protokolu a nižšiu flexibilitu v porovnaní s protokolom SIP. Spätná kompatibilita môže však byť veľkou výhodou a často ekonomickým riešením pre používateľa, ktorý požaduje súčasné nasadenie viacerých zariadení s podporou rôznych verzií tohto protokolu. Protokol SIP v sebe obsahuje mechanizmy na pridávanie nových používateľsky špecifických funkcií. Takto je umožnené výrobcom poskytovať rôzne neštandardizované funkcie, avšak s rizikom možnej nekompatibility zariadení. Protokol sa snaží byť čo najjednoduchším a obsahuje v sebe aj mechanizmy na redukciu nepoužívaných služieb. Tento prístup šetrí veľkosť kódu a redukuje tiež komplexnosť, za cenu straty spätnej kompatibility. 1.4.5 Riadenie vyrovnávania záťaže v sieti Protokol H.323 pomocou RAS správ umožňuje riadiť prevádzku cez viacero správcov prípadne brán, za účelom vyrovnania záťaže jednotlivých komunikačných elementov. SIP v sebe neobsahuje žiadnu podobnú funkciu, plne sa v dnešnej dobe spolieha na služby rozšírenia doménového pomenovacieho serveru DNS SRV (Domain Name System Service). V budúcnosti však počíta za týmto účelom využiť HTTP riadenie vyrovnania prevádzky s možnou modifikáciou pre rozoznávanie SIP hlavičiek. - 20 -
1.4.6 Účtovanie hovorov Pri ktoromkoľvek spôsobe priebehu H.323 spojenia má správca brány vždy dostatok informácií o smerovaní a trvaní hovoru, takže je veľmi ľahko schopný uskutočniť účtovanie hovorov. V SIP protokole jediným komponentom, ktorý je schopný vykonávať účtovanie hovorov, je proxy server. Tento však za týmto účelom musí počas celého trvania spojenia zostať prostredníkom medzi oboma komunikujúcimi entitami, aby bol schopný určiť presné trvanie hovoru. 1.4.7 Oneskorenie budovanie spojenia Oneskorenie sa definuje ako počet komunikačných slučiek nutných na vybudovanie spojenia medzi volaným a volajúcim. Je závislé od skutočnosti, či je použitý správca brány alebo nie. Vo verzii H.323 v1 bolo toto oneskorenie veľmi značné (6-7 slučiek). H.323 v2 (fast connect) dosiahlo výrazného zlepšenia, a to až na úroveň 2,5 slučky. SIP a H.323 v3 ešte viac zdokonalili stratégiu budovania spojenia, čím oneskorenie kleslo na hodnotu 1,5 slučky. Využívaním UDP je možné vynechať slučky asociované s transportnou vrstvou. 1.4.8 Komplexnosť H.323 je oveľa komplexnejším protokolom ako SIP. Zahŕňa H.245 pre riadenie spojenia, H.332 pre multimediálne konferencie, H.450 pre podporné služby, H.235 pre bezpečnosť a kódovanie a H.246 pre spoluprácu so sieťami s prepojovaním kanálov. Veľa služieb pritom požaduje vzájomnú interakciu týchto protokolov, čo ešte viac zvyšuje komplexnosť. Na druhej strane SIP a SDP sú menej komplikované. Jednoduchý SIP telefón obsahuje štyri základné hlavičky (To, From, Call-ID a Cseq) a tri typy požiadaviek (INVITE, ACK a BYE), čo veľmi zjednodušuje úroveň programovania a obsluhy. 1.4.9 Detekcia slučky Protokol H.323 do verzie 3 nepodporoval mechanizmus detekcie slučky. Až vo verzii 3 sa začína využívať pole Path Value Identifikácia cesty s indikáciou - 21 -
maximálneho počtu správcov brán v ceste signalizácie. Tento prístup výrazne redukuje pomer slučiek, avšak nie tak dokonale ako algoritmus použitý v SIP, ktorý je veľmi podobný BGP (Border Gateway Protocol protokol smerovania paketov). 1.4.10 Bezpečnosť H.323 definuje mechanizmus bezpečnosti pomocou podporného protokolu H.235, prípadne za účelom zabezpečenia spojenia umožňuje využiť aj SSL protokol (Secure Socket Layer protokol na bezpečný prenos informácií). SIP využíva end-to-end autorizáciu a kódovanie s podporou buď PGP (RFC 1991), alebo S/MIME (Secure Multipurpose Internet Mail Extensions štandard pre zabezpečený prenos mailových správ) (RFC 2311, 2312). Bezpečnosť komunikačného kanálu zabezpečuje využitím transportnej vrstvy na báze mechanizmov SSL alebo HTTPS. Bližší popis v kapitole 4.1. 1.4.11 Mobilita H.323 nepodporuje mobilitu klienta, pričom SIP klient nie je obmedzený na používanie jedného definovaného koncového zariadenia. Dokonca nie je obmedzený na používanie len jedného koncového zariadenia v danom čase. 1.4.12 Dodatočne podporované služby Protokol SIP podporuje schopnosť vybudovať spojene medzi dvoma komunikujúcimi stranami prostredníctvom inej nezúčastnenej strany. Táto funkcia sa označuje ako riadenie nezúčastnenou treťou stranou. V súčasnosti sa na jej implementácii do protokolu H.323 intenzívne pracuje. Na definovanie schopností multimediálnych terminálov využíva H.323 servisný protokol H.245. Možnosti terminálov sú zadefinované skupinou štruktúr (Capability Descriptor popis schopností), ktoré obsahujú veľmi precízne informácie o možnostiach každého terminálu. SIP využíva podporu SDP, takže volajúci môže pomocou požiadavky OPTION zistiť komunikačné schopnosti volanej strany. Na základe odpovede prispôsobí svoje možnosti prenosu. V súčasnosti SIP nemá tak komfortnú podporu definície schopností terminálov, akú zabezpečuje H.245. - 22 -
1.4.13 Video a dátové konferencie H.323 pomocou MCU jednotky poskytuje riadiace schopnosti pre uskutočnenie videokonferencií. Rovnako podporuje funkcie na zabezpečenie synchronizácie medzi audio a video dátovými tokmi a pomocou protokolu T.120 umožňuje uskutočňovať aj dátové konferenčné spojenia. SIP protokol obsahuje len veľmi obmedzené schopnosti pre videokonferencie a vôbec nepodporuje dátové konferencie. Nepodporuje žiadne protokoly na riadenie konferenčného spojenia za účelom synchronizácie hlasových a obrazových tokov. 1.4.14 Budovanie a ukončenie spojenia Výstavba spojenia H.323 v2 je založená na spoľahlivom transportnom protokole, preto je spojenie budované v dvoch fázach: fáza TCP a fáza volania. H.323 v3 podporuje TCP aj UDP, čo zjednodušuje procedúru budovania spojenia. SIP procedúra budovania spojenia je veľmi podobná H.323 v3. 1.4.15 Zhodnotenie Z porovnaní SIP a H.323 protokolov je zrejmé, že neustálym vývojom nových verzií signalizačných protokolov sa ich vlastnosti veľmi približujú. V každom prípade je však potrebné podotknúť, že SIP protokol v súčasnosti najmä vďaka svojej vysokej flexibilite, dynamickosti a jednoduchej implementácii stále čoraz viac naberá na význame. Protokol H.323 ťaží hlavne zo svojej bohatej histórie a širokého rozšírenia. Poskytuje obrovské množstvo funkcií, z ktorých mnohé chýbajú stále sa rozvíjajúcemu protokolu SIP, alebo nedosahujú porovnateľnú kvalitu. Na druhej strane protokol SIP prináša množstvo nových služieb, hlavne v oblasti lokalizácie, možností tzv. objednania si hovoru, alebo nastavenia preferovania určitej formy komunikácie. Z týchto dôvodov bude v ďalších kapitolách spracovaná téma VoIP so zameraním sa na signalizačný protokol SIP. - 23 -
2. PROTOKOLY ZABEZPEČUJÚCE PRENOS DÁT V REÁLNOM ČASE (zabezpečujúce paketizáciu) 2.1 Protokoly RTP (Real-time Transport Protocol) a RTCP (Real-time Transport Control Protocol) Prenos dát v reálnom čase vyžaduje výkonnú komunikačnú sieť. To znamená, že musí spĺňať vysoké nároky na prenosovú rýchlosť, oneskorenie a kvalitu služieb. To je hlavný rozdiel medzi prenosom statických dát a prenosom dát v reálnom čase. Preto protokoly bežne používané pre prenos statických dát nevyhovujú prenosom dát v reálnom čase. Protokoly, ktoré sú vhodné pre spoľahlivý prenos dát v sieti s malou šírkou pásma sú protokoly HTTP a FTP. Sú založené na protokoloch TCP/IP. Platí, že ak je paket stratený či poškodený, dojde k jeho opätovnému vyslaniu. Z tohto dôvodu sa pre prenos dát v reálnom čase používajú iné protokoly ako TCP. Jeden z najčastejšie používaných protokolov je UDP (User Datagram Protocol). UDP je nespoľahlivý protokol, ktorý nezaručuje, aby každý vyslaný paket bol doručený do cieľa. Dokonca nezaručuje ani to, aby pakety dorazili v správnom poradí. Internetovým štandardom pre prenos dát v reálnom čase je protokol RTP [ 8 ] [ 9 ] [ 10 ], ktorý využíva protokol UDP. Obr. 2.1.1 Začlenenie RTP v architektúre protokolov RTP môže byť použitý ako pre unicastové (pre každý cieľ je vysielaná zo zdroja jedna kópia) tak aj pre multicastové (dáta sú vysielané zo zdroja jedenkrát a záleží od siete, aby zaistila prenos dát do rozdielnych miest) služby siete. - 24 -
2.1.1 Služby RTP RTP umožňuje pred samotným začatím prenosu identifikovať typ dát, ktoré budú prenášané, určiť poradie paketov v akom budú dáta posielané a synchronizovať dátové toky z rozdielnych zdrojov. Pre dátové pakety RTP nie je garantované, že dorazia v poradí v akom boli vysielané, ani nie je garantované, že dorazia všetky. Je na adresátovi, aby rekonštruoval poradie prijatých paketov a detekoval neprijaté pakety pomocou informácií v záhlaví paketu. Zatiaľ čo RTP neposkytuje žiadny mechanizmus k zaisteniu včasného doručenia alebo k poskytnutiu záruky QoS (Quality of Service - kvalita služieb), sú tieto mechanizmy poskytované kontrolným protokolom RTCP, ktorý umožňuje sledovanie kvality distribúcie dát. RTCP tiež poskytuje kontrolný a identifikačný mechanizmus pre RTP prenosy. Obr. 2.1.2 - Príklad RTP session (spojenia) Vytvorenie RTP session (spojenia) je vlastne asociácia skupiny aplikácií, komunikujúcich s RTP. Session (spojenie) je identifikované sieťovou adresou a párom portov. Jeden port je určený pre prenos dát a druhý port je určený pre RTCP kontrolné dáta. Účasť na spojení môže byť pasívny príjem dát, vysielanie dát alebo oboje (príjem aj vysielanie). Každý rozdielny typ dát je prenášaný iným spojením (session). Napríklad ak je pri videokonferencii prenášaný zvuk aj obraz zároveň, je jedno spojenie určené pre prenos audio a druhé spojenie pre video dáta. To umožní účastníkovi výber typu dát, ktorý chce prijímať (napr. ak je niekto v mieste s nízkou šírkou pásma). - 25 -
2.1.2 Štruktúra RTP a RTCP paketov Dátový paket RTP (znázornený na obrázku 2.1.3) Obr. 2.1.3 - Dátový paket RTP Popis jednotlivých bitov v pakete a vysvetlenie významu: V verzia RTP protokolu (2 bity) P doplnenie (1 bit), ak je tento bit nastavený, je na konci paketu jeden alebo viacej bytov, ktoré nie sú súčasťou užitočného obsahu. Úplne posledný byte v pakete indikuje počet doplnených bytov. Doplnenie je využívané niektorými šifrovacími algoritmami. X extension (rozšírenie) 1 bit, ak je tento bit nastavený, nasleduje za pevným záhlavím jedno rozšírené záhlavie. Tento mechanizmus umožňuje vloženie rozširujúcich informácií do záhlavia RTP. CSRC (CC) - 4 bity, je to počet CSRC identifikátorov, ktoré nasledujú za pevným záhlavím. Ak je počet CSRC nula, je zdrojom synchronizácie zdroj užitočného obsahu. M záložka 1 bit, záložkový bit definovaný konkrétnym profilom média. PT typ užitočného obsahu 7 bitov, index z tabuľky profilu média, ktorý popisuje formát užitočného obsahu. Sequence Number 16 bitov, jedinečné číslo paketu, ktoré popisuje pozíciu paketu v poradí paketov. Číslo paketu je inkrementované po každom odoslanom pakete. RTP timestamp 32 bitov, vyjadruje moment odobrania vzorky prvého bytu užitočného obsahu. - 26 -
SSRC 32 bitov, identifikuje synchronizačný zdroj. Ak je počet CSRC nula, je zdroj užitočného obsahu zdrojom synchronizácie. Ak je CSRC nenulové, SSRC identifikuje mixér. Sample data bits samotné prenášané dáta (prispievajúcich zdrojov do užitočného obsahu môže byť max. 16 a počet určuje pole CSRC (CC) ) Kontrolný paket RTCP Ako dodatok k multimediálnym dátam pre spojenie, sú pakety kontrolných dát RTCP zasielané všetkým účastníkom spojenia. RTCP pakety môžu obsahovať informácie o QoS (kvalita služieb) pre účastníkov spojenia, informácie o zdroji dát na dátovom porte a štatistiky k dátam, ktoré boli doteraz prenášané. Je niekoľko typov RTCP paketov: - sender report (správa odosielateľa) SR - receiver report (správa príjemcu) RR - source description (popis zdroja) SDES - BYE, APP a iné RTCP pakety sú zlúčiteľné a sú zasielané ako skupina minimálne dvoch paketov (report paket a paket popisu zdroja). Všetci účastníci spojenia posielajú RTCP pakety. Účastník, ktorý nedávno poslal paket, vydáva správu odosielateľa. Tá obsahuje celkový počet odoslaných paketov a bytov a aj informáciu, ktorá môže byť využitá k synchronizácii toku médií z iných spojov. Účastníci spojenia posielajú v pravidelných intervaloch správu príjemcu určenú pre ostatné zdroje, z ktorých prijímajú dátové pakety. Správa príjemcu obsahuje informáciu o počte stratených paketov, najvyššie číslo poradia a TIMESTAMPu, ktorý môže byť použitý k odhadu obojsmerného oneskorenia medzi odosielateľom a adresátom. Prvý paket v skupine RTCP paketov musí byť paket správy aj v prípade, že neboli prijaté ani odoslané žiadne dáta. Všetky skupiny RTCP paketov musia obsahovať popis zdroja (SDES), ktorý obsahuje kanonické meno (CNAME) identifikátor zdroja. Popis zdroja môže obsahovať aj ďalšie informácie ako je meno zdroja, emailová adresa, telefónne číslo, zemepisná poloha, názov aplikácie alebo správu popisujúcu aktuálny stav zdroja. Pokiaľ už zdroj nie je aktívny, pošle RTCP protokol paket BYE. V správe môže byť zahrnutý dôvod zrušenia spojenia. Paket APP poskytuje aplikáciám mechanizmus pre definovanie a zasielanie užívateľských informácií cez RTP riadiaci port. - 27 -
RTCP SR (sender report) správa odosielateľa (obr. 2.1.4) Správy SR umožňujú medzizdrojovú synchronizáciu, zabezpečujú meranie parametrov pre prenos RTP, spätnú väzbu o prenesených dátach, prenášajú pakety odosielateľa a počítadlo bytov, umožňujú príjemcovi kalkulovať so stratami a zahrňujú správy RR pre odosielateľa. Popis polí v pakete: Obr. 2.1.4 RTCP SR V verzia RTP protokolu (2 bity) P doplnenie (1 bit), ak je tento bit nastavený, je na konci paketu jeden alebo viacej bytov, ktoré nie sú súčasťou užitočného obsahu. Úplne posledný byte v pakete indikuje počet doplnených bytov. Doplnenie je využívané niektorými šifrovacími algoritmami. RC počet identifikátorov RT=RR=200 identifikácia, že sa jedná o SR Length dĺžka paketu Sender SSRC synchronizačné číslo odosielateľa NTP timestamp + RTP timestamp = medzizdrojová synchronizácia NTP timestamp meranie a kontrola parametrov pri prenose Cumulative number of packets sent celkové číslo poslaných paketov Cumulative number of octets sent celkové číslo poslaných Bytov - 28 -
RTCP RR (receiver report) správa príjemcu (obr. 2.1.5) Správy RR predovšetkým odpovedajú a posielajú spätnú väzbu o parametroch pre RTP prenos (oneskorenie, poradové číslo, jitter, strata paketov...) a upravujú na základe týchto parametrov kodek, prenosovú rýchlosť a iné parametre. Popis polí v pakete: Obr. 2.1.5 RTCP RR V verzia RTP protokolu (2 bity) P doplnenie (1 bit), ak je tento bit nastavený, je na konci paketu jeden alebo viacej bytov, ktoré nie sú súčasťou užitočného obsahu. Úplne posledný byte v pakete indikuje počet doplnených bytov. Doplnenie je využívané niektorými šifrovacími algoritmami. RC počet identifikátorov RT=RR=201 identifikácia, že sa jedná o RR Length dĺžka paketu Sender SSRC správa o SSRC odosielateľa SSRC of sender reported in this block popis SSRC Fraction lost strata rámcov Cumulative number of packets lost priemerné číslo straty paketov Extended highest sequence number received najvyššie prijaté sekvenčné číslo Interarrival jitter správa o jitteri po prijatí paketu Last SR posledná SR DLSR oneskorenie od poslednej SR Further receiver report blocks ďalšie bloky odpovedí príjemcu - 29 -
Receiver report block blok odpovede príjemcu RTCP SDES (source description) popis zdroja (obr. 2.1.6) Správy slúžia na popis a identifikáciu zdroja ako CNAME, NAME, EMAIL, PHONE, LOC, TOOL, PRIV (kanonické meno, meno, email, tel.č., poloha, nástroj, privátne rozmery) Popis polí v pakete: Obr. 2.1.6 RTCP SDES V verzia RTP protokolu (2 bity) P doplnenie (1 bit), ak je tento bit nastavený, je na konci paketu jeden alebo viacej bytov, ktoré nie sú súčasťou užitočného obsahu. Úplne posledný byte v pakete indikuje počet doplnených bytov. Doplnenie je využívané niektorými šifrovacími algoritmami. SC počet identifikátorov RT=RR=202 identifikácia, že sa jedná o SDES Length dĺžka paketu SDES chunk časť SDES Sender SSRC synchronizačný zdroj odosielateľa SDES items chunk pole pre SDES aplikácie Further SDES chunks ďalšie polia SDES SDES item data dáta aplikácie SDES Item type typ aplikácie Item length dĺžka aplikácie - 30 -
2.1.3 Prenos RTP/RTCP paketov v UDP paketoch Na obrázku 2.1.7 je znázornený prenos RTP/RTCP v UDP pakete a následne prenos do sieťovej vrstvy do IP paketu. Obr. 2.1.7 Prenos RTP/RTCP v UDP pakete 3. ANALÝZA POŽIADAVIEK PRIVÁTNYCH SIETÍ NA BEZPEČNOSŤ PRIPOJENIA DO KONVERGOVANEJ SIETE INÝCH OPERÁTOROV A BEZPEČNOSTNÉ A IMPLEMENTAČNÉ PROBÉMY (z hľadiska VoIP cez protokol SIP) 3.1 Kategorizácia privátnych sietí z hľadiska nárokov na bezpečnostnú politiku V súvislosti s rastúcou zložitosťou počítačových systémov, neskôr kombinovaných s komunikačnými prostriedkami a súhrnne nazývanými informačnými technológiami, sa postupne ukázala nutnosť otázku bezpečnosti neobmedzovať len na počítačové systémy, ale chápať ju komplexnejšie. Táto zmena vnímania sa odrazila aj v zmene názvu disciplíny namiesto pojmu počítačová bezpečnosť sa začal presadzovať pojem informačná bezpečnosť, ktorý lepšie vystihoval podstatu problému (bezpečnosť informácii bez ohľadu na to, kde sa práve nachádzajú). Naviac sa ukázalo, že prudký rozvoj IT ako aj rozličných metód útokov na systémy IT si vyžaduje špecializáciu - 31 -
vybudovanie účinného systému zabezpečenia systémov IT už presahuje sily a kvalifikáciu bežného špecialistu na informačné technológie informatika. Je veľmi dôležitým aspektom zaoberať sa analýzou potrebných bezpečnostných požiadaviek zákazníkov (firiem). Z hľadiska providera to má nesmierny význam v snahe získať zákazníka na svoju stranu. V dnešnej dobe sú informácie o konkurencii strategickým materiálom v boji o zákazníka. Preto je pochopiteľné, že každý subjekt na trhu sa snaží všetkými možnými spôsobmi chrániť informácie. Firmy obchodujú na trhu online, preposielajú sa strategické informácie medzi pobočkami, telefonujú atď. Špeciálne telefónický kontakt je veľmi nevyhnutný. Vo väčšine veľkých firiem prevláda názor, že je nevyhnutné takúto formu komunikácie chrániť (šifrovať). A platí to aj pri implementovaní VoIP. Predtým ako sa začneme niečo chrániť pred potenciálnymi útočníkmi, je nutné urobiť analýzu, čo daný zákazník potrebuje. Uvediem príklad: je asi nezmyselné chrániť firmu vyrábajúcu klince, kde nebezpečenstvo odcudzenia strategických informácií je minimálne. Ak by ale daná firma mala recept na to ako z kila železa urobiť 10 kg klincov, je už potom namieste uvažovať o ochrane údajov. Preto je veľmi potrebné zaoberať sa rozdelením zákazníkov do kategórií (v zmysle potreby ochrany ich údajov). Je to ale veľmi individuálne a záleží to od konkrétnych požiadaviek zákazníka. Vo väčšine prípadov však platí: čím má firma väčší podiel na trhu, tým sú jej nároky na bezpečnosť vyššie. Samozrejme s výnimkou inštitúcií, ktoré majú zhromaždené iné dôležité informácie (armáda, banky, zdravotníctvo, školstvo, telekomunikácie a iné). K takýmto subjektom je nutné pristupovať špecificky. V analýze sú ponúknuté rozdelenie zákazníkov a stručne špecifikované ich predpokladané požiadavky na bezpečnosť siete. 3.1.1 Rozdelenie zákazníkov na subjekty s odlišnými požiadavkami na bezpečnosť Malé subjekty (malé privátne siete) Do tejto kategórie by som zaradil subjekty pôsobiace na trhu, ktoré zamestnávajú do 10 zamestnancov. Zväčša sú to subjekty pôsobiace v nejakom regióne a ich postavenie na trhu nie je strategické. V ojedinelých prípadoch vlastní takáto firma strategické informácie (ak takýto subjekt je len pobočkou veľkého subjektu alebo regionálny úsek strategického subjektu, napr.pobočka banky). Ale vo väčšine prípadov nevyžadujú zvýšenú bezpečnosť ich informačnej infraštruktúry. Zväčša je ich informačná štruktúra - 32 -
tvorená niekoľkými počítačmi a telefónmi. Z hľadiska implementovania novej služby akou je VoIP, prevláda ich pozitívny názor a radi uvítajú toto lacnejšie a komplexnejšie riešenie. Z hľadiska zabezpečenia ich siete im postačujú klasické a finančne pre nich dostupné riešenia. Samozrejme s výnimkou subjektov, ktoré sa potrebujú chrániť formou zvýšenej úrovne zabezpečenia. Pre providerov je tento segment zákazníkov dobrou víziou do budúcnosti z hľadiska nasadzovania novej služby VoIP. Často je v praxi tento segment zákazníkov nazývaný rezidenčný segment. Uplatňovaná bezpečnostná politika a prepojenie s providerom: Prepojenie: Telefónna linka, ISDN, xdsl, bezdrôtové prepojenie (WiFi) z hľadiska ceny, spoľahlivosti a bezpečnosti je toto riešenie pre takéhoto zákazníka postačujúce Bezpečnosť: vo väčšine prípadov bezheslová politika, nešifrované spojenia, priame prepojenie do internetu (modem, router) alebo cez malý server, kancelárske softwarové balíky, často bez Firewallu, antivírová ochrana, VoIP bez nutnosti šifrovania Požiadavky na VoIP: nie je nutné šifrovať, možnosť dovolať sa Obr. 3.1.1 a 3.1.2 Pripojenie malej organizácie k internetu Stredné subjekty (stredne veľké privátne siete) Sem možno zaradiť subjekty s väčším podielom na trhu a väčším počtom zamestnancov ako 10 a menším ako 25. Zväčša opäť pôsobia v nejakom regióne. Ich nároky sú v porovnaní s malými subjektami v podstate identické, s výnimkou strategických subjektov. Vo všeobecnosti je dobré takýmto subjektom implementovať určité bezpečnostné pravidlá z hľadiska ich budúceho vývoja. Je dobré, aby aj zamestnanci takéhoto subjektu pristupovali zodpovedne k bezpečnosti informácií a snažili sa dodržovať stanovené pravidlá (heslová politika, antivírová ochrana, softwarový firewall, práca na internete, atď). Pre subjekty tohto typu je tiež výhodné implementovať VoIP. Z hľadiska zabezpečenia takéhoto subjektu existuje mnoho finančne dostupných a veľmi efektívnych riešení. Pre malé a stredné firmy je veľmi dobrým riešením - 33 -
poskytnutie informačných služieb na báze IP. Oceňujú najmä lepšiu cenovú dostupnosť a jednoduchosť riešenia. Uplatňovaná bezpečnostná politika a prepojenie s providerom: Prepojenie: Telefónna linka, ISDN, xdsl, bezdrôtové prepojenie (WiFi) z hľadiska ceny, spoľahlivosti a bezpečnosti je toto riešenie pre takéhoto zákazníka postačujúce Bezpečnosť: heslová politika, nešifrované spojenia, prepojenie do internetu cez router (často nenastavený Firewall), mail server (často pripojený priamo na prístupový router), často povolené všetky služby, VoIP nešifrované, antivírová ochrana, antispyware Požiadavky na VoIP: nie je nutné šifrovať, možnosť dovolať sa Veľké subjekty (veľké privátne siete) Za veľké subjekty v tomto rozdelení by som považoval firmy, ktoré majú viac ako 25 a menej ako 200 zamestnancov. Sem by som zaradil veľkú škálu subjektov pôsobiacich jednak na regionálnej, národnej a nadnárodnej úrovni. Z hľadiska bezpečnosti ich privátnych sietí, tvoria tieto subjekty špecifickú kategóriu. Je nutné si uvedomiť, že je veľmi dôležité konzultovať s takýmto subjektom ich požiadavky, kritériá a potreby na zabezpečenie ich privátnej siete. Možno predpokladať, že väčšina takýchto subjektov si potrebuje chrániť svoje informačné systémy voči Internetu. Preto musí jednak samotná firma a jej tím správy IT bezpečnosti v spolupráci s providerom konzultovať možné bezpečnostné slabiny a hľadať spoločné riešenia. Na druhej strane je veľmi dôležité, aby samotná firma urobila maximum pre zabezpečenie svojej siete a zaviedla pravidlá, ktorých dodržiavanie by mala striktne sledovať v rámci celej firmy. Najdôležitejšie sú: 1. používanie silných hesiel a ich pravidelná obmena 2. opatrnosť pri narábaní s prílohami e-mailu a pri sťahovaní softvéru z webu 3. inštalácia a používanie antivírusových programov 4. inštalácia a používanie firewall 5. odstránenie nepoužívaného softvéru a používateľských účtov a čistenie vyraďovaného zariadenia od údajov 6. kontrola fyzického prístupu k zariadeniam 7. zálohovanie dôležitých súborov, adresárov a programov 8. včasné aplikovanie bezpečnostných záplat - 34 -
9. implementácia ďalších prvkov sieťovej bezpečnosti 10. obmedzenie prístupu k citlivým a dôverným údajom 11. plán riadenia bezpečnostných rizík 12. využitie externej špecializovanej podpory Na obr. 3.1.3 je znázornený príklad štruktúry siete takéhoto subjektu (predpokladám, že daný subjekt dodržuje štandardné implementovanie bezpečnostnej politiky). Sieť takéhoto subjektu musíme chápať ako celok, aj keď je často tvorená z viacerých regionálnych sietí. Z pohľadu implementácie služby VoIP požadujú zabezpečenie takejto dátovej komunikácie. Momentálne prevládajú obavy takýchto subjektov pri nasadzovaní VoIP do ich sieťovej infraštruktúry hlavne kvôli obave z napadnutia ich siete. V kapitolách 4.1, 4.2, 4.3 a 4.4 sú popísané možné bezpečnostné riešenia pri implementácii VoIP. Uplatňovaná bezpečnostná politika a prepojenie s providerom: Prepojenie: xdsl z hľadiska spoľahlivosti a bezpečnosti je toto riešenie pre takéhoto zákazníka nepostačujúce, z hľadiska ceny výhodné Prenajatý okruh (Lease Line) z hľadiska spoľahlivosti a bezpečnosti je riešenie postačujúce, z hľadiska ceny nevýhodné MPLS - z hľadiska spoľahlivosti, ceny a bezpečnosti je toto riešenie pre takéhoto zákazníka postačujúce (častý prípad prepojenia takéhoto subjektu a providera) Ethernet (CISCO) - veľmi progresívne sa vyvíjajúca technológia, navyše nepotrebuje žiadne iné prenosové systémy na 1. vrstve (SDH/SONET). Ukazuje sa, že siete tohto typu sa postupne budú čoraz viac presadzovať na celom svete. Hlavnými dôvodmi je jednoduchosť riešenia, komplexnosť a hlavne cena. Bezpečnosť: Firewally, VPN (virtuálne privátne siete), často DMZ (demilitarizované zóny), heslová politika, antivírová ochrana, antispyware, často povolené len určité služby (http, SMTP, POP3), access listy, prepojenie často cez router (Firewall, NAT) Požiadavky na VoIP: šifrovanie SIP, šifrovanie RTP, access listy, spoľahlivosť (možnosť dovolať sa aj pri výpadku v sieti) - 35 -
Obr. 3.1.3 - Príklad siete veľkého subjektu Nadnárodné subjekty (nadnárodné privátne siete) Do tejto kategórie zaradím subjekty nad 200 zamestnancov, ktoré pôsobia na medzinárodnej pôde. Subjekty tohto typu majú veľmi dobre rozvinutú a zaužívanú bezpečnostnú politiku, o ktorú sa im starajú tímy špecialistov v tejto oblasti. Pre ne platia všetky doposiaľ spomenuté kritériá bezpečnosti, pričom, riziko útoku na takúto sieť je značne väčšie. Pre providera bude ťažké presadiť u takéhoto subjektu služby VoIP bez toho, aby mu poskytol komplexné riešenie. Záleží len od poskytovateľa služieb ako sa dokáže s touto výzvou a problémom vysporiadať. Aj tu existujú dostupné riešenia bezpečnostných problémov, tak aby bol takýto zákazník spokojný. Samozrejme, že aj v tomto prípade má zmysel uvažovať nad výhodami a možnosťami VoIP cez SIP. Hlavne je dobré spomenúť výhodné volania do zahraničia (v rámci firmy ale aj do iných sietí) cez IP sieť. Je teda dobré uvažovať nad touto možnosťou aj zo strany providera ako aj zo strany zákazníka. Z prieskumu medzi takýmito zákazníkmi vyplýva pre providera splniť niekoľko nutných požiadaviek. Uplatňovaná bezpečnostná politika a prepojenie k providerovi: Prepojenie: SONET/SDH spoľahlivosť, bezpečnosť a primeraná cena - 36 -
ATM spoľahlivosť, bezpečnosť a z hľadiska, že túto technológiu nasadzovalo v minulosti veľa spoločností, je takýto spôsob prepojenia pre veľa zákazníkov výhodný, cenovo však dosť náročný Ethernet (CISCO) do popredia sa dostávajúci spôsob prepojenia, vysoko spoľahlivý a flexibilný, spoločnosti postupne prechádzajú na tento spôsob prepojenia (nízka cena) Bezpečnosť: Firewally, VPN (virtuálne privátne siete), často DMZ (demilitarizované zóny), heslová politika, antivírová ochrana, antispyware, často povolené len určité služby (http, SMTP, POP3) a prístup k nim majú len určité skupiny, access listy, prepojenie často cez router (Firewall, viacnásobný NAT), v rámci Intranetu https, servre na báze CITRIX, mail server s distribuovanou štruktúrou, k informáciám majú prístup len oprávnení užívatelia Požiadavky na VoIP: šifrované SIP, RTP, kontrola prístupu, overovanie na základe certifikátov, IPsec, spoľahlivosť služby na 99,999% (dovolatelnosť aj pri výpadku v sieti providera), decentralizovaná štruktúra Na obrázku 3.1.4 je príklad štruktúry siete nadnárodného subjektu. Obr. 3.1.4 - Príklad štruktúrý siete nadnárodného subjektu Špecifické subjekty (špecifické privátne siete) Do tejto kategórie zaradím subjekty ako banky, armáda, telekomunikácie, zdravotníctvo, školstvo a iné. Táto kategória privátnych sietí je veľmi špecifická kvôli tomu, že sa nedajú presne zovšeobecniť požiadavky a potreby na bezpečnosť. Je veľký rozdiel v zabezpečení privátnej siete banky a privátnej siete školy. Akademická pôda je - 37 -
predsa len volnejšie prostredie ako striktné prostredie v sieti banky. V sieti subjektu akým je banka si nemôžeme dovoliť ani len najmenšiu chybu, pretože hrozí veľké nebezpečenstvo. Na akademickej pôde tiež hrozí nebezpečenstvo útoku hackerom, ale škody spôsobené nie sú až tak závažné ako v prípade banky. Práve kvôli tomuto rozdielu som tieto subjekty zaradil do kategórie špecifické. Pri implementovaní nových služieb do siete takéhoto subjektu, treba hľadať spoločné riešenia aj zo strany subjektu a aj zo strany providera. 3.2 Bezpečnostné a implementačné problémy protokolu SIP pri službe VoIP V tejto časti sa budem venovať službe VoIP z pohľadu protokolu SIP (signalizácia). Poukážem na problematické miesta pri implementovaní takejto služby (VoIP cez SIP). [ 11 ] 3.2.1 VoIP SPAM a lokalizácia pôvodu spojenia SPIT (Spam over Internet Telephony) nevyžiadané dáta prostredníctvom internetovej telefónie. Pri signalizačnom protokole SIP je hrozba takéhoto SPAMu veľmi reálna. Ako už bolo spomínané a vysvetlené, protokol SIP je aplikačným protokolom a signalizačné správy sú v textovom formáte. Preto takýto SPAM môžeme považovať za značnú hrozbu. SIP nedokáže automaticky zistiť pôvod signalizačných správ, nakoľko útočník môže správy generovať a posielať ich ako inicializáciu SIP session (spojenia) svojej obeti. Útočník to môže využiť a môže nadviazať viacero takýchto nevyžiadaných spojení (voice SPAM) a tým zahltiť a vyradiť tak uzol obsluhujúci SIP spojenia. Alebo na druhej strane si útočník prostredníctvom SIP signalizácie môže cez SDP protokol dohodnúť vhodné 2 porty a cez tieto porty potom získať privilégiá a preniknúť tak do siete obete. 3.2.2 DoS (Denial of Service) odoprenie služby Pri VoIP službe sa jedná o zahltenie uzla obsluhujúceho SIP spojenia, deregistráciu zariadení z register servera (čo v konečnom dôsledku znamená, že zariadenia nemôžu prijímať/uskutočňovať hovory) a ukončovanie nadviazaných spojení (call - 38 -
termination by 3rd party). Dôvody prečo môže dojsť k takýmto situáciám (DoS) sú nepovinná autentifikácia a chýbajúci automatický mechanizmus overovania správ. 3.2.3 Neautorizované smerovanie volania Na obrázku 3.2.1 je znázornený takýto prípad neoprávneného smerovania hovoru v sieti. Útočník (prvý) volá terminál A, terminál A volá terminál B, terminál B potom C atď. Takéto neautorizované (nepovolené) smerovanie volania môže útočník využiť na vyradenie viacerých terminálov (klientov) v sieti. Opäť dôvodmi prečo takáto situácia môže nastať sú nepovinná autentifikácia a chýbajúci automatický mechanizmus overovania správ. Obr. 3.2.1 - Neautorizované smerovanie volania 3.2.4 Neautorizovaná registrácia terminálu (klienta) a odpočúvanie Útočník si zaregistruje na register serveri ďalšieho klienta (terminál) pod SIP URL obete. Takýmto spôsobom útočník prijíma všetky volania smerujúce poškodenému užívateľovi. Príklad je znázornený na obrázku 3.2.2. - 39 -
Obr. 3.2.2 - Odpočúvanie 3.2.5 Získanie údajov o registrovaných klientoch (Directory Harvesting) Jedná sa o zneužitie príkazov REGISTER na získanie kompletného listu registrovaných klientov na register serveri. Útočník tak má možnosť zahlcovať jednotlivých klientov v privátnej sieti neoprávnenými a falošnými SIP spojeniami (VoIP SPAM). Ak je samozrejme daná sieť málo zabezpečená, útočník získa ďalšie privilégiá na manipuláciu so SIP klientami, registrovanie neoprávnených SIP klientov, poprípade odcudzenie dôležitých informácií zo siete poškodeného. 3.2.6 Impersonifikácia SIP servera (vydávanie sa za server) Útočník sa vydáva za SIP proxy/register server, a tým získa kontrolu nad všetkými SIP správami a nad všetkými volaniami prechádzajúcimi cez SIP server. Na obrázku 3.2.3 je znázornený takýto prípad. Obr. 3.2.3 - Impersonifikácia SIP servera (útočník je umiestnený medzi Proxy servermi alebo medzi Proxy a UA) - 40 -
3.2.7 Falšovanie správ (Message Tampering) Falšovanie správ je možné ak útočník dokáže odchytiť a modifikovať pakety prechádzajúce medzi SIP zariadeniami. Falšovanie správ môže zapríčiniť de-registráciu UA, impersonifikáciu SIP serverov alebo môže byť zamerané na atakovanie iných komponentov v sieti ako Firewall, brána a iné. Príklad je zobrazený na obrázku 3.2.4. Obr. 3.2.4 - Falšovanie správ(útočník získava prístup ku každému sieťovému prvku) 3.2.8 Zhodenie spojenia (Session Tear Down) Takáto situácia nastane ak útočník spozoruje SIP signalizáciu a pošle falošné SIP BYE správy obom UA. Veľa SIP UA nepožaduje autentifikáciu, preto útočník dokáže takúto situáciu využiť a poslať obom UA správu BYE a tým zhodiť spojenie. Obrázok 3.2.5 ilustruje danú situáciu. Obr. 3.2.5 - Zhodenie spojenia Ak UA nedokáže kontrolovať pakety, útočník nemusí zachytiť SIP signalizáciu, stačí mu ak pozná IP adresu UA (moja brána, SIP telefón, X-lite atď) a pošle správu BYE a tak - 41 -
ukončil nadviazané spojenie. Ďalším príkladom zhodenia spojenia je zahltenie Firewallu BYE správami tak, že sa zahltia UDP porty pre legitímne volania. 3.2.9 Ďalšie možné útoky a prehľad najčastejších bezpečnostných problémov Útoky tohto typu by som rozdelil do dvoch skupín útoky smerujúce na sieťové prvky a útoky zamerané na aplikačné vybavenie sieťových prvkov. Do prvej kategórie by som zaradil: syn flood, smurfing, IP spoofing a iné. Do druhej kategórie by som zaradil útoky zamerané na pretečenie pamäte aplikačných vybavení serverov (buffer overflow attacks). Pre ilustráciu by som do tejto časti zaradil tabuľku 2, ktorá vyjadruje najčastejšie bezpečnostné problémy pri SIP a následky týchto problémov. [ 12] problém odpočúvanie: neautorizované zachytenie a dekódovanie signalizačných správ vírusy a trójske kone opätovné vysielanie správ spoofing:vydávanie sa za legitímneho užívateľa manipulácia so správami záplava SYN na Proxy/Register servery SIP IP telefóny: TFTP(trivial FTP), odpočúvanie, DHCP, spoofing, telnet následok zníženie súkromia a dôveryhodnosti DoS/neautorizovaný prístup DoS neautorizovaný prístup riziko neúplnosti správ, DoS DoS DoS, neautorizovaný prístup, zníženie súkromia Tabuľka 2 - Najčastejšie problémy pri SIP protokole 3.2.10 Firewall a SIP Vzájomná súčinnosť Firewallu a SIP protokolu je veľmi dôležitým aspektom pri implementácii služieb VoIP. Ako som spomínal v predošlých kapitolách, prenos správ protokolu SIP je realizovaný prostredníctvom protokolu UDP (vyššie verzie aj TCP) a príslušného portu. Štandardne pre signalizáciu je to port 5060. Ako som spomenul, SIP signalizácia dohoduje mediálne spojenie medzi volajúcim a volaným. Použité sú protokoly RTP a RTCP, pričom sú zapúzdrené v UDP datagrame. V tomto prípade sú využité 2 dynamické porty z rozsahu 1024-65535. Danú situáciu dobre ilustruje obr. - 42 -
1.2.10. Keďže hovorím o implementačných problémoch VoIP cez SIP, uvediem príklad kde takýto problém môže nastať. IT správca firmy RUDKO sa rozhodne, že na Firewalle, ktorý robí prvotné filtrovanie protokolov a portov zakáže všetky prichádzajúce UDP datagramy do jeho siete. Odchádzajúce UDP a porty sú povolené. Ak takáto firma má službu VoIP cez SIP, potom nastane to, že síce UA sa budú snažiť prihlásiť na SIP proxy, ale neprihlásia sa nakoľko na Firewalle sa všetky UDP pakety prichádzajúce zo SIP proxy dropnú (obr. 3.2.6). Týmto príkladom chcem vyjadriť prečo je vážnym implementačným problémom SIP vs. Firewall. Preto ak by správca RUDKO chcel vyhovieť zamestnancom, aby mohli volať a aby mohli prijímať hovory, musel by na Firewalli povoliť UDP a porty 5060 pre signalizáciu a 1024 65535 pre mediálny tok. Samozrejme takýmto krokom sa dostaneme do situácie, že SIP vs. Firewall sa stáva aj vážnym bezpečnostným problémom. Potenciálny útočník môže takéto otvorenie portov veľmi rýchlo zneužiť. Preto stále pretrváva obava IT správcov pred implementáciou SIP. Mojou snahou je ukázať, že riešenia takéhoto problému existujú a v ďalších kapitolách sa nimi budem zaoberať. Obr. 3.2.6 Príklad konfigurácie Firewallu 3.2.11 NAT (Network Address Translation) a SIP NAT je logická funkcia, zväčša používaná na zariadení tvoriacom rozhranie medzi sieťami, ktorá prekladá interné (privátne) IP adresy na externé (verejné) IP adresy. NAT zariadenia sú hardwarové/softwarové entity, ktoré pracujú na TCP/IP vrstve. NAT robí značný problém VoIP komunikácii, hlavne kvôli tomu, že protokoly VoIP sú protokoly vyšších vrstiev. Ak nejaký protokol z aplikačnej vrstvy obsahuje IP adresu a porty v tele TCP/IP paketu, NAT v takomto prípade zlyháva. Existuje ale niekoľko možností ako riešiť tento problém, ale najlepším riešením tohto problému je kombinácia viacerých - 43 -
riešení. Ukážem niekoľko príkladov, kedy je nutné zaoberať sa problematickou implementáciou SIP cez NAT: Dynamické IP porty: SIP zostavuje spojenia medzi doposiaľ neznámymi IP adresami a dynamicky pridelenými portami. Tu teda nie je možné stanoviť striktné pravidlá na Firewalli. Okrem toho tieto IP adresy a porty sa môžu počas spojenia meniť. IP adresa v tele paketu: Mnohé SIP hlavičky (napr. contact, record-route, via, from, to) obsahujú polia, v ktorých môžu byť použté IP adresy namiesto doménových mien. Toto vedie k problémom pri zostavovaní SIP session (spojenia), pretože IP adresy sú zvyčajne privátne a nie sú prístupné zariadeniam z vonku (z verejnej siete). A práve preto je potrebné aby tieto adresy boli na NAT zariadení preložené na verejne dostupné adresy. Životnosť: Na NAT zariadení je verejná IP adresa preložená na privátnu IP adresu, ktorá má určitú životnosť T. Ak na NAT zariadení nie je žiadna prevádzka určitú dobu T alebo spojenie bolo explicitne už ukončené, ukončí NAT zariadenie aj preklad adries. SIP INVITE správa, ktorá smeruje z privátnej IP adresy cez NAT na verejnú IP adresu, nesie informáciu o stave. Tento stav musí byť eventuálne zmazaný. Ak je použitý TCP protokol, zavretie TCP spojenia je dobrým indikátorom, že daná aplikácia bola ukončená. Keďže SIP používa UDP pakety, zavretie spojenia chýba. Navyše určitá perióda ticha počas hovoru, ktorá je dlhšia ako T sekúnd nemusí postačovať na indikáciu konca spojenia. Výsledkom môže byť, že niektorá informácia o stave je zmazaná pred vybavením a hovor je tým pádom ukončený. Multicast: SIP môže používať multicast pre správy INVITE a REGISTER. Hoci multicast nie je dobre podporovaný NAT servrami, zvyčajne sa ako najlepšie riešenie ukazuje použiť ALG (Application Layer Gateway) vo vnútri NAT servera. Bezpečnosť: SIP je možno zabezpečiť spôsobom hop to hop a end to end mechanizmami. RFC2543 hovorí o zabezpečení cez IPsec a TLS ako potenciálne riešenie hop to hop mechanizmu. IPsec nie je priechodný cez NAT, teda implementácia použitím IPsec je značne obmedzená. IPsec pre SIP je priechodný cez Firewall, ale nemusí byť schopný rozoznať porty použité pre mediálny tok - 44 -
dát. End to end mechanizmus v SIP je reprezentovaný autentifikáciou a kryptovaním. Oba spôsoby ale robia problémy NAT serverom. [ 13 ] Obr. 3.2.7 - Schéma NAT 3.2.12 Typy NAT Full cone NAT Čo sa týka full cone NAT, mapovanie je veľmi jednoducho realizované. Každý kto chce kontaktovať z verejného internetu užívateľa v lokálnej sieti za NAT serverom musí poznať iba schému mapovania adries. Napríklad počítač za NAT serverom s IP adresou 192.168.1.100 komunikujúci cez port 5060 je mapovaný na externý port a IP adresu 212.12.32.99:12768. Hocikto z internetu môže poslať pakety na túto IP:port a pakety budú doručené užívateľovi v lokálnej sieti s IP 192.168.1.100:5060. Tento píklad je znázornený na obr. 3.2.8. Obr. 3.2.8 - Full cone NAT - 45 -
Restricted cone NAT V prípade restricted cone NAT je externá IP:port otvorená len pre jeden interný počítač, ktorý posiela dáta smerom von. Napríklad klient posiela pakety externému počítaču 1 a NAT mapuje klientovu IP 10.0.0.1:8000 na 202.123.211.25:12345. Externý počítač 1 môže posielať naspäť pakety. NAT bude blokovať pakety prichádzajúce z externého počítača 2, zatiaľ čo klient posiela dáta na IP adresu externého počítača 2. Existuje možnosť, že externý počítač 1 aj 2 môžu posielať pakety naspäť klientovi a mapovanie bude rovnaké pre oba externé počítače. Príklad je znázornený na obrázku 3.2.9. Obr. 3.2.9 - Restricted cone NAT a port restricted cone NAT Port restricted cone NAT Tento typ NAT je takmer identický ako restricted cone, ale v tomto prípade bude NAT blokovať všetky pakety iba ak klient predtým poslal paket na IP a port, ktoré slúžia na posielanie dát cez NAT. Ak klient pošle externému PC 1 dáta na port 5060, NAT povolí prístup paketom ku klientovi len z IP 222.11.22.33:5060. Ak klient pošle pakety na viacero IP:port, vtedy mu môžu odpovedať všetci externí užívatelia a na NAT zariadení budú mapovaní na jediný pár IP:port. Príklad je na obrázku 3.2.9. Symetrický NAT Posledný z typov NAT je symetrický NAT. Je dosť odlišný od prvých troch techník mapovania interných IP:port na externé IP:port. Je závislý od IP adresy, na ktorú sú posielané pakety. Napríklad klient pošle dáta z IP 192.168.1.100:5060 na externý PC 2, môže byť mapovaný na IP 212.12.32.99:15799, pričom ak by poslal dáta na externý PC - 46 -
1 bude mapovaný inak napríklad 212.12.32.99:12768. Oba externé PC môžu klientovi odpovedať, ale musia použiť IP adresu a port, cez ktoré majú povolený NAT. Ak by poslali dáta na iný pár IP:port, ich dáta budú na NAT zariadení zahodené. Na obrázku 3.2.10 je príklad symetrického NAT. Obr. 3.2.10 - Symetrický NAT Zatiaľ všetky IP siete používajú IPv4, čo znamená, že je nutné sa zaoberať problematikou NAT vs. SIP. Tento problém bude vyriešený pri nasadení IPv6, keďže NAT už nebude potrebný. Existujú však riešenia ako implementovať SIP do IP sietí ak sa v sieťach nachádzajú NAT zariadenia. Týmito možnými riešeniami sa budem zaoberať v ďalších kapitolách. [ 14 ] 3.3 Bezpečnostné a implementačné problémy protokolov prenášajúcich dáta v reálnom čase RTCP a RTP 3.3.1 Bezpečnostné problémy RTP a RTCP pri službe VoIP Po dohodnutí spojenia SIP signalizácou, nasleduje samotný mediálny prenos dát v reálnom čase protokolmi RTP a RTCP. Využité sú presne tie dva porty, ktoré sa dohodnú signalizáciou. Prenos potom prebieha medzi volaným a volajúcim. Obr. 1.2.10 a 3.3.1 presne vyjadrujú danú situáciu. Z pohľadu bezpečnosti je to vážny problém, hlavne ak si predstavíme, že spojenie inicioval užívateľ z internetu, ktorého vieme identifikovať možno len podľa jeho IP adresy. Tu nastáva veľká obava väčšiny správcov privátnych sietí. Hrozí veľké nebezpečenstvo odcudzenia strategických informácií, nakoľko výmena dát je realizovaná ako spojenie koniec koniec (obr. 3.3.1). Navyše RTP a RTCP pakety sú prenášané v UDP datagramoch, čo dané riziko len znásobuje. Na druhej strane je nutné poznať štruktúru danej privátnej siete. Je samozrejmé, že ak daná - 47 -
firma povolí len používanie hardwarových SIP telefónov, maximálne jej hrozí útok na vyradenie služby DoS. V takomto prípade je obava z odcudzenia dát minimálna. V prvom rade je veľmi dôležité zvážiť požiadavky a potreby daného subjektu. Ak sa daná firma rozhodne používať softwarové SIP telefóny, musí rátať s tým, že riešenie bezpečnosti siete bude finančne náročnejšie. Na prvý pohľad sa zdá, že tento problém nemožno vyriešiť k spokojnosti zákazníka. Môžeme predpokladať, že zákazník službu VoIP odmietne práve kvôli tomuto problému. Existujú však veľmi dobré riešenia ako zabezpečiť RTP a RTCP a zabrániť tak potenciálnemu útočníkovi zneužitie danej situácie. Riešenia tohto bezpečnostného problému sú spomenuté v kapitole 4.2. Obr. 3.3.1 Prechod SIP signalizácie a RTP/RTCP dát 3.3.2 Implementačné problémy RTP a RTCP pri službe VoIP Nesmieme zabúdať, že telefónna konverzácia je obojsmerný proces. Dáta musia korektne doraziť k volanému terminálu a potom aj smerom naopak. Hovor smerujúci z privátnej siete smerom do verejnej siete cez NAT zariadenie nepredstavuje až taký problém. Zdrojová privátna adresa UDP datagramu bude na NAT zariadení preložená na verejnú IP adresu. Problém skôr predstavuje dátový tok smerujúci z vonkajšej siete do privátnej. Vtedy je nutné zabezpečiť, aby NAT zariadenie malo inštrukcie o tom na akých RTP portoch sa môže uskutočňovať komunikácia a o nastavení mapovania portov. Zariadenie teda musí identifikovať, kam presmerovať prichádzajúce UDP datagramy a ako má mapovať UDP/RTP porty v konverzácii. Toto je dôležité si uvedomiť, nakoľko existujú už spomínané 4 typy NAT. Je možné použiť viacero zariadení od viacerých výrobcov, ktoré takéto mechanizmy majú implementované. - 48 -
4. ANALÝZA EXISTUJÚCICH A DOSTUPNÝCH BEZPEČNOSTNÝCH RIEŠENÍ V PRIVÁTNYCH SIEŤACH A PRI ICH PREPOJENÍ K SIEŤAM INÝCH OPERÁTOROV (z pohľadu VoIP cez SIP) 4.1 Zabezpečenie manažmentu SIP spojenia Keďže protokol SIP bol odvodený z HTTP protokolu, všetky dostupné bezpečnostné riešenia a algoritmy v HTTP je možné aplikovať aj na protokol SIP. [ 15 ] Použitím MIME kontajnerov vnútri SIP správ podnecuje potenciálne využitie emailových bezpečnostných mechanizmov ako PGP alebo S/MIME. A samozrejme URI z HTTP, ktoré je podobné ako URI v SIP, je možné prenášať cez zabezpečený tunel na transportnej vrstve (TLS). Posledným mechanizmom ako zabezpečiť všetky služby bežiace na IP protokole, je použitím IPsec. Hlavné bezpečnostné mechanizmy určené na ochranu SIP spojení sú v tabuľke 3. Zhodujú sa so súborom metód, ktoré sú odporúčané verziou 1 SIP štandardu. Medzitým boli štandardom SIPv2 odmietnuté PGP a HTTP základná autentifikácia. Autentifikačné metódy: PSK (Pre- Shared Keys) a PKI (Public Key Infrastructure) Autentifikácia Dátová integrita Utajenosť HTTP 1.0 základná autentifikácia PSK nie nie HTTP 1.1 digest autentifikácia PSK nie nie odmietnuté SIPv2, nezabezpečený prenos hesla výzva/odpoveď založená na MD5 algoritme, hash z hesla PGP (Pretty Good Privacy) PKI x x odmietnuté SIPv2 S/MIME (Secure MIME) PKI x x SIPS URI (TLS) PKI x x IPsec PKI x x pre kryptovanie verejného kľúča užívateľa musí byť známý UA SIP aplikácie a proxy servre musia striktne podporovať TLS integrácia so SIP aplikáciami nie je nutná, ale proxy servre musia byť dôveryhodné Tabuľka 3 Riešenia ako zabezpečiť SIP manažment - 49 -
4.1.1 HTTP digest autentifikácia (RFC 2617) V tejto časti je ukázané ako SIP INVITE správa poslaná užívateľom Alice je autentifikovaná proxy serverom. Použitá je pritom HTTP digest autentifikácia. Akonáhle proxy server obdrží SIP INVITE správu od užívateľa Alice, odpovedá na ňu výzvou (obr. 4.1.1). Výzva obsahuje náhodný výraz (nonce), definuje použitý digest algoritmus (zvyčajne MD5 alebo SHA-1) a autentifikačnú zónu (voči ktorej sa musí užívateľ autentifikovať). Ako odpoveď na výzvu, užívateľ Alice prepošle originálnu SIP INVITE správu doplnenú v záhlaví o odpoveď na výzvu (obr. 4.1.2). Odpoveď obsahuje MD5 digest užívateľské meno, utajené heslo, náhodný výraz (nonce), SIP metódu a požadované URI. Keďže heslo je prenášané v zašifrovanom formáte, musí byť proxy server schopný dešifrovať heslo, aby bolo možné overiť autentifikačnú odpoveď. Obr. 4.1.1 HTTP digest autentifikácia výzva Obr. 4.1.2 HTTP digest autentifikácia autentifikačná INVITE správa - 50 -
HTTP digest autentifikácia vylepšuje nedostatky HTTP základnej autentifikácie tým, že sa prenáša MD5 alebo SHA-1 digest. Hoci HTTP digest autentifikácia má výhodu v tom, že identita užívateľa môže byť platná aj bez potreby prenosu hesiel v cleartexte, môže byť citlivá na ataky založené na odchytení hash hodnôt, najmä ak sú použité krátke a slabé heslá. Ďalšou veľkou nevýhodou je nedostatočný kryptovací mechanizmus zabezpečujúci utajenosť. Navyše nie je možné garantovať dátovú integritu SIP správ. 4.1.2 PGP (Pretty Good Privacy) (RFC 1991) PGP je možno potenciálne využiť na autentifikáciu a kryptovanie MIME tela paketu v SIP správach. Avšak verzia 2 protokolu SIP už takúto možnosť nepodporuje a vylučuje. 4.1.3 S/MIME (Secure MIME) (RFC 2312) SIP správy obsahujú MIME správy, ktoré je možno zabezpečiť. Mechanizmus zabezpečenia MIME správ sa nazýva S/MIME. X.509 certifikáty sa používajú na identifikáciu koncových užívateľov na základe ich emailových adries, ktoré sú súčasťou SIP URI (rudo@vinice.sk, jozo@vrable.sk atď). Podpisovanie MIME správ nie je veľký problém, nakoľko každý užívateľ má svoj privátny kľúč a užívateľský certifikát môže byť poslaný v pkcs7-mime alebo pkcs7-signature poliach. Na druhej strane pri kryptovaní MIME správ napríklad SDP správ je nutné poznať príjemcov verejný kľúč. Tento kľúč je zvyčajne certifikovaný X.509 certifikátom a musí byť získaný pred začiatkom spojenia. Kľúč je buď stiahnutý z verejného adresára alebo môže byť vyžiadaný prostredníctvom špeciálnej SIP správy. S/MIME sa používa na zabezpečenie MIME správ buď spôsobom hop-hop alebo koniec-koniec (UA-UA). Na obr. 4.1.3 je možné vidieť SDP MIME správu zapúzdrenú do SIP INVITE správy a zakryptovanú S/MIME algoritmom. Application/pkcs7-mime binárne envelopeddata pole zapúzdruje symetricky kryptované SDP telo paketu a tiež obsahuje symetrický kľúč. Symetrický kľúč je zakryptovaný verejným kľúčom užívateľa. V tomto prípade je kryptované telo paketu dodatočne podpísané. Použitá je multipart/signed metóda. Podpis a X.509 certifikát užívateľa sa nachádzajú v binárnom poli application/pkcs7-signature, ktoré nasleduje za MIME telom paketu. Ako alternatívne riešenie je možné využiť aj binárne pole signeddata. - 51 -
Obr. 4.1.3 - S/MIME kryptované a autentifikované SDP MIME telo paketu Každý mechanizmus, ktorý je závislý na existencii certifikátov pre koncových užívateľov, je určitým spôsobom limitovaný. V dnešnej dobe existuje celosvetovo viacero nekonsolidovaných autorít, ktoré ponúkajú certifikáty pre koncových užívateľov. Preto je veľmi dôležité mať certifikáty od verejne známych certifikačných autorít (CA), ktorých certifikáty sa navzájom poznajú. 4.1.4 SIPS URI (TLS) (RFC 2246) Použitie SIPS URI v SIP INVITE správe znamená, použiť TLS cez celú trasu spojenia až ku koncovému bodu. TLS ochrana musí byť realizovaná spôsobom hop-hop na každom segmente trasy. TLS vyžaduje použiť transportný protokol TCP (TCP/SIP) a infraštruktúru verejných kľúčov. 4.1.5 IPsec (RFC 2709) IPsec je základný bezpečnostný mechanizmus, ktorý chráni SIP správy na sieťovej vrstve. Kvôli požiadavke, že každý proxy server na trase musí čítať/prepísať prístup k SIP záhlaviu, musia byť IPsec ESP (RFC 2406) alebo AH (RFC 2402) založené na báze hophop. Potrebné IPsec bezpečnostné mechanizmy môžu byť založené na pevnej báze - bez - 52 -
aktívnej účasti SIP UA (tie čo využívajú spojenie) alebo na dynamickej báze UA a proxy servre si počas nadväzovania spojenia interaktívne dohodnú IPsec mód. IKE (RFC 2409) podporuje aj PSK a PKI. Keďže IP adresy SIP užívateľov sú často dynamicky prideľované, IKE v hlavnom móde nebude fungovať a IKE v agresívnom móde má svoje bezpečnostné problémy (ataky typu man-in-the-middle, offline dictionary ataky a iné). V tomto prípade je preferovaná viac autentifikácia verejnými kľúčmi. To ale znamená značný problém v dôveryhodnosti X.509 (RFC 2459) certifikátov. IPsec metódy zabezpečenia a vytváranie VPN sú popísané v Prílohe 3. 4.2 Zabezpečenie mediálneho kanálu (zabezpečenie protokolov RTP a RTCP) 4.2.1 SRTP a SRTCP Audio a video dáta v reálnom čase sú veľmi citlivé na celkové oneskorenie a fázové chvenie (jitter). Žiadny z algoritmov zabezpečujúci takéto dáta by nemal výrazne ovplyvňovať tieto parametre. Z dôvodu, že dáta sú na transportnej vrstve mapované do UDP paketov, v praxi je možné využiť iba dve metódy zabezpečenia takýchto dát. Popísané sú v tabuľke 4. Autentifikačné metódy: PSK (Pre-Shared Keys)a PKI (Public Key Infrastructure) Autentifikácia Dátová integrita Utajenosť SRTP (Secure RTP) PSK x x IPsec (IP Security) PKI x x použitie vlastných kľúčov, ktoré musia byť distribuované rôznymi spôsobmi integrácia so SIP aplikáciami nie je nutná, ale spojenie musí byť dôveryhodné Tabuľka 4 - Metódy zabezpečenia RTP 4.2.2 SRTP (Secure RTP) SRTP je len rozšírením štandardu RTP a poskytuje utajenie dát, autentifikáciu správ a ochranu voči opätovnému preposielaniu v RTP a RTCP. Použitím kryptograficky - 53 -
výkonnej ale počítačovo nenáročnej AES šifry v móde SC (Stream Cipher), je garantovaná vysoká úroveň bezpečnosti, pričom sa v podstate nezväčší objem prenášaných dát. Autentifikačné návestie požaduje pre dátovú integritu pridať len 10 Bytov ku každému RTP/RTCP paketu, ale je možnosť ho zredukovať len na 4 Byty ak je použitý veľmi úzky komunikačný kanál. Ako alternatívne riešenie je možné použiť zabezpečenie RTP a RTCP dát na sieťovej vrstve a to už spomínaným súborom protokolov IPsec v transportnom móde. Oba RTP a RTCP pakety môžu byť kryptograficky zabezpečené s protokolomi SRTP a SRTCP. Na obr. 4.2.1 je znázornený formát SRTP paketu. Obr. 4.2.1 Formát SRTP paketu Ako je možné vidieť na obr. 4.2.2, jedine RTP dáta sú zakryptované. Ako už bolo povedané, veľkosť RTP dát sa kryptovaním nezväčšila. MKI (Master Key Identifier) pole nie je povinné a identifikuje vlastný kľúč, z ktorého sú odvodené kľúče pre spojenie. Ak je nutné zmeniť kľúče, užívateľ môže MKI použiť na získanie správneho vlastného kľúča. SQN (Sequence Number) je 16 bitové pole a je použité spolu s 32 bitovým poľom ROC (Rollover Counter) ako časť kryptografického kontextu v SRTP spojení. Tieto polia slúžia na zabezpečenie SRTP spojenia voči opätovnému preposielaniu (zahlteniu spojenia). Autentifikačné návestie (authentication tag) je kryptografická suma vypočítaná z celého RTP paketu. Táto suma chráni celý RTP paket voči neautorizovaným modifikáciám. Dĺžka tejto sumy v Bytoch už bola spomenutá. - 54 -
4.2.3 SRTCP (Secure RTCP) Na obr. 4.2.2 je znázornený SRTCP paket, ktorý je zabezpečený podobným spôsobom ako SRTP paket. Je tu len jeden rozdiel, že v tomto prípade je pole AT (authentication tag) povinné. Na druhej strane môže útočník poslať BYE paket, aby tak ukončil RTP spojenie. Ďalšie pole je SRTCP index, ktorý slúži ako sekvenčné počítadlo v prevencii voči opätovným atakom (zahltenie spojenia). Ak je použité E (Encryption Flag) pole v SRTCP indexe, potom je telo RTCP paketu kryptované. Obr. 4.2.2 Formát SRTCP paketu 4.2.4 Štandardný kryptovací algoritmus V princípe každá kryptovacia schéma môže byť použitá pre SRTP. Štandardne sa používajú NC (NULL cipher) a AES-CTR (Advanced Encryption Standard in Counter Mode). AES-CTR je znázornený na obr. 4.2.3. Obr. 4.2.3 AES-CTR kryptovací algoritmus - 55 -
AES v CTR móde vystupuje ako generátor kľúčov produkujúci pseudonáhodné streamy kľúčov ľubovoľných dĺžok, ktoré sú aplikované v bitovo-orientovanom tvare do RTP/RTCP tela paketu. Používa logickú funkciu XOR. Samostatne je AES blok šifier, ktorý tvoria 128 bitový blok a kľúč o veľkosti 128,192 alebo 256 bitov. AES je spustený spolu s jednoznačným IV (initialisation vector) vždy na začiatku každého RTP a RTCP paketu. IV je odvodený ako hash zo 112 bitového salt_key, SSRC toku dát a paket indexu. IV je na výstupe kryptované 128 pseudonáhodnými bitmi. Ďalej je IV zväčšený o jeden a je znovu zakryptovaný generovaním ďalších 128 bitov. Opakovaním tohto postupu je možné zakryptovať celé telo RTP/RTCP paketu. AES sa používa v CTR móde namiesto CBC (Cipher Block Chaining) módu. Oproti CBC módu má veľkú výhodu v tom, že stream kľúčov môže byť prepočítaný skôr ako sa telo paketu stane prístupné. Takto sa výrazne minimalizuje oneskorenie spojené s kryptovaním. A samozrejme ak použijeme streamovú šifru namiesto bloku šifier, nie je potrebné doplniť k telu RTP/RTCP paketu ďalší blok. V najhoršom prípade by mohol tento blok spôsobiť zväčšenie RTP/RTCP záhlavia o 15 Bytov. 4.2.5 Štandardný autentifikačný algoritmus Štandardný SRTP autentifikačný algoritmus správ je HMAC-SHA-1, ktorý je založený na známej 160 bitovej SHA-1 hash funkcii. Kryptografická bezpečnosť je dosiahnutá hashovaním 160 bitového tajného kľúča (auth_key) do kontrolnej sumy (autentifikačné návestie), ktorá je potom konvertovaná na 80 bitov, aby sa zredukovala veľkosť záhlavia paketu a skryla hash funkcia. V aplikáciách, kde je problém so šírkou pásma, je možné autentifikačné návestie zredukovať až na 32 bitov. Obr. 4.2.4 Autentifikácia s použitím HMAC-SHA-1-56 -
4.2.6 Odvodenie kľúčov pre spojenie Kryptovací a autentifikačný algoritmus už boli popísané. Oba algoritmy vyžadujú pre spojenie utajené symetrické kľúče, ktoré musia poznať všetci UA participujúci na SIP spojení. Toto zvyšuje problém s generovaním a distribúciou kľúčov pre spojenie. SRTP štandard ponúka čiastočné riešenie. Toto riešenie spočíva v odvodení všetkých potrebných kľúčov pre spojenie zo známeho vlastného kľúča. Otvorená je však distribúcia vlastného kľúča. Ten musí klient získať sám. Na obrázku 4.2.5 je znázornené ako sú vypočítané kľúče pre spojenie z vlastného kľúča. Znovu je blok šifry AES v CTR móde, aby vygeneroval nevyhnutné kľúčové dáta. Vlastný kľúč, ktorý môže mať veľkosť 128, 192 alebo 256 bitov, slúži na kryptovanie AES. Pseudonáhodný generátor je načítaný s IV. IV je funkcia zložená z 112 bitov salt_key, label a session key number. Pre návestia 0x00 po 0x05, sú kryptovanie, autentifikácia a salt_key pre oba SRTP a SRTCP pakety odvodené z rovnakého vlastného kľúča. Ak bola definovaná rýchlosť odvodenia kľúčov, potom boli takou istou rýchlosťou generované a posielané SRTP a SRTCP pakety a vypočítané kľúče pre spojenie. Ak je rýchlosť odvodenia kľúčov nastavená na nulu, potom je rovnaký počet kľúčov použitý pre celú dĺžku spojenia. Obr. 4.2.5 Odvodenie kľúčov pre spojenie - 57 -
4.2.7 Distribúcia vlastných kľúčov Ide o distribúciu vlastných kľúčov k UA, ktorá tvorí časť inicializácie spojenia. Distribúcia je založená na MIKEY (Multimedia Internet Keying) algoritme. MIKEY je nový protokol výmeny kľúčov podobný IPsec-ovému IKE (Internet Key Exchange), ale je už prispôsobený na špecifické požiadavky multimediálneho prostredia. Nanešťastie, k tomuto štandardu nie je zatiaľ dostupná dokumentácia. Ako náhradné riešenie pre prenos vlastného kľúča je možné použiť k parameter v SDP protokole. Obrázok 4.2.6 znázorňuje typickú SIP INVITE správu, ktorá zapúzdruje SDP MIME správu. V SDP správe sa nachádza parameter k reprezentujúci 128 bitový SRTP vlastný kľúč v hexadecimálnom tvare. Samozrejme prenos vlastného kľúča v nešifrovanom formáte prináša so sebou veľké riziko. Za predpokladu, že proxy servre dokážu spoľahlivo SIP INVITE správu odkryptovať, môže byť SIP INVITE hop-by-hop zakryptovaná použitím TLS alebo IPsec. Ak je požadovaná utajenosť SDP MIME správy typu koniec-koniec, potom je možné použiť ochranu S/MIME. Obr. 4.2.6 SIP INVITE správa s enkapsulovanou SDP MIME správou (k -128 bitový vlastný kľúč) - 58 -
4.3 Riešenie základných bezpečnostných problémov vo VoIP V tabuľke 5 sú uvedené základné bezpečnostné problémy a ich riešenia. Problém a dôvody DoS (odoprenie služby): prevencia prístupu k službe a zabránenie bombardovania SIP proxy alebo VoIP brán z Internetu neautentifikovanými paketmi Odpočúvanie: neoprávnené zachytenie hlasových paketov (RTP) a dekódovanie signalizačných správ Záplava paketmi: impersonifikácia legitímneho užívateľa Riešenie konfigurácia zariadení voči takýmto atakom Použiť SRTP Preposlať adresnú autentifikáciu medzi komunikujúcimi partnermi Preposielanie správ: zahltenie systému obsluhujúceho spracovanie signalizačných správ Integrita správ: zabezpečiť aby prijaté správy boli tie, ktoré boli skutočne vyslané Tabuľka 5 Kryptovanie sekvenčných správ (použiť Cseq a Call ID) Autentifikovať správy použitím HTTP digest autentifikácie 4.4 Implementačné riešenia (Riešenie problému s Firewallom a NAT) 4.4.1 UPnP (Universal Plug and Play) UPnP [ 16 ] [ 17 ] je technológia zameraná na domácich používateľov a domáce kancelárie (home Office). Táto architektúra je určená na adresovanie množstva hlavných požiadaviek (problémov) (nie len VoIP) a je navrhnutá tak aby umožnila použitie hotovej konfigurácie pre malé siete aj neskúsenými používateľmi. UPnP umožňuje klientským aplikáciám odhaľovať vyhľadávať a konfigurovať sieťové komponenty, vrátane NAT firewallov, ktoré sú zahrnuté v UPnP softwari. Základnou potrebou vo VoIP aplikáciách je odhaliť a použiť externú IP adresu a port ktorý NAT vyberie pre signalizáciu a toky médií. Ak sú už potrebné informácie známe, VoIP klient môže túto informáciu použiť na VoIP signalizáciu na nadviazanie spojenia. Toto zabezpečuje, že hovor je uskutočnený použitím verejných, smerovateľných adries a portov a je uskutočnené priame spojenie. Na dosiahnutie spojenia musia mať NAT a VoIP klienti zapnuté a podporované UPnP. Zatiaľ čo mnoho menších spoločností - 59 -
podporuje NAT UPnP pre VoIP, existuje len veľmi málo VoIP klientov s touto podporou. Hlavná nevýhoda tejto technológie súvisí s bezpečnosťou, keďže nedostatočne rieši problém s firewallom. UPnP závisí na NAT opening pinholes (otvorenie portov nutných na VoIP) do vonkajšieho sveta ktoré sú pod dynamickou kontrolou UPnP klienta. Toto riešenie je protikladom k viacerým bezpečnostným/firewallovým politikám a práve preto táto technológia nemôže byť akceptovateľná pre väčšie spoločnosti. Obr. 4.4.1 UPnP komponenty 4.4.2 STUN (Simple Traversal of User Datagram) Protokol STUN (Simple Traversal of User Datagram) [ 16 ] [ 17 ] umožňuje SIP klientovi zistiť či sa nachádza za NAT a determinovať typ tohto NAT. STUN je veľmi dobrým riešením pre VoIP za NAT avšak, má jeden významný nedostatok, funguje len pri niektorých typoch NAT. Dokonca nepracuje so symetrickým NAT ktoré je používané vo väčšine podnikových sietí. STUN taktiež nepodporuje SIP zariadenia založené na TCP. Obr. 4.4.2 STUN, signalizačný tok Návrh protokolu STUN definuje špeciálny server (STUN server) vo verejnom adresnom priestore. Slúži na informovanie SIP klienta s aktivovaným STUN privátneho - 60 -
adresného priestoru istej verejnej NAT IP adresy a portu ktorý bude použitý pri danom spojení. Avšak používanie klientov s podporou STUN prípadne vylepšovanie už použitých klientov na podporu STUN, robia tento protokol nie veľmi populárny u veľkých spoločností. STUN identifikuje verejnú stranu NAT pomocou prieskumných STUN správ ktoré prichádzajú do STUN servera. Klient s aktivovaným STUN posiela tieto prieskumné STUN správy externému STUN serveru aby determinoval prijímací port ktorý bude používať. STUN server overí prichádzajúcu správu a informuje klienta, ktorá verejné IP adresa a porty boli použité NAT. Tieto údaje sú neskôr použité pri správach pre nadviazanie spojenia. Ako už bolo spomenuté STUN nedokáže pracovať so symetrickým NAT. Symetrické NAT vykonávajú mapovanie na základe zdrojovej IP adresy a čísla portu, ako aj cieľovej IP adresy a príslušného čísla portu. IP adresa cieľového VoIP klienta je iná ako tá ktorú má STUN server. To znamená, že NAT uskutoční nové mapovanie za použitia iného portu pre odchádzajúce dáta, čo vedie k tomu, že informácie obsiahnuté v správe pre nadviazanie spojenia sú nesprávne a pokus o spojenie zlyhá. Ten istý problém sa vyskytuje aj u prijímaných dát. Práve preto STUN je závislý od toho, že ak je raz port pre odchádzajúce dáta STUN servera namapovaný, všetky dáta z hociktorej časti siete s ľubovoľnou zdrojovou IP adresou budú schopné použiť mapovanie v opačnom smere a dosiahnuť prijímací port v klientovi. NAT, ktoré pracujú na princípe spomenutom vyššie sú náchylné na útoky z vonku, čo nie je z hľadiska bezpečnosti žiadúci jav. Táto metóda preto zlyháva v riešení problémov s firewallmi pretože zo sebou prináša väčšie riziká z hľadiska bezpečnosti. 4.4.3 Comedia (Connection Oriented Media) Problém symetrických NAT rieši metóda označovaná ako Connection oriented media [ 16 ] [ 17 ]. V prípade symetrických NAT musí klient poslať RTP na a prijímať RTP z tej istej IP adresy. Každé RTP spojenie medzi koncovým bodom mimo NAT a bodom za NAT musí byť point-to-point a preto koncový bod mimo NAT musí čakať pokiaľ neprijme paket od klienta predtým ako vie kam má odpovedať. Ak koncový bod komunikuje s klientmi za NAT a súčasne s klientmi mimo NAT, musí vedieť, kedy môže dôverovať SDP správam ktoré prijíma v SIP správach, a kedy potrebuje počkať na prijatie paketu priamo od klienta ešte pred tým ako otvorí kanál späť k zdroju IP:port odkiaľ bol paket prijatý. - 61 -
Jeden z návrhov ako informovať koncový bod aby čakal na prichádzajúci paket je pridať riadok a=direction:active do SDP správy (ktorá prichádza od klienta za NAT). Keď koncový bod prečíta pridaný riadok, vie že klient aktívne nastaví IP:port kam má koncový bod vrátiť RTP a IP:port ktorý bude v SDP správe bude ignorovať. Primárne SIP klienti nepodporujú a= tag. Na podporu tagu je potrebné aby mali do SIP toku vložený istý druh prekladača, ktorý môže rušiť ostatné rozhodnutia aby determinoval že sa klient nachádza za symetrickým NAT. Ak je rozhodnuté že klient je za symetrickým NAT, prekladač vloží vyššie uvedený riadok do SDP v SIP správe. Žiaľ veľkou nevýhodou je, že toto riešenie nefunguje ak sú obaja klienti za NAT. Obr. 4.4.3 - Comedia 4.4.4 TURN (RTP Relay) Ak koncové body podporujú Connection Oriented Media, problém prenosu cez symetrické NAT je vyriešený. Avšak stále existujú 2 problematické situácie: Ak koncový bod nepodporuje tag a=direction:active Ak obaja klienti sú za symetrickým NAT V týchto prípadoch je jedným z riešení mať RTP Relay (server) [ 16 ] [ 17 ] v ceste RTP toku medzi dvoma koncovými bodmi. RTP relay sa správa ako druhý koncový bod vo vzťahu k aktuálnym koncovým bodom, ktoré medzi sebou chcú komunikovať. Väčšinou je ešte prítomný server v strede SIP toku (nazývaný NAT Proxy) ktorý manipuluje s SDP tak aby koncové body posielali RTP do RTP relay a nie sebe. RTP vykoná vlastné interné mapovanie a zaznamená zdrojovú IP:port každého koncového bodu, teda používa toto mapovanie na posúvanie RTP z jedného do druhého koncového bodu. - 62 -
Typický priebeh hovoru, ktorý môže byť medzi User Agentom (užívateľským klientom) za symetrickým NAT a hlasovou bránou mimo NAT, znázorňuje obrázok 4.4.4. Obr. 4.4.4 RTP Relay 1. UA pošle pozývaciu správu (invite message) NAT Proxy cez NAT 2. NAT Proxy kontaktuje RTP relay a požiada o nadviazanie spojenia 3. RTP Relay pridelí voľné páry portov pre toto spojenie. NAT Proxy to využije na modifikovanie SDP informácie prijatej pozývacej správy. 4. NAT Proxy posunie ďalej SIP pozývací odkaz so zmeneným SDP druhému klientovi 5. Druhý klient odpovie svojou vlastnou SDP informáciou ktorá obsahuje port na ktorom prijíma RTP pakety 6. NAT Proxy kontaktuje RTP Relay aby zamenil IP:port druhého klienta (ak je brána (Gateway) taktiež za symetrickým NAT, NAT Proxy dá inštrukcie RTP Relay aby počkal na pakety od druhého klienta predtým ako nastaví IP:port na posielanie RTP na bránu) 7. RTP Relay odpovedá NAT Proxy že RTP port je pripravený ma tok dát (upstream) 8. NAT Proxy posiela odpoveď späť UA hneď ako zmení SDP s odpoveďou s IP:port z RTP Relay 9. UA začína posielať RTP na IP:port RTP Relay ktorý dostal 10. RTP Relay zaznamená IP:port odkiaľ prijal paket a posunie paket na IP:port druhého klienta 11. RTP pakety od druhého klienta smerujú do RTP Relay 12. RTP Relay tieto pakety posiela klientovi - 63 -
Pri tomto riešení je dôležitých niekoľko skutočností: 1. Klient potrebuje stále posielať a prijímať RTP na rovnakom porte 2. Toto riešenie funguje na všetkých typoch NAT, avšak kvôli oneskoreniu spojenému s RTP Relay, je menej výhodné ho nasadiť pri symetrickom NAT. 3. Existujú aj iné riešenia implementácie RTP Relay. Veľkou výhodou tohto riešenia je, že dokáže prekonať všetky typy NAT. Avšak nevýhodou môže byť, že celá komunikácia stojí na jednom bode a tým je RTP Relay a taktiež môže byť nevýhodou vysoká cena, ktorá predurčuje toto riešenie pre väčšie firmy. 4.4.5 ALG (Application Layer Gateway) Táto metóda stojí na inštalácii nového Firewall/NAT Application Layer Gateway (ALG) [ 16 ] [ 17 ]. Dané zariadenie alebo software nahrádza privátnu IP:port v odchádzajúcej SIP/SDP správe externou IP:port. Potom inštruuje NAT aby urobilo verejno-privátne mapovanie. Prichádzajúce SIP a RTP pakety budú teda niesť verejnú IP adresu a portu. Pri ďalšom NAT sú tieto údaje namapované znovu na privátnu IP adresu a port cieľového bodu. ALG a NAT sa môžu zdať ako dva komponenty s rovnakým riešením. Väčšinou sú implementované ako dve aplikácie v rámci jedného zariadenia. SIP signalizácia musí stále prechádzať cez ALG avšak u RTP to nie je potrebné. 4.4.6 Tunelovacie techniky Obr. 4.4.5 ALG Táto metóda je založená na vytvorení tunela pre média aj signalizáciu, ktoré sú pomocou tunela prenášané cez NAT/firewall do servera vo verejnom adresnom priestore - 64 -
[16 ] [ 17 ]. Táto technológia vyžaduje existenciu servera v privátnej sieti a servera mimo privátnej siete. Tieto zariadenia vytvoria medzi sebou tunel a pomocou neho prenášajú všetky SIP dáta. Server mimo privátnej siete modifikuje signalizáciu tak aby zohľadnil vlastné porty pre odchádzajúce dáta a umožnil tak VoIP systému vytvárať odchádzajúce hovory a prijímať prichádzajúce hovory. Zvyčajne sa v takomto tuneli nepoužíva enkrypcia dát. Aj keď táto technológia vyžaduje minimálne zmeny v bezpečnostnej politike, jej hlavným problémom je nutnosť existencie servera mimo privátnej siete. Obr. 4.4.6 Tunelovacie techniky 4.4.7 External Query Pri absencii metódy komunikácie s NAT zariadením, najlepšou cestou pre klienta na získanie svojej externej IP adresy a čísla portu, je vyžiadať si od servera mimo NAT informáciu, ako vidí zdroj paketu ktorý pošle. V tomto prípade, externý server (NAT probe) čaká na pakety. Ak príjme paket, vráti správu z rovnakého portu zdroju ktorý paket poslal. Táto správa už obsahuje externú IP adresu a číslo portu. Takto to funguje vo všetkých typoch NAT. Klient vie za daných okolností determinovať: a) že je za NAT (ak dvojica IP adresa:port ktorá sa vráti v správe z externého servera je iná akú má pôvodne b) ktorá externá IP adresa:port má byť použitá v SDP správe aby mohol byť klient dosiahnuteľný Napríklad chce byť klient dosiahnuteľný na 192.168.1.100:5060, najprv pošle požiadavku NAT probe z portu 5060. NAT probe automaticky príjme paket s požiadavkou z adresy 212.12.32.99:12768 a odpovie na túto adresu a port tou istou IP:port dvojicou. - 65 -
Obr. 4.4.7 External Query Táto metóda funguje len za splnenia týchto podmienok: klient musí posielať a prijímať RTP na tom istom porte klient musí posielať SIP správy krátko po poslaní požiadavky NAT probe. Ak je medzi nimi oneskorenie príliš veľké, môže dôjsť k zmene mapovania NAT v prípade Restricted Cone a Port Restricted Cone NAT musí klient poslať paket k cieľu skôr ako NAT dovolí prijať pakety z cieľového bodu (nikto nemôže kontaktovať klienta skôr ako ho klient sám kontaktuje). [ 16 ] [ 17 ] 4.4.8 Interactive Connectivity Establishment (ICE) Na rozdiel od predošlých riešení prenosu hlasu za NAT ktoré používajú server ktorý je medzi dvoma koncovými bodmi, toto riešenie sa zameriava na koncové body, konkrétne na proces ich vyhľadávania. ICE umožňuje koncovým bodom determinovať typy NAT ktoré medzi nimi existujú a taktiež umožňuje zistiť IP adresy pomocou ktorých môžu komunikovať. Proces vyhľadávania koncových bodov používa mnoho z mechanizmov spomenutých vyššie. Proces komunikácie prebieha nasledovne: 1. Koncový bod ktorý iniciuje spojenie (iniciátor) najprv získa informáciu o tom na akej IP adrese a porte ho vidia zariadenia mimo NAT použitím vlastných konfiguračných informácií a taktiež mechanizmov ako STUN alebo TURN. Teda využíva vonkajší server len na získanie informácie o externej IP adrese a čísle portu. - 66 -
2. Iniciátor posiela inicializačnú správu druhému koncovému bodu. Táto správa obsahuje informácie získané v prvom kroku. ICE zahŕňa signalizačné informácie na základe ktorých vie prekonať NAT. 3. Na základe prijatej inicializačnej správy, druhý koncový bod získa informáciu o svojej externej IP adrese a čísle portu rovnako ako v prvom kroku iniciátor. 4. Následne pošle správu s odpoveďou iniciátorovi. Hneď ako je signalizácia dokončená, každý koncový pod posiela dáta na danú adresu v poradí s najvyššou prioritou. 5. Pri výmene dát medzi koncovými bodmi, každý z bodov súčasne posiela STUN požiadavku druhému koncovému bodu. Z toho je zrejmé, že každý z koncových bodov slúži tomu druhému ako STUN server. 6. Nasledujú STUN odpovede na požiadavky 7. Zo všetkých STUN odpovedí ktoré sa vrátili je tá s najvyššou prioritou použitá pre následné dátové pakety. [ 16 ] [ 17 ] 4.4.9 SBC (Session Border Controller) Obr. 4.4.8 ICE proces SBC (Session Border Controller) je zariadenie predovšetkým pre VoIP sieť, ktoré kontroluje prístup hovorov do siete. Niekedy má funkciu (závisí od zariadenia) hostu, ktorý obsluhuje kontrolu hovorov v sieti, čiže UA v sieti nie sú touto kontrolou zaťažený. SBC má dve hlavné funkcionality: Signalizačná funkcionalita (SBC - SIG) kontroluje prístup VoIP signalizačných správ do siete a obsluhuje tieto správy - 67 -
Mediálna funkcionalita (SBC - MEDIA) kontroluje prístup mediálnych (RTP/RTCP) paketov do siete, zabezpečuje diferencovanie služieb a QoS pre rôzne typy mediálnych spojení (media streams) a chráni sieť voči útokom Použitie SBC Chránia okrajovú časť siete providera. o Sú implementované ako NAT servre. o Môžu zastávať funkcionalitu Firewallu alebo spolupracovať s existujúcimi Firewallmi v DMZ. Môžu otvárať priechodné porty (pinholes) na Firewalli, aby tak povolili prechod VoIP signalizácii a mediálnemu toku do siete. o Majú schopnosť utajiť sieťovú topológiu a tým utajiť detaily konfigurácie siete (providera, zákazníka, atď) alebo smerovania hovorov. Modifikujú VoIP signalizačné správy. o Eliminujú nepodporované VoIP signalizačné a mediálne protokoly na okraji siete Podporujú VoIP signalizáciu a mediálny prenos k zariadeniam za Firewallom/NAT bez požiadavky na rekonfiguráciu zariadení alebo Firewallu Dokážu kontrolovať prístup hovorov do siete. Chránia sieť pred DoS útokmi, pretože neoprávnené hovory sú odmietnuté. Garantujú dodržiavanie SLA (Service Level Agreement). Obr. 4.4.9 Bloková architektúra SBC [ 18 ] - 68 -
5. ROZBOR STAVU SIETE ŽILINSKEJ UNIVERZITY Z HĽADISKA BEZPEČNOSTI A ROZHRANÍ (VoIP CEZ SIP) 5.1 Všeobecné poznatky o stave siete Žilinskej univerzity z hľadiska bezpečnosti V tejto kapitole bude spomenutá analýza momentálneho stavu siete Žilinskej univerzity z hľadiska bezpečnosti a to na základe konzultácií so správcom siete UIaKT (Ústav informačných a komunikačných technológií). Požadované vlastnosti siete Žilinskej univerzity sú nasledovné: Vysoké pokrytie univerzity dátovou sieťou Komunikačná infraštruktúra pre IIS Efektívny management siete Účinná bezpečnostná politika Garantované pásmo pre koncového užívateľa 10/100Mb VLAN QoS Multicast Konvergovaná sieť IP Telefónia Videokonferencie Súčasný stav je charakterizovaný v tabuľke 6 a na obrázkoch 5.1.1 a 5.1.2. Fyzická vrstva Prenosová technológia Smerovanie Kryptovanie (VPN) Monitorovanie siete Bezpečnostná politika Spoľahlivosť Služby Obmedzenia na serveroch Optika (Backbone) aj metalika Ethernet (CISCO) - jeden dodávateľ, v budúcnosti možný upgrade siete L3 switching - VLAN len strategické úseky siete (rektorát) zdieľanie Intranetu áno (monitorovanie iba prevádzky), neuvažuje sa o prideľovaní prístupových práv nie je presne definovaná (neboli vydané pravidlá), evolučný vývoj zabezpečenia siete, zabezpečenie hlavne chrbticovej siete veľký dôraz na spoľahlivosť siete, niektoré sieťové prvky sú zálohované (VD a knižnica vzájomne), snaha o nepretržitú prevádzku siete, riešené aj záložné napájanie najdôležitejších sieťových prvkov povolené všetky služby (http, smtp, pop3, telnet, ftp, atď), neuvažuje sa o obmedzeniach servre sú monitorované a pri prípadnom napadnutí je limitovaná prenosová rýchlosť na 128 kb/s - 69 -
Prepojenia Prípojné body Pripojenie detaš. pracovísk prepojenie s SSE, pripravuje sa aj prepojenie s Orange a T-Mobile Nemocnica s poliklinikou (nepripojené), Regionálna knižnica (spojenie aktívne), Bilingválne gymnázum (spojenie aktívne) FRI detašované pracovisko Ružomberok, FRI detašované pracovisko Prievidza, EF detašované pracovisko L. Mikuláš, FŠI detašované pracovisko Košice Tabuľka 6 Súčasný stav siete Žilinskej univerzity VD-A Internaty Hliny FRI B Polop VD-B VD-C VD-D VD-E NR NS Hurbanova A VD SvF Hurbanova B FRI CCM VoiP GW + GK VD PIX SANET PU UK ZA Moyzesova SANET MT Internavt VD HB Menza H FSI Obr. 5.1.1 Topológia siete Žilinskej univerzity - 70 -
CI SC O S YS T EM S C IS C O S YS TE M S CISCO S YSTEMS 1Gb SMF CI SC O S Y ST EM S CI SCO S YSTEMS CISCO S YSTEMS R PS 1 2 1 2 3 4 5 6 7 8 9 1 0 11 12 1 3 14 15 16 17 18 19 20 21 22 23 24 CISC O S Y STEM S Cisco 1Gb SMF 12000 SERI ES CISCO S YSTEMS CI S CO S YSTEM S R PS 1 2 1 2 3 4 5 6 7 8 9 10 11 1 2 13 14 15 16 17 18 19 20 21 22 23 24 Žilinská univerzita v Žiline Poloprevadzka C 2950C - FEL+SjF C 2950C - FEL+SjF 100Mb MMF 2x100Mb MMF 2x100Mb MMF C 2950C - FEL+SjF 2x100Mb MMF 2x100Mb MMF C 2950C -FPEDaS 100Mb MMF 100Mb MMF NR NS C2950 - Menza USZ-VDBlok H Hosp.Blok 100Mb MMF 100Mb MMF 100Mb MMF C3550 - FRI C 2950T 1Gb SMF C 2950 C 3550 - Velky Diel 1Gb SMF C 3550 - Un.Kniznica C 2950 1Gb - SANET -MT 100Mb MMF 1Gb - SANET -PU SANET C6509 - Rektorat PIX - Rektorat C 3524 XL -SvF 1Gb SMF 1Gb SMF St. router - E 100Mb MMF C 2950 - Int.VD. Blok E F 34Mb C 2950 - Int.VD. Blok G H C2950 - FPV C2950 - Int.Hliny.B3 C2500 - SjF KAM C2950 - FSI Obr. 1. Topológia MAN UTCNet Obr. 5.1.2 - Topológia siete Žilinskej univerzity 5.1.1 Popis stavu siete Z hľadiska dostupných materiálov a poznatkov o toplógii a rozhraní je možné sieť Žilinskej univerzity zaradiť do kategórie špecifických subjektov (kap. 3.1.1). Je potrebné si uvedomiť, že takáto akademická sieť musí ponúknuť široký priestor pre oblasť výskumu, vedy, vzdelávania a prístupu k informáciám. Zrejme aj z tohto hľadiska bola takýmto spôsobom koncipovaná a navrhnutá. Predovšetkým musí byť spoľahlivá (odolnosť voči výpadkom v sieti) a musia byť dostupné potrebné informácie. Na druhej strane môže byť takáto sieť aj dobrým testovacím prostredím pre výskum v oblasti telekomunikácií, čoho dôkazom bol aj výber prenosovej technológie (CISCO Gbit Ethernet). - 71 -
5.1.2 Vplyv projektu SANET II na IKT Žilinskej univerzity Prínosy: Nárast objemu prenesených a spracovaných údajov Penetrácia VT do prostredia univerzity (správa a riadenie, veda a výskum, výučba) 80% pokrytie pracovísk univerzity dátovými prípojkami (pracoviská, učebne, laboratóriá, internáty,..) Vytvorenie podmienok pre rozvoj univerzitného intranetu (univerzitná pracovná plocha, internetové kiosky) Vytvorenie podmienok pre rozvoj Integrovaného informačného systému univerzity Vysoká kvalita dátovej siete a služieb (odozva, spoľahlivosť, priepustnosť,...) Spoločenská prezentácia univerzity konferencie, streaming video, web kamery, virtuálna knižnica... Problémy: zvýšenie požiadaviek na počítačovú gramotnosť a zručnosť používateľov zvýšenie nákladov na podporu používateľov (help-desk, školenia, nápovedy, príručky,...) nárast prienikov a útokov na univerzitnú sieť nárast porušovania AUP (Acceptable Use Policies) užívateľmi (študenti, doktorandi) väčšie dôsledky vírusových útokov (epidémie) spam nárast nákladov na prevádzku siete (antivírus, antispam, firewall, správa siete, technický servis,...) 5.1.3 Integrovaný informačný systém ŽU Tvoria subsystémy: personalistika a mzdy, dochádzkový systém stravovací systém register študentov - 72 -
e-vzdelávanie (prihlasovanie na skúšky, evaluácia, zadávanie známok, testovací systém,...) register preukazov na čipových kartách (zamestnanci, študenti, návštevy) ekonomický informačný systém + MIS, evidencia majetku knižničný informačný systém jednotný systém správy účtov užívateľov (LDAP). Zamestnanci i študenti univerzity majú pridelené užívateľské meno, heslo, prístup k aplikáciám redakčný systém pre správu univerzitného intranetu (za obsah, správnosť a aktualizáciu zodpovedá pracovisko kde prvotná informácia vznikla) 5.1.4 Popis stavu siete z hľadiska VoIP Aktívny CallManager, gateway prepojenia na PBX, gatekeeper prepojenia na Košice a CESNET Hlasové služby na IP sieti integrálna súčasť riešenia VoIP v sieti SANET Problémy s dokončením výstavby infraštruktúry pre VoIP H.323 SIP Možnosť zabezpečenia SBC (Session Border Controller) Gatekeeper (GNUGK) - 1. pre smerovanie (SR a mimo SR), 2. peering do CZ SIP proxy - 1. SIP Express Router (prihlasovanie užívateľov), 2. SIP Express Router (smerovanie) V SIP možnosť SSL, autorizácia, možnosť doinštalovania mechanizmov IPsec zatiaľ nebola potreba nasadzovať ich do siete Tabuľka 7 Popis súčasného stavu vo VoIP sieti - 73 -
<--- Obr. 5.1.3 Topológia a logická štruktúra VoIP siete Žilinskej univerzity - 74 -
5.1.5 Výhody prepojenia VoIP a PBX Volanie medzi budovami univerzity zadarmo po IP sieti Volanie medzi univerzitami na Slovensku a do ČR zadarmo Jednotný číslovací plán IP telefónov a PBX umožňuje jednoduché telefonovanie Problémy na riešenie pre rozvoj: Vytvorenie H.323 administratívnych zón pre hlasové služby v rámci SANET Vytvorenie služieb autentifikácie užívateľov, autorizácie hovorov Riešenie problematiky tarifikácie pre účastníkov IP telefónie Vypracovanie pravidiel pre pripájanie účastníkov do siete IP telefónie Riešenie problematiky komplexných adresárových služieb Riešenia XML služieb pre IP telefóniu v rutinnej prevádzke 6. NÁVRH OPTIMÁLNEHO RIEŠENIA PREPOJENIA PRIVÁTNYCH SIETÍ K SIETI PROVIDEROV NA BÁZE IP (z hľadiska VoIP) Pri návrhu optimálneho riešenia prepojenia privátnej siete a siete providera (z hľadiska VoIP ) je nutné aplikovať všetky poznatky spomenuté v tejto práci. 6.1 Návrh prepojenia malej privátnej siete a providera Pripojenie: pripojenie k providerovi cez ISDN linku pripojenie k providerovi cez adsl linku pripojenie k providerovi cez WiFi Koncové zariadenie: ISDN TA adsl modem, adsl router WiFi karta - 75 -
Bezpečnosť a VoIP: zákazník by mal používať antivírovú ochranu, používať antispyware, zablokovať nepotrebné služby použiť softwarový Firewall, poprípade nastaviť Firewall na koncovom zariadení použitie softwarového SIP klienta (Softphone, X-Lite, iné) použitie hardwarového SIP klienta (IP telefón) povoliť na Firewalli príslušné UDP porty dané providerom doporučené šifrovanie spojenia (UA to musí podporovať) SIP Na obrázku 6.1.1 je znázornené odporúčané prepojenie takejto siete k sieti providera. Zákazník má možnosť vybrať si z VoIP služieb, ktoré momentálne provideri poskytujú. Obr. 6.1.1 Príklad prepojenia malej privátnej siete a providera 6.2 Návrh prepojenia strednej privátnej siete a providera Pripojenie: pripojenie k providerovi cez ISDN linku pripojenie k providerovi cez adsl linku pripojenie k providerovi cez WiFi Koncové zariadenie: ISDN TA adsl modem, adsl router WiFi karta Bezpečnosť a VoIP: používanie antivírovej ochrany a antispyware, zablokovať nepotrebné služby, sústrediť sa na implementovanie heslovej politiky - 76 -
používať Firewall na koncovom zariadení, zablokovať nepotrebné porty a protokoly hlasovú prevádzku obmedziť na zariadeniach, kde sú uložené dôležité dáta (Softphone nenainštalovať na PC, ktorý slúži ako server) použitie softwarového SIP klienta (Softphone, X-Lite, iné) použitie hardwarového SIP klienta (IP telefón) povoliť na Firewalli príslušné UDP porty dané providerom doporučené šifrovanie spojenia (UA to musí podporovať) SIP Softphone nainštalovať iba na vyhradené počítače Na obrázkoch 6.2.1 a 6.2.2 sú znázornené odporúčané prepojenia takejto siete k sieti providera. V súčasnosti väčšina providerov dokáže takémuto zákazníkovi poskytnúť akceptovateľnú VoIP službu zo svojho portfólia. Obr. 6.2.1 Príklad prepojenia strednej privátnej siete a providera Obr. 6.2.2 Príklad prepojenia strednej privátnej siete a providera - 77 -
6.3 Návrh prepojenia veľkej privátnej siete a providera Pripojenie: pripojenie k providerovi cez adsl linku pripojenie k providerovi cez MPLS okruh pripojenie k providerovi cez prenajatý okruh (lease line) pripojenie k providerovi cez Ethernet (CISCO) Koncové zariadenie (u zákazníka): adsl router (vyššej triedy Firewall, VoIP brána, podpora IPsec) CISCO router (buď pre MPLS alebo pre Ethernet) Iné rozhranie (ATM, FR, atď) Bezpečnosť a VoIP (u zákazníka): používanie antivírovej ochrany a antispyware, zablokovať všetky služby a postupne povoliť potrebné, sústrediť sa na silnú heslovú politiku (pravidelná obmena hesiel) používať Firewall na koncovom zariadení, zablokovať nepotrebné porty a protokoly hlasovú prevádzku oddeliť od dátovej (použitie VLAN) použitie softwarového SIP klienta (Softphone, X-Lite, iné) ale len na zariadeniach, ktoré sú na inej LAN ako servre a databázy použitie hardwarového SIP klienta (IP telefón) použitie ALG zariadení (riešenie problému s NAT a Firewallom) Access listy, verifikácia volajúceho podľa certifikátov Kontrola logov a neoprávnených spojení Na obrázkoch 6.3.1, 6.3.2 a 6.3.3 sú znázornené odporúčané prepojenia takejto siete k sieti providera. - 78 -
Obr. 6.3.1 Príklad pripojenia pobočiek privátnej siete do MPLS siete providera Obr. 6.3.2 - Prepojenie sietí cez VPN tunel (IPsec) Obr. 6.3.3 - VPN prepojenie pobočiek cez centrálnu pobočku 6.3.1 Odporúčané bezpečnostné pravidlá Zákazník by mal: presne zadefinovať bezpečnostné pravidlá v sieti a podmienky a zdokumentovať ich - 79 -
chrániť dôležité databázy a servre prístupovými právami a certifikátmi a doležité informácie zálohovať (CD) do VoIP siete implementovať pre seba potrebné bezpečnostné mechanizmy (kap. 4.1 4.4) Provider by mal: podporovať štandardné bezpečnostné mechanizmy (IPsec) poskytnúť zákazníkovi cenovo dostupné a spoľahlivé riešenie (k službe VoIP poskytnúť telefónnu linku) 6.4 Návrh prepojenia nadnárodnej privátnej siete a providera Pripojenie: pripojenie k providerovi cez prenajatý okruh (lease line) pripojenie k providerovi cez Ethernet (CISCO) pripojenie k providerovi cez SONET/SDH - odporúčané Koncové zariadenie: CISCO router vyšších tried ako 3 Iné rozhranie (ATM, FR, atď) SDH rozhranie (napr. Lucent LKA.., Alcatel, Nortel a pod.) Bezpečnosť a VoIP: používanie antivírovej ochrany a antispyware, zablokovať všetky služby a postupne povoliť potrebné, sústrediť sa na silnú heslovú politiku (pravidelná obmena hesiel) používať Firewall na koncovom zariadení, zablokovať nepotrebné porty a protokoly hlasovú prevádzku oddeliť od dátovej (použitie VLAN) použitie softwarového SIP klienta (Softphone, X-Lite, iné) výlučne na zariadeniach fyzicky oddelených od Intranetu, databáz, servrov použitie hardwarového SIP klienta (IP telefón) odporúčané sieť takýchto klientov oddeliť od dátovej siete (smerom k providerovi nezávislé rozhrania pre dátovú a pre hlasovú prevádzku) použitie ALG zariadení (riešenie problému s NAT a Firewallom) Access listy, verifikácia volajúceho podľa certifikátov - 80 -
Kontrola logov a neoprávnených spojení Na obrázkoch 6.4.1-4 sú znázornené odporúčané prepojenia takejto siete k sieti providera. Obr. 6.4.1 Príklad pripojenia privátnej siete k providerovi Obr. 6.4.2 Príklad spolupráce Firewallu a SBC (Session Border Controller) - 81 -
Obr. 6.4.3 Príklad prepojenia privátnej siete na providera s využitím funkcionalít SBC Ďalšie možné prepojenie k providerovi na báze dostupnej softwarovej alebo hardwarovej platformy: Obr. 6.4.4 Pripojenie k providerovi cez softwarovú platformu bežiacu na serveri (napr. Bordeware - SIPassure) 6.4.1 Odporúčané bezpečnostné pravidlá Zákazník by mal: presne zadefinovať bezpečnostné pravidlá v sieti a podmienky a zdokumentovať ich chrániť dôležité databázy a servre prístupovými právami a certifikátmi a doležité informácie ukladať na zrkadlové servre (záloha dát) - 82 -
CISCO SYSTEMS Catalys t 8500 SER IES Switch Processor Powe r Su pp ly 0 Po wer Sup ply 1 SD Cisco 1720 WI C 0 OK B 1 B 2 O K FDX 100 BRI S/ T LNK CONSOLE AUX L P LOOP WIC 1 OK DSU CPU S3 SD Cisco 1720 WI C 0 OK B 1 B 2 O K FDX 100 BRI S/ T LNK CONSOLE AUX L P LOOP WIC 1 OK DSU CPU S3 SD Žilinská univerzita v Žiline do VoIP siete implementovať SBC a bezpečnostné mechanizmy vo VoIP (kap. 4.1 4.4) robiť monitorovanie svojej siete Provider by mal: podporovať požadované bezpečnostné mechanizmy zákazníkom (IPsec, TLS, SSL a iné) poskytnúť zákazníkovi náhradné riešenie pri výpadku siete (napr. pri výpadku vo VoIP spojení presmerovať hlasovú prevádzku na PSTN sieť alebo na mobilnú sieť) obr. 6.5.2, prípadne SLA vo VoIP presunúť právomoc registrácie užívateľov na privátny proxy server (umiestnený v privátnej sieti obr. 6.4.3) 6.5 Návrh prepojenia špecifickej privátnej siete a providera (Prepojenie siete Žilinskej univerzity a providera) Prepojenie siete Žilinskej univerzity a providera bude realizované optickým vláknom. Ako rozhranie prepojenia bude použitý router CISCO 7204 VXR (Príloha 4), ktorý bude prepojený k rozhraniu CISCO Catalyst 6509 (obr. 5.1.2). V tomto prípade bude len potrebné uvažovať, či daný provider má rozhrania podporujúce prenosové módy buď ATM, SDH alebo Ethernet. Vyhovujúce by v tomto prípade bolo ak by provider mal vo svojej sieti implementovaný niektorý z routerov CISCO sady 7200. V takomto prípade by boli využité všetky funkcionality oboch routerov. Predpokladám situáciu, že provider takéto zariadenie má. Prepojenie je znázornené na obr. 6.5.1. Obr. 6.5.1 Prepojenie siete Žilinskej univerzity a providera - 83 -
Pripojenie: pripojenie k providerovi cez Fast/Gbit Ethernet (CISCO) pripojenie k providerovi cez SONET/SDH pripojenie k providerovi cez ATM Koncové zariadenie: CISCO 7204 VXR (Príloha 4) Bezpečnosť a VoIP: používať Firewall na koncovom zariadení, zablokovať nepotrebné porty a protokoly nie je nutné hlasovú prevádzku oddeliť od dátovej použitie softwarového SIP klienta (Softphone, X-Lite, iné) výlučne na zariadeniach fyzicky oddelených od Intranetu (Rektorát), databáz, servrov použitie hardwarových IP telefónov použitie hardwarového SIP klienta (IP telefón) distribuovaná štruktúra siete z hľadiska VoIP (využiť už existujúce SIP proxy a Gatekeepre) šifrovanie SIP spojení a šifrovanie mediálneho kanálu nutné hlavne v podsieti Rektorátu (UA a rozhrania podporujúce IPsec, TLS, S/MIME, SRTP a SRTCP), nutné aby aj provider podporoval tieto mechanizmy 99,999% spoľahlivosť spojení (možnosť dovolať sa kedykoľvek) záložné riešenia pre zákazníka Kontrola logov a neoprávnených spojení 6.5.1 Odporúčané bezpečnostné pravidlá Zákazník by mal: presne zadefinovať bezpečnostné pravidlá v sieti a podmienky a zdokumentovať ich chrániť dôležité databázy a servre prístupovými právami a certifikátmi a doležité informácie ukladať na zrkadlové servre (záloha dát) do VoIP siete implementovať kryptovanie a SBC (v Intranete) robiť monitorovanie siete a pri výpadku v sieti informovať (email, SMS) správcu danej časti siete - 84 -
Provider by mal: podporovať požadované bezpečnostné mechanizmy zákazníkom (IPsec, TLS, SSL a iné) poskytnúť zákazníkovi náhradné riešenie pri výpadku siete (napr. pri výpadku vo VoIP spojení presmerovať hlasovú prevádzku na PSTN sieť alebo na mobilnú sieť) obr. 6.5.2, prípadne SLA vo VoIP presunúť právomoc registrácie užívateľov na privátny proxy server (umiestnený v privátnej sieti obr. 6.4.3) decentralizovaná štruktúra siete Obr. 6.5.2 Príklad presmerovania hlasovej služby na mobilnú sieť pri výpadku VoIP - 85 -