ARCHITEKTURA PROGRAMOVÉHO VYBAVENÍ MO- NITOROVACÍ SONDY NA BÁZI TOKŮ

Transkript

1 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV POČÍTAČOVÝCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS ARCHITEKTURA PROGRAMOVÉHO VYBAVENÍ MO- NITOROVACÍ SONDY NA BÁZI TOKŮ DIPLOMOVÁ PRÁCE MASTER S THESIS AUTOR PRÁCE AUTHOR Bc. PETR ŠPRINGL BRNO 2009

2 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV POČÍTAČOVÝCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER SYSTEMS ARCHITEKTURA PROGRAMOVÉHO VYBAVENÍ MO- NITOROVACÍ SONDY NA BÁZI TOKŮ SOFTWARE ARCHITECTURE FOR FLOW BASED MONITORING PROBE DIPLOMOVÁ PRÁCE MASTER S THESIS AUTOR PRÁCE AUTHOR VEDOUCÍ PRÁCE SUPERVISOR Bc. PETR ŠPRINGL Ing. TOMÁŠ MARTÍNEK BRNO 2009

3

4

5

6 Abstrakt Tato práce se zabývá návrhem a implementací architektury programového vybavení pro Flexibilní FlowMon sondu, což je zařízení monitorující vysokorychlostní sítě na základě datových toků, které je vyvíjeno v rámci projektu Liberouter. V práci je rozebrána problematika monitorování na základě datových toků, detailněji jsou popsány nejčastěji používané formáty pro zasílání dat z exportérů na kolektory - formáty NetFlow verze 5, NetFlow verze 9 a IPFIX. Práce obsahuje popis hardwarové části Flexibilní FlowMon sondy včetně jejích požadavků na programové vybavení, ze kterých návrh programové architektury vychází. Detailněji je popsána ta část programového vybavení, která byla v rámci této práce implementována. Klíčová slova Sít, IP tok, monitorování, NetFlow, formát, IPFIX, kolektor, FlowMon, sonda Abstract This thesis deals with design and implementation of software architecture for Flexible Flow- Mon probe, accessories for monitoring high speed computer networks based on IP flows. The probe has been developed in project named Liberouter. There is described flow based monitoring and export formats NetFlow version 5, NetFlow version 9 and IPIFX, which are very widely used. The thesis contains description of hardware part of Flexible FlowMon probe including its requirements for software, which are the base of the whole software architecture. There is detailed description of that part of software architecture which was implemented during the work on this thesis. Keywords Network, IP flow, monitoring, NetFlow, format, IPFIX, collector, FlowMon, probe Citace Petr Špringl: Architektura programového vybavení monitorovací sondy na bázi toků, diplomová práce, Brno, FIT VUT v Brně, 2009

7 Architektura programového vybavení monitorovací sondy na bázi toků Prohlášení Prohlašuji, že jsem tuto práci vypracoval samostatně pod vedením pana Ing. Tomáše Martínka. Další informace mi poskytli kolegové z projektu Liberouter. Uvedl jsem všechny literární prameny, ze kterých jsem čerpal Petr Špringl 20. ledna 2009 Poděkování Především bych rád poděkoval vedoucímu své práce panu Ing. Tomáši Martínkovi za odborné vedení a čas věnovaný konzultacím této práce. Také bych chtěl poděkovat kolegům z projektu Liberouter za poskytnutí informací a zajištění technické podpory při návrhu a implementaci. c Petr Špringl, Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informačních technologií. Práce je chráněna autorským zákonem a její užití bez udělení oprávnění autorem je nezákonné, s výjimkou zákonem definovaných případů.

8 Obsah 1 Úvod 3 2 Monitorování na základě datových toků NetFlow Systém monitorování Protokoly pro export dat NetFlow verze NetFlow verze Formát paketu Netflow verze Hlavička formátu NetFlow verze NetFlow verze 9 formát FlowSetu šablon NetFlow verze 9 formát datového FlowSetu IPFIX Definice IPFIX formátu Architektura Formát IPFIX zprávy Hlavička IPFIX zprávy IPFIX formát setu šablon IPFIX formát datového setu FlowMon sonda Flexibilní FlowMon sonda Monitorovací proces Architektura firmwaru HFE procesor HashGenerator FlowStateManager FlowProcessingUnit Flexibilita u FlowMon sondy Architektura programového vybavení Flexibilní FlowMon sondy Přípravná část Monitorovací část Webové konfigurační rozhraní Konfigurační démon Systém Netopeer Programová architektura Sekundární flowcache

9 5 Implementace programového vybavení Knihovna libcsfflow Generování firmare Vývojové nástroje a lokální konfigurace sondy Exportovací program Vzdálená konfigurace Komunikační systém Netopeer Webové rozhraní Konfigurační démon Vlastnosti implementace a další postup práce Závěr 49 Literatura 51 Seznam použitých zkratek 52 Seznam příloh 53 A Popis ovládání programů 54 B Popis metod rozhraní org.liberouter.netopeer 59 C Doxygen dokumentace 62 2

10 Kapitola 1 Úvod V poslední době dochází k obrovskému rozvoji informačních technologií a to především takových, které jsou vytvořeny nad počítačovými sítěmi a Internetem. Neustále se zvyšuje počet uživatelů, jež využívají informační prostředky pro přenos, ukládání a zpracování dat. S tímto souvisí rostoucí požadavky na přenosy většího množství dat po síti vyššími rychlostmi, přičemž se zcela automaticky předpokládá, že tyto přenosy budou probíhat spolehlivě a bezpečně. Ovšem tento samozřejmý požadavek je zcela netriviální, nebot s rostoucím počtem uživatelů Internetu také dochází ke zvyšování četnosti útoků, jejichž odhalování je stále náročnější. Současně také neustále rostou rychlosti počítačových sítí, které nyní dosahují až 10 Gbps, přičemž v brzké budoucnosti bude pravděpodobně dosaženo ještě rychlostí vyšších, což opět správu a detekci problémů na síti ještě více zkomplikuje. Proto je nutné vyvíjet stále nová zařízení, která budou sloužit pro správu a monitorování i nejmodernějších složitých počítačových sítí. Monitorovací zařízení slouží správcům sítí pro zjištění informací o stavu sítě či nastalých změnách v síti. Pokud tyto informace získá správce dostatečně včas, tak může na vzniklou situaci reagovat a řešit jí. Tato zařízení mohou upozorňovat na útoky, vyhodnocovat využívání jednotlivých služeb či přímo vytížení celé sítě, ale také třeba sloužit pro výpočty poplatků za služby. Existující zařízení umožňující monitorování sítě jsou dostatečně výkonnými nástroji pro použití na běžných rychlostech, ovšem při využití na vysokorychlostních sítích (>1 Gbps) již selhávájí. To je obvykle způsobeno tím, že monitorovací činnost není jedinou činností, kterou vykonávají, nebo jsou limitovány výkonem procesoru či propustností systémové sběrnice. Sít ový provoz je možné sledovat mnoha různými způsoby, přičemž každý poskytuje jiný druh informací či je prezentuje v jiné podobě. Příkladem jedné z metod je velmi využívaný SNMP (Simple Network Management Protocol), jenž slouží pro zasílání statistických dat ze sít ových prvků k jejich další analýze. Poskytuje informace založené na čítačích a určených podmínkách jako jsou počet přijatých paketů, počet chybných paketů. [1] V posledních letech získává na důležitosti především monitorování na základě datových toků, tzv. IP flows. Hlavním představitelem je v této oblasti firma CISCO [2], která v roce 1996 vyvinula metodu NetFlow. NetFlow poskytuje informace o komunikaci o IP přenosech a v jejich kontextu odpovídá na otázky: Kdo, co, kde, kdy, kolik a jak?. [5] Neboli vystihuje komunikaci mezi dvěma IP adresami pomocí určité služby probíhající na určitých portech v určitý čas a zahrnující určité množství přenesených dat. Vytváří stručný, ale výstižný záznam o komunikaci mezi každými dvěma počítači, tedy poskytuje detailní pohled na děje probíhající v síti. Umožňuje sledování aktivity uživatelů či využívání jednotlivých služeb, plánování architektury sítě, zvyšování bezpečnosti sítě včasným odhalováním útoků, 3

11 účtování sít ové služby a mnohé další. FlowMon sonda, pasivní monitorovací zařízení vznikající v rámci projektu Liberouter [12] je jedinečným nástrojem umožňující monitorovat vysokorychlostní sítě na základě datových toků. Funkčnost sondy je rozdělena mezi dvojici akceleračních karet se sít ovými rozhraními a hostitelský osobní počítač, do kterého jsou karty připojeny. Zcela podle principu hardware software co-design jsou rychlostně a výpočetně náročné operace prováděny pomocí programovatelných polí (FPGA) na akceleračních kartách a méně naročné, ale o to složitější části, jsou zajišt ovány programovým vybavením hostitelského počítače. Díky tomu je možné pomocí sondy monitorovat i nejmodernější sítě bez nutnosti vzorkování a to s přijatelným uživatelským rozhraním zprostředkovaným hostitelským osobním počítačem. Cílem této práce bylo navrhnout programovou architekturu nejnovější verze tzv. Flexibilní FlowMon sondy, jejíž hardwarová část právě vzniká, a následně navržené programové vybavení ve spolupráci s členy projektu Liberouter implementovat. Teoretický rozbor a návrh programového vybavení byl již částečně zpracován v rámci mého semestrálního projektu na FIT VUT v Brně [19]. V úvodu práce je popsán princip monitorování na základě datových toků a jeho rozdělení mezi exportéry a kolektory. Detailněji je rozebrána problematika exportovacích protokolů pro přenos dat na kolektory a jsou popsány nejvýznamější z nich - protokoly NetFlow verze 5, NetFlow verze 9 a IPFIX. Další kapitola je věnována popisu pevné části Flexibilní FlowMon sondy a analýze požadavků na její programové vybavení. Z této části vychází architektura programového vybavení pro ovládání a konfiguraci sondy, která byla v rámci této práce vytvořena. Následující část práce popisuje implementační detaily jednotlivých bloků vytvořené architektury. Závěrem jsou zhodnoceny vlastnosti implementovaných programových částí a navrženy možnosti dalšího pokračování práce. 4

12 Kapitola 2 Monitorování na základě datových toků Pro efektivní monitorování počítačové sítě je nutné zvolit takovou metodu, která bude poskytovat vhodný obraz o situaci na síti a to nejen za standardních podmínek, ale i v případě jejího vyššího zatížení či útoku. Navíc je nutné, aby byly získané informace poskytovány s co nejmenším zpožděním, nebot to ovlivňuje možnost na vzniklé situace včasně reagovat. V současné době je hlavním problémem monitorování vysokorychlostních sítí bez zkreslení, jež je způsobováno použitím vzorkování. S tímto také úzce souvisí problém s množstvím přenášených dat po síti, kdy není možné uchovávat veškeré informace o událostech v síti, ale je třeba je agregovat a vhodným způsobem prezentovat. Komunikace mezi prvky na síti probíhá prostřednictvím zasílání paketů. Zařízení nejprve svá odesílaná data rozdělí na části (segmenty). Dále segmenty podle typu komunikačního protokolu zabalí do paketů, které již obsahují informace o cílovém prvku. Pakety jsou postupně odesílány do sítě. Vzhledem k obrovskému množství paketů v síti není vhodné založit monitorování na základě sledování jednotlivých paketů, ale je třeba monitorovat na vyšší úrovni abstrakce. Jako vhodná metoda se jeví monitorování na základě datových toků. [18] 2.1 NetFlow Pojmem NetFlow se označuje metoda monitorování sítě na základě datových toků (tzv. IP flows), jež reprezentují komunikaci mezi dvěma IP zařízeními v síti. U každého paketu, který prochází přes monitorovací zařízení, je zkoumána množina jeho IP atributů. Pomocí těchto atributů se rozlišuje, ke kterému toku daný paket náleží. Datový tok je tvořen pakety, jež mají shodné všechny zkoumané IP atributy (klíčové IP atributy). Každý datový tok reprezentuje komunikaci na síti, a nebot se většina komunikace skládá z mnoha paketů avšak z výrazně méně toků, tak je současně dosahováno i výrazné agregace dat. Obvykle jsou datové toky založeny nad množinou pěti až sedmi klíčových IP atributů [5, 18], jsou to: zdrojová IP adresa, cílová IP adresa, zdrojový port, cílový port, 5

13 typ protokolu, druh služby (TOS), rozhraní monitorovacího zařízení. Celý princip činnosti metody NetFlow je zobrazen na Obrázku 2.1. V určitém vhodném bodě v síti (obvykle páteřní linka) dochází k monitorování na základě datových toků, což znamená že u veškerých procházejících paketů jsou zkoumány klíčové IP atributy. Na základě těchto klíčových atributů je daný paket bud přidán do již existujícího toku uloženého v paměti monitorovacího zařízení nebo je přidán jako tok nový, pokud ještě v paměti založen není. U každého toku se kromě informací z klíčových polí ukládají také informace, které charakterizují daný tok - např. počet paketů tvořících tok, velikost toku v bajtech (součet velikostí všech paketů), začátek toku (první paket toku), konec toku (poslední paket patřící danému toku) a další. SRC and DST IP addr SRC and DST port Protocol number Lifetime Number of packets Sum of bytes TCP flags Others Duration Proto Src IP Addr:Port Dst IP Addr:Port Flags Pack. Bytes TCP : :445.A TCP : :80.A.R TCP : :80.A.R UDP : : UDP : : TCP : :1358.AP Obrázek 2.1: NetFlow monitoring [13] Teoreticky by mohly být datové toky nekonečné, ale toto v praxi není možné a musí být určitým mechanismem zajištěno, aby v určitém časovém intervalu každý tok skončil. Toky jsou totiž vyhodnocovány až v okamžiku jejich ukončení (expirace). Dlouhotrvající komunikace by tedy byla vyhodnocena až s velkým zpožděním, což by výrazně snižovalo vypovídací hodnotu monitorování. 6

14 Datový tok může expirovat obvykle vlivem dvou nastavitelných vlastností - aktivní a neaktivní timeout. Datový tok je ukončen, pokud časová délka jeho neaktivity přesáhne neaktivní timeout, neboli pokud po dobu neaktivního timeoutu nepřišel žádny paket patřící do daného toku. Tímto způsobem je vlastně detekováno ukončení dané komunikace. Naproti tomu aktivní timeout slouží pro rozdělení dlouhotrvajících toků do několika různých toků, aby nedocházelo k tak velkému zpoždění v získávání informací při monitorování. Každý tok je ukončen, pokud je doba jeho trvání delší než hodnota aktivního timeoutu. 2.2 Systém monitorování Existují dvě základní možnosti, jak získávat informace o datových tocích. Prvním je obvyklý monitorovací systém, kdy monitorování a agregaci dat na základě datových toků provádí přímo směrovače. V tomto případě jsou ovšem omezení v rychlosti i spolehlivosti monitorování, nebot primárním účelem směrovačů je směrování paketů, což je pro ně často samo o sobě dosti náročné. Monitorování proto obvykle probíhá za pomoci vzorkování, kdy jsou zpracovávány pouze pakety vybrané určitou heuristikou, což samozřejmě zkresluje naměřené výsledky. Druhou možností je samostatný pasivní prvek sítě, který slouží jen pro monitorování a již nevykonává žádné další operace. Prochází skrze něj pakety, které si pouze zkopíruje a následně zpracuje. Díky tomu je docíleno vyšší rychlosti zpracování, vyšší propustnosti i vyšší bezpečnosti. Monitorování samo o sobě, at již prováděné směrovači nebo speciálními zařízeními, není dostatečnou činností, nebot je nutné také získaná data zpracovávat, analyzovat, vyhodnocovat, ukládat atp. Proto metoda NetFlow využívá celý monitorovací systém složený ze dvou základních prvků, kterými jsou exportéry a kolektory. Exportéry jsou umístěny na důležitých místech sítě jako jsou směrovače a brány a zajišt ují vlastní monitorovací činnost. Prochází přes ně pakety, které jsou analyzovány a sdružovány do datových toků. V okamžiku, kdy datový tok skončí, at již na základě aktivního, neaktivního timeoutu či jiné situace, tak je odeslán (exportován) na jeden či více vzdálených kolektorů k dalšímu zpracování.[8] Kolektory přijímají a zpracovávají příchozí toky od exportérů. Data ukládají do své databáze, vytvářejí různé statistiky, mohou zobrazovat grafy a statistická schémata. Dělají vše, aby bylo možné na základě jejich výstupů sledovat situace na síti a vytvářet dlouhodobé analýzy sít ového provozu. [8] Příklad možného grafického zobrazení na kolektoru zachycující komplexně situaci na síti v určitém okamžiku je na Obrázku 2.2, jenž vytvořil volně dostupný NFSen kolektor. Rozdělení monitorovacího systému mezi exportéry a kolektory má několik různých důvodů. Především je důležité si uvědomit, že monitorování vysokorychlostních sítí je v současné době skutečným problémem, nebot pakety prochází sítí obrovskými rychlostmi, a při monitorování je třeba nejenom tyto pakety analyzovat, ale také získané informace zpracovávat, ukládat, agregovat a vhodným způsobem zpřístupňovat uživateli - správci sítě. Proto je výhodné oddělit celý proces mezi více různých zařízení. Exportéry zajišt ují pouze analýzu paketů a tvorbu datových toků, což je nutné provádět přímo za běhu, zatímco následné operace, které již nejsou časově kritické, provádí vzdálené kolektory. Dalším důvodem je bezpečnost, kdy je vhodnější uchovávat nasbíraná data na dobře zabezpečeném kolektoru, jenž je mimo páteřní linku, na které se obvykle exportéry umíst ují. Toto schéma také přináší 7

15 Obrázek 2.2: NFSen kolektor [13] možnost rozdělit monitorovaná data mezi více kolektorů a tím konkrétní podmnožinu dat zpřístupnit pouze konkrétní skupině uživatelů. 2.3 Protokoly pro export dat Po ukončení datového toku na straně exportéru je nutné, aby byl co nejdříve odeslán na vzdálený kolektor. Toto odesílání může být prováděno různými způsoby pomocí různých protokolů určených pro export dat. Nejčastěji používanými jsou exportovací formáty firmy CISCO zvané Cisco NetFlow Export Format a protokoly z nich odvozené (např. IPFIX). Exportovací formát NetFlow má za sebou již víceletý vývoj. Byla vytvořena jeho již devátá verze, přičemž pouze některé verze byly a jsou skutečně využívány. V současné době je především využívána verze 5 a také se začíná prosazovat nejnovější verze, verze 9. Všechny verze jsou postaveny nad protokolem UDP a verze 9 oproti ostatním verzím vyniká především svými možnostmi rozšiřitelnosti a značnou flexibilitou. Stručné charakteristiky používaných verzí Cisco NetFlow Export Format jsou uvedeny v Tabulce 2.1. [3] NetFlow Export Format verze 1 verze 5 verze 7 verze 8 verze 9 Charakteristika první verze, nejjednodušší, používán jen výjimečně rozšířený formát, přidává podporu o BGP autonomních systémech a podporuje sekvenční číslování toků přidána podpora pro některé přepínače firmy CISCO nově podpora pro export agregačních dat z mezipamětí směrovačů nejnovější formát, dosti flexibilní a rozšiřitelný, založen na principu zasílání šablon pro popis formátu přenášených dat, na jeho bázi založen i další formát - IPFIX Tabulka 2.1: Vývoj exportovacího formátu NetFlow [18] 8

16 2.4 NetFlow verze 5 Jedná se o základní verzi formátu, která vychází z verze 1. Hlavní rozdíly jsou v přidání informací o monitorovacích systémech a sekvenčním číslování toků. Číslování toků je důležitou změnou, nebot je pro zasílání datagramů výhradně používán protokol UDP, který nezajišt uje jistotu doručení. Kolektor při příjmu datagramu odečte nejvyšší sekvenční číslo přijatého toku (sekvenční číslo + počet toků v datagramu) v předchozích datagramech od sekvenčního čísla právě přijatého datagramu a tím zjistí počet ztracených toků. [3] Tento formát má pevně danou strukturu. Skládá se z hlavičky ihned následované jedním až třiceti vlastních záznamů obsahující informace o jednotlivých tocích. Velikost hlavičky je 24 bajtů a má následující podobu: Pozice Obsah Popis 0-1 Verze NetFlow verze záznamů v paketu 2-3 Počet Počet toků v paketu (1-30) 4-7 Čas chodu systému Počet milisekund od spustění exportéru 8-11 UNIX čas Čas odeslání paketu zaznamenán v sekundách od UTC (Coordinated Universal Time), tedy od UNIX čas Část UNIX času v nanosekundách Sekvenční číslo Sekvenční číslo prvního toku v datagramu 20 Typ zařízení Typ monitorovacího zařízení 21 Port zařízení Port monitorovacího zařízení Rezervováno Nepoužité Tabulka 2.2: Hlavička NFv5 [3] Záznam popisující jeden tok má velikost 48 bajtů a má také přesně danou strukturu: Pozice Obsah Popis 0-4 Zdrojová adresa IP adresa zdrojového zařízení 4-7 Cílová adresa IP adresa cílového zařízení 8-11 Next hop IP adresa následujícího směrovače Vstup SNMP index vstupního rozhraní Výstup SNMP index výstupního rozhraní Pakety Počet paketů tvořící tok Počet oktetů Celkový počet bajtů v paketech (L3 vrstva) Začátek Systémový čas zařízení při zahájení toku Konec Systémový čas při přijetí posledního paketu toku Zdrojový port Použitý port na zdrojovém zařízení Cílový port Použitý port na cílovém zařízení 36 Zarovnání Nepoužité 37 TCP flagy Kumulativní OR TCP flagů 38 Protokol Použitý protokol 39 TOS Typ služby Zdrojový AS Autonomní systémové číslo zdrojového zařízení Cílový AS Autonomní systémové číslo cílového zařízení 9

17 44 Zdrojová maska Bitová maska prefixu adresy zdrojového zařízení 45 Cílová maska Bitová maska prefixu adresy cílového zařízení Zarovnání Nepoužité Tabulka 2.3: Záznam o toku NFv5 [3] Výhodou toho formátu je jeho jednoduchost a také pevně daná struktura, která umožňuje snadnou tvorbu exportovaných paketů na straně exportéru i jejich analýzu na straně kolektoru. Tento formát je v současné době nejvíce rozšířen a je podporován téměř všemi zařízeními pracujícími s datovými toky. Nevýhodou ovšem je nemožnost jeho rozšířitelnosti. Při exportu dat prostřednictvím NFv5 není možné sledovat jiné charakteristiky, než jaké jsou definovány v tomto formátu - resp. je možné je monitorovat, avšak se již dané informace nedostanou na kolektory. Určitou nevýhodou je i nutnost použití jako transportní vrstvu protokol UDP, který nezajistí doručení daných dat. Na druhou stranu by ale při použití např. protokolu TCP mohlo na vysokorychlostních sítí docházet k nestíhání odesílání exportovaných paketů vlivem nutnosti potvrzování a znovu zasílání ztracených paketů. Na Obrázku 2.3 je zobrazena část exportovaného paketu, jenž je analyzován pomocí programu wireshark. Je na něm dobře demonstrována jeho přesně daná podoba, která byla popsána výše. Obrázek 2.3: NetFlow verze 5 paket analyzován programem wireshark 10

18 2.5 NetFlow verze 9 Je to nejnovější verze NetFlow formátu, který byl vytvořen pro snadný export informací o datových tocích z exportérů na kolektory. Jeho hlavními výhodami oproti ostatním formátům jsou možnosti jeho rozšířitelnosti a jeho značná flexibilita. Tyto vlastnosti jsou dány tím, že je založen na systému zasílání šablon (templates), které popisují strukturu odesílaných dat. Šablony poskytují rozšiřitelnou podobu formátu s tím, že až v budoucnu dojde k vzniku nové vlastnosti NetFlow služby, kterou bude třeba také exportovat, tak se daná vlastnost přidá a popíše pouze v šabloně. A od tohoto okamžiku budou obě strany, přijímací (kolektor) i vysílací (exportér), snadno přijímat či vysílat informace o této nové vlastnosti. Je zcela patrné, že nebude nutné s novými vlastnostmi vytvářet stále nové verze formátu, ale bude zcela stačit přidání dané vlastnosti do stávajícího formátu. [4, 7] Exportéry vytváří exportované pakety (export packets), které jsou odesílány na vzdálené kolektory, kde dochází k jejich zpracování. [8] Tyto pakety se skládají z hlavičky (packet header) a z části nazývané FlowSet (viz Obrázek 2.4). Hlavička je první částí exportovaného paketu, která poskytuje základní informace o paketu jako jsou NetFlow verze, počet záznamů obsažených v paketu a číslování, pomocí kterého lze snadno zjistit ztrátu některého z paketů. FlowSet je druhou částí paketu a je to obecný pojem pro kolekci záznamů následujících za hlavičkou v exportovaném paketu. [4, 7] FlowSet Packet header Template FlowSet Data FlowSet... Template FlowSet Data FlowSet Obrázek 2.4: Paket NetFlow verze 9 Existují dva druhy FlowSetů, jeden druh obsahuje šablony (templates) a druhý data. Paket může obsahovat jeden nebo více FlowSetů a oba jejich typy se mohou v jednom paketu kombinovat (viz Obrázek 2.4). Kolekce jedné nebo více šablon (template record), které byly seskupeny v jednom paketu, se říká FlowSet šablon (template FlowSet). Šablona slouží k popisu sekvenčních dat, která mohou být v současném či v některém z budoucích exportovaných paketů odeslány na kolektor. Je důležité také poznamenat, že šablona nemusí nezbytně popisovat data v exportovaném paketu, ve kterém se vyskytuje. Naopak šablony jsou číslovány unikatním identifikačním číslem (template ID), které je později uvedeno u každého datového záznamu, aby bylo zřejmé, podle které z šablon byl vytvořen a musí být interpretován. Šablony se nemusí posílat v každěm paketu, ale stačí je v určitých intervalech obnovovat. Proto je nezbytné, aby měly kolektory určitou vyrovnávací pamět pro ukládání příchozích šablon. [4, 7] Stejně jako FlowSet šablon je kolekcí jedné či více seskupených šablon v paketu, tak FlowSet dat (data FlowSet) je kolekcí seskupených datový záznamů (data record), které jsou zásadní informační složkou NetFlow formátu. Datové záznamy poskytují informace o datových tocích, které byly expirovány na exportéru. Pomocí NetFlow formátu verze 9 je možné také zasílat informace o vlastnostech celého NetFlow monitorovacího procesu, kterými například jsou vzorkování dat či identifikace rozhraní, ze kterého data přichází atp. K tomuto slouží datové záznamy voleb (options data record), které jsou v duchu celého formátu popsány šablonami voleb (options template). [4, 7] 11

19 2.5.1 Formát paketu Netflow verze 9 Paket formátu NetFlow verze 9 se skládá vždy z hlavičky následované alespoň jedním Flow- Setem obsahující data nebo šablony. FlowSet šablon poskytuje popis jednotlivých polí, která budou využita v budoucích datových FlowSetech, které se ale mohou vyskytnout již v daném paketu. [4, 7] Existují tři možnosti přípustných kombinací FlowSetů v paketu: 1. Paket obsahuje různě prokládaně FlowSety se šablonami i s daty. Kolektor by v tomto případě neměl předpokládat, že šablony vložené v paketu mají nějaký zvláštní vztah k datovým FlowSetům v daném paketu. Kolektor si musí ukládat všechny přijaté šablony a k interpretaci datového FlowSetu použije šablonu, jejíž ID je shodné s identifikátorem uvedeným v datovém FlowSetu. 2. Paket obsahuje pouze datové FlowSety. Toto je nejčastější případ. Již byly odeslány veškeré šablony na kolektor, jsou dostatečně aktuální a nyní se zasílají pouze nasbíraná data. 3. Paket obsahuje pouze FlowSety se šablonami. Toto je nejméně častá situace, většinou se informace o šablonách zasílají spolu s nasbíranými daty. Používá se v situacích, kdy je třeba synchronizovat exportér s kolektorem jak nejrychleji to je možné, např. po restartu exportéru. Také je důležité, že šablony mají určitou dobu platnosti. Tedy je třeba šablony v určitých časových intervalech obnovovat a znovu zasílat na kolektor. A pokud právě nejsou žádná jiná data k odeslání, tak se může odeslat paket obsahující pouze šablony Hlavička formátu NetFlow verze 9 Formát hlavičky NetFlow verze 9 zůstává ve srovnání s dřívějšími verzemi v podstatě nezměněn, je postaven nad formátem hlavičky z NetFlow verze 5. Je pevně daná struktura jednotlivých polí, jejich velikost (až na vyjmenované výjimky jsou 32-bitové) i pořadí. Skládá se z těchto šesti polí: [4, 7] Verze (version) Počet (count) Čas chodu systému (system uptime) Vyjadřuje verzi NetFlow záznamů v paketu, pro verzi 9 se jedná o hodnotu 0x0009. Velikost pole je 16 bitů. Sděluje kolik FlowSetů (jak datových tak se šablonami) je obsaženo v paketu. Velikost pole je 16 bitů. Počet milisekund které uběhly od spuštění exportéru. UNIX čas Datum a čas odeslání paketu, který je zaznamenán v sekundách (UNIX seconds) od UTC (Coordinated Universal Time), tedy od Pořadové číslo (sequence number) Pořadové číslo paketu odesílaného exportérem, které slouží k detekci případných nedoručených paketů s daty. 12

20 ID zdroje (source ID) 32-bitová unikátní hodnota, která specifikuje zařízení, ze kterého byly pakety odeslány. Toto číslo je závislé na konkrétním výrobci NetFlow verze 9 formát FlowSetu šablon Jedním z klíčových prvků formátu NetFlow verze 9 je FlowSet obsahující šablony. Šablony zajišt ují výraznou flexibilitu formátu, nebot umožňují kolektorům správně interpretovat příchozí data bez předešlé znalosti formátu daných dat. Šablony jsou použity k popisu typu a délky jednotlivých polí uvnitř datových záznamů. Každý datový záznam NetFlow formátu obsahuje pole s jedinečným identifikátorem šablony, podle které byl záznam vytvořen a tedy má být i interpretován na straně kolektoru. FlowSet šablon se skládá z těchto polí, která mají výhradně velikost 16 bitů: [4, 7] Identifikátor FlowSetu Tento identifikátor slouží k rozlišení záznamů šablon od dat. (FlowSet ID) Má vždy hodnotu 0. Délka (length) Identifikátor šablony (template ID) Počet polí (field count) Typ pole (field type) Délka pole (field length) Vyjadřuje celkovou délku daného FlowSetu. Nebot mohou být šablony a tedy i FlowSety různě dlouhé, tak je nutné udávat tuto hodnotu, aby byl zřejmý začátek dalšího FlowSetu. Délka je vyjádřena v TLV (type/length/value) formátu, což znamená, že obsahuje v bajtech vyjádřenou délku FlowSetu včetně polí Identifikátor FlowSetu a Délka. Každá šablona má unikátní identifikační číslo, které slouží k jednoznačnému určení šablony. Určuje počet polí v dané šabloně. Je nezbytné, nebot jeden FlowSet může obsahovat více šablon, tedy slouží k určení konce dané šablony. Toto číslo vyjadřuje typ pole, tedy jakou informaci bude dané pole obsahovat v datovém záznamu. Definice hodnot vyjadřující určitý typ pole jsou zcela závislé na výrobci zařízení, ale obvykle se používají definice od firmy CISCO. V bajtech vyjádřená délka předcházejícího pole. Výše uvedená pole se mohou ve FlowSetu šablon opakovat takovým způsobem, aby bylo možné šablonou datový formát dostatečně popsat (viz Obrázek 2.5). Šablony musí být na kolektory v určitých intervalech znovu posílány a tím obnovovány, v jiném případě by došlo k jejich vypršení a zneplatnění na straně kolektoru. Existují dvě možnosti, jak šablony obnovovat. Posílat šablony vždy po uplynutí určitého časového intervalu nebo znovu zasílat šablony v každém N-tém paketu. [4, 7] 13

21 FlowSet ID = 0 Length... next fields Template ID Field Count Field 1 Type Field 1 Length Field N Type Field N Length Template ID Field Count Field 1 Type Field 1 Length... next fields Field M Type Field M Length... Obrázek 2.5: FlowSet šablon NetFlow verze 9 formát datového FlowSetu V datových FlowSetech se posílají informace o tocích. Každy FlowSet odpovídá některé z dříve zaslaných šablon a podle ní je také interpretován. Jeden FlowSet může obsahovat data o více tocích. Pokud k danému datovému FlowSetu není nalezena šablona, tak dochází k jeho zahození. Datový FlowSet se skládá z těchto polí: [4, 7] Identifikátor FlowSetu (FlowSet ID) Délka (length) Hodnoty toků (record N - field N) Zarovnání (padding) Obsahuje číslo šablony, podle které má být tento FlowSet interpretován. 16-bitová hodnota. Vyjadřuje celkovou délku daného FlowSet v TLV (type/length/value) formátu. 16-bitová hodnota. Hodnoty jednotlivých polí definovaných v odpovídající šabloně. Zarovnání na 32-bitovou hodnotu. I zarovnání se počítá do celkové délky(length). Na Obrázku 2.6 je vyobrazen ilustrativní příklad činnosti formátu NetFlow verze 9. Začátek exportovaného paketu tvoří jeho hlavička, z níž je zřejmé, že se jedná o NetFlow formát verze 9 a obsahuje tři FlowSety. Odpovídající exportér s identifikací 0xf101 již monitoruje 561 sekund a tento paket, jenž je již v pořadí šestým, odeslal v 15: Za hlavičkou paketu je první FlowSet, jehož identifikátor má hodnotu 0x0, tedy se jedná o FlowSet šablon o délce 40 bajtů. První šablona v tomto FlowSetu má číselný identifikátor roven hodnotě 258 a obsahuje čtyři 32-bitové položky - zdrojová a cílová IP adresa, počet paketů a bajtů. Následují další šablony, které již ale nejsou rozepsány. Za FlowSetem šablon následuje datový FlowSet, který byl vytvořen podle šablony číslo 258. Tento FlowSet má délku 52 bajtů, což vzhledem k délce šablony číslo 258 představuje informace o třech tocích, které stručně charakterizují komunikaci mezi dvojící počítačů (resp. zařízení). Např. mezi počítačem s IP adresou a počítačem s IP adresou došlo k výměně 10 paketů, které představovaly celkem 800 bajtů dat. Paket je ukončen dalším FlowSetem obsahující jednu šablonu. 14

22 Export Packet Header Template FlowSet Template record Template record Data FlowSet Data record Data record Data record Template FlowSet Template record Header x0003 0x0009 (count) (version) 561 (sysuptime) ( :47:56) 6 (package sequence) 0xf101 (source id) Template FlowSet (flowset id templates) 40 (length bytes) 258 (template id) 4 (field count)... IPv4_SRC_ADDR 4 (length) IPv4_DST_ADDR 4 (length) PKTS_32 4 (length) BYTES_32 4 (length) Data FlowSet (length) (flowset id) Obrázek 2.6: Schéma formátu NetFlow verze 9 Na Obrázku 2.7 je zobrazena část exportovaného paketu ve formátu NetFlow verze 9, jenž je analyzován pomocí programu wireshark. Paket obsahuje po úvodní hlavičce několik FlowSetů, přičemž první z nich je datový FlowSet odpovídající šabloně s identifikačním číslem 256. Tento FlowSet obsahuje informace o několika různých tocích v celkové délce 1152 bajtů. Je zřejmé, že formát NetFlow verze 9 pro odesílání dat z exportérů na kolektory je výhodný díky své výrazné flexibilitě a možnosti zasílat pouze skutečně potřebná data. Ovšem zřejmou nevýhodou je závislost tohoto formátu na společnosti CISCO, jež jej vytvořila. Neexistuje totiž ucelený standard, který by pevně a kompletně tento formát definoval. Toto samozřejmě přináší problémy se vzájemnou kompatibilitou zařízení (především mezi exportéry a kolektory), kdy každý z výrobců daného zařízení určitou vlastnost formátu implementoval mírně odlišně. 15

23 Obrázek 2.7: NetFlow verze 9 paket analyzován programem wireshark 2.6 IPFIX Vzhledem k tomu, že exportovací formáty NetFlow jsou proprietárními formáty společnosti CISCO, bylo snahou vytvořit nezávislý obecný standard pro export informací o datových tocích ze směrovačů, sond a dalších zařízení. Výsledkem této snahy je protokol IPFIX (Internet Protocol Flow Information Export), který vytvořila pracovní skupina IETF Internet Engineering Task Force). IPFIX standard definuje, jak mají být informace o datových tocích formátovány a přenášeny z exportérů na kolektory. IPFIX formát je definován v RFC dokumentech, přičemž formát NetFlow verze 9 od společnosti CISCO byl použit jako předloha tohoto nového standardu. [17] IPFIX protokol je někdy označován jako NetFlow verze 9 implementovaný nad transportním protokolem SCTP a obsahující několik dalších změn. Je to i proto, že výrazně větší změnu představoval vznik protokolu NetFlow verze 9 oproti předchozí verzi 5 než vznik IPFIXu, jehož hlavní výhodou je právě jeho nezávislost a obecnost Definice IPFIX formátu Pro formát IPFIX byly pevně definovány veškeré pojmy, aby byla vyloučena jakákoliv možnost nesprávné interpretace. RFC dokumenty IPFIX formátu definují pojmy, které se v rámci řady protokolů NetFlow vůbec nepoužívají nebo které nebyly dříve definovány či dokonce i takové, které byly dříve definovány mírně odlišně. Avšak základní myšlenka 16

24 monitorování na základě datových toků i princip činnosti zůstávají zcela nezměněny. Zařízení zajišt ující monitorování na základě datových toků jsou stále označovány jako exportéry a vzdálená zařízení analyzující nasbíraná data se označují jako kolektory. Vlastní proces sběru dat je označen jako měřící proces (metering process), který se uskutečňuje v tzv. pozorovacím bodě (observation point), což je vlastně označení monitorovacího zařízení. Pozorovací bod je součástí pozorovací domény (observation domain), což je největší možná množina pozorovacích bodů, pro které mohou být agregovány informace v rámci měřícího procesu (tzn. před vlastním exportem na kolektory). [6] Pro datový tok, resp. tok (IP traffic flow, flow) existuje v internetové komunitě několik definicí. IPFIX protokol definuje datový tok následovně: Datový tok je definován jako množina IP paketů procházejících pozorovacím bodem v síti během určitého časového intervalu. Všechny pakety náležící určitému jedinému toku mají množinu vlastností. Každá vlastnost je definována jako výsledek aplikace funkce na hodnotu: 1. jedné nebo více položek z hlavičky paketu (např. cílová IP adresa), z hlavičky paketu transportní vrsty (např. cílový port) nebo hlavičky paketu aplikační vrstvy, 2. jedné nebo více samotných charakteristik paketů (např. MPLS tagy), 3. jedné nebo více polí odvozených při zpracování paketů (např. next hop, výstupní rozhraní). Paket náleží danému toku, pokud jsou splněny všechny definované (určené) vlastnosti toku. Všechny položky hlaviček paketů, které se podílí na získání hodnoty určené vlastnosti, jsou označovány jako klíčové položky. [6] Je zřejmé, že tato definice je výrazně obecnější než definice použitá pro NetFlow formáty a umožňuje tedy mnohem větší flexibilitu monitorování, které může být uzpůsobeno přímo pro konkrétní sít či situaci. Dle této definice je možné za datový tok označit např. soubor paketů obsahující stejné zdrojové a cílové IP adresy a typ protokolu - viz Obrázek 2.8. Num. Src IP Addr Dst IP Addr Proto Pack TCP TCP UDP TCP 20 Obrázek 2.8: Toky - klíčové položky: IP adresy a typ protokolu Num. Src IP Addr Dst IP Addr Proto Pack / /26 TCP / /26 UDP / /26 TCP 20 Obrázek 2.9: Toky - klíčové položky: IP adresy s maskou /26 a typ protokolu Můžeme ale také mírně modifikovat vlastnosti, na základě kterých se pakety sdružují do toků, a to např. tak, že na IP adresy aplikujeme funkci 26-bitové masky. Poté množina zcela stejných paketů dává odlišné datové toky, které mají samozřejmě i odlišnou vypovídací schopnost - viz Obrázek

25 2.6.2 Architektura IPFIX rozděluje celé monitorování na základě datových toků do tří základních procesů, kterými jsou: [6] měřící (metering process), exportovací (exporting process) a sběrný proces (collecting process). Měřící proces se skládá z celé množiny funkcí, které zahrnují zachytávání a analýzu hlaviček paketů, práci s časovými značkami, vzorkování paketů, hodnocení a správu datových toků. Správa datových toků obsahuje vytváření nových toků, obnovování toků existujících, počítání statistik jednotlivých toků, detekce expirace toku, přeposílání expirovaných toků do exportovacího procesu a mazání takových toků. Exportovací proces zahrnuje zasílání záznamů o tocích do jednoho či více sběrných procesů. Exportér je zařízení, které hostí jeden či více exportovacích procesů, zatímco IPFIX zařízení představuje libovolné zařízení, které hostí minimálně jeden exportovací proces. Může tedy zahrnovat různý počet exportovacích procesů a libovolný počet sledovacích bodů a měřících procesů. Z toho plyne, že IPFIX zařízení nemusí samo o sobě data sbírat, ale třeba je jen přijímat od jiných zařízení. Sběrný proces přijímá záznamy o tocích z jednoho či více exportovacích procesů a tyto záznamy ukládá či dále zpracovává. Kolektorem je označováno zařízení hostící jeden či více sběrných procesů. IPFIX standard definuje možné způsoby expirace toků, kterými jsou aktivní a neaktivní timeout stejně jako u NetFlow, avšak je navíc doplněna možnost expirovat tok na základě dosažených limitů IPFIX zařízení, což může být například zaplnění paměti. IPFIX také povoluje definovat různá pravidla na příchozí pakety do měřícího procesu, kterými mohou být vzorkování (sampling) a filtrování (filtering). Stejně jako NetFlow verze 9 je i IPFIX postaven nad principem využívání šablon. Šablona (template) je definována jako seřazená sekvence dvojic typ a velikost (type, length), které se používají pro úplnou specifikaci struktury a sémantiky dílčích množin informací, jež jsou nutné pro komunikaci z IPFIX zařízení do kolektoru. Každá šablona je označena jednoznačným identifikačním číslem šablony (template ID). Informace zasílané z IPFIX zařízení se dělí do dvou skupin. Jedná se o řídící informace (control information) a datové streamy (data stream). Řídící informace zahrnují definice toků, výběrová kritéria pro pakety odesílané do exportovacího procesu a definice šablon odesílaných dat. Řídící informace tedy zahrnují veškeré informace potřebné pro koncové body komunikace, aby bylo možné rozumět IPFIX protokolu a správně data interpretovat. Datový stream zahrnuje záznamy o tocích. Kontrolní informace i datové streamy se posílají z exportovacího do sběrného procesu prostřednictvím IPFIX zpráv (IPFIX message), což je ve své podstatě analogický pojem k exportovanému paketu v NetFlow formátech. [6] Formát IPFIX zprávy IPFIX zpráva se skládá z hlavičky zprávy následované jedním nebo více sety informací, kterými mohou být datový set (Data Set), set obsahující šablony (Template Set) nebo set obsahující šablony voleb (Options Template Set). Tyto sady se mohou navzájem střídat a 18

26 býti v libovolném pořadí - viz Obrázek Veškeré informace v IPFIX zprávách musí být uspořádány v sít ovém pořadí bajtů (známé také jako uspořádání bajtů big-endian). IPFIX Message: Message header Template Set Data Set... Opt. Template Set Data Set Obrázek 2.10: IPFIX zpráva IPFIX zpráva je zabalena do protokolu transportní vrstvy, přičemž je možné použít protokoly: [6] SCTP - umožňuje spolehlivý i nespolehlivý přenos, musí být vždy implementován, TCP - poskytuje pouze spolehlivý přenos, UDP - poskytuje pouze nespolehlivý přenos. Často je případná ztráta paketů minimalizována využitím speciální ethernetové linky určené pouze pro export dat z exportéru na kolektor. Protokol IPFIX neposkytuje žádný mechanismus pro nastavení spojení mezi exportovacím a sběrným procesem. Toto spojení zcela zajišt uje protokol nižší vrstvy (transportní vrstvy). [15] Hlavička IPFIX zprávy Formát hlavičky IPFIX zprávy se velmi podobá formátu hlavičky NetFlow verze 9. Má přibližně stejnou vypovídací hodnotu, ale oproti NetFlow verze 9 neobsahuje informaci o čase chodu systému a délka celé zprávy je udána v bajtech a ne v počtech FlowSetů. Pevně daná struktura jednotlivých polí, jejich velikost (až na uvedené vyjímky se jedná o 32-bitová pole) i pořadí v hlavičce IPFIX zprávy je následující: Číslo verze (version number) Délka (length) Čas exportu (export time) Pořadové číslo (sequence number) ID sledované domény (observation domain ID) Vyjadřuje verzi exportovacího formátu v dané zprávě, pro IPFIX zprávu se jedná o hodnotu 0x000a. Pole je 16-bitové. Celková délka IPFIX zprávy počítaná v bajtech včetně hlavičky. Velikost pole je 16 bitů. Datum a čas odeslání zprávy, který je zaznamenán v sekundách od UTC (Coordinated Universal Time). Pořadové číslo zprávy odesílané exportérem, které slouží k detekci případných nedoručených zpráv. 32-bitový identifikátor sledované domény, který je unikátní vůči exportovacímu procesu. 19

27 2.6.5 IPFIX formát setu šablon Sady šablon jsou zásadním prvkem formátu, což je stejné jako u NetFlow verze 9. Ale liší se v tom, že informační elementy (information element) a jejich datové typy, ze kterých je šablona sestavena a které popisují odpovídající datové sety, mají přiřazené unikátní hodnoty, jež jsou registrovány v seznamu spravovaném organizací IANA (Internet Assigned Numbers Authority). Tímto je zajištěna jednoznačnost při interpretaci šablon na různých zařízeních. [6] Šablony jsou použity k popisu typu a délky jednotlivých polí uvnitř datových záznamů. Pro nalezení správné šablony jsou použity jedinečné číselné identifikátory šablony (hodnota vyšší než 255). Set šablon se skládá z těchto polí, která mají velikost 16 bitů (kromě uvedených výjímek): Identifikátor setu (set ID) Délka (length) ID šablony (template ID) Počet polí (field count) ID inf. elementu (inform. element ID) Délka elementu (field length) Číslo organizace (enterprise number) Tento identifikátor slouží k rozlišení záznamů šablon od dat. Pro šablony má hodnotu 2 (resp. 3 v případě šablony voleb). Vyjadřuje celkovou délku daného setu v bajtech včetně hlavičky setu i zarovnání. Slouží pro určení začátku následujícího setu. Každá šablona má unikátní identifikační číslo vyšší než hodnota 255, které slouží k jednoznačnému určení šablony. Určuje počet polí v dané šabloně. Je nezbytné, nebot jeden set může obsahovat více šablon, tedy slouží k určení konce dané šablony. Toto číslo vyjadřuje typ pole, tedy jakou informaci dané pole bude obsahovat v datovém záznamu. V bajtech vyjádřená délka předcházejícího pole. IANA číslo organizace, která definovala daný informační element. V případě definice daného informačního elementu organizací IETF nemusí být toto pole přítomno. Velikost pole je 32 bitů. Výše uvedená pole se mohou v setu šablon opakovat takovým způsobem, aby bylo možné dostatečným způsobem šablonou popsat datový formát - viz Obrázek Prvních 16 bitů představuje identifikátor setu, který je roven hodnotě 2, což znamená že se jedná o set šablon. Následující 16-bitová hodnota udává velikost celého setu v bajtech. V dalších dvou 16-bitových hodnotách již očekáváme identifikátor šablony a počet polí v ní definovaných. Nyní již následují 16-bitové hodnoty představující vlastní šablonu a tedy i popis odpovídající datové části. Tento popis je zapsán prostřednictvím dvojic číselný identifikátor pole a velikost daného pole. Za posledním položkou šablony ihned následuje šablona další, která samozřejmě začíná svým číselným identifikátorem. 20

28 Length Field Count = N Field Length 1.1 Field Length 1.2 Enterprise Number 1.1 Set ID = 2 Template ID = 256 Inform. Element ID 1.1 Inform. Element ID Field Length 1.N Inform. Element ID 1.N Field Count = M Template ID = 257 Field Length 2.1 Inform. Element ID Field Length 2.M Inform. Element ID 2.M Optional Padding Obrázek 2.11: IPFIX formát setu šablon IPFIX formát datového setu V datových setech se posílají informace o tocích. Každy set odpovídá některé z dříve zaslaných šablon a podle ní je také interpretován. Jeden set může obsahovat data o více tocích. Pokud k danému datovému setu není nalezena šablona, tak dochází k jeho zahození. Datový set se skládá z těchto polí (až na vyjmenované výjimky 32-bitová): ID setu (Set ID) Délka (length) Hodnoty toků (record N - field M) Zarovnání Obsahuje číslo šablony, podle které má být tento set interpretován. 16-bitová hodnota. Vyjadřuje celkovou délku daného setu v bajtech včetně hlavičky setu i zarovnání. Slouží pro určení začátku následujícího setu. Hodnoty jednotlivých polí definovaných v odpovídající šabloně. Volitelné zarovnání na 32-bitovou hodnotu. Princip činnosti IPFIX formátu je totožný s principem popsaným a ilustrovaným na Obrázku 2.6. Jediný rozdíl je v mírně odlišném datovém formátu setů a označení jednotlivých částí. 21

29 Kapitola 3 FlowMon sonda FlowMon sonda je zařízení vyvíjené v rámci projektu Liberouter sloužící pro monitorování vysokorychlostních sítí na základě datových toků. Prvotní verze sondy byla navržena pro 1 Gbps sítě, na kterých probíhalo monitorování bez ztráty paketu. Ovšem při nasazení na 10 Gbps sítích již nebylo možné monitorovat bez použití vzorkování nebo dokonce ztráty výrazné části paketů vlivem přijímání velkého množství paketů vysokými rychlostmi. Proto bylo nutné vytvořit zcela novou verzi sondy, pomocí níž by bylo možné sledovat sítě pracující na 10 Gbps a v budoucnu případně i 40 Gbps sítě. Nová verze sondy byla označena jako Flexibilní FlowMon sonda, nebot při tvorbě návrhu nové architekury firmwaru sondy nebyl kladen důraz pouze na zrychlení původní verze, ale také na možnost konfigurovat vlastní monitorování na základě datových toků. Tedy v duchu flexibilních exportovacích formátů (NetFlow verze 9, IPFIX) umožnit uživateli specifikovat, jaké informace jej zajímají. S vznikem kompletně nové architektury samozřejmě souvisí také nutnost navrhnout a vytvořit novou architekturu navazujícího programového vybavení, což bylo cílem této práce. [12] 3.1 Flexibilní FlowMon sonda FlowMon sonda je založena na bežném osobním počítači s operačním systémem Linux obsahujícím dvojici akceleračních karet (pozn.: akcelerační karty nesou označení COMBO karty, Obrázek 3.1 ukazuje jednu z nich), které jsou vyvíjeny v rámci projektu Liberouter. Jedná se o hlavní kartu zapojenou do PCI sběrnice základní desky, k níž je připojena druhá z karet mající 2 až 4 sít ová rozhraní. Na obou kartách jsou mimo jiné programovatelné čipy (FPGA), jež umožňují zpracovávat velká množství dat vysokými rychlostmi. Karty poskytují jednotné rozhraní použitím platformy NetCOPE [12] pro přístup k periferním rozhraním (sít ová rozhraní, paměti, PCI sběrnice), které umožňuje relativně rychlou implementaci celé architektury firmwaru a odstíňuje konkrétní použitou dvojici akceleračních karet (např. mající různá sít ová rozhraní atp.). [21, 22] U původní verze FlowMon sondy bylo rozdělení činností mezi hardware (akcelerační karty) a software (programové vybavení OS Linux) takové, že veškeré operace související s monitorování na základě datových toků prováděly akcelerační karty a programové vybavení sloužilo pouze k nastavování vlastností monitorování, vyčítání expirovaných toků a jejich odesílání na vzdálené kolektory. Akcelerační karta byla plně vytížena, zatímco procesor počítače byl využit přibližně z pěti procent. Při návrhu Flexibilní FlowMon sondy byly brány v podtaz zkušenosti zjištěné používáním předchozích verzí a bylo rozhodnuto o rozdělení vlastního monitorovacího procesu 22