Jakiś czas temu uruchamiałem kolejny serwer z zamysłem używania go wyłącznie jako storage (backup). Przez kilka tygodni serwer był nieużywany, ale cały czas podłączony do publicznej sieci.
Aż tydzień temu, gdy inne maszyny były już skonfigurowane pod nowym serwer zapasowy spojrzałem w dzienne logi maszyny. Naprawdę mocno się zdziwiłem, gdy zobaczyłem, że do serwera, który nic nie oferuje poza SSH, nie zaistniał w Sieci, nagle każdego dnia są tysiące prób logowań na użytkownika root oraz po kilkaset na losowe generowane nazw kont.
Dopiero po chwili przypomniałem sobie, że od lat korzystam z fail2ban i jest to jedna z pierwszych paczek, które instaluję po zainstalowaniu systemu (Debian, apt-get install fail2ban).
1 lutego paczka została doinstalowana. W domyślnej konfiguracji, kontroluje wyłącznie port 22 (SSH). Jeśli w ciągu 600 sekund (findtime) zostanie wykonanych 5 prób połączeń (maxretry) to nastąpi wycięcie ruchu dla tego adresu IP na 3600 sekund (bantime).
To wystarczyło, aby ilość prób otworzenia SSH dla TOP 3 adresów IP spadła z 6-20k do raptem 0.3-0.5k.
Oczywiście zainstalowanie fail2ban nie zwalnia nas z zadbania o dobrą konfigurację serwera SSH. Powinniśmy wyłączyć możliwość logowania na użytkownika root, wymagać uwierzytelnienia po kluczach i można również zmienić domyślny port SSH. A na koniec najlepiej zezwalać na ruch tylko via VPN 😉 .
Sam fail2ban nie służy tylko do konfigurowania reguł dla SSH, ale ma gotowe schematy dla m.in. apache, dovecot, nginx, postfix czy proftpd.
Ale dla innych usług radzę dwa razy się zastanowić i przejrzeć konfigurację reguły zanim włączycie domyślną konfigurację, ponieważ np. nasza aplikacja web może wykonywać dużo jednoczesnych zapytań i powodować zablokowanie niewłaściwych adresów IP.