View metadata, citation and similar papers at core.ac.uk brought to you by CORE
provided by Digital library of Brno University of Technology
VYSOKEU´ CENˇ ´I TECHNICKE´ V BRNEˇ BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA INFORMACNˇ ´ICH TECHNOLOGI´I USTAV´ INFORMACNˇ ´ICH SYSTEM´ U˚
FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS
NETGRAPH MODUL VE FREEBSD PRO POCˇ ´ITAN´ ´I STATISTIK NETGRAPH MODULE IN FREEBSD FOR TRAFFIC ACCOUNTING
BAKALA´ RSKˇ A´ PRACE´ BACHELOR’S THESIS
AUTOR PRACE´ JAN BLAZEKˇ AUTHOR
VEDOUC´I PRACE´ Ing. RUDOLF CEJKAˇ SUPERVISOR
BRNO 2007
Abstrakt Tato bakal´aˇrsk´apr´acese zab´yv´amodul´arn´ım s´ıt’ov´ymsubsyst´emem Netgraph v j´adˇre operaˇcn´ıhosyst´emu FreeBSD. Netgraph se zde pˇredstavuje z uˇzivatelsk´ehohlediska. Je zde pops´anonˇekolik konkr´etn´ıch modul˚u,n´astroje pro pr´acis Netgraphem a pˇr´ıklady pouˇzit´ı. Souˇc´ast´ıpr´aceje i implementace modulu pro sledov´an´ıs´ıt’ov´ehoprovozu a poˇc´ıt´an´ısta- tistik. V t´eto souvislosti jsou pˇredstaveny i dalˇs´ısubsyst´emy j´adravyuˇz´ıvan´emodulem – zavediteln´emoduly j´adra,mbuf – spr´ava pamˇeti pro meziprocesovou komunikaci v j´adˇre a rozhran´ısysctl pro sd´ılen´ıpromˇenn´ych mezi kernelem a userspace programy.
Kl´ıˇcov´aslova Netgraph, FreeBSD, s´ıt’ov´estatistiky, TCP/IP, Ethernet, KLD, zavediteln´emoduly j´adra, sysctl, mbuf, BSD, UNIX
Abstract This bachelor’s thesis deals with modular kernel networking subsystem Netgraph in Free- BSD operating system. Netgraph is shown from user’s point of view. This work describes several concrete modules, tools for Netgraph management and examples of usage. Part of the work is about implementation of Netgraph module for network traffic accounting. There are described some other kernel subsystems used by the module – kernel loadable modules, mbuf – memory management in kernel interprocess subsystem and sysctl interface for sharing kernel variables with user space programs.
Keywords Netgraph, FreeBSD, network traffic accounting, TCP/IP Ethernet, KLD, kernel loadable module, sysctl, mbuf, BSD, UNIX
Citace Jan Blaˇzek: Netgraph modul ve FreeBSD pro poˇc´ıt´an´ıstatistik, bakal´aˇrsk´apr´ace, Brno, FIT VUT v Brnˇe,2007 Netgraph modul ve FreeBSD pro poˇc´ıt´an´ıstatistik
Prohl´aˇsen´ı Prohlaˇsuji, ˇzejsem tuto bakal´aˇrskou pr´aci vypracoval samostatnˇepod veden´ım pana Ing. Ru- dolfa Cejky.ˇ Uvedl jsem vˇsechny liter´arn´ıprameny a publikace, ze kter´ych jsem ˇcerpal.
...... Jan Blaˇzek 13. kvˇetna2007
Podˇekov´an´ı Dˇekuji Ing. Rudolfu Cejkoviˇ za hodnotn´erady a odborn´eveden´ıbˇehemm´epr´ace.
c Jan Blaˇzek, 2007. Tato pr´ace vznikla jako ˇskoln´ı d´ılo na Vysok´emuˇcen´ı technick´emv Brnˇe,Fakultˇein- formaˇcn´ıch technologi´ı. Pr´ace je chr´anˇenaautorsk´ymz´akonem a jej´ıuˇzit´ıbez udˇelen´ıopr´avnˇen´ı autorem je nez´akonn´e,s v´yjimkou z´akonemdefinovan´ych pˇr´ıpad˚u. Obsah
1 Uvod´ 3
2 Operaˇcn´ısyst´emFreeBSD 4 2.1 UNIX ...... 4 2.2 BSD ...... 4 2.3 FreeBSD ...... 5 2.4 V´yvojov´ymodel a veden´ıprojektu FreeBSD ...... 6 2.5 BSD licence ...... 6
3 S´ıt’ov´ysubsyst´emNetgraph 7 3.1 Co je to Netgraph? ...... 7 3.1.1 Z´akladn´ıpojmy ...... 8 3.1.2 Adresov´an´ı ...... 8 3.2 Pˇr´ıklady modul˚u ...... 10 3.2.1 echo ...... 10 3.2.2 tee ...... 10 3.2.3 iface ...... 10 3.2.4 eiface ...... 10 3.2.5 ether ...... 10 3.2.6 socket ...... 11 3.2.7 ksocket ...... 11 3.3 N´astroje pro pr´acis Netgraphem ...... 11 3.3.1 nghook ...... 11 3.3.2 ngctl ...... 12 3.3.3 libnetgraph ...... 13 3.4 Pˇr´ıklady vyuˇzit´ıNetgraphu ...... 13 3.4.1 UDP tunel ...... 13 3.4.2 Podvrˇzen´ıMAC adresy pomoc´ıNetgraphu ...... 14
4 Dalˇs´ısubsyst´emy vyuˇziteln´epro modul 17 4.1 Moduly j´adra ...... 17 4.2 Mbuf ...... 18
1 4.2.1 Funkce pro manipulaci s mbufy ...... 20 4.3 Sysctl ...... 21
5 Modul pro poˇc´ıt´an´ıstatistik 23 5.1 Inspirace v ng tee ...... 23 5.2 Prvn´ıverze modulu ...... 25 5.3 Rozˇs´ıˇren´ıfunkˇcnosti ...... 26 5.4 Komunikace s uzlem ...... 27
6 Z´avˇer 28 6.1 Srovn´an´ıs podobn´ymimoduly ...... 28 6.1.1 Cisco NetFlow ...... 28 6.2 N´avrhy na rozˇs´ıˇren´ı ...... 28
Seznam pouˇzit´ych zdroj˚u 31
Seznam pˇr´ıloh 32
A BSD licence 33
B N´avod pro pˇreklad a instalaci modulu 35
C N´avod k pouˇzit´ımodulu 36 C.0.1 Kontroln´ızpr´avy ...... 36 C.0.2 SYSCTL ...... 37
2 Kapitola 1
Uvod´
Pˇri spr´avˇepoˇc´ıtaˇcov´es´ıtˇeje d˚uleˇzit´evˇedˇet,co se v s´ıti dˇeje,jak´ytyp dat a jak´emnoˇzstv´ıdat teˇce pˇresnaˇseservery. Kdyˇzv´ıme, co se v s´ıtidˇeje,m˚uˇzeme dˇelatspr´avn´arozhodnut´ı.Tato pr´ace se zab´yv´an´avrhem a implementac´ıjadern´ehomodulu, kter´ym˚uˇzeb´ytpouˇzitpro sledov´an´ıs´ıt’ov´ehotoku. Modul m´asp´ıˇse jen z´akladn´ıfunkˇcnost a pro re´aln´enasazen´ı, by bylo vhodn´eho d´alerozˇs´ıˇrit.D˚uraz v pr´acije kladen zejm´enana sezn´amen´ıse s Netgraphem, s jehoˇzpomoc´ıje modul vytvoˇren.D´alejsou pops´any i dalˇs´ıoblasti, kter´es t´ımto modulem bezprostˇrednˇesouvis´ı. Kapitola 2 struˇcnˇepojedn´av´ao historii operaˇcn´ıhosyst´emu FreeBSD a o jeho pˇredch˚ud- c´ıch BSD a UNIXu. Je zde pops´anv´yvojov´ymodel projektu FreeBSD a je zde pˇrestavena hlavn´ılicence operaˇcn´ıch syst´em˚uBSD – BSD licence. Kapitola 3 se zab´yv´asamotn´ym Netgraphem. Netgraph je pˇredstaven z uˇzivatelsk´eho hlediska, jsou zde vysvˇetleny z´akladn´ıpojmy a pops´any nˇekter´emoduly a n´astroje pro pr´aci s Netgraphem. Pˇripraveny jsou i dva pˇr´ıklady vyuˇzit´ıNetgraphu. V kapitole 4 jsou pˇredstaveny dalˇs´ıjadern´esubsyst´emy vyuˇziteln´epro modul na poˇc´ıt´an´ı statistik. Z trochu ˇsirˇs´ıho pohledu jsou uvedeny moduly j´adra.D´ale je zde pˇredstavena spr´ava pamˇetipro meziprocesovou komunikaci v j´adˇrea rozhran´ısysctl pro sd´ılen´ıpromˇen- n´ych mezi j´adrem a userspace programy. V pˇredposledn´ıkapitole 5 je pops´ann´avrh a implementace modulu pro vytv´aˇren´ıstatis- tik. Jsou zde uvedena sch´emata hlaviˇcek nˇekolika s´ıt’ov´ych protokol˚ua zde pops´anprincip jejich zkoum´an´ımodulem. Z´avˇereˇcn´akapitola 6 srovn´av´amodul s podobn´ymisyst´emy a pˇredkl´ad´an´avrhy na rozˇs´ıˇren´ımodulu.
3 Kapitola 2
Operaˇcn´ısyst´emFreeBSD
M´ame-li si povˇedˇetnˇeco o historii operaˇcn´ıho syst´emu FreeBSD, mus´ıme zaˇc´ıt od jeho koˇren˚u.
2.1 UNIX
Poˇc´atkyUNIXu m˚uˇzeme datovat do roku 1969. Tenkr´atvznikl v hlavˇeKenna Thompsona v AT&T Bell Laboratories n´apad vytvoˇrit nov´yoperaˇcn´ısyst´em.Z´ahy se k nˇemu pˇripojil Dennis Ritchie, autor jazyka C. Vˇetˇsina syst´emu byla pˇreps´anaz ˇcist´ehoassembleru do ja- zyka C, coˇzumoˇznilo jeho pozdˇejˇs´ıexpanzi na spoustu r˚uzn´ych platforem. Ritchie, Thomp- son a dalˇs´ıv´yvoj´aˇrip˚uvodnˇepracovali na v´yvoji operaˇcn´ıho syst´emu Multics, ze kter´eho byla pˇrejata ˇrada myˇslenek a koncept˚u.V´yvoj Multicsu byl velice rozs´ahl´ya n´akladn´ypro- jekt, kter´yse zhroutil pod vlastn´ıvahou. V´yvoj´aˇriUNIXu se vˇsak nechtˇelivzd´atmoˇznost´ı kter´ejim Multics jako v´ıce´ulohov´yoperaˇcn´ısyst´em nab´ızel v dobˇe,kdy byly st´alebˇeˇzn´e syst´emy s d´avkov´ymzpracov´an´ım ´uloh. N´azev UNIX je reakc´ı na Multics; v oblastech, kde se Multics snaˇzilprov´adˇet mnoho ´uloh, UNIX mˇel prov´adˇetpouze jednu akci, ale zato dobˇre.Dalˇs´ım pˇredkem UNIXu byl CTSS (Compatilbe Time-Sharing System), pˇredch˚udce Multicsu vyv´ıjen´yna MIT v Bostonu. [6, 5]
2.2 BSD
Syst´emBSD je ´uzce spjat s Kalifornskou Univerzitou v Berkeley. P˚uvodn´ıdistribuce UNIXu ze 70. let obsahovaly zdrojov´ek´odysyst´emu a byly za pˇr´ızniv´ych podm´ınek dostupn´ehlavnˇe pro univerzity. Software z Berkeley byl vyd´av´anv takzvan´ych Berkeley Software Distribuc´ıch (odtud zkratka BSD). P˚uvodnˇeto nebyl cel´yoperaˇcn´ısyst´em, ale sp´ıˇse rozˇs´ıˇren´ık UNIXu. Prvn´ı verze 1BSD (1977) byla doplˇnkem k ˇsest´eedici UNIXu a jej´ımihlavn´ımi komponenty byly pˇrekladaˇcjazyka Pascal a ˇr´adkov´yeditor ex.
4 Druh´averze 2BSD obsahovala aktualizace program˚uz 1BSD a dva nov´e,v UNIXu dodnes zn´am´e,programy; editor vi (vizu´aln´ırozhran´ık editoru ex) a C shell. Pr´ace na verzi 3BSD byly ve znamen´ıportov´an´ısyst´emu z architektury PDP-11 na VAX. Port na tuto architekturu sice jiˇzexistoval, byl j´ımUNIX/32V od Bellov´ych laboratoˇr´ı,ale ten nevyuˇz´ıval moˇznost´ıvirtu´aln´ıpamˇetiVAXu. J´adro 32V bylo z velk´eˇc´astipˇreps´ano studenty z Berkeley a tato pr´acesi z´ıskala pomˇernˇedobr´euzn´an´ı. Uspˇech´ 3BSD zapˇr´ıˇcinil to, ˇzegrantov´aagentura ministerstva obrany USA DARPA (Defense Advanced Research Projects Agency) se rozhodla dotovat t´ymz Berkeley, aby tak podpoˇrila jeho dalˇs´ıv´yvoj. C´ılemprojektu 4BSD bylo vytvoˇritpodporu pro internetov´y protokol TCP/IP, kter´yvzeˇsel pr´avˇeod DARPY. N´asledovaly verze 4.1, 4.2, 4.3. Ve verzi 4.2 byla v roce 1983 uvolnˇenaimplementace protokolu TCP/IP a byla tak v´yraznˇepos´ılenapodpora s´ıt´ıv syst´emu UNIX, kter´anebyla do t´edoby nijak zvl´aˇstˇerozvinut´a. Do doby verze 4.3 obsahovaly distribuce BSD k´odz AT&T UNIXu a vyˇzadovaly tak vlastnictv´ı jeho licence. Tato licence vˇsakbyla pomˇernˇedrah´aa vznikala popt´avka po rozˇs´ıˇren´ıch BSD (hlavnˇes´ıt’ov´emk´odu) bez tˇechto omezen´ı.Reakc´ıbylo vyd´an´ıNetworking Release (Net/1) v roce 1989, kter´ebylo uvolnˇeno pod BSD licenc´ı. Po verzi Net/1 se v´yvoj´aˇrKeith Bostic zam´yˇslel vydat vˇetˇs´ıˇc´astsyst´emu pod BSD licenc´ı.Zaˇcal tedy znovu implementovat nˇekter´en´astroje bez pouˇzit´ık´odu poch´azej´ıc´ıho z AT&T. Napˇr´ıklad editor vi, kter´yobsahoval k´odz licencovan´eho editoru ed, byl pˇreps´an jako nvi. Po jednom a p˚ulroce, byl pˇreps´anskoro vˇsechen k´odod AT&T kromˇenˇekolika zdrojov´ych soubor˚ukernelu. Ty byly vyjmuty a byla uvolnˇenadistribuce Net/2 jako t´emˇeˇr kompletn´ıoperaˇcn´ısyst´em. Syst´emNet/2 byl z´akladem ke dvˇema port˚um na architekturu Intel 80386. Byly to nekomerˇcn´ı386BSD od Williama Jolitze a propriet´arn´ıBSD/386 (pozdˇejipˇrejmenov´anna BSD/OS) od Berkeley Software Design (BSDi). Syst´em 386BSD byl z´akladempro projekty NetBSD a FreeBSD. [11]
2.3 FreeBSD
FreeBSD projekt se vyvinul v roce 1993 z neofici´aln´ıch rozˇs´ıˇren´ık 386BSD. V roce 1994 byl ukonˇcensoudn´ıspor ohlednˇevlastnictv´ıpr´avk ˇc´astemNet/2 mezi Univerzitou v Ber- keley a firmou Novell, kter´aje koupila od AT&T. Pr´ava byla pˇrizn´ana spoleˇcnosti Novell a uˇzivatel˚umNet/2 bylo doporuˇceno pˇrej´ıt k 4.4BSD-Lite, coˇzbyla verze, ze kter´ebyl d˚uslednˇeodstranˇen k´odod AT&T a chybˇelyv n´ıvelk´ekusy k´odu, kter´ebyly potˇrebapro sestaven´ıfunkˇcn´ıhosyst´emu. Projekt FreeBSD musel tedy zaˇc´ıt vyv´ıjetpodstatnou ˇc´ast znovu z k´odu4.4BSD-Lite. [9, kap. 1.3]
5 2.4 V´yvojov´ymodel a veden´ıprojektu FreeBSD
Pˇri snaze pochopit jak se projekt FreeBSD vyv´ıj´ıa jak vznik´asi mus´ımeuvˇedomitnˇekter´e aspekty v´yvoje opensource softwaru. Oproti v´yvoj´aˇr˚umpropriet´arn´ıch syst´em˚ujsou v´yvoj´aˇri FreeBSD ˇcasto pouze dobrovoln´ıci, nejsou (aˇzna nˇekter´ev´yjimky) za odvedenou pr´aci pla- ceni a ˇcasto programuj´ıhlavnˇepro z´abavu ve sv´emvoln´em ˇcase. Kompletn´ı zdrojov´ek´ody syst´emu vˇcetnˇedokumentace, hl´aˇsen´ı o chyb´ach a archiv pˇr´ıspˇevk˚una mailing-listu je veˇrejnˇedostupn´ypˇres syst´emspr´avyverz´ıCVS. Pr´ava k z´apisu do tˇechto repozit´aˇr˚um´avˇsakpouze omezen´yokruh lid´ı,tzv. commiters. V´yvoj´aˇri,kter´ych je v souˇcasnosti cca 3000-4000, musej´ı spolupracovat s nˇekter´ymz 300-400 commiter˚u, jestliˇzechtˇej´ı,aby se jimi navrhovan´ezmˇeny prom´ıtly do syst´emu. Stejnˇejako v´yvoj´aˇri se i commiters vˇetˇsinou specializuj´ına nˇekterou ˇc´astsyst´emu. Vˇsechny rozs´ahl´ezmˇeny by mˇely b´yt ovˇeˇreny v´ıcecommitery, neˇzbudou zaneseny do zdrojov´ehostromu. V hierarchii v´yˇs nad commitery je uˇzjen tzv. core team. Clenov´et´etouˇzˇs´ıskupinyˇ (v souˇcasnosti 9 lid´ı) jsou voleni kaˇzd´edva roky. Jejich ´ukolem je pˇrij´ım´an´ız´avaˇznˇejˇs´ıch rozhodnut´ı, ˇreˇsen´ıspor˚u dvou nebo v´ıcecommiter˚ua pˇrij´ım´an´ınov´ych commiter˚u. V´yvoj prob´ıh´aparalelnˇeve dvou vˇetv´ıch: FreeBSD-STABLE a FreeBSD-CURRENT. Vˇetev FreeBSD-STABLE je zam´yˇslena jako stabiln´ı a prom´ıtaj´ı se do n´ı pouze zmˇeny, kter´eopravuj´ıchyby a pˇrid´avaj´ıpodporu pro nov´yhardware. Stabiln´ıvˇetev je ˇcas od ˇcasu vyd´av´ana jako RELEASE“ a je uvolnˇenav podobˇeISO obraz˚uk vyp´alen´ına CD. Aktivn´ı ” v´yvoj a pˇrid´av´an´ınov´ych moˇznost´ıprob´ıh´ave vˇetvi CURRENT. Pˇribliˇznˇekaˇzd´edva roky se vˇetev CURRENT rozdvoj´ı,aby se zformovala nov´avˇetev STABLE.
2.5 BSD licence
Aˇckoliv jsou ˇc´asti syst´emu licencov´any pod r˚uzn´ymilicencemi, preferovanou licenc´ı pro j´adro a syst´emov´en´astroje je BSD licence. BSD licence samotn´am´asv˚uj p˚uvod na univer- zitˇev Berkeley. Text t´etolicence je uveden v pˇr´ıloze A. BSD licence je velmi volnou licenc´ı, oproti GNU GPL neobsahuje ˇz´adn´aomezen´ı, kromˇetoho, ˇze s´ıˇren´eodvozen´ed´ılo (at’ uˇzv bin´arn´ı nebo zdrojov´eformˇe)mus´ı obsa- hovat informaci o autorech, o licenci a bˇeˇzn´ezˇreknut´ıse odpovˇednosti za d´ılo.BSD licence umoˇzˇnuje komerˇcn´ı vyuˇzit´ı vˇcetnˇevyuˇzit´ı bez zveˇrejnˇen´ı zdrojov´ych k´od˚u.Nˇekdyb´yv´a vtipnˇeoznaˇcov´ana jako copycenter:
Existuje copyright, kter´yzakazuje ˇs´ıˇren´ıd´ıla, copyleft, kter´ynaopak zakazuje omezov´an´ıˇs´ıˇren´ıd´ıla a BSD licenci nazvˇeme copycenter, coˇzznamen´a Vezmˇete ” si to do copycentra a udˇelejtesi kopi´ıkolik chcete.“ [10]
6 Kapitola 3
S´ıt’ov´ysubsyst´em Netgraph
3.1 Co je to Netgraph?
Netgraph je modul´arn´ıs´ıt’ov´ysubsyst´emimplementovan´ypˇr´ımov j´adˇre operaˇcn´ıhosyst´emu FreeBSD. Ukolem´ Netgraphu nen´ınahradit existuj´ıc´ıs´ıt’ovou infrastrukturu v j´adˇre,ale sp´ıˇsese s n´ıdoplˇnovat a nab´ıdnout v´yvoj´aˇr˚umnov´emoˇznosti [2]:
• flexibiln´ızp˚usobkombinov´an´ıprotokol˚ua ovladaˇc˚us´ıt’ov´ych zaˇr´ızen´ı
• zp˚usobjak modul´arnˇeimplementovat nov´eprotokoly
• spoleˇcnouplatformu pro vz´ajemnou komunikace objekt˚uv kernelu
• efektivn´ıimplementaci v kernelu
Netgraph navrhli a poprv´eimplementovali v´yvoj´aˇri Archie Cobbs a Julian Elischer roku 1996 ve firmˇeWhistle Communications, Inc. ve verzi FreeBSD 2.2 modifikovan´epro zaˇr´ızen´ı Whistle InterJet. Jednalo se o server urˇcen´ypro menˇs´ıkancel´aˇre a dom´acnostik pˇripojen´ı do internetu a poskytov´an´ısluˇzeb jako e-mail, VPN, firewall, souborov´yserver apod.[1] Do ofici´aln´ıho stromu se Netgraph dostal poprv´eve verzi FreeBSD 3.4. V n´avrhu Netgraphu lze pomˇernˇesnadno rozeznat ovlivnˇen´ıunixovou filosofi´ı.M´ısto nˇejak´eho sloˇzit´eho robustn´ıho syst´emu je k dispozici cel´asada nˇekolika relativnˇejedno- duch´ych n´astroj˚u, kter´eprov´adˇej´ı jednoduch´epˇresnˇedefinovan´eoperace. D´ıky tomu se tento syst´emd´ajednoduˇse pˇrizp˚usobit a lze s n´ımprov´adˇetvˇeci, na kter´ep˚uvodn´ın´avrh´aˇri tˇrebaani nepomysleli. Tˇemiton´astroji jsou uzly (nodes), kter´ejsou pomoc´ı hran spojov´any do vˇetˇs´ıch celk˚u, graf˚u. Pod´elhran se ˇs´ıˇr´ı data, kter´ajsou zpracov´anav uzlech, napˇr. pˇrid´av´an´ımˇci odeb´ır´an´ımhlaviˇcek paket˚um pˇriimplementaci r˚uzn´ych protokol˚u.
7 3.1.1 Z´akladn´ıpojmy
V t´eto podkapitole si objasn´ımez´akladn´ıpojmy jako uzly, hrany, kontroln´ızpr´avy.
Uzel
Z´akladn´ıjednotkou v Netgraphu je uzel. Uzly zpracov´avaj´ıdata, kter´apˇres nˇeteˇcou, napˇr. pˇrid´avaj´ınebo odeb´ıraj´ıhlaviˇckyr˚uzn´ych protokol˚u.Uzly tak´emohou b´ytzdrojem nebo c´ılemdat v pˇr´ıpadˇe, ˇzejsou asociov´any pˇr´ımos hardware nebo s jin´ymi ˇc´astmi s´ıt’ov´ehosub- syst´emu. Vˇsechny uzly maj´ınˇekolik spoleˇcn´ych pˇreddefinovan´ych metod, kter´ejim umoˇzˇnuj´ı komunikovat s ostatn´ımi uzly. Kaˇzd´yuzel patˇr´ık nˇejak´emu typu. Typ urˇcuje chov´an´ıuzlu a zp˚usob pˇripojen´ık ostatn´ım uzl˚um. Nab´ız´ıse paralela s objektovˇeorientovan´ymprogramov´an´ım. Typ m˚uˇzeme ch´apat jako tˇr´ıdu, kter´aje odvozen´aod hlavn´ıtˇr´ıdya dˇed´ıtak rysy spoleˇcn´epro vˇsechny uzly. Uzel je instanc´ıtypu (tˇr´ıdy). Typ uzlu je pops´anjednoznaˇcn´ych ASCII n´azvem. Uzlu je v dobˇejeho vytvoˇren´ıpˇridˇelena jednoznaˇcn´aadresa, kter´aje tvoˇrena32-bitov´ymˇc´ıslem (ID number). Nav´ıc m˚uˇze b´ytuzel pro vˇetˇs´ıpˇrehlednost a usnadnˇen´ıpr´acepojmenov´an ASCII n´azvem. N´azev nesm´ıobsahovat znaky ‘.’ nebo ‘:’ a jeho d´elka je implementaˇcnˇe omezen´ana NG_NODESIZ (vˇcetnˇeukonˇcovac´ıho znaku nula). Spojen´ımp´aru h´ak˚uvznikne hrana. Data teˇcou obousmˇernˇemezi uzly pod´el hran tvoˇren´ych p´aremh´ak˚u.Uzel m˚uˇzem´ıt libovoln´ypoˇcet h´ak˚u. Kaˇzd´yh´akm´asv˚uj ASCII n´azev, kter´yje jednoznaˇcn´yv r´amci uzlu. N´azev nesm´ı podobnˇejako u n´azvuuzlu obsahovat znaky ‘.’ a ‘:’ a jeho d´elka je omezen´ana NG_HOOKSIZ znak˚u(vˇcetnˇeukonˇcovac´ıho znaku nula). H´akje vˇzdypˇripojen k nˇejak´emu jin´emu h´aku a vznik´aatomicky aˇzv dobˇevytv´aˇren´ıhrany. Odstranˇen´ıh´akuna jedn´estranˇespoje m´a za n´asledek odstranˇen´ıcel´ehrany i s protilehl´ymh´akem. Pro h´akym˚uˇzou b´ytdefinov´any vlastn´ımetody pro pˇr´ıjemdat a kontroln´ıch zpr´av.Dojde tak k pˇret´ıˇzen´ı“obecn´ych metod ” pro dan´yuzel.
Kontroln´ızpr´avy
Ke komunikaci s uzly, k jejich konfiguraci a zjiˇst’ov´an´ıstavu se pouˇz´ıvaj´ıkontroln´ızpr´avy. Vˇsechny uzly rozumˇej´ız´akladn´ımkontroln´ım zpr´av´am,kter´ejsou souˇc´ast´ıimplementace Netgraphu. Tv˚urce modulu m˚uˇze navrhnout vlastn´ızpr´avyspecifick´epro vytv´aˇren´yuzel. Zpr´avyjsou z d˚uvodu efektivnosti v bin´arn´ım form´atu, ale vˇetˇsinouje nav´ıcdefinov´ani textov´yform´at,kter´yje vhodnˇejˇs´ıpro ladˇen´ıa pouˇzit´ıv uˇzivatelsk´ych rozhran´ıch. Vˇsechny zpr´avy jsou opatˇreny 32-bitovou hodnotou naz´yvanou typecookie, kter´aznaˇc´ıtyp zpr´avy. Kaˇzd´ytyp uzlu, kter´yrozum´ıdan´ezpr´avˇe, m´adefinovanou stejnou hodnotu typecookie.
3.1.2 Adresov´an´ı
Netgraph nab´ız´ı pˇrehledn´yzp˚usobjak adresovat konkr´etn´ı uzel v grafu. Kaˇzd´yuzel je dostupn´ypˇresadresu, kter´am´atyp ˇretˇezce ASCII znak˚u.Je nutn´epoznamenat, ˇze toto
8 adresov´an´ıje pouˇziteln´epouze pro zas´ıl´an´ıkontroln´ıch zpr´av. Vˇsechny uzly v grafu maj´ıunik´atn´ıID (ID number). Uzavˇren´ımtohoto ˇc´ıslav hexade- cim´aln´ımtvaru do hranat´ych z´avorek a pˇrid´an´ımdvojteˇckyna konec dostaneme platnou adresu konkr´etn´ıhouzlu. Napˇr´ıklad uzel s ID ˇc´ıslem 38f m˚uˇzeme adresovat jako ,,[38f]:”. Nˇekter´euzly maj´ı jm´ena. Uzly spojen´es hardwarov´ymzaˇr´ızen´ım maj´ı v netgraphu typicky jm´enodan´ehozaˇr´ızen´ı. Napˇr´ıklad uzel asociovan´ys ethernetov´ymadapt´erem ,,em0” m´aadresu ,,em0:”. Adresy mohou b´yti sloˇzitˇejˇs´ıneˇzpouh´ejm´enonebo ID ˇc´ıslouzlu, nav´ıcse adresy dˇel´ına absolutn´ıa relativn´ı.Absolutn´ıadresa zaˇc´ın´ajm´enemnebo ID ˇc´ıslem uzlu, d´alen´asleduje dvojteˇcka, za n´ıposloupnost h´ak˚uoddˇelen´ateˇckami. Relativn´ıadresa obsahuje pouze se- znam h´ak˚uoddˇelen´ych teˇckami. Cesta pak zaˇc´ın´av uzlu, ze kter´ehose odkazujeme. Pro n´azornost si uvedeme nˇekolik pˇr´ıklad˚u. Uvaˇzujmeobr´azek 3.1, na uzel ngeth0 se m˚uˇzeme odk´azat napˇr´ıklad tˇemitoadresami: ngeth0: mybridge:link3 bfe0:lower.link0 [5c8]: [5c4]:upper.link3 mybridge:link2.lower.link3
mybridge: bridge [5cc]:
ngeth0: bfe0: link3 link0 link2 link1 ether [5c8]: ether [5c4]:
upper lower upper lower
Obr´azek 3.1: Pˇr´ıklad k adresov´an´ı
9 3.2 Pˇr´ıkladymodul˚u
Nyn´ısi uvedeme nˇekolik pˇr´ıklad˚ukonkr´etn´ıch netgraphov´ych modul˚u(resp. typ˚u),kter´e jsou implementov´any ve FreeBSD. U kaˇzd´ehopop´ıˇseme pouze z´akladn´ıchov´an´ıa moˇznosti vyuˇzit´ı.Podrobnˇejˇs´ıinformace lze nal´ezt v manu´alov´ych str´ank´ach k pˇr´ısluˇsn´ymmodul˚um.
3.2.1 echo
Modul ng_echo(4) pos´ıl´azpˇet odes´ılatelivˇsechny kontroln´ızpr´avy a data, kter´ek nˇemu dorazily. Tento modul je pouˇziteln´yzejm´ena k testov´an´ıa ladˇen´ı.
3.2.2 tee
Modul ng_tee(4) funguje podobnˇejako pˇr´ıkaz tee(1). Chov´ase jako rozdvojka, ale na rozd´ıl od jej´ıhoshellov´eho ekvivalentu je oboustrann´a.Tee uzly maj´ıˇctyˇrih´aky:left, right, left2right a right2left. Vˇsechna data, kter´adoraz´ına h´akleft, jsou posl´anana h´akyright a left2right. Obdobnˇez right na left a right2left. D´alepak data z uzlu right2left (resp. left2right) teˇcou v nezmˇenˇen´epodobˇena h´akyright (resp. left). Uzel typu tee se hod´ı zejm´enak ladˇen´ınebo odposlouch´av´an´ı“spojen´ımezi dvˇema uzly. Za zm´ınku stoj´ıi to, ” ˇzeuzel si pro jednotliv´eh´akyvytv´aˇr´ıstatistiku o poˇctudatov´ych zpr´av(paket˚u)a jejich celkov´evelikosti pro smˇer toku ven i dovnitˇruzlu.
3.2.3 iface
Vytvoˇren´ımuzlu typu iface vznikne virtu´aln´ıs´ıt’ov´erozhran´ıtypu point-to-point. To je dosaˇziteln´ejednak z Netgraphu jako uzel, ale i jako klasick´es´ıt’ov´erozhran´ıpˇres syst´emov´y n´astroj ifconfig(8). Rozhran´ıjsou pojmenov´anajako ng0, ng1, atd. Uzly tohoto typu maj´ıh´akyodpov´ıdaj´ıc´ıjednotliv´ymprotokol˚um(inet, inet6, ipx, atalk, atm, . . . ). Pakety, kter´edoraz´ına s´ıt’ov´erozhran´ıse objev´ına h´akupˇr´ısluˇsn´ehoprotokolu a data poslan´ana h´akznaˇc´ıc´ıurˇcit´yprotokol poˇsle rozhran´ıdo s´ıtˇejako pakety dan´eho protokolu.
3.2.4 eiface
Podobnˇejako ng_iface(4) i modul ng_eiface(4) vytv´aˇr´ıvirtu´aln´ıs´ıt’ov´erozhran´ıs t´ım rozd´ılem, ˇze se jedn´ao ethernetov´erozhran´ı.Rozhran´ıjsou pojmenov´anan´azvyngeth0, ngeth1, atd.
3.2.5 ether
Modul ng_ether(4) umoˇzn´ıs´ıt’ov´ymethernetov´ymrozhran´ımobjevit se v Netgraphu jako uzly, kter´ejsou pojmenov´any stejnˇejako jim pˇr´ısluˇsej´ıc´ıethernetov´arozhran´ı. Uzly typu ether maj´ıh´aky lower, upper a orphans. H´ak lower slouˇz´ık pˇr´ım´emu spojen´ıs ethernetov´ym rozhran´ım.Kdyˇzje pˇripojen, jsou na nˇejdoruˇceny vˇsechny pˇr´ıchoz´ıpakety ze s´ıtˇe.Z´apis dat
10 na tento h´akzp˚usob´ıjejich odesl´an´ıdo s´ıtˇe.H´ak upper vytv´aˇr´ıspojen´ıs horn´ımi vrstvami s´ıt’ov´ehostacku. Po jeho pˇripojen´ıjsou na nˇej pos´ıl´any vˇsechny odchoz´ıpakety, m´ısto aby byly vys´ıl´any pˇr´ımos´ıt’ov´ymadapt´erem. Z´apis na tento h´akzp˚usob´ı, ˇze data budou pˇrijata jako ethernetov´yr´amec j´adrem OS, tak jako by se jednalo o data ze s´ıtˇe. H´ak orphans se chov´apodobnˇejako lower s t´ımrozd´ılem,ˇze na jeho v´ystupu se objev´ıpouze pakety, u kter´ych nebyl rozpozn´anjejich typ (tj. j´adro OS si s nimi neum´ıporadit). Kdyˇznejsou ˇz´adn´eh´aky pˇripojeny, uzel se chov´atak, jako by byly h´aky lower a upper spojeny.
3.2.6 socket
Modul ng_socket(4) implementuje uzly, kter´ejsou z´aroveˇnuzly netgraphu a z´aroveˇnp´arem soket˚uz rodiny PF_NETGRAPH. Jeden soket je pouˇzit pro data a druh´ypro kontroln´ızpr´avy. Uzel netgraphu je vytvoˇrenv dobˇevytv´aˇren´ısoket˚uv userspace programu. Pˇr´ıklad takov´eho vytvoˇren´ısoket˚u: int s1, s2; s1 = socket(PF_NETGRAPH, SOCK_DGRAM, NG_CONTROL); s1 = socket(PF_NETGRAPH, SOCK_DGRAM, NG_DATA);
3.2.7 ksocket
Modul ng_ksocket(4) vytv´aˇr´ıuzly, kter´ejsou z´aroveˇnBSD sokety a z´aroveˇnuzly netgra- phu. Avˇsak v tomto pˇr´ıpadˇejde o obr´acenouverzi ng_socket. Tento modul n´amumoˇzn´ı vytvoˇritBSD soket pˇr´ımov kernelu a nav´azatspojen´ıs procesem, kter´ybˇeˇz´ılok´alnˇena stejn´emstroji, nebo s jin´ymstrojem pˇres s´ıt’. Uzel akceptuje kontroln´ı zpr´avy connect, accept, listen, bind apod., kter´emaj´ıstejn´yv´yznam jako pˇripouˇzit´ı socket(2).
3.3 N´astroje pro pr´acis Netgraphem
V t´eto sekci si pop´ıˇseme programov´en´astroje, kter´eslouˇz´ık vytv´aˇren´ıgrafu a ke komunikaci s uzly. D´ale si pˇredvedeme nˇekter´etechniky, kter´esice nejsou nezbytnˇenutn´e,ale v´yraznˇe n´amzjednoduˇs´ıpr´aci.
3.3.1 nghook
N´astroj nghook(8) se pˇripoj´ına nepˇripojen´yh´akuzlu v grafu a umoˇzn´ıpˇrij´ımata vys´ılat pakety pˇresstandardn´ıvstup a v´ystup. V´ystup m˚uˇze b´ytdek´odov´ando ˇciteln´ehoASCII form´atu. Napˇr´ıklad pokud si chceme nechat zobrazit v ASCII form´atunerozpoznan´epakety ze s´ıt’ov´ehoadapt´eru bfe0, pouˇzijeme pˇr´ıkaz: nghook -a bfe0: orphans
K propojen´ınetgraphu, kter´ybˇeˇz´ıv kernelu, s procesem nghook v uˇzivatelsk´emprostoru je pouˇzit uzel typu socket (ng_socket(4)).
11 3.3.2 ngctl
Program ngctl(8) vytvoˇr´ıuzel typu socket. Pˇresnˇej jsou uzl˚um zas´ıl´any kontroln´ızpr´avy a z´ısk´av´any informace o uzlech. Tento program s rozhran´ım pˇr´ıkazov´eˇr´adky m˚uˇzeb´yt jednak pouˇzit v interaktivn´ımm´odu, ale tak´ev shellov´ych skriptech napˇr´ıkladpro d´avkov´e vytvoˇren´ıjiˇznavrˇzen´ehosch´ematu grafu. V´ypisnejd˚uleˇzitˇejˇs´ıch pˇr´ıkaz˚u: connect Spoj´ıp´arh´ak˚u,aby se vytvoˇrila hrana. dot Vyp´ıˇse cel´ygraf ve form´atuGraphViz (.dot). help Zobraz´ıseznam pˇr´ıkaz˚unebo podrobnou n´apovˇedu pro specifick´ypˇr´ıkaz. list Zobraz´ıinformace o vˇsech uzlech v grafu. mkpeer Vytvoˇr´ınov´yuzel a pˇripoj´ıho na existuj´ıc´ıuzel. msg Zaˇsle kontroln´ızpr´avuvybran´emu uzlu. name Pˇriˇrad´ıuzlu jm´eno. rmhook Rozpoj´ıdva uzly, kter´ejsou spojen´e. show Zobraz´ıinformace o dan´emuzlu. shutdown Pˇreruˇs´ıvˇsechny hrany a odstran´ıuzel. types Zobraz´ıinformace o pr´avˇenainstalovan´ych typech. quit Ukonˇc´ıprogram.
Pˇr´ıkaz mkpeer m´ana rozd´ılod ostatn´ıch pˇr´ıkaz˚usloˇzitˇejˇs´ısyntaxi, kter´anemus´ıb´ytna prvn´ıpohled zˇrejm´a. pouˇzit´ı:mkpeer [cesta]:
Pˇr´ıkaz vytvoˇr´ınov´yuzel typu typ“ a pˇripoj´ıho na uzel na adrese cesta“. H´akyurˇcen´eke ” ” spojen´ıjsou h´ak1“ na p˚uvodn´ım uzlu a h´ak2“ na novˇevytvoˇren´emuzlu. ” ”
Za povˇsimnut´ıstoj´ıpˇr´ıkaz dot, kter´yprodukuje v´ystuppro sadu program˚uGraphViz. Po nainstalov´an´ıt´etosady z bin´arn´ıhobal´ıˇcku pˇr´ıkazem:
# pkg_add -r graphviz pˇr´ıpadnˇekompilac´ıa instalac´ız port˚u:
# cd /usr/ports/graphics/graphviz # make install clean n´amn´asleduj´ıc´ıpˇr´ıkaz zobraz´ısch´ema grafu v grafick´epodobˇe.
# ngctl dot | dotty -
V bal´ıku graphviz je v´ıceuˇziteˇcn´ych program˚upro pr´acis t´ımto form´atem. Za zm´ınku stoj´ı alespoˇn dot, kter´yum´ımimo jin´eexport do PostScriptu. Takto byly vytvoˇreny i obr´azky graf˚uv t´eto pr´aci.
12 3.3.3 libnetgraph
Dalˇs´ımprostˇredkem pro komunikaci userspace proces˚us moduly netgraphu je knihovna libnetgraph(3). Je to knihovna napsan´av jazyce C a implementuje funkce nutn´eke spr´avˇe netgraphu. Samotn´akomunikace s netgraphem prob´ıh´apomoc´ı modulu ng_socket(4). Prostˇredky t´etoknihovny vyuˇz´ıvaj´ıpr´avˇen´astroje ngctl(8) a nghook(8).
3.4 Pˇr´ıkladyvyuˇzit´ıNetgraphu
V adres´aˇri /usr/share/examples/netgraph nalezneme pˇr´ıklady vyuˇzit´ıNetgraphu.
3.4.1 UDP tunel
Pop´ıˇseme si skript, kter´ym´aza ´ukol vytvoˇrittunel mezi dvˇema pods´ıtˇemi. Vyuˇz´ıv´ase v nˇemtunelov´an´ıIP protokolu pˇresUDP spojen´ı. Pˇrepis skriptu s ˇcesk´ymikoment´aˇri:
#!/bin/sh
# Definice adres lok´aln´ıa vzd´alen´evnitˇrn´ıs´ıtˇe, # definice vnˇejˇs´ıchadres a ˇc´ısloUDP portu, # kter´ybude pouˇzitpro tunel. # LOC_INTERIOR_IP=192.168.1.1 LOC_EXTERIOR_IP=1.1.1.1 REM_INTERIOR_IP=192.168.2.1 REM_EXTERIOR_IP=2.2.2.2 REM_INSIDE_NET=192.168.2.0 UDP_TUNNEL_PORT=4028
# Vytvoˇr´ıuzel rozhran´ı‘‘ng0’’, jestliˇzedosud neexistuje, # jinak se pouze ujist´ı,zda nen´ık nˇeˇcemupˇripojen. if ifconfig ng0 >/dev/null 2>&1; then ifconfig ng0 inet down delete >/dev/null 2>&1 ngctl shutdown ng0: else ngctl mkpeer iface dummy inet fi
# Pˇripojen´ıUDP soketu k h´aku‘‘inet’’ uzlu rozhran´ıza pouˇzit´ıuzlu # typu ng_ksocket(4). # ngctl mkpeer ng0: ksocket inet inet/dgram/udp
13 # Sv´aˇze(bind) UDP soket s lok´aln´ıvnˇejˇs´ıIP adresou a portem. # ngctl msg ng0:inet bind inet/${LOC_EXTERIOR_IP}:${UDP_TUNNEL_PORT}
# Propoj´ıUDP soket se vzd´alenouvnˇejˇs´ıIP adresou a portem. # ngctl msg ng0:inet connect inet/${REM_EXTERIOR_IP}:${UDP_TUNNEL_PORT}
# Nakonfiguruje rozhran´ıtypu point-to-point. # ifconfig ng0 ${LOC_INTERIOR_IP} ${REM_INTERIOR_IP}
# Vloˇz´ız´aznamdo routovac´ıtabulky, tak aby spojen´ıdo vzd´alen´evnitˇrn´ı # s´ıtˇeprob´ıhalopˇrestunel. # route add ${REM_INSIDE_NET} ${REM_INTERIOR_IP}
3.4.2 Podvrˇzen´ıMAC adresy pomoc´ıNetgraphu
S´ıt’ov´eadapt´ery maj´ı od v´yrobce pevnˇepˇridˇelenu tzv. hardwarovou MAC adresu. Tato adresa je unik´atn´ı(nebo by alespoˇnmˇelab´yt). Tak jako se pomoc´ıprotokolu DNS spojuj´ı dom´enov´ajm´enas IP adresami, obdobnˇese na nˇekter´ych s´ıt´ıch vytv´aˇr´ıpomoc´ıprotokolu ARP spojen´ımezi IP adresami a MAC adresami s´ıt’ov´ych rozhran´ı. MAC adresa je na kartˇevˇetˇsinou pevnˇe vyp´alena“do pamˇetiEPROM. Nˇekdy je vˇsak ” tˇrebatuto adresu zmˇenit, napˇr´ıklad pokud poskytovatel internetov´eho pˇripojen´ıprov´ad´ı mapov´an´ıIP adres na MAC adresy a uˇzivatel si chce napˇr. jen na p´arhodin pˇripojit jin´y poˇc´ıtaˇc, aniˇzby musel absolvovat proceduru s odhl´aˇsen´ımp˚uvodn´ıMAC adresy a registrac´ı nov´e. U nˇekter´ych s´ıt’ov´ych karet je moˇzn´enastavit MAC adresu softwarovˇepomoc´ın´astroje ifconfig(8). Ve skuteˇcnostinedojde ke zmˇenˇepevnˇedan´eadresy, jen se karta tv´aˇr´ı, jako by mˇela jinou. Co si vˇsak poˇc´ıt s kartami, kter´etuto softwarovou zmˇenu neumoˇzˇnuj´ı? V takov´em pˇr´ıpadˇen´amm˚uˇze pomoci Netgraph.[13] N´asleduj´ıc´ıpˇr´ıkazy vytvoˇr´ıuzel typu ng_bridge(4) a virtu´aln´ıethernetov´erozhran´ı.
• Odstran´ıIP adresu rozhran´ı.
# ifconfig dc0 delete
• Vytvoˇr´ıvirtu´aln´ıethernetov´erozhran´ı.
# ngctl mkpeer . eiface hook ether
14 • Ovˇeˇr´ı, zda rozhran´ıexistuje a MAC adresu m´avynulovanou.
# ifconfig ngeth0 ngeth0: flags=8802
• Zapne virtu´aln´ıethernetov´erozhran´ı.
# ifconfig ngeth0 up ngeth0: flags=8843
• Pokud tak nebylo uˇcinˇenoje potˇrebazav´est modul pro ng_ether(4).
# kldload ng_ether
• Vytvoˇr´ımost (bridge) a pˇripoj´ıdoln´ıh´akvirtu´aln´ıho rozhran´ı.
# ngctl mkpeer ngeth0: bridge lower link0
• Pojmenuje most.
# ngctl name ngeth0:lower mybridge
• Pˇripoj´ıh´akdoln´ıvrstvy fyzick´ehorozhran´ı.
# ngctl connect dc0: mybridge: lower link1
• Pˇripoj´ımost na h´akhorn´ıvrstvy fyzick´ehorozhran´ı.
# ngctl connect dc0: mybridge: upper link2
• Pˇripoj´ımost na h´akhorn´ıvrstvy virtu´aln´ıho rozhran´ı.
# ngctl connect ngeth0: mybridge: upper link3
• Nastav´ıfyzick´erozhran´ı,aby nepˇrepisovalo MAC adresu v hlaviˇck´ach r´amc˚usvou MAC adresou.
# ngctl msg dc0: setautosrc 0
15 • Pˇrepne fyzick´erozhran´ıdo promiskuitn´ıho modu, tzn. karta pˇred´av´ado vyˇsˇs´ıch vrstev i pakety, kter´enejsou adresov´any pˇr´ımo pro ni.
# ngctl msg dc0: setpromisc 1
• Nastav´ıMAC adresu virtu´aln´ıho rozhran´ı.
# ifconfig ngeth0 link 00:5c:16:10:dd:79
• Nech´asi od DHCP serveru pˇridˇelit IP adresu pro virtu´aln´ırozhran´ı.
# dhclient ngeth0 # ifconfig ngeth0 ngeth0: flags=8843
Sch´ema takto vytvoˇren´ehografu je moˇznovidˇet na obr´azku 3.1.
16 Kapitola 4
Dalˇs´ısubsyst´emy vyuˇziteln´epro modul
Pro n´avrh Netgraph modulu pro poˇc´ıt´an´ıstatistik je potˇreba porozumˇet nˇekolika dalˇs´ım subsyst´em˚um a mechanism˚um j´adra. V n´asleduj´ıc´ıch kapitol´ach si pˇredstav´ıme jednotliv´e mechanismy. Nejprve danou problematiku uvedeme do ˇsirˇs´ıhokontextu, potom se zamˇeˇr´ıme na specifick´edetaily a nakonec danou oblast uvedeme do souvislosti s navrhovan´ymmodu- lem.
4.1 Moduly j´adra
J´adro syst´emu FreeBSD se ˇrad´ımezi monolitick´aj´adra,avˇsak jako vˇetˇsinamodern´ıch uni- xov´ych syst´em˚um´apodporu pro jadern´emoduly. Pod pojmem jadern´emoduly m˚uˇzeme ch´apatdvˇer˚uzn´evˇeci. Pokud chtˇelv´yvoj´aˇrdo starˇs´ıch verz´ı BSD j´adra(jako monoli- tick´eho celku) pˇridat nˇejakou novou sluˇzbunebo subsyst´em, musel m´ıtvelice dobrou zna- lost intern´ıch jadern´ych mechanism˚u. To samozˇrejmˇeˇcinilo v´yvoj obt´ıˇznˇejˇs´ım a ˇcasovˇe n´aroˇcnˇejˇs´ım. V novˇejˇs´ıch verz´ıch nastal proces modularizace j´adra, tedy rozbit´ına v´ıcelo- gick´ych celk˚u,kter´eposkytuj´ıjednotliv´esluˇzby. Tyto moduly jsou pˇrizav´adˇen´ısyst´emu seˇrazeny do logick´eho sledu podle toho, jak na sobˇez´avis´ı.Modularizovan´ej´adro umoˇzˇnuje v´yvoj´aˇr˚umsnadnˇejipˇrid´avat nov´esluˇzby a subsyst´emy. Moduly m˚uˇzeme rozdˇelit na dvˇeskupiny. Moduly, kter´emohou b´ytnaˇcteny a naopak uvolnˇeny z pamˇeti v dobˇebˇehu syst´emu naz´yv´ame zavediteln´emoduly j´adra. Moduly, kter´e musej´ıb´ytzavedeny do pamˇeti pˇrizav´adˇen´ısyst´emu, naz´yv´ame permanentn´ıjadern´emo- duly. Tyto moduly poskytuj´ız´akladn´ısluˇzby jako spr´avupamˇetinebo pl´anovaˇcproces˚u,a proto nemohou b´ytodstranˇeny z pamˇetibˇeˇz´ıc´ıho syst´emu. Programov´an´ızavediteln´ych modul˚uj´adra je pro syst´emov´eprogram´atorydaleko poho- dlnˇejˇs´ıa rychlejˇs´ı. Program´ator m˚uˇze modul zkompilovat, zav´est, ladit pomoc´ıdebuggeru, uvolnit z pamˇeti,zmˇenit kus k´odu, zkompilovat a znovu naˇc´ıstbez toho, aniˇzby musel re- startovat syst´em. Pouˇzit´ızavediteln´ych modul˚uj´adra umoˇzˇnuje tak´eaktualizovat potˇrebn´e
17 ˇc´asti syst´emu bez nutnosti restartu. Na druhou stranu pˇrirealizaci syst´emu, kter´yumoˇzˇnuje zav´adˇeta uvolˇnovat moduly j´adra za bˇehu syst´emu, vyvst´av´ai ot´azka bezpeˇcnosti. Ve star´ych verz´ıch BSD bylo j´adro kompletnˇeimunn´ıv˚uˇci zmˇen´amproveden´ych uˇzivatelem za doby bˇehu syst´emu. Jedin´ym rozhran´ımpro interakci s j´adrem byla syst´emov´avol´an´ı. Uˇzivatel sice mohl shodit sv˚ujprogram, ale nemohl nijak ovlivnit j´adroOS, pomineme-li moˇznost zneuˇzit´ınˇejak´ez´avaˇzn´echyby v j´adˇre.Naproti tomu u j´adra s podporou zavedi- teln´ych modul˚uhroz´ınebezpeˇc´ı, ˇzeuˇzivatel, kter´emu se podaˇr´ız´ıskat pr´ava superuˇzivatele, m˚uˇzezmˇenit nˇekterou ˇc´ast bˇeˇz´ıc´ıhosyst´emu. Urˇcit´esluˇzby nemohou b´ytuvolnˇeny z bˇeˇz´ıc´ıho j´adra, coˇzje sice urˇcit´aforma ochrany, ale modul, kter´yje spr´avnˇenaps´anm˚uˇzeb´ytkdy- koliv zaveden, vˇcetnˇetˇech podstrˇcen´ych ´utoˇcn´ıkem. Urˇcit´ymˇreˇsen´ım bezpeˇcnostiby byla podpora digit´aln´ıch podpis˚uu jadern´ych modul˚u.Protoˇze vˇsak FreeBSD digit´aln´ımipod- pisy modul˚unedisponuje, d´avaj´ıspr´avci, kteˇr´ıprovozuj´ıFreeBSD v komerˇcn´ısf´eˇre pˇrednost sp´ıˇsezakompilov´an´ıvˇsech potˇrebn´ych sluˇzeb pˇr´ımodo j´adra a nepouˇz´ıvaj´ıjadern´emoduly, kter´emohou b´ytnaˇcteny v dobˇebˇehu syst´emu. [3] Cel´ysubsyst´em Netgraphu m˚uˇzeme m´ıtk dispozici jako jadern´ymodul, nebo ho m˚uˇzeme zakompilovat pˇr´ımodo j´adra, v tom pˇr´ıpadˇeje nutno pˇridat do konfiguraˇcn´ıhosouboru j´adra ˇr´adek options NETGRAPH. Samotn´emoduly Netgraphu maj´ıtak´eformu jadern´ych modul˚u.
4.2 Mbuf
Poˇzadavky na spr´avupamˇetipro prostˇredkymeziprocesov´ekomunikace (kam spad´ai s´ıt’ov´a komunikace) jsou trochu jin´eneˇzpoˇzadavky od ostatn´ıch ˇc´ast´ıj´adra operaˇcn´ıho syst´emu. V obou pˇr´ıpadech jde sice o efektivn´ıalokaci a uvolˇnov´an´ıpamˇeti,ale v pˇr´ıpadˇemezipro- cesov´ekomunikace je pˇriimplementaci r˚uzn´ych protokol˚uˇcasto nutn´epaket˚um pˇrid´avat ˇci odeb´ıratr˚uzn´ehlaviˇcky. Odes´ılan´adata se ˇcasto rozdˇeluj´ıdo v´ıcepaket˚ua naopak pˇrij´ıman´e pakety se sluˇcuj´ıdo vˇetˇs´ıch buffer˚u.Pakety jsou ˇcasto ˇrazeny do front, neˇzjsou pˇred´any d´alvyˇsˇs´ımvrstv´ampro pˇr´ıjem nebo niˇzˇs´ımpro odesl´an´ı.Pro tyto ´uˇcely existuje speci´aln´ı spr´ava pamˇeti. Alfou a omegou, kolem kter´eje tato spr´ava pamˇetivystavˇena,je datov´astruktura mbuf (obr. 4.1). Paket je sloˇzen z ˇretˇezce tˇechto struktur (mbuf chains). Mbufy maj´ıstandardn´ı velikost 256 byt˚u.Kaˇzd´y mbuf m´ana zaˇc´atkuhlaviˇcku tvoˇrenoustrukturou m hdr, ta obsahuje mimo jin´etak´eukazatel m next, kter´yukazuje na dalˇs´ı mbuf v ˇretˇezci. Hodnota NULL tohoto ukazatele znaˇc´ı, ˇze je dan´y mbuf posledn´ımv ˇretˇezci. Za hlaviˇckou se nach´az´ıdatov´aoblast, kter´aje standardnˇevelk´a234 byt˚u(hlaviˇcka zab´ır´a22 byt˚u).Pokud by tato datov´aoblast pˇr´ımov mbuf svoji velikost´ınestaˇcila, alokuje se pro data extern´ıdatov´astruktura. V hlaviˇcce m hdr je proto ukazatel m data, kter´yuka- zuje bud’ na datovou ˇc´ast mbuf nebo na extern´ıdatovou strukturu. Data se tedy nach´azej´ı pouze pˇr´ımov mbuf nebo v extern´ıstruktuˇre, nikdy na obou m´ıstech. D´aleje v hlaviˇcce m hdr k dispozici tak´e´udaj o velikosti datov´eoblasti, takˇzes jeho pomoc´ıa s ukazatelem na data je datov´aoblast pˇresnˇevymezena.
18 m_next m_nextpkt m_data m_len m_flags m_type
m_dat 234 bytes
Obr´azek 4.1: Datov´astruktura mbuf
Jak jiˇzbylo ˇreˇceno, m˚uˇze b´ytnˇekolik struktur typu mbuf zˇretˇezeno do ´utvaru naz´yvan´eho mbuf chain. Ty mohou b´ytd´alezˇretˇezeny pomoc´ıukazatele m nextpkt v hlaviˇcce do dalˇs´ıho seznamu objekt˚u,kter´yse v tomto pˇr´ıpadˇenaz´yv´afronta (mbuf queue). Dalˇs´ızaj´ımavou poloˇzkou v hlaviˇcce mbuf je poloˇzka flags. Tyto pˇr´ıznaky“popisuj´ı ” jak samotn´y mbuf, tak i objekt uloˇzen´yv mbuf chain. Pˇr´ıznaky popisuj´ı, zda m´a mbuf data uloˇzena v extern´ıdatov´estruktuˇre(M EXT), zda je k dispozici sekund´arn´ıhlaviˇcka (M PKTHDR). Pakety jsou uloˇzeny v mbuf chain a prvn´ı mbuf v ˇretˇezci m´anastaven pˇr´ıznakM PKTHDR. D´alem˚uˇzoub´ytnasteveny pˇr´ıznaky M BCAST nebo M MCAST, kter´eznaˇc´ı,ˇzedan´ypaket byl vysl´anjako broadcast nebo multicast, pˇr´ıpadnˇebyl takto pˇrijat. Jestliˇze je nastaven pˇr´ıznakM PKTHDR, n´asleduje za bˇeˇznouhlaviˇckou mbuf hlaviˇcka paketu. Ta zmenˇs´ıdatovou oblast na 210 byt˚u(obr. 4.2). Hlaviˇcka paketu je pˇr´ıtomna pouze v poˇc´ateˇcn´ım mbuf v ˇretˇezci mbuf chain a obsahuje poloˇzku ud´avaj´ıc´ıcelkovou velikost paketu, ukazatel na rozhran´ı,kter´ymbyl dan´ypaket pˇrijat, ukazatel na hlaviˇcku paketu, kontroln´ısouˇcty a seznam doplˇnuj´ıc´ıch znaˇcek. Mbuf nemus´ım´ıtdata paketu obsaˇzena pˇr´ımov sobˇe, ale m˚uˇzeukazovat na extern´ı datovou strukturu. Data tak mohou b´ytpouˇz´ıv´ana i v jin´ych ˇc´astech s´ıt’ov´ehosubsyst´emu bez nutnosti vytv´aˇretjejich kopie. Kdyˇzje poˇzadov´ano v´ıce kopi´ıstejn´ych dat, staˇc´ıkdyˇz se mbufy odkazuj´ına spoleˇcn´adata. [3, 4]
19 m_next m_nextpkt m_data m_len m_flags m_type pkt.len pkt.rcvif pkt.header pkt.csum_flags pkt.csum_data pkt.tags
m_dat 210 bytes
Obr´azek 4.2: Datov´astruktura mbuf s M PKTHDR
4.2.1 Funkce pro manipulaci s mbufy
Pro alokaci nov´eho mbufu se pouˇz´ıv´amakro MGET(). Pokud chceme k novˇevytv´aˇren´emu mbufu pˇripojit rovnou i hlaviˇcku,m˚uˇzeme pouˇz´ıtmakro MGETHDR(). Funkce m adj() upravuje vymezen´ıdatov´eoblasti v mbufu. Data nejsou nijak posouv´ana, pouze se manipuluje s odkazem m data a hodnotou m len. Pˇripˇred´av´an´ıpaketu dalˇs´ım vrstv´amse tak m˚uˇzeme posunout o hlaviˇcku n´ıˇznebo v´yˇs. Makro mtod() utvoˇr´ız ukazatele na mbuf hlaviˇcku ukazatel na jemu pˇr´ısluˇsej´ıc´ıdato- vou oblast pˇretypovan´yna poˇzadovan´ytyp. Analogicky makro dtom() vezme ukazatel na datovou oblast a vrac´ıukazatel na hlaviˇcku mbufu, ale tato funkce funguje pouze, jsou-li data pˇr´ımosouˇc´ast´ı mbufu. Funkce m pullup() uprav´ı mbuf tak, ˇze poˇzadovan´ypoˇcet byt˚uje spojitˇeum´ıstˇenpˇr´ımo v datov´eoblasti v mbufu. Tato operace se pouˇz´ıv´anapˇr´ıkladpro zkouman´ıprotokolov´ych hlaviˇcek, abychom se na nˇemohli pod´ıvat jako na spojitou datovou strukturu. [3]
20 4.3 Sysctl
Sysctl je syst´em pro sd´ılen´ıpromˇenn´ych mezi j´adrem a uˇzivatelsk´ymi procesy. Uˇzivatel m˚uˇze tyto promˇenn´eˇc´ıst a nˇekter´ei nastavovat pomoc´ıutility sysctl(8) nebo pomoc´ıjin´eho programu vyuˇz´ıvaj´ıc´ıknihovnu sysctl(3). Promˇenn´e sysctl jsou ˇrazeny do strom˚ua podstrom˚upodobnˇejako adres´aˇrov´estruktury. Nejd˚uleˇzitˇejˇs´ıpodstromy prvn´ı´urovnˇejsou tyto: kern j´adro, procesy a limity compat vrstva kompatibility (s jin´ymi operaˇcn´ımisyst´emy) vm virtu´aln´ıpamˇet’ vfs souborov´ysyst´em net s´ıt’ debug ladˇen´ı hw hardware machdep z´avisl´ena architektuˇre security bezpeˇcnost user user-level p1003 1b POSIX 1003.1B
Podstromy mohou obsahovat dalˇs´ıpodstromy nebo promˇenn´e.Jednotliv´e´urovnˇezanoˇren´ı jsou v syntaxi utility sysctl(8) oddˇeleny teˇckou. Vezmˇeme si jako pˇr´ıklad promˇennou net.inet.ip.fw.enable. Jej´ımnastaven´ım m˚uˇzeme zapnout, resp. vypnout firewall. N´asleduj´ıc´ım pˇr´ıkazem si nech´amezobrazit struˇcnou informaci k t´etopromˇenn´e.
# sysctl -d net.inet.ip.fw.enable net.inet.ip.fw.enable: Enable ipfw
Dalˇs´ıpˇr´ıkaz vyp´ıˇse nastaven´ıt´eto promˇenn´e.
# sysctl net.inet.ip.fw.enable net.inet.ip.fw.enable: 1
V´ıd´ıme, ˇzefirewall je zapnut´y.T´ımto pˇr´ıkazem firewall vypneme:
# sysctl net.inet.ip.fw.enable=0 net.inet.ip.fw.enable: 1 -> 0
Statick´adeklarace
K statick´edeklaraci sysctl promˇenn´ych v kernelu slouˇz´ımakra SYSCTL DECL(). Takto vy- tvoˇren´epromˇenn´ejsou inicializov´any pˇriinicializaci jadern´eho modulu a pˇri jeho uvolnˇen´ı jsou zniˇceny. K dispozici m´amemakra jako SYSCTL INT() pro vytvoˇren´ıpoloˇzky typu cel´ehoˇc´ısla, SYSCTL LONG pro dlouh´ecel´eˇc´ıslo, SYSCTL STRING() pro ˇretˇezec znak˚u,
21 atd. Nov´ypodstrom vytvoˇr´ıme makrem SYSCTL NODE(). Pokud nˇekter´apromˇenn´apˇri ˇcten´ınebo z´apisuvyˇzaduje sloˇzitˇejˇs´ızpracov´an´ıdat k jejich zpˇr´ıstupnˇen´ı,m˚uˇzeme vytvoˇrit handler pro tuto promˇennou pomoc´ımakra SYSCTL PROC(). Promˇenn´ym je tˇrebapˇri vytv´aˇren´ınastavit pr´ava (pouze pro ˇcten´ı, pro ˇcten´ıi z´apisrootem, pro ˇcten´ıi z´apis libo- voln´ymuˇzivatelem, atd.). Podrobnˇejˇs´ıpopis tˇechto maker a nˇekolik uk´azkov´ych pˇr´ıklad˚u najdeme v manu´alov´estr´ancek sysctl(9).
Dynamick´adeklarace
Statick´aalokace sysctl promˇenn´en´amumoˇzn´ı,ˇzese promˇenn´avytvoˇr´ı,kdyˇzmodul naˇcteme do j´adra. Pokud vˇsakmus´ımevytv´aˇret promˇenn´ebˇehembˇehu programu modulu, mus´ıme s´ahnout po funkci sysctl add oid(). Tato funkce vytvoˇr´ı obecnˇejak´ykoliv dostupn´ytyp promˇenn´e sysctl. Sp´ıˇse je vˇsakv´yhodnˇejˇs´ı pouˇz´ıt pˇripraven´amakra pro jednotliv´etypy (SYSCTL ADD NODE(), SYSCTL ADD INT(), SYSCTL ADD UINT(), apod.), k´odpo- tom bude alespoˇno nˇeco ˇcitelnˇejˇs´ı. U staticky deklarovan´ych sysctl promˇenn´ych nem´ameˇz´adnou moˇznost,jak je zruˇsit, kromˇeodstranˇen´ımodulu z pamˇeti.Dynamicky deklarovan´epromˇenn´ei cel´epodstromy m˚uˇzeme ruˇsitpomoc´ıfunkce sysctl remove oid(). K pˇresouv´an´ıobjekt˚una jin´epodstromy slouˇz´ıfunkce sysctl move oid(). Podrobnˇejˇs´ı popis tˇechto funkc´ı a pˇr´ıklady pouˇzit´ı nalezneme v manu´alov´estr´ance sysctl_add_oid(9). Pˇri vytv´aˇren´ınov´ych promˇenn´ych je dobr´esi uvˇedomit, ˇze tyto promˇenn´emohou b´yt pouˇz´ıv´any pˇr´ımouˇzivateli, knihovnami, programy nebo mohou b´ytuv´adˇeny v dokumen- taci. N´azvypodstrom˚ua promˇenn´ych sysctl bychom mˇeli vyb´ırat tak, abychom vylouˇcili pˇr´ıpadn´ekolize se souˇcasn´ymi n´azvy a mˇelibychom tak´emyslet na budoucnost a vyb´ırat zvl´aˇstˇepro nov´epodstromy vhodn´ajm´ena.
22 Kapitola 5
Modul pro poˇc´ıt´an´ıstatistik
Jedn´ımz ´ukol˚ut´eto bakal´aˇrsk´epr´acebylo vytvoˇrit netgraphov´ymodul pro poˇc´ıt´an´ıs´ıt’ov´ych statistik. Jako postaˇcuj´ıc´ıse uk´azala koncepce modulu se dvˇemah´aky, kter´ybude po za- pojen´ıpoˇc´ıtatpˇres nˇej tekouc´ıdata (poˇcet pˇrenesen´ych paket˚ua jejich celkovou velikost). Jak jiˇzbylo ˇreˇceno, Netgraph m´ado jist´em´ıryobjektovˇeorientovan´ycharakter. Pˇri implementaci vlastn´ıho uzlu se pouˇz´ıv´apˇret´ıˇzen´ıgenerick´ych metod vlastn´ımi funkcemi. Nejd˚uleˇzitˇejˇs´ımimetodami v uzlu je funkce pro pˇr´ıjem dat a funkce zpracov´an´ıkontroln´ıch zpr´av. Funkce pro pˇr´ıjem dat m´apˇr´ıstupk dat˚um jako ke struktur´amtypu mbuf. Pˇripˇrenosu datov´ych zpr´avmezi uzly nedoch´az´ıke zbyteˇcn´emu kop´ırov´an´ı,ale nam´ıstotoho se pˇren´aˇsej´ı pouze ukazatele na mbufy. Tyto ukazatele na mbufy jsou ve skuteˇcnosti obaleny strukturou naz´yvanou item. Ta obsahuje poloˇzkyjako adresu c´ılov´ehouzlu, r˚uzn´epˇr´ıznakyapod. Tyto implementaˇcn´ıdetaily samotn´eho Netgraphu n´asvˇsaknemus´ıpˇr´ıliˇszaj´ımat.Podstatn´eje, ˇzese dostaneme na strukturu mbuf, kterou m˚uˇzeme d´alezkoumat. Pro z´ısk´an´ınamˇeˇren´ych dat z modulu je moˇzn´evyuˇz´ıtmechanismu kontroln´ıch zpr´av. Funkce pro pˇr´ıjem kontroln´ıch zpr´avpˇri pˇr´ıjmu dan´ehotypu zpr´avyodeˇslejako odpovˇed’ strukturu s namˇeˇren´ymidaty. Dalˇs´ı moˇznost´ı jak z´ısk´avat namˇeˇren´adata z modulu je vyuˇzit´ısyst´emu sysctl.
5.1 Inspirace v ng tee
Pro z´akladn´ıpoˇc´ıt´an´ıpr˚uchoz´ıch dat se d´avyuˇz´ıtmodul ng_tee(4). Uzel tohoto typu si pro kaˇzd´yh´akudrˇzuje jednoduch´estatistiky o pˇrijat´ych a odeslan´ych datech. Pro jednoduch´e ´uˇctov´an´ına linkov´evrstvˇem˚uˇzeme pˇripojit uzel typu tee mezi h´aky lower a upper uzlu ether.
• Modul ng_ether(4) je potˇreba naˇc´ıstmanu´alnˇe, vˇetˇsinaostatn´ıch modul˚use zav´ad´ı automaticky pˇri vytv´aˇren´ıprvn´ıho uzlu dan´eho typu.
# kldload ng_ether
23 • Modul ng_ether(4) vytvoˇrilpro kaˇzd´eethernetov´erozhran´ıodpov´ıdaj´ıc´ıuzel. Dejme tomu, ˇzechceme ´uˇctovat data na zaˇr´ızen´ı bfe0. Pˇripoj´ımena uzel s n´azvem “bfe0” nov´yuzel tee a pojmenujeme ho ASCII n´azvem “tee”.
# ngctl mkpeer bfe0: tee lower left # ngctl connect bfe0: lower upper right # ngctl name bfe0:lower tee
tee: tee [27]:
bfe0: right left ether [25]:
upper lower
Obr´azek 5.1: Pˇripojen´ıuzlu tee na ether
• Vytvoˇren´ygraf m˚uˇzeme vidˇetna obr´azku 5.1. Uzlu “tee” nyn´ıpoˇsleme zpr´avu,aby vr´atilnamˇeˇren´estatistiky.
# ngctl msg tee: getstats Rec’d response ‘‘getstats’’ (1) from ‘‘[27]:’’: Args: { right={ inOctets=32298 inFrames=376 outOctets=2303817 outFrames=27181 } left={ inOctets=2303817 inFrames=27181 outOctets=32298 outFrames=376 } }
• Jestliˇze chceme uzel “tee” odstranit, poˇsleme mu generickou kontroln´ızpr´avu shut- down.
# ngctl shutdown tee:
• Povˇsimnˇeme si vˇsak, ˇzedoˇsloke spojen´ıh´ak˚u lower a upper (viz. obr. 5.2). To je totiˇz specialita ng_tee(4), ˇze pokud jsou pˇripojeny h´aky left a right, dojde pˇrivypnut´ı uzlu ke spojen´ıjeho protˇejˇsk˚u.Uzel tee se tak odpoj´ız cesty a mezeru po sobˇezacel´ı.
• To, ˇzez˚ustanouh´aky lower a upper typu ether spojen´e,nem´ana jeho funkci ˇz´adn´yvliv. Pokud bychom tomu chtˇelipˇredej´ıt,staˇc´ıjeden z h´ak˚uuzlu tee nejdˇr´ıve odstranit a
24 bfe0: ether [25]:
upper
lower
Obr´azek 5.2: Po vypnut´ıuzlu tee
potom uzel vypnout. Dalˇs´ımoˇznost´ıje odstranit oba h´aky. Potom dojde jako u vˇetˇsiny modul˚upo odstranˇen´ıvˇsech h´ak˚uk automatick´emu vypnut´ıuzlu.
# ngctl rmhook tee: left # ngctl rmhook tee: right
• Uzly typu ether nelze jako ostatn´ıuzly vypnout pomoc´ıkontroln´ızpr´avy shutdown. Nam´ısto toho lze tyto uzly odpojit od ethernetov´ych zaˇr´ızen´ızpr´avou detach.
# ngctl msg bfe0: detach
• Moduly je potom moˇzn´eodstranit z pamˇeti:
# kldunload ng_tee # kldunload ng_ether
5.2 Prvn´ıverze modulu
Modul pro poˇc´ıt´an´ıstatistik byl pojmenov´anjako ng_stat. Prvn´ıverze modulu vznikla zjednoduˇsen´ımmodulu ng_tee(4). Modul ng_tee(4), stejnˇejako cel´yNetgraph je zveˇrejnˇen pod BSD licenc´ı, takˇze nic nebr´anilo tomu vych´azet pˇri implementaci z k´odutohoto modulu. Uzel typu tee m´ah´aky right2left a left2right, na kter´epos´ıl´aduplikovan´adata. To se uk´azalo jako zbyteˇcn´ea proto byly tyto h´akyodstranˇeny. Zbyteˇcn´eje tak´e,aby se pro kaˇzd´y h´akpoˇc´ıtala pˇr´ıchoz´ıi odchoz´ıdata. V pˇr´ıpadˇeˇze jsou data pos´ıl´anana protˇejˇs´ıh´ak,staˇc´ı aby se zaznamen´avala napˇr.pouze data pˇrich´azej´ıc´ıdo uzlu. Po pˇripojen´ı na uzel typu ether poˇc´ıtala prvn´ı verze modulu jednotliv´eethernetov´e r´amcea sˇc´ıtala jejich velikosti. Velikost pˇrijat´eho r´amce se z´ısk´az poloˇzky pkt.len v hlaviˇcce
25 prvn´ıho mbufu v ˇretˇezci mbuf chain. To, ˇzenamˇeˇren´avelikost odpov´ıd´avelikosti etherne- tov´ych r´amc˚u, bylo ovˇeˇrenosrovn´an´ım v´ystupu s v´ystupem softwarov´eho s´ıt’ov´ehoana- lyz´atoruWireshark (http://www.wireshark.org). Koncepce sledov´an´ıethernetov´ych r´amc˚uje pouˇziteln´ai na bezdr´atov´eLAN (Wi-Fi), protoˇze tam se k pˇrenosu pouˇz´ıv´atak´eethernetov´yprotokol ([8, str. 69]).
5.3 Rozˇs´ıˇren´ıfunkˇcnosti
Rozˇs´ıˇren´ımodulu oproti prvn´ıverzi spoˇc´ıv´ave zkoum´an´ıstruktury pˇren´aˇsen´ych etherne- tov´ych r´amc˚u. Pˇrizkoum´an´ı mbufu postupujeme vˇzdy podle tohoto sch´ematu:
• Nejprve, pokud je tˇreba,uprav´ıme mbuf pomoc´ıfunkce m pullup(), abychom mˇeli jistotu, ˇze se poˇzadovan´ypoˇcet byt˚unach´az´ıspojitˇev datov´eoblasti mbufu.
• Pot´ez´ısk´ameukazatel na data pomoc´ımakra mtod().
• A potom se uˇzm˚uˇzeme na data pod´ıvat jako na poˇzadovanou strukturu.
Jako prvn´ıse ke zkoum´an´ına linkov´evrstvˇenab´ızej´ıethernetov´er´amce. Zn´azornˇen´ı jednotliv´ych poloˇzek v ethernetov´emr´amci vid´ımena obr. 5.3. Zaj´ımav´aje poloˇzka type, kter´aud´av´atyp dan´ehospojen´ı.Po porovn´an´ıt´etopoloˇzkys konstantami z hlaviˇckov´eho souboru net/ethernet.h m˚uˇzeme rozhodnout, do jak´ehoprotokolu na s´ıt’ov´evrstvˇespojen´ı patˇr´ı.Implementovan´ymodul sleduje protokoly IP a ARP. O dalˇs´ıprotokoly je moˇzn´emodul rozˇs´ıˇritjednoduch´ymz´asahem do zdrojov´ehok´odu.
Bytes 8 6 6 2 0−1500 0−46 4
Destination Source Check− Preamble address address Type Data Pad sum
Obr´azek 5.3: Ethernetov´yr´amecIEEE 802.3
Inkrementac´ıukazatele na datovou oblast se m˚uˇzeme posunout v ethernetov´emr´amci za poloˇzku type. To n´amumoˇzn´ıpod´ıvat se na data z perspektivy protokolu na vyˇsˇs´ıvrstvˇe. Na obr´azku 5.4 vid´ımestrukturu hlaviˇckyIP protokolu verze 4. Poloˇzka Protocol obsahuje informaci o protokolu transportn´ı vrstvy dan´ehopaketu. Definice konstant jednotliv´ych protokol˚unajdeme v hlaviˇckov´em souboru netinet/in.h. Nad protokolem IP rozpozn´av´a n´aˇsmodul protokoly TCP, UDP a ICMP. Podobn´ymzp˚usobem si lze vˇs´ımati dalˇs´ıch poloˇzek v IP hlaviˇcce. Mus´ımesi vˇsakd´at pozor na to, ˇze jednotliv´ebyty poloˇzek v IP hlaviˇcce jsou uloˇzeny v poˇrad´ıBig-Endian, coˇzje standard v s´ıt’ov´ekomunikaci. K pˇrevodu ˇc´ısel mezi k´odov´an´ımnaˇs´ıarchitektury a poˇrad´ım Big-Endian na s´ıti slouˇz´ımakra htonl() pro 32-bitov´acel´aˇc´ıslaa htons() pro 16-bitov´a cel´aˇc´ısla.Pro opaˇcn´ypˇrevod ze s´ıt’ov´ehopoˇrad´ıbyt˚una poˇrad´ınaˇs´ıarchitektury existuj´ı
26 0 31
Version IHL Type of sevice Total length D M Identification F F Fragment offset
Time to live Protocol Header checksum
Source address
Destination address
Options (0 or more words)
Obr´azek 5.4: Hlaviˇcka protokolu IPv4
makra ntohl() a ntohs(). Na architektur´ach s poˇrad´ımbyt˚uBig-Endian jsou tato makra definov´anatak, ˇze s pˇredan´ymihodnotami nic neprov´adˇej´ı,pˇresto (nebo snad pr´avˇeproto) se doporuˇcuje je pouˇz´ıvat, nebot’ se tak zv´yˇs´ıpˇrenosnost naˇsehoprogramu. Ve zdrojov´em k´odu implementovan´ehomodulu je pro uk´azku u protokolu TCP nastaveno ´uˇctov´an´ıpouze spojen´ıs urˇcitoupevnˇenastavenou IP adresou. D´aleje moˇzn´eposunout se o velikost IP hlaviˇcky a zkoumat hlaviˇcku dalˇs´ıhoprotokolu, napˇr.TCP nebo UDP, a zaznamen´avat jen spojen´ıurˇcit´eho portu apod. V implemento- van´emmodulu je toho vyuˇzitoa pro demonstraci se ´uˇctuj´ı v TCP sekci pouze spojen´ı asociovan´as urˇcit´ymnapevno nastaven´ymportem.
5.4 Komunikace s uzlem
Pro kaˇzd´yz protokol˚uIP, ARP, TCP, UDP a ICMP jsou v modulu zvl´aˇst’ poˇc´ıtadla pro tok dat ze s´ıtˇe(upstream – z niˇzˇs´ıch vrstev do vyˇsˇs´ıch) a pro opaˇcn´ysmˇer (downstream). Tyto namˇeˇren´ehodnoty je moˇzn´ez´ıskat dvoj´ımzp˚usobem:
1. Pomoc´ıkontroln´ıch zpr´av.
2. Pˇres syst´emsysctl.
Pro oba zp˚usoby se pouˇz´ıvaj´ı jedny a ty sam´e promˇenn´e. To, ˇze mohou b´yt pouˇzity oba syst´emy, nijak neovlivˇnuje v´ykon modulu. Konkr´etn´ıpopis kontroln´ıch zpr´ava sysctl promˇenn´ych je uveden v pˇr´ıloze C v n´avodu k pouˇzit´ı.
27 Kapitola 6
Z´avˇer
6.1 Srovn´an´ıs podobn´ymi moduly
Na z´avˇer se nab´ız´ısrovn´an´ıs ostatn´ımi podobn´ymi n´astroji na sledov´an´ıs´ıt’ov´ehoprovozu a vytv´aˇren´ıstatistik. Podobn´ym syst´emem je napˇr´ıklad Cisco NetFlow.
6.1.1 Cisco NetFlow
Cisco NetFlow je protokol pro sledov´an´ıa sb´ır´an´ıinformac´ıo toku na s´ıti. Implementace tohoto protokolu sest´av´aze dvou od sebe oddˇelen´ych program˚u. Tou prvn´ıˇc´ast´ıjsou sen- zory, kter´erozpozn´avaj´ıjednotliv´e toky“ (flows) v s´ıt’ov´emprovozu. Toky jsou rozliˇsov´any ” podle IP adres koncov´ych bod˚u,TCP/UDP port˚u, ToS a vstupn´ıch rozhran´ı.Namˇeˇren´a data jsou pos´ıl´ana pˇresUDP spojen´ıdalˇs´ım program˚um, tzv. sbˇeraˇc˚um.Sbˇeraˇce skladuj´ı namˇeˇren´adata, ze kter´ych pak m˚uˇzoub´ytvytv´aˇreny r˚uzn´egrafy apod. Senzory a sbˇeraˇce mohou b´ytnainstalov´any oddˇelenˇena r˚uzn´ych stroj´ıch na s´ıti. Ve FreeBSD existuje senzor pro NetFlow implementovan´yv Netgraphu. Je j´ımmodul ng_netflow(4).[7] NetFlow sleduje datov´aspojen´ına s´ıt’ov´evrstvˇeprotokolu IP, modul ng_stat naproti tomu m˚uˇze sledovat spojen´ıuˇzna niˇzˇs´ılinkov´evrstvˇea vid´ıtak protokoly, kter´ejsou i mimo IP.
6.2 N´avrhy na rozˇs´ıˇren´ı
Modul ng_stat by se dal samozˇrejmˇed´alerozˇs´ıˇrit. Jednou z oblast´ırozˇs´ıˇren´ıby mohla b´yt hlubˇs´ıanal´yzaproch´azej´ıc´ıch paket˚ua rozpozn´av´an´ıv´ıceprotokol˚u. Rozˇs´ıˇren´ıby nebylo nijak zvl´aˇstˇesloˇzit´e, staˇc´ıpostupovat zp˚usobem naznaˇcen´ym v kapitole 5. Dalˇs´ırozˇs´ıˇren´ıpr´aceby mohlo spoˇc´ıvat ve vytvoˇren´ısyst´emov´ehoutility operuj´ıc´ıv user- space. N´astroj by mohl vyuˇz´ıvat knihovnu netgraph(3) v pˇr´ıpadˇe,ˇze by komunikoval s mo- dulem pˇreskontroln´ızpr´avyNetgraphu. V pˇr´ıpadˇekomunikace pˇres sysctl, by bylo vhodn´e pouˇz´ıtknihovnu sysctl(3).
28 Nam´ısto st´avaj´ıc´ıhopˇrizp˚usobov´an´ısi modulu pˇr´ımo ´upravou zdrojov´ehok´odu, by bylo vhodn´evytvoˇritsyst´emkonfigurace, resp. nˇejak´ykonfiguraˇcn´ıjazyk. Dobr´eby tak´ebylo prov´est testov´an´ıvlivu modulu na v´ykonnost syst´emu a proveden´ı pˇr´ıpadn´ych optimalizac´ı.
29 Seznam pouˇzit´ych zdroj˚u
[1] Cobbs, A.: All About Netgraph. [online], 2000, [cit. 2007-04-24]. URL http://ezine.daemonnews.org/200003/netgraph.html
[2] Elischer, J.; Cobbs, A.: FreeBSD Kernel Interfaces Manual: NETGRAPH(4). FreeBSD, 2004, [rev. 2004-06-01].
[3] McKusick, M. K.; Neville-Neil, G. V.: The Design and Implementation of the FreeBSD Operating System. Addison-Wesley Professional, 2005, ISBN 0-201-70245-2.
[4] Patoˇcka, M.: Porovn´an´ısyst´em˚uLinux a FreeBSD (13). [online], 2004, [cit. 2007-05-01]. URL http://www.root.cz/clanky/porovnani-linux-freebsd-13/
[5] Raymond, E. S.: The Art of Unix Programming. Addison-Wesley Professional, 2003, ISBN 0-13-142901-9. URL http://www.faqs.org/docs/artu/
[6] Ritchie, D. M.: The Evolution of the UNIX Time-sharing System. BSTJ, roˇcn´ık63, 8, 1984: s. 1577–1594. URL http://cm.bell-labs.com/cm/cs/who/dmr/hist.html
[7] Smirnoff, G.: FreeBSD Kernel Interfaces Manual: NG NETFLOW(4). FreeBSD, 2006, [rev. 2006-03-02].
[8] Tanenbaum, A. S.: Computer Networks. Prentice Hall, 2003, ISBN 0-13-066102-3.
[9] The FreeBSD Documentation Project: FreeBSD Handbook. [online], 2007, [cit. 2007-05-05]. URL http://www.freebsd.org/doc/en US.ISO8859-1/books/handbook/index.html
[10] The Jargon File, version 4.4.7: Copycenter. [online], [cit. 2007-05-05]. URL http://catb.org/∼esr/jargon/html/C/copycenter.html
[11] Wikipedia: Berkeley Software Distribution. [online], 2007, [rev. 2007-04-29], [cit. 2007-05-04]. URL http://en.wikipedia.org/wiki/Berkeley Software Distribution
30 [12] Wikipedie: BSD licence. [online], 2007, [rev. 2007-04-15], [cit. 2007-05-08]. URL http://cs.wikipedia.org/wiki/BSD licence
[13] Yeske, D.: MAC address spoofing on FreeBSD using netgraph. [online], 2004, [cit. 2007-04-24]. URL http://ezine.daemonnews.org/200406/netgraph.html
31 Seznam pˇr´ıloh
A BSD licence
B N´avod pro pˇreklad a instalaci modulu
C N´avod k pouˇzit´ımodulu
32 Pˇr´ıloha A
BSD licence
Neofici´aln´ıˇcesk´ypˇreklad dneˇsn´ıpodoby licence[12]:
Copyright c ROK, VLASTN´IK PRAV.´ Vˇsechna pr´ava vyhrazena. Redistribuce a pouˇzit´ızdrojov´ych i bin´arn´ıch forem d´ıla,v p˚uvodn´ımi upravo- van´emtvaru, jsou povoleny za n´asleduj´ıc´ıch podm´ınek:
• S´ıˇren´yzdrojov´yk´odmus´ıobsahovatˇ v´yˇseuvedenou informaci o copyrightu, tento seznam podm´ınek a n´ıˇze uveden´ezˇreknut´ıse odpovˇednosti. • S´ıˇren´ybin´arn´ıtvarˇ mus´ın´est v´yˇse uvedenou informaci o copyrightu, tento seznam podm´ıneka n´ıˇzeuveden´ezˇreknut´ıse odpovˇednosti ve sv´edoku- mentaci a/nebo dalˇs´ıch poskytovan´ych materi´alech. • Ani jm´enovlastn´ıka pr´av,ani jm´ena pˇrispˇevatel˚unemohou b´yt pouˇzita pˇri podpoˇrenebo pr´avn´ıch aktech souvisej´ıc´ıch s produkty odvozen´ymi z tohoto software bez v´yslovn´eho p´ısemn´ehopovolen´ı.
TENTO SOFTWARE JE POSKYTOVAN´ DRZITELEMˇ LICENCE A JEHO PRISPˇ EVATELIˇ JAK STOJ´I A LEZˇ´I A JAKEKOLIV´ VYSLOVN´ E´ NEBO PREDPOKLˇ ADAN´ EZ´ ARUKY´ VCETNˇ E,ˇ ALE NEJEN, PREDPOKLˇ ADA-´ NYCH´ OBCHODN´ICH ZARUK´ A ZARUKY´ VHODNOSTI PRO JAKYKO-´ LIV U´CELˇ JSOU POPRENY.ˇ DRZITEL,ˇ ANI PRISPˇ EVATELˇ E´ NEBUDOU V ZˇADN´ EM´ PRˇ´IPADEˇ ODPOVEDNIˇ ZA JAKEKOLIV´ PRˇ´IME,´ NEPRˇ´IME,´ NAHODN´ E,´ ZVLA´STNˇ ´I, PRˇ´IKLADNE´ NEBO VYPLYVAJ´ ´IC´I SKODYˇ (VCET-ˇ NE,ˇ ALE NEJEN, SKODˇ VZNIKLYCH´ NARUSENˇ ´IM DODAVEK´ ZBOZˇ´I NEBO SLUZEB;ˇ ZTRATOU´ POUZITELNOSTI,ˇ DAT NEBO ZISKU;˚ NEBO PRERUˇ SENˇ ´IM OBCHODN´I CINNOSTI)ˇ JAKKOLIV ZPUSOBEN˚ E´ NA ZA-´ KLADEˇ JAKEKOLIV´ TEORIE O ZODPOVEDNOSTI,ˇ ATUˇ Zˇ PLYNOUC´I Z JINEHO´ SMLUVN´IHO VZTAHU, URCITˇ E´ ZODPOVEDNOSTIˇ NEBO PRE-ˇ CINUˇ (VCETNˇ Eˇ NEDBALOSTI) NA JAKEMKOLIV´ ZPUSOBU˚ POUZITˇ ´I
33 TOHOTO SOFTWARE, I V PRˇ´IPADE,ˇ ZEˇ DRZITELˇ PRAV´ BYL UPO- ZORNENˇ NA MOZNOSTˇ TAKOVYCH´ SKOD.ˇ
V p˚uvodn´ılicenci licenci od University of California in Berkeley (tzv. star´eBSD licenci) byl obsaˇzen nav´ıctento bod:
• Vˇsechny propagaˇcn´ımateri´alyzmiˇnuj´ıc´ıvlastosti nebo pouˇzit´ıtohoto soft- waru musej´ıobsahovat n´asleduj´ıc´ıtext: Tento produkt zahrnuje software vytvoˇren´yVLASTN´IKEM PRAV´ a pˇrispˇevatel˚u.
34 Pˇr´ıloha B
N´avod pro pˇreklad a instalaci modulu
Pro sestaven´ımodulu je potˇreba m´ıtk dispozici zdrojov´ek´odyj´adra.Nejpohodlnˇejˇs´ıje k jejich instalaci pouˇz´ıtn´astroj sysinstall(8). Jako uˇzivatel root spust´ıme sysinstall, z nab´ıdky postupnˇevybereme Configure, Distributions, src a zaˇskrtneme poloˇzky base a sys. Popisy alternativn´ıch zp˚usob˚uinstalace zdrojov´ych k´od˚uj´adra najdeme napˇr´ıklad v [9, kap. 8.3]. Pˇreklad spust´ıme pˇr´ıkazem make. Pˇreloˇzen´ymodul je potom potˇreba nakop´ırovat do adres´aˇre /boot/kernel/ nebo alespoˇndo nˇejum´ıstitsymbolick´ylink na modul.
$ make a
# cp ng_stat.ko /boot/kernel/ nebo
# ln -s ng_stat.ko /boot/kernel/
35 Pˇr´ıloha C
N´avod k pouˇzit´ımodulu
Pro snadn´enaˇcten´ımodulu a pˇripojen´ıuzlu na poˇzadovan´aethernetov´arozhran´ıbyl vy- tvoˇrenshellov´yskript etherstat.sh. Jeho pouˇzit´ıje n´asleduj´ıc´ı:
• Pokud je tˇreba,uprav´ımepromˇennou IFACES, kter´adefinuje rozhran´ı, na kter´ych si pˇrejeme sledovat provoz.
• Skript spust´ıme s parametrem start:
# etherstat.sh start Loading ng_stat.ko...done
• Pro odpojen´ıuzl˚uz grafu a uvolnˇen´ımodulu z pamˇetislouˇz´ıparametr stop:
# etherstat.sh stop Unloading ng_stat.ko...done
• Nav´ıcje k dispozici parametr restart, kter´yspust´ıpostupnˇesekce stop a start.
Na obr´azku C.1 vid´ımepˇripojen´ımodulu na uzel ethernetov´ehorozhran´ı.
C.0.1 Kontroln´ızpr´avy
Modul rozum´ın´asleduj´ıc´ımkontroln´ımzpr´av´am:
Bin´arn´ıform´at Textov´yform´at V´yznam NGM_STAT_GET_STATS getstats z´ısk´astatistiky NGM_STAT_CLR_STATS clrstats smaˇzestatistiky (vynuluje poˇc´ıtadla) NGM_STAT_GETCLR_STATS getclrstats atomicky z´ısk´aa smaˇze statistiky
Vyps´an´ınamˇeˇren´ych statistiky doc´ıl´ımes n´astrojem ngctl(8) napˇr.takto:
36 statbfe0: stat [6]:
bfe0: upper lower ether [3]:
upper lower
Obr´azek C.1: Pˇripojen´ıuzlu stat na ether
# ngctl msg statbfe0: getstats Rec’d response ‘‘getstats’’ (1) from ‘‘[18]:’’: Args: { downstream={ ip_octets=19150259 ip_frames=348114 udp_octets=60071 udp_frames=402 arp_octets=294 arp_frames=7 } upstream={ ip_octets=781547454 ip_frames=541149 udp_octets=1518023 udp_frames=10125 arp_octets=2618880 arp_frames=43648 } }
C.0.2 SYSCTL
Pˇr´ıkladv´ypisu vˇsech statistik vˇsech uzl˚utypu stat pomoc´ı sysctl(8): net.stat.00000006.name: statbfe0 net.stat.00000006.downstream.ip_octets: 19347667 net.stat.00000006.downstream.ip_frames: 350985 net.stat.00000006.downstream.tcp_octets: 0 net.stat.00000006.downstream.tcp_frames: 0 net.stat.00000006.downstream.udp_octets: 65085 net.stat.00000006.downstream.udp_frames: 430 net.stat.00000006.downstream.icmp_octets: 0 net.stat.00000006.downstream.icmp_frames: 0 net.stat.00000006.downstream.arp_octets: 336 net.stat.00000006.downstream.arp_frames: 8 net.stat.00000006.upstream.ip_octets: 786816119 net.stat.00000006.upstream.ip_frames: 546585 net.stat.00000006.upstream.tcp_octets: 0 net.stat.00000006.upstream.tcp_frames: 0 net.stat.00000006.upstream.udp_octets: 1719152
37 net.stat.00000006.upstream.udp_frames: 11582 net.stat.00000006.upstream.icmp_octets: 0 net.stat.00000006.upstream.icmp_frames: 0 net.stat.00000006.upstream.arp_octets: 3078900 net.stat.00000006.upstream.arp_frames: 51315
Jak m˚uˇzeme vidˇet z pˇredchoz´ıho v´ypisu, uzel si v net.stat vytvoˇr´ıpodstrom, jehoˇz jm´enemje adresa uzlu v hexadecim´aln´ımtvaru. Je to z toho d˚uvodu, ˇze vytvoˇren´yuzel nemus´ıv˚ubec dostat jm´eno.Pokud ale uzel jm´enodostane, objev´ıse v promˇenn´e name.
38