Pomiędzy bitami

Jeśli korzystasz z systemu Debian, to zapewne przywykłeś do wygodnej sytuacji, że aktualizacje zwykle przychodzą w repozytorium security. Jest to wygodne, bo proste apt-get update; apt-get upgrade teoretycznie zapewnia aktualne wersje wszystkich pakietów w systemie, z aktualizacjami bezpieczeństwa. Prawda?

Niestety, nie do końca. Po pierwsze, sama instalacja aktualnych wersji pakietów nie zawsze oznacza, że automatycznie zaczynają być one używane. Pomijając kernel, którego faktyczna aktualizacja wiąże się z rebootem, także inne programy niekoniecznie zaczynają być używane automatycznie w aktualnej wersji po ich instalacji. W określeniu programów do restartu przydatne bywa polecenie checkrestart z pakietu debian-goodies, o którym pisałem w ściągawce z przydatnymi poleceniami dla Linuksa. Ogólnie: próbuje ono podać procesy, których restart jest wymagany ze względu np. na aktualizację bibliotek.

Ale i to nie wszystko. Jest kilka innych rzeczy, które nie aktualizują się, mimo zainstalowanych paczek, które spowodowały ich obecność w systemie:

1. Flash od Adobe. Popularny na desktopach, spaczkowany - w specyficzny sposób - w Debianie w pakiecie flashplugin-nonfree, przy okazji podobno popularny wektor ataku. Aktualność swojej wersji Flasha można sprawdzić na stronie Flash Player check. Jakoś wolę ten sposób od strony Adobe. Aby zaktualizować wersję w systemie należy wydać polecenie:

   update-flashplugin-nonfree --install --verbose

   Oczywiście po powyższym trzeba zrestartować przeglądarki, żeby zmiana była efektywna.
2. Java od Sun. Ze względu na zmianę polityki, niedawno Java od Sun przestała być aktualizowana, również w zakresie aktualizacji bezpieczeństwa w Debianie i Ubuntu. Jeśli nadal korzystasz z niej w systemie, jest spora szansa, że masz starą wersję, o której aktualizację musisz zadbać samodzielnie. Można też zmienić wersję na którąś z wolnych alternatyw.
3. Mikrokod procesora. Jeśli posiadasz procesor Intela, to dostępne są aktualizacje mikrokodu od producenta. Co prawda bez tego też będzie działać, ale może udało się poprawić coś, co zwiększy wydajność? Sama instalacja pakietu microcode.ctlnie wystarczy, by zawsze mieć aktualną wersję zainstalowaną i wykorzystywaną w systemie. Aktualizację obecnego w systemie mikrokodu można wywołać ręcznie poprzez polecenie:

   update-intel-microcode

   Potem można przeładować mikrokod przy pomocy:

   /etc/init.d/microcode.ctl restart

Powyższe aktualne dla Debiana (głównie na desktopie, stąd nic o bazach wirusów, filtrach antyspamowych itp.), zapewne także dla pochodnych typu Ubuntu. Chyba, że tam jest to lepiej rozwiązane?

UPDATE: Przeładować owszem, można, ale jeśli dokonywana jest aktualizacja, to przeładowanie jest automatyczne.

Niektórzy to chyba się nigdy nie zmienią. Przeglądam stare wpisy o zmianie pracy i mam wrażenie, że nic się nie zmieniło, jeśli chodzi o moje podejście. Krótki opis sytuacji - jakieś dwa(? może nieco mniej, ale tak to odbieram; półtora roku przynajmniej) lata temu większość udziałów w obecnej firmie wykupiła inna firma. Wywołało to w owym czasie spore zamieszanie u nas, bo nikt nie wiedział, co będzie, jak będzie itd. Po jakimś czasie się sytuacja się ustabilizowała, wiele się nie zmieniło, wszyscy przeszli nad tym do porządku dziennego, praca toczyła się po staremu. Ale jakieś ziarno niepewności zostało.

Niedawno czynnie pojawiła się we władzach firmy osoba z firmy, która wykupiła większość udziałów. Kilka(naście) tygodni temu miła pani z HR przeprowadziła wywiady z ludźmi w firmie. Co kto robi, co mu się podoba, co nie, kompetencje. Taka prawie rozmowa rekrutacyjna. W sumie jedyną informacją jaką dostałem, było, że jak przejmują firmy to nie zwalniają raczej pracowników. Ale tyle to już zdążyłem wywnioskować. Dodając jeden do jeden wyszło mi, że koniec jest bliski (wbrew temu, co niektórzy pracownicy u nas twierdzili).

No i na początku grudnia dostałem oficjalną informację o wchłonięciu większej części obecnej firmy i propozycję bezproblemowego przejścia do firmy obok. Zmiana stanowiska, zmiana warunków pracy, z szansą na wyprostowanie pewnych upierdliwości, które tu od lat się nie zmieniły, a które z czasem stawały się coraz bardziej irytujące (głównie dyżury). Cóż, jak coś nie zmienia się od lat, to pewnie nie zmieni się nigdy... Wybór między niczym (bo nie dostaliśmy z firmy przejmującej żadnej informacji, jak widzą naszą pracę - stanowiska, warunki - po wchłonięciu) AKA czarną dziurą AKA chyba znowu zostanie po staremu, ale może coś się zmieni (pytanie czy na lepsze) a taką szansą był dość prosty. Została do załatwienia papierkologia i niefajny okres pracy poniekąd na dwa fronty.

Żałuję rozstania z dotychczasową ekipą, bo była naprawdę rewelacyjna i dająca radę z różnymi dziwnymi rzeczami (ilość R'n'D w pracy była zacna, nowości też, trochę szkoda, że nie do końca się to - z różnych względów - na wdrożenia produkcyjne przekładało). Ale nową ekipę znam i też wygląda OK (nie chwaląc dnia przed zachodem słońca). Zresztą ze starą ekipą mam nadzieję utrzymać kontakt, nie tylko zawodowy. Jak będzie, zobaczymy za kwartał, może pół roku. W każdym razie coś się kończy, coś zaczyna.

Zresztą, chyba coś dziwnego na rynku pracy się dzieje, bo prawda jest taka, że ostatnio (powiedzmy ostatni kwartał) wszyscy dookoła zmieniają pracę, a im bliżej końca roku, tym więcej ludzi zmienia. Poczynając od firm, z którymi współpracujemy, po znajomych z netu. Zresztą, właśnie niedawna rozmowa ze znajomym z netu zasiała spore wątpliwości co do sensu dotychczasowej sytuacji. Więc tak czy inaczej do końca stycznia (no, może do końca lutego) musiało się coś zmienić...

I tyle zamiast podsumowania roku 2011 (ten wpis nie miał być w żaden sposób podsumowaniem roku), który był rokiem bardzo mieszanym - trochę plusów, trochę minusów. Jak zwykle. Generalnie nie oceniam go źle.

W poprzednich wpisach było parę przemyśleń i sugestii poprawy komfortu pracy na desktopie wyposażonym w niewielką ilość pamięci RAM, bez finalnego rozwiązania choć z paroma trickami poprawiającymi pracę, więc pora na podejście trzecie do tematu, inspirowane przez kumpla z IRC, który sprzedał mi "newsa" o zram.

Od pewnego czasu (okolice kernela 2.6.37, jeśli dobrze widzę) w kernelu Linuksa obecny jest moduł zram, pozwalający na tworzenie kompresowanych urządzeń blokowych w pamięci RAM. Wykorzystać to można podobnie jak compcache, czyli do tworzenia kompresowanego obszaru pamięci, używanego przez system przed przeniesieniem danych na swap na dysku. Idea jest prosta - swap na dysku jest tragicznie wolny i obciąża I/O, procesor zwykle się trochę nudzi, zresztą nie będzie miał dużo więcej pracy, a ilość wolnej pamięci się zwiększy.

Ogólnie zram jest ideowym spadkobiercą compcache, ale wygląda mi na prostszy i ideowo, i w użyciu. No i jest obecny w kernelu. Idea działania jest prosta: tworzymy swap z wyższym priorytetem, niż swap na dysku, na urządzeniu blokowym umieszczonym w kompresowanym obszarze pamięci. Początkowo dane tradycyjnie są w RAM, w przypadku, gdy system musi korzystać z przestrzeni wymiany, umieszcza je najpierw na swapie w RAM, a dopiero później - tradycyjnie - na swapie na dysku.

Prosty skrypt realizujący powyższe:

#!/bin/bash
modprobe zram
echo $((200*1024*1024)) > /sys/block/zram0/disksize # 200 MB
mkswap /dev/zram0
swapon -p 60 /dev/zram0

Kolejno: załadowanie modułu zram (można korzystać z parametrów), określenie rozmiaru dysku dla urządzenia /dev/zram0 na 200 MB (i jest to rozmiar swap, będący jednocześnie maksymalną wielkością zużytej pamięci, nie rozmiarem przeznaczonej pamięci pamięci!), utworzenie swapu na urządzeniu  /dev/zram0, włączenie utworzonego swap z priorytetem 60.

Podobno efekty są świetne - zaczynam testy u siebie, wstępnie nie wygląda źle, na pewno niebawem podzielę się wrażeniami (jako update do tego wpisu) po dłuższym teście. Jeśli chodzi o rozmiar swap dla modułu zram, to zacząłbym od 10-20% całości RAM (u mnie 200 MB przy 1 GB RAM). Z tego co zauważyłem, skompresowane dane zajmują w praktyce ok. 40-50% oryginalnych.

Parę przydatnych poleceń diagnostycznych:

• cat /sys/block/zram0/compr_data_size - rozmiar danych po kompresji
• cat /sys/block/zram0/orig_data_size - rozmiar nieskompresowanych danych
• cat /sys/block/zram0/mem_used_total - całkowita ilość zużytej pamięci
• swapon -s - rozmiar i wykorzystanie poszczególnych swap (inna jednostka!)

Linki w temacie, które zdecydowanie warto przejrzeć, jeśli ktoś jest bardziej zainteresowany:

• http://www.webupd8.org/2011/10/increased-performance-in-linux-with.html
• http://unix.stackexchange.com/questions/17879/cleancache-vs-zram
• https://lwn.net/Articles/454795/
• http://en.gentoo-wiki.com/wiki/Zram_disks
• http://crunchbanglinux.org/forums/topic/15344/zram-a-good-idea/

Szczególnie ostatni wpis zawiera fajny, uwzględniający ilość procesorów skrypt startowy. Można rozważyć użycie po przeanalizowaniu. IMHO dla 1-2 procesorów trochę kosmiczne wartości będą, uzależnianie wielkości swap od ilości procesorów też jest średnie, ale poprawienie to nic trudnego. Za to obsługą utworzonego urządzenia blokowego zajmie się w tamtym wariancie więcej, niż jeden procesor. Z drugiej strony kto ma więcej niż dwa rdzenie i mało RAM?

Miałem obawy co do działania hibernacji (z użyciem pm-utils, z uswsusp miałem problem...) w takiej konfiguracji. Niepotrzebnie, bo wygląda, że działa OK - zapewne hibernacja jest na tyle inteligentna, że rozpoznaje, czy ma do czynienia z fizycznym urządzeniem blokowym.

Oczywiście swap to nie jedyne możliwe zastosowanie modułu zram - więcej przykładów w linku do wiki Gentoo.

Każdy medal ma dwie strony. To, że popieram prawo do anonimowości i wolności wypowiedzi nie znaczy, że nie rozumiem osób, które z różnych względów chciałyby ograniczyć dostępu do swojej sieci czy swojego serwisu użytkownikom sieci Tor. Poza tym, w znacznej mierze bawię się Torem, żeby lepiej poznać z czym wiążą się różne, zwłaszcza administracyjne aspekty sieci na sieci.

Sieć Tor z założenia ma sprzyjać anonimowości i omijaniu cenzury, a jak to wygląda w praktyce? Moim zdaniem, ma wiele słabości, chwilami sprawia po prostu broken by design. Ostatnio słychać było, o skompromitowaniu sieci Tor. Na blogu projektu Tor pojawiło się sprostowanie, wytykające błędy ale nie znaczy to, że różne słabości zupełnie nie istnieją.

Podstawową, znaną i opisaną w FAQ, słabością projektu, wynikającą z założeń projektowych jest, moim zdaniem, fakt, że publicznie dostępna, a przynajmniej trywialna do uzyskania jest lista wszystkich węzłów wyjściowych (exit node) i pośredniczących (relay node) Tora. Znacznie trudniej uzyskać listę bridge nodes, czyli węzłów służących wyłącznie do przyjęcia pierwszego połączenia od użytkownika, ale nie jest ona tak naprawdę potrzebna, by któryś duży gracz przeciwko Torowi mógł zaszkodzić sieci.

Niejawność bridge nodes wynikała z założeń projektu i z założenia miała służyć do tego, aby żaden ISP/kraj nie mógł w prosty sposób pozbawić swoich użytkowników możliwości połączenia z siecią Tor. I to zadanie spełnia przyzwoicie. Użytkownicy nadal mają możliwość uzyskania częściowych danych o bridge nodes z listy i podania ich ręcznie w swoim kliencie Tor, co w połączeniu ze zmiennymi IP bridge nodes bardzo utrudnia (o ile nie eliminuje) możliwości całkowitego zablokowania łączności z siecią Tor. Przynajmniej zablokowania opartego tylko o blokadę IP, nie analizę ruchu, ale to jakby zupełnie inny temat i skala trudności.

Natomiast mając listę węzłów końcowych, można je zablokować na wejściu do sieci czy dostępie do serwisu. Istnieją nawet serwisy, które zapewniają - mniej lub bardziej aktualne - gotowce. Ten serwis na przykład udostępnia aktualizowaną co godzinę blacklistę opartą na DNS z podziałem na węzły wychodzące i zwykłe.

Ale nie jest to jedyna metoda walki serwisów czy ISP z Torem. W praktyce mało kto, przynajmniej w naszym kraju, udostępnia węzeł wychodzący. Przyczyna jest prosta - dość szybko może skończyć się to (i kończy, nie mówię z własnego doświadczenia, ale słyszałem z pierwszej ręki o takich przypadkach) wizytą policji z powodu nadużyć z danego IP. Węzeł pośredniczący, o ile nie ma uruchomionej tzw. ukrytej usługi (hidden service) nie przechowuje ani nie udostępnia żadnych danych, więc jego uruchomienie w domu nie pociąga za sobą żadnych problemów (poza zużyciem części pasma).

Przynajmniej teoretycznie. W praktyce bowiem serwery serwisów nie lubiących Tora mogą sprawdzać nie tylko, czy użytkownik nie łączy się z IP na którym uruchomiony jest węzeł wychodzący, ale także czy połączenie nie jest z IP na którym uruchomiony jest węzeł pośredniczący i... także odmawiać dostępu. Przykładem jest choćby powyższy serwis z listami. Łącząc się z IP, na którym uruchomiony jest relay node zobaczymy:

Forbidden - TOR Node / Anonymous Proxy I'm sorry, but I really don't see why anyone would need to use a TOR node or Anonymous Proxy server to look at my site. So i'm afraid you can't look. Stop running TOR / using an anonymous proxy and you can view my site.

Przy względnie częstej aktualizacji listy węzłów (choćby wspomniana godzina), rozwiązanie takie praktycznie nie generuje skutków ubocznych dla serwisu, który ją wykorzystuje i minimalizuje ryzyko false positives, nawet przy zmiennym IP węzłów. Zakładając oczywiście, że lista jest prawidłowa i kompletna.

Zresztą, sami twórcy projektu Tor dają o to, żeby administratorzy którzy muszą blokować węzły wyjściowe Tora, mogli robić to w prosty sposób. Banowanie użytkowników sieci Tor także ma swój wpis w FAQ. Uprzykrzanie życia właścicielom relay nodes to już raczej otwarta wojna, której chcą uniknąć.

Skoro o otwartej wojnie mowa, gdyby jakieś państwo chciało unieruchomić sieć Tor, to obok blokowania bridge nodes może sięgnąć po (D)DoS (w sumie wystarczy zwykły flood) na - niekoniecznie szybkie - węzły pośredniczące. Węzły wyjściowe często są na dedykowanych maszynach i łączach, pośredniczące (tylko pośredniczące, każdy wyjściowy jest jednocześnie pośredniczącym) - niekoniecznie. Zresztą ponownie - istnieje strona podająca status sieci Tor, a na niej szczegółowe informacje o węzłach - rola, tzw. flagi, system, ilość przesyłanego ruchu... Zapewne można na jej podstawie szacować, jakie zasoby potrzebne są do przeprowadzenia ataku.

Przy okazji takie spostrzeżenie - ludzie z projektu Tor naprawdę wydają się skupieni na etyczny zastosowaniach i zapewnieniu anonimowości i wolności ludziom, którzy naprawdę tego potrzebują. I mocno liczą, że administratorzy serwisów to zrozumieją i nie będą w Torze widzieć wyłącznie narzędzia abuserów. W ciągu kilkudziesięciominutowej rozmowy, która się wywiązała na IRC przy okazji wspomnienia na temat tworzenia tego wpisu zostałem odesłany do paru prac naukowych (nie czytałem jeszcze, bo niezupełnie ten temat, podlinkowane poniżej). Atak totalny na tak szczytne przedsięwzięcie chyba nie bardzo mieści im się w głowie, natomiast zaprzątnięci są zapewnieniem anonimowości użytkownikom i pracują nad ulepszeniem możliwości łatwego i pewnego rozdzielenia węzłów wyjściowych od pośredniczących dla tych, którzy muszą blokować dostęp z sieci Tor.

Stąd moje wrażenie o broken by design może być przesadzone lub zwyczajnie mylne - zwyczajnie nie do tego i nie przy takich zastosowaniach było to projektowane... Generalnie Tor ma warstwy - z pozoru wygląda na bardzo prosty twór, ale im dalej się wgłębiać, tym ciekawsze nowe rzeczy się pojawiają. Przyznam, że sam nie grokuję Tora w pełni, stąd ten wpis, będący poniekąd próbą uporządkowania paru faktów.

Linki (które kiedyś mam nadzieję przeczytam, niekoniecznie o Torze):

• Ogólny zbiór prac nt. anonimowości: Selected Papers in Anonimity
• http://isis.poly.edu/~csaw_research/Eugene%20Vasserman.pdf
• http://hatswitch.org/~nikita/papers/phd-thesis.pdf
• http://petsymposium.org/2006/preproc/preproc_11.pdf
• http://research.microsoft.com/en-us/um/people/gdane/papers/bridge.pdf
• Prezentacja nt. ataku na sieć Tor http://www.flickr.com/photos/35149312@N05/6304649995/in/photostream/