Zpracování IP toků nástroji Elasticsearch a Kibana

Masarykova univerzita Fakulta informatiky

Zpracování IP toků nástroji Elasticsearch a Kibana Diplomová práce

Bc. Jana Němcová

Brno, jaro 2016

Místo tohoto listu vložte kopie oficiálního podepsaného zadání práce a prohlášení autora školního díla.

Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracovala samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používala nebo z nich čerpala, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Bc. Jana Němcová

Vedoucí práce: doc. Ing. Pavel Čeleda, Ph.D. i

Poděkování Na tomto místě bych ráda poděkovala doc. Ing. Pavelu Čeledovi, Ph.D. za cenné připomínky a odborné rady, kterými přispěl k vypracování této diplomové práce. Dále děkuji bezpečnostnímu oddělení CSIRTMU za poskytnuté informace a konzultace, především RNDr. Petru Velanovi, RNDr. Martinovi Husákovi a Tomáši Plesníkovi. Také bych chtěla poděkovat své rodině za trpělivost a podporu během studia. ii

Shrnutí Těžiště mé práce spočívá ve zjištění, zda trojici navazujících programů ELK (Elasticsearch, Logstash a Kibana) vytvořených obecně pro zpracování a zobrazení velkých objemů dat lze úspěšně využít i při specifických požadavcích na zpracování IP toků. Aby mohla být zpracovávána i data v reálném čase, musela jsem ale vytvořit propojení sondy a ELKu. Srovnávacím produktem je na IP toky specializovaný Flowmon. Porovnání s programy ELK provádím jak z hlediska funkcí, které podporují (s důrazem na funkce prakticky využívané v CSIRT-MU, HTTP analýzu a síťové útoky), tak i z hlediska vizualizačního. Součástí mé práce je i vytvoření nového vizualizačního rozšíření do Kibany, které vyžaduje specifické požadavky pro zobrazení IP toků.

iii

Klíčová slova IP tok, Elasticsearch, Kibana, Logstash, ELK, Flowmon, IPFIX, vizualizace, D3js

iv

Obsah Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Využití IP toků k analýze síťového provozu . . . . . . 2.1 Protokoly pro záznam IP toků . . . . . . . . . . . . . . 2.2 Nejznámější typy kolektorů . . . . . . . . . . . . . . . 2.3 Realizace propojení sondy s ELK . . . . . . . . . . . . 3 ELK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Logstash . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Elasticsearch . . . . . . . . . . . . . . . . . . . . . . . 3.3 Kibana . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Analýza možností pro práci s IP toky použitím ELK . 4.1 Porovnání z hlediska funkcí . . . . . . . . . . . . . . . 4.2 Porovnání z hlediska vizualizací . . . . . . . . . . . . 5 Rozšíření vizualizace . . . . . . . . . . . . . . . . . . . 5.1 Komunikační graf . . . . . . . . . . . . . . . . . . . . 5.2 Přidání vlastního grafu do Kibany . . . . . . . . . . . 6 Praktické ověření funkčnosti ELK pro práci s IP toky 6.1 TOPn statistiky . . . . . . . . . . . . . . . . . . . . . 6.2 Toky rozšířené o HTTP data . . . . . . . . . . . . . . 6.3 Analýza základních útoků . . . . . . . . . . . . . . . . 7 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . A Obsah elektronických příloh . . . . . . . . . . . . . . . B Instalace a konfigurační soubory ELK . . . . . . . . . . C Zdrojový kód komunikačního grafu . . . . . . . . . . . 1 2

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

1 3 4 7 10 15 15 17 18 22 22 34 36 36 39 42 42 44 47 51 53 57 58 62

v

1 Úvod Sledování toků dat v počítačové síti zajímá informatiky od síťových prvopočátků. Studovanými parametry bylo množství přenesených dat, rychlost přenosu, chybovost, zabezpečení přenášených dat a podobně. Ale až od roku 1991 se začalo uvažovat speciálně o IP tocích, a to ještě jen pro potřeby účtování za připojení. Časem se začaly vytvářet speciální nástroje na analýzu a zachytávání IP toků a protokoly pro komunikaci prvků sítě. Roku 1996 společnost CISCO vytvořila NetFlow protokol (RFC3954 [1]), který byl ale veřejně dostupný až roku 2004. Novějším protokolem je IPFIX (RFC7011 [2], RFC7015 [4]), byla na něm zahájena práce v roce 2008. Má více funkcí než NetFlow, např. dovoluje definovat vlastní formát dat. Tento protokol jsem použila během své práce. Pro zachycení paketů a tvorbu získaných informací o tocích se používají takzvané sondy. V dnešní době jakýkoliv směrovač, přepínač, virtuální stroj, firewall atd. dokáží fungovat jako sonda v síti (i když jen jako doplňková služba). Zachycená data zpracovat a posílat dále ke zpracování do nástrojů zvaných kolektory, kterými se v práci budu podrobněji zabývat. Jednou z jejich základních vlastností je schopnost efektivně ukládat velkoobjemová data, vyhledávat v nich, filtrovat je, agregovat a pod. Tyto vlastnosti budu podrobněji analyzovat a u dvou zvolených nástrojů (Flowmon a Elasticsearch) podrobněji porovnávat. Flowmon kolektor je kolektor speciálně určený pro zpracování dat ze sondy (údajů o IP tocích) [28] a v této práci ho porovnám se softwarem Elasticsearch, který je obecně navržen pro práci s velkými objemy dat. A právě zpracování rozsáhlých dat je společný prvek jak při práci s běžnými daty (databázemi), tak i při monitorování IP toků v síti. Pro obecné zpracování velkých objemů dat byla vytvořena trojice navazujících programů: Logstash, Elasticsearch a Kibana (ELK). Všechny tři programy vyvíjí firma Elastic, která poskytuje jejich kód jako open source, takže si je uživatel může přizpůsobit svým potřebám a přidat vlastní funkce. V této práci budu analyzovat možnosti použití ELK pro práci s IP toky a srovnám je s Flowmon kolektorem nejen z hlediska dostupných funkcí, např. možnosti analýzy dat, ale i z hlediska vizualizačního (gra1

1. Úvod fické nadstavby nad kolektorem) a uživatelského. Přitom náročnost a potřeby uživatele budou odpovídat požadavkům na analýzu IP toků v té úrovni, jak ji využívá bezpečnostní tým Masarykovy univerzity CSIRT-MU. Předpokládám, že v grafické nadstavbě Elasticsearch budou chybět výstupy specifické pro IP toky, proto vytvořím i příslušné vizualizační rozšíření. Chtěla bych také ověřit, zda je možné využít ELK při zpracování proudových dat v reálném čase za pomocí vlastního zapojení se sondou.

2

2 Využití IP toků k analýze síťového provozu Monitorování síťového provozu se rozděluje do dvou kategorií - pasivní a aktivní [13]. Aktivní zkoumá aktuální zatížení sítě, její odezvu, cestu paketů v síti, např. pomocí nástrojů Ping nebo Traceroute. Naopak pasivní jen čeká a měří toky dat, které projdou určitými měřícími body definovanými uživatelem. Pasivní monitorování lze rozdělit na další dvě skupiny, zachytávání paketů a sledování toků. Údaje ze sledování paketů poskytují mnohem více informací, ale ve vysokorychlostních sítích může být zachytávání a zkoumání paketů pomalé, drahé a náročné na hardware. Proto se začal používat jednodušší přístup a to agregace paketů do toků a zkoumání jednotlivých toků. Ty se také jinak nazývají IP toky podle monitorovaného protokolu. IP tok (flow) je sekvence paketů od zdrojového počítače (např. serveru) k počítači cílovému (host). Cílem paketů může být jen jeden host, multicastová skupina nebo třeba i celá broadcastová doména. Jeden tok je unikátně definován parametry zdrojová a cílová IP adresa, zdrojový a cílový port a protokol čtvrté vrstvy ISO/OSI modelu (např. TCP, UDP, ICMP). Všechny pakety se stejnou IP adresou zdroje, IP cíle, portu zdroje a cíle jsou tedy považovány za jeden tok. Rozlišení jednotlivých toků je důležité ať už pro zaručení potřebné kvality přenosu nebo oddělení front ve směrovačích, přepínačích, ale také při monitorování sítě. Např. UDP protokol tvoří jen jednosměrné kanály a naopak ICMP a TCP jsou obousměrné, ale v zásadě se neurčuje směr toků, jen jejich existence. Obousměrná komunikace se projeví jako dva IP toky, ale lze je i spárovat na kolektoru [29]. Pakety

Zachycení a export informací o síti (sonda)

Protokol (IPFIX, NetFlow)

Sběr a uložení dat (kolektor)

Analýza a zobrazení dat

Obrázek 2.1: Architektura analýzy toků Proces zkoumání toků se skládá z několika fází (viz. obrázek 2.1). První je pozorování, kdy jsou pakety zachyceny. Druhá je zpracování vybraných informací z paketů a jejich agregování do toků. Tyto údaje jsou pak dále posílány pomocí příslušných protokolů, např. NetFlow nebo IPFIX. Třetí fází je uložení dat a zobrazení statistik. Poslední 3

2. Využití IP toků k analýze síťového provozu fází je analýza, ať už manuální, kdy uživatel sám filtruje jednotlivé údaje, nebo automatická pomocí různých nástrojů. První dvě fáze může vykonávat stejné zařízení. Kritickým problémem je porozumět tokům, rozhodnout se, které informace jsou přínosné, jak je názorně zobrazit, aby z nich šly vyčíst důležité informace (anomálie, přetížení, útoky), případně jaká je vhodná odezva. Zkoumání toků přináší ještě jednu zásadní výhodu - většinou nepotřebuje žádný speciální hardware, protože bylo zjištěno [13], že 70% všech zařízení jako jsou směrovače, přepínače a firewally podporují flow export, na rozdíl od analýzy paketů, ke které potřebujeme externí zařízení. Další výhodou zkoumání toků je zmenšení objemu dat ať už posílaných flow statistik po síti, nebo uložených pro pozdější analýzu útoků a detekci malware. Tento objem dat, i je když ve srovnání s analýzou vlastních paketů řádově menší, pořád představuje velký objem. Proto se i pro toky používají techniky tzv. big data a pro uložení a práci s nimi se využívají speciální nástroje. Vzhledem k těmto vlastnostem jsou toky používány pro ukládání údajů o síťovém provozu. Například evropští poskytovatelé sítě mají zákonnou povinnost uchovávat tyto údaje o tocích i několik let zpětně [13]. Důležité je i to, že se při analýze paketů prohlíží i obsah samotného paketu, což by mohlo být v rozporu s platnou legislativou (osobní údaje). Při analýze toků se zkoumá jen hlavička paketu, která neobsahuje privátní informace.

2.1

Protokoly pro záznam IP toků

Nejrozšířenější jsou dva protokoly - IPFIX a NetFlow. NetFlow NetFlow je protokol vyvinutý společností Cisco Systems pro monitorování provozu na základě IP toků. Původně sloužil jen jako doplňková služba v Cisco směrovačích. Nejpoužívanější verze protokolu NetFlow byla označována číslem 5, předchozí se příliš nerozšířily. Struktura dat posílaných NetFlow se nazývá záznam a ve verzi 5 obsahuje tyto položky [22]: 4

2. Využití IP toků k analýze síťového provozu ∙

čas začátku IP toku (posláno jen u prvního paketu),

∙

počet bajtů a paketů v toku,

∙

sekvenční číslo,

∙

SNMP index vstupního a výstupního rozhraní (pomáhá sledovat vytížení jednotlivých zařízení v síti),

∙

údaje z třetí vrstvy - zdrojová a cílová IP adresa a port, IP protokol, druh služby,

∙

směrovací informace - adresa příštího hopu a maska cílové a zdrojové IP adresy,

∙

v případě TCP toků ukazuje ještě TCP příznaky (flags).

Internet Kolektor Sonda (směrovač)

LAN

LAN

Obrázek 2.2: NetFlow architektura Protokol NetFlow verze 9, který je v dnešní době aktuální, umožňuje navíc definovat flexibilní formát obsahující i nové položky jako jsou např. informace o IPv6, MAC adresy a pod. Přesná definice protokolu je v RFC 3954 [1] z roku 2004. NetFlow architektura se skládá z dvou komponent [20]. První je sonda (NetFlow agent, exportér), která vytváří toky a po agregaci je 5

2. Využití IP toků k analýze síťového provozu posílá k analýze na druhou komponentu - kolektor. Ten je uloží pro pozdější použití. Funkci sondy mohou plnit směrovače, přepínače, firewally a jiná zařízení, ale kvůli velké zátěži, které sledování paketů může představovat, je lepší používat zařízení externí. Zvolené řešení má také výhodu v tom, že zařízení je v síti odstíněno a není vidět z vnější strany sítě, a proto nemůže být cílem útoků. Sonda si do paměti toků (flow cache) ukládá informace o všech aktivních tocích a každý tok dostane unikátní klíč. Příchozí paket je pak přes hashování přiřazen klíčem ke správnému toku. Když se nový paket přiřadí k již existujícímu toku, pozmění se informace o toku (jako např. počet paketů toku). Když se tok v paměti nenajde, vytvoří se nový záznam s klíčem. Tok je uložen v paměti až do přednastavené doby expirace. Máme několik metod [13], jak stanovit konec toků. Např. předem nastavíme dobu trvání typicky v řádů sekund až minut, tzv. aktivní time-out. Po ukončení této doby budou pakety patřit do nového toku. Jinou variantou stanovení konce toku je zvolení časového intervalu, po který není zachycen žádný paket, tzv. neaktivní timeout. Speciální metodu nalezneme u TCP paketů (na rozdíl od UDP), kde počáteční paket má v příznacích značku FIN a poslední RST. Nastavení timeoutů je velice důležité, může ovlivnit velikosti toků a tím i zkreslit výsledky pozdější analýzy. Sondy odesílají statistiky v několikaminutových intervalech, aby nepřetěžovaly síť, ale přesto hovoříme o sledování sítě v reálném čase. Sondy se většinou nacházejí v důležitých částech sítě - uzlech, kde probíhá velké množství komunikace (např. u směrovače nebo směrovač samotný). Naopak kolektor lze umístit kdekoliv v síti a může získávat data z několika sond ve stejném čase (přes různá rozhraní). Uživatel pak využívá většinou ještě další aplikace k lepšímu zobrazení a vyhodnocení uložených údajů. Nevýhodou NetFlow verze 9 je malá flexibilita, protože se mohou používat pouze údaje předdefinované společností CISCO. Z toho vznikl další, nyní uživateli stále oblíbenější protokol IPFIX (Internet Protocol Flow Information Export) [19], který umožňuje v záznamech definovat vlastní pole.

6

2. Využití IP toků k analýze síťového provozu IPFIX Jako každý protokol i IPFIX má definováno, jak by měly být informace o tocích formátovány a jak přenášeny po síti ke kolektoru. Přesná specifikace protokolu IPFIX je definována v RFC 7011 [2], RFC 7015 [4] a RFC 5103 [5]. IPFIX definuje tok jako posloupnost paketů v určitém časovém rámci se stejným zdrojem, cílem a protokolem na třetí vrstvě. IPFIX patří do kategorie push protokolů, což znamená, že každá sonda periodicky posílá zprávy, aniž by o ně musel kolektor žádat. IPFIX umožňuje vybrat z hlaviček IP paketů jen určitá pole, jejich počet si může uživatel zvolit. Také lze definovat vlastní pole, například pro toky rozšířené o HTTP informace [31], které budu používat v kapitole 4. Díky této flexibilitě polí je velice využíván.

2.2

Nejznámější typy kolektorů

Je mnoho kolektorů s různými vlastnostmi [13]. Nejpoužívanější jsou SiLK, ntop, IPFIXcol, NFDUMP a Flowmon kolektor, které v následujících řádcích rozeberu. SiLK SiLK je jedním z nástrojů sloužících jako kolektor. Byl vyvinut organizací CERT NetSA [8]. Jako všechny kolektory i tento podporuje sběr a ukládání IP toků. Software se skládá ze dvou částí - systému, který sbírá data ve formátu IPFIX či NetFlow a přeformátuje je do efektivního formátu k uložení. Druhá část umožňuje tvořit dotazy nad uloženými daty, filtrování a analýzu. Na rozdíl od ostatních nástrojů podporuje strukturovaná data dle RFC 6313 [3]. Používá se převážně v USA. ntop Kolektor ntop [24] zobrazuje aktuální zatížení sítě, a to jak pro IP sítě, tak i pro protokoly, které IP adresu nepoužívají (ARP, RARP). Je možné ho použít i jako sondu s předdefinovanou vrstvou k měření druhé síťové vrstvy (MAC), ale lze ho použít i pro třetí (TCP/IP). K zobrazení 7

2. Využití IP toků k analýze síťového provozu dat potřebuje jen webový prohlížeč. Ntop nebyl navržen pro velké či rychlé sítě, a proto je v těchto případech výhodné použít jako sondu nProbe a data si v ní předzpracovat. nProbe [25] je sonda, která podporuje IPFIX a NetFlow a na rozdíl od výše zmíněného SiLKu umožňuje různou délku kódování dat v IPFIX, protože IPFIX obsahuje šablony pro vytvoření vlastní datové struktury s variabilní délkou, což šetří místo. Výhodnou vlastností nProbe je možnost exportu toků do MySQL, SQLite databází či do textových a binárních souborů. Je vytvořen pro prostředí s limitovanými zdroji a vestavěnými systémy. Nejnovější verze ntopu se nazývá ntopng [26]. Je napsána v přenosném kódu na všechny operační systémy. Má vysoký výkon a vyžaduje menší zdroje na rozdíl od původního ntopu.

IPFIXcol IPFIXcol [30] byl vytvořen CESNETem z důvodu různých potřeb pro úložiště formátů dat (mění formát dat dle potřeby), data ukládá do sloupcové databáze jako jeden z mála, protože ostatní nástroje využívají pro uložení dat spíš binární soubory. IPFIXcol je kolektor, který podporuje data v IPFIX formátu, a to i s rozšířením (jako je například výše zmíněná variabilní délka kódování dat). Je vytvořen pro velké sítě a podporuje data z různých zdrojů najednou. IPFIXcol jako prostředek pro změnu dat jsem použila ve svém zapojení, které je popsáno níže.

NFDUMP Jeden z nejčastěji používaných open-source nástrojů na sběr dat je NFDUMP [14], který se skládá ze 6 podprogramů, z nichž dva nejdůležitější jsou nfcapd, který čte data IP toků ze sítě a ukládá je do souboru, a nfdump, který čte data uložená nfcapdem, data zobrazuje a provádí základní statistiky. Existuje i grafická nadstavba nfsen. NFDUMP podporuje IPFIX formát i NetFlow data verze 5 a verze 9 a je kompatibilní s IPv6. 8

2. Využití IP toků k analýze síťového provozu Sonda

NfCapd

Datové úložiště

Sonda

NfDump

NfSen

NfCapd

Datové úložiště

Sonda

NfCapd

Datové úložiště

Obrázek 2.3: NFDUMP architektura Zdroj: upravená verze http://nfdump.sourceforge.net/overview.gif

Flowmon kolektor Firmou Flowmon byl kolektor NFDUMP rozšířen o další funkce a GUI a je používán pod názvem Flowmon kolektor. Flowmon kolektor [17] je realizován jako server, který sbírá, ukládá, analyzuje a zobrazuje síťová data ze sondy [16]. Pro ochranu dat a zvýšení výkonu podporuje RAID technologie, a proto se hodí i pro velké sítě. Vizualizační prostředí umožňuje nastavení filtrů, agregací a časového okna. Vzhledem k tomu, že monitoruje veškerou komunikaci, umožňuje i nastavení zasílání automatického upozornění při určité události definované uživatelem. Flowmon používá REST API a podporuje kromě IPFIX formátu dat i NetFlow v5/v9 a mnoho dalších R NetStream, jFlow aj.). (sFlow○, Firma Flowmon nabízí i speciální rozšíření jako jsou DDoS Defender, sondy, kolektory, Traffic Recorder, ale i samotnou analýzu provozu. Tyto nástroje nad protokolem IPFIX používá bezpečnostní tým Masarykovy univerzity a já jsem je porovnávala s druhou variantou analýzy pomocí Logstash a Elasticsearch. Logstash a Elasticsearch Druhou možností, kam odeslat data ze sondy, je využití programů Logstash do Elasticsearch (a následně i Kibany), viz obrázek 2.4. Toto propojení není běžné, bylo vytvořeno pro potřeby mé diplomové práce. 9

2. Využití IP toků k analýze síťového provozu

log Záznamy

Logstash 1.5.4

ElasticSearch 2.3.1

Kibana 5.0.0

Obrázek 2.4: ELK schéma dávkového zpracování Logstash spravuje načítání dat do Elasticsearch, který má na starosti uchovávání dat a efektivní a rychlé operace (filtrování, agregace...) s daty. Elasticsearch je open-source kolektor dat, který ale není primárně určen pro zpracování flow dat ve formátu IPFIX a používá pro komunikaci a ukládání svých dat formát JSON. Z toho důvodu je třeba použít jako převodník dat IPFIXcol, aby změnil formát dat z IPFIX na JSON. Pro filtrování dat a vkládání do Elasticsearch se používá Logstash. Schéma zapojení je na obrázku 2.5. Pro grafické zobrazení uložených dat se používá Kibana. Instalace ELK (Elasticsearch, Logstash, Kibana) je popsána v příloze B.

2.3

Realizace propojení sondy s ELK

Data, se kterými jsem pracovala, jsem získala ze sondy buď jako uložený soubor (log ze sondy), nebo jako data zasílaná v reálném čase. V obou případech jsem použila IPFIXcol 0.9.0 a Logstash 1.5.4 na změnu formátu pro zpracování v Elasticsearch 2.3.1. Při načítání dat ze souboru nenastal žádný větší problém. Konfigurační soubor pro Logstash je v příloze B. Případně se data dají načíst i příkazem přes příkazovou řádku s vloženým nastavením uvnitř: $ cat 1000 k . log | ./ Logstash / Logstash -1.5.4/ bin / Logstash -e ’ input { stdin { codec = > " json_lines "}} output { elasticsearch { host = > " localhost :9200" protocol = > " http " codec = > " json " }} ’ -v

10

2. Využití IP toků k analýze síťového provozu IPFIXcol 0.9.0

FlowMon Probe v8.01.00

Pakety

Flowmonexp 4.0.22

IPFIX

JSON

Kibana 5.0.0

ElasticSearch 2.3.1

Logstash 1.5.4

Obrázek 2.5: Schéma zpracování IP toků pomocí ELK Kde 1000k.log je soubor se záznamy, kodek je json a Elasticsearch pracuje na portu 9200. Při zpracování proudových dat, která pochází ze sondy Flowmon Probe v8.01.00, se vyskytly potíže s formátem polí dat. Elasticsearch nepodporuje v názvu atributu pole určité znaky (např. „.“). Kolektor ale posílá data např. s názvem atributu ipfix.ipVersion, proto jsem musela využít funkcí Logstashe umožňujících přejmenovat název atributu, např. na ipVersion. Také jsem vyřadila některá pole, např. pole s HTTP odkazem, protože občas obsahoval nepovolené znaky. Stejně tak jsem nemohla použít ani pole pro začátek a konec toku v milisekundách, protože Elasticsearch měl problém se zpracováním tak velkého čísla jako datový typ int. V nastavení jsem proto musela použít přetypování na datový typ long. Konfigurační soubor pro Logstash je v příloze B. Pro proudová data je řetězec zpracování IP toků pomocí ELK zobrazen na obrázku 2.5. Při sběru dat jsem pracovala s exportérem Flowmonexp 4.0.22, který využívá též Flowmon kolektor. Ten posílá data v IPFIX formátu do interface IPFIXcol, který je převede na JSON formát dat a pošle 11

2. Využití IP toků k analýze síťového provozu Date_first_seen: 2014-01-16T12:49:10.008+01:00 Date_last_seen: 2014-01-16T12:49:15.175+01:00 Duration: Src_ip_adress:

5.167

Dst_ip_adress:

63.41.XXX.XXX

Src_port:

37

Dst_port:

80

Protocol: Flags:

..A..SF

Tos: Packets: Bytes:

63.190.XXX.XXX

6 0 4 168

Obrázek 2.6: Struktura dávkových dat do Logstash. Jednotlivé řádky dat (záznam jednoho toku) ve formátu JSON se filtrují a upravují (např. změna názvu) a posílají na uložení do kolektoru Elasticsearch. Na konci řetězce je grafické rozhraní Kibana, která data zobrazuje. Jako alternativa místo Logstash a IPFIXcol lze použít NetFlow Integrator [23].Vznikl pro sjednocení různých flow protokolů jako jsou NetFlow, IPFIX, sFlow a pomocí algoritmů je převede na standardní formát Syslog nebo JSON. Data poté odešle do společného úložiště. Umožňuje proudovou analýzu dat. Měla jsem dávková data a proudová. Z dávkových dat (ze souboru) byly již odfiltrovány nedůležité informace. Proudová data obsahovala veškeré informace přímo zaznamenané a zaslané sondou. Struktura základních dat je na obrázku 2.6. Struktura rozšířených dat se liší podle typu protokolu na dvě skupiny - TCP a UDP. Protokol TCP je znázorněn v obrázku 2.7 a jeho rozšíření o HTTP data je na obrázku 2.8. Obsažená pole jsou nadefinová organizací IANA. Možnosti polí jsou zveřejněny na webu organizace IANA [18].

12

2. Využití IP toků k analýze síťového provozu

Timestamp:

April 21th 2016, 18:50:15.288

Type:

ipfix.entry

Version: Id:

1

Index:

logstash-2016.04.21

AVQ5uqzlmqaOuPF0YxCZ

Score: Type:

logs

DestinationIPv4Adress:

163.215.243.242

DestinationTransportPort: 28548 EgressInterface:

0

Host:

147.251.14.45

IngressInterface:

10

IpClassOfService:

0

IpTTL:

61

IpVersion:

4

OctetDeltaCount:

4260

PacketDeltaCount:

8

ProtocolIdentifier:

TCP

SamplingAlgorithm:

0

SamplingInterval:

0

SourceIPv4Address:

108.196.153.84

SourceTransportPort:

443

TcpControlBits:

Obrázek 2.7: Struktura TCP dat

13

2. Využití IP toků k analýze síťového provozu

Timestamp:

March 15th 2016, 14:09:33.064

Type:

ipfix.entry

Version:

1

HTTPRequestHost:

travel.tile.appex.bing.com

HTTPRequestHostReferer: HTTPRequestType:

1

HTTPRequestURL:

/api/livetile.xml?language=cs-CZ®ion=CZ

HTTPResponseCode:

0

HTTPResponseType: Id:

AVN6ZU-luX_tR7CCDad4

Index:

logstasg-2016.03.15

Score: Type:

logs

DestinationIPv4Adress:

195.113.XXX.XXX

DestinationTransportPort: 80 EgressInterface:

7

Host:

147.251.XXX.XXX

IngressInterface:

7

IpClassOfService:

0

IpTTL:

126

IpVersion:

4

OctetDeltaCount:

321

PacketDeltaCount:

4

ProtocolIdentifier:

TCP

SamplingAlgorithm:

0

SamplingInterval:

0

SourceIPv4Address:

147.251.XXX.XXX

SourceTransportPort:

52277

TcpControlBits:

26

Obrázek 2.8: Struktura TCP dat s HTTP

14

3 ELK Jak Logstash, tak Elasticsearch i Kibana (zkráceně ELK) jsou open source programy vyvíjené firmou Elastic, která se specializuje na zpracování a zobrazování velkých objemů dat v reálném čase pomocí proudového zpracování. Tato firma vydává i různá rozšíření k základnímu ELK, např. Watcher, viz. kapitola 4.1, Shield, který přidává šifrování, autentizaci, auditing a kontrolu přístupových práv k Elasticsearch. Zajímavý je také program Beats, který má stejné funkce jako Logstash, ale umožňuje ještě lepší načítání různých vstupů dat. Tento program je poměrně nový z roku 2015. Na obrázku 3.1 je podrobnější zapojení jednotlivých částí ELKu. Znázorněna je forma komunikace i jednotlivé funkce. Popis jednotlivých částí je uveden v následujících odstavcích. logy NetFlow JMX ...

Uchování dat Clustery, JSON

Úprava dat JSON

Logstash 1.5.4

Zobrazení dat REST rozhranní

Query DSL

ElasticSearch 2.3.1

Kibana 5.0.0

Obrázek 3.1: Schéma fungovaní ELK ELK je nový a velice rychle se vyvíjející nástroj, což chci ukázat na příkladech vývoje jednotlivých částí ELKu popsaných v dalším textu.

3.1

Logstash

Pomocí Logstash [10] můžeme převádět formáty zaznamenaných dat (Apache logs, syslog, Windows event logs, NetFlow, JMX) z databází i proudů na množství jiných, přičemž během přenosu lze data filtrovat a odstraňovat chybně naformátovaná data (pattern matching). Logstash dokáže data z různých operačních systémů normalizovat a převést na stejný formát. Dostupné jsou rozšiřující pluginy, kterých je přes 200 a lze doprogramovat i vlastní. 15

3. ELK Pro vložení dat je potřeba vytvořit vlastní konfigurační soubor, který obsahuje položky input pro nastavení vstupních dat a output pro data výstupní. V nich se nastaví např. stdin { } pro standardní vstup (typicky klávesnice), stdout { } pro standardní výstup (typicky terminálový výstup) nebo v mém případě Elasticsearch { hosts = > [" localhost :9200"] }

což je odkaz na Elasticsearch, který pracuje na portu 9200. Tento soubor může mít i položku filter, která data upraví. Má např. položky remove pro vymazání záznamů, add_field pro přidání, match pro shodu dle zadané podmínky, např. date { match = > [" timestamp " ," dd / MMM / yyyy : HH : mm : ss Z "]}

když chceme data jen z dnešního dne. Logstash pracuje s výrazy pro datum a čas. Také lze vkládat podmínky typu „if - else“, „in“, „!=“ a mnoho dalších. Díky těmto možnostem lze přijímat prakticky jakákoliv data. Popis zpracování mých dat je v kapitole 2.3 a přesný popis mých konfiguračních souborů, stejně tak jako návod na instalaci, je uveden v příloze B. Konfigurační soubor se pak načte pomocí příkazu: $ / bin / Logstash -f config_file_name . conf

Užitečná je i možnost kontroly konfiguračního souboru přes přepínač –configtest. Vývoj První Logstash vyšel 26. února 2014 (Kibana vyšla o pár měsíců později). Bohužel předchozí verze nejsou moc dobře zdokumentované. Předposlední verze 2.3.01 ze dne 30. března 2016 přinesla změnu v načítání konfiguračního souboru. V původní verzi změna konfiguračního souboru znamenala restart celé aplikace. V této se dá použít přepínač –auto-reload, který konfigurační soubor načítá automaticky defaultně každé 3 sekundy. Umožňuje také uložení proměnných a díky přepsání části kódu do jazyka Java tak došlo ke zrychlení až o 75%. Bohužel 1.

www.elastic.co/blog/logstash-2-3-0-and-2-2-3-released

16

3. ELK předchozí verze obsahovala mnoho chyb a tak vývojáři doporučují ji aktualizovat na verzi 2.3.1 ze 7. dubna 2016, která tyto chyby opravila.

3.2

Elasticsearch

Elasticsearch [9] je vyvíjen na platformě Javy (Lucene) pod licencí Apache a má RESTful rozhraní, kterým komunikuje s Kibanou. Platforma Lucene umožňuje fulltextové vyhledávání nad daty. Dotazovací jazyk se nazývá Query DSL a umožňuje data filtrovat, agregovat a je založen JSON struktuře. Bližší popis jazyka je uveden v kapitole 4.1. Elastic používá bezschémovou databázi - struktura databáze se vytvoří sama na základě vložených dat. Data ukládá do tzv. clusterů, které se dají libovolně rozšiřovat dle množství dat. Při výpadku clusteru se data automaticky seskupí, aby byla rozložena rovnoměrně. Jednotlivé záznamy dat jsou uchovány ve strukturovaných JSON dokumentech a všechna pole jsou ve výchozím nastavení indexovaná [27]. Návod na instalaci Elastisearch 2.3.1 je v příloze B. Elasticsearch-head Elasticsearch má jedno užitečné rozšíření, které se nazývá Elasticsearchhead [6], autorem je Ben Birch. Jedná se o velice jednoduché grafické rozhranní, které umožňuje data prohlížet a provádět s nimi základní operace. Rozhraní také zobrazí jednotlivé soubory a jejich velikost. Data můžeme pomocí dotazů v jazyce JSON i filtrovat a použít na ně základní metody - GET, PUT, POST a DELETE. Vývoj Firma Elastic začala jako první s vývojem Elasticsearch a dne 8.února 2010 vydala verzi 0.4.0 a hned další měsíc 5. března 2010 vydala verzi 0.5.0, která nově nabízela i automatickou tvorbu indexů, filtrování dle termů, řetězců a jiné. V dalším vývoji stojí za zmínku verze 1.3.0 z 23. července 2014, která přidala agregace a také možnost spouštět vlastní skripty vložené v souboru templates. 17

3. ELK Elasticsearch 1.4.02 byl vydán přibližně v době, kdy vznikla i první Kibana. Přidávala agregaci součtů přes jednotlivé podagregace. 23. března 2015 vyšel Elasticsearch 1.5.0, který přinesl možnost použít i časovou zónu pro vyhledávání a vylepšené časové rozsahy. Dalším milníkem je verze 2.0.03 z 28. října 2015, která opravila mnoho chyb ať už v javě samotné, v mapování dat či zabezpečení REST komunikace. Nejnovější verze Elasticsearch 2.3.0 4 vyšla 30. března 2016 a přinesla celou dávku opravených chyb. Opravilo se třeba opakované načítání modelu grafu při změně parametrů. Elasticsearch nabízí hodně funkcí a neustálým zlepšováním je přizpůsobený na práci s velkým množstvím různorodých dat. Novinkou je vylepšení Lucene verze z předchozí 5.4.1 na novější 5.5.0. Zajímavostí je také to, že v současnosti Elasticsearch s verzí 2.3.0. vyvíjí zároveň verzi 5.0.0-aplha15 , která je brána jako testovací, ale je veřejně dostupná a funkční, a uživatelé si ji mohou stáhnout, otestovat či i „naostro“ používat. Běží na nové verzi platformy Lucene 6 (verze předtím fungují na Lucene 5), která umožňuje dimenzionální data stromovou strukturu dat. Nově bude umožněno základní vkládání dat přímo do Elasticsearch bez použití Logstash. Nová užitečná vlastnost je i možnost ukládání celé haldy (heap paměti), takže se zamezí okamžité ztrátě dat a nastavení, když si uživatel omylem něco změní.

3.3

Kibana

Kibana je open source nástroj pro zobrazování grafů na základě dat poslaných z Elasticsearch. Díky tomu je schopna spolupracovat s Elasticsearch a je výkonným prostředkem pro rychlou tvorbu tabulek, histogramů, grafů atd. Vytvořené grafy se dají vložit do grafických přehledů (dashboards), které nám umožňují změnou údajů v jednom grafu ovlivnit grafy 2. www.elastic.co/downloads/past-releases/elasticsearch-1-4-0 3. www.elastic.co/guide/en/elasticsearch/reference/2.0/release-notes-2.0.0beta1.html 4. www.elastic.co/guide/en/elasticsearch/reference/2.3/release-notes2.3.0.html 5. www.elastic.co/blog/elasticsearch-5-0-0-alpha1-released

18

3. ELK ostatní. Vlastní dashboardy lze uložit i sdílet přes url a uložit do Elestacsearch. Kibana je založena na JavaScriptu a HTML, které jsou dostupné prakticky na každé klientské stanici. K Elasticsearch je propojena přes REST rozhraní. To, že nepotřebuje ke spuštění žádný výkonný server, je její velká výhoda. Zkušenější uživatel může nastavit dashboardy a ostatní je mohou už jen používat, aniž by museli rozumět práci s grafy dashboardu. Zajímavou vlastností Kibany je možnost exportu grafu a vložení do iframe. Návod na instalaci Kibany 5.0.0 je v příloze B. Vývoj První Kibana byla vydána 26. února 2014 pod názvem Kibana 3.0.06 . Předtím byla součástí Elasticsearch jako rozhraní, ale tvůrci se rozhodli ji rozšířit a vyvíjet samostatně.

Obrázek 3.2: Kibana 3.0.0 - uživatelské rozhraní Zdroj: www.elastic.co/assets/bltad8aa4eaa6a65ab9/ Screen-Shot-2014-02-25-at-4.42.52-PM-1024x557.png

Kibana již měla specifickou tvorbu vlastních panelů. Jako první se načetla data, která bylo možné pomocí zaškrtávacího pole fields filtrovat a pak bylo možné zvolit, v jakém grafu je chceme zobrazit. Na 6.

www.elastic.co/guide/en/kibana/3.0/index.html

19

3. ELK výběr bylo mezi column - sloupci, histogramem, mapou, koláčovým grafem, tabulkou a obyčejným textem. Kibana 4 - třetí beta verze vyšla 18. prosince 2014. Oficiální Kibana 4.0.0 vyšla až 19. února 2015. Nabízí kromě nového vzhledu i více možností jak filtrovat data. Nově přidala i Area Chart - to je plošný graf, dále pak Line Chart - spojnicový (čárový) graf, Vertical Bar Chartsloupcový graf, Tile map - zobrazení mapy se státy s možností přiblížení. Funguje drag and drop pro přesun jednotlivých grafů (není už šipka jako v předchozích).

Obrázek 3.3: Kibana 4.0.0 - uživatelské rozhraní Zdroj: www.elastic.co/assets/blt5dddb0351d09a397/ Screen-Shot-2015-02-17-at-1.25.15-PM-1024x692.png

Dále došlo k vylepšení agregací dat z hlediska kardinality, rozsahu, významných termů (hodnot), percentilů. Dají se také uložit vyhledávací skripty, které se mohou spustit přímo za běhu. Další vylepšení nalezneme při ukládání vizualizací, kdy je možné uložit pouze link na ni. U koláčových grafů lze jednotlivé výsledky dále dělit, teoreticky donekonečna. Z hlediska výkonu se zredukoval počet HTTP volání potřebných pro načtení stránky. Zabezpečila se komunikace ze strany klienta SSL 20

3. ELK protokolem. Data jsou exportována formátu do CSV nebo JSON. Je také možnost zobrazit komunikaci mezi Elasticsearch a Kibanou. Kibana 4.0.1 byla vydána 4. března 2015, 4.0.2 13., dubna 4.0.3 9., června a hned další den vydali Kibanu 4.1.0. Přidali nově Bubble chart - bublinkový graf, jakousi derivaci od bodového, Heatmap - teplotní mapu. Dá se nastavovat formát jednotlivých polí, přibyla nová agregace dle IPv4, export jednotlivých objektů - vizualizací, dashbordů a výsledků. Další Kibana, která přinesla větší změny, byla vydána 24. listopadu 2015 a vyžaduje min. Elasticsearch verze 2.1, protože se změnilo parsování datumů. V Kibaně se to projevilo vylepšeným rozhraním pro práci s datumy. Mnoho dalších změn se ale neobjevilo, jen podpora všech časových zón, možnost vlastních JSON souborů a názvu filtrů. Předposlední verze Kibany 4.4. je z 2. února 2016. Vylepšuje hledání dle datumů a opravuje další chyby7 . Důkazem, že Elastic se snaží Kibanu co nejlépe přizpůsobit potřebám uživatelů, slouží vydání oprav hned 9 dnů poté (Kibana 4.1.1) a opět za další měsíc (10. března 2016) vyšly další opravy pojmenované jako Kibana 4.4.2, které např. přidávají basePath proměnnou pro zkrácení URL adres, rozšíření pro formát souborů .tgz8 . Nejnovější Kibana 4.5.0 opravila jen některé chyby. Bližší informace naleznete na webové stránce9 . Jak vidíme, Kibana se neustále mění a vylepšuje, takže v dohledné době může přibýt nejen nový graf, ale také funkce a třeba i úpravy pro práci s IP toky. Ale i staré verze Kibany (4.3 i 4.1) jsou stále vylepšovány, poslední opravy vyšly 10. března 2016. Stejně jako Elasticsearch i Kibana má verzi 5.0.0-aplha10 , která slouží jen pro vývoj. Úplně změnila vzhled stránek a vylepšuje přidávání pluginů. Více informací zatím není v tomto čase dostupných.

7. 8. 9. 10.

www.elastic.co/guide/en/kibana/4.4/releasenotes.html www.elastic.co/downloads/past-releases/kibana-4-4-2 www.elastic.co/guide/en/kibana/4.5/releasenotes.html www.elastic.co/blog/kibana-5-0-0-alpha1

21

4 Analýza možností pro práci s IP toky použitím ELK Určila jsem si dvě kategorie, podle nichž budu porovnávat zmíněné programy (Elasticsearch verze 2.3.1, Kibana verze 5.0.0, Flowmon verze 8.00.01). První kategorií jsou funkce, které programy podporují. Druhou je vizualizační, jaké grafy jsou v programech dostupné.

4.1

Porovnání z hlediska funkcí

Máme-li ověřit použitelnost ELK pro analýzu IP toků, musíme si definovat základní funkce (vlastnosti), které budeme vyžadovat. Jedná se o tři základní oblasti: 1.

procházení a filtrování dat,

2.

statistiky - klasické TOP n statistiky a pod.,

3.

upozornění a varování - ohledně propustnosti a zahlcení sítě či neobvyklé jevy.

Procházení a filtrování Procházení - zobrazit všechna data bez filtrování lze v Kibaně v záložce Discovery. Data jsou seřazena dle času a je zde zobrazen i graf objemu dat po deseti sekundách. Na panelu vlevo je seznam hodnot, které jednotlivé položky obsahují, a může se zobrazit jen čas a vybraný sloupec hodnot. Po kliknutí na pole Visualize se zobrazí histogram těchto hodnot. Flowmon má procházení dat v záložce Analýza a ve spodní části je záložka Toky. Zobrazí se základní informace o tocích - IP adresa zdroje a cíle, port zdroje a cíle, bajty, toky, IP protokol, TCP příznaky a IP adresa zdroje toku. Na této stránce se také provádí filtrování, takže všechna funkcionalita je pohromadě. Ale na rozdíl od řádkového zobrazení Kibany je seřadí do sloupců. Elasticsearch používá v dotazech jazyk Query DSL obdobný jazyku JSON 1 . Tento jazyk používá kromě boolovských dotazů, které vrací 1.

www.elastic.co/guide/en/elasticsearch/reference/1.4/query-dsl.html

22

4. Analýza možností pro práci s IP toky použitím ELK logické hodnoty, ještě další dva typy dotazů - termy a prefixy (a jejich kombinace) 2 . Tyto dotazy vrací podmnožinu vyhovujících záznamů. Dotazy se skládají z jednotlivých filtrů. Term hledá přesnou shodu, např: { " term " : { " dstip " : "192.165.12.2"} }

Jak už název vypovídá, prefix dotaz se používá na vyhledání počáteční části slova. Vypadá takto: { " prefix " : { " dstip " : "192.165." } }

Při více podmínkách (kombinovaný dotaz) se zadává, jestli je dotaz splňovat musí must, měl by should, nesmí must-not3 . Například dotaz kdy port je roven 25 a protokol nesmí být TCP: { " query ": { " bool ": { " must ":[ { " match ": { " port ": "25" } } ], " must - not ": [ { " match ": { " protocol ": " tcp " } } ] } } }

Každý dotaz kromě podmnožiny dat vrátí také skóre, které nám říká, jak hodně záznamy vyhovují dotazu. Čím větší skóre, tím jsou data relevantnější. Samotné filtry nacházející se uvnitř těla dotazu skóre nemají. Filtry pracují efektivně, protože výsledek mohou uklá2. www.elastic.co/guide/en/elasticsearch/reference/1.4/_introducing_ the_query_language.html 3. www.elastic.co/guide/en/elasticsearch/reference/current/ query-filter-context.html

23

4. Analýza možností pro práci s IP toky použitím ELK dat do mezipaměti a při opakovaném dotazu ho již nemusí znovu vyhodnocovat. { " filter ": { " range ": { " created ": { " gte ": " now - 1 d / d " } } } }

Zajímavým parametrem filtru, který můžeme volit, jsou tzv. strategie. Strategie jsou např. leap_frog_query_first - najdi první dokument, který se shoduje s výrazem, a vyfiltruj ho. Filtry se dají sdružovat přes AND, existují existencionální filtry, limitní filtry, filtr má potomka atd. Všechny se dají najít např. zde 4 .

Obrázek 4.1: Kibana - filtrování a agregace Pokud uživatel používá pro grafické znázornění výsledků Kibanu, nemusí výše zmíněný jazyk používat, protože mu stačí zvolit parametry z nabídky, a vlastní vytvoření dotazu provede Kibana. Všechny dotazy a odpovědi z Kibany do Elasticsearch a naopak se dají zobrazit po kliknutí na šipku pod grafem. Navíc je v Kibaně pro filtr přímo políčko v aggregation - filters. Zde se dá zapsat filtr i bez závorek, protože Elasticsearch si to převede na výraz dle potřeby. Případně lze příkaz pro filtr napsat do horního řádku, viz obrázek 4.1. Příklad filtru v Kibaně: pr ot oc ol Id en ti fi er : TCP AND d e s t i n a t i o n T r a n s p o r t P o r t : 53 AND bytes :[0 TO 48]

Ve Flowmon kolektoru by se tento filtr zapsal například takto: 4.

www.elastic.co/guide/en/elasticsearch/reference/1.4/query-dsl-filters.html

24

4. Analýza možností pro práci s IP toky použitím ELK proto TCP AND port 25 AND bytes > 0 AND bytes < 48

Možnosti filtru Flowmon kolektoru jsou mnohem rozsáhlejší než u Kibany. Díky speciálnímu formátu pro IP adresu s maskou, IPv6 nebo MAC adresu dokáže pracovat i s těmito údaji efektivně. Kibana tyto formáty nemá, a tudíž je filtrování těchto dat mnohem složitější nebo dokonce nemožné. Nepodporuje ani vyhledání dle TCP příznaků, např. .AP.SF. Ale některé funkce by se nahradit daly. Např. vyhledávání dle příznaků provést pomocí shody řetězců. Oba programy podporují filtrování rozsahu IP adres, například takto to vypadá v Kibaně: src_ip_addr : [70.121.190.37 TO 80.122.191.50]

Filtrování dle části slova (string) Kibanou se provádí pomocí speciálních značek. Pro hledání přesné shody se dá výraz do uvozovek, např. IPAddress : ”192.168.1.1.” Pro hledání podvýrazu se použije symbol *, např. IPAddress: *192*. Elasticsearch (a tedy i Kibana) neumí hledání podvýrazu pro datový typ string, proto se v tomto případě musí použít speciální typ raw, který se automaticky vygeneruje při vložení dat. Poznáme ho dle názvu, např. IPAddress.raw. V obou programech je možné filtry i ukládat. Statistiky Abych mohla srovnat statistické funkce, rozdělila jsem je na čtyři kategorie kategorie podobně jako Čermák a kol. [12]: 1.

základní statistické výpočty - počet, průměr atd.,

2.

agregace - spojení dat dle určitého klíče a vrácení počtu výsledků,

3.

TOP n prvků - vrátí pouze zadaný počet prvků,

4.

časové okno - omezení toků dle času.

Základní statistické výpočty V Kibaně se funkce počet (count) dá nastavit přes Aggregation - Terms Order by - metric: Count. Funguje ve všech grafech a pro všechny typy 25

4. Analýza možností pro práci s IP toky použitím ELK hodnot (řetězec, číslo...). Kibana má ještě Unique Count pro počet jen unikátních hodnot. V Flowmon kolektoru je na počet několik speciálních příkazů podle toho, z čeho chceme mít počet, např.: dns-qcount je počet DNS dotazů a dns-answcount je počet DNS odpovědí. Tento dotaz by se v Kibaně musel nahradit filtrem na port 53. Průměr se dá vybrat přes pole average při nastavení Order by Custom Metric. V témže poli lze nastavit i max, min, sumu, počet unikátních hodnot a Percentile rank, který udává procenta dat menších než zadaná hodnota. Samozřejmě všechny tyto statistiky lze provádět jen nad číselnými hodnotami. Ve Flowmonu jsou na tyto základní statistiky opět speciální příkazy, např. art-cntmin vrátí minimální čas odpovědi klienta, art-cnt vrátí sumu časů jeho odpovědí a art-cntmax vrátí maximální čas. Také se objevují speciální příkazy pro směrodatnou odchylku, např. npm-ddev udává směrodatnou odchylku mezipaketového zpoždění. Díky těmto speciálním příkazům lze provádět tyto statistické výpočty jen nad zvolenou množinou hodnot. Agregace Agregace je sloučení dat dle stejné hodnoty. Elasticsearch podporuje tři základní typy agregací 5 : 1.

Bucketing - tvoří buckety (koše) dle klíče, každá hodnota padne dle slučované hodnoty do určitého koše.

2.

Metrika - počítá hodnoty z celého dokumentu.

3.

Pipeline - agreguje výstup jiných agregací.

Díky tomuto systému můžeme definovat i vnitřní agregace, např. se dá agregovat dle IP adresy a poté dle portů. Příkaz pro agregaci dle zdrojové IP adresy, prvních 5 výskytů dle počtu: " filter ": { " aggs ": { 5. https://www.elastic.co/guide/en/elasticsearch/reference/current/ search-aggregations.html

26

4. Analýza možností pro práci s IP toky použitím ELK " terms ": { " field ": " dstip " , " size ": 5 , " order ": { " _count ": " desc " } } }

Místo počtu hodnot můžeme jako funkci vybrat i max, min, průměr, sumu, percentil pod polem custom metric. Kibana navíc podporuje i speciální agregace [34]: ∙

Date Histogram - zpracovává datum a čas a lze nastavit časové okno (sekundy, minuty až roky).

∙

Histogram - klasický histogram pro číselné pole. Tlačítko show empty buckets zobrazí i prázdná pole.

∙

Range - dá se specifikovat rozsah hodnot pro číselná pole.

∙

Date Range - agregace pro rozsahy datumů. Lze použít speciální notaci, např. now+1h.

∙

IPv4 Range - definuje rozsah pro adresy IPv4.

∙

Terms - agregace pro prvních nebo posledních x elementů, které budou seřazené dle metriky nebo počtu.

∙

Filtres - definice vlastního filtru dle Apache Lucene - Query Parser syntaxe nebo v JSON formátu.

∙

Significant Terms - zobrazí důležité prvky, přičemž počet se dá nastavit.

∙

Geohash - agregace pro geohash koordinace.

Flowmon kolektor také podporuje vnořené agregace, ale navíc má přehlednější možnosti voleb pro agregaci. Kibana jen zobrazí názvy položek v datech, ale Flowmon kolektor je rozděluje podle typu (IP, HTTP) a obsahuje i speciální funkce, např. sloučení dle IPv4 či IPv6 masky. 27

4. Analýza možností pro práci s IP toky použitím ELK TOPn prvků TOPn je základní funkce pro výběr jen určitého počtu prvků. V Kibaně se po nastavení funkce řazení vybere počet zobrazených prvků. Na rozdíl od Flowmon kolektoru, kde počet je předem definován na 10, 20, 50, 100, 200 nebo 500, lze v Kibaně zadat jakékoliv kladné číslo. Také je možné nastavit jiné řazení a jiný počet prvků ve vnitřních agregacích. Časové okno Je důležité, aby se dal jednoduše a logicky omezit časový úsek dat. V časovém okně Kibany lze kliknutím změnit interval na: ∙

Quick - předem definované časové úseky, jako jsou dnešek, letos, minulý měsíc atd.

∙

Relative - před X měsíci/dny a pod. do dneška.

∙

Range - klasický výběr ze dvou dat pro od-do.

Při vkládání nových dat si uživatel vybere, zda chce řadit data dle datumu a času načtení do Kibany (pole @timestamp), nebo podle datumu a času pořízení dat (např. pole date_first_seen) - pokud v souboru takový údaj existuje.

Obrázek 4.2: Kibana - výběr dat z časového intervalu 28

4. Analýza možností pro práci s IP toky použitím ELK Musím připustit, že chvíli trvá, než si na tento systém člověk zvykne. Protože časové okno nezjišťuje automaticky interval od kdy do kdy jsou vložená data, a pokud je časové okno nastaveno chybně, grafické rozhraní nemusí nic zobrazit. V záložce Discover (obrázek 4.2) je pak přehled dat (jaký mají formát) a současně vidíme vybrané časové okno. Také po kliknutí na pole v levém sloupci si můžeme zobrazit hodnoty s nejvyšším počtem výskytů a jejich procentuální zastoupení. V tomto okně lze ručně zvolit jiný časový úsek, ale také se dají zvolit jen určité parametry dat a celý výběr i s časem uložit pro budoucí použití. Při proudových datech je možné nastavit interval načítání nových dat na několik sekund či minut.

Obrázek 4.3: Flowmon - výběr dat z časového intervalu Ve Flowmon kolektoru se automaticky ukládá posledních 10 uživatelských dotazů a jejich výsledků pro rychlejší zobrazení. Výsledky lze exportovat nebo ukládat v programu (lze jich uložit 10). Kibana takové omezení nemá hlavně proto, že je navržena jako vizualizační prostředí na tvorbu grafů, a počítá se s tím, že bude výsledné grafy (výsledky dotazů) ukládat. Flowmon má také možnost výběru předdefinovaných časových intervalů i data pro časový interval od-do. Také můžeme použít dva sloupcové grafy (obrázek 4.3). Horní ukazuje vybraný interval v rámci dnů, druhý pod ním v rámci hodin. Je to přehlednější než výběr časového intervalu v Kibaně, která má jen jeden sloupcový graf a v tomto grafu se výběrem dají data jen zúžit, ale ne zvětšit. V nejbovější verzi 29

4. Analýza možností pro práci s IP toky použitím ELK Flowmonu v8.01.00 lze vybrat časové okno po 30 sekundách (dříve jen 5 minutách), ale Kibana 5.0.0. umí jemnější časové intervaly až po milisekundách.

Celkové hodnocení Dotazovací jazyk Query DSL používaný Kibanou a Elasticsearch je přehledný na čtení i psaní. Umí filtrovat dle přesné hodnoty, podřetězce, rozsahy hodnot, agregace i základní statistické metody. V Kibaně se dá většina funkcí „naklikat“ bez jakékoliv znalosti tohoto jazyka, ale pro lepší ovládání je dobré ho znát a používat. Pro IP toky podporuje speciální formát pro IPv4 adresu, filtrování přes rozsahy IPv4 adres. Názvy protokolů a porty bere jako řetězce resp. čísla, nevidí mezi nimi souvislost, ale to nebrání v práci. Bohužel nemá podporu pro IPv6, MAC adresy nebo masky sítě. Předpokládám, že aspoň formát pro IPv6 se objeví v novější verzi. Ale i bez speciálního formátu lze pracovat s těmito poli jako textovými řetězci, takže hledání shody nebo podvýrazu (v našem případě část adresy, např. sítě) lze také provést. Flowmon má speciální příkazy na zjišťování statistických dat, např. průměru, Kibana je v tomto univerzálnější a nemusíme tyto speciání příkazy znát. Zobrazení jiného časového intervalu je jednoduché a lze nastavit i automatickou aktualizaci načítání dat pro proudová data. Jen změna intervalu je neintuitivní. Flowmon v8.01.00 zobrazuje časový interval po 30 sekundách, ale Kibana 5.0.0. umí až po milisekundách.

Upozornění a varování Anomaly Detection System (ADS) je řešení pro hledání provozních problémů a útoků v síti a je přímo součástí Flowmon. ADS sleduje chování celkové sítě a hledá anomálie (nečekané změny v datech) nebo určité vzory útoků. Příkladem jsou scany sítí, slovníkové nebo DoS útoky, které mají velké množství malých toků buď ze stejného zdroje nebo z různých adres při distribuovaném útoku [33]. Flowmon nabízí softwarový modul Flowmon ADS [15] pro kolektor nebo sondu. 30

4. Analýza možností pro práci s IP toky použitím ELK CSIRT-MU sbírá data ze sítě a každých 5 minut spouští sken uložených dat pro hledání anomálií. ELK sám o osobě nepodporuje automatické upozornění, ale vznikl plugin pro Elasticsearch s názvem Watcher [11]. Instalace je popsána v příloze B. Watch - hlídač se skládá z: ∙

Trigger - kdy se watch má spustit z časového hlediska.

∙

Input - určení načítání vstupních dat.

∙

Condition - podmínka, zda se má akce provést. Standardně je nastavena na „vždy“.

∙

Transform - transformace dat, libovolná.

∙

Actions - udává akci, co se má stát, když se splní podmínka.

Do těla pole input - vstupu - se dá zapsat jakýkoliv dotaz query, který používá i Elasticsearch. Popsán je v kapitole 4.1. Příklad, kdy chceme kontrolovat data každých 10 sekund, přesněji záznamy z logů a hledat v nich error v položce message. Watcher pak chybu zaloguje dle nastavení6 : $

curl - XPUT ’ http :// localhost :9200/ _watcher / watch / log_watch ’ -d ’{ " trigger " : { " schedule " : { " interval " : "10 s " } }, " input " : { " search " : { " request " : { " indices " : [ " logs " ] , " body " : { " query " : { " match " : {" message ": " error "} } } } } 6. https://www.elastic.co/guide/en/watcher/current/watch-log-data. html

31

4. Analýza možností pro práci s IP toky použitím ELK }, " actions " : { " log_error " : { " logging " : { " text " : " Found errors in the logs " } } } }’

Zaměřím se hlavně na rozsah funkcí, které Watcher nabízí. V podmínkách podporuje čtyři základní typy - always, never, script a compare. Podmínka always se vyhodnocuje jako pravda, takže se provede vždy, když se spustí watcher. Naopak never podmínka se neprovádí vždy a slouží jen k testování. Zajímavější je hodnota script 7 , která umožňuje spustit jakýkoliv skript, který vrátí boolen hodnotu, aby se dalo rozhodnout, jestli je podmínka splněna či ne. Samotný skript může být napsán i v externím souboru a defaultně používá jazyk groovy, ale podporuje jazyky jako javascript, python či mustache. Ve skriptu máme přístup k datům, jen již nejsou ve formátech, které používá Elasticsearch, ale jako řetězce. Takže je potřeba pomocí např. Datetime formát parsovat. Poslední podmínka compare porovnává hodnotu se zadanou. Lze například definovat: počet výskytů je větší než 10, zapíšeme jako gte 10. Když ještě přidáme agregaci k datům dle zdrojové adresy a typu dotazu, tak při počtu větším než 30 000 výskytů pro síť MU za 5 minut dostaneme možnost, jak najít útoky typu scanování sítě, viz kapitola 6.3. Takový watcher by mohl vypadat následovně: $ curl - XPUT ’ http :// localhost :9200/ _watcher / watch / error ’ -d ’{ { " trigger ": { " schedule ": { " interval ": "5 m " } }, " input " : { 7. www.elastic.co/guide/en/elasticsearch/reference/2.3/ modules-scripting.html

32

4. Analýza možností pro práci s IP toky použitím ELK " search " : { " request " : { " indices " : [ " data " ] , " body " : { " size ": 0 , " aggs ": { "2": { " terms ": { " field ": " sourc eIPv4A ddres s " , " size ": 10 } }, " aggs ": { "3": { " terms ": { " field ": " HTTPRequestType " , " size ": 5 } }, " condition " : { " compare " : { " ctx . payload . hits . total " : { " gt " : 30000 }} }, " actions " : { " emailAdmin " : { " email " : { " to " : " admin@mail . muni . cz " , " subject " : " Scan attack " , " body " : "{{ ctx . payload . hits . total }} communications recorded . ." , " attachment " : { " attached_data " : { " data " : { " format " : " json " }}}}} }’

Jako první se nastaví v trigger interval na každých 5 minut. Pak se spustí dotaz v Elasticsearch pro data, které jsem agregovala. Můžeme i jednotlivé agregace uložit do nového dokumentu s novými indexy a s těmi pak pracovat. Podmínkou je počet větší než 30 000 a akce musí být odeslání email administrátorovi s daty ve formátu json v příloze. Flowmon nabízí mnohem jednodušší řešení pro anomálie toků než 33

4. Analýza možností pro práci s IP toky použitím ELK Kibana, uživatel si jen vybírá z programů pro detekci útoků a anomálií a je tomu lépe přizpůsoben. Ale i ELK nabízí základní detekci.

4.2

Porovnání z hlediska vizualizací

Pro lepší zobrazení dat se používají v Kibaně grafické přehledy (dashboard), které většinou obsahují několik vzájemně provázaných grafů, takže poskytují různé pohledy na stejná data. Při klasickém sloupcovém nebo čárovém grafu můžeme jednoduše vidět, když nastane výkyv (speciální vrchol v grafu), který může být způsoben buď zvýšeným počtem připojených hostů i útokem. Rozlišit, o který případ jde, bychom měli být schopni ze správné grafické vizualizace. Poslední verze Kibany podporuje následující typy grafů: 1.

Plošný graf (Area Chart) Jedná se o plošný graf; je to řada bodů propojená lomenou čárou, přičemž i oblast pod čarou je vyplněna. Tím je dán důraz na obsah, takže se hodí např. na porovnávání (objemu) toků dat.

2.

Tabulka (Data Table) Data table je klasická tabulka, kde se dají přidat i agregace. Zobrazí se (nahradí graf) i po kliknutí na šipku pod každým jiným grafem.

3.

Čárový graf (Line Chart) Nastavení tohoto grafu se dá přizpůsobit, ať už barvou nebo i „křivostí“ čar (plynulé, ostré hrany), ukázat body v místech dat, zdůraznit min/max hodnoty, legendu a nastavit měřítko y osy a zvolit lineární a logaritmické. Tento graf se může změnit na bublinkový; ten obsahuje jen body, které škáluje dle barvy.

4.

Koláčový graf (Pie Chart) Koláčový graf, který je ve všech vizualizacích pro flow data, podporuje agregace dle počtu, sumy, unikátních hodnot a poté rozšířené agregace, které jsou popsány v předchozí části 4.1. Lze opět přidat i vnitřní agregace, takže nám vznikne Sunburst chart neboli víceúrovňový koláčový graf. 34

4. Analýza možností pro práci s IP toky použitím ELK 5.

Mapa (Tile Map) Zobrazuje geografické údaje na mapě.

6.

Vertikální sloupcový graf (Vertical Bar Chart) Sloupcový graf. Data lze seskupit a jednotlivé sloupce rozdělit do více úrovní.

Z uvedených typů grafů Flowmon kolektor podporuje jen graf koláčový a plošný, přičemž plošný používá hlavně na real-time data a koláčový na TOPn statistiky. Porovnat ho s klasickým sloupcovým grafem můžeme třeba na obrázku 4.3. Na základní analýzu toků tyto grafy postačují, ale nedají se upravovat ani přizpůsobit potřebám uživatele. Flowmon zobrazuje v tabulce pod grafem i vlajku země dle IP adresy. Tato funkce by se dala v Kibaně rozšířit, získat souřadnice země (např. střed) a zobrazit na mapě (graf Tile map). Ani Kibana, ani základní Flowmon (Flowmon ADS ano) neobsahují graf komunikační, který je používaný pro znázornění síťové komunikace mezi prvky sítě. Více se tímto problémem budu zabývat v kapitole 5. Celkové hodnocení Kibana nabízí více druhů grafů než Flowmon kolektor. Všechny grafy se dají upravit, rozdělit sloupce, jak si přeje uživatel, změnit formát os... Jako graf je brán i text nebo tabulka. Díky tomu, že Kibana obsahuje mnoho typů grafů, lze vybrat graf dle toho, co má přesně zobrazit. Např. plošný graf zdůrazňuje obsahy hodnot, takže se hodí pro porovnávání objemů přenosů víc než např. čárový. Některé grafy, např. mapa, by se daly upravit pro zobrazení IP adres. Kibana je v tomto směru více interaktivní.

35

5 Rozšíření vizualizace Do Kibany 5.0.0 jsem vytvořila vlastní vizualizace v D3js, které neobsahují ani Flowmon kolektor, z jehož vlastností vycházím.

5.1

Komunikační graf

Jak už název napovídá, komunikační graf zobrazuje komunikaci mezi jednotlivými síťovými prvky, čímž nám částečně ukazuje propojení uzlů v síti. Na obrázku 5.1 jsem si zvolila počet prvků = 5 , parametr nejvíce zatížených a počet cílů = 3. Je patrné, že vznikly oddělené úseky sítě, obsahující hlavní uzly sítě zprostředkovávající komunikaci. Až při 10 nejvíce komunikujících uzlech a 5 cílech se mi propojily celky do sebe, viz vlevo dole na obrázku 5.2 [7]. Zvolila jsem nakonec zobrazení vytíženosti uzlů barvou a ne hodnotou průměru, protože v druhém případě zanikala přehlednost grafu v případě velkých rozdílů v komunikaci (průměrů bodů) často se lišící i o několik řádů.

Obrázek 5.1: Komunikační graf - ukázka 5 hlavních uzlů

36

5. Rozšíření vizualizace

Obrázek 5.2: Komunikační graf - ukázka pro 15 hlavních uzlů Nastavení v D3js automaticky „vyvažuje“ graf při počátečním zobrazení, takže je vidět, který uzel je hlavní - má největší počet komunikací se svými poduzly, viz obrázek 5.3. Pro lepší přehlednost se podrobnější informace o komunikaci zobrazují jen při najetí myši. Můžeme ukázat myší na uzly, kde se zobrazí IP adresa a celková komunikace se všemi uzly, které tam vedou. Můžeme ukázat také na spoje uzlů, kde se zobrazí počet komunikací po tomto spoji. Navíc je možné v hlavním menu po kliknutí na Hide information nastavit trvalé zobrazení IP adres. Při trvalém zobrazení IP adres se může graf stát nepřehledným, proto graf má i funkci drag&drop, takže stačí chytnout za uzel a popotáhnout s ním. Tím se vzdálenosti mezi uzly zvětší. Mnou navržený graf má následující parametry: Source (zdroj), Target (cíl) a jejich počet, tzn. kolik zdrojů a kolik cílů, se kterými proběhla komunikace, se má zobrazit. Automaticky je nastavena metrika na počet (počet komunikací), ale toto lze změnit třeba na velikost (sumu 37

5. Rozšíření vizualizace přenesených dat), vybrat jeden protokol a pod. Zdroj a cíl jsou agregovány typem Terms pro IP adresy, ale samozřejmě lze použít i jiné informace o koncových uzlech.

Obrázek 5.3: Komunikační graf - jeden hlavní uzel Komunikační graf je naprogramován za pomoci knihovny D3js tak jako všechny grafy v Kibaně. Ale aby se pomocí ní daly vytvořit uzly (nodes) a spoje mezi nimi (links), je zapotřebí mít data v specifickém formátu. Tím je seznam všech uzlů a asociativní pole pro spoje, tzn. source: n, target: m; kde n a m jsou čísla řádků v seznamu uzlů. Proto jsem si musela vytvořit vlastní strukturu. Pole nodes vypadá např. takto: ip : 192.168.1.1 , number : 5 , id : 0

Number je velikost komunikace a id je pořadí, které potřebuji pro spoje. Pole links vypadá následovně: source : 192.168.1.1 , target :192.168.1.0 , number : 5

38

5. Rozšíření vizualizace kde number je opět velikost komunikace mezi zdrojem a cílem. Pro rychlejší vyhledávání používám pomocné pole se seznamem IP adres. Zdrojový kód k úpravě dat je v příloze C. Při vykreslování grafu s větším množstvím uzlů nastal problém s nedostatečnou pamětí Elasticsearch. Při bližším zkoumání jsem zjistila, že problém je s pamětí haldy při agregaci velkého množství dat. Ta se dá zvětšit příkazem $ export ES_HEAP_SIZE =10 g

V mém konkrétním případě jsem zobrazovala proudová data, tzn. posledních pěti minut sledování sítě, a i přesto jsem měla přes 100 000 záznamů. Samotný kód grafu v D3js je v příloze C. Jedná se o klasický javascriptový kód. Pomocí funkce force se vytvoří kostra grafu, přičemž se nastaví parametry jako např. vzdálenost uzlů a velikost grafu. Poté se pomocí svg.selectAll(’link’) načtou hodnoty pro spoje, nastylují se a přidá se k nim funkcionalita po najetí myší. Další funkce slouží pro uchopení uzlu a jeho manipulaci. Poté se ve funkci svg.selectAll(’node’) vytvoří uzly, opět se upraví velikost a vzhled a přidá se popisek (tooltip) - zobrazení IP adresy a velikosti komunikace po najetí myší. Následně se vytvoří legenda ke grafu, jednotlivé čtverce a popisky k nim. Také jsem potřebovala zdůraznit po najetí myši jen sousedící hrany a uzlů, k čemuž slouží funkce function fade(opacity), která snižuje průhlednost.

5.2

Přidání vlastního grafu do Kibany

Kibana je open source program, tzn. zdrojové kódy jsou veřejně zpřístupněny a uživatelé je mohou upravovat dle libosti. Vývojáři rychle reagují na potřeby komunity uživatelů, takže pokud určitý počet uživatelů napíše, že by chtěli přidat nový graf či funkci, dříve či později se objeví v některých aktualizacích. Kibana podporuje instalaci modulů (plugins), které rozšiřují funkcionalitu. Ale ani jeden z modulů neumožňuje jednoduše přidávat další graf třeba jen vložením D3js kódu. Protože kód grafu je obecně 39

5. Rozšíření vizualizace závislý na mnoha faktorech, vznikly soubory jen pro tvorbu např. osy x, y a pod. Přidání nového grafu se tím stává poměrně složitou záležitostí. Proto do této práce přidávám postup na přidání grafu. Složka src/ui/public/vislib/visualizations obsahuje všechny zdrojové kódy ke grafům. Sem jsem vložila zdrojový kód mého nového komunikačního grafu, nejdůležitější část zdrojového kódu najdete v příloze C, jinak na přiloženém CD. Při programování jsem vycházela z již hotového plošného grafu, protože měl podobné nastavení. Je nutná registrace nově vloženého grafu a nového poskytovatele (providera) v souboru src/ui/public/vislib/visualizations/vis_ types.js. Dále je zapotřebí ještě jednou registrovat nový graf v souboru src/plugins/kbn_vislib_vis_types/public/kbn_vislib_vis_types. js. Při tom vznikne nově vytvořený js soubor s nastavením grafu, který se shoduje s názvem mnou vytvořeného grafu. Zde se také nastavuje použitá šablona, název grafu, ikona, popis. Tyto informace se objeví v menu Kibany u výběru grafů. Dále pak nastavujeme parametry grafu jako zobrazení os, tooltipu, legendy, měřítka os (lineární, logaritmické, exponenciální) a schéma, což jsou typy agregací, které lze použít pro tento graf, a omezení počtu vnořených agregací.

Obrázek 5.4: Horizontální sloupcový graf Poté se přidá nový handler do souboru ui/pubic/vislib/lib/ handler/handler_types. Já jsem se místo přidání odkázala na jeden z již vytvořených (bodový). Připravené jsou celkem tři ve složce handler/ 40

5. Rozšíření vizualizace types. Jeden je pro koláčový, další pro bodový a poslední je pro mapu. Koláčový nemá osu, bodový má osu a mapa má speciální formát handleru. Tyto základní typy by měly stačit pro jakékoliv potřeby. A jako poslední se musí přidat nový html editor do složky src/ plugins/kbn_vislib_vis_types/public/editors/. Zde se nastavuje rozložení okna na oddíly pro legendu apod. Opět jsem použila jeden z již hotových. Vytvořila jsem ještě jeden graf - horizontální sloupcový. U něj je zapotřebí i nastavit osy. Obě jsou ve složce src/ui/public/vislib/ lib/x_axis, popřípadě y\_axis. Zde se dá měnit doména, škálování, pozice vložení osy. Nově upravené osy se pak změní v souboru src/ ui/public/vislib/lib/axis_title.js. Pro nastavení stylů jsem upravila v src/ui/public/vislib/styles soubory layout.less a svg.less. Shrnutí Kibana zatím neumožňuje snadné přidání nového grafu jen za pomoci vložení D3js kódu. Proto jsem posala cestu, jak úpravou několika souborů vlastní graf přidat. Díky tomuto návodu je doplnění vlastního grafu mnohem snadnější. Jelikož pro zobrazení toků se často využívá komunikační graf, který v Kibaně chybí, doprogramovala jsem ho a připravila k využití v Kibaně.

41

6 Praktické ověření funkčnosti ELK pro práci s IP toky V této kapitole je popsáno praktické ověření využití ELK pro analýzu IP toků z hlediska využití v bezpečnostní týmu CSIRT-MU, a to klasické TOP statistiky, útoky a rozšířená HTTP data. CSIRT-MU používá v součastnosti Flowmon kolektor pro analýzu sítě.

6.1

TOPn statistiky

V CSIRT-MU Flowmon kolektor nejvíce používají členové bezpečnostního týmu (zejména handleři - osoby reagující na bezpečnostní incidenty a hrozby) při zjišťování útoků v síti a kontrole stavu sítě. K tomu používají 18 typů grafů uložených v přehledu reportů. Většina z těch, které kontrolují stav sítě, jsou jen základní TOP statistiky znázorňující provoz na síti. Proto jsem vybrala jen několik z nich a vytvořila obdobné grafy v Kibaně. Více jsem se soustředila na grafy, které jsou potřeba k ověření útoků, protože mají většinou speciální filtraci dat.(V Kibaně jsou vložená jiná data, proto nejsou následující grafy pro porovnání Kibany a Flowmon kolektoru přesně totožné.) TOP10 adres s největší komunikací Nejpoužívanější graf je přehledový objem komunikace. Tento graf se používá pro zjištění, není-li problém s přístupem na nějaký server a zda nějaký počítač nevykazuje neobvyklé množství komunikace. V Kibaně se vybere koláčový graf, agregace je terms - srcip - custom Metric - Sum - bytes - Size 10. Kibana neumožňuje podrobnější výpis současně s grafem, jak to má Flowmon kolektor, proto jsem musela použít dashboard a udělat koláčový graf a tabulku zvlášť. Samozřejmě grafy v dashboard jsou propojené, takže po kliknutí na jednu hodnotu se zvýrazní i v druhém grafu. Porovnání obou grafů je na obrázku 6.1, Kibana nahoře a kolektor pod ní. Oba grafy můžeme jednoduše vytvořit a oba jsou přehledné a interaktivní. Jen Kibana měla tu nevýhodu, že jsem musela udělat koláčový graf a druhý graf jen jako tabulku (popis typů grafů v sekci 4.2). 42

6. Praktické ověření funkčnosti ELK pro práci s IP toky

Obrázek 6.1: Kibana vs Flowmon kolektor - TOP10 adres s největším objemem komunikace Výhodou nezávislého grafu a tabulky naopak je možnost libovolného upravování velikosti obou grafů a pozice na stránce.

TOP10 toků Pro zjištění slovníkových útoků, skenování sítě, detekci červa nebo viru a jiných podezřelých aktivit se používá graf TOP10 toků. Když je počet komunikací abnormálně velký (samozřejmě musíme počítat s tím, že komunikace serverů bude výrazně větší a podle potřeby ji tedy můžeme vynechat), tak se může jednat např. o scan sítě. 43

6. Praktické ověření funkčnosti ELK pro práci s IP toky

Obrázek 6.2: Kibana vs Flowmon kolektor - TOP10 komunikací Na obrázku 6.2 vidíme ukázku obou grafů. V Kibaně se jednalo o koláčový graf a agregaci count přes zdrojové IP adresy. Oba grafy jsou přehledné, bez problémů s filtrací.

6.2

Toky rozšířené o HTTP data

HTTP je nejpoužívanější protokol, a proto by bylo dobré se věnovat analýze jeho toků více. Bohužel informací o využití HTTP dat pro analýzu toků je velice málo. Rozšířené hodnoty jsou: ∙

Request host name - jméno serveru, kterého se klient ptá.

∙

Request host referrer - URL, ze které je dotaz odkazován. 44

6. Praktické ověření funkčnosti ELK pro práci s IP toky ∙

Request type - 1 = GET, 2 = POST, 3 = HTTP, 4 = HEAD, 5 = PUT, 6 = OPTIONS, 7 = DELETE, 8 = TRACE, 9 = CONNECT, 10 = PATCH, 11 = SSL/TLS dotaz bez hlavičky.

∙

Request HTTP path - žádaná URL adresa.

∙

Response code - 200 = vše proběhlo v pořádku, 400 = špatná žádost, 401 = nedostatečná přístupová práva atd.

HTTP request type se rozumí spojení protokolů SSL a HTTP, protože se nedá zjistit přesně druh požadavku.

Obrázek 6.3: HTTP komunikace se stejným zdrojem, cílem a požadavkem Pokud v síti zachytíme větší počet toků se stejnou IP adresou zdroje, IP adresou cíle a HTTP požadavkem, je to velice podezřelé. Zajímají nás hlavně tři skupiny [21]. ∙

Jaký je nepočetnější tok?

∙

Kolik cílových uzlů bylo kontaktováno z jedné zdrojové IP adresy se stejným požadavkem?

∙

Kolik requestů bylo vyžadováno z jedné zdrojové adresy? 45

6. Praktické ověření funkčnosti ELK pro práci s IP toky

Obrázek 6.4: Popularita zdrojů v závislosti na požadavku Rozebírala jsem komunikaci ze dne 21. dubna 2016 od 18 hod do 23 hod, která obsahovala 3 790 811 záznamů. Vždy jsem si vybrala menší časový úsek a vyzkoušela na něm vytvořit grafy. IP adresy jsem měla anonymizované a uvedené hodnoty slouží jen jako orientační. V Kibaně jsem vytvořila sloupcový graf a rozdělila ho na skupiny dle prvních dvou nejpočetnějších typů požadavků (ostatní byly zanedbatelné), pak dle zdrojové a následně cílové adresy. Jak vidíme na obrázku 6.3, zelený sloupec ukazuje na 3 975 komunikací s požadavkem 11, tzn. HTTP s SSL/TLS protokol (proto i cílový port byl 443), takže se jedná o HTTPS. U HTTPS požadavků se neanalyzují hlavičky dotazů, protože se jedná o zabezpečnou komunikaci. Samozřejmě nemusí jít hned o útok, protože komunikací bylo „jen tisíc“, ale může jít třeba o komunikaci mezi servery, automatickou výměnu nějakých informací a pod. Další zajímavé údaje získáme zobrazením počtu hostů, kteří přistupují k jednomu zdroji se stejným požadavkem. To nám ukazuje popularitu zdroje. V Kibaně jsem použila sloupcový graf a rozdělila si ho na tři nejpočetnější požadavky (řádky v obrázku 6.4). Výsledkem jsou požadavky 1,2 a 11. A na ose x je 10 nejpočetnějších hostů. Každý sloupec se skládá z barev, které představují různé IP adresy. Tento graf vytvoříme pomocí agregace Terms - HTTPRequestHost počet 10, 46

6. Praktické ověření funkčnosti ELK pro práci s IP toky

Obrázek 6.5: TOP20 požadavků subagregací přes destinationIPv4Address počet 5 a Split Chart - Rows pro pole HTTPRequestType a počet 5. Největší barevný obsah zabírá fialová ve sloupci pro edge a facebook, IP adresa je 31.13.64.16 v obou případech a požadavek HTTP. V tomto případě to vypadá na běžnou komunikaci přes Facebook a online antivirový skener. Díky předchozímu výsledku mě zajímaly cílové adresy bez odlišení requestů. Proto jsem odstranila z předchozího grafu typ požadavku a zvýšila počet cílových IP adres na 20 (obrázek 6.5). Nejvíce lidé žádali adresu google.com, pak analytics.com a www.google.com, jednotlivé IP adresy mají přibližně stejné zastoupení.

6.3

Analýza základních útoků

Slovníkový útok Velmi častým a jednoduchým útokem je slovníkový útok. Na jeho odhalení potřebujeme rozšířená HTTP data, kde hledáme větší množství opakujících se stejných požadavků ze stejného zdroje na stejný cíl a stejnou cestu (URL adresu). Útočník totiž zkouší postupně jednotlivá hesla ze svého předem připraveného slovníku. Počet dotazů může vést řádově ke stovkám až k tisícím, takže i tok bude ohromný. URL 47

6. Praktické ověření funkčnosti ELK pro práci s IP toky

Obrázek 6.6: Počet požadavků na stránky s “login“ adresa většinou ještě obsahuje na konci /login nebo i /index, takže je zřejmé, že se jedná o přihlašovací formulář. Z výzkumu na obrázku 6.3 vyšlo najevo, že i větší komunikace tohoto typu může být mezi klientem a proxy serverem, který je na bázi webu. Ale proxy můžeme poznat i z webové adresy. V Kibaně jsem vybrala požadavky na stránky obsahující slovo login, pomocí výrazu: HTTPRequestHost . raw : * login *

K nim jsem poté zobrazila zdrojové adresy do bublinkového grafu (obrázek 6.6). Časový úsek jsem nastavila na hodinu, a jak vidíme, během této hodiny bylo 41 dotazů z adresy 108.196.63.191 na server login.microsoftonline.com. Číslo není tak vysoké, proto by mohlo jít o přihlášení z počítačové studovny a pod. SYN záplava Častým útokem je záplava SYN paketů [22]. TCP SYN pakety se používají pro ustavení komunikace mezi dvěma uzly. Server se pak snaží ustanovit podvržené spojení a rezervuje si pro něj zdroje, které si tím postupně vyčerpá. 48

6. Praktické ověření funkčnosti ELK pro práci s IP toky

Obrázek 6.7: TOP10 nejpočetnějších SYN komunikací Většinou je útok distribuovaný (SYN DDoS), takže SYN pakety chodí z různých zdrojů a je velice těžké je odlišit od náhodného navýšení SYN požadavků. Obvykle dojde k odpojení nebo dokonce ke zhroucení serveru, a teprve následně v datech vyhledáme, které počítače byly zapojeny do útoku pomocí pole TCP příznaků. Ty budou mít hodnotu příznaku ....S. (synchronizovat) a cílová IP adresa bude adresa našeho serveru. Na obrázku 6.7 jsem zobrazila 10 uzlů s největším počtem SYN komunikací. V Kibaně jsem nastavila filtrování dle řetězce ....S. Skenování portů Při skenování portů útočník postupně zkouší adresy v síti, aby zjistil, jaké aplikace jsou dostupné, popřípadě jejich zranitelnosti. Takže zdrojová adresa a HTTP cesta budou stejné a cílovými adresami budou různé stanice v síti MU [33]. Jednu z největších komunikací do sítě MU má adresa 179.231.208.108. Pomocí příkazu v horním řádku na obrázku 6.8 jsem si vyfiltrovala jen komunikaci z této adresy do sítě MU. Dále jsem chtěla vědět počet unikátních adres, který vyšel 21 393. Síť MU má okolo 65 000 adres, z toho je ale jen 15 000 aktivních, takže by se mohlo jednat o scan. 49

6. Praktické ověření funkčnosti ELK pro práci s IP toky

Obrázek 6.8: Scanování sítě Celkové hodnocení Vyzkoušela jsem zobrazit nejpoužívanější grafy i grafy se speciálními požadavky na filtrování dat a vše šlo bez obtíží zobrazit. Jen je oproti Flowmon kolektoru složitější zobrazit zároveň i výpis dat. Vyzkoušela jsem filtrovat i pomocí speciálních polí HTTP. Kibana má problém s URL adresou, kterou chápe jako řetězec, a proto ji neumí rozdělit na jednotlivé položky (např. port za dvojtečkou). Kibana navíc umožňuje i uložení více grafů pro pozdější zobrazení.

50

7 Závěr Moje práce se zabývala zpracováním a vyhodnocením IP toků. Přitom jsem porovnávála vlastnosti programu Flowmon speciálně navrženého pro analýzu IP toků a trojice navazujících programů ELK (Elasticsearch, Logstash a Kibana), které jsou orientovány obecně na zpracování velkého množství dat. Prvním úkolem bylo propojit ELK se sondou, která ze síťového provozu generuje IP toky, aby bylo možné zpracovávat data v reálném čase. Toto propojení je popsáno v kapitole 2. Při tom jsem narazila na problém kompatibility sondy a programu Logstash, které používají různý formát dat. Řešením je konverze formátu dat pomocí IPFIXcol. Dalším drobným problémem bylo, že Logstash nepodporuje v názvech atributů polí některé znaky. Toto lze vyřešit přímo pomocí programu Logstash přejmenováním příslušných názvů polí. Ve výsledku bylo propojení vyhovující i pro zpracování dat v reálném čase. Srovnáním funkcí pro práci s databázemi Elastisearch (a grafického rozhraní Kibana) s funkcemi Flowmon se zabývá kapitola 4. Dotazovací jazyk Query DSL pro práci s databází (Elastisearch) je velice podobný jazyku JSON, a proto je intuitivní a jednoduchý na naučení. Z hlediska podporovaných funkcí nevznikl žádný větší problém, s výjimkou síťových adres. Tím, že ELK není speciálně určen pro zpracování tohoto typu dat, nemá speciální formát pro IPv6 a ani pro MAC adresy či adresy s maskou sítě. Adresa s maskou se dá obejít přes prosté vložení IPv4 a zadání rozsahu sítě, který lze v Kibaně jednoduše nastavit. Díky tomu, že se programy ELK se velice rychle vyvíjí, jak jsem ukázala v kapitole 3 o vývoji ELK, lze předpokládat, že podpora alespoň IPv6 se objeví v nejbližších měsících. ELK podporuje všechny základní statistické operace jako jsou počet, průměr, počet unikátních hodnot atd. Od Flowmon se liší jen v detailech, které nejsou podstatné (např. nepřítomnost směrodatné odchylky). Naopak výhodou ELK je rozšířená podpora agregace, která kromě základní varianty dle řetězců umožňuje agregovat pole i dle rozsahu pro číselná pole, rozpětí pro pole časová či rozsahu pro IPv4. Flowmon je jen více graficky uzpůsoben pro IP toky a je přehlednější. Kibana je méně intuitivní, ale po kratší práci s ní si uživatel zvykne. 51

7. Závěr Narozdíl od Flowmonu, který vybírá data po 30 sekundách (až od nejnovější verze 8.1), Kibana (ELK) umí jemnější časové intervaly až po milisekundách, díky tomu je přesnější a vhodnější na zobrazování dat. Z hlediska vizualizací má více možností opět ELK. Hlavně proto, že byl vytvořen pro zpracování obecných dat. Grafy jsou více interaktivní, lze je vložit do dashboard a i zde fungují jako navzájem provázané (po změně dat v jednom grafu se táž data zobrazí i v ostatních grafech). Také nám dovoluje vytvořené grafy exportovat na webovou stránku v podobě iframe (plavoucí rám). Vzhledem k tomu, že ELK (Kibana) nemá zabudované grafy specificky určené na zobrazení IP toků, vytvořila jsem v kapitole 5 komunikační graf, jehož pomocí vidíme vytížení jednotlivých linek a spojů. Graf je naprogramován v D3js stejně jako ostatní grafy v Kibaně. Postup při vkládání nového grafu jsem popsala obecně pro další možné rozšíření v budoucnosti. V poslední, kapitole 6, jsem ověřovala praktické využívání funkcí Flowmon v CSIRT-MU. Vytvořila jsem v Kibaně obdobné TOP statistiky se základní agregací i grafy s HTTP daty (ta obsahují speciální formáty jako URL adresu či IP adresu). Také jsem se věnovala analýze útoků. Vyzkoušela jsem v IP tocích detekovat základní útoky slovníkový, SYN útok a skenování portů, všechny šly bez problémů identifikovat a zobrazit. Na základě mé analýzy vyplývá, že trojice programů Logstash, Elasticserach a Kibana je srovnatelná v základních parametrech s Flowmon a představuje určitý potenciál pro zpracování a vyhodnocování IP toků. Cílem této práce nebylo testování ELK z hlediska výkonnosti ani jeho rychlost načítání většího objemu dat. ELK je vytvořen speciálně pro práci s velkým množstvím dat (big data), podporuje vysokorychlostní SSD disky, RAID technologie pro redundanci dat, proto předpokládám, že by neměl být žádný problém. Přesto je srovnání výkonnosti a rychlosti ELKu s Flowmonem vhodné téma na další analýzu.

52

8 Literatura [1] CLAISE B. Cisco Systems NetFlow Services Export Version 9. RFC 3954 (Informational), October 2004. [2] CLAISE B., TRAMMELL B., and AITKEN P. Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information. RFC 7011 (INTERNET STANDARD), September 2013. [3] CLAISE B., DHANDAPANI G., AITKEN P., and YATES S. Export of Structured Data in IP Flow Information Export (IPFIX). RFC 6313 (Proposed Standard), July 2011. [4] TRAMMEL B., WAGNER A., and CLAISE B. Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol. RFC 7015 (Proposed Standard), September 2013. [5] TRAMMELL B. and BOSCHI E. Bidirectional Flow Export Using IP Flow Information Export (IPFIX). RFC 5103 (Proposed Standard), January 2008. [6] BIRCH Ben. Elasticsearch-head. [online] https://mobz.github. io/elasticsearch-head/, 2016. Naposledy navštíveno 13. 4. 2016. [7] BREITKREUTZ Bobby-Joe, STARK Chris and TYERS Mike. Osprey: a network visualization system. [online] http://www.biomedcentral.com/content/pdf/ gb-2003-4-3-r22.pdfBobby-Joe, 2003. Naposledy navštíveno 7. 5. 2016. [8] CERT. SiLK. [online] https://tools.netsa.cert.org/silk/, 2016. Naposledy navštíveno 7. 5. 2016. [9] ELASTIC. Elastic. [online] http://www.elasticsearch.org, 2016. Naposledy navštíveno 15. 3. 2016. [10] ELASTIC. Logstash. [online] https://www.elastic.co/ products/logstash, 2016. Naposledy navštíveno 8. 4. 2016. 53

8. Literatura [11] ELASTIC. Watcher. [online] https://www.elastic.co/ products/watcher, 2016. Naposledy navštíveno 25. 4. 2016. [12] LAŠTOVIČKA Martin a ČELEDA Pavel ČERMÁK Milan, TOVARŇÁK Daniel. Performance benchmark of netflow data analysis on distributed stream processing systems. Technical report, 2016. Vyjde v: Proceedings of the Network Operations and Management Symposium. [13] HOFSTEDE Rick et al. Flow monitoring explained: From packet capture to data analysis with netflow and ipfix. Technical report, IEEE COMMUNICATIONS SURVEYS AND TUTORIALS, PISCATAWAY: IEEE-INST ELECTRICAL ELECTRONICS ENGINEERS INC, 2014. s. 2037-2064. ISSN 1553-877X. doi:10.1109/COMST.2014.2321898. [14] FIRST. User Documentation nfdump & NfSen. [online] https://www.first.org/conference/2006/papers/ haag-peter-papers.pdf, 2006. Naposledy navštíveno 6. 5. 2016. [15] FLOWMON. Flowmon ADS. [online] https://www.flowmon.com/getattachment/ 3498c8ec-8c61-4f2f-96a7-82a611cecf13/Flowmon-ADS.aspx, 2016. Naposledy navštíveno 3. 4. 2016. [16] FLOWMON. Monitorujte síť nejvýkonnějšími NETFLOW/IPFIX sondami na světě. [online] https://www.flowmon.com/cs/ products/flowmon/probe, 2016. Naposledy navštíveno 15. 3. 2016. [17] FLOWMON. Výkonný NETFLOW/IPFIX kolektor pro detailní přehled o dění v síti. [online] https://www.flowmon.com/cs/ products/flowmon/netflow-collector, 2016. Naposledy navštíveno 15. 3. 2016. [18] IANA. IP Flow Information Export (IPFIX) Entities. [online] http://www.iana.org/assignments/ipfix/ipfix.xhtml, 2007. Naposledy navštíveno 19. 3. 2016. [19] ŘÁBEK Martin. Určení zdroje síťové komunikace na základě IP adresy. Bakalářská práce, Masarykova Univerzita, 2013. 54

8. Literatura [20] ŽÁDNÍK Martin. Network monitoring based on ip data flows - best practice document. [online] http://services.geant.net/cbp/Knowledge_Base/Network_ Monitoring/Documents/gn3-na3-t4-cbpd131.pdf, 2010. Naposledy navštíveno 12. 3. 2016. [21] HUSÁK Martin, VELAN Petr, and VYKOPAL Jan. Security monitoring of http traffic using extended flows. In 2015 10th International Conference on Availability, Reliability and Security, pages 258–265, Toulouse, 2015. IEEE. [22] NEUMANN Martin. Služba a nfsen plugin pro analýzu síťových toků pomocí sekvenčních statistických metod. Diplomová práce, České vysoké učení technické v Praze, 2014. [23] NETFLOWLOGIC. NetFlow Integrator. [online] https://www. netflowlogic.com/products/netflow-integrator/, 2016. Naposledy navštíveno 6. 5. 2016. [24] NTOP. nTop. [online] http://www.ntop.org/wp-content/ uploads/2011/09/ntop-man.html, 2005. Naposledy navštíveno 7. 5. 2016. [25] NTOP. nProbe. [online] http://www.ntop.org/products/ netflow/nprobe/, 2010. Naposledy navštíveno 7. 5. 2016. [26] NTOP. ntopng. [online] http://www.ntop.org/products/ traffic-analysis/ntop/, 2016. Naposledy navštíveno 7. 5. 2016. [27] KONONENKO Oleksii, BAYSAL Olga, HOLMES Reid, and GODFREY Michael W. Mining modern repositories with elasticsearch. In Proceedings of the 11th Working Conference on Mining Software Repositories, MSR 2014, pages 328–331, New York, NY, USA, 2014. ACM. [28] ČELEDA Pavel, KOVÁČÍK Milan, KONÍŘ Tomáš, KRMÍČEK Vojtěch, ŠPRINGL Petr, and ŽÁDNÍK Martin. Flowmon probe. Networking Studies, 2006. [29] MINAŘÍK Pavel, KRMÍČEK Vojtěch, and VYKOPAL Jan. Improving host profiling with bidirectional flows. In 2009 International 55

8. Literatura Conference on Computational Science and Engineering, pages 231– 237, Vancouver, Canada, 2009. IEEE Computer Society. [30] VELAN Petr and KREJČÍ Radek. Flow information storage assessment using ipfixcol. In Pavel Čeleda Martin Waldburger Burkhard Stiller Ramin Sadre, Jiří Novotný, editor, Lecture Notes in Computer Science 7279, pages 155–158, Heidelberg, 2012. Springer Berlin / Heidelberg. [31] VELAN Petr, JIRSÍK Tomáš, and ČELEDA Pavel. Design and evaluation of http protocol parsers for ipfix measurement. In Thomas Bauschert, editor, Advances in Communication Networking, Lecture Notes in Computer Science, Vol. 8115, pages 136–147, Heidelberg, 2013. Springer Berlin / Heidelberg. [32] SFLOW.ORG. sflow. [online] http://www.sflow.org/, 2003. Naposledy navštíveno 12. 5. 2016. [33] SADRE R. MORARIU C. SPEROTTO A., SCHAFFRATH G. An overview of ip flow-based intrusion detection. IEEE Communications Surveys Tutorials, 12(3):343–356, Third 2010. Kibana 4 Tutorial – Part 3: Visua[34] ROES Tim. lize. [online] https://www.timroes.de/2015/02/07/ kibana-4-tutorial-part-3-visualize/, 2015. Naposledy navštíveno 8. 4. 2016.

56

A Obsah elektronických příloh Přiložené elektronické přílohy obsahují následující soubory: 1.

Text práce ve formátu PDF.

2.

Složka nove_soubory obsahuje zdrojové kódy ke komunikačnímu grafu (soubory communication.js a communication_chart.js) i ke grafu horizontálnímu (soubory horizontal.js, horizontal_line_chart.js a upravené osy x_axis2.js, y_axis2.js).

3.

Složka src, která obsahuje hlavní zdrojové kódy ke Kibaně i s mými pozměněnými soubory, jak bylo posáno v kapitole 5.2. Přesněji soubory na těchto umístěních:

\ path { src / ui / public / vislib / visualizations } \ path { src / ui / public / vislib / visualizations / vis_types . js } \ path { src / ui / pubic / vislib / lib / handler / handler_typesn } \ path { src / ui / public / vislib / lib / axis_title . js } \ path { src / ui / public / vislib / lib / x_axis } \ path { src / ui / public / vislib / styles } \ path { src / plugins / k b n _ v i s l i b _ v i s _ t y p e s / public / k b n _ v i s l i b _ v i s _ t y p e s . js } \ path { src / plugins / k b n _ v i s l i b _ v i s _ t y p e s / public / editors /}

57

B Instalace a konfigurační soubory ELK Instalace ELK Vše jsem instalovala na operační systém Debian GNU/Linux 8.2 (architektura x86_64, AMD Opteron(tm) Processor 4284). Logstash jsem nainstalovala přímo ze souboru na adrese www.elastic. co/downloads/logstash. Elasticsearch a Kibanu pomocí příkazové řádky, protože nainstaluje-li se Kibana ze souboru, není umožněn přístup ke kódu. Použila jsem následující příkazy: $ $ $ $

git clone https :// github . com / elastic / kibana . git kibana cd kibana git clone https :// github . com / elastic / kibana . git kibana cd kibana

Jsou potřeba balíky build-essential a libssl-dev, ale měly by být již nainstalované. $ curl -o - https :// raw . gith ubuser conten t . com / creationix / nvm / v0 .29.0/ install . sh | NVM_DIR =/ usr / local / nvm bash $ nvm install " $ ( cat . node - version ) " $ npm install $ npm run elasticsearch

Posledním příkazem se zapne Elasticsearch, který zůstane zapnutý v terminále. Kvůli zapnutí Kibany je tedy nutné otevřít nový terminál ve složce kibana. $ nvm use " $ ( cat . node - version ) " $ npm start

Kibana by se měla spustit na adrese localhost:5601.

Instalace watcher Instalace je jednoduchá. Otevře se složka: $ cd / usr / share / elasticsearch

58

B. Instalace a konfigurační soubory ELK pak se naistaluje License plugin pomocí: # sudo bin / plugin install license

a samotný watcher: # sudo bin / plugin install watcher

Komunikace pak probíhá přes: $ curl - XGET ’ http :// localhost :9200/ _watcher / stats ? pretty ’

Konfigurační soubor pro Logstash pro dávková data Konfigurační soubor má příponu conf. Logstash se spouští přes příkazovou řádku, kde jako první se uvede cesta k Logstash a pak za příkazem -f (file) se uvede cesta ke konfiguračnímu souboru. Např: $ / opt / logstash / bin / logstash -f / home / janan / network . conf

Pro zjištění, zda konfigurační soubor je správně nastaven, lze použít příkaz –configtest. Např. $ / opt / logstash / bin / logstash -- configtest janan / network . conf

-f / home /

input { file { path = > "~/1000 k . log " start_position = > " beginning " } } output { elasticsearch { host = > " localhost :9200" protocol = > " http " index = > " data " } }

59

B. Instalace a konfigurační soubory ELK

Konfigurační soubor pro Logstash pro proudová data input { udp { port = > 9300 codec = > " json_lines " } } filter { mutate { remove_field = >{ [ " ipfix . HTTPRequestAgent " , " @accessors ", " @store " , " @lut " , " ipfix . tlsCliCips " ] } convert = > {" f l ow E n dM i l li s e co n d s " = >" long "} convert = > {" f l o w S t a r t M i l l i s e c o n d s " = >" long "} rename = > {" ipfix . octetDeltaCount " = >" octetDeltaCount "} rename = > {" ipfix . f l o w S t a r t M i l l i s e c o n d s " = >" f l o w S t a r t M i l l i s e c o n d s "} rename = > {" ipfix . f lo w E nd M i ll i s ec o n d s " = >" f l ow E n dM i l li s e co n d s "} rename = > {" ipfix . ingressInterface "= >" ingressInterface "} rename = > {" ipfix . ipVersion " = >" ipVersion "} rename = > {" ipfix . so urceI Pv4Add ress " = >" sou rceIPv 4Addre ss "} rename = > {" ipfix . d e s t i n a t i o n I P v 4 A d d r e s s " = >" d e s t i n a t i o n I P v 4 A d d r e s s "} rename = > {" ipfix . ipClassOfService " = > " ipClassOfService "} rename = > {" ipfix . ipTTL " = >" ipTTL "} rename = > {" ipfix . pr ot oco lI de nt if ie r " = >" p rot oc ol Id en ti fi er "} rename = > {" ipfix . tcpControlBits " = >" tcpControlBits "} rename = > {" ipfix . s ou r c eT r a ns p o rt P o r t " = >" s o ur c e Tr a n sp o r tP o r t "} rename = > {" ipfix . d e s t i n a t i o n T r a n s p o r t P o r t " = >" d e s t i n a t i o n T r a n s p o r t P o r t "} rename = > {" ipfix . egressInterface " = >" egressInterface "} rename = > {" ipfix . samplingInterval " = >" samplingInterval "} rename = > {" ipfix . sa mplin gAlgor ithm " = >" sam plingA lgorit hm "} rename = > {" ipfix . HTTPRequestType " = >" HTTPRequestType "} rename = > {" ipfix . HTTPRequestHost " = >" HTTPRequestHost "}

60

B. Instalace a konfigurační soubory ELK rename = > {" ipfix . HTTPRequestURL " = >" HTTPRequestURL "} rename = > {" ipfix . HT TP Req ue st Re fe re r " = >" H TTP Re qu es tR ef er er "} rename = > {" ipfix . HTTPResponseCode " = >" HTTPResponseCode "} rename = > {" ipfix . HTTPResponseType " = >" HTTPResponseType "} rename = > {" ipfix . tlsCliVer " = > " tlsCliVer "} rename = > {" ipfix . HTTPResponseType " = >" HTTPResponseType "} rename = > {" ipfix . HTTPResponseType " = >" HTTPResponseType "} rename = > {" ipfix . packetDeltaCount " = >" packetDeltaCount "} } } output { elasticsearch { hosts = > [" localhost :9200"] codec = > " json " } }

61

C Zdrojový kód komunikačního grafu Úprava dat pro komunikační graf Elasticsearch posílá data v jiném formátu, než je potřeba pro komunikační graf. Následující kód převádí tyto data do formátu asociovaného pole. layers = self . stackData ( data ) ; var j =0; var nodes = new Array () ; var k ~=0; var ip = new Array () ; for ( i =0; i < layers . length ; i ++) { if ( ip . indexOf ( layers [ i ][0]. x ) == -1) { ip . push ( layers [ i ][0]. x ) ; nodes . push ({ ip : layers [ i ][0]. x , number : layers [ i ][0]. y , id : k ~}) ; k ++; } else { var index = ip . indexOf ( layers [ i ][0]. x ) ; var num = nodes [ index ]. number ; nodes [ index ]. number = num + layers [ i ][0]. y ; } if ( ip . indexOf ( layers [ i ][0]. label ) == -1) { ip . push ( layers [ i ][0]. label ) ; nodes . push ( \{ ip : layers [ i ][0]. label , number : layers [ i ][0]. y , id : k ~\}) ; k ++; } else { var index = ip . indexOf ( layers [ i ][0]. label ) ; var num = nodes [ index ]. y ; nodes [ index ]. y = num + layers [ i ][0]. y ; } } var links = new Array () ; for ( i =0; i < layers . length ; i ++) {

62

C. Zdrojový kód komunikačního grafu links . push ( { source : ip . indexOf ( layers [ i ][0]. x ) , target : ip . indexOf ( layers [ i ][0]. label ) , number : layers [ i ][0]. y }) ; }

Komunikační graf - zdrojový kód v d3js // Select the current DOM element div = d3 . select ( this ) ; // Create the canvas for the visualization svg = div . append ( ’ svg ’) . attr ( ’ width ’ , width ) . attr ( ’ height ’ , height + margin . top + margin . bottom ) . append ( ’g ’) . attr ( ’ transform ’ , ’ translate (0 , ’ + margin . top + ’) ’) ; function draw ( nodes , links ) { var force = self . force = d3 . layout . force () . nodes ( nodes ) . links ( links ) . size ([ width -70 , height +70]) . charge ( -150) . linkDistance (80) . start () ; /** * Add links */ link = svg . selectAll ( ’ link ’) . data ( links ) . enter () . append ( ’ svg : line ’) . attr ( ’ class ’ , ’ link ’) . attr (" x1 " , function ( d ) { return d . source . x ; . attr (" y1 " , function ( d ) { return d . source . y ; . attr (" x2 " , function ( d ) { return d . target . x ; . attr (" y2 " , function ( d ) { return d . target . y ; . on (" mouseover " , function ( d ) { divLink . transition () . duration (200) . style (" opacity " , .9) ; divLink . html (" Size : " + d . number )

}) }) }) })

63

C. Zdrojový kód komunikačního grafu . style (" left " , ( d3 . event . pageX ) + " px ") . style (" top " , ( d3 . event . pageY - 28) + " px ") ; } ) . on (" mouseout " , function ( d ) { divLink . transition () . duration (500) . style (" opacity " , 0) ; }) . style (" stroke - width " , 2) ; /** * Drag function */ var node_drag = d3 . behavior . drag () . on (" dragstart " , dragstart ) . on (" drag " , dragmove ) . on (" dragend " , dragend ) ; function dragstart (d , i ) { force . stop () } function dragmove (d , i ) { d . px += d3 . event . dx ; d . py += d3 . event . dy ; d . x += d3 . event . dx ; d . y += d3 . event . dy ; tick () ; } function dragend (d , i ) { d . fixed = true ; tick () ; } /** * Add nodes */ node = svg . selectAll ( ’ node ’) . data ( nodes ) . enter () . append ( ’ circle ’) . attr ( ’ class ’ , ’ node ’)

64

C. Zdrojový kód komunikačního grafu . attr (" r " , function ( d ) { return 10; }) . attr (" id " , function ( d ) { return d . id ; }) . style (" fill " , function ( d ) { return c20 ( d . number ) ;}) . on (" mouseover " , function ( d ) { div . transition () . duration (200) . style (" opacity " , .9) ; div . html (" Field value : " + d . ip + " Size : " + d . number ) . style (" left " , ( d3 . event . pageX ) + " px ") . style (" top " , ( d3 . event . pageY - 28) + " px ") ; } ) . on (" mouseout " , function ( d ) { . div . transition () . duration (500) . style (" opacity " , 0) ; }) . call ( node_drag ) ; n = svg . selectAll ( ’ node ’) . data ( nodes ) . enter () . append (" text ") . attr (" dy " , function ( d ) { return -13}) . attr (" dx " , function ( d ) { return -37}) . attr (" class " , " nodetext ") . text ( function ( d ) { return d . ip }) ; var div = d3 . select (" body ") . append (" div ") . attr (" class " , " tooltip ") . style (" opacity " , 0) ; var divLink = d3 . select (" body ") . append (" div ") . attr (" class " , " tooltipLink ") . style (" opacity " , 0) ; force . on (" tick " , tick ) ; node . on (" mouseenter " , fade (.3) ) ; node . on (" mouseleave " , fade (1) ) ; /** * Create legend */ var legend = d3 . select ( ’ svg ’) . append (" g ")

65

C. Zdrojový kód komunikačního grafu . attr (" class " , " legenda ") . selectAll (" g ") . data ( c20 . domain () ) . enter () . append ( ’g ’) . attr ( ’ class ’ , ’ legend ’) . attr ( ’ transform ’ , function (d , i ) { var height = 27; var x = 1; var y = i * height +5; return ’ translate ( ’ + x + ’,’ + y + ’) ’; }) ; legend . append ( ’ rect ’) . attr ( ’ width ’ , 25) . attr ( ’ height ’ ,25) . style ( ’ fill ’ , c20 ) . style ( ’ stroke ’ , c20 ) ; legend . append ( ’ text ’) . attr (" class " , " textLegenda ") . attr ( ’y ’ , 25 -21 + 13) . attr ( ’x ’ , 25 + 10) . text ( function ( d ) { return d ; }) ; /** * Tick */ function tick () { link . attr (" x1 " , function ( d ) { return d . source . x ; }) . attr (" y1 " , function ( d ) { return d . source . y ; }) . attr (" x2 " , function ( d ) { return d . target . x ; }) . attr (" y2 " , function ( d ) { return d . target . y ; }) ; node . attr (" transform " , function ( d ) { return " translate (" + d . x + " ," + d . y + ") "; }) ; n . attr (" transform " , function ( d ) { return " translate (" + d . x + " ," + d . y + ") "; }) ; }; var linkedByIndex = {}; links . forEach ( function ( d ) {

66

C. Zdrojový kód komunikačního grafu linkedByIndex [ d . source . index + " ," + d . target . index ] = 1; }) ; function isConnected (a , b ) { return linkedByIndex [ a . index + " ," + b . index ] || linkedByIndex [ b . index + " ," + a . index ] || a . index == b . index ; } /** * Fade links and nodes */ function fade ( opacity ) { return function ( d ) { node . style (" stroke - opacity " , function ( o ) { thisOpacity = isConnected (d , o ) ? 1 : opacity ; this . setAttribute ( ’ fill - opacity ’ , thisOpacity ) ; return thisOpacity ; }) ; force . stop () ; link . style (" stroke - opacity " , opacity ) . style (" stroke opacity " , function ( o ) { return o . source === d || o . target === d ? 1 : opacity + 0.1; }) ; }; } } draw ( nodes , links ) ;

67