Firewall filter w MikroTik RouterOS

19 maja 2015, 12:05 | Teksty | komentarzy 5
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.

Niniejszy tekst jest drugą częścią serii artykułów o firewallu MikroTika. Dotychczas opublikowany został jeszcze jeden tekst:

Cel

Filter Rules (reguły filtrowania) to jeden z trzech elementów firewalla w systemie RotuerOS. Jego podstawowy cel to zapewnienie bezpieczeństwa poprzez odrzucenie ruchu niespełniającego określonych warunków. Moduł ten pełni funkcję analogiczną do reguł ACL (Access Control List) spotykanych u wielu innych producentów.

Praca z regułami

Ze względu na zwięzłość przekazu, w tekście będziemy się posługiwać poleceniami do interfejsu CLI (Command Line Interface), czyli do wpisania do terminala. Natomiast, w szczególności dla początkujących, zalecana jest obsługa reguł firewalla przez interfejs graficzny w narzędziu MikroTik WinBox. Reguły prezentowane w ten sposób są bardziej czytelne, a operowanie nimi (kopiowanie, modyfikacja, zmiana kolejności itp.) bardziej naturalne.

Translacja poleceń CLI na operacje w interfejsie graficznym nie powinna stanowić problemu, ponieważ ścieżki w drzewie konfiguracji oraz nazwy pól są prawie zawsze niemal identyczne. Przykładowo, gałąź /ip firewall filter odpowiada oknu IP > Firewall > Filter Rules w interfejsie graficznym. Częstą praktyką jest dodanie reguł (np. ze skryptu lub kopii zapasowej) przez terminal i dalsza praca nad nimi przez WinBoxa.

1. Budowa reguł

Reguły filtrowania dodajemy w drzewie konfiguracji /ip firewall filter. Domyślną polityką w RouterOS jest akceptowanie pakietów, zatem przy pustej konfiguracji żadne pakiety nie są blokowane. Pusta konfiguracja nie oznacza domyślnej konfiguracji, bo dla większości routerów domyślny jest zestaw reguł blokujących dostęp z sieci WAN (szczegółowe informacje o domyślnej konfiguracji w zależności od płyty RouterBoard znajdują się na stronie z dokumentacją MikroTika). W niniejszym tekście za punkt wyjścia przyjmujemy pustą listę reguł. W razie potrzeby domyślnie dodane reguły możemy wyczyścić poleceniem:

Dodając nową regułę, możemy określić szereg (około 50) jej właściwości. Podzielmy te pola na trzy kategorie:

  • wybór łańcucha (chain),
  • pola warunkowe,
  • pola akcji.

Pełna lista pól wraz z ich opisem dostępna jest w Wiki MT:

2. Chain

Wybór łańcucha (pole chain) to pole obligatoryjne. Odpowiada za to, jakiego rodzaju ruchu i na którym etapie przetwarzania może dotyczyć reguła. Mamy do wyboru trzy łańcuchy predefiniowane:

  • input – ruch przychodzący (przez jeden z interfejsów), kierowany do routera (czyli pakiety, których adres docelowy jest tożsamy z jednym z adresów IP routera). Łańcucha input używa się do zabezpieczenia routera.
  • output – ruch wychodzący (przez jeden z interfejsów) od routera (czyli pakiety, które zostały wykreowane przez router, tj. adres IP routera jest adresem źródłowym pakietu). Łańcuch output jest rzadko wykorzystywany.
  • forward – ruch przechodzący przez router. Łańcucha forward używa się do zabezpieczania sieci podłączonych do routera.

Zakres działania łańcuchów predefiniowanych jest rozłączny. Innymi słowy, dany pakiet może być przetwarzany tylko w obrębie jednego z ww. łańcuchów.

System pozwala na definiowanie własnych łańcuchów. Używane są one do zwiększenia efektywności oraz czytelności firewalla.

Ruch w łańcuchu zdefiniowanym przez użytkownika musi pierwotnie pochodzić z któregoś z łańcuchów domyślnych. Możliwe jest kierowanie ruchu z różnych łańcuchów (zarówno z kilku łańcuchów domyślnych oraz zdefiniowanych) do łańcucha zdefiniowanego. Można wrócić ruch z łańcucha zdefiniowanego do łańcucha domyślnego, ale nie jest możliwe kierowanie ruchu do innych łańcuchów domyślnych. Nie jest także możliwe łączenie łańcuchów w pętle.

3. Pola warunkowe

Pól warunkowych w konfiguracji reguły jest zdecydowanie najwięcej, natomiast żadne z nich nie jest obligatoryjne. Pola te określają warunki, jakie musi spełniać pakiet, aby podlegać zdefiniowanej przez regułę akcji. Najczęściej używane pola określają źródłowy/docelowy adres w nagłówku pakietu IP (src-address, dst-address), protokół i porty (protocol, src-port, dst-port), stan połączenia (connection-state).

4. Pola akcji

Podstawowe pole tej grupy to action (domyślnie accept). Określa ono, co ma się stać z pakietem, który należy do wybranego łańcucha i spełnia określone pola warunkowe. Podstawowe akcje to:

  • accept – pakiet jest akceptowany,
  • drop – pakiet jest odrzucany.

Akcje add-src-to-address-list i add-dst-to-address-list powodują dynamiczne dodanie adresu (źródłowego – src, lub docelowego – dst) zapisanego w nagłówku przetwarzanego pakietu IP do listy adresów o nazwie określonej dodatkowym parametrem (address-list). Dodatkowo, możemy określić czas timeout, przez jaki wpis do listy adresów ma być aktywny. Jest to dość praktyczny mechanizm, dalej w tekście przedstawiamy przykład jego użycia.

  • Akcja jump służy do przekazywania pakietu do innego (zdefiniowanego przez użytkownika) łańcucha, a akcja return wraca pakiet do miejska, z którego została wywołana akcja jump. Domyślnie na końcu każdego łańcucha zdefiniowanego przez użytkownika jest niejawna reguła wykonująca akcję return.
  • Akcja passthrough to w zasadzie brak akcji – pakiet jest przekazywany do następnej reguły. Użycie tej akcji może mieć zastosowanie do celów statystycznych.
  • Akcja reject jest podobna do drop (odrzuca pakiet), z tym że dodatkowo wysyła informację ICMP o odrzuceniu. Akcja tarpit przechwytuje połączenie TCP (odpowiada pakietem SYN/ACK na przychodzący pakiet TCP SYN). Akcje reject oraz tarpit są rzadko używane w praktyce.
  • Pola log, log-prefix pozwalają na logowanie informacji o każdym pakiecie, dla którego została zastosowana akcja.

Pozostałe pola tej grupy mają zastosowanie tylko do konkretnych akcji, np. pole address-list jest stosowne tylko dla akcji add-src-to-address-list oraz add-dst-to-address-list.

5. Zasada działania

Reguły są przetwarzane sekwencyjnie. Pakiet najpierw jest przetwarzany przez pierwszą (od góry) regułę na liście. Jeżeli należy do określonego łańcucha oraz spełnia kryteria ustawione w polach warunkowych, to aplikowana jest przypisana do reguły akcja i pakiet nie jest już przetwarzany przez kolejne reguły (chyba, że ustawiona akcja to passthrough lub jump). Warunki ustawione w regule rozpatrywane są łącznie, więc jeśli pakiet nie spełnia przynajmniej jednego z nich, to akcja nie jest stosowana i pakiet jest przekazywany do rozpatrzenia przez kolejną regułę. Jeżeli żadna z reguł nie złapie pakietu, to stosowana jest akcja domyślna, czyli accept.

Dobre praktyki

Wiemy już jak działają reguły filtrowania i jak je dodawać. Zastanówmy się teraz, jak zbudować dobry zestaw reguł. Dobry – czyli realizujący zakładaną politykę, optymalizujący wykorzystanie procesora oraz przejrzysty i wygodny w zarządzaniu.

Poniżej przedstawiamy zestaw wskazówek, które pomogą ten cel osiągnąć.

1. Zaplanuj zanim wykonasz

Jeśli nie zostało to wcześniej wykonane, budowanie firewalla zacznij od ustalenia i przemyślenia polityki, jaką firewall powinien realizować. Można ją zapisać w postaci np. listy zasad lub macierzy, która obrazuje, jaka komunikacja pomiędzy jakimi sieciami jest dozwolona (przykład poniżej).

fw filter tab_1

2. Jasna struktura 

Wszys­tko na­leży up­raszczać jak tyl­ko można, ale nie bar­dziej.

– genialna wskazówka Alberta Einsteina uchroni nas od wielu błędów i ułatwi pracę nad regułami w przyszłości.

Są dwa standardowe podejścia do konstrukcji reguł. Pierwsze polega na tym, że tworzymy zestaw reguł blokujących niepożądany ruch, pozwalając pakietom autoryzowanym na dojście do końca listy, gdzie czeka na nie zdefiniowana (lub domyślna, niejawna) reguła typu accept.

fwfilter_2

Drugie podejście jest odwrotne: definiujemy reguły określające autoryzowany ruch, a pozostały blokujemy.

fwfilter_1

Podejście drugie jest zalecane z dwóch powodów.

Po pierwsze, konstrukcja, w której jawnie określamy dozwolony, prawidłowy ruch, ma tendencję do bycia bardziej bezpieczną. Określając ruch do zablokowania (potencjalnie szkodliwy), łatwiej o przeoczenie nietypowych zagrożeń.

Po drugie, z reguły znacznie więcej ruchu przepuszczamy przez firewall niż odrzucamy. Zatem struktura pokazana na drugim rysunku jest bardziej wydajna (mniej obciąża procesor). W przypadku pierwszej, większość pakietów musi przejść przez wszystkie reguły. W przypadku drugiej, tylko nieliczne.

3. Własne łańcuchy (chains)

Jeżeli pewna część ruchu, którą da się łatwo wyodrębnić (np. pakiety wychodzące z określonej podsieci IP), wymaga specjalnego potraktowania, to przekieruj ten ruch do własnego łańcucha i wewnątrz niego zastosuj filtrowanie. Zwiększy to czytelność i efektywność firewalla, gdyż pozostałe pakiety (niewymagające specjalnego traktowania) będą przetwarzane przez pojedynczą regułę typu jump. Ilustruje to poniższy przykład, w którym dla części ruchu potrzebujemy wyodrębnić dodatkowe 4 reguły blokujące.

fwfilter_3

fwfilter_4

Jak widać, tylko część pakietów w tej sytuacji jest przetwarzana przez reguły 5-8. Pakiety, które zostały przechwycone przez regułę return (istniejącą domyślnie na końcu łańcucha zdefiniowanego przez użytkownika), wracają do głównego łańcucha, do reguły nr 1.

4. Używaj komentarzy

Dodając reguły filtrowania, opisuj w komentarzu, jaki jest jej cel. Znacznie ułatwi to diagnostykę problemów oraz modyfikację reguł w przyszłości.

5. Używaj list adresów

Zamiast dodawać wiele analogicznych reguł dla różnych adresów IP – użyj listy (/ip firewall address-list).

6. Kolejność reguł

Spośród reguł wykonujących tę samą akcję, te, które przechwytują najwięcej ruchu, umieszczaj na początku. Dzięki temu zmniejszy się średnia liczba reguł, przez które jest przetwarzany pakiet.

7. Zweryfikuj działanie

Zarówno po implementacji firewalla, jak i po każdej jego modyfikacji, sprawdź, czy firewall działa zgodnie z założeniami. Nieprzetestowane modyfikacje firewalla są niezwykle częstą przyczyną problemów.

Weryfikacja działania na podstawie inżynierskiego eksperymentu myślowego okazuje się bowiem zwykle niewystarczająca.

Przykład 1 – zabezpieczenie routera

Poniżej zestaw poleceń dodających przykładowe reguły zabezpieczające dostęp do routera.

Wszystkie reguły dotyczą wbudowanego łańcucha input, czyli ruchu kierowanego do routera (ale nieprzechodzącego przez router).

Pierwsze trzy reguły pozwalają na działanie protokołu ICMP do celów diagnostycznych oraz usług SSH i WinBox do zarządzania. Reguła SSH akceptuje pakiety na porcie 22 (standardowy SSH), ale w przypadku, gdy router jest podłączony do Internetu, zalecana jest zmiana tego portu (w /ip service) – jeżeli nie chcemy oglądać w logach natłoku informacji o próbach włamania do naszego routera przez grasujące po Internecie boty.

Kolejne dwie reguły to zezwolenie na zapytania DNS. Zakładamy tu, że nasz router pełni funkcję serwera DNS dla sieci lokalnej, która znajduje się na interfejsie bridge_lan.

Następna para reguł pozwala na połączenia zestawione i powiązane z nimi. Pozwala to routerowi na wykonywanie połączeń do innych hostów, w szczególności na dostęp do Internetu (np. w celu synchronizacji czasu przez NTP). Ponieważ nie definiowaliśmy reguł dla łańcucha output, pakiety generowane przez router wychodzą bez żadnego filtrowania, natomiast nawiązywane połączenia są rejestrowane (/ip firewall connection). Pakiety przychodzące w ramach tych połączeń (poniekąd „wracające” z Internetu) trafiają do łańcucha input i są akceptowane przez reguły, o których właśnie mówimy.

Ostatnia reguła blokuje pakiety, które nie załapały się na żadną z ww. reguł.

 

Przykład 2 – firewall firmowy

Zabezpieczymy teraz komunikację w ramach przykładowej sieci firmowej. Poniższa tabela przedstawia macierz akceptowanych połączeń:

fw filter tab_2

Oto konfiguracja reguł: oprócz typowego filtrowania pakietów, zastosujemy podstawową ochronę przed atakami DoS (Denial of Service) dla serwerów w strefie DMZ, aby pokazać w praktyce szerszy wachlarz możliwości firewalla.

Pierwsze dwie reguły (0 i 1) akceptują ruch wychodzący z sieci DMZ, będący częścią ustanowionych połączeń. Załatwia nam to środkową kolumnę tabelki. Komunikacja pomiędzy maszynami w DMZ (tak samo jak pomiędzy pracownikami) odbywa się w obrębie danej domeny rozgłoszeniowej (nie przechodzi przez router), stąd nie są potrzebne dodatkowe reguły firewalla zezwalające na ten ruch. Reguły 0 i 1 nie określają adresu docelowego, gdyż zgodnie z tabelą, wszystkie zestawione połączenia wychodzące z DMZ powinny być akceptowane. W ten sposób mamy nieco prostszy (o 2 reguły krótszy) firewall.

Kolejna reguła (2) przekierowuje ruch kierowany na port TCP 80 (protokół HTTP) do nowego łańcucha: dmz. W łańcuchu tym mamy 3 reguły stanowiące proste zabezpieczenie przed atakami DoS polegającymi na zestawianiu dużej liczby połączeń TCP. Pierwsza z tych reguł (7) blokuje ruch z adresów wpisanych na listę atak_dos_blokada. Druga reguła dodaje na tę listę (na czas 24 godzin) adresy hostów, które próbowały zestawić jednocześnie ponad 100 połączeń do hostów w sieci DMZ. Dodatkowo, reguła ta zapisuje do logów informację z prefixem „atak dos”. Trzecia reguła akceptuje pozostały ruch w łańcuchu dmz (wyłączając go z dalszego przetwarzania).

Wracając do głównego łańcucha (forward), kolejne reguły (3 i 4) akceptują ruch przychodzący do pracowników w ramach zestawionych połączeń. Załatwia nam to pierwszy wiersz macierzy. Analogicznie jak w przypadku reguł 0 i 1, nie jest potrzebny warunek określający adres źródłowy, dzięki czemu oszczędzamy kolejne 2 reguły.

Reguła nr 5 akceptuje ruch wychodzący od pracowników do Internetu. Użyte są dwa warunki określające źródło (interfejs oraz źródłowy adres IP), co dodatkowo zabezpiecza przed wysyłaniem pakietów ze zmodyfikowanym źródłowym adresem IP z innej sieci (IP spoofing), np. ze skompromitowanego serwera w strefie DMZ.

Ostatnia reguła łańcucha forward (6), blokuje pozostały ruch.

Zależności

Tworząc konfigurację firewalla, należy pamiętać o zależnościach pomiędzy różnymi mechanizmami.

Po pierwsze, aby działały funkcje związane ze stanem połączeń, funkcja śledzenia połączeń nie może być wyłączona. Domyślna wartość przełącznika (auto) powoduje, że śledzenie połączeń jest włączone, gdy istnieje przynajmniej jedna reguła firewalla. Z drugiej strony, jeśli w firewallu nie używamy żadnych reguł wymagających śledzenia połączeń, wyłączając tę funkcję, osiągniemy znaczną oszczędność mocy obliczeniowej procesora. Można tego dokonać poleceniem:

Druga ważna zależność dotyczy kolejności przetwarzania przez różne mechanizmy. Kompletny graf dostępny jest na Wiki MikroTika.

Wróćmy na chwilę do drugiego przykładu. Rutynowo w takich sytuacjach router wykonuje SRC-NAT na pakietach wychodzących do sieci Internet i DST-NAT na pakietach przychodzących z Internetu do sieci lokalnej. W takiej sytuacji, pakiety przychodzące do routera z Internetu są kierowane de facto na adres IP przypisany do routera. W świetle tego co pisaliśmy wcześniej o łańcuchach, pakiety te powinny trafić do łańcucha input (a nie forward). DST-NAT (część bloku Prerouting) wykonuje się jednak przed blokiem Routing Decision, który odpowiada za kierowanie pakietu do łańcucha Input lub Forward. Ponieważ translacja została wykonana wcześniej, to pakiet trafia do łańcucha Forward i na tym poziomie widzimy go już z adresem lokalnym.

–Bartłomiej Dabiński

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. jancyk

    Bardzo pożyteczna lektura. Tylko prosze, skupcie sie na tym z czym ludzie szczegolnie na poczatku przygody z mikrotkiem maja najwieksze problemy… PACKET FLOW. wiekszosc pytan na forach mikrotikowych obija sie o brak dobrego zrozumienia przeplywu pakietow. Wiem, sa grafy, niezmienia to jednak faktu ze dla wielu poczatkujacych sa niezrozumiale. Tym bardziej ze nie jest nigdzie lopatologicznie wytlumaczone ‚jak to praktycznie dziala’.
    A rozumiejac packet flow, markowanie, shapeing, routing, staja sie niewiarygodnie latwiejsze do konfiguracji.

    Dajmy wedke a nie rybke ;)

    Odpowiedz
    • Artykuł sam w sobie dobry. Jednak nie zgadzam się z kolegą jancyk, nie widzę potrzeby aby opisywać podstawy (zdaje się, że jest to miejsce dla bardziej zaawansowanych użytkowników) przepływu pakietów. Patrząc w ten sposób należy rozpocząć od przepisania wikipedi odnośnie protokołu TCP później tłumaczyć jak się wkomponowuje tam IP. Bardzo dobrym pomysłem jest rozwal.to oraz artykuł „Wprowadzenie do ids”, które aby „umieć odczytać/wykonać” trzeba mieć wiedzę dalece większą niż przysłowiowy PACKET FLOW, że nie wspomnę o routingu klasach IP itp

      Wydaje mi się, że jak idziesz do szkoły gotowania to nikt Cie nie uczy obierania ziemniaków.

      Dajmy im silnik do łodzi rybackiej, bo tego im brakuje, to zarobią na swoje rodziny, siebie i podszkolą pozostałych ;-)

      Odpowiedz
  2. orge

    Masz racje, tylko nie każdy używał IP tables, a sformułowania postrouting i prerouting mogą być dla niego nie do końca zrozumiałe. Pamiętajmy że są różne sposoby łowienia , różne rodzaje wędek, różnymi łodziami też można pływać na łowiska. I nie ma takich osób co znają każdy sposób łowienia i każdy sprzęt do tego a wbrew pozorom potrafią bardzo dobrze łowić i nadal chcą poznawać nowe sposoby choćby wiązało się to z przejściem szkolenia od początku z racji innego uchwytu na wędce :D

    Odpowiedz
  3. Michał

    Świetny tekst, bardzo mi się przydał bo rozjaśnił kilka spraw. Poproszę więcej na temat RouterOS :)

    Odpowiedz
  4. Michał

    Dzień dobry,

    Proszę o podpowiedź czy takie dwie reguły powinny się znajdować w konfiguracji:
    ;;; default configuration
    chain=forward action=accept connection-state=established log=no log-prefix=””

    ;;; default configuration
    chain=forward action=accept connection-state=related log=no log-prefix=””

    Czy nie wystarczą takie reguły w łańcuchu input do wyjścia na świat? Proszę o wyrozumiałość, dopiero zaczynam przygodę z RouterOS

    Odpowiedz

Odpowiedz