Panoptykon narzeka na ministerstwa i blokowanie Tora

Fundacja Panoptykon po raz kolejny narzeka na blokowanie przez ministerstwa IP, na którym mają uruchomiony węzeł Tor (relay-node). Sytuacja skłoniła mnie do wpisu, bo mam wrażenie, że zachodzi grube niezrozumienie tematu. Z obu stron…

Logo projektu Tor

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

 

Czy warto blokować ruch z sieci Tor?

To zależy. Ruch z sieci Tor pozwala na łatwe uzyskanie stosunkowo wysokiej anonimowości w sieci. Z jednej strony jest to wykorzystywane do anonimowej komunikacji przez zwykłych ludzi, z drugiej jest wykorzystywane do nadużyć i wandalizmu. Ze znanych serwisów wymienionych w FAQ – Wikipedia blokuje edycję artykułów z sieci Tor, podobnie Slashdot. Oczywiście takich serwisów jest o wiele więcej. Po prostu stosunek sygnał/szum jest w przypadku sieci Tor wyjątkowo niski.

Są też inne, poważniejsze powody do blokowania. O ile sieć Tor ma raczej słabą przepustowość i nie nadaje się do ataków wolumetrycznych, to zdecydowanie ułatwia łatwe, anonimowe ataki na aplikację, SQLi itp. Czyli raj dla script kiddies. I dokładnie taki jest oficjalny powód podany przez rzecznika ABW cytowany na Niebezpieczniku.

Jak blokować ruch z sieci Tor?

Autorzy projektu Tor podkreślają, że wezły sieci Tor mają indywidualne polityki, ale.. Patrząc z punktu widzenia administratora serwisu docelowego i ekonomii działania: sieć Tor to jakieś ułamki promila ruchu, w dodatku często ruchu niepożądanego. Jeśli ktoś zdecyduje się już blokować ruch z sieci Tor, to raczej nie będzie bawił się w polityki poszczególnych węzłów, tylko zablokuje wszystkie. Czy to na poszczególnych maszynach, czy to na centralnym firewallu, czy wręcz null-route’ując na routerach ruch kierowany do węzłów Tor (co uniemożliwi komunikację TCP). Ostatnia metoda jest i prosta w implementacji, i prosta w utrzymaniu (centralne miejsce do zarządzania), i wydajna.

Z których węzłów ruch blokować?

Tu jest pies pogrzebany. Fundacja Panoptykon nie prowadzi exit node, czyli nie przekazuje ruchu z sieci Tor do „normalnego internetu”. Niestety, oficjalne narzędzia udostępniane przez projekt Tor IMO nie są zbyt przyjazne administratorom (szczególnie tym, którzy są mniej świadomi zasad działania Tora lub którzy nie mają czasu). Blokowanie wszystkich węzłów Tora widziałem spotkałem, zarówno jako użytkownik końcowy (tak, relay node w domu, ruch z normalnego IP i komunikat o niewpuszczaniu z sieci Tor w serwisie), jak i administrator. Przede wszystkim brakuje oficjalnej listy węzłów wyjściowych łatwej do przetwarzania, czyli zawierającej same IP. Przypominam, że pisałem we wpisie o blokowaniu węzłów Tor, że udostępniam taką listę. Tylko exit nodes, tylko adresy IP.

Podsumowując, obie strony są winne:

Dziwią mnie żale ze strony Panoptykonu, gdy sytuacja jest typowa i opisana w FAQ Tora:

You might also find that your Tor relay’s IP is blocked from accessing some Internet sites/services. This might happen regardless of your exit policy, because some groups don’t seem to know or care that Tor has exit policies. (If you have a spare IP not used for other activities, you might consider running your Tor relay on it.)

Jak widać, projekt Tor zaleca prowadzenie węzłów na oddzielnych IP, nieużywanych do innych usług. Tak, wiem, sekcja dotyczy węzłów wyjściowych, ale idę o zakład, że pomysłodawca/admin w Panoptykonie nie czytał. Poza tym, zdrowy rozsądek zaleca analizę możliwych konsekwencji przed uruchomieniem usługi i stosowanie oddzielnych IP w tym przypadku.

Dziwi mnie też implementacja blokowania Tora na rządowych serwerach, wskazująca na niezrozumienie tematu. Oczywiście nie mam złudzeń co do korzystania przez nich np. z mojej listy (sam bym tego na ich miejscu nie zrobił), ale samodzielna implementacja to nie rocket science… Plus, niezrozumienie tematu może prowadzić do fałszywego poczucia bezpieczeństwa – tak naprawdę nie sposób zablokować 100% ruchu z sieci Tor, przynajmniej nie w oparciu o adresy IP.

Chef i cookbooki bez metadata.rb

W firmie korzystamy z Chefa, niby robi swoją robotę, ale nie przepadam za nim z różnych względów. Jedna z rzeczy, która mnie drażni, to wersjonowanie i niekompatybilność (bardziej: pozorna kompatybilność) pomiędzy wersjami. W Debianie Jessie, którego mam na desktopie jest chef w wersji 11, który generalnie działał. Na serwerach mamy Chefa 12.

Ostatnio instaluję cookbook nodejs:

knife cookbook site install nodejs
Installing nodejs to /home/rozie/chef-repo/cookbooks
Checking out the master branch.
Pristine copy branch (chef-vendor-nodejs) exists, switching to it.
Downloading nodejs from the cookbooks site at version 2.4.2 to /home/rozie/chef-repo/cookbooks/nodejs.tar.gz
Cookbook saved: /home/rozie/chef-repo/cookbooks/nodejs.tar.gz
Removing pre-existing version.
Uncompressing nodejs version 2.4.2.
removing downloaded tarball
No changes made to nodejs
Checking out the master branch.
ERROR: IOError: Cannot open or read /home/rozie/chef-repo/cookbooks/nodejs/metadata.rb!

Zacząłem szukać i widywać różne dziwne rozwiązania na nieistniejące metadata.rb, przez chwilę przyszło mi dogenerowanie „brakującego” pliku na podstawie obecnego metadata.json, ale… coś mnie tknęło i postanowiłem najpierw spróbować z nowszym Chefem u siebie na lapku.

Ależ oczywiście, że instalacja Chefa w wersji 12 rozwiązała problem.

Korzystając z apt-dater – parę uwag

Od pewnego czasu korzystam z opisywanego kiedyś narzędzia apt-dater do aktualizacji hostów w środowiskach większych, niż kilka własnych testowych maszyn. Garść praktycznych uwag nt. używania w takich środowiskach.

  1. W okolicy wersji 1.0 zmienił się format pliku (teraz jest XML), przez co linkowany wyżej opis jest nieaktualny. Zmian wymagał też skrypt generujący konfigurację apt-datera na podstawie danych z Chefa.
  2. Warto podzielić hosty na grupy – raz, że łatwiej decydować, gdzie wykonujemy aktualizację w danym momencie, dwa, że każdy host to osobne procesy w momencie działań więc… może być tego za dużo, jeśli zaczniemy aktualizować listę pakietów wszędzie jednocześnie (tak, mam skonfigurowane limits na workstacji, tak walnąłem w limity, jak leciałem hurtem).
  3. Sama aktualizacja to nie wszystko, trzeba jeszcze zrestartować procesy korzystające ze starych bibliotek. Kiedyś był checkrestart, teraz jest bardziej popularny –  i nieźle współpracujący z apt-daterneedrestart.
  4. Niezależnie od podziału na grupy, można ad hoc zaznaczyć hosty do wykonania operacji (polecenie tag). Sposób niezbyt intuicyjny, bo najpierw zaznaczamy hosty [t], następnie zatwierdzamy je do wykonania [;], a na końcu wybieramy polecenie do wykonania.
  5. Apt-dater przyspiesza pracę, ale nie udało mi się (i nie tylko mi), uniknąć podłączania do każdej sesji po zakończeniu aktualizacji i zamykania jej. Nawet, jeśli cała aktualizacja przeszła pomyślnie, bez interaktywnych pytań i nie ma nic do restartu. Gdyby się komuś udało – proszę o komentarz.
  6. Odpowiednio ustawione hold lub apt_preferences to podstawa, jeśli ma się jakieś dziwne (czytaj: 3rd party) pakiety, których autorzy niezupełnie umieją paczkować Debian way.

W każdym razie apt-dater bardzo ułatwia i przyspiesza pracę. Generalnie polecam.