Sprawdzanie DNS sinkhole

W poprzednim wpisie o phishingu w Polsce pisałem, że chcę zbadać jak wygląda adopcja listy hole.cert.pl wśród ISP do DNS sinkhole zapytań o domeny używane do phishingu. Odzew był mniejszy, niż się spodziewałem, ale coś udało się zrobić. Trochę się nauczyłem i może się to przydać także do względnie łatwego, samodzielnego sprawdzania np. cenzury w sieci, nie tylko w Polsce.

Wyniki

Jeśli kogoś interesują wyniki DNS sinkhole na podstawie hole.cert.pl wśród ISP, to znajdzie je w repo. Jak widać próbka jest mała, ale pewien trend daje się zauważyć. Nawet duzi ISP kablowi nie wykorzystują listy od CERT Polska. Na pewno – co oczywiste – wykorzystują ją sygnotariusze porozumienia. CERT trafnie zauważa, że lista może być wykorzystywana nie tylko na DNS operatorów, ale także na innych poziomach (Pi-hole, filtry AdBlock). Przypomnę jednak, że chodziło mi o sprawdzenie jaka jest adopcja listy na poziomie infrastruktury ISP. Czyli bez wymagania dodatkowych urządzeń czy działań po stronie użytkowników.

Pierwotny pomysł, czyli skrypty uruchamiane przez osoby trzecie w zasadzie ląduje w koszu. Wykorzystanie sond z projektu RIPE Atlas probe pozwala sprawdzić wszystko samodzielnie, bez angażowania innych ludzi. Wyniki się pokrywają, więc w repo zostawiłem zebrane ręcznie. Przy okazji widzę, że przy wynikach przydała by się data pomiaru. Do wyciągnięcia z commitów, ale lepsza byłaby podana jawnie.

RIPE Atlas probe

Dawno temu pisałem już o RIPE Atlas probe. Ogólnie są to małe pudełka dystrybuowane przez RIPE i uruchamiane przez ochotników (zarówno firmy jak i osoby fizyczne) w swoich sieciach na całym świecie. Pozwalają na wykonywanie pomiarów zlecanych przez panel RIPE. Istnieje też wersja programowa.

Użycie RIPE Atlas probe daje całkiem spore, zwłaszcza jeśli chodzi o zasięg pomiarów, możliwości ale… nie jest proste. Po pierwsze, trzeba mieć konto i kredyty. O ile założenie konta to moment, o tyle zebranie kredytów chwilę trwa – trzeba mieć uruchomioną sondę. No chyba, że dostaniemy je od kogoś, kto już je zgromadził (dziękuję!).

Po drugie, parametrów jest dużo i podobnie jak zwracane wyniki nie są do końca oczywiste. Np. w JSON szczegółowa odpowiedź jest zakodowana w base64, przez co początkowo uznałem (nie tylko ja…), że jej tam nie ma. Dekodowanie odpowiedzi DNS jest proste i opisane w dokumentacji, z przykładami w różnych językach. Niemniej, bariera wejście jest większa, niż się spodziewałem.

Sytuacji nie poprawiał fakt, że panel RIPE jest właśnie aktualizowany czy też przerabiany i nie wszystko wydaje się działać poprawnie. Np. wyszukiwania sond zwracają różne wyniki po API i przez stronę WWW.

RIPE Atlas Tools

Ostatecznie stanęło na tym, że korzystałem z API za pośrednictwem RIPE Atlas Tools. Do prototypowania i sprawdzeń ręcznych całkiem użyteczne. Nie jest to narzędzie idealne, na przykład status jest podawany numerycznie i… nie znalazłem opisu, który co oznacza. TBH szybciej było mi sprawdzić metodą porównania z wynikami z panelu. W każdym razie status connected to 1. Opis użycia w CLI:

Usage: ripe-atlas probe-search [-h] [--asn asn] [--asnv4 asnv4] [--asnv6 asnv6] [--prefix prefix] [--prefixv4 prefixv4] [--prefixv6 prefixv6]
[--location location | --center center | --country country] [--radius radius] [--tag tag] [--limit limit]
[--field {id,asn_v4,asn_v6,country,status,prefix_v4,prefix_v6,coordinates,is_public,description,address_v4,address_v6,is_anchor}]
[--aggregate-by {country,asn_v4,asn_v6,prefix_v4,prefix_v6}] [--all] [--max-per-aggregation max_per_aggregation] [--ids-only] [--status {0,1,2,3}]

Pora na parę przykładów użycia. W zasadzie wystarczają one do sprawdzenia jak z sieci danego ISP na określonym serwerze DNS jest resolvowana domena, czyli tego, co było przedmiotem projektu. Znalezienie aktywnych sond w sieci Orange (AS5617):

ripe-atlas probe-search --asn 5617 --country pl --ids-only --status 1

Sprawdzenie rozwiązywania domeny (tu: example.com) na wskazanym serwerze DNS (tu: 8.8.8.8) i sondzie (ID 1234):

ripe-atlas measure dns --query-argument example.com --from-probes 1234 --target 8.8.8.8

Powyższe zwróci w konsoli wynik w postaci już zdekodowanej. Dodatkowo będzie tam link do wyniku w panelu RIPE, który można pobrać w postaci JSON. Wtedy trzeba zdekodować odpowiedź DNS samodzielnie w sposób linkowany wyżej.

Na koniec wystarczy porównać, czy oczekiwany wynik jest taki sam, jak z serwera co do którego mamy pewność, że nie zmienia odpowiedzi i już wiemy, czy mamy do czynienia z DNS sinkhole. No prawie, bo domena może mieć np. zróżnicowane rozwiązywania nazwy na podstawie geolokalizacji. Można oczywiście sprawdzać większe ilości sond itp., ale do sprawdzania ew. cenzurowania stron lepsze mogą być zapytania HTTP – blokada bowiem może być na innym poziomie niż rozwiązywanie nazw domen.

Co dalej?

Ustalić adresy IP serwerów DNS przydzielanych klientom przez największych polskich ISP. Sądziłem, że będzie trywialne. Niestety myliłem się. Kiedyś można było bez problemu znaleźć je w sieci na stronach poszczególnych ISP. Teraz często nie chwalą się oni tą informacją. Np. nie udało mi się znaleźć tej informacji np. dla operatorów Vectra i Toya[1]. Tu liczę na pomoc czytelników w postaci podania nazwy ISP i przydzielonych przez niego adresów serwerów DNS.

Pełny automat. Powyższe przykłady są dobre do ręcznego wykorzystania. Mam wrażenie, że odpytywanie przy pomocy RIPE Atlas Tools słabo nadaje się do oskryptowania. Obsługa timeoutów, parsowanie odpowiedzi, zapisywanie wyników – wydaje mi się, że lepiej będzie napisać wszystko w Pythonie.

Badanie czasu od pojawienia się domeny na liście do czasu zablokowania u danego ISP. Bez pełnego automatu nie ma co podchodzić do tematu. I pewnie do przemyślenia jak to potem sensownie interpretować, pewnie trzeba będzie wspomóc się statystyką.

Motywacja mi nieco siadła, więc pewnie zejdzie dłuższa chwila nim coś nowego się pojawi.

[1] Dla Netii z kolei znalazłem serwery DNS, ale nie było ochotnika do zrobienia testu wersją ze skryptem. Przy pomocy sond RIPE Atlas ustaliłem, że nie korzystają z listy CERT Polska, ale z publikacją tego poczekam na zmianę flow zamieszczania danych.

Phishing w Polsce

Phishing w Polsce ma się dobrze. Niedawno na z3s.pl pojawił się opis kolejnej kampanii phishingowej. Tak się złożyło, że równolegle widziałem opis jednej z ofiar. No i zbiegło się to w czasie z wpisem na nfsec.pl o tworzeniu RPZ dla unbound. Przypomniałem sobie o inicjatywie CERT Polska, która w założeniu może pomóc zmniejszyć liczbę ofiar tego typu ataków. Powróciło pytanie, które chodziło mi od początku po głowie, odkąd usłyszałem o projekcie hole.cert.pl[1]. Kto z tego będzie korzystał?

Phishing a hole.cert.pl

Pomysł jest prosty. Ludzie zgłaszają domeny phishingowe, CERT Polska je weryfikuje i udostępnia publicznie do wykorzystania wszystkim zainteresowanym. Zainteresowani, czyli polscy ISP, przekierowują żądania do domen wykorzystywanych przy phishingu na serwery ostrzegające użytkownika o zagrożeniu.

Pewne kontrowersje budzi analogia do rozwiązania blokującego dostęp do serwisów w ramach „ustawy antyhazardowej”. Zgadza się, w obu projektach wykorzystywany jest ten sam mechanizm. Ale są to projekty niezależne. Wszystko rozbija się tak naprawdę o „wsad”, czyli to, jakie domeny są blokowane. Jak pisałem niedawno, to samo narzędzie (tu: mechanizm) może być wykorzystane do różnych celów.

Więc tak, dla purystów wolnościowych jest to cenzura, zło i naruszenie wolności. Ale praktycznie rzecz biorąc, jest to jedyny sposób by skutecznie blokować phishingi. Szczególnie na urządzeniach mobilnych, gdzie często nie można łatwo sprawdzić domeny przed kliknięciem. Albo nie jest ona dobrze, w całości, widoczna. O ile sam raczej łatwo nie nabiorę się na phishing na desktopie, bo go zauważę[2], to w przypadku telefonu nie mam do siebie takiego zaufania. Nawet po zwróceniu uwagi i zachowaniu ostrożności.

Więc ostatecznie IMO bardzo dobra inicjatywa. Nie wymaga żadnych działań po stronie użytkowników, czyli rozwiązanie jest dostępne dla użytkowników o dowolnym poziomie wiedzy o komputerach czy bezpieczeństwie. Skutecznie blokuje dostęp do zasobu systemom korzystających z serwera DNS z wdrożonym rozwiązaniem. Jest łatwe do wdrożenia przez ISP – mają już potrzebną infrastrukturę i korzystają z niej w analogicznym projekcie. Oczywiście nie eliminuje phishingu w Polsce w zupełności, ale zmniejsza jego skuteczność.

Pomysł

Wpadłem zatem na pomysł, żeby zebrać dane, czy ISP – poza wymienionymi w porozumieniu – korzystają z tego rozwiązania. Przy okazji trochę wzrośnie świadomość, że hole.cert.pl w ogóle istnieje. Szczególnie, jeśli portale piszące o bezpieczeństwie pokuszą się o interpretację danych.

Jednak przede wszystkim ludzie dostaną argument w rozmowach ze swoimi ISP, czemu ochrona nie jest włączona. Tym bardziej, że po stronie koszt ISP praktycznie żaden. I tak już utrzymują mechanizm w związku z ustawą antyhazardową, wystarczy dodać obsługę kolejnego źródła danych.

Po krótkim namyśle stwierdziłem, że dane powinny być zbierane publicznie. Tak, aby każdy mógł sprawdzić, skąd się wzięły i ew. samodzielnie zweryfikować ich poprawność. Zresztą nie mam ani dostępu do wszystkich ISP, ani czasu na ich samodzielne testowanie.

Szybko zrobiłem repo projektu badającego adopcję hole.cert.pl na GitHubie, w którym zapisuję dane. Plus prosty skrypt w bashu, który ma ułatwić zbieranie danych.

Trudności

Niestety, nawet znając adresy IP serwerów DNS polskich ISP nie da się samodzielnie sprawdzić jak resolvują daną domenę. Ze względu na ataki DDoS wykorzystujące open resolvery DNS do amplifikacji, większość serwerów limituje dostęp do usługi. Zresztą ISP nie mają obowiązku świadczenia usługi nie swoim abonentom, więc rozumiem. To akurat wziąłem pod uwagę od początku, stąd m.in. użycie GitHub i nadzieja na pomoc innych osób.

Kolejna sprawa: nawet jeśli ktoś korzysta z danego providera, to niekoniecznie korzysta z jego serwerów DNS. I niekoniecznie ma je podane bezpośrednio w konfiguracji komputera. Dlatego trzeba podawać je jawnie. A wcześniej ustalić. Nic trudnego, ale jest to ręczna robota – albo poszukanie na stronie ISP, albo wyciągnięcie z konfiguracji.

To co mnie zaskoczyło najbardziej: Android nie daje łatwej możliwości sprawdzenia aktualnie wykorzystywanych serwerów DNS. Szczególnie przy wykorzystaniu połączenia GSM nie znalazłem tej możliwości w ogóle. Dla WiFi są programy, które to podają[3].

W zasadzie należałoby nie tylko sprawdzać, czy ISP korzysta z tych danych, ale jak często je aktualizuje. Kampanie phishingowe są coraz bardziej dynamiczne, domeny żyją nawet tylko po kilka(naście) godzin. Czas reakcji jest więc kluczowy dla rozwiązania. Synchronizacja raz dziennie byłaby słaba… Niemniej, CERT również opiera się na ręcznie dostarczanych danych i podlegają one ręcznej weryfikacji, a to potrafi chwilę trwać[4]. Wymaga to trochę innego podejścia, w tym cyklicznego uruchamiania skryptu, więc na początek odpuszczam.

Co dalej?

Planuję zebrać dane samodzielnie i z pomocą znajomych dla największych polskich ISP, którzy z nich blokują phishing. Dopracować skrypty i metody zbierania danych, szczególnie dla urządzeń mobilnych. Ustalić docelowy format plików.

Jeśli pomysł „chwyci”, postaram się dorobić badanie opóźnienia między pojawieniem się domeny na hole.cert.pl, a propagacją danych do systemów DNS danego ISP. Jeśli ktoś jest zainteresowany, zachęcam do pomocy. Raczej na GitHub, niż w komentarzach, ale nie będę wybrzydzał.

UPDATE Dobrzy ludzie przypomnieli, że istnieje coś takiego jak RIPE Atlas probe i doładowali kredyty, używane przy requestach API. Wygląda, że nada się idealnie, więc nieco zmodyfikuję podejście. Tym bardziej, że będzie łatwa możliwość zrobienia samodzielnych, cyklicznych zapytań i mierzenia czasu propagacji.

UPDATE 2 Wygląda, że RIPE Atlas probe nie potrafi zwrócić pełnego wyniku resolvowania domeny (tu: rekordów A) z danej sondy, wykonanego z danej sondy na konkretnym serwerze DNS. Będę jeszcze badał temat czy nie można jakoś tego obejść, ale w API nie znalazłem. Dobrzy ludzie też nie, więc to nie moja ślepota.

UPDATE 3 Jednak zwraca, choć w mniej oczywisty sposób. Wyjaśnienie w kolejnym wpisie.

[1] Akurat ta domena nie była jeszcze blokowana na hole.cert.pl, została zgłoszona jako phishing i… nadal jej nie widzę w blokowanych. Zdarza się.

[2] Tak pewnie myśli każdy z niezerowym pojęciem o komputerach i bezpieczeństwie IT, prawda?

[3] Tylko co mi po nich, jeśli wtedy jest to IP routera, ew. ISP stacjonarnego?

[4] Nawet robiłem jakiś benchmark, ale próbka zdecydowanie za mała, żeby wyciągać wiążące wnioski. Nie było źle.

***** ****

W tytule nie ma błędu. Nie chodzi o popularne ostatnio osiem gwiazdek czyli ***** ***. Choć nawiązanie nie jest wcale przypadkowe. Będzie bowiem o polityce i sytuacji w Polsce.

Protesty

Wyrok Trybunału Konstytucyjnego doprowadził do protestów inicjowanych głównie przez Ogólnopolski Strajk Kobiet. Tak, Strajk Kobiet to nazwa ruchu, nie sam strajk. Niezbyt fortunna nazwa, ale nie o nazwę chodzi. Przypomnijmy, chodzi o dalsze zaostrzenie polityki aborcyjnej w kraju.

Czas na protesty nie jest dobry z uwagi na pandemię koronawirusa i wysoką liczbę zachorowań. Zupełnie się z tym zgadzam. O ile nie mam danych, czy i na ile protesty zwiększają liczbę zachorowań, to od protestów na pewno liczba zarażonych nie spada.

Rząd zwala winę za wzrost zachorowań na protestujących. Oczywiście bez twardych danych. Wygląda, że to świetna wymówka i próba przeniesienia odpowiedzialności. Za dramatyczną sytuację w kraju, grożący nam brak łóżek w szpitalach, ogólny stan służby zdrowia, gospodarczy chaos. Nie rząd winien, tylko protestujący! Wygodne. Tak wygodne, że gdyby nie było protestów, należałoby je wymyślić.

Tylko przecież protesty nie wzięły się z powietrza. Pandemia i kryzys to nie jest dobry moment na protesty – zgoda. Tylko czy to dobry moment na zmiany prawa dotyczące kontrowersyjnych tematów? Protesty były nawet nie tyle do przewidzenia, co pewne. Bo przecież to nie jest tak, że jak PO PiS dostaje w wyborach 70-80% głosów łącznie, to takie mają poparcie w kraju. Jest jeszcze spora grupa niegłosujących. Z różnych powodów. Należy pamiętać, że niegłosowanie to też forma głosu. A i sam OSK działa od paru lat. Czyli klasyczne odwracanie kota ogonem.

Rząd nie rządzi

rząd nie rządzi
Źródło: https://www.wykop.pl/cdn/c3201142/comment_1604138238DyE9A5j7249yB5G9EFoxtM.jpg

Nie znam oryginalnego źródła (też Wykop?), ktoś wrzucił linka na IRC, ujęło mnie celnością. W zasadzie mógłbym się pod tym podpisać. Dekrety, pokazówki, hasła i wielkie słowa – to wychodzi. Zrywy i akcje, koniecznie z przymiotnikiem narodowy, odmienianemu na wszelkie sposoby. Nawet kwarantanna w ustach rządu jest już narodowa, nie ogólnopolska czy ogólnokrajowa. A długofalowe zarządzanie krajem, by zwykłym ludziom było dobrze. Tak zwyczajnie i po prostu. Hm…

Zatem kto rządzi w kraju? Spotkałem się z bardzo ładnym podsumowaniem, kto obecnie rządzi w kraju, w kontekście pandemii. Nie rząd, nie prezes, nie premier. Rządzi Darwin. W przypadku zachorowania na koronawirusa największe znaczenie dla przeżycia mają bowiem wiek i stan zdrowia. Godziny dla seniorów nie rozwiązują problemu. Appka do monitoringu kontaktów także nie. Więcej tu i tu. Znaczy znowu – działania nieskuteczne, nie poparte danymi.

Jednowymiarowość

Wracając do poparcia dla partii politycznych. W Polsce popularyzowany jest, szczególnie w mediach, jednowymiarowy podział partii. Lewica, centrum, prawica. Sęk w tym, że to zupełnie nie przystaje. Są inne klasyfikatory partii politycznych 8values, Political Compass, Trójkąt Ideologiczny. Więcej tutaj. To nadal są uproszczenia, ale absolutne minimum dla klasyfikacji politycznej to IMO dwa wymiary.

Jeden wymiar jest wygodny. Prosty i zrozumiały dla każdego. My tu, oni tam. A wszystko pomiędzy da się sklasyfikować w zależności od potrzeb albo tu, albo tam. Z jednej strony pozwala PiS uważać się za prawicę. A z drugiej strony łatwo dyskredytować wszystkie partie liberalne światopoglądowo. To przecież lewica, a lewica to komunizm. Tyle, że poza jednowymiarowym podziałem partii – zupełnie nie. No i PiS słabo nadaje się wtedy na partię prawicową.

Pandemia koronawirusa

Na blogu raczej unikam tematów politycznych. Jednak mamy drugą falę zarażeń koronawirusem. Liczby zarażeń i zgonów są dość dramatyczne. W ciągu ostatnich dwóch tygodni chorych na covid-19 w Polsce przybyło tyle, co przez ostatnie dwa kwartały. Liczba zgonów (ogólnie, wszystkie przyczyny) wzrosła w porównaniu z poprzednimi latami o ok. 50%. W szpitalach kończą się miejsca.

Sytuacja gospodarcza też jest zła. Szczególnie w niektórych branżach. Ludzie chcą pracować, w sposób zwiększający ilość kontaktów międzyludzkich, nie dlatego, że taki mają kaprys, tylko dlatego, że muszą, bo nie mają z czego żyć. Rząd nie zapewnia im warunków do zaprzestania pracy. Tymczasem tematy te są przez rząd omijane. Zamiast tego dominują tematy zastępcze i działania pozorowane.

Ja rozumiem, że nas nie stać. Przynajmniej nie na wszystko. Nie na pełen lockdown. Ale można przynajmniej nie dolewać oliwy do ognia w postaci prowokowania protestów.

Nie wyjaśniłem skąd wziął się tytuł. Jeśli ktoś dotarł do tego momentu, pora na wyjaśnienie Znajdziecie ją w tym wpisie.