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:

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ý IP protokolem (jak IPv4, tak i IPv6) a na zpracování provozních záznamů typu NetFlow, které tento provoz v agregované podobě popisují. Naším primárním zdrojem NetFlow informací jsou páteřní směrovače sítě CESNET2 a sondy FlowMon vyvíjené v rámci aktivity Programovatelný hardware. Naší snahou je postupný vývoj flexibilních a škálovatelných řešení v distribuované architektuře, která poskytnou 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ě

Nosným prvkem naší činnosti v této oblasti je vývoj systému G3. Nejvýznamnější výsledky naší práce v roce 2007 zahrnují:

• Rozšíření měřící části systému v oblasti interního zpracování a ukládání dat.
• Přenesení části funkcí souvisejících s obsluhou uživatelů z uživatelského rozhraní do podoby systémového procesu.
• Vytvoření kompaktní podoby uživatelského rozhraní systému.
• Rozšíření vlastností uživatelského rozhraní.
• Návrh a realizace elektronického klienta systému.

5.1.1   Rozšíření architektury měřící části systému G3

Původní architektura měřící části systému byla založena na principu, kdy je spektrum sledovaných zařízení rozděleno pomocí konfigurace nejvyšší úrovně do volitelného množství skupin. Součástí každé skupiny může být libovolné množství sledovaných prvků. Sběr dat i jejich následné zpracování a ukládání bylo pro každou takto nadefinovanou skupinu sledovaných prvků zajištěno samostatným procesem. Tato architektura nedokáže eliminovat náhodné shluky požadavků na úložiště a rozložit související zátěž rovnoměrným způsobem.

Vzhledem k výše uvedenému byla měřící část systému rozšířena o režim, kdy veškeré požadavky na úložiště vybavuje jediný proces. Tento proces hraje z makro pohledu i roli vyrovnávací paměti a zajišťuje rovnoměrnější, z hlediska původních požadavků asynchronní ukládání dat do úložiště. Komunikace s procesy provádějícími vlastní sběr dat probíhá volitelně buď přes sdílenou paměť nebo pomocí UNIX soketů. Rozšíření architektury systému je naznačeno na obrázku.

5.1.2   Rozšíření architektury obsluhy uživatelů

Uživatelské rozhraní bylo ve své původní podobě navrženo tak, že veškeré operace nutné k vybavení požadavků uživatelů byly prováděny každou bežící instancí rozhraní, a to nezávisle na sobě. V principu se jedná o několik skupin operací:

1. příprava dat pro konstrukci navigačního stromu,
2. konstrukce navigačního stromu podle aktuálního vzoru pro jeho strukturu (template),
3. vizualizace navigačního stromu nebo jeho části,
4. generování výstupů na základě vybraných prvků navigačního stromu a zvoleného rozsahu veličin.

V případě netriviálního množství sledovaných zařízení a především množství objektů vyplývajících z jejich konfigurace je nejnáročnější operací příprava dat pro konstrukci navigačního stromu. Tato operace znamená v podstatě traverzování všemi naměřenými daty se vztahem k navigaci. Výsledný "polotovar" je pak platným a autoritativním zdrojem pro konstrukci navigačního stromu po nastavenou dobu (lze měnit prostřednictvím uživatelského rozhraní). Tuto architekturu jsme rozšířili s cílem optimalizovat využití zdrojů. Generování výchozích dat pro konstrukci navigace je možné provádět novým modulem - samostatně bežícím procesem na hostitelském stroji. Tento proces běžící na pozadí generuje v nastavené periodě data, která jsou následně využita všemi instancemi uživatelského rozhraní systému. Na obrázku je znázorněno rozšíření architektury obsluhy uživatelů.

5.1.3   Kompaktní uživatelské rozhraní

Vedle generického uživatelského rozhraní jsme vytvořili i jeho kompaktní, minimalistickou verzi. Obě verze jsme pak postupně slaďovali tak, aby při přechodu z jedné do druhé byla patrná určitá logická i vizuální souvislost. Kompaktní verze je mnohem přehlednější a některá nastavení se automaticky mění v závislosti na uživatelem zadaných parametrech souvisejícího významu. Mezi oběma režimy rozhraní lze interaktivně přepínat. V základní nabídce kompaktní verze jsou přímo k dispozici pouze nástroje na filtraci, vyhledávání, změnu struktury objektů a základní parametry pro generování souhrnů. Výchozí stav je znázorněn na obrázku. Další ovládací moduly jsou dostupné prostřednictvím menu na horní liště a lze je podle potřeb interaktivně rozbalovat.

5.1.4   Rozšíření vlastností uživatelského rozhraní

Z dalších úprav a rozšíření uživatelského rozhraní stojí za zmínku možnost uchování aktuálního nastavení pro pozdější použití - session management (související menu na obrázku), dále možnost sdílet část uživatelského nastavení s ostatními uživateli (související menu na obrázku) a v neposlední řadě rozšíření možností pro zadávání zájmového časového intervalu. Počáteční čas intervalu lze zadávat jako násobnou položku, což umožňuje generovat v rámci jednoho výstupu několik dílčích výstupů - každý pro jinou historii dat (např. den, měsíc, rok apod.). Ukázka možného nastavení je na obrázku.

5.1.5   Elektronický klient systému G3

Systém G3 je z hlediska uživatelského ovládání koncipován jako interaktivní s tím, že vlastní práce probíhá ve dvou fázích. V první fázi jsou pomocí vyhledávání, filtrace nebo prostým procházením vybírány z navigačního stromu objekty, které jsou předmětem zájmu uživatele. Ve druhé fázi jsou pro tyto objekty generovány výstupy v závislosti na souvisejících, uživatelem nastavených parametrech. Tento model práce vyhovuje zpravidla takovým skupinám uživatelů jako jsou administrátoři sítě. Pro běžného uživatele může být tento způsob ovládání složitý a obtížně srozumitelný, neboť navigační strom (informační obsah) je konstruován přímo z dat naměřených na síťových zařízeních a v základní podobě odpovídá technologické struktuře těchto prvků. I další související parametry, které jsou podstatné pro získání kvalitních výstupů, jsou nabízeny způsobem srozumitelným především odbornému personálu. Přesto je v běžné praxi potřebné uspokojit i požadavky běžných uživatelů a nabídnout jim maximálně jednoduchou formu navigace a srozumitelnost výstupů bez nutnosti interaktivního nastavování jakýchkoli parametrů. Cílem by měly být variantní statické výstupy uspořádané do logických struktur a zastřešené srozumitelnými rozcestníky.

Tento požadavek jsme vyřešili prostřednictvím elektronického klienta - nového samostatného nástroje s pracovním názvem Reporter (podrobněji technická zpráva [Koš07]), který specifickým způsobem ovládá uživatelské rozhraní systému G3. Tento nástroj se opírá o dva základní zdroje informací. Prvním jsou uživatelská nastavení uložená prostřednictvím session managementu (viz. výše). Prostřednictvím každého takto uloženého záznamu získává Reporter informace o objektech, které jsou s tímto záznamem svázány (např. všechna síťová rozhraní související s konkrétní linkou) a jsou potenciálním předmětem generovaných výstupů (viz obrázek) - tedy co může být vizualizováno. Druhým zdrojem informací jsou samostatné konfigurace, každá pro skupinu záznamů uložených v rámci session managementu, které mají nějakou vzájemnou souvislost (např. všechny záznamy popisující páteřní linky sítě). Zde se, kromě jiného, definuje struktura výstupů, jejich informační obsah apod. - tedy jak má být vizualizováno. Pokud je třeba vizualizovat stejnou skupinu záznamů uložených pomocí session managementu opakovaně a nezávisle na sobě (např. pokaždé s jinými časovými intervaly, s jinou vypovídací hodnotou nebo rozdílnou mírou agregace výstupů), je možné pomocí konfigurační direktivy importovat obsah jedné konfigurace do druhé tak, že sdílené údaje jsou zadány právě jednou v jedné konfiguraci.

V souvislosti s návrhem a programováním tohoto nástroje jsme museli analogicky rozšířit funkčnost uživatelského rozhraní systému G3. Vizualizační modul je nyní schopen produkovat statické výstupy podle ad-hoc požadované struktury s požadovaným lokálním umístěním. Zároveň je zajištěno vzájemné provázání jednotlivých částí výstupů. S tím souvisí i rozšíření spektra akceptovaných parametrů na vstupu uživatelského rozhraní a kontrola způsobu, jakým bylo spuštěno. Parametry, které podmiňují generování statických výstupů do systému souborů, nejsou akceptovány od HTTP serveru prostřednictvím CGI (standard pro G3 uživatelské rozhraní v interaktivním režimu). Architektura s elektronickým klientem s sebou nese požadavky na negociační proces mezi klientem a uživatelským rozhraním G3. Příslušné skupiny informací mohou nyní být poskytovány klientské straně alternativně také ve formátech usnadňujících elektronické zpracování.

Reporter systému G3 zajišťuje zpracování několika základních skupin úloh. V rámci jedné konfigurační entity (skupina záznamů uložených prostřednictvím session managementu + související konfigurace Reporteru pro tuto logickou skupinu) je množství úloh, které budou provedeny, podmíněno parametry uloženými v konfiguraci Reporteru. Současné spektrum použitelných základních funkcí je následující:

Kontrola objektů

Záznamy uložené v rámci interaktivní práce pomocí session managementu obsahují ve vztahu k příslušným objektům filtrační a vyhledávací podmínky, pomocí nichž byly tyto objekty nalezeny. V případě rekonfigurací sledovaných zařízení a změny popisných údajů objektů (změna popisu síťového rozhraní administrátorem sítě, přeadresování apod.) může dojít k tomu, že uloženým podmínkám vyhovuje po rekonfiguraci zařízení jiný počet objektů než doposud. V případě potřeby lze v konfiguraci Reporteru nastavit pro každý záznam uložený pomocí session managementu počet objektů, které musí být v rámci aktuálního běhu nalezeny - v opačném případě je záznam vyňat z dalšího zpracování a volitelně je elektronickou poštou odesláno oznámení o této disproporci.

Vyhodnocení zátěže linek/tras/cest pro zadané období

Toto je specifická úloha - jediná, kde je svázán typ objektu s konkrétními veličinami (síťová rozhraní, kapacity, přenesené objemy dat). Jako samostatná, nezobecněná byla zachována z následujících důvodů. Kromě toho, že se jedná o úlohu, která byla akcelerátorem vzniku Reporteru a je standardně požadována, musí zpracování zohlednit faktory, které nejsou vždy technicky zjistitelné a měřitelné. Zpracování musí být možné pro architekturu několika linek/tras mezi dvěma koncovými body obecně, a to jak pro modely provozu s rozdělenou zátěží, tak se vzájemným zálohováním. A také musí být možné zadat a zohlednit kapacitu administrativně přidělenou jednotlivým trasám (např.: smluvní kapacity nebo situace kdy vlastní měření probíhá na jiném úseku trasy s fyzicky odlišnými parametry apod.)

Vyhodnocení dalších volitelných veličin pro zadané období

Tato úloha je v principu zobecněním předchozí úlohy. V konfiguraci Reporteru je možné specifikovat prakticky libovolnou položku měřenou systémem G3 (případně kombinaci více položek) a výsledek zpracování prezentovat způsobem opět podmíněným konfigurací Reporteru (např. nezávisle na terminologii, se kterou pracuje systém G3). Typické využití této úlohy se očekává při zpracování výstupů typu: "mapa podílu multicastu v síti", "mapa zdraví sítě", "mapa průměrné délky paketů" apod.

Generování statických výstupů

Z pohledu koncových uživatelů jedna ze základních úloh. Reporter ovládá na základě parametrů nastavených v konfiguraci uživatelské rozhraní systému G3 obdobným způsobem jako uživatel v interaktivním režimu s tím, že finální výstupy jsou ukládány ve statické podobě na zadané místo. Konfigurace umožňuje zadat dostatečné množství parametrů k dosažení potřebné rozmanitosti výstupů - časové intervaly, míru agregace, strukturu výstupů, jejich informační hloubku a další.

Generování souhrnného agregovaného výstupu

Souhrnný agregovaný výstup může obsahovat grafickou vizualizaci vybraných veličin zpracovaných v rámci předchozích úloh. Tato vizualizace může mít charakter aktivní mapy - grafická interpretace může odkazovat na příslušné statické výstupy a naopak. Další součástí mohou být tabulky s jednotlivými zpracovanými veličinami vztažené k příslušným statickým výstupům - opět s odkazy na vygenerované statické výstupy. Ve smyslu jedné konfigurační entity má takovýto výstup charakter rozcestníku.

Zpracování všech výše uvedených úloh je podmíněno nezávislými konfiguračními parametry. Každá z úloh (je-li požadována) je prováděna na základě vlastního časového scénáře určujícího např. frekvenci/časový krok pro spuštění, dobu časové platnosti výsledků a časový rozsah zpracování. Reporter může zpracovávat několik konfiguračních entit současně a být spuštěn jednorázově (případně opakovaně) nebo jako permanentně běžící proces na pozadí.

Jako ukázky některých výstupů Reporteru jsou na obrázku a obrázku příklady souhrnných agregovaných výstupů a na obrázku příklad statického výstupu.

5.1.6   Systém G3 v praxi

Systém G3 stále intenzívně vyvíjíme a jeho charakter je částečně prototypový. Přesto jsme jej v průběhu roku udrželi v permanentním chodu a podařilo se nám zajistit prakticky bezvýpadkové měření. V rámci páteřní sítě CESNET2 systém pracoval ve třech instalacích. První dvě s nakonfigurovanými identickými množinami sledovaných zařízení, ale s rozdílnými verzemi systému - jedna instalace jako určitá forma zálohy. Třetí instalace je experimentální, vývojová a konfigurovaná na sledování pouze velmi úzké množiny typově různorodých zařízení.

5.2   Sledování provozu sítě

V této oblasti se zaměřujeme na rozvoj systému FTAS (Flow-based Traffic Analysis System) a jeho efektivní využití v prostředí sítě CESNET2. V roce 2007 jsme se zabývali:

• využitím klasifikačních a filtračních vlastností systému v praxi pro analýzy především externího IP provozu sítě CESNET2,
• ověřováním možností systému v oblasti pro-aktivní detekce útoků a provozních anomálií v prostředí s proměnným dvoustupňovým vzorkováním vstupních informací (úroveň paketů, úroveň NetFlow záznamů).

5.2.1   Analýza externího IP provozu sítě CESNET2

Z hlediska topologie existuje pro externí provoz z/do sítě CESNET2 několik potenciálních cest, které jsou jak na fyzické úrovni, tak na IP úrovni distribuovány mezi několik páteřních uzlů. Systém FTAS pracuje v oblasti klasifikace obou částí (zdrojové i cílové) NetFlow záznamu se čtyřvrstvou hierarchií, která sestává ze tří administrativních úrovní a jedné technologické (filtrační podmínka pro klasifikaci). Součástí záznamů s konfigurací filtračních podmínek pro klasifikaci je i priorita podmínky - to umožňuje řízeným způsobem řešit situace, při kterých je pro danou část NetFlow záznamu validních více podmínek, např. překryv rozsahů adres v případě klasifikace síťového celku a zároveň nutnosti identifikovat jeho podsíť. Filtrační podmínka pro klasifikaci může být zároveň svázána s konkrétními zdroji NetFlow záznamů. To znamená, že informace o provozu, který má z hlediska klasifikace společný jmenovatel, mohou být sestaveny z dat pocházejících z různých zdrojů. Pro záznamy z různých zdrojů mohou být uplatněny naprosto odlišné filtrační podmínky (např.: rozsahy IP adres vs. čísla autonomních systémů vs. "nexthop" apod.). Těchto vlastností jsme využili při sestavování klasifikačního modelu a následné analýze externího provozu sítě CESNET2 podle jednotlivých směrů.

V průběhu roku jsme byli požádáni o realizaci experimentu s cílem pokusit se vyhodnotit externí provoz sítě CESNET2 v rámci jednotlivých směrů podle regionálního rozdělení zdrojů a cílů. Pro řešení jsme se rozhodli využít klasifikačních vlastností systému FTAS. Zdrojem klasifikačních informací byla exportní data všech regionálních registrátorů (AFRINIC, APNIC, ARIN, LACNIC, RIPE) obsahující regionální informace. Analyzovali jsme provoz přenášený protokolem IPv4 (provozní záznamy IPv6 nebyly k dispozici ze všech zdrojů). Postup řešení byl následující: Pomocí námi vytvořeného nástroje byly veškeré IPv4 adresní rozsahy získané z exportu registrátorů (cca 80 tisíc záznamů) rozčleněny podle regionálních údajů (úroveň zemí). Tyto záznamy byly dále klasifikovány pomocí údajů ISO-3166 podle jednotlivých kontinentů. Záznamy byly uskupeny podle kontinentů a následně agregovány adresní rozsahy v rámci kontinentu (cca 15 tisíc adresových rozsahů) a vytvořeny filtrační podmínky pro klasifikační záznamy systému FTAS se základní prioritou. V dalším kroku byla pro Evropu a část Severní Ameriky provedena sekundární kumulace podle jednotlivých zemí a opět byly vygenerovány filtrační podmínky - v tomto kroku s vyšší prioritou (cca 17 tisíc adresových rozsahů). Takto vytvořené záznamy (cca 55) byly přeneseny do systému FTAS (na obrázku je ukázka části výpisu konfiguračních záznamů pro klasifikaci).

Vlastní zpracování proběhlo na samostatné instanci systému FTAS. Vzhledem k celkovému toku vstupních NetFlow záznamů ze všech potřebných zdrojů v oblasti (okolo 30 tisíc záznamů za sekundu) a množství klasifikačních podmínek (cca 32 tisíc) bylo nutné pro bezeztrátové zpracování nastavit vstupní vzorkování na úrovni NetFlow záznamů. Použili jsme "bezpečnou" hodnotu 20, čímž jsme reálný tok NetFlow záznamů snížili na cca 1500 za sekundu. Mimo vlastní klasifikaci jsme nakonfigurovali filtry pro oddělení základních směrů externího provozu a následné agregované zpracování výsledků (hodinové agregáty podle regionálních údajů). Ukázky výstupů jsou k dispozici na obrázcích znázorňujících regionální rozdělení příchozího provozu, zpřesněné regionální rozdělení a zpřesněné rozdělení pro vybranou linku. Uvedené ukázky jsou zatíženy statistickou chybou v oblasti absolutních hodnot způsobenou vzorkováním vstupních dat na úrovni NetFlow záznamů.

5.2.2   Možnosti systému FTAS v oblasti pro-aktivní detekce útoků.

V oblasti podpory řešení bezpečnostních incidentů je systém FTAS doposud používán pro analýzu a verifikaci provozu souvisejícího s přijatými hlášeními. V rámci jeho rozvoje jsme v roce 2007 ověřovali jeho možnosti v oblasti pro-aktivní detekce útoků. Zaměřili jsme se při tom primárně na možnosti detekce DoS útoků v prostředí s proměnným vzorkováním na úrovni NetFlow záznamů. Při ověřování jsme postupovali ve dvou krocích.

V prvním kroku jsme rozšířili stávající možnost zadat v konfiguraci systému FTAS přímo zdrojový kód ve formě funkce podmiňující uložení NetFlow záznamu. Využili jsme tuto vlastnost pro základní rozdělení NetFlow záznamů a pro "zajímavé" záznamy (z hlediska možných útoků) jsme nakonfigurovali parametry pro následné zpracování ve formě specifických agregací. Signifikantní zdroje provozu v takto vygenerovaných výstupech jsme následně použili jako podmínky pro výběr ze všech uložených dat příslušného zdroje NetFlow a postupnou analýzou takto získaných informací jsme zpřesňovali experimentální konfiguraci.

Z obecného hlediska je vypovídací hodnota jednoho izolovaného NetFlow záznamu nedostatečná k rozhodnutí, zda reprezentuje DoS útok či nikoli. Ke kvalifikovanému rozhodnutí je třeba provést hlubší analýzu - např. vyhodnotit sekvenci záznamů s určitou historií podle různých kritérií nebo provést statistickou normalizaci a výsledek porovnávat z hlediska velikosti odchylky vůči statistickému průměru celkového provozu. V případech, kdy nelze uplatnit statistické metody (např. vzhledem k primárnímu účelu systému, jeho vnitřní architektuře nebo vzhledem k celkovému objemu NetFlow záznamů), je možné použít metodu krátkodobých agregací příslušných částí NetFlow záznamů za chodu. Zároveň je nutné po stejnou dobu uchovávat plnohodnotné NetFlow záznamy a teprve na základě vyhodnocení krátkodobě agregovaných informací rozhodnout o jejich dalším zpracování.

Způsob vyhodnocení pomocí krátkodobých agregací NetFlow záznamů jsme zvolili pro druhou fázi experimentu. Do řetězce pro vstupní zpracování byl začleněn modul, který na základě konfigurace provádí jednak krátkodobou agregaci podmnožiny polí NetFlow záznamů podle zdroje, případně podle cíle, a zároveň udržuje po potřebnou dobu původní NetFlow záznamy ve vyrovnávací paměti. Tato operace je velmi náročná na zdroje, proto je na vstupu každý NetFlow záznam krátce analyzován po obsahové stránce a na základě parametrů daných konfigurací (ukázku parametrů vstupního filtru obsahuje obrázek) systém rozhodne, zda bude dále zpracováván. Touto prerekvizitou se výrazným způsobem snižuje počet záznamů pro agregaci.

Po uplynutí doby pro krátkodobou agregaci (vztaženo ke zdroji resp. cíli přenosu) je agregát klasifikován a pokud je výsledná hodnota vyšší než limit zadaný v konfiguraci, jsou všechny související NetFlow záznamy ve vyrovnávací paměti (stejný zdroj/cíl) uloženy k dalšímu zpracování. Klasifikace probíhá na základě mnoha kritérií - počty paketů, jejich délka, množství a rozložení identifikátorů opačného konce přenosu apod. V této fázi je tedy rozhodnuto o tom, zda danou skupinu NetFlow záznamů považuje systém za důsledek útoku nebo provozní anomálie. Z dlouhodobého hlediska je nutné provést další krok ve zpracování těchto záznamů.

Množství dat, která reprezentují typické útoky identifikovatelné analýzou NetFlow, je vzhledem k principu vytváření NetFlow záznamů zpravidla nadstandardní (např. desetitisíce záznamů v případě různých scanů). Na druhou stranu je v běžné praxi žádoucí uchovávat informace o bezpečnostních problémech relativně dlouhou dobu. Aby toto bylo efektivní, je nutné data agregovat, a to tak, aby byl výsledný počet záznamů vztahujících se k jednomu útoku přijatelný (stovky) a zároveň nebyl ztracen charakteristický rys útoku. Pro vyřešení tohoto problému jsme využili standardní vlastnosti FTAS systému - vícestupňovou agregaci v modulu následného zpracování dat (viz. obrázek). Takže celý experimentální mechanismus v oblasti detekce útoků funguje zatím tak, že všechny NetFlow záznamy, které systém vyhodnotí jako validní, jsou v obsahově plnohodnotné podobě uchovávány po krátkou dobu - zpravidla v řádu dnů (lze konfigurovat) - a zároveň jsou s určitým zpožděním (zpravidla konfigurována 1 hodina) agregovány a v této výsledné podobě uchovávány dlouhodobě (v řádu měsíců).

Mechanismus pro vyhodnocení anomálií je začlenitelný (z pohledu FTAS systému) jak do procesu zpracování kompletního proudu NetFlow záznamů z primárních zdrojů (např. celý směrovač), tak do procesu zpracování záznamů příslušných konkrétnímu filtru - což je lépe využitelné v praxi (např. konkrétní trasa, konkrétní oblast sítě apod.). Ukázka konkrétního výstupu je uvedena na obrázku.

5.2.3   Systém FTAS v praxi.

Na systému FTAS probíhá průběžný vývoj, nicméně jednotlivé stabilizované fáze tohoto procesu umožňují povyšovat instalace v síti CESNET2 bez výpadků v měření a zpracování dat. V současné době běží v IP/MPLS páteři sítě CESNET2 tři instalace. První má distribuovanou architekturu a je určena k plošnému sledování celé IP/MPLS páteře, další slouží k realizaci specifických požadavků na analýzy provozu a poslední je experimentální, vývojová - pro testování vyvíjených částí. Mimo rámec páteřní sítě CESNET2 běží stabilizované verze u některých členů sdružení - konkrétně ČVUT v Praze v Dejvicích, Masarykovy Univerzity v Brně, Technické Univerzity v Liberci a mimo rámec účastníků sítě CESNET2 u Seznam.cz, a. s.

předchozí

obsah

následující