Tag: admin

Opublikowane w

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

Opublikowane w

Testowanie szybkości kluczy Zabbix agenta

Było tak, że jeden z kluczy w Zabbiksie działał wolno. Nawet: bardzo wolno. Ile czasu może się wykonywać proste sprawdzenie wersji programu typu chef-client -v, nawet na umiarkowanie dobitym systemie? Zainteresowani znajdą odpowiedź na końcu wpisu[1], dość powiedzieć, że czasami załączał się timeout po stronie zabbix agent. Problem został rozwiązany w sposób najdoskonalszy, czyli poprzez zrzucanie wartości z crona do pliku, i czytanie jej z pliku, ale niesmak pozostał. Poza niesmakiem, pozostało pytanie które jeszcze klucze są nieoptymalne?

Ponieważ na ten moment Zabbix nie daje możliwości sprawdzenia statystyk czasu zapytań dla poszczególnych kluczy, wykonałem małą protezę w postaci skryptu w Perlu, który odpyta danego hosta o wszystkie klucze kilka(naście) razy i policzy dla nich statystyki. Wklejka poniżej.

 

Skrypt przyjmuje dokładnie jeden parametr – hosta na którym będzie przeprowadzać test. Poza tym, wymaga wszystkich kluczy dla danego hosta, które ma testować, w pliku określonym w zmiennej $file. Na końcu wyświetli łączny czas wykonania zdefiniowanej ilości zapytań dla każdego klucza wyrażony w sekundach oraz sam klucz. Czytaj: pewnie chcesz przepuścić wynik przez sort -n. 😉

Parę rzeczy, które wyszły w trakcie pisania tego skryptu lub których się nauczyłem (w sumie gdyby nie one, to nie powstałby ten wpis):

Pętla sprawdzające N razy wszystkie klucze po kolei jest dokładniejsza od pętli, która sprawdza kolejno wszystkie klucze N razy każdy. Chodzi o rozkład obciążanie na maszynie, w tym drugim przypadku jest większa szansa, że któryś klucz trafi w nietypowe obciążenie maszyny.

Dokumentacja do modułu Time::HiRes jest… taka sobie. Można to zrobić prościej, jak wyżej. Początkowo kombinowałem ze sprintf oraz clock_gettime(CLOCK_REALTIME);

Może zastanawiać, skąd mnożenie przez 1000000. Otóż chodzi o bug z zapisem liczb zmiennoprzecinkowych (kojarzyłem to raczej z ośmiobitowców i dzielenia, nie wiem czy słusznie…):

perl -e '$a=1415907504.646884; $b=1415907504.603042; $d=$a-$b; print $d,$/'

vs.

perl -e '$a=1415907504.646884*1000000; $b=1415907504.603042*1000000; $d=($a-$b)/1000000; print $d,$/'

Że tak zacytuję real programmers use integer. 😉

Na koniec niezła wiadomość: jest szansa, że w przyszłości Zabbix będzie miał coś w stylu MySQLowego slowloga, czyli nie będzie trzeba robić testów na poszczególnych hostach, tylko będzie wbudowane narzędzie do wykrywania wolnych zapytań. Można głosować na ten feature. 😉

Specjalne podziękowania za uwagi i wyjaśnienia dla Tona z #perl @ IRCnet (thanks Ton!).

I wracając do pytania o nieoptymalne klucze z początku wpisu – tylko nieszczęsny chef-client okazał się być czarną owcą. Pozostałe klucze, choć czasem wymagają uruchomienia Perla lub kilku poleceń w Bashu, wykonywały się w zdecydowanie przyzwoitym czasie, grubo poniżej sekundy.

[1] Wykonuje się nawet cbanq cvęganśpvr frxhaq (rot13)! Bo na tyle ustawiony był timeout…

Opublikowane w

Blokada exit nodes Tora

Dawno temu pisałem o walce z Tor. Odsyłałem tam do strony, na której można sprawdzić, czy IP jest węzłem wyjściowym Tora, jest też stronka z listą węzłów. Niestety, stronka popełnia częsty błąd i wrzuca wszystkie węzły do jednego wora, zarówno węzły wyjściowe (exit node) jaki pośredniczące (relay node). Niestety, błąd ten później pokutuje, bo taki admin, który chce wyciąć exit nodes bierze, nie patrzy, nie rozumie i… wycina np. moje domowe IP, choć z Tora się do jego serwera nie łączę, tylko dorzucam parę groszy do projektu przerzucając czyjś ruch.

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

Ponieważ potrzebowałem (no dobrze, ja jak ja…) listę węzłów wyjściowych na niezupełnie swoje potrzeby, zrobiłem własną listę. Tylko IP i tylko węzły wyjściowe. Idealne do automatycznego przetwarzania.

Dane brane są z z oficjalnej strony projektu Tor ( https://check.torproject.org/exit-addresses). Aktualizacja odbywa się raz na godzinę o pełnej godzinie (nie ma sensu pytać częściej). Jakby było zainteresowanie i potrzeba, to mogę zwiększyć częstotliwość. Mi wystarcza.

Plik dostępny jest po HTTP i HTTPS pod tym adresem: Tor exit node IP list. Udostępniam as is, bez żadnych gwarancji działania, dostępności, kompletności czy poprawności danych czy braku złośliwych danych. Jak widać wisi to na darmowej domenie, co może mieć dotyczące zawartości. You get what you pay for. 😉

Zresztą ogólnie korzystanie z tego typu automatycznych źródeł bez jakiejś weryfikacji uważam za nierozsądne.

UPDATE: Metoda nie jest doskonała. O tym, że część exit nodes może nie być widocznych przeczytasz tutaj.