Software vyvíjený týmem CESNET, Masarykovy univerzity a Flowmon Networks vám tyto a mnohé další problémy pomůže odhalit.
Útoků přibývá, stejně tak i dat
V dnešní době jsme neustále svědky velkých útoků směřujících na infrastrukturu Internetu a jeho základní služby, vzpomeňme například na nedávný útok na DNS servery společnosti Dyn, díky čemuž byly pro mnohé uživatele nedostupné další populární webové služby jako Twitter, PayPal a další. Kromě těchto velkých útoků probíhají i cílené útoky s velmi nízkou intenzitou provedené na míru dané oběti. Cílem těchto útoků jsou buď zajímavé informace (např. výrobní plány) nebo další zdroje, které budou použity pro větší útoky. Monitoringem síťového provozu získáme nejen možnost detekce těchto útoků, ale i přehled o rozsahu a dopadech útoků. Síťový monitoring tak poskytuje administrátorovi důležité informace, které je obtížné získat přímo monitoringem serverů, například právě proto, že je server kompromitován, nebo je obětí DoS útoku a nedostávají se mu hardwarové zdroje pro monitoring, nebo je server pod správou třetí strany.
Pro účely síťového monitoringu jsou informace o dění v počítačové síti nejčastěji získávány ve formě záznamů o síťových tocích. Síťový tok je proud paketů, které zaslal odesílatel příjemci. Záznamy o tocích jsou sbírány pomocí monitorovacích zařízení, tzv. síťových sond, umístěných na významných bodech v počítačové síti. Naměřené záznamy například obsahují počet přenesených paketů, bytů mezi dvěma počítači v síti, a jsou shromažďovány v centrálním úložišti, tzv. kolektoru, kde slouží pro sledování vytížení sítě a služeb, dále pak pro detekci a dohledávání incidentů. Kolektor je tak často využíván administrátory jako zdroj dat pro zjištění problémů v síti, dohledání jejich příčin a následků.
Vzhledem ke stále většímu množství zařízení, která jsou online (např. mobily, televize), roste diverzita a objem síťového provozu. Cisco predikuje růst objemu [PDF] provozu v datových centrech o 25 % každý rok. Síťoví administrátoři tak čelí potřebě zpracovat velké množství dat, ve kterých hledají pověstnou jehlu v kupce sena. Například za jeden den je potřeba zpracovat přibližně 250 GB záznamů, které vzniknou měřením vytížené stogigabitové linky. Bohužel současná řešení kolektorů nedovolují distribuci úlohy kolektoru na více strojů, naráží tak na strop výkonnosti jednoho serveru a dochází k zahazování či vzorkování dat právě v okamžicích, kdy jsou tato data nejvíce důležitá. Typicky je například velké množství záznamů ukládáno na kolektor v době skenování či DDoS útoku. Pro útočníka se tím nabízí příležitost maskování cíleného útoku s podstatným dopadem jiným velkým útokem, který ani nemusí představovat hrozbu pro danou oběť. Pro monitoring velkých sítí (např. velkých ISP či operátorů) tak chybí škálovatelné řešení.
Big data: ano i ne
Jako zajímavá platforma kolektoru se jeví využití dnes velmi populárních frameworků pro práci s velkým objemem dat tzv. Big Data. Mezi ty nejznámější patří například Hadoop, ElasticSearch, Spark a další. Nicméně testy těchto platforem v úloze kolektoru, tedy potřeba průběžně přijímat velké množství dat, zpracovávat tato data a dotazovat se ad hoc nad velkým objemem dat, ukázaly, že většina těchto řešení má velmi vysokou režii a značné problémy v rychlosti ukládání dat do úložiště. Například Hadoop při dotazování nad uloženými daty vykazuje režii přibližně 15 sekund, která je způsobena komunikací mezi uzly a tuto režii se ani přes naše snahy nepodařilo významně snížit.
Režie představuje problém v situaci, kdy jsou kromě velkých dotazů pokládány dotazy i nad malým množstvím dat, kde uživatel intuitivně očekává velmi rychlou odezvu. Jako příklad velkého dotazu lze uvést dohledání kompromitace zařízení, kdy je nutné projít data za dlouhý časový úsek a naopak jako příklad malého dotazu vyhledat zařízení, které v konkrétní pětiminutovce nejvíce přispívalo k úspěšnému útoku, kde odpověď je běžně dostupná na současném řešení za méně než jednu sekundu.
Samotný příjem, zpracování a průběžné ukládání velkého proudu dat je u frameworků problémem, neboť při jejich návrhu bylo často předpokladem, že doba nahrávání dat do frameworku není tím pověstným úzkým hrdlem. Například u ElasticSearch se nám nepodařilo dosáhnout rychlejšího vkládání než 30 tisíc záznamů za vteřinu na cluster tří výkonných strojů, zatímco současné kolektory běžící na jednom uzlu zvládají uložit kolem 300 tisíc záznamů za vteřinu. Charakter práce s kolektorem je takový, že záznamy nutné průběžně uložit tak rychle, jak přicházejí. Nad uloženými daty pak můžeme položit jakýkoliv dotaz s dosahem do historie až v řádu jednotek měsíců, nicméně většina takto uložených dat se nikdy nepoužije, respektive, to zda se použijí či nepoužijí, ovlivní až konkrétní události a problémy v dané síti.
Naše zkušenosti s frameworky pro velká data ukazují, že se začínají vyplácet, pokud potřebujeme pracovat s velkým množstvím dat neustále, abychom mohli tolerovat režii frameworku. Navíc tyto frameworky byly budovány s cílem spravovat desítky až stovky strojů a s nutností čelit neustálým výpadkům i v průběhu výpočtů, což dále přispívá k jejich režii. Nicméně u kolektoru se typicky počítá se škálováním na jednotky strojů a vysokou efektivitou zpracování dat na každém z těchto strojů.
Jednoduché a efektivní
Z výše uvedených důvodů se tým vědců a vývojářů CESNETu, Masarykovy univerzity a Flowmon Networks rozhodl postavit vlastní řešení kolektoru nazvané SecurityCloud kolektor. SecurityCloud kolektor je distribuovaný jak na úrovni jader CPU, tak na úrovni uzlů. Oproti dřívějším řešením, která nebyla schopná využívat více jader, je tak možné dosáhnout zrychlení i při zpracování dat na jednom stroji. Na rozdíl od Big Data frameworků, SecurityCloud toleruje výpadek pouze jednoho uzlu, což ale spolu s implementací v jazyce C/C++ vede k efektivnímu využívání dostupných výpočetních zdrojů.
Řešení využívá modelu master/slave, kde master uzel nazýváme proxy a slave uzly nazýváme subkolektory. Data o síťových tocích ze sítě přicházejí na proxy uzel, který je přeposílá na subkolektory, které tato data ukládají. Dotaz nad daty je položen na proxy uzlu. Proxy uzel tento dotaz předá subkolektorům. Subkolektory dotaz zpracují a vrátí dílčí výsledky na proxy uzel, který následně sestaví finální výsledek.
Odolnost proti výpadku subkolektoru je zajištěna úpravou přeposíláním dat z proxy a průběžným duplikováním dat na sousední subkolektor. V případě výpadku proxy dojde k migraci proxy buď na subkolektor, který se stane novou proxy, či na záložní dedikovanou proxy. Jako technologii pro řešení odolnosti používáme GlusterFS pro správu úložiště a Pacemaker pro management úloh kolektoru běžících na jednotlivých uzlech a Corosync pro migraci proxy.
Další úlohou kolektoru je průběžná analýza síťových dat za účelem detekce útoků a anomálií. V této oblasti jsme zvolili paradigma proudového zpracování dat oproti dřívějšímu zpracování dat v pětiminutových dávkách. Vzhledem k novému konceptu rozvíjíme dvě implementace, jednu prototypovou založenou na nástroji Apache Spark, a druhou realizační s vysokou efektivitou.
Prototypová implementace s názvem Stream4Flow reprezentuje platformu pro distribuované proudové zpracování síťových dat. Jádro platformy tvoří nástroj Apache Spark, který umožňuje v téměř reálném čase zpracovávat velké množství dat a je v současné době využíván pro zpracování dat ve velkých společnostech, jako jsou Yahoo!, Baidu nebo NASA. Stream4Flow umožňuje rychlé prototypování detekčních metod a díky interní reprezentaci dat je schopný poskytnout informace o dění v síti na úrovni jednotlivých zařízení v síti.
Další implementací detekčního systému vyvíjeného pro SecurityCloud je Nemea. Jedná se o sadu modulů, které je možné zapojovat do série či paralelně a skládat tak komplexní detekční systém. Jednotlivé moduly spolu transparentně komunikují přes síťový soket po síti či unixový soket v rámci lokálního uzlu. Aktuálně existující moduly pak dokáží detekovat skenování, DDoS útoky, hádání hesel, zneužití IP telefonie a další problémy.
SecurityCloud kolektor běžící na třech výkonných uzlech dovoluje zpracovat dotazy nad uloženými záznamy rychlostí přibližně 100 mil. záznamů za vteřinu (v nejhorším případě, tj. pokud nelze využít index). Tato výkonnost je více než dostatečná pro pokrytí potřeb páteřní sítě, jakou je například síť CESNET2. Kolektor nám tak například umožnil prohledat data za poslední tři měsíce a dohledat stroje, na kterých byl nainstalován spyware, který odesílal URL zadanou uživatelem v prohlížeči na botnet situovaný v Rusku.
Závěrem
Výsledky projektu integruje společnost Flowmon Networks tak, aby se v roce 2017 staly součástí řešení Flowmon, které nabídne robustní distribuovanou architekturu a vysokou dostupnost. Prototypové komponenty kolektoru uvolněné jako open source můžete najít na github SecurityCloud, Stream4flow a Nemea. Projekt byl podpořen Technologickou Agenturou České republiky.
