Kto wie, jakie strony odwiedzasz?

detektywi.it 5 lat temu

W lipcu jeden z najpopularniejszych serwerów DNS BIND skończył 33 lata. Pierwsza wersja standardu DHCP przypada na rok 1993 (RFC1531). Od tego czasu świat poszedł naprzód i większość protokołów została zastąpiona swoimi szyfrowanymi odpowiednikami (Telnet → SSH, FTP → SFTP, HTTP → HTTPS). DNS i DHCP przetrwały praktycznie bez zmian. W tym artykule przedstawi, jakie konsekwencje dla prywatności niesie ze sobą używanie tych standardów i jak w prosty sposób można to naprawić.

Inspiracją do tego posta jest wykład twórcy curla z tegorocznego FOSDEMu, który opisaliśmy tu: https://detektywi.it/2019/02/fosdem-2019/.

Trochę historii

– A więc: internet jest zjebany, Julita. To pierwsza ważna informacja. Zbudowano go na błędnych założeniach. Albo inaczej: w innym celu, który nijak ma się do tego, jak używamy go dzisiaj. To miała być sieć wojskowa o ograniczonym dostępie. Koncepcja była taka, iż skoro już jesteś zalogowany, można ci zaufać. Zanim ktokolwiek to dobrze przemyślał, sieć miała miliony użytkowników. I tak już zostało: zjebane. Zapisałaś sobie? Zje-ba-ne.

“Cokolwiek wybierzesz”, Jakub Szamałek, 2019

DNS, BGP i DHCP powstawały w czasach, kiedy Internet był miłym i przyjaznym miejscem, a nikt choćby nie myślał o bezpieczeństwie, bo jego gwarantem była mała liczba użytkowników. Pierwsze podejście do DNSu to zwykły plik z parami: nazwa hosta i adres IP (obecnie /etc/hosts). Wszystkie wpisy edytowano manualnie, co przy rosnącej liczbie klientów było bardzo uciążliwe.

Podobnie było z protokołem Dynamic Host Configuration Protocol (DHCP). W początkach sieci TCP/IP adresy hostów przydzielano manualnie. To administrator podczas konfigurowania maszyny ustalał jej adres raz na zawsze. Jednak kiedy sieci rosły, konieczność manualnej konfiguracji adresów IP zaczęła być uciążliwa. Dodatkowo komputery stały się coraz bardziej przenośne, przez co w sieciach pojawiały się i znikały urządzenia, a to skutkowało wysychaniem puli adresów podsieci. Aby usprawnić ten proces, powstał mechanizm automatycznego przydzielania adresów w ramach zdefiniowanej podsieci.

Pomysł na usprawnienie tych procesów był bardzo prosty – decentralizacja. Internet od początku pomyślany był jako zdecentralizowana sieć, co zapewnia jego działanie, choćby gdy pojedyncze podsieci nie są aktywne.

Jak działa DNS?

Kiedy chcemy połączyć się z domeną, np. detektywi.it, nasz system sprawdza, czy adres IP jest już znany (może być w pamięci po wcześniejszym zapytaniu lub na dysku w pliku hosts). jeżeli system nie może znaleźć odpowiadającego adresu IP, wysyła zapytanie do rekursywnego serwera nazw. Ten serwer działa podobnie, i znów, jeżeli nie może znaleźć odpowiedzi u siebie, to odpytuje root serwer. Takich serwerów jest kilkanaście, a odpowiadają one za geograficzne obszary świata. Nie przechowują informacji o wszystkich domenach, ale wiedzą gdzie szukać źródła. W związku z tym domena detektywi.it zostanie przesłana do serwerów odpowiadających za Włochy (domena najwyższego poziomu it odpowiada za Italię), które następnie kontaktują się z serwerami cloudflare, a one podają odpowiednią destynację. Chociaż cały proces jest skomplikowany, zajmuje milisekundy, a wielopoziomowe cachowanie zmniejsza narzut na komunikację i w rezultacie odpowiedź dostaniemy bezpośrednio z pierwszego serwera DNS.

Jak działa DHCP?

Niestety nie ma dokładnych informacji na temat tego, czym inspirowany był protokół DHCP, ale przypomina on bar, do którego wchodzi człowiek i pyta kto jest barmanem. Nikt się nie odzywa, aż w końcu zgłasza się barman i wskazuje mu miejsce. Kiedy łączymy się z siecią nasz komputer działa podobnie: wysyła żądanie DHCP Discover do wszystkich komputerów w sieci (broadcast). W zamian serwer DHCP odpowiada mu na to zapytanie przez pakiet DHCP Offer przydzielając mu adres IP i informując o adresie serwera nazw oraz adresie bramy bramie. Dane, które zostaną zwrócone, można podejrzeć w ruchu sieciowym albo przy pomocy nmap

Gdy wszystko się zgadza, przy pomocy pakietu DHCP Request zajmujemy przypisany adres IP. jeżeli serwer wyraża na to zgodę, dostajemy DHCP ACK.

Problemy z bezpieczeństwem

Pokrótce opisane protokoły mają wspólny problem – działają w oparciu o jawny tekst i nie mają żadnej formy uwierzytelniania, ani choćby potwierdzania spójności. Powoduje to, iż każdy może zobaczyć naszą komunikację, i co gorsze, wziąć w niej czynny udział.

Man in the middle

Wyobraźmy sobie następującą sytuację. Skoro DHCP nie jest szyfrowanym protokołem i nie ma kontroli integralności, to każdy może uruchomić własny serwer DHCP i przydzielać adresy w sieci. Co ważne, poza przydzielaniem adresu IP serwer DHCP wysyła informację o bramie oraz serwerze DNS. Dzięki temu atakujący może przekierować cały nasz ruch na swoją maszynę. Może nie jest to w obecnych czasach bardzo groźne, bo większość stron korzysta z szyfrowanego połączenia, jednak zawsze pozostaje ten 1%, który akurat szyfrowania nie ma. Z drugiej strony wykorzystując tę technikę może odciąć nam dostęp do sieci w ogóle. Inne ataki wykorzystujące błędy w DNS to DNS spoofing, Pharming, DNS hijacking.

“Metadane mówią wszystko o twoim życiu”

Stewart Baker

W swojej prezentacji Adam Haertle opowiada, jak identyfikowano osoby pozornie dbające o swoją prywatność tylko na podstawie metadanych. Czy już widzisz zagrożenia? Czasem same informacje, jakich nazw szukamy w sieci, mogą ujawnić więcej, niż byśmy chcieli. Pamiętajmy, iż każde urządzenie podłączone do sieci, które samo się aktualizuje, prawdopodobnie szuka tych aktualizacji na stronie producenta, dlatego sama informacja o tym, jakie domeny przeszukujemy, może dać informację, co mamy w domu albo jakich programów używamy. Oczywiście dochodzą do tego domeny, których sami szukamy np: raczej nie będziemy szukać gmail.com, jesli nie mamy tam konta.

Jak podsłuchać wszystkich?

Jest to dosyć proste i zdarza się kilka razy do roku (z jakiegoś powodu najczęściej w tego typu ataki zamieszane są Chiny). Wystarczy przechwycić ruch do DNS przy użyciu BGP hijacking. Wtedy możemy zbierać wszystkie zapytania użytkowników. Atak tego typu, co prawda bez przejmowania ruchu przez BGP, miał miejsce w Wenezueli.

Opisane powyżej ataki nie zawsze są niezgodne z prawem. Większość państw wymaga od dostawców internetu (ISP) blokowania wybranych stron przez przekierowanie domen na serwery rządowe. W Polsce od kilku lat wybrane strony hazardowe powinny być blokowane. Powinny, bo wygląda na to, iż Orange nie przejmuje się ustawą i ich serwery nie przekierowują ruchu na stronę ministerstwa.

Server: ...netia.com.pl dns.tpsa.pl Address: 5.226.78.34#53 194.204.159.1#53 Non-authoritative answer: Name: reloadbet42.com reloadbet42.com Address: 145.237.235.240 104.28.28.185 Name: reloadbet42.com reloadbet42.com Address: 2001:41b0:0:47::10 2606:4700:30::681c:1cb9

Jak naprawić DNS?

Jak widać, DNS nie przystaje do naszych czasów. Wszyscy go używają, bo działa, ale przecież mamy lepsze sposoby na rozwiązywanie nazw.

Domain Name System Security Extensions (DNSSEC)

Kiedy zorientowano się, iż DNS jest niebezpieczny, podjęto prace nad jego zabezpieczeniem. W 1997 roku pojawiło się pierwsze RFC 2065 z opisem nowego standardu, który zapewni spójność danych. Zdecydowano się go oprzeć na kryptografii klucza publicznego. Jednak standard ten nie szyfruje komunikacji, a jedynie potwierdza integralności danych. To znaczy, iż nie można podszyć się pod serwer DNS. DNSSEC jest stosowany, w szczególności pomiędzy resolverami i raczej nie ma klientów indywidualnych.

DNSCrypt

Prace nad tym protokołem rozpoczęto w 2008. Na początku jako tunel SSH dla DNS w systemie BSD. Protokół wspiera pełne szyfrowanie. Niestety nie jest zbyt popularny i nigdy nie miał oficjalnego RFC. Nie wspiera re-używania połączenia, ani multipleksowania żądań.

DNS over TLS (DoT)

Ogłoszony w 2016 wspiera pełne szyfrowanie. Posiada jedną wadę. W większości przypadków działa w trybie oportunistycznym. To znaczy: jeżeli nie można nawiązać połączenia TLS, przechodzi na zwykły DNS. Potencjalnie łatwy do zablokowania, gdyż używa niestandardowego portu 853. Niestety nie jest popularny wśród operatorów internetu.

DNS over HTTPS (DoH)

Najmłodszy spośród protokołów pretendujących do zastąpienia DNS. https://tools.ietf.org/html/rfc8484 Oparty jest w całości o HTTPS. Co ciekawe, minimalną zalecaną wersją HTTP dla DoH jest HTTP/2. W żądaniu HTTP przesyłamy zwykłe zapytanie DNS. Może to zrobić na dwa sposoby

stare dobre zapytanie DNS – czyli binarna paczka danych w request body
Metodą GET z parametrami w URLu

curl -H 'accept: application/dns-json' \ 'https://mozilla.cloudflare-dns.com/dns-query?name=detektywi.it' { "Status":0, "TC":false, "RD":true, "RA":true, "AD":false, "CD":false, "Question":[{ "name":"detektywi.it.", "type":28 }], "Answer":[{ "name":"detektywi.it.", "type":28, "TTL":300, "data":"2606:4700:30::681c:1864" },{ "name":"detektywi.it.", "type":28, "TTL":300, "data":"2606:4700:30::681c:1964" }] }%

DNS od Googla również wspiera DoH i nie wymaga specjalnego nagłówka, więc zadziała w przeglądarce https://dns.google/resolve?name=detektywi.it

Poza pełnym szyfrowaniem i kontrolą zgodności do zalet DoH należy zaliczyć użycie powszechnie używanego protokołu. Dzięki temu bardzo trudne jest wytropienie i zablokowanie zapytań DNS. ISP nie może w łatwy sposób zablokować dostępu do wybranych domen, ani choćby zobaczyć zapytania, dlatego wokół DoH narosło wiele kontrowersji. Brytyjscy dostawcy nazwali Mozillę czarnym charakterem internetu, a choćby jeden z twórców protokołu DNS odradza korzystanie z DoH.

Co zrobić? Jak żyć?

Włącz DoH lub DoT

O ile w Firefox działa to już od pewnego czasu, w Chrome wsparcie dla DoH powinno się pojawić lada dzień. Android P wspiera DoT domyślnie używa DoT, jeżeli jest dostępny, co niestety jest rzadkością, więc warto go samemu włączyć, w szczególności po doniesieniach o złośliwym działaniu Vodafone:

Pi Hole na ratunek

Niestety nie w każdym urządzeniu/przeglądarce możemy łatwo włączyć DoH. Jednak możemy zrobić przejściówkę ze zwykłego DNS w naszej sieci domowej do DoH. Jak to działa? Po pierwsze potrzebujemy zmienić adres DNS na naszym routerze na lokalny serwer DNS. Czasem tego nie da się zrobić, gdyż urządzenia, które dostajemy od ISP nie mają możliwości zmiany ustawień. Co wtedy? Wystarczy, iż nasz serwer będzie również serwerem DHCP. Wtedy wraz z adresem IP przyzna poprawny adres serwera DNS (czyli swój). Możemy to zrobić tylko wtedy, gdy nasz router pozwala na wyłączenie DHCP.

Na szczęście takie oprogramowanie już istnieje i jest bajecznie proste w konfiguracji. Projekt Pi Hole. Wystarczy zainstalować Pi Hole na raspberry pi albo jakimkolwiek innej maszynie (pi zero w zupełności wystarczy). Ja do tego celu wykorzystałem nieużywane ci20 – mały komputerek oparty o procesor MIPS (temat na inny post). Instrukcja krok po kroku znajduje się tu.

Pi Hole to coś więcej niż tylko serwer DNS. Pozwala on na monitorowanie i, co ważniejsze, blokowanie niechcianych domen. Dzięki temu możemy bez adblocka wyłączyć niektóre reklamy, skrypty czy potencjalnie niebezpieczne strony.

Zróbmy sobie proxy

Niestety sam Pi Hole to nie wszystko. Domyślnie pozwala na wybranie nam docelowego resolvera. Niestety domyślnie nie korzysta z DoH (co prawda można włączyć DNSSEC). Aby zapewnić sobie pełną prywatność, potrzebujemy w jakiś sposób zamienić zapytania DNS na HTTPS. Do tego celu możemy skorzystać z projektu cloudflared. Stworzony przez Cloudflare zestaw narzędzi do korzystania z ich ekosystemu posiada most DNS→DoH. jeżeli z jakiegoś powodu nie chcemy korzystać z rozwiązań Cloudflare, napisanie prostego proxy DNS jest w zasięgu każdego. W internecie jest mnóstwo gotowych projektów, w tym jeden od facebooka – doh-proxy.

Po uruchomieniu proxy musimy skonfigurować pi.hole do korzystania z lokalnego serwera DNS. I już możemy cieszyć się bezpiecznym, bardziej prywatnym Internetem. Wszystko jest opisane tu. Warto skorzystać z https://mozilla.cloudflare-dns.com/dns-query niż https://1.1.1.1/dns-query, gdyż zbiera o nas mniej danych. Oczywiście nic nie stoi na przeszkodzie, aby dodać więcej serwerów.

Jeśli z jakiegoś powodu nie chcemy korzystać z DoH, warto chociaż skorzystać z DoT. W podobny sposób można skonfigurować most DNS na DoT korzystając ze Stubby lub Unbound. Ten drugi może nam zupełnie zastąpić Pi Hole, gdyż ma podobne funkcje, ale mniej przyjazny interfejs. Można też włączyć DoT na serwerze z Pi Hole, aby choćby w lokalnej sieci zapytania DNS były szyfrowane.

1.1.1.1 czy 8.8.8.8, a może 9.9.9.9?

Niestety nie ma dobrej odpowiedzi na to, któremu dostawcy najlepiej zaufać. Możemy wybrać ten, który najszybciej odpowiada. W tym artykule opisano sposób na przetestowanie prędkości różnych serwerów. Co prawda namebench nie korzysta ani z DoT ani z DoH, ale zawsze może to być jakaś wskazówka, który serwer wybrać.

Oczywiście sam czas odpowiedzi to nie wszystko. Ważne jest również to, co dostajemy od serwera. Lokalny ISP może być zobowiązany do filtrowania odpowiedzi oraz udostępniania danych organom ścigania. Z drugiej strony DNS od dużego gracza może używać historii naszch zapytań do profilowania. Niektóre serwery wspierają technikę Extended Client Subnet (ECS), która z jednej strony pozwala resolwerowy podać nam optymalny gelokalizacyjnie adres IP, a z drugiej strony zmniejsza naszą prywatność.

Jako followup do posta zostawiam panel dyskusyjny na temat prywatności w kontekście DNS.

A odpowiedź na pytanie postawione w tytule pytanie jest tu: https://1.1.1.1/help

Idź do oryginalnego materiału