FAKULTA INFORMAČNÍCH TECHNOLOGIÍ

Transkript

1 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV INFORMAČNÍCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS DETEKCE A IZOLACE ÚTOČNÍKŮ POMOCÍ ZÁZNAMŮ NETFLOW DETECTION AND ISOLATION OF ATTACKERS USING NETFLOW DATA DIPLOMOVÁ PRÁCE MASTER S THESIS AUTOR PRÁCE AUTHOR VEDOUCÍ PRÁCE SUPERVISOR MATĚJ GRÉGR Ing. PETR MATOUŠEK, Ph.D. BRNO 2009

2 Zadání práce 1. Seznamte se s protokolem NetFlow a nástroji pro analýzu dat získaných ze sondy NetFlow. 2. Seznamte se s penetračními nástroji pro zjišt ování informací o síti a sít ových zařízení (nessus, nmap, apod.). 3. Simulujte útok na sít v laboratorních podmínkách. Analyzujte záznamy NetFlow s cílem detekce a izolace útočník. 4. Navrhněte a implementujte systém pro automatickou detekci a izolaci útočníka. 5. Demonstrujte použitelnost systému na reálném sít ovém provozu (podle doporučení vedoucího).

3 Licenční smlouva Licenční smlouva je uložena v archívu Fakulty informačních technologií Vysokého učení technického v Brně. Abstrakt Diplomová práce se zabývá použitím záznamů NetFlow pro detekci skenování sítě. Jako zdroj dat jsou použita anonymizovaná data NetFlow z páteřní sítě VUT. Z těchto dat jsou vytvořeny statistiky, na jejichž základě je navrhnuta sada skriptů. Pomocí těchto skriptů je možné detekovat skenování i ve velkých akademických sítích. Abstract This thesis deals with using NetFlow records for detection network scanning. Anonymized NetFlow records from backbone VUT network are used as the source. Based on statistics created from these records, several Bash and Python scripts are implemented. With these scripts it is possible to detect network scanning even in large academics networks. Klíčová slova NetFlow, sonda, skenování, zabezpečení Keywords NetFlow, probe, scanning, security Citace Matěj Grégr: Detekce a izolace útočníků pomocí záznamů NetFlow, diplomová práce, Brno, FIT VUT v Brně, 2009

4 Detekce a izolace útočníků pomocí záznamů NetFlow Prohlášení Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně pod vedením pana Ing. Petra Matouška, Ph.D Matěj Grégr Poděkování Děkuji Ing. Petrovi Matouškovi, Ph.D. za vedení diplomové práce a cenné připomínky a Ing. Tomáši Podermańskimu za zpřístupnění záznamů NetFlow a poskytnuté konzultace k dosaženým výsledkům. c Matěj Grégr, Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informačních technologií. Práce je chráněna autorským zákonem a její užití bez udělení oprávnění autorem je nezákonné, s výjimkou zákonem definovaných případů.

5 Obsah Obsah 2 1 Úvod Cíl diplomové práce Členění práce Útoky a jejich analýza 5 3 Skenovací techniky a nástroje Skenovací techniky TCP UDP Skenovací nástroje NetFlow Protokol NetFlow Základní popis Princip fungování a vznik protokolu Ukládané informace Architektura NetFlow Sonda NetFlow Vlastnosti sondy: Nástroje Skenování a NetFlow Skenování pomocí nmap Skenování pomocí EtherScope TM Series II Práce s daty NetFlow v rozsáhlých sítích Zdroj dat NetFlow Zpracování dat Statistika dat NetFlow v rozsáhlých sítích 21 8 Analýza získaných dat a návrh aplikace Shrnutí získaných statistik Rozhodovací algoritmus

6 9 Implementace Popis implementace Čas zpracování Výsledky analýzy Výzkum ve světě Možná rozšíření Závěr 40 Použitá literatura 42 Seznam příloh 43 A Nástroj nfdump - formát výstupu pipe 44 B Grafické rozhraní vytvořené nástrojem nfsen 45 C Ukázka detekce a záznam komunikace 46 C.1 Skenovaná IP adresa pomocí protkolu ICMP C.2 Detekce útoku snažící se zneužít službu Windows Messenger C.3 Skenování služby DNS C.4 Skenování služby SSH

7 Kapitola 1 Úvod Počítačové sítě čelí v dnešní době stále většímu množství bezpečnostních hrozeb a zabezpečit je proti těmto hrozbám přináší celou řadu problémů. Samotný firewall již na kvalitní zabezpečení přestává stačit a proto bývá kombinován s další technologií. Jednou z možností jak zvýšit bezpečnost počítačové sítě, by mohlo být využití záznamů NetFlow, které jsou generovány sondami nebo směrovači s podporou této technologie. Aby mohl útočník naplánovat útok na počítačovou sít, potřebuje znát o dané síti co nejvíce informací. Pokud se při zajišt ování bezpečnosti počítačové sítě zaměříme také na tuto počátační fázi útoku, můžeme díky včasné detekci útoku minimalizovat vzniklé škody, případně útok zcela odvrátit. 1.1 Cíl diplomové práce Hlavním cílem diplomové práce bude analyzovat, zda lze pomocí záznamů NetFlow úspěšně detekovat počáteční fázi útoku - skenování sítě. Pokud by se tyto typy útoků daly detekovat, byl by to přínos pro bezpečnost sítě. Reakcí na detekovaný útok by mohla být blokace útočníka, omezení útočníka nebo zaslání informace správci sítě. Tato diplomová práce navazuje na semestrální projekt, ve kterém byly popsány principy a fungování protokolu NetFlow, jaká zařízení slouží ke generování záznamů NetFlow a jaké nástroje můžeme použít k analýze těchto záznamů. Byly také popsány techniky skenování sítě a dostupné nástroje, které se ke skenování používají. Jednotlivé skenovací nástroje byly otestovány v laboratorních podmínkách. V diplomové práci se dále budu zabývat daty NetFlow získanými z reálného provozu velké sítě. Z těchto dat bude vytvořena statistika, která pomůže určit, které údaje jsou z hlediska detekce skenování důležité. Dále bude implementována aplikace, která bude schopna tato skenování detekovat a zaznamenat. Dosažené výsledky by měly být konzultovány se správcem sítě, aby se aplikace dala použít prakticky a získané výsledky umožnily zvětšit zabezpečení sítě. 1.2 Členění práce Kapitola 2 popisuje současně používané techniky pro detekci sít ových útoků. V kapitole 3 se zabývám technikami skenování zařízení na síti a skenovacími nástroji (at už hardwarovými nebo softwarovými). Kapitola 4 popisuje protokol NetFlow, princip fungování protokolu a volně dostupné nástroje určené pro práci s tímto protokolem. Použití skeno- 3

8 vacích nástrojů a testování skenovacích technik při skenování v laboratoři jsou popsány v kapitole 5. Kapitola 6 popisuje problematiku analýzy záznamů NetFlow ve velkých sítích. Je zde také popsáno, odkud byla získána data NetFlow, použita v této práci a jaká tato data mají omezení. V kapitole 7 je popsáno, jak byly vytvořeny z dat NetFlow statistiky, které jsou použity pro zjištění, které informace jsou důležité z hlediska detekce skenování. V kapitole 8 jsou tato data analyzována a je vytvořen návrh aplikace, která bude schopna detekovat skenování. Kapitola 9 popisuje konkrétní implementaci pro sít VUT. V kapitole 10 jsou shrnuty dosažené výsledky a diskutována možná rozšíření. Součástí diplomové práce jsou také přílohy. Seznam viz 11. 4

9 Kapitola 2 Útoky a jejich analýza Útok na sít vždy začíná zkoumáním sítě (network reconnaissance), kdy se útočník pokouší o neautorizované zmapování sítě, služeb nebo zranitelností. Cílem této fáze je získat dostatek informací k provedení dalších typů útoků se zaměřením na získání přístupu nebo odmítnutí přístupu legitimním uživatelům. Pokud by byla počáteční fáze (tedy zkoumání) neúspěšná, další útok by byl pro útočníka daleko obtížněji realizovatelný. Při mapování sítě se používají převážně následující techniky: Skenování IP adres: Zjišt ování aktivních IP adres v podsíti či organizaci. Realizované převážně pomocí protokolu ICMP a zpráv Echo request, Echo reply (ping). Skenování portů: U aktivních IP adres možnost zjistit, jaké služby dané sít ové zařízení podporuje. Více v kapitole 3 Naslouchání: Odposlouchávání datového provozu na síti. Ztěžují to přepínané sítě, ale pokud se bude analyzovat provoz na hraničních bodech, lze získat množství informací. Informační dotazy na aplikační vrstvě: Využití dotazů DNS, databáze whois, zjištění rozsahu IP adres organizace Pro detekci těchto a dalších typů útoků se dnes ve větších sítích používají Network Intrusion Detection System (NIDS) a Network Intrusion Prevention System (NIPS). Systém NIDS útoky detekuje a rozpoznává. Útokům se nesnaží aktivně bránit - jedná se o pasivní obranný systém. NIPS se snaží útokům aktivně zabránit. Systém NIDS/NIPS tvoří senzory na vstupních bodech sítě, které analyzují sít ový provoz a snaží se detekovat útoky. Získaná data posílají centrální stanici, která je zpracovává. Řešení může být čistě softwarové, např. program snort, nebo specializované zařízení, např. Cisco Guard. Při reakci na útok je spuštěn alarm. To je obecný název pro akci, kterou systém upozorňuje na detekovanou aktivitu. Záleží na systému, jak je tato akce realizována. Může se jednat například o poslání u správci nebo zaznamenání události do logovacího souboru. Žádný systém NIDS/NIPS ale není natolik přesný, aby generoval pouze korektní alarmy. Cílem je minimalizovat falešné pozitivní a negativní alarmy. Falešné alarmy - špatné vyhodnocení situace falešné pozitivní alarmy - vygenerován alarm při normální sít ové aktivitě falešné negativní alarmy - nevygenerován alarm při známém útoku 5

10 Pravé alarmy - správné vyhodnocení situace pravé pozitivní alarmy - vygenerován alarm při útoku pravé negativní alarmy - při normlní aktivitě není generován žádný alarm Pro analýzu datového toku a detekci útoků se používá několik typů analýz [19]. Analýza vzorů - Cílem je najít vzor, který je pro útok specifický. Z těchto vzorů jsou pak vytvořeny databáze, které se využívají pro detekci (může být dodána například výrobcem spolu se systémem IDS). Posloupnost paketů, které mají nastaven pouze příznak SYN, může být například vzor útoku pro skenování. Každý nový útok musí být analyzován a uložen jako nový vzor. Podle počtu paketů potřebných k detekci útoku můžeme klasifikovat vzory atomické - stačí jeden paket, nebo složené - je třeba více paketů. Systém IDS využívající tento typ analýzy může generovat zvýšené množství jak falešných negativních alarmů (např. při malé změně známého útoku) tak falešných pozitivních (vzor je příliš neurčitý). Statistická analýza - Někdy označována také jako detekce anomálií. Systém pracující s touto analýzou se naučí normální provoz v dané síti, tzv. profil. Pokud následně profil sítě přesáhne zvolenou odchylku, je generován alarm. Výhodou tohoto systému je i možnost detekce nových útoků a pokud je vytvořen kvalitní profil, tak i snížení falešných pozitivních alarmů. Uživatelé své chování mohou ale měnit, což negativně ovlivňuje počet falešně pozitivních alarmů (je nutné aktualizovat profily při změně sítě). Kontrola obsahu protokolů - Aplikační protokoly jako FTP, HTTP, SMTP a jiné mohou být analyzovány na základě obsahu jednotlivých paketů. Tato detekce a analýza se týká spíše systémů IPS, které mohou blokovat vybrané příkazy, sloužit jako proxy servery a podobně. Jedná se o aktivní obranu. Pokud je nějaký útok detekován, závisí na použitém systému, jaká bude další reakce. Pokud se jedná o systém NIDS, útok je zpravidla zaznamenán do souboru se záznamy (logu) a systém upozorní správce, který provede bezpečnostní opatření. Systém NIPS zpravidla reaguje ihned a útoku se snaží aktivně zabránit. Následuje fáze prevence, kdy se snaží upravit odolnost systému, aby zabránil dalším podobným útokům. Možné reakce a prevence: Reset spojení TCP - u spojení TCP je zaslán paket s příznakem RST oběma účastníkům. U spojení UDP se generuje paket ICMP se zprávou Port Unreachable. Blokace spojení - sít ové spojení je ihned zrušeno a zdrojová IP adresa je zablokována. Odebírání přidělených prostředků - v případě vyčerpání zdrojů se mění např. max. počet částečně otevřených spojení, max. doba nečinnosti spojení (idle timeout), max. počet současně otevřených spojení, délka čekání na ukončovací paket (příznak FIN) a jiné. Využití proxy - u protokolu HTTP i jiných aplikačních protokolů, u spojení TCP se může využít tzv. SYN cookies. 6

11 Kapitola 3 Skenovací techniky a nástroje Skenování sítě bývá rozděleno většinou na tři typy, podle způsobu, jakým skenuje porty (viz obrázek 3.1). Při horizontálním skenování útočník skenuje jeden port na více počítačích. U vertikálního skenování skenuje více portů na jednom počítači a blokové skenování je kombinací obou. porty ~ 1023 vertikální skenování ~ horizontální skenování ~ blokové skenování ~ ~ ~ IP Obrázek 3.1: Typy skenování Skenování je realizováno u protokolu TCP a UDP skenováním portů [8]. Porty mohou být v následujících stavech: open, accepted: Pokud je port open (otevřený), znamená to, že na něm běží sít ová služba a je možno s ním navázat spojení. closed, denied: closed port značí uzavřený port. Na pokus o připojení k takovému portu je u TCP portu poslán zpět paket s nastavenými příznaky RST a ACK, v případě portu UDP je poslán ICMP paket typu 3, kód 3 (port unreachable). filtered, blocked: Při pokusu o kontaktování tohoto portu nebyla zjištěna odpověd (kladná ani záporná) Další zjišt ování informací o tom, co na daném portu běží za službu, případně jaký OS daný počítač používá, je už převážně záležitost analyzování odpovědí ze skenování portů. 7

12 3.1 Skenovací techniky TCP U skenování TCP portů můžeme využít více technik. Většina využívá různých nastavených příznaků v TCP paketu a toho, že u protokolu TCP se navazuje a ustanovuje spojení. Při navazování spojení jde o tzv. třífázovou synchronizaci (three-way handshake). Pokud port odpoví tak jak má (příznaky SYN/ACK), je ve stavu open. Při odpovědi RST je ve stavu closed a při žádné odpovědi ve stavu filtered/blocked. Skenování SYN Skenování SYN nikdy nedokončí TCP spojení. Pro zjištění toho, zda je port otevřen, mu stačí poslat pouze paket s příznakem SYN a čekat na odpověd. Pokud přijde SYN/ACK, útočník ví, že port je otevřený. Podle třífázové synchronizace by měl poslat paket s příznakem ACK, ale ten nepošle a kompletní spojení tedy nenaváže. Tento typ skenování se využívá pro svou rychlost a proto, že je větší pravděpodobnost, že nekompletní navázání spojení nebude logováno. Skenování connect Skenování connect je vlastně klasické kompletní navázání spojení. Pokud je port ve stavu open, proběhnou všechny tři kroky synchronizace TCP. Tato skenovací technika není příliš využívána, protože poskytuje stejné informace jako SYN scan, ale je pomalejší a kompletní spojení bývají logována. Skenování Null, FIN a Xmas Tyto způsoby skenování využívají znění TCP RFC 793 [15], kde je řečeno, že pokud je port ve stavu closed, na každá příchozí data, která neobsahují příznak RST, má odpovědět paketem s příznakem RST. Pokud je port ve stavu open, má na jakékoliv pakety, kde nejsou nastaveny ani jedny z příznaků SYN, RST, ACK, zareagovat zahozením paketu. Skenování Null posílá pakety bez nastavení jakéhokoliv příznaku. Skenování FIN nastavuje u paketu pouze příznak FIN. Skenování Xmas nastavuje příznaky FIN, URG a PSH. Skenování Ack Tento způsob skenování má za účel zjistit pouze to, zda je port filtrován nebo ne. Pokud je port nefiltrován, tak open i closed port by na paket s příznakem ACK měl odpovědět paketem s příznakem RST. Pokud je port filtrován, tak neodpoví UDP U protokolu UDP se využívá pouze jediného skenování. Pro oskenování UDP portu se posílá paket UDP pouze s hlavičkou, který neobsahuje žádná data. Pokud se vrátí jako odpověd paket ICMP typu 3, kódu 3, je port označen jako closed. Pokud se vrátí paket ICMP jiného kódu (1,2,9,10,13), můžeme port označit jako filtered. Při otevřeném portu jako odpověd přijdou nějaká data z dotazovaného UDP portu. 8

13 3.2 Skenovací nástroje Většinu výše zmiňovaných technik skenování lze vyzkoušet pomocí skenovacího nástroje. Kromě skenování connect, které je v podstatě stejné, jako připojení se na daný port telnetem, využívají ostatní techniky upravené příznaky v hlavičkách TCP paketů, které vyžadují externí knihovny a administrátorská oprávnění. Nejznámější a nejpoužívanější skener portů a sítě obecně je nástroj Network Mapper, zkráceně nmap. Nmap [14] Nmap ( Network Mapper ) je bezpečnostní a sít ový skener. Dokáže odhalovat počítače v síti a služby, které na nich běží. Z pokročilejších nastavení lze použít detekci operačního systému, jaké filtry a firewally jsou použity a jaké verze služeb běží na daném počítači apod. Je šířen pod licencí GNU GPL. Pokud ponecháme základní nastavení, tak základní příkaz #nmap ip.skenovaného.počítače zadaný na příkazové řádce otestuje, zda je počítač aktivní a pokud ano, testuje přibližne 1000 nejpoužívanějších portů. Nmap má obrovské množství nastavení a různých způsobů jak zjistit, jaké služby počítač poskytuje. Více informací lze získat v manuálové stránce nebo na stránce projektu. Nessus [1] Nessus je program pro kompletní bezpečnostní analýzu. Skládá se z démona nessusd, který se stará o samotné skenování a klienta nessus, který nastavuje různé parametry skenování, spouští skenování a zobrazuje výsledky uživateli. Pro samotné skenování používá zásuvné moduly, napsané ve vlastním skriptovacím jazyce NASL 1. Těchto modulů existuje velké množství (přes ) a stále se aktualizují, podle aktuálních bezpečnostních zranitelností. Při testování zranitelnosti používá Nessus na začátku skenování portů daného počítače. Má vlastní skener, ale dokáže použít také externí, jako např. nmap. U zjištěných otevřených portů zkouší využít známých bezpečnostních chyb služeb, které na daném portu naslouchají. Testuje také konfiguraci a chybějící bezpečnostní záplaty, zda se nepoužívají standardní a nevyplněná hesla a další. Do roku 2005 to byl projekt s otevřeným zdrojovým kódem, pak byl uzavřen. Pro nekomerční využití je stále k dispozici zdarma (je nutná registrace), ale aktualizované moduly jsou nabízeny se sedmidenním zpožděním. EtherScope TM Series II [2] Sít můžeme skenovat i pomocí hardwarových zařízení. Jedním z analyzátorů, je přístroj EtherScope TM Series II od firmy Fluke networks. Tento přístroj dokáže analyzovat sít, do které je připojen. Zvládá otestovat kabeláž, analyzovat provoz v síti, identifikovat VLAN sítě, odhalit aktivní zařízení v síti. Je schopen zobrazit statistiky a grafy protokolů, které se na síti používají, detekovat úzká místa v síti (bottleneck) a mnoho dalšího. Zařízení používá jako operační systém Linux a pro zobrazení výsledků platformu Qtopia od firmy Trolltech. Podrobnější popis je k dispozici v dokumentaci u výrobce. 1 Nessus Attack Scripting Language 9

14 Kapitola 4 NetFlow Tato kapitola popisuje protokol NetFlow. Je zde popsán princip fungování protokolu, nástroje, které se při práci s tímto protokolem používají, a sonda NetFlow, což je hardwarové zařízení využívající NetFlow protokol. Pomocí tohoto protokolu lze ukládat záznam o provozu v síti. Tato data budou v práci dále analyzována a pokusím se zjistit, zda lze z těchto dat odhalit skenování sítě. 4.1 Protokol NetFlow Základní popis Protokol NetFlow je protokol pro přenos záznamů o tocích, který vyvinula společnost Cisco. NetFlow je také chápán i jako celý proces měření toků. Jako další protokoly této společnosti je uzavřený, ale je k dispozici jeho specifikace v RFC 3954 [5](poslední verze 9). Díky dostupnosti specifikace je protokol implementován a podporován také na jiných platformách než Cisco IOS např. směrovače Juniper nebo distribuce FreeBSD, OpenBSD a GNU/Linux. Vzniklo několik verzí tohoto protokolu. Nejpoužívanější je v dnešní době verze 5 a rozšiřuje se také poslední verze 9. Poslední verze protokolu NetFlow je také základem protokolu IPFIX 1, vytvořený IETF, který pravděpodobně bude v blízké době schválen jako standard. Protokol definuje několik pojmů, se kterými je nutné se seznámit. IP tok (IP Flow): Často se používá pouze název tok. Tok je posloupnost paketů procházející monitorovaným rozhraním za určitý časový interval. Tyto pakety se shodují ve zdrojové a cílové IP adrese, zdrojovém a cílovém portu UDP nebo TCP, protokolu, rozhraní a stejně nastaveným bajtem Type of Service [6]. NetFlow záznam (Flow Record, NetFlow data): Podrobnější informace k danému IP toku. Jsou zde informace o délce toku, počtu přenesených bajtů, paketů a dalších. Exportér (Exporter): Zařízení (např. směrovač), které monitoruje procházející pakety a vytváří z nich IP toky. Informace z těchto toků jsou ve formě záznamů NetFlow odesílány do kolektoru. Exportovaný paket (Export Packet): Paket vytvářený exportérem, který obsahuje záznamy NetFlow. Je odesílán exportérem do kolektoru. 1 Internet Protocol Flow Information Export 10

15 NetFlow kolektor (NetFlow collector): Kolektor, který přijímá a zpracovává pakety z jednoho nebo více exportérů. Tyto pakety jsou pak ukládány na disk. Schéma fungování protokolu lze vidět na obrázku 4.1. Zde jsou na pozici exportérů směrovače Cisco. Ty vytvářejí toky, které jsou dedikovanou linkou posílány do kolektoru. Následně mohou být tato data zobrazena např. pomocí nástrojů nfdump 4.3 nebo nfsen 4.3. Obrázek 4.1: Princip fungování protokolu Princip fungování a vznik protokolu Kvůli urychlení přepínání na moderních přepínačích, které pracují na třetí vrstvě referenčního modelu ISO/OSI a využívají pokročilejší techniky při přepínání jako např. access list, byl přepracován systém vyrovnávacích pamětí na přepínačích a směrovačích Cisco. Začalo se využívat informací o sít ovém toku. Tento tok se shodoval ve zdrojové a cílové IP adrese a zdrojovém a cílovém portu, viz obrázek 4.2. Zařízení s podporou NetFlow síťový provoz analýza paketu zdrojová IP adresa cílová IP adresa zdrojový port cílový port L3 protokol TOS vstupní rozhraní Vyrovnávací paměť NetFlow Informace o toku Počet paketů Bajtů/paket adresy, porty Vytvoření toků z atributů paketu Obrázek 4.2: Princip vytváření toku [6] Vedlejším efektem byl zisk zajímavých statistik o sít ovém toku. Tyto statistiky byly rozšířeny a za cenu mírně vyšší režie při průchodu paketů jsou získávány informace, které mohou být použity k celkové analýze vytížení sítě, analýze provozu dat procházející jednotlivými uzly v síti atd. Vznikl tak protokol NetFlow. Postupně se přidávaly další aplikace, 11

16 které dokázaly s protokolem NetFlow pracovat a používat ho např. k účtování zákazníků za množství odeslaných dat nebo konektivitu. Protokol NetFlow vytváří pro všechny aktivní toky vyrovnávací pamět, která je vytvořena na základě přijetí prvního paketu daného toku. V této vyrovnávací paměti se postupně ukládají další informace o toku, které jsou později odeslány do kolektoru. Tyto exporty jsou prováděny jednou za čas podle nastavení zařízení, které export dat provádí. Export dat u protokolu NetFlow by měl být dostatečně efektivní a podle statistik by měl tvořit pouze 1,5 % [20] přenesených dat na směrovači. Ukončování toku a následný export se obvykle řídí podle následujících pravidel: Spojení TCP bylo uzavřeno, at už pomocí ukončení spojení (příznak FIN) nebo zrušení (příznak RST). Tok je po určitou dobu neaktivní. Tok trvá příliš dlouho (základní hodnota v nastavení je 20 minut). Zaplnění vyrovnávací paměti, hrozba přetečení čítačů. Ukončené datové toky se záznamy NetFlow jsou spojeny do paketu viz Exportovaný paket a odeslány do kolektoru. Tento paket může obsahovat až 30 záznamů NetFlow. Data se posílají jako datagramy UDP a po odeslání jsou exportérem zahozeny. Protože je protokol UDP bezestavový, může dojít ke ztrátě datagramu Ukládané informace V následující tabulce lze vidět, co vše protokol NetFlow ukládá a jaké informace tedy můžeme použít k následné analýze. Tato data lze získat pomocí nástroje nfdump 4.3 Date flow start Date flow end Duration Proto Src IP Addr:port Dst IP Addr:port TCP flags ToS inif, outif src AS, dst AS Packets pps bps Bpp Flows Čas, kdy byl tok poprvé zaznamenán. Ukládán ve formátu ISO 8601 včetně milisekund. Konec toku. Čas, kdy byl tok naposledy detekován. Ukládán ve formátu ISO 8601 včetně milisekund. Délka toku v milisekundách. Pokud jsou toky agregované, délka toku je součtem délek všech těchto toků. Protokol, který byl použit v daném toku Zdrojová adresa a port Cílová adresa a port Příznaky u paketu TCP (SYN,ACK aj.) Typ služby (Type of service) Zdrojové a cílové sít ové rozhraní Zdrojový a cílový autonomní systém Počet paketů v toku. Pokud jsou toky agregované tak jejich součet Počet paketů za sekundu: počet paketů / délka toku Počet bitů za sekundu: 8 * počet bajtů / délka toku Počet bajtů za paket: počet bajtů / počet paketů Počet toků. Pokud jsou toky jenom vypsány - vždy 1. Pokud jsou toky agregovány - součet toků 12

17 4.1.4 Architektura NetFlow Klasicky se předpokládá na pozici exportéra Cisco směrovač se zapnutou službou NetFlow. Směrovače pak potom kromě přeposílání paketů musí svůj výpočetní výkon věnovat také tvorbě statistik. Pokud směrovačem prochází vyšší datový tok, nemůže výpočetně zvládat zpracovávání každého paketu a zároveň generovat statistiky pro daný tok. Proto se provádí vzorkování, tedy pro výpočet statistiky se využívá pouze každý n-tý paket. Pokud záznamy NetFlow z těchto směrovačů slouží pouze pro sběr statistik, pak vzorkování nemá větší negativní vliv. Pouze snižuje přesnost. Pokud ale chceme zabránit bezpečnostním incidentům, je výběr pouze každého n-tého paketu problém. Problém se vzorkováním paketů řeší hardwarově akcelerované sondy NetFlow. Podrobnější popis sondy je v sekci Sonda NetFlow Sonda NetFlow je pasivním (data jsou pouze monitorována, nezasahuje se do nich) monitorovacím zařízením [22]. Je schopná monitorovat IP toky a posílat je do externích kolektorů. Pokud sondu zapojíme na linku, kterou chceme monitorovat, příchozí provoz je poslán přímo ke svému cíli a zároveň je kopie předána sondě ke zpracování. Pokud data odesíláme dedikovanou linkou přímo do kolektoru, je sonda neviditelná na linkové a vyšší vrstvě. Díky tomu je téměř vyloučen případný útok proti sondě. Použití této sondy místo směrovačů odstraňuje problém se vzorkováním paketů a přináší další výhody. Směrovače pak mohou svůj procesorový čas využít pouze k tomu, k čemu jsou určeny - směrování. Analýzou bylo zjištěno, že sonda zvládá na lince datovou propustnost 1Gbps bez ztráty paketů a bez ohledu na velikost paketů [10] Vlastnosti sondy: monitorování dvou 1Gbps portů přesný čas při analýze paketů aktivní časový limit - za jak dlouho se tok, který je považován za aktivní, musí odeslat do kolektoru neaktivní časový limit - umožňuje nastavit časový interval, za který bude tok klasifikován jako ukončený a odeslán do kolektoru export dat ve verzi NetFlow 5, verzi 9 nebo IPFX export dat na více kolektorů zároveň možnost nastavit vzorkovaní sběr statistik - získávání statistik o IP adrese, číslech portů, protokolech, počtech přenesených bajtů a paketů atd. 13

18 4.3 Nástroje Pro práci se záznamy NetFlow existuje celá řada nástrojů: nfdump (netflow dump) [4]: Nástroj pro čtení a zpracovávání dat NetFlow uložených pomocí nfcapd. Dokáže z těchto dat vytvářet statistiky. Napsán v C pro větší rychlost. Díky tomu dokáže filtrovat více než 4 milióny toků za vteřinu na 3GHz procesoru Intel [9], nebo vypočítat statistiku top N za 2.5s při 1,5 miliónů toků. Pracuje v příkazové řádce, podobný programu tcpdump. Podporuje záznamy NetFlow verze 5, 7 a 9. Lze použít filtrování podobné jako u libpcap nebo WinPcap, které používá např. tcpdump a wireshark. nfcapd (netflow capture deamon): Zaznamenává data NetFlow ze sítě a ukládá je do souborů. Dokáže pracovat se záznamy NetFlow verze 5, 7, 9. nfprofile (netflow profiler): Dokáže procházet soubory uložené pomocí nfcapd. Tyto soubory filtruje podle zadaných filtrů a ukládá pro pozdější analýzu. nfreplay (netflow replay): Čte soubory s daty NetFlow uložené pomocí nfcapd a posílá je po síti na jiný počítač. nfclean (netflow cleanup): Skript pro mazání starých dat. nfsen (netflow sensor): Jedná se o grafické rozhraní pro nástroj nfdump. Díky tomuto nástroji lze pomocí webových stránek jednoduše procházet uložená data z kolektoru. Dokáže z těchto dat zobrazit grafy pro jednotlivá rozhraní, protokoly, zvolit si časový úsek, za který budou grafy vykresleny, a další. Ukázka rozhraní je v příloze B Pro práci s daty NetFlow bude v této práci použit hlavně nástroj nfdump. 14

19 Kapitola 5 Skenování a NetFlow Skenovací nástroje jsou běžně používány pro analýzu sítě. Může je také ale použít útočník a informace získané z těchto skenování použít pro další útok. Pokud chceme toto skenování detekovat, je třeba analyzovat, co za pakety tyto nástroje používají. V laboratorních podmínkách jsem vyzkoušel skenování pomocí nástrojů nmap a EtherScope. 5.1 Skenování pomocí nmap Následuje příklad, jak se uloží data NetFlow při skenování pomocí nástroje nmap. Schéma 5.1 ukazuje zapojení sondy NetFlow v laboratoři. Můžeme si povšimnout, že sonda není zapojena přímo do přepínače. Je to z toho důvodu, že dané skenování bychom potom vůbec neodhalili. Na síti tvořené přepínači a směrovači se data posílají pouze od zdroje k cíli (pokud pomineme různé útoky jako arp cache poisoning, zaplnění CAM tabulky a jiné) a data by pro sondu nebyla vůbec viditelná. Obrázek 5.1: Schéma zapojení Pokud nyní provedeme skenování pomocí nástroje nmap, základním příkazem #nmap , a prohlédneme si, pomocí nástroje nfdump, co sonda zaznamenala, získáme údaje, které jsou vidět v tabulce

20 Date flow start Src IP Addr:Port Dst IP Addr:Port Flags Packets Flows :03: : :80...S :03: : :22...S :03: : :23...S :03: : :143...S :03: : :443...S :03: : :21...S :03: : : S :03: : : S. 1 1 Pro přehlednost byly z tabulky vypuštěny některé údaje. Jsou to informace o délce toku, typ protokolu, ToS 1 a počet bajtů. Jak lze vidět, je skenováno asi 1000 nejpoužívanějších portů. Tok se vždy zobrazuje jako jednosměrný provoz. Tedy tyto stejné toky dostaneme i v opačném směru, ale budou mít nastavené jiné příznaky u paketu TCP (příznak RST, odmítnutí spojení). Na první pohled lze vidět, že bylo použito skenování SYN. Toho můžeme při pozdějším návrhu využít. Další věc určující skenování je krátká délka toku a malý počet paketů v toku. Tyto informace bude třeba zpracovat a na základě nich se rozhodovat. Nástroj nfdump umožňuje i tvorbu filtrů. Jednoduchým filtrem, který můžeme použít na snadnější odhalení skenování SYN, by mohl být například filtr proto tcp and flags S and not flags ARFPU Tento filtr vypíše všechny TCP toky, které mají u paketu TCP nastavený pouze příznak SYN. Vyzkoušel jsem všechny typy skenování, které nmap poskytuje. Podrobněji jsou tyto techniky a principy, které používají k detekci portů, popsány v kapitole 3. Pokud se jedná o skenování SYN, tak je funkční, rychlé a spolehlivé. Skenování connect je pomalejší, ale pokud na daném zařízení nemá uživatel administrátorská oprávnění, je taktéž použitelné. U méně obvyklých technik jako skenování FIN a XMASS záleží na zařízení. Většinou ale zobrazí počet otevřených či filtrovaných portů. U skenování NULL jsem se spíše setkal s tím, že na ně sít ové zařízení vůbec neodpovědělo, přestože by u zavřených portů mělo generovat paket s příznakem RST. 5.2 Skenování pomocí EtherScope TM Series II Další skenovací zařízení, které jsem vyzkoušel v laboratoři je přístroj EtherScope [2]. Tento sít ový analyzátor skenuje celou sít. Sondu jsem zapojil přímo za toto zařízení, jak je vidět na obrázku 5.2, abych získal veškeré údaje o paketech, které toto zařízení posílá. Přibližná data lze vidět v následující tabulce Type of Service 16

21 Obrázek 5.2: Schéma zapojení II Duration Proto Src IP Addr:Port Dst IP Addr:Port Flags Packets Bytes Flows ICMP : : UDP : : ICMP : : UDP : : ICMP : : ICMP : : ICMP : : Z této tabulky byly odstraňeny údaje o času skenování a ToS. Tady vidíme, že zařízení EtherScope posílá převážně pakety ICMP a UDP. U těchto paketů nemůžeme provést filtrování jako u skenování SYN. Jsou to ale toky vesměs velmi krátké, s malým počtem paketů a krátkou dobou trvání. Tyto toky by se v síti neměly vyskytovat příliš často. Většina uživatelů používá připojení pro prohlížení webových stránek, komunikaci nebo mail a tam je trvání toků delší, s větším počtem paketů. Statistické výsledky, které zjišt ují, zda toto tvrzení je pravdivé, jsou probrány v kapitole 7 17

22 Kapitola 6 Práce s daty NetFlow v rozsáhlých sítích Objem dat NetFlow ukládáných směrovači nebo sondami NetFlow záleží na velikosti provozu sítě. Velikost exportovaných souborů se může pohybovat od několika MB v malých sítích do stovek MB ve velmi rozsáhlých sítích. V malých sítích mohou být použity pro vytváření záznamů NetFlow směrovače, které tento protokol podporují. Ve větších sítích s velkým datovým provozem to již ale není možné a je nutno zaznamenávat data pomocí hardwarově akcelerovaných zařízení, jako jsou např. sondy NetFlow 4.2. Ty bývají nasazované do sítí od velikosti padesáti zařízení. Často jsou nasazovány v sítích o zařízení. Následují banky, poskytovatelé připojení, státní instituce aj., kde se velikost sítě pohybuje v několika tisících zařízení. 6.1 Zdroj dat NetFlow Při zkušebním provozu sondy NetFlow zapojené v rámci vnitřní sítě FIT, byl ukládaný provoz minimální a nehodil se k žádné analýze. Pro podrobnější analýzu byla poskytnuta data z páteřní sítě VUT, která je připojena do akademické sítě CESNET. Tato data jsou získávána ze dvou externích 10Gb/s linek, které připojují sít VUT do CESNETu. Sběr dat je prováděn 10Gb/s kartami na provozu odbočeném prostřednictvím TAPu. TAP je hardwarové zařízení, které umožňuje monitorovat komunikaci mezi dvěma body. Zařízení má minimálně tři porty. Port pro monitorování a port pro každé monitorované zařízení. Veškerá probíhající komunikace mezi těmito body je pak zkopírována na monitorovací port. Data jsou ukládána jako hodinový záznam (dump) provozu. Toto je celkem nestandardní řešení, protože NetFlow exportér je standardně nastaven na pětiminutové exportování a toto dodržuje dle zkušeností z praxe většina firem. Dodaná data, s kterými jsem pracoval, nejsou kompletní data NetFlow. Chybí jim několik položek, např. příznaky u paketů TCP. Toto do značné míry ztěžuje vyhledávání skenování, protože nejvíce skenovacích útoků je skenování SYN [13]. Pokud bychom měli uloženy i příznaky, mohli bychom použít filtry, které by z toků vypsaly pouze ty s nastaveným příznakem SYN a tímto do jisté míry odhalit skenování. U ustanovení nového spojení TCP se sice také posílá paket SYN, ale tento paket má nastaven i příznak ACK a tedy by nezkreslil filtrované výsledky. Další podstatná chybějící položka je u protokolu ICMP. NetFlow dokáže u tohoto protokolu ukládat typ a kód paketu. Tyto položky ukládá jako zdrojový a cílový port. Tedy například u nejpoužívanější dvojice paketů Echo Request- 18

23 velikost souboru / MB :00 05:00 10:00 15:00 20:00 čas / hod Obrázek 6.1: Průměrná velikost souborů s NetFlow daty Echo Reply, používána příkazem ping, bude ve zdrojovém portu uložena 0 a v cílovém 8.0. Odpověd Echo Reply (typ 0) na dotaz Echo Request (typ 8, kód 0). Tento nedostatek, stejně jako chybějící příznaky u protokolu TCP, ztěžuje následné odhalení útoků, které těchto paketů ICMP využívají k zjištění živosti sít ových zařízení. Časem se však plánuje zakoupení sondy, která bude schopna exportovat plnohodnotné data NetFlow. Data jsou postupně ukládána na server od a zatím je možno analyzovat přibližně 740 GB dat. Přibližná velikost jednotlivých souborů a počet toků za hodinu lze vidět v grafu 6.1 a 6.2. U grafu 6.1 je vypočítaná průměrná velikost souborů za jednotlivé hodiny. Průměr je vypočítán z uložených záznamů za tři měsíce. V grafu 6.2 je počet toků vypočítán obdobně, jako průměrný počet toků za danou hodinu v daný den. Průměr je vypočítán také za tři měsíce záznamů. Zákazníci používající sondy NetFlow v ČR dosáhnou maximální propustnosti okolo 400 toků za sekundu. Jak lze vidět, počet toků dosahovaných v rámci páteřní sítě VUT je nejméně 1600 toků/s, běžně ale dosáhne 3500 toků/s. Zpracovávat takové množství dat je časově velmi náročné. Průměrnou dobu generování statistik na počítačích, které jsem používal, lze vidět v tabulce 6.1. Procesor/RAM Pentium-M 1.86 GHz / 1GB Intel Xeon 2.4 GHz / 3GB Průměrná doba vytvoření statistiky 22s 12s Tabulka 6.1: Průměrná doba zpracování Průměrná doba vytvoření statistiky je doba, za kterou se vytvoří statistika top 20 IP adres seřazených podle počtu toků z jednoho souboru, který obsahuje hodinový záznam provozu. Nástroj nfdump umožňuje procházet i více souborů najednou a generovat z nich globální statistiky. To je ale extrémně náročné na výpočetní zdroje a operační pamět. Doba pro vytvoření takové statistiky je v desítkách minut. 19

24 1.5e e e e+07 počet toků 1.1e+07 1e+07 9e+06 8e+06 7e+06 6e+06 5e+06 00:00 5:00 10:00 15:00 20:00 čas / h 6.2 Zpracování dat Obrázek 6.2: Průměrný počet toků za jednotlivé hodiny Z výše uvedených dob zpracování a velikostí dat lze stanovit určité postupy, jak budou data dále zpracována. Nabízejí se dvě možnosti. Ukládat data do relační databáze a pokusit se je zpracovat dotazovacím jazykem či nějakým rozšířením pro data mining u databáze Oracle, nebo se je pokusit zpracovat přímo pomocí skriptovacích jazyků. U relační databáze by se nejprve musel vygenerovat skript pro uložení dat, následně data nahrát do databáze a zpracovat, pravděpodobně jazykem PHP nebo podobným. U skriptovacích jazyků se data mohou zpracovat rovnou a pravděpodobně jsou ke zpracování vhodnější. U obou řešení se potýkáme s velkými objemy dat pro zpracování. Tento objem dat by mohl být snížen filtrováním. Abychom věděli, jaká data je možné odfiltrovat, jsou v kapitole 7 vytvořeny statistiky ze získaných dat, které by mohly pomoci s rozhodováním, která data jsou důležitá pro následné zpracování. 20

25 Kapitola 7 Statistika dat NetFlow v rozsáhlých sítích V rozsáhlých sítích s velkým počtem aktivních uzlů a několika tisíci spojeními za sekundu je obtížné vůbec získat plnohodnotná data NetFlow v poměru 1:1 1. Data jsou běžně vzorkována a hodí se hlavně pro statistické účely. Pokud jsou získávána kompletní data, lze v kapitole 6 vidět, že těchto dat je velké množství a zpracování není nejrychlejší. Můžeme se tedy pokusit podívat na data jako celek, zjistit jaké služby jsou v tocích dominantní, jaké jsou přenosy dat, atp. Na následujícím grafu 7.1 je vidět průměrné množství unikátních IP adres v průběhu dne. Tento graf bude posléze důležitý při návrhu zpracování dat pro odhalení skenování. Pokud bychom chtěli porovnávat jednotlivé záznamy mezi sebou, časová složitost takové operace by byla kvadratická O(n 2 ). U záznamu, který má 2 mil. unikátních IP adres za hodinu, by počet operací potom dosáhl 4 12, což je neúměrně náročné a musí být použit jiný přístup. 2.6e e e+06 počet unikátních IP 2e e e e e+06 1e+06 00:00 05:00 10:00 15:00 20:00 čas/hod Obrázek 7.1: Počet unikátních IP adres v toku Graf 7.2 ukazuje, kolik je průměrně vyměněno paketů v toku. V datech, ze kterých je 1 Je zaznamenán každý paket. Nedochází tedy ke vzorkování 21

26 1e+08 1e+07 1e Četnost e+06 Počet paketů v toku Obrázek 7.2: Frekvence počtu paketů v toku tento graf vygenerován, se vyskytovalo téměř 35 mil. jednopaketových toků, což představuje přibližně 55 %. Toky do 3 paketů pak tvořily přibližně 80 % všech toků. Díky této statistice se výrazně změnilo tvrzení, které jsme uvažovali v kapitole 5, tedy že krátkých toků bude malé množství. Pokud se na toky podíváme z hlediska služeb, nenalezneme příliš překvapivé výsledky. Dominantní službou je protokol HTTP, HTTPS. U UDP je to protokol DNS. Co se týče přenesených dat, zde je dominantní tunelovací protokol GRE 2 od firmy Cisco. Počet toků u služeb Počet bytů u služeb DNS 2.7% ICMP 4.0% HTTP 9.2% HTTPS 1.7% SSH 0.3% dynamic ports 1.6% HTTPS 0.4% HTTP 1.7% GRE 2.9% rest of 93.1% rest of 82.3% Obrázek 7.3: Statistika jednotlivých služeb Z následujících grafů 7.3 se může zdát, že tyto služby jsou zastoupeny v mizivém množství. Je třeba si ale uvědomit, že celkové množství portů je Tedy součet všech ostatních toků a bajtů proudící na ostatní porty je samozřejmě větší. Položka dy- 2 Generic Routing Encapsulation 22

27 namické porty znamená porty od výše. Tyto porty se ve statistice mění každý den a pravděpodobně to budou vytvořené tunelovací spoje. To usuzuji za předpokladu, že tyto dynamické porty mají velice podobný poměr počtu toků ku přeneseným bajtům. Jako další významná položka z hlediska počtu toků je protokol ICMP. Předpokládám, že většina těchto toků jsou pakety ICMP Echo-Request a Echo-Replay, ale z důvodů uvedených v kapitole 6 to nelze přesně určit. Pokud jsem zkoumal data, která byla k dispozici od firmy Invea, lze v tocích ICMP pozorovat také hodně paketů kódu 3 - Destination unreachable. Přesto Echo pakety převažují. V tabulce 7.1 lze vidět přibližný poměr toků a bajtů u nejfrekventovanějších služeb. Tato statistika je generována za čtyř hodinový provoz v nejfrekventovanější denní dobu. Za tyto čtyři hodiny bylo v přibližně 77 mil. tocích přeneseno 1,2 TB dat. Lze vidět, že pomocí tunelovacího protokolu se přenáší velké množství dat, ale počet toků je velice malý, díky velice dlouhému trvání spojení. U protokolu HTTP je naopak přeneseno velké množství bajtů při několikanásobném množství toků. Proto jsem výše usoudil, že dynamické porty, které se objevují ve statistikách budou pravděpodobně další tunelovací protokoly, jako např. VPN. Protokol Počet přenesených bajtů Počet toků GRE 31.6 GB 7694 HTTP 18.4 GB 7.1 mil. dynamic ports 15 GB 7318 SSH 3.6 GB Tabulka 7.1: Poměr přenesených bytů k počtu toků U skenování se připojuje útočník na jednotlivé porty zařízení, které skenuje. Pokud skenuje např. pomocí základního nastavení skeneru nmap, testuje u jednoho počítače tisíc portů. Bylo by tedy zajímavé zjistit, na kolik portů se v reálném provozu průměrně uživatel připojuje. Toto lze vidět na grafu 7.4. Lze vidět, že průměrně se uživatel připojuje na velice malé množství portů. V 80 % případů je to dokonce pouze jeden port. 1e+07 1e Četnost Počet navštívených portů Obrázek 7.4: Frekvence počtu navštívených portů Stejně tak jsem vytvořil statistiku počtu toků za jednotlivé IP adresy. Graf 7.5 je vy- 23

28 tvořen z 26,3 mil. toků, ve kterém bylo 2,6 mil. unikátních IP adres. Počet IP adres, které vytváří pouze jeden tok je sice největší, ale z celkového množství je to pouze okolo 6 %. Je totiž daleko více IP adres, které mají větší množství toků. 1e+07 1e Četnost e+06 Počet toků na IP Obrázek 7.5: Frekvence počtu toků za IP adresu 24

29 Kapitola 8 Analýza získaných dat a návrh aplikace V předcházejících kapitolách jsem vytvořil řadu statistik, které popisují provoz v síti. Ze získaných údajů je nyní nutné vybrat základní prvky, díky kterým bude možno odhalit skenování i v takto rozsáhlé síti. Dále je nutno zodpovědět otázky týkající se samotné aplikace. Následuje shrnutí nejpodstatnějších údajů. 8.1 Shrnutí získaných statistik Unikátní IP adresy: V provozu jsem zjistil velký počet unikátních IP adres. Běžně je to kolem 2 mil. adres za hodinu. Každá adresa se samozřejmě připojuje v libovolný čas a v záznamu se tedy vyskytuje tisíce toků se stejnou IP adresou. Pokud bych chtěl na základě IP adresy toky analyzovat, musel bych pro každou IP adresu projít celý záznam. Navštívené porty: Pokud jsem sledoval průměrný počet navštívených portů u IP adresy, v 80 % případů je to pouze jeden port. Jak již bylo zmíněno, u skenování se útočník připojuje k velkému množství portů nebo k jednomu, ale na velkém množství počítačů. Počet paketů v toku: U skenování je využíváno především skenování SYN, které používá pouze jeden paket. Toků, které obsahují pouze jeden paket, je ale více než polovina. Tato situace je tedy podobná jako u unikátních IP adres. Množství dat: Záznamy v hodinových dumpech provozu obsahují velké množství dat. Zpracovávat tato data je pak časově náročné. Je nutné si uvědomit, že i kdyby byla k dispozici velká výpočetní síla a nebyl bych omezen pamětí apod., analyzovat data delší časový úsek je bezpředmětné. Skenovací útok často předchází útok jiný a je tedy výhodné na něj rychle reagovat a dalším útokům tak zabránit. Také je ale důležité si uvědomit, že výsledky, zda došlo v reálném provozu ke skenování, nemohu odhalit ihned. Záznam NetFlow nemůže exportér odesílat každou sekundu, protože by zahltil sít. Standardně je posílán po pěti minutách. Co z výše uvedených bodů vyplývá? U dat by bylo vhodné se pokusit odfiltrovat ta data, o kterých jsme přesvědčeni, že neobsahují podezřelou aktivitu a zmenšit tak objem dat k dalšímu zpracování. Problém u filtrování je ten, že dat, která jsou pro odhalení 25

30 skenování nejdůležitější, je nejvíc. Ve většině případů jsou to totiž krátké, několikapaketové toky, tedy stejná data, jaká posílají nástroje pro skenování portů. Odfiltrováním delších toků sice zmenším částečně objem, ale 80 % dat mi stejně zůstane a řeším stejný problém. Čas na zpracování dat aplikací musí být přinejhorším stejný, jako čas, za který se vytváří záznamy. Pokud jsou záznamy posílány do kolektoru v desetiminutových intervalech, nelze data zpracovávat déle než 10 minut. Zpracování by ale mělo trvat podstatně kratší dobu. Odhalit všechna skenování v síti, která má milióny spojení za hodinu, je nemožné. Pokud bude útočník skenovat pouze několik počítačů a portů, je to v takto objemných datech neodhalitelné. Toto ale ani není požadavkem. U takto velkých sítí je cílem odhalit útočníky, kteří provádí horizontální skenování celých podsítí, případně velké blokové skenování. Zaměřme se tedy na horizontální skenování. Pro toto skenování platí: Používá jedno až dvou paketové toky Skenuje velké množství IP adres Toky trvají krátce. Délka skenování závisí na počtu IP adres. Počet bajtů je stále stejný Protože v hodinovém záznamu o provozu jsem nedokázal efektivně odhalit žádné útoky, zaměřil jsem se na omezení velikosti zpracovávaných dat. Jak jsem ukázal v kapitole 7, velký počet toků na IP adresu je relativně malý. Skenování trvá také relativně krátkou dobu. Za tuto krátkou dobu ale vytvoří útočník velké množství toků. Omezil jsem si tedy hodinový záznam na nejkratší rozumný pětiminutový záznam. Pokud se v tomto krátkém časovém úseku objeví útočník, měla by nastat následující situace: 1. Útočník vytvoří velké množství spojení. Toto by se mělo projevit ve statice toků na základě zdrojové IP adresy. 2. Toky útočníka by měly vykazovat stejný počet paketů, stejný počet bytů a krátkou dobu trvání. 3. Legitimní uživatelé by neměli podle získaných statistik vytvářet velké množství toků. 4. Servery, které obsluhují hodně klientů, vytváří také hodně toků. V těchto tocích by ale počet paketů měl kolísat, stejně tak počet přenesených bajtů. Z výše uvedených úvah jsem postupoval následujícím způsobem. 1. Z pětiminutového toku je vytvořena statistika o nejfrekventovanějších IP adresách na základě počtu toků. 2. U každé IP adresy je vyfiltrován záznam o všech jejích tocích v daném časovém intervalu. 3. Tento záznam je zpracován pomocí rozhodovacího algoritmu. 4. Výsledky jsou zobrazeny na standardní výstup. 26

31 8.2 Rozhodovací algoritmus Pro rozhodování, zda daný tok je, nebo není součást skenování, je vhodné použít techniky pro strojové učení a dolovaní z dat. Při dolování z dat se zde uplatní hlavně analytická metodologie, při které se používají rozhodovací stromy, neuronové sítě nebo genetické programování. Pro tuto práci jsem usoudil, že bude nejvhodnější použít rozhodovací strom generovaný algoritmem ID3 1 [16]. Rozhodovací stromy jsou induktivní algoritmy vytvořené ke klasifikaci instancí. Můžeme je použít, když jsou instance popsány atributy a hodnotami (např. VLHKOST: normální, vysoká) a cílová funkce nabývá diskrétních hodnost (např. ANO / NE). Trénovací data mohou obsahovat i chyby a také nemusí obsahovat hodnoty všech atributů. Cílová funkce je reprezentována rozhodovacím stromem (sekvencí rozhodnutí if-then-else). Klasifikace se provádí průchodem stromem od kořene k listům, kdy se testuje hodnota jednoho atributu instance pro každý uzel. Každá hrana odpovídá jedné hodnotě. Každý list pak určuje klasifikaci instance. U ID3 algoritmu vytváříme na základě trénovacích dat rozhodovací strom. Strom se vytváří od kořene. V každém uzlu se zjišt uje, který atribut je pro právě tento uzel nejvhodnější. Počet potomků odpovídá počtu hodnot vybraného atributu. Trénovací data se rozdělí podle příslušné hodnoty atributu na příslušné podmožiny. Algoritmus pracuje rekurzivně v následujících krocích. Příklad vytvořeného rozhodovacího stromu můžeme vidět na obrázku 8.1. U tohoto příkladu je strom použit k rozhodnutí, zda mám nebo nemám jít hrát golf. Předpověď Slunečno Zataženo Déšť Vlhkost ANO Vítr Vysoká Normální Silný Slabý NE ANO NE ANO Obrázek 8.1: Příklad rozhodovacího stromu 1 Iterative Dichotomiser 3 27

32 ID3(Trénovací data, Cílový atribut, Atributy) 1. Založ Kořen stromu 2. Pokud jsou všechna Trénovací data pozitivní, vytvoř jednouzlový strom s kořenem označeným + 3. Jsou-li všechna Trénovací data negativní, vytvoř jednouzlový strom s kořenem označeným - 4. Je-li množina atributů Atributy prázdná, vrat jednouzlový strom s kořenem označeným nejčastější hodnotou cílového atributu v trénovacích datech 5. Jinak: Vyber atribut A, který nejlépe klasifikuje trénovací data, Kořen = A 5.1 Pro každou jeho možnou hodnotu vytvoř novou větev 5.2 Vytvoř Podmnožina vi z trénovacích dat, pokud A = v i 5.3 Je-li Podmožina vi prázdná, pod danou větví založ list stromu označený nejčastější hodnotou cílového atributu v trénovacích datech 5.4 Jinak přidej pod větev podstrom ID3(Podmnožina vi, Cílový atribut,atributy - A) 6. Vrat výsledný podstrom Výběr nejlepšího atributu probíhá na základě entropie (zisku informace) [7]. Necht X je náhodný jev, jenž může nabývat hodnot x 1, x 2,..., x n s pravděpodobnostmi p(x 1 ), p(x 2 ),..., p(x n ) n a necht je p(x i ) = 1. Pak entropie jevu X je i=1 H(X) = n p(x i ) log 2 p(x i ) i=1 Kritérium očekávaného zisku můžeme definovat jako míru očekávaného snížení entropie po rozdělení trénovacích dat podle hodnoty vybraného atributu [23]. Tedy informace, kterou nám přináší znalost hodnoty atributu. Formální zápis potom ukazuje rovnice 8.1: Gain(D, A) H(D) v V alues(a) A - atribut; A(d) - hodnota atributu A v instanci d V alues(a) - množina všech možných hodnot atributu A D - trénovací data D v - trenovací data taková že: D v = {d D; A(d) = v} D v D H(D v) (8.1) 28

33 Trénovací data Pro klasifikaci, zda tok je nebo není součástí skenování, jsem vytvořil následující sadu pravidel. Popis atributů: Cílová IP: malý rozdíl v rozsahu: Tato hodnota znamená, že IP adresy jdou postupně za sebou v jedné podsíti. Např , atd. stejná: Stejná IP adresa ve dvou po sobě následujících tocích rozdílná: IP adresa je z rozdílných podsítí Cílový port: rozdíl < 5: Podobně jako u IP adresy tato hodnota atributu určuje, zda porty jdou postupně za sebou. stejný: Porty po dvou po sobě jdoucích tocích jsou shodné. rozdílné: Dva po sobě jdoucí toky mají rozdílné porty. Počet paketů: < 5: Tok obsahuje méně než pět paketů. > 5: Tok obsahuje více než pět paketů. Počet bytů: stejný, nebo dvojnásobný nebo poloviční: Tok má stejný, nebo dvojnásobný nebo poloviční počet bajtů jako tok předcházející. rozdílný: Rozdílný počet bajtů ve 2 tocích. Cílová IP Cílový port Počet paketů Počet bajtů Skenování malý rozdíl v rozsahu stejný < 5 stejný, nebo 2x nebo 1 2 ANO stejná rozdíl < 5 < 5 stejný, nebo 2x nebo 1 2 ANO rozdílná rozdílný < 5 rozdílný NE stejná rozdílný < 5 rozdílný NE stejná rozdíl < 5 > 5 rozdílný NE malý rozdíl v rozsahu rozdíl < 5 < 5 stejný, nebo 2x nebo 1 2 ANO rozdílná rozdíl < 5 > 5 rozdílný NE rozdílná rozdílný > 5 stejný, nebo 2x nebo 1 2 NE stejná stejný > 5 rozdílný NE malý rozdíl v rozsahu rozdílný > 5 rozdílný NE malý rozdíl v rozsahu rozdíl < 5 < 5 rozdílný ANO stejná rozdíl < 5 < 5 rozdílný ANO Tabulka 8.1: Trénovací data pro ID3 algoritmus 29

34 Z tabulky 8.1 jsem vytvořil množinu trénovacích dat. Algoritmus pro vytvoření rozhodovacího stromu jsem vytvořil v jazyce python. Části algoritmu jsou převzaté z [18]. Po vytvoření rozhodovacího stromu jsem zjistil, že z hlediska očekávaného zisku jsou důležité pouze atributy Počet paketů a Cílový port. Tím by ale nebylo moc možností, jak ovlivnit citlivost detekce. Doplnil jsem tedy i další atributy. Část větve výsledného stromu je na obrázku 8.2 Pakety > 5 > 5 Porty NE rozdíl < 5 = rozdílný IP IP IP = < 5 rozdílná... Počet bajtů Počet bajtů Počet bajtů... =!= ANO Podezřelé Obrázek 8.2: Část ID3 stromu 30

35 Kapitola 9 Implementace 9.1 Popis implementace Uložená data NetFlow zpracovávám pomocí několika skriptů implementovaných pomocí skriptovacích jazyků Bash a Python. Vytvářet univerzální aplikaci je náročné z několika hledisek. Data mohou být umístěna na různých systémech rozdílně. Toto lze částečně řešit konfiguračním souborem, kde nastavíme výchozí adresáře. Ty ale mohou mít rozdílnou adresářovou strukturu, rozdílný způsob pojmenování, atd. Vytvořil jsem několik skriptů, které spojuji do většího celku. Důvodem, proč jsem vytvářel malé, jednoúčelové skripty, je větší univerzálnost. Data z páteřní sítě VUT tvoří záznamy hodinového provozu. Tyto záznamy potřebuji rozdělit na pětiminutové, ale jiné systémy mohou ukládat data již v požadovaném časovém rozsahu. Proto může být většina skriptů vynechána a správce použije pouze ty, které potřebuje pro analyzování dat. Sadu skriptů jsem tedy vytvořil s ohledem na univerzálnost, ale primárně pro zpracování dat ze sítě VUT. Pro zpracování na jiných systémech bude pravděpodobně potřeba je překonfigurovat, případně přizpůsobit. Data na serveru VUT jsou uložena v této adresářové struktuře: /data/netflow/cesnet.anonymized/yyyy-mm-dd/nfcapd.yyyymmddhhmm kde yyyy = rok, mm = měsíc, dd = den, hh = hodina(24h/den), mm = minuta. Tyto soubory jsou hodinové záznamy provozu. Nejdříve je nutné je rozdělit na pětiminutové záznamy. Příklad rozdělení hodinového souboru na pětiminutový. nfdump -r /cesta/netflow -t 2009/01/01.00:00: /01/01.00:04:59 \ -w /kam/ulozit/ r: určuje zdroj NetFlow dat -t: filtruje data pouze podle časového okna zadaného jako parametr -w: soubor ukládá jako NetFlow záznam do požadovaného adresáře (v základním nastavení jsou záznamy vypsány na standardní výstup a nemohou být zpracována znovu pomocí nástroje nfdump) Schéma volání skriptů je na obrázku 9.1. Pro rozdělení hodinových záznamů NetFlow slouží skript split.sh. Pomocí nástroje nfdump jsou tyto záznamy rozděleny na menší o požadované délce. Tento skript dále spouští 31

36 Soubor NetFlow s hodinovým záznamem síťového provozu split.sh Skript rozdělí daný hodinový záznam na pětiminutové soubory NetFlow pětiminutový záznam síťového provozu vytvoř statistiku topn Skript vygeneruje statistiku topn. Z souboru s daty NetFlow vyfiltruje záznam o komunikaci pro jednotlivé IP adresy. main_skript.sh seznam IP adres parseip.py Skript získá ze statistiky IP adresy, s počtem toků tisíc a víc záznam o síťové komunikaci jedné IP adresy detectscan.py Skript analyzuje záznam o komunikaci. Výsledek detekce je přidán do logu pro daný den. Zápis do souboru Obrázek 9.1: Schéma volání skriptů skript main skript.sh, kterému předá v argumentech název pětiminutového souboru, datum a čas, ze kterého je tento souboru vytvořen. To je nutné, pokud běží více procesů a skript split.sh rozdělil data z jedné hodiny. Tato data ale ještě nebyla zpracována; data by se přepisovala. Skript main skript.sh vytváří z daného souboru statistiku topn podle nejfrekventovanější IP adresy, seřazené podle počtu toků. Samotný nástroj nfdump umožňuje si definovat vlastní formát výstupu. Toto funguje správně. Problémem je, že nelze nadefinovat vlastní formát výstupu u tisku statistik, i když podle dokumentace by to mělo být možné. Program tento formát nebere na vědomí a zobrazuje výsledek v základním nadefinovaném formátu. Musel jsem proto vytvořit skript printip.py, který dané IP adresy vyfiltruje. Výsledek předá pomocí roury zpět skriptu main skript.sh. Ten na základě těchto IP adres uloží provoz jednotlivých IP adres do souborů. Provoz je ukládán jako text, aby mohl být zpracován dalším skriptem. Pro ukládání provozu dat používám předdefinovaný formát pipe, který jednotlivé položky odděluje znakem. Příklad záznamu provozu u IP adresy Jednotlivé položky jsou popsány v příloze A. Soubor se záznamem o provozu je následně zpracován skriptem detectscan.py. V tomto skriptu je rozhodovací strom ID3 transformován na sadu if-then-else pravidel. Soubor s provozem je načten do paměti. Tok, který prochází stromem, se vždy porovnává s předcházejícím tokem. Pro podrobnější nastavení jsou k dispozici čtyři váhy. Tyto proměnné určují váhu jednotlivých větví při průchodu stromem. Jednotlivé váhy se týkají počtu paketů, IP adresy, počtu bajtů a cílového portu. Váhy jsou na základě průchodu toku stromem sčítány. Pokud se dva porovnávané toky nebudou shodovat např. v počtu bajtů, váha počtu bajtů nebude do výsledné váhy připočtena. Výsledná váha tak nebude maximální, ale díky velké shodě v ostatních položkách tento tok bude pořád 32

37 podezřelý. Výslednou vahou se vynásobí krok prahu. Ten se vypočte jako 100/počet toků dané IP. Dojde tak k tomu, že pokud každý tok IP adresy splní všechna podezření, že je součástí skenování, výsledný práh bude roven hodnotě 100. Částečně podezřelé toky pak tuto hodnotu snižují. Výsledný práh je následně zanalyzován. Empirickou cestou jsem pak stanovil hranici prahu > 70. Pokud tedy výsledný práh odpovídá této hodnotě, je provoz z dané IP adresy považován za skenování. Do logu jsou potom zapsány statistické informace o daném skenování. Příklad detekovaného skenování a jeho záznamu v logu. Ukládané položky jsou: IP adresa start konec práh počet IP port součet Tabulka 9.1: Ukládané údaje o skenování Význam jednotlivých položek: IP adresa: IP adresa útočníka. start: Začátek skenování, formát času - UNIX. konec: Konec skenování, formát času - UNIX. práh: Celkový vypočítaný práh. počet IP: Počet skenovaných IP adres. port: Který port byl skenován. součet: Kolikrát byl daný port skenován. Pokud bylo detekováno více portů, jsou ukládány postupně za sebou ve formátu číslo portu kolikrát byl skenován 9.2 Čas zpracování V reálném provozu předpokládám následující použití. Data budou ukládána v pětiminutových intervalech. Skript pro detekci bude spouštěn v těchto intervalech na nově vytvořené soubory. Výsledky analýzy mohou být poslány na , nebo zobrazeny ve webovém rozhraní. Další možností je propojit tento detekční systém se skriptem, který bude automaticky generovat pravidla pro firewall. Možností je celá řada a záleží na správci sítě, co bude požadovat. Doba zpracování jednotlivých souborů závisí na provozu v síti. Z dat, které mám k dispozici, obsahuje pětiminutový záznam přibližně 1.5 mil. toků. Vytvoření celé statistiky u takového souboru trvá přibližně 10 sekund. Vytvoření pětiminutového záznamu trvá přibližně 33

38 15 sekund. Analýza dat jednoho dne trvá přibližně hodiny. Záleží na množství dat a na počtu adres, ze kterých se generuje statistika topn, tedy u kolika IP adres se kontrolují všechny toky. 34

39 Kapitola 10 Výsledky analýzy Pomocí implementovaných skriptů jsem provedl zpětně analýzu na anonymizovaných datech. Výsledkem jsou záznamy (logy), ve kterých jsou zaznamenány bezpečnostní incidenty za jednotlivé dny ve formátu jak ukazuje tabulka 9.1. Bezpečnostní incident je jeden záznam v souboru. Pokud se skenování opakuje delší dobu, bude toto skenování zaznamenáno vícekrát. Provedl jsem analýzu za měsíce leden a únor. Celkem bylo analyzováno 393,7 GB dat. Díky problému ve skriptu, který ukládal data NetFlow na serveru, nejsou u dalších měsíců uložena kompletní data. Chybí např. několik hodin záznamů za den, u některých dnů nejsou uloženy záznamy vůbec. Pokud by se z těchto nekompletních dat generovala statistika, byly by výsledky oproti měsícům leden, únor zkreslené a neporovnatelné. V příloze C je výběr několika detekovaných IP adres a ukázka komunikace, která byla získaná z dat NetFlow. Počet všech bezpečnostních incidentů za jednotlivé měsíce a nejčastěji skenované porty jsou zobrazeny na obrázku 10.1 a Jednotlivé položky jsou popsány v tabulce Počet incidentů Obrázek 10.1: Počet skenování za měsíc leden 35

40 Počet skenování dns cap 1027 http icmp telnet ms-sql-s board-voip ssh ssc-agent Obrázek 10.2: Nejčastěji skenované porty za měsíc leden Počet incidentů Obrázek 10.3: Počet skenování za měsíc únor Jak lze vidět, počet bezpečnostních incidentů je relativně vysoký. Pokusil jsem se tedy zjistit, zda jsou tyto výsledky pravdivé a detekované bezpečnostní incidenty jsou opravdu skenováním. U anonymizovaných dat nelze určit, komu odpovídá jednotlivá IP adresa. Skripty byly 36

41 Počet skenování dns cap microsoft-ds 1027 http icmp telnet ms-sql-s ssh ssc-agent Obrázek 10.4: Nejčastěji skenované porty za měsíc únor Protokol Port Popis ICMP Protokol ICMP, pravděpodobně ping cap , 1027 Calendar Access Protocol. Pravděpodobně pokus o spam pomocí služby Windows Messenger [21] http 80 Protokol HTTP dns 53 Protokol DNS board-voip 9750 Board M.I.T. Synchronous Collaboration ms-sql-s 1433 Microsoft-SQL-Server telnet 23 Protokol Telnet ssh 22 Protokol SSH ssc-agent 2967 Symantec System Center. Pravděpodobný pokus o zneužití chyby v programu Symantec AV Corp. [3] Tabulka 10.1: Popis nejčastěji skenovaných portů pro testovací účely tedy spuštěny nad jednodenním záznamem neanonymizovaných dat. Mohly být tedy dohledány jednotlivé IP adresy a zjištěny některé další informace o zařízení, které by umožnily určit, zda se nejedná o falešný pozitivní alarm. Ukázalo se, že detekované IP adresy opravdu byly skenovány, nebo skenování používaly. Nabízí se otázka, jak tyto výsledky reálně zpracovat, aby byly přínosem pro bezpečnost v dané síti. Dosažené výsledky byly konzultovány se správcem páteřní sítě VUT Ing. Tomášem Podermańskim. Získané poznatky z případného praktického uplatnění jsem shrnul v následujících bodech. Nelze provádět blokaci detekovaných IP adres. Blokace je obecně velice problematická, protože čelím několika problémům. 37

42 Délka blokace: Nelze rozumně určit délku blokování. Krátké blokování pravděpodobně nebude příliš efektivní. Dlouhá blokace zase komplikuje průchod filtrovacími pravidly na firewallu. Detekovaných IP adres je velké množství, firewall by tedy musel procházet velké množství pravidel. Podvrh adresy: Zdrojová IP adresa (tedy IP adresa útočníka) může být podvrhnuta. Pokud bych přistoupil k blokování, zablokuji neprávem přístup legitimnímu uživateli. Blokace zařízení PAT: Může se stát, že skenování sítě procházelo přes zařízení sloužící pro překlad adres. Pokud bych zablokoval IP adresu tohoto zařízení, můžu tím zablokovat přístup velkému počtu legitimních uživatelů. Při blokování pak v praxi vznikají nedeterministické chyby. Zákazníkovi občas něco funguje, občas ne. Tyto chyby se velice těžko odhalují a opravují. Na skenování mířící do vnitřní sítě VUT nelze z výše uvedených důvodů adekvátně reagovat. Pokud je ale detekováno skenování ze sítě VUT, lze už tento počítač vyhledat, zjistit, kdo je za něj zodpovědný a proč ke skenování došlo. Z tohoto důvodu jsou informace o skenování ze sítě VUT směrem do Internetu významnější. Lze tedy vidět, že reakce na detekované skenování je velice problematická. Pokud někdo skenuje sít VUT, nelze na to ve většině případů adekvátně reagovat. Blokace z výše uvedených důvodů nepřipadá ve většině případů v úvahu. Porty bývají blokované pomocí firewallu a jediné čeho tak útočník dosáhne je automatické uzavření spojení TCP. Bylo tedy navrhnuto řešení, které by mělo praktický přínos pro bezpečnost sítě. Budou detekována pouze ta skenování, která pochází ze sítě VUT. Díky tomu bude možno dohledat problematické počítače a sjednat nápravu. Tyto údaje budou uloženy do již implementovaného systému, který se v současnosti používá ke získání informací z počítačů, které fungují jako honey-pot. Tyto informace jsou pak předkládány správcům jednotlivých areálů, kteří na základě těchto informací adekvátně reagují na zjištěné hrozby. 38

43 10.1 Výzkum ve světě Neustála potřeba zvyšovat zabezpečení sítě vede ke snaze použít pro zvýšení bezpečnosti nové technologie, např. NetFlow. V konferencích je publikována celá řada článků, která se zabývá výzkumem, jak tento protokol a získaná data využít pro bezpečnost sítě. Jedním ze způsobů je snaha o vizualizaci dat NetFlow ve formě grafů a následnou analýzou zjistit bezpečnostní chyby [12]. Dalším způsobem využití záznamů NetFlow je klasifikace sít ových skenování do nových kategorií. Některé škodlivé programy provádí skenování, které spadá do určitých kategorií a tak lze do jisté míry odhalit bezpečnostní incidenty v síti [11]. Převážně je ale snaha využít tuto technologii v systémech NIDS a NIPS. Většina těchto řešení používá pro analýzu útoků detekci anomálií. Příkladem může být český prototyp systému NIDS, CAMNEP [17]. Je vyvíjen Českým vysokým učením technickým a Masarykovou univerzitou. Tento systém používá data NetFlow získaná z více bodů v síti. Data jsou následně analyzována pomocí agentů, kde každý agent používá jinou funkci pro detekci anomálií. Výsledkem je míra důvěry v daný tok. Následně lze toky podle získaných hodnot filtrovat a vizualizovat. Protokol NetFlow je relativně nová technologie, která není ve velkých sítích zatím moc rozšířená. Tyto sítě pro kvalitní a úplná data NetFlow potřebují hardwarové sondy NetFlow, aby zamezily vzorkování a zátěži směrovačů. Díky těmto sondám se ale tato technologie stále více rozšiřuje. Ukládaná data NetFlow obsahují množství informací o provozu v síti. Je tedy snaha použít tato data pro zvýšení bezpečnosti sítě a navrhnout kvalitní NIDS, který by na základě těchto dat byl schopen detekovat útoky i ve vysokorychlostních sítích Možná rozšíření Protože protokol NetFlow je uzavřený protokol a funguje pouze na Cisco zařízeních, je možné použít jiný standard pro monitorování sítě. Nabízí se použít standard sflow. Tento monitorovací standard je jednodušší než protokol NetFlow. Je implementován na více zařízeních. Většina přepínačů tento standard podporuje a je tedy více rozšířený. Díky tomu by data mohla být získávána z více míst v síti. Nevýhody standardu sflow ale pravděpodobně převažují. sflow používá vzorkování paketů. Jak bylo zmíněno v kapitole 7 a 4 je toto u bezpečnostní analýzy nežádoucí. Podle zkušeností z praxe jsou pak zařízení, které mají zapnuté zaznamenávání statistik pomocí sflow a prochází jimi větší datový tok, velice nestabilní. Přesto je to jedna z možností, která by mohla být užitečná a rozšířila by funkcionalitu tohoto projektu. Časem bude také pro sít VUT dodána hardwarově akcelerovaná sonda NetFlow, pomocí které budou získávány plnohodnotná data NetFlow. Bylo by tedy vhodné implementované řešení otestovat na těchto datech a doplnit zpracování příznaků u paketů TCP a jednotlivých kódů u paketů ICMP. Dalším rozšířením by mohlo být samostatné webové rozhraní, optimalizace algoritmu a případné použití algoritmů pro detekci anomálií. Dalším rozšířením by mohla být detekce útoků na odepření služby. 39

44 Kapitola 11 Závěr V úvodních části diplomové práce jsem se zabýval převážně teoretickou částí. Nastudoval jsem protokol NetFlow, údaje o sondě NetFlow a seznámil jsem se s nástroji, které jsou potřebné k práci s daty NetFlow. Dále jsem nastudoval problematiku skenování zařízení v síti. Seznámil jsem se s různými typy skenování jak u protokolu TCP, tak UDP. Nutnost byla nastudovat manuály a informace o skenovacích nástrojích jako je nmap, nessus a o přístroji EtherScope. V laboratoři jsem za pomoci těchto nástrojů a sondy NetFlow oskenoval zařízení v síti a analyzoval získané údaje ze sondy. V praktické části diplomové práce jsem analyzoval data z páteřní sítě VUT. Z těchto dat jsem vytvořil statistiky, které umožňují detailnější pohled na fungování sítě. Na základě těchto statistik jsem implementoval sadu skriptů, díky kterým jsem schopen v datech NetFlow detekovat pokusy o skenování. Pro analýzu toků je použita technika pro data-mining - rozhodovací strom. Dosažené výsledky byly konzultovány se správcem páteřní sítě VUT, byla diskutována omezení, které vyplývají z praxe a byly navrženy úpravy skriptů, aby se výsledky daly reálně využít pro zajištění větší bezpečnosti sítě VUT, např. omezení detekování skenování pouze z vniřní sítě. V diplomové práci jsem dokázal i z nekompletních, anonymizovaných dat NetFlow detekovat skenování sítě. Ve vysokorychlostních sítích, jako je sít VUT, je těchto útoku velké množství. Reakce na tato skenování není triviální a je probrána v kapitole 10. Zpracování získaných dat tedy závisí na správci sítě, který určí důležitá data z hlediska bezpečnosti dané sítě. Detekovaná skenování lze také použít pro odhalení škodlivých programů. Většina těchto programů při šíření se síti skenuje danou podsít a tato skenování by byla implementovanými skripty detekována. Tato práce může být přínosem pro velké akademické sítě nebo pro poskytovatele připojení, kde detekované údaje mohou být použity pro zvýšení bezpečnosti dané sítě. V kapitole 9 je popsána konkrétní implementace pro sít VUT. Možnosti rozšíření jsou popsány v

45 Literatura [1] Tenable Network Security. [online], , [cit ]. URL [2] Portable Gig and a/b/g wireless LAN testing, analysis and throubleshooting. [online], , [cit ]. URL [3] DShield; Cooperative Network Security Community. [online], Květen 2009, [cit ]. URL [4] NFDUMP. [online], Květen 2009, [cit ]. URL [5] B. CLAISE, E.: Cisco Systems NetFlow Services Export Version 9. RFC 3954 (Standard), Říjen URL [6] Cisco Systems, I.: Introducing to Cisco IOS NetFlow. Technická zpráva, Cisco, Říjen [7] COVER, T. M.; THOMAS, J. A.: Elements of Information Theory. 2006, isbn [8] GRÉGR, M.: Monitoring zabezpečení LAN sítě. Bakalářská práce, Vysoké učení technické, [9] HAAG, P.: Watch your Flows with NfSen and NFDUMP. [online], Květen URL ripe50-plenary-tue-nfsen-nfdump.pdf [10] IVANKO, J.: Report of One-way Throughput Test. Technická zpráva, Červen URL [11] KIKUCHI, H.; FUKUNO, N.; KOBORI, T.; aj.: Automated Port-scan Classification with Decision Tree and Distributed Sensors. Information Processing, ročník 16, Září 2008: s [12] Lakkaraju, K.; Yurcik, W.; Lee, A. J.: NVisionIP: netflow visualizations of system state for security situational awareness. In VizSEC/DMSEC 04: Proceedings of the 2004 ACM workshop on Visualization and data mining for computer security, New 41

46 York, NY, USA: ACM, 2004, ISBN , s , doi: [13] LEE, C. B.; ROEDEL, C.; SILENOK, E.: Detection and Characterization of Port Scan Attacks. Technická zpráva, University of California, San Diego. URL [14] LYON, G.: Free Security Scanner For Network Exploration and Security Audits. [online], Duben 2009, [cit ]. URL [15] POSTEL, J.: Transmission Control Protocol. RFC 793 (Standard), Září 1981, updated by RFC URL [16] QUINLAN, J.: Induction of Decision Trees. Mach. Learn., ročník 1, č. 1: s , ISSN , doi: [17] REHÁK, M.; PĚCHOUČEK, M.; BARTOŠ, K.; aj.: CAMNEP: An intrusion detection system for high-speed networks. Září 2007, s [18] ROACH, C.: Building Decision Trees in Python. [online], Září 2006, [cit ]. URL [19] SCARFONE, K.; MELL, P.: Guide to intrusion detection and prevention systems. Technická zpráva, NIST, Únor [20] CALIGARE s.r.o..: What is Netflow? [online], Květen 2006, [rev ], [cit ]. URL [21] STEWART, J.: Windows Messenger Popup Spam on UDP Port [online], Červen 2003, [cit ]. URL [22] The Liberouter Project Team: FlowMon Probe Handbook. [online], Prosinec 2008, [cit ]. URL [23] VIDOVÁ-HLADKÁ, B.; SCHLESINGER, P.; RIBAROV, K.: Úvod do strojového učení (v počítačové lingvistice). [online], Únor 2009, [cit ]. URL C3%AD_(v_po%C4%8D%C3%ADta%C4%8Dov%C3%A9_lingvistice) 42

47 Seznam příloh A B C nfdump - formát výstupu pipe Webové rozhraní vytvořené nástrojem nfsen Ukázka detekce a záznam komunikace 43

48 Příloha A Nástroj nfdump - formát výstupu pipe Výstup formátu pipe je určen k dalšímu zpracování jiným programem. Jednotlivé položky jsou odděleny. IP adresy jsou ukládány jako 4 po sobě jdoucí 32bitová čísla. Pro IPv4 adresy se používá pouze poslední 32bitové číslo. Ostatní jsou nastaveny na 0. Address family PF INET or PF INET6 Time first seen UNIX time seconds msec first seen Mili seconds first seen Time last seen UNIX time seconds msec last seen Mili seconds first seen Protocol Protocol Src address Src address as 4 consecutive 32bit numbers. Src port Src port Dst address Dst address as 4 consecutive 32bit numbers. Dst port Dst port Src AS Src AS number Dst AS Dst AS number Input IF Input Interface Output IF TCP Flags Output Interface TCP Flags FIN SYN RESET PUSH ACK URGENT Tos Type of Service Packets Packets Bytes Bytes Příklad formátu u příznaku TCP paketu. Každý příznak je reprezentován 6-ti bity. U bitů se provede xor a výsledek se zapíše dekadicky. Takže SYN + RESET = 6 44

49 Pr ı loha B Graficke rozhranı vytvor ene na strojem nfsen Obra zek B.1: Hlavnı a navigac nı stra nka Obra zek B.2: Detaily grafu a pouz itı na stroje nfdump ve webove m rozhranı 45