MASARYKOVA UNIVERZITA FAKULTA}w¡¢£¤¥¦§¨  INFORMATIKY !"#$%&'()+,-./012345

Testovanie paketového filtru NIFIC v prostredí reálnej siete

BAKALÁRSKAPRÁCA

Michal Michalík

Brno, jeseˇn2010 Prehlásenie

Prehlasujem, že táto bakalárska práca je mojím pôvodným autorským dielom, ktoré som vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré som pri vypracovaní používal alebo z nich ˇcer- pal, v práci riadne citujem s uvedením úplného odkazu na príslušný zdroj.

Michal Michalík

Vedúci práce: RNDr. Jan Vykopal

ii Pod’akovanie

Chcel by som pod’akovat’ najmä vedúcemu mojej práce RNDr. Jano- vi Vykopalovi za cenné rady, ochotu a trpezlivost’ pri vedení práce. Dalejˇ d’akujem mojim kolegom z projektu Liberouter za konštruk- tívne pripomienky a rady. V neposlednom rade chcem pod’akovat’ mojej rodine a priatel’ke za morálnu podporu.

iii Zhrnutie

Táto práca si kladie za ciel’ navrhnutie testov a otestovanie hárd- verovo akcelerovaného paketového filtru NIFIC pomocou reálnej sie- t’ovej premávky. Citatel’aˇ najskôr zoznámi s filtrom NIFIC a meto- dikou testu stratovosti, z ktorého navrhnuté testy vychádzajú. Dalejˇ práca rozoberá možnosti zachytávania, ukladania, preposielania a tak- tiež anonymizácie siet’ovej premávky. V praktickej ˇcastidefinuje ano- nymizaˇcnépožiadavky pre testovanie siet’ového zariadenia NIFIC a na základe získaných skúseností vytvára sadu testov. Súˇcast’ou práce sú aj výsledky týchto testov vo forme grafov a tabuliek namer- aných hodnôt.

iv Kl’úˇcovéslová

Liberouter, NIFIC, paketový filter, zachytávanie siet’ovej premávky, anonymizácia siet’ovej premávky, , Spirent Anue XGEM, testy siet’ových zariadení, stratovost’ paketov

v Obsah

1 Úvod ...... 1 2 Testovanie paketového filtru NIFIC ...... 3 2.1 NIFIC ...... 3 2.2 Testovanie siet’ových zariadení ...... 4 2.2.1 Štatisticky významná vzorka ...... 5 2.2.2 Opakovatel’nost’ ...... 5 3 Možnosti príjmu a generovania paketov ...... 6 3.1 Knižnica Libpcap ...... 8 3.2 Špecializované zariadenia ...... 10 3.2.1 Spirent TestCenter ...... 11 3.2.2 Agilent N2X ...... 12 3.2.3 Spirent Anue XGEM ...... 12 4 Analýza siet’ovej premávky ...... 14 4.1 Zloženie siet’ovej premávky ...... 14 4.1.1 OSI model ...... 14 4.1.2 Vrstva dátových spojov ...... 15 4.1.3 Siet’ová vrstva ...... 16 4.1.4 Transportná vrstva ...... 17 4.2 Analýza siet’ovej premávky ...... 18 4.2.1 Topológia ...... 18 4.2.2 Operaˇcnýsystém ...... 18 4.2.3 Služby ...... 19 4.2.4 Informácie generované užívatel’om ...... 19 4.3 Anonymizácia siet’ovej premávky ...... 20 4.3.1 Anonymizaˇcnénástroje ...... 21 4.3.2 Proces anonymizácie vzoriek ...... 22 5 Tvorba testov pre siet’ové zariadenie NIFIC ...... 23 5.1 Filtraˇcnépravidlá ...... 23 5.2 Štatistické údaje zachytených vzoriek ...... 24 5.3 Priebeh testov ...... 26 5.3.1 Test stratovosti paketov ...... 28 5.3.2 Test klasifikácie paketov podl’a IP adries . . . . 28 5.3.3 Test klasifikácie paketov podl’a MAC adries . . 29 5.3.4 Test klasifikácie paketov podl’a protokolov 4. vrstvy ...... 30

vi 5.3.5 Test klasifikácie paketov podl’a príznakov pro- tokolu TCP ...... 31 5.3.6 Test klasifikácie paketov podl’a rozsahov IP adries 31 5.3.7 Test ostrihávania paketov ...... 32 5.4 Zhrnutie výsledkov testov ...... 32 6 Záver ...... 34 A Obsah priloženého CD ...... 37 B Konfigurácia hostitel’ského poˇcítaˇca ...... 38 C Výsledky testov ...... 39 C.1 Test stratovosti ...... 40 C.2 Test klasifikácie paketov podl’a IP adries ...... 42 C.3 Test klasifikácie paketov podl’a MAC adries ...... 44 C.4 Test klasifikácie paketov podl’a protokolov 4. vrstvy . 46 C.5 Test klasifikácie paketov podl’a príznakov protokolu TCP ...... 48 C.6 Test klasifikácie paketov podl’a rozsahov IP adries . . . 50 C.7 Test ostrihávania paketov ...... 52 D Popis gramatiky filtraˇcnýchpravidiel ...... 54

vii 1 Úvod

Snaha o vyšší výkon a zlepšenie fungovania nástrojov je stará ako l’udstvo samo. V prostredí poˇcítaˇcovejtechniky sa túto potrebu snaží nap´lˇnat’ neutíchajúci vývoj nových hárdverových prvkov, ako aj ich softvérového vybavenia. Na zaruˇceniespätnej väzby programátorom a vedeniu projektov je potrebné požadované vlastnosti a oˇcakávané chovanie vyvíjaných produktov dôkladne a odborne overit’. Preto vo väˇcšineprojektov existuje tím l’udí zaoberajúcich sa testovaním. Inak tomu nie je ani v projekte Liberouter [7]. Jedná sa o iniciatívu spoloˇcnosti CESNET [2] za podpory Ma- sarykovej univerzity a Vysokého uˇcenítechnického v Brne (VUT). Ciel’om je vyvíjat’ vysokorýchlostné hárdverovo akcelerované sie- t’ové zariadenia obsahujúce programovatel’né ˇcipy FPGA1. Jedným z týchto zariadení je aj siet’ový paketový filter NIFIC. NIFIC je transparentný siet’ový prvok urˇcenýk súbežnému spra- covaniu paketov2 na vysokorýchlostných linkách s rýchlost’ou až do 10 Gb/s [7]. Variabilnost’ tohto zariadenia umožˇnujejeho nasade- nie do rôznych podmienok, na plnenie rozliˇcnýchúloh. Medzi naj- bežnejšie aplikácie patrí bezstavový firewall, inteligentný rozdel’o- vaˇcalebo replikátor tokov. V rámci projektu stále prebieha diskusia o d’alších možnostiach využitia tohto zariadenia. Úlohou testerského tímu v projekte je pomocou navrhnutých tes- tov hl’adat’ chyby, poukazovat’ na nedostatky a urˇcit’ výkonnostné vlastnosti testovaného zariadenia. Testy by mali prebiehat’ poˇcasce- lého vývoja produktov. Címˇ skôr je totiž chyba objavená, tým je ce- novo a ˇcasovomenej nároˇcnejšiejej odstránenie. Moja práca sa zameriava na testovanie pomocou reálnej premáv- ky. Na rozdiel od premávky generovanej zariadením na testovacie úˇcely(tzv. syntetickej premávky) sa testy s reálnou premávkou pri- bližujú podmienkam použitia zariadenia v praxi. Nasleduje krátky prehl’ad kapitol. Zoznámenie s testovaným zariadením NIFIC a opis metodiky tes- tovania sa nachádza v druhej kapitole.

1. FPGA je hárdverovo programovatel’ný logický ˇcip. 2. Paketom v našom texte oznaˇcujemesiet’ovú dátovú jednotku na l’ubovol’nej vrstve OSI modelu. 1 1. ÚVOD

Ako s reálnou premávkou pracovat’ a aké nástroje na prácu ˇci testy s reálnou premávkou použit’ sa dozvedáme v tretej kapitole. Reálna premávka však obsahuje zneužitel’né údaje. O tom, z ˇcoho sa premávka skladá, aké informácie sa z nej dajú zistit’ a ako takejto analýze predchádzat’, nám hovorí štvrtá kapitola. Piata kapitola sa sústredí na samotnú tvorbu testov, príslušnú konfiguráciu zariadení a ich vzájomných spojov.

2 2 Testovanie paketového filtru NIFIC

Dôležitou súˇcast’ou životného cyklu hárdverových zariadení a ich programového vybavenia je testovanie. Rovnako to platí aj pre pake- tový filter NIFIC. Ak však chceme nejaké zariadenie podrobovat’ tes- tom, musíme sa s ním najskôr zoznámit’.

2.1 NIFIC

Zariadenie NIFIC je siet’ová karta podporujúca hárdverové filtrova- nie, konkrétne ostrihávanie, preposielanie a zahadzovanie paketov [7]. Pomocou PCI Express zbernice1 je zapojená do hostitel’ského poˇcí- taˇca.Je zložená z COMBOv2 karty [3], kde sa nachádza hárdverovo programovatel’ny FPGA ˇcip.V ˇnomje nahratý firmware zariadenia. Karta má dva fyzické ethernetové rozhrania s rýchlost’ou 10 Gb/s a jedno softvérové rozhranie, zapojené do PCI Express zbernice, ktoré je rozdelené na 14 virtuálnych rozhraní2. Dôležitou súˇcast’ou nakonfigurovaného zariadenia je súbor fil- traˇcnýchpravidiel. Tieto pravidlá identifikujú pakety podl’a vybra- ných údajov z protokolov 2. až 4. vrstvy OSI modelu [15], rozhrania, na ktorom bol paket prijatý a definujú operáciu nad paketom. NIFIC sa dá konfigurovat’ pravidlami jednak lokálne z hostitel’ského poˇcí- taˇcaalebo vzdialene pomocou konfiguraˇcnéhosystému Netopeer [7]. Filtraˇcnépravidlá vo verzii NIFIC 3.3.03 identifikujú premávku podl’a nasledujúcich položiek4 a ich kombinacii:

• zdrojová a ciel’ová MAC adresa,

• zdrojová a ciel’ová IPv4 adresa,

• protokol 4. vrstvy,

1. PCI Express je zbernica poˇcítaˇca. Predstavuje sústavu vodiˇcov, pomocou ktorých je procesor spojený s pamät’ou a vstupno-výstupnými obvodmi. 2. Podrobnému opisu vybavenia a architektúry karty NIFIC sa vo svojej bakalárskej práci venoval Michal Truneˇcka. 3. Testovaná je práve verzia NIFIC 3.3.0 4. Obsah pravidiel je vysvetlený v 5. kapitole.

3 2. TESTOVANIE PAKETOVÉHO FILTRU NIFIC

• zdrojové a ciel’ové porty TCP a UDP protokolu,

• príznaky protokolu TCP,

• vstupné rozhranie zariadenia.

2.2 Testovanie siet’ových zariadení

Producenti niekedy výsledkami vlastných testov zahmlievajú nepria- znivé vlastnosti svojich produktov [14]. Takto môže ich zariadenie neprávom získat’ lepšie postavenie na trhu. Tomu sa dá predíst’ za- definovaním štandardných metód testovania. Vytváraním štandar- dov siete internet sa zaoberá organizácia IETF. IETF vydáva RFC dokumenty opisujúce správanie, metódy a ino- vácie systémov a zariadení, s príslušnost’ou k sieti internet. Pre testo- vanie paketového filtru NIFIC sa najviac hodí dokument RFC 2544 [14]. Ten za pomoci pojmov definovaných v RFC 1242 [13] popisuje me- tódy testovania pre siet’ové zariadenia. Takto namerané výsledky sú korektnejším ukazovadlom kvality produktov. Obsahu dokumentu RFC 2544 sa podrobnejšie vo svojej bakalárskej práci venoval Michal Truneˇcka[22]. My si predstavíme metodiku testovania stratovosti rámcov, z ktorej budeme pri našom testovaní vychádzat’. Stratovost’ rámcov percentuálne vyjadruje pomer množstva pri- jatých rámcov k množstvu oˇcakávanýchz testovaného zariadenia, vid’ rovnica 2.1. recieved frames frame loss rate = ∗ 100 (2.1) sent frames Meranie by malo byt’ postupne vykonávané od 100% (v našom prípade 10 Gb/s) rýchlosti zostupne po 10-percentných krokoch až po hranicu, kedy bola nameraná nulová hodnota stratovosti pre dve po sebe následné rýchlosti. Hustejšia granularita je vítaná, redšia ne- prípustná. Výsledok by mal byt’ zobrazený grafom, kde os X je rých- lost’ prehrávania v percentách a os Y hodnota stratovosti. V našich testoch budeme za prijaté považovat’ iba tie pakety, ktoré boli filtrom NIFIC správne klasifikované. RFC 2544 d’alej uvádza, že testovanie má dodržiavat’ základné zásady ako:

4 2. TESTOVANIE PAKETOVÉHO FILTRU NIFIC

• použitie štatisticky významnej vzorky, • opakovatel’nost’.

2.2.1 Štatisticky významná vzorka Test musí byt’ meraný na štatisticky významnej vzorke, inak môžeme dospiet’ k nesprávnemu záveru. Ak by sme napríklad chceli porov- nat’ inteligenˇcný kvocient obyvat’el’ov dvoch vel’komiest, nestaˇcí nám vybrat’ vzorku dvesto l’udí pretože výsledky môžu byt’ vel’mi nepresné. V našom prípade preto budeme testovat’ pomocou niekol’- kých, dostatoˇcnevel’kých (približne 150 MB) vzoriek a za použitia filtrov, ktoré sa týkajú rôznych polí hlaviˇciekpaketov.

2.2.2 Opakovatel’nost’ Opakovatel’ný test môže byt’ spustený opakovane, priˇcomzachová- va nasledujúce vlastnosti:

• rovnaká procedúra merania, • rovnaký nástroj merania použitý rovnakým spôsobom, • rovnaké prostredie.

Dôvodov, preˇcomá byt’ test opakovat’el’ný, je hned’ niekol’ko. Násobné spustenie testu v rámci jedného testovania je opodstatnené a v praxi zaužívané, pretože dôkaz, že testované zariadenie sa správa deterministicky, je pre d’alší vývoj esenciálny. Ak sa totiž ukáže, že medzi nameranými hodnotami iterácii je nezanedbatel’ná odchýlka, pokladáme to za nezrovnalost’, ktorá si vyžaduje prešetrenie. Ak sa na základe výsledkov testu objaví chyba testovaného zariadenia, po jej opravení väˇcšinounasleduje opakované testovanie, ktoré môže odhalit’ nedostatoˇcnéodstránenie problému, ako aj zanesenie nových chýb. Dalšímˇ dôvodom je neistota pozorovatel’a, že test bol vyko- naný správne. V takom prípade môže test kedykol’vek znova vyko- nat’. Z manažérskeho pohl’adu na testovanie je dôvodom zachova- nia opakovatel’nosti napríklad potreba overenia testu iným pracov- níkom, cena tvorby nového testu, ˇcipríprava na prezentáciu testo- vaného zariadenia.

5 3 Možnosti príjmu a generovania paketov

Splnit’ podmienku opakovatel’nosti je pri používaní syntetickej pre- mávky jednoduché. Tá môže byt’ zaznamenaná pomocou opisu hla- viˇciekpaketov, d´lžok rámcov, ich poˇctua rýchlosti posielania. Spolu s informáciami o metóde a použitých nástrojoch sa dá test zrekon- štruovat’ a splnit’ požadované vlastnosti opakovatel’nosti. Pri reálnych tokoch paketov, generovaných užívatel’mi a siet’ový- mi zariadeniami vnútri siete, je však rekonštrukcia premávky z opisu kvôli množstvu dát takmer neuskutoˇcnitel’ná. Jednoduchšie je pre- mávku zachytit’ a test vykonávat’ preposielaním týchto paketov. Proces zachytávania paketov pozostáva z prijatia paketu siet’o- vým rozhraním, spracovania paketu ovládaˇcomsiet’ovej karty a o- doslania paketu ˇcipaketov do operaˇcnejpamäte hostitel’ského poˇcí- taˇca.Tam môže byt’ zachytená premávka zabalená do súboru knižni- cou Libpcap, ktorá potom umožˇnujed’alšie spracovanie zachytených dát. Test application Libpcap library Standard PF_RING Szedata2 SNF library TCP/IP Stack Standard Device Driver Szedata2 SNF Driver Driver ETHERNET

Fig. 3.1: Proces zachytávania paketov

Existuje viacero metód zachytávania paketov [20], vid’ figúra 3.1. Líšia sa použitým hárdverom, rýchlost’ou spracovania premávky a za- t’ažením procesoru. Zachytávanie metódou Stack TCP/IP je klasickým riešením, kde sa prichádzajúce pakety posielajú jadru operaˇcnéhosystému. Jadro ich potom cez TCP/IP zásobník odošle až do aplikácie. Metóda je l’ahká na implementáciu, no riešenie má najväˇcšiustratovost’ pake- tov.

6 3. MOŽNOSTI PRÍJMU A GENEROVANIA PAKETOV

Zrýchlenie predstavuje metóda PF_RING, kde sa pakety kopírujú do kruhového zásobníka ovládaného ukazovatel’mi. Ak je zásobník plný, d’alšie pakety sú zahadzované. Na rozdiel od prvého riešenia si tu aplikácia musí o pakety požiadat’. Metóda zodpovedná za kopírovanie dát z jednej pamäte do dru- hej s minimálnou réžiou procesora sa nazýva Zero-copy. Implementá- ciou metódy v procese príjmu paketov je systém Szedata2, vyvinutý projektom Liberouter pre platformu NetCOPE [6], ale aj systém Myri- com SNF od firmy Myricom. Systém Szedata2 tvoria dva kruhové zásobníky, jeden na siet’ovej karte, druhý v RAM pamäti hostitel’ského poˇcítaˇca.Pakety prichá- dzajúce na zásobník siet’ovej karty sú agregované a periodicky pre- nášané cez zbernicu do RAM pamäte. Výhodou je dokázaná vyššia priepustnost’ pri použití kariet z rodiny Combo [3]. Vyššie spomínanými metódami zachytávania paketov sa vo svo- jej bakalárskej práci podrobnejšie venuje Tomáš Mrázek [20]. Inou implementáciou metódy Zero-copy je Myricom SNF. Systém tvorí siet’ová karta Myricom 10G1, špecializovaný ovládaˇca knižnica SNF. Pakety sú agregované na zásobníku siet’ovej karty a asynchro- nicky posielané do kruhových zásobníkov v operaˇcnejpamäti poˇcí- taˇcaskrz PCI Express zbernicu. Kruhové zásobníky sú riadené knižni- cou a užívatel’, resp. proces, k ním pristupuje prostredníctvom upra- venej knižnice Libpcap alebo cez aplikaˇcnéprogramové rozhranie. Systém (za použitia karty Myricom 10G) podporuje paralelné spraco- vanie prichádzajúcich dát. Pakety sú v tomto prípade najprv triedené hašovaciou funkciou a podl’a výstupu funkcie odosielané na prís- lušné kruhové zásobníky.

Zachytenú premávku na neskoršie použitie, prípadne analýzu, je potrebné nejakým spôsobom uchovat’. Najˇcastejšieje na uloženie paketov používaný dátový formát Pcap[8]. Ten je v operaˇcnýchsys- témoch typu implementovaný knižnicou Libpcap, vytvorenou vývojovými pracovníkmi tímu .

1. Je možné použit’ aj inú siet’ovú kartu, no funkˇcnost’ systému nie je zaruˇcená.

7 3. MOŽNOSTI PRÍJMU A GENEROVANIA PAKETOV 3.1 Knižnica Libpcap

Libpcap [8] a jej prenesená verzia Winpcap (pre poˇcítaˇces operaˇcným systémom Windows) sú používané monitorovacími zariadeniami na zachytávanie paketov, ich ukladanie do formátu Pcap i následné ˇcí- tanie. Typický príklad použitia knižnice na zachytenie premávky je zobrazený vo figúre 3.2. Hlavnou myšlienkou autorov knižnice bolo vytvorit’ platformovo nezávislé vysokostupˇnovéaplikaˇcnérozhra- nie. Pôvodne bola knižnica napísana pre programovací jazyk C, dnes sú k dispozícií implementácie pre viaceré programovacie jazyky. Pro- jekt Liberouter disponuje upravenou verziou knižnice. Tá je upravená tak, aby podporovala aj zachytávanie pomocou metódy Szedata2. Hlavné funkcie knižnice Libpcap sú:

• Pcap_findalldevs() - zobrazí zoznam siet’ových rozhraní.

• Pcap_open_live() - inicializuje rozhrania. Tu sa definuje ˇcas, po ktorom má jadro kopírovat’ pakety z pamäte jadra do pamä- te užívatel’a a takisto maximálna d´lžka paketov. To je výhodné, ak chceme zachytávat’ napríklad iba hlaviˇckypaketov.

• Pcap_next() - vracia prvý, resp. d’alší zachytený paket.

• Pcap_loop(), pcap_dispatch() - slúžia na zbieranie pa- ketov a na následné operácie nad nimi.

• Funkcie protokolov - vypisujú informácie z protokolov pake- tov.

• Pcap_dump_open() - otvorí uložený súbor Pcap.

• Pcap_dump() - uloží zachytený paket do súboru Pcap.

• Pcap_setfilter() - špecifikuje filter použitý na zachytá- vanie ˇciposielanie.

• Pcap_inject() - pošle paket cez špecifikované zariadenie.

8 3. MOŽNOSTI PRÍJMU A GENEROVANIA PAKETOV

Fig. 3.2: Príklad použitia knižnice Libpcap

Existuje vel’ké množstvo programov na zachytávanie, analýzu, prepisovanie ˇcipreposielanie premávky, ktoré používajú knižnicu Libpcap. Tie najznámejšie si teraz predstavíme.

Tcpdump slúži na zachytávanie paketov a ich analýzu [8]. Tcpdump vypisuje údaje o paketoch nachádzajúcich sa na siet’ovom rozhraní, resp. v uloženom súbore Pcap. Program nemá grafické rozhranie a je ovladaný príkazovým riadkom. Môže byt’ spustený s booleanovým výrazom, ten funguje ako filter a Tcpdump vypíše iba pakety zodpovedajúce tomuto výrazu. Tcpdump pracuje, až pokial’ nie je ukonˇcenýsignálom SIGINT alebo SIGTERM, resp. po nazbie- raní zodpovedajúceho poˇctupaketov. Po skonˇceníprogram vypíše poˇcetpaketov prijatých funkciou Tcpdump, poˇcetpaketov prijatých filtrom a poˇcetzahodených paketov.

Tcpreplay je generátorom siet’ovej premávky z Pcap súboru [9]. Užívatel’ tohto programu má možnost’ nastavit’ rýchlost’ prehráva- nia, poˇcetopakovaní prehrávania a existuje aj možnost’ rozdelit’ pre- mávku do prúdov a prehrávat’ na viacerých siet’ových rozhraniach súˇcasne.Na toto rozˇcleneniepoužíva Tcpreplay svoj preprocesor Tcpprep zodpovedný za delenie premávky.

9 3. MOŽNOSTI PRÍJMU A GENEROVANIA PAKETOV

Tcprewrite slúži na editáciu paketov uložených vo formáte Pcap [9]. Vstupný súbor obsahujúci pôvodné pakety a výstupný s upravenými paketami sú parametrami tejto funkcie. Umožnuje editovat’ vybrané položky druhej až siedmej vrstvy OSI modelu, napríklad IP a MAC adresu, kontrolnú hodnoty, ˇcíslaportov a d’alšie.

Wireshark zachytáva a analyzuje siet’ovú premávku [10]. Väˇcšina užívatel’ov si na analýzu premávky vyberá práve tento nástroj. Vel’kou výhodou tohto softvéru je jeho grafické rozhranie, ktoré umožˇnujedôkladnú analýzu. Delí sa na tri okná. Prvé poskytuje zoz- nam zachytených (resp. nahratých z Pcap súboru) paketov, druhé zobrazuje podrobnosti o vybranom pakete. V poslednom okne sa nachádza obsah paketu v hexadecimálnej sústave. Dalšouˇ výhodou je pomerne intuitívna tvorba filtrov. Filter sa po- tom prejaví na zozname paketov v prvom okne. Wireshark podáva množstvo štatistík o zachytenej premávke ako napríklad graf množ- stva paketov prijatých za ˇcasovújednotku, percentuálne zastúpe- nie jednotlivých protokolov, graf komunikácie a d’alšie, ˇcospolu s použitím filtrov vytvára silný analyzaˇcnýnástroj. Spolu s programom Wireshark prichádza aj program Editcap fungujúci obdobne ako už spomínaný Tcprewrite. Wireshark existuje aj vo forme bez grafického rozhrania pod názvom Tshark.

3.2 Špecializované zariadenia

Vyššie spomínané programy obvykle pracujú nad klasickými siet’o- vými kartami. Na testovanie vysokorýchlostných zariadení sa však klasická karta dá použit’ iba v obmedzenej miere a na výkonnostné testy sa kvôli rýchlostným obmedzeniam nehodí vôbec [23]. Naš- tastie existujú testovacie prístroje pracujúce so siet’ovou premávkou, ktoré požadované rýchlostné kritéria sp´lˇnajú.Ich vel’kou nevýhodou je samozrejme vysoká cena. Postupne si predstavíme niektoré z tých, ktorými projekt Liberouter v súˇcastnostidisponuje.

10 3. MOŽNOSTI PRÍJMU A GENEROVANIA PAKETOV

3.2.1 Spirent TestCenter

Spirent TestCenter [11] pochádza od britskej telekomunikaˇcnejfirmy Spirent Communication. Tá sa zaoberá vývojom testovacích zariadení. Systém pozostáva z jednej ˇciviacerých šasi (v našom prípade SPT 2000). Do nich sú vložené testovacie moduly. Spirent ponúka hned’ niekol’ko týchto modulov, ktoré sa líšia použitými osobnostnými kar- tami (personality board), vel’kost’ou pamäte CPU jednotky, podpo- rou vyšších vrstiev protokolov OSI modelu, poˇctomportov a d’al- šími vlastnost’ami. Systém Spirent používaný projektom Liberouter sa skladá z dvoch prenosných verzií šasi. Každá obsahuje 2 rôzne moduly, všetky s kapacitou zásobníkov o vel’kosti 16 MB. Zatial’ ˇco 12-portový modul série EDM podporuje rýchlost’ generovania naj- viac 1 Gb/s, MSA moduly majú 2 porty, no dokážu pracovat’ na rýchlosti 10 Gb/s. Nad systémom operuje špecializované aplikaˇcné softvérové vybavenie spustené z poˇcítaˇcapripojeného na šasi prís- troja. TestCenter je možné ovládat’ pomocou pripravených TCL skrip- tov8. Taktiež existuje možnost’ použit’ grafické rozhranie. Zariadenie ponúka neprieberné množstvo funkcií, pre nás je najdôležitejšie naj- mä generovanie a zachytávanie premávky na rýchlosti 10 Gb/s, ˇco vyhovuje rýchlostným požiadavkám filtru NIFIC. Spirent TestCenter generuje premávku z užívatel’om vytvorených prúdov, do ktorých definuje hlaviˇckyprotokolov a poˇcetpaketov v prúde. Maximálny poˇcetvygenerovaných prúdov je 32 767. Na zaˇciatkuprehrávania so objaví štatistická tabul’ka o poˇcteposlaných i prijatých paketov prístrojom, rozdelená podl’a prúdov. Poˇcetzobrazených prijatých prú- dov môže byt’ až 65 535. Toto generovanie, získanie štatistík a násled- ná analýza sa dá použit’ ako test správnosti vykonávania akcií pake- tovým filtrom NIFIC, ale hodí sa aj na výkonnostné testy. TestCen- ter obsahuje aj automatické konfigurácie testov podl’a kritérii RFC, samozrejme s podporou IPv6 adries. Dalšouˇ výhodou je možnost’ rezervovat’ skupiny portov (namiesto celého zariadenia), vd’aka ˇco- mu môže prístroj naraz používat’ hned’ niekol’ko užívatel’ov.

8. TCL je programovací jazyk urˇcenýna tvorbu skriptov.

11 3. MOŽNOSTI PRÍJMU A GENEROVANIA PAKETOV

3.2.2 Agilent N2X Agilent N2X [5] je zariadenie zložené z testovacích modulov a do nich vložených kariet obdobne ako v prípade TestCenter. Agilent N2X projektu Liberouter pozostáva z dvoch dvojportových XS kariet. Tie sú optimalizované na integrované generovanie pre- mávky zamerané na reálne napodobˇnovaniesignálnych a smerova- cích protokolov. Dokáže generovat’ pakety z definovaných prúdov, zachytávat’ a agregovat’ údaje z hlaviˇciekprijatých paketov a simulo- vat’ rôzne zariadenia množstvom protokolov. Ovládanie N2X je sprostredkované cez poˇcítaˇcso systémom Win- dows (tzv. Controller), na ktorom sa dá pracovat’ cez grafické rozhra- nie, alebo skriptami jazyka TCL.

3.2.3 Spirent Anue XGEM XGEM [12] je zariadenie vyvíjané firmami Spirent Communications a Anue Systems, zaoberajúce sa emulovaním reálnych sietí a opti- malizáciou monitorovania siet’ovej prevádzky. XGEM nedokáže pre- mávku generovat’, zato dokáže premávku zachytit’, uložit’, modi- fikovat’ a preposlat’. XGEM sa skladá z blade kariet osadených FPGA ˇcipom.Každá karta má port na posielanie i na prijímanie premávky na linkách vel’kosti až 10 Gb/s. Na každú blade kartu sú aplikované profily. Profily umožˇnujúfiltrovat’ premávku podl’a MAC adries, VLAN identifikátora, IP adries (vo verzii 4 aj 6), IP protokolu, portov pro- tokolov TCP a UDP. Pokroˇcilejšiefunkcie na modifikáciu zachytenej premávky ako premenlivé zdržanie, zahadzovanie, preusporiadanie, duplikovanie paketov, ˇcipoškodzovanie CRC sú súˇcast’ou profilov a umožˇnujúrealistickú simuláciu sietí. Vzdialene sa tento emulátor ovláda pomocou webového resp. grafického rozhrania ako aj spúšt’aním TCL skriptov. Vd’aka 10-násobne väˇcšiemu zásobníku dokáže XGEM bezstra- tovo zachytávat’ premávku po dlhší ˇcasako ostatné zariadenia (vid’ tabul’ka 3.1). Spolu s rozsiahlymi štatistikami o premávke a podpore nahrávania z Pcap súboru sa prístroj XGEM najviac približuje potre- bám tejto práce, preto som si ho na uskutoˇcnenietestov vybral.

12 3. MOŽNOSTI PRÍJMU A GENEROVANIA PAKETOV

Rýchlost’ prehrávania Vel’kost’ zásobníkov a zachytávania [Gb/s] [MB] Agilent N2X 10 27 Spirent TestCenter 10 16 Spirent XGEM 10 700

Tabul’ka 3.1: Vel’kosti zásobníkov špecializovaných zariadení

13 4 Analýza siet’ovej premávky

Ako vyzerá siet’ová premávka z pohl’adu nižších vrstiev? Coˇ všetko dokáže potenciálny neetický užívatel’ zo zachytenej premávky zne- užit’ a ako sa proti takejto analýze bránit’? To sú otázky, na ktoré sa budeme snažit’ nájst’ odpoved’ v tejto kapitole.

4.1 Zloženie siet’ovej premávky

Avšak predtým, ako si budeme schopní na tieto otázky odpovedat’, musíme si doplnit’ poznatky o štruktúre siet’ovej premávky. Tieto fakty nám navyše umožnia lepšie pochopit’ význam filtraˇcnýchpra- vidiel testovaného zariadenia NIFIC.

4.1.1 OSI model Siet’ovú premávku možno rozdelit’ do logických celkov - vrstiev[15]. Na takéto rozdelenie sa používa dobre známy OSI model organizácie ISO. Ten pod pojmom vrstva rozumie súbor obsahovo príbuzných funkcií, ktoré poskytujú služby pre vyššie vrstvy a vyžadujú služby od nižších vrstiev. Jednotlivé vrstvy sú v siet’ovej premávke reprezen- tované hlaviˇckamipaketu. Každá hlaviˇckaprislúcha konkrétnemu protokolu asociovaného s jednou vrstvou OSI modelu. Vrstvy OSI modelu sú:

• aplikaˇcnávrstva,

• prezentaˇcnávrstva,

• relaˇcnávrstva,

• transportná vrstva,

• siet’ová vrstva,

• vrstva dátových spojov,

• fyzická vrstva.

14 4. ANALÝZA SIETOVEJˇ PREMÁVKY

Pre pochopenie položiek filtraˇcnýchpravidiel zariadenia NIFIC ako aj porozumenie analýzy siet’ovej premávky je dôležité zoznámit’ sa najmä s funkcionalitou nižších vrstiev a s niektorými dôležitými hlaviˇckamiprotokolov týchto vrstiev. Enkapsuláciu paketu hlaviˇckamiprotokolov 2. až 4. vrstvy zo- brazuje figúra 4.1.

Ethernet TCP/UDP Ethernet IP header Payload header header trailer

Fig. 4.1: Štruktúra paketu

4.1.2 Vrstva dátových spojov

Druhá vrstva OSI modelu aranžuje bity fyzickej vrstvy do logických sekcií, rámcov. Má za úlohu adresovanie staníc pripojených k spoloˇc- nému médiu, detekciu a korekciu chýb v prenose ako aj prenášanie dát medzi siet’ovými entitami identifikovanými MAC adresami. Ob- vykle je v siet’ovej premávke reprezentovaná ethernetovým rámcom (štruktúra ethernetového rámca vid’ figúra 4.2).

Dest. Source Preamble SOF Type Data FCS address address

Fig. 4.2: Štruktúra ethernetového rámca

Z ethernetového rámca je pre nás najpodstatnejšia MAC adresa. Slúži ako unikátny identifikátor siet’ového rozhrania, ide o pevnú adresu pridelenú výrobcom zariadenia. Zdrojová MAC adresa iden- tifikuje rozhranie, z ktorého bol paket poslaný, zatial’ ˇcociel’ová u- kazuje na rozhranie príjemcu rámca. Jednými z filtraˇcnýchpoložiek paketového filtru NIFIC sú práve zdrojová a ciel’ová MAC adresa.

15 4. ANALÝZA SIETOVEJˇ PREMÁVKY

4.1.3 Siet’ová vrstva Tretia vrstva je zodpovedná za prenos dát od adresáta cez jednu alebo viac sietí až k príjemcovi. Logicky adresuje siet’ové rozhrania IP adresami ( obvykle priradené k rozhraniam siet’ovým administrá- torom alebo dynamicky konfiguraˇcnýmprotokolom DHCP) tak, aby zariadenia v sieti vytvárali logickú hierarchiu. Vrstva je v siet’ovej premávke obvykle definovaná IP protoko- lom [16]. Dnes najˇcastejšiepoužívanou verziou je IPv4.

Fig. 4.3: Hlaviˇckaprotokolu IPv4

Z hlaviˇckyIPv4 (vid’ figúra 4.3) sú pre nás podstatné: • Total Length - d´lžka paketu od hlaviˇckyIPv4 (vrátane) až po náklad v bajtoch - identifikuje operaˇcnýsystém. • Time to Live - poˇcetskokov, ktoré môže paket vykonat’ pred jeho zahodením - identifikuje operaˇcnýsystému a topológiu siete. • Protocol - definuje protokol 4. vrstvy paketu podl’a autority IANA [4] - jedná sa o filtraˇcnúpoložku paketového filtru NIFIC. • Source Address - IP adresa odosielatel’a paketu - je taktiež fil- traˇcnápoložka, identifikuje komunikujúcu entitu. • Destination Address - IP adresa príjemcu paketu - je rovnako ako IP adresa odosiel’atel’a paketu filtraˇcná položka identifiku- júca komunikujúcu entitu.

16 4. ANALÝZA SIETOVEJˇ PREMÁVKY

4.1.4 Transportná vrstva Štvrtá vrstva zabezpeˇcujetransparentný prenos dát medzi koncový- mi užívatel’mi. Protokolov. Obvyklé protokoly 4. vrstvy sú TCP a UDP. TCP [17] ( z anglického transmission control protokol) protokol je stavový, ˇcoznamená, že zúˇcastnenéentity si udržiavajú informácie o ich stave v spojení. Prechod medzi stavmi sa uskutoˇcnujeposiela- ním a príjmaním TCP paketov s príslušnými príznakmi. Protokol definuje poradie paketov položkami sequence num- ber a acknowledgement number. Vd’aka nim si príjemca dokáže preusporiadat’ prijaté pakety, identifikovat’ poškodený, resp. nepri- jatý paket, ˇcímprotokol TCP zaruˇcujeúspešný transport všetkých dát. Prehl’ad o hlaviˇckeprotokolu TCP sa nachádza vo figúre 4.4. Protokol UDP [21] je naopak bezstavový. Chudobná hlaviˇckade- finuje iba komunikujúce porty, d´lžku paketu a kontrolný súˇcetumož- ˇnujúciidentifikáciu poškodeneného paketu. Zatial’ ˇcociel’om pro- tokolu TCP je doruˇcit’ všetky pakety, UDP sa zameriava na konš- tantný transport dát. Používa sa na aplikácie preferujúce rýchlost’ pred presným doruˇcovaním(napr. priamy video prenos).

Fig. 4.4: Hlaviˇckaprotokolu TCP

Dalšímiˇ z nášho pohl’adu významnými zložkami sú: • Zdrojový a ciel’ový port - identifikujú komunikujúce aplikácie,

17 4. ANALÝZA SIETOVEJˇ PREMÁVKY

resp. procesy - filtraˇcnápoložka zariadenia NIFIC.

• Window Size (TCP) - indikuje maximálny objem dát, ktoré môže odosielatel’ poslat’ bez potvrdenia o prijatí príjemcom - identifikácia operaˇcnéhosystému.

• TCP Options (TCP) - väˇcšinaTCP možností sa vyskytuje len pri nadväzovaní spojenia. Upravujú vlastnosti TCP spojenia ako navýšenie vel’kosti okna, ˇcasovéznámky alebo potvrde- nia prijatých paketov mimo poradia - identifikácia operaˇcného systému. .

4.2 Analýza siet’ovej premávky

Analýza siet’ovej premávky ma rôzne zamerania [18]. Zatial’ ˇcoad- ministrátor siete ˇnoukontroluje stav siete a zist’uje útoˇcníckeaktivi- ty, pre útoˇcníkapredstavuje zdroj údajov použitel’ných na útok proti sieti, resp. zneužitel’ných voˇcikomunikujúcim stranám. Predstavu o tom, aké informácie je možno zo zachytenej premávky odvodit’, nám poskytne táto ˇcast’ práce.

4.2.1 Topológia O logických vzdialenost’iach komunikaˇcnýchbodov od miesta za- chytávania nám najviac napovie pole TTL. To síce ukazuje iba, kol’ko skokov môže paket ešte vykonat’, no vedomost’, že iniciaˇcnáhod- nota je (v závislosti na operaˇcnomsystéme) jednou z 32, 64, 128 alebo 256, nám umožˇnujeodvodit’ vzdialenost’ odosielatel’a od miesta za- chytenia. Z paketov protokolu ARP sa dozvedáme IP a MAC adresu brány, zatial’ˇcoprotokol DNS lokalizuje DNS server.

4.2.2 Operaˇcnýsystém Detekcia operaˇcnéhosystému pomocou TCP paketu nadväzujúceho spojenie (s aktivovaným TCP SYN príznakom) je najpoužívanejšou metódou. Štvorica údajov z hlaviˇciekprotokolov IP a TCP tohto pa- ketu vytvára odtlaˇckyprstov jednotlivých systémov (príklad odtlaˇc- ky prstov vybraných operaˇcnýchsystémov, vid’ tabul’ka 4.1).

18 4. ANALÝZA SIETOVEJˇ PREMÁVKY

TTL Window Packet TCP options size length 2.4 64 5840 60 MSS TS SOK WSC 1NOP OpenBSD 64 16384 64 MSS TS SOK WSC 5NOP Solaris 7 255 8760 44 MSS AIX 4.3 64 16384 44 MSS Windows 2000 128 16384 48 MSS SOK 2NOP

Tabul’ka 4.1: Príklad odtlaˇckovprstov vybraných operaˇcnýchsysté- mov

Alternatívou je odvodzovanie operaˇcnéhosystému z paketov pro- tokolu ICMP. Obe techniky dokopy sú spol’ahlivým ukazatel’om na operaˇcnýsystém odosielatel’a.

4.2.3 Služby Súˇcast’ou hlaviˇckyTCP a UDP paketu je zdrojový a ciel’ový port. Porovnanie ˇcíslaportu v pakete so zoznamom dobre známych por- tov1 nám prezrádza, aká služba bola na serveri v ˇcasezachytávania používaná. Niektoré služby sa však náhodným výberom komuniku- júcich portov snažia takejto analýze zabránit’.

4.2.4 Informácie generované užívatel’om Najviac súkromných dát obsahuje samozrejme samotný náklad pa- ketu. Ten, pokial’ nie je šifrovaný, dokáže byt’ bez odšifrovania preˇcí- taný. Takto sa užívatel’ s prístupom k zachytenej premávke môže dostat’ ku konverzáciam medzi užívatel’mi siete, k navštíveným strán- kam ako aj heslám k rôznym úˇctom.

Testovanie pomocou reálnej prevádzky je dôležitou súˇcast’ou životného cyklu siet’ových zariadení. Avšak, ako sme sa dozvedeli,

1. Zoznam dobre známych portov vydala organizácia IANA.

19 4. ANALÝZA SIETOVEJˇ PREMÁVKY

zachytená reálna premávka je mnohostranne zneužitel’ná. Aby sme mohli reálnu premávku ukladat’, používat’ na špecifické úˇcelya zá- roveˇnnezverejnovat’ citlivé informácie, musíme premávku anony- mizovat’[19].

4.3 Anonymizácia siet’ovej premávky

Proces anonymizácie spoˇcívav mazaní, resp. šifrovaní reálnych dát z paketov tak, aby sa zabránilo zneužitiu citlivých údajov. Anony- mizácia by mala byt’ šitá na mieru úˇcelupoužitia reálnej premávky. Náš dôvod použitia je samozrejme testovanie zariadenia NIFIC. NIFIC nijako neovplyvˇnuje obsah paketu ˇcihlaviˇckyvyšších vrs- tiev, tie sú však plné citlivých údajov a treba sa ich nejakým spô- sobom zbavit’. Na druhej strane d´lžky paketov hrajú významnú úlo- hu v priepustnosti zariadení, ako zaplnenie zásobníkov ˇcirýchlost’ spracovania hlaviˇciek.Kompromis predstavuje nahradenie obsahu protokolov 4. vrstvy nulovými bitmi tak, aby svojou vel’kost’ou zod- povedal vel’kosti pôvodného paketu. Dalšímˇ kandidátom procesu anonymizácie je IP adresa. Najjed- noduchším spôsobom je nahradenie hostitel’skej ˇcastiIP adresy konš- tantnou hodnotou. To ale spôsobuje vysokú kolíznost’ IP adries, ˇco znamená, že rôzne adresy z rovnakej podsiete sa spoja do jednej adresy. Jednou zo zložiek filtrov karty NIFIC je práve IP adresa a preto je žiadané bezkolízne mapovanie. Metóda zachovávania pre- fixov (ak mali dve pôvodné IP adresy spoloˇcnýprefix d´lžky k, budú ho mat’ spoloˇcnýaj po anonymizovaní), je síce bezkolízna, ale je tu zvýšené riziko, že dáta budú odanonymizované. Zníženie rizika predstavuje postup, v ktorom sú spoloˇcnéiba podsiete namiesto všet- kých bitov. Spolu s bezkolizitou mapovania sa táto metóda javí ako najvhodnejšia pre naše použitie. Ak sa potenciálny útoˇcníkdostane k anonymizovaným IP adre- sám prislúchajúcim skutoˇcnýmMAC adresám a nachádza sa na sieti z ktorej bola vzorka zachytená, je tu riziko, že anonymizované IP adresy odhalí. Riešenie predstavuje bezkolízna anonymizácia MAC adries (MAC adresa je jednou z filtraˇcnýchpoložiek pravidiel). Po zadefinovaní položiek a spôsobu anonymizácie sa zaˇcínapá- tranie po vhodnom (a funkˇcnom)anonymizaˇcnomnástroji.

20 4. ANALÝZA SIETOVEJˇ PREMÁVKY

4.3.1 Anonymizaˇcnénástroje Vhodný anonymizaˇcnýprogram by mal v našom prípade sp´lˇnat’ nasledujúce kritéria [1]. Okrem anonymizácie spomínaných polí defi- novanými spôsobmi (MAC adresa, IP adresa, obsah), by sa mal pro- gram správat’ deterministicky a jeho vstupom i výstupom by mal byt’ súbor typu Pcap, kedže typ Pcap je, základným kameˇnomprá- ce s uloženou siet’ovou premávkou. Medzi sekundárne kritéria na vý- ber programu patrí kvalita dokumentácie a užívatel’ská prístupnost’.

Tcpanon napísaný v jazyku Python, vyžaduje zastaralú verziu kniž- nice dpkt, ktorá má problémy s inštaláciou. Kvôli tomuto faktu sa mi program nepodarilo úspešne spustit’. So spustením mali problém aj programy Flaim a CoralReef.

Scrub-tcpdump je napisaný v jazyku C, bohužial najnovšia verzia z roku 2007 je 0.1 (ˇcíslonaznaˇcuje,že autor program nepovažuje za finálnu verziu). Program je síce spustitel’ný a ˇciastoˇcnefunkˇcný(fun- guje anonymizácia IP adresy náhodnými hodnotami), no väˇcšina funkcií nepracuje správne (napríklad metóda zachovania prefixov a mazanie obsahu paketu). Navyše nevypisuje žiadne chybové hlášky, ˇcímsa stáva prakticky nepoužitel’ným.

Tcpmkpub je taktiež napísaný v programovacom jazyku C. Uží- vatel’ programu si vytvára stratégiu anonymizácie upravovaním sú- borov typu Anon. Tento program sa mi podarilo úspešne spustit’. Jeho správanie však nebolo deterministické a stávalo sa, že upravené súbory Anon neboli do programu správne nakonfigurované. Nekva- litná dokumentácia s nízkou výpovednou hodnotou výrazne obme- dzovala pokusy na vyriešenie spomínaných problémov.

TcPurify je program obdobný programu Tcpdump, so zameraním na mazanie obsahu hlaviˇciekprotokolov 2. až 4. vrstvy a to tak, že hlaviˇckuprotokolu ponechá nezmenenú. To znamená, že hlaviˇcka stále udržuje údaj o pôvodnej vel’kosti dát paketu. Autori tvrdia, že dokáže podl’a konfiguraˇcnéhosúboru anonymizovat’ IP adresy. Praktické použitie však toto tvrdenie vyvracia.

21 4. ANALÝZA SIETOVEJˇ PREMÁVKY

Tcprewrite bol už spomínaný v kapitole 3. Okrem toho Tcprewrite dokáže z protokolov 4. vrstvy zistit’ pôvodnú vel’kost’ dát hlaviˇcky a chýbajúce bity nahradí konštantnou hodnotou. Navyše podporuje anonymizáciu IP adries metódou zachovania podsietí.

Editpcap je vyvíjaný ˇclenomprojektu Liberouter Tomášom Cejkom.ˇ Program bude podporovat’ funkcie ako zahodenie paketu, výpis ob- sahu paketu ˇcianonymizácia paketu. V súˇcasnejdobe program pod- poruje bezkolíznu anonymizáciu MAC adries. Vzhl’adom na to, že program je v rannej fáze vývoja, nie je ešte verejne dostupný.

Ako sme sa mohli presvedˇcit’ v predchádzajúcom texte, nebol náj- dený žiaden program, ktorý by sp´lˇnalvšetky naše požiadavky. Naš- t’astie každú požiadavku sp´lˇnalaspoˇnjeden program, a preto sa vhodnou kombináciou anonymizaˇcnýchnástrojov podarilo zachy- tené vzorky anonymizovat’.

4.3.2 Proces anonymizácie vzoriek Proces anonymizácie zachytenej premávky podl’a našich kritérií po- zostáva z niekol’kých ˇcastí.Najprv sa filtrovaním odstránia pakety s protokolmi IPv6, MPLS a GRE2. Nasleduje zmazanie obsahu pro- tokolov 4. vrstvy a vloženie konštánt zodpovedajúcich vel’kostí spät’ do tela protokolu. Dalejˇ sú metódou zachovávania podsietí anonymi- zované IP adresy a nakoniec MAC adresy (náhodnými hodnotami). Poslednou akciou je korekcia kontrolných súˇctovhlaviˇciekanonymi- zovanej vzorky3. Po vytvorení anonymizovaných vzoriek nám už niˇcnestojí v ceste definovat’ jednotlivé testy.

2. IPv6, MPLS a GRE pakety sa kvôli ich štruktúre nepodarilo úspešne anonymi- zovat’. 3. Zoznam príkazov anonymizácie je súˇcast’ou prílohy.

22 5 Tvorba testov pre siet’ové zariadenie NIFIC

Súˇcast’ou tvorby testu je aj urˇceniespôsobu vyhodnotenia testu. Vy- hodnotenie testu spoˇcívav porovnaní oˇcakávanýchhodnôt s name- ranými. Predpokladaný príjem paketov v našich testoch dokážeme odvodit’ zo štatistických údajov použitých vzoriek aplikovaných na príslušný súbor filtraˇcnýchpravidiel. Prvá ˇcast’ tejto kapitoly sa preto venuje tvorbe filtraˇcnýchpravidiel, kým druhá ˇcast’ anotuje zachy- tené anonymizované vzorky. Tretia ˇcast’ sa zaoberá nastavením celej testovacej sústavy a definuje konkrétne testy.

5.1 Filtraˇcnépravidlá

Ako už bolo spomínané, paketový filter NIFIC pripravený na použi- tie musí byt’ nakonfigurovaný filtraˇcnýmipravidlami. Každé pravi- dlo potom urˇcujejednu konkrétnu akciu nad zadefinovanou skupi- nou pravidiel. Filtraˇcnépravidlo sa dá logicky rozdelit’ na 3 ˇcasti1:

• identifikácia paketov,

• priorita,

• akcia.

Identifikácia paketov rozhoduje o príslušnosti paketov k pravidlu. Paket je identifikovaný podl’a už spomínaných polí protokolov 2. až 4. vrstvy (zdrojová a ciel’ová IP adresa, MAC adresa, protokol 4. vrstvy, zdrojový a ciel’ový port, TCP príznaky).

Priorita urˇcujeporadie, v akom bude paketový filter NIFIC porov- návat’ paket s jednotlivými pravidlami. Napríklad ak prichádzajúci paket zodpovedá pravidlám s prioritou 50 a 128, filter NIFIC prejde vzostupne všetky zadefinované pravidlá s prioritami 1 až 50, vykoná operáciu urˇcenúpravidlom 50 a d’alšie pravidlá neprechádza.

1. Gramatika pravidiel je súˇcast’ou prílohy práce.

23 5. TVORBATESTOVPRESIETOVÉZARIADENIEˇ NIFIC

Akcia urˇcujesamotnú operáciu nad paketom. Akcia block pri- kazuje zahodenie paketu. Akcia pass posiela zodpovedajúcu pre- mávku na konkrétne rozhranie. K akcii pass môže byt’ pridaný prí- kaz on definujúci vstupné rozhranie alebo crop preposielajúci iba prvú ˇcast’ paketu s vel’kostou definovanou príkazom crop v bajtoch.

5.2 Štatistické údaje zachytených vzoriek

Z linky pripojujúcej Masarykovu univerzitu do siete CESNET boli v popoludˇnajšíchhodinách pracovného dˇnanástrojom XGEM za- chytené dva Pcap súbory, ktoré po vyššie zmienenej anonymizácii dostali názvy Vzorka 1 a Vzorka 2. Aby sme mohli tieto vzorky pou- žit’ potrebujeme poznat’ ich štatistické údaje relevantné našim testom. Vel’kost’ súborov a poˇcetpaketov v súboroch zobrazuje tabul’ka 5.1. Percentuálne ako aj absolútne zastúpenie vybraných protokolov 4. vrstvy (TCP, UDP, ICMP) vo vzorkách prezentuje tabul’ka 5.2. Tabul’- ka 5.3 zobrazuje poˇctypaketov v tokoch od zdrojovej do ciel’ovej IP adresy2. Jej obdobou je tabul’ka 5.4 kde sa pakety agregujú do tokov podl’a MAC adries. Poslednou je tabul’ka 5.5 urˇcujúcapoˇcetpaketov s vybranými príznakmi protokolu TCP.

Vel’kost’ súboru [MB] Poˇcetpaketov Vzorka 1 132,2 159 301 Vzorka 2 147,7 168 595

Tabul’ka 5.1: Vel’kost’ vzoriek

TCP UDP ICMP Vzorka 1 115 627 (72,58%) 43 057 (27,03%) 251 (0,16%) Vzorka 2 123 492 (73,25%) 43 780 (25,97%) 223 (0,13%)

Tabul’ka 5.2: Zastúpenie protokolov

2. V prípadoch, kde jedna z adries nie je uvedená sa jedná o toky z uvedenej IP adresy do všetkých adries vzorky a naopak.

24 5. TVORBATESTOVPRESIETOVÉZARIADENIEˇ NIFIC

Zdrojová IP Ciel’ová IP Poˇcet adresa adresa paketov 82.127.93.252 - 7057 - 179.137.111.235 2736 Vzorka 1 191.76.36.168 179.181.100.235 2428 179.137.60.236 55.195.101.205 2013 82.125.167.186 179.181.94.125 1973 83.234.219.214 - 6415 - 177.111.101.229 3543 Vzorka 2 189.234.37.217 177.111.229.205 2873 219.71.99.95 177.103.237.35 1893 213.182.90.250 177.111.227.199 1696

Tabul’ka 5.3: Štatistiky poˇctupaketov v tokoch pre vybrané IP adresy

Zdrojová MAC Ciel’ová MAC Poˇcet adresa adresa paketov 67:75:9f:c5:97:27 67:85:28:41:12:e8 50 523 Vzorka 1 67:85:28:41:12:e8 67:75:9f:c5:97:27 36 056 67:75:9f:c5:97:27 67:85:25:f2:80:27 29 731 67:85:25:f2:80:27 67:75:9f:c5:97:27 25 489 67:75:9f:c5:97:27 67:85:28:41:12:e8 50 642 Vzorka 2 67:75:9f:c5:97:27 67:85:25:f2:80:27 38 756 67:85:28:41:12:e8 67:75:9f:c5:97:27 33 394 67:85:25:f2:80:27 67:75:9f:c5:97:27 28 408

Tabul’ka 5.4: Štatistiky poˇctupaketov v tokoch pre vybrané MAC adresy

SYN RST CWR Vzorka 1 1303 473 3 Vzorka 2 1990 446 2

Tabul’ka 5.5: Zastúpenie vybraných príznakov protokolu TCP

25 5. TVORBATESTOVPRESIETOVÉZARIADENIEˇ NIFIC 5.3 Priebeh testov

Zariadenie NIFIC je jedným zo svojich hárdverových portov pripo- jené na zariadenie Spirent XGEM. Druhý port sa pripojí na zariadenie Spirent TestCenter. Anonymizovaná premávka sa nahrá do vytvoreného kanálu za- riadenia XGEM, odkial’ prúdi do karty NIFIC. Z paketového filtru NIFIC sa na základe nakonfigurovaného súboru pravidiel premávka preposiela do zariadenia TestCenter, resp. na siet’ové rozhranie hos- titel’ského poˇcítaˇca3. Rozhranie bolo vytvorené pri spustení karty NIFIC z konfigu- raˇcnéhosúboru nific.conf4 a to tak, aby zodpovedalo 3. virtuálnemu portu karty NIFIC. Na rozhraní je spustených niekol’ko inštancií pro- gramu Tcpdump (jedna inštancia sleduje celkový poˇcetpaketov, os- tatné kontrolujú korektnost’ pravidiel nakonfigurovaných do zaria- denia NIFIC). Po preposlaní sa zozbierajú údaje o prijatých paketoch a porov- najú sa s oˇcakávanýmpoˇctompaketov vzhl’adom na jednotlivé kon- figuraˇcnépravidlá tak, ako je uvedené v odstavci Stratovost’ rámcov v druhej kapitole. Následne sa test vykoná znova na nižšej rýchlosti (meranie je vždy minimálne do rýchlosti 5 Gb/s napriek tomu že to RFC 2544 nepožaduje). Výsledky sú reprezentované formou grafov a tabuliek, ktoré sú súˇcast’ou prílohy práce. Tok paketov v priebehu testu je znázornený vo figúre5.1

3. Konfigurácia hostitel’ského poˇcítaˇcakarty NIFIC je súˇcast’ou prílohy práce 4. Súbor nific.conf je súˇcast’ou priloženého nosiˇcaCD

26 5. TVORBATESTOVPRESIETOVÉZARIADENIEˇ NIFIC

Fig. 5.1: Zapojenie zariadení poˇcaspriebehu testu

27 5. TVORBATESTOVPRESIETOVÉZARIADENIEˇ NIFIC

5.3.1 Test stratovosti paketov NIFIC je nakonfigurovaný jediným pass pravidlom, ktoré odosiela všetky prijaté pakety na port zariadenia TestCenter. Jedná sa teda o klasický test stratovosti definovaný v dokumente RFC 2544 s použi- tím heterogénnych d´lžok paketov. NIFIC je v prípade oboch vzoriek nakonfigurovaný pravidlami: 1 pass 1 on 0 100 block Tabul’ka 5.6 zobrazuje pakety s oˇcakávanýmpríchodom na zaria- denie TestCenter ako aj na rozhranie hostitel’ského poˇcítaˇca.

TestCenter Hostitel’ský poˇcítaˇc Spolu Vzorka 1 159 301 0 159 301 Vzorka 2 168 595 0 168 595

Tabul’ka 5.6: Oˇcakávanýpríjem paketov

5.3.2 Test klasifikácie paketov podl’a IP adries Test skúma správnost’ klasifikácie zdrojovou a ciel’ovou IP adresou. Nakonfigurované pravidlá sú nastavené nekonfliktne. To znamená, že každý paket vie byt’ klasifikovaný práve jedným pravidlom. Ne- konfliktnost’ bola overená nástrojom Wireshark. Poradie pravidiel je nastavené tak, aby NIFIC musel celkovo pre- jst’ ˇconajviac pravidiel. Inými slovami, ˇcímviac paketov zodpovedá pravidlu, tým nižšiu prioritu (a vyššie ˇcíslopriority) bude pravidlo mat’. Takéto poradie pravidiel budeme d’alej nazývat’ najneefektív- nejšie. Množstvo oˇcakávanýchpaketov je znázornené v tabul’ke5.7. Pravidlá pre Vzorku 1: 1 pass 3 from 82.125.167.186 to 179.181.94.125 2 pass 3 from 179.137.60.236 to 55.195.101.205 3 pass 0 from 191.76.36.168 to 179.181.100.235 4 pass 0 from any to 179.137.111.235 5 pass 0 from 82.127.93.252 100 block

28 5. TVORBATESTOVPRESIETOVÉZARIADENIEˇ NIFIC

Pravidlá pre Vzorku 2: 1 pass 3 from 213.182.90.250 to 177.111.227.199 2 pass 3 from 219.71.99.95 to 177.103.237.35 3 pass 0 from 189.234.37.217 to 177.111.229.205 4 pass 0 from any to 177.111.101.229 5 pass 0 from 83.234.219.214 100 block

TestCenter Hostitel’ský poˇcítaˇc Spolu Vzorka 1 12 221 3986 16 207 Vzorka 2 12 831 3589 16 410

Tabul’ka 5.7: Oˇcakávanýpríjem paketov

5.3.3 Test klasifikácie paketov podl’a MAC adries Test je vel’mi podobný predchádzajúcemu s tým rozdielom, že pra- vidlá premávku klasifikujú podl’a zdrojovej a ciel’ovej MAC adresy. Najmohutnejšia konverzácia je posielaná do zariadenia XGEM a dru- há najmohutnejšia konverzácia je smerovaná do hostitel’ského poˇcí- taˇca.Pravidlá sú opät’ nastavené bezkonfliktne a najneefektívnejšie. Množstvo oˇcakávanýchpaketov je vyjadrené tabul’kou5.8 Pravidlá pri použití Vzorky 1: 1 pass 3 from any mac 67:85:25:f2:80:27 to any mac 67:75:9f:c5:97:27 2 pass 3 from any mac 67:75:9f:c5:97:27 to any mac 67:85:25:f2:80:27 3 pass 0 from any mac 67:85:28:41:12:e8 to any mac 67:75:9f:c5:97:27 4 pass 0 from any mac 67:75:9f:c5:97:27 to any mac 67:85:28:41:12:e8 100 block

Pravidlá pri použití Vzorky 2:

29 5. TVORBATESTOVPRESIETOVÉZARIADENIEˇ NIFIC 1 pass 3 from any mac 67:85:25:f2:8d:27 to any mac 67:75:9f:c5:97:27 2 pass 3 from any mac 67:75:9f:c5:97:27 to any mac 67:85:25:f2:8d:27 3 pass 0 from any mac 67:85:28:41:12:e8 to any mac 67:75:9f:c5:97:27 4 pass 0 from any mac 67:75:9f:c5:97:27 to any mac 67:85:28:41:12:e8 100 block

TestCenter Hostitel’ský poˇcítaˇc Spolu Vzorka 1 86 579 55 200 141 779 Vzorka 2 84 036 67 164 151 200

Tabul’ka 5.8: Oˇcakávanýpríjem paketov

5.3.4 Test klasifikácie paketov podl’a protokolov 4. vrstvy Zatial’ ˇcodo zariadenia TestCenter sú preposielané pakety protokolu TCP, na rozhranie hostitel’ského poˇcítaˇcasú smerované pakety pro- tokolu ICMP a UDP. Opät’ sa použije najneefektívnejšie poradie pra- vidiel. Pravidlá sú rovnaké pre obe použité vzorky: 1 pass 3 proto ICMP 2 pass 3 proto UDP 3 pass 0 proto TCP 100 block Oˇcakávanépoˇctyprijatých paketov zobrazuje tabul’ka5.9.

TestCenter Hostitel’ský poˇcítaˇc Spolu Vzorka 1 115 627 43 308 158 935 Vzorka 2 123 492 44 003 167 495

Tabul’ka 5.9: Oˇcakávanýpríjem paketov

30 5. TVORBATESTOVPRESIETOVÉZARIADENIEˇ NIFIC

5.3.5 Test klasifikácie paketov podl’a príznakov protokolu TCP Pakety s príznakom SYN sú nasmerované do zariadenia TestCenter a pakety s príznakmi RST alebo CWR (z anglického Congestion Window Reduced) sú smerované na siet’ové rozhranie hostitel’ského poˇcítaˇca. Pravidlá sú spoloˇcnépre obe vzorky: 1 pass 3 proto TCP flags C/C 2 pass 3 proto TCP flags R/R 3 pass 0 proto TCP flags S/S 100 block

Tabul’ka5.10 zobrazuje oˇcakávanépoˇctyprijatých paketov.

TestCenter Hostitel’ský poˇcítaˇc Spolu Vzorka 1 1303 476 1779 Vzorka 2 1990 448 2438

Tabul’ka 5.10: Oˇcakávanýpríjem paketov

5.3.6 Test klasifikácie paketov podl’a rozsahov IP adries Test skúma správnost’ klasifikácie ako aj stratovost’ pri konfiguraˇc- ných pravidlách s rozsahmi IP adries. Pravidlá sú v tomto prípade konfliktné a na výpoˇcet oˇcakávaných paketov poslúžil program Wireshark. Jeden rozsah adries je posielaný do zariadenia TestCen- ter, kým druhý, ochudobnený o spoloˇcnépakety s prvým rozsahom je zachytávaný programom Tcpdump na siet’ovom rozhraní hostitel’- ského poˇcítaˇca. Pravidlá pre Vzorku 1: 1 pass 0 from 179.137.0.0/16 2 pass 0 from any to 179.137.0.0/16 3 pass 3 from 179.181.0.0/16 4 pass 3 from any to 179.181.0.0/16 100 block

Pravidlá pre Vzorku 2:

31 5. TVORBATESTOVPRESIETOVÉZARIADENIEˇ NIFIC 1 pass 0 from 177.111.0.0/16 2 pass 0 from any to 177.111.0.0/16 3 pass 3 from 177.103.0.0/16 4 pass 3 from any to 177.103.0.0/16 100 block

Oˇcakávanémnožstvá paketov pre tento test sú v tabul’ke5.11

TestCenter Hostitel’ský poˇcítaˇc Spolu Vzorka 1 56 864 83 514 140 378 Vzorka 2 79 703 66 603 146 306

Tabul’ka 5.11: Oˇcakávanýpríjem paketov

5.3.7 Test ostrihávania paketov Test je svojimi pravidlami a oˇcakávanýmmnožstvom paketov vel’mi podobný Testu klasifikácie paketov podl’a protokolov 4. vrstvy. Na rozdiel od neho však NIFIC nebude preposielat’ celé pakety ale len urˇcitú d´lžku paketu (400 B pre hostitel’ský poˇcítaˇca 450 B pre zariade- nie TestCenter ). Tabul’ka oˇcakávanéhomnožstva paketov je rovnaká ako tabul’ka 5.9 Pravidlá sú spoloˇcnépre obe použité vzorky:

1 pass 3 crop 400 proto ICMP 2 pass 3 crop 400 proto UDP 3 pass 0 crop 450 proto TCP 100 block

5.4 Zhrnutie výsledkov testov

Hárdvérovo akcelerovaný paketový filter NIFIC obstál vo väˇcšine testov výborne, kedže už na rýchlosti prehrávania 10 Gb/s stratovost’ paketov neprekroˇcilahranicu 0,005 %, na rýchlosti 95 % sa neobjavi- la vôbec a všetky pakety prijaté testovacími nástrojmi boli klasifiko- vané správne .

32 5. TVORBATESTOVPRESIETOVÉZARIADENIEˇ NIFIC

Výnimkou je Test klasifikácie paketov podl’a rozsahov IP adries, kde bola na Vzorke 1 nameraná maximálna hodnota stratovosti 2,2 % (vid’ Dodatok C.6) a nulová hodnota sa pri oboch použitých vzorkách objavila až na rýchlosti 7 Gb/s. Druhou výnimkou je Test klasifikácie paketov podl’a MAC adries v ktorom bola nameraná hodnota stratovosti 100 % pre všetky testo- vané rýchlosti. Toto bol jediný prípad, kde klasifikaˇcnýalgoritmus nevykonával oˇcakávanúoperáciu a pakety s príslušnými pravidlami neasocioval5. Jedná sa o známu chybu, na ktorú som upozornil pri štandardnom teste balíˇcku NIFIC 3.3.0 pre projekt Liberouter. Chyba zatial’ nebola odstránená najmä kvôli vývoji verzií 4.0.0 a 4.0.16 s vyššou prioritou.

5. Dôkazom tvrdenia bol pozmenený test, kde sa posledné pravidlo block nahradilo pravidlom pass 0 on 1. V takom prípade boli namerané obdobné hodnoty ako v Teste stratovost’i paketov. 6. Verzie 4.0.0 a 4.0.1 sa zameriavajú hlavne na filtráciou podl’a IPv6 adresy

33 6 Záver

Poˇcastvorby tejto práce som sa zoznámil s hárdverovo akcelero- vaným siet’ovým filtrom NIFIC, preštudoval dokument RFC 2544, z ktorého som navrhol použitú metódu testovania - test stratovosti. Dalejˇ som opísal základné zásady testovania a to použitie štatisticky významnej vzorky a opakovatel’nost’ testu. Následne som sa zameral na prácu s reálnou premávkou, zazna- menal možnosti jej zachytávania a preposielania, opísal relevantné programy a tie hárdverové nástroje, ktorými projekt Liberouter dis- ponuje. Potom som preskúmal štruktúru siet’ových jednotiek a poukázal na riziká spojené s prácou s reálnou premávkou. Ako obranu som navrhol proces anonymizácie zachytených vzoriek reálnej premávky a vyhl’adal vhodné anonymizaˇcnénástroje. V následujúcom kroku som opísal filtraˇcnépravidlá siet’ového zariadenia NIFIC a zo zachytených anonymizovaných vzoriek som vytvoril prehl’ad dôležitých štatistík. Pomocou týchto štatistík, opisu filtraˇcnýchpravidiel a vedomostí o testovaní siet’ových zariadení som navrhol sadu testov. Následne som testy aplikoval a zozbieral namerané hodnoty. Tie som na záver analyzoval a vytvoril zodpove- dajúce tabul’ky a grafy. Za možnosti pokraˇcovaniav práci považujem najmä vytvorenie automatizovaného nástroja na anonymizáciu siet’ovej premávky pre potreby testovania siet’ových zariadení a vývoj nástroja konfiguru- júceho siet’ový filter NIFIC filtraˇcnýmipravidlami na základe získa- ných štatistík zo vstupného testovacieho Pcap súboru.

34 Bibliography

[1] Anonymization tools taxonomy. [online, cit. 2010-30- 11]. http://www.caida.org/tools/taxonomy/ anonymization.xml.

[2] Cesnet homepage. [online, cit. 2010-11-28]. http://www. cesnet.cz.

[3] Description of COMBO cards [online, cit. 2010-11-28]. http: //www.liberouter.org/hardware.php.

[4] Iana - internet assigned numbers authority. [online, cit. 2010-3- 12]. http://www.iana.org.

[5] Ixn2x: Specifications. [online, cit. 2010-11-28]. http:// www.ixiacom.com/products/ixn2x/specifications/ index.php.

[6] Netcope - platform for implementation oh hardware- accelerated networking applications. [online, cit. 2010-29-11]. http://www.liberouter.org/netcope/index.php.

[7] Programmable hardware - liberouter homepage. [online, cit. 2010-25-11]. http://www.liberouter.org.

[8] Tcpdump public repository. [online, cit 2010-11-28]. http:// www.tcpdump.org.

[9] Tcpreplay - pcap editing and replay tools. [online, cit. 2010-11- 28]. http://tcpreplay.synfin.net.

[10] Wireshark - the world’s foremost network protocol ana- lyzer.[online, cit. 2010-11-28]. http://www.wireshark.org.

[11] Spirent testcenter system - reference manual, January 2008.

[12] Spirent XGEM - user guide, July 2008.

[13] S. Bradner. Benchmarking terminology for network intercon- nection devices.RFC1242, July 1991.

35 6. ZÁVER

[14] S. Bradner and J. McQuaid. Benchmarking methodology for network interconnect devices. RFC2544, March 1999.

[15] International Organization for Standardization. Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model, July 1996.

[16] Information Sciences Institute. RFC 791. http://www. rfc-editor.org/rfc/rfc791.txt, 1981.

[17] Information Sciences Institute. RFC 793. http://www. rfc-editor.org/rfc/rfc793.txt, 1981. Edited by Jon Postel.

[18] Toby Miller. Passive os fingerprinting: Details and techniques. http://www.ouah.org/incosfingerp.htm.

[19] David Moore. Summary of anonymization best practice tech- niques. http://www.caida.org/projects/predict/ anonymization, 2008.

[20] T. Mrázek. Srovnávací testy sít’ových karet, 2009.

[21] J. Postel. RFC 768. http://www.rfc-editor.org/rfc/ rfc768.txt, 1981. Edited by Jon Postel.

[22] M. Truneˇcka. Automatizované testy akceleraˇcníkarty s hard- varovou filtrací paketu, 2009.

[23] J. Vykopal and T. Mrázek. Packet capture benchmark on 1 ge, 2008.

36 A Obsah priloženého CD

• Anonymizované vzorky, • Táto práca vo formáte Pdf, • Postupnost’ príkazov anonymizácie zachytenej pre- mávky, • konfiguraˇcnýsúbor nific.conf.

37 B Konfigurácia hostitel’ského poˇcítaˇca

• Názov: panonia.liberouter.org • Poˇcetprocesorov: 4 • Procesor: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz • Základná doska: Supermicro X7DBN • Kapacita pamäte: 10 GB • Operaˇcnýsystém: Linux 2.6.18-194.el5 • Combo karta: comboLXT155 / combo-10G1 • S/N comboLXT155: 8100322 • S/N combo-10G1: 8100377

38 C Výsledky testov

Výsledky testov sú zobrazené vo forme tabuliek a grafu. Mierka per- cent stratovosti paketov je rôzna v závislosti na nameraných výsled- koch.

39 C.VÝSLEDKYTESTOV C.1 Test stratovosti

Vzorka 1 TestCenter Hostitel’ský poˇcítaˇc Spolu Stratovost’ [%] 10 Gb/s 159 297 0 159 297 0,0025 9,5 Gb/s 159 301 0 159 301 0 9 Gb/s 159 301 0 159 301 0 8,5 Gb/s 159 301 0 159 301 0 8 Gb/s 159 301 0 159 301 0 7,5 Gb/s 159 301 0 159 301 0 7 Gb/s 159 301 0 159 301 0 6,5 Gb/s 159 301 0 159 301 0 6 Gb/s 159 301 0 159 301 0

Tabul’ka C.1: Množstvo prijatých paketov

Vzorka 2 TestCenter Hostitel’ský poˇcítaˇc Spolu Stratovost’ [%] 10 Gb/s 168 592 0 168 592 0,0018 9,5 Gb/s 168 595 0 168 595 0 9 Gb/s 168 595 0 168 595 0 8,5 Gb/s 168 595 0 168 595 0 8 Gb/s 168 595 0 168 595 0 7,5 Gb/s 168 595 0 168 595 0 7 Gb/s 168 595 0 168 595 0 6,5 Gb/s 168 595 0 168 595 0 6 Gb/s 168 595 0 168 595 0

Tabul’ka C.2: Množstvo prijatých paketov

40 C.VÝSLEDKYTESTOV

41 C.VÝSLEDKYTESTOV C.2 Test klasifikácie paketov podl’a IP adries

Vzorka 1 TestCenter Hostitel’ský poˇcítaˇc Spolu Stratovost’ [%] 10 Gb/s 12 221 3 986 16 207 0 9,5 Gb/s 12 221 3 986 16 207 0 9 Gb/s 12 221 3 986 16 207 0 8,5 Gb/s 12 221 3 986 16 207 0 8 Gb/s 12 221 3 986 16 207 0 7,5 Gb/s 12 221 3 986 16 207 0 7 Gb/s 12 221 3 986 16 207 0 6,5 Gb/s 12 221 3 986 16 207 0 6 Gb/s 12 221 3 986 16 207 0

Tabul’ka C.3: Množstvo prijatých paketov

Vzorka 2 TestCenter Hostitel’ský poˇcítaˇc Spolu Stratovost’ [%] 10 Gb/s 12 831 3 589 16 410 0 9,5 Gb/s 12 831 3 589 16 410 0 9 Gb/s 12 831 3 589 16 410 0 8,5 Gb/s 12 831 3 589 16 410 0 8 Gb/s 12 831 3 589 16 410 0 7,5 Gb/s 12 831 3 589 16 410 0 7 Gb/s 12 831 3 589 16 410 0 6,5 Gb/s 12 831 3 589 16 410 0 6 Gb/s 12 831 3 589 16 410 0

Tabul’ka C.4: Množstvo prijatých paketov

42 C.VÝSLEDKYTESTOV

43 C.VÝSLEDKYTESTOV C.3 Test klasifikácie paketov podl’a MAC adries

Vzorka 1 TestCenter Hostitel’ský poˇcítaˇc Spolu Stratovost’ [%] 10 Gb/s 0 0 0 100 9,5 Gb/s 0 0 0 100 9 Gb/s 0 0 0 100 8,5 Gb/s 0 0 0 100 8 Gb/s 0 0 0 100 7,5 Gb/s 0 0 0 100 7 Gb/s 0 0 0 100 ... 0 0 0 100 0,5 Gb/s 0 0 0 100

Tabul’ka C.5: Množstvo prijatých paketov

Vzorka 2 TestCenter Hostitel’ský poˇcítaˇc Spolu Stratovost’ [%] 10 Gb/s 0 0 0 100 9,5 Gb/s 0 0 0 100 9 Gb/s 0 0 0 100 8,5 Gb/s 0 0 0 100 8 Gb/s 0 0 0 100 7,5 Gb/s 0 0 0 100 7 Gb/s 0 0 0 100 ... 0 0 0 100 0,5 Gb/s 0 0 0 100

Tabul’ka C.6: Množstvo prijatých paketov

44 C.VÝSLEDKYTESTOV

45 C.VÝSLEDKYTESTOV C.4 Test klasifikácie paketov podl’a protokolov 4. vrstvy

Vzorka 1 TestCenter Hostitel’ský poˇcítaˇc Spolu Stratovost’ [%] 10 Gb/s 115 619 43 308 158 927 0,0050 9,5 Gb/s 115 627 43 308 158 935 0 9 Gb/s 115 627 43 308 158 935 0 8,5 Gb/s 115 627 43 308 158 935 0 8 Gb/s 115 627 43 308 158 935 0 7,5 Gb/s 115 627 43 308 158 935 0 7 Gb/s 115 627 43 308 158 935 0 6,5 Gb/s 115 627 43 308 158 935 0 6 Gb/s 115 627 43 308 158 935 0

Tabul’ka C.7: Množstvo prijatých paketov

Vzorka 2 TestCenter Hostitel’ský poˇcítaˇc Spolu Stratovost’ [%] 10 Gb/s 123 486 44 003 167 489 0,0035 9,5 Gb/s 123 492 44 003 167 495 0 9 Gb/s 123 492 44 003 167 495 0 8,5 Gb/s 123 492 44 003 167 495 0 8 Gb/s 123 492 44 003 167 495 0 7,5 Gb/s 123 492 44 003 167 495 0 7 Gb/s 123 492 44 003 167 495 0 6,5 Gb/s 123 492 44 003 167 495 0 6 Gb/s 123 492 44 003 167 495 0

Tabul’ka C.8: Množstvo prijatých paketov

46 C.VÝSLEDKYTESTOV

47 C.VÝSLEDKYTESTOV C.5 Test klasifikácie paketov podl’a príznakov protokolu TCP

Vzorka 1 TestCenter Hostitel’ský poˇcítaˇc Spolu Stratovost’ [%] 10 Gb/s 1303 476 1779 0 9,5 Gb/s 1303 476 1779 0 9 Gb/s 1303 476 1779 0 8,5 Gb/s 1303 476 1779 0 8 Gb/s 1303 476 1779 0 7,5 Gb/s 1303 476 1779 0 7 Gb/s 1303 476 1779 0 6,5 Gb/s 1303 476 1779 0 6 Gb/s 1303 476 1779 0

Tabul’ka C.9: Množstvo prijatých paketov

Vzorka 2 TestCenter Hostitel’ský poˇcítaˇc Spolu Stratovost’ [%] 10 Gb/s 1990 448 2438 0 9,5 Gb/s 1990 448 2438 0 9 Gb/s 1990 448 2438 0 8,5 Gb/s 1990 448 2438 0 8 Gb/s 1990 448 2438 0 7,5 Gb/s 1990 448 2438 0 7 Gb/s 1990 448 2438 0 6,5 Gb/s 1990 448 2438 0 6 Gb/s 1990 448 2438 0

Tabul’ka C.10: Množstvo prijatých paketov

48 C.VÝSLEDKYTESTOV

49 C.VÝSLEDKYTESTOV C.6 Test klasifikácie paketov podl’a rozsahov IP adries

Vzorka 1 TestCenter Hostitel’ský poˇcítaˇc Spolu Stratovost’ [%] 10 Gb/s 56 004 81 246 137 250 2,2282 9,5 Gb/s 56 213 81 735 137 948 1,731 9 Gb/s 56 482 82 414 138 896 1,0557 8,5 Gb/s 56 675 82 414 139 089 0,9182 8 Gb/s 56 791 83 229 140 020 0,255 7,5 Gb/s 56 840 83 416 140 256 0,0869 7 Gb/s 56 857 83 497 140 354 0,017 6,5 Gb/s 56 864 83 514 140 378 0 6 Gb/s 56 864 83 514 140 378 0

Tabul’ka C.11: Množstvo prijatých paketov

Vzorka 2 TestCenter Hostitel’ský poˇcítaˇc Spolu Stratovost’ [%] 10 Gb/s 79 349 65 820 145 169 0,7771 9,5 Gb/s 79 462 66 054 145 516 0,5400 9 Gb/s 79 583 66 301 145 884 0,2884 8,5 Gb/s 79 655 66 486 146 141 0,1128 8 Gb/s 79 689 66 573 146 262 0,0301 7,5 Gb/s 79 702 66 595 146 297 0,0062 7 Gb/s 79 703 66 603 146 306 0 6,5 Gb/s 79 703 66 603 146 306 0 6 Gb/s 79 703 66 603 146 306 0

Tabul’ka C.12: Množstvo prijatých paketov

50 C.VÝSLEDKYTESTOV

51 C.VÝSLEDKYTESTOV C.7 Test ostrihávania paketov

Vzorka 1 TestCenter Hostitel’ský poˇcítaˇc Spolu Stratovost’ [%] 10 Gb/s 115 619 43 308 158 927 0 9,5 Gb/s 115 627 43 308 158 935 0 9 Gb/s 115 627 43 308 158 935 0 8,5 Gb/s 115 627 43 308 158 935 0 8 Gb/s 115 627 43 308 158 935 0 7,5 Gb/s 115 627 43 308 158 935 0 7 Gb/s 115 627 43 308 158 935 0 6,5 Gb/s 115 627 43 308 158 935 0 6 Gb/s 115 627 43 308 158 935 0

Tabul’ka C.13: Množstvo prijatých paketov

Vzorka 2 TestCenter Hostitel’ský poˇcítaˇc Spolu Stratovost’ [%] 10 Gb/s 123 486 44 003 167 489 0 9,5 Gb/s 123 492 44 003 167 495 0 9 Gb/s 123 492 44 003 167 495 0 8,5 Gb/s 123 492 44 003 167 495 0 8 Gb/s 123 492 44 003 167 495 0 7,5 Gb/s 123 492 44 003 167 495 0 7 Gb/s 123 492 44 003 167 495 0 6,5 Gb/s 123 492 44 003 167 495 0 6 Gb/s 123 492 44 003 167 495 0

Tabul’ka C.14: Množstvo prijatých paketov

52 C.VÝSLEDKYTESTOV

53 D Popis gramatiky filtraˇcnýchpravidiel

Filter language

The "Filter language" is used to describe a rule set for the NIFIC filter. It is similar to the OpenBSD PF or FreeBSD ipfw language and is NOT case-sensitive.

Constants

Decimal and hexadecimal digits are defined: dec_digit := ’0’ - ’9’ hexadecimal_digit := dec_digit | (’a’ - ’f’)

Decimal constant is a sequence of decimal digits: dec_const := dec_digit+

Hexadecimal constant is a sequence of hexadecimal digits: hexadecimal_const := hexadecimal_digit+

IP address is a sequence of four decimal constants from range 0-255 separated by ’.’. The address may be followed by a ’/’ and a number of bits from the left that are considered in evaluation. There must be no space around ’/’ character:: ipv4_const := dec_const (’.’ dec_const){3} [’/’ dec_const]

Examples of correct IPv4 addresses:

10.0.0.0/8 10.1.2.3

MAC address is a sequence of six doubles of hexadecimal numbers

54 D.POPIS GRAMATIKY FILTRACNÝCHˇ PRAVIDIEL

00-FF separated by ’:’ : mac_const := hexadecimal_const (’:’ hexadecimal_const){5}

Lists

List is a set of constant ranges surrounded by brackets ’{’ and ’}’. The list may only contain one range type. Commas ’,’ are ignored inside lists: list := ’{’ (constant_range | ’,’)* ’}’

In case a list is used as an attribute value then the condition is satisfied when the attribute equals at least one of the list items. That means the rule:

100 pass 1 from { 10.0.0.0/8, !10.1.2.3 } has the same meaning as the two rules, which passes any packet::

100 pass 1 from 10.0.0.0/8 100 pass 1 from !10.1.2.3

Therefore it is not recommended to use a negation in a list.

Rules

The rule specify an action which is performed on the packet when all requested conditions are met. The rule is defined by following syntax:: rule := id action [’on’ interface] [’proto’ protocol] (’from’ src_addr [’mac’ src_mac] [’port’ src_port]) (’to’ dst_addr [’mac’ dst_mac][’port’ dst_port])

55 D.POPIS GRAMATIKY FILTRACNÝCHˇ PRAVIDIEL (’flags’ [set_flags] ’/’ checked_flags) [’flowid’ flowid]

ID is the first thing defined in the rule. It also specifies rule priority. Lower numbers denotes higher priority. Id is from 0 to 65535: id := dec_const

Packets may be blocked or passed (sent) to several interfaces. Passed packets may also be cropped to a defined sizes: action := (’pass’ (interface_number+) [’crop’ size]) | ’block’ interface_number := dec_const size := dec_const

Interface is defined by a decimal constant or list of decimal constants from the range 0-15 possibly with negation: action := (’pass’ (interface_number+) [’crop’ size]) | ’block’ interface_number := dec_const size := dec_const

Protocol is defined by a keyword ’TCP’, ’UDP’, ’ICMP’ or a decimal number from the file /etc/protocols. It is also possible to use negation and lists of protocols: protocol := protocol_range | list protocol_range := [’!’] protocol_const protocol_const := ’tcp’ | ’udp’ | ’icmp’ | dec_const (’to’ dst_addr [’mac’ dst_mac][’port’ dst_port]) (’flags’ [set_flags] ’/’ checked_flags) [’flowid’ flowid]

ID is the first thing defined in the rule. It also specifies rule priority. Lower numbers denotes higher priority. Id is from 0 to 65535:

56 D.POPIS GRAMATIKY FILTRACNÝCHˇ PRAVIDIEL id := dec_const

Packets may be blocked or passed (sent) to several interfaces. Passed packets may also be cropped to a defined sizes: action := (’pass’ (interface_number+) [’crop’ size]) | ’block’ interface_number := dec_const size := dec_const

Interface is defined by a decimal constant or list of decimal constants from the range 0-15 possibly with negation: action := (’pass’ (interface_number+) [’crop’ size]) | ’block’ interface_number := dec_const size := dec_const

Protocol is defined by a keyword ’TCP’, ’UDP’, ’ICMP’ or a decimal number protocol := protocol_range | list protocol_range := [’!’] protocol_const protocol_const := ’tcp’ | ’udp’ | ’icmp’ | dec_const

Source and destination address may be defined by keyword ’any’ which means any address, by one IP address, by address with negation using character ’!’ or by address list:: src_addr := dst_addr := ’any’ | ipv4_range | list linebreak ipv4_range := [’!’] ipv4_const

Mac address is defined by single address or by list of addresses: src_mac := dst_mac := mac_const | list

57 D.POPIS GRAMATIKY FILTRACNÝCHˇ PRAVIDIEL

Source and destination port may be specified by port range or by list of port ranges: src_port := dst_port := port_range | list

Range is defined by no operator meaning the exact specified value, by unary operators non-equal ’!=’, lesser ’<’, greater ’>’, lesser or equal ’<=’ or greater or equal ’>=’ and binary operators in range without borders ’><’, out of range ’<>’ or in range including borders ’:’: port_range := dec_const | ((’!=’ | ’<’ | ’>’ | ’<=’ | ’>=’) dec_const) | (dec_const (’><’ | ’<>’ | ’:’) dec_const)

TCP flags are given in the form set/checked. Individual flags are represented by their first letter. For example ’S/SA’ means to check SYN and ACK, where only SYN is set: set_flags := checked_flags := (’F’ | ’S’ | ’R’ | ’P’ | ’A’ | ’U’ | ’E’ | ’C’)

Flow ID is a user defined identifier that is returned when the rule is matched. flowid := dec_const

58