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?