Proxy firewall

Úvod

Počítačová bezpečnost patří k ožehavým tématům dneška. V době stále se rozšiřujícího Internetu číhá nebezpečí na každém rohu. Profesionálové o něm dobře vědí a málokdo z nich bere tento problém na lehkou váhu, avšak spousta běžných uživatelů není dostatečně informována, a ti, kteří jsou, si myslí, že se jich nebezpečí napadení cizím útočníkem netýká. To je jeden z největších omylů v této oblasti. Všichni máme na pevném disku informace, které bychom neradi zveřejnili nebo ukázali někomu cizímu. Na jedné straně se oháníme zákony na ochranu osobnosti, na straně druhé necháváme často až příliš nápadně „otevřené dveře“ do našeho systému. Problém počítačové kriminality je čím dál hrozivější. Počítače dnes využívá kdekdo, staly se součástí našich životů a svou práci si bez nich nedokážeme představit.

Největší hrozbou je jistě připojení k počítačové síti. A platí přímá úměra mezi její velikostí a nebezpečím, které se v ní ukrývá. Z toho plyne, že největší síť znamená také největší riziko. Touto je bezesporu celosvětová síť Internet. Díky své rozlehlosti, anonymitě jednotlivých uživatelů, kterých jsou miliony a nedůvěryhodné povaze znamená pro naše data a soukromé informace obrovské riziko, jemuž je potřeba rázně čelit. Vznikly tedy síťové programy a zařízení nazývané firewally, jejichž úlohou je oddělit sítě s různou úrovní důvěryhodnosti a kontrolovat datový tok mezi těmito sítěmi. Kontrola dat probíhá na základě pravidel, která určují podmínky a akce. Podmínky se stanovují pro údaje, které je možné získat z datového toku. Úloha firewallu spočívá ve vyhodnocení podmínky a provedení akce, pokud je podmínka splněna. Základní akcí je povolit či blokovat datový paket. Existují i takové akce, které slouží pouze na zaznamenání nebo změnu hlaviček paketu. Pro snadnější integraci do sítě dnešní firewally podporují i směrování.

Mezi základní způsoby ochrany sítě firewallem patří filtrování paketů na základě zdrojové či cílové IP adresy nebo podle TCP/UDP portů, dále stavová inspekce, která umí přiřadit pakety k příslušnému spojení (díky této vlastnosti firewall rozpozná, že se jedná o pakety vracející se do sítě v rámci spojení, které bylo navázáno zevnitř) a proxy firewall/aplikační brána pracující na aplikační úrovni a vyhodnocující průběh komunikace na této nejvyšší vrstvě. Proxy jednoduše řečeno ukončují spojení směrem od klienta a směrem k serveru navazují spojení nové. Míra bezpečnosti je proto pro konkrétní aplikace velmi vysoká. Spolu s firewally, chránícími síť jako celek, jsou často zmiňovány i tzv. proxy servery, umožňující oddělit klienty (hostitelské stanice) od přímého styku s počítači (resp. servery) „na druhé straně“ informačního řetězce a poskytnout tak anonymitu a bezpečnost uživateli.

Tato práce se bude z velké části zaobírat především tematikou principu činnosti proxy firewallů, ovšem budou zde zmíněny i ostatní typy firewallů, spolu se vzájemným porovnáním jejich vlastností, výhod a nevýhod. Další dvě velké kapitoly budou tvořit překlady síťových adres (NAT) a proxy servery, kterým bude poskytnuto více prostoru. Praktickou část práce bude představovat návrh řešení proxy firewallu postavené na platformě GNU/Linux. Této části spolu s popisem principu činnosti proxy firewallů bude věnována největší pozornost. V samotné příloze na závěr přiložím komentované konfigurační soubory a skripty, které budou na linuxovém serveru otestovány a funkčně využity.

Nezanedbatelná část internetových serverů dnes běží na strojích, které jsou spravovány některým z operačních systémů patřících do rodiny Unix. Proto veškeré, později jmenované programy či softwarové aplikace, budou přizpůsobeny operačním systémům založeným na svobodném jádru Linux a spadající pod licenci GNU General Public License.

Firewally

Technologie firewallů

Firewall (česky by se dalo říct „bezpečnostní brána“ či „ochranný počítač“, pojem se však nepřekládá) je jednoduše řečeno brána oddělující sítě. Může být realizován jako program spuštěný na počítači nebo jako samostatné zařízení. Primárním účelem firewallu je zabránit nechtěné komunikaci z jedné sítě (zóny) do jiné sítě (zóny) a jeden firewall může oddělovat i více než dvě různé sítě (zóny).

Rozlišení, která komunikace bude povolena či zakázána, je řízeno bezpečnostní politikou. Tato politika je vložena do konfigurace firewallu a pro každý požadavek na průchod firewallem jsou aplikována pravidla bezpečnostní politiky, podle nichž firewall rozhodne, zda komunikaci povolit či zakázat. Tato činnost je často nazývána filtrování komunikace a to je příčina, proč jsou firewally někdy označovány jako síťové filtry.

Přehled typů firewallů

Rozdělení firewallů je možné podle úrovně, na které firewall filtruje komunikaci. Buď může fungovat na vrstvě síťové (nejrychlejší a zpravidla také nejméně nákladná varianta, ale filtruje velmi povrchně - rozhoduje se pouze dle informací dostupných na této vrstvě), tyto firewally jsou zpravidla označovány jako paketové. Pro jejich rychlost je vhodné je umístit na místa s hustým provozem, např. vstupní brána do sítě apod.

Firewall může být i stavový, když dokáže rozlišit již navázaná spojení a k nim příbuznou komunikaci (například pro FTP protokol). V tomto případě již ale musí pracovat na vrstvě transportní.

Na aplikační vrstvě pracující firewall je často označován jako proxy firewall. Výhodou těchto firewallů je, že zpravidla plně „rozumí“ fungování aplikací a protokolů a jsou schopny detekovat např. případy jejich nestandardního chování apod., tedy filtrují velmi důkladně. Je tedy nejvhodnější je umístit až na hostitelské stanice či v jejich bezprostředních blízkostech (předřazený jednoúčelový server - firewall).

Poslední dvě možnosti rozdělení tvoří analyzátory paketů a NAT (Network Address Translation)

SW/HW firewally

Hardwarové firewally

HW firewall je aktivní síťové zařízení, které slouží zejména ke kontrole a filtrování datového toku. Obvykle má alespoň jedno vstupní a jedno výstupní síťové rozhraní. Firewall kontroluje procházející data podle definovaných pravidel. Pravidla se aplikují buď na jednotlivé pakety (tzv. paketový filtr) na základě směru toku (vstupní/výstupní), nebo IP adresy a portu (zdroje/cíle). Pokud se zaznamenává stav pro rychlejší zpracování paketů patřících do jednoho toku dat, jedná se o stavový filtr. V případě zpracování aplikačních protokolů jde o tzv. aplikační brány.

Hardwarové firewally jsou specializovaná síťová zařízení, která na první pohled připomínají menší přepínače. Umějí však mnohem více. Kromě přepínání a filtrace paketů provádějí např. analýzu dat na aplikační úrovni (obsah WWW stránek, e-mailů, atp.). Kombinují funkce stavového i paketového filtru a přidávají kontrolu obsahu dat pomocí vyhledávání řetězců. Oproti softwarovému řešení jsou rychlejší, poměrně jednodušeji se konfigurují a spravují (velmi relativní). Poskytují komplexní ochranu a monitorování bezpečnosti sítě. Konfigurovat je můžeme pomocí grafického rozhraní (přes WWW) nebo textového CLI (Command Line Interface)

Z technického pohledu je hardwarový firewall vlastně specializovaný počítač, který obsahuje procesor, paměť a síťová rozhraní.

Součástí mohou být i hardwarové akcelerátory postavené na technologiích ASIC nebo FPGA pro rychlý výpočet šifrovacích algoritmů u VPN či vyhledávání řetězců u systémů IDS (Intrusion Detection System). Např. u firewallu ZyWall 35 umožňuje přídavná PCMCIA karta prohledávání obsahu dat a antivirovou kontrolu. Operačním systémem těchto zařízení může být (kromě proprietárních řešení) například Linux.

Softwarové firewally

Dobře známé jsou softwarové firewally, které mohou běžet na osobním počítači, který může být pro tento účel vyhrazen nebo také ne. V prvním jmenovaném případě bychom se bavili o serverech s více síťovými kartami, které kromě filtrování provádějí i překlad adres NAT. Obvykle je na serveru s firewallem také služba DHCP pro dynamické přidělování IP adres, případně DNS služba pro překlad doménových jmen na IP adresy. Druhý případ značil (koncové) počítače uživatelů. SW řešení je levné a oblíbené – můžeme využít volně dostupný software a přizpůsobit si ho podle svých požadavků. Nastavení však vyžaduje zkušeného administrátora, a také analýza přenosů nebývá příliš jednoduchá. Pod OS Linux je k dispozici již vestavěný firewall v jádře operačního systému s názvem Netfilter.

Kde vytvořit firewall

Podle chráněného subjektu můžeme firewally rozdělit na dva druhy - firewally na ochranu (jednoho) počítače (tzv. „host-based“ firewally) a firewally na ochranu celé sítě (tzv. „network-based“ firewally).

Firewally na ochranu (jednoho) počítače

Firewally určené k ochraně jediného počítače jsou relativně „jednoduché“. Jejich úlohou je chránit jeden jediný počítač (typicky s jednou síťovou kartou), nepotřebují se zaobírat přesměrováním paketů ani překladem adres. Jsou nakonfigurované na počítači, který mají chránit, a tak mohou být pravidla těchto firewallů velmi specifická a umožňovat jen ten síťový provoz, který je potřebný pro zabezpečení služby (služeb) či aplikací na daném počítači.

Takovéto firewally se často používají na doplňkovou ochranu serveru, který je umístěný za nějakým již existujícím („front-line“) firewallem, například (ovšem ne výlučně) ve webhostingovém centru a dále k ochraně jednotlivých osobních počítačů (pracovních stanic) připojených k síti. Proto jsou také často nazývány osobními firewally.

Firewally na ochranu sítě

Ve většině případů je úlohou firewallu oddělit dvě či vícero sítí s různými přístupovými právy nebo obsahem. Dále se budu držet příkladu, ve kterém firewall odděluje Internet (vnější síť) a Intranet (vnitřní síť). Z předešlého logicky vyplívá, že přes firewall musí procházet všechny pakety pohybující se mezi sítěmi. V opačném případě je firewall není schopen kontrolovat. Firewall funguje pro sítě jako bezpečnostní brána (ve skutečnosti vykonává i směrování paketů, takže tato analogie není od věci).

Politika firewallu

V kapitole o bezpečnosti serveru v síti budu hovořit o tom, jak důležité je stanovit si dobrou bezpečnostní politiku. V případě firewallu je důležité zejména rozhodnutí, jak firewall naloží s pakety, jejichž osud explicitně neurčíme. Ze zkušeností odborníků na počítačovou bezpečnost se obecně uplatňuje postup, při kterém „co není výslovně povoleno, je zakázáno“. Tato zvolená strategie se z hlediska zabezpečení jeví jako ucelenější.

Firewall & server versus samostatný firewall

Existují v podstatě dvě řešení, jak implementovat firewall do existující sítě. První řešení předpokládá, že firewall bude na serveru, který bude poskytovat určité služby pro některou ze sítí (nebo obě), které vzájemně propojuje. Bude tedy bránou, firewallem a serverem současně. Toto řešení je méně nákladné, protože nepotřebujeme samostatný počítač na firewall, ale (relativně) není příliš bezpečné. V případě, že na firewallu běží nějaké služby, je možno je za určitých okolností zneužít (ať už jsou chráněné jakýmkoliv způsobem), získat práva administrátora a upravit/smazat pravidla firewallu.

Naproti tomu, když se firewall umístí na úplně samostatný počítač, na kterém neběží žádné služby, je řešení mnohem bezpečnější. V takovém případě je vhodné, jestliže se na firewall přihlašuje administrátor pouze z konzole, aby nemusely na počítači běžet ani služby jako SSH. Všechny služby, které mají být dostupné z Internetu, běží fyzicky na jiném počítači (serveru) a firewall zabezpečí správné směrování paketů pomocí routovací tabulky či překladu adres NAT.

V případě, že síť bude poskytovat služby do Internetu, nejbezpečnějším řešením se stává takové, při kterém firewall propojuje ne dvě, ale tři sítě (Internet, Intranet a DMZ – demilitarizovanou zónu). DMZ je síť, která se používá pro servery s veřejnými službami přístupnými z Internetu. Firewall umožňuje chránit Intranet (do něho proniknou maximálně odpovědi na spojení již iniciované z Intranetu), veřejně dostupné služby jsou v odděleném segmentu sítě a firewall nad všemi drží „stráž“.

Paketové filtr

Paketový filtr umožňuje sledovat síťový provoz na třetí vrstvě ISO/OSI modelu (tj. logické IP adresy). Je mnohem rychlejší, ale jeho správa je komplikovanější a nemá tolik možností jako aplikační proxy, protože se například nedostane ke jménu uživatele, kterému patří zachycené pakety.

Nevýhodou paketového filtru je i to, že někdy musí na serveru fungovat služby, které při komunikaci využívají náhodně vybrané porty (např. při přenosu souborů pomocí služby FTP). Paketový filter „nevidí“ (nepozná) souvislosti mezi pakety a každý analyzuje samostatně. Je tedy třeba povolit buď celý rozsah portů (příliš benevolentní) nebo jej zakázat a takovéto služby nepoužívat (někdy nerealizovatelné) .

Postup paketového filtru:

1. Zjištění zdrojové i cílové IP adresy a portů.

2. Průchod tabulkou po jednotlivých řádcích odshora dolů, dokud není nalezen řádek s pravidlem, který odpovídá danému paketu. Většinou definována i poslední výchozí „policy“.

3. Provede se akce uvedená v příslušném řádku pravidla. Zpravidla se paket propustí („allow“) nebo zahodí („deny“; „drop“), popřípadě i zaloguje, čili se zaznamená přísl. akce do souboru.

Příklad filtračních pravidel pro lokální síť s adresou 192.168.2.0:

První pravidlo zajišťuje navázání TCP spojení iniciovaných z vlastní sítě. Druhé pravidlo zabraňuje útočníkovi vystupovat v síti jako firewall. Třetí pravidlo zabraňuje vnějšímu útočníkovi komunikovat s firewallem. Čtvrté pravidlo umožňuje všem prvkům sítě komunikovat s kýmkoliv z vnější sítě a použít přitom jakýkoliv protokol. Páté pravidlo umožňuje projít všem paketům z vnější sítě, pokud nesou data protokolu HTTP. Poslední šesté pravidlo je velmi důležité - vše co nespadá pod výše uvedená pravidla nepustit do (ze) sítě. Jak je názorně vidět z tabulky, paketový filtr je založen na pravidlech stanovených pro dvojici zdrojová IP adresa a cílová IP adresa. Tyto údaje jsou často ještě upřesněny pro konkrétní TCP nebo UDP porty

Stavové firewally

Speciálním případem paketového filtru je stavový paketový filtr. Ten si dokáže uvést v souvislost procházející pakety a tak si uchovat stav spojení. Jedno navázané spojení a všechny pakety, které k němu patří, se nazývá relace (session). Stavový firewall se oproti paketovému filtru liší také tím, že není obecně univerzální, ale je využitelný pouze pro TCP/IP protokoly.

Stav spojení je možné uplatnit v pravidlech, a tak například automaticky povolit odpovědi na všechny odeslané pakety, povolit spojení, která souvisí s daným, již navázaným spojením po dobu jeho trvání, atd. Toho se s výhodou prakticky využívá např. u řešení již zmíněného problému s FTP.

Tento typ firewallu rozezná paket, který otevírá nové spojení, od paketů, které tuto komunikaci realizují, a díky tomu může precizněji filtrovat datové toky. Pokusy o spoofing, podvržení paketů, které se tváří, jako by se "vracely do sítě" v rámci fiktivního spojení, jsou blokovány.

Softwarový firewall je implementovaný přímo v jádře Linuxu. Ve verzích jádra 2.4.X a 2.6.X je to bezpečnostní nástroj s názvem "iptables", který kromě správy filtrovacích pravidel umožňuje i správu NATu. Samotný firewall (framework pro manipulaci s pakety) se nazývá "netfilter".

Protože je Iptables z technologického hlediska nejdokonalejší (nejpokročilejší), a jelikož je doporučeno používat aktuální stabilní verze jádra Linuxu, budu se v dalších částech textu zaobírat pouze tímto mocným firewallovým nástrojem, který umožňuje linuxovému systému plně pracovat se síťovou komunikací.

Proxy firewally

Firewally se stavovou inspekcí paketů jsou v podstatě rozšířenou verzí běžného paketového filtru. Zde popisovaná zařízení jdou ještě dále a provádějí analýzu paketů na aplikační vrstvě (ochrana na úrovni aplikací). Tuto úroveň ochrany implementuje několik různých technologií, které se označují různými názvy; každá z nich pracuje trochu jinak, ale jejich cíl je stejný - posílit bezpečnost sítě.

Firewally na aplikační úrovni zajišťují nejbezpečnější typ datových spojení, protože dokáží v komunikačním procesu zkoumat úplně všechny vrstvy modelu TCP/IP. Pro zajištění této úrovně ochrany musí uvedené firewally neboli proxy (proxy servery) fakticky vstoupit do probíhající komunikace (do role „prostředníka“, což je v podstatě český význam slova „proxy“) a detailně kontrolovat každé spojení. Jestliže proxy označí dané spojení za povolené, otevře směrem k serveru druhé spojení od sebe sama, jménem původního hostitele, jak vidíme na obrázku 7.

Při této inspekci je nutné odříznout datovou část každého procházejícího paketu, zkontrolovat jej, znovu sestavit a odeslat po druhém spojení. Uvedené funkce lze zajistit v různých typech firewallů:

·        Standardní proxy firewally. Běžný proxy firewall neprovádí směrování paketů a pouze je přeposílá; pracuje v aplikační vrstvě modelu TCP/IP. Z funkčního hlediska přijímá nad jedním síťovým rozhraním pakety, kontroluje je podle definované množiny pravidel, a pokud se rozhodne pro jejich povolení, odešle je přes jiné rozhraní. Mezi vnějším a vnitřním počítačem nikdy neexistuje přímé spojení; z pohledu počítače ve vnitřní síti tak veškeré informace zdánlivě pocházejí od proxy firewallu.

·        Dynamické proxy firewally. Tento typ proxy firewallů se vyvinul ze standardních proxy firewallů, oproti kterým je navíc rozšířen o filtrování paketů. Dynamický proxy firewall tak provádí úplnou inspekci paketů; po prvotním vytvoření spojení a zejména po jeho schválení již stačí ostatní pakety kontrolovat v rychlejším, i když slabším mechanismu filtrování paketů. Podtrženo a sečteno, spojení se nejprve zkontroluje na aplikační vrstvě, a poté již další kontrola probíhá jen na vrstvě síťové.

Tyto proxy firewally tak „vidí“ veškeré informace z aplikační vrstvy modelu TCP/IP. To znamená, že mohou vyhledávat přesněji definované údaje, než jakékoli jiné typy dosud probíraných technologií. Dokáží například rozlišit mezi paketem s e-mailovou zprávou a paketem s javovým appletem či nebezpečným prvkem ActiveX, jak vidíme na obrázku 8. Speciálním případem je SSL proxy, což je varianta proxy firewallu založená na protokolu SSL. S pomocí tohoto protokolu je umožněn uživatelům z vnější sítě (př. Internetu) bezpečný přístup do vnitřní sítě.

Při vstupu do proxy serveru podle obrázku 8 se z paketu odstraní veškeré parametry hlavičky TCP/IP a samotné inspekci dále podléhají vlastní přenášená data. Informace zjištěné při této inspekci se poté předloží firewallovým pravidlům a podle výsledků bude průchod paketu povolen nebo zamítnut. Je-li paket shledán „nezávadným“, tedy povoleným, uloží si proxy firewall informace o daném spojení z hlavičky, přepíše novou hlavičku a upravený paket odešle dále. Zamítnutý paket se jednoduše odstraní.

Omezení možností proxy

Každá technologie má svá omezení nebo určité svoje nevýhody. Zde jsou některá obecná omezení proxy firewallů:

·        Pomalejší činnost. Vzhledem k důkladnému zkoumání a pečlivému zpracování paketů jsou proxy firewally velice bezpečné, ale zároveň také dosti pomalé. Protože se na této úrovni zabezpečení kontrolují v podstatě všechny části všech paketů, bývá činnost proxy firewallů opravdu pomalejší oproti ostatním.

·        Nejsou vždy aktuální. S vývojem nových protokolů a aplikací je nutné odpovídajícím způsobem doplnit či rozšířit i proxy servery, které musí daný provoz označit za přípustný či nikoliv. To znamená, že je k nové aplikaci nutné také vyvinout a otestovat nové proxy servery. To ovšem nějaký čas trvá a do té doby je příslušné bezpečnostní zařízení neaktuální.

Z bezpečnostního hlediska se za nejbezpečnější firewall dá považovat standardní proxy firewall, který provádí inspekci veškerého provozu na aplikační vrstvě. V některých dnešních sítích není takové řešení vždy zrovna praktické a patřičné. Pro návrh správného a dostatečně silného zabezpečení je proto důležité se pečlivě připravit a seznámit se s charakterem síťového provozu i s požadovaným zabezpečením. Firma pro údržbu parků a zahrad bude mít například jiné potřeby zabezpečení než společnost, která vyvíjí elektronické komponenty pro armádní zbraňové systémy.

V každé navrhované síti je nutné v rámci vrstveného zabezpečení provozovat alespoň jeden ze dvou probíraných typů firewallů - stavový nebo proxy firewall. Pokud kromě některé z těchto technologií spustíme také na hraničním směrovači paketový filtr a ve firewallovém zařízení zapneme překlady adres NAT, dostaneme solidní základ vrstvené bezpečnosti sítě.

Jelikož primárním cílem diplomové práce je detailně popsat princip činnosti proxy firewallů, věnuji této bezpečnostní problematice samostatnou kapitolu, která podrobně rozvede všechny možnosti využití proxy, objasní jak proxy fungují a nakonec vyzdvihne přednosti tohoto řešení.

Omezení firewallů

Firewall je důležitou komponentou zabezpečení každé sítě a jeho úkolem je řešit problémy spojené s integritou dat a s autentizací síťového provozu (prostřednictvím stavové inspekce paketů), a dále zajišťovat důvěrnost vnitřní sítě (pomocí překladového mechanismu NAT). Pokud bude síť přijímat veškerý provoz jen přes firewall, dostane se jí plnohodnotné ochrany. O důležitosti firewallu ve strategii zabezpečení nelze pochybovat, přesto je ale důležité si uvědomit, že i firewall se potýká s některými omezeními:

·        Firewall nedokáže zabránit uživatelům a útočníkům s modemy v přímém přihlášení do vnitřní sítě (nebo naopak ze sítě ven); tím ovšem tento uživatel úplně obchází jak firewall, tak i jeho ochranu.

·        Firewally nedokáží uskutečňovat přijaté zásady práce s hesly a nezabrání ani v možném zneužití hesel. Stanovit zásady pro práci s hesly je proto velice důležité, a to včetně sankcí za případné porušování.

·        Naprosto neúčinné jsou firewally také proti netechnickým bezpečnostním rizikům, jako je například známé „sociální inženýrství“.

·        Každý firewall tvoří úzké hrdlo síťového provozu, protože se v něm veškerá komunikace a zabezpečení koncentrují do jediného místa; tím vzniká jediné kriticky zranitelné místo sítě.

Porovnání jednotlivých typů firewallů

Výsledné stručné srovnání jednotlivých typů firewallů z hlediska jejich výhod a nevýhod. U každé vzpomenuté technologie se krátce zmíním o vlastnostech a připomenu základní princip.

Paketové filtry (Packet filter)

Nejjednodušší a nejstarší typ firewallu, kde jsou pakety řízeny pravidly, která uvádějí, z jaké adresy a portu na jakou adresu a port může být doručen procházející paket. Tyto informace jsou získány z hlaviček paketů. Paketový filtr pracuje na síťové vrstvě ISO/OSI modelu.

Toto řešení se vyznačuje jednoduchostí a transparentností, což se projevuje vysokou rychlostí. Z toho důvodu je řešení hojně využíváno v místech, kde není potřeba důkladnější analýza procházejících dat. Další nespornou výhodou proti aplikačním proxy je přizpůsobivost na libovolný typ protokolu.

Nevýhodou je nízká úroveň kontroly procházejících spojení. To je způsobeno schopností sledovat pouze jednotlivé pakety bez možnosti hledání závislostí mezi nimi. Další nevýhody jsou absence autentizace vůči firewallu, relativně omezené možnosti logování, sledování pouze hlaviček paketů, zneužití nedokonalosti TCP/IP protokolu a konfigurace filtrů.

Typickým představitelem paketových filtrů je ipchains, který byl součástí jádra. Od jádra verze 2.4 je nahrazen nástrojem iptables (frameworkem netfilter).

Stavové paketové filtry (Stateful packet inspection)

Stavové paketové filtry poskytují to samé jako paketové filtry a navíc umožňují ukládání informací o povolených spojeních, které lze používat při rozhodování o budoucnosti paketů. Dochází ke zvýšení bezpečnosti, protože lze nastavit, která komunikující strana může otevřít spojení a firewall bude povolovat i pakety jdoucí z druhé strany jako odpovědi na požadavky (request <-> response).

Mezi výhody patří stejně jako u paketových filtrů rychlost zpracování požadavků a současně lepší možnost zabezpečení, než u paketových filtrů. Další výhodou je poměrně jednoduchá konfigurace minimalizující škody způsobené například překrýváním některých pravidel a kontrola stavu spojení.

Nevýhodou je nižší úroveň zabezpečení, než poskytují aplikační brány a o něco náročnější režie oproti paketovým filtrům (musí se udržovat informace o spojeních a kontrolovat souvislosti).

Typickým představitelem je iptables v linuxovém jádře.

Stavové paketové filtry s kontrolou protokolů a IDS

Moderní stavové paketové filtry kromě informací o stavu spojení a schopnosti dynamicky otevírat porty pro různá řídící a datová spojení složitějších známých protokolů implementují něco, co se v marketingové terminologii různých společností nazývá nejčastěji Deep Inspection nebo Application Intelligence. Znamená to, že firewally jsou schopny kontrolovat procházející spojení až na úroveň korektnosti procházejících dat známých protokolů i aplikací.

Nejnověji se do firewallů integrují tzv. in-line IDS (Intrusion Detection Systems – systémy pro detekci útoků). Tyto systémy pracují podobně jako antiviry a pomocí databáze signatur a heuristické analýzy jsou schopny odhalit vzorce útoků i ve zdánlivě nesouvisejících pokusech o spojení, např. skenování adresního rozsahu, rozsahu portů, známé signatury útoků uvnitř povolených spojení apod.

Výhodou těchto systémů je vysoká úroveň bezpečnosti kontroly procházejících protokolů při zachování relativně snadné konfigurace, vyšší rychlost kontroly ve srovnání s aplikačními branami, nicméně je znát významné zpomalení proti stavovým paketovým filtrům.

Nevýhodou je zejména to, že z hlediska bezpečnosti designu je základním pravidlem bezpečnosti udržovat bezpečnostní systémy co nejjednodušší a nejmenší (i když aktuálním trendem je opak). Tyto typy firewallů integrují obrovské množství funkcionality a zvyšují tak pravděpodobnost, že v některé části jejich kódu bude zneužitelná chyba, která povede ke kompromitaci celého robustního systému.

Podobná funkce je k dispozici ve formě experimentálních modulů pro iptables v linuxovém jádře.

Aplikační brány (Application proxy firewall gateway)

Aplikační brána (proxy firewall, proxy server, aplikační proxy) je ochrana na aplikační vrstvě. Dochází k úplnému oddělení sítí. Spojení probíhá tak, že klient pošle proxy severu požadavek na otevření spojení s nějakou službou v jiné síti a aplikační brána toto spojení otevře. Všechna data prochází vždy přes proxy server, který rozhodne o jejich osudu. Jinými slovy, proxy server slouží jako prostředník mezi klientem v jedné síti a službou v druhé síti. Vedlejším efektem tohoto způsobu komunikace je skrytí zdrojové adresy klienta, protože jako klient vždy vystupuje aplikační brána.

Výhodou tohoto řešení je možnost kontroly obsahu přenášených paketů (např. antivirová kontrola, filtrování nevhodného obsahu, systém detekce průniků, apod.), autentizace uživatelů, možnost cachování dat, skrytí zdrojové adresy klienta (anonymizace) a četné logovací možnosti.

Proti tomuto řešení hovoří především vyšší hardwarové nároky (výkonová a paměťová náročnost) a netransparentnost (nutná úprava aplikací), kdy musí každá aplikace podporovat připojení pomocí proxy a tyto aplikace musí být správně nastaveny. Pro každou aplikaci musí být zvláštní proxy.

Tj. nejsou univerzální jako paketové filtry - HTTP proxy, FTP proxy, atp.

Pro Linux existuje mnoho proxy serverů, jedněmi z nich jsou např. Squid, FWTK nebo SOCKS.

Pro úplnost dále uvádím přehled vlastností a charakter. atributů ostatních síťových technologií.

Network Address Translation (NAT)

Překlad síťových adres slouží ke změně hlaviček paketů, kde jsou přepsány zdrojové - DNAT (Destination NAT), nebo cílové adresy - SNAT (Source NAT). Toto řešení lze použít, pokud nemáme mnoho IP adres, aby všechny počítače v síti mohly mít svou vlastní veřejnou IP adresu nebo ke zvýšení zabezpečení. Za výhodu i nevýhodu lze považovat „neviditelnost“ počítačů z vnější sítě, což vede k již zmíněnému zvýšení zabezpečení a také k omezení, protože nelze používat některé služby vyžadující inicializaci spojení serverem (řeší Port Forwarding, česky přesměrování/mapování portů). Na překladu adres je založena aplikační brána.

Analyzátory paketů (Network Packet Analyzer)

Analyzátory paketů fungují podobně jako aplikační brána, ale jsou pasivní a transparentní. Umožňují neměnnou analýzu paketů a případné reakce na podněty. Příkladem může být IDS balík Snort. Mezi výhody tedy patří pasivní kontrola přenášených dat s možností definice reakce na potenciální útok (např. zablokování příjmu paketů z podezřelé IP adresy). Nevýhodou je náročnost na systémové prostředky a fakt, že nejsou univerzální.

HW versus SW firewally

Pravděpodobně by bylo vhodné uvést i přednosti obecně fyzických řešení firewallů. Hardwarové firewally mají vůči softwarovým firewallům výhodu především v rychlosti, nezávislosti na operačním systému, jednoduchosti nasazení a správy a v méně bezpečnostních „trhlinách“. Zřejmou výhodou může být i integrace firewallu s jinými zařízeními (např. směrovači). Dražší a výkonnější HW firewally mohou rovněž podporovat i externí moduly přidávající komplementární funkce antivirové kontroly či systému detekce průniku IDS. Toto zvolené řešení má ale i své nedostatky v podobě vyšší ceny (některé SW firewally jsou poskytovány zdarma) a pružnosti/adaptace konfigurace. Pouze jako poznámku doplním, že HW firewally jsou spíše firemní záležitostí [6].

Překlad síťových adres (NAT)

Když se poprvé objevilo adresování protokolu IPv4, zdálo se, že je množství dostupných adres prakticky neomezené a že musí stačit „na věčné časy“. Teoreticky je v tomto adresovém prostoru k dispozici 232 neboli 4 294 967 296 jedinečných veřejných adres; skutečný počet dostupných adres se pohybuje někde mezi 3,2 a 3,3 miliardami, a to z důvodu rozdělení adresového prostoru do tříd (A, B, C) a vyhrazení určitých adres pro vícesměrné vysílání, testování a další speciální účely (třída D). Uvedené dělení nadefinovalo sdružení IETF (Internet Engineering Task Force), ale později se od něj upustilo, protože nebylo příliš hospodárné. Efektivním se ukázalo být tzv. podsíťování (členění na subsítě), kdy se několik prvních bitů původně určených k adresaci stanice použije na definici podsítě, zbývající bity pak adresují stanice v této podsíti. Subsíť je definována adresou třídy a síť. Maskou.

Vzhledem k obrovskému rozmachu sítě Internet a neustále rostoucí potřebě přidělování IP adres v domácích sítích a v malých firmách je zřejmé, že počet dostupných adres IPv4 zkrátka nemůže stačit. Jednoduchou úvahou dojdeme k řešení, kterým je změna schématu adresování a rozšíření adresového prostoru. Toto nové adresování je skutečně ve vývoji a nasazení, a to pod označením IPv6, ale jeho implementace potrvá ještě řadu let, protože je u ní nutné změnit činnost infrastruktury celého Internetu. Proces přechodu z dosavadní verze IPv4 na novou verzi IPv6 je proto velmi pomalý a nejspíše bude i nadále postupovat zdlouhavým tempem, protože život dosavadních adres IPv4 dále prodlužuje překladový mechanismus NAT.

Pomocí překladů síťových adres NAT mohou organizace vyřešit nedostatek veřejných IP adres ve své síti, připojené do Internetu. Sítě, které dosud nemají veřejné IP adresy, registrované u centra NIC, si je musí vyžádat od sdružení IANA (Internet Assigned Numbers Authority) a registru ARIN (American Registry for Internet Numbers), což znamená zdlouhavý úřední postup. Mnohá pracoviště dokonce těmito nepříjemnými úředními procedurami neprojdou; pro většinu sítí je tudíž řešením právě NAT.

Při zapojení překladů NAT může firma používat veřejné IP adresy na vnější straně sítě (tedy u zařízení, přímo připojených k veřejnému Internetu). Jak jsem ale naznačil, těžko bude mít stejná firma dostatek veřejných IP adres, aby je přiřadila každému serveru, osobnímu počítači, síťové tiskárně, směrovači, bezdrátovému zařízení, atd. Všechna uvedená zařízení potřebují ale pro komunikaci v protokolu TCP/IP nějakou IP adresu, a proto budeme ve vnitřní síti přiřazovat privátní IP adresy. Díky tomu mohou všechna zařízení vnitřní sítě komunikovat v protokolu TCP/IP – a to je také naším cílem. Směrem do veřejného Internetu, se již ale privátní adresy dostat nesmí, a proto musíme uvést do provozu mechanismus NAT.

Překlady síťových adres NAT (Network Address Translation) zavádíme a provozujeme na vhodném zařízení (firewallu, směrovači nebo počítači), umístěném mezi vnitřní sítí s privátními IP adresami a vnějším Internetem s veřejnými IP adresami. Zmíněné zařízení pak provádí takzvané převody neboli překlady adres z privátních na veřejné. Jedna jeho strana bývá připojena k vnitřní síti, druhá pak k Internetu nebo jiné vnější síti. Umístění mechanismu NAT v rámci vrstvené obrany dokresluje obrázek 10.

Mechanismus překladů adres NAT znamená také další úroveň zabezpečení sítě. Samotný NAT má několik různých podob a může pracovat ve třech základních režimech činností:

·        Statický NAT – definuje jednoznačné mapování neboli zobrazení privátních IP adres na veřejné (tedy jedna k jedné). To je užitečné zejména u zařízení, která musí být dostupná z veřejného Internetu (z vnější sítě). Pokud má například webový server takovouto vnitřní IP adresu (10.0.0.1) a má být dostupný z Internetu (je to veřejný webový server), musíme definovat statický překlad NAT, který zajistí trvalý a jednoznačný převod uživatelských požadavků s veřejnou adresou webového serveru na jeho vnitřní adresu 10.0.0.1. Právě pro zařízení dostupná z vnější sítě, jako jsou webové servery apod., jsou statické překlady NAT velice běžné.

·        Dynamický NAT – tento režim zajišťuje mapování privátních IP adres na veřejnou IP adresu, vybranou ze skupiny registrovaných adres. I při tomto typu překladů NAT je mezi privátními a veřejnými IP adresami jednoznačné zobrazení (jedna k jedné); má-li například náš osobní počítač privátní adresu 10.0.0.2 a kolegův počítač 10.0.0.3, dostaneme při komunikaci s veřejným Internetem přiděleny od firewallu dvě různé veřejné IP adresy (ty mohou být ovšem při každé komunikaci jiné). Dynamický NAT je bezesporu užitečný, ale na některé stanice je krátký; může se například stát, že již firewall všechny veřejné IP adresy vyčerpal a naši komunikaci tak zamítne. To může být v určitých situacích vážný problém, proto byl vyvinut takzvaný přetížený NAT.

·        Přetížený NAT – jedná se o speciální typ dynamického NAT, který převádí větší skupinu privátních IP adres na jedinou veřejnou IP adresu, přičemž je rozlišuje pomocí různých portů TCP. Uvedený mechanismus se označuje také jako překlady portů PAT (Port Address Translation), případně jednoadresový NAT. Název ale není tak podstatný jako mechanismus činnosti: pro jedinou IP adresu je totiž k dispozici více než 64 000 portů (celkem 65 535) TCP, a proto PAT umožňuje efektivní přístup k Internetu velkému množství uživatelů s privátními IP adresami. Tento poslední typ překladu NAT se používá nejčastěji, protože dokáže najednou obsloužit největší množství uživatelů.

Zvýšení bezpečnosti sítě

Vývoj překladového mechanismu NAT byl veden především snahou o vyřešení problému s nedostatkem veřejných adres protokolu IPv4. NAT poskytuje ale další vrstvu zabezpečení a ochrany sítě. Obecně se totiž dá říci, že NAT útočníkovi velmi výrazně ztěžuje:

·        Mapování topologie cílové sítě a zjišťování informací o konektivitě

·        Zjištění počtu provozovaných systémů v síti

·        Zjištění typu provozovaných počítačů a jejich operačních systémů

·        Vedení různých útoků s odepřením služeb (DoS), jako jsou například záplavy synchronizačních paketů SYN, prohledávání portů a vnášení paketů (injekce)

Zařízení uvnitř sítě LAN nejsou díky technologii překladu adres NAT adresovatelná z Internetu, což taktéž posiluje bezpečnost (útočník nezná strukturu sítě a nemůže se spojit přímo s konkrétním počítačem, lépe řečeno zařízením v síti, vždy se dostane „pouze“ na hraniční směrovač nebo počítač provádějící službu překladu adres). NAT ovšem firewall nenahrazuje a existují způsoby, jak počítače za NATem napadnout.

Překlad adres a OS Linux

Zde je uvedena příkladová situace. Uživatel vnitřní lokální sítě s IP 192.168.1.100 má přístup k Internetu a požaduje po internetovém prohlížeči webovou stránku http://www.google.cz. Internetový prohlížeč naváže TCP spojení pomocí HTTP protokolu s webovým serverem (na portu 80) a vrátí zpět uživateli požadovaný dokument, www stránku, soubor apod. Mezitím se událo (z pohledu překladu síťových adres) několik skutečností zachycených na obrázku 11.

Situace, která je symbolizována tabulkou s pořadovým číslem (1), zachycuje požadavek klienta v síti LAN na webový vyhledávací portál s doménovým názvem www.google.cz. S pořadovým číslem (2) následuje přepis zdrojové IP adresy (+ portu) SNAT tohoto požadavku, dále ve (3) kroku příchozí odpověď od serveru na požadavek klienta, a ve (4) finální fázi přepis cílové IP adresy (+ portu) DNAT.

SNAT v POSTROUTING – mění se zdrojové adresy a zdrojové porty.

DNAT v PREROUTING – mění se cílové adresy a cílové porty.

Využití je zřejmé: připojení sítí LAN k Internetu pomocí jedné veřejné IP adresy.

Pozn. Ne všechny pakety prošlé PRE/POSTROUTING projdou, musí mít pravidlo v řetězci FORWARD!

Omezení mechanismu NAT

Je zřejmé, že příchod technologie NAT do světa počítačových sítí a Internetu znamenal alespoň částečné vyřešení problémů s nedostatkem IP adres. Mnozí lidé se tudíž ptají, jestli sítě vůbec někdy přejdou na novou verzi protokolu IPv6, když překlady NAT tak výborně fungují. Otázkou ovšem fakticky není zdali, ale kdy. Asijský region dnes například v implementaci protokolu IPv6 jasně vede a mnohé sítě jej již skutečně používají.

S ohledem na stále rostoucí konektivitu a konvergenci sítí budou potřeba stále další a další IP adresy. Nakonec se tedy budeme muset k protokolu IPv6 uchýlit. Mechanismus NAT tyto nevyhnutelné změny pouze oddálil. NAT má svoje nepopiratelné výhody, ale na druhé straně má také jistá omezení:

·        Problémy s protokolem UDP – překladový mechanismus NAT sleduje a kontroluje stav spojení. V protokolu UDP ovšem nelze stav spojení nijak určit (protokol UDP je nespojovaný – spojení se v něm vůbec nevytvářejí). NAT nedokáže tudíž žádným způsobem určit, jestli určitý paket spadá do nějaké probíhající konverzace, nebo jestli tvoří izolovaný přenos dat. Zařízení s překlady NAT tak musí odhadovat, jak dlouho může konverzace UDP trvat a jak dlouho ji tedy po posledním paketu ponechat otevřenou; hovoříme o tzv. době nečinnosti. Například ve firewallech od firmy Cisco je možné nastavením doby nečinnosti tyto případy omezit.

·        Citlivé protokoly – některé protokoly skrývají, pozměňují nebo jinak zastiňují atributy paketů, které NAT potřebuje ke správnému překladu adres. Příkladem jsou protokoly Kerberos, X Window, vzdálený shell (rsh) nebo protokol SIP (Session Initiation Protocol), které mohou mít při průchodu zařízením s NAT jisté problémy. Příčina problémů se skrývá v aplikacích, jež vkládají IP adresu do paketů. Firewally Cisco mají pro různé protokoly opravné funkce (fixup), například Skinny pro telefonii (SCCP).

·        Vzájemné vlivy systémů šifrování a autentizace – mnohé systémy šifrování dat se pokoušejí zajistit integritu paketů a kontrolují tak jejich neporušenost při přenosu. Překladový mechanismus NAT ale z principu pakety pozměňuje, a proto šifrovací a autentizační technologie s ním často nedokáží spolupracovat.

·        Komplikovaný záznam do systémových protokolů – pokud zařízení odesílá přes překladové zařízení určité informace do systémových protokolů, musí cílové zařízení znát překlady prováděné mechanismem NAT. Dosažení souladu systémových protokolů s překlady NAT pak může být velice složité a často se těžko zajišťuje, který z interních systémů vlastně dané události zaznamenal.

Závěrem ale poznamenejme, že překladový mechanismus NAT je skutečně velmi užitečný – celé firemní síti nabízí přístup k Internetu a zároveň tvoří další úroveň zabezpečení. Technika NAT umožňuje komunikaci zařízení v privátní síti se zařízeními jiných sítí, sdílet jednu veřejnou IP adresu více zařízeními privátní sítě, vyrovnávat zatížení serverů poskytujících stejnou službu, v případě výpadku zajistit adekvátní náhradu serveru záložním serverem a hlavně (z hlediska bezpečnosti) skrýt před vnějším útočníkem strukturu vnitřní sítě. Tímto disponují i proxy servery, probírané v další kapitole, jež pracují na nejvyšší aplikační vrstvě. Dokáží navíc zabránit prozrazení některých důležitých informací o hostitelské stanici, jako např. typ OS, www prohlížeč, interní IP adresa a další. Vzdálený server se tak o klientu dozví minimum informací (je odkázán pouze na informace zpřístupněné proxy serverem), což umožňuje určitý (pokročilejší) stupeň anonymizace.

Proxy servery

Jak proxy servery fungují

Přímá komunikace mezi klientem a WWW serverem pomocí HTTP protokolu je nejběžnější způsob získávání informací z WWW. V některých případech je však tato forma komunikace zprostředkována pomocí prostředníka – proxy serveru. Proxy server je zpravidla program (běžící na serveru organizace), který pracuje současně jako klient i server, schematické znázornění funkce je možné nalézt na obrázku 12. V obrázku je záměrně opomenuto DNS zjišťování IP adresy hostitele, které probíhá jak na straně klienta (hledání IP proxy serveru), tak na straně proxy serveru (hledání cílové IP webového serveru).

Podstatnou vlastností je, že proxy server tím, že vystupuje za klienta, poskytuje anonymitu uživatele vzhledem k www serveru.

Jak již bylo nastíněno, proxy server je server počítačové sítě, který umožňuje klientům nepřímé připojení k jinému serveru. Proxy server funguje jako prostředník/zprostředkovatel mezi klientem a cílovým serverem, překládá klientské požadavky a vůči cílovému serveru vystupuje jako klient. Přijatý požadavek následně odesílá zpět na klienta. Může se jednat jak o specializovaný hardware, tak o software běžící například na počítači klienta.

Aplikační proxy server je server speciálně určený pro určitý protokol resp. aplikaci. Za pomocí něj lze analyzovat obsah komunikace, případně ji pozměňovat (např. odstraňování reklamních bannerů z HTTP požadavků, blokování webových stránek podle obsahu, zákaz přístupu na nepovolené webové servery apod.).

Stručný popis jednotlivých kroků:

(1) Uživatel chce zobrazit určitou stránku na internetu, např.: http://www.server.cz/stranka.htm, což se předá nižším vrstvám k přenosu. Stručný popis jednotlivých kroků [18]:

(2) Nižší vrstvy navážou spojení se serverovou částí proxy serveru a předají požadavek prohlížeče (HTTP metoda GET).

(3) Proxy server rozumí struktuře HTTP protokolu a proto je schopen detailně vyhodnotit požadavek. Na základě vlastní logiky může proxy tento požadavek přepsat a de facto tak např. změnit cílový server, z kterého se bude stránka získávat. Dále může ověřovat, zda je vůbec uživatel oprávněn takový požadavek provést. Další netriviální činností, kterou může proxy provádět, je ukládání odpovědí do své cache paměti a při opakování dotazu na stejnou stránku tak zajistit rychlejší odezvu. Tato činnost však mírně ztrácí význam v souvislosti s rozvojem dynamicky generovaných stránek. Komplexnější proxy dokáže na základě spolupráce s firewallem případně antivirovým programem účinně filtrovat provoz a chránit tak uživatele. Pokud proxy nenajde ve své paměti požadovanou stránku a uživatel je oprávněn, předá se požadavek klientské části proxy.

(4) Klientská část zajistí navázání spojení s www serverem a předání metody (GET /stranka.htm).

(5) WWW server přijme požadavek a vyhodnotí ho.

(6) Výsledkem je odpověď WWW serveru, zpravidla požadovaná stránka.

(7) Na základě nižších vrstev je odpověď předána zdroji metody GET, což je v tomto případě klientská část proxy serveru.

(8) Stejné operace jako v bodě 3), jen zpětně. Např. přepsání odpovědi do formy v jaké ji očekává uživatel, případně zápis stránky do cache paměti.

(9) Odpověď se pomocí nižších vrstev předá uživateli (původní tazatel).

(10) Prohlížeč odpověď zpracuje a stránku zobrazí.

Jak je patrné z předcházejícího textu, proxy rozumí aplikačnímu protokolu (HTTP) a je schopno samo navazovat spojení, což jsou nejmarkantnější rozdíly např. od techniky překladu síťových adres (NAT). Umístění proxy serveru v rámci sítě není pevně dáno. Nejčastějším použitím je oddělení vnitřní sítě a Internetu, takže proxy server je umístěn na pomezí těchto dvou oblastí (viz obrázek 13). K proxy serveru se však lze připojovat i za hranice vnitřní sítě (do Internetu). V takovém případě se jedná o veřejné (public) proxy servery, kterých existuje velké množství, avšak jejich důvěryhodnost je často pochybná, protože do souhrnu (ne)žádoucích činností, které provádí, nemáme možnost nahlédnout.

V textu je pojednáno pouze o variantě proxy pracující s HTTP protokolem (nejčastější), proxy server však zpravidla podporuje i další typy, jako např. FTP protokol atp

Oddělení sítí – bezpečnost

V lokálních sítích se často používají privátní adresy (např. 10.0.0.0/8, 192.168.0.0/16), takže počítače nemohou komunikovat (resp. přistupovat) přímo do Internetu. Používá se buď technika překladu adres na firewallu (NAT), nebo řešení pomocí proxy serveru. Klient používá proxy server na své vlastní privátní síti (má privátní IP adresu) a ten komunikuje (nejčastěji pomocí jiného síťového připojení) s Internetem (tedy vnější sítí). Nutno poznamenat, že pro některé sítě je použití přístupu pomocí proxy serveru jedinou možností přístupu na Internet.

Výhodou použití proxy serveru z hlediska bezpečnosti je:

·        Možno ho použít pro přístup k (určitým službám) Internetu i v případě, že klienti používají privátní adresy (netřeba použít NAT).

·        Možno ho použít jen pro přístup k těm službám, které podporuje proxy server.

·        Klient se připojuje na (lokální) proxy server a ne přímo na vzdálený server – nekomunikuje přímo s vnější sítí, čímž se dosahuje vyšší bezpečnosti, neboť je nemožné zneužít probíhající spojení na útok směřující ze serveru na klienta.

Existují nejméně tyto tři zmíněné důvody, proč nasadit proxy server v praxi. Přirozeně, řešení má i své nevýhody či nedostatky:

·        Možno ho použít jen na přístup k těm síťovým službám, které podporuje samotný proxy server (toto je výhoda i nevýhoda zároveň, záleží na úhlu pohledu).

·        V případě použití aplikačního proxy serveru, zpracování aplikační vrstvy modelu OSI (běžné síťové protokoly založené na TCP) zanáší do komunikace jisté zpoždění – proxy server musí analyzovat nejvyšší vrstvu modelu OSI.

Obecné doporučení:

V případě užití proxy serveru, vzdálený server nekomunikuje přímo s klientem, takže nemůže proti němu podniknout útok, může však zneužít spojení se samotným proxy serverem. Tento proxy server je třeba proto co nejlépe zabezpečit (pomocí firewallu):

·        Proxy server nepotřebuje přijímat spojení z vnější sítě, pouze odpovědi na už vytvořené spojení (stavový filtr v IPTABLES: ESTABLISHED).

·        Proxy server se nepotřebuje připojovat do vnitřní sítě, posílá pouze odpovědi na už vytvořené spojení (stavový filtr v IPTABLES: ESTABLISHED).

·        Proxy server by měl „poslouchat“ jen na portech, které jsou nevyhnutelné pro správný provoz dané služby (služeb).

·        Proxy server by v ideálním případě neměl poskytovat žádné jiné služby (WWW, FTP, MAIL, aj.); důvodů existuje několik, mezi hlavní patří bezpečnostní hledisko (možné zneužití poskytovaných služeb a následné získání vyšších práv - root) a rozprostření zátěže mezi více serverů (přičemž každý server plní svou funkci => při pádu jednoho stále fungují ostatní).

Řízení přístupu

Jestliže zabezpečíme, že všechny klientské počítače v síti budou používat proxy server, stane se jediným „úzkým hrdlem“ komunikace mezi klientem a serverem. Vznikne tak místo v síti, kde je možné pomocí stanovených pravidel regulovat přístup k Internetu.

Výhody použití proxy serveru:

·        Možnost nasazení a vynucování bezpečnostní politiky z hlediska přístupu k Internetu – např. k určitým nevhodným či nebezpečným webovým stránkám.

·        Jednoduché nastavení bez nutnosti konfigurovat politiky na všech klientech.

Nevýhody použití proxy serveru:

·        Výkon proxy serveru má vliv na rychlost a efektivitu přenosu (čas odezvy na požadavek)

·        Vzniká rizikové místo v síti („single point of failure“), v případě výpadku proxy serveru je nemožné se dostat na Internet (či obecně do vnější/WAN sítě). Toto lze řešit pomocí vícenásobného množství proxy serverů v clusteru, ale jen v případě, že je možné si to dovolit.

Druhy proxy serverů

Jak už jsem v předešlém poznamenal, proxy je síťová brána, obecně nejen pro HTTP protokol. Většinou umožňuje cachování dat, kontrolu přístupu, filtrování obsahu a některé další služby.

V zásadě rozlišujeme dva druhy proxy serverů:

1.      Aplikační proxy servery – jsou navrhnuté jen pro vybrané síťové služby, jako např. HTTP, HTTPS, FTP, apod. Výhodou je, že nastavování a konfigurace klienta nejsou složité, stačí uvést adresu proxy serveru a jeho port. V zásadě rozlišujeme dva druhy proxy serverů:

2.      SOCKS proxy servery – fungují pro libovolné služby za předpokladu, že aplikace podporuje tento typ proxy serveru (musí být speciálně upravená).

Další eventuální rozdělení je taktéž na forward proxy a reverse proxy. Záleží, zda jde o caching či balancing – umístění před klientem nebo serverem.

Forward (dopředná) proxy – klasická síťová brána s možností cachování, umístěna blíže ke klientovi. Typická je speciální konfigurace klienta (nemusí být vždy pravda).

Vlastnosti: urychlení síťového provozu, snížení datového toku, bezpečnost (lze doplnit o antivir aj.).

Podrobnější rozčlenění dopředné proxy může být na klasickou proxy a transparentní proxy.

Reverse (zpětná) proxy – je transparentní z pohledu klienta, umístěna před serverem. Výhodou je možnost balancingu (rozložení požadavků na více strojů). Klient nevyžaduje speciální konfiguraci.

Vlastnosti: urychlení síťového provozu (některé požadavky lze vyřídit z cache paměti, eliminace prodlevy ve spojení mezi klientem a serverem, mezi klientem a proxy může probíhat SSL spojení, vlastní server se tak může věnovat vyřizování skutečných požadavků), rozložení zátěže na více serverů, zvýšená bezpečnost (klienti se připojují k proxy, ne k samotnému serveru).

Reverzní proxy server někdy také slouží k šifrování/dešifrování spojení. Nedochází tím k degradaci potřebného výpočetního výkonu serverů. Zajištěno je šifrování směrem ke klientovi, spojení mezi serverem a proxy šifrované není, ale tato oblast se považuje za bezpečnou (součást např. DMZ).

Klasická proxy

Klasická proxy se používá zejména pro protokoly Telnet, FTP, HTTP a HTTPS. Například při použití Telnetu se uživatel nejdříve připojí na proxy, kde zadá příkaz connect, ve kterém určí název nebo IP adresu skutečného serveru. Klientská část proxy naváže spojení s cílovým serverem a začne předávat mezi klientem a tímto serverem data. Klientovi se pak jeví, jako by mezi ním a cílovým serverem žádná proxy nebyla.

Generická proxy

Někteří klienti nemohou nebo nechtějí vést úvodní dialog s proxy, aby jí sdělili cílový server. Generická proxy je program, který může spouštět a konfigurovat správce sítě podle momentálních požadavků. Dokáže pracovat s TCP i UDP.

Serverová část proxy je spuštěná na konkrétním portu, který určil správce, a je připravena přijímat požadavky od klientů ve vnitřní síti. Klientská část proxy je pevně nastavena na jeden cílový server.

Jedna spuštěná generická proxy dokáže obsloužit jeden cílový server. Naráz jích pochopitelně může být spuštěných více. Generické proxy se používají hlavně pro protokoly POP3, IMAP4, SSH, LDAP, SMTP a NNTP.

Transparentní proxy

Klient naváže spojení s transparentní proxy a má pocit, že navázal spojení se skutečným serverem. Klientská část transparentní proxy hned navazuje spojení s cílovým serverem. Transparentní proxy nemusí vést s klientem žádný dialog.

Předpoklady pro práci transparentní proxy jsou:

·        Klient ve vnitřní síti má možnost přeložit jméno cílového serveru nebo počítače v Internetu na IP adresu. Cílová adresa IP datagramu je adresa cílového serveru.

·        IP datagram odeslaný do Internetu musí projít přes transparentní proxy.

·        IP datagramy jednoho spojení musí procházet přes jednu transparentní proxy. Může existovat více transparentních proxy najednou.

Používá se především pro protokoly HTTP, HTTPS, FTP, NNTP, IMAP, POP3 a Telnet.

Reverzní proxy

Reverzní proxy využívají jinou technologii proxy serverů. Můžeme je využít vně firewallu, kde reprezentují bezpečný obsahový server určený pro vnější klienty a zabraňují přímému, nesledovanému přístupu k datům na vnitřních serverech z vnější sítě. Reverzní proxy také urychlují činnost sítě, protože před silně vytížený server můžeme umístit i několik proxy serverů a zátěž mezi nimi vyrovnávat. Dopřednou a reverzní aplikaci může zajišťovat stejný proxy server.

Je patrné, že složitý obvod sítě s různými proxy servery, tunely a paketovými filtry, které pracují v obou směrech, se může velmi rychle zkomplikovat a znepřehlednit. V diagramech propojení sítě je proto vhodné zavést si jednoduchou konvenci a každý z typů serverů označit např. následovně:

·        C Client (Klient) – systém, který vyžaduje určitou službu

·        S Server – systém s požadovanou internetovou službou

·        L Listener (Posluchač) – vnitřní strana proxy serveru, která očekává spojení od klientů

·        I Iniciátor – vnější strana proxy serveru, která navazuje spojení s vlastním serverem

SOCKS

SOCKS je souprava proxy nástrojů, která umožňuje zprostředkovanou proxy komunikaci aplikací bez nutnosti vytváření zvláštních proxy modulů. Hostitel na jedné straně serveru SOCKS může přistupovat k hostitelům na druhé straně serveru bez potřeby přímé konektivity IP. Server SOCKS přesměruje spojení i požadavky služeb mezi hostiteli; zajišťuje přitom autentizaci a autorizaci požadavků, zavádí zprostředkované proxy spojení a přeposílá data mezi oběma propojenými hostiteli.

Program SOCKS má dva samostatné konfigurační soubory. První definuje povolené typy přístupu a druhý směruje požadavky služeb na odpovídající proxy server. Dále je zde možné identifikovat IP adresy a uživatele pro filtrování.

Aplikace, které mají s proxy serverem SOCKS spolupracovat, musí být zvlášť upravené. Pro každou z podporovaných služeb jsou potřeba hned dvě aplikace – například dva různé programy Telnet, z nichž jeden zajišťuje přímou komunikaci a druhý komunikaci přes proxy server SOCKS. Instrukce pro nezbytné úpravy najdeme přímo u serveru SOCKS. Určité úpravy jsou potřebné v každé aplikaci; klientský software pak komunikuje přes server SOCKS. Celý SOCKS se skládá ze dvou součástí, a sice ze serveru SOCKS a klienta SOCKS. Server SOCKS je implementován na aplikační úrovni, zatímco klient SOCKS pracuje mezi aplikační a transportní vrstvou.

Cache pro obsah (WWW)

Některé typy aplikačních proxy serverů (např. HTTP proxy) mohou disponovat cache pamětí, ve které se určitý čas uchovávají odpovědi vzdálených serverů a obsah této paměti je k dispozici pro další požadavky. Jestliže proxy server najde požadovanou odpověď v cache paměti, může odpovědět klientovi rychleji, než kdyby musel odpověď znovu získat. To je výhodné zejména v případě, že připojení na Internet není velmi rychlé, zatímco přenosová rychlost lokálních sítí dnes běžně dosahuje 100 Mbit/s i více.

Mohlo by se zdát, že hlavní výhodou je tedy kratší čas odezvy na požadavky klienta, což je i pravda, ale pouze v případě, že se hledaná odpověď nachází v cache paměti proxy serveru. Její velikost je totiž vždy omezená (kromě fyzické paměti se používá i pevný disk). Aby se do cache mohly ukládat stále nové údaje, musí se z ní něco odstranit. Na to existuje několik algoritmů, např. odstraní se nejméně používané údaje. Nejrychlejší odezvy na klientský požadavek lze dosáhnout pomocí proxy serveru tehdy, jestliže bude v případě HTTP proxy přistupováno na nejčastěji využívané stránky.

Výhoda použití proxy serveru je tedy, kromě již zmíněné bezpečnosti, zmenšení času odezvy (subjektivně „rychlejší načítání“) pro nejčastější požadavky nacházející se v cache paměti. Nevýhody lze zmínit dvě. První spočívá v omezené velikosti cache paměti a druhá v limitu na minimální a maximální velikost cachovaného objektu. Může se stát, že stránky, které je potřeba uchovávat v paměti, nevyhoví zmíněným limitním požadavkům, a bude tedy nutností je vždy získat z webového serveru. Pro lepší představu, jak funguje cachující proxy server pro WWW stránky, vyzdvihnu následující orientační model. Požadavkem je URL adresa, kterou klient požaduje od HTTP proxy.

Nachází se webová stránka v cache paměti?

Ø ANO – Je odpověď stále ještě platná? (Pozn. zjišťuje se například čas poslední modifikace stránky)

·        Ano – Proxy server vrátí stránku ze svojí cache paměti.

·        Ne – Proxy server aktualizuje kopii stránky v cache paměti a vrátí jí klientovi.

Ø NE – Proxy server se pokusí stáhnout webovou stránku z cílového serveru. Podařilo se stránku získat?

·        Ano – Vyhovuje stránka kritériím pro uložení (velikost, typ, direktivy pro proxy server, apod.)?

o   Ano – Proxy server uloží stránku do cache paměti a vrátí jí klientovi.

o   Ne – Proxy server vrátí stránku klientovi bez uložení v cache paměti.

·        Ne – Proxy server vrátí klientovi hlášení o chybě.

Proxy servery s cache pamětí se používají téměř výhradně na uchovávání obsahu WWW stránek.

Linuxový proxy firewall

Platforma Linux

Proč Linux?

Linux od počátku patřil mezi často nasazované operační systémy na servery. Toto řešení v sobě přinášelo (kromě jiného) spolehlivost, stabilitu, bezpečnost, konfigurovatelnost, efektivnost a ve většině případů může být i zdarma. Pro náš proxy server spolu s firewallem je operační systém GNU/Linux ideálním východiskem. Veškeré aplikace, které zde budou později uváděny a které budou vhodně zvoleny pro projekt (s ohledem na dostupnost, bezpečnost řešení, konfigurovatelnost, apod.), budou tzv. open source.

Open source nebo také open-source software (OSS) je počítačový software s otevřeným zdrojovým kódem. Otevřenost zde znamená jak technickou dostupnost kódu, tak legální dostupnost – licenci software, která umožňuje, při dodržení jistých podmínek, uživatelům zdrojový kód využívat, například prohlížet a upravovat. V užším smyslu se OSS míní software s licencí vyhovující definici prosazované Open Source Initiative (OSI). Pro odlišení se někdy open source software vyhovující požadavkům OSI označuje Open Source.

V nepřesném, ale poměrně běžném vyjadřování se označení open source používá i pro mnoho vlastností, které s otevřeností zdrojového kódu nesouvisí, ale vyskytují se u mnoha open source programů. Například může jít o bezplatnou dostupnost software, vývoj zajišťovaný úplně nebo z podstatné části dobrovolnickou komunitou nebo „nekomerčnost“.

Bezpečnost open source

Z hlediska bezpečnostních děr v software je otevřenost kódu dvojsečná zbraň. Chyby v programech může hledat mnohem širší skupina lidí (nebo i automatických pomůcek) a je proto naděje, že se snáze opraví. Na druhou stranu zranitelnosti mohou snáze najít i útočníci. V současném paradigmatu informační bezpečnosti full disclosure se ovšem považuje za obecně výhodnější, když jsou informace dostupné všem, i za tu cenu, že jsou dostupné útočníkům. Alespoň u populárních programů s velkou základnou uživatelů a vývojářů lze předpokládat, že „uživatelská“ strana má výrazně větší prostředky (především více času kvalifikovaných lidí) než potenciální útočník.

Nespornou výhodou otevřeného zdrojového kódu je ohromné ztížení možnosti propašování zadních vrátek a trojských koní.

Kterou distribuci Linuxu zvolit?

Protože praktickým cílem této diplomové práce je navrhnout, nakonfigurovat a zprovoznit funkční proxy firewall na platformě GNU/Linux, je třeba příslušnou konkrétní distribuci tohoto OS zvolit. S ohledem na bezpečnost, stabilitu a spolehlivost (v neposlední řadě také dlouhodobou prověřenost administrátory serverů) byla zvolena distribuce s plným označením Debian GNU/Linux verze 4.0r5 (později upgradováno na stabilní verzi 5.0, čili z Etch na Lenny), která je schopna plnohodnotného serverového nasazení, a která velice dobře splňuje požadavky serverového řešení proxy firewallu.

Debian GNU/Linux

Na úvod stručně charakterizuji vybranou distribuci operačního systému Linux, která je v tomto případě Debian (s verzí jádra 2.6.26).

Co je Debian?

Debian je svobodný operační systém určený k provozu na mnoha různých typech počítačů. Operační systém se skládá ze základního programového vybavení a dalších nástrojů, kterých je k provozu počítače třeba. Vlastním základem systému je jádro. Jelikož Debian používá jádro Linux a většina základních systémových programů byla vytvořena v rámci projektu GNU, nese systém plné označení GNU/Linux.

Debian nezávisí na konkrétním jádře. Momentálně používá jádro Linux, které je svobodným softwarem, jehož vývoj byl zahájen Linusem Torvaldsem a je nyní podporováno více než tisíci programátory z celého světa (dobrovolníky i profesionály). Pracuje se na úpravě Debianu i pro jiná jádra, obzvláště Hurd. Hurd je kolekce serverů běžících nad mikrojádrem (např. Mach nebo L4).

Tato distribuce je známa především svou konzervativností. Přesto je to jedna z nejrozšířenějších linuxových distribucí na světě. Oproti klasickým „komerčním distribucím“, jako jsou Red Hat nebo SUSE, nepoužívá balíčkovací systém postavený na RPM (RPM Package Manager, dříve Red Hat Package Manager), ale má vlastní balíčkovací systém tzv. deb-balíčků, který je velmi propracovaný a umožňuje velmi jednoduše provádět správu balíčků z různých zdrojů. Nazývá se Advanced Packaging Tool (APT).

Debian GNU/Linux 4.0 je zatím poslední stabilní verzí distribuce. Tato verze vyšla v dubnu roku 2007 a obsahuje zhruba 18040 balíků (předkompilovaného softwaru zabaleného do formátu umožňujícího snadnou instalaci na každém počítači) svobodného softwaru. Tento software je k dispozici pro všechny podporované architektury.

Debian se ve své společenské smlouvě zavázal, že bude založen na svobodném softwaru a sám vždy svobodným softwarem zůstane. To je velmi podstatný rys této distribuce. Znamená to významnou záruku pro její uživatele – mohou se pro Debian rozhodnout a začít na něm stavět s jistotou, že základní komponenta bude vždy uživateli poskytovat jeho svobody.

Debian a serverové nasazení

Poznámka:

Už při samotné instalaci Debianu se instalační proces zabýval informacemi týkajícími se zadáním proxy ve standardním tvaru Poznámka: http://[[uživatel][:heslo]@]počítač[:port]/ (Pokud pro přístup k okolnímu světu používáte HTTP proxy, zadejte zde potřebné informace. V opačném případě nic nevyplňujte.).

Konfigurace sítě

Jak je uvedeno v tabulce 1, nastavení sítě se u distribuce Debian provádí zpravidla v souborech /etc/hostname a /etc/network/interfaces, nápomocen je i soubor options v adresáři /etc/network.

Jméno hostitele se nastavuje v souboru /etc/hostname. Jméno v tomto souboru by mělo být plně kvalifikované, protože jeho hodnota se používá i v jiných kontextech. Standardní instalace Debianu zde zanechává nekvalifikované jméno. Adresa IP, síťová maska a implicitní brána se nastavují v souboru /etc/network/interfaces.

Například:

iface lo inet loopback

iface eth0 inet static

address 192.168.1.100

netmask 255.255.255.0

gateway 192.168.1.1

Příkazy ifup a ifdown čtou tento soubor a zapínají nebo vypínají rozhraní voláním nízkoúrovňových příkazů, jako je např. příkaz ifconfig, se správnými parametry. Základní formát souboru interfaces obsahuje řádek začínající slovem iface pro každé rozhraní, a pak následují odsazené řádky specifikující další parametry.

Klíčové slovo inet na řádku iface je rodina adres. Klíčovým slovem static se nazývá metoda, která udává, že pro rozhraní eth0 bude adresa IP a síťová maska přiřazena přímo. Řádky address a netmask jsou pro statické konfigurace povinné; starší verze Linuxu vyžadovaly i zadání síťové adresy (dnes už běžně probíhá výpočet síťové adresy z adresy IP a síťové masky). Řádek gateway udává adresu implicitní brány a používá se pro určení výchozího směru.

Soubor options dovoluje nastavení některých síťových proměnných v době spuštění systému. Debian nastavuje defaultně předávání adres na vypnuto, ochranu před předstíráním cizí identity na zapnuto a syn cookies na vypnuto.

DHCP server

Protokol DHCP (Dynamic Host Configuration Protocol) se používá ke konfiguraci klíčových síťových parametrů jednotlivých klientů. DHCP protokol umožňuje prostřednictvím jediného DHCP serveru nastavit všem stanicím sadu parametrů nutných pro komunikaci v sítích používajících rodinu protokolů TCP/IP včetně parametrů doplňujících a uživatelsky definovaných.

Významným způsobem tak zjednodušuje a centralizuje správu počítačové sítě (například při přidávání nových stanic, hromadné změně parametrů nebo pro skrytí technických detailů před uživateli). DHCP servery mohou být sdruženy do skupin, aby bylo přidělování adres odolné vůči výpadkům. Pokud klient některým parametrům nerozumí, ignoruje je.

Protože se DHCP využívá hojně i v jiných systémech, pokusím se nakonfigurovat takový server pro spolupráci s okolím. Klient přihlášený do sítě tak automaticky získá potřebné parametry, jako je např. IP adresa zařízení, maska sítě, brána (případně DNS servery), z linuxového DHCP serveru stroje Debianu. Oproti „pevnému“ manuálnímu přidělování adres nabízí DHCP server několik výhod spočívajících ve výrazně nižší náročnosti administrace (vše stačí nastavit pouze na serveru, není třeba konfigurovat jednotlivé stanice) a eliminace mnoha potenciálních chyb (např. přidělení téže IP adresy dvěma různým stanicím, chybné nastavení výchozí brány na některé stanici apod.).

Princip činnosti

Klienti žádají DHCP server o IP adresu. DHCP server eviduje u každého klienta půjčenou IP adresu a čas, do kdy ji klient smí používat (doba zapůjčení, ang. lease time). Poté co vyprší, smí server adresu přidělovat jiným klientům. Klient komunikuje na UDP portu 68, server naslouchá na UDP portu 67.

Po připojení do sítě klient vyšle broadcastem (všesměrově) DHCPDISCOVER paket. Na ten odpoví DHCP server paketem DHCPOFFER s nabídkou IP adresy. Klient si z (teoreticky několika) nabídek vybere jednu IP adresu a o tu požádá paketem DHCPREQUEST. Server mu ji vzápětí potvrdí odpovědí DHCPACK. Jakmile klient obdrží DHCPACK, může již IP adresu a zbylá nastavení používat.

Klient musí před uplynutím doby zapůjčení z DHCPACK obnovit svou IP adresu. Pokud lhůta uplyne, aniž by dostal nové potvrzení, musí klient IP adresu přestat používat.

Server

Nastavení konfiguračního souboru /etc/dhcp3/dhcpd.conf:

subnet 192.168.2.0 netmask 255.255.255.0 {

range 192.168.2.1 192.168.2.50; //definuje rozsah přidělitelných adres

default-lease-time 3600; //implicitní doba platnosti IP [s]

max-lease-time 7200; //max. doba platnosti IP, 86400s = 24h

option subnet-mask 255.255.255.0; //definuje masku podsítě

option broadcast-address 192.168.2.255; //všesměrová adresa

option routers 192.168.2.100; //adresa směrovače (eth1 rozhraní)

option domain-name-servers 212.24.128.8, 82.113.57.2; //DNS servery }

Ukázka konfigurace DHCP na Linuxu. Máme nastavený rozsah IP adres 192.168.2.1 až 192.168.2.50, kde bude náš DHCP server operovat. Mezi hlavní nastavení můžeme přidat jméno časového serveru, jméno DNS serveru či WINS serveru, atp.

Podrobnější informace o serverem DHCP přidělených IP adresách klientů lze zjistit v souboru /var/lib/dhcpd3/dhcpd.leases.

Klient

Instalace DHCP klientů je na každém systému odlišná. V Linuxu stačí nainstalovat příslušný balíček DHCP Client Daemon a nakonfigurovat síť na DHCP. V operačním systému Windows je třeba otevřít okno Síťová připojení a v Konfigurace sítě („Protokol sítě Internet - TCP/IP“) taktéž nastavit získávání IP adresy z DHCP serveru automaticky. Po dalším restartu už bude síť aktivní.

DNS

DHCP klient může (ale nemusí - tak se chová implicitně i dhcpcd) se svou zprávou zaslat svoje jméno a doménu. DHCP si tuto informaci uloží do dhcpd.leases. Tohoto se využívá ve spojení s DNS serverem. Není totiž problém získat z dhcpd.leases tyto informace a poslat DNS serveru zprávu, aby si upravil svoje tabulky. Pokud se tak bude dít pravidelně (například z cronu), každý počítač, jehož DHCP klient pošle serveru svoje jméno, dostane relevantní DNS záznam (včetně reverzního).

Startovací skripty

Do startovacích skriptů se v rámci praktické části práce umístí skript firewall-iptables.sh, což zajistí automatickou aplikaci pravidel navrženého firewallu při (re)startu systému. Proto se zde krátce zmíním o informacích týkajících se startovních skriptů Debianu (spuštění daemonů a síťových služeb).

V každé úrovni běhu init spouští skript /etc/init.d/rc, a jako argument předává novou úroveň. Každý skript odpovídá za nalezení svých vlastních konfiguračních informací, které mohou být ve formě jiných souborů v adresáři /etc, v podadresáři uvnitř adresáře /etc nebo někde ve skriptu samotném.

Když hledáme název hostitele, je uložen v souboru /etc/hostname, který je načítán do skriptu /etc/init.d/hostname.sh. Síťové rozhraní a parametry implicitní brány jsou uloženy v souboru /etc/network/interfaces, které čte příkaz ifup volaný ze skriptu /etc/init.d/networking. Některá nastavení sítě mohou být uložena i v souboru /etc/network/options.

Webový prohlížeč a používané programy (aplikace, služby) Debianu

Jelikož se v práci často pracuje s webovým prohlížečem (např. v souvislosti s omezováním přístupu na vymezené internetové stránky – regulace zdrojů Internetu, nebo virová kontrola webového provozu tzv. „on-fly“), stručně představím implicitní prohlížeč Debianu, kterým je IceWeasel. Tento prohlížeč je odnoží webového prohlížeče Mozilla Firefox. Je součástí stabilní verze Debianu od verze 4.0 a snahou je synchronizace kódu s Firefoxem. Veškeré testování, ladění a zkoušení proxy serveru na stroji s Debianem probíhalo právě v tomto svobodném prohlížeči.

O HTTP proxy Squid bude detailně pojednáváno v dalších kapitolách práce. Obrázky zachycující práci s webovým rozhraním Webmin jsou součástí přílohy CD diplomové práce. Vstup do tohoto rozhraní je umožněn prostřednictvím internetového prohlížeče zadáním adresy https://stroj-s-proxy:10000/.

Operační systém jako firewall

Linux a Iptables

Důležitým doplňkem jádra operačního systému Linux je funkce filtrování paketů a překládání adres (NAT) v samotném operačním systému. Tato funkce se původně nazývala IP Masquerade kvůli své schopnosti překládání adres. Nyní se označuje jako Ipchains nebo Iptables (v závislosti na použité verzi), protože umožňuje správci vytvořit řetězce nebo tabulky pravidel, které musí splňovat paket doručený do systému Linux, směrovaný v rámci počítače na jiný adaptér nebo odesílaný z počítače do jiné sítě . Dnes se již v distribucích Linuxu setkáváme výhradně s Iptables.

Služba Iptables zajišťuje překládání adres (NAT) a filtrování paketů. Inspekci protokolu musí poskytovat služba na vyšší vrstvě. Squid je vynikajícím balíčkem serveru proxy (protokolu HTTP), který velmi dobře spolupracuje se službou Iptables systému Linux.

Hlavní funkce

Linux se službou (resp. nástrojem) Iptables poskytuje následující hlavní funkce:

·        Pro každý příchozí paket, paket procházející zásobníkem směrování systému Linux a odchozí paket jsou použita pravidla filtrování. Služba Ipchains je bezstavová, zatímco služba Iptables je stavová. Jedná se o hlavní funkční rozdíl mezi nimi.

·        Lze vytvořit servery proxy pomocí filtrů obsahu specifických pro určité protokoly, které jsou poskytovány službami na vyšších vrstvách, jako např. Squid.

·        Dynamické nebo statické překládání adres (NAT) zpracovává pakety procházející zásobníkem směrování do skrytých interních sítí.

·        Zóny DMZ lze vytvořit filtrováním obsahu do externě viditelné chráněné podsítě, nebo přesměrováním virtuálních veřejných adres na chráněné hostitele s přeloženými adresami.

·        Možnosti připojení v síti VPN z firewallu na firewall a z firewallu na vzdáleného klienta jsou k dispozici jako další komponenty systému Linux, které lze bezplatně získat z Internetu.

·        Přesměrování portů je nativně poskytováno službou Iptables. • Promyšleným použitím služby Iptables spolu s linuxovým balíčkem Squid můžeme získat transparentní servery proxy, což je výhodné především z hlediska velkého počtu stanic v síti. • Linux s balíčkem FWTK také snadno zajišťuje služby reverzních serverů proxy.

·        Další balíčky upravují běžný systém protokolování syslog v systému Linux, aby mohl ukládat informace protokolování do databází a poskytoval varování např. e-mailem.

Doplňkové funkce

Linux se službou (resp. nástrojem) Iptables poskytuje následující doplňkové funkce:

·        Filtrování paketů firewallem v systému Linux je rychlé, protože běžné počítačové procesory jsou mnohem rychlejší, než procesory používané ve většině vyhrazených firewallů. Dalším důvodem je, že systém Linux nemá zdaleka takovou režii sítě, jako běžnější operační systémy pro všeobecné použití. Díky integraci do zásobníku protokolu IP systému Linux není filtr paketů zatížen režií jiných firewallů, které jsou implementovány jako programy na uživatelské úrovni. Toto řešení dokáže snadno zvládat zatížené připojení sítě LAN k Internetu, i když je povolena možnost překládání adres (NAT).

·        Konfigurace pomocí příkazového řádku vyžaduje více zkušeností se správou, ale umožňuje ukládat zásady do textových souborů a použít nástroje skriptování při dynamické správě zásad.

·        Vzdálená správa (např. protokolem SSH) umožňuje spravovat firewall z jiných počítačů v síti LAN.

·        Díky pravidlům filtrování paketů lze použít překládání adres (NAT) a přesměrování soketů, abychom přesměrovali provoz určený jistým službám (jako např. HTTP) na chráněné interní servery.

Zabezpečení

Systém Linux filtruje pakety před jejich doručením do zásobníku protokolu IP ke zpracování, což umožňuje chránit počítač před chybně formátovanými pakety a dalšími útoky na úrovni protokolu IP.

Protože systém Linux neanalyzuje datové části zpracovávaných paketů, je nutné pomocí serveru proxy zajistit, že provoz procházející určitým portem odpovídá příslušnému protokolu (například, že portem 80, prochází pouze požadavky a odpovědi protokolu HTTP).

Rozhraní

Filtrování paketů systému Linux lze spravovat příkazem iptables. Jako argumenty slouží pravidla filtru paketů, které chceme vytvořit nebo upravit. Ukázkový příklad syntaxe příkazu iptables pro příkazový řádek je uveden níže:

iptables -P INPUT DROP
iptables -A INPUT -i eth0 -s 192.168.0.1 -j ACCEPT

Uvedené dva příkazy zajistí, aby všechny pakety, které přijdou na síťové rozhraní eth0 z jiné zdrojové IP adresy než 192.168.0.1, byly zahozeny. Obdobně se sestavuje celá bezpečnostní politika firewallu.

Linux jako server v síti

Síťový server

Většinu operačních systémů (a Linux v tomto ohledu není výjimkou) lze použít mnoha různými způsoby. Linux jakožto univerzální operační systém lze použít na pracovní stanici, jako firewall a proxy server, jako router a mnoha dalšími způsoby. Linuxové systémy dnes patří mezi nejrozšířenější serverová řešení. Nabízí širokou škálu využití, a to jak pro vnitřní síť (Intranet), tak i pro vnější síť (Internet).

Linux v roli serveru

Jako server je Linux již tradičně velmi silný - řada firem na Linux plně spoléhá při zpracování elektronické pošty, sdílení souborů a tiskáren, přiřazování IP adres a spousty dalších činnostech. Pro každý ze zmíněných úkolů (a nejen pro ně) Linux nabízí nepřeberné množství open-source programů. Než se ale rozhodneme Linux v úloze serveru nasadit, měli bychom mít jasno v jeho výhodách, nevýhodách, hardwarových a softwarových nárocích.

Vlastnosti Linuxu jako serveru

Linux lze jako server nasadit v mnoha rozličných konfiguracích. Hodí se výborně jako firewall, WWW server nebo též databázový server. Výhody Linuxu jako serveru v síti jsou následující - spolehlivost, cena, licencování, bezpečnost, poměrně rozsáhlá nabídka softwaru, správa prostředků, uživatelské úpravy a nároky na hardware. Většina zmíněných výhod se vztahuje na všechny operační systémy typu UNIX, tedy např. i na Solaris nebo FreeBSD. Ve srovnání s těmito systémy je největší výhodou Linuxu hardwarová přizpůsobivost, open source licence a nízké náklady (existují ovšem i další levné open source unixové systémy). Linux má přirozeně i své nevýhody, v úloze serveru jde naštěstí pouze o nevýhody drobného rázu - vyšší nároky na správu a potenciální bezpečnostní problémy (Linux je sice imunní vůči běžným červům a virům napadajícím Windows, má však svá vlastní bezpečnostní rizika. Do linuxových serverů se často snaží dostat útočníci a úspěšnost jejich průniků není nulová. Čistě teoreticky by mělo být prolomení ochrany dobře zabezpečeného systému obtížné, někdy ale stačí zapomenout na aktualizaci jednoho balíku a systém může být najednou zranitelný).

Sečteno a podtrženo výhody Linuxu značně převažují jeho nevýhody. Vysoká stabilita a spolehlivost systému, množství dostupných programů, které jsou pro roli serveru k dispozici a nízké pořizovací náklady jsou obrovské plus. Na druhou stranu lze konstatovat, že není v mnoha ohledech schopen kvalitativně nahradit některé funkce a vlastnosti ostatních produktů. Alespoň prozatím ne.

Bezpečnost serveru v síti

Proč nás zajímá bezpečnost?

Ještě než začneme, musíme si uvědomit jednu věc. Od okamžiku, kdy připojíme počítač do sítě, je tento počítač vystaven eventuálním útokům zvenčí. Poněvadž počítač může být nejen bránou do naší sítě, ale i bránou do našeho soukromí, jistě budeme souhlasit s tím, že útokům všeobecně na počítače je třeba předcházet a jestliže je to možné, tak jim úplně zabránit.

Bohužel, účinná stoprocentní ochrana proti útočníkům neexistuje. Jelikož nechceme server úplně odpojit od Internetu, musíme se spokojit s reálnějšími metodami ochrany. Tyto metody si kladou za cíl co pokud možno nejvíce minimalizovat riziko útoku na server, jeho rychlou detekci v případě, že byl úspěšný a zejména rychlé a bezpečné zotavení se z jeho následků.

Klíčové slovo této kapitoly je bezpečnost. Bezpečnost jako taková se stanoví a řídí pomocí bezpečnostní politiky („secure policy“).

Bezpečnostní politika

Bezpečnostní politika je soubor pravidel, jejichž dodržování má zaručit počítačovou bezpečnost. Poněvadž bezpečnost je příliš důležitá na to, aby byla dobrovolná, musí být vynucována („enforced“) operačním systémem nebo speciálními aplikacemi a zařízeními, které musí být navrhnuté tak, aby se nedali obejít (proxy servery, firewally, atd.).

K tomuto si dovolím poznamenat několik věcí. Každý informační systém by měl mít stanovenu jasnou a kompletní bezpečnostní politiku, která určuje, kdo má jaká práva. Počítače na Internetu (obecně v jakékoliv jiné/cizí síti) jsou též informačními systémy, jejichž přínosná užitková hodnota je různorodá. V případě připojení na Internet je vypracování vhodné bezpečnostní politiky téměř nutností, nedojde k možnému ohrožení privátních dat a citlivých informací.

Základní poučky pro tvorbu bezpečnostní politiky:

1. To, co není explicitně povolené, musí být zakázané. Základní poučky pro tvorbu bezpečnostní politiky

2. Nedávat uživatelům a aplikacím vyšší práva, než je nezbytně nutné pro jejich činnost.

3. Nikdy se nespoléhat na jediný ochranný prostředek. Například na omezení přístupu používat nejen TCP wrapper, ale zkombinovat ho i s firewallem.

4. Pravidelně aktualizovat software a zálohovat data.

Při tvorbě bezpečnostní politiky nezapomenout zohlednit i to, že nemalá většina útoků pochází z vnitřní sítě, tedy ze sítě, kterou obyčejně chráníme proti útokům zvenku. Jestliže je prevence založená pouze na ochraně „hranice“ mezi sítěmi, kterou obyčejně zabezpečuje firewall, ve skutečnosti jsou servery stejně zranitelné - z vnitřní strany lokální sítě.

Pravděpodobně každého napadlo nejjednodušší řešení vypnout všechny služby z venkovní i vnitřní sítě, s výjimkou DNS, WWW a elektronické pošty a zakázat či přiměřeně omezit jednotlivým uživatelům provádět nepovolené operace. Přesto nastává problém s potenciálními útoky na tyto běžící služby (útoky na DNS, přesměrování WWW) při nedodržení dalších bezpečnostních opatření. Navíc, proti některým útokům se brání velice obtížně právě proto, že jde o služby, které mají být (musí) přístupné všem, např. už zmíněné WWW, DNS a elektronická pošta.

Základní princip, který v administraci serverů vyznává určité nemalé procento správců je takový, že se snažíme omezit destruktivní potenciál uživatelů bez současného drastického omezení možností využívání služeb. Pokusíme se omezit to, co je (resp. eventuálně může být) opravdu nebezpečné. Protože se nikdy nedá dosáhnout stoprocentní bezpečnosti, při zabezpečení systému se snažíme o to, abychom případnému útočníkovi co nejvíce znesnadnili práci.

Bezpečnostní slabiny

Rozlišujeme následující pojmy:

·        zranitelné místo („vulnerability“): slabina v bezpečnostním systému (aplikaci, operačním systému, apod.), která může být využitá

·        hrozba („threat“): okolnost, která má potenciál způsobit ztrátu nebo škodu

·        útok („attack“): aktivita, která využívá zranitelné místo na průnik do systému

·        ochrana („protection“): ochranné opatření, jehož úlohou je redukce slabin

Bezpečnost operačního systému

Do této kategorie bezpečnosti můžeme zahrnout ochranu na úrovni jádra operačního systému a kontrolu s použitím systémových aplikací.

Na začátek je třeba si uvědomit, že Linux, jako každý jiný operační systém, obsahuje chyby, které se dříve nebo později objeví. Linux se vyvíjí velmi rychlým tempem, takže téměř zároveň se zveřejněním chyby je již k dispozici i potřebná bezpečnostní záplata.

Každá chyba v jádře může mít katastrofální následky. Jádro totiž běží v privilegovaném režimu a nic na počítači nemá tak neomezená práva, jako právě jádro. V případě kritické chyby se lokální (a někdy i vzdálený) uživatel může stát rootem (superuživatelem). Naštěstí, tyto z bezpečnostního hlediska nebezpečné chyby se už dnes nevyskytují tak často.

Klíčové otázky:

·        Je sledován vývoj verzí jádra a jeho aktualizace v případě, že byla odhalena závažná chyba? Klíčové otázky: Ø

·        Je používán mechanismus zabezpečující vyšší ochranu na úrovni jádra operačního systému (většinou záplaty/„patche“ do jádra, např. Grsecurity, Medusa NG)?

Bezpečnost lokální sítě

V případě, že server funguje jako firewall/brána mezi Internetem a místní LAN sítí, nebo v případě plánu nasadit samostatný počítač jako firewall (doporučované), rozrůstá se bezpečnostní politika o další rozměr – neochraňujeme pouze jeden počítač, ale určitou skupinu počítačů (nacházejících se v této síti) s různými operačními systémy. Naší úlohou je zaručit relevantní bezpečnost pro lokální síť.

Klíčové otázky:

·        Omezení přístupu – je kontrolován přístup dovnitř sítě? Je používán firewall? Ideální je využít samostatný segment sítě pro veřejně přístupné služby, tzv. Demilitarizovaná zóna (DMZ). Klíčové otázky: Ø

·        Je používáno šifrování pro přenos důležitých a citlivých údajů a hesel po síti? (TLS/SSL, šifrování protokolů, které přenášejí přihlašovací jméno a heslo, např. POP3 a IMAP). Ø

·        Jakým způsobem přistupují uživatelé z vnitřní sítě k Internetu? Je aplikován proxy server? Ø

·        Je lokální síť chráněna před viry, spyware, spamem, apod. Je používán systém IDS?

Firewall

Paketové filtry na Linuxu

Paketový filtr je součástí Linuxu již od verze jádra 1.1 (1994). V těchto nejstarších verzích byl založen na ipfw převzatém ze systému BSD. Ve verzi 2.0 přibyl uživatelský nástroj ipfwadm pro nastavení filtrovacích pravidel. Ve verzi 2.2 byl rozšířen nástrojem ipchains. V dalších verzích jádra byl kód firewallu zcela přepsán a proto se ve verzích jádra 2.4 a novějších (včetně aktuální řady 2.6.X) pro nastavení filtrovacích pravidel používá nástroj iptables, který je v řadě dalším rozšířením ipfwadm a ipchains. V současné době jsou známa první fakta o firewallu nftables, jakožto nástupci iptables.

Netfilter

Základem nové implementace pro jádra 2.4 a novější je firewallový subsystém netfilter. Je součástí jádra (možno i v modulech). Jedná se o firewall, který kromě základního paketového filtru podporuje také stavové filtrování a NAT. Čili s jeho pomocí můžeme provádět paketovou a stavovou inspekci, překlad adres, využít jej k implementaci transparentního proxy, TOS, aj. Pro jeho provoz potřebujeme mít v konfiguraci jádra zapnuto alespoň (v originálních jádrech distribucí toto již zapnuto je):

·        CONFIG_PACKET

·        CONFIG_NETFILTER

·        CONFIG_IP_NF_IPTABLES

·        CONFIG_IP_NF_FILTER

Pro využití všech možností netfilteru je nutné zapnout i další volby v Networking Options -> IP: Netfilter Configuration. Za zmínku stojí také přídavné moduly, např. pro FTP → ip_conntrack_ftp a ip_nat_ftp, které řeší problém pasivního spojení zajištěním tzv. port forwardingu pro každou relaci.

Důležité je povolit volbu IP Forward, která umožňuje směrovat pakety, které nejsou určeny pro místní procesy (čili mezi dvěma síťovými rozhraními). Nastavuje se pomocí parametru jádra (viz dále).

K vytvoření linuxového firewallu typu netfilter v operačním systému Linux je potřeba:

1.      Podpora routování v jádře: Networking options -> TCP/IP networking -> IP: advanced router

2.      Při startu systému je třeba routování paketů povolit příkazem: echo "1" > /proc/sys/net/ipv4/ip_forward

3.      Podpora firewallu v jádře: Networking options -> IP: Netfilter Configuration -> vybrat všechny potřebné možnosti, základem jsou: •

·        Connection tracking (požadováno pro masq/NAT) •

·        IP tables support (požadováno pro filtering/masq/NAT) •

·        Connection state match support •

·        Packet filtering • REJECT target support •

·        Full NAT (v případě, že chceme překládat adresy) •

·        MASQUERADE target support (jestliže chceme překlad adres pomocí MASQUERADE - pro servery s pevnou IP adresou postačí NAT) •

·        REDIRECT target support (jestliže chceme přesměrování služeb, např. pro účely transparentního proxy serveru) •

·        LOG target support

4.      Nástroj "iptables" (vytváří rozhraní pro práci s firewallem)

5.      Čas na návrh, implementaci a otestování firewallu. To souvisí s vytvořením bezpečnostní politiky.

Pokud si při kompilaci jádra nejsme jistí, co budeme potřebovat, nemusíme zbytečně kompilovat vše (včetně experimentálních modulů), typicky postačí běžné jádro. Pokud budeme potřebovat něco navíc, tak využijeme moduly, nebo přikompilujeme to, co nám prozatím chybí. Jestliže vytváříme modulární jádro a komponenty netfilteru zkompilujeme jako moduly, zavedou se do paměti, jen když to bude potřebné. V případě monolitického jádra se jeho velikost mírně zvětší.

Řetězce

Netfilter má 5 základních řetězců pro filtrování a případnou další úpravu paketů (NAT). Lze nadefinovat i další vlastní a do nich přesměrovat pakety (vhodné pro přehlednost a jednoduchost pravidel, resp. zpřehlednění funkce firewallu). Základní řetězce není možné smazat.

5 základních řetězců:

·        PREROUTING

·        INPUT

·        FORWARD

·        OUTPUT

·        POSTROUTING

Systém netfilteru se skládá z několika tabulek („tables“) obsahujících tyto řetězce pravidel („chains“).

Tabulky a řetězce

·        filter - používá se na filtrování všeobecně, tedy na akce typu ACCEPT, REJECT, DROP apod. V této tabulce by nemělo docházet k úpravě paketů, provádí se zde pouze filtrování paketů v řetězcích.

o   INPUT (pakety určené pro lokální aplikace), §

o   FORWARD (pakety negenerované lokálně a neurčené pro localhost), §

o   OUTPUT (lokálně vygenerované paketu).

·        nat - v této tabulce se provádí překládání adres (NAT); prochází jí pouze první paket každého spojení, ve kterém se provádí překlad adres. Výsledek průchodu paketu tabulkou je potom aplikován na všechny ostatní pakety spojení. NAT (Network Address Translation) lze rozdělit na Source NAT (překlad zdrojových adres) a Destination NAT (překlad cílových adres); maškaráda (masquerading) je speciální případ SNAT; překládání portů (port forwarding) a transparentní proxy jsou speciální případy DNAT. NAT se provádí v řetězcích:

o   PREROUTING (pakety přicházející ze zařízení),

o   POSTROUTING (pakety odcházející na zařízení).

·        mangle - tabulka opět pro úpravu paketů - změny v hlavičkách (TTL, TOS a další), ale nikoliv NAT a „maškarádování“. Tyká se zejména řetězců PREROUTING a OUTPUT.

Iptables

Jak funguje firewall Iptables

Řízení toku paketů probíhá na síťové vrstvě na úrovni jádra. V jádru jsou uložené tabulky filter, nat, mangle a raw. Každá tabulka obsahuje řetězce pravidel, které jsou buď předdefinované, anebo uživatelsky definované. Předdefinované řetězce má každá tabulka svoje. Kromě nich si může uživatel definovat svoje vlastní řetězce pravidel, které může volat z předdefinovaných, podobně jako subrutinu v programu. Každý řetězec obsahuje seznam pravidel, která určují, jaké akce budou s pakety prováděny.

Konfigurace Iptables

Netfilter/Iptables nemají žádný konfigurační soubor v tradičním smyslu. Na konfiguraci slouží program iptables, pomocí kterého se manipuluje s pravidly jednotlivých tabulek. Firewall je tedy ovládán prostřednictvím programu iptables. Při používání programu iptables se jako parametr uvádí tabulka a řetězec pravidel, se kterými chceme pracovat, typ operace a specifikace pravidla.

Poslední, ale velmi důležitou částí pravidla je určení cílového kroku, který následuje po konečném rozhodnutí. Tento krok je určen již zmíněným parametrem -j a může být vybrán například z následujících možností:

o   DROP … paket je tiše zahozen –

o   REJECT … paket je zahozen a jeho odesilatel je o tom informován chybovým hlášením –

o   ACCEPT … paket volně prochází/pokračuje přes iptables –

o   LOG … existence paketu je zaznamenána daemonem syslogd, toto pravidlo není definitivní a paket pokračuje v cestě řetězcem

Akcí je samozřejmě více, tyto jsou však zdaleka nejpoužívanější (podobně platí i u výše uvedených tabulek). Více informací - viz manuálové stránky Iptables.

Stavové filtrování

Jak již bylo řečeno, při filtrování dokáže netfilter zohledňovat také stavové informace. Rozlišujeme tyto stavy spojení (nutno informace udržovat):

o   ESTABLISHED - paket je součástí již existujícího spojení (ve kterém proběhly pakety oběma směry)

o   NEW - jde o paket, který otvírá nové spojení (nebo je součástí dosud jednostranného spojení)

o   RELATED - paket, který se vztahuje k nějakému existujícímu spojení, ale není přímo jeho součástí (např. ICMP chybová zpráva)

o   INVALID - paket který nelze přiřadit žádnému existujícímu spojení (neplatné spojení)

Konfigurace firewallu

Logování

Logování se provádí prostřednictvím daemona syslogd do souboru /var/log/messages (v některých případech je důležitý také hlavní systémový log /var/log/syslog).

Rozšíření iptables

Target Extensions - rozšířené cíle

pomocí přepínače -j

o   LOG

o   DNAT, SNAT

o   REDIRECT

o   TTL

Match Extensions - rozlišení paketů jinak, než dle IP
- pomocí přepínače -m

·        state

·        iprange, multiport

·        mac, physdev

·        limit

·        time, account

Záplavovým DoS zprávám se lze většinou bránit na firewallu, v kombinaci se syncookies.
Ochrana firewallem //pozn. DoS (Denial of Service) = odmítnutí, odepření síťových služeb

iptables -N syn flood

iptables -A INPUT -i eth0 -p tcp --syn -j syn flood

iptables -A syn flood -m limit --limit 1/s --limit-burst 5 -j RETURN

iptables -A syn flood -m limit --limit 1/s --limit-burst 5 -j LOG --log-prefix=”SYN flood”

iptables -A syn flood -j DROP

Analýza a statistika záznamových souborů síťového firewallu Iptables

Existují tucty různých řešení síťových firewallů a pro každé řešení existuje unikátní formát záznamových souborů. Některá taková zařízení zaznamenávají pouze málo informací o přenosech - přibližně ty samé informace jako většina směrovačů. Jiné firewally jsou schopné zaznamenat i spoustu detailů o přenosech, které monitorují. Hloubka naší analýzy incidentů a podezřelé aktivity bude velice záležet na rozmanitosti v množství zaznamenaných informací.

Iptables zaznamenává události mnohem komplexněji, než většina ostatních typů firewallů.

Dec 1 14:04:12 debian kernel: [6111.337472] INPUT drop: IN=eth1 OUT= MAC= SRC=192.168.2.100 DST=224.0.0.251 LEN=260 TOS=0x00 PREC=0x00 TTL=255 ID=0
DF PROTO=UDP SPT=5353 DPT=5353 LEN=240

Zde je stručné vysvětlení, jaký význam mají jednotlivá políčka této položky záznamového souboru: datum, čas, jméno hostitele firewallu Iptables, úroveň syslog, příchozí a odchozí rozhraní, MAC adresy, zdrojová IP adresa, cílová IP adresa, délka paketu (LEN), typ služby (TOS), priorita typu služby (PREC), doba života (time-to-live, TTL), IP identifikační číslo (ID), IP protokol, zdrojový port, cílový port a délka užitečného obsahu. Příznak DF (Don’t fragment) značí zákaz fragmentace (DF = 1 nebo 0).

Iptables zaznamenává také několik dalších informací, které jsou užitečné při provádění analýzy záznamových souborů. Tyto informace mohou být hodnotné v případech, když určujeme povahu útoku stejně tak jako vlastnosti a záměry potenciálního útočníka (ovšem v případě velmi dobrého obeznámení s detekcí síťového vniknutí).

Wflogs je nástroj k analýze logů firewallů. Může být použit k tvorbě souhrnných reportů, a to v otevřeném textu, HTML a XML, nebo k monitorování firewall-logů v reálném čase. Tento nástroj je součástí tzv. WallFire projektu, ale může být využíván nezávisle. WallFire je určený k práci na reálných systémech jako jsou Unix, Linux a *BSD, od toho se samozřejmě odvíjí podporované systémy. Současnými vstupními moduly wflogs jsou netfilter, ipchains, ipfilter, cisco_pix, cisco_ios a snort. Příklad použití, kdy se překonvertuje patřičný logovací soubor netfilteru do HTML výstupu, je dále.

# wflogs -i netfilter -o html netfilter.log > /var/www/wflogs/logs.html

Automatický aplikace pravidel firewallu iptables

Jestliže si manuálně anebo nějakým skriptem nastavíme potřebná pravidla firewallu, je třeba zabezpečit automatické spuštění firewallu při startu/restartu operačního systému a přímo tak vynutit aplikaci pravidel filtrování. Na Debianu je podporovaný následující způsob [12], [27].

Jako první provedeme linuxový skript spustitelným (vlastník může soubor spouštět, zapisovat a číst): #chmod 700 firewall-iptables.sh Pozn. Pro takzvané „Debian-based“ distribuce (distribuce založené na Debianu) platí: skript firewallu je vhodné pouštět ihned po spuštění síť. rozhraní - při startu systému používáme vlastní skript - zkopírujeme jej tedy do adresáře /etc/init.d/ - spustíme následující příkaz #update-rc.d firewall-iptables.sh defaults 19 nebo v libovolném souborovém manažeru (mc) vytvoříme symlink (symbolický odkaz) na skript

Adding system startup for /etc/init.d/firewall-iptables.sh ...

·        /etc/rc0.d/K19firewall-iptables.sh -> ../init.d/firewall-iptables.sh

·        /etc/rc1.d/K19firewall-iptables.sh -> ../init.d/firewall-iptables.sh

·        /etc/rc6.d/K19firewall-iptables.sh -> ../init.d/firewall-iptables.sh

·        /etc/rc2.d/S19firewall-iptables.sh -> ../init.d/firewall-iptables.sh

·        /etc/rc3.d/S19firewall-iptables.sh -> ../init.d/firewall-iptables.sh

·        /etc/rc4.d/S19firewall-iptables.sh -> ../init.d/firewall-iptables.sh

·        /etc/rc5.d/S19firewall-iptables.sh -> ../init.d/firewall-iptables.sh

Tímto příkazem jsme učinili skript firewall-iptables.sh startovacím skriptem (tj. je zajištěno jeho automatické spuštění). Kontrolu nastavených pravidel v jednotlivých řetězcích výchozích tabulek filter, nat a mangle provedeme v konzole příkazového řádku následovně -viz obrázky (tato aplikovaná pravidla je nutné vyzkoušet a otestovat také v praxi, aby se ověřilo, zda vše funguje, jak má!):

Z výše uvedeného je zřejmé, že tabulky nezůstaly prázdné ani po restartu OS. Jsou naplněny příslušnými pravidly definovanými při tvorbě skriptu pro automatické spouštění. Ruční spuštění skriptu, tzn. manuální uplatnění pravidel firewallu je možné příkazem #sh /etc/init.d/firewalliptables.sh. Skript neběží jako daemon → nelze restartovat, úprava za běhu je možná pomocí příkazů.

TCP Wrappers - omezení přístupu k síťovým službám

Nejjednodušší způsob zabezpečení počítače je nespouštět na něm žádné služby, které by reagovaly na síťový provoz. To však není u serveru možné, protože potřebujeme obsluhovat nejrůznější služby. Kompromisním řešením je omezit spolupráci serveru ke komunikaci s klienty na nejnižší možnou míru. Zřejmě nejsnadnější metoda omezení příjmu síťových spojení je TCP wrapper (balíček tcp_wrappers). Je to knihovna, kterou lze snadno přilinkovat k prakticky jakémukoliv programu. Její funkce spočívá v tom, že veškerá příchozí TCP spojení jsou nejprve podrobena kontrole a teprve pak předána k obsloužení samotnému programu. Kontroly, které povolí nebo odmítnou příchozí spojení, jsou pro všechny programy, které TCP wrapper používají, soustředěny ve dvou souborech: /etc/hosts.allow a /etc/hosts.deny. Kupříkladu lze zakázat přístup všem strojům, jejichž jméno neodpovídá jejich IP adrese (tzv. paranoidní mód). V současné době jsou s touto knihovnou slinkovány téměř všechny programy, které přijímají TCP spojení (dokonce i NFS démoni pracující s UDP). Přesto existují výjimky - např. WWW server Apache, u něhož omezení přístupu nastavujeme v jeho vlastním konfiguračním souboru.

Tcp_wrapper pracuje se dvěma konfiguračními soubory:
/etc/hosts.deny – zakázaný přístup (obsahuje seznamy strojů, které k daným službám přístup nemají) /etc/hosts.allow – povolený přístup (definuje seznamy strojů, ze kterých je přístup k uvedeným službám povolen)

Firewall spoluprácí s TCP Wrappers umožňuje vhodnou obranu např. proti útokům hrubou silou, kdy se útočník snaží získat přístup do systému (prolomit heslo) generováním náhodných sekvencí - slov, slovních spojení, číselných kombinací, atp., a vzniká přitom velké množství neúspěšných spojení směrovaných na určitou službu daného systému. Tato podezřelá síťová aktivita je firewallem detekována (postup stále opakujeme, jen zkoušíme jiná hesla => náhlé zvýšení zátěže, alokace prostředků systému; ovšem požadavky přicházejí z jedné IP adresy stroje, popřípadě několika málo IP adres, pokud se jedná o distribuovaný útok). Firewall dynamicky upraví soubor /etc/hosts.deny přidáním zdrojové IP adresy potenciálního útočníka (zjištěné z hromadně přicházejících paketů) a následně „odstřihne“ vzdáleného uživatele, který se již nikdy nepřipojí. Stanovením vhodného limitu počtu spojení za sekundu (popř. minutu, hodinu) se lze takovému útoku efektivně bránit, ovšem tak, aby nedošlo k omezení právoplatných uživatelů odepřením služby (v případě nedostačujících limitních hodnot). V linuxovém prostředí je osvědčena spolupráce firewallu Iptables s TCP Wrappers

Port může být otevřený, což znamená, že na něm běží nějaká služba, nebo zavřený, pokud na něm nic neběží. Je možno rozpoznat ještě jeden stav, a to je filtrovaný, kdy je port chráněn firewallem. Při pokusu o připojení na port TCP je zpět odeslán paket s příznaky RST a ACK. V případě, že se jedná o UDP porty, je zpět poslán ICMP paket (zpráva) typu 3, z čehož vyplývá, že port je nedosažitelný. ICMP zprávy jsou vkládány do datové části IP paketů (za 20B hlavičku), číslo protokolu vyšší vrstvy je 1.

Proxy server

Squid HTTP Proxy 3.0

Dříve jmenované tři možnosti využití proxy serveru si představíme na kvalitním open-source proxy serveru pro cachování obsahu WWW stránek. Jeho jméno je Squid a pro své možnosti využití je velmi dobře znám nemalé linuxové komunitě.

Squid umožňuje klientům pracovat s protokoly HTTP, HTTPS, FTP a podporuje i několik dalších, méně používaných aplikačních protokolů.

Před instalací Squidu je třeba si uvědomit, že převážná část činnosti proxy serveru spočívá v uchovávání objektů v paměti a na disku. Čím více budeme mít paměti (doporučeno nejméně 128 - 256 MB), tím rychlejší bude proxy server. Jestliže se údaje budou uchovávat na pevném disku, jeho rychlost rapidně ovlivní výkon samotného proxy serveru. Z toho plyne použití velmi rychlých disků se sběrnicí SAS (serverové), případně SATA disků nejlépe zapojených do tzv. RAID pole 0 (stripping).

Kompilace a instalace Squidu

Pro kompilaci ze zdrojových souborů vystačíme s:

./configure --enable-linux-netfilter

make all

make install

Kompilace Squidu s parametrem „--enable-linux-netfilter“ => kernel je kompilován s podporou transparentního proxy.

Instalace adresářové struktury cache

Po nainstalování Squidu je třeba vytvořit adresářovou strukturu, ve které bude uchovávat obsah svojí cache paměti (cachované soubory). Některé linuxové distribuce vytvoří tuto strukturu při instalaci nebo prvním spuštění. V některých případech se musí tato struktura vytvořit ručně (např. při kompilaci Squidu ze zdrojových souborů):

/usr/sbin/squid3 -z

Výsledkem je vytvoření adresářové struktury v adresáři uvedeném v konfiguračním souboru "/etc/squid3/squid.conf", standardně je to "/var/spool/squid3".

Spouštění a zastavování Squidu

Program Squid se spouští automaticky při startu systému v runleveli 3 a 5, protože nemá význam jej pouštět manuálně. Co však význam určitě má, je jeho ovládání z příkazového řádku v případě údržby, upgrade, změny konfigurace a podobně.

V případě použití „init“ skriptů jsou všechny operace velmi jednoduché:

·        Spuštění Squidu: /etc/init.d/squid3 start

·        Zastavení Squidu: /etc/init.d/squid3 stop

·        Restartování Squidu: /etc/init.d/squid3 restart

·        Opětovné načtení konfiguračních souborů: /etc/init.d/squid3 reload

Poznámka: „init“ skripty jsou jen rozhraním k ovládání Squidu pomocí příkazového řádku konzole.

debian:/home/zdenek# /etc/init.d/squid3 restart
Restarting Squid HTTP Proxy 3.0: squid3 Waiting.....................done

Jestliže „init“ skripty použity nejsou, operace jsou částečně odlišné (cesta závisí na instalaci Squidu):

·        Spuštění Squidu: /usr/sbin/squid3 •

·        Zastavení Squidu: /usr/sbin/squid3 -k shutdown •

·        Opětovné načtení konfiguračních souborů: /usr/sbin/squid3 -k reconfigure

Konfigurační soubor "/etc/squid3/squid.conf"

Konfigurační soubor obsahuje direktivy pro proxy server Squid. Každý řádek má tvar:

direktiva hodnota1 [hodnota2 hodnota3 … hodnotaN]

Mnoho direktiv má nastavené implicitní hodnoty, takže je není nutno ani odkomentovat (o tom vždy informuje komentář v příslušné části konfiguračního souboru "squid.conf").

Soubor je velmi dobře komentovaný, většina parametrů je už defaultně nastavena správně, kromě parametrů týkajících se zabezpečení, nastavení vlastností cache či vlastní adresy sítě. Implicitně nastavený proxy server zabraňuje připojení uživatelům z jakékoliv síťové adresy kromě 127.0.0.1.

Nastavení sítě (sekce NETWORK OPTIONS)

Následující nastavení umožňuje určit porty, na kterých Squid „naslouchá“. Čím méně portů je otevřených, tím nižší je riziko jejich zneužití. Některé z těchto portů ne vždy potřebujeme, takže je můžeme zakázat.

·        http_port 3128: port, na kterém Squid defaultně přijímá požadavky klientů. Tento port je nevyhnutelný pro činnost Squidu. •

·        icp_port 3130: port, pomocí kterého Squid spolupracuje s rovnocennými proxy servery. V případě nevyužití je možné tuto funkci zablokovat hodnotou čísla portu „0“. •

·        htcp_port 4827: port, pomocí kterého Squid spolupracuje s rovnocennými proxy servery. V případě nevyužití je možné tuto funkci zablokovat hodnotou čísla portu „0“.

Nastavení cache (sekce OPTIONS WHICH AFFECT THE CACHE SIZE)

Pomocí těchto nastavení můžeme ovlivnit velikost diskové cache paměti, objekty, které se nemají uchovávat v cache paměti a algoritmus odstraňování objektů z cache paměti v případě, že dochází potřebný paměťový prostor a je třeba uložit objekty nové.

·        cache_mem 8 MB: velikost paměti používaná na nejvíce užívané objekty. Hodnotu zvětšíme dle našich možností a nároků. Pozor, nejde o paměť, kterou bude Squid zabírat. Ve skutečnosti bude proces „squid“ zabírat v paměti více! •

·        maximum_object_size 4096 KB: maximální velikost objektu uchovávaného v cache paměti. Větší objekty se uchovávat nebudou.

·        minimum_object_size 0 KB: minimální velikost objektu uchovávaného v cache paměti. Menší objekty se uchovávat nebudou. Hodnota „0“ znamená ignoraci tohoto požadavku.

·        maximum_object_size_in_memory 8 KB: maximální velikost objektu, který má být uchovávaný ve fyzické paměti.

·        cache_replacement_policy lru: algoritmus odstraňování objektů z cache paměti (určuje, které objekty budou odstraněny a které zůstanou v paměti). Výchozím nastavením je „lru“ (least recently used – nahradí nejdéle nevyužívanou stránku). Pomocí tohoto parametru lze radikálně ovlivnit výkon proxy serveru, pravděpodobně to však vyžaduje rekompilaci kódu (tzv. balíčkové verze nepodporují všechny algoritmy). Některé z dalších užívaných algoritmů jsou „lfu“ (least frequently used – nahradí nejméně využívanou stránku), „nfu“ (not frequently used – stránka nepoužívaná často), dále pak aging (stárnutí), apod.

·        memory_replacement_policy lru: algoritmus odstraňování objektů z fyzické paměti (stejný princip jako u parametru „cache_replacement_policy“).

Cesty k „log“ souborům a cache (sekce LOGFILE PATHNAMES AND CACHE DIRECTORIES)

•       cache_dir ufs /var/spool/squid3 100 16 256: nastavení adresáře s cachovanými objekty. První parametr („ufs“) určuje způsob uchovávání souborů. Druhý parametr („/var/spool/squid3“) určuje adresář, ve kterém se uchovávají objekty. Třetí parametr („100“) určuje velikost cache paměti na disku (v jednotkách MB). Poslední dva parametry určují počet vytvořených adresářů nižší úrovně v adresáři s cache. Při defaultním nastavení se vytvoří 16 podadresářů, každý z nich má dalších 256 podadresářů, v kterých se uchovávají objekty. Tyto adresáře se vytvářejí pro zrychlení přístupu k objektům – nemělo by do nich být zasahováno. Je nutné pamatovat také na to, že po změně hodnoty této direktivy je třeba znovu vytvořit/upravit adresářovou strukturu cache paměti (pozn. spustit Squid s parametrem „-z“).

•       cache_access_log /var/log/squid3/access.log: logovací soubor se záznamy každého požadavku.

•       cache_log /var/log/squid3/cache.log: logovací soubor se všeobecnými informacemi o správě cache paměti. Můžeme ho sledovat například po spuštění proxy serveru a dozvědět se, zda je vše v pořádku.

•       cache_store_log none: logovací soubor obsahující záznamy o objektech, čase vložení do cache paměti, čase odstranění z cache paměti a podobně. V konfiguračním souboru je přímo zmínka o neexistenci seriózní utility pro analýzu tohoto souboru, takže ho můžeme zakázat (hodnota „none“).

•       emulate_httpd_log off: umožňuje zapnout a vypnout emulaci formátu HTTP serveru (Apache) v logu „cache_access_log“. Emulovaný formát lze jednodušeji číst (správcem), ale pro přirozený formát existují speciální nástroje na analýzu přístupů a podobně.

Vyladění cache paměti (sekce OPTIONS FOR TUNING THE CACHE)

•       request_body_max_size 1 MB: maximální velikost HTTP požadavku.

•       reply_body_max_size 0: maximální velikost HTTP odpovědi. Umožňuje zablokovat stahování objemných souborů (MP3, AVI, apod.) přes proxy server. Výchozí nastavení nelimituje příchozí odpověď.

Řízení přístupu pomocí ACL (Access Control Lists)

Ke kontrole přístupu slouží v nastavení Squidu přístupové záznamy (ACL – Access Control Lists).

Každý ACL se skládá nejméně ze čtyř částí:

acl jméno typ hodnota . . .

acl jméno typ "soubor" . . .

1.      direktiva acl

2.      jméno ACL (bude se na něho odvolávat při samotném řízení přístupu)

3.      typ ACL (určuje, co se bude kontrolovat, např. zdrojová adresa, cílová adresa, atd.)

4.      hodnota, případně vícero hodnot (hodnota je uvedená jako řetězec, popřípadě je možné uvést jméno souboru v uvozovkách – soubor musí být textový, ve kterém každý řádek znamená jednu hodnotu)

Následuje záznam nejpoužívanějších typů ACL s uvedením jejich syntaxe a krátkým popisem. Všechny jsou uvedené v konfiguračním souboru "/etc/squid3/squid.conf". Připomínám, že cílová adresa znamená adresu (HTTP) serveru, zdrojová adresa je adresa klientského počítače, který si žádá od proxy serveru zpřístupnění www stránky na dané cílové adrese.

•       acl aclname src 10.0.0.0/255.255.255.0 ...: definuje ACL založené na zdrojové IP adrese a masce •

•       acl aclname src 10.0.0.1-10.0.63/255.255.255.255 ...: definuje ACL pro zadaný rozsah zdrojových IP adres •

•       acl aclname dst 192.168.0.0/255.255.255.0 ...: definuje ACL pro zadanou cílovou IP adresu s maskou •

•       acl aclname srcdomain .foo.com ...: definuje ACL pro zadanou část domény ve zdrojové adrese (vykoná se reverzní překlad zdrojové adresy) •

•       acl aclname dstdomain .foo.com ...: definuje ACL pro zadanou část domény v cílové adrese (z URL adresy) •

•       acl aclname srcdom_regex [-i] xxx ...: definuje ACL pro zdrojovou adresu (adresu klienta), která vyhovuje regulérnímu výrazu. Parametr "-i" znamená, že se nebude brát v úvahu velikost písmen. •

•       acl aclname dstdom_regex [-i] xxx ...: definuje ACL pro cílovou adresu (adresu serveru), která vyhovuje regulérnímu výrazu. Parametr "-i" znamená, že se nebude brát v úvahu velikost písmen. •

•       acl aclname time [day] [h1:m1-h2:m2]: definuje ACL pro určitou časovou relaci – jsme schopni určit konkrétní dny (S - Sunday, M - Monday, T - Tuesday, W - Wednesday, H - Thursday, F - Friday, A - Saturday) a časy (h1:m1 musí být méně jako h2:m2). •

•       acl aclname url_regex [-i] ^http://www.foo.com ...: definuje ACL pro URL, která vyhovuje regulérnímu výrazu. V tomto případě musí URL začínat textem http://www.foo.com. •

•       acl aclname urlpath_regex [-i] \.gif$ ...: definuje ACL pro část URL adresy (cesty), která vyhovuje regulérnímu výrazu. V tomto případě musí cesta končit řetězcem ".gif". •

•       acl aclname port 80 70 21 ...: definuje ACL pro cílový port nebo více cílových portů •

•       acl aclname port 0-1024 ...: definuje ACL pro rozsah cílových portů •

•       acl aclname proto HTTP FTP ...: definuje ACL pro typ protokolu •

•       acl aclname method GET POST ...: definuje ACL pro metodu protokolu HTTP •

•       acl aclname browser [-i] regexp: definuje ACL pro hlavičku "User-Agent" v protokolu HTTP (umožňuje detekovat typ prohlížeče), která vyhovuje regulérnímu výrazu

Další důležitá nastavení

Tyto direktivy nastavují rozličné administrativní parametry:

•       cache_mgr root: e-mailová adresa správce cache.

•       cache_effective_user squid: uživatel, s jehož právy běží procesy Squidu, jestliže byl spuštěný pod tzv. rootem. Doporučuje se vytvořit speciálního uživatele (např. „squid“).

•       cache_effective_group squid: skupina, s jejímiž právy běží procesy Squidu, jestliže byl spuštěný pod tzv. rootem. Doporučuje se vytvořit speciální skupinu (např. „squid“).

•       memory_pools on: zapnutí této volby způsobí, že si Squid udržuje alokovanou (i když nevyužitou) paměť pro další použití. V případě nedostatečného množství paměti lze volbu zakázat pomocí hodnoty „off“.

•       memory_pools_limit 50 MB: velikost paměti, kterou si Squid udržuje alokovánu, jestliže používáme „memory_pools“.

•       error_directory /usr/share/squid3/errors/Czech: adresář s chybovými hlášeními – defaultně anglický jazyk. Zde uvedená direktiva zabezpečí zobrazování českých chybových hlášení. Chybová hlášení jsou uložená jako samostatné HTML soubory, které jsme schopni libovolně modifikovat a vhodně doplňovat.

•       snmp_port 0: v případě nevyužití SNMP služby (resp. protokolu), můžeme zakázat další port pomocí hodnoty „0“.

•       chroot /chroot_jail: umožní uzavřít program Squid ve vyhrazeném adresáři (systémové volání chroot ()). Všechny cesty, které Squid používá, se stanou relativními cestami od tohoto adresáře, tedy např. "/var/spool/squid3" znamená "/chroot_jail/var/spool/squid3". Ve výchozím nastavení je volba vypnuta.

•       logfile_rotate: počet udržovaných logovacích souborů při používání "squid -k rotate" (přípony předcházejících log. souborů budou čísla). Tento příkaz se volá automaticky pomocí programu „logrotate“. Jestliže je hodnota parametru "logfile_rotate" rovna „0“, nastavení řídí program „logrotate“.

•       append_domain: doména, která se přidá za nekompletní adresy v URL.

Redirector

Jakmile Squid u nového požadavku zkontroluje přístupová práva (ACLs), může předat URL ke zpracování externímu redirectoru a pokračovat až se zpracovanou URL. Redirector je jednoduchý filtr, co na standardním vstupu přečte URL, zpracuje ji a na standardní výstup vypíše novou verzi. K zapnutí redirectoru slouží klauzule redirect_program, kam se zadá cesta k programu. Pomocí ACL operátoru redirector_access můžeme nastavit, pro které požadavky bude redirector uplatněn. Součástí Squidu žádný redirector není, je tedy třeba využít software třetí strany nebo vytvořit vlastní.

Refresh algorithm

Pokud není cachování úplně zakázáno direktivami HTTP jako Pragma: no-cache nebo Cache-control: {Private,No-Cache,No-Store}, může být objekt při průchodu proxy serverem uložen do paměti cache. Refresh algorithm je algoritmus, podle kterého Squid určuje, jestli objekt může ještě klientovi vrátit z cache (objekt je FRESH), nebo zda už je příliš zastaralý a neaktuální (STALE) a musí se tudíž obnovit z původního serveru a následně poté předat klientovi, který o něj žádal.

Hierarchické cachování (pro komunikaci vyvinut speciální protokol ICP)

Pokud Squid potřebuje pro klienta získat nějaký dokument, obrací se přímo na vzdálený server. Mnohem efektivnější by ale bylo, kdyby se obrátil nejdříve na nějakou jinou cache poblíž, kde latence spojení bude mnohem menší. Vztahy mezi cache jsou dvou druhů: "parent" (rodič) a "sibling" (sourozenec). Sibling oproti parent serveru nebude nikdy obstarávat objekt mimo svou cache.

Konfigurace Squidu

Transparentní režim Squidu

Nastavení transparentního režimu Squidu v předchozích verzích:

•       httpd_accel_host virtual

•       httpd_accel_uses_host_header on

•       httpd_accel_port 80

•       httpd_accel_with_proxy on

Od verze 2.6 stačí v konfiguračním souboru squid.conf nastavit pouze:

•       http_port 3128 transparent

•       always_direct allow all

Plus samozřejmě zapnout přesměrování ve firewallu Iptables:

# Protože používáme proxy server Squid jako transparentní proxy, je nutné nastavit firewall Iptables tak, aby veškerý provoz směřující na port 80 (WWW) byl automaticky přeposílán tomuto proxy serveru. iptables -t nat -A PREROUTING -i $LAN_IN -p tcp --dport 80 -j DNAT --to $SQUID_SERVER:$SQUID_PORT

# Jestliže se jedná o stejný systém, pak platí následující. iptables -t nat -A PREROUTING -i $INTERNET -p tcp --dport 80 -j REDIRECT --to-port $SQUID_PORT

V našem případě - $LAN_IN: eth1 [192.168.2.100/24], $INTERNET: eth0 [192.168.1.100/24],
                                    $SQUID_SERVER: 192.168.1.100, $SQUID_PORT: 3128

Vyjmutí X-Forwarded-For hlavičky z HTTP požadavků

Tento úkon se provádí z důvodu anonymity klientských PC. Nedojde tak k nechtěnému prozrazení IP adres počítačů v interní síti „schovaných“ za proxy firewallem. Výsledek je zobrazen na 2 příkladech.

v forwarded_for off [možnosti proměnné jsou: “on” … zapnuto, ”off” … vypnuto]

Kromě toho se pomocí hlavičky zjišťuje unikátnost návštěvníka, např. při hlasování v anketě apod. Hlavičku lze snadno podvrhnout, proto na ní nelze spoléhat. Squid disponuje dalšími možnostmi anonymizace klienta prostřednictvím konfiguračních direktiv anonymize_headers a fake_user_agent.

Zde bylo poukázáno pouze na některé z obrovských možností konfigurace Squidu. Další prováděná nastavení - viz Příloha diplomové práce, komentovaný konfigurační soubor /etc/squid3/squid.conf.

Konfigurace klientských webových prohlížečů

Testování sítě & proxy serveru

Popis předchozího obrázku :

•       eth0 - externí síťové rozhraní [WAN]; nedůvěryhodná nebo neznámá síť (např. Internet)

•       eth1 - interní síťové rozhraní [LAN]; důvěryhodná místní síť (např. Intranet)

•       lo - lokální loopback, místní smyčka (IP adresa: 127.0.0.1, maska: 255.0.0.0); pro účely testování

Vnějším rozhraním eth0 byla data přijímána z Internetu a vnitřním rozhraním eth1 poskytována místním hostitelským stanicím. Z obrázku je patrné, že modře vyhraničená pole značí u síťového rozhraní eth0 download (RX bytes) a u síťového rozhraní eth1 upload (TX bytes). Hodnoty uvedené v těchto polích (v jednotkách megabajtů) názorně dokazují funkčnost a efektivnost využití proxy serveru. V našem případě proxy serveru Squid.

Zobrazené hodnoty množství dat je nutno brát pouze v orientačním měřítku, jelikož byly v domácích omezených podmínkách testování k dispozici pouze tři dostupné osobní počítače a jeden notebook, všichni připojení k proxy serveru přes 100 Mbit/s switch (přepínač), neprojevila se zdaleka tolik efektivnost využití proxy cache, jako například v případě menší či střední firmy o několika desítkách či dokonce stovkách zaměstnanců.

Při takovém počtu připojených počítačů se často opakující se požadavky načítají „úsporně“ vzhledem k přenosové lince pouze z lokální cache proxy (za předpokladu splnění určitých kritérií) a šetří tak potenciál (výkon, někdy i cenu) síťových prostředků komunikační linky.

Vzniklý rozdíl mezi přijatými daty rozhraním eth0 a odeslanými daty rozhraním eth1 tvoří právě nacachované objekty v proxy, které byly rozhraním eth1 odeslány klientským stanicím jako odpovědi na požadavky, aniž by proxy server s těmito hostitelskými žádostmi kontaktoval vzdálený server na Internetu a vyžádal si novou/nenacachovanou, případně aktualizovanou stránku (tzn., požadavky od klientů vůbec neprošly vnějším síťovým rozhraním eth0). Diference mezi RX (pakety přijatými eth0) a TX (pakety odeslanými eth1) může být ovlivněna také lokálními broadcast pakety (tj. lokální oběžník).

δ = TX bytes_eth1 - RX bytes_eth0 = 7,4 MB - 5,7 MB = 1,7 MB - rozdílová hodnota značící velikost objektů uložených v cache proxy (lokálně k dispozici klientským stanicím); [TX bytes_eth1 ≥ RX bytes_eth0]

Otestování konektivity a zjištění dostupnosti obou rozhraní linuxového proxy zobrazuje obrázek 35. Program ping testuje funkčnost cesty ke zvolenému cíli paketem ICMP a poskytuje statistiku zpoždění. Ze zobrazených výsledků (výsledných časů) lze soudit, že síťová komunikace je v pořádku

•       IP adresa 192.168.2.100 - vnitřní rozhraní [eth1].

•       IP adresa 192.168.1.100 - vnější rozhraní [eth0].

•       Testováno z počítače uvnitř sítě (PC1), IP adresa 192.168.2.1.

•       Počítač má přes proxy server zajištěnou konektivitu do Internetu.

Zadáním příkazu netstat -n zobrazíme aktivní připojení TCP a provedeme kontrolu otevřených síťových portů. Program netstat podává informace o funkci celého komunikačního systému a jeho jednotlivých komponent

Popis předchozího obrázku

Proxy server Squid běží na síťové IP adrese 192.168.1.100 a naslouchá příchozím požadavkům klientů na portu 3128. Hostitelský počítač (klient) navazující spojení má IP adresu 192.168.2.1, privátní/dynamický port 5213X (porty 49152 - 65535 jsou používány pro komunikaci klienta se serverem). Z obrázku lze dále vyčíst, že pro komunikaci byl použit spojově orientovaný transportní protokol TCP a také, že se jedná o navázaný stav. IP adresa 127.0.0.1 (localhost) je rezervována pro tzv. Popis předchozího obrázku 36: loopback, logickou smyčku umožňující posílat pakety sám sobě.

Současný stav směrovací tabulky můžeme získat příkazem route (bez parametrů) na stroji Debianu. Zkontrolujeme v ní obsažené údaje. Příkazem route konfigurujeme statickou směrovací tabulku (nastavení routování a výchozí brány).

IP 192.168.2.0 je adresa vnitřní sítě (dostupná přes rozhraní eth1), IP 192.168.1.0 je adresa vnější sítě (dostupná přes rozhraní eth0). U obou maska třídy C (prefix /24). Defaultní adresát s IP 192.168.1.1 je brána (gateway) s maskou sítě 0.0.0.0 pro výchozí trasu. Uvedené příznaky znamenají: U (up) je funkční směrování a G (gateway) je označení místa, kde se paketů ujímá směrovač. Rozhraní je označení síťového adaptéru.