Hlavní navigace

Stavíme firewall (3)

8. 1. 2002
Doba čtení: 7 minut

Sdílet

Dnešním dílem končí série o sestavování firewallových pravidel na jádrech 2.4. Nejprve se podíváme na stavový firewall, a pak si ukážeme, jak vyzrát na některé známé firewallovací problémy.

V roce 2001 jsme publikovali seriál článků „Stavíme firewall“, který inspiroval překvapivé množství linuxových administrátorů ke tvorbě vlastního firewallu. Součástí článků byl i ukázkový script, který doporučoval mj. zablokovat adresní rozsah 96.0.0.0/4, který v té době byl rezervovaný. Protože nyní při nedostatku IPv4 adresního prostoru došlo k přerozdělování i těchto rozsahů může dojít k problémům, pokud jej váš firewall stále blokuje. Pokud jste tedy uvedený skript použili jako základ pro váš firewall, ujistěte se, že neblokujete nyní korektní rozsahy adres.

Stavový firewall

Jádra řady 2.4 přicházejí s koncepčně novým přístupem, kdy při filtrování berou v úvahu nejen informace obsažené v záhlaví zkoumaného datagramu, ale dokáží na něj nahlížet komplexně, v kontextu spojení, do kterého patří. Stavový firewall rozezná paket, který otevírá nové spojení, od paketů, které tuto komunikaci realizují, a díky tomu můžeme precizněji filtrovat datové toky.

Každý zkoumaný datagram (a to nejen TCP segment, ale i UDP paket) je pak zařazen do některé z těchto kategorií:

  • NEW – datagram otevírá novou komunikaci
  • ESTABLISHED, RELATED – datagram je součástí již navázaného spojení nebo s ním nějakým způsobem souvisí.
  • INVALID – datagram není součástí žádného spojení nebo se jej nepodařilo identifikovat.

Na základě stavové informace můžeme tedy pakety třídit. Můžeme například stanovit, že spojení mohou být navazována pouze směrem z vnitřní sítě ven a ne naopak, přičemž pakety již otevřených spojení mohou putovat oběma směry.

iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED \
  -j ACCEPT
iptables -A FORWARD -i eth1 -j ACCEPT

Jaké má stavový firewall výhody?

Stavový firewall přináší značné zjednodušení filtrovacích pravidel oproti dobám, kdy jsme pomocí ipchains museli brát v úvahu různé kombinace adres, vysokých portů a SYN flagů. Nyní tedy můžeme, díky klasifikaci paketů, imlicitně povolit, aby firewallem protékaly pakety patřící k již navázaným spojením (ESTABLISHED), a omezení stanovujeme na úrovni navázání spojení.

Nová inteligence stavového firewallu dovoluje přísnější „lustrování“ paketů. Nyní již můžeme odstranit i podvržené pakety, které se pohledem statického firewallu jeví jako nezávadné, ale v kontextu probíhajících spojení je stavový firewall dokáže odhalit. Díky tomu se můžeme lépe bránit nejrůznějším technikám fingerprintingu (zjišťování typu OS) a portscanningu (zjišťování otevřených portů), které může útočník zneužít při odhalování slabin naší sítě.

Stavový firewall řeší s konečnou platností fungování pasivního a zejména aktivního FTP režimu (viz níže), což bylo dříve přinejmenším problematickou záležitostí.

A jaké má nevýhody?

Ve srovnání s výhodami zanedbatelné. Jedinou, která mě napadá, jsou vyšší nároky na hardware firewallu. V paměti je totiž nezbytné udržovat stavové informace o všech spojeních.


Aktivní a pasivní FTP

Známým oříškem při tvorbě firewallových pravidel je od nepaměti FTP. FTP může fungovat ve dvou řežimech – pasivním a aktivním. V aktivním režimu klient odešle (na port 21) serveru číslo portu (nad 1024) a server se na něj ze svého portu (20) připojí. Pasivní režim funguje přesně opačně – server pošle klientovi port (nad 1024) a on se na něj připojí (z > 1024). Novější programy, zejména WWW browsery, preferují pasivní FTP režim, který je pokládán za bezpečnější, zejména díky tomu, že datové spojení je navazováno ve stejném směru jako původní požadavek.

Problémem FTP je, že pracovní port není statický, ale mění se s každým spojením. Proto není snadné (a ani možné) napsat bezpečné a jednoznačné statické filtrovací pravidlo, které by dokázalo regulérní FTP spojení rozpoznat.

Proto firewall potřebuje oporu v jádře, respektive v modulu ip_conntrack_ftp, který dokáže z navazovaného spojení „odposlechnout“ dohodnutou kombinaci portů a zajistí, že stavový firewall bude tyto pakety klasifikovat jako „RELATED“. Pokud chcete, aby váš firewall podporoval FTP přenosy, zaveďte zmíněný modul a povolte příchozí RELATED spojení.

modprobe ip_conntrack_ftp
iptables -A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Dodejme, že podobně jako FTP se chová také IRC a některé další „zlobivé“ protokoly. V době, kdy vzniká tento článek, však obsahuje kernel 2.4 podporu právě jen pro FTP a IRC.

AUTH

Některé programy používají službu AUTH (identd) ke zjištění, jakému uživateli patří to které spojení. Protože může poskytovat útočníkovi nežádoucí údaje, není dobré ji otevírat světu. Ovšem pokud ji běžným způsobem zablokujeme (DROP), také to není dobře, neboť některé programy (např. SMTP servery) ji mohou využívat v rámci užitečného provozu. Pokud ji tedy budeme filtrovat, může docházet ke značnému zpomalení komunikace, když bude protistrana čekat na vypršení času vyhrazeného k vyřízení AUTH požadavku.

Proto je nezbytné na firewallu blokovat AUTH ne pravidlem DROP, ale REJECTem. Rozdíl je takový, že zatímco DROP pakety doslova „zahodí“, REJECT je „zdvořile odmítne“, tedy vygeneruje odesílateli ICMP datagram s oznámením o odfiltrování dotyčného paketu.

iptables -A INPUT -i eth0 -p TCP --dport 113 -j REJECT

Ochrana před IP spoofingem

IP spoofing znamená falšování zdrojové IP adresy, čímž se útočník snaží předstírat, že je někdo jiný, nebo se snaží zamaskovat svoji pravou IP adresu. Proto je žádoucí, aby se na vstupu firewallu filtrovaly pakety, které jsou evidentně podvržené a jejich původce nemůže mít čisté úmysly.

Nejzákladnější ochranu před IP spoofingem představuje rp_filter. Jde o jednoduchou ochranu, která je vázána na konkrétní síťové rozhraní. Funguje tak, že jádro zablokuje pakety se zdrojovou adresou, která by podle routovací tabulky měla přijít z jiného dostupného rozhraní. Příklad:

echo "1" > /proc/sys/net/ipv4/conf/eth0/rp_filter

nebo obecněji

for interface in /proc/sys/net/ipv4/conf/*/rp_filter; do
      echo "1" > ${interface}
  done

Pokud je adresa vnitřní sítě např. 192.168.0.0/24, zajistí jádro, že přes rozhraní eth0 nepronikne žádný paket, který by se snažil tvářit, jako by měl svůj původ v této vnitřní síti. Stejně tak bude blokovat 127.0.0.0/8, protože tyto adresy příslušejí loopbacku…

rp_filter je jednoduchou, ale účinnou ochranou před IP spoofingem. Pokud nepoužíváte nějaké složité routovací techniky, měli byste jej mít zapnutý.

Rozšířenou ochranu před IP spoofováním řešíme až na úrovni paketového filtru. RFC 1918 udává rozsahy IP adres, které jsou vyhrazeny pro použití v lokálních sítích a jejichž datagramy není dovoleno směrovat do Internetu. Pokud se takový paket objeví na internetové straně routeru, nemůže se jednat o žádoucí spojení a je třeba jej odfiltrovat:

iptables -N spoofing
iptables -A spoofing -s 192.168.0.0/16 -j DROP
iptables -A spoofing -s 172.16.0.0/12 -j DROP
iptables -A spoofing -s 10.0.0.0/8 -j DROP

iptables -A INPUT -i eth0 -j spoofing
iptables -A FORWARD -i eth0 -j spoofing

V uvedeném příkladu jsme nejprve definovali nový řetězec „spoofing“ a nechali jím proběhnout příchozí pakety z řetězců INPUT a FORWARD. Tímto zápisem jsme si ušetřili duplikování zákazů na dvou místech.

Kromě adres rezervovaných v RFC 1918 existují i další adresy, se kterými bychom se neměli v internetu potkat. Jejich seznam najdete tady. Pokud je ve sloupci uvedeno „reserved“, naní daný rozsah adres přidělen a můžeme jej tedy filtrovat. Dejte ovšem pozor, protože rezervované adresy mohou být v budoucnu přiděleny.

SYN flooding

Je oblíbená crackerská technika, kterou se realizuje DoS (Denial of Service) útok. Spočívá v tom, že útočník zahltí oběť spoustou TCP segmentů s nastaveným SYN flagem, které požadují vytvoření nového spojení. Prostředky serveru jsou samozřejmě omezené, a proto dříve nebo později dojde k DoS.

Ochrana spočívá ve stanovení limitu pro nově vytvářená spojení (SYN pakety) v čase. Pomocí iptables můžeme vytvářet pravidla, kterými sice paket povolíme (ACCEPT), ale zároveň určujeme, že pravidlo smí být aplikováno ne častěji než například 4× za sekundu. Tak například přiměřená ochrana našeho serveru před SYN floodingem může být:

iptables -N syn_flood
  iptables -A INPUT -i eth0 -p tcp --syn -j syn_flood
  iptables -A syn_flood -m limit --limit 1/s --limit-burst 5 -j RETURN
  iptables -A syn_flood -j DROP

Přeloženo do přirozeného jazyka: Vytvořili jsme nový řetezec, do kterého předáváme TCP pakety s flagem SYN přicházející z eth0. Pokud bude takových paketů méně než pět za sekundu, navrátíme je zpátky do INPUTU. Jinak je filtrujeme.

Inteligentní logování

Logování zahozených paketů je jistě dobrá věc, zejména při diagnostikování problémů, ale každý, kdo kdy prohledával logy nějakého restriktivně navrženého firewallu, jistě ví, že mohou nabobtnávat do někdy až nepříliš praktických objemů. Proto se snažíme zamezit logování vícera stejných záznamů pomocí stejné techniky jako u SYN floodingu. Namísto obyčejného logovacího pravidla napíšeme něco jako:

iptables -A INPUT -m limit --limit 3/hour --limit-burst 5 -j LOG

Uvedený zápis loguje pouze prvních pět vyhovujících paketů, ovšem ne častěji než třikrát za hodinu.

Ping of death

Další napříjemná DoS technika, spočívá v zavalení oběti žádostmi o echo-request (ping). Bránit se jí můžeme stanovením limitu na ICMP echo-request požadavky. Pět pingů za sec bohatě stačí:

CS24_early

iptables -A INPUT -p icmp --icmp-type echo-request \
    -m limit --limit 1/s --limit-burst 5 -j ACCEPT

Tak a tím jsem s výkladem základů firewallování na Linuxu 2.4 u konce. Pokud chcete vidět, jak vypadá taková hotová konfigurace, dovolil jsem si shrnout poznatky vysvětlované ve všech třech částech tohoto seriálu do ukázkového skriptu, který naleznete tady a který můžete ihned začít používat nebo si z něj třeba jen vzít inspiraci pro stavbu svého vlastního firewallu.

Související odkazy:

Byl pro vás článek přínosný?

Autor článku