hledat:

5  Sledování infrastruktury a provozu sítě

V této aktivitě se zabýváme návrhem, vývojem a optimalizací užití prostředků pro systematické dlouhodobé a plošné sledování dějů v síti. Soustřeďujeme se na dva základní okruhy problematiky.

V oblasti sledování infrastruktury sítě se zaměřujeme na zpracování a poskytování informací primárně získaných ze souboru technických prostředků, které síťovou infrastrukturu vytvářejí, a to prakticky bez ohledu na vrstvu sítě, ve které ten či onen prvek dominantně pracuje. Snažíme se vyvíjet prostředky, které by byly schopny poskytnout jak detailní, tak souhrnné informace o konkrétních parametrech, zachytily alespoň určitou míru dynamiky jevů v síti a na úrovni vizualizace dokázaly na základě aktuální potřeby pracovat s různou logickou strukturu síťových prvků a provádět tomu odpovídající agregaci průběhů požadovaných veličin. Základním zdrojem informací o stavu jednotlivých prvků infrastruktury sítě je pro nás SNMP (Simple Network Management Protocol). Námi přidaná hodnota spočívá v hledání nestandardních způsobů zpracování a zprostředkování takto získaných informací.

V oblasti sledování provozu sítě provádíme analýzu toho, co je síťovou infrastrukturou přenášeno. Zde se zaměřujeme na provoz přenesený protokolem IP (IPv4 i IPv6) a na zpracování provozních záznamů založených na bázi toků, které tento provoz v agregované podobě popisují. Naší snahou je postupný vývoj flexibilních a škálovatelných řešení pro analýzu provozu (v distribuované architektuře), která jsou schopna poskytnout velmi široké spektrum informací o IP provozu a budou, kromě jiného, podpůrným nástrojem v oblasti bezpečnostní problematiky a při řešení incidentů.

5.1  Sledování infrastruktury sítě

V této oblasti je nosným prvkem naší činnosti vývoj, správa a provoz systému G3. V roce 2010 jsme se zaměřili na jeho interní stabilizaci, rozšíření měřicích a vizualizačních schopností. Součástí našich prací byla i příprava konceptu budoucího poskytování služeb sledování infrastruktury uživatelům velké infrastruktury CESNET.

5.1.1  Vývoj a rozšíření systému G3

V rámci úprav systému jsme postupně stabilizovali některé komponenty měřicí části. Podařilo se nám zefektivnit chod uživatelského rozhraní při přípravě a správě dat souvisejících se vznikem a udržováním konkrétní relace (session). Dokončili jsme přepracování knihovny pro vizualizaci vícezdrojových RRD (Round Robin Database) dat. Princip úprav spočíval v postupném sjednocování dílčích specializovaných funkcí do jednotného obecného parametrizovatelného algoritmu. Modul G3 reporter jsme kromě jiného rozšířili o schopnost zpracovat a vizualizovat trendy vývoje numerických údajů (oproti odpovídajícím hodnotám výstupu z předchozího časového období v rámci dlouhodobých sérií výstupů). Ukázky rozsahu vizualizačních možností modulu na úrovni sumarizovaných informací jsou na obrázku 5.1 a 5.2.

Patrně nejzásadnější změnou systému G3 v roce 2010 byla implementace monitorování IPv6 parametrů zařízení. Tyto údaje jsou zatím měřitelné různým způsobem (různé MIB – Management Information Base) u různých platforem v závislosti na konkrétních verzích operačního systému. Proto jsme vytvořili sjednocující mechanismus pro všechny alternativy, který je dále otevřený pro začlenění případných dalších způsobů sběru IPv6 informací. Tento mechanismus jsme na úrovni základních popisných údajů (IP adresace rozhraní) začlenili do stávajícího způsobu generování exkluzivních identifikátorů rozhraní (doposud IPv4 adresace, technologické a administrátorské popisné údaje). Tyto informace se týkají popisu základní struktury zařízení, což ve výsledku implikuje změny v logické struktuře všech zařízení s přiřazenými globálními IPv6 adresami na jednotlivých rozhraních. Na obrázku 5.3 je ukázka vlivu rozšíření informací (spodní identifikátor s IPv6 adresou) pro konstrukci identifikace objektu oproti předchozímu stavu (horní identifikátor bez IPv6 adresy). Na obrázku 5.4 je potom ukázka možnosti sjednotit pohled na totéž rozhraní pomocí agregačních vlastností uživatelského rozhraní systému G3.

Dále jsme připravili nástroje pro permanentní dohled nad chodem systému. Navrhli a implementovali jsme základní sadu výkonných modulů, celkový koncept a schéma pro monitorování technologické infrastruktury systému G3 i jeho běhu pomocí systému Nagios a uvedli jej do praxe. Součástí SW balíku je jak automatický instalátor Nagios monitoringu na nové instance systému G3, tak generátor odpovídající globální konfigurace Nagios.

5.1.2  Provozní stav systému G3 v prostředí sítě CESNET2

V rámci páteřní sítě CESNET2 jsou v provozu dvě instalace systému – na úrovni měření jsou konfigurovány identicky, takže z hlediska měření se vzájemně zálohují. Uživatelé mají přístup k jedné instalaci, druhá slouží jako základna pro generování veškerých periodických výstupů pomocí modulu G3 reporter. Na konci roku 2010 jsou objemy měření následující: Každá z instalací měří periodicky přes 585 tisíc položek ze 148 zařízení (viz ukázka výstupu nástroje na administraci na obrázku 5.5) s krokem měření v rozsahu 20–1200 vteřin a průměrem 600 vteřin. To znamená, že za poslední rok byl proveden sběr více než 30 miliard údajů z každé instalace. Pro představu je z hlediska struktury zařízení kromě jiného zachyceno přes 36 tisíc síťových rozhraní (fyzických i logických), přes 7 tisíc HW komponent nebo necelé 4 tisíce QoS objektů. Aktuálně jsou jednotlivé komponenty RRD databáze kalibrovány na dobu uchování dat necelých 14 let s progresivní agregací v sedmi časových intervalech. Vzhledem k množství ukládaných a zpracovávaných dat se podle dostupných informací jedná o jednu z nejrozsáhlejších RRD implementací globálně.

Primární instalace aktuálně běží na 16 jádrech Intel X7350/2,93 GHz s 64 GB RAM a HW RAID 10 úložištěm sestaveným z osmi 15 krpm SAS jednotek.

Přístup k interaktivnímu uživatelskému rozhraní je v současnosti omezen pouze na skupiny pracovníků správy sítě a dohledu. V roce 2010 jsme celkem zaznamenali přes 18 tisíc interaktivních přístupů. K veřejně dostupným výstupům systému, generovaným modulem G3 reporter jsme zaznamenali za posledních 6 měsíců více než 2 milióny přístupů.

Kromě sledování infrastruktury sítě CESNET2 jsme průběžně povyšovali a spravovali dedikovanou instalaci systému pro souvislé plošné sledování síťové infrastruktury projektu FEDERICA (7. rámcový program).

5.1.3  Koncept služeb pro uživatele velké infrastruktury CESNET

V souvislosti s budoucností jsme se snažili systém v jeho aktuálním vývojovém stádiu optimalizovat a zároveň připravit koncept možných služeb pro uživatele velké infrastruktury CESNET (dále VI CESNET) tak, aby bylo možné uspokojit požadavky všech očekávaných typů.

Základním modelem nasazení systému bude sledování jednotlivých komponent VI CESNET z prostředí páteřní sítě. Oproti současnému stavu to bude znamenat rozšíření systematického sledování o nové technologické prvky (úložiště, grid). To by mělo dostačit jak pro požadavky správy a dohledu nad VI CESNET, tak pro generování statických výstupů pro jednotlivé zájmové skupiny uživatelů (např. dedikované logické infrastruktury, multimediální služby, dostupnost a využití úložišť z hlediska síťové komunikace a mnoho dalších).

Pro uživatele, kteří budou potřebovat ustanovit sledování vlastních zařízení v připojených sítích (resp. navazujících technologických celků) a nebudou disponovat dostatečnými vlastními kapacitami, případně budou chtít použít stejné nástroje jako ve VI CESNET, máme v plánu dvě varianty. V rámci první předpokládáme zajistit sledování na centrálních HW prostředcích pomocí dedikovaných instalací systému G3 a sledovat připojené infrastruktury z páteřní sítě. Uživatelé pak mohou mít k dispozici interaktivní uživatelské rozhraní a periodicky generované statické výstupy podle svých potřeb a vzájemné dohody. Druhá varianta předpokládá, že si uživatel na svém HW vytvoří dedikovanou instalaci systému G3 se sdílenou administrací.

V rámci nasazení do VI CESNET předpokládáme další vývoj systému G3 směrem k pokud možno komplexnímu sledování všech základních komponent VI CESNET. Zaměříme se na zefektivnění chodu měřicí části z hlediska různých architektur měření, na další optimalizaci modulu G3 reporter a budeme se snažit reagovat na požadavky, které se objeví v průběhu rekonstrukce VI CESNET (nové typy sbíraných a zpracovávaných informací). V neposlední řadě máme v plánu propojovat systém G3 se systémem FTAS pro analýzu IP provozu v oblastech sdílení identifikátorů popisujících aktuální konfiguraci síťové infrastruktury.

5.2  Sledování provozu sítě

V této oblasti je nosným prvkem naší činnosti vývoj, správa a provoz systému FTAS.

5.2.1  Vývoj a rozšíření systému FTAS

V roce 2010 prodělal systém několik zásadních změn. Rozšířili jsme vizualizační část uživatelského rozhraní o vyhledávací formuláře pro ad-hoc nastavení filtračních podmínek při vizualizaci. K dispozici jsou v podobě analogické s vyhledávací částí uživatelského rozhraní – je k dispozici varianta obecná pro zadání volné filtrační podmínky (ukázku vidíte na obrázku 5.6) a varianta s poli přednastavenými podle obsahu vizualizovaných dat (viz obrázek 5.7). Tento mechanismus umožňuje výrazně zefektivnit práci se systémem. Primární (a z hlediska spotřeby zdrojů nejnáročnější) vyhledávání může být provedeno s šíře vymezenými podmínkami (např. obousměrný provoz několika zájmových IP adres v daném období) a následně je možné provést řadu vizualizací, tj. sekundárních vyhledání (z již dříve samostatně uložených dat) s přesným vymezením (např. každá zájmová IP adresa pro každý směr přenosu zvlášť).

Další významnou změnou v systému bylo odbourání výkonnostních limitů pro zpracování provozních záznamů z jednoho zdroje. Vytvořili jsme nový, volitelný mechanismus umožňující rozdělení proudu příchozích provozních informací z jednoho zdroje na několik sad (multiplexů) dílčích proudů. Množství dílčích proudů v rámci každého multiplexu je libovolné. Každý multiplex (a v principu každý dílčí proud v rámci multiplexu) může být směrován ke zpracování na libovolný uzel soustavy a pro každý multiplex lze explicitně určit jaké úkony na něm mají být provedeny (ukázka konfigurace vytvoření multiplexu je na obrázku 5.8).

To například umožňuje směrovat jeden multiplex k prostému uložení neagregovaných provozních informací (ukázka konfigurace na obrázku 5.9) a druhý k provedení všech klasifikačních a filtračních operací (obrázek 5.10), přičemž v rámci multiplexu pro klasifikaci a filtraci (náročnější operace) můžeme vytvořit např. 6 proudů a v rámci multiplexu pro prosté uložení proudy pouze 2. Použijeme-li jiný přístup k problematice, můžeme vytvořit model prostého paralelního rozdělení zátěže vytvořením jediného multiplexu a v jeho rámci pak na všechny dílčí proudy provozních informací aplikujeme kompletní sadu všech úkonů.

Tímto rozšířením systému jsme zásadním způsobem zvýšili jeho průchodnost – ta je nyní v principu omezena pouze dostupnými zdroji v HW. Po nasazení do produkční instalace v páteři sítě CESNET2 je tak v principu možné bez vstupního vzorkování zpracovat 100 % příchozích provozních záznamů (beze ztrát). V praxi jsme však zvolili určitý kompromis, neboť zvýšením průchodnosti zpracování jsme přesunuli problém směrem ke kapacitě úložišť a pro produkční zpracování jsme systém kalibrovali tak, aby byly k dispozici neagregované provozní záznamy alespoň s měsíční historií.

Změny v architektuře zpracování provozních informací jsme promítli do té části uživatelského rozhraní, která vizualizuje statistické informace z jednotlivých kolektorů. V přepracovaném rozhraní je vizualizována jak každá část multiplexu, tak multiplex jako celek. Kromě toho jsme zjemnili navigaci tak, aby bylo možné odkázat se cíleně na jednotlivé zdroje provozních záznamů, přijímače výsledků filtrace nebo celého kolektoru, a to v závislosti na oprávnění uživatelů.

V modulu vstupního zpracování provozních záznamů jsme navrhli a implementovali specifický mechanismus zpracování provozních informací z platformy Cisco ASAxxxx, a to s volitelným způsobem zpracování záznamů buď z vnějšího pohledu (před zařízením) nebo vnitřního pohledu (za zařízením) včetně přemapovaných čísel portů, případně obou variant záznamů současně. V ukázce výstupu na obrázku 5.11 je varianta z pohledu vnitřní sítě.

Kompletně jsme přepracovali vyhledávání provozních informací. Původní koncept byl založen na vyhledávání v místě, ve kterém jsou uložena prohledávaná data. Vizualizace nalezených dat potom probíhala pomocí výběru na vzdáleném místě (z hlediska uživatelského rozhraní). Nové schéma je založeno na tom, že veškerá vyhledaná data jsou ukládána na definované místo – aktuálně na úložiště svázané s uživatelským rozhraním. Tento koncept nám umožnil vyvinout a implementovat mechanismus vyhledávání, který je schopen (v případě volby) provést jedno vyhledávání provozních informací z více zdrojů současně. Tato koncepce vytváří předpoklad pro vyšší flexibilitu řízení a využití systému.

V případě volby zdrojů provozních záznamů s rozdílnými množinami zpracovávaných polí je zatím aplikován restriktivní přístup při nabídce polí pro vyhledání a zadání vyhledávacích podmínek (průnik množin použitých polí záznamů u jednotlivých zdrojů). Toto rozšíření významně zjednodušuje práci při detailní analýze provozu, který se mohl potenciálně objevit na více místech sítě (běžné u řešení bezpečnostních hlášení). Obrázek 5.12 obsahuje ukázku uživatelského rozhraní při zvolení tří zdrojů provozních záznamů – množiny dostupných polí pro výběr a zadání vyhledávacích podmínek jsou omezeny průnikem vlastností zvolených zdrojů.

Pro speciální případy jsme rozšířili autorizační schéma definující přístup k jednotlivým informacím o provozu. Původní mechanismus odvozený od vazby uživatel->objekt jsme rozšířili o možnost nastavit exkluzivní vazbu objekt->uživatel (automaticky vylučující všechny ostatní uživatele včetně administrátora).

Vyhledávací, vizualizační a interní statistickou část uživatelského rozhraní jsme upravili tak, aby výsledný generovaný kód byl z hlediska HTML bezchybný.

V rámci zásadního přepracování některých částí uživatelského rozhraní jsme jeho architekturu rozšířili tak, že v nové verzi může koexistovat několik uživatelských rozhraní pro jednu instalaci systému, a to nezávisle na sobě. Instalováno může být i mimo uzly dané instance systému.

Uživatelské rozhraní bylo dále upraveno tak, aby se pokusilo dokončit vyhledávání (případně i vizualizaci) v případě, kdy došlo ke ztrátě spojení se vzdáleným úložištěm (tj. databázovým strojem). Systém se po určitou dobu snaží periodicky obnovit spojení a v případě úspěchu pokračuje ve vyhledávání. Dále jsme ošetřili situace, kdy uživatelské rozhraní během vyhledávání narazí na porušená data (např. vinou předchozí havárie kolektoru). V takovém případě systém informuje uživatele o poškozených datových tabulkách a vyhledávání pokračuje následující tabulkou ve frontě. Tento mechanismus je velkým přínosem především při vyhledávání v rámci velmi dlouhých časových intervalů.

V uživatelském rozhraní jsme vytvořili novou sekci – interaktivní nápovědu pro činnosti vyhledávání a vizualizace dat. Interaktivní manuál pokrývá způsobem krok za krokem (včetně praktických příkladů ve variantách) všechny způsoby vyhledávání (obecný i základní jednoduchý formulář) a všechny varianty vizualizace (prostý text, HTML, HTML s grafy).

Pro potřeby bezpečnostního týmu CESNET CERTS v souvislosti s řešením mezinárodních incidentů v rámci projektu GN3 jsme rozšířili vlastnosti vyhledávacího i vizualizačního aparátu systému FTAS o možnost zadávat zájmový časový rozsah volitelně i v GMT. Na úrovni vizualizace provozních záznamů je analogicky možné interaktivně přepínat mezi lokálním časovým pásmem a GMT.

Pro potřeby statistických odhadů odvozených z vyhledávání v rámci velkého časového intervalu jsme pro zrychlení běhu úloh implementovali možnost nastavit „vzorkování“ na úrovni datových tabulek v úložišti. Každá datová tabulka reprezentuje pro provozní záznamy z daného zdroje určitý časový interval (zpravidla v rozsahu od 1 do 30 minut podle zdroje). Mechanismus umožňuje stanovit krok pro výběr tabulek k vlastnímu vyhledávání ze serializovaného seznamu (podle času a zdroje) všech potenciálních tabulek pro vyhledávání. Ukázka části uživatelského rozhraní s rozšířenými možnostmi pro zadání časových parametrů je na obrázku 5.13. Vlastní efekt vzorkování na úrovni datových tabulek z hlediska rozložení nalezených dat na časové ose znázorňuje obrázek 5.13.

Do vizualizačního modulu systému FTAS jsme implementovali nastavitelnou anonymizaci zdrojových a cílových IP adres. Nastavení se provádí interaktivně pro každou stranu toku nezávisle. Aktuálně je možné nastavit 3 stupně intenzity anonymizace. Anonymizace je protokolově nezávislá (IPv4 i IPv6). V případě vyžádaného překladu IP adres na jména je anonymizace automaticky rozšířena v odpovídající logice i na jména uzlů. Ukázka anonymizovaného výstupu je na obrázku 5.15.

5.2.2  Provozní informace

Technologickou infrastrukturu instalace systému v páteři sítě CESNET2 jsme vzhledem k rozpočtové situaci posílili alespoň pomocí tří uzlů sestavených z funkčních komponent starších (samostatně již nefunkčních) strojů. To nám umožnilo o něco lépe rozdělit zpracování a uložení provozních informací v rámci celé soustavy.

Provedli jsme zcela novou instalaci systému FTAS ve vnitřní síti Masarykovy nemocnice v Ústí nad Labem (dále MNUL) a ve spolupráci s administrátory sítě MNUL nakonfigurovali systém pro sběr provozních informací z regionální nemocniční sítě. Systém je provozován na HW MNUL ve sdílené správě. Dále jsme nově ustanovili cílené systematické zpracování provozních informací pro Nemocnici Na Homolce. V tomto případě se jedná o dedikovanou konfiguraci v rámci primární instalace systému v síti CESNET2. Ostatní dedikovaná cílená sledování specifického provozu v rámci provozu páteře sítě CESNET2 pro bezpečnostní týmy a některé připojené organizace zůstávají v provozu. Taktéž ostatní externí instalace a dedikované konfigurace (Seznam.cz, a. s., MU Brno, TU Liberec, ZČU Plzeň a další) jsou pod průběžnou správou a pravidelně povyšovány.

5.2.3  Aktuální stav systému páteřní sítě CESNET2 v číslech

Primární instalace systému v páteři sítě CESNET2 aktuálně běží na 12 uzlech. To reprezentuje 70 jader a více než 14 TB úložišť. Průběžně jsou zpracovávána data z cca 20 páteřních směrovačů. Celkový objem příchozího toku provozních záznamů na všechny uzly systému (včetně jejich interní redistribuce) se aktuálně pohybuje v rozsahu mezi 28 Mb/s a 175 Mb/s s průměrem okolo 75 Mb/s. Oproti loňskému roku tok provozních záznamů vzrostl přibližně 1,7 krát – ukázka průběhu je na obrázku 5.16. Za celý rok bylo na vstupy všech kolektorů přivedeno přibližně 273 TB dat. Z toho bylo kompletně zpracováno přibližně 110 TB dat, což reprezentuje přibližně 1,5 bilionu provozních záznamů. Přístup k uživatelskému rozhraní systému mají pouze správci sítí a členové bezpečnostních týmů, přesto zaznamenáváme v průměru okolo 700 přístupů měsíčně.

předchozí

obsah

následující