Monitoring, logy a detekce

Jak zjistíš, co se v síti opravdu děje: proč bez logů nedohledáš nic, log server jako jedno místo pro celou síť, úrovně závažnosti a únava z alertů, ztracené logy a slepá místa (syslog jede přes UDP 514 a firewall ho umí zavřít), datové toky, baseline a anomálie, korelace útržků do jednoho incidentu, SIEM konceptuálně a monitoring zařízení včetně nástrahy a kontrolního seznamu.

Lekce 1: Proč logy

Co se stane, když logy nemáš

Než začneš: tenhle kurz staví na pojmech ze začátečnických kurzů (adresy a maska, brána, VLANy, porty, DNS, firewall) – když ti některý nebude jasný, mrkni napřed do nich. Představ si běžné pondělní ráno: účetní nemůže na sdílený disk, jeden server je od pátku vypnutý a v úterý přijde e-mail, že z firemní adresy někdo rozesílal podvodné zprávy. Tři otázky, které padnou hned: kdy to začalo, kdo to způsobil a co se dělo předtím. Bez logů nemáš na jednu jedinou z nich odpověď. Nemáš totiž žádný záznam o tom, co se v síti stalo – síť je zařízení bez paměti a ptát se jí na minulost je zbytečné. Zůstane ti jen to, co si lidé pamatují, a to je při hledání závady i při vyšetřování incidentu velmi slabý podklad. Log je časově označený záznam o jedné události: „v 9:14 firewall zablokoval provoz z PC2 na server", „v 9:20 se zařízení vypnulo". Sám o sobě je nudný. Cenu má proto, že jich je hodně a jdou si postavit vedle sebe – teprve tehdy z nich vzniká časová osa. Praktický důsledek, na který lidé narazí až v krizi: logy musíš sbírat předem. Když se něco stane a ty logy nemáš, už si je nedoplníš – událost, která nebyla zapsaná, se stala jen jednou a je nenávratně pryč. Proto se sběr logů zapíná v klidu, ne po incidentu. V simulátoru na to máš panel Syslog (sběr událostí) – v téhle lekci si ukážeme, co do něj přiteče a odkud.

Krok za krokem

V pátek se něco stalo: provoz z PC2 skončil na firewallu. Bez logu o tom nikde není záznam.
V pondělí padnou tři otázky: kdy to začalo, kdo to způsobil a co se dělo předtím. Paměť lidí na ně nestačí.
Se sběrem logů má každá událost čas a původce. Z jednotlivých řádků se dá poskládat časová osa.
Jenže logy musíš sbírat předem. Událost, která nebyla zapsaná, je nenávratně pryč – sběr se zapíná v klidu, ne po incidentu.

Log server: jedno místo pro celou síť

Zařízení si své záznamy umí držet i sama u sebe – jenže lokální log má tři vady. Za prvé má malé místo: starší řádky přepisují novější, takže když se k němu za týden dostaneš, hledaná událost už je pryč. Za druhé je roztroušený: při vyšetřování bys musel obejít firewall, switch, router i každý počítač a ručně skládat časy dohromady. Za třetí – a to je nejhorší – je na stejném zařízení jako problém. Když útočník obsadí stroj, první, co udělá, je smazání stop; a když se zařízení rozbije nebo vypne, vezme si své záznamy s sebou. Řešení je jednoduché a je staré desítky let: log server, tedy jedno místo, kam všechna zařízení své události posílají. V simulátoru je to obyčejný host se službou Sběr logů (Syslog) na portu 514 – žádná zvláštní krabice, jen běžný server s jednou službou navíc. Když v síti není, panel Syslog ti to rovnou napíše: události se nikam nesbírají. Tři věci, které tím získáš, stojí za zapamatování: jednu časovou osu napříč celou sítí (vidíš, že alert IDS přišel dvě vteřiny po pokusu o spojení), záznam mimo dosah obsazeného stroje a místo, kde se dá hledat, aniž bys musel obcházet zařízení. Log server je proto prvním krokem monitoringu – dřív než jakýkoli chytrý nástroj.

Krok za krokem

Lokální log má tři vady: malé místo, je roztroušený po zařízeních a mizí spolu s tím, co se rozbilo.
Log server je obyčejný host se službou Sběr logů (Syslog) na portu 514. Žádná zvláštní krabice.
Zařízení své události posílají na jedno místo. Vznikne tak jedna časová osa napříč celou sítí.
Aktivní prvky – firewall, router, switch, IDS – logují ze správcovského rozhraní. Záznam je tak mimo dosah obsazeného stroje.

Co logovat a co ne

Když už logy sbíráš, přijde otázka, která rozhoduje o tom, jestli ti k něčemu budou: co zapisovat. Odpověď „všechno" je lákavá a téměř vždy špatná. Kdo zapíše každý paket a každý úspěšný přístup, dostane po týdnu haldu, ve které se nedá nic najít, disk se zaplní a starší záznamy se přepíšou – tedy přesně ty, které bys při vyšetřování potřeboval. Zároveň platí opak: kdo zapisuje málo, dozví se o incidentu, ale ne o jeho příčině. Rozumné vodítko zní: zapisuj rozhodnutí a změny stavu, ne běžný chod. Do logu patří zamítnutý přístup (firewall něco zablokoval), alert od IDS, změna stavu zařízení nebo linky (vypnuto, zapnuto, spoj spadl), přihlášení a jeho selhání, změna konfigurace a nastartování či zastavení služby. Naopak se nevyplácí zapisovat každý úspěšný paket, každou obsluhu DNS dotazu nebo periodické kontroly dostupnosti – to je šum, který jen ředí signál. Rozdíl mezi šumem a signálem se dá otestovat jednoduchou otázkou: když se tenhle řádek objeví, změní se tím něco, co udělám? Pokud ne, do sbíraných logů nepatří. A ještě jedna zásada, na kterou dohlížejí i předpisy: v logu nemají co dělat hesla, obsah zpráv ani citlivé osobní údaje. Log je stopa o události, ne kopie dat – jinak z něj uděláš další cíl, který je potřeba chránit.

Krok za krokem

Zapisovat všechno je lákavé a téměř vždy špatně: disk se zaplní a starší záznamy se přepíšou.
Do logu patří rozhodnutí: firewall něco zablokoval. Takový řádek má cenu i za měsíc.
A patří tam změny stavu a alerty: zařízení vypnuto či zapnuto, IDS hlásí podezřelý provoz, přihlášení selhalo.
Test na šum: změní ten řádek něco, co udělám? A do logu nepatří hesla, obsah zpráv ani citlivé údaje.

▶ Otevřít v simulátoru

Lekce 2: Severity a co s ní

Úrovně závažnosti

Log server ti během dne přinese stovky řádků a ty nemáš čas číst je všechny. Proto má každý záznam úroveň závažnosti (severity) – jednoduchou značku, která říká, jak moc se máš zajímat. Podrobná stupnice syslogu má osm úrovní, ale v praxi si vystačíš se třemi, které používá i panel v simulátoru. Informace (info): normální chod, který jen zaznamenáváš – zařízení se zapnulo, služba nastartovala. Nikam nespěcháš, ale při vyšetřování ti tenhle řádek dá čas a kontext. Varování (warn): něco se nepovedlo, ale síť jede dál – firewall zablokoval provoz, přihlášení selhalo, linka je přetížená. Jeden takový řádek nic neznamená, opakování ano. Kritické (crit): něco přestalo fungovat nebo někdo něco napadl – zařízení je mimo provoz, IDS hlásí podezřelý provoz. Tohle chceš vědět hned. Dvě chyby se dělají pořád dokola. První: všechno kritické. Když každý řádek křičí, přestaneš rozlišovat a chováš se, jako by nekřičel žádný. Druhá: nic kritické, tedy jednotná šeď, ve které se skutečný průšvih ztratí mezi rutinou. Severita není vlastnost události samotné, ale tvého rozhodnutí, co s ní uděláš. Dobrá zkouška: kritické je to, kvůli čemu má někoho vzbudit telefon. Ke všemu ostatnímu stačí, když se na to podíváš ráno.

Krok za krokem

Informace: běžný chod – zařízení se zapnulo, služba nastartovala. Nespěcháš, ale máš čas a kontext.
Varování: něco se nepovedlo, ale síť jede dál. Jeden řádek nic neznamená – opakování ano.
Kritické: zařízení je mimo provoz nebo IDS hlásí podezřelý provoz. Tohle chceš vědět hned.
Severita není vlastnost události, ale tvého rozhodnutí. Kritické je to, kvůli čemu má někoho vzbudit telefon.

Kritické události, které nesmíš minout

Které řádky si tedy zaslouží úroveň kritické? Vyplatí se mít krátký, konečný seznam, protože všechno, co v něm není, může počkat do rána. Za prvé výpadek: zařízení je mimo provoz, spoj spadl, služba se zastavila. Vypnutý switch neznamená jen jednu tmavou ikonu – bere s sebou všechno, co za ním viselo, a v panelu Syslog to poznáš podle toho, že přestanou chodit i záznamy od zařízení za ním. Za druhé alert od IDS: to je jediná událost, u které někdo přímo tvrdí „tohle vypadá jako útok". Za třetí opakované selhání přihlášení na správu zařízení – jedno selhání je překlep, třicet za minutu je hádání hesla. Za čtvrté změna konfigurace mimo pracovní dobu, kterou nikdo neohlásil; útočník se nejlíp maskuje jako správce. A za páté – trochu překvapivě – ticho: když zařízení, které celý týden posílalo záznamy, najednou mlčí, je to informace stejně silná jako alert. Buď spadlo, nebo mu někdo vypnul odesílání. Všimni si, že tenhle seznam je krátký a dá se napsat na půl stránky. To je záměr: seznam kritických událostí, který má dvacet položek, se v praxi nedá dodržet a do půl roku ho začnou lidé přeskakovat. K tomu ještě jedna praktická zásada: u každé kritické položky měj předem napsané, co se s ní dělá. Kritický alert bez postupu je jen hlasitější šum.

Krok za krokem

Výpadek: switch je mimo provoz. Bere s sebou i všechno, co za ním viselo – přestanou chodit i jejich záznamy.
Alert od IDS je jediná událost, u které někdo přímo tvrdí: tohle vypadá jako útok.
Opakované selhání přihlášení na správu je hádání hesla. A změna konfigurace v noci, kterou nikdo neohlásil, je podezřelá.
A ticho: zařízení, které týden posílalo záznamy, najednou mlčí. Buď spadlo, nebo mu někdo vypnul odesílání.

Únava z alertů

Existuje selhání monitoringu, které nezpůsobí žádná porucha ani útočník – způsobí ho množství hlášení. Říká se mu únava z alertů a probíhá vždycky stejně. Nasadí se sledování, nastaví se citlivé prahy, aby nic neuteklo, a první týden chodí padesát hlášení denně. Většina z nich je plané – zálohovací úloha, která běží v noci, testovací stroj, který se pravidelně restartuje, kolega, který se dvakrát překlepl v hesle. Člověk je postupně odklikává rychleji a rychleji, pak si na ně udělá filtr do složky a nakonec je přestane číst úplně. V ten okamžik máš nejhorší možný stav: platíš za sledování, máš plný disk záznamů, ale nikdo se nedívá – a přitom všichni věří, že se dívá. Skutečný alert pak v haldě planých projde bez povšimnutí. Léčba není vypnout sledování, ale zúžit ho. Za prvé: zvyš prahy tam, kde je hlášení pravidelně plané, a plané zdroje si rovnou pojmenuj a vyřaď (známý zálohovací agent, testovací stroj). Za druhé: hlásit se má opakování a vybočení, ne každý jednotlivý výskyt – třicet zamítnutí za minutu je alert, jedno zamítnutí je řádek v logu. Za třetí: každé hlášení, které nikdo nikdy nevyřešil, buď oprav, nebo zruš. Užitečné měřítko, které se dá sledovat: kolik procent alertů vedlo k akci. Když je to pod pár procent, neladíš detekci – jen si vyrábíš šum.

Krok za krokem

Citlivé prahy přinesou padesát hlášení denně a většina je planá: noční záloha, testovací stroj, překlep v hesle.
Člověk je odklikává rychleji, pak si udělá filtr a nakonec je přestane číst. Nikdo se nedívá – a všichni věří, že ano.
Skutečný alert pak v haldě planých projde bez povšimnutí. To je nejhorší možný stav monitoringu.
Léčba je zúžit: hlas opakování a vybočení, plané zdroje pojmenuj a vyřaď, a co nikdo nikdy neřešil, oprav nebo zruš.

▶ Otevřít v simulátoru

Lekce 3: Když logy nedorazí

Cesta logu je taky provoz

Tady přijde myšlenka, která začátečníky často zaskočí: log není kouzlo, je to síťový provoz. Když zařízení pošle záznam na log server, vznikne obyčejný paket, který musí projít úplně stejnou cestou jako cokoli jiného – přes switch, přes firewall, po lince, která může být přetížená nebo přerušená. Syslog navíc tradičně jezdí přes UDP na portu 514, a to má dva důsledky, které stojí za pochopení. UDP je nespolehlivý: odesílatel paket vypustí a nedostane potvrzení, že dorazil. Zařízení proto vůbec neví, že se jeho hlášení ztratilo – klidně dál posílá do prázdna a tváří se, že je všechno v pořádku. Zároveň je UDP levné: nemusí navazovat spojení a jeho odesílání nezdrží ani zahlcený router, což je u tisíců záznamů za minutu praktická výhoda. Právě proto se u syslogu drží dodnes. Z toho ale plyne důležitý závěr pro návrh sítě: mezi každým zařízením, které loguje, a log serverem musí existovat průchodná cesta – směrování, které tam vede, a povolení na firewallu, které to nezastaví. Zapamatuj si to jako pravidlo: cesta logu je součást návrhu, ne samozřejmost. V simulátoru si to ověříš přímo – když log server odpojíš, přesuneš za zavřený firewall nebo vypneš, panel Syslog ti spočítá, kolik událostí se nedoručilo.

Krok za krokem

Záznam na log server je obyčejný paket. Jde přes switch, přes firewall a po lince jako cokoli jiného.
Syslog jezdí přes UDP na portu 514. Bez navazování spojení, a proto levně i při tisících záznamů za minutu.
UDP nepotvrzuje doručení. Zařízení tedy vůbec neví, že se hlášení ztratilo – posílá dál do prázdna.
Proto platí: mezi každým zdrojem a log serverem musí vést průchodná cesta. Cesta logu je součást návrhu, ne samozřejmost.

Firewall blokuje port 514

Nejčastější způsob, jak si sběr logů rozbiješ, je přitom docela nevinný: firewall zavře port 514. Vzniká to úplně přirozeně. Nastavíš výchozí zákaz mezi segmenty – uživatelé nesmějí na servery, kamery nesmějí nikam – povolíš, co lidé potřebují k práci, a jsi hotov. Jenže sběr logů není práce uživatele: je to provoz zařízení, o kterém při psaní pravidel nikdo nepřemýšlí. Výsledek je zákeřný, protože vypadá dobře. Firewall dělá přesně to, co jsi mu řekl, síť funguje, uživatelé si nestěžují a nikde nesvítí červená. Jen do log serveru přestanou chodit záznamy z jednoho segmentu. A protože UDP nepotvrzuje doručení, ani odesílající zařízení o tom neví – dál poctivě vypouští hlášení, která nikdo nikdy neuvidí. Panel Syslog v simulátoru ti tuhle situaci ukáže: událost se ztratí a panel spočítá, kolikrát se to stalo. Stejný stav umí vyrobit i další tři věci: log server neběží (je vypnutý), chybí cesta mezi segmenty (žádná routa nebo přerušený kabel) nebo je server ve špatném segmentu, kam se ostatní nedostanou. Praktický návod: při psaní pravidel povol syslog jako první, spolu s DNS a časem – jsou to tři služby, které potřebuje síť sama k tomu, aby se dala provozovat. A po každé změně pravidel se do panelu podívej: mlčící segment je podezřelý dřív než hlasitý.

Krok za krokem

Dokud je port 514 povolený, záznamy chodí a v panelu Syslog přibývají řádky. Zatím je vše v pořádku.
Nastavíš výchozí zákaz mezi segmenty a povolíš, co lidé potřebují. Sběr logů ale není práce uživatele – zůstane zavřený.
Stav vypadá dobře: síť jede, nikdo si nestěžuje, nikde nesvítí červená. Jen z jednoho segmentu přestanou chodit záznamy.
Povol syslog jako první, spolu s DNS a časem. Stejný stav vyrobí i vypnutý server nebo chybějící cesta.

Ztracené logy = slepé místo

Zastavme se u toho, co ztracený log vlastně znamená, protože to je závažnější, než vypadá. Když se hlášení nedoručí, nevznikne nikde chybová hláška ani prázdné místo s otazníkem. Vznikne mlčení, které se tváří jako klid. Když se pak podíváš na log server, uvidíš záznamy ze zbytku sítě, panel bude vypadat obydleně a ty přirozeně usoudíš, že v tichém segmentu se nic neděje. To je slepé místo (blind spot): část sítě, kterou nevidíš, ale myslíš si o ní, že je v pořádku. Nevědomost je nepříjemná, mylná jistota je nebezpečná. A je tu ještě jedna vrstva, kterou si musíš přiznat: útočníkovi vyhovuje, když nevidíš. Vypnout odesílání logů nebo zahodit sběrač je běžný krok při zahlazování stop, a když se to povede, nezůstane po něm žádný záznam právě proto, že záznamy zmizely. Proto se hlídá i samotný sběr logů. Tři jednoduché kontroly ti pokryjou většinu případů. Za prvé čítač ztracených událostí – panel Syslog v simulátoru ho ukazuje a jakékoli číslo nad nulou je závada, ne kosmetika. Za druhé seznam zdrojů: víš, která zařízení mají logovat, a pravidelně kontroluješ, jestli od každého něco přišlo. Za třetí ticho jako alert: zdroj, který přestal posílat, si zaslouží upozornění stejně jako alert od IDS. Slepé místo se totiž nikdy neohlásí samo – najdeš ho jen tak, že se po něm aktivně díváš.

Krok za krokem

Hlášení se ztratí. Nikde nevznikne chybová hláška ani prázdné místo – jen mlčení, které se tváří jako klid.
Zbytek sítě loguje dál a panel vypadá obydleně. Přirozeně usoudíš, že v tichém segmentu se nic neděje.
To je slepé místo: část sítě, kterou nevidíš, ale považuješ ji za v pořádku. Mylná jistota je horší než nevědomost.
Hlídej tři věci: čítač ztracených událostí, seznam zdrojů, které mají logovat, a ticho ber jako alert.

▶ Otevřít v simulátoru

Lekce 4: Kdo s kým mluví

Provoz jako datový tok

Logy říkají, co zařízení udělalo. Druhá polovina monitoringu se dívá na to, co po síti teče – a k tomu nepotřebuješ číst obsah paketů. Stačí datový tok (flow): stručný zápis jednoho spojení, který obsahuje pět údajů – zdrojová adresa, cílová adresa, port, protokol a objem přenesených dat, plus čas začátku a konce. Nic víc. Je to jako výpis hovorů: nevíš, o čem se mluvilo, ale vidíš kdo s kým, kdy a jak dlouho. Pro monitoring je to překvapivě mocné, a to hned ze tří důvodů. Za prvé je to malé – z hodin provozu vzniknou kilobajty záznamů místo gigabajtů, takže se dají držet dlouho a procházet zpětně. Za druhé to funguje i na šifrovaný provoz: HTTPS ti skryje obsah, ale ne to, že tvůj počítač každých třicet sekund mluví s adresou, kterou nikdo nezná. Za třetí neobsahuje citlivá data, takže s ním nemáš problém, kterému by se dalo říkat ochrana soukromí. V simulátoru se na tohle díváš panelem Provoz & logy → Živý provoz: vidíš jednotlivé toky, jejich zdroj, cíl, port a to, jestli prošly nebo je někdo zastavil. Klíčová myšlenka na zbytek lekce: tok sám o sobě nic neznamená. Význam dostane až porovnáním s tím, co je v téhle síti obvyklé.

Krok za krokem

Datový tok je stručný zápis jednoho spojení: zdroj, cíl, port, protokol, objem dat a čas. Nic víc.
Je to jako výpis hovorů: nevíš, o čem se mluvilo, ale vidíš kdo s kým, kdy a jak dlouho.
Tok funguje i u šifrovaného provozu: HTTPS skryje obsah, ale ne to, s kým a jak často se mluví.
Jeden tok sám o sobě neznamená nic. Význam dostane až porovnáním s tím, co je v téhle síti obvyklé.

Baseline: co je normální

Aby ses mohl ptát „není tohle divné?", musíš nejdřív vědět, co je normální. Tomu popisu obvyklého stavu se říká baseline (výchozí obraz) a je to nejpodceňovanější část monitoringu – nudná, pracná a bez ní nefunguje nic dalšího. Baseline vznikne tak, že síť chvíli jen pozoruješ a zapíšeš si, co jsi viděl: které stroje spolu mluví, na kterých portech, kdy v průběhu dne, jak velké objemy dat a co je v síti vidět, i když nikdo nepracuje. Ta poslední položka je nejzajímavější. V simulátoru na to máš režijní provoz přímo před očima: ARP, DHCP a broadcast běží v pokročilém režimu pořád (sleduj panel Provoz & logy → Živý provoz) – i „prázdná" síť mluví bez přestání. Stanice se ptají ARP dotazem na MAC adresu k IP, klienti si obnovují zapůjčení adresy přes DHCP, switche a další prvky si posílají svoje zprávy. Tenhle šum patří k normálu a je potřeba ho znát – jinak ho jednou uvidíš, lekneš se a budeš hledat útok tam, kde žádný není. Praktické zásady tři. Baseline měř v klidném období, ne uprostřed migrace; sbírej ji alespoň přes celý týden, protože pondělní ráno a nedělní noc vypadají úplně jinak; a zapiš si ji, protože co je jen v hlavě, to za rok nikdo neobhájí. A počítej s tím, že baseline stárne: každý nový server, nová aplikace nebo změna procesu ji posune. Neaktualizovaný výchozí obraz vyrábí plané poplachy stejně spolehlivě jako příliš citlivé prahy.

Krok za krokem

Baseline je popis normálu: které stroje spolu mluví, na kterých portech, kdy během dne a jak velké objemy.
I „prázdná" síť mluví pořád: ARP, DHCP a broadcast. Tenhle režijní provoz patří k normálu – musíš ho znát.
Měř v klidném období, sbírej alespoň přes celý týden a zapiš si to – pondělí a neděle vypadají jinak.
Baseline stárne: každý nový server nebo aplikace ji posune. Neaktualizovaná vyrábí plané poplachy.

Anomálie: co vybočuje

S baseline v ruce se dá konečně ptát na to podstatné: co vybočuje? Anomálie není „něco zlého", je to odchylka od obvyklého – a teprve člověk rozhodne, jestli je za ní útok, porucha, nebo jen nová aplikace. Stojí za to znát pár typických tvarů. Nový partner: stroj, který dosud mluvil se třemi servery, se najednou baví s adresou, kterou nikdo nezná. Nový port: mezi dvěma stroji, které si celý rok vyměňovaly jen HTTPS, se objeví spojení na správcovský port. Nezvyklý čas: přenos deseti gigabajtů ve tři ráno v neděli. Nezvyklý objem: běžný tok, který je najednou stokrát větší nebo naopak úplně vyschl. Pravidelnost: spojení, které se ozývá přesně každých 60 sekund – lidé takhle přesní nejsou, stroje ano, a přesně takhle vypadá napadený stroj hlásící se svému řídicímu serveru. A záplava: prudký nárůst broadcastů nebo ARP dotazů, který zaplní linku – tam bývá příčinou spíš smyčka v topologii než útočník, ale síť to položí stejně. Dvě věci si z toho odnes. Zaprvé: anomálie je otázka, ne rozsudek. Správná reakce zní „proč se tohle děje?", ne „vypni to". Zadruhé: většina anomálií má nudné vysvětlení – nový kolega, nový nástroj, nová záloha – a to je v pořádku. Detekce, která nikdy nic nenajde, je stejně podezřelá jako ta, která hlásí všechno.

Krok za krokem

Nový partner: stroj, který mluvil se třemi servery, se najednou baví s adresou, kterou nikdo nezná.
Pravidelnost: spojení přesně každých 60 sekund. Lidé takhle přesní nejsou – napadený stroj hlásící se řídicímu serveru ano.
Záplava: prudký nárůst broadcastů nebo ARP dotazů. Bývá to spíš smyčka v topologii, ale síť to položí stejně.
Anomálie je otázka, ne rozsudek. Většina má nudné vysvětlení – nový kolega, nový nástroj, nová záloha.

▶ Otevřít v simulátoru

Lekce 5: Korelace: příběh z útržků

Jedna událost nestačí

Vezmi si jediný řádek z log serveru: „firewall zablokoval provoz z PC2 na server". Co z toho víš? Skoro nic. Může to být kolega, který si spletl adresu sdíleného disku. Může to být aplikace, která se po aktualizaci pokouší o spojení, jaké dřív nedělala. A může to být útočník, který si osahává, kam z obsazeného stroje dosáhne. Ta samotná událost je pro všechny tři případy stejná – a to je jádro problému, který řeší celá tahle lekce. Jednotlivý řádek nemá kontext, a proto se z něj nedá udělat rozhodnutí. Odpověď se jmenuje korelace: skládání více záznamů z různých zdrojů k sobě, dokud nevznikne příběh. Ptáš se tří věcí. Kdy: co se dělo těsně předtím a těsně potom? Kdo: objevuje se ten stroj i jinde, v jiných záznamech? Kolikrát: bylo to jednou, nebo padesátkrát za minutu? Jedno zamítnutí je omyl. Padesát zamítnutí za minutu na padesát různých cílů je rozhlížení po síti. Aby korelace vůbec šla dělat, potřebuješ dvě věci, které musíš zařídit předem. První je společný čas: když má každé zařízení hodiny o kus jinde, časová osa se rozpadne a příběh se poskládat nedá – proto se v síti nasazuje sjednocení času. Druhá je jedno místo, kde jsou záznamy pohromadě, tedy log server z první lekce. Bez těch dvou věcí zůstaneš u jednotlivých řádků, které nic neříkají.

Krok za krokem

„Firewall zablokoval provoz z PC2." Omyl kolegy, nová aplikace, nebo útočník? Ta událost je pro všechny tři stejná.
Korelace se ptá tří věcí: kdy (co bylo předtím a potom), kdo (kde jinde se stroj objevuje) a kolikrát.
Jedno zamítnutí je omyl. Padesát zamítnutí za minutu na padesát cílů je rozhlížení po síti.
Korelace stojí na dvou věcech předem: společný čas na všech zařízeních a jedno místo, kde jsou záznamy pohromadě.

Tři řádky, jeden incident

Podívejme se, jak korelace vypadá na konkrétním případu. V panelu se během několika minut objeví tři různé řádky a každý sám o sobě vypadá nevýrazně. 9:14 – IDS hlásí podezřelý provoz od PC2 (jak takový alert vzniká, znáš z kurzu Pokročilá bezpečnost (DPI, IDS/IPS)). Sám o sobě je to jeden alert z mnoha, a kdo zná únavu z alertů, přejde ho. 9:15 – firewall zablokoval provoz z PC2 na server. Sám o sobě je to jedno zamítnutí, a taková chodí denně. 9:17 – server je mimo provoz. Sám o sobě je to výpadek, na který se zavolá technik, a ten napíše „asi napájení". Tři různé zdroje, tři různé úrovně závažnosti, tři různí lidé, kteří se na to podívají – a nikdo z nich nevidí celek. Jakmile ale ty řádky postavíš na jednu časovou osu a všimneš si, že se ve dvou z nich opakuje stejný stroj, přestává to být trojice drobností: v rozmezí tří minut se objevil podezřelý provoz z konkrétní stanice, ta se pokusila o spojení, které jí bylo zamítnuto, a hned nato spadl server. To už není šum, to je incident, a zaslouží si postup, ne uzavření tří samostatných tiketů. Zapamatuj si dvě vodítka. Blízkost v čase a opakující se aktér jsou dvě nejlevnější a nejsilnější vodítka korelace – a obě jsou vidět pouhým okem, pokud máš logy na jednom místě. A ještě jedna zásada: souvislost v čase není důkaz příčiny. Korelace ti řekne, na co se podívat; jestli server spadl kvůli útoku, nebo shodou okolností, rozhodne až vyšetření.

Krok za krokem

9:14 – IDS hlásí podezřelý provoz od PC2. Sám o sobě jeden alert z mnoha; kdo zná únavu z alertů, přejde ho.
9:15 – firewall zablokoval provoz z PC2 na server. Sám o sobě jedno zamítnutí, a taková chodí denně.
9:17 – server je mimo provoz. Sám o sobě výpadek, na který se zavolá technik a napíše „asi napájení".
Na jedné časové ose se ve dvou řádcích opakuje stejný stroj. Ze tří drobností je incident – ale souvislost není důkaz příčiny.

SIEM: korelace ve velkém

Korelaci pro tři řádky zvládneš očima. Pro tři miliony řádků denně z padesáti zařízení už ne, a právě odtud se bere SIEM – nástroj, který sbírání a vyhodnocování záznamů dělá za tebe. Zkratka znamená správu bezpečnostních informací a událostí a v praxi dělá čtyři věci. Sbírá záznamy ze všech zdrojů, tedy je to log server z první lekce. Normalizuje je: každý výrobce píše logy jinak a SIEM je převede do společného tvaru, takže se dá hledat „všechna zamítnutí" napříč zařízeními od různých výrobců. Koreluje podle pravidel, která napíšeš: „alert od IDS a do pěti minut výpadek na stejném stroji" nebo „třicet selhaných přihlášení za minutu". A upozorní, když pravidlo sedne. Nic z toho není magie – je to přesně to, co jsi v předchozích dvou modulech dělal ručně, jen ve velkém a rychle. A právě proto stojí za to znát tři meze. Za prvé: SIEM vidí jen to, co mu pošleš. Zdroj, který neloguje nebo jehož záznamy blokuje firewall, v něm chybí a nikdo si toho nevšimne. Za druhé: SIEM koreluje podle pravidel, která napsal člověk – neumí najít to, na co nikdo nepomyslel. Za třetí: SIEM nic nevyřeší; vyrábí alerty, a když k nim nemáš lidi a postupy, koupil sis dražší způsob, jak se unavit z alertů. Pořadí kroků je proto pořád stejné: nejdřív sbírej na jedno místo, pak zaveď severitu a baseline, a teprve pak zvažuj nástroj.

Krok za krokem

SIEM sbírá záznamy ze všech zdrojů a normalizuje je – každý výrobce je totiž píše jinak.
Pak koreluje podle pravidel („alert a do pěti minut výpadek na stejném stroji") a upozorní, když pravidlo sedne.
Mez první: SIEM vidí jen to, co mu pošleš. Zdroj, jehož záznamy zastaví firewall, v něm prostě chybí.
Meze druhá a třetí: koreluje jen podle pravidel od člověka a sám nic nevyřeší – bez lidí a postupů je to dražší šum.

▶ Otevřít v simulátoru

Lekce 6: Monitoring v praxi

Co sledovat na zařízeních

Logy a toky říkají, co se v síti děje. Zbývá třetí pohled: jak se daří samotným zařízením. Tady nejde o bezpečnost, ale o provoz – a přesto se sem valná část incidentů promítne dřív než kamkoli jinam. Čtyři věci stojí za sledování a jsou to pořád tytéž. Stav rozhraní: je port nahoře, nebo dole? Spoj, který během dne desetkrát spadl a vstal, je horší než ten, co je poctivě dole – vypadá totiž, že funguje. Vytížení linky: dlouhodobě přetížený spoj se projeví jako „síť je pomalá", což je stížnost, se kterou se bez čísel nedá pracovat. Chybovost: rostoucí počet chyb na portu je typicky vadný kabel nebo konektor a bývá to jediné včasné varování, které dostaneš. A dostupnost služby: běží na serveru to, co běžet má? Sbírá se to nejčastěji přes SNMP – zavedený způsob, jak se sledovací systém zařízení ptá na jeho hodnoty (a jak mu zařízení umí samo poslat upozornění, když se něco stane). Rozdíl proti syslogu si zapamatuj takhle: syslog zařízení vypráví, co se stalo, SNMP se ho ptá, jak na tom je. K tomu jedna bezpečnostní poznámka, protože SNMP je stará technologie: starší verze posílají údaje nešifrovaně a chrání je jen sdílené heslo, které bývá výchozí. Sledování patří do správcovské sítě, ne mezi běžný provoz – jinak si z monitoringu uděláš pohodlný zdroj informací pro útočníka.

Krok za krokem

Stav rozhraní: spoj, který během dne desetkrát spadl a vstal, je horší než ten poctivě dole – tváří se, že funguje.
Vytížení linky se projeví jako „síť je pomalá". A rostoucí chybovost na portu je typicky vadný kabel.
Sbírá se to přes SNMP. Rozdíl: syslog vypráví, co se stalo, SNMP se ptá, jak na tom zařízení je.
Starší SNMP posílá údaje nešifrovaně a chrání je jen sdílené heslo. Sledování patří do správcovské sítě.

Nástraha jako čistý signál

Celý kurz zatím bojoval s jedním problémem: odlišit signál od šumu. Prahy se ladí, baseline stárne, plané poplachy otravují. Existuje ale jeden druh signálu, který je čistý ze své podstaty – nástraha (honeypot). Podrobně ji rozebírá kurz Zero Trust a mikrosegmentace v lekci „Předpokládej průnik"; tady se dívám na to, co znamená pro monitoring. Je to zařízení nebo služba, která v síti stojí bez jakéhokoli legitimního účelu: falešný souborový server, falešné správcovské rozhraní, adresa, kterou žádná aplikace nezná. Nikdo do ní nemá důvod sáhnout. Právě proto je každý přístup k ní podezřelý a nepotřebuješ k tomu žádné prahové hodnoty ani baseline – hranice je nula. Pro monitoring je to nejlevnější dobrý alert, jaký si můžeš pořídit. Praktické zásady jsou tři a všechny jsou důležité. Za prvé: nástraha musí být izolovaná a nesmí mít cestu jinam – jinak sis do sítě přinesl slabě zabezpečený stroj, který útočníkovi poslouží jako odrazový můstek. Za druhé: nesmí obsahovat nic cenného, protože počítáš s tím, že se k ní někdo dostane. Za třetí: musí být napojená na sběr logů a někdo se na to musí dívat, jinak si vyrobíš past, která se sklapne v prázdné místnosti. A jedna střízlivá poznámka na závěr: nástraha nikoho nezastaví. Nechrání data, neblokuje útok, nenahradí segmentaci ani pravidla. Je to včasná výstraha, nic víc – ale výstraha, u které skoro nemusíš přemýšlet, jestli je planá.

Krok za krokem

Celý kurz bojuje s jedním: odlišit signál od šumu. Prahy se ladí, baseline stárne, plané poplachy otravují.
Nástraha je zařízení bez jakéhokoli legitimního účelu: falešný server, falešná správa, adresa, kterou nikdo nezná.
Nikdo tam nemá důvod sáhnout, takže každý přístup je podezřelý. Žádné prahy, žádná baseline – hranice je nula.
Musí být izolovaná, bez cenného obsahu a napojená na sběr logů. Nikoho ale nezastaví – je to jen včasná výstraha.

Kontrolní seznam monitoringu

Poslední modul je praktický: kontrolní seznam, který si můžeš projít na vlastní síti nebo na topologii v simulátoru. Je rozdělený do čtyř okruhů a záměrně je krátký, protože seznam, který se nedá projít za dvacet minut, si nikdo neprojde. Sběr. Máš v síti log server? Posílají na něj záznamy všechna aktivní zařízení – firewall, router, switch, IDS – a ne jen ta, na která si někdo vzpomněl? Mají zařízení sjednocený čas, aby se dala poskládat časová osa? Cesta. Dostane se hlášení z každého segmentu na log server, tedy je port 514 povolený i po posledním zpřísnění pravidel? Ukazuje panel Syslog nula ztracených událostí? Mlčí některý segment, aniž bys věděl proč? Obsah. Loguješ zamítnutí, alerty, změny stavu a selhaná přihlášení – a naopak neloguješ hesla ani obsah zpráv? Má každá kritická událost napsaný postup, co s ní? Pozornost. Dívá se na hlášení opravdu někdo, nebo jen padají do složky? Kolik procent alertů vedlo k akci? Znáš svou baseline a kdy se naposledy aktualizovala? Poslední rada, kterou je dobré si odnést z celého kurzu: monitoring není projekt s koncem. Nová aplikace, nové pravidlo, nový segment – každá změna sítě je i změnou toho, co vidíš a co ne. Proto se seznam prochází pravidelně, ne jednou při zavádění. A když z celého kurzu zůstane jediná věta, ať je to tahle: co nesbíráš, to nevidíš, a co nevidíš, to nevyšetříš.

Krok za krokem

Sběr: máš log server? Posílají na něj všechna aktivní zařízení? Mají sjednocený čas?
Cesta: dostane se hlášení z každého segmentu na server? Je port 514 povolený i po zpřísnění? Je ztracených nula?
Obsah: loguješ zamítnutí, alerty, změny stavu a selhaná přihlášení – a neloguješ hesla? Má kritická událost postup?
Pozornost: dívá se opravdu někdo? Kolik alertů vedlo k akci? Co nesbíráš, to nevidíš – a co nevidíš, to nevyšetříš.

▶ Otevřít v simulátoru