Firewally jsou tedy používány v zásadě ze dvou důvodů: 1. udržet útočníky mimo síť nebo 2. udržet uživatele v síti, zřejmá je 3. možnost, která představuje kombinaci výše uvedeného. Možná bychom nyní měli rozšířit definici firewalu jako systému filtrujícího síťový provoz – tedy paketový filtr – o nejrůznější proxy servery, které budeme v této práci chápat jako systémy umožňující uživatelům po autorizaci a na základě přidělených práv přístup k určitému médiu, například http protokolu internetu. Záměrně abstrahujeme od takzvaných transparentních proxy serverů, jejichž účelem většinou bývá skryté monitorování, filtrování či urychlování určitých služeb.
Zapojení firewallu do chráněné sítě, respektive architektura firewallu, představují první a možná nejzásadnější problém, který musí být řešen. Záleží z velké části na tom, zda bude třeba poskytovat internetu nějaké služby, řekněme například webserver. V takovém případě často volíme model s takzvanou DMZ – demilitarizovanou zónou – která je stále pod plnou kontrolou správců podnikové sítě (viz. kap. 2.2.1), ale zároveň je fyzicky oddělena od zbytku systému. Architektura by v takovém případě mohla vypadat například takto:
Jestliže máme jasno v umístění firewallu můžeme přistoupit k samotnému návrhu. Obecně existují dvě základní možnosti:
- standardně povolit veškerý provoz a zakazovat pouze určité služby / porty / atd.
- nebo implicitně zakázat naprosto vše a poté určit, které služby / porty / atd. mají firewallem procházet.
V podnikovém prostředí se nejčastěji setkáváme s druhou možností, tzn. default deny, jelikož firmy mají většinou IT oddělení, které je schopno udržovat a měnit filtrovací pravidla v závislosti na požadavcích pracovníků. Strategie filtrovaní veškerého provozu totiž vyžaduje velmi časté zásahy do konfigurace firewallu a tedy velmi mnoho času pověřených pracovníků. Navíc bohužel existují aplikace, které nepracují s přesně stanovenou skupinou portů takže není možné povolit jejich průchod firewallem. Řešením pak může být použití Socks proxy nebo v krajním případě vybudování VPN mezi problémovými místy.
Konfigurace filtru
Po zvolení defaultní strategie můžeme přistoupit k samotné konfiguraci firewallu, tato se samozřejmě liší produkt od produktu. Budeme dále předpokládat návrh firewallu na úrovni TCP/IP a rodinu protokolů IPv4. Existují samozřejmě i jiné kombinace, ale výše uvedené řešení je dnes asi nejrozšířenější. V našem případě si tedy musíme poradit v zásadě s TCP, UDP a ICMP. Protokol TCP je jak známo stavový, takže se pro něj pravidla píší velmi snadno, stačí například pouze povolit iniciační konekce na určité služby z venkovní sítě (internetu) a pak už jenom přidat pravidlo na propouštění již navázaných spojení. Protokol UDP má poněkud jiné určení, UDP transakce nemají charakter trvalého spojení a tak je třeba pravidla často psát obousměrně. Tento problém je možné řešit mnoha způsoby, jedním z nich je například použití takzvaného stavového firewallu. Pokud například pravidlo pro odchozí UDP konekci zvolíme jako stavové, vytváří si poté software firewallu samostatně krátkodobá dočasná pravidla, která povolí i připojení v opačném směru. Stavová pravidla je samozřejmě možné použít i u TCP, ovšem je třeba mít na zřeteli značné množství generovaných dynamických pravidel (zejména u protokolu UDP). Co se týče ICMP, je věcí každého správce sítě, jaké icmp type povolí. Podle standardů by měl každý stroj připojený do internetu odpovídat minimálně na ping tzn. echo request a reply, dále je pak záhodno kvůli správnému routování a provozu na síti povolit source quench, unreachable, fragmentaci případně traceroute. Výše uvedené platí spíše pro poskytované služby do internetu, nastavení pro vnitřní síť je samozřejmě plně v kompetenci podniku.
Žádné komentáře:
Okomentovat