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.

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

We wpisie poświęconym systemowemu cache DNS w linux'ie mieliśmy okazję zobaczyć jak wzrasta wydajność po zaimplementowaniu tego mechanizmu. W skrócie, to ponad drugie tyle zapytań było rozwiązywanych lokalnie bez potrzeby odwoływania się do zdalnego serwera DNS, co zajmuje sporo czasu (20-40ms). Przeglądarki internetowe, np. Firefox, mają swoje wynalazki, które potrafią wyeliminować opóźnienia związane z surfowaniem po stronach www. Do nich zalicza się również cache DNS, z tym, że w tym przypadku zaimplementowany jest on na poziomie przeglądarki, a nie globalnie w systemie. Dzięki temu rozwiązaniu, nawet bez dnsmasq , Firefox jest nam w stanie zaoszczędzić sporo czasu przy przeglądaniu internetu. Zajrzyjmy zatem Firefox'owi pod maskę i sprawdźmy, które parametry dotyczące cache DNS wymagają dostosowania.

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.

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.