Docker.io Debian Jessie HOWTO

Parę dni temu pojawiła się nowa wersja Debiana o nazwie Jessie. O upgrade i drobnych i niedrobnych perypetiach napiszę innym razem, dziś krótkie rozwiązanie problemu, który pojawia się dość często na IRCu. Chodzi o to, że pakiet docker.io nie jest dostępny w Jessie. A ludzie chcą dockera używać. Widzę trzy rozwiązania:

1. Pobranie pakietu docker.io w wersji dla Debiana unstable.

Rozwiązanie najprostsze, ale potencjalnie najbardziej problematyczne. Wchodzimy na https://packages.debian.org/sid/docker.io wybieramy architekturę, następnie mirror, pobieramy paczkę deb (akualnie jest to docker.io_1.3.3~dfsg1-2_amd64.deb). Instalujemy ją w systemie, mniej lub bardziej ręcznie spełniając zależności.

2. Dodanie repozytoriów unstable w systemie oraz odpowiedni pinning pakietów.

Po pierwsze czytamy dokładnie i ze zrozumieniem jak działa pinning pakietów (man apt_preferences), żeby nagle nie zaktualizowało systemu do unstable, albo nie pomieszało pakietów ze stable i unstable przy spełnianiu zależności. Następnie dodajemy wpisy dla unstable w sources.list. Aktualizujemy listę pakietów i docker.io powinien być dostępny do instalacji.

3. Samodzielnie robimy backport pakietu docker.io dla Jessie.

Wersja najdoskonalsza, bo nie robi bałaganu związanego z mieszaniem wersji stable i unstable w systemie. Po pierwsze zaopatrujemy się w debianowe źródła pakietu. Można dodać wpisy deb-src dla unstable w sources.list, zaktualizować listę pakietów. Następnie:

cd /usr/srcwajig source docker.iocd docker.io-1.3.3~dfsg1/wajig builddepends docker.iodpkg-buildpackage
cd ..
wajig install docker.io_1.3.3~dfsg1-2_amd64.deb

W tym momencie powinniśmy mieć zainstalowanego dockera w systemie. Nie sprawdzałem, czy działa, ale zarówno metoda druga jak i trzecia powodują, że pakiet instaluje się czysto, więc raczej będzie działać. Przykłady dla wersji 1.3.3, być może z czasem może się coś zmienić.

Mój uptime

Już od jakiegoś czasu zastanawiałem się nad włączeniem monitoringu dla rosnącej liczby moich gratów w sieci. Do tej pory korzystałem z premedytacją głównie z gotowych serwisów typu Blox czy Jogger, ale ostatnio coraz więcej rzeczy jest zależnych tylko ode mnie. Niby niekrytyczne, ale… lubię, jak działa. A zdarzyło mi się, że po restarcie serwera nie wszystkie usługi działały – niby drobiazg, nie wstał varnish[1], ale efekty opłakane – statystyki nie działały.

Oczywiście mogłem podpiąć się pod monitoring w firmie (Zabbix), ale mało eleganckie, i ogólnie nie lubię mieszania gratów służbowych z prywatnymi. Mogłem też odpalić coś prostego swojego (nawet ze sprawdzaniem na krzyż, albo i w trójkącie), ale… trochę overkill, podobnie jak stawianie własnego Zabbiksa. Poza tym, na pewno nie miałoby to ładnego frontendu (chyba, że Zabbix). W ogóle pewnie nie miałoby frontendu. 😉

Stwierdziłem, że poszukam, bo na pewno są gotowe serwisy. Wymagania były proste:

  • darmowe
  • obsługa min. 5 hostów w darmowej wersji
  • prosta rejestracja i używanie
  • wsparcie dla IPv6
  • monitoring hostów (ping) oraz stron WWW

Owszem, są gotowe serwisy. Nawet sporo. Na tyle sporo, że miałem problem z decyzją. Prawie się zdecydowałem na monitor.us, ale zapytałem znajomych i… nikt nic nie umiał powiedzieć. Temat umarł śmiercią naturalną.

Przynajmniej na jakiś czas, bo niedawno zobaczyłem ten wpis i… dałem szansę serwisowi Uptime Robot. W sumie polecany na zestawieniu 10 darmowych serwisów do monitoringu stron WWW, więc pewnie go widziałem, ale jakoś nie zwróciłem uwagi. Ma wszystko co wyżej, na tle konkurencji wyróżnia się dużą liczbą sprawdzanych hostów/usług w wariancie darmowym (50) oraz stosunkowo wysoką częstotliwością sprawdzeń (co 5 minut), więc nada się nawet do więcej niż czysto amatorskich/prywatnych zastosowań.

Dashboard wygląda tak:

Uptime Robot dashboard

Kolejna wyróżniająca cecha to bycie darmowym jako podstawa, nie jako doklejka – serwis powstał jako darmowy z założenia, wersja płatna została dorobiona później, dla tych, którzy jednak potrzebują więcej. Wygląda więc, że nie zniknie nagle, nie zacznie proponować nachalnie płatnej wersji czy wymagać klikania linków co miesiąc…

A tak wygląda wykres dla pojedynczego hosta (ten z przerwą):

Uptime Robot wykres dla hosta

Uptime Robot umie powiadamiać o awarii mailem (tak właśnie korzystam, w końcu to prywatne graty) oraz dodatkowo przez IM (Twitter) oraz SMS (z tych metod nie korzystam). Metodę powiadomień ustawia się dla każdego hosta indywidualnie, więc można mieć ważne i ważniejsze, pilne i pilniejsze. Sprawdzać można działanie strony, obecność zadanej treści na stronie, odpowiedź hosta na ping oraz status otwarcia portu. Jak na serwis darmowy – więcej niż wystarczające. Do tego całość jest schludna i prosta. Polecam.

[1] Zachciało mi się usprawnień i optymalizacji… W top wyglądało OK – mysql był, lighttpd był…

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