Správa a analýza bezpečnostních logů

MASARYKOVA UNIVERZITA Fakulta informatiky

Správa a analýza bezpečnostních logů

Antonín Víteček

Brno, 2012 1

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

V Hustopečích dne 27. května 2012

…..................................................

Poděkování Děkuji mému vedoucímu RNDr. Václavu Lorencovi za vstřícnost, pomoc a neskonalou trpělivost, kterou jsem navzdory všem radám bohužel zklamal. Dále bych chtěl velice poděkovat svým blízkým za podporu a pochopení při psaní práce.

2

Shrnutí Práce shrnuje přehled základních znalostí a problematiky správy logů. Popisuje současný stav správy logů na Ústavu výpočetní techniky MU. Dále se zaměřuje na zkušební nasazení nástroje Splunk a jeho potencionálního nasazení do běžné praxe, případně nahrazení obdobným nástrojem. Klíčová slova správa logů, analýza logů, logovací server, syslog, SIEM, monitoring 3

Obsah 1. Úvod.....................................................................................................................................6 2. Logy......................................................................................................................................7 2.1 Co je to log.....................................................................................................................7 2.2 Formáty logů..................................................................................................................7 2.2.1 Syslog.....................................................................................................................7 2.2.2 Textové formáty.....................................................................................................9 2.2.2.1 Common Log Format...................................................................................10 2.2.2.2 W3C Extended Log Format.........................................................................10 2.2.2.3 XML – eXtensible Markup Language..........................................................11 2.2.2.4 CSV – Comma Separated Values.................................................................11 2.2.3 Binární logy..........................................................................................................11 2.2.4 SNMP...................................................................................................................12 2.3 Správa logů..................................................................................................................13 2.3.1 Logovací infrastruktura........................................................................................13 2.3.1.1 Zdroje (generátory) logů..............................................................................13 2.3.1.2 Logovací servery..........................................................................................14 2.3.1.3 Analyzátory logů..........................................................................................15 3. Správa logů na ÚVT...........................................................................................................17 3.1 Oddělení datových sítí - ODS......................................................................................18 3.2 Oddělení bezpečnosti datové sítě.................................................................................19 3.3 Oddělení vývoje systémových služeb..........................................................................20 3.4 Oddělení systémové správy.........................................................................................20 4. Nástroje pro analýzů logů...................................................................................................20 4.1 Splunk..........................................................................................................................20 4.1.1 Instalace...............................................................................................................21 4.1.2 Popis základního GUI..........................................................................................22 4.1.2.1 Horní navigační lišta....................................................................................23 4.1.2.2 Aplikace Search............................................................................................24 4.1.3 Vyhledávání..........................................................................................................27 4.1.4 Praktické nasazení Splunku................................................................................29 4.1.4.1 Možnosti načítání dat Splunku.....................................................................29 4.1.4.2 Zdroje logů v síti ODS.................................................................................31 4.1.4.3 Konfigurace Splunku pro vstup dat k indexaci ...........................................33 4.1.4.4 Konfigurace Rsyslogu..................................................................................33 4.1.4.5 Náhrada CiscoReportu.................................................................................36 4.1.4.5.1 Formát Cicsco logů...............................................................................36 4.1.4.5.2 Dashboard CiscoReport........................................................................37

4

7. Závěr...................................................................................................................................40 Použitá literatura:....................................................................................................................41

5

1. Úvod Správa logů by měla být v současnosti nedílnou částí při správě jakékoliv síťové, nebo počítačové infrastruktury. Přičemž by měla být stanovena pravidla pro pravidelnou revizi logů a analýzu získaných informací. Logů může být velké množství a správce by měl mít intuitivně ovladatelné nástroje, které mu umožní snadno a přehledně získávat z logů důležité údaje, monitorovat stav infrastruktury a automatizovat vykonávání činností v závislosti na výskytu událostí. Splnit uvedené podmínky však není příliš jednoduché. Oddělení datových sítí k tomuto účelu využívá nástroj CiscoReport, který je však třeba modernizovat. Cílem diplomové práce je nalézt, nebo vyvinout nástroj, který by splňoval uvedené podmínky a mohl původní řešení nahradit. Kapitola 2 – popisuje význam logů, formát a strukturu nejznámějších druhů a význam správy logů spolu s popisem jednotlivých částí logovací infrastruktury Kapitola 3 – mapuje současný stav správy logů na ÚVT z pohledu jednotlivých oddělení Kapitola 4 – se podrobně zabývá možnostmi nástroje Splunk a ostatními dostupnými nástroji Kapitola 5 – by měla obsahovat návrh vlastního řešení dané problematiky, pomocí freeware dostupných nástrojů Kapitola 6 – by měla obsahovat politiku pro správu logů pro Oddělení datových sítí Kapitola 7 – závěr a zhodnocení práce.

6

2. Logy 2.1 Co je to log Pojmem log se v počítačové terminologii rozumí soubor se záznamem jednotlivých událostí, které nastaly v monitorovaném systému. Každá událost je typicky zaznamenána právě jedním záznamem v logu a obsahuje důležité informace popisující vlastní událost. Například čas, původce, podrobnější popis události atp. Původně se logy využívaly spíše k odladění problémů, s postupem času a masivním rozvojem výpočetní techniky však získaly na důležitosti a jsou často zdrojem podstatných informací. [1] Logy obsahující informace týkající se počítačové bezpečnosti nazýváme bezpečnostní logy. Jsou to logy z antivirových programů, firewallů, systémů IDS/IPS (Intrusion Detection/Prevention System) atp. Speciální typ bezpečnostního logu, který např. eviduje změny oprávnění, nebo vlastníky souborů v operačním systému, se nazývá audit log. S pomocí tohoto typu logu jsme v případě potřeby, např. při řešení bezpečnostního incidentu, schopni prokázat konkrétnímu uživateli, konkrétní změnu v systému. Jeden ze základních problémů při správě logů je, jak rozumně uchovávat a zpracovávat stále se zvětšující objem logů, které jsme schopni poměrně snadno generovat a získávat.

2.2 Formáty logů Následuje popis nejběžnějších formátů logů.

2.2.1 Syslog Je jedním z nejznámějších a nejstarších formátů využívaném při logování vůbec. Původně byl vyvinut v 80. letech pro potřeby poštovního serveru Sendmail. Díky své jednoduchosti si získal oblibu a rozšířil se na celou řadu platforem a množství různorodých zařízení. I když nikde nebyla oficiálně definována jeho podoba, stal se pro logování de facto standardem. Kvůli absenci oficiální podoby však vznikaly i vzájemně nekompatibilní implementace. Roku 2001 byl vydán dokument RFC 3164, který popisoval status quo syslogu. [2] Následně byl v roce 2009 aktualizován dokumentem RFC 5424 [3], který ho rozšířil o nově potřebné vlastnosti. Původní verze protokolu používala pro přenos zpráv po síti nepotvrzovaný protokol UDP s cílovým portem 514 a maximální délka paketu byla stanovena na 1024 bytů. Vlastní tělo zpráv je kódováno v ASCII a dělí se na tři po sobě následující části: PRI, HEADER a MSG. První část se sestává z číselné hodnoty – priority – v rozmezí 0 až 191, uzavřené 7

mezi znak < a >. Tuto hodnotu získáme výpočtem: 8*facility₊severity Přičemž číselná hodnota facility popisuje příslušnost zprávy k určitému subsystému a číselná hodnota severity popisuje míru závažnosti. Přehled hodnot je uveden v tabulce č. 1 a tabulce č. 2. V první tabulce si můžeme všimnout zajímavosti u hodnot (9, 15) a (4, 10, 13, 14). Ačkoliv mají různá čísla, odpovídají přibližně stejnému subsystému. Tato nekonzistence vznikla nejednotností implementací v průběhu let. Hodnoty local0 až local7 tradičně používají síťová zařízení. Druhá část HEADER následuje bezprostředně po znaku > předchozí části PRI. Obsahuje datum, čas a mezerou oddělené pole hostname, za kterým následuje další mezera. V případě neznalosti hostname je použita IP adresa odesílatele. Časový údaj je uveden ve formátu: „Mmm dd hh:mm:ss“ Mmm je zkrácený anglický název měsíce (Jan, Feb, atd.), následuje mezerou oddělený den v měsíci a další mezerou oddělený údaj o aktuálním času ve 24 hodinovém formátu. Z formátu časového údaje lehce vidíme i dva nedostatky původní verze Syslogu. Neobsahuje žádný údaj o časové zóně a nejjemnější schopnost rozlišení času je pouze na celé sekundy. Číselná hodnota 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Slovní popis hodnoty kernel messages user-level messages mail systém systém daemons security/authorization messages messages generated internally by syslogd line printer subsystem network news subsystem UUCP subsystem clock daemon security/authorization messages FTP daemon NTP subsystem log audit log alert clock daemon local use 0 (local0) local use 1 (local1) local use 2 (local2) local use 3 (local3) local use 4 (local4) local use 5 (local5) local use 6 (local6) local use 7 (local7)

Tabulka č. 1: Facility [2]

8

Třetí část MSG, která následuje po druhé části a sahá až do konce paketu, se dále dělí na dvě pole. První pole TAG obvykle blíže identifikuje proces, který zprávu vygeneroval (např. jméno procesu). Maximální délka je 32 alfanumerických znaků. První nealfanumerický znak ukončuje toto pole a až do konce paketu pokračuje pole CONTENT, které nemá žádný pevně stanovený formát a obsahuje již samotný text zprávy. Číselná hodnota 0 1 2 3 4 5 6 7

Slovní popis hodnoty Emergency: system is unusable Alert: action must be taken immediately Critical: critical conditions Error: error conditions Warning: warning conditions Notice: normal but significant condition Informational: informational messages Debug: debug-level messages

Tabulka č. 2: Severity [2] Verze Syslogu podle novějšího RFC se snaží vycházet vstříc moderním požadavkům, zároveň se však snaží zachovat jednoduchost starší verze. Popis struktury zprávy se dle RFC mírně změnil, v podstatě však došlo jen k rozšíření či přidání několika málo polí. Přesný popis struktury lze dohledat přímo v RFC. [3] Nejdůležitější změny jsou tyto: •

přidání pole verze Syslogu v hlavičce

•

čas je uveden dle RFC 3339 [4] s možností uvedení časové zóny a rozlišení času až na mikrosekundy

•

v hostname je uvedeno celé doménové jméno

•

pro snadnější strojové zpracování byly přidány strukturovaná pole, tzv. sd-elements

•

pro část MSG je použita znaková sada Unicode kódována v UTF-8

•

minimální podporovaná délka paketu je 2048 bytů

•

jako transportní protokol je použito TCP

•

všechny implementace musí podporovat zabezpečení protokolem TLS

2.2.2 Textové formáty Textové logy lze uchovávat v celé škále různých formátů. Záleží na uvážení vývojářů, zda použijí již standardizovaný formát, nebo si vytvoří svůj vlastní. Standardizované formáty mají výhodu v možnosti použít na zpracování již existující nástroje a zajistit tak interoperabilitu.

9

2.2.2.1 Common Log Format

Je standardizovaný textový formát, známý především díky svému použití u webových serverů [5], kterému rozumí i mnoho nástrojů pro analýzu logů. Každý požadavek je zaznamenán na jednom řádku a je složen z následujících sedmi polí: •

host – jméno nebo IP adresa adresa klienta

•

RFC 931 identifikátor klienta [6]

•

username – uživatelské jméno použité při autentizaci

•

date:time timezone – datum, čas a informace o časové zóně

•

request – vlastní tělo požadavku, které je složeno z informací o použité metodě, požadovaném zdroji a verzi HTTP protokolu

•

statuscode – číselný HTTP stavový kód vrácený klientovi

•

bytes – velikost odpovědi v bytech

Pole bez definované hodnoty jsou nahrazena pomlčkou. Pokud vyjmenovaná pole rozšíříme ještě o pole referer (informuje o zdroji odkud je klient odkazován) a user-agent (identifikace použitého prohlížeče), získáme tzv. Combined Log Format. [7] 2.2.2.2 W3C Extended Log Format

Je výchozí formát pro logování webového serveru IIS. Podobně jako u CLF (Common Log Format), každý požadavek je zaznamenán na jednom řádku. Jednotlivá pole jsou od sebe oddělena mezerou a pole bez definované hodnoty jsou nahrazena pomlčkou. Vlastní struktura a pořadí polí na řádku není pevně stanovena standardem. [8] Každý soubor v ELF (Extended Log Format) obsahuje svou vlastní definici struktury polí a to pomocí speciálních řádků, tzv. direktiv. Direktiva je řádek začínající znakem mřížka a standard definuje následující: •

Version – verze použitého ELF standardu

•

Fields – seznam jednotlivých polí požadavku

•

Software – jméno programu, který vygeneroval log

•

Start-date – datum a čas počátku logu

•

End-date – datum a čas konce logu

•

Date – datum a čas přidání záznamu

•

Remark - poznámka

10

Názvy polí lze dále upřesnit pomocí prefixů. Například pole ip (IP adresa) lze upřesnit na s-ip (server IP) a c-ip (IP klienta). 2.2.2.3 XML – eXtensible Markup Language

Je značkovací jazyk [9], podobně jako HTML, kdy jednotlivá pole jsou uzavřena párovými značkami, tzv. tagy. Samy značky dále mohou obsahovat ještě atributy. Stejně jako v předchozím případě, vnitřní struktura a pořadí polí v souboru není pevně stanovena. Na začátku souboru je ale uveden odkaz na soubor s popisem schéma. V tomto souboru je popsána struktura, pořadí, datové typy a četnost jednotlivých polí, za využití některého jazyka z rodiny jazyků na popis schéma. Např. XML Schema, Relax NG, Schematron, DTD. Aby byl soubor platným XML dokumentem – označovaným jako validní – musí splňovat obecná pravidla pro XML a jeho struktura značek a atributů musí odpovídat pravidlům popsaným v odkazovanému schéma. Formát XML je hojně využíván pro výměnu dat mezi systémy. Umožňuje jednoduše pomocí pravidel transformovat zdrojový dokument do jiných formátů. Jako znaková sada se implicitně používá Unicode. Soubory jsou přitom čitelné jak pro člověka, tak i dobře počítačově zpracovatelné pomocí běžně dostupných nástrojů. Nevýhodou může být velikost přenášených dat. 2.2.2.4 CSV – Comma Separated Values

Je jednoduchý textový formát, nejvíce využíván pro reprezentaci tabulkových dat, případně pro přenos těchto dat mezi různými systémy. Na řádku jsou jednotlivá pole oddělena čárkou, odtud tedy získal svůj název. [10] Využití čárky s sebou přináší však i komplikace, protože v některých jazycích, včetně češtiny, se jako oddělovač desetinných míst používá právě desetinná čárka. V těchto případech lze pak použít jako oddělovač polí znak tabelátor, středník, nebo i mezeru. Ani tyto další oddělovací znaky nám však nemusí zaručit, že nenastane žádný konflikt s obsahem polí. Je potřeba uvážit obsah polí a podle toho případně na jejich ohraničení použít uvozovky. Bývá zvykem, že první řádek souboru obsahuje pojmenování jednotlivých polí nebo sloupců. I když je tento formát standardizován v RFC, ne vždy je ho možné dodržet kvůli výše zmíněným problémům. Záleží na uživateli, aby vhodně uvážil a nastavil pravidla pro import a export dokumentu, aby byl korektně zpracován.

2.2.3 Binární logy Nachází své uplatnění v situacích, kdy jsme omezeni přenosovou kapacitou sítě, nebo úložnou kapacitou disků. Textová data totiž mohou být velmi efektivně zakódována do binární podoby a zmenšit tak několikanásobně svou velikost. Komprimace je jedna z forem 11

kódování. Nevýhodou je, že na zpracování každého typ binárních logů potřebujeme specializovaný nástroj, přímo určený pro konkrétní typ. Databáze MySQL používá binární logy pro záznam všech událostí které mění databázi a to včetně obsahu změn. Tyto logy lze posléze použít buď pro obnovu obsahu databáze ze zálohy při výpadku, nebo pro její replikaci. [11]

2.2.4 SNMP Simple Network Management Protocol je standardizovaný, široce používaný protokol pro monitorování a správu zařízení přes síť. [12] Funguje na principu klient/server. Na straně monitorovaného/spravovaného zařízení běží SNMP agent ve funkci serveru, který vyřizuje požadavky přijaté od SNMP správců (klientů). Standard definuje i speciální případ, kdy sám agent iniciuje odeslání zprávy klientům. Tento typ zprávy se nazývá SNMP trap a je odeslán v případě, kdy agent detekuje výjimečnou situaci o které by měl být správce informován, například výpadek přívodního napájení u UPS. Vlastní identifikace všech hodnot (objektů), které chceme od zařízení (agenta) získat, nebo které chceme změnit je jednoznačně určena číslem OID (Object IDentifier). OID 1.3.6.1.2.1.1.3 například identifikuje uptime zařízení. [13] Uvnitř SNMP paketů se nepřenáší slovní pojmenování objektů, ale pouze tyto čísla OID. Identifikátory jsou organizovány do stromu a tato stromová struktura, včetně významu, typu a textového popisu jednotlivých OID je popisována v souborech MIB (Management Information Base).

Obrázek č. 1: Ukázková struktura OID [20] Protokol existuje ve třech verzích, přičemž verze 1 a 2c používají jako autentizaci nešifrované textové heslo – komunitu. Verze 3 přidává podporu šifrování pro zajištění integrity, autentizace a utajení. Jako transportní protokol je využito UDP.

12

2.3 Správa logů Pro správu logů je zažité i anglické pojmenování log management (LM), soubor pravidel a postupů práce s logy. Jejich získávání, zpracování, ukládání, prohledávání, analýza atd. Potřeba správy logů je logickým vyústěním stále se zvyšující potřeby dohledatelnosti a schopnosti monitorovat bezchybný chod systémů v organizacích. Tato potřeba může vznikat nejenom na základě interních potřeb vlastních organizací, ale může být také vyžadována externě. Organizace zpracovávající data platebních karet by měli splňovat standard PCI DSS (Payment Card Industry Data Security Standard). [14] Části tohoto standardu přímo vyžadují zavedení správy logů a pravidelné kontroly logů. Dodržování standardu je kontrolováno externím auditorem a v případě nesplnění hrozí organizaci pokuty, nebo i přerušení spolupráce s ostatními organizacemi. Správa logů může být také vyžadována zákonnými normami, viz obávaný zákon data retention. [17] Jedním z důležitých bodů správy logů je i pravidelná kontrola správného chodu celého systému.

2.3.1 Logovací infrastruktura Sestává se v podstatě ze všeho, co se nějakým způsobem týká logů. Ať už jejich generováním, přenášením, ukládáním atd. Lze ji rozdělit na několik samostatných částí, které budou dále popsány. Rozdělení na jednotlivé části umožňuje jednodušší nasazení v praxi, snadnější správu jednotlivých částí a kontrolu jejich správného chodu. Zlepšuje také přehlednost celého logovacího systému a usnadňuje administrátorům odhalování a odlaďování případných chyb. Logická topologie infrastruktury nemusí být pouze jedna jediná. Může jich být několik a odpovídat vnitřnímu členění organizace. 2.3.1.1 Zdroje (generátory) logů

Je jimi cokoliv, co dokáže nějakým způsobem generovat logy. Mohou to být například síťová zařízení jako jsou switche, routery, firewally, systémy IDS/IPS. Hardwarová zařízení, servery, případně softwarové aplikace. Většina zdrojů je schopna logy odesílat na logovací server nativně, například pomocí protokolu Syslog. Takový režim provozu se nazývá agent-less, bez agenta. Pokud však zdroj z nějakého důvodu není odesílání logů schopný (vývojáři s touto možností nepočítali, vyžadujeme specifický způsob přenosu logů), přenos logů zajišťuje agent. Jedná se o aplikaci, která buď běží přímo na zdroji a aktivně přeposílá logy, nebo může běžet jinde a aktivním dotazováním (polling) získává ze zdroje požadované logy. Protože agenti běží přímo na hostitelských strojích, jsou platformově závislí a v případě heterogenního prostředí mohou nastat komplikace s dostupností agentů pro danou platformu. Další nevýhodou je, že při svém běhu zatěžují hostitelský systém. 13

NTP Pro přesné zpracování a analýzu logů je téměř nezbytné, aby všechny zdroje logů měli správně synchronizovaný čas. K tomu slouží protokol NTP (Network Time Protocol) [15]. NTP servery jsou hierarchicky uspořádány do úrovní. Stratum 0 označuje zařízení, které mají čas přímo synchronizovány s externím zdrojem času (GPS hodiny, radiový signál, atomové hodiny). Stratum 1 servery se synchronizují mezi sebou a podle úrovně Stratum 0. Stratum 2 se synchronizují mezi sebou a úrovní Stratum 1 atd. Důvod zavedení úrovní je, aby se vyhnulo cyklickému synchronizování času. Pro běžné použití by měly počítače používat až NTP servery úrovně Stratum 3. NTP používá protokol UDP a zdrojový i cílový port 123. Pro zařízení s omezenými zdroji existuje i zjednodušená verze protokolu SNTP (Simple NTP).

Obrázek č. 2: Diagram synchronizace jednotlivých úrovní NTP serverů [21] 2.3.1.2 Logovací servery

Ukládání a zpracování logů zajišťují logovací servery, které přijímají logy od zdrojů a na základě konfigurace je dále zpracovávají. Logy mohou ukládat do souborů, databáze, jiných datových úložišť, nebo je přeposílat na další logovací servery. V závislosti na požadavcích, může mít topologie logovacích serverů různou podobu. V praxi se lze setkat s logovacími servery na několika úrovních. Jednotlivé pobočky organizace, nebo její části, mívají samostatný logovací server přímo v lokální síti. Lze tak částečně předejít nechtěné ztrátě logů při případném zahlcení sítě, nebo transformovat logy do zabezpečené podoby, aby mohli být dále přeposlány na centrální logovací server. Centrální logovací server agreguje logy ze všech zdrojů a přeposílacích log serverů 14

(forwarders), dále je zpracovává, třídí a může přeposílat na specializované log servery. Pro zajištění redundance, či rozložení zátěže, může být centrálních serverů hned několik. Specializované servery mohou sloužit například pro analýzu logů, k dlouhodobému ukládání logů (archivaci a zajištění integrity), atp. [1] Rotace logů Je způsob archivace logů, který typicky probíhá na logovacím serveru. Pokud logy nijak neomezujeme, stále se zvětšují a v krajním případě mohou zaplnit celý disk. Toto riziko lze omezit právě použitím mechanismu rotace logů. Nejčastější schéma rotace logů je následující. Soubor s názvem soubor.log je přejmenován na soubor.log.1 a je vytvořen nový log soubor.log. Při další rotaci logů je soubor.log.1 přejmenován na soubor.log.2, soubor.log přejmenován na soubor.log.1 a je opět vytvořen nový log soubor.log. Na OS Linux rotaci logů nejčastěji provádí nástroj logrotate. [16] Pro každý log lze dále nastavit různé parametry. Jak často se bude rotovat, zda denně, týdně, měsíčně, nebo po překročení určité velikosti logu. Kolik odrotovaných logů chceme zachovat. Zda se odrotované logy budou komprimovat a jakým kompresním algoritmem. S jakými přístupovými právy bude vytvořen nový soubor, jaké programy se spustí před a po odrotování souboru, atp. Rotace logů nám může usnadnit vyhledávání. Pokud máme logy DHCP serveru rotovány každý den a potřebujeme dohledat záznam z konkrétního dne, nemusíme prohledávat jeden velký soubor, ale stačí nám prohledávat konkrétní soubor z daného dne. Další možné použití je při uchovávání a zpracování citlivých, nebo osobních údajů, které máme oprávnění uchovávat jen určitý počet dnů. Nastavíme jednoduše počet rotování logů na požadovaný limit a starší soubory jsou při rotaci automaticky smazány. 2.3.1.3 Analyzátory logů

Jsou nejdůležitější a nejpřínosnější částí logovací infrastruktury. Můžeme se setkat s analyzátory v podobě jednoúčelových programů, specializovaných samostatných zařízení (tzv. appliance), nebo i složitějších komplexních programů. Analyzátory zkoumají a prohledávají shromážděná data. Analýza může probíhat ve skutečném čase na aktuálně vygenerovaných a právě přijímaných a zpracovávaných datech, označovaná jako real-time (RT). RT analýza se zejména hodí na odhalování kritických stavů, kdy při odhalení kritického stavu je spuštěn poplach (alert). Lze ji také využívat pro procesní řízení. Opakem je tzv. off-line analýza, která probíhá na starších uložených datech. Své uplatnění zde nachází především statistická analýza. Umožňuje nám například sledovat vytížení provozovaných zařízení a služeb, sledovat a odhadovat trendy, detekovat anomálie atp. Off-line analýzu lze také využít při zpětném řešení bezpečnostních incidentů (forenzní 15

analýze), případně při hledání kořenové příčiny (root cause). Analyzátory mohou pracovat s logy v surovém (raw) formátu, tedy ve stejném, v jakém je obdrží. Variabilita různých formátů však analyzátorům znesnadňuje vyhledávání nad takto nestrukturovanými daty a proto některé analyzátory pracují s logy v normalizované podobě. Proces normalizace logů zpracovává nestrukturované příchozí logy, vyhledává v nich důležité části, extrahuje je a dále pracuje pouze s těmito extrahovanými částmi. Při normalizaci přicházíme o část informací z logů. Proto je vhodné, aby měl analyzátor možnost přístupu i k původním nezměněným logům pro případné dohledání detailů. Podstatnou součástí analyzátorů jsou možnosti výstupů a prezentace vlastní analýzy. Dají se shrnout do několika kategorií. Alert (poplach, výstraha) Se zejména používá při RT analýze. Signalizuje kritický stav, o kterém je potřeba neprodleně informovat správce, nebo který je nutno neprodleně řešit. Může být spuštěn na základě výskytu nějakého předepsaného vzoru, nebo pokud počet stanovených událostí nějakým způsobem překročí limit, tzv. threshold. Vlastní provedení alertu může mít různé podoby. Informativní, ve formě nějakého výpisu na monitorovací konzoli, textového výstupu, či výpisu v administrativním rozhraní (většinou webové). Nebo může být na alert navázáno spuštění nějaké činnosti: odeslání e-mailu, odeslání SNMP trapu, odeslání SMS zprávy, spuštění nějakého skriptu (programu). Dashboard (kontrolní panel) Slouží k průběžnému monitorování stavu systému, nebo jeho částí. Mívá grafické provedení v podobě kontrolního panelu. Na panelu mohou být umístěny grafy, které například podle barvy signalizují stav sledované infrastruktury, různé statistické tabulky, které se automaticky aktualizují, výpisy logů, atp. Mohou zde být umístěné i interaktivní ovládací prvky pro případné dohledání událostí. Své využití nachází především pro dohledové služby a operátory, kteří jsou schopni za pomoci dashboardů samostatně řešit případné stížnosti uživatelů a to bez pomoci administrátorů, či administrátorských práv. Report (zpráva, hlášení) Je pravidelně vytvářený informativní výpis za určité časové období (den, týden, měsíc, atd.). Může obsahovat grafy, tabulky, výpisy nejčastějších událostí, výpisy chybových stavů. Slouží pro seznámení a udržení celkového přehledu o stavu spravované infrastruktury pro obsluhu, aniž by musela celou dobu sledovat RT monitoring na dashboardech. Reporty mohou být jak v textové podobě, tak i v grafické a mohou být dostupné buď přes administrační rozhraní nástroje, nebo mohou být například pravidelně zasílány mailem.

16

SIEM nástroje Akronym anglického názvu Security Information and Event Management zažívá od roku 2005 velký rozmach a i přes současné ekonomické krize je stále rostoucím odvětvím. Označuje komplexní nástroj pro správu bezpečnostních událostí a správu logů, v současnosti kvůli jednoduchosti a univerzálnosti nejčastěji ovládaného pomocí webového rozhraní. SIEM vznikl jako přirozené propojení dvou druhů nástrojů označovaných SEM (Security Event Management), pro správu bezpečnostních událostí a SIM (Security Information Management), pro správu logů. Nástroje SIEM tedy řeší jak monitoring v reálném čase s možností automatizace reakcí na události, tak i uchovávání logů, vytváření reportů, jejich pravidelnou kontrolu atp. v souladu s interními, externími, či zákonnými požadavky. [18] Jednou z velmi zajímavých vlastností nástrojů SIEM je schopnost korelace událostí. Korelací událostí se rozumí proces, při němž jsou na základě nějakého společného prvku dány do souvislosti zdánlivě nesouvisející události z různých zdrojů. Pokud útočník provádí masivní slovníkový útok přes SSH, není příliš obtížné tento útok odhalit. Snaží-li se však útočník být nenápadný, může jednotlivé požadavky rozložit v čase a ještě mezi různé stroje organizace. Útok se stane obtížněji detekovatelný, neboť v logovacích souborech na jednotlivých zařízeních to vypadá jako ojedinělý pokus. Jakmile využijeme korelaci událostí a jako společný prvek použijeme zdrojovou IP adresu, nebo uživatelské jméno u kterého jsme zaznamenali neúspěšná přihlášení, jednotlivé na první pohled ne příliš významné události ze zařízení najednou získají zcela nový význam a s vysokou pravděpodobností vypovídají o probíhajícím útoku. Správci tak mohou podniknout nějaká preventivní opatření. Je třeba mít na paměti, že nástroje SIEM nejsou vždy univerzálním řešením na všechny problémy. V počáteční fázi případného nasazení je důležité si ujasnit a stanovit jaké požadavky a jaké konkrétní problémy budeme chtít tímto nástrojem řešit a zda je pro náš případ opravdu nutné nasazovat komplexní řešení typu SIEM nástroje a nevyřešily by je jiné, např. jednoúčelové, nástroje na správu a analýzu logů. [19]

3. Správa logů na ÚVT I když by se mohlo zdát, že správa logů je v současnosti na ÚVT neefektivní, neboť si ji každé oddělení řeší po svém, není tomu tak. Centrální dohled nad službami a infrastrukturou je prováděn non-stop Dohledovým centrem datových sítí [22] za využití nástrojů Nagios [23] a HP OpenView [24]. Z historického hlediska zde nebyla příliš velká potřeba sdílet a zpracovávat logy napříč různými odděleními, kvůli jejich rozličnému zaměření. V poslední době však lze v tomto směru pozorovat jistý posun. V průběhu mapování a rozpracování tématu pro diplomovou práci, která se týká analýzy a správy logů pro Oddělení datových sítí, se 17

objevila zajímavá možnost. Nalézt nástroje pro zpracování logů vhodné i pro další oddělení a nabídnout jim případnou pomoc a podporu při využití takového řešení. Získání nejzajímavějších a nejpřínosnějších výsledků nabízelo využití korelace logů ve spolupráci s Oddělením vývoje a systémové správy, Oddělením systémové správy a Bezpečnostním oddělením.

3.1 Oddělení datových sítí - ODS Spravuje aktivní prvky páteřní sítě Masarykovy univerzity, aktivní prvky lokální sítě na ÚVT, Komenského náměstí 2, Univerzitního kampusu Bohunice a s postupem času přebírá správu dalších lokalit MU. V těchto sítích jsou převážně použity síťové prvky od společnosti Cisco, v menším zastoupení pak HP, 3Com, H3C a Enterasys. I když v současnosti značky HP, 3Com a H3C trochu splývají, neboť 3Com nejprve odkoupil H3C a poté i samotný 3Com odkoupilo HP. U některých produktů tak v současnosti dochází k přejmenování pod vlajkovou značku HP. Všechny spravovatelné aktivní prvky podporují protokol Syslog a jsou nakonfigurovány tak, aby logy přeposílaly na centrální Syslog server, kde jsou dále zpracovávány a archivovány. Jako implementace logovacího serveru je nainstalován rsyslog [25] z aktuální stabilní verze distribuce Debian. Logy jsou na serveru lokálně ukládány na disky zapojené do softwarového pole typu RAID 5 a celý stroj je dále pravidelně zálohován na magnetické pásky. Logovací server Rsyslog vznikl jako jeden z konkurentů projektu Syslog-ng [26], s cílem nabídnout pokročilé funkce pod GPL licencí. Syslog-ng sice nabízel některé pokročilé funkce, ale pouze v placené Premium edici. Díky rychlému zavádění novinek a široké nabídce funkcí přebral Rsyslog postupně roli leadera mezi open source logovacími servery. Základní konfigurace tohoto serveru je poměrně přímočará a jednoduchá. Dokumentace pokročilejších způsobů nastavení není však bohužel příliš přehledná. Na logovacím serveru jsou zprávy z aktivních prvků Cisco jsou analyzovány pomocí nástroje CiscoReport vyvinutého Mgr. Jitkou Plesníkovou v rámci diplomové práce v roce 2005 [27]. V současnosti nástroj generuje denní reporty zasílané e-mailem. Zahrnují přehled o změnách stavu linek, změnách v routovacích protokolech, nejčastější zprávy v logách atd. Nástroj také dříve generoval každé tři hodiny reporty se statistickými údaji o IP adresách a portech zaznamenaných access-listy, což se využívalo pro detekci zavirovaných, či jinak napadených počítačů. V současnosti tuto detekci již provádí bezpečnostní oddělení pomoci dat o datových tocích v síti z NetFlow dat a tak jsou tyto reporty vypnuty. I když je nástroj CiscoReport psán modulárně a s ohledem na budoucí rozšiřitelnost, pro každý nový typ logů je potřeba naprogramovat nový modul. S odchodem Jitky Plesníkové z ÚVT je stále těžší a náročnější udržet pro neprogramátorské oddělení tento 18

nástroj plně funkční a dále ho rozšiřovat, i když je analýza logů pro bezpečnost a správu celé infrastruktury velice důležitá. Tento problém byl také jeden z hlavních důvodů pro sepsání této diplomové práce a nalezení lepšího řešení situace do budoucna. Kromě aktivních síťových prvků spravuje oddělení také několik linuxových serverů, PC firewallů a IPS. Logování na těchto prvcích je prozatím řešeno pouze lokálně. Po zpracování diplomové práce by měly být důležité logy přeposílány na centrální logovací server a začleněny do analýzy.

3.2 Oddělení bezpečnosti datové sítě Monitoruje a analyzuje provoz v datové síti pomocí NetFlow dat z hardwarově akcelerovaných FlowMon sond, umístěných v důležitých uzlech sítě MU. NetFlow údaje obsahují informací o zdrojové a cílové IP adrese, zdrojovém a cílovém portu, typu IP protokolu, době trvání, počtu paketů, součtu bajtů a TCP příznacích. [28] V případě potřeby je možno tuto množinu údajů upravit. Analýzou těchto toků je velice efektivní odhalovat některé typy útoků, například skenování portů. Uzly, které jsou na základě analýzy identifikovány jako napadené, jsou ve spolupráci s Oddělením datových sítí automaticky blokovány na nejbližším routeru pomocí technologie S/RTBH (Source Remotely Triggered Black Hole) [29] . Blokace uzlů funguje i na uzly ležící mimo síť MU. Oddělení má také vyhrazený segment pro nasazení honeypotů, což jsou systémy simulující běžné funkční servery, ale monitorují akce prováděné útočníkem. Na základě chování lze odhalit, zda se jedná o náhodný útok, či o záměrný a případně blokovat útočníka. Inteligentní logovací server V průběhu let 2009 - 2010 nasadilo bezpečnostní oddělení ILS (Inteligentní logovací server) v rámci fondu rozvoje sdružení CESNET [30] do sítě MU. Cílem projektu bylo vytvoření centrálního logovacího serveru s pokročilými možnostmi sběru, zpracování a analýzy dat, což se podařilo. Logy z honeypotů a logy vygenerované na základě detekce útoků z NetFlow dat jsou přeposílany na ILS, kde jsou korelovány a je tak zvýšena přesnost detekce útoků a snížena hranice falešných hlášení. Korelace událostí je prováděna pomocí nástroje SEC (Simple Event Correlator). I když je SEC velice silný nástroj, z pohledu nutnosti textové konfigurace ztrácí trochu na lehkosti ovladatelnosti v porovnáním s webovým GUI některých SIEM nástrojů. ILS je koncipován jako hierarchický logovací server. Součástí praktické části diplomové práce je vytipování zajímavých událostí v infrastruktuře ODS a přeposílání těchto údajů na ILS pro korelaci s dalšími zdroji.

19

3.3 Oddělení vývoje systémových služeb Vyvinulo a spravovalo infrastrukturu univerzitních počítačových studoven. [31] . Celé řešení je realizováno pomocí standardizovaných technologií pro správu OS Windows. Základem je využití Microsoft Active Directory, které přebírá údaje o uživatelích z databáze Informačního systému MU. Na AD (Active Directory), jakožto autentizační a autorizační službu, jsou dále napojeny další služby v rámci ÚVT (VPN, EduRoam). Ne všechny služby jsou však provozovány pouze na OS Windows. Některé další služby v rámci UPS (Univerzitních počítačových studoven) jsou provozovány na OS Linux, jedná se například o zajištění tiskových a kamerových služeb. Z těchto systémů jsou logy přeposílány na centrální logovací server OVSS (Oddělení vývoje systémových služeb), kde jsou analyzovány pomocí nástroje Epylog [32] a reporty jsou pravidelně zasílány e-mailem.

3.4 Oddělení systémové správy Zajišťuje správu služeb pro chod ÚVT. Což zahrnuje například správu zaměstnaneckých počítačů s OS Windows, provoz serverů, různých informačních systémů, ale také například ve spolupráci s dalšími odděleními provoz univerzitních služeb jako VPN a EduRoam. Po událostech na ÚVT z počátku tohoto roku a odchodu velké části oddělení OVSS přešla zodpovědnost za správu infrastruktury UPS právě na oddělení OSS. V současnosti dochází ke konsolidaci provozovaných služeb a celého řešení.

4. Nástroje pro analýzů logů 4.1 Splunk Je softwarový nástroj určený pro ukládání, zpracování a analýzu jakýchkoliv textových dat. Umožňuje velmi snadné a intuitivní vyhledávání v těchto datech, real-time monitoring a jednoduché vytváření grafů, reportů a dashboardů. Mezi referencemi má zvučná jména jako Visa, NASA, Cisco, LinkedIn. [33] Splunk nabízí možnost vyzkoušet si plně funkční verzi, omezenou pouze množstvím indexovaných dat na 500 MB za den, a to po dobu 60 dní. Po uplynutí této doby jsou omezeny některé funkce, bližší přehled viz tabulka č. 3. Zvláštní povaha nástrojů na analýzu logů (nevíme co vlastně chceme a hledáme, dokud to nenajdeme) znesnadňuje nalezení vhodného nástroje. Možnost vyzkoušení trial verze nabízí velkou příležitost osahat si ve svém oboru špičkovou technologii. Díky strmé křivce učení umožňuje poměrně rychle nabrat potřebné zkušenosti, které by se mohli později zúročit při výběru vhodného nástroje, nebo při jeho vývoji. Proto jsem rozhodl v rámci diplomové práce věnovat tomuto produktu značnou pozornost. 20

Tabulka č. 3: Porovnání licencí [33]

4.1.1 Instalace Vlastní instalace Splunku je velice jednoduchá. Z webových stránek http://www.splunk.com/download stáhneme verzi určenou pro požadovaný operační systém. Podporovány jsou OS rodiny Windows, Linux, Solaris, OS X, FreeBSD, AIX a HP-UX. V závislosti na rodině OS je Splunk dostupný ve formě instalátoru (Windows), .rpm či .deb balíčků (Linux), nebo nějaké podoby zabaleného archivu (Linux a zbylé OS). V našem případě jsme využili předpřipraveného .deb balíku a pod uživatelským účtem root jsme balík nainstalovali: dpkg -i splunk-4.3.1-119532-linux-2.6-amd64.deb

A následně spustili příkazem: /opt/splunk/bin/splunk start

21

Při prvním spuštění a po potvrzení licence jsou vygenerovány RSA klíče, vytvořeny pracovní adresáře. Je spuštěno webové rozhraní, které je dostupné na adrese http://hostname:8000/. Pro administraci je automaticky vytvořen uživatel admin s heslem changeme.

Obrázek č. 3: Přihlašovací obrazovka [33] Při prvním přihlášení je uživatel důrazně vyzván ke změně hesla. Jelikož administrace probíhá nešifrovaně, je vhodné nastavit administraci přes šifrovaný protokol HTTPS. To se provede vytvořením souboru /opt/splunk/etc/system/local/web.conf s následujícím obsahem: #https access [settings] httpport = 8000 enableSplunkWebSSL = true privKeyPath=etc/auth/splunkweb/splunk-server-private.key caCertPath=etc/auth/splunkweb/splunk-server-certificate.pem

A restartováním webového administračního rozhraní: /opt/splunk/bin/splunk restart splunkweb

4.1.2 Popis základního GUI Grafické rozhraní je intuitivně a jednoduše navrženo, takže se příjemně ovládá a uživatel nemusí nic složitě hledat. Položky se nacházejí tam, kde by je hledal. Zpočátku může být trochu matoucí rozdělení na jednotlivé aplikace, toto však naopak zajišťuje v pozdější fázi využití nástroje zjednodušení pro dohledovou službu a běžného uživatele.

22

4.1.2.1 Horní navigační lišta

Po přihlášení administrátora do systému se ocitáme v aplikaci Home, která nám umožní ihned přidat data a poté nad nimi vyhledávat. Mezi aplikacemi se přepínáme pomocí seznamu aplikací (App) v navigační liště v pravém horním rohu. Stěžejní aplikací je Search v které prohlížíme logy a které se budeme dále věnovat podrobněji. Uživatel si též může vytvářet vlastní aplikace. Pojmem aplikace se rozumí ucelený soubor nastavení, definicí, pravidel, dashboardů, reportů atd. specializovaných na analýzu a monitorování určité části infrastrutury. Například aplikace pro monitoring firewallů Cisco PIX a ASA, Apache web serveru, OS Linux atd. Administrátor může každému uživateli nastavit jeho výchozí aplikaci po přihlášení, případně nastavením oprávnění omezit pouze na jednu vybranou a tím zamezit zmatení běžných uživatelů a usnadnit ovládání.

Obrázek č. 4: Aplikace Home Nastavení (Manager) Všechna běžná nastavení Splunku se dají provádět právě v této sekci. Konfigurace je posléze zapsána do textových konfiguračních souborů v adresářích etc. Může se jednat o adresáře systémové, uživatelské nebo aplikační. Změny lze také provádět přímo v konfiguračních souborech, záleží na preferenci uživatele, či správce. Mezi nejběžnější úkony správy prováděné v sekci Nastavení patří přidávání nových zdrojů dat, správa uživatelských účtů a nastavení jejich oprávnění, správa typů událostí, polí, aplikací atd. Poplachy (Alerts) Důležitou částí monitoringu stavu infrastruktury je upozornění správce na výskyt nějakého závadného stavu. V případě splnění stanovených podmínek, nebo například při výskytu určité zprávy je vyvolán poplach. V této sekci si pak správce může podrobně prohlížet nastavení jednotlivých poplachů, konfigurovat podmínky pro jejich vyvolání, či sledovat aktivované poplachy.

23

Obrázek č. 5: Manager Úkoly (Jobs) Každý zadaný vyhledávací dotaz, včetně naplánovaných uložených dotazů a dotazů pro reporty a dashboardy, je klasifikován jako jeden úkol. V této sekci lze sledovat právě probíhající a již proběhlé úkoly, jejich náročnost, zpracované výsledky, nebo stav jejich aktuálního průběh. Odhlášení (Logout) Provede odhlášení uživatele ze systému. Ve výchozím nastavení dochází k odhlášení uživatele při nečinnosti delší než 60 minut. Tento limit lze změnit v sekci Manager → System Settings. 4.1.2.2 Aplikace Search

Při spuštění aplikace Search, je nejprve zobrazen dashboard Summary. V levé vrchní části vidíme navigační lištu, která obsahuje následující položky (Search app navigation bar). Summary Dashboard zobrazuje v reálném čase aktualizované informace o indexovaných datech. Jejich počet, zdroje, typy zdrojů a žebříček nejvíce aktivních hostů. Správce si tak udrží snadno hrubý přehled, zda se správně indexují data a zda nějaké zařízení nevykazuje znenadání velké množství dat, což by mohlo signalizovat nějaký problém. Search bar nabízí okamžitě možnost zadat dotaz a prohledávat data. Search Je určen na zkoumání a vyhledávání v datech. V horní části se nachází pole určené pro zadávání vyhledávacího dotazu, označováno jako search bar. Pravá část search baru slouží pro zpřesnění časového období v kterém se má zadaný dotaz vyhledávat (time range picker). Výchozí volba není časově nijak omezená, vyhledávají se tedy všechny odpovídající 24

záznamy ve všech zaznamenaných datech. Ovšem dotazy trvající déle než 30 sekund jsou automaticky pozastaveny a je nutno je explicitně povolit pomocí ovládacích prvků nacházejících se vpravo pod time range pickerem (search actions). Kromě tlačítek na spuštění dotazu na pozadí, pozastavení, znovu spuštění, nebo zrušení vykonávání dotazu, jsou zde ještě přítomny tlačítka na uložení jak dotazu, tak jeho výsledků. Tlačítkem Create (vytvořit) pak ze zadaného dotazu můžeme vytvořit dashboard, poplach, report, typ události, nebo plánovaný dotaz.

Obrázek č. 5: Aplikace Search [33] Ve střední části se nachází časová osa (timeline), na které je zobrazen počet a čas výskytu výsledků nalezených odpovídající zadanému dotazu. V průběhu vyhodnocování dotazu, jak jsou nacházeny nové výsledky, je postupně aktualizován graf na časové ose. Pomocí myši lze výběrem přímo do časové osy upravit časový rozsah dotazu, zmenšit, nebo naopak zvětšit časové období. V dřívějších verzích byla časová osa implementována pomocí technologie Adobe Flash, což z výkonnostních důvodů znesnadňovalo, nebo i z důvodu chybějící podpory znemožňovalo použití na některých zařízeních. V současné době už je časová osa implementována pomocí prvku HTML5 Canvas a Splunk je v případě potřeby možno používat i na mobilních telefonech atp. V dolní části se nachází dva panely. Levý panel slouží k zobrazení polí rozpoznaných během vyhledávání. Data uložená ve Splunku nemají primárně žádnou definovanou 25

strukturu a je s nimi zacházeno jako se strojovými daty, nad kterými je vytvořen fulltextový index. Až zpětně, při vyhledávání, jsou ve vyhledávaných datech rozpoznávány podle vzorů různá pole, mající sémantiku. Například pole jako zdrojová a cílová IP adresa, zdrojový a cílový port atp. V pravém panelu jsou zobrazeny již vlastní výsledky hledání, řádky logu odpovídající výsledkům vyhledávaného dotazu. Části nalezených logů, které odpovídající vyhledávanému dotazu, jsou žlutě zvýrazněny.

Obrázek č. 6: Zobrazení výsledků vyhledávání Status Dasboard obsahuje několik položek týkajících se zatížení a výkonu instalace Splunku. Zobrazuje informace o množství dotazů, jejich náročnosti na systémové prostředky atd. Podrobnější statistické informace o aktivitě indexovaných dat, podrobnější než nabízí dashboard Summary a aktivitu jednotlivých indexů. Informace o aktivitě naplánovaných dotazů a o stavu serveru. Dashboards & Views Umožňuje vytvářet, editovat a spouštět dashboardy. View je nazývána každá stránka aplikace, nejběžnějším typem stránek (viewů) je právě dashboard. Searches & Reports Při zkoumání a prohledávání dat se nám občas podaří vytvořit poměrně složité vyhledávací dotazy. Abychom si je nemuseli pamatovat a nepřišli o ně, lze si je snadno uložit pro pozdější použití. Uložené dotazy se využívají také v dashboardech, reportech, nebo při spuštěných plánovaných úkolů.

26

4.1.3 Vyhledávání Prosté vyhledávání ve Splunku je velice jednoduché. Stačí se přepnout na aplikaci Search a okamžitě můžeme zadávat zajímavá hledaná slova, nebo řetězce do Search baru a sledovat, procházet a analyzovat výsledky dotazu. Nejjednodušší způsob vyhledávání je prosté zadávání hledaných slov. U vyhledávaných slov není brán zřetel na velikost písmen, slova oddělená mezerou mají mezi sebou implicitně logický operátor AND. Vyhledávaná slova lze dále spojovat logickým operátorem OR nebo zakázat jejich výskyt použitím NOT. Na velikosti písmen logických spojek záleží. Komplikovanější logické výrazy lze pro jednoznačnost uzavírat do závorek. Pro vyhledání frází lze použít uvozovky. Neznáme-li přesné znění vyhledávaného slova, můžeme si vypomoci použitím zástupného znaku hvězdička (*). Pokud jsme zadali příliš obecný dotaz a výsledky obsahují i záznamy, které neodpovídají našemu záměru, nemusíme další slova zadávat přímo z klávesnice, ale prostým kliknutím na slova ve výsledcích vyhledávání jsou automaticky připojena k dotazu. Je-li při kliknutí na slova ve výsledcích držena klávesa Ctrl je dotaz změněn na negaci daného slova. Tedy jsou vyhledány právě všechny záznamy, kde se dané slovo nevyskytuje. Získané výsledky lze dále zpracovávat pomocí rozsáhlé skupiny příkazů, které se uvádí za znakem svislá čára |. Příkazy nabízí různé statistické výpočty nad získanými výsledky, generování tabulek, odesílaní mailů atp. Možnosti příkazů jsou poměrně rozsáhlé a komplexní, ale rychlý přehled lze získat pohledem do dokumentace s přehledem těchto příkazů. [34] Protože však hledání v online dokumentaci není úplně pohodlné, search bar obsahuje historii a interaktivní nápovědu, která na základě zadávaného dotazu nabízí nápovědu k použitým funkcím, odhadovaným jménům polí atp. Specifikaci časového rozsahu pro který má být daný dotaz vykonán lze stanovit nejen pomocí webového rozhraní, ale i přímo jako součást vyhledávacího požadavku a užitím parametrů earliest a latest. Parametry nabízí užití jak absolutních hodnot, tak i relativních. Relativní specifikace času nám například umožňuje provádět dotazy v reálném čase a případně generovat reporty za posledních uplynulých 60 minu dotazem earliest=-60m. Relativní hodnoty lze navíc „přichytit“ (snap to) k jistému časovému okamžiku, aby oněch relativních 60 minu zpětně bylo například počítáno až od začátku, nebo konce celé hodiny. Výše uvedený příklad by byl upravený do podoby earliest=-60m@-1h latest=@-1h. Parametr snap to se uvádí za znak zavináč, není-li uveden, je použit aktuální čas. Uvedená kombinace parametrů znamená, že prohledáváme časový úsek 60 minut zpětně, ale od poslední ukončené celé hodiny. A konec intervalu je poslední celá ukončená hodina. Bude-li aktuální čas například 13:33, prohledávaný interval bude 12:00 až 13:00. Podrobný přehled použitelných jednotek lze nalézt v dokumentaci. [35] 27

Definice polí Fulltextové vyhledávání na základě klíčových slov je sice velmi užitečné, při dalším zpracováni logů však potřebujeme nějakým způsobem extrahovat pro nás zajímavé části logů a dále s nimi pracovat. Na základě regulárních výrazů jsou v nestrukturovaných datech rozpoznány důležité části, které je dále možno zpracovávat pomocí různých statistických, manipulačních a jiných příkazů. Tomuto procesu se v terminologii Splunku říká extrakce polí (field extraction). Pouze několik málo základních polí je extrahováno již v průběhu indexace dat, drtivá většina se však extrahuje až v průběhu vykonávání dotazu. Způsobů jak definovat pole máme hned několik. Pro začátek se jeví jako nejrychlejší metoda použití nástroje Interactive Field Extractor. Nástroj spustíme přes Event option menu → Extract fields, jež se nachází na začátku každého řádku výsledků. Do pole Example values zadáme ukázkovou hodnotu pole, které chceme nadefinovat, jež se nachází někde v zaindexovaných datech a Splunk vygeneruje regulární výraz, který se snaží odpovídat uvedeným hodnotám. Bohužel, takto vygenerované regulární výrazy jsou dost nepřesné a ve výsledku často neodpovídají požadovaným hodnotám. O něco složitější metoda je ruční vytváření regulárních výrazů a jejich ukládání do konfiguračního souboru props.conf. Editaci tohoto souboru můžeme provádět buď přímo, máme-li dostatečná oprávnění, nebo pomocí webového rozhraní Manager → Fields → Field extraction. Jedná se o regulární výrazy založené na PCRE knihovně [36] a k extrakci polí se využívá vyhledávání pomocí pojmenovaných skupin (named capturing groups). [37] Upravujeme-li definici polí přímo v souboru props.conf, je potřeba Splunk restartovat. Zápis extrakce pole v souboru props.conf vypadá následovně: [cisco] EXTRACT-cisco-configured-by = Configured from .* by (?[^ ]+)

První řádek je jakýsi identifikátor typu zdroje. Pro různé zdroje logů totiž můžeme mít různé regulární výrazy, které však extrahují stejná pole. Na základě identifikátoru se pro konkrétní zdroj vybere správná sada regulárních výrazů k extrakci. Využití typů událostí při vyhledávání Splunk nám umožňuje výsledky vyhledávání sdružovat a klasifikovat do uživatelsky definovaných typů událostí (event type). Tento mechanizmus nám následně velmi usnadňuje vyhledávání. Místo složitého vyhledávacího řetězce zadáme pouze vyhledat události určitého typu. Jak uvidíme v našem případě náhrady CiscoReportu, vyhledávací řetězec lze nahradit jednoduchým dotazem na vyhledání událostí typu: eventtype=cisco-configured. Typy událostí lze dále označovat štítky a tyto štítky využívat při vyhledávání. Typy událostí mají ve výchozím nastavení platnost pouze v rámci aplikace (App), v které byly vytvořeny, nicméně tuto platnost lze v případě potřeby nastavit napříč všemi 28

aplikacemi. Typy událostí lze definovat buď pomocí webového rozhraní v části Manager → Event types, definovat na základě vyhledané události, nebo přímo v konfiguračním souboru eventtypes.conf.

4.1.4 Praktické nasazení Splunku 4.1.4.1 Možnosti načítání dat Splunku

Splunk podporuje mnoho způsobů jak získávat data pro indexaci a následné vyhledávání.

Obrázek č. 7: Typy vstupních dat Lokální soubory a adresáře Jedná se o standardní způsob zadávání dat pro indexaci. Soubory můžeme přímo nahrát přes formulář, nebo načíst ze souborového systému. Jednorázově načítané soubory jsou nativně podporované i komprimované pomocí algoritmu zip. Velmi důležitou vlastností je automatické sledování změny obsahu souborů a adresářů. Jakýkoliv obsah, který je do nich zapsán, je automaticky indexován. U načítaných souborů jsme v rozšířených možnostech schopni zadat další parametry, jako je typ logu, typ zdroje, jméno indexu atp., které můžeme využít později při vyhledávání. Malým trikem jsme také schopni monitorovat i například SNMP trapy. Přijaté trapy zapisuje SNMP server do logovacího souboru, který Splunk automaticky sleduje a indexuje.

29

Obrázek č. 8: Načítání lokálního souboru Vzdálené soubory a adresáře Splunk může fungovat i v režimu tzv. forwarderu, kdy podobně jako forwardovací (přeposílací) logovací server pouze přeposílá získaná data na jiný server. Na sledovaných hostitelích běží instance Splunku, která získává data, jež však neindexuje, ale přeposílá na jinou centrální instanci Splunku, která teprve provádí indexaci. Dostupné jsou tři verze forwarderu: universal, heavy a light. První je specializovaná aplikace, která pouze přeposílá nestrukturovaná data a konfiguruje se z příkazového řádku. Další dvě verze jsou plnohodnotné instalace Splunku s některými funkcemi omezenými, aby co nejméně zatěžovaly systém.

Obrázek č. 9: Schéma infrastruktury forwarderů [33] Druhá metoda sledovaní vzdálených souborů je, dalo by se říci, spíše pseudo vzdálená. Jedná se o lokálně sledované soubory a adresáře připojené ze vzdálených počítačů pomocí protokolu NFS, SAMBA aj. Syslog přes UDP/TCP Při tomto způsobu Splunk poslouchá na nastavených portech a můžeme tedy přeposílat logy 30

přímo z logovacího serveru na instanci Splunku. Podporována je nová i starší verze Syslogu. Nevýhodou tohoto řešení přímé indexace je, že všechny logy máme uložené a dostupné pouze ve Splunku. Skriptované vstupy Tento způsob sice klade při tvorbě skriptů jisté nároky na správce, ale přináší téměř neomezené možnosti, jaká data do Splunku můžeme načítat. Nastavíme cestu ke skriptu, interval v jakém se má spouštět a chtěné údaje stačí skriptu vypisovat na standardní výstup a Splunk je automaticky zpracuje.

Obrázek č. 10: Nastavení vstupu ze skriptu 4.1.4.2 Zdroje logů v síti ODS

V Oddělení datových sítí se nachází poměrně různorodé zdrojů logů. Kromě síťových prvků, spravuje také několik PC firewallů a síťových služeb. Tento stav je částečně důsledkem historického vývoje a částečně provázaností některých systémů. Například provozovaná Wi-Fi síť je autentizována vůči radius serveru běžícím na serveru částečně ve správě oddělení OSS, které přebírá autentizační údaje z univerzitního AD. Kvůli rychlejšímu řešení problémů se ODS částečně podílí také na správě těchto serverů, nebo jejich služeb. Řešení problémů je poté o něco náročnější, neboť si pracovník musí dohledat data z různých systémů a navzájem časově srovnat. Většina z níže uvedených zařízení a služeb podporuje protokol Syslog, pomocí kterého jsou z nich logy přeposílány na současný centrální logovací server. Z centrálního logovacího serveru jsou logy pomocí spolehlivého protokolu TCP přeposílána na server se Splunkem.

31

Přijaté logy na serveru se Splunkem jsou nejprve logovacím serverem uložené do souborů. Tyto soubory Splunk monitoruje na změnu a indexuje. Tento způsob, nejprve logy uložit a teprve poté indexovat, je vybrán s ohledem na možnost využití uložených logů nejenom Splunkem, ale i jinými nástroji. Aktivní síťové prvky Blíže popsány v části 3.1. Jedná se o hardwarové routery a switche, které podporují přeposílání logů pomocí protokolu Syslog. Firewally Cisco PIX a ASA Dřívější firewally Cisco PIX jsou nahrazovány novějšími modely ASA, nebo firewally jiných výrobců. Na firewallech ASA jsou převážně provozovány IPSec tunely pro zabezpečené přípojení vzdálených lokalit a peněžních aplikací. Taktéž podporují logování protokolem Syslog. PC firewally Jedná se o jednotky kusů, které připojují počítačové učebny a knihovny. Logy týkající se firewallu a SSH jsou Rsyslogem přeposílány pomocí spolehlivého protokolu TCP na Splunk server. Servery Na spravovaných serverech jsou provozovány různé služby DHCP – Dynamické přidělování IP adres. Server podporuje logování voláním systémové služby syslog. Rsyslog přeposílá logy na Splunk server. IPSec/Racoon – Některé IPSec tunely jsou ukončené na serverech, nebo navázané mezi servery. Apache – webový server pro interní potřeby oddělení, poskytování informací uživatelům a rozhraní pro několik XMLRPC služeb. Radiator – Radius server pro potřeby sítě EduRoam a 802.1X. Logy jsou ukládány lokálně na serveru, protože server nepodporuje logování protokolem Syslog. TACACS+ – Server pro autentizaci a autorizaci uživatelů aktivních prvků. Podporuje logování voláním systémové služby syslog. IPS Intrusion Prevention System – Systém pro detekci a ochranu sítě před útoky, podporuje logování protokolem Syslog. Wireless controller Centralizovaný administrační nástroj pro správu bezdrátových přístupových bodů, 32

podporuje logování protokolem Syslog. 4.1.4.3 Konfigurace Splunku pro vstup dat k indexaci 4.1.4.4 Konfigurace Rsyslogu

Jak bylo zmíněno dříve, Rsyslog je syslog server s pokročilými možnostmi. Je zpětně kompatibilní s formátem konfiguračního souboru standardního syslogd. [38] Mezi nejzajímavější rozšíření patří podpora logování protokolem TCP, šifrovaný přenos, logování do databáze a zejména pak pokročilé možnosti definice podoby výstupního formátu logů a pokročilé možnosti filtrování zpráv podle jejich obsahu. Základní funkce má Rsyslog implementovány přímo v hlavním programu, zbylé jsou zajištěné pomocí rozšiřujících modulů. Zpětně kompatibilní řádek konfigurace je složen ze selektoru a akce oddělené mezerami. auth,authpriv.*                 /var/log/auth.log  *.*;auth,authpriv.none          ­/var/log/syslog  Selektor je dvojice facility a priority oddělená tečkou, která odpovídá hodnotám z protokolu Syslog. Hodnoty facility lze oddělit čárkou, více selektorů na jednom řádku pak může být odděleno středníkem. Hodnoty selektoru mohou být také nahrazeny zástupnými znaky hvězdička pro libovolnou hodnotu, vykřičník pro negaci a znak rovnítko pro přesnou hodnotu. Následně podle konfigurace, pro zprávy které odpovídají kombinací facility a priority je vykonána příslušná uvedená akce. Akcí se rozumí co se s přijatým logem provede, může být zapsán do obyčejného souboru, přesměrován do pojmenované roury, vypsán na terminál a konzoli, přeposlán na jiný stroj, vypsán konkrétním přihlášeným uživatelům, zaslán všem přihlášeným uživatelům, zapsán do databáze, přesměrován do výstupního kanálu Rsyslogu (tato funkce bude v budoucnu zrušena), předán jako parametr spouštěnému programu, nebo zahozen. Akce přesměrování do obyčejného souboru je rozpoznána tak, že začíná znakem lomítko a určuje cestu k souboru. Pokud je před lomítkem ještě znak pomlčka, je potlačen vynucený zápis na disk (operace sync), čímž vytížený systém může ušetřit systémové prostředky a zapisovat na disk až více nashromážděných požadavků. Na druhou stranu v případě výpadku přijdeme o nezapsaná data. V případě, že uvedený soubor je speciální soubor ovladače zařízení, například pro TTY, je zpráva vypsána na terminál, nebo na konzoli. Logování do pojmenované roury je rozpoznáno znakem svislá čára (|), za kterým následuje cesta k souboru. Roura musí být vytvořena ještě před spuštěním logovacího 33

serveru pomocí nástroje mkfifo. Je-li jako druh akce uveden znak tilda, logy jsou zahozeny. Začíná-li akce znakem stříška (^) za nímž je uvedena cesta ke spustitelnému souboru, tento soubor je spuštěn a log je mu předán jako argument. V průběhu vykonávání programu je však logovací server zablokován a proto se nedoporučuje tento způsob používat na vytížené servery, protože by docházelo ke ztrátě logů. Použití parametru :omusrmsg:uzivatel,uzivatel2 na pozici akce, zapříčiní vypsání zprávy vyjmenovaným uživatelům, pokud jsou právě přihlášeni. Je-li místo jména uživatele použita hvězdička, je log vypsán všem aktuálně přihlášeným uživatelům. Toto se hodí především pro velmi kritické zprávy způsobující nefunkčnost systému. Přeposílání zpráv protokolem UDP na jiný Rsyslog server se konfiguruje parametrem @remote-host, parametr @@remote-host nastavuje přeposílání spolehlivým protokolem TCP. Autor Rsyslogu také vyvíjí protokol pro spolehlivý přenos RELP (The Reliable Event Logging Protocol), jež je podporován použitím modulu omrelp. Protokol zajišťuje potvrzovaný přenos nejen paketů ale i přímo zpráv a v další verzi by měl podporovat eliminaci případných duplikovaných zpráv, které se v současnosti při použití protokolu TCP mohou při ztrátě a obnově spojení objevit. Formát paramteru akce je následující: :omrelp:<sever>:<port>; Zápis logů do databáze je možný opět použítím výstupních modulů. Nejdříve je potřeba modul v konfiguraci nahrát: $ModLoad ommysql a následně v konfiguraci použít: :ommysql:database-server,database-name,database-userid,database-password

Šablony – Templates Rsyslog nabízí velmi užitečnou funkcionalitu v podobě možnosti definice podoby výstupního formátu logů pomocí šablon. Definice šablony vypadá následovně: $template TraditionalFormat,"%timegenerated% %HOSTNAME% %syslogtag% %msg:::drop-last-lf%0

Za klíčovým slovem template je mezerou oddělené jméno formátu a za čárkou následuje v uvozovkách formátovací řetězec výstupu. Názvy klíčových slov uzavřených mezi znaky procento, je nahrazen aktuální hodnotou odpovídající hodnotě parametru zpracovávané zprávy. Seznam parametrů lze dohledat v dokumentaci. Použití šablony pro konkrétní selektor je provedeno připojením jména šablony za akci, oddělené středníkem. *.*;auth,authpriv.none

-/var/log/syslog;TraditionalFormat

Pomocí šablon jsme schopni generovat i dynamická jména souborů. Za použití filtrování a dynamických jmen souborů takto můžeme roztřídit logy do souborů podle jmen hostů a data, tedy v podstatě částečně nahradit mechanizmus rotování logů. Šablona pro dynamicky generované jméno má stejný formát a vlastnosti jako normální šablona, jen 34

s rozdílem, že je ve tvaru cesty k souboru. Parametr $NOW je nahrazen aktuálním datem ve tvaru RRRR-MM-DD, což značně usnadňuje orientaci v souborech při dohledávání. $template DHCP-host-file,"/var/log/uvt/dhcp/dhcpd-%HOSTNAME%-%$NOW%.log"

Na místě jména akce následně použijeme jméno šablony dynamického jména. Opět použití pomlčky před jménem akce potlačí vynucený zápis na disk. Pro výše uvedenou šablonu, datum 22.1.2012 a server thingol budou logy s facility local1 a libovolnou prioritou zapsány do souboru /var/log/uvt/dhcpd-thingol-2012-01-22.log local1.*

-?DHCP-host-file

Pro zajištění obdobného mechanismu jako je rotace logů, aby se nám aktuální logy nepletly se staršími záznamy, využijeme nástroje find. [39] Starší logy budou přesunuty do archivačního adresáře, který může být dále zálohovaný na magnetickou pásku pro zajištění integrity dat. Každý den o půlnoci je vytvořen referenční soubor. 1 0

* * *

root

touch /oldlog/midnight

Poté, pomocí cronu, jsou logy starší než referenční soubor zkomprimovány a přesunuty do archivačního adresáře. cd /var/log/uvt/dhcp/ && find /var/log/uvt/dhcp/ -type f /oldlog/midnight -name "*.log" -exec bzip2 '{}' \; -exec mv /oldlog/uvt/dhcp/ \;

!

-newer '{}'.bz2

Filtrování logů V některých situacích filtrování logů jen podle facility a priority prostě nestačí. Například dva programy nám logují se stejnou facility a soubory se nám zahlcují hlášeními, které nechceme. Pro tyto případy přichází Rsyslog s řešením v podobě pokročilého filtrování logů. První možnost filtrování je podle obsahu parametrů zmíněných u šablon. Hodnota parametru je porovnána uvedenou operací vůči hodnotě, v případě vykřičníku je výsledek tohoto porovnání negován. :parametr, [!]operace-porovnani, "hodnota"

Operace porovnání mohou být následující: contains (hodnota je obsažena v parametru), isemtpy (parametr je prázdný), isequal (test na přesnou shodu parametru s hodnotou), startswith (parametr začíná uvedenou hodnotou), regex a eregex (test zda parametr odpovídá regulárnímu výrazu uvedenému na pozici hodnota). Tento způsob slouží především pro jednoduché filtrování. Znak ampersand uvedený na dalším řádku znamená definici další akce pro filtru uvedený na předchozím řádku. :programname, contains, "sshd"

/var/log/ssh.log

& ~

35

V uvedeném příkladu nejprve zapíše zprávy, které vygeneroval SSH démon a zbytek jich zahodí, aby se duplicitně nezapisovaly do dalších logů. Použitím ampersandu získáváme výkonnostní benefit, protože filtr se už znovu nevyhodnocuje, ale po prvním vyhodnocení a zapsaní do logu je dalším řádkem zahozen. Pro složitější požadavky filtrace je možné použít filtrování na základě složených výrazů. Používá syntaxi podmíněného výrazu, tedy začíná klíčovým slovem if, za kterým následuje vyhodnocovaný výraz, následně klíčové slovo then a akce pro logy, které splňují podmínku. Výše uvedený výraz lze přepsat následovně: if $programname contains 'sshd' then /var/log/ssh.log

Složitější výrazy lze spojovat logickými operátory and, or, nebo negovat. Parametry můžeme také porovnávat aritmeticky. if $programname contains /var/log/ssh-failed.log

'sshd'

and

$msg

contains

'failed'

then

Logger Jedná se o program, který nám umožňuje vygenerovat do systémového logu zprávu s danou prioritou, facility a obsahem, což se při psaní a odlaďování filtrů a ověřování správné funkčnosti velmi hodí. [40] 4.1.4.5 Náhrada CiscoReportu

V současnosti je z původních informací obsažených v CiscoReportu při denní rutinně využíváno jen několik údajů. Především se jedná o informace o tom kdo, kdy a jaký prvek konfiguroval a jaké typy nezpracovaných zpráv se objevily v logu. Náhrada CiscoReportu byla první přirozený adept na vyzkoušení možností a uplatnění Splunku.

Obrázek č. 11: Výstup CiscoReportu 4.1.4.5.1 Formát Cicsco logů

Logy zařízení Cisco používají k logování původní verzi Syslogu, přičemž od verze IOS 12.4 podporují i logování spolehlivým protokolem TCP. [41] Syslog facility lze na zařízení konfigurovat, výchozí hodnota je Local7 a pro zařízení PIX Local4. Vlastní tělo zprávy 36

začíná znakem % a odpovídá následujícímu formátu [42]: %FACILITY-SEVERITY-MNEMONIC: Message-text

Pole FACILITY (příslušnost) však neodpovídá příslušnosti z protokolu Syslog, ale identifikuje zdroj zprávy v rámci zařízení Cisco. Zdroj může být hardwarové zařízení, protokol, nebo například část zařízení nebo systému. Z jejich názvu lze většinou poměrně dobře odhadnout, čeho se týkají. Pole SEVERITY (závažnost) má stejný význam jako u protokolu Syslog, čím nižší číslo, tím závažnější zpráva. Pole MNEMONIC je jednoznačný unikátní kód typu zprávy. Pole Message-text obsahuje detailnější popis události a situace. Obsahuje například identifikátory portů, MAC adresy, IP adresy, TCP porty, UDP porty, atd. Oproti standardizované původní podobě Syslogu, pokud Cisco prvky nemají synchronizovaný čas, před datum vkládají znak hvězdička, nebo tečka. [42] Existuje ještě jeden speciální typ zpráv, který popisuje interní chyby IOS, tzv. tracebacky. Zprávy tohoto typu mohou být vyvolány pří nějaké nízkoúrovňové chybě v OS. Pokud například daná softwarová funkce není implementovaná v hardware, pokud existuje chyba v IOS atp. Tyto zprávy mohou znamenat závažný problém, bez specializovaných nástrojů jsou však pro běžné uživatele nesrozumitelné. Hlášení může vypadat následovně: %SYS-SP-3-CPUHOG: Task is running for (40)msecs, (35/34),process = REP LSL Hello PP Process.

more

than

(28)msecs

-Traceback= 0x40457170z 0x404583FCz 0x4102C1C8z 0x40415084z 0x40415068z

4.1.4.5.2 Dashboard CiscoReport

Syslog z Cisco zařízení máme přesměrovaný na Splunk a typ zdroje sourcetype nastavený jako cisco. Nejprve potřebujeme z logů vytřídit záznamy, které informují, že bylo zařízení konfigurováno. Jan 4 15:49:54.201: %SYS-5-CONFIG_I: Configured from console by xvitec on vty0 (147.251.1.29)

Podíváme-li se jak vypadá řádek z logu, vidíme, že obsahuje řetězec SYS-5-CONFIG_I. Vyfiltrování chtěných záznamů z logů tedy provedeme prostým zadáním tohoto řetězce do search baru. Každý jednoduchý dotaz, který neobsahuje vnořený dotaz nebo operátor | může být uložen jako typ události. Toho využijeme i v našem případě a pomocí webového UI tlačítkem Create → Event type vytvoříme nový typ události cisco-configured. Stejného 37

efektu dosáhneme kliknutím na Event options menu → Build event type, které se nachází na začátku každého řádku nalezených výsledků. Použitím druhého z uvedených způsobů můžeme také vyhledávací řetězec přímo vyzkoušet a případně upravit. Budeme-li nyní potřebovat vyhledat patřičné záznamy, nemusíme si složitě pamatovat specifický řetězec, ale stačí zadat dotaz ve tvaru: eventtype="cisco-configured", což je mnohem příjemnější a praktičtější. Výpis vyhledaných řádků má však do podoby nějakého reportu stále poměrně daleko. My potřebujeme vědět kdo, kdy, odkud a co konfiguroval. Tyto informace jsou v záznamech obsaženy, ale nemáme zatím nástroj, jak je vyznačit a dále s nimi pracovat. K tomuto účelu slouží právě pole (fields). Některá předdefinovaná pole rozpoznaná a extrahovaná Splunkem při vyhledávání jsou zobrazena v levém panelu vyhledávacího dashboardu. Potřebné údaje pro Cisco report extrahujeme užitím následujících definic v souboru props.conf: [cisco] EXTRACT-cisco-configured-by = Configured from .* by (?[^ ]+) EXTRACT-cisco-configured-from = Configured from (?[^ ]+) EXTRACT-cisco-configured-srcip = Configured .* on \w+ \((?[^ ] +)\) EXTRACT-cisco-configured-srcip-tftp [^/]+)/

=

Configured

from

tftp://(?

EXTRACT-syslog-host = ^[^:]*\d\d\:\d\d\:\d\d[^:]*?\s(?<syslog_host>[^ ]+)

Provedeme-li vytvoření výše uvedených definice přes webové rozhraní, vyhneme se restartu Splunku. Pokud nyní zopakujeme výše uvedený dotaz pro nově vytvořený typ události cisco-configured, všimneme si, že v levém panelu se nám objevily nová pole: confby, conffrom a confsrcip. Jeden z nejzákladnějších příkazů vyhledávacího jazyku pro reprezentaci výsledku je příkaz table. Jako parametry příkazu se uvádí jména polí v pořadí, v jakém je chceme zobrazit. Protože jména polí nemusí mít takovou vypovídací hodnotu, jakou bychom do reportu chtěli, lze jména polí přejmenovat příkazem rename. Pro různé úpravy a výpočty nad hodnotami polí můžeme využít funkce eval, pro řazení výsledků příkaz sort. Upravený dotaz nám již zobrazí výsledky v tabulce jak jsme požadovali. eventtype="cisco-configured" | rename confby as "uživatel", conffrom as "zdroj konfigurace", confsrcip as "odkud", syslog_host as stroj| eval kdy = strftime(_time, "%H:%M") | table "kdy" "stroj" "uživatel" "odkud" "zdroj konfigurace" | sort kdy

38

Obrázek č. 12: Výpis výsledků dotazu v přehledné tabulce

39

7. Závěr Práce se zaměřovala na zmapování současné situace správy logů na ÚVT, zejména pro Oddělení datových sítí. Cílem bylo nalézt vhodnou náhradu současného řešení. Součástí praktické části bylo testovací nasazení nástroje Splunk a jeho využití společně s ostatními odděleními ÚVT. V teoretické části jsem se zaměřil na zmapování znalostí okolo správy logů, použitelných nástrojů a jejich efektivní využití pro denní potřebu ODS. Nabyté znalosti jsem posléze promítl do úprav současné logovací infrastruktury, s cílem zjednodušit dohledatelnost při řešení problému. Testovací nasazení Spluku bylo velmi zajímavé a zaujalo i ostatní oddělení. Z časových důvodů a mé neschopnosti bohužel k širšímu uplatnění a využití možností naplno nedošlo. Hlavním cílem diplomové práce bylo implementovat náhradu současného řešení CiscoReportu, použitím obdobných nástrojů jako je Splunk. Což se mi nakonec vůbec nepovedlo a považuji to za velké a hrubé osobní selhání a zklamání všech co mi věřili. Hlavní příčina selhání byla především ve velmi špatné schopnosti plánování času, opakované neplnění dohodnutých termínů a neschopnosti se motivovat. Hlavní přínos z tohoto selhání je, že mi zůstane jako memento a odstrašující případ. Doufám, že už se v budoucnu nebude opakovat.

40

Použitá literatura: 1. KENT, Karen. SOUPPAYA, Murugiah. Guide to Computer Security Log Management : Recommendations of the National Institute of Standards and Technology. Gaithersburg : NIST , Září 2006. 72 s. SP800-92 2. RFC 3164. The BSD syslog Protocol [online]. C. Lonvick. August 2001. [cit. 2011-12-5]. Dostupný z WWW: 3. RFC 5424. The Syslog Protocol [online]. R. Gerhards. March 2009. [cit. 2011-12-5]. Dostupný z WWW: 4. RFC 3339. Date and Time on the Internet: Timestamps [online]. G. Klyne, Clearswift Corporation, C. Newman. July 2002. [cit. 2011-12-5]. Dostupný z WWW: 5. Common Log Format. [online]. The Apache Software Foundation. [cit. 2011-12-6]. Dostupný z WWW: 6. RFC 931. Authentication Server. [online]. M. StJohns. January 1985. [cit. 2011-12-9]. Dostupný z WWW: 7. Combined Log Format. [online]. The Apache Software Foundation. [cit. 2011-12-6]. Dostupný z WWW: 8. Extended Log File Format. [online]. P. M. Hallam-Baker, B. Behlendorf. The World Wide Web Consortium. [cit. 2011-12-9]. Dostupný z WWW: 9. Extensible Markup Language. [online]. The World Wide Web Consortium. [cit. 2011-12-11]. Dostupný z WWW: 10. Common Format and MIME Type for Comma-Separated Values (CSV) Files. [online]. Y. Shafranovich. October 2005. [cit. 2011-12-12]. Dostupný z WWW: 11. The Binary Log. [online]. Oracle Corporation and/or its affiliates. [cit. 2012-1-5]. Dostupný z WWW: 41

12. TCP/IP Frequently Asked Questions [online]. M. Oliver. 1999. [cit. 2012-1-7]. Dostupný z WWW: 13. OID sysUpTime. [online]. Alvestrand data. [cit. 2012-2-1]. Dostupný z WWW: 14. PSI DSS Data Security Standards Overview. [online]. PCI Security Standards Council [cit. 2012-2-15]. Dostupný z WWW: 15. NTP: The Network Time Protocol. [online]. Dostupný z WWW: 16. Logrotate. [online]. Dostupný z WWW: 17. Data retention, alias: uchovávání provozních a lokalizačních údajů. [online]. J. Peterka. [cit. 2012-2-20] Dostupný z WWW: http://www.earchiv.cz/i_retention.php3> 18. The Future of SIEM – The market will begin to diverge. [online]. A. Williams. [cit. 2012-2-21] Dostupný z WWW: 19. Five Best and Five Worst Practices for SIEM. [online]. A. Chuvakin. [cit. 2012-2-21] Dostupný z WWW: 20. http://www.h3c.com/portal/res/200805/20/20080520_622871_image002_606347_57 _0.gif 21. http://upload.wikimedia.org/wikipedia/commons/c/c9/Network_Time_Protocol_serv ers_and_clients.svg 22. Dohledové centrum datových sítí. [online]. Dostupný z WWW: 23. Nagios. [online]. Dostupný z WWW: 24. HP OpenView. [online]. Wikimedia Foundation. [cit. 2012-2-21] Dostupný z WWW: 42

25. Rsyslog. [online]. Dostupný z WWW: 26. Syslog-ng. [online] Dostupný z WWW: 27. PLESNÍKOVÁ, Jitka. Analýza logů aktivních síťových prvků [online]. 2005 [cit. 2012-02-27]. Diplomová práce. Masarykova univerzita, Fakulta informatiky. Vedoucí práce Jan Staudek. Dostupné z: 28. NetFlow. [online] Wikimedia Foundation. Dostupný z WWW: http://en.wikipedia.org/wiki/NetFlowasdf 29. Remotely Triggered Black Hole Filtering – Destination Based and Source Based. [online]. Cisco Systems. [cit. 2012-3-1] Dostupný z WWW: 30. Inteligentní logovací server. [online]. J. Vykopal, M. Juřen, D. Kouřil, P. Minařík, M. Procházka, A. Zajíček. ÚVT 2010. Dostupný z WWW: 31. J. Dobrovolný, V. Bukač. Infrastruktura univerzitních počítačových studoven. Zpravodaj ÚVT MU. ISSN 1212-0901, 2008, roč. XIX, č. 2, s. 9- 11. Dostupný z WWW: 32. Epylog. [online]. Dostupný z WWW: 33. Splunk. [online]. Dostupný z WWW: 34. Search Cheatsheet. [online]. Dostupný z WWW: 35. Search Time Modifiers. [online]. Dostupný z WWW: 36. Perl Compatible Regular Expressions. [online]. Dostupný z WWW: http://www.pcre.org/ 37. Named Capturing Groups. [online]. Dostupný z WWW: http://www.regular-expressions.info/named.html)

43

38. Sysklogd. [online]. Dostupný z WWW: 39. Find. [online]. Dostupný z WWW: 40. Logger. [online]. Dostupný z WWW: 41. Running Syslog Over TCP. [online]. I. Pepelnjak. Dostupný z WWW: 42. Build Scalable Syslog Management Solutions. [online]. Cisco Systems. Dostupný z WWW:

44