Tag: linux

Opublikowane w

T(A)ILS czyli jak zachować anonimowość w Internecie.

Dawno temu pisałem o pomyśle na dystrybucję anonimizującą. Miało to działać na zasadzie liveCD uruchamianego – głównie dla wygody – z maszyny wirtualnej, wyposażonego w domyślne ustawienia utrudniające identyfikację użytkownika i domyślnie wysyłającego wszystkie dane WWW za pośrednictwem sieci TOR. Już samo użycie liveCD w znacznym stopniu utrudnia identyfikację – po uruchomieniu gubione są wszelkie informacje zawarte w ciasteczkach, LSO, historii odwiedzanych stron, cache, jak również cechy charakterystyczne systemu/przeglądarki są wspólne dla wszystkich instancji systemów bootowanych z jednego obrazu.

Projekt Anonymix nie wyszedł poza fazę planów (żaden build nie był w pełni działający i nie został opublikowany), ale znalazłem coś, co nie tylko jest praktycznie dokładnym odpowiednikiem tego, co chciałem realizować, ale bardzo ładnie rozwija tę ideę. Mowa o T(A)ILS, czyli The (Amnestic) Incognito Live System.

T(A)ILS to dystrybucja rozpowszechniania w postaci liveCD i liveUSB skonfigurowana tak, by cała komunikacja odbywała się przez sieć TOR i aby nie zostawiać żadnych śladów użycia danego systemu i przeprowadzanych operacji na dyskach (dopóki wyraźnie o to nie poprosimy). Oczywiście w przypadku uruchomienia z poziomu maszyny wirtualnej tak dobrze nie będzie – przykładowo dane mogą zostać – i zapewne zostaną – przekazane do hosta gospodarza i mogą zostać zapisane na dysku np. w pliku swap, ale dokładnie taką samą wadą obarczony był Anonymix. Warto podkreślić, że tak naprawdę nie wpływa to na anonimowość – jeśli chodzi o identyfikację zdalną jest to bez znaczenia. Klasyczne bezpieczeństwo vs. wygoda – bootowanie fizycznej maszyny z liveCD jest mniej wygodne, ale bezpieczniejsze.

Warto zauważyć, że T(A)IlS nie tylko pomaga zachować anonimowość, ale pomaga zabezpieczyć przed przechwyceniem danych na różne sposoby – od zabezpieczenia przed keyloggerami za sprawą wirtualnej klawiatury, przez zapewnia komunikację Jabberem z użyciem OTR i szerokie wsparcie dla GPG. Do tego T(A)ILS wyposażony jest narzędzia do obróbki dźwięku, skanerów obróbki obrazów, wspólnej edycji tekstów i wykonywania tłumaczeń… Wygląda na niezłe zaplecze dla Wikileaks czy Anonimowych.

Projekt wygląda na aktywnie rozwijany, więc nie pozostało mi nic innego, jak definitywne pogrzebanie Anonymiksa, przekazanie pomysłów (o ile już nie są wdrożone; patrząc na listę błędów – większość jest) i ew. pomoc przy rozwoju T(A)IlS. Na tę chwilę dostępna jest wersja 0.6.2 oparta na Debianie Lenny, więc z testem poczekam raczej na coś opartego o Squeeze, bo sporo się pozmieniało.

Opublikowane w

Apt-p2p – ostateczny test

Krótko o apt-p2p

Apt-p2p spodobał mi się od razu, gdy tylko o nim usłyszałem. Jest to bardzo ciekawe podejście, w którym pobieranie pakietów deb odbywa się przy pomocy P2P (protokół bittorrent), zamiast z tradycyjnych centralnych repozytoriów (HTTP, FTP). Centralne repozytoria są wykorzystywane wyłącznie w przypadku, kiedy pakiet nie jest dostępny przez P2P lub nie jest wystarczająco popularny (za mało peerów).

Kiedyś zrobiłem krótki test apt-p2p, ale trudno go nazwać miarodajnym – maszyna była bardzo słaba, demon ma spory apetyt na zasoby i nie udało mi się wtedy zmusić go do działania jako proxy dla innych maszyn, a sam test nie trwał długo. Od tamtej pory minęło trochę czasu. Maszynka robiąca za router została wymieniona na coś bardziej współczesnego, znalazłem sposób na uruchomienie apt-p2p jako lokalnego proxy (brzydki, bo wymaga gmerania w kodzie, ale się da i działa). Program dostał drugą szansę.

Efekty działania

Demon był testowany (czyli po prostu używany) w sumie na trzech maszynach, przez parę tygodni. Pierwsza maszyna, działająca 24/7, w zasadzie base system + parę pakietów, Lenny, publiczne IP, robiła też za proxy dla kolejnej (desktop, Lenny). Apt-p2p w wersji 0.1.5:

Transport

Mirror DownloadsPeer DownloadsPeer Uploads
This Session0.0B0.0B0.0B
Session Ratio0.00%0.00%0.00%
All-Time108MiB32.5MiB50.4MiB
All-Time Ratio76.85%23.15%35.86%

Maszyna druga (mój desktop), Squeeze, za NAT, bez przekierowanych portów. Apt-p2p w wersji 0.1.6:

Transport

Mirror DownloadsPeer DownloadsPeer Uploads
This Session47.4MiB119KiB0.0B
Session Ratio99.75%0.25%0.00%
All-Time1.07GiB340MiB0.0B
All-Time Ratio76.33%23.67%0.00%

Statystyk trzeciej maszyny nie zaprezentuję – napotkałem na dziwny problem z pobieraniem plików, być może mający związek z uruchomieniem tunelu IPv6 (MTU? brak wsparcia dla IPv6 w apt-p2p?) i cache był czyszczony przy okazji prób rozwiązania problemu. Jak patrzyłem wcześniej, to nic specjalnie różniącego się od powyższych nie zauważyłem.

Inne uwagi

Pierwsze, co rzuca się w oczy po zmianie sposobu pobierania, to fakt, że pobieranie jest znacznie wolniejsze, niż normalnie. Widać to szczególnie na szybszych maszynach, z lepszym łączem. Prawda jest taka, że zwykle z tradycyjnych repozytoriów pakiety lecą z pełną prędkością. W przypadku skorzystania z apt-p2p widać przy każdym pliku laga, zapewne chodzi o sprawdzanie, czy peery posiadają dany pakiet. Nie jest to drastyczne dla aktualizacji systemu, ale drażni, jeśli potrzebujemy szybko doinstalować jakiś pakiet.

Jeśli chodzi o pobieranie, to jak widać na tej mizernej próbce, stosunek pakietów pobieranych tradycyjnie do pobieranych przez P2P jest w miarę stały i wynosi około 3 do 1. Całkiem niezły wynik, szczerze mówiąc liczyłem na znacznie mniej pobieranych przez P2P.

Widać też wyraźnie, że przekierowanie portu jest absolutnie niezbędne, jeśli nie chcemy być leecherem. Szczerze mówiąc, liczyłem, że coś tam będzie się wysyłać zza NAT do peerów z publicznym IP, tak jak przy tradycyjnym P2P, ale widocznie implementacja protokołu niestety nie pozwala na to.

Pakiet ma sporo błędów, a autor nie spieszy się z ich usunięciem. Wspomniany wcześniej brak prostego sposobu na uruchomienie apt-p2p jako lokalnego proxy to jeden z przykładów. Do tego dochodzą nieciekawe defaulty związane z miejscem zajmowanym przez logi czy problemy z działaniem przy zmianie IP lub utracie łączności z Internetem.

Na szybką poprawę błędu związanego z możliwym DDoSem przez klientów P2P też pewnie nie ma co liczyć… Nawet nie zgłaszałem tego, bo na inne błędy zero reakcji autora. Taki brak odpowiedzi jest okrutnie demotywujący, fajnie jest usłyszeć choćby, że będzie poprawione w następnej wersji, albo że nie uważa tego za (poważny) błąd.

Ewidentnie brakuje silnego community wokół projektu, najlepiej ze znajomością Pythona (przyznaję, próbowałem nieco z powyższych poprawić przez dodanie opcji, ale prawda jest taka, że ciężko i długo robi się coś w języku, którego się nie zna).

Zapewne wszystko wiąże się z tym, że apt-p2p jest mało popularny. Widać to choćby na kanale IRC poświęconym programowi. Zapewne prędkość pobierania byłaby wyższa, gdyby peerów było więcej, pewnie udałoby się poprawić część błędów, a autor miałby większą motywację do pracy widząc, że program jest popularny.

Podsumowanie

Uważam, że w tej chwili apt-p2p jest mocno zapuszczony, słabo przetestowany i IMHO nadaje się wyłącznie dla geeków. Jeśli są chętni (najlepiej ze znajomością Pythona) do zabawy z tym programem, to dajcie znać. Jest dobry moment na popularyzację tego rozwiązania, przy okazji pewnie dałoby się odciążyć nieco mirrory przy wydaniu Squeeze’ego (i zapewnić szybszy upgrade do nowego systemu – tak przynajmniej twierdzono w swoim czasie w przypadku Ubuntu). Jeśli chętnych brak, to nie pozostaje nic innego, jak wyłączyć apt-p2p i znowu poczekać parę lat… Może coś się zmieni.