MikroTik RouterOS – dlaczego nie działa
W tym artykule postaramy się wylistować i opisać najczęściej spotykane błędy w konfiguracji MikroTik RouterOS. W ostatnich latach podczas audytów konfiguracji, konsultacji i szkoleń niejednokrotnie spotkaliśmy się z elementami ustawień, które mogły doprowadzić lub doprowadziły do kłopotów. Część z nich wydaje się błaha i podstawowa, jednakże i o nich warto wspomnieć. Niejednokrotnie tego typu błędy zdarzają się „starym wyjadaczom”, pracującym wiele lat w IT, na co dzień korzystającym z urządzeń MikroTik RouterOS. Czy to rutyna, chyba tak …
1. Ograniczenie dostępu do usług zarządzania.
Domyślnie wszystkie metody zarządzania routerem są dostępne na każdym zaadresowanym interfejsie. Dobrą praktyką jest ograniczenie zarządzania jedynie do wydzielonego segmentu sieci tzw. Management Network. W mniejszych instalacjach spotyka się także podeście z dostępem do zarządzania z sieci LAN. Ten pierwszy sposób jest preferowany. Mamy nadzieję, że bez względu z którego z podejść korzystasz na co dzień, zgodzisz się, że udostępnianie możliwości podłączenia się do urządzenia poprzez interfejs WAN (w szczególności, gdy router posiadania publiczny adres IP) to zły pomysł.
Możliwości ograniczenia dostępu jest kilka. Po pierwsze, za pomocą zakładki IP -> Services możliwe jest ograniczenie danej metody do wskazanych adresów IP lub podsieci. Drugą i bardziej zalecaną metodą jest wykorzystanie IP -> Firewall filter.
IP Firewall weryfikowany jest wcześniej niż IP->Services dzięki temu metoda ta jest wydajniejsza i bardziej pewna. Pakiet iptables jest znany od lat, przez co szansa na występowanie w nim podatności jest niewielka.
Gdy rozważamy dostęp do zarządzania, często zdarza się, że administratorzy nie weryfikują i nie ograniczają dostępu do zarządzania dla protokołów warstwy drugiej modelu OSI (Tools -> MAC server)
W konfiguracji narzędzia wykorzystuje się Interface List – rodzaj słownika definiowanego w oknie Interfaces. Zalecane jest utworzenie wydzielonej sieci, portu dla dostępu zarządzania L2, np. lista MGNT i wskazanie tylko niej dla MAC Winbox , MAC Telnet.
Co należałoby zrobić, gdy potrzebny jest dostęp do zarządzania z zewnątrz organizacji? Nic prostszego. Od tego mamy VPN (np. L2TP + IPSEC, SSTP i inne).
2. Aktualizacja oprogramowania
Nie da się nie wspomnieć przy tego typu artykule o aktualizacji oprogramowania routera. W przypadku urządzeń Routerboard aktualizacji podlegają dwa elementy. Oprogramowanie systemowe (Packages) oraz firmware (Routerboard).
Metod aktualizacji jest wiele. Do najpopularniejszych zaliczyć można: ręczną za pomocą System -> Packages, zautomatyzowaną za pomocą własnych skryptów lub z wykorzystaniem oprogramowania DUDE.
Przykładowy skrypt ilustrujący proces:
:global updChannel “current”
:local mailAdmin “info@mwtc.pl”
# zmienna okreslajaca czy aktualizowac takze firmware
:local firmwareUpdate 0
#przejscie do odpowiedniego poziomu drzewa konfiguracji
/system package update
# sprawdzenie jaka jest aktualna wersja
set channel=$updChannel
/system package update check-for-updates
#trzeba zaczekac aby RouterOS sprawdzil na serwerach Mikrotik i mial wynik
:delay 15s;
#jesli wersja zainstalowana rozni sie od obecnej to dokonaj aktualizacji
:if ([get installed-version] != [get latest-version]) do={
#przed aktualizacja wysle powiadomienie do administratora
/tool e-mail send to=$mailAdmin subject=$mailTeamtOS body=$mailWiadomoscOS
#dodatkowo takze dodam wpis w log, przechowywanie logow poza pamiecia RAM
:log info $mailWiadomoscOS
# Wait for mail to be send & upgrade
:delay 10s;
# instalacja paczki (wykona restart urzadzenia)
install
} else={
:if ($firmwareUpdate = 1) do={
# RouterOS latest, let’s check for updated firmware
:log info (“Nie znaleziono paczek do zainstalowania, sprawdze teraz czy jest firmware do aktualizacji”)
/system routerboard
:if ([get current-firmware] != [get upgrade-firmware]) do={
#przed aktualizacja wysle powiadomienie do administratora
/tool e-mail send to=$mailAdmin subject=$mailTeamtFW body=$mailWiadomoscFW
#dodatkowo takze dodam wpis w log, przechowywanie logow poza pamiecia RAM
:log info $mailWiadomoscFW
# Zaczekam aby wyslal sie mail
:delay 10s;
upgrade
# zaczekam aby wykonala sie aktualizacja i restart urzadzenia
:delay 180s;
/system reboot
} else={
:log info (“Nie znaleziono nowszej wersji firmware”)
}
} else={
:log info (“Nie znaleziono paczek do zainstalowania, koncze swoje dzialanie”)
}
}
Następnie kod wklejamy w zadanie System -> Scheduler, odpowiedzialny za cykliczne wykonanie sprawdzenia i w razie potrzeby dokonanie aktualizacji.
Każdy z administratorów ma własną politykę aktualizacji i zgodzimy się, że nie ma jedynej słusznej. Wszystko zależy od krytyczności urządzenia, od zastosowanych metod wysokiej dostępności, czy stosowanych metod monitorowania w razie niepowodzenia aktualizacji i problemu z działaniem routera.
3. Brak kopii bezpieczeństwa
W przypadku aktualizacji oprogramowania można powiedzieć, że nie ma jedynej słusznej drogi. W przypadku kopii bezpieczeństwa, każdy (bezwzględnie) powinien dbać o posiadanie aktualnych kopii. Zazwyczaj ręczne kopie po wykonaniu zmiany nie sprawdzają się na dłuższy czas, stąd zachęcamy do zaplanowania tego zadania w sposób automatyczny. Tu z pomocą może przyjść skrypt uruchamiany cyklicznie, odpowiedzialny za wykonanie kopii bezpieczeństwa i przesłanie jej na (backup i/lub export) na zewnętrznych serwer FTP lub SFTP. Przykładowy skrypt znajduje się poniżej:
# dodam funkcje do zmiany znaków w tekscie
:global strReplaceFunc
#Zmienna na przechowanie nazwy pliku
:local fileNameExport “”;
:local fileNameBackup “”;
#dane do polaczenia FTP
:local ftpHost “”
:local ftpUser “ftp”
:local ftpPass “”
:local ftpDstPath “”
:local ftp2Host “”
:local ftp2User “”
:local ftp2Pass “”
:local ftp2DstPath “”
#zapisanie do zmiennej identity routera
:local identity [/system identity get name];
#zapisanie daty do zmiennej
:local date [/system clock get date];
#zapisanie czasu do zmiennej
:local time [/system clock get time];
#zapisanie wersji routerOS
:local version [/system package update get installed-version];
#zmienie niepozadane znaki w dacie i czasie
:set date [$strReplaceFunc text=$date];
:set time [$strReplaceFunc text=$time];
#ustalenie nazwy pliku skladajacego sie z identity, daty i czasu
:set fileNameExport (“configExport-“.$identity.”-“.$version.”-“.$date.”-“.$time);
:set fileNameBackup (“configBackup-“.$identity.”-“.$version.”-“.$date.”-“.$time);
:put $fileNameBackup
#eksport konfiguracji do pliku
/export file=$fileNameExport;
/system backup save name=$fileNameBackup
#wyslanie pliku do zdalnego serwera FTP
/tool fetch address=$ftpHost src-path=($fileNameExport.”.rsc”) dst-path=($ftpDstPath . “Uploaded-export-“.$fileNameExport.”.rsc”) \
upload=yes mode=ftp user=$ftpUser password=$ftpPass
/tool fetch address=$ftpHost src-path=($fileNameBackup.”.backup”) dst-path=($ftpDstPath . “Uploaded-backup-“.$fileNameBackup.”.backup”) \
upload=yes mode=ftp user=$ftpUser password=$ftpPass
#wysylanie na zapasowy serwer FTP, jesli zostal zdefiniowany
:if ([:len $ftp2Host] != 0) do={
/tool fetch address=$ftp2Host src-path=($fileNameExport.”.rsc”) dst-path=($ftp2DstPath . “Uploaded-export-“.$fileNameExport.”.rsc”) \
upload=yes mode=ftp user=$ftp2User password=$ftp2Pass
/tool fetch address=$ftp2Host src-path=($fileNameBackup.”.backup”) dst-path=($ftp2DstPath . “Uploaded-backup-“.$fileNameBackup.”.backup”) \
upload=yes mode=ftp user=$ftp2User password=$ftp2Pass
}
Dodatkowo do jego działania, aby zmodyfikować string tworzący nazwę pliku wykorzystywana jest funkcja pomocnicza strReplaceFunc której ciało znajduje się poniżej:
:global strReplaceFunc do={
# parametr z tekstem do sprawdzenia
:local stringBefore $text
# zmienna zwracana jako wynik po dokonaniu zmiany znakow
:local stringAfter
# tablica przechowujaca jako klucz niepozadany znak, a jako wartosc znak na ktory ma zostac dokonana podmiana
:local zleznaki {” “=”-“;”/”=”-“;”:”=”-“;}
#iteracja po kazdym znaku
:for i from=0 to=([:len $stringBefore] – 1) do={
# zapis znaku do zmniennej do porownania czy jest jednym z niepozadanych
:local char [:pick $stringBefore $i]
# weryfikacja znaku
:foreach zly,nowy in=$zleznaki do={
# jesli jest niepozadany to zmiana
:if ($char=$zly) do={
:set $char $nowy;
}
}
# aktualizuje ciag ktory zwracam
:set stringAfter ($stringAfter . $char)
}
#zwrocenie zmiennej jako wynik dzialania funkcji
:return $stringAfter
}
# przykladowe wywolanie
:put [$strReplaceFunc text=”jul/16/2018 11:33:22″];
4. Problemy z DNS
W RouterOS zaimplementowano funkcjonalność resolvera DNS. To na pozór prosta funkcjonalność, odpowiadająca za rozwiązywanie nazw DNS dla klientów. Dzięki niej możliwe jest wysłanie do routera DNS request i otrzymanie odpowiedzi. Warto jednak pamiętać, że włączenie tej opcji – Allow Remote Request powoduje, że zaakceptowane i obsłużone zostaną zapytania trafiające na każdy zaadresowany IP interfejs. Gdy router posiada publiczny adres IP każdy może przesłać do niego zapytanie. Najczęściej takie niefortunnie wystawione na świat serwery DNS wykorzystywane są jako zombie do wykonywania ataku DDoS. Dodatkowo, gdy liczba zapytań będzie duża, nasz router może zostać przeciążony.
Sposób ochrony jest dość prosty i sprowadza się do pamiętania, aby określić skąd dopuszczane są zapytania DNS (tcp/53, udp/53) poprzez odpowiednie reguły IP – Firewall (łańcuch Input).
5. Problemy z NAT
SRC-NAT
Tu najczęściej spotykamy się ze zbyt ogólnymi regułami NAT, a w szczególności brakiem precyzyjnego określenia adresacji i interfejsów źródłowych i docelowych. Skutkuje to zazwyczaj zwiększonym obciążeniem CPU z racji dokonywania translacji zbyt dużej części ruchu. Drugim problemem jest wówczas nieszczelność reguł Firewall spowodowana zamaskowaniem adresacji.
DST-NAT
Doświadczenia pokazały, że zbyt często administratorzy uciekają się do wykorzystania dst-nat jako najprostszej metody udostępniania zasobów wewnętrznych dla zdalnych pracowników i kontrahentów. Znacznie częściej widzimy to zjawisko od roku, gdy wiele firm zostało zmuszonych do „ewakuacji” personelu do domu i rozpoczęcia działania w trybie zdalnym. Nagminnym faktem są udostępnione pulpity zdalne (RDP) do maszyn nie aktualizowanych od lat, nieposiadających silnych haseł dla kont użytkowników. To prosta droga do utraty lub wykradzenia danych stanowiących o wartości przedsiębiorstwa.
Problem można dość łatwo rozwiązać stosując wspomniane wcześniej połączenia VPN.
6. Brak logów
Z wywiadów wśród kursantów i firm dla których realizujemy projekty sieciowe jasno wynika, że niewielki odsetek z nich posiada poprawnie zaprojektowany system do kolekcji logów z urządzeń. Część z nich nie zbiera logów wcale.
Należy zwrócić uwagę, że skomplikowanie infrastruktury i wartość przetwarzanych przez systemy informatyczne danych cały czas rośnie i to właśnie logi są elementem pozywającym na analizę problemu i postawienie diagnozy. Są także nieocenione jako element analizy po włamaniu pozwalając niejednokrotnie na wskazanie źródła ataku oraz ewidencję zasobów, do których atakujący uzyskał dostęp.
W tym artykule nie będziemy się skupiać na kompleksowym sposobie kolekcji, przetwarzania i analizy logów –temat jest zbyt obszerny. Z pewnością wrócimy kiedyś z tym tematem jako osoby artykuł.
Teraz jedynie pokażemy jak szybko ustawić przesyłanie logów na posiadany serwer syslog (może to być np. serwer NAS z aplikacją „serwer logów”, większość producentów daje opcję doinstalowania takowej lub posiada ją zainstalowana domyślnie). Alternatywnie można rozważyć użycie jednego z popularnych projektów open-source: rsyslog, graylog, ELK.
7. Problemy z połączeniami IPSEC
Kluczowe do rozwiązania większości problemów z połączeniami IPSEC jest uświadomienie sobie, gdzie dokładnie w procesie Packet Flow dokonywana jest decyzja o zaszyfrowaniu/ odszyfrowaniu ruchu. Przedstawia to uproszczony schemat poniżej:
Analiza schematu wyjaśnia co zrobić, aby rozwiązać najczęstszy problem opisywany jako: sesja IPSEC jest „established”, a nie działa.
Problem związany jest poniekąd z już wcześniej wspomnianym NAT. Często administratorzy dodają zbyt ogólne reguły src-nat. Zwróć uwagę, że jeśli nie zostanie ograniczona adresacja dla src-nat najczęściej ruch mający trafić w tunel IPSEC zostanie zanatowany (zmieniony adres źródłowy) przez co nie będzie pasował do IPSEC Policy (za Postrouting). Można to rozwiązać na dwa sposoby: ograniczyć reguły src-nat lub dodać odpowiednio wysoko regułę z akcją accept dla ruchu określonego w IPSEC Policy.
Drugi często spotykany problem z IPSEC to kwestia wydajności. Tu z pomocą przychodzi dokumentacja, która jasno wskazuje dla jakich urządzeń zapewnione jest wsparcie sprzętowe w IPSEC. Dodatkowo nie można zapomnieć, że nie na każdym urządzeniu wszystkie warianty pozwalają na zachowanie wsparcia sprzętowego. Zachęcamy do szczegółowego zapoznania się z poniższym linkiem:
https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Hardware_acceleration
i tabelą, której fragment zamieszczamy poniżej:
8. Bridge i VLAN
Kolejny często spotykany problem to zachowanie wysokiej wydajności na przełącznikach MikroTik. Po pierwsze kluczowe jest uświadomienie, że za wydajność w kontekście przełączenia w pełni odpowiedzialny jest dedykowany układ – nie CPU. Ilustruje to schemat blokowy dla przykładowego przełącznika:
Kolejnym krokiem jest upewnienie się, że układ w urządzeniu wspiera wymagane przez nas funkcje. Szczegółowy opis znajduje się na stronie:
https://help.mikrotik.com/docs/display/ROS/Switch+Chip+Features
Warto zwrócić uwagę, że nawet nowe urządzenia jak np. RB4011 posiadające układy dla sprzętowego wsparcia przełączania mogą nie wspierać, wydawałoby się podstawnych funkcjonalności, np. VLAN (to nie błąd, RB4011 – to jednak router).
Kolejny krok to poprawna konfiguracja. Tu czyha wiele pułapek, które spowodują wyłączenie wsparcia sprzętowego. Najcięższymi są:
- niepoprawna konfiguracja VLAN (o tematyce VLAN można pisać wiele, z pewnością wrócimy do tego tematu w szczegółach w przyszłych numerach)
- stosowanie bridge horizon
O tym, że wsparcie sprzętowe zostało deaktywowane może świadczyć brak flagi H, przy porcie w oknie Bridge -> Ports
9. Spoofing adresacji IP
Gdy zastanowimy się jak najczęściej wyglądają ataki DDoS, to pewnym wspólnym mianownikiem wielu z nich będzie Spoofing adresu IP. Wystąpi on wówczas, gdy z sieci dopuszczalne jest przesłanie pakietu z adresem źródłowym nie należącym do posiadanej przez nas adresacji.
Warto rozważyć zabezpieczenie się przed tym poprzez dodanie odpowiednich reguł IP Firewall lub też wykorzystanie mniej znanej opcji IP -> Settings -> RP Filter (Reverse Path Filter).
Domyślną wartością jest „NO”, co oznacza, że mechanizm uRPF (Unicast) nie jest aktywny. Warto rozważyć przełączenie tej opcji na strict lub loose (zalecane strict, stosowanie loose konieczne jest przy stosowaniu routingu asymetrycznego lub redundancji z wykorzystaniem interfejsów VRRP). Więcej o RP znajdziesz w RFC3704 (https://tools.ietf.org/html/rfc3704)+
10. Brak hasła
Ostatni błąd na liście, ale nie tak rzadko spotykany to zła polityka zarządzania użytkownikami. W ekstremalnym przypadku sprowadza się do pozostawienia konta admin bez hasła (ustawienie domyślne). W znacznej części jednak hasło jest zbyt krótkie lub będące szablonowym hasłem stosowanym w całej firmie.
Drugim zagadnieniem, o którym warto wspomnieć to stosowanie kont imiennych dla administratorów i serwisantów. Dzięki takiemu podejściu szybko zyskujemy: rozliczalność, granulację poziomu uprawnień.
Jeśli do tego dodamy centralny serwer uwierzytelniania Radius mamy komplet – dodaliśmy łatwe przydzielanie, zawieszanie i odbieranie uprawnień.
To może brzmieć jakby było trudne, ale tak nie jest. Jako serwer Radius można wykorzystać paczkę RouterOS UserManager. Konfigurując kilka zakładek zyskujemy to wszystko co opisaliśmy powyżej.
Routers – urządzenia, które mają prawo odpytywać serwer RADIUS
Profiles – profile przechowujące dodatkowe atrybuty użytkowników (trzeba dodać przynajmniej jeden profil)
Users – lista użytkowników z hasłami
Podsumowanie
Powyższa lista błędów nie stanowi oczywiście kompletnej bazy. Wierzymy jednak, że każdy znajdzie w niej coś co pomoże lepiej zarządzać swoimi routerami. Może coś nawet uda się poprawić od ręki.
Na koniec pragniemy życzyć Wam dużo zdrowia i abyśmy jak najszybciej mogli spotykać się na różnego rodzaju wydarzeniach branżowych.
