1. Prolog:

Stavový firewall je totální základ každé sítě. Je to ohnivá zeď, která odděluje zrno od plev. Samotný stavový firewall je jen hloupý filtr, který na hrubozrnné úrovni pomáhá správcům sít povolit jen to, co má být manažováno a poté zahazuje vše, co je neznámé.

Pokročilejší nástavby jsou  tzv. NGA firewally  což je obchodní název pro nástavbovou soustavu skriptů, které dávají do stavového firewallu vyšší logiku, ale to není dnešním tématem.

Dnes si budeme demonstrovat základy problematiky stavového firewallu na platformě RouterOS. RouterOS přebírá veškerou filozofii z linuxových IPTables a je v něm viditelné, jaké jsou prazáklady tohoto kouzelného světa síťařské problematiky.

2. Řetězce

V RouterOS se řetězcům říká chainy. IPTables má definované řetězce. Řetězce si můžeme představit jako určitou logickou formu kategorizace datového toku dle toho, kam směřuje. Ve firewallech se posloupnost pravidel  čte sekvenčně od prvního do posledního pravidla. Ukážeme si to konkrétně. Představme si, že máme v síti MikroTik.

Pokud datový tok směřuje přímo na samotný MikroTik, pak se tento řetězec nazývá input.

Prochází-li datový tok přes router, pak tento řetězec nazýváme forward.

Je-li datový tok generován ze samotného MikroTiku ven, pak se tento řetězec nazývá output.

2.1 Příklad z praxe

Přiřaďte jednotlivým situacím správný řetězec (odpovědi jsou na konci článku):

A) Spokojený zaměstnanec firmy Connectica s.r.o. je venku na služební cestě a snaží se vytočit si VPN pomocí SSTP. Na MikroTiku v mateřské firmě běží SSTP server. V jakém řetězci bude datový tok zachycen?

B) Máme ve vnitřní síti dva počítače. PC1 a PC2. Oba počítače jsou spojeny na přímo do MikroTiku. PC1 do eth1 portu, PC2 do eth3 portu. Jaký řetězec se uplatní, budou-li oba stroje komunikovat mezi sebou?

C) Samotný MikroTik se snaží dotazovat ven na NTP server, aby si mohl synchronizovat svůj čas. Jaký řetezec se uplatní?

Vždy, když uvažujete o datovém toku, musíte si správně uvědomit v jakém řetězci se datový tok realizuje a na jakém je. Dokážete-li toto, pak máte z půlky vyhráno a firewall pro Vás už bude o to větší brnkačka.

2.2 Akce ve Firewallu

Aby byl datový tok zachycen správně, používáme několik možností, jak jej identifikovat. Ne nadarmo vycházíme z toho, jak vypadá samotný IP paket na kost.

V tom základním článku zmíníme:

1. Zdrojová IP adresa
2. Cílová IP adresa
3. Příchozí rozhraní
4. Odchozí rozhraní
5. Typ užitého protokolu



Není to výčet všech, ale jen těch základních společných znaků obecných pro všechny firewally. Avšak ani samotný IP paket není to jediné, dle čeho lze udělat matching (zachycování). lze matchovat pomocí zdrojového,cílového portu.

Linuxová filozofie (kterou RouterOS kopíruje) přidává mnoho dalších identifikátorů, které ostatní výrobci buď pro jednoduchost ignorují, nebo je mají někde  kulišáčky schované. Typicky například drop veškerého trafficu, což je pravidlo, které se nachází vždy na konci.

2.3 Stav spojení

Nebo-li connections. Ač můžeme pracovat s jednotlivými pakety, tak je elegantní  a pohodlné pracovat s celým spojením. RouterOS si vnitřně dělí navázaná spojení do následujících stavů: (neplést si s TCP  stavy, například syn)

1. Datová komunikace navazuje spojení (new)
2. Datová komunikace je navázána (estabilished)
3. Datová komunikace je příbuzná (related)
4. Datová komunikace kterou nelze zařadit do žádné z výše uvedených komunikací  (invalid)
5. Untracked – V tomto článku se mu nebudeme věnovat. V případě zájmu se k němu vrátíme v budoucnosti.

Chce-li Váš počítač komunikovat s nějakou službou (třeba SSH, která užívá port 22), pak Váš počítač vybere nějaký typicky pseudonáhodný port  a odešle od sebe na cílový server na cílový port paket, který má příznak syn. Datová komunikace může vypadat obecně takto:

Proto TCP (SYN), IP_lokálníhoPC>:PseudoNahodnyPort ---> <veřejnáIP>:port, len 44

Konkrétně je to:

Proto TCP (SYN), 192.168.88.111:4253 --> 1.2.3.4:22,len 44

Taková komunikace je systémem vnímána  jako nová. Snaží se navázat spojení. Proto stav spojení je new.

Naváže-li takováto komunikace spojení, pak je toto spojení estabilished (navázané spojení).

Odvozeným případem spojení je related connection (příbuzné spojení). Tento druh paketů vychází z navázaného spojení a pouze přeskočí někam jinam. Dodáme, že related komunikace je velmi malé množství, lze se s ním setkat například u SIP protokolu.

Poslední druh spojení je invalid connection (nevhodné spojení). Tento druh spojení je definován v RoS tak, že je to nějaký paket, který nenavazuje ani nové spojení a nepatří ani k nějakému estabilished nebo related spojení.

Typický příklad, kdy invalid komunikace může být validní se projevuje při dynamickém routování.



2.3 A co s datovým tokem?

Se správně identifikovým datovým tokem můžeme udělat celkem tři základní věci:

A. Filtr

1. 1. Povolit jej (allow)
   2. Odmítnout jej (reject)
   3. Zahodit jej (drop)

B. Změna (Mangle, NAT)

Výše uvedený obrázek vypadá na první pohled zbytečně, ale je to esence pro pochopení mistrovství ve firewallech. Na obrázku jsou dle různých tvarů zobrazeny cesty toku paketů vně routeru. Barevně označená písmenka značí akce, které můžeme v jednotlivých místech dělat. Jak vidíme, manglování paketů můžeme dělat nejčastěji. Správné umědomnění si co můžeme kdy dělat nám dává nadhled nad celou problematikou.

Bod A1. je zcela jasný. Rozdíl mezi bodem A2. a A3. si ukážeme opět na konkrétním příkladu. Představme si, že posíláme na nějaký veřejný router icmp paket (alias ping). Pokud má router na firewallu definované, že takovou příchozí komunikaci na inputu má odmítnout (reject), pak nám dorazí zpráva, že icmp pakety jsou „prohibited“. Kdežto, měl-li by router nastaveno, že příchozí icmp komunikaci má dropnout, pak nám nedorazí žádná slušná odpověď. Router mlčí jako ryba. Důvod je zcela evidentní. ICMP pakety pomáhají v sítích k diagnostice, ale současně mohou být útočníky a hackery užity k tomu, aby v nějakém skriptu odhalovaly po celém světě veřejné IP adresy, které odpovídají na ICMP. Pro útočníka je to nepřímý signál – “třeba správce neumí zabezpečit svůj router”. Když jsme dostali odpověď na ping, pak zkusíme něco dalšího (třeba port scanner). A po port scanneru, třeba zkusíme čeknout jestli není nějaká bezpečnostní díra na jeho užívané platformě, abychom ji mohli kompromitovat.

Mezi další možnosti práce s datovým tokem mimo jiné patří:

1. Tarpit (TCP only)
2. Passtrough
3. Jump

Jump je vynikající funkcionalita. Umožnuje si určité pakety označit a nechat je přeskočit do jiného, samostatného řetězce. Když jump umíte používat, velmi pomůže s přehledností firewallu a  také může při správném použítí ulehčit CPU při zpracování pravidel.



Proč uvažovat u firewallu v kombinaci s filtrací provozu a klasifikaci na základě druhého spojení? Představme si, že na inputu si definujeme, že povolujeme všechen tok z LAN a pak cokoliv jiného zahazujeme. Pokud nějaký PC ve vnitřní síti si pingne na náš MikroTik, tak pro jednoduchost příkladu stroj prostě spojení příjme. Ale co když si router chce pingnout na nějaký stroj ve WANu? Když to s tímto pravidlem zkusí, nedostane zpět odpověď. On totiž router sice pošle paket ven, ale jakmile se paket vrací, tak je automaticky zahozen. Je to jednoduché. Pingáme-li na stroj ve WAN, tak tento stroj jednoznačně není v naší LAN síti a proto se uplatňuje druhé pravidlo – drop. Jak to obejít?

Můžeme nastavit, že povolujeme všechny ICMP pakety, ale to nám může udělat bezpečnostní díru a to přeci nechceme. Toto je přesně ten moment, kdy nám pomůže klasifikace na základě stavu spojení. Povolíme-li pakety, které jsou estabilished, pak po pingnutí na WAN stroj dostaneme zpět odpověď. Spojení se už navázalo, netřeba ho dál filtrovat. Je to jednoduché a přitom genální, že?

3. Konkrétní návrh firewallu na MikroTiku:

Teorii známe, pojďme na praxi. V praxi uvažujeme SOHO/SME společnost do 50 zaměstnanců. V nejjednodušším případě by to mohlo vypadat nějak takto:

1. Povolíme co chceme povolit, zakážeme vše ostatní
2. V základu je vše povoleno, my jen zakazujeme dle naší potřeby.

Bod 2 je jednodušší, ale velmi se nedoporučuje tento přístup. Důvod, proč to zmiňujeme je ten, že toto je výchozí stav v RouterOS.

3.1 Pravidla pro input:

• Povolíme estabilished, related pakety.
• Dropneme invalid pakety.
• Povolíme datový tok z management IP adres.
• Povolíme VPN tunely, monitoring, syslogy aj. služby potřebné pro náš monitoring.
• (Pro naše potřeby a pro jednoduchost si povolíme na TIK komunikaci z LAN i DMZ)
• Vše ostaní dropneme

3.2 Volitelné na inputu:

• Nastavení analogie Fail2ban pro služby otevřené ze světa
• Nastavení ochranu proti DDoS útokům.

3.3 Pravidla na forward:

• Povolíme estabilished, related pakety.
• Dropneme invalid pakety.
• Dropneme komunikaci WAN –> LAN
• Povolíme komunikaci  LAN –> WAN
• Vše ostatní dropneme.

3.4 Pravidla pro DMZ

• Povolíme estabilished, related pakety.
• Dropneme invalid pakety.
• Utvoříme si chain a povolíme si služby z WAN –> DMZ
• Povolíme komunikaci DMZ –> WAN
• Vše ostatní dropneme.

3.4 Volitelné pravidla na outputu:

• Povolíme estabilished, related pakety.
• Dropneme invalid pakety.
• Povolíme komunikaci pro tunely, winbox, SSH.
• Povolíme dotazy na DNS, NTP a cokoliv, co router potřebuje k životu.
• Vše ostaní dropneme.

4. Praktická ukázka firewallu v MikroTiku.

Nyní si ukážeme ukázku implementace jednoduchého, ale přitom velmi efektivního firewallu v textovém výpisu z MikroTiku. V ukázce jsou fiktivní adresy

Ve firewallu se užívají address-listy i interface-listy. Obojí jsou pouze grupy, které usnaďují přehlednost a zjednodušují firewall do té míry, aby se v něm dalo snadněji orientovat.

5. Závěr:

Probrali jsme teorii a ukázali jsme si základní implementaci jednoduchého stavového firewallu na platformě RouterOS.

Stavový firewall nabízí mnoho základních i pokročilých funkcionalit, jak filtrovat provoz a je plně dostačující pro většinu SOHO/SME společností, když přihlédneme k celkové velmi přijatelné ceně za hotové řešení.

Výčet stavového firewallu popsán výše je jen špička ledovce u samotného komplexního zabezpečení společnosti používající RouterOS. Nejedná se jen o potřebnou antivirovou kontrolu na endpointech, či i uvědomění uživatelů užívajících koncová zařízení. Z časových důvodů jsme u MikroTik RouterOS nezmínili mnoho dalších nástavbových pravidel vně RouterOS, které jsou nezbytným předpokladem pro správnou konfiguraci routeru jako celku. Uvádíme například funkce Neigbhours, mac-telnet/winbox, RoMON, CAPsMAN, L2 firewall či správně nakonfigurované IP services.

Společnost Connectica s.r.o. v rámci svého projektu ThinkTik realizuje úplné, komplexní realizace zabezpečení RouterOS dle standardních znalostí z certifikací MTCTCE a MTCSE. Pánům z NOC můžete písnout na sales@connectica.cz

5.1 Odpovědi na otázky 🙂

A – input

B – forward

C – output

Nakoukněte co vše umíme dále 😉

Výstavby DNS serverů

Jedná se o velmi častou problematiku, která je žádána jako alternativa k ADDC. Výstavba DNS serverů v redundanci na OS Debian a OS CentOS s užitím BINDu.

Read more

VPN koncentrátory na MikroTiku

Výstavba VPN koncentrátorů pro potřeby zasíťování více poboček se směrováním na jednu centrální kancelář.

Read more

Diagnostiky nízké propustnosti

Velmi často je řešena problematika diagnostiky nízkých propustností, kde hlavním pilířem je hledání bottlenecku v infrastruktuře, který může být na více místech.

Read more

Dokumentace výrobních linek

Ukázka řešení základní problematiky topologického mapování a dokumentace infrastruktury ve výrobních společnostech.

Read more

Upgrade infrastruktur

Rozsáhlé aktivity při upgrade celé infrastruktury na nejnovější verze OS a to tak, aby vše bylo sladěno a zkoordinováno bezvýpadkově pro celou společnost.

Read more

Výstavba Proxmoxových serverů

Poměrně častou problematikou společnosti je dodávka infrastuktury na klíč. Naším oblíbeným hypervizorem je Proxmox a tento druh problematiky je velmi často žádán.

Read more