VŠB Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Katedra telekomunikační techniky Detekce bezpečnostních hrozeb a jejich eliminace v IP telefonii Detection of security threats and their elimination in the IP telephony 2016 Ondřej Pinda
Poděkování Rád bych poděkoval doc. Ing. Miroslavu Vozňákovi, Ph.D. za odbornou pomoc a konzultaci při vytváření této diplomové práce.
Abstrakt Tato diplomová práce prezentuje dostupné možnosti v oblasti zabezpečení počítačových sítí. Nabízí pohled na jednotlivé pilíře bezpečnosti, na kterých lze stavět a pokusit snížit rizika a hrozby na minimum. Pro dlouhodobě používané standartní bezpečnostní prvky jako jsou firewally, šifrovací algoritmy a IDS systémy jsou v dnešní době k dispozici nástroje v podobě ještě ne příliš využívaných systémů pro detekci anomálií v reálném čase. Vedle několika komerčních projektů je volně dostupným systémem pro detekci anomálií také Snort. Tento IDS umožňuje analyzovat provoz v počítačových sítích a díky několika přídavným modulům je schopen detekovat anomálie a tím působit jako další faktor navyšující bezpečnost. Cílem této práce je otestovat systém Snort v režimu pro detekci anomálií a pokusit se odhalit několik útoků používaných ve VoIP telefonii. Klíčová slova Bezpečnost sítí, Rizika v IP telefonii, útoky, SNORT, SURICATA, detekce anomálií a minimalizace rizik ve VoIP, detekce průniku
Abstract This thesis presents the options available in the network security field. It provides a view to single security pillars. These are able to build up security and try to reduce the risks and threats to minimum. For long-term used standard security features such as firewalls, encryption algorithms and IDS systems are now available the tools in not yet frequently used system shape to detect anomalies in real time. Besides several commercial projects is as well free available Snort for anomaly detection system. This IDS allows to analyze the operations on computer networks and with additional modules can detect anomalies, and impacts as an additional factor for increasing security. This work taget is to test the system Snort in a mode for detecting anomalies and attempt to detect several attacks used in VoIP telephony. Key words Network Security, threats in IP telephony, attacks, SNORT, SURICATA, anomaly detection and minimization of risks in VoIP, intrusion detection
Obsah Úvod...- 14-1 Bezpečnost sítí...- 15-1.1 PKI...- 15-1.1.1 PKI infrastruktura...- 15-1.1.2 Služby poskytující PKI...- 16-1.1.3 Architektura modelu PKI...- 16-1.2 Šifrování...- 17-1.2.1 Symetrické šifrování...- 17-1.2.2 Asymetrické šifrování...- 18-1.3 VLAN...- 18-1.3.1 Výhody VLAN...- 18-1.4 VPN...- 19-1.4.1 Spojení typu bod - bod...- 19-1.4.2 Spojení typu bod - síť...- 19-1.4.3 Spojení typu síť - síť...- 19-1.5 Firewally a IDS systémy...- 19-1.5.1 Firewall...- 19-1.5.2 Kategorie firewallu...- 20-1.5.3 Netfilter...- 20-1.5.4 IDS systémy...- 21-2 Rizika IP telefonie a přehled útoků...- 24-2.1 Skenování sítě...- 24-2.1.1 NMAP...- 24-2.1.2 INVITE sken útok...- 24-2.1.3 OPTIONS sken útok...- 24-2.1.4 REGISTER sken útok...- 25-2.2 Odposlech...- 25-2.3 Nevyžádaný kontakt...- 25-2.3.1 Spam over IP Telephony (SPIT)...- 25-2.3.2 Voice phishing...- 26-2.4 Odepření služeb (DoS)...- 26 -
2.4.1 Single packet útoky...- 26-2.4.2 DoS pomocí záplavy paketů...- 27-2.4.3 Zesílení DoS útoku...- 28-2.4.4 Metody detekce...- 28-2.5 Odcizení služeb a útoky na účtovací systémy...- 28-2.5.1 InviteReplay útok...- 28-2.5.2 FakeBusy útok...- 29-2.5.3 ByeDelay útok...- 30-2.5.4 ByeDrop útok...- 31-2.5.5 Metody detekce...- 32-2.6 Modifikace a aktivní útoky na spojení...- 32-2.6.1 Útoky na registraci...- 32-2.6.2 Přesměrování hovorů...- 33-2.6.3 Násilné ukončení spojení...- 33-2.6.4 Metody detekce...- 33-2.6.5 Modifikace obsahu hovoru...- 34-2.6.6 Metody detekce...- 34-2.7 Další bezpečnostní hrozby... - 34-3 SNORT, SURICATA a další nástroje....- 36-3.1 SNORT...- 36-3.1.1 Režimy Snortu...- 36-3.1.2 Achitektura a moduly Snortu... - 36-3.2 SURICATA...- 39-3.2.1 Podpora multi-threadingu...- 39-3.2.2 HTP knihovna...- 40-3.2.3 Architektura Suricaty...- 40-3.3 CAMNEP...- 40-3.3.1 Architektura systému...- 40-3.3.2 Sběr dat ve vysokorychlostních sítích...- 41-3.3.3 Detekce škodlivého síťového provozu...- 42-3.3.4 Vizualizace síťového provozu...- 42-3.4 Caligare Flow Inspector...- 42-3.5 FlowMon ADS...- 42 -
4 Praktická realizace detekce anomálií a minimalizace rizik ve VoIP...- 43-4.1 Praktická realizace detekce anomálií...- 43-4.1.1 Implementace Snortu...- 43-4.1.2 Generování profilu sítě...- 44-4.1.3 Výstup logovacího souboru...- 45-4.1.4 Anomaly Detection Struktura...- 50-4.1.5 Generování predikovaného modelu...- 51-4.1.6 Konfigurace Snortu...- 53-4.1.7 Úprava pravidel pro AD preprocesor...- 53-4.1.8 SIPp...- 54-4.1.9 Generovaní útoků...- 54-4.1.10 Detekování anomálií...- 56-4.2 Zabezpečení VoIP sítě...- 58-4.2.1 Řízení přístupu k síťovému médiu na úrovni portů...- 60-4.2.2 Oddělení hlasových a nehlasových služeb...- 61-4.2.3 Zabezpečení signalizačních spojení...- 62-4.2.4 Zabezpečení datového spojení...- 64-5 Zhodnocení dosažených výsledků...- 65-5.1 Nastavení a optimalizace Snortu...- 65-5.2 Výběr a Nastavení AD algoritmu...- 65-5.3 Provedení DoS útoků...- 65-5.4 Odhalení útoků...- 65-5.5 Klasifikace útoků...- 66 - Závěr...- 67 - Použitá literatura...- 68 - Seznam příloh...- 71 -
Seznam použitých zkratek Zkratka Význam AD ARP ASK CA DDoS DHCP DNS DoS DTLS EDI FTP GUI HIDS HTTP ICMP IDS IP MAC MIB MITM NAT NIDS NIPS NMAP NRPE OID OISF OSI Anomally Detection Address Resolution Protocol Asymmetric cryptography Certificate authority Distributed Denial of Service Dynamic Host Configuration Protocol Domain Name System Denial of Service Datagram Transport Layer Security Electronic Data Interchange File Transfer Protocol Graphical User Interface Host-based intrusion detection system Hypertext Transfer Protocol Internet Control Message Protocol Intrusion detection system Internet Protocol Media Access Control Management information base Man in the middle Network Address Translation Network intrusion detection system Network Intrusion prevention system Network MAPer Nagios Remote Plugin Executor Object identifier Open Information Security Foundation The Open Systems Interconnection
PEM PGP PHP PKI RFC S/MIME SIP SMTP SNMP SPIT SRTP SSH SSL TCP TFTP TLS TTL UDP UNIX URI VAM VLAN VoIP VVLAN WAP ZRTP Privacy Enhanced Mail Pretty Good Privacy Hypertext Preprocessor Public Key infrastructure Request for Comments Secure/Multipurpose Internet Mail Extensions Session Initiation Protocol Simple Mail Transfer Protocol Simple Network Management Protocol Spam over Internet telephony The Secure Real-time Transport Protocol Secure Shell Secure Sockets Layer Transmission Control Protocol Trivial File Transfer Protocol Transport Layer Security Time to live User Datagram Protocol Ochranná známka operačního systému Uniform Resource Identifier VoIP Spam Virtual Local Area Netwotk Voice over Internet Protocol Voice Virtual Local Area Network Wireless Application Protocol Zimmermann RTP
Seznam ilustrací a seznam tabulek Číslo ilustrace Název ilustrace Číslo stránky 1.1 Architektura PKI 17 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19 1.20 1.21 1.22 1.23 1.24 1.25 1.26 1.27 1.28 1.29 Schéma IDS InviteReplay útok FakeBusy útok ByeDelay útok ByeDrop útok Hrozby VoIP Architektura Snortu Princip jednotky paketového záchytu Preprocesor Snortu Detekční jednotka Jednotka logování Schéma Suricaty Architektura systému CAMNEP Zápis do log souboru Ukázka logovacího souboru Struktura AD systému Struktura predikovaného modelu Vygenerování OPTIONS útoku Vygenerování REGISTER flood útoku Vygenerování ICMP flood útoku Printscreen detekce OPTIONS floodu Printscreen detekce REGISTER floodu Printscreen detekce INVITE floodu Printscreen detekce ICMP floodu Vrstvy VoIP systému Bezpečnostní rizika jednotlivých vrstev Autentizace přes 802.1X Oddělení hlasového provozu 22 29 30 31 32 35 36 37 37 38 39 40 41 45 45 50 53 54 55 56 56 57 57 58 59 60 61 62
1.30 1.31 Zabezpečení signalizace pomocí SIPS Zabezpečení signalizace pomocí SIPS+S/MIME 63 63 Číslo tabulky Název tabulky Číslo stránky 1.1 Rychlost downloadu UDP paketů 47 1.2 1.3 1.4 1.5 1.6 1.7 1.8 Rychlost uploadu UDP paketů Počet příchozích paketů Počet odchozích paketů Počet přenesených UDP paketů Odchozí ICMP pakety Příchozí ICMP pakety Porovnání jednotlivých útoků 47 48 48 49 49 50 66
Úvod Úvod Tato diplomová práce se snaží přiblížit otázku bezpečnosti počítačových sítí a bezpečnosti ve VoIP. Cílem této práce je otestování systému Snort v režimu pro detekci anomálií a pokus o odhalení několika útoků používaných ve VoIP telefonii. První kapitola je úvodem do teorie počítačových sítí s úmyslem objasnit a popsat jednotlivé prvky a principy z oblasti počítačové bezpečnosti. Celá tato kapitola je rozdělena do pěti obsáhlejších podkapitol věnujících se PKI, šifrování, VLAN, firewallům a IDS systémům. Druhá kapitola je rozborem širokého spektra bezpečnostních útoků a hrozeb ve VoIP telefonii. Na konci podkapitol jsou popsány metody detekce spolu s doporučením jak dosáhnout minimalizace rizika úspěšnosti daného druhu útoků. Třetí kapitola je úvodem do praktické části. Zaměřuje se na detailní popis IDS systémů a systémů schopných detekovat anomálie v počítačových sítích. Vybráni jsou zástupci AD systémů z řad volně dostupných tak i z komerční sféry. Jmenovitě se jedná o Snort, který bude otestován v praktické části této práce, dále jeho velký konkurent na poli IDS systémů Suricata a Projekt CAMNEP spolu s Caligare Flow Inspector a Flowmon ADS. Čtvrtá kapitola je dokumentací praktické části popisující implementaci Snortu AD s moduly nutnými pro jeho chod, generování síťového profilu a vytváření predikovaného modelu. Následuje konfigurace Snortu a ukázka úpravy pravidel pro preprocesor. Závěrečnou částí pak je již generování útoků za použití nástroje SIPp, jejich detekování a popis možností pro zvýšení bezpečnosti v prostředí VoIP. - 14 -
Bezpečnost sítí 1 Bezpečnost sítí 1.1 PKI Public Key Infrastructure je soustavou technických a především organizačních opatření spojených s vydáváním, správou, používáním a odvoláváním platností kryptografických klíčů a certifikátů. 1.1.1 PKI infrastruktura Pojmem PKI je označována infrastruktura, která se zabývá zabezpečením pomocí šifrování. Základními prvky jsou certifikační autorita, registrační autorita, seznam zneplatněných certifikátů, OCSP, digitální certifikát a podpis. 1.1.1.1 Certifikační autorita O důvěryhodnost vztahu mezi jedincem a jeho klíčem se stará třetí strana takzvaná certifikační autorita (dále jen CA), která řídí správu kryptografických klíčů a certifikátů. Jejím hlavním úkolem je jejich vydávání, používání a odvolávání. Pokud je tedy námi použitá CA důvěryhodná, můžeme tedy důvěřovat i údajům uvedeným v certifikátu nebo vztahu mezi dvěma klíči. 1.1.1.2 Registrační autorita Registrační autorita zastupuje autoritu certifikační a ověřuje totožnost žadatele. Přijímá žádosti o nové certifikáty a následně vyřízené certifikáty předává koncovému uživateli. Také se stará o zneplatnění certifikátů. 1.1.1.3 Seznam zneplatněných certifikátů Seznam zneplatněných certifikátů (CRL) je databáze, do které zveřejňuje CA odvolané certifikáty. K odvolání certifikátu v době jeho platnosti může dojít při ztrátě nebo zcizení párového klíče, popřípadě při porušení podmínek CA a na žádost uživatele nebo jiné autority. V záznamu je uvedeno číslo certifikátu, datum zneplatnění a důvod. Seznam by měl být veřejně dostupný na Internetu nebo přes protokol LDAP. 1.1.1.4 OSCP Význam zkratky OCSP se dá vyložit jako online služba pro zjištění aktuálního stavu certifikátu. Přes protokol HTTP můžeme zkontrolovat platnost konkrétního certifikátu i bez nutnosti stahovat celého CRL. 1.1.1.5 Digitální certifikát Jako digitální certifikát v ASK slouží veřejný šifrovací klíč vydaný certifikační autoritou. Lze říct, že se jedná o obdobu občanského průkazu, ve kterém jsou obsaženy údaje o jeho majiteli. Nejčastěji jsou používány pro identifikaci uživatele přistupujícího na HTTPS nebo do VPN. 1.1.1.6 Digitální podpis Digitální podpis je mechanismus sloužící k potvrzení pravosti dat. Pomocí hashovacího algoritmu se vytvoří otisk dat a ten je poté zašifrován soukromým klíčem uživatele. Zašifrovaný podpis je pak přiložen ke zprávě. Příjemce stejným hashovacím algoritmem vypočte otisk příchozích - 15 -
Bezpečnost sítí dat. Veřejným klíčem odesílatele dešifruje jeho digitální podpis a porovná hash vypočtený ze zprávy a hash získaný z podpisu. Pokud je shodný, má příjemce jistotu, že identita odesílatele je pravá. 1.1.2 Služby poskytující PKI Autentizací rozumíme proces, při němž ověřujeme identitu. V praxi je to např. kontrola totožnosti uživatele přistupujícího přes portál do systému. Což je spojeno s autorizací, skrze kterou jsou přirazena práva přistupující osobě, jenž má následně přístup pouze do určitých složek a omezenou práci se soubory. Tato služba je zajištěna digitálním certifikátem. Druhou vlastností PKI je nepopíratelnost. Všichni uživatelé nesou odpovědnost za své činy na portálu. Není možné popřít odeslaná data a provedené úkony, ke kterým se vztahuje identita konkrétního uživatele. Zajištěna je pomocí digitálního podpisu. Další nedílnou součástí je důvěrnost, která ručí za bezpečný přenos dat přes veřejnou nezabezpečenou síť. Tím nám dává jistotu, že při přenosu se nedostane k datům neautorizovaná osoba. Pro zvýšení bezpečnosti je použito šifrovacích algoritmů. Integrita zajišťuje, že data průchodem veřejnou sítí nebyla změněna ani jinak modifikována. K tomu v PKI slouží hashovaní zpráv. [1] 1.1.3 Architektura modelu PKI Uživatel: CA: RA: CRL: Repository: koncový uživatel, kterému byl vydán certifikát. certifikační autorita vydává certifikáty. registrační autorita kontroluje elektronickou žádost a totožnost žadatele. systém pro správu odvolaných certifikátů. úložný systém shromažďující certifikáty. - 16 -
Bezpečnost sítí Obrázek 1.1: Architektura PKI 1.2 Šifrování Šifrování má za úkol bezpečný přenos informace mezi dvěma stranami. Bezpečnostní algoritmy zabezpečují komunikaci, která by jinak byla velmi náchylná k odposlechu či modifikaci. Šifrování lze dále rozdělit na symetrické a asymetrické podle způsobu použití klíče. 1.2.1 Symetrické šifrování Symetrické šifrování je metoda, kterou jsou data šifrována podle klíče. Přednostní symetrické šifry je rychlost algoritmu. K dešifrování je třeba použít stejný klíč, což je jeho slabinou. Musí však dojít k bezpečné výměně klíče mezi odesílatelem a příjemcem. Problémem je tedy zabezpečení distribuce, aby se nedostal do nepovolaných rukou. Další nevýhodou je případ, kdy se komunikace účastní více subjektů. Pokud chceme pro každou dvojici vlastní klíč, potřebujeme pro n subjektů n (n- 1)/2 klíčů. Mezi jeho výhody patří jednoduchost, rychlost a nenáročnost na výpočetní výkon. Nejznámějšími zástupci jsou Data encryption Standard, Advanced Encryption Standard, Blowfish, Twofish a RC4. [2, 3] - 17 -
Bezpečnost sítí 1.2.2 Asymetrické šifrování Základním kamenem pro asymetrické šifrování je matematická vazba mezi klíči. Každá z komunikujících stran vygeneruje pár klíčů - privátní a veřejný. Privátní klíč je uchován v tajnosti a je využíván pouze jeho vlastníkem. Kdežto klíč veřejný je volně distribuován příjemcům zpráv. Princip tohoto šifrování je následující: Chce-li Alice zaslat zprávu Bobovi, zašifruje zprávu veřejným klíčem od Boba, poté je zpráva odeslána a po doručení je možné ji dešifrovat pouze Bobovým privátním klíčem. Výhodou tohoto šifrovacího algoritmu je vysoká míra důvěryhodnosti. Nevýhodou je vyšší náročnost na výpočetní výkon. Jeho nejznámějšími zástupci jsou Rivest, Shamir, Adelman (RSA), Pretty Good Privacy (PGP), Elliptic curve cryptography (ECC). [2, 3] 1.3 VLAN VLAN nabízí logické členění sítě bez ohledu na její fyzickou infrastrukturu. Lze tedy existující fyzickou síť rozdělit do více logických částí. Příkladem tak může být skupina počítačů, kdy je jedna část připojena do switche a část do switche druhého pro oddělení provozu fyzickou cestou. Nebo lze využít VLAN a realizovat rozdělení logické pomocí jednoho switche.[4] 1.3.1 Výhody VLAN 1) Snížení broadcastů Velkou výhodou VLAN je vytvoření více, ale menších broadcastových domén. Dochází tedy ke zvýšení výkonnosti sítě snížením provozu. 2) Zjednodušená správa Přesun zařízení do jiné sítě je možný jeho přeřazením do jiné VLANy. Úkolem správce je konfigurace pouze po softwarové stránce a není nutné fyzického přepojení. 3) Zvýšení zabezpečení Dosáhneme jej oddělením komunikace do speciální VLANy, kde má přístup pouze autorizovaná osoba. Lze docílit i použitím switchů, avšak práce s VLAN je mnohem jednodušší. 4) Oddělení provozu Dnes se využívá celá řada služeb, které není nutné distribuovat do celé sítě, ale přesto je potřebná jejich dostupnost na různých místech. Navíc je nežádoucí, aby ovlivňovaly běžný provoz (například VoIP, management, komunikace mezi AP v centrálně řízeném prostředí, apod.). 5) HW náročnost Nesnižuje se potřebný počet portů (výjimkou jsou speciální případy jako je VoIP), ale možností mít různé podsítě na stejném switchi, jej lze lépe využít (např. k pro propojení čtyř zařízení není potřeba speciálního switche, který má minimálně 8 portů). Například pro VoIP, kde je použití VLAN naprosto běžné a často i nutné, nám stačí jediná zásuvka, kam přivedeme VLAN pro telefonii i VLAN s přístupem do sítě a v telefonu se komunikace - 18 -
Bezpečnost sítí rozdělí. Navíc VLAN můžeme vázat s QoS pro zaručení kvality komunikace. Tématu VVLAN (Voice VLAN) se věnuji více v kapitole 4. [4] 1.4 VPN Virtuální privátní síť je mechanismus, umožňující organizaci vybudovat privátní síť v prostředí veřejné sítě jako je např. internet. VPN pracuje na principu tunelování šifrovaných dat skrz sdílenou infrastrukturu s autentizací na jednotlivých koncích tunelů. Pod termínem tunel si představíme virtuálně vytvořené dvoubodové spojení skrze již zmíněnou veřejnou infrastrukturu, ve kterém jsou přenášeny pakety. Využití VPN oproti realizaci vlastní privátní sítě je nízká cena a flexibilita topologie VPN, která se odvíjí jen od konfigurace routerů a firewallů u konce VPN tunelu. O používání VPN ve sdílené infrastruktuře nemusí její poskytovatel vůbec vědět. [5] síť. VPN lze rozdělit tři základní typy podle spojení a to na spojení typu bod - bod, bod - síť a síť - 1.4.1 Spojení typu bod - bod Jedná se o nejpoužívanější VPN, jde o dvoubodové propojení uživatele se zabezpečenou aplikací. Pod termínem aplikace si můžeme představit spojení s bankovní službou nebo zabezpečené spojení mezi serverem a uživatelem. [5] 1.4.2 Spojení typu bod - síť Tento druh spojení může být využit při vzdáleném připojování zaměstnanců do firemní sítě, např. při práci z domova nebo ke vzdálené správě. Skrze VPN tak mají přístup ke všem firemním dokumentům a aplikacím, aniž by museli sedět u počítače v kanceláři. Připojení je často nazýváno jako Road Warrior, neboli cestující válečník. Kdy v roli klienta je zaměstnanec, který je nucen přistupovat z cizího tj. válečného prostředí do vzdálené firemní sítě. [5] 1.4.3 Spojení typu síť - síť Jako nejjednodušší příklad lze uvést situaci, kdy potřebujeme propojit dvě privátní sítě dvou poboček stejné společnosti přes internet. Počítače obou poboček se tak tváří, jako by byly zapojeny v jedné lokální síti. [5] 1.5 Firewally a IDS systémy 1.5.1 Firewall Jde o bezpečnostní systém oddělující jednu síť od druhé. Z pravidla je umístěný mezi privátní a veřejnou sítí, obsahující pravidla, podle kterých je rozhodováno, který síťový tok bude propuštěn, odmítnut nebo blokován. Tuto funkci nejčastěji vykonává router, počítač se speciálním systémem nebo jiné síťové zařízení schopné filtrace paketů. [6] - 19 -
Bezpečnost sítí 1.5.2 Kategorie firewallu 1.5.2.1 Paketové filtry Nejstarší a nejjednodušší variantou firewallu je paketový filtr. Uvádí z jaké adresy a portu na jakou adresu a port může být paket doručen. Paket je kontrolován na třetí a čtvrté vrstvě OSI. Vyznačují se vysokou rychlostí zpracování, nevýhodou však je nízká úroveň kontroly. 1.5.2.2 Aplikační brány Aplikační brány nebo také proxy firewally zcela oddělují jednotlivé sítě. Komunikace probíhá spojením dvou bodů přes aplikační bránu. Klient inicializující komunikaci se připojí na proxy bránu, která spojení zpracuje a otevře nové připojení k požadovanému serveru. Odpověď putuje zpět stejnou cestou pomocí původního spojení. Server tak nevidí zdrojovou adresu klienta a jako zdroj figuruje adresa aplikační brány. Proxy firewall automaticky plní funkci překladače adres. Výhodou je vysoká úroveň zabezpečení, avšak nevýhodou je vysoká hardwarová náročnost. Používají se tam, kde nestačí jen pouhé filtrování paketů, ale je potřeba i hloubkového dohledu nad přenášenými daty. Kontrola se tak provádí na aplikační vrstvě modelu OSI. 1.5.2.3 Stavové paketové filtry Jedná se o rozšíření standardních paketových filtrů, o možnost rozlišení již používaného spojení od nově příchozích. Porovnává tak tabulkové definice, ale udržuje i přehled již probíhající komunikace. Umožňuje tím reagovat na ustanovená spojení a automaticky povoluje odpověď. Nerozhoduje již jen podle zdrojové a cílové adresy, kterou obsahuje paket, ale i na základě parametrů probíhajícího spojení. Používají se čtyři základní stavy a to NEW, ESTABLISHED, RELATED a INVALID. Kde NEW označuje nově začínající komunikaci, ESTABLISHED komunikaci ustanovenou, kde je očekávána odpověď. RELATED pak značí stav spojení, které by mělo zůstat otevřeno z důvodu očekávané odpovědi. Poslední stav INVALID slouží pro paket s neodpovídajícím očekávaným chováním. Taktéž jako paketový filtr pracuje na třetí a čtvrté vrstvě modelu OSI. 1.5.3 Netfilter Jedná se o Linuxový firewall, který je již implementován v jádře. Konfigurace je možná přes program iptables. Pracuje na principu stavového filtru, dokáže tak analyzovat spojení a ne jen samotný paket. Využíván je také protokolem NAT, který taktéž nutně potřebuje vědět o stavu probíhajících spojení. K vysvětlení principu Netfilteru použitého pro zabezpečení VoIP serveru postačí jeho zjednodušené blokové schéma. Netfilter je složený celkově ze čtyř částí a těmi jsou filter, nat, mangle a raw. Ve filteru dochází k samotnému filtrování paketů podle třech pravidel ACCEPT, DROP a REJECT. Každá ze čtyř výše jmenovaných tabulek ještě obsahuje řetězce typu INPUT, OUTPUT, FORWARD, PREROUTING a POSTROUTING, podle kterých je rozhodnuto kam paket bude směrovat. INPUT a OUTPUT značí pakety příchozí a odchozí z lokální stanice. FORWARD pravidlo předává paket mezi jednotlivými síťovými rozhraními. PREROUTING obsahuje sadu pravidel pro změnu cíle, než paket projde firewallem a POSTROUTING naopak pravidla pro změnu zdroje již po průchodu firewallem. Princip Netfilteru je následující. Když na vstup přijde paket, je řetězcem PREROUTING rozhodnuto zda patří místní stanici. Pokud ne je automaticky předán na rozhraní, aby pokračoval - 20 -
Bezpečnost sítí do jiné sítě. Prochází FORWARD řetězcem, kde probíhá filtrování mezi jednotlivými sítěmi. Jestliže paket patří místní stanici, pokračuje k řetězci INPUT. Poté co je zpracována odpověď, je odevzdána řetězci OUTPUT. Po zpracování řetězcem OUTPUT nebo FORWARD je předán paket pro vykonání řetězci POSTROUTING. [6] 1.5.4 IDS systémy IDS je jen jednou z více částí ochranného systému, není tedy samostatným bezpečnostním opatřením. Slouží pouze k detekování a upozornění na podezřelé aktivity v síti, které mohou, ale i nemusí být hrozbou. Tato upozornění jsou uložena do logu nebo jsou přijata dalšími podpůrnými systémy, které již provedou příslušná opatření. Mezi spolupracující systémy patří IPS a firewally, které se těmto útokům již snaží bránit. IDS lze do sítě připojit několika způsoby. Můžeme jej připojit na rozhraní síťového zařízení, jako je router, switch, nebo firewall. Každý paket je pak zkopírován a prověřen. Dále pak pomocí zařízení TAP, které pracuje jako sonda, skrze kterou protéká provoz určený k analýze. Poslední jmenovanou možností je připojení ethernetového hubu, který procházející data zasílá na port, na jehož konci je připojeno IDS. IDS detekují potencionální útok na základě činnosti jednoho ze dvou principů: 1) Porovnáním vzorů Detekce narušení prováděná porovnáváním s pravidly (signaturami) uloženými v databázi, které mají podobu některého známého útoku. Databáze pravidla již obsahuje, ale je možné i dopisovat vlastní vzory. 2) Detekováním statické anomálie Systém analyzuje provoz v síti a pátrá po výjimečném stavu nebo jakékoliv odchylce od normálu. Sledováním sítě po delší časové období se stanoví normální stav. Upozorněno je pak na cokoliv co vykazuje nestandardní chování. Pokud se např. rapidně zvýší počet dotazů na server, je následně událost považována za útok. Výhodou je detekce dosud neznámých útoků. Takový útok je odhalen, pokud v komunikaci dojde k odklonu od určitého standardu. Vytváření modelu normálního chování lze rozdělit na statický a dynamický model. Statický model chování je vytvořen pouze jedenkrát a dále je již neměnný. Toto sestavení je využíváno systémy, které v čase vykazují stejné chování. Do modelu dynamického jsou však průběžně přidávány nové záznamy o chování systému, samotný systém je tak flexibilnější. Nevýhodou obou modelů je v případě, jestliže je systém pod útokem ve fázi vytváření normálního stavu a dojde-li ke stejnému útoku. Server tudíž nebude vykazovat známky neznámého chování a nemusí tak být útok odhalen. Důležitý faktor je čas potřebný k vyhodnocení, zdali se jedná o skutečné napadení. Vyhodnocování v reálném čase dává možnost téměř ihned reagovat na odhalený útok, ale při větším zatížení sítě je nutné počítat s vyššími nároky na výkon stanice. Zatímco u intervalově orientovaného přístupu jsou informace ukládány periodicky a posléze vyhodnocovány. Výhodou jsou nízké nároky na výpočetní výkon. Využíván je pouze v prostředí s nízkým rizikem napadení a nízkými potencionálními ztrátami. Chybí však bezprostřední reakce na útok a nutností je dostatečně velká paměť pro ukládání záznamů. [7] - 21 -
Bezpečnost sítí Obrázek 1.2: Schéma IDS IDS systémy lze rozdělit do tří základních skupin podle jejich umístění v síti: 1) NIDS - Network Based Intrusion Detection Systems Síťové IDS jsou umístěny na strategickém segmentu námi monitorované sítě a kontrolují každý procházející paket. Standardně síťová karta pracuje v nepromiskuitním režimu, ve kterém jsou analyzovány pouze pakety směrované pro MAC (Media Access Control) této karty. Je nutné, aby karta byla nastavena do režimu promiskuitního módu, ve kterém je umožněno zachytávání celého síťového provozu. Při větším vytížení sítě roste objem dat ke zpracování. Kontrolou velkého množství pravidel rostou i hardwarové nároky a může docházet k přetížení. Tím se zvyšuje šance, že útok nebude odhalen. Může také dojít k výskytu falešných útoků, které je poté obtížné rozlišit od reálných hrozeb. Je tedy nutné mít správně nastavený systém a omezit falešné útoky na minimum, jinak může dojít k ignorování alertů a tím rapidně klesá bezpečnost. Mezi nejznámější systémy patří Suricata, Bro a Snort. [8] 2) HIDS - Host Based Intrusion Detection Systems Systém HIDS je zaměřen pouze na bezpečnost hostitelského systému. Je schopný kontrolovat aktivitu uživatelů v síti i probíhající změny v souborovém systému. Vyhodnocuje tyto procesy u hostitele tak, že prochází obsah logů a porovnává, jestli se některý neshoduje s obsahem z databáze signatur útoku. Nutná je instalace na každé zařízení zvlášť. Máme možnost řídit každé zvlášť nebo hromadně přes server. HIDS pracují na aplikační vrstvě modelu OSI, který dokáže na rozdíl od systému NIDS analyzovat šifrovaný přenos dat a detekovat útoky vedené přes šifrovaný kanál. Nevýhodou je možnost vyřazení z provozu pomocí Dos útoků. Použít můžeme např. Tripwire, Snortinline, LIDS. [8] - 22 -
Bezpečnost sítí 3) DIDS - Distributed Intrusion Detection System Systém je kombinací předchozích dvou zmíněných systémů NIDS a HIDS, dosahuje tak nejlepších výsledků díky využití výhod obou a částečné eliminaci jejich nevýhod. Architektura by se dala popsat jako sonda-manažer. Kdy systémové i síťové sondy jsou rozmístěny kdekoliv v síti a jsou monitorovány centrálně. Tím pádem je monitorován provoz sítě a současně i jednotlivé systémy. Není tedy nutné mít všechny sondy jen typu NIDS nebo HIDS. Je tedy možné mít kombinaci obou typů. Teoreticky takto navržený systém by měl zajistit zcela komplexnější detekci útoků. Síťové karty tak mohou pracovat v obou režimech, jak v promiskuitním, tak i nepromiskuitním.[8] - 23 -
Rizika IP telefonie a přehled útoků 2 Rizika IP telefonie a přehled útoků V oblasti VoIP existuje celá řada hrozeb. Cílem útoku jsou servery a jejich operační systémy, síťová zařízení a jejich protokoly a v neposlední řadě telefony a jejich software. Jakékoliv z těchto zařízení může být cílem útoku, který se principiálně neliší od útoku na běžný server, protokol nebo aplikaci. Následující kapitola shrnuje tyto nejzranitelnější místa ve VoIP telefonii. 2.1 Skenování sítě Prozkoumání sítě je primárním krokem každého útočníka. Díky tomuto kroku získá dostatek informací o dané infrastruktuře a může se zaměřit na nejslabší místa, na které bude směřovat útoky. Samotné skenování není nikterak velkou hrozbou. Ale jeho detekcí můžeme odhalit přípravu sofistikovanějšího útoku. Nutností je zabezpečení systému i proti útokům z vnitřní sítě, kdy v pozici útočníka může být oprávněný uživatel. Nejvhodnějším řešení pro průzkum sítě a identifikaci zařízení je nástroj zvaný NMAP. 2.1.1 NMAP NMAP je nástroj pro penetrační testování vyvinutý Gordonem Lyonem. Primárně je využíván pro vyhledávání hostitelských stanic a služeb v síti a následného vytvoření mapy popisující infrastrukturu sítě. Skenování portů probíhá zasíláním upravených paketů. NMAP dokáže nejen zjistit, zda je koncové zařízení online či offline, ale také je schopen odhalit použitý OS, jména a verze služeb naslouchajících na cílovém portu. NMAP disponuje velkým množstvím VoIP fingerprintů, je tedy jednoduché získat informace o jaké druhy VoIP zařízení v síti se jedná. Pak lze využít následujících typů skenování pro útok k získání uživatelského jména (SIP URI). 2.1.2 INVITE sken útok Invite skenování lze velmi lehce odhalit, protože při něm cílový telefon vyzvání. Útok tak nelze skrýt, ale na druhou stranu jej lze použít k obtěžování uživatelů. Samotný útok probíhá tak, že jsou zasílány na SIP Proxy server nebo Register server INVITE zprávy s uživatelskými jmény. Ty jsou z pravidla tvořena ze jmenného slovníku a číselných kombinací. Odpoví-li server zprávou 180 Ringing útočníkovi, podařilo se zjistit platné uživatelské jméno. Pokud však uživatel neexistuje, odpovídá zprávou 404 Not found. V případě, že toto skenování není účinné, server odesílá zprávu 503 Service Unavailable. Pak lze využít dalších dvou druhů skenování nebo zasílat INVITE zprávy přímo na IP adresy uživatelských zařízení. 2.1.3 OPTIONS sken útok Skenování za pomoci OPTIONS zpráv v SIP protokolu slouží k získání informací o dostupných funkcích a službách serveru a koncových zařízení. Oproti INVITE skenování se jedná nenápadnou metodu útoku. Samotné skenování probíhá velmi podobně jako u INVITE skenu. Na cíl útoku je zaslána OPTIONS zpráva se SIP URI, např. OPTIONS sip:505@192.168.178.22. Jedná-li se o existujícího uživatele, je odpovědí zpráva 200 OK a zasílá své parametry. V opačném případě kdy uživatel neexistuje, je zaslána zpráva 404 Not Found. Může však nastat situace, že i toto skenování nemusí být účinné. Jedná se například o situaci kde je využit Asterisk. - 24 -
Rizika IP telefonie a přehled útoků V tomto případě je automaticky zasílána odpověď 200 OK, ať se jedná o uživatele existujícího či neexistujícího. 2.1.4 REGISTER sken útok Při použití REGISTER skenu je zaslán na server požadavek REGISTER s určitým uživatelským jménem. Pokud daný uživatel existuje a není nutná autentizace, server odpoví zprávou 200 OK. Pokud je autentizace vyžadována, zasílá server zprávu 401 Unauthorized popř. 407 Proxy Authentification Required. V situaci, kdy je použit neexistující uživatel může být chování různé. U Asterisku je poslána odpověď 403 Forbidden. 2.2 Odposlech Odposlech můžeme zařadit mezi nejoblíbenější útoky ve VoIP a je velmi úzce spjatý s důvěrností systému. Myšlenka odposlouchávání cizího hovoru vznikla již v dobách PSTN sítí. Odposlech ve VoIP není zúžen pouze na zachycení hlasové konverzace, ale řadíme k němu i informace týkající se signalizačních protokolů. V neposlední řadě nesmí být ani možné odhalit kdo s kým hovořil a jak dlouho hovor trval. Realizace odposlechu probíhá následujícím způsobem. V situaci, kdy má útočník volný přístup k datovému toku a je schopen odchytávat pakety, může některým z celé řady nástrojů provádět jejich analýzu. Tyto programy jsou schopny také přímého převodu RTP streamu do volitelného zvukového formátu. Z nejznámějších nástrojů jmenujme např. Wireshark, který je nástupcem nástroje Ethereal. Wireshark primárně poskytuje analýzu síťového provozu a je schopen detekce velké řady používaných protokolů. V neposlední řadě také umí vytvořit audio stopu z RTP paketů a analyzovat protokoly používané ve VoIP telefonii. Druhým často používaným nástrojem pro realizaci útoků je Cain and Abel, také on zvládá odchytávání VoIP konverzace a mnohé další. Nejlepší obranou proti odposlechu je zabránění útočníkovi v přístupu k síti. Pokud však telefonujeme mimo naši vnitřní síť, je kontrola toku a bezpečnost našich dat nereálná. Zvýšit bezpečnost lze použitím některým ze šifrovacích algoritmů, např. VPN IPsec, který šifruje veškerý datový stream. Druhou variantou zabezpečení je šifrování dat přenášeného protokolu. K přenosu zvukové stopy a obrazu tak lze využít SRTP a ZRTP protokolu. 2.3 Nevyžádaný kontakt Tento druh útoku není nijak velkým rizikem, dochází pouze k obtěžování uživatelů nevyžádaným hovorem. S masivním rozšiřováním VoIP telefonie však lze počítat i s nárůstem této hrozby. Do budoucna ji tak bude nutné věnovat také pozornost. Mezi nejznámější útoky tohoto druhu řadíme Spam over IP Telephony a Voice phisping. 2.3.1 Spam over IP Telephony (SPIT) SPIT je velmi podobný e-mailovému spamu, někdy taky znám zkratkou VAM neboli voice spam nebo VoIP spam. Jde o nevyžádané hromadné zprávy ve VoIP. Přestože obchodníci již používají hlasové pošty pro komerční zprávy, IP telefonie umožňuje efektivnější využití, protože odesílatel může odesílat zprávy hromadně místo vytáčení každého čísla zvlášť. Také razantním snížení poplatků - 25 -
Rizika IP telefonie a přehled útoků za hovory, které VoIP přináší, se tyto útoky stávají velmi výhodné pro útočníka. Pro generování SPITu dokonale slouží nástroje Spitter a TeleYapper využívající Asterisk IP PBX. Co se týče detekování e-mailového spamu, tak je již na dobré úrovni. Jelikož je detekce SPITu podobná, lze využít některých z již známých metod. Bohužel u detekce SPITu nastává problém ten, že se jedná o realtime-provoz a celé odhalení musí probíhat v reálném čase. Velkou nevýhodou však je podobnost používaných signalizačních protokolů legitimního provozu a SPITu. Dále také analýza zvukové stopy hovoru je v nepoměru s analýzou textu u spamu. [27] 2.3.2 Voice phishing Jedná se o podvod, kdy je uživatel podveden a útočník se od něj snaží získat důvěrné informace. Jeho předchůdcem je e-mailový spam, který je stále velmi rozšířený, což můžeme očekávat také u VoIP komunikace. Kde se může objevit ve formě e-mailového spamu, ve kterém je adresát vyzván o verifikaci autentizačních údajů nebo také údajů k bankovnímu účtu prostřednictvím hovoru na číslo útočníka. Je mnohem nebezpečnější než e-mailový spam, jelikož neznalí uživatelé daleko více důvěřují telefonu než e-mailu. 2.4 Odepření služeb (DoS) Útoky patřící do kategorie odepření služeb, zkráceně DoS mají za cíl znemožnit uživateli použití VoIP služeb. V případě Dos útoku mířeného na webový server je důsledkem pouze pomalé načítání stránek, avšak ve VoIP, jenž je mnohem závislejší na QoS, může být služba naprosto nepoužitelná. Pokud dojde k útoku distribuovanou formou Dos tzv. DDOS, při které zaútočí na cíl několik stanic najednou, je účinek útoku ještě znásoben. Další nevýhodou VoIP telefonie je použití většího množství protokolů sloužících k signalizaci, sestavení hovoru a přenosu dat. Jednotlivé protokoly pracují v různých vrstvách a kterýkoliv může být cílem útoku. Cílem útoku mohou být jak IP telefony, tak i servery. Servery mají mnohem větší výpočetní výkon na rozdíl od koncových zařízení, jsou tedy vůči DoS útoku odolnější. S masivním rozšiřováním VoIP je nutné brát ohled právě na tento typ útoku, jelikož jsou lehce proveditelné i pro začátečníka s minimem zkušeností o hackingu. Na internetu je volně ke stažení celá řada nástrojů s intuitivním GUI, jmenujme např. LOIC, XOIC a HULK. VoIP využívají především firmy závislé na dostupnosti komunikačních služeb, útoky DoS jsou tak pro ně obrovskou hrozbou. Při zasažení firemních serverů jsou tedy koncové telefony nedostupné, komunikace firmy s vnějším světem nemožná a dochází k finančním ztrátám. Je tedy nutné implementovat systém, který bude efektivní v odhalování těchto útoků a navýšit tak spolehlivost VoIP. 2.4.1 Single packet útoky Při útoku Single packet je využito speciálně upraveného paketu, který využívá zranitelnosti určitého protokolu a následně dochází k nestandartnímu chování systému popř. jeho celého pádu. Tento útok je mnohem sofistikovanější než DoS, není tak snadno odhalitelný v síťovém provozu a k úspěšnému útoku stačí pouze jediný paket. Nejlepší možnou ochranou je fuzzing, což je black-box testování protokolů. Samotné testování probíhá tak, že na cílovou stanici jsou odesílány speciální zprávy s cílem odhalit neobvyklé chování daného systému. Jako příklad můžeme uvést stav buffer overflow, ke kterému dochází v nedostatku - 26 -
Rizika IP telefonie a přehled útoků paměti. Dochází ke stavu, kdy systém je zahlcen a je neschopný přijímat hovory. Toto testování většinou provádí již výrobci VoIP zařízení. [11] Single packet útoky lze rozdělit do následujících kategorií: 1) Buffer overflow vulnerabilities Útok týkající se přetečení vyrovnávací paměti. U SIP zásobníků bez adekvátního ověření kontroly jejich délky. 2) SIP SQL injection vulnerabilities Podobně jako u webových aplikací i SIP servery používají databázové aplikace k dotazování a ověřování informací o uživateli. Díky nedostatečné kontrole SIP registrátorů může dojít k neoprávněnému vstupu do databáze. Tímto způsobem lze lehce získat informace, zda je uživatel online nebo jakou má IP adresu. 3) Format string vulnerabilities Využití chyby špatného formátu řetězce, kdy u špatně naprogramovaných SIP zásobníků může hacker číst jejich hodnoty proměnných nebo zapisovat data v libovolných místech paměti. Důsledkem může být spuštění škodlivého kódu nebo pád celého systému. 4) Non-ASCII Vkládání ne-ascii znaků do SIP hlavičky, které můžou mít za následek nestandardní chování nebo úplný pád služby. 5) Malformed SIP packets Jde o chybně formátované SIP pakety v situaci, kdy dojde k akceptování neplatné zprávy k sestavení SIP hovoru, který má sebedestruktivní chování, které lze přirovnat k DoS útoku. 6) SIP known vulnerabilities Specifické zranitelnosti SIP jako jsou SIP Asterisk-BO, SIP sipd resolve-dos a mnohé další, které mají za následek pád služby SIP tj. vytváření podmínek DoS. 2.4.2 DoS pomocí záplavy paketů Útok DoS záplavou paketů má za cíl zahltit všechny volné zdroje sítě nebo zařízení, tak aby nebylo schopné odpovídat na legitimní provoz. Pod pojmem zdroje si můžeme představit počet aktivních TCP spojení a přenosovou kapacitu u sítí, u zařízení pak vytížení CPU a paměti. DoS útoky lze rozdělit podle vrstev, na které jsou útoky mířeny. Může se jednat obecné útoky cílené na transportní vrstvu nebo přímé na signalizační protokoly v aplikační vrstvě. Z první zmiňované skupiny jmenujme záplavu TCP SYN a UDP paketů. Výhodnější variantou pro útočníka je samozřejmě využití UDP záplavy paketů, protože se jedná o bezstavový protokol, který nepoužívá sekvenční čísla, což ho dělá hůře detekovatelným. Velké množství dnes dostupných telefonů lze vyřadit záplavou na port SIP port tj. 5060. Tyto útoky jsou zde již delší dobu a je proti nim velká řada obranných mechanismů. Slabinou VoIP telefonů oproti VoIP serverům je jejich nízký výpočetní výkon. Telefon tak nemusí síle útoku odolat a také na něm nemohou být implementovány tak silné ochranné prvky. - 27 -
Rizika IP telefonie a přehled útoků Zde následuje výčet útoků proti signalizačním protokolům: 1) Záplava INVITE paketů Cílem je zahlcení serveru nebo telefonu INVITE pakety. Jde o jeden z nejvíce oblíbených útoků na SIP protokol díky velkému množství dostupných programů k jeho realizaci a vysoké úspěšnosti. Nevýhodou je jeho snadná detekce, protože při útoku telefon vyzvání. [27] 2) Záplava REGISTER paketů Cílem je zahlcení serveru REGISTER pakety, tak aby mu bylo zabráněno odpovídat na legitimní požadavky. 3) Záplava RTP paketů Útok zaplavou RTP paketů nepostihuje signalizační protokoly, ale je mířen na RTP protokol, který zprostředkovává datový tok hovoru. Útok je zjednodušen, protože protokol pracuje nad UDP protokolem. Odposlechnutím požadavku INVITE dojde ke zjištění portu, který bude využit pro komunikaci a útok je zacílen právě na něj. Cílem útoku jsou tedy koncové telefony, které můžou být zcela nedostupné. [27] 2.4.3 Zesílení DoS útoku Zesílit útok lze tak, že pokud odpověď na dotaz útočníka vygeneruje větší provoz než samotný požadavek. Dojde tedy k vytvoření falešných požadavků, kde je zdrojová adresa podvržena adresou cíle útoku. Požadavky pak jsou odeslány většímu množství zařízení, což mohou být SIP proxy nebo také VoIP telefony. Odpovědi poté vytvoří frontu požadavků a zařízení tak není schopné komunikace. 2.4.4 Metody detekce Detekce záplavy INVITE, REGISTER a RTP paketů je odhalována za pomoci NetFlow dat. Sledován je například poměr počtu požadavků a kladných odpovědí na server. Útoky záplavou SIP paketů je krom informací z NetFlow dat využito také informací ze SIP hlaviček. Konkrétně se jedná o použité SIP metody a jejich počet co se týče rámce toku. U RTP záplavy je však detekce poněkud těžší, jelikož je zaslán větší množství RTP paketů než paketů signalizačních. Množství je závislé na použitém kodeku. Podle kodeku lze tedy zjistit jak velké množství RTP paketů bude přenášeno. Pokud se přenášené množství znatelně liší, můžeme se domnívat, že dochází k útoku. 2.5 Odcizení služeb a útoky na účtovací systémy 2.5.1 InviteReplay útok Jde o útok využívající slabou autentizaci SIP protokolu. Úkolem útočníka je získání INVITE zprávy z některého již proběhnutého hovoru a následné vyčtení autentizačních údajů. Nejjednodušším postupem k získání těchto údajů je využití DHCP popřípadě ARP spoofingu v pozici MITM. V takto odcizené INVITE zprávě útočník změní RTP parametry jako je IP adresa a port. Takto upravená zpráva je poté odeslána na cíl útoku. Následně dochází ke spojení útočníka s cílem a lze například přehrát SPIT. Takto provedený útok bude úspěšný za předpokladu, že není použitá SIP autentizace. - 28 -
Rizika IP telefonie a přehled útoků Obrázek 1.3: InviteReplay útok [9] 2.5.2 FakeBusy útok Útok, při kterém útočník v pozici MITM odcizí uživateli spojení. Na straně uživatele se situace jeví, jako by se hovor nezdařil z důvodu, že je volané číslo obsazené. Útočník skrze získanou relaci pak telefonuje na náklady oběti. Názornou ukázku útoku můžeme vidět na obr. 1.4. Uživatel Vonage Phone snažící se spojit s uživatelem ATT Phone. Vonage Phone tedy zasílá na svůj Proxy server INVITE zprávu. Proxy server uživatele vyzve k zaslání autentizačních údajů, které jsou zachyceny útočníkem MITM1. Ve zprávě změní IP adresu a port pro RTP komunikaci na své vlastní a tu zašle Proxy serveru. Zároveň Vonage Phone obdrží zprávu BUSY, která oznamuje nedostupnost stanice ATT Phone. Vonage Proxy server komunikuje s ATT Proxy serverem, jenž se snaží zkontaktovat ATT Phone. Útočník číslo dva s označením MITM2 zachytí INVITE zprávu a změní opět IP adresy a porty na své. Tímto způsobem je tedy sestaveno spojení mezi MITM1 a MITM2 a všechny poplatky jsou účtovány uživateli Vonage Phone. Tento útok je pro uživatele těžce odhalitelný, jelikož se zdá, že cílový telefon je pouze obsazený a volané číslo se o pokusu o spojení vůbec nedozví. - 29 -
Rizika IP telefonie a přehled útoků Obrázek 1.4: FakeBusy útok [9] 2.5.3 ByeDelay útok ByeDelay útok má za cíl prodloužit celkový čas spojení přes RTP stream. Ze schématu útoku na obr. 1.5 lze vyčíst, že máme opět dva útočníky, kteří se snaží odchytit informace o spojení jak na straně volajícího, tak i na straně volaného. Celkové sestavení hovoru probíhá standardně, do doby kdy jedna ze stran ukončí hovor a dojde k zaslání BYE zprávy. Tato zpráva je zachycena MITM útočníkem, jenž zašle odpověď 200 OK. Účastnici hovoru jsou přesvědčeni, že hovor byl ukončen, avšak spojení bylo převzato útočníky MITM1 a MITM2. Ti mohou spolu dále komunikovat přes daný RTP stream, jenž se oběma Proxy serverům jeví jako stále probíhající hovor. Uživateli je následně účtována plná doba hovoru, než je skutečně provolaná. - 30 -
Rizika IP telefonie a přehled útoků 2.5.4 ByeDrop útok Obrázek 1.5: ByeDelay útok [9] Je obdobou ByeDelay útoku. Průběh celého útoku je zobrazen na obr. 1.6. U tohoto útoku však dojde k zahození BYE zpráv a spojení nadále probíhá mezi MITM1 a MITM2. Proxy servery však po určité době spojení ukončí samy. V článku je však uvedeno, že ke spojení došlo až po 218 minutách, které jsou stále účtovány uživatelům. - 31 -
Rizika IP telefonie a přehled útoků Obrázek 1.6: ByeDrop útok [9] 2.5.5 Metody detekce Detekce odcizení služby a útoků na účtovací systémy je mnohem komplikovanější, než je tomu u útoků na signalizační protokoly. Problémem je, že díky použití MITM z pohledu serveru vypadá komunikace v naprostém pořádku. Proto základem pro úspěšné detekování útoku je nutnost odhalení MITM. Jedná se však o téměř neřešitelný úkol, protože by musela být monitorována celá komunikační trasa a poté ještě rozeznat upravenou zprávu útočníka. Řešením je dbání zřetele na silnou autentizaci a integritu zpráv. 2.6 Modifikace a aktivní útoky na spojení 2.6.1 Útoky na registraci Velkou výhodou Voip technologie je možnost použití stejného telefonního čísla na více zařízeních. Podmínkou však je, že každý z telefonů musí být registrován u Proxy serveru, který následně směruje příchozí hovor. Server Registrar má za úkol ověření hodnotu pole From z REGISTER zprávy a následně dochází ke změně kontaktní adresy v poli To. Samotná registrace proběhne po aktivaci telefonu a poté se opakuje v intervalu 60 minut. Tento interval může Proxy server změnit ve zprávě 200 OK. Problém nastává při nedostatečné autentizaci, kdy útočník zneužije - 32 -
Rizika IP telefonie a přehled útoků cizí identitu a cílí útok na registrační systém. Primárním cílem útočníka může být odstranění registrace telefonu. Telefon pak není schopen přijmout příchozí hovory, avšak odchozí hovor lze stále realizovat. Pro zesílení útoku útočník deregistraci provádí opakovaně v intervalu několika minut, zamezí tím řádné provozuschopnosti zařízení i po pokusech opětovné registrace. Existuje také možnost registrace telefonu útočníka, který bude v roli dalšího zařízení oběti. Příchozí hovor tedy zvoní i na telefonu útočníka a stačí, aby on přijal hovor jako první. Mezi nejvíce rozšířený útok na SIP registraci patří registration hijacking. Dochází k situaci, kdy je útočníkem přepsána existující registrace. Útočník tak vystupuje pod cizí identitou. Dále může útok využít např. k phishingu nebo k MITM, kdy bude přeposílat provoz legitimnímu uživateli. Obsah má pod kontrolou, ale může ho i měnit. Tento druh útoku je velmi snadno proveditelný a může nést vážné následky. Jeho detekce je obtížná, protože nelze snadno rozlišit, zda se jedná o legitimního uživatele nebo útočníka, protože nejspíš dojde k podvržení IP adresy. K odhalení útoku může dojít v situaci, kdy útočník opakovaně zasílá deregistrační zprávy. Proti tomu se lze bránit nastavením limitu přijatých deregistračních zpráv na jednu IP adresu. Nejlepší možnou obranou je však silná autentizace mezi koncovým zařízením a serverem. 2.6.2 Přesměrování hovorů Tyto útoky jsou velmi podobné útokům na registraci. Mířeny jsou konkrétně vůči příchozím hovorům. V SIP protokolu je dáno, že na INVITE zprávu může odpovědět proxy nebo User Agent zprávou 301 Moved Pernamently nebo 302 Moved Temporarily. Následně se tedy volající pokusí kontaktovat volaného na adrese, která je uvedena v poli Contact. Pokud se útočníkovi podaří odchytit INVITE požadavek a poslat svoji zprávu 301 nebo 302, může přesměrovat hovor na jím určené umístění. Může jím být neplatná IP adresa a dochází tak k DoS útoku nebo může hovor přesměrovat na své zařízení a pokusit se tak o získání důvěrných informací. 2.6.3 Násilné ukončení spojení Úspěšnost tohoto útoku se opět zakládá na slabé autentizaci a jeho cílem je násilně ukončit probíhající hovor. Útočník poté co odchytí údaje o probíhající komunikaci, zasílá BYE zprávu s podvrženými údaji jednoho z účastníků a dochází k přerušení probíhajícího hovoru. Samotný hovor lze ukončit již ve fázi inicializace za pomoci zprávy CANCEL, kterou musí zaslat ve velmi krátkém intervalu ihned po odeslání zprávy INVITE a před přijetím zprávy ACK. K útokům na signalizaci lze také zmínit zaslání re-invite zpráv. Díky těmto re-invite zprávám může útočník upravit parametry probíhajícího spojení. 2.6.4 Metody detekce Co se týče ochrany proti násilnému ukončení spojení a přesměrování probíhajícího hovoru, tak i zde platí stejná pravidla jako pro útoky na registraci. Jelikož je velmi obtížné odlišit legitimní jednání od útoku. Nejlepší prevencí je tak zvýšení zabezpečení signalizačního protokolu. - 33 -
Rizika IP telefonie a přehled útoků 2.6.5 Modifikace obsahu hovoru Při tomto druhu útoku je cílem modifikovat samotný obsah hovoru, pro jehož přenos je ve velké míře využíván RTP protokol, který je postaven na UDP protokolu, jenž není šifrován a je tedy možné jej modifikovat. Parametry z RTP hlavičky: Payload type: použitý audio kodek Sequence number: sekvenční číslo paketu Timestamp: vzorkovací perioda audio streamu Synchronization source identifier (SSRC): identifikace komunikujících stran Jednou z variant tohoto druhu útoku lze popsat jako situaci, při které dojde k podvržení originálního zvukového streamu. Tohoto útočník dosáhne tak, že odchytí RTP paket a ze získaných údajů vytváří modifikované pakety. Tyto pakety obsahuji totožné čísla UDP portů, Payloadu a SSRC, kdy se však zvyšuje Timestamp a sekvenční číslo. Dojde-li k situaci k, že příjemce dostane podvržené pakety s vyšším číslem, legitimní pakety budou zahozeny, neboť budou považovány za neaktuální a neplatné. Další variantou útoku je pouhé přidání útočníkovi stopy do probíhajícího hovoru a tím ovlivnění směru komunikace, zdiskreditování volajícího nebo vkládání šumu a snižování tak kvality hovoru. Pro realizaci útoku lze použít například aplikaci RTPInject. 2.6.6 Metody detekce Tento druh útoku je snadnější detekovat skrze sledování sekvenčního čísla z hlaviček RTP paketů. Sběr těchto dat a následná analýza pomocí NetFlow je velmi jednoduché. 2.7 Další bezpečnostní hrozby Další bezpečnostní hrozbou ve VoIP jsou softwarové telefony, které jsou využívány pro domácí využití nebo v prostředí, kde není možné připojit hardwarové zařízení. Jejich slabinou je PC jakožto platforma, na které jsou provozovány. PC totiž nelze považovat za bezpečné prostředí, může na něm v pozadí běžet velké množství škodlivého softwaru. Druhou skutečností je snížená úroveň integrity a důvěrnosti, kvůli nemožnosti oddělení VLAN pro data a hovory, jak je tomu u hardwarových VoIP zařízení. Pro bezproblémový chod softwarového klienta je nutné ve firewallu povolit širší rozsah UDP portů pro RTP komunikaci, tyto porty ale můžou posloužit pro šíření červů. Seznam nejznámějších hrozeb ve VoIP je zobrazen na obrázku 1.7. - 34 -
Rizika IP telefonie a přehled útoků Obrázek 1.7: Hrozby VoIP [10] - 35 -
SNORT, SURICATA a další nástroje. 3 SNORT, SURICATA a další nástroje. Pro detekci útoků v počítačových sítích známe celou řadu IDS nástrojů. Mezi nejrozšířenější open-source IDS patří Snort a Suricata, kterým je věnována tato kapitola. Dále bych rád zmínil i několik méně známých projektů. 3.1 SNORT Jde o open-source bezpečnostní nástroj pro detekci a prevenci útoků spadající do kategorie NIDS. Pracuje na principu prohledávání síťové komunikace a porovnávání provozu podle signatur již známých útoků. Při odhalení útoku je jeho úkolem provedení akcí, jako je zápis do logu, varování administrátora nebo předání této informace IPS. Při analyzování dat ze sítě, které probíhá v reálném čase, nedochází ke zpomalení provozu. Jádro Snortu je naprogramováno v jazyce C a zachytávání paketů je realizováno knihovnou libpcap. Kontroluje veškerou průchozí komunikaci běžící na protokolech, jakými jsou TCP, IP, UDP a ICMP. Provozovat ho lze na Unixových systémech, Windows a MacOS X. Hardwarové požadavky jsou závislé na velikosti monitorované sítě a objemu provozu. [8] 3.1.1 Režimy Snortu 1) Sniffer mode Režim slídiče zachytává veškerý provoz a zobrazuje jej v terminálu. 2) Packetlogger mode 3) NIDS režim Rozšířená verze sniffer módu, zachycená data jsou uložena do logu. Nejužitečnější režim detekce narušení sloužící k monitorování nebezpečných aktivit v síti. Rozdíl mezi dvěma předchozími módy je ten, že nezaznamenává všechnu aktivitu, ale jen tu, kterou podle pravidel označí jako nebezpečnou. 3.1.2 Achitektura a moduly Snortu Obrázek 1.8: Achitektura Snortu 3.1.2.1 Jednotka paketového záchytu Jednotka paketového záchytu Sniffer je aplikací naslouchající síťovému provoz, který protéká skrz IDS. Pracuje s protokoly TCP, IP, UDP, ICMP a interpretuje zachycené pakety do pro lidi srozumitelné formy nebo posílá na výstup k dalšímu zpracování. Jednotku lze použít k síťové a výkonnostní analýze a v neposlední řadě i k odposlechu nešifrovaných hesel. [8] - 36 -
SNORT, SURICATA a další nástroje. Obrázek 1.9: Princip jednotky paketového záchytu 3.1.2.2 Preprocesor Preprocesor pomáhá k identifikaci potencionálních útoků a připravuje pakety pro detekční jednotku. Dalším úkolem je kontrola integrity a defragmentace paketů, protože při přenosu větších dat jsou pakety rozděleny na menší části a pro kontrolu je nutné je zkompletovat. Nahlíží tak do hlaviček paketů, zda nedošlo k jejich modifikaci útočníkem. Dále pokud je k útoku použit paket, který překročí velikost MTU 1500 bajtů, dojde k jeho rozdělení a nemusí již splňovat signaturu útoku a nebude detekován. Jakmile dojde k defragmenaci je hrozba odhalena. [8] Obrázek 1.10: Preprocesor Snortu 3.1.2.3 Detekční jednotka Detekční jednotka porovnává přijaté data z preprocesoru s databází pravidel. Při zjištění podobnosti se signaturou z databáze jsou data předána jednotce pro logovaní a výstrahy. Časově i výkonnostně se jedná o nejnáročnější modul. Jeho výkonnost závisí na počtu pravidel, výkonu stanice a vytížení sítě. [8] - 37 -
SNORT, SURICATA a další nástroje. Obrázek 1.11: Detekční jednotka 3.1.2.4 Systém logovaní a výstrah Úkolem jednotky je zapsání aktivit po obdržení informací z detekční jednotky. Data můžou být odeslána e-mailem, uložena do databáze nebo zobrazena na webu. Standardně jsou uložena do log souboru, který se nachází v adresáři /var/log/snort. [8] - 38 -
SNORT, SURICATA a další nástroje. 3.2 SURICATA Obrázek 1.12: Jednotka logování Velkým konkurentem pro Snort je právě Suricata. V současnosti je v testovací fázi volně ke stažení a zatím nebyl vpuštěn do komerční sféry. Jde výkonný IDS vyvinutý a podporovaný nadací OISF spolu s Emerging Threats (www.emergingthreats.net). Velkou výhodou oproti Snortu je podpora multi-threadingu, automatická detekce protokolů, lepší viditelnost provozu na aplikační vrstvě, rychlejší normalizace, parsování HTTP datového toku a novinkou v této oblasti je využití grafických procesorů pro zpracování paketů. [12, 14] 3.2.1 Podpora multi-threadingu Vzhledem k tomu, že nejvíce výpočetní práce je nutné pro samotnou detekci, rozhodli se vývojáři Suricaty implementovat vláknové rozdělení zátěže pro navýšení výkonu detekce. Samotná analýza je tak rovnoměrně rozdělena mezi jednotlivá jádra a jde o razantní navýšení efektivity. Díky velkému vypočetnímu výkonu dnešních grafických procesorů, lze také využít technologie CUDA a OpenGL k řešení jednoduchých instrukcí v Suricatě. [12] - 39 -
SNORT, SURICATA a další nástroje. 3.2.2 HTP knihovna Jádro Suricaty pracuje společně s HTP knihovnou, která provádí parsování a analýzu posloupnosti prvků. Snaží se tak určit gramatickou strukturu vůči dané formální gramatice. Hlavní funkcí tohoto modulu je analyzovat data protokolu HTTP. [10] Tento modul byl vytvořen v jazyce C a jeho autorem je Ivan Ristic. Hlavní funkcí je analýza HTTP prokolu. Využívána je také pro filtry a proxy. Její jádro podporuje funkcionality, jako jsou snort VRT pravidla, snort logování, standardizovaný vstup/výstup, nastavení pravidel jazyka, interakce s výstupními logy, podpora IPv6, statistika výkonu, možnosti ovládání toku dat, Windows, Gzip dekomprese a rychlé porovnání IP adres. [12, 14] 3.2.3 Architektura Suricaty Na obrázku 1.13 je zobrazena architektura Suricaty, kde je detekce řešena třemi samostatnými vlákny. Obrázek 1.13: Schéma Suricaty 3.3 CAMNEP Jedná se o projekt financovaný armádou spojených států. V roce 2005 nabídla spolupráci ústavu výpočetní techniky MU a Gerstnerově laboratoři na ČVUT. Výsledkem jejich spolupráce bylo vytvoření týmu pro řešení projektu CAMNEP, který měl za úkol vytvořit systém pro detekci průniku ve vysokorychlostních sítích. Skupina z MU zastřešila problematiku měření síťového provozu a inteligentní vizualizaci výstupů systému. Zatímco skupina z Gerstnerovy laboratoře se zaměřila na rozpoznávání anomálního provozu a minimalizace falešných poplachů. [13, 15] 3.3.1 Architektura systému CAMNEP (Cooperative Adaptive Mechanism for Network Protection) je rozdělen do tří vrstev. První vrstva systému je optimalizována pro nejvyšší výkon, tak aby byla schopna zpracovat a připravit pro vyšší vrstvu velký objem dat, jenž dnes prochází ve vysokorychlostních sítích. Druhá vrstva pracuje s předzpracovanými daty a vyhledává anomální provoz spolu s určováním míry důvěryhodnosti jednotlivých toků v síti. Nejvyšší vrstva pak tvoří rozhraní s výsledky o detekovaném anomálním provozu pro správce bezpečnosti sítě. [13, 15] - 40 -
SNORT, SURICATA a další nástroje. Obrázek 1.14: Architektura systému CAMNEP 3.3.1.1 Vrstva sběru dat a jejich předzpracování Nejnižší vrstva je složena z FlowMon sond tvořících NetFlow statistiku provozu, která je následně odeslána na kolektor. Kolektor provádí sběr a předzpracování statistik pro vyšší vrstvy, kterým tak ulehčí od náročných výpočetních operací. [13, 15] 3.3.1.2 Agentní vrstva pro detekci anomálií Prostřední vrstva se skládá z agentů detekujících anomálie v NetFlow datech. Jednotliví agenti reprezentují různé metody detekce, ke konečnému rozhodnutí je využito kolektivního rozhodování.[14] 3.3.1.3 Uživatelské rozhraní síťového operátora Úkolem nejvyšší vrstvy je interakce se správcem skrze vizualizační aplikaci NetFlow Visualizer. NFVis prezentuje výsledky z detekční vrstvy o podezřelých aktivitách spolu s detailními informacemi, jako jsou DNS jména, IP adresy, porty atd. [13, 15] 3.3.2 Sběr dat ve vysokorychlostních sítích Data jsou sbírána z IP toků sondami FlowMon. Tok je definován jako sekvence paketů s pěti hlavními údaji: zdrojová/cílová adresa, zdrojový/cílový port a číslo použitého protokolu. Výsledné statistiky obsahující informace o hustotě provozu a aktivitách uživatelů sítě obstarávají specializované aplikace, tzv. kolektory, které mají za úkol shromažďovat NetFlow data ze sond. [13, 15] - 41 -
SNORT, SURICATA a další nástroje. 3.3.3 Detekce škodlivého síťového provozu Detekční vrstva vybírá z množiny zaznamenaných spojení, která představují podezřelou či nežádoucí aktivitu v síti. Tyto incidenty jsou následně předány bezpečnostním správcům, jejichž úkolem je provést odpovídající kroky v rámci bezpečnostních opatření. Celá tato vrstva je založena na multiagentním systému, ve kterém společně pracuje několik samostatných entit v podobě agentů, jenž každý vykonává vlastní detekci. Výsledky získané od jednotlivých agentů jsou v průběhu celého detekčního procesu agregovány k tvorbě komplexního pohledu na celý provoz v síti. Jednotliví agenti mají různé metody detekce anomálií a po analýze přiřazují jednotlivým spojením míru anomálie. Tato hodnota získaná od každého agenta poté slouží ke konečné agregaci a závěrem se vytvoří celková míra anomálie posuzovaného spojení. [13, 15] 3.3.4 Vizualizace síťového provozu Tradiční dění v síti je zobrazeno ve formě grafů a jednotlivé incidenty jsou pak uloženy jako řádky v tabulce. V projektu CAMNEP je zobrazení nedůvěryhodného provozu řešeno tak, aby operátor mohl efektivně rozhodovat, zda se jedná o hrozbu či nikoliv. NFVis zobrazuje síť jako neorientovaný graf, kde uzly představují zařízení v síti a hrany jejich komunikaci. Graf je doplněn tabulkami obsahujícími objem přenesených dat, druh provozu atd. [13, 15] 3.4 Caligare Flow Inspector Caligare Flow Inspector je softwarové řešení schopné exportu síťových toků ze zařízení od firem jako jsou Cisco Systems, 3COM, Juniper, Extreme Networks a také ze softwarových sond. Dokáže sledovat síťové toky v reálném čase, analyzovat je, filtrovat a agregovat informace. Pro nekomerční účely je možné otestovat volně dostupnou verzi, která je však omezena jen na dvě zařízení s objemem do 250 toků/s a absencí detekce anomálií v síti. V placené verzi však již je detekce skenování portů, DoS útoků, provozu her, peer-to-peer nástrojů a problémů ve směrování. Pro nasazení Caligare Flow Inspector je třeba stanici s linuxovým systémem, webovým serverem a databází. Komunikace s bezpečnostním správcem probíhá skrze webové rozhraní, kde je možné nahlížet do nastavení kolektoru a sledovat dění v síti v reálném čase ve formě grafů. [16] 3.5 FlowMon ADS FlowMon ADS je komerčním řešení pro detekování anomálií v sítích. Přichází s novými možnostmi využití statistik o provozu v datové síti (NetFlow, IPFIX, jflow, NetStream). Díky nové technologii tzv. behaviorální analýzy (Network Behavior Analysis) je schopen detekovat hrozby, které překonaly zabezpečení na perimetru nebo byly zavlečeny do datové sítě jiným způsobem nebo ty, pro které dosud nebyl vytvořena signatura. Automatická detekce bezpečnostních hrozeb, anomálií provozu datové sítě a konfiguračních problémů velmi zjednodušuje správu takové sítě, zvyšuje bezpečnost a umožňuje proaktivně identifikovat příčiny problémů. Je vhodným doplňkem pro nástroje pracující na bázi signatur. Pracuje na úrovni sítě, není tak nutná jeho instalace na koncových stanicích. Je schopen detekovat útoky na síťové služby, infikované stanice šířící škodlivý obsah, anomálie DNS, anomálie DHCP, skenování portů, nežádoucí síťové aplikace jako jsou P2P, anonymizační služby, výpadky a špatné konfigurace služeb, úniky dat, Útoky na VoIP, šíření spamu a zneužívání serverů např. pro DDoS útoky. [17] - 42 -
Praktická realizace detekce anomálií a minimalizace rizik ve VoIP 4 Praktická realizace detekce anomálií a minimalizace rizik ve VoIP 4.1 Praktická realizace detekce anomálií V této části se věnuji otestování Snortu spolu s modulem AD ve verzi 2.9.3.1 pro detekování anomálií v síti. Z širokého spektra hrozeb VoIP telefonii jsem vybral nejrozšířenější DoS útoky a to OPTIONS, REGISTER, INVITE a ICMP flood. 4.1.1 Implementace Snortu Pro otestování detekce anomálií využívám virtuální stroj se systémem Red Hat Enterprise Linux Server release 6.3 běžícím ve VirtualBoxu verze 5.07. Zde je stručný popis instalace Snortu a nutných doplňků pro jeho bezproblémový chod: Jako první nainstalujeme potřebné doplňky a knihovny: yum install gcc gcc-c++ kernel-devel patch make nano libxml2 libxml2-devel pcre pcre-devel flex bison libpcap libpcap-devel V druhém kroku stáhneme knihovnu daq. Extrahujeme a provedeme instalaci pomocí příkazů: tar daq-x.x.x.tar.gz cd /home/daq-x.x.x./configure && make && make install Následuje instalace knihoven libnet a libdnet, které rozbalíme a po přesunu do jejich adresáře nainstalujeme: tar libnet-x.x.tar.gz cd /home/libnet-x.x./configure && make && make install tar libdnet-x.x.tar.gz cd /home/libdnet-x.x./configure && make && make install Poté stáhneme Snort a spp_anomalydetection modul. Po extrahování je před instalací třeba ještě překopírovat spp_anomalydetection.c a spp_anomalydetection.h z '/home' do '/home/snortx.x.x/src/preprocessors' - 43 -
Praktická realizace detekce anomálií a minimalizace rizik ve VoIP tar snort-x.x.x.tar.gz tar AnomalyDetection.tar.gz cp /home/spp_anomalydetection.c /home/snort-x.x.x/src/preprocessors cp /home/spp_anomalydetection.h /home/snort-x.x.x/src/preprocessors V dalším kroku vyhledáme soubor plugbase.c, který se nachází v '/home/snort-x.x.x/src/'. V něm nalezneme sekci '/* built-in preprocessors */' a přidáme hlavičku: #include "preprocessors/spp_anomalydetection.h" A ve funkci 'void RegisterPreprocessors(void)' přidáme řádek: SetupAnomalyDetection(); Poté editujeme Makefile.in, který se nachází '/home/snort-x.x.x/src/preprocessors/' a na konci sekce 'libspp_a_sources' přidáme: spp_anomalydetection.c spp_anomalydetection.h A v sekci 'am_libspp_a_objects' přidáme: spp_anomalydetection.$(objext) Nyní se přesuneme do adresáře Snortu a dokončíme instalaci: cd /home/snort-x.x.x./configure --disable-ipv6 --disable-reload && make && make install Pokud instalace proběhla v pořádku, je na řadě první úprava konfiguračního souboru pro potřeby získání dat nutných k vytvoření síťového profilu, jenž je popsána v další kapitole. 4.1.2 Generování profilu sítě Data síťového charakteru jsou získána z komunikace dvou virtuálních serverů. Na nichž je spuštěna instance Snortu pro zachytávání komunikace pro následné vytvoření profilu sítě a softwaru SIPp, který tuto komunikaci simuluje SIP. Před spuštěním Snortu je nutné upravit jeho konfigurační soubor snort.conf uložený v adresáři '/etc/', do kterého přidáme tento řádek, který odkazuje na logovací soubor a udává časový interval, ve kterém se data budou ukládat: preprocessor AnomalyDetection: LogPath /var/log/snort log time 60-44 -
Praktická realizace detekce anomálií a minimalizace rizik ve VoIP Snort spustíme tímto příkazem, kde parametrem -c odkazujeme na konfigurační soubor a parametrem -h na IP adresu z které budeme získávat data: snort c /etc/snort/snort.conf h 192.168.25.57 Pak již na výstupu z terminálu můžeme vidět, jak dochází k pravidelnému zápisu do logovácího souboru viz. obrázek 1.15. Obrázek 1.15: Zápis do logovacího souboru 4.1.3 Výstup logovacího souboru Na obrázku 1.16 vidíme ukázku z logovacího souboru, z kterého můžeme vyčíst záznam o dění v síti vždy za uplynulých 60 sekund. Obrázek 1.16: Ukázka logovacího souboru Každý řádek obsahuje 29 parametrů popisujících síťový provoz. Zde je jejich výčet: celkový počet přenesených TCP paketů počet odchozích TCP paketů počet příchozích TCP paketů počet TCP paketů v rámci podsítě celkový počet přenesených UDP paketů počet odchozích UDP paketů počet příchozích UDP paketů počet UDP paketů v rámci podsítě celkový počet přenesených ICMP paketů počet odchozích ICMP paketů - 45 -
Praktická realizace detekce anomálií a minimalizace rizik ve VoIP počet příchozích ICMP paketů počet ICMP paketů v rámci podsítě, počet paketů TCP s SYN/ACK počet odchozích TCP paketů z portu 80 počet příchozích TCP paketů z portu 80 počet odchozích UDP paketů z portu 53 počet příchozích UDP paketů z portu 53 počet ARP-request paketů počet ARP-replay paketů počet NOT TCP/IP paketů celkový počet všech přenesených paketů rychlost TCP uploadu rychlost TCP downloadu rychlost WWW uploadu rychlost WWW downloadu rychlost UDP uploadu rychlost UDP downloadu rychlost DNS uploadu rychlost DNS downloadu Pro potřeby mé diplomové práce se zaměřím pouze na počet přijatých paketů, rychlost stahování UDP paketů a počet příchozích ICMP paketů. Z grafů níže sestrojených z hodnot získaných z logovacího souboru můžeme vyčíst pohyb těchto hodnot za posledních 24 hodin. Lze si všimnout, že rychlost stahování UDP paketů se pohybuje od 18.4 kbps a do 18.8 kbps. Rychlost odesílání se pak pohybuje v rozmezí od 19.4 kbps do 20 kbps. Hodnota počtu ICMP paketů je 120 a je konstantní pro oba grafy. Posledními mnou sledovaným parametry je celkový počet přenesených UDP paketů s hodnotami od 7260 do 7266. Počet odchozích UDP paketů s hodnotami pohybujícími se okolo hodnoty 3960 a počet přijatých UDP paketů s hodnotou okolo 3300. - 46 -
2:51:01 3:51:01 4:51:01 5:51:01 6:51:01 7:51:01 8:51:01 9:51:01 10:51:01 11:51:01 12:51:01 13:51:01 14:51:01 15:51:01 16:51:01 17:51:01 18:51:01 19:51:01 20:51:01 21:51:01 22:51:01 23:51:01 0:51:01 1:51:01 2:51:01 2:51:01 3:51:01 4:51:01 5:51:01 6:51:01 7:51:01 8:51:01 9:51:01 10:51:01 11:51:01 12:51:01 13:51:01 14:51:01 15:51:01 16:51:01 17:51:01 18:51:01 19:51:01 20:51:01 21:51:01 22:51:01 23:51:01 0:51:01 1:51:01 Praktická realizace detekce anomálií a minimalizace rizik ve VoIP Tabulka 1.1: Rychlost downloadu UDP paketů Rychlost downloadu UDP paketů [kbps] za 24 hodin 18,8 18,7 18,6 18,5 18,4 18,3 18,2 Tabulka 1.2: Rychlost uploadu UDP paketů Rychlost uploadu UDP paketů [kbps] za 24h 20 19,9 19,8 19,7 19,6 19,5 19,4 19,3 19,2-47 -
2:51:01 3:51:01 4:51:01 5:51:01 6:51:01 7:51:01 8:51:01 9:51:01 10:51:01 11:51:01 12:51:01 13:51:01 14:51:01 15:51:01 16:51:01 17:51:01 18:51:01 19:51:01 20:51:01 21:51:01 22:51:01 23:51:01 0:51:01 1:51:01 2:51:01 3:51:01 4:51:01 5:51:01 6:51:01 7:51:01 8:51:01 9:51:01 10:51:01 11:51:01 12:51:01 13:51:01 14:51:01 15:51:01 16:51:01 17:51:01 18:51:01 19:51:01 20:51:01 21:51:01 22:51:01 23:51:01 0:51:01 1:51:01 Praktická realizace detekce anomálií a minimalizace rizik ve VoIP Tabulka 1.3: Počet příchozích UDP paketů Počet příchozích UDP paketů [počet paketů] 3310 3300 3290 3280 3270 3260 3250 3240 Tabulka 1.4: Počet odchozích UDP paketů Počet odchozích UDP paketů [počet paketů] 3970 3960 3950 3940 3930 3920 3910 3900 3890 3880-48 -
2:51:01 3:51:01 4:51:01 5:51:01 6:51:01 7:51:01 8:51:01 9:51:01 10:51:01 11:51:01 12:51:01 13:51:01 14:51:01 15:51:01 16:51:01 17:51:01 18:51:01 19:51:01 20:51:01 21:51:01 22:51:01 23:51:01 0:51:01 1:51:01 2:51:01 2:51:01 3:51:01 4:51:01 5:51:01 6:51:01 7:51:01 8:51:01 9:51:01 10:51:01 11:51:01 12:51:01 13:51:01 14:51:01 15:51:01 16:51:01 17:51:01 18:51:01 19:51:01 20:51:01 21:51:01 22:51:01 23:51:01 0:51:01 1:51:01 Praktická realizace detekce anomálií a minimalizace rizik ve VoIP Tabulka 1.5: Počet přenesených UDP paketů Celkový počet přenesených UDP paketů [počet paketů] 7267 7266 7265 7264 7263 7262 7261 7260 7259 7258 7257 Tabulka 1.6: Odchozí ICMP pakety Odchozí ICMP pakety [počet paketů] za 24 hodin 140 120 100 80 60 40 20 0-49 -
2:51:01 3:51:01 4:51:01 5:51:01 6:51:01 7:51:01 8:51:01 9:51:01 10:51:01 11:51:01 12:51:01 13:51:01 14:51:01 15:51:01 16:51:01 17:51:01 18:51:01 19:51:01 20:51:01 21:51:01 22:51:01 23:51:01 0:51:01 1:51:01 2:51:01 Praktická realizace detekce anomálií a minimalizace rizik ve VoIP Tabulka 1.7: Příchozí ICMP pakety Příchozí ICMP pakety [počet paketů] za 24 hodin 140 120 100 80 60 40 20 0 4.1.4 Anomaly Detection Struktura Anomaly Detection preprocesor slouží k analýze síťového provozu a detekování v něm vyskytujících se anomálií. Je schopen analýzy velké řady parametrů komunikace jako je TCP, UDP, ICMP, ARP provoz a rychlost příchozích a odchozích paketů. Jeho vstupním souborem je logovací soubor ADlog60.txt, který se nachází v adresáři '/var/log/snort/'. Výstupem pak je PROFILE60.txt umístěný v adresáři '/etc/'. Struktura Anomaly Detection systému zobrazena na obrázku 1.17 se skládá z těchto hlavních částí: Obrázek 1.17: Struktura AD systému - 50 -
Praktická realizace detekce anomálií a minimalizace rizik ve VoIP 4.1.4.1 AD Profile Generator Modul s názvem AD Profile Generátor slouží pro vygenerování souboru PROFILE60.txt, reprezentujícího síťový profil. Vstupními daty pro něj je soubor ADLog60.txt, který obsahuje data popisující síťový provoz. Tento profil je generován na základě těchto pěti algoritmů. Výchozím algoritmem je Moving average, který počítá klouzavý průměr. Na výběr pak je ještě algoritmus Naive method, Autoregressive time series, Holt-Winters a jeho modifikace Holt-Winters:Brutlag. Dalším důležitým parametrem je období, pro které bude výpočet vykonán. Nabízenými možnostmi jsou LAST, DAILY a WEEKY. Model LAST bude počítat s naposledy získanými daty, model DAILY s daty za posledních 24 hodin a model WEEKLY s daty za uplynulých 7 dní, kde je profil vypočten pro každý den zvlášť. 4.1.4.2 AD Preprocessor Úkolem AD preprocessoru je generování výstrah, pracujícím na principu porovnávání parametrů predikovaného modelu ze souboru PROFILE60.txt s provozem sítě. Pokud tedy hodnota ze sítě přesáhne definovanou minimální či maximální hodnotu dojde k vyvolání alertu. Výstrahy jsou počítány podle následujícího vzorce: W / (w 2σ; w + 2σ) kde W značí aktuální provoz a σ směrodatnou odchylku, jenž byla získána ze souboru PROFILE60.txt. 4.1.4.3 AD Evaluator AD Evuluator slouží k porovnání statistik Mean absolute error (průměrné absolutní chyby) mezi dvěma soubory. Lze ho také použít pro porovnání modelu predikovaného a historického, ale i predikovaného modelu s hodnotami reálnými. 4.1.5 Generování predikovaného modelu Pro vytvoření predikovaného modelu potřebujeme logovací soubor ADLog60.txt zachycující 72 hodin síťového provozu. Defaultním algoritmem je AVG, což je klouzavý průměr. Generovat profil však lze dle více různých algoritmů. Dalšími možnými pak jsou Naive, Autoregresive time, Holt- Winters a jeho modifikace HoltWinters Brutlag. 4.1.5.1 Holt-Wintersova metoda V této podkapitole popíši, co Holt-Wintersova metoda znamená, k čemu slouží a její základní vzorce. Holt-Wintersova metoda byla navržena Charlesem C. Holtem v roce 1957 a posléze vylepšena jeho studentem Peterem R. Wintersem v šedesátých letech. Předpovídá hodnoty jak pro jeden časový krok do budoucnosti, tak pro několik následujících kroků, neboť obsahuje mechanismus, který se dokáže vypořádat s chybějícími daty. Vychází z premisy, že pozorovaná časová řada může být dekomponována do tří komponent a to do základní úrovně, lineárního trendu a sezónního trendu. Kde a, b, c značí jednotlivé komponenty, tedy základní úroveň, lineární trend, sezónní trend a m značí časovou periodu sezónního cyklu. [18, 19] - 51 -
Praktická realizace detekce anomálií a minimalizace rizik ve VoIP Základní úroveň: Lineární trend (sklon): Sezónní trend: Predikce je potom suma těchto tří komponent: Pro potřeby otestování detekce anomálií je použito právě tohoto algoritmu, který vygenerujeme následujícím příkazem: ad_profilegenerator.r l /var/log/snort/adlog60.txt p /etc/profile HW 1.txt a 10080 m HW hw DAILY d 1 v Kde parametrem -l nastavíme cestu k logovacímu souboru, ze kterého jsou čteny data, parametrem -p cestu k souboru do kterého je profil zapsán, parametrem -a počet predikovaných hodnot a parametrem -hw časový horizont. Struktura profilu je rozdělena do pěti částí. V prvním sloupci je datum ve formátu den, měsíc a rok. Druhý sloupec značí den v týdnu, kde pondělí má číslo jedna a až neděle s číslem sedm. Třetí sloupec obsahuje datum záznamu. Další sloupce zobrazují minimální a maximální hodnotu daného parametru v síti. Takto vygenerovaný model nalezneme v souboru PROFILE60.txt v adresáři '/etc/'. Na obr. 1.18 je ukázka jeho struktury. Výpis obsahuje hodnoty minimálních a maximálních mezí pro všechny parametry, které jsou popsány v kapitole věnující se výstupu z logovacího souboru. - 52 -
Praktická realizace detekce anomálií a minimalizace rizik ve VoIP Obrázek 1.18: Struktura predikovaného modelu 4.1.6 Konfigurace Snortu Hlavním konfiguračním souborem Snortu je snort.conf, který se nachází v '/etc/'. Přidána byla cesta k souboru classification.config sloužícím pro klasifikaci alertu. Dále preprocessor.rules ve kterém jsou uložena pravidla pro Anomaly Detection preprocesoru. Třetí řádek definuje cestu k predikovanému modelu v '/etc/profile-hw-1.txt' a cestu k logovacímu souboru v '/var/log/snort/alert' spolu s intervalem záznamu anomalií. include classification.config include /etc/preprocessor.rules preprocessor AnomalyDetection: ProfilePath /etc/profile-hw-1.txt LogPath /var/log/snort alert log time 60 4.1.7 Úprava pravidel pro AD preprocesor Pro otestování jsem vycházel z jednoho pravidla, které je uloženo v '/etc/ preprocessor.rules'. Zbývající pravidla jsem odstranil a ponechal pouze jedno, které jsem vždy upravil před provedením útoku. Pravidlo níže má za úkol detekovat útok OPTIONS flood, při kterém dochází ke zvýšení maximální hodnoty na UDP portu: alert udp any any -> 192.168.25.57 5060:5064 ( msg: "AD HIGH VALUE OF UDP DATA"; sid:1000152; gid:1000100; rev: 1; metadata: rule type preproc; classtype:bad-unknown; ) Dále jsem pravidlo upravil pro detekování útoku REGISTER flood: alert udp any any -> 192.168.25.57 5060 ( msg: "AD HIGH VALUE OF REGISTER MESSAGES"; sid:1000152; gid:1000100; rev: 1; metadata: rule type preproc; classtype:bad-unknown; ) - 53 -
Praktická realizace detekce anomálií a minimalizace rizik ve VoIP Třetím Pravidlem je Snort schopen detekovat útok INVITE flood: alert udp any any -> 192.168.25.57 5000 ( msg: "AD HIGH VALUE OF INVITE MESSAGES"; sid:1000152; gid:1000100; rev: 1; metadata: rule type preproc; classtype:bad-unknown; ) Čtvrtým pravidlem Snort detekuje útok ICMP flood: alert icmp any any -> 192.168.25.57 ( msg: "AD HIGH VALUE OF ICMP DATA"; sid:1000152; gid:1000100; rev: 1; metadata: rule type preproc; classtype:bad-unknown; ) 4.1.8 SIPp SIPp je open source program pro generování provozu, navržený pro testování SIP prostředí. Byl napsán Richardem Gayraudem a posléze upraven Olivierem Jacquesem. Díky velké oblibě je program stále zdokonalován komunitou developerů. Je schopen simulace chovaní UAC, UAS, generování signalizace ale i přenos média. Velmi často je využíván pro generování provozu v modelových situacích při ověřování zabezpečení a testování zátěže. Ovládán je skrze terminál, později také došlo k implementaci funkce pro import XML souborů pro tvorbu složitějších komunikačních schémat. Dále také přibyla možnost importu CSV souborů pro emulaci uživatelů. Za zmínku také stojí schopnost zasílat RTP média ve formátu.pcap. [20] 4.1.9 Generovaní útoků 4.1.9.1 Záplava OPTIONS zpráv Pro simulaci útoku OPTIONS flood bylo využito programu SIPp. Příkaz pro zaslání OPTIONS zpráv je následující: sipp 192.168.25.57 -sf '/root/desktop/options.xml' -m 100000 -s 200 Obrázek 1.19: Vygenerování OPTIONS flood útoku - 54 -
Praktická realizace detekce anomálií a minimalizace rizik ve VoIP 4.1.9.2 Záplava REGISTER zpráv Pro simulaci útoku OPTIONS flood bylo také využito programu SIPp. Příkaz pro zaslání OPTIONS zpráv je následující: sipp 192.168.25.57 -sf REGISTER_client.xml -inf REGISTER_client.csv -m 1 -l 1 -trace_msg -trace_err Obrázek 1.20: Vygenerování REGISTER flood útoku 4.1.9.3 Záplava INVITE zpráv Generovat útok Invite flood je možné provádět přímo z terminálu bez nutnosti instalace, protože v Kali Linux ho je již obsažen. Příkaz pro provedení útoku je následující: inviteflood eth1 5000 192.168.25.57 192.168.25.57 10000 4.1.9.4 Záplava ICMP zpráv Pro ICMP flood útok bylo využito jednoduchého programu hping3, který je také možné spustit přímo z terminálu bez nutnosti instalace, protože v Kali Linuxu je již obsažen. Příkaz pro provedení útoku je následující: hping3 -c 1000 --icmp 192.168.25.57-55 -
Praktická realizace detekce anomálií a minimalizace rizik ve VoIP Obrázek 1.21: Vygenerování ICMP flood útoku 4.1.10 Detekování anomálií 4.1.10.1 Behaviorální analýza Tato metoda pracuje na předpokladu, že útoky lze detekovat pomocí sledování odchylek od běžného sítového provozu. Odchylka od definovaného chování je poté označena jako anomálie. Využíváno je takzvané učící fáze, během které se při sledování sítového provozu určí limity, v rámci kterých je komunikace pokládána za legitimní. Pokročilejší implementace mohou využít sezónnosti síťového provozu, při kterých je vypočítána předpověď a anomálie je posuzována dle odchylky od reálného stavu. K tomuto účelu je právě vhodná metoda Holt-Winters. Pro ověření zda byla detekce úspěšná, otevřeme po každém provedení útoku soubor '/var/log/snort/alert' a podle názvu pravidla vyhledáme záznam. Frekvence záznamů v logovacím souboru by měla odpovídat správnému detekování anomálie. Testování probíhalo po dobu tří minut, logování bylo nastavena na 60 sekund. Předpoklad je tedy, že po správném detekování anomálie budou 3 záznamy v logovacím souboru. 4.1.10.2 Detekování OPTIONS floodingu Zde je ukázka logovacího souboru, při kterém bylo detekováno provedení OPTIONS floodingu, při kterém dochází ke zvýšení počtu příchozích paketů: Obrázek 1.22: Printscreen detekce OPTIONS floodu - 56 -
Praktická realizace detekce anomálií a minimalizace rizik ve VoIP Z obr. 1.22 je patrné, že z IP adresy 192.168.25.36 přišlo větší množství UDP paketů na adresu 192.168.25.57 s portem 5060. Dále pak můžeme vidět informace jako je MAC adresa, ID číslo, TTL atd. 4.1.10.3 Detekování REGISTER floodingu Zde je ukázka logovacího souboru, při kterém bylo detekováno provedení REGISTER floodingu, při kterém dochází ke zvýšení počtu příchozích paketů: Obrázek 1.23: Printscreen detekce REGISTER floodu Na obr. 1.23 je opět patrná zdrojová IP adresa 192.168.25.36, z které bylo odesláno větší množství UDP paketů na adresu 192.168.25.57 s portem 5060. Dále pak lze opět vyčíst informace jako je MAC adresa, ID číslo, TTL atd. 4.1.10.4 Detekování INVITE floodingu Zde je ukázka logovacího souboru, při kterém bylo detekováno provedení INVITE floodingu, při kterém dochází ke zvýšení počtu příchozích paketů: Obrázek 1.24: Printscreen detekce INVITE floodu - 57 -
Praktická realizace detekce anomálií a minimalizace rizik ve VoIP Na obr. 1.24 je také odhalena zdrojová IP adresa 192.168.25.36, z které došlo k zaslání většího množství UDP paketů na adresu 192.168.25.57 s portem 5000. Opět lze také vyčíst informace jako je MAC adresa, ID číslo, TTL atd. 4.1.10.5 Detekování ICMP floodingu Zde je ukázka logovacího souboru, při kterém byl detekováno provedení ICMP floodingu, při kterém dochází ke zvýšení počtu příchozích paketů: Obrázek 1.25: Printscreen detekce ICMP floodu Na obr. 1.25 dochází k odhalení IP adresy 192.168.25.36, z které přichází větší množství ICMP paketů na adresu 192.168.25.57. Opět lze také vyčíst informace jako je MAC adresa, ID číslo, TTL atd. 4.2 Zabezpečení VoIP sítě K procesu zabezpečení lze přistupovat z několik různých hledisek. K dosažení požadované úrovně zabezpečení je vhodné kombinovat technické prostředky spolu se snahou co nejvíce omezit vliv lidského faktoru. U technických prostředků je nutné brát v potaz cenu a efektivitu. Vliv osob přistupujících do sítě lze ovlivnit provedením školení a definovat pravidla bezpečnostní politiky, která řeší práva a kompetence uživatelů. V následující podkapitole jsou popsány bezpečnostní opatření pro každou z vrstev VoIP infrastruktury. - 58 -
Praktická realizace detekce anomálií a minimalizace rizik ve VoIP Obrázek 1.26: Vrstvy VoIP systému [21] Technologie VoIP používá pro svůj chod celou řadu protokolů, subsystémů a služeb, ty lze rozdělit podle logických vrstev, které znázorňuje obr. 1.26. Jednotlivé vrstvy pracují s různými protokoly, na které jsou cíleny pro ně specifické útoky, jenž jsou některé zobrazeny na obr. 1.27. - 59 -
Praktická realizace detekce anomálií a minimalizace rizik ve VoIP Obrázek 1.27: BEZPEČNOSTní rizika jednotlivch vrstev [21] Zde již následuje výčet možností zabezpečení pro VoIP infrastrukturu pro jednotlivé vrstvy: 4.2.1 Řízení přístupu k síťovému médiu na úrovni portů Pro zvýšení bezpečnosti na úrovni portů se nabízí řešení přes standard IEEE 802.1X, definující autentizaci v síti. Architektura tohoto standardu je složena z těchto tří entit: Suplikant představující entitu (softwarový klient nebo IP telefon) přistupující do sítě; Autentizátor má roli zprostředkovatele v procesu autentizace. Komunikuje se suplikanty přes protokol EAPOL. Informace získané od suplikanta předá autentizačnímu serveru, který následně rozhoduje, zda povolí či zamítne přístup; Autentizační server slouží pro ověřování identity suplikanta. S autentizátorem komunikuje přes protokol RADIUS. - 60 -