Zakłada się, że wiesz jak zainstalować maszynę wirtualną z RouterOS i Linux oraz jak skonfigurować sieć oraz co to jest DNS.
1. DNS i RouterOS
Zestaw połączenia zgodne z poniższym schematem. Możesz użyć GNS3
Skonfiguruj dwie maszyny wirtualne jedną z RouterOS druga z Linux/Windows, bez znaczenia.
2. Konfiguracja ustawień IP oraz DNS
RouterOS
Na systemie RouterOS skonfiguruj interfejsy sieciowe. Od strony WAN uzyskaj adres z DHCP albo
wprowadź ręcznie. Wykonasz to w WinBox z menu /IP/Addresses. Przykładowo jak niżej:
Skonfiguruj bramę domyślną
Ustaw adres serwera DNS oraz włącz buforowanie zapytań od klientów sieci LAN
Sprawdzamy czy działa z konsoli RouterOS:
Ponieważ nasz ROS jest routerem dla sieci LAN włączamy na nim usługę NAT (z konsoli)
/ip firewall nat add action=masquerade chain=srcnat out-interface=ether1
Linux
Na systemie Linux także ustal adresację IP. Za pomocą poleceń konsoli zrobisz to tak (jako root):
#ip address add 192.168.0.2/24 dev enp0s3
#ip route add default via 192.168.0.1
#cat nameserver 1.1.1.1 > /etc/resolv.conf
Sprawdzamy konfiguracje i czy działa
#ip a
#ping wp.pl
Działa ale taki ruch zapytań nie jest szyfrowany co bardzo łatwo można sprawdzić za pomocą podsłuchiwania sieci np. programem Wireshark lub wbudowanym w RouterOS snifferem.
Przechwycenie ruchu zapytań i odpowiedzi DNS
Na naszym RouterOS
– Z menu Tools/Packet sniffer otwieramy okno sniffera
– Ustawiamy jak niżej
— pamięć 8M
— nazwa pliku dns.pacp
— limit wielkości pliki około 32M
– Włączamy podsłuch na interfejsie LAN (w tym przykładzie to ether2 o adresie 192.168.0.1) klikając w Apply i kolejno w Start
Z konsoli systemu Linux wysyłamy „pinga” do dowolnego adresu domenowego
#ping -c 1 www.wp.pl
Zatrzymujemy przechwytywanie na RouterOS klikając w Stop. Utworzony plik (/Files) przenosimy do komputera hosta i wczytujemy do Wireshark (z WinBox możemy przenieść myszką ten plik bezpośrednio do okna Wireshark).
Po wczytaniu do Wireshark widok poniższy:
Ponieważ ruch sieciowy był minimalny nie musimy stosować filtrów. Pakiet numer 5 i 6 to pytania z systemu Linux do serwera DNS znajdującego się do adresem 1.1.1.1 (bo tak Linux był ustawiony). Z jakiego powodu mamy dwa pytania choć zadane było jedno? Ponieważ nasz Linux ma włączony stos IPv6. Pierwsze zapytanie jest o rekord A protokołu IPv4 a drugie o rekord AAAA protokołu IPv6. Pakiety 7 i 8 to odpowiedzi na powyższe pytania. Jak widać zarówno zapytania jak i odpowiedzi przesyłane są tekstem jawnym.
W perspektywie bezpieczeństwa to bardzo niedobrze. Ten ruch jest routowany przez nasz ROS do serwera Cloudflare, przez nie naszą sieć czyli przez Internet. Jest zatem wiele możliwości podejrzenia takiego ruchu, a co gorsza przesłania nam spreparowanej odpowiedzi z innym adresem IP. Jeśli docelowy serwis WWW zostanie dobrze podrobiony możemy dać się nabrać i wprowadzić tam nasze login i hasło tym samym przekazując je napastnikowi.
Jeśli chcesz możesz teraz powtórzyć przechwytywanie ruchu ale na interfejsie routera od strony WAN. W tym wypadku będziemy mieli znaczenie więcej przechwyconych pakietów ponieważ od strony WAN pracuje znacznie więcej maszyn (w naszym przykładzie).
Kilka sekund przechwytywania dało prawie 800 pakietów. Aby wyłowić co nas interesuje użyjemy filtrowania. Nasz filtr do „dns” i w wynikach widzimy kilka pakietów. Pakiet numer 562 zawiera odpowiedź dla IPv4
Po tej stornie routera ruch DNS także nie jest filtrowany.
3. Szyfrowanie ruchu
Na routerze włączymy teraz szyfrowanie ruchu DNS. Proces opisany jest tutaj. W tym wypadku jednak musimy zmienić teraz konfigurację klienta (resolvera) DNS na kliencie czyli naszym Linux. W pliku /etc/resolv.conf zmieniamy adres DNS z 1.1.1.1 na 192.168.0.1.
Aby powyższa konfiguracja zadziałała na RouterOS trzeba włączyć opcję Allow Remote Request na zakładce DNS (o ile tego nie wykonano wcześniej).
Jeśli router ma włączony firewall to zapewne trzeba dodać regułę pozwalającą na dostęp do jego portu UDP/53 od strony LAN. Jest to port, na którym nasłuchuje usługa DNS. Przykład takiej reguły poniżej:
#/ip firewall filter add action=accept chain=input dst-port=53 in-interface=ether2 protocol=udp
Po konfiguracji szyfrowania DNS ponownie wykonamy dwa przechwytywania ruchu: od strony LAN i WAN
4. Przechwytywanie ruchu DNS po szyfrowaniu
Proces przechwytywania jest identyczny jak poprzedni zatem pokazane są poniżej tylko wyniki w Wireshark
Od strony LAN
Jak widać tutaj nic się nie zmieniło, nadal mamy ruch nieszyfrowany. Tylko teraz nasz Linux zapytania wysyła nie bezpośrednio do Cloudflare a do naszego lokalnego resolvera jakim jest nasz RouterOS pod adresem 192.168.0.2. Ponieważ to ruch w sieci lokalnej może nie będzie konieczne szyfrowanie. Ale jeśli i ten odcinek chcemy zabezpieczyć nie pozostaje nic innego jak zainstalować na kliencie odpowiednie oprogramowanie szyfrujące ruch DNS. O tym temacie w innym module/artykule.
Przy okazji 1: reguła firewall złapała zapytanie z systemu LInux
Przy okazji 2: w buforze naszego lokalnego DNS pojawiły się wpisy adresów poszukiwanych przez Linux:
Przy okazji 3: w tej sytuacji koniecznie trzeba zabronić dostępu do DNS na RouterOS od strony WAN (tutaj ether1):
# /ip firewall filter add action=drop chain=input dst-port=53 in-interface=ether1 protocol=udp
Jeśli teraz do czasu życie takiego wpisu w buforze ktoś zapyta o tą samą nazwę domenową to nasz RouterOS odpowie z odwzorowaniem nazwa–>IP z bufora, nie będzie musiał wysyłać zapytania do DNS w sieci Internet.
Od strony WAN
Także tym razem plik z przechwyconym ruchem sieciowym zawiera dużo danych, zastosujemy filtr DNS jak poprzednio:
Pusto! Z jakiego powodu? Przecież zapytanie było wysłane do DNS pod adresem 1.1.1.1. Powodem jest to, że teraz ruch DSN jest szyfrowany. Sprawdzimy innym filtrem, a mianowicie filtrem adresu IP. Wiemy, że zapytania maja być kierowane do adresu 1.1.1.1, zatem:
Widać, że nasz host 192.168.7.191 wysyła jakiś ruch (szyfrowany) do 1.1.1.1 i uzyskuje odpowiedzi. Wszystko jest zaszyfrowane zatem do środka nie zajrzymy. Miejmy nadzieję, że zły pan czy zła pani także nie zobaczą co tam jest 🙂
Podsumowanie
W pierwszej części pokazano nieszyfrowany ruch zapytań i odpowiedzi DNS, w drugiej ten ruch został zaszyfrowany. Weź pod uwagę, że szyfrujemy od routera przez Internet do celu (w stronę powrotną też). W sieci LAN ruch DNS nie jest szyfrowany. Ma to wady i zalety.
Zaletą jest to, że możemy teraz dodać konfigurację blokady połączeń DNS nieszyfrowanych z naszej sieci LAN i przekierować jest do routera, który ten ruch przechwyci i pośle w świat już w postaci zaszyfrowanej. Jak to zrobić opisano tutaj. W takim wypadku żaden host z naszej sieci LAN nie będzie mógł wysyłać nieszyfrowanych zapytań do sieci Internet. Oczywiście mowa o konfiguracji standardowej czyli połączeniach UDP na port 53.
Wadą jest to, że jeśli powyższej blokady nie zrobimy to tylko hosty korzystające z naszego RouterOS jako serwera DNS będą chronione w Internecie szyfrowanym ruchem DNS.
