22T34 Własny serwer DNS [konfiguracja MikroTik]

MikroTik Local DNS Server DNS client auto configuration via DHCP server

Link do artykułu.

0:00 Wprowadzenie

0:50 Konfiguracja Własnego serwera DNS na routerze MikroTik

15:38 Podsumowanie

Transkrypcja

Zanim przejdziemy do dzisiejszego odcinka, chciałbym Cię zaprosić do wzięcia udziału w najbliższych warsztatach online z konfiguracji WireGuard Site to Site na MikroTiku od zera. Link do zapisów na warsztaty znajdziesz pod filmem. A teraz zapraszam do odcinka.

Cześć. Chciałbyś mieć możliwość komunikacji z urządzeniami w sieci lokalnej po nazwach domenowych lub chciałbyś zoptymalizować ruch do serwerów DNS z sieci lokalnej? Rozwiązaniem tego typu problemów jest uruchomienie w sieci lokalnej własnego serwera DNS. Jeśli korzystasz z routerów MikroTIk istnieje możliwość uruchomienia własnego serwera DNS właśnie na tym routerze. W tym odcinku pokażę, jak uruchomić własny serwer DNS na routerze MikroTIk. Zapraszam.

Aby skonfigurować własny serwer DNS na routerze MikroTik należy: połączyć się z routerem MikroTIk wykorzystując WinBox. Następnie przejść do IP –> DNS. W polu Servers należy wpisać adres IP serwera DNS. Tutaj niżej Dynamic Servers – są to serwery, które pochodzą z serwera DHCP, z którego konfigurację uzyskał ten router MikroTik. Dla przykładu jako serwer zostanie wykorzystany quad9. Ta usługa jest dostępna pod adresem: quad9.net. Mamy tutaj informacje o adresach wykorzystywanych na tym DNS-ie. Są to cztery 9. Wpisujemy tutaj ten adres i dodajemy alternatywny serwer DNS. Tez z quad9 i ten adres wklejamy w drugim polu. Zaznaczamy opcję Allow Remote Requests. Pozwoli to korzystać z tego serwera DNS urządzeniom sieci lokalnej. Tutaj w razie potrzeby możemy zmienić czas wygasania pakietów DNS. Np. serwer może zwrócić Timeout po dwóch sekundach braku odpowiedzi a na wszystkie żądania po dziesięciu sekundach. Quad9 wspiera DNS over HTTPS, więc można skonfigurować też tą usługę. Kopiujemy ten adres i używamy DNS over HTTPS. Wklejamy adres, naciskamy Apply. Tutaj możemy ustalać statyczną konfigurację DNS. Np. wskazać nazwę domenową i zdefiniować lokalny adres IP, który ma zwrócić serwer DNS. W polu Cache możemy sprawdzić informacje o adresach DNS, które otrzymał serwer DNS po odpytaniu przez inne urządzenia.

Jak widać nigdzie nie było błędów więc konfiguracja DNS jest prawidłowa. 7-dniowy cache domyślny możemy zostawić. Jeśli byśmy mieli problem z dostępem do jakiejkolwiek strony, wystarczy cache wyczyścić. Dla przykładu aby tutaj wymusić odpytanie serwera DNS, sprawdzę dostępność aktualizacji. Serwer DNS został odpytany. Teraz pokażę jak urządzenia mogą uzyskać dostęp do tego serwera DNS.

Zaloguję się do Linuxa. Sprawdzę konfigurację interfejsów sieciowych. Należy zainstalować paczkę net-tools. Nie ma tutaj informacji o serwerze DNS. Aby sprawdzić jaki adres IP jest aktualnie serwerem DNS, należy wykonać komendę resolvectl status. Mamy informację, że do interfejsu ens3 jest aktualnie przypisany serwer DNS 1.1.1.1 a pozostałe serwery to 10.0.10.1, czyli adres naszego routera MikroTik i 1.1.1.1, które są z głównego serwera DHCP w naszej sieci. Aby urządzenia otrzymywały odpowiednią konfigurację należy jeszcze zmienić ustawienia serwera DHCP. W tym celu przechodzimy do IP –> DHCP Server. Przechodzimy do zakładki Networks. Definiujemy adres serwera DNS. Dla urządzeń ma być przydzielony 10.0.10.1. Naciskamy OK. Wykonujemy polecenie dhclient. Sprawdźmy jak wygląda konfiguracja… Tutaj na pierwszy rzut oka nic się nie zmieniło. Jeszcze raz wykonamy polecenie resolvectl status. Mamy tutaj informacje tylko o jednym serwerze DNS, czyli naszym routerze. Teraz wykonując polecenie ping netadminpro.pl Będziemy odpytywać najpierw router. Zobaczmy jak wygląda aktualnie cache serwera DNS.

Przechodzimy do IP DNS, następnie Cache. A tutaj jest informacja, że DNSSEC jest niewspierany to na ten moment wyłączę opcję DNS over HTTPS. Tutaj nazwa została rozwiązana. Jak wyczyszczę cache, jeszcze raz wykonam zapytanie. W cache pojawiły się trzy wpisy: wpis PTR, wpis z rekordem A domeny i rekord SOA. Widać, że każdy z tych rekordów ma inny okres ważności. Ogólnie informacja o nazwie netadminpro.pl z rekordem A zniknie z serwera po 12 minutach. Wyczyszczę lokalny cache i jeszcze raz wykonam polecenie ping netadminpro.pl. Ten rekord A ma ważność około pół godziny i jest zależny od czasu rzeczywistego zegara. Wartość TTL jest zczytywana z konfiguracji serwera DNS konkretnej domeny. W aktualnej konfiguracji istnieje ryzyko, że ktoś może korzystać z naszego serwera DNS i odpytywać o zakazane strony. Wtedy to nasz router jako lokalny serwer DNS odpyta publiczny serwer DNS o niedozwoloną domenę i potencjalnie możemy mieć z tego powodu problemy. Jeśli operator nie blokuje ruchu zainicjowanego z zewnątrz, musimy sami zadbać o to, aby taki ruch zablokować. Zanim to zrobię, pokażę, że istnieje możliwość uzyskania dostępu do lokalnego serwera DNS z zewnątrz. Dodam dodatkowe urządzenie: Virtual PC. Dla przykładu nazwę to urządzenie Hacker albo Attacker. Zakładamy, że Hacker to pozytywne znaczenie. Atakujący odpytywał by nasz router z sieci dlatego nie zostanie podłączony bezpośrednio do routera, tylko za pośrednictwem interfejsu sieciowego. Połączmy się z tym urządzeniem. Uzyskamy teraz konfigurację z centralnego serwera DHCP. Mamy tutaj adres z końcówka 107. Aktualnie jest tutaj ustawiony serwer DNS 1.1.1.1 z Cloudflare. Podobnie jak domyślnie otrzymuje router MikroTik z centralnego serwera DHCP. Teraz jako atakujący zmienię adres IP serwera DNS. Jako adres serwera DNS wskażę publiczny adres IP routera MikroTik. Wykonuję komendę ip dns i tutaj wpisuję 10.253.253.103. Z punktu widzenia tego urządzenia jest to adres publiczny.

Zobaczmy aktualną konfigurację… Jest ustawiony serwer DNS. Teraz zobaczmy jak tutaj wygląda cache DNS. Wyczyszczę cache. Jeśli teraz wykonam polecenie ping netadminpro.pl to jeśli router odpowie na rządanie DNS, w tym miejscu powinien wyświetlić się odpowiedni wpis z zapytaniem o domenę netadminpro.pl do centralnego serwera DNS, którym w tej konfiguracji jest quad9. Widać żądanie zostało wysłane. Z tego względu, że Linux prosił o dodatkowe informacje a taki prosty emulator komputera nie prosi o np. rekord PTR, NS, to mamy tutaj z tego względu tylko jeden wpis. Aby zapobiec odpytywaniu naszego serwera DNS należy jeszcze dodatkowo ustawić regułę na Firewallu. Przechodzimy do IP –> Firewall i będąc w zakładce Filter Rules należy dodać kilka reguł do Firewalla. Wszystkie będą na łańcuchu input, jedyna różnica będzie w akcji i w interfejsie. Otwieramy wewnętrzne okno terminala routera MikroTik i przechodzimy do konfiguracji IP –> Firewall –> Filter. Jest to dokładnie to samo miejsce, które tutaj mamy w interfejsie graficznym. Regułę, którą będziemy chcieli dodać, będzie zawierała następujące parametry: będzie na łańcuchu input, będzie to protokół TCP, port docelowy 53, interfejs Bridge LAN.

Akcja dozwolona. Możemy wypisać jaka jest teraz konfiguracja. Na podstawie tej reguły możemy teraz wygodnie tworzyć kolejne. Jako że usługa DNS działająca na porcie 53 komunikuje się protokołem TCP i UDP, należy dodać jeszcze drugą regułę akceptującą ruch, ale wykorzystującą protokół UDP. Zapomniałem tutaj dodać na początku polecenie add. Teraz wszystko się zgadza. Mamy dwa wpisy. Teraz będą potrzebne wpisy zabraniające ruchu. Jako że interfejsy działające w sieci lokalnej konfigurujemy zbiorczo na bridge LAN to pozostaje dodać tylko dwa wpisy odrzucające na interfejsie ether1. Dlatego zmieniamy tylko akcję na drop. Interesuje nas interfejs ether1 i podobny wpis z protokołem TCP. Dla porządku możemy zmienić tutaj kolejność. Zobaczmy czy komunikacja odbywa się prawidłowo. Wykonuję polecenie ping netadminpro.pl. Zobaczmy cache. Otrzymuję odpowiedź. Zobaczmy teraz jak wygląda komunikacja z poziomu atakującego. Sprawdźmy aktualną konfigurację. Zmienię tylko serwer DNS na router MikroTik i wykonam polecenie ping netadminpro.pl. Tutaj jest widoczny wpis ale on nie ma aktualnie znaczenia. Zobaczmy, jak zachowa się urządzenie atakującego. Zostało rozłączone.

Jak mogłeś zauważyć, taki serwer z lokalnym cache daje wiele możliwości. Możesz np. blokować dostęp do różnych domen kierując je tak jak działa PiHole, np. na localhost. Mam nadzieję, że ten odcinek był dla Ciebie pomocny. Daj znać, co sądzisz o tego typu poradnikach w komentarzu. Do następnego razu.