terminal

LINUX ADMIN7

Strona główna / Baza Wiedzy / Bezpieczeństwo

Fail2Ban Best Practices: Twoja tarcza przed atakami Brute-Force

Kompletny przewodnik ekspercki po zabezpieczaniu infrastruktury Linux przed atakami słownikowymi i automatycznymi botami skanującymi.

person Autor: Ekspert LINUXADMIN7 schedule Czas czytania: 15 min update 28.01.2026
Server hardware in dark room with red lighting

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.

# Linux # Security # Fail2Ban # Sysadmin