VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ ÚSTAV TELEKOMUNIKACÍ FACULTY OF ELECTRICAL ENGINEERING AND COMMUNICATION DEPARTMENT OF TELECOMMUNICATIONS
METODY ZAJIŠTĚNÍ IP PBX PROTI ÚTOKŮM SECURING IP PBX AGAINST ATTACKS
DIPLOMOVÁ PRÁCE MASTER'S THESIS
AUTOR PRÁCE
Bc. LUBOŠ HYNEK
AUTHOR
VEDOUCÍ PRÁCE SUPERVISOR
BRNO 2013
Ing. PAVEL ŠILHAVÝ, Ph.D.
VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ Fakulta elektrotechniky a komunikačních technologií Ústav telekomunikací
Diplomová práce magisterský navazující studijní obor Telekomunikační a informační technika Student: Ročník:
Bc. Luboš Hynek 2
ID: 119303 Akademický rok: 2012/2013
NÁZEV TÉMATU:
Metody zajištění IP PBX proti útokům POKYNY PRO VYPRACOVÁNÍ: Nastudujte problematiku útoků a možnosti zajištění bezpečnosti VoIP provozu a Open source PBX. Zaměřte se zejména na Asterisk, FreeSwitch a YATE v posledních a LTS verzích. Vytvořte ucelený nástroj pro experimentální generování různých typů útoků, který lze snadno ovládat a umožní snadné ověření zabezpečení systému. Pomocí vytvořeného nástroje ověřte míru nebezpečnosti různých typů útoků. Proti jednotlivým útokům navrhněte opatření, s pomocí vytvořeného nástroje tato opatření ověřte a vyhodnoťte dle Vámi definovaných kritérií. DOPORUČENÁ LITERATURA: [1] Meggelen, J.V, Smith, J., Madsen, L. Asterisk™ The Future of Telephony. Sevastopol: O'Reilly Media, Inc., 2005. ISBN 0-596-00962-3. [2] Jackson, Benjamin. Asterisk hacking :toolkit and liveCD / Burlington: Syngress, 2007. xii, 253 s. + ISBN 978-1-59749-151-8. [3] Dwivedi, Himanshu. Hacking VoIP :protocols, attacks, and countermeasures / San Francisco : No Starch Press, 2009. xiii, 211 s. : il. ISBN 978-1-59327-163-3. [4] Endler, David. Hacking exposed VoIP :voice over IP security secrets & solutions / New Yrok : McGraw-Hill, 2007. xxvii, 539 s. ISBN 978-0-07-226364-0. Termín zadání:
11.2.2013
Termín odevzdání:
Vedoucí práce: Ing. Pavel Šilhavý, Ph.D. Konzultanti diplomové práce:
prof. Ing. Kamil Vrba, CSc. Předseda oborové rady
29.5.2013
Faculty of Electrical Engineering and Communication Brno University of Technology Purkynova 118, CZ-61200 Brno, Czechia http://www.six.feec.vutbr.cz
Výzkum popsaný v této diplomové práci byl realizován v laboratořích podpořených z projektu SIX; registrační číslo CZ.1.05/2.1.00/03.0072, operační program Výzkum a vývoj pro inovace.
ANOTACE Tato diplomová práce se zaměřuje na možnosti ochrany nejpoužívanějších svobodných softwarových ústředen Asterisk, FreeSWITCH a YATE. V praxi bylo ověřeno chování ústředen při útocích a navrhnuta ochrana proti nim na jedné z nejrozšířenějších serverových distribucí Linuxu, CentOS. Byl vytvořen nástroj pro simulaci několika typů útoků zaměřených na odepření služby. Zvláštní kapitola je věnována porovnání různých metod použité ochrany. Byly použity jak ochranné možnosti samotných ústředen, tak možnosti operačního systému. Porovnány byly také možnosti ochrany jednotlivých ústředen navzájem. Práce také obsahuje stručný popis použitého protokolu, topologii různých útoků a doporučení pro provozování ústředen. Klíčová slova: Asterisk, Freeswitch, YATE, ústředna, softwarová ústředna, zabezpečení, TLS, SRTP, DoS, DDoS, firewall, SIPp, Fail2ban, open source, Linux
ABSTRACT This master project focuses on the possibilities of protecting the most common free software PBX Asterisk, FreeSWITCH and YATE. In practice, it was verified the behavior of PBX in the attacks and suggested protection against them on one of the most popular distributions of Linux server on CentOS. Tool was created to simulate several types of attacks targeting denial of service. Both protective options PBX themselves and operating system capabilities are used in this work. Comparison was also the possibility of protection of individual PBX with each other. It also includes a brief description of the protocol, topology attacks and recommendation for the operation of softswitches. Keywords: Asterisk, Freeswitch, YATE, PBX, softswitch, security, TLS, SRTP, DoS, DdoS, firewall, SIPp, Fail2ban, open source, Linux
HYNEK, L. Metody zajištění IP PBX proti útokům . Brno: Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií, 2013. 68 s. Vedoucí diplomové práce Ing. Pavel Šilhavý, Ph.D..
Prohlášení Prohlašuji, že svoji diplomovou práci na téma Metody zajištění IP PBX proti útokům jsem vypracoval samostatně pod vedením vedoucího diplomové práce a s použitím odborné literatury a dalších informačních zdrojů, které jsou všechny citovány v práci a uvedeny v seznamu literatury na konci práce. Jako autor uvedené diplomové práce dále prohlašuji, že v souvislosti s vytvořením této diplomové práce jsem neporušil autorská práva třetích osob, zejména jsem nezasáhl nedovoleným způsobem do cizích autorských práv osobnostních a/nebo majetkových a jsem si plně vědom následků porušení ustanovení § 11 a následujících zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon), ve znění pozdějších předpisů, včetně možných trestněprávních důsledků vyplývajících z ustanovení části druhé, hlavy VI. díl 4 Trestního zákoníku č. 40/2009 Sb. V Brně dne 29.5.2013
............................................ podpis autora
Poděkování Děkuji vedoucímu práce Ing. Pavlu Šilhavému, Ph.D. za velmi užitečnou metodickou pomoc a cenné rady při zpracování diplomové práce. V Brně dne 29.5.2013
............................................ podpis autora
OBSAH Úvod............................................................................................................................................8 1 Telefonní ústředna na protokolu IP.....................................................................................9 1.1 Asterisk.............................................................................................................................9 1.2 FreeSWITCH..................................................................................................................10 1.3 YATE..............................................................................................................................10 2 Protokol SIP..........................................................................................................................11 3 Útoky na IP ústředny 5. generace.......................................................................................14 3.1 Útoky na poskytování služby..........................................................................................14 3.2 Síťová infrastruktura TCP/IP a možné hrozby................................................................14 3.3 Záplavové útoky pomocí zpráv SIP................................................................................15 3.4 Útok na probíhající multimediální relaci........................................................................15 3.5 Stav zabezpečení u používaných open source PBX........................................................16 3.5.1 Asterisk 11.0.1.........................................................................................................17 3.5.2 FreeSWITCH 1.2.4..................................................................................................17 3.5.3 YATE 4.2.0-2...........................................................................................................18 4 Možnosti zabezpečení Open Source PBX..........................................................................19 4.1 Použité postupy testování................................................................................................19 4.2 Software SIPp.................................................................................................................20 4.3 Testovací skripty.............................................................................................................21 4.3.1 Měření s přístupem na ústřednu...............................................................................23 4.3.2 Měření bez přístupu na ústřednu..............................................................................25 4.4 Fail2ban...........................................................................................................................26 4.5 Použití firewallu pro omezení počtu paketů....................................................................27 5 Praktická realizace ochrany proti útokům........................................................................29 5.1 Skript sipp_check.sh.......................................................................................................29 5.1.1 Asterisk 11.0.1.........................................................................................................29 5.1.2 FreeSWITCH 1.2.4..................................................................................................34 5.1.3 YATE 4.2.0-2...........................................................................................................38 5.2 Ochrana proti DDoS útoku.............................................................................................42 5.3 Srovnání použitých metod zabezpečení..........................................................................44 5.4 Porovnání bezpečných hodnot provozu..........................................................................46 5.5 Doporučení pro provoz ústředen.....................................................................................47 6 Závěr.....................................................................................................................................48 Použitá literatura...................................................................................................................50 Seznam zkratek......................................................................................................................52 Seznam příloh.........................................................................................................................53 A První příloha........................................................................................................................54 B Druhá příloha......................................................................................................................56 C Třetí příloha.........................................................................................................................62 D Čtvrtá příloha......................................................................................................................66 E Pátá příloha..........................................................................................................................67 F Šestá příloha.........................................................................................................................68
ÚVOD S rostoucí nabídkou připojení k internetu a jeho klesající cenou se rozšiřují i služby na něm provozované. Jednou z nich je i VoIP (Voice over IP) telefonie, která po již zaplacené službě připojení k internetu, přináší i možnost telefonních hovorů a videohovorů s malými nebo žádnými dalšími náklady. Jakmile se jakákoliv služba rozšíří, stane se atraktivní pro útočníky. V počátcích VoIP se používalo nešifrovaných spojení, které mohly být jednoduše odposlechnuty. Uživatelé používali jednoduchá hesla, která se dala uhodnout. To stačilo na zajímavé podvodné výdělky v řádech milionů korun. Na tento stav programátoři zareagovali implementací šifrování na transportní vrstvě. Pokud se používají nezpronevěřené a dostatečně silné certifikáty, není dnes možné hovor v reálném čase odposlechnout. Šifrování ovšem musí podporovat jak koncové stanice, tak poskytovatelé služeb, což není vždy pravidlem. Útočníkům tak zbývá samotný útok na poskytování služby, kdy se snaží o její narušení a sociální inženýrství, kdy se snaží podvodně získat přístupové údaje. Dále je možné zneužít chybu v programu, ale to je obvykle rychle opraveno. Tato práce je zaměřena na zabezpečení ústředen proti útokům na poskytovanou službu. Bude v ní vyzkoušeno jak jsou jednotlivé implementace odolné proti těmto útokům a jak je možné je dále zabezpečit, aby byly schopny i při útoku bezproblémově pracovat. Jako nejpoužívanější ústředny budou testovány open source implementace Asterisk, FreeSWITCH a YATE. Nejdříve budou představeny jednotlivé softwarové ústředny a použitý protokol v kapitolách 1 a 2. Ve třetí kapitole budou popsány možné útoky na ústředny a prověřeny možnosti použití zabezpečených protokolů. Vytvořením testovacího nástroje a návrhu ochrany proti útokům se zabývá čtvrtá kapitola. Poslední kapitola se bude věnovat samotným testům navržených ochran na jednotlivých instalacích nejpoužívanějších ústředen a návrhu konkrétních opatření. Nakonec budou výsledky vyhodnoceny, porovnány a bude specifikováno doporučení pro provoz. V přílohách jsou obsaženy výpisy skriptů, konfiguračních souborů, podrobné výsledky a obsah přiloženého CD.
8
1 TELEFONNÍ ÚSTŘEDNA NA PROTOKOLU IP Telefonní ústředny se používají již přes 100 let. Dnes již jde o 5. generaci ústředen, které pracují v síťovém prostředí TCP/IP a samotné spojovací pole představuje software[1]. Existují proprietární ústředny klasických velkých telefonních společností a velmi rychle se rozvíjející ústředny s otevřeným kódem (Asterisk, FreeSWITCH, YATE). Výhodou open source ústředen je rychlý komunitní vývoj a kontrola nad kódem. Je pravidlem rychlá aktualizace nebo reakce na vzniklý bezpečnostní problém. Některé podporuje ve vývoji výrobce hardware, který je v nich používán. Proprietární ústředny zase díky uzavřenosti a neznámé implementaci jsou do jisté míry odolné pomocí mechanismu „security by obscurity“. Na ten se však spolehnout nedá a uživatel je plně v moci výrobce. Používané svobodné ústředny jsou naprogramovány jako jádro s moduly, které rozšiřují její funkčnost. Je možné vytvořit funkční telefonní ústřednu na běžném počítači bez jakýchkoli nákladů. Platí se pouze za licencované moduly, jako jsou různé hlasové kodeky nebo pokročilá signalizace [2]. Tato práce se bude věnovat nejrozšířenějším ústřednám Asterisk, FreeSWITCH a YATE na serverovém operačním systému CentOS 6.3. V širším srovnání mají všechny tyto ústředny stejnou funkčnost.
1.1 Asterisk Nejstarší projekt, který se stal standardem ve světě open source PBX ústředen je nasazen na více než milionu serverů po celém světě [3]. Existuje na něj nejvíce dokumentace, a proto je snadné najít manuál k nastavení pro potřebnou konfiguraci. Hlavním sponzorem je firma Digium, která prodává rozšiřující karty pro různá rozhraní nebo další funkčnost. Dnes již mnoho výrobců dodává hotové ústředny založené na tomto SW [4]. Je vydáván ve dvou typech verzí, standard a Long Term Support (LTS) [5]. Vydané verze znázorňuje Tab. 1.1. V této práci byla použita poslední verze 11.0.1, která je podporovaná až do roku 2017. Tab. 1.1: Přehled verzí a data podpory Asterisku Verze 1.2.X 1.4.X 1.6.0.X 1.6.1.X 1.6.2.X 1.8.X 10.X 11.X 12.X 13.X
Typ vydání Datum vydání 2005-11-21 LTS 2006-12-23 Standard 2008-10-01 Standard 2009-04-27 Standard 2009-12-18 LTS 2010-10-21 Standard 2011-12-15 LTS 2012-10-25 Standard 2013-10 (předběžně) LTS 2014-10 (předběžně)
Jen bezpečnostní záplaty 2007-08-07 2011-04-21 2010-05-01 2010-05-01 2011-04-21 2014-10-21 2012-12-15 2016-10-25 2014-10 (předběžně) 2018-10 (předběžně)
9
Konec podpory 2010-11-21 2012-04-21 2010-10-01 2011-04-27 2012-04-21 2015-10-21 2013-12-15 25. 10. 2017 2015-10 (předběžně) 2019-10 (předběžně)
1.2 FreeSWITCH Jedná se o open source multiplatformní telefonní framework, který je používán pro propojení různých komunikačních protokolů [6]. Byl navržen v roce 2006 bývalými vývojáři Asterisku se zaměřením na modularitu a multiplatformnost. Dnes již je vyvíjen širší komunitou vývojářů. Nativně jsou podporovány tyto platformy: • Windows • Max OS X • Linux • BSD • Solaris Tento projekt, podobně jako Asterisk, podporuje výrobce HW pro telekomunikace Sangoma. Je to spolehlivé řešení, které se nasazuje i do hotových řešení pro koncové zákazníky [6].
1.3 YATE YATE - Yet Another Telephony Engine je samotný engine tvořený pro použití ve VoIP a PSTN sítích se zaměřením na snadnou rozšiřitelnost. Vývoj začal v roce 2004. Všechny datové toky jsou jednotně směrovány pomocí flexibilního směrovacího subsystému a systému zpráv [7]. Pro jednoduché programování rozšíření jsou vyvinuty potřebné knihovny v jazycích PHP, Python a Perl. Jádro ústředny je napsané v jazyce C++ a je možné ji přeložit na mnoho platforem. Zajímavostí je podpora na nenáročných zařízeních na platformě ARM nebo uclibc [8]. Strukturu modulů a komunikace ukazuje Obr. 1.1.
Obr. 1.1: Modulární struktura ústředny YATE [9] 10
2 PROTOKOL SIP SIP (Session Initiation Protocol) je patrně nejrozšířenější protokol používaný pro sestavování spojení v internetové telefonii [10]. Oproti staršímu protokolu H.323, který je binární je SIP textově orientovaný, podobný svou strukturou HTTP (Hypertext Transport Protocol). Protokol používá aplikační vrstvu modelu ISO/OSI (International Organization for Standardization/Open Systems Interconnection) a je specifikován v doporučení RFC 3261 [11]. Samotná multimediální data jsou přenášena pomocí protokolu RTP (Real-time Transport Protocol), popřípadě zabezpečeně pomocí SRTP (Secure Real-time Transport Protocol). Je schopný pracovat jak přes UDP (User Datagram Protocol) a TCP (Transmission Control Protocol), tak i šifrovaně přes TLS (Transport Layer Security). SIP pro vytvoření spojení používá metody, což jsou vlastně jednotlivé příkazy, na které očekává odpovědi. Umožňuje vytvořit, udržet a ukončit samotné spojení. Mezi hlavní metody při navazování hovorů patří následující: • • • • • • • • • • •
REGISTER – registrace klienta na registračním serveru INVITE – navázání nového spojení nebo změna parametrů stávajícího ACK – potvrzení o obdrženém požadavku, používá se „3-way handshaking“ CANCEL – přerušení spojení INVITE ještě před sestavením BYE – ukončení spojení OPTIONS – výměna informací o možnostech jednotlivých stran INFO – přenos signalizačních informací SUBSCRIBE – přihlášení k prezenční službě PRACK – dočasné potvrzení odpovědí 1xx UPDATE – aktualizace stavu relace MESSAGE – přenos zprávy
Chybová hlášení jsou podobná jako u HTTP protokolu. Odpověď je trojciferné číslo, přičemž první číslice udává třídu odpovědi a další dvě jsou upřesnění. • • • • • •
1xx – akce probíhá – 100 – trying, 128 – ringing 2xx - úspěch – akce skončila úspěšně – 200 – OK, 202 - accepted 3xx - přesměrování – 300 – moved, 302 – moved temporarily 4xx - chyba klienta – 401 – unauthorized, 403 – forbidden, 486 – busy here 5xx - chyba serveru – 501 – unimplemented, 503 – service unavailable 6xx - fatální chyba – 601 – busy everywhere, 603 – decline
Celý průběh spojení ukazuje Obr. 2.1, který lze jednoduše získat pomocí programu Wireshark, pokud není použito šifrování pomocí TLS.
11
Obr. 2.1: Průběh spojení zachycený pomocí programu Wireshark Každé zařízení komunikující skrze SIP se nazývá User agent (UA). Podle typu komunikace se dále rozdělují na UA Client (UAC) a UA Server (UAS). UAC začíná spojení a kontaktuje UAS s požadavkem, na který UAS odpovídá. Během komunikace se role několikrát vyměňují. Klíčovým prvkem sítě je SIP server, který obvykle sdružuje několik logických serverů do jednoho. Sloučené servery jsou: • • • •
Proxy – přeposílá a analyzuje zprávy, kterým podle potřeby mění hlavičky Registar – přijímá registrace klientů a aktualizuje Location server Location – adresář klientů, slouží pro vyhledávání Redirect – přijímá žádosti o spojení a směruje do cílové destinace
Pro vytvoření a řízení multimediální relace musí SIP ve spolupráci se zmíněnými servery zajistit následující činnosti [12]: • Lokalizování účastníka – nalezení spojení s koncovou stanicí • Zjištění stavu účastníka – zjištění, jestli je účastník schopen relaci navázat (může mít obsazeno, přesměrováno atd.) • Zjištění možností účastníka – zjištění, jaké jsou možnosti účastníka (typ kodeku audio/video atd.) • Vlastní navázání spojení – zde vstupuje do hry také protokol SDP (Session Description Protocol), který popisuje navázané spojení a odkazuje na RTP datový tok • Řízení probíhajícího spojení – případné změny vlastností v průběhu relace a činnosti spojené s jejím ukončováním SIP protokol používá adresování podobné jako emailová adresa. Skládá se z domény a uživatelského jména, popřípadě telefonního čísla, oddělených znakem @. Toto URI (Uniform Resource Identifier) je možné rozšířit o další volitelné parametry a vypadá následovně [13]: sip:<user>[:<password>]@[:<port>][;][?] sip: [email protected]? subject=project%20x&priority=urgent
12
Takto je možné se přímo spojit s hledaným účastníkem. Každé nepřímé spojení se nejdříve navazuje s proxy serverem. Tento server může vyřídit pouze signalizaci a nechat samotný multimediální provoz v režii obou klientů nebo může proti oběma klientům vystupovat jako protistrana a veškerý provoz směrovat přes sebe. Tento případ se nazývá Back to Back User Agent (B2BUA), viz Obr. 2.2, kdy má ústředna plnou kontrolu nad hovorem. PBX
PBX
B2BUA Framework
Proxy Framework
RTP
RTP
RTP
Obr. 2.2: Rozdíl mezi B2BUA a Proxy serverem Při navrhování protokolu nebyl kladen důraz na zabezpečení, ale na jednoduchou koncepci vycházející z již používaných technologií. Toto přináší i problémy při použití SIP protokolu skrz NAT (Network Address Translation) [14]. Je nutné udržovat spojení s přihlašovacím serverem nebo použít speciální pravidla při překládání adres. Časem vyvstala potřeba použití zabezpečení. Toho bylo dosaženo pomocí SSL (Secure Socket Layer) jak během sestavování hovoru, tak i během samotného hovoru. Toto zabezpečení šifrováním pomocí SSL je dnes již nezbytným předpokladem pro bezpečnou komunikaci. Následuje ukázka výpisu zabezpečeného přihlášení (REGISTER). REGISTER sip:192.168.198.129 SIP/2.0 Přihlášení uživatele Via: SIP/2.0/TLS Použito zabezpečení TLS 192.168.198.1:54728;branch=z9hG4bK80ac5aeb8a32e211bb263a4490ee0a39;rport;alias From: "PhonerLite" <sip:[email protected]>;tag=3602554407 To: "PhonerLite" <sip:[email protected]> .
Příklad zahájení nešifrované komunikace, kdy se číslo 1111 snaží dovolat číslu 1234 pomocí metody INVITE. INVITE sip:[email protected] SIP/2.0 Žádost o spojení Via: SIP/2.0/UDP Použito nešifrované spojení 192.168.198.1:58364;branch=z9hG4bK804dad79e032e21199c11535d58e5ecc;rport From: "PhonerLite" <sip:[email protected]>;tag=365749677 To: <sip:[email protected]>
Další nespornou výhodou použití zabezpečení je nutnost navázání komunikace a nastavení parametrů před samotným útokem. Nelze tak použít podvržené zdrojové IP adresy a útočník může být snadno zablokován. Při nastavování parametrů šifrování dochází k matematickým operacím, které se ve velkém počtu již mohou projevit na obou stranách jako zátěž systému. Je proto vhodné použít hardwarovou akceleraci šifrovacích algoritmů.
13
3 ÚTOKY NA IP ÚSTŘEDNY 5. GENERACE 3.1 Útoky na poskytování služby Mezi nejsnadněji realizovatelné útoky patří záplavové útoky na ústřednu. Pomocí generovaných žádostí lze přetížit linku nebo zahltit systémové zdroje ústředny. Jde o DoS (Denial of Service) útok, kdy útočník útočí z jednoho počítače na jiný. Při přetížení linky, kterou je ústředna připojená do internetu, začne docházet ke zpožďování jednotlivých paketů, v extrémním případě k zahazování, značně kolísá také jitter. Při narůstajícím zpoždění není možné komfortně poskytovat službu a od zpoždění cca 300 ms se stává VoIP hovor nepoužitelný [15] a [16]. Velký datový tok také může pro provozovatele znamenat finanční ztrátu při účtování přenesených dat. Tento útok nemusí být směřován na samotnou ústřednu, ale na jakoukoliv službu či server připojený na stejné lince. Mezi systémové zdroje ústředny, které lze vyčerpat záplavovými útoky, patří paměť a procesor. Při přetížení procesoru dochází k podobným problémům jako při přetížení linky a ústředna není schopna včas reagovat na požadavky a dochází ke zpoždění provozu. Pokud ústředně dojde volná paměť, začne odmítat další hovory nebo se dostane do nedefinovaného stavu. V těchto případech systém program násilně ukončí. Může dojít i k zaplnění mezipaměti a jejímu přetečení. Toho lze v extrémních případech zneužít pro spuštění škodlivého kódu. Záplavové útoky lze pomocí sítě dálkově ovládaných počítačů nebo dobrovolníků rozšířit na DDoS (Distributed Denial of Service), kdy na linku nebo ústřednu útočí koordinovaně celá síť počítačů. Proti DDoS útoku je velmi těžká obrana a řeší se ve spolupráci s poskytovatelem tranzitních spojení, popřípadě geografickým rozdělením poskytované služby [17].
3.2 Síťová infrastruktura TCP/IP a možné hrozby Všechny IP ústředny používají síťovou infrastrukturu TCP/IP. Pro samotné zamezení komunikace ústředny tedy není nutné napadnout ústřednu na aplikační vrstvě, ale stačí útočit na nižší vrstvy síťové infrastruktury. Nejjednodušší jsou záplavové útoky pomocí protokolů ICMP (Internet Control Message Protocol), UDP a TCP [18]. Pomocí protokolu ICMP jsou nejznámější tyto útoky [18]: • • •
Smurf attack – využívá všesměrové adresy, kdy všechny počítače v síti odpovídají na podvrženou adresu oběti a ta má zahlcenou linku, Ping flood – útočník se snaží zahltit linku nebo systémové prostředky oběti, pokud má silnější linku, může být úspěšný, Ping of death – využívá chyby v implementaci fragmentace velkých paketů.
Všechny tyto útoky jsou dlouho známé a na softwarové úrovni proti nim existuje obrana nebo jsou již neúčinné [18]. UDP protokol je využíván hlavně pro DNS amplification, kdy je útok zesílen DNS (Domain Name System) serverem na několikanásobek a odpověď odeslána na podvrženou adresu oběti [19]. Paradoxem je, že použití DNSSEC (Domain Name System Security Extensions) zvětší zesílení útoku, i když dnes se používají častěji dlouhé textové záznamy [20]. Obrana proti tomuto typu útoků není jednoduchá a musí se řešit komplexně na úrovni jednotlivých ISP (Internet service provider) [20]. 14
Pomocí TCP protokolu je nejznámější útok TCP SYN [18], kdy je na server odeslán požadavek TCP SYN s podvrženou zdrojovou adresou a server čeká na odpověď od oběti a udržuje otevřená spojení až do vyčerpání prostředků. Obranou je používání SYN cookies, kdy se neudržují otevřená spojení. Četnost těchto DoS útoků rok od roku stoupá. Největší vzestup za rok 2012 byl zaznamenán u útoku pomocí DNS serverů, DNS amplification [21]. Tyto útoky vedené na infrastrukturu se přímo netýkají softwarových ústředen, ale síťového subsystému serveru, proto nebudou dále rozebírány.
3.3 Záplavové útoky pomocí zpráv SIP Pomocí zpráv zasílaných ústředně lze docílit DoS i DDoS útoku. Mezi možné zprávy ústředně patří například INVITE, REGISTER a OPTIONS. U všech zpráv lze docílit jak vyčerpání přenosové kapacity linky, tak přetížení systémových zdrojů ústředny. Je také možné odposlouchávat řídící protokol, pokud má útočník přístup na přenosovou trasu. Jedná se hlavně o zjištění přístupových informací, tedy adres, přihlašovacích jmen a hesel, které lze zneužít na podvodné telefonáty, viz Obr. 3.1.
Obr. 3.1: Zachycená nešifrovaná signalizace a začátek hovoru Ochrana proti odposlechu spočívá v použití šifrování. Na aplikační vrstvě jde o šifrovaný přenos jmen a hesel pomoci HTTP Digest Authentication nebo S/MIME. Na transportní vrstvě se používá šifrovaný TLS protokol, který je implementován ve všech hlavních softwarových ústřednách, v praxi se však příliš nepoužívá. Velcí čeští poskytovatelé tuto možnost již začínají poskytovat [22] a [23]. Použití TLS protokolu je vidět na Obr. 3.2. Z těchto zachycených dat lze pouze zjistit, že proběhla komunikace a nic jiného. Je také možné šifrovat již na síťové vrstvě pomoci IPSec. Toto řešení je však náročnější na režii, je nutné spojit šifrovaný tunel a veškerá data směrovat se zpožděním přes něj. Pro zjišťování jmen a hesel lze použít i slovníkové útoky na systémové nebo často používané účty.
3.4 Útok na probíhající multimediální relaci Samotné hovory probíhají pomocí RTP a RTCP (RTP Control Protocol). Tento protokol je nešifrovaný a lze jej jednoduše zachytit a reprodukovat, popřípadě pozměnit. Opět je řešením použití šifrování. Konkrétně protokoly SRTP a SRTCP (Secure RTCP) pro hovor, viz Obr. 3.2, pakety 19 a 20. Tuto volbu opět mají implementovány všechny ústředny, ale 15
stejně jako TLS není u velkých českých poskytovatelů využívána. Pro bezpečnou výměnu použitých klíčů je určen protokol ZRTP.
Obr. 3.2: Zachycená šifrovaná komunikace TLS a začátek hovoru SRTP Podporu zabezpečené komunikace mají všechny novější HW telefony a mnoho softwarových implementací. Obr. 3.3 ukazuje zabezpečené připojení k serveru pomocí TLS a zapnutou podporu SRTP. Při tomto nastavení je téměř nemožné pozměnit či odposlechnout hovor. Vše závisí na síle použitých šifer, které jsou dnešními prostředky v reálném čase nerozluštitelné.
Obr. 3.3: Možnosti zabezpečení u SW telefonu PhonerLite
3.5 Stav zabezpečení u používaných open source PBX Jednoznačně nejpoužívanější open source PBX je Asterisk [24], který je používán jak u velkých světových výrobců, tak u malých ústředen i v čistě SW řešeních. Mezi další rozšířené systémy patří FreeSWITCH a YATE. V této práci budou použity tyto nejnovější verze: • • •
Asterisk 11.0.1 LTS FreeSWITCH 1.2.4 YATE 4.2.0-2
16
U všech těchto řešení již je šifrování implementováno a problém odposlechu je tímto považován za vyřešený. DoS, DDoS a slovníkové útoky je možné eliminovat v závislosti na možnostech použitého softwarového vybavení. Obecně lze říci že tvůrci Open Source PBX se snaží o implementaci ochran proti těmto útokům. Buď se snaží aktivně odhalit tyto útoky a nereagovat na ně nebo podezřelé chování reportují a o eliminaci se starají další části systému, nejčastěji různé watchdogy pomocí iptables. V nejnovějších verzích je zlepšování zabezpečení věnováno mnoho prostoru.
3.5.1 Asterisk 11.0.1 Asterisk plně podporuje šifrované hovory. Pro spojení těchto hovorů je nutné použít spolehlivý přenos TCP. Pro signalizaci je použit TLS a pro samotná multimediální data SRTP s protokolem UDP. TLS je možné používat od verze 1.6, SRTP od verze 1.8. Přidání podpory ZRTP pro Asterisk je možné pomocí patche [25]. Pro šifrovanou komunikaci je nutné vygenerovat potřebné certifikáty a ty poté použít v konfiguraci. V distribuci se nacházejí skripty pro snadné vytvoření. Následuje výpis konfigurace, kde jsou znázorněny změny v souboru sip.conf oproti výchozí konfiguraci. tcpenable=yes; Zapnutí podpory TCP spojení tcpbindaddr=0.0.0.0; IP addresa použitá TCP serverem tlsenable=yes; Povolení TLS šifrovaných spojení tlsbindaddr=0.0.0.0; IP addresa použitá TLS serverem ;------------------------ TLS settings --------------------------tlscertfile=/etc/asterisk/keys/asterisk.pem tlscafile=/etc/asterisk/keys/ca.crt tlscipher=ALL tlsclientmethod=sslv3 transport=tls; Nastavení šifrované signalizace [1111] encryption=yes; Použít SRTP
3.5.2 FreeSWITCH 1.2.4 Také FreeSWITCH je schopen šifrovat hovory. TLS i SRTP podporuje již od počátku vývoje a podpora ZRTP byla přidána v květnu 2012, dříve bylo nutné použít patch. Certifikáty, nutné pro zabezpečenou komunikaci, lze jednoduše vytvořit pomocí přiloženého skriptu. Oproti výchozí konfiguraci je potřeba pouze zapnout podporu pro TLS v souboru vars.xml. <X-PRE-PROCESS cmd="set" data="sip_tls_version=sslv23"/> <X-PRE-PROCESS cmd="set" data="internal_auth_calls=true"/> <X-PRE-PROCESS cmd="set" data="internal_sip_port=5060"/> <X-PRE-PROCESS cmd="set" data="internal_tls_port=5061"/> <X-PRE-PROCESS cmd="set" data="internal_ssl_enable=true"/> <X-PRE-PROCESS cmd="set" data="internal_ssl_dir=$${base_dir}/conf/ssl"/>
17
3.5.3 YATE 4.2.0-2 Stejně jako ostatní i YATE je schopen použít šifrování jak pro signalizaci, tak pro samotná multimediální data. TLS je podporováno od verze 4.0.0. Zapnutí šifrování se provádí v souboru ysipchan.conf. [listener name] type=tls addr=x.x.x.x port=5061 sslcontext=server_context
Zapnutí podpory SRTP se provádí v tomtéž souboru. [default] ; secure: bool: Generate and accept RFC 4568 security descriptors for SRTP secure=enable
Certifikáty jsou určeny v souboru openssl.conf. [server_context] enable=yes certificate=name.crt key=name.key
18
4 MOŽNOSTI ZABEZPEČENÍ OPEN SOURCE PBX Ústředny buď obsahují nástroje pro detekci útoků nebo je možné tyto útoky detekovat pomocí sledování datových toků. Pokud ústředny tyto nástroje obsahují, mohou se samy aktivně bránit útokům. Po nastavení mezních hodnot již nemusí přijímat spojení od protistrany vůbec nebo tato spojení resetovat. Další možností je předání zjištěné události nadřízenému systému, který již může provádět nápravná opatření. Ústředny takto sledují útoky vedené přímo na ně pomocí používaných protokolů. Pokud se používá šifrovaná komunikace, není možný útok typu man in the middle nebo jiné odposlechy. V tomto ideálním případě je možný útok typu DoS nebo slovníkový útok. Slovníkový útok na účet se může projevovat jako DoS. Tyto útoky jsou nápadné, protože zatíží linku nebo ústřednu a omezí dostupnost služby. VoIP může být poměrně odolné proti DoS útokům na přenosové pásmo, pokud se používá QoS (Quality of Service) a linka má řádově větší kapacitu než hovor. Pokud jsou pakety hovoru upřednostňovány před ostatním provozem, je možné i na zatížené lince provést hovor [26]. Naproti tomu slovníkový útok může být veden nenápadně a do určitého objemu požadavků za sekundu nemusí být hned zjištěn. V těchto případech je vhodné, aby ústředna uměla detekovat i tyto útoky, například pomocí maximálního počtu chybných přihlášení, a hlásila toto dále do systému. Při sledování maximálního počtu chybných přihlášení je možné poté zablokovat dočasně účet nebo zabránit další komunikaci s útočníkem pomocí systému a firewallu. Další možností je pozdržet odpověď a tím omezit četnost dotazů útočníka na pro něj neúnosnou míru. Na úrovni systému je již možné zamezit komunikaci s útočníkem a povolit pouze legitimní požadavky ostatních uživatelů. Proti DoS útokům pomocí metod, které neumí ústředny adekvátně zaznamenat do logu pro systém nebo samy nastavit systémová pravidla, je nutné použít obecnější nastavení firewallu pro síťový provoz.
4.1 Použité postupy testování U všech instalací byl použit software Fail2ban, který je možno nainstalovat z repozitáře Fedora EPEL (Extra Packages for Enterprise Linux). Tento software přímo nastavuje pravidla ve firewallu iptables a blokuje přístup z IP adres podle logů ústředen. Vzhledem k použité šifrované komunikaci není možné sledování a vyhodnocování provozu pomocí pomocných programů. Veškeré možnosti ochrany pomocí Fail2ban vycházejí ze schopnosti ústředny náležitě hlásit různé útoky a nestandardní chování, popřípadě na ně reagovat samostatně. Toto logování je funkční u všech ústředen pro nejdůležitější metody REGISTER a INVITE, kdy se útočník může pokoušet o uhodnutí hesla. Tyto metody lze pohodlně zaznamenat a pomocí firewallu adekvátně zareagovat. U dalších použitých typů záplavových útoků se ústředny chovaly různě. Proti útokům metodou ACK jsou ústředny víceméně imunní a nepředstavují velkou zátěž pro systém. Metoda BYE dokáže ústředny vytížit na desítky procent. Metoda OPTIONS dokáže vytížit ústřednu násobně více než BYE. Jako další stupeň ochrany bylo použito omezení počtu příchozích paketů ze stejné IP adresy. Pomocí pravidla, které sleduje tento počet je poté nastaven firewall, který propustí do systému nastavený počet spojení za jednotku času.
19
Testování proběhlo ve virtualizovaném prostředí VMware, kdy bylo systému s ústřednou přiděleno 1 jádro Intel Core 2 Quad 9100 z hostitelského systému a 2 GB RAM. Útoky probíhaly z jiného virtuálního stroje se stejným nastavením.
4.2 Software SIPp Pro všechny testy byl využit volně šiřitelný software určený pro testování ústředen pracujících s protokolem SIP, SIPp ve verzi 3.3. Program je možné velmi detailně nastavit pro testování konkrétního sledovaného parametru. Také umožňuje používat uživatelské scénáře, které jsou použity i v této práci. Pomocí tohoto programu je možné detailně testovat například typ odpovědi od serveru i zpoždění komunikace při jednotlivých dotazech. Všechny výstupy je možné zapisovat do souboru i sledovat interaktivně na obrazovce. Program se distribuuje ve zdrojových kódech, je tedy nutné ho před použitím zkompilovat. Kompilaci je možné provést na většině UNIX/linuxových platformách i ve Windows XP a výše. Pro možnost testů šifrované komunikace je nutné z repozitářů distribuce nainstalovat OpenSSL knihovny a zapnout podporu při kompilaci. tar -xvzf sipp-xxx.tar.gz cd sipp autoreconf -ivf ./configure --with-openssl make
Po úspěšné kompilaci je již možné používat vytvořený spustitelný soubor sipp. Pro potřeby práce byly vytvořeny scénáře, které se používají pro jednotlivé testy. Každá jednotlivá testovaná metoda, tedy ACK, BYE, INVITE, OPTIONS a REGISTER je zastoupena jedním scénářem. Všechny scénáře jsou přiloženy v třetí příloze. Pro zápis scénáře používá SIPp jednotlivé soubory ve formátu XML (Extensible Markup Language). V souboru jsou uvozené jednotlivé proměnné či nastavení v XML formátu. Všechny soubory musí začínat verzí, použitým kódováním a jménem scénáře. Pro účely práce bylo použito měření délky hovoru rozdělené do skupin podle milisekund. <scenario name="ACK">
Následně je v souboru zapsán samotný obsah SIP komunikace, který se bude posílat na ústřednu. Retrans je použit v případě komunikace přes nespolehlivý UDP protokol, podle RFC3261. <send retrans="500"> ;tag=[call_number] To: ack_flood_test <sip:ack_flood_test@[remote_ip]: [remote_port]>[peer_tag_param] Call-ID: [call_id] CSeq: 1 ACK Contact: sip:sipp@[local_ip]:[local_port] Max-Forwards: 70 Subject: Performance Test ]]>
20
U některých scénářů jsou specifikovány očekávané odpovědi od ústředny, aby nedocházelo k chybovým hlášením během testů.
Pro samotné testy byly použity tyto přepínače programu SIPp: -sf -t
nastaven vlastní scénář komunikace, použitý transportní protokol, s přídavkem 1 – pro všechny hovory použít stejný socket, -l maximální počet simultánních hovorů, bylo použito množství hovorů za sekundu krát 30 sekund (doba útoku), -p použít definovaný port -r frekvence hovorů za sekundu, nastaveno ve skriptu, -trace_stat ukládat detailní statistiku do souboru, -recv_timeout maximální doba k příjmu odpovědi od serveru v milisekundách, -send_timeout maximální doba k odeslání žádosti k serveru v milisekundách, -timeout čas, po kterém se sipp ukončí v sekundách, -timeout_error sipp se ukončí i v případě nedokončené transakce, -i použitá IP adresa pro komunikaci Výsledný příkaz použitý ve skriptu, se zmíněnými přepínači, cílovou adresou ústředny a přesměrováním hlášení do /dev/null. sipp -sf scenarios/$scenario.xml -p 65002 -t "${TRANSPORTS[$i]}"n -l $CALLS -r $freq -trace_stat -recv_timeout 10000 -send_timeout 10000 -timeout 30s -timeout_error -i $LOCAL_IP $TARGET_IP:"${PORTS[$i]}" > /dev/null 2>&1
4.3 Testovací skripty Byly vytvořeny skripty pro měření zátěže. Jsou napsány pro prostředí příkazové řádky BASH (Bourne Again SHell). S využitím zmíněných nástrojů byl napsán hlavní skript určený na zátěžové testování ústředen a dva pomocné skripty. Jeden pro měření zatížení serveru a jeden pro vyhodnocení získaných výsledků. Hlavní skript umožňuje testování ve dvou režimech s modifikací: •
•
testování vzdálené ústředny s přístupem ◦ s telefonátem ◦ bez telefonátu testování vzdálené ústředny bez přístupu ◦ s telefonátem ◦ bez telefonátu
Pro výběr režimu spuštění byly použity parametry spouštěného skriptu. První parametr je IP adresa nebo DNS jméno ústředny, druhý nepovinný parametr označuje zda použít nebo nepoužít testovací hovory, třetí parametr jest číslo pro hovory. Formát je následující: sipp_check.sh IP|address [[Y|N] [number]]
21
Pokud nejsou použity nepovinné parametry, spouští se skript jako bez přístupu k ústředně. Na začátku skriptu sipp_check.sh lze dále nastavit hlavní parametry, proměnné, cestu k programu SIPp a umístění log souborů. Nastavitelné parametry jsou: SCENARIO=(ack bye)
Seznam metod, které budou použity k testům, soubory s příponou xml musí mít stejný název, FREQ_CALLS=(500 1000) četnosti jednotlivých testů, SCENARIOS_PATH="scenarios" adresář se použitými metodami, LOCAL_IP=`ifconfig|grep inet|head -1|sed 's/\:/ /'|awk '{print $3}'` lokální IP adresa, TARGET_IP="$1" cílová IP adresa ústředny, LOG="./sipp_test.log" soubor se záznamem testu, TEMP_LOG="/tmp/sipp_test_temp_log" dočasný soubor se záznamem, SIPP_PATH="." cesta k spustitelnému souboru SIPp. Dále následuje nastavení limitů operačního systému podle doporučení od vývojářů FreeSWITCHe pomocí utility ulimit [27]. Pokud je použit režim s přístupem na ústřednu, je nutné synchronizovat čas na počítači a na testované ústředně. K tomu slouží v obou skriptech systémový program rdate, který synchronizuje místní hodiny s veřejně přístupným NTP serverem sítě CESNET. Četnosti jednotlivých útoků jsou v tomto případě dále nastaveny pevně. Skript poté vytvoří jednotlivé soubory s výsledky a vyplní záhlaví. Následně otestuje na ústředně známé porty 5060 a 5061 a zjistí kde a na jakém protokolu poskytuje ústředna službu. Jestliže neodpovídá, skript vypíše hlášení a ukončí se. Tyto výsledky jsou dále použity v hlavní smyčce. Následuje samotné testování ústředny pro jednotlivé nastavené četnosti použité scénáře a protokoly. Po každém testu je uložen log soubor s patřičným názvem a výsledky jsou prozkoumány podle více kritérií. První kritériem hodnocení jsou jednotlivá zpoždění odpovědí. Jsou odstupňována následovně: <10 ms, <50 ms, < 100 ms, <500 ms, <1000 ms, < 5000 ms, <10000 ms, ≥10000 ms. Jako vyhovující zpoždění je vyhodnoceno <100 ms. Větší zpoždění je podle velikosti odstupňovaně hlášeno na obrazovce a v log souboru. Dalším kriteriem je úspěšnost transakcí. Podle něho a zpoždění je vyhodnocena možná ochrana ústředny nebo blížící se vyčerpání systémových prostředků. Vyhodnocení je založeno na chování ústředen při jistých situacích. Pokud se vyskytují transakce se zpožděním větším než 1000, 5000 nebo 10000 ms, je pravděpodobné, že ústředna se blíží k vyčerpání systémových prostředků a zpoždění se již může projevovat pro legitimní účastníky. Zároveň ovšem pokud se vyskytují pouze zpoždění větší než 10000 ms, a tedy vyprší časový limit, je pravděpodobné že ústředna používá nějakou formu ochrany a neodpovídá na všechny transakce. Stejně tak, pokud se tyto zpoždění nevyskytují, ale nedokončených transakcí je více než je četnost, opět má pravděpodobně ústředna nějakou formu ochrany. Další skript siptop.sh je určen na zaznamenávání stavu počítače s ústřednou. K tomu využívá výpis systémového programu top, z kterého v sekundových intervalech vybírá informace o čase a stavu systému. Dále zaznamenává, kolik paměti a procesorového času zabírá proces ústředny. Pro přesnou synchronizaci, opět pomocí NTP serveru, nastavuje přesný čas.
22
Poslední skript sipp_log.sh kombinuje výstupy obou předchozích. Nejdříve z jednoho logu vyseparuje začátky a počty testů spolu s jejich popisem a následně je spáruje s daty zatížení podle časového razítka a vygeneruje výsledný záznam, který uloží. Tento a předchozí skript jsou nutné pouze při testování s přístupem na ústřednu. Pokud k ústředně přístup není, lze použít pouze první skript pro odhad zatížitelnosti.
4.3.1 Měření s přístupem na ústřednu Pokud je umožněn k ústředně přístup a je možné spouštět soubory, lze použít měření zátěže samotné ústředny spolu s generováním útoků. Pro tento případ jsou určeny skripty siptop.sh, sipp_check.sh a sipp_log.sh. První byl spouštěn na systému s ústřednou, druhý skript, na samotné zátěžové testovaní virtuálního počítače s ústřednou, byl spouštěn z jiného počítače. Útoky a měření zátěže jsou časově synchronizovány a pomocí posledního skriptu sloučeny logy z obou předchozích do výsledného souboru. Nejdříve byl na počítači s ústřednou spuštěn skript siptop.sh, který jako parametr obsahuje název spuštěného souboru samotné ústředny a kontinuálně zaznamenává zátěž v sekundových intervalech. Po ukončení testování se přeruší běh tohoto skriptu pomocí Ctrl + c a výsledný soubor siptop.log je přenesen na testovací počítač, kde je vyhodnocen skriptem sipp_log.sh. Použité skripty jsou uvedeny v druhé příloze. Pro samotné útoky byl zvolen scénář, kdy se v čase HH: MM: 00 spustí útok, který trvá 30 s, po skončení následuje 30 s pauza na vyprázdnění vyrovnávacích pamětí a odeznění výkyvů systémů, následně opět v čase HH: MM: 00 se spouští další útok. Skript sipp_test.sh se spouští s parametrem adresy ústředny a dalšími volitelnými. Po otestování portů, vyzkouší všechny předdefinované metody, tedy ACK, BYE, INVITE, OPTIONS a REGISTER a v cyklech bude zvyšovat jejich četnost. Pokud je detekována možnost nešifrované komunikace skript na tuto skutečnost varovně upozorní, vypíše verzi a typ použitého software a spustí testy. [root@localhost sipp.svn]# ./sipp_check.sh 192.168.198.144 Unsecured UDP transport on port 5060 FOUND. Eavesdropping is possible. Server: YATE/4.2.0 Unsecured TCP transport on port 5060 NOT FOUND. Secured tls transport on port 5061 FOUND. Secure call enabled. Server: YATE/4.2.0 Please wait, testing in progress, this may take a while. Testing scenario ack for 500 attempts/s, transport UDP.
Pokud je ústředna nakonfigurovaná pro použití šifrování, probíhá vše podobně s vizuálním zvýrazněním doporučené konfigurace. [root@localhost sipp.svn]# ./sipp_check.sh 192.168.198.144 Unsecured UDP transport on port 5060 NOT FOUND. Unsecured TCP transport on port 5060 NOT FOUND. Secured tls transport on port 5061 FOUND. Secure call enabled. Server: YATE/4.2.0 Please wait, testing in progress, this may take a while. Testing scenario ack for 500 attempts/s, transport tls.
Ve skriptu lze nastavit jak jednotlivé četnosti útoků, tak jednotlivé předdefinované scénáře. Je možné i vytvořit scénář vlastní. Výstupem skriptu je soubor delay.csv, ve kterém 23
jsou detailní výsledky počtu úspěšných a neúspěšných pokusů a časy odezev. Další vytvořené soubory obsahují podrobné statistické informace jednotlivých útoků. Tyto soubory je možné využít pro detailní zkoumání chování jednotlivých ústředen. Při analýze a slučování obou hlavních výsledných souborů se vypisuje na obrazovce zatížení procesoru během testu a je zvýrazněno vysoké zatížení, které může mít vliv na nové a probíhající hovory. Vysoké zatížení je vyhodnoceno jako více než 80% po dobu více než 5 s. Již z této analýzy lze určit problémové místa na která je potřeba se zaměřit. [root@localhost sipp.svn]# ./sipp_log.sh Average Average Average Average Average Average Average Average Average Average
CPU: CPU: CPU: CPU: CPU: CPU: CPU: CPU: CPU: CPU:
10%, flood: 500 ack/s on tls 84%, flood: 500 bye/s on tls, 36 sec. of 50 is greather than 80% 4%, flood: 500 invite/s on tls 74%, flood: 500 options/s on tls, 31 sec. of 50 is greather than 80% 3%, flood: 500 register/s on tls 12%, flood: 800 ack/s on tls 92%, flood: 800 bye/s on tls, 42 sec. of 50 is greather than 80% 5%, flood: 800 invite/s on tls 86%, flood: 800 options/s on tls, 40 sec. of 50 is greather than 80% 4%, flood: 800 register/s on tls
Výsledný soubor CPU.csv lze použít pro vytvoření přehledného grafu v tabulkovém procesoru, podobně jako v této práci. Do grafů je vynesen časový úsek testu – 5 s před útokem až +15 s po útoku u každé použité metody. Během útoků mohou být prováděny testovací telefonáty. Tyto se nastavují jako druhý a třetí parametr skriptu. V každé ústředně byla nakonfigurována čísla s automatickou odpovědí. Skript spustí na pozadí další instanci programu sipp, který dle zadaného scénáře naváže spojení na zvolené číslo, simuluje hovor a zavěsí, viz Obr. 4.1. Toto spojení je navázáno každou sekundu během 30 sekund testu, celkem je tedy navázáno 30 spojení a na závěr každého testu je vypočtena a zobrazena úspěšnost. 33 % successfull testing calls !!!ERROR!!!, PBX cannot answer to all testing calls!!!
Obr. 4.1: Průběh navázání testovacího hovoru Dle scénáře je navázán hovor pomocí metody INVITE, dále je očekávána odpověď 200 OK. Po potvrzení skript čeká 3 sekundy, během níž naslouchá RTP provozu z ústředny a vrací ho zpět. Po uplynutí této doby korektně ukončí hovor. Během jednoho testu tedy proběhne 30 hovorů s celkovou délkou 33 sekundy. Pokud ústředna nezpracuje všechny hovory, je na tuto skutečnost upozorněno. Následuje vytvořené schéma komunikace a výsledný příkaz použitý ve skriptu.
Časová souslednost testů byla následující: 1. 2. 3. 4. 5.
Spuštění skriptu siptop.sh na počítači s běžící ústřednou. Spuštění skriptu sipp_test.sh na jiném počítači. Po ukončení skriptu sipp_test.sh, ukončení siptop.sh pomocí Ctrl + c. Přenesení souboru siptop.log z počítače s ústřednou na testovací počítač. Spuštění skriptu sipp_log.sh, který vygeneruje výsledný soubor CPU.csv.
4.3.2 Měření bez přístupu na ústřednu Jestliže není umožněn přístup k ústředně je možné skript spustit v režimu vzdáleného testování, kdy je na základě zpoždění a úspěšnosti odpovědí odhadnuta zatížitelnost ústředny. Tato metoda je zatížena chybou přenosové trasy, kdy se může zpoždění na přenosové trase projevit jako přetížení ústředny. Chybu lze částečně eliminovat výběrem vhodné přenosové trasy nebo statistickými metodami s vícenásobnými testy. Po spuštění, stejně jako v předchozím případě, je oskenována ústředna a po zjištění aktivních portů, jsou započaty testy. Četnost útoků začíná na 100 za sekundu a pokud test proběhne v pořádku je četnost zvýšena o 100 a test se zopakuje. Maximum ve skriptu je nastaveno na 2000. Po proběhnutí každého testu je vypsáno rozložení zpoždění a úspěšnosti testované metody. Pokud jsou zadány informace o testovacím čísle, provedou se i zkušební hovory a vypíše se úspěšnost. Příklad výpisu, kdy vše proběhlo bez problémů následuje. Rate/s <10ms <50ms <100ms <500ms <1s <5s <10s 1195.62 28534 7466 0 0 0 0 0 100 % successfull testing calls OK, the PBX is able to serve 1200 options per sec.
>=10s 0
Succ. 36000
Failed 0
Při zpracování skript upozorní na zpoždění, které se již může projevit na fungování ústředny. Upozornění na zpoždění je odstupňováno takto: • • • •
0 – 100 ms bez upozornění 101 – 500 ms, NOTIFICATION 501 – 1000 ms, ALERT více než 1 s, WARNING
Zároveň jakmile zpoždění překročí 1 s, je tato situace vyhodnocena jako přetížení ústředny. Ukončí se testování aktuální metodou a pokračuje se další metodou. Zároveň je oznámena maximální použitelná zátěž ústředny.
25
Rate/s <10ms <50ms <100ms <500ms <1s <5s <10s >=10s Succ. Failed 1566.99 2539 575 0 28483 16100 0 0 303 47697 303 100 % successfull testing calls NOTIFICATION, 28483 of 48000 answer(s) is delayed more than 100ms. ALERT, 16100 of 48000 answer(s) is delayed more than 500ms. WARNING, 303 of 48000 answer(s) is delayed more than 10s (timeout)!!! WARNING, The PBX is going to overload, maximum (1600) attempts per sec. reached!
Pokud je ústředna zabezpečena proti záplavovým útokům neukončí se testy úspěšně. Zabezpečení se projeví na počtu chybných pokusů o spojení. V těchto případech ústředna odpoví na několik prvních pokusů a zbytek je neúspěšný. Skript na tuto skutečnost upozorní a přejde na testování další metodou. Rate/s <10ms <50ms <100ms <500ms <1s <5s <10s >=10s Succ. 66.6385 1 0 0 0 0 0 0 2999 1 100 % successfull testing calls WARNING, 2999 of 3000 answer(s) is delayed more than 10s (timeout)!!! The PBX is probably protected, flood attack isn´t effective.
Failed 2999
Po proběhnutí všech testů skript na obrazovku vypíše souhrnnou informaci o odhadnuté zatížitelnosti ústředny a zároveň zapíše údaje do log souboru. PBX maximum rates: ack-tls-protected bye-tls-1300/sec. invite-tls-protected options-tls-1600/sec. register-tls-200/sec.
4.4 Fail2ban Pro nastavení pravidel firewallu je v této práci použit tento daemon, který na pozadí kontroluje nastavené log soubory a podle zaznamenaných zpráv nastavuje pravidla komunikace. Samotný program je napsaný v skriptovacím jazyce Python, spouští se při startu počítače a je aktivní po celou dobu. Podle nastavených pravidel omezuje přístup útočníkům pomocí například iptables, buď na jednotlivé porty nebo k celému serveru. Samotná konfigurace pro jednotlivý log soubor se provádí ve 2 souborech. V souboru /etc/fail2ban/jail.conf je nastaveno chování kontrolního mechanismu. V následujícím příkladě je nastaven velmi konzervativní filtr, který umožňuje 50 chybových hlášení za 60 sekund z jedné IP adresy, pro testovací provoz. V běžném provozu je možné počet chybových hlášení snížit na 10 a čas zakázaného přístupu na stovky až tisíce sekund. [asterisk-iptables] enabled filter action logpath findtime maxretry bantime
= = = = = = =
true asterisk #jméno konfiguračního souboru iptables-allports[name=ASTERISK, protocol=all] #použité pravidlo /var/log/asterisk/messages 60 #prohledávaný časový úsek v sekundách 50 #maximální počet záznamů 60 #čas v sekundách po který je zakázán přístup
Druhý soubor, definovaný v předchozí konfiguraci, se nachází v adresáři /etc/fail2ban/filter.d a obsahuje podmínky detekce. Při nastavování podmínek se používá regulárních výrazů a pomocných proměnných, podle kterých se prohledává stanovený log 26
soubor. V následujícím příkladě se prohledává výskyt definovaného textu v log souboru asterisku a výstupem je IP adresa v proměnné , na kterou se nastavují pravidla. failregex = NOTICE.* .*: Call from '.*' \(:.*\) .* .* '.*' rejected because extension not found in context '.*'.
Pravidla reakce jsou určena konfiguračními soubory v adresáři /etc/fail2ban/action.d a v předchozím příkladě je použito odmítnutí komunikace z dané IP adresy na všechny porty.
4.5 Použití firewallu pro omezení počtu paketů Protože možné nastavení záznamů ústředen není vhodné pro kontrolování a reakci v reálném čase na všechny typy útoků, je nutné omezit vstupní datový tok pomocí nastavení firewallu. Vzhledem k tomu, že se SIP signalizace používá pouze při sestavování spojení nebo při změnách parametrů, tak při běžném provozu dosahuje frekvence SIP zpráv z unikátní IP adresy maximálně desítek za minutu. Naproti tomu útok se vyznačuje frekvencí i tisíckrát vyšší. Díky tomuto nepoměru lze s vysokou pravděpodobností určit, že od jisté úrovně SIP zpráv za časovou jednotku se jedná o útok. Úroveň se liší podle způsobu připojení klientů. Například při použití techniky DNAT (Destination network translation) může téměř libovolný počet klientů komunikovat pod jednou IP adresou hraničního směrovače. Při běžné komunikaci ovšem klienti komunikují s ústřednou z většiny rozsahu IPv4 (Internet Protocol version 4) adres. Pokud není pro komunikaci použit šifrovaný přenos pomocí TLS, je možné pomocí firewallu kontrolovat příchozí pakety na výskyt klíčových slov SIP komunikace. Ideální jsou názvy jednotlivých metod, které jsou jedinečné a přítomné téměř v každém paketu. Pak již stačí jen omezit množství paketů za čas, tak aby nebyl dotčen běžný provoz, ale bylo možné omezit různé útoky. Například pro registraci účastníka s heslem jsou potřebné 2 pakety metodou REGISTER. Je tedy možné omezit tuto metodu na 10 paketů za minutu i s rezervou na chyby na trase nebo chybné heslo. Při použití šifrované komunikace je možné pouze sledovat počet paketů za časovou jednotku, které směřují z jedné IP adresy na příslušný port ústředny. V tomto případě je kvůli vyměňování klíčů a sestavení šifrované komunikace na začátku spojení potřeba více paketů. Aby se útoky projevily na celkové zátěži ústředny, musí se pohybovat v tisícinásobcích běžného provozu. Pro prvotní přihlášení uživatele k ústředně je potřeba přenést 10 paketů směrem k ústředně. V následujících testech bylo ověřeno, že všechny testované ústředny se vyrovnají s provozem až 1000 dotazů za sekundu. Jako bezpečná rezerva bylo stanoveno, že dostačující je desetinásobek skutečné potřeby, tedy 100 paketů za minutu. Žádost o navázání nebo ukončení hovoru potřebuje méně paketů než přihlášení. Po překročení limitu, budou následující pakety zahazovány a samotný útočník bude nucen čekat na chybějící pakety, udržovat otevřená spojení a tím zatěžovat vlastní systém. Tímto zahazováním paketů bude postižena pouze IP adresa útočníka. Pro vytvoření těchto pravidel bylo použito iptables s funkcí hashlimit. Tato funkce umožňuje omezit počet paketů z jedné IP adresy za časovou jednotku. Pro správnou funkci filtru si nejprve odkloníme komunikaci směřující na zadaný port pomocí příkazu iptables -A INPUT -i eth0 -m tcp -p tcp --dport 5061 -j sipdos
27
Poté jsou všechny pakety směřující na port 5061 vnitřně přesměrovány do řetězce (chain) sipdos, kde se již uplatní další pravidla. Pro dříve zmíněné počty paketů zadáme následující omezení. iptables -A sipdos -m hashlimit --hashlimit 100/minute --hashlimit-burst 30 --hashlimit-mode srcip,dstport --hashlimit-name sip_o_limit -j ACCEPT
Pomocí tohoto zápisu uplatníme na veškerý provoz směrovaný do řetězce (chain) sipdos omezení na 100 spojení za minutu, maximální shluk 30 paketů. Pakety, které překročí zadané limity jsou dále zaznamenány pro další zpracování a následně zahozeny. iptables -A sipdos -j LOG iptables -A sipdos -j DROP
Celý spustitelný skript s nastavením je přiložen ve čtvrté příloze. Na zaznamenané pakety je uplatněn filtr programu Fail2ban, který zakáže komunikaci z útočníkovy IP adresy na delší časový úsek, viz první příloha. Takto zabezpečená ústředna je schopna reagovat na útok do několika sekund, útočníka zablokovat ve firewallu a ostatním uživatelům i nadále poskytovat službu.
28
5 PRAKTICKÁ REALIZACE OCHRANY PROTI ÚTOKŮM V praktické části byly vytvořeny skripty pro simulaci útoků, navrženy ochrany proti nim a zhodnocena jejich účinnost. Z výsledků následně byla vyvozena doporučení pro provoz ústředen.
5.1 Skript sipp_check.sh U každé ústředny proběhl nejdříve test s přístupem k ústředně a využitím testovacího hovoru na registrované číslo 1000. Byly testovány všechny dostupné metody, tedy ACK, BYE, INVITE, OPTIONS a REGISTER. Četnosti byly zvoleny 500, 800, 1000, 1200 a 1500. Při nižších četnostech nebyly ústředny téměř zatěžovány a při vyšších četnostech naopak již byly přetížené, i program sipp se choval neočekávatelně a docházelo k přetečení paměti a násilnému ukončení programu. Po ukončení testu s přístupem následoval test bez přístupu také s testovacími hovory, kdy se skript snažil na základě výsledků odhadnout zatížitelnost. Oba tyto testy byly opakovány se zabezpečením pomocí Fail2ban a poté i se zabezpečením pomocí omezení počtu paketů. V dalším textu a obrazové dokumentaci budou ústředny srovnávány při četnostech 1000 pokusů za sekundu, kdy již mají pokusy výrazný vliv na chod ústředny, ale ještě nedochází k přetěžování a zkreslování výsledků.
5.1.1 Asterisk 11.0.1 Nejdříve proběhly testy s přístupem k ústředně a bylo měřeno zatížení procesoru ústředny a spotřeba paměti. Asterisk je poměrně odolný vůči záplavovým útokům. Je schopen zpracovat tisíce požadavků za sekundu a po odeznění se plně zotavit. Při větších útocích, hlavně metodou INVITE, spotřebovává velké množství paměti v řádu GiB, viz Obr. 5.1. Při záplavě INVITE Asterisk odpoví na prvních 499 pokusů 404, potom odpovídá 403 a do logu se zapisuje chyba Cannot create socket. Souvisí to s povoleným množstvím otevřených souborů, což je maximální množství simultánně probíhajících hovorů. Při větším množství souborů ovšem ústředna rychle vyčerpá paměťové prostředky. Z Obr. 5.2 je patrné, že největší zátěž systému představují zprávy INVITE, kdy lze při datovém toku v řádu stovek kB/s zatížit procesor až na 100 %. Také metody OPTIONS a REGISTER jsou schopny při dostatečné četnosti způsobit vyčerpání zdrojů ústředny. Útoky typu ACK a BYE jsou naproti tomu poměrně neškodné i ve velkém množství.
29
Obr. 5.1: Systémové prostředky při záplavě INVITE, 1000 zpráv/s po dobu 30 s Jakékoliv útoky jsou ovšem nepřijatelné a je třeba proti nim ústřednu zabezpečit. Kvůli šifrované komunikaci jsou využity logovací schopnosti samotné ústředny. Standardní logovací schopnosti Asterisku zaznamenávají neúspěšné metody INVITE a REGISTER. Toto je dostačující pro slovníkové útoky na zjištění hesla. Pro zbývající typy je nutné zapnout debug log v souboru /etc/asterisk/logger.conf. debug => debug
A také v příkazové řádce ústředny nastavit úroveň: *CLI> core set debug 5
Poté již ústředna loguje všechny použité útoky a lze na ně reagovat pomocí Fail2ban. Při tomto nastavení ovšem do logu proudí značné množství dat a skenovací systém Fail2ban je schopen při vyhodnocování pravidel zatížit procesor na desítky procent, obzvláště se to projevuje při metodě OPTIONS. Testovací telefonáty proběhly úspěšně při všech útocích kromě útoku metodou INVITE. Pokud není použito zabezpečení, ústředna při útocích metodou INVITE není schopna reagovat na požadavky spojení a klientům odpovídá chybovým kódem 403: Forbidden. Tuto reakci lze považovat za úspěch útočníka a DoS útok je tedy možný. Útok metodou REGISTER a OPTIONS znamená pro klienty nepatrné zpoždění při požadavcích do 1 s. Toto je způsobeno vyčerpáním volné paměti a použitím swap souboru, který značně zpomalí zpracování požadavků. Zvětšením paměti se tato prodleva eliminuje a sytém odpovídá okamžitě.
30
Vytížení CPU [%]
100 90 80 70 60 50 40 30 20 10 0
500/s 800/s 1000/s 1200/s 1500/s bye ack
options invite
register
Obr. 5.2: Zátěž procesoru různými zprávami o různé četnosti bez zabezpečení
Vytížení CPU [%]
Pro nastavení Fail2ban slouží konfigurační soubory, do kterých se zapisují očekávané události v logu, na které má reagovat. Použitá pravidla jsou uvedena v první příloze. Na Obr. 5.3 jsou vidět reakce na zprávy INVITE a REGISTER, které jsou standardně logovány a útočníkovi je po detekci odepřena komunikace pomocí iptables. Pro běžné klienty se již ústředna chová jako při běžném provozu. Nadále je při útocích metodou OPTIONS spotřebováno velké množství paměti. Testovací telefonáty z útočícího počítače byly neúspěšné u metod INVITE a REGISTER kvůli nastavení firewallu programem Fail2ban. Z jiného počítače proběhly vždy v pořádku. Nejzranitelnější metoda INVITE je již ošetřena pomocí firewallu a legitimní volání nejsou útokem dotčena.
100 90 80 70 60 50 40 30 20 10 0
500/s 800/s 1000/s 1200/s 1500/s bye ack
options invite
register
Obr. 5.3: Zátěž procesoru různými zprávami o různé četnosti při použití Fail2ban Obr. 5.4 ukazuje stejný případ jako předchozí s využitím detekce debug zpráv. Zprávy OPTIONS přinášejí velký datový tok do logovacího souboru debug zpráv a systém při větší četnosti reagoval se značným zpožděním na útok. Při 800 zprávách za sekundu systém zareagoval po 15 s a při 1000 a více zprávách za sekundu až po více než 30 s, takže se na grafu zásah neprojeví. Toto chování bylo způsobeno velkou zátěží procesoru, kdy samotná 31
Vytížení CPU [%]
ústředna spotřebovala asi 60 % času a kontrolní mechanismus systému Fail2ban zbývajících 40 % času. Testovací telefonát z jiného než útočícího počítače proběhl vždy v pořádku, pouze u útoku metodou OPTIONS nastávalo zpoždění sestavení hovoru do 1 s. Ve všech případech byla ústředna schopna po odeznění útoků pokračovat v normálním provozu, jen alokace paměti se zvětšila z ~400 MB na 1,8 GiB.
100 90 80 70 60 50 40 30 20 10 0
500/s 800/s 1000/s 1200/s 1500/s
bye ack
options invite
register
Obr. 5.4: Zátěž procesoru různými zprávami o různé četnosti při použití Fail2ban debug Použití omezení počtu paketů spolehlivě odfiltruje škodlivé útoky a ústředna již není nadměrně zatěžována, což se projeví na její spotřebě systémových prostředků, viz Obr. 5.5. Zatížení procesoru i využitá paměť se pohybují v mezích nezatíženého systému. Pouze na síťovém provozu je vidět komunikace, která je ovšem omezena použitým nastavením a v běžném provozu ústředny je zanedbatelná.
Obr. 5.5: Systémové prostředky při záplavě REGISTER, 1000 zpráv/s po dobu 30 s 32
Na Obr. 5.6 jsou znázorněny pouze ojedinělé špičky při spotřebě procesorového času, které ve většině případů nepřesahují 15 %. Na začátku testu firewall propustí ve shluku 30 paketů. Při zobrazované četnosti 1000 SIP zpráv za sekundu, což znamená několikanásobek zaslaných paketů kvůli navazování spojení a výměně šifrovacích klíčů nelze kvůli zpoždění na lince úspěšně dokončit ani jednu celou SIP transakci v tomto počtu paketů. Ani v testovacím prostředí, kde jsou kvůli virtualizaci na jednom počítači odezvy rychlejší ji nebylo možno dokončit. Transakce je tak dokončena až po sérii opakovaných požadavků. Paradoxně tak nastává situace, kdy s menší četností je více útoků dokončeno v časech do 1 sekundy. Při vyšších četnostech byly jednotlivé útoky úspěšné až po několika sekundách. Ve všech těchto případech se však úspěšné transakce pohybují v desítkách za testovací dobu 30s. Protože ústředny jsou schopné úspěšně obsloužit i 1000 transakcí za sekundu, tak tento počet pro ně není významný.
100 90 80 Vytížení CPU [%]
70
500/s 800/s 1000/s 1200/s 1500/s
60 50 40 30 20 10 0
bye ack
options invite
register
Obr. 5.6: Zátěž procesoru různými zprávami o různé četnosti s omezením provozu Asterisk se snaží obsloužit co nejvíce transakcí v co nejkratším čase. Různé metody potřebují různé množství času na obsluhu. Distribuci časového zpoždění ukazuje Obr. 5.7. Nezabezpečená ústředna obslouží všechny požadavky a zpoždění odpovídá náročnosti. Zabezpečení pomocí Fail2ban se projeví na metodách INVITE a REGISTER, které lze reportovat do logu. U ochrany pomocí sipdos je již dokončen pouze zlomek ze zamýšlených transakcí. Jako další typ testu proběhl test bez přístupu k ústředně. Po testu byly zaznamenány tyto maximální bezpečné hodnoty četnosti útoků: • • • • •
Obr. 5.7: Počet transakcí pro různé typy útoků s četností 1000/s a rozložení jejich zpoždění Během testu byly prováděny testovací hovory jak skriptem, tak manuálně. Všechny hovory proběhly v pořádku, pouze v případě metody INVITE docházelo ke ztrátám a úspěšnost byla pod 10 %. Ústředna nebyla žádným způsobem zabezpečena. Bezpečné hodnoty jsou vzhledem k předchozím naměřeným hodnotám zatížení procesoru poměrně malé, zvláště u metod INVITE a OPTIONS. To je dáno konzervativním nastavením mezí, kdy zpoždění méně než 1 procenta pokusů znamená ukončení testu. I když v těchto případech nejsou zdroje ústředny výrazně zatíženy, pro oprávněné uživatele již tato zpoždění znamenají zmenšený komfort užívání.
5.1.2 FreeSWITCH 1.2.4 Během většiny testování s přístupem k ústředně nevykazovala ústředna zvýšenou potřebu paměťových prostředků. Pouze v případě metody REGISTER ústředna implicitně odpovídá pomaleji se zřejmě pevným počtem odpovědí za sekundu. To zapříčinilo během testu pád testovacího programu na přetečení paměti, jak je patrné z Obr. 5.9, kdy došlo v polovině testu k pádu programu a skokovému snížení zátěže. Při testu bez zabezpečení TLS se testovací program neukončil a ústředna vyčerpala všechnu paměť a byla ukončena násilně systémem. FreeSWITCH při tomto testu dokázal alokovat přes 4 GB paměti a odpověď na požadavky byla 500 Internal Server Error, viz Obr. 5.8. Více než polovina testovacích transakcí nebyla dokončena. Za 30 sekund testu jich nebylo ve většině případů dokončeno více než 6000, což při maximální testované zátěži představuje účinnost 13 %. Při záplavovém útoku metodou ACK ústředna odpoví na prvních několik paketů a následně resetuje spojení a neodpovídá. U metody INVITE odpoví pouze na první pokus a dále již neodpovídá. Testovací telefonáty proběhly opět úspěšně při všech útocích kromě útoku metodou REGISTER. Pokud není použito zabezpečení, ústředna při útocích metodou REGISTER není 34
schopna reagovat na požadavky spojení a klientům odpovídá s úspěšností mezi 10 a 50 %. Opět je tedy DoS útok možný. Po odeznění útoku byla ústředna schopna i nadále poskytovat služby jako před útokem.
Vytížení CPU [%]
Obr. 5.8: Systémové prostředky při záplavě REGISTER, 1000 zpráv/s po dobu 30 s
100 90 80 70 60 50 40 30 20 10 0
500/s 800/s 1000/s 1200/s 1500/s
bye ack
options invite
register
Obr. 5.9: Zátěž procesoru různými zprávami o různé četnosti bez zabezpečení FreeSWITCH nezapisuje detailní komunikaci do log souboru ve formátu použitelném pro Fail2ban, proto není možné reagovat na všechny útoky, ale pouze na útoky metodami REGISTER a INVITE při použití standardního stupně zápisu do log souboru. Obr. 5.10 ukazuje značné zlepšení při metodě REGISTER, ostatní hodnoty jsou podobné.
35
Vytížení CPU [%]
Testovací hovory nejsou úspěšné, protože Fail2ban pomocí firewallu zakáže komunikaci s útočícím počítačem. Hovory z jiné IP adresy už probíhají normálně. Pokud tedy útočník nebude provádět útoky s větší četností než 1500 za sekundu, nebude funkce ústředny dotčena a legitimní uživatelé ji mohou používat. I nadále však při útocích dochází k nadměrnému zatěžování zdrojů ústředny i přenosové linky.
100 90 80 70 60 50 40 30 20 10 0
500/s 800/s 1000/s 1200/s 1500/s
bye ack
options invite
register
Obr. 5.10: Zátěž procesoru různými zprávami o různé četnosti při použití Fail2ban Obr. 5.11 ukazuje vliv omezení počtu příchozích paketů. Není zde vidět žádná spotřeba systémových prostředků, pouze opět malý datový tok síťového rozhraní. Na Obr. 5.12 je vidět, že jádro ústředny je napsáno velice úsporně a během celého testu nepřesáhlo zatížení procesoru 10 % ani při maximální zátěži. Při tomto typu ochrany je při překročení limitů chování ústředen podobné a i u Freeswitche bylo velmi obtížné dokončit transakci, podobně jako u Asterisku. Testovací telefonáty z jiného než útočícího počítače proběhly všechny úspěšně a pro uživatele se takto zabezpečená ústředna jeví pod útokem stejně jako bez něj. Na Obr. 5.13 je patrné, že jádro je napsáno efektivně, protože zpoždění odpovědi nepřesáhne 500 ms v žádném případě. U metody INVITE ústředna zpracuje pouze první požadavek a dále už neodpovídá. Na další požadavek by bylo potřeba otevřít nové spojení. Fail2ban opět blokuje útočníka při metodách INVITE a REGISTER, které zaznamenávají IP adresu do log souboru. Sipdos omezí komunikaci takovým způsobem, že úspěšně je dokončeno jen několik málo transakcí. Nástroj sipp bohužel značné chyby v komunikaci vyhodnotí chybně, a i když hlásí drtivou většinu transakcí jako neúspěšnou, přesto ve výsledku některé transakce vystupují jako úspěšné. Toto chování se projevuje pouze u ochrany omezením počtu paketů, kdy dochází k masivní chybovosti a opakování jednotlivých paketů. Například u metody ACK bylo vyhodnoceno 29999 chybných transakcí, přesto ve výsledku jsou zahrnuty jako transakce úspěšně ukončené v čase < 10 ms.
36
Obr. 5.11: Systémové prostředky při záplavě REGISTER, 1000 zpráv/s po dobu 30 s
100 90 80 Vytížení CPU [%]
70 500/s 800/s 1000/s 1200/s 1500/s
60 50 40 30 20 10 0
bye ack
options invite
register
Obr. 5.12: Zátěž procesoru různými zprávami o různé četnosti s omezením provozu Při testech bez přístupu k ústředně byly zaznamenány tyto maximální bezpečné četnosti útoků. Ústředna nebyla nijak zabezpečena. • • •
Obr. 5.13: Počet transakcí pro různé typy útoků s četností 1000/s a rozložení jejich zpoždění FreeSWITCH je v základní instalaci schopen odolat některým záplavovým útokům. U metody ACK a INVITE dovolí v rámci jednoho spojení jeden pokus a na další nereaguje a tak šetří systémové prostředky. Metoda REGISTER je zřejmě vnitřně ošetřena na omezený počet pokusů za čas. Metody, které nejsou omezovány, dosahují vysokých četností s nízkým zpožděním, což dokazuje vysokou úroveň naprogramování. Obzvláště metoda OPTIONS dokáže beze ztrát využít téměř všechny systémové prostředky. Všechny testovací hovory proběhly v pořádku, úspěšnost byla ve všech testech 100%.
5.1.3 YATE 4.2.0-2 V nové verzi 4.2 přibyla funkce SIP flood protection, kdy je možné v konfiguračním souboru nastavit, při kolika zprávách se začne uplatňovat zahazování zpráv. Tato funkce je aktivní pro metody INVITE, REGISTER, SUBSCRIBE a OPTIONS. V logu taková zpráva vypadá následovně: <sip:WARN> Flood detected, dropping INVITE/REGISTER/SUBSCRIBE/OPTIONS messages, allowing reINVITES
Během testů s přístupem k ústředně se neprojevilo jakékoliv zahazování zpráv na zátěži procesoru a systém se ke zdrojům choval jako bez ochrany, viz Obr. 5.14. Naopak na rozdíl od ostatních ústředen, YATE při útoku nespotřebovává žádnou další volnou paměť. Přestože ústředna hlásí záplavový útok, nelze na něj reagovat pomocí Fail2ban, protože ústředna nereportuje IP adresu útočníka. Při zapnutí detailního logování existuje možnost sledování, 38
ovšem stejně jako v případě Asterisku je objem logovaných dat vysoký. V tomto případě ovšem dojde k přetížení procesoru při jakémkoliv útoku. Souvisí to se zátěží, kterou generuje samotný YATE spolu s Fail2ban. Testovací telefonáty z jiného počítače proběhly během útoků bezchybně. Systém reagoval bez zpoždění a zatížení procesoru nepoznamenalo odezvy ústředny na SIP požadavky. Telefonáty z útočícího počítače byly úspěšné pouze u metod ACK a BYE. V ostatních případech byla kvůli funkci SIP flood protection úspěšnost kolem 60 %. Podobné procento úspěšnosti bylo ze stejného důvodu zaznamenáno i u celkového počtu úspěšných transakcí u těchto metod. Po odeznění útoku byla ústředna schopna i nadále poskytovat služby jako před útokem.
Obr. 5.14: Systémové prostředky při záplavě REGISTER, 1000 zpráv/s po dobu 30 s Základní instalace YATE obsahuje skript banbrutes.php, který má podobnou funkci jako Fail2ban a pomocí pravidel v iptables blokuje útočníka na určitý čas. Skript je nutné povolit při spuštění v souboru extmodule.conf. Zatímco Fail2ban reaguje na útok s určitým zpožděním, které může být v řádu sekund, při velké zátěži i desítky sekund, viz Obr. 5.3, Obr. 5.4, Obr. 5.10, banbrutes.php reaguje okamžitě, viz Obr. 5.16. Na Obr. 5.15 je patrné, že ústředna bez zabezpečení je schopna spotřebovat veškerý procesorový čas i při menší zátěži. Jedině zprávy ACK jí nečiní problémy. Obr. 5.16 ukazuje schopnost skriptu banbruttes.php okamžitě zareagovat na útok a zakázat další komunikaci na metody INVITE a REGISTER. Ostatní metody bohužel nezohledňuje.
39
Vytížení CPU [%]
100 90 80 70 60 50 40 30 20 10 0
500/s 800/s 1000/s 1200/s 1500/s bye ack
options invite
register
Obr. 5.15: Zátěž procesoru různými zprávami o různé četnosti bez zabezpečení
Vytížení CPU [%]
Testovací telefonáty proběhly z útočícího počítače úspěšně při útoku metodami ACK a BYE. Při metodě OPTIONS byla jejich úspěšnost i úspěšnost transakcí podobná jako u nezabezpečené ústředny, tedy kolem 60 %. Skript banbrutes.php zcela znemožnil testovací telefonáty při obou zbývajících metodách, INVITE a REGISTER. Z jiného počítače byly všechny testovací telefonáty úspěšné. Samotná ústředna se je schopna úspěšně bránit útokům na nedostupnost služby, nadále však zatěžuje procesor u některých metod, viz Obr. 5.16.
100 90 80 70 60 50 40 30 20 10 0
500/s 800/s 1000/s 1200/s 1500/s bye ack
options invite
register
Obr. 5.16: Zátěž procesoru různými zprávami o různé četnosti při použití banbrutes.php I v tomto případě, při omezení počtu paketů, ústředna nespotřebovává žádné systémové prostředky navíc, útok se projeví pouze malou špičkou počtu paketů na začátku a poté již firewall propouští omezené množství komunikace, viz Obr. 5.17. Obr. 5.18 ukazuje, že ústředna nezatíží procesor na více než 20 % po celou dobu testu. Vykazuje pouze kontinuálně nepatrně vyšší zátěž než ostatní testované. Všechny testovací telefonáty proběhly úspěšně.
40
Obr. 5.17: Systémové prostředky při záplavě REGISTER, 1000 zpráv/s po dobu 30 s
100 90 80 Vytížení CPU [%]
70
500/s 800/s 1000/s 1200/s 1500/s
60 50 40 30 20 10 0
bye ack
options invite
register
Obr. 5.18: Zátěž procesoru různými zprávami o různé četnosti s omezením provozu Z grafu na Obr. 5.19 je zřejmé, že ústředna používá SIP flood protection a i bez zabezpečení nejsou počty transakcí velké. Výjimkou je metoda ACK, která sice není ošetřena, ale také neklade na systémové prostředky zvýšené nároky. Při zabezpečení pomocí banbrutes.php, jsou spolehlivě potlačeny útoky metodami INVITE i REGISTER, které lze reportovat do log souboru. Při zabezpečení sipdos již není možné ústřednu zatížit.
Obr. 5.19: Počet transakcí pro různé typy útoků s četností 1000/s a rozložení jejich zpoždění V testu bez přístupu k ústředně byly maximální bezpečné četnosti poznamenány funkcí SIP flood protection: • • • • •
ACK BYE INVITE OPTIONS REGISTER
2000 300 300 400 400
Z výsledku je patrné, že ochrana ústředny je účinná a nedovolí útočníkovi efektivní DoS útok, protože pro ostatní účastníky je ústředna běžně dostupná, ale pro útočníka již dochází ke zpožděním a nedokončeným transakcím, které mohou mít vliv na útočící systém. I nadále ovšem dochází ke zvýšené zátěži procesoru, takže další ochrana s omezením počtu paketů je vhodný doplněk. Pouze jeden testovací hovor z 340 byl neúspěšný a to v případě, kdy již skript vyhodnotil zátěž jako mezní a testy ukončil.
5.2 Ochrana proti DDoS útoku Kombinace nastavení omezení počtu spojení a schopnost ústředen zpracovat velké množství požadavků poskytuje poměrně účinnou ochranu proti DDoS útokům. Podle testů je metoda OPTIONS metodou, která velmi zatěžuje systém ústředen a zároveň na útok touto metodou nelze jednoduše reagovat prostřednictvím záznamů ústředen. Představuje tak nejhorší možný scénář útoku. Při použití šifrované komunikace je potřeba na přenos jedné SIP zprávy,12 paketů směrem od útočníka, viz Obr. 5.20. 42
Obr. 5.20: Zabezpečené navázáni a ukončení komunikace s metodou OPTIONS Při nastavení omezení na 100 příchozích paketů za minutu lze tedy úspěšně útočit s četností 8,33 SIP zpráv za minutu z jedné IP adresy, což pro ústředny nepředstavuje zátěž nad rámec běžného provozu. Jestliže útočník přesáhne tuto četnost ústředna začne pakety zahazovat a bude obtížné dokončit korektně komunikaci následkem čehož se četnost opět sníží. Pokud ústředna obslouží 1000 zpráv za sekundu bez zpožďování komunikace, může takto odolat útoku až z 1000/(8,33/60) = 7200 IP adres. Tab. 5.1 znázorňuje závislost množství obsloužitelných IP adres při omezení počtu paketů z každé z nich. Při překročení počtu povolených paketů dochází k jejich opakovanému přenosu a počet úspěšně doručených SIP zpráv rychle klesne na 0. Pro orientaci je uváděn i počet SIP zpráv za minutu a sekundu. Tab. 5.1: Závislost množství obsloužených IP adres na povoleném počtu paketů Paketů/min. 50 100 150 200 250
SIP zpráv/min. 4,167 8,333 12,500 16,667 20,833
SIP zpráv/s 0,069 0,139 0,208 0,278 0,347
IP adres 14400 7200 4800 3600 2880
Pokud se útoky provádějí s vyšší četností, než je nastaveno ve firewallu, iptables zahazuje pakety a provádí zápis do souboru. Na tento soubor reaguje Fail2ban a pro dotyčné IP adresy zakáže komunikaci po nastavenou dobu. Pro útočníka je tedy velmi těžké vést útok s dostatečnou intenzitou, protože sama ústředna je schopna při správném nastavení obsloužit až desetitisíce IP adres a jakmile četnost paketů přesáhne stanovenou mez je daná IP adresa zablokována. Při této konfiguraci může dojít dříve k zahlcení samotného připojení než k vyčerpání prostředků ústředny. Například z předchozího grafu na Obr. 5.1 vyplývá datový tok při útoku na úrovní 200 kiB za sekundu. V modelovém případě při útoku ze 7200 IP adres již datový tok představuje 1,37 GiB za sekundu. Tento případ se řeší ve spolupráci s poskytovatelem tranzitních spojení například odpojování celých rozsahů IP adres, dočasným zvýšením 43
kapacity spojení, popřípadě geografickým rozdělením poskytované služby. Je možné také používat geograficky oddělené SIP proxy servery, které propustí pouze validní komunikaci na samotnou ústřednu.
5.3 Srovnání použitých metod zabezpečení Všechny srovnávané ústředny byly podrobeny stejným testům. Pokud nejsou nijak zabezpečené, tak se Asterisk a FreeSWITCH chovají velmi podobně a určitým typem útoku lze dosáhnout stavu odmítnutí služby i pro ostatní uživatele. YATE při větší zátěži okamžitě spotřebuje procesorový čas, viz Obr. 5.21, ale je stále schopna poskytovat službu. Odolává tak útokům pomocí jednotlivých metod a pro legitimní uživatele je vždy dostupná. Dále se YATE umí sama pomocí integrovaného rozšíření aktivně bránit proti útokům metodami INVITE a REGISTER. Prakticky stejné možnosti pro další zabezpečení pomocí log souborů a programu Fail2ban poskytuje Asterisk, těsně následovaný PBX FreeSWITCH. Mají i podobné možnosti nastavení, i když Asterisk lze nastavit podrobněji. Obě lze jednoduše nastavit pro metody INVITE a REGISTER, Asterisk lze nastavit i pro ostatní metody, ovšem za cenu velkých datových toků a tím pádem velkého zatížení procesoru, než zasáhne Fail2ban a nastaví firewall. FreeSWITCH v jednom spojení odpovídá pouze na jeden požadavek INVITE a na ostatní nereaguje, což je také určitý druh ochrany, protože zátěž procesoru je výrazně nižší než u ostatních, viz Obr. 5.21. Proti slovníkovým útokům, či jiným na zjištění hesla, tímto poskytují ústředny dostatek prostředků na zamezení komunikace s útočníkem. Proti záplavovým útokům pomocí jiných metod již se možnosti různí a nejsou tak účinné. Na Obr. 5.21 a Obr. 5.22 jsou srovnány nároky jednotlivých ústředen na procesor při různých stavech.
100 90 80 Vytížení CPU [%]
70 60 50 40 30 20 10 0
bye ack
options invite
Asterisk 1000/s
Freeswitch 1000/s
Obr. 5.21: Srovnání zátěže nezabezpečených ústředen
44
register YATE 1000/s
100 90 80 Vytížení CPU [%]
70 60 50 40 30 20 10 0
bye ack
options invite
Asterisk 1000/s
register
Freeswitch 1000/s
YATE 1000/s
Obr. 5.22: Srovnání zátěže zabezpečených ústředen pomocí Fail2ban nebo banbrutes.sh Na Obr. 5.23 je zřejmé, že pomocí omezení počtu spojení je možné eliminovat útoky až na úroveň, která se neprojevuje na zatížení ústředen. Všechny ústředny při veškerých útocích nealokovaly prostředky hostitelského systému nad rámec běžného provozu a byly schopny poskytovat služby legitimním uživatelům. Pomocí striktního nastavení firewallu proti DoS útokům lze do značné míry eliminovat útoky DDoS, které míří na vyčerpání zdrojů ústředny.
120
Vytížení CPU [%]
100 80 60 40 20 0
bye ack
options invite
Asterisk 1000/s
Freeswitch 1000/s
register YATE 1000/s
Obr. 5.23: Srovnání zátěže zabezpečených ústředen pomocí omezení počtu spojení
45
Detailní srovnání všech metod a zabezpečení při četnosti 1000 útoků za sekundu je přiložené v páté příloze. Z něho vyplývá, že spolehlivé zabezpečení pomocí omezení počtu paketů má za následek velký počet nedokončených transakcí, které mohou mít vliv i na útočící systém (sloupec hang). Dále je zaznamenáno velké množství neúspěšných transakcí (sloupec failed). Neúspěšné transakce jsou u YATE ve všech testech následkem funkce SIP flood protection, podobně jako u FrreSWITCHE a jeho chování u metod INVITE a REGISTER. U Asterisku se žádné takové chování neprojevovalo a ústředna se vždy snažila odpovědět na všechny žádosti. Bylo také ověřeno, že integrovaná ochrana banbrutes.sh, použitá u YATE reaguje rychleji než řešení s Fail2ban. YATE má při této četnosti reakční dobu kolem 100 ms, Fail2ban dokáže zareagovat v rozmezí 0,5 – 2 s (sloupec successful u metod INVITE a REGISTER). Pokud je použito zabezpečení pomocí omezení počtu paketů spolu s Fail2ban na nahlášené IP adresy, útočník je schopen dokončit pouze méně než 1 % útoků, viz pátá příloha. Systém v tomto případě reaguje v jednotkách sekund a zablokuje přístup. 2013-05-27 20:55:02,323 fail2ban.actions: WARNING [sipdos-iptables] Ban 192.168.198.151 2013-05-27 20:56:02,464 fail2ban.actions: WARNING [sipdos-iptables] Unban 192.168.198.151
Tab. 5.2 ukazuje úspěšnost či neúspěšnost testovacích telefonátů během útoků. Pokud neproběhl je zaznamenáno, u které metody byl neúspěšný. Telefonáty proběhly automaticky nebo při omezení komunikace firewallem, manuálně z jiného počítače během každé metody na výzvu skriptu. Tab. 5.2: Úspěšnost testovacích hovorů při útocích 1000 zpráv za sekundu Asterisk FreeSwitch YATE
Bez zabezpečení ne (INVITE) ne (OPTIONS) ano
Fail2ban ano ne (OPTIONS) ano
Omezení počtu spojení ano ano ano
5.4 Porovnání bezpečných hodnot provozu Bezpečné hodnoty jsou predikovány na základě dosažených hodnot zpoždění při útocích na nezabezpečené ústředny. Pokud jsou ústředny některým z předchozích způsobů zabezpečeny, nelze tyto hodnoty použít, protože oba způsoby ukončí komunikaci s útočníkem již při útoku 100 transakcí za sekundu, i když je jich ústředna schopna obsloužit tisíce. V Tab. 5.3 jsou porovnány dosažené hodnoty. Tab. 5.3: Odhadnuté bezpečné hodnoty provozu metoda ACK BYE INVITE OPTIONS REGISTER
U ústředny FreeSWITCH je detekováno použití zabezpečení. V případě metody ACK ústředna resetuje spojení a u INVITE neodpovídá na další pokusy. Bezpečné hodnoty u ústředny YATE jsou poznamenány funkcí SIP flood protection, kdy ústředna nedovolí větší počty bez omezení komunikace. Pouze metoda ACK není ústřednou omezována. Pouze Asterisk nemá žádné vnitřní omezení a poskytuje službu dokud nejsou vyčerpány systémové prostředky. Nízké odhadnuté hodnoty jsou výsledkem striktního nastavení, kdy není dovoleno zpoždění o více než 1 sekundu žádné transakci.
5.5 Doporučení pro provoz ústředen Ze všech získaných poznatků a všeobecně známých zásad, které je nutné dodržovat pro zachování soukromí a pro ochranu citlivých informací, které se často vyměňují při telefonických rozhovorech, vyplývají tato doporučení pro provozování softwarové telefonní ústředny: • • • • • • • •
používat pouze šifrované spojení jak pro signalizaci (TLS), tak pro data (SRTP), na lince mít nastavené QoS, které prioritizuje datové toky z a do ústředny, omezit firewallem všechny přístupy z internetu a povolit pouze potřebné služby, zahazovat pakety s nepřiměřenou četností, pomocí firewallu aktivně odpojovat podvodné účastníky na základě hlášení z ústředny, vyhradit virtuální server pouze pro ústřednu, pravidelně aktualizovat používaný software, kvůli bezpečnostním aktualizacím, zamezit fyzicky přístupu k ústředně neautorizovaným osobám.
Klient, který má využívat takto navržené ústředny, musí mít pouze implementovánu podporu šifrování signalizace a datových toků, viz Obr. 5.24. Pokud navíc umožňuje používat certifikáty, je možné při navazování spojení ověřovat obě strany vůči důvěryhodné certifikační autoritě.
Obr. 5.24: Ikony zabezpečené komunikace programu PhonerLite 47
6 ZÁVĚR IP ústředny jsou díky konvergenci přenosových sítí stále populárnější a získávají podíl na trhu na úkor ústředen starších generací. Tyto ústředny existují jak od velkých zavedených výrobců ústředen, tak i v open source implementacích. Zavedení výrobci nabízí komplexní řešení i s implementovanými ochranami ovšem za vysoké pořizovací náklady s další placenou údržbou po dobu životnosti. Na druhé straně open source ústředny jsou zcela zdarma nebo za nízké licenční poplatky patentovaných částí, například použitých kodeků. Cena je mnohdy určující pro výběr systému a ani větší obtížnost implementace není překážkou. Poskytované služby jsou pro obě možnosti velmi podobné. Tím, že ústředny využívají pro svůj provoz internet, jsou daleko dostupnější pro útoky, než ústředny starší na dedikovaných sítích. Doba, kdy nebylo nutné řešit zabezpečenou komunikaci již uplynula a dnes je nutné nepodceňovat nebezpečí odposlechu důvěrných dat nebo nedostupnosti poskytované služby. Zabezpečit komunikaci proti odposlechu je možné s platnými standardy a dnešní implementace open source ústředen tyto standardy plně podporují. Pro signalizaci je bezpečné používat šifrovaný protokol TLS a pro multimediální data šifrovaný SRTP protokol. Útoky, které lze použít na takto zabezpečené i nezabezpečené ústředny jsou popsány v kapitole 3.1 a dalších navazujících kapitolách. Nadále se předpokládá použití výhradně šifrované komunikace, která velkou část útoků znemožňuje. V kapitole 3.5 jsou porovnány možnosti zabezpečení tří nejznámějších open source ústředen, konkrétně Asterisk 11.0.1, FreeSWITCH 1.2.4 a YATE 4.2.0-2. U všech lze jednoduchým způsobem nastavit používání pouze zabezpečené komunikace. Zabezpečení hovorů pomocí TLS a SRTP přináší nečekané překážky v ochraně samotných ústředen. Kvůli zabezpečené komunikaci není možné aktivně kontrolovat datové toky, chování jednotlivých uživatelů a především útočníků pomocí programů třetích stran. Použitá ochrana proto musí spoléhat na možnosti ústředen. Navržená ochrana proto kombinuje reakce na hlášení ústředen a omezení datových toků pomocí firewallu. Všechny ústředny shodně reportují pouze útoky metodami INVITE a REGISTER. Tyto metody pokrývají nejčastější slovníkové útoky na zjištění hesel. Na hlášení z ústředen reaguje daemon Fail2ban a nastavuje pravidla blokování provozu hlášeným útočníkům. Vytvořené skripty pro testování jsou popsány v kapitole 4.3. Umožňují dva druhy měření ústředen buď s využitím dat o jejich zatížení nebo na dálku s predikcí. Výsledné soubory z měření lze jednoduše zpracovávat v tabulkovém kalkulátoru. V kapitole 5.1 byly provedeny záplavové testy pomocí různých metod SIP protokolu a vyhodnoceny výsledky ústředen bez ochrany i s navrženou ochranou. Asterisk bez ochrany je schopen odolat útokům přes 1000 transakcí za sekundu ovšem za cenu zvýšené zátěže procesoru a extrémních nároků na alokaci paměti u metody INVITE. Při útoku touto metodou jsou také postižení legitimní uživatelé a nelze sestavit hovor. Po aplikaci Fail2ban, který spolupracuje se záznamy ústředny, byly ošetřeny metody INVITE a REGISTER, ale OPTIONS stále zatěžovala procesor. Hovory již byly bezproblémové. Další použité metody jsou odkázány na detailní debug log, který je ovšem ústředna schopna plnit v objemu gigabajtů za hodinu a při jeho kontrole vytížit procesor spolu s ústřednou na maximum, což je kontraproduktivní. Po aplikaci omezení datových toků kleslo zatížení na úroveň jako bez provozu a navenek se ústředna chovala jako za běžných provozních podmínek.
48
FreeSWITCH se k systémovým zdrojům chová podobně jako Asterisk, má podobné využití procesoru, ale vystačí si s minimem paměti mezi 100 a 200 MB. Výjimkou jsou útoky metodou REGISTER, kdy roste spotřeba paměti velmi rychle. Zároveň však lze těmto útokům efektivně zabránit pomocí Fail2ban. Ústředna sama používá určitý způsob omezení počtu transakcí. Uplatňuje se u metod ACK, INVITE a REGISTER, kdy nebylo nikdy dosaženo plného počtu úspěšných transakcí. Při útocích metodou OPTIONS nebylo možné sestavit hovor ani při zabezpečení pomocí Fail2ban. Až po omezení datových toků se ústředna chovala, podobně jako Asterisk, jako za běžných provozních podmínek. YATE vychází ze srovnání nejhůře, co se týká zatížení procesoru. Kromě metody ACK ústředna vytíží procesor na maximum při polovičních hodnotách útoku než ostatní. Na druhou stranu se je schopna sama bránit útokům pomocí metod INVITE a REGISTER blokováním provozu od útočníka podobně jako daemon Fail2ban. Dále umožňuje monitorovat zatížení CPU a podle toho přizpůsobit své chování [28]. Zřejmě díky tomu proběhly vždy všechny hovory. Jako u ostatních ústředen po nastavení firewallu na omezení datových toků YATE pracovala bez problémů. Podrobné srovnání i s grafy popisuje kapitola 5.3. Pomocí kombinované ochrany omezení počtu paketů z jedné IP adresy a reakce na záznamy ústředny pomocí Fail2ban je již možné efektivně zabránit zneužití ústředny. Samotné omezení datových toků je velmi jednoduché na implementaci ve firewallu. Je pouze nutné zvážit míru omezení aby nebyli omezováni legitimní uživatelé. Jiné počty paketů budou nastaveny na ústředně s 20 uživateli a jiné na ústředně s tisícovkami uživatelů. Omezení toků pouze ztíží útočníkovi přístup k ústředně. Pro úplné zakázání přístupu je nutné použít Fail2ban s nastaveným časem zablokování. Na základě naměřených údajů bylo vytvořeno obecné doporučení pro implementaci těchto ústředen.
49
POUŽITÁ LITERATURA [1]
SVOBODA, Jaroslav, et al. Telekomunikační technika, Díl 2.. Praha : Hüthig&Beneš, 1999. Přenos dat, spojovací a přenosové systémy, s. 142. ISBN 80-901936-4-1.
[2]
Asterisk Software Add Ons: G729 Codec. IP Phone Systems, UC and Asterisk solutions - Phone Systems Powered by Asterisk [online]. 2013 [cit. 2013-05-25]. Dostupné z: http://www.digium.com/en/products/software/g729-codec Asterisk IP PBX, VOIP Gateway, IVR & Open Source Communications [online]. 2012 [cit. 2012-11-20]. Dostupné z: http://www.asterisk.org/ PBX, IP PBX, Phone System - Switchvox [online]. 2011 [cit. 2012-12-12]. Dostupné z: http://www.switchvox.com/ Asterisk Versions. Asterisk Project Wiki [online]. 2012 [cit. 2012-11-20]. Dostupné z: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions FreeSWITCH | Communication Consolidation [online]. 2012 [cit. 2012-11-20]. Dostupné z: http://freeswitch.org/ Yate | Main / HomePage [online]. 2012 [cit. 2012-11-20]. Dostupné z: http://yate.null.ro/pmwiki/ Why Yate?. Yate | Main / HomePage [online]. 2012 [cit. 2012-11-20]. Dostupné z: http://yate.null.ro/pmwiki/index.php?n=Main.WhyYate? Architecture. Yate | Main / HomePage [online]. 2012 [cit. 2012-11-20]. Dostupné z: http://yate.null.ro/pmwiki/index.php?n=Main.Architecture Voice over IP. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2013 [cit. 2013-05-25]. Dostupné z: http://en.wikipedia.org/wiki/Voice_over_IP RFC3261. IETF [online]. 2012 [cit. 2012-11-20]. Dostupné z: http://www.ietf.org/rfc/rfc3261.txt Session_Initiation_Protocol. Wikipedie, otevřená encyklopedie [online]. 2012 [cit. 201211-20]. Dostupné z: http://cs.wikipedia.org/wiki/Session_Initiation_Protocol URI_scheme. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2013 [cit. 2012-11-20]. Dostupné z: http://en.wikipedia.org/wiki/URI_scheme RFC 6314 - NAT Traversal Practices for Client-Server SIP. IETF Documents [online]. 2011 [cit. 2013-05-25]. Dostupné z: http://tools.ietf.org/html/rfc6314 QoS - voip-info.org. Voip-info.org - voip-info.org [online]. 2013 [cit. 2013-05-25]. Dostupné z: http://www.voip-info.org/wiki/view/QoS Latency VoIP: Voice over IP | DSLReports.com, ISP Information. DSLReports Home : Broadband ISP Reviews News Tools and Forums [online]. 2013 [cit. 2013-05-25]. Dostupné z: http://www.dslreports.com/faq/4278 RFC 1546 - Host Anycasting Service. IETF Documents [online]. 1993 [cit. 2013-0525]. Dostupné z: http://tools.ietf.org/html/rfc1546 Denial-of-service attack. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2013 [cit. 2013-05-25]. Dostupné z: https://en.wikipedia.org/wiki/Denial-of-service_attack DNS Amplification Attacks. In: DNS Amplification Attacks [online]. 2006 [cit. 201305-25]. Dostupné z: http://www.isotf.org/news/DNS-Amplification-Attacks.pdf .blog >> Archiv >> Ochrana obětí před DNS amplification útoky. .blog [online]. 2013 [cit. 2013-05-18]. Dostupné z: http://blog.nic.cz/2013/03/29/ochrana-obeti-pred-dnsamplification-utoky/
[21] 2012 Global Application & Network Security Report. Radware Ltd. [online]. 2013 [cit. 2013-05-18]. Dostupné z: http://www.radware.com/Resources/rclp.aspx? campaign=1630844 [22] Podporujeme šifrované hovory ZRTP i SRTP. In: Forum.odorik.cz [online]. 2012 [cit. 2013-05-25]. Dostupné z: http://forum.odorik.cz/viewtopic.php?f=14&t=892&p=5335 [23] SIP přes TLS/SRTP je k dispozici. In: Www.voocall.cz [online]. 2012 [cit. 2013-05-25]. Dostupné z: http://www.voocall.cz/forum/viewtopic.php?f=10&t=44 [24] Asterisk custom communications - PBX, VoIP gateways, IVRs and more... Asterisk custom communications - PBX, VoIP gateways, IVRs and more... [online]. 2013 [cit. 2013-05-25]. Dostupné z: http://www.asterisk.org/ [25] The Zfone Project - Asterisk PBX Support. Zfone Project Home Page [online]. 2012 [cit. 2012-11-20]. Dostupné z: http://www.zfoneproject.com/prod_asterisk.html [26] QoS Provisioning for VoIP over Wireless Local Area Networks. In: ONG, Eng Hwee a Jamil Y. KHAN. 11th IEEE Singapore International Conference on. 2008, s. 906-911. ISBN 978-1-4244-2423-8. DOI: 10.1109/ICCS.2008.4737317. [27] Performance testing and configurations - FreeSWITCH Wiki. FreeSWITCH Wiki [online]. 2012 [cit. 2013-05-22]. Dostupné z: http://wiki.freeswitch.org/wiki/Performance_testing_and_configurations [28] Cpuload. Yate Documentation [online]. 2012 [cit. 2013-05-25]. Dostupné z: http://docs.yate.ro/wiki/Cpuload
51
SEZNAM ZKRATEK BASH
Bourne Again Shell
B2BUA
Back to Back User Agent
DNAT
Destination Network Translation
DNS
Domain Name System
DNSSEC
Domain Name System Security Extensions
DdoS
Distributed Denial of Service
DoS
Denial of Service
EPEL
Extra Packages for Enterprise Linux
HTTP
Hypertext Transport Protocol
ICMP
Internet Control Message Protocol
IPv4
Internet Protocol version 4
ISO/OSI
International Organization for Standardization/Open Systems Interconnection
ISP
Internet service provider
NAT
Network Address Translation
PBX
Private Branch Exchange
QoS
Quality of Service
RTCP
RTP Control Protocol
RTP
Real-time Transport Protocol
S/MIME
Secure/Multipurpose Internet Mail Extensions
SDP
Session Description Protocol
SIP
Session Initiation Protocol
SRTCP
Secure RTCP
SRTP
Secure Real-time Transport Protocol
TCP
Transmission Control Protocol
TLS
Transport Layer Security
UA
User Agent
UAC
User Agent Client
UAS
User Agent Server
UDP
User Datagram Protocol
URI
Uniform Resource Identifier
VoIP
Voice over IP
XML
Extensible Markup Language
52
SEZNAM PŘÍLOH První příloha, výpis důležitých konfiguračních souborů Druhá příloha, použité skripty Třetí příloha, výpis jednotlivých scénářů Čtvrtá příloha, nastavení firewallu pro omezení počtu paketů Pátá příloha, podrobné výsledky Šestá příloha, obsah přiloženého CD
53
A
PRVNÍ PŘÍLOHA Pravidla Fail2ban pro standardní logovací soubor Asterisku: failregex = NOTICE.* .*: Call from '.*' \(:.*\) .* .* '.*' rejected because extension not found in context '.*'. NOTICE.* .*: Registration from '.*' failed for ':.*' - Wrong password NOTICE.* .*: Registration from '.*' failed for ':.*' - No matching peer found NOTICE.* .*: Registration from '.*' failed for ':.*' - No matching peer found NOTICE.* .*: Registration from '.*' failed for ':.*' Username/auth name mismatch NOTICE.* .*: Registration from '.*' failed for ':.*' - Device does not match ACL NOTICE.* .*: Registration from '.*' failed for ':.*' - Peer is not supposed to register NOTICE.* .*: Registration from '.*' failed for ':.*' - ACL error (permit/deny) NOTICE.* .*: Registration from '.*' failed for ':.*' - Device does not match ACL NOTICE.* .*: Registration from '\".*\".*' failed for ':.*' - No matching peer found NOTICE.* .*: Registration from '\".*\".*' failed for ':.*' - Wrong password NOTICE.* failed to authenticate as '.*'$ NOTICE.* .*: No registration for peer '.*' \(from \) NOTICE.* .*: Host failed MD5 authentication for '.*' (.*) NOTICE.* .*: Failed to authenticate user .*@.* NOTICE.* .*: failed to authenticate as '.*' NOTICE.* .*: tried to authenticate with nonexistent user '.*' VERBOSE.*SIP/-.*Received incoming SIP connection from unknown peer
Pravidla Fail2ban pro logovací soubor debug Asterisku: failregex = DEBUG.* chan_sip.c: Trying to put .* onto TLS socket destined for :.* DEBUG.* chan_sip.c:.* ACK must have a to tag. dropping callid: .*@ from: sipp .* DEBUG.* chan_sip.c: Allocating new SIP dialog for .*@ - OPTIONS .*
Pravidla Fail2ban pro standardní logovací soubor FreeSWITCH: failregex = \[WARNING\] sofia_reg.c:\d+ SIP auth failure \(REGISTER\) on sofia profile \'[^']+\' for \[.*\] from ip \[WARNING\] sofia_reg.c:\d+ SIP auth failure \(INVITE\) on sofia profile \'[^']+\' for \[.*\] from ip \[WARNING\] sofia_reg.c:\d+ SIP auth challenge \(REGISTER\) on sofia profile \'[^']+\' for \[.*\] from ip
Pravidla Fail2ban pro standardní logovací soubor YATE: # Fail2Ban configuration file for YATE [Definition] # Option: # Notes.: # Values: # failregex
failregex regex to match the password failures messages in the logfile. TEXT = <.*> '.*' received .* bytes SIP message from :.* \[.*\]
54
Pravidla Fail2ban pro logovací soubor Sipdos: failregex = kernel: .* SRC= .* DPT=5061
Nastavení časových konstant pro Fail2ban a reakce na splnění podmínek pro Asterisk [asterisk-iptables] enabled filter action logpath findtime maxretry bantime
Nastavení časových konstant pro Fail2ban a reakce na splnění podmínek pro Sipdos [sipdos-iptables] enabled filter action logpath findtime maxretry bantime
Použité skripty pro testování, sběr a úpravu informací. Skript pro generování útoků sipp_check.sh: #!/bin/bash # Setting variables #################################################################### SCENARIO=( ack bye invite options register ) FREQ_CALLS=( #100 #200 #300 #400 500 #600 #700 800 #900 1000 #1100 1200 #1300 #1400 1500 #1600 #1700 #1800 #1900 #2000 ) SCENARIOS_PATH="scenarios" LOCAL_IP=`ifconfig|grep inet|head -1|sed 's/\:/ /'|awk '{print $3}'` TARGET_IP="$1" LOG="./sipp_test.log" TEMP_LOG="/tmp/sipp_test_temp_log" SIPP_PATH="." #################################################################### if [ "$1" == "--help" ] || [ "$1" == "" ]; then echo -e "\nsipp_check.sh IP|address [[Y|N] [number]]\n" echo "IP|address - IP or address of tested PBX" echo "[[Y|N] [number]] - testing calls yes or no and registered number" exit fi ulimit -c unlimited # The maximum size of core files created. ulimit -d unlimited # The maximum size of a process's data segment. ulimit -f unlimited # The maximum size of files created by the shell (default option) ulimit -i unlimited # The maximum number of pending signals ulimit -n 999999 # The maximum number of open file descriptors. ulimit -q unlimited # The maximum POSIX message queue size ulimit -u unlimited # The maximum number of processes available to a single user. ulimit -v unlimited # The maximum amount of virtual memory available to the process. ulimit -x unlimited # ??? ulimit -s 8192 # The maximum stack size ulimit -l unlimited # The maximum size that may be locked into memory. #ulimit -a if [ "$2" == "Y" ]; then CPU_CHECK="Y" rdate -s tik.cesnet.cz else CPU_CHECK="N" FREQ_CALLS=( 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900 2000 ) fi
56
rm $SCENARIOS_PATH/*.csv > /dev/null 2>&1 rm $SCENARIOS_PATH/*.log > /dev/null 2>&1 rm *.csv > /dev/null 2>&1 echo "**************************************************************************" > $TEMP_LOG echo "`date` Starting SIPp test script on $TARGET_IP" >> $TEMP_LOG echo "**************************************************************************" >> $TEMP_LOG if [ "$3" != "" ]; then echo "Scenario;Start time;Transport;Designed attempt;Running time;Total attempt;Testing rate/s;Real rate/s;<10ms;<50ms;<100ms;<500ms;<1000ms;<5000ms;<10000ms;>=10000ms;Successful;Failed ;Hang;Successfull testing calls [%]" > delay.csv else echo "Scenario;Start time;Transport;Designed attempt;Running time;Total attempt;Testing rate/s;Real rate/s;<10ms;<50ms;<100ms;<500ms;<1000ms;<5000ms;<10000ms;>=10000ms;Successful;Failed ;Hang" > delay.csv fi $SIPP_PATH/sipp -sf $SCENARIOS_PATH/options.xml -m 1 -l 1 -r 1 -i $LOCAL_IP -trace_msg -recv_timeout 1000 -timeout 1 -t u1 $TARGET_IP:5060 > /dev/null 2>&1 PBX=`cat $SCENARIOS_PATH/*.log | grep -e Agent -e Server | tail -1` k=0 #number of open ports echo if [ "$PBX" == "" ]; then echo -e "Unsecured UDP transport on port 5060 \e[00;32mNOT FOUND\e[00m." echo "Unsecured UDP transport on port 5060 NOT FOUND." >> $TEMP_LOG else echo -e "Unsecured UDP transport on port 5060 \e[00;31mFOUND\e[00m. Eavesdropping is possible." echo -e "Unsecured UDP transport on port 5060 FOUND. Eavesdropping is possible." >> $TEMP_LOG echo "$PBX" PORTS["$k"]="5060" TRANSPORTS["$k"]="u" k=`expr $k + 1` fi PBX="" rm $SCENARIOS_PATH/*.log > /dev/null 2>&1 $SIPP_PATH/sipp -sf $SCENARIOS_PATH/options.xml -m 1 -l 1 -r 1 -i $LOCAL_IP -trace_msg -recv_timeout 1000 -timeout 1 -t t1 $TARGET_IP:5060 > /dev/null 2>&1 PBX=`cat $SCENARIOS_PATH/*.log | grep -e Agent -e Server | tail -1` if [ "$PBX" == "" ]; then echo -e "Unsecured TCP transport on port 5060 \e[00;32mNOT FOUND\e[00m." echo "Unsecured TCP transport on port 5060 NOT FOUND." >> $TEMP_LOG else echo -e "Unsecured TCP transport on port 5060 \e[00;31mFOUND\e[00m. Eavesdropping is possible." echo -e "Unsecured UDP transport on port 5060 FOUND. Eavesdropping is possible." >> $TEMP_LOG echo "$PBX" PORTS["$k"]="5060" TRANSPORTS["$k"]="t" k=`expr $k + 1` fi PBX="" rm $SCENARIOS_PATH/*.log > /dev/null 2>&1 $SIPP_PATH/sipp -sf $SCENARIOS_PATH/options.xml -m 1 -l 1 -r 1 -i $LOCAL_IP -trace_msg -recv_timeout 1000 -timeout 1 -t l1 $TARGET_IP:5061 > /dev/null 2>&1 PBX=`cat $SCENARIOS_PATH/*.log | grep -e Agent -e Server | tail -1` if [ "$PBX" == "" ]; then echo -e "Secured tls transport on port 5061 \e[00;31mNOT FOUND\e[00m. You may use this for security." echo -e "Secured tls transport on port 5061 NOT FOUND. You may use this for security." >> $TEMP_LOG else echo -e "Secured tls transport on port 5061 \e[00;32mFOUND\e[00m. Secure call enabled." echo -e "Secured tls transport on port 5061 FOUND. Secure call enabled." >> $TEMP_LOG echo "$PBX" PORTS["$k"]="5061" TRANSPORTS["$k"]="l" fi
57
PBX="" rm $SCENARIOS_PATH/*.log > /dev/null 2>&1 if [ "${PORTS[0]}" == "" ]; then echo "No answer from PBX" exit fi l="0" #Max attempts position echo -e "\nPlease wait, testing in progress, this may take a while." for scenario in ${SCENARIO[*]}; do #loop for each scenario for (( i = 0; i <= $k ; i++)); do #loop for each trasport TRANSPORT=`echo ${TRANSPORTS[$i]} | sed -e s/u/UDP/ -e s/t/TCP/ -e s/l/tls/` #convert to full name for log MAX_ATTEMPTS[$l]="$scenario-$TRANSPORT-2000/sec." for freq in ${FREQ_CALLS[*]}; do #loop for each frequency echo `date`" Test for $freq $scenario attempts/s, transport $TRANSPORT." >> $TEMP_LOG CALLS=`expr $freq \* 30` echo -e "Testing scenario \e[00;34m$scenario for $freq attempts/s\e[00m, transport $TRANSPORT." SECS=`date +%S` WAIT=`expr 60 - $SECS` echo "Waiting $WAIT sec. for timesync" sleep $WAIT echo "You may make a testing call to any registered number in next 30 s." TIME=`date +%H:%M:%S` if [ "$3" != "" ]; then $SIPP_PATH/sipp -sf $SCENARIOS_PATH/call.xml -bg -s "$3" -p 65001 -t "$ {TRANSPORTS[$i]}"1 -r 1 -trace_stat -send_timeout 5000 -timeout 45s -m 30 -rtp_echo -i $LOCAL_IP $TARGET_IP:"${PORTS[$i]}" > /dev/null 2>&1 fi $SIPP_PATH/sipp -sf $SCENARIOS_PATH/$scenario.xml -p 65002 -t "$ {TRANSPORTS[$i]}"1 -l $CALLS -r $freq -trace_stat -send_timeout 5000 -recv_timeout 15000 -timeout 53s -timeout_error -m $CALLS -i $LOCAL_IP $TARGET_IP:"${PORTS[$i]}" > /dev/null 2>&1 echo "End of test, waiting for flushing buffers." sleep 20 mv $SCENARIOS_PATH/$scenario*.csv "test_res_$scenario $freq per_sec_transport $TRANSPORT.csv" if [ "$3" != "" ]; then#if testing call enable, rename its log mv $SCENARIOS_PATH/call*.csv "test_call_$scenario $freq per_sec_transport $TRANSPORT.csv" fi sleep 2 echo "Rate/s <10ms <50ms <100ms <500ms <1s <5s <10s >=10s Succ. Failed" | tee -a $TEMP_LOG printf "%-8s %-6s %-6s %-6s %-6s %-6s %-6s %-6s %-6s %-6s %-6s \n" `tail -1 "test_res_$scenario $freq per_sec_transport $TRANSPORT.csv" | awk -F ";" '{ print $8 " " $66 " " $67 " " $68 " " $69 " " $70 " " $71 " " $72 " " $73 " " $16 " " $18 }'` | tee -a $TEMP_LOG DATA=`tail -1 "test_res_$scenario $freq per_sec_transport $TRANSPORT.csv" | awk -F ";" '{ print $5 ";" $13 ";" $6 ";" $8 ";" $66 ";" $67 ";" $68 ";" $69 ";" $70 ";" $71 ";" $72 ";" $73 ";" $16 ";" $18 ";" $14 }'` FAILED=`tail -1 "test_res_$scenario $freq per_sec_transport $TRANSPORT.csv" | awk -F ";" '{ print $18 }'` if [ "$3" != "" ]; then#if testing call enable, calculate its efficiency TEST_CALLS=`tail -1 "test_call_$scenario $freq per_sec_transport $TRANSPORT.csv" | awk -F ";" '{ print $16 }'` TEST_CALLS=`expr $TEST_CALLS \* 100 \* 33 / 1000 + $TEST_CALLS \* 100 % 33 / 30` echo "$scenario;$TIME;$TRANSPORT;$CALLS;$DATA;$TEST_CALLS">> "delay.csv" echo "$TEST_CALLS % successfull testing calls" | tee -a $TEMP_LOG else echo "$scenario;$TIME;$TRANSPORT;$CALLS;$DATA">> "delay.csv" fi DELAY_ARRAY=( `tail -1 "test_res_$scenario $freq per_sec_transport $TRANSPORT.csv" | awk -F ";" '{ print $66 " " $67 " " $68 " " $69 " " $70 " " $71 " " $72 " " $73 }'` ) if [ "$3" != "" ]; then#if testing call enable if [ "$TEST_CALLS" -lt "100" ]; then #if efficiency is lower than 100%, show it echo -e "\e[00;31m!!!ERROR!!!\e[00m, PBX cannot answer to all testing calls!!!" echo "!!!ERROR!!!, PBX cannot answer to testing calls!!!" >> $TEMP_LOG fi fi
58
if [ "${DELAY_ARRAY[3]}" -gt "0" ]; then echo -e "\e[00;35mNOTIFICATION\e[00m, ${DELAY_ARRAY[3]} of $CALLS answer(s) is delayed more than 100ms." echo "NOTIFICATION, ${DELAY_ARRAY[3]} of $CALLS answer(s) is delayed more than 100ms." >> $TEMP_LOG fi if [ "${DELAY_ARRAY[4]}" -gt "0" ]; then echo -e "\e[00;33mALERT\e[00m, ${DELAY_ARRAY[4]} of $CALLS answer(s) is delayed more than 500ms." echo "ALERT, ${DELAY_ARRAY[4]} of $CALLS answer(s) is delayed more than 500ms." >> $TEMP_LOG fi if [ "${DELAY_ARRAY[5]}" -gt "0" ]; then echo -e "\e[00;31mWARNING\e[00m, ${DELAY_ARRAY[5]} of $CALLS answer(s) is delayed more than 1s!" echo "WARNING, ${DELAY_ARRAY[5]} of $CALLS answer(s) is delayed more than 1s!" >> $TEMP_LOG fi if [ "${DELAY_ARRAY[6]}" -gt "0" ]; then echo -e "\e[00;31mWARNING\e[00m, ${DELAY_ARRAY[6]} of $CALLS answer(s) is delayed more than 5s!" echo "WARNING, ${DELAY_ARRAY[6]} of $CALLS answer(s) is delayed more than 5s!" >> $TEMP_LOG fi if [ "${DELAY_ARRAY[7]}" -gt "0" ]; then echo -e "\e[00;31mWARNING\e[00m, ${DELAY_ARRAY[7]} of $CALLS answer(s) is delayed more than 10s (timeout)!!!" echo "WARNING, ${DELAY_ARRAY[7]} of $CALLS answer(s) is delayed more than 10s (timeout)!!!" >> $TEMP_LOG fi if [ "$3" != "" ]; then#if testing call enable if [ "${DELAY_ARRAY[3]}" -eq "0" ] && [ "${DELAY_ARRAY[4]}" -eq "0" ] && [ "$ {DELAY_ARRAY[5]}" -eq "0" ] && [ "${DELAY_ARRAY[6]}" -eq "0" ] && [ "$ {DELAY_ARRAY[7]}" -eq "0" ] && [ "$TEST_CALLS" -eq "100" ]; then #criteria for succesfull test, delay is lower than 100ms, testing calls 100% echo -e "\e[00;32mOK\e[00m, the PBX is able to serve $freq $scenario per sec." echo "OK, the PBX is able to serve $freq $scenario per sec." >> $TEMP_LOG fi else #if testing call disable if [ "${DELAY_ARRAY[3]}" -eq "0" ] && [ "${DELAY_ARRAY[4]}" -eq "0" ] && [ "$ {DELAY_ARRAY[5]}" -eq "0" ] && [ "${DELAY_ARRAY[6]}" -eq "0" ] && [ "$ {DELAY_ARRAY[7]}" -eq "0" ]; then #criteria for succesfull test, delay is lower than 100ms echo -e "\e[00;32mOK\e[00m, the PBX is able to serve $freq $scenario per sec." echo "OK, the PBX is able to serve $freq $scenario per sec." >> $TEMP_LOG fi fi if [ "${DELAY_ARRAY[5]}" -eq "0" ] && [ "${DELAY_ARRAY[6]}" -eq "0" ] && [ "$ {DELAY_ARRAY[7]}" -eq "0" ] && [ "$FAILED" -gt "$freq" ]; then if [ "$CPU_CHECK" == "N" ]; then #without PBX access, brake echo -e "\e[00;31mThe PBX is probably protected, flood attack isn´t effective.\e[00m" echo "The PBX is probably protected, flood attack isn´t effective." >> $TEMP_LOG MAX_ATTEMPTS[$l]="$scenario-$TRANSPORT-protected." break fi fi if [ "${DELAY_ARRAY[5]}" -gt "0" ] || [ "${DELAY_ARRAY[6]}" -gt "0" ] || [ "$ {DELAY_ARRAY[7]}" -gt "0" ]; then if [ "${DELAY_ARRAY[5]}" -eq "0" ] && [ "${DELAY_ARRAY[6]}" -eq "0" ] && [ "$ {DELAY_ARRAY[7]}" -gt "$freq" ]; then if [ "$CPU_CHECK" == "N" ]; then echo -e "\e[00;31mThe PBX is probably protected, flood attack isn´t effective.\e[00m" echo "The PBX is probably protected, flood attack isn´t effective." >> $TEMP_LOG MAX_ATTEMPTS[$l]="$scenario-$TRANSPORT-protected." break fi else if [ "$CPU_CHECK" == "N" ]; then echo -e "\e[00;31mWARNING, The PBX is going to overload, maximum ($freq) attempts per sec. reached!\e[00m"
59
echo "WARNING, The PBX is going to overload, maximum ($freq) attempts per sec. reached!" >> $TEMP_LOG MAX_ATTEMPTS[$l]="$scenario-$TRANSPORT-$freq/sec." break fi fi fi done l=`expr $l + 1` done done cat test*.csv > cumulative_results.csv if [ "$CPU_CHECK" == "Y" ]; then echo `date`" Test completed, please press Ctrl+c on server machine, copy siptop.log here and run siptop_log.sh file." | tee -a $TEMP_LOG else echo -e "\nPBX maximum rates:\n" | tee -a $TEMP_LOG for result in ${MAX_ATTEMPTS[*]}; do #loop for each result echo "$result" | tee -a $TEMP_LOG done fi echo "For detail info look at file delay.csv" | tee -a $TEMP_LOG cat $TEMP_LOG >> $LOG rm $TEMP_LOG exit 0
Skript pro zpracování průběžných log souborů sipp_log.sh: #!/bin/bash PBX_BIN=`tail -2 siptop.log | head -1 | awk '{ print $(NF) }'` cat siptop.log | grep -e "load average" -e $PBX_BIN | sed '$!N;s/\n/ /' | awk -F " " '{ print $3 ";" $(NF-6) ";" $(NF-3) }' > siptop.csv k=2 LINES_METHODS=`wc -l delay.csv | awk -F " " '{ print $1}'` #lines of delay.csv METHOD=`tail -1 delay.csv | awk -F ";" '{ print $1}'` #last method from delay.csv ROUNDS_METHODS=`cat delay.csv |grep $METHOD |wc -l` #number of rounds TEMP=`expr "$LINES_METHODS" - "1"` NUM_METHODS=`expr $TEMP / "$ROUNDS_METHODS"` #number of methods STARTTIME=`sed -n '2,2p' delay.csv | awk -F ";" '{ print $2}'` #start of test time ENDTIME=`tail -1 delay.csv | awk -F ";" '{ print $2}'` #end of test time STARTLINE=`sed -n -e '/'$STARTTIME'/{=}' -e h siptop.csv` TEMP=`sed -n -e '/'$ENDTIME'/{=}' -e h siptop.csv` ENDLINE=`expr 30 + $TEMP` LINES=`expr $ENDLINE - $STARTLINE` HIGH_CPU="80" #define % of high CPU rm -f CPUTEMP.csv rm -f MEMTEMP.csv for (( i = 2; i <= $LINES_METHODS ; i = $i+$ROUNDS_METHODS)) do TEMP=`sed -n ''$i','$i'p' delay.csv | awk -F ";" '{ print $1}'` echo -n ";;;;;;;;;;;;;;;;;;;;;$TEMP;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;" >>"CPUTEMP.csv" echo -n ";;;;;;;;;;;;;;;;;;;;;$TEMP;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;" >>"MEMTEMP.csv" done for (( k = 0; k <= $ROUNDS_METHODS-1 ; k++ )) do echo "">>"CPUTEMP.csv" echo "">>"MEMTEMP.csv" l=`expr 2 + $k` TRANSPORT=`sed -n ''$l','$l'p' delay.csv | awk -F ";" '{ print $3}'` RATE=`sed -n ''$l','$l'p' delay.csv | awk -F ";" '{ print $7}'` echo -n "$RATE/s $TRANSPORT">> "CPUTEMP.csv" echo -n "$RATE/s $TRANSPORT">> "MEMTEMP.csv" for (( i = 2+$k; i <= $LINES_METHODS ; i = $i+$ROUNDS_METHODS )) do STARTTIME=`sed -n ''$i','$i'p' delay.csv | awk -F ";" '{ print $2}'`
60
STARTLINE=`sed -n -e '/'$STARTTIME'/{=}' -e h siptop.csv` METHOD=`sed -n ''$i','$i'p' delay.csv | awk -F ";" '{ print $1}'` TRANSPORT=`sed -n ''$i','$i'p' delay.csv | awk -F ";" '{ print $3}'` RATE=`sed -n ''$i','$i'p' delay.csv | awk -F ";" '{ print $7}'` high=0 #secs of high CPU usage AVERAGE_CPU=0 for (( j = `expr $STARTLINE - 5`; j <= `expr $STARTLINE + 45` ; j++ )) do CPU=`sed -n ''$j','$j'p' siptop.csv | awk -F ";" '{ print $3}'` MEM=`sed -n ''$j','$j'p' siptop.csv | awk -F ";" '{ print $2}'` if [ "${CPU/.*}" -gt "$HIGH_CPU" ]; then high=`expr $high + 1` fi if [ "$j" -ge "$STARTLINE" ] && [ "$j" -le "`expr $STARTLINE + 30`" ]; then AVERAGE_CPU=$(echo $AVERAGE_CPU + $CPU | bc) fi echo -n ";$CPU">> "CPUTEMP.csv" echo -n ";$MEM">> "MEMTEMP.csv" done AVERAGE_CPU=$(echo $AVERAGE_CPU / 30 | bc) echo -en "\nAverage CPU: $AVERAGE_CPU%, flood: $RATE $METHOD/s on $TRANSPORT" if [ "$high" -gt "5" ]; then echo -en ", \e[00;31m$high sec. of 50 is greather than $HIGH_CPU%\e[00m" fi done done echo cat CPUTEMP.csv | tr "." "," >CPU.csv cat MEMTEMP.csv | tr "." "," >MEM.csv rm -f CPUTEMP.csv rm -f MEMTEMP.csv exit 0
Skript pro logování zatížení CPU na ústředně siptop.sh: #!/bin/bash if [ "$1" == "--help" ] || [ "$1" == "" ]; then echo -e "\nsiptop.sh [PBX_bin]\n" exit fi PBX_PID=`ps -e | grep $1 | awk '{ print $1; }'` if [ "$PBX_PID" == "" ] ; then echo -e "\nsiptop.sh [PBX_bin]\n" exit fi rdate -s tik.cesnet.cz rm siptop.log echo "Start logging CPU usage of $1" echo "After finished tests pres Ctrl+c" top -d 1 -b -p $PBX_PID > siptop.log if [ "`tail -2 siptop.log | head -1 | awk '{ print $(NF) }'`" == "$1" ]; then exit else echo -e "\e[00;31mSomething is wrong PBX is not working or changed PID!!!\e[00m" fi
61
C
TŘETÍ PŘÍLOHA Použité scénáře pro testování odezvy.
]]> <pause milliseconds = "3000"/> <send retrans="500"> ;tag=[call_number] To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param] Call-ID: [call_id] CSeq: 2 BYE Contact: sip:sipp@[local_ip]:[local_port] Max-Forwards: 70 Subject: Performance Test Content-Length: 0 ]]>
65
D
ČTVRTÁ PŘÍLOHA Nastavení firewallu pro omezení počtu paketů sipdos.sh. #!/bin/sh # # All SIP traffic rate, per host. RATE=100/minute # Burst BURST=30 # Interface(s) to protect. Seperate multiple interfaces with spaces. IFACE="eth0" # Location of iptables binary. IPTABLES=`which iptables` if [ ! "$1" ] then echo "SIP DoS/DDoS mitigation script for iptables See top of script for configuration Usage: $0 [start|stop|status]" exit 1 fi if [ "$1" = "status" ] then $IPTABLES -L -v -n exit fi # Setup iptables $IPTABLES -F sipdos 2> /dev/null $IPTABLES -X sipdos 2> /dev/null $IPTABLES -N sipdos 2> /dev/null if [ "$1" = "stop" ] then echo "Clearing iptables rules…" $IPTABLES -F INPUT 2> /dev/null exit fi # Send the right traffic through our chain for i in $IFACE do $IPTABLES -A INPUT -i $i -m tcp -p tcp --dport 5061 -j sipdos done # Finally set limits… $IPTABLES -A sipdos -m hashlimit --hashlimit $RATE --hashlimit-burst $BURST --hashlimit-mode srcip,dstport --hashlimit-name sip_o_limit -j ACCEPT # Take action $IPTABLES -A sipdos -j LOG $IPTABLES -A sipdos -j DROP
66
E
PÁTÁ PŘÍLOHA Podrobné výsledky všech testů u všech metod a druhů zabezpečení s četností 1000 útoků za sekundu.
67
F
ŠESTÁ PŘÍLOHA Obsah přiloženého CD
Conf Results Scripts Metody zajisteni IP PBX proti utokum.pdf
konfigurační soubory podrobné výsledky všech testů použité skripty tato diplomová práce
