Własna strona w sieci Tor

Za sprawą normalnych tradycyjnych stron w sieci Tor zrobiło się ostatnio głośno z powodu Facebooka. Nie dość, że Facebook wystawił stronę oficjalnie do sieci Tor pod adresem .onion, to adres był ciekawy, a całość jest dostępna po HTTPS, czyli w wersji szyfrowanej[1]. Mniejsza o powody, dla których to uczynili. Wydaje się, że nie tyle chodziło im o anonimowość użytkowników (nie miejcie złudzeń), co o ich prywatność i bezpieczeństwo (ukrycie lokalizacji). Plus przy okazji rozwiązali sobie problem false positives przy wykrywaniu włamań, które mieli przy użytkownikach korzystających z tradycyjnych exit node[2]. Będzie zatem o własnej stronie w sieci Tor.

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

Tak czy inaczej, wygląda, że Tor został dostrzeżony przez dużych w z właściwej perspektywy, czyli po prostu jako medium transmisji, a nie odrębna sieć, używana przez złoczyńców[3]. Myślę, że można spodziewać się kolejnych naśladowców.

Warto zauważyć, że to co zrobił Facebook to nie jest typowy hidden service w sieci Tor. W typowym chodzi o ukrycie tożsamości właściciela, miejsca hostowania itp. Czyli masa pracy poświęcona uszczelnianiu systemu i serwera WWW, która nie jest przedmiotem tego wpisu. Na stronie projektu Tor też się tym nie zajmują, ale zainteresowani znajdą tam ogólne wskazówki. Tu przeciwnie – wszystko jest dostępne, a tożsamość jest potwierdzona certyfikatem SSL, czyli wersja znacznie łatwiejsza w wykonaniu.

I właśnie takim przypadkiem zajmę się w tym wpisie. Całość opisana jest dokładnie na stronie projektu Tor. Widzę jednak, że pojawiają się pytania jak to zrobić, więc zamieszczę wersję skróconą i uproszczoną. Tak naprawdę całość sprowadza się do dwóch linii w pliku konfiguracyjnym. Zakładam, że Tor jest już skonfigurowany jako relay node lub bridge node. I nawet nie do napisania, tylko do odhashowania/edycji.

Przede wszystkim w pliku konfiguracyjnym[4] szukamy sekcji dotyczącej hidden services, zaczynającej się od linii:

############### This section is just for location-hidden services ###

Następnie odhashowujemy/edytujemy dwie linie:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 IP_SERWERA_WWW:80

Pierwsza musi wskazywać na katalog, który musi mieć prawa odczytu i zapisu dla użytkownika na którym działa demon Tor. W Debianie wystarczy odhashować.

Druga to wskazanie który port chcemy przekierowywać i na jaki adres oraz port. IPv4 działa na pewno, IPv6 nie udało mi się skłonić do działania. Jedyna zmiana, czy też wymóg konfiguracji po stronie serwera WWW, jest taki, że musi on pozwalać na dostęp do zasobów po IP, bez podania domeny (vhosta)[5].

Następnie należy zrestartować demona Tor i… gotowe. Pozostało jeszcze tylko sprawdzić, jaki adres ma nasz hidden service:

cat /var/lib/tor/hidden_service/hostname

Potem można już tylko zweryfikować działania serwisu za pośrednictwem adresu .onion. Jeśli nie mamy pod ręką normalnego dostępu do Tora, można posiłkować się bramką Tor2web.

[1] I całe szczęście, bo przypominam, że Tor nie szyfruje użycie Tora nie oznacza automatycznie szyfrowania danych. Co więcej, każdy węzeł, ma możliwość przechwycenia całej (co prawda zaszyfrowanej) transmisji. A exit node, jest w stanie podsłuchać nieszyfrowaną transmisję do końcowego hosta.

[2] Więcej w tym wpisie (ANG).

[3] Nie ukrywajmy, typowy użytkownik Tora kojarzył się do tej pory z nielegalnymi działaniami.

[4] W Debianie jest to /etc/tor/torrc, pewnie w Ubuntu i innych pochodnych jest analogicznie.

[5] Tu uwaga dla chcących stawiać bramki hidden service – z punktu widzenia zewnętrznego serwisu (i tylko jego, i tylko w przypadku połączeń poprzez adres .onion) mój klient Tor IP jest teraz exit node! W przypadku nadużyć za pośrednictwem sieci Tor i adresu .onion może się to skończyć wizytą policji. W przypadku serwisów, których nie jesteśmy właścicielami bezwzględnie należy mieć zgodę właściciela serwisu.

Przyspieszanie łącza internetowego

Wpis, który przeleżał jako szkic ponad rok. I bardziej go już nie skończę, więc publikuję, jak jest. Miały być testy i dokładne konfiguracje, ale z braku czasu będzie czysta teoria. Tak czy inaczej myślę, że przyda się ludziom z wolnymi łączami lub korzystającym z WWW (i nie tylko…), a chcącym zminimalizować ilość przesłanych danych do urządzenia końcowego. Do rzeczy.

Na podstawie doświadczeń z Aero2, czyli łącza zarówno wolnego (niska przepływność) jak i zlagowanego (duże opóźnienia pakietów), postanowiłem popełnić krótki poradnik, jak przyspieszyć działanie sieci na wolnym łączu internetowym. Zwykle zakładam w tym poradniku, że użytkownik korzysta z Linuksa, ale nie zawsze i część sposobów przyda się niezależnie od systemu.

Krok pierwszy – przyspieszanie zapytań DNS

Ważna sprawa, bo serwery DNS odpytywane są coraz częściej. Otwarcie pojedynczej strony internetowej to w dzisiejszych czasach często kilkanaście, a nawet kilkadziesiąt zapytań do serwerów DNS. W przypadku zlagowanego połączenia do każdego zapytania dochodzi opóźnienie łącza. Można sobie pomóc poprzez wykorzystanie lokalnego cache DNS. Z prostych w konfiguracji polecam opisany kiedyś dnsmasq lub lekki i wydajny unbound. Cache DNS działa dla całego systemu, nie tylko dla stron WWW, ale w ich przypadku różnica powinna być najbardziej widoczna. Dodatkowa zaleta to uniezależnienie się od potencjalnych problemów z serwerami DNS naszego dostawcy łącza.

Krok drugi – kompresja danych

Mechanizm kompresji danych na wolnym odcinku nie jest niczym nowym. Od dawna z powodzeniem stosuje go Opera w swojej funkcji turbo. Pierwsza obróbka strony odbywa się na ich serwerach, które dysponują szybkimi łączami. Dodatkowo może się odbywać redukcja zbędnych elementów. Zaletą rozwiązania jest łatwość uruchomienia – wystarczy kliknąć przycisk w Operze. Wadą rozwiązania jest to, że wymaga korzystania z Opery i działa tylko dla stron WWW.

Kompresja danych – DIY

ziproxy

Jeśli mamy dostęp do serwera (może być VPS) z Linuksem, możemy w prosty sposób stworzyć podobne rozwiązanie samodzielnie, korzystają z programu ziproxy. Instalujemy je na serwerze, konfigurujemy, jak bardzo mają być redukowane grafiki (60-70% wygląda znośnie), ustawiamy adres IP i port serwera jako proxy w przeglądarce i.. tyle. Od tej pory przez wolne łącze przesyłane są zredukowane (stratnie, zatem gorzej wyglądające) obrazy. Reszta danych jest przesyłana w postaci skompresowanej.

Zaleta jest taka, że działa z każdą przeglądarką i – dla paranoików – że nasze dane nie błądzą po serwerach Opery.

Wady: działa tylko dla WWW, stopień redukcji obrazów ustala się raz, nie ma możliwości dynamicznej zmiany jakości (np. obejrzenie wybranych obrazów w lepszej jakości).

sshuttle

Jeśli mamy dostęp do serwera z Linuksem i dodatkowo ma on zainstalowanego Pythona, to możemy skorzystać z VPN over SSH, czyli shuttle. Rozwiązanie powstało jako namiastka VPN i miało pierwotnie bardziej zapewniać bezpieczeństwo transmisji (szyfrowanie) w przypadku otwartych hotspotów. Można je jednak skonfigurować tak, aby ruch był kompresowany (wykorzystanie kompresji SSH).

Zaletą jest to, że działa dla całego ruchu (TCP), nie tylko dla WWW. Można określić, do których sieci ruch ma być obsługiwany przez to rozwiązanie.

Wada: działa tylko dla TCP (oraz zapytań DNS), wymaga zainstalowanego Pythona na maszynie pełniącej rolę serwera.

ssh + socks proxy

Jeśli nie chcemy instalować dodatkowego oprogramowania, a mamy dostęp do serwera z Linuksem, możemy w prosty sposób wykorzystać tunelowanie SSH oraz – podobnie jak w poprzednim przypadku – wykorzystać kompresję oferowaną przez SSH. W tym celu ustawiamy socks proxy w przeglądarce na localhost oraz port 9000, oraz uruchamiamy ssh -CND 9000 user@serwer. Od tej pory ruch WWW tunelowany jest przez SSH do serwera. Jeśli zależy nam nie tylko na wydajności, ale i na prywatności, warto sprawdzić ustawienia przeglądarki dotyczące przesyłania zapytań DNS przez proxy.

Zaleta: łatwość uruchomienia (na systemach *nix).

Wady: działa tylko dla ruchu WWW (lub jawnie przetunelowanego z innych aplikacji), wymaga przeglądarki WWW ze wsparciem dla socks proxy (praktycznie każda sensowna ma tę opcję dostępną w ten lub inny sposób).

OpenVPN

Ostatni sposób to wykorzystanie OpenVPN oraz wbudowanej kompresji. Wymaga skonfigurowanego OpenVPN zarówno po stronie klienta jak i serwera.

Zalety: działa dla wszystkich rodzajów ruchu.

Wady: wymaga zainstalowania i skonfigurowania OpenVPN. Dochodzi narzut CPU na szyfrowanie (domyślnie będzie włączone, zwł. u zewnętrznych providerów).

Oczywiście cudów nie ma i ww. sposoby pomogą jedynie dla treści, które przesyłane są jako nieskompresowane i dobrze się kompresują. Nie ma co liczyć, że filmy na YouTube zaczną działać szybciej. Osobiście idę na łatwiznę i korzystam zwykle z ssh i socks proxy.

Boot once w GRUB

Czasami jest potrzeba, żeby uruchomić maszynę z danym kernelem, ale tylko raz. W przypadku niepowodzenia chcemy mieć uruchamiany z powrotem stary, sprawdzony kernel. Zwykle taka potrzeba pojawia się, gdy testujemy nowy kernel i nie mamy fizycznego (lub zbliżonego) dostępu do maszyny, a np. mamy pod ręką kogoś, kto w razie problemów niekoniecznie pomoże z debugiem, ale chociaż wciśnie reset. Dziś pojawiła się u mnie taka potrzeba, za sprawą dedyka pod Piwika i chęci zmiany kernela z nieco starego z OVH na dystrybucyjny.

Okazało się, że wypadłem z tematu. Ostatni raz miałem potrzebę jednorazowego uruchomienia kernela chyba w okolicach LILO jako używanego bootloadera. Nie pamiętam jak to dokładnie w LILO wyglądało, ale mam wrażenie, że było proste, intuicyjne (w końcu jeden konfig) i – przede wszystkim – dobrze udokumentowane.

Poszukałem chwilę i znalazłem polecenie grub-reboot, któremu jako parametr podaje się numer wpisu w /boot/grub/grub.cfg i które ma powodować jednokrotne uruchomienie kernela o podanym wpisie. Ucieszyłem się, że pomyśleli o mnie i tak prosto. Maszynka niekrytyczna, kernel dystrybucyjny, więc raczej wstanie, wydałem więc stosowne polecenie, następnie reboot i… system wstał! Ze starym kernelem.

Nawet niezbyt się zirytowałem. Po prostu odpaliłem testowego kompa w domu i zacząłem się bawić. Ustawiam numer wpisu, który ma się włączyć, reboot i… to samo. Dłuższa chwila szukania i znalazłem opis na niezawodnym wiki Arch Linux:

This requires GRUB_DEFAULT=saved in /etc/default/grub (and then regenerating grub.cfg) or, in case of hand-made grub.cfg, the line set default=”${saved_entry}”.

Jak na lata doświadczeń przystało, wyboru kernela nie pozostawiam przypadkowi i w moim /etc/default/grub były ustawione na sztywno numery kerneli do uruchomienia. Zmieniam na powyższe na testowej maszynie w domu, grub-reboot potem reboot i… wstał! Z nowym kernelem. Świat wydaje się piękny, więc reboot, by wrócić na stary kernel i… tak dobrze nie ma. Uruchamia się za każdym razem z nowym.

Nawet niezbyt się zirytowałem, po prostu rebootnąłem zdalną maszynkę na nowy kernel. Skoro dystrybucyjny to raczej wstanie. Stosowne zmiany, reboot i… maszynka wstała, z nowym kernelem, wszystko wydaje się działać. Misja zakończona, cel osiągnięty.

I tu byłby koniec wpisu, ale w międzyczasie zacząłem rozmowę na ten temat na kanale IRC #debian (@freenode). Tam dowiedziałem się o /boot/grub/grubenv i o tym, że może (będzie) się tak dziać, jeśli nie jest ustawione prev_saved_entry. I faktycznie, nie było. I dowiedziałem się, że można to ustawić wydając polecenie grub-reboot więcej, niż raz.

Czyli, żeby zrobić boot once dla GRUBa, trzeba kolejno:

  • ustawić GRUB_DEFAULT=saved w /etc/default/grub
  • grub-reboot <wpis, gdzie ma być default>
  • grub-reboot
  • sprawdzić /boot/grub/grubenv na wszelki wypadek
  • reboot

I pomyśleć, że przy LILO była to szybka edycja konfiga plus lilo dla wprowadzenia zmian w życie… Znaczny postęp poczyniliśmy! 😉

Skoro już wpis na tematy linuksowe… Archa nie próbowałem, ale ludzie (w tym jeden DD) chwalą. Bardzo dobra dokumentacja. Poza tym, jest taka inicjatywa jak debianfork.org. I cieszę się, że jest. Bo skoro Debian może mieć więcej niż jedną architekturę, więcej niż jeden kernel (tak kFreeBSD), to czemu nie miałby móc mieć różnych, równorzędnych demonów do startu usług?