VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra technických studií Obor Aplikovaná informatika
Systém centrálního logování bakalářská práce
Autor: Jiří Týma Vedoucí práce: Ing. Martin Skoumal, DiS. Jihlava 2016
Abstrakt Analýza dostupných možností pro vytvoření infrastruktury pro systém centrální správy logů, včetně nástrojů pro vyhledávání a reporting. Nalezení optimálního řešení pro potřeby VŠPJ. Implementace zvoleného řešení s ohledem na výkonnost, rozšiřitelnost a vysokou dostupnost. Dále také návrh a implementace způsobu archivace logů tak, aby bylo zaručeno, že nedojde k jejich ztrátě.
Klíčová slova Centrální logování, Log management
Abstract Analysis of available options for creating infrastructure of centralized logging system, including tools for searching and reporting. Find the optimal solution for the environment of VŠPJ. Implement the chosen solution considering performance efficiency, scalability and high accessibility. Also suggest and implement a method of archiving logs in a way, which will assure they cannot be lost.
Key words Centralized logging, Log management
Prohlašuji, že předložená bakalářská práce je původní a zpracoval jsem ji samostatně. Prohlašuji, že citace použitých pramenů je úplná, že jsem v práci neporušil autorská práva (ve smyslu zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, v platném znění, dále též „AZ“). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím užitím k výuce nebo k vlastní vnitřní potřebě VŠPJ. Byl jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje AZ, zejména § 60 (školní dílo). Beru na vědomí, že VŠPJ má právo na uzavření licenční smlouvy o užití mé bakalářské práce a prohlašuji, že s o u h l a s í m s případným užitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom toho, že užít své bakalářské práce či poskytnout licenci k jejímu využití mohu jen se souhlasem VŠPJ, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených vysokou školou na vytvoření díla (až do jejich skutečné výše), z výdělku dosaženého v souvislosti s užitím díla či poskytnutí licence. V Jihlavě dne
…………………… Podpis
Poděkování Rád bych poděkoval celému týmu oddělení správy sítě Vysoké školy polytechnické Jihlava za odborné rady a poskytnutí materiálů, zejména Ing. Martinu Skoumalovi, DiS. za vedení bakalářské práce.
Obsah 1
Úvod .......................................................................................................................... 8
2
Životní cyklus logu ................................................................................................. 10
3
Analýza ................................................................................................................... 12
4
3.1
Transport ......................................................................................................... 12
3.2
Zpracování ...................................................................................................... 15
3.3
Ukládání .......................................................................................................... 16
3.4
Vizualizace a vyhledávání .............................................................................. 17
3.5
Archivace ........................................................................................................ 18
3.6
Ochrana aktiv .................................................................................................. 19
Praktická část .......................................................................................................... 21 4.1
Analýza prostředí ............................................................................................ 21
4.2
Výběr řešení .................................................................................................... 21
4.3
Pilotní nasazení ............................................................................................... 22
4.3.1
Fronta .......................................................................................................... 23
4.3.2
Archivace .................................................................................................... 27
4.4
Logstash .......................................................................................................... 28
4.4.1
Nastavení konfiguračních souborů.............................................................. 28
4.4.2
Parsování ..................................................................................................... 29
4.4.3
Notifikace .................................................................................................... 32
4.4.4
Sanitize MAC.............................................................................................. 33
4.4.5
GeoIP .......................................................................................................... 34
4.4.6
Odstranění původní zprávy ......................................................................... 35
4.4.7
Vnořené pole ............................................................................................... 35
4.4.8
Parsování CSV souborů .............................................................................. 36
4.4.9
Typová konverze ......................................................................................... 37
4.4.10
Rozdělování polí ..................................................................................... 37
4.4.11
Zahazování zpráv .................................................................................... 37
4.4.12
Přidání dalších polí.................................................................................. 38
4.4.13
Víceřádkový log ...................................................................................... 38
4.4.14
Ruby split logmessage ............................................................................ 39
4.5
Elasticsearch.................................................................................................... 41
4.6
Kibana ............................................................................................................. 42
4.6.1
Tvorba dashboardu ...................................................................................... 42
5
Testování ................................................................................................................. 44
6
Závěr ....................................................................................................................... 45
Seznam použité literatury................................................................................................ 46 Seznam obrázků .............................................................................................................. 50 Seznam tabulek ............................................................................................................... 51 Seznam zkratek ............................................................................................................... 52 Přílohy ............................................................................................................................. 53 Obsah přiloženého CD ................................................................................................ 53
1 Úvod Informační technologie se v dnešní době stávají stále více komplexními. Infrastruktura informačních technologií se skládá z mnoha nejrůznějších prvků. Od routerů a switchů, přes tiskárny a samozřejmě servery s různými operačními systémy – Windows, Linux a mnohé další. Každý z těchto prvků může generovat určité množství informací, takzvaných logů. Termínem log jsou zde myšlena všechna data, která obsahují časovou známku. Zde je ukázka errorlogu programu nginx. 2015/04/09 03:11:14[notice] 64782#0: cache loader process 64789 exited with code 0 (časová známka) (data) Logy zaznamenávají události, transakce, zprávy a vlastně cokoliv, co tvůrce softwaru považoval za důležité. V případě problému to může být právě log, co ukáže jeho příčinu. Logů je obvykle velké množství a správce nemá možnost všechny projít. Je tedy nutné tyto logy upravovat do lépe čitelné podoby, filtrovat a pracovat s užší množinou dat. K tomu se často používají regulární výrazy nebo jednoúčelové skripty, které výběr dat omezí podle zadaných kritérií. To vede k nutnosti vytvořit nový skript, pokud je potřeba získat jinou množinu dat. Neustálé vytváření nových skriptů je ale časově náročné, a navíc to nemusí každý, kdo potřebuje v logu nějakou informaci vyhledat, umět. V praxi se totiž setkáváme se situací, že specialisté na vyhodnocování logů neexistují. Vyhodnocování tedy často provádějí správci systémů bez patřičných znalostí. Často tuto úlohu vykonává pouze jediný člověk, na kterém jsou ostatní uživatelé závislí. V organizaci pak chybí zastupitelnost a takový pracovník se pro ostatní stává tzv. lidskou klávesnicí. Další nevýhodou takového přístupu je, že vyskytne-li se v logu událost, kterou do té doby správce nepovažoval za zajímavou, je pravděpodobné, že regulární výraz na ni nebude reagovat. Takováto zpráva tedy unikne pozornosti, kterou by si možná zasloužila. Navíc pro správce budou zcela postrádat smysl logy obsahující výkonnostní charakteristiky, které se dají vyhodnotit, pouze pokud jsou agregované v čase a zobrazené např. v grafech. Jako příklad uveďme počet přenesených bytů u http požadavků.
8
Jedním z prvních řešení pro logování byl Syslog, který se stal standardem na Unixových systémech. Různé variace jeho implementací existují i na jiných operačních systémech. Obvykle je můžeme nalézt i na síťových zařízeních, například routerech.
9
2 Životní cyklus logu Každý log prochází určitým životním cyklem. Vzniká, je zapsán na disk a časem je smazán. V typickém systému se všechny tyto procesy dějí v rámci každého serveru zvlášť, takže na serveru, kde log vzniká, také zaniká. Logy jsou uloženy na svých příslušných serverech a nejsou sdílené, mezi servery neputují a jsou od sebe odstíněny. Takto probíhá životní cyklus logu na typickém systému.
Server 1
Server 2
Obrázek 1: Servery s logy, které nikam neputují
Pokud chce správce vyhledat v takovémto logu informaci, musí se připojit k danému serveru, vyhledat správný soubor logu a v něm tuto informaci najít. Navíc potřebuje mít přístupová práva k tomuto serveru, a také ke konkrétnímu souboru. Když se vyskytne problém napříč více systémy, je nutné se postupně přihlásit ke všem a pokusit se v nich nějak orientovat. Tento způsob vyhledávání informací v logu lze použít pouze při správě menšího množství serverů s malým nebo středním provozem. V momentě, kdy je serverů větší množství, nebo je větší množství požadavků, je tento způsob vyhledávání informací nepoužitelný. Řešení situace s velkým množstvím různorodých logů a jejich dalším zpracováním pro pozdější analýzu, nabízí právě centrální logovací systém. Díky centrálnímu logovacímu systému se zcela vyhneme problémům spočívajících v nutnosti správce přistupovat k jednotlivým serverům, jelikož jsou data přístupná na jednom místě. Toho je dosaženo pomocí odesílání logů na společné místo, kde proběhne zpracování a následné uložení těchto dat. Teprve nad těmito zpracovanými daty jsou prováděny analýzy. Ve chvíli, kdy není potřeba s daty dále pracovat, jsou archivována a nakonec smazána.
10
Životní cyklus logu v centralizovaném systému si můžeme představit následovně:
Vznik
Transport
Ukládání
Analýza
Smazání
Obrázek 2: Životní cyklus logu v centralizovaném systému
V další části této práce budou jednotlivé fáze životního cyklu logů podrobně popsány. Dále bude v praktické části uvedena ukázka nasazení konkrétního řešení v prostředí VŠPJ.
11
3 Analýza K vytvoření centrálního systému pro správu logů je potřeba poskládat celou strukturu
z komponent řešících jednotlivé fáze životního cyklu logu. Tyto fáze zahrnují transport logů ze serverů, kde vznikají, na společné místo. Dále pak zpracování těchto logů do potřebné podoby, jejich uložení a následné vyhledávání informací a provádění analýz nad těmito daty.
Server 1
Transport logu
Server 2
Zpracování
Uložení
Vizualizace, vyhledávání
Server 3 Obrázek 3: Cesta logu v centralizovaném systému
Tento proces lze realizovat pomocí nasazení kompletního řešení – programu, který zahrnuje všechny fáze životního cyklu logu, nebo je možné použít více specializované programy, které budou zvládat jednu či více z těchto funkcí. V následující části budou jednotlivé fáze podrobněji popsány.
3.1 Transport V samém počátku životního cyklu logu je logová zpráva vytvořena programem (zdrojem logu). Předtím, než se správce pustí do samotného zpracovávání zpráv, je potřeba vyřešit jejich transport ze serveru, kde vznikají, na server centrální. Ne všechny programy umí logová data posílat po síti nebo zapisovat do Syslogu, některé jsou totiž schopné pouze zapsat data na disk. V takovém případě musí být součástí transportu i přečtení těchto dat z disku a jejich odeslání na centrální server. Existují různé transportní mechanismy zajišťující doručení logových zpráv na centrální server. Kvůli citlivé povaze logů je jedním z požadavků možnost šifrování dat při přenosu 12
mezi stroji. Dále by měl být zaručen spolehlivý přenos, to znamená zajištění doručení všech zpráv. Při přenosu dat prostřednictvím sítě typu Ethernet jsou k dispozici dva základní přenosové protokoly: TCP a UDP. Protokol TCP (Transmission Control Protocol) kontroluje přenos paketů, a v případě, že nejsou doručeny, zajišťuje jejich opětovný přenos. S pomocí TCP je tedy transport logů poměrně spolehlivý, nicméně TCP samo o sobě není šifrované. Otevření spojení Handshake Klient
Požadavek
Server
Odpověď Ukončení spojení Obrázek 4: Příklad TCP komunikace
Na Unixových systémech je ukládání a transport logů obvykle řešen pomocí Syslogu, který umožňuje odesílání logovaných dat na jiný server pomocí UDP (User Datagram Protocol). Hlavní nevýhodou protokolu UDP je, že pokud dojde ke ztrátě paketu, nikdo se o tom nedozví. Přenos pomocí UDP není šifrovaný, ale některé programy dokáží přenos zabezpečit a tím odstranit nedostatky takového spojení.
Požadavek Klient
Odpověď
Server
Obrázek 5: Příklad UDP komunikace
Z obrázků je na první pohled patrné, že je režie v případě protokolu UDP nižší. Zásadní výhodou jeho používání tedy je, že zvládne přenášet obrovské množství dat v krátkém čase. Proto se často vyplatí postavit řešení na UDP, a programově dodělat požadovanou vlastnost, kterou může být například opětovné zasílání nedoručených zpráv. DTLS (Datagram Transport Layer Security) je založen na tokově orientovaném protokolu TLS, a poskytuje podobné bezpečnostní záruky, ale nad protokolem UDP. To znamená, že UDP obohatí o integritu, autentifikaci a šifrování. DTLS doručuje tok bytů, takže na 13
rozdíl od obyčejného UDP dokáže detekovat ztracené datagramy a obsahuje i svůj vlastní mechanismus pro opětovné zaslání zpráv. Díky těmto vlastnostem se DTLS zdá být nejvhodnějším protokolem pro transportu logů. Při výběru transportního nástroje se správce musí ohlížet i na typ operačního systému původního serveru, a buď vybrat program, který umí zpracovat logy z různých OS, nebo vybrat pro každý OS jiné řešení. V druhém případě musí být centrální server schopný přijmout různé typy vstupů. V praxi se běžně setkáváme s výpadky, a to ať vlivem softwaru, nebo výpadkem sítě. Taková situace samozřejmě může vést ke ztrátě dat. Způsobem jak bránit ztrátě dat při výpadku cílového serveru je například buffer (vyrovnávací paměť) na straně klienta. Klient tak má způsob jak uchovat data, dokud nedojde k obnovení spojení. Dalším řešením pro zamezení ztráty dat je implementace fronty. Ta je v sobě schopná při výpadku, ať už plánovaném či neplánovaném, zachovat zprávy. Ty se v ní budou hromadit, než se obnoví spojení se serverem, který tyto zprávy zpracovává. Díky těmto vlastnostem fronta navíc umožňuje snadnou údržbu a upgradování strojů. U transportních programů se obvykle dbá na úspornost zdrojů. Nejvhodnější jsou proto programy s malou spotřebou paměti. Většina jich tedy sahá k použití jazyka C, jak je patrné v tabulce 1. V současnosti se začíná prosazovat použití jazyka Go.
14
Tabulka 1: Přehled transportních programů a jejich vlastností
Program
TCP výstup
UDP výstup
Zabezpečení
Zaručení doručení zpráv
Filebeat [1]
Ano
N/A
TLS
Ano
Syslog-ng [2]
Ano
Ano
TLS
Ano
Rsyslog [3]
Ano
Ano
TLS
Ano
Nxlog [4]
Ano
Ano
TLS
Syslog [5]
Ano
Ano
Fluentd [6]
N/A
N/A
Podporované OS
Buffer
Komprese
Jazyk
Ano
Ano
Go
Ano v PE 1
Ano v PE
C
Linux, OS X, Windows
Ano
Ano
C
Ano
Linux, Windows
Ano
N/A
C
TLS
Ano
Linux
Ne
Ne
C
TLS
Ano
Linux, Mac OSX
Ano
Ano
C, Ruby
Linux, Windows Linux, Mac OS X, Windows v PE
3.2 Zpracování Většina logových zpráv je zasílána v nestrukturované podobě a cílem fáze zpracování je konvertovat data do požadované struktury. Proces normalizace je převedení různých reprezentací stejných typů dat do jednotného formátu. To může zahrnovat například převod časů na společný formát, IP adresy na doménová jména, apod.
1424822433.996 Unixový čas v sekundách
25/Feb/2015:00:00:33 +0100
2015-02-25T00:00:33.996Z Čas normalizovaný pomocí programu Logstash
Čas ve formátu ISO 8601 Obrázek 6: Příklad normalizace časů
Normalizace se dá dosáhnout různými způsoby. Jednou z možností je systém založený na regulárních výrazech, ale psaní a starání se o velké množství regulárních výrazů může být náročné a výskyt chyb bude pravděpodobně také vyšší.
15
Parsování je proces analýzy a transformace vstupního textu na datové struktury určitých typů. Většina nástrojů je tedy založena na určitých vzorcích, toto parsování probíhá na základě pevně daných řetězců a porovnávání se dělá pomocí předdefinovaných typů polí. Tento způsob sice v základu stojí také na regulárních výrazech, ale v tomto případě se o ně správce již nemusí starat. Fáze zpracování logů může probíhat na centrálním serveru, nebo na jednotlivých klientech. Možnost zpracování dat na straně klienta se zpravidla nevolí kvůli velkým nárokům na výkon, který klienti zpravidla potřebují pro svoji činnost, jakou může být například provoz webových serverů. Proto se v zásadě volí varianta, kde jsou data zpracovávána na centrálním serveru. Další výhodou je, že všechna pravidla parsování jsou uložena na jednom místě, a dají se snadno změnit. Vyšší výpočetní náročnost při větším objemu dat se pak zpravidla řeší rozdělením zátěže na více serverů. Při výběru řešení je třeba toto zohlednit a vybírat pouze nástroje, které lze snadno škálovat. Škálování se dá popsat jako rozšiřování systému za účelem zvýšení výkonu. Škálování rozdělujeme do dvou skupin – vertikální a horizontální. Vertikální škálování znamená navyšování výkonu serveru. Horizontální škálování je přidávání dalších serverů. V případě běžného provozu, kde dochází k většímu zatížení jen jednou za čas (např. nárazově velký počet klientů v e-shopu), nemá smysl mít více serverů, ale je lepší implementovat frontu, která data podrží a server je postupně zpracuje. Tabulka 2: Přehled programů vhodných pro zpracování logů Program
Vstup dat
Normalizace
Škálování
Jazyk
Logstash [7]
beats, lumberjack, rabbitmq, redis, unix , zeromq, TCP, UDP, RELP, ...
Ano
Pomocí fronty
Ruby
Graylog2 [8]
Syslog, GELF, TCP, UDP, JSON, nxlog, heroku
Ano
Nativně
Java
Splunk [9]
Files and directories, TCP, UDP, Windows, ...
Ano
Nativně
C++
3.3 Ukládání Pouhé ukládání normalizovaných logů není dostatečné. Aby byly logy naplno využity, je třeba nad nimi provádět analýzu, což znamená, že k datům bude nutné opakovaně 16
přistupovat. Proto během této fáze dochází nejen k uložení dat, ale obvykle i jejich indexaci, která urychlí jejich pozdější vyhledávání. Řešením bývá zpravidla relační databáze nebo NoSQL systém. V NoSQL systémech, jakými jsou například MongoDB nebo Elasticsearch, jsou data ukládána v JSON, XML, nebo jiných datových formátech. Takové soubory mohou být indexovány pro urychlení vyhledávání. Hlavní výhodou NoSQL je především možnost jednoduchého škálování a shardování (horizontální dělení dat mezi více servery). Takové řešení je nutné v prostředí, kde se pracuje s velkým množstvím dat (řádově terabyty). V případě relačních databází je hlavní výhodou agregace dat. Problém nastává s velkým objemem dat, protože relační databáze se hůře škálují a cena za licence je v takové situaci příliš vysoká. Tabulka 3: Programy vhodné pro fázi ukládání logů Program
SQL
NoSQL
Indexace
Škálování
Formát
Jazyk
Elasticsearch [10]
Ne
Ano
Ano
Ano
JSON
Java
MongoDB [11]
Ne
Ano
Ano
Ano
BSON
C++
PostgreSQL [12]
Ano
Ano
Ano
Ano
JSONB
C
3.4 Vizualizace a vyhledávání Logy mohou být uloženy jakkoliv pěkně, ale bez vizuálního výstupu a korelace to správci bude k ničemu. Proto by pro plné využití všech předchozích kroků měl mít správce k dispozici nejrůznější vizualizace, grafy, filtrování a vyhledávání. Nástroj pro vizualizaci by měl v ideálním případě umožňovat tvorbu odlišných náhledů pro různé typy logů. Jelikož je často potřeba zobrazovat rozdílné informace pro různé druhy uživatelů, bylo by vhodné, aby tento interface řešil i různé úrovně uživatelských přístupů. Existuje několik webových aplikací, které umí zobrazit různé aspekty logových událostí. Většina z nich je integrovaná do některého logovacího nástroje, např. Octopussy, Graylog2 nebo Elsa.
17
Tabulka 4: Přehled programů pro vizualizaci a vyhledávání Program
Vstup dat
Webová aplikace
Jazyk
Kibana 4 [13]
Elasticsearch
Ano
JRuby
Graylog2 [8]
Elasticsearch
Ano
Javascript
Octopussy [14]
MySQL
Ano
Perl
Elsa [15]
MySQL
Ano
Perl
3.5 Archivace Všechna data, která systémem prochází, je potřeba archivovat, aby je bylo možné při selhání obnovit. V případě centrálního logování je hlavní otázkou, kdy data zálohovat. To znamená výběr správné fáze životního cyklu pro jejich zálohování. Archivace hned na počátku, tedy na jednotlivých klientech znamená, že data nejsou centralizovaná. To dělá práci s daty, která mohou vznikat na různých typech serverů, poměrně složitou. Oddělenost jednotlivých klientů navíc výrazně zvyšuje složitost obnovy dat. Archivace dat po jejich sesbírání na centralizovaném serveru ještě před jejich zpracováním se zdá být nejvhodnější volbou. V této fázi totiž ještě nedošlo ke ztrátě žádné části dat kvůli normalizaci. Na druhou stranu je z tohoto důvodu objem původních dat maximální. Také je potřeba dát pozor na situaci, kdy se parametry zpracování změnily, což by vedlo k odlišným výsledkům normalizace. To může nastat například při překladu doménových jmen na IP adresy. Výhodou archivace dat po jejich zpracování je, že již došlo k jejich zpracování. Rychlost obnovy je tedy výrazně vyšší než v předchozím případě. Velikou nevýhodu ovšem spatřujeme v tom, že pokud by v budoucnu byla zjištěna chyba v procesu normalizace, zahozenou část dat už není možné dostat zpět. Je jenom smysluplné, že záloha by měla být jinde než u produkčních dat. Samotný indexovací nástroj by se měl specializovat pouze na indexování dat a nestarat se i o jejich archivaci.
18
Tabulka 5: Přehled možností archivace logů Místo archivace
Riziko ztráty dat při normalizaci
Rychlost obnovy
Velikost dat
Klient
Ne
Pomalá
Výchozí
Ne
Pomalá
Výchozí
Ano
Rychlá
Záleží na normalizaci, obvykle vyšší
Centrální server před normalizací Centrální server po normalizaci
3.6 Ochrana aktiv Business continuity planning (dále jen BCP) je systém prevence a kroků vedoucích k obnovení klíčových prvků infrastruktury v případě jejich selhání. Jakákoliv událost, která by mohla negativně ovlivnit obvyklý chod infrastruktury je v tomto plánu zahrnuta. Takové selhání může být krátkodobé, s minimálním dopadem, které je možné vyřešit během minut, nebo závažné, jejichž odstranění může být i v řádech dní. Současným standardem pro BCP je BS ISO22301:2012. [16] BCP zahrnuje analýzu, určení strategií, implementaci, testování a údržbu. Cílem kroku analýzy je identifikace kritických činností, procesů a zdrojů, které podporují klíčové funkce organizace. Za kritické se považují takové činnosti, jejichž přerušení je považováno za nepřijatelné. Proto jsou stanoveny přesné požadavky, které bude potřeba vynaložit na řešení jednotlivých situací. Při hodnocení přijatelnosti rizik je obvykle nahlíženo právě na výši vynaložených nákladů. Obvyklé hrozby zahrnují výpadek proudu, požár, krádež, zemětřesení, epidemii, válku, a další. Z těchto příkladů je patrné, že některým rizikům nelze předejít, proto je nutné se s nimi smířit a pokusit se minimalizovat jejich dopad. V případě IT se jedná především o specifické hrozby typu výpadek serveru či poškození hardware. Při určení strategií jsou navrženy různé postupy reakcí při jednotlivých incidentech. Při tom je třeba zohlednit maximální přijatelnou dobu narušení těchto činností a také náklady na implementaci konkrétních strategií obnovy. Část implementace určuje přesné kroky pro jednotlivé plány obnovy kritických činností. V těchto plánech by měly být identifikovány činnosti i zdroje nutné pro řešení krizových situací.
19
Ve fázi testování jsou plány detailně zkontrolovány a je zhodnoceno, zda jsou funkční a úplné. Testování a revize by měly probíhat v pravidelných intervalech, a také když dojde v organizaci k významným změnám. V případě centrálního logování by kromě obecných hrozeb měl BCP především předcházet a zamezit výpadkům a ztrátě dat, ať už z důvodu selhání hardware, software nebo lidské chyby. Dále následují některé příklady hrozeb a způsoby jak jim předcházet nebo zmírnit jejich dopad.
Selhání hardware – servery v režimu vysoké dostupnosti
Výpadek napájení – záložní zdroj
Konektivita – náhradní konektivita
Požár, zemětřesení – více datových center
Krádež – zabezpečovací systémy
Ztráta dat – zálohování
20
4 Praktická část Praktická část této práce se zabývá nasazením centrálního logovacího systému v prostředí VŠPJ. V dalších kapitolách je popsána analýza prostředí, dále postup při výběru vhodného software, a poté přesný způsob implementace, včetně popisu zvoleného software.
4.1 Analýza prostředí Prvním krokem při vytváření jakéhokoli systému je zjištění požadavků a potřeb zákazníka. V případě VŠPJ bylo cílem umožnit snadný a přehledný přístup k logům, především k logům serverů informačního systému, kvůli jejich důležitosti pro programátorský
tým.
Jelikož
dlouhodobou
strategií
odboru
informačních
a komunikačních technologií je nasazovat bezplatná a open-source řešení, bylo nutné, aby všechny použité programy tyto vlastnosti splňovaly. Mimo to měly být vybrané programy stále aktivně vyvíjeny. Posledním kritériem byla snadná rozšiřitelnost a škálovatelnost. Tyto vlastnosti umožní v budoucnu snadné navýšení výkonu a také dovolí řešení nasadit ve vysoké dostupnosti, díky čemuž bude jednotlivé systémy snadné udržovat.
4.2 Výběr řešení Výběr probíhal od konce – tedy vizualizace, jelikož zde bylo nejméně možností voleb. Pak byly prozkoumány dostupné programy vhodné pro předchozí fáze a porovnána jejich schopnost spolupráce a kompatibility. Tímto způsobem se postupovalo až na začátek, tedy k samotnému způsobu sběru logů z jednotlivých strojů. Mezi zvažované varianty patřil Graylog2. Jedná se o kompletní řešení správy logů, včetně vizualizace přes webové rozhraní. Data jsou ukládány do elasticsearch clusteru a statistiky a grafy do MongoDB. Zprávy mohou být zasílány nestrukturovaně pomocí syslogu nebo v GELF, což je unikátní strukturovaný formát Graylogu. [8]
Dalším ze zvažovaných programů byl Splunk. Ten funguje jako kompletní řešení s širokou škálou možností pro zpracování logových zpráv, včetně jejich vizualizace a monitoringu. Splunk ale bohužel není zdarma, ani open-source, ačkoliv nabízí zdarma verze pro vyzkoušení, s omezenou kapacitou dat. [17] Jako řešení byl vybrán ELK Stack, což je kombinace programů Elasticsearch, Logstash a Kibana. Za vývojem těchto produktů stojí společnost Elastic, která ke svým produktům 21
také nabízí komerční podporu. Logstash slouží k transportu a normalizaci logů, Elasticsearch indexuje data a Kibana slouží jako interface pro vyhledávání logů a umožňuje jejich vizualizaci. Jedná se o programy, které byly původně vyvíjeny samostatně různými lidmi a později byly sdruženy pod společnost se současným názvem Elastic. To zaručuje, že jsou odladěny, aby mezi sebou dokázaly snadno spolupracovat. Díky tomu je možné ELK Stack použít jako kompletní řešení pro centrální správu logů. Jednotlivé programy mají navíc k dispozici rozsáhlou dokumentaci a širokou vývojářskou základnu. Aplikovatelnost těchto nástrojů v praxi dokazuje jejich užití řadou velkých společností. Jako příklad uveďme alespoň několik známějších. Mozilla například využívá nástroje Elasticu pro správu událostí. GitHub a SoundCloud je využívají pro uživatelské vyhledávání. [18]
4.3 Pilotní nasazení Jako pilotní nasazení bylo zvoleno zpracování logů aplikačních serverů, které běží na OS Linux a webovém serveru Nginx. Zde byl jako nástroj pro transport nasazen Logstashforwarder (který je v současnosti zastaralý a byl nahrazen programem Filebeat). Dále bylo potřeba napojit doménové kontrolery (Active Directory), které běží na OS Windows. V tomto případě byl pro získávání a transport logů použit program Nxlog. Zvolené programy zasílají logové zprávy na centrální server, kde jsou Logstashem přijmuty a označeny podle zdroje, ze kterého pochází – tedy vlastně podle úlohy, kterou plní. Logstash tyto logy následně předává do fronty, takže tento první centralizovaný server pouze plní úlohu dispatchingu.
22
Server 1
Log
Logstash dispatcher
Server 2
RabbitMQ
Logstash parser
Záloha
Server 3
Elasticsearch
Kibana
Obrázek 7: Znázornění infrastruktury centrálního logování na VŠPJ
4.3.1 Fronta Hlavní výhodou implementace fronty v prostředí VŠPJ je, že pokud server Logstash parser není schopen přijímat data, jsou tato data uchována ve frontě. Toto uchování trvá do té doby, než je služba obnovena a zprávy nejsou úspěšně předány. Důvody pro neschopnost serveru přijímat zprávy mohou být jak plánované, tak neplánované. Plánovanými důvody mohou být například vypnutí služby kvůli upgradu softwaru. Neplánovanými důvody potom mohou být např. softwarová chyba nebo jen příliš velké zatížení programu Logstash. Další výhodou fronty je, že místo masivního navyšování výkonu serverů tak můžeme v případě výkonnostní špičky uchovat data ve frontě, odkud jsou postupně zpracovávána. Fronta navíc umožňuje snadné škálování jednotlivých komponent celé architektury. Důležitým kritériem byla tzv. perzistence dat. Ta vyjadřuje, zda je fronta schopná si při restartu v sobě data zachovat. O naplňování fronty se stará tzv. broker. Pro jeho implementaci existuje řada programů, z nichž je většina založena na protokolu AMQP. Na VŠPJ bylo zvažováno použití těchto čtyř programů:
RabbitMQ – Má slušný výkon, perzistenci dat, jednoduché nasazení a konfiguraci. [19]
Redis – Redis je populární volbou a je často využíván právě pro plnění takovýchto funkcí. [20]
ZeroMQ – Výhodou je velmi vysoký výkon, bohužel nemá perzistenci dat. [21] 23
Apache Kafka – Open-source broker napsaný v jazyce Scala, slibující rychlost, škálování a perzistenci zpráv. V současné době jde ještě o velmi mladý projekt. [22]
Pro implementaci fronty v prostředí VŠPJ byl zvolen program RabbitMQ. RabbitMQ disponuje pro současné potřeby VŠPJ dostatečným výkonem, je open-source a lze ho nasadit v clusteru. Navíc splňuje i požadavek na perzistenci dat. Především je ale RabbitMQ praxí ověřený a spolehlivý, ve svých produktech ho využívá např. firma VMware a na VŠPJ s ním už máme také pozitivní zkušenosti. Na obrázku 8 je vidět rozbor funkčnosti brokeru, v tomto případě konkrétně programu RabbitMQ. Exchange v podání AMQP protokolu slouží jako vstupní bod pro příjem zpráv. Exchange tedy nejprve přijme zprávu a poté ji na základě svého typu pošle nula nebo více frontám. Samotná fronta je připojena k jedné nebo více exchange, spojení mezi frontou a exchange se nazývá binding. Každá fronta může mít několik konzumerů, kterým zprávy předává. Konzumeři jsou v našem případě Logstash parser a zálohovací server. [23]
Obrázek 8: Příklad cesty zprávy v program RabbitMQ [23]
24
RabbitMQ má následující čtyři druhy exchange:
Direct Exchange – Tento typ exchange je založen na routovacím klíči (routing key), pomocí kterého je zpráva označena a následně předána frontě s odpovídajícím klíčem. Její aplikace je ideální pro unicast (ačkoliv může být použita i pro multicastové doručování).
Obrázek 9: Funkce Direct exchange [23]
Fanout Exchange – V tomto případě je kopie zprávy doručená do každé připojené fronty. Pokud je tedy připojeno N front, kopie zprávy je doručena všem N frontám. Ideální v případě broadcastu.
Obrázek 10: Funkce Fanout exchange [23]
25
Topic Exchange – Zde je zpráva doručena jedné nebo více frontám podle routovacího klíče a vzorce, který byl použit pro připojení fronty. Obvykle se používá pro multicast.
Headers Exhange – Při použití tohoto typu exchange je routovací klíč ignorován, zprávy jsou doručeny frontám, pokud údaje v jejich hlavičce odpovídají hodnotě specifikované při připojení konkrétní fronty.
Na VŠPJ jsou použity dva druhy exchange. Prvním je fanout exchange, využitý pro předávání stejných dat jak Logstash parseru, tak i zálohovacímu serveru. Druhým typem je direct exchange, který je využíván pro vstup dat ze zálohy. Konfigurace exchange a front RabbitMQ probíhá skrz webové rozhraní.
Obrázek 11: RabbitMQ administrace - správa exchange
26
Obrázek 12: RabbitMQ administrace - správa front
4.3.2 Archivace Kvůli bezpečnosti by měla být data zálohovaná na zcela jiném místě, než jsou produkční data. Díky implementaci fronty to není problém, protože server může být úplně kdekoli. Na VŠPJ byla archivace zvolena mezi Logstash dispatcherem a Logstash parserem. To znamená v místě, kde jsou data centralizovaná, ale ještě před jejich normalizací. Jak již bylo řečeno v předchozí kapitole, data pro archivaci jsou vytahována z fronty a taktéž při obnově jsou odesílána do fronty. V obou případech se tak děje pomocí programu Logstash. V současnosti ještě nebyla vyřešena limitace s DNS záznamy, které se mohou v čase měnit. Čím větší množství dat budeme v záloze mít, tím lepší potřebujeme hardware, a to se samozřejmě odrazí na ceně. Proto je potřeba si definovat, jak stará data je v našich podmínkách nutné uchovávat. Starší data jsou pak v průběžných časových intervalech mazána, aby nedošlo místo. K tomu může sloužit buď skript, nebo enterprise řešení. Jedním z populárních je například Bacula.
27
V našem prostředí zálohovaná data zůstávají v plaintextu, a po určitém čase, který je v současnosti nastaven na jeden týden, jsou komprimována. Pro jejich obnovu pak slouží skript v bashi, který tato data rozbalí a pošle do fronty. Data starší než šest měsíců jsou nakonec mazána.
4.4 Logstash Logstash je open-source nástroj pro sběr dat s možností zřetězeného zpracování, který umí dynamicky spojit data z rozdílných zdrojů a normalizovat je do výstupů dle našeho výběru. Logstash je tedy v podstatě ekvivalentem ETL procesu v business intelligence. [24]
4.4.1 Nastavení konfiguračních souborů V programu Logstash byl vytvořen konfigurační soubor, který se dělí na 3 části. V části input je nejprve specifikováno, z jakých zdrojů logy přicházejí. Část filter určuje jejich přesný způsob parsování a normalizace. Poslední částí je output, který uvádí, kam mají být logy dále odeslány. Pro každou z těchto částí má Logstash k dispozici celou řadu pluginů. V sekci output je to například Elasticsearch_http, kdy jsou pomocí HTTP protokolu data předávána do Elasticsearch, kde probíhá jejich indexace, nebo File, který umožní výstup směřovat do souboru, což se hodí především při debuggingu. Jednoduchý příklad by mohl vypadat následovně. [25] input { lumberjack { port => 6782 ssl_certificate => "/etc/logstash/lumberjack.crt" ssl_key => "/etc/logstash/lumberjack.key" } } filter { if [type] == "firewall_linux" { grok { match => ['message', '%{FIREWALL_LINUX}'] } } output { elasticsearch_http { host => localhost } file
{
path => "/tmp/output.txt" codec => rubydebug } }
28
Již po přidání pravidel pro rozparsování prvního logu začíná být konfigurační soubor poměrně dlouhý. Umístění filtrů do jednoho souboru je nepřehledné a kvůli jeho délce i při těch nejmenších úpravách velice zdlouhavé a problematické. Logstash bohužel nepodporuje direktivu include, ale naštěstí lze situaci vyřešit použitím více konfiguračních souborů, které logstash načte v abecedním pořadí. V případě distribuce Debian je načítá ze složky /etc/logstash/conf.d/. Soubory je nutné vhodně pojmenovat tak, aby byl načten nejprve soubor s definicí vstupů, poté soubory, kde jsou jednotlivá filtrovací pravidla a nakonec soubor s definicí výstupů. Bylo zvoleno číslování 00_input.conf pro nastavení vstupu, 99_output.conf pro výstup a mezi nimi jsou
soubory
s
filtry
pro
jednotlivé
typy
logů,
například
20_filter_mail_postfix.conf.
4.4.2 Parsování Protože cílem parsování je rozdělit původní zprávu na její jednotlivé hodnoty, je nejprve potřeba vytvořit vzorec, který určí, kde se jaký druh informace nachází, jak je pojmenovat, a případně i o jaký typ hodnoty jde. Pro parsování používáme filter grok, který funguje na základě kombinace textových vzorů do podoby odpovídající struktuře logu. Syntaxe groku je %{SYNTAX:SEMANTIC}, kde syntax vyjadřuje, jaký typ hodnoty očekávat (podle jakého vzoru hodnotu parsovat), a semantic určuje její jméno. V závorkách se může vyskytovat ještě třetí hodnota, která udává, jaký datový typ bude hodnotě přiřazen. Pokud není uvedena, bude s ní dále pracováno jako s řetězcem znaků. [26] %{NOTSPACE:remote_user} %{INT:status:int} Řada těchto parsovacích vzorců je v programu Logstash předdefinovaná a lze je nalézt ve složce patterns. Z příkladu je patrné, že se vlastně jedná o regulární výrazy. Pokud jsou pro rozložení našich logových zpráv vzorce poskytnuté Logstashem nedostatečné, je možné nadefinovat naše vlastní. Stačí vytvořit správně strukturovaný soubor a vložit ho do stejné složky. Výrazy samozřejmě mohou obsahovat i odkazy na jiné výrazy. V následující ukázce je vidět vzorec pro parsování IP adres a různých druhů zápisu MAC adres. Ty jsou v posledním řádku sdružené, takže při použití patternu MAC je z nich vybrán ten, který pasuje.
29
cat /opt/logstash/patterns/grok-patterns IP (?:%{IPV6}|%{IPV4}) HOSTNAME \b(?:[0-9A-Za-z][0-9A-Za-z-]{0,62})(?:\.(?:[0-9A-Za-z][0-9A-Za-z]{0,62}))*(\.?|\b) IPORHOST (?:%{HOSTNAME}|%{IP}) CISCOMAC (?:(?:[A-Fa-f0-9]{4}\.){2}[A-Fa-f0-9]{4}) WINDOWSMAC (?:(?:[A-Fa-f0-9]{2}-){5}[A-Fa-f0-9]{2}) COMMONMAC (?:(?:[A-Fa-f0-9]{2}:){5}[A-Fa-f0-9]{2}) MAC (?:%{CISCOMAC}|%{WINDOWSMAC}|%{COMMONMAC})
Na VŠPJ je používán webový server Nginx s vlastním upraveným formátem logování. Takto vypadá jeho konfigurace v případě VŠPJ. cat /etc/nginx/include/logging.conf log_format combined_ssl '$remote_addr - $remote_user [$time_iso8601] $msec $request_time ' '$ssl_protocol/$ssl_cipher ' '"$http_host" "$request" $status $body_bytes_sent "$sent_http_content_type" ' '"$http_referer" "$http_user_agent" ' '"$upstream_addr" "$upstream_response_time" $pipe ' '$uid_set $uid_got "$request_id"';
Dále následuje ukázka logové zprávy vytvořené programem Nginx podle této konfigurace. cat /var/log/nginx/www.access_log 136.243.XXX.XXX - - [2016-03-18T10:15:08+01:00] 1458292508.953 0.276 TLSv1.2/ECDHE-RSAAES128-GCM-SHA256 "www.vspj.cz" "GET /skola/kontakty/detail/zamestnanec/1156 HTTP/1.1" 200 3282 "text/html; charset=UTF-8" "-" "Mozilla/5.0 (compatible; BLEXBot/1.0; +http://webmeup-crawler.com/)" "192.168.XXX.XXX:80" "0.276" . brid=BBCF71C334C5EB56F60CF66C02961203
Soubor se specifikací způsobu parsování našeho logu vypadá takto: cat /opt/logstash/patterns/load_balancer NACCESS %{IPORHOST:remote_addr} - (?:-|%{NOTSPACE:remote_user}) \[%{TIMESTAMP_ISO8601}\] %{NUMBER:msec:float} %{NUMBER:request_time:float} %{SSL_PROTOCOL_CIPHER} "(?:|%{HOST:http_host}(:%{INT:http_host_port})?)" %{REQUEST} %{INT:status:int} %{INT:body_bytes_sent:int} (?:"-"|%{QS:mime_type}) (?:""|"-"|%{QS:http_referer}) (?:|%{QS:http_user_agent}) %{UPSTREAM} %{NOTSPACE:piped} (?:-|brid=%{BASE16NUM:brid_set}) (?:-|brid=%{BASE16NUM:brid_got}) %{QS:request_id}
Jedním
z
patternů, které
jsme
si
museli
nadefinovat
sami,
je
například
SSL_PROTOCOL_CIPHER. Jeho podoba je následující: SSL_PROTOCOL_CIPHER (?:-|%{USER:ssl_protocol})/(?:-|%{USER:ssl_c})
30
Tento pattern slouží k rozparsování použitého šifrování. Jeho část pojmenovaná ssl_c je pak znovu parsována ve filtrech, které se používají pro získání podrobných informací o použité šifře. Řetězec, na který se v tomto případě pravidlo aplikuje: TLSv1.2/ECDHE-RSA-AES128-GCM-SHA256
Mimo počáteční fázi analýzy je to právě tvorba filtrů a parsovacích vzorců, co zabírá na celé tvorbě centrálního logovacího systému nejvíce času a tvoří i největší podíl práce. V této fázi se tedy vyplatí být velice důsledný, jelikož i při sebemenší chybě ve vzorci nebude grok správně fungovat. Při změně filtrů či parsovacích vzorců je pro další vyzkoušení nutné jejich opětovné načtení, což vyžaduje restart samotné služby Logstash. Nasazení ostatních částí centrálního logování je v kontrastu s tímto pouhou otázkou instalace a jejich následného nastavení.
31
Obrázek 13: Výsledná podoba logu v Kibaně
Po propojení s Kibanou je v těchto datech možné vyhledávat pomocí webového rozhraní, což práci velmi usnadňuje. Pomocí ikonky lupy je například možné jedním kliknutím ihned filtrovat zobrazené výsledky.
4.4.3 Notifikace Na kritické události lze reagovat již při parsování a zasílat notifikaci např. e-mailem. Toho je využíváno v případě parsování logů aplikačních serverů, kde chceme být upozorněni, pokud se ve zprávě vyskytne HTTP status větší než 499, který ukazuje na závažný problém. Ve filtrech programu Logstash je možné použít funkci e-mail, která slouží právě pro odeslání e-mailu na zadanou adresu a se zadaným tělem. Pokud se ale problém vyskytuje ve více logových zprávách, bude funkce reagovat na každou z nich a systém bude zahlcen obrovským množstvím varování. Z tohoto důvodu je potřeba mít možnost 32
omezení počtu těchto upozornění. Logstash naštěstí disponuje funkcí throttle, která dovoluje označit logové zprávy, ale pouze v omezeném počtu za určité časové období. Při nastavení varování jako reakci právě na toto označení je tento problém vyřešen. Pomocí následujícího kódu jsou všechny zprávy s HTTP statusem větším než 499 označeny tagem “throttled”. Parametry before_count a after_count v tomto případě stanovují, že takto budou označeny všechny zprávy kromě první, a to za dobu stanovenou parametrem period, uvedenou v sekundách. filter { if [status] and 499 < [status] { throttle { before_count => 1 after_count => 1 period => 3600 key => "%{http_host}" add_tag => "throttled" } } } output { if [type] == "vspjproxy_access" { if "throttled" not in [tags] { if [http][status] > 499 { email { to => "
[email protected]" from => "
[email protected]" subject => "HTTP status code greater then 500" body => "Alert on %{host} at %{@timestamp}:\n\n%{[http][vhost]}%{[http][request_page]}\nStatus code: %{[http][status]}" } }
Ačkoliv by bylo srozumitelnější, kdyby byla označena pouze první zpráva, kvůli chybě v Ruby to možné není. Z tohoto důvodu je pak v části výstupu znovu podmínka pro HTTP status. Dále je nastavena cílová adresa, odkud e-mail pochází, předmět a samotné tělo zprávy, kde využíváme proměnných této logové zprávy, díky kterým e-mail předává velice konkrétní informace.
4.4.4 Sanitize MAC I MAC adresy se mohou v logových zprávách vyskytovat v mnoha různých formátech. Například mohou být odděleny dvojtečkou či pomlčkou, nebo obsahovat velká nebo malá písmena. Pokoušet se o jejich převedení na jednotný formát by pouze s nástroji, které 33
Logstash po instalaci nabízí, bylo velice pracné. Ačkoliv rozpoznání MAC adres pomocí filtru grok nečiní žádný problém, samotná změna jejich konečné podoby pomocí filtru vyžaduje nahrazování jednotlivých znaků a podmínky by musely být pro každý typ adresy vytvořeny zvlášť. Proto jsme použili filtr sanitize_mac.rb nalezený na internetu, který někdo vytvořil právě za tímto účelem. Po stažení ho jednoduše vložíme do složky s konfiguračními soubory pro parsování. Poté v části filtrů nastavíme, na jaké pole dat se má aplikovat, zvolíme separátor a zda použít velká či malá písmena. Ukázka použití: if [type] == "firewall_linux" { sanitize_mac { match => { "[firewall][source_mac]" => "[firewall][source_mac]" } match => { "[firewall][destination_mac]" => "[firewall][destination_mac]" } separator => "-" fixcase => "upper" } }
15:AB:69:XX:XX:XX Příklad MAC adresy v různých formátech 15-ab-69-XX-XX-XX
15-AB-69-XX-XX-XX Adresa normalizovaná pomocí filtru sanitize_mac.rb
Obrázek 14: Sjednocení MAC adres na společný formát
4.4.5 GeoIP GeoIP je filtr, který přidává informace o geografické lokaci IP adres na základě dat z databáze Maxmind. Před jeho použitím se vyplatí zkontrolovat, zda není na stránkách http://dev.maxmind.com/geoip/legacy/geolite/ k dispozici aktuálnější databáze, než jakou po instalaci obsahuje Logstash. Pro použití ve filtru pouze vybereme pole dat obsahující IP adresu, o které se chceme informace dozvědět. [27]
34
Obrázek 15: Příklad využití GeoIP dat v Kibaně
4.4.6 Odstranění původní zprávy Po úspěšném rozparsování zprávy jsou všechny důležité hodnoty spárované s příslušnými poli. V takovou chvíli už původní logová zpráva ztrácí svojí hodnotu a může být odstraněna, čímž šetříme místo na disku. Pokud by parsování nebylo provedeno, ať už z důvodu špatného nastavení filtrů či jiné chyby, Logstash automaticky zprávu označí tagem _grokparsefailure. Proto v našem filtru máme podmínku, že pokud toto označení není nalezeno, pole s původní zprávou bude smazáno. Díky tomu bude při výskytu chyby původní zpráva ponechána a následně se z ní můžeme poučit. filter { ... if "_grokparsefailure" not in [tags] { mutate { remove_field => [ "message" ] } } }
4.4.7 Vnořené pole Vnořená pole dělají orientaci v rozparsovaných hodnotách mnohem přehlednější díky jejich sdružení pod názvy polí se společnou tématikou. Ačkoliv nástroje ELK Stacku dokáží s vnořenými poli pracovat, bohužel je není možné vytvořit přímo pomocí groku při parsování. Filtr mutate však nabízí funkci rename, která umožňuje libovolné pole
35
přejmenovat, a to i na pole vnořené. Následuje příklad užití tohoto filtru pro vytvoření vnořených polí spadajících pod HTTP. mutate { rename => [ "http_host", "[http][vhost]" ] rename => [ "http_referer", "[http][referer]" ] rename => [ "http_user_agent", "[http][user_agent]" ] rename => [ "http_version", "[http][version]" ] rename => [ "remote_user", "[http][remote_user]" ] rename => [ "request_page", "[http][request_page]" ] rename => [ "request_time", "[http][request_time]" ] rename => [ "method", "[http][method]" ] rename => [ "status", "[http][status]" ] rename => [ "mime_type", "[http][mime_type]" ] rename => [ "body_bytes_sent", "[http][body_bytes_sent]" ] rename => [ "piped", "[http][piped]" ] }
4.4.8 Parsování CSV souborů Při parsování logů se můžeme setkat se strukturou CSV (Comma-Separated values). V tomto formátu ukládají logy i některé často používané služby, například postfix, jak je vidět v následující krátké ukázce. 2016-04-01T11:56:40.000+02:00 Milhouse postfix/smtp[48967]: E592B47BC8: to=
, relay=vspj-mail-onmicrosoftcom.mail.protection.outlook.com[213.199.154.170]:25, delay=21, delays=0.26/0.45/0.5/19, dsn=2.6.0, status=sent (250 2.6.0 <[email protected]> [InternalId=112283330026098, Hostname=DB4PR02MB062.eurprd02.prod.outlook.com] 1275704 bytes in 0.244, 5102.196 KB/sec Queued mail for delivery)
Na první pohled se může zdát, že je tato logová zpráva dlouhá a nepřehledná. Jedná se ale v podstatě o tabulku, kde jsou její jednotlivé hodnoty oddělené čárkou. Ačkoliv by samozřejmě šlo takový druh logu parsovat pomocí groku, Logstash nabízí mnohem vhodnější řešení, jímž je přímo csv filtr. V případě postfix logu nastavíme jména sloupců a pokud na příslušném místě něco je, filtr vytvoří pole s odpovídajícím názvem a danou hodnotu do něj přiřadí. Následuje ukázka parsování postfix logu pomocí csv filtru. csv { columns => ['logdate', 'client_ip', 'client_hostname',
'server_ip', 'server_hostname',
'source_context', 'connector_id', 'source', 'event_id', 'internal_me ssage_id', 'message_id', 'network_message_id', 'recipient_address', 'recipient_status', 'total_bytes', 'recipient_count', 'related_recipient_address', 'reference', 'mes sage_subject', 'sender_address', 'return_path', 'message_info', 'directionality', 'tenant_id', 'original_client_ip', 'original_server_ip', 'custom_data'] }
36
4.4.9 Typová konverze Občas může být nutné ve filtrech změnit nebo blíže specifikovat typ hodnoty některého pole. Bez toho by totiž nebylo možné používat různé argumenty při vyhledávání, například hledání číselné hodnoty v určitém rozmezí, či orientace v IP adresách. Pokud pracujeme s CSV filtrem, není vůbec možné hodnotám přiřadit implicitní typ, což znamená, že s nimi bude pracováno jako s obyčejným textem. Pro řešení obou situací se dá použít funkce convert filtru mutate, která dokáže převést typ pole na námi specifikovaný nový typ. V případě parsování pomocí CSV ho můžeme stejným způsobem použít vlastně k samotné definici, jak ukazuje následující příklad. mutate { convert => [ "total_bytes", "integer" ] convert => [ "recipient_count", "integer" ] }
4.4.10 Rozdělování polí Logstash umožňuje ukládání více hodnot v jediném poli. V situaci, jakou je například parsování logu pomocí CSV filtru, není možné dopředu vědět, kolik konečných hodnot bude logová zpráva obsahovat. Řešením je obsažení většího bloku této zprávy do jediného pole a jeho pozdější rozdělení na více hodnot pomocí filtru split. Následuje ukázka rozdělení polí podle zadaného znaku, v tomto případě je jím středník. mutate { split => ["recipient_address", ";"] split => [ "source_context", ";" ] split => [ "custom_data", ";" ] }
4.4.11 Zahazování zpráv Některé části logu mohou být neužitečné, či pouze informovat o vlastnostech nebo struktuře logu. Takový typ zprávy se obvykle zahodí pomocí funkce drop. Logy Exchange začínají vždy takto: #Software: Microsoft Exchange Server #Version: 15.00.0913.007 #Log-type: Message Tracking Log #Date: 2015-02-16T00:01:21.226Z #Fields: date-time,client-ip,client-hostname,server-ip,server-hostname,sourcecontext,connector-id,source,event-id,internal-message-id,message-id,network-message-
37
id,recipient-address,recipient-status,total-bytes,recipient-count,related-recipientaddress,reference,message-subject,sender-address,return-path,messageinfo,directionality,tenant-id,original-client-ip,original-server-ip,custom-data
Tyto zprávy jsou pouze informativní a v konečné zprávě nemají co dělat. Filtr proto nastavíme tak, že dojde k zahození zprávy, pokud její řetězec začíná některou z těchto počátečních slov. if ([message] =~ "#Software:") { drop { } } else if ([message] =~ "#Version:") { drop { } } else if ([message] =~ "#Log-type:") { drop { } } else if ([message] =~ "#Date:") { drop { } } else if ([message] =~ "#Fields:") {drop { } } else { csv { ...
4.4.12 Přidání dalších polí V některých situacích může být potřeba přidat k logové zprávě další informace. Následuje příklad použití funkce add_field filtru mutate pro přidání nového textového pole upřesňujícího hodnotu, která se v původním logu vyskytuje pouze číselně. Na podobném principu vlastně funguje i plugin GeoIP, který také zprávě přidává nová pole. if [Radius][Acct-Status-Type] == "1" { mutate { add_field => { "[Radius][Acct-StatusType-Text]" => "Start" } } } if [Radius][Acct-Status-Type] == "2" { mutate { add_field => { "[Radius][Acct-StatusType-Text]" => "Stop" } } } if [Radius][Acct-Status-Type] == "3" { mutate { add_field => { "[Radius][Acct-StatusType-Text]" => "Alive" } } } if [Radius][Acct-Status-Type] == "7" { mutate { add_field => { "[Radius][Acct-StatusType-Text]" => "Accounting-On" } } } if [Radius][Acct-Status-Type] == "8" { mutate { add_field => { "[Radius][Acct-StatusType-Text]" => "Accounting-Off" } } }
4.4.13 Víceřádkový log V případě některých logů se může jediná logová zpráva rozprostírat na více řádcích. Typickým příkladem takových logů je Apache Tomcat. Apr 2, 2015 2:42:59 PM org.apache.catalina.session.StandardManager doLoad SEVERE: IOException while loading persisted sessions: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: cz.effectiva.carmen.bo.nulls.Ano nymousReader java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: cz.effectiva.carmen.bo.nulls.AnonymousReader at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1353)
38
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1989) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1914)
Při přijmutí takového logu Logstashem by řádky byly interpretovány jako jednotlivé zprávy, proto je nutné zprávy nejprve sjednotit. Řešením je Multiline filter. Pro jeho využití je nutné specifikovat řetězec, který bude používán pro rozpoznání zprávy. Obvykle záznam z logu začíná časovou značkou, čemuž je tak i v případě Apache Tomcat logu. Jeho časová značka je v groku specifikovaná následovně: CATALINA_DATESTAMP %{MONTH} %{MONTHDAY}, 20%{YEAR} %{HOUR}:?%{MINUTE}(?::?%{SECOND}) (?:AM|PM)
Samotný filtr pro sjednocení vypadá takto. Pattern indikuje, jaký řetězec ve zprávě hledat. Direktiva negate s hodnotou true pak říká, že ke zprávě se vzorcem, který jsme specifikovali, má přiřadit ostatní zprávy, ve kterých nebyl nalezen. Direktiva what určuje, kam se neidentifikované zprávy mají připojit, což je v případě hodnoty previous nejbližší předchozí zpráva, ve které byl řetězec nalezen. multiline { pattern => "^%{CATALINA_DATESTAMP} " negate => true what => previous }
4.4.14 Ruby split logmessage V některých situacích jsou zprávy z jednoho zdroje natolik odlišné, že aplikování groku pro získání všech informací není prakticky použitelné. V prostředí VŠPJ jsou to například zprávy Nginx errorlogu. 2015/04/08 08:45:28 [warn] 6924#0: *56886 an upstream response is buffered to a temporary file //var/lib/nginx/tmp/proxy/1/80/0000000801 while reading upstream, client: 192.168.XXX.XXX, server: helpdesk.vspj.cz, request: "GET /NoAuth/RichText/ckeditor.js HTTP/1.1", upstream: "http://192.168.XXX.XXX:80/NoAuth/RichText/ckeditor.js", host: "helpdesk.vspj.cz", referrer: https://helpdesk.vspj.cz/ 2015/04/08 10:25:05 [error] 16731#0: *358 limiting requests, excess: 15.226 by zone "one", client: 46.135.XXX.XXX, server: is.vspj.cz, request: "GET /student/rozvrh/mujrozvrh HTTP/1.1", host: "is.vspj.cz" 2015/04/08 10:25:20 [error] 16734#0: *197 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.XXX.XXX, server: rozvrh.nodejs.vspj.cz, request: "GET /socket.io/?EIO=3&transport=websocket&sid=6NZy5tStvQTJcej1AAD6 HTTP/1.1", upstream:
39
"http://192.168.XXX.XXX:3002/socket.io/?EIO=3&transport=websocket&sid=6NZy5tStvQTJcej1AA D6", host: "rozvrh.nodejs.vspj.cz"
Za časovou známkou je v hranatých závorkách uvedena závažnost zprávy. V případě upozornění warn nebo chyby error jsou pro nás informace v tomto textu zásadní a jako jeden celek by nebyly dost informativní. Jak je ale vidět v ukázce, různé zprávy jsou zcela odlišné a mají navíc i rozdílnou délku. Aplikovat grokový vzorec v situaci, kdy dopředu nevíme, jak bude zpráva dlouhá, ani co přesně bude obsahovat, by bylo velice složité, jelikož na jeden společný vzorec se nelze spolehnout. Ačkoliv je groku možné nabídnout více možností parsování, ze kterých si vybere tu správnou, v případech, jako je tento, by bylo vytvoření parsovacího vzorce pro každou situaci nemožné kvůli obrovskému množství variant zpráv. NGINX_DATESTAMP %{YEAR}/%{MONTHNUM}/%{MONTHDAY} %{HOUR}:%{MINUTE}:%{SECOND} NGINX_ERRORLOG %{NGINX_DATESTAMP:log_timestamp} \[%{WORD:severity}\] %{NUMBER:pid:int}#%{NUMBER}: %{GREEDYDATA:logmessage}
Zpráva je pomocí groku rozdělena na čas, závažnost, id procesu a pak celý zbytek zprávy jako logmessage. Události v logmessage jsou oddělené čárkou a mezi názvem a hodnotou je dvojtečka, čehož je možné využít pro rozdělení této zprávy. Protože však předem nevíme, na kolik polí bude nutné logmessage rozdělit, použijeme následující kód v Ruby. if [severity] == "warn" or [severity] == "error" { ruby { code => " fieldArray = event['logmessage'].split(', ') for field in fieldArray field = field.delete '\"' result = field.split(': ') event['[nginx_errorlog][' + result[0] + ']'] = result[1] end " } mutate { remove_field => [ "logmessage" ] } }
V případě, že jde o chybovou hlášku nebo varování, zprávu rozdělíme podle čárek pomocí metody split. Ruby totiž dovoluje použít cyklus for field, kterému jednotlivé hodnoty předáme. Ty jsou následně ještě jednou rozděleny podle dvojtečky a jejich první část se stane názvem pole, druhá pak jeho hodnotou.
40
4.5 Elasticsearch Elasticsearch je vysoce škálovatelný open-source full-textový vyhledávací a analytický nástroj. Dovoluje ukládat, prohledávat a analyzovat velké objemy dat rychle a téměř v reálném čase. Obvykle je používán jako základní technologie, na které běží aplikace se složitými vyhledávacími funkcemi a požadavky. [28] Elasticsearch vychází z Apache Lucene a je napsán v jazyce Java. Jeho škálovatelnost je umožněná díky podpoře clusterování. Pro vznik clusteru stačí serverům na stejné síti nastavit identické jméno clusteru. To umožní efektivní rozdělení zátěže mezi jednotlivé stroje v rámci clusteru. Samotný běh Elasticsearch spotřebovává poměrně velké množství výkonu procesoru i RAM, nicméně při dostatečně silném hardware je Elasticsearch schopný zpracovávat i petabajty dat. Navíc se jedná o multiplatformní nástroj, lze ho nasadit na OS Linux i Windows. Pro interakci s daty je využíváno RESTful API, které funguje pomocí HTTP metod. Obvykle je specifikován typ akce a na která data ji provést. Na stejném principu funguje i Kibana, kde má ovšem uživatel situaci zjednodušenou díky GUI. Data lze nicméně získávat z Elasticsearch i tímto způsobem. Následuje příklad použití REST API k získání všech záznamů se specifickou IP adresou žadatele. curl -XGET 'http://localhost:9200/_search?q=remote_addr:192.168.XXX.XXX'
Složitější vyhledávání podle konkrétní domény a adresy žadatele může vypadat následovně: curl -XGET 'http://localhost:9200/_all/_search?pretty=1' -d '{ "query": { "bool": { "must":
{ "match": { "vhost": "nav.vspj.cz" }},
"must": { "match": { "remote_addr" : "194.228.13.123" }} } } }'
41
Dále následuje ukázka použití REST API ke smazání logů. Takto mohou být smazány všechny logy, nebo pouze logové zprávy z konkrétního data. curl -XDELETE 'http://localhost:9200/logstash*' curl -XDELETE 'http://localhost:9200/logstash-2016.04.17'
Společnost Elasticsearch nabízí také placenou podporu a několik placených doplňků:
Marvel – nabízí přehled stavu jednoho či více Elasticsearch clusterů
Shield – ochrana dat pomocí šifrování komunikace, přihlašování, filtrování podle IP adres, sledování přístupů, apod.
Watcher – produkt, upozorňující na výkyvy v datech
Graph – analýza a vizualizace vztahů mezi daty
Elastic Cloud – zabezpečený cluster běžící na Amazon Web Services s nejnovější verzí Elasticsearch a Kibany
4.6 Kibana Kibana je open-source nástroj pro analýzu a vizualizaci, navržený pro spolupráci s Elasticsearch. Dá se využít pro vyhledávání, zobrazení a interakci s daty uloženými v Elasticsearch. S jeho pomocí je možné snadno vykonávat pokročilou analýzu dat a jejich vizualizaci v široké škále grafů, tabulek a map. [29]
4.6.1 Tvorba dashboardu Dashboard je souhrn důležitých metrik, které na první pohled ukazují charakteristiku provozu. Koncovému uživateli tedy přes grafické rozhraní poskytuje snadnou orientaci a okamžitý přehled. Pro vznik dashboardu je nejprve nutné vytvořit dílčí části, ze kterých je nakonec poskládán. Těmi mohou být různé grafy a vizualizační prvky. Aby byl dashboard pro správce užitečný, je potřeba ho poskládat z informací, které jsou podstatné. Proto se obvykle pro každý typ logu tvoří jeho vlastní dashboard, který se týkají jeho důležitých vlastností. Konfigurace dashboardů jsou ukládány do Elasticsearch.
42
Obrázek 16: Příklad dashboardu v Kibaně 4
Na této ukázce je vidět dashboard vytvořený pro accesslog VŠPJ. V časové ose nahoře se nachází počet logových zpráv, v tomto případě vlastně počet obdržených požadavků za daný čas. Pod tím jsou umístěny dvě podobné menší časové osy, kde jsou ale data pomocí filtru omezena pouze na zprávy s hodnotou HTTP statusu 5XX vlevo a hodnotou 4XX vpravo. Barevná osa vlevo o řádek níže ukazuje počet přenesených dat. Koláčový graf zobrazuje, na které stránky VŠPJ je přistupováno (vnitřní kruh) a z jakých prohlížečů (vnější kruh). Číselné hodnoty jsou percentily (50, 75, 95 a 99), které vyjadřují, do jaké doby bylo dané procento požadavků vyřízeno.
43
5 Testování Logy byly zasílány na vývojový server, kde byly společně nasazeny nástroje ELK Stacku – tedy Logstash, Elasticsearch a Kibana. Kromě samotného vyzkoušení jejich instalace a spolupráce bylo hlavním účelem testování funkcí a parsování v programu Logstash. Po otestování byla použitá pravidla a nastavení nasazena do produkčního prostředí. Při tvorbě pravidel byl velmi užitečným nástrojem grok debugger, který slouží pro tvorbu a především testování správnosti parsovacích pravidel pro Logstash. K dispozici je online na internetové adrese https://grokdebug.herokuapp.com/. Tato aplikace se ukázala jako velice užitečná zejména při parsování složitých logů, jelikož kontrola jejich správnosti a případné pokusy o nalezení chyby v produkčním prostředí vyžaduje jejich zpracování všemi nástroji. To často vynucuje restart služby Logstash a smazání údajů o předchozím zpracování tohoto logu. Na internetových stránkách je navíc k dispozici bohatá škála předdefinovaných logů, díky kterým se může i naprostý začátečník rychle zorientovat v této problematice.
44
6 Závěr Systém centrálního logování byl aplikován v prostředí VŠPJ a je využíván jak programátorským týmem, tak oddělením správy sítě. Výsledek této práce vyřešil složité přistupování k logům jednotlivých serverů. Tato práce potvrdila že systém centrálního logování řeší všechny problémy s vytěžovaním informací z logů. V praxi je možné ELK Stack použít i pro vytvoření pokročilejších systémů, jakým je např. SIEM (Security Information and Event Management). ELK Stack se tedy prokázal jako velice dobrá platforma pro realizaci centrálního logování. To dokazuje i skutečnost, že řada technologických firem nabízí produkty postavené právě nad ELK Stack.
45
Seznam použité literatury [1]
Filebeat Reference [1.0.1]. Elastic · Revealing Insights from Data (Formerly Elasticsearch)
[online].
Elasticsearch,
2016
[cit.
2016-01-19].
Dostupné z: https://www.elastic.co/guide/en/beats/filebeat/current/index.html [2]
The syslog-ng Open Source Edition 3.7 Administrator Guide. Contextual Security Intelligence™
[online].
Dostupné
z:
https://www.balabit.com/sites/
default/files/documents/syslog-ng-ose-latest-guides/en/syslog-ng-ose-guideadmin/html-single/index.html [3]
Welcome to Rsyslog - rsyslog 8.15.0 documentation. Rsyslog [online]. [cit. 201601-19]. Dostupné z: http://www.rsyslog.com/doc/master/index.html
[4]
NXLOG Community Edition Reference Manual for v2.9.1504 [online]. nxlog.co, 2015 [cit. 2016-01-19]. Dostupné z: https://nxlog.co/docs/nxlog-ce/nxlogreference-manual.html
[5]
RFC 5424 - The Syslog Protocol. IETF Tools [online]. [cit. 2016-01-19]. Dostupné z: https://tools.ietf.org/html/rfc5424
[6]
Quickstart Guide | Fluentd. Fluentd | Open Source Data Collector | Unified Logging Layer
[online].
Fluentd
Project,
2010
[cit.
2016-01-19].
Dostupné z: http://docs.fluentd.org/articles/quickstart [7]
Reference [2.1]. Elastic · Revealing Insights from Data (Formerly Elasticsearch) [online].
Elasticsearch,
2016
[cit.
2016-01-19].
Dostupné
z:
https://www.elastic.co/guide/en/logstash/2.1/index.html [8]
Welcome to the Graylog documentation - Graylog 2.0.0 documentation. Graylog | Open Source Log Management [online]. Graylog, 2015 [cit. 2016-01-19]. Dostupné z: http://docs.graylog.org/en/2.0/
[9]
Documentation - Splunk Knowledgebase. Operational Intelligence, Log Management, Application Management, Enterprise Security and Compliance | Splunk
[online].
Splunk,
©2005-2016
[cit.
2016-01-19].
Dostupné
z:
https://docs.splunk.com/Documentation
46
[10] Elasticsearch: The Definitive Guide [master]. Elastic · Revealing Insights from Data (Formerly Elasticsearch) [online]. Elasticsearch, 2016 [cit. 2016-01-19]. Dostupné z: https://www.elastic.co/guide/en/elasticsearch/guide/current/index.html [11] The MongoDB 3.2 Manual - MongoDB Manual 3.2. MongoDB for GIANT Ideas | MongoDB
[online].
MongoDB,
2016
[cit.
2016-01-19].
Dostupné
z:
https://docs.mongodb.org/manual/ [12] PostgreSQL: Documentation: 9.5: PostgreSQL 9.5.0 Documentation. PostgreSQL: The world's most advanced open source database [online]. The PostgreSQL Global Development
Group,
©1996-2016
[cit.
2016-01-19].
Dostupné
z:
http://www.postgresql.org/docs/9.5/static/index.html [13] Kibana User Guide [4.3]. Elastic · Revealing Insights from Data (Formerly Elasticsearch) [online]. Elasticsearch, 2016 [cit. 2016-01-19]. Dostupné z: https://www.elastic.co/guide/en/kibana/current/index.html [14] Octopussy_Documentation/00_Documentation.md
at
master
·
sebthebert/Octopussy_Documentation · GitHub. GitHub · Where software is built [online]. GitHub, 2016 [cit. 2016-01-19]. Dostupné z: https://github.com/ sebthebert/Octopussy_Documentation/blob/master/00_Documentation.md [15] Documentation · mcholste/elsa Wiki · GitHub. GitHub · Where software is built [online]. GitHub, 2016 [cit. 2016-01-19]. Dostupné z: https://github.com/ mcholste/elsa/wiki/Documentation [16] Business continuity planning. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2016, last modified on 16 March 2016 [cit.
2016-03-23].
Dostupné
z:
https://en.wikipedia.org/wiki/
Business_continuity_planning [17] Operational Intelligence, Log Management, Application Management, Enterprise Security and Compliance | Splunk. Operational Intelligence, Log Management, Application Management, Enterprise Security and Compliance | Splunk [online]. Splunk, ©2005-2016 [cit. 2016-05-08]. Dostupné z: http://www.splunk.com/
47
[18] Use Cases · ELK Stack Success Stories. Elastic · Revealing Insights from Data [online].
Elasticsearch,
2016
[cit.
2016-03-31].
Dostupné
z:
https://www.elastic.co/use-cases [19] RabbitMQ - Messaging that just works. RabbitMQ - Messaging that just works [online]. Pivotal Software, ©2007-2016 [cit. 2016-05-08]. Dostupné z: https://www.rabbitmq.com/ [20] Redis. Redis [online]. Redis Labs, 2016 [cit. 2016-05-08]. Dostupné z: http://redis.io/ [21] ØMQ - The Guide. Distributed Messaging - zeromq [online]. iMatix, 2014 [cit. 2016-04-27]. Dostupné z: http://zguide.zeromq.org/page:all [22] Apache Kafka. Apache Kafka [online]. The Apache Software Foundation, 2016 [cit. 2016-05-08]. Dostupné z: http://kafka.apache.org/ [23] RabbitMQ - AMQP 0-9-1 Model Explained. RabbitMQ - Messaging that just works [online]. Pivotal Software, ©2007-2016 [cit. 2016-05-08]. Dostupné z: https://www.rabbitmq.com/tutorials/amqp-concepts.html [24] Logstash Introduction. Elastic · Revealing Insights from Data (Formerly Elasticsearch) [online]. Elasticsearch, 2016 [cit. 2016-05-08]. Dostupné z: https://www.elastic.co/guide/en/logstash/current/introduction.html [25] Structure of a Config File. Elastic · Revealing Insights from Data (Formerly Elasticsearch) [online]. Elasticsearch, 2016 [cit. 2016-05-08]. Dostupné z: https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html [26] Grok. Elastic · Revealing Insights from Data (Formerly Elasticsearch) [online]. Elasticsearch, 2016 [cit. 2016-05-08]. Dostupné z: https://www.elastic.co/ guide/en/logstash/current/plugins-filters-grok.html [27] Geoip. Elastic · Revealing Insights from Data (Formerly Elasticsearch) [online]. Elasticsearch, 2016 [cit. 2016-05-08]. Dostupné z: https://www.elastic.co/ guide/en/logstash/current/plugins-filters-geoip.html
48
[28] Getting Started. Elastic · Revealing Insights from Data (Formerly Elasticsearch) [online]. Elasticsearch, 2016 [cit. 2016-05-08]. Dostupné z: https://www.elastic.co/ guide/en/elasticsearch/reference/current/getting-started.html [29] Introduction. Elastic · Revealing Insights from Data [online]. Elasticsearch, 2016 [cit.
2016-03-31].
Dostupné
z:
https://www.elastic.co/guide/en/kibana/
current/introduction.html
49
Seznam obrázků Obrázek 1: Servery s logy, které nikam neputují ............................................................ 10 Obrázek 2: Životní cyklus logu v centralizovaném systému .......................................... 11 Obrázek 3: Cesta logu v centralizovaném systému ........................................................ 12 Obrázek 4: Příklad TCP komunikace.............................................................................. 13 Obrázek 5: Příklad UDP komunikace ............................................................................. 13 Obrázek 6: Příklad normalizace časů .............................................................................. 15 Obrázek 7: Znázornění infrastruktury centrálního logování na VŠPJ ............................ 23 Obrázek 8: Příklad cesty zprávy v program RabbitMQ [23] .......................................... 24 Obrázek 9: Funkce Direct exchange [23] ....................................................................... 25 Obrázek 10: Funkce Fanout exchange [23] .................................................................... 25 Obrázek 11: RabbitMQ správa exchange ....................................................................... 26 Obrázek 12: RabbitMQ správa front ............................................................................... 27 Obrázek 13: Výsledná podoba logu v Kibaně ................................................................ 32 Obrázek 14: Sjednocení MAC adres na společný formát ............................................... 34 Obrázek 15: Příklad využití GeoIP dat v Kibaně ............................................................ 35 Obrázek 16: Příklad dashboardu v Kibaně 4 .................................................................. 43
50
Seznam tabulek Tabulka 1: Přehled transportních programů a jejich vlastností....................................... 15 Tabulka 2: Přehled programů vhodných pro zpracování logů ........................................ 16 Tabulka 3: Programy vhodné pro fázi ukládání logů ...................................................... 17 Tabulka 4: Přehled programů pro vizualizaci a vyhledávání .......................................... 18 Tabulka 5: Přehled možností archivace logů .................................................................. 19
51
Seznam zkratek VŠPJ - Vysoká škola polytechnická Jihlava TCP - Transmission Control Protocol UDP - User Datagram Protocol DTLS - Datagram Transport Layer Security SQL - Structured Query Language JSON - JavaScript Object Notation XML - Extensible Markup Language BCP - Business Continuity Planning HTTP - Hypertext Transfer Protocol CSV - Comma-Separated Values AMQP - Advanced Message Queuing Protocol DNS - Domain Name System ETL - Extract-Transform-Load SIEM - Security Information and Event Management
52
Přílohy Obsah přiloženého CD Na přiloženém CD se nachází zdrojový kód pro nastavení filtrů a parsování logů na serverech Logstash Dispatcher a Logstash Parser.
53
