Kategoria: Linux

Opublikowane w

Powtarzalne budowanie pakietów w Debianie

Dyskusji nt. zgodności pakietów binarnych z dostarczanymi źródłami teraz nie znajdę (podrzucenie mile widziane), ale Półtora roku temu pisałem o braku weryfikacji, czy kod źródłowy jest zgodny z wersją binarną. Pamiętam, że w różnych dystrybucjach wyglądało to różnie, a chyba w żadnej dobrze. IIRC na testowanym pakiecie różnice w Debianie były minimalne, bo dotyczyły tylko timestampu ale… były. W praktyce dla użytkownika końcowego oznacza to brak możliwości łatwego zweryfikowania, czy dostarczony (bardziej: deklarowany) kod źródłowy odpowiada dostarczonej wersji binarnej pakietu[1].

Implikacje są oczywiste: możemy uruchamiać co innego, niż sądzimy, że uruchamiamy. Z jednej strony może dojść do naruszenia licencji (zwł. GPL) i użytkownik może mieć problemy z modyfikacją oprogramowania, z drugiej, bardziej praktycznej: mogą pojawić się problemy z bezpieczeństwem. Nie tylko developer może dołożyć coś od siebie (developerom ufamy),. Także atakujący może w wyniku włamania przejąć klucze jakiegoś developera i wprowadzić zmodyfikowaną wersję binarną pakietu do repozytorium.

Wiadomo, że dokładna i systematyczna kontrola podstawą zaufania, w związku z tym w Debianie ogłoszono projekt Reproducible Builds. Ma on na celu dostarczenie narzędzi i środowisk do kontroli. Oraz poprawę pakietów tak, aby można było w prosty sposób sprawdzić zgodność pakietu binarnego ze źródłem. Czyli każdy będzie mógł łatwo odpowiedzieć na pytanie: czy dany pakiet powstał z deklarowanego źródła?

Projekt dotyczy raczej przyszłych wersji Debiana, ale na pewno jest krokiem w kierunku zwiększenia wolności użytkowników i bezpieczeństwa.

Wg danych projektu Reproducible Builds w chwili obecnej udało się potwierdzić powtarzalność budowy ponad 83% pakietów z repozytorium main dla Debiana unstable.

[1] Nie miejsce na dyskusję nad wyższością dystrybucji pakietów w źródłach nad wersją binarną i odwrotnie.

Opublikowane w

Iptables TARPIT, czyli spowolnij boty

Jak wiadomo, nie jestem fanem malware i raczej staram się uprzykrzać życie botom i spamerom. Nic wielkiego: a to zrobię miejsce, gdzie boty mogą znaleźć wiele adresów email, a to zwykły spam do SpamCopa wyślę, a to boty próbujące zgadnąć hasła SSH metodą bruteforce zgłoszę do blocklist.de. No i właśnie o botach atakujących SSH tym razem będzie.

Poprzedni wpis był o dziwnych wpisach w auth.log i choć już prawdopodobnie sama konfiguracja serwera powodowała zaangażowanie botów, z którego nie miały pożytku, to, jak zapowiedziałem w komentarzach,  postanowiłem pójść o krok dalej.

Otóż iptables pozwala nie tylko na odrzucenie połączenia (DROP, REJECT), ale – co prawda nie w podstawowej wersji – także na udawanie nawiązania połączenia przy pomocy TARPIT. Jeśli chodzi o szczegóły, to odsyłam do tego artykułu, a w skrócie: połączenie przychodzące do serwera jest nawiązane, dane nie są przesyłane, nie jest honorowane zakończenie połączenia, musi dojść do timeoutu po stronie klienta (bota). Czyli bot traci zasoby na komunikację, która się nie odbywa. Zużywa ich więcej, niż gdyby po stronie serwera był w iptables REJECT czy DROP.

Aby zainstalować TARPIT w Debianie, potrzebujemy źródeł kernela oraz pakietu xtables-addons-dkms. Pierwsze możemy zainstalować przez:

apt-get install linux-headers-`uname -r`

Przy okazji powinny doinstalować gadżety typu GCC, które za moment będą potrzebne. Natomiast właściwy pakiet instalujemy oczywiście przez:

apt-get install xtables-addons-dkms

Jeśli wszystko poszło OK, to zostaną zbudowane stosowne moduły dla aktualnie uruchomionego kernela i można korzystać w iptables z -j TARPIT.

Oczywiście to nie wszystko, co można zrobić z TARPIT. Inne, związane z utrudnieniem skanowania itp. można znaleźć na stronie projektu LaBrea. Polecam lekturę.

Proste rozwiązanie dla tych, którzy przenieśli SSH na inny port, niż standardowy, to utworzenie reguły:

iptables -A INPUT -p tcp -m tcp --dport 22 -j TARPIT

Wszystkie boty próbujące bruteforce na standardowym porcie 22 ugrzęzną tu na chwilkę. 😉

Linki:

  1. Slow Down Internet Worms With Tarpits
  2. LaBrea: „Sticky” Honeypot and IDS
  3. Debian TARPIT iptables How To
Opublikowane w

Rodzina Orange Pi

Jakiś czas temu zachwalałem Banana Pi. Twórcy w międzyczasie wypuścili Banana Pro, z m.in. dodaną kartą wifi. Nie pisałem, bo cena była mało atrakcyjna (obecnie wygląda lepiej ok. 50 USD), a zmiany tak naprawdę kosmetyczne.

Dziś dowiedziałem się o Orange Pi. Kolejny chiński produkt, który można określić mianem klona klonu Raspberry Pi. 😉

Poniżej zdjęcie jednej z wersji Orange Pi (wersja Mini):

Orange Pi Mini - front

Źródło: http://www.orangepi.org/orangepimini/minijieshao1.jpg

Tak naprawdę są to trzy produkty: Orange Pi zwykłe, mini i plus.

  • Zwykłe Orange Pi jest dłuższe od Banana Pi o 20 mm, za to dodatkowo ma kartę wifi oraz wyjście VGA. Cena: ok. 50 USD.
  • Orange Pi Plus ma ten sam rozmiar co zwykła wersja, nie ma wyjścia VGA, ale za to wyposażona jest w czterordzeniowy procesor A31S ARM. Brak portu SATA. Cena: ok. 70 USD.
  • Orange Pi Mini jest najbardziej zbliżone do Banana Pi – jedynie o 2 mm dłuższe i o 1 mm węższe. Od Banana Pi różni się głównie posiadaniem karty wifi. Cena: ok. 40 USD, czyli praktycznie tyle samo, co Banana Pi.

Wszystkie wersje posiadają port SATA, wszystkie mają 1 GB RAM. Producent twierdzi, że działa Android, Debian, Ubuntu itp. Ceny z AliExpress dla wersji z free shipping.

Wygląda ciekawie, choć dość niechlujnie (choćby widoczne literówki na opisach na zdjęciach). Sam pewnie nie kupię, a przynajmniej nie w najbliższym czasie, ale jakby komuś wpadło w ręce, to poproszę test i podzielenie się linkiem do testu.

UPDATE: Na portalu LinuxGizmos.com pojawiło się ciekawe zestawienie przyjaznych Linuksowi SoC na rok 2015. Polecam lekturę.

UPDATE 2: Wbrew temu, co napisałem, Orange Pi Plus nie posiada portu SATA.