Možnosti analýzy IP toků v OS Linux

Možnosti analýzy IP toků v OS Linux Lukáš Kuna Abstrakt:  Tato   práce   se   zabývá   možnostmi   analýzy   IP   provozu   na   počítačích   s  operačním systémem Linux, popisuje klíčové zástupce jednotlivých metod a zkouší je  porovnávat ve výkonnostních testech. Klíčová slova: Linux, analýza provozu, NetFlow, bezpečnost, optimalizace, akcelerace,  výkon, porovnání, fprobe, nprobe, PF_RING, libpcap, TAP  1  Úvod..............................................................................................................................2  2  Metody analýzy............................................................................................................3  2.1  Průchozí metody....................................................................................................3  2.2  Neinvazivní metody..............................................................................................3  3  Výstupy analýzy...........................................................................................................5  3.1  NetFlow.................................................................................................................5  3.2  SQL, binární, textové exporty...............................................................................6  4  Analýza paketů v user space.........................................................................................7  4.1  Analýzy využívající knihovnu libpcap..................................................................7  4.2  Analýzy s využitím nfnetlink rozhraní (soketů)...................................................9  5  Analýza paketů v user space s optimalizací................................................................12  5.1  PF_RING.............................................................................................................12  5.2  Libe1000..............................................................................................................16  6  Analýza paketů v jádře................................................................................................17  6.1  ipt_NETFLOW....................................................................................................17  7  Analýza s hardwarovou akcelerací..............................................................................18  7.1  Akcelerační karty PCI / PCI­X / PCIe.................................................................18  8  Vybraná měření některých řešení...............................................................................20  8.1  Různá velikost paketů při konstantní rychlosti....................................................21  8.2  Zátěž procesoru podle velikosti paketů...............................................................23  8.3  Zátěž procesoru podle počtů toků.......................................................................24  9  Závěr...........................................................................................................................25  10  Literatura...................................................................................................................26

listopad 2009

1/26

 1  Úvod K efektivní správě počítačové sítě patří zajisté také analýza průchozího provozu. Napomáhá k identifikaci  slabých míst, přetížení nebo třeba také útoků zvenčí nebo zevnitř sítě. V rámci platné legislativy ČR dokonce  musí ISP analýzu provádět povinně (zákon 485/2005 a doprovodné vyhlášky). Pro zabezpečení těchto úkolů slouží spousta komerčních řešení, ať už softwarových nebo běžících na plně  dedikovaném hardware. Vyžadují hlubší nebo zevrubnější integraci do infrastruktury sítě. V rámci  této práce jsem se zaměřil  na rozbor  možností a  způsobů, jak provádět  analýzu v  prostředí  serverů nebo směrovačů běžících s operačním systémem Linux. Nejprve uvedu metody analýzy z pohledu  zapojení do infrastruktury, poté se zaměřím na vysvětlení jednoho z nejpoužívanějších protokolů pro export  dat z analyzátorů provozu ­ NetFlow, rozeberu několik teoretických i plně realizovaných řešení pro analýzu v  Linuxu a na závěr se pokusím provést výkonnostní srovnání některých z popsaných řešení.

listopad 2009

2/26

 2  Metody analýzy Podle   zapojení   jsem   rozdělil   metody   analýzy   na   dva   hlavní   typy   ­   průchozí   a   neinvazivní   metody.  Průchozí   metody   předpokládají   hlubší   integraci   a   mohou   při   poruše   způsobit   ohrožení   funkčnosti   sítě,  zatímco u neinvazivních metod je toto riziko vysoce sníženo nebo zcela eliminováno. 

 2.1  Průchozí metody Chceme­li při analýze provozu využít stávajících linuxových strojů (PC), zvolíme některou z průchozích  metod analýzy, kdy sledovaná data zařízením přímo prochází. Nejedná se tedy o dedikované zařízení pouze  pro analýzu provozu. Mezi průchozí metody můžeme také řadit některá řešení založená na integrovaných obvodech FCPGA,  která  provádí  nejdříve  kopírovaní  průchozích  dat  do  vnitřní  paměti  a  pak  teprve  nad  kopírovanými  daty  analýzu. V závislosti na implementaci (blokovací/neblokovací – zda je průchodnost dat monitorované linky  ovlivněna dokončením analýzy) tak může být dosaženo až stoprocentní úspěšnosti analýzy průchozích dat,  avšak za cenu možného narušení funkčnosti sítě při poruše zařízení. Úspěšností analýzy se zde myslí poměr  mezi skutečně zpracovanými daty a těmi, co analyzovanou linkou protekly.

 2.2  Neinvazivní metody V   případě,   že   chceme   integrovat   analýzu   provozu   bez   zásadnějšího   zásahu   do   sítě   a   nechceme   její  existencí   ohrožovat   její   samotnou   funkčnost,   vybereme   některou   z   následujících   neinvazivních   variant  analýzy.

 2.2.1  Mirror port Mnoho  síťových   přepínačů   umožňuje   funkcionalitu   tzv.   mirror   portu,   tedy   situace,   kdy   se   provoz   na  vybraném portu zcela kopíruje na port jiný. Zde je nutno dávat pozor na to, aby přepínač takto kopíroval  rámce v obou směrech (příchozím i odchozím). Na tomto mirror portu lze pakety odchytávat a analyzovat. V   případě   přímého   zpracování   v   Linuxu   bez   hardwarové   akcelerace   je   mnohdy   nutno   zapnout   tzv.  promiskuitní režim, který umožňuje zpracování rámců, které nejsou adresovány lokální síťové kartě. Je zapotřebí si uvědomit, že kopie analyzovaných dat na mirror portu proudí vždy pouze v odchozím  směru   (od   přepínače),   takže   pokud   součet   toků   analyzovaných   dat   v   příchozím   i   odchozím   směru   na  původním (zdrojovém) portu přepínače přesáhne kapacitu mirror portu, jsou nadlimitní rámce pro mirror  port zahozeny. Toto lze obejít zapojením, kdy se kopírují příchozí data ze zdrojového portu na jeden port a  odchozí data na jiný port. Analýza pak musí logicky probíhat na dvou fyzických linkách. Možnost použití  této alternativní konfigurace je závislá na schopnostech použitého přepínače.

 2.2.2  TAP (Test Access Point) Zařízení   TAP   umožňují   neinvazivní   metodu   analýzy   dat   bez   zásahu   do   přenášených   dat.   V   případě  metalického TAPu se jedná prakticky o pasivní rozbočovač elektrického signálu tak, že do jednoho TAP  portu je zapojena jedna a do druhého portu druhá část linky, další (minimálně dva) porty slouží pro vyvedení  každého ze směrů analyzované linky na odchozí žíly metalické linky (tedy odchozí směr analyzované linky  se shoduje s odchozím směrem jednoho TAP portu a příchozí směr analyzované linky se shoduje s odchozím  portem druhého TAP portu). Vnitřním zapojením je také zajištěno, že nemůže dojít k ovlivnění provozu na  analyzované lince z portů TAP, které slouží pro zapojení analyzátoru. 

listopad 2009

3/26

Obrázek 1: schéma TAPu V případě TAPů s potřebou napájení bývá také ošetřena situace, kdy dojde k výpadku elektrické sítě  (analyzovaná linka funguje dál). Pro metalické linky lze použít do rychlosti 1 Gbps, pro optické i více (zcela transparentní, není u nich ani  vyžadováno napájení).

 2.2.3  Hub Mezi způsoby neinvazivní analýzy lze také zařadit použití hubu, avšak na trhu dnes již tyto zařízení téměř  nenajdeme,   zvláště   v   rychlejších   variantách   (pro   rychlosti   nad   1   Gbps   už   vůbec),   také   nemusíme   chtít  provozovat sledovanou linku na polovičním duplexu, takže se v reálném nasazení s hubem zřejmě nesetkáme.

listopad 2009

4/26

 3  Výstupy analýzy Pokud neumožňuje sonda přímo zpracovávat (filtrovat, agregovat, vyhodnocovat) výsledky analýzy, musí  mít   implementován   pokud   možno   standardizovaný   způsob   exportu   dat   do   aplikace,   která   toto   umí.   V  závislosti na povaze analýzy se mohou struktury exportu samozřejmě výrazně lišit.

 3.1  NetFlow NetFlow   protokol   vyvinula   firma   Cisco   Systems   pro   účely   exportu   dat   z   analýzy   provozu   ze   svých  směrovačů s podporou této technologie. Patří mezi nejpoužívanější protokoly podobného použití vůbec. Jako transportní protokol se využívá převážně UDP, i když lze využít také SCTP. NetFlow vnímá jako elementární prvek analýzy tzv. tok (flow), který reprezentuje všechna přenesená data  (i v několika paketech) mezi dvěmi IP adresami, stejnými porty (transportní vrstvy), ve stejném transportním  protokolu a v jistém časovém oknu. Aplikaci, která sbírá a vyhodnocuje UDP diagramy nesoucí NetFlow data, se říká NetFlow kolektor. Nejčastěji se lze setkat s NetFlow exporty verze 5, s nástupem technologií jako IPv6 a MPLS se začíná  hojně používat i verze 9. Na jejich strukturu se můžete podívat v následujících schématech.

Obrázek 2: NetFlow v5 hlavička paketu

Obrázek 3: NetFlow v5 tělo paketu

listopad 2009

5/26

Obrázek 4: ukázka NetFlow v9 paketu Zatímco verze 5 se specializuje především na atributy protokolu IP a vyšších transportních protokolů (IP  adresy, porty, TCP příznaky), verze 9 si již klade za cíl pojmout širší spektrum atributů i nižších vrstev a  proto zavedla princip tzv. šablon, který umožňuje větší flexibilitu v popisování sledovaných dat.

 3.2  SQL, binární, textové exporty Mnohá řešení analýzy nabízí i několik různých proprietárních exportů. Takto sice můžete data jednoduše  exportovat na disk nebo přes síť do SQL databáze, připravíte se však o kompatibilitu v případě výměny  analyzátoru provozu.

listopad 2009

6/26

 4  Analýza paketů v user space Zvláště při průchozí analýze na Linuxovém směrovači bychom logicky požadovali, aby probíhala v rámci  user   space.   Důvod   je   nasnadě,   v   případě   selhání   aplikace   v   user   space   nedojde   k   ovlivnění   funkčnosti  samotné sítě. Tímto požadavkem však vzniká největší problém ­ vyšší nároky na výkon způsobené přesunem  dat mezi kernel a user space.

 4.1  Analýzy využívající knihovnu libpcap Knihovna  libpcap  je  hodně   používanou  nejen   v  prostředí  Linuxu,  ale   i  jiných   Unix  OS  a   také  třeba  Windows  (varianta  WinPcap). Už  z  názvu (pcap  = packet capture) je zřejmé,  že  slouží pro zachytávání  síťového   provozu.   Knihovna   je   vyvíjena   v  rámci   projektu   tcpdump.org   pod   BSD   licencí   (kořeny   má   na  Berkeleyho univerzitě). Provoz knihovny vyžaduje linuxové jádro zkompilované se zapnutou volbou CONFIG_PACKET, avšak  toto je běžné ve všech distribucích. V rámci práce s touto knihovnou se také velmi často používá filtrování zachytávaných paketů (přesněji  rámců), avšak v moderních linuxových jádrech se již filtrace neprovádí a filtruje se vždy až v knihovně v user  space.  Za pomocí promiskuitního režimu lze dosáhnout i možnosti neinvazivní metody analýzy.

 4.1.1  Fprobe První vydání tohoto projektu ve verzi 0.8 se datuje už do roku 2002, postaral se o ni ruský programátor  Slava Astashonok. Nyní je již projekt neaktivní, avšak stále používaný. Mezi podporované platformy patří  kromě Linuxu také FreeBSD a Solaris.  Podporuje export ve formátu NetFlow v1, v5 a v7, avšak ne všechny položky vyplňuje (např. ASN a  SNMP indexy rozhraní). Podporuje pouze protokol IPv4, spouští se jako samostatný daemon pro každé rozhraní, umožňuje běžet v  promiskuitním módu a také monitorovat zároveň všechna rozhraní v jedné instanci (jako název rozhraní se  použije „any“). Podporovány jsou libpcap filtry pro omezení monitorovaného provozu. Stránky projektu: http://fprobe.sourceforge.net/ Výhody: vysoká kompatibilita (pouze nainstalovat, nakonfigurovat a spustit) Nevýhody: – bez podpory rozeznávání rozhraní (nevyplňuje tuto hodnotu v NetFlow paketech) – vysoká výpočetní náročnost – téměř žádné nadstandardní funkce –

listopad 2009

7/26

 4.1.2  Softflowd Historie projektu Softflowd se datuje také do roku 2002, o vývoj se stará Damien Miller, s drobnými  úpravami je udržován až dodnes. Umožňuje monitoring IPv4 i IPv6 paketů, export v NetFlow formátu verze 1, 5 a 9, pro transport NetFlow  dat lze použít nejenom IPv4 UDP, ale také UDP na IPv6 a multicastu. Běží jako samostatný daemon s nasloucháním na jednom rozhraní v promiskuitním režimu, možné je  použít jako zdroj soubor v pcap formátu. Běh daemona lze limitované ovlivňovat a zjišťovat z něj statistiky za  pomocí dodávané aplikace softflowctl. Stránky projektu: http://www.mindrot.org/projects/softflowd/

– – – – –

Výhody: podpora IPv6 možnost načítání dat z pcap souboru lepší výpočetní náročnost než fprobe možnost omezeného ovládání sondy za běhu Nevýhody: nemožnost monitoringu více rozhraní najednou v rámci jedné instance daemona

 4.1.3  Pmacct Vývojář Paolo Lucente stojí za projektem pmacct (Promiscuous mode IP Accounting package). Jedná se o kombinovaný NetFlow kolektor a analyzátor dat z různých zdrojů – libpcap,  libnetfilter_log  (popisovaný dále), NetFlow a sFlow. Výsledky umí exportovat ve formátech NetFlow v5 a v9 a také sFlow  v5, data se mohou ukládat i do SQL databází. Podporuje protokoly IPv4 i IPv6, umožňuje také monitorovat  BGP spojení ­ integruje BGP démona, který umí ze zjištěných BGP tabulek rozpoznávat zdrojový a cílový  autonomní systém, z kterých BGP partnerů data přišla, odpovídající AS­PATH, komunity, lokální preference  nebo MED. Kompatibilita je zaručena na systémech Linux, BSD a Solaris. Díky exportům do SQL databází  projekt umožňuje dobrou integraci s jinými řešeními pro monitoring a grafické znázornění jako je MRTG,  GNUplot, apod. Celá množina funkcionalit však s sebou nese obtížnější nastavování aplikace. Stránky projektu: http://www.pmacct.net/ Výhody: možnost přímého exportu do MySQL, PostgreSQL nebo SQLite mnoho funkcionalit včetně monitoringu BGP spojení, analýzy IPv6, podpory importů/exportů NetFlow a  sFlow, netlink importy, agregace... Nevýhody: – složitější konfigurace – –

listopad 2009

8/26

 4.2  Analýzy s využitím nfnetlink rozhraní (soketů) Knihovna libnfnetlink zprostředkovává komunikaci mezi kernel a user space pro aktivity, které se řadí do  skupiny netfilter funkcionalit v rámci linuxového jádra. Netfilter není potřeba linuxovým administrátorům asi  moc představovat, jedná se o celou skupinu funkcionalit a možností pro práci s IP provozem v jádře ­ filtrace,  tvarování, analýza, manipulace (včetně překladu adres). Velká část funkcionalit je v jádře a doprovodných  utilitách   (především   iptables)   přímo   integrována,   vyvíjena   a   udržována,   projekt   sdružuje   také   několik  doprovodných řešení, které lze do jádra doplnit. Řešení v rámci rozhraní netlink rozhraní patří mezi relativně čerstvé, odpovídající nfnetlink podsystém  začal být součástí jádra od verze 2.6.14 (konec roku 2005). Stránky projektu: http://www.netfilter.org/projects/libnfnetlink/

 4.2.1  Projekty využívající knihovny libnetfilter_log Jednou z vyvíjených knihoven v rámci projektu netfilter, která využívá hlavní knihovny libnfnelink, je  knihovna   libnetfilter_log.   Komunikuje   s   podsystémem   jádra   nfnetlink_log,   které   zprostředkovává   přenos  paketů z netfilter modulu jádra ULOG do user space. Jednoduše řešeno, za pomocí všech silných filtrovacích  metod si utilitou iptables nadefinujete, které data se budou přenášet pomocí tohoto rozhraní do user space a  za pomocí libnetfilter_log knihovny můžete v user space pakety zachytávat a případně za pomocí dalších  řešení analyzovat. Stránka projektu: http://www.netfilter.org/projects/libnetfilter_log/ Existuje několik řešení, která umožňují analyzování dat za pomocí knihovny libnetfilter_log, pro podobné  parametry se nemá smysl zabývat každým řešením individuálně. Vyjmenuji aspoň některá řešení: – fprobe­ulog (varianta frobe pro tento zdroj dat) – ipcad (podporuje šírší množinu zdrojů dat) – ulogd (nepodporuje NetFlow export) Výhody: filtrace monitorovaného provozu za pomocí všech silných metod iptables jednoduché nasazení a dobrá kompatibilita (u nových jader) Nevýhody: – pouze průchozí metoda analýzy – vysoká výpočetní náročnost (u testovaného řešení fprobe­ulog) – –

listopad 2009

9/26

 4.2.2  Použití knihovny libnetfilter_queue Do sady knihoven používajících libnfnetlink patří také knihovna libnetfilter_queue. Jedná se o náhradu  dřívějších řešení znamých pod názvy ip_queue nebo libipq (IPQ). Stránky projektu: http://www.netfilter.org/projects/libnetfilter_queue/ Ve   své   podstatě   nebyla   tato   knihovna   a   odpovídající   podsystém   jádra   nfnetlink_queue   navržena   pro  analyzování provozu, ale pro filtrování. Stejně jako předchozí knihovna umožňuje přenos paketů do user  space za účelem zpracování, cílem je však posouzení, zda má být paket propuštěn dále nebo zahozen. Lze tak  jednoduše stavět filtry (především na aplikační úrovni) bez zásahu do jádra. Vzhledem ke komplexnosti  řešení však není problém teoreticky využít tohoto principu i v případě analýzy provozu. Tento princip lze považovat pouze za průchozí metodu analýzy. Neexistuje příliš mnoho implementací, které by tohoto principu využívaly, starší způsob za pomocí libipq  umožňuje třeba již zmíněná aplikace ipcad.

– – – –

Výhody: filtrace monitorovaného provozu za pomocí všech silných metod iptables garance 100% zaznamenaného průchozího provozu Nevýhody: při problému user space aplikace jsou pakety zahozeny (riziko) pouze průchozí metoda analýzy

 4.2.3  Použití knihovny libnetfilter_conntrack Před představením této další knihovny z řady bych chtěl vysvětlit pojem connection tracking. Jedná se  soubor   metod   pro   evidenci   stavů   spojení   a   obecně   průchozích   dat   směrovačem.   Směrovač   je   schopný  evidovat,   v   jakém   stavu   se   přenos   dat   nachází   a   v   závislosti   na   tom   umožňuje   stavovou   filtraci   paketů  (nazýváno   také   SPI   ­   stateful   packet   inspection).   Connection   tracking   musí   být   také   aktivní   v   případě  základních operací s překladem adres ­ směrovač musí udržovat záznamy o přemapování adres a portů. V  rámci   linuxového   jádra   lze   takto   nahlížet   na   procházející   data   v   širším   kontextu   a   provádět   rozsáhlejší  analýzy provozu. Tyto záznamy jádro ukládá v takzvané conntrack (CONNection TRACKing) tabulce. Knihovna libnetfilter_conntrack umožňuje zpracovávat záznamy v conntrack tabulce ­ vyvolávat události  při vzniku, změně stavu a zániku položky, odebírat a přidávat záznamy, apod. Abychom si udělali dobrý  přehled o tom, jaké události mohou být vyvolány a jaké informace lze z conntrack záznamu zjistit, použijeme  utilitu s příznačným názvem conntrack pro online výpis události v tabulce. Pro ICMP data:     [NEW] icmp     1 30 src=1.1.1.1 dst=2.2.2.2 type=8 code=0 id=2684  [UNREPLIED] src=2.2.2.2 dst=1.1.1.1 type=0 code=0 id=2684 id=3581955672  [UPDATE] icmp     1 30 src=1.1.1.1 dst=2.2.2.2 type=8 code=0 id=2684  src=2.2.2.2 dst=1.1.1.1 type=0 code=0 id=2684 id=3581955672 [DESTROY] icmp     1 src=1.1.1.1 dst=2.2.2.2 type=8 code=0 id=2684 packets=1  bytes=128 src=2.2.2.2 dst=1.1.1.1 type=0 code=0 id=2684 packets=1 bytes=128  id=3581955672

Podobně pro UDP (dns požadavek):     [NEW] udp      17 30 src=1.1.1.1 dst=2.2.2.2 sport=49772 dport=53  [UNREPLIED] src=2.2.2.2 dst=1.1.1.1 sport=53 dport=49772 id=3478669640 [DESTROY] udp      17 src=1.1.1.1 dst=2.2.2.2 sport=49772 dport=53 packets=1  bytes=60 src=2.2.2.2 dst=1.1.1.1 sport=53 dport=49772 packets=1 bytes=269  id=3478669640

listopad 2009

10/26

Takto vypadají události při telnet TCP spojení:     [NEW] tcp      6 120 src=1.1.1.1 dst=2.2.2.2 sport=62573 dport=23  [UNREPLIED] src=2.2.2.2 dst=1.1.1.1 sport=23 dport=62573 id=3662681144  [UPDATE] tcp      6 60 SYN_RECV src=1.1.1.1 dst=2.2.2.2 sport=62573 dport=23  src=2.2.2.2 dst=1.1.1.1 sport=23 dport=62573 id=3662681144  [UPDATE] tcp      6 86400 ESTABLISHED src=1.1.1.1 dst=2.2.2.2 sport=62573  dport=23 src=2.2.2.2 dst=1.1.1.1 sport=23 dport=62573 [ASSURED] id=3662681144  [UPDATE] tcp      6 120 FIN_WAIT src=1.1.1.1 dst=2.2.2.2 sport=62573 dport=23  src=2.2.2.2 dst=1.1.1.1 sport=23 dport=62573 [ASSURED] id=3662681144  [UPDATE] tcp      6 60 CLOSE_WAIT src=1.1.1.1 dst=2.2.2.2 sport=62573 dport=23  src=2.2.2.2 dst=1.1.1.1 sport=23 dport=62573 [ASSURED] id=3662681144  [UPDATE] tcp      6 30 LAST_ACK src=1.1.1.1 dst=2.2.2.2 sport=62573 dport=23  src=2.2.2.2 dst=1.1.1.1 sport=23 dport=62573 [ASSURED] id=3662681144  [UPDATE] tcp      6 120 TIME_WAIT src=1.1.1.1 dst=2.2.2.2 sport=62573 dport=23  src=2.2.2.2 dst=1.1.1.1 sport=23 dport=62573 [ASSURED] id=3662681144 [DESTROY] tcp      6 src=1.1.1.1 dst=2.2.2.2 sport=62573 dport=23 packets=37  bytes=1542 src=2.2.2.2 dst=1.1.1.1 sport=23 dport=62573 packets=34 bytes=1809  [ASSURED] id=3662681144

Je zjevné, že nejzákladnější informace pro vygenerování NetFlow v5 paketu máme: protokol, zdrojová a  cílová adresa i s portem, počet přenesených paketů a bajtů, u některých transportních protokolů i další údaje.  Dokonce by stačilo zachytávat pouze DESTROY události. Implementaci zachytávání události conntrack tabulky pro odesílání na NetFlow kolektor jsem nenalezl,  umí s nimi pracovat již zmiňovaná aplikace ulogd. Implementace by nemusela být složitá a na výpočetní  výkon náročná.  Stránky projektu: http://www.netfilter.org/projects/libnetfilter_conntrack/ Výhody: jednoduché řešení, není potřeba žádná logika potencionálně velmi výkonné řešení Nevýhody: – předpokládá běh connection trackingu – problémy se zjištěním dodatečných atributů NetFlow v5 záznamu (ASN, ToS, apod.) – –

listopad 2009

11/26

 5  Analýza paketů v user space s optimalizací Protože se ukazuje přenos analyzovaných dat do user space za použití technik ve výchozím linuxovém  jádře jako úzké místo v rámci celé implementace, je vhodné se zabývat možnými způsoby pro snížení této  režie pomocí různých modifikací jádra nebo zcela jinými řešeními.

 5.1  PF_RING Projekt ntop.org vytvořil nový typ soketu ­ PF_RING. Při jeho otevření se v jádře alokuje vyrovnávací  paměť (kruhová vyrovnávací paměť ­ ring buffer, z tohoto PF_RING), do které se ukládají data bezprostředně  po příchodu z ovladače síťové karty. Jádro si udržuje ukazatel do kruhové vyrovnávací paměti, kam zapisuje  příchozí data, také udržuje ukazatel na místo, ze kterého jsou data čtena z user space. Není tak potřeba  vysoce náročného zamykání. Pro čtení dat z kernel space v user space se používá techniky mmap (nízká  režie). Díky těmto praktikám lze dosáhnout velmi účinného zachytávání dat. Aplikace využívající PF_RING  se ani vzájemně neovlivňují, protože pro každý soket se používá samostatná vyrovnávací paměť, pokud jedna  zpracovává data pomalu, ztrácí příchozí data pouze ona sama.

Obrázek 5: architektura PF_RING

Stránky projektu: http://www.ntop.org/PF_RING.html Poslední   verze   PF_RING   umožňují   modulární   kompilaci   bez   patchování   jádra,   vyžadují   samozřejmě  zdrojové kódy aktuálně používaného jádra. Pro jednoduchou práci s pakety v user space slouží dodávaná  knihovna. Autoři  se  také  snažili  ještě  více  snížit  nároky  na  přenos  dat  do  vyrovnávací  paměti  tím,  že  podporu  implementovali přímo do vybraných ovladačů síťových karet. Podle jejich měření může dojít k zefektivnění v  řádu 10­20%, avšak je k zamyšlení, zda je vhodné cestu speciálně upravených a hůře udržovaných ovladačů  podstupovat. Výraznější úspory lze dosáhnout upravenými ovladači při technice TNAPI, kterou popisuji dále. Výhody: významné vylepšení ve výpočetní náročnosti snížení možných ztrát paketů při zachytávání jednoduchá kompilace modulu jádra Nevýhody: – aplikace musí umět využít tuto funkci – – –

listopad 2009

12/26

 5.1.1  Knihovna libpcap s podporou PF_RING Snaha   přivést   uživatele   k   použití   technologie   PF_RING   bez   nutnosti   upravovat   své   aplikace   vedla  vývojáře k zakomponování podpory PF_RING přímo transparentně do knihovny libpcap. V aplikacích tak  není nutno nic měnit, nepříjemností však je, že musí být znova překompilovány s nalinkovanou knihovnou  libpfring. Výsledná optimalizace však vede k výraznému snížení výpočetní náročnosti.

Obrázek 6: architektura libpcap s  PF_RING a přímý přístup PF_RING

– – – –

Výhody: není nutno měnit zdrojové kódy hotových aplikací používajících libpcap výrazně menší zátěž oproti řešení bez podpory PF_RING Nevýhody: nutno použít dodávané libpcap nutno překompilovat všechny libpcap aplikace

 5.1.2  TNAPI Vývojaři projektu ntop.org se snaží využít také některých dalších možností, jak optimalizovat dodání  analyzovaných dat do user space. Projekt TNAPI využívá technik Intel I/O Acceleration Technology (I/OAT),  Message Signaled Interrupts (MSI­X), Direct Cache Access (DCA), Intel Resource Side Scaling (RSA) a  Intel Quickdata. Při použití těchto technik je možno volat nezávislá přerušení na každé samostatné jádro  procesoru a data ze síťové karty tak mohou proudit paralelně. Originální linuxový driver tohoto principu  nevyužívá   dostatečně   (zpracovává   fronty   ze   všech   jader   sekvenčně),   avšak   techniky   TNAPI   společně   s  PF_RING dokáží tyto funkcionality využít naplno, vytvořit hned několik kruhových vyrovnávacích pamětí  tak,   aby   každé   odpovídalo   jednomu   jádru   a   datům   v   cestě   nebránilo   žádné   sériové   zpracování.   Zhruba  dvojnásobného zefektivnění lze dosáhnout i bez použití více vyrovnávacích pamětí, TNAPI pak obchází  serializaci síťového ovladače a zpětnou deserializaci při rozdvojení do kruhových vyrovnávacích pamětí a  další z uvedených technik. Řádově k n­násobnému urychlení úměrnému počtu jader dojde v případě použití  plného TNAPI s podporou všech uvedených technik. Podrobnější informace a testy naleznete na stránkách  projektu. Podporovány jsou síťové karty založené na chipech Intel 82575/82576 (1 gbps) a Intel 82598/82599 (10  gbps).

listopad 2009

13/26

Obrázek 7: přístup k datům ze síťové karty s  podporou RSS bez optimalizací TNAPI

Obrázek 8: přístup k datům ze síťové karty s podporou  RSS s optimalizací TNAPI

Stránky projektu: http://www.ntop.org/TNAPI.html

– – – –

Výhody: extrémní urychlení přenosu do user space ze síťové karty Nevýhody: použití upravených ovladačů nutno mít podporovaný hardware (procesor, základní deska, síťové karty) "placený" projekt

listopad 2009

14/26

 5.1.3  Nprobe Analyzátor nProbe patří mezi další řešení projektu ntop.org.   I když dokáže aplikace nProbe zachytávat data za pomocí knihovny libpcap, zahrnul jsem ji do kategorie  user space analýzy s optimalizaci, protože zasahuje hned do několika popisovaných kategorií. Analyzovaná  data lze zachytávat také prostřednictvím technologie PF_RING, avšak přímo bez prostřednictví upravené  knihovny libpcap. Tuto funkčnost se mi však nepodařilo otestovat a ověřit, protože se jedná o novinku a za  stažení zdrojových kódu se platí. Podporuje také některé síťové akcelerační karty, export do SQL databází,  IPv6, rozšířené VoIP analýzy, NetFlow v5 a v9. Stránky projektu: http://www.ntop.org/nProbe.html

– – – – –

Výhoda: vysoké množství funkcí multiplatformní nízká výpočetní náročnost nativní podpora PF_RING Nevýhoda: "placené" řešení

listopad 2009

15/26

 5.2  Libe1000 Max Krasnyansky vytvořil projekt Libe1000. Jak už je z názvu zřejmé, týká se síťových karet značky  Intel. Vytvořil do jádra upravený ovladač e1000, který umožňuje za pomocí DMA přenos dat z karty přímo  do user space. Odpadá tak zcela režie spojená z přenosem dat z kernel space do user space, protože data přes  kernel space vůbec neproudí, navíc DMA přenos se provádí nezávisle na procesoru. Samotné ovládání a  přístup k zachytáváním datům zprostředkovává v user space dodávaná knihovna a utilita e1000config.  Stránky projektu: http://libe1000.sourceforge.net/

– – – – –

Výhody: odpadá režie přenosu dat z kernel do user space Nevýhody: obtížnější nasazení, částečně modulární (od verze 3.0 nezasahuje do originálního ovladače) specializované řešení pro jeden typ síťové karty v základu pouze neinvazivní metoda analýzy zřejmě již neudržovaný projekt

listopad 2009

16/26

 6  Analýza paketů v jádře  6.1  ipt_NETFLOW Projekt ipt_NETFLOW patři mezi modulární řešení analýzy dat čistě v rámci kernel space, vyvíjí ho  ruský vývojář s pseudonymem aabc, zřejmě z lokální telekomunikační firmy. V zásadě se jedná o velmi efektivní a modulární řešení analýzy v kernel space, autor zvolil implementaci  jako iptables modul cíle (target modul), což s sebou nese mnoho výhod: přesně definované rozhraní s jádrem  (jednoduše přizpůsobitelné v případě změn), přímý přístup k potřebným atributům paketu, stejná výpočetní  náročnost při různých velikostech paketů při jejich stejném počtu, monitorované pakety lze efektivně filtrovat  za pomocí všech silných metod iptables, je zaručeno stoprocentní zpracování průchozích dat. Kompilace  modulu jádra  i  iptables  probíhá  modulárně,  nutno  mít  samozřejmě  zdrojové  kódy  jádra  a  iptables. Projekt nabízí také jednu specialitu ­ za pomocí velmi malého patche jádra lze zachytávat v netfilter  tzv. raw tabulce data v promiskuitním módu, takže lze provádět analýzu i neinvazivně.   Za běhu lze sledovat užitečné statistické informace přes virtuální proc souborový systém. V testech se  potvrdila implementace jako velice efektivní, nepříjemností jistě je, že se opakovaně při uvolnění modulu  "podařilo" vytvořit oops jádra (kernel oops), obvykle důvody pro uvolnění modulu nejsou, parametry jako  adresa NetFlow kolektoru lze měnit také prostřednictvím proc souborového systému. Stránky projektu: http://sourceforge.net/projects/ipt­netflow/ Výhody: modulární řešení zcela bez interakce s user space ­ velmi nízká zátěž (pro malé počty proudů téměř neměřitelná) možnost neinvazivní analýzy (vyžaduje patch jádra) možnost blokující průchozí analýzy s garancí 100% zpracovaných paketů pravidla pro agregaci filtrace monitorovaného provozu za pomocí všech silných metod iptables Nevýhody: – zapotřebí zdrojové kódy jádra a iptables (ale není nutno patchovat) – riziko zpracování v kernel space – bez podpory IPv6 – – – – – –

listopad 2009

17/26

 7  Analýza s hardwarovou akcelerací Pro maximální možné snížení zátěže procesoru při analýze dat by mohlo být užitečné provádět aspoň  některé operace akcelerovaně bez zatěžování procesoru. Vzhledem k tomu, že již dnes karty celkem běžně  podporují akceleraci kontroly CRC, moc možností urychlení kromě akcelerace přenosu dat z karty do paměti,  které jsem tu už popsal, už není, otevírá se pouze možnost analyzovat data přímo v nějakém hardwarovém  modulu a PC sběrnici a procesor zatěžovat pouze exportovanými výsledky analýz.

 7.1  Akcelerační karty PCI / PCI­X / PCIe  7.1.1  FFlowMon V rámci aktivit Cesnetu a projektu Liberouter je vyvíjeno řešení s názvem FFlowMon (Flexible FlowMon  probe)  jako  nástupce  starší   verze   FlowMon.   Jedná  se   o  komplexní  architekturu,  v   rámci   níž   bylo   nutno  provést vývoj karet s programovatelnými poli, firmwaru pro něj, modulů jádra, knihoven, ovládacích utilit a  webového rozhraní. Vytvořené   PCI   karty   využívají   integrovaných   chipů   společnosti   Xilinx,   síťové   rozhraní   je   řešeno   za  pomocí SFP a XFP modulů. Karty řady COMBO6 zvládnou zpracovat rychlosti do 10 Gbps, inovovaná řada  COMBOv2 si poradí i s vyššími rychlostmi. Kromě protokolu IPv4 je také podporován protokol IPv6 a  dokonce MPLS. V závislosti na velikosti osazené paměti lze analyzovat až 128 nebo 512 tisíc paralelních  toků. Mezi podporované exportní protokoly patří NetFlow v5 a v9 a také protokol IPFIX. Karta umožňuje neinvazivní metodu měření, ale je možné provádět měření průchozí metodou, kdy se  karta stará o replikaci provozu na druhý port. 

Obrázek 9: architektura FFlowMon O komerční prodej a podporu řešení se stará česká firma Invea­Tech, která integruje řešení s kompletní  dodávkou hardware, NetFlow kolektoru, TAP prvky, apod. Stránky projektu: http://www.liberouter.org/fflowmon/

– – – – – –

Výhody: velmi nízké zatížení procesoru i pro velký počet toků, malou velikost paketů i jejich velké množství možnost neinvazivní i průchozí metody Nevýhody: cena vyžaduje port v PC omezení počtu toků (aktuálně max 512 tisíc) neprůchodnost dat při poruše sondy (u neinvazivní metody)

listopad 2009

18/26

 7.1.2  DAG karty společnosti Endace Společnost   Endace   komerčně   vyvíjí   PCI/PCIe   akcelerační   karty   pro   analýzu   provozu   technologií  Ethernet, Sonet/SDH a PDH/TDM.

– – – – –

Umožňují provádět filtraci provozu přímo v kartě na základě: ethertype zdrojové a cílové MAC adresy zdrojové a cílové IP adresy typu transportního protokolu značkách protokolu

Pro analýzu může být z karty posílán celý paket, jenom jeho hlavička nebo vybraný počet bajtů. Samozřejmostí je optimalizace průchodu kernel space, v user space se o práci s daty stará knihovna  libdag. Možná je také integrace s knihovnou libpcap. Karty podporuje také tzv. jumbo frame do velikosti 9600 bajtů, pro připojení do sítě je možno použít více  druhů rozhraní v závislosti na technologii a typu karty. Je zapotřebí si uvědomit, že tyto karty samy o sobě analýzu toků neprovádí, vyplatí se v případě, že  potřebujete   analyzované   data   více   filtrovat,   urychlení   přináší   funkce   přenosu   hlaviček   paketu   nebo  omezeného počtu bajtů a také další akcelerační techniky přenosu do user space.  Stránky výrobce: http://www.endace.com/dag­network­monitoring­cards.html

 7.1.3  Karty společnosti Napatech Firma Napatech nabízí celé množství typů karet, běžné filtrační jako u řady DAG, ale také inspekční karty  založené na analýze toků. Kromě hardwarového filtrování a integrace s knihovnou libpcap se výrobci chlubí efektivním rozkládáním  zátěže na více jader, značkováním provozu a dalšími funkcionalitami. Bližší informace o kartách pro analýzu toků se dozvíte na následujících stránkách firmy: –  http://www.napatech.com/products/inspect_adapters.html 

 7.1.4  Karty společnosti Tilera Analýzou provozu s hardwarovou akcelerací se také zabývá společnost Tilera, bližší informace můžete  najít na jejich webu: –  http://www.tilera.com/solutions/networking.php  –  http://www.tilera.com/solutions/network_security_appliances.php 

listopad 2009

19/26

 8  Vybraná měření některých řešení Pro měření analýzy dat  jsem zvolil počítač s  dvoujádrovým  procesorem Intel Atom 330, protože má  relativně malý výkon na jedno jádro oproti dnešním tradičním procesorům a proto se na něm lépe projeví  zátěž   i   při   menším   provozu.   Deska   byla   osazena   2   GB,   z   důvodu   měření   jsem   vypnul   funkci   Hyper­ Threading, linuxové jádro jsem zvolil ve verzi 2.6.31. UDP provoz jsem generoval za pomocí vlastních aplikací naprogramovaných v C.

listopad 2009

20/26

 8.1  Různá velikost paketů při konstantní rychlosti Jako   hlavní   test   jsem   zvolil   modelovou   situaci,   kdy   jsem   za   pomocí   vytvořené   aplikace   generoval  jednosměrný UDP provoz konstantní přenosové rychlosti, avšak pokaždé s jinou velikostí paketů. Provoz  jsem   pro   účely   NetFlow   exportu   analyzoval   téměř   všemi   řešeními,   které   jsem   byl   schopen   zprovoznit.  Celkovou konstantní rychlost jsem počítal včetně všech L2 ­ L4 hlaviček. Testoval jsem tyto nastavení generování provozu: – 64bajtové rámce, 40 tisíc za sekundu – 128bajtové rámce, 20 tisíc za sekundu – 256bajtové rámce, 10 tisíc za sekundu – 512bajtové rámce, 5 tisíc za sekundu – 1024bajtové rámce, 2.5 tisíc za sekundu – 1500bajtové rámce, 1707 za sekundu Každý dílčí test s každým řešením trval minutu, prováděl jsem ho 3­krát za sebou a vypočítal aritmetický  průměr výpočetní náročnosti.  

Obrázek 10: graf závislosti zatížení procesoru na počtu paketů při konstantní rychlosti Podívejme se na graf v souvislostech. Velkým (negativním) překvapením byl pro mne výkon řešení fprobe­ulog. Přestože autoři slibují lepší  výkon oproti verzi fprobe založené na knihovně libpcap, opak je pravdou a fprobe­ulog tak uzavírá test s  naprosto nejhorším výsledkem. Jen zhruba o pár procent rychleji si vedla standardní varianta fprobe. Z grafu je zřejmě, že o velkou  výpočetní   náročnost  se   zde   nepodílí   hlavně   přenos   rámců   do   user   space,   ale   špatná   výkonnost   samotné  analyzační   části,   protože   další   čistě   user   space   řešení   nProbe   ukázalo   prakticky   poloviční   náročnost.  Akcelerovaná varianta fprobe s podporou PF_RING sice vykazuje o hodně lepší výsledky, stále je náročnější  než nProbe bez podpory PF_RING. Velmi sympatické výkony podalo řešení nProbe, jak bez i s podporou technologie PF_RING. Varianta s  PF_RING se dokonce ukázala zhruba jenom jednou tak náročnější než čistě kernel space řešení ipt_netflow,  které lze dle očekávání jednoznačně pasovat za vítěze testu.

listopad 2009

21/26

 8.1.1  Porovnání výkonu libpcap řešení s a bez použití PF_RING Pro demonstraci toho, jak může být výhodné použití funkcionality PF_RING, se podívejme na přímé  porovnání zatížení procesoru při testech řešení fprobe a nProbe s a bez funkcionality PF_RING.

Obrázek 11: porovnání zátěže fprobe bez a s technologií PF_RING

Obrázek 12: porovnání zátěže nprobe bez a s technologií PF_RING

listopad 2009

22/26

 8.2  Zátěž procesoru podle velikosti paketů V tomto testu jsem vybral z každé skupiny NetFlow analyzátorů jednoho (lepšího) zástupce a vyzkoušel,  jak velkou roli hraje velikost paketu na zátěž procesoru. Při stejném počtu UDP paketů za vteřinu jsem měnil  postupně jejich velikost a zaznamenával vytížení, konkrétně pro tyto případy: – 6000 paketů za vteřinu, 1500 bajtů – 6000 paketů za vteřinu, 1024 bajtů – 6000 paketů za vteřinu, 512 bajtů – 6000 paketů za vteřinu, 256 bajtů – 6000 paketů za vteřinu, 128 bajtů – 6000 paketů za vteřinu, 64 bajtů Provedl jsem opět každý test 3­krát a spočetl průměr. Můžete si prohlédnout výsledný graf:

Obrázek 13: zátěž procesoru v závislosti na velikosti paketů při jejich stejném počtu Protože bylo problém vyrobit velké množství testovacích rámců tak, aby se dal provést test s velkým  rozsahem   velikostí   paketů,   jsou  výsledná   data   zatížena   velkou   chybou   měření.   Výsledky   jsem   prokládal  přímkou, protože si myslím, že charakteristice nejlépe vyhovuje. Potvrdila se teze, že na výpočetní náročnost řešení ipt_netflow velikost paketů nemá prakticky žádný vliv  (zátěž byla prakticky konstantní). Nejvyšší nárůst zátěže vykázalo řešení fprobe­ulog, avšak výsledky testu  bych bral opravdu s velkou rezervou. Lze ale s určitostí říci, že při výběru implementace se nemusíme ohlížet  na   to,   jak   velké   pakety   chceme   monitorovat.   V   kontextu   s   předchozím   testem   je   zřejmé,   že   zátěž  implementací se především odvíjí od počtu přenesených paketů.

listopad 2009

23/26

 8.3  Zátěž procesoru podle počtů toků Při tomto testu jsem chtěl zjistit, jak se jednotlivá řešení vypořádají s rostoucím počtem toků. Generoval  jsem proto provoz 40 tisíc 64bajtových UDP paketů za vteřinu, měnil počet vygenerovaných toků a sledoval  změnu v zátěži. Jednotlivé toky ze lišily ve zdrojovém a cílovém portu.  Celkem jsem testoval tyto počty toků: 50, 500, 5000, 50000 a 500000. Použité   programy   fprobe,   nprobe   (oba   s   optimalizací   PF_RING),   fprobe­ulog   a   modul   jádra  ipt_NETFLOW jsem použil ve výchozím nastavení, takže je potřeba výsledky brát mírně s rezervou, avšak  základní orientaci tento test určitě poskytne. Provedl jsem opět každý test 3­krát a spočetl průměr.

Obrázek 14: zátěž procesoru v závislosti na počtu toků při stejném počtu paketů Výsledky fprobe­log jsou zatížené velkou chybou kvůli tomu, že měření prakticky zcela zatěžovalo jedno  celé jádro, avšak proložený graf částečně ukazuje tendence v zátěži (ověřil jsem to i na polovičním počtu  analyzovaných paketů).  Podobnou progresi  lze sledovat  také  u tradičního  fprobe  postaveného na  libpcap  PF_RING, jsou to v jádru prakticky shodné aplikace, pouze s jiným zdrojem dat. Celkem dramatický nárůst výpočetní náročnosti se ukázal u řešení nProbe PF_RING nad úrovní zhruba  20 tisíc souběžných toků, zhruba nad 200 tisíc souběžných toků se řešení ukázalo dokonce pomalejší než  fprobe PF_RING. Proč se tomu tak děje? Nejspíše to má na svědomí odlišná implementace evidence toků v  každé z aplikací, svou roli může hrát skutečnost, že test probíhal vždy mezi stejnými IP adresami, ale pouze s  jinými dvojicemi portů, na což může být fprobe lépe optimalizováno. Při testu s maximálním počtem toků  dokonce   nProbe   začalo   hlásit   problém   s   NetFlow   exportem.   Má   totiž   vnitřně   určen   limit   65536  exportovaných toků zároveň, což způsobilo v souvislosti s tím, že testované toky dat vznikly téměř zároveň a  také bylo potřeba informace o nich zároveň exportovat, že počet exportů přesáhl tuto hodnotu a exporty byly  zahozeny. V reálném nasazení se dá předpokládat, že toky budou v čase více rozložené a k nárazovému  exportu nebude docházet, v opačném případě bude nutná úprava kódu programu. Zvyšování počtu toků tvoří na rozdíl od zvyšování velikosti paketů jasný impulz pro zvýšení výpočetní  náročnosti u řešení ipt_netflow. Při počtu 500 tisíc toků však vykazuje implementace pouze absolutně o 8.5  procent vyšší zatížení oproti počtu kolem 50ti toků, což je přijatelné. listopad 2009

24/26

 9  Závěr V úvodu práce jsem uvedl motivaci, za jakým účelem provádět analýzu provozu na síti, popsal způsoby,  jak se dají analyzátory zapojit do funkční infrastruktury a vysvětlil podstatu protokolu NetFlow pro export  dat z analyzátorů  Dále jsem vytvořil přehled možností, jak na směrovačích nebo serverech s operačním systémem Linux  provádět různé typy analýz s popisem některých vybraných hotových implementací. V závěru práce jsem se snažil poskytnout podrobnější data z měření výkonu jednotlivých vybraných  řešení pro NetFlow export, aby se mohl případný zájemce o tento typ analýz rozhodnout mezi popsanými  implementacemi. Pro ucelenější porovnání popsaných řešeních by bylo do budoucna možno provést test řešení TNAPI a  FlowMon a pokusit se vytvořil implementaci pro analýzu pomocí libnetfilter_conntrack a Libe1000.

listopad 2009

25/26

 10  Literatura Cisco Systems, Inc.. NetFlow Version 9 Flow­Record Format [online]. 2007 [cit. 2009­11­22]. Dostupný z  WWW:  . Netflow   [online].   2008­2009   ,   26.   3.   2009,   07:34   [cit.   2009­11­22].   Dostupný   z   WWW:  . Modules   [online].   2008   ,   Fri   Dec   19   22:18:35   2008   [cit.   2009­11­22].   Dostupný   z   WWW:  . Message Signaled Interrupts [online]. 2006­2009 , 13:37, 24 September 2009 [cit. 2009­11­22]. Dostupný  z WWW: . Intel Corp.. Intel(R) I/O Acceleration Technology Software Guide for Linux* [online]. 2008 , December  11, 2008 [cit. 2009­11­22]. Dostupný z WWW: . KUBÍČEK, Josef, TŮMA, Miroslav, GRUNTORÁD, Jan. Roční zpráva o řešení výzkumného záměru :  Programovatelný   hardware   [online].   2008   [cit.   2009­11­22].   Dostupný   z   WWW:  . INVEA­TECH   a.s..   FlowMon   sonda   [online].   c2007­2009   [cit.   2009­11­22].   Dostupný   z   WWW:  . ČELEDA, Pavel, NOVOTNÝ, Jiří. Hardware Acceleration of NetFlow Monitoring [online]. [2008] [cit.  2009­11­22]. Dostupný z WWW: . Ntop.org.   Ntop­based   Solutions   [online].   c1998­2009   [cit.   2009­11­22].   Dostupný   z   WWW:  . DERI, Luca. Improving Passive Packet Capture: Beyond Device Polling [online]. [2006] [cit. 2009­11­ 22]. Dostupný z WWW: .

listopad 2009

26/26