4 Programovatelný hardware

Aktivita Programovatelný hardware se zabývá vývojem prototypů specializovaných síťových zařízení, která využívají programovatelná hradlová pole (FPGA, Field-Programmable Gate Array) k akceleraci některých svých funkcí. V této stručné charakteristice se skrývá mnoho různých činností, které pokrývají prakticky celou vertikální škálu potřebných součástí, počínaje návrhem hardwarových karet přes vývoj firmwaru pro tyto karty a ovladače pro operační systém Linux až po uživatelské programy pro konfiguraci těchto zařízení a vlastní práci s nimi.

V posledních letech jsme se zaměřili především na vývoj sond určených k monitorování datového provozu ve vysokorychlostních sítích:

Sonda FlowMon agreguje provoz do záznamů o IP tocích, které jsou exportovány ve formátu NetFlow verze 5 či 9 a IPFIX.
Traffic Scanner je hardwarovým akcelerátorem známého programu Snort, jenž je určen k vyhledávání signatur virů, červů a jiného škodlivého softwaru.

Významným přírůstkem do rodiny karet COMBO je karta rozhraní 2×10GE (COMBO-2XFP2), jejíž první dva prototypy byly vyrobeny v září 2007. Na tuto kartu jsme již naportovali aplikaci FlowMon, takže jsme schopni monitorovat toky i na desetigigabitových okruzích. Začátkem roku 2008 hodláme sondu nasadit na okruhy 10GE propojující CESNET s NIX.CZ, kde dosud měření toků nebylo možné.

Dokončili jsme také základní návrh rodiny karet COMBO verze 2. Nové karty jsou navrženy pro maximální propustnost 40-100 Gb/s (podle toho, jaký bude další standard Ethernetu) a umožní nám tak i v několika dalších letech vyvíjet aplikace pro špičkové vysokorychlostní sítě.

Pro vývojáře firmwaru bylo hlavním úkolem roku 2007 dokončení platformy NetCOPE, která v budoucnu výrazně usnadní vývoj firmwaru síťových aplikací a zajistí i jistou nezávislost těchto aplikací na použitém hardwaru. Při vývoji a zejména ladění tohoto dosti složitého a vzájemně provázaného systému jsme narazili na řadu komplikací, které způsobily určité zpoždění. V říjnu 2007 však byla platforma NetCOPE dokončena a portována nejen na karty COMBO, ale též na experimentální kartu ML555 firmy Xilinx. Dvě ze stávajících aplikací - NIC (standardní víceportová síťová karta) a NIFIC (totéž s hardwarovou filtrací) - jsme již na NetCOPE převedli, pro první měsíce roku 2008 tak zbývá jako hlavní úkol převedení monitorovacích sond FlowMon a Traffic Scanner.

Sonda FlowMon, která je těžištěm naší práce v rámci aktivity JRA2 (Bezpečnost) projektu GN2, byla v roce 2007 v několika směrech významně vylepšena:

Využitím DRAM se zvětšila kapacita paměti pro záznam dat o tocích až na 512 tisíc simultánních toků.
Implementovali jsme podporu pro MPLS, což umožňuje mj. monitorování páteřních okruhů sítě CESNET2.
Software i firmware pro FlowMon je k dispozici ve formě snadno instalovatelného balíčku.
Sondu lze konfigurovat vzdáleně pomocí konfiguračního systému založeného na protokolu NETCONF.
Vytvořili jsme rozsáhlou uživatelskou dokumentaci, která pokrývá celý postup práce se sondou od instalace a konfigurace přes ovládání až po napojení na kolektory.

Další vývoj sondy FlowMon bude zaměřen především na implementaci proměnného obsahu záznamů o tocích. Tato nová verze sondy, které pracovně říkáme flexibilní FlowMon, je již navržena (nad platformou NetCOPE) a v roce 2008 bude implementována.

Praktické testy sondy Traffic Scanner ukázaly, že hardwarová akcelerace může skutečně přinést výrazné zvýšení propustnosti systému IDS, zároveň ale také poukázaly na určitou křehkost zvoleného řešení, které je závislé na správné syntéze designu VHDL pro zadanou množinu pravidel programu Snort. Hlavním úkolem pro nejbližší období je zvýšení robustnosti celého postupu a vytvoření stabilního balíku této aplikace. Další uvažovaná a jistě potřebná vylepšení, zejména schopnost vyhledávat fragmentované řetězce (v několika po sobě jdoucích datagramech), jsou však natolik složité, že jsme se rozhodli je prozatím odložit a ponechat sondu Traffic Scanner v podstatě ve stávající podobě, pouze s přidáním podpory pro IPv6.

V následujících oddílech podrobněji popíšeme výše uvedené výsledky.

Významnou událostí roku 2007 bylo úspěšné završení procesu přenosu technologií vyvinutých aktivitou Programovatelný hardware. I když zájemců bylo v různých fázích tohoto procesu několik, smlouvu nakonec podepsala jediná společnost - INVEA-TECH, a. s. - která převzala hardware, firmware a software ve stavu k počátku května 2007. Tato firma by měla v roce 2008 realizovat dodávku sond FlowMon sedmi partnerům projektu GN2. Cesta k tomuto úspěšnému přenosu know-how do praxe byla ovšem značné trnitá. Ukazuje se, že přes obecně proklamovanou podporu je realizace výzkumu financovaného z veřejných prostředků stále velmi komplikovaná a naráží na řadu legislativních i ekonomických bariér.

4.1 Rodina karet COMBO

Vývoj karet rodiny COMBO pokračoval návrhem a výrobou karty rozhraní COMBO-2XFP2 (viz obrázek) se dvěma desetigigabitovými a jedním gigabitovým portem. V současné době jsou vyrobeny dva plně funkční prototypy. V rámci vývoje sondy FlowMon jsme převedli VHDL design ze starší 10GE karty COMBO-2XFP a získali tak ucelenou řadu FlowMon sond od 10 Mb až po 10 Gb. Portování platformy NetCOPE na COMBO-2XFP2 probíhá v současné době.

Obrázek 4.1: Karta rozhraní COMBO-2XFP2 se dvěma porty 10GE a jedním GE

Kartou COMBO-2XFP2 jsme završili vývoj rodiny karet COMBO. Vzhledem k současnému trendu v oblasti programovatelného hardware jsme se rozhodli pro návrh nové rodiny karet COMBOV2, která bude zacílena na dosažení vyššího výkonu, abychom zhruba za rok mohli zpracovávat datový tok v řádu 40-100 Gb/s. To si vyžádalo změnu architektury, takže karty rodiny COMBOV2 nebudou kompatibilní s kartami COMBO na úrovni vzájemného propojení. Hlavními rysy nové generace karet COMBOV2 jsou:

použití obvodů rodiny VIRTEX 5 se zabudovaným Express PCI endpointem,
osazení dvěma konektory pro rychlý sériový přenos mezi mateřskou kartou a kartou rozhraní,
mateřská karta bude obsahovat několik konektorů pro připojení pomalých periferií (karta časových značek, 1Gb portů, atd.),
použití DRAM v SODIMM patici s možností použít i paměti RLDRAM,
odklon od používání pamětí TCAM.

V roce 2007 jsme rozpracovali architekturu karet rodiny COMBOV2 a předali materiály pro návrh plošných spojů první mateřské karty COMBO-LXT. Návrh plošných spojů nyní prochází kontrolou a předpokládáme předání do výroby v lednu 2008. Dále jsme připravili návrh podkladů pro dceřiné karty rozhraní 4×1 Gb COMBOI-1G4 a 2×10 Gb COMBOI-10G2.

4.2 Firmwarová vrstva NetCOPE

Základním cílem projektu NetCOPE je vytvoření konfigurovatelné platformy pro usnadnění a urychlení vývoje síťových aplikací akcelerovaných pomocí FPGA čipů. Vlastní urychlení je založeno na využití abstraktní vrstvy nad FPGA, která odstíní nízkoúrovňové hardwarově závislé vlastnosti zvolené karty s FPGA čipem a poskytne snadný přístup k jejím zdrojům (síťové rozhraní, připojení k hostitelskému počítači, kontroléry pamětí aj.).

Tato vrstva umožní návrháři aplikace koncentrovat se primárně na vývoj vlastní aplikace a ušetřit si tak značné úsilí, které by jinak bylo nutné věnovat implementaci jednotek pro obsluhu periferií karty. Další výhodou této platformy je snadná integrace uživatelské aplikace na různé karty od různých výrobců. Karty se mohou lišit v počtu a rychlosti síťových rozhraní, typem systémové sběrnice, ke které je karta připojena, nebo dalšími periferiemi ovládanými z FPGA. Vlastní aplikace se pro dvě různé karty nemusí vůbec měnit, změní se pouze použitá vrstva NetCOPE.

Spojení se softwarovou částí síťové aplikace zprostředkují připravené ovladače a softwarové nástroje pro obsluhu karty. Rozhraní dodržuje definovanou strukturu a síťové aplikace se tak nemusí měnit ani při použití jiných hardwarových karet a jiných aplikačních jader. V hardwarové části platformy NetCOPE je integrován flexibilní propojovací systém na čipu, který umožňuje rychlé DMA přenosy z karty do hostitelského PC. Je podporováno snadné zadávání transakcí jak mezi jednotlivými komponentami v FPGA, tak mezi jednotkou a softwarovou aplikací.

Platforma NetCOPE tak může být využita například pro tyto aplikace:

síťová karta s hardwarovou filtrací,
aktivní/pasivní síťový monitoring,
IPv4/IPv6 směrovač,
kryptografie,
zakódování/dekódování videa,
generování paketů.

4.2.1 Základní struktura platformy NetCOPE

Architektura platformy NetCOPE vychází z rozdělení funkcí do čtyř vrstev (viz též obrázek):

Hardwarová karta: nejnižší vrstvou aplikace je vlastní karta s integrovaným čipem FPGA, který ovládá další čipy na kartě nebo rozhraní připojená přímo k FPGA.
Aplikační jádro: tato vrstva je implementována uživatelem platformy a představuje akcelerovanou část konkrétní síťové aplikace. Rozhraní mezi jádrem a NetCOPE je dostatečně abstraktní, aby nebylo závislé na použité technologii a nízkoúrovňových detailech dané hardwarové karty. Příkladem aplikačního jádra může být filtrace vstupních paketů na základě hlaviček paketu, která přepošle vyšším vrstvám jen ty pakety, které jsou pro softwarovou aplikaci důležité.
Ovladač a rozhraní směrem k softwarovým aplikacím: softwarová část uživatelské aplikace může s akcelerovaným aplikačním jádrem komunikovat prostřednictvím standardních síťových rozhraní v jádru operačního systému nebo pomocí aplikačně specifického rozhraní. Nízkoúrovňovou obsluhu karty na základě podnětů od softwarové aplikace zařizuje právě tato vrstva.
Softwarová část aplikace: v této vrstvě uživatel implementuje softwarovou část aplikace, která komunikuje s aplikačním jádrem. Díky spolupráci obou částí a možnosti umístění výpočetně náročných částí aplikace do akcelerované části je možné připravit výrazně výkonnější řešení, než při použití klasických síťových karet a samostatné softwarové aplikace.

Obrázek 4.2: Vrstvy aplikace založené na platformě NetCOPE

4.2.2 Hardwarová architektura

K hlavním firmwarovým blokům, které využívá aplikace NetCOPE, patří síťové rozhraní, blok pro komunikaci s hostitelským PC (propojovací systém na čipu) a softwarové buffery pro snadné odesílání a přijímání dat ze softwaru. Jejich rozmístění vzhledem k jádru platformy je znázorněno na obrázku.

Obrázek 4.3: Architektura platformy bez podrobného rozkreslení propojovacího systému (ICS)

Síťové rozhraní

Komunikace se síťovým rozhraním karty se děje pomocí síťových bloků, které podporují jak gigabitové, tak i desetigigabitové síťové rozhraní. Pakety jsou do aplikace přenášeny pomocí sběrnice protokolem FrameLink, který je modifikací zavedeného protokolu LocalLink firmy Xilinx. Připojená sběrnice má takovou propustnost, aby byla schopna přenést všechny pakety při plném zatížení síťového rozhraní, včetně případných uživatelských metadat připojených k paketu.

Bloky vstupního síťového rozhraní implementují příjem a vysílání paketů z daného síťového rozhraní na úrovni linkové vrstvy podle standardu IEEE 802.3. Parametry každého z bloků - např. maximální a minimální přípustné délky paketů, zastavení příjmu paketů nebo rychlost síťového rozhraní - je možné samostatně nastavit i za běhu aplikace. Všechny tyto parametry lze nastavovat pomocí připravených softwarových nástrojů.

K příchozím paketům je možné připojit libovolná uživatelská metadata. Nejjednoduššími příklady uživatelských metadat mohou být číslo síťového rozhraní, ze kterého byl paket přijat, délka paketu nebo přesná časová značka.

Komunikace s hostitelským počítačem

Blok komunikace s hostitelským počítačem připojený na systémovou sběrnici PCI nebo PCI Express zajišťuje příjem a vysílání datových transakcí mezi aplikačním jádrem a softwarem na hostitelském PC. V bloku je integrován flexibilní propojovací systém pro FPGA (ICS - Interconnection system) a softwarové buffery s rychlým spojením do softwaru. Uživateli jsou poskytnuty způsoby komunikace se softwarem s různými vlastnostmi: vysokorychlostní interní sběrnice a pomalejší lokální sběrnice pro spojení volitelného počtu komponent se softwarem a rozhraní FrameLink k softwarovým bufferům. Buffery zprostředkují rychlé a snadno realizovatelné vysílání a příjem dat ze softwaru.

Propojovací systém je jedním z nejdůležitějších bloků NetCOPE. Je možné ho chápat jako abstraktní rozhraní pro připojení aplikačního jádra ke sběrnici PCI, PCI-X nebo PCI Express. Uživatel se tak nemusí zabývat technickými rozdíly jednotlivých sběrnic a využívá jednotného rozhraní. Propojovací systém umožňuje jak datové přenosy mezi komponentami v FPGA a hostitelskou pamětí RAM, tak i interně přímo mezi jednotlivými komponentami.

Struktura interní sběrnice dodržuje stromové uspořádání, kde kořenem je blok komunikace s hostitelským počítačem a listy jsou připojené komponenty v FPGA. Uzly slouží pouze pro propojení kořene a jednotlivých listů stromu. Komunikace mezi uzly je založena na zasílání paketů, podobně jako tomu je ve velmi rozšířené systémové sběrnici PCI Express. Komunikační protokol podporuje jednoduché i blokové čtecí a zápisové transakce.

Kvůli ušetření zdrojů na FPGA je možné komponenty, u kterých není vyžadováno vysokorychlostní spojení, připojit k lokální sběrnici. K této sběrnici je výhodné připojovat zejména konfigurační nebo ladicí rozhraní komponent.

Softwarové buffery

Softwarové buffery poskytují snadno přístupné a rychlé spojení ze/do softwaru. Ke kontroléru sběrnice jsou připojeny pomocí rychlé interní sběrnice pro dosažení co nejvyšší propustnosti do softwaru. Skládají se ze dvou částí:

RX: část pro příjem paketů do softwaru,
TX: část pro odesílání paketů ze softwaru.

Buffery jsou s uživatelskou aplikací spojeny rozhraním FrameLink. Odeslání paketu do softwaru je jednoduché - stačí pouze odeslat paket rozhraním FrameLink do části RX. Podobně snadné je odeslání paketu ze softwaru do FPGA, jehož výsledkem je vytvoření nového datového paketu na rozhraní FrameLink v části TX. Buffery jsou volně nastavitelné, je možno nezávisle na sobě nastavit počet RX a TX částí nebo velikost jejich interních pamětí.

Rozhraní aplikačního jádra

Rozhraní platformy NetCOPE k uživatelskému jádru je dostatečně abstraktní, aby bylo použitelné pro široké spektrum hardwarových karet a aplikací. Pro přenos dat je využit protokol FrameLink. Jeho propustnost (objem přenesených dat za jednotku času) lze navíc snadno přizpůsobit požadavkům datového spoje.

V rozhraní jsou povinně vyvedeny následující signály (další zavedené signály se mohou lišit v závislosti na hardwarové kartě):

Pro každý síťový port karty je k dispozici jedno rozhraní FrameLink pro vstupní síťové buffery.
Pro každý síťový port karty je dále k dispozici rozhraní pro uživatelské generování metadat k příchozím paketům (např. přesné časové značky).
FrameLink rozhraní k softwarovým bufferům (lze zvolit počet RX a TX částí, tedy i počet FrameLink rozhraní).
Přípojný uzel lokální sběrnice.
Přípojný uzel Interní sběrnice.

4.2.3 Řízení DMA přenosů

Síťová aplikace je složena nejen z akceleračního jádra umístěného v hardware, ale také z části pracující na úrovni programového vybavení. Komunikační kanál realizující efektivní přenosy dat mezi oběma vrstvami je pak jednou z klíčových součástí platformy. Pro síťové aplikace je charakteristický přenos dat ve formě paketů. Akcelerační jádro shromažďuje pakety pro softwarovou aplikaci v softwarových bufferech. Na druhé straně kanálu zpracovává aplikace pakety přímo v paměti RAM. O efektivní přenosy dat mezi interními buffery akcelerační karty a pamětí RAM se stará řadič DMA přenosu, který je součástí akcelerační karty.

Přenášené pakety mohou mít obecně různou velikost. Aby byla paměť RAM využita efektivně, pracuje jádro operačního systému s pakety tak, že je skládá z menších bloků (segmentů) provázaných do lineárního seznamu. Přenos jednoho paketu pak obvykle znamená přenos několika menších bloků z nebo do různých částí paměti RAM. Způsob provázání jednotlivých části paketu do lineárního seznamu se provádí pomocí datových struktur, které se nazývají deskriptory (viz obrázek).

Obrázek 4.4: Segmentace paketu v paměti RAM

Různé síťové aplikace mohou mít odlišné požadavky na formát přenášených dat, strukturu deskriptoru nebo řídicích informací v nich uložených. Z důvodu flexibility je DMA řadič realizován pomocí procesoru PowerPC vestavěného přímo uvnitř čipů FPGA. Procesor, resp. DMA řadič je řízen programem uloženým v instrukční paměti (IC), který lze snadno modifikovat. Datová paměť (DC) pak slouží pro uložení samotných deskriptorů paketů nebo lokálních dat procesoru.

Architektura DMA řadiče

DMA řadič je úzce propojen se softwarovými buffery, aby si mohl rychle vyměňovat informace o nově příchozích paketech nebo naopak zadávat požadavky na odeslání paketu z bufferu směrem k aplikačnímu jádru nebo uvolňovat již odeslané pakety. Samotné DMA přenosy řadič inicializuje přes komponentu Endpoint, která dokáže vyčíst data z interního prostoru bufferů a odeslat je přes interní sběrnici do paměti RAM. Podobně i opačným směrem je schopna vyslat požadavek na čtení dat z paměti RAM a výsledná data uložit do interního prostoru bufferů.

Implementace řadiče dosahuje výkonnosti až 1300 DMA přenosů za sekundu, což odpovídá propustnosti zhruba 700 Mb/s při nejkratších paketech pro technologii Ethernet. S využitím schopnosti agregace paketů do větších bloků (viz oddíl) lze dosáhnout teoretické propustnosti až 7,3 Gb/s. Avšak vzhledem k omezené propustnosti sběrnice PCI a způsobu propojení FPGA čipu na desce plošného spoje dosahuje reálná propustnost systému hodnot okolo 2,8 Gb/s. V současné době se připravuje návrh nové verze DMA řadiče, který by měl dosahovat teoretické propustnosti v řádu stovek Gb/s a vysoce přesahovat výkon současné implementace.

4.2.4 Softwarové rozhraní

Pro tu část aplikace, která je implementována v softwaru, nabízí platforma NetCOPE dva základní modely komunikace (viz obrázek):

Standardní síťové rozhraní - akcelerační karta se v systému chová jako běžná síťová karta. Příchozí pakety jsou z ovladače předány jádru operačního systému a putují sloupcem protokolů TCP/IP až k cílové aplikaci. Alternativně mohou aplikace využít knihovnu PCAP, která je součástí operačního systému, a přistupovat k datům paketů v tzv. "surové (raw)" formě mimo sloupec TCP/IP (takový postup je typický pro monitorovací aplikace typu Tcpdump, Wireshark, Snort apod.). Výhodou tohoto rozhraní je jeho univerzálnost a možnost připojení libovolné již vytvořené aplikace. Nevýhodou je pak nízká propustnost způsobená průchodem paketu jádrem operačního systému, které vyžaduje rozložení paketů do segmentů bez možnosti agregace.
Aplikačně specifické rozhraní - akcelerační karta nabízí aplikaci obecné rozhraní pro přenos datových bloků. Komunikace probíhá přímo mezi ovladačem a aplikací mimo sloupec TCP/IP. Formát uložených dat není omezen jádrem operačního systému a může tak obsahovat např. agregované pakety doplněné o kontrolní informace, časové značky atd. Kromě paketových dat lze přenášet i libovolná další data, například záznamy o IP tocích, informace extrahované z hlaviček paketů apod. Pro účely monitorovacích aplikací vytvořených nad rozhraním PCAP je zde možnost modifikovat aktuální implementaci PCAP knihovny tak, aby komunikovala přímo s ovladačem mimo jádro operačního systému (přístup používaný i v jiných podobných zařízeních, např. monitorovacích kartách firem Endane a Napatech). Hlavní výhodou tohoto modelu je jeho propustnost, jež je dána možností agregovat menší pakety do větších bloků a snížit tak režii související s DMA přenosy.

Obrázek 4.5: Modely komunikace se software (větší obrázek)

4.2.5 Aplikačně specifické rozhraní

V rámci aplikačně specifického rozhraní (tzv. szedata) je základní jednotkou blok dat. Každý blok s sebou nese informace o svém umístění v paměti hostitelského stroje, ukazatele na seznamy, ve kterých je právě vložen a referenční počet. Bloky jsou vkládány a přesouvány mezi obousměrně zřetězenými seznamy umožňujícími jednoduché vložení a odstranění prvku. Takových seznamů je několik typů:

seznam s volnými bloky - čeká na příchozí data ze sítě,
seznam s použitými bloky - je naplněn daty, čekajícími na zpracování v aplikaci,
seznam s uzamčenými bloky - obsahuje data, která právě zpracovávají aplikace.

Každá aplikace má dva oddělené seznamy: seznam bloků čekajících na zpracování a seznam uzamčených bloků, které se právě zpracovávají.

V průběhu inicializace se vytvoří soubor pro přístup k akcelerační kartě v adresáři /dev. Dále se alokuje paměť pro určitý počet bloků (řádově tisíce až desetitisíce, podle rychlosti vstupního rozhraní). Ukazatele (deskriptory) na takto vytvořené bloky jsou pak postupně přenášeny do akcelerační karty.

Aplikaci se po otevření zařízení (souboru v adresáři /dev) přidělí datová struktura obsahující informace o tom, ke kterému z hardwarových rozhraní se registrovala, po kolika příchozích paketech má být probuzena (dále poll-hranice), odkazy na zmíněné dva seznamy aj. Hodnoty v této datové struktuře lze nastavit nebo změnit pomocí systémového volání ioctl. Jiným voláním ioctl lze zjistit velikost alokované paměti (v blocích) a celou tuto oblast přemapovat pomocí volání mmap do uživatelského prostoru aplikace.

Po provedení předchozích kroků je aplikace připravena pro příjem dat a ovladač povolí přenosy z akcelerační karty. Operace pro příjem paketu se realizují v tomto sledu:

Volání funkce get_block - dojde k přesunu bloku ze seznamu volných do používaných a spuštění DMA přenosu. Není-li žádný z volných bloků k dispozici, uvolní se nejdéle čekající blok ze seznamu připravených (nejstarší ještě nezpracovaná data).
Naplnění bloků daty prostřednictvím DMA přenosů.
Volání funkce put_block - zařazení bloku do seznamů těch aplikací, které o tato data požádaly, a zvýšení počtu připravených bloků o jedničku.

Obrázek 4.6: Model komunikace uživatelské aplikace s FPGA pomocí modulu szedata

Výše popsaný postup lze urychlit provedením operace get_block (bod 1) již v inicializační části. Hardware ovladač probudí už s platnými daty a není tak potřeba čekat na dokončení DMA přenosu (bod 2). Bod 3 (přesun bloků a zvýšení počítadla) zůstává nezměněn.

Dojde-li k překročení poll-hranice počtem připravených bloků, aplikace se probouzí, požádá o zamčení několika bloků a může data začít zpracovávat. Zamčení je akce, při níž bloky přecházejí ze seznamu použitých do seznamu zamčených, čímž nemohou být používány jinou aplikací nebo jinak modifikovány. Po ukončení zpracování dat aplikace bloky odemkne a dojde k jejich přesunu zpět do seznamu volných bloků. Odemčení i zamčení se provádí systémovým voláním ioctl, čekání a uspávání pomocí poll (proto poll-hranice).

Po skončení poslední uživatelské aplikace je hardware zastaven a všechny uzamknuté bloky odemčeny. Následně je možné ovladač odebrat ze systému a uvolnit tak všechny dříve alokované paměťové bloky.

4.3 Sonda FlowMon

Sonda FlowMon je specializované zařízení pro sběr statistických dat o síťovém provozu. Její vývoj byl zahájen v roce 2004 v rámci aktivity JRA2 (Bezpečnost) evropského projektu GN2. V průběhu tří let jsme architekturu sondy dále rozšiřovali s cílem zvýšit propustnost a rozšířit její funkce. Na základě zkušeností získaných v předchozích letech jsme v roce 2007 navrhli zcela novou architekturu sondy, jež umožní měřit linky o rychlosti deset gigabitů a vyšší.

Obrázek 4.7: Vývoj sondy FlowMon

Původní návrh sondy z roku 2004 jsme implementovali a úspěšně otestovali v říjnu 2005. Tuto verzi také otestovali naši partneři v projektu GN2. Přestože její propustnost a funkcionalita nedosahovala linkové rychlosti 1 Gb/s, bez problémů překonala existující softwarová řešení. Přechod na výkonnější typ karet COMBO6X + SFPRO v roce 2006 nám již umožnil měřit plně zatíženou gigabitovou linku. Podrobný popis této verze je možné najít v naší technické zprávě [ZL05]. Tuto verzi sondy jsme nasadili i na řadě míst v síti CESNET2 a získali tím mnoho zkušeností s reálným měřením sítě. Využitím karty COMBO-XFP jsme v roce 2007 získali i první desetigigabitové řešení. Další rozšíření se pak týkala implementace různých typů vzorkování, anonymizace, či vzdálené správy sondy.

4.3.1 Flexibilní FlowMon

Stejně jako se vyvíjela sonda FlowMon, vyvíjela se i oblast monitorování na základě toků. Původní a nejvíce rozšířený protokol NetFlow v5 byl rozšířen o verzi NetFlow v9. NetFlow v5 má fixní strukturu informací (záznam), které ke každému síťovému toku shromažďuje. Jde především o klíč toku, který tok jednoznačně identifikuje. Jako klíč se obvykle volí uspořádaná pětice obsahující zdrojovou a cílovou IP adresu, zdrojový a cílový port a protokol. Pro každý tok se dále sleduje například doba jeho trvání a přenesený počet bajtů a paketů. NetFlow v9 dává možnost fixní záznam měnit, přidávat nové položky či ubírat staré. Podrobnější popis je možné nalézt v v informativním RFC 3954. Sjednocením všech požadavků na monitorování toků vznikl protokol IPFIX. Tyto nové protokoly získávají na významu a postupně se objevují nástroje pro jejich podporu.

Právě plná podpora nových protokolů byla původní motivací pro návrh nové koncepce sondy nazvané flexibilní FlowMon (fFlowMon) v roce 2007. Dalším studiem oblasti monitorování provozu na základě toků se ukázalo, že flexibilní FlowMon může mít daleko širší uplatnění, než jsme původně předpokládali. Rešerší literatury v oblasti monitorování sítí jsme zjistili, že kromě původního využití pro odhalovaní chyb v konfiguraci sítě, plánování sítě, dokazování bezpečnostních incidentů, je možné například automaticky odhalovat škodlivý provoz [GMT05], [Li06], automaticky charakterizovat provoz na úrovni aplikací [MP05] či protokolů nebo použít data o tocích pro zjišťování kvality linky. Metody popsané v těchto článcích jsou obvykle implementovány softwarově a často pracují se vzorky provozu (obsahujícími celé pakety), i když by jim stačila informace o toku. Takový přístup je nemyslitelný pro linky o rychlostech 1 Gb/s a vyšších. Z toho usuzujeme, že mnohdy chybí zdroj, který by umožnil zpracování provozu na úrovni toků a zároveň poskytl dostatečnou flexibilitu.

Na základě zjištěných skutečností jsme se rozhodli navrhnout flexibilní sondu FlowMon a schéma, které by umožnilo uživateli sondy definovat a přizpůsobit parametry monitorovacího procesu, a to především:

které položky se mají z paketu extrahovat,
které položky tvoří identifikátor toku,
strukturu záznamu o toku,
předpis agregační operace pro každou položku záznamu.

Pro popis monitorovacího procesu jsme zvolili jazyk XML. Jeho hlavními výhodami jsou možnost rozšíření, strukturovaný zápis a tudíž přehlednost, jakož i existence knihoven pro jeho zpracování. Celá definice tvoří strom, v němž jedna část definuje strukturu dat extrahovaných z paketu (uhrecord) a strukturu záznamu o toku (flowrecord). Druhá část pak obsahuje definici agregačních operací (flowoperation), například sčítání délek paketů a kontrolních operací (controloperation), např. přetečení čítače paketů. Tento popis je obecný a je možné ho použít pro definici monitorovacího procesu implementovaného ve firmware či software. Proprietární konfigurace (např. hlavičkových souborů) jsou generovány až následně na základě XML souboru.

Nově zavedená definice flexibilního záznamu o toku by nutně potřebovala úpravy ve stávající architektuře sondy FlowMon. Ukázalo se, že bude výhodnější stávající architekturu opustit, neboť její propustnost není dostatečná pro plně vytížené linky s rychlostí přenosu deset gigabitů a vyšší. To je způsobeno složitostí monitorovacího procesu ve firmware, jehož části jsou implementovány algoritmy vhodnými spíše pro softwarové řešení. Na základě měření jsme dále došli k závěru, že architektura příliš málo využívá výpočetní výkon procesoru v počítači, který je vytížen jen z několika procent. Klíčovou myšlenkou je tedy zjednodušit firmware a veškeré problémy, které tím vzniknou, dořešit v software.

Obrázek 4.8: Schematické znázornění rozložení úloh mezi kartu a počítač (větší obrázek)

Sonda je stále založena na akceleračních kartách rodiny COMBO a hostitelském počítači, změna je v rozložení zátěže mezi kartu a počítač. Navržená architektura obsahuje dva monitorovací procesy (viz obrázek). První proces na kartě agreguje pakety do záznamů o tocích, není však schopen udržet záznam v paměti dostatečně dlouho a dochází k jeho předčasné expiraci dříve než síťový tok skončí. To je způsobeno přímou adresací záznamů (dochází ke kolizím). Díky alespoň částečné agregaci se vstupní datový tok dostatečně zmenší a záznamy je již možné přenést do paměti počítače, kde jsou dále agregovány a exportovány na kolektor.

Pro rychlý vývoj aplikačního firmware jsme využili projekt NetCOPE [MT06]. Ten poskytuje jednotné rozhraní pro práci s periferiemi na kartě (paměti, síťová rozhraní, PCI rozhraní). Pro správu záznamů o tocích jsme využili projekt FlowContext [KK07], který dokáže distribuovat záznamy mezi několik paralelně pracujících jednotek. Aplikační firmware se pak skládá z několika za sebou zřetězených jednotek (viz obrázek).

Obrázek 4.9: Architektura firmware (větší obrázek)

První z nich je množina jednotek HFE (Header Field Extractor). Jejich úkolem je přijmout paket z NetCOPE rozhraní a extrahovat informace pro monitorovací proces. Tyto jednotky jsou napsány v jazyku Handel-C, což je velká změna oproti původním jednotkám. Původní HFE byly implementovány ve VHDL jako procesory, na nichž běžel tzv. nanoprogram. Naproti tomu nové HFE nevykonávají žádný program, jejich funkce jsou přímo zabudovány ve firmware a v době běhu je není možné měnit. Tento přístup je efektivnější a umožňuje jedné jednotce zpracovat i větší než gigabitový datový tok. Předpokládá se použití osmi HFE pro zpracování všech paketů při rychlosti deset gigabitů. Nové HFE podporují širokou množinu parametrů, které je z paketu možné zjistit. Na základě konfigurace zapsané v XML se tato množina zúží jen na vyžadované položky.

Extrahovaná data jsou přenesena z karty rozhraní na základní kartu, kde je z klíčových položek (obvykle IP adres, portů a protokolu) vypočítána hodnota rozptylovací funkce (hash). Klíčové položky je možné určit pomocí definice monitorovacího procesu, která je také zapsána v XML.

Správu záznamů (rozhodnutí o expiraci záznamu) zajišťuje Flow State Manager ve vyhrazené paměti. Původní implementaci založenou na řazení záznamů podle stáří v dvojsměrně vázaném seznamu jsme nahradili jednodušší variantou. Její princip spočívá v ukládání časové značky posledního paketu daného toku a postupným kontrolováním všech platných značek.

FlowContext [KK07] nakonec distribuuje extrahovaná data z paketů a k nim příslušné záznamy mezi několik procesních jednotek (Flow Processing Units). Právě procesní jednotky tvoří jádro monitorovacího procesu. Vygenerování instance procesní jednotky vyžaduje zpracovat flexibilní definici XML, tj. přiřadit operacím konkrétní implementaci ve VHDL a tyto operace namapovat na položky záznamu o toku a záznamu extrahovaného z paketu. Procesní jednotka je pak připravena založit, aktualizovat, či uvolnit záznam o toku.

Popsanou architekturu firmware jsme v roce 2007 navrhli a implementovali. Nyní se nachází ve fázi simulací. Aplikační firmware je postaven nad platformou NetCOPE, což znamená, že je do značné míry nezávislý na typu karty. V dnešní době je simulován nad kartami COMBO6X a COMBO-2XFP2 a do budoucna předpokládáme jeho využití na kartách COMBOV2. Softwarově provedené simulace ukazují, že při použití vhodných typů pamětí (QDR SSRAM) bude sonda schopna zpracovat plně vytíženou desetigigabitovou linku.

Kromě firmware jsme museli navrhnout nové programové vybavení. Je nutná podpora práce s XML schématem tak, aby uživatel mohl pohodlně definovat, které položky chce sledovat a přitom strukturu XML nemusel vůbec znát. Tento úkol bude plnit webový frontend, který po zadání všech požadavků provede optimalizace a vygeneruje příslušný firmware.

Na sondě bude instalováno další programové vybavení, například ovladače karty a skripty zajišťující nahrání firmware do karty, inicializaci celé sondy a konfiguraci jejích parametrů. Konfigurace může probíhat lokálně či vzdáleně. Konfigurační část zůstává stejná jako u předchozích FlowMon sond, tedy používá se protokol NETCONF. Nedílnou součástí nové sondy je druhý monitorovací proces běžící v software a na něj navazující exportér. Export dat ze sondy bude možný v několika formátech (NetFlow v5, v9, IPFIX). Nové programové vybavení sondy je ve fázi návrhu. Zároveň předpokládáme převzetí již implementovaných a odzkoušených celků, jako jsou startovací skripty, vzdálená konfigurace, exportéry, apod.

Flexibilní sonda FlowMon spolu s kolektory podporující plně NetFlow v9, či IPFIX může poskytovat o síti daleko více informací než stávající řešení. Její flexibilita umožní uživateli testování různých konfigurací sondy a záznamu samotného. Naměřené výsledky mohou sloužit jak pro ověřování metod například pro detekci útoků, tak vývoje metod nových.

V roce 2008 plánujeme implementovat potřebný software a otestovat sondu jak v laboratorních podmínkách, tak v živé síti. V živé síti bychom chtěli vyzkoušet různé definice záznamu o toku a použít tyto výsledky pro ověření či návrh metod pro detekci škodlivého provozu, charakterizaci provozu, či měření kvality. V delší časové perspektivě bychom pak chtěli nadále zvyšovat výkon sondy, například přechodem na nové karty COMBOV2.

4.3.2 Původní FlowMon sonda

V roce 2007 pokračovaly práce i na původní sondě FlowMon. Podařilo se upravit firmware pro kartu desetigigabitového rozhraní COMBO-XFP a úspěšně s ní měřit desetigigabitovou linku spojující Polsko a Maďarsko. Velkým úspěchem bylo zprovoznění dynamické paměti na základní kartě COMBO6X a její využití pro ukládání až 512 tisíc záznamů. To je oproti původním 64 tisícům toků podstatný rozdíl. Na dnešních linkách se běžně nachází kolem 100 tisíc souběžných toků. S malou kapacitou paměti není možné toky monitorovat nepřerušeně po celou dobu jejich aktivity. Dochází tak k fragmentaci, kdy původně jeden tok je oznamován jako několik samostatných toků. Tento negativní jev je odstraněn použitím dostatečně velké paměti. Dalším rozšířením firmware bylo zabudování podpory pro změnu rychlosti linky. Sonda tedy již umožňuje měřit linky s rychlostí 10 Mb/s, 100 Mb/s, 1 Gb/s a 10 Gb/s.

Programové vybavení původní sondy jsme dále rozšířili, například o implementaci exportéru záznamů, jenž podporuje protokol IPFIX. Podporou protokolu IPFIX jsme se dostali mezi špičku celosvětového vývoje a zjišťujeme, že neexistuje mnoho kolektorů, které by tento protokol dokázaly uspokojivě zpracovat. Samozřejmě zde zůstala možnost záznamy filtrovat podle rozsahu IP adres nebo je anonymizovat. Uživatel má tedy možnost vybírat a modifikovat data podle cílového kolektoru.

Dalším významným přínosem bylo dokončení implementace protokolu NETCONF pro vzdálenou správu a konfiguraci síťových zařízení. V tomto kontextu je NETCONF využíván webovým frontendem, který jsme dokončili na konci tohoto roku. Uživatel může konfigurovat ve frontendu více sond, vytvářet si profily atd. NETCONF podporuje obousměrnou komunikaci mezi sondou a webovým frontendem, je tedy možné zjišťovat aktuální konfiguraci sondy. Přes protokol NETCONF je možné i vzdáleně vykonávat příkazy, například vypnutí sondy. Veškerá data se přitom přenášejí bezpečně šifrovaným SSH kanálem.

Rostoucí složitost celé sondy a existence několika verzí, které vznikly v průběhu vývoje, si vyžádala vznik uživatelské příručky. Ta nemá formu dokumentace, ale spíše návodu na použití sondy. Jako první tento návod ocenila naše testerská skupina, která testuje vydávané balíčky s firmwarem a softwarem sondy, a dále naši partneři v GN2. V tomto roce byla především otestována výkonnost našich sond vůči stávajícím čistě softwarovým řešením - sondám nprobe a fprobe (viz. obrázek), ale také vůči nprobe nad kartami DAG firmy Endace.

Obrázek 4.10: Výsledky měření různých typů sond

Celá instalace sondy FlowMon existuje ve formě balíčku, který lze nainstalovat na běžný počítač s OS Linux a podporovanými COMBO kartami. Tím považujeme tuto verzi sondy za dokončenou a dále se budeme soustředit pouze na doladění případných chyb, či zapracování menších vylepšení. Naše budoucí práce bude směřovat k implementaci flexibilní sondy, jejímu testování a použití v realné síti.

4.4 Traffic Scanner

Od roku 2005 jsme se také soustředili na vývoj hardwarově akcelerovaného systému pro detekci síťových útoků (IDS, Intrusion Detection System). Ke konci roku 2006 jsme vyvinuli prototyp sondy Traffic Scanner, která je schopna akcelerovat velmi rozšířený IDS systém Snort a zvýšit jeho propustnost z několika stovek Mb/s na 4 Gb/s. Sonda je vybavena webovým konfiguračním rozhraním, pomocí něhož ji lze konfigurovat pro akceleraci libovolné množiny pravidel pro Snort. Sonda Traffic Scanner je detailněji popsána v technické zprávě [KKH06].

V letošním roce probíhal vývoj ve dvou směrech. Sonda byla nasazena ve dvou sítích členů CESNETu (VŠB Ostrava a ČVUT Praha). Zde se občas objevily chyby ve firmware, část prací se proto soustředila na řádné otestování a odladění sondy. Umístili jsme do ní ladicí registry, které měly detekovat problémy v sondě. Našim partnerům jsme poskytli nový balíček s opravenými chybami a rovněž možností znova inicializovat sondu v případě neočekávaných problémů. Část lidských zdrojů jsme soustředili na detailní srovnání našeho akcelerovaného IDS řešení vůči čistě softwarovému protějšku. Výsledky ukázaly, že softwarový Snort už pro velmi malou množinu vzorů selhává při 150 Mb/s, zatímco hardwarově akcelerované řešení si poradí i s gigabitovými rychlostmi.

Druhý směr vývoje se soustředil na portování sondy Traffic Scanner na platformu NetCOPE, která do budoucna zajistí snadnější podporu nových karet, vyšší spolehlivost a vysokou propustnost do software. Funkce sondy se portováním na tuto platformu zásadním způsobem nemění, pouze jsme na žádost našich partnerů do firmware zahrnuli podporu protokolu IPv6.

V současné době se Traffic Scanner nad NetCOPE dokončuje. Na konec ledna 2008 plánujeme dokončení beta verze a ke konci února pak stabilní verze. Vzhledem k problémům se spolehlivostí, které se občasně projevují u původního Traffic Scaneru, jsme se rozhodli věnovat více kapacit na verifikaci firmware. Jako zajímavý přístup se ukázala verifikace pomocí SystemVerilogu [Kob07]. Díky ní by měly být téměř všechny chyby objeveny již v implementační fázi. Tento přístup vyzkoušíme na verzi Traffic Scanneru nad NetCOPE v příštím roce.

4.5 Nové výzkumné směry

V polovině roku 2007 byla zformována skupina řešitelů, jejichž úkolem bude zkoumat možné směry dalšího vývoje v rámci aktivity, především tedy najít takové síťové aplikace, které jsou zajímavé z pohledu hardwarové akcelerace v FPGA. Obecně jsou vhodné aplikace, které vyžadují jednoduché, vysoce paralelizovatelné výpočty, zpracování velkého toku dat v reálném čase nebo přesná měření síťového provozu.

Skupina se nejprve zaměřila na aplikace v oblasti síťové bezpečnosti a prostudovala několik síťových aplikací, které jsou nejčastějším terčem specifických útoků nebo zneužití - elektronická pošta a peer-to-peer sítě. Pozornost byla také věnována nespecifickým útokům typu DoS (denial of service), odposlouchávání nešifrovaných spojení, podvržení identity a dalším.

Studium portfolia několika komerčních firem vyvíjející zařízení v oblasti síťové bezpečnosti ukázalo, že důraz je kladen na ad hoc řešení typu "vše v jednom" s použitím známých metod, jakou je například vyhledávání vzorů. Výsledkem jsou pak buď softwarová řešení s nízkou propustností anebo velmi drahá hardwarová zařízení. Usoudili jsme, že v tomto směru nemá smysl komerčním řešením konkurovat.

Chtěli bychom se proto zaměřit na vývoj zařízení, která jsou sice specializovaná a relativně nákladná, ale v dané oblasti dostatečně univerzální. Takovým zařízením se nyní jeví být sonda FlowMon, zvláště pak její nově vyvíjená verze, flexibilní FlowMon. To potvrdilo množství článků zabývajících se analýzou dat, které tato sonda může v principu poskytnout. Spadají sem aplikace pro detekci nežádoucího provozu, detekci virů a červů, DoS útoků, skenování portů, identifikaci aplikací, a dalších.

Ve výzkumných projektech 7. rámcového programu (např. GN3 nebo FEDERICA) se často objevuje myšlenka virtualizovaných sítí, které jsou vytvořeny jakožto vzájemně nezávislé "řezy" (slices) stejné fyzické infrastruktury. Ukazuje se, že úzkým hrdlem moderních virtualizačních nebo paravirtualizačních technologií (VMware, Xen či VServer) je bridžování datového provozu z fyzického síťového rozhraní do několika virtuálních strojů. Pro masivnější virtualizaci by proto mohla mít značný význam hardwarová akcelerace této funkce. Ve spolupráci s jinými aktivitami výzkumného záměru chceme tuto oblast v roce 2008 detailně prozkoumat a případně vyvinout příslušný firmware pro nové karty COMBOV2.

předchozí

obsah

následující