}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Analýza distribuce sít’ového provozu na více výpoˇcetních jader pomocí HW testovacích pˇrístroju˚ ˇ B AKALÁ RSKÁ PRÁCE
Libor Horák
Brno, podzim 2012
Prohlášení Prohlašuji, že tato bakaláˇrská práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Libor Horák
Vedoucí práce: Ing. Štˇepán Friedl ii
Podˇekování Chtˇel bych podˇekovat vedoucímu mé práce Ing. Štˇepánu Friedlovi a Ing. Viktoru Pušovi za odborné vedení, ochotu a cenné rady, které mi pomohly pˇri sepisování této práce. Dále pak dˇekuji Ing. Jiˇrímu Novotnému za velkou vstˇrícnost a kolegum ˚ pracujícím na projektu Liberouter za pomoc pˇri testování. V neposlední rˇ adˇe pak mé rodinˇe a pˇrátelum ˚ za jejich podporu.
iii
Shrnutí Cílem této bakaláˇrské práce je porovnání odolnosti Netflow sond proti útoku pˇri využití distribuce sít’ového provozu mezi více jader procesoru za pomoci sít’ové karty s hardwarovou akcelerací HANIC, která je vyvíjena v rámci projektu Liberouter. Nejprve je popsán princip technologie NetFlow, dále samotná sít’ová karta HANIC a poté následuje rozbor RFC dokumentu˚ týkajících se testování sít’ových zaˇrízení. V další cˇ ásti jsou popsány hardwarové testovací pˇrístroje. Na závˇer se práce vˇenuje testování a porovnání NetFlow sond a jejich chování pˇri útoku.
iv
Klíˇcová slova Liberouter, HANIC, FPGA, COMBOv2, NetFlow, test propustnosti, NetFlow sonda
v
Obsah 1 2
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Technologie NetFlow . . . . . . . . . . . . . . . . . . . 2.1 Tok v poˇcítaˇcových sítích . . . . . . . . . . . . . . . 2.2 NetFlow Exportér . . . . . . . . . . . . . . . . . . . 2.2.1 FlowMon . . . . . . . . . . . . . . . . . . . 2.2.2 Softflowd . . . . . . . . . . . . . . . . . . . 2.2.3 fProbe . . . . . . . . . . . . . . . . . . . . . 2.3 NetFlow kolektor . . . . . . . . . . . . . . . . . . . 3 Sít’ová karta s hadwarovou akcelerací HANIC . . . . . 3.1 Architektura . . . . . . . . . . . . . . . . . . . . . . 3.2 Distribuce provozu mezi jádra procesoru . . . . . 3.3 Vícejádrové procesory . . . . . . . . . . . . . . . . 4 Rozbor RFC dokumentu˚ o testování sít’ových zaˇrízení 4.1 RFC 1242 . . . . . . . . . . . . . . . . . . . . . . . . 4.2 RFC 2544 . . . . . . . . . . . . . . . . . . . . . . . . 5 Hadwarové testovací pˇrístroje . . . . . . . . . . . . . . 5.1 TC2000 . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 AX4000 . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Analýza bˇežného sít’ového provozu . . . . . . . . 5.4 Útok DDoS . . . . . . . . . . . . . . . . . . . . . . . 5.5 Test propustnosti karty HANIC . . . . . . . . . . . 6 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Popis zaˇrízení použitých pˇri testování . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
2 3 3 4 4 4 5 5 6 6 7 8 10 10 11 13 13 14 14 15 16 17 20
1
1 Úvod V posledních letech se rychlost poˇcítaˇcových sítí rapidnˇe zvyšuje. V souˇcasnosti jsou bˇežnˇe nasazeny 1 Gbps a 10 Gbps technologie a již zaˇcala implementace technologie 100 Gbps. Se zvyšující se šíˇrkou pásma poˇcítaˇcových sítí roustou i nároky na zpracování a analýzu sít’ového provozu. Pˇríkladem systému˚ dotˇcených tˇemito nároky jsou firewally, zaˇrízení pro detekci a prevenci vniknutí nebo systémy pro monitorování sít’ových toku. ˚ Stále se zyvšující požadavky na výpoˇcetní výkon, nejen v obalsti sítí, zpusobily ˚ i zmˇeny v architektuˇre poˇcítaˇcových procesoru. ˚ Pˇrístup použití jednoho silného procesoru nahradil jiný, který na jeden cˇ ip umístil více procesorových jader. Aby aplikace pro analýzu sít’ového provozu mohly využít výkon vícejádrových procesoru, ˚ musí svoji práci paralelnˇe rozdˇelit na jednotlivá jádra. Nejefektivnˇejším zpusobem ˚ jak toho dosáhnout je hardwarová akcelerace. Vývojem vysokorychlostních sít’ových zaˇrízení s hardwarovou akcelerací se zabývá projekt Liberouter [3]. Sít’ové prvky toho projektu jsou postaveny na programovatelných FPGA1 cˇ ipech. Jedním z tˇechto zaˇrízení je i sít’ová karta s hardwarovou akcelerací HANIC[6], která umožnuje ˇ zpracování sít’ového provozu až o rychlosti 10 Gbps a jeho rozdˇelení mezi procesorová jádra. Pˇredkládaná práce je rozdˇelena na pˇet hlavních cˇ ástí. V první cˇ ásti je popsán princip technologie NetFlow [5] a jsou vysvˇetleny pojmy jako IP tok, NetFlow exportér nebo NetFlow kolektor. V druhé cˇ ásti je popsána sít’ová karta s hadwarovou akcelerací HANIC a rozdˇelení sít’ového provozu mezi více jader procesoru. V následující cˇ ásti je proveden rozbor RFC2 dokumentu˚ týkajících se testování síˇ t’ových zaˇrízení. Ctvrtá cˇ ást popisuje hardwarové testovací pˇrístroje.. Praktická cˇ ást je vˇenována vlastním testum ˚ sit’ové karty HANIC a NetFlow sond FlowMon [15], fProbe [1] a Softflowd [11] a vyhodnocení jejich chování.
1. Field-programmable gate array 2. Request for Comments
2
2 Technologie NetFlow Tato kapitola popisuje princip technologie NetFlow [5]. S touto technologíí úzce souvisí pojmy jako tok, NetFow exportér a NetFlow kolektor, kterými se v tato kapitola také zabývá. Technologii NetFlow vyvinula firma Cisco na zaˇcátku 90. let 20. století. Byla navržena jako prostˇredek pro sledování sít’ového provozu na základˇe IP toku. ˚ Puvodním ˚ zámˇerem jejího využití bylo úˇctování za poskytnuté služby, ale v souˇcasnosti je tato technologie využívána zejména pro monitorování poˇcítaˇcových sítí a zajištˇení jejich bezpeˇcnosti nebo pro plánování zátˇeže poˇcítaˇcových sítí.
Obrázek 2.1: Princip technologie NetFlow
2.1 Tok v poˇcítaˇcových sítích Definic IP toku existuje mnoho. Pro úˇcely této práce budeme za tok považovat jednosmˇernou sekvenci paketu˚ se spoleˇcnými vlastnostmi, která prošla sít’ovým zaˇrízením za urˇcitý cˇ as. Spoleˇcnými vlastnostmi, které definují, že paket je souˇcástí urˇcitého toku, rozumíme tuto pˇetici údaju: ˚ zdrojová a cílová IP adresa, použitý protokol (TCP, UDP apod.) a cˇ ísla zrojového a cílového portu. Mimo tyto údaje obsahují zaznamenané informace o tocích, tzv. NetFlow data, detailní informace jako poˇcet paketu, ˚ souˇcet bajtu, ˚ cˇ asové známky, ToS (Type 3
2. T ECHNOLOGIE N ET F LOW of service), vstupní a výstupní rozhraní apod.. Tyto informace poskytují pˇrehled o vlastnostech pozorovaných toku, ˚ rozložení sít’ového provozu nebo o chování uživatelu. ˚
2.2 NetFlow Exportér NetFlow exportér, cˇ asto oznaˇcován jako NetFlow sonda, monitoruje pˇríchozí pakety na pozorovaném sít’ovém zaˇrízení a vytváˇrí statistiky toku. ˚ Tyto informace, oznaˇcované jako NetFlow data, odesílá na NetFlow kolektor prostˇrednictvím UDP paketu. ˚ V souˇcasnosti nejrozšíˇrenˇejšími verzemi NetFlow jsou verze 5 a 9. NetFlow verze 9 [9] umožnuje ˇ práci se šablonami a struturu dat odesílaných na NetFlow kolektor, je možné uživatelsky definovat. Puvodnˇ ˚ e byly NetFlow exportéry navrženy pro použití v Cisco smˇerovaˇcích, kam pˇrinášely funkce NetFlow ve formˇe pˇrídavného NetFlow modulu. Toto rˇ ešení však nabízely pouze pomˇernˇe drahé zaˇrízení a následkem této cenové nároˇcnosti se zaˇcaly objevovat softwarová rˇ ešení založená na klasickém PC vybaveného sít’ovou kartou. V následující cˇ ásti je uvedeno, a krátce pˇredstaveno, nˇekolik NetFlow sond.
2.2.1 FlowMon Sonda FlowMon [15] je vyvíjena v rámci projektu Liberouter [3]. Jedná se o pasivní sít’ové monitorovací zaˇrízení urˇcené pro sledování provozu vysokorychlostních sítí. Sonda umožnuje ˇ nashromáždˇené informace o sít’ovém provozu exportovat na NetFlow kolektor a to ve formátech NetFlow verze 5 a 9 nebo ve formátu IPFIX.
2.2.2 Softflowd Softflowd [11] je open-source softwarový NetFlow exportér vydávaný pod BSD licencí, který je schopen nasbírané informace o IP tocích odeslat na Netflow kolektor ve formátech NetFlow verze 1, 5 a 9. 4
2. T ECHNOLOGIE N ET F LOW 2.2.3 fProbe NetFlow exportér fProbe [1] je open-source softwarový nástroj dostupný pod GNU licencí, který sbírá a zpracovává informace o sít’ovém provozu a tyto informace posílá na NetFlow kolektor ve formátu NetFlow verze 5.
2.3 NetFlow kolektor NetFlow kolektor je aplikace, která pˇrijímá NetFlow data z jednoho nebo více exportéru. ˚ Pˇrijatá data zpracuje a získané informace uloží. Údaje mohou být pˇred uložením agregovány, což znaˇcnˇe zredukuje jejich objem. Pˇríkladem NetFlow kolektoru je open-source rˇ ešení, jež je založeno na sadˇe nástroju˚ NFDUMP [10].
5
3 Sít’ová karta s hadwarovou akcelerací HANIC Hardware Accelerated Network Interface Card (HANIC) je sít’ová karta s hardwarovou akcelerací vyvíjená v rámci projektu Liberouter [3]. Hlavní funkcí tohoto zaˇrízení je distribuce sít’ového provozu mezi procesorová jádra. HANIC rozdˇeluje pˇríchozí provoz mezi nˇekolik softwarových rozhraní, pˇriˇremž každé z tˇechto rozhraní muže ˚ mít pˇridˇeleno vlasní jádro procesoru pro zpracování dat. [2] Tato vlastnost navíc umožnuje ˇ zachovat mapování toku na konkrétní jádro, což je velmi duležité ˚ zejména pro aplikace, které s toky pracují jako jsou napˇr. NetFlow nástroje.
3.1 Architektura Pro implementaci hardwarové akcelerace je pro úˇcely této práce využita karta COMBO-LX155T [6, 16] z rodiny COMBOv2 [14]. Karta je složena z mateˇrské karty COMBO-LXT, vybavené pˇríslušným firmwarem, a karty COMBOI-10G2 zajišt’ující dvojici 10Gbps Ethernetových rozhraní. Samotnou akceleraci provádí FPGA1 cˇ ip Virtex5. Karta je pˇripojena do poˇcítaˇce pomocí PCI Express x8. Na Obrázku 3.1 je zachycena architektura hardwarové akcelerace. Paket je pˇrijat do vstupního bufferu, kde je mu pˇridˇelena cˇ asová známka. Dále paket postupuje do modulu HFE (Header Field Extractor), který vyjme jeho hlaviˇcku. Následnˇe modul Mask vybere z jednotlivých polí hlaviˇcky pouze ty, které jsou relevantní pro danou aplikaci. Typicky pole obashující IP adresy, protokol nebo cˇ ísla portu. ˚ Poté modul pro výpoˇcet hashe spoˇcítá na základˇe vybraných polí hlaviˇcky kontrolní souˇcet CRC. Tento hash je použit jako idetifikátor procesorového jádra, na kterém bude paket zpracován, a je firmwarem karty pˇridán ve formˇe specifické hlaviˇcky pˇred puvodní ˚ paket. Takto upravené pakety z obou vstupních bufferu˚ vstupují do sluˇcovacího modulu Binder. V posledním kroku jsou pakety urˇcené konkrétnímu jádru pˇreneseny do bufferu v operaˇcní pamˇeti. Každé jádro má svuj ˚ vlastní buffer, cˇ ímž se minimalizuje riziko kolize ve 1. Field-programmable gate array
6
ˇ 3. S Í TOVÁ KARTA S HADWAROVOU AKCELERACÍ HANIC
vyrovnávací pamˇeti procesoru. Komunikaci mezi operaˇcní pamˇetí a FPGA akcelerátorem zajišt’uje DMA modul.[22] Kromˇe zminované ˇ distribuce provozu mezi více jader tato karta také umožnuje ˇ zkracování paketu˚ [2], které je možné s výhodou využít napˇr. pro NetFlow aplikace, kde jsou zkoumány pouze hlaviˇcky paketu. ˚
Obrázek 3.1: Architektura hardwarové akcelerace
3.2 Distribuce provozu mezi jádra procesoru Jak již bylo zmínˇeno výše, pro identifikaci procesorového jádra, na kterém bude paket zpracován, je používán hash. Toto cˇ íslo muže ˚ mít velikost tˇri bity, v pˇrípadˇe distribuce mezi osm jader, nebo cˇ tyˇri bity pro pˇrípad distribuce mezi šestnáct jader. Díky tomu, že hashovací fuknce vždy vrací stejnou hodnotu pro pakety patˇrící do urˇcitého toku, je zajištˇeno mapování konkrétního toku na konkrétní jádro. Pro výpoˇcet hashe mohou být použity následující údaje z hlaviˇcky paketu. •
Verze IP protokolu
•
Zdrojová a cílová IP adresa
•
Protokol vyšších vrstev
•
Zdrojový a cílový TCP/UDP port 7
ˇ 3. S Í TOVÁ KARTA S HADWAROVOU AKCELERACÍ HANIC
3.3 Vícejádrové procesory S rostoucími nároky na výpoˇcetní výkon a souˇcasnému pˇriblížení k fyzikálním limitum ˚ dosavadního pˇrístupu ke zvyšování výkonu, došlo na pˇrelomu století ke zmˇenˇe konceptu procesoru jako jedné výkonné výpoˇcetní jednotky. Nahradila jej architektura vícejádrových procesoru, ˚ které obsahují více výpoˇcetních jednotek na jednom cˇ ipu. Aby aplikace pro analýzu sít’ového provozu mohly využít výkon vícejádrových procesoru, ˚ musí svoji práci paralelnˇe rozdˇelit na jednotlivá jádra procesoru. Toho se dá dosáhnout nˇekolika zpusoby. ˚ U výpoˇcetních úkolu, ˚ které jsou lehce rozdˇelitelné, muže ˚ každé jádro zpracovávat všechna data, ale pˇritom provést pouze cˇ ást z požadovaného úkolu. Toto zˇretˇezené zpracování je zobrazeno na obrázku 3.2. Tento pˇrístup však není vhodný pro obecné použití a ve vˇetšinˇe pˇrípadu˚ jej nelze použít.
Obrázek 3.2: Zˇretˇezené zpracování Vhodným obecným pˇrístupem je ponechání výpoˇcetního úkolu v nezmˇenˇeném stavu, pˇriˇcemž každé procesorové jádro provede požadovaný úkol pouze nad cˇ ástí dat v ideálním pˇrípadˇe tak, že dojde k rozdˇelení sít’ového provozu na nˇekolik cˇ ástí podobné velikosti. Rozdˇelení sít’ového provozu mezi procesorová jádra však nemuže ˚ být provodeno náhodnˇe, protože vˇetšina aplikací zpracovává pˇríchozí pakety na úrovni toku˚ (napˇr. TCP spojení).Všechny pakety patˇrící k urˇcitému toku proto musí být vždy pˇriˇrazeny stejnému jádru. Distribuce sít’ového provozu na úrovni toku˚ obvykle zahrnuje inspekci každého pˇríchozího paketu, dále extrakci specifických polí z hlaviˇcky paketu (napˇr. zdrojových a cílových adres nebo portu) ˚ a nakonec pˇriˇrazení paketu urˇcitému jádru. [22] Takováto distribuce paketu˚ však v souˇcasnosti není dostupná ani na úrovni operaˇcnícho systému a ani ji nepodporují bˇežnˇe dostupné levné sít’ové karty. Proto si musí aplikace rozdˇelování paketu˚ mezi 8
ˇ 3. S Í TOVÁ KARTA S HADWAROVOU AKCELERACÍ HANIC
jednotlivá jádra procesoru zajišt’ovat ve vlastní režii. Pˇríkladem je pˇrístup zobrazený na obrázku 3.3. Jedno procesorové jádro zajišt’uje distribuci paketu˚ mezi ostatní jádra, která již slouží k samotnému výpoˇctu požadovaného úkolu.
Obrázek 3.3: Paralelní distribuce paketu˚ bez akcelerace Tento pˇrístup softwarové distribuce však výkonnostnˇe nestaˇcí pro vysokorychlostní sítˇe operujících s rychlostmi 10 Gbps a výššími. Tato skuteˇcnost vedla k vytvoˇrení hardwarovˇe akcelerované distribuce paketu˚ mezi jádra, který je zobrazen na obrázku 3.4.
Obrázek 3.4: Distribuce paketu˚ za pomoci hardwarové akcelerace
9
4 Rozbor RFC dokumentu˚ o testování sít’ových zaˇrízení Tato kapitola je vˇenována rozboru RFC dokumentu˚ týkajících se testu˚ sít’ových zaˇrízení. Vytváˇrením RFC na toto téma se zabývá skupina BMWG1 vrámci IETF2 . Prvním duležitým ˚ dokumentem je RFC 1242 [21], ve kterém jsou definovány základní pojmy používané v pozdˇejších RFC. Na tento dokument navazuje RFC 1944[17], který byl posléze nahrazen RFC 2544[18], kde byly definovány základní metodiky testování. Tyto dokumenty aktualizuje RFC 6201[13] defiující pojem cˇ as zotavení a pˇríslušné testy chování zaˇrízení v pˇrípadˇe nutnosti jeho restartu. Obecný pˇrehled RFC dokumentu˚ podal Jan Vykopal ve své bakaláˇrské práci[19], a proto se budu na tomto místˇe zabývat pouze RFC, které jsou úˇcelné pro téma této práce. HANIC je specifické zaˇrízení, proto v uvedených RFC nenajdeme testy na míru tohoto nástroje. Je ovšem možné využít nˇekolika obecných testu. ˚
4.1 RFC 1242 Jak již bylo nastínˇeno výše, tento dokument definuje základní pojmy používané pˇri testech sít’ových zaˇrízení. Toto RFC reflektuje potˇrebu jednoznaˇcnˇe definovaných pojmu˚ užívaných pˇri testování sít’ových zaˇrízení a snaží se tak pˇredcházet možným desinterpretacím v této oblasti. V následující cˇ ásti jsou zmínˇeny vybrané pojmy, Konstatní zatížení Tato metrika je definována jako provoz obsahující rámce konstantní velikosti, posílané do testovaného zaˇrízení danou nemˇenící se rychlostí. Ikdyž se podobné podmínky v reálném provozu témˇerˇ nevyskytují, lze tuto hodnotu využít napˇr. k testum ˚ srovnávajícím výkon zaˇrízení od ruzných ˚ výrobcu. ˚ Ztrátovost Procento provozu, které mˇelo být testovaným zaˇrízením 1. Benchmarking Methodology Working Group 2. Internet Engineering Task Force
10
ˇ ˇ 4. R OZBOR RFC DOKUMENT U˚ O TESTOVÁNÍ SÍ TOVÝCH ZA RÍZENÍ
zpracováno, ale kvuli ˚ nedostatku zdroju˚ ke zpracování nedošlo. Tato hodnota muže ˚ být využita pˇri vyjádˇrení výkonu sít’ového zaˇrízení v pˇretíženém stavu. Propustnost Maximální míra provozu (typicky vyjádˇrená v bitech za sekundu), pˇri které testované zaˇrízení vykazuje nulovou ztrátovost. Tato hodnota je duležitá, ˚ protože významné zpoždˇení v komunikaci muže ˚ být zusobeno ˚ i ztrátou pouze jednoho paketu.
4.2 RFC 2544 Jak bylo zmínˇeno výše, tento dokument nahrazuje RFC 1944. S pojmy definovanými v RFC 1242 je možné nastínit obsah RFC 2544. Úvod dokumentu je vˇenován jeho cíli, jímž je poskytnutí nˇekolika testu˚ pro získání a prezentaci údaju˚ o výkonnosti sít’ových zaˇrízení jejich výrobci tak, aby byla usnadnˇena orientace spotˇrebitelu˚ na trhu. Tyto sjednocené testy by mˇely pˇrispˇet ke ztížení možnosti udávat tendenˇcní výsledky mˇerˇ ení tak, aby došlo k zamlˇcení urˇcitých parametru˚ zaˇrízení a výrobce tak neuvádˇel spotˇrebitele v omyl. V další cˇ ásti jsou popsány možnosti zapojení testovaných a testovacích pˇrístroju˚ v závislosti na typu použitých médií a dostupnosti testovacích zaˇrízení. Dále jsou uvedeny požadavky na postup pˇrípravy testovaného zaˇrízení. To musí být nainstalováno a nakonfigurováno podle dodané uživatelské dokumentace. Veškerá nastavení je tˇreba provést pˇred zahájením testu. Report z testu musí tuto konfiguraci obsahovat. Následující cˇ ast je vˇenována formátu a délkám testovacích rámcu. ˚ Pro úˇcely tohoto textu jsou relevantní pouze hodnoty pro Ethernet a to v délce 64, 128, 256, 512, 1024, 1280 a 1518 bajtu. ˚ Pˇred samotným popisem testu˚ jsou zmínˇeny obecné zásady jejich provádˇení. Základní postup pˇri testování je tento. Po korektním zapojení a konfiguraci testovaného zaˇrízení zapneme generátor provozu a odešleme všechny plánované testovací pakety. Po odeslání vyˇckáme dvˇe sekundy a vyhodnotíme výsledky. Pˇred dalším testem vyˇckáme minimálnˇe pˇet sekund kvuli ˚ stabilizaci testovaného zaˇrízení. Každý z dílˇcích testu˚ by mˇel trvat nejménˇe 60 sekund. Vzhledem k tomu, že nˇekteré testy vyžadují opakované provedení dílˇcích 11
ˇ ˇ 4. R OZBOR RFC DOKUMENT U˚ O TESTOVÁNÍ SÍ TOVÝCH ZA RÍZENÍ
testu, ˚ dokument umožnuje ˇ zkrácení pod hranici 60 sekund, ale za podmínky, že koneˇcné výsledky musí být ovˇerˇ eny na intervalu plné délky. Dále následují popisy jednotlivých testu, ˚ ze kterých jsem vybral dva nejvíce podstatné, test propustnosti a test ztrátovosti. Test propustnosti Tento test je urˇcen ke zjištˇení propustnosti definované v RFC 1242. Postup pˇri testu je následující. Do testovaného zaˇrízení odešleme rámce zamýšlené velikosti a poˇctu. Zjistíme kolik rámcu˚ testované zaˇrízení odeslalo zpˇet. Pokud se poˇcty rámcu˚ nerovnají, snížíme rychlost. Jako efektivní pˇrístup RFC navrhuje binární vyhledávání3 . Výsledek mˇerˇ ení by mˇel být ve formˇe grafu, kde jsou na ose x délky rámcu˚ a na ose y rychlost v rámcích za sekundu. Graf by mˇel také kromˇe samotných výsledku˚ mˇerˇ ení obsahovat také maximální teoretickou propustnost. Za nejpodstatnˇejší hodnotu je považována propustnost pˇri užití rámcu˚ nejkratší možné délky. Test Ztrátovosti Cílem tohoto testu je zjištˇení ztrátovosti podle definice z RFC 1242. Test by mˇel zaˇcít odesláním provozu rychlostí, která odpovídá maximálnímu zatížení linky. Pokud testované zaˇrízení zpracuje všechny rámce, ztrátovost je nulová. V pˇrípadˇe že je ztrátovost nenulová, vypoˇrítáme její hodnotu jako procentuální podíl poˇctu zpracovaných rámcu˚ vzhledem k odeslaným rámcum. ˚ Dalším krokem je odeslání provozu o rychlosti 90%. Takto postupnˇe snižujeme rychlost po 10% intervalech, dokud výsledkem dvou po sobˇe následujících mˇerˇ ení není nulová ztrátovost. Výsledky mˇerˇ ení by mˇely opˇet být ve formˇe grafu, kde na ose x je procentuální zatížení linky a na ose y ztrátovost vyjádˇrená v procentech. Do jednoho grafu mohou být vyneseny ztrátovosti pro ruzné ˚ delky rámcu. ˚ Ikdyž jsou testy uvažovány v laboratorních podmínkách byly skupinˇe BMWG pro tyto úˇcely pˇridˇeleny IP adresy od organizace IANA4 v rozsahu 198.18.0.05 až 198.19.255.255. Smyslem opatˇrení je minimalizovat riziko konfliktu˚ adres pˇri neúmyslném úniku testovacího provozu do prostˇredí reálné sítˇe. 3. Pulení ˚ intervalu˚ v každé iteraci 4. Internet Assigned Numbers Authority 5. V puvodním ˚ RFC 2544 je uvedena chybná adresa 192.18.0.0 [12]
12
5 Hadwarové testovací pˇrístroje Pod pojmem hardwarové testovací pˇrístroje rozumíme zaˇrízení, pomocí kterých je možné testovat funkˇcnost sít’ových prvku. ˚ Jedná se o nástroje, které jsou shcopny generovat nadefinovaný sít’ový provoz obsahující požadované typy paketu˚ vˇcetnˇe jejich obsahu. Tento provoz je možné poslat na testované zaˇrízení a otestovat tak jeho chování. Pˇrípadnˇe umožnují ˇ provoz od testovaného zaˇrízení zachytit, analyzovat a zjistit, zda odesílá to, co je od nˇej oˇcekáváno. Testovací pˇrístroje se skládají z chassi, do nˇehož jsou zapojeny samotné testovací karty, a ovládacího softwaru. Tyto karty se od sebe mohou odlišovat poˇctem portu, ˚ použitým rozhraním (nejˇcastˇeji optický nebo metalický kabel), pomocí kterého jsou propojeny s testovaným zaˇrízením, nebo rychlostí, pˇri níž jsou shopny pracovat (napˇr. 1 Gbps nebo 10 Gbps). Ovládací software je bud’ pˇrítomen na samotném testovacím zaˇrízení nebo se nachází na jiném poˇcítaˇci. Pak je nutné ovládat testovací pˇrístroj za pomoci vzdáleného pˇrístupu. Tento software je nejˇcastˇeji vytvoˇren pro Windows a má grafické uživatelské prostˇredí, kde je možné vše pohodlnˇe nastavit. Alternativou je potom skriptovací rozhraní v jazyce Tcl umožnující ˇ automatizované nastavování. Projekt Liberouter disponuje nˇekolika takovými zaˇrízeními. Podrobnˇe se jimi zabýval Kamil Veselý ve své bakaláˇrské práci [20], já je na tomto místˇe jen krátce pˇredstavím.
5.1 TC2000 Prvním hardwarovým testovacím pˇrístrojem, kterému se budu vˇenovat je zaˇrízení nesoucí název Spirent Test Center 2000, zkrácenˇe TC2000, a pochází od britské telekomunikaˇcní spoleˇcnosti Spirent Communications [4]. Chassi vlastnˇené projektem Liberouter je vybaveno dvˇema kartami. První disponuje dvojicí portu˚ schopných pracovat až rychlostí 10 Gbps a druhou, disponující dvanácti porty o rychlosti 1 Gbps. Zaˇrízení je možné ovládat pˇres grafické uživatelské prostˇredí nebo pomocí Tcl API. Generátor umožnuje ˇ nastavování velkého množství hlaviˇcek ruzných ˚ protokolu˚ a samotného obsahu paketu˚ bud’ jako rˇ etˇezec zanku˚ nebo v hexadecimální podobˇe. Dále je možné nastavit 13
ˇ 5. H ADWAROVÉ TESTOVACÍ P RÍSTROJE
délky jednotlivých paketu˚ a také délky mezipaketových mezer. Pro úˇcely testování v rámci této práce, sloužil jako generátor sít’ového provozu právˇe tento testovací pˇrístroj.
5.2 AX4000 Druhé zaˇrízení je také dílem spoleˇcnosti Spirent Communications a je pojmenováno AX4000. Tento nástroj je o nˇekolik let starší. Chassi obsahuje opˇet dvojici karet. První z nich je vybavena dvˇema porty pracujících s rychlostí až 10 Gbps a druhá obsahuje šest portu˚ umožnujících ˇ rychlost 1 Gbps. Zaˇrízení lze také ovládat pˇres grafické uživatelské prostˇredí nebo pomocí Tcl API.
5.3 Analýza bˇežného sít’ového provozu Tato cˇ ást je vˇenována analýze bˇežného sít’ového provozu. Souslovím "bˇežný provoz" je na tomto místˇe myšlen provoz bez masivních útoku˚ na analyzovanou sít’, tedy sít’ový provoz, který je z velké vˇetšiny tvoˇren relevantními požadavky aplikací a uživatelu. ˚ Abychom vubec ˚ s analýzou mohli zaˇcít, je nutné vyjít z nˇejakého záznamu takového sít’ového provozu. Veˇrejnˇe dostupné záznamy mˇerˇ ení sít’ového provozu dává k dispozici napˇr. projekt MAWI (Measurement and Analysis on the WIDE Internet) [8], který se zamˇerˇ uje na dlouhodobé mˇerˇ ení provozu v rozlehlých sítích ve východní Asii. K analýze jsem si vybral záznam mˇerˇ ení z 29.11.2012[7]. Pro úˇcely této práce budeme tento záznam považovat za bˇežný provoz a budeme z nˇej pozdˇeji vycházet pˇri simulování bˇežného provozu pomocí hardwarového testovacího pˇrístroje. Nejduležitˇ ˚ ejšími paramatery pro nás budou následující údaje: •
Poˇcet toku˚ = 1940345
•
Poˇcet paketu˚ = 33434620
•
Prumˇ ˚ erný poˇcet paketu˚ na tok = 17,23
•
Distribuce délek paketu˚ v provozu (na obrázku 5.1)
14
ˇ 5. H ADWAROVÉ TESTOVACÍ P RÍSTROJE
Obrázek 5.1: Distribuce délek paketu˚ v sít’ovém provozu
5.4 Útok DDoS Útok DDoS (Distributed Denial of Service) má za cíl zahltit sít’ový provoz tak, že nakonec dojde k znepˇrístupnˇení služby, proti které je útok veden, z duvodu ˚ zahlcení výpoˇcetních prostˇredku˚ sít’ových prvku˚ a následnému zahazování paketu. ˚ V této práci se zamˇerˇ uji na porovnání odolnosti pasivních NetFlow exportéru˚ vuˇ ˚ ci DDoS útoku na sít’ kterou monitorují. Ideální stav by byl samozˇrejmˇe takový, že NetFlow exportér bude zvládat monitorovat a poskytovat údaje i bˇehem útoku a pˇrinášet tak o nˇem cenné informace. Útok bude simulován hardwarovým testovacím pˇrístrojem, který bude generovat velké množství toku. ˚ Každý tok bude sestávat pouze z jednoho krátkého paketu o délce 64 B. 15
ˇ 5. H ADWAROVÉ TESTOVACÍ P RÍSTROJE
5.5 Test propustnosti karty HANIC Následující cˇ ást je vˇenována výsledkum ˚ testu propustnosti sít’ové karty s harwarovou akcelerací HANIC. Test propustnosti byl proveden na základˇe RFC 2544 [18]. V prubˇ ˚ ehu testu byly použity následující délky paketu: ˚ 64, 128, 207, 256, 313, 512, 726, 1024, 1280 a 1518 B. Konfigurace hostitelského poˇcítaˇce je uvedena v pˇríloze A. Jako generátor provozu byl použit hardwarový testovací pˇrístroj Spirent TC2000, který generoval provoz o šíˇrce pásma 10 Gbps. Každá z uvedených délek paketu˚ byla generována po dobu jedné minuty. Jak je patrné z obrázku 5.2 sít’ová karta HANIC díky hardwarové akceleraci bezproblému˚ zvládá zpracovat provoz pˇri zátˇeži 10 Gbps a to i v pˇrípadˇe velkého poˇctu krátkých paketu. ˚
Obrázek 5.2: Test propustnosti HANICu pˇri zátˇeži 10 Gbps
16
6 Závˇer V rámci sepsání této práce jsem nastudoval technologii NetFlow a seznámil se s oblastí pasivních monitorovacích NetFlow exportéru, ˚ které jsem zmínil v první cˇ ásti práce. Dále jsem se zabýval distribucí sít’ového provozu mezi více jader procesoru a nastudoval architekturu a funkcionalitu sít’ové karty s hardwarovou akcelerací HANIC. Také jsem prostudoval základní RFC dokumenty týkající se testování sít’ových zaˇrízení a provedl jejcih rozbor. Dále jsem se zabýval hardwarovými testovacími zaˇrízeními a krátce je popsal. Na rozhraní teoretické a praktické cˇ ásti práce jsem se vˇenoval analýze bˇežného sít’ového provozu a útokum, ˚ které jej mají za cíl narušit nebo úplnˇe znemožnit. V praktické cˇ ásti jsem otestoval propustnost sít’ové karty s hardwarovou akcelerací HANIC.
17
Literatura [1] fProbe - NetFlow probe [online, cit. 2012-11-29]. URL: http: //fprobe.sourceforge.net/. [2] HANIC handbook [online, cit. 2012-11-15]. URL: http:// canti.liberouter.org/hanic/handbook.html. [3] Internetové stránky projektu Liberouter [online, cit. 2012-11-15]. URL: http://www.liberouter.org. [4] Internetové stránky spoleˇcnosti Spirent Communications [online, cit. 2012-11-29]. URL: http://www.spirent.com. [5] Introduction to Cisco IOS NetFlow - A Technical Overview [online, cit. 2012-11-29]. URL: http://www.cisco.com/ en/US/prod/collateral/iosswrel/ps6537/ps6555/ ps6601/prod_white_paper0900aecd80406232.html. [6] Liberouter.org - Cards [online, cit. 2012-11-15]. URL: https: //www.liberouter.org/?page_id=1156. [7] MAWI Working Group Traffic Archive - traffic trace info[online, cit. 2012-11-29]. URL: http://mawi.wide.ad.jp/mawi/ samplepoint-F/2012/201211291400.html. [8] MAWI Working Group Traffic Archive [online, cit. 2012-11-29]. URL: http://mawi.wide.ad.jp/mawi/. [9] NetFlow Version 9 Flow-Record Format [online, cit. 2012-11-29]. URL: http://www.cisco.com/en/US/ technologies/tk648/tk362/technologies_white_ paper09186a00800a3db9_ps6601_Products_White_ Paper.html. [10] NFDUMP - NetFlow processing tools [online, cit. 2012-11-29]. URL: http://nfdump.sourceforge.net/. [11] Softflowd - fast software NetFlow probe [online, cit. 2012-11-29]. URL: http://www.mindrot.org/projects/softflowd/. 18
ˇ 6. Z ÁV ER
[12] Bradner S.; Dubray K.; McQuaid J.; Morton A. RFC 6815: Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful, November 2012. [13] Asati R.; Pignataro C.; Calabria F.; Olvera C. RFC 6201: Device Reset Characterization, March 2011. [14] Novotný J.; Žádník M. COMBOv2 – Hardware Accelerators for High-Speed Networking. XILINX Academic Forum, San Jose, USA, 2008. Dostupné online, URL: http://wp.liberouter.org/wp-content/uploads/ 2012/05/COMBOV2-2008-02-10-Academic_Forum.pdf. [15] Žádník M.; Polˇcák L.; Lengál O.; Elich M.; Kramoliš P. FlowMon for Network Monitoring. Technical Report 20/2010, CESNET, Praha, 2010. ˇ [16] Celeda P.; Krejˇcí R.; Barienˇcík J.; Elich M.; Kalíˇcek V. HAMOC – Hardware-Accelerated Monitoring Center. Technical Report 9/2010, CESNET, Praha, 2010. [17] Bradner S.; McQuaid J. RFC 1944: Benchmarking Terminology for Network Interconnection Devices, May 1996. Obsoleted by RFC 2544. [18] Bradner S.; McQuaid J. RFC 2544: Benchmarking Terminology for Network Interconnection Devices, March 1999. [19] Vykopal Jan. Metody testování výkonu prvku˚ sít’ové infrastruktury. Bakaláˇrská práce, Masarykova Univerzita, 2006. [20] Veselý Kamil. Skriptovací rozhraní pro hardwarové testery sít’ového provozu. Bakaláˇrská práce, Masarykova Univerzita, 2008. [21] Bradner S. RFC 1242: Benchmarking Terminology for Network Interconnection Devices, July 1991. [22] Puš V.; Dedek T.; Martínek T. Hardware-accelerated Distribution of Network Traffic among Processor Cores. Technical Report 15/2010, CESNET, Praha, 2010.
19
A Popis zaˇrízení použitých pˇri testování Generátor Zaˇrízení, které sloužilo jako generátor TCP/IP provozu. Testovací zaˇrízení: Spirent Test Center 2000 Testovací software: Tcl library TC2000 Hostitelský poˇcítaˇc Poˇcítaˇc, na kterém byly nainstalovány a postupnˇe otestovány všechny NetFlow sondy. Název stroje: mossel.liberouter.org Poˇcet prosecosru: ˚ 1 Poˇcet jader: 4 Procesor: Intel(R) Xeon(TM) E5420 2.50 GHz Opraˇcní systém: Linux 2.6.32 Základní deska: Supermicro X7DB8 Kapacita pamˇeti: 2 GB COMBO karta: ComboLX155T / ComboI-10G2 S/N ComboLX155T: 8100325 S/N ComboI-10G2: 8100379
20
