5             Filtrace, proxy, firewall a internetový FrontEnd

5.1                 Filtrace

Filtrací rozumíme kontrolu procházejících paketů aktivním prvkem sítě na základě obsahu jejich procházejících paketů a následné rozhodnutí, zda-li může být paket poslán dále nebo ne. Filtr nemění obsah datových paketů (což neplatí o některých dále popisovaných prostředcích ochrany jako je např. NAT). Filtraci lze přirovnat k cenzuře prováděné v některých případech s poštovními zásilkami. Filtrace se může provádět na různých úrovních:

 

Obr. 5-1 Ochrana vnitřní sítě filtrací

Cílem filtrace je vytvořit polopropustný filtr, který umožňuje vlastním zaměstnancům přístup do Internetu, ale zamezuje přístup cizím uživatelům do naší sítě. Proto se často takovýto filtr přirovnává k diodě (pro elektrikáře) nebo k semipermeabilní membráně (pro biology).

 

Na obr. 5-1 je šipkami znázorněn cíl filtrace: umožnit přístup z vnitřní sítě do Internetu a zamezit útokům z Internetu na zdroje na vnitřní síti. Na obrázku šipky nevyjadřují přenos dat, ale pouze směr přístupu. Přenos dat je vždy obousměrný. Klient posílá do Internetu datové pakety s požadavky na získání informací z Internetu a zpět z Internetu chce získávat data.

 

Kde si máme filtr ve směrovači představit? Směrovač může mít více síťových rozhraní, takže předávání IP-datagramů může být mezi všemi rozhraními. Pokud je to technicky možné, tak se filtry přiřazují jednotlivým rozhraním. Na obr. 5-2 je rozhraní „Ethernet1“ přiřazen filtr „Filtr 1“, rozhraní „Serial1“ je přiřazen filtr „Filtr 4“ atd.

 

Obr. 5-2 Filtry na směrovači se přiřazují jednotlivým síťovým rozhraním

V klasickém operačním systému (např. UNIX) není možné pro aplikační vrstvu snadno zjistit, ze kterého linkového rozhraní IP-datagram přišel, protože linková vrstva „vybalí“ z linkového rámce IP-datagram a předá jej vrstvě IP. Při tomto předávání se již nepředává informace, z jakého linkového rozhraní data přišla – k dispozici je pouze IP-adresa – a je otázkou, zda-li je tato informace důvěryhodná. To bývá také důvodem, proč si firewally upravují standardní operační systémy. V případě, že není možné důvěryhodně v operačním systému zjistit, ze kterého rozhraní IP-datagram přichází, pak se filtry v takových systémech realizují, jakoby ležely ve středu systému a identifikace linkových rozhraní ve filtrech nefiguruje.

 

5.1.1                  Filtrace na úrovni protokolu IP

Filtrace se realizuje filtrem, který se vkládá mezi síť, kterou chceme chránit, a Internet.

 

Obr. 5-3 Filtr na úrovni protokolu IP

Filtr je zpravidla jednou z funkcí přístupového směrovače. Podobně jako poštmistr klasického poštovního úřadu třídí a předává poštu na základě adresy uvedené na obálce, tak směrovač předává IP-datagramy na základě pouze informací uvedených v záhlaví IP-datagramu. Korektně pracující poštmistr nikdy neotevře poštu a nepřečte si ji, stejně tak dobře vychovaný směrovač by nikdy neměl pracovat s jinými informacemi než s informacemi uvedenými v IP-záhlaví. Uvidíme však, že filtrace pouze na základě informací ze záhlaví IP-datagramu nestačí a směrovač-filtr potřebuje pracovat i s informacemi ze záhlaví TCP segmentu či UDP datagramu. A to existují i filtry pracující s aplikačními informacemi.

 

I když je filtrace možná na nejrůznějších prvcích, tak s největší pravděpodobností se s ní v praxi setkáte na směrovačích CISCO. Proto si popíšeme filtraci na těchto směrovačích, které podporují následující typy filtrů:

·         „Standardní filtry“ filtrující pouze na základě IP-adresy odesilatele (odesilatelem se rozumí odesilatel IP-datagramu).

·         „Rozšířené filtry“ filtrující na základě jak IP-adresy odesilatele, tak i IP-adresy příjemce. Dále rozšířené filtry umí filtrovat i na základě informací z TCP-záhlaví (resp. UDP-záhlaví)

·         „Dynamické filtry“ umožňující otevřít specifikovaný průchod směrovačem uživateli, který se směrovači autentizoval. Praktické využití tohoto filtru je omezeno spíše na správce systému, protože uživatel se nejprve musí autentizovat např. programem telnet. To však asi není příliš pro běžné uživatele schůdné.

·         „Reflexivní filtry“, které sledují relaci vyššího protokolu (TCP resp. UDP) a povolují směrem ven zřídit relaci a směrem dovnitř propouští pouze pakety patřící k této relaci.

 

Standardní filtr

Obr. 5-5 Standardní filtr

Standardní filtr prakticky nelze použít k nějaké bezpečnostní ochraně. Můžeme si představit podle obr. 5-5, že naše vnitřní síť není chráněna před útoky z Internetu a ani tuto ochranu nevyžadujeme. Vnitřní síť je tvořena dvěma sítěmi třídy C: sítí 195.41.41.0/24 a sítí 194.41.42.0/24. Cílem naší filtrace je, abychom přístup do Internetu povolili pouze ze sítě 195.41.41.0/24 a ostatním uživatelům tento přístup zamezili.

 

Nejprve je třeba vysvětlit, jak se nelogicky u směrovačů CISCO zadává síť 195.41.41.0/24. Pokud bychom očekávali, že zapíšeme tuto síť jako síť 195.41.41.0 s maskou 255.255.255.0, tak to je omyl. CISCO v masce zaměňuje nuly a jedničky (mají na to několik báchorek, proč tomu tak je, ale nejlépe je o tom nepřemýšlet a mechanicky to přijmout). Takže ve světě CISCO je:

 

Tvorba filtru se skládá ze dvou částí. Nejprve se definuje filtr (access-list) a ve druhém kroku se filtr aktivuje na konkrétním rozhraní směrovače. Toto elegantní řešení tak umožní jednou vytvořený filtr aktivovat i na více síťových rozhraních směrovače.

 

Rozšířený filtr

 

Rozšířený filtr umožňuje filtraci na základě adresy odesilatele i příjemce.

 

Pro další úvahy si vybudujeme hypotetickou podnikovou síť 195.41.41.0/24 a propojíme ji pomocí směrovače k Internetu (obr. 5-6). Náš hypotetický podnik má ještě další podobně k Internetu připojené pracoviště se sítí 195.47.40.0/24. Obě pracoviště chtějí komunikovat spolu a pro vzájemnou komunikaci chtějí využít Internet.

 

 

Obr. 5-6 Filtr omezující komunikaci na komunikaci pouze mezi dvěma sítěmi

 

 

Pravidlo je však takové, že filtry aktivujeme vždy na rozhraní, které je blíže k útočníkovi, aby se zamezilo útočníkovi i útokům vedeným proti samotnému směrovači. V tomto případě, očekáváme útočníka z Internetu (nekomentuji zde, že k většině útoků dochází od vlastních zaměstnanců).

 

Bezpečnostní riziko při propojení dvou sítí přes Internet s filtrací na úrovni IP-adres spočívá v tom, že někdo v Internetu, kdo se nachází mezi oběmi sítěmi, se nelegálně může prohlásit za IP-adresu, která patří jedné ze sítí.

 

Tak může útočník předstírat, že je naším protějškem, což takto postavený filtr nemůže zjistit (tzv. man in the middle attack).

 

Obr. 5-7 Man in the middle attack

Proto v případě, že jsou dvě sítě propojeny pomocí Internetu takovým způsobem, aby tvořily z hlediska přístupu jeden celek, zabezpečuje se toto spojení ještě dalšími prostředky. Příkladem řešení je vytvoření VPN.

 

Dalším útokem je address-spoofing attack. Při něm útočník odesílá IP-datagramy s adresou odesilatele patřící do intervalu vnitřní sítě. Obr. 5-8 znázorňuje, jak se dostat skrze náš filtr na počítač vnitřní sítě.

 

Obr. 5-8 Address-spoofing attack

Útočník v tomto případě volí adresu z vnitřní sítě. Zdánlivě se to může zdát neefektivní, protože útočník nemůže dostávat žádné odpovědi. Ano, je pro útočníka komplikovanější provést útok, aniž by od napadeného počítače dostával nějaké reakce. Avšak v mnoha případech může útočník reakci napadeného předpokládat a tak odpovědi ani nepotřebuje. Takový útok je komplikovaný např. už při použití protokolu TCP, kde napadený generuje náhodné číslo, kterým začíná číslovat svá odesílaná data. Útočník tak musí ve svém útoku předpovědět toto náhodné číslo, aby mohl v TCP relaci pokračovat. Zdá se neuvěřitelné předpovědět náhodné číslo, ale v minulosti se ukázalo, že mnohé generátory náhodných čísel nebyly příliš „náhodné“ a k takovým útokům došlo. Nedávná studie prokázala, že mnoho obvyklých operačních systémů stále nemá dostatečně kvalitní generátory náhodných čísel a útoky tohoto druhu jsou stále možné. Avšak útočit UDP datagramy či ICMP signalizací není komplikované ani pro méně zdatného útočníka. Např. podvrhnout v DNS přiřazení jména počítače na jinou IP-adresu či změnit čas pomocí protokolu NTP jsou velmi snadné úlohy.

 

5.1.2                  Filtrace na úrovni TCP

 

Rozšířený filtr - pokračování

 

Zatím jsme rozšířený filtr použili pouze pro protokol IP; nyní jej použijeme i pro jiné protokoly.

 

Zatímco filtrací protokolu IP se určovalo, které počítače mohou mezi sebou komunikovat, filtrací na úrovni protokolu TCP (resp. UDP) se tato komunikace omezuje jen na některé aplikace běžící na těchto počítačích. Kombinací filtrace protokolu IP a protokolů TCP/UDP je možné stanovit, aby konkrétní počítače mohly mezi sebou komunikovat pouze konkrétními aplikacemi. Navíc je možné filtrací zajistit, aby klienti určité aplikace z vnitřní sítě mohli využívat serverů v Internetu a přitom naopak, aby cizím klientům byl znemožněn přístup do vnitřní sítě. Např. aby se klienti z vnitřní sítě dostali na WWW-servery v Internetu, ale aby cizí klienti se nedostali na WWW-servery vnitřní sítě.

 

 

Obr. 5-10 Fragmentace

Začněme však od začátku. TCP segment (resp. UDP datagram) paket se vkládá (balí) do IP-datagramů. IP-datagram nesoucí TCP segment může být během své cesty Internetem fragmentován na několik IP-datagramů. To se stane v případě, že na nějaký směrovač na cestě dorazí IP-datagram jehož délka je větší než největší možná velikost dat linkového rámce (tzv. MTU), kterým mají být data dále přepravována. Např. na obr. 5-10 nám z jednoho TCP segmentu fragmentací vznikly tři IP-datagramy.

 

Fragmentací vzniklé IP-datagramy se dopravují Internetem samostatně. Všimněte si, že TCP záhlaví je jen v prvním z nich! Jak může provádět směrovač filtraci na základě záhlaví TCP segmentu, když v některých IP-datagramech TCP záhlaví vůbec není? Směrovač to dělá jednoduše. V případě, že chce filtrovat protokol TCP, pak filtruje pouze ty IP-datagramy, které obsahují TCP-záhlaví. Ostatní propouští.

 

Příjemci pak nedorazí pouze první fragment. Příjemce se snaží sestavit z jednotlivých došlých částí TCP segmentu celý paket. Ale to se mu nepodaří, protože mu vždy schází začátek. Po dosažení časového limitu to příjemce vzdá. Jediný problém je v tom, že příjemce, který nesestavil TCP paket, tak protokolem ICMP (packet reassembly time expired) o tom informuje odesilatele TCP paketu. Tato informace vysvětluje útočníkovi, proč se nedostal dále. Doporučuje se tedy takovéto odpovědi také filtrovat, aby útočník nedostával další informace.

 

Zopakujme si výměnu paketů mezi klientem a serverem v protokolu TCP. Jako příklad si zvolíme protokol telnet, jehož server používá port 23.

 

Obr. 5-11 Komunikace klient/server v protokolu Telnet

Nejprve musí být spuštěn server na portu 23 (viz obr. 5-11). Budeme předpokládat, že server má IP-adresu 193.145.1.30. Předpokládáme, že IP-adresa klienta je 195.41.41.5. Před tím než může začít klient s komunikací, tak si musí nechat od svého operačního systému přidělit nějaký volný port >1023. Předpokládejme, že systém klientovi přidělil port 1500.

 

 

Obr. 5-12 Útočník používající port 23 jako port klientský

Prozkoumáte-li obr. 5-12, tak nám námi napsaný filtr umožní útočit na servery běžící na portech větších než 1023 a to jsou zejména databázové servery (databázové servery se spouští na těchto portech, aby správce databáze nemusel mít superuživatelská privilegia).

 

I tomuto útoku lze zabránit zdokonalením filtrace na úrovni protokolu TCP.

 

Obr. 5-13 Příznak ACK není nastaven pouze u prvního TCP segmentu

 

Protokol TCP vytváří spojení mezi dvěmi aplikacemi. V tomto spojení se obě strany vzájemně potvrzují došlé pakety. K potvrzování došlých paketů se v TCP záhlaví používá příznak ACK. Tento příznak se nastavuje ve všech paketech TCP, kterými se potvrzují předchozí došlé pakety. Příznak ACK tedy není nastaven v prvním paketu, kterým klient navazuje spojení. Ve všech dalších paketech klient má již nastaven příznak ACK. Všechny pakety, které odesílá server, mají rovněž nastaven příznak ACK. 
 

5.1.3                  Reflexivní filtry

Protokoly UDP, ICMP, IGMP apod. nemají bit ACK. Proto u nich s technikou uvedenou v předchozím odstavci nevystačíme. Jedná se vesměs o protokoly, které nevytváří spojení.

 

Reflexivní filtr není nic složitého. Jedná se o velice prostou úvahu. Vraťme se zcela na počátek k obr. 5-1. Cílem ochrany vnitřní sítě je umožnit zaměstnancům z vnitřní sítě přistupovat do Internetu a zamezit útočníkům z Internetu útočit na systémy ve vnitřní síti. Avšak jak komunikace zaměstnance, tak i útok útočníka jsou z hlediska přenosu dat obousměrné relace. Tj. zaměstnanec navazuje relaci např. s webovým serverem v Internetu, zadá mu, jaké informace od něj žádá, a webový server mu je podává.

 

Reflexivní filtr filtruje odchozí datové pakety. Pokud zachytí paket, kterým se zahajuje nová relace, pak v opačném směru vygeneruje položku dočasného filtru, která umožní průchod paketům téže relace v opačném směru. Položka dočasného filtru získá své parametry z odchozího paketu:

 

Dočasná položka je udržována po dobu relace. V případě protokolu TCP je udržována ještě 5 vteřin po průchodu druhého paketu s příznakem FIN nebo je ukončena po průchodu paketu s příznakem RST (odmítnutí spojení). Tuto taktiku lze uplatnit pouze u protokolu TCP, který vytváří spojení. Obecně se pomocí klíčového slova „timeout“ nastavuje ve vteřinách interval, po jehož uplynutí se položka dočasného filtru ruší, pokud po tuto dobu byla relace nečinná.

 

Reflexivní filtry mají i svá omezení. Nelze je použít pro protokoly, jejichž odpověď může použít jiný port. Např. je nelze aplikovat na klasické FTP (avšak na pasivní FTP lze použít i reflexivní filtry). 

 

Reflexivní filtr na vnějším rozhraní

 

V prvním kroku vytvoříme reflexivní filtr, který bude zachycovat odchozí datové pakety, kterými klient vnitřní sítě bude zřizovat nové relace. Odchycení prvního paketu relace má za následek zřízení dočasného filtru v opačném směru. Ve druhém kroku musíme připravit dočasný filtr.  

 

Reflexivní filtr definujeme pro odchozí provoz, kdežto dočasný filtr definujeme pro příchozí provoz. Oba filtry musí mít svá samostatná jména. Zatímco u reflexivního filtru definujeme jeho jednotlivé položky, tak u dočasného filtru definujeme pouze jeho základ – jeho položky budou vznikat dynamicky s tím, jak uživatelé vnitřní sítě budou zřizovat své relace.

 

 

Obr. 5-14 Reflexivní filtr na vnějším rozhraní směrovače

 

Reflexivní filtr na vnitřním rozhraní

 

Reflexivní filtr není vhodné aktivovat na vnějším rozhraní přístupového směrovače v případě, že používáme demilitarizovanou zónu (DMZ). Tato aktivace by znemožnila přístup z Internetu na systémy na DMZ. Obzvláště v případě, kdy bychom měli na DMZ např. webový server či DNS server, by tato situace byla nepříjemná.

 

Obr. 5-15 Reflexivní filtr na vnitřním rozhraní směrovače

Řešením je aktivovat reflexivní filtr na vnitřním rozhraní. V tomto případě se reflexivní filtr definuje na vstupu do vnitřního rozhraní směrovače a dočasný filtr vzniká na výstupu tohoto rozhraní.

 

5.1.4                  Filtrace protokolů UDP, ICMP a případě dalších protokolů

Zde již jde pouze o diskusi na uvedené téma, neboť metody jsme již popsali. Je nesporné, že teoreticky dovedou směrovače filtrovat nejrůznější protokoly. A to včetně protokolů, které s rodinou protokolů vůbec ani nesouvisí. Já si myslím, že je třeba se nejprve zamyslet nad tím, jaké aplikace (jaké aplikační protokoly) mohou protokoly UDP, ICMP a případně další protokoly využívat.

 

Přitom si musíme uvědomit, že řešíme využití těchto protokolů pro komunikace skrze přístupový směrovač, tj. mezi Internetem a vnitřní sítí.

 

5.1.5                  Zakázané adresy

Zjistíme-li, že z nějaké IP-adresy nás atakuje útočník, pak tuto adresu si zaneseme do množiny zakázaných adres – na „černou listinu“. Filtry pak rozšíříme o explicitní zákaz komunikace s těmito adresami. Za zmínku stojí i to, že zakázané adresy můžeme mít i z vnitřní sítě.

 

5.2                 Proxy

Proxy je program, který pracuje na aplikační úrovni. Skládá se ze dvou částí. Na jedné straně pracuje jako server a na druhé straně jako klient. Serverová část proxy přijímá požadavky od klientů a předává je klientské části proxy, která jménem původního klienta předává požadavky na originální server.

 

Proxy a s ní bránu a tunel pro protokol HTTP jsme probrali při popisu protokolu HTTP. Podrobně je činnost proxy i s činností DNS znázorněna na obr. 2-13. Obr. 5-16 zjednodušuje tento obrázek. Proxy si představujeme jako aplikaci běžící na počítači se dvěma síťovými rozhraními. Jedno síťové rozhraní je připojeno do vnitřní sítě a druhé do Internetu.

 

Mnohdy jsou užitečné i jednodušší proxy, které používají pouze jedno síťové rozhraní. Příklad jejich využití jsem uvedl v kapitole o filtraci. Jiné využití takovýchto proxy je, že neoddělují dvě sítě, ale využívají se pro zrychlení komunikace. Tj. využívají se jako cache.

 

Obr. 5-16 Proxy

 

Proxy se používá zejména na rozhraní dvou sítí, mezi nimiž není přímá konektivita. Proxy se pak používá jako oddělovač obou sítí. Z jedné sítě je tak možné se připojit na proxy a z ní pak dále do druhé sítě.

 

Klasická představa proxy je počítač s dvěma síťovými rozhraními. Cílem je, aby na vnitřním rozhraní pracovala serverová část proxy a na vnějším rozhraní klientská část. Nemusí to být jediným cílem. Někdy je požadováno, aby proxy pracovala i opačně, tj. aby pracovníci na cestách (klienti) si mohli např. vybírat poštu z vnitřní sítě. Takto pracující proxy je však nebezpečná. Pokud se vůbec něco takového povolí, pak zpravidla v kombinaci s autentizací jednorázovým heslem před propuštěním klienta do vnitřní sítě. Klienti bývají pro tyto účely vybavování autentizačními kalkulátory. Dnes se stále více takovéto řešení opouští a nahrazuje řešením na bázi VPN.

 

Proxy pracuje tak, že serverová část proxy předává požadavky klientské části proxy a opačně. Při předávání požadavků mezi oběma částmi proxy nemusí dojít pouze k mechanickému předávání, ale předávání může být propracovanější. Zajímavé jsou zejména dvě následující vlastnosti:


Takže proxy může např. pro protokol HTTP určovat, které počítače mohou používat metodu GET a na jaká URL. Jiné počítače zase mají povolenu metodu PUT či POST. Obdobně u protokolu FTP je možné povolit příkaz GET, ale zakázat příkaz PUT, aby zaměstnanci vnitřní sítě nemohli zcizit data.

 

Některé aplikační protokoly ve své podstatě pracují jako proxy. Není třeba pro tyto protokoly vyvíjet nějaké speciální proxy – místo nich stačí použít server pro příslušný protokol. Jedná se např. o protokoly:

5.3                 SOCKS

Doposud jsme pro každý aplikační protokol spouštěli samostatnou proxy (obr. 5-18). 

 

Obr. 5-18 Proxy běžící pro jednotlivé aplikační protokoly

Proxy řeší dva problémy:

  1. Autentizaci klienta. Pouze pro autentizované klienty se proxy otevře. Autentizace může být na základě:

·         IP-dresy klienta a na proxy může být vedena tabulka IP-adres jednotlivých klientů, kteří mohou používat proxy. Nebo se vedou adresy sítí, ze kterých mohou klienti používat proxy (např. síť 10.0.0.0/8).

·         Jména a hesla (běžné u HTTP-proxy).

·         Jednorázového hesla generovaného např. autentizačním kalkulátorem.

  1. Zajištění přenosu informací mezi vnitřní sítí a Internetem.

 

V případě, že proxy nepodporuje autentizaci, pak se před proxy předřadí wrapper. Asi vás však napadlo, že wrapper je v podstatě šit na míru do prostředí operačního systému UNIX. SOCKS řeší problematiku proxy včetně autentizace zcela obecně a nezávisle na použitém operačním systému.

 

SOCKS-server je proxy, která je společná pro všechny aplikační protokoly (obr. 5-19).

 

 

Obr. 5-19 SOCKS Server

SOCKS je protokol, kterým komunikují klienti se SOCKS serverem. Cílem této komunikace je otevřít příslušnou proxy pro daný požadavek. Klient zřídí řídící kanál se SOCKS serverem (zpravidla na portu 1080/tcp). Dialogem vedeným v řídícím kanálu server sdělí klientu IP-adresu a port serverové části proxy, kterou otevírá pro klienta. Klient pak na uvedenou IP-adresu a port naváže datové spojení protokolem TCP, jako by navazoval spojení s cílovým serverem v Internetu. Pokud se klient se SOCKS serverem dohodli na UDP-proxy, pak klient na uvedenou adresu a port protokolu UDP odešle datagram, který proxy předá do Internetu (obr. 5-20).

 

 

Obr. 5-20 Řídící na datový kanál

Protokol SOCKS verze 5 zavedený v RFC-1928 řeší celou problematiku komplexně ve čtyřech krocích:

  1. Dohoda na autentizační metodě. Klient nabídne SOCKS-serveru autentizační metody, které podporuje. SOCKS-server z nich vybere jednu. Klient se pak na základě této metody autentizuje. Metoda může teoreticky v sobě zahrnovat i požadavek na šifrování a elektronické podepisování přenášených dat mezi klientem a SOCKS-serverem. V takovém případě po prokázání totožnosti běží veškerý provoz zabezpečeně (šifrovaně, případně elektronicky podepisován). Požadavek na zabezpečení dat mezi klientem a SOCKS serverem je důležitý zejména v případech, kdy by od SOCKS serveru bylo požadováno, aby umožňoval autentizovaným klientům Internetu přístup do vnitřní sítě.

  2. Autentizační dialog. Autentizační dialog závisí na zvolené metodě. Tč. je normalizová metoda autentizace pomocí jména a hesla uživatele (RFC-1929), metoda GSS-API (RFC-1961) a pochopitelně metoda bez autentizace. Metoda bez autentizace je metoda, kdy od klienta není vyžadován žádný autentizační dialog. Avšak SOCKS-server je přesto schopen provést autentizaci na základě IP-adresy klienta.  

  3. Požadavek na zřízení příslušné proxy. Teprve po autentizačním dialogu SOCKS-server přijme od klienta požadavek, na jehož základě zřídí příslušnou proxy. Klient protokolem SOCKS předá požadavky SOCKS-serveru. Klient vydává požadavek CONNECT či BIND pro zřízení proxy na bázi protokolu TCP a požadavek ASSOCIATE pro zření UDP proxy (UDP relay).

  4. Datová komunikace skrze proxy se vzdáleným serverem.

 

Jinými slovy: klient (např. program telnet) musí nejprve vést dialog se SOCKS-serverem, kterému sdělí, na jaký server v Internetu se chce propojit. Volitelně je možná autentizace klienta. Podstatné je, že klient vede se SOCKS-serverem dialog. Programy na straně klienta (např. telnet) musí být upraveny tak, aby uměly vést tento dialog. Tj. programy klientů musí být upraveny, aby komunikovaly se SOCKS serverem.

 

Jsou vytvořeny knihovny podporující SOCKS-protokol, které jsou obdobou standardních socketových knihoven používaných při programování v prostředí TCP/IP. Stačí ve zdrojovém textu programu opravit volání standardní funkcí socketových knihoven za tato volání. Přitom obojí volání mají stejnou syntaxi. Stačí pouze mechanicky zaměnit názvy funkcí:
 

Standardní knihovny

Knihovny SOCKS

connect()

Rconnect()

getsockname()

Rgetsockname()

bind()

Rbind()

accept()

Raccept()

listen()

Rlisten()

select()

Rselect()

 

V podstatě ani není třeba opravovat zdrojové texty programů, protože uvedenou substituci je možné zadat při překladu programu (tj. specifikovat v souboru Makefile).  Máte-li zdrojový text programu klienta, pak jej znovu přeložíte s uvedenou substitucí a získáte klienta pracujícího se SOCKS. Dnešní klienti jsou již konfigurovatelní tak, že je možné zvolit komunikaci přes SOCKS-server (např. Netscape Navigator). 

 

Na předchozích obrázcích jsem nakreslil klienta ve vnitřní síti, jak přistupuje na server v Internetu. Jelikož se provádí autentizace, tak obdobně jako při použití wrapperu je za použití dostatečných kryptografických mechanizmů možné přistupovat pro vybrané uživatele (kteří se autentizují) přes SOCKS-server z Internetu do vnitřní sítě. SOCKS-server pak zpravidla konfigurujeme tak, že pro přístup:

Jak jsem se již zmínil, tak předpokládáme, že SOCKS-server zpravidla běží na firewallu.

 

5.4                 WIN SOCKS

WIN SOCKS je značně odlišné řešení oproti SOCKS. WIN SOCKS je podporováno systémem MS Proxy. Na úvod je třeba poznamenat, že MS Proxy podporuje tři typy proxy:

 

MS Proxy je již spíše firewall než běžné proxy. Což není dáno tím, že podporuje celou škálu typů proxy, ale spíše tím, že striktně vyžaduje dvě rozhraní. Jedno pro vnitřní síť a druhé pro Internet.

 

WIN SOCKS se na problematiku dívá z jiného úhlu. Příliš si neláme hlavu síťovým protokolem mezi klientem a proxy. Ten snad ani není závazně zveřejněn. Pohlížejí na problém prakticky z pohledu tvorby aplikace.

 

 

Obr. 5-27 Klient v prostředí Microsoft používá dynamické knihovny

Klient v systémech Microsoft používá pro komunikaci protokolem TCP/IP na bázi soketů buď šestnáctibitovou knihovnu WINSOCK.DLL nebo 32-bitovou knihovnu WSOCK32.DLL.

 

Aplikace jsou tvořeny tak, že veškerou problematiku komunikace řeší voláním API příslušné knihovny. Myšlenka spočívá v tom, že se místo původních knihoven podvrhnou nové knihovny, které se budou jmenovat stejně a budou mít i stejné API (obr 5-28). To umožní, aby aplikace, které využívaly původní knihovny, používali knihovny nové. Přitom v aplikacích nemusí být změněno vůbec nic.

 

 

 

 

Obr. 5-28 Nové DLL knihovny přenesou komunikační požadavky na MS Proxy

Nové knihovny pak naváží řídící kanál se serverem MS Proxy. Tento kanál může být navázán nejenom protokolem TCP/IP, ale i jinými protokoly (IPX/SPX či NetBEUI). Veškeré požadavky aplikaci (tj. veškerá volání API) jsou přenesena řídícím kanálem na MS Proxy, kde se teprve provedou. Po navázání spojení se zřídí datový kanál, kterým se přenášejí příslušná data. Jelikož MS Proxy má přístup do Internetu a síťová volání jsou prováděna až na MS Proxy, tak klient může komunikovat se servery v Internetu.

 

 

Obr. 5-29 Celková komunikace MS Proxy

Má to však háček, který spočívá v potřebě komunikovat také v rámci vnitřní sítě. Aby veškerá komunikace v rámci vnitřní sítě nemusela probíhat přes Proxy, tak se provede další trik (obr. 5-29). Po zřízení řídícího kanálu zašle MS Proxy klientovi tabulku LAT, ve které je poznamenáno, které sítě jsou vnitřní sítě.

 

Pak stačí testovat jednotlivé položky klienta a v případě, že klient chce komunikovat pře MS Proxy, použít nové knihovny. V případě, že klient chce komunikovat v rámci vnitřní sítě, pak se použijí původní knihovny.

 

 

 

Výhodou WIN SOCKS je, že pokud jsou aplikace vyvinuty v prostředí Microsoft a používají soketové knihovny, tak je není třeba vůbec měnit. Další výhodou je, že se díky rozšíření produktů firmy Microsoft podařilo tento systém poměrně rozšířit (na rozdíl od klasických SOCKS). Nevýhodou je, že celý systém je orientován pouze na prostředí Microsoft. 

 

5.5                 Skryté sítě

V případě, že používáme proxy, pak se navazují dvě TCP spojení (obr. 5-30):

1.        Mezi klientem a proxy.

2.        Mezi proxy a cílovým serverem.

 

Obr. 5-30 Při proxy se navazují dvě TCP spojení

Z pohledu Internetu (např. z hlediska cílového serveru) není vnitřní síť vidět - je skrytá. Klienti vnitřní sítě se jeví, jakoby byli lokálními klienty proxy (obr. 5-31).

 

Obr. 5-31 Z hlediska Internetu se proxy jeví, jakoby byla nějakým velkým počítačem s velkým množstvím terminálů a všichni klienti vnitřní sítě seděli u těchto terminálů.

Spojení klienta s proxy může být realizováno protokolem TCP/IP nebo dokonce i jinými protokoly, jako např. IPX/SPX, NetBEUI apod.  Budeme si však i pro spojení na vnitřní síti nadále představovat použití protokolů TCP/IP.

 

Z pohledu Internetu na IP-adresách klientů nezáleží - jsou skryty za proxy. Avšak z hlediska proxy bychom ji zbytečně přivedli do svízelné situace, kdyby klient měl stejnou IP-adresu jako nějaký cílový server. Proto je důležité volit pro klienty vnitřní sítě IP-adresy takové, které  se v Internetu nevyskytují.

 

I když je na Zemi mnoho vnitřních sítí (intranetů), tak klienti jednotlivých intranetů mezi sebou většinou nenavazují žádné spojení, tj. všechny Intranety mohou používat stejné IP-adresy. Pro Intranety byly přiděleny následující intervaly IP-adres:
 
 

10.0.0.0

až

10.255.255.255

172.16.0.0

až

172.31.255.255

192.168.0.0

až

192.168.255.255

 

5.6                 NAT

Proxy pracující na aplikační vrstvě nám dokáže skrýt vnitřní podnikovou síť před Internetem. Nešlo by to však udělat bez proxy? Co takhle přímo na směrovači převádět IP-adresy? Když dokáže směrovač přepsat položku TTL v záhlaví IP-datagramu, neuměl by přepsat IP-adresu odesilatele a příjemce?

 

Řešením je "Network Adress Translator" (NAT), který takové převody realizuje. NAT specifikuje RFC-1631 a dále následující normy: RFC-2663, RFC-2709, RFC-2766 a RFC-2993.

5.7                 Firewall

Firewall je  systém tvořený jedním nebo více počítači vyhrazený k „bezpečnému“ oddělení vnitřní sítě od Internetu tak, aby mohli uživatelé vnitřní sítě přistupovat k informacím dostupným na Internetu.  Firewall využívá všech mechanizmů, které jsme popsali v předchozích kapitolách, tj. filtrací, wrappery, proxy, bránu či SOCKS.

 

Co přináší firewall nového kromě toho, že je realizován na vyhrazených počítačích? Firewall ukládá informace o provozu do souborů (logů), ze kterých lze nejenom vyčíst dílčí akce, ale i vytvářet sumární přehledy (reporty). Původní firewally používaly běžný, neupravený operační systém, kdy správce firewallu musel periodicky ručně procházet logy a vyhodnocovat je, zda nedošlo k nějakému bezpečnostnímu incidentu. Nevýhodou těchto firewallů bylo, že se na bezpečnostní incidenty přišlo až s určitým časovým odstupem.

 

Aktivní firewally nezapisují vzniklé události pouze do logu, ale je na nich možné stanovit jistá pravidla, kdy vzniklá událost může způsobit jistou akci (alert). Akcí je pochopitelně spuštění či ukončení nějakého programu. Ve většině případů ale nejde o obecné spuštění nějakého obecného programu, ale nejčastěji o:

 

Standardní knihovny TCP/IP aplikační vrstvě nejsou schopny předat zaručenou informaci, z jakého síťového rozhraní (z jaké sítě) datový rámec přišel. Takže při použití klasické proxy máme vždy obavu, nepodvrhuje-li nám náhodou někdo z Internetu paket, jakoby přišel z vnitřní sítě. Tomu však umí většina filtrů bránit dostatečně efektivními metodami, aniž by se proxy musela o tuto věc starat.

 

V závislosti na typu firewallu je snaha, aby firewall řešil i zabezpečení na linkové vrstvě, tj. aby firewall ošetřil i stavy, kdy:

 

U firewallu je každé síťové rozhraní označeno buď jako vnitřní, jako vnější či jako rozhraní pro DMZ. Toto označení je u některých firewallů jen formální pro účely konfigurace; u jiných firewallů se pak opravdu na linkové vrstvě kontroluje, zdali IP-datagramy přicházejí na rozhraní, na které přicházet mají. Všechny ostatní situace se pak označují za potenciální bezpečnostní incidenty a generují příslušné události.

 

Firewall některé služby jako je filtrace, proxy či NAT provádí sám. Jiné služby, jako je zjišťování virů v datech procházejících firewallem či autentizace klientů, může firewall vyžadovat od aplikací běžících i na jiných počítačích specializovaných pouze pro tyto účely. Takové počítače jsou zpravidla umístěny ve vnitřní síti. Firewall pak pracuje jako klient těchto serverů.

 

Z hlediska operačního systému je u firewallu vyžadována bezpečnost třídy C2. Z běžně používaných firewallů pouze firewall Cyberguard KnightStar používá bezpečnost třídy B.

 

Základem každého firewallu je vždy buď proxy (např. Firewally Raptor, Gautlet či MS Proxy) nebo filtrace (Firewall-1 či CISCO PIX). Mnohé firewally pak podporují jak proxy, tak i filtraci. V takovém případě můžeme pro některé aplikace využít filtraci a pro jiné proxy.

 

Pojem firewallu není přesně vymezen. Existuje i norma zabývající se firewally: RFC-2979. Jedná se však o velice útlou a tudíž ne příliš „výživnou“ normu, která by problematiku obšírně vymezila. Tato norma specifikuje firewall jako agenta, který sleduje datový provoz mezi vnitřní síti a Internetem a zjistí-li provoz, který považuje za neodpovídající či dokonce nebezpečný, tak jej zablokuje. I tato norma říká, že firewall pracuje buď jako filtr nebo cílový bod z hlediska protokolu nebo je firewall kombinací obou technik.

 

Firewall pracuje jako cílový bod v případě protokolu HTTP, kdy klient navazuje spojení s proxy a proxy pak navazuje spojení jménem klienta dále do Internetu. Obdobně u protokolu SMTP firewall přijme elektronickou poštu a posléze ji předá dalším spojením dále. V případě, že firewall pracuje jako koncový bod spojení, pak je firewall vidět jak ze strany klienta, tak ze strany cílového serveru. V případě, že firewall pracuje jako filtr, pak ani klient, ani server se nemusí o existenci firewallu dozvědět.

 

Norma RFC-2979 říká, že firewally pracující jako koncové body spojení by měly podporovat jen takovou podmnožinu protokolů, která je bezpečná, měly by podporovat veškerá rozšíření protokolů zabývající se kontrolami (validity check) a mely by být provozovány v bezpečném prostředí.

 

Já jsem se poprvé setkal s firewallem SEAL dnes již neexistující firmy Digital. Ten byl řešen třemi počítači původně se systémem ULTRIX; později pak počítači se systémem DEC OSF/1 (DEC OSF/1 je dnes označován COMPAQ True64 UNIX).

 

Firewall SEAL byl řešen třemi počítači (obr. 5-38):

 

Použití tří systémů má mnohé výhody:

 

Prohlédneme-li si obrázek 5-38, pak LAN, na které je směrovač 1, systém gatekeper a vnější rozhraní systému gate označená jako „červená síť“, tvoří DMZ v případě, že na směrovači 1 aktivujeme filtraci. Na tuto DMZ je možné umísťovat různé aplikace. Obdobně „modrá síť“ tvoří také DMZ. Každá z těchto DMZ má ale jiné bezpečnostní charakteristiky. Na vnitřní DMZ je např. poštovní server. Vnitřní DMZ vznikne aktivací filtrů na směrovači 2. Filtry na směrovači 2 chrání firewall před útoky z vnitřní sítě.

 

Obr. 5-38 Firewall SEAL

Pokud chce klient přistupovat např. protokolem HTTP z vnitřní sítě do Internetu, pak kontaktuje proxy běžící na systému gate. Tato proxy pak jménem klienta zprostředkuje spojení do Internetu. Jinými slovy, červená síť musí mít adresy použitelné v Internetu, tj. přidělené poskytovatelem Internetu, protože klientská část proxy bude používat tuto adresu. Avšak červená síť musí být adresovatelná i ve vnitřní síti, protože klient bude kontaktovat z vnitřní sítě proxy ležící na červené síti.

 

Z firewallu SEAL se vyvinul firewall AltaVista (dnes Raptor). Cílem bylo zredukovat firewall na jeden počítač oddělující vnitřní a vnější síť (obr. 5-39). Na takto vzniklý systém vznikly extrémní nároky na bezpečnost. Výsledkem je „jednopočítačový“ firewall zabezpečující veškeré funkce a teoreticky nevyžadující nějakou bezpečnostní součinnost ani směrovačů 1 a 2. Tento firewall zpracovává procházející informace od linkové vrstvy až po aplikační vrstvu. Avšak z bezpečnostních důvodů by neměly na „jednopočítačovém“ firewallu byt spouštěny jakékoliv jiné aplikace než aplikace realizující samotný firewall. Tj. neměl by zde např. běžet podnikový webový či poštovní server atd. (o použití firewallu k editaci textů ani nemluvě, protože to by znamenalo navíc ještě přístup nepovolaných osob k systému). To má za následek, že většina firem si stejně zakoupí další dva systémy: jeden pro webový server a druhý pro poštovní server.

 

 

Obr. 5-39 Firewall Raptor

Jiným typem firewallu je TIS Firewall Toolkit. Jedná se o soubor programů, který je možné zkompilovat na operační systému typu UNIX. Tento soubor programů obsahuje jednotlivé funkce potřebné pro činnost firewallu. Firewall si pak můžeme postavit podle našich potřeb „na míru“. Od tohoto firewallu je pak odvozen komerční firewall Gauntlet, který je doplněn o celou řadu moderních funkcí.

 

TIS Firewall Toolkit vychází z představy použít firewall na klasickém operačním systému typu UNIX a vytvořit z něj jednopočítačový firewall. Filosoficky nám může vzniknout jedno z následujících zapojení:

·         Firewall se dvěma síťovými rozhraními, jedním do Internetu a druhým do vnitřní sítě. Toto řešení se dříve  nepovažovalo za  bezpečné, protože je použit neupravený operační systém UNIX, který by zajišťoval i bezpečnost na linkové vrstvě. Stránka: 31
Dnešní unixové systémy mají velmi sofistikované IP filtry, které na síťové i linkové vrstvě zajišťují bezpečnost velmi kvalitně. Např. Linux má svoje filtry ipchains a iptables, ve FreeBSD pak najdete velmi kvalitní IPFILTER a IPFIREWALL.

 

Obr. 5-40 TIS Firewall Toolkit

 

V dnešní době pokročilých směrovačů s propracovanou filtrací bych osobně použil na místo dvou směrovačů jeden směrovač s více rozhraními (obr. 5-41). Při porovnání s obr. 5-16 zjistíme, že jsme dospěli ke stejnému závěru jako při popisu ochrany vnitřní sítě pomocí filtrace.

 

 

 

Obr. 5-41 Použití směrovače s více rozhraními

Dnes se mnohým může zdát, že TIS Firewall Toolkit již zastaral, že je lépe koupit komerční firewall. Avšak historie se opakuje. Stále existuje početná skupina architektů, kteří si budou chtít svůj firewall ušít na míru. Tato skupina dnes často používá operační systém Linux nebo FreeBSD. V Linuxu je populární obdoba NAT označovaná jako maškaráda. Avšak i tito tvůrci dnes někdy sáhnou po některých komponentách z TIS Firewall Toolkitu a zkompilují si je. Pokud potřebují firewallem propustit protokol FTP, tak proxy je vždy lepší řešení a ve srovnání s reflexivními filtry kombinovanými s pasivním FTP je použití proxy z TIS Firewall Toolkitu velice elegantní. Drobnou komplikací je u TIS Firewall Toolkitu jeho licence, která neumožňuje přímo zasahovat do kódu ani jej distribuovat, natož pak vydělávat na komerční podpoře tohoto systému.

5.7.1                  Demilitarizované zóny

S DMZ jsme se již setkali. DMZ je síť chráněná filtrací, jež je omezeně dostupná jak z Internetu, tak i z vnitřní sítě. Na obr. 5-42 vidíme, že taková síť vzniká na třetím síťovém rozhraní firewallu. V případě, že použijeme filtraci na směrovači 1, pak jako další DMZ je síť s webovým serverem. Každá s těchto DMZ má jiné bezpečnostní charakteristiky.  Zatímco DMZ za třetím rozhraním firewallu je vhodná pro umístění aplikačních serverů, tak DMZ za směrovačem 1 je vhodná pro umístění webového serveru s informacemi o firmě.

 

 

Podobně se jako DMZ označuje i síť na obr. 5-42 s poštovním serverem. Tato síť již však není dostupná z Internetu. Toho lze využít k umístění serverů určených pro autentizaci či pro virovou ochranu apod.

 

Obr. 5-42 DMZ

Na DMZ zpravidla umísťujeme aplikační servery, abychom do Internetu zpřístupnili aplikace provozované ve vnitřní síti. Postupujeme přitom následovně: aplikace provozovaná ve vnitřní síti má informace uloženy v databázi. Tu část databáze, kterou potřebuje aplikační server na DMZ, v pravidelných  intervalech replikujeme do DMZ.

 

5.7.2                  Extranet

Zatím jsme se zabývali pouze oddělením vnitřní sítě od Internetu. Mnohdy je však potřebné propojit mezi sebou vnitřní sítě jednotlivých firem, tj. vytvořit mezi vnitřními sítěmi tzv. extranet.

 

Obr. 5-44 Extranet

Na obr. 5-44 je znázorněno řešení extranetu pomocí dvou firewallů. V každém případě je třeba mít oddělující prvek na straně každé firmy, tj. extranet neřešíme jedním firewallem společným pro obě firmy. Jsou pro to nejméně dva důvody:

 

 

5.8                 Interent FrontEnd

Vladislav Rameš

 

Zatímco v předchozích kapitolách jsme se zabývali zejména problematikou ochrany uzavřené sítě s tím, že „svým“ uživatelům chceme poskytnout maximum služeb, poskytovaných Internetem, nyní se pokusíme zaměřit na problém přesně opačný. Tím je v současnosti čím dál tím aktuálnější otázka, jak co nejefektivněji nabízet své služby klientovi, přistupujícímu z Internetu k aplikacím, jejichž zdroje jsou ve vnitřní síti. Přitom však nesmíme zapomenout na bezpečnost vnitřní sítě před útokem zvenčí.

 

Zároveň s tím je často nezbytné (zejména v případech elektronického bankovnictví) autentizovat klienta. Všechny tyto (často protichůdné) požadavky nám může pomoci splnit systém Internetový FrontEnd Virtual Vault, který na své hardwarové platformě dodává firma Hewlet Packard.

 

Pokud nahlédneme do česko-anglického slovníku, zjistíme, že slovo "Vault" může znamenat trezor, sklepení, anebo také žumpu. O tom, který z překladů je nejvýstižnější, nechť si čtenář udělá názor sám: v dalším textu se pokusím popsat činnost tohoto systému včetně jednoduchých příkladů konfigurace.

 

Systém je postaven na modifikovaném operačním systému HP-UX 11.00, což je víceméně typický představitel "BSD like" UNIXu. Modifikace pak spočívá v implementaci rysů tzv. „B-class security“. Zejména z marketingových důvodů (aby nebyl použitelný pro klienty, vyžadující o řád dražší systémy, splňující všechna kritéria příslušné normy) záměrně nejsou některé prvky B-class security implementovány. Konkrétně se jedná zejména o následující komponenty:

 

·         Síťová část systému: je pojata jako klasické TCP/IP, rozdělení na "compartmenty" (systémové rozdělení, které bude popsáno dále) je realizováno "natvrdo" až po vstupu dat do systému na základě přiřazení síťové komponenty (nebo obecně řečeno příslušného vstupně/výstupního rozhraní) tomu kterému compartmentu.

·         Grafická část (X-windows): Oficiálně není HP vůbec podporována, protože systém se v praxi instaluje na servery výkonnostní typové řady minimálně "L" class, ke kterým se nedodává grafická karta a jedinou administrativní komponentou pro systém by měl být sériový terminál. V praxi však CDE funguje, dokonce jsou terminálová okna jednotlivých "compartmentů" označena různými barvami. Jedná se však pouze o kosmetické úpravy, mezi různými "compartmenty" můžeme volně přes clipboard kopírovat data, což by nám klasický "B" class security systém neumožnil, a pokud využijeme příslušná privilegia a změníme "compartment", ke kterému náležíme, okraj okna to samozřejmě "nepozná".

·         Systém volitelně umožňuje činnost bez zapnutého auditu, respektive v případě nemožnosti auditu lze zvolit, zda se má systém zastavit nebo pouze ukončit auditing. Toto bývá využíváno při útocích na "C" class security systémy: hacker nejprve vyvolá událost, která způsobí masivní nárůst dat, která tvoří výstup auditu, poté vyčká na přetečení disku a pak již "beze stop" provede útok.

 

V rámci přesné specifikace terminologie, používané v této souvislosti v literatuře, je třeba si ujasnit následující termíny: Pod pojmem Virtual Vault si můžeme představit souhrn vlastního speciálního operačního systému plus  nadstavbu tohoto systému, zahrnující v sobě nástroje pro integraci hotových aplikací do uvedeného prostředí, pro správu a řízení tohoto systému přes webové rozhraní, modifikovaný webový server Netscape ePlanet a některé další nástroje. Vlastní upravený OS, na kterém tato nadstavba funguje, se v literatuře nazývá Virtual Vault Operation System (VVOS) a tyto dva termíny (VV – VVOS) bývají často zaměňovány. Pro úplnost dodejme, že v terminologii firmy HP je modifikace verze operačního systému označena ve verzi ukončením „.x4“, tč. hovořím o aktuální verzi 11.04.

 

V operačním systému"B-class" security jsou veškerá data rozdělena do tzv. compartmentů (oddělení), například letectvo, námořnictvo, pěchota apod. V našem případě se jedná o dva compartmenty: „Inside“ a „Outside“. Na základě tohoto rozdělení pak můžeme jednotlivá data ještě roztřídit do tzv. senzitivity levelů (doslovný překlad "úrovně citlivosti" zní alespoň pro mne poněkud matoucně, proto se v tomto případě budu držet původní anglické fráze). V operačních systémech „B-class security level“, využívaných zejména v armádě, je toto rozdělení dat použito obecně pro oddělení dat různého stupně senzitivity a stupně utajení. Například složka „letectvo“ je v rámci daného systému viditelná složce „letectvo-tajné“, ale nikoli naopak. Složky s atributem „námořnictvo“ nebo dokonce „námořnictvo-tajné“ nemohou sdílet data se složkami „letectvo“.  Pokud ano, tak pouze přes přesně definované programové rozhraní. Přecházet mezi těmito levely je umožněno pouze po přidělení určitých práv.

 

U „plnotučných“ operačních systémů třídy „B“ je toto oddělení dat natolik striktní, že například ani není možné překopírovat v X-windows přes clipboard data z okna  s atributem „letectvo“ do okna s atributem „námořnictvo“. Takto striktně ovšem VVOS nepracuje, ale přesto si musíme zvyknout na některé zvláštnosti – například, že uživatel „root“ zde není „všemocný“ jako ve většině ostatních UNIXových systémů, ale je pouze jedním ze souboru systémových uživatelů, z nichž každý má striktně vymezené pravomoci. Předpokládá se, že ve firmách, investujících do tak drahého software, jakým je Virtual Vault, bude i každého systémového uživatele představovat samostatný fyzický správce (obdobně jako například v bankovnictví je k otevření trezoru třeba minimálně dvou lidí: klíčníka, který má klíč, ale nikdy nesmí znát heslo, a likvidátora, který zná heslo, ale nikdy nesmí dostat do ruky klíč). Po korektním nainstalování a nakonfigurování systému je přesto doporučeno uživatele „root“ „penzionovat“ (retire), což je do verze VVOS 10.24 nevratná operace a po vlastních zkušenostech s administrací takovéhoto systému před tímto krokem varuji. V popisované verzi VVOS 11.04 je již tento krok vratný (on v podstatě byl vratný i v předchozích verzích - po restartu systému do jednouživatelského režimu a manuální editaci databází tcb), ale přesto si dle mého názoru tímto způsobem přivodíme pouze následné komplikace.

 

V rámci VVOS jsou implicitně použity  celkem čtyři system levely:

 

Představení si uspořádání těchto senzitivity levelů usnadňuje následující obrázek:

 

Obr. 5-49a VVOS

 

Princip obrázku tedy spočívá v tom, že „výše“ umístěné system levely mohou vidět „níže“ umístěné sytem levely. Podívejme se tedy nyní na to, jak celý tento systém vlastně pracuje:

 

Jak již bylo uvedeno v popisu jednotlivých systémových levelů, vlastní klientská webová stránka včetně webového serveru je umístěna na úrovni system, takže i v případě potenciálního průniku na vnější stranu systému je pro útočníka read only. Webové servery však běží na outside straně systému, a jsou tam logicky zapisovány i jejich logy. „Vnější“ síťová karta je tedy rovněž přiřazena senzitivity levelu „outside“. Při správně nakonfigurovaném Virtual Vaultu na „vnější“ straně nenaslouchá nic než porty webových serverů. Dokonce i DNS je možné z principu nakonfigurovat (tedy alespoň podle dokumentace k systému) pouze tak, aby se obracelo s dotazy na jmenné servery vnitřní sítě. Elektronická pošta je zpracováván rovněž serverem, umístěným na „vnitřní straně“. Na systému neběží program sendmail, nahrazuje jej primitivní poštovní klient mtasmtp. (Čtenář se nesmí nechat zmýlit tím, že systém reaguje na příkaz sendmail včetně obvyklých přepínačů: jedná se pouze o symbolický link na mtasmtp. Na tomto klientovi lze pouze nastavit smart relay, která vyřizuje veškeré mailové požadavky, a je vhodné čas od času daemonem cron vyčistit frontu mailových požadavků, s nimiž si mtasmtp nevěděl rady („klasické“ sendmail –q).)

 

Odtud je patrné, že i kdyby se potenciálnímu útočníkovi podařilo proniknout do Virtual Vaultu (což není u systému s rysy „B-class security“ zcela triviální), ocitne se na straně „outside“ a jeho případná destruktivní činnost může poškodit „pouze některé obrázky“ nebo části webových serverů, což jsou relativně bezcenná data, která jsou snadno obnovitelná z pásky. V tomto faktu spočívá největší „kouzlo“ systému Virtual Vault. Čtenáře jistě napadne otázka, jak je tedy vlastně realizována komunikace se scripty na vnitřní straně?

 

K tomuto účelu slouží relativně jednoduchý program, o kterém jsem se letmo zmínil již výše, nazývaný „důvěryhodná brána“ (‚trusted gateway agent“ alias „tga“). Tento program, který se spouští při startu systému jako daemon, je jediný legální prostředek, který dokáže „přeštítkovat“ data s atributem „outside“ na data s atributem „inside“ a zprostředkovat spuštění CGI scriptu na „vnitřní“ straně. Program tga je pochopitelně v seznamu ACL, a jakákoli změna jeho kontrolního součtu by způsobila vyhlášení poplachu. Mnohé čtenáře napadne, zda není slabé místo systému v tom, že šifrovaný SSL kanál končí na outside straně a odtud se holá data předávají důvěryhodné bráně. Dle dokumentace a vyjádření pracovníků HP je tento problém řešen tak, že běžící webový server i tga musejí mít komplementární systémová oprávnění, aby se TCP spojení mezi nimi mohlo uskutečnit, a toto je „v kompetenci“ jádra systému.

5.9                 Závěr

Na závěr je třeba  zdůraznit, že pro propojení naší podnikové sítě s Interentem je třeba vždy volit odpovídající prostředky.

 

Obr. 5-50 Připojení vnitřní sítě k Internetu

Na obr. 5-50 je znázorněno využití Firewallu a FrontEndu. Obě zařízení se připojují vzájemně paralelně. Firewall slouží:

 

Firewall se nehodí:

 

FrontEnd je určen pro: