Nie zablokujesz Tora…

Krótkie przypomnienie: około pół roku temu pisałem, jak zablokować węzły wyjściowe Tora. Lista węzłów wyjściowych (exit nodes) Tora jest publiczna, więc wygląda, że mamy sielankę.

Logo Tor

Źródło: https://media.torproject.org/image/official-images/2011-tor-logo-flat.svg

Tymczasem dziś podczas rozmowy w gronie administratorów padło stwierdzenie od osoby, która badała ruch w sieci Tor, że podczas swoich eksperymentów zarejestrowała ruch z węzłów wyjściowych, których nie było na liście. Metodyka badania prosta jak budowa cepa: wyślij znane żądanie przez Tora do swojego hosta, zapisz IP z którego nadeszło połączenie, porównaj z listą exit nodes.

I wtedy mnie olśniło. Dla pewności zapytałem jeszcze na kanale IRC poświęconym Torowi czy nie ma jakiejś weryfikacji i… jak najbardziej jest to wykonalne. Po prostu jako exit node listowany jest IP, który jest podłączony do sieci Tor. Wystarczy więc, że maszyna ma więcej niż jedno IP lub przekierowuje ruch na inną maszynę (choćby iptables) i… połączenia Tor będą widoczne z nielistowanego adresu. Co więcej, może się on zmieniać w czasie…

Usłyszałem nawet znamienne zdanie na kanale: założę się, że są exit node’y, które po prostu wysyłają ruch przez VPN.  I to by było tyle w temacie prostych, błędnych odpowiedzi na pozornie proste pytania…

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ł…

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ć.