[MIKROTIK] Podstawowe reguły firewall

Dzień dobry :slight_smile:

Przekopałem się trochę przez forum i internet i chciałbym zadać kilka pytań odnośnie podstawowych reguł do firewalla. Router MikroTik hAP ac3. RouterOS 6.48.2

Na chwilę obecną mam router skonfigurowany z wykorzystaniem standardowych ustawień. Chciałbym jednak zrobić sobie sieć pod siebie (swój adres, bridge, etc). Wiem już jak poustawiać wan, bridge… ale nie wiem za co dokładnie podstawowe reguły odpowiadają. Czy ktoś mógłby tutaj skomentować podstawowe reguły firewalla, które dostępne są w manualu?

https://wiki.mikrotik.com/wiki/Basic_universal_firewall_script

Warto w ogóle korzystać z takich reguł? Może zaproponujecie coś lepszego na start do nauki?

A co konkretnie chcesz osiągnąć? Bo domyślnie masz firewall i to całkiem solidny, możesz sobie np. dodać listę domen do blokowania z cert.pl instrukcja link

Możesz zrobić Pi-hole , czyli takiego adblocka, ale będzie blokował przed komputerem, już same zapytania, więc odciąży niepotrzebny ruch.

Możesz dodać ochronę przed atakami z niebezpiecznych adresów. masz tego pełno w sieci, pogrzeb co ci jest potrzebne i już.

Ja osobiście zawsze przyjmuję politykę drop all. To znaczy, że najpierw zezwalam na to co potrzebuję (dostęp do Winbox, ssh, VPN itp.), zezwalam na połączenia nawiązane i powiązane, a resztę wycinam w pień. Mam jeszcze swoje regułki honeypot, ale w warunkach domowych są raczej opcjonalne.

Myślę, że powinieneś wyjść od takich reguł.

INPUT

  1. 53/udp allow z podsieci lub interfejsu bridge - jeśli korzystasz z DNS na Mikrotiku
  2. Połączenia nawiązane i powiązane allow
  3. Drop

FORWARD

  1. Połączenia nawiązane i powiązane allow
  2. Drop

OUTPUT

  1. Połączenia nawiązane, powiązane i nowe
  2. Drop
1 polubienie

Oczywiście, zdaję sobie sprawę z tego, że standardowy firewall jest dobry, ale obowiązuje on tylko w sytuacji, kiedy zachowam domyślną konfigurację RouterOS. Chciałbym jednak wszystko wymazać i ustawić sobie po swojemu. I tutaj nasuwa się pytanie, które są najbardziej potrzebne i jak je skomentować (aby w przyszłości móc się na nich opierać).

@roobal Czy mógłbyś mnie odesłać w którą część internetu, gdzie będę w stanie zobaczyć składnię dla tworzenia takich reguł?

Najbardziej potrzebna jest translacja adresów czyli NAT, no bo bez tego nie będzie internetu po stronie wewnętrznej sieci. A potem możesz sobie już tworzyć reguły jakie chcesz.

Tutek do tego jak robić podstawowe reguły znajduje się np. tutaj link

Podstawowe kroki, jakie warto zrobić masz tutaj link.

Ja mam tak skonfigurowane:

/ip firewall filter
add action=drop chain=input comment=“blokada ::: WAN ::: atak ::: DNS ::: UDP” dst-port=53 in-interface-list=WAN_LIST protocol=udp
add action=drop chain=input comment=“blokada ::: WAN ::: atak ::: DNS ::: TCP” dst-port=53 in-interface-list=WAN_LIST protocol=tcp
add action=accept chain=input comment=L2PT dst-port=500,1701,4500 protocol=udp
add action=accept chain=input comment=WINBOX dst-port=xxxxx in-interface-list=LAN_LIST protocol=tcp
add action=accept chain=input comment=HTTPS dst-port=xxxxx in-interface-list=LAN_LIST protocol=tcp
add action=accept chain=input comment=“defconf: accept established,related,untracked” connection-state=established,related,untracked
add action=accept chain=input comment=“accept ICMP” in-interface-list=LAN_LIST protocol=icmp
add action=accept chain=input comment=“defconf: accept to local loopback (for CAPsMAN)” dst-address=192.168.1.1
add action=drop chain=input comment=“detect and drop port scan connections” protocol=tcp psd=21,3s,3,1
add action=tarpit chain=input comment=“suppress DoS attack” connection-limit=3,32 protocol=tcp src-address-list=black_list
add action=add-src-to-address-list address-list=black_list address-list-timeout=1d chain=input comment=“detect DoS attack” connection-limit=10,32 protocol=tcp
add action=drop chain=input comment=“defconf: drop ICMP” protocol=icmp
add action=drop chain=input comment=“defconf: drop invalid” connection-state=invalid
add action=drop chain=input comment=“defconf: drop all not coming from LAN” in-interface-list=!LAN_LIST
add action=fasttrack-connection chain=forward comment=“defconf: fasttrack” connection-state=established,related
add action=accept chain=forward comment=“defconf: accept in ipsec policy” ipsec-policy=in,ipsec
add action=accept chain=forward comment=“defconf: accept out ipsec policy” ipsec-policy=out,ipsec
add action=accept chain=forward comment=“defconf: accept established,related, untracked” connection-state=established,related,untracked
add action=drop chain=forward comment=“defconf: drop invalid” connection-state=invalid
add action=drop chain=forward comment=“defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat connection-state=new in-interface-list=WAN_LIST

Może się komuś przyda. A może ktoś podpowie co tam jeszcze można dodać/poprawić/przesunąć do zastosowań domowych. Jest to lekko zmodyfikowany standard.

Mój zestaw reguł.

/ip firewall filter
add action=add-src-to-address-list address-list=Fail2Ban address-list-timeout=2d chain=input dst-port=22 in-interface=WAN protocol=tcp src-address-list=!ALLOWED
add action=drop chain=input in-interface=WAN src-address-list=Fail2Ban
add action=accept chain=input dst-port=53 in-interface=LAN protocol=udp
add action=accept chain=input connection-state=new dst-port=8291 in-interface=LAN protocol=tcp src-address-list=ALLOWED
add action=accept chain=input dst-port=223 in-interface=LAN protocol=tcp src-address-list=ALLOWED
add action=accept chain=input connection-state=established,related
add action=drop chain=input
add action=drop chain=forward in-interface=WAN src-address-list=Fail2Ban
add action=accept chain=forward in-interface=LAN out-interface=WAN
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward
add action=accept chain=output connection-state=established,related,new
add action=drop chain=output

W skrócie:

  1. Zbierasz IPki, które próbują wbić się na 22/tcp - w ip services zmień sobie port SSH na 223;
  2. Zezwalasz na zapytania DNS tylko z sieci LAN - o ile korzystasz z DNS na Mikrotiku i zaznaczyłeś w IP>DNS opcję Allow remote requests;
  3. Zezwalasz na dostęp do Winbox i SSH tylko dla określonych adresów IP z listy - listę ALLOWED musisz sobie utworzyć. W IP Services też dodaj IP dla Winbox i SSH. Resztę usług wyłącz;
  4. Zezwalasz na ruch z połączeń nawiązanych i powiązanych.
  5. Resztę ruchu blokujesz.
1 polubienie

Przy domyślnej konfiguracji router przepuszcza nawiązane połączenia, odrzuca pakiety które mają status invalid (instrukcja dokładniej wyjaśnia kiedy pakiet może mieć taki status). przepuszcza połączenia icmp (w tym po stronie WAN) oraz odrzuca wszystkie połączenia z poza sieci wewnętrznej LAN (czyli np. próbę połączenia na porcie przykładowo 23 z internetu).

Połączenia z internetu są akceptowane jeżeli zostaną dodane na listę NAT (dstnat), jest to właściwie tzw. przekierowanie portu na określony adres ip w sieci wewnętrznej.

Te reguły nie występują domyślnie jednak zalecane jest zablokowanie połączeń na porcie 53 przy korzystaniu z wbudowanego serwera DNS. Jeżeli opcja “Allow Remote Requests” jest aktywna.

Dlatego napisałem że lekko modyfikowałem domyślny konfig (dodałem po prostu kilka wpisów)

Przerobiłem już dziesiątki, jak nie setki Mikrotików, od zwykłych RB po CCRy i domyślny skrypt nie ma tego o czym piszesz. Firewall jest praktycznie czysty.

Ta reguła, owszem, jest obowiązkowa, ale tylko gdy filtrujesz ruch z WAN. Gdy na input masz drop bez wskazania interfejsu, to wycina Ci wszystko i wtedy 53/udp dla LAN trzeba zezwolić. W RouterOS jest linuksowy filtr pakietów, działa tak samo jak na systemach linuksowych, przy czym politykę bezpieczeństwa określa się regułą. Podobnie jak na urządzeniach Cisco, przy czym na Cisco domyślnie jest deny all.

Moje reguły przyjmują politykę drop na cały ruch sieciowy. Reguły wycinają wszystko i musisz zezwolić na to co potrzebujesz.

Piszę o domyślnej konfiguracji domowych urządzeń hAP itd.

Nie mam pod ręką takiego świeżo z pudełka, ale chyba są fabrycznie ustawione z pierwszym portem jako WAN, pozostałymi jako LAN spięty bridge, i właśnie takim zestawem reguł.

edit
Są domyślnie ustawione, nawet instrukcja o tym wspomina.

Na każdym RB jest ten sam skrypt. W domu mam hAP Lite i firewall zawsze był czysty. Nie ma to znaczenia czy to SoHo czy CCR, skrypt jest ten sam, soft jest ten sam i na żadnym nie ma skonfigurowanego firewalla, a przerabiam naprawdę sporo Mikrotików.

Domyślnie tak, jeden port jest WAN, reszta bridge, ale firewall jest czysty, poza włączonym fasttrack, jeśli dobrze pamiętam. Zdarzało mi się też spotykać Mikrotiki w domyślnej konfiguracji, bo ktoś je sprzedał, podłączył w domyślnej konfiguracji i nawet hasła nie ustawił. Ktoś wcisnął sprzęt, ale nawet nie poświęcił czas na konfigurację. Każde było bez hasła z czystym firewallem.

Wydaje mi się że są domyślnie wrzucone reguły z komentarzem “defconf”, chyba że były wygenerowane przez quicksetup.

Nawet w dokumentacji mają

We strongly suggest to keep default firewall on.

Specjalnie zresetowałem swój hAP, aby zobaczyć jak to obecnie wygląda. Zwracam honor, miałeś rację :wink: Możliwe, że Mikrotik zmienił swój skrypt.

Nawet dodali ostatnio regułę która umożliwia podłączenie się do CAPSMANA z tego samego urządzenia (defconf: accept to local loopback (for CAPsMAN)). Widać więc że co jakiś czas nawet coś dodadzą. Wcześniej trzeba było to ręcznie dodawać.

Dzięki za tak liczne odpowiedzi :slight_smile: Już wiem coś więcej. Mam jeszcze pytanie odnośnie układania reguł. Czytam o zasadzie układania reguł od góry i jednego nie rozumiem: najpierw powinny być dozwolone a później odrzucone, czy zasada przetwarzania jest trochę inna? Ogarniam wszystko według poradnika ze strefy kursów, ale gość nie jest wcale takim świetnym nauczycielem jak pisali w komentarzach :frowning:

Mają coś na blokowanie CNAME “first party tracking”?

Dziś wpadł mi w ręce Hex S i CCR. W każdym przypadku skrypt generuje te same reguły, czyli nie ma znaczenia czy to SOHO czy CCR :wink:

RouterOS bazuje na kernelu Linux i jego filtrze pakietów. Jak w większości routerów, reguły są sprawdzane po kolei. Jeśli robisz drop all, czyli przyjmujesz politykę deny all, to drop powinien być zawsze na końcu. Co kolejności konkretnych reguł drop lub accept, to zależy na co zezwalasz lub co chcesz blokować. Reguły accept muszą być zawsze nad regułami established, related. Co do dropów, jeśli chcesz odrzucać 53/udp na interfejsie WAN, lepiej dać ją wyżej, aby pakiet nie był sprawdzany przez każdą regułę (zmniejszasz obciążenie CPU).

Nie wiem o co dokładnie chodzi, ale masz webproxy, firewall layer7.

Podejrzewam że z którąś wersja ROS się pojawiły. Właśnie to w tym systemie jest najlepsze. Nie ważne jak stary sprzęt. Jeżeli hardware udźwignie to masz praktycznie wieczystą aktualizację :smiley: