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

Dziwne wpisy w auth.log, czyli coś nowego na SSH

Jedną z maszynek mam wystawioną do netu z SSH na standardowym, 22 porcie[1]. Głównie w celu zbierania śmieci (i zgłaszania ich do blocklist.de). Zerknąłem na /var/log/auth.log i zobaczyłem masę nietypowych wpisów typu:

Jan  8 19:41:28 xxx sshd[32002]: Connection closed by 195.130.253.159 [preauth]Jan  8 19:46:52 xxx sshd[32298]: Connection closed by 195.130.253.159 [preauth]Jan  8 19:52:16 xxx sshd[32645]: Connection closed by 195.130.253.159 [preauth]

Są to jedyne wpisy w logach dotyczące tych IP. IP jest stosunkowo niewiele, połączenia zwykle co kilka minut. Brak śladów po próbie logowania. Wydaje mi się, że wcześniej tego nie było, przynajmniej nie aż tyle. Logi mam od 7 grudnia, wygląda, że zjawisko zaczęło się w okolicy 11 grudnia, a apogeum miało miejsce na przełomie roku:

zegrep -h "Connection closed by .*preauth" /var/log/auth.log* | awk '{print $1" "$2}' | sort | uniq -c | sort -n      1 Dec 11      1 Dec 12      1 Dec 21      1 Dec 8      2 Dec 18      4 Dec 17     10 Dec 26     19 Dec 16     43 Dec 14     75 Dec 22    150 Jan 4    155 Jan 8    159 Dec 24    209 Dec 15    214 Dec 27    267 Jan 5    303 Jan 7    360 Dec 28    381 Jan 3    445 Dec 29    446 Jan 6    717 Dec 30    905 Jan 2   1041 Jan 1   1132 Dec 31

Jeśli chodzi o rozkład IP, to na moim serwerze wygląda to następująco (tylko ponad 100 wystąpień prezentuję):

zegrep -h "Connection closed by .*preauth" /var/log/auth.log* | awk '{print $9}' | sort | uniq -c | sort -n | egrep "[0-9][0-9][0-9]    113 128.199.252.25    147 121.78.147.217    159 195.154.226.100    358 195.130.253.159    416 118.98.43.33    684 37.187.119.89   1378 76.74.157.51   1416 112.216.92.44   1883 112.107.2.154

Kolejnych 13 IP ma powyżej 10 wystąpień.

Jeśli chodzi o kraje, to raczej malware’owy standard (dla >10 wystąpień):

zegrep -h "Connection closed by .*preauth" /var/log/auth.log* | awk '{print $9}' | sort | uniq -c | sort -n | egrep "[0-9][0-9] " | awk '{print $2}' | xargs -L1 geoiplookup | sort | uniq -c | sort -n      1 GeoIP Country Edition: AR, Argentina      1 GeoIP Country Edition: AT, Austria      1 GeoIP Country Edition: GB, United Kingdom      1 GeoIP Country Edition: ID, Indonesia      1 GeoIP Country Edition: IT, Italy      1 GeoIP Country Edition: NL, Netherlands      1 GeoIP Country Edition: RU, Russian Federation      2 GeoIP Country Edition: FR, France      2 GeoIP Country Edition: IP Address not found      3 GeoIP Country Edition: CN, China      3 GeoIP Country Edition: KR, Korea, Republic of      5 GeoIP Country Edition: US, United States

Ktoś się orientuje o co chodzi? Jakiś nowy atak? Błąd w skryptach od bruteforce w którymś botnecie?

UPDATE Dzięki pomocy ludzi z #z3s udało się ustalić, że tego typu wpisy w logach pojawią się, jeśli nawiąże się połączenie tylko w celu pobrania obsługiwanych sposobów szyfrowania (i rozłączy się po ich otrzymaniu). Nie tłumaczy to oczywiście, czemu połączenia się powtarzają. Padła sugestia, że może jakiś głupi bot wykłada się na nietypowej konfiguracji – host nie ma domyślnego konfiga SSH, tylko wdrożone zalecenia z bettercrypto.org (polecam, swoją drogą).

[1] Ponieważ było to pierwsze pytanie, jakie dostałem, to dopiszę: tak, celowo, tak nie mam tu innego portu/fail2ban/knockd, choć każda z tych metod pewnie eliminuje 99% skanów. Jestem świadomy możliwości nie oglądania tego typu rzeczy, ale tu chcę je widzieć.