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

30 Obrázek 3.1: COMBO karta [12] mezi akcelerační kartu a osobní počítač. Toto je výrazná změna v přístupu k implementaci celé sondy oproti předchozím verzím, která umožňuje zjednodušení, a tím i zrychlení části firmwaru a také zkvalitnění celého monitorovacího procesu. Ale na druhé straně nese vyšší požadavky na programové vybavení a využití osobního počítače. 3.2 Monitorovací proces Monitorovací proces u Flexibilní FlowMon sondy je rozdělen do dvou častí mezi akcelerační karty (COMBO cards) a osobní počítač (host PC). Prostřednictvím rozhraní na akcelerační kartě jsou přijímány pakety ze sítě a zpracovávány na základě datových toků. Toky, které jsou uvolněny z pamětí akceleračních karet, jsou přenášeny do hostitelského osobního počítače, kde je rozhodnuto o jejich dalším zpracování na základě datových toků nebo o jejich exportu na kolektory s využitím exportovacích formátů NetFlow verze 5 či 9 nebo IPFIX (viz Obrázek 3.2). [21, 22] COMBO cards flow records host PC packets Monitoring process 1 Monitoring process 2 NetFlow v5, v9, IPFIX Obrázek 3.2: Koncept Flexibilní FlowMon sondy [22] Detailnější popis rozdělení monitorovacího procesu do dvou stupňů je následující. Na akcelerační kartě dochází postupně k: příjem paketů ze sítě, extrakce informací z hlaviček paketů (vrstvy L2, L3, L4), z klíčových polí toku vytvořena hash, která je přímo adresa v paměti pro uložení daného toku, 23

31 kolize toků v paměti jsou řešeny expirací toku a jeho přepsáním tokem novým, expirované nebo kolizní toky jsou přeneseny do paměti hostitelského osobního počítače. Celý proces pokračuje v hostitelském osobním počítači: příjem toků pomocí přímého přístupu do paměti (DMA), druhá část monitorovacího procesu - agregace příchozích toků s odpovídajícími toky v paměti počítače, export expirovaných toků z paměti počítače na kolektory. Je zřejmé, že vlastní monitorování již skutečně neprovádí pouze akcelerační karta, ale probíhá (pokračuje) i v programovém vybavení počítače. Tím je umožněno výrazné rozšíření celkové paměti pro ukládání informací o tocích, které již nebylo možné dále rozšiřovat na akcelerační kartě vlivem omezených pamět ových kapacit na kartě. Při monitorování na vysokorychlostních sítích je právě nedostatečné pamět ové úložiště jedním z výrazných problémů, nebot v případě nedostatečné paměti dochází k násilnému ukončení toků a tím i ke snižování vypovídací hodnoty monitorování a výrazně vyššímu zatěžování sítě při exportu informací o tocích na kolektory. Rozdělení úlohy na dvě části snižuje výskyt fragmentovaných toků, tedy toků, které expirovaly z jiného důvodu než na základě aktivního či neaktivního timeoutu (např. kolize, nedostatek paměti). Na základě testů bylo zjištěno, že agregace kartou sníží rychlost příchozích paketů na méně než jednu desetinu původní hodnoty, což umožní procesoru počítače zpracovávat všechny příchozí toky z karty a dále je agregovat a sondě zpracovávat celý provoz 10 Gbps linky. 3.3 Architektura firmwaru Základ Flexibilní FlowMon sondy tvoří akcelerační karty, které obsahují programovatelná hradlová pole (FPGA). Tato pole je vždy třeba nejprve naprogramovat, což se provádí prostřednictvím nahrání odpovídajícho firmware. Firmware vzniká překladem (resp. syntézou) zdrojových souborů popisující architekturu a procesy probíhající v FPGA - popisují firmware Flexibilní FlowMon sondy. Firmware Flexibilní FlowMon sondy využívá firmwarové platformy NetCOPE a Flow- Context. Platforma NetCOPE sdružuje nízkoúrovňové bloky určené pro přístup ke zdrojům karty a poskytuje k nim konfigurovatelné rozhraní. Těmito bloky jsou zejména sít ová rozhraní, vysokorychlostní sběrnice pro přístup ze strany hostitelského počítače a softwarový ovladač. FlowContext zajišt uje možnost analyzovat a pracovat s příchozími pakety na bázi toků paketů (více k platformám NetCOPE a FlowContext viz [12]). Činnost firmwaru Flexibilní FlowMon sondy je následující. Firmware NetCOPE přijímá pakety, které je schopen také vzorkovat na základě požadavku z firmwaru FlowMon sondy. Tyto požadavky jsou získávány od uživatele prostřednictvím programové vrstvy na hostitelském počítači. Na vstupu je paketům přiřazena časová značka a jsou posílány do Flow- Mon firmwaru. Zde dochází k extrahování položek z hlaviček paketů (sít ové vrsty L2, L3 a L4; zajišt uje komponenta HFE procesor) a jsou získávány informace nezbytné k vytvoření záznamu o toku, ostatní informace jsou zahozeny. Informace získané z paketu jsou předány FlowContext firmwaru, jenž zajistí vyčtení existujícího záznamu o toku z paměti 24

32 a jeho přidělení (společně s daty o paketu) FlowProcessingUnit jednotce (FPU). FPU zajistí aktualizaci hodnot v záznamu a uloží záznam zpět, pokud není důvod k jeho expiraci. V případě expirace je záznam přeposlán do výstupního bufferu, odkud je proveden přenos do softwaru hostitelského počítače. [21, 22] NetCOPE External memory External memory Input Buffers HFE cover Hash generator Flow state manager Flow context block Sampling NetCOPE SW buffer NetCOPE Obrázek 3.3: Blokové schéma firmwaru [22] Postup zpracování paketu: pakety s časovou značkou jsou získávány od NetCOPE, pakety jsou distribuovány mezi několik HFE instancí, HFE extrahuje informace z paketu a vytvoří UH hlavičku, následuje zbytek paketu, HashGenerator spočítá hash, která je používána jako adresa/identifikátor toku, FlowStateManager podle záznamu upraví časové údaje o toku, FlowContext připraví záznam o toku z paměti a pošle ho do FPU, FPU jednotka upraví statistiky, či expiruje záznam a předá ho části NetCOPE, která provede DMA přesun do softwaru HFE procesor HFE (Header Field Extractor) procesor je hardwarová jednotka sloužící pro získávání informací z hlaviček příchozích paketů, ze kterých vytváří tzv. UH hlavičky. Nadále se již pracuje právě s těmito hlavičkami, nebot pro monitorování na základě datových toků nejsou potřeba celé pakety, ale pouze informace z jejich hlaviček. U Flexibilní FlowMon sondy je možné, aby si uživatel před vytvořením firmwaru definoval strukturu UH hlavičky včetně jejího obsahu a tím si vybral položky z hlaviček paketů, které jej při monitorování zajímají. HFE jednotka je implementována v jazyce Handel-C, který je modifikací standardního jazyka C pro popis paralelních výpočtů. Vlastní zdrojový kód HFE procesoru je velmi složitý, proto 25

33 bylo uživateli umožněno definovat strukturu UH hlavičky prostřednictvím konfiguračního souboru, jenž je používán při překladu této jednotky. [21, 22] Požadavek na programové vybavení této jednotky je umožnit uživateli snadno definovat položky z hlaviček příchozích paketů, které se budou podílet na monitorování, a tím vlastně přizpůsobit celý firmware vlastním požadavkům HashGenerator HashGenerator je velmi jednoduchá jednotka, která podle bitového pole zadaného při konfiguraci firmwaru vybere klíčová slova (vymaskuje neklíčová) z UH hlavičky. Na těchto slovech vypočítá pro každou UH hlavičku hash, kterou před ní následně uloží. Tato hash slouží k adresaci toku příslušného paketu, proto hash musí být co nejkvalitnější (např. MD5 či CRC). Vstupem HashGenerator jednotky je UH hlavička a výstupem pak také UH hlavička, ale s přidaným identifikátorem (hash). [21, 22] Maska pro výpočet hash musí být nastavena prostřednictvím programového vybavení hostitelského počítače a je možné ji i během používání sondy měnit. Při startu sondy je také nutné hash funkci inicializovat náhodnou hodnotou FlowStateManager Jednotka FlowStateManager slouží pro expiraci již nepoužívaných toků, tedy takových, které neobdrželi po určitou dobu žádný paket. Tato doba se nazývá neaktivní timeout a je možné její hodnotu volit kdykoliv během používání sondy. Jednotka kontroluje všechny toky vzhledem k hodnotě neaktivního timeoutu a informuje FlowProcessingUnit o tocích, které mají být uvolněny. FlowStateManager přijímá UH hlavičky paketů z jednotky HashGenerator. Příchozí pakety způsobují obnovu časového příznaku pro daný tok. Aktualní čas mínus časový příznak toku značí délku neaktivity toku. Pokud je tok neaktivní po dobu delší než je nastavený neaktivní timeout, pak je k toku poznačen příznak neplatnosti časové značky. FlowState- Manager na takový tok vygeneruje požadavek na expiraci, který zašle FlowProcessingUnit přes FlowContext. [21, 22] Tuto jednotku není třeba z programového vybavení počítače žádným způsobem konfigurovat. Žádoucí je pouze umožnění vyčítání stavových informací z dostupných registrů vývojářům ve fázi ladění firmwaru sondy FlowProcessingUnit Jednotka FlowProcessingUnit (FPU) má za úkol aktualizovat záznam o toku informacemi získanými z příchozího paketu. Záznam i informace o paketu jí jsou poskytnuty FlowContextem. Protože se zpracování záznamu jeví jako časově náročný úkol, tak je tato jednotka instancována dvou a vícekrát, na což je FlowContext připraven. [21, 22] Jednotka také provádí kontroly nad klíčovými poli (identifikující tok) pro shodu záznamu o toku (context) a UH hlavičkou - zda daný paket reprezentovaný UH hlavičkou skutečně náleží danému toku a nedošlo ke kolizi. Tyto kontroly (včetně dalších jako např. aktivní timeout), ale i popis UH hlavičky, vlastního záznamu o toku a definice operací nad položkami jsou popsány v konfiguračním xml souboru (viz [21]). FPU jednotka musí veškeré tyto informace reflektovat a na základě nich musí být korektně vygenerována v době přípravy firmwaru - tzn. před vlastní monitorovací činností sondy. Toto vygenerování FPU jednotky 26

34 musí probíhat automaticky a samostatně pouze na základě popisu monitorovacího procesu v daném konfiguračním xml souboru, aniž by uživatel musel jakkoliv interreagovat. 3.4 Flexibilita u FlowMon sondy Výstupy monitorovacího procesu na základě datových toků lze použít mnoha způsoby, přičemž v každé síti a pro každého správce sítě mohou být důležité jiné informace o síti. Avšak vzhledem k jasným omezením, jak na straně hardware tak i software není možné do monitorování zahrnout veškeré možné informace, které by sledování na základě datových toků mohlo poskytovat. Při vývoji Flexibilní FlowMon sondy bylo proto rozhodnuto o poskytnutí uživateli jistého stupně flexibility. Tato flexibilita spočívá v možnosti určit jaké konkretní charakteristiky se mají sledovat. To ovšem není možné dosáhnout pouze prostřednictvím modifikací programového vybavení v hostitelském osobním počítači, ale je nutné určitou flexibilitu zabudovat i do vlastního firmwaru sondy. Avšak firmware pro programovatelná hradlová pole FlowMon sondy není možné vytvořit obecně a modifikovat pouze konfigurací, nebot by pak nebylo možné splnit další požadavky kladené na sondu - např. dostatečná rychlost. Bylo tedy nutné flexibilitu zajistit jiným způsobem, který spočívá ve vytvoření firmwaru před zahájením vlastního monitorování a to přesně podle požadavků uživatele na monitorovací proces. Po nahrání firmwaru do akceleračních karet a zahájení monitorování již není možné firmware měnit a změna zásadních vlastností monitorovacího procesu může být dosažena pouze použitím jiného firmwaru. Pro uživatele je z hlediska jiného zaměření či vypovídací schopnosti metody na základě datových toků především důležité definovat: jaké položky z hlaviček paketů budou zpracovávány/sledovány (podoba UH hlavičky), které z nich budou klíčové pro tvorbu jednotlivých toků, jak bude vypadat vlastní záznam o jednotlivých tocích (jaké bude obsahovat položky), jak bude docházet k aktualizaci záznamů o toku. Tyto vlasnosti není možné nastavovat bez zásahu do firmwaru sondy. Bylo vytvořeno xml schéma (viz [21, 22]), které umožňuje uživateli zcela tyto vlastnosti monitorování popsat a definovat. Na základě tohoto xml souboru je následně třeba pomocí programového vybavení vytvořit konfigurační soubor pro jednotku HFE (popis UH hlavičky), nastavit HashGenerator jednotku (klíčové položky) a vytvořit odpovídající FPU jednotku (záznam o toku, aktualizace toků atp.). Nyní je nutné celý firmware FlowMon sondy provést procesem syntézy pomocí komerčních syntezačních nástrojů a tím z něj vytvořit binární soubory nahratelné do programovatelných polí akceleračních karet. Následně musí být celý firmware inicializován a nastaven prostřednictvím programového vybavení hostitelského počítače. Sonda začne monitorovat sít na základě datových toků a to přesně podle požadavků uživatele. Během činnosti může uživatel měnit vlastnosti sondy (timeouty, vzorkování, export na kolektory atp.), ale pokud chce změnit vlastní monitorovací proces, tak je nutné jej opět definovat prostřednictvím xml konfiguračního souboru, na základě něj vytvořit popis části firmwaru, přeložit firmware a ten nahrát do akcelerační karty. 27

35 Kapitola 4 Architektura programového vybavení Flexibilní FlowMon sondy Na základě provedené analýzy pevné části Flexibilní FlowMon sondy a jejích požadavků na programové vybavení hostitelského počítače bylo zjištěno, že je vhodné navazující programové vybavení rozdělit do dvou logických částí (viz Obrázek 4.1). Jedná se o: přípravnou (popisnou, generační) část a monitorovací část. User requests for characteristics of monitoring process once before monitoring User requests for configuration of the probe many times in realtime GENERATING FRAMEWORK Firmware MONITORING FRAMEWORK Obrázek 4.1: Rozdělení na přípravnou a monitorovací činnost Toto rozdělení vychází ze skutečnosti, že je potřeba nejprve vytvořit odpovídající firmware a až následně (po úspěšném vygenerování firmwaru, což trvá i několik desítek minut) je možné začít s monitorovací činností. Případně je samozřejmě možné využít již dříve vytvořený firmware. Tedy se oddělení tvorby firmwaru a monitorovací činnosti jeví jako více než vhodné. Přípravnou částí se rozumí veškeré činnosti nutné před vlastním prvním spuštěním Flexibilní FlowMon sondy. Zahrnuje specifikaci požadavků na monitorovací proces uživatelem, což znamená především určení položek paketů, které se budou sledovat a jakým způsobem se s nimi bude pracovat. Následně je třeba na základě této specifikace vytvořit (vygenerovat) firmware odpovídající požadavkům uživatele. Tuto činnost je nutné provést pouze 28

36 jedinkrát při určování požadavků na monitorování a následně až v okamžiku, kdy dojde k jejich změně. V případě, že uživatel nechce přesně specifikovat činnost sondy, tak může použít některý z firmwarů již vytvořených a poskytovaných tvůrci sondy. Monitorovací část obsahuje nahrání vygenerovaného firmwaru do akceleračních karet, jeho inicializaci, nastavení a vlastní monitorování sítě. Tato činnost probíhá neustále, a proto je třeba, aby poskytovala co nejpříjemnější uživatelské rozhraní. 4.1 Přípravná část Tato část je tvořena sadou nástrojů pro popis monitorovacího procesu a syntézu firmwaru. Vlastním popisem procesu se rozumí zapsání požadavků uživatele v podobě jediného xml souboru, který byl pro tuto úlohu navržen (viz [21, 22]). Tento soubor je zpracován a na základě něj je programově: vytvořen hlavičkový soubor pro jednotku HFE procesor, vytvořena maska pro výpočet hash v HashGenerator jednotce, vygenerována FlowProcessingUnit jednotka. Vytvoření hlavičkového souboru pro jednotku HFE procesor vlastně představuje převedení informací o UH hlavičče z xml souboru do vhodného formátu a podoby hlavičkového souboru použitelného při překladu jednotky HFE, jež je implementována v jazyce Handel-C. Vytvoření masky pro výpočet HashGenerator jednotky znamená nalezení v xml těch polí, která jsou označena jako klíčová, a na základě jejich pozice v záznamu o toku vytvořit bitovou masku. Tato maska je zapsána do souboru a použita při překladu jednotky HashGenerator. HW description in XML web based application HFE header file HashGenerator mask FPU C programs HW units (VHDL code) SYNTHESIS synthesis tools FIRMWARE Obrázek 4.2: Schéma přípravné části programového vybavení Generování FlowProcessingUnit jednotky je složitou činností, kdy se na základě popsaného monitorovacího procesu v xml souboru generuje zdrojový kód jednotky v jazyce 29

37 VHDL. Tato část není předmětem této práce, ale jiné bakalářské práce na FIT VUT v Brně (viz [11]), proto se jí nebude detailněji věnováno. Po provedení těchto operací je již možné spustit nástroje sloužící pro syntézu firmwaru celé sondy. Tyto nástroje nejsou běžně volně dostupné a vlastní překlad trvá řádově desítky minut. Výstupem jsou binární soubory přímo nahratelné do hradlových polí akceleračních karet. Je vidět, že během přípravné fáze je nutné provést poměrně velké množství operací, přičemž chyba v jakékoliv z nich způsobí následnou nefunkčnost sondy. Proto je vhodné, aby všechny operace prováděla jediná aplikace, čímž se zajistí konzistence všech činností. Ale vzhledem k nutnosti používat složité překladové nástroje třetích stran je toto prakticky nemožné. Stejně tak je nemožné tvořit ručně xml soubor popisující monitorovací proces, nebot není vůbec triviální a musí být zcela korektní a konzistentní. Jako vhodným řešením se jeví zastřešení všech těchto jednotlivých částí jediným webovým rozhraním, přičemž navíc celá tato sada nástrojů bude umístěna jen na vyhrazeném serveru tvůrců sondy. To z důvodu složitosti a dostupnosti překladových nástrojů a ne příliš častému generování firmwaru. Uživatel tedy nebude muset instalovat žádné nástroje a pouze prostřednictvím svého webového prohlížeče přistoupí na daný server. Zde výběrem z nabízených možností popíše monitorovací proces a zadá požadavek na vytvoření odpovídajícího firmwaru. Webová aplikace vytvoří xml soubor, který bude jinak uživateli zcela skryt, a předá jej spuštěnému programu pro tvorbu součástí zdrojových kódů jednotek firmwaru (HFE procesor, HashGenerator, FPU). Po jejich vytvoření webová aplikace spustí syntézu celého firmwaru. Po dokončení celé činnosti bude uživatel informován prostřednictvím elektronické pošty o úspěšném ukončení tvorby firmwaru a možnosti si balíček s tímto firmwarem stáhnout. Balíček obsahuje binární soubory nahratelné do hradlových polí akceleračních karet a konfigurační xml soubor. 4.2 Monitorovací část Monitorovací část vychází z původní softwarové architektury FlowMon sondy ( neflexibilní, viz [23]). Zásadní změny s sebou ovšem přináší flexibilita záznamu o toku a také změna v rozdělení monitorovacího procesu mezi hardware a software. Tato část zahrnuje všechny činnosti následující po vytvoření a stažení balíčku s firmwarem z vyhrazeného serveru. Již zcela probíhá na straně uživatele. Stejně jako u současné verze FlowMon sondy i u Flexibilní FlowMon sondy je uživateli dána možnost zvolit si ze dvou základních přístupů, jak ji ovládat a konfigurovat. Prvním z nich je použití terminálového rozhraní, kdy se uživatel přímo na sondu přihlásí pomocí SSH (Secure Shell) a pomocí skriptů a dalších nástrojů spouštěných přímo z příkazové řádky na sondě provádí veškeré operace s ní. Druhým přístupem je vzdálená konfigurace prováděná prostřednictvím webového rozhraní, která je pro nezkušeného uživatele sondy intuitivnější a uživatelsky přívětivější. Základní bloky představují: webové konfigurační rozhraní na vzdáleném webovém serveru, konfigurační démon na sondě, systém Netopeer. 30

38 4.2.1 Webové konfigurační rozhraní Webové konfigurační rozhraní představuje aplikaci tvořenou v jazyce PHP, která využívá služeb serveru apache a slouží uživateli pro zadávání jeho požadavků na konfiguraci sondy. Webové rozhraní uživateli umožňuje komfortní a snadnou editaci konfiguračního souboru sondy a jejích vlastností (pozn.: jedná se o jiný konfigurační soubor než xml soubor popisující monitorovací proces) krok za krokem. Z jediného rozhraní je možné nastavovat libovolný počet sond. Po zadání požadavku na realizaci změn provedených v konfiguračním souboru, je soubor odeslán prostřednictvím systému Netopeer na sondu, aby mohly být vyžadované změny provedeny, což zajistí konfigurační démon. Konfigurační démon informuje webový frontend opět prostřednictvím systému Netopeer o výsledku přenastavení sondy, o němž je následně vyrozuměn i uživatel. Webové rozhraní také prezentuje stavové informace ze sondy získané vzájemnou komunikací s konfiguračním démonem. Uživatel má možnost pracovat přes webové rozhraní se dvěma různými konfiguracemi (konfiguračními soubory) sondy - tzv. running a startup - a vždy si nejprve vybere, s kterou z nich chce právě pracovat. Jejich rozdíl spočívá v tom, že změny v running konfiguraci se provádí okamžitě, zatímco změny ve startup konfiguraci se provedou až po restartu sondy. Tento princip je použit proto, aby uživatel mohl nejprve ozkoušet korektní funkčnost nové konfigurace sondy - bude pracovat s konfigurací running. V případě, že vlivem provedených změn dojde k problémům na sondě, tak je se možné velmi snadno vrátit k předchozí konfiguraci pouhým restartem sondy. Ověřená a funkční running konfigurace může být uložena jako startup a následně používána jako základní. Podobné webové rozhraní je již používáno pro současnou verzi FlowMon sondy, avšak aby bylo použitelné i pro Flexiblní FlowMon sondu, tak je v něm nutné provést určité změny. Odlišnosti spočívají především ve změnách v množině nastavitelných parametrů sondy a návratových stavových hodnot ze sondy, ale také v možnosti prostřednictím webového rozhraní instalovat nový a vybírat z nainstalovaných firmwarů na sondě. Jak již bylo zmíněno, tak flexibilita sondy je realizována mimo jiné i použitím různých firmwarů v akceleračních kartách. Proto je nutné, aby webové rozhraní umožňovalo i instalaci a výběr firmwarů použitých na sondě. Součástí konfigurovatelných vlastností sondy je tedy i výběr jednoho z nainstalovaných firmwarů na sondě. Výběr této možnosti způsobí nahrání nového firmwaru do programovatelných polí akceleračních karet, čímž dojde ke změně v monitorovacím procesu. Webové rozhraní umožňuje i přímo instalaci balíčku na sondu, kdy uživatel zadá cestu k balíčku, který se má na sondu nainstalovat. Prostřednictvím systému Netopeer dojde k nakopírování a instalaci balíčku na sondu a následně je tento firmware již nabízen i k výběru na webovém rozhraní Konfigurační démon Na sondě je spuštěn jako programový démon konfigurační program, jenž provádí vlastní konfiguraci sondy na základě údajů v konfiguračních souborech. Také získává stavové informace ze sondy. Konfigurace sondy spočívá v těchto akcích: nahrání binárních souborů firmwaru do akceleračních karet, inicializace firmwaru: nahrání masky do HashGenerator jednotky, inicializace hodnoty pro výpočet hash v HashGenerator jednotce, 31

39 další činnosti spojené s inicializací jednotlivých jednotek i celé sondy, nastavení aktivního a neaktivního timeoutu, nastavení vzorkování paketů na vstupu, nastavení exportu dat o tocích: IP adresa a port kolektoru, verze exportovacího protokolu, anonymizace dat a další. Získávané a prezentované stavové informace ze sondy jsou: počet přijatých paketů, počet chybných paketů, počet navzorkovaných paketů, stav linky a další. Programový démon přistupuje na akcelerační karty, provádí konfiguraci a získává stavové informace prostřednictvím knihovny (viz Kapitola 4.2.4), která bude pro tuto úlohu vytvořena. Konfigurační démon po svém spuštění načte startup konfigurační soubor a podle údajů z něj začne provádět nastavení sondy. Nahraje vybraný firmware do akceleračních karet, provede jeho inicializaci a následně i nastaví žádoucí vlastnosti sondy. Spustí také exportovací program s parametry odpovídající hodnotám v konfiguračním souboru. Démon zkopíruje startup konfigurační soubor a vytvoří z něj running konfigurační soubor. Nyní již sonda začíná monitorovat sít. Konfigurační démon čeká na požadavky na přenastavení sondy, které mu jsou od uživatele doručovány prostřednictvím komunikace se systémem Netopeer, který je spouštěn webovým rozhraním Systém Netopeer Komunikace mezi konfiguračním démonem a webovým rozhraním je zajišt ována systémem Netopeer, což je implementace komunikačního protokolu NETCONF vytvořená v rámci projektu Liberouter (viz [9]). Protokol NETCONF je určen pro konfiguraci sít ových zařízení. Poskytuje jednoduchý mechanismus, pomocí kterého lze provádět nejrůznější změny konfigurace určitého zařízení. Jde nejen o nastavení různých parametrů daného zařízení nebo získání konkrétních konfiguračních či stavových informací, ale hlavně o komplexní změny v konfiguracích sít ových zařízení. Protokol NETCONF je postaven na formátu xml. Hierarchické uspořádání dat v xml protokol využívá pro vytváření RPC (Remote Procedure Call) zpráv s popisem požadovaných funkcí. Komunikace v rámci protokolu NETCONF má podobu klasické aplikace klient-server. Klientem je zařízení vznášející požadavky a serverem je konfigurované zařízení. NETCONF je postaven nad protokolem SSH (Secure Shell). [9] Při zadání požadavku uživatele na provedení změn na sondě spustí webový frontend Netopeer klienta a předá mu konfigurační soubor obsahující dané změny. Netopeer klient 32

40 se připojí na svůj server na Flexibilní FlowMon sondě a přenese na ní daný konfigurační soubor. Netopeer server předá požadavek na přenastavení sondy konfiguračnímu démonovi prostřednictvím komunikačního sběrnicového systému D-Bus a ten změny provede. Stejným způsobem, ale opačným směrem, odesílá démon odpověd i stavové informace ze sondy. Protokol NETCONF umožňuje definovat rozšíření. Pro potřeby Flexibilní FlowMon sondy je třeba implementovat rozšíření v podobě instalace balíčku firmwaru na sondu. Tedy instalace balíčku probíhá zcela v režii Netopeer systému, stejně jako operace restart a vypnutí sondy Programová architektura V přechozích sekcích byly popsány tři základní bloky monitorovací části programového vybavení sondy z pohledu jejího ovládání. Nyní bude popsáno, z jakých jednotlivých vrstev je tvořena programová architektura přímo umístěná na sondě (Obrázek 4.3). WWW interface Collector 1 NetFlow v5, v9 Collector n NetFlow v5, v9 Netopeer system Exporter Secondary FlowCache Config. daemon User space Library Kernel space Driver HW COMBO card Obrázek 4.3: Architektura programového vybavení sondy Vzhledem k tomu, že firmware Flexibilní FlowMon sondy je postaven nad platformou NetCOPE, která poskytuje jednotné rozhraní nejenon vůči fyzickým sít ovým rozhraním, ale také pro přenos dat do softwaru, tak je pro vyčítání datových toků z firmwaru využita právě tato možnost. Je to zajištěno využitím speciálního modulu linuxového ovladače szedata2 (straight zero copy data version 2), který umožňuje rychlý přenos bloků dat z karty do uživatelského prostoru (user space), čehož je dosaženo vyloučením aktivního kopírování dat procesorem z paměti do aplikace (více viz [16]). Toto je výrazná změna oproti předchozí verzi FlowMon sondy, která využívala speciální modul ovladače přímo implementovaný pro daný účel. V případě szedata2 jsou data přenesena a zpřístupněna aplikacím po jednotlivých blocích, avšak bez informace co konkrétně daná data obsahují za informace, což je nutné zjišt ovat až v navazujících vrstvách. 33

41 Na modul ovladače přímo navazuje knihovna, která poskytuje funkce pro vyčítání záznamu o toku z firmwaru sondy, ale také slouží pro vyčítání všech stavových informací a pro nastavování vlastností sondy. Vlastní vyčítání záznamů o tocích není triviální, nebot vzhledem k možné flexibilitě záznamu je vždy nejprve nutné zjistit, jaké položky a jaký formát záznam o datovém toku má. Následně knihovna na základě této informace poskytuje záznamy o tocích v odpovídající podobě jednotlivým aplikacím. Vzhledem k aplikacím je tedy informace o konkrétní podobě záznamu o toku zcela odstíněna a tím pádem i výrazně zjednodušena. Tato knihovna využije sadu již existujících funkcí, jež jsou používány pro přístup do adresového prostoru akceleračních karet na projektu Liberouter. Konfigurační démon i exportovací program sloužící pro zasílání dat na kolektor přistupují na akcelerační karty právě prostřednictvím této knihovny. Konfigurační démon při inicializaci a nastavování sondy spouští také exportovací program. V předchozích verzích FlowMon sondy sloužil tento program pouze pro vyčítání dat o tocích z karty, jejich zabalení do zvolené verze NetFlow protokolu a odeslání na jediný kolektor. V případě, že bylo žádáno zasílat data na více kolektorů, potom muselo být spuštěno více exportovacích programů a každý vyčítal záznamy o tocích a zasílal je na jediný kolektor (pozn.: modul ovladače byl uzpůsoben tak, aby bylo možné vyčítat z karty stejná data několika aplikacemi současně). Ovšem pro Flexibilní FlowMon sondu bylo z objektivních důvodů (viz Kapitola 3.1) rozhodnuto o rozdělení monitorovacího procesu mezi hardware a software, tedy vlastně o vytvoření sekundární cache pro záznamy o tocích (sekundární flowcache) v softwaru (primární flowcache je ve firmwaru). Není vhodné, aby každý z kolektorů samostatně tuto sekundární flowcache tvořil a ani aby byla jediná sekundární flowcache sdílena více programy, protože to výrazně komplikuje její implementaci. Proto nová verze exportovacího programu podporuje zasílání dat na více kolektorů zároveň, tedy není nutné ani možné spustit více instancí exportovacího programu. Navíc exportovací program obsahovuje nový programový modul, který zajišt uje funkci sekundární flowcache. Exportovací program je také nutné modifikovat s ohledem na variabilitu záznamu o toku. Po svém spuštění nejprve voláním odpovídající funkce knihovny zjistí, jaké položky obsahuje záznam o toku pro daný právě používaný firmware. Od tohoto okamžiku je schopen s těmito daty korektně pracovat. Modul zajišt ující sekundární flowcache musí navíc vyčítat i informace týkající se agregace dat na základě datových toků, aby mohl v této agregaci korektně pokračovat Sekundární flowcache Sekudární flowcache v softwaru je výraznou změnou v monitorovacím procesu sondy. Celková velikost flowcache je při monitorování na vysokorychlostních sítích jedním z nejdůležitějších parametrů sondy, nebot zásadně ovlivňuje vypovídací hodnotu naměřených dat i efektivitu monitorování. V případě nedostatečné flowcache (tzn. v paměti sondy je možné uchovávat dané síti neodpovídající množství datových toků) se při vyšším zatížení monitorované sítě musí často uvolňovat toky předčasně (ještě před vypršením aktivního či neaktivního timeoutu), aby se uvolnil prostor pro nově příchozí toky. Jedná se o tzv. fragmentované toky, kdy je jeden skutečný tok zasílán na kolektory jako několik nezávislých toků vlivem zaplnění paměti sondy. Na kolektory se zasílá větší množství toků a to způsobuje vyšší zatížení sondy, neefektivitu a v neposlední řadě také snižuje vypovídací hodnotu analyzovaných dat na kolektoru. V případě Flexibilní FlowMon sondy není možné neustále 34

42 zvyšovat flowcache ve firmwaru vlivem hardwarových omezení, proto bude vytvořena další flowcache v softwaru. Do této sekundární flowcache budou přicházet již předagregované záznamy o tocích, které musely být již z flowcache firmwaru expirovány, nebot : došlo k uplatnění aktivního či neaktivního timeout, došlo ke kolizi dvou toků při ukládání v primární flowcache ve firmwaru, primární flowcache ve firmwaru je již plná. V sekundární flowcache je rozhodnuto o jejich další agregaci s odpovídajícími toky. Agregace již dále neprobíhá v případě, že k expiraci došlo z důvodu uplatnění aktivního či neaktivního timeoutu a záznam o toku je zařazen k exportu na kolektory. V opačném případě dojde k zařazení záznamu o toku do sekundární flowcache. Se zařazenými záznamy o tocích se pracuje principielně zcela stejně jako ve flowcache ve firmware a i jejich expirace probíhá na základě stejných timeoutů, přičemž časové hodnoty toků se z firmwaru i sekundární flowcache sčítají. Tímto způsobem dojde k výraznému posunutí limitu monitorování velkého množství toků na vysokých rychlostech. COMBO card Software... Exporter 2nd stage aggregation Driver & Library 1st stage aggregation Flow cache Header field extraction IP traffic Obrázek 4.4: Dvoustupňová agregace dat - primární a sekundární flowcache [12] 35

43 Kapitola 5 Implementace programového vybavení Při vývoji každého výpočetního systému souběžným návrhem technického a programového vybavení (hardware/software co-design) je nutné i při vývoji programových částí úzce spolupracovat, navazovat a reagovat na vývoj technického vybavení. Stejně tak tomu je i na projektu Liberouter při vývoji Flexibilní FlowMon sondy, kdy je nezbytná úzká spolupráce vyvojářů programových částí s vývojáři firmwaru. Není možné od sebe vzájemně oddělit vývoj software a hardware a to ani časově ani co se týká vzájemné spolupráce a koordinace činností. Vývojáři firmwaru nemohou bez programových nástrojů svůj firmware otestovat a v případě Flexibilní FlowMon sondy ani vytvořit (pozn.: je nutné generovat části zdrojových kódů). Proto bylo nutné i při vývoji programového vybavení sondy veškeré činnosti přizpůsobit vývoji firmwaru a nejprve byly vytvořeny podpůrné nástroje vývojářů firmwaru, nástroje na testování a až následně vlastní programové vybavení. Zásadním problémem, který bylo třeba vyřešit, bylo umožnění nejenom snadné instalace vlastní sondy do operačního systému Linux, ale především instalace nově vytvořených firmwarů. V případě Flexibilní FlowMon sondy je klíčová správná identifikace konfiguračního xml odpovídající danému firmwaru, nebot tento konfigurační soubor popisuje průběh monitorovací činnosti a formát výstupních záznamů o tocích z daného firmwaru. Jakékoliv čistě programové řešení je nedostačující, proto bylo rozhodnuto o úpravě firmwaru, kdy byla vyčleněna jedna pamět BlockRAM o velikosti 2048 bajtů pouze pro potřeby programových vrstev. Tato pamět je daty naplněna ve fázi generování firmwaru, následně do ní není možné zapisovat, jen data číst. Zapisovaná data obsahují informaci o identifikaci xml konfiguračního souboru, jeho hash a verzi použitého xml formátu. Vzhledem ke kapacitě BlockRAM paměti bylo rozhodnuto i o využití paměti pro zápis popisu formátu záznamu o toku. Jedná se sice o duplicitní informaci, která je již zapsaná v xml konfiguračním souboru, ale i přesto je to výhodné, nebot informaci o podobě záznamu o toku je třeba znát téměř na všech programových úrovních, ale práce s xml není na nižších úrovních zcela vhodná. V BlockRAM paměti je tedy zaznamenána také velikost záznamu o toku, počet položek v záznamu o toku a postupný popis jednotlivých položek (viz Obrázek 5.1). Formát dat zapisovaných do BlockRAM paměti je následující: 36

44 Verze xml schématu (4 bajty) Identifikace xml (16 bajtů) Verze použitého xml schématu v konfiguračním souboru. Název/identifikátor konfiguračního souboru. Hash SHA1 hash xml konfiguračního souboru, pro ověření (20 bajtů) vzájemného souladu mezi xml souborem a firmwarem. Velikost záznamu (2 bajty) Počet položek záznamu (2 bajty) Velikost záznamu o toku udaná v bajtech. Počet položek v záznamu o toku. ID položky Jednoznačné identifikační číslo položky v záznamu (2 bajty) o toku. Použity identifikátory dle IPFIX standardu. Velikost položky (2 bajty) Velikost odpovídající položky v záznamu o toku. ID operace Jednoznačný identifikátor operace prováděné nad (2 bajty) odpovídající položkou během monitorovacího procesu. 7B 4B 3B XML identification XML format version XML identification cont.1 XML hash XML indetif. cont.2 XML hash cont.1 XML hash cont.2 Item 1 size Item 1 ID Items Record size Item 2 oper. Item 2 size Item 2 ID Item 1 oper.... Item 3 oper. Item 3 size Item 3 ID 0B Obrázek 5.1: Formát informace uložené v BlockRAM paměti firmwaru 5.1 Knihovna libcsfflow Nástroje konfigurační, testovací či určené pro generování firmwaru musí přistupovat do adresového prostoru sondy, vyčítat záznamy o tocích nebo zjišt ovat informace o definici položek dle IPFIX standardu (identifikační čísla pro jednoznačné určení položky v konfiguračním xml souboru). Proto bylo rozhodnuto o vytvoření knihovny, která poskytne funkce právě pro takovéto činnosti. Jedině tato knihovna je závislá na nižších vrstvách 37

45 sondy (ovladač, firmware), ostatní aplikace využívají pro jakoukoliv práci se sondou tuto knihovnu. Knihovna byla označena jako libcsfflow (library combo-six flexible flow), což vychází z obvykle používaných názvů na projektu Liberouter. Knihovna navazuje na linuxový ovladač szedata2 pro vyčítání dat z firmwaru akcelerační karty. Pro přístup do adresového prostoru firmwaru sondy využívá funkce knihovny libcombo. Přehledné schéma je na Obrázku 5.2. Pro práci s akceleračními kartami COMBO je využívána celá struktura linuxových modulů ovladače. Nejnižší vrstvou je vždy modul jádra ovladače, který je přímo specifický pro daný typ akcelerační karty, a tento modul využívají další již méně specifické moduly. Pro běžné čtení a zápisy do adresového prostoru karty je využívan COMBO ovladač, který je pro snadné použití zastřešen knihovnou libcombo. Pro velmi rychlé čtení bloků dat z firmwaru je využíván modul szedata2. Exporter/flowcache interface libcsfflow Probe configuration SW HW libcombo COMBO szedata driver Driver core COMBO card Obrázek 5.2: Schéma použití libcsfflow knihovny [12] Celou tuto architekturu zastřešuje knihovna libcsfflow, jež poskytuje sadu rozhraní pro určitou práci se sondou: zahájení a ukončení práce se sondou zahrnuje sadu rutin, které je třeba provést před započetím práce se sondou či pro korektní ukončení této práce. inicializace a nastavení vlastností sondy, získávání stavových a statistických informací o sondě, vyčítání záznamů o tocích z firmwaru sondy, zjišt ování formátu záznamu o tocích a získávání jeho jednotlivých položek, identifikace položek dle IPFIX standardu. Detailnější informace o knihovně poskytuje její doxygen dokumentace, jejíž nejdůležitější část je v Příloze C. 38

46 5.2 Generování firmare Před zahájením vlastního monitorování je u Flexibilní FlowMon sondy třeba nejprve vygenerovat firmware dle požadavků na monitorovací proces. Celý tento proces probíhá na vyhrazeném serveru způsobem, jaký byl popsán v návrhu přípravné fáze (viz Kapitola 4.1). Pro vývojové účely je však tvorba xml souboru prostřednictvím webového rozhraní dosti neefektivní, tak bylo umožněno tvořit firmware pouze použitím příkazové řádky na daném serveru, což je ve fázi vývoje výrazně efektivnější způsob. Byl vytvořen shellový skript, který zastřešuje všechny potřebné nástroje a pomocí kterého je možné provést veškeré činnosti související s tvorbou firmwaru. Vstupem toho skriptu je konfigurační xml soubor popisující monitorovací proces a sada parametrů pro určení dalších vlastností (např. pro jaké konkrétní dvojice akceleračních karet se má firmware vytvořit). Činnost skriptu je možné rozdělit do několika částí, jimiž jsou: 1. Určení zdrojových a konfiguračních souborů zahrnuje identifikaci vstupního konfiguračního xml souboru a sadu souborů se zdrojovými kódy celého firmwaru v jazyce VHDL či Handel-C. Skript umožňuje přímo použití aktuální verze SVN (subversion) repositáře se zdrojovými kódy, jenž je automaticky stažen, nebo určení adresáře obsahující dané zdrojové kódy. 2. Překlad potřebných nástrojů pro generování částí zdrojových kódů. Nejdůležitější z těchto nástrojů je program pro tvorbu FPU jednotky, který byl výstupem bakalářské práce na FIT VUT v Brně (viz [11]). 3. Spuštění nástrojů pro generování FPU jednotky, hlavičkového souboru pro HFE jednotku, bitové masky pro HGEN, data identifikující daný firmware zapisovaná do BlockRAM paměti a jejich zápis do odpovídajících souborů. 4. Překlad HFE jednotky. 5. Syntéza firmware komerčními nástroji a tím vytvoření požadovaných binárních souborů nahratelných do hradlových polí akceleračních karet. Tento skript je možné snadno spouštět z webového serveru a tedy je celá architektura velice snadno napojitelná na plánované webové rozhraní. Uživatel si prostřednictvím webového rozhraní kompletně popíše monitorovací proces včetně formátu záznamů o tocích. Tento popis je webovým rozhraním zpracován a na základě něj je vytvořen xml konfigurační soubor, který bude vstupem skriptu pro generovaní firmware. Skript i další potřebné nástroje pro generování firmware již byly zcela dokončeny a otestovány, ale webové rozhraní dosud nebylo implementováno, nebot bylo třeba pracovat na prioritnějších částech architektury a bude potřebné až v okamžiku poskytnutí sond uživatelům, což v nejbližší době ještě nebude. Alespoň byla ale navržena podoba tohoto webového rozhraní (viz Obrázek 5.3). Základem navrženého rozhraní je dvojice polí, kdy jedno obsahuje veškeré možné položky dostupné v záznamu o tocích, zatímco druhé pole představuje přesnou podobu záznamu o toku. Uživatel si pak jen velice snadno použitím techniky Táhni a pust (Drag-and-drop) vytvoří záznam o toku přesně dle svých představ. Následně každé položce záznamu o toku přidá žádoucí vlastnosti - zda se jedná o položku klíčovou, jakým způsobem má být aktualizována v okamžiku příchodu dalšího paketu náležící do daného toku - a spustí tvorbu firmware. Detailní popis ovládání skriptu je v Příloze A. 39

47 Obrázek 5.3: Návrh podoby webové rozhraní pro popis záznamu o toku 5.3 Vývojové nástroje a lokální konfigurace sondy Ve fázi vývoje jakéhokoliv zařízení je velmi důležité, zda existují nástroje, které umožní vyvíjené zařízení či jeho část snadno a rychle otestovat nebo ověřit správnou činnost. Takovéto nástroje zásadně urychlují celý proces vývoje a umožňují vývojářům soustředit se skutečně pouze na další vývoj a neztrácet svůj čas testováním. I při vývoji Flexibilní Flow- Mon sondy hrály vytvořené vývojové nástroje zásadní roli. Jedná se především o skripty a programy: Shellový skript fflowmonlkm (Flexible FlowMon load kernel modules), který slouží pro korektní přidání/odebrání všech potřebných modulů Linuxového ovladače do jádra operačního systému včetně ošetření veškerých možných chybových stavů. Skript nejprve detekuje, jaké jsou akcelerační COMBO karty v počítači dostupné, a na základě získané informace identifikuje odpovídající moduly jádra, které do jádra přidá či z něj odebere. Program fflowmonctl (Flexible FlowMon control tool) je implementován v jazyce C a slouží pro nastavení všech dostupných vlastností firmwaru sondy a získání všech informací o něm. Pro přístup do firmwaru využívá výhradně funkce poskytované knihovnou libcsfflow. Umožňuje firmware inicializovat, restartovat, nastavit aktivní i neaktivní timeout či parametry vzorkování na vstupu, ale také vrací veškeré dostupné informace o firmwaru. Program fflowread (Flexible FlowMon read) je implementován v jazyce C a je určen výhradně pro vývojové účely a testování. Slouží pro vyčítání expirovaných záznamů o tocích z firmwaru sondy, což provádí využitím funkcí poskytovaných knihovnou 40

48 libcsfflow. Díky tomuto programu bylo možné odladit celou řadu chyb jak v knihovně, tak v szedata2 ovladači či ve firmwaru. Je snadno použitelný a umožňuje počítat statistické informace nad vyčítanými toky, proto je také užíván testery, kteří testují činnosti jednotlivých částí sondy. Shellový skript fflowmon (Flexible FlowMon) zastřešuje všechny konfigurační nástroje a umožňuje kompletní ovládání sondy - od nahrání firmwaru, přes jeho inicializaci a nastavení až po spuštění exportovacích programů s odpovídajícím nastavením exportovacích protokolů. Spolu se skriptem fflowmonlkm se jedná o jediné nástroje, které jsou potřeba pro lokální konfiguraci a ovládání Flexibilní FlowMon sondy. Může se zdát, že jsou tyto nástroje triviální a nemají velký význam, opak je ovšem pravdou. Právě tyto nástroje hrají velmi důležitou roli při vývoji sondy a při ověřování správné činnosti nových verzí firmwarů. Jsou využívány vývojáři programového vybavení, vývojáři firmwaru i testery a i nadále budou mít velký význam pro uživatele, kteří preferují při ovládání sít ových zařízení použití příkazové řádky před webovým rozhraním. Ke každému z nástrojů byla samozřejmě vytvořena odpovídající dokumentace v podobě manuálové stránky a textového README. Popis ovládání jednotlivých nástrojů je v Příloze A. 5.4 Exportovací program Transport naměřených dat ze sondy na vzdálený kolektor zajišt uje samostatný program, který je zde označován jako exportér nebo exportovací program. Pojem exportér je tedy chápan v o něco užším významu než je zvykem u protokolů NetFlow, kde je exportérem označováno celé vlastní monitorovací zařízení zasílající data na kolektor. Program exportér vyčítá expirované záznamy o tocích z firmwaru sondy, z nich vytváří exportovaný paket v podobě odpovídající danému NetFlow či IPFIX formátu, které zabalí do protokolů vyšších vrstev a odešle na vzdálený kolektor. U předchozí verze FlowMon sondy byl pro každý exportovací formát (NetFlow verze 5, NetFlow verze 9, IPFIX) vytvořen samostatný program, který zajišt oval export v daném formátu na jediný kolektor. V případě, že bylo třeba zasílat data na více kolektorů, tak bylo nutné spustit více instancí exportovacího programu. U Flexibilní FlowMon sondy nebylo možné tento koncept použít vzhledem k záměru vytvářet sekundární flowcache v programovém vybavení - konkrétně právě v exportovacím programu. Bylo nutné upravit program exportér tak, aby jediná instance tohoto programu umožňovala zasílat data na více kolektorů a to navíc v různých exportovacích formátech. Také bylo nutné provést změny související s variabilitou záznamu o toku pro různé použité firmwary v akceleračních kartách sondy. Nyní je nezbytné nejenom vyčítat záznamy o tocích z firmwaru sondy a ty převést na odpovídající exportovací formát, ale nejprve je třeba zjistit, které položky záznam o toku obsahuje a jakým způsobem je z nich možné vytvořit exportovaný paket. Pro zjišt ování podoby záznamu o toku a vyčítání dat z firmwaru sondy jsou využívány funkce poskytované knihovnou libcsfflow. Program exportér byl vytvořen v rámci projektu Liberouter několika vývojáři programového vybavení, přičemž podíl na jeho vývoji v rámci této práce lze označit za částečný až okrajový. 41

49 5.5 Vzdálená konfigurace Druhým a hlavním způsobem konfigurace Flexibilní FlowMon sondy je vzdálená konfigurace, jejíž uživatelské rozhraní je tvořeno webovým frontendem. Výhodou tohoto řešení je jednoduchost jeho použití bez nutnosti detailní znalosti vlastností a principů sondy. Také je výrazně bezpečnější oproti lokální konfiguraci prováděné přímo z příkazové řádky sondy. Jak již bylo zmíněno v části popisující architekturu programového vybavení, tak je tvořeno třemi základními bloky, jimiž jsou: webové konfigurační rozhraní na vzdáleném webovém serveru, konfigurační démon na sondě, systém Netopeer. Implementace tohoto systému nebyla ještě zcela dokončena, nebot ve fázi vývoje Flexibilní FlowMon sondy není klíčovou a mnohem důležitější bylo vytvořit nástroje pro vývoj a testování vyvíjeného firmwaru Komunikační systém Netopeer Vzdálená komunikace mezi konfiguračním démonem a webovým rozhraním probíhá prostřednictvím komunikačního protokolu NETCONF, který byl implementován v rámci projektu Liberouter [9] a označen jako Netopeer systém. Je určen pro bezpečnou vzdálenou konfiguraci sít ových zařízení. Slouží pro přenos dat zapsaných v xml formátu a je zcela nezávislý na obsahu dat i na zařízení. Pro dané sít ové zařízení, pro jehož konfiguraci má sloužit, je potřeba vždy vytvořit určité uživatelské rozhraní a konfigurační nástroj. Pomocí uživatelského rozhraní jsou zapisována konfigurační data do xml souboru, využitím systému Netopeer jsou přenesena na sít ové zařízení, kde jsou aplikována daným konfiguračním nástrojem. Propojení mezi uživatelským rozhraním a Netopeer systémem je velice jednoduché. Rozhraní spustí běžně dostupný SSH program (Secure Shell) s volbou -s netopeer, což určí SSH serveru, že má spustit podsystém Netopeer. Tím dojde ke spuštění programu netopeer-manager, který je klientem Netopeer systému. Klient se připojí k zadanému Netopeer serveru na sít ovém zařízení, vymění si uvítací zprávy a navážou spojení. Netopeer-manager prostřednictvím komunikace se serverem provede veškeré požadavky pomocí změn v konfiguračních úložištích (konfigurační soubory startup nebo running) nebo přímo ve spolupráci s konfiguračním programem na sít ovém zařízení. Požadavky jsou programu netopeer-manager předávány v souboru (tzv. batch-file) specifikovaném při jeho spouštění. Soubor obsahuje vždy určitý příkaz NETCONF protokolu a jeho parametry, kterými jsou především specifikace měněného konfiguračního úložiště a dané změny. Netopeer systém řeší i požadavky na rekonfiguraci příchozí v jediném okamžiku od více různých uživatelů, k čemuž používá sadu zámků, které aplikuje na datová úložiště sít ového zařízení. Proto není vícenásobný přístup na zařízení třeba vůbec řešit. Pro potřeby Flexibilní FlowMon sondy nebylo třeba výše popsaný systém měnit, ale bylo nutné na něj navázat na straně sondy konfiguračním programem a na uživatelské straně webovým konfiguračním rozhraním. Také bylo nutné systém rozšířit o operace vypnutí a restart zařízení a o instalaci nového firmwaru na sondu, což představuje rozšíření NETCONF protokolu, která jsou v jeho standardu povolena. 42

50 Configuration Frontend Manager Device NETOPEER Manager SSH NETOPEER Agent Network Configuration Data Stores Configuration Daemon Obrázek 5.4: Schéma začlenění Netopeer systému do programového vybavení sondy [10] Webové rozhraní Jako uživatelské rozhraní Flexibilní FlowMon sondy bylo zvoleno webové rozhraní, přičemž důvody tohoto rozhodnutí i princip činnosti je popsán v Kapitole Webové rozhraní bylo implementováno v rámci bakalářské práce na FIT VUT v Brně (viz [20]) a následně bylo upraveno pro potřeby Flexibilní FlowMon sondy. Především bylo nezbytné modifikovat xml schéma konfiguračního souboru nastavení sondy, který je tvořen webovým rozhraním, Netopeer systémem přenášen na sondu do podoby datového konfiguračního úložiště (startup či running) odrážející nastavení sondy. Webové rozhraní je rozděleno do několika sekcí, kterými jsou: editace vlastností sondy, editace nastavení exportu dat na kolektory, servisní operace se sondou (restart, vypnutí, instalace firmwaru) a zobrazení stavových a statistických informací ze sondy. 43

51 Obrázek 5.5: Podoba webového rozhraní sondy [20] Konfigurační démon Požadavky na rekonfiguraci sondy z webového rozhraní musí být na sondě zpracovány a provedeny, což zajišt uje program fflowmond. Ten běží v operačním systému sondy neustále jako programový démon a pro přístup do firmwaru Flexibilní FlowMon sondy využívá funkce poskytované knihovnou libcsfflow. Uživatelovy požadavky na rekonfiguraci sondy přichází z webového rozhraní na sondu přes Netopeer systém v podobě dat zapsaných v xml formátu. Démon fflowmond komunikuje s Netopeer systémem (resp. serverovou stranou Netopeer systému - programem netopeer-agent) na sondě prostřednictvím komunikačního sběrnicového systému D-Bus. Vzhledem k tomu, že programový démon i program netopeer-agent mohou obecně běžet s oprávněním různých uživatelů, je využívána systémová sběrnice programu dbus-daemon. Programový démon se po svém spuštění k této sběrnici připojí a čeká na příchozí zprávy od programu netopeer-agent. Program fflowmond poskytuje implementace metod rozhraní org.liberouter.netopeer. Pokud není démon spuštěn v době volání metod, tak je spuštěn automaticky, ačkoliv takovéto používání není příliš vhodné. Program netopeer-agent zajišt uje provádění změn v konfiguračních úložištích (running a startup) a zároveň se stará o iniciaci provedení patřičných změn na samotném zařízení. Pro provedení změn na zařízení používá konfiguračního démona, kterému předává požadavky pomocí volání metod rozhraní org.liberouter.netopeer implementovaných objekty 44