Botnet w Torze.

Napisałem dziś na µblogu, że mam dylemat. I podałem tego linka do bloga projektu Tor. Ostatnio zajmowałem się czym innym i zupełnie przegapiłem opisywany gwałtowny wzrost użytkowników Tora. Dziś zagadka została wyjaśniona – winny jest botnet, który korzysta z Tora do zarządzania węzłami (dobre źródło, po polsku i blog ogólnie ciekawy). Mój dylemat polega na tym, że w chwili obecnej 80% węzłów Tora stanowią komputery zombie wykorzystywane do ataków DDoS, wysyłania spamu itp., a ja nie chcę pomagać spamerom/abuserom.

Jasne, wiadome było, że nie tylko do szczytnych zastosowań Tor służy, ale do tej pory nie miałem żadnych konkretnych, jednoznacznych danych. Teraz je mam.

Sytuacja jest bardzo niekorzystna dla projektu, o czym autorzy nie piszą. Botnet prosto można rozbroić np. wyłączając mu komunikację. Czyli – na poziomie operatora ISP – np. blackhole’ując wszystkie node’y Tora (pośredniczące, czyli relay nodes; lista węzłów wyjściowych i pośredniczących jest publiczna, o czym pisałem we wpisie nt. walki z Tor). Chyba, że botnet jest naprawdę sprytny i korzysta z bridge node’ów, ale coś mi mówi, że raczej nie. Poza tym, zablokowanie – albo przynajmniej drastyczne utrudnienie – dostępu do informacji o bridge nodes też nie jest specjalnie trudne dla ISP…

Twórcy Tora są więc w trudnej sytuacji. Z jednej strony projekt powstał dlatego, że chcą zapewnić swobodną komunikacją. Z drugiej – jeśli nie będą interweniować i nie wyłączą w jakiś sposób botnetu, to istnieje ryzyko, że cała sieć Tor stanie się obiektem ataku jako wspierająca botnet.

Póki co, mój dylemat rozwiązałem tak, że drastycznie zredukowałem pasmo na moim relay node. I czekam na rozwiązanie sprawy. Jeśli trend się utrzyma, nie wykluczam wyłączenia węzła w ogóle.

PS. Jest jeszcze też oczywiście spiskowa teoria. Wszystko to dzieło wspierających kontrolę użytkowników i obywateli i zemsta za dekonspirację PRISM.

Czy to naprawdę kod źródłowy tego programu?

Polecam cały artykuł Is that really the source code for this software? a dla niecierpliwych lub niespikających krótkie streszczenie. Wiele wolnego oprogramowania przychodzi w postaci binarnej. Dołączony jest do niej kod źródłowy w teorii odpowiadający dokładnie temu, z którego zostały zbudowane wersje binarne. Zagadnienie jest ważne zarówno z punktu widzenia wolności oprogramowania, jak i bezpieczeństwa.

Autor ww. artykułu postanowił sprawdzić, jak to wygląda w praktyce dla popularnych dystrybucji Linuksa (Debian, Fedora, OpenSUSE). Na przykładzie tak prostego oprogramowania jak tar. Wykorzystał do tego celu minimalne instalacje systemu, korzystał ze źródeł dostarczonych w dystrybucjach i metod budowania zalecanych przez dystrybucje.

Wyniki są dość zaskakujące: ani razu nie udało mu się uzyskać dokładnej (bit w bit) kopii tego prostego przecież pakietu wykorzystując kod źródłowy.

W przypadku Debiana różnice były minimalne (data i id buildu w plikach wykonywalnych), w przypadku OpenSUSE było gorzej. Powstałe pliki binarne były 5 razy większe od oryginału. Po wykonaniu strip na wersjach binarnych sytuacja wyglądała już podobnie jak w przypadku Debiana. Najgorzej wypadła Fedora – nie tylko różnic było najwięcej, ale autorowi artykułu nie udało się ustalić przyczyn wszystkich rozbieżności . Jak pisze „niełatwo stwierdzić, czy samodzielny build ze źródeł będzie funkcjonował identycznie, jak opublikowana wersja binarna z dystrybucji”.

W przypadku skomplikowanych pakietów i projektów luźniej podchodzących do kwestii wolności oprogramowania, niż dystrybucje Linuksowe (np. firmware routerów z wykorzystaniem wolnego oprogramowania – często zamieszczają kernel, ale zwykle jest to wersja waniliowa wzięta na żywca z kernel.org…) różnice będą jeszcze większe. Gdyby ktoś znalazł komentarz RMS do sprawy, proszę o linka – bardzo jestem ciekaw, co ma do powiedzenia w tej sprawie.

UPDATE: Problem czy to naprawdę kod źródłowy danej binarki został dostrzeżony i doceniony, idea reproducible builds stała się popularna.

Domena debian-multimedia.org przejęta.

Zespół Debiana donosi, że domena debian-multimedia.org, pod którą wcześniej było dostępne nieoficjalne, lecz popularne repozytorium pakietów, wygasła, a obecnie została przejęta przez osobę niezwiązaną z projektem.

W związku z tym, wszystkie repozytoria odwołujące się do niej powinny być usunięte z sources.list, gdyż zachodzi możliwość przedostania się w ten sposób do systemu złośliwego kodu.

Aby sprawdzić, czy w systemie są one aktualnie obecne, można wykonać polecenie:

grep debian-multimedia.org /etc/apt/sources.list /etc/apt/sources.list.d/*

Przypominają również, że począwszy od wydania Wheezy’ego najprawdopodobniej nie będzie ona już potrzebna ze względu na poprawione wsparcie dla multimediów w tym wydaniu.

Przy okazji: z dyskusji na Facebooku wynika, że www.deb-multimedia.org nadal jest bezpieczne.