FAKULTA ELEKTROTECHNIKY A INFORMATIKY STU V BRATISLAVE

Size: px
Start display at page:

Download "FAKULTA ELEKTROTECHNIKY A INFORMATIKY STU V BRATISLAVE"

Transcription

1

2 FAKULTA ELEKTROTECHNIKY A INFORMATIKY STU V BRATISLAVE Bc. Karol Krasňan PROBLEMATIKA BEZPEČNOSTI V SIEŤACH VOIP Diplomová práca Vedúci diplomovej práce: Ing. Vladimír Ondruš Pedagogický vedúci diplomovej práce: prof. Ing. Ivan Baroňák, PhD. Dátum odovzdania diplomovej práce: máj 2008

3 Čestné prehlásenie Čestne prehlasujem, že diplomovú prácu som vypracoval samostatne pod vedením vedúceho diplomovej práce, s využitím získaných teoretických poznatkov a s použitím uvedenej literatúry. BRATISLAVA, máj 2008 Bc. Karol Krasňan

4 Poďakovanie Týmto by som chcel poďakovať môjmu vedúcemu diplomovej práce Ing. Vladimírovi Ondrušovi za jeho odborné vedenie. Za množstvo odborných pripomienok, praktických rád, odporúčaní a pomoci pri realizácii tejto práce. Taktiež sa chcem poďakovať svojej manželke a dcére za poskytnutý priestor potrebný na vytvorenie diplomovej práce a všetkým, ktorí mi držali palce a podporovali ma. Moje najväčšie poďakovanie patrí mojím rodičom vďaka ktorým som mohol študovať, rozvíjať svoje schopnosti a rásť.

5 Anotácia Slovenská technická univerzita v Bratislave Fakulta elektrotechniky a informatiky Študijný odbor: Telekomunikácie Autor: Bc. Karol Krasňan Názov diplomovej práce: Problematika bezpečnosti v sieťach VoIP Vedúci diplomovej práce: Ing. Vladimír Ondruš Pedagogický vedúci diplomovej práce: prof. Ing. Ivan Baroňák, PhD. Termín odovzdania: Máj 2008 Práca vo svojom úvode popisuje základné charakteristiky signalizačného protokolu SIP pri použití vo VoIP sieťach. Následne sú analyzované možné bezpečnostné hrozby spojené s používaním VoIP sietí. Najmä nebezpečenstvo zneužitia prihlasovacích údajov, odpočúvania a DoS útokov. Zároveň práca predkladá možné riešenia týchto bezpečnostných hrozieb najmä pri použití Open Sip Express Router ako SIP proxy servera. V praktickej časti práca obsahuje podrobný popis implementácie jednotlivých stupňov zabezpečenia komunikácie medzi proxy servermi, klientom a proxy serverom, pri použití OpenSER. Taktiež jej obsahom je porovnanie efektívnosti jednotlivých implementovaných spôsobov zabezpečenia. 4

6 Annotation Slovak University of Technology in Bratislava Faculty of Electrical Engineering and Information Technology Degree Course: Telecommunications Author: Bc. Karol Krasňan Thesis: Security threats in VoIP networks Supervisor: Ing. Vladimír Ondruš Education supervisor: prof. Ing. Ivan Baroňák, PhD. 2008, May At the beginning of this work is described main characteristics of signaling protocol SIP in VoIP networks. Consequently are analyzing main VoIP security threats. Especially misusing registration information, eavesdropping and DoS attack. Together work described possible solutions of this security threats especially with use Open Sip Express Router as proxy server. In practical part work contain detailed description of implementation several security levels of communication between proxy servers, client proxy server with OpenSER using. Accordingly its content is efficiency comparison of several security implementations variants. 5

7

8 Obsah Obsah... 7 Zoznam obrázkov a grafov...10 Zoznam použitých skratiek Úvod SIP: Session Initiation Protocol Stručná história Prehľad funkcií SIP Formát hlavičky SIP správy Polia hlavičiek požiadavkových aj odpoveďových správ Polia hlavičiek požiadavkových správ Polia hlavičiek odpoveďových správ Polia hlavičiek tela správy správa SIP Požiadavkové správy Odpoveďové správy SDP : Session Description Protocol SIP Transakcia a dialóg Bezpečnostné hrozby VoIP systémov VoIP spam (vamming, SPIT (Spam over Internet Protocol)) SPIT scenáre Call-centrum Telefonické Roboty SPIT vyzváňací tón Kombinácie Možné spôsoby obrany Cena telefonovania Biele zoznamy / Zoznamy priateľov Rozšírenie bielych zoznamov o dôveryhodných účastníkov Blacklists Štatistické blacklisty Interakcia s hlasovým menu Greylisty Simultánna konverzácia Vishing Nedostupnosť služby (DoS Denial of Service) Prelomenie registrácie Odpočúvanie Pasívne odpočúvanie Aktívne odpočúvanie (man in the middle)

9 4. Spôsoby zabezpečenia Message digest authentication S/MIME SIP over TLS (Transport Layer Security) Schéma SIPS URI Princíp fungovania TLS SRTP IPsec Zabezpečenie VoIP komunikácie pri použití OpenSER Modul AUTH Podpora TLS...39 PRAKTICKÁ ČASŤ Počiatočná konfigurácia Použité softvérové prostriedky Testovanie základnej konfigurácie Použitý konfiguračný súbor Testovacie spojenie Implementácia AUTH modulu Potrebné softvérové úpravy Konfigurácia openserctlrc Zmeny konfigurácie OpenSER Testovacie spojenie Implementácia OpenSER TLS Potrebné softvérové úpravy Generovanie autentifikačných certifikátov Certifikáty certifikačnej autority Užívateľské certifikáty Šifrovanie komunikácie medzi dvoma OpenSER Zmeny konfigurácie OpenSER Testovacie spojenie Šifrovanie komunikácie medzi užívateľským klientom a OpenSER Zmeny konfigurácie OpenSER Zmeny konfigurácie užívateľského klienta Testovacie spojenie Zabezpečenie komunikácie použitím OpenVPN Princíp fungovania VPN Konfigurácia OpenVPN Testovacie spojenie Testovanie efektivity OpenSER s TLS a OpenVPN Východiská testovania Priebeh testovania

10 10.3 Vyhodnotenie testovania Záver...84 Zoznam použitej literatúry...85 PRÍLOHA A Parametre a poskytované funkcie AUTH modulu...87 PRÍLOHA B Konfiguračné parametre a funkcie ponúkané programovou časťou OpenSER TLS

11 Zoznam obrázkov a grafov Obr. 1 Hierarchické usporiadanie vybraných protokolov...14 Obr. 2 Schematické znázornenie pozície útočníka pri pasívnom odpočúvaní...30 Obr. 3 Schematické znázornenie pozície útočníka pri aktívnom odpočúvaní...32 Obr. 4 Schematické znázornenie zabezpečeného spojenia cez vonkajšiu sieť...35 Obr. 5 Schematické znázornenie priebehu zostavovania šifrovaného spojenia cez TLS...37 Obr. 6 Schéma virtuálnej siete použitej pri realizácii praktickej časti práce...42 Obr. 7 Priebeh zostavenia, realizácie a ukončenia testovacie spojenia...48 Obr. 8 Priebeh prihlasovania bez zadania užívateľského hesla...55 Obr. 9 Schéma zostavenia, priebehu a ukončenia testovacieho spojenia pri použití AUTH modulu...57 Obr. 10 Schéma zostavenia, priebehu a ukončenia testovacieho spojenia pri šifrovaní spojenia medzi OpenSER proxi servermi...65 Obr. 11 Schéma zostavenia, priebehu a ukončenia testovacieho spojenia pri šifrovaní celého spojenia...70 Obr. 12 Schematické znázornenie spojenia proxy serverov použitím VPN...74 Obr. 13 Schéma zostavenia, priebehu a ukončenia testovacieho spojenia pri zabezpečení spojenia medzi proxy servermi použitím OpenVPN...75 Obr. 14 Schéma východiskovej konfigurácie použitej na testovanie výkonnosti šifrovania OpenSER s TLS a OpenVPN...77 Obr. 15 Schéma generovaného spojenia pri testovaní výkonnosti šifrovania OpenSER s TLS a OpenVPN...78 Graf 1 Oneskorenie správy pri zaťažení 10 správ za sekundu...79 Graf 2 Celkový čas spojenia pri zaťažení 10 správ za sekundu...79 Graf 3 Oneskorenie správy pri zaťažení 100 správ za sekundu...80 Graf 4 Celkový čas spojenia pri zaťažení 100 správ za sekundu...80 Graf 5 Oneskorenie správy pri zaťažení 400 správ za sekundu...81 Graf 6 Celkový čas spojenia pri zaťažení 400 správ za sekundu...81 Graf 7 Priemerné oneskorenie správy vzhľadom na zaťaženie systému...82 Graf 8 Priemerné celkové trvanie spojenia vzhľadom na zaťaženie systému...82 Graf 9 Vyťaženie CPU servera podľa početu zaťaženia systému

12 Zoznam použitých skratiek AES Advanced Encryption Standard ARP Address Resolution Protocol CPU Central Processing Unit DoS Denial of Service HTTP Hyper Text Transport Protocol IETF The Internet Engineering Task Force IP Internet Protocol IPsec Internet Protocol Security MAC Media Access Control OpenSER Open SIP Express Router OSI Open Systems Interconnection PSTN Public Switched Telephone Network RTP Real Time Protocol S/MIME Secure / Multipurpose Internet Mail Extensions SAP Session Announcement Protocol SDP Session Description Protocol SIP Session Initialization Protocol SMTP Simple Mail Transport Protocol SPIT Spam over Internet Protocol SRTP - Secure Real Time Protocol TCP Transmission Control Protocol TLS Transport Layer Security UDP User Datagram Protocol URI Uniform Resource Identifier URL Uniform Resource Locator VoIP Voice over Internet Protocol VPN Virtual Private Network 11

13 1. Úvod S čoraz väčším prenikaním digitalizácie a používaním moderných počítačových prostriedkov v bežnom živote sa rapídne zvyšuje aj podiel elektronickej komunikácie medzi ľuďmi. Významnou zložkou elektronickej komunikácie sa stalo aj telefonovanie hlavne prostredníctvom siete Internet, označované VoIP Voice over IP. V tejto oblasti má hlavnú zásluhu na tejto situácii softvér SKYPE, ktorý vďaka svojej jednoduchosti a užívateľskej prívetivosti priblížil komunikáciu prostredníctvom Internetu širokým masám bežných užívateľov. Podľa prieskumu agentúry In-Stat z júla 2007 v roku 2006 pribudlo celosvetovo 34 miliónov predplatiteľov VoIP služieb. V roku 2011 bude globálny trh s VoIP službami predstavovať 44 miliárd amerických dolárov. Aj z uvedených čísel je zjavné, že používanie komunikácie prostredníctvom Internetu zažíva veľký rozmach, ktorý bude pokračovať ešte väčším tempom. So stúpajúcim množstvom používateľov VoIP služieb, stúpa aj počet užívateľov, ktorí túto formu komunikácie využívajú nielen na osobnú komunikáciu, ale aj na dôležitú pracovnú, či firemnú komunikáciu. Taktiež rastie počet firiem a organizácií, ktoré využívajú VoIP ako svoj hlavný komunikačný prostriedok, prípadne sa stal pre ne predmetom podnikania a generovania ziskov. S postupným rozširovaním Internetovej komunikácie do biznis prostredia, ako aj so zvyšujúcimi sa nárokmi bežných užívateľov, sa dostáva do popredia otázka bezpečnosti takejto komunikácie. Predstava, kedy by bolo možné odpočúvať dôverné firemné rozhovory, prípadne útokom znemožniť komunikáciu v rámci celej firmy, je určite nepríjemná. Z týchto dôvodov veľa spoločností zaoberajúcich sa VoIP čoraz viac a komplexnejšie rieši otázky spojené so zabezpečením tejto formy komunikácie. Cieľom mojej diplomovej práce je priblížiť čitateľovi základy fungovania VoIP s najrozšírenejším signalizačným protokolom SIP. Analyzovať potenciálne bezpečnostné hrozby a predostrieť možné spôsoby zabezpečenia a prevencie pred nimi. Zároveň sa zameriavam na zabezpečenie komunikácie pri použití open source SIP proxy servera, Open SIP Express Router (OpenSER). V praktickej časti uvádzam spôsoby zabezpečenia komunikácie v tomto prostredí, ich bezpečnostnú analýzu a porovnanie možných spôsobov zabezpečenia. 12

14 2. SIP: Session Initiation Protocol SIP je protokol, ktorý umožňuje dvom, viacerým internetovým koncovým bodom (označovaným tiež užívateľskí agenti) nájsť jeden druhého a vytvoriť charakteristické spojenie, ktoré chcú zdieľať. Pre lokalizáciu budúcich účastníkov spojenia, a pre ďalšie funkcie, SIP umožňuje vytvoriť infraštruktúru sieťových hostiteľských počítačov (označovaných ako proxy servery), na ktoré môžu užívateľskí agenti posielať registrácie, výzvy na vytvorenie spojenia, a iné požiadavky. SIP je agilný, všeobecne orientovaný nástroj pre vytváranie, modifikovanie, a ukončovanie spojení, ktoré pracujú nezávisle od nižšie pracujúcich transportných protokolov a so závislosťou na type spojenia, ktoré je vytvárané. Ako bolo už povedané SIP zabezpečuje vytvorenie spojenia, nezabezpečuje prenos samotných multimediálnych dát, ani nijakým spôsobom nedozerá na ich prenos. Túto funkciu zabezpečujú iné protokoly, s ktorými SIP spolupracuje (napr. RTP - Real Time Protocol). 2.1 Stručná história SIP bol vyvinutý skupinou IETF (The Internet Engineering Task Force). Verzia 1.0 bola publikovaná v roku Následne boli v protokole urobené významné zmeny, ktoré vyústili do vydania verzie 2.0 v roku Protokol sa stal štandardom v Marci 1999 a bol publikovaný v RFC 2543 v Apríli Práce na protokole pokračujú ďalej a doteraz bolo vydaných niekoľko rozširujúcich RFC dokumentov. SIP obsahuje elementy dvoch najrozšírenejších Internetových protokolov: Hyper Text Transport Protocol (HTTP) používaný na prezeranie web stránok a Simple Mail Transport Protocol (SMTP) používaný na výmenu ových správ. Od HTTP si SIP prepožičal klient server dizajn a používanie URLs a URIs. Od SMTP SIP prevzal textovú kódovaciu schému a štýl hlavičky. Napríklad SIP používa SMTP hlavičky ako To, From, Date a Subject. 2.2 Prehľad funkcií SIP SIP je kontrolný protokol pracujúci na aplikačnej vrstve OSI modelu, ktorý môže vytvoriť, modifikovať a ukončiť multimediálne spojenie (napr. Internetové telefónne volania). SIP vie taktiež pripojiť ďalších účastníkov do už existujúceho spojenia ako 13

15 sú multicastové konferencie. SIP podporuje mapovanie mien a služby na presmerovanie, čo umožňuje osobnú mobilitu užívateľovi stačí udržovať jediný externe viditeľný identifikátor. Umožňuje vytvárať spojenia v rámci paketových sietí ale taktiež je možné ho použiť pri vytváraní spojenia s klasickou verejnou telekomunikačnou sieťou. Hlavné signálne funkcie protokolu sú nasledujúce: lokalizácia koncového bodu kontaktovanie koncového bodu a vymedzenie pravidiel pre vytvárané spojenie výmena informácií o médiu, ktoré umožňuje spojenie vytvoriť modifikácia existujúcich spojení ukončenie existujúcich spojení SIP bol rozšírený, aby bol schopný poskytovať aktuálne informácie o klientoch podobne ako spojenia pre okamžitú výmenu správ (instant message). Tieto funkcie obsahujú: poskytovanie a získavanie aktuálnych informácií žiadanie doručenia aktuálnych informácií okamžité transportovanie správ Obr. 1 Hierarchické usporiadanie vybraných protokolov Na obrázku 1 je znázornené hierarchické usporiadanie protokolov používaných pri multimediálnom prenose v paketových sieťach. Ako bolo už povedané, SIP je protokol pracujúci na najvyššej aplikačnej vrstve modelu. Na transportnej vrstve SIP 14

16 využíva služby tak spojovo orientovaného TCP protokolu, ako aj nespojovo orientovaného protokolu UDP. Na internetovej vrstve je využívaný IP protokol. SIP protokol sa využíva najmä v Ethernet sieťach, ale jeho uplatnenie je možné aj v ostatných paketových sieťach. 2.3 Formát hlavičky SIP správy SIP je textovo orientovaný protokol, preto jeho správy majú formát textových správ. Správy protokolu SIP obsahujú hlavičky, ktoré umožňujú správnu interpretáciu správy. V nasledujúcej časti si stručne popíšeme niektoré polia, ktoré hlavičky SIP správy obsahujú. Polia hlavičky SIP správy vo väčšine prípadov dodržujú rovnaké pravidlá ako hlavičky HTTP správy. Polia hlavičky SIP správy môžeme rozdeliť do skupín podľa toho, v akých správach resp. časti správy sa vyskytujú: polia hlavičiek požiadavkových aj odpoveďových správ polia hlavičiek požiadavkových správ polia hlavičiek odpoveďových správ polia hlavičiek tela správy a podľa toho kto ich vkladá, upravuje v správe: end-to-end môže ich vložiť a upravovať len koncový bod hop-by-hop môže ich vložiť a upravovať len proxy server Väčšina hlavičiek v protokole SIP sú typu end-to-end. Polia hlavičky sú definované Hlavička : pole, kde hlavička je identifikátor, ktorý reprezentuje názov poľa a pole je skupina znakov obsahujúca informáciu. Okrem niekoľkých výnimiek nie je podstatné poradie usporiadania hlavičiek v SIP správe. Pokiaľ sa v správe vyskytne neznáma hlavička tak je ignorovaná Polia hlavičiek požiadavkových aj odpoveďových správ Nasledujúce hlavičky sa môžu vyskytovať ako v požiadavkových, tak aj v odpoveďových správach SIP. Uvedené sú len niektoré najčastejšie používané hlavičky. 15

17 Call-ID táto hlavička sa povinne nachádza v každej požiadavkovej aj odpoveďovej správe. Je to časť jedinečného identifikátora komunikujúcich užívateľov. Musí byť jedinečné medzi všetkými volaniami okrem prípadu kedy ide o registračnú požiadavku. Hlavička Call-ID je vždy vytváraná užívateľským agentom a nikdy nie je menená serverom. Contact hlavička Contact je používaná na oznámenie zdroja požiadavky alebo pôvodcu odpovede. Keď už je raz prijatý obsah tejto hlavičky, tak identifikátor zdroja (URI), ktorý obsahuje, môže byť uložený do pamäte a použitý pre budúce smerovanie správ. Táto hlavička musí byť obsiahnutá v správach INVITE a 200 OK. CSeq táto hlavička je požadovaná vo všetkých požiadavkových správach. Toto pole obsahuje desiatkové číslo, ktoré sa zvýši pri každej požiadavke. Obyčajne sa zvýši o 1 pri každej novej požiadavke s výnimkou požiadaviek CANCEL a ACK, ktoré používajú hodnotu CSeq od správy INVITE, ku ktorej sa viažu. From obsah poľa hlavičky From identifikuje pôvodcu odoslanej požiadavky. Je to jedna z dvoch adries používaná na identifikáciu spojenia. Toto pole obsahuje identifikátor zdroja a obsahuje aj pole tag. Tag je číselná hodnota, ktorú generuje užívateľský klient pri vytváraní správy INVITE. Táto hodnota sa v rámci spojenia (dialogu) udržuje rovnaká. To pole hlavičky To je vyžadované v každej SIP správe a používa sa na identifikáciu cieľa správy. Podobne ako užívateľský klient, ktorý inicializuje spojenie vkladá hodnotu tag do poľa From. Analogicky užívateľský klient, ktorý na výzvu odpovedá vkladá tag hodnotu do hlavičky To. Hodnoty To tag, From tag a Call-ID vytvárajú Dialog ID, ktorý je jedinečným identifikátorom celého spojenia. Record-Route hodnota hlavičky sa používa na smerovanie správy cez proxy servery, ktoré vytvárajú spojenie medzi dvoma užívateľskými agentmi. Proxy server vkladá svoju adresu do poľa tejto hlavičky a tým nastaví vracajúcej sa správe cestu po ktorej sa má vrátiť. 16

18 Retry-After toto pole sa používa na oznámenie, kedy sa môže znova opakovať pokus o kontaktovanie zdroja alebo služby. Obsahujú ju správy, ktoré oznamujú chybu. User-Agent pole tejto hlavičky nesie informáciu o užívateľskom agentovi, ktorý vygeneroval správu. Via pole hlavičky Via je používane na zaznamenanie trasy, ktorou išla SIP správa, aby bolo možné odpoveď smerovať tou istou cestou. Užívateľský agent generujúci správu vloží svoju adresu do poľa hlavičky. Zatiaľ čo pri väčšine hlavičiek SIP správy poradie záznamov nie je podstatné, pri poli hlavičky Via je poradie záznamov podstatné. Záznamy musia byť v správnom poradí, lebo na ich základe sa smeruje správa. Proxy server smerujúci správu vloží do poľa hlavičky Via svoju vlastnú adresu na vrchol poľa. Proxy server alebo užívateľský klient, ktorý generuje odpoveď skopíruje všetky záznamy z poľa hlavičky v požadovanom poradí a pošle správu na adresu, ktorá bola na vrchu záznamov. Proxy server, ktorý dostane takúto správu, skontroluje adresu na vrchu poľa hlavičky, či súhlasí s jeho adresou. Pokiaľ nie došlo k chybe smerovania a správa je zahodená. Pokiaľ adresa súhlasí, je odstránená z poľa hlavičky Via a odpoveď je odoslaná na nasledujúcu adresu v poradí Polia hlavičiek požiadavkových správ Hlavičky uvedené v nasledujúcej časti sa vyskytujú v požiadavkových správach protokolu SIP. Taktiež sú uvedené len častejšie používané hlavičky. Accept táto hlavička je definovaná v protokole HTTP a je používaná na indikáciu typov formátov, ktoré sú pre odosielateľa správy akceptovateľné pri odpovedi. Pokiaľ hlavička nie je v správe prítomná, predpokladá sa predvolená hodnota application/sdp. Authorization pole tejto hlavičky je používané na prenos identifikačných údajov klienta potrebných pri jeho autorizovaní. Táto hlavička sa vkladá do správy na výzvu servera, alebo aj bez nej, pokiaľ sa predpokladá nutnosť autentifikácie. Zároveň v nej 17

19 klient posiela zdieľané tajomstvo. Tým však zároveň požaduje od servera odpoveď a pridelenie užívateľského mena a hesla. Allow hlavička je používané na oznámenie metód, ktoré užívateľský klient podporuje. Join táto hlavička je používaná v správe INVITE. Je výzvou na vytvorenie nového spojenia k už existujúcemu spojeniu. Parametrami poľa hlavičky Join sú Call-ID už existujúceho spojenia To tag a From tag. Toto sa využíva pri vytváraní konferenčných hovorov Polia hlavičiek odpoveďových správ Authenticaton-Info pole s touto hlavičkou je vkladané do správy, ktorá je odpoveďou na požiadavku obsahujúcu hlavičku Authorization alebo WWW- Authenticate. Server v tomto poli posiela klientovi potrebné údaje k prihláseniu zašifrované zdieľaným tajomstvom. Warning pole hlavičky Warning poskytuje podrobnejšiu informáciu o varovaní v podobe trojmiestného čísla, ktoré je potom interpretované príjemcom správy Polia hlavičiek tela správy Hlavičky opísané v tejto časti obsahujú vo svojich poliach informácie o obsahu tela správy. Content-Encoding, Content-Disposion, Content-Language, Content- Lenght, Content-Type v telách týchto hlavičiek sú uvedené informácie o obsahu tela správy. Teda o type jeho kódovania, jeho významu, jazyka, dĺžky a o type samotného obsahu. 18

20 2.4 správa SIP V predchádzajúcej časti sme si opísali najčastejšie používané hlavičky v správach protokolu SIP. Avšak správa môže okrem hlavičiek, ktoré nesú významnú informačnú hodnotu obsahovať aj rôzne typy informácií uložených v tele správy. SIP prenáša tieto informácie obdobným spôsobom, ako sú prenášané prílohy v tele ových správ. Na indikáciu obsahu tela správy sa používa hlavička Content-Disposion. V prípade, že táto hlavička v správe nie je prítomná predpokladá sa, že správa obsahuje informácie o spojení. Na ďalšie špecifikovanie obsahu tela správy sa používajú hlavičky opísané vyššie. Samotné správy SIP môžeme rozdeliť na dve skupiny: požiadavkové správy odpoveďové správy Požiadavkové správy Každá požiadavková správa obsahuje na svojom začiatku rezervované slovo, ktoré sa označuje ako metóda. Na základe názvu metódy vie klient alebo server vyhodnotiť správu a reagovať na ňu. Vo svojej základnej definícii obsahuje protokol SIP šesť metód a to INVITE, REGISTER, BYE, ACK, CANCEL a OPTIONS. Neskôr bol rozšírený o ďalšie metódy REFER, SUBSCRIBE, NOTIFY, MESSAGE, UPDATE, INFO a PRACK Odpoveďové správy Odpoveďové správy sú generované serverom ako odpoveď na prijatú požiadavku. Tieto správy môžu obsahovať rôzne hlavičky, ktoré obsahujú bližšie informácie, na základe ktorých bola odpoveď generovaná. Odpoveďové správy sú zaradené do šiestich skupín. Prvých päť bolo prevzatých od HTTP šiesta bola vytvorená pre SIP. Každá správa je identifikovaná trojicou číslic, na základe ktorých je aj zaradená do nasledujúcich skupín: 1xx Informácia Indikujú stav priebehu vytvárania spojenia 2xx Úspech Informujú o úspešnom vykonaní požiadavky 3xx Presmerovanie Server nimi informuje klienta o iných možných pripojenia 4xx Chyba klienta Požiadavka bola neúspešná kvôli chybe klienta 19

21 5xx Chyba servera Požiadavka bola neúspešná kvôli chybe servera 6xx Globálna chyba Požiadavka bola neúspešná Pre zjednodušenie identifikácie problému SIP spolu s kódom odpoveďových správ posiela aj stručný popis prečo daná situácia nastala napr.: 400 Bad Request 2.5 SDP : Session Description Protocol Session Description Protocol popisuje multimediálne spojenia. Je navrhnutý, aby medzi samotnými účastníkmi spojenia vymieňal informácie o vlastnostiach spojenia. SDP je výhradne len formát na popis multimediálneho spojenia. Nerieši otázku transportu samotných dát. V tejto oblasti sa spolieha na iné protokoly najmä na Session Annoucement Protocol (SAP) alebo na Session Initiation Protocol (SIP). SDP správy sú najčastejšie transportované v rámci správy SIP, to znamená, že využíva hlavičku správy SIP a v jej textovej časti sú uložené informácie protokolu SDP. Správa protokolu SDP obsahuje: názov a účel spojenia čas vytvorenia spojenia typy mediálnych dát začlenených do spojenia informácie o prijímaní mediálnych dát (IP adresa, port, atď.) 2.6 SIP Transakcia a dialóg Keďže SIP správy sú prenášané cez sieť nezávisle, musí byť vytvorený systém ako jednotlivé správy identifikovať a správne ich priradiť jednu k druhej. Preto sú SIP správy obyčajne zostavené do SIP transakcií. SIP transakcia je sekvencia SIP správ, ktoré si medzi sebou vymieňajú jednotlivé sieťové elementy. Transakcia pozostáva z jednej požiadavky a jednej finálnej odpovede. Príkladom môže byť transakcia zostavenia spojenia. Volajúci odosiela správu INVITE (požiadavka). Následne dostáva niekoľko odpovedí: 100 Trying, 180 Ringing a 200 OK, ktorá je finálnou odpoveďou a tým aj ukončením transakcie. Ďalšou transakciou môže byť ukončenie spojenia. Klient odošle požiadavku BYE a dostáva odpoveď 200 OK, čím je transakcia ukončená. 20

22 Taktiež však musí existovať spôsob ako identifikovať jednotlivé transakcie. Môže sa stať, že jeden užívateľ naraz uskutočňuje viacero hovorov a teda potrebuje vedieť, ktorá správa prípadne transakcia sa viaže k jednotlivému hovoru. Táto identifikácia sa označuje SIP dialóg. SIP dialóg predstavuje kompletné spojenie medzi dvoma účastníkmi, teda sa môže skladať z viacerých transakcií. Ako bolo už spomenuté SIP dialóg je identifikovaný použitím Call-ID, From tag a To tag, ktoré vytvárajú Dialog ID. Zároveň na identifikáciu transakcie v rámci dialógu nám slúži pole CSeq. 21

23 3. Bezpečnostné hrozby VoIP systémov V nasledujúcej časti sa budeme podrobnejšie venovať možným bezpečnostným hrozbám v súvislosti s VoIP systémami a špeciálne so zameraním na používanie SIP protokolu. Možných bezpečnostných hrozieb je veľké množstvo, preto sa zameriame na najrozšírenejšie a potenciálne najviac nebezpečné z hľadiska zachovania súkromia, komfortu používania služby a samotnej dostupnosti služby. Zároveň rozoberieme možné riešenia týchto bezpečnostných hrozieb. 3.1 VoIP spam (vamming, SPIT (Spam over Internet Protocol)) S masívnym rozširovaním internetového telefonovania narastá aj hrozba zneužitia tejto technológie na rôzne podvodné aktivity. Tak, ako sme toho svedkami pri e- mailovej komunikácii. Skúsenosti, kedy každý deň dostávate desiatky nevyžiadaných ov, určite nie sú príjemné. Často sa zdá, že boj proti ovému spamu je bez konca. Našťastie v poslednej dobe sa úspešne darí obmedzovať množstvo spamu, ktoré sa dostane až k užívateľovi. Samozrejme tento boj stojí obrovské finančné prostriedky či už je to čas ľudí, ktorí sa bojom zo spamom zaoberajú, alebo je to množstvo výpočtového výkonu použitého na rôzne detekcie. Analogická situácia môže nastať pri VoIP komunikácii. Predstava kedy stále vyzváňa telefón, aby po jeho zdvihnutí si človek vypočul nechcenú reklamu, či inú správu určite nie je príjemná. V súčasnej dobe táto forma telefonického spamu ešte nie je veľmi rozvinutá, ale už sa objavili prvé náznaky a nebezpečné pokusy. Aj vďaka skúsenostiam z oblasti ov sú spoločnosti, ktoré sa zaoberajú VoIP obozretné a snažia sa vyvíjať aktívne nástroje na obranu proti tejto hrozbe. Rozdiel medzi ovou komunikáciu a VoIP je však na prvý pohľad zrejmý. E- mailová komunikácia je asynchrónna. To umožňuje použiť množstvo rôznych algoritmov na detekciu nevyžiadanej pošty, nakoľko každá správa obsahuje všetky informácie o jej odosielateľovi a pôvode ešte predtým ako je vôbec doručená adresátovi. Na základe týchto informácii je systém schopný s vysokou mierou úspešnosti identifikovať nevyžiadanú poštu. Naopak, telefonický hovor je synchrónna komunikácia, čo nám nedáva toľko informácii o jeho účelu a obsahu. Tým je oveľa náročnejšie identifikovať nechcený hovor. 22

24 Nevyžiadané (SPIT) volania môžu pochádzať od živej osoby (človeka), ktorý uskutoční hovor. Môže ísť o rôzne call-centrá, predajné ponuky a pod. Nebezpečnejšia forma, zákonom zakázaná, je používanie automatov, ktoré sú schopné generovať tisícky volaní vo veľmi krátkom čase SPIT scenáre Call-centrum Call-centrá sa zameriavajú najčastejšie na získavanie nových klientov pre rôzne tipy služieb. Počítač systematicky alebo náhodne vyberá užívateľa na telefonický hovor. V prípade, že účastník odpovie na hovor, tento je prepojený na voľného operátora, ktorý realizuje samotný hovor. Počet súčasne vedených hovorov a tým pádom aj dopad nevyžiadaných telefonátov, závisí priamo úmerne od počtu operátorov v callcentre. Nepredpokladá sa, že táto forma nevyžiadaných telefonátov by mala v budúcnosti výrazne negatívne ovplyvňovať samotnú službu Telefonické Roboty Internetové telefonovanie je komunikačná platforma silne založená na počítačoch. Preto najčastejšie práve počítače vykonávajú nevyžiadané hovory. Systematicky, alebo náhodne vyberajú účastníkov, ktorým je po akceptovaní volania prehratá správa SPIT vyzváňací tón Niektoré VoIP telefóny umožňujú akceptovať špeciálny typ SIP hlavičky označovaný Allert-info, ktorý môže obsahovať URL adresu na prednahratý zvukový súbor, ktorý sa použije ako zvonenie. Takéto zvonenie môže byť zneužité na reklamné účely ešte predtým, ako je vôbec hovor akceptovaný. Správnou konfiguráciou VoIP telefónu sa dá tomuto prístupu ľahko zabrániť. Treba zakázať možnosť sťahovať vyzváňacie tóny z Internetu Kombinácie Taktiež je možné počítať s kombináciou predchádzajúcich scenárov a ich rôznymi obmenami. 23

25 3.1.2 Možné spôsoby obrany V dnešnej dobe exituje len niekoľko možností, ako sa reálne brániť voči SPIT. V nasledujúcej časti priblížime hlavné spôsoby obrany proti nevyžiadaným reklamným hovorom generovaným pomocou robotov, nakoľko sa očakáva, že práve táto oblasť bude najviac problematická, podobne, ako to je pri ovej komunikácii Cena telefonovania Bežným spôsobom boja proti nevyžiadaným hovorom je zvýšenie ceny hovorov pre volajúceho (spamera). Tento prístup môže byť čiastočne efektívny, nakoľko môže potenciálneho spamera odradiť od vykonávania jeho činnosti. Avšak tento spôsob je v rozpore s myšlienkou VoIP znižovania nákladov na telefonovanie Biele zoznamy / Zoznamy priateľov Každý účastník v telefónnom systéme si udržiava vlastný zoznam účastníkov, od ktorých chce prijímať hovory. Ostatní účastníci, ktorí sa nenachádzajú v tomto zozname, sú automaticky odmietnutí a nie je im umožnené uskutočniť hovor. Tento prístup spôsobuje problémy s prvým kontaktom. Zatiaľ čo tento prístup je veľmi efektívny pri odstránení SPIT, taktiež dochádza k potlačeniu želaných hovorov Rozšírenie bielych zoznamov o dôveryhodných účastníkov Na povolenie volania od účastníka, ktorý sa nenachádza v súkromnom bielom zozname, je možné sa pozrieť do zoznamu dôveryhodných účastníkov na webe. Každý účastník garantuje dôveryhodnosť niekoľkým ďalším účastníkom, ktorých má vo svojom bielom zozname. Pokiaľ sa tieto zoznamy udržujú iba v rámci dôveryhodných účastníkov, rýchlo narastá zoznam bez nejakých problémov. Základný problém je v tom, pokiaľ niekto garantuje dôveryhodnosť spamerovi. V tom prípade celý whitelist je kompromitovaný a stráca svoj zmysel Blacklists Blacklist môže byť taktiež udržiavaný účastníkom samotným a taktiež môže existovať niekoľko centrálnych blacklistov na webe. Pokiaľ je identifikovaný zdroj SPIT, je pridaný do blacklistu, a pri volaní iným účastníkom je tento hovor odmietnutý. Tento prístup je však obmedzený iba na blokovanie už odhalených spamerov. Pokiaľ účastník používa iba súkromný blacklist, tak je vysoko pravdepodobné, že sa v ňom 24

26 bude nachádzať len malá časť spamerov. Centrálne blacklisty sú oveľa viac efektívne, avšak nezabránia hovorom od neidentifikovaných spamerov Štatistické blacklisty Telefónny poskytovatelia sú schopní presne analyzovať prenášané dáta a použitím štatistických metód o prirodzených hovoroch identifikovať spamera. Napr. v prípade, že účastník volá na stovky rôznych telefónnych čísel v určitom definovanom časovom intervale, pričom malá časť z nich skutočne odpovedá na hovor, ide s najväčšou pravdepodobnosťou o spamera. Takýto užívateľ môže byť pridaný do verejného blacklistu a ostatní účastníci nebudú od neho akceptovať hovor Interakcia s hlasovým menu Predtým, ako bude volajúci spojený s volaným účastníkom, bude nasmerovaný na automatické hlasové menu a bude od neho požadované vykonanie úlohy napr. Pre pokračovanie hovoru prosím stlačte 562*#. Iba po zadaní správnych symbolov bude hovor pokračovať, v opačnom prípade bude odmietnutý. V prípade, že generovanie kódu bude náhodné, je tento prístup schopný efektívne potlačiť SPIT hlavne od automatizovaných robotov. Tento prístup bude samozrejme efektívny do doby, pokiaľ robot nebude schopný interaktívne rozoznať hlasové vzory. To by však spôsobilo zvýšenie nákladov pre spamera Greylisty Graylist je typ rozmazaného white alebo blacklistu. Ich použitie závisí od okolností hovoru. V prípade, že sa účastník nachádza v grayliste, pri prvom pokuse o nadviazanie spojenia bude automaticky vygenerovaný obsadzovací tón. Volanému nezazvoní telefón. Pokiaľ sa bude pokus o hovor vzápätí opakovať, je pravdepodobné, že sa jedná o skutočného človeka, ktorý má záujem o hovor. Samozrejme, podľa týchto okolností je možné zmeniť správanie robota, avšak prinajmenšom dosiahneme zníženie počtu nevyžiadaných hovorov za určitý čas Simultánna konverzácia Tento prístup je podobný ako v prípade interakcie s hlasovým menu. Rozdiel je v tom, že od volajúceho sa vyžaduje prezentovať sa hlasovo. Na základe automatickej hlasovej výzvy volajúci musí odpovedať. Potom sa odpoveď vyhodnotí, a na základe 25

27 intenzity hlasu, sfarbenia a pod. sa rozhodne, či ide o prirodzený ľudský hlas, alebo nahrávku. Tento prístup značne znižuje efektívnosť spamera. Na druhej strane zvyšuje celkové náklady na volanie, pretože nadviazanie spojenia je časovo zložitejšie. 3.2 Vishing Ďalšou veľmi nebezpečnou hrozbou, ktorá sa v poslednej dobe objavila v súvislosti s VoIP technológiami, je vishnig. Toto označenie je kombinácia slov voice (hlas) a phising, čo sa v Internetovej terminológii používa na označenie podvodnej web stránky. Vishing je teda hlasovou obdobou webového phisingu. Obidve tieto hrozby sa najčastejšie používajú na získanie diskrétnych informácii od užívateľa, hlavne ohľadom jeho účtov, autentifikačných kódov a pod. Spoločnosti poskytujúce služby, či už finančné alebo iného druhu, čoraz viac používajú na komunikáciu s klientom automatizované hlasové systémy, ktoré sú schopné pomocou pripravených nahrávok viesť klienta, aby vykonal požadovanú operáciu bez zásahu živého operátora. Tento prístup nepochybne znižuje spoločnostiam náklady, na druhej strane dáva nový priestor pre podvodníkov. Zároveň ľudia prirodzene majú väčšiu dôveru pri telefonickom rozhovore, aj keď sa nejedná o živého človeka, ako pri komunikácii cez web. Táto prirodzená dôvera znižuje ich ostražitosť a opatrnosť. Princíp vishingu spočíva v tom, že útočník veľmi realisticky napodobňuje kontaktné centrum inštitúcie a nenápadne získa od klienta požadované informácie. Pre lepšie pochopenie tejto hrozby si ju predstavíme na príklade, ktorý bol už niekoľkokrát použitý v USA v spojení s bankovou inštitúciou. V prvom kroku klient bankovej inštitúcie realizuje platbu svojou platobnou kartou prostredníctvom internetového obchodu. Pri tejto operácii uvedie číslo svojej platobnej karty a ový kontakt. Tieto údaje sa však dostanú do rúk útočníkovi, ktorý monitoruje veľké množstvo podobných obchodov. Následne na to útočník zistí na základe čísla platobnej karty, ktorá banka ju vydala a pošle klientovi falošný v mene banky. obsahuje správu, v ktorej je klient upozornený na problém s platobnou kartou a vyzvaný, aby 26

28 kontaktoval klientske centrum. Samozrejme telefónne číslo je iné ako v skutočnosti používa banka, ale líši sa len minimálne. Klient v domnení, že je v kontakte s klientskym centrom banky, a že práve rieši problém so svojou platobnou kartou, vydá útočníkovi citlivé informácie napr. PIN, dátum narodenia, a pod. Útočník má potom všetky potrebné informácie, aby sa dokázal takto obohatiť. Základnou obranou proti takémuto typu nebezpečenstva je vysoká miera obozretnosti pri každej neosobnej komunikácii. V tomto prípade je na mieste vždy používať kontaktné informácie, ktoré má klient k dispozícii priamo od inštitúcie, napr. sú uvedené na platobnej karte. 3.3 Nedostupnosť služby (DoS Denial of Service) Ide o jednu z najnebezpečnejších hrozieb, ktoré sú spojené s používaním Internetu, pretože cieľom takéhoto útoku je kompletne vyradiť službu a znemožniť jej používanie. Komplexný výpadok VoIP služby pre firmu, alebo providera môže mať za následok veľké ekonomické straty. Útočníci najčastejšie používajú na dosiahnutie cieľa tzv. flooding, alebo zahltenie. Vtedy je na server zasielaných veľké množstvo neopodstatnených požiadaviek. V prípade VoIP a použitia SIP protokolu môže ísť o zasielanie správ INVITE. Keďže server je zaneprázdnený spracovávaním neopodstatnených požiadaviek, nedostávajú sa k spracovaniu reálne požiadavky a služba sa stáva nedostupnou. Dochádza k maximálnemu vyťaženiu servera až k jeho úplnému zlyhaniu. Pri VoIP komunikácii je takýto útok obzvlášť nebezpečný, nakoľko užívatelia okamžite pocítia zníženie kvality poskytovaných služieb. Na takýto typ útoku je však potrebné mať k dispozícii množstvo počítačov, ktoré budú odosielať požiadavky na server. A práve v tomto momente sa prejavuje celková počítačová gramotnosť užívateľov Internetu. Väčšinou sú práve bežní užívatelia a ich počítače súčasťou takéhoto útoku, samozrejme bez toho, aby si boli toho vedomí. Pokiaľ užívateľ podcení bezpečnosť svojho počítača, ľahko sa mu môže stať, že sa k nemu dostane neželaný kód. Najčastejšie je to trójsky kôň, alebo vírus. Tento kód sa nijakým spôsobom neprejavuje, takže bežný užívateľ si nevšimne jeho prítomnosť. Neželaný kód čaká na príkaz od svojho majiteľa. Takto infikovaný počítač sa nazýva zombie. V súčasnosti sa predpokladá, že až 7% všetkých počítačov (cca. 7 27

29 miliónov) pripojených do Internetu sú infikované takýmto nežiaducim kódom a môžu byť použité na DoS útok. Obrana proti tomuto typu útoku je pomerne zložitá. V zásade sa dá rozdeliť na dve časti. Prvou časťou je ochrana samotných zdrojov DoS útoku, čiže bežných počítačov užívateľov Internetu. Je preto veľmi dôležité dbať na zodpovedajúce zabezpečenie, mať nainštalovaný firewall, antivírus a udržiavať ich stále aktuálne. Druhou časťou ochrany sú úkony, ktoré môže vykonať samotný správca VoIP servera. Taktiež je nevyhnutné mať nainštalovaný aktuálny antivírus a správne nakonfigurovaný firewall s obmedzeniami prichádzajúceho zaťaženia. V prípade firemnej VoIP komunikačnej siete je dôležité, aby vnútorná sieť bola zabezpečená a nebola taktiež pôvodcom DoS útoku, aby v prípade útoku z vonka mohla byť zabezpečená komunikácia z vnútra firmy. Vhodnou obranou môže byť aj použitie špeciálnych softvérov, ktoré dokážu odhaliť útočníka resp. zdroje útoku v rámci vnútornej siete. Jedným z takých softvérov je aj open source projekt SNORT. Tento softvér monitoruje všetku prevádzku v rámci vnútornej siete a pokiaľ zistí nejakú podozrivú aktivitu začne na ňu upozorňovať, prípadne podnikne iné kroky na eliminovanie vplyvu na sieť. Ďalšími možnosťami, ako znižovať riziko DoS útoku, je vhodne zvolená a implementovaná celková sieťová štruktúra. Samotné sieťové prvky v prípade útoku môžu obmedzovať prichádzajúcu prevádzku a tým znížiť zaťaženie servera a zabrániť úplnému výpadku služby. Zároveň je odporúčané pre VoIP služby vytvoriť samostatnú virtuálnu sieť, cez ktorú sa prenáša iba hlas a signalizácia, oddelene od ostatnej dátovej prevádzky. Veľmi vhodným spôsobom obrany voči DoS útoku je kompletné šifrovanie signalizácie, kedy server vyhodnocuje iba šifrované, teda dôveryhodné správy a ostatné automaticky zahadzuje a nezoberá sa nimi. 3.4 Prelomenie registrácie Nasledujúce dve bezpečnostné hrozby môžeme považovať za potenciálne najčastejšie práve preto, že sú ľahko realizovateľné aj pre menej skúseného útočníka. Tieto bezpečnostné hrozby vyplývajú hlavne z nedostatočného zabezpečenia samotného SIP protokolu. Prvú hrozbu môžeme označiť ako neoprávnené získanie prihlasovacích údajov a následných osobných informácií z toho vyplývajúcich. Pokiaľ sa útočníkovi podarí 28

30 získať tieto informácie, môže ich využiť viacerými spôsobmi. Napríklad ich môže použiť na využívanie služieb, ktoré má klient predplatené, a tým mu spôsobiť finančnú ujmu. Alebo môže takéto užívateľské konto zneužiť na šírenie vishingu a pod. Nasledujúca ukážka správy predstavuje odoslanie registračných informácií od klienta k serveru v správe REGISTER. Celý systém je bez akéhokoľvek dodatočného zabezpečenia. Ukážka správy REGISTER REGISTER sip: SIP/2.0 Via: SIP/2.0/UDP :62572;branch=z9hG4bK-d87543-d5469f666c7ba00a- 1--d87543-;rport Max-Forwards: 70 Contact: <sip:karol@ :62572;rinstance=da30d c141> To: "Karol"<sip:karol@ > From: "Karol"<sip:karol@ >;tag=c919472b Call-ID: YzM4ZTNhYjk4MmMxNGVkNmZjNzdkODZlNGQzZjU1YjI. CSeq: 1 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: eyebeam release 1011w stamp Content-Length: 0 Ako môžeme vidieť z ukážky správy, útočník má k dispozícii všetky potrebné informácie o užívateľovi. S týmito údajmi sa môže vydávať za užívateľa, zneužiť jeho služby, prípadne následne odpočúvať jeho hovory. Táto bezpečnostná hrozba sa dá úspešne eliminovať použitím SIPS (SIP cez TLS). Tejto téme sa podrobne venujeme v kapitole Odpočúvanie Odpočúvanie je jednou z najviac diskutovaných tém spojených s prenosom hlasu vôbec. Príchodom VoIP sa táto téma dostala ešte viac do popredia záujmu. Odpočúvanie je často diskutované aj v spojení s klasickými PSTN alebo mobilnými sieťami. V nasledujúcej časti popíšeme možný spôsob odpočúvania VoIP hovoru. Odpočúvanie vo VoIP sieťach je mierne odlišné od odpočúvania v klasických dátových sieťach. Hlavným rozdielom je, že útočník musí zachytiť zvlášť signalizáciu a k nej prislúchajúci mediálny tok dát, ktorý obsahuje samotný hovor. Signalizácia v našom prípade je realizovaná pomocou SIP a mediálny prenos pomocou RTP protokolu. 29

31 3.5.1 Pasívne odpočúvanie V prípade, že je hovor realizovaný prostredníctvom siete, ktorá obsahuje sieťové elementy podporujúce iba broadcastový prenos, teda všetky správy odoslané v rámci jedného sieťového elementu sú doručené ku všetkým užívateľom, je úloha útočníka veľmi jednoduchá. Stačí mu odchytiť signalizačnú správu, ktorá obsahuje nastavenia pre mediálny prenos a následne odchytiť všetky správy prislúchajúce tomuto prenosu. Po dekódovaní prenosu má útočník k dispozícii kompletnú nahrávku telefonického hovoru. Takémuto postupu sa hovorí pasívne odpočúvanie. Obr. 2 Schematické znázornenie pozície útočníka pri pasívnom odpočúvaní V nasledujúcej časti správy INVITE vidíme všetky informácie o nastavení mediálneho toku, potrebné k zachyteniu a následnému dekódovaniu prenášaného rozhovoru. Časť zachytenej správy INVITE: INVITE sip:tinka@ SIP/2.0 Record-Route: <sip: ;lr=on> Via: SIP/2.0/UDP ;branch=z9hG4bK2a13.ca0e9ba3.0 Via: SIP/2.0/UDP :62572;branch=z9hG4bK-d87543-df7eda2a3c080e3f- 1--d87543-;rport=62572 Max-Forwards: 69 Contact: <sip:karol@ :62572> To: "tinka@ "<sip:tinka@ > From: "Karol"<sip:karol@ >;tag=a Call-ID: OGQyMjc2NGFhN2E0ZGQwNzJlMjU0OTY4NDRjNmVmYTU. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: eyebeam release 1011w stamp Content-Length: 469 P-hint: outbound v=0 o=- 0 2 IN IP s=counterpath eyebeam 1.5 c=in IP

32 t=0 0 m=audio RTP/AVP a=alt:1 1 : z/znswep wpx1rrnt a=fmtp:18 annexb=yes a=fmtp: a=rtpmap:107 BV32/16000 a=rtpmap:100 SPEEX/16000 a=rtpmap:106 SPEEX-FEC/16000 a=rtpmap:105 SPEEX-FEC/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv a=x-rtp-session-id:2c0bd20aed1d47169f1d5d372b Pokiaľ útočník pozná IP adresy komunikujúcich strán a čísla portov, vie jednoznačne určiť, ktorý RTP tok potrebuje zachytiť. V ukážke RTP správy vidíme, že útočník má k dispozícii aj sekvenčné číslo správy, čím dokáže správy aj správne usporiadať a tým minimalizovať poškodenie odchytených dát. Časť RTP dátovej správy obsahujúcej samotný prenos hovoru: Real-Time Transport Protocol [Stream setup by SDP (frame 6)] = Version: RFC 1889 Version (2) = Padding: False = Extension: False = Contributing source identifiers count: = Marker: False Payload type: BV32 (107) Sequence number: 6033 [Extended sequence number: 71569] Timestamp: Synchronization Source identifier: 0x781346f5 ( ) Payload: 68CA4A912A5E1902D E68672F4BA3474D Aktívne odpočúvanie (man in the middle) Použitie sieťových elementov podporujúcich iba broadcastový prenos je dnes už viacmenej výnimkou. Väčšina sieťových elementov podporuje ARP protokol a priame smerovanie podľa MAC adresy. Ale aj v tomto prípade má útočník možnosť odpočúvať hovor. Princíp smerovania pomocou MAC adries je založený na získaní MAC adresy adresáta, nakoľko väčšinou poznáme iba IP adresy adresátov. K tomu sa používa ARP protokol. Zariadenie najskôr odošle ARP správu, ktorou sa všetkých v danom sieťovom elemente opýta, kto má požadovanú IP adresu. Zariadenie s požadovanou IP adresou odpovedá ARP správou, ktorá obsahuje jeho MAC adresu. Zariadenie, 31

33 ktoré chce komunikovať, tým získa potrebné údaje a môže správu odoslať priamo adresátovi. ARP poisoning je založený na tom, že útočník pozmení ARP záznamy zariadenia, ktoré správu odosiela, a tým docieli, že správa je doručená k nemu. Útočník najskôr odošle falošnú ARP odpoveď, v ktorej tvrdí, že on je zariadenie s požadovanou IP adresou a podsunie svoju MAC adresu. Keďže odosielateľ nemá možnosť overiť pravosť ARP správy, zmení svoj ARP záznam a všetky dáta odosiela na novú MAC adresu, teda k útočníkovi. Aby sa útočník neprezradil, odosiela správy ďalej k skutočnému adresátovi, ktorému obdobným spôsobom zmenil ARP záznamy. Keďže má všetky správy k dispozícii, môže ich ľubovoľne pozmeňovať, odpočúvať a pod. Tento postup sa označuje ako aktívne odpočúvanie alebo man in the middle útok. Obr. 3 Schematické znázornenie pozície útočníka pri aktívnom odpočúvaní Riešením týchto bezpečnostných hrozieb je taktiež dodatočné zabezpečenie signalizácie (SIPS), ako aj samotného mediálneho prenosu (SRTP). Oba tieto prístupy sú bližšie rozobraté v nasledujúcej kapitole. 32

34 4. Spôsoby zabezpečenia 4.1 Message digest authentication Toto zabezpečenie je dnes požadované od všetkých užívateľských softvérov. Poskytuje základný spôsob zabezpečenia medzi SIP proxy serverom a užívateľom. Výsledkom tohto zabezpečenia je zašifrovanie prihlasovacieho hesla pomocou MD5 alebo podobného algoritmu. Týmto spôsobom sa dá zabrániť prelomeniu registrácie. Avšak táto technika je efektívna iba v prípade silného hesla, nakoľko dnes existuje už niekoľko techník, ktorými sa dajú tieto algoritmy prelomiť pomocou slovníkových prístupov. Toto zabezpečenie však nijako neuchráni pred odpočúvaním a taktiež môže byť táto technika zvrátená útokom man in the middle. V nasledujúcej ukážke správy REGISTER vidíme použitie message digest authentication a zašifrovanie prihlasovacieho hesla pomocou MD5 algoritmu. Časť správy REGISTER: REGISTER sip: SIP/2.0 Via: SIP/2.0/UDP :60546;branch=z9hG4bK-d b c53-1--d87543-;rport Max-Forwards: 70 Contact: <sip:tinka@ :60546;rinstance=a6c a812> To: "Martinka"<sip:tinka@ > From: "Martinka"<sip:tinka@ >;tag=d Call-ID: MjNjOGM5Nzk2YmM4NmE5NGQzN2Y1M2M4YmZmYWM1NmE. CSeq: 2 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: eyebeam release 1011w stamp Authorization: Digest username="tinka",realm=" ",nonce="481ee254a34af057c6b49a2969a9f19 0b1b071e0",uri="sip: ",response="7fa6cc0af0d99c5d5e2921d90fe62598 ",algorithm=md5 Content-Length: S/MIME S/MIME (Secure / Multipurpose Internet Mail Extensions) je štandard, ktorý bol vytvorený pre zabezpečenie ovej komunikácie. S/MIME poskytuje šifrovanie pre textové časti správ, čo znemožňuje útočníkovi odhaliť šifrovanú časť správy. Princíp tejto technológie je založený na asymetrickom šifrovaní. Teda každý užívateľ, ktorý chce S/MIME využívať, musí mať vlastný digitálny certifikát s verejným 33

35 a privátnym kľúčom. Tento certifikát by mal byť vydaný certifikačnou autoritou, u ktorej je možné overiť hodnovernosť certifikátu. Takýto certifikát obsahuje identifikátory užívateľa. V našom prípade je to SIP URI alebo SIPS URI, ová adresa a pod. Verejný kľúč musí byť umiestnený na všeobecne dostupnom mieste v tzv. virtuálnej úschovni kľúčov. Pokiaľ sa odosielateľ správy rozhodne poslať správu šifrovanú S/MIME, musí najskôr zistiť verejný kľúč prijímateľa a na základe tohto kľúča zašifrovať správu. Po doručení správy jedine prijímateľ je schopný pomocou privátneho kľúča dešifrovať správu. V prípade použitia tejto techniky v spojení so SIP protokolom je možné šifrovať len niektoré časti SIP správy. Napríklad SDP časť, ktorá nie je potrebná pre smerovanie samotnej správy cez sieť, ale je dôležitá pre nadviazanie samotného spojenia. Touto technikou sa dá zabrániť získaniu údajov o vytváranom spojení a s použitím SRTP protokolu zabrániť odpočúvaniu. Tento prístup má však veľkú nevýhodu, nakoľko je potrebné vytvárať a udržiavať databázu verejných kľúčov. Taktiež je potrebné, aby každý užívateľský softvér podporoval množstvo funkcií spojených s výmenou certifikátov. Práve kvôli týmto komplikáciám sa tento spôsob zabezpečenia doteraz veľmi nepresadil. 4.3 SIP over TLS (Transport Layer Security) TLS bolo pôvodne vyvinuté pre potreby použitia s HTTP protokolom. Keďže SIP je taktiež textovo orientovaný protokol podobne ako HTTP, je možné TLS použiť aj v prípade SIP. TLS slúži na vytvorenie šifrovaného komunikačného kanála medzi dvoma komunikujúcimi bodmi. Je to efektívny nástroj, ktorý dokáže zabrániť, alebo aspoň značne skomplikovať útočníkovi pokus o narušenie bezpečnosti. Efektívne dokáže zabrániť odpočúvaniu hovoru, prelomeniu registrácie a ďalším bezpečnostným hrozbám. Ako bolo už uvedené, TLS je spojovo orientovaný proces, takže je výhradne používaný s TCP protokolom. Zabezpečenie SIP pomocou TLS môžeme rozdeliť do dvoch úrovní. Prvou úrovňou je zabezpečenie bezpečného spojenia medzi dvoma SIP proxy servermi. V tomto prípade predpokladáme, že v rámci našej vlastnej domény nie je hrozba útoku a preto v nej komunikácia prebieha nešifrovane. Komunikácia je teda šifrovaná len na úrovni SIP 34

36 proxy serverov, kedy táto komunikácia prechádza cez otvorenú sieť, kde je zvýšená možnosť útoku. Túto situáciu znázorňuje obrázok 4. Obr. 4 Schematické znázornenie zabezpečeného spojenia cez vonkajšiu sieť Týmto spôsobom zabezpečenia však neochránime sieť pred útokom z vnútra. Teda v prípade, že útočník bude vo vnútri našej vlastnej domény, môže vykonať útok. Aby sme zabránili aj tomuto prípadu, je možné rozšíriť zabezpečenie aj na komunikáciu medzi užívateľom a SIP proxy serverom. Na takéto zabezpečenie je potrebné, aby technológiu TLS podporoval aj užívateľský softvér Schéma SIPS URI SIPS URI využíva rovnakú syntax ako pri SIP. Samozrejme rozdielom je nahradenie sip výrazom sips. URI je používané ako textový identifikátor užívateľa, ktorý je používaný v SIP správach. Pokiaľ je v identifikátore URI použitá SIPS schéma, znamená to, že každý krok, ktorý absolvuje prenášaná správa od odosielateľa až k cieľovej doméne, musí byť zabezpečený cez TLS. Akonáhle správa dosiahne cieľovú doménu, záleží od lokálneho nastavenia, či správa bude smerovaná cez zabezpečené spojenie, alebo nie. Pokiaľ príjemca vidí, že v správe je použitá SIPS schéma, môže si byť istý, že celá trasa od odosielateľa až k cieľovej doméne je zabezpečená. Príklad SIPS URI: sips:karol@krasnan.eu;transport=tcp 35

37 4.3.2 Princíp fungovania TLS Pred vytvorením zabezpečeného spojenia je potrebné, aby sa klient a server (v našom prípade to môžu byť dva proxy SIP servery) dohodli na parametroch spojenia. Hlavným parametrom je dohodnutie šifrovacích algoritmov a kľúčov, pomocou ktorých sa bude šifrovanie uskutočňovať. Tento proces zostavenia zabezpečeného spojenia sa nazýva handshake procedure. Počas tejto procedúry je používané asymetrické šifrovanie. Znamená to, že šifrovať správu môže hocikto použitím verejného kľúča, ale dešifrovať správu je schopný len prijímateľ na základe súkromného kľúča. Handshake proces začína odoslaním požiadavky o šifrované spojenie na server. Klient v tejto správe uvádza zoznam všetkých podporovaných šifrovacích algoritmov a hešovacích funkcií. Server si zo zoznamu vyberie najsilnejší šifrovací algoritmus a spoločne s digitálnym certifikátom ho pošle naspäť klientovi. Digitálny certifikát by mal obsahovať predovšetkým názov servera a meno dôveryhodnej certifikačnej autority, ktorá certifikát vydala. Digitálny certifikát taktiež obsahuje aj verejný kľúč servera. Taktiež klient môže mať svoj digitálny certifikát a môže sa ním preukázať serveru. Následne klient vygeneruje náhodné číslo, ide o 28B výstup z náhodného generátora, čo tvorí 2 8*28 = 2, možností, ktoré zašifruje použitím verejného kľúča od servera. Dešifrovať toto číslo je schopný jedine server na základe súkromného kľúča. Pomocou predtým dohodnutého algoritmu a s použitím náhodne vygenerovaného kľúča obe strany získajú nový šifrovací kľúč, pomocou ktorého je šifrovaná všetka ďalšia komunikácia. V ďalšej komunikácii sa teda používa symetrické šifrovanie. 36

38 Obr. 5 Schematické znázornenie priebehu zostavovania šifrovaného spojenia cez TLS 4.4 SRTP Doteraz sme rozoberali možnosti zabezpečenia SIP signalizácie. Na realizáciu bezpečného hovoru však potrebujeme zabezpečiť aj samotný mediálny prenos (zvuk, video). V súčasnosti sa najčastejšie na prenos mediálneho toku používajú RTP správy. SRTP (Secure Real Time Protocol) je profil pre RTP protokol, ktorý poskytuje zabezpečenie, integritu a autentifikáciu mediálneho prenosu cez RTP. Pri vytváraní SRTP sa dbalo najmä na adekvátne zabezpečenie mediálneho prenosu, ale taktiež na čo najnižšie dodatočné zaťaženie hardvéru a minimálne zvýšenie šírky prenosového pásma. Nezvyšovanie požiadaviek na prenosové pásmo je dôležité hlavne pre zachovanie použiteľnosti tohto protokolu v prostredí bezdrôtových sietí. Pred samotným prenosom je nevyhnutné, aby sa komunikujúce zariadenia dohodli na používaní šifrovacieho algoritmu a navzájom si vymenili šifrovacie kľúče. Tento krok sa môže uskutočniť viacerými spôsobmi. SRTP podporuje niekoľko algoritmov na výmenu šifrovacích kľúčov napr. MIKEY, ZRTP a pod. Taktiež môže byť použitý protokol SIP, samozrejme s adekvátnym zabezpečením (S/MIME, TLS). Všetky tieto postupy majú spoločný princíp, a to prostredníctvom zabezpečenej cesty doručiť ku komunikujúcim stranám šifrovacie kľúče. Následne na to môže začať samotný prenos. Po zachytení mediálnych dát zo vstupu (mikrofón alebo kamera), sú tieto dáta zakódované použitím zodpovedajúceho kodeku. Zakódované dáta sú symetricky zašifrované predtým dohodnutým 37

39 algoritmom a šifrovacím kľúčom. Štandardne je používaný AES (Advanced Encrytpion Standard) šifrovací algoritmus, hlavne kvôli jeho rýchlosti a vysokej bezpečnosti. Bežne sa používa 128 bitové dĺžka šifrovacieho kľúča. Takto zašifrované mediálne dáta sú vložené do štandardnej RTP správy ako jej obsah. Tento postup však neposkytuje zabezpečenie integrity celej RTP správy, keďže útočník je potenciálne schopný meniť RTP hlavičku a tým falšovať posielané mediálne dáta. Preto SRTP štandard umožňuje zabezpečenie celej RTP správy, vrátane hlavičky. Na tento účel sa používa hešovací HMAC-SHA1 algoritmus. Výsledok tohto postupu je umiestnený do tela SRTP správy, ktorý v hlavičke obsahuje nevyhnutné údaje na smerovanie a iné úkony spojené s transportom mediálnych dát. 4.5 IPsec Ďalšou možnosťou zabezpečenia komunikácie je balíček protokolov a zabezpečovacích funkcií pod názvom IPsec (Internet Protocol Security). Tento protokol pracuje na 3. vrstve RM OSI, čo mu dáva značnú výhodu napr. oproti TLS. Poskytuje totiž zabezpečenie tak pre TCP ako aj pre UDP protokol, teda môže byť použitý rovnako pre signalizáciu ako aj pre zabezpečenie toku samotných mediálnych dát. Dôležitou vlastnosťou je, že nevyžaduje podporu od aplikácií, nakoľko je implementovaný priamo v operačnom systéme. Pôvodne bol tento protokol vytvorený pre použitie s IPv6, v súčasnosti exituje aj podpora pre IPv4. Keďže je požadované, aby tento protokol podporoval samotný operačný systém, je nevyhnutné ho implementovať do samotného jadra systému. Momentálne podporu tomuto protokolu poskytujú napr. systémy Linux 2.6, NetBSD a iné. Operačný systém Windows prináša implementovanú podporu IPSec priamo v jadre systému od verzie vista resp. server

40 5. Zabezpečenie VoIP komunikácie pri použití OpenSER OpenSER je robustný SIP proxy server modulárneho charakteru, ktorý umožňuje realizáciu množstva prídavných služieb či už pre účastníkov, alebo správcu celého systému. OpenSER je schopný okamžite po inštalácii za použitia predpripraveného konfiguračného súboru realizovať SIP spojenia. Avšak v tejto základnej konfigurácii nie je zahrnuté žiadne zabezpečenie komunikácie a preto je takéto nasadenie možné odporúčať len v podmienkach malej privátnej siete. V nasledujúcej časti popíšeme základné moduly, ktoré je potrebné použiť a nakonfigurovať, aby OpenSER spĺňal bezpečnostné požiadavky. 5.1 Modul AUTH Tento modul poskytuje základné funkcie potrebné pre už opísanú metódu zabezpečenia message digest authentication. Taktiež je potrebné vhodným spôsobom upraviť konfiguračný skript. Po týchto úpravách bude každý účastník, ktorý sa bude snažiť použiť proxy server, vyzvaný na autentifikáciu a zaslanie užívateľského mena a hesla. Pokiaľ účastník zašle správne údaje, proxy server ho zaregistruje a bude mu umožnená komunikácia. Tomu samozrejme predchádza potreba vytvorenia užívateľského účtu na samotnom proxy serveri. Pokiaľ by proxy server nepoužíval na uchovávanie údajov externý databázový systém napr. MySQL, bolo by potrebné po každom spustení proxy servera zadať všetky užívateľské účty nanovo. Preto sa vo väčšine prípadov používa aj externý databázový systém, do ktorého sú všetky údaje o užívateľských účtoch uložené. Tento modul poskytuje niekoľko parametrov a funkcií potrebných pre jeho konfiguráciu a použitie. Ich kompletný zoznam aj s popisom je obsahom prílohy A. 5.2 Podpora TLS Popísaný modul AUTH poskytuje iba základné zabezpečenie, a to zašifrovanie prihlasovacích údajov. Ako sme však uviedli vyššie, v dnešných podmienkach môžeme takéto zabezpečenie len ťažko považovať za dostatočné. Aby OpenSER mohol byť považovaný za skutočne bezpečný systém, prináša možnosť kompletnej šifrovanej komunikácie medzi servermi samotnými, ako aj serverom a užívateľským agentom. 39

41 TLS v systéme OpenSER nie je modulového charakteru. Je priamo súčasťou jadra samotného softvéru, preto je potrebné od začiatku inštalácie softvéru myslieť na túto skutočnosť. Jednotlivé kroky inštalácie sú popísané v praktickej časti tejto práce. TLS taktiež obsahuje niekoľko parametrov a funkcií potrebných pre jeho nastavenie a fungovanie. Ich kompletný zoznam aj s popisom sú obsahom prílohy B. 40

42 PRAKTICKÁ ČASŤ 41

43 6. Počiatočná konfigurácia Úlohou praktickej časti diplomovej práce bolo implementovať vybrané spôsoby zabezpečenia VoIP komunikácie medzi dvoma VoIP proxy servermi, a taktiež medzi serverom a užívateľským klientom pri použití OpenSER. Samotná realizácia sa skladala z viacerých krokov, ktoré postupne na seba nadväzovali a predstavovali rôzne úrovne zabezpečenia komunikácie. V nasledujúcej časti si priblížime jednotlivé kroky realizácie, ukážeme potrebné nastavenia použitých softvérových súčastí a zhodnotíme dosiahnuté výsledky z hľadiska bezpečnosti komunikácie. Na splnenie zadanej úlohy bolo potrebné vytvoriť vhodné prostredie, ktoré obsahuje dva VoIP proxy servery s pripojenými užívateľmi. Tento cieľ bol dosiahnutý vytvorením virtuálnej siete, ktorá sa skladala zo štyroch zariadení - dvoch serverov a dvoch klientov. Takouto zostavou sme dosiahli simulovanie reálnych podmienok, kedy ku každému proxy serveru sú pripojení jednotliví užívatelia v rámci vnútornej siete a komunikácia medzi servermi je realizovaná cez vonkajšiu sieť, napr. Internet. Nasledujúci obrázok približuje použitú topológiu virtuálnej siete. Obr. 6 Schéma virtuálnej siete použitej pri realizácii praktickej časti práce 6.1 Použité softvérové prostriedky Na vytvorenie virtuálnych počítačov sme použili softvér VMware Workstation ACE Edition. Tento softvér nám umožnil vytvorenie všetkých potrebných zariadení. Následne sme na jednotlivé zariadenia nainštalovali operačný systém s potrebným softvérovým vybavením. Pre potreby staníc užívateľských klientov sme zvolili najrozšírenejší operačný systém OS Windows XP. Potrebné bolo nainštalovať aj 42

44 vhodný VoIP softvérový telefón. Našou podmienkou bolo, aby tento softvér podporoval nielen základné prvky zabezpečenia, ale aby umožňoval aj úplné šifrovanie komunikácie. Túto podmienku bolo pomerne ťažké splniť, nakoľko momentálne existuje len veľmi málo programov, ktoré túto podmienku spĺňajú a väčšinou sú spoplatnené, čo môže veľa bežných užívateľov odradiť od ich používania. Nakoniec sme sa rozhodli pre použitie softvérového telefónu EyeBeam od spoločnosti CounterPath. Pre potreby nasadenia OpenSER bol použitý operačný systém Debian v najnovšej stabilnej verzii SID. Pri samotnej inštalácii OpenSER bolo potrebné hneď na začiatku počítať s tým, že budeme chcieť využívať aj funkčnosť, ktorú ponúka TLS, nakoľko priamo pri kompilácii softvéru je potrebné podľa toho upraviť konfiguračný súbor kompilácie. Nami používaný OpenSER bol v najnovšej verzii označovaný TLS. 6.2 Testovanie základnej konfigurácie Prvým momentom, kedy sme sa rozhodli testovať bezpečnosť komunikácie, bolo hneď po nainštalovaní OpenSER. Použili sme predpripravený konfiguračný súbor, ktorý nevyužíva žiadne funkcie AUTH modulu ani TLS. Chceli sme zistiť, ako bude zabezpečená komunikácia bez ďalšieho dodatočného softvéru a nastavení Použitý konfiguračný súbor Teraz si ukážeme konfiguračný súbor OpenSER, ktorý je k dispozícii priamo po nainštalovaní softvéru a stručne si opíšeme jeho jednotlivé časti. Oba OpenSER mali rovnaký konfiguračný súbor. ####### Globálne Parametre ######### debug=3 Parametre nemajú na fungovanie log_stderror=no OpenSER podstatný vplyv. Slúžia na log_facility=log_local0 nastavenie debug režimu. fork=yes children=4 disable_tls = yes Keďže máme OpenSER už 43

45 port=5060 predpripravený na použitie TLS, avšak zatiaľ ho nemáme vhodne nakonfigurovaný, musíme použitie TLS vypnúť. Nastavenie portu, na ktorom OpenSER prijíma správy, implicitne bude prijímať komunikáciu na všetkých rozhraniach. ####### Sekcia Modulov ######## mpath="/usr/lib/openser/modules/" Cesta k jednotlivým modulom. loadmodule "sl.so" Zavedenie jednotlivých funkčných loadmodule "tm.so" modulov. loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" Moduly usrloc a registrar poskytujú loadmodule "registrar.so" funkcie potrebné na správu zoznamu loadmodule "textops.so" zaregistrovaných užívateľov. loadmodule "mi_fifo.so" loadmodule "uri_db.so" loadmodule "uri.so" loadmodule "xlog.so" loadmodule "acc.so" # Nastavenie parametrov jednotlivých modulov modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") modparam("rr", "enable_full_lr", 1) modparam("rr", "append_fromtag", 0) modparam("registrar", "method_filtering", 1) modparam("uri_db", "use_uri_table", 0) modparam("uri_db", "db_url", "") modparam("acc", "early_media", 1) modparam("acc", "report_ack", 1) modparam("acc", "report_cancels", 1) modparam("acc", "detect_direction", 0) modparam("acc", "failed_transaction_flag", 3) modparam("acc", "log_flag", 1) modparam("acc", "log_missed_flag", 2) modparam("acc", "db_flag", 1) modparam("acc", "db_missed_flag", 2) modparam("usrloc", "db_mode", 0) Mód 0 znamená, že informácie o užívateľoch nebudú overované v databáze. ####### Smerovacia Logika ######## route{ if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","too Many Hops"); exit; Pri prekročení maximálneho počtu skokov je poslané chybové hlásenie. 44

46 } if (has_totag()) { } if (loose_route()) { Pokiaľ správa v poli TO obsahuje TAG a pokiaľ obsahuje hlavičku if (is_method("bye")) { ROUTE a jedná sa o správu BYE setflag(1); nastavia sa potrebné príznaky. setflag(3); } route(1); Pokiaľ sa nejedná o správu BYE } smerovacím postupom (1). else { Ak správa neobsahuje ROUTE if ( is_method("ack") ) { a jedná sa o správu ACK if ( t_check_trans() ) { t_relay(); nasmeruje sa správa k adresátovi exit; uvedenému v URI správy. } else { exit; } } sl_send_reply("404","not here"); Pokiaľ správa neobsahuje ROUTE a nie je typu ACK alebo BYE, odošle sa chybová správa o nemožnosti smerovania. } exit; if (is_method("cancel")) Pokiaľ je správa typu CANCEL je { nasmerovaná k adresátovi if (t_check_trans()) uvedenému v URI správy. t_relay(); exit; } if (!is_method("register MESSAGE")) Pokiaľ správa nie je typu record_route(); REGISTER je do nej pridaná hlavička ROUTE potrebná pre ďalšie smerovanie. if (is_method("invite")) { Pokiaľ je správa typu INVITE setflag(1); nastaví sa potrebný príznak. } if (!uri==myself) Pokiaľ správa je určená na { smerovanie mimo vlastnej 45

47 } append_hf("p-hint: outbound\r\n"); domény je označená a ďalej route(1); smerovaná postupom (1). if (is_method("publish")) { sl_send_reply("503", "Service Unavailable"); exit; Pokiaľ je správa typu PUBLISH je odoslaná chybová správa o nedostupnosti služby. } if (is_method("register")) Pokiaľ je správa typu REGISTER { tak sa záznam o užívateľovi uloží if (!save("location")) do zoznamu prihlásených sl_reply_error(); užívateľov. Ak sa to nepodarí je exit; odoslaná chybová správa. } if ($ru==null) { sl_send_reply("484","address Incomplete"); exit; Pokiaľ správa neobsahuje kompletnú informáciu o adresátovi je odoslaná chybová správa. } if (!lookup("location")) { Z tela správy vyextrahuje switch ($retcode) { informáciu o požadovanom case -1: užívateľovi a pokúsi sa ho nájsť case -3: v databáze užívateľov. Pokiaľ sa t_newtran(); to nepodarí je odoslaná chybová t_reply("404", "Not Found"); správa. exit; case -2: sl_send_reply("405", "Method Not Allowed"); exit; } } setflag(2); Pokiaľ je užívateľ nájdený nastaví route(1); sa potrebný príznak a smerovanie } pokračuje ďalej. route[1] { if (is_method("invite")) { Pokiaľ je správa typu INVITE je 46

48 } t_on_branch("2"); t_on_reply("2"); t_on_failure("1"); následne podľa jej príslušnosti k hovoru označená. } if (!t_relay()) { sl_reply_error(); }; exit; Pokiaľ sa smerovanie nepodarí je odoslaná chybová správa. branch_route[2] { Označenie správy podľa xlog("new branch at $ru\n"); predchádzajúceho určenia } príslušnosti k hovoru. onreply_route[2] { xlog("incoming reply\n"); } failure_route[1] { if (t_was_cancelled()) { exit; } } 47

49 6.2.2 Testovacie spojenie Pri takto nakonfigurovanom systéme sme realizovali testovacie spojenie medzi užívateľmi. Nasledujúci obrázok znázorňuje priebeh zostavovania, realizácie a ukončenia spojenia. V obrázku sú číselne znázornené správy, ktoré sme podrobnejšie analyzovali. Obr. 7 Priebeh zostavenia, realizácie a ukončenia testovacie spojenia V prvej fáze spojenia vidíme proces registrácie oboch užívateľských klientov. Celá registrácia pozostáva len zo samotnej správy REGISTER a potvrdenia o registrácii zo strany servera 200 OK. Nenastáva žiadna autentifikácia a teda hocikto sa môže na server prihlásiť a používať jeho služby. Taktiež z ukážky správy vidíme, že obsah nie je nijako šifrovaný a teda všetky údaje o užívateľovi sú prístupné a ľahko zneužiteľné. Ukážka správy REGISTER REGISTER sip: SIP/2.0 Via: SIP/2.0/UDP :62572;branch=z9hG4bK-d87543-d5469f666c7ba00a- 1--d87543-;rport Max-Forwards: 70 Contact: <sip:karol@ :62572;rinstance=da30d c141> To: "Karol"<sip:karol@ > From: "Karol"<sip:karol@ >;tag=c919472b Call-ID: YzM4ZTNhYjk4MmMxNGVkNmZjNzdkODZlNGQzZjU1YjI. CSeq: 1 REGISTER 48

50 Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: eyebeam release 1011w stamp Content-Length: 0 V ďalšej fáze spojenia je medzi servermi prenášaná SIP správa INVITE spolu s SDP časťou, ktorá obsahuje informácie o navrhovanom RTP spojení. Ako môžeme z ukážky správy vidieť, správa taktiež nie je nijako zabezpečená a útočník môže veľmi ľahko získať informácie o použitom protokole, čísla portov, označení RTP relácie a ďalšie informácie, ktoré môžu byť použité napr. pri odpočúvaní. Ukážka správy INVITE INVITE sip:tinka@ SIP/2.0 Record-Route: <sip: ;lr=on> Via: SIP/2.0/UDP ;branch=z9hG4bK2a13.ca0e9ba3.0 Via: SIP/2.0/UDP :62572;branch=z9hG4bK-d87543-df7eda2a3c080e3f- 1--d87543-;rport=62572 Max-Forwards: 69 Contact: <sip:karol@ :62572> To: "tinka@ "<sip:tinka@ > From: "Karol"<sip:karol@ >;tag=a Call-ID: OGQyMjc2NGFhN2E0ZGQwNzJlMjU0OTY4NDRjNmVmYTU. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: eyebeam release 1011w stamp Content-Length: 469 P-hint: outbound v=0 o=- 0 2 IN IP s=counterpath eyebeam 1.5 c=in IP t=0 0 m=audio RTP/AVP a=alt:1 1 : z/znswep wpx1rrnt a=fmtp:18 annexb=yes a=fmtp: a=rtpmap:107 BV32/16000 a=rtpmap:100 SPEEX/16000 a=rtpmap:106 SPEEX-FEC/16000 a=rtpmap:105 SPEEX-FEC/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv a=x-rtp-session-id:2c0bd20aed1d47169f1d5d372b Volaný účastník potvrdzuje akceptáciu hovoru SIP správou 200 OK, ktorá taktiež obsahuje aj SDP časť s navrhovanými parametrami pre prenos samotnej komunikácie. Z ukážky správy môžeme opäť vidieť, že potenciálny útočník má k dispozícii všetky podstatné informácie na realizáciu útoku. 49

51 Ukážka správy 200 OK SIP/ OK Via: SIP/2.0/UDP ;branch=z9hG4bK2a13.4cbddf21.0 Via: SIP/2.0/UDP ;branch=z9hG4bK2a13.ca0e9ba3.0 Via: SIP/2.0/UDP :62572;branch=z9hG4bK-d87543-df7eda2a3c080e3f- 1--d87543-;rport=62572 Record-Route: <sip: ;lr=on> Record-Route: <sip: ;lr> Contact: To: From: Call-ID: OGQyMjc2NGFhN2E0ZGQwNzJlMjU0OTY4NDRjNmVmYTU. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: eyebeam release 1011w stamp Content-Length: 469 v=0 o=- 7 2 IN IP s=counterpath eyebeam 1.5 c=in IP t=0 0 m=audio RTP/AVP a=alt:1 1 : /fxmatbw 8n4toq/K a=fmtp:18 annexb=yes a=fmtp: a=rtpmap:107 BV32/16000 a=rtpmap:100 SPEEX/16000 a=rtpmap:106 SPEEX-FEC/16000 a=rtpmap:105 SPEEX-FEC/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv a=x-rtp-session-id:546359c3ee cc9ae90cf810c45 Následne po dohodnutí parametrov spojenia dochádza k samotnému prenosu komunikácie prostredníctvom RTP protokolu. Z uvedenej ukážky správy je vidieť, že pokiaľ útočník má k dispozícii informácie o označení RTP relácie, čísla portov, z ktorých užívatelia odosielajú/prijímajú dáta, nemá problém celú komunikáciu zachytiť a následne dekódovať. Nakoľko ani samotné dáta vo vnútri RTP správy nie sú nijako zabezpečené. Ukážka RTP správy Real-Time Transport Protocol [Stream setup by SDP (frame 6)] = Version: RFC 1889 Version (2) = Padding: False = Extension: False = Contributing source identifiers count: = Marker: True Payload type: BV32 (107) Sequence number:

52 [Extended sequence number: 71561] Timestamp: Synchronization Source identifier: 0x781346f5 ( ) Payload: FDE A69A69A69A6BAE7967AE9A6996BA7DAC Z uvedenej analýzy jasne vyplýva, že konfigurácia OpenSER hneď po nainštalovaní neponúka žiadne zabezpečenie komunikácie a určite nie je vhodná pre nasadenie v reálnych podmienkach. 51

53 7. Implementácia AUTH modulu Z predchádzajúcej analýzy vyplýva nevyhnutnosť realizovať kroky na zabezpečenie komunikácie. Prvým takýmto krokom je implementácia AUTH modulu. Tento modul poskytuje základné prvky zabezpečenia, akými sú manažovanie vlastnej databázy užívateľov, ktorí môžu využívať služby proxy servera, a s tým spojená nutnosť autentifikácie pri prihlasovaní. 7.1 Potrebné softvérové úpravy Prvým krokom, pokiaľ chceme implementovať tento spôsob zabezpečenia, je inštalácia modulov k jadru OpenSER. Potrebný je samotný modul AUTH, modul MySQL (prípadne modul k databáze Postgres) a modul AUTH_DB. Posledné dva moduly poskytujú nevyhnutné funkcie a parametre, aby systém mohol bez problémov komunikovať a využívať služby databázového systému. Samozrejme je nevyhnutné aj doinštalovanie samotnej databázy a jej konfigurácia. V našom prípade sme realizovali inštaláciu databázového systému MySQL s preddefinovanými parametrami. Ďalším krokom pri implementácii je správna konfigurácia systému OpenSER spolu s databázovým systémom. Najskôr je potrebné nadefinovať parametre nainštalovaného databázového systému. Všetky parametre potrebné pre správne fungovanie OpenSER a databázy sú uvedené v súbore openserctlrc, ktorý sa nachádza na rovnakom mieste ako konfiguračný súbor OpenSER. 7.2 Konfigurácia openserctlrc V našom prípade vyzerala konfigurácia openserctlrc nasledovne: SIP_DOMAIN= Doménový názov nášho OpenSER servera DBENGINE=MYSQL Použitý databázový systém DBHOST=localhost Adresa servera s databázovým systémom DBNAME=openser Názov databázy DBRWUSER=openser Meno užívateľa s právom na čítanie aj zápis do databázy DBRWPW="openserrw" Heslo pre užívateľa s právom na čítanie aj zápis 52

54 DBROUSER=openserro DBROPW=openserro USERCOL="username" HAS_SERWEB="yes" Meno užívateľa s právom na čítanie z databázy Heslo užívateľa s právom na čítanie z databázy Názov stĺpca tabuľky, ktorý obsahuje užívateľské mená Prítomnosť serweb tabuľky V ďalšom je možné nadefinovať ešte množstvo parametrov ovplyvňujúcich AUTH modul. V našom prípade sme ostatné voľby nemenili a použili sme prednastavené hodnoty. Posledným krokom pri implementácii AUTH modulu je spustenie inicializačného skriptu. Skript má za úlohu na základe nadefinovaných parametrov vytvoriť v databázovom systéme potrebnú databázu s tabuľkami a základnými dátami. Inicializačný skript openserdbctl sa nachádza v adresári spolu s ostatnými ovládacími skriptami systému OpenSER, v našom prípade /usr/local/sbin/openserdbctl. Skript spustíme s parametrom create. 7.3 Zmeny konfigurácie OpenSER Po úspešnom vykonaní skriptu je ešte potrebné upraviť samotný konfiguračný súbor OpenSER. Nasledujú zmeny, ktoré sú potrebné vykonať na predpripravenom konfiguračnom súbore. ####### Sekcia Modulov ######## loadmodule "mysql.so" loadmodule "auth.so" loadmodule "auth_db.so" Zavedenie potrebných modulov ###### Nastavenie parametrov jednotlivých modulov ###### #modparam("uri_db","use_uri_table",0) #modparam("uri_db","db_url","") modparam("uri_db","subscriber_table","subscriber") Názov tabuľky obsahujúcej informácie o užívateľoch modparam("uri_db","subscriber_user_column","username") Názov stĺpca v tabuľke obsahujúceho užívateľské mená #modparam("usrloc","db_mode",0) modparam("usrloc","db_mode",2) Autentifikácia užívateľov oproti databáze modparam("auth_db", "calculate_ha1", yes) Výpočet HA1 reťazca zo zadaného hesla 53

55 modparam("auth_db", "password_column", "password") Názov stĺpca v tabuľke obsahujúceho užívateľské heslá ####### Smerovacia Logika ######## route{ if (!(method=="register") && from_uri==myself) { if (!proxy_authorize(" ", "subscriber")) { proxy_challenge(" ", "0"); exit; } if (!check_from()) { sl_send_reply("403","forbidden auth ID"); exit; } consume_credentials(); } Pokiaľ správa nie je typu REGISTER a bola odoslaná od užívateľa v rámci vlastnej domény, a zároveň užívateľ nie je úspešne registrovaný na serveri, vyzve užívateľa, aby sa autentifikoval. Pokiaľ užívateľ nie je v zozname akceptovateľných užívateľov, odošle správu o nemožnosti registrácie. Pokiaľ je všetko v poriadku, teda správa je od registrovaného užívateľa, odstránia sa zo správy všetky prípadné registračné údaje, aby nedošlo k ich prezradeniu, a pokračuje sa s jej spracovaním. if (is_method("register")) { if (!www_authorize(" ", "subscriber")) { www_challenge(" ", "0"); exit; } if (!check_to()) { sl_send_reply("403","forbidden auth ID"); exit; } } if (!save("location")) sl_reply_error(); exit; Pokiaľ je správa typu REGISTER a užívateľ nie je registrovaný na serveri, odošle sa požiadavka na autentifikáciu. Pokiaľ užívateľ nie je v zozname akceptovateľných užívateľov, odošle správu o nemožnosti registrácie. Pokiaľ sa nepodarí uložiť záznam o registrácii do zoznamu užívateľov, je odoslaná chybová správa. 54

56 } Po úprave konfiguračného súboru máme úspešne implementovaný prvý stupeň zabezpečenia pomocou AUTH modulu. Samozrejme, predtým ako sa môže nejaký užívateľ registrovať na náš server, je potrebné mu vytvoriť užívateľské konto. Na prácu s užívateľskými kontami slúži ovládací skript openserctl. 7.4 Testovacie spojenie Po týchto zmenách sme znovu realizovali testovacie spojenia. Najskôr sme nášmu užívateľovi vytvorili užívateľské konto príkazom openserctl add karol heslo karol@krasnan.eu. Avšak najskôr sme sa pokúsili prihlásiť obdobným spôsobom ako v prvom prípade, teda bez použitia prihlasovacieho hesla. Nasledujúca schéma ukazuje priebeh tohto spojenia. Obr. 8 Priebeh prihlasovania bez zadania užívateľského hesla V prvom kroku užívateľ odosiela správu REGISTER, ktorá je rovnaká, ako pri predchádzajúcom prípade. Nakoľko užívateľ nie je registrovaný, server odosiela chybovú správu 400 Unauthorized a ako môžeme vidieť v ukážke správy, požaduje registráciu s uvedením prihlasovacích údajov. Ukážka správy 400 Unauthorized SIP/ Unauthorized Via: SIP/2.0/UDP :36280;branch=z9hG4bK-d b2136a60e4d3e- 1--d87543-;rport=36280 To: "Karol"<sip:karol@ >;tag=329cfeaa6ded039da25ff8cbb8668bd2.6b00 From: "Karol"<sip:karol@ >;tag=e25b787a 55

57 Call-ID: MTllMWY5MzVhOTkyYWJkMWNlZWYzNWVmYjA3ZjllNzA. CSeq: 1 REGISTER WWW-Authenticate: Digest realm=" ", nonce="481edee08d0ddb8339e b80424bcad27" Server: OpenSER (1.3.0-tls (i386/linux)) Content-Length: 0 Užívateľ sa snaží znova registrovať a odosiela správu REGISTER. Ako je vidieť, správa je na základe výzvy upravená. Je do nej vložená hlavička Authorization. Keďže sme však nezadali prihlasovacie heslo, toto nie je uvedené a server znova odmieta registráciu a užívateľský klient nás informuje o neúspešnej registrácii. Ukážka správy REGISTER REGISTER sip: SIP/2.0 Via: SIP/2.0/UDP :36280;branch=z9hG4bK-d b248d78dc d87543-;rport Max-Forwards: 70 Contact: <sip:karol@ :36280;rinstance=d74ddcbf461783bb> To: "Karol"<sip:karol@ > From: "Karol"<sip:karol@ >;tag=e25b787a Call-ID: MTllMWY5MzVhOTkyYWJkMWNlZWYzNWVmYjA3ZjllNzA. CSeq: 2 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: eyebeam release 1011w stamp Authorization: Digest username="karol", realm=" ", nonce="481edee08d0ddb8339e b80424bcad27", uri="sip: ", response="a9f3ceeede5e4d643f3c04fa9f939f56", algorithm=md5 Content-Length: 0 Následne sme realizovali kompletné testovacie spojenie. V tomto prípade však obaja užívatelia mali vytvorené užívateľské kontá na svojom serveri a používali korektné prihlasovacie údaje. Nasledujúci obrázok znázorňuje priebeh zostavovania, realizácie a ukončenia spojenia. V obrázku sú znova číselne znázornené správy, ktoré sme podrobnejšie analyzovali. 56

58 Obr. 9 Schéma zostavenia, priebehu a ukončenia testovacieho spojenia pri použití AUTH modulu Najskôr sa užívateľský klient snaží registrovať na serveri. Odosiela správu REGISTER, ktorá neobsahuje žiadne autentifikačné údaje. Server odpovedá správou 400 Unauthorized a požaduje autentifikáciu. Následne na to klient odpovedá a ako je vidieť z ukážky správy, predkladá všetky potrebné autentifikačné údaje. Prihlasovacie heslo je uložené v parametri response hlavičky Authorization a je šifrované MD5 algoritmom. Použitie tohto algoritmu je prednastavené, ale dá sa samozrejme zmeniť. Po úspešnej autentifikácii server odpovedá správou 200 OK a vykonáva registráciu klienta. Ukážka správy REGISTER REGISTER sip: SIP/2.0 Via: SIP/2.0/UDP :9622;branch=z9hG4bK-d87543-c da6d555b-1- -d87543-;rport Max-Forwards: 70 Contact: <sip:karol@ :9622;rinstance=f b27cd> To: "Karol"<sip:karol@ > From: "Karol"<sip:karol@ >;tag=ad5c6273 Call-ID: MDZjNmE2NzM3ZTQ1YjQ1NTY1NWNhNGIyZTEyYjU0OTY. CSeq: 2 REGISTER Expires:

59 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: eyebeam release 1011w stamp Authorization: Digest username="karol", realm=" ", nonce="481ee0bd05ec97e20a80c99d328184cd91434f16", uri="sip: ", response="b90f01de00a369454dc300d429dc5624",algorithm=md5 Content-Length: 0 Priebeh ďalšieho spojovania je totožný s priebehom bez použitia AUTH modulu. Vidíme teda, že modul AUTH je len miernym posunom v zabezpečení komunikácie. Keďže je vyžadovaná registrácia každého užívateľa a prihlasovacie heslo je šifrované, je značne sťažená pozícia útočníka, pokiaľ by chcel zneužiť identitu užívateľa. Avšak samotná komunikácia je naďalej úplne otvorená a teda nie je problém komunikáciu odpočúvať, pozmeňovať a pod. Taktiež je server stále náchylný na DoS útoky, pretože spracováva všetky správy, ktoré sú mu odoslané. 58

60 8. Implementácia OpenSER TLS Z uvedenej analýzy vidíme, že zabezpečenie stále nemôžeme považovať za dostatočné. Preto je potrebné implementovať ďalší spôsob zabezpečenia. Týmto spôsobom je práve implementácia podpory TLS, ktorá by nám mala výrazne zvýšiť bezpečnosť spojenia. Poďme sa preto bližšie pozrieť na kroky potrebné pre jej úspešnú realizáciu. 8.1 Potrebné softvérové úpravy Keďže s implementáciou TLS zabezpečenia sme rátali od začiatku, odpadá potreba preinštalovania OpenSER, nakoľko naše jadro systému už túto časť obsahuje. Ďalším nevyhnutným doplnkom je inštalácia podpory SSL,TLS protokolov. V našom prípade sme doinštalovali softvér OpenSSL. Tento softvér nám poskytuje aj funkcie potrebné na správu a generovanie autentifikačných certifikátov. Neboli potrebné, žiadne ďalšie nastavenia tohto softvéru. Jediným problémom bola korektná spolupráca tohto softvéru s ovládacím skriptom opensrctl, ktorý poskytuje funkcie pre spoluprácu s OpenSER. Tu je potrebné si dať pozor na správne nastavenie ciest k súborom OpenSSL vo vnútri skriptu. 8.2 Generovanie autentifikačných certifikátov Ako bolo uvedené v časti na to, aby dva uzly mohli medzi sebou začať šifrovanú komunikáciu cez TLS, je predtým potrebné, aby si bezpečným spôsobom dohodli šifrovacie algoritmy a používané kľúče. Na vytvorenie tejto bezpečnej cesty je potrebné, aby sa minimálne jedna komunikujúca strana (server) bola schopná preukázať dôveryhodným certifikátom a poskytla verejný šifrovací kľúč (verejný certifikát). Tu vyvstáva otázka, ako získať tieto potrebné certifikáty. V zásade sú dve možnosti. Prvou je nechať si certifikáty vystaviť treťou stranou, teda uznávanou certifikačnou autoritou, čo je samozrejme spoplatnená služba. Druhou možnosťou je vytvoriť si vlastné certifikáty tzv. self signed certificate. V našom prípade sme realizovali druhú možnosť. 59

61 8.2.1 Certifikáty certifikačnej autority Keďže sme sa rozhodli vygenerovať si vlastné certifikáty, postavili sme sa do úlohy certifikačnej autority (CA). Každá certifikačná autorita má svoj verejný certifikát a podpisový privátny kľúč. Verejný certifikát je verejne dostupný a pokiaľ chceme akceptovať certifikáty, ktoré podpísala certifikačná autorita, musíme mať tento verejný certifikát v našom lokálnom zozname dôveryhodných CA. Privátnym kľúčom certifikačná autorita podpisuje každý svoj certifikát a tým uznáva, že certifikát je platný a tým všetky počítače, ktoré uznávajú CA budú akceptovať ňou podpísané certifikáty a budú považovať majiteľa takéhoto certifikátu za dôveryhodného. Pokiaľ by došlo k prezradeniu privátneho podpisového kľúča certifikačnej autority, všetky ňou podpísané certifikáty by boli kompromitované. V prvom kroku je potrebné upraviť konfiguračný súbor pre generovanie certifikátov certifikačnej autority ca.conf. Tento súbor sa nachádza v adresári TLS spolu s ostatnými konfiguračnými súbormi OpenSER. Nami použitý súbor ca.conf: [ ca ] default_ca = local_ca [ local_ca ] dir =./rootca Umiestnenie adresárov a certificate = $dir/cacert.pem definovanie názvov database = $dir/index.txt výstupných súborov pri new_certs_dir = $dir/certs podpisovaní certifikátov. private_key = $dir/private/cakey.pem serial = $dir/serial default_crl_days = 365 Dĺžka platnosti default_days = 1825 podpísaných certifikátov. default_md = sha1 Šifrovací algoritmus pri policy = local_ca_policy vytváraní certifikátov. x509_extensions = local_ca_extensions [ local_ca_policy ] commonname = supplied Vyžadované parametre, stateorprovincename = supplied ktoré musí obsahovať countryname = supplied certifikát, podpisovaný address = supplied certifikačnou autoritou. organizationname = supplied organizationalunitname = supplied [ local_ca_extensions ] 60

62 basicconstraints nscerttype = CA:false = server [ req ] default_md = sha1 Šifrovací algoritmus, počet default_bits = 2048 bitov pre šifrovanie default_keyfile =./private/cakey.pem privátneho kľúča CA prompt = no a jeho umiestnenie. distinguished_name = root_ca_distinguished_name x509_extensions = root_ca_extensions [ root_ca_distinguished_name ] Identifikačné údaje commonname = Karol Krasnan certifikačnej autority. stateorprovincename = Slovakia countryname = SK address = karol@krasnan.eu organizationname = FEI STU [ root_ca_extensions ] basicconstraints = CA:true subjectaltname = copy issueraltname = issuer:copy Následne spustíme samotný proces generovania certifikátov pre certifikačnú autoritu. V našom prípade /usr/local/sbin/openserctl tls rootca. Počas vykonávanie skriptu budeme vyzvaní na zadanie hesla, ktorým sa zašifruje privátny kľúč a ktorý budeme musieť uviesť pri každom podpisovaní certifikátu. Po úspešnom prebehnutí procesu bude vytvorený adresár rootca, ktorý obsahuje verejný certifikát CA, súbor cacert.pem. Ďalej bude vytvorený adresár Private, ktorý obsahuje privátny podpisový kľúč CA a adresár Certs, ktorý obsahuje informácie o všetkých certifikátoch, ktoré certifikačná autorita podpísala Užívateľské certifikáty Po úspešnom vytvorení certifikátov vlastnej certifikačnej autority potrebujeme vytvoriť certifikáty pre jednotlivých užívateľov, v našom prípade OpenSER proxy serveri, aby sa mohli nimi preukazovať pri zostavovaní TLS spojenia. Takýto certifikát sa taktiež skladá z verejného certifikátu, ktorým klient, ktorý sa na server pripája, šifruje komunikáciu, a privátneho kľúča, ktorý pozná len server a teda jedine on je schopný dešifrovať správu zašifrovanú jeho verejným certifikátom. 61

63 Potrebné nastavenia na vygenerovanie užívateľského certifikátu sú v súboroch user.conf a request.conf. Druhý z uvedených súborov predstavuje žiadosť o vydanie certifikátu a nemusíme ho upravovať, pokiaľ nám vyhovujú prednastavené parametre. Súbor user.conf obsahuje informácie o konkrétnom používateľovi certifikátu, teda je nevyhnutné ho upraviť podľa parametrov užívateľa, ktorý bude certifikát používať. Po upravení je potrebné súbor user.conf premenovať podľa názvu nášho servera, ktorý budú užívatelia používať, keď sa budú naň pripájať. Nami použitý súbor request.conf: [ ca ] default_ca = CA_request [ CA_request ] dir =./rootca Informácie o certifikáte new_certs_dir = $dir/certs certifikačnej autority. Tieto certificate = $dir/cacert.pem nastavenia sa musia zhodovať serial = $dir/serial s nastaveniami, s ktorými bol private_key = $dir/private/cakey.pem vygenerovaný certifikát CA. default_days = 365 default_crl_days = 1825 default_md = sha1 policy = req_policy nameopt = ca_default certopt = ca_default copy_extensions = copy x509_extensions = cert_extensions [ req_policy ] countryname = supplied Zadefinovanie parametre, ktoré stateorprovincename = optional musia byť resp. môžu byť uvedené organizationname = supplied o používateľovi certifikátu. organizationalunitname = optional commonname = supplied address = supplied [ cert_extensions ] basicconstraints = CA:false Nami použitý súbor conf (user.conf): [ req ] prompt = no distinguished_name = Názov servera, ktorý bude certifikát využívať. [ ] commonname =

64 stateorprovincename = Bratislava countryname = SK address = karol@krasnan.eu organizationname = Karol Krasnan organizationalunitname = FEI STU Po vykonaní potrebných nastavení vygenerujeme samotný certifikát spustením príkazu usr/local/sbin/openserctl tls usercert. Následne bude vygenerovaný certifikát a budeme vyzvaní na zadanie hesla k privátnemu kľúču certifikačnej autority. Po zadaní hesla bude certifikát podpísaný a pripravený na použitie. Po tomto procese bude vytvorený adresár s názvom servera, pre ktorý je generovaný certifikát, ktorý v našom prípade obsahuje súbory: cert_req.pem je medziprodukt celého procesu privkey.pem je privátny kľúč pre server Tieto dva súbory sú potrebné pre znovu vygenerovanie verejného certifikátu, napr. po vypršaní jeho platnosti cert.pem verejný certifikát calist.pem informácie o certifikačnej autorite, ktorá certifikát podpísala. 8.3 Šifrovanie komunikácie medzi dvoma OpenSER Ako sme uviedli vyššie, šifrovanie komunikácie môžeme rozdeliť na dve fázy. Šifrovanie komunikácie medzi servermi a šifrovanie medzi klientom a serverom. V ďalšej časti sa budeme venovať nastaveniu šifrovania medzi dvoma servermi a testovaniu tohto nastavenia Zmeny konfigurácie OpenSER Na realizáciu požadovaného zabezpečenia je potrebné vykonať ďalšie zmeny v konfiguračnom súbore OpenSER. Zároveň je potrebné vytvoriť zoznam dôveryhodných certifikačných autorít. Tento zoznam musí obsahovať všetky CA, ktoré považujeme za dôveryhodné. Zoznam calist.pem môžeme vytvoriť spojením verejných certifikátov certifikačných autorít napr. príkazom cat verejny_certifikat.pem >> calist.pem. 63

65 Uvádzané sú len tie časti konfiguračného súboru, ktoré je potrebné doplniť, prípadne zmeniť. ####### Globálne Parametre ######### disable_tls = no Zapnutie používania TLS časti. listen = tls: Nastavenie rozhrania, na ktorom bude server prijímať šifrovanú komunikáciu. tls_method = SSLv23 Používaná metóda šifrovania. tls_verify_server = 1 Vyžadovanie šifrovanej komunikácie medzi servermi a zároveň sa vyžaduje aj preukázanie platného certifikátu servera. tls_verify_client = 0 Nevyžaduje sa šifrovaná komunikácia s klientmi. tls_require_client_certificate=0 Nevyžaduje sa, aby sa klienti preukazovali certifikátom. tls_certificate = "/usr/local/etc/openser/tls/ / cert.pem" Cesta k verejnému certifikátu servera. tls_private_key = "/usr/local/etc/openser/tls/ / privkey.pem" Cesta k privátnemu kľúču servera. tls_ca_list = "/usr/local/etc/openser/tls/calist.pem" Cesta k zoznamu dôveryhodných CA. listen= Nastavenie rozhrania, na ktorom bude server prijímať nešifrovanú komunikáciu. port 5060 ####### Sekcia Modulov ######## loadmodule "domain.so" Modul poskytujúci funkcie potrebné pre smerovanie šifrovaných správ medzi doménami. ####### Smerovacia Logika ######## route{ if (!is_uri_host_local()) { append_hf("p-hint: outbound\r\n"); if($rd==" ") { t_relay("tls: "); exit; } route(1); } Pokiaľ správa obsahuje URI iného, ako lokálneho servera, tak sa označí ako smerovaná mimo lokálneho servera a podľa jej URI sa jej priradí adresa servera, na ktorú bude smerovaná. V našom prípade to bude cez TLS protokol. } 64

66 8.3.2 Testovacie spojenie Po uvedených úpravách sme znova realizovali testovacie spojenie. Nasledujúci obrázok znázorňuje zostavovanie, priebeh a ukončenie testovacieho spojenia. Obr. 10 Schéma zostavenia, priebehu a ukončenia testovacieho spojenia pri šifrovaní spojenia medzi OpenSER proxi servermi Na uvedenej schéme vidíme, že celý proces znova začína registráciou užívateľských klientov a ich autentifikáciou tak, ako to bolo popísané v časti 7.4. Zmena nastáva v momente, kedy je potrebné preniesť INVITE správu medzi OpenSER servermi. Tu sa začína handshake proces zostavovania šifrovaného TLS spojenia. OpenSER1, ktorý je v pozícii klienta odosiela správu ClientHello, ktorá okrem iného obsahuje zoznam podporovaných šifrovacích algoritmov, kompresných metód atď. Ukážka správy ClientHello Secure Socket Layer TLSv1 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 83 65

67 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 79 Version: TLS 1.0 (0x0301) Random Session ID Length: 0 Cipher Suites Length: 40 Cipher Suites (20 suites) Compression Methods Length: 1 Compression Methods (1 method) Následne OpenSER2, ktorý je v pozícii servera odpovedá správou ServerHello, v ktorej uvádza ním zvolený šifrovací algoritmus, kompresnú metódu atď. Časť správy ServerHello Secure Socket Layer TLSv1 Record Layer: Handshake Protocol: Server Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 74 Handshake Protocol: Server Hello Handshake Type: Server Hello (2) Length: 70 Version: TLS 1.0 (0x0301) Random Session ID Length: 32 Session ID: 40F5C33431C5EA28FA3154F8B4A86C97E363391BBEB Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Compression Method: null (0) OpenSER2 v zapätí posiela aj správu Certificate, v ktorej posiela svoj verejný certifikát a parametre potrebné na vytvorenie jedinečného šifrovacieho kľúča, ktorý bude použitý pri ďalšej komunikácii a symetrickom šifrovaní. Používaním preukazovania autenticity pomocou certifikátov sa takmer znemožní útok typu Man in the middle. Nakoľko pokiaľ útočník nezíska privátny kľúč niektorých pre klienta dôveryhodných certifikačných autorít, nebude schopný sa preukázať a nedôjde k zostaveniu spojenia. Časť správy Certificate Secure Socket Layer TLSv1 Record Layer: Handshake Protocol: Certificate Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 1640 Handshake Protocol: Certificate Handshake Type: Certificate (11) Length: 1636 Certificates Length: 1633 Certificates (1633 bytes) Certificate Length:

68 Certificate STU,id-atorganizationName=Karol Krasnan,id-at-stateOrProvinceName=Bratislava,id-atcountryName=SK) Certificate Length: 935 Certificate (id-at-organizationname=fei Krasnan) Secure Socket Layer TLSv1 Record Layer: Handshake Protocol: Server Hello Done Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 4 Handshake Protocol: Server Hello Done Handshake Type: Server Hello Done (14) Length: 0 Následne prebehne medzi servermi dohodnutie šifrovacích pravidiel, odoslanie testovacích zašifrovaných správ a začína sa samotný prenos šifrovaných dát. Samotné dáta sú prenášané v správach s hlavičkou Application Data. Z priebehu zostavovania spojenia vidíme, že prvá prenášaná zašifrovaná správa je správa INVITE. Časť správy ApplicationData Secure Socket Layer TLSv1 Record Layer: Application Data Protocol: sip.tcp Content Type: Application Data (23) Version: TLS 1.0 (0x0301) Length: 1296 Encrypted Application Data: 9F41D28A1AFEB690291EDBE953602EE6ABA C Z pohľadu na správu je však zrejmé, že útočník nemá možnosť zistiť, o akú správu sa v skutočnosti jedná, ani aký je jej obsah. Celá správa INVITE je prenášaná v poli Encrypted Application Data. Týmto sme výrazne zvýšili bezpečnosť prenášaných SIP správ medzi servermi v rámci vonkajšej siete. Samotná komunikácia, teda prenos RTP správ aj prenos SIP signalizácia v rámci vnútornej siete však zostáva nešifrovaný. Pozícia útočníka je aj napriek tomu značne skomplikovaná, nakoľko bez SIP signalizácie je pre neho oveľa zložitejšie identifikovať komunikujúce strany a lokalizovať tok RTP správ. S vynaložením väčšieho úsilia a výpočtového výkonu je to však realizovateľné. Problémom stále zostáva komunikácia v rámci vnútornej siete, ktoré je kompletne otvorená a teda keby útočník bol v rámci nej, nie je pre neho žiaden problém útok 67

69 realizovať. Ďalším problémom je, že náš server prijíma aj nešifrované správy a teda je stále náchylný na DoS útoky. 8.4 Šifrovanie komunikácie medzi užívateľským klientom a OpenSER Druhou fázou zabezpečenia komunikácie šifrovaním je implementácia šifrovania v rámci vnútornej siete, teda medzi klientom a serverom. V nasledujúcej časti sa zaoberáme potrebnými zmenami v konfigurácii našej testovacej siete, realizáciou a analyzovaním testovacieho spojenia Zmeny konfigurácie OpenSER Keďže v konfiguračnom súbore OpenSER už máme implementovanú podporu pre šifrovanú komunikáciu medzi servermi, rozšírenie zabezpečenia aj na komunikáciu s klientmi si vyžaduje len minimálne zmeny. Uvádzané sú len tie časti konfiguračného súboru, ktoré je potrebné doplniť, prípadne zmeniť. ####### Globálne Parametre ######### listen = tls: Nastavenie rozhrania, na ktorom bude server prijímať šifrovanú komunikáciu. listen = tcp: tls_verify_client = 1 Vyžaduje sa šifrovaná komunikácia s klientmi. tls_require_client_certificate=0 Nevyžaduje sa, aby sa klienti preukazovali certifikátom. Ostatné časti konfiguračného súboru nie je potrebné meniť. Najdôležitejšou zmenou je zmena hodnoty parametra tls_verify_client. OpenSER bude teda od klientov očakávať iba šifrovanú komunikáciu a vôbec nebude spracovávať nešifrované správy. Nastavenie rozhrania pre protokol TCP je potrebné pri zostavovaní šifrovaného spojenia. Maximálne zabezpečenie by sme dosiahli, keby sme aj od klientov vyžadovali preukazovanie certifikátom. Táto možnosť je však málo používaná hlavne kvôli nutnosti, aby každý klient mal svoj vlastný dôveryhodný certifikát. Tento prístup môže byť veľmi zaujímavý pre riešenie firemných privátnych VoIP sietí. 68

70 8.4.2 Zmeny konfigurácie užívateľského klienta Väčšia časť zmien pri implementácii zabezpečenej komunikácie medzi užívateľom a serverom je na strane užívateľského klienta. V prvom rade je potrebné mať IP telefón, ktorý podporuje šifrovanú komunikáciu a je potrebné v nastaveniach povoliť používanie šifrovanej komunikácie. V zásade je možné povoliť šifrovanie iba signalizácie teda SIP správ, alebo aj samotnej komunikácie, teda použitie SRTP. V našom prípade sme zvolili maximálne zabezpečenie, teda sme požadovali šifrovanie SIP správ, ako aj komunikácie prenášanej cez RTP. Keďže v našej testovacej virtuálnej sieti predstavovali užívateľských klientov softvérové telefóny používané pod operačným systémom Windows, bolo zároveň potrebné pridať certifikát našej certifikačnej autority medzi dôveryhodných partnerov. Pokiaľ by sme tak neurobili, nedošlo by ku korektnému zostaveniu šifrovaného spojenia. V prostredí Windows je na správu certifikátov vytvorený program certmgr.msc. Po jeho spustení vyberieme voľbu Akcia Nájsť certifikát a nalistujeme verejný certifikát našej certifikačnej autority (cacert.pem), ktorý sme vytvorili podľa postupu uvedeného v časti Po ukončení procedúry musíme nájsť náš certifikát v zozname dôveryhodných certifikačných autorít. 69

71 8.4.3 Testovacie spojenie Po vykonaní všetkých potrebných zmien sme znova realizovali testovacie spojenie a analyzovali niektoré správy. Obr. 11 Schéma zostavenia, priebehu a ukončenia testovacieho spojenia pri šifrovaní celého spojenia Zo schémy priebehu spojenia si hneď môžeme všimnúť, že predtým, ako klient odosiela nejakú správu, žiada o vytvorenie zabezpečeného spojenia správou ClientHello. Ukážka správy ClientHello Secure Socket Layer TLSv1 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 91 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) 70

72 Length: 87 Version: TLS 1.0 (0x0301) Random gmt_unix_time: May 12, :27: random_bytes: 41C141C44EB752D2E07847C8BC B9B1AC6CA Session ID Length: 0 Cipher Suites Length: 48 Cipher Suites (24 suites) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Cipher Suite: TLS_DHE_DSS_WITH_RC4_128_SHA (0x0066) Cipher Suite: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x0062) Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x0015) Cipher Suite: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0014) Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009) Cipher Suite: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0008) Cipher Suite: TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (0x0063) Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012) Cipher Suite: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x0011) Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064) Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 (0x0060) Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003) Cipher Suite: TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA (0x0065) Compression Methods Length: 1 Compression Methods (1 method) Server odpovedá štandardným spôsobom a preukazuje svoju autenticitu odoslaním certifikátov. Následne dochádza k zostaveniu zabezpečeného spojenia. Až v tomto momente odosiela klient správu INVITE, ktorá je však zašifrovaná a ako je vidieť z ukážky správy, útočník sa z nej dozvie maximálne, že ide o zašifrovanú SIP správu. Všetky podstatné informácie sa prenášajú v poli Encrypted Application Data. Časť správy ApplicationData(INVITE) Secure Socket Layer TLSv1 Record Layer: Application Data Protocol: sip.tcp Content Type: Application Data (23) Version: TLS 1.0 (0x0301) Length: 32 Encrypted Application Data: EE1031D8A85AA6958D6EA61E4ED62212DE361FF49BAE694E... TLSv1 Record Layer: Application Data Protocol: sip.tcp Content Type: Application Data (23) Version: TLS 1.0 (0x0301) Length:

73 Encrypted Application Data: 18AE56DF44775D14FD74C06B66BFD31923F7E475FE6AAE9A... Takýmto spôsobom sa prenášajú aj všetky ostatné SIP správy počas celej komunikácie. Dôležitou zmenou je aj zabezpečenie samotného prenosu mediálnych dát. Ako môžeme vidieť z ukážky správy, dáta samotného mediálneho prenosu sú taktiež šifrované v poli Data UDP správy. Ukážka šifrovaných dát v UDP správe User Datagram Protocol, Src Port: (59662), Dst Port: (50052) Data (102 bytes) Data: 806B124C000B5180CA5C219C2D78934E8D10DA112DC247B6... Z uvedeného je zjavné, že takto zabezpečený VoIP systém je skutočne bezpečný a je zložité naň realizovať útok. Týmto spôsobom dokážeme potlačiť väčšinu možných bezpečnostných hrozieb, či už odpočúvanie hovoru, zneužitie prihlasovacích údajov, a keďže takto nakonfigurovaný server spracováva iba šifrované správy, tak aj nebezpečenstvo DoS útokov. 72

74 9. Zabezpečenie komunikácie použitím OpenVPN Ďalším možným prístupom k zabezpečeniu VoIP komunikácie je vytvorenie virtuálnej privátnej siete. Keďže toto riešenie je v poslednej dobe čoraz častejšie nie len v prípade VoIP systémov, implementovali sme tento spôsob a porovnávali ho so zabezpečením OpenSER s TLS. 9.1 Princíp fungovania VPN Základným princípom virtuálnej privátnej siete je vytvorenie zabezpečeného spojenia medzi dvoma komunikujúcimi uzlami. Toto spojenie predstavuje samostatný komunikačný kanál (samostatné rozhranie), v ktorom prenášaná komunikácia je navonok šifrovaná. V našej implementácii sme použili softvér OpenVPN, pomocou ktorého sme vytvorili zabezpečené spojenie medzi OpenSER servermi. Tento softvér pre vytvorenie zabezpečeného spojenia taktiež využíva TLS protokol. Postup vytvorenia spojenia je teda identický, ako v predchádzajúcich prípadoch. 9.2 Konfigurácia OpenVPN Konfigurácia OpenVPN si vyžaduje predovšetkým nastavenie uzlov, medzi ktorými sa bude vytvárať zabezpečené spojenie. Následne je potrebné nastaviť parametre šifrovania, vygenerovať a nastaviť šifrovacie kľúče. Po nakonfigurovaní softvéru a jeho spustení nasleduje pokus o nadviazanie spojenia s druhou stranou, s ktorou má byť vytvorená VPN. Pokiaľ aj druhá strana je pripravená na vytvorenie spojenia, prebehne handshake procedúra, vymenia sa všetky údaje potrebné na šifrovanie a v systéme pribudne nové sieťové rozhranie. Ide o virtuálne sieťové rozhranie, ktoré je ukončením zabezpečeného komunikačného kanála. Takéto rozhranie je vytvorené no oboch uzloch. Všetky dáta, ktoré sú odosielané na toto sieťové rozhranie, sú následne softvérom OpenVPN šifrované a posielané cez už existujúce spojenie. Na druhej strane server prijíma dáta na reálnom sieťovom rozhraní posúva ich OpenVPN, ten ich dešifruje a dešifrované dáta prichádzajú z virtuálneho sieťového rozhrania. Výsledkom je, že z pohľadu užívateľa systému sa nám javí, ako keby všetky dáta prechádzali samostatným sieťovým spojením. 73

75 Nasledujúci obrázok schematicky znázorňuje vytvorené virtuálne šifrované spojenie medzi proxy servermi. Obr. 12 Schematické znázornenie spojenia proxy serverov použitím VPN 74

76 9.3 Testovacie spojenie Aj na implementácii tohto zabezpečenia sme realizovali testovacie spojenie a sledovali sme zabezpečenie prenášaných správ. Predtým však bolo potrebné vhodne zmeniť konfiguráciu oboch OpenSER tak, aby správy určené mimo vlastnej domény smerovali cez virtuálne sieťové rozhranie. Obr. 13 Schéma zostavenia, priebehu a ukončenia testovacieho spojenia pri zabezpečení spojenia medzi proxy servermi použitím OpenVPN Ako v schéme vidíme hneď, po spustení OpenVPN prebehla handshake procedúra a bolo vytvorené zabezpečené virtuálne spojenie. Následne na to sme realizovali samotné volanie. Postup výmeny signalizačných správ je identický ako pri predchádzajúcich testovaniach. Z nasledujúcej ukážky prenášanej správy medzi OpenSer vidíme, že dochádza k jej zašifrovaniu a útočník nemá možnosť zistiť, o akú správu sa v skutočnosti jedná. Samotné šifrované dáta sú prenášané v parametri Data. Dôležité je upozorniť, že táto 75

77 správa bola odchytená v rámci reálneho sieťového spojenia. Teda toho, ktoré by mal potenciálne prístupné aj útočník. Ukážka správy INVITE prenášanej cez VPN: User Datagram Protocol, Src Port: commplex-link (5001), Dst Port: commplexlink (5001) Source port: commplex-link (5001) Destination port: commplex-link (5001) Length: 1276 Checksum: 0xc837 [correct] Data (1268 bytes) Z uvedenej ukážky vidíme, že toto riešenie nám taktiež poskytuje zabezpečenie komunikácie medzi proxy servermi. Taktiež vidíme, že samotný mediálny prenos nie je šifrovaný, nakoľko tento prenos je realizovaný spojením priamo medzi klientmi. Hlavnou výhodou tohto riešenia je vytvorenie jedného šifrovaného spojenia, ktoré môžu využívať všetky aplikácie. Teda celá komunikácia medzi servermi môže byť šifrovaná a nemusíme riešiť zabezpečenie pre každú aplikáciu zvlášť. Na druhej strane nevýhodou je, že takéto spojenie je možné vytvoriť vždy iba medzi dvoma uzlami. Teda na zabezpečenie celej komunikácie by sme museli vytvoriť virtuálne spojenie medzi všetkými komunikujúcimi dvojicami. 76

78 10. Testovanie efektivity OpenSER s TLS a OpenVPN Ako bolo uvedené vyššie, podarilo sa nám realizovať niekoľko stupňov a spôsobov zabezpečenia VoIP komunikácie pri použití SIP. V poslednej fáze praktickej časti nás zaujímalo, ktorý zo spôsobov je efektívnejší a mohli by sme ho odporúčať. Z tohto dôvodu sme testovali efektívnosť zabezpečenia spojenia medzi našimi proxy servermi pri použití OpenSER s TLS a OpenVPN Východiská testovania Na testovanie sme použili špeciálny softvér Sipp, ktorý bol vytvorený práve k tomuto účelu. Tento softvér simuluje správanie užívateľského softvéru a dokáže podľa potreby generovať až niekoľko stoviek hovorov za sekundu. Nasledujúca schéma znázorňuje východiskovú konfiguráciu, ktorú sme použili na testovanie. Obr. 14 Schéma východiskovej konfigurácie použitej na testovanie výkonnosti šifrovania OpenSER s TLS a OpenVPN Užívateľských klientov sme nahradili softvérom Sipp, ktorý sme nakonfigurovali tak, aby generoval priebeh klasického volania. Schéma nami generovaného volania je znázornená na obrázku

79 Obr. 15 Schéma generovaného spojenia pri testovaní výkonnosti šifrovania OpenSER s TLS a OpenVPN Pri testovaní sme sa rozhodli sledovať tri najdôležitejšie parametre ovplyvňujúce jednak kvalitu poskytnutej VoIP služby, a taktiež generované zaťaženie hardvéru proxy servera. Sledovali sme teda percentuálne vyťaženie procesora proxy servera, oneskorenie odoslanej správy a celkový čas trvania zostavenia a ukončenia spojenia. Oneskorenie odoslanej správy predstavuje čas, za ktorý správa odoslaná SIPP1 prejde cez OpenSER1, cez spojovaciu cestu, OpenSER2, je spracovaná SIPP2 a reakcia doručená naspäť ku SIPP1. Celkový čas zostavenia a ukončenia spojenia predstavuje čas od odoslania správy INVITE SIPP1 po prijatie správy 200 OK SIPP1, ktorá potvrdzuje ukončenie spojenia. Ide teda o trvanie celej cyklicky sa opakujúcej časti spojenia, alebo aj o čas trvania SIP dialógu. V schéme priebehu spojenia bolo vložené 100ms oneskorenie, ktoré predstavuje realizáciu hovoru. Teda v prípade, že by oneskorenie signalizačných správ bolo nulové, celé spojenie by trvalo minimálne 100ms. Tieto tri parametre sme sledovali pri rôznych zaťaženiach systému a pre každý spôsob zabezpečenia zvlášť. Postupne sme zväčšovali zaťaženie systému od 10 do 400 hovorov za sekundu. Každé testovanie trvalo približne 100 sekúnd, takže sme celkovo vygenerovali 100 násobný počet hovorov oproti sekundovému zaťaženiu. Dôležité je ešte upozorniť, že nebolo možné 100% zaručiť rovnaké podmienky pri všetkých testovaniach, čo sa prejavilo aj na niektorých nameraných hodnotách. 78

Copyright 2016 by Martin Krug. All rights reserved.

Copyright 2016 by Martin Krug. All rights reserved. MS Managed Service Copyright 2016 by Martin Krug. All rights reserved. Reproduction, or translation of materials without the author's written permission is prohibited. No content may be reproduced without

More information

Registrácia účtu Hik-Connect

Registrácia účtu Hik-Connect Registrácia účtu Hik-Connect Tento návod popisuje postup registrácie účtu služby Hik-Connect prostredníctvom mobilnej aplikácie a webového rozhrania na stránke www.hik-connect.comg contents in this document

More information

Aplikačný dizajn manuál

Aplikačný dizajn manuál Aplikačný dizajn manuál Úvod Aplikačný dizajn manuál je súbor pravidiel vizuálnej komunikácie. Dodržiavaním jednotných štandardov, aplikácií loga, písma a farieb pri prezentácii sa vytvára jednotný dizajn,

More information

Recipient Configuration. Štefan Pataky MCP, MCTS, MCITP

Recipient Configuration. Štefan Pataky MCP, MCTS, MCITP Recipient Configuration Štefan Pataky MCP, MCTS, MCITP Agenda Mailbox Mail Contact Distribution Groups Disconnected Mailbox Mailbox (vytvorenie nového účtu) Exchange Management Console New User Exchange

More information

Anycast. Ľubor Jurena CEO Michal Kolárik System Administrator

Anycast. Ľubor Jurena CEO Michal Kolárik System Administrator Anycast Ľubor Jurena CEO jurena@skhosting.eu Michal Kolárik System Administrator kolarik@skhosting.eu O nás Registrátor Webhosting Serverové riešenia Správa infraštruktúry Všetko sa dá :-) Index Čo je

More information

Spájanie tabuliek. Jaroslav Porubän, Miroslav Biňas, Milan Nosáľ (c)

Spájanie tabuliek. Jaroslav Porubän, Miroslav Biňas, Milan Nosáľ (c) Spájanie tabuliek Jaroslav Porubän, Miroslav Biňas, Milan Nosáľ (c) 2011-2016 Úvod pri normalizácii rozdeľujeme databázu na viacero tabuliek prepojených cudzími kľúčmi SQL umožňuje tabuľky opäť spojiť

More information

Manuál k programu FileZilla

Manuál k programu FileZilla Manuál k programu FileZilla EXO TECHNOLOGIES spol. s.r.o. Garbiarska 3 Stará Ľubovňa 064 01 IČO: 36 485 161 IČ DPH: SK2020004503 support@exohosting.sk www.exohosting.sk 1 Úvod EXO HOSTING tím pre Vás pripravil

More information

TP-LINK 150Mbps Wireless AP/Client Router Model TL-WR743ND Rýchly inštalačný sprievodca

TP-LINK 150Mbps Wireless AP/Client Router Model TL-WR743ND Rýchly inštalačný sprievodca TP-LINK 150Mbps Wireless AP/Client Router Model TL-WR743ND Rýchly inštalačný sprievodca Obsah balenia TL-WR743ND Rýchly inštalačný sprievodca PoE injektor Napájací adaptér CD Ethernet kábel Systémové požiadavky

More information

Počítačové siete Bezpečnosť

Počítačové siete Bezpečnosť Počítačové siete Bezpečnosť Bezpečnostné problémy v sieťach dôvernosť integrita a autentickosť dostupnosť autentifikácia používateľov systémov riadenie prístupu 2 Bezpečnostné mechanizmy fyzická ochrana

More information

Riešenia a technológie pre jednotnú správu používateľov

Riešenia a technológie pre jednotnú správu používateľov Riešenia a technológie pre jednotnú správu používateľov Radovan Semančík Agenda Úvod: Identity Crisis Technológie správy používateľov Postup nasadenia Záver Súčasný stav IT Security Nekonzistentné bezpečnostné

More information

Obsah. SOA REST REST princípy REST výhody prest. Otázky

Obsah. SOA REST REST princípy REST výhody prest. Otázky REST Peter Rybár Obsah SOA REST REST princípy REST výhody prest Otázky SOA implementácie WEB (1990) CORBA (1991) XML-RPC (1998) WS-* (1998) SOAP RPC/literal SOAP Document/literal (2001) REST (2000) SOA

More information

Ochrana koncových staníc pomocou Cisco Security Agent 6.0. Ľubomír Varga.

Ochrana koncových staníc pomocou Cisco Security Agent 6.0. Ľubomír Varga. Ochrana koncových staníc pomocou Cisco Security Agent 6.0 Ľubomír Varga lubomir.varga@lynx.sk Agenda CSA 6.0 refresh Vybrané vlastnosti CSA 6.0 Application Trust levels Notify User Rule Actions User Justifications

More information

Spôsoby zistenia ID KEP

Spôsoby zistenia ID KEP Spôsoby zistenia ID KEP ID KEP (kvalifikovaný elektronický podpis) je možné zistiť pomocou napr. ovládacieho panela, prostredíctvom prehliadača Internet Expolrer, Google Chrome alebo Mozilla Firefox. Popstup

More information

kucharka exportu pro 9FFFIMU

kucharka exportu pro 9FFFIMU požiadavky na export kodek : Xvid 1.2.1 stable (MPEG-4 ASP) // výnimočne MPEG-2 bitrate : max. 10 Mbps pixely : štvorcové (Square pixels) rozlíšenie : 1920x1080, 768x432 pre 16:9 // výnimočne 1440x1080,

More information

Mesačná kontrolná správa

Mesačná kontrolná správa Mesačná kontrolná správa Štrukturálna štúdia dec.16 nov.16 okt.16 sep.16 aug.16 júl.16 jún.16 máj.16 apr.16 mar.16 feb.16 jan.16 Internetová populácia SR 12+ 3 728 988 3 718 495 3 718 802 3 711 581 3 700

More information

Ochrana proti DDoS za použitia open-source software. Katarína Ďurechová

Ochrana proti DDoS za použitia open-source software. Katarína Ďurechová Ochrana proti DDoS za použitia open-source software Katarína Ďurechová katarina.durechova@nic.cz 30.11.2013 Distributed Denial of Service odopretie služby dosiahnutím limitu pripojenia sieťovej karty CPU

More information

Mesačná kontrolná správa

Mesačná kontrolná správa Mesačná kontrolná správa Štrukturálna štúdia mar.18 feb.18 jan.18 dec.17 nov.17 okt.17 sep.17 aug.17 júl.17 jún.17 máj.17 apr.17 mar.17 Internetová populácia SR 12+ 3 904 509 3 802 048 3 870 654 3 830

More information

Databázové systémy. SQL Window functions

Databázové systémy. SQL Window functions Databázové systémy SQL Window functions Scores Tabuľka s bodmi pre jednotlivých študentov id, name, score Chceme ku každému doplniť rozdiel voči priemeru 2 Demo data SELECT * FROM scores ORDER BY score

More information

Technické podmienky pripojenia SIP PBX k službe Business Trunk.

Technické podmienky pripojenia SIP PBX k službe Business Trunk. Technické podmienky pripojenia SIP PBX k službe Business Trunk Vypracoval: Peter Hecht Platné od: 1 septembra 2015 Verzia: 70 1 Použitie služby Služba Business Trunk je určená pre pripojenie zákazníckych

More information

Základná(umelecká(škola(Jána(Albrechta Topoľčianska(15

Základná(umelecká(škola(Jána(Albrechta Topoľčianska(15 Základná(umelecká(škola(Jána(Albrechta Topoľčianska(15 851(01(Bra@slava Titl.: Ján(Hrčka Bohrova(11 851(01(Bra@slava V(Bra@slave(21.11.2013 Vec:(Odpoveď(na(informácie(ohľadom(mandátnej(zmluvy(na(základe(Zákona(č.(211/2000(Zb.

More information

INTERFACE SPECIFICATION SIP Trunking. 8x8 SIP Trunking. Interface Specification. Version 2.0

INTERFACE SPECIFICATION SIP Trunking. 8x8 SIP Trunking. Interface Specification. Version 2.0 8x8 Interface Specification Version 2.0 Table of Contents Introduction....3 Feature Set....3 SIP Interface....3 Supported Standards....3 Supported SIP methods....4 Additional Supported SIP Headers...4

More information

JAVA. Sieťové programovanie

JAVA. Sieťové programovanie JAVA Sieťové programovanie Sieťové programovanie Sieťová knižnica jazyka JAVA bola vytvorená podľa súborovej knižnice Zapúzdrovanie pripojení do streamov Multithreading Identifikácia počítača Každý počítač

More information

Kategória školenia Školenia Cisco obsahuje kurzy:

Kategória školenia Školenia Cisco obsahuje kurzy: Kategória školenia Školenia Cisco obsahuje kurzy: Cisco CCNA I - Úvod do počítačových sietí Školenie Cisco CCNA I - Úvod do počítačových sietí je určený záujemcom o počítačové siete a ich budúcim administrátorom.

More information

BGP - duálne prepojenie AS. (primary + backup spoj), s IBGP, cez virtuální L2 linky

BGP - duálne prepojenie AS. (primary + backup spoj), s IBGP, cez virtuální L2 linky BGP - duálne prepojenie AS (primary + backup spoj), s IBGP, cez virtuální L2 linky Peter Jašica Abstrakt: Cieľom tohto projektu je zhotoviť a otestovať funkčnosť BGP s dvojitým prepojením Autonómnych systémov.

More information

Information About SIP Compliance with RFC 3261

Information About SIP Compliance with RFC 3261 APPENDIX A Information About SIP Compliance with RFC 3261 This appendix describes how the Cisco SIP IP phone complies with the IETF definition of SIP as described in RFC 3261. It has compliance information

More information

Podporované grantom z Islandu, Lichtenštajnska a Nórska prostredníctvom Finančného mechanizmu EHP a Nórskeho finančného mechanizmu

Podporované grantom z Islandu, Lichtenštajnska a Nórska prostredníctvom Finančného mechanizmu EHP a Nórskeho finančného mechanizmu Podporované grantom z Islandu, Lichtenštajnska a Nórska prostredníctvom Finančného mechanizmu EHP a Nórskeho finančného mechanizmu Závereč ný workshop projektu INEDU-GOV Inovatívne vzdelávanie pracovníkov

More information

VYLEPŠOVANIE KONCEPTU TRIEDY

VYLEPŠOVANIE KONCEPTU TRIEDY VYLEPŠOVANIE KONCEPTU TRIEDY Typy tried class - definuje premenné a metódy (funkcie). Ak nie je špecifikovaná inak, viditeľnosť členov je private. struct - definuje premenné a metódy (funkcie). Ak nie

More information

Session Initiation Protocol (SIP) Overview

Session Initiation Protocol (SIP) Overview Session Initiation Protocol (SIP) Overview T-110.7100 Applications and Services in Internet 5.10.2010 Jouni Mäenpää NomadicLab, Ericsson Research Contents SIP introduction, history and functionality Key

More information

Compliance with RFC 3261

Compliance with RFC 3261 APPENDIX A Compliance with RFC 3261 This appendix describes how the Cisco Unified IP Phone 7960G and 7940G complies with the IETF definition of SIP as described in RFC 3261. It contains compliance information

More information

BENESTRA - ISDN SLUŽBY Špecifikácia transportných, doplnkových a teleslužieb ISDN siete

BENESTRA - ISDN SLUŽBY Špecifikácia transportných, doplnkových a teleslužieb ISDN siete BENESTRA, s. r. o., Einsteinova 24, 851 01 Bratislava BENESTRA - ISDN SLUŽBY Špecifikácia transportných, doplnkových a teleslužieb ISDN siete Technické parametre Verzia: 1.4 Dátum vydania: 01.12.2014 Informácie

More information

SIP security and the great fun with Firewall / NAT Bernie Höneisen SURA / ViDe, , Atlanta, GA (USA)

SIP security and the great fun with Firewall / NAT Bernie Höneisen SURA / ViDe, , Atlanta, GA (USA) security and the great fun with Firewall / NAT Bernie Höneisen SURA / ViDe, 29.03.2006, Atlanta, GA (USA) 2006 SWITCH Content and Firewall and NAT Privacy / Encryption SpIT / Authentication Identity General

More information

Crestron Mercury. Univerzálny Videokonferenčný a Kolaboračný systém

Crestron Mercury. Univerzálny Videokonferenčný a Kolaboračný systém Crestron Mercury Univerzálny Videokonferenčný a Kolaboračný systém Tradičná malá zasadacia miestnosť CRESTRON Mercury Videokonferenčná miestnosť Možnosť rezervácie miestnosti: Prostredníctvom MS Outlook

More information

Desatinné čísla #1a. Decimal numbers #1b. How much larger is 21,8 than 1,8? Desatinné čísla #2a. Decimal numbers #2b. 14 divided by 0,5 equals...

Desatinné čísla #1a. Decimal numbers #1b. How much larger is 21,8 than 1,8? Desatinné čísla #2a. Decimal numbers #2b. 14 divided by 0,5 equals... Desatinné čísla #1a Mravec išiel 5,5 cm presne na sever, potom 3,4 cm na východ, 1,8 cm na juh, 14,3 cm na západ, 1,3 cm na sever a 10,9 cm na východ. Najmenej koľko cm musí teraz prejsť, aby sa dostal

More information

Sieťové prostriedky na vytváranie VPN. Michal Majerčík 2014

Sieťové prostriedky na vytváranie VPN. Michal Majerčík 2014 Sieťové prostriedky na vytváranie VPN Michal Majerčík 2014 1 Teória VPN sietí Osnova Praktické konfigurácie (Cisco, Fortinet, Juniper, windows...) 2 Čo je to VPN sieť Základ VPN Prečo budujeme VPN siete

More information

Technical specifications for connecting SIP PBX to the Business Trunk service by Slovak Telekom without registration, with static routing.

Technical specifications for connecting SIP PBX to the Business Trunk service by Slovak Telekom without registration, with static routing. Technical specifications for connecting SIP PBX to the Business Trunk service by Slovak Telekom without registration, with static routing Author: Peter Hecht Valid from: 1st January, 2019 Last modify:

More information

N-Squared Software SIP Specialized Resource Platform SIP-SDP-RTP Protocol Conformance Statement. Version 2.3

N-Squared Software SIP Specialized Resource Platform SIP-SDP-RTP Protocol Conformance Statement. Version 2.3 N-Squared Software SIP Specialized Resource Platform SIP-SDP-RTP Protocol Conformance Statement Version 2.3 1 Document Information 1.1 Scope and Purpose This document describes the implementation of the

More information

REPORT DESIGNER 1 VYTVORENIE A ÚPRAVA FORMULÁRA. úprava formulárov v Money S4 / Money S Vytvorenie formulára

REPORT DESIGNER 1 VYTVORENIE A ÚPRAVA FORMULÁRA. úprava formulárov v Money S4 / Money S Vytvorenie formulára REPORT DESIGNER úprava formulárov v Money S4 / Money S5 Informačný systém Money S4/S5 umožňuje upraviť tlačové zostavy tak, aby plne vyhovovali potrebám používateľa. Na úpravu tlačových zostáv slúži doplnkový

More information

LL LED svietidlá na osvetlenie športovísk. MMXIII-X LEADER LIGHT s.r.o. Všetky práva vyhradené. Uvedené dáta podliehajú zmenám.

LL LED svietidlá na osvetlenie športovísk. MMXIII-X LEADER LIGHT s.r.o. Všetky práva vyhradené. Uvedené dáta podliehajú zmenám. LL LED svietidlá na osvetlenie športovísk MMXIII-X LEADER LIGHT s.r.o. Všetky práva vyhradené. Uvedené dáta podliehajú zmenám. LL SPORT LL SPORT je sofistikované vysoko výkonné LED svietidlo špeciálne

More information

TECHNICKÁ UNIVERZITA V KOŠICIACH. Multimediálna elektronická učebnica v programe Toolbook - Prenos hlasu v IP sieťach DIPLOMOVÁ PRÁCA

TECHNICKÁ UNIVERZITA V KOŠICIACH. Multimediálna elektronická učebnica v programe Toolbook - Prenos hlasu v IP sieťach DIPLOMOVÁ PRÁCA TECHNICKÁ UNIVERZITA V KOŠICIACH FAKULTA ELEKTROTECHNIKY A INFORMATIKY Multimediálna elektronická učebnica v programe Toolbook - Prenos hlasu v IP sieťach Pavol SAKÁČ DIPLOMOVÁ PRÁCA 2009 TECHNICKÁ UNIVERZITA

More information

Testovanie bieleho šumu

Testovanie bieleho šumu Beáta Stehlíková FMFI UK Bratislava Opakovanie z prednášky Vygenerujeme dáta Vygenerujeme dáta: N

More information

Understanding SIP exchanges by experimentation

Understanding SIP exchanges by experimentation Understanding SIP exchanges by experimentation Emin Gabrielyan 2007-04-10 Switzernet Sàrl We analyze a few simple scenarios of SIP message exchanges for a call setup between two SIP phones. We use an SIP

More information

Štruktúra údajov pre kontajner XML údajov 1. Dátové prvky pre kontajner XML údajov

Štruktúra údajov pre kontajner XML údajov 1. Dátové prvky pre kontajner XML údajov Štruktúra údajov pre kontajner XML údajov 1. Dátové prvky pre kontajner XML údajov D.4 Kontajner XML údajov (XMLDataContainer) Príloha č. 11 k výnosu č. 55/2014 Z. z. [pridaná novelou č. 275/2014 Z. z.,

More information

1. ELASTIX inštalácia 2 2. Elastix konfigurácia Nastavenie užívateľských kont Pridanie nových užívateľských kont 10 2.

1. ELASTIX inštalácia 2 2. Elastix konfigurácia Nastavenie užívateľských kont Pridanie nových užívateľských kont 10 2. 1. ELASTIX inštalácia 2 2. Elastix konfigurácia 8 2.1 Nastavenie užívateľských kont 9 2.2 Pridanie nových užívateľských kont 10 2.3 InstantMessaging and presence 12 2.4 TLS 12 2.5 Conference 12 3. Záver

More information

Databázy (1) Prednáška 11. Alexander Šimko

Databázy (1) Prednáška 11. Alexander Šimko Databázy (1) Prednáška 11 Alexander Šimko simko@fmph.uniba.sk Contents I Aktualizovanie štruktúry databázy Section 1 Aktualizovanie štruktúry databázy Aktualizácia štruktúry databázy Štruktúra databázy

More information

Košice. Riešenia pre malé a stredné podniky

Košice. Riešenia pre malé a stredné podniky 28.09.2016 Košice Riešenia pre malé a stredné podniky Partnerský program Hewlett Packard Enterprise Partner Ready Výhody - Špeciálne ceny - Partner ready portál - Bezplatné školenia - Registrácia obchodného

More information

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV INFORMAČNÍCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS PROSTŘEDÍ PRO

More information

Návod na odstránenie certifikátov so zrušenou platnosťou

Návod na odstránenie certifikátov so zrušenou platnosťou Návod na odstránenie certifikátov so zrušenou platnosťou Dátum zverejnenia: 7. 11. 2017 Verzia: 1 Dátum aktualizácie: Popis: Tento dokument je určený používateľom, ktorí elektronicky podpisujú dokumenty

More information

SLOVENSKÁ TECHNICKÁ UNIVERZITA V BRATISLAVE FAKULTA ELEKTROTECHNIKY A INFORMATIKY. TECHNOLÓGIA VoIP S VYUŽITÍM PBX ASTERISK

SLOVENSKÁ TECHNICKÁ UNIVERZITA V BRATISLAVE FAKULTA ELEKTROTECHNIKY A INFORMATIKY. TECHNOLÓGIA VoIP S VYUŽITÍM PBX ASTERISK SLOVENSKÁ TECHNICKÁ UNIVERZITA V BRATISLAVE FAKULTA ELEKTROTECHNIKY A INFORMATIKY TECHNOLÓGIA VoIP S VYUŽITÍM PBX ASTERISK BAKALÁRSKA PRÁCA EVIDENČNÉ ČÍSLO: FEI-5408-49912 Študijný program: telekomunikácie

More information

SIP Compliance APPENDIX

SIP Compliance APPENDIX APPENDIX E This appendix describes Cisco SIP proxy server (Cisco SPS) compliance with the Internet Engineering Task Force (IETF) definition of Session Initiation Protocol (SIP) as described in the following

More information

OpenSIPS Workshop. Federated SIP with OpenSIPS and RTPEngine

OpenSIPS Workshop. Federated SIP with OpenSIPS and RTPEngine OpenSIPS Workshop Federated SIP with OpenSIPS and RTPEngine Who are you people? Eric Tamme Principal Engineer OnSIP Hosted PBX Hosted SIP Platform Developers of See: sipjs.com, or https://github.com/onsip/sip.js

More information

Session Initiation Protocol (SIP) Overview

Session Initiation Protocol (SIP) Overview Session Initiation Protocol (SIP) Overview T-110.7100 Applications and Services in Internet 6.10.2009 Jouni Mäenpää NomadicLab, Ericsson Contents SIP introduction, history and functionality Key concepts

More information

Voice over IP (VoIP)

Voice over IP (VoIP) Voice over IP (VoIP) David Wang, Ph.D. UT Arlington 1 Purposes of this Lecture To present an overview of Voice over IP To use VoIP as an example To review what we have learned so far To use what we have

More information

ENSC 833-3: NETWORK PROTOCOLS AND PERFORMANCE. Implement Session Initiation Protocol (SIP) User Agent Prototype

ENSC 833-3: NETWORK PROTOCOLS AND PERFORMANCE. Implement Session Initiation Protocol (SIP) User Agent Prototype ENSC 833-3: NETWORK PROTOCOLS AND PERFORMANCE Final Project Presentation Spring 2001 Implement Session Initiation Protocol (SIP) User Agent Prototype Thomas Pang (ktpang@sfu.ca) Peter Lee (mclee@sfu.ca)

More information

SECURITY BULLETIN Týždeň

SECURITY BULLETIN Týždeň No: B20170926-01V 1 / 13 Dôležitosť Nízka Stredná Vysoká Kritická CVSS skóre: 7.7 Cisco Small Business Managed Switches Denial of Service Vulnerability Zraniteľnosť v systéme Secure Shell (SSH) softvéru

More information

Microsoft Azure platforma pre Cloud Computing. Juraj Šitina, Microsoft Slovakia

Microsoft Azure platforma pre Cloud Computing. Juraj Šitina, Microsoft Slovakia Microsoft Azure platforma pre Cloud Computing Juraj Šitina, Microsoft Slovakia m Agenda Cloud Computing Pohľad Microsoftu Predstavujeme platformu Microsoft Azure Benefity Cloud Computingu Microsoft je

More information

Slovenská technická univerzita v Bratislave Fakulta informatiky a informačných technológií FIIT-XXXX-XXXXX

Slovenská technická univerzita v Bratislave Fakulta informatiky a informačných technológií FIIT-XXXX-XXXXX Toto je titulný list práce. Je súčasťou každej priebežnej či záverečnej správy (BP, DP) Slovenská technická univerzita v Bratislave Fakulta informatiky a informačných technológií FIIT-XXXX-XXXXX evidenčné

More information

Just how vulnerable is your phone system? by Sandro Gauci

Just how vulnerable is your phone system? by Sandro Gauci Just how vulnerable is your phone system? by Sandro Gauci $ whoami Sandro Gauci (from.mt) Security researcher and Pentester SIPVicious / VOIPPACK for CANVAS VOIPSCANNER.com Not just about VoIP EnableSecurity

More information

REALIZÁCIA VIRTUÁLNEHO LABORATÓRIA S VYUŽITÍM XPC TARGET-u

REALIZÁCIA VIRTUÁLNEHO LABORATÓRIA S VYUŽITÍM XPC TARGET-u REALIZÁCIA VIRTUÁLNEHO LABORATÓRIA S VYUŽITÍM XPC TARGET-u I. Masár Department of Electrical Engineering Control Systems Engineering Group, University of Hagen Universitätsstr. 27, 580 97 Hagen, Germany

More information

Abstract. Avaya Solution & Interoperability Test Lab

Abstract. Avaya Solution & Interoperability Test Lab Avaya Solution & Interoperability Test Lab Application Notes for Configuring SIP Trunking between Sotel IP Services SIP Edge Advanced SIP Trunking Solution and an Avaya IP Office Telephony Solution Issue

More information

Session Initiation Protocol (SIP) Basic Description Guide

Session Initiation Protocol (SIP) Basic Description Guide Session Initiation Protocol (SIP) Basic Description Guide - 1 - Table of Contents: DOCUMENT DESCRIPTION... 4 SECTION 1 NETWORK ELEMENTS... 4 1.1 User Agent... 4 1.2 Proxy server... 4 1.3 Registrar... 4

More information

VoIP Security Threat Analysis

VoIP Security Threat Analysis 2005/8/2 VoIP Security Threat Analysis Saverio Niccolini, Jürgen Quittek, Marcus Brunner, Martin Stiemerling (NEC, Network Laboratories, Heidelberg) Introduction Security attacks taxonomy Denial of Service

More information

Rýchlosť Mbit/s (download/upload) 15 Mbit / 1 Mbit. 50 Mbit / 8 Mbit. 80 Mbit / 10 Mbit. 10 Mbit / 1 Mbit. 12 Mbit / 2 Mbit.

Rýchlosť Mbit/s (download/upload) 15 Mbit / 1 Mbit. 50 Mbit / 8 Mbit. 80 Mbit / 10 Mbit. 10 Mbit / 1 Mbit. 12 Mbit / 2 Mbit. Fiber 5 Mbit ** 5 Mbit / Mbit 5,90 Fiber 50 Mbit * 50 Mbit / 8 Mbit 9,90 Fiber 80 Mbit * 80 Mbit / Mbit 5,90 Mini Mbit* Mbit / Mbit 9,90 Klasik 2 Mbit* 2 Mbit / 2 Mbit Standard 8 Mbit* 8 Mbit / 3Mbit Expert

More information

SIP v malých telekomunikačných systémoch. Convergence. A matter of lifestyle.

SIP v malých telekomunikačných systémoch. Convergence. A matter of lifestyle. SIP v malých telekomunikačných systémoch Convergence. A matter of lifestyle. Obsah Prehľad portfólia malých komunikačných systémov Aastra BusinessPhone - Úvod - Prehľad koncových telefónnych aparátov -

More information

VLSM a CIDR. CCNA2 Kapitola Cisco Systems, Inc. All rights reserved. Cisco Public 1

VLSM a CIDR. CCNA2 Kapitola Cisco Systems, Inc. All rights reserved. Cisco Public 1 VLSM a CIDR CCNA2 Kapitola 6 1 Trošku histórie Pred rokom 1981 IP adresy používali na špecifikáciu siete len prvých 8 bitov Rok1981, RFC 791 Zaviedol adresný priestor s tromi triedami adries Polovica 90

More information

Session Initiation Protocol (SIP)

Session Initiation Protocol (SIP) Session Initiation Protocol (SIP) Introduction A powerful alternative to H.323 More flexible, simpler Easier to implement Advanced features Better suited to the support of intelligent user devices A part

More information

SIP Trunking & Peering Operation Guide

SIP Trunking & Peering Operation Guide SIP Trunking & Peering Operation Guide For OfficeServ v2.3.0 SIP Trunking & Peering Operation Guide For Samsung OfficeServ Oct 5, 2010 doc v2.4.0 Sungwoo Lee Senior Engineer sungwoo1769.lee@samsung.com

More information

Textový formát na zasielanie údajov podľa 27 ods. 2 písm. f) zákona

Textový formát na zasielanie údajov podľa 27 ods. 2 písm. f) zákona Popis textového formátu a xsd schémy na zasielanie údajov podľa 27 ods. 2 písm. f) zákona (formu na zaslanie údajov si zvolí odosielateľ údajov) Textový formát na zasielanie údajov podľa 27 ods. 2 písm.

More information

Chapter 3: IP Multimedia Subsystems and Application-Level Signaling

Chapter 3: IP Multimedia Subsystems and Application-Level Signaling Chapter 3: IP Multimedia Subsystems and Application-Level Signaling Jyh-Cheng Chen and Tao Zhang IP-Based Next-Generation Wireless Networks Published by John Wiley & Sons, Inc. January 2004 Outline 3.1

More information

RFC 3665 Basic Call Flow Examples

RFC 3665 Basic Call Flow Examples http://www.tech-invite.com RFC 3665 Basic Call Flow Examples Alice's SIP Bob's SIP 3.8 Unsuccessful No Answer INVITE CANCEL ACK 100 Trying 180 Ringing 200 OK 487 Request Terminated INVITE CANCEL ACK 100

More information

How to set FAX on asterisk

How to set FAX on asterisk How to set FAX on asterisk Address: 10/F, Building 6-A, Baoneng Science and Technology Industrial Park, Longhua New District, Shenzhen, Guangdong,China 518109 Tel: +86-755-82535461, 82535095, 82535362

More information

Doručovanie multimedialného obsahu (Nástroje, metódy a riešenia) František Jakab November 2008

Doručovanie multimedialného obsahu (Nástroje, metódy a riešenia) František Jakab November 2008 Doručovanie multimedialného obsahu (Nástroje, metódy a riešenia) František Jakab November 2008 LPS - CNL Laboratórium Počítačových ových Sietí Computer Networks Laboratory» CNL!= Cisco Network Laboratory

More information

Reserving N and N+1 Ports with PCP

Reserving N and N+1 Ports with PCP Reserving N and N+1 Ports with PCP draft-boucadair-pcp-rtp-rtcp IETF 83-Paris, March 2012 M. Boucadair and S. Sivakumar 1 Scope Defines a new PCP Option to reserve a pair of ports (N and N+1) in a PCP-controlled

More information

Coordinates ordering in parallel coordinates views

Coordinates ordering in parallel coordinates views Univerzita Komenského v Bratislave Fakulta matematiky, fyziky a informatiky Coordinates ordering in parallel coordinates views Bratislava, 2011 Lukáš Chripko Univerzita Komenského v Bratislave Fakulta

More information

Signaling trace on GSM/CDMA VoIP Gateway

Signaling trace on GSM/CDMA VoIP Gateway Signaling trace on GSM/CDMA VoIP Gateway Part1. Login the gateway & General Knowledge the command This is a document for some customers who need to get the logs on gateway Tips: The document is fit for

More information

INTERNET. História internetu

INTERNET. História internetu INTERNET 1 Úvod Internet je celosvetová počítačová sieť. Je všade okolo, ale nepatrí nikomu, nikto ho neriadi. Internet predstavuje najväčšie množstvo informácií dostupných z jedného miesta. Internet tvoria

More information

Using Genband E911 on Yealink IP Phones

Using Genband E911 on Yealink IP Phones Introduction This guide introduces how to configure the Genband Enhanced 911 (E911) feature on Yealink IP phones. The features introduced in this guide apply to Yealink SIP-T54S, SIP-T52S, SIP-T48G/S,

More information

TSIN02 - Internetworking

TSIN02 - Internetworking Lecture 8: SIP and H323 Litterature: 2004 Image Coding Group, Linköpings Universitet Lecture 8: SIP and H323 Goals: After this lecture you should Understand the basics of SIP and it's architecture Understand

More information

ZACHOVÁNÍ VALIDITY MS EXCHANGE HLAVIČEK NA FILTRUJÍCÍM SMTP PROXY-SERVERU PRESERVING VALIDITY OF MS EXCHANGE HEADERS ON FILTERING SMTP PROXY-SERVER

ZACHOVÁNÍ VALIDITY MS EXCHANGE HLAVIČEK NA FILTRUJÍCÍM SMTP PROXY-SERVERU PRESERVING VALIDITY OF MS EXCHANGE HEADERS ON FILTERING SMTP PROXY-SERVER VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV INFORMAČNÍCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS ZACHOVÁNÍ VALIDITY

More information

BAKALÁRSKA PRÁCA. Ľuboš Magic Telefón do embedded systému

BAKALÁRSKA PRÁCA. Ľuboš Magic Telefón do embedded systému Univerzita Karlova v Prahe Matematicko-fyzikálna fakulta BAKALÁRSKA PRÁCA Ľuboš Magic Telefón do embedded systému Ústav formálnej a aplikovanej lingvistiky Vedúci bakalárskej práce: Mgr. David Kolovratník

More information

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ ÚSTAV TELEKOMUNIKACÍ FACULTY OF ELECTRICAL ENGINEERING AND COMMUNICATION DEPARTMENT OF TELECOMMUNICATIONS

More information

PCP NAT64 Experiments

PCP NAT64 Experiments PCP NAT64 Experiments I-D. draft-boucadair-pcp-nat64-experiments IETF 85-Atlanta, November 2012 Authors: M. Ait Abdesselam, M. Boucadair, A. Hasnaoui, J. Queiroz Presenter: J. Queiroz 1 Objectives of this

More information

SIPPING Working Group A. Johnston, Ed. Internet-Draft Avaya Intended status: BCP R. Sparks Expires: January 12, 2009 Estacado Systems C. Cunningham S.

SIPPING Working Group A. Johnston, Ed. Internet-Draft Avaya Intended status: BCP R. Sparks Expires: January 12, 2009 Estacado Systems C. Cunningham S. SIPPING Working Group A. Johnston, Ed. Internet-Draft Avaya Intended status: BCP R. Sparks Expires: January 12, 2009 Estacado Systems C. Cunningham S. Donovan Cisco Systems K. Summers Sonus July 11, Status

More information

ICE: the ultimate way of beating NAT in SIP

ICE: the ultimate way of beating NAT in SIP AG Projects Saúl Ibarra Corretgé AG Projects Index How NAT afects SIP Solving the problem In the client In the network ICE: the ultimate solution Why ICE doesn't didn't work Fixing ICE in the server OpenSIPS

More information

Technical specifications for connecting SIP PBX to the Business Trunk service by Slovak Telekom with registration of pilot account.

Technical specifications for connecting SIP PBX to the Business Trunk service by Slovak Telekom with registration of pilot account. Technical specifications for connecting SIP PBX to the Business Trunk service by Slovak Telekom with registration of pilot account Author: Peter Hecht Valid from: 1st January, 2019 Last modify: 29th december,

More information

SIP Reliable Provisional Response on CUBE and CUCM Configuration Example

SIP Reliable Provisional Response on CUBE and CUCM Configuration Example SIP Reliable Provisional Response on CUBE and CUCM Configuration Example Document ID: 116086 Contributed by Robin Cai, Cisco TAC Engineer. May 16, 2013 Contents Introduction Prerequisites Requirements

More information

Overview of SIP. Information About SIP. SIP Capabilities. This chapter provides an overview of the Session Initiation Protocol (SIP).

Overview of SIP. Information About SIP. SIP Capabilities. This chapter provides an overview of the Session Initiation Protocol (SIP). This chapter provides an overview of the Session Initiation Protocol (SIP). Information About SIP, page 1 How SIP Works, page 4 How SIP Works with a Proxy Server, page 5 How SIP Works with a Redirect Server,

More information

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ TESTOVÁNÍ ODOLNOSTI IP PBX PROTI ÚTOKŮM S VYUŽITÍM TESTERU SPIRENT AVALANCHE

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ TESTOVÁNÍ ODOLNOSTI IP PBX PROTI ÚTOKŮM S VYUŽITÍM TESTERU SPIRENT AVALANCHE VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ ÚSTAV TELEKOMUNIKACÍ FACULTY OF ELECTRICAL ENGINEERING AND COMMUNICATION DEPARTMENT OF TELECOMMUNICATIONS

More information

TOPOLOGIE SÍTÍ A JEJICH MONITOROVÁNÍ

TOPOLOGIE SÍTÍ A JEJICH MONITOROVÁNÍ VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ ÚSTAV TELEKOMUNIKACÍ FACULTY OF ELECTRICAL ENGINEERING AND COMMUNICATION DEPARTMENT OF TELECOMMUNICATIONS

More information

Overené riešenia.

Overené riešenia. www.eset.sk Overené riešenia. Ultra-silná autentifikácia pre ochranu prístupu do siete a vašich dát ESET Secure Authentication poskytuje efektívnu autentifikáciu, ktorá ochráni vzdialený prístup do vašej

More information

BENESTRA - TÓNY A HLÁSKY

BENESTRA - TÓNY A HLÁSKY BENESTRA, s. r. o., Einsteinova 24, 851 01 Bratislava BENESTRA - TÓNY A HLÁSKY Špecifikácia tónov a hlások pre telefónnu službu Technické parametre Verzia: 1.4 Dátum vydania: 01.12.2014 Informácie uvedené

More information

D.Signer prostriedok pre vytváranie zaručeného elektronického podpisu. Inštalačná príručka

D.Signer prostriedok pre vytváranie zaručeného elektronického podpisu. Inštalačná príručka D.Signer prostriedok pre vytváranie zaručeného elektronického podpisu Inštalačná príručka Obsah 1 Predpoklady pre inštaláciu D.Signer... 3 1.1 Inštalácia.NET Framework... 3 1.1.1 Windows 8, 8.1... 4 1.1.2

More information

Secure Telephony Enabled Middle-box (STEM)

Secure Telephony Enabled Middle-box (STEM) Report on Secure Telephony Enabled Middle-box (STEM) Maggie Nguyen 04/14/2003 Dr. Mark Stamp - SJSU - CS 265 - Spring 2003 Table of Content 1. Introduction 1 2. IP Telephony Overview.. 1 2.1 Major Components

More information

GSM VoIP Gateway Series

GSM VoIP Gateway Series VoIP Gateway Series SIP Protocol Debugging Service Overview www.addpac.com AddPac Technology Sales and Marketing Contents? Network Diagram for SIP Debugging? SIP Debugging Access Method via Console Port?

More information

Voice over IP Consortium

Voice over IP Consortium Voice over IP Consortium Version 1.6 Last Updated: August 20, 2010 121 Technology Drive, Suite 2 University of New Hampshire Durham, NH 03824 Research Computing Center Phone: +1-603-862-0186 Fax: +1-603-862-4181

More information

SMARTPHONE FAKULTA INFORMAČNÍCH TECHNOLOGIÍ BRNO UNIVERSITY OF TECHNOLOGY FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS

SMARTPHONE FAKULTA INFORMAČNÍCH TECHNOLOGIÍ BRNO UNIVERSITY OF TECHNOLOGY FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV POČÍTAČOVÝCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS ZABEZPEČENÁ KOMUNIKACE

More information

a. Draw a network diagram, showing how a telephone in the US would make calls to a telephone on Deception Island. (15 points).

a. Draw a network diagram, showing how a telephone in the US would make calls to a telephone on Deception Island. (15 points). TSM 350 IP Telephony Fall 2004 E Eichen Exam 1 (Midterm): November 10 Solutions 1 True or False: a Call signaling in a SIP network is routed on a hop-by-hop basis, while call signaling in an H323 network

More information

Nové komunikačné trendy v dátových centrách

Nové komunikačné trendy v dátových centrách Nové komunikačné trendy v dátových centrách Martin Vozár Roman Benko 25. november 2009 Cisco Expo, Bratislava Agenda 1. Konvergovaná architektúra 2. Komponenty architektúry 3. AVNET demo LAB 2 / 17 Konvergovaná

More information

Multimedia Communication

Multimedia Communication Multimedia Communication Session Description Protocol SDP Session Announcement Protocol SAP Realtime Streaming Protocol RTSP Session Initiation Protocol - SIP Dr. Andreas Kassler Slide 1 SDP Slide 2 SDP

More information

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE DIPLOMOVÁ PRÁCE

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE DIPLOMOVÁ PRÁCE ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA ELEKTROTECHNICKÁ DIPLOMOVÁ PRÁCE 2015 Patrik Havrila ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická Katedra telekomunikační techniky Bezpečnost

More information

Implementácia proxy riešenia ústavu

Implementácia proxy riešenia ústavu SLOVENSKÁ TECHNICKÁ UNIVERZITA V BRATISLAVE Fakulta chemickej a potravinárskej technológie Evidenčné číslo: FCHPT-5414-39583 Implementácia proxy riešenia ústavu Diplomová práca 2013 Bc. Branislav Mitterpach

More information