Tag: debian

Opublikowane w

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.

Opublikowane w

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
Opublikowane w

Linux – co warto seedować?

Jakiś czas temu postawiłem NAS w domu (jest zaległy szkic wpisu od… dawna, pewnie w końcu się zbiorę i go opublikuję). Łącze jest przyzwoite (2 Mbit uploadu) i słabo wykorzystane, a nie chciałem, żeby leżało odłogiem i postanowiłem wesprzeć projekty open source poprzez seedowanie plików.

Minęło jakieś półtora miesiąca od ostatniej zmiany plików, więc można pokusić się o jakieś wnioski. Plik/katalog i ratio:

tails-i386-0.22.1 - 15,0
debian-7.4.0-amd64-netinst.iso - 4,4
debian-7.4.0-amd64-CD-1.iso - 7,1
debian-7.4.0-i386-netinst.iso - 5,1
debian-7.4.0-i386-CD-1.iso - 7,8
debian-7.4.0-armel-netinst.iso - 1,6
debian-7.4.0-armel-CD-1.iso - 1,2

Jak widać, największym zainteresowaniem cieszy się opisywana kiedyś dystrybucja T(A)ILS, w przypadku Debiana zaskakuje niemal równa popularność architektur i386 oraz amd64 (liczyłem, że będzie duża przewaga amd64, przecież to niemal każdy współczesny procesor wspiera). IMO zupełnie nie warto seedować obrazów z architekturą armel.

Zdaję sobie sprawę, że lista jest mocno niekompletna, ale niestety nadal nie kupiłem docelowego dysku i miejsce mnie mocno ogranicza. Przy najbliższej wymianie plików wyleci armel, a pojawi się jakieś Ubuntu albo i Kali Linux.

UPDATE: Próbka jest na razie bardzo mała bo jakieś 4 dni, ale wygląda, że Kali Linux (architektura amd64, następca BackTrack, czyli dystrybucja Linuksa przeznaczona dla pentesterów) jest strzałem w dziesiątkę. Ratio 2,44, kolejny w kolejności ma 1,07…

UPDATE2: Zdecydowanie Kali Linux! Amd64 – ratio 37,3 , i386 – 25,9 w ciągu 4 tygodni.Tails – 5,01 w ciągu 2 tygodni, czyli po normalizacji czasu ratio ok. 10. Dość podobnie jak w krótkim okresie, jak widać.