České vysoké učení technické v Praze Fakulta informačních technologií Katedra počítačových systémů
Diplomová práce
Univerzální NfSen plugin pro analýzu síťových toků ve statistickém systému R. Bc. Martin Kopp
Vedoucí práce: Mgr. Rudolf B. Blažek, Ph.D.
10. května 2012
Poděkování Děkuji své ženě Petře za to, že hlídala naší dcerku v době mého psaní této práce. Dále děkuji paní Mgr. Petře Veselovské za korekturu a panu Ing. Pavlu Kordíkovi Ph.D. za cenné a podnětné připomínky.
Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.
V Plzni dne 10. května 2012
.....................
České vysoké učení technické v Praze Fakulta informačních technologií c 2012 Martin Kopp. Všechna práva vyhrazena.
Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.
Odkaz na tuto práci Martin Kopp. Univerzální NfSen plugin pro analýzu síťových toků ve statistickém systému R.: Diplomová práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.
Abstract This thesis deals with efficient deployment of statistical and mathematical analysis of network flows in real computer network traffic. The goal of the thesis is to design and implement a universal plugin for NfSen, which is a graphical web interface for the NeFlow collector nfdump. The plugin will serve as connection between data from a sensor and a system for statistical analysis R. This interface will allow for easier classification of captured network flows. The resulting plugin is useful in data mining and network security, where it will enhance development and testing of methods for detection of potentionally dangerous users, groups or segments in network infrastructure. Keywords NetFlows, nfdump, NfSen, R, statistical analysis, ...
Abstrakt Tato práce se zabývá problematikou efektivního nasazení statistické a matematické analýzy síťových toků v reálném provozu počítačových sítí. Cílem práce je navrhnout a implementovat univerzální plugin pro prostředí NfSen, které je grafickou webovou nadstavbou NetFlow kolektoru nfdump. Plugin bude sloužit jako propojení mezi daty z měřící sondy a systémem pro statistickou analýzu R. Toto rozhraní pak poslouží ke snazší klasifikaci zachycených síťových toků. Výsledný plugin má využití pro data mining a síťovou bezpečnost, kde umožní vývoj a testování metod pro vyhledání potenciálně nebezpečných jedinců, skupin nebo segmentů v prostoru síťové infrastruktury. Klíčová slova NetFlows, nfdump, NfSen, R, statistická analýza, ...
Přehled funkčních a nefunkčních služeb v nástroji Nagios core . . . Tradiční architektura pro sběr NetFlow dat . . . . . . . . . . . . . Architektura pro sběr NetFlow dat s použitím hardwarové sondy .
Diagram rozložení komunikace a provázanosti prvků Ukázka uživatelského rozhraní . . . . . . . . . . . . Ukázka výstupu, použitý algoritmus K means . . . . Schéma komunikačního rozhraní frontend : backend
Přehled částí pluginu včetně jejich funkcí . . . . . . . . . . . . . . Měření časové složitosti výpočtu kontingenčních tabulek za použití Nfdumpu a R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Časová složitost výpočtu features . . . . . . . . . . . . . . . . . . .
5.1 5.2 5.3
Závislost doby výpočtu K-means na velikosti instance a počtu center 44 Časová složitost výpočtu, EM algoritmus . . . . . . . . . . . . . . 46 Časová složitost výpočtu, algoritmus Silhoutte . . . . . . . . . . . 48
xv
37 39
Úvod Když v roce 1969 začínali zaměstnanci amerického výzkumného centra ARPA1 pracovat na sdílené počítačové síti, ani nemohli mít tušení, jak rozsáhlou a zásadní se jejich síť stane. Vývoj ARPAnetu, jak svoji síť nazvali, byl motivován především touhou lépe využít v té době dostupné výpočetní prostředky [22]. Již v roce 1969 existovaly specializované superpočítače, zejména pro vědecké a vojenské účely. Hlavním cílem tvůrců ARPAnetu bylo umožnit přístup odborníků v různých oborech k těmto, mnohdy stovky mil vzdáleným, strojům. Původní síť, ačkoliv geograficky velmi rozlehlá, byla složena pouze z počítačů několika předních výzkumných center a vyhlášených univerzit. Jednalo se řádově o stovky počítačů, což znamenalo využití jen malého zlomku dostupného adresního prostoru. Hlavním cílem v tomto období bylo sdílení vědomostí mezi několika stovkami „vyvolených“ se zaměřením na kvalitu spojení. Problém bezpečnosti tehdy nebyl vůbec řešen. Od roku 1991, kdy se ARPAnet oficialně změnil v Internet, se tato mezinárodní počítačová síť rozrostla tak, že dnes je součástí téměř každé moderní domácnosti po celém světě. Síťové karty najdeme nejen v počítačích, telefonech, televizorech a radiích, ale dokonce již i v pračkách či plynových kotlích. Ze svého počítače můžeme nakupovat, platit nájem, odevzdávat výsledky své práce, atd. Po síti se každý den pohybují s instatní rychlostí miliardy dolarů, eur, rublů a dalších měn. Většina aktivit lidské společnosti se alespoň z části kontroluje pomocí počítačů, které jsou připojeny k nějaké více či méně izolované síti. Nejen ve vědě a výzkumu, ale i ve státní správě, školství, průmyslu, energetice či obraně. V důsledku toho je pro dnešní svět Internet jedním z nejdůležitějších, ale v případě zneužití potenciálně také jedním z nejnebezpečnějších vynálezů dvacátého století. S nárůstem popularity Internetu vzrostl i počet síťových útoků tak, že se dostaly do popředí zájmu veřejnosti. Několikrát za měsíc si můžeme v tisku přečíst titulky jako například „Anonymous prý na konci března zastaví internet“ z 21.2.2012 [38], nebo „Anonymous hrozí napadením DNS. Můžou uspět?“ z 23.2.2012 [37]. Případně ze sousedního Slovenska „Útoky na web Úradu vlády SR vraj nespôsobili priame škody“ [39], který se objevil 31.1.2012 1 Advanced Research Projects Agency, výzkumná agentura United States Department of Defense, byla přejmenována přidáním slova „Defense“ na DARPA v r. 1972 a 1996.
1
Úvod krátce po jednání o smlouvě ACTA, jejíž přijetí by znamenalo v rámci zamezení pirátství omezit „svobodný internet“. Očividně se otázka bezpečnosti stala v současnosti více než aktuální. Metody útočníků jsou stále rafinovanější a zejména distribuované útoky, mezi které patří i výše zmiňované útoky, se stávají velkým trendem. Přestože metody obrany se také stále zlepšují, jejich vývoj je tlačen kupředu spíše nutností reagovat na nové a nové hrozby, než jim předcházet. Proto jsou potřeba metody lepší, účinnější a vzhledem k narůstajícímu provozu také rychlejší. Problémem detekce útoků a ochrany proti nim není jen to, že původní návrh protokolů ARPAnetu a Iternetu nezahrnoval bezpečnostní aspekty. Novým fenoménem je obrovský počet uživatelů a služeb, které Internet dnes má. Přestože síťové protokoly jsou deterministické a přesně popsané, náhodné chování uživatelů změnilo Internet ve stochastický systém enormních rozměrů. Toto má negativní vliv například na výkon detekčních systémů. Mezi hlavní nedostaktky i těch sebelepších deterministických systémů patří, že u nich není možné vhodně vybalancovat hranici mezi falešnými poplachy a dlouhou reakční dobou. Pokud takovýmito nástroji chceme detekovat útoky dostatečně rychle, můžeme se dočkat falešných poplachů tak často, že přehlédnout opravdový útok v záplavě falešných hlášení je velmi snadné. Druhým extrémem je přílišné zvýšení prahové hranice (tzv. threshold) určující, kdy systém detekuje útok. Dostáváme pak sice méně falešných útoků, avšak mnohdy se pak i o masivním útoku dozvíme se značným zpožděním a rafinované pozvolné útoky nám mohou uniknout úplně [33, 34]. Z tohoto důvodu jsou dnes vyvíjeny stále dokonalejší metody statistické, které threshold nastavují s ohledem na denní dobu, den v týdnu a mnoho dalších faktorů a které berou v potaz statistické vlastnosti síťového provozu. Příklad optimalizace statistické metody z [33, 34] je zobrazen v obr. 1 a 2. Dalším důsledkem stochastických aspektů i rozsáhlosti Internetu je, že je velmi obtížné definovat normální a abnormální síťový provoz a chování uživatelů. Proto je třeba zabývat se metodami kvantitativní, statistické a behaviorální analýzy a jinými typy specializovaných analýz [10, 11, 21]. Nejprve musíme pochopit činnosti běžného úživatele na síti, abychom dokázali nalézt anomální chovaní, které může znamenat útok, a tak mu dokázali předejít, nebo alespoň minimalizovat jeho dopad. V této práci se věnuji problematice efektivního nasazení a testování statistické a matematické analýzy síťových toků ve spojení se senzorem, který monitoruje reálný provoz pomocí protokolu NetFlow [5]. Hlavním tématem bylo vytvoření univerzálního statistického pluginu pro populární softwarový monitor síťových toků NfSen [16]. Cílem pluginu bylo, aby bezpečnostním pracovníkům jednoduchým způsobem zpřístupnil sofistikované klasifikační algoritmy přímo z webového rozhraní NfSenu. Důležitým aspektem je univerzálnost pluginu, která umožní výzkumným týmům snadný vývoj, testování a rychlé nasazení nových algoritmů přímo v reálném provozu sítě. Neméně důležitá je rychlost přenosu a předzpracování dat, protože naměřených toků 2
Obrázek 1: Grafu zachycuje detekci DoS útoku, za použití statistického algoritmu s dynamicky nastavovaným trasholdem, který vychází z historických dat. Zelená čárá reprezentuje velikost trasholdu v čase spuštění DoS. Útok byl zachycen v čase 120s, tedy za 6s od začátku. Zdroj obrázku[34].
Obrázek 2: Na tomto grafu je použit stejný statistický algoritmus jako na obrázku 1, ovšem se staticky nastaveným trasholdem. Zachycení nastalo v čase 150s, Zpoždění je tedy 36s. Zdroj obrázku [34].
3
Úvod je obvykle velké množství. První kapitolu práce jsem věnoval rešerším několika opensource a freeware systémů pro monitorování sítě. Z nich vyplynuly důvody pro implementaci pluginu právě do NfSenu. V druhé kapitole jsem popsal všechny nástroje, které jsem použil v této práci. Jsou to: Statistický jazyk R, softwarová sonda fprobe, hardwarová sonda flowmon a NetFlow kolektor nfdump. Zvláštní pozornost si zaslouží statistický výpočetní systém R popsaný v sekci 2.5. V R jsem implementoval veškeré výpočetní metody, protože vzhledem k množství dat je nezbytné provádět veškeré výpočty velmi rychle. Pro tento bezplatný systém je navíc k dispozici mnoho knihoven s velmi moderními a sofistikovanými statistickými metodami. Proto se velmi dobře hodí pro implementaci nových metod pro statistickou detekci anomálií a útoků. Sytému NfSen je pro jeho význam věnována samostatná kapitola 3. Popisu výsledného implementovaného pluginu pro komunikaci NfSenu s jazykem R se věnuji v kapitole 4. V pluginu jsem pro účel testování výkonnosti implementoval několik základních nesupervizovaných klastrovacích algoritmů, například K-means. Všechny implementované algoritmy jsou podrobně popsány v kapitole 5. Výsledný plugin je naprogramován tak, aby byl snadno rozšiřitelný. Pro přidání nové statistické metody pro analýzu toků je potřeba jen implementace této metody v jazyce R a připsání jediného řádku do konfiguračního souboru. Vznikl tak nástroj, který v mnohém usnadní klasifikaci a analýzu síťových toků. Závěr práce tvoří ukázka klasifikace s pomocí pluginu.
4
Kapitola
Monitorování sítí 1.1
Dostupné nástroje
V této části práce bych rád představil několik nástrojů pro monitorování nejen sítí a poukázal na jejich přednosti a slabiny.
1.1.1
Snort
Snort[29] je opensourcový program, který slouží jako NIDS a NIPS. Spravuje ho firma Sourcefire, kterou založil původní autor Snortu Martin Roesch. Hlavní síla spočívá v kombinaci těchto tří technik: • porovnávání signatur • analýza protokolů • kontrola síťových anomálií. Metoda vyhledávání signatur je běžná například v antivirových programech. Její využití je samozřejmě mnohem širší, v rámci počítačových sítí ji lze využít například pro vyhledávání P2P spojení. V ramci analýzy protokolů jsme schopni odhalit například slovníkové útoky na SSH. Jak to funguje? Konkrétně pro SSH nám norma RFC 4253 předepisuje, jak má vypadat komunikce pomocí protokolu SSH. Dokonce i takové detaily, jakými jsou velikost kladné a záporné odpověďi na autentizaci. Díky čemuž jsme poměrně snadno schopni poznat slovníkový útok podle velkého množství zamítavých odpovědí. Bohužel ne všechny protokoly jsou takto striktně definovány. Kontrola síťových anomálií slouží k odhalování nových hrozeb. K tomuto účelu se běžně používají některé z metod výpočetní inteligence. Zejména v poslední době je kladen velký důraz na význam umělé inteligence a tedy neuronových sítí. 5
1
1. Monitorování sítí Snort má tři různé režimy : • Sniffer - odposlech paketů. • Packet Logger - záznam paketů. • NIDS - zpracování paketů podle uživatelem definovaných pravidel. Pro nás je samozřejmě nejzajímavější třetí režim. Je potřeba upozornit na frázi „uživatelem definovaných pravidel“. Snort je tedy stejně dobrý jako sada pravidel jimiž se řídí. Respektive jako uživatel, který tato pravidla napsal. Firma sourcefire se sice stará o vývoj a testování vhodných pravidel, ta už ovšem nejsou zdarma.
1.1.2
Nagios
Obrázek 1.1: Přehled funkčních a nefunkčních služeb v nástroji Nagios core.
Nagios [25] je opensource systém pro monitorování počítačových systému, sítí a infrastruktury. Jeho původním záměrem bylo monitorovat chod serverů, ale v současnosti se využívá na sledování mnoha rozličných služeb. Nagiosem lze za pomoci vhodných pluginů monitorovat např. turnikety a bezpečnostní kamery, obsazenost disků, ale i mnoho síťových charakteristik. Přes jeho široké využití zůstávají původní funkce majoritním důvodem jeho masové obliby. 6
1.1. Dostupné nástroje Pokud Nagios při monitorování nalezne nějakou závadu, může poslat upozornění amdinistrátorovi např. pomocí sms, e-mailu atp... Některé chyby samozřejmě nevyžadují okamžitý zásah administrátora, a tak lze při jejich detekci spustit samoopravné, zálohovací nebo jiné scripty. Jistě si dovedete představit kolik výkonu je potřeba na neustále monitorování řekněme 100 služeb. Nagios toto řeší dle mého soudu velmi chytře. Existuje jeden (ve velkých provozech více) čistě monitorovací server, který neprovádí žádné testování. Testování provádí hlídaná zařízení sama (samozřejmě pokud je to možné) a na monitorovací server posílají pouze závěrečná hlášení z testů. Nagios navíc jednotlivé testy vhodně plánuje tak, aby výkon monitorovaných zařízení co nejméně ovlivnil. Monitorovací server se pak stará pouze o příchozí zprávy a přehledně je zobrazuje, případně zašle upozornění nebo spustí patřičné skripty.
1.1.3
Tcpdump
Tcpdump[15] je terminálový nástroj pro monitorování sítě a sběr dat. První verze se objevila v roce 1987. Původními autory jsou Van Jacobson, Craig Leres a Steven McCanne, kteří tou dobou pracovali v Lawrence Berkeley Laboratory Network Research Group. Protože tcpdump patří mezi opensource, může k jeho rozvoji přispět každý, avšak současné autorství si nárokuje skupina zvaná The tcpdump group. Tcpdump pracuje na úrovni paketů. Zachytává je, filtruje a analyzuje. K tomutu účelu využívá knihovny libpcap, na jejímž vývoji taktéž pracuje skupina The tcpdump group. Pomocí tcpdumpu lze sledovat veškerou komunikaci mezi dvěma nebo více stroji. Veškerá zachycená data lze uskladnit do souboru a umožnit tak jejich zpracování pomocí dalších nástrojů. Protože tcpdump je oblíbeným programem pro monitorování provozu na sítí již mnoho let, existuje velké množství nástrojů, které umí načíst soubory v jeho formátu a dále je analyzovat. Mnoho z nich lze nalézt například zde: http://www.acm.org/sigcomm/ITA/. Samotný tcpdump čte a vhodným způsobem zobrazuje zachycené pakety. Chování tcpdumpu ovlivňuje opravdu velké množství přepínačů. V terminálu tak můžeme sledovat obsahy nejen tcp, udp, ale třeba i pakety ve formatu Cisco netflow. Vzhled výstupu lze upravovat téměř libovolně. A tak, když zachytíme nebo si vyfiltrujeme stahovaní webové stránky, můžeme si pomocí přepínače -A prohlednout její obsah v html kódu. Přepínačem -E lze dokonce dešifrovat IPsec ESP pakety. Základní syntaxi shrnuje následující tabulka. Tabulka 1.1: Syntaxe tcpdumpu Syntaxe Příklad
Protokol tcp
Směr dst
Host 10.10.1.7
Hodnota 443
Operátor or
Další výraz tcp 80
7
1. Monitorování sítí Volba Protokol
Směr Host Logický Operátor
Hodnoty Ether, fddi, ip, arp, rarp, decnet, lat, sca, moprc, mopdl, tcp and udp. Defaultně jsou přijímány všechny protokoly. Src, dst, src and dst, src or dst. Defaultně je přijímána komunikace oběmi směry tedy src or dst. Net, port, host, portrange. Defaultní nastavení je host. Not, and, or. Příklad „(not tcp port 3128) and tcp port 23“.
Tcpdump je bezesporu nesmírně užitečný nástroj, má však jednu zásadní nevýhod, a to ukládání všech dat, která procházejí po monitorované části síťě. Je naprosto nemyslitelné, kolik diskové kapacity by bylo potřeba pro záznam byť jediného dne na páteřní síti. Ve skutečnosti stačí mnohem menší síťový segment, aby potřeba diskového prostoru překročila všechny meze. Krásný modelový příklad je vysokoškolská kolej pro řádově sto studentů. Objem dat zachycených na takové síti se samozřejmě bude různit den ode dne. Není neobvyklé, že nashromážděná data překročí 1TB. Jakkoliv je tcpdump užitečný nástroj, pro monitorování velkých nebo vysokobjemových sítí se nehodí.
1.2
Netflow
Protože zbytek práce se zabývá síťovými toky, popíši nejprve, co jsou to síťové toky a jak se ukládají.
1.2.1
Co jsou toky v síťích
Zjednodušeně lze řící, že síťovým tokem rozumíme spojení mezi dvěma stroji jedním směrem, které probíhá na stejném portu. Ve skutečnosti je to o něco složitější. Definice toku: Tok je definován jako jednosměrná posloupnost paketů, které sdílí sedm následujích vlastností : • Rozhraní • Zdrojová IP adresa. • Cílová IP adresa. • IP protokol. • Zdrojový port pro UDP nebo TCP, pro ostatní protokoly 0. • Cílový port pro UDP nebo TCP, typ a kód pro ICMP, pro ostatní prokoly 0. 8
1.2. Netflow • IP typ služby (Type of service). Z definice je tedy patrné, že full-duplexní spojení mezi dvěma uzly, jsou vždy alespoň dva toky. Tok vzniká příjetím paketu, který nespadá do žádného již aktivního toku. Další pakety jsou pak náležitě zařazeny k přílušným tokům. K ukončení toku dojde podle konfigurace serveru buď pasivně, nebo aktivně. Pasivní ukončení nastává uplynutím časového intervalu tout od posledního přijatého paketu. Aktivně je tok ukončen také po čase tout , ovšem od začátku spojení. Velké a dlouhé toky jsou tedy rozsekány na několik menších. Tím pádem jsou dříve odeslány na zpracování a při analýze je lze opět spojit. Toto může být výhodné zejména při odhalování dlouhotrvajících pozvolných útoků. NetFlow[4] [36] je otevřený síťový protokol vyvíjený společností Cisco Systems. Slouží k získávání informací o síťovém provzu v téměř reálném čase. Přestože formátů na ukládání informací o sítových tocích lze nálezt mnoho, je NetFlow v dnešní době nejrozšířenějším protokolem, zejména verze 5 a 9.
1.2.2
Architektura NetFlow
Pokud chceme měřit síťové toky, potřebujeme jeden nebo více exportérů a alespoň jeden kolektor. Exportér musí být v síti vhodně umístěn, protože vidí pouze traffic, který jde přes něj. Jako kolektor je tedy vhodný například směrovač. Ze svého místa sbíra data o tocích a posílá je na kolektor. Je evidentní, že jeden exportér nemůže zvládnout celou síť, proto je jich obvykle v síti několik. Naproti tomu kolektor býva zpravidla jeden. Shromažduje data ze všech exportérů a provadí nad nimi analýzu. Máme tedy několik vhodně umístěných exportérů, které posílají NetFlow data na kolektor, který je dále zpracovává. Původní architektura podle Cisca svěřuje roli exportérů speciálním směrovačům. Tato metoda má několik nedostatků. Udržování informací o aktivních tocích značně vyčerpává výpočetní prostředky určené pro směrovaní. Navíc pořizovací cena těchto zařízení v podstatě znemožnila jejich nasazení v malých a středních sítích. Aby bylo možné dostatečně rychlé směrování při sběru dat, začalo se používat vzorkování. Tento přístup sice snížil výpočetní nároky na směrovače, ale také snížil vypovídající hodnotu měření. Tomuto přístupu se říká sampled NetFlow a je naprosto nevhodný např. pro odhalování bezpečnostních rizik. V současnosti se velice rozmáhají v roli exportérů speciální hardwarové sondy (viz obr. 1.3). Výhodná je samozřejmě cena těchto zařízení. Směrovačům nic neubírá na výkonu a sondy lze připojit na jakékoliv místo v síťi naprosto transparentním způsobem. Sondy na svém místě průchozí data monitorují, ale nezasahují do nich. Proto říkáme, že jsou sondy pasivní nebo transparentní. V idealním případě je exportér (sonda) spojen s kolektorem (server) dedikovanou linkou, čímž se 9
1. Monitorování sítí
Obrázek 1.2: Tradiční architektura pro sběr NetFlow dat podle Cisco Systems. zdroj wikipedia.org
sníží zátěž vlastní sítě. Hardwarové sondy tedy řeší včechny neduhy tradiční architektury. Záznamy o ukončených tocích odesílá exportér na kolektor pomocí UDP nebo SCTP, obvykle na portech 9995, 9555 nebo 2055. Jakmile je NetFlow záznam exportován, sonda nebo směrovač jej smaže. Z kapacitních a výkonostních důvodu je ani nelze skladovat déle.
1.2.3
Struktura a verze NetFlow
Při měření toků nás nezajímá obsah paketů, ale pouze jejich vlastnosti, počet a velikost. Jinými slovy není důležité, jaká data se šíří po síti, ale jak rychle, kudy a kolik jich teče. Záznam o jednom toku podle standardu NetFlow verze 5 obsahuje: • Verze NetFlow. • Index vstupního rozhraní . 10
1.2. Netflow
Obrázek 1.3: Architektura pro sběr NetFlow dat s použitím hardwarové sondy podle Cisco Systems. zdroj wikipedia.org
• Index výstupního rozhraní, 0 pokud byl paket zahozen. • Čas začátku a konce toku, v milisekundách od posledního bootu systému. • Počet bytů a paketů. • Údaje z L3 hlavičky: – Zdrojová a cílová IP adresa. – Zdrojový a cílový port. – ICMP typ a kód. – IP protocol. – ToS (Type of Service). – Maska cílové a zdrojové IP adresy. • U TCP toků obsahuje množinu všech TCP flagů, které se během toku vyskytly. 11
1. Monitorování sítí • IP adresa přístího HOPu (Host on Path). NetFlow verze 9 je flexibilní formát určený šablonou, může tedy obsahovat mnoho dalších informací o průběhu a vlastnostech toku. Další verze jsou: Tabulka 1.2: Verze NetFlow protokolu Verze v1 v2-v4 v5 v6 v7 v8 v9 v10
Popis První verze Nebyly uvedeny Nejpoužívanější Podpora pro tunelovaný provoz Informace ze switchů Podpora agregace Struktura daná šablonou, umožňuje mnoho kombinací IPFIX, IETF standard [19], rozšíření NetFlow v9
Přestože IPFIX (IP Flow Information Export) je vlastní protokol (definován v RFC 5101 - 5103), bývá často označován jako NetFlow verze 10. Vychází totiž z NetFlow verze 9 a dále ji rozšiřuje. V současnosti je velmi populární a výrobci jej stále častěji implementují do svých zařízení.
1.2.4
Využití
Datové toky se nezabývají obsahem paketů, ale, zjednodušeně řečeno, pouze jejich hlavičkami. Při jejich analýze tedy nemáme k dispozici informace o tom, co který uživatel posílá nebo přijímá za data. Víme pouze, kdy se kdo kam připojil, přes jaký protokol, jak dlouhá byla komunikace a kolik dat bylo celkem přeneseno. Z těchto informací jsme s vhodnými nástroji schopni poznat, zdali jde o normální síťový provoz, nebo např. DoS útok. A protože k tomu nepotřebujeme data, lze toky zpracovávat rychleji. To nám umožňuje sledovat mnohem více spojení. Proto se NetFlows používají zejména pro monitorování rychlých a páteřních sítí. Možnosti využití jsou obrovské. Pomocí toků lze odhalit např. slovníkové útoky na SSH, DoS i DDoS útoky, P2P spojení, horizontální i vertikální skeny. Snadno lze také poznat, který uživatel využívá jakou část pásma, ať už nám tato informace poslouží k vyúčtování, nebo lepšímu nastavení QoS. Protože skladovat informace o tocích je datově mnohém méně náročné než skladovat všechna data, umožnuje nám tato technika dlouhodobé monitorování sítě. Podle toho odhalíme tzv. úzká hrdla, případně přeexponovaná místa. NetFlows lze tedy využít jako vhodného pomocníka při plánování a udržování síťové infrastruktury, zejména ve větším měřítku, jako bezpečnostní prvek, nebo jako prostředek pro ISP (Internet Service Provider). 12
Kapitola
Použité nástroje Pro sběr NetFlows jsou potřeba exportér (sonda) a kolektor. Následující tabulka přehedně ilustruje, které nástroje jsme použili a k jakému učelu. Tabulka 2.1: Přehled použitých nástrojů pro sběr NetFlow dat Nástroj Fprobe
Funkce Softwarová sonda
Flowmon
Hardwarová sonda
Nfdump
Kolektor
NfSen
Kolektor
R
Statistická analýza
Popis Jednoduchý opensource nástroj, který nám posloužil jako exportér pro testovací data. Dedikovaná hardwarová sonda, kterou jsme sbírali na reálné síti. Balík nástrojů pro sběr a základní statistickou analýzu NetFlow dat. Webové rozhraní a rozšíření Nfdump. Speciální programovací jazyk pro statistickou analýzu.
Nástroje fprobe, Flowmon a Nfdump stručně popíši níže. Kolektoru NFsen a jazyku R je věnována samostatná kapitola.
2.1
Fprobe
Fprobe [13] je softwarová sonda, která používá knihovnu libpcap. Tuto sondu jsme vybrali, protože jako jediná je opensource a vyzkoušeli jsme, že implementace knihovny libpcap je kvalitní. Existuje ještě varianta fprobe-ulog, která přesměrovává toky pomocí ip-tables. Tato varianta sice nabízí lepší propustnost, ale složitěji se konfiguruje a v době psaní této práce nebyla ani starší verze v repozitáři plně funkční. 13
2
2. Použité nástroje Dalšími variantami softwarových sond jsou nProbe[27] a softflowd[24]. Základní licence pro nProbe vyjde ročně na 100 e. Dokumentace k sondě softflowd, byla mírně řečeno strohá. Základní funkce fprobe je vcelku jednoduchá. Z příchozích paketů sbírá informace o tocích a ty exportuje ve formě NetFlow na kolektor. Používali jsme verzi 1.1, která zvládá NetFlows verze 1,5,7. Dále umí také vzorkování, ukládání do různých formátů a také čtení dat z uložených pcap souborů. fprobe spustíte velmi snadno např. příkazem: fprobe -i eth0 localhost:9995 Použitý přepínač -i je povinný a určuje, nad kterým interfacuem fprobe poběží. Následuje parametr s adresou a portem, kde poslouchá kolektor. Samozřejmě pro upravení chování existuje velké množství dalších přepínačů. Zde uvedu ješte dva nejdůležitější. Pro více informací doporučuji přečíst manual. fprobe -i wlan0 -f ’tcp && port 80’ -n 7 192.168.15.250:9555 V tomto příkladu bude sonda zachytávat všechny TCP toky na portu 80, tedy webový provoz, který jde přes rozhraní wlan0, a odesílat ho na port 9555 na adrese 192.168.15.252 ve formátu NetFlows verze 7. Přepínač -f lze používat stejným způsobem jako u nástrojů tcpdump.
2.2
Sonda Flowmon
Flowmon [2] [3] je hardwarová implementace NetFlow sondy. Na jejím vývoji pracuje sdružení CESNET[1]. Základ tvoří FPGA deska COMBO6X s přídavnou kartou COMBO-4SFPRO. Tato sonda plní dvě zásadní úlohy :
• Full duplexní Gigabitový opakovač. • Zpracování příchozích paketů do IP toků, jejich zaznamenávání a odesílaní na kolektor. Díky první funkci je sonda Flowmon transparentní pro okolní linku, dokonce může být použita jako opakovač. Samozřejmě hlavním důvodem pro umístění do sítě je druhá funkce. Tedy zpracování a odesílaní NetFlow dat na kolektor. V současné verzi Flowmon v2 je sonda schopná zpracovat až jeden milion paketů za sekundu a udržet v paměti 64 tisíc aktivních záznamů o probíhajících tocích. Ve vývoji je dokonce sonda 40Gb. Tato verze sondy je navržena pro obrovské nebo vysokorychlostní sítě. Pro naše účely, měření v univerzitní síti FIT ČVUT, jsme si vystačili se starší verzí. 14
2.3. Kolektor Nfdump
Obrázek 2.1: Hardwarová sonda Flowmon, zakladní deska COMBO6X s přídavnou kartou COMBO-4SFPRO.
2.3
Kolektor Nfdump
Nfdump tools je balík opensource nástrojů pro zpracovní NetFlow dat. Nejvíce využívané jsou nfcapd, kolektor pro sběr dat, a nfdump, který umožnuje jejich následné zpracování. Nfcapd (NetFlow capture daemon) slouží ke sběru dat z jednoho exportéru. Chceme-li tedy používat tři exportéry, je nutné, aby běžely tři instance nfcapd. Toky z každého exportéru jsou ukládány do oddělených složek a lze je tak zpracovávat buď dohromady, nebo odděleně. Adresářová struktura uložených dat je snadno konfigorovatelná. Vlastní data jsou pak ukládána do souborů v binárním formátu. Názvy se řídí jednoduchým pravidlem, např. nfcapd.201203221830 obsahuje záznam z 22. března 2012 18:30. Po uplynutí předem definovaného časového úseku (typicky 5-ti minut) se data začnou ukládat do nového souboru. Nfcapd umí pracovat s NetFlow verze 5,7 a 9, také umožňuje samplování. Nfcapd není třeba nijak složitě konfigurovat stačí napsat např.: nfcapd -p 9995 -l flows/ Tento příkaz spustí nfcapd, který bude poslouchat na portu 9995, rotovat soubory po pěti minutách a ukládat je do složky flows. Pro odladění doporučuji použít ještě přepínač -E, který zobrazí zachycené toky na obrazovku 15
2. Použité nástroje v člověkem čitelném formátu. Pro běžné použítí bych doporučil ještě další dva přepínače -z, pro komprimaci ukládaných dat a -D čili spustit jako démona. Nfdump slouží ke zpracování souborů uloženýh pomocí nfcapd, ale i jinými nástroji, pokud používají k ukládání toků stejný formát. Umí zobrazovat data po jednotlivých souborech nebo za časové období, dokonce i z komprimovaných souborů (parametr -z u nfcapd). Zvládá také jednoduché statistické úlohy, jako N nej, nebo průměrný tok atp. Velmi zajímavá a zároveň užitečná je možnost použítí filtrů. Jejich formát se velmi podobá filtrům u nástrojů tcpdump. Z výše uvedeného je evidentní, že se jedná o jednoduchý, přesto komplexní nástroj. Nicméně pro práci s NetFlow daty nemusí a také není terminál vždy to pravé rozhraní. Tyto nedostatky beze zbytku a s mnoha dalšími výhodami řeší webový frontend jménem NfSen.
2.4
NfSen
NfSen není samostatným nástrojem, ale spíše nadstavbou nad Nfdumpem. Rozšiřuje Nfdump o přehledné webové rozhraní, počítá jednoduché statistiky a s pomcí RRD (Round Robin Database) tools vykresluje grafy. Umožňuje periodické vykonávání úloh nad daty a také, lze nastavit upozorňování na přednastavené události. Nasazení NfSenu v mnohém usnadňuje práci s NetFlow daty. Práce v NfSenu je hlavně velmi pohodlná a snadná. Vyberete si datum a časové rozmezí a okamžitě vidíte grafy. Máte tak přehled, jaký traffic byl na protokolech UDP, TCP, ICMP a také znáte vytížení sítě z hlediska toků. Pod grafy je tabulka se statistikami, kolik a jakých paketů bylo ve zvolenou dobu přeneseno po síti celkem a kolik průměrně za sekundu. To vše zvlášť pro vyjmenované protokoly a zvlášt pro toky. Pokud chceme data podrobit intenzivnější analýze, stačí použít Netflow Processing, který nabízí několik základních funkcí. Případně lze vyzkoušet některý z dostupných pluginů. Dále je možné si přijímaná data rozdělit do několika tzv. kanálů. Například si lze vytvořit pro každou sondu oddělený kanál. Pokud máte jedinou sondu, ale sledujete několik podsítí, můžete si vyfiltrovat a odděleně sledovat jednotlivé podsítě. Kanály se v grafech zobrazují různými barvami. Získáte tak přehled ne jen o síti celkově, ale také o jejích částech. Kanály stejně jako valnou většinu chování NfSenu lze nastvit buď přes webové rozhraní, nebo přímo v konfiguračním souboru. Protože NfSen má pro tuto práci naprosto stěžejní výzanam, je mu věnována celá následující kapitola 3. 16
2.5. R
Obrázek 2.2: Ukázka z webového rozhraní NfSen.
2.5
R
R je open source programovací jazyk pro statistické výpočty a grafiku. V podstatě se jedná o freewarovou implementaci statistického jazyka S. Původními autory R jsou Ross Ihaka a Robert Gentleman z novozélandské University of Auckland. V současnosti jej vyvíjí R Development Core Team, jehož členem je i původní autor jazyka S John Chambers. R je naprogramováno převážně v C, Fortranu a R. Přestože pro něj existuje několik GUI, stále se nejvíce používá v původním terminálovém rozhraní, které je volně dostupné pro většinu operačních systémů. R nabízí širokou škálu statistických a grafických metod, včetně lineárního a nelineárního modelování, klasických statictických testů, klasifikace a klastrování. Původní již tak bohaté prostředí je neustále rozšiřováno komunitou. R se od komerčního S liší zejména svým vysoce objektovým přístupem. Navíc přímo z prostředí R je možné volat funkce v C, C++ nebo Fortranu. Z výzkumu Rexer’s Annual Data Miner Survey [28] za rok 2010 vyplývá, že R se stalo nejpoužívanějším nástrojem pro data mining. V daném oboru jej používá více než 43% analytiků.
17
2. Použité nástroje R má dlouhou historii a pro svoji vysokou kvalitu a rychlost jeho obliba stále roste. V seznamu nejoblíbenějších programovacích jazyků TIOBE index[6] v březnu 2012 se R umístilo v top 20. Obliba komunitou a zejména odborníky z různých oborů zaručuje kvalitní a prověřené implementace nových i klasických metod. Proto jsme si jej vybrali jako vhodný nástroj pro statistickou a analytickou část této práce, Což zaručí snadnou rozšiřitelnost o nové metody i algoritmy.
18
Kapitola
NfSen Přestože NfSen se na první pohlem může zdát pouze jako vizualizační nástroj, nebo chcete-li webový frontend, opak je pravdou. NfSen výrazným způsobem rozšiřuje možnosti Nfdumpu. Navíc i tento nástroj je opensource, který lze rozšířit pomocí pluginů. Toto a mnoho dalších důvodů nás vedlo pro použití NfSenu jako jednoho z hlavních nástrojů pro tuto práci.
3.1
Popis
NfSen výrazným způsobem rozšiřuje původní funkcionalitu Nfdumpu. Hlavní funkce NfSenu jsou: • Zpracování NetFlow dat ve vybraném časovém úseku. • Vizualizace nasbíraných NetFlows a výsledků zpracování. • Snadná navigace mezi NetFlow daty za pomoci filtrů a profilů. • Systém pro automatické upozornění, nastane-li definovaná situace. • Periodické zpracovávání NetFlow dat. • Rozšířitelnost pomocí pluginů. Vše je dostupné přes jednoduché a přehledné webové rozhraní a navíc přes příkazový řádek. Pokud by toto vše nestačilo, existuje několik velmi zajímavých pluginů, které přidávají další možnosti. Některé z již hotových pluginů jsou čistě účelové např. Botnet[31], který, jak název napovídá, slouží pro odhalení botnetů v monitorované části sítě. Jiné pluginy mohou být, spíše pro zajímavost, např. SURFmap[18], jehož úkolem je zobrazovat síťové toky na mapě. Ke svému běhu NfSen potřebuje: PHP verze alespoň 4.1 ideálně 5, Perl verze 5.6, RRD tools a samozřejmě Nfdump. Výkonné jádro NfSenu je napsáno v jazyce Perl a webová část v jazyce PHP. Chování NfSen je potřeba nastavit 19
3
3. NfSen v konfiguračním souboru nfsen/etc/nfsen.conf. Mimo jiné se zde nastavuje, kolik instancí nfcapd se má spustit při startu NfSenu a na jakých portech mají poslouchat, jaká adresářová struktura se má použít pro ukládaní dat a jaké pluginy se mají nahrát. NfSen spustíme jednoduchým příkazem: nfsen/bin/nfsen start Sám se postará o spuštění nfcapd na správných portech. Pokud se změní počet nebo nastavení exportérů, nestačí službu jen restartovat, ale je nutné použít příkaz: nfsen/bin/nfsen reconfig Tento příkaz přizpůsobí adresářovou strukturu novému počtu a názvům profilů exportérů.
3.2
Systém pluginů
Stejně jako celý NfSen i rozšiřující pluginy můžeme rozdělit na dvě logické části, backend a frontend. Backendová část umožňuje periodicky i na vyžádání spouštět operace nad NetFlow daty. Dovoluje definovat alerty pro různé situace. Backendová část musí být napsána v jazyce Perl a může existovat samostatně bez frontendové části. Musí být v adresáři, který je pro backendové pluginy definován v konfiguračním souboru, typicky nfsen/plugins. Frontendová část zprostředkovává komunikaci s uživatelem a vizualizaci výstupů z pluginu. Základ tvoří PHP, ale lze použít JavaScript, Ajax a podobně. Frontend nemůže existovat samostatně, protože veškerá funkcionalita je obsažena v backendové části. Bez odpovídajícího Perl modulu se plugin ani nepodaří do NfSen zaregistrovat. Hotový PHP script se nahraje do umístění definovaného v konfiguračním souboru pro frontendový plugin, typicky do /var/www/nfsen/plugins. Chceme-li plugin začít používat, je potřeba jej zaregistrovat v konfiguračním souboru tímto způsobem: @plugins = ( # profil # modul [ ’*’, ’muj_plugin’ ], [ ’profil1’, ’muj_druhy_plugin’ ], ); Pokud přidáte nebo výrazně změníte některý z pluginů, je potřeba NfSen restartovat, aby si změn všimnul. Pokud budete provádět změny pouze v PHP části, restart není nutný. Vizualní část vašeho pluginu tak můžete ladit takzvaně „za živa“. 20
3.3. Struktura backendového pluginu
3.3
Struktura backendového pluginu
Backendový plugin musí být napsán v jazyce Perl a je nutné dodržet strukturu standardního modulu. Základní struktura je pevně dána a musí obsahovat následující: Jméno pluginu: package PluginName; Verze NfSenu, pro kterou je plugin určen: our $VERSION = 130; A dvě povinné funkce. První Init, jak již název napovídá, slouží pro inicializaci. Tato funkce vrací 1, pokud vše proběhlo v pořádku, v opačném případě pak 0. Pokud funkce vrátí hodnotu nula, zachází se nadále s pluginem, jako by byl deaktivovaný. sub Init { return 1; } Druhá povinná funkce run, ve které jsou pak všechny operace, které se mají provádět každých pět minut. Na návratovou hodnotu této funkce není brán zřetel. Doba nutná na vykonání všech operací v této funkci nesmí přesáhnout jednu periodu rotace souboru, typicky pět minut. sub run { my $profile = shift; my $timeslot = shift; # Format: yyyymmddHHMM # Do whatever you want to do. }
Dále je rezervováno několik názvů funkcí, které mají specifický účel, ale již nejsou povinné: sub Cleanup - Tato funkce se zavolá těsně před koncem běhu pluginu, aby po sobě plugin uklidil. Zde je vhodné navrátit původní hodnoty globálních proměných, smazat dočasné soubory atp. sub alert_condition - Tato funkce se používá, pokud je třeba kontrolovat nějakou vlastnost, kterou nelze nastavit v defaultním rozhraní NfSenu. Je-li tato funkce přítomna při zavádění pluginů, objeví se jeho název při nastavování podmínek spuštění alertu v menu NfSenu. 21
3. NfSen
Obrázek 3.1: Definice alertu pomocí pluginu.
sub alert_action - Zde se definuje akce, která se vykoná, pokud nastane alert. Funkce alert_condition a alert_action na sobě nezávisí. Dokonce ani nemusí být přítomny obě v jednom pluginu. Stejně jako u alert_condition, pokud je přítomna tato funkce při závádění pluginu, objeví se jeho název v rozbalovací nabídce.
3.4
Struktura frontendového pluginu
Frontendová část pluginu je nepovinná, dokonce bude rozpoznána, jen pokud existuje odpovídající backendová část. Název souboru s backendovou a frontendovou částí musí být shodný. Přestože ve frontendu lze použít různé technologie pro tvorbu webu, základem musí být php script. Tento script navíc musí obsahovat dvě funkce pluginName_ParseInput a pluginName_Run. Funkce pluginName_ParseInput se zavolá hned po načtení webového rozhraní pluginu. Je to tedy první věc, která se vykoná. Až po dokončení jsou odeslány hlavičky vlastního NfSenu. Následuje volání funkce pluginName_Run. Požadavky na povinnou část frontendu nejsou velké, na druhou stranu je tu několik konvencí, které je vhodné dodržet, aby se předešlo kolizím s funkcemi vlastního NfSenu a ostatních pluginů: • Každému pluginu je přiděleno ID a posláno jako parametr. • Název všech funkcí by měl splňovat předpis pluginName_Function. 22
3.4. Struktura frontendového pluginu
Obrázek 3.2: Definice obsluhy alertu pomocí pluginu.
• Neukládejte žádné proměné přímo do pole sezení$_SESSION. Použijte raději podpole $_SESSION[’plugin’][$plugin_id]. • Pro práci s formuláři a parametry jsou zde speciální funkce (viz níže).
3.4.1
Zpracování formulářů
NfSen má vlastní speciální funkci pro zpracování dat z formulářů ParseForm. Její účel je sice zcela evidentní, nicméně způsob jejího použití už nikoliv. list ($process_form, $has_errors) = ParseForm($parse_opts); Funkce vrací list se zpracovanými proměnými z formuláře. Jako parametr přijíma speciální pole. $parse_opts = array( // var colour => array( "required" => 0, "default" => “red”, "allow_null" => 1, "match" => "/^[a-z]*$/" , "validate" => NULL), time => array( .... 23
3. NfSen Toto pole obsahuje pro každý parametr (např. colour, time) daného formuláře pole, které definuje jeho vlastnosti. Kopletní přehled viz (tabulka 3.1). Tabulka 3.1: Definice pole parseopts required allow_null default match
Definuje, jestli se parametr musí nacházet v $_POST. Nabývá hodnot 0,1. Definuje, jestli hodnota může být nulová, případně prázdná. Nabývá hodnot 0,1. Defaultní hodnota, na kterou se proměnná nastaví, pokud je prázdná, nebo v $_POST chybí. Zkontroluje zda-li, hodnota proměnné vyhovuje požadavkům. Příklady: "match" "match" "match" "match"
validate
3.4.2
=> => => =>
"/[^A-Za-z0-9-+\_]\+/" - regulární výraz array("red", "green", "blue") - výčet range(0, 10) - rozsah NULL - nekontroluje se
Dodatečná validace. Nabývá hodnot: NULL nekontroluje se, nebo název validační funkce
Validační funkce
function validate (&$var, $opts) &$var je ukaztel na hodnotu, která má být zkontrolována. $opts je pole parametrů pro tuto proměnou. V případě úspěchu musí funkce vrátit 1, v opačném případě 0. Pokud se ve validační funkci vyskytne chyba, je možné vrátit hodnotu 2 - error. V tomto případě se validovaná hodnota nepřepíše na defaultní hodnotu. Na závěr příklad použití funkce ParseForm: ’ $parse_opts = array( "colour" => array( "required" => 1, "default" => ’#6600ff”, "allow_null" => 0, "match" => "/^#[0-9a-f]{6}/i", "validate" => NULL) ); list ($process_form, $has_errors) = ParseForm($parse_opts); 24
3.5. Komunikace Zpracováné hodnoty teď lze nalézt zde $proccess_form[’colour’]. Použití funkce ParseForm sice není příliš intuitivní, přesto je velmi vhodné ji používat. Hlavní důvody jsou zejména bezpečnostní. Tato funkce kontroluje veškerý vstup a vhodně s ním nakládá. Pomůže dobře si rozmyslet jaký vstup je vlastně očekáván a podle toho vhodně nastavit regulární výraz. Jste tak chráněni proti útokům typu injection. I když NfSen nepoužívá SQL databázi, neošetřeným vstupem z formuláře pořád hrozí dokonce několik typů útoků. Jako příklad lze uvést XSS. Proto z bezpečnostních důvodů, důrazně doporučuji používat pro zpracování dat z formuláře funkci ParseForm. Obzvláště velké riziko hrozí, pokud bychom neošetřili parametry, které později používá backendová část při volání Nfdumpu nebo jiných programů. Pro demonstraci zde uvedu modelový příklad. Jako neošetřený vstup mějme pole pro zadání času $timestamp. Obsah tohoto pole předán backendu, který jej použije jako parametr pro volání nfdumpu. Například takto: my @output = ‘$nfdump -A srcip,dstport - M $netflow_sources nfcapd.$timestamp‘; Pokud se do tohoto pole místo času ve formátu RRRRMMDDhhmm zadá vlastní kód v bashi, bude interpretován. vložíme-li do pole $timestamp například |cat /etc/shadow, bude v proměné @output uložen obsah souboru /etc/shadow. Samozřejmě v tuto chvíli záleží na tm, jaká práva má spuštěný NfSen. V současnosti obvykle běží pod uživatelem www-data, který k souboru /etc/shadow nemá přístup. Ovšem v budoucnosti, až dojde k separaci backendu a frontendu, není jasné, jaká práva bude backendová část vyžadovat ke svému běhu, a už vůbec není jasné, s jakými právy bude skutečně spuštěn. Dále je třeba zdůraznit, že oddělený backend může bežet na zcela jiném stroji než na webovém serveru. Pokud by backendová část byla spuštěna s rootovským oprávněním, lze skrze toto neošetřené pole získat kontrolu nad celým strojem. Protože NfSen je lidově řečeno „choulostivý“ na nastavení práv všech svých složek a souborů, je dosti pravděpodobné, že se NfSen spuštěný se zvýšenými oprávněními občas vyskytne. Přestože tento příklad je pouze teoretický, tak přejít od spekulace k praktickému útoku lze velmi rychle a snadno. ři psaní vlastního pluginu je proto naprosto nezbytné dbát základních bezpečnostních opatření. A pro veškerý vstup použít funkci ParseForm, případně jinou spolehlivou metodu.
3.5
Komunikace
Plugin je rozdělen na dvě části. Z toho plyne potřeba komunikace mezi oběma částmi. V budoucích verzích NfSenu pravděpodobně dojde k ještě větší separaci backendu od frontendu. Je pravděpodobné, že frontend poběží například 25
3. NfSen na webovém serveru a backend na nějakém výpočetně zdatnějším stroji. Proto je nutné ke komunikaci zvolit vhodný přístup. NfSen používá Berkley sockety. Protože přistupovat k socketům přímo je poněkud složité a zdlouhavé, nabízí NfSen metody pro výměnu dat mezi částmi pluginu. Tyto metody lze nalézt v souborech nfsen/libexec/Nfcomm.pm a /var/www/nfsen/nfsenutil.php.
3.5.1
Frontend
Z frontendu je možné zavolat funkci backendu pomocí příkazu nfsend_query. Tato má dva parametry, první je název funkce oddělený dvojtečkami od jména pluginu. Druhým parametrem je pole všech hodnot, které chceme předat backendu. $out_list = nfsend_query("MujPlugin::secti", $opts); V proměné $out_list je uložen výstup z volané funkce backendu. Pokud při vykonávání funkce nastane chyba, v proměné $out_list bude hodnota FALSE.
3.5.2
Backend
Pokud chceme ve frontendu volat funkci z backendové části, musíme ji nejprve zaregistrovat. To provedeme takto: our %cmd_lookup = ( ’secti’ => \&SectiCisla, ’druha’ => \&DalsiMetoda, ); V hashi %cmd_lookup je uložen seznam funkcí tak, že hodnota u každého klíče je ukazatel na funkci. Tato funkce se zavolá ve chvíli kdy je zachycen k ní registrovaný příkaz. Nazev %cmd_lookup je povinný. Implemetace funkce musí obsahovat následující: sub SectiCisla { my $socket my $opts }
= shift; = shift;
Měla by přijímat dva parametry $socket a $opts.V $socket je odkaz na aktuální komunikační socket. Tato hodnota se předává i ostatním funkcím. $opts je hash, který obsahuje všechny proměnné a pole poslané z frontendu. Pro odeslání dat zpět frontendu jsou k dispozici dvě funkce Nfcomm::socket_send_ok a Nfcomm::socket_send_error. Ty se používají následujícím způsobem: 26
3.5. Komunikace Nfcomm::socket_send_ok($socket, \%args); Nfcomm::socket_send_ok má dva parametry. Prvním je ukazatel na aktuální socket, V druhém parametru se předávají zpět frontendu všechny pole i proměnné ve formě hashe. Pokud se něco nepodaří, je potřeba informovat frontend. Použije se funkce Nfcomm::socket_send_error. Nfcomm::socket_send_error($socket, "Chybová zpáva"); I zde se zadávají dva parametry, ukazatel na socket spojení a chybová zpráva.
3.5.3
Příklad
Na závěr jednoduchý příklad. Frontend: // příprava argumentů $opts = array(); $opts[’cislo1’] = 13; $opts[’cislo2’] = 29; //muzeme predavat i pole $opts[’cisla’] = array ( ’22’, ’20’); //Zavoláme funkci z~backendu $out_list = nfsend_query("Pluginname::secti", $opts); //kontrola výsledku // if $out_list == FALSE – V backendove fci nastala chyba if ( !is_array($out_list) ) { SetMessage(’error’, "Error v~backendové části); return FALSE; } $soucet = $out_list[’soucet’]; $soucetpole = $out_list[’soucetpole’]; echo "Soucet cisel je: $soucet "; echo "Soucet hodnot v poli je$soucetpole "; ...
27
3. NfSen Backend: # registrace funkce our %cmd_lookup = ( ’secti’ => \&SectiCisla, ); sub SectiCisla { my $socket = shift; my $opts = shift; # kontrola vstupu if (!exists $$opts{’cislo1’} || !exists $$opts{’cislo2’}) { Nfcomm::socket_send_error($socket, "Chybí hodnota"); return; } # Vybereme hodnoty my $x1 = $$opts{’cislo1’}; my $x2 = $$opts{’cislo2’}; # ukazatel na pole my @numbs = $$opts{’cisla’}; my $ans = $x1 + $x2; my $anspole = $numbs[0] + $numbs[1]; # Příprava odpovědi my %args; $args{’soucet’} = $ans; $args{’soucetpole’} = $anspole; //a posílame Nfcomm::socket_send_ok($socket, \%args); }
28
Kapitola
Plugin pro komunikaci NfSen a R Nfsen2R Hlavní motivací pro vytvoření tohoto pluginu byla potřeba rychle a efektivně zpracovávat velké množství NetFlow dat. Analýza síťových toků je důležitá zejména ve dvou odvětích. Jsou jimi data mining a síťová bezpečnost. Při práci na tomto pluginu jsem si kladl za cíl vytvořit vhodný nástroj pro obě tato odvětví. Abychom mohli dělat data mining nebo statistickou analýzu, potřebujeme dobrý algoritmus, ale hlavně dobrá data. Z těchto důvodů jsem se rozhodl implementovat plugin, který umožní analyzovat data přímo v prostředí NetFlow kolektoru NfSen. Při návrhu pluginu jsem měl na paměti, že algoritmus, který je dobrý dnes, bude za rok již zastaralý. V oblasti data miningu je poločas zastarání algoritmu ještě mnohem kratší. Proto práce není zaměřena na implementaci nejmodernějších algoritmů. Místo toho jsem vytvořil prostředí, které lze velmi snadno rozšířit o nové algoritmy, a to naprosto bez znalosti vnitřní struktury pluginu. Vytvořil jsem transparentní spojení mezi vašimi daty a vašimi algoritmy. Pro psaní algoritmů jsem vybral jazyk R, který je v současnosti nejoblíbenějším nástrojem pro data mining viz. [6]. V R je možné velmi snadným způsobem implementovat vlastní algoritmy stejně dobře jako využít některé ze stovek knihoven. displaymath Tato kapitola popisuje všechny části a funkce pluginu, který byl hlavním úkolem celé diplomové práce. Pro úspěšnou komunikaci webového frontendu NfSenu se statistickým jazykem R je zapotřebí mnoha kroků. Situaci nejlépe pomůže vystihnout přehledný diagram. Z diagramu 4.1 je jasné, že vlastní plugin se skládá z několika oddělených částí. Hlavními částmi pluginu jsou frontend pro NfSen, backend pro NfSen a vlastní implementace algoritmů v jazyce R. Každá z těchto částí má na starosti rozdílné úlohy, konkrétně tyto: Následuje rozbor jednotlivých částí: 29
4
4. Plugin pro komunikaci NfSen a R Nfsen2R
Host 1 user input
Nfsen frontend (PHP,JS)
timestamp, user variables
output
Nfsen backend
(Perl,Bash) simple statistics
timestamp
user output
Host 2
timestamp
RRD database
algrithm user variables
R output
temporary files
Nfdump flows
Obrázek 4.1: Diagram ukazuje rozložení komunikace a provázanosti prvků. Zjednodušeně vše probíha asi takto: Uživatel si pomocí webového frontendu NfSenu vybere algoritmus a časový interval. Tyto informace jsou poslány na backendovou část NfSenu, která zavolá Nfdump. Nfdump z RRD databáze vyzvedne NetFlow data za požadované období. Provede nad nimi jednoduchou statistiku. Ta je několika jednoduchými scripty v bashi rozparsována a uložena spolu s daty do dočasných souborů. Ty jsou předány zpět backendové části NfSenu. Odtud je pak vytvořen most pro komunikaci s R. Podle uživatelských dat je vybrán algoritmus a zvolena implementace pro statistický jazyk R. Ten je interpretován a výsledek odeslán backendu a z něj následně frontendu NfSenu, kde je zobrazen uživateli. Tabulka 4.1: Přehled částí pluginu včetně jejich funkcí Část pluginu Frontend
Backend
R
30
Funkce Určení algoritmů a jejich parametrů. Komunikace s uživatelem. Komunikace s backendem. Vizualizace výsledků. Parsování configuračního souboru. Získání dat, voláním Nfdumpu. Předzpracování dat pro R. Komunikce s frontendem a R. Kontrola a logování průběhu. Předpočet features. Výpočet vlastního algoritmu. Kreslení grafů.
4.1. Frontend
4.1
Frontend
Frontend pluginu Nfsen2R je napsán v PHP a JavaScriptu (JS). Použil jsem JS knihovny jQuery v. 1.4.3 [12] a FancyBox v. 1.3.4 [32]. Hlavním úkolem frontendu je samozřejmě komunikace s uživatelem. K té slouží jednoduché uživatelské rozhraní viz obr. 4.2
Obrázek 4.2: Ukázka uživatelského rozhraní. Jak je vidět, uživatelské rozhraní je skutečně jednoduché. Stačí zadat čas od-do ve formátu RRRRMMddhhmm, vybrat si algoritmus a zmáčknout execute. Samozřejmě je vhodné přenastavit defaultní hodnoty parametrů algoritmu. Další možností je výběr jednoho konkrétního kanálu. Výchozí nastavení je, že se analýza provede na data ze všech kanálu. To ovšem nemusí být vždy žádoucí. Získání seznamu algoritmů a kanálů. Seznam algoritmů s parametry je, stejně jako seznam dostupných kanálů, načten z konfiguračního souboru nfsen/etc/nfsen.conf, při načítání úvodní stránky pluginu. Bohužel ke konfiguračnímu souboru má přímý přístup pouze backend. V současné době sice lze ke konfiguračnímu souboru přistoupit přímo z frontendu, nicméně v budoucích verzích NfSenu bude frontend a backend zcela separátní. Velmi pravděpodobně poběží na různých strojích, a tak přímý přístup možný nebude. Z tohoto důvodu a také z důvodu zachování původní struktury a návrhu NfSenu je implementace následující: Frontend pošle backendu žádost o přečtení seznamu algoritmů. Backend přečte z konfiguračního souboru všechny parametry pro Nfsen2R. Parametry protřídí a vybere jen ty, které obsahují algoritmy, a přiřadí je do pole, které odešle zpět frontendu. Bohužel se mi nepodařilo odeslat z backendu hash, ale pouze očíslované pole, což poněkud komplikuje následnou úlohu frontendu. Ten přijme a rozparsuje toto pole a podle hodnot parametrů zobrazí nabídku. Pro získání seznamu algoritmů bylo tedy nutné vytvořit metody v obou částech pluginu. Získání seznamu dostupných kanálů je velmi obdobné, jen na obou stranách snazší. Jde totiž o list názvů, který se snadno převede na pole a pošle. Protože validace probíhá v backendu, na frontendu zůstává už jen vytvoření rozbalovací nabídky. 31
4. Plugin pro komunikaci NfSen a R Nfsen2R Komunikace s uživatelem a vizualizace výstupu. Dalším úkolem frontendu je převzít všechna data zadaná uživatelem, zvalidovat je, sestavit z nich pole a formou BSD socketu poslat backendu. K validaci dat používám funkci ParseForm, podrobně rozebranou zde 3.4.2. Když backend odvede svůj díl práce odešle stejným způsobem výsledky frontendu. Ten data přebere a zobrazí přímo ve webovém rozhraní. Příklad výstupu můžete vidět na obrázku 4.3. Výstup se obvykle skláda z několika grafů a dvou polí s informacemi o datech. Zobrazené grafy jsou pouze náhledy. Po kliknutí, se vybraný graf přesune do popředí v plné velikosti. Mezi zvětšenými grafy, lze přecházet buď pomocí šipek po stranách obrázku, stiskem klávesy nebo kolečkem myši. Grafy a obecně veškeré obrázky na výstupu jsou generovány v jazyce R, proto zásady jejich tvorby v pluginu Nfsen2R rozeberu níže v sekci 4.3. Další částí výstupu jsou pole s informacemi o datech a jejich zpracování. První pole informuje o časové náročnosti. Zobrazena je celková doba běhu a dílčí časy potřebné na předpočítaní features a běh algoritmu. V druhém poli jsou zobrazeny informace derivované z vlastních toků, nejprve celkový počet zpracovaných toků, poté přehled nejčastějších zdrojových a cílových IP adres a portů, nakonec informace o délkách toků v sekundách. Pod těmito poli se zobrazí, pokud je k dispozici, dodatečná zpráva o běhu algoritmu. Například pokud se nepodaří smazat dočasné soubory, bude o tom uživatel informován pomocí dodatečené zprávy. Komunikace s backendem. Komunikace fronendu s backendem probíhá pomocí BSD socketů a řídí se schématem obr. 4.4. Veškeré podrobnosti již byly rozebrány v sekci 3.5.
4.2
Backend
Přestože to není přímo vidět, backendová část má na starosti většinu vykonané práce. Na základě uživatelského vstupu rozhoduje o použitých metodách pro předzpracování dat. Je nezbytná pro čtení konfiguračních souborů, získání dat z binárních souborů a jako rozhraní mezi vstupními daty a výpočty. Většina backendu je napsána v Perlu, menší část pak v bashi. Pro komunikaci s R jsem vybral modul Statistics::R. Dalším, a kromě vlastního NfSenu, posledním rozšiřujícím modulem, je Time::HiRes, který slouží pro měření výpočetního času. Parsování configuračního souboru. První úloha, kterou si ihned po startu pluginu vyžádá frontend, je čtení konfiguračního souboru nfsen/etc/nfsen.conf. Nejprve musí být načten seznam algortimů a pro každý algoritmus pak seznam jeho parametrů. Tyto pa32
4.2. Backend
Obrázek 4.3: Ukázka výstupu pluginu Nfsen2R. V horní části tohoto výřezu jsou vidět grafy, které zobrazují datové toky rozdělené do klastrů algoritmem K-means. Následují údaje o době běhu. V posledním na obrázku viditelném poli jsou údaje o analyzovaných tocích. Zobrazí se zde nejčastěji použivaná zdrojová a cílová IP adresa a port. Zobrazené grafy jsou jen náhledy, které se po kliknutí zvětší.
rametry jsou v konfiguračním souboru uloženy v části PluginConf. Zde jsou parametry všech pluginů, sepsané do hashe. Každému pluginu je tak přiřazeno pole jeho parametrů. Protože toto pole je bráno jako jeden parametr, není možné načíst pouze jeho část, ale musí být načteno vcelku a poté rozebráno. Parsování a zároveň kontrola dat je realizována pomocí regulárních výrazů. Poté, co jsou vyparsována a seřazena podpole všech algoritmů, je výsledek odeslán frontendu. Toto vše má na starosti subrutina Nfsen2R::getAlgorithms. Záznam v konfiguračním souboru může vypadat například takto: %PluginConf = ( ’Nfsen2R_alg1’ => { ’alg’ => ’kmeans’, ’p1’=>’centers’, ’p1_type’=>’number’, ’p1_default’=>’7’ }, ’Nfsen2R_alg2’ => { ’alg’ => ’EM’, ’p1’=>’p1’, ’p1_type’=>’text’, ’p2’=>’p2’, ’p2_type’=>’enum ["one","two","three"]’}, ’Nfsen2R_alg4’ => { ’alg’ => ’MINDS’, ’p1’ => ’clusters’, ’p1_type’ => ’enum 2:15’ }); 33
4. Plugin pro komunikaci NfSen a R Nfsen2R
FRONTEND Frontend plugin Nfsen2R.php
nfsen comm interface nfsenutil.php BSD socket
nfsen comm interface Nfcomm.pm
Backend plugin Nfsen2R.pm
BACKEND Obrázek 4.4: Schéma komunikačního rozhraní frontend - backend.
Struktura má několik pravidel, která musí být dodržena. Každý parametr pro konkrétní plugin musí začínat jménem pluginu, tedy Nfsen2R. Pokud chceme, aby se náš algoritmus objevil v nabídce frontendu, musí řádek začínat: Nfsen2R_alg#. Znak # zde zastupuje číslo. To slouží pro určení pořadí, čím menší číslo, tím výše v nabídce algoritmus bude. Záporná čísla ani nula nejsou přípustné. První parametr se musí jmenovat alg a jeho hodnota určuje název algoritmu. Následuje seznam parametrů. Povinné jsou dvě vlastnosti: název a typ parametru. Třetí vlastností je nepovinná defaultní hodnota. Typem parametru může být number, text a enum. Enum má dva druhy zápisu. Pro čísla je formát enum od:do. Pokud chceme výčet textových hodnot pak enum ["prvni","druha"]. Rozdíl mezi hodnotou enum a number pro zadávání čísel je interpretace frontendem. Pro hodnotu number frontend zobrazí textové pole, do kterého uživatel napíše libovolné číslo. Může tedy být zaporné nebo desetinné. Pokud je typem parametru enum 2:5, frontend zobrazí rozbalovací nabídku s čísly od 2 do 5 včetně. Další úlohou backendu je načtení seznamu dostupných kanálů. Jejich seznam nalezneme v konfiguračním souboru pod klíčem sources. Protože tato proměnná je globální a tedy společná v rámci celého NfSenu, její načtení je výrazně snazší. Nám navíc nejde o konkrétní hodnoty, ale pouze o seznam názvů kanálů. Což je list hodnot, který se snadno převede na pole, předá frontendu i zpracuje. Tuto funkci plní subrutina Nfsen2R::getChannels.
34
4.2. Backend Záznam v konfiguračním souboru může vypadat napříkal takto: %sources = ( ’stream1’=>{’port’=>’9995’,’col’=>’#00f’,’type’=>’netflow’}, ’stream2’=>{’port’=>’9996’,’col’=>’#0f0’,’type’=>’netflow’}, ’subnet’=>{’port’=>’9995’,’col’=>’#f31’,’IP’=>’192.168.11.0/24’}, ); V tomto příkladu jsou celkem tři kanály: stream1, stream2 a subnet. Každý kanál má definovanou barvu, kterou bude mít na grafech, a port, na kterém se spustí a bude poslouchat nfcapd. Stream1 a subnet mají sice nastaven stejný port, ale subnet přijímá jenom toky, které mají zdroj nebo cíl v podsíti 192.168.11.0/24. Parametr type může mít dvě hodnoty, netflow nebo sflow. Defaultní hodnota je netflow, takže určení typu toků jako netflow pro kanály stream1 a stream2 je redundantní. Je uveden pouze pro úplnost. Obě předešlé metody na čtení z konfiguračního souboru jsou důležité pro potřeby frontendu. Ten z nich generuje nabídky v uživatelském rozhraní, čímž umožňuje snadno přidat do Nfsen2R nové algoritmy. Protože s jejich pomocí je generováno základní uživatelské rozhraní, jsou obě automaticky volány při načítání úvodní stránky pluginu. Získání a předzpracování dat. Následují procedury se spouští tzv. „on demand“, čili na požádání. Tím požádáním je pro nás stisk tlačítka execute. To vyvolá nejprve validaci vstupních dat frontendem. Až poté, a jen pokud jsou v pořádku, dojde k jejich odeslání backendové subrutině runAlgorithm. Ta je nejdůležitější částí celého pluginu. Stará se o získání a předzpracování dat, komunikaci s R a řízení výpočtu. Nejdříve ze všeho jsou upraveny vstupní časové intervaly. Čas může být zadán s přesností na minuty, ale soubory rotují po pěti minutách. Jejich názvy vypadají například takto nfcapd.201204231505. Tento soubor obsahuje toky z 23.dubna 2012 od 15:05 do 15:10. Zaokrouhlíme tedy vstupy na pět minut, vždy směrem dolů. V dalším kroku jsou vybrány všechny kanály, pro které se má provádět analýza. Pokud vše proběhne bez problému, Perl vytvoří tři soubory ve složce /tmp. Konkrétně jsou to tmp.flw, dport.flw a sport.flw. Do těchto souborů jsou zapsány hlavičky pro výsledné csv. V tmp.flw budou uloženy všechny toky ve formátu: timestamp, source IP, destination IP, protokol, source port, destination port, duration, flags. Do sport.flw respektive dport.flw budou uloženy napočtené výskyty párů zdrojový port, cílová adresa respektive cílový port, zdrojová adresa ve formátu: 35
4. Plugin pro komunikaci NfSen a R Nfsen2R source/destination IP,source/destination port, frequency Když jsou hlavičky v souborech připravené, zavolá se nfdump, který soubory naplní údaji o tocích. Poté, co jsou předpřipravené dočasné soubory, spustí se prostředí pro komunikaci s R. S jeho pomocí jsou předány parametry potřebné pro spuštění klastrovacího, případně jiného algoritmu. Samozřejmě není možné klasifikovat surové toky, nejprve je nezbytné z nich získat tzv. features, tedy sledované vlastnosti. Teprve ty jsou vstupem pro klasifikační algoritmus. Předpočet features probíha v jazyce R, proto bude podrobně diskutováno níže, viz sekce 4.3. Přestože máme otevřený kanál pro komunikaci perlu a R, snažím se co nejméně kódu vykonávat přímo z perlu. Motivací je usnadnit co nejvíce vkládání nových algoritmů. Proto je převážná většina Rkového kódu v oddělených souborech. Ty mohou být snadno upraveny, nebo zcela vyměněny. Soubory jsou dva: jeden pro přípravu dat a předpočet features a druhý s vlastním algoritmem. Dalším důvodem pro oddělení Rkového a perlovského kódu je snazší ladění. Pokud změníme část perlovského kódu, byť třeba jen zmenšíme konstantu, nebo doplníme středník, musí být restartován celý NfSen, aby se změna projevila. Pokud ovšem provedete změny v souborech s instrukcemi pro R, projeví se okamžitě, bez nutnosti restartu. Funkce runAlgorithm se stará v podstatě o vše. Začíná přebráním uživatelského vstupu a jeho úpravou. Pokračuje voláním nfdumpu, který z databáze vybere požadovaná data a předpočítá kontingenční tabulky. Dále řídí komunikaci s R a nakonec přeposílá výsledky na frontend. Tímto vším tvoří páteř celého pluginu. Komunikace s R. Komunikace s R probíhá pomocí modulu Statistics::R verze 0.27 . Jeho základní použití ilustruje následující úsek kódu. # Spuštění prostředí R my $R = Statistics::R->new(); # Nastavení proměné v~R. x=$perl_variable $R->set(’x’,$perl_variable) # Spuštění příkazu $R->run(’y<-sqrt(x)’); # Získání výstupu z~R pro další práci v~Perlu. my $output = $R->get(’y’); # Ukončení práce s~R $R->stop(); 36
4.2. Backend Kompletní seznam příkazů je uveden např. zde [7]. Tento modul také umožňuje tzv. bridged mode, což znamená, že se z více míst připojujete k jedné instanci R. Existuje jistě mnoho zajímavých aplikací, kde je to velmi užitečné, nicméně pro náš plugin tato funkce není podstatná, proto se jí nebudu dále zabývat. Nabízí se otázka, proč používám dočasné soubory. Je přece možné příkazem $R->set() předat data do R přímo. Původní myšlenka byla nepoužívat žádné dočasné soubory a využít přímého spojení. Autoři modulu pro komunikaci Perlu s R, dokonce tvrdí, že by to mělo být výrazně rychlejší. Bohužel opak je pravdou. Čas potřebný na předání tisíce toků z Perlu do R přímo je přibližně jedna minuta. Při použití dočasných souborů jsou to řádově desetiny vteřiny. Rychlost je také hlavním důvodem, proč předpočítávám kontingenční tabulky port/IP v Nfdumpu a nepočítam je přímo v R např. pomocí funkce table. Nfdump, který přistupuje přímo k binárním datům, zvládá napočítat četnosti mnohem rychleji než R (viz tabulka 4.2). Tabulka 4.2: Měření časové složitosti výpočtu kontingenčních tabulek za použití Nfdumpu a R. Měření probíhalo na notebooku s dvoujadrovým procesorem Intel U7300 1.3Ghz se 4GB RAM, operační sytém Ubuntu 10.10, jádro 2.6.35. #flows
Tabulka zachycuje měření časové náročnosti výpočtu kontigenčních tabulek. Za uvedený čas byly vypočteny dvě kontingenční tabulky: první zdrojový port, cílová IP adresa a druhá cílový port, zdrojová IP adresa. Meřil jsem na reálných datech ze školní sítě FIT ČVUT. Data jsou z nočních hodin, kdy je průměrná zátěž sítě rovna přibližně deseti tisícům toků za pět minut. Uvedené hodnoty jsou průměr z celkem pěti identických měření. První řádek odpovídá datům v intervalu pěti minut, každý další o pět minut více. Poslední dva řádky obsahují údaje za hodinu a hodinu a půl. Jsou uvedeny pro ilustraci, protože takovéto hodnoty jsou ve špičce běžné za pět minut. Dalším důvodem, proč používám pro předpočet kontingenčních tabulek nfdump, je úspora paměti. V R nebylo možné při velkém zatížení sítě některé tabulky napočítat. Pokud bylo v odpoledním provozu, který je výrazně bohatší než ten noční, více než sto tisíc toků, R často spadlo pro nedostatek paměti. Pro R mám vyhrazeno 1,5 Gb paměti.
37
4. Plugin pro komunikaci NfSen a R Nfsen2R Kontrola a logování průběhu. Posledím úkolem backendu je kontrola správnosti běhu programu. V zásadních částech kódu jsou vloženy příkazy, které kontrolují, jestli vše pokračuje tak, jak má. Například jestli byly vytvořeny dočasné soubory, načteny všechny proměnné, navázáno spojení s R a pod. Pokud by v některé části došlo k neočekávané nebo nechtěné události, program nesmí skončit bez informování uživatele. V první řadě je potřeba tyto události zachytit dříve, než způsobí pád. Pokud tato situace nastane, je třeba odeslat socket s informacemi, proč byl běh programu ukončen, na fronted, kde bude zobrazen uživateli. Je velmi nepravděpodobné, že by se podařilo odchytit všechna místa, kde může dojít k pádu. Proto je použito ještě logování. Pokud by tak došlo k neočekávanému pádu, lze najít alepoň nějaké informace v syslogu.
4.3
R
Úloha R je velmi jasná, co nejrychleji spočítat vše potřebné. Konkrétně má R na starosti předpočítání features, klasifikační algoritmus a kreslení grafů. Kromě funkcí samotného R používám ještě knihovnu Mclust. Ta poskytuje velmi dobré metody pro odhad počtu shluků v datech a také kvalitní implementaci algoritmu Exepctation-Maximization. Předpočet features. V naší implementaci klasifikujeme toky podle těchto pěti feature: • Počet toků, ze stejné zdrojové IP adresy. • Počet toků, na stejnou cílovou IP adresu. • Počet toků se stejným párem zdrojový port, cílová IP adresa. • Počet toků se stejným párem cílový port, zdrojová IP adresa. • Trvání toku v sekundách. Naše volba je inspirovaná [10], [11], [21]. Zdrojové kódy pro předpočet features jsou v samostatných souborech, jejichž název musí dodržet předpis: algoritmus_data_prep.r a je uložen v adresáři specifikovaném v konfiguračním souboru jako $R_DIR. Pokud soubor s tímto názvem neexistuje je použit default.r. Důvod pro samostatný soubor je nasnadě. Ne každý musí nutně souhlasit s naší volbou features, případně ji může rozšířit, či z časových důvodů zmenšit. Také některé algoritmy mohou vyžadovat odlišně formátované vstupy. Pokud se rozhodnete pro vlastní features, navrhujte algoritmy pro jejich výpočet velmi obezřetně. Snažte se využívat akcelerované a dobře optimalizované metody R. Vyhněte se zejména používání klasických cyklů, jakými 38
4.4. Instalace jsou např. for, while. Jejich použitím snadno učiníte předpočítání features časově příliš komplikovaným. Pokud se bez použití cyklů nedokážete obejít, doporučuji napsat si alespoň ty výpočetně nejnáročnější části v C. Čas potřebný na výpočet featurs viz. tabulka 4.3 Tabulka 4.3: Závislost doby výpočtu features na velikosti instance. n[-] 10 511 19 197 28 627 38 176 53 675
t[s] 0,99 1,84 2,67 3,64 5,14
n[-] 60 229 77 510 91 197 119 574 138 123
t[s] 5,76 6,77 8,95 12,134 14,07
Vlastní algoritmus. V pluginu Nfsen2R jsou implementovány tři algoritmy: K-means, Silhouette a Expectation-Maximization (EM). Je však možné implementovat téměř jakýkoliv smysluplný algoritmus, který lze spustit nad našimi pěti features, případně vašimi features. Vlastní klasfikační algoritmy ukládám do souborů algoritmus.r, také do adresáře R_DIR. V tomto zdrojovém souboru je také nutné vytvořit veškeré grafy, které mají být součástí výstupu. Kreslení grafů. Pokud jsou součástí výstupu z vašeho algoritmu obrázky, respektive grafy, musí jejich název odpovídat následujícímu vzoru: algoritmus#.png. Tedy například MINDS1.png, MINDS2.png atd. Váš algoritmus může vygenerovat libovolný počet grafů, pokud jejich názvy zachovají předepsaný vzor. Vygenerované grafy musí být uloženy přímo do složky backendového pluginu. Osobně s tímto umístěním nesouhlasím. Bohužel pokud jsem nechtěl upravit část původního NfSenu, případně komplikovat instalaci pluginu, nebyla jiná možnost. Z důvodu plánované separace backendu a frontendu jsou i obrázky přenášeny pomocí BSD socketů. Ty jsou přeneseny až ve chvíli, kdy je má frontend zobrazit.
4.4
Instalace
Instalace pluginu Nfsen2R je velmi jednoduchá. Přesto sestává z několika kroků, které je potřeba dodržet. Předpokládám, že pokud chcete používat plugin do NfSenu, vlastní NfSen již máte instalován. Pokud ano, potřebujete ještě nainstaloval perlovský modul Statistics::R a samozřejmě R se všemi knihovnami, které chcete používat. 39
4. Plugin pro komunikaci NfSen a R Nfsen2R Instalce pluginu Nfsen2R do NfSenu. Instalace sestává ze dvou kroků: • Nakopírování souborů pluginu do NfSenu. • Registrace pluginu a algoritmů v konfiguračním souboru. V prvním kroku překopírujte obsah složky Nfsen2R/backend/ do adresáře pro backendový plugin, typicky NfSen/plugins/. Dále zkopírujte obsah složky Nfsen2R/frontend/ do adresáře určeného pro frontendový plugin, typicky /var/www/nfsen/plugins. Zkontrolujte, že soubory mají dobře nastavené vlastníky (stejný jako zbytek souborů v daných adresářích). V druhém kroku upravíme konfigurační soubor nfsen/etc/nfsen.conf. Do klíče @plugins je potřeba přidat řádek [’*’, ’Nfsen2R’],. Tím zaregistrujete plugin do NfSenu. Ovšem aby Nfsen2R fungoval správně musíme mu ještě přidat algoritmy a hlavně adresář, kde máte zdrojové soubory pro spuštění v R, do klíče %PluginConf. Výsledný konfigurační soubor bude vypadat nějak takto: @plugins = ( # profile # module [’*’, ’demoplugin’], [’*’, ’Nfsen2R’], ); %PluginConf = ( demoplugin => { param2 => 42, }, ’R_DIR’ => "${BASEDIR}/plugins/R", ’Nfsen2R_alg1’=>{’alg’=>’kmeans’,’p1’=>’centers’,’p1_type’=>’number’}, ’Nfsen2R_alg2’=>{’alg’=>’EM’}, ’Nfsen2R_alg3’=>{’alg’=>’MINDS’,’p1’=>’clusters’,’p1_type’=>’number’}, ); A to je úplně vše, co je nezbytné ke správnému běhu Nfsen2R. Instalce nových algoritmů do Nfsen2R. Postup pro přidání vlastního algoritmu je následující. Především je nutné jej naprogramovat v R, nebo použít jednu z několika set knihoven. Algoritmus se uloží do soubor s názvem mujAlgoritmus.r. Pokud nestačí našich pět features (viz. 4.3), doporučuji napsat si vlastní přípravu dat. Tu uložte do souboru mujAlgoritmus_data_prep.r. Oba soubory překopírujte do adresáře pro zdrojové kódy v R, defaultně nfsen/plugins/R. Na závěr svůj algoritmus připište do konfiguračního souboru, do klíče %PluginConf. 40
Kapitola
Klasifikace síťových toků V této kapitole jsou nejprve podrobně popsány všechny implementované algoritmy. U každého je vysvětlený příklad výstupu, aby bylo zřejmé co znamená. V poslední části kapitoly naleznete analýzu realných dat ze školní sítě FIT ČVUT. Využiji k ní všechny implementované algoritmy a pokusím se tak ilustrovat jejich výhody a nevýhody na praktickém příkladě.
5.1
K-means
K-means je metoda pro shlukovou analýzu, která se snaží rozdělit n bodů do k klastrů. Každý bod je přiřazen do klastru, jehož centrum je mu podle sledovaných kritérií nejblíže. Ve zkoumaném prostoru tak vlastně vznikne Voroného digram [35]. Důsledkem přiřazování bodů nejbližšímu centru vznikají velikostně srovnatelné klastry částečně sférického tvaru.
Algoritmus Mějme množinu bodů x1 , x2 , ..., xn , kde bodem rozumíme d-rozměrný vektor. K-means se snaží rozdělit n bodů do k množin S1 , S2 , ..., Sk , kde k ≤ n, tak aby součet čtverců vzdáleností bodů od středu klastru byl co nejmenší. Tedy: min
k X X
||xj − µi ||2
i=1 xj ∈Si
Protože původní K-means je problém velmi obtížny (NP-těžký), vzniklo několik heuristických přístupů, které velmi rychle konvergují k lokalnímu optimu. Nejběžnější přístup je tzv. Lloydův algoritmus. Ten má tři fáze: • Inicializace • Přiřazení • Aktualizace 41
5
5. Klasifikace síťových toků Inicializace V inicializační fázi je rozmístěno k budoucích center c1 , c2 , ..., ck . Jsou dva obecné přístupy, jak centra rozmístit. Forgyho metoda a Random Partition. Forgyho metoda náhodně vybere k bodů z počáteční množiny dat a použije je jako centra. Random Partition nejprve náhodně přiděli každému bodu klastr a pokračuje krokem tři, kde bude centrum pro každý klastr přemístěno do těžiště. Výsledkem Forgyho inicializační metody je počáteční rozmístění center spíše po okrajích dat, kdežto Random Partition začíná s centry blíže středu dat. Vzhledem k článku [17] je preferována metoda Random Partition, proto je v této práci použita.
Přiřazení V této části přiřadíme všechny body x1 , x2 , ..., xn do klastru, jehož centrum je nejblíže. Tedy:
(t)
Si
(t)
(t)
= {xp : ||xp − ci || ≤ ||xp − cj ||∀1 ≤ j ≤ k}
Každý bod xp je přiřazen právě do jednoho klastru. Pokud by ležel přímo na hranici a mohl tak být přiřazeno do dvou klastrů, je zvolen první.
Aktualizace Ve fázi aktualizace je upravena poloha všech center, tak aby byla minimalizována suma čtverců vzdáleností všech bodů od centra jejich klastru.
(t+1)
ci
=
1
X
(t)
|Si | x
xj
(t) j ∈Si
Kroky dva a tři se opakují tak dlouho, dokud není dosaženo konvergence. Protože je použit heuristický algoritmus, není záručno, že dosáhneme konvergence v globálním optimu. Výsledek často záleží na počátečním rozložení center. Je proto vhodné spustit algoritmus vícekrát s různými počátečními podmínkami. Grafické znázornění průběhu algoritmu můžete vidět na obrázcích 5.1. Pro názornost je vybrán dvojrozměrný příklad. 42
5.1. K-means
1) Náhodná inicializace k-center (barevně).
2) Přiřazení bodů k nejbližšímu centru. Barevně je vyznačena sféra vlivu každého centra.
3) Přesun center do těžiště.
4) Krok 2 a 3 je opakován dokud není dosaženo konvergence.
Obrázek 5.1: Grafické znázornění běhu algoritmu K-means. Zdroj: wikipedia.org Přestože ilustrace je dvourozměrná, lze K-means rozšířit do n dimenzí. Bohužel, s přibývajícími dimenzemi výrazně klesá vypovídající hodnota grafů. Proto jsou použity náhledy z více stran. Příklad výstupu z pluginu Nfsen2R můžete vidět na obrázku 5.2. Výhodou K-means je jeho složitost O (N.k), kde N určuje velikost dat a k počet shluků. Je to tedy velmi rychlá metoda, vhodná na počáteční osahání dat. Čas potřebný na výpočet K-means v závislosti na velikosti instance a počtu shluků ilustruje tabulka 5.1. Největší nevýhodou K-means je ono k, které určuje počet center. Musí jej totiž zadat uživatel. Špatně zvolené k v podstatě znamená špatný výstup. Existuje mnoho algoritmů, které využívají K-means právě k určení počtu shluků. K-means nepatří k zrovna nejpřesnějším algoritmům. Zejména proto, že se snaží data přiřazovat do přibližně stejně velkých shluků sférického tvaru. Tento problém řeší některé algoritmy definované nad tzv. Gaussovskou směsí. V následující sekci si představíme jeden z nich Expectation-Maximization.
43
5. Klasifikace síťových toků
Obrázek 5.2: Příklad výstupu z pluginu Nfsen2R. Pro jednoduchost jsou zobrazeny pouze dvě dimenze. Ve skutečnosti sledujeme pět vlastností, tedy i výstup je pěti-rozměrný. Data jsou z malé lokální sítě za jednu hodinu, celkem dva tisíce toků. Osa x představuje počet výskytů zdrojové adresy, osa y počet výskytů cílového portu. Černou barvou jsou často používané adresy a shora porty 5355, 80, 53 a 443, tedy vcelku běžný provoz. Zajimavé jsou zejména body červenou barvou. Hodně málo vzdálených adres a cílové porty se rychle mění, mohlo by jít o skenování portů. Tabulka 5.1: Závislost doby výpočtu K-means na velikosti instance a počtu center. Uvedené hodnoty jsou průměr z celkem tří měření a jsou v sekundách. Měření probíhalo na notebooku s dvoujadrovým procesorem Intel U7300 1.3Ghz se 4GB RAM, operační sytém Ubuntu 10.10, jádro 2.6.35. k/n 10 511 19 197 28 627 38 176 53 674 60 229
Expectation-Maximization (EM)[8] je algoritmus, který pracuje s tzv. Gaussovskou směsí nebo chcete-li směsí normálního rozdělení. Normální rozdělení N (µ, σ) : 1 (x − µ)2 f (x) = √ exp( 2σ 2 2πσ
!
Což lze pro více rozměrů rozšířit na N (µ, Σ): 1
1 f (x) = exp − (x − µ)t Σ−1 (x − µ) d 2 2 (2π) 2 |Σ| ) Obecně lze řící, že se jedná o vážený průměr Gaussovských hustot. Graf pro trojrozměrný případ může vypadat jako na obr. 5.3 .
Obrázek 5.3: Graf směsi normálního rozdělení, patrné jsou dvě hlavní komponenty. Zdroj: http://crsouza.blogspot.com. Vlastní algortimus EM má pak na starosti doslova naučení parametrů jednotlivých Gaussových funkcí. Dosahuje toho iterováním dvou kroků: Estimate step, který odhadne parametry skrytých veličin, a Maximaze step, který maximalizuje věrohodnost modelů vzhledem k datům. V našem případě rozumíme skrytou veličinou příslušnost ke shluku C. Učíme tzv. Naive Bayes model, sestávající z proměných C a funkce f (N (µk , Σk )|C = k). E-step V tomto kroku přiřadíme všechna pozorvání x = 1, ..., N , do shluků k = 1, ..., K. pki = P (C = k|xi ) = αi .P (xi |C = k).P (C = k) Váhu shluku pak spočítáme: pk =
N X
pki
i=1
45
5. Klasifikace síťových toků M-step Pro daná data spočítáme maximálně věrohodný odhad: µk =
N X pki i=1
Σk =
N X pki i=1
pk
pk
xi
(xi − µk )(xi − µk )t
pk P (C = k) = Pk
j=1 pj
Lze dokázat, že se v každém kroku zvýší věrohodnost modelu. Nicméně tento důkaz je nad rámec této práce. Současná implementace používá knihovnu Mclust [14], která je pro akademické účely zdarma. V této knihovně je implementována i metoda na odhad optimálního počtu shluků, respektive Gaussových funkcí. Tato knihovna je velmi robustní, pro naše účely až příliš. Z časových důvodů by bylo vhodné nahradit tuto knihovnu vlastní „odlehčenou“ verzí. Asymptotická složitost EM algoritmu je O(N 2 ). Z toho plyne potřeba velká data vzorkovat. Aktuálně beru 1/4 z celkového množství dat. Časovou složitost výpočtu pro různě veliké instance zachycuje tabulka 5.2 a graf obr. 5.2. Tabulka 5.2: Závislost doby výpočtu EM algoritmu na velikosti instance. Měření probíhalo na notebooku s dvoujadrovým procesorem Intel U7300 1.3Ghz se 4GB RAM, operační sytém Ubuntu 10.10, jádro 2.6.35. 2000
t[s] 30,7 126,3 336,1 735,9 1 285,3 1 937,4
1500
t@sD
n[-] 10 511 19 197 28 627 38 176 53 675 60 229
1000
500
0 10 000
20 000
30 000
40 000
50 000
60 000
n@-D
5.3
Silhouette
Silhouette[30] [23] je metoda pro interpretaci a validaci shlukové analýzy. Jednoduchým způsobem zobrazuje jak dobře, která data zapadají do shluků, ke kterému jsou přiřazena. Každý bod je v ní reprezentován horizontální čárou 46
5.3. Silhouette na intervalu < -1,1 >. Čím blíže je hodnota jedničce tím spíše do shluku patří a naopak. Příklad výstupu můžete vidět na obrázku 5.4. Formálnější definice může vypadat například takto: Pro každé pozorování i, je šířka siluety s(i) definována následovně: a(i) = průměrnou odlišnost (Průměrnou odlišností, zde rozumíme Eukleidovskou vzdálenost, ale metriky mohou být různé.) mezi (i) a všemi ostatními body ve shluku do, kterého i náleží. Pokud je i jediným bodem shluku, pak a(i) =0. Pro všechny ostatní shluky C, d(i, C) = průměrnou odlišnost i, ke všem bodům náležejícím do C. b(i) = min(d(i, C)), pak nazvěme odlišností se sousedním shlukem. Zjednodušeně řečeno rozdíl mezi pozorováním i a nejbližším shlukem, do kterého i nepatří. Konečně : s(i) =
b(i) − a(i) max(b(i), a(i))
Pozorování s velkým s(i) (blízko 1) jsou velmi dobře zařazena, pozorování s malým s(i) leží na pomezí mezi dvěma shluky. Konečně pozorování se zápornou hodnotou s(i) jsou pravděpodobně zařazena ve špatném shluku. Příklad dobře a špatně pasující shlukové analýzy můžete vidět na obr. 5.4 respektive obr. 5.5. Silhoutte for 6 clusters 6 clusters Cj j : nj | avei∈C j si
Silhouette width si Average silhouette width : 0.86
Obrázek 5.4: Na grafu vidíte výstup z algoritmu Silhouette. Z grafu je patrné rozdělní dat do celkem šesti shluků, z nichž každý vykazuje jinou míru důvěryhodnosti. Čím blíže je vodorovná čára jedničce, tím více je jisté, že bod patří do konkrétního shluku. Průměrná důvěryhodnost rozdělení dat do shluků je zde 86%.
47
5. Klasifikace síťových toků
Silhoutte for 10 clusters 10 clusters Cj j : nj | avei∈C j si
Silhouette width si Average silhouette width : 0.72
Obrázek 5.5: Na grafu vidíte výstup z algoritmu Silhouette. Oproti předešlému obr. 5.4, se liší počtem shluků a zejména kvalitou rozdělení dat. Přestože je zde shluků více, důveryhodnost rozdělení je výrazně menší, pouze 72%. Zejména shluk šest dopadl velmi špatně.
Cílem algoritmu Silhouette je velmi rychle informovat o úspěšnosti shlukování. Abych dosáhl dostatečné rychlosti i pro velká data, používám postup podrobně popsaný zde [20]. Princip je velmi jednoduchý. Data jsou rozdělená do několika stejně velkých disjunktních podmnožin a analyzována zvlášť. Výstupem je pak sjednocení dílčích výsledků. Velikost podmnožiny určuji dynamicky jako zlomek původních dat. Při analýze realných dat jsem odhadl tyto hranice, při kterých se mění počty podmnožin: deset tisíc toků, padesát tisíc toků a sto tisíc toků. Jim odpovídají tyt počty podmnožin padesát, sto, dvěstě. Časovou složitost algoritmu Silhoutte ilustruje tabulka 5.3. Tabulka 5.3: Závislost doby výpočtu algoritmu Silhouttena velikosti instance. Na hodnotách jsou dobře patrné dva ze tří bodů, ve kterých se mění velikost analyzovaných podmnožin. n[-] 10 511 19 197 28,627 38 176 53 675
48
t[s] 0,57 0,62 1,49 2,64 1,24
n[-] 60 229 77 510 91 197 119 574 138 123
t[s] 1,58 3,05 3,22 1,96 2,05
5.4. Ukázka klasifikace
5.4
Ukázka klasifikace
V této kapitolce budu prezentovat použití pluginu Nfsen2R pro analýzu NetFlow dat od začátku do konce. Zaměřím se zejména na interpretaci výsledků, aby bylo zřejmé, co přesně výstupy z jednotlivých algoritmů znamenají. Jako příklad pro analýzu jsem si vybral reálná data ze síťě FIT ČVUT ze čtvrtka 1.3.2012 z 9:00 - 9:05. Tedy do políček time from a time to vložím string 201203010900. Jako algoritmus nechám defaultní count. Vyberu si kanál, v mém případě usptream. Spustím tlačítkem execute. Výstup je zatím zcela jasný, ve zvoleném časovém intervalu je celkem 25 637 toků. Myslím, že pro ukázku je to dostatečně velký vzorek. První algoritmus, který zvolím na osahání dat je Silhouette. Spustím jej pro 2-20 shluků. Tedy clus_from = 2 a clus_to = 20. Výstupem je 19 „siluet“, které vypovídají o kvalitě shlukování, část výstupu viz. obr. 5.6. I z těchto poměrně malých náhledů je vidět, že se důveryhodnost rozdělení dat, od 4 až do 6 shluků (horní řada), postupně zvyšuje. Přidáním sedmého shluku se situace výrazně zhorší. Přidáváním dalších shluků se příliš nezlepší. Ani s 20 shluky není analýza lepší, než se šesti. Přestože metoda Silhouette není dostatečně přesná, dává alespoň základní informace o rozdělění dat. Silhoutte for 4 clusters
Silhoutte for 5 clusters 4 clusters Cj j : nj | avei∈C j si
n = 300
Silhoutte for 6 clusters 5 clusters Cj j : nj | avei∈C j si
n = 300
6 clusters Cj j : nj | avei∈C j si
n = 300
1 : 201 | 0.80
1 : 207 | 0.81
1 : 220 | 0.75
2 : 23 | 0.23
2 : 25 | 0.21
3 : 20 | 0.99
2 : 35 | 0.78
3 : 30 | 0.99
3 : 16 | 0.98 4 : 29 | 0.31
0.0
0.2
0.4
0.6
0.8
1.0
4 : 16 | 0.69
4 : 17 | 0.98
5 : 35 | 0.99
5 : 21 | 0.59
-0.2
0.0
0.2
Silhouette width si
0.4
0.6
0.8
1.0
6 : 5 | 0.84 0.0
0.2
0.4
Silhouette width si
Average silhouette width : 0.72
1.0
Average silhouette width : 0.78
Silhoutte for 8 clusters 7 clusters Cj j : nj | avei∈C j si
n = 300
0.8
Silhouette width si
Average silhouette width : 0.77
Silhoutte for 7 clusters
0.6
Silhoutte for 9 clusters 8 clusters Cj j : nj | avei∈C j si
Silhouette width si Average silhouette width : 0.62
49
1.0
5. Klasifikace síťových toků Obrázek 5.6: Devět z celkem devatenácti siluet, které vypovídají o kvalitě rozdělení dat do shluků. Vybral jsem úsek od čtyř do dvanácti shluků. Z obrázků lze jasně vidět, že největší důveryhodnosti je dosáženo pro šest shluků (pravý horní roh). Další grafy jsou zde, aby bylo zřejmé, že přidávání shluků analýzu nemusí vždy zlepšit.
V dalším kroku použiji algoritmus K-means pro vizualizaci dat a základní shlukovou analýzu. Protože nejlepších výsledků bylo dosaženo pro šest shluků, nastavíme centers=6. Výsledek je na obr. 5.7. Protože shluková analýza proběhla na pětirozměrných datech, ale grafy jsou dvorozměrné, může zařazení některých prvků působit matoucím dojmem.
150 0
50
100
duration
200
250
300
6 -means clustering
0
500
1000
1500
2000
2500
source IP
Obrázek 5.7: Náhled na výsledek K-means, který ukazuje rozdělení dat do šesti shluků. Pro důkladnější analýzu využijeme Gaussovské směsy. Spustíme tedy algoritmus Expectation-Maximization. Součástí implementace z knihovny mclust, kterou používám, je i průzkum dat na „optimální“ počet shluků. Za tímto účelem použivá (Bayesian information criterion) BIC. Pro tento počet center proběhne nacvičení parametrů Gaussových funkcí. Výsledek shlukování, spolu s vyznačenými sférami vlivu jednotlivých Gassových křivek, lze vidět na obrázku 5.8. Na obrázku 5.9 je vyobrazena míra neurčitosti zařazení jednotlivých bodů. Čím větší a tmavší bod, tím více si klasifikátor není zařazením jistý.
50
5.4. Ukázka klasifikace
0
500
1000
1500
2000
2500
1,2 Coordinate Projection showing Classification
0
500
1000
1500
2000
2500
Obrázek 5.8: Graf znázorňuje barevně odlišené shluky dat. Dále jsou patrné sféry vlivu jednolivých Gaussových funkcí. Poslední dva obrázky graficky znázorňují hustotu dat. Obr. 5.11 využívá k zobrazení hustoty 3D model. Čím vyšší vrcholek, tím hustější data. Oproti tomu graf obr. 5.10 rozlišuje stupěn hustoty dat barevně. Světlejší barva znamená větší datové zastoupení v dané oblasti. Teď přibližně víme jaké je rozložení hustoty u dat, kde nedošlo k útoku. Z toho můžeme vycházet při detekci anomálií. Pokud například zaznamenáme růst hustoty okolo středu, je to známkou toho, že se na síti děje něco neobvyklého. Samozřejmě ne všechny anomálie se projeví mimo obvyklá data. Kromě rozložení hustoty známe také přibližný počet shluků. Pokud tedy zachytíme místo šesti, třináct shluků je jasné, že nám v síti bují podezdřelá aktivita. Obě tato kritéria budou dostatečná pouze na masivní útoky. Nicméně je považuji za dostatečné pro tento jednoduchý příklad. Pokud bychom chtěli detekovat pomalý port scan, případně jiný typ pozvolného útoku, je nezbytné vycházet ze znalosti historických dat. Také je potřeba si uvědomit, že v různou dení dobu bude vytížení sítě vykazovat jinou aktivitu. Důležitým faktorem není jen denní doba, ale také den v týdnu. Síť bude rozhodně ve všední dny více zatížena než o víkendu. Protože naše data pocházejí z vysokoškolské sítě, budou vykazovat odlišnosti i v rámci týdne. Většina studentů má například volné pátky a podobně. Faktorů, které lze použít pro detekci útoků, nebo obecněji anamolií na síti, je mnohem více. A s přibývajícími algoritmy jich bude ještě více. Zaleží tedy jen na důvtipu analytika, jak jich dokáže využít. 51
5. Klasifikace síťových toků
0
500
1000
1500
2000
2500
1,2 Coordinate Projection showing Uncertainty
0
500
1000
1500
2000
2500
0
500
1000
y
1500
2000
2500
Obrázek 5.9: Na grafu je znázorněna nejistota zařazení dat do shluků. Čím tmavší barva a větší bod tím více si je klasifikátor zařazením nejistý.
0
500
1000
1500
2000
x
Obrázek 5.10: Tento model zobrazuje rozložení hustoty dat pomocí barvy. Čím světlejší barva tím hustější je v té oblasti zastoupení dat.
52
5.4. Ukázka klasifikace
y
Z x
Obrázek 5.11: 3D model hustoty dat. Výše položené oblasti znázorňují vyšší hustotu dat.
53
Závěr Cílem práce bylo prostudovat technologie pro sběr síťových toků s použitím softwarového senzoru NfSen a vytvořit nástroj, s jehož pomocí bude možné snadno a pohodlně provádět analýzu toků pomocí NfSenu s využitím statistického výpočetního systému R. K dosažení tohoto cíle jsem navrhl a implementoval plugin pro NfSen, nazvaný Nfsen2R. Během rešerše možností propojení pluginů sondy NfSen s externím systémem R jsem nalezl několik překážek. Kromě komplikací s nedostatečnou, chybějící či chybnou dokumentací většiny existujících nástrojů byla hlavním problémem malá rychlost přenosu dat mezi NfSenem a R. Například při použití modulu Statistics::R přesně dle dokumentace [7] se jednalo rychlosti přenosu deset tisíc toků za přibližně šest minut. Vzhledem k tomu, že data ze sítě FIT ČVUT v odpoledních hodinách obvykle obsahují 90-120 tisíc toků za pět minut, trvalo by jen předání dat hodinu, což by bylo neúnosné. Další překážky, se kterými jsem se musel vypořádat, souvisejí s vlastní strukturou NfSenu, který používá málo flexibilní socketovou komunikaci s moduly v Perlu pro správu NetFlow dat. Příkladem omezené flexibility připojení těchto modulů s R je např. povinné úmístění obrázků s výsledky analýzy přímo do složky určené pro zdrojové kódy backendového moduly v Perlu. Tento a jiné podobné problémy jsou jen zdánlivě nepatrné, způsobují totiž komplikace při implementaci i nepříliš komplexních modulů v jazyce Perl. Přes všechna uvedená úskalí se mi v rámci této práce podařilo vytvořil funkční plugin pro propojení NfSenu s R, který má dostačující rychlost přenosu dat ve formátu Netflow mezi oběma systémy. Tento plugin umožňuje spouštět algoritmy napsané v R přímo z webového prostředí NfSenu. Abych demonstroval funkcionalitu pluginu a rychlost přenosu a zpracování dat, implemetoval jsem v něm tři vybrané klastrovací algoritmy: Silhouette, K-means a EM. Plugin je univerzální a je navržen tak, aby se dal velmi snadno rozšířit o mnoho dalších specializovaných i obecných algoritmů a metod pro zpracování dat v R. Velmi důležitým přínosem pluginu je tak jeho rozšiřitelnost, a to naprosto bez znalosti vnitřní struktury NfSenu. Ta z něj činí velmi perspektivní nástroj pro vývoj a testování data mining a statistických metod v síťové bezpečnosti. S použitím pluginu Nfsen2R se mi podařilo odhalit v domácí síti podezdřelou aktivitu na portu 5355. Tento port jsem před tím neznal. Zjistil jsem, že na 55
Závěr windows je rezervován pro protokol LLMNR, který slouží pro detekci strojů v lokální síti. Tento druh komunikace byl natolik častý, že z hlediska toků, přehlušil i datový provoz. Rozhodl jsem se tento protokol vypnout. Všechny stroje v lokální síti komunikují bez problémů dál, nicméně celkové vytížení sítě se výrazně snížilo. Za největší úspěch celé práce považuji předpočet features. Podařilo se nám celý proces optimalizovat natolik, že pro sto tisíc toků trvá méně než 10 vteřin. Měřeno na mém notebooku s procesorem Intel U7300 na 1,3GHz. Pro budoucí možné vylepšení pluginu bylo vhodné, aby si plugin udržoval historická data. Mohl by tak vytvářet profily normálního chování, či např. počet shluků klastrovací analýzy za poslední měsíc, nebo grafy rozložení hustoty dat. Vytváření profilů by usnadnilo odhalení anomálií, avšak vyžaduje nasazení databáze pro management profilů.
56
Literatura (1) CESNET: CESNET. 2012. Available at WWW: (2) CESNET: Flowmon. 2012. Available at WWW: (3) CESNET: Flowmon. 2012. Available at WWW: (4) Cisco: NetFlow - Cisco systems. 2012. Available at WWW: <www.cisco. com/go/netflow> (5) Cisco IOS NetFlow - Cisco Systems. Stav z 2012-04-29. Available at WWW: (6) co., T. S.: TIOBE Software BV. 2012. Available at WWW: <www.tiobe. com/> (7) CRAN: Statistics::R. 2012. Available at WWW: (8) Dempster, A.; Laird, N.; Rubin, D.: Maximum likelihood from incomplete data via the EM algorithm. Journal of the Royal Statistical Society. Series B (Methodological), 1977: pp. 1–38. (9) ELICH, M.: Rozšíření NetFlow kolektoru NfSen o detekci síťových anomálií [online]. Diplomová práce, Masarykova univerzita, Fakulta informatiky, 2009 [cit. 2012-04-30]. Available at WWW: (10) Ertoz, L.; Eilertson, E.; Lazarevic, A.; etc.: Detection of novel network attacks using data mining. In Proc. of Workshop on Data Mining for Computer Security, 2003. (11) Ertoz, L.; Eilertson, E.; Lazarevic, A.; etc.: Minds-minnesota intrusion detection system. Next Generation Data Mining, 2004: pp. 199–218. 57
Literatura (12) jQuery Foundation: jQuery. 2012. Available at WWW: (13) fprobe: fprobe. 2012. sourceforge.net/>
Available
at
WWW:
(14) Fraley, C.; Raftery, A.: MCLUST version 3 for R: Normal mixture modeling and model-based clustering. Technical report, Technical report, 2006. (15) Group, T. T.: tcpdump. 2012. Available at WWW: (16) Haag, P.: Watch your Flows with NfSen and NFDUMP. In 50th RIPE Meeting, 2005. (17) Hamerly, G.; Elkan, C.: Alternatives to the k-means algorithm that find better clusterings. In Proceedings of the eleventh international conference on Information and knowledge management, CIKM ’02, New York, NY, USA: ACM, 2002, ISBN 1-58113-492-4, pp. 600–607, doi:10.1145/584792. 584890. Available at WWW: (18) Hofstede, A., Rick Sperotto; Fioreze, T.: NfSen SURFmap plugin. 2012. Available at WWW: (19) ietf.org: The Internet Engineering Task Force. 2012. Available at WWW: (20) Kaufman, L.; Rousseeuw, P.; etc.: Finding groups in data: an introduction to cluster analysis, volume 39. Wiley Online Library, 1990. (21) Lee, W.; Stolfo, S.; SCIENCE., C. U. N. Y. D. O. C.: Data mining approaches for intrusion detection. Defense Technical Information Center, 2000. (22) Leiner, B.; Cerf, V.; Clark, D.; etc.: A brief history of the Internet. Arxiv preprint cs/9901011, 1999. (23) Maechler, M.; Struyf, A.; Hubert, M.; etc.: cluster: Cluster Analysis Extended Rousseeuw et al. Technical report, 2005. (24) mindrot.org: softflowd. 2012. Available at WWW: (25) Nagios: Nagios Ain’t Gonna Insist On Sainthood. 2012. Available at WWW: 58
Literatura (26) Novovičová, J.: Pravděpodobnost a základy matematické statistiky. ČVUT Praha, 2002. (27) nTop: nProbe. 2012. Available at WWW: (28) Rexer, K.: 4.th Rexer’s Annual Data Miner Survey. 2012. Available at WWW: (29) Roesch, M.: Snort. 2012. Available at WWW: (30) Rousseeuw, P.: Silhouettes: a graphical aid to the interpretation and validation of cluster analysis. Journal of computational and applied mathematics, volume 20, 1987: pp. 53–65. (31) Schram, W.: NfSen Botnet plugin. 2012. Available at WWW: (32) Skarnelis, J.: Fancybox. 2012. Available at WWW: (33) Tartakovsky, A.; Rozovskii, B.; Blazek, R.; etc.: A Novel Approach to Detection of Intrusions in Computer Networks via Adaptive Sequential and Batch-Sequential Change-Point Detection Methods. IEEE Transactions on Signal Processing, volume 54, 2006: pp. 3372–3382. (34) Tartakovsky, A. G.; Rozovskii, B. L.; Blažek, R. B.; etc.: Detection of intrusions in information systems by sequential change-point methods. Statistical Methodology, volume 3, no. 3, 2006: pp. 252–293. (35) wikipedia: Voroneho diagram. 2012. Available at WWW: (36) wikipedia.org: NetFlow - wikipedia. 2012. Available at WWW: (37) www.root.cz: Anonymous hrozí napadením DNS. Můžou uspět? 2012. Available at WWW: (38) www.zive.cz: Anonymous prý na konci března zastaví internet. 2012. Available at WWW: 59
Literatura (39) www.zive.sk: Útoky na web Úradu vlády SR vraj nespôsobili priame škody. 2012. Available at WWW:
60
Příloha
A
Seznam použitých zkratek ACTA Anti-Counterfeiting Trade Agreement, Obchodní dohoda proti padělatelství. ARPA Advanced Research Projects Agency (přejmenována na DARPA v r. 1972 a 1996). DARPA Defense Advanced Research Projects Agency, výzkumná agentura United States Department of Defense. DDoS Distribuovaný Denial of service. DoS Denial of service, techinka útoku, která se snaží vyčerpat cílům veškeré zdroje. EM Expectation-Maximization, algoritmus na nelineární regresi a shlukovou analýzu. ESP Encapsulating Security Payload, součást bezpečnostního standardu IPsec. FPGA Field-programmable gate array, programovatelné hradlové pole. HoP Host on Path, metrika pro směrování v síťích. GUI Graphical user interface, grafické uživatelské rozhraní. ICMP Internet Control Message Protocol. IP Internet Protocol. IPFIX IP Flow Information Export. IPsec Internet Protocol Security, sada protoklů, která má zaručit bezpečnost komunikace. 61
A. Seznam použitých zkratek IPv4 Internet Protocol verze 4. ISP Internet service provider, poskytovatel připojení k internetu. L3 Layer 3, třetí vrstva ISO OSI modelu. LLMNR Link-local Multicast Name Resolution protokol. MIT Massachusetts Institute of Technology. MINDS Minnesota intrusion detection system. NIDS Network intrusion detection system, systém pro detekci vniknutí do sítě. NIPS Network intrusion prevention system, systém pro prevenci vniknutí do sítě. P2P Peer to peer, označení typu počítačových sítí, kde spolu komunikují přímo jednotliví klienti. QoS Quality of Service, termín používaný pro rezervaci a řízení datových toků. RFC Request for Comments, používá se pro označení standardů popisujících Internetové protokoly. RRD Round-robin database, speciální typ databáze, který se zaměřuje na zpracování a ukládání časově závislých dat. SCTP Stream Control Transmission Protocol. SSH Secure Shell, síťový protokol pro bezpečnou komunikaci. TCP Transmission Control Protocol, síťový protokol, který zaručuje doručení paketů. UDP User Datagram Protocol, síťový protokol, který nezaručuje doručení paketů. XSS Cross-site scripting, je metoda narušení WWW stránek využitím bezpečnostních chyb ve skriptech (především neošetřené vstupy).
