Bezpieczny DNS

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─Ö.

Firefox Menu > Preferences (Ustawienia)

Firefox Menu > Preferences (Ustawienia) > General (Og├│lne)

Firefox Menu > Preferences (Ustawienia) > General (Og├│lne) > Network Settings (Ustawienie sieci) zaznaczamy Enable DNS over HTTPS

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─Ö.

W┼é─ůczamy flag─Ö w Microsoft Edge > Secure DNS lookups

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

Strona główna routera z oprogramowaniem 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).

OpenWrt z menu wybieramy 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).

OpenWrt. W menu sieci dodajemy adresy DNS do CloudFlare

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

OpenWrt. Edytujemy interfejs sieci lokalnej i dodajemy adresy DNS do CloudFlare

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.

OpenWrt. Przechodzimy do menu Serwices (Usługi) a następnie > DNS over HTTPS Proxy

Us├│wamy Google z konfiguracji DNS over HTTPS proxy w OpenWrt

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.

Odczytywanie niezabezpieczonych rekord├│w DNS w sieci lokalnej przy pomocy WireShark DNS

Odczytywanie zabezpieczonych rekord├│w DNS przy pomocy TLCv1.3 w sieci lokalnej przy pomocy WireShark 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.

OpenWrt Status Services Recursive DNS

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

OpenWrt Recursive DNS Status Statistics

Moja konfiguracja:

OpenWrt Recursive DNS Files UCI extended

OpenWrt Recursive DNS Files UCI

OpenWrt Recursive DNS Unbound Advances

OpenWrt Recursive DNS Unbound Basics

OpenWrt Recursive DNS Unbound DHCP Part 1

OpenWrt Recursive DNS Unbound DHCP Part 2

OpenWrt Recursive DNS Unbound Resources Part 1

OpenWrt Recursive DNS Unbound Resources Part 2

OpenWrt Recursive DNS Zones

I to by było na tyle.

Pozdrawiam.

Komentarze
Kategorie