Bezpieczny DNS (w przeglądarce oraz na routerze z OpenWrt)

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!

Na początku 2020 roku 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 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.

W przeciągu kolejnych lat inne przeglądarki również zyskały obsługę szyfrowania zapytań DNS. Firefox ma tę funkcję domyślnie włączoną, gdzie w innych musimy to zrobić ręcznie.

W Firefox, 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

Tak jak wspomniałem wcześniej, Firefox obecnie posiada domyślnie włączone szyfrowanie DNS, jednakże, jak się możemy przekonać, nie zawsze to działa od razu. Twórcy oprogramowania zaznaczają, że to, czy usługa działa domyślnie, zależy od rejonu na świecie, w którym się znajdujemy.

Aby to sprawdzić, przechodzimy do Ustawień (Settings) > Prywatność i Bezpieczeństwo (Privacy & Security), po czym przewijamy stronę do sekcji DNS over HTTPS.

Jak widać poniżej, w moim przypadku (w Wielkiej Brytanii), przy opcji domyślnej ochrony (Default Protection), status powyżej zwraca informację wyłączony (Off).

Firefox - Settings - Privacy & Security - DNS over HTTPS settings

Wybierając opcję zwiększonej ochrony (Increased Protection) możemy to zmienić. Na tym etapie mamy również do wyboru, oprócz Cloudflare również innych usługodawców.

Firefox - Settings - Privacy & Security - DNS over HTTPS - Increased Protection

Google Chrome i Microsoft Edge (Chromium)

W przypadku Google Chrome przechodzimy do Ustawień (Settings) > Prywatność i Bezpieczeństwo (Privacy and Security), gdzie w sekcji zaawansowane (Advanced) upewniamy się, że mamy włączony przełącznik przy Użyj bezpiecznego DNS (Use secure DNS).

Domyślną, zaznaczoną opcją, jest używanie bezpiecznego DNS, od obecnego usługodawcy, co jednak nie jest sprecyzowane, którego, oraz jest zaznaczony fakt, że czasami ta opcja może nie być dostępna (Secure DNS may not be available at all time).

W związku z tym lepiej wybrać kolejną opcję i z listy wybrać Cloudflare lub innego usługodawcę.

Google Chrome - Settings - Privacy and Security > Secure DNS

Analogicznie w przypadku Microsoft Edge przechodzimy do Ustawień (Settings) > Prywatność, Wyszukanie i usługi (Privacy, Search, and Services) gdzie w sekcji Bezpieczeństwo (Security) zaznaczmy opcję przy Używaj bezpiecznego DNS… (Use secure DNS to specify how to lookup the network address for websites). Wybierając drugą opcję, jak w Google Chrome, możemy wybrać naszego usługodawce, np. Cloudflare.

Safari

Tutaj niestety nic nie możemy włączyć — ustawić, aby zacząć używać szyfrowanego DNS. Apple wbudowało ochronę naszych zapytań do serwerów DNS w system (macOS, iOS lub iPadOS), pod warunkiem, że mamy wykupiony pakiet iCloud+, który zapewni nam usługę Private Relay.

Pozytywną stroną tego rozwiązania jest fakt, że wszystkie nasze zapytania do serwerów DNS, również z innych aplikacji, są szyfrowane. Wówczas nie jesteśmy ograniczeni tylko do przeglądarki internetowej. Negatywną stroną jest fakt konieczności płacenia Apple za tego typu usługę.

Jeżeli natomiast nie chcemy płacić, a chcemy otrzymać zabezpieczenie dla naszego całego systemu dla systemów od Apple, ale również Windows oraz urządzeń z Androidem, wystarczy zainstalować aplikację WARP (1.1.1.1) od Cloudflare, która dostarczy nam to, co oferuje Apple w ramach Private Relay. O tym więcej poniżej.


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 przejdziesz dalej, zadasz pytanie, jak włączyć DNS over HTTPS na tablecie lub telefonie komórkowym.

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

Aplikacja Cloudflare 1.1.1.1 Połączona (Connected)

Cloudflare 1.1.1.1 Informacje o połączeniu

Cloudflare 1.1.1.1 Połączony wraz z DNS przez HTTPS (DoH)

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

System Windows 11 posiada również możliwość włączenia szyfrowania serwerów DNS w całym systemie z poziomu ustawień naszej karty sieciowej. Osobiście tego nie używam, gdyż w moim środowisku firmowym powoduje problemy, ale nie znaczy to, że nie można. Odsyłam tutaj do wpisu Enable DNS over HTTPS (DoH) in Windows 11.


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 mbilnych z wykorzystaniem aplikacji WARP (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ć.


DNS over HTTPS (OpenWrt)

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 obecnie używane w routerze do najnowszych wersji, nim zaczniemy instalację.

Po czym przystępujemy do instalacji naszego pakietu do szyfrowania DNS.

opkg install https-dns-proxy luci-app-https-dns-proxy

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ź.

Takim sposobem szyfrowanie DNS z poziomu routera działa.

Domyślnie, pakiet na routerze wykorzystuje serwery Cloudflare (jako podstawowy) oraz Google (zapasowy), w zależności, który aktualnie jest dostępny.


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#5053 (Cloudflare) lub 127.0.0.1#5054 (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.

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.


Idąc dalej…

Na routerze z OpenWrt możemy również uruchomić szyfrowanie DNS po TLS, jednakże, żę wymaga to sporej ilości zasobów systemowych, oraz porządnego routera, dlatego też zdecydowałem się nie opisywać tej metody.

Tak na marginesie, wszyscy wprowadzają DNS over HTTPS jako standard co wypycha opcję szyfrowania po TLS. Podobnie jak było z płytami HD DVD i Blu-ray. Jak wiem, Blu-ray przyjął się znacznie lepiej, a HD DVD umarł śmiercią naturalną. Podejrzewam, że w przypadku DNS over TLS też się tak stanie.

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).


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 (lub posiada w wersji okrojonej). Aby go dodać, wykonujemy następującą komendę:

opkg update
opkg install curl

Curl jest dobrą metodą na aktualizację certyfikatów. Jeżeli uruchamiamy ją po raz pierwszy, gdy w systemie nie mamy żadnych certyfikatów, wówczas może ona zwrócić błąd. W związku z tym warto jest wykorzystać wget na początku a później polegać na 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 (w niektórych wersjach) 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

Śledzenie pakietów

Aby sprawdzić, czy oby rzeczywiście nasze zapytania do internetu nie są wysyłane w postaci łatwego do odczytania tekstu, możemy podłużyć się pakietem tcpdump.

opkg install tcpdump

A na naszym komputerze instalujemy program WireShark, który posłuży do przechwycenia pakietów bezpośrednio z routera.

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.

I to by było na tyle.

Pozdrawiam.

Komentarze
Kategorie