eské vysoké u£ení te hni ké v Praze Fakulta elektrote hni ká
Diplomová prá e Provozní harakteristiky sí´ový h ltr· B . Petr Juha¬ák
Vedou í prá e: Do .Ing. Jan Jane£ek, CS .
Studijní program: Výpo£etní te hnika kv¥ten 2008
Podˇ ekov´ an´ı Dˇekuji vedouc´ımu diplomov´e pr´ace Doc.Ing. Janu Janeˇckovi, CSc. za veden´ı ˇ akovi za pr´ace. D´ale chci podˇekovat Michalu Medveck´emu a Michalu Stus´ zap˚ ujˇcen´ı hardwarov´eho firewallu.
Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem svou diplomovou pr´aci vypracoval samostatnˇe a pouˇzil pouze podklady uveden´e v pˇriloˇzen´em seznamu. Nem´am z´avaˇzn´ y d˚ uvod proti uˇzit´ı tohoto ˇskoln´ıho d´ıla ve smyslu §60 Z´akona ˇc. 121/2000 Sb., o pr´avu autorsk´em, o pr´avech souvisej´ıc´ıch s pr´avem autorsk´ ym a o zmˇenˇe nˇekter´ ych z´akon˚ u (autorsk´ y z´akon).
Abstrakt Pr´ace se zamˇeˇruje na provozn´ı charakteristiky s´ıt’ov´ ych filtr˚ u, kvantifikuje zpoˇzdˇen´ı paket˚ u v z´avislosti na objemu a typu pravidel. Pˇredmˇetem zkoum´an´ı je softwarov´ y firewall zaloˇzen´ y na iptables a hardwarov´ y firewall CISCO PIX 506.
Abstract This thesis is aimed at the time characteristics of packet filters, quantifies delays of packets depending on the amount and a type of rules. Research is focused on software firewall iptables and hardware PIX firewall produced by Cisco company.
´ Uvod Firewally pln´ı bezpeˇcnostn´ı funkci na hraniˇcn´ıch bodech s´ıt´ı, skr´ yvaj´ı informace o struktuˇre vnitˇrn´ı s´ıtˇe a blokuj´ı neˇz´adouc´ı sluˇzby. V komerˇcn´ım prostˇred´ı jsou dnes jiˇz firewally nutnost´ı, ale m˚ uˇzeme pozorovat i jejich pouˇzit´ı v dom´ac´ıch s´ıt´ıch, kde se vyskytuj´ı ve formˇe aktivn´ıch s´ıt’ov´ ych prvk˚ u nebo na klientsk´ ych stanic´ıch v podobˇe softwaru. Kdyˇz pomineme bezpeˇcnostn´ı funkci firewallu, zaj´ım´a n´as tak´e, jak´ y maj´ı firewally vliv na s´ıt’ov´ y provoz a jak m˚ uˇzeme kvantifikovat zpoˇzdˇen´ı paket˚ u v z´avislosti na typu a objemu pravidel? D´ale lze zkoumat, jak´e jsou moˇznosti konkr´etn´ıch implementac´ı firewall˚ u a kde jsou hranice jejich pouˇzit´ı. Na tyto ot´azky odpov´ıd´a tato diplomov´a pr´ace, kter´a pomoc´ı experiment˚ u zkoum´a softwarov´ y firewall zaloˇzen´ y na iptables a propriet´arn´ı firewall CISCO PIX 506. V jednotliv´ ych u ´loh´ach kvantifikuje zpoˇzdˇen´ı paket˚ u v z´avislosti na objemu a typu pravidel. Prvn´ı kapitola klasifikuje moˇzn´e typy firewall˚ u, se kter´ ymi se dnes m˚ uˇzeme setkat. Druh´a a tˇret´ı kapitola je vˇenov´ana problematice TCP/IP protokol˚ ua struktuˇre firewallu iptables. N´asleduj´ıc´ı dvˇe kapitoly se zab´ yvaj´ı konstrukc´ı experiment´aln´ıch u ´loh a jejich pozorov´an´ı. Posledn´ı kapitola je vˇenov´ana bezpeˇcnosti.
2
Kapitola 1
Firewally Firewally tvoˇr´ı hraniˇcn´ı body na pˇrechodech vnitˇrn´ıch a vnˇejˇs´ıch s´ıt´ı, kontroluj´ı s´ıt’ov´ y provoz a zakazuj´ı neˇz´adouc´ı sluˇzby. Robustn´ı firewally chr´an´ı s´ıt’ov´ y provoz od linkov´e aˇz po aplikaˇcn´ı vrstvu. Jednoduˇsˇs´ı firewally monitoruj´ı provoz v rozsahu linkov´e aˇz transportn´ı vrstvy.
1.1
Hardwarov´ e a softwarov´ e firewally
Firewally dˇel´ıme na dvˇe z´akladn´ı skupiny: • hardwarov´e • softwarov´e Hardwarov´e firewally jsou integrov´any pˇr´ımo do aktivn´ıch s´ıt’ov´ ych prvk˚ u, kter´ ymi jsou napˇr. smˇerovaˇce. Hardwarov´e firewally maj´ı dostateˇcnˇe dimenzovan´ y hardware pro s´ıt’ov´ y provoz a pouˇz´ıvaj´ı propriet´arn´ı operaˇcn´ı syst´em, kter´ y je navrˇzen pouze pro tento typ zaˇr´ızen´ı; je jednoduˇsˇs´ı a d´ıky tomu i bezpeˇcnˇejˇs´ı. Naproti tomu softwarov´ y firewall je aplikace, kter´a mus´ı b´ yt s operaˇcn´ım syst´emem tˇesnˇe sv´az´ana, a tud´ıˇz je tento typ firewallu zraniteln´ y na u ´rovni operaˇcn´ıho syst´emu nebo jeho chybn´e implementaci TCP/IP z´asobn´ıku. Operaˇcn´ı syst´em zpravidla poskytuje dalˇs´ı zbyteˇcn´e s´ıt’ov´e sluˇzby a aplikace, kter´e vytv´aˇrej´ı prostor pro zranitelnost cel´eho syst´emu. Pokud chceme poˇz´ıvat softwarov´ y firewall, vyhrad´ıme si pro nˇej dedikovan´ y stroj a omez´ıme vˇsechny sluˇzby. Softwarov´e firewally jsou tak´e vhodn´e na klientsk´ ych stanic´ıch jako bezpeˇcnostn´ı doplnˇek, nebo pro monitorov´an´ı s´ıt’ov´ ych aktivit klientsk´eho softwaru.
1.2
Metody regulace s´ıt’ov´ eho provozu
Firewally vyuˇz´ıvaj´ı tˇri z´akladn´ı metody[1] k regulaci s´ıt’ov´eho provozu:
4
1.2 Metody regulace s´ıt’ov´eho provozu • filtrov´an´ı paket˚ u1 • pˇreklad s´ıt’ov´ ych adres NAT • sluˇzeb proxy
1.2.1
Paketov´ e filtry
Paketov´e filtry porovn´avaj´ı pole hlaviˇcek IP paket˚ u a transportn´ıch protokol˚ u (TCP, UDP). Z tˇechto informac´ı firewall pozn´a adresu zdroje a adresu c´ıle vˇcetnˇe port˚ u. Z´ıskan´e informace porovn´a s vnitˇrn´ımi pravidly, kter´e tvoˇr´ı politiku firewallu. Pokud paket vyhovuje politice firewallu, paket projde d´ale, pokud paket nevyhovuje firewall paket zahod´ı. Tato technika je jednoduch´a, ale m´a sv´a u ´skal´ı. Jednak neskr´ yv´a adresy poˇc´ıtaˇc˚ u ve vnitˇrn´ı s´ıti, jednak pokud doch´az´ı k fragmentaci paket˚ u, tak TCP hlaviˇcka je pˇr´ıtomn´a v prvn´ım fragmentu zpr´avy a pro ostatn´ı pˇr´ıchoz´ı pakety se firewall m˚ uˇze opˇr´ıt pouze o hlaviˇcku IP protokolu, kter´a uˇz nedefinuje zdrojov´e a c´ılov´e porty. Z podstaty paketov´eho filtru vypl´ yv´a, ˇze nen´ı schopen identifikovat, zda data uvnitˇr transportn´ıho protokolu jsou bˇeˇzn´a data dan´eho aplikaˇcn´ıho protokolu (napˇr. HTTP) nebo ˇskodliv´ y k´od. V´ yhodou tohoto typu firewallu je jiˇz zm´ınˇen´a jednoduchost, nebot’ se analyzuje mal´e mnoˇzstv´ı informac´ı a filtrov´an´ı nen´ı n´aroˇcn´e na prostˇredky jako je CPU a pamˇet’. Doch´az´ı tak k mal´e latenci a je jednoduch´e tyto firewally implementovat jako hardwarov´e zaˇr´ızen´ı.
1.2.2
NAT
Pˇreklad adres NAT (network address translation) je metoda jak maskovat adresu vnitˇrn´ı s´ıtˇe. Prim´arn´ım u ´ˇcelem NAT bylo umoˇznit s jednou IP adresou pˇripojit celou skupinu poˇc´ıtaˇc˚ u na lok´aln´ı s´ıti k internetu, protoˇze voln´ ych adres u protokolu IP verze 4 je nedostatek. Funkci NAT m˚ uˇzeme osvˇetlit n´asleduj´ıc´ım pˇr´ıkladem; paket putuj´ıc´ı z vnitˇrn´ı s´ıtˇe doraz´ı na firewall, kter´ y m˚ uˇze b´ yt z´aroveˇ n smˇerovaˇcem a postupnˇe prov´ad´ı tyto kroky: • prozkoum´a IP paket • pˇrep´ıˇse p˚ uvodn´ı zdrojovou adresu a nahrad´ı ji svou IP adresou • prozkoum´a porty transportn´ıho protokolu (TCP, UDP) • poznaˇc´ı si p˚ uvodn´ı zdrojov´ y port a pˇrep´ıˇse jej n´ahodnˇe zvolen´ ym voln´ ym portem, kter´ y bude pro tuto komunikaci pouˇz´ıvat 1
Exaktn´ı definice slova paket neexistuje, jedn´ a se o obecn´ y term´ın popisuj´ıc´ı segmentaˇcn´ı jednotku dat pˇripravenou k pˇrenosu po s´ıti, kter´ a je oznaˇcena informacemi nutn´ ymi pro doruˇcen´ı paketu adres´ atovi a pˇr´ıpadn´emu doruˇcen´ı odpovˇedi odesilateli.
1.2 Metody regulace s´ıt’ov´eho provozu
5
D˚ usledkem je, ˇze pakety odch´azej´ıc´ı ze smˇerovaˇce do vnˇejˇs´ı s´ıtˇe maj´ı spoleˇcnou zdrojovou adresu (IP adresu smˇerovaˇce). T´ım se skr´ yvaj´ı adresy vnitˇrn´ı s´ıtˇe a informace o jej´ı struktuˇre. Je samozˇrejmˇe nutn´e, aby smˇerovaˇc pˇri opaˇcn´e komunikaci z vnˇejˇs´ı s´ıtˇe dovnitˇr pˇrekl´adal zpˇet IP adresy smˇerovaˇce na IP adresy poˇc´ıtaˇc˚ u vnitˇrn´ı s´ıtˇe. Smˇerovaˇc nalezne IP adresu spr´avn´eho adres´ata pr´avˇe d´ıky c´ılov´emu portu, kter´ y m´a poznaˇcen v tabulce existuj´ıc´ıch spojen´ı. Nev´ yhodou NAT je, ˇze pracuje jako proxy na transportn´ı vrstvˇe, to znamen´a, ˇze tento typ firewallu nefiltruje datovou ˇc´ast pˇren´ aˇsenou v paketech transportn´ıch protokol˚ u (TCP, UDP). S nˇekter´ ymi aplikaˇcn´ımi protokoly si NAT neporad´ı, protoˇze pr´avˇe do datov´e ˇc´asti transportn´ıho protokolu ukl´adaj´ı nˇekter´e protokoly vyˇsˇs´ıch vrstev IP adresy. Tˇech se samozˇrejmˇe NAT, nedotkne protoˇze je implementov´an na u ´rovni hlaviˇcek protokolu IP a transportn´ıch protokol˚ u UDP, TCP. NAT se bˇeˇznˇe vyskytuje jako doplˇ nkov´a funkce aktivn´ıch s´ıt’ov´ ych prvk˚ u.
1.2.3
Proxy firewall
Proxy sluˇzby pracuj´ı vˇzdy s prostˇredn´ıkem (proxy serverem), kter´ y je uprostˇred komunikace mezi stanic´ı ve vnitˇrn´ı s´ıti, jeˇz chce komunikovat, a mezi c´ılov´ ym hostitelsk´ ym poˇc´ıtaˇcem ve vnˇejˇs´ı s´ıti. M´ısto abychom komunikovali pˇr´ımo s c´ılov´ ym hostitelsk´ ym poˇc´ıtaˇcem na u ´rovni dan´eho aplikaˇcn´ıho protokolu, obr´at´ıme se na proxy server s ˇz´adost´ı o spojen´ı. T´ımto se st´av´a proxy server klientem a komunikuje za n´as s protistranou a vrac´ı v´ ysledky komunikace. Proxy firewally maj´ı tu v´ yhodu, ˇze filtruj´ı aplikaˇcn´ı protokoly. Mohou tak filtrovat a validovat jeho obsah a zabr´anit pˇr´ıpadn´emu u ´toku na aplikaˇcn´ı vrstvu. Nev´ yhodou je moˇzn´e zahlcen´ı, protoˇze inspekce na aplikaˇcn´ı vrstvˇe je n´aroˇcn´a. T´ım, ˇze do komunikace mezi klientem a serverem vstupuje aplikaˇcn´ı proxy, je moˇzn´e pouˇz´ıvat dvˇe nez´avisl´a TCP spojen´ı a odm´ıtat vˇsechny pˇr´ım´e IP pakety bez podporovan´eho protokolu. Kaˇzd´ y paket, kter´ y na proxy doraz´ı, se nejdˇr´ıve rozebere, prozkoum´a se, zda vyhovuje aplikaˇcn´ım pravidl˚ um a vytvoˇr´ı se nov´ y paket. To ˇcin´ı proxy servery v´ıce imunn´ı proti bˇeˇzn´ ym i nezn´am´ ym u ´tok˚ um, kter´ ymi stavov´e firewally trp´ı. Nev´ yhodou je, ˇze pro kaˇzdou inspekci aplikaˇcn´ıho protokolu, kterou chceme chr´anit proti u ´toku, potˇrebujeme dalˇs´ı proxy firewall.
6
1.2 Metody regulace s´ıt’ov´eho provozu
Kapitola 2
Z´ aklady TCP/IP Pod oznaˇcen´ım TCP/IP mysl´ıme rodinu protokol˚ u zaloˇzen´ ych nad protokolem IP, kter´ y je z´akladn´ım protokolem internetu. Protokol IP (Internet Protocol) pouˇz´ıv´a logick´e adresov´an´ı ve formˇe IP adres a z´aroveˇ n pˇrekon´av´a rozd´ıly mezi s´ıtˇemi r˚ uzn´ ych architektur, kter´e pouˇz´ıvaj´ı vlastn´ı fyzick´e adresov´an´ı a specifick´e m´edium pro pˇrenos sign´alu.
2.1
Model TCP/IP
Kaˇzd´ y hostitelsk´ y poˇc´ıtaˇc, kter´ y se chce pˇripojit k internetu pomoc´ı protokolu IP, mus´ı poˇz´adat sv˚ uj operaˇcn´ı syst´em o komunikaci se vzd´alen´ ym hostitelsk´ ym zaˇr´ızen´ım. Komunikuje se pˇres programov´e rozhran´ı, jehoˇz konkr´etn´ı implementaci ˇr´ık´ame TCP/IP z´asobn´ık (TCP/IP stack) a kter´e podporuje protokoly TCP/IP v operaˇcn´ım syst´emu. Fyzicky prob´ıh´a komunikace pomoc´ı s´ıt’ov´e karty. Aby se operaˇcn´ı syst´em domluvil s hardwarem s´ıt’ov´e karty, potˇrebuje ovladaˇc zaˇr´ızen´ı, tzv. driver. Celou s´ıt’ovou architekturu hostitelsk´eho syst´emu m˚ uˇzeme popsat modelem a pˇredstavit si cestu dat od okamˇziku, kdy je pos´ıl´a aplikace aˇz po okamˇzik, kdy data opust´ı s´ıt’ovou kartu. Na obr´azku 2.1 vid´ıme dva s´ıt’ov´e modely. Vpravo je referenˇcn´ı model OSI, kter´ y se neprosadil, a sp´ıˇse se dnes povaˇzuje za didaktickou pom˚ ucku, protoˇze se nikdy plnˇe nerealizovaly vˇsechny jeho protokoly. Vlevo vid´ıme model TCP/IP, jehoˇz protokoly nakonec zv´ıtˇezily a kter´e budou pˇredmˇetem naˇseho z´ajmu. Model TCP/IP se skl´ad´a z nˇekolika vrstev. Pro kaˇzdou vrstvu plat´ı pravidlo, ˇze komunikuje pouze se sousedn´ımi vrstvami. Pˇredstavme si, ˇze pracujeme s webov´ ym prohl´ıˇzeˇcem a chceme si pˇreˇc´ıst naˇse obl´ıben´e str´anky. Kdyˇz nap´ıˇseme do adresn´ıho ˇr´adku dom´enov´ y n´azev naˇseho obl´ıben´eho webov´eho serveru, mus´ı n´aˇs poˇzadavek postupnˇe pro” bublat” vˇsemi vrstvami. Pˇr´ıchoz´ı odpovˇed’ od webov´eho serveru reverznˇe probubl´a” vrstvami modelu TCP/IP. ”
8
2.1 Model TCP/IP
Obr´azek 2.1: model TCP/IP a referenˇcn´ı model OSI
2.1.1
Aplikaˇ cn´ı vrstva
Na vrcholu z´asobn´ıku (TCP/IP modelu) vid´ıme aplikaˇcn´ı vrstvu, kde bˇeˇz´ı s´ıt’ov´e aplikace vyuˇz´ıvaj´ıc´ı sluˇzeb operaˇcn´ıho syst´emu. Bˇeˇz´ı zde i webov´ y prohl´ıˇzeˇc, kter´ y vytvoˇr´ı poˇzadavek na naˇcten´ı str´anky pomoc´ı protokolu HTTP a IP adresy c´ılov´eho webov´eho serveru. Aplikace webov´eho prohl´ıˇzeˇce poˇz´ad´a operaˇcn´ı syst´em o vytvoˇren´ı s´ıt’ov´eho spojen´ı, coˇz je z hlediska TCP/IP modelu pˇresun do n´asleduj´ıc´ı spodn´ı transportn´ı vrstvy.
2.1.2
Transportn´ı vrstva
Aplikace poˇz´adala vol´an´ım sluˇzby operaˇcn´ıho syst´emu o vytvoˇren´ı s´ıt’ov´eho spojen´ı na konkr´etn´ı IP adresu. Protoˇze pˇrenos dat pomoc´ı protokolu IP je nespolehliv´ y, vyuˇz´ıvaj´ı se transportn´ı protokoly TCP nebo UDP. Oba protokoly zav´adˇej´ı kontroln´ı souˇcty pro data a doplˇ nuj´ıc´ı adresaci pomoc´ı port˚ u. Port je adresn´ı identifik´ator, kter´ y na hostitelsk´em stroji urˇcuje adresu s´ıt’ov´e sluˇzby. V internetu je kaˇzd´e aktivn´ı s´ıt’ov´e spojen´ı mezi dvˇema hostiteli jednoznaˇcnˇe identifikovateln´e dvojic´ı IP adres a dvojic´ı, kter´a je tvoˇrena zdrojov´ ym a c´ılov´ ym portem. Protokol TCP bˇehem tˇr´ı krok˚ u ustavuje spojen´ı mezi obˇema hostiteli a garantuje pˇrenos dat po ustaven´em kan´alu. Pokud se nˇejak´ y paket nepodaˇr´ı doruˇcit, tento protokol zajist´ı, ˇze vys´ılac´ı strana pˇrenos zopakuje. Protokol TCP je tedy stavov´ y; m˚ uˇzeme se tak´e setkat s oznaˇcen´ım spojovˇe orientovan´ y. Naproti tomu protokol UDP je jednoduˇsˇs´ı, rychlejˇs´ı, ale negarantuje doruˇcen´ı dat. V pˇr´ıpadˇe detekce nedoruˇcen´eho paketu, mus´ı aplikace sama zajistit nov´ y pˇrenos.
2.1 Model TCP/IP
9
Kdyˇz se vr´at´ıme k naˇsemu pˇr´ıkladu s webov´ ym prohl´ıˇzeˇcem, tak jeho aplikaˇcn´ı protokol HTTP pracuje implicitnˇe na portu 80 a vyuˇz´ıv´a sluˇzeb transportn´ıho protokolu TCP. Operaˇcn´ı syst´em nasegmentoval data HTTP poˇzadavku do TCP segmentu. Kaˇzd´ y TCP segment obsahuje hlaviˇcku s hodnotou c´ılov´eho portu a libovolnˇe zvolen´ ym zdrojov´ ym portem, kter´ y se vyuˇzije jako identifik´ator procesu ˇz´adaj´ıc´ıho o data, aˇz pˇrijde zpˇet odpovˇed’ na n´aˇs HTTP dotaz. T´ımto jsou TCP segmenty pˇripraveny k pˇred´an´ı do niˇzˇs´ı internetov´e vrstvy.
2.1.3
Internetov´ a vrstva
V t´eto vrstvˇe n´am zb´ yv´a zabalit pˇripraven´e segmenty nebo datagramy1 do pˇripraven´ ych IP paket˚ u, kter´e v hlaviˇcce obsahuj´ı IP adresu c´ıle. V datov´e ˇc´asti m´a kaˇzd´ y IP paket jeden datagram, kter´ y pˇriˇsel v r´amci jedn´e relace. Zde konˇc´ı veˇsker´a logick´a adresace a operaˇcn´ı syst´em pˇred´av´a frontu pˇripraven´ ych IP paket˚ u posledn´ı vrstvˇe, kter´a bude muset fyzicky vyˇreˇsit doruˇcen´ı pˇripraven´ ych dat c´ılov´emu hostiteli.
2.1.4
S´ıt’ov´ a vrstva a hardware
´ Ukolem posledn´ı vrstvy je zapouzdˇrit IP paket do r´amce a vyslat vˇse na m´edium pomoc´ı s´ıt’ov´e karty. M´edium m˚ uˇze m´ıt podobu metalick´eho veden´ı, optick´eho vl´akna, nebo bezdr´atov´eho m´edia komunikuj´ıc´ıho pomoc´ı r´adiov´ ych vln. R´amec si m˚ uˇzeme pˇredstavit jako ˇcasov´ y prostor pro vysl´an´ı dat na m´edium. R´amec m´a definovanou strukturu, kter´a je z´ avisl´a na typu m´edia a implementovan´e technologie. Za zm´ınku stoj´ı, ˇze na u ´rovni r´amce je zavedena fyzick´a adresace. Kaˇzd´e fyzick´e zaˇr´ızen´ı v podobˇe s´ıt’ov´e karty m´a fyzickou adresu a o ˇz´adn´e logick´e IP adrese nem˚ uˇze b´ yt na t´eto vrstvˇe ˇreˇc. Napˇr. na Ethernetu, nejbˇeˇznˇejˇs´ım s´ıt’ov´em rozhran´ı, se fyzick´a adresa s´ıt’ov´e karty oznaˇcuje jako 48bitov´a MAC adresa. Pokud se vˇsak hostitelsk´e poˇc´ıtaˇce v internetu adresuj´ı logick´ ymi IP adresami, aby pˇrekonaly architektonick´e rozd´ıly s´ıt´ı, mus´ı na t´eto vrstvˇe existovat zp˚ usob, jak namapovat IP adresu ke konkr´etn´ı fyzick´e adrese. K tomuto kroku mus´ı doj´ıt dˇr´ıve, neˇz se pˇripraven´e IP pakety vyˇslou na fyzick´e m´edium ve formˇe r´amce, protoˇze ten si vynucuje vyplnit fyzickou adresu pˇr´ıjemce. ˇ sen´ım je zaveden´ı protokolu ARP (Adress Resolution Protocol), kter´ Reˇ y zajist´ı mapov´an´ı mezi logickou a fyzickou adresou. Pokud poˇc´ıtaˇc nezn´a fyzickou adresu c´ıle pro konkr´etn´ı IP adresu, pos´ıl´a ARP dotaz na m´edium. Kdyˇz se adres´at nach´az´ı na stejn´em segmentu lok´aln´ı s´ıtˇe (LAN), obdrˇz´ı 1
Datagram je oznaˇcen´ı jednoho fragmentu dat protokolu UDP, podobn´e oznaˇcen´ı existuje pro fragment dat protokolu TCP, kter´e se naz´ yv´ a TCP segment.
10
2.2 Odposlech komunikace
ARP odpovˇed’, kter´a pˇriˇrazuje fyzick´e adrese konkr´etn´ı IP adresu. Je-li zˇrejm´e, ˇze IP adresa nepoch´az´ı ze stejn´eho segmentu s´ıtˇe, automaticky se pro komunikaci pouˇzije fyzick´a adresa br´any. Nyn´ı je vˇse pˇripraveno, poˇc´ıtaˇc m˚ uˇze zapouzdˇrit pˇripraven´e IP pakety do r´amc˚ u a odeslat je na m´edium. Za nˇejak´ y ˇcas dostane odpovˇed’ od webov´eho serveru, kter´a doraz´ı ve formˇe r´amc˚ u na n´aˇs segment s´ıtˇe LAN, a cel´ y pr˚ uchod modelem TCP/IP bude nyn´ı prob´ıhat opaˇcnˇe. Dojde k rozbalen´ı r´amce a IP pakety se pˇrenesou do vyˇsˇs´ı internetov´e vrstvy. Po rozbalen´ı obsahu IP paketu doch´az´ı k rozbalen´ı TCP segmentu nebo UDP datagramu na u ´rovni transportn´ı vrstvy. Podle c´ılov´eho portu operaˇcn´ı syst´em pˇred´a data konkr´etn´ımu procesu na aplikaˇcn´ı vrstvˇe. Webov´ y prohl´ıˇzeˇc naˇcte webovou str´anku a uˇzivatel je spokojen.
2.2
Odposlech komunikace
Kdybychom si chtˇeli ovˇeˇrit, jak vypad´a komunikace na s´ıti a jak jsou jednotliv´e protokoly TCP/IP modelu zapouzdˇreny do sebe, m˚ uˇzeme vyuˇz´ıt n´astroje pro odposlech komunikace na s´ıti, kter´e se v anglick´e terminologii oznaˇcuj´ı jako sniffery. Typick´ ymi z´astupci jsou programy tcpdump nebo 2 whireshark .
2.2.1
TCP spojen´ı
Abychom dobˇre porozumˇeli odchycen´ ym paket˚ um s TCP protokolem, prozkoum´ame nejdˇr´ıve mechanismus vytvoˇren´ı TCP spojen´ı a jeho uzavˇren´ı. Obr´azek 2.2 zobrazuje klienta (vlevo), kter´ y chce zah´ajit komunikaci s webov´ ym serverem (vpravo).
Obr´azek 2.2: Tˇr´ıcestn´e ustaven´ı TCP spojen´ı V prvn´ım kroku klient zas´ıl´a TCP segment s nastaven´ ym pˇr´ıznakem SYN. V druh´em kroku protistrana potvrzuje obdrˇzen´ı SYN pˇr´ıznaku odesl´an´ım 2
whireshark je nov´e oznaˇcen´ı, p˚ uvodnˇe se tento produkt jmenoval ethereal
2.2 Odposlech komunikace
11
TCP segmentu s pˇr´ıznaky SYN a ACK. Nakonec klient potvrd´ı pˇrijat´ y paket TCP segmentem s pˇr´ıznakem ACK. Obˇe strany se t´ımto zp˚ usobem dohodly na vytvoˇren´ı kan´alu s garantovan´ ym pˇrenosem dat. Doˇslo k dohodˇe sekvenˇcn´ıch ˇc´ısel, kter´a jsou pro komunikaci vygenerov´ana. Jejich n´asledn´e sekvence budou oznaˇcovat poˇrad´ı paketu. Toto opatˇren´ı chr´an´ı TCP spojen´ı proti u ´nosu.
Obr´azek 2.3: Ukonˇcen´ı TCP spojen´ı Uzavˇren´ı TCP spojen´ı prob´ıh´a podle obr´azku 2.3 ve ˇctyˇrech kroc´ıch, kdy si obˇe strany vymˇen´ı TCP segmenty s FIN pˇr´ıznaky a vˇzdy si je navz´ajem potvrd´ı pˇr´ıznakem ACK.
2.2.2
Pˇ r´ıklad HTTP komunikace
N´asleduj´ıc´ı pˇr´ıklad ukazuje z´aznam HTTP komunikace mezi klientem s webov´ ym prohl´ıˇzeˇcem a webov´ ym serverem. Z´aznam komunikace byl vytvoˇren pomoc´ı n´astroje tcpdump, kter´ y jsem spustil pˇred zah´ajen´ım s´ıt’ov´e aktivity na s´ıt’ov´em rozhran´ı eth0 a pˇresmˇeroval jeho v´ ystup do souboru pro pozdˇejˇs´ı anal´ yzu. tcpdump -nXi eth0 > soubor_komunikace.txt Po ukonˇcen´ı komunikace v souboru nalezneme skupinu vyslan´ ych a doruˇcen´ ych paket˚ u. Kaˇzd´ y z´aznam je doplnˇen o ˇcasov´e raz´ıtko a smˇer komunikace, kter´a je vyj´adˇrena dvojicemi (IP_zdroje:port > IP_c´ ıle:port). D´ale n´asleduje z´aznam zachycen´eho paketu, kter´ y je vyj´adˇren skupinou hexadecim´aln´ıch ˇc´ıslic. Pro lepˇs´ı orientaci je v´ ypis doplnˇen v prav´em sloupci o informaci, kter´a v textov´e formˇe reprezentuje hexadecim´aln´ı z´apis paketu. Prozkoum´ame nyn´ı celou komunikaci, kter´a je zp˚ usobena poˇzadavkem na zobrazen´ı str´anky do webov´eho prohl´ıˇzeˇce. Klient, kter´ y ˇz´ad´a o komunikaci, m´a pˇriˇrazenu IP adresu 192.168.0.8. Nejdˇr´ıve se snaˇz´ı z´ıskat IP adresu webov´eho serveru, jenˇz chce poˇz´adat o zasl´an´ı webov´e str´anky. Sluˇzba, kter´a tento pˇreklad realizuje, se naz´ yv´a DNS. Kaˇzd´ y poˇc´ıtaˇc m´a nakonfigurov´anu IP adresu hostitelsk´eho stroje, kter´ y
Obr´azek 2.4: DNS poˇzadavek na pˇreklad adresy www.juhanak.cz sluˇzbu DNS realizuje. V naˇsem pˇr´ıkladˇe nejbliˇzˇs´ı DNS server leˇz´ı na IP adrese 212.96.162.2 a poslouch´a na portu 53, kde pˇrij´ım´a poˇzadavky klient˚ u. Za zm´ınku stoj´ı dodat, ˇze sluˇzba DNS je realizov´ana transportn´ım protokolem UDP. Po chv´ıli n´am DNS server odpov´ı zpˇet a prozrad´ı n´am, ˇze IP adresa webov´eho serveru je 82.208.58.92. Nyn´ı je situace zaj´ımavˇejˇs´ı a klient zahajuje komunikaci s webov´ ym serverem. Protoˇze komunikace aplikaˇcn´ıho protokolu HTTP je zajiˇstˇena transportn´ım protokolem TCP, mus´ı nejdˇr´ıve doj´ıt k ustaven´ı TCP spojen´ı pomoc´ı tˇr´ıf´azov´e v´ ymˇeny3 . Klient vyz´ yv´a webov´ y server k ustaven´ı spojen´ı a zas´ıl´a paket s pr´azdn´ ym TCP segmentem s pˇr´ıznakem SYN. 06:53:27.378570 IP 192.168.0.8.41385 > 82.208.58.92.80: S 1962769082:1962769082(0) win 5840 <mss 1460,sackOK,timestamp 208089 0> 0x0000: 00c0 4f62 6035 0018 f32f 11b9 0800 4500 ..Ob‘5.../....E. 0x0010: 003c 5663 4000 4006 967c c0a8 0008 52d0 .
Obr´azek 2.5: TCP handshaking (1) SYN Webov´ y server klientovi potvrzuje, ˇze obdrˇzel ˇz´adost o spojen´ı a potvrd´ı tuto skuteˇcnost zasl´an´ım TCP segmentu s pˇr´ıznaky SYN / ACK 06:53:27.378714 IP 82.208.58.92.80 > 192.168.0.8.41385: S 1487109809:1487109809(0) ack 1962769083 win 5792 <mss 1460,sackOK,timestamp 75348255 208089,nop,wscale 7> 0x0000: 0018 f32f 11b9 00c0 4f62 6035 0800 4500 .../....Ob‘5..E. 0x0010: 003c 0000 4000 3606 f6df 52d0 3a5c c0a8 .<[email protected].:\.. 0x0020: 0008 0050 a1a9 58a3 7eb1 74fd 7abb a012 ...P..X.~.t.z... 0x0030: 16a0 8ff3 0000 0204 05b4 0402 080a 047d ...............} 0x0040: b91f 0003 2cd9 0103 0307 ....,.....
Obr´azek 2.6: TCP handshaking (2) SYN / ACK 3
V anglick´em jazyce se tato situace oznaˇcuje jako 3 way handshaking, tedy potˇr´ as´ an´ı rukou natˇrikr´ at mezi obˇema u ´ˇcastn´ıky komunikace
2.2 Odposlech komunikace
13
Nyn´ı klient obdrˇzel potvrzen´ı, ˇze server bude komunikovat a jeˇstˇe jednou potvrd´ı serveru, ˇze jeho paket obdrˇzel. 06:53:27.378808 IP <nop,nop,timestamp 0x0000: 00c0 4f62 0x0010: 0034 5664 0x0020: 3a5c a1a9 0x0030: 00b7 d4a5 0x0040: b91f
Obr´azek 2.7: TCP handshaking (3) ACK Nyn´ı je TCP spojen´ı ustaveno a klient zaˇc´ın´a v datov´e ˇc´asti TCP segmentu pos´ılat data webov´emu serveru, jehoˇz sluˇzba poslouch´a na portu 80. V pr˚ ubˇehu TCP spojen´ı obˇe strany potvrzuj´ı veˇsker´e doˇsl´e pakety. TCP spojen´ı je ukonˇceno, pokud obˇe strany vyˇslou paket s pˇr´ıznaky FIN a obˇe strany potvrd´ı tuto skuteˇcnost ACK pˇr´ıznaky. 06:53:27.378861 IP P 1:401(400) ack 1 0x0000: 00c0 4f62 0x0010: 01c4 5665 0x0020: 3a5c a1a9 0x0030: 00b7 f8ab 0x0040: b91f 4745 0x0050: 0d0a 486f
Pˇredchoz´ı v´ ypisy zachytily komunikaci pˇri poˇzadavku na zobrazen´ı webov´e str´anky. Protoˇze ve v´ ypisech nejsou zobrazeny r´amce, vidˇeli jsme pouze IP protokol a v jeho datov´e ˇc´asti jsme nalezli data jin´ ych protkol˚ u. Obr´azek A.3 demonstruje pouˇzit´ı aplikace Whireshark, kter´a umoˇzn ˇuje l´epe vizualizovat s´ıt’ov´ y provoz. Prvn´ı v hiearchii vid´ıme ethernetov´ y r´amec s fyzickou adresou zdroje a c´ıle (48 bit MAC adresy) . Uvnitˇr r´amce najdeme protokol IP, kter´ y adresuje zdroj a c´ıl logick´ ymi IP adresami. Za hlaviˇckou IP protokolu se nach´az´ı jeho datov´a ˇc´ast, kde nalezneme transportn´ı protokol TCP. V hlaviˇcce transportn´ıho protokolu je specifikov´an c´ılov´ y port 80, kter´ y oznaˇcuje webovou sluˇzbu. Pokud se pod´ıv´ame do datov´e ˇc´asti TCP segmentu, m˚ uˇzeme vidˇet protokol HTTP a jeho data, ze kter´ ych lze vyˇc´ıst, ˇze se jedn´a o poˇzadavek na str´anku z dom´eny sourceforge.net.
14
2.2 Odposlech komunikace
Kapitola 3
Linuxov´ y firewall iptables Tato kapitola struˇcnˇe popisuje paketov´ y filtr iptables a tvorbu pravidel.
3.1
Netfilter
Netfilter je framework pro spr´avu paket˚ u v linuxov´em j´adˇre. Framework program´ator˚ um poskytuje z´achytn´e body ve formˇe h´aˇck˚ u (hooks), kter´e si m˚ uˇzeme pˇredstavit jako m´ısto, kde si program´ator zaregistruje sv´eho posluchaˇce, kter´ y ho bude upozorˇ novat v pˇr´ıpadˇe vznikl´e ud´alosti, napˇr. pˇri pˇr´ıchodu paketu. Netfilter umoˇzn ˇuje pakety modifikovat a vracet je zpˇet j´adru. D´ıky t´eto vlastnosti lze realizovat pˇreklady adres a modifikovat hlaviˇcky s´ıt’ov´ ych protokol˚ u.
3.2
Iptables
Iptables je softwarov´ y stavov´ y firewall postaven´ y nad frameworkem Netfilter. Umoˇzn ˇuje filtrov´an´ı paket˚ u a funkci NAT. Definuje skupinu tabulek, do kter´ ych uˇzivatel vol´an´ım aplikace iptables registruje pravidla do ˇretˇezc˚ u. Kaˇzd´ y pˇreddefinovan´ y ˇretˇezec v´ yznamovˇe odpov´ıda h´ aˇck˚ um, kter´e definuje framework Netfilter.
3.2.1
Tabulky
Iptables logicky rozdˇeluj´ı zp˚ usob pr´ace s pakety pomoc´ı tabulek. Kaˇzd´a tabulka m´a pˇreddfinov´any ˇretˇezce nad kter´ ymi uˇzivatel vytv´aˇr´ı pravidla. Uˇzivatel m´a moˇznost v kaˇzd´e tabulce definovat vlastn´ı ˇretˇezce, kter´e jsou vhodn´e pro udrˇzen´ı pˇrehlednosti nebo sv´ ym n´azvem vystihuj´ı logiku pravidel. Iptables definuj´ı tyto tabulky: • filter • nat
16
3.2 Iptables • mangle • raw
Tabulka filter Tabulka filter je implicitn´ı tabulkou firewallu. Pokud chce uˇzivatel explicitnˇe pracovat s jinou tabulkou, pomoc´ı pˇrep´ınaˇce -t uvede konkr´etn´ı tabulku. Tabulka filter obsahuje pˇreddefinovan´e ˇretˇezce: • INPUT - pˇr´ıchoz´ı paket je adresov´an pˇr´ımo na lok´aln´ı stroj (firewall) • OUTPUT - paket byl vytvoˇren na lok´aln´ım stroji a chce odej´ıt • FORWARD - paket nen´ı urˇcen pro lok´aln´ı stroj a jen proch´ az´ı Tabulka nat Tabulka nat, jak uˇz jej´ı n´azev napov´ıd´a, je urˇcena pro pˇreklad adres, tzn. modifikaci zdrojov´ ych a c´ılov´ ych IP adres a jejich port˚ u. Nad tabulkou nat jsou definov´any ˇretˇezce: • PREROUTING - pˇr´ıchoz´ı paket je odchycen pˇred smˇerov´an´ım • OUTPUT - paket byl vytvoˇren na lok´aln´ım stroji a je odchycen pˇred smˇerov´an´ım • POSTROUTING - odchoz´ı paket jiˇz proˇsel smˇerov´an´ım a chce odej´ıt Tato tabulka je z´aludn´a v tom, ˇze pˇreklad adres se uplatˇ nuje jen pˇri vytv´aˇren´ı nov´eho spojen´ı. Iptables si spojen´ı vnitˇrnˇe oznaˇc´ı a pˇreklad se dˇeje transparentnˇe. Pro uˇzivatele to znamen´a, ˇze veˇsker´a pravidla, kter´a zde vytvoˇr´ıme, se uplatn´ı jen pro prvn´ı paket spojen´ı. Dalˇs´ı pakety v ustaven´em spojen´ı uˇz do tabulky nat nevstupuj´ı. Tabulka mangle Nev´ yhodu pˇredeˇsl´e tabulky odstraˇ nuje tabulka mangle, kter´a se pouˇz´ıv´a pro modifikaci paket˚ u za kaˇzd´e situace. Tabulka definuje tyto ˇretˇezce: • PREROUTING - pˇr´ıchoz´ı paket je odchycen pˇred smˇerov´an´ım • INPUT - pˇr´ıchoz´ı paket je adresov´an pˇr´ımo na lok´aln´ı stroj • OUTPUT - paket byl vytvoˇren na lok´aln´ım stroji a je odchycen pˇred smˇerov´an´ım • POSTROUTING - odchoz´ı paket jiˇz proˇsel smˇerov´an´ım a chce odej´ıt • FORWARD - paket nen´ı urˇcen pro lok´aln´ı stroj a jen proch´ az´ı
3.2 Iptables
17
Tabulka raw Posledn´ı tabulka je urˇcena pro trasovac´ı u ´ˇcely a definuje ˇretˇezce • PREROUTING - pˇr´ıchoz´ı paket z jak´ehokoliv rozhran´ı • OUTPUT - vˇsechny lok´alnˇe generovan´e pakety
3.2.2
Pravidla
Pravidla se zapisuj´ı ve tvaru: iptables [-t tabulka] [operace_nad_ˇ retˇ ezcem] [podm´ ınka] [-j skok] Kaˇzd´e pravidlo je definov´ano nad tabulkou a ˇretˇezcem, kter´ y m˚ uˇze b´ yt uˇzivatelsk´ y nebo pˇreddefinovan´ y. D´ale n´asleduje zachyt´avac´ı podm´ınka, kter´a urˇcuje, kdy pravidlo vyhovuje. Skok na c´ıl urˇcuje, co se s paketem provede, pokud vyhovˇel zachyt´avac´ı podm´ınce. N´asleduj´ıc´ı z´apis pravidla zp˚ usob´ı zahazov´an´ı paket˚ u s protokolem TCP urˇcen´ ych na port 80 (HTTP): iptables -t filter -A FORWARD -p tcp --dport 80 -j DROP Protoˇze tabulka filter je implicitn´ı, lze cel´ y parametr -t filter vynechat. Dalˇs´ı pˇr´ıklady pravidel jsou uvedeny v kapitole 4.1.2.
3.2.3
C´ıle skoku
U kaˇzd´eho pravidla m˚ uˇzeme definovat c´ıl, tedy co se m´a s paketem prov´est, pokud pravidlu vyhov´ı. Za z´akladn´ı c´ıle skoku m˚ uˇzeme povaˇzovat tyto: • ACCEPT - paket vyhovˇel, uˇz neproch´az´ı dalˇs´ımi pravidly • DROP - paket zahozen • REJECT - paket zahozen, poˇsle vˇsak zdroji ICMP zpr´avu o odm´ıtnut´ı • QUEUE - poˇsle paket do uˇzivatelsk´eho prostoru1 • RETURN - skok na konec ˇretˇezce, coˇz zp˚ usob´ı n´avrat do rodiˇcovsk´e vˇetve pravidel, osud paketu z´avis´ı na nadˇrazen´ ych pravidlech, nebo skonˇc´ı v implicitn´ı politice firewallu. • SNAT, DNAT, MASQUERADE2 - tyto skoky slouˇz´ı pro pr´aci s pˇrekladem adres. 1 Pod uˇzivatelsk´ ym prostorem se mysl´ı aplikace, kter´ a m´ a z´ ajem pakety zkoumat, napˇr´ıklad syst´emy pro detekci pr˚ uniku (IDS) 2 Maˇskar´ ada (MASQUERADING) je transparentn´ı pˇr´ıpad pˇrekladu zdrojov´ ych adres (SNAT) bez nutnosti specifikovat rozsahy zdrojov´ ych port˚ u.
18
3.2 Iptables
Iptables pouˇz´ıvaj´ı dalˇs´ı c´ıle skoku, kter´e rozˇsiˇruj´ı funkˇcnost firewallu a je moˇzn´e je podrobnˇe prostudovat v dokumentaci. Za zm´ınku stoj´ı c´ılov´ y skok s n´azvem LOG, kter´ y zp˚ usob´ı, ˇze informace o paketu se poˇslou syst´emov´emu d´emonu syslogd, kter´ y zap´ıˇse z´aznam do souboru /var/log/messages, pokud nen´ı nen´ı nastaveno jinak. To je vhodn´e napˇr. pro detekci u ´toku3 .
3.2.4
Pr˚ uchod tabulkami a ˇ retˇ ezci
Jakmile paket doraz´ı do j´adra operaˇcn´ıho syst´emu, j´adro klasifikuje zda paket: • byl adresov´an pˇr´ımo na lok´aln´ı stroj • byl vytvoˇren na lok´aln´ım stroji a odch´az´ı • proch´az´ı, nen´ı adresov´an na lok´aln´ı stroj (FORWARDING) Algoritmus popisuj´ıc´ı pr˚ uchod paketu paketov´ ym filtrem, kter´ y je vyj´adˇren n´asleduj´ıc´ımi tabulkami, jsem pˇrevzal z dokumentace iptables [2]. Obr´azek A.4 pak zachycuje cel´ y rozhodovac´ı algoritmus komplexnˇe. Pˇ r´ıchoz´ı paket Pˇredpokladem je, ˇze paket dorazil na s´ıt’ov´e rozhran´ı a ovladaˇc tohoto zaˇr´ızen´ı informoval linuxov´e j´adro, ˇze v pamˇet’ov´em prostoru m´a pˇripraven pˇr´ıchoz´ı paket. J´adro tuto ud´alost zpracuje asynchronnˇe a paket logicky putuje pˇres paketov´ y filtr podle tabulky 3.2. Odchoz´ı paket Odchoz´ı paket, kter´ y byl vytvoˇren na lok´aln´ım stroji, jehoˇz IP adresa je uvedena jako zdrojov´a v IP hlaviˇcce, byl vygenerov´an lok´aln´ı aplikac´ı. Paket proˇsel smˇerov´an´ım, aby se vybralo s´ıt’ov´e rozhran´ı, kter´e se pouˇzije pro odchod paketu. Nyn´ı paket putuje v j´adˇre podle postupu uveden´eho v tabulce 3.3. Pr˚ uchoz´ı paket Pˇredpokl´ad´ame situaci, kdy se na firewall dostane paket, kter´ y je adresov´an jin´emu hostitelsk´emu poˇc´ıtaˇci v s´ıti a pˇres firewall pouze proch´az´ı. Tabulka 3.1 zachycuje tuto situaci. 3
Pˇredpokladem je, ˇze syst´emov´ y administr´ ator tyto soubory pravidelnˇe ˇcte.
3.2 Iptables
3.2.5
19
Politiky
V pˇr´ıpadˇe, kdy firewall projde vˇsechna pravidla pro dan´ y paket a ten ˇz´adn´e z nich nevyhov´ı, z´aleˇz´ı na politice firewallu, zda paket pust´ı nebo ne. Politika je tedy posledn´ı soud pro paket, kter´emu se podaˇrilo prokliˇckovat” mezi ” vˇsemi pravidly. V´ ychoz´ı politika firewallu se definuje pˇr´ıkazem: iptables -P {INPUT|OUTPUT|FORWARD} {ACCEPT|DROP} V podstatˇe existuj´ı dva pˇr´ıstupy pˇri tvorbˇe v´ ychoz´ı politiky: • Politikou vˇse zak´aˇzu a explicitn´ımi pravidly povol´ım v´ yjimky. • Politikou vˇse povol´ım a explicitn´ımi pravidly zak´aˇzu definovan´a spojen´ı. V´ yhody a nev´ yhody obou variant jsou zˇrejm´e. Prvn´ı varianta je bezpeˇcn´a, ale nen´ı pohodln´a, protoˇze aby vˇse fungovalo, mus´ı administr´ator zn´at vˇsechny typy spojen´ı a ruˇcnˇe je povolit. Vˇetˇsinou se jedn´a o dlouhodob´ y proces. Druh´a varianta je z hlediska bezpeˇcnostni naivn´ı, ale pro administr´atora pohodln´a. Pˇr´ıklad v´ ychoz´ı politiky, kter´a zahazuje vˇse co nen´ı povoleno, by vypadala takto: iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
3.2.6
Stav konfigurace firewallu
Pro pr´aci s paketov´ ym filtrem iptables je kromˇe definice pravidel uˇziteˇcn´e zobrazit si aktu´aln´ı konfiguraci firewallu. M˚ uˇzeme pouˇz´ıt pˇr´ıkaz: iptables -L [-t tabulka] [ˇ retˇ ezec], kde pˇrep´ınaˇc -L diktuje zobrazit seznam pravidel (LIST) a pˇrep´ınaˇc -t urˇcuje tabulku, se kterou chceme pracovat. Neuvedeme-li explicitnˇe tabulku, bude vyps´ana implicitn´ı tabulka filter. Parametr pro specifikaci ˇretˇezce nen´ı povinn´ y. Nen´ı-li uveden, vyp´ıˇs´ı se vˇsechny ˇretˇezce definovan´e nad tabulkou. D´ale m´ame moˇznost pouˇz´ıt pˇr´ıkaz urˇcen´ y pro nativn´ı export pravidel, jenˇz je znakovˇe ˇciteln´ y. iptables-save [-c] [-t tabulka] Pokud neuvedeme argumenty, zobraz´ı se cel´a konfigurace firewallu, kterou je vhodn´e pˇresmˇerovat do souboru. Pˇrep´ınaˇc -c, slouˇz´ı k zachov´an´ı ˇc´ıtaˇc˚ u (counters), kter´e se sleduj´ı pro statistick´e u ´ˇcely. Zb´ yvaj´ıc´ı argument m´a stejn´ y v´ yznam jako v pˇredchoz´ım pˇr´ıkladˇe. Pro zpˇetn´ y import pravidel, napˇr. po restartu poˇc´ıtaˇce, slouˇz´ı pˇr´ıkaz iptables-restore.
20
krok 1
3.2 Iptables
tabulka raw
ˇ retˇ ezec PREROUTING
3
mangle
PREROUTING
4
nat
PREROUTING
6
mangle
FORWARD
7
mangle
POSTROUTING
8
nat
POSTROUTING
2
5
9
koment´ aˇ r Opˇet m˚ uˇzeme v tomto m´ıstˇe oznaˇcit paket, aby nebyl zachycen trasovac´ım syst´emem. Trasovac´ı syst´emy na tomto m´ıstˇe jiˇz sleduj´ı spojen´ı. Tento ˇretˇezec je pouˇz´ıv´an pro modifikaci paket˚ u pˇred smˇerov´an´ım, napˇr. zmˇena TOS pol´ı. Tento ˇretˇezec se pouˇz´ıv´a pro DNAT. J´adro prov´ad´ı znovu smˇerov´an´ı paket˚ u, zda se paket bude pˇresmˇerov´avat na jin´e rozhran´ı. Tato konfigurace tabulky a ˇretˇezce se pouˇz´ıv´a pro speci´aln´ı pˇr´ıpady, kdy chceme modifikovat paket, kter´ y proˇsel smˇerovac´ım rozhodnut´ım. Pˇres tento ˇretˇezec putuje vˇsechen provoz nez´avisle na smˇeru. V tomto ˇretˇezci m˚ uˇzeme modifikovat pakety, ale bez moˇznosti ovlivnit smˇerovac´ı rozhodnut´ı, kter´e uˇz bylo vykon´ano. Na tomto m´ıstˇe prov´ad´ıme SNAT. Paket odch´az´ı na urˇcen´e s´ıt’ov´e rozhran´ı.
Tabulka 3.1: Pr˚ uchod traverzuj´ıc´ıho paketu paketov´ ym filtrem
3.2 Iptables
krok 1
21
tabulka raw
ˇ retˇ ezec PREROUTING
3
mangle
PREROUTING
4
nat
PREROUTING
6
mangle
INPUT
7
filter
INPUT
2
5
8
koment´ aˇ r Tento ˇretˇezec pracuje s pakety jeˇstˇe pˇred t´ım, neˇz jak´ ykoliv trasovac´ı syst´em zachyt´ı provoz. Tato konfigurace tabulky a ˇretˇezce se pouˇz´ıv´a pro ladˇen´ı nebo pro specifick´a spojen´ı, kter´a nemaj´ı b´ yt zachycena trasovac´ımi syst´emy. Trasovac´ı syst´emy jiˇz na tomto m´ıstˇe sleduj´ı vˇsechna spojen´ı. Tento ˇretˇezec je obvykle pouˇz´ıv´an pro modifikaci paket˚ u pˇred smˇerov´an´ım, napˇr. zmˇena TOS pol´ı. Tento ˇretˇezec se nejv´ıce pouˇz´ıv´a pro DNAT. J´adro prov´ad´ı smˇerov´an´ı paket˚ u. Tento ˇretˇezec se pouˇz´ıv´a pro zachycen´ı paketu, kter´ y proˇsel smˇerov´an´ım a jeˇstˇe nedorazil k c´ılov´emu procesu. V tomto ˇretˇezci filtrujeme vˇsechen provoz urˇcen´ y na lokaln´ı stroj bez ohledu na to, z jak´eho s´ıt’ov´eho rozhran´ı provoz pˇriˇsel. Paket dorazil k lok´aln´ımu procesu.
Tabulka 3.2: Pr˚ uchod paketov´ ym filtrem - pˇr´ıchoz´ı paket
22
krok 1
3.2 Iptables
tabulka raw
ˇ retˇ ezec OUTPUT
3
mangle
OUTPUT
4
nat
OUTPUT
6
filter
OUTPUT
7
mangle
POSTROUTING
8
nat
POSTROUTING
2
5
9
koment´ aˇ r Tento ˇretˇezec pracuje s pakety jeˇstˇe pˇred t´ım, neˇz jak´ ykoliv trasovac´ı syst´em zachyt´ı provoz. Trasovac´ı syst´emy na tomto m´ıstˇe jiˇz sleduj´ı spojen´ı. Tento ˇretˇezec je obvykle pouˇz´ıv´an pro modifikaci paket˚ u pˇred smˇerov´an´ım, napˇr. zmˇena TOS pol´ı. Tento ˇretˇezec se nejv´ıce pouˇz´ıv´a pro NAT lok´alnˇe vytvoˇren´ ych paket˚ u. J´adro prov´ad´ı znovu smˇerov´an´ı paket˚ u, protoˇze tabulka mangle a nat mohla ovlivnit smˇerovac´ı rozhodnut´ı. V tomto ˇretˇezci filtrujeme odch´azej´ıc´ı pakety vznikl´e na firewallu. V tomto ˇretˇezci m˚ uˇzeme modifikovat pakety, ale bez moˇznosti ovlivnit smˇerovac´ı rozhodnut´ı, kter´e uˇz bylo vykon´ano. Najdeme zde i pakety, kter´e firewallem proch´azej´ı. Na tomto m´ıstˇe prov´ad´ıme SNAT. Paket odch´az´ı na urˇcen´e s´ıt’ov´e rozhran´ı.
Tabulka 3.3: Pr˚ uchod paketov´ ym filtrem - odchoz´ıho paket
Kapitola 4
Experiment´ aln´ı u ´ lohy s iptables C´ılem sady experiment˚ u je zjistit, jak´e jsou hranice linuxov´eho firewallu zaloˇzen´eho na iptables a kdy je firewall na hranici sv´ ych moˇznost´ı. Pˇredmˇetem zkoum´an´ı je softwarov´ y firewall iptables 1.3.8, kter´a bˇeˇz´ı na linuxov´em kernelu verze 2.6.21. Verze operaˇcn´ıho syst´emu (j´adra) je d˚ uleˇzit´a, protoˇze zp˚ usob pr´ace se vstupn´ımi frontami z´asadnˇe ovlivˇ nuje chov´an´ı firewallu a je z´avisl´a na implementaci operaˇcn´ıho syst´emu. Anal´ yza experiment˚ u se op´ır´a o aplikaci tcpdump 3.9.5 s knihovnou libpcap v0.9.5, kter´a umoˇzn ˇuje monitoring provozu na s´ıt’ov´ ych rozhran´ıch.
4.1
Pˇ r´ıprava
Nejdˇr´ıve jsem musel vytvoˇrit prostˇred´ı, ve kter´em bych dok´azal vyprodukovat dostateˇcnˇe velkou z´atˇeˇz, abych firewall tzv. utahal”, protoˇze bez vhodn´e ” z´atˇeˇze nemohu pozorovat v´ yrazn´a zpoˇzdˇen´ı. Protoˇze nejsem spr´avcem ˇz´adn´eho syst´emu, kde bych mohl sledovat firewall na re´aln´e z´ atˇeˇzi, musel jsem takov´e prostˇred´ı vybudovat. D´ale jsem se musel zamyslet, jak sledovat veliˇciny, kter´e jsou pˇredmˇetem m´eho z´ajmu, a jak vˇsechna mˇeˇren´ı uspoˇr´adat.
4.1.1
Testovac´ı prostˇ red´ı
Prvn´ım krokem je vytvoˇren´ı testovac´ıho prostˇred´ı, kter´e bude spoleˇcn´e pro prvn´ı dva experimenty. Hostitelsk´ y poˇc´ıtaˇc laptop slouˇz´ı jako bud´ıc´ı prvek a spojen´ı, kter´e navazuje na poˇc´ıtaˇc dell-NAT. Abych se vyhnul vlivu aktivn´ıho prvku (hub), je dvojice poˇc´ıtaˇc˚ u dell-NAT a theresa-NAT propojena pˇr´ımo kˇr´ıˇzen´ ym kabelem, kter´ y je oznaˇcen ˇcervenˇe. Linuxov´ y firewall, kter´ y je pˇredmˇetem zkoum´an´ı, je provozov´an na poˇc´ıtaˇci dell-NAT. Zbyl´ y hostitelsk´ y poˇc´ıtaˇc
24
4.1 Pˇr´ıprava
Obr´azek 4.1: Testovac´ı prostˇred´ı desktop je vyuˇz´ıv´an pouze pro reporty vˇzdy po ukonˇcen´ı experimentu. Parametry jednotliv´ ych prvk˚ u naleznete v pˇr´ıloze.
4.1.2
Vytvoˇ ren´ı z´ atˇ eˇ ze
Z´atˇeˇz lze doc´ılit dvˇema zp˚ usoby; bud’ nashrom´aˇzdˇen´ım dostateˇcn´eho poˇctu klientsk´ ych stanic, kter´e budou vytv´aˇret spojen´ı pˇres firewall, nebo zahlcen´ım firewallu provozem vznikaj´ıc´ım z dvojice stroj˚ u realizuj´ıc´ıch pˇreklad adres, kter´e po urˇcitou dobu vracej´ı pakety pˇres firewall tam a zpˇet. Z obr´azku je patrn´e, ˇze jsem si zvolil druh´ y zp˚ usob. Jak jsem uˇz naznaˇcil, bud´ıc´ım prvkem je poˇc´ıtaˇc laptop; ten generuje TCP SYN pakety na poˇc´ıtaˇc dell-NAT na port 81 pomoc´ı konzolov´e aplikace hping. Perioda vys´ıl´an´ı je voliteln´a. Hostitelsk´e jm´eno poˇc´ıtaˇce dell-NAT napov´ıd´a, ˇze pln´ı funkci pˇrekladu adres, a to adres c´ılov´ ych (DNAT - Destinantion NAT). Vˇsechny pakety obsahuj´ıc´ı protokol TCP s n´ıˇze uveden´ ymi porty budou pˇreposl´any na hostitele theresa-NAT podle tˇechto pravidel. iptables iptables iptables iptables iptables
Obr´azek 4.2: dell-NAT: pravidla pro pˇreklad c´ılov´ ych adres a port˚ u Kdyˇz na port 80 hostitelsk´eho poˇc´ıtaˇce dell-NAT doraz´ı TCP SYN paket, linuxov´ y firewall projde seznam pravidel. V ˇretˇezci PREROUTING odchyt´ı paket jeˇstˇe pˇred okamˇzikem, neˇz linuxov´e j´adro rozhodne o smˇerov´an´ı paketu. Protoˇze prvn´ı pravidlo vyhovuje, firewall zmˇen´ı c´ılovou IP adresu a port na 192.168.0.4:82, coˇz je IP adresa stroje theresa-NAT Paket d´ale
4.1 Pˇr´ıprava
25
pokraˇcuje po ˇcervenˇe oznaˇcen´em spoji na druh´ y stroj theresa-NAT na port 82. Na stroji theresa-NAT je tak´e linuxov´ y firewall s podobnou sadou pravidel, kter´a vracej´ı pakety zpˇet na IP adresu stroje dell-NAT, a to na porty s lich´ ymi ˇc´ısly. Vznik´a tak paketov´ y ping pong”, kdy paket doraz´ı nejprve na ” stroj dell-NAT na port 81. N´aslednˇe se paket postupnˇe pohybuje mezi stroji dell-NAT, theresa-NAT a inkrementuje se ˇc´ıslo portu, dokud nedos´ahne hodnoty 91. iptables iptables iptables iptables iptables
Obr´azek 4.3: theresa-NAT: pravidla pro pˇreklad c´ılov´ ych adres a port˚ u
4.1.3
Zpoˇ zdˇ en´ı paketu
Po sestrojen´ı testovac´ıho prostˇred´ı jsem se zamyslel, jak zjistit hodnotu zpoˇzdˇen´ı paketu, kter´a je kl´ıˇcov´a. Sestavil jsem sadu skript˚ u, kter´e nad logem s´ıt’ov´eho provozu, zachycen´eho pomoc´ı n´astroje tcpdump prov´adˇej´ı n´asleduj´ıc´ı algoritmus: • vyberu z´aznamy paket˚ u s c´ılov´ ym portem 83 a 84 (pˇr´ıchoz´ı a odchoz´ı) • setˇr´ıd´ım je podle sekvenˇcn´ıho ˇc´ısla paketu (nemˇen´ı se vlivem DNAT) • z´ısk´av´am nad sebou dvojice pˇr´ıchoz´ıch a odchoz´ıch paket˚ u • odeˇctu ˇcas pˇr´ıchodu a odchodu paketu a z´ısk´av´am zpoˇzdˇen´ı • sestav´ım datov´ y soubor z dvojic (ˇc´ıslo paketu, zpoˇzdˇen´ı) pro vizualizaci n´astrojem gnuplot
4.1.4
Kapacita media a velikost paketu
Hostitelsk´ y stroj s firewallem iptables je provozov´an na technologii 100 Mbit Ethernetu. Tabulka 4.1 zobrazuje teoretickou kapacitu, kter´e je moˇzno na medium dos´ahnout. Podle velikosti paketu, kter´a je byla ve vˇsech experimentech 1 500B, vypoˇc´ıt´ame hustotu toku v paketech za sekundu.
26
4.2 Experiment prvn´ı - zjiˇstˇen´ı pracovn´ı oblasti firewallu
technologie 10 Mbit Ethernet 100 Mbit Ethernet
max. tok [Mbit/s] 10 100
velikost paketu [B] 1 500 1 500
max. tok [p/s] 833 8 333
Tabulka 4.1: Kapacita media
4.2
Experiment prvn´ı - zjiˇ stˇ en´ı pracovn´ı oblasti firewallu
Experiment vych´az´ı z testovac´ıho prostˇred´ı a generov´ an´ı TCP SYN paket˚ u, kter´e byly pops´any v kapitole 4.1.1. Takto vznikl´ y provoz se nepodob´a skuteˇcn´emu TCP toku a m´a sp´ıˇse charakter u ´toku. Proto je tok tvoˇren´ y TCP segmenty s pˇr´ızakem SYN ten nejhorˇs´ı pˇr´ıpad, a tud´ıˇz vhodn´ y k hled´an´ı pracovn´ı oblasti. Pˇr´ıjemn´a vlastnost TCP/SYN paket˚ u je, ˇze nedoch´az´ı k ˇr´ızen´ı toku na u ´rovni protokolu TCP, protoˇze se spojen´ı nikdy korektnˇe neustav´ı a gener´ator neˇcek´a na ACK odpovˇed’ .
4.2.1
C´ıle a pˇ redpoklady
Firewall se bude chovat jistˇe odliˇsnˇe v pˇr´ıpadˇe zvyˇsuj´ıc´ıho se vstupn´ıho toku a v pˇr´ıpadˇe rostouc´ıho souboru pravidel. C´ılem je naj´ıt pracovn´ı oblast, ve kter´e se firewall jeˇstˇe chov´a pˇredv´ıdatelnˇe a m´a dostatek syst´emov´ ych zdroj˚ u. N´asleduj´ıc´ı dvˇe pod´ ulohy experimentu odhal´ı pracovn´ı oblast firewallu, jeˇz bude pozdˇeji pouˇzita jako hraniˇcn´ı ve vˇsech dalˇs´ıch experimentech.
4.2.2
Klidov´ y reˇ zim
Nejdˇr´ıve jsem potˇreboval naj´ıt klidov´ y reˇzim firewallu, abych zjistil, jak´ y je pr˚ ubˇeh zpoˇzdˇen´ı paket˚ u pˇri n´ızk´e z´atˇeˇzi, a pouˇzil vznikl´ y diagram z´atˇeˇze jako referenˇcn´ı. Volil jsem minim´aln´ı vstupn´ı tok a ponechal 10 pravidel nutn´ ych pro DNAT, nezbytnou funkci testovac´ıho prostˇred´ı. Zpoˇzdˇen´ı paket˚ u pˇri n´ızk´e z´atˇeˇzi je zn´azornˇeno na obr´azku A.5 v pˇr´ıloze, kde se zpoˇzdˇen´ı pohybuje maxim´alnˇe do 250 µs. Po celou dobu mˇeˇren´ı je tato hranice nemˇenn´a.
4.2.3
Mezn´ı vstupn´ı tok
V t´eto u ´loze jsem hledal hodnotu mezn´ıho vstupn´ıho toku, kter´a v´ yraznˇe ovlivn´ı chov´an´ı firewallu a zpoˇzdˇen´ı pˇr´ıchoz´ıch paket˚ u. Hodnota mezn´ıho toku omez´ı oblast mˇeˇren´ı, v n´ıˇz nebude m´ıt smysl prov´adˇet dalˇs´ı experimenty. Mezn´ı hodnotu vstupn´ıho datov´eho toku jsem urˇcil pokusem, pˇri
4.3 Experiment druh´ y - soubory pravidel
27
kter´em jsem postupnˇe zvyˇsoval velikost vstupn´ıho toku a sledoval vliv na zpoˇzdˇen´ı paketu. Hraniˇcn´ı tok je 8 300 p/s, je to omezen´ı vypl´ıvaj´ıc´ı z kapacity media.
4.2.4
Pozorov´ an´ı
Experiment uk´azal, ˇze pracovn´ı oblast firewallu je v nejhorˇs´ım pˇr´ıpadˇe omezena mezn´ım tokem 7000 paket˚ u za sekundu. Po dosaˇzen´ı t´eto hranice se firewall chov´a nepˇredv´ıdatelnˇe a zpoˇzdˇen´ı pro pˇr´ıchoz´ı pakety je r˚ uzn´e podle toho, zda paket pˇriˇsel v obdob´ı doˇcasn´e saturace firewallu, nebo ne. Obr´azek A.6 zn´azorˇ nuje chov´an´ı firewallu po dosaˇzen´ı mezn´ıho toku. Vid´ıme zde periodick´e kol´ıs´an´ı zpoˇzdˇen´ı, kdy po urˇcitou dobu razantnˇe naroste doba na odbaven´ı paket˚ u a na kr´atkou dobu se firewall zase uklidn´ı. D´ale jsem zkouˇsel nˇekolikr´at pˇrekroˇcit mezn´ı tok. U tok˚ u pˇrekraˇcuj´ıc´ıch 8000 paket˚ u za sekundu se firewall dost´av´a do oblasti, kdy s´ıt’ov´ y provoz spotˇrebuje veˇsker´ y procesn´ı ˇcas. Tato ud´alost m´a vliv i na bˇeh ostatn´ıch u ´loh operaˇcn´ıho syst´emu. Situace je zaj´ımav´a z bezpeˇcnostn´ıho hlediska a bylo by vhodn´e detailnˇe prozkoumat, zda firewall pakety zahod´ı, pˇrestane u ´plnˇe pracovat, nebo nˇekter´e pakety propust´ı bez pˇrezkoum´an´ı souboru pravidel.
4.3
Experiment druh´ y - soubory pravidel
Velikost soubor˚ u pravidel ovlivˇ nuje chov´an´ı firewallu ve dvou rovin´ach. Pˇri kaˇzd´em obslouˇzen´ı paketu mus´ı firewall proj´ıt seznam vˇsech pravidel a urˇcit, zda paket vyhovuje nˇekter´emu z nich. Coˇz znamen´a, ˇze s rostouc´ım poˇctem pravidel se zvyˇsuje doba na odbaven´ı paketu. Druh´ ym vlivem na zpoˇzdˇen´ı paketu je charakter pravidel. Kaˇzd´e pravidlo m´a r˚ uznou reˇzii na vyhodnocen´ı, zda vyhovuje, ˇci nikoliv.
4.3.1
C´ıle a pˇ redpoklady
C´ılem experimentu je zjistit, jak´ y vliv m´a zvˇetˇsov´an´ı soubor˚ u pravidel na zpoˇzdˇen´ı. Vstupn´ı tok je pˇrizp˚ usobov´an tak, aby smˇerodatn´a odchylka nepˇrekroˇcila 20µs od stˇredn´ı hodnoty. Jinak ˇreˇceno, zaj´ım´a mˇe vliv objemu pravidel na zpoˇzdˇen´ı, nikoliv vliv typu pravidel na v´ ykon firewallu. Protoˇze odeˇc´ıt´an´ı zpoˇzdˇen´ı paket˚ u v testovac´ım prostˇred´ı je zaloˇzeno na realizaci NAT, jsou sady pravidel definov´any nad ˇretˇezcem PREROUTING. Pˇredpokl´ad´am tedy, ˇze firewall by se nechoval jinak v pˇr´ıpadˇe, kdyby r˚ uzn´e objemy pravidel byly definov´any nad ostatn´ımi ˇretˇezci firewallu.
4.3.2
Parametry experimentu
Mˇeˇril jsem v oblasti toku do 6000 paket˚ u za sekundu. Pro kaˇzd´ y typ pravidla jsem zvolil pˇredpˇripraven´e soubory o objemu 10, 20, 30, 40, 50, 100, 200, 300,
28
4.3 Experiment druh´ y - soubory pravidel
400, 500, 1 000 a 2 000 pravidel dan´eho typu. Pravidla jsou unik´atn´ı, abych vylouˇcil vliv vyrovn´avac´ıho mechanizmu, pokud firewall nˇejak´ y pouˇz´ıv´a. Jako unik´atn´ı prvek jsem v pˇr´ıpadˇe transportn´ıch protokol˚ u volil ˇc´ıslo portu. V´ yjimkou jsou pravidla pro protokol ICMP, kde jsem cyklicky opakoval typ ICMP zpr´avy, kter´a m´a celkem 40 typ˚ u.
4.3.3
Typy pravidel
Podle dokumentace projektu netfilter jsem vybral podmnoˇzinu zaj´ımav´ ych typ˚ u pravidel a jejich z´astupce. Obecn´ a pravidla Touto kategori´ı jsou oznaˇcena pravidla, kter´a se dotazuj´ı na atributy protokolu IP a povaˇzuj´ı se za pravidla z´akladn´ı. Jako z´astupce jsem vybral pravidlo, kter´e se dotazuje na zdrojovou IP adresu. iptables -t nat -A PREROUTING -s 192.168.100.1 -j NAKONEC Pravidla nad protokolem UDP Pravidla tohoto typu se dotazuj´ı na atributy protokolu UDP. Z´astupcem t´eto kategorie je n´asleduj´ıc´ı pravidlo ovˇeˇruj´ıc´ı c´ılov´ y port UDP datagramu. iptables -t nat -A PREROUTING -p udp --dports 1 -j NAKONEC Pravidla nad protokolem TCP Pravidla tohoto typu se dotazuj´ı na atributy protokolu TCP. Z´astupcem t´eto kategorie je n´asleduj´ıc´ı pravidlo ovˇeˇruj´ıc´ı c´ılov´ y port TCP segmentu. iptables -t nat -A PREROUTING -p tcp --dports 1 -j NAKONEC Pravidla ICMP ICMP je sluˇzebn´ı protokol protokolu IP pro signalizaci chybov´ ych stav˚ ua zas´ıl´a dalˇs´ı ˇr´ıd´ıc´ı zpr´avy. Z´astupcem pro experiment je pravidlo ovˇeˇruj´ıc´ı typ ICMP zpr´avy. Ve specifikaci ICMP je definov´ano celkem 40 typ˚ u ICMP zpr´av. iptables -t nat -A PREROUTING -p icmp --icmp-type 1 -j NAKONEC
4.3 Experiment druh´ y - soubory pravidel
29
Pravidla kontroluj´ıc´ı stav spojen´ı Jedin´ y protokol, kter´ y je stavov´ y, je TCP. Stav spojen´ı m˚ uˇze odpov´ıdat nˇekolika stav˚ um: spojen´ı nov´e, ustaven´e, v relaci aj. UDP protokol je sice nestavov´ y, ale firewall je schopen na z´akladˇe existuj´ıc´ıch informac´ı usoudit, zda nˇejak´e UDP spojen´ı na portech prob´ıh´a. Z´astupcem je pravidlo dotazuj´ıc´ı se na TCP spojen´ı, kter´e je ustaveno z konkr´etn´ı IP adresy. iptables -t nat -A PREROUTING -p tcp --192.168.100.1
-j NAKONEC
Pravidla pro pˇ reklad adres Tato skupina pravidel patˇr´ı do skupiny aktivn´ıch pravidel, protoˇze realizuje pˇreklad adres (NAT) a umoˇzn ˇuje modifikovat pakety. Funkc´ı NAT lze modifikovat IP adresy v hlaviˇcce IP protokolu a porty v hlaviˇck´ach transportn´ıch protokol˚ u. Jako z´astupce jsem vybral pravidlo, kter´e v pˇr´ıpadˇe shody, kdy c´ılov´a IP adresa ukazuje na hostitele 192.168.101.1, dojde k pˇrekladu c´ılov´e IP adresy a ˇc´ısla portu. iptables -t nat -A PREROUTING -p tcp --dst 192.168.100.1 --dport 11 -j DNAT -to-destinantion 192.168.101.1:11 Ostatn´ı pravidla Linuxov´ y firewall umoˇzn ˇuje pouˇz´ıt mnoho dalˇs´ıch pravidel, jako je napˇr. logov´an´ı paket˚ u do souboru, znaˇckov´an´ı paket˚ u pro budouc´ı ˇr´ızen´ı toku, modifikace jin´ ych ˇc´ast´ı paket˚ u neˇz je IP adresa a porty. Z praktick´ ych d˚ uvod˚ u nen´ı moˇzn´e postihnout vˇsechna tato pravidla a zahrnout dalˇs´ı moduly, kter´e rozˇsiˇruj´ı funkˇcnost firewallu o nov´a pravidla.
4.3.4
Pozorov´ an´ı
Obr´azek A.7 ukazuje, k jak´emu zpoˇzdˇen´ı doch´az´ı u jednotliv´ ych typ˚ u pravidel v z´avislosti na velikosti souboru pravidel. Podle v´ ysledk˚ u mˇeˇren´ı jsem kaˇzd´e pravidlo zaˇradil do jedn´e ze tˇr´ı skupin: • Pravidla s n´ızk´ ym zpoˇzdˇen´ım • Pravidla se stˇredn´ım zpoˇzdˇen´ım • Pravidla s vysok´ ym zpoˇzdˇen´ım Pravidla s n´ızk´ ym zpoˇ zdˇ en´ım Do prvn´ı skupiny patˇr´ı pravidla, kter´a zp˚ usobuj´ı pˇredv´ıdateln´e zpoˇzdˇen´ı paket˚ u i pˇri velk´ ych objemech. Zpoˇzdˇen´ı s rostouc´ım objemem pravidel
vzr˚ ust´a t´emˇeˇr line´arnˇe. Na kaˇzd´ ych deset pravidel pˇripad´a zpoˇzdˇen´ı o 3µs vˇetˇs´ı. Patˇr´ı sem pravidla pracuj´ıc´ı s obecn´ ymi dotazy nad protokolem IP a tak´e pravidla pro ovˇeˇren´ı stavu TCP spojen´ı, kter´a jsou oznaˇcen´a svˇetle modrou barvou. Pˇrekvapivˇe do t´eto skupiny patˇr´ı i pravidla prov´adˇej´ıc´ı NAT. Pˇredpokl´ad´am, ˇze tato pravidla budou m´ıt dopad na v´ ykon firewallu, coˇz nen´ı v tomto experimentu zˇrejm´e, protoˇze bereme ide´aln´ı pˇr´ıpad datov´eho toku pro dan´ y typ pravidel.
Pravidla s n´ızk´ ym zpoˇ zdˇ en´ım Mezi druhou skupinu pravidel patˇr´ı pravidla pro pr´aci s protokolem ICMP a pravidla dotazuj´ıc´ı se na atributy transportn´ıho protokolu UDP. Zde je situace zaj´ımavˇejˇs´ı, protoˇze rostouc´ı kˇrivka vyjadˇruj´ıc´ı zpoˇzdˇen´ı v z´avislosti na poˇctu pravidel uˇz nem´a line´arn´ı pr˚ ubˇeh. Napˇr., pokud objem tˇechto pravidel pˇresahuje poˇcet 600, vid´ıme, ˇze vznikl´e zpoˇzdˇen´ı je proti prvn´ı skupinˇe temˇeˇr o jednu polovinu vˇetˇs´ı. U souboru 1 000 pravidel je to jiˇz dvojn´asobn´e zpoˇzdˇen´ı. V pˇr´ıpadˇe pravidel nad protokolem ICMP si nedok´aˇzu pˇredstavit praktick´e pouˇzit´ı v objemu vˇetˇs´ım neˇz stovek, coˇz je oblast, ve kter´e nedoch´az´ı k velk´ ym rozd´ıl˚ um zpoˇzdˇen´ı vzhledem k ostatn´ım skupin´ am. Naproti tomu u protokolu UDP uˇz lze pˇredpokl´adat ˇcastˇejˇs´ı v´ yskyt pouˇzit´ı vˇetˇs´ıho objemu pravidel.
Pravidla s vysok´ ym zpoˇ zdˇ en´ım Posledn´ı skupinu, kter´a m´a nejvˇetˇs´ı vliv na zpoˇzdˇen´ı paketu vzhledem k poˇctu pravidel, tvoˇr´ı pravidla pracuj´ıc´ı s atributy protokolu TCP. Tento protokol je nejv´ıce zastoupen v bˇeˇzn´em s´ıt’ov´em provozu a administr´ator by mˇel poˇc´ıtat s dopadem na zpoˇzdˇen´ı pˇri dan´ ych objemech pouˇzit´ ych pravidel, kter´a jsou v´ yrazn´a vzhledem k ostatn´ım skupin´am.
4.4
Experiment tˇ ret´ı - n´ ahodn´ e intervaly vys´ıl´ an´ı
Pˇredchoz´ı u ´loha pracovala s TCP/SYN pakety, kter´e zdroj generoval v pravideln´ ych intervalech. Skuteˇcn´e toky zaloˇzen´e na TCP protokolu jsou charakteristick´e t´ım, ˇze nejdˇr´ıve ustav´ı spojen´ı a teprve n´ aslednˇe prob´ıh´a pˇrenos dat a jejich potvrzov´an´ı. Pˇrenos dat po takto ustaven´em kan´alu m´a sp´ıˇse n´ahodn´ y charakter neˇz periodick´ y pr˚ ubˇeh. N´asleduj´ıc´ı experiment pracuje s korektnˇe ustaven´ ymi TCP spojen´ım s n´ahodn´ ymi intervaly mezi pˇr´ıchoz´ımi pakety.
Obr´azek 4.4: Testovac´ı prostˇred´ı pro tˇret´ı experiment
4.4.1
C´ıle a pˇ redpoklady
C´ılem experimentu je zjistit zpoˇzdˇen´ı paket˚ u v z´avislosti na velikosti toku a poˇctu pravidel. Pˇredpokladem je ustaven´ı korektn´ıho TCP spojen´ı. Intervaly mezi starty paket˚ u jsou definov´any n´ahodnou veliˇcinou, jeˇz m´a Poissonovo rozdˇelen´ı.
4.4.2
Testovac´ı prostˇ red´ı
Testovac´ı prostˇred´ı jsem upravil dle obr´azku 4.4, protoˇze ustaven´e TCP spojen´ı vyˇzaduje potvrzov´an´ı smˇerem ke zdroji a pˇredchoz´ı zapojen´ı testovac´ıho prostˇred´ı tomuto poˇzadavku nevyhovovalo. Hostitelsk´ y stroj laptop, kter´ y je v roli gener´atoru TCP paket˚ u, je nucen zas´ılat data pˇres firewall, jenˇz zaznamen´av´a pˇr´ıchoz´ı a odchoz´ı pakety. C´ılem komunikace je hostitelsk´ y poˇc´ıtaˇc desktop.
4.4.3
Generov´ an´ı paket˚ u
Pˇredchoz´ı generov´an´ı paket˚ u pomoc´ı aplikace hping je pro tento experiment nevyhovuj´ıc´ı. Hledal jsem gener´ator s´ıt’ov´eho provozu, podporuj´ıc´ı protokol TCP s volbu n´ahodn´eho intervalu mezi starty paket˚ u, kter´e maj´ı Poissonovo rozdˇelen´ı. Jako vhodn´ y gener´ator se osvˇedˇcil soubor aplikac´ı D-ITG, kter´ y pouˇz´ıv´a agenta ITGSend, a jenˇz splˇ nuje v´ yˇse uveden´e poˇzadavky. N´asleduj´ıc´ı pˇr´ıklad vytvoˇr´ı TCP tok po dobu jedn´e minuty o pr˚ umˇern´em toku 5 000 paket˚ u za sekundu s n´ahodn´ ymi intervaly mezi vys´ılan´ ymi pakety, maj´ıc´ı Poissonovo rozdˇelen´ı. ITGSend -a 192.168.0.10 -O 5000 -t 60000 -T TCP Aby gener´ator spr´avnˇe pracoval, mus´ı se na c´ılov´ y hostitelsk´ y poˇc´ıtaˇc nainstalovat agent, kter´ y pˇrij´ım´a a potvrzuje pˇr´ıchoz´ı spojen´ı aplikac´ı ITGRecv.
4.4.4
Parametry experimentu
Mˇeˇril jsem shodn´ y soubor pravidel, jenˇz byl pops´an v kapitole 4.3.3, a redukoval jsem objemy na mnoˇziny: 10, 100, 200, 300, 400, 500, 1 000 a 2 000
pravidel. Kaˇzd´ y jednotliv´ y soubor pravidel jsem mˇeˇril po dobu jedn´e minuty s parametrem toku. Vyzkouˇsel jsem aplikac´ı ITGSend pˇredat n´asleduj´ıc´ı toky 5 000, 8 000, 10 000, 12 000 a 14 000, kter´e podle prvn´ıho testu posouvali hranici zpoˇzdˇen´ı. Na prvn´ı pohled je zˇrejm´e, ˇze toky nad 8 000 p/s nelze po mediu vys´ılat, proto je v pozorov´an´ı nebudu interpretovat. Re´alnˇe zaznamenan´e toky na pˇrij´ımac´ı stranˇe daleko niˇzˇs´ı a ve v´ yjimeˇcn´ ych pˇr´ıpadech pˇrekraˇcuj´ı max. kapacitu kan´alu.
4.4.5
Pozorov´ an´ı
Graf pro kaˇzd´ y typ pravidla zobrazuje stˇredn´ı hodnoty tok˚ u a zpoˇzdˇen´ı; barvou jsou odliˇseny velikosti soubor˚ u pravidel. Na prvn´ı pohled se zd´a, ˇze body v grafu vyjadˇruj´ıc´ı zpoˇzdˇen´ı nemaj´ı ˇz´adn´ y ˇr´ad, kter´ y by alespoˇ n vystihoval z´avislost zpoˇzdˇen´ı a toku. Jedinou pravidelnost´ı je bod se zpoˇzdˇen´ım 45 µs v m´ıstˇe toku 5 000 p/s. Pokud bychom u kaˇzd´eho grafu zakryli jeho levou ˇc´ast od v´ yˇse popsan´eho bodu, uvid´ıme rostouc´ı kˇrivky v z´avislosti na hustotˇe toku. Souvislosti mezi velikost´ı soubor˚ u tato u ´loha neprokazuje. Velmi podobn´ y obor hodnot je u vˇsech graf˚ u v oblasti toku 7 000 p/s. Napˇr. na obr´azku A.10 lze vypozorovat, ˇze IP pravidla o velikosti 10 a 2 000 pravidel maj´ı podobnou strmost a pr˚ ubˇeh, ale vystihuj´ı opaˇcnou kvantitu, proto nelze nal´ezt vliv velikosti souboru na zpoˇzdˇen´ı. Obr´azku A.11 vystihuje zaj´ımavou situaci TCP pravidel, kdy pro toky bl´ıˇz´ıc´ı se k hranici kapacity media, firewall odbavil vˇetˇsinu paket˚ u do 400 µs.
Kapitola 5
Experiment´ aln´ı u ´ lohy s hardwarov´ ym firewallem V t´eto kapitole uvedu z´akladn´ı parametry a strukturu hardwarov´eho firewallu CISCO PIX 506 (d´ale jen firewall) a zkonstruuji pro toto zaˇr´ızen´ı podobn´e experiment´aln´ı u ´lohy jako pro linuxov´ y firewall iptables.
5.1
Hardware
Hardwarov´ y firewall patˇr´ı mezi levnˇejˇs´ı firewally, kter´e firma CISCO nab´ızela v kategorii mal´eho a stˇredn´ıho podnik´an´ı. Jedn´a se o stavov´ y firewall, jehoˇz zp˚ usob rozhodov´an´ı oznaˇcuje CISCO algoritmem ASA (Adaptive Security Algorithm). D´ale podporuje tvorbu VPN tunel˚ u a detekuje vybran´e typy u ´tok˚ u. Zaˇr´ızen´ı vyuˇz´ıv´a 200 MHz procesor s 32MB RAM, 8MB FLASH ROM a je urˇceno pro trval´e uloˇzen´ı nastaven´ı. Firewall m´a dvˇe ethernetov´a rozhran´ı podporuj´ıc´ı rychlost 10Mbit/s a jeden konektor pro s´eriovou komunikaci. Na trhu je st´ale k dispozici verze s oznaˇcen´ım PIX 506E, kter´a podporuje 100 Mbit Ethernet a pouˇz´ıv´a procesor Celeron taktovan´ y na 300MHz.
5.1.1
Nastaven´ı komunikace
Zap˚ ujˇcen´e zaˇr´ızen´ı bylo v provozu a lze oˇcek´avat, ˇze nebude nastaveno v tov´arn´ım nastaven´ı. Pro prvotn´ı oˇziven´ı jsem pouˇzil s´eriovou linku a aplikaci minicom. Parametry komunikace pˇres s´eriovou linku definuje dokumentace, staˇc´ı nastavit rychlost, paritu a stop bit.
5.1.2
Obnova tov´ arn´ıho nastaven´ı
Firewall po startu zobrazil hardwarov´e parametry a vyˇzadoval autentizaci. Procedura pro restart hesla spoˇc´ıvala v pˇrepnut´ı zaˇr´ızen´ı do monitor m´odu
34
5.2 Struktura firewallu
a konfiguraci zaˇr´ızen´ı pro staˇzen´ı bin´arn´ıho souboru z TFTP serveru1 . Po restartu bylo moˇzn´e uv´est firewall do tov´arn´ıho nastaven´ı. Nakonfiguroval jsem IP adresy na rozhran´ıch a povolil telnetov´e spojen´ı, d´ıky kter´emu uˇz nen´ı nutn´e pouˇz´ıvat s´eriovou linku pro komunikaci s firewallem.
5.2
Struktura firewallu
Firewall podporuje pˇreklad adres a port˚ u, d´ale filtruje provoz na nˇekolika u ´rovn´ıch [3]: • Kontrola hardwarov´ ych adres na linkov´e vrstvˇe • Kontrola protokolu IP, transportn´ıch protokol˚ u a jejich port˚ u • Inspekce vybran´ ych aplikaˇcn´ıch protokol˚ u; kromˇe standardn´ıch protokol˚ u HTTP, DNS, FTP zde najdeme SQLNet2 • Omezen´e filtrov´an´ı nˇekter´ ych protokol˚ u ActiveX, Java applety, filtrace HTML
