Zpět  

Současnost a trendy řešení firewallů

Bezpečnost je dnes samostatné odvětví IT. Skládá se z řady technologií a produktů. Základem řešení bezpečnosti je však stále firewall. Ten původně chránil síť před nechtěným provozem. Například umožní přístup k webovému a poštovnímu serveru, veškerý další provoz je blokován. Postupně byly do firewallu integrovány mnohé další funkce. V prvé řade autentizace, to je ověření uživatele. Předtím než může uživatel přistupovat k síťovým zdrojům musí se přihlásit a ověřit, ať už vůči interní databázi uživatelů ve firewallu nebo externím serveru - LDAP, RADIUS atd. Z důvodu snadné integrace do sítě firewally dnes plnohodnotně podporují směrování (RIP, OSPF, BGP atd.). Samozřejmostí je integrace VPN (IPSec, PPTP, L2TP) do firewallu. Má to řadu praktických důvodů. Nejdůležitější je ten, že provoz z/do VPN tunelu může být současně prověřen firewallem. VPN provoz je šifrován a pokud by byl VPN koncentrátor za firewallem, mohl by se do sítě dostat nežádoucí provoz bez možnosti jeho ověření a blokování. V každém případě integrované řešení velice usnadňuje implementaci a zvyšuje bezpečnost. Neméně důležitá je i podpora QoS, kvality služby. V dnešní době je stále populárnější VoIP. Telefonovat mezi pobočkami, ať už přes pevné linky nebo VPN bez QoS prakticky není možné. Nesprávná volba firewallu může implementaci a provozování podobných aplikací znemožnit.

Dnešní firewall je tedy zpravidla multifunkční zařízení, schopné plnit řadu funkcí. Jak však funguje samotný firewall a jaké jsou současné trendy vývoje?

Slovo firewall usnadňuje prodej, takže není divu, že se často jedná více o marketing, než o technické parametry. Z tohoto důvodu je dobré vědět, co vše lze od firewallu očekávat. Z hlediska bezpečnosti představuje nejnižší kategorii paketový filtr. Ten dokáže na základě zdrojové a cílové IP adresy eventuálně TCP/UDP portu blokovat jednotlivé pakety. To dnes umí v podstatě průměrný směrovač a úroveň bezpečnosti je minimální. Problém je v tom, že nedokáže z jednotlivých paketů sestavit spojení. To umí až stavový firewall (statefull inspection). Umí přiřadit pakety příslušnému spojení, viz obr.1. Díky tomu například rozpozná, že se jedná o pakety vracející se do sítě v rámci spojení, které bylo navázáno zevnitř. Úroveň bezpečnosti je mnohem vyšší. Dokáže odhalit například spoofing, tj. útok založený právě na tom, že se pakety odeslané útočníkem "vracejí" do sítě. Třetí kategorii podle klasického dělení je proxy neboli aplikační brána. Toto zařízení pracuje na aplikační úrovni. Jinými slovy rozumí konkrétním aplikacím (http, telnet, ftp atd.), ukončují spojení od klienta a směrem k serveru navazují úplně nové. Znamená to, že musí obsahovat jak klienta tak i server pro všechny podporované aplikace. Míra bezpečnosti pro konkrétní aplikace je velice vysoká. Nevýhodou je podpora omezené množiny aplikací a menší výkon. Nelze obecně říct, že aplikační brána je lepší nebo horší než stavový firewall. Aplikační brána může poskytovat menší ochranu před útoky na síťové vrstvě. Jde o to, co je potřeba řešit. Obě řešení se často kombinují.

Firewally se začaly implementovat v 90. letech minulého století a postupem času dosáhly téměř dokonalosti při ochraně před nebezpečím typickým v té době, tj. proti neoprávněnému přístupu do sítě. Samozřejmě tyto techniky a možnosti se využívají stále, ale v dnešní době se čím dál více útoků odehrává na sedmé tj. aplikační vrstvě. Využívá se bezpečnostních nedostatků konkrétních aplikací - IIS nebo Apache web serverů, poštovních aplikací atd. Tento typ útoků je na síťové vrstvě nedetekovatelný a ani aplikační brána nemůže vědět například o riziku přetečení zásobníku (buffer overflow) v konkrétní aplikaci.

Přístup jednotlivých výrobců se v drobnostech může lišit, ale trend je obecný. Popis vychází z řešení Juniper Networks. První krok posílení bezpečnosti je posílení stavové inspekce tak, aby i tento typ firewallu rozuměl aplikacím. Řada aplikací navazuje spojením na jiném TCP/UDP portu než přenáší data (například FTP). Některé pak kombinují dokonce více protokolů. Příkladem může být VoIP, kdy signalizační protokoly jsou prakticky nezávislé na samotném přenosu hlasu (RTP). Pokud firewall takové aplikaci nerozumí, musí mít otevřeny veškeré možné porty, na kterých může komunikovat a těch může být tisíce. To představuje velké bezpečnostní riziko. Proto je většina současných, alespoň těch dobrých firewallů hybridních. Přesněji řečeno dokážou sledovat navazování spojení u tohoto typu aplikací a dynamicky otevřít pouze domluvené porty pro konkrétní spojení. Jedná se stále o stavovou inspekci, spojení není přerušeno, jako u proxy řešení je pouze sledován jeho průběh od navázání až po ukončení. ALG (Application Level Gateway) tak kombinuje výkon a výhody (například možnost redundantního zapojení) stavových firewallů s porozuměním komunikace i na aplikační vrstvě.

Obr. 1 Před čím chrání jednotlivé typy produktů

Stále však platí, že ani ALG nemůže v principu vědět nic o bezpečnostních nedostatcích konkrétních aplikací. Pokud příliš dlouhé URL způsobí přetečení zásobníku nebo umožní přístup k systémovým adresářům, je to z pohledu firewallu legální HTTP provoz. Před tímto rizikem dokáže ochránit samostatná kategorie produktů - jednak starší a dnes už poněkud zastaralé systémy detekce průniku (IDS - Intrusion Detection System) a novější systémy prevence průniku (IPS - Intrusion Prevention System). Ty nejlepší firewally mají dnes integrovaný systém prevence průniku přímo v sobě, jedná se o deep packet inspection.

Není od věci ve stručnosti popsat, jak funguje IDS a IPS. Pomůže to lépe pochopit přínosy deep packet inspection. IDS je pasivní zařízení. Provoz je na něj zpravidla "kopírován" pomocí funkce copy port/port mirroring na přepínači. IDS naslouchá provozu a vyhledává příznaky útoků. Co se stane, pokud je detekován útok?

IDS může informovat firewall o probíhajícím útoku (firewall signaling),a ten zablokuje provoz z dané zdrojové adresy. Takové řešení má dvě zásadní nevýhody. Jak bylo řečeno, provoz na IDS je kopírován, tzn. zároveň pokračuje dále do sítě. Část paketů tak dorazí k cílovému serveru dříve než firewall provoz zablokuje. Je tedy nutno zjistit, zda došlo k nějakým škodám. Zadruhé firewall zablokuje veškerý provoz z dané zdrojové IP adresy. Za touto adresou se může skrývat - díky překladu adres - nejen útočník, ale i řada dalších uživatelů internetu. Příkladem může být síť AOL, kdy řadově milióny uživatelů této sítě přistupují do zbytku internetu přes mega-proxy s jedinou IP adresou. Firewall tak zablokuje útok, ale zablokuje i veškerý další legální provoz z dané adresy. Druhá možnost, kterou IDS může využít, je vyslat TCP reset. To je pochopitelně omezeno pouze na TCP provoz. Opět platí, že útok je detekován až v jeho průběhu a je tudíž nutno prošetřit škody. Na druhou stranu je blokován pouze provoz týkající se daného útoku.

IPS se na rozdíl od IDS nasazuje in-line, podobně jako firewall. Díky tomu přes něj musí projít veškerý provoz, není závislé na jiných zařízeních a útok může okamžitě blokovat tak, že zahazuje výhradně "špatný" provoz.

Jak lze útoky na aplikační vrstvě detekovat? Zde není zásadní rozdíl mezi IDS, IPS nebo deep packet inspection. Základní metodou je packet signatures, tj. vyhledávání známého řetězce znaků v toku dat. De facto stejně funguje antivir. Tato metoda má jednu nevýhodu a to riziko falešných alarmů, tzv. false positives. Jednoduchý příklad, pokud bude řetězec detekován během navazování spojení poštovního klienta se serverem, jedná se o útok. Pokud bude řetězec nalezen v těle mailu, může se jednat o popis útoku a alarm bude falešný. Juniper Networks tuto metodu vylepšila na statefull signatures. Příslušný řetězec je detekován výhradně v okamžiku, kdy se může konkrétní útok odehrát, například právě při navazování spojení. Přesnost metody se zvýší a pozitivně se to projeví i na výkonu. Nicméně je zřejmé, že takto lze detekovat pouze známé útoky. Z tohoto důvodu je jedna detekční metoda málo. Dobrá řešení proto podporují více metod. Nejčastěji se jedná o detekci protokolových anomálií. Tok dat je porovnán s definicí daného protokolu a pokud se liší například délka odpovědi při navazování spojení, může takto být detekován i neznámý útok.

Obr. 2 Analýza provozu i deep packet inspection

Tato činnost je mimořádně náročná na výkon zařízení. Je nutné z jednotlivých paketů sestavit spojení, poradit si s defragmentací paketů, s duplikací a překryvem paketů. Dále provést normalizaci a zajistit jednoznačnou prezentaci dat. Následně porovnat s definicí protokolu (RFC) a rozdělit vše do jednotlivých částí - například adresy v mailu, subject, tělo mailu a příloha, viz obr.2. Jinými slovy je potřeba, aby data byla „pochopena“ stejným způsobem jako u cíle respektive adresáta.

Obr. 3 Konfigurace deep inspection

Důležitá je i flexibilita z hlediska před čím a jak jednotlivé části sítě, servery a objekty chránit. To znamená, že pouze vypnout a zapnout deep packet inspection je nedostatečné a mimo jiné to má velice nepříznivý vliv na výkon zařízení. Není nutné chránit síť před útoky vůči Exchange serverům, pokud používáte pouze Lotus Notes a naopak. Nebo v síti může být vlastní aplikace a je vhodné mít možnost doplnit vlastní signatures nebo i upravit detekci anomálií. U řady firewallů NetScreen společnosti Juniper Networks je přístup velice flexibilní. Rozhraní, ať už fyzická (ethernet porty) nebo logická (VLAN rozhraní) jsou přiřazena do bezpečnostních zón (trust, untrust, DMZ atd.). V rámci zón lze definovat objekty (web server, poštovní server, PC1 atd.). Stejně tak lze definovat objekty pro aplikace (mail, web, Oracle atd.). Objekty lze sdružit i do skupin. Pravidla komunikace lze pak definovat mezi bezpečnostními zónami a lze i definovat konkrétní pravidla vůči konkrétnímu objektu nebo skupině objektů v rámci zóny. Pokud si dáme práci s definováním objektů, lze pak definovat velice srozumitelná a logická pravidla, například z internetu přístup pouze HTTP na web server 1 v zóně DMZ. V okamžiku, kdy je provoz povolen, lze na úrovni jednotlivých pravidel zapnout deep packet inspection. A nejen to, je možné i explicitně říci, vůči kterým útokům bude daný objekt chráněn, a to až do úrovně jednotlivých signatures nebo anomálií, viz obr.3. Každá síť je jiná a okamžitě začít blokovat provoz může způsobit problémy. Řada aplikací se nedrží příliš striktně standardu apod. Proto je vhodné nejdříve zjistit, co v síti běhá a zda nebude blokován i provoz, který je v pořádku. Z toho důvodu existuje u deep packet inspection možnost určit způsob reakce, pouze monitorovat nebo i blokovat. Monitorování spolu s logováním událostí usnadní jak implementaci, tak vyhodnocení toho, co se v síti děje. Signatures jsou navíc v čitelné podobě a s odkazem na popis konkrétního rizika. Pomocí centrálního managementu (NSM - NetScreen Security Management) lze získat kompletní obraz aktuálního stavu sítě i z více zařízení, viz obr. 4.

Obr. 4 Centrální přehled L7 útoků

Různá rizika a nové útoky se objevují prakticky denně. Proto jsou mimořádně důležité i pravidelné update databáze signatures. V případě Juniper Networks se jedná o týdenní update plus okamžité, pokud se jedná o kritické útoky (MSBlaster, Nimda apod.). Bez nich by jednalo o polovičaté řešení. Logické je oddělení update této databáze o upgrade firmware.

Na závěr k častému dotazu, kdy je vhodné zvolit IPS, kdy deep packet inspection a jaký je v tom rozdíl? Pokud se jedná o běžnou internetovou komunikaci (ftp, http, DNS, poštovní protokoly - POP3, IMAP, SMTP), bezpečnost vzdálených poboček, jde o prakticky shodné řešení. Pro velké centrály a datová centra, kde je potřeba velký výkon a podpora desítek protokolů (na příklad různé databáze), je vhodnější nasadit dva samostatné produkty, viz obr. 5.

Obr. 5 Kde nasadit IPS a deep packet inspection


-Petr Lasek-