Gotowanie żaby

Dziś będzie o gotowaniu żaby, czyli jak my, obywatele, oddajemy bezczynnie coraz więcej swojej wolności państwu. Po małym kawałeczku. Wpis jest zainspirowany dyskusją na kanale IRC o tym, jak to my, społeczeństwo bez protestu przyjmujemy to, co wymyśla rząd AKA miłościwie nam panujący.

Poszło o rządową cenzurę stron przy pomocy DNS. O sprawie pisał DI, pisała też Fundacja Panoptykon. Oczywiście, sprawa nikogo nie dotyczy – mało kogo interesuje hazard przez Internet, poza tym, co to za zabezpieczenie przez blokadę w DNS, skoro można zmienić DNS? No i mamy Tora i VPNy, łatwo można obejść ustawę za parę euro miesięcznie, jak pisałem. Zresztą na innych portalach branżowych również są instrukcje dotyczące czy to zmiany serwerów DNS, czy zdobycia łatwego VPNa. Niby nie ma sprawy.

Tyle, że powstało pozwolenie na pewną czynność i pewien mechanizm. Czynność to blokowanie dostępu do stron WWW czyli informacji na rozkaz państwa. Przy pomocy centralnego rejestru. Oczywiście na razie to tylko hazard i tylko nieskuteczna blokada DNS, ale… jaki problem rozszerzyć za jakiś czas indeks stron zakazanych o strony porno? Porno złe! I nikt nie będzie protestował. Albo krytykujące miłościwie nam panującego prezydenta. Albo równie miłościwie nam panujący rząd? Krytyka zła! I nikt nie będzie protestował.

Na razie mechanizm blokady jest nieskuteczny i prosty do obejścia, więc się godzimy na niego. Ale jaki problem za jakiś czas poprawić go? Omijają kontrolowane przez rząd DNSy? Wymuśmy, by ISP – nieodpłatnie rzecz jasna – przekierowywał każdy ruch DNS na nie. Używają Tora? Wiadomo do czego! Zablokujmy Tora! Nikt nie zaprotestuje. Używają dnscrypt i VPNów? Wiadomo do czego! Zablokujmy! Nie da się w DNSach? To nic, doda się obowiązek utrzymywania blokowania po IP. Nawet prostszy w implementacji… Nikt nie zaprotestuje.

Zwrócono w dyskusji uwagę, że przy ACTA były protesty na ulicach i że ten język rządzący rozumieją. Bo czy ten wpis, czy linkowane wyżej artykuły Panoptykonu czy DI, czy opinie Ministerstwa Cyfryzacji spływają po miłościwie nam panujących jak po kaczce. Teraz nie ma żadnych działań.

Nie chodzi o tę jedną ustawę, oczywiście. Przypominam, że powstaje (albo już powstał) ogólnopolski projekt monitorowania ruchu internetowego. Oczywiście znowu w imię walki z przestępczością i terroryzmem. Potem wystarczy dorzucić, że próby obejścia rządowej blokady są przestępstwem, wytypować korzystających z Tora, VPNów itp. i… z głowy. A wiadomo, że służby muszą mieć sukcesy. I że jak się ma młotek, to wszystko wygląda jak gwóźdź…

Inne, podobne: pamiętacie obowiązek rejestracji kart SIM, wprowadzony w imię walki z terroryzmem? Niektórzy zastanawiali się, co z niezarejestrowanymi. Niektórzy nie wierzyli jak pisałem, że po prostu za jakiś czas każą operatorom zablokować wszystkie niezarejestrowane karty. Że prawo nie może działać wstecz, że umowa, że operator się nie zgodzi. Otóż Plus już zmienił regulaminy:

Klienci zawierający umowę o świadczenie usług telekomunikacyjnych od dnia 25 lipca 2016 r. będą zobowiązani do dokonania rejestracji powyższych danych oraz umożliwienia ich weryfikacji z dokumentem potwierdzającym tożsamość przed zawarciem umowy i rozpoczęciem korzystania z usług.

Abonenci Na Kartę, którzy zawarli umowę o świadczenie usług telekomunikacyjnych przed dniem 25 lipca 2016 r. obowiązani są podać powyższe dane i umożliwić ich weryfikację najpóźniej do dnia 1 lutego 2017 r. Zgodnie z ustawą o działaniach antyterrorystycznych niedokonanie rejestracji powyższych danych będzie skutkowało całkowitym zaprzestaniem świadczenia usług z dniem 2 lutego 2017 r.

Nikt nie protestuje, nikogo to nie dotyczy, jaki problem zarejestrować kartę?

Temperatura wody rośnie, żaba nie reaguje…

Nie zablokujesz Tora…

Krótkie przypomnienie: około pół roku temu pisałem, jak zablokować węzły wyjściowe Tora. Lista węzłów wyjściowych (exit nodes) Tora jest publiczna, więc wygląda, że mamy sielankę.

Logo Tor

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

Tymczasem dziś podczas rozmowy w gronie administratorów padło stwierdzenie od osoby, która badała ruch w sieci Tor, że podczas swoich eksperymentów zarejestrowała ruch z węzłów wyjściowych, których nie było na liście. Metodyka badania prosta jak budowa cepa: wyślij znane żądanie przez Tora do swojego hosta, zapisz IP z którego nadeszło połączenie, porównaj z listą exit nodes.

I wtedy mnie olśniło. Dla pewności zapytałem jeszcze na kanale IRC poświęconym Torowi czy nie ma jakiejś weryfikacji i… jak najbardziej jest to wykonalne. Po prostu jako exit node listowany jest IP, który jest podłączony do sieci Tor. Wystarczy więc, że maszyna ma więcej niż jedno IP lub przekierowuje ruch na inną maszynę (choćby iptables) i… połączenia Tor będą widoczne z nielistowanego adresu. Co więcej, może się on zmieniać w czasie…

Usłyszałem nawet znamienne zdanie na kanale: założę się, że są exit node’y, które po prostu wysyłają ruch przez VPN.  I to by było tyle w temacie prostych, błędnych odpowiedzi na pozornie proste pytania…

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.