Mumble, czyli alternatywa dla TeamSpeak

Powody dla powstania wpisu są dwa. Po pierwsze, pogrywam sobie czasem w World of Tanks, ostatnimi czasy niekoniecznie sam, a częściej w plutonie. Oczywiście można grać przy pomocy porozumiewania się wbudowanym chatem, czyli pisząc i używając wbudowanych komend i tak długi czas z K. graliśmy, ale przyszedł M. i namówił nas na zorganizowanie mikrofonów i słuchawek. I faktycznie, w przypadku komunikacji głosowej fun jest nieporównywalnie większy.

Korzystaliśmy z wbudowanego w grę mechanizmu, który wymaga wciśnięcia klawisza, jeśli chce się coś powiedzieć. Wykonalne, ale palców jest ograniczona ilość i w czasie gry mają lepsze zajęcia, niż obsługa głosu. Zdarza się, że się zapomni o wciśnięciu klawisza czy po prostu nie ma czasu go wcisnąć. I komunikat ginie.

Trochę zaczęliśmy myśleć o alternatywach. Ostatecznie gracze z jakiegoś powodu korzystają z TeamSpeaka… W klanie K. jako system komunikacji głosowej obowiązywał nie TeamSpeak, ale Mumble, którego nazwa zupełnie nic mi nie mówiła.

Logo Mumble

Źródło: https://en.wikipedia.org/wiki/File:Icons_mumble.svg

Rzuciłem okiem i okazało się, że jest natywna wersja linuksowa, a software to open source. I tu drugi powód powstania wpisu: TeamSpeak jest dostępny (zarówno klient, jak i serwer) na Linuksa, ale nie jest open source i dostarczana jest binarka. Tylko dla architektur i386 oraz amd64 w Debianie. Niedawno na kanale IRC ktoś pytał o tego typu chat grupowy z możliwością uruchomienia serwera na procesorze ARM. Mumble jako open source oczywiście jest dostępne także na architektury armel oraz armhf. Poza tym, lubię testować alternatywy.

Zainstalowałem serwer (można ograniczyć dostęp hasłem, domyślna konfiguracja jest prosta i wystarczająca do uruchomienia…), choć można skorzystać z serwerów publicznych. W konfiguracji serwera można też zgłosić swój serwer do katalogu publicznych.

Instalacja klienta jest równie prosta, jedyne co trzeba zrobić, to wyskalować dźwięk przy pomocy wizarda. Klient ma trzy metody włączania nadawania: non-stop (mikrofon cały czas „zbiera” – średnio wygodne dla reszty uczestników), znana z WoT aktywacja klawiszem oraz tryb najlepszy, czyli aktywacja głosem. I po to jest kalibracja, żeby przy odpowiednim natężeniu dźwięku (czyli gdy coś mówimy) klient zaczynał transmisję, ale nie zbierał cały czas tła.

Najważniejsze cechy Mumble:

  • szyfrowana komunikacja (domyślnie)
  • niskie opóźnienie
  • open source
  • wieloplatformowość (Linux, Windows, OS X)
  • niskie wymagania zasobów (serwer; jest nawet wersja serwera dla OpenWrt)
  • usuwanie echa
  • pozycjonowane audio (słychać z którego kierunku mówi osoba)
  • in-game overlay (jest wyświetlane, kto mówi)

Z ostatnich trzech nie korzystam, bo – kolejno – gramy na słuchawkach, nie ma potrzeby/nie zauważyłem, zupełnie nie mam potrzeby. Jeśli chodzi o jakość dźwięku i opóźnienie jestem bardzo zadowolony (póki co testowane na dwóch osobach na kanale, większą ilością się nie zebraliśmy). Jakość dźwięku lepsza zarówno niż w WoT, jak i na Skype (skoro VoIP porównujemy). Nie wiem na ile w tym zasługi łącz, a na ile klienta, ale jeśli tylko wszyscy w plutonie mają zainstalowanego klienta Mumble, to korzystamy z tego rozwiązania. Polecam.

Więcej o Mumble można poczytać na angielskiej stronie Wikipedii. Ale nie ma co czytać, trzeba instalować. 😉

101 filmów czyli VOD i promocja Żywca

W sklepie zobaczyłem na opakowaniu Żywca 1 piwo = 1 film, co przesądziło o zakupie. Może nie miałem wielkiej ochoty na Żywca, ale uchodzi, a stwierdziłem, że dawno nie zaglądałem na portale VOD. Ostatnio jak patrzyłem, to dominowała chała i nie działało pod Linuksem. Stwierdziłem, że w najgorszym wypadku dam kody znajomym, ale pewnie i tak znajdą się jakieś filmy, które można zobaczyć, najwyżej nie na podstawowym kompie.

Zatem kupiłem czteropak. Wizyta na portalu 101filmow.pl, żeby zobaczyć co dają i upewnić się, że na Linuksie nie zadziała. Jeśli chodzi o pierwszą część, to miło się rozczarowałem oferowanym repertuarem. Filmy zdecydowanie do obejrzenia – i trochę w miarę nowych, i trochę klasyki, i parę ambitniejszych. Jeśli chodzi o część drugą, to przeczytałem wymagania, nic o Linuksie nie znalazłem (ani o wymogu Windows), ale gdzieś mignęło mi, że część filmów nie działa na platformach mobilnych. Czyli jakieś ciężkie DRM, czyli zapomnij o Linuksie. Potem doczytałem na vod.pl, że wymagany jest Windows. Oczywiście planowałem zgłosić błąd (skoro na 101filmow.pl nic nie piszą, że na Linuksie nie działa), ale później okazało się, że część filmów (bez zabezpieczeń) działa.

Jednak nie uprzedzajmy faktów. Zarejestrowałem konto (na jakiś tymczasowy adres), wklepałem kody. Nawet fajnie rozwiązane. Jedyny zgrzyt, który się pojawił to termin ważności kodów do 28. lutego. No c’mon… Drugi zgrzyt to 48h na obejrzenie. Niby dużo i pewnie chodzi o to, by nie dzielić się kodami zanadto, ale… inne mam wymagania już. Na jeden wieczór może film się nie zmieścić, drugiego coś może wypaść… 72h to IMHO minimum, no dobra, 50h. 😉

Na pierwszy rzut poleciał Jak zostać królem, który kiedyś widziałem (a młoda nie). Po włączeniu pierwsze rozczarowanie: nie można wybrać wersji innej, niż z lektorem dostarczonej przez wydawcę. Znaczy: nic nie można wybrać; jak jest lektor, to jest lektor i kropka, jak napisy (rzadkość), to napisy. Ejże, to już nawet chyba na wszystkich(?) kanałach jest, przynajmniej z satki… Druga sprawa: jakość. Pomiarów jeszcze nie robiłem, ale wygląda to na ekranie komputera, jak… kiedyś na telewizorze kineskopowym, czyli okolice PAL. Okolice 480p na YouTube. Jak na dzisiejsze czasy – trochę słabo. Tym bardziej, że net przyzwoity (realnie ~15-20 Mbps do kompa), więc spokojnie weszłoby w znacznie lepszej rozdzielczości.

Najgorsze jednak okazał się zaciachy. Pierwszy w piątej, minucie, kolejny w ósmej. Wkurzyłem się, zrestartowałem przeglądarkę i… pomogło, a raczej, prawie pomogło, bo jeszcze jedna ścinka pod koniec była. Następnego dnia sprawdziłem pod Linuksem i… film też działał. Nie trzeba mieć Silverlighta, wystarczy Flash… Na dodatek się nie ciął. Z innymi filmami było podobnie. Nie wiem czy kwestia serwisu, czy systemu, czy np. ilości wolnego miejsca na dysku (jest mało, rzędu 2 GB). Jeśli nawet to ostatnie, to oczekiwałbym informacji o niewystarczających zasobach od odtwarzacza… Uznam jednak (brzytwa Ockhama), że to wina systemu.

Ogólnie mam mieszane uczucia. Z jednej strony darowanemu koniowi w zęby się nie zagląda, z drugiej bardzo średni produkt dają, jak na dzisiejsze czasy. Najbardziej chyba obowiązkowy lektor mnie rozczarował. Ogólnie: 4/10.

UPDATE: Włoski dla początkujących już nie działa pod Linuksem, czyli na 101filmow.pl nie wszystkie są „przyjazne” – Flash nie starczy, trzeba mieć Silverlight. Za to zaciachów na nim nie stwierdzono (póki co, bo to połowa).

UPDATE2: Niektóre filmy jakby lepiej wyglądają, więc może opinia o jakości była pochopna. Niektóre płatne filmy są poprzedzone reklamą. Spotkałem raz, krótka i nienachalna reklama filmu Hiszpanka w kinie, ale jednak. Last but not least – część filmów na vod.pl jest dostępna za darmo, bez żadnych kodó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