Shorewall - snazší cesta k tvorbě firewallu

10.6.2010 09:10 | Přečteno: 3335× | Počítače | | poslední úprava: 11.6.2010 11:23

S několika servery jsem převzal do správy i firewall nastavený přes shorewall. To si předělám na svůj vlastní systém, byla první věc, co mě napadla. Ale nepředělám. Nastudoval jsem si shorewall. Přece jen - nastavení je jednodušší (nižší pravděpodobnost chyby) a spousta věcí, o které jsem se musel starat sám, se shorewallem odpadá.

Shorewall tvoří několik souborů s různými parametry a pravidly. Z těch se pak při startu systému (z init skriptů) nebo při změně (make) vygenerují a zavedou do kernelu pravidla iptables.

Konfigurace

K vytvoření jednoduchého firewallu pro malou firmu nebo domácí síť stačí několik málo souborů.

params

Soubor není zcela nezbytný, ale dovede usnadnit tvorbu složitějších pravidel. V tomto souboru můžeme definovat různé proměnné, které lze později použít v pravidlech, například:

HTTP=10.10.1.100        # adresa vnitřního HTTP serveru
OUTER=93.231.291.257    # adresa vnějšího (internetového) síťového rozhraní
OUTER_DEV=eth0
INNER_DEV=eth1

masq

Nastavení maškarády nebo SNAT na výstupním síťovém rozhraní. Jaký je rozdíl mezi MASQUERADE a SNAT? SNAT si pamatuje všechna spojení a při krátkodobém výpadku linky je schopné pokračovat v práci jakoby se nechumelilo. Adresa pro SNAT musí být zadaná v parametrech. SNAT použijte, pokud máte pevnou linku. MASQUERADE při výpadku linky zruší všechna spojení a je třeba vytvořit spojení znovu. Adresu si MASQUERADE zjišťuje pokaždé v kernelu (pomalejší). MASQUERADE použijte, jste-li připojení například přes modem protokolem PPP a internetová adresa je vám přidělovaná dynamicky.

V souboru stačí obvykle jediný řádek. Pro mne je výhodné, jsou-li konkrétní hodnoty nahrazené symbolickými hodnotami (ty jsou nastavené v souboru params). Takto vypadá soubor pro SNAT:

$OUTER_DEV  $INNER_DEV   $OUTER 

A takto vypadá soubor pro MASQUERADE:

$OUTER_DEV  $INNER_DEV 

Vyberte si samozřejmě pouze jednu podobu podle vašich potřeb.

interfaces

Pro jednoduchý firewall se dvěma síťovými kartami stačí jednoduchý soubor interfaces (konkrétní hodnoty jsou opět nahrazené symbolickými hodnotami ze souboru params):

net     $OUTER_DEV  detect
loc     $INNER_DEV  detect  routeback

Hodnoty net a loc jsou názvy zón - na vnějším ($OUTER_DEV) rozhraní je pověšená zóna net, na vnitřním rozhraní zóna loc. Klíčové slovo detect znamená, že broadcast adresa se najde automaticky. Pro vnitřní rozhraní může být důležitá hodnota routeback - povoluje se tímto routování z vnitřní sítě do vnitřní sítě. Může to být důležité, máte-li ve vnitřní síti služby, ke kterým přistupujete přes router (například HTTP server a podobně).

policy

Nastavení defaultní politiky. Na svých firewallech obvykle vždy nastavuji DROP či REJECT, ale pro jednoduché firewally to může být někdy dost těžký kanón - v takovém případě je vše zakázané a funguje pouze to, co se výslovně povolí v souboru rules. Ošetřit je třeba všechny směry:

loc   net   REJECT         # Vše z vnitřní sítě do internetu se zakáže
net   loc   DROP    info   # Vše z venku dovnitř se zahodí a zaloguje

$FW   loc   ACCEPT         # Vše z firewallu do vnitřní sítě se povolí
loc   $FW   REJECT         # Vše z vnitřní sítě na firewall se zakáže

$FW   net   ACCEPT         # Vše z firewallu ven se povolí
net   $FW   DROP           # Vše z internetu na firewall se zahodí

all   all   DROP    info   # Vše ostatní se zahodí a zaloguje

zones

Zde jsou definované jednotlivé zóny (internet, vnitřní síť, firewall a případně demilitarizovaná zóna). Soubor je ve své základní podobě velmi jednoduchý:

net ipv4
loc ipv4
fw  firewall

rules

Soubor s jednotlivými pravidly. Zde je to pravé místo, kde se můžeme vyřádit. Pravidla jsou rozdělená do různých sekcí, obvykle nás bude zajímat pouze sekce NEW (pravidla budeme psát za řádek SECTION NEW).

V souboru lze používat makra. To je fajn myšlenka, ale pouze do chvíle, než začneme psát jednoduchá pravidla pro DNAT. Pak to kdosi nedomyslel (nebo mi něco uniklo) a generovaná pravidla pro iptables hraničí s nepoužitelností (ale jo, chápu, proč to tak asi je). Bez komentáře se proto použití maker na nevhodném místě (DNAT) vyhnu. Makrem je v souboru například zápis Ping/ACCEPT (nemusíme se starat, jak vyjádřit v jazyce shorewall ping).

# Z vnější sítě na FW
Ping/ACCEPT         net         $FW
SSH/ACCEPT          net         $FW

# Z vnitřní sítě na FW
Ping/ACCEPT         loc         $FW
SSH/ACCEPT          loc         $FW

# Z vnitřní sítě ven
# Hodně restriktivní firewall 
SSH/ACCEPT          loc         net
Ping/ACCEPT         loc         net
Web/ACCEPT          loc         net
Jabberd/ACCEPT      loc         net
IMAP/ACCEPT         loc         net
IMAPS/ACCEPT        loc         net
POP3/ACCEPT         loc         net
POP3S/ACCEPT        loc         net

Pravidla pro provoz z vnější sítě dovnitř potřebují bližší vysvětlení. Provoz, který je iniciován zevnitř, je povolený automaticky. Kromě toho ale často vyvstává problém povolit různé služby (webový server) a zajistit, aby byla taková služba přístupná jak z internetu, tak z vnitřní sítě. Kromě toho musí být taková služba přístupná z obou sítí stejně. Nelze mít server http://bravenec.org/ přístupný z internetu normální URL adresou http://bravenec.org/ a z vnitřní sítě adresou http://10.10.1.100/ - u protokolu http by vám to obvykle apache sedící ve svém digitálním vigvamu neodpustil. Ale jedno už je to třeba poště - ale ani zde není důvod přistupovat ke službě jinak zvenku a jinak zevnitř (konfigurovat poštu na notebooku dvakrát denně je pěkný opruz).

# Služby
DNAT    net     loc:$HTTP   tcp   80    -    $OUTER
DNAT    loc     loc:$HTTP   tcp   80    -    $OUTER

Shorewall je natolik inteligentní, že jedním pravidlem (DNAT loc...) pro vnitřní síť nastaví jak forwading z vnitřní sítě do vnitřní sítě, tak i potřebný SNAT. Bohužel není shorewall natolik inteligentní, že nelze napsat pravidlo DNAT v jeho zjednodušené podobě (jak je popsané v dokumentaci k shorewall). Pokud totiž neuvedete adresu $OUTER, shorewall vygeneruje pravidlo bez této adresy a přesměruje pak veškerý provoz na portu 80 dovnitř sítě - provoz pro váš http jde na váš vnitřní server (v pořádku), provoz pro pro microsoft.com jde na váš vnitřní server (v pořádku???), provoz pro google jde na váš vnitřní server (život bez google?). Ale co je nejhorší, i provoz na vaši oblíbenou pornosajtu jde na váš vnitřní server. A to už v pořádku sakra není!

Ale pokud potřebujete mít službu přístupnou pouze z venku, nic vám nebrání zapsat pravidlo jednodušeji:

# Služby
HTTP/DNAT   net     loc:$HTTP

Přeložení, spuštění

Konfigurace je hotová, můžeme pravidla přeložit příkazem make.

Nezapomeňte zajistit, aby se shorewall startoval při spuštění systému (initskripty). To už záleží na distribuci, já to v Gentoo zajistím takto:

rc-update shorewall add default

A nakonec nezbytný odkaz na domácí stránku: http://www.shorewall.net

Jo - a ještě se možná musím předem omluvit za případné chyby či nepřesnosti. Před 24 hodinami jsem shorewall prakticky neviděl.

       

Komentáře

[houska]

HTTP=10.10.1.100        # adresa vnitřního HTTP serveru
OUTER=93.231.291.257    # adresa vnějšího (internetového) síťového rozhraní

za pul roku nebudes vedet co je "OUTER" - jestli rozhrani, ipcko, nejakej server... o "HTTP" ani nemluvim ;)

[Petr Bravenec]

Pravděpodobně to vědět budu, protože to jsou zkratky, které v iptables pravidlech používám nějakých deset let. Jsem na ně zvyklý.

[CEST]

Takze hrajes na vendor lock-in? Pokud by to mel nekdo po tobe prevzit nebo za tebe zakocit, tak pro nej bude jednodussi a zrejme i rychlejsi z vypisu iptables -nvL udelat v nejakym obecnym nastroji (at uz to bude fwbuilder, pfSense nebo IPcop) novej firewall, nez zjistovat, co ktera promenna vlastne dela a jestli muze zmenit tamtu promennou tak, aby to udelalo to, co opravdu chce a ne tisic dalsich veci, ktery nechce.

Proto mam taky radsi cisty iptables, protoze to je proste standard. Kazdej, kdo dela FW na linuxu bude iptables na 99% umet. Kdyz neco ubastlim ve fwbuilderu/pfSense/m0n0wall/IPcop, bude si to ten nekdo muset trosku nastudovat, ale tyhle nastroje jsou urceny k tomu, aby se s tim delalo jednoduse, takze udelat zmenu by melo byt pro FW odbornika i bez znalosti konkretniho produktu jednoduche. Ale pochopeni ciziho skriptu bude asi slozitejsi.

[Petr Bravenec]

Proměnné a jiné různé symbolické hodnoty se používají poměrně běžně a s oblibou. Všude. V programech, ve skriptech, v parametrech. I v iptables. Rozhodně je čitelnější napsat https než 443. Co je na tom špatně? Navíc takový FW napsaný pomocí proměnných v shorewall nebo přímo v iptables je pružnější. Při přenosu na jiný počítač stačí přepsat pár proměnných (komentovaných) a restartovat. Při přesunu služby stačí přepsat proměnnou a restartovat. Nemusím hledat, kde všude se IP adresa vyskytuje. Přímo v iptables by to bylo v pravidlech out-in, in-in, pre-in, pre-out, in-post, dmz-in, in-dmz... je jedno co to znamená, jen tak z hlavy jsem si vzpomenul na sedm míst pro nastavení jediné služby.

Shorewall jsem zdědil. Uvažoval jsem o nahrazení čistě iptables. Ale nemá to smysl, shorewall je výhodnější - dobře zdokumentovaný, rozšířený, poměrně přehledný a ve srovnání s iptables nepoměrně pružnější.

[Petr Bravenec]

Člověče, tak mě napadá... ty jsi viděl shorewall nebo víš aspoň vůbec, o čem je řeč, když - cituji - "pochopení cizího skriptu bude asi složitější"? Shorewall není "cizí" není "skript". Takto se dalo argumentovat u mého včerejšího zápisku:

http://www.abclinuxu.cz/blog/Bravenec/2010/6/skripty-pro-firewall

[KluceoveSlova]

Jednoznacne PfSense je najlepsi hned po IPCop...

[Petr Bravenec]

Jenže PfSense je klikací a IPCop je něco úplně jiného.

[Visgean Skeloru]

Hmm a co říkáte na Vuurmuur? Osobně s ním mám dobré zkušenosti ale zas tak se v tomhle nevyznám...

[Petr Bravenec]

Klikací

Tedy abych nekřivdil - GUI je v ncurses, pravděpodobně to myší nebude ovladatalné.

Kde se bere má nechuť ke klikacím nástrojům:

Plusy GUI:

• Snadné nastavení i pro lamu.
• Odborník si nemusí pamatovat nebo studovat příkazy iptables.

Minusy GUI:

• Snadné nastavení i pro lamu.
• Odborník si musí pamatovat nebo studovat příkazy iptables.
• Odborník musí vědět, jak přečurat gui.
• Obvykle nelze rozumně komentovat (jako například registry windows).
• Obvykle nelze kus "zakomentovat", je potřeba celý kus smazat (jako například registry windows).
• Jsem zvyklý číst písmenka, nerozumím obrázkům.
• Nefunguje na systémech z roku 2003 s Pentiem a 64MB RAM

Mám na starosti více serverů a je pro mě výhoda překopírovat na server šablonu (s komentáři a s návodem), upravit pár proměnných (OUTER, OUTER_DEV, HTTP....) a spustit. Pro archivaci změn a testování nových funkcí mohu snadno nasadit git (verzovací systém). Minusů má GUI jednoznačně více.

[Visgean Skeloru]

Tak to 'klikátko' (ono to není klikátko) pouze edituje nějaké svoje soubory a ty pak můžete taky synchronizovat podle libosti.. Vuurmuur toho umí docela hodně, někdy to zkuste :) (a nebo třeba nezkoušejte :)) )

Mimochodem, dobrý nápad synchronizovat konfiguráky pomocí gitu.

[SPM]

Tak jsem si to teď zkusil nainstalovat, akorát jak se tak koukám do jejich roadmapy, tak to vypadá, že neumí IPv6 a ještě asi docela dlouho umět nebude... :-/

[Petr Bravenec]

V první chvíli jsem se vyděsil, že by se to snad mělo týkat shorewall. Koukal jsem do repozitáře, balík shorewall6 tam mám... pak mi došlo, že se to týká zřejmě vuurmuur.

[SPM]

Přesně tak; u shorewallu bych nepředpokládal, že by tam nebyla :) Btw nezkoušel jste to? Jde mi o to, jestli configy shorewallu jsou pro IPv4 a IPv6 stejné nebo je to také striktně oddělené?

[Petr Bravenec]

Nezkoušel jsem to. Já s IPv6 zatím jen tak laškuju...

[Petr Bravenec]

Ještě jsem tam objevil chybu. V nastavení služeb bylo původně uvedeno:

# Služby
DNAT    net     loc:$HTTP   tcp   80    80    $OUTER
DNAT    loc     loc:$HTTP   tcp   80    80    $OUTER

Není to vyloženě špatně, ale uvedená služba (HTTP) by pracovala pouze v případě, že by byl zdrojový port také 80, což obecně nebývá. Opravil jsem to na:

# Služby
DNAT    net     loc:$HTTP   tcp   80    -    $OUTER
DNAT    loc     loc:$HTTP   tcp   80    -    $OUTER