Otwarte SSH i walka z robotami

Dzisiaj z ciekawości przeprowadziłem analizę logów (auth.log) na jednym z serwerów, chciałem przekonać się czy boty próbują się logować, zgadywać hasła, skąd są, oraz które loginy najbardziej są narażone na atak. Opierając się na stosunkowo małej próbce (21 marzec – 24 kwiecień), spróbowałem wygrzebać trochę informacji…

# grep -c ‘Apr 23.*Failed password’ /var/log/auth.log
7546

Statystyka z wczoraj (23 kwietnia) mówi, że nieudanych prób logowania było 7546… czyli średnio co 11 sekund… Wziąłem więc wszystkie logi z ponad miesiąca i zrobiłem kilka zestawień.

Łączna ilość nieudanych logowań: 84974

Zestawienie 10 loginów na które było najwięcej prób logowania (liczba z lewej to ilość prób):

24281  root
730    oracle
705    test
559    admin
351    user
306    webmaster
306    guest
231    nagios
226    webadmin
199    postgres

Sprawdźmy skąd było najwięcej takich prób:

35454  212.106.195.103 Spain
4673   110.45.144.120 Republic of Korea
4000   121.119.164.56 Japan
2068   202.75.221.232 China
1891   210.35.88.61 China
1553   222.35.137.146   China
1068   203.192.171.186  Philippines
986    121.131.210.92   Republic of Korea
850    89.146.41.95     Netherlands
729    84.243.245.210   Netherlands

W moim przypadku wygrała Hiszpania?!? a zaraz za nią Korea, Japonia i Chiny…

Zmierzam do tego, żeby zadbać, by hasła dla użytkowników w systemie były naprawdę silne, widać, że roboty próbują logować się zarówno na użytkowników związanych z usługami (oracle, nagios, postgres) jak i systemowych (root), ciekawy jest użytkownik test ;-) ciekawy jestem ilu z Was się przyzna, że ma takiego usera w systemie z hasłem typu test123? albo dupa.8? ;-) w tym momencie nie wiem jakie hasła były podawane, ale korci mnie, żeby delikatnie zmodyfikować sshd i zacząć je również logować ;-) prawdopodobnie będą to tylko jakieś słownikowe wyrazy, ale kto wie… ;-) Jeśli ktoś nie potrafi się zmusić do używania silnych haseł, polecam zatrudnić do tego zadania starego i sprawdzonego cracklib‘a, najlepiej spinając go z pam’em który przed ustawieniem hasła sprawdzi je i podpowie, czy jest silne, czy możemy je lepiej sobie darować.

W przypadku gdyby ktoś chciał zniwelować liczbę prób nieudanych logowań może skorzystać z ciekawego narzędzia Sshguard, które podpięte do syslog’a na bieżąco analizuje nieudane próby logowania i podejmuje akcję zablokowania danego IP na firewallu. Implementacja jest bardzo prosta i szybka:

Instalacja sshguard’a (Ubuntu):

# apt-get install sshguard

Następnie konfiguracja syslog-ng (w przypadku gdyby ktoś używał innego loggera, na tej stronie znajdzie gotowy przepis):

filter f_sshguard { facility(auth, authpriv) and not program(„sshguard”); };
destination sshguard { program(„/usr/sbin/sshguard” template(„$DATE $FULLHOST $MSGHDR$MESSAGEn”)); };
log { source(s_all); filter(f_sshguard); destination(sshguard); };

• filter f_sshguard – tworzymy filtr o nazwie f_sshguard, uwzględniający poziom logowania facility oraz auth, bez ciągu znaków „sshguard”
• destination – określamy sposób logowania zdarzenia, w tym przypadku nie zapisuje danych nigdzie do pliku, ale wywołujemy program /usr/sbin/sshguard z parametrami data, pełny host, oraz treść komunikatu
• log – spinamy w całość filtr + destination, biorąc jako źródło logów s_all, czyli wszystkie znane źródła komunikatów (/dev/log)

Mając taki wpis możemy wykonać, reload syslog-ng:

# /etc/init.d/syslog-ng reload
* Reload system logging syslog-ng

Kolejny krok to skonfigurowanie systemowego firewall’a, w Linuksie będzie to Iptables, zgodnie z dokumentacją wykonujemy:

# iptables -N sshguard
# ip6tables -N sshguard

Właśnie utworzyliśmy nowe łańcuchy (zarówno dla IPv4 jak i IPv6), przypnijmy teraz je do naszego INPUT’a:

# iptables -A INPUT -j sshguard
# ip6tables -A INPUT -j sshguard

Domyślne wartości dla sshguarda:

• blokada po 4 nieudanych próbach zalogowania
• czas blokowania – 420 sekund
• czas po którym sshguard zapomni o potencjalnym adresie IP do zablokowania – 1200 sekund

Przetestujemy jak to działa:

Apr 24 18:36:22 katha sshd[3449]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=macbook  user=root
Apr 24 18:36:24 katha sshd[3449]: Failed password for root from 192.168.1.168 port 62690 ssh2
Apr 24 18:36:24 katha sshguard[3290]: Matched IP address 192.168.1.168
Apr 24 18:36:31 katha sshd[3449]: Failed password for root from 192.168.1.168 port 62690 ssh2
Apr 24 18:36:31 katha sshguard[3290]: Matched IP address 192.168.1.168
Apr 24 18:36:31 katha sshguard[3290]: Blocking 192.168.1.168: 4 failures over 28 seconds.
Apr 24 18:36:31 katha sshguard[3290]: Setting environment: SSHG_ADDR=192.168.1.168;SSHG_ADDRKIND=4;SSHG_SERVICE=100.
Apr 24 18:36:31 katha sshguard[3290]: Run command „case $SSHG_ADDRKIND in 4) exec /sbin/iptables -A sshguard -s $SSHG_ADDR -j DROP ;; 6) exec /sbin/ip6tables -A sshguard -s $SSHG_ADDR -j DROP ;; *) exit -2 ;; esac”: exited 0.

4 próby nieudane w ciągu 28 sekund i zostaliśmy odcięci:

root@katha:/home/jamzed# iptables -n -L sshguard
Chain sshguard (2 references)
target     prot opt source               destination
DROP       all  –  192.168.1.168        0.0.0.0/0

Przed użyciem polecam zapoznać się z opcjami sshguarda, bo zawsze warto dodać w pierwszej kolejności swoje IP do whitelisty ;-)

A Wy jakimi narzędziami monitorujecie serwery? zwracacie uwagę na to kto i kiedy próbuje się logować do systemu? czy może preferujecie -j DROP/REJECT od razu na SSH i tylko ACCEPT dla konkretnych IP?

Bądź na bieżąco, dodaj nas do RSSów:


Podobne wpisy:

• Apache walczy ze spamem
• Szyfrujemy transmisję HTTP / Apache 1.3.37 + SSL
• Odciążanie apache przez mod_evasive
• Tunelowanie ssh
• Zabezpieczamy nasz kontent przed hotlinkowaniem
• Marcowe spotkanie OWASP – PHP [video]

oceń artykuł (4 gł., średnia: 5,00)

 Dziekujemy za glos. ...