Jak skutecznie zabezpieczyć MikroTik RouterOS ?
W ostatnim czasie głośno jest o lukach w RouterOS. W idealnym świecie nie powinny się pojawiać, lecz praktyka wskazuje, że każdy producent ma na swoim koncie mniej lub więcej wpadek. Co za tym idzie, stosując zasadę ograniczonego zaufania, warto zadbać o bezpieczeństwo naszych routerów. Poniższy tekst pokazuje elementy, na które należy zwrócić szczególną uwagę. Zajmiemy się kolejno: kontami użytkowników, zabezpieczeniem dostępu po IP i adresach MAC, interfejsami, usługami typu DNS czy bt-Test, regułami firewall i kilkoma jeszcze.
Konta użytkowników
Na początek przejdźmy do użytkowników systemowych (tych dodawanych w menu System->Users). Użytkownicy Ci będą mogli logować się na router i w zależności od uprawnień, przeglądać lub modyfikować konfigurację. Zaleceniem tu jest zmiana loginu admin na inny, korzystanie z silnych, złożonych i długich haseł oraz przydzielenie osobnych kont dla każdego z administratorów.
/user set 0 name=nazwaUżytkownika
/user set 0 password=”odpowiednioSkomplikowaneHasło”
W większych środowiskach zamiast lokalnej bazy użytkowników warto rozważyć wykorzystanie serwera Radius do autoryzacji – oczywiście z zachowaniem wcześniej przytoczonych zasad. W temacie użytkowników warto ograniczyć dostęp dla kont, gdzie i tak wiemy, że wykorzystywane są jedynie z sieci wewnętrznej (np. allowed-address=192.168.1.0/24).
/user set 0 allowed-address=192.168.1.0/24
Dostęp z sieci bezpośrednio podłączonych do routera
Dobrą praktyką jest wyłączenie wszystkich fizycznych interface’ów, które nie są obecnie używane:
/interface set 1,2,3 disabled=yes
Następnie warto zastanowić się, jak nasz router podłączony jest do sieci zewnętrznej, oraz czy aby na pewno wszystkie sieci prywatne są sieciami zaufanymi. Typowy schemat podłączenia router’a poniżej:
Można rozważyć przeznaczenie jednego z interface’ów do zarządzania lokalnie naszym urządzeniem. Na pozostałych interface’ach powinniśmy wyłączyć możliwość podłączenia się do router’a za pomocą adresu MAC, jak również wyłączyć działanie protokołu MNDP (MikroTik Neighbor Discovery Protocol). W tym celu wykonujemy następujące kroki:
/interface list add name=mgmt
/interface list member add interface=ether5 list=mgmt
/ip neighbor discovery-settings set discover-interface-list=mgmt
/tool mac-server mac-winbox set allowed-interface-list=mgmt
/ tool mac-server set allowed-interface-list=mgmt
/tool mac-server ping set enabled=no
W powyższym przykładzie ograniczyliśmy działanie protokołu MNDP do interface’u ether5. Podobnie zrobiliśmy, ograniczając możliwość zalogowania się na urządzenie za pomocą mac-address’u (mac-winbox, mac-telnet). Protokół MNDP, jeżeli jest włączony na interfejsie, to za jego pomocą nasz RouterOS może wykrywać inne urządzenia jak i sam staje się wykrywalny. Poza faktem bycia wykrytym, router ujawni również swój identyfikator, platformę na jakiej działa a także jakie oprogramowanie jest na nim zainstalowane (w której wersji).
Metody dostępu do urządzenia oraz inne usługi
RouterOS umożliwia nam zarządzanie naszym routerem na wiele sposobów. Każdy z nich może stać się słabym punktem naszego bezpieczeństwa. Dlatego dostęp do naszego routera powinniśmy ograniczyć do jednej, czasami dwóch metod.
/ip service disable [find name=telnet]
/ip service disable [find name=ftp]
/ip service disable [find name=www]
/ip service disable [find name=www-ssl]
/ip service disable [find name=api]
/ip service disable [find name=api-ssl]
W tym przypadku pozostawiliśmy jedynie dostęp ssh oraz winbox. Dodatkowo możemy zmienić domyślne numery portów na jakich działają usługi winbox, ssh, oraz wskazać z jakich adresów IP będziemy mogli się do nich podłączyć.
/ip service set port=2022 address=10.10.10.10,10.10.10.11 [find name=ssh]
/ip service set port=18291 address=10.10.10.10,10.10.10.11 [find name=winbox]
Kolejna elementem podnoszącym bezpieczeństwo jest ustawienie silnej kryptografii dla połączeń ssh
/ip ssh set strong-crypto=yes
Pozostałe usługi, jakie powinniśmy wyłączyć:
/tool bandwidth-server set enabled=no
/ip dns set allow-remote-requests=no
/ip socks set enabled=no
Usługa UPnP pozwala na dynamiczne tworzenie reguł dst-nat dla urządzeń w sieci LAN które o to poproszą. Najczęściej są nimi konsole do gier czy telewizory IP. Gdy tylko jest to możliwe zalecane jest wyłączenie tej funkcjonalności.
/ip upnp set enable=no
Reverse Path Filtering – metoda blokowania pakietów mających niepoprawny adres źródłowy. Tzn z naszej sieci LAN nie powinien wyjść pakiet, którego adres źródłowy różni się od adresacji wewnętrznej.
/ip settings set rp-filter=strict
Jeżeli nie korzystamy z usługi DynDNS oraz serwera czasu, powinniśmy ją wyłączyć
/ip cloud set ddns-enable=no update-time=no
/ip proxy set enabled=no
/ip socks set enabled=no
Część urządzeń MikroTik posiada wbudowane wyświetlacze LCD. Jeżeli nie kontrolujemy fizycznego dostępu do routera (przestrzenie współdzielone) lub nie korzystamy z tej funkcjonalności, należy się zastanowić nad wyłączeniem wyświetlacza:
/lcd set enabled=no
Dostęp z zewnątrz do routera
Możliwość kontrolowania routera z zewnątrz powinna zostać szczegółowo zaplanowana i możliwie ograniczona. Dobrą praktyką jest zablokowanie łączenia się bezpośrednio z zewnątrz sieci do naszego routera. Mechanizmami, które zwiększą nasze bezpieczeństwo to technologie VPN, oraz odpowiednie reguły firewall’a.
Opcja 1 – dostęp tylko ze znanych adresów IP (gdy mamy stały adres IP)
/ip firewall filter add chain=input comment=”Accept Established, Related” connection-state=established,related action=accept
/ip firewall filter add chain=input src-address=45.32.154.212 action=accept
/ip firewall filter add chain=input src-address=45.32.154.100 action=accept
/ip firewall filter add chain=input action=drop
Opcja 2 – dostęp tylko z VPN (możemy łączyć się z różnych adresów IP)
/ip firewall filter add chain=input comment=”Accept Established, Related” connection-state=established,related action=accept
/ip firewall filter add chain=input comment=”SSTP VPN” protocol=tcp dst-port=443 action=accept
/ip firewall filter add chain=input src-address=172.16.10.0/24 action=accept/ip firewall filter add chain=input action=drop
Opcja 3 – port knocking (możemy łączyć się z różnych adresów IP)
Mechanizm port knocking polega na dynamicznym modyfikowaniu reguł dostępowych firewall’a w przypadku, gdy nastąpiła określona akcja. Aby móc zalogować się za pomocą winbox’a należy wcześniej wykonać dodatkowe czynności, np. podjąć próbę komunikacji z routerem na port 2133/tcp a następnie 7117/tcp. Po wykonaniu tej sekwencji router doda nasz adres IP do odpowiedniej listy adresów, która będzie miała dostęp do wcześniej zablokowanego portu winbox’a.
/ip firewall filter add chain=input comment=”Accept Established, Related” connection-state=established,related action=accept
/ip firewall filter add chain=input protocol=tcp dst-port=2133 action=add-src-to-address-list address-list=port-knocking-stage1 address-list-timeout=00:01:00
/ip firewall filter add chain=input protocol=tcp dst-port=7117 src-address-list=port-knocking-stage1 action=add-src-to-address-list address-list=port-knocking-stage2 address-list-timeout=00:01:00
/ip firewall filter add chain=input src-address-list=port-knocking-stage2 protocol=tcp dst-port=8291 action=accept/ip firewall filter add chain=input action=drop
Jeżeli nasz komputer wyposażony jest w narzędzie telnet, możemy zasymulować próbę połączenia na wskazane porty:
telnet adresIProutera 2133
telnet adresIProutera 7117
dopiero teraz możemy użyć winbox do połączenia z naszym routerem.
Uwagi
Niektórzy administratorzy dodatkowo ustawiają na urządzeniu wiadomość powitalną dla każdego kto się loguje. Tego typu informacja może zawierać notę prawną lub inny komunikat mający na celu poinformowanie intruza o fakcie, iż jego poczynania są od teraz monitorowane.
/system note set show-at-login=yes
/system note set note=”Dostęp do urządzenia jest monitorowany.”
Zalecane jest również zbieranie zdarzeń systemowych typu Syslog, najlepiej na zewnętrznym serwerze do tego przeznaczonym. Dodatkowo warto zastanowić się nad skorzystaniem z Netflow w celu zalogowania również pakietów przychodzących do naszego routera i późniejszej analizy.
Regularnie powinniśmy tworzyć kopie zapasowe naszej konfiguracji, pamiętając aby nie przechowywać ich bezpośrednio na routerze.
W ten sposób płynnie przechodzimy do części związanej z Firewall. Zanim skupimy się na konkretnych regułach kilka ogólnych zasad.
Używać adress-list
Korzystać z interface-list
Stosować własne łańcuchy
Wykorzystywać komentarze
Te proste zasady znacznie ułatwiają utrzymanie katalogu „dobrych reguł” i przyspieszą ich stosowanie w przypadku gdy opiekujemy się grupą urządzeń.
Zabezpieczenie dostępu do routera (łańcuch INPUT):
Akceptacja dla połączeń już ustanowionych i powiązanych
Akceptacja dla połączeń z sieci do zarządzania
Przyzwolenie dla ruchu DNS (jeśli korzystamy w Mikrotik jako resolvera) z uwzględnieniem jakie hosty mają prawo odpytywać
Akceptacja dla ICMP (Internet Control Message Protocol)
….. pozostałe reguły potrzebne z punktu widzenia usług (np., dla VPN)
Zablokowanie całego pozostałego ruchu (drop ALL)
Zabezpieczenie sieci lokalnej
Akceptacja dla połączeń już ustanowionych i powiązanych
Zablokowanie pakietów w stanie invalid[1]
Blokowanie pakietów przychodzących na interfejs WAN z adresów z sieci prywatnych [2]
Blokowanie pakietów trafiających na interfejs LAN a mających adres źródłowy spoza adresacji lokalnej[3]
….. pozostałe reguły potrzebne z punktu widzenia usług (np., dla VPN)
Zablokowanie całego pozostałego ruchu (drop ALL)
Zabezpieczenie usług w DMZ
Dobrą praktyką jest wykorzystanie własnych łańcuchów dzięki czemu znacznie lepiej można wizualizować reguły dostępu do usługi. Dodatkowym argumentem przy większej liczbie reguł jest optymalizacja pod kątem wydajności. Własne łańcuchy dają szanse na zmniejszenie liczby reguł przetwarzanych przez poszczególne pakiety.
W artykule przytoczę przykład zastosowania reguł dla ustalenia zasad dostępu do serwera WWW umieszczonego w sieci DMZ pod adresem 10.10.10.200 (sieć 10.10.10.0/24). Z sieci Internet ma być widoczny tylko port tcp/80 oraz tcp/443. Dodatkowo z zdefiniowanej listy adresów ma być dodatkowo dostęp do zarządzania za pomocą SSH (tcp/22).
Pierwszym krokiem jest przygotowanie reguł NAT (dst-nat)
/ip firewall nat chain=dstnat in-interface=ether1-WAN dst-address=<<public_ip>> dst-port=80 to-address=10.10.10.200 comment=”przekierowanie portu 80 serwer WWW DMZ”
/ip firewall nat chain=dstnat in-interface=ether1-WAN dst-address=<<public_ip>> dst-port=443 to-address=10.10.10.200 comment=”przekierowanie portu 443 serwer WWW DMZ”
W kolejnym kroku należy zdefiniować reguły w tablicy Filter
/ip firewall filter chain=forward dst-address=10.10.10.200 action=jump jump-target=SRV-DMZ-WWW comment=”przekierowanie ruchu do serwera WWW celem przefiltrowania”
/ip firewall filter chain= SRV-DMZ-WWW dst-port=80 protocol=tcp action=accept comment=”akceptacja ruchu do serwera www na port 80 tcp”
/ip firewall filter chain= SRV-DMZ-WWW dst-port=443 protocol=tcp action=accept comment=”akceptacja ruchu do serwera www na port 443 tcp”
/ip firewall filter chain= SRV-DMZ-WWW dst-port=22 protocol=tcp action=accept src-address-list=”Accept-zarzadzanie” comment=”akceptacja polaczen do zarzadzania za pomoca SSH – tylko z uprawnionych”
/ip firewall filter chain= SRV-DMZ-WWW action=drop comment=”Blokada pozostalych pakietow kierowanych do serwera DMZ WWW”
[1] Pakiety nie należące do wcześniej ustanowionego połączenia i zarazem nie będące pierwszym pakietem dla połączenia.
[2] wg RFC1918 – Address Allocation for Private Internets
[3] Adresacja LAN jest znana w organizacji. Zalecane jest określenie jako address-list i w razie potrzeby aktualizacja
