Jakość niektórych narzędzi security Linuksie

Był sobie ciekawy wpis dotyczący siły haseł i narzędzi do automatycznego jej sprawdzania. Szykowałem się do dokładniejszej zabawy i testów, ale jakoś się rozeszło po kościach, więc krótko o tym, co zauważyłem.

Wnioski na temat jakości narzędzi do generowania haseł i automatycznego sprawdzania nie są zbyt optymistyczne. Narzędzia do haseł mają błędy. Smutne błędy. Spójrzmy na następujące wynik dotyczące haseł wygenerowanych przez pwgen i sprawdzanych cracklib-checki. Za każdym razem generowane było 100 tys. haseł, o zadanej długości (poczynając do 10 i kończąc na 20). Liczba podaje, ile nie było OK wg cracklib-check.

LANG=C pwgen -s -1 10 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK' 
79LANG=C pwgen -s -1 11 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
122LANG=C pwgen -s -1 12 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
16LANG=C pwgen -s -1 13 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
27LANG=C pwgen -s -1 15 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
59LANG=C pwgen -s -1 16 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
98LANG=C pwgen -s -1 17 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
141LANG=C pwgen -s -1 18 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
215LANG=C pwgen -s -1 19 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
275LANG=C pwgen -s -1 20 100000 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -cv ': OK'
373

Jak widać, ilość słabych haseł spada, osiągając minimum w okolicy dwunastoznakowych, by następnie systematycznie rosnąć. Rzut oka na generowane hasła i… wszystko jasne:

HiGFYedy6gHG: it is too simplistic/systematicnowuTUtOon4W: it is too simplistic/systematicO4rstUX43Bef: it is too simplistic/systematic1mMTsIHZyHIH: it is too simplistic/systematicSeVw3MnMnOpp: it is too simplistic/systematic

Domyślnie(?) cracklib-check uznaje powtórzenie znaków za oznakę słabego hasła. Kurtyna.

Kolejne narzędzie, które znam, lubię i którego używam często (zwykle modyfikując wynik, jednakowoż) to gpw. Okazuje się, że posiada ono brzydki błąd, który powoduje, że czasami hasło nim wygenerowane jest krótsze, niż planowaliśmy, tj. niż podane w stosownym parametrze. Przykład: 100 tys. haseł szesnastoznakowych (niby!):

gpw 100000 16 | LANG=C /usr/sbin/cracklib-check | LANG=C fgrep -v ': OK' | grep -i shortaqs: it is WAY too short

I hasło typu aqs. Jest nawet zgłoszony błąd w Debianie w tej sprawie. Też mam mieszane uczucia co do poziomu istotności błędu, ale… sprawdzanie długości otrzymanego wyniku to przecież trywialna sprawa, więc jakie inne błędy może mieć soft?

Ogólnie: mam wrażenie, że nie warto zbytnio ufać gotowym narzędziom. Może nawet nie to, żeby od razu pisać coś własnego, ale warto sprawdzić gotowce (bezpieczne! wolnoźródłowe!), nim się z nich skorzysta.

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.

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