Tomáš Košňar CESNET z.s.p.o. kosnar@cesnet.cz

1. Plošné a souvislé sledování provozu IP sítě na základě informací o datových tocích • Tomáš Košňar • CESNET z.s.p.o. • kosnar@cesnet.cz

2. Obsah • Úvod – cílové prostředí - síť CESNET2 • Provozní informace o IP datových tocích • Co je dobré vzít v úvahu při úvahách o monitorování na bázi informací o IP datových tocích • Potřeby a požadavky na sledování provozu • Systém FTAS (účel, vlastnosti, nasazení v páteřní síti CESNET2) • Závěr

3. CESNET2 • národní vysokorychlostní počítačová síť určená pro vědu, výzkum, vývoj a vzdělávání

4. CESNET2 • páteř • DWDM • IP/MPLS backbone • IPv4 unicast, multicast • IPv6 unicast, Multicast • L1, L2 specifické infrastruktury • E2E služby • specifický účel a vlastnosti (náročné distribuované výpočty a datové sklady, fyzika, medicína, multimédia ve vysoké kvalitě a další)

5. CESNET2 • IP/MPLS backbone • přibližný rozsah sledování provozu páteře

6. Provozní informace o IP datových tocích • pohled na síť • topologie

7. Provozní informace o IP datových tocích • pohled na síť • vrstvy, enkapsulace dat - příklad

8. Provozní informace o IP datových tocích • koncept NetFlow(Cisco Systems Inc. ™) • vybrané informace z hlaviček datagramů TCP/IP • tj. informace o jednosměrném toku • v závislosti na dalších faktorech případné rozšiřující odvozené informace • např. číslo AS, nexthop, indexy síťových rozhraní… • závisí např. na místě vzniku záznamu (např. jsou-li k dispozici směrovací informace) • závisí na verzi formátu NetFlow dat

9. Provozní informace o IP datových tocích • koncept NetFlow • informace dočasně uchována v paměti • modifikována s každým datagramem (paketem) příslušným danému toku • postupně vzniká agregovaná informace o provozu • míra agregace je dána časem po který je informace dočasně držena v paměti • míra agregace je nastavitelná v závislosti na implementaci

10. Provozní informace o IP datových tocích • koncept NetFlow • po expiraci je záznam exportován do míst zpracování (tzv. kolektory) • zpravidla UDP • několik exportních formátů • pevné – např. v1,5,7 (částečně se liší obsahem, základní struktura stejná) • otevřený – v9 (RFC 3954) • IPFIX (RFCs 3917, 3955, 5101-3)

11. Provozní informace o IP datových tocích • struktura NetFlow záznamu • A. identifikátory toku • základní veličiny identifikující tok • adresa zdroje, cíle • přenosový protokol • čísla portů, identifikátor služby (v závislosti na protokolu) • klíč pro doplnění informací dalšími pakety daného toku • tj. stejné údaje pro všechny pakety příslušné danému toku

12. Provozní informace o IP datových tocích • struktura NetFlow záznamu • B. objemové ukazatele, časové informace • celkový objem toku • celkový počet paketů toku • rozsah toku v čase • čas prvního a posledního paketu toku • tj. agregované údaje modifikované s každým dalším paketem příslušným danému toku

13. Provozní informace o IP datových tocích • struktura NetFlow záznamu • C. atributy toku • Type of Service • TCP flags • agregované (logické OR) údaje přes všechny pakety příslušné danému toku

14. Provozní informace o IP datových tocích • zdroje NetFlow záznamů • směrovače • např. Cisco, Juniper • specializované sondy • např. FlowMon (CESNET z.s.p.o ™) • SW řešení • např. tcpflow

15. Co je dobré vzít v úvahu při úvahách o monitorování • architektura monitorování • o provozu, který „neteče přes zdroj“ NetFlow záznamů, se prostřednictvím NetFlow nic nedozvíme • způsob zpracování dat • o provozu, který „teče přes více zdrojů“ NetFlow záznamů, se dozvíme vícekrát • principu není možné absolutně eliminovat duplicity - agregační mechanismy na jednotlivých zdrojích jsou nezávislé • dynamické chování sítě může ovlivnit získané informace o provozu (např. změny ve směrování)

16. Co je dobré vzít v úvahu při úvahách o monitorování • příklady obecné architektury pro sledování provozu

17. Co je dobré vzít v úvahu při úvahách o monitorování • příklady obecné architektury pro sledování provozu

18. Co je dobré vzít v úvahu při úvahách o monitorování • efekty změn ve směrování z pohledu koncových uzlů a zdrojů NetFlow

19. Co je dobré vzít v úvahu při úvahách o monitorování • vliv struktury a objemu provozu na množství generovaných NetFlow záznamů IP forwarding [dtgm/s] Průběh exportu [NetFlow/s]

20. Co je dobré vzít v úvahu při úvahách o monitorování • míra agregace mezi IP pakety a NetFlow záznamy • v uvedeném případě ~ 50-100 paketů na NetFlow • nelze příliš zobecňovat • poměr závisí na konkrétních podmínkách • zdroj NetFlow • volná vyrovnávací paměť • agresivita parametrů pro export • chování uživatelů • nejlépe prakticky ověřit

21. Co je dobré vzít v úvahu při úvahách o monitorování • rozložení množství paketů v rámci NetFlow záznamů • zpravidla progresivní pokles počtu paketů na NetFlow záznam • příklad (experiment v konkrétních podmínkách - uvedeno pouze pro zajímavost, ovlivněno mnoha faktory) • vzorek 100K NetFlow záznamů • průměr 70 paketů na NetFlow záznam • nad nebo na průměru (70 paketů/záznam) pouze 10% záznamů • 50% záznamů 5 nebo méně paketů • 25% pouze 1 paketové záznamy

22. Co je dobré vzít v úvahu při úvahách o monitorování • absolutní množství potenciálních NetFlow záznamů ke zpracování • požadavky vs. možnosti zpracování • úspora zdrojů za cenu ztráty vypovídací hodnoty • vzorkování • pakety při „vstupu“ do NetFlow „stroje“ • záznamy při exportu z NetFlow „stroje“ • na straně kolektorů na úrovni příchozích NetFlow záznamů

23. Co je dobré vzít v úvahu při úvahách o monitorování • průchodnost jednotlivých komponent plánovaného systému • celková výkonnost systému založeného na bázi NetFlow ~ dána „nejslabším článkem řetězu“ (nic objevného, bohužel často opomíjeno)

24. Co je dobré vzít v úvahu při úvahách o monitorování • není-li k dispozici úplný obraz provozu sítě, platí • „jistota nalezeného“ ~ co jsme nalezli v NetFlow záznamech „bylo i v datagramech“ • jestliže jsme nic nenalezli, není jistota, že takový přenos nebyl uskutečněn... • při rozumných hodnotách vzorkování a vzhledem k principu vzniku NetFlow záznamů je u typických požadavků na analýzu přesnost velmi vysoká • proporce provozu a objemy provozu síťových entit • bezpečnostní incidenty na bázi emitování provozu • potvrzování/vyvracení provozu určitého typu v rámci makro-časového intervalu (alespoň jednotky minut)

25. Co je dobré vzít v úvahu při úvahách o monitorování • inspekce NetFlow záznamů a vztah použitých čísel portů k použitému aplikačnímu a programovému vybavení na koncových stanicích (typické požadavky na identifikaci P2P sítí) ? • je možný pouze odhad • NetFlow poskytuje informace o transportu a ne o obsahu

26. Potřeby a požadavky na sledování provozu • typové skupiny uživatelů • administrátoři sítě • administrátoři služeb • bezpečnostní tým • strategické plánování • další...

27. Potřeby a požadavky na sledování provozu • typové skupiny požadavků • zpětná analýza provozu (bez předem stanovených podmínek) na základě ad-hoc požadavku • „traffic-browser“ s komplexními vyhledávacími možnostmi • přijatelná doba uchování dat (dny/týdny) • ...bezpečnostní analýzy, verifikace chování sítě, služeb • „jaké zdroje z ASx na cíle v síti Y na tcp/4623-4624 nebo na udp/161 mezi 2:10-3:17“ • „provoz z a na IPx minulé pondělí okolo půlnoci“ • „komunikoval host.kdesi.cz mezi 17:00-17:15 s foo.bar.com na tcp/45000 ?“ • „odkud z venku (a na které cíle) na udp/445 během posledních 5ti dnů“ • apod.

28. Potřeby a požadavky na sledování provozu • typové skupiny požadavků • průběžná analýza provozu (na základě dopředu známých požadavků) pomocí komplexních klasifikačních a filtračních podmínek • doba uchování dat (dny/týdny) • a následné zpracování s cílem redukovat objem dat při zachování signifikantních charakteristik provozu • dlouhá doba uchování dat (měsíce) • ...sumární statistiky, trendy chování uživatelů, využití zdrojů a služeb, strategie směrovací politiky • „nejvýznamnější zdroje/cíle v síti X a charakteristika jejich provozu“ • „nejvýznamnější zdroje/cíle z našeho AS“ • „dlouhodobá charakteristika provozu zdroj.kdesi.cz“ • „nejvýznamnější TCP zdrojové porty v síti X/AS“ • „jaký podíl objemu našeho externího provozu po lince X mají sítě Q,W,E,.... v každém směru zvlášť“ • apod.

29. Potřeby a požadavky na sledování provozu • typové skupiny požadavků • proaktivní detekce potenciálních anomálií provozu včetně následné agregace při zachování signifikantních charakteristik anomálií • accounting • ...mnoho dalších

30. Potřeby a požadavky na sledování provozu • geneze v prostředí národní sítě pro vědu, výzkum, vývoj a vzdělávání • historicky několik systémů pro analýzu provozu • počátky v roce 1996 • první pokusy založeny ještě na IP-accounting (Cisco) mechanismu • aktuálně pro síť CESNET2 • FTAS - Flow-based Traffic Analysis System

31. Systém FTAS • snaha o design otevřeného systému pro flexibilní a variabilní zpracování NetFlow ve smyslu předchozích požadavků • design a vývoj na CESNET z.s.p.o. primárně pro potřeby sítě CESNET2 • průběžně vyvíjený systém

32. Systém FTAS • základní vlastnosti (aktuální) • modulární architektura umožňující flexibilní distribuované zpracování provozních informací • základní architektura: • centrální konfigurace • 1-N víceúčelových kolektorů • odděleně i v rámci jednoho stroje • víceúčelový kolektor: • 1-M víceúčelových „flow“ procesorů • úložiště • odděleně i v rámci jednoho stroje • možnost sdílení společného úložiště více procesory v rámci jednoho stroje

33. Systém FTAS • základní vlastnosti • škálovatelný systém (atomický prvek – 1 primární zdroj NetFlow) • provozovatelný na konvenčním HW • chování přizpůsobitelné možnostem – stabilní poměr „dostupné zdroje/vypovídací hodnota“ • podpora NetFlow v1,5,7,9 distribučních formátů • podpora IPv6 • NetFlow v9 obsahující informace o IPv6 provozu • transport NetFlow po IPv6 • „dual-stack“ na aplikační úrovni – volitelná verze IP v rámci interní redistribuce • interaktivní uživatelská rozhraní distribuovaná prostřednictvím WWW • vyhledávání a vizualizace informací o provozu • administrace, stavové informace systému

34. Systém FTAS • základní mechanismy zpracování provozních informací • průběžné zpracování příchozích NetFlow záznamů z primárních zdrojů • klasifikace (více úrovní) příchozích NetFlow záznamů z primárních zdrojů pomocí komplexních podmínek • průběžné samostatné zpracování informací o provozu podle komplexních filtračních podmínek (nad libovolnou množinou zdrojů primárních NetFlow záznamů) • periodické následné zpracování informací o provozu – agregace se zachováním charakteristik provozu • accounting na základě klasifikačního mechanismu • proaktivní detekce anomálií provozu

35. Systém FTAS • zpracování NetFlow z primárních zdrojů NetFlow z primárních zdrojů redistribuce – N cílů mimo konfigurační rámec parsování vzorkování (úroveň záznamů) aplikace klasifikačních podmínek (rozšířený interní formát) interní export pro zpracování accountingu a/nebo statistik aplikace filtračních podmínek, interní export (i vícenásobný) vyhovujících záznamů pro zpracování výsledků filtrace on-fly agregace - podmnožina NetFlow polí a/nebo parametry agregace (čas, počet zázn.) odeslání do úložiště

36. Systém FTAS • zpracování záznamů z interního exportu – výsledky filtrace, statistiky výsledky filtrace redistribuce – N cílů mimo konfigurační rámec parsování vzorkování (úroveň záznamů) on-fly agregace - podmnožina NetFlow polí a/nebo parametry agregace (čas, počet zázn.) odeslání do úložiště

37. Systém FTAS • příklad následného zpracování primární vyhledání v úložišti na základě konfigurace svázané s objektem (třídící podmínky) vícestupňová agregace v rámci všech vyhledaných dat statistics_order=octets desc statistics_group_key= statistics_nogroup_output=100/src_ip,dst_ip,src_port,proto statistics_nogroup_output=50/src_ip,proto statistics_nogroup_output=0/ uložení agregovaných dat do úložiště

38. Systém FTAS • příklad následného zpracování primární vyhledání v úložišti na základě konfigurace svázané s objektem (třídící podmínky) vícestupňová agregace po skupinách statistics_order=octets desc statistics_group_key=src_ip,flow_source statistics_group_output=10/dst_ip, proto, src_port, dst_port statistics_group_output=10/dst_ip, proto, src_port statistics_group_output=10/dst_ip, proto statistics_group_output=0/proto uložení agregovaných dat do úložiště

39. Systém FTAS • interaktivní uživatelské rozhraní • distribuce prostřednictvím WWW • dvoufázový styl práce - založeno na předpokladu • jedno vyhledání • vícenásobná vizualizace • ...potenciálně šetří zdroje

40. Systém FTAS • uživatelské rozhraní – vyhledávání, jednoduchý formulář

41. Systém FTAS • uživatelské rozhraní – vyhledávání, jednoduchý formulář • přizpůsobení struktuře zdroje na úrovni dostupných polí

42. Systém FTAS • uživatelské rozhraní – vyhledávání, obecný formulář

43. Systém FTAS • uživatelské rozhraní – výsledky, textový výstup

44. Systém FTAS • uživatelské rozhraní – výsledky, textový výstup, agregace nad podmnožinou polí

45. Systém FTAS • uživatelské rozhraní – výsledky, sumarizace, agregace nad podmnožinou polí

46. Systém FTAS • uživatelské rozhraní – výsledky, agregace nad jinou podmnožinou polí (stále nad původními výsledky hledání)

47. Systém FTAS • uživatelské rozhraní – výsledky, agregace nad jinou podmnožinou polí, sumarizace v rámci agregačního kroku (stále nad původními výsledky hledání)

48. Systém FTAS • uživatelské rozhraní – výsledky, agregace nad jinou podmnožinou polí (stále nad původními výsledky hledání)

49. Systém FTAS • uživatelské rozhraní – výsledky, anomálie provozu

50. Systém FTAS v IP/MPLS páteři sítě CESNET2 • plošný monitoring • cca 20 kolektorů na 8mi serverech (~4 jádra,~2-3GHz, ~4GB RAM, in-box HW RAID, U320, SAS) • 18 primárních zdrojů NetFlow (13 páteřních) • až 18k NetFlows/s/zdroj (průměr za 10 min)