Bezpieczny DNS

05-03-2020 22:38

01-11-2022 19:05

15 min.

Zawartość

Zapewne jesteś tego świadomy, że bardzo ważne jest, aby strona, którą odwiedzasz, a szczególnie ta, na której wprowadzasz jakiekolwiek dane (w tym login i hasło) zabezpieczona była tzw. zieloną kłódką, czyli serwowana przez https:// przed nazwą witryny.

HTTPS staje się swojego rodzaju normą. Coraz to więcej przeglądarek już teraz ostrzega cię, jeżeli odwiedzasz stroną poprzez nieszyfrowane połączenie, a w przyszłości większość z nich nie pozwoli ci nawet na nie wejść.

Dzięki HTTPS strony wyposażone są w certyfikat pozwalający w szyfrowaniu naszego połączenia. Dane, które wprowadzamy na stronie, czy to formularze, czy po prostu hasło do naszego konta wysyłane jest w sposób nieczytelny dla osoby postronnej.

W przypadku połączeń nieszyfrowanych HTTP, ktokolwiek pomiędzy tobą, a stroną docelową, może “podsłuchać” co na danej stronie robisz. Do tego celu nie trzeba zbyt dużej wiedzy a jedynie odpowiednie oprogramowanie.

Osobą, która może cię podsłuchiwać, czy tego chcesz, czy nie, jest przede wszystkim twój operator dostarczający połączenie internetowe. W zależności, jakie zobowiązania na niego nakłada lokalne prawo, mimo tego czy chce, czy nie, zmuszony jest przekazywać “twoje” informacje do odpowiednich organów państwowych.

I tak powstaje globalny program inwigilacji, który w połączeniu z poszczególnymi reżimami na świecie, decyduje, co jego obywatele mogą, a co nie mogą zobaczyć w internecie.

Stąd też przedstawione zostało połączenie HTTPS, dzięki czemu, wszelkie dane wysyłane w kierunku witryny internetowej są szyfrowane nie do poznania. O ile zaczęło się to od instytucji bankowych, to nabrało to tępa i strony, takie jak moja, serwowane są przez bezpieczne połączenie. Jeszcze kilka lat temu, certyfikaty były drogą inwestycją i nieopłacalną dla szarego człowieka. W miarę popularyzacji standardu i orientowania użytkowników w kierunku ich własnego bezpieczeństwa wszystko zaczęło tanieć. Certyfikat dla strony internetowej można już mieć praktycznie za darmo i to wystawione przez bardzo zaufane instytucje. Na mojej stronie opisywałem, jak można uzyskać w bardzo prosty sposób, za darmo, certyfikat i serwować domyślnie naszą stronę przez HTTPS (Certyfikat SSL dla twojej strony WWW).

W momencie odwiedzenia strony poprzez szyfrowane połączenie, oprócz ciągu znaków, potencjalna osoba, która nas podsłuchuje, nie zobaczy nic więcej — no prawie.

Strona internetowa i adres do niej to jedno, jednakże w internecie wszystko zaczyna się od numerków. Te oto numerki to adresy IP, które odpowiadają serwerom za nimi zlokalizowanymi. Pod jednym adresem IP, na jednym serwerze (lub więcej niż jednym) może znajdować się wiele stron. Aby przejść na stronę, którą oczekujemy, musimy podać odpowiednią nazwę — nazwę strony internetowej — domenę. Bazując na nazwie, serwer przekaże nas do tej, a nie innej strony.

I tak chcąc przejść na stronę Google wpisujemy google.com (nazwa, domena), a nie 216.58.206.110 (IP).

Serwer znajdujący się po drugiej stronie numerków, na bazie nazwy — domeny, którą wprowadziliśmy, przekazuje nas tam, gdzie chcemy.

I tak z wykorzystaniem połączenia szyfrowanego lądujesz na stronie https://www.google.com i możesz bezpiecznie wyszukiwać, to co chcesz. To, co wpisujesz w wyszukiwarce, nie jest dostępne w łatwy sposób dla osób ciebie podsłuchujących. Jednakże to nie znaczy, że dane osoby nie wiedzą, co robisz i jaką stronę odwiedzasz.

Otóż w momencie, gdy wpisujesz w przeglądarce internetowej google.com, odpowiednie zapytanie ląduje do tak zwanych serwerów nazw (dns), które odczytują tekst (nazwę — domenę) i informują, z jakim serwerem (adresem IP) należy cię połączyć.

Gdy wysyłasz zapytanie do serwera nazw, a nim wylądujesz na stronie docelowej, każdy, kto jest w stanie ciebie podsłuchać, jest w stanie zobaczyć, gdzie zmierzasz i jaką stronę odwiedzasz. Mimo tego, że nie będą w stanie powiedzieć, co dalej robisz na stronie, to co odwiedziłeś, jest dla nich podstawą do dalszych działań.

Słyszałeś na pewno o osobie oskarżonej o terroryzm, tylko dlatego że weszła (świadomie lub nie) na stronę, która uznana została za niedozwoloną.

Dlaczego?

Otóż zapytanie do serwera nazw wysyłane jest w postaci nieszyfrowanej. Każde szyfrowanie spowalnia ruch w internecie (było tak jeszcze kilka lat temu), w związku z tym, aby szybko przekierować się na serwer docelowy, wszystkie zapytania wysyłane są w postaci czystego tekstu, który może zostać w łatwy sposób przeczytany przez serwery pośredniczące, jak również inne osoby na drodze do miejsca docelowego.

Jeszcze kilka lat temu, połączenie z zieloną kłódką (HTTPS) nie było tak popularne wśród szarych użytkowników i właścicieli małych stron internetowych. Wiązało się to nie tylko z kosztami, ale również tym, że potrzeba było nieco większej mocy obliczeniowej, aby taki połączenie obsłużyć. Strony przez HTTPS na słabych serwerach ładowały się stanowczo dłużej a niżeli strony serwowane przez standardowy protokół HTTP.

Wszystko na szczęście się zmieniło. Różnica w prędkościach połączeń nieszyfrowanych (HTTP) i szyfrowanych (HTTPS) jest naprawdę marginalna. I mimo tego, że serwer, na którym strona się znajduje, nadal odgrywa znaczącą rolę, to nawet firmy takie jak Google zapowiedziały, że w 2020, to właśnie bezpieczne strony będą wiodły prym w wynikach wyszukiwania.

Mimo dużego skoku w technologii i świadomości użytkowników nadal większość z nas jest nieświadoma faktu, że strony, które odwiedzamy — adresy, są widoczne dla wszystkich, gdyż serwery nazw (DNS) działają w sposób “prosty” niezmiennie od lat.

Bez względu na to, czy za serwer nazw wybierzesz ten, dostarczony jest przez twojego operatora, czy jako świadomy użytkownik zmienisz go na Google (tj. 8.8.8.8), CloudFlare (1.1.1.1) czy OpenDNS, to nadal wszystko jest widoczne dla wścibskich oczu. Stąd też świadomość użytkowników zaczyna być kreowana przez duże firmy, wprowadzając szyfrowanie do poziomu serwerów nazw, zwiększając tym samym bezpieczeństwo użytkowników.

Bezpieczeństwo użytkowników jest teraz na modzie i słusznie!

Ostatnio Mozilla wypuściła informację, która szybko została podchwycona przez wszystkie portale. Otóż w ich przeglądarce internetowej Firefox włączyli oni domyślnie (oficjalne wejdzie w przeciągu następnych tygodni) szyfrowanie serwerów nazw DNS przy pomocy podobnej metody do stron serwowanych przez HTTPS. Dlatego też nazwane zostało to jako DNS over HTTPS, czyli serwer nazw DNS obsługiwany przez bezpieczne połączenie HTTPS, w skrócie DoH.

W związku z tym, zaczynając od wpisania adresu google.com aż do wylądowania na stronie docelowej, wszystko jest szyfrowane (no prawie wszystko). Wścibskie oczy zobaczą, że coś odwiedzasz w internecie, jednak ograniczone to będzie tylko do adresu IP serwera. Z reguły jeden adres IP obsługiwać może multum stron internetowych, więc określenie dokładnie jaką stronę odwiedzasz, nie jest już takie łatwe.

Fakt, że Firefox został wzbogacony w tę funkcję, która dodatkowo została włączona domyślnie (czytaj dalej) dla wszystkich stron, które wpisujemy w pasku adresu, nie znaczy, że masowo mamy porzucać nasze “niebezpieczne” przeglądarki i instalować “bezpieczną” przeglądarkę Firefox.

Nie wszystko jest takie różowe, jak myślicie.

Po pierwsze, Mozilla Firefox dopiero wprowadza to do swojego programu. Na pierwszy ogień, królikami doświadczalnymi zostali Amerykanie, reszta musi sobie poczekać (sic!). Dodatkowo cała usługa bazować będzie początkowo na serwerach nazw dostarczonych od CloudFlare.

Serwery nazw od CloudFlare są obecnie jednymi z najszybszych serwerów na rynku, a dodatkowo oferują dodatkowe zalety.

A co w przypadku, gdy chcemy użyć DoH już dzisiaj i zabezpieczyć swoją przeglądarkę przed wścibskimi oczami, szczególnie w krajach, które zaczynają śledzić użytkownika na każdym kroku?

Nie mówię tutaj tylko o Polsce, ale również Wielkiej Brytanii. Po wystąpieniu z Unii Europejskiej i zakończeniu okresu przejściowego wiele się może zmienić.

Otóż szyfrowanie DNS możemy włączyć już dzisiaj w naszej przeglądarce na naszym komputerze.

Mozilla Firefox

Jeżeli nie mieszkamy w stanach lub nie chcemy czekać, aż Mozilla udostępni oficjalnie DoH w naszej przeglądarce, możemy wykonać poniższe kroki i cieszyć się zwiększonym bezpieczeństwem już dzisiaj.

Przechodzimy do Menu przeglądarki, klikając na trzy poziome linie w prawym górnym rogu, następnie z listy wybierając opcję Ustawienia (Preferences), lub w pasku adresu wpisujemy about:preferences
Następnie przesuwamy stronę do samego dołu i przechodzimy do Ustawień Sieci (Network Setting). Na samum dole w oknie Ustawienia połączenia (Connection Settings) zaznaczymy Uruchom DNS przez HTTPS (Enable DNS over HTTPS) i pozostawiamy Cloudflare jako domyślnego usługodawcę.

Google Chrome i Microsoft Edge (Chromium)

W przypadku Chrome (oraz Edge bazującym na Chromium) musimy włączyć dodatkową, zaawansowaną opcję (flagę), aby uruchomić DoH.

W tym celu w pasku adresu wpisujemy i przechodzimy na chrome://flags/#dns-over-https (Chrome) lub edge://flags/#dns-over-https (Edge)
Następnie przy fladze Bezpiecznego DNS (Secure DNS lookup) zmieniamy status z Domyślny (Default) na Włączony (Enabled) i uruchamiamy ponownie przeglądarkę.

Aby wszystko w pełni działało, należy również ustawić w naszym systemie operacyjnym (lub na routerze) adresy DNS dla naszego połączenia sieciowego na następujące:

IPv4
1.1.1.1
1.0.0.1

IPv6
2606:4700:4700::1111
2606:4700:4700::1001

Więcej znajdziesz tutaj: Zmienianie ustawień protokołu TCP/IP.

Również, w przypadku gdy strona https://1.1.1.1/help wykryje, że nie korzystasz z bezpiecznego DNS, pod wynikiem przedstawi ci, jak ustawić serwery nazw Cloudflare na używanym przez ciebie systemie operacyjnym.

Safari

Tutaj niestety nic nie możemy włączyć — ustawić, aby zacząć używać szyfrowanego DNS. Jest to poniekąd dziwne, gdyż to Apple ostatnio kreuje pozytywne myślenie odnośnie bezpieczeństwa (sic!).

Jeżeli wszystko wykonaliśmy prawidłowo, to przechodzą na stronę https://1.1.1.1/help sprawdzimy, czy nasz DoH działa, czy nie. Jednakże nie jest to 100%-owa wykładnia, szczególnie gdy używasz innej metody implementacji bezpiecznego DNS w twojej sieci domowej, o której napiszę za chwilę.

Nim przejdę dalej, zadasz pytanie, jak włączyć DNS over HTTPS na tablecie lub telefonie komórkowym.

Otóż nic prostszego! Wystarczy zainstalować dedykowaną aplikację 1.1.1.1 ze Sklepu Play (Android) lub AppStore (iOS) i postępować zgodnie z instrukcjami.

Aplikacja od Cloudflare oprócz zabezpieczenia DNS oferuje również WARP w celu przyśpieszenia serfowania w internecie, ale nie będę się o tym rozpisywał, gdyż to temat na inny wpis.

Idąc dalej…

Jeżeli doszedłeś do tego punktu, możliwe, że zaświeciła ci się żaróweczka nad głową, która przerodziła się w znak zapytania.

Jeżeli ustawiliśmy bezpieczny DNS w przeglądarce, co się dzieje, jeżeli inne programy nawiązują połączenia z wykorzystaniem serwera nazw. Otóż te niestety nie są zabezpieczone (z wyjątkiem aplikacji mobilnych z wykorzystaniem aplikacji 1.1.1.1).

Zapytasz więc, jak zabezpieczyć całą sieć i wszystkie programy w sieci wykorzystujące DNS przed wścibskimi osobami postronnymi, lub też osobami z naszej sieci domowej, które nie do końca używają nasz internet do celów do których powinny (szpiegują nas samych).

Otóż ta sprawa nie jest już taka prosta, ale możliwa.

Najlepszym rozwiązaniem byłoby włączenie DoH po stronie naszego routera. I nie mówię tutaj tylko o ustawieniu adresów DNS CloudFlare na routerze dla całej sieci (co i tak powinieneś włączyć), gdyż zapytania do serwerów nazw nadal będą wysyłane w postaci czystego, niezabezpieczonego tekstu.

Niestety, routery standardowo otrzymywane od operatorów i usługodawców internetowych nie mają możliwości włączenia DNS over HTTPS w standardzie i nic na to (z reguły) nie możemy poradzić.

Jeżeli natomiast mamy własny router, który do tego wybraliśmy, nie tylko żeby robił swoje, ale również, żeby oferował dodatkowe, zaawansowane opcje, z pomocą może nam przyjść OpenWrt.

OpenWrt to alternatywne oprogramowanie dla naszego routera, które zmienia go bardziej w box oparty na systemie Linux. Otwiera nam ono opcje na zaawansowane konfiguracje.

Aby sprawdzić, czy nas sprzęt obsługuje OpenWrt, wystarczy przejść na stronę: https://openwrt.org/toh/views/toh_fwdownload i poszukać.

Nie obejmę w tym wpisie metody instalacji OpenWrt. To pozostawiam wam, gdyż i tak ten wpis jest dość długi.

W moim przypadku, gdy używam nisko budżetowego routera ASUS RT-AC57U (https://openwrt.org/toh/hwdata/asus/asus_rt-ac57u), wystarczyło włączyć SSH, pobrać oprogramowanie, wysłać je do routera za pomocą SFTP i z wykorzystaniem pojedynczej komendy wgrać. Po ponownym uruchomieniu router wystartował z OpenWrt.

W 2018 na oficjalnym blogu CloudFlare Juande Ali poruszył sposób włączenia szyfrowania zapytań DNS z wykorzystaniem protokołu TLS - DNS over TLS (DoT).

Sprawdziłem i potwierdziłem, że ta metoda działa. Wszelkie zapytania w sieci lokalnej do serwera nazw w internecie są szyfrowane z wykorzystaniem TLS i nie da się odczytać jaki adres odwiedzamy. To, jak użyć DoT zamiast DoH napiszę w dalszej części tego wpisu.

Zacznijmy najpierw od DNS over HTTPS.

DNS over HTTPS (OpenWrt)

Sprawdzone w wersji OpenWrt 21.02 oraz OpenWrt 22.03

A więc, jeżeli zdecydowaliśmy się uruchomić DoH 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.

Poprzez przeglądarkę internetową logujemy się do naszego routera i przechodzimy do Network (Sieć) > DHCP and DNS (DHCP i DNS).

W zakładce General Settings (Ustawienia Ogólne) przechodzimy do DNS forwardings i wprowadzamy następujące serwery CloudFlare DNS:

1.1.1.1
1.0.0.1
2606:4700:4700::1111
2606:4700:4700::1001

Po czym wybieramy Save & Apply (Zapisz i Zastosuj).

Następnie przechodzimy do Network (Sieć) > Interfaces (Interfejsy) gdzie klikamy Edit (Edytuj) przy LAN. Przechodzimy do sekcji Advanced Settings (Ustawienia Zaawansowane) i w Use custom DNS servers (Używaj niestandardowych serwerów DNS) wprowadzamy serwery CloudFlare. Zapisujemy ustawienia klikając przycisk Save (Zapisz).

Ponownie wybieramy Save & Apply (Zapisz i Zastosuj).

Wracamy do SSH i sprawdzamy, czy aby napewno mamy zainstalowany pakiet dnsmasq oraz dodatkowo instalujemy https-dns-proxy

opkg install dnsmasq https-dns-proxy

Warto również doinstalować graficzny interfejs do naszego panelu sterowania przez przeglądarkę internetową.

Możemy to zrobić wykonując komendę

opkg install luci-app-https-dns-proxy

Aby włączyć szyfrowanie DNS przez HTTPS wykonujemy następującą komendę:

uci -q delete dhcp.@dnsmasq[0].server
DOHPROXY_ADDR="$(uci get https-dns-proxy.@https-dns-proxy[0].listen_addr)"
DOHPROXY_PORT="$(uci get https-dns-proxy.@https-dns-proxy[0].listen_port)"
DOHPROXY_SERV="${DOHPROXY_ADDR//[][]/}#${DOHPROXY_PORT}"
uci add_list dhcp.@dnsmasq[0].server="${DOHPROXY_SERV}"

Ostatnim krokiem pozostaje wymuszenie na wszystkich użytkownikach sieci lokalnej (LAN) używanie szyfrowanego — bezpiecznego DNS. Dokonujemy tego za pomocą komendy:

uci set dhcp.@dnsmasq[0].noresolv="1"
uci commit dhcp

Po czym restartujemy dnsmasq komendą:

/etc/init.d/dnsmasq restart

Aby sprawdzić, czy nasz router działa jako pośrednik szyfrujący, wykonujemy następującą komendę:

nslookup openwrt.org localhost

Po czym powinniśmy otrzymać odpowiedź.

Po tych czynnościach w DHCP & DNS zauważymy, że nasze serwery DNS, które wprowadziliśmy wcześniej uległy zmienieniu na 127.0.0.1#5054 (CloudFlare) lub 127.0.0.1#5053 (Google).

W panelu administracyjnym, w zakładce Services (Usługi) > DNS HTTPS Proxy możemy sprawdzić, który port odpowiada za CloudFlare, a który za Google. Również tam możemy dodać inne usług. Osobiście polecam pozostawienie tylko CloudFlare.

Przechodząc na stonę https://1.1.1.1/help zobaczymy, że używamy Cloudflare jako domyślny serwer nazw (DNS) oraz, że nasze zapytania DNS są szyfrowane przez HTTPS (DoH).

Szybko i w miarę bezboleśnie zabezpieczyliśmy całą naszą sieć lokalną i zmusiliśmy do używania DNS over HTTPS (DNS przez HTTPS) przy każdym zapytaniu do serwera DNS.

Dodatkowo…

Według oficjalnego wpisu na stronie OpenWrt odnośnie DNS przez HTTPS widnieje informacja, że lokalny system (nasz router), nie używa dnsmasq jako domyślnego systemu DNS gdy szyfrowanie jest włączone. W tym istnieje znany problem związany z synchronizacją czasu (przez protokół NTP) na przeróżnych urządzeniach, gdy szyfrowanie DNS jest włączone.

Aby zmienić/naprawić powyższe, pozostało kilka dodatkowych komend do wykonania.

Wymuszenie szyfrowania DNS dla lokalnego systemu (routera)

uci set dhcp.@dnsmasq[0].localuse="1"

Pobranie informacji o usługodawcy DNS

. /lib/functions/network.sh
network_flush_cache
network_find_wan NET_IF
network_find_wan6 NET_IF6
network_get_dnsserver NET_DNS "${NET_IF}"
network_get_dnsserver NET_DNS6 "${NET_IF6}"

Ominięcie szyfrowania DNS dla szyfrowania czasu poprzez NTP

uci get system.ntp.server \
| sed -e "s/\s/\n/g" \
| sed -e "s/^[0-9]*\.//" \
| sort -u \
| while read -r NTP_DOMAIN
do
uci add_list dhcp.@dnsmasq[0].server="/${NTP_DOMAIN}/${NET_DNS%% *}"
uci add_list dhcp.@dnsmasq[0].server="/${NTP_DOMAIN}/${NET_DNS6%% *}"
done
uci commit dhcp

Na koniec restartujemy dnsmasq

/etc/init.d/dnsmasq restart

Idąc dalej…

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.

Pakiet https-dns-proxy do prawidłowego działania używa certyfikatów jednostek uwierzytelniających, w związku z tym, co jakiś czas należy te certyfikaty odnowić. Spotkałem się ostatnio z problemem, gdzie DNS over HTTPS nagle przestało działać (było to przy okazji robienia wpisu: Ustawienie domeny dla zmiennego adresu IP (OpenWrt i DDNS). Okazało się wówczas, że plik przechowujący certyfikaty w systemie został uszkodzony i należało go ponownie pobrać:

Przy pomocy curl

curl -k -o /etc/ssl/certs/ca-certificates.crt https://curl.se/ca/cacert.pem

Domyślnie system nie posiada curl zainstalowanego. Aby go dodać, wykonujemy następującą komendę:

opkg update
opkg install curl

Przy pomocy wget

wget  --no-check-certificate -O /etc/ssl/certs/ca-certificates.crt http://curl.se/ca/cacert.pem

Była to sytuacja nietypowa, ale jednocześnie dała do myślenia, gdyż certyfikaty w naszym systemie powinny być co jakiś czas odświeżane. W tym celu możemy dodać odpowiednią regułę do harmonogramu (Scheduled Tasks), która będzie robić to za nas pierwszego każdego miesiąca o godzinie 3 w nocy.

Przechodząc do System > Scheduled Tasks dodajemy następującą linię:

Dla curl

00 3 1 * * /usr/bin/curl -k --silent --remote-name --time-cond /etc/ssl/certs/ca-certificates.crt -o /etc/ssl/certs/ca-certificates.crt https://curl.se/ca/cacert.pem >/dev/null 2>&1

Dla wget

00 3 1 * * /usr/bin/wget -q --timestamping --no-check-certificate -O /etc/ssl/certs/ca-certificates.crt http://curl.se/ca/cacert.pem >/dev/null 2>&1

Drobna uwaga.

Wbudowany w OpenWrt wget może nie posiadać opcji sprawdzania czasu (–timestamping) dla plików. W tym celu należy zainstalować (zaktualizować) jego najnowszą wersję:

opkg update
opkg install wget

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: 1.1.1.1@853                   
  forward-addr: 1.0.0.1@853                             
  forward-addr:.6:4700:4700::1111@853
  forward-addr:.6:4700:4700::1001@853
  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 root@192.168.1.1 tcpdump -i eth0.2 -U -s0 -w - 'not port 22' | sudo wireshark -k -i -

Oczywiści, 192.168.1.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 Save & Apply (Zapisz i Zastosuj) 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ć.