Tag: security

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

All your GSM numbers are belong to us!

Zaczęło się od wpisu Montera o skopanej wysyłce MMS do wielu osób. Long story short: jeśli wiadomość MMS jest wysyłana do kilku osób, to odbiorcy widzą wszystkie numery, na które została wysłana. Analogicznie jak przy wielu odbiorcach w polu To lub Cc w przypadku email (zamiast Bcc).

Telefon komórkowy

Źródło: http://www.publicdomainpictures.net/view-image.php?image=692

Moja teza jest jednak taka, że zjawisko, choć złe, nie jest aż tak tragiczne, na jakie wygląda. Odbiorca dostaje co prawda listę numerów z książki adresowej, ale nie wie do kogo należą i czy w ogóle działają. Może jedynie porównać tę listę ze znanymi sobie numerami i ustalić, jakich mają wspólnych znajomych. Albo zrobić brute force i dzwonić wszędzie (hell yeah, automaty tak robią podobno…).

Całe zdarzenie jest dla mnie porównywalne z listą PINów wszystkich ludzi na świecie (tak, wasz też tam jest, mój zresztą też), jeśli chodzi o naruszenie prywatności czy bezpieczeństwa. Postanowiłem więc zrobić listę wszystkich polskich numerów komórkowych. W trakcie tworzenia, już po pierwszym prefiksie zwątpiłem – plik miał około 100 MB surowych danych, do tego tagi HTML…

Zatem zamiast ryby – wędka i zestaw DIY do stworzenia listy wszystkich polskich numerów GSM. Na podstawie listy polskich prefiksów GSM przypisanych operatorom i odrobiny magii w Perlu, każdy może sobie wygenerować taką listę.

Blox nie lubi nawiasów ostrych, więc wklejka na zewnętrznym serwisie:

Całość działa tak długo, dopóki Wikipedia nie zmieni formatu publikowania artykułów. Klepnięte na kolanie, nieoptymalizowane w żaden sposób. U mnie wygenerowanie wszystkich numerów ww. skryptem trwa od dwóch do czterech minut. Have fun!

PS Wygląda, że w Polsce może być 110300000 numerów telefonów komórkowych. Nie odliczam niewykorzystanych prefiksów itp.

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