resolver

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

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 .

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.

Aero2 w połączeniu z dnsmasq i dnscrypt-proxy

Aero2 już od dość dawna oferuje darmowy dostęp do internetu w technologi LTE ale jakoś wcześniej nie byłem tym tematem zainteresowany. Parę dni temu złożyłem jednak wniosek o kartę SIM, tak by posiadać zapasowe łącze na wypadek, gdyby mój obecny ISP z jakiegoś powodu padł. Aero2 oferuje wersję komercyjną jak i tę za free i każda z nich ma swoje wady i zalety. Jako, że to łącze ma robić jedynie za zapas, to korzystam z wersji FREE, a jest ono dość poważne ograniczenie, tj. występuje tutaj kod CAPTCHA, który trzeba wpisywać tak co godzinę, po czym należy resetować modem. Ten kod może zostać zaserwowany jedynie w przypadku korzystania z DNS Aero2 i pozornie odpada możliwość używania własnego systemu DNS opartego o dnsmasq i dnscrypt-proxy. Po kilku dniach eksperymentów udało mi się wypracować przyzwoitą konfigurację, która potrafi obejść to ograniczenie, poprawiając tym samym prywatność i bezpieczeństwo w internecie korzystając z darmowego LTE za sprawą Aero2. W tym wpisie postaramy się zaimplementować ten mechanizm na debianie.

Cache DNS, czyli włączenie buforowania zapytań

Większość z nas wie, że standardowe instalacje systemu linux nie buforują żadnych zapytań do serwerów DNS. Dzieje się tak dlatego, że te systemy domyślnie nie mają zainstalowanego żadnego oprogramowania, które by im to umożliwiało. Niesie to ze sobą zwiększenie opóźnień transakcji krótkoterminowych, np. tych w protokole http czy https. Za każdym razem gdy odwiedzamy jakiś serwis www, musimy wykonać szereg zapytań DNS, by rozwiązać nazwy domen na adresy IP. W przypadku gdybyśmy mieli cache DNS, to te nazwy nie musiałyby być za każdym każdym razem rozwiązywane na nowo, przynajmniej nie przez odpytywanie zdalnego serwera DNS, do którego RTT wynosi jakieś 20-40ms. Przydałoby się zatem nieco poprawić wydajność stron www i w tym wpisie postaramy się zaimplementować prosty cache DNS z wykorzystaniem narzędzia dnsmasq.

DNScrypt-proxy, czyli szyfrowanie zapytań DNS

Do protokołów SSL/TLS w serwisach www chyba wszyscy już przywykli. Obecnie praktycznie na każdej stronie, gdzie jest okienko logowania, mamy do czynienia z szyfrowaniem danych przesyłanych w różnego rodzaju formularzach. Co prawda, klucze nie są zbyt długie (512-2048 bitów) ale zawsze to lepsze niż nic. O ile dane służące do logowania czy też wszelkie operacje dokonywane w panelach administracyjnych da radę ukryć bez większego problemu, o tyle zapytania DNS są przesyłane otwartym tekstem i każdy może je sobie podejrzeć. Pytanie tylko, po co szyfrować ruch DNS? Czy są tam przesyłane jakieś ważne informacje? Jeśli przyjrzymy się jak działa system DNS, możemy dojść do wniosku, że szyfrowanie zapytań jest pozbawione sensu, bo z reguły nazwa domeny oznacza konkretny adres IP. Znając adres IP, możemy ustalić kto na jakie strony wchodzi. Nie do końca jest to prawdą, poza tym istnieją jeszcze inne czynniki, które sprawiają, że ukrycie zapytań DNS ma jak najbardziej sens. W tym wpisie zaimplementujemy sobie na naszych linux'ach szyfrowanie zapytań DNS przy wykorzystaniu narzędzia dnscrypt-proxy.