Monitoring Tora w konsoli – howto.

Jak wiadomo m.in. z poprzedniego wpisu, prowadzę węzeł Tora. Bez połączeń wychodzących, czyli robię tylko za żuczka dokładającego jeden hop w ścieżce w celu zwiększenia anonimowości korzystających z tego programu. Od pewnego czasu miałem wrażenie, że jedyne, co robi mój Tor, to zajmuje pamięć (ponad 30% na biednym Dockstarze). Nie robiłem żadnych dokładnych statystyk, po prostu obserwowałem ilość ruchu na interfejsach, ale wyglądało, że jest mniej, niż kiedyś.

Postanowiłem sprawdzić, co się dzieje w rzeczywistości. Już kiedyś widziałem, że jest projekt arm czyli anonymizing relay monitor, ale wtedy nie było pakietów w Debianie, więc nie instalowałem, a pozwala on na znacznie więcej, niż tylko obejrzenie ilości ruchu, więc postanowiłem zainstalować arm.

W tej chwili paczka tor-arm jest dostępna w Debianie unstable (na stable instaluje się czysto), więc doinstalowałem ją (wajig install tor-arm). Samo uruchomienie (wpisanie arm) nic nie dało (używa domyślnej konfiguracji), więc po pierwsze, skopiowałem domyślną konfigurację (położenie w Debianie nieco inne niż podawane w manualu):

zcat /usr/share/doc/tor-arm/armrc.sample.gz > .arm/armrc

Nadal nic. Kolejna sprawa, to uruchomienie portu do kontroli w samym Torze, czyli dodanie w configu opcji:

ControlPort 9051

Po ponownym uruchomieniu arm jak najbardziej się połączył, ale ostrzega, że port do kontroli jest otwarty. Co prawda maszynka jest firewallowana, ale wypadałoby dodać hasło do zarządzania. Nie jest to trywialne i znalezienie zajęło mi dłuższą chwilę (chociaż jest w dokumentacji), więc opiszę. Najpierw generujemy hash hasła:

tor --hash-password jakieshaslo 

Otrzymujemy coś w stylu ciągu

16:2CCAAB2DEEB082CD60610B3BE6A0FF2A90EEFC92AD434C9C8CBFA42B0B

Następnie w konfiguracji Tora dodajemy linię

HashedControlPassword 16:2CCAAB2DEEB082CD60610B3BE6A0FF2A90EEFC92AD434C9C8CBFA42B0B

i restartujemy Tora (/etc/init.d/tor restart). Na koniec edytujemy ~.arm/armrc i uzupełniamy linię z startup.controlPassword, by miała postać:

startup.controlPassword jakieshaslo

Po zmianach okazało się, że miałem nosa i faktycznie niewiele się dzieje. Nawet bardzo niewiele. Praktycznie nic. Ponieważ kiedyś ruchu było więcej, postanowiłem sprawdzić, czy winnym nie jest ustawienie węzła jako bridge node. Bingo! Po zmianie od razu jest więcej ruchu. Zatem w chwili obecnej mój konfig Tora wygląda następująco:

ControlPort 9051
RelayBandwidthRate 20 KBytes
RelayBandwidthBurst 30 KBytes
ExitPolicy reject *:* # no exits allowed
ORPort 443
HashedControlPassword 16:2CCAAB2DEEB082CD60610B3BE6A0FF2A90EEFC92AD434C9C8CBFA42B0B

UPDATE: Przy okazji wygląda, że wyłączając tryb bridge node upiekłem dwie pieczenie na jednym ogniu. Po 16 godzinach zużycie pamięci RAM przez Tor wynosi ledwie 9%, zamiast wspomnianych 30%. Czyżby jakiś bug związany z trybem bridge? W każdym razie średni ruch upload i download teraz to po 50 Kbps, zużycie pamięci, które mnie trochę bolało mniejsze. Jednym słowem: lubię to! 😉

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.