Vysoce dostupný firewall na Linuxu

Michal Filka 1. 11. 2007

Každá slušná počítačová síť má vlastní firewall. Ten brání neoprávněnému vstupu do sítě, ale také obvykle určuje pravidla komunikace uživatelům uvnitř. Takový firewall je však kritickým místem celé sítě a pokud by došlo k jeho výpadku, přeruší se komunikace s ostatními sítěmi. Jak tomu zabránit?

Motivace

Představme si, že stojíme před problémem zabezpečit spojení jednoho či více počítačů připojených do nějaké vnější sítě. Pojmem zabezpečit rozumíme mít kontrolu nad spojeními, která jsou s těmito počítači navazována a naopak. Typické je řešení pomocí firewallu.

Firewall je bod v síti, který je zodpovědný za komunikaci s vnějším světem. Podle definovaných pravidel rozlišuje provoz na povolený a zakázaný. Může se jednat o specializované kusy hardware, často se ale jedná o běžná pc s operačním systémem (OS) Linux. Pokud situace v síti vypadá tak, jak bylo právě popsáno, pak jsme si do sítě zanesli bod, jehož chyba je kritická pro veškerou komunikaci s vnějším světem.

V této souvislosti se hovoří o „single point of failure“ – díky selhání jednoho zařízení dojde ke kolapsu komunikace s vnějším světem. Tématem tohoto článku je, jak zlepšit spolehlivost komunikace s vnějším světem pomocí fyzické redundance firewallu. Popsané řešení bylo a je provozováno na architektuře i386 s OS Linux – Debian Etch.

Kde je problém?

Nyní je potřeba představit ty části a vlastnosti OS Linux, které jsou pro nastavení vysoce dostupného firewallu důležité. Místy bude popis značně zjednodušený – pro účely tohoto článku postačí hrubá představa, půjde spíše o popis konceptu než konkrétních detailů.

V linuxu se o funkce firewallu – jmenovitě o nastavování logiky firewallu – stará aplikace známá jako iptables. Tato aplikace pracuje s prostředky jádra poskytovanými projektem netfilter, který je zodpovědný za část průchodu paketu jádrem. Zjednodušeně řečeno je paket během své cesty skrz jádro konfrontován typicky s několika „kontrolními“ body (detailní informace lze nalézt na NetFilter.org), ve kterých se rozhoduje o jeho dalším osudu. Jednou z aplikací, která těchto „kontrolních“ bodů využívá, jsou právě iptables.

Pokud si definujete pomocí iptables nějaké pravidlo, je součástí definice, ve kterém bodě se toto pravidlo provádí – v iptables se tyto body označují jako chain(s). Doposud z hlediska redundantního firewallu není žádný problém – stačí na záložním stroji nějakým způsobem zadat stejnou skupinu pravidel a vše je v pořádku.

První problém vychází z toho, že iptables jsou stavový firewall, tudíž nepracují s pakety odděleně, ale zkoumají je v širších souvislostech. Například si pamatují aktuální stav nějakého TCP sezení (session), jsou schopny rozhodnout, zda právě zpracovávaný paket do tohoto spojení patří, a na základě toho nějak reagovat.

Iptables tedy pracují s konkrétními spojeními. Aby nebylo nutné každý paket spojení nechat zpracovat sadou definovaných pravidel, ukládají si iptables své rozhodnutí pro dané spojení do své části nazývané conntrack. Pokud chceme, aby v případě přepnutí z primáru na záložní firewall zůstaly všechny spoje funkční, je nutné zálohovat tuto tabulku. Velmi jednoduše řečeno při vytváření spojení se k pravidlům iptables dostane pouze úvod tohoto spojení. Jakmile se podaří spojení úspěšně sestavit, je o něm udělán záznam v conntrack tabulce, další pakety spojení se k pravidlům již nedostanou a postupují touto známou cestou.

Pokud po vytvoření spojení dojde k přepnutí na záložní firewall, který o existenci tohoto spojení neví, komunikace prováděná přenášená tímto spojem spadne. Jednoduchý příklad k tomuto tématu: Řekněme, že všechny počítače jsou k vnějšímu světu připojeny prostřednictvím NAT (například připojení privátní sítě k internetu s jednou veřejnou ip adresou). Vytvořme jednoduché pravidlo pro tcp spojení – SNAT (S), který původní zdrojovou adresu přeloží na adresu F2, kde F2 je vnější adresa firewallu (F).

Vytvořme nyní z počítače A TCP spojení přes F na počítač C. Pokud se spojení podaří sestavit, můžou spolu A a C nerušeně komunikovat. Pokud během komunikace smažeme na F pravidlo S, bude komunikace dále fungovat. A to proto, že během začátku TCP spojení si F zapamatoval zpracování této TCP session v conntrack table a S není pro další zpracování provozu potřeba. Pokud bychom ale chtěli vytvořit nové spojení, jako například přístup na jiný web server přes F, už by se to nepodařilo.

To je podobné případu přepnutí na záložní firewall, kdy by nebyly synchronizované conntrack tabulky. V takový okamžik začne záložní firewall dostávat pakety z prostředku TCP session, očekává tedy, že má v conntrack tabulce uloženo zpracování pro odpovídající spojení. V tomto případě ale pakety žádnému jemu známému spojení neodpovídají a nebude je tedy umět zpracovat.

Druhý problém je, jak zajistit dostupnost záložního stroje v případě výpadku primárního. Z principu ip sítě musí mít primární a záložní stroj jinou ip adresu. Jak tedy postupovat v případě výpadku primárního – jak se vlastně vnitřní síť dozví o nové ip adrese pro odchozí provoz? Předefinovat ve vnitřní síti u všech počítačů adresy pro odchozí provoz? Nebo naopak v okamžiku, kdy víme, že primární stroj je nedostupný, předefinovat ip adresy používané u sekundárního? Jak vůbec výpadek primáru detekovat?

Závěr

Tento článek měl posloužit pouze pro získání představy o tom, co je potřeba uvažovat při budování vysoce dostupného firewallu. Konkrétní řešení budou představena příště. Motivací pro zájemce budiž to, že řešení existuje, a to dokonce pomocí volně dostupného software.

Anketa

Máte na sítí firewall?

Našli jste v článku chybu?
Podnikatel.cz: Místa, kde hází podnikání klacky pod nohy

Místa, kde hází podnikání klacky pod nohy

120na80.cz: I tuto vodu můžete pít

I tuto vodu můžete pít

Vitalia.cz: Petra Pospěchová: Na túrách bodne desinfekční panák

Petra Pospěchová: Na túrách bodne desinfekční panák

Měšec.cz: TEST: Vyzkoušeli jsme pražské taxikáře

TEST: Vyzkoušeli jsme pražské taxikáře

Měšec.cz: Ceny PHM v Evropě. Finty na úspory

Ceny PHM v Evropě. Finty na úspory

Lupa.cz: Japonská invaze. Proč SoftBank kupuje ARM?

Japonská invaze. Proč SoftBank kupuje ARM?

Lupa.cz: IT scéna po brexitu: přijde exodus vývojářů?

IT scéna po brexitu: přijde exodus vývojářů?

Vitalia.cz: Tohle je Břicháč Tom, co zhubnul 27 kg

Tohle je Břicháč Tom, co zhubnul 27 kg

DigiZone.cz: Kauza technik: oficiální vyjádření Novy

Kauza technik: oficiální vyjádření Novy

Měšec.cz: Banky umí platby na kartu, jen to neříkají

Banky umí platby na kartu, jen to neříkají

Podnikatel.cz: Fotogalerie: Jesenka už má skoro 50 let

Fotogalerie: Jesenka už má skoro 50 let

Měšec.cz: Se stavebkem k soudu už (většinou) nemusíte

Se stavebkem k soudu už (většinou) nemusíte

Podnikatel.cz: 3 velké průšvihy obchodních řetězců

3 velké průšvihy obchodních řetězců

Podnikatel.cz: Polská vejce na českém pultu Albertu

Polská vejce na českém pultu Albertu

DigiZone.cz: Oživení ekonomiky by mělo navýšit reklamu

Oživení ekonomiky by mělo navýšit reklamu

DigiZone.cz: Sázka na e-sporty stanici Prima vychází

Sázka na e-sporty stanici Prima vychází

Podnikatel.cz: Přiznal prodej padělků. Pokuta ho nemine

Přiznal prodej padělků. Pokuta ho nemine

Lupa.cz: Největší torrentový web KickassTorrents padl

Největší torrentový web KickassTorrents padl

Lupa.cz: eIDAS: Nepřehnali jsme to s výjimkami?

eIDAS: Nepřehnali jsme to s výjimkami?

Vitalia.cz: Pepsi Cola mění sirup za cukr

Pepsi Cola mění sirup za cukr