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

Transcription

1 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA ELEKTROTECHNICKÁ DIPLOMOVÁ PRÁCE 2015 Patrik Havrila

2

3 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická Katedra telekomunikační techniky Bezpečnost SIP PBX Leden 2015 Diplomant: Vedoucí práce: Patrik Havrila Ing. Ján Kučerák

4 Čestné prehlásenie Čestne vyhlasujem, ţe predkladanú diplomovú prácu Bezpečnost SIP PBX som napísal samostatne, pod odborným vedením vedúceho diplomovej práce, konzultanta a za pouţitia literatúry uvedenej v bibliografii. Ďalej prehlasujem, ţe nemám ţiadne námietky proti poţičiavaniu alebo zverejňovaniu mojej diplomovej práce alebo jej časti so súhlasom katedry. Dátum: podpis diplomanta

5

6 Abstrakt v SJ V tejto diplomovej práci je riešená problematika VoIP. Konkrétne ide o protokol SIP. Zaoberá sa zhodnotením moţností nasadenia na trhu dostupných zariadení SBC. Zhrňuje všeobecný pohľad na SBC, ujasňuje dôvody a moţnosti jeho pouţitia na úrovni Network-to-Network Interface a User-to-Network Interface. Popisuje základné SIP útoky a následné zabezpečenie proti ním. Takisto popisuje bezpečnostné mechanizmy a moţnosti zabezpečenia Avaya Aura architektúry, ktorá sa skladá zo serverov Avaya Session Manager a Avaya System Manager. Sústredí sa aj na jej praktické zabezpečenie, a to pomocou všetkých dostupných bezpečnostných prvkov vrátane Avaya Session Border Controller for Enterprise. Kľúčové slová VoIP, SIP, NGN, Unnified Communications, Avaya Aura, Session Border Controller, Session Manager, System Manager Abstrakt v AJ Main topic of this diploma thesis is the VoIP especially the SIP. It deals with the assessment of SBC deployment available on the market. This diploma thesis summarizes SBC as a product from all of the possible views to one general description. Clarifies possible usage and security threads at Network-to-Network Interface and Userto-Network Interface. Describes basic SIP attacks and main defense against them. Also describes security mechanisms and security options to secure Avaya Aura architecture consist of Avaya Session Manager and Avaya System Manager servers. The aim is on practical securing by all available secure features included by Avaya Session Border Controller for Enterprise. Kľúčové slová v AJ VoIP, SIP, NGN, Unnified Communications, Avaya Aura, Session Border Controller, Session Manager, System Manager

7 Poďakovanie Týmto by som chcel poďakovať vedúcemu diplomovej práce Ing. Jánovi Kučerákovi za cenné rady pri písaní práce. Ďalej by som chcel poďakovať môjmu konzultantovi Ing. Josefovi Čechovi za všetku poskytnutú pomoc a skúsenosti. Takisto by som chcel poďakovať aj firme Algotech za poskytnutie všetkého potrebného vybavenia k diplomovej práci.

8 Obsah Zoznam obrázkov... 9 Zoznam tabuliek Zoznam symbolov a skratiek Slovník termínov Úvod Bezpečnosť VoIP Typy útokov proti SIP Denial-of-Service Odmietnutie sluţby Toll Fraud Theft of the Service Eavesdropping Zabezpečenie protokolu SIP Heslo a kontrola prístupu Šifrovanie Autentizácia a autorizácia BYOD Session Border Controller Potreba SBC NNI - SIP trunk k operátorovi UNI - Remote workers Moţnosti zapojenia SBC Topológia Two-wire Topológia One-wire Demilitarized Zone - DMZ SBC High Availability (HA) Vyber správneho SBC Avaya Aura architektúra Avaya Aura Session Border Controller for Enterprise Funkcie Avaya SBCE Bezpečnostné špecifikácie Avaya SBCE Avaya Aura Session Manager Bezpečnosť Avaya Aura System Manager... 43

9 3.4 SIP Klienti Praktická časť Implementácia Avaya Aura a Inštalácia Avaya SBCE Adresovanie siete Inštalácia a základné nastavenie SBC Moţnosti útoku a spôsoby zabezpečenia Návrh bezpečnej architektúry Zabezpečenie komunikácie Kontrola prístupu (Autorizácia a autentifikácia) Šifrovanie Nastavenie SIP firewallu v SM Nastavenie Firewallu v SBC Topology hiding Ďalšie zabezpečenie Záver Zoznam použitej literatúry Príloha A Ukážky z útokov Priloha B Certifikáty... Chyba! Záloţka není definována.

10 Zoznam obrázkov Obr. 1 Klasifikácia rôznych typov DoS útoku [4] Obr. 2 Hop-by-Hop TLS medzi UA a Proxy serverom Obr. 3 Registračná procedúra pomocou digest-autentizácie Obr. 4 Vnútorná architektúra SBC Obr. 5 Typy SBC Obr. 6 SIP trunk [15] Obr. 7 Útok z pohľadu útočníka bez SBC Obr. 8 Útok z pohľadu útočníka s nasadeným SBC Obr. 9 Remote Workers [15] Obr. 10 Zapojenie Two-wire [15] Obr. 11 Zapojenie One-wire [15] Obr. 12 DMZ Obr. 13 Detailné zapojenie Avaya Aura SBCE v HA [15] Obr. 14 Zjednodušené zapojenie v HA [15] Obr. 15 Avaya Aura architektúra Obr. 16 Ochrana IP-PBX pred útokmi Obr. 17 SM ako centrum SIP siete [20] Obr. 18 Fyzické zapojenie SBC [26] Obr. 19 Základné nastavenie SBC Obr. 20 Natavenie Server Flows Obr. 21 Nastavenie Subscriber Flows Obr. 22 SBC za Firewallom Obr. 23 SBC pred Firewallom Obr. 24 Bezpečné zapojenie Obr. 25 Signalizácia pri zapojení len jedného rozhrania Obr. 26 Single Source DoS Obr. 27 Phone DoS/DDoS Obr. 28 Stealth DoS/DDoS Obr. 29 Call Walking Obr. 30 Domain DoS Obr. 31 Topology hiding

11 Zoznam tabuliek Tab. 1 Bezpečnostné vrstvy [1] Tab. 2 Špecifikácie Avaya Aura podľa jednotlivých verzií [20] Tab. 3 Parametre počtu konkurenčných hovorov pre Avaya SBCE [15] Tab. 4 Zoznam pouţitých portov [22] Tab. 5 Inštalované Scrubber balíčky v Avaya SBCE [21] Tab. 6 Porovnanie SM a SBC pre pripojenie k SIP operátorovi [23] Tab. 7 Kapacita SMGR [25] Tab. 8 Adresovanie siete Tab. 9 Doby trvania prelomenia hesla Tab. 10 Nastavenie Firewallu Zoznam Grafov Graf 1 Závislosť vyťaţenie CPU SM od času s vypnutým SIP firewallom Graf 2 Závislosť počtu správ od času s vypnutým SM SIP firewallom Graf 3 Pomer úspešných a neúspešných hovorov počas simulácie DoS útoku Graf 4 Závislosť vyťaţenia CPU SM od času so zapnutým SIP firewallom Graf 5 Závislosť vyťaţenia CPU SBC od času s vypnutým SBC SIP firewallom Graf 6 Závislosť vyťaţenia CPU SM od času so zapojeným SBC

12 Zoznam symbolov a skratiek ASBCE B2BUA BYOD CA CM DDoS DMZ DNS DoS EMS FTP HA HTTP IP LAN NAT NGN NNI PBX PSTN RPM RTP SBC SIP SM SMGR SRTP TCP TLS UA UAC UAS UDP UNI URI VLAN VoIP VPN WAN Avaya Session Border Controller for Enterprise Back-to-back User Agent Bring Your Own Device Certifikačná autorita Communication Manager Distributed Denial of Service Demilizarizovaná zóna Domain Name System Denial of Service Element Management System File transfer Protocol High Availability Hypertext Transfer Protocol Internet Protocol Local Area Network Network Address Translation Next Generation Network Network to Network Interface Private Branch Exchange Public Switched Telephony Network Red Hat Package Manager Real-time Transport Protocol Session Border Controller Session Initiation Protocol Session Manager System Manager Secure Real-time Transport Protocol Transmission Control Protocol Transport Layer Security User Agent User Agent Client User Agent Server User Datagram Protocol User to Network Interface Uniform Resource Identifier Virtual Local Area Network Voice over Internet Protocol Virtual Private Network Wide Area Network 11

13 Slovník termínov Firewall je sieťové zariadenie alebo softvér, ktorého úlohou je oddeliť siete s rôznymi prístupovými právami a kontrolovať dátový tok medzi týmito sieťami. Kodek je počítačový program, ktorý dokáţe transformovať dátový tok alebo signál. Slovo vzniklo zloţením počiatočných slov kodér a dekodér resp. kompresia a dekompresia. Koncové zariadenie je zariadenie, ktoré je pouţité ako rozhranie medzi človekom a komunikačnou sieťou. Multimédia je označenie pre digitálny obsah, ktoré je kombináciu viacerých druhov audiovizuálneho obsahu. Paket označuje v informatike blok dát prenášaný v počítačových sieťach zaloţených na prepojovaní paketov. Rozhranie je bod, v ktorom je vytvorené spojenie medzi dvoma elementmi tak, aby spolu mohli navzájom pracovať. Server je v informatike všeobecne označenie pre počítač, ktorý poskytuje nejaké sluţby, alebo počítačový program, ktorý tieto sluţby realizuje. SIP Proxy je zariadenie, ktoré smeruje SIP poţiadavku na správne miesto, autentizuje, autorizuje uţívateľov k rôznym sluţbám a poskytuje rôzne sluţby. SIP Redirect server je user agent server, ktorý generuje 3xx odpovede na poţiadavky ktoré prijme, nasmerovaním klienta ku kontaktovaniu inej mnoţiny URI adries. SIP registrar je server ktorý prijme SIP REGISTER poţiadavku a uloţí ju do databázy známej ako Location Service. SIP Trunk je spôsob pripojenia privátnej ústredne do internetu. SIP URI je adresná schéma signalizačného protokolu SIP, ktorá umoţňuje volanie ostaným osobám. Telefónna ústredňa je zariadenie, ktoré zaisťuje spojovanie telefónnych hovorov. VoIP sieť je systém navzájom prepojených VoIP elementov v počítačovej sieti, ktoré medzi sebou komunikujú signalizačnými protokolmi. 12

14 Úvod V diplomovej práci sa budem zaoberať aktuálnym zhodnotením nasadenia SBC do NGN architektúry. Popíšem aktuálny stav a spôsob zabezpečenia PBX pracujúcich na protokole SIP, konkrétne Avaya Aura architektúru. Budem sa zaoberať všetkými dostupnými prvkami, ktoré systém zabezpečujú. Diplomová práca bude predpokladať základné znalosti z oblasti SIP signalizačného protokolu. Pokúsim sa vecne zodpovedať na otázky, ktoré by si mohla klásť organizácia alebo firma rozhodujúca sa nad implementáciou SBC do praxe. Budem tieţ riešiť otázky ohľadom samotného SBC, i samotné bezpečnostné hľadisko SBC. V texte sa preto nebudem podrobne zaoberať základnými vlastnosťami protokolu SIP, ale svoju pozornosť zameriam na praktické zabezpečenie Avaya Aura NGN siete. Práca je rozdelená do štyroch kapitol, jednotlivé kapitoly sa členia na teoretickú a praktickú časť. V úvode práce oboznámim čitateľa s čo najširším spektrom bezpečnostných otázok, spomeniem tieţ všeobecné bezpečnostné mechanizmy protokolu SIP a prejdem aţ k tým, ktoré Avaya priamo ponúka. Cieľom teoretickej časti bude popísanie aktuálneho stavu zabezpečenia PBX systémov pracujúcich na protokole SIP. Priblíţim architektúru zapojenia z pohľadu bezpečnosti, otestujem jednotlivé metódy zabezpečenia a následne zhodnotím ochranu systému. V praktickej časti práce ponúknem aj návod, ako nastaviť základné zabezpečenie a to v kombinácií Avaya Aura Session Manager a Avaya Session Border Controller for Enterprise. V prvej kapitole sa budem zaoberať celkovou VoIP bezpečnosťou, opíšem základné útoky a moţnosti zabezpečenia protokolu SIP. Spomeniem aj najváţnejšie útoky akými sú DoS, Toll Fraud a Eavesdropping. Z pohľadu VoIP bezpečnosti spomeniem i čoraz rozšírenejší trend BYOD, ktorého implementáciu ponúka aj Avaya Session Border Controller for Enterprise, a ktorý tak zvyšuje atraktivitu jeho pouţitia. Druhá kapitola bude patriť SBC, ktoré zadefinujem, popíšem jeho potrebu, moţnosti zapojenia a v neposlednom rade aj jeho správny výber. Táto kapitola vysvetľuje čo vlastne pojem SBC znamená a čo môţe SBC poskytnúť. Na SBC sa budem pozerať hlavne z bezpečnostného hľadiska, ale popíšem aj všetky moţné funkcie SBC. Spolu s prvou kapitolou budú tieto dve kapitoly tvoriť teoretický základ diplomovej práce, ktorý dopomôţe k lepšiemu porozumeniu praktickej časti práce. V tretej kapitole rozoberiem pojem Avaya Aura. Popíšem jednotlivé prvky hlavne z pohľadu bezpečnosti. Zadefinujem Avaya Aura Session Border Controller for Enterprise, ktorý je ochranným prvkom celej Avaya Aura architektúry. Poviem o tom, ako a kam ho v sieti uloţiť. Malú časť kapitoly venujem aj SIP klientom od firmy Avaya. Táto kapitola bude chýbajúcim kúskom skladačky medzi teoretickou a praktickou časťou, ktorá ozrejmí pouţitú Avaya technológiu, jej vlastnosti a katalógové informácie. Posledná, štvrtá, kapitola tvorí praktickú časť diplomovej práce. Popíšem implementáciu testovacej Avaya Aura architektúry i implementáciu a konfiguráciu Avaya Aura SBCE pre ochranu trunkov a vnútornej siete. Štvrtá kapitola diplomovej práce sa prelína s diplomovou prácou môjho kolegu, Ondru Kováře, kde testovanie jednotlivých metód zabezpečenia bude našim spoločným bodom. Ondra Kovář bude na navrhnutú architektúru útočiť a ja sa budem snaţiť jeho útokom ubrániť. A tak budeme skúmať celkový dopad rôznych útokov na architektúru 13

15 Avaya Aura. Na základe získaných výsledkov zhodnotím moţnosti zabezpečenia tejto architektúry a pokúsim sa navrhnúť prípadné zlepšenia jej ochrany. 14

16 1 Bezpečnosť VoIP Na trhu, v oblasti telekomunikácií, sa stávame svedkami kedy je technológia VoIP stále populárnejšou. S týmto spôsobom komunikácie sa dostáva do popredia aj protokol SIP. Protokol SIP slúţi ako dorozumievací prostriedok na vytváranie, modifikáciu a ukončovanie relácií v IP sieťach. Zahŕňa telefónne hovory, konferencie a multimediálny prenos hlasu, videa a správ. O tento protokol sa začína zaujímať stále väčšie mnoţstvo ľudí, či uţ ide o sieťových odborníkov, pracujúcich pre poskytovateľov dátových sluţieb, malých prevádzkovateľov VoIP pobočkových ústrední alebo len o obyčajných ľudí, ktorý sa týmto spôsobom snaţia zníţiť svoje výdavky spojené s telefonovaním. Pri takejto narastajúcej populárnosti je veľmi dôleţité zaoberať sa aj otázkou bezpečnosti v IP telefónii. Tá je dnes výzvou, a to hlavne preto, lebo je priamo pripojená k internetu, ktorý je z pohľadu zabezpečenia dát a ochrany súkromia hrozbou. Kaţdý kto sa zaoberá problematikou bezpečnosti vie, ţe pripojenie k internetu je rizikom. Exituje mnoho prípadov kedy boli internetové sluţby kompromitované, boli ukradnuté/zneuţité citlivé informácie alebo sa vyskytla nedostupnosť sluţby z dôvodu jej zahltenia. Netreba sa nechať zmiasť tým, ţe sofistikované bezpečnostné riešenia dokáţu zabrániť útokom na sieť. Dokonca aj virtuálne hradby najbezpečnejších sietí sveta čelia útokom a neraz aj podľahnú. To ale pomáha identifikovať slabé miesta a zaujať voči ním patričné stanovisko. Preto je štúdium zraniteľnosti SIP protokolu dôleţitou súčasťou, ktorá by mala viesť k lepšiemu porozumeniu VoIP a hlavne k zníţeniu bezpečnostného rizika. V tejto oblasti je aktívna organizácia IETF, ktorá vyvíja a neustále pridáva rôzne vylepšenia a záplaty proti sieťovým útokom. Tie prispievajú k lepšiemu a bezpečnejšiemu chodu protokolu SIP. Veľa zostáva priamo na pleciach prevádzkovateľov sietí a sieťových administrátorov, ktorí si týchto záplat a vylepšení musia byť vedomí. V problematike bezpečnosti je úplne v poriadku ak sa firma alebo organizácia stane do určitej miery paranoidnou. Pod paranoidnosťou myslím, ţe firma hľadá všetky slabé miesta a moţnosti odkiaľ útok môţe prísť. Príčinou útoku môţe byť LAN sieť, nezabezpečené servery, bezpečnostné diery v serverových operačných systémoch, ale aj nepremyslený dizajn architektúry, infraštruktúry, ponechaná základná konfigurácia alebo základné heslá. Tieto slabé miesta je potrebné v čo najkratšom čase odhaliť a zabezpečiť. Existuje veľa moţností zabezpečenia VoIP siete - autentizácia, šifrovanie paketov a bezpečná architektúra. Jednou z nich je aj nasadenie SBC ako tzv. SIP firewall, ktorý bráni neţiaducej SIP prevádzke preniknúť do vnútra siete, a ktorým sa budem ďalej v tejto diplomovej práci zaoberať. Nebolo by však rozumné myslieť si, ţe jediné SBC, ako bezpečnostný prvok zabráni všetkým útokom, pretoţe nejaká časť príde určite aj zvnútra. Preto bezpečnostné riešenie musí byť implementované tak zvonku ako aj zvnútra siete. Na úrovni NNI a rovnako aj na úrovni UNI. Dokonca aj vonkajšie útoky môţu vyuţiť nesprávnu konfiguráciu siete alebo nejaké slabé miesta, ktoré v konečnom dôsledku môţu a nemusia mať s protokolom SIP nič spoločné. 15

17 1.1 Typy útokov proti SIP Ako také útoky vyzerajú? Existuje mnoho tipov útokov, niektoré sú sieťové, iné útočia na slabiny šifrovacieho algoritmu, operačného systému, fyzického zapojenia alebo bezpečnostných pravidiel danej organizácie. SIP sa nachádza aţ na samom vrchu tejto pomyselnej pyramídy (Tab. 1). Preto jeho bezpečnosť sa spolieha na všetky tieto vrstvy pod ním a je taká silná ako ten najslabší prvok. Slabiny a zabezpečenia týchto vrstiev sú dnes uţ celkom známe, popísané a pravidelne sa vyvíjajú rôzne záplaty a vylepšenia. Mojou úlohou v diplomovej práci je popísať moţnosti zabezpečenia práve tejto najvyššej VoIP vrstvy. Pochopeniu všetkých moţností zabezpečenia predchádza pochopenie útokov. Z tohto dôvodu sa v tejto kapitole budem sústrediť práve na tie útoky a zabezpečenia proti ním, ktoré sa týkajú priamo SIP protokolu. Tab. 1 Bezpečnostné vrstvy [1] Bezpečnostné vrstvy Typ útoku na danú bezpečnostnú vrstvu 6. VoIP DoS/DDoS, Toll Fraud, Eavesdropping, Fuzzing 5. Bezpečnosť OS Pretečenie zásobníka, Červy, Konfigurácia, Pád OS 4. Bezpečnosť podporných sluţieb SQL Injection, 3. Sieťová bezpečnosť Sin Flood, SYN Flood, Ping of Death, Paketová búrka 2. Fyzická bezpečnosť Shutdown, Reboot 1. Bezpečnostná politika Slabé heslá Jednou z prvých vecí, ktorá človeka napadne ak sa začne zaoberať útokmi je, zamyslieť sa nad dôvodmi, ktoré vedú útočníka k zlomyseľnej činnosti. Tieto dôvody sú tými istými, ktoré vedú útočníkov útočiť aj na obyčajné telefóne siete. Či uţ v minulosti alebo v súčasnosti, tak ľuďom šlo vţdy hlavne o finančný prospech, a to napríklad metódami Toll Fraud, krádeţou informácií alebo identity. Takíto ľudia nemajú strach z odhalenia. Medzi ďalšie dôvody patrí snaha znepríjemniť uţívateľom vyuţívanie nejakej sluţby alebo znehodnotiť sluţbu operátora, a to zaťaţením siete vysokou prevádzkou. [2] Existuje mnoho útokov proti sluţbe SIP, niektoré sú účinnejšie, a niektoré naopak menej. Všetko závisí hlavne na tom, čo útočník od svojho útoku poţaduje. Typy útokov proti sluţbe SIP je moţné všeobecne kategorizovať [3]: Prelomenie registrácie - vydávanie sa útočníka za niekoho iného. Ide o jeden z najčastejších útokov, v ktorom útočník neoprávnene vyuţíva SIP sluţby. Prelomenie registrácie môţe byť dosiahnuté slovníkovým útokom alebo útokom hrubou silou na heslo legitímneho uţívateľa. Tak isto môţe byť prelomená registrácia odchytením platnej registrácie účastníka, z ktorej je moţné vyčítať meno a heslo. Privlastnenie identity servera - útočník sa snaţí dostať do komunikácie medzi SIP server (SIP Proxy, SIP registrar alebo Redirect) a UA. Útočník bude schopný odpočúvať, kontrolovať alebo presmerovať všetku prevádzku prechádzajúcu cez takýto kompromitovaný SIP server. 16

18 Manipulácia so správou - odchytenie a modifikáciu SIP hlavičky. Manipulácia s reláciou - do tejto kategórie patrí napríklad odchytenie časti komunikácie a na základe získaných informácií a vhodného nástroja je moţné zrušiť BYE útokom práve prebiehajúcu reláciu. DoS útoky. V dnešnej dobe, dobe internetu, uţ nie je problém vyhľadať si informácie o danom type útoku a svojpomocne takýto útok zrealizovať. Nech uţ je dôvod útočníka akýkoľvek, tak s vysokou pravdepodobnosťou si vyberie jeden z niekoľkých najčastejšie pouţívaných útokov, ktorými môţu byť DoS/DDoS, Toll Fraud, Man in the Middle, Eavesdropping, Theft of Service, Impersonation, Credential and Identity Theft, Hijacking alebo Fuzzing Denial-of-Service Odmietnutie služby Táto technika útoku, tzv. odmietnutie sluţby, sa snaţí platným účastníkom zabrániť pouţívať danú sluţbu. Dochádza k zaplaveniu servera poţiadavkami realizovanými veľkým počtom neuţitočných paketov, ktoré zahlcujú pamäť CPU alebo prenosovú rýchlosť kanála. Týmto útokom dôjdu serveru vlastné prostriedky pre poskytovanie danej sluţby, a to vedie zvyčajne k znemoţneniu obslúţenia platných účastníkov alebo pádu sluţby. Medzi útoky typu Denial-of-Service patrí aj pouţitie malého mnoţstva škodlivých paketov, ktoré sú navrhnuté na zneuţitie zraniteľných miest softwaru sluţby. Útočník týmto spôsobom nad ňou zvyčajne preberá kontrolu alebo znemoţní odoslanie platnej poţiadavky. Kvôli zvýšeniu obtiaţnosti sledovania a objavenia zdroja tohto útoku sa takýto útok väčšinou prevádza distribučným spôsobom. V takomto prípade sú veľké počty systémov v internete ovládané útočníkom a tie následne zahlcujú obeť [4]. Môţeme rozlišovať medzi úmyselnými, neúmyselnými alebo záškodníckymi DoS útokmi. Rozdelenie je zobrazené na Obr. 1. Zatiaľ čo neúmyselné DoS útoky sú často výsledkom implementácie alebo konfiguračnej chyby, tak tie zlomyseľné sú zahájené útočníkmi úmyselne. Tieto útoky môţu byť ďalej rozdelené do vyčerpávajúcich (tzv. flooding) útokov a do útokov, ktoré zneuţívajú zraniteľné miesta protokolu (tzv. misuse) [4]. Ďalším hľadiskom, z ktorého sa na útoky je moţné pozerať sú útoky priame a nepriame. Priame útoky spočívajú v priamom napadnutí obete posielaním veľkého mnoţstva poţiadaviek alebo zneuţitím určitej bezpečnostnej chyby. Nepriame zvyčajne útočia na nejaké podporné sluţby. Takouto sluţbou môţe byť napríklad DNS alebo databáza pouţívaná obeťou. V tomto prípade nemusí sluţba vykazovať ţiadne známky útoku, ale jej funkčnosť uţ nie je taká, aká bola zamýšľaná. [4][1] 17

19 Obr. 1 Klasifikácia rôznych typov DoS útoku [4] Toll Fraud Theft of the Service Toll Fraud je v oblasti telekomunikácií a VoIP celosvetovo rozšíreným problémom. Je to útok, v ktorom útočník vyuţije slabinu VoIP zabezpečenia a získa prístup k volaniam, ktoré je ďalej schopný lacno predať. Tieto volania potom často krát smerujú práve do krajín, v ktorých sú poplatky za takéto hovory drahé. Odpoveď na otázku prečo takéto hovory nezastaví uţ priamo operátor je taká, ţe operátor nedokáţe rozlíšiť či ten hovor je od firmy, zákazníka alebo je to útok typu Toll Fraud. Takýto hovor je prenášaný cez rôznych IXC (Inter-Exchange Carriers) - telekomunikační operátori prenášajúci hovory na veľké vzdialenosti. Kaţdý z nich musí platiť svoju časť pri prenášaní hovoru. V prípade volania do exotickej krajiny musí jeden operátor platiť tomu druhému, a to bez ohľadu na to, či je to Toll Fraud útok alebo nie. [1] Podľa americkej CFCA (asociácia zaoberajúca sa útokmi Toll Fraud) bola celková spôsobená škoda vo výške $4.96 miliárd amerických dolárov. [5] Človek má, po prečítaní takejto správy tendenciu neprikladať jej veľkú váţnosť a povedať si, ţe: Mne sa to nemôţe stať. Je dobré vedieť o týchto hrozbách, neskrývať sa pred nimi a zaujať voči ním patričné stanovisko Eavesdropping Typ útoku, ktorý monitoruje a odpočúva SIP reláciu. Môţe ísť o signalizáciu, média alebo indikáciu toho, kto s kým hovorí. SIP správa obsahuje signalizačné správy, ktoré pozostávajú z údajov ako identita, kontaktná adresa, bezpečnostné kľúče a ďalšie uţitočné informácie pre vytvorenie relácie, ktoré sa napríklad pomocou voľne dostupného programu Wireshark dajú jednoducho odchytiť, prečítať a následne jednoducho zneuţiť. Tieto informácie by mali byť z pohľadu bezpečnosti vhodným spôsobom utajené. [6] 1.2 Zabezpečenie protokolu SIP Ak bude firma rozmýšľať o stavbe bezpečnej SIP siete, potrebuje vziať do úvahy štyri rôzne oblasti, v ktorých zabezpečenie bude pouţité. Ako prvé je potrebné zabezpečiť SIP signalizáciu. Prioritou číslo dva by bola ochrana RTP streamu prenášaného cez sieť. Potom je tu zaistenie toho, ţe SIP entita je naozaj tá, za ktorú sa vydáva. A ako posledné je vytvorenie bezpečného pripojenia k 18

20 internetu na okraji siete. V tejto kapitole sa preto budem snaţiť popísať rôzne metódy zabezpečenia protokolu SIP.[7] Pri návrhu a implementácii siete je nutné pouţiť bezpečnostné opatrenia, ktoré dokáţu uspokojiť poţiadavky bezpečnej siete. Medzi základné bezpečnostné mechanizmy patrí [8]: Autentizácia proces overenia identity účastníka. Vyţaduje pouţitie hesla kedykoľvek keď sa uţívateľ pripojí do siete, a tak zaháji registráciu uţívateľa v sieti. Autorizácia oprávnenie prístupu. Vyţaduje dopytovanie sa databázy na základne údajov o účastníkovi, o sluţbách, ktoré je účastník autorizovaný pouţívať. Tieto údaje pozostávajú z privátnej a verejnej identity účastníka. Autorizácia môţe byť kvôli zefektívneniu súčasťou autentifikácie. Dôvernosť čo znamená, ţe k informáciám a dátam majú prístup len oprávnení účastníci, konverzácia nemôţe byť špehovaná a účastníci si môţu slobodne vymieňať informácie (napríklad telefonovať) bez toho, aby boli odchytené niekým iným. Celistvosť zaistenie, ţe informácia nebola zničená, stratená alebo modifikovaná. Je veľmi jednoduché získať prístup k nezabezpečenej SIP správe a predtým neţ bude doručená, tak zmeniť jej obsah. Napríklad za účelom zmeny sluţby a doručovacieho miesta. Súkromie zaistenie anonymity účastníka (skrývanie IP adresy). Dostupnosť zaistenie dostupnosti sluţby. Nepopierateľnosť zaisťuje, aby po tom čo účastník sluţbu pouţil, tak nemohol poprieť vyuţitie danej sluţby. Toto sú len všeobecne definované bezpečnostné mechanizmy, ktoré tvoria základ špecifických bezpečnostných implementácií v sieti SIP. Na nich sú postavené všetky bezpečnostné mechanizmy opísané v nasledujúcich podkapitolách. V nich som sa nezaoberal bezpečnostnými mechanizmami, S/MIME, PGP a Secure SIP, pretoţe tieto mechanizmy nie sú pouţité v Avaya Aura architektúre Heslo a kontrola prístupu Heslo patrí k najzákladnejším a najviac prehliadaným bezpečnostným prvkom. Heslá sú nepríjemnou záleţitosťou a nikto sa s nimi nerád zaoberá pokiaľ sa chce prihlásiť k svojmu SIP účtu. Problémom s heslami je ich správa, napr. implementáciu starnutia hesla, ktorá zvyšuje bezpečnosť. Je to pravidelná zmena hesla, ktorá sa týka účastníkov alebo kritických sieťových prvkov. Niekto si svoje heslo mení pravidelne, iní vôbec. Moţno to vyzerá triviálne, ale niektorí správcovia sietí si heslá na svojich zariadenia pravidelne vôbec nemenia, nech sa jedná o brány, smerovače alebo iné sieťové zariadenia. Dokonca nechávajú štandardné heslá, ktoré sú veľmi dobré zdokumentované a ďalej šírené pomocou internetu, a to môţe viesť k tzv. Toll Fraud útoku [8]. 19

21 Prvým najzákladnejším a nevyhnutným krokom k bezpečnejšej sieti je zmena základného hesla a jeho pravidelná aktualizácia. Je potrebné mať taktieţ čo najdlhšie a najzloţitejšie heslá Šifrovanie SIP signalizácia sa v sieti šíri ako tzv. plain text čo z anglického prekladu znamená prostý text. Ten je moţné pomocou sieťových nástrojov, napríklad Wireshark, veľmi jednoducho odchytiť. Preto je z hľadiska bezpečnosti potrebné uvaţovať aj o šifrovaní takéhoto prostého textu. Šifrovanie je jedným z bezpečnostných prvkov, ktoré rieši mnoho problémov a jedna z najlepších ciest, ako preventívne zamedziť neţiaducemu prečítaniu správy naprieč sieťou na ceste k jej prijímateľovi. RFC 3261 [9] v tomto prípade štandardizuje pouţitie TLS pre proxy servery, redirect servery a registrar. Taktieţ sa odporúča jeho pouţitie pre UA. Pri pouţití TLS vznikne dôverné spojenie na transportnej vrstve OSI modelu. TLS je schopné poskytnúť ochranu SIP komunikácie proti strate celistvosti, dôvernosti (kap. 1.2) a proti opakovanému generovaniu SIP správy. TLS sa pouţíva na Hop-by-Hop báze (Obr. 2) medzi UA a proxy alebo medzi UA a call severom. Ak budem uvaţovať o relácii medzi dvomi UA a dvomi proxy servermi, podľa Obr. 2, tak kaţdý z týchto tzv. hopov bude rôznou TLS reláciou. TLS tunel je v signalizačnej ceste zostavovaný nezávisle medzi všetkými koncovými bodmi. V kaţdom spojení je moţné pouţiť rôzne bezpečnostné certifikáty, rôzne hash funkcie a šifrovacie algoritmy. Vo výsledku bude zaistená celistvosť a dôvernosť pri prechode cez kaţdú SIP entitu na signalizačnej ceste, ale obsah SIP správy bude viditeľný pre obe sip proxy. [2] V reálnom pouţití je však veľmi ťaţké dokázať, ţe v signalizačnej ceste pri telefonovaní cez internet bol medzi všetkými sip entitami vybudovaný TLS tunel. Význam jeho pouţitia je hlavne medzi UA a proxy serverom, ktoré spravuje sieťový operátor, a ktoré má pod svojou kontrolou. Takto je moţné zabezpečiť to, ţe hovory v jeho sieti nebudú odpočúvané. Obr. 2 Hop-by-Hop TLS medzi UA a Proxy serverom Čo sa šifrovania týka, tak tu patrí nielen šifrovanie signalizácie pomocou TLS ale aj šifrovanie médií. Avaya podporuje šifrovanie pomocou SRTP [10]. Je to šifrovaný RTP prenos. Takýto prenos nemôţe byť odpočúvaný, a to jednoduchým odchytením 20

22 komunikácie pomocou programu Whireshark. Útočník nebude poznať kľúč, ktorým je komunikácia šifrovaná, a preto si daný hovor nebude môcť prehrať Autentizácia a autorizácia Jedným zo základných bezpečnostných mechanizmov je aj autentizácia. Dôvodom potreby autentizácie je overenie identity toho s kým komunikujeme. Taktieţ zabezpečuje to, ţe to čo prijímateľ prijme je to čo odosielateľ odoslal (celistvosť). Tak isto zabraňuje neautorizovanej registrácií. SIP špecifikuje niekoľko druhov autentizácie. Tá najzákladnejšia má anglický názov basic a originálne pochádza z protokolu HTTP. Táto autentizácia prenáša uţívateľove prihlasovacie údaje v čistom texte zakódovaná do base-64, takţe pre útočníka by vôbec nebolo problémom získať pouţívateľovo heslo. Základná autentizácia neobsahuje ţiadne zabezpečovacie mechanizmy a je jednoducho zneuţiteľná. Je však moţné pouţiť základnú autentizáciu aj bezpečne, a to v určitých prípadoch. Kde by komunikáciu chránil napríklad TLS tunel. Aj napriek tomu by však mali byť pouţité digest alebo silnejšie autentizačné metódy. [2] Z pohľadu bezpečnosti neexistuje dôvod nepouţiť digest autentizáciu, ktorá tak ako aj na klienta, tak aj na server kladie len minimálne poţiadavky. Digest autentizácia vychádza z protokolu HTTP a pouţíva sa na autentizáciu medzi UA a proxy serverom alebo naopak. Kvôli bezpečnosti vyuţíva tzv. nonce alebo jednorázovo generovaný kľúč. Pouţívateľove prihlasovacie údaje sú zvyčajne hashované pomocou MD5. MD5 hash tvorí pouţívateľské meno, heslo, realm a nonce. Môţe byť pouţitý len pod špecifickou doménou. Popis toho ako taká autentizácia funguje je zobrazený na Obr. 3. Táto autentizácia nemusí byť iba súčasťou REGISTER poţiadavky ale aj INVITE a BYE. [11] Obr. 3 Registračná procedúra pomocou digest-autentizácie 1.3 BYOD Dnešná doba prináša obrovský bum vo výrobe a vývoji nových mobilných zariadení (tabletov, telefónov). Tie sa stávajú novodobým trendom a všetok vývoj sa začína točiť okolo nich. Bolo by veľkou škodou ak by si zamestnanec firmy kúpil svoje vlastné zariadenie, napríklad tablet a nemohol ho pouţívať v rámci firmy. To doteraz 21

23 bolo moţné ale takéto zariadenie muselo byť prísne monitorované, pretoţe z pohľadu siete sa stávalo hrozbou. Ani sám pouţívateľ nemusel vedieť o tom, aký škodlivý softvér si tam nevedomky nainštaloval. To je uţ ale minulosťou. SIP ponúka moţnosť nainštalovať si na svoje zariadenie vlastného SIP klienta a týmto klientom byť pripojený k firemnej sieti. Tento trend sa nazýva Bring Your Own Device (BYOD). Takéto zariadenie uţ nemusí podliehať prísnej kontrole, pretoţe uţ to nie je ten tablet alebo mobilný telefón, ktorý sa pomocou VPN pripája k firemnej sieti ale SIP aplikácia. Tá môţe ponúknuť široké moţnosti komunikácie telefonovanie, videohovor, konferencia, videokonferencia, prezenčný systém alebo zdieľanie pracovnej plochy za účelom prezentácie. [12] Dnes je moţné si nainštalovať na IOS, Android alebo Windows Phone svojho vlastného SIP klienta a reagovať na hovory vo firme práve ním - UNI (User to Network Interface). Bezpečnosť v tomto prípade nebude problém pod podmienkou, ak celá komunikácia z vlastných zariadení bude prechádzať cez SBC. Ten prepustí len platnú SIP komunikáciu, vrátane médií a do internej siete sa nič cudzie nemôţe dostať. Takto medzi organizáciou a vlastným zariadením odpadne potreba VPN tunela. Uţ nebude potrebné zabezpečiť celé zariadenie a následné monitorovanie inštalovaných aplikácií ako pri VPN. V tomto prípade ide len o zabezpečenie SIP aplikácie. [12] 22

24 2 Session Border Controller Session Border Controller (SBC) je SIP B2BUA entita, ktorá je všeobecne známa ako hranica medzi privátnou a verejnou sieťou. SBC prijíma ţiadosti ako UAS a potom ich ďalej preposiela ako UAC. Tvorí akýsi SIP firewall, ktorý zabraňuje neţiaducej prevádzke ohroziť sieť. V súčasnosti kaţdý VoIP operátor, ku ktorému sa firma pripojí bude mať na svojom okraji siete vţdy nejaké SBC, ktorým si bude chrániť svoju vlastnú sieť. Preto je potrebné zváţiť pouţitie SBC aj na okraji internej siete. Kaţdý kto spravuje sieť, ju chce mať pod čo najväčšou kontrolou. Táto kontrola zahŕňa aj takú zdravú nedôveru voči VoIP operátorovi, ktorý môţe ale nemusí ochrániť firemnú internú sieť od vonkajších útokov. Preto prvým bezpečnostným prvkom v sieti by malo byť vlastné SBC, ktoré má sieťový administrátor pod svojou kontrolou. Termín SBC je relatívne nešpecifikovaný, pretoţe zatiaľ nie je štandardizovaný. SBC typicky spracováva signalizáciu médií, často modifikuje hlavičky a časti tela správy SIP, ktoré SIP Proxy nemajú dovolené modifikovať. Taktieţ zvyčajne sedí na hranici medzi vnútornou a vonkajšou sieťou, kde dáva pozor, kontroluje a chráni prevádzku, ktorá smeruje z vonkajšej siete (nedôveryhodnej) do vnútornej (dôveryhodnej). SBC je konfigurované a spravované organizáciou, ktorá spravuje aj vnútornú sieť. Na Obr. 4 je znázornená vnútorná architektúra SBC, ktorá zahŕňa časť spracúvajúcu média a časť spracúvajúcu signalizáciu. [13] Signalizácia SBC Signalizácia Vnútorná sieť Vonkajšia sieť Média Média Obr. 4 Vnútorná architektúra SBC SBC sa delí na podnikové, prístupové a peering SBC (Obr. 5). Podnikové SBC je štandardné SBC, ktoré oddeľuje internú sieť firmy od operátora. To je pripojené k prístupovému SBC, ktoré má uţ v správe VoIP operátor. Peering SBC sú navzájom prepojení operátori. 23

25 Operator 1 Operator 2 Peering SBC Access SBC Peering SBC Firma Enterprise SBC Enterprise SBC Obr. 5 Typy SBC SBC je zariadenie, ktoré disponuje niekoľkými funkciami [13][14]: SIP Firewall Vo svojej podstate je SBC akýmsi SIP firewallom, ktorý prepúšťa iba správne formátované SIP správy. Dokáţe zastaviť DoS a DDoS útok, obsahuje white list a black list IP adries, monitoruje zlyhané pokusy o prihlásenie sa a poskytuje prevenciu proti zahlcovacím útokom. Topology hiding Jednou z ďalších výhod SBC je, ţe dokáţe poskytnúť topology hiding - skrývanie topológie, ktoré funguje ako Network Addresses Translation (NAT). NAT nám zaistí mapovanie privátnej IP adresy na niekoľko málo verejných. To spôsobí, ţe vnútro siete je zvonku neviditeľné. Interoperablita Je to schopnosť rôznych systémov spolu vzájomne spolupracovať. SBC poskytuje moţnosť meniť a manipulovať so SIP správami, ktoré cez neho prechádzajú. To znamená, ţe môţe zmeniť obsah takejto správy manipulovaním hlavičiek. Táto funkcia sa vyuţíva hlavne pri naviazaní komunikácie s rôznymi SIP telefónmi, servermi a trunkami od rôznych operátorov. Veľmi často sa stáva, ţe rôzne SIP siete majú svoj vlastný formát SIP signalizácie, a preto by siete spolu, bez nejakého prvku medzi nimi nedokázali navzájom dorozumievať. Netýka sa to len rôznych sietí, ale aj rôznych výrobcov (napríklad Cisco a Avaya). Prekódovanie Je jazykový preklad, ktorý je vyţadovaný vtedy ak sa medzi sieťami pouţívajú rôzne jazykové prostriedky, ktoré chcú spolu komunikovať ale pouţívajú rôzne jazyky. Napríklad zmena signalizácie H.323 na SIP alebo potreba zmeny z jedného kodeku na druhý (z G.729 na G.711). Ďalšie moţnosti zahŕňajú preklad IPV6 na IPV4, SRTP na RTP alebo TLS na SIP. Smerovanie hovorov SBC dokáţe taktieţ smerovať SIP signalizáciu v sieti. Táto moţnosť vie byť nápomocná ak v sieti pouţívame viac ústrední alebo iných SIP prvkov. 24

26 Dynamická manipulácia signalizácie SBC pouţíva dynamickú manipuláciu SIP signalizačných správ, ktorá dovoľuje pridať, zmeniť alebo vymazať ľubovoľnú SIP hlavičku v SIP správe. Táto funkcia sa v Avaya SCB vyuţíva pomocou skriptovacieho jazyka zvaný SigMa. 2.1 Potreba SBC Potreba SBC sa nemusí primárne vzťahovať len na bezpečnosť. To je len jedna z funkcií, ktoré SBC ponúka. V čom sa teda líši klasické SBC od firewallu? Tradičný firewall nedokáţe zabrániť zahlteniu ústredne SIP poţiadavkami, otvárať a zatvárať média porty podľa SIP signalizácie, sledovať stav relácie. Nedokáţe zabezpečiť kompatibilitu medzi rôznymi SIP sieťami. V konečnom dôsledku závisí potreba SBC len na danej organizácii. Predsa len sa jedná o určitú finančnú poloţku. Dôvody potreby SBC sa preto pokúsim stručne popísať v nasledujúcich podkapitolách. Na potrebu SBC sa pozriem z dvoch hlavných pohľadov. Tieto dva pohľady sa delia na úrovne NNI a UNI NNI - SIP trunk k operátorovi SIP trunk sa stáva čoraz obľúbenejším spôsobom pripojenia k operátorovi a postupne nahrádza drahé tradičné telefónne linky T1/E1. Takto dosiahne firma ten istý výsledok za menej peňazí. Jediným problémom ostáva iba bezpečnosť, na ktorú sa pri SIP trunku kladie oveľa väčší dôraz. Niektoré firmy sú ešte aj teraz pripojené pomocou T1/E1 liniek, pretoţe neveria IP telefónii a boja sa pripojiť svoju sieť do verejnej siete. Chcú mať bezpečnosť siete pod kontrolou aspoň takto. Toto riešenie je ale oproti SIP tunku drahšie. Preto pri správnom zabezpečení siete pomocou SBC je moţné mať zabezpečené pripojenie a k tomu aj ušetriť peniaze za tieto linky. Bezpečnosť SIP trunku Dnes si asi nikto nedokáţe predstaviť, ţe by pripojil svoju privátnu sieť do tej verejnej bez toho, aby medzi toto spojene vloţil nejaký firewall. Takéto pripojenie by predstavovalo riziko útoku a to isté platí aj pre SIP. Nákup nového SBC zhltne určitú poloţku vo finančnom rozpočte. Niektoré firmy si poriadne premyslia či túto poloţku do svojho finančného rozpočtu vôbec zahrnú a budú vznikať rôzne argumenty proti nasadeniu SBC. Niekto by sa vedel obhájiť aj tým, ţe je pripojený k operátorovi, ktorý ho dokáţe ochrániť. To je sčasti pravda, takýto operátor disponuje schopnosťou odhaliť a včas zamedziť nejakým druhom útokov (hlavne DoS/DDoS). Prečo sa ale spoliehať len na operátora, ak je moţnosť mať bezpečnosť svojej siete vo vlastných rukách, ktorá je ešte znásobená tým, ţe o túto bezpečnosť sa stará aj operátor? 25

27 Obr. 6 SIP trunk [15] Porovnávaním sieťovej bezpečnosti s VoIP bezpečnosťou je vidieť, ţe tá VoIP je iná. Nasadením firewallu je moţné zamedziť útokom orientovaným na tretiu a štvrtú vrstvu OSI modelu. Keďţe SIP je určený pracovať na najvyššej aplikačnej vrstve, tak takýto útok firewall nedokáţe ochrániť. Je potrebné si uvedomiť, ţe bezpečnosť VoIP sa od tej klasickej líši. Vystavením nechránenej VoIP siete do internetu vzniká riziko toho, ţe útočník dokáţe zo SIP hlavičiek vyčítať o sieti kľúčové informácie. Tieto informácie môţe ľahko pouţiť k napadnutiu. Zachytením hocijakej SIP relácie ju môţe odpočúvať, pozmeniť, posielať škodlivé poţiadavky alebo len tak vyzváňať na telefóny. Čo sa teda stane ak na hranicu siete príde SBC? Z pohľadu bezpečnosti to, ţe útočník uţ nebude schopný prečítať a istým spôsobom zneuţiť informácie zo SIP správ, ktoré z internej siete odchádzajú. SBC pozmení SIP hlavičky tak, ţe ich nahradí za také, ktoré pre útočníka nebudú mať nijakú hodnotu. V prípade, ţe by tam to SBC nebolo je útočník schopný vidieť určité detaily o volajúcom, napríklad jeho IP adresu. Na tú potom môţe záškodnícky vyzváňať. Naopak, v prípade, ţe je SBC nasadené bude útočník vidieť len IP adresu SBC a všetko ostatné bude pre neho skryté. Dôvodom je to, ţe pri pouţití SBC sa bude jeden hovor fyzicky skladať z dvoch relácií. Útočník bude vidieť len reláciu po hranicu SBC, tá druhá, ktorá obsahuje cenné informácie o infraštruktúre vnútornej siete, bude pre neho vďaka tej druhej relácii utajená. Vidím SIP informácie o užívateľoch. Môžem vyzváňať na telefóny, alebo poslať zlú SIP požiadavku! UA Útočník SIP Trunk Firewall IP PBX UA UA Jedna SIP relácia Obr. 7 Útok z pohľadu útočníka bez SBC 26

28 Vidím len SBC, ktoré mi skrýva topológiu siete. UA Útočník SIP Trunk Firewall SBC IP PBX UA UA Dve SIP relácie Obr. 8 Útok z pohľadu útočníka s nasadeným SBC Funkčnosť V niektorých prípadoch nemusí byť pouţité SBC len kvôli bezpečnosti. Potreba SBC vychádza taktieţ aj z hľadiska funkčnosti. Pretoţe vďaka SBC je moţné pouţívať všetky funkcie popísané v kap. 2, a tak isto aj funkcie z nich vychádzajúce napr.: UDP/TLS TLS s operátorom, UDP v sieti, spracovanie viacerých registrácií od účastníka zatiaľ čo voči ústredni sa zaregistruje len raz, v niektorých SBC je moţné aj účtovať hovory, nastavenie určitého maximálneho počtu hovorov od daného uţívateľa UNI - Remote workers Komunikácia je jeden z najvýraznejších faktorov úspešnosti firmy. Ocitáme sa vo svete kedy sa jeden človek nedokáţe postarať o celý komplexný projekt. Určite bude potrebovať pomoc od ostatných ľudí, a preto s nimi musí ostať v kontakte. Firma, v ktorej spolu zamestnanci môţu pohodlne komunikovať má vysoké predpoklady rastu. Komunikácia nebude problém ak sa títo ľudia budú kaţdý deň osobne stretávať alebo budú aspoň v jednej budove, kde náklady na komunikáciu sú zanedbateľné. Takýto svet ale začína byť postupne minulosťou. Ľudia začínajú viac cestovať a vzďaľovať sa od sídla firmy i na druhú stranu planéty. V tomto bode sa začína komunikácia zhoršovať a ľudia sú nútení vyuţívať relatívne lacné internetové spojenie a s ním spojenú technológiu VoIP. To prináša radu bezpečnostných rizík. V predchádzajúcom prípade bolo pouţitie SBC otázne, ale odôvodnené. V tomto prípade, kedy sa firma rozhodne vyuţiť funkčnosť protokolu SIP, ktorou je vzdialený prístup k firemnej SIP sieti, tak pouţitie SBC je nutnosťou. SBC bude jediné zariadenie, ktoré bude stáť medzi internetom a privátnou sieťou alebo medzi potenciálne nebezpečným zariadením a ústredňou. Moţnosti protokolu SIP sa stále vyvíjajú a s tým sa vyvíja aj firemná komunikácia, kde firemný zamestnanci často pracujú z domu alebo si nosia do práce vlastné zariadenia (BYOD). Tento vzrastajúci trend je vo svete SIP novinkou a pestrým rozšírením moţností modernej firmy, ale zároveň aj veľkou bezpečnostnou hrozbou. 27

29 Túto situáciu popisuje nasledujúci príklad, v ktorom firemný zamestnanec pracujúci z domu alebo na sluţobnej ceste potrebuje komunikovať so svojím kolegom v tej istej firme. Doteraz mohol disponovať zvýhodneným paušálom od operátora, ale pri väčšom počte takýchto zamestnancov to uţ nemusí byť pre firmu zanedbateľná poloţka. Firemný zamestnanec bude mať s veľkou pravdepodobnosťou prístup k internetu. Populárnou moţnosťou je pouţitie virtuálnej privátnej siete, tzv. VPN, táto moţnosť je ale nepraktická pretoţe sa vzťahuje na celé zariadenie, s ktorým sa pripájame k sieti. SIP preto ponúka moţnosť, tzv. remote worker, kde firemný zamestnanec sa so svojím SIP klientom zo svojho vlastného počítača a so svojím internetovým pripojením prihlási do firemnej siete a bez ţiadnych ďalších finančných nákladov komunikuje s ostatnými zamestnancami firmy. Takýto SIP klient sa registruje pomocou internetu na SBC, ktoré túto SIP registráciu skontroluje a predá ďalej ústredni, v tomto prípade to bude Avaya Aura Session Manager. Týmto odpadá potreba VPN SIP komunikácie, zjednoduší sa vzdialený prístup k sieti a otvoria sa nové moţnosti firmy. V konečnom dôsledku sem okrem volania patria aj videohovory, prezenčný systém, zdieľanie plochy, konferencie a videokonferencie. 2.2 Možnosti zapojenia SBC Obr. 9 Remote Workers [15] Architektúra siete i uloţenie SBC je dôleţitým prvkom. SBC je moţné zapojiť ako Two-wire a One-wire. Výber vhodnej topológie závisí od bezpečnostných potrieb a poţiadaviek organizácie. Ţiadne z týchto zapojení nepridáva zbytočnú latenciu. Obe zapojenia je z bezpečnostného hľadiska potrebné vloţiť do DMZ. [15] 28

30 2.2.1 Topológia Two-wire V Táto topológia je jedna z najjednoduchších a najzákladnejších moţností, ako zapojiť SBC. To je umiestnené v DMZ medzi interným a externým firewallom - priamo na linke medzi ústredňou a internetom. V tomto prípade ponúka SBC hraničnú kontrolu SIP prevádzky. Zahŕňa SIP firewall, NAT, spravovanie a kontrola prístupu. Tieto funkcie sú zaloţené na bezpečnostných opatreniach firmy. Nezávisle na nich je táto topológia schopná chrániť aj proti útokom ako DoS, spoofing, stealth útoky a hlasový SPAM. [15] Obr. 10 Zapojenie Two-wire [15] Topológia One-wire V topológií typu One-wire je SBC tak isto uloţené v DMZ, ale od predchádzajúceho zapojenia sa líši v uloţení, a to ţe uţ nie je priamo na linke medzi ústredňou a verejnou sieťou. V tomto prípade je však SIP smerovanie nastavené tak, aby všetky SIP komunikácia prechádzala cez SBC. [15] 29

31 2.2.3 Demilitarized Zone - DMZ Obr. 11 Zapojenie One-wire [15] DMZ je fyzická alebo logická podsieť a znamená demilitarizovanú zónu. Dôvodom pouţitia DMZ je zvýšenie bezpečnosti. Ide o podsieť, ktorá síce patrí k organizácii, ale je to izolovaná sieť, ktorá oddeľuje LAN od WAN. Je to sieť, do ktorej sa vloţia servery, ktoré potrebujú priamo komunikovať s externou nedôveryhodnou WAN sieťou. V prípade mojej diplomovej práce sa to týka SBC, ktoré tu bude uloţené. Táto sieť síce bude chránená firewallom, ale stále má priamy prístup k internetu. To znamená, ţe ak aj náhodou bude kompromitovaná útočníkom zvonku, tak internej sieti sa nič nestane, tá bude aj naďalej funkčná. Výhodou DMZ je taktieţ priama kontrola nad servermi v nej. [16] Interná sieť DMZ Internet IP PBX Interný Firewall SBC Externý Firewall Obr. 12 DMZ SBC High Availability (HA) Väčšina SBC môţe byť nakonfigurovaná v dvoch módoch. Pre jednoduchosť som sa doteraz zaoberal len jedným z nich tzv. standalone. Celú prácu vykonáva len jeden hardware a v prípade poruchy alebo nečakaného výpadku SBC môţe byť celá komunikácia prechádzajúca práve cez toto SBC v ohrození alebo stratená. 30

32 Obr. 13 Detailné zapojenie Avaya Aura SBCE v HA [15] Druhý mód je High Availability konfigurácia, kde celé SBC pozostáva z dvoch rovnako nakonfigurovaných serverov a tretieho (EMS), ktorý tieto dva spravuje a synchronizuje. Celá prevádzka prechádza cez oba SBC servery, kde jeden je aktívny a druhý je jeho kópia v reálnom čase. Tieto dva SBC majú rovnako nakonfigurované verejné a privátne adresy, avšak tie sú pouţívané len v aktívnom SBC. V dobe kedy nastane výpadok aktívneho SBC, druhé v okamihu schopného prevziať IP adresy a následne aj kontrolu nad všetkou práve prebiehajúcou komunikáciou. [15] Obr. 14 Zjednodušené zapojenie v HA [15] 31

33 2.3 Vyber správneho SBC Existuje niekoľko kritérií podľa ktorých je moţné si vybrať to správne SBC. SBC je relatívne nový produkt a keďţe nie je presne štandardizovaný, tak všetci výrobcovia disponujú veľkou voľnosťou pri jeho dizajne. Asi najdôleţitejším kritériom pri výbere bude kapacita SBC. Ide o počet súbeţných hovorov, ktoré je schopné SBC odbaviť. Na trhu sa SBC, podľa kapacity, delia do troch kategórií. Kategória pre malé, stredné a pre veľké firmy. Pre predstavu sa rozsahy počtov relácií pre malé firmy pohybujú od Pre stredné od 500 do SBC s najväčšou kapacitou sú od do Kaţdý výrobca ponúka SBC s rôznym počtom relácií. Ďalšími kritériami by mohla byť funkčnosť SBC či ponuka HA alebo šifrovanie hlasu a signalizácie. Otázkou môţu byť aj pouţité kodeky, ktoré SBC podporuje alebo či vie previesť H.323 signalizáciu do SIP. Tieţ ako vyzerá manaţment SBC či je jednoduché ho konfigurovať napríklad cez webové rozhranie alebo sa konfiguruje cez príkazový riadok. S konfiguráciu ide ruka v ruke otázka podpory od výrobcu. [17] Významnú úlohu zohráva samozrejme aj bezpečnosť a spôsob akým je schopné zvládnuť útoky. Do úvahy prichádza aj moţnosť nastavenia prahovej hranice pri DoS útokoch a následné informovanie o podozrivom správaní sa v sieti. Správny výber preto výrazne závisí od poţiadaviek zákazníka. Myslím si, ţe dobrým porozumením potrieb zákazníka a moţnosti dostupných SBC sa dá dospieť k tým najdôleţitejším kritériám pre danú firmu. [17] Najznámejšími výrobcami SBC, ku ktorým som sa dopátral sú: Avaya, AudioCodes, Genband, Sonus, Cisco, Acme, Mediant, Edgewater Networks, Frafos a Squire Technologies. Kaţdý z nich ponúka niekoľko SBC produktov, ktorými sa snaţí pokryť trh čo najširšie. 32

34 3 Avaya Aura architektúra Avaya Aura je názov komunikačného riešenia od firmy Avaya, ktoré predstavuje komunikáciu zabezpečenú pomocou protokolu SIP. Poskytuje tzv. Unnified communication (UC) čo z anglického názvu znamená zjednotenú komunikáciu. UC pozostáva z komunikácie v reálnom čase k čomu patrí: posielanie rýchlych správ (chat), prezencia, VoIP, videokonferencia, zdieľanie plochy, zdieľanie dát, kontrola hovorov, rozpoznávanie reči. Do komunikácie, ktorá neprebieha v reálnom čase patrí: hlasová schránka, , SMS a fax. Zároveň podporuje aj H.323 telefoniu. [18] Avaya Aura architektúra sa skladá z piatich základných serverov: Communication Manager, Application Enablement, Presence, System Manager a Session Manager. Zaoberal som sa len dvoma z nich - System Manager a Session Manager, ktoré mi k zabezpečeniu obyčajného telefónneho spojenia medzi pár klientmi úplne stačilo. V sieti som mal dva SM zapojené v HA, ktoré boli manaţované z pomocou SMGR. Prístup k týmto serverom som získali od firmy Algotech, ktoré uţ boli nasadené a pripojené do testovacej prevádzky. Prvým krokom bolo spoznávanie a moţnosti nastavenia celej tejto architektúry. K ďalším testom bolo potrebné nainštalovať, nastaviť a k celej sieti pripojiť Session Border Controller (SBC). Všetky tieto servery pouţívajú operačný systém Red Hat Enterprise Linux, ktorého bezpečnosť bola firmou Avaya vylepšená, a to odstránením nepouţívaných Red Hat Packet Management (RPM) balíčkov. Dôvodom je to, ţe IP telefónia od firmy Avaya nevyţaduje všetky RPM poskytované Red Hat-om, ktoré by mohli byť bezpečnostnou hrozbou. K zisteniu všetkých RPM balíčkov, ktoré sú v danom serveri pouţité je moţné pouţiť príkaz rmp-qa. Kvôli minimalizácii sieťovo zaloţených útokov sú povolené len porty potrebné k telefónnym aplikáciám. Uţ v základe sú vypnuté menej bezpečné sluţby ako napríklad TELNET a FTP, ktoré prenášajú nezašifrované prihlasovacie údaje. Namiesto nich sú pouţité SSH, SCP a SFTP. Taktieţ nie je moţné pouţiť štandardnú kombináciu kláves CTRL-ALT-DELETE k reštartovaniu servera. [19] Obr. 15 Avaya Aura architektúra 33

35 Tab. 2 Špecifikácie Avaya Aura podľa jednotlivých verzií [20] Kapacita/počet Release 6.0 Maximálny limit Release Release Release Celkový počet SIP pouţívateľov SIP koncové zariadenia Počet pouţívateľov na SM Počet pouţívateľov na CM Pouţívatelia z funkciou Shared Control na SM Počet SM Simultánne relácie Registrácie za sekundu na SM N/A N/A Počet CM Počet SIP domén Dial pattern/smerovanie Avaya Aura Session Border Controller for Enterprise Avaya Session Border Controller for Enterprise (SBCE) nepatrí síce priamo do Avaya Aura architektúry, no je jedným z jej bezpečnostných prvkov, ktorý zabezpečuje komunikáciu v reálnom čase smerujúcu za hranice internej siete. Poskytuje niekoľko zabezpečovacích mechanizmov a pracuje v dvoch typoch prevádzky. Jedným je SIP trunk a tým druhým je tzv. remote worker - vzdialené pripojenie, ktoré rozširuje komunikačné moţnosti firmy a tu patrí aj trend BYOD. Vo svojej podstate je SBCE akýmsi doplnkom do Avaya Aura architektúry, ktorý pridáva celému prostrediu ďalšie prídavné funkcie a zvyšuje jeho celkovú bezpečnosť. Skladá sa z dvoch komponentov [21]: Avaya SBCE a Avaya Element Management System (EMS). V závislosti na veľkosti siete a poţiadaviek sluţby je moţné rozmiestniť SBCE buď do tzv. standalone konfigurácie, kde je Avaya SBCE a EMS na tom istom fyzickom serveri. Potom je tu konfigurácia typu multiple server, kde sú EMS a Avaya SBC rozdelené na dva fyzické servery. Takéto EMS dokáţe spravovať aj viacero Avaya SBCE v sieti. Nakoniec existuje aj moţnosť HA konfigurácie (kap ) kedy je potrebné mať dva servery pre Avaya SBCE (primárny a sekundárny) a jeden pre EMS. [21] Funkcie Avaya SBCE Z funkčného hľadiska sa Avaya SBCE delí na časť spracovávajúcu signalizáciu a na časť, ktorá spracováva média (Obr. 4). Signalizačná časť vytvára 2 ms latenciu na celkovej signalizačnej trase End-to-End (Obr. 2) a stará sa o funkcie akými sú šifrovanie TLS, manaţment bezpečnostných kľúčov, overovanie SIP správ, ochrana internej siete, QoS a v neposlednom rade aj smerovanie do rôznych ústrední v sieti. Časť, ktorá spracováva média je zodpovedná za ich riadenie a správu (napr. správa pouţitých kodekov, šifrovania SRTP alebo detekcia anomálií v RTP prenose). [21] 34

36 Tab. 3 Parametre počtu konkurenčných hovorov pre Avaya SBCE [15] Počet konkurenčných hovorov Trunk Remote Workers Nezašifrované Zašifrované Nezašifrované Zašifrované Tieto špecifikácie z Tab. 3 podľa [15] platia za predpokladu, ţe: parametre servera - Dell PowerEdge R210 II, štvorjadrový procesor Intel Xeon E (3,1GHz, 8MB cache), 8GB DDR3 1600MHz (aţ 32GB), 6x1Gb Ethernet, špecifikovaný kodek kodek G711 s 20ms paketovým intervalom a všetky relácie sú audio relácie, model hovoru pouţitý model SIP RFC pre model hovoru v trunkovom type prevádzky, konfigurácia Avaya SBCE sú pouţité iba základné nastavenia a všetky bezpečnostné mechanizmy sú vypnuté Bezpečnostné špecifikácie Avaya SBCE Bezpečnostný produkt od firmy Avaya chráni pred nasledujúcimi útokmi [22]: neoprávnený prístup alebo modifikácia správ, odcudzenie dát, DoS útoky, vírusy a červy. K zabráneniu týmto hrozbám je pouţitá stratégia skladajúca za z troch bezpečnostných častí, ktorými sú: bezpečnosť návrhu, základné zabezpečenie a zabezpečenie komunikácie. [22] Bezpečnosť návrhu Bezpečnosť návrhu spočíva v rozdelení sietí do bezpečnostných zón, respektíve do rôznych jednoúčelových LAN alebo VLAN sietí pre určitú funkciu [19]: manaţment sieť manaţment rozhranie SBC, ktoré slúţi na konfiguráciu celého SBC, verejná sieť PSTN alebo internet, privátna sieť vnútorná sieť firmy. Tieto rôzne bezpečnostné zóny nepotrebujú a nemali by byť medzi sebou prepojené, pretoţe kaţdá z nich je určená k prenášaniu špecifického typu dát. Základné zabezpečenie Toto zabezpečenie sa týka operačného systému. Tým je v prípade Avaya SBCE Red Hat Enterprise Linux, ktorý nedisponuje ţiadnymi nadbytočnými funkciami. Má len limitovaný počet portov a sluţieb, ktoré sú potrebné pre telefónne aplikácie, a ktoré závisia od počtu pripojených účastníkov. Takáto redukcia nepotrebných funkcií prispieva k zníţeniu počtu bezpečnostných aktualizácií a záplat. [19] 35

37 Zabezpečenie komunikácie Komunikácia môţe byť zabezpečená šifrovaním (signalizácie a médií) a to konkrétne TLS/SRTP alebo kontrolou prístupu. Kritéria pouţité pre kontrolu prístupu zahŕňajú zdrojovú podsieť, účastníka, URI skupinu alebo konkrétnu pouţitú SIP aplikáciu. [19] V prípade šifrovania médií pomocou SRTP Avaya SBCE podporuje prechod z práve šifrovaného SRTP na RTP, a to z dôvodu nízkej šírky pásma alebo v prípade keď to cieľový server nepodporuje. Podporuje aj opačný prechod z RTP na SRTP a modifikáciu kľúčov pomocou REINVITE. [21] Obr. 16 Ochrana IP-PBX pred útokmi Avaya SBCE ako bezpečnostný produkt zaisťuje integritu všetkých IP aplikácií v reálnom čase. Stará sa o celkovú bezpečnosť celej Avaya Aura architektúry, spoľahlivosť a dostupnosť, a to pomocou nasledujúcich troch funkcií [15]: Monitorovanie - poskytovanie kompletného bezpečnostného monitorovania, ktoré zahŕňa všetky aspekty UC siete vrátane koncových zariadení, ústrední, média brán a aplikačných serverov. K monitorovaniu poskytuje grafické rozhranie, ktoré sa nazýva EMS Web Interface. Toto rozhranie potom monitoruje a koordinuje bezpečnostné aktivity všetkých Avaya SBCE v sieti. Detekcia - detekčné schopnosti dynamických a adaptívnych algoritmov k detegovaniu rôznych anomálií v sieti. Detekcia týchto anomálií sa vzťahuje pre rôzne časové úseky dňa (dopoludnie, predpoludnie, noc) a víkendu. Sem spadá aj detekcia anomálií v obsahu SIP signalizačných správ. Ochrana - ide o poskytovanie ochrany blokovaním útokov zatiaľ čo je platná SIP komunikácia prepúšťaná ďalej. 36

38 Taktieţ chráni pred útokmi tretej, štvrtej vrstvy a skenovaniu portov. Napríklad zahŕňa IP firewall, ktorý zabráni preniknutiu neţelanej prevádzky do vnútra siete. Ďalej disponuje prevenciou zahltenia paketmi ICMP alebo TCP SYN, kde v prípade detekcie zablokuje po určitý čas zdroj takéhoto útoku. Tak isto po špecifickú dobu zablokuje účastníka, ktorý zahájil skenovanie dostupných portov v SBC. [21] Tab. 4 Zoznam použitých portov [22] Rozhranie Pripojenie Sluţba Protokol Port Verejný Interface Privátny Interface Manaţment Interface SIP UA Web Conf. TCP 843 LDAP TCP 636 LDAPs TCP 636 SIP TCP/UDP 5060 SIP TLS 5061 Média RTP IM TCP 5222 FW HTTP Download 80 FW HTTPS Download 443 PPM HTTP 80 PPM HTTPS 443 SIP PSTN Provider SIP TCP/UDP 5060 SIP TLS 5061 SM SIP Proxy / Access Elements /PPM SIP TCP/UDP 5060 SIP TLS 5061 PPM HTTP 80 PPM HTTPS 443 Media Gateways / Phones Media RTP Web Conf. Server Web Conf. TCP 843 Utility Server HTTP 80 HTTPS 443 EMS NTP UDP 123 Syslog TCP/UDP 514 Open VPN UDP 1194 HTTPS TCP 443 SSH TCP 222 DNS Server TCP/UDP 53 Syslog Server TCP/UDP 514 Admin Terminal SSH TCP 222 HTTPS TCP 443 SNMP UDP 161 UDP

39 Dôleţitým bezpečnostným prvkom je zabezpečenie proti DoS/DDoS útokom. Toto zabezpečenie sa vzťahuje buď k typu prevádzky, a to k remote workers, ku SIP trunku alebo jedno pravidlo vzťahujúce sa zároveň k obom typom prevádzky. Ďalším prvkom je aj zakrytie topológie, ktoré zmení kľúčové parametre SIP správy, aby znemoţnil neautorizovanému prístupu útočníka k informáciám o sieti. Do kategórie bezpečnosti patrí aj Protocol Scrubber, ktorý kontroluje prichádzajúcu prevádzku pouţitím štatistických mechanizmov a chráni pred škodlivými alebo zle formátovanými správami. Protocol Scrubber overuje napríklad sekvenciu správ, formátovanie správ, kontroluje dĺţku jednotlivých hlavičiek. Správy, ktoré Protocol Scrubber vyhodnotí ako chybné a zároveň škodlivé budú zahodené. Naopak správy, ktoré sú chybné, a ktoré nevyhodnotí ako škodlivé budú opravné. Tieto pravidlá sa vzťahujú na pouţitý typ prevádzky (SIP trunk alebo remote workers) a sú pripravené spoločnosťou Avaya, uţívateľ ich môţe meniť len minimálne. Avšak je dovolené inštalovať prídavné Protocol Scrubber balíčky. [21] Tab. 5 Inštalované Scrubber balíčky v Avaya SBCE [21] Balíček Popis Pouţitie v SBC móde SPKF Syntax Pravidlá zaloţené na RFC 3261 Trunk SPKF Protos Pravidlá zaloţená na teste SIP Protos Trunk, Remote worker SPKF OCS Pravidlá pre MS OCS/MS Lync - SPKF Avaya Pravidlá pre Avaya Remote worker 3.2 Avaya Aura Session Manager Vo firemnom prostredí môţe byť spravovanie VoIP komunikácií v reálnom čase komplikované a drahé, a to najmä vtedy, ak organizácia pouţíva niekoľko komunikačných ústrední, ktorých vzájomné prepojenie môţe byť zloţité. Session Manager (SM) dokáţe spravovať pripojenia ku všetkým týmto ústredňam a SIP aplikáciám. Session Manager (SM) je SIP telefónna ústredňa, ktorá naprieč celou sieťou spravuje účastníkov, aplikácie, ostatné ústredne a všetku komunikáciu medzi nimi. Spolupracuje s ostatými ústredňami v sieti a účastníkom poskytuje pripojenie a komunikáciu v reálnom čase bez ohľadu na to, kde sa v sieti nachádzajú. SM je v sieti SIP Proxy a zároveň aj Registrar serverom. Taktieţ ide o kľúčový prvok, ktorý vystupuje z radu obyčajnej telefónie a posúva sieť k Unnified Communications. 38

40 Obr. 17 SM ako centrum SIP siete [20] Poskytuje smerovanie hovorov medzi rôznymi poskytovateľmi sluţieb, a to na základe číslovacieho plánu alebo IP adresy. Smerovanie hovorov je moţné nastaviť podľa záťaţe siete, poruchy siete alebo doby kedy sú hovory uskutočnené. Podľa timeof-day a time-of-week smeruje hovory na základe najniţšej ceny. To má názov Leastcost routing. V prípade nejakej poruchy v sieti vyberá alternatívne smerovanie (Alternate routing). Nakoniec disponuje ešte funkciami rovnomerného rozdelenia záťaţe (Load ballancing) a presmerovaním hovorov kedy je vyčerpaná šírka pásma danej linky (Call admission control). Taktieţ poskytuje, respektíve, doručuje aplikácie naprieč celou sieťou. [23] Spravuje číslovacie plány, poskytuje rôzne monitorovacie nástroje, napríklad status pripojených SIP entít, komunikačné profily všetkých uţívateľov a indikácia registrácie uţívateľa, spravovanie pouţitia šírky pásma. K SM patria aj systémové nástroje akým je SIP trace a SIP monitoring. Tento SM je moţné pouţiť v stredne veľkých a veľkých organizáciách, kde v prípade nedostatku výkonu jedného servera je moţné pridávať ďalšie SM servery, a to aţ do počtu 12. Všetky tieto SM sú potom kvôli jednoduchosti spravované iba jediným SMGR. Momentálne existujú 2 typy serverov, ktoré je moţné pouţiť ako SM. Oba sú od firmy HP [23]: Avaya Common Servers Release 1- HP ProLiant DL360 G7 Power Edge R610 servers o je schopný spravovať uţívateľov počas beţnej prevádzky. o 100 relácií za sekundu ( za hodinu) o konkurenčných SIP relácií Avaya common Servers Release 1 - HP ProLiant DL360p G8 Power Edge R610 servers o je schopný spravovať uţívateľov počas beţnej prevádzky. 39

41 o 150 relácií za sekundu (540 za hodinu) o 160 konkurenčných SIP relácií Bezpečnosť Bezpečnosť sieťovej vrstvy SM podporuje VLAN segregáciu SIP a SIP manaţment sietí. SM má oddelené manaţérske rozhranie k manaţment komunikácii medzi SM a SMGR. SIP manaţment rozhranie sa nachádza v inej VLAN ako obyčajné SIP rozhranie, tak isto nie je moţné k nemu pristúpiť zo SIP siete. SMGR je prístupný len cez manaţment VLAN. SM pouţíva IPTables sieťový firewall kvôli ochrane proti sieťovým DoS útokom a k otvoreniu všetkých pouţívaných TCP/UDP portov. Nepouţívané porty sú uţ od základu zakázané. Firewall pravidlá sú nakonfigurované automaticky uţ počas inštalácie a poskytuje ochranu proti nasledujúcim sieťovým útokom [19]: TCP Syn Flood, IP Options, ICMP timestamps, ICMP Redirects, Source Routed Packets, Reverse Path Forwarding, neplatné IP pakety, škodlivé IP pakety. Bezpečnosť SIP SM pouţíva firewall aj na aplikačnej vrstve k ochrane proti SIP DoS útokom. Všetka zašifrovaná prevádzka pomocou TLS je rozšifrovaná ešte predtým neţ prejde cez SIP firewall. Ten poskytuje nasledujúce akcie [19]: Flood - ochrana pred záplavou SIP správ od špecifického zdroja, Advanced Flood Protection - táto ochrana vie detekovať alebo zmierniť útok z práve prebiehajúcej sip komunikácie z vopred definovaných zdrojov útoku, Rate-Limiting - toto pravidlo nastavuje limitovanie počtu SIP správ v určitom časovom intervale pri určitej prekročenej prevádzke, Rate-Blocking - blokuje všetku prevádzku z útočiaceho SIP zdroja, a to v prípade keď prevádzka dosiahne určitú medznú hranicu, Signature detection - je moţné nastaviť detekciu SIP správ, ktoré budú pri nájdení nejakého hľadaného výrazu zahodené. To platí pre hlavičku, tak ako aj pre telo SIP správy. SIP firewall sleduje SIP správy. Pri prekročení daného mnoţstva týchto správ za určitý čas je moţné vo firewalle pouţiť jednu z definovaných akcií [19]. Počet týchto pravidiel nie je nijako zvlášť obmedzený. Jedno takéto SIP firewall pravidlo z Tab. 10 sa skladá z nasledujúcich častí, ktoré je moţné navzájom nezávisle definovať. Týmito časťami sú [24]: 40

42 General Tu sa povoľuje a zakazuje dané pravidlo, názov pravidla log (či to bude alarm alebo len záznam) a nakoniec Action type. V Action type je na výber z rôznych moţností: No Action ţiadna akcia sa po pri aktivovaní pravidla nevykoná, táto moţnosť sa pouţíva v prípade, ţe chceme generovať alarm alebo záznam do logu, Permit pri aktivovaní tejto akcie je prevádzka pustená ďalej cez firewall bez toho, aby bola nejako obmedzená, Drop podľa nastavených treshold parametrov začne zahadzovať SIP prevádzku, Rate Block podľa nastavených treshold parametrov začne blokovať SIP prevádzku, Rate Limit podľa nastavených treshold parametrov začne limitovať SIP prevádzku. IP Layer Match Nastavenie SIP Firewallu, ktorý sa vzťahuje na Protocol (UDP, TLS, TCP), špecifickú IP adresu a rozsah portov. SIP Layer Match Tu je moţné nastaviť to, ktoré SIP hlavičky (SIP telo) budú kontrolované a aký výraz sa v nich v nich bude hľadať. Hľadaný výraz je moţné definovať ako string alebo regular expression. IP/SIP Layer Match Je moţné nastaviť iba pri Rate Limit alebo Rate Blok. V tejto časti sa nastavuje to, čo bude SIP Firewall (aké hlavičky) sledovať: IP adresu Port From To Contact Request Treshold Nastavenie hraničných hodnôt, pri ktorých sa pravidlo aktivuje a doby, počas ktorej bude trvať. Connections Nastavenie dôveryhodnej, nedôveryhodnej SIP entity alebo o UA. 41

43 K zablokovaniu alebo povoleniu určitých IP adries má SM k dispozícií Blacklist a Whitelist. Blakclist je moţné pouţiť v prípade, známeho zdroja DoS útoku alebo nejakej škodlivej správy. Kaţdá SIP správa prichádzajúca z IP adresy umiestnenej v Blackliste, bude zahodená, a to bez výraznejšieho vyťaţenia CPU. Whitelist je zas presný opak. Ten funguje tak, ţe kaţdá SIP správa, ktorá prichádza z IP adresy v ňom uloţenej bude posunutá ďalej na spracovanie, a to bez toho, aby boli aplikované ďalšie firewall pravidlá. Funkciu Whitelistu je moţné pouţiť v prípade ak vieme, ţe z danej SIP entity nám nemôţe hroziť ţiadny útok. To spôsobí zníţenie záťaţe CPU. Napríklad ak Avaya CM je priamo pripojená k SM, tak IP adresa CM môţe byť daná do Whitelistu, ale len v prípade, ţe aj SIP entity za CM sú dôveryhodné. SM je k operátorovi moţné pripojiť aj priamo, a to bez pouţitia SBC. Dobré nastavenie firewallu si dokáţe poradiť so SIP útokmi, celková kontrola nad týmto spojením a jeho bezpečnosť je však niţšia ako v prípade SBC. Tab. 6 Porovnanie SM a SBC pre pripojenie k SIP operátorovi [23] Vlastnosti SBC Session Manager Bezpečnosť Chráni sieť a všetky ostatné zariadenie pred DoS a DDoS útokom Pomocou šifrovania (Médií a signalizácie) chráni identitu a súkromie SIP konverzácie. Uplatňuje pravidla kontroly prístupu, a to limitovaním počtu prichádzajúcich relácií od SIP operátora K utajeniu topológie a vnútrosieťových koncových staníc poskytuje Sieťový preklad adries (NAT). Kontroluje prevádzku, zabezpečuje ochranu proti vírusom a červom z vonkajšej siete. To zahŕňa kontrolu paketov. Konektivita Podporuje 2000 konkurenčných SIP relácií. Podporuje manipuláciu čísla, URI a signalizácie. Zabezpečuje prepojenie šifrovaných a nešifrovaných relácií. Taktieţ zabezpečuje prepojenie rôznymi SIP a medzi SIP a H.323. Poskytuje preklad adries medzi privátnymi a verejnými alebo medzi IPv4 a IPv6 Poskytuje SDP a DTMF manipuláciu a prekódovanie Chráni servery a aplikácie Unnified Communication pred DoS a SIP DoS útokom Podporuje šifrovanie médií k zabezpečeniu hlasu Pomocou SMGR uplatňuje pravidla kontroly prístupu a autentizácie účastníkov. Neposkytuje sieťový preklad adries. Spolieha sa na to, ţe to za neho spraví SBC Kontroluje SIP prevádzku a vo vnútri siete zabraňuje škodlivým správam k dosiahnutiu danej aplikácie Podporuje konkurenčných SIP relácií Podporuje manipuláciu čísla, URI a signalizácie. Zabezpečuje prepojenie šifrovaných (TLS) a nešifrovaných relácií. Neposkytuje preklad adries. N/A 42

44 3.3 Avaya Aura System Manager System Manager (SMGR) je bezpečný centralizovaný systém, ktorý poskytuje správu celej VoIP siete. Tá zahŕňa správu pouţívateľov, správu volacieho plánu, smerovanie hovorov a v neposlednom rade aj monitorovanie výkonu a porúch. Pomocou grafického webového rozhrania zabezpečuje správu všetkých Avaya severov, ktoré patria do skupiny Avaya Aura. V mojom prípade som ho pouţil k manaţovaniu SM a celej mojej VoIP siete. Priamo do SM som pristupoval len pomocou CLI a to za účelom sledovania práve prebiehajúcej prevádzky v reálnom čase. K nastaveniu SM som pristupovali cez SMGR. Výhodou SMGR je to, ţe je jediný riadiaci bod v celej sieti. V prípade veľkej siete zniţuje jej komplexnosť. Relatívne jednoduchým nastavením sa snaţí čo najviac zamedziť konfiguračným chybám. Operačným systémom CentOS s balíčkami Avaya Aura systémovej platformy. [25] Tab. 7 Kapacita SMGR [25] Kapacita Maximálny limit Administrátorské prihlásenia 250 Súčasné administrátorské prihlásenia 50 Koncové zariadenia SIP koncové zariadenia Koncový uţívatelia Mailboxy Kontakty jedného uţívateľa 250 Verejné kontakty Kontaktný list jedného uţívateľa 1 Skupiny 300 Členovia v skupine 400 Elementy Communication Manager 500 Session Manager 12 Gateway Role 200 Role jedného uţívateľa SIP Klienti Pri písaní diplomovej práce som prišiel do kontaktu aj s Avaya SIP klientmi. Jedným z nich bol stolný telefón Avaya 9601 SIP IP Deskphone, ktorý je moţné pouţívať ako SIP a aj ako H.323 telefón. Tento telefón slúţi ako terminál. Jeho funkcie ako napr. telefónny zoznam sa nevzťahujú k telefónu ako takému. Účastník sa môţe prihlásiť na akýkoľvek telefón a vţdy bude mať prístup k svojím osobným nastaveniam a k adresáru. Je napájaný funkciou PoE. Disponuje ešte druhým 10/100 Eternetovým portom pre pripojenie počítača a následné zredukovanie kabeláţe na pracovnom stole. 43

45 Druhým Avaya SIP klientom, s ktorými som prišiel do kontaktu je Avaya One-X Communicator. Ten je tzv. softphone, čo je softvérový SIP klient, ktorý zvláda prenos hlasu, videa, u, hlasovej schránky a faxu. Uţívateľovi poskytuje jednoduchý a intuitívny prístup ku kaţdodennej komunikácii. Existuje verzia pre osobný počítač a mobilná verzia pre ios, Android a Windows Phone. Pri inštalácii Avaya One-X Communicator na vlastný mobilný telefón alebo počítač (BYOD v kap. 1.3) je potrebné zváţiť zabezpečenie pomocou SBC. 44

46 4 Praktická časť V tejto kapitole sa budem venovať praktickej časti diplomovej práce. Tu zhodnotím moţnosti útoku a spôsoby zvýšenia bezpečnosti v Avaya Aura architektúre. Všetko potrebné vybavenie vrátane serverov mi bolo poskytnuté firmou Algotech. Tá uţ mala nainštalované testovacie prostredie, ktoré obsahovalo nainštalovaný SM a SMGR. Tieto servery obsahovali základnú sieťovú konfiguráciu. Čo sa SBC týka, tak ten som si do daného testovacieho prostredia doinštaloval a nakonfiguroval sám. 4.1 Implementácia Avaya Aura a Inštalácia Avaya SBCE Celú testovaciu Avaya Aura architektúru reprezentovali v mojom prípade SM a SMGR. V sieti bol pripojený aj CM, no ten uţ bol v ostrej prevádzke a vo firme Algotech spravoval všetku komunikáciu medzi H.323 telefónmi. Jenou z mojích úloh bola konfigurácia Avaya Aura serverov a pripojenia SBC ako ochranného prvku. Návodom k tejto konfigurácii mi boli aplikačné poznámky od firmy Avaya, ku ktorým som dostali prístup cez firmu Algotech. Počas implementácie sa často vyskytli aj nepredvídateľné konfiguračné problémy. Pri riešení váţnejších takýchto konfiguračných problémov, mi výrazne pomohli Avaya Online Support Adresovanie siete Tab. 8 Adresovanie siete Server Zariadenie IP adresa Maska Brána System Manager SMGR / Session Manager SM (Session Manager) SM - CLI /24 / Session Border Controller SBC - M1 SBC - A1 SBC - B /24 /24 / DNS prim. DNS sec. NTP server UA SIP klient DHCP DHCP DHCP V Tab. 8 sú uvedené všetky IP adresy, ktoré som v Avaya Aura architektúre pouţil. IP adresa bola verejná a všetky ostatné pouţité IP adresy boli privátne. Použité servery tieto servery boli zo skupiny Common Servers Release 1: SM - HP ProLiant DL360 G7, štvorjadrový procesor Intel Xeon E5620 ( 2,4 GHz, 12MB cache), 12GB (3x4GB) DDR3 1333MHz, 4x1Gb Ethernet, HDD 2x 300GB. SBC - Dell PowerEdge R210 II, štvorjadrový procesor Intel Xeon E (3,1GHz, 8MB cache), 8GB DDR3 1600MHz (aţ 32GB), 6x1Gb Ethernet 45

47 SMGR - HP ProLiant DL360 G7, štvorjadrový procesor Intel Xeon E5620 ( 2,4 GHz, 12MB cache), 12GB (3x4GB) DDR3 1333MHz, 4x1Gb Ethernet, HDD 2x 300GB Použitý SIP klienti: Avaya One-X Communicator Avaya 9601 SIP IP Deskphone Empathy Linphone Inštalácia a základné nastavenie SBC K pripojeniu na server som pouţili sériový port (CLI Obr. 18), program Putty s rýchlosťou Bd. Po chvíli mi server ponúkol moţnosti bootovania. Bootoval som z USB disku, na ktorom bol skopírovaný systém Avaya Session Border Controller for Enterprise Release Q16 FP1 Service Pack 1 GA. Pribliţne po hodine inštalácie sa server spýtal na jeho základnú konfiguráciu, kde bolo potrebné zadať IP adresu, masku siete a bránu pre port M1. Tento port bude slúţiť ako manaţment SBC. V ďalšom kroku sa server spýtal na meno domény siete, DNS a NTP server. Inštalácia bola vykonaná bez fyzického pripojenia k sieti a SBC sa nutne potrebovalo pripojiť k NTP serveru, tak ten som podľa Tab. 8 pripojili k smerovaču Cisco. Tam som na interface0/0 nastavili IP adresu brány a na interface0/1 IP adresu NTP servera. Na smerovači som vykonal príkaz ntp master a SBC si týmto mohlo zosynchronizovať čas. Nakoniec bol na SBC nainštalovaný najnovší patch, a to Release Q18. Po dokončení inštaláci bolo SBC pripravené na odvoz do serverovne. Kaţdý ďalší prístup k SBC uţ bol vykonávaný vzdialene. Z pohľadu zvýšenia bezpečnosti je vhodné zvoliť čo najsilnejšie prístupové heslo pre administrátorský účet a heslo si bezpečne uchovať. SBC ponúka moţnosť nakonfigurovať viacerých uţívateľov čo sa hodí v prípade, keď je potrebné dať administrátorský prístup viacerým ľuďom. Noví uţívatelia môţu byť nakonfigurovaní s rôznymi právami. Vo väčšej firme je takto moţné dať prístup ku konfigurácii viacerým ľuďom a stále mať SBC plne pod kontrolou. 46

48 Obr. 18 Fyzické zapojenie SBC [26] A1 Externá sieť B1 interná sieť M1 manaţment SBC CLI sériový port Obr. 19 Základné nastavenie SBC 47

49 Obr. 20 Natavenie Server Flows Obr. 21 Nastavenie Subscriber Flows 4.2 Možnosti útoku a spôsoby zabezpečenia Na zabezpečenie Avaya Aura architektúry som sa pozeral z troch pohľadov (kap ). Zaoberal som sa hlavne bezpečnosťou architektúry zapojenia a zabezpečením komunikácie. Tretiemu z bezpečnostných pohľadov (základné zabezpečenie, ktoré sa týkalo viac operačného systému ako SIP) som sa v tejto diplomovej práci nevenoval. 48

50 Popisujem však všetky dostupné VoIP bezpečnostné mechanizmy, ktoré Avaya Aura spolu s Avaya SBCE spolu ponúkajú Návrh bezpečnej architektúry Predtým neţ sa bude sieťový administrátor zaoberať rôznym nastavením zabezpečenia komunikácie bude musieť riešiť spôsob zapojenia Avaya Aura architektúry v siete. Pod týmto sa myslí hlavne zapojenie SBC, a to ako bezpečnostného prvku Avaya Aura architektúry. Nastavenie bezpečnosti príde na rad aţ vo chvíli, keď bude celá architektúra fyzicky zapojená a nakonfigurovaná. V kap. 2.2 som opísal moţnosti zapojenia SBC v sieti. V tejto kapitole sa pozriem na to, ktorá z týchto moţností je z pohľadu bezpečnosti najoptimalnejšia, a ako by sa táto bezpečnosť ešte dala zvýšiť. Nebolo by vhodné pripojiť ústredňu priamo k internetu lebo kaţdý útok na túto ústredňu by mohol ovplyvniť funkčnosť SIP sluţieb. Preto úplne najjednoduchším zapojením by bolo zapojenie, kedy je SBC umiestnené na okraji siete a jedna strana je pripojená k internetu alebo k operátorovi a tá druhá k ústredni. Takto vytvorí SBC hraničný prvok medzi internetom a ústredňou, ktorý bol akýmsi nárazníkom. Zatiaľ čo bude SBC vyčerpávať svoje zdroje na obranu pred hrozbami z internetu, tak ústredňa je aj naďalej schopná ničím nerušene vykonávať svoju prácu. Toto základné zapojenie je vhodné ďalej zabezpečiť firewallom, ktorý by bol umiestnený buď pred, alebo za SBC. Rozhodnutie toho aké postavenie medzi sebou SBC alebo firewall zaujmú závisí od bezpečnostných zásad aké firma pouţíva a spôsobom vyuţitia SBC (kap. 2.2). Napríklad či firma pouţíva SIP trunk alebo remote workers. V prípade, ţe má firma nadefinované bezpečnostné pravidlo, v ktorom stojí ţe firewall je jediné zariadenie, ktoré rozhodne o tom čo do siete pustí a čo nie, tak pôjde SBC za neho. Intranet Internet PSTN A1 A1 SBC B1 Firewall Obr. 22 SBC za Firewallom Rovnako je výhodné uloţiť SBC za firewall v prípade, ţe je pouţitá funkcia remote workers, ktorá vyuţíva viac neţ SIP komunikáciu. Naopak, ak sa jedná len o pouţitie SIP trunku tak môţe byť SBC aj pred firewallom. Takúto spoluprácu firewallu a SBC je ďalej nutné nakonfigurovať tak, aby prenos médií a všetka komunikácia na portoch 5060 (UDP) a 5061 (TLS) šla priamo k SBC a nebola ďalej 49

51 spracovávaná firewallom. Tak isto je vhodné oddeliť SIP komunikáciu do osobitnej VLAN. Intranet Internet Firewall A1 SBC B1 PSTN Obr. 23 SBC pred Firewallom Ešte bezpečnejším spôsobom zapojenia je uloţenie SBC do DMZ, ktorá pridáva ďalšiu pomyselnú bezpečnostnú vrstvu. Ide o nasadenie SBC medzi interný a externý firewall oddelených do rôznych LAN sietí. Takto útočník zaútočí iba na servery, ktoré sa nachádzajú v DMZ. Všetko čo je za ňou, vrátane ústredne je pre neho skryté. Toto konkrétne zapojenie je doporučené aj firmou Avaya [15]. Posledným spôsobom ako zapojiť SBC je zapojenie viacerých SBC za sebou (Obr. 24). Zapojenie, ktorého silná stránka je v tom, ţe vo firewalle nie je potrebné povoľovať všetky moţné porty pre média a týmto sa zníţi počet pouţívaných portov. V tomto prípade stačí medzi oboma SBC nastaviť trunk. Komunikácia prebiehajúca týmto trunkom prejde cez firewall len jedným portom. Ide hlavne o média, pre ktoré musia byť v internom firewalle povolené porty. Cez firewall medzi SBC1 a SBC 2 bude prechádzať signalizácia média iba jedným portom. Média sú priamo preposielané k UA aţ druhým SBC 2. Vzniká scenár back-to-back-to-back komunikácie (B2B2B). V tomto spôsobe zapojenia stačí aj na internom firewalle povoliť iba jeden port pre trunk. Toto zapojenie ma výhodu v jednoduchšej konfigurácii a správe firewallu. Nevýhodou ostáva potreba dvoch SBC a to predstavuje kúpu ďalšieho hardvéru. (to však pre firmu nemusí byť veľmi výhodné). Iná situácia nastane v prípade virtualizácie SBC, kde uţ nebude potrebné zakúpiť nový drahý server. Avaya uţ začala podporovať virtualizáciu SBC v dobe písania tejto diplomovej práca. 50

52 Signalizácia Média Intranet DMZ Internet Interná sieť IP PBX A1 B1 A1 B1 Interný Firewall 1 Externý Firewall SBC 2 SBC 1 PSTN Obr. 24 Bezpečné zapojenie Spomenul by som ešte jedno zapojenie. Nepatrí do kategórie tých v úvodzovkách najbezpečnejších, ale v určitých prípadoch môţe byť nápomocné. Je to zapojenie kedy je z portov A1, B1, A2, B2 pouţitý iba jeden z nich, a to A1. SBC je v tomto prípade nakonfigurované prijať prevádzku týmto jedným portom a po spracovaní ju tým istým portom presmerovať ďalej k ústredni. Konfigurácia Avaya SBC túto moţnosť povoľuje. Výhodou by bolo napríklad uvoľnenie jedného portu. Pri tejto komunikácii je nutné nastaviť smerovanie v sieti tak, aby všetka SIP prevádzka prešla cez SBC. Signalizácia Intranet DMZ Internet Interná sieť PSTN Interný Firewall A1 Externý Firewall SBC 1 Obr. 25 Signalizácia pri zapojení len jedného rozhrania Všetky tieto zapojenia sú typu NNI a SBC je uloţené na hranici siete. V internej sieti a v zapojení typu UNI uţ nejde o SIP trunk, ale priamo uţívatelia sa pripájajú na SM cez SBC vo vnútri siete. Toto zapojenie v prípade Avaya Aura však nemusí byť veľmi efektívne. Svoj účel to síce splní, ale všetkých účastníkov je moţné týmto spôsobom pripojiť aj priamo k SM, ktorý prípadné DoS/DDoS útoky z vnútra siete dokáţe odraziť. Pri písaní tejto diplomovej práce som sa nestretol s potrebou pouţiť SBC vo vnútri siete, bez toho aby bolo nakonfigurované v móde remote workers a v inom prípade ako pri trende BYOD. Správnou konfiguráciou SIP firewallu v SM, a pri priamom pripojení účastníkov v internej sieti, je moţné aj bez SBC dosiahnuť bezproblémový a bezpečný chod siete. Iné by to bolo v prípade remote workers kedy sa účastníci pripájajú z internetu a SBC je umiestené na okraji siete. 51

53 Posledným bezpečnostným prvkom, ktorý sa týka architektúry siete, a ktorý je určite vhodné pouţiť, je zapojenie SBC do HA. V prípade výpadku jedného SBC prevezme jeho činnosť to druhé. V tomto prípade sú potrebné 3 servery. Dva SBC a jeden riadiaci server, ktorý tieto 2 SBC synchronizuje a v prípade problému odstaví nefunkčné SBC a na jeho miesto dosadí to funkčné. Avaya ponúka túto moţnosť uţ pri inštalácii SBC Zabezpečenie komunikácie Z pohľadu zabezpečenia komunikácie ide o celú škálu mechanizmov pouţitých k tomuto účelu. Pouţitím, správnym nastavením a kombináciou všetkých z nich vznikne relatívne celkom zabezpečená sieť. Vravíme relatívne, pretoţe sieť je taká bezpečná ako zabezpečenie toho najslabšieho článku v nej. Existuje stále veľa moţností ako VoIP napadnúť, a to pokojne aj útokom na niţšej vrstve podľa Tab. 1. Prvým z mechanizmov pouţitým k zabezpečeniu komunikácie je autorizácia. Avaya pouţíva uţ v základnom nastavení digest autorizáciu. Tá zabráni útočníkovi k jeho neţiaducemu prístupu a to tým, ţe na prihlásenie bude potrebovať meno a heslo. Je nutné však pouţívať kvalitné heslá, ktoré nebude moţné pomocou metódy hrubej sily odhaliť. To v prípade soft SIP klienta nie je problém. Problém nastáva pri telefónoch Avaya. V telefónoch Avaya, s ktorými som prišiel do kontaktu môţe byť dĺţka a zloţitosť hesla slabinou celej siete, pretoţe tieto telefóny podporujú len číselné heslá, a to s dĺţkou maximálne 8 miest. Predpokladám, ţe nie kaţdý si zvolí maximálnu dĺţku hesla. Napríklad také 4 miestne heslo je pri nesprávne nastavenom firewallu moţné prelomiť pomocou metódy hrubej sily s dnes úplne obyčajným notebookom (Dual Core 2,2 GHz, 4GB RAM) do niekoľkých sekúnd. K overeniu tohto tvrdenia som pouţil skript (kolekciu skriptov) napísaný v jazyku Python, ktorý sa volá SIP Vicious [27]. V mojom prípade som pouţili konkrétne skript s názvom svcrack - bruteforce utilita, ktorá skúšala všetky moţné číselné kombinácie hesiel. Na základe tohto výsledku som prepočítal dobu prelomenia pre rôzny počet cifier. Prepočítané odhady pri rôzne dlhých heslách sú zobrazené v Tab. 9. Tabuľka nezobrazuje presné doby trvania odhadu hesla, je to len pribliţný odhad. Tomuto sa však dá zamedziť konfiguráciou maximálneho počtu registračných pokusov, ktoré má SIP účastník povolené v určitej dobe vyčerpať. Toto nastavenie sa vzťahuje na nastavenie firewallu a je bliţšie popísané v kapitolách týkajúcich sa SIP firewallu. Konkrétne ide o SIP firewall pravidlá - Obmedzenie a alarm vysokého počtu REGISTER od jedného UA a jednej IP (Tab. 10). Tab. 9 Doby trvania prelomenia hesla Počet cifier Pribliţná doba prelomenia hesla hesla 4 - ciferné heslo 20 sekúnd 5 - ciferné heslo 27 minút 6 - ciferné heslo 4,5 hodín 7 - ciferné heslo 2 dni 8 - ciferné heslo 2 týţdne 52

54 4.2.3 Kontrola prístupu (Autorizácia a autentifikácia) Oba servery, Avaya SM a tak isto aj Avaya SBCE, pouţívajú digest autorizáciu, ktorú uţ majú nastavenú a nedá sa v prípade potreby vypnúť. Autorizácia sa pouţíva pri všetkých SIP poţiadavkách REGISTER, INVITE a BYE. WWW-Authenticate a následná odpoveď Authorization vyzerala v mojom prípade nasledovne: WWW-Authenticate: Digest realm= abg.net, qop= auth, opaque= abcedef,nonce= 14a21a406cbffac10c53c021c503c89e0d2D 77d27c1,algorithm=MD5,stale=false Authorization: Digest username= 560, realm= abg.net, nonce= 14a21a406cbffac10c53c021c503c89e0d2D77d27c1, uri=sip:ab.net, response= ebef1c ee589bdac95f36a870, algorithm=md5, cnonce= 0a4f113b, opaque= abcedef, qop=auth, nc= Ďalšou funkciou zabezpečujúcou kontrolu prístupu je povolenie prístupu iba určitému klientovi. Táto funkcia je dostupná len v SBC a ide jej o zabránenie pouţitia neznámeho SIP klienta. Napríklad pri trende BYOD, kde si uţívateľ môţe nainštalovať SIP klienta podľa svojho vlastného uváţenia. Administrátor si to môţe ako-tak odkontrolovať v SBC Global Parameters User Agents. Táto funkcia však nie je nejako výrazne ošetrená, pretoţe jediné čo robí je porovnávanie zhody názvu v SIP hlavičke User-Agent so zadaným názvom v tabuľke. Zabezpečenie sa dá preto veľmi ľahko obísť vhodným prepísaním SIP hlavičky User-Agent. Kontrolu prístupu je moţné kontrolovať aj podľa účastníka alebo URI skupiny do ktorej patrí, takto je moţné kaţdej skupine alebo účastníkovi nastaviť vlastné práva, smerovanie alebo kontrolu prístupu. Nastavenie: SBC Global Parameters URI Groups Šifrovanie Oba servery (SM aj SBC) podporujú zabezpečený prenos SIP signalizácie pomocou TLS. Veľa útokov je moţné realizovať len vďaka tomu, ţe v sieti nie je pouţité šifrovanie. Ak je vo VoIP sieti pouţité šifrovanie signalizácie tak z bezpečnostného pohľadu odpadne veľké mnoţstvo potenciálnych hrozieb. Šifrovanie signalizácie pomocou TLS je preto z hľadiska bezpečnosti výhodné nasadiť. Lenţe existuje niekoľko ďalších uhlov pohľadov kedy to uţ tak výhodné nie je. Dôvody sú rôzne, ale medzi tie najhlavnejšie patrí to, ţe v prípade TLS sa zloţito riešia problémy v sieti. SIP prevádzka šifrovaná protokolom TLS je neviditeľná aj pre administrátora, ktorý tam preto radšej nastaví UDP a získa väčší prehľad o dianí v sieti. Ďalším z dôvodov je zaistenie kompatibility, pretoţe veľa systémov to nepodporuje. V neposlednom rade ide šifrovanie aj na úkor výkonu, kde pokles počtu hovorov je taký výrazný (napr. Tab. 3), ţe je pre väčšiu firmu z ekonomického hľadiska výhodnejšie tam to TLS nepouţiť. Nepouţitím TLS šifrovania zostáva veľké bezpečnostné riziko. Pokiaľ by sieť nebola zabezpečená iným spôsobom, ktorý sa uţ nemusí priamo týkať SIP signalizácie, tak kdekoľvek v organizácii si útočník nájde voľný kábel a je schopný nahliadnuť do prevádzky siete. 53

55 Je potrebné zváţiť pouţitie TLS a nasadiť ho tam, kde má naozaj význam. Existujú však dôvody kedy je pouţitie TLS priam samozrejmosťou. Ide o prípad kedy funguje SBC v móde remote workers, a to z dôvodu priameho pripojenia do verejnej siete. Podporu šifrovaného prenosu médií (SRTP) uţ podporuje len SBC. SM touto funkciou nedisponuje pretoţe Session Manager médiá neprenáša. Opäť tu však SRTP pripadá na zváţenie. Aj keď zabráni záškodnému odpočúvaniu hovorov, tak organizácia sa pripravuje o pouţitie nahrávania, čo v niektorých prípadoch (napr. Call centrum) môţe byť nevýhoda. V neposlednom rade zniţuje počet dostupných konkurenčných SIP relácií. V prípade, ţe sa organizácia rozhodne pouţiť šifrovaný prenos SIP signalizácie (TLS) alebo médií (SRTP), tak Avaya odporúča pouţiť CA certifikáty tretích strán avšak ponúka aj vlastné. Natavenie SRTP je v SBC Domain Policies Media Rules Media Encryption. Natavenie TLS v je v SBC TLS Management Client Profiles. Daný profil je potom následne potrebné priradiť k Subscriber alebo Server Flows v SBC Device Specific Settings End Poit Flows. V SM to bude SM Routing Entity Links Protocol a certifikáty v SM Services Security Certificates Nastavenie SIP firewallu v SM Nastavenie SIP firewallu bude závisieť hlavne od toho, ako sa daný SM správa pri zvýšenej prevádzke. Preto sme s mojím kolegom Ondrou Kovářem, ktorý na moju architektúru útočil, simulovali DoS útok pomocou voľne prístupného programu SIPp a sledovali vyťaţenie procesora na SM. Pouţili sme dva počítače. Oba počítače boli vybavené najnovším procesorom Intel i7 a 16 GB pamäťou RAM. Týmto sa tieto notebooky výkonnostne radili medzi vyššiu triedu. Test sme skúšali najprv s jedným počítačom a potom sme pridali druhý, následne sme pocítili asi 10 % nárast vyťaţenia CPU na SM. Tento útok prebiehal tak, ţe sme z dvoch počítačov, na ktorých beţal SIPp postupne zaplavovali ústredňu SIP prevádzkou. Túto prevádzku tvorili transakcie REGISTER, INVITE, OPTION a nakoniec ešte REGISTER spolu s INVITE. Nakoniec sme ešte pridali tretí počítač, ten sa uţ radil medzi tie slabšie a ţiadny ďalší výrazný nárast vyťaţenia CPU uţ nenastal. Vo výslednom grafe (Graf 1) je vidieť výsledok testu smerovaného na Avaya Aura Session Manger. 54

56 Počet správ [tis.] Výkon CPU [%] ČVUT Graf 1 Závislosť vyťaženie CPU SM od času s vypnutým SIP firewallom Čas [s] REGISTER INVITE OPTIONS REGISTER+INVITE Na grafe (Graf 1) je vidieť, ako sme postupne kaţdých 30 sekúnd navýšili počet odoslaných správ o 100 za sekundu. Počiatočná hodnota bola 10 správ za sekundu. Hodnotu 30 sekúnd sme zvolili preto, lebo pri nej hodnote uţ bolo vyťaţenie procesora po predošlom náraste relatívne ustálené. Takto sme zvyšovali prevádzku aţ sa hodnota počtu odoslaných správ priblíţila k , počet vyslaných správ je zobrazený v grafe (Graf 2). Je viditeľné, ako po tejto hodnote prestáva SM odpovedať na správy. Graf 2 Závislosť počtu správ od času s vypnutým SM SIP firewallom Čas [s] Vyslané správy Správy na ktoré prišla odpoveď od SM Počas trvania testu sme skúšali aj obyčajné hovory. Čo vlastne simulovalo účastníka, ktorý sa počas takéhoto DoS útoku snaţí niekam dovolať. Volali sme na striedačku z jedného klienta na druhý. Výsledkom nášho testu bolo 12 neúspešných hovorov z 20 (Graf 3). Čím by náš útok uţ mohol uţívateľovi znepríjemniť deň. 55

57 Výkon CPU [%] ČVUT Graf 3 Pomer úspešných a neúspešných hovorov počas simulácie DoS útoku Hodnota je maximálny počet SIP relácií, ktoré dokáţe SM bez problémov odbaviť a je definovaná spoločnosťou Avaya (kap. 3.2). Táto hodnota nebola fixne daná. Niekedy sme sa dostali aj nad Čo svedčí v prospech SM konkurenčných SIP relácií bolo však minimom, ktoré sme potom zohľadnili pri návrhu SIP firewallových pravidiel v SM. Celý tento test prebiehal s vypnutým SIP firewallom, po jeho nakonfigurovaní uţ bola situácia odlišná. Priebeh testu je zobrazený v grafe (Graf 4). Na ňom je vidieť, ako po poslaní veľkého mnoţstva správ bol SIP firewall schopný odhaliť a zachytiť náš útok. Polovičné vyťaţenie procesora trvalo pribliţne iba jednu sekundu. So serverom sa nič nedialo ani pri ďalšom zvyšovaní počtu záškodníckych SIP správ. Tu je vidieť, ţe SIP Firewall zmysel má a to taký, ţe ţiadny legitímny hovor počas tohto útoku, nebol ovplyvnený. V praxi by to znamenalo, ţe kaţdý účastník by sa bez problémov dovolal aj v prípade, ţe by sa niekto snaţil o zahltenie ústredne. Nastavenie SIP Firewallu je však relatívne a je taktieţ veľmi subjektívnou záleţitosťou, pretoţe kaţdý má iné bezpečnostné poţiadavky a kaţdá firma môţe mať ináč nastavený DoS limit. Respektíve limit, kedy uţ firma povaţuje zvýšenú prevádzku v sieti za DoS útok. Nejaká malá firma s pár telefónni môţe uţ pár INVITE poţiadaviek za minútu povaţovať za útok. Zatiaľ čo pre inú väčšiu firmu nemusia ani stovky INVITE poţiadaviek za minútu predstavovať ţiadny problém. Graf 4 Závislosť vyťaženia CPU SM od času so zapnutým SIP firewallom ,00 2,00 4,00 6,00 8,00 Čas [s] OPTIONS REGISTER INVITE REGISTER+INVITE V prípade REGISTER SIP správy nemusí ísť len o simuláciu útoku, kde útočník záškodne posiela REGSITER poţiadavky, tento test mohol simulovať aj výpadok SM 56

58 a jeho následný reštart. Po reštarte SM by sa začali všetci uţívatelia naraz registrovať. SM nemal problém aj pri vypnutom SIP firewalle zaregistrovať 500 účastníkov za sekundu. Pri registrácii účastníkov za sekundu a vypnutom firewalle uţ začal na nejaké poţiadavky nereagovať, no v konečnom dôsledku by boli všetci uţívatelia zaregistrovaní. Pretoţe uţívateľ bude posielať REGISTER pokiaľ sa úspešne nezaregistruje. V nasledujúcej tabuľke sú prehľadne znázornené všetky pouţité pravidlá SIP firewallu, ktoré boli pri našom teste pouţité. Pravidlá je moţné kombinovať v ľubovoľnom mnoţstve. Vysvetlenie toho, čo všetky tie pojmy v tabuľke znamenajú je v kap Toto nastavenie je pozmenené základné nastavenie SIP Firewallu od firmy Avaya, ktoré by podľa nej malo byť modifikované len v prípade potreby. Tab. 10 Nastavenie Firewallu Typ záznamu Počet správ Perioda [s] Timeout [s] Názov Typ akcie Obmedzenie a alarm vysokého počtu INVITE od jedného UA Rate Limit A+Z Obmedzenie a alarm vysokého počtu REGISTER od jedného UA Rate Limit A+Z Obmedzenie a alarm vysokého počtu OPTIONS od jedného UA Rate Limit A+Z Obmedzenie a alarm vysokého počtu INVITE z jednej IP Rate Limit A+Z Obmedzenie a alarm vysokého počtu REGISTER z jednej IP Rate Limit A+Z Obmedzenie a alarm vysokého počtu OPTIONS z jednej IP Rate Limit A+Z Vysoká prevádzka od jedného UA Rate Limit A+Z Vysoká prevádzka z jednej IP adresy Rate Limit A+Z A Alarm Z Záznam do logu Toto nastavenie Firewallu je moţné pri reálnej prevádzke prispôsobiť, no je však potrebné poznať priemerné počty aktívnych uţívateľov a aktívnych hovorov. Podľa nich sa potom dajú detekovať prípadné anomálie v sieti. Táto detekcia môţe prebiehať napríklad nastavením pravidla Firewallu na poţadovaný detekovaný počet správ, ako typ akcie zvoliť No Action a následne zaznamenať do logu SM. V prípade SM sa SIP firewall nastavuje cez SMGR v sekcii SM Network Configuration SIP Firewall. Tu je moţné definovať rôzne typy nastavenia firewallu (Tab. 10). Tak isto je moţné pridať vopred známe IP adresy do Blacklistu alebo 57

59 Výkon CPU [%] ČVUT Whitelistu. Po tom, čo sú nadefinované jednotlivé pravidlá SIP firewallu, tak je potrebné ich priradiť k SM a to nastavením: SM Network Configuration SIP Firewall Označiť Rule Set Assign Vybrať SM, na ktorý bude aplikovaný firewall Commit Nastavenie Firewallu v SBC Rovnaký test aký sme previedli v prípade SM, tak sme testovali aj pri zapojení SBC pred SM. Tento test bol opäť s vypnutým firewallom, tentokrát však uţ na SBC. Oba servery boli zapojené podľa Obr. 22. a v móde remote worker. Architektúra zapojenia však nemala ţiadny vplyv na tento test. Opäť sme pouţili dva počítače z predchádzajúcej kapitoly a sledovali vyťaţenie CPU oboch serverov zobrazené na Graf 5 a Graf 6. Prevádzka najskôr prechádzala cez SBC (Graf 5) a potom následne do SM (Graf 6). V tomto prípade, však SBC prestalo odbavovať naše záškodnícke správy oveľa skôr ako samotný SM v teste predtým. Počet konkurenčných hovorov sa pohyboval okolo hodnoty 2 000, čo bol maximálny počet remote workers definovaný firmou Avaya podľa Tab. 3. Na grafe je vidieť, ţe aj keď sa SBC celkom nudil, tak aj tak začal zahadzovať hovory. Z toho je moţné vidieť, ţe SBC neplní rolu len bezpečnostného prvku ale nejaké prostriedky si necháva aj na jeho ostatné funkcie. 25 Graf 5 Závislosť vyťaženia CPU SBC od času s vypnutým SBC SIP firewallom REGISTER Čas [s] Ďalší graf, Graf 6, zobrazuje prepustenú prevádzku z SBC na SM. Z predošlého testu však vieme, ţe je schopný zvládnuť oveľa viac. V reálnej prevádzke nebude spracovávať len poţiadavky od SBC ale aj priamo pripojených účastníkov. Tých je však s pomocou SBC schopný ochrániť. V prípade útoku budú vyťaţené len zdroje SBC a vnútro siete na čele s SM bude ďalej fungovať. Obmedzenie sa bude vzťahovať len na tých pár remote workers pripojených k SBC. 58

60 Výkon CPU [%] ČVUT Graf 6 Závislosť vyťaženia CPU SM od času so zapojeným SBC REGISTER Čas [s] Konfigurácia proti DoS/DDoS útokom v SBC umoţňuje jednoducho vytvárať a editovať rôzne pravidlá. Typovo je podobná SM. Nastavuje sa v SBC Global Parameters DoS/DDoS Edit. Tu je moţné nastaviť: Single Source DoS Tento typ útoku je proti jednému alebo viacerým koncovým bodom v sieti, a to práve od jedného zdroja. Toto pravidlo je firmou Avaya nastavené na akciu Alert Only, a to upozorniť na všetky správy od jedného zdroja, ktoré prekročia prahové hodnoty 300 SIP správ za 5 sekúnd. Túto hranicu je moţné ľubovoľne nastaviť a priradiť jej jednu z nasledujúcich akcií: Alert Only informuje o prekročenej prahovej hranici, Block zablokuje prevádzku, SIP Challenge zaháji autentizáciu. Obr. 26 Single Source DoS Phone DoS/DDoS Typ DoS útoku, ktorý útočí práve na jeden koncový bod. V tomto prípade je tak isto moţné ľubovoľne nastaviť prahovú hranicu. Základné nastavenie je definované na 200 sip správ za 3 sekundy, ktoré sa vzťahujú na všetky SIP sluţby a metódy. K prekročeniu prahovej hodnoty je moţné priradiť nasledujúce akcie, kde oproti predchádzajúcemu prípade pribudne jedna navyše: Alert Only informuje o prekročenej prahovej hodnoty, Block zablokuje prevádzku, SIP Challenge zaháji autentizáciu, 59

61 Enforce Limits neblokuje ţiadnu prevádzku. Obr. 27 Phone DoS/DDoS Stealth DoS/DDoS Typ DoS útoku, ktorý je smerovaný priamo na jedného koncového uţívateľa, kde sa zdroj volania mení. V tomto prípade sa priraďujú jednotlivým časovým oknám rôzne prahové hodnoty. Tieto časové okná sú rozdelené na ráno, popoludnie, večer a noc. Pravidlo sa vzťahuje len na INVITE správy v telefónnych hovoroch. Pouţité akcie sú: Alert Only informuje o prekročenej prahovej hranice, Block zablokuje prevádzku, SIP Challenge zaháji autentizáciu. Obr. 28 Stealth DoS/DDoS Call Walking Typ DoS útoku, kde útočník z jedného zdroja sekvenčne útočí na niekoľko koncových bodov. Pravidlo sa vzťahuje na všetky SIP správy, kde sa dajú osobitne nastaviť prahové hodnoty pre INVITE a REGISTER. Pouţité akcie sú opäť: Alert Only informuje o prekročenej prahovej hranice, Block zablokuje prevádzku, SIP Challenge zaháji autentizáciu. Obr. 29 Call Walking Domain DoS Ďalšie DoS nastavenia sú v: SBC Global Profiles Server Configuration DoS Protection. Toto nastavenie od základu nie je aktivované preto sa aktivuje: Advanced Edit Enable DoS Protection Finish tu ponúka Avaya SBC jednoduchú konfiguráciu DoS pravidiel pri zahltení DoS útokom. Jediný rozdiel oproti predchádzajúcim DoS nastaveniam je, ţe v tomto prípade sú pravidlá vzťahujúce sa ku 60

62 konkrétnemu serveru, ku ktorému sú smerované a aţ po aplikovaní smerovania. Pretoţe cieľový SIP server je identifikovaný aţ potom čo ho SBC nájde vo svojej smerovacej tabuľke. Toto DoS nastavenie je automaticky prepočítané podľa zadaného maximálneho počtu aktívnych relácií. Základné nastavenie sa vzťahuje k maximálnym súbeţným reláciám (Obr. 30), ktoré v prípade potreby mení. Pri tomto prepočítaní je moţné zvoliť typ prevádzky: Trunk Traffic, Remote Users, Tunk Traffic and Remote Users. Obr. 30 Domain DoS Nastavený Domain DoS sa priradí k SBC Domain Policies Security Rules Domain DoS. Toto bezpečnostné pravidlo (Security Rules) sa potom priradí k SBC Domain Policies End Point Policy Groups. End Point Policy Groups nakoniec k SBC Device Specific Dettings End Point Flows Server Flow Topology hiding Topology hiding je funkcia poskytovaná serverom Avaya SBCE a umoţňuje zmeniť kľúčové SIP správy, obsahujúce určité parametre akými sú IP adresa alebo názov lokálnej domény. Ich zmena potom následne zabráni alebo zamaskuje útočníkovi z verejnej siete jej topológiu. V SBC je vhodné prepísať tieto SIP hlavičky, ktorými sú: from, Request-Line ato Obr. 31. Nastavenie funkcie Topology hiding je moţné previesť v SBC Global Profiles Topology Hiding. Toto nastavenie je moţné ľubovoľne modifikovať a v prípade potreby prepísať aj hlavičky Record-Route, SDP, Via, Reffered-By a Refer- To. Obr. 31 Topology hiding 61

63 4.2.8 Ďalšie zabezpečenie Avaya SBCE ponuka taktieţ aj funkcie Scrubber a Fingerprint, ktoré skúmajú pakety do hĺbky a v prípade nejakej anomálie škodlivé pakety zahodia alebo informujú administrátora alarmom. Obe funkcie bohuţiaľ nie je moţné ľubovoľne modifikovať. Avaya ich modifikáciu nepovoľuje. Dajú sa len povoliť alebo zakázať. Avaya však odporúča ich pouţívanie [28]. Ich povolenie alebo zakázanie funkcie Scrubber je v SBC Global Parameters Scrubber. Povolenie alebo zakázanie funkcie Fingerprint je v SBC Global Profiles Fingerprint. 62

64 5 Záver V diplomovej práci som sa sústredili hlavne na konkrétne moţnosti zabezpečenia Avaya Aura architektúry, tak zvnútra ako aj zvonku siete. Popísal som jednotlivé časti Avaya Aura architektúry, jej komponenty i prvky, ktoré celý systém zabezpečujú. Venoval som sa tieţ dostupným bezpečnostným prvkom poskytovaných firmou Avaya. Práca bola rozdelená na teoretickú a praktickú časť. V prvej, teoretickej, časti práce som sa zaoberal aktuálnym stavom a spôsobmi zabezpečenia PBX systémov zaloţených na protokole SIP, a to nasadením SBC ako hraničného ochranného prvku NGN siete. Snaţil som sa zhodnotiť moţné hrozby i zabezpečenia proti ním a bezpečnostné trendy pre NGN siete s nasadeným SBC, a to na úrovniach NNI a UNI. Úroveň NNI znamenala z pohľadu Avaya SBCE pripojenie k VoIP operátorovi SIP trunkom. V rámci UNI išlo o pripojenie, ktoré má názov Remote Workers. Popísal som výhody SBC potreby, dôvody jeho pouţitia, správny výber a spôsoby jeho zapojenia v NGN sieti, ktoré mali vplyv na jej celkovú bezpečnosť. V praktickej časti diplomovej práce som sa zaoberal uţ konkrétnou implementáciou a konfiguráciou testovacej Avaya Aura architektúry. Zároveň som sa venoval implementácii a konfigurácii Avaya SBCE pre ochranu trunku, remote workers, ústredne a BYOD zariadení. Všetky servery boli poskytnuté firmou Algotech. Praktickú časť som mal rozdelenú spolu s diplomovou prácou môjho kolegu Ondru Kováře. Išlo o koncept, kde sa Ondra Kovář snaţil útočiť a ja som sa bránil. Kvôli tomu sme vytvorili testovacie prostredie pre rôzne DoS útoky a vďaka nemu sme namerali údaje a následne ich, ako grafy spracovali do tejto diplomovej práce. Pomocou nich sme overili bezpečnostné moţnosti SM aj SBC. Pri testovaní jednotlivých metód zabezpečenia sme videli správanie ústredne počas útoku. Na základe toho som navrhol patričné opatrenia a zhodnotil jej ochranu. Tieto opatrenia pozostávali z bezpečnostných moţností ponúkaných firmou Avaya. Týkalo sa to návrhu bezpečnej architektúry, kontroly prístupu, šifrovania (signalizácie a médií) a nakoniec aj návrhu nastavenia SIP firewallu. Návrh SIP firewallu bol rôzny pre SM a SBC. Pri SBC sa ešte delil na mód, v ktorom bolo SBC nakonfigurované či uţ SIP trunk alebo Remote Workers. Cieľom tejto práce bolo vytvoriť referenčné nastavenie proti širokej škále SIP útokov. Pri implementácii všetkých bezpečnostných moţností, ktoré Avaya ponúka, a ktorých nastavenie som popísali v tejto práci. Je preto moţné povedať, ţe sieť bude na základe tejto diplomovej práce zabezpečená proti všetkým útokom typu: neautorizovaný prístup, odpočúvanie, DoS/DDoS, Toll Fraud alebo záškodnícka modifikácia správ. Táto práca môţe slúţiť aj ako návod alebo aspoň vodítko pri zavádzaní bezpečnostných opatrení do Avaya Aura architektúry. Čím by sa preto dalo v tejto práci pokračovať? Zaoberal som sa len malými VoIP sieťami, resp. bezpečnostnými princípmi fungujúcimi hlavne v malých sieťach a firmách. Relatívne veľká firma alebo call centru si však nemôţe dovoliť pouţiť len jeden SM alebo len jedno SBC. Pretoţe sa môţe stať, ţe rôzne časti firmy pouţívajú rôzne bezpečnostné opatrenia. Keďţe Avaya podporuje aj dodatočné rozširovanie celej NGN siete, tak pri väčších firmách by v nich bolo potrebné zváţiť pouţitie viacerých SBC a SM. Pri oboch serveroch je potom potrebné dôsledne zváţiť a odôvodniť ich nový počet a taktieţ bezpečnostnú konfiguráciu, ktorá by bola šitá na mieru pre rôzne logické časti veľkej SIP siete. Napríklad rôzne SBC pre DMZ, SBC pre SM a SBC pre Remote Workers. 63

65 Zoznam použitej literatúry [1] DWIVEDI, Himanshu: Hacking VoIP: protocols, attacks, and countermeasures. 2006, No Starch Press, San Francisco. ISBN-10: , ISBN-13: [2] JOHNSTON, Alan; PISCITELLO, David: Understanding Voice over IP Security Artech House, INC. ISBN [3] RANSOME, James; RITTINGHOUSE, John: Voice over Internet Protocol (VoIP) Security Elsevier Inc. ISBN [4] DORGHAM, Sisalem; FLOROIU, John; KUTHAN, Jiri: SIP Security. Great Britain 2009, John Wiley & Sons Ltd. ISBN (H/B) [5] Communications Fraud Control Association (CFCA), Announces results of worldwide telecom fraud survey. 4. Októbra 2011, Roseland, NJ. Dostupné na internete: < [6] AHSON, Syed; ILYAS, Mohammad: SIP Handbook, Services Technologies and Security of SIP Tayor & Francis Group, LLC. ISBN [7] PROKOP, Andrew: Building a secure SIP network [online]. Aktualizované 13. Februára [cit ]. Dostupné na internete: < [8] RUSSEL, Travis: Session Initiation Protocol (SIP): Controlling Convergent Networks. Jún 2008 McGraw-Hill. ISBN-10: ISBN-13: [9] ROSENBERG, J.; SCHULZRINNE, H.; CAMARILLO, G: SIP: Session Initiation Protocol. IETF RFC Jún Dostupné na internete: < [10] Baugher, M; McGrew, D; Naslund, M: The Secure Real-time Transport Protocol (SRTP). IETF RFC Marec Dostupné na internete: < [11] THERMOS, Peter; TAKANEN Ari: Securing VoIP networks. Threats, Vulnerabilities and Countermeasures Boston MA, Pearson Education, Inc. ISBN-13: ISBN-10: [12] NIELSEN, Lisa: 7 Myths About BYOD Debunked [online]. Aktualizované 9.Novembra 2009 [cit ] Dostupné na internete: < [13] HAUTAKORPI, J.; CAMARILLO, G.; PENFIELD, R.; HAWRYLYSHEN, A.; BHATIA, M. (April 2010). Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments. IETF RFC Dostupné na internete: < [14] PROKOP, Andrew: Why a Sessio Border Controller (SBC). [online]. Aktualizované 2.Februára [cit ]. Dostupné na internete: 64

66 < [15] Dokumentácia: Avaya Session Border Controller for Enterprise Overview and Specification. Release 6.2, Issue 2. December 2013 Avaya Inc. [16] SHINDER, Deb: SolutionBase: Strengthen network defenses by using a DMZ [online]. Aktualizované 29. Júna [cit ]. Dostupné na internete: < [17] VoIP News: 10 Questions to Ask Your SBC [online]. Aktualizované 23. Júla [cit ]. Dostupné na internete: < [18] PLEASANT, Blair: What UC is and what it isn t [online]. Aktulaizované Júl [cit ]. Dostupné na internete: < [19] Dokumentácia: Security Design in Avaya Aura Session Manager. Release 6.3, Október 2013 Avaya Inc. [20] Dokumentácia: Avaya Aura Session Manager. Release 6.3, Issue 5, August 2014 Avaya Inc. [21] Dokumentácia: Avaya Session Border Controller for Enterprise Overview and Specification. Release 6.3, Issue 3, Október 2014 Avaya Inc. [22] Dokumentácia: Avaya SBCE 6.3 Security Configuration and Best Practices Guide. Release 6.3, Issue 1.0, Október 2014 Avaya Inc. [23] Dokumentácia: Avaya Aura Session Manager Overview and Specification. Release 6.3, Issue 5, August 2014 Avaya Inc. [24] Dokumentácia: Administering Avaya Aura Session Manager, Release 6.3, Issue 7, September 2014 Avaya Inc. [25] Dokumentácia: Avaya Aura System Manager Security Design, Release 6.1, Január 2011 Avaya Inc. [26] Dokumentácia: Configuring the Avaya Session Border Controller for IP Office Remote Workers, September 2013 Avaya Inc. [27] Dokumentácia: SIP Vicious. Dostupné online: < [28] Dokumentácia: Administering Avaya Session Border Controller for Enterprise. Release 6.2, Issue 2, Január 2013 Avaya Inc. [29] Kuhn, Richard; Walsh, Thomas; Fries, Steffen (January 2005) Security Considerations for Voice Over IP Systems. Gaithersburg, Computer Security Division, Information Technology Laboratory, Naitonal Institute of Standards and Technology, Special publication , MD

67 Príloha A Ukážky z útokov 66

68 67