Předchozí
Následující

Firewall

Design a bezpečnost

V tomto bodě máme probrané všechny základní technické aspekty Linuxového firewallu. Ještě ale nepadlo ani slovo o tom, co mají pravidla vyjadřovat.

Základní poučka v počítačové bezpečnosti je, že výchozí stav by měl být takový, že je všechno zakázáno a z toho se pak udělují výjimky pro aplikace a opodstatněné případy. Tento přístup by se dal ve firewallu snadno přenést do výchozích akcí drop ve všech řetězcích a do povolování výjimek pro konkrétní datové toky. Tento způsob by byl ovšem extrémní a spíš má smysl zkoncentrovat snahu o zabezpečení do řetězců v tabulce filter. V nich by opravdu měla být výchozí akce drop a uživatel by měl definovat datové toky, které potřebuje a ty pak explicitně povolit.

Pochopitelně pro pracovní stanici jsou požadavky docela jiné než pro server, který poskytuje konkrétní aplikaci přes HTTP a nikam dál se nepřipojuje, jen si stahuje z definovaného serveru updaty a používá třeba DNS a NTP opět z předem známých serverů. Pro takový server lze pravidla v tabulce filter definovat velmi precizně, možná klidně až paranoidně. Naopak u pracovní stanice obvykle neomezujeme kam se může připojovat, protože předpokládáme, že bude zdrojem velkého množství HTTP spojení na předem neznámé servery. To často vede k úvaze, že můžeme v tabulce filter v řetězci OUTPUT vše povolit a často to je nakonec jediná možnost, jak uživateli nekomplikovat život.

V dnešní době může i selhat poučka, že pracovní stanice je čistě klientská a že na ní tedy můžeme zakázat připojování zvenčí a to zejména proto, že programátoři často provozují svoje vývojové aplikace lokálně a uživatelé začali používat peer-to-peer spojení pro legitimní aplikace. Tato otázka nebývala předtím takový problém, protože s IPv4 RFC1918 adresami a NATem toho klientské stanice mnoho nedokázaly. S příchodem IPv6 se pro servery mnoho nezměnilo, ale pro klientské stanice to přináší opětovně problém správného vybalancování dostatečné ochrany uživatelů, proti degradaci dostupné konektivity do Internetu nesmyslnými omezeními. Na jednu stranu by byla velká škoda na firewallu zamezit point-to-point konektivitě, kterou IPv6 znovu zajišťuje všem stanicím v Internetu. Jedná se totiž o jednu z hlavních výhod IPv6 proti IPv4, které sice na začátku point-to-point konektivitu mělo, ale v devadesátých letech ji obětovalo kvůli nedostatku IPv4 adres. Na druhou stranu povolení spojení zvenčí na uživatelské stanice vyžaduje radikální změnu myšlení uživatelů i správců, kteří jsou bezmála 30 let ukolébáváni falešným pocitem bezpečí v sítích s oddělenou adresní doménou, protože používají IPv4 RFC1918 adresy a NAT.

Tady nám nezbývá než podotknout: NAT není bezpečnostní mechanismus! Veškerou bezpečnost by měl zařizovat firewall v tabulce filter. NAT se nakonec dá obelstít a lze přes něj různými triky dostat do vnitřní sítě různý provoz. Nejlepší je proto při návrhu firewallu na NAT nespoléhat a ideálně napsat pravidla pro IPv4 a IPv6 najednou a společně tak, aby předpokládaly a promyšleným způsobem se vyrovnaly s faktem, že protokol IPv6 zajišťuje end-to-end konektivitu.

Tady se hodí připomenout, že zatímco iptables má pravidla pro IPv4 a IPv6 striktně oddělená tím, že IPv4 se zadávají přes utilitu iptables, tak IPv6 mají svou utilitu ip6tables. Naproti tomu nftables umožňují nejen napsat IPv4 i IPv6 firewall do jednoho souboru, ale dokonce umožňují sdílet řetězce a zkrátka platí, že pokud testujeme na shodu IPv6 packet s pravidlem, které má test na IPv4 hlavičku, tak zkrátka shoda není možná a platí to pochopitelně i naopak pro IPv4 packet a IPv6 pravidlo.

Definice tabulky pro IPv4 je tedy:

table ip filter {
    chain INPUT {
        type filter hook input priority filter; policy accept;
        ...
    }
}

Pro IPv6 to je:

table ip6 filter {
    chain INPUT {
        type filter hook input priority filter; policy accept;
        ...
    }
}

A společná tabulka pro oba protokoly:

table inet filter {
    chain INPUT {
        type filter hook input priority filter; policy accept;
        ...
    }
}

Odkazy:

Na závěr této sekce nám nezbývá, než zopakovat upozornění: Protokol ICMP (a ICMPv6) je zapotřebí pro správnou funkci ostatních protokolů. Jeho paušálním zakázáním máloco zlepšíme, ale hodně toho rozbijeme.

A úplně nakonec: Je třeba myslet na povolení provozu z a na loopback rozhraní lo.

Předchozí
Následující