dns

Szyfrowany DNS z dnscrypt-proxy i dnsmasq na Debian linux

Ostatnio na forum dug.net.pl jeden z użytkowników miał dość spory problem z ogarnięciem zadania polegającego na zaszyfrowaniu zapytań DNS z wykorzystaniem dnscrypt-proxy i dnsmasq. Ładnych parę lat temu opisywałem jak skonfigurować te dwa narzędzia na Debianie (i też na OpenWRT), choć od tamtego czasu w świecie linux'owym trochę rzeczy się pozmieniało. Dla przykładu, dnscrypt-proxy przeszedł gruntowną przebudowę, no i też systemd jest w powszechniejszym użyciu niż to miało miejsce w tamtych czasach, przez co w sporej części przypadków usługi takie jak systemd-networkd.service czy systemd-resolved.service są już włączone domyślnie. Zatem sporo informacji zawartych w tych napisanych przeze mnie artykułach już niekoniecznie może znaleźć obecnie zastosowanie. Dlatego też pomyślałem, że nadszedł już czas, by ździebko zaktualizować tamte wpisy. Ostatecznie stanęło jednak na tym, by w oparciu o te artykuły napisać kompletnie nowy tekst na temat szyfrowania zapytań DNS na linux przy wykorzystaniu oprogramowania dnscrypt-proxy oraz dnsmasq i zawrzeć w nim te wszystkie ciekawsze informacje, które udało mi się pozyskać przez te ostatnie lata w kwestii poprawy bezpieczeństwa i prywatności przy przeglądaniu stron WWW.

Jak włączyć w Firefox ESNI (Encrypted SNI)

Obecnie szyfrowanie zapytań DNS staje się powoli normą za sprawą protokołu DoH (DNS over HTTPS) lub DoT (DNS over TLS). Można by zatem pomyśleć, że wraz z implementacją szyfrowania tego kluczowego dla działania internetu protokołu (przynajmniej z naszego ludzkiego punktu widzenia), poprawie ulegnie również nasza prywatność w kwestii odwiedzanych przez nas stron WWW. Niemniej jednak, w dalszym ciągu można bez problemu wyciągnąć adresy domen, które zamierzamy odwiedzić. Nie ma przy tym żadnego znaczenia ile stron jest hostowanych na danym adresie IP, ani nawet fakt, że ruch do serwera WWW będzie szyfrowany (w pasku adresu wpiszemy https:// ) z wykorzystaniem protokołu SSL/TLS (w tym również TLS v1.3). Wszystko przez rozszerzenie SNI (Server Name Indication), którego to zadaniem jest umożliwienie jednemu serwerowi na prezentowanie wielu certyfikatów hostowanych w jego obrębie domen. Dzięki takiemu rozwiązaniu, każda domena może szyfrować ruch niezależnie od siebie na linii serwer<->klient (używać innych kluczy szyfrujących). Niemniej jednak, podczas nawiązywania szyfrowanego połączenia, w pakiecie ClientHello przesyłanym do takiego serwera musi znaleźć się nazwa domeny, której to certyfikat serwer będzie musiał nam przedstawić. Niestety ten pakiet jest przesyłany przez sieć otwartym tekstem, przez co każdy, kto podsłuchuje naszą komunikację (w tym też nasz ISP), bez problemu może ustalić na jakie strony internetowe wchodzimy. Ostatnimi czasy jednak pojawiły się dwa rozszerzenia ECH (Encrypted Client Hello) oraz ESNI (Encrypted SNI), które mają zaadresować problemy związane z prywatnością przez pełne zaszyfrowanie pakietu ClientHello lub też zaszyfrowanie jedynie pola SNI w tym pakiecie. Póki co, prace nad tymi rozszerzeniami nie są jeszcze skończone ale Firefox w połączeniu z CloudFlare powoli testują ESNI. Postanowiłem zatem dobrowolnie przyłączyć się do grupy testerów i wdrożyć na swoim linux'ie to rozszerzenie ESNI dla przeglądarki Firefox.

Instalacja i konfiguracja AdGuard na routerze z OpenWRT

Jakiś już czas temu opisywałem w jaki sposób skonfigurować AdBlock'a na routerze WiFi z wgranym firmware OpenWRT oraz jak wdrożyć szyfrowanie zapytań DNS w oparciu o dnscrypt-proxy dla wszystkich klientów naszej sieci domowej. Zarówno AdBlock jak i dnscrypt-proxy można w dalszym ciągu wykorzystywać, zwłaszcza na routerach wyposażonych w niewielkich rozmiarów flash i mało pamięci RAM. Niemniej jednak, nie każdy lubi konfigurować swój bezprzewodowy router za pośrednictwem terminala. Dla takich osób powstał właśnie AdGuard Home, który ma na celu możliwie uprościć konfigurację routera, przynajmniej jeśli chodzi o rzeczy związane z protokołem DNS. W tym artykule przyjrzymy się nieco bliżej AdGuard'owi i zobaczymy czy można z niego zrobić jakiś większy użytek.

Jak zaszyfrować zapytania DNS na smartfonie (dnscrypt-proxy)

Smartfony to takie małe komputery, z których praktycznie każdy z nas korzysta na co dzień. Nie różnią się one zbytnio od tych domowych PC czy laptopów, no może za wyjątkiem rozmiarów. Wszystkie elementy tyczące się spraw sieciowych, np. korzystanie z internetu za pomocą przeglądarki, są dokładnie taka same co w przypadku zwykłych komputerów. Na smartfonach domeny również trzeba jakoś rozwiązać. Standardowo w Androidzie są wykorzystywane serwery od Google (8.8.8.8 i 8.8.4.4). Jeśli nasza sieć WiFi oferuje inne DNS'y, to wtedy one mają pierwszeństwo. Niemniej jednak, nie zawsze będziemy w stanie kontrolować środowisko sieciowe, do którego zostaniemy podłączeni. W takiej sytuacji będziemy zdani na łaskę admina obcej sieci w kwestii poufności odwiedzanych przez nas stron www czy jakichkolwiek innych domen w internecie. Z doświadczenia wiem, by nie składać swojej prywatności w czyjeś ręce i dlatego też postanowiłem poszukać sposobu na zaszyfrowanie zapytań DNS bezpośrednio na smartfonie. Długo nie musiałem szukać, bo okazuje się, że dnscrypt-proxy jest dostępny również na Androida.

Cannot move /etc/resolv.conf.dhclient-new to /etc/resolv.conf: Operation not permitted

Użytkownicy linux'a przykładają nieco większą wagę do konfiguracji swojego systemu. Te nieco bardziej świadome jednostki zdają sobie sprawę, że różnego rodzaju automaty są w stanie przepisywać konfigurację systemową bez naszej wiedzy. Weźmy sobie resolver DNS. To bardzo krytyczna usługa, nie tylko z punktu widzenia bezpieczeństwa ale też i prywatności. Zakładając, że chcemy korzystać z pewnych określonych serwerów DNS lub też mamy skonfigurowaną usługę dnscrypt-proxy, trzeba zadbać o to, by adresy w pliku /etc/resolv.conf nie zostały z jakiegoś powodu przepisane. Użytkownicy zwykle nadają temu plikowi atrybut odporności ( chattr +i ) . Niemniej jednak, przy pobieraniu konfiguracji sieciowej za sprawą protokołu DHCP, w logu można zaobserwować komunikat: mv: cannot move '/etc/resolv.conf.dhclient-new' to '/etc/resolv.conf': Operation not permitted . Niby w niczym on nie przeszkadza ale możemy tak skonfigurować demona dhclient , by tę wiadomość wyeliminować.

Blokowanie zapytań DNS z dnscrypt-proxy na linux'ie

Narzędzie dnscrypt-proxy począwszy od wersji 1.7.0 ma domyślnie włączoną obsługę wtyczek. W standardzie nie ma ich dużo, bo jedynie trzy ale mogą one się okazać dla pewnych osób bardzo użyteczne. Dzięki tym pluginom możemy, np. zablokować rozwiązywanie nazw w protokole IPv6 na wypadek, gdyby ten protokół nie był wspierany w naszej sieci domowej czy też u naszego ISP. Możemy także zdefiniować sobie adresy/domeny, które powinny zostać zablokowane i w efekcie użytkownicy nie będą w stanie odwiedzić tych miejsc w internecie. Jest także wtyczka, która może nam pomóc zalogować zapytania DNS. Jak widać, całkiem przyzwoite są te dodatki. W tym wpisie przyjrzymy się nieco bliżej konfiguracji poszczególnych wtyczek dla dnscrypt-proxy .

Konfiguracja DDNS dla OpenDNS

Ludzkość w dalszym ciągu siedzi na przestarzałym już od prawie 20 lat protokole IPv4. Nie widać, też by w najbliższym czasie coś miało się w tej kwestii zmienić. Można, co prawda, wykupić sobie stały adres IP ale to kosztuje, no i płacimy za coś co powinniśmy mieć w standardzie, gdyby ludzie w końcu zaczęli korzystać z IPv6. Niemniej jednak, by te wszystkie nasze maszyny podłączyć jakoś do sieci, potrzebne nam są prywatne adresy IP + NAT lub też dynamicznie zmieniające się adresy publiczne. Bywają też przypadki, że mamy przydzielane dynamicznie adresy z puli prywatnej, np. w wyniku dbania o prywatność w sieciach WiFi przez generowanie sobie przy każdym połączeniu losowego adresu MAC. Zwykle w takiej sytuacji zmienia nam się adres zewnętrzny (publiczny), który wskazuje na jeden z adresów naszego ISP. Taki zmieniający się adres powoduje problemy przy konfiguracji poszczególnych usług sieciowych, np. gdy w grę wchodzi konfiguracja filtra DNS, który jest zapewniany przez OpenDNS. By tego typu niedogodności rozwiązać, możemy posłużyć się DDNS (dynamic DNS). Za każdym razem, gdy adres IP ulega zmianie, klient DDNS informuje o tym fakcie skonfigurowane usługi. W tym artykule przyjrzymy się nieco bliżej temu mechanizmowi.

DHCP i DNS, czyli konfiguracja sieci w OpenWRT

Rutery WiFi są w stanie zorganizować przewodową i/lub bezprzewodową sieć w naszych domach. By taka sieć działała bez zarzutu, potrzebna jest odpowiednia adresacja wszystkich komputerów wewnątrz niej. W obecnych czasach już praktycznie nie stosuje się statycznej konfiguracji, bo to zadanie zostało zrzucone na barki serwera DHCP. W OpenWRT do tego celu oddelegowane jest oprogramowanie dnsmasq. Zapewnia ono nie tylko wspomniany wyżej serwer DHCP ale także serwer cache'ujący zapytania DNS. Ten drugi z kolei jest niezastąpiony w przypadku przekazywania zapytań o nazwy domen do upstream'owego serwera DNS, który zajmuje się rozwiązywaniem tych nazw na odpowiadające im adresy IP. Bez dnsmasq ogarnięcie naszej sieci przerodziłoby się w istne piekło. Dlatego też w tym artykule przybliżymy sobie nieco konfigurację tego narzędzia.

Przeciek DNS (DNS leak) w VPN (resolvconf)

Przeciek DNS (dns leak) to nic innego jak wyciek poufnej informacji, za sprawą nieprawidłowej konfiguracji resolver'a DNS. Może niekoniecznie jest winne tutaj samo oprogramowanie, które realizuje zapytania DNS, czy też serwer domen jakiejś organizacji. Chodzi głównie o tematykę VPN, gdzie cały ruch sieciowy powinien być wrzucany do tunelu SSL/TLS i szyfrowany. W pewnych sytuacjach, zapytania DNS mogą zostać wysyłane pod zewnętrzny resolver, często w formie niezaszyfrowanej i do tego poza połączeniem VPN. Ten ruch można podsłuchać, przechwycić i poddać analizie. Celem tego artykułu jest tak skonfigurowanie linux'a (w tym przypadku dystrybucja Debian), by te przecieki wyeliminować. Jest to możliwe za sprawą narzędzia resolvconf.

Konfiguracja dnscrypt-proxy w OpenWRT

Realizowanie zapytań DNS jest kluczowe do poprawnego działania min. stron internetowych. Router z OpenWRT na pokładzie bez problemu potrafi rozwiązywać domeny na adresy IP. Jest to realizowane przez oprogramowanie dnsmasq . Problem w tym, że zwykle resolver, który będzie uwzględniany w konfiguracji routera, wskazuje na serwery DNS naszego ISP, czy też jakiejś większej korporacji. W ten sposób, wszystkie dane z przeglądania stron internetowych podajemy tym organizacjom za free. Przy pomocy narzędzia dnscrypt-proxy jesteśmy w stanie zabezpieczyć naszą sieć przed tego typu zabiegami zbierania danych. Po części też możemy uchronić się przed cenzurą, którą może nam zafundować lokalny provider internetowy. W tym artykule zaimplementujemy obsługę szyfrowanego resolver'a DNS na naszym domowym routerze.