012345

}w !"#$%&'()+,-./012345
Masarykova univerzita Fakulta informatiky

Testování firewallů pomocí hardwarového testovacího přístroje Bakalářská práce

Petr Potůček

Brno, 2012

Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Petr Potůček

Vedoucí práce: doc. RNDr. Eva Hladká, Ph.D. ii

Poděkování Touto cestou bych chtěl poděkovat panu Ing. Jiřímu Novotnému za rady a vedení práce, Ing. Viktorovi Poušovi, za rady a pomoc při nastavování firewallů a propojů a paní doc. RNDr. Evě Hladké, Ph.D., za vedení práce a cenné informace.

iii

Shrnutí Cílem této bakalářské práce je seznámit čtenáře se základní strukturou zabezpečení počítačové sítě, principem fungování firewallů a přiblížením firewallů NIFIC a firewallu založeného na IP Tables. Tyto dva firewally otestovat pomocí hardwarového testovacího přístroje s důrazem na výkonnostní charakteristiky a porovnat je.

iv

Klíčová slova NIFIC, firewall, testování, Liberouter, IP Tables, zabezpečení, bezpečnost, COMBO, RFC

v

Obsah Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Přehled kapitol . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Zabezpečení sítě . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Bezpečnostní politika . . . . . . . . . . . . . . . . . . . . . . . 2.2 Hloubková ochrana sítě . . . . . . . . . . . . . . . . . . . . . 2.2.1 Obvod sítě . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Vnitřní síť . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Lidský faktor . . . . . . . . . . . . . . . . . . . . . . . 3 Firewally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Základní rozdělení a charakteristika firewallů . . . . . . . . . 3.1.1 Paketový filtr . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Stavový firewall . . . . . . . . . . . . . . . . . . . . . . 3.1.3 Aplikační brána . . . . . . . . . . . . . . . . . . . . . 3.1.4 Hardwarově akcelerovaný firewall . . . . . . . . . . . . 4 Přehled základních dokumentů o testování síťových prvků 4.0.5 RFC 1242 . . . . . . . . . . . . . . . . . . . . . . . . . 4.0.6 RFC 2544 . . . . . . . . . . . . . . . . . . . . . . . . . 4.0.7 RFC 2647 . . . . . . . . . . . . . . . . . . . . . . . . . 4.0.8 RFC 3511 . . . . . . . . . . . . . . . . . . . . . . . . . 5 Testované firewally . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Hardwarově akcelerovaná filtrace síťového provozu NIFIC . . 5.1.1 NIFIC verze . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Filtrování paketů v systému Linux . . . . . . . . . . . . . . . 5.2.1 NetFilter . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 IP Tables . . . . . . . . . . . . . . . . . . . . . . . . . 6 Metody testování síťových zařízení . . . . . . . . . . . . . . . 6.1 Testování pomocí hardwarových zařízení . . . . . . . . . . . . 6.1.1 Spirent TestCenter2000 . . . . . . . . . . . . . . . . . 6.2 Testování pomocí softwaru . . . . . . . . . . . . . . . . . . . . 7 Testy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Test propustnosti hw přeposílání . . . . . . . . . . . . . . . . 7.2 Test vlivu počtu pravidel na propustnost . . . . . . . . . . . . 7.3 Test ztrátovosti hardwarového přeposílání paketů . . . . . . . 7.4 Test propustnosti do cílové aplikace pro NIFIC 3.1 a 4.0 . . . 7.5 Shrnutí výsledků . . . . . . . . . . . . . . . . . . . . . . . . . 8 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Reporty jednotlivých testů . . . . . . . . . . . . . . . . . . . . 1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 3 4 4 5 5 6 7 8 8 8 8 10 10 11 11 11 12 13 14 14 17 17 17 18 20 20 20 20 22 22 25 27 29 30 31 33

1

1 Úvod Internet je systém navzájem propojených počítačových sítí, ve kterých mezi sebou počítače komunikují podle síťových protokolů. Jeho vznik je datován kolem roku 1947, kdy za studené války hrozilo rozsáhlé ničení komunikační infrastruktury jadernými zbraněmi. Tato hrozba byla impulzem pro zadání požadavku na vývoj komunikační sítě pro počítače, která by v případě výpadku jednoho segmentu byla schopna stále fungovat. První takováto síť byla vyvinuta pouze pro vojenské účely, konkrétně pro radarové systémy. V roce 1958 byla založena agentura ARPA, která o jedenáct let později uvedla do provozu síť ARPANET se 4 uzly, které představovaly univerzitní počítače v různých částech USA. Tato síť byla decentralizovaná a neměla tedy snadno zničitelné centrum. Od této doby počet připojených počítačů roste ohromným tempem, síť se stává komerční a v současné době je připojeno přes 2 miliardy uživatelů. Vzhledem k velikosti Internetu požadavky na bezpečnost stále rostou. Každý den jsou uživatelé vystavováni pokusům o útoky, často i v řádech tisíců, až stotísíců denně. Proto vyvstává otázka, jak síť před těmito útoky ochránit. Základní infrastrukturu zabezpečení v každé organizaci řeší bezpečnostní politika, která určuje co, jak a proti komu se má chránit. Specifikuje, co se chápe jako citlivá data, jaká existují rizika, jaká je pravděpodobnost jejich naplnění, co dělat v případě útoku, jak se před ním bránit a další. Opatření proti útokům tvoří hloubkovou ochranu, která se skládá z obvodu sítě, první obranné linie, vnitřní sítě a často opomíjeného lidského faktoru. Tato práce se zabývá firewallem, který může být součástí obvodu i vnitřní sítě a určuje, jakým způsobem se budou filtrovat jednotlivé pakety, které jím procházejí. Firewall se umísťuje na hraniční směrovače, které jsou prvními vstupními, respektive posledními výstupními prvky naší sítě, osobní počítače, směrovače, případně další prvky přes které proudí pakety. Takovéto filtry je potřeba v období návrhu, při vývoji i po něm velmi důsledně otestovat a to jak funkčně tak výkonnostně. Cílem mé práce je, mimo seznámení se strukturou zabezpečení sítě, otestovat a porovnat dva různé firewally se zaměřením na jejich výkonnostní charakteristiky. Jedná se o firewall založený na IP Tables, což je nástroj pro specifikaci pravidel firewallu v Linuxu a hardwarově akcelerovanou filtraci síťového provozu NIFIC[11]. Tento filtr je vyvíjen a testován v rámci projektu Liberouter[1] na Masarykově Univerzitě. Zabývá se vývojem vysokorychlostních hardwarově akcelerovaných síťových zařízení založených na programovatelných čipech FPGA1 . Projekt Liberouter spolupracuje se společností CESNET 2 a Vysokým učením technickým v Brně.

1. Field-programmable Gate Array 2. sdružení založené v roce 1996 českými veřejnými vysokými školami a Akademií věd ČR

2

1. Úvod

1.1

Přehled kapitol

První kapitola seznamuje s tématem bezpečnosti počítačových sítí. Následuje část o zabezpečení počítačové sítě, ve které jsou shrnuty základní pojmy, používané dále v práci, popsána bezpečnostní politika a jednotlivé komponenty hloubkové ochrany sítě. Třetí část pojednává o firewallech a jejich rozdělení. Ve čtvrté části jsou rozebírány základní dokumenty RFC3 zabývající se testováním síťových zařízení a firewallů. Praktická část práce se skládá z popisu testovaných firewallů NIFIC a IP tables, popisem metod pro testování síťových zařízení a samotných testů. V závěru shrnuji poznatky o firewallech. Na konci práce uvádím reporty z jednotlivých testů.

3. Request for Comments

3

2 Zabezpečení sítě Zabezpečení počítačové sítě by mělo být realizováno ve vrstvách. Příchozí i odchozí pakety musí projít hraničními směrovači organizace, vnitřními směrovači a dalšími prvky uvnitř organizace až k cíli. Jednotlivé prvky uvnitř sítě jsou rozloženy do vrstev, přičemž každá z nich je na své úrovni nějak zabezpečena (princip vrstvené ochrany). V případě útoku by útočník potřeboval dostatečně výkonný hardware a znalosti, aby se mu podařilo prolomit všechny vrstvy a dostal se k citlivým datům v přiměřeném čase. Základní strukturu zabezpečení sítě nám popisuje bezpečnostní politika.

2.1

Bezpečnostní politika

Bezpečnostní politika řeší zabezpečení organizace od ostrahy, až po ochranu dat. Tvoří ji několik hierarchicky provázaných dokumentů, které určují strukturu zabezpečení uvnitř organizace. Jedná se o: •

Bezpečnostní politiku organizace

•

Bezpečnostní politiku informací

•

Bezpečnostní politiku IT

Bezpečnostní politika organizace Souhrn bezpečnostních zásad a principů, definujících správu a ochranu aktiv. Aktivum představuje něco, co má pro organizaci neopominutelnou hodnotu. Každé aktivum má svou hodnotu, na základě které je mu přidělena míra ochrany. Dokument definuje zabezpečení organizace jako celku. Hlavním cílem je zajištění dostupnosti, důvěrnosti a integrity.

Dostupnost Prevence ztráty přístupu k datům. Dostupnost musí být zajištěna spolehlivým a včasným přístupem k datům pro autorizované osoby. Zapříčinění nedostupnosti se stává oblíbeným způsobem útoků. Zavádějí se proto redundantní mechanismy, záložní systémy a školí zaměstnanci, jak systém uvést zpět do funkčního stavu. Důvěrnost Prevence neautorizovaného vyzrazení dat. Důvěrnost dat by měla být zachována jak při uchovávání dat, tak při posílání a předání.

Integrita Zajištění, že data jsou přesná, s daným obsahem a bez neautorizované úpravy dat. Integrita může být porušena například virem, podvržením programu nebo i vlastní chybou.

Bezpečnostní politika informací Jedná se o souhrn bezpečnostních zásad a principů pro ochranu informačních aktiv. Běžně 4

2. Zabezpečení sítě se píše neformálně v přirozeném jazyce, lze však použít i formální logicko-matematické jazyky. Pak je možné dosáhnout vysoké úrovně důvěryhodnosti. Politika dále musí splňovat nadřazenou bezpečnostní politiku organizace, z níž částečně vychází. Stanovuje koncepci zabezpečení informací organizace na 5-10 let. Dokument obsahuje definici, co lze chápat jako citlivá aktiva, klasifikuje odpovědnosti za jejich stav, definuje třídu útočníků, proti kterým se přijímají opatření. Měla by být nezávislá na použitých technologiích. Maximální rozsah dokumentu by měl být přibližně dvě strany A4. Při její tvorbě se postupuje následovně: •

Posouzení vstupních vlivů

•

Hodnocení rizik organizace (analýza rizik a jejich vyhodnocení)

•

Vypracování projektu, který obsahuje plán zvládnutí rizik a prohlášení o aplikovatelnosti

•

Implementace a prosazení

•

Plnění činnosti pod kuratelnou

•

Vyhodnocení

Některé kroky mohou být prováděny současně, můžeme se však setkat i s vynecháním některého z nich. Bezpečnostní politika IT Prezentuje ve svých pravidlech široký souhrn pečlivě vybraných opatření, závazných pro celou oblast IT organizace.

2.2

Hloubková ochrana sítě

S bezpečnostní politikou jsme již seznámeni, proto mohu přejít k popisu hloubkové ochrany sítě, která je součástí bezpečnostní politiky, jelikož chráníme aktiva a strukturu zabezpečení určenou bezpečnostní politikou a jejími dokumenty. Hloubková ochrana sítě má také několik částí. Obvod sítě, vnitřní síť a samotné zaměstnance nebo obecněji lidský faktor. Každá z těchto částí je složena z dalších komponent, které se vzájemně doplňují a tvoří tak celkové zabezpečení sítě. Jednotlivé vrstvy jsou na sebe vázány, a měly by být zabezpečeny bez výjimky. Není totiž možné dosáhnou efektivního zabezpečení, například pokud nemáme chráněnou vnitřní síť nebo pokud zaměstnance neinformujeme o bezpečenostních zásadách. [2] 2.2.1 Obvod sítě Do obvodu sítě spadá mnoho prvků od všech druhů firewallů přes detekční systém IDS, až po virtuální privátní sítě. V této části bych chtěl přiblížit jednotlivé prvky a jejich roli v zabezpečení sítě. Statický paketový filtr bývá zpravidla použit na hraničním směrovači, který je prvním prvkem naší sítě, přes který proudí pakety ze sítě vnější. Tento filtr kontroluje v každém paketu jen základní informace, proto má minimální vliv na propustnost oproti například proxy 5

2. Zabezpečení sítě firewallu, který již zohledňuje více informací, ale zároveň při velkém provozu na síti již nemá propustnost dostatečnou. Takto kontrolujeme především vstupní, případně i výstupní provoz. Účinnost filtru závisí na nadefinovaných pravidlech. Při sestavování pravidel je vhodné využít veřejné seznamy škodlivého provozu jako SANS Top 20 [10]. Stavový firewall mimo statického filtrování sleduje i aktivní spojení. Jedná se o nejběžnější typ firewallů. Proxy firewall je nejvyspělejším, ale i nejméně používaným typem. Oproti stavovému komunikují vnitřní a vnější hostitelské systémy přes proxy. Není vhodný na místa, kde je nutný plynulý a rychlý provoz. Podrobněji rozeberu jednotlivé firewally v samostatné kapitole. Detekční systémy IDS (Intrusion Detection System) detekují neobvyklé aktivity, které by mohly vést k narušení bezpečnosti v počítačové síti. Na strategických místech jsou rozmístěny senzory, které obsahují mechanizmy pro detekci škodlivých a nebezpečných kódů. V případě detekce o tom informují. Výstrahy se obvykle generují pomocí dvou metod. První je detekce anomálií. Ta je založena na statistické analýze a detekuje odchylky nespadající do běžného chování. Druhá metoda je detekce signatur. Signatura je vzor, který se v síti vyhledává a na základě které se případně pošle výstraha. Na rozdíl od firewallů tedy do provozu nijak nezasahují, pouze analyzují. Existují však i senzory, které dokáží aktivně reagovat na podezřelý přenos a například přerušit podezřelá TCP spojení. Poslední zmiňovanou částí obvodu sítě je virtuální privátní síť (VPN). Jedná se o logické spojení, které je zavedeno nad již existující veřejnou infrastrukturou pomocí autentizačních, nebo šifrovacích technologií pro vytvoření bezpečného komunikačního kanálu. Komunikace může být zabezpečena na mnoha odlišných vrstvách, například na aplikační, kde šifrování může být zajištěno programově nebo pomocí zabezpečených kanálů jako SSH, transportní (protkolem SSL) či síťové (protokol IPSec). 2.2.2 Vnitřní síť Pomocí výše popsaného obvodu sítě chráníme vnitřní síť organizace, ve které jsou umístěny servery, vnitřní směrovače, pracovní počítače, úložné systémy, systémy UPS1 a další potřebná zařízení. To však neznamená, že by vnitřní síť nebylo třeba zabezpečit, opak je pravdou. Vnitřní síť je třeba chránit před útoky zevnitř, kdy uživatel může nevědomě zavést škodlivý software do naší sítě nebo při prolomení obvodu sítě. Důkladným zabezpečením vnitřní sítě přispíváme k již zmíněné vrstvené ochraně. Z mechanizmů zabezpečení se zde využívá filtrování na vnitřních směrovačích, senzory IDS, proxy servery, osobní firewally, které nás částečně zabezpečí například při zmiňovaném připojení mimo organizaci, antivirový software, konfigurace operačního systému, kdy se u všech systémů a zařízení v síti zavádí jistá známá konfigurace. Jako kontrola našeho zabezpečení 1. systém, který zajišťuje souvislou dodávku elektřiny pro zařízení, která nesmějí být neočekávaně vypnuta

6

2. Zabezpečení sítě slouží audit, při kterém nezávislá třetí strana pozoruje realitu, vyhodnocuje ji a navrhuje změny. Ten by se měl pravidelně opakovat kvůli ověření, že je vše tak, jak má být. 2.2.3 Lidský faktor Za veškerým návrhem, konfigurací a správou, však stojí člověk a ten může chybovat. V tomto případě mám na mysli zaměstnance ve firmě, který pracuje na firemním počítači. Člověk neseznámený s bezpečnostními procedurami tvoří jisté riziko, proto se nesmí zapomínat na tuto poslední část hloubkové ochrany a zaměstnance pravidelně informovat o zásadách bezpečnosti například formou školení. Samozřejmě je seznamovat s interními pravidly, které definuje bezpečnostní politika.

7

3 Firewally Před tím, než přejdeme k samotnému testování, přiblížím, co to firewall vlastně je, jaké existují základní typy a jak fungují. Firewall je síťové zařízení, které slouží k řízení a zabezpečení provozu na síti, mezi dvěma nedůvěryhodnými sítěmi. Má nadefinovaná pravidla, podle kterých určuje, jaký provoz smí projít a jaký bude zahozen. Mezi nejjednodušší firewally patří ty, které filtrují provoz pouze na základě zdrojové a cílové IP adresy a čísla portu. Takovýto filtr je vcelku efektivní, protože není příliš časově náročný. Modernější typy firewallů již využívají více informací například o stavu spojení, znalosti kontrolovaných protokolů nebo se opírají o prvky IDS.

Obrázek 3.1: Ukázka umístění firewallu

3.1

Základní rozdělení a charakteristika firewallů

3.1.1 Paketový filtr Paketový filtr filtruje pakety na základě informací v jejich hlavičce. Konkrétně zdrojové a cílové adresy, zdrojového a cílového portu či rozhraní. Přijde-li tedy paket, firewall si zjistí potřebné informace, porovná s nadefinovanými pravidly a buď ho přepošle dál nebo zahodí. V základní podobě pracuje firewall pouze na síťové vrstvě ISO/OSI modelu a není schopen se rozhodovat podle vyšších vrstev. Tento způsob se stále pro svoji nenáročnost na výkon používá na místech, kde není třeba důkladné filtrování a je třeba velká propustnost, například u směrovačů. Jako nevýhodu lze brát, že nerozumí návaznosti paketů, jelikož se rozhoduje pouze podle jedné vrstvy ISO/OSI (viz obr. 3.2). Aby byl filtr účinný, je klíčové správně nastavit pravidla. Povolit opravdu jen to, co je potřeba a dbát na správné pořadí pravidel. Paketové filtry můžeme využít buďto ve spojení s jinými firewally, nebo v oblastech nízkého rizika i rozpočtu, jelikož se nejedná o drahé řešení. 3.1.2 Stavový firewall Stavový firewall je již oproti paketovému filtru chytřejší, pracuje na transportní a nižší případně částečně aplikační vrstvě ISO/OSI modelu (viz obr. 3.2). Kromě funkce paketového filtru si udržuje tabulku aktuálně navázaných spojení. Jednotlivé položky se v tabulce tvoří při zahájení relace, která jde přes stavové zařízení. Příchozí pakety jsou pak porovnávány s tabulkou a v případě shody podle pravidla propuštěny dál nebo zahozeny. Informace ve 8

3. Firewally

Obrázek 3.2: ISO/OSI model a znázornění firewallů stavové tabulce musí být jednoznačné a podrobné, aby případný útočník nemohl napodobit provoz, který by mohl projít. O každém spojení se uchovává určitá skupina informací, která by měla relaci jednoznačně identifikovat, tedy například zdrojová a cílová adresa, čísla portů, pořadové číslo, příznaky, protkol, typ ICMP1 . Nejnáročnější kontrola je prováděna během navázání spojení, poté jsou již pakety zpracovávány rychleji. Datagram může spadat do následujících kategorií: •

NEW - zahájení nové komunikace

•

ESTABLISHED, RELATED - navázané spojení

•

INVALID - datagram je neidentifikovatelný, nenáleží do žádného existujícího spojení

Stav relace lze sledovat různými způsoby, přičemž nelze zvolit jeden konstantní. Například u protokolu TCP je využit trojcestný handshake. Jako zahajovací paket je považován paket, který má nastavený příznak SYN2 na 1, čímž firewall pozná, že se jedná o nové spojení. Jeli služba na serveru k dispozici, odpoví odesláním paketu s nastaveným příznakem SYN na 1 a ACK 3 na 1. Celou úvodní komunikaci završí klient, který pošle serveru paket s nastaveným příznakem ACK na 1, čímž je spojení ustaveno jako ESTABLISHED. Filtr pak propustí pouze pakety s již navázaným a povoleným spojením. Aby spojení v tabulce nezůstávala navždy, je třeba je také ukončit. To lze pomocí sledování stavu, kdy podle příznaku poznáme, že se například jedná o poslední paket nebo pomocí času do konce (TTL 4 ), což je položka v hlavičce IP datagramu, která určuje maximální dobu existence paketu a chrání tak síť před zahlcením. Případně při dlouhé odmlce posílá klient serveru zprávy keepalive, aby spojení zůstalo navázáno. U protokolu UDP už je to složitější, protože se jedná o nespojovanou službu. V tomto případě můžeme použít IP adresy a čísla portů. Podobně v dalších protokolech je vždy třeba najít atributy, které stav definují.

1. 2. 3. 4.

Internet Control Message Protocol Synchronize Acknowledgement Time To Leave

9

3. Firewally Celkově je stavový firewall bezpečnější než paketový filtr a není tak náročný na výkon jako vyspělejší proxy firewall, proto najde své využití například při obvodovém zabezpečení nebo ve větší síti. 3.1.3 Aplikační brána Tetno typ firewallu se liší od předešlých především tím, že není možné komunikovat mezi dvěma sítěmi napřímo, tak jako tomu bylo u stavového či paketového filtru. V praxi to znamená zakázání IP forwardingu. Filtr pracuje na aplikační vrstvě ISO/OSI (viz obr. 3.2), proto lépe rozumí obsahu paketů a jejich návaznosti. Veškerá komunikace mezi klientem a serverem probíhá přes třetí stranu, kterou zastává proxy brána (proxy server). Nikdo z vnější sítě proto nevidí do vnitřní sítě. Pakety určené do vnější sítě nejdříve putují na proxy bránu se zdrojovou adresou původce, na aplikační bráně se zdrojová adresa změní na adresu brány, která dále vystupuje jako zprostředkovatel. Zpětná komunikace funguje na podobném principu, tedy paket, který je určen pro naši síť, jde nejdříve na bránu, ze které je následně poslán na cílovou adresu. (viz obr. 3.3) Proxy bránu si lze představit jako kombinaci klienta a serveru v jednom, navíc se specializací pro jednu službu. Existují tedy brány zvlášť pro služby WWW, FTP, SSH, elektronickou poštu a mnoho dalších.

Obrázek 3.3: Znázornění průchodu paketů přes aplikační bránu Výhodou aplikační brány je kvalitní zabezpečení známých protokolů, díky tomu, že pracuje na aplikační vrstvě. Nevýhodou však je poměrně velká náročnost na hardware počítače, brány nejsou schopné pracovat na stejné rychlosti jako například paketové filtry a mají vyšší latenci. Aplikační brány se využívají v místech, kde není třeba filtrovat velké množství dat během krátké doby.[3] 3.1.4 Hardwarově akcelerovaný firewall Hardwarově akcelerované firewally jsou většinou formou externího zařízení (například PCI karty), které obsahuje programovatelný hardware. Samotné filtrování paketů probíhá na kartě, čímž není tolik zatížen procesor hostitelského počítače. Toto řešení umožňuje filtrovat vysokorychlostní sítě, což je při použití samotných softwarových řešení obtížně proveditelné. Záleží však na hardwarové architektuře daného firewallu. Jako příklad hardwarově akcelerovaného firewallu uvádím NIFIC[11] , který je vyvíjen v rámci projektu Liberouter[1] na Masarykově Univerzitě. Podrobnějšímu popisu tohoto firewallu se věnuji v následující kapitole.

10

4 Přehled základních dokumentů o testování síťových prvků Testování síťových prvků podléhá standartizaci. Vytvářením těhto standardů se zabývá skupina BMWG1 , patřící pod IETF2 . Definuje v těhto dokumentech základní pojmy kvůli jednoznačnosti, popisuje jednotlivé testy a metodiky testování a definuje, jak by měl vypadat výstup testů. Pro účely této práce jsem vybral následující dokumenty. 4.0.5 RFC 1242 Tento dokument s názvem Benchmarking terminology for Network Interconnection Devices je prvním dokumentem vydaným skupinou BMWG v roce 1991[4]. Definuje základní pojmy používané v dalších vydaných dokumentech a formát, v jakém by měly být prezentovány výsledky jednotlivých testů. Jedná se o pojmy jako Back-to-back rámce, most, router, konstantní zatížení a další. Pro účely této práce podrobněji vysvětlím: Latence Časový interval, který začíná v momentě, kdy první bit dosáhne vstupní port a končí, když ho vidíme na výstupním portu. Router Zařízení, které přeposílá data na základě informací v síťové vrstvě. Propustnost Maximální rychlost, při které se neztratí žádný rámec. 4.0.6 RFC 2544 Tento dokument nahradil dřívější RFC 1944[5] z roku 1996 a definuje několik testů, které mohou být použity pro popsání výkonnostních charakteristik síťových zařízení[7]. Výsledky testů poskytnou porovnatelná data pro různé výrobce. Tento dokument vychází částečně z dokumentu RFC 1242, ve kterém je definováno mnoho pojmů zde používaných. Rozlišuje se zde mezi výrazy musí, měl by a volitelné, jako i v jiných dokumentech RFC a podle toho, jak testy splňují požadavky, buď vyhovují zcela, částečně, nebo nevyhovují. Na síťové zařízení se v tomto dokumentu díváme jako na blackbox, tedy nás nezajímá co je uvnitř, zajímají nás pouze jeho výkonové charakteristiky. V dokumentu je dále popsáno ideální zapojení testovaného zařízení, dále pouze DUT (Device Under Test) a testeru. Ideálně by měly být rámce posílány z odesílajícího portu testeru na přijímající port DUT a z posílajícího portu DUT zpátky do testeru. Díky tomu, že tester poslal i přijal všechny rámce, dokáže snadno určit, zdali se nějaký ztratil. Část dokumentu je věnována nastavení zařízení, které musí odpovídat konfiguraci uvedené v testovací zprávě. Všechny protokoly podporované testovaným zařízením by měly být nakonfigurovány a spuštěny. Testy by také měly být provedeny beze změny v konfiguraci zařízení. Všechny popisované testy by měly být spuštěny vícekrát, nejméně s pěti rozdílnými velikostmi rámců, ideálně včetně rámců s minimální a maximální povolenou velikostí pro dané médium. 1. Benchmarking Methodology Working Group 2. nternet Engineering Task Force

11

4. Přehled základních dokumentů o testování síťových prvků Pro Ethernet jsou to velikosti rámců: 64, 128, 256, 512, 1024, 1518 bytů. Také zmiňuje problematiku filtrování paketů, kdy je filtr nejdříve nastaven pouze s jedním pravidlem, které přepošle vše na výstupní port. Poté se test zopakuje, avšak s 25 pravidly, přičemž 24 s vyšší prioritou nebude mít vliv na provoz. Všechen ostatní provoz by měl být zamítnut. Cílem tohoto testu je vliv počtu pravidel na výkon, přičemž počítá, že zařízení bere pravidla lineárně za sebou. Poslední částí dokumentu před popisem jednotlivých testů jsou obecné zásady provádění testů. Po zapojení a nakonfigurování testováného zařízení spustíme generátor provozu. Po odeslání všech přichystaných rámců počkáme dvě vteřiny. Následně vyhodnotíme výsledky a před dalším testem počkáme alespoň 5 vteřin, kvůli stabilizaci testovaného zařízení. Jeden test by měl trvat nejméně 60 vteřin, RFC připouští i zkrácení tohoto intervalu, avšak pouze s tím, že poslední měření by mělo být provedeno na plném intervalu. Následuje popis jednotlivých testů, z nichž jsem pro potřeby své práce vybral: Test propustnosti Testo test má za cíl určit propustnost definovanou v RFC 1242. Postup: Na DUT je určitou rychlostí posláno množství rámců, přičemž zjišťujeme, kolik jich bylo pomocí DUT přeposláno zpět. Pokud je počet poslaných rámců rovný počtu přijatých, zvýšíme rychlost posílání a zkusíme test znovu. Výsledná hodnota je největší rychlost, jakou je možné rámce posílat, bez toho, že se některý ztratí. Výsledky by měly být prezentovány grafem, kde osa x představuje délku rámců a y rychlost jejich posílání. Mimo jiné by v grafu měla být zanesena i maximální teoretická propustnost. Test ztrátovosti Cílem je určit ztrátovost rámců definovanou v RFC 1242, za použití celé šíře rychlosti posílání dat a délky rámců. Postup: Tento test začíná odesláním rámců se 100 procentní rychlostí linky. Pokud je počet vyslaných a přijatých rámců rovný, ztrátovost je nulová, pokud ne, snížíme rychlost posílání dat a opakujeme. Jednotlivé kroky by měly být menší než 10 procent. Výsledky jsou počítány za použití následujícího vzorce: ((počet odeslaných rámců – počet přijatých rámců) * 100) / počet odeslaných rámců Hodnoty by měli být zaneseny do grafu, kde osa x představuje procentuální zatížení linky a osa y procentuální ztrátovost. [7] 4.0.7 RFC 2647 Dokument RFC 2647[8] s názvem Benchmarking Terminology for Firewall Performance definuje pojmy používané v měření výkonu firewallů, vychází mimo jiné i z RFC 1242, avšak místo rámců již používá pakety, vzhledem k vrstvě, o které se v souvislosi s tímto dokumentem 12

4. Přehled základních dokumentů o testování síťových prvků bavíme. Z definovaných pojmů jsem vybral následující: Povolený provoz Pakety, které prošly na základě nastavených pravidel DUT. Spojení Stav, kdy dva hosté nebo host a DUT souhlasí s výměnou dat za použití známého protokolu. Ustanovení spojení Data vyměněná mezi hosty nebo mezi hostem a DUT, pro zahájení spojení. Demilitarizovaná zóna (DMZ) Prvek sítě umístěný mezi chráněnou a nechráněnou sítí. Firewall Zařízení nebo skupina zařízení, která prosazuje politiku řízení přístupu mezi sítěmi. Network adress translation (NAT) Metoda mapování jedné nebo více privátních rezervovaných IP adres na jednu nebo více veřejných. Zamítnutý provoz Pakety zahozené na základě nastavených pravidel DUT.

4.0.8 RFC 3511 Tento dokument se zabývá testováním výkonnosti firewallů, avšak výhradně stavových filtrů a aplikačních bran. Obsahuje popis testů IP propustnosti, přenosové rychlosti HTTP, zpoždění, zvládání fragmentace IP paketů apod.[9]

13

5 Testované firewally 5.1

Hardwarově akcelerovaná filtrace síťového provozu NIFIC

Hardwarově akcelerovaná karta s filtrací síťového provozu NIFIC[11] slouží ke zpracovávání síťových toků maximální rychlostí linky bez ztráty paketu. Umožňuje filtrovat počítačovou síť s rychlostí linky až 10 Gbit/s. Architekturu NIFICu lze využít například jako bezstavový firewall, inteligentní rozbočovač či jako nástroj pro sledování datového toku. Tato karta je vyvíjena v rámci projektu Liberouter na Masarykově Univerzitě. Systémová architektura NIFICu je složena z několika vrstev. První a základní vrstvou je hardware, pod kterým se skrývá samotná akcelerovaná karta COMBOv2[1] s FPGA čipem, odpovědná za fyzickou úroveň, například přenos signálů. Vrstva, kde je umístěn firmware zajišťuje akceleraci pomocí FPGA čipu. Všechny pakety jsou přijímány a klasifikovány právě v této vrstvě. Nad firmwarem se nachází jádro, což je modul operačního systému Linux, který je zodpovědný za konfiguraci a komunikaci s uživatelským prostorem. Ten zahrnuje software a knihovny pro správu systému (viz obr. 5.1).

Obrázek 5.1: firewallu[13]

Struktura

Obrázek 5.2: konfigurace[13]

Lokální

Lokální konfigurace V tomto případě je firewall konfigurován přímo z hostitelského pořítače. Uživatel musí vytvořit soubor s pravidly, zapsanými speciálním jazykem a nahrát je pomocí nificgend démona zobrazeného na obrázku. Ten připraví strukturu dat a nakonfiguruje klasifikaci v jádru systému. Pravidla nahrajeme za pomocí nástroje nific-config[11] (viz obr. 5.2).

14

5. Testované firewally Vzdálená konfigurace Pokud budeme chtít konfigurovat firewall vzdáleně, musíme využít vzdálené kontrolní centrum, které komunikuje s hostitelským počítačem firewallu pomocí Netconf protokolu. Nificgend démon je zde použit podobně jako v lokální konfiguraci, s tím rozdílem, že konigurační data přijímá od vzdáleného centra. Co v lokální konfiguraci nevystupovalo a nebylo třeba, je démon nificexp, který přeposílá vybrané pakety na vzdálené centrum, které je monitoruje. Nificd zde vystupuje jako prostředník mezi všemi částmi (viz obr. 5.3).

Obrázek 5.3: konfigurace[13]

Vzdálená

Obrázek 5.4: paketů[13]

Klasifikace

Algoritmus klasifikace paketů Klasifikační algoritmus je tou nejdůležitější částí nificu, jelikož tento firewall je určen pro vysokorychlostní sítě a při větším množství pravidel by neměl ztrácet na propustnosti. Filtrace je založena na dekompozici problému. V prvním kroku jsou paralelně zpracovávána všechna významná pole z hlavičky jednotlivých paketů za pomocí LPM algoritmu[13]. Tento algoritmus použitý v NIFICu je založený na TreeBitmap algoritmu. Jako výsledek prvního zpracování hlaviček paketů je jedno 67 bitové slovo. Analýzy však ukázaly, že pro několik slov je možné dosáhnout stejného pravidla. Tato slova se nazývají pseudopravidla. Aby se tomuto problému předešlo, byla vytvořena speciální hašovací funkce, která předchází kolizím a všechna pseudopravidla, která směřují na stejný výsledek pomocí hašovací funkce, převede na stejné číslo(viz obr. 5.4). Hašovací funkce ale přiřadí výsledek pro každý paket, tedy i pro ten, který nemá odpovídající pravidlo, proto se v poslední části porovnává hlavička paketu s odpovídajícím pravidlem. Pokud hlavička sedí pravidlu, bylo nalezeno správné pravidlo, pokud ne, pravidlo neexistuje. Pakety mohou být filtrovány na základě MAC adres, Ipv4 adres, L4 protokolů, TCP a UDP portů, TCP příznaků a čísla rozhraní. Jednoduchá pravidla, která konfigurují NIFIC firmware pro přeposílání paketů z jednoho portu na druhý, by vypadala následovně: 1 pass 0 on 1 2 pass 1 on 0 3 block 15

5. Testované firewally Architektura firmwaru Firmware je vyvinut nad platformou NetCOPE, která obsahuje vstupní a výstupní bufffery a DMA kontrolory. Na obrázku (č. 5.5) můžeme vidět celý proces zpracovávání paketů. Systém poskytuje tři cesty, dvě přes 10G porty a jednu přes PCI rozhraní, jelikož aplikace mohou také přijímat a posílat pakety. Všechny tři cesty jsou implementovány FrameLink protokolem v FPGA čipu. Pakety ze sítě jsou přijaty XGMII IBUF modulem a konvertovány do FrameLink formátu. Pokud je paket poslán ze softwaru, jde přes DMA1 TX Buffer a poté je stejně jako v ostatních cestách přeložen. Přeložené pakety dále proudí do HFE (Header Field Extraction), kde jsou, jak jsem již výše popisoval, rozparsovány hlavičky paketů. Po rozparsování jdou jednou cestou pakety zabalené FrameLink protokolem a druhou pouze rozparsované hlavičky, které míří do klasifikačního algoritmu, popsaného dříve. Výsledek tohoto algoritmu je poslán do Header Insert modulu, kde se přidělí paketu pravidlo a akce. Crossbar modul pak má na starost poslání rámce na správný výstup. Tok do softwaru je ukládán na DMA RX Bufferu, odkud je přeposlán do apliakce. QDR-II paměť slouží k ukládání pravidel[13].

Obrázek 5.5: Struktura firmwaru[13]

1.

Direct Memory Access

16

5. Testované firewally 5.1.1 NIFIC verze V této práci testuji a porovnávám dvě různé verze firewallu NIFIC. Základní architektura je u obou verzí stejná, pouze s několika málo rozdíly. Proto v následujícím odstavci popíši, v čem se verze 3.1 a 4.0 liší a proč tomu tak je. Asi nejpodstatnějším rozdílem je přidaná podpora klasifikace podle IPv6 adres, jelikož ta ve verzi 3.1 chyběla. Tato vlastnost byla přidána do firmwaru a softwaru NIFICu. Implementace probíhala ve dvou fázích, v té první bylo využito již implementované jednotky z klasifikačního jádra NIFICu. Ta ale zapříčinila nízký počet podporovaných Ipv6 adres (maximálně 128). Na FPGA čipu byla proto z důvodu úspory místa vynechána podpora klasifikace podle MAC adres. Naopak přibyla možnost klasifikovat pakety podle značek VLAN2 a MPLS3 a byla zvýšena propustnost do softwaru hostitelkého počítače. Druhá fáze byla zaměřena na zvýšení počtu adres IPv4 a IPv6 v pravidlech firewallu. Implementace pro hledání nejdelšího prefixu z předchozí verze byla kompletně předělána. Nový algoritmus je nyní založen na vyhledávání pomocí rozptylovací funkce a treebitmap algoritmu. Tímto řešením bylo dosaženo teoretické propustnosti 100Gbps za podpory tisíců IPv4 i IPv6 adres, čímž se stává vyhovujícím i do budoucna pro potencionální karty do 40 a 100 Gb sítí. Dále byl zvýšen počet podporovaných pravidel z 2048 na 10 000 i více. Toho bylo dosaženo přesunutím tabulky pravidel z blokové paměti na FPGA čipu do exerní paměti QDRII SRAM.

5.2

Filtrování paketů v systému Linux

V operačním systému Linux je paketový filtr zabudován v jádře již od verze 1.1. Od té doby prošel razantním vývojem a v současných verzích Linuxu se používá netfilter a iptables. V následujících podkapitolách popíši, jak funguje a co je Netfilter a IP tables, včetně znázornění průchodu paketů. 5.2.1 NetFilter Zakladatelem projektu Netfilter[12] a IP tables se stal roku 1998 Rusty Russell, australský programátor a advokát, který dal dohromady skupinu programátorů zvanou Core Team. Jejich software je licensován pod General Public Licence (GPL) a byl připojen do operačního systému Linux 2.3 v roce 2000. Současným lídrem této skupiny je Patrick McHardy. Netfilter framework je součástí jádra Linuxu a poskytuje prostředek k manipulaci a zachytávání síťových paketů. Umožňuje řadu věcí, mezi které patří i možnost vytvoření pravidel zastávajících funkci firewallu. Zjednodušené schéma tabulek Netfilteru (viz obr. 5.6). Ebtables Jedná se o nástroj pro filtrování Ethernetových rámců. Je podobný IP tables, pouze jednodušší, jelikož Ethernet protokol není tak složitý jako IP protokol. 2. Virtual Local Area Network 3. Multiprotocol Label Switching

17

5. Testované firewally

Obrázek 5.6: Tabulky Netfilteru Arptables Nástroj pro manupulaci a správu pro filtraci ARP paketů. IP tables Nástroj IP tables vzhledem k jeho rozšíření a velikosti popíši v samostatné kapitole níže. Conntrack Jedna z důležitých vlastností postavená na Netfilter framework je sledování spojení. To umožňuje jádru stále sledovat všechna logická spojení sítí a přiřazovat pakety, které spojení náleží. Mimo jiné se o tyto informace opírá NAT a překládá všechny související pakety stejnou cestou. Ip tables můžou využít tyto informace pro chování jako stavový firewall. Jednotlivá spojení mohou být: NEW ESTABLISHED RELATED INVALID UNTRACKED

snaha o vytvoření nového spojení součást již existujícího spojení připsáno paketu, který se snaží navázat nové spojení a který byl očekáván paket byl zhodnocen jako vadný speciální stav, který může paketu přiřadit administrátor, aby se vyhnul jeho sledování

Pro lepší pochopení lze jako příklad uvést první paket spojení. Conntrack subsystém jej uvidí a označí ho jako NEW. Další pakety náležící tomuto spojení budou již označeny jako ESTABLISHED, případný ICMP error daného spojení by byl označen jako RELATED. Paket, který nebude souhlasit s žádným z navázaných spojení, bude označen jako INVALID.

5.2.2 IP Tables IP tables[12] je nástroj pro konfiguraci a správu tabulek filtrovacích pravidel. Tyto tabulky obsahují předem nebo i uživatelsky definované skupiny pravidel, které se nazývají řetězce a na základě kterých samotné filtrování běží. Jedná se o tabulky filter, nat a mangle, přičemž přístupnost záleží na konfiguraci jádra. Filter Tato tabulka se použije automaticky, pokud nedefinujeme jako výchozí jinou. Mezi základní předdefinované řetězce této tabulky patří INPUT, OUTPUT a FORWARD (viz obr. 18

5. Testované firewally

Obrázek 5.7: Ilustrace cesty paketů tabulkami 5.8). Ty mohou být doplněné uživatelsky definovaným řetězcem, na který ale musí odkazovat nějaké pravidlo ze základních, aby byl dostupný. Pokud paket směřuje dovnitř sítě, aplikuje se na něj řetezec INPUT, pokud směřuje ven ze sítě, řetězec OUTPUT a pokud není pro náš počítač a je povolené přeposílání paketů (IP forwarding), použije se FORWARD a INPUT i OUTPUT se vynechá. Nat Tabulka nat má také tři řetězce, PREROUTING, POSTROUTING a OUTPUT. PREROUTING je řetězec, který se aplikuje na příchozí pakety. Pomocí něho můžeme editovat cílovou adresu paketu. V případě POSTROUTING můžeme definovat odchozí spojení, neboli Source NAT (SNAT). Toho je využíváno, pokud potřebujeme skrýt více síťových prvků za jednu IP adresu. Nakonec tabulka OUTPUT se aplikuje před odchodem paketů do vnější sítě. Mangle Tato tabulka obsahuje všechny řetězce, INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING. Řetězce jsou tvořeny jednotlivými pravidly. Paket v řetězci putuje od shora dolů, dokud nevyhoví nějakému pravidlu, přičemž může být přijat (ACCEPT), zamítnut (REJECT) nebo zahozen (DROP). Pokud paket nevyhoví žádnému z pravidel, přichází na řadu politika řetězce, která ho může akceptovat nebo zahodit. V případě uživatelsky definovaných řetězců se paket pošle zpět na místo, odkud byl uživatelsky definovanému řetězci poslán. Pravidla v řetězci by měla jít od konkrétnějších po obecnější, v opačném případě by se specifičtější pravidlo nedostalo na řadu. Definice pravidel se provádí pomocí příkazů, nebo přes software. Základní syntaxe pro zápis pravidel se samozřejmě liší od NIFICu a vypadá následovně: iptables [tabulka][akce][řetězec][ip část][match][cíl][cíl info] 19

6 Metody testování síťových zařízení Síťové prvky je třeba před zařazením do provozu a prodeje otestovat a to jak z hlediska funkčního tak výkonnostního. Typy testů a formát reportů je definován v dokumentech RFC, které jsem zmiňoval výše. V této kapitole bych chtěl rozebrat používané nástroje pro testování síťových prvků a to hardwarových i softwarových.

6.1

Testování pomocí hardwarových zařízení

O hardwarových testovacích zařízeních psal ve své bakalářské práci Ing. Jan Vykopal[15], proto zde uvedu pouze nástroj Spirent Test Center 2000, který jsem k testování používal a který v této práci uvedený není. 6.1.1 Spirent TestCenter2000 Spirent Communications je jedna z největších společností zabývajících se výrobou testovacích přístrojů komunikačních technologií na světě. Spirent TestCenter2000[17] je jedním z novějších testerů, které má projekt LIBEROUTER k dispozici. Je vybaven kartou s dvanácti porty rychlosti 1Gbps a kartou se dvěma porty o rychlosti až 10Gbps. TestCenter2000 má opravdu široké možnosti nastavení. Mezi základní patří samozřejmě nastavení obsahu a velikosti paketů, jejich protokolových hlaviček, adres, možnost definovat proud paketů s krokovou či náhodnou změnou IP adres s následným náhledem. Dále lze zadat délku mezery mezi jednotlivými pakety, definovat dobu vysílání či dávky, lze si nastavit více proudů najednou a pouštět je najednou nebo jednotlivě atd. Tester lze ovládat přes GUI nebo pomocí Tcl knihovny z příkazového řádku. GUI je přehledné s mnoha možnostmi. Na začátku každého testování je třeba rezervovat přímo v programu porty. Po proběhnutí rezervace se objeví v pravém sloupci v záložce Ports, přičemž u každého z nich máme možnou volbu mezi generováním paketů, analyzováním paketů, nastavením zařízení a zachytávání. Po zvolení generátoru paketů již lze definovat provoz a jeho parametry. Paketům je možné dát jakoukoli hlavičku, nastavit adresy cíle, zdroje a brány, velikost, rychlost, ttl a další. Pro analyzování výsledků testů lze využít analyzátor dostupný pro každý port nebo jen jednoduše počítat pakety příjaté a odeslané v případě, že nepotřebujeme detailněji zkoumat obsah. Jako nevýhodu grafického rozhraní lze určitě brát zdlouhavost testování, jelikož vše je třeba nastavit ručně pro každý test. Tester však můžeme ovládat i pomocí TCL knihovny a algortimů, címž se můžeme vyhnout zdlouhavému procesu nastavování a hledání výsledné hodnoty ručně.

6.2

Testování pomocí softwaru

Softwarem pro testování se zabývá dokument RFC 2398[6], který uvádí několik užitečných aplikací, většinou se specifickou funkcí pro testování síťových zařízení. Tento dokument byl vydán v roce 1998. Vzhledem k tomu, že se o těhto nástrojích zmiňoval v již zmíněné práci Ing. Jan Vykopal[15], vypíši zde pouze změny v novějších verzích.

20

6. Metody testování síťových zařízení DBS 1.2.0 Cílem této aplikace je otestovat protokol TCP a jeho funkce. Umožňuje koordinovat vícenásobný přenos dat a analyzovat chování TCP protokolu. Výsledek je prezentován jako ASCII soubor. Poslední verze DBS 1.2.0 (Distributed Benchmark System) byla vydána roku 1998, do té doby nevyšla novější verze. IPerf 2.0.5 Nástroj pro testování protokolů TCP a UDP. Můžeme pomocí něj sledovat šířku pásma, zpoždění a ztrátu paketu. Poslední verze je 2.0.5 z roku 2010. V programu bylo provedeno několik úprav, proto již méně zatěžuje CPU pod operačním systémem Linux a přibyla hlavička statistik reportů. Také byla upravena man stránka v operačním systému Linux a přidán přepínač -Z pro simulaci přetížení. NetPerf 2.5.0 NetPerf je možné použít pro měření výkonnosti různých typů sítí. Poskytuje testy jak pro propustnost tak pro end-to-end zpoždění. Tato poslední verze má několik nových možností v příkazové řádce, jako například –S pro nastavení SO_KEEPALIVE. Výstup pomocí možnosti -D v příkazové řádce byl obohacen o sekundy a milisekund. NetPIPE 3.7.1 Nezávislý, výkonný nástroj, který vizuálně představuje síťový výkon za různých podmínek. Poslední verze 3.7.1 má navíc kontrolu integrity (-i), dále byly odstraněny problémy se streaming režimem.

21

7 Testy Mým cílem bylo otestovat firewally NIFIC a IP tables, vzhledem k výkonnostním charakteristikám a porovat je. Pro test jsem vybral dvě verze firewallu NIFIC, kde chci poukázat na změny, které byly provedeny v novější verzi oproti starší a firewall založený na IP tables. Ze všeho nejdříve bylo třeba určit, co bude nejlépe specifikovat výkon daných firewallů. Poté provést konfiguraci, testy a vyhodnotit je. Pro všechny testy bylo použito stejné zapojení, tedy tester Spirent Test Center 2000 připojený dvěma 10Gb porty na DUT (Device Under Test), kde DUT představovalo počítač se zapojenou kartou NIFIC nebo v případě IP tables s kartou Intel. Podrobnější konfigurace strojů:

7.1

Stroj:

mossel (NIFIC 3.1)

veneto (NIFIC 4.0)

Počet procesorů: Procesor: Základní deska: Operační systém: Použitá karta: Paměť: Stroj:

4 Intel Xeon E5420 2,50 Ghz Supermicro X7DB8 Linux 2.6.18 ComboLXT155 10G2 2 GiB rhone (IP Tables)

4 Intel Xeon E5410 2,33 Ghz Supermicro X7DBN Linux 2.6.32 ComboLXT155 10G2 4 GiB

Počet procesorů: Procesor: Základní deska: Operační systém: Použitá karta: Paměť:

4 Intel Xeon E5410 2,33 Ghz Supermicro X7DB8 Linux 2.6.32 Intel Corporation 82599EB - 10G2 4 GiB

Test propustnosti hw přeposílání

Vzhledem k tomu, že typické využití firewallu NIFIC je bezstavový filtr, je vhodné otestovat propustnost mezi jednotlivými porty. Maximální hodnota pro NIFIC by měla být 10Gbps pro každý port, vzhledem k rychlosti portů na kartě COMBO. Oběma porty pak 20Gbps, při použití jednoduchých pravidel, která budou přeposílat vše z jednoho rozhraní na druhé. Tento typ testu je vhodný i pro IP tables, vzhledem k tomu, že se jako bezstavový firewall použivají. Jejich teoretická propustnost je limitována nastavením jádra systému, pravidly a rychlostí portů síťové karty, podobně jako u NIFICu. V mém případě měl každý port maximální propustnost 10Gbps. Cílem tohoto testu je nastínit rozdíl mezi firewallem s hardwarovou akcelerací a firewallem čerpajícího systémové zdroje. Použitá pravidla NIFICu: 1 pass 0 on 1 2 pass 1 on 0 3 block

22

7. Testy Použitá pravidla IP Tables: iptables -P FORWARD DROP iptables -A FORWARD -s 192.168.0.1 -j ACCEPT Tedy výchozí politika řetězce FORWARD nastavená na zahození paketů a pravidlo, které umožní průchod paketu s danou zdrojovou adresou. Průběh testu: Jedná se o test propustnosti definovaný v RFC 2544. Jedním portem jsem posílal pakety o velikostech 64, 128, 256, 512, 1024, 1280, 1518 bajtů. Dále pro délky spadající do mezery, tedy 96, 192, 384, 768, 1152, 1399 bajtů. Pro každou velikost paketů jsem pustil určitou rychlostí pakety na DUT. Pokud se žádný neztratil, rychlost jsem zvýšil a test opakoval. Výsledná hodnota byla nejvyšší možná, při níž se neztratily žádné pakety. Výsledky: Délka rámce[B]

NIFIC 3.1 [Gbps]

NIFIC 4.0 [Gbps]

IP Tables [Gbps]

64 96 128 192 256 384 512 768 1024 1152 1280 1399 1518

10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00

10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00

0,29 0,40 0,51 0,73 0,95 1,39 1,82 2,67 3,50 3,92 4,25 4,74 5,13

Obrázek 7.1: Propustnost HW přeposílání

23

7. Testy Závěr testu Jak je možné vidět z naměřených hodnot, NIFIC dosáhl v obou verzích propustnosti 10Gbps, s tím, že zatížení procesoru bylo ve všech případech délek paketů nulové. Naopak IP Tables nedosáhly zdaleka tak velké propustnosti a zatížení procesoru se celou dobu pohybovalo mezi 14 až 21 procenty, jak uvádím v příloze A v podrobném reportu z testů. Tyto výsledky jsou důsledkem různé implementace, zatímco NIFIC zpracovává vše na COMBO kartě, IP Tables musí čerpat systémové zdroje, které jej limitují.

24

7. Testy

7.2

Test vlivu počtu pravidel na propustnost

Jelikož testuji firewally, které mohou mít v některých případech i stovky pravidel, nabízí se jako další vhodný test, vliv počtu pravidel na propustnost. Zde je mezi NIFICem a IP tables další rozdíl. Přidělení příslušného pravidla v NIFICu zpracovává jádro (viz kapitola č. 5.1). U IP Tables se prochází pakety od vrchu dokud nenarazí na vyhovující pravidlo. Pokude se tak nestane, přijde na řadu výchozí politika řetězce. Cílem tohoto testu je poukázat na rozdíl v propustnosti mezi těmito dvěma přístupy. Použitá pravidla: Pro tento test jsem si sestavil sady pravidel o velikosti 1, 25, 100 a 250 pravidel. V každé této sadě bylo pravidlo povolující provoz umístěno až na konec souboru. Nahrání pravidel do firewallu předcházelo každému testu. U IP tables jsem používal skript, NIFIC jsem konfiguroval lokálně pomocí nific-config ze souboru. Průběh testu: Průběh testu byl obdobný testu propustnosti hardwarového přeposílání s tím rozdílem, že hodnota byla měřena pro více sad pravidel. Výsledky: Výsledné hodnoty pro firewall NIFIC byly beze změny oproti dříve naměřené propustnosti, tedy pro všechny sady pravidel na všech měřených délkách paketů beze ztrát. U IP tables se však projevil neefektivní systém vyhledávání příslušného pravidla, proto dále vypíši pouze výsledné hodnoty pro IP Tables. Délka rámce[B]

64 128 256 512 1024 1280 1518

Propustnost [Gbps] 1 pravidlo

25 pravidel

100 pravidel

250 pravidel

0,29 0,51 0,95 1,82 3,50 4,35 5,13

0,28 0,49 0,92 1,77 3,43 4,26 5,05

0,23 0,41 0,77 1,47 2,89 3,59 4,25

0,15 0,27 0,49 0,95 1,86 2,33 2,75

Závěr testu V tomto testu vyvstal rozdíl mezi způsobem vyhledávání pravidel u obou firewallů. Pro větší sady pravidel IP tables významě ztrácejí na propustnosti. Důvodem této ztráty je především neefektivní algoritmus jejich vyhledávání.

25

7. Testy

Obrázek 7.2: Vliv počtu pravidel na propustnost

26

7. Testy

7.3

Test ztrátovosti hardwarového přeposílání paketů

Jedná se o test definvaný v dokumentu RFC 2544, s tím rozdílem, že jsem ho provedl pouze pro velikost paketu 64B a 1518B, tedy hraniční hodnoty. Test jsem provedl na IP tables i obou verzích NIFICu. Cílem tohoto testu je otestovat ztrátovost hardwarového přeposílání paketů. Použitá pravidla NIFICu: 1 pass 0 on 1 2 pass 1 on 0 3 block Použitá pravidla IP Tables: iptables -P FORWARD DROP iptables -A FORWARD -s 192.168.0.1 -j ACCEPT Průběh testu: Na DUT jsem posílal pakety plnou rychlostí linky (10Gbps), pokud se nějaký paket ztratil, rychlost posílání jsem snížil a test opakoval, dokud se počet poslaných a přijatých paketů nerovnal. Jednotlivé kroky by měly být maximálně 10 procent. Výsledky:

Obrázek 7.3: Ztrátovosti pro paket o velikosti 64B

27

7. Testy

Obrázek 7.4: Ztrátovosti pro paket o velikosti 1518B Závěr testu V tomto testu se projevila nízká propustnost IP tables, které měly pro velikost paketu 64B velmi vysokou ztrátovost. Pro hodnotu 1518 jsem na dříve naměřené hodnotě propustnosti naměřil ztrátu paketů. Naopak NIFIC v obou verzích neztratil žádný paket a dosáhl nulové ztrátovosti.

28

7. Testy

7.4

Test propustnosti do cílové aplikace pro NIFIC 3.1 a 4.0

Tento test má za cíl ověřit, zda-li dosahuje NIFIC verze 4.0 vyšší propustnosti do cílové aplikace než verze 3.1. Použitá pravidla NIFICu: 1 pass 3 on 1 2 pass 2 on 0 3 block Průběh testu: Na DUT jsem posílal pakety plnou rychlostí linky. Pokud se žádný paket neztratil, rychlost posílání jsem zvýšil a test opakoval. Výsledná hodnota byla nejvyšší možná, při níž se neztratily žádné pakety. V testu jsem využíval grafické rozhraní a knihovnu sze2data pro měření propustnosti do softwaru. Výsledky:

Obrázek 7.5: Propustnost do cílové aplikace Závěr testu Z výsledků je patrné, že propustnost pro pakety větších než 768B se razantně zvýšila. Naopak pro pakety menší lehce klesla.

29

7. Testy

7.5

Shrnutí výsledků

Na závěr testů je nutné říci, že IP tables a Netfilter mají řadu rozšíření a nastavení. Jádro systému jde upravit, jednotlivá rozšíření mohou řešit problém efektivněji než samotné IP tables a lze tak dosáhnout lepších hodnot při měření. Dalším důležitým faktorem je hardware hostitelského počítače, jelikož v případě IP tables je to jeden z hlavních limitujících faktorů. Testováním IP tables a Netfilteru na různých konfiguracích PC se částečně zabývá práce Netfilter Performance Testing[18]. Ve své práci jsem se zaměřil pouze na základní verzi na jedné konfiguraci. U novější verze firewallu NIFIC byla prokázána větší propustnost do cílové aplikace. V práci jsem se zaměřil pouze na prostředí IPv4, proto jsem další vylepšení NIFICu v podobě podpory IPv6 netestoval. IPtables jsou mocný nástroj, který velmi dobře poslouží v sítích s menším tokem dat, pro účely filtrace vysokorychlostních sítí má však NIFIC nesporné výhody, především v podobě hardwarové akcelerace a efektivního algoritmu pro vyhledávácí příslušného pravidla.

30

8 Závěr Při tvorbě této práce jsem se seznámil s prvky zabezpečení počítačové sítě, od navržení bezpečnostní politiky, až po způsob zabezpečení vnitřní sítě. Dále jsem nastudoval problematiku firewallů, jejich základní druhy a principy fungování. V praktické části jsem prostudoval základní RFC dokumenty týkající se problematiky testování síťových zařízení, potažmo i samotných firewallů. Ty jsem v práci popsal současně s několika testy v nich definovaných ze kterých jsem vycházel. Dále jsem se podrobněji seznámil s principem fungování hardwarově akcelerovaného firewallu NIFIC vyvýjeného v rámci projektu LIBEROUTER na Masarykově Univerzitě a firewallu v operačním systému Linux, založeného na IP tables a netfilteru. Následně jsem stručně popsal metody testování síťových zařízení a to jak softwarové tak hardwarové, včetně popisu mnou používaného testeru. Závěrečná část patřila stručné analýze testů vhodných pro porovnání výkonnostních charakteristik firewallů, jejich následnému výběru a provedení. Jednotlivé reporty jsem začlenil do práce formou dodatku a výsledky porovnal v závěru práce.

31

Literatura [1]

Internetové stránky projektu http://www.liberouter.org/.

Liberouter.

[online,

[2]

Stephen Northcutt, Lenny Zeltser, Scott Winters, Karen K. Frederick, Ronald W. Ritchey: Bezpečnost počítačových sítí. CP Books, a.s. [2005].

[3]

S. J. Bigelow: Mistrovství v počítačových sítích. CP Books, a.s. [2004].

[4]

S. Brander: Benchmarking Terminology for Network Interconnection Devices. RFC 1242, 1991.

[5]

S. Brander, J. MvQuaid: Benchmarking Methodology for Network Interconnect Devices. RFC 1944, 1996.

[6]

S. Parker, C. Schmechel: Some Testing Tools for TCP Implementors. RFC 2398, 1998.

[7]

S. Brander, J. MvQuaid: Benchmarking Terminology for Network Interconnection Devices. RFC 2544, 1999.

[8]

D. Newman: Benchmarking Terminology for Firewall Performance. RFC 2647, 1999.

[9]

B. Hickman, D. Newman, S. Tadjudin, T. Martin: Benchmarking Methodology for Firewall Performance. RFC 3511, 2003.

[10]

The Top Cyber Security Risc. [online, http://www.sans.org/top-cyber-security-risks/.

[11]

CESNET, z.s.p.o.: NIFIC handbook. CESNET, z.s.p.o., 2010.

[12]

H. Welte: The Netfilter project. http://www.netfilter.org/index.html..

[13]

V. Puš, T. Dedek: Designing a Hardware-Accelerated Firewall with Two 10 Gbps Ports. CESNET, z.s.p.o., 2008.

[14]

R. Enns: NETCONF Configuration Protocol. RFC 4741, 2006.

[15]

J. Vykopal: Metody testování výkonu prvků síťové infrastruktury. Masarykova Univerzita, Brno, 2006.

[16]

T. Williams, C. Kelley: Gnuplot - utilita pro tvorbu grafů. [online, cit. 2012-05-12], URL: http://www.gnuplot.info/index.html..

[17]

Spirent Test Center 2000. [online, cit. 2012-05-12], http://www.spirent.com/Solutions-Directory/Spirent-TestCenter.aspx..

[18]

J. Kadlecsik, G. Pásztor: Netfilter Performance Testing. [online, cit. 2012-05-12], http://people.netfilter.org/kadlec/nftest.pdf..

[online,

cit.

cit.

cit.

2012-05-12],

URL:

2012-05-12],

URL:

2012-05-12],

URL:

32

A Reporty jednotlivých testů Test propustnosti HW přeposílání NIFICu 3.1 NIFIC verze: Datum testu: Otestoval a sepsal:

3.1 09/2011 Petr Potůček

Konfigurace použitých zařízení Počet procesorů: Procesor: Základní deska: Operační systém: Combo karta: Sériové číslo karty: Paměť:

4 Intel Xeon CPU E5420 @ 2,50 Ghz Supermicro X7DB8 Linux 2.6.18-164.4.1.e15 ComboLXT155 / Combo - 10G2 8100325 / 8100379 2 GiB

Použitá pravidla firewallu 1 2 3

pass 1 on 0 pass 0 on 1 block

Popis testu Stroj mossel s nainstalovaným NIFICem je oběma 10Gb porty připojený k hardwarovému testovacímu nástroji Spirent Test Center 2000. Pomocí grafického rozraní byla měřena propustnost z jednoho portu na druhý. Pro délky paketů dle RFC 2544 64, 128, 256, 512, 1024, 1280, 1518 bajtů. Dále pro délky spadající do mezery, tedy 96, 192, 384, 768, 1152, 1399 bajtů. Pro každou délku paketu trvala jedna iterace 60 vteřin.

33

A. Reporty jednotlivých testů Naměřené hodnoty

Délka rámce[B]

Propustnost [%]

Propustnost [Gbps]

Propustnost [fps]

CPU [%]

64 96 128 192 256 384 512 768 1024 1152 1280 1399 1518

100 100 100 100 100 100 100 100 100 100 100 100 100

10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00

14 880 710 10 775 698 8 445 809 5 896 131 4 528 911 3 093 676 2 349 586 1 586 269 1 197 298 1 066 536 961 523 880 268 811 675

0 0 0 0 0 0 0 0 0 0 0 0 0

Obrázek A.1: Propustnost HW přeposílání

34

A. Reporty jednotlivých testů

Test propustnosti HW přeposílání NIFICu 4.0 NIFIC verze: Datum testu: Otestoval a sepsal:



4 Intel Xeon CPU E5410 @ 2,33 Ghz Supermicro X7DBN Linux 2.6.32-131.12.1.e16.x86_64 ComboLXT155 / Combo - 10G2 8100325 / 8100379 4 GiB



Popis testu Stroj veneto s nainstalovaným NIFICem je oběma 10Gb porty připojený k hardwarovému testovacímu nástroji Spirent Test Center 2000. Pomocí grafického rozraní byla měřena propustnost z jednoho portu na druhý. Pro délky paketů dle RFC 2544 64, 128, 256, 512, 1024, 1280, 1518 bajtů. Dále pro délky spadající do mezery, tedy 96, 192, 384, 768, 1152, 1399 bajtů. Pro každou délku paketu trvala jedna iterace 60 vteřin. Naměřené hodnoty Délka rámce[B]

Propustnost [%]

Propustnost [Gbps]

Propustnost [fps]

CPU [%]

64 96 128 192 256 384 512 768 1024 1152 1280 1399 1518

100 100 100 100 100 100 100 100 100 100 100 100 100

10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00 10,00

14 880 549 10 775 565 8 445 714 5 896 064 4 528 861 3 093 974 2 349 559 1 586 251 1 197 284 1 066 553 961 538 880 281 811 688

0 0 0 0 0 0 0 0 0 0 0 0 0

35



36


Test propustnosti HW přeposílání IP tables Datum testu: Otestoval a sepsal:

05/2012 Petr Potůček

Konfigurace použitých zařízení Počet procesorů: Procesor: Základní deska: Operační systém: Síťová karta: Paměť:

4 Intel Xeon CPU E5410 @ 2,33 Ghz Supermicro X7DB8 Linux 2.6.32-131.12.1.e16.x86_64 Intel Corporation 82599EB - 10G2 4 GiB

Použitá pravidla firewallu Vytvořen most mezi eth1 a eth4. Pravidla: iptables -P FORWARD -j DROP iptables -a FORWARD -s 192.168.0.1 -j ACCEPT Protože v tabulce FORWARD se výchozí politika s důvodu bezpečnosti nenastavuje na ACCEPT, přidal jsem jedno pravidlo, které povolilo provoz pro pakety s danou zdrojovou adresou, tedy se zdrojovou adresou posílaných paketů. Popis testu Stroj rhone s nainstalovaným Linuxem a IP Tables je oběma 10Gb porty připojený k hardwarovému testovacímu nástroji Spirent Test Center 2000. Pomocí grafického rozraní byla měřena propustnost z jednoho portu na druhý. Pro délky paketů dle RFC 2544 64, 128, 256, 512, 1024, 1280, 1518 bajtů. Dále pro délky spadající do mezery, tedy 96, 192, 384, 768, 1152, 1399 bajtů. Pro každou délku paketu trvala jedna iterace 60 vteřin. Výsledná hodnota je zaokrouhlená na dvě desetinná místa.

37

A. Reporty jednotlivých testů Naměřené hodnoty Délka rámce[B]

Propustnost [%]

Propustnost [Gbps]

64 96 128 192 256 384 512 768 1024 1152 1280 1399 1518

2,92 4,02 5,11 7,34 9,51 13,85 18,24 26,65 35,00 39,15 43,46 47,41 51,31

0,29 0,40 0,51 0,73 0,95 1,39 1,82 2,67 3,50 3,92 4,35 4,74 5,13

Propustnost [fps]

434 432 431 432 431 428 428 422 418 417 417 417 416

028 825 630 825 034 082 082 297 901 223 223 781 667

CPU [%]

21 21 21 22 21 20 18 16 14 14 14 14 14


38


Test vlivu počtu pravidel na propustnost HW přeposílání - NIFIC 4.0 Datum testu: Otestoval a sepsal:




Použitá pravidla firewallu Pro tento test jsem si vytvořil soubor s 1, 25, 100 a 250ti pravidly. Před každým spuštěním testu jsem nastavil pravidla ze souboru, kde vždy poslední pravidlo v řetězci povolilo provoz. Popis testu Stroj veneto s nainstalovaným NIFICem je oběma 10Gb porty připojený k hardwarovému testovacímu nástroji Spirent Test Center 2000. Pomocí grafického rozraní byla měřena propustnost z jednoho portu na druhý. Před každým testem byla nejdříve nastavena pravidla. Pro délky paketů dle RFC 2544 64, 128, 256, 512, 1024, 1280, 1518 bajtů. Pro každou délku paketu trvala jedna iterace 60 vteřin. Naměřené hodnoty

Délka rámce[B]

64 128 256 512 1024 1280 1518


25 pravidel

100 pravidel

250 pravidel

10,00 10,00 10,00 10,00 10,00 10,00 10,00

10,00 10,00 10,00 10,00 10,00 10,00 10,00

10,00 10,00 10,00 10,00 10,00 10,00 10,00

10,00 10,00 10,00 10,00 10,00 10,00 10,00

Občas se stávalo, že počítač po zadání příkazu k nastavení pravidel přestal odpovídat. Ve většině případů byl třeba restart, jen v několika se vzpamatoval.

39


Obrázek A.4: Vliv počtu pravidel na HW propustnost

40


Test vlivu počtu pravidel na propustnost HW přeposílání - IP Tables Datum testu: Otestoval a sepsal:


Konfigurace použitých zařízení Počet procesorů: Procesor: Základní deska: Operační systém: Síťová karta: Paměť:


Použitá pravidla firewallu Pro tento test jsem si vytvořil skript s 1, 25, 100 a 250ti pravidly. V každém ze skriptů se nejdříve vyprázdnil řetězec FORWARD v IP tables a následně přidala pravidla, kde až poslední povolilo provoz přes FORWARD. Výchozí politika byla nastavená na DROP. Popis testu Stroj rhone s nainstalovaným Linuxem a IP Tables je oběma 10Gb porty připojený k hardwarovému testovacímu nástroji Spirent Test Center 2000. Pomocí grafického rozraní byla měřena propustnost z jednoho portu na druhý. Před každým testem byla nejdříve nastavena pravidla. Pro délky paketů dle RFC 2544 64, 128, 256, 512, 1024, 1280, 1518 bajtů. Pro každou délku paketu trvala jedna iterace 60 vteřin. Naměřené hodnoty

Délka rámce[B]

64 128 256 512 1024 1280 1518


25 pravidel

100 pravidel

250 pravidel

0,29 0,51 0,95 1,82 3,50 4,35 5,13

0,28 0,49 0,92 1,77 3,43 4,26 5,05

0,23 0,41 0,77 1,47 2,89 3,59 4,25

0,15 0,27 0,49 0,95 1,86 2,33 2,75

41


Obrázek A.5: Vliv počtu pravidel na HW propustnost

42


Test propustnosti do softwaru - NIFIC 3.1 NIFIC verze: Datum testu: Otestoval a sepsal:






Popis testu Stroj mossel s nainstalovaným NIFICem je oběma 10Gb porty připojený k hardwarovému testovacímu nástroji Spirent Test Center 2000. Pomocí grafického rozraní a sze2data byla měřena propustnost do softwaru. Pro délky paketů dle RFC 2544 64, 128, 256, 512, 1024, 1280, 1518 bajtů. Dále pro délky spadající do mezery, tedy 96, 192, 384, 768, 1152, 1399 bajtů. Pro každou délku paketu trvala jedna iterace 60 vteřin. Naměřené hodnoty Délka rámce[B]

Propustnost [%]

Propustnost [Gbps]

64 96 128 192 256 384 512 768 1024 1152 1280 1399 1518

6,60 9,23 11,64 16,36 21,04 29,85 39,10 49,49 49,60 49,74 49,91 49,96 50,19

0,66 0,92 1,16 1,64 2,10 2,99 3,91 4,95 4,96 4,97 4,99 5,00 5,02

Propustnost [fps]

980 992 982 964 952 921 916 784 593 530 479 439 407

446 048 688 491 622 814 510 688 055 239 477 789 735

CPU [%]

21 20 20 20 20 20 11 22 7 16 4 14 6

43


Obrázek A.6: Propustnost do softwaru

Obrázek A.7: Porovnání reálné a teoretické propustnosti do softwaru

44


Test propustnosti do softwaru - NIFIC 4.0 Datum testu: Otestoval a sepsal:






Popis testu Stroj veneto s nainstalovaným NIFICem je oběma 10Gb porty připojený k hardwarovému testovacímu nástroji Spirent Test Center 2000. Pomocí grafického rozraní a sze2data byla měřena propustnost do softwaru. Pro délky paketů dle RFC 2544 64, 128, 256, 512, 1024, 1280, 1518 bajtů. Dále pro délky spadající do mezery, tedy 96, 192, 384, 768, 1152, 1399 bajtů. Pro každou délku paketu trvala jedna iterace 60 vteřin. Naměřené hodnoty Délka rámce[B]

Propustnost [%]

Propustnost [Gbps]

64 96 128 192 256 384 512 768 1024 1152 1280 1399 1518

5,95 8,25 10,06 15,01 19,09 27,24 34,90 47,46 59,01 64,91 68,99 73,94 79,05

0,60 0,83 1,01 1,50 1,91 2,72 3,49 4,75 5,90 6,49 6,90 7,39 7,91

Propustnost [fps]

882 887 849 885 863 842 820 753 705 691 663 651 641

768 784 184 269 260 318 209 012 418 372 482 042 648

CPU [%]

21 20 20 20 20 20 20 21 21 21 21 21 22

45


Obrázek A.8: Propustnost do softwaru

Obrázek A.9: Porovnání reálné a teoretické propustnosti do softwaru

46


Test ztrátovosti hardwarového přeposílání paketů Jedná se o test definvaný v dokumentu RFC 2544, provedeného pro velikosti paketů 64B a 1518B, tedy hraniční hodnoty. Test byl provedet na IP tables a obou verzích NIFICu. Konfigurace použitých zařízení: NIFIC 3.1: Počet procesorů: Procesor: Základní deska: Operační systém: Combo karta: Sériové číslo karty: Paměť:


NIFIC 4.0: Počet procesorů: Procesor: Základní deska: Operační systém: Combo karta: Sériové číslo karty: Paměť:


IP tables: Počet procesorů: Procesor: Základní deska: Operační systém: Síťová karta: Paměť:


Použitá pravidla NIFICu: 1 pass 0 on 1 2 pass 1 on 0 3 block Použitá pravidla IP Tables: iptables -P FORWARD DROP iptables -A FORWARD -s 192.168.0.1 -j ACCEPT Průběh testu: Na DUT jsem posílal pakety plnou rychlostí linky (10Gbps), pokud se nějaký paket ztratil, rychlost posílání jsem snížil a test opakoval, dokud se počet poslaných a přijatých paketů nerovnal. Jednotlivé kroky by měly být maximálně 10 procent.

47

A. Reporty jednotlivých testů Výsledky: IP tables pro paket velikosti 64B: Rychlost [%]

Poslané pakety

100 90 80 70 60 50 40 30 20 10 5 4 3 2

892 844 262 781 238 604 694 990 971 624 990 971 535 706 331 446 422 046 353 768 383 267 853 252 178 568 803 89 284 425 44 642 212 35 713 769 26 785 326 17 856 884

Přijaté pakety

26 26 26 26 26 26 26 26 26 26 26 26 26 17

502 591 500 698 640 339 617 505 679 546 280 481 556 856

854 477 474 853 849 792 238 621 331 354 548 437 312 884

Ztrátovost [%]

97,03 96,60 96,18 95,73 95,02 94,01 92,47 90,10 85,06 70,27 41,13 25,85 0,85 0

IP tables pro paket velikosti 1518B: Rychlost [%]

100 90 80 70 60 50 49 48 47

Poslané pakety

48 43 38 36 29 24 23 23 22

700 819 980 394 250 381 885 403 911

598 163 737 414 750 971 003 031 898

Přijaté pakety

26 26 26 27 23 23 23 23 22

100 055 145 440 128 126 213 205 911

324 629 109 695 077 053 010 551 898

Ztrátovost [%]

46,41 40,50 32,93 24,60 20,93 5,15 2,81 0,84 0

NIFIC 3.1 a 4.0 pro paket velikosti 64B: Rychlost [%]

Poslané pakety

Přijaté pakety

Ztrátovost [%]

100

892 859 385

892 859 385

0

NIFIC 3.1 a 4.0 pro paket velikosti 1518B: Rychlost [%]

Poslané pakety

Přijaté pakety

Ztrátovost [%]

100

48 701 399

48 701 399

0

48


Obrázek A.10: Ztrátovost pro paket o velikosti 64B

Obrázek A.11: Ztrátovost pro paket o velikosti 1518B

49

012345

Recommend Documents