Stavíme firewall (3)

Miroslav Petříček 8. 1. 2002

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čí:

widgety

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:

Našli jste v článku chybu?
DigiZone.cz: Další programatické formáty

Další programatické formáty

Lupa.cz: Co všechno je Facebook schopný cenzurovat?

Co všechno je Facebook schopný cenzurovat?

DigiZone.cz: Digi Slovakia zařazuje stanice SPI

Digi Slovakia zařazuje stanice SPI

Vitalia.cz: 5 důvodů, proč jet na výlov rybníka

5 důvodů, proč jet na výlov rybníka

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

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

120na80.cz: Co je padesátkrát sladší než cukr?

Co je padesátkrát sladší než cukr?

DigiZone.cz: Nova opět stahuje „milionáře“

Nova opět stahuje „milionáře“

DigiZone.cz: Technisat připravuje trojici DAB

Technisat připravuje trojici DAB

Vitalia.cz: Voda z Vltavy před a po úpravě na pitnou

Voda z Vltavy před a po úpravě na pitnou

Podnikatel.cz: Letáky? Lidi zuří, ale ony stále fungují

Letáky? Lidi zuří, ale ony stále fungují

Měšec.cz: „Ukradli“ jsme peníze z bezkontaktních karet

„Ukradli“ jsme peníze z bezkontaktních karet

Lupa.cz: Blíží se konec Wi-Fi sítí bez hesla?

Blíží se konec Wi-Fi sítí bez hesla?

Vitalia.cz: Nová vakcína proti chřipce se aplikuje nosem

Nová vakcína proti chřipce se aplikuje nosem

Vitalia.cz: Vodárny varují: Ve vodě z kohoutku jsou bakterie

Vodárny varují: Ve vodě z kohoutku jsou bakterie

Lupa.cz: Jak levné procesory změnily svět?

Jak levné procesory změnily svět?

Vitalia.cz: Test dětských svačinek: Tyhle ne!

Test dětských svačinek: Tyhle ne!

Podnikatel.cz: Udělali jsme velkou chybu, napsal Čupr

Udělali jsme velkou chybu, napsal Čupr

DigiZone.cz: Parlamentní listy: kde končí PR...

Parlamentní listy: kde končí PR...

Lupa.cz: Patička e-mailu závazná jako vlastnoruční podpis?

Patička e-mailu závazná jako vlastnoruční podpis?

DigiZone.cz: Regionální tele­vize CZ vysílá "Mapu úspěchu"

Regionální tele­vize CZ vysílá "Mapu úspěchu"