Monitoring sítě pomocí sond a zpracování logů s LLM, BSS 2026

Martin Žádník: Použití ML a LLM ve zpracování logů

Logy jsou hlášení ze služeb, aplikací, systému či zařízení, která jsou sbíraná lokálně na zařízení nebo se odesílají na vzdálené úložiště k dalšímu zpracování. Často obsahují velmi užitečné informace, protože popisují to, jak celý proces probíhá a zda se dějí nějaké problémy. Může jít o stovky gigabajtů denně a chceme je uchovat a vše analyzovat s rozumnými hardwarovými a lidskými zdroji.

Logy jsou často nestrukturované a pocházejí z mnoha různých zařízení. I pro jeden typ zařízení se mohou logy lišit dle nasazení. Musíme tedy nestrukturovaná data převést do strukturované podoby pomocí syntaktické analýzy a šablonovacího systému. Při sémantickém parsingu se k měnícím se částem záznamů přidává ještě sémantika.

Abychom nenutili uživatele psát předpisy pro zpracování logů ručně, můžeme využít techniky umělé inteligence. V síti se může nacházet nějaké zařízení, které není příliš obvyklé a my z něj chceme přesto sbírat logy. Můžeme položky ze šablony a taxonomie zakódovat do vektorového prostoru, ve kterém můžeme hledat největší podobnost.

Vytvoří se nám slabě anotovaná datová sada, která bude říkat, co která položka znamená. Tuto sadu pak použijeme v konceptu Name Entity Recognition, kdy se snažíme natrénovat LLM tak, aby podle kontextu pojmenovával jednotlivé položky a řadil je do kategorií. Na základě toho pak můžeme vygenerovat předpis pro dané zařízení. Uživatel pak může předpis zkontrolovat, nebo ho upravit, pokud se mu na něm něco nezdá.

Tento přístup dosahuje velmi dobrých výsledků ve strukturálním i sémantickém parsingu. Sbíráme metriky a měříme, jak přesně jsme schopni sbírat data a seskupovat je mezi šablonami. Snaha je mít vše co nejpřesnější, ale filosofie je nepovažovat jazykové modely za všespásné, ale používat je jako nástroj.

Podobně je možné strojové učení použít i k automatickému rozpoznávání typů logujících zařízení v síti. Můžeme ručně udržovat seznam zařízení a jejich IP adres, ale to se může v čase měnit. Pokud se sledují správné logy, pohybuje se přesnost klasifikace mezi 90 a 95 procenty. Uživatel takto nemusí vědět, co mu kde běží a systém jednotlivá zařízení rozpozná sám.

Pokud se v lozích objeví nějaký problém, chceme uživatele informovat. Obvykle je pro to potřeba předem napsat složitá pravidla v doménově specifickém jazyce. To není příliš uživatelsky přívětivé. Příjemnější je v přirozeném jazyce popsat, o jaká oznámení bychom měli zájem. Používáme to jako prototypovací nástroj pro uživatele.

Jakub Cabal: Zvládání vysokokapacitních linek pomocí hardwarové akcelerace

Potřeba přenášet stále větší množství dat neustále roste a sítě se rychle vyvíjejí. Včera jsme tu měli 100Gb, dnes máme 400Gb a možná už zítra budeme mít 800Gb. Všechno tedy už nemůžeme nechat na procesoru, neustále klesá čas na zpracování každého paketu. U nejvyšších rychlostí je už pod jednou nanosekundou, což není moc času. Proto je nutné nasadit specializovaný hardware.

Alespoň část práce tedy musíme provést na kartě s FPGA, část paketů úplně odfiltrovat a provést parsování síťových toků až na čtvrtou vrstvu. Začátek provozu pak můžeme poslat k analýze do procesoru a o zbytku si nechat jen počítat statistiku.

FPGA je programovatelné hradlové pole, tedy spousta malých logických elementů schopných implementovat logickou funkcí. Vše propojuje matice, kterou můžeme konfigurovat a připravit si tak libovolné funkce. Výhodou je flexibilita, protože konfiguraci můžeme snadno měnit a přidávat nové funkce třeba pro parsování nového protokolu.

Nejdražší FPGA čipy mají zabudované specializované bloky pro vysokorychlostní rozhraní, včetně 400Gb Ethernetu a PCIe Gen5 x16. Protože to nemusíme implementovat my, můžeme celé hradlové pole využít pro vlastní funkce karty. CESNET dlouhodobě vyvíjí vlastní platformu NDK (Network Develipment Kit) pro vývoj akcelerovaných síťových aplikací na FPGA.

Uvnitř FPGA sondy probíhá generování časových značek, parsování paketů, filtrace, výpočet RSS hašů, distribuce paketů na jednotlivá výpočetní jádra, počítání statistik flow a přenos paketů do RAM hostujícího PC pomocí DMA. V počítači je pak dostupný linuxový ovladač, který pomocí vlastního NDP API, DPDK nebo XDP předává data ke zpracování open-source nástroji ipfixprobe.

Před vývojáři stál před časem úkol aktualizovat na 400 Gb, protože se počítalo s nasazením této rychlosti v síti CESNET. Museli jsme na to být připraveni předem, aby nám pak síťaři sondu neodpojili. V roce 2021 už byly k dispozici první vhodné FPGA čipy, ale neexistovala žádná dostupná karta. Začal tedy vývoj vlastní karty postavené na nejnovějším čipu z řady Intel Ailex 7 s podporou rozhraní 400Gb Ethernetu a PCIe Gen5.

Bylo potřeba také rozšířit datové sběrnice, aby firmware zvládal čtyřnásobný datový tok. Sběrnice se rozšířila na 2048bitů, což ale znamená, že se v jednom taktu do karty dostanou až čtyři pakety. Nestačilo tedy jen změnit nějaké parametry ve firmwaru, ale museli jsme celou logiku přepsat. Bylo potřeba vyřešit problémy s časováním a použít víceportové paměti pro paralelní zpracování více paketů.

Současná karta téměř zvládne zpracovat 400 Gb, ale PCIe se ukazuje jako úzké hrdlo, zejména u nejkratších paketů. Hodně toho ovlivňuje i řadič paměti a další limity. Pomáhá použití rozhraní PCIe v režimu bifurkace, jenže některé servery jsou vybíravé a karty v tomto režimu vůbec nevidí.

Sondy s podporou 400 Gb byly do ostrého provozu úspěšně nasazeny v roce 2025. V plánu je začít aktivně používat zpracování flow statistik a použití přesných časových značek pomocí protokolu White Rabbit. Zároveň se připravujeme na 800Gb linky, což bude znamenat extrémní optimalizace ve firmwaru a nové přístupy. První čipy s podporou 800 Gb budou snad k dispozici v roce 2027.

Lukáš Huták: přesná open-source sonda a kolektor

V síti potřebujeme sbírat agregovaná data o tom, kdo s kým komunikoval, kolik dat přenesl a jakým protokolem. Tato data pak musíme zpřístupnit správci, který je může v případě potřeby analyzovat. Typicky nás nezajímají surová data, ale chceme vidět obrázky, grafy a trendy.

CESNET využívá vlastní open-source sondu ipfixprobe, která je pasivní, na síti pouze poslouchá a není možné ji detekovat. Sonda zachytává nevzorkovaný provoz a z vybraných protokolů dokáže sama získat zajímavé informace: na jaký port se uživatel připojoval, jaké DNS dotazy pokládal a podobně. Sonda je velmi flexibilní, dokáže běžet na 1Gb, ale i na 400Gb linkách. Jde o vícevláknovou aplikaci připravenou pro vysokorychlostní zpracování.

Správce se při nasazení musí v prvním kroku rozhodnout, kam sondu nainstaluje. Je možné ji umístit na jeden server uvnitř sítě pro sledování interního provozu nebo na perimetr celé sítě. Pak vidíte vše, co vám přichází z internetu, ale musíte si dát pozor na NAT omezující pohled na zdroje a cíle komunikace ve vaší síti.

Provoz můžeme do sondy dostat obvykle pomocí pasivního optického prvku TAP, který část signálu odkloní směrem do sondy. Alternativou je použití zrcadlení pomocí SPAN na prvku vyšší vrstvy, ale zde je potřeba dát pozor na dostatečný výkon prvku. Poté se na monitorovacím serveru data dostanou do sondy pomocí rozhraní jako AF_PACKET, AF_XDP, DPDK nebo jiného proprietárního API. Platí přímá úměra, že čím rychlejší rozhraní, tím hůře se nasazuje.

Sonda pouze přijímá data, provádí parsování provozu a rozdělení na jednotlivé síťové vrstvy, zápis do flow keše a uchovávání potřebných informací. Jakmile máme informaci o tom, že je tok uzavřen, můžeme sběr dat o něm ukončit a poslat informace na kolektor.

Pro zvládnutí vyšších rychlostí je potřeba paralelizovat, protože výkony procesorů nerostou hrubou frekvencí, ale přidáváním jader. Tomu je třeba se přizpůsobit na softwarové úrovni. Na 100Gb linku nám stačí 16jádrový procesor, pro 400 Gb provozu už potřebujeme 60 jader.

Sondy si neporadí s masivními DDoS útoky nebo velkými skeny. Když to nezvládá infrastruktura, jak by to mohla zvládat sonda? Při malých 64bajtových paketech se zahltí export a flow keš, takže pak dochází k degradaci kvality měření.

Je třeba také dát pozor na kompatibilitu sond a kolektorů, kde jsou standardizované jen základní položky, naopak ty aplikační jsou proprietární. Výhodou open-source sondy je, že si ji můžete libovolně upravit podle potřeb kolektoru.

Jako kolektor je možné použít ipfixcol2, který řeší příjem dat pomocí různých protokolů jako NetFlow, IPFIX nebo Biflow. Data je pak možné posílat do dalšího procesního nástroje jako Kafka či ClickHouse nebo data odesílat na další sub-kolektory. Je to takový průtokáč, který má na jedné straně vstup a na druhé straně výstup do míst, kde chcete data ukládat.

Jaroslav Pešek: RETINA kolektor

RETINA je nástroj pro manuální analýzu informací o datových tocích. Používá nejen data o samotném provozu, ale i další zdroje dat například z DNS, informace o IP adresách nebo podrobnosti získané z TLS certifikátů. Díky pokročilým sondám jsme schopni získat spoustu podrobností, které jsou při analýze velmi cenné.

Analýza dat naráží na problémy s asymetrickým směrováním, které se projevuje jako dvě různá flow. Takového směrování není málo, ve velké síti ho může být klidně i deset procent. Když pak vykreslujeme grafy, máme pokřivený pohled na svět. Dalším problémem jsou duplikujícící se flows z více sond.

Tyto problémy je možné řešit pomocí agregace biflow na základě vybraných položek, případně je možné využít heuristickou deduplikaci. Tyto transformace nějakou dobu zaberou, v analýze můžeme výsledek vidět i za několik desítek sekund. Tyto operace proběhnou ještě před uložením do databáze, zároveň jsou data obohacena o další informace jako GeoIP, otagování podle prefixů známých organizací, doplnění ASN či informace o vybraných službách.

Kromě analýzy probíhající v databázi, je možné provádět také detekce v reálném čase. Posílání do databáze vytváří zpoždění a analýza také znamená další zátěž. Proto je možné pomocí jednoduchých SQL dotazů sledovat živý provoz paralelně s tím, jak je ukládán do databáze. V tu chvíli je možné provádět jednodušší detekce postavené například na blocklistech. Pokročilejší detektory pak běží později nad databází.

Do těchto činností je možné zapojit také jazykové modely, zatím jde o první nesmělé testovací krůčky. Je možné vytvářet pravidelná textová shrnutí situace za poslední období, případně automaticky detekovat anomálie. Zatím si s tím jen hrajeme, nemáme to nikde v produkci nasazené.

David Kežlínek: PANDDA aneb monitorování sítě jednoduše a prakticky

PANDDA je webový konfigurátor, který pomáhá s nasazením celé monitorovací infrastruktury. Ta se skládá ze sond sbírajících a obohacujících data a kolektoru sbírajícího a ukládajícího flows.

Užitečnou funkcí je ADiCT, což je systém pro pasivní inventarizaci sítě. Místo aktivního sledování jen skenujeme provoz a na jeho základě provádějí inventarizaci. Nevýhodou je, že takto nevidíte zařízení, která nekomunikují. Takto je možné odhalit IP adresy zařízení, otevřené cílové porty podle zaznamenané komunikace a lze detekovat také vybrané komunikační protokoly.

Webové rozhraní slouží k nasazení monitorovací infrastruktury, vše probíhá postupně krok za krokem. Po instalaci se vás PANDDA nejprve zeptá na hlavní heslo, kterým se šifrují všechny citlivé údaje. Následuje předání přihlašovacích údajů k SSH, pomocí kterého se bude vše vzdáleně nasazovat. Poté vyberete IP rozsah, který vás zajímá, a už můžete přidávat jednotlivé instance. Můžete se pak podívat, jak probíhá nasazení pomocí Ansible a je hotovo.

V uživatelském rozhraní pak v desetiminutových intervalech naskakují informace o jednotlivých zařízeních, jeho IP adresách, otevřených portech a třeba také varování o otevřených DNS resolverech. Můžete se také podívat na grafy, které například ukazují, jak moc dat odchází z vybraného rozsahu.

Václav Bartoš, Pavel Valach: HUGO Honeynet – nasazení honeypotu a sdílení dat snadno a rychle

Honeypot je zařízení, které simuluje službu připojenou do sítě, láká útočníky a umožňuje sledovat jejich aktivitu. Pokud je honeypotů více, jsou sdruženy do honeynetu. Existuje mnoho různých implementací takových nástrojů, které se liší podle kvality simulace služby a účelu.

Projekt HUGO využívá open-source implementací různých nástrojů jako Cowrie a Dionaea a v plánu je rozšířit jej o další protokoly. Sdílení dat je integrováno přes existující systém Warden. Je tam doplněný i monitoring a vše je připravené pro jednoduché nasazení a správu. Vše je zabaleno do jednoho virtuálního počítače, případně je možné nasazení provést pomocí sady dockerových kontejnerů.

V tuto chvíli je HUGO nasazen v 16 sítích nemocnic, univerzit, veřejné správy a komerčních firem. Máme tři nasazení v zahraničí a budeme rádi za někoho dalšího, kdo bude ochoten provozovat honeypot ve své síti. Po dohodě s CESNET-CERTS stačí spustit virtuální stroj, přiřadit mu veřejnou adresu, připojit ho ke sběru dat a pak na něj můžete zapomenout.

Systém sbírá IP adresy útočníků, zkoušená jména a hesla a prováděné příkazy. To je pro nás užitečné, protože jsme schopni získat například URL pro stahování malware, případně přímo jeho vzorky. Ve většině případů se útočníci zkoušejí jen přihlásit, v malém procentu zadají i nějaké příkazy a zkusí stáhnout vlastní kód.

Útočníci se zhruba před půl rokem naučili zneužívat některé honeypoty bez nastavených limitů pro DDoS útoky na další stroje. Nám to nevadilo, protože jsme měli na firewallu implementovaný limit na odchozí spojení. Teď už má ochrany v kódu implementované přímo i Cowrie.

Data z těchto honeypotů se pak sbírají v několika systémech, mezi které patří i systém pro reputaci IP adres, URL evaluator pro zjišťování podrobností o používaných adresách nebo třeba do SIEM Mentat. Ten zákazníci sítě CESNET znají, dá jim vědět, pokud jejich adresa dělá něco podezřelého.

(Autorem fotografií je Petr Krčmář.)