Vissza az extra tartalmakhoz!

A MikroTik Online Klub több anyaga is foglalkozik a tűzfal rejtelmeivel. Nem véletlenül: nagyon fontos témakör, hiszen, ha valaki nulláról épít fel egy konfigot, akkor a tűzfal nélkül a router védtelen lesz a nem kívánt belépési kísérletekkel szemben. Ha pedig default konfigra építkezünk (amit nem javaslok), akkor tudnunk kell, hogy hogyan tudunk kinyitni például bizonyos eléréseket. Mivel sok anyag szétszóra található a tűzfalról, ezért szükségét éreztem annak, hogy a legfontosabbakat egy helyre összeszedjem – erről szól ez az anyag.

Az IPv4 tűzfal Winbox-ban és Webfig-ben az IP menü Firewall pontjában található, a Filter Rules fülön. Pontosabban 2 szűrési tábla is van: ezt hívjuk Filter táblának, a másikkal pedig majd később megismerkedünk. Ebben az anyagban CLI parancsokat fogok mutatni (/ip firewall filter), mert az írásos forma nem teszi lehetővé, hogy hatékonyan mutassak meg minden Winbox-ban. Van külön tűzfal az IPv6-os csomagokra is az IPv6 menü Firewall pontjában és alapjait tekintve hasonlóan működik, mint az IPv4-es. Az anyagban a példák az IPv4 tűzfallal kerülnek bemutatásra.

Alapok:

A tűzfal alapvetően IP csomagokkal dolgozik. Bár a csomagok tartalmába is be tud bizonyos szinten tekinteni, de alapvetően nem Layer2-es kereteket, vagy  L4-es datagramokat figyel, hanem IP csomagokat. A tűzfal elsődleges feladata a router megvédése a nem kívánt hozzáférésektől. A user-ek forgalmát is szabályozhatjuk vele, de nem minden esetben ideális, hogy ezt RouterOS-sel valósítsuk meg, ezért ennek az anyagnak a fő iránya is a router megvédéséről szól.

A tűzfalazás elsődlegesen Filter szabályokkal valósítható meg és ezeknek a szabályoknak két kötelezően kitöltendő eleme van. Az egyik a chain, a másik az action.

A chain azt határozza meg, hogy milyen típusú forgalmakra vonatkozik a szabályunk. A három alapértelmezett chain:

  • input: ebbe kerül minden olyan forgalom, aminek a végállomása a router. Mindegy, hogy a net felől jön, vagy a LAN-ból származik: ha a router a végállomás, akkor input chain-be kerül. Példák: megpingeted a routert, megszólítod a webes felületét, vagy indítasz rá egy Winbox/ssh/bármilyen bejelentkezést.
  • forward: alapbeállítások mellett ebbe kerül minden olyan forgalom, ami átmegy a roueteren és nem bridge-elt/switch-elt interfészek között közlekedik. Tipikusan ilyen a LAN-on lévő eszközök netes forgalma, vagy ha egyik LAN-ból egy másik LAN-be mennek forgalmak.
  • output: ide kerül minden olyan forgalom, ami a routerből indul és megy bárhová, akár a net felé, akár a LAN felé. Tipikus példa: amikor a routerből megpingtesz egy eszközt, vagy traceroute-olsz. Az output chain-ben valószínűleg kevés szabályt fogsz írni, de arra figyelni kell, hogy az input és az output chain sokszor összefügg: ha pl. megpingeted a routert akkor az ICMP kérés az input chain-be kerül, de a válasz már az output-ba. Vagy ha a routerből pingetsz: a kérés csomag az output chain-be kerül, a válasz pedig az inputba (és jó lenne nem eldobni)

Kérdés: melyik chain-be kerül egy port forward-olt forgalom, ami eredetileg a routernek szól, de a port forward után továbbmegy egy másik eszköz felé? A választ a packet flow diagram adja meg, amit itt találsz: https://wiki.mikrotik.com/wiki/Manual:Packet_Flow Igen, elsőre bonyolultnak tűnik, de nem az és a Security Online anyagban egy magyarázó videót is találsz róla. De hogy a kérdésre is válaszoljak: a forward chain-be fog kerülni, mivel a port forward dst-nat szabály hamarabb le fog futni, mint a tűzfal. Tehát mire a router eldönti, hogy melyik chain-be rakja a forgalmat, addigra már meg lesz változtatva a célcíme.

A másik kötelezően kitöltendő elem az action. Minden tűzfal szabály két részből áll: a feltétel (condition, matcher), amit vizsgál a router, hogy az adott csomag ennek megfelel e. És ha igen, jön az elvégzendő művelet, ami az action. Ebből többféle is van, de most első körben kettővel foglalkozunk:

  • accept: elfogadjuk a csomagot és arra a csomagra több tűzfal szabályt nem vizsgálunk meg.
  • drop: eldobjuk a csomagot, innentől kezdve az nem létezik.

Mindezek ismeretében akár létre is hozhatjuk az első tűzfal szabályunkat, ami a következő:

pl 1:

/ip firewall filter add chain=input protocol=tcp dst-port=80 action=accept

És akkor most egy gondolat kísérlet: mi is történik? Jön egy csomag, ami a routernek szól, azaz a célcíme a router valamelyik IP címe. Az ilyen csomagokra kerülnek ellenőrzésre az input chain szabályai. A router megvizsgálja a szabály feltétel rendszerét és a csomag paramétereit. TCP protokollú a csomagban lévő datagram? 80-as a célportja? Ha mindkettőre igen a válasz, akkor lefut az accept action, azaz a csomag bejöhet a routerbe, megnyílik a webes felülete. Ha bármelyik kérdésre is nem a válasz, akkor pedig átlép a következő szabályra és ugyanezt az ellenőrzést megcsinálja. Ha pedig nincs több szabály, akkor kilép a csomag a tűzfalból. A feldolgozás mindig az adott chain első szabályával kezdődik és a szabályok sorrendje nagyon fontos!

Mi történik azokkal a csomagokkal, amikre nincs illeszkedő tűzfal szabály? Azokat is elfogadja a router! A RouterOS tűzfala alapértelmezetten megengedő, tehát ha nincs egy darab filter szabályunk sem, vagy vannak szabályok, de egyik sem illeszkedik az adott csomagra, akkor azt beengedi. Tehát ha csak a fenti tűzfal szabályunk van és nincs más, akkor igazából ez a szabály semmi hasznosat nem csinál, hiszen minden csomagot alapból beenged a router. Éppen ezért a tűzfalunkba szinte minden esetben kell egy drop szabály is, azaz bizonyos forgalmakat el fogunk dobni. A logikai felépítés a legtöbbször úgy néz ki, hogy elfogadunk bizonyos nekünk szükséges forgalmakat és a végén minden mást eldobunk. A megengedő viselkedés miatt fontos, hogy egyáltalán foglalkozzunk a tűzfalazással, hiszen, ha nem szűrjük a nem kívánt forgalmakat, akkor bármi eljut a feldolgozásig.

Teljes zárás:

Sok esetben semmi szükség nincs arra, hogy a router a pl. net felől elérhető legyen. Ilyen esetekben alkalmazhatjuk a teljes zárást, ami így néz ki:

pl: 2

/ip firewall filter add chain=input action=drop

Ez a szabály nem csak a net felől jövő, a routernek szóló csomagokat dobja el, hanem azokat is, amik a LAN felől jönnek. Ez esetben a LAN felől sem érhető el IPv4 alapon a router, de MACWinbox-szal, vagy IPv6-tal igen. Ha azt szeretnénk, hogy a LAN-ból az IPv4 elérés menjen, akkor használhatjuk az in-interface matcher-t és mondjuk csak a WAN-ról jövő forgalmakat dobjuk:

pl 3:

/ip firewall filter add chain=input in-interface=WAN_interfész action=drop

Arra figyelj, hogy a WAN interfész PPPoE esetén nem a fizikai interfész lesz, hanem a pppoe-out interfész, tehát azt kell a szabályban megadnod.

És még egy dolgot vegyél figyelembe: ha esetleg vendég wifi is van, akkor valószínűleg nem akarod, hogy az oda csatlakozók elérhessék a routert és ez esetben a vendég wifi (virtuális) interfészre is kell egy ilyen szabály. Vagy ugyanez a helyzet, ha több LAN-od, akár VLAN-ok vannak: nem kell mondjuk egy cég pénzügyi osztályához tartozó (V)LAN-ból hozzáférést adni a routerhez.

pl 4:

/ip firewall filter

add chain=input in-interface=guest_wifi_interfész action=drop

add chain=input in-interface=vlan_interfész action=drop

A teljes zárás esetén viszont érhetnek meglepetések, például nem tudsz semmit megpingetni a router-ből, mindenre timeout-ot kapsz. Ez azért van, mert amikor a routerből pingetsz bármilyen irányba, akkor az ICMP kérés, ami kimegy, az egy output chain-be kerülő csomag lesz. A cél jó esetben válaszol, azaz küld egy ICMP választ, ami viszont a router input chain-jébe kerül. Viszont, ha minden bejövő forgalmat eldobunk, akkor hiába jön válasz, mert a ping tool és mindenféle helyi csomagfeldolgozás már a tűzfalazás után van. Ugyanez történik akkor, ha a routerből egy VPN kapcsolatot indítasz egy VPN szerver felé: mivel a szervertől jövő forgalmakat az input chain-be kerülnek, ezeket eldobja a router.

Erre a problémára megoldás és a tűzfalazás által okozott CPU terhelést is csökkenti, ha foglalkozunk a csomagok….

Szerezd be a teljes verziót és tovább olvashatsz!

A folytatásból megtudhatod, hogy:

  • hogyan adj kivételeket a tűzfalhoz. Hogyan engedj be bizonyos ellenőrzött forgalmakat. Gyakori, a hálózatok 99%-ához szükséges példák
  • hogyan tudsz biztonságos hozzáféréseket kialakítani úgy, hogy Te bárhonnan hozzáférj az eszközödhőz, de más ne.
  • hogyan és mikor használd a másik tűzfal táblát, a RAW táblát.
  • hogyan védekezz a DoS támadások ellen a tűzfallal.
  • hogyan ne kövess el egy gyakori hibát, ami megakadályozza a tűzfal szabályok futását.
  • és két összesített, komplett példa, amit azonnal használhatsz a saját eszközödön.

16 oldalnyi a tűzfal legjavából! (A4 oldalon, 12-es betűmérettel számolva)