Kategorie
Sprzęt

Bezpieczny DNS

Ostatnio zaktualizowany

Tak jak wspomniałem wcześniej, postaram się opisać również metodę zabezpieczenia DNS z wykorzystaniem TLS (DNS over TLS).

Ta metoda w ustawieniu jest bardziej zaawansowana oraz obciąża nasz router bardziej niż DoH.

Nim to jednak zrobię, szybkie porównanie różnic pomiędzy DNS over HTTPS (DoH) oraz DNS over TLS (DoT).

Obie metody mają na celu osiągnięcie tego samego, czyli szyfrowanie naszych zapytań do serwerów nazw (DNS).

DoT używa protokołu TCP (basic connection protocol) wraz z warstwą szyfrującą oraz uwierzytelniającą (layers over TLS encryption and authentication). DoH używa do połączenia protokołu HTTP/2. HTTP/2 odpowiada za komunikację serwera z przeglądarką mający zapewnić ekspresowe wczytywanie stron internetowych i nie bez powodu ma to znaczenie w przypadku serwera nazw (DNS). Połączenie z DNS musi być szybkie, gdyż na tym opiera się pierwszy krok gdy wchodzimy na daną stronę w internecie.

Oprócz tego DoT używa portu 853 (lub 53), natomiast DoH używa portu 443, tego samego, którego używa się przechodzą na stronę z zieloną kłódeczką (HTTPS). Dzięki czemu odwiedzanie bezpiecznej strony (przez port 443) a żądanie zapytania do serwera nazw wyglada tak samo i ciężko je odróżnić a co przede wszystkim zablokować. W przypadku dedykowanego portu, blokada 853/tcp jest znacznie łatwiejsza a niżeli 443.

Inną różnicą jest rownież to, że w przypadku DoT na routerze, nie jesteśmy 100% pewni czy wszystko działa przechodząc na stronę https://1.1.1.1/help, bez uruchomienia śledzenia pakietów przy pomocy WireShark. Dopiero wówczas możemy potwierdzić, że zapytania DNS są rzeczywiście szyfrowane. W przypadku poprawnie wprowadzonego DoH na routerze powyższa strona powinna potwierdzić nam że wszystko działa.

Oczywiście warto również posłużyć się stroną DNS Leak w celu analizy wycieku zapytań do serwerów nazw (DNS). Uruchomiając zaawansowany test (Extended test), możemy sprawdzić, czy odpowiedzi przychodzą tylko z jednego źródła (jednego typu serwerów).

Decyzja w wyborze DoT czy DoH nie jest łatwa. Dyskusja pomiędzy ekspertami trwa do dzisiaj, jednakże z tego, co widać, w 2020 roku wygrywa DoH. Może się okazać, że będzie tak jak ze standardami Blu-ray i HD-DVD. O HD-DVD nie wiele osób już pamięta, gdzie Blu-ray podbił rynek. Pożyjemy, zobaczymy kto wygra.

DNS over TSL (OpenWRT)

A więc, jeżeli zdecydowaliśmy się uruchomić DoT na naszym routerze z OpenWRT, zaczynamy następująco.

W pierwszej kolejności zaczynamy od aktualizacji naszego routera i oprogramowania.

Logujemy się za pomocą SSH i wykonujemy komendę:

opkg update

Która zaktualizuje nam informację o dostępnych pakietach.

Następnie:

opkg list-upgradable | cut -f 1 -d ' ' | xargs opkg upgrade

Która zaktualizuje nam pakiety używane w routerze do najnowszych wersji.

Następnie instalujemy pakiety unbound-control, unbound-daemon-heavy, libunbound-heavy, luci-app-unbound oraz odhcpd komendą:

opkg install unbound-control unbound-daemon-heavy libunbound-heavy luci-app-unbound odhcpd

Pakiet luci-app-unbound dodaje nam odpowiednią opcję do graficznego panelu administracyjnego w naszym routerze, dzięki czemu niektóre komendy możemy wprowadzić z poziomu przeglądarki internetowej a niżeli z poziomu terminala.

Na tym etapie możemy napotkać na problem z pakietem odhcpd oraz jego konfliktem z odhcpd-ipv6only. W tym celu należy ten drugi usunąć i ponowić powyższą komendę.

opkg remove odhcpd-ipv6only

Domyślnie OpenWRT używa do zarządzania zapytaniami DNS pakiet dnsmasq, który może kolidować z odhcpd i zalecane jest jego usunięcie, chociaż ja zauważyłem, że w graficznym interfejsie unbound można wybrać z listy, który ma być używany. Jednakże, jeżeli nie chcemy powodować problemów, wykonujemy następującą komendę:

opkg remove dnsmasq

Następnie pozostaje nam skonfigurowanie naszej aplikacji unbound, która będzie zarządzała naszymi połączeniami i dbała szyfrowanie naszych zapytań DNS.

W tym celu należy wyedytować plik /etc/unbound/unbound_ext.conf przy pomocy Vim dodając następujące linie.

forward-zone:
  name: "."
  forward-addr: [email protected]                   
  forward-addr: [email protected]                             
  forward-addr: 2606:4700:4700::[email protected]
  forward-addr: 2606:4700:4700::[email protected]
  forward-ssl-upstream: yes

Oraz zmienić domyślne ustawienia w pliku /etc/config/unbound dodając lub modyfikują istniejące opcje następująco.

config unbound
  option add_local_fqdn '1'
  option add_wan_fqdn '1'
  option dhcp_link 'odhcpd'
  option dhcp4_slaac6 '1'
  option domain 'lan'
  option domain_type 'static'
  option listen_port '53'
  option rebind_protection '1'
  option unbound_control '1'

Pamiętajmy jednak! Powyższy plik konfiguracyjny zawiera zdefiniowane dodatkowe linie konfiguracyjne, które muszą w nim pozostać, dlatego ważne jest, aby poszczególne linijki dodawać, jeżeli nie istnieją oraz modyfikować ustawienie tych istniejących tak jak powyżej, a niżeli zrobić kopiuj — wklej.

Mój plik konfiguracyjny w całości wygląda następująco:

config unbound
	option add_extra_dns '0'
	option add_local_fqdn '1'
	option add_wan_fqdn '1'
	option dns64 '0'
	option domain 'lan'
	option domain_type 'static'
	option edns_size '1280'
	option extended_stats '0'
	option hide_binddata '1'
	option localservice '1'
	option manual_conf '0'
	option num_threads '1'
	option protocol 'default'
	option rebind_localhost '0'
	option rebind_protection '1'
	option recursion 'default'
	option resource 'default'
	option root_age '9'
	option ttl_min '120'
	option unbound_control '1'
	option verbosity '1'
	option enabled '1'
	option listen_port '53'
	option dhcp_link 'odhcpd'
	option validator '1'
	option validator_ntp '1'
	list trigger_interface 'lan'
	list trigger_interface 'wan'

config zone
	option enabled '0'
	option fallback '1'
	option url_dir 'https://www.internic.net/domain/'
	option zone_type 'auth_zone'
	list server 'lax.xfr.dns.icann.org'
	list server 'iad.xfr.dns.icann.org'
	list zone_name '.'
	list zone_name 'arpa.'
	list zone_name 'in-addr.arpa.'
	list zone_name 'ip6.arpa.'

config zone
	option enabled '0'
	option fallback '1'
	option resolv_conf '1'
	option zone_type 'forward_zone'
	list zone_name 'isp-bill.example.com.'
	list zone_name 'isp-mail.example.net.'

Ostatnim etapem będzie zmodyfikowanie konfiguracji DHCP w pliku /etc/config/dhcp aby zawierała następujące wpisy:

config dhcp 'lan'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option interface 'lan'
        option leasetime '12h'
        option ra 'server'
        option ra_management '1'

config odhcpd 'odhcpd'
        option maindhcp '1'
        option leasefile '/var/lib/odhcpd/dhcp.leases'
        option leasetrigger '/usr/lib/unbound/odhcpd.sh

Teoretycznie wszystko powinno być ustawione prawidłowo. Teraz należy włączyć unbound aby startował za każdym razem, gdy startuje nasz router oraz go uruchomić.

service unbound enable
service unbound start

W teorii, odwiedzając przeróżne strony, nie zobaczymy różnicy, jak również https://1.1.1.1/help nie powie nam czy wszystko działa, czy nie. Możemy użyć programu WireShark, jednakże z poziomu użytkownika nie wiele zobaczymy, gdyż powinniśmy prześledzić pakiety z poziomu routera.

W tym celu musimy zainstalować tcpdump na naszym routerze:

opkg install tcpdump

A na naszym komputerze posiadać zainstalowanego WireShark’a.

W przypadku macOS wystarczy uruchomić terminal i wykonać następującą komendę aby uruchomić przechwytywanie pakietów na naszym routerze i przekazać je do analizy w WireShark na naszym komputerze.

ssh [email protected] tcpdump -i eth0.2 -U -s0 -w - 'not port 22' | sudo wireshark -k -i -

Oczywiści, 192.168.0.1 to adres naszego routera, który musimy dostosować, jeżeli jest inny.

Na tym etapie będziesz zmuszony podać hasło do SSH routera oraz hasło administratora w systemie macOS. Gdyż ten proces może być nieco mylący, które hasło wpisać kiedy, najlepiej uruchomić terminal oraz wykonać komendę sudo su przed wykonaniem powyższego.

Teraz, w oknie WireShark powinniśmy zobaczyć ruch, który generujemy. Filtrując go przy pomocy ip.dst == 1.1.1.1 możemy ograniczyć wyświetlanie wpisów dotyczących naszego serwera DNS.

I tak zobaczymy, że zamiast protokołu DNS używanego przy połączeniu z 1.1.1.1, jak by to było bez szyfrowania, mamy TLSv1.3 potwierdzające szyfrowanie. W oknie odczytu danych również nie zobaczymy nazwy domeny, którą wpisywaliśmy tylko zaszyfrowane dane.

Na koniec.

Jako że powyższa metoda nie zadziałała u mnie przy pierwszym podejściu, udałem się do panelu administracyjnego mojego routera i dokonałem kilku modyfikacji.

Jeżeli masz problem — WireShark nadal pokazuje czyste zapytania DNS oraz DNS Leak zwraca więcej niż jeden serwer odpowiadający, zerknij poniżej na moją konfigurację i dokonaj zmian. Na końcu naciśnij Zapisz i Zastosuj (Save & Apply) i sprawdź zakładkę Status > Statistics, gdzie powinieneś widzieć jak unbound się spisuje.

W przypadku, gdy wszystko działa dobrze, przy kolejno odwiedzonych stronach pozycja num.queries powinna się zwiększać.

Moja konfiguracja:

I to by było na tyle.

Pozdrawiam.