Vysoce dostupný firewall na Linuxu

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.