ÚÝ Ó Ù Ò Ø Ò Ú ÈÖ Þ ÙÐØ Ð ØÖÓØ Ò ÔÐÓÑÓÚ ÔÖ ÈÖÓÚÓÞÒ Ö Ø Ö Ø Ý ðóú ÐØÖó º È ØÖ ÂÙ Î ÓÙ ÔÖ ÓºÁÒ º Â Ò Â Ò Ëº ËØÙ Ò ÔÖÓ Ö Ñ ÎÔÓ ØÒ Ø Ò Ú Ø Ò ¾¼¼
Poděkování Děkuji vedoucímu diplomové práce Doc.Ing. Janu Janečkovi, CSc. za vedení práce. Dále chci poděkovat Michalu Medveckému a Michalu Štusákovi za zapůjčení hardwarového firewallu.
Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Milovicích dne 21.5. 2008...
Abstrakt Práce se zaměřuje na provozní charakteristiky sít ových filtrů, kvantifikuje zpoždění paketů v závislosti na objemu a typu pravidel. Předmětem zkoumání je softwarový firewall založený na iptables a hardwarový 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.
Obsah Úvod 1 1 Firewally 3 1.1 Hardwarové a softwarové firewally............... 3 1.2 Metody regulace sít ového provozu............... 3 1.2.1 Paketové filtry...................... 4 1.2.2 NAT............................ 4 1.2.3 Proxy firewall....................... 5 2 Základy TCP/IP 7 2.1 Model TCP/IP.......................... 7 2.1.1 Aplikační vrstva..................... 8 2.1.2 Transportní vrstva.................... 8 2.1.3 Internetová vrstva.................... 9 2.1.4 Sít ová vrstva a hardware................ 9 2.2 Odposlech komunikace...................... 10 2.2.1 TCP spojení....................... 10 2.2.2 Příklad HTTP komunikace............... 11 2.2.3 Zapouzdření protokolů.................. 13 3 Linuxový firewall iptables 15 3.1 Netfilter.............................. 15 3.2 Iptables.............................. 15 3.2.1 Tabulky.......................... 15 3.2.2 Pravidla.......................... 17 3.2.3 Cíle skoku......................... 17 3.2.4 Průchod tabulkami a řetězci............... 18 3.2.5 Politiky.......................... 19 3.2.6 Stav konfigurace firewallu................ 19 4 Experimentální úlohy s iptables 23 4.1 Příprava.............................. 23 4.1.1 Testovací prostředí.................... 23 4.1.2 Vytvoření zátěže..................... 24 7
4.1.3 Zpoždění paketu..................... 25 4.1.4 Kapacita media a velikost paketu............ 25 4.2 Experiment první - zjištění pracovní oblasti firewallu..... 26 4.2.1 Cíle a předpoklady.................... 26 4.2.2 Klidový režim....................... 26 4.2.3 Mezní vstupní tok.................... 26 4.2.4 Pozorování........................ 27 4.3 Experiment druhý - soubory pravidel.............. 27 4.3.1 Cíle a předpoklady.................... 27 4.3.2 Parametry experimentu................. 27 4.3.3 Typy pravidel....................... 28 4.3.4 Pozorování........................ 29 4.4 Experiment třetí - náhodné intervaly vysílání......... 30 4.4.1 Cíle a předpoklady.................... 31 4.4.2 Testovací prostředí.................... 31 4.4.3 Generování paketů.................... 31 4.4.4 Parametry experimentu................. 31 4.4.5 Pozorování........................ 32 5 Experimentální úlohy s hardwarovým firewallem 33 5.1 Hardware............................. 33 5.1.1 Nastavení komunikace.................. 33 5.1.2 Obnova továrního nastavení............... 33 5.2 Struktura firewallu........................ 34 5.3 Konfigurace firewallu....................... 34 5.4 Testovací prostředí........................ 35 5.4.1 Časová synchronizace.................. 36 5.4.2 Import pravidel...................... 36 5.5 Experiment první - tok TCP/SYN............... 37 5.5.1 Předpoklady....................... 37 5.5.2 Pozorování........................ 38 5.6 Experiment druhý - náhodný tok................ 38 5.6.1 Předpoklady....................... 38 5.6.2 Pozorování........................ 38 6 Bezpečnost 39 6.1 Hrozby............................... 39 6.2 Formy útoku........................... 39 6.3 Obrana proti útokům...................... 40 Závěr 40 A Příloha 45
B Obsah přiloženého CD 57
Seznam obrázků 2.1 model TCP/IP a referenční model OSI............. 8 2.2 Třícestné ustavení TCP spojení................. 10 2.3 Ukončení TCP spojení...................... 11 2.4 DNS požadavek na překlad adresy www.juhanak.cz...... 12 2.5 TCP handshaking (1) SYN................... 12 2.6 TCP handshaking (2) SYN / ACK............... 12 2.7 TCP handshaking (3) ACK................... 13 2.8 HTTP komunikace........................ 13 4.1 Testovací prostředí........................ 24 4.2 dell-nat: pravidla pro překlad cílových adres a portů.... 24 4.3 theresa-nat: pravidla pro překlad cílových adres a portů.. 25 4.4 Testovací prostředí pro třetí experiment............ 31 5.1 Konfigurace sít ových rozhraní.................. 35 5.2 Definice pravidel pro vnitřní sít ové rozhraní.......... 35 5.3 Testovací prostředí pro firewall CISCO PIX 506........ 35 5.4 Dotaz na seznam spojení NTP serveru............. 36 5.5 Výpis............................... 37 A.1 Hlavní skript pro zpracování naměřených výsledků...... 46 A.2 AWK skript pro výpočet zpoždění............... 46 A.3 Paketový sniffer Wireshark - zanoření protokolů........ 47 A.4 Průchod paketu iptables..................... 48 A.5 Klidový režim firewallu iptables (TCP/SYN)......... 49 A.6 Při toku 7000 p/s se na firewallu periodicky objevuje saturace (iptables)............................. 49 A.7 Vliv zpoždění na typ a velikost souboru pravidel (iptables).. 50 A.8 Vliv zpoždění na velikost toku, soubor IP pravidel (Poisson iptables)............................. 51 A.9 Vliv toku na zpoždění paketu, soubor ICMP pravidel (Poisson iptables).............................. 51 A.10 Vliv toku na zpoždění paketu, soubor UDP pravidel (Poisson iptables).............................. 52 11
A.11 Vliv toku na zpoždění paketu, soubor TCP pravidel (Poisson iptables).............................. 52 A.12 Vliv toku na zpoždění paketu, soubor TCP STATE pravidel (Poisson iptables)......................... 53 A.13 Vliv toku na zpoždění paketu, soubor DNAT pravidel (Poisson iptables)........................... 53 A.14 PIX Firewall - tok TCP/SYN................. 54 A.15 PIX Firewall - TCP pravidla (Poisson)............. 55 A.16 PIX Firewall - UDP pravidla (Poisson)............. 55
Úvod Firewally plní bezpečnostní funkci na hraničních bodech sítí, skrývají informace o struktuře vnitřní sítě a blokují nežádoucí služby. V komerčním prostředí jsou dnes již firewally nutností, ale můžeme pozorovat i jejich použití v domácích sítích, kde se vyskytují ve formě aktivních sít ových prvků nebo na klientských stanicích v podobě softwaru. Když pomineme bezpečnostní funkci firewallu, zajímá nás také, jaký mají firewally vliv na sít ový provoz a jak můžeme kvantifikovat zpoždění paketů v závislosti na typu a objemu pravidel? Dále lze zkoumat, jaké jsou možnosti konkrétních implementací firewallů a kde jsou hranice jejich použití. Na tyto otázky odpovídá tato diplomová práce, která pomocí experimentů zkoumá softwarový firewall založený na iptables a proprietární firewall CISCO PIX 506. V jednotlivých úlohách kvantifikuje zpoždění paketů v závislosti na objemu a typu pravidel. První kapitola klasifikuje možné typy firewallů, se kterými se dnes můžeme setkat. Druhá a třetí kapitola je věnována problematice TCP/IP protokolů a struktuře firewallu iptables. Následující dvě kapitoly se zabývají konstrukcí experimentálních úloh a jejich pozorování. Poslední kapitola je věnována bezpečnosti.
2
Kapitola 1 Firewally Firewally tvoří hraniční body na přechodech vnitřních a vnějších sítí, kontrolují sít ový provoz a zakazují nežádoucí služby. Robustní firewally chrání sít ový provoz od linkové až po aplikační vrstvu. Jednodušší firewally monitorují provoz v rozsahu linkové až transportní vrstvy. 1.1 Hardwarové a softwarové firewally Firewally dělíme na dvě základní skupiny: hardwarové softwarové Hardwarové firewally jsou integrovány přímo do aktivních sít ových prvků, kterými jsou např. směrovače. Hardwarové firewally mají dostatečně dimenzovaný hardware pro sít ový provoz a používají proprietární operační systém, který je navržen pouze pro tento typ zařízení; je jednodušší a díky tomu i bezpečnější. Naproti tomu softwarový firewall je aplikace, která musí být s operačním systémem těsně svázána, a tudíž je tento typ firewallu zranitelný na úrovni operačního systému nebo jeho chybné implementaci TCP/IP zásobníku. Operační systém zpravidla poskytuje další zbytečné sít ové služby a aplikace, které vytvářejí prostor pro zranitelnost celého systému. Pokud chceme požívat softwarový firewall, vyhradíme si pro něj dedikovaný stroj a omezíme všechny služby. Softwarové firewally jsou také vhodné na klientských stanicích jako bezpečnostní doplněk, nebo pro monitorování sít ových aktivit klientského softwaru. 1.2 Metody regulace sít ového provozu Firewally využívají tři základní metody[1] k regulaci sít ového provozu:
4 1.2 Metody regulace sít ového provozu filtrování paketů 1 překlad sít ových adres NAT služeb proxy 1.2.1 Paketové filtry Paketové filtry porovnávají pole hlaviček IP paketů a transportních protokolů (TCP, UDP). Z těchto informací firewall pozná adresu zdroje a adresu cíle včetně portů. Získané informace porovná s vnitřními pravidly, které tvoří politiku firewallu. Pokud paket vyhovuje politice firewallu, paket projde dále, pokud paket nevyhovuje firewall paket zahodí. Tato technika je jednoduchá, ale má svá úskalí. Jednak neskrývá adresy počítačů ve vnitřní síti, jednak pokud dochází k fragmentaci paketů, tak TCP hlavička je přítomná v prvním fragmentu zprávy a pro ostatní příchozí pakety se firewall může opřít pouze o hlavičku IP protokolu, která už nedefinuje zdrojové a cílové porty. Z podstaty paketového filtru vyplývá, že není schopen identifikovat, zda data uvnitř transportního protokolu jsou běžná data daného aplikačního protokolu (např. HTTP) nebo škodlivý kód. Výhodou tohoto typu firewallu je již zmíněná jednoduchost, nebot se analyzuje malé množství informací a filtrování není náročné na prostředky jako je CPU a pamět. Dochází tak k malé latenci a je jednoduché tyto firewally implementovat jako hardwarové zařízení. 1.2.2 NAT Překlad adres NAT (network address translation) je metoda jak maskovat adresu vnitřní sítě. Primárním účelem NAT bylo umožnit s jednou IP adresou připojit celou skupinu počítačů na lokální síti k internetu, protože volných adres u protokolu IP verze 4 je nedostatek. Funkci NAT můžeme osvětlit následujícím příkladem; paket putující z vnitřní sítě dorazí na firewall, který může být zároveň směrovačem a postupně provádí tyto kroky: prozkoumá IP paket přepíše původní zdrojovou adresu a nahradí ji svou IP adresou prozkoumá porty transportního protokolu (TCP, UDP) poznačí si původní zdrojový port a přepíše jej náhodně zvoleným volným portem, který bude pro tuto komunikaci používat 1 Exaktní definice slova paket neexistuje, jedná se o obecný termín popisující segmentační jednotku dat připravenou k přenosu po síti, která je označena informacemi nutnými pro doručení paketu adresátovi a případnému doručení odpovědi odesilateli.
1.2 Metody regulace sít ového provozu 5 Důsledkem je, že pakety odcházející ze směrovače do vnější sítě mají společnou zdrojovou adresu (IP adresu směrovače). Tím se skrývají adresy vnitřní sítě a informace o její struktuře. Je samozřejmě nutné, aby směrovač při opačné komunikaci z vnější sítě dovnitř překládal zpět IP adresy směrovače na IP adresy počítačů vnitřní sítě. Směrovač nalezne IP adresu správného adresáta právě díky cílovému portu, který má poznačen v tabulce existujících spojení. Nevýhodou NAT je, že pracuje jako proxy na transportní vrstvě, to znamená, že tento typ firewallu nefiltruje datovou část přenášenou v paketech transportních protokolů (TCP, UDP). S některými aplikačními protokoly si NAT neporadí, protože právě do datové části transportního protokolu ukládají některé protokoly vyšších vrstev IP adresy. Těch se samozřejmě NAT, nedotkne protože je implementován na úrovni hlaviček protokolu IP a transportních protokolů UDP, TCP. NAT se běžně vyskytuje jako doplňková funkce aktivních sít ových prvků. 1.2.3 Proxy firewall Proxy služby pracují vždy s prostředníkem (proxy serverem), který je uprostřed komunikace mezi stanicí ve vnitřní síti, jež chce komunikovat, a mezi cílovým hostitelským počítačem ve vnější síti. Místo abychom komunikovali přímo s cílovým hostitelským počítačem na úrovni daného aplikačního protokolu, obrátíme se na proxy server s žádostí o spojení. Tímto se stává proxy server klientem a komunikuje za nás s protistranou a vrací výsledky komunikace. Proxy firewally mají tu výhodu, že filtrují aplikační protokoly. Mohou tak filtrovat a validovat jeho obsah a zabránit případnému útoku na aplikační vrstvu. Nevýhodou je možné zahlcení, protože inspekce na aplikační vrstvě je náročná. Tím, že do komunikace mezi klientem a serverem vstupuje aplikační proxy, je možné používat dvě nezávislá TCP spojení a odmítat všechny přímé IP pakety bez podporovaného protokolu. Každý paket, který na proxy dorazí, se nejdříve rozebere, prozkoumá se, zda vyhovuje aplikačním pravidlům a vytvoří se nový paket. To činí proxy servery více imunní proti běžným i neznámým útokům, kterými stavové firewally trpí. Nevýhodou je, že pro každou inspekci aplikačního protokolu, kterou chceme chránit proti útoku, potřebujeme další proxy firewall.
6 1.2 Metody regulace sít ového provozu
Kapitola 2 Základy TCP/IP Pod označením TCP/IP myslíme rodinu protokolů založených nad protokolem IP, který je základním protokolem internetu. Protokol IP (Internet Protocol) používá logické adresování ve formě IP adres a zároveň překonává rozdíly mezi sítěmi různých architektur, které používají vlastní fyzické adresování a specifické médium pro přenos signálu. 2.1 Model TCP/IP Každý hostitelský počítač, který se chce připojit k internetu pomocí protokolu IP, musí požádat svůj operační systém o komunikaci se vzdáleným hostitelským zařízením. Komunikuje se přes programové rozhraní, jehož konkrétní implementaci říkáme TCP/IP zásobník (TCP/IP stack) a které podporuje protokoly TCP/IP v operačním systému. Fyzicky probíhá komunikace pomocí sít ové karty. Aby se operační systém domluvil s hardwarem sít ové karty, potřebuje ovladač zařízení, tzv. driver. Celou sít ovou architekturu hostitelského systému můžeme popsat modelem a představit si cestu dat od okamžiku, kdy je posílá aplikace až po okamžik, kdy data opustí sít ovou kartu. Na obrázku 2.1 vidíme dva sít ové modely. Vpravo je referenční model OSI, který se neprosadil, a spíše se dnes považuje za didaktickou pomůcku, protože se nikdy plně nerealizovaly všechny jeho protokoly. Vlevo vidíme model TCP/IP, jehož protokoly nakonec zvítězily a které budou předmětem našeho zájmu. Model TCP/IP se skládá z několika vrstev. Pro každou vrstvu platí pravidlo, že komunikuje pouze se sousedními vrstvami. Představme si, že pracujeme s webovým prohlížečem a chceme si přečíst naše oblíbené stránky. Když napíšeme do adresního řádku doménový název našeho oblíbeného webového serveru, musí náš požadavek postupně probublat všemi vrstvami. Příchozí odpověd od webového serveru reverzně probublá vrstvami modelu TCP/IP.
8 2.1 Model TCP/IP Obrázek 2.1: model TCP/IP a referenční model OSI 2.1.1 Aplikační vrstva Na vrcholu zásobníku (TCP/IP modelu) vidíme aplikační vrstvu, kde běží sít ové aplikace využívající služeb operačního systému. Běží zde i webový prohlížeč, který vytvoří požadavek na načtení stránky pomocí protokolu HTTP a IP adresy cílového webového serveru. Aplikace webového prohlížeče požádá operační systém o vytvoření sít ového spojení, což je z hlediska TCP/IP modelu přesun do následující spodní transportní vrstvy. 2.1.2 Transportní vrstva Aplikace požádala voláním služby operačního systému o vytvoření sít ového spojení na konkrétní IP adresu. Protože přenos dat pomocí protokolu IP je nespolehlivý, využívají se transportní protokoly TCP nebo UDP. Oba protokoly zavádějí kontrolní součty pro data a doplňující adresaci pomocí portů. Port je adresní identifikátor, který na hostitelském stroji určuje adresu sít ové služby. V internetu je každé aktivní sít ové spojení mezi dvěma hostiteli jednoznačně identifikovatelné dvojicí IP adres a dvojicí, která je tvořena zdrojovým a cílovým portem. Protokol TCP během tří kroků ustavuje spojení mezi oběma hostiteli a garantuje přenos dat po ustaveném kanálu. Pokud se nějaký paket nepodaří doručit, tento protokol zajistí, že vysílací strana přenos zopakuje. Protokol TCP je tedy stavový; můžeme se také setkat s označením spojově orientovaný. Naproti tomu protokol UDP je jednodušší, rychlejší, ale negarantuje doručení dat. V případě detekce nedoručeného paketu, musí aplikace sama zajistit nový přenos.
2.1 Model TCP/IP 9 Když se vrátíme k našemu příkladu s webovým prohlížečem, tak jeho aplikační protokol HTTP pracuje implicitně na portu 80 a využívá služeb transportního protokolu TCP. Operační systém nasegmentoval data HTTP požadavku do TCP segmentu. Každý TCP segment obsahuje hlavičku s hodnotou cílového portu a libovolně zvoleným zdrojovým portem, který se využije jako identifikátor procesu žádajícího o data, až přijde zpět odpověd na náš HTTP dotaz. Tímto jsou TCP segmenty připraveny k předání do nižší internetové vrstvy. 2.1.3 Internetová vrstva V této vrstvě nám zbývá zabalit připravené segmenty nebo datagramy 1 do připravených IP paketů, které v hlavičce obsahují IP adresu cíle. V datové části má každý IP paket jeden datagram, který přišel v rámci jedné relace. Zde končí veškerá logická adresace a operační systém předává frontu připravených IP paketů poslední vrstvě, která bude muset fyzicky vyřešit doručení připravených dat cílovému hostiteli. 2.1.4 Sít ová vrstva a hardware Úkolem poslední vrstvy je zapouzdřit IP paket do rámce a vyslat vše na médium pomocí sít ové karty. Médium může mít podobu metalického vedení, optického vlákna, nebo bezdrátového média komunikujícího pomocí rádiových vln. Rámec si můžeme představit jako časový prostor pro vyslání dat na médium. Rámec má definovanou strukturu, která je závislá na typu média a implementované technologie. Za zmínku stojí, že na úrovni rámce je zavedena fyzická adresace. Každé fyzické zařízení v podobě sít ové karty má fyzickou adresu a o žádné logické IP adrese nemůže být na této vrstvě řeč. Např. na Ethernetu, nejběžnějším sít ovém rozhraní, se fyzická adresa sít ové karty označuje jako 48bitová MAC adresa. Pokud se však hostitelské počítače v internetu adresují logickými IP adresami, aby překonaly architektonické rozdíly sítí, musí na této vrstvě existovat způsob, jak namapovat IP adresu ke konkrétní fyzické adrese. K tomuto kroku musí dojít dříve, než se připravené IP pakety vyšlou na fyzické médium ve formě rámce, protože ten si vynucuje vyplnit fyzickou adresu příjemce. Řešením je zavedení protokolu ARP (Adress Resolution Protocol), který zajistí mapování mezi logickou a fyzickou adresou. Pokud počítač nezná fyzickou adresu cíle pro konkrétní IP adresu, posílá ARP dotaz na médium. Když se adresát nachází na stejném segmentu lokální sítě (LAN), obdrží 1 Datagram je označení jednoho fragmentu dat protokolu UDP, podobné označení existuje pro fragment dat protokolu TCP, které se nazývá TCP segment.
10 2.2 Odposlech komunikace ARP odpověd, která přiřazuje fyzické adrese konkrétní IP adresu. Je-li zřejmé, že IP adresa nepochází ze stejného segmentu sítě, automaticky se pro komunikaci použije fyzická adresa brány. Nyní je vše připraveno, počítač může zapouzdřit připravené IP pakety do rámců a odeslat je na médium. Za nějaký čas dostane odpověd od webového serveru, která dorazí ve formě rámců na náš segment sítě LAN, a celý průchod modelem TCP/IP bude nyní probíhat opačně. Dojde k rozbalení rámce a IP pakety se přenesou do vyšší internetové vrstvy. Po rozbalení obsahu IP paketu dochází k rozbalení TCP segmentu nebo UDP datagramu na úrovni transportní vrstvy. Podle cílového portu operační systém předá data konkrétnímu procesu na aplikační vrstvě. Webový prohlížeč načte webovou stránku a uživatel je spokojen. 2.2 Odposlech komunikace Kdybychom si chtěli ověřit, jak vypadá komunikace na síti a jak jsou jednotlivé protokoly TCP/IP modelu zapouzdřeny do sebe, můžeme využít nástroje pro odposlech komunikace na síti, které se v anglické terminologii označují jako sniffery. Typickými zástupci jsou programy tcpdump nebo whireshark 2. 2.2.1 TCP spojení Abychom dobře porozuměli odchyceným paketům s TCP protokolem, prozkoumáme nejdříve mechanismus vytvoření TCP spojení a jeho uzavření. Obrázek 2.2 zobrazuje klienta (vlevo), který chce zahájit komunikaci s webovým serverem (vpravo). Obrázek 2.2: Třícestné ustavení TCP spojení V prvním kroku klient zasílá TCP segment s nastaveným příznakem SYN. V druhém kroku protistrana potvrzuje obdržení SYN příznaku odesláním 2 whireshark je nové označení, původně se tento produkt jmenoval ethereal
2.2 Odposlech komunikace 11 TCP segmentu s příznaky SYN a ACK. Nakonec klient potvrdí přijatý paket TCP segmentem s příznakem ACK. Obě strany se tímto způsobem dohodly na vytvoření kanálu s garantovaným přenosem dat. Došlo k dohodě sekvenčních čísel, která jsou pro komunikaci vygenerována. Jejich následné sekvence budou označovat pořadí paketu. Toto opatření chrání TCP spojení proti únosu. Obrázek 2.3: Ukončení TCP spojení Uzavření TCP spojení probíhá podle obrázku 2.3 ve čtyřech krocích, kdy si obě strany vymění TCP segmenty s FIN příznaky a vždy si je navzájem potvrdí příznakem ACK. 2.2.2 Příklad HTTP komunikace Následující příklad ukazuje záznam HTTP komunikace mezi klientem s webovým prohlížečem a webovým serverem. Záznam komunikace byl vytvořen pomocí nástroje tcpdump, který jsem spustil před zahájením sít ové aktivity na sít ovém rozhraní eth0 a přesměroval jeho výstup do souboru pro pozdější analýzu. tcpdump -nxi eth0 > soubor_komunikace.txt Po ukončení komunikace v souboru nalezneme skupinu vyslaných a doručených paketů. Každý záznam je doplněn o časové razítko a směr komunikace, která je vyjádřena dvojicemi (IP_zdroje:port > IP_cíle:port). Dále následuje záznam zachyceného paketu, který je vyjádřen skupinou hexadecimálních číslic. Pro lepší orientaci je výpis doplněn v pravém sloupci o informaci, která v textové formě reprezentuje hexadecimální zápis paketu. Prozkoumáme nyní celou komunikaci, která je způsobena požadavkem na zobrazení stránky do webového prohlížeče. Klient, který žádá o komunikaci, má přiřazenu IP adresu 192.168.0.8. Nejdříve se snaží získat IP adresu webového serveru, jenž chce požádat o zaslání webové stránky. Služba, která tento překlad realizuje, se nazývá DNS. Každý počítač má nakonfigurovánu IP adresu hostitelského stroje, který
12 2.2 Odposlech komunikace 06:53:27.378017 IP 192.168.0.8.32775 > 212.96.162.2.53: 30562+ AAAA? 0x0000: 00c0 4f62 6035 0018 f32f 11b9 0800 4500..Ob 5.../...E. 0x0010: 003c 2cc9 4000 4011 d6d4 c0a8 0008 d460.<,.@.@... 0x0020: a202 8007 0035 0028 98cf 7762 0100 0001...5.(..wb... 0x0030: 0000 0000 0000 0377 7777 076a 7568 616e...www.juhan 0x0040: 616b 0263 7a00 001c 0001 ak.cz... Obrázek 2.4: DNS požadavek na překlad adresy www.juhanak.cz službu DNS realizuje. V našem příkladě nejbližší DNS server leží na IP adrese 212.96.162.2 a poslouchá na portu 53, kde přijímá požadavky klientů. Za zmínku stojí dodat, že služba DNS je realizována transportním protokolem UDP. Po chvíli nám DNS server odpoví zpět a prozradí nám, že IP adresa webového serveru je 82.208.58.92. Nyní je situace zajímavější a klient zahajuje komunikaci s webovým serverem. Protože komunikace aplikačního protokolu HTTP je zajištěna transportním protokolem TCP, musí nejdříve dojít k ustavení TCP spojení pomocí třífázové výměny 3. Klient vyzývá webový server k ustavení spojení a zasílá paket s prázdným TCP segmentem s pří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.<Vc@.@.....R. 0x0020: 3a5c a1a9 0050 74fd 7aba 0000 0000 a002 :\...Pt.z... 0x0030: 16d0 24c8 0000 0204 05b4 0402 080a 0003..$... 0x0040: 2cd9 0000 0000 0103 0305,... Obrázek 2.5: TCP handshaking (1) SYN Webový server klientovi potvrzuje, že obdržel žádost o spojení a potvrdí tuto skutečnost zasláním TCP segmentu s pří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.<..@.6...r.:\.. 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ázek 2.6: TCP handshaking (2) SYN / ACK 3 V anglickém jazyce se tato situace označuje jako 3 way handshaking, tedy potřásání rukou natřikrát mezi oběma účastníky komunikace
2.2 Odposlech komunikace 13 Nyní klient obdržel potvrzení, že server bude komunikovat a ještě jednou potvrdí serveru, že jeho paket obdržel. 06:53:27.378808 IP 192.168.0.8.41385 > 82.208.58.92.80:. ack 1 win 183 <nop,nop,timestamp 208092 75348255> 0x0000: 00c0 4f62 6035 0018 f32f 11b9 0800 4500..Ob 5.../...E. 0x0010: 0034 5664 4000 4006 9683 c0a8 0008 52d0.4Vd@.@...R. 0x0020: 3a5c a1a9 0050 74fd 7abb 58a3 7eb2 8010 :\...Pt.z.X.~... 0x0030: 00b7 d4a5 0000 0101 080a 0003 2cdc 047d...,..} 0x0040: b91f Obrázek 2.7: TCP handshaking (3) ACK Nyní je TCP spojení ustaveno a klient začíná v datové části TCP segmentu posílat data webovému serveru, jehož služba poslouchá na portu 80. V průběhu TCP spojení obě strany potvrzují veškeré došlé pakety. TCP spojení je ukončeno, pokud obě strany vyšlou paket s příznaky FIN a obě strany potvrdí tuto skutečnost ACK příznaky. 06:53:27.378861 IP 192.168.0.8.41385 > 82.208.58.92.80: P 1:401(400) ack 1 win 183 <nop,nop,timestamp 208092 75348255> 0x0000: 00c0 4f62 6035 0018 f32f 11b9 0800 4500..Ob 5.../...E. 0x0010: 01c4 5665 4000 4006 94f2 c0a8 0008 52d0..Ve@.@...R. 0x0020: 3a5c a1a9 0050 74fd 7abb 58a3 7eb2 8018 :\...Pt.z.X.~... 0x0030: 00b7 f8ab 0000 0101 080a 0003 2cdc 047d...,..} 0x0040: b91f 4745 5420 2f20 4854 5450 2f31 2e31..GET./.HTTP/1.1 0x0050: 0d0a 486f 7374 3a20 7777 772e 6a75 6861..Host:.www.juha Obrázek 2.8: HTTP komunikace 2.2.3 Zapouzdření protokolů Předchozí výpisy zachytily komunikaci při požadavku na zobrazení webové stránky. Protože ve výpisech nejsou zobrazeny rámce, viděli jsme pouze IP protokol a v jeho datové části jsme nalezli data jiných protkolů. Obrázek A.3 demonstruje použití aplikace Whireshark, která umožňuje lépe vizualizovat sít ový provoz. První v hiearchii vidíme ethernetový rámec s fyzickou adresou zdroje a cíle (48 bit MAC adresy). Uvnitř rámce najdeme protokol IP, který adresuje zdroj a cíl logickými IP adresami. Za hlavičkou IP protokolu se nachází jeho datová část, kde nalezneme transportní protokol TCP. V hlavičce transportního protokolu je specifikován cílový port 80, který označuje webovou službu. Pokud se podíváme do datové části TCP segmentu, můžeme vidět protokol HTTP a jeho data, ze kterých lze vyčíst, že se jedná o požadavek na stránku z domény sourceforge.net.
14 2.2 Odposlech komunikace
Kapitola 3 Linuxový firewall iptables Tato kapitola stručně popisuje paketový filtr iptables a tvorbu pravidel. 3.1 Netfilter Netfilter je framework pro správu paketů v linuxovém jádře. Framework programátorům poskytuje záchytné body ve formě háčků (hooks), které si můžeme představit jako místo, kde si programátor zaregistruje svého posluchače, který ho bude upozorňovat v případě vzniklé události, např. při příchodu paketu. Netfilter umožňuje pakety modifikovat a vracet je zpět jádru. Díky této vlastnosti lze realizovat překlady adres a modifikovat hlavičky sít ových protokolů. 3.2 Iptables Iptables je softwarový stavový firewall postavený nad frameworkem Netfilter. Umožňuje filtrování paketů a funkci NAT. Definuje skupinu tabulek, do kterých uživatel voláním aplikace iptables registruje pravidla do řetězců. Každý předdefinovaný řetězec významově odpovída háčkům, které definuje framework Netfilter. 3.2.1 Tabulky Iptables logicky rozdělují způsob práce s pakety pomocí tabulek. Každá tabulka má předdfinovány řetězce nad kterými uživatel vytváří pravidla. Uživatel má možnost v každé tabulce definovat vlastní řetězce, které jsou vhodné pro udržení přehlednosti nebo svým názvem 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živatel explicitně pracovat s jinou tabulkou, pomocí přepínače -t uvede konkrétní tabulku. Tabulka filter obsahuje předdefinované řetězce: INPUT - příchozí paket je adresován přímo na lokální stroj (firewall) OUTPUT - paket byl vytvořen na lokálním stroji a chce odejít FORWARD - paket není určen pro lokální stroj a jen prochází Tabulka nat Tabulka nat, jak už její název napovídá, je určena pro překlad adres, tzn. modifikaci zdrojových a cílových IP adres a jejich portů. Nad tabulkou nat jsou definovány řetězce: PREROUTING - příchozí paket je odchycen před směrováním OUTPUT - paket byl vytvořen na lokálním stroji a je odchycen před směrováním POSTROUTING - odchozí paket již prošel směrováním a chce odejít Tato tabulka je záludná v tom, že překlad adres se uplatňuje jen při vytváření nového spojení. Iptables si spojení vnitřně označí a překlad se děje transparentně. Pro uživatele to znamená, že veškerá pravidla, která zde vytvoříme, se uplatní jen pro první paket spojení. Další pakety v ustaveném spojení už do tabulky nat nevstupují. Tabulka mangle Nevýhodu předešlé tabulky odstraňuje tabulka mangle, která se používá pro modifikaci paketů za každé situace. Tabulka definuje tyto řetězce: PREROUTING - příchozí paket je odchycen před směrováním INPUT - příchozí paket je adresován přímo na lokální stroj OUTPUT - paket byl vytvořen na lokálním stroji a je odchycen před směrováním POSTROUTING - odchozí paket již prošel směrováním a chce odejít FORWARD - paket není určen pro lokální stroj a jen prochází
3.2 Iptables 17 Tabulka raw Poslední tabulka je určena pro trasovací účely a definuje řetězce PREROUTING - příchozí paket z jakéhokoliv rozhraní OUTPUT - všechny lokálně generované pakety 3.2.2 Pravidla Pravidla se zapisují ve tvaru: iptables [-t tabulka] [operace_nad_řetězcem] [podmínka] [-j skok] Každé pravidlo je definováno nad tabulkou a řetězcem, který může být uživatelský nebo předdefinovaný. Dále následuje zachytávací podmínka, která určuje, kdy pravidlo vyhovuje. Skok na cíl určuje, co se s paketem provede, pokud vyhověl zachytávací podmínce. Následující zápis pravidla způsobí zahazování paketů s protokolem TCP určených na port 80 (HTTP): iptables -t filter -A FORWARD -p tcp --dport 80 -j DROP Protože tabulka filter je implicitní, lze celý parametr-t filter vynechat. Další příklady pravidel jsou uvedeny v kapitole 4.1.2. 3.2.3 Cíle skoku U každého pravidla můžeme definovat cíl, tedy co se má s paketem provést, pokud pravidlu vyhoví. Za základní cíle skoku můžeme považovat tyto: ACCEPT - paket vyhověl, už neprochází dalšími pravidly DROP - paket zahozen REJECT - paket zahozen, pošle však zdroji ICMP zprávu o odmítnutí QUEUE - pošle paket do uživatelského prostoru 1 RETURN - skok na konec řetězce, což způsobí návrat do rodičovské větve pravidel, osud paketu závisí na nadřazených pravidlech, nebo skončí v implicitní politice firewallu. SNAT, DNAT, MASQUERADE 2 - tyto skoky slouží pro práci s překladem adres. 1 Pod uživatelským prostorem se myslí aplikace, která má zájem pakety zkoumat, například systémy pro detekci průniku (IDS) 2 Maškaráda (MASQUERADING) je transparentní případ překladu zdrojových adres (SNAT) bez nutnosti specifikovat rozsahy zdrojových portů.
18 3.2 Iptables Iptables používají další cíle skoku, které rozšiřují funkčnost firewallu a je možné je podrobně prostudovat v dokumentaci. Za zmínku stojí cílový skok s názvem LOG, který způsobí, že informace o paketu se pošlou systémovému démonu syslogd, který zapíše záznam do souboru /var/log/messages, pokud není není nastaveno jinak. To je vhodné např. pro detekci útoku 3. 3.2.4 Průchod tabulkami a řetězci Jakmile paket dorazí do jádra operačního systému, jádro klasifikuje zda paket: byl adresován přímo na lokální stroj byl vytvořen na lokálním stroji a odchází prochází, není adresován na lokální stroj (FORWARDING) Algoritmus popisující průchod paketu paketovým filtrem, který je vyjádřen následujícími tabulkami, jsem převzal z dokumentace iptables [2]. Obrázek A.4 pak zachycuje celý rozhodovací algoritmus komplexně. Příchozí paket Předpokladem je, že paket dorazil na sít ové rozhraní a ovladač tohoto zařízení informoval linuxové jádro, že v pamět ovém prostoru má připraven příchozí paket. Jádro tuto událost zpracuje asynchronně a paket logicky putuje přes paketový filtr podle tabulky 3.2. Odchozí paket Odchozí paket, který byl vytvořen na lokálním stroji, jehož IP adresa je uvedena jako zdrojová v IP hlavičce, byl vygenerován lokální aplikací. Paket prošel směrováním, aby se vybralo sít ové rozhraní, které se použije pro odchod paketu. Nyní paket putuje v jádře podle postupu uvedeného v tabulce 3.3. Průchozí paket Předpokládáme situaci, kdy se na firewall dostane paket, který je adresován jinému hostitelskému počítači v síti a přes firewall pouze prochází. Tabulka 3.1 zachycuje tuto situaci. 3 Předpokladem je, že systémový administrátor tyto soubory pravidelně čte.
3.2 Iptables 19 3.2.5 Politiky V případě, kdy firewall projde všechna pravidla pro daný paket a ten žádné z nich nevyhoví, záleží na politice firewallu, zda paket pustí nebo ne. Politika je tedy poslední soud pro paket, kterému se podařilo prokličkovat mezi všemi pravidly. Výchozí politika firewallu se definuje příkazem: iptables -P {INPUT OUTPUT FORWARD} {ACCEPT DROP} V podstatě existují dva přístupy při tvorbě výchozí politiky: Politikou vše zakážu a explicitními pravidly povolím výjimky. Politikou vše povolím a explicitními pravidly zakážu definovaná spojení. Výhody a nevýhody obou variant jsou zřejmé. První varianta je bezpečná, ale není pohodlná, protože aby vše fungovalo, musí administrátor znát všechny typy spojení a ručně je povolit. Většinou se jedná o dlouhodobý proces. Druhá varianta je z hlediska bezpečnostni naivní, ale pro administrátora pohodlná. Příklad výchozí politiky, která zahazuje vše 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áci s paketovým filtrem iptables je kromě definice pravidel užitečné zobrazit si aktuální konfiguraci firewallu. Můžeme použít příkaz: iptables -L [-t tabulka] [řetězec], kde přepínač -L diktuje zobrazit seznam pravidel (LIST) a přepínač -t určuje tabulku, se kterou chceme pracovat. Neuvedeme-li explicitně tabulku, bude vypsána implicitní tabulka filter. Parametr pro specifikaci řetězce není povinný. Není-li uveden, vypíší se všechny řetězce definované nad tabulkou. Dále máme možnost použít příkaz určený pro nativní export pravidel, jenž je znakově čitelný. iptables-save [-c] [-t tabulka] Pokud neuvedeme argumenty, zobrazí se celá konfigurace firewallu, kterou je vhodné přesměrovat do souboru. Přepínač -c, slouží k zachování čítačů (counters), které se sledují pro statistické účely. Zbývající argument má stejný význam jako v předchozím příkladě. Pro zpětný import pravidel, např. po restartu počítače, slouží příkaz iptables-restore.
20 3.2 Iptables krok tabulka řetězec komentář 1 raw PREROUTING Opět můžeme v tomto místě označit paket, aby nebyl zachycen trasovacím systémem. 2 Trasovací systémy na tomto místě již sledují spojení. 3 mangle PREROUTING Tento řetězec je používán pro modifikaci paketů před směrováním, např. změna TOS polí. 4 nat PREROUTING Tento řetězec se používá pro DNAT. 5 Jádro provádí znovu směrování paketů, zda se paket bude přesměrovávat na jiné rozhraní. 6 mangle FORWARD Tato konfigurace tabulky a řetězce se používá pro speciální případy, kdy chceme modifikovat paket, který prošel směrovacím rozhodnutím. Přes tento řetězec putuje všechen provoz nezávisle na směru. 7 mangle POSTROUTING V tomto řetězci můžeme modifikovat pakety, ale bez možnosti ovlivnit směrovací rozhodnutí, které už bylo vykonáno. 8 nat POSTROUTING Na tomto místě provádíme SNAT. 9 Paket odchází na určené sít ové rozhraní. Tabulka 3.1: Průchod traverzujícího paketu paketovým filtrem
3.2 Iptables 21 krok tabulka řetězec komentář 1 raw PREROUTING Tento řetězec pracuje s pakety ještě před tím, než jakýkoliv trasovací systém zachytí provoz. Tato konfigurace tabulky a řetězce se používá pro ladění nebo pro specifická spojení, která nemají být zachycena trasovacími systémy. 2 Trasovací systémy již na tomto místě sledují všechna spojení. 3 mangle PREROUTING Tento řetězec je obvykle používán pro modifikaci paketů před směrováním, např. změna TOS polí. 4 nat PREROUTING Tento řetězec se nejvíce používá pro DNAT. 5 Jádro provádí směrování paketů. 6 mangle INPUT Tento řetězec se používá pro zachycení paketu, který prošel směrováním a ještě nedorazil k cílovému procesu. 7 filter INPUT V tomto řetězci filtrujeme všechen provoz určený na lokalní stroj bez ohledu na to, z jakého sít ového rozhraní provoz přišel. 8 Paket dorazil k lokálnímu procesu. Tabulka 3.2: Průchod paketovým filtrem - příchozí paket
22 3.2 Iptables krok tabulka řetězec komentář 1 raw OUTPUT Tento řetězec pracuje s pakety ještě před tím, než jakýkoliv trasovací systém zachytí provoz. 2 Trasovací systémy na tomto místě již sledují spojení. 3 mangle OUTPUT Tento řetězec je obvykle používán pro modifikaci paketů před směrováním, např. změna TOS polí. 4 nat OUTPUT Tento řetězec se nejvíce používá pro NAT lokálně vytvořených paketů. 5 Jádro provádí znovu směrování paketů, protože tabulka mangle a nat mohla ovlivnit směrovací rozhodnutí. 6 filter OUTPUT V tomto řetězci filtrujeme odcházející pakety vzniklé na firewallu. 7 mangle POSTROUTING V tomto řetězci můžeme modifikovat pakety, ale bez možnosti ovlivnit směrovací rozhodnutí, které už bylo vykonáno. Najdeme zde i pakety, které firewallem procházejí. 8 nat POSTROUTING Na tomto místě provádíme SNAT. 9 Paket odchází na určené sít ové rozhraní. Tabulka 3.3: Průchod paketovým filtrem - odchozího paket
Kapitola 4 Experimentální úlohy s iptables Cílem sady experimentů je zjistit, jaké jsou hranice linuxového firewallu založeného na iptables a kdy je firewall na hranici svých možností. Předmětem zkoumání je softwarový firewall iptables 1.3.8, která běží na linuxovém kernelu verze 2.6.21. Verze operačního systému (jádra) je důležitá, protože způsob práce se vstupními frontami zásadně ovlivňuje chování firewallu a je závislá na implementaci operačního systému. Analýza experimentů se opírá o aplikaci tcpdump 3.9.5 s knihovnou libpcap v0.9.5, která umožňuje monitoring provozu na sít ových rozhraních. 4.1 Příprava Nejdříve jsem musel vytvořit prostředí, ve kterém bych dokázal vyprodukovat dostatečně velkou zátěž, abych firewall tzv. utahal, protože bez vhodné zátěže nemohu pozorovat výrazná zpoždění. Protože nejsem správcem žádného systému, kde bych mohl sledovat firewall na reálné zátěži, musel jsem takové prostředí vybudovat. Dále jsem se musel zamyslet, jak sledovat veličiny, které jsou předmětem mého zájmu, a jak všechna měření uspořádat. 4.1.1 Testovací prostředí Prvním krokem je vytvoření testovacího prostředí, které bude společné pro první dva experimenty. Hostitelský počítač laptop slouží jako budící prvek a spojení, které navazuje na počítač dell-nat. Abych se vyhnul vlivu aktivního prvku (hub), je dvojice počítačů dell-nat a theresa-nat propojena přímo kříženým kabelem, který je označen červeně. Linuxový firewall, který je předmětem zkoumání, je provozován na počítači dell-nat. Zbylý hostitelský počítač
24 4.1 Příprava Obrázek 4.1: Testovací prostředí desktop je využíván pouze pro reporty vždy po ukončení experimentu. Parametry jednotlivých prvků naleznete v příloze. 4.1.2 Vytvoření zátěže Zátěž lze docílit dvěma způsoby; bud nashromážděním dostatečného počtu klientských stanic, které budou vytvářet spojení přes firewall, nebo zahlcením firewallu provozem vznikajícím z dvojice strojů realizujících překlad adres, které po určitou dobu vracejí pakety přes firewall tam a zpět. Z obrázku je patrné, že jsem si zvolil druhý způsob. Jak jsem už naznačil, budícím prvkem je počítač laptop; ten generuje TCP SYN pakety na počítač dell-nat na port 81 pomocí konzolové aplikace hping. Perioda vysílání je volitelná. Hostitelské jméno počítače dell-nat napovídá, že plní funkci překladu adres, a to adres cílových (DNAT - Destinantion NAT). Všechny pakety obsahující protokol TCP s níže uvedenými porty budou přeposlány na hostitele theresa-nat podle těchto pravidel. iptables -t nat -A PREROUTING -p tcp --dport 81 -j DNAT --to 192.168.0.4:82 iptables -t nat -A PREROUTING -p tcp --dport 83 -j DNAT --to 192.168.0.4:84 iptables -t nat -A PREROUTING -p tcp --dport 85 -j DNAT --to 192.168.0.4:86 iptables -t nat -A PREROUTING -p tcp --dport 87 -j DNAT --to 192.168.0.4:88 iptables -t nat -A PREROUTING -p tcp --dport 89 -j DNAT --to 192.168.0.4:90 Obrázek 4.2: dell-nat: pravidla pro překlad cílových adres a portů Když na port 80 hostitelského počítače dell-nat dorazí TCP SYN paket, linuxový firewall projde seznam pravidel. V řetězci PREROUTING odchytí paket ještě před okamžikem, než linuxové jádro rozhodne o směrování paketu. Protože první pravidlo vyhovuje, firewall změní cílovou IP adresu a port na 192.168.0.4:82, což je IP adresa stroje theresa-nat Paket dále
4.1 Příprava 25 pokračuje po červeně označeném spoji na druhý stroj theresa-nat na port 82. Na stroji theresa-nat je také linuxový firewall s podobnou sadou pravidel, která vracejí pakety zpět na IP adresu stroje dell-nat, a to na porty s lichými čísly. Vzniká tak paketový ping pong, kdy paket dorazí nejprve na stroj dell-nat na port 81. Následně se paket postupně pohybuje mezi stroji dell-nat, theresa-nat a inkrementuje se číslo portu, dokud nedosáhne hodnoty 91. iptables -t nat -A PREROUTING -p tcp --dport 82 -j DNAT --to 192.168.0.2:83 iptables -t nat -A PREROUTING -p tcp --dport 84 -j DNAT --to 192.168.0.2:85 iptables -t nat -A PREROUTING -p tcp --dport 86 -j DNAT --to 192.168.0.2:87 iptables -t nat -A PREROUTING -p tcp --dport 88 -j DNAT --to 192.168.0.2:89 iptables -t nat -A PREROUTING -p tcp --dport 90 -j DNAT --to 192.168.0.2:91 Obrázek 4.3: theresa-nat: pravidla pro překlad cílových adres a portů 4.1.3 Zpoždění paketu Po sestrojení testovacího prostředí jsem se zamyslel, jak zjistit hodnotu zpoždění paketu, která je klíčová. Sestavil jsem sadu skriptů, které nad logem sít ového provozu, zachyceného pomocí nástroje tcpdump provádějí následující algoritmus: vyberu záznamy paketů s cílovým portem 83 a 84 (příchozí a odchozí) setřídím je podle sekvenčního čísla paketu (nemění se vlivem DNAT) získávám nad sebou dvojice příchozích a odchozích paketů odečtu čas příchodu a odchodu paketu a získávám zpoždění sestavím datový soubor z dvojic (číslo paketu, zpoždění) pro vizualizaci nástrojem gnuplot 4.1.4 Kapacita media a velikost paketu Hostitelský stroj s firewallem iptables je provozován na technologii 100 Mbit Ethernetu. Tabulka 4.1 zobrazuje teoretickou kapacitu, které je možno na medium dosáhnout. Podle velikosti paketu, která je byla ve všech experimentech 1 500B, vypočítáme hustotu toku v paketech za sekundu.
26 4.2 Experiment první - zjištění pracovní oblasti firewallu technologie max. tok velikost paketu max. tok [Mbit/s] [B] [p/s] 10 Mbit Ethernet 10 1 500 833 100 Mbit Ethernet 100 1 500 8 333 Tabulka 4.1: Kapacita media 4.2 Experiment první - zjištění pracovní oblasti firewallu Experiment vychází z testovacího prostředí a generování TCP SYN paketů, které byly popsány v kapitole 4.1.1. Takto vzniklý provoz se nepodobá skutečnému TCP toku a má spíše charakter útoku. Proto je tok tvořený TCP segmenty s přízakem SYN ten nejhorší případ, a tudíž vhodný k hledání pracovní oblasti. Příjemná vlastnost TCP/SYN paketů je, že nedochází k řízení toku na úrovni protokolu TCP, protože se spojení nikdy korektně neustaví a generátor nečeká na ACK odpověd. 4.2.1 Cíle a předpoklady Firewall se bude chovat jistě odlišně v případě zvyšujícího se vstupního toku a v případě rostoucího souboru pravidel. Cílem je najít pracovní oblast, ve které se firewall ještě chová předvídatelně a má dostatek systémových zdrojů. Následující dvě podúlohy experimentu odhalí pracovní oblast firewallu, jež bude později použita jako hraniční ve všech dalších experimentech. 4.2.2 Klidový režim Nejdříve jsem potřeboval najít klidový režim firewallu, abych zjistil, jaký je průběh zpoždění paketů při nízké zátěži, a použil vzniklý diagram zátěže jako referenční. Volil jsem minimální vstupní tok a ponechal 10 pravidel nutných pro DNAT, nezbytnou funkci testovacího prostředí. Zpoždění paketů při nízké zátěži je znázorněno na obrázku A.5 v příloze, kde se zpoždění pohybuje maximálně do 250 µs. Po celou dobu měření je tato hranice neměnná. 4.2.3 Mezní vstupní tok V této úloze jsem hledal hodnotu mezního vstupního toku, která výrazně ovlivní chování firewallu a zpoždění příchozích paketů. Hodnota mezního toku omezí oblast měření, v níž nebude mít smysl provádět další experimenty. Mezní hodnotu vstupního datového toku jsem určil pokusem, při
4.3 Experiment druhý - soubory pravidel 27 kterém jsem postupně zvyšoval velikost vstupního toku a sledoval vliv na zpoždění paketu. Hraniční tok je 8 300 p/s, je to omezení vyplívající z kapacity media. 4.2.4 Pozorování Experiment ukázal, že pracovní oblast firewallu je v nejhorším případě omezena mezním tokem 7000 paketů za sekundu. Po dosažení této hranice se firewall chová nepředvídatelně a zpoždění pro příchozí pakety je různé podle toho, zda paket přišel v období dočasné saturace firewallu, nebo ne. Obrázek A.6 znázorňuje chování firewallu po dosažení mezního toku. Vidíme zde periodické kolísání zpoždění, kdy po určitou dobu razantně naroste doba na odbavení paketů a na krátkou dobu se firewall zase uklidní. Dále jsem zkoušel několikrát překročit mezní tok. U toků překračujících 8000 paketů za sekundu se firewall dostává do oblasti, kdy sít ový provoz spotřebuje veškerý procesní čas. Tato událost má vliv i na běh ostatních úloh operačního systému. Situace je zajímavá z bezpečnostního hlediska a bylo by vhodné detailně prozkoumat, zda firewall pakety zahodí, přestane úplně pracovat, nebo některé pakety propustí bez přezkoumání souboru pravidel. 4.3 Experiment druhý - soubory pravidel Velikost souborů pravidel ovlivňuje chování firewallu ve dvou rovinách. Při každém obsloužení paketu musí firewall projít seznam všech pravidel a určit, zda paket vyhovuje některému z nich. Což znamená, že s rostoucím počtem pravidel se zvyšuje doba na odbavení paketu. Druhým vlivem na zpoždění paketu je charakter pravidel. Každé pravidlo má různou režii na vyhodnocení, zda vyhovuje, či nikoliv. 4.3.1 Cíle a předpoklady Cílem experimentu je zjistit, jaký vliv má zvětšování souborů pravidel na zpoždění. Vstupní tok je přizpůsobován tak, aby směrodatná odchylka nepřekročila 20µs od střední hodnoty. Jinak řečeno, zajímá mě vliv objemu pravidel na zpoždění, nikoliv vliv typu pravidel na výkon firewallu. Protože odečítání zpoždění paketů v testovacím prostředí je založeno na realizaci NAT, jsou sady pravidel definovány nad řetězcem PREROUT- ING. Předpokládám tedy, že firewall by se nechoval jinak v případě, kdyby různé objemy pravidel byly definovány nad ostatními řetězci firewallu. 4.3.2 Parametry experimentu Měřil jsem v oblasti toku do 6000 paketů za sekundu. Pro každý typ pravidla jsem zvolil předpřipravené soubory o objemu 10, 20, 30, 40, 50, 100, 200, 300,
28 4.3 Experiment druhý - soubory pravidel 400, 500, 1 000 a 2 000 pravidel daného typu. Pravidla jsou unikátní, abych vyloučil vliv vyrovnávacího mechanizmu, pokud firewall nějaký používá. Jako unikátní prvek jsem v případě transportních protokolů volil číslo portu. Výjimkou jsou pravidla pro protokol ICMP, kde jsem cyklicky opakoval typ ICMP zprávy, která má celkem 40 typů. 4.3.3 Typy pravidel Podle dokumentace projektu netfilter jsem vybral podmnožinu zajímavých typů pravidel a jejich zástupce. Obecná pravidla Touto kategorií jsou označena pravidla, která se dotazují na atributy protokolu IP a považují se za pravidla základní. Jako zástupce jsem vybral pravidlo, které 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ástupcem této kategorie je následující pravidlo ověřující cílový 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ástupcem této kategorie je následující pravidlo ověřující cílový port TCP segmentu. iptables -t nat -A PREROUTING -p tcp --dports 1 -j NAKONEC Pravidla ICMP ICMP je služební protokol protokolu IP pro signalizaci chybových stavů a zasílá další řídící zprávy. Zástupcem pro experiment je pravidlo ověřující typ ICMP zprávy. Ve specifikaci ICMP je definováno celkem 40 typů ICMP zpráv. iptables -t nat -A PREROUTING -p icmp --icmp-type 1 -j NAKONEC
4.3 Experiment druhý - soubory pravidel 29 Pravidla kontrolující stav spojení Jediný protokol, který je stavový, je TCP. Stav spojení může odpovídat několika stavům: spojení nové, ustavené, v relaci aj. UDP protokol je sice nestavový, ale firewall je schopen na základě existujících informací usoudit, zda nějaké UDP spojení na portech probíhá. Zástupcem je pravidlo dotazující se na TCP spojení, které je ustaveno z konkrétní IP adresy. iptables -t nat -A PREROUTING -p tcp --192.168.100.1 -j NAKONEC Pravidla pro překlad adres Tato skupina pravidel patří do skupiny aktivních pravidel, protože realizuje překlad adres (NAT) a umožňuje modifikovat pakety. Funkcí NAT lze modifikovat IP adresy v hlavičce IP protokolu a porty v hlavičkách transportních protokolů. Jako zástupce jsem vybral pravidlo, které v případě shody, kdy cílová IP adresa ukazuje na hostitele 192.168.101.1, dojde k překladu cílové IP adresy a čí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ý firewall umožňuje použít mnoho dalších pravidel, jako je např. logování paketů do souboru, značkování paketů pro budoucí řízení toku, modifikace jiných částí paketů než je IP adresa a porty. Z praktických důvodů není možné postihnout všechna tato pravidla a zahrnout další moduly, které rozšiřují funkčnost firewallu o nová pravidla. 4.3.4 Pozorování Obrázek A.7 ukazuje, k jakému zpoždění dochází u jednotlivých typů pravidel v závislosti na velikosti souboru pravidel. Podle výsledků měření jsem každé pravidlo zařadil do jedné ze tří skupin: Pravidla s nízkým zpožděním Pravidla se středním zpožděním Pravidla s vysokým zpožděním Pravidla s nízkým zpožděním Do první skupiny patří pravidla, která způsobují předvídatelné zpoždění paketů i při velkých objemech. Zpoždění s rostoucím objemem pravidel
30 4.4 Experiment třetí - náhodné intervaly vysílání vzrůstá téměř lineárně. Na každých deset pravidel připadá zpoždění o 3µs větší. Patří sem pravidla pracující s obecnými dotazy nad protokolem IP a také pravidla pro ověření stavu TCP spojení, která jsou označená světle modrou barvou. Překvapivě do této skupiny patří i pravidla provádějící NAT. Předpokládám, že tato pravidla budou mít dopad na výkon firewallu, což není v tomto experimentu zřejmé, protože bereme ideální případ datového toku pro daný typ pravidel. Pravidla s nízkým zpožděním Mezi druhou skupinu pravidel patří pravidla pro práci s protokolem ICMP a pravidla dotazující se na atributy transportního protokolu UDP. Zde je situace zajímavější, protože rostoucí křivka vyjadřující zpoždění v závislosti na počtu pravidel už nemá lineární průběh. Např., pokud objem těchto pravidel přesahuje počet 600, vidíme, že vzniklé zpoždění je proti první skupině teměř o jednu polovinu větší. U souboru 1 000 pravidel je to již dvojnásobné zpoždění. V případě pravidel nad protokolem ICMP si nedokážu představit praktické použití v objemu větším než stovek, což je oblast, ve které nedochází k velkým rozdílům zpoždění vzhledem k ostatním skupinám. Naproti tomu u protokolu UDP už lze předpokládat častější výskyt použití většího objemu pravidel. Pravidla s vysokým zpožděním Poslední skupinu, která má největší vliv na zpoždění paketu vzhledem k počtu pravidel, tvoří pravidla pracující s atributy protokolu TCP. Tento protokol je nejvíce zastoupen v běžném sít ovém provozu a administrátor by měl počítat s dopadem na zpoždění při daných objemech použitých pravidel, která jsou výrazná vzhledem k ostatním skupinám. 4.4 Experiment třetí - náhodné intervaly vysílání Předchozí úloha pracovala s TCP/SYN pakety, které zdroj generoval v pravidelných intervalech. Skutečné toky založené na TCP protokolu jsou charakteristické tím, že nejdříve ustaví spojení a teprve následně probíhá přenos dat a jejich potvrzování. Přenos dat po takto ustaveném kanálu má spíše náhodný charakter než periodický průběh. Následující experiment pracuje s korektně ustavenými TCP spojením s náhodnými intervaly mezi příchozími pakety.
4.4 Experiment třetí - náhodné intervaly vysílání 31 Obrázek 4.4: Testovací prostředí pro třetí experiment 4.4.1 Cíle a předpoklady Cílem experimentu je zjistit zpoždění paketů v závislosti na velikosti toku a počtu pravidel. Předpokladem je ustavení korektního TCP spojení. Intervaly mezi starty paketů jsou definovány náhodnou veličinou, jež má Poissonovo rozdělení. 4.4.2 Testovací prostředí Testovací prostředí jsem upravil dle obrázku 4.4, protože ustavené TCP spojení vyžaduje potvrzování směrem ke zdroji a předchozí zapojení testovacího prostředí tomuto požadavku nevyhovovalo. Hostitelský stroj laptop, který je v roli generátoru TCP paketů, je nucen zasílat data přes firewall, jenž zaznamenává příchozí a odchozí pakety. Cílem komunikace je hostitelský počítač desktop. 4.4.3 Generování paketů Předchozí generování paketů pomocí aplikace hping je pro tento experiment nevyhovující. Hledal jsem generátor sít ového provozu, podporující protokol TCP s volbu náhodného intervalu mezi starty paketů, které mají Poissonovo rozdělení. Jako vhodný generátor se osvědčil soubor aplikací D-ITG, který používá agenta ITGSend, a jenž splňuje výše uvedené požadavky. Následující příklad vytvoří TCP tok po dobu jedné minuty o průměrném toku 5000 paketů za sekundu s náhodnými intervaly mezi vysílanými pakety, mající Poissonovo rozdělení. ITGSend -a 192.168.0.10 -O 5000 -t 60000 -T TCP Aby generátor správně pracoval, musí se na cílový hostitelský počítač nainstalovat agent, který přijímá a potvrzuje příchozí spojení aplikací ITGRecv. 4.4.4 Parametry experimentu Měřil jsem shodný soubor pravidel, jenž byl popsán v kapitole 4.3.3, a redukoval jsem objemy na množiny: 10, 100, 200, 300, 400, 500, 1 000 a 2 000
32 4.4 Experiment třetí - náhodné intervaly vysílání pravidel. Každý jednotlivý soubor pravidel jsem měřil po dobu jedné minuty s parametrem toku. Vyzkoušel jsem aplikací ITGSend předat následující toky 5 000, 8 000, 10 000, 12 000 a 14 000, které podle prvního testu posouvali hranici zpoždění. Na první pohled je zřejmé, že toky nad 8 000 p/s nelze po mediu vysílat, proto je v pozorování nebudu interpretovat. Reálně zaznamenané toky na přijímací straně daleko nižší a ve výjimečných případech překračují max. kapacitu kanálu. 4.4.5 Pozorování Graf pro každý typ pravidla zobrazuje střední hodnoty toků a zpoždění; barvou jsou odlišeny velikosti souborů pravidel. Na první pohled se zdá, že body v grafu vyjadřující zpoždění nemají žádný řád, který by alespoň vystihoval závislost zpoždění a toku. Jedinou pravidelností je bod se zpožděním 45 µs v místě toku 5 000 p/s. Pokud bychom u každého grafu zakryli jeho levou část od výše popsaného bodu, uvidíme rostoucí křivky v závislosti na hustotě toku. Souvislosti mezi velikostí souborů tato úloha neprokazuje. Velmi podobný obor hodnot je u všech grafů v oblasti toku 7 000 p/s. Např. na obrázku A.10 lze vypozorovat, že IP pravidla o velikosti 10 a 2 000 pravidel mají podobnou strmost a průběh, ale vystihují opačnou kvantitu, proto nelze nalézt vliv velikosti souboru na zpoždění. Obrázku A.11 vystihuje zajímavou situaci TCP pravidel, kdy pro toky blížící se k hranici kapacity media, firewall odbavil většinu paketů do 400 µs.
Kapitola 5 Experimentální úlohy s hardwarovým firewallem V této kapitole uvedu základní parametry a strukturu hardwarového firewallu CISCO PIX 506 (dále jen firewall) a zkonstruuji pro toto zařízení podobné experimentální úlohy jako pro linuxový firewall iptables. 5.1 Hardware Hardwarový firewall patří mezi levnější firewally, které firma CISCO nabízela v kategorii malého a středního podnikání. Jedná se o stavový firewall, jehož způsob rozhodování označuje CISCO algoritmem ASA (Adaptive Security Algorithm). Dále podporuje tvorbu VPN tunelů a detekuje vybrané typy útoků. Zařízení využívá 200 MHz procesor s 32MB RAM, 8MB FLASH ROM a je určeno pro trvalé uložení nastavení. Firewall má dvě ethernetová rozhraní podporující rychlost 10Mbit/s a jeden konektor pro sériovou komunikaci. Na trhu je stále k dispozici verze s označením PIX 506E, která podporuje 100 Mbit Ethernet a používá procesor Celeron taktovaný na 300MHz. 5.1.1 Nastavení komunikace Zapůjčené zařízení bylo v provozu a lze očekávat, že nebude nastaveno v továrním nastavení. Pro prvotní oživení jsem použil sériovou linku a aplikaci minicom. Parametry komunikace přes sériovou linku definuje dokumentace, stačí nastavit rychlost, paritu a stop bit. 5.1.2 Obnova továrního nastavení Firewall po startu zobrazil hardwarové parametry a vyžadoval autentizaci. Procedura pro restart hesla spočívala v přepnutí zařízení do monitor módu
34 5.2 Struktura firewallu a konfiguraci zařízení pro stažení binárního souboru z TFTP serveru 1. Po restartu bylo možné uvést firewall do továrního nastavení. Nakonfiguroval jsem IP adresy na rozhraních a povolil telnetové spojení, díky kterému už není nutné používat sériovou linku pro komunikaci s firewallem. 5.2 Struktura firewallu Firewall podporuje překlad adres a portů, dále filtruje provoz na několika úrovních [3]: Kontrola hardwarových adres na linkové vrstvě Kontrola protokolu IP, transportních protokolů a jejich portů Inspekce vybraných aplikačních protokolů; kromě standardních protokolů HTTP, DNS, FTP zde najdeme SQLNet 2 Omezené filtrování některých protokolů ActiveX, Java applety, filtrace HTML <object> značek, filtrování URL adres pro protokoly HTTP, HTTPS, FTP je možné za pomocí filtračních serverů Firewall má další vlastnosti: Podpora VPN tunelů Využití systémů pro externí autentizaci RADIUS, TACACS+ Zabraňuje vybraným útokům na zdroje firewallu, které mají záplavový charakter (flooding attack) Auditní systém (IDS) na bázi sledování IP paketů; pokud vyhovuje signatuře, může firewall paket zahodit, resetovat TCP spojení, nebo odeslat zprávu démonu syslog 5.3 Konfigurace firewallu Spustil jsem aplikaci minicom a dostal jsem na konzoli příkazový řádek firewallu. Nyní lze komunikovat s proprietárním operačním systémem. Uživatel konfiguruje zařízení v privilegovaném režimu, do kterého se přepne příkazem configure terminal. Nejdříve jsem nastavil sít ová rozhraní a přiřadil k nim IP adresy a masky. 1 TFTP (Trivial File Transfer Protocol) je zjednodušená varianta protokolu FTP pracující s transportním protokolem UDP. Protokol v podstatě umí pouze přenášet soubory mezi serverem a klientem a je vhodný právě pro hardwarová zařízení nebo jednoduché stanice na lokální síti, které potřebují stáhnout soubor a nahrát si jej do paměti. 2 Sít ový protokol společnosti Oracle, který je postaven nad transportními protokoly a používá se pro komunikaci mezi klienty a databázemi Oracle
5.4 Testovací prostředí 35 interface ethernet0 10full (vnější rozhraní) interface ethernet1 10full (vnitřní rozhraní) nameif ethernet0 eth0 security0 nameif ethernet1 eth1 security99 ip address eth0 192.168.0.20 255.255.255.0 ip address eth1 192.168.100.2 255.255.255.0 Obrázek 5.1: Konfigurace sít ových rozhraní Tímto se vytvořily implicitní směrovací záznamy. Pomocí příkazu access-list jsem nastavil firewall, aby přijímal jakýkoliv sít ový provoz. Tento seznam nadefinovaných pravidel jsem přiřadil oběma sít ovým rozhraním a ověřil spojení aplikací ping. access-list 1 permit icmp any any (nutné pro funkčnost ping) access-list 1 permit tcp any any access-list 1 permit udp any any access-list 1 permit ip any any access-group 1 in interface eth1 Obrázek 5.2: Definice pravidel pro vnitřní sít ové rozhraní 5.4 Testovací prostředí Úlohy prováděné na hardwarovém firewallu přinášejí změny v návrhu testovacího prostředí. Logování sít ového provozu na firewallu není již praktické a měřící body se přesouvají na počítače, které jsou zdrojem a cílem toku. Tato úloha si vynucuje synchronizaci času na zdrojové a cílové stanici, aby byly soubory logovacích záznamů reprezentativní. Obrázek 5.3 znázorňuje zapojení testovacího prostředí. Obrázek 5.3: Testovací prostředí pro firewall CISCO PIX 506
36 5.4 Testovací prostředí root@dell:~# ntpq -p localhost remote refid st t when poll reach delay offset jitter ============================================================================= *LOCAL(0).LOCL. 10 l 12 64 377 0.000 0.000 0.002 Obrázek 5.4: Dotaz na seznam spojení NTP serveru 5.4.1 Časová synchronizace Časovou synchronizaci jsem zajistil protokolem NTP 3, kde na hostitelském stroji laptop je nainstalován NTP server. Cílový počítač dell-nat je v roli NTP klienta a jeho softwarový firewall se již nevyužívá. Synchronizace času klienta je zajištěna periodickým dotazování aplikace ntpdate proti NTP serveru. 5.4.2 Import pravidel Firewall sice umožňuje interaktivně definovat pravidla, ale tento způsob práce není příliš praktický, vezmeme-li v úvahu, že testujeme soubory o objemu stovek pravidel. Společnost Cisco sice dodává pro správu software PDM 4, ale preferuji spíše možnost skriptování a tak jsem přemýšlel jak tento problém vyřešit. Z dokumentace jsem zjistil, že firewall podporuje zálohu konfigurace přes TFTP. Usoudil jsem, že je možné vyexportoval konfiguraci PIX firewallu do textového souboru, následně do něj přidat pravidla a naimportovat pravidla zpět. Prakticky se však firewall chrání před modifikací exporotvaného souboru kontrolním součtem. Kdyby se mi podařilo kontrolní součet obejít, je zde stále riziko rozkonfigurování celého zařízení v případě uživatelské chyby. Prostudoval jsem nápovědu k aplikacím minicom a telnet, jakým způsobem bych mohl po ustavení spojení s hardwarovým firewallem posílat příkazy ze souboru, kde bych si vždy vygeneroval potřebnou sadu pravidel. Nakonec jsem dospěl ke skriptu na výpisu 5.5. Skript obsahuje kulaté závorky, které označují substituci na úrovni shellu. Před zpracováním samotného skriptu interpret shellu vyhodnotí nejdříve všechny příkazy v kulatých závorkách a provádí tak substituci před vlastním zpracováním skriptu. Následně interpret shellu začíná zpracovávat skript a vygenerovaný text předává pomocí speciálního operátoru na vstup relace telnet. Protože 3 NTP (Network Time Protocol) je protokol služby řešící časovou synchronizaci, která je na lokální síti schopna teoreticky dosáhnout přesnosti 200µs pomocí rozesílaných časových známek. NTP využívá k přenosu transportního protokolu UDP na portu 123. 4 PDM (Cisco PIX Device Manager) je konfigurační utilita založená na webovém rozhraní. Nalezl jsem také nástroj čistě pro Linux s názvem Firewall Builder, který podporuje správu politik Cisco PIX firewallu včetně iptables.
5.5 Experiment první - tok TCP/SYN 37 data jsou na vstup aplikace telnet předávána velmi svižně, je skript doplněn o příkazy sleep, které skript pozastaví. Uvnitř skriptu ještě vidíme iterační smyčku for, která generuje pravidla vyhovující pro konkrétní IP adresu s protokolem TCP pro jednotlivé porty. #!/bin/bash ( echo "admin" sleep 1 echo enable echo "" echo "configure terminal" echo "clear access-list 3" echo "access-list 3 permit icmp any any" echo "access-list 3 permit tcp any any" echo "access-list 3 permit udp any any" echo "access-list 3 permit ip any any" echo "access-group 3 in interface eth1" sleep 1 for ((i=1; i <= 10;i=i+1)) ; do echo "access-list 3 permit tcp any host 192.168.101.1 eq ${i}" done; echo logout exit ) telnet 192.168.100.2 Obrázek 5.5: Skript pro import pravidel do PIX firewallu 5.5 Experiment první - tok TCP/SYN 5.5.1 Předpoklady Zvolil jsem si objemy pravidel o velikostech 10, 100, 500, 1 000 a 2 000. PIX firewall při vytváření pravidel filtruje duplicity, což vyžaduje změnu generování pravidel. Z časových důvodů jsem do experimentu zahrnul pouze pravidla pro TCP, UDP a NAT, protože se mi nepodařilo dostatečně rychle nakonfigurovat synchronizaci s lokálním NTP serverem, který je pro měření zásadní. Podobně jako u iptables, generuji tok TCP segmentů s příznaky TCP/SYN pomocí aplikace hping2 po dobu jedné minuty. Z tabulky 4.1 vyplívá, že pro 10 Mbit Ethernet je max. kapacita kanálu 833 p/s, pokud je jeden paket dlouhý 1500B. Empiricky jsem nastavil takový interval vysílání, aby hustota toku nepřekročila 100 p/s. Z pozorování synchronizace časů, která probíhala mezi klientem a NTP serverem mohu prohlásit, že hodiny obou strojů byly synchronizovány s přesností na setinu sekundy.
38 5.6 Experiment druhý - náhodný tok 5.5.2 Pozorování Z pozorování vyplynul, že PIX firewall zachovává pro různě velké soubory pravidel TCP nebo UDP téměř konstantní zpoždění 480 µs. Pravidla pracující s překladem adres způsobují skokovou změnu zpoždění na 640 µs. 5.6 Experiment druhý - náhodný tok 5.6.1 Předpoklady Sít ový tok jsem generoval pomocí aplikací ITGSend po dobu jedné minuty pro daný soubor pravidel a definovaný tok. 5.6.2 Pozorování U poslední úlohy s náhodným tokem jsem pečlivě neproměřil všechny body a pravidla. Z obrázku A.15 můžeme vidět, že paradoxně soubor pravidel s menším tokem, způsobuje větší zpodění. Z tohoto křížení lze usuzovat, že nezáleží pouze na síle toku. Graf pro zpoždění použitých pravidel pro protokol UDP vypadá již uspořádaněji, avšak najdeme zde další anomálii v podobě křivky označené zeleně. Závěrečné shrnutí všech pozorování jsem dále uvedl v závěru.
Kapitola 6 Bezpečnost Bezpečnost je iterativní proces, jehož cílem je vylepšovat a neustále ověřovat stav zabezpečení sledovaného systému. Vždy jde o kompromis mezi funkčností a uživatelským komfortem. Protože tato činnost neprodukuje žádný zisk; v řadě společností se systematicky touto činností nikdo nezabývá. Firewally jsou základní strategií každé bezpečnostní politiky, která se neomezuje pouze na implementaci technologií řešících zabezpečení, ale může např. formálně popisovat, jak nakládat s tištěnými materiály, které jsou klasifikovány jako odpad, starými zálohami a pevnými disky. 6.1 Hrozby V dnešní době chráníme naše systémy a citlivá data proti útočníkům, kteří pracují v organizovaných skupinách s vlastní podporou marketingu. Útoky na počítačové systémy již nejsou výsadou odborně vyspělých jedinců. Konkurenční firmy si najímají služby provozované těmito skupinami, aby získaly výhodu na trhu, poškodily jméno konkurenta, nebo získaly informace o budoucích produktech. Pokud nepatříme do skupiny lákavých cílů a nevedeme konkureční boj, jsme stále ohroženi útoky, které mají za cíl získat kontrolu nad hostitelskými stroji a využívat je k pozdějším útokům. 6.2 Formy útoku Firewally vytvářejí falešný pocit bezpečí, protože se uživatelé mylně domnívají, že je firewall uchrání před čímkoliv. Pokud se podíváme na firewall z pohledu útočníka, zjistíme, že lze provádět následující útoky: na protokoly, které firewall propouští na nechráněné konfigurace firewallu
40 6.3 Obrana proti útokům nalezení slabiny v souboru pravidel nalezením zranitelnost v samotné implementaci firewallu pomocí spojení iniciovaného z vnitřní sítě např. škodlivý software na klientských stanicích nebo sociotechnický útok na uživatele nalezení jiného způsobu připojení k vnitřní síti (modemy, wi-fi sítě) z vnitřní sítě, má-li útočník fyzický přístup (zaměstnanec) 6.3 Obrana proti útokům Útočníci objevují techniky průniku, které odborná veřejnost nezná, proto prakticky neexistuje způsob, jak se útokům vždy úspěšně bránit. Můžeme však na zabezpečení pracovat a útočníkovi stížit cestu průniku, útoky detekovat a poučit se z nich. Příprava útoku proti dobře zabezpečenému systému je časově i finančně náročná což odradí určitou část útočníků.
Závěr V rámci své diplomové práce jsem se seznámil se dvěma typy sít ových filtrů a jejich konfigurací na lokální síti. Vybudoval jsem testovací prostředí a navrhl několik měřicích úloh, abych prozkoumal provozní charakteristiky sít ových filtrů. Zaměřil jsem se na časové zpoždění paketů, které vzniká při průchodu paketu firewallem, v závislosti na hustotě provozu, velikosti souboru a charakteru pravidel. Vyhodnocování výsledků jsem zajistil dávkovými skripty, které vizualizují výsledky měření do grafu. Firewall iptables Zatížení tokem TCP/SYN Pro sít ový tok charakteristický TCP/SYN pakety s pravidelnou frekvencí vysílání jsem vypozoroval na minimálním souboru pravidel průměrné zpoždění paketů 150 µs, které jsem definoval jako horní mez při nulovém souboru pravidel. Postupně jsem zvětšoval velikost souboru pravidel a klasifikoval je do tříd podle růstu zpoždění v závislosti na počtu pravidel. První třída pravidel obsahuje pravidla pro protokol IP, vyhodnocování stavu TCP spojení a pravidla realizující DNAT. Tato třída pravidel se vyznačuje zpožděním, které se pravidelně zvyšuje o 3 µs na každých 10 pravidel. Druhou třídu pravidel tvoří pravidla pro protokoly UDP a ICMP, u kterých jsem vypozoroval nárůst zpoždění 4 až 5 µs na každých 10 pravidel. Samostatnou třídu tvoří pravidla pro protokol TCP, kde jsem zjistil nárůst zpoždění 8 µs na každých 10 pravidel, což je dvakrát tak více, než je zpoždění vzniklé při procházení souboru pravidel nad protokolem UDP. Zatížení náhodným tokem Generováním toku pomocí náhodné veličiny s Poissonovým rozdělením, která reprezentuje intervaly mezi starty paketů, se mi nepodařilo prokázat vliv velikosti souboru pravidel na časové zpoždění paketu. Firewall odbavuje příchozí pakety se zpožděním 45 µs pokud nepřesáhneme hustota provozu tok 5 000 p/s. Dalším zvyšováním toku se zpoždění pohybuje v intervalu 100 až 600 µs v závislosti na charakteru toku a typu pravidel.
42 6.3 Obrana proti útokům PIX firewall Konstrukce měřicích úloh byla pro tento firewall více náročná, protože odečítání časového zpoždění se děje mimo vlastní firewall, a hostitelské stroje, které se účastní odečítaní, musí být časově synchronizovány. Zatížení tokem TCP/SYN Ekvivaletní experiment s tokem TCP/SYN paketů ukázal že pravidla pro protokoly TCP a UDP způsobují konstantní zpoždění i když zvětšujeme počet pravidel; firewall odbavuje pakety se zpožděním 480 µs. Zatížení náhodným tokem Pro hardwarový firewall jsem dospěl v případě náhodného toku ke stejnému závěru. Tok nezpůsobuje časové rozdíly při inspekci souborů pravidel stejného typu a různého počtu pravidel. Zhrnutí Charakteristiky zpoždění založené na tocích TCP/SYN umožnily najít pracovní oblasti firewallu a prozkoumat soubory pravidel. Simulovaný provoz s korektně ustaveným TCP spojením a náhodnými intervaly mezi příchozími pakety ukázal, že firewally jsou schopny pracovat s většími objemy pravidel bez známky dopadu na zpoždění. Skutečný sít ový provoz však není nikdy tvořen pouze TCP spojeními, ale je kombinací toků TCP, UDP a diagnostických zpráv ICMP, proto bude chování firewallu vždy záviset na charakteru provozu a jeho konkrétním časovém okně.
Literatura [1] Matthew Strebe, Charles Perkins: Firewally a proxy-servery Computer Press, Brno 2003 [2] Dokumentace projektu Netfilter http://www.netfilter.org [3] Cisco PIX Firewall and VPN Configuration Guide http://www.cisco.com
44 LITERATURA
Dodatek A Příloha Parametry testovacího prostředí: sít 100Mb Ethernet aktivní prvek HUB (5portový EDIMAX bez označení) desktop AMD Duron 1000 MHz, 512 MB RAM OS GNU/Linux - Kubuntu (debian), jádro 2.6.20-15 laptop: Intel Celeron 1200MHz, 360 MB RAM OS GNU/Linux - ArchLinux (slackware), jádro 2.6.22 dell-nat: Intel Pentium II 350 MHz, 64MB RAM OS GNU/Linux Slackware 12.0, jádro 2.6.21.5 theresa-nat Intel Pentium I 75 MHz, 32 MB RAM OS GNU/Linux Slackware 10.1, jádro 2.4.29 Cisco PIX Firewall 506 CPU 300MHz, 32 MB RAM OS CISCO 6.3 2x port - 10Mbit Ethernet
46 A Příloha #! /bin/bash echo " * konverze tcpdump row-dat pro gnuplot" echo "+--------------------------------------" echo " " echo "=> tcpdump offline prezvejkani do txt -tt (timestamp unformat)" # tcpdump -tt neformatovany timestamp => pocet sekund tcpdump -nttr./pix_in >./log/dump01.txt tcpdump -nttr./pix_out >./log/dump02.txt cat./log/dump01.txt./log/dump02.txt >./log/dump.txt echo "=> rozmelnim dump.txt 83 84"./01-list.sh echo "=> a setridim jej podle ID PAKETU"./02-awk.sh echo "=> vypocet zpozdeni mezi pakety, priprava souboru pro gnuplot"./03-awk-gnuplot-prepare.sh./03-awk-gnuplot.sh echo " " echo "vysledek ulozen gnuplot-data.txt" echo "=> vypocet statistiky...=> stats" tcpstat -F -r./pix_in -o "\n pocet paketu za sekundu:%p, celkem %I" > _tcp_stats echo "=> gnuplot..."./gnuplot.sh echo "=> statistika dat..."./stat.sh Obrázek A.1: Hlavní skript pro zpracování naměřených výsledků #! /bin/bash awk BEGIN {r=0;cas=0;dif=0; }; { if (r==1) { r=0; dif=0; printf cas; dif=(($1-cas)*1000); printf " "; printf("%4.2f",dif); printf "\n"; } else { r=r+1; cas=$1; } }./_gnuplot-data-prepare.txt >./_gnuplot-data.txt Obrázek A.2: AWK skript pro výpočet zpoždění
A Příloha 47 Obrázek A.3: Paketový sniffer Wireshark - zanoření protokolů
48 A Příloha Obrázek A.4: Průchod paketu iptables
A Příloha 49 Obrázek A.5: Klidový režim firewallu iptables (TCP/SYN) Obrázek A.6: Při toku 7000 p/s se na firewallu periodicky objevuje saturace (iptables)