Tails w wersji 1.0 wydany

Projekt Tails, czyli dystrybucji Linuksa ułatwiającej zachowanie anonimowości (szerzej opisana w tym wpisie) doczekał się w końcu wersji 1.0. Poza kosmetycznymi zmianami w nazwie i logo, wydanie przynosi tradycyjne aktualizacje bezpieczeństwa typu aktualizacja przeglądarki Firefox i aktualizacja oprogramowania Tor, w szczególności pod kątem niedawnego błędu Heartbleed.

Prawdę mówiąc uważam, że przeskok numeracji nieco przedwczesny, gdyż na czerwiec przewidziane jest wydanie wersji bazującej na Debianie Wheezy (aktualnie Tails oparty jest o Squeeze). Ale w sumie to tylko cyferki – sam system działa nieźle od dłuższego czasu. Co ciekawe, twórcy donoszą, że liczba użytkowników wzrosła w ciągu ostatniego półtora roku czterokrotnie.

Banana Pi – alternatywa dla Raspberry Pi

Zwykle nie piszę o hardware, nawet opartym na ARM, ale tu zrobię wyjątek. Raspberry Pi od początku średnio mi się podobało, ale nowy projekt czyli Banana Pi, zrobiony przez inną ekipę jest naprawdę ciekawy. Jak to ktoś ładnie ujął, Chińczycy wezmą i zrobią lepiej.

 

Zmiany w stosunku do Raspberry Pi:

  • Ethernet 10/100/1000 (przy NAS po kablu może robić kolosalną różnicę, choć wątpię, by faktycznie wyciągało pełen gigabit),
  • Wbudowane złącze SATA (znowu spora różnica dla NAS),
  • Procesor Corex A7 dual core, czyli dwa rdzenie prawdopodobnie po 1 GHz każdy, czyli niemal trzy razy tyle MHz ile ma niepodkręcane Raspberry Pi,
  • 1 GB RAM, czyli dwa razy więcej,
  • wbudowany IR (odbiornik podczerwieni), czyli teoretycznie trywialne do zrobienia sterowanie pilotem

Zachowane złącza GPIO, wymiary i niska cena. Z tego co piszą, działa dedykowany dla Raspberry Pi Raspbian. Wspierany jest także Debian (czyżby niemodyfikowany?). Co lepsze, użycie nowszego procesora oznacza, że będzie działać architektura armhf, więc nie ma potrzeby stosowania protezy w postaci Raspbiana.

Koszt to niby 43 dolary, ale za mniej niż 50 nie znalazłem do kupienia. Tak czy inaczej IMO zdecydowanie warto dopłacić. Niebawem zamówię i najprawdopodobniej wymienię silnik obecnego NAS opartego na Raspberry Pi.

I jeszcze stronka w Wikipedii poświęcona Banana Pi.

UPDATE: Dzięki namiarom z komentarzy (thx Zal!) wiemy więcej. Zapowiadało się dobrze i jest dobrze. Przynajmniej jeśli chodzi o benchmark Banana Pi vs. Raspberry Pi. Dla niecierpliwych: banan ma sieciówkę (o go głównie były obawy) 6-7 razy szybszą (iperf). Za to uwaga, Banana Pi jest nieco większe od Raspberry Pi i nie wszędzie się zmieści. Jak donosi też mniej pochlebna recenzja, nie wszystkie rozszerzenia będą pasowały z uwagi na przesunięcie niektórych złącz.

UPDATE: W jednym z kolejnych wpisów opisuję, jak zrobić z maszynki z Linuksem router, GSM/LTE z Wi-Fi. Z uwagi na niewielkie rozmiary i mały pobór energii Banana Pi świetnie się do tego nada.

Raspberry Pi jako NAS

Nie bardzo miałem co zrobić z moim Raspberry Pi, a przecież nie może się maszynka nudzić. Przy czym łącze do domu mam całkiem fajne i w praktyce po WiFi nie do wykorzystania[1], więc postanowiłem zrobić sobie seeder torrentów[2], serwer do backupu innych maszynek i ogólnie NAS dla domu. Niby coś jak Dockstar, ale nie głównie router, tylko z akcentem na NAS. W sumie może kiedyś dorzucę mini hosting dla własnych gadżetów – na razie leży to sobie na dedyku, zresztą rpi demonem szybkości nie jest, więc z czymkolwiek ponad statyczne strony może być ciężko…

Nierozwiązaną miałem kwestię obudowy dla Raspberry Pi. Przy czym, gdybym zrobił to tradycyjnie, to byłby hub USB, kabelki do rpi, kabelki do dysku, kabel do zasilania, kabel do routera. Trochę plątanina, którą ciężko utrzymać w czystości, bo ani odkurzyć porządnie, ani przetrzeć szmatką. No i podatne na usterki, bo taki kabel na wierzchu jednak łatwo szturchnąć. Postanowiłem, że spróbuję upchać to wszystko w jedno pudło i zacząłem rozglądać się za jakimś dającym się wykorzystać gotowcem.

Pierwsze co mi wpadło w oko, to pudełka do żywności w Netto. Trzy sztuki (różnej wielkości) za 8 zł. Szybka przymiarka ujawniła, że średnie, na które liczyłem się nie nadaje, bo jest za małe. Za to największe pasuje. Na styk, zresztą, ale to dobrze – można zrezygnować z mocowania elementów w środku. Trochę bałem się, że plastik nie będzie odporny na temperaturę, ale niesłusznie – wg opisu pojemniki są przeznaczone do temperatur od -30 do +100 C i do użytku w mikrofali.

Układ elementów w pudełku następujący: na dole dysk w kieszeni, jako element najchłodniejszy i najcięższy, ma lekko miękkie etui z tworzywa, więc na nim bez obaw mogę położyć Raspberry Pi. Hub USB Unitek przymocowany do pokrywki przy pomocy opasek samozaciskowych (AKA żmijki). Po pierwsze jest metalowy, więc nie chcę go mieć w pobliżu rpi z uwagi na możliwe zwarcia, po drugie jego ażurowa obudowa sugeruje, że może się grzać. Pierwotnie rpi miało leżeć wzdłuż dysku, ale nie pasowało to do układu kabli. Zresztą jest na tyle małe, że w poprzek też praktycznie nie wystaje poza obrys dysku.

Miałem obawy o temperaturę w środku, bo wymiana powietrza jest mocno utrudniona. Nie było źle – S.M.A.R.T. dla dysku pokazywał góra 40 stopni, ale ostatecznie zdecydowałem się na dodanie otworów od spodu pudełka (w zamyśle wlot zimnego), zrobienie nóżek z podkładek filcowych (samoprzylepne do mebli) w celu umożliwienia dopływu powietrza do nich, oraz kilku otworów na samej górze z boku (w zamyśle wylot ciepłego powietrza; nie pokrywka, żeby kurz nie wpadał od góry do środka). Dzięki temu jakiś tam przepływ jest i odrobinę chłodniej.

Uroki notek po czasie są takie, że mogę napisać, jak to działało i czemu przestało. Działało bardzo dobrze i stabilnie. Jedyne restarty to braki prądu (rzadko się zdarza, ale się zdarza) lub wymiana kernela. Uptime po kilkadziesiąt dni. Wydajnościowo szału nie ma – sam NTFS via ntfs-3g potrafił wskoczyć w top na pierwsze miejsce z kilkadziesiąt procent (40-60) zużycia CPU. Oczywiście NTFS jest tam tymczasowy – po prostu chwyciłem do testu dysk, który robił za przenośny. No i całość jak najbardziej wyrabiała się z serwowaniem plików po sambie po WiFi, tyle, że cokolwiek więcej w tym czasie na rpi było problematyczne. Dysk po USB jak najbardziej daje radę, ale ten element miałem przetestowany już wcześniej.

Dzięki temu, że miałem notkę o testowym uruchomieniu Raspberry Pi, wiem dość dokładnie, ile działało. Problemy (niemożność zalogowania się po SSH) zaczęły się na początku kwietnia, czyli podziałało jakieś 4 m-ce. Niestety, trafnie przewidziałem powód: pad karty micro SD (ja wiedziałem, że tak będzie… pamięci flash nie nadają się do zapisu ja wiedziałem, że tak będzie…). Początkowo uważałem, że to zwykłe zawieszenie, ale po restarcie po paru godzinach sytuacja się powtórzyła. Wyjąłem kartę, w komputerze popełniłem backup przez obraz partycji, następnie fsck (były błędy) i przy okazji zdjąłem journal z ext4. Podziałało jeszcze parę dni i sytuacja znowu się powtórzyła. Tym razem sprawdziłem dokładniej. Badblocks widzi błędy na karcie, zarówno na teście odczytu (jeden), jak i niedestrukcyjnym teście zapisu (więcej). Próbowałem reanimować przez oznaczenie przez fsck sektorów jako uszkodzonych (patrz przydatne polecenia Linux), ale bez powodzenia – po naprawie rpi już się nie bootuje z tej karty.

Nie jestem w stanie stwierdzić, czy winien był – niestety domyślnie w Raspbianie włączony – journal, czy zapisywanie przez transmission stanu co kilkanaście minut na dysk (kartę) gdzieś w /var. Symlinka i przenoszenia na dysk twardy nie robiłem, bo po pierwsze i tak system był z journalem, po drugie, chciałem zobaczyć, na ile to szkodliwe dla karty. Jak widać jest szkodliwe i karta potrafi paść w mniej niż pół roku. Co prawda widzę karty Goodram 4 GB za ok. 10 zł, ale nie widzę sensu w grzebaniu i ew. utracie danych.

Niebawem, po kupnie karty (tak się pechowo składa, że nic wolnego większego niż 2 GB chwilowo pod ręką nie mam), wskrzeszę system. Być może kupię docelowy dysk do kieszeni i wtedy zrobię od razu root montowany w trybie read only. Nawet jeśli nie, to od razu po instalacji zdejmę journal z ext4, prawdopodobnie zajmę się też od razu transmission…

Kiedyś pojawią się tu zdjęcia – leżą na dysku, który był podłączony do NAS, a nie chce mi się podłączać go bezpośrednio do kompa…

[1] Bo router to WRT54GL, który co prawda linkuje się na 54 Mbit bezprzewodowo, ale realnie komputery wyciągają ok. 20 Mbps. Po wpięciu na kablu nie ma problemu. W eterze umiarkowany syf, wybrany najlepszy kanał i tryb G only. Ogólnie 802.11n by się przydało, ale przecież router działa, a szczerze mówiąc nie sądzę, bym zobaczył różnicę – 20 Mbps to kosmos. Chociaż znajomi donoszą, że przy 802.11n poprawia się zasięg, więc pewnie się skuszę…

[2] Żadne tam nielegale, po prostu mały wkład w projekty open source: seedują się netiso Debiana (trzy architektury), pierwszy CD Debiana (trzy architektury), t(a)ils, tego typu sprawy. Zresztą pisałem o tym już (uroki niechronologicznego publikowania notek).

UPDATE: W jednej z kolejnych notek opisuję, jak zrobić z maszynki z Linuksem router GSM/Wi-Fi. Z uwagi na niewielkie rozmiary i mały pobór energii Raspberry Pi nadaje się do tego bardzo dobrze.

Nie żyjesz w demokracji

Jakiś czas temu mignął mi nagłówek na Slashdocie o tym, że badania wykazują, że w Stanach Zjednoczonych nie ma demokracji, tylko zamiast niej jest oligarchia. Czyli, pokrótce, nie rządzą przeciętni obywatele, tylko elity ekonomiczne i przedstawiciele zorganizowanych grup zajmujących się daną sprawą. Na dłuższy wpis nie miałem do tej pory czasu za sprawą zadymy w pracy i treningów, ale zagadnienie jest bardzo ciekawe, więc pora nadrobić.

Po pierwsze, nie jest to gdybanie oparte na Głębokim Przekonaniu i argumentami typu to wymyślili producenci gaśnic czy to pomysł lobby producentów żarówek, tylko badania naukowe, z podanymi źródłami i możliwością ich samodzielnej weryfikacji i analizy (na to nie miałem czasu jeszcze). Po drugie, dotyczy USA. U nas może być tylko gorzej, choćby ze względu na inwestycje pozakrajowych grup interesów. Po trzecie, potwierdza to słuszność ruchów libertariańskich, anarchistycznych i samorządowych, które z jednej strony są od siebie ideologicznie dość odległe (niestety; bardzo to na rękę obecnym elitom), z drugiej postulują znacznie bardziej oddolny model, niż to, z czym mamy obecnie.

Na koniec dla przypomnienia wpisy o manipulacji w demokracji, i o niegłosowaniu w wyborach. Polecam też uwadze fakt, że mamy tak genialnie skonstruowaną ordynację, że frekwencja, czy zainteresowanie ludu nie ma już znaczenia w większości przypadków w wyborach. W razie czego elity same do urn pójdą i w wyborach obsłużą się same.

Na wypadek, gdyby rzeczony dokument miał zniknąć lokalna kopia do pobrania.

Dziura w OpenSSL, o jakiej się nie śniło

No bo jak inaczej nazwać błąd, który pozwala na zdalny dostęp do pamięci podatnej maszyny? Co prawda „tylko” 64kB i „tylko” związanej z procesem korzystającym z biblioteki zawierającej błąd, ale biorąc pod uwagę, do czego OpenSSL służy… Wyciec mogą klucze (jeśli nie zostaną zmienione, to w przypadku ich przechwycenia będzie można podsłuchać transmisję nawet po aktualizacji biblioteki), loginy i hasła (jeśli użytkownicy nie zmienią haseł, to atakujący będzie mógł się dostać do serwisów nawet po zmianie certyfikatów i aktualizacji biblioteki).

Heartbleed

Źródło: http://heartbleed.com/

Błąd związany z OpenSSL w Debianie sprzed blisko 6 lat to przy tej dziurze pikuś – wtedy wystarczyło zaktualizować pakiet i zmienić klucze. Teraz na dobrą sprawę należałoby zmienić wszystkie certyfikaty SSL (o ile były używane na choć jednej podatnej maszynie) i skłonić wszystkich użytkowników do zmiany haseł. Niekoniecznie technicznych użytkowników, dodajmy.

Ważne jest to o tyle, że niektóre popularne polskie serwisy oferujące darmową (i nie tylko) pocztę były podatne. I to dość długo (nie wiem, czy nadal nie są). Jeśli atakujący uzyska dostęp do poczty, a używamy tej skrzynki do przypominania hasła w innych serwisach to zmiana w nich haseł nie rozwiązuje problemu.

Dodatkowo sprawdzanie podatności systemów było utrudnione. Popularny test sprawdzający podatność na atak z powodu obciążenia zgłaszał… false negatives. Czyli system był podatny, a narzędzie testujące twierdziło, że jest OK. I to w pewnym momencie, wg moich obserwacji, w jakichś 9x% prób… Problemu tego nie miało narzędzie CLI, ale dość szybko przestało ono być dostępne. Zapewne dlatego, że skutkiem ubocznym tego narzędzia był zrzut pamięci i dostęp do wrażliwych danych.

Na koniec mały paradoks. Systemy, w których logowanie było bez szyfrowania nie są podatne na dziurę (za to były i są podatne na podsłuchanie transmisji). Podobnie jak Debian Squeeze, czyli oldstable, któremu wkrótce skończy się support bezpieczeństwa. Użyta w nim wersja OpenSSL jest na tyle stara, że nie jest podatna.

Na razie status jest taki, że jest dostępna poprawka, załatana jest część systemów (wczoraj o ok. 17 było naprawdę sporo dziurawych). Widziałem tylko jedną firmę (polską), która poinformowała o błędzie użytkowników i zaleciła zmianę certyfikatów (ale już ani słowa o hasłach). Osobiście zalecam zwykłym użytkownikom w tej chwili zmianę ważniejszych haseł (zwł. pocztowych!) i obserwację sytuacji. Gdy opadnie kurz, tj. administratorzy załatają systemy i wymienią certyfikaty – ponowna zmiana haseł, tym razem wszystkich (ale naprawdę wszystkich wszystkich).

Błędowi poświęcona jest specjalna strona i tam odsyłam po szczegóły. Tak jeszcze patrzę na to, co napisałem parę lat temu i chyba tekst dane, niezależnie od tego jak zabezpieczane, nie są bezpieczne i prędzej czy później nastąpi ich ujawnienie łapie się na jakieś motto.

UPDATE: Ważna uwaga, o której zapomniałem. Jeśli aktualizujemy OpenSSL w systemie, to trzeba jeszcze zrestartować usługi. W Debianie można skorzystać z polecenia checkrestart (pakiet debian-goodies), ale na przynajmniej jednym systemie pokazywał, że nie ma nic do restartu, choć był apache i zabbix-server. Można zamiast tego użyć:

lsof -n | grep ssl | grep DEL

Dyn.com kończy świadczenie darmowych usług

Dla mnie konto na dyn.com skończyło się wcześniej, dziś ogłosili na blogu, dlaczego zdecydowali się zaprzestać świadczenia darmowych usług w ogóle. Przyznam, że byłem zadowolony w tym wąskim zakresie, w jakim korzystałem, ale dopiero sposobem wyłączenia i rozłożeniem go w czasie mnie ujęli. PRowo jak dla mnie wzorowo: mocno rozłożone w czasie, narastający poziom trudności w utrzymaniu darmowych usług, możliwość łatwego przejścia na wariant płatny, dobra informacja (OK, to w ich interesie). Last but not least: utrzymanie obiecanych wiecznych darmowych kont wczesnym użytkownikom. Naprawdę uważam za ładnie rozegrane.

Pozostało mi życzyć im powodzenia i podziękować, zatem: thank you, dyn.com. 🙂

Wolność w Mozilla Foundation

Albo raczej jej brak. Po tym jak Brendan Eich został CEO Mozilla Foundation, ludzie przekopali jego przeszłość i odkryli, że w roku 2008 dokonał darowizny w wysokości tysiąca dolarów na rzecz poparcia zmiany prawa tak, by małżeństwa osób tej samej płci nie były możliwe w Kalifornii. I zaczęła się nagonka ze strony środowisk LGBT, która zakończyła się ustąpieniem ze stanowiska (prywatnie uważam, że niekoniecznie z własnej nieprzymuszonej woli).

Jak to ma się do wolności przekonań politycznych, religijnych, moralnych i światopoglądowych? Legalne poparcie legalnych instytucji (nie mówimy tu przecież o jakichś bojówkach), ze środków prywatnych, owocuje atakiem medialnym. W moim odczuciu atakiem z powodu prywatnych przekonań, bo Brendan Eich jasno dał do zrozumienia, że w zakresie Mozilla Foundation nic się nie zmienia i pozostają nadal otwarci na różnych ludzi, niezależnie od rasy, płci, religii i orientacji seksualnej.

Uważam, że działaniom środowisk LGBT blisko w tym momencie do dyskryminacji z powodu przynależności partyjnej, religijnej itd. IMO Mozilla niebezpiecznie zbliża się do stanowiska szanujemy wolność wypowiedzi i przekonań, pod warunkiem, że są to przekonania zgodne z oficjalną linią partii. Ciekawe kiedy wpadną na pomysł wprowadzenia mechanizmów cenzury w ramach obrony wolności wypowiedzi?

W każdym razie Mozilla sporo straciła w moich oczach. O ruchu LGBT nie wspominając.

CryptoLocker – polski akcent

Istnieją poważne poszlaki, że za ransomware o nazwie CryptoLocker stoją… Polacy. Malware ów został zbadany i opisany na blogu [deadlink] (polecam lekturę całego wpisu), autor uzyskał dostęp do bazy (niestety dość pustej) i widać w kodzie tekst:

define('DBPASS', 'Be6mybCWhpFpgG4u');//Dostep do sql zamiana!!!

Swojsko brzmiący komentarz, prawda? Swoją drogą ładny przykład na to, że korzystanie z Tor nie oznacza braku możliwości namierzenia, gdzie stoi serwis, chociaż w tym przypadku autorowi wpisu nie udało się uzyskać adresu IP systemu.

UPDATE: Jak donosi Zaufana Trzecia Strona, malware nie nazywa się CryptoLocker, a CryptorBit. Polecam ich wpis – dużo więcej informacji i po polsku.