Automatyczne pobieranie kontaktu abuse dla domeny lub adresu IP

Zawsze miałem problem z szukaniem właściwego kontaktu abuse. No może problem to za dużo powiedziane, ale szukanie ręcznie, w hurtowych ilościach to nie jest nic ciekawego. Poza tym, jeśli chcemy zgłaszać automatycznie, to szukanie ręcznie odpada. A w danych whois były cuda, więc parsowanie tego byłoby wyzwaniem… Stosunkowo niedawno RIPE zrobiło jako taki porządek i pojawiły się pola abuse-c. Jednak już wcześniej znalazłem abusix i ich projekt Abuse Contact DB. Pozwala na wygodne odpytywanie o kontakty abuse przy pomocy DNS, więc szybko, prosto i wygodnie.

Trochę, żeby ułatwić życie kolegom, a trochę, żeby automatycznie zgłaszać nadużycia (np. próby włamań po SSH) ze swoich hostów, popełniłem funkcję w Perlu[1], która zwraca pierwszy email z listy, na podstawie ww. bazy. W międzyczasie zająłem się czym innym, znalazłem serwis, który rozwiązał temat automatycznego raportowania prób włamania. Temat więc trochę umarł. Przynajmniej do wczoraj/przedwczoraj, kiedy znalazłem ten wpis i dowiedziałem się, że najprawdopodobniej nikt nie powiadomił firm hostujących. Plus zwykła ciekawość: a gdzie te skompromitowane hosty leżą? Z potrzeby chwili i własnej ciekawości skleciłem skrypt, który bierze domenę (czyli adres strony), sprawdza jego IP (dokładniej: rekord A) i ustala stosowny adres email do kontaktu z abuse.

Wynik działania dla domen .pl jest tu, a wynik działania dla całej listy tu. Skrypt jest zdecydowanie do poprawienia i rozwoju. W tej chwili nie zwraca nic przy braku kompletu danych, czyli brak obsługi błędów, jest wolny, bo działa sekwencyjnie, nie jest to czysty Perl, nie obsługuje IP (ani IPv6 czyli rekordów AAAA), grupowania domen/IP po kontakcie abuse (żeby nie słać wielu maili na ten sam adres) i wysyłki maili, ale leci na GitHuba. W ramach motywatora. 😉 Może kiedyś przyda się komuś, kto znajdzie jakiś malware…

TIL: istnieje oficjalne narzędzie w Pythonie, obsługujące bazę danych abuse; działa zarówno dla IPv4 jak i IPv6 (ale nie obsługuje domen). Generalnie robi to, co moja pierwotna funkcja w Perlu, tylko trochę lepiej. Mam wrażenie, że jak wtedy patrzyłem na tę stronę, to go nie było…

PS Z różnych źródeł wiem, że większe polskie hostingi są już powiadomione, nie ma potrzeby wysyłania maili. 😉 Warto natomiast zobaczyć, czy nie ma na liście strony własnej/znajomych. Problem leży tak naprawdę po stronie użytkownika hostingu i  jego niezaktualizowanej aplikacji, więc tylko on może go tak naprawdę rozwiązać.

[1] Teraz widzę, że funkcja nie jest w czystym Perlu, tylko wywołuje zewnętrzny program host, poprawię wkrótce.

Panoptykon narzeka na ministerstwa i blokowanie Tora

Fundacja Panoptykon po raz kolejny narzeka na blokowanie przez ministerstwa IP, na którym mają uruchomiony węzeł Tor (relay-node). Sytuacja skłoniła mnie do wpisu, bo mam wrażenie, że zachodzi grube niezrozumienie tematu. Z obu stron…

Logo projektu Tor

Źródło: https://media.torproject.org/image/official-images/2011-tor-logo-flat.svg

 

Czy warto blokować ruch z sieci Tor?

To zależy. Ruch z sieci Tor pozwala na łatwe uzyskanie stosunkowo wysokiej anonimowości w sieci. Z jednej strony jest to wykorzystywane do anonimowej komunikacji przez zwykłych ludzi, z drugiej jest wykorzystywane do nadużyć i wandalizmu. Ze znanych serwisów wymienionych w FAQ – Wikipedia blokuje edycję artykułów z sieci Tor, podobnie Slashdot. Oczywiście takich serwisów jest o wiele więcej. Po prostu stosunek sygnał/szum jest w przypadku sieci Tor wyjątkowo niski.

Są też inne, poważniejsze powody do blokowania. O ile sieć Tor ma raczej słabą przepustowość i nie nadaje się do ataków wolumetrycznych, to zdecydowanie ułatwia łatwe, anonimowe ataki na aplikację, SQLi itp. Czyli raj dla script kiddies. I dokładnie taki jest oficjalny powód podany przez rzecznika ABW cytowany na Niebezpieczniku.

Jak blokować ruch z sieci Tor?

Autorzy projektu Tor podkreślają, że wezły sieci Tor mają indywidualne polityki, ale.. Patrząc z punktu widzenia administratora serwisu docelowego i ekonomii działania: sieć Tor to jakieś ułamki promila ruchu, w dodatku często ruchu niepożądanego. Jeśli ktoś zdecyduje się już blokować ruch z sieci Tor, to raczej nie będzie bawił się w polityki poszczególnych węzłów, tylko zablokuje wszystkie. Czy to na poszczególnych maszynach, czy to na centralnym firewallu, czy wręcz null-route’ując na routerach ruch kierowany do węzłów Tor (co uniemożliwi komunikację TCP). Ostatnia metoda jest i prosta w implementacji, i prosta w utrzymaniu (centralne miejsce do zarządzania), i wydajna.

Z których węzłów ruch blokować?

Tu jest pies pogrzebany. Fundacja Panoptykon nie prowadzi exit node, czyli nie przekazuje ruchu z sieci Tor do „normalnego internetu”. Niestety, oficjalne narzędzia udostępniane przez projekt Tor IMO nie są zbyt przyjazne administratorom (szczególnie tym, którzy są mniej świadomi zasad działania Tora lub którzy nie mają czasu). Blokowanie wszystkich węzłów Tora widziałem spotkałem, zarówno jako użytkownik końcowy (tak, relay node w domu, ruch z normalnego IP i komunikat o niewpuszczaniu z sieci Tor w serwisie), jak i administrator. Przede wszystkim brakuje oficjalnej listy węzłów wyjściowych łatwej do przetwarzania, czyli zawierającej same IP. Przypominam, że pisałem we wpisie o blokowaniu węzłów Tor, że udostępniam taką listę. Tylko exit nodes, tylko adresy IP.

Podsumowując, obie strony są winne:

Dziwią mnie żale ze strony Panoptykonu, gdy sytuacja jest typowa i opisana w FAQ Tora:

You might also find that your Tor relay’s IP is blocked from accessing some Internet sites/services. This might happen regardless of your exit policy, because some groups don’t seem to know or care that Tor has exit policies. (If you have a spare IP not used for other activities, you might consider running your Tor relay on it.)

Jak widać, projekt Tor zaleca prowadzenie węzłów na oddzielnych IP, nieużywanych do innych usług. Tak, wiem, sekcja dotyczy węzłów wyjściowych, ale idę o zakład, że pomysłodawca/admin w Panoptykonie nie czytał. Poza tym, zdrowy rozsądek zaleca analizę możliwych konsekwencji przed uruchomieniem usługi i stosowanie oddzielnych IP w tym przypadku.

Dziwi mnie też implementacja blokowania Tora na rządowych serwerach, wskazująca na niezrozumienie tematu. Oczywiście nie mam złudzeń co do korzystania przez nich np. z mojej listy (sam bym tego na ich miejscu nie zrobił), ale samodzielna implementacja to nie rocket science… Plus, niezrozumienie tematu może prowadzić do fałszywego poczucia bezpieczeństwa – tak naprawdę nie sposób zablokować 100% ruchu z sieci Tor, przynajmniej nie w oparciu o adresy IP.

Wybór kraju w sieci Tor

Dawno nie było notki. W sumie to chyba jeszcze nie było tak długiej przerwy między wpisami. Nie dlatego, że nic się nie dzieje, bo się dzieje aż za dużo, ale po pierwsze jakaś blokada przed jakimkolwiek pisaniem (nie tylko na blogu), po drugie, jakiś taki wypompowany z pracy przychodzę, że mi się nie chce już pisać, nawet jak są ciekawe tematy. No to może na przełamanie o wyborze kraju podczas korzystania z sieci Tor…

Logo Tor

Źródło: https://media.torproject.org/image/official-images/2011-tor-logo-flat.svg

Ostatnio jeden z czytelników przysłał maila z pytaniem: czy jest możliwość zmodyfikowania TOR-a tak by zawsze przydzielał polski adres IP? Już zacząłem odpisywać, że byłoby to bez sensu, bo przecież wybór exit node tylko z jednego kraju znacznie zmniejsza poziom anonimowości (nie rozwijając: i łatwiej podsłuchać, i łatwiej namierzyć korzystającego), ale… coś mnie tknęło i zacząłem drążyć temat. Bo patrząc na to z drugiej strony, do pewnych usług dostęp może być tylko z pewnych lokalizacji geograficznych, więc funkcjonalność w postaci możliwości wyboru kraju w sieci Tor miałaby sens.

Podrążyłem nieco temat i – ku memu niewielkiemu zdziwieniu – okazuje się, że można wybrać kraj.  Oznacza to, że można na przykład użyć sieci Tor do obejścia blokady regionalnej. Co lepsze, można wybrać zarówno konkretny exit node, z którego chcemy korzystać, jak i sam kraj. W obu przypadkach może to być zbiór, nie pojedyncza wartość.

Wybór konkretnego exit node wygląda następująco:

ExitNodes server1, server2, server3
StrictExitNodes 1

Natomiast wybór kraju (lub krajów) w sieci Tor:

ExitNodes {pl}, {de}
StrictNodes 1

Za każdym razem zmiany należy wprowadzić w pliku torrc (pod Debian/Ubuntu: /etc/tor/torrc) i przeładować konfigurację demona Tor. Podobno działa, ale nie testowałem, bo wykorzystując dystrybucję TAILS nie udało się wyedytować konfiga i uruchomić ponownie Tora. Nie drążyłem specjalnie, bo nie zależało mi i nie mam powodu nie wierzyć dokumentacji.

Źródła, czyli więcej informacji, w tym lista kodów krajów:

  1. wybór serwera w sieci Tor [en]
  2. wybór kraju w sieci Tor, lista kodówkrajów [en]