Obecné povědomí o tzv. datových tocích (reprezentovaných standardy NetFlow, IPFIX, a dalšími) je v IT komunitě již řadu let. Tato technologie standardně nachází uplatnění v segmentu telco, například při účtování datových služeb, plánování kapacity sítě nebo při ochraně před útoky typu DDoS. V poslední době roste zájem o flow data také v segmentu enterprise, především ze strany IT manažerů a CIO, které oslovuje jejich potenciál pro správu sítí a jejich ochranu. Rychlejšímu přijetí této technologie však brání řada mýtů a nepřesností. Podívejme se na čtyři nejčastější.

Mýtus č.1 - Flow data jsou samplována a vysoce nepřesná

Tvrzení z titulku platí pouze u starších standardů sFlow nebo NetFlow lite, které jsou podporovány na vysloužilých zařízeních. Všichni významní výrobci síťových prvků v segmentu enterprise dnes nabízejí routery a switche, které generují nesamplované a vysoce přesné statistiky síťového provozu. Také všichni významní dodavatelé firewallů podporují získávání vysoce přesných informací o datovém provozu ve formě toků. Dokonce i cenově dostupná zařízení, jako jsou například routery Mikrotik, umí takto přesné statistiky dodávat. 


Aby bylo možné datové toky zpracovat, uchovávat a analyzovat je potřeba tzv. kolektor. Díky němu lze vizualizovat i provoz uvnitř sítě, tzv. east-west provoz, čímž operátor získává lepší představu o využití jednotlivých uplinků v různých lokacích. Mezi další důležitá využití patří řešení síťových incidentů. Projděme si následující situaci. Uživatel nahlásí, že má při připojování k serveru prostřednictvím služby SSH potíže. Pomocí flow dat můžeme snadno potvrdit, že uživatel neobdržel žádnou odpověď. Tím jsme úspěšně vyloučili řadu potenciálních příčin, jako je například odstávka serveru, sítě nebo chybná konfigurace. Rozsah příčin byl tedy razantně zúžen – chyba je generována nespuštěnou službou nebo firewallem blokujícím komunikaci. Celý proces tak výrazně snížil čas k vyřešení problémů (MTTR).

OBR.1: Komunikace uživatele s externí službou. Host neobdržel žádnou odpověď.

Mýtus č. 2 - Flow je omezeno viditelností vrstvy L3 a L4

Dříve byla flow data omezena pouze na informace z vrstvy L3 a L4. Aby bylo srozumitelné, o čem je řeč, je třeba říci, že statistiky o síťových tocích sledují start a cíl každého paketu, přičemž poskytují informace (metadata) o této datové komunikaci: zdrojovou a cílovou adresu, zdrojový port, cílový port a komunikační protokol. Tyto pakety se agregují do flow statistik (záznamů), které ukazují informace o množství přenášených dat, počet přenesených paketů a další informace z vrstvy L3 a L4. Nicméně, před více než šesti lety jsme přišli s konceptem, který základní model obohacuje o informace z aplikační vrstvy L7. Tento koncept byl již široce přijat mnoha výrobci. Tzn. že dnes již není problém s detailní viditelností aplikačních protokolů, jako je HTTP, DNS, DHCP a dalších. Faktem je, že to posouvá řešení síťových incidentů na zcela novou úroveň.


Opět si představme příklad. Uživatel si stěžuje na nereagující službu. Analyzováním standardních dat se zdá být vše v pořádku. Ale nevidíme žádný provoz směrem k službě. Díky rozšířené viditelnosti – poskytované obohacenými datovými toky – jsme snadno zjistili proč. Požadovaný název služby není ve službě DNS správně nakonfigurován a vrátí "NXDOMAIN", což znamená, že požadovaný název domény neexistuje a nemůže být poskytnuta odpovídající adresa IP. Proto nebyla vytvořena žádná relace.

OBR. 2: Filtrování DNS provozu a pátrání po chybě NXDomain.

Mýtus č. 3 - Flow data postrádají informace o výkonu sítě

Kromě řešení síťových incidentů se technologie datových toků využívá také k monitorování výkonu sítě. Síťový monitoring nezajišťují totiž jen SNMP nástroje nebo nástroje pro zachytávání paketů v plném rozsahu. Výkonnostní ukazatele lze snadno získat z hlaviček paketů a exportovat je jako součást flow statistiky. Ukazatele výkonu sítě, jako jsou například RTT (round trip time), SRT (server response time), jitter nebo počet opakovaných přenosů (retransmise), jsou dostupné pro veškerou síťovou komunikaci bez ohledu na aplikační protokol. S ohledem na tyto výhody přijali tento přístup také významní dodavatelé. To znamená, že můžeme měřit výkon všech provozovaných aplikací v prostředí on-premise, v private cloudu stejně jako v public cloudu. Pro lepší pochopení toho, jak tyto informace získáváme, poslouží příklad výkonnostního monitoringu sondami Flowmon (viz obr. níže).

OBR. 3: Princip NPM měření sondou

Mýtus č. 4 - Flow není komplexní nástroj pro monitorování a diagnostiku sítě (NPMD)

Podle analytiků společnosti Gartner by nástroje NPMD měly poskytovat výkonnostní ukazatele vycházející z informací ze záchytu paketů v plném rozsahu a schopnost řešit síťové incidenty analýzou těchto záznamů. Avšak skutečně potřebujeme zachytávat pakety v plném rozsahu? Nikoliv. Flow data poskytují přesné statistiky síťového provozu, viditelnost do aplikační vrstvy L7 a ukazatele výkonu sítě, takže plně postačují pro uplatnění v oblastech definovaných segmentem NPMD.



Ve skutečnosti se s nárůstem šifrovaného provozu, s ohledem na různorodé prostředím a zvyšující se rychlost sítě stávají flow data preferovaným přístupem v oblasti NPMD. Zejména rostoucí šířka pásma je něco, čemu musí čelit paketová řešení. Podívejme se na jednoduchý příklad. Páteřní síť s 10G kapacitou vyžaduje pro sledování síťového provozu po dobu 24 hodin úložiště o velikosti až 108 TB. Jedná se obrovské množství dat, které je potřeba shromažďovat, ukládat a analyzovat, což činí celý tento proces extrémně drahý.

 

Přitom skutečně potřebujete jen zlomek těchto dat. Flow data vyžadují ve stejné situaci úložiště velké zhruba 250 GB. To umožňuje držet 30denní historii na kolektoru s kapacitou jen 8 TB. Využitím flow dat dokážete držet síťové operace na maximálním výkonu, stejně tak jako řešit a odstraňovat síťové incidenty, a to se zlomkem potřebných zdrojů.

 

Takže, co když potřebujete vyřešit velmi specifický problém na nepodporovaném aplikačním protokolu, kde není viditelnost flow dat? V takovém případě potřebujete nástroj pro zachytávání paketů. Ve skutečnosti však nepotřebujete. Pokud tam máte Flowmon sondu, máte i přístup ke kompletním informacím z paketů. Takže namísto extrahování metadat z paketů, zaúkolujete sondu, aby zahájila záchyt paketů. Tento úkol bude časově omezen a striktně zaměřen na zaznamenávání paketů, které jsou relevantní pro vyřešení specifického problému. Selektivní záchyt paketů na vyžádání (on-demand) je řešení snadno ovladatelné i v prostředí s více 10G linkami, a bez potřeby masivního úložiště.

Flow data jsou řešením pro dynamickou budoucnost

Flow data již dlouho nejsou hračkou, jejíž využití je omezeno na několik málo případů. Technologie obohacených flow dat dozrála natolik, že se stala moderním nástrojem, který nabízí dostatečnou detailnost pro řešení síťových incidentů, konfiguračních problémů, pro plánování kapacity atd. Ve srovnání s nástroji pro záchyt paketů v plném rozsahu nabízejí významně lepší škálovatelnost, flexibilitu a snadnější ovládání. V důsledku toho šetří čas, snižují MTTR i celkové náklady na síťové operace. Jejich využití přitom není omezeno jen na monitorování výkonu a odstraňování síťových problémů. Jsou také základem pro behaviorální analýzu sítě, která dokáže detekovat a reportovat náznaky IOC (indikátory kompromitace), lateral movement taktiku, APT, síťové útoky atd. 

Není náhodou, že jsme v posledních letech svědky postupného nahrazování technologie pro záchyt paketů právě technologií flow dat. Ty se dostávají do korporátního prostředí i díky stále častější migraci infrastruktury do cloudu, využívání IoT, SDN a enormně rostoucí šířce pásma. A tento trend bude nadále pokračovat.