Przenośny router chroniący prywatność: obsługa DNS-Over-TLS w OpenWRT (LEDE) z Unbound

Dziś udostępniamy szczegółową instrukcję konfiguracji DNS-Over-TLS na GL-AR750 , której autorem jest Junade Ali. Jeśli nie wiesz, czym jest DNS-Over-TLS, oto krótka ciekawostka:

Wścibski dostawca Internetu może analizować każdy Twój ruch w sieci i sprzedawać te dane reklamodawcom oraz firmom marketingowym. DNS-Over-TLS to nowe narzędzie bezpieczeństwa przeglądania, które chroni prywatność użytkownika. Szyfruje zapytania DNS, zapobiegając podsłuchiwaniu i manipulowaniu danymi DNS przez ataki man-in-the-middle.

---

Aby przejść od razu do instrukcji, przewiń do następnej sekcji. Ale podobnie jak uzgadnianie TLS jestem bardzo rozmowny, więc zapraszam do lektury wstępu.

Wyobraź sobie taką sytuację: jestem w restauracji i potrzebuję przeprowadzić prywatną rozmowę telefoniczną, ale niestety bateria telefonu się rozładowała. Aby rozwiązać problem, pożyczam telefon od znajomego i wybieram numer. Chcąc chronić prywatność, wychodzę na zewnątrz. Po zakończeniu rozmowy wracam do środka i oddaję telefon.

Choć telefon nie przechowuje samej rozmowy, ma historię ostatnio wybranego numeru. Znajomy, od którego pożyczyłem telefon, mógłby łatwo sprawdzić, do kogo dzwoniłem, nawet jeśli nie znałby tematu rozmowy.

Czasem informacja o tym, z kim rozmawiano, zdradza bardzo wiele o rozmowie. Jeśli ktoś zadzwonił na infolinię wsparcia emocjonalnego lub do firmy windykacyjnej, już sam identyfikator rozmówcy pozwala wyciągnąć wiele wniosków o rozmowie.

Przeglądając Internet, używamy szyfrowania, aby chronić nasze rozmowy. Gdy łączysz się ze stroną przez HTTPS, zielona kłódka w przeglądarce informuje, że rozmowa jest zaszyfrowana tak, by napastnikowi znajdującemu się między Tobą a serwerem strony było obliczeniowo trudno zobaczyć jej treść.

Wcześniej pisałem o tym, jak w pewnych okolicznościach można usunąć to szyfrowanie i jakie środki mogą stosować strony, aby temu zapobiec. Niestety istnieje znacznie bardziej fundamentalny problem prywatności w sieci.

Jak powszechnie wiadomo w IT, zanim przeglądarka nawiąże połączenie HTTP ze stroną (np. cloudflare.com), klient musi wysłać zapytanie DNS, aby ustalić adres IP, z którym ma nawiązać połączenie HTTP. To samo dotyczy innych protokołów warstwy aplikacji, gdy łączysz się przez nazwę hosta zamiast adresu IP. Wprowadzenie do DNS znajdziesz w artykule o podstawach DNS w naszym Learning Centre.

Choć technologie szyfrowania HTTP istnieją już od dawna, takie techniki zostały ustandaryzowane dla DNS dopiero niedawno. Jeśli nie wiesz, czy Twój ruch DNS jest szyfrowany, prawdopodobnie nie jest.

W praktyce oznacza to, że gdy łączysz się ze stroną używającą HTTPS, nawet jeśli rozmowa jest zaszyfrowana, osoba mogąca przechwycić połączenie zobaczy, jakiej strony szukasz, i (zależnie od zabezpieczeń strony) może nawet zmanipulować odpowiedź, aby skierować Cię do innego serwera.

Jest to szczególnie przydatne dla podsłuchujących: zarówno dla operatora bezpłatnego hotspotu Wi-Fi, który chce sprzedać Twoje dane reklamodawcom, jak i dla hakera popijającego latte podczas przechwytywania ruchu sieciowego (ironicznie ubranego w czarną bluzę z kapturem i kominiarkę).

Przełączając resolver DNS na Cloudflare DNS Resolver, przyspieszasz przeglądanie i masz pewność, że operatorzy resolvera DNS nie sprzedają tych danych do kierowania reklam. Choć Cloudflare Resolver obsługuje DNS-over-HTTPS i DNS-over-TLS, aby mieć pewność, że połączenie między Cloudflare Resolver a Tobą jest szyfrowane, może być konieczna dodatkowa konfiguracja, np. włączenie klienta DNS over HTTPS.

Ten wpis wyjaśnia, jak skonfigurować router OpenWRT, aby szyfrował ruch wychodzący do Cloudflare Resolver. Jest to szczególnie przydatne, gdy chcesz chronić ruch urządzeń domowych, które mogą nie obsługiwać szyfrowanych protokołów DNS, takich jak telewizor lub toster z IoT. Choć lokalni klienci mogą jawnie zastąpić lokalny resolver DNS w routerze, wielu domyślnie będzie z niego korzystać.

OpenWRT (LEDE)

W weekend przed napisaniem tego wpisu zamówiłem nowy router bezprzewodowy GL.iNet GL-AR750. Ten router ma bardzo małe wymiary i jest oferowany jako „router podróżny”. Może działać jako repeater Wi-Fi oraz tradycyjny router Wi-Fi. Jego najdłuższy bok ma mniej więcej długość mojego palca wskazującego:

Zamówiłem ten router nie tylko ze względu na wymiary. Ma również fabrycznie zainstalowany OpenWRT, wbudowany system operacyjny oparty na Linux, dobrze przystosowany do routerów. W maju 2016 projekt OpenWRT został rozwidlony jako LEDE (Linux Embedded Development Environment), a następnie ponownie połączony z projektem OpenWRT w styczniu 2018.

Jeśli nie masz routera z fabrycznie zainstalowanym LEDE, możesz wykonać kroki z tego wpisu na innym routerze, który umożliwia wgranie oprogramowania układowego OpenWRT. Więcej informacji znajdziesz na stronie OpenWRT Support Devices. Pamiętaj jednak, że zależnie od urządzenia może się to wiązać z pewnym ryzykiem.

Obsługa DNS-over-TLS (lub jej brak)

Router, który testuję, ma opcję konfiguracji nadrzędnego resolvera DNS używanego, gdy zapytanie nie znajduje się w pamięci podręcznej wewnętrznego resolvera. Ten lokalny resolver jest następnie sugerowany klientom łączącym się z routerem.

Na potrzeby eksperymentu mogę przez interfejs WWW skonfigurować router tak, aby używał 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111 i 2606:4700:4700::1001 jako nadrzędnych serwerów DNS (z odpowiednią zmianą adresów IPv6, jeśli sieć ich nie obsługuje):

Łącząc port WAN routera z komputerem, mogę przechwytywać ruch wychodzący z routera w Wireshark, zanim trafi do rzeczywistej sieci WAN. Gdy zapytania DNS nie ma w pamięci podręcznej routera, jest ono przekazywane do 1.1.1.1. Ponieważ router wysyła te zapytania bez szyfrowania zamiast używać DNS-over-TLS, mogę zobaczyć te zapytania DNS przesyłane przez Internet w niezaszyfrowanej postaci:

Choć Cloudflare Resolver obsługuje DNS-over-TLS, mój router niestety go nie obsługuje i po prostu wysyła wszystkie zapytania bez szyfrowania.

Konfiguracja DNS-Over-TLS

Domyślnie LEDE ma zainstalowany Dnsmasq jako wewnętrzny resolver, więc nie obsługuje DNS-over-TLS. Aby szyfrować zapytania, zastąpimy Dnsmasq przez Unbound i odhcpd. Kroki, które wykonuję, są oparte na przydatnej dokumentacji pakietu OpenWRT Unbound.

Zanim zaczniemy, musimy połączyć się z routerem przez SSH. Jeśli pojawi się prośba o hasło, prawdopodobnie będzie ono takie samo jak ustawione dla panelu WWW:

LEDE używa ​opkg​ jako menedżera pakietów. Najpierw zaktualizujmy listę pakietów, a następnie zainstalujmy Unbound z Unbound-Control i pełną wersję odhcpd:

opkg update
opkg install unbound odhcpd unbound-control
opkg remove dnsmasq

Możesz dodatkowo zainstalować aplikację Luci dla Unbound, aby sterować nim przez standardowy interfejs użytkownika.

opkg install luci-app-unbound

Ponieważ mój router nie używa obecnie niezmodyfikowanego LEDE, jego interfejs użytkownika nie zmieniłby się po tej instalacji. Nie testowałem tego modułu osobiście.

Po zainstalowaniu Unbound możemy dodać konfigurację, aby używał 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111 i 2606:4700:4700::1001 jako resolverów DNS z szyfrowaniem TLS. Zrobiłem to, dopisując konfigurację do /etc/unbound/unbound_ext.conf za pomocą Vim:

forward-zone:
  name: "."
  forward-addr: 1.1.1.1@853
  forward-addr: 1.0.0.1@853
  forward-addr: 2606:4700:4700::1111@853
  forward-addr: 2606:4700:4700::1001@853
  forward-ssl-upstream: yes

W pliku konfiguracji Unbound pod ścieżką /etc/config/unbounddodałem wymagane parametry konfiguracji opisane w dokumentacji pakietu. W moim przypadku wykonałem kopię pliku konfiguracji i po prostu użyłem poniższych ustawień:

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'

Jeśli w pliku masz dodatkowe parametry, upewnij się, że nic nie zastępuje ustawionych wartości. Zachowaj szczególną ostrożność przy parametrze unbound_control .

Połączyłem też poniższą konfigurację z /etc/config/dhcp (pozostawiając część istniejących wpisów bez zmian):

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'

Na koniec możemy włączyć automatyczne uruchamianie Unbound i uruchomić usługę:

service unbound enable
service unbound start

Oto praktyczny dowód: przechwytując zapytania DNS między naszym routerem a Internetem, zobaczymy, że są szyfrowane za pomocą TLS v1.2:

Podsumowanie

W tym wpisie omówiliśmy, jak szyfrowanie ruchu DNS może pomóc chronić prywatność podczas przeglądania Internetu. Zastępując Dnsmasq przez Unbound, umożliwiamy OpenWRT korzystanie z DNS-over-TLS, aby szyfrować ruch sieciowy.

---

Dziękujemy Junade Ali za zgodę na udostępnienie artykułu na naszej stronie. Artykuł został pierwotnie opublikowany na stronie Cloudflare 9 kwietnia 2018: https://blog.cloudflare.com/dns-over-tls-for-openwrt/