Jak nie zainstalowałem Google Hangouts w Debianie Wheezy

Z własnej nieprzymuszonej woli bym z Google Hangouts nie skorzystał, bo jeśli już muszę korzystać z niewolnych wynalazków, to mam Skype od Microsoftu, ale w pracy była potrzeba skontaktowania się grupowo, grupa już ma wybrane rozwiązanie i używa Hangouts, więc… co może pójść źle? System to Debian Wheezy plus backporty, czyli nic nietypowego czy niestabilnego. Skype od Microsoft daje gotową paczkę deb, co prawda multiarch, a nie natywne amd64, ale działa bez problemu, po dodaniu architektury i386. Google ma opinię firmy bardziej przyjaznej Linuksowi, poza tym na rynek weszli później, więc pewnie bardziej się starają.

Oczywiście wszedłem na stronę Google Hangouts z Iceweasel, czyli Firefoksa. Są wersje dla mobilków, jest pobierz na swój komputer. Klikam… i komunikat, że ta przeglądarka się nie nadaje, pobierz sobie Chrome. Czyli nie wersja Hangouts na komputer, tylko jako dodatek do przeglądarki. Pod pewnymi względami może to mieć nawet sens, zresztą mam Chromium (opensource’owa wersja Chrome), co mi szkodzi wrzucić tam Hangouts? Odpalam Chromium, strona Google Hangouts i… link do wersji „stacjonarnej” nie jest aktywny.

No dobrze, wiem, że dają działającą paczkę z Chrome, więc chociaż nie potrzebuję tej przeglądarki, to mogę ją zainstalować i tylko do tego jednego celu mogę jej używać. Instalacja Chrome bez problemu (nie, nie będzie domyślną przeglądarką w systemie…), wchodzę na stronę Hangouts, dodał appkę. Uruchamiam i… chat działa, ale w momencie kliknięcia rozmowy video (znaczy audio/video, samego audio chyba się nie da, choć by wystarczyło…) nie uruchamia jej w Chrome, tylko… próbuje uruchomić w Iceweasel, który jest domyślną przeglądarką. Tym razem jednak proponuje pobranie pluginu w postaci paczki deb. Nie można tak było od razu? Pobieram oferowany plugin, instaluję i…

dpkg: problemy z zależnościami uniemożliwiają skonfigurowanie pakietu google-talkplugin:
google-talkplugin zależy od libc6 (>= 2.14); jednakże:
Wersją libc6:amd64 w systemie jest 2.13-38+deb7u8.

Brawo Google!

Źródło: http://gifrific.com/wp-content/uploads/2012/04/joker-clap-hq.gif

Oczywiście problemu pewnie by nie było, gdyby Chrome był domyślną przeglądarką w systemie, ale nie ze mną te numery, Brunner^HGoogle. Skończyło się odinstalowaniem i Chrome, i nieszczęsnego pluginu na podstawowym systemie. Oczywiście za tydzień problemu pewnie nie będzie, bo najprawdopodobniej Jessie będzie stable, ale póki co – nie da się w rozsądny sposób korzystać z Hangouts pod stabilnym Debianem.

Oczywiście z tym nie zainstalowałem z tytułu lekko przesadzam[1], bo nie kijem go, to pałką i skończyło się szybkim postawieniem osobnej wirtualki (AQEMU, KVM) tylko pod Hangouts. Ale faktem jest, że w podstawowym systemie poległem.

Pozytyw całej akcji jest taki, że przetestowałem instalator Jessie (rc2). Jest parę fajnych opcji, choćby wybór, które dokładnie środowisko chcemy zainstalować (jest LXDE i działa w zasadzie od kopa – jedyna rzecz, która wymagała interwencji to wyciszony mikrofon – musiałem doinstalować jakiś xfce4-mixer, który chyba zresztą jakoś nie zapamiętuje ustawień. Potem się przyjrzę dokładniej, podobnie jak udostępnieniu wbudowanej kamery do wirtualki…

[1] Pierwotnie w tytule nie było nic o wersji Debiana.

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