Blokada exit nodes Tora

Dawno temu pisałem o walce z Tor. Odsyłałem tam do strony, na której można sprawdzić, czy IP jest węzłem wyjściowym Tora, jest też stronka z listą węzłów. Niestety, stronka popełnia częsty błąd i wrzuca wszystkie węzły do jednego wora, zarówno węzły wyjściowe (exit node) jaki pośredniczące (relay node). Niestety, błąd ten później pokutuje, bo taki admin, który chce wyciąć exit nodes bierze, nie patrzy, nie rozumie i… wycina np. moje domowe IP, choć z Tora się do jego serwera nie łączę, tylko dorzucam parę groszy do projektu przerzucając czyjś ruch.

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

Ponieważ potrzebowałem (no dobrze, ja jak ja…) listę węzłów wyjściowych na niezupełnie swoje potrzeby, zrobiłem własną listę. Tylko IP i tylko węzły wyjściowe. Idealne do automatycznego przetwarzania.

Dane brane są z z oficjalnej strony projektu Tor ( https://check.torproject.org/exit-addresses). Aktualizacja odbywa się raz na godzinę o pełnej godzinie (nie ma sensu pytać częściej). Jakby było zainteresowanie i potrzeba, to mogę zwiększyć częstotliwość. Mi wystarcza.

Plik dostępny jest po HTTP i HTTPS pod tym adresem: Tor exit node IP list. Udostępniam as is, bez żadnych gwarancji działania, dostępności, kompletności czy poprawności danych czy braku złośliwych danych. Jak widać wisi to na darmowej domenie, co może mieć dotyczące zawartości. You get what you pay for. 😉

Zresztą ogólnie korzystanie z tego typu automatycznych źródeł bez jakiejś weryfikacji uważam za nierozsądne.

UPDATE: Metoda nie jest doskonała. O tym, że część exit nodes może nie być widocznych przeczytasz tutaj.

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?

EncFS – kolejne narzędzie do szyfrowania upada

Dawno temu zachwycałem się EncFS[1]. Obsługiwało AES, pozwalało szyfrować pliki, nie partycje i pozwalało trzymać je na zwykłym systemie plików. Tak naprawdę szyfrowany był katalog. Jakiś czas temu upadł Truecrypt, który – zdaniem twórców – okazał się nie tak bezpieczny, jak postrzegali go ludzie. Teraz kolej na EncFS.

Wczoraj, podczas aktualizacji systemu[2], dostałem w twarz dialogboksem o następującej treści:

Encfs security informationAccording to a security audit by Taylor Hornby (Defuse Security), the current implementation of Encfs is vulnerable or potentially vulnerable to multiple types of attacks. For example,an attacker with read/write access to encrypted data might lower the decryption complexity for subsequently encrypted data without this being noticed by a legitimate user, or might usetiming analysis to deduce information.Until these issues are resolved, encfs should not be considered a safe home for sensitive data in scenarios where such attacks are possible.

Pięknie, prawda? Szczególnie, że EncFS byłby świetnym rozwiązaniem do szyfrowania plików w chmurze – EncFS dla WebDAV czy Dropbox były proste w założeniu i wygodne w użytkowaniu[3]

Wygląda, że pomału można żegnać się z EncFS. A podobnych alternatyw jakoś nie widać na horyzoncie.

[1] Strona projektu zwraca 404. Przypadek? W każdym razie nie linkuję, łatwe do wyszukania…

[2] Debian unstable. Akurat tam nie używam encfs, ale instaluję wszędzie. Planowałem do chmury.

[3] Ładne ilustrowane howto dla EncFS w chmurze.

Nowe biletomaty w Poznaniu

Jak pisałem poprzednio, nowe biletomaty w Poznaniu zaczęły pracę od awarii. Potem zaczęły działać. Co prawda, obserwując reakcje korzystający, chyba nie były zbyt intuicyjne i/lub responsywne, no widziałem szukanie, klikanie w kilku miejscach, klikanie po klika razy tego samego (nim załapało?), ale przyszedł taki dzień, gdy chciałem kupić bilet. Padło na dobowy, bo planowałem w najbliższym czasie kilka przejazdów.

Podchodzę do biletomatu (Kórnicka) i widzę:

Biletomat Poznań wyjmij kartę

Źródło: fot. własna

Zgodnie z tym, co widać na powyższym zdjęciu, żadnej karty nie ma. Klikanie na ekranie również nie przynosiło rezultatów. Czyli biletu kupić się nie da, za to w pojeździe możemy się spotkać z tekstem jak na wiacie na przystanku tuż obok

Bileciki do kontroli grafitti

Źródło: fot. własna

Ostatnio widzę na mieście trochę billboardów Łódź vs Poznań. A to festiwal filmowy na Malcie, a to Szkoła Filmowa w Łodzi będących częścią kampanii ocieplającej wizerunek Łodzi (paywalled, ale przykład widać). Tak sobie myślę, że nie ma się co wysilać. Wystarczyłyby hasła u nas stać cię na bilet oraz u nas biletomaty działają.

Miasto know how, takie piękne…

Plnog 13

Dziś wróciłem z trzynastej edycji PLNOG. Znacznie lepsze wrażenia, niż po edycji 11. Krótko i subiektywnie o wykładach, na których byłem.

Peering vs Tranzyt prowadzony przez Grzegorza Janoszkę z Booking.com. Zaskoczenia nie było; w skrócie: peering oznacza mniejsze opóźnienia, szybsze transfery i mniejsze odchylenia czasu transferu. Czyli – patrząc z punktu widzenia lepiej róbmy sieć/usługę – warto. Niestety, podobno nie przełożyło się to w żaden sposób na wyniki sprzedaży. Duży szacunek za kulturę pomiarów i weryfikację tez w praktyce, mimo trudnych warunków pomiaru (każdy okres jest inny, wzrost ruchu w czasie, zmienne środowisko).

James Kretchmar z Akamai mówił o obsłudze największych wydarzeń w Internecie. Czyli np. transmisje video z MŚ w piłce nożnej. Bez wielkich zaskoczeń, z grubsza tak to sobie wyobrażałem. Ciekawe wyzwania i mechanizmy przy tego typu skali. Największe wrażenie zrobiła właśnie skala i poziom poukładania.

O systemie ochrony przed atakami DDOS Wanguard mówił Piotr Okupski. Wykład ciekawy, praktyczny, przekonujący. Sporo namiarów i ciekawostek nt. wpływu optymalizacji systemu Linux i wyboru kart sieciowych na wydajność. Ogólnie sporo o wydajności, zwł. w kontekście przetwarzania informacji o ruchu sieciowym w większej skali live. Zdecydowanie będę musiał zgłębić temat. W tej chwili mam to rozwiązane nieco inaczej (i też działa i wystarcza), ale warto znać alternatywy.

Czy bezpłatne WiFi może być opłacalne? Chyba najbardziej marketingowy wykład, na jaki trafiłem. Paradoksalnie, cieszę się, że byłem, choć ze względu na ochronę prywatności. Z punktu widzenia użytkownika końcowego: nie ma darmowych obiadów. Zalogujesz się do darmowego WiFi przy pomocy konta FB/maila/numeru telefonów, to spodziewaj się reklam na wallu, spamu, SMSów. Darmowe WiFi w galerii[1]? Pomiar, gdzie chodzisz (dokładność do kilku m), ukierunkowane reklamy przy przejściu obok danego sklepu, na wallu itd. I wszechobecne parcie w kierunku big data. Trochę ciary, mocne skojarzenia z Rok 1984 i Wielkim Bratem.

O narzędziach open source w służbie ISP mówili ludzie z FiberRing. Wyniosłem głównie da się połączone z pewne rzeczy warto rozwijać samemu (bo nie ma alternatyw ;-)) i parę nazw narzędzi, którym chcę się bardziej przyjrzeć.

Mechanizmy ochrony anty-DDoS w Telekomunikacji Polskiej/Orange – taki był tytuł wykładu Andrzeja Karpińskiego. Fajny, poukładany, przemyślany wykład w formie, która bardzo mi się podobała, bo łączyła teorię z praktyką. Czyli z jednej strony co należy robić, a z drugiej jak my to robimy. Myślę, że dobry instruktaż, albo przynajmniej przypomnienie. Mam dość niewesołe przemyślenia w temacie security, niestety. Mianowicie: dużym jest łatwiej, a bezpieczeństwo coraz mniej jest sprawą community sieciowego, a coraz bardziej produktem. Dużą zmianę jakościową mogłaby przynieść dopiero zmiana mentalności end userów, ale na to się nie zanosi. Nawiasem, nie zdziwiłbym się, gdyby wykład okazał się też owocny handlowo (bo o produktach TP/Orange w tym zakresie też było).

Pierwszy dzień konferencji zakończyłem spotkaniem SP Security Community Working Group. Ustalenia są w skrócie takie, że nadal to będzie działać, ma być bardziej otwarte na nowych ludzi i bardziej lokalne. I chyba dobrze, bo IMO do tej pory formuła nie do końca się sprawdzała.

Dzień drugi zaczął Artur Pająk z Huawei wykładem o iSCSI i FCoE. Dobry przegląd technologii. FCoE wygląda jakby lepie w dłuższej perspektywie, ale obecnie barierą może być brak „wspólnego języka” między vendorami.

Mateusz Viste z Border 6 mówił o optymalizacji BGP w czasie rzeczywistym. Dobrze poprowadzony wykład typu co i jak można zrobić. Jeśli się trochę pomyśli i porzeźbi, oczywiście. I napisze trochę swojego kodu[2]. A firma dla tych, którym się nie chce/nie potrafią daje gotowca. Wyniki ciekawe, pewnie parę lat temu byłbym poważnie zainteresowany produktem. Teraz trochę się zmieniła pozycja – ceny hurtowego dostępu do internetu spadły, pojawiły się punkty wymiany ruchu, które też znacznie pomagają (patrz wykład z pierwszego akapitu), a dodatkowo capacity daje pewną odporność na DDoSy (przynajmniej teoretycznie). Może po prostu nie jestem odbiorcą docelowym w tym momencie, tzn. nie mam takich potrzeb.

Ostatni wykład na którym byłem prowadził Adam Obszyński z Infoblox. Zupełnie niemarketingowy wykład o DNSSEC, czy warto, czemu warto, czemu nie warto i co to daje. Ogólnie IMO trochę poprawia bezpieczeństwo, zwł. w przypadku przejęcia ruchu (MITM), ale problemu nie rozwiązuje, w szczególności nie rozwiązuje go dla użytkownika końcowego. Bo ten nadal jest narażony na podmianę adresów serwerów DNS na swoim komputerze/routerze (i wtedy DNSSEC nic nie daje), ruch do DNS nadal jest widoczny (DNSSEC to podpisywanie, nie szyfrowanie) i ogólnie nadal musi ufać swojemu ISP[3]. Widać, że nie do końca się standard przyjął (w Polsce jest naprawdę słabo), wiele ostatnich artykułów jest z okolic 2010-2012, ale przyznam, że ja zostałem przekonany do włączenia (w tym: dla moich użytkowników, aktualnie testuję na sobie). Będzie odrobinę bezpieczniej, a włączenie jest trywialne.

Bo że z bezpieczeństwem DNS nie jest za dobrze, to wiadomo – niedawno dość modny (z braku lepszego określenia zostawię to słowo) stał się DNSCrypt, który robi zupełnie co innego, ale… ma inne wady, a jego uruchomienie to na ten moment porażająca rzeźba, niestety.

W każdym razie zupełnie prywatnie wykład inspirujący i planuję wkrótce wpis(y?) o DNSSEC.

[1] Obawiam się, że do samego pomiaru położenia wystarczy włączone WiFi w telefonie, nie trzeba podłączać się do sieci… A potem, kiedyś, jak już się podłączy na podstawie MAC karty sparuje się urządzenie z użytkownikiem i dołoży parę puzzli do układanki.

[2] Tak, kolejny wykład o tym, że DIY w sieciach ma rację bytu.

[3] I swojemu ISP od DNS też, jeśli przypadkiem nie jest to ten sam byt.