Jako administratorzy systemów Linux, codziennie stajemy w szranki z tysiącami zautomatyzowanych botów, które niestrudzenie pukają do naszych drzwi SSH, paneli administracyjnych i usług webowych. Ignorowanie logów pełnych nieudanych prób logowania to proszenie się o kłopoty. Tu właśnie na scenę wkracza Fail2Ban – narzędzie stare jak świat (w skali IT), ale wciąż niezastąpione, o ile wiemy, jak je odpowiednio skonfigurować.
Natura ataków Brute-Force w 2024 roku
Współczesne ataki to już nie tylko proste skrypty "admin/admin". To rozproszone botnety, które potrafią rotować setkami adresów IP, by zmylić standardowe progi blokowania. Jeśli Twój serwer jest widoczny w sieci publicznej, gwarantuję Ci, że w tej sekundzie ktoś próbuje odgadnąć Twoje hasło SSH. Fail2Ban działa jako warstwa pośrednia między logami Twoich usług a systemowym firewallem (iptables, nftables), dynamicznie reagując na anomalie.
Fundament: Instalacja i `jail.local`
Zasada numer jeden: Nigdy nie edytuj pliku /etc/fail2ban/jail.conf. Jest on nadpisywany podczas aktualizacji pakietu. Zawsze twórz własny plik konfiguracyjny jail.local.
# Instalacja na Debian/Ubuntu
sudo apt update && sudo apt install fail2ban -y
# Tworzenie pliku konfiguracyjnego
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local
W pliku jail.local powinniśmy zdefiniować globalne parametry, które będą dziedziczone przez poszczególne "jaile" (więzienia):
[DEFAULT]
# Ignoruj mój domowy adres IP (kluczowe!)
ignoreip = 127.0.0.1/8 ::1 192.168.1.100
# Czas blokady (im więcej, tym lepiej)
bantime = 1h
# Okno czasowe, w którym liczymy próby
findtime = 10m
# Dopuszczalna liczba błędów
maxretry = 5
# Używamy nftables zamiast iptables (nowoczesny standard)
banaction = nftables-multiport
Hardening SSH: Pierwsza linia obrony
SSH jest najczęstszym celem. Nawet jeśli używasz kluczy RSA/ED25519, warto blokować boty, by nie marnowały zasobów Twojego procesora na procesy uwierzytelniania.
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 24h
Zwróć uwagę na bantime = 24h. Dla SSH polecam agresywne podejście – jeśli ktoś pomylił się 3 razy w ciągu 10 minut, prawdopodobnie nie jest Twoim pracownikiem.
Praktyka: Konfiguracja Nginx i Apache: Walka z Vulnerability Scanners
Jail: Serce systemu
Boty często skanują serwery WWW w poszukiwaniu plików .env, wp-login.php czy config.php. Możemy to łatwo wyłapać, monitorując błędy 404 lub 403.
Dla Nginx:
[nginx-http-auth]
enabled = true
filter = nginx-http-auth
port = http,https
logpath = /var/log/nginx/error.log
[nginx-botsearch]
enabled = true
port = http,https
logpath = /var/log/nginx/access.log
filter = nginx-botsearch
maxretry = 2
Custom Filters: Kiedy standard to za mało
Prawdziwa moc Fail2Ban tkwi w filtrach Regex. Jeśli Twoja aplikacja zapisuje błędy logowania w specyficzny sposób, stwórz filtr w /etc/fail2ban/filter.d/moja-apka.conf:
[Definition] failregex = ^<HOST> - .* "POST /login .* 401 ignoreregex =
Ten prosty wzorzec wyłapie wszystkie próby logowania (POST), które zakończyły się kodem 401 (Unauthorized).
Podsumowanie i Monitoring
Fail2Ban to nie "set and forget". Raz w tygodniu sprawdź stan swoich więzień: fail2ban-client status sshd. Zobaczysz tam listę aktualnie zbanowanych adresów IP oraz ogólne statystyki. Pamiętaj, że bezpieczeństwo to proces, a Fail2Ban to jeden z najważniejszych trybów w Twojej maszynie.