Fail2Ban na VPS — konfiguracja ochrony przed brute-force
Opublikowano: 8 kwietnia 2026 · Kategoria: Bezpieczeństwo
Każdy serwer VPS podłączony do internetu jest atakowany przez boty skanujące porty i próbujące złamać hasła SSH metodą brute-force. Fail2Ban to daemon bezpieczeństwa, który monitoruje logi systemowe i automatycznie blokuje podejrzane adresy IP przez iptables — zanim zdążą złamać hasło.
Instalacja Fail2Ban
# Ubuntu / Debian sudo apt update && sudo apt install fail2ban -y # CentOS / Rocky Linux / AlmaLinux sudo dnf install epel-release -y && sudo dnf install fail2ban -y # Uruchom i włącz przy starcie systemu sudo systemctl enable --now fail2ban # Sprawdź status sudo fail2ban-client status
Podstawowa konfiguracja — jail.local
Nigdy nie edytuj /etc/fail2ban/jail.conf — zostanie nadpisany przy aktualizacji.
Utwórz /etc/fail2ban/jail.local:
[DEFAULT] # Czas blokady (sekundy): 1 godzina bantime = 3600 # Okno czasowe dla liczenia prób findtime = 600 # Ile nieudanych prób przed blokadą maxretry = 5 # Twoje stałe IP - NIGDY nie blokuj ignoreip = 127.0.0.1/8 ::1 YOUR.OFFICE.IP.HERE # Backend logów (auto = najlepsza opcja) backend = auto [sshd] enabled = true port = ssh # Jeśli zmieniłeś port SSH np. na 2222: # port = 2222 logpath = %(sshd_log)s maxretry = 3 bantime = 86400
Po każdej zmianie konfiguracji: sudo systemctl restart fail2ban.
Ochrona nginx przed brute-force HTTP
[nginx-http-auth] enabled = true port = http,https logpath = /var/log/nginx/error.log maxretry = 5 [nginx-limit-req] enabled = true port = http,https logpath = /var/log/nginx/error.log maxretry = 10 [nginx-botsearch] enabled = true port = http,https logpath = /var/log/nginx/access.log maxretry = 2
Ochrona WordPress (wp-login.php)
Utwórz filtr /etc/fail2ban/filter.d/wordpress.conf:
[Definition]
failregex = ^<HOST> .* "POST .*wp-login\.php
^<HOST> .* "POST .*xmlrpc\.php
ignoreregex =
Dodaj jail do /etc/fail2ban/jail.local:
[wordpress] enabled = true port = http,https filter = wordpress logpath = /var/log/nginx/access.log maxretry = 5 bantime = 3600
Zarządzanie blokadami
# Status wszystkich jailów sudo fail2ban-client status # Status konkretnego jaila (lista zablokowanych IP) sudo fail2ban-client status sshd sudo fail2ban-client status wordpress # Odblokowanie IP (np. gdy zablokowałeś siebie) sudo fail2ban-client set sshd unbanip 1.2.3.4 # Ręczne zablokowanie IP sudo fail2ban-client set sshd banip 192.168.1.100 # Podgląd logów w czasie rzeczywistym sudo tail -f /var/log/fail2ban.log # Test filtra (czy dopasowuje logi) sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf
Porównanie poziomów ochrony SSH
| Metoda | Trudność | Skuteczność | Uwagi |
|---|---|---|---|
| Fail2Ban (domyślna) | Łatwa | Dobra | Blokuje po N próbach |
| Zmiana portu SSH | Łatwa | Ograniczona | Ukrywa przed skanerami portów |
| Klucze SSH (bez haseł) | Średnia | Bardzo dobra | Brute-force niemożliwy |
| Fail2Ban + klucze SSH | Średnia | Doskonała | Rekomendowane połączenie |
| AllowUsers w sshd_config | Łatwa | Dobra | Tylko określeni użytkownicy |
Dobre praktyki bezpieczeństwa
- Zawsze dodaj swój stały IP do ignoreip — aby nie zablokować siebie przy błędzie
- Używaj kluczy SSH zamiast haseł — w połączeniu z Fail2Ban to najlepsza ochrona
- Zmień domyślny port SSH (np. na 2222) — zmniejsza szum w logach
- Monitoruj logi Fail2Ban —
/var/log/fail2ban.logpokaże wzorce ataków - Ustaw długi bantime dla SSH — 24h lub więcej dla powtarzających się IP
- Chroń też xmlrpc.php — często atakowany endpoint WordPress