Instalacja Fail2ban na Ubuntu 24.04

Funkcja narzędzia Fail2ban

Fail2ban to demon analizujący pliki logów. Monitoruje on komunikaty uwierzytelniania SSH. Po wystąpieniu określonej liczby nieudanych prób z jednego adresu w krótkim czasie, narzędzie wykonuje polecenie firewall, które blokuje dany adres na określony czas. To jest główna zasada działania. Konfiguracja składa się z około 30 linii w jednym pliku. W systemie Ubuntu 24.04 instalacja wymaga pojedynczej komendy apt, co zapewnia ochronę jeszcze przed dokonaniem jakichkolwiek edycji.

Należy precyzyjnie określić zakres możliwości narzędzia. Fail2ban nie przeprowadza uwierzytelniania, nie szyfruje danych i nie powstrzyma pojedynczej, zdecydowanej próby logowania. Blokuje jedynie powtarzające się próby z tego samego źródła. Narzędzie pełni funkcję filtra szumów oraz limitera częstotliwości (rate limiter), a nie zamka. Jego zadaniem jest wyeliminowanie ciągłego skanowania portu 22, co oszczędza zasoby CPU, przepustowość łącza oraz miejsce w logach. Narzędzie spowalnia również działania atakującego, który musi korzystać z jednego adresu naraz.

Czego nie zastępuje Fail2ban

Fail2ban stanowi trzecią warstwę zabezpieczeń, a nie pierwszą. Jeśli serwer nadal akceptuje hasła SSH, botnet rozproszony na tysiące adresów może kontynuować próby odczytu, ponieważ każdy adres pozostaje poniżej progu blokady i nie wyzwala jej. Skuteczną obroną jest uwierzytelnianie wyłącznie za pomocą kluczy, które uniemożliwia zgadywanie haseł niezależnie od liczby prób. Fail2ban stosowany wraz z uwierzytelnianiem kluczem zapewnia dwie korzyści: eliminuje szum ataków brute-force z logów oraz wcześnie blokuje skanery, co zapobiega nadmiernemu obciążaniu portu. Należy traktować to rozwiązanie jako obronę wielowarstwową (defence in depth). Fail2ban działa za uwierzytelnianiem kluczem oraz za firewallem, nigdy przed nimi.

Wymagania wstępne i specyfika Ubuntu 24.04

Wymagany jest serwer VPS z systemem Ubuntu 24.04, uprawnieniami root lub sudo oraz działającym protokołem SSH (zalecane uwierzytelnianie kluczem). Fail2ban zużywa mało zasobów: kilka dziesiątek megabajtów pamięci RAM; nie wymaga dostrajania limitów.

Poniżej znajduje się błąd występujący w starszych poradnikach. Przez lata standardową radą było: „zainstaluj Fail2ban, a następnie dodaj backend = systemd, ponieważ Ubuntu przestało tworzyć /var/log/auth.log”. Ta rada odnosi się do rzeczywistej zmiany — nowoczesne obrazy serwerowe i chmurowe nie zawierają rsyslog, więc logi SSH trafiają wyłącznie do systemd journal, a plik tekstowy nie istnieje. Jednak w wersji Ubuntu 24.04 pakiet Fail2ban uwzględnia już tę zmianę. Pakiet dostarcza /etc/fail2ban/jail.d/defaults-debian.conf, a to ten plik, a nie domyślne ustawienia producenta, jest używany przez serwer:

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

[sshd]
enabled = true

Należy dokładnie zapoznać się z powyższymi informacjami, ponieważ rozwiązuje to dwie kwestie przed rozpoczęciem konfiguracji. backend = systemd oznacza, że jail dla SSH odczytuje journal, więc brak auth.log nie ma znaczenia. banaction = nftables oznacza, że blokady są wymuszane przez nftables, czyli firewall faktycznie używany przez Ubuntu 24.04 zamiast przestarzałego iptables. [sshd] enabled = true oznacza, że jail jest aktywny od pierwszego uruchomienia. Wniosek: standardowy apt install fail2ban na Ubuntu 24.04 blokuje ataki brute-force na SSH od razu po instalacji. Większość prac polega na weryfikacji tego stanu, dostrojeniu polityki oraz upewnieniu się, że nie zostanie utracony dostęp do serwera.

Stara pułapka auth.log występuje w trzech sytuacjach i warto je rozpoznać: zainstalowano Fail2ban za pomocą pip zamiast apt, przez co brakuje defaults-debian.conf; pracowano wewnątrz nieuprzywilejowanego kontenera, który nie posiada systemd journal do odczytu; lub zastosowano stary poradnik i wklejono backend = auto do własnego pliku jail.local, nadpisując działające ustawienia domyślne. Sekcja dotycząca błędów opisuje dokładnie każdy z tych przypadków.

Krok 1: Instalacja i weryfikacja aktywnego blokowania

sudo apt update
sudo apt install -y fail2ban

System Ubuntu 24.044 zawiera pakiet Fail2ban 1.0.2. Pakiet ten wymaga python3-systemd jako twardej zależności, co zapewnia niezbędne wsparcie dla backendu journal. Usługa jest automatycznie aktywowana i uruchamiana:

sudo systemctl status fail2ban

Wymagane jest active (running). Następnie należy sprawdzić działającą już klatkę (jail):

sudo fail2ban-client status sshd

Na publicznym serwerze VPS, który jest dostępny w sieci od zaledwie kilku minut, często można już zaobserwować zliczone nieudane próby logowania oraz zablokowane adresy IP. Internet stale skanuje port 22. Stanowi to dowód na poprawne działanie domyślnej konfiguracji. Dalsze działania polegają na modyfikacji istniejących ustawień, a nie na tworzeniu ich od podstaw.

Step 2: Edytuj jail.local, nigdy jail.conf

Fail2ban przechowuje domyślne ustawienia w /etc/fail2ban/jail.conf. Nie należy edytować tego pliku. Każdy apt upgrade pakietu może go zastąpić, co spowoduje utratę wprowadzonych zmian bez ostrzeżenia. Fail2ban odczytuje pliki w określonej kolejności — najpierw jail.conf, następnie wszystkie pliki w jail.d/, a na końcu jail.local — ostatnia wartość ma priorytet. Plik .local należy do użytkownika i aktualizacje pakietu nigdy go nie modyfikują. Ta sama zasada dotyczy filtrów, gdzie plik *.local nadpisuje dostarczony filter.d/*.conf.

Należy utworzyć krótki jail.local, który nadpisuje tylko niezbędne ustawienia, pozostawiając pliki jail.conf oraz fabryczny jail.d/defaults-debian.conf nienaruszone jako materiały referencyjne.

Step 3: Utwórz plik /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

Wprowadź poniższą treść, zmieniając adres w linii ignoreip na własny publiczny adres IP:

[DEFAULT]
# Ubuntu 24.04 already sets these two in jail.d/defaults-debian.conf.
# Pinning them here documents the dependency and survives if that
# file is ever removed or changed by an upgrade.
backend   = systemd
banaction = nftables

# Ban for one hour ...
bantime  = 1h
# ... if an address fails ...
maxretry = 5
# ... 5 times within 10 minutes.
findtime = 10m

# Never ban these. PUT YOUR OWN IP HERE.
ignoreip = 127.0.0.1/8 ::1 10.0.0.24

# Longer bans for repeat offenders: 1h, 2h, 4h ... up to a week.
bantime.increment = true
bantime.maxtime   = 1w

[sshd]
enabled = true

Każda linia pełni określoną funkcję:

• bantime, findtime, maxretry definiują politykę. Domyślna wartość bantime wynosi dziesięć minut; zaleca się ustawienie minimum jednej godziny. Pięć nieudanych prób z jednego adresu w ciągu dziesięciu minut skutkuje blokadą. Prawdziwi użytkownicy popełniają błąd raz lub dwa; pięć prób w dziesięć minut wskazuje na skrypt.
• ignoreip służy jako zabezpieczenie. Wpisz tutaj publiczny adres, z którego się łączysz, aby Fail2ban nie zablokował dostępu do własnego serwera. W przypadku połączenia domowego ze zmiennym adresem IP zaleca się metodę VPN opisaną na końcu, ale nie należy pomijać tej linii.
• bantime.increment = true powoduje, że każda kolejna blokada jest dłuższa od poprzedniej — jedna godzina, potem dwie, potem cztery — aż do bantime.maxtime. Adresy podejrzane o powtarzające się ataki są blokowane coraz dłużej.

Aby znaleźć adres do dodania do białej listy, należy sprawdzić adres na maszynie, z której wykonujesz połączenie SSH, a nie na serwerze:

curl -s ifconfig.me

Można wygenerować plik jail.local dostosowany do portów i polityki blokowania pod tym adresem, a następnie wkleić go do pliku:

Step 4: Restart and verify it is reading the journal

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Usługa -t najpierw wykonuje test konfiguracji. Błąd w jail.local zostanie natychmiast wykryty, co zapobiega niekontrolowanemu zatrzymaniu usługi. Poprawny status jail wygląda następująco:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     14
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     3
   `- Banned IP list:   10.0.0.66

Wskaźnikiem potwierdzającym poprawne odczytywanie logowań przez Fail2ban jest wartość Total failed. Jeśli wartość ta jest większa od zera lub rośnie podczas celowych nieudanych prób logowania z innego urządzenia, dziennik (journal) jest poprawnie odczytywany. Jeśli wartość pozostaje na poziomie 0 mimo wielokrotnych nieudanych prób — przy założeniu, że testy nie są wykonywane z adresu ignoreip — należy przejść do sekcji opisującej błędy poniżej.

Należy zwrócić uwagę, że linia Journal matches nadal wskazuje na sshd.service. W systemie Ubuntu jednostka SSH to w rzeczywistości ssh.service, jednak dostarczony filtr dopasowuje również _COMM=sshd. Dodatkowo OpenSSH w wersji 24.04 loguje nieudane próby z procesu o nazwie sshd, co zapewnia poprawne dopasowanie. Ta szczegółowa informacja jest istotna tylko w przypadku nowszych wersji OpenSSH (9.8 lub nowszych, gdzie proces worker dla każdego połączenia to sshd-session); opisane błędy obejmują ten przypadek.

Step 5: Obserwacja rzeczywistej blokady lub wymuszenie blokady w celach testowych

Na dowolnym publicznym VPS rzeczywiste blokady pojawiają się automatycznie w ciągu kilku minut. Aby je monitorować, należy śledzić logi:

sudo tail -f /var/log/fail2ban.log

Blokada wygląda następująco:

2026-07-15 10:31:40,502 fail2ban.filter  [812]: INFO    [sshd] Found 10.0.0.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 10.0.0.66

Aby przetestować działanie mechanizmu bez oczekiwania, należy ręcznie zablokować adres dokumentacji — nigdy własny adres:

sudo fail2ban-client set sshd banip 10.0.0.66

Zostanie wyświetlony komunikat 1, a adres pojawi się pod Banned IP list w fail2ban-client status sshd. Następnie należy potwierdzić istnienie blokady w firewallu. W systemie Ubuntu 24.04 stosowany jest nftables, a nie iptables:

sudo nft list table inet f2b-table

Zostanie wyświetlona pula o nazwie addr-set-sshd zawierająca 10.0.0.66 oraz łańcuch f2b-chain odrzucający wszystkie źródła z tej puli. Jeśli fail2ban-client wskazuje, że adres jest zablokowany, a w nft list nie pojawiają się żadne dane, oznacza to, że akcja blokowania nie odpowiada konfiguracji firewallu — należy sprawdzić notatkę nftables/iptables w sekcji błędów.

Step 6: Odblokowanie własnego adresu oraz odzyskiwanie dostępu po blokadzie

Jeśli zablokowano nieprawidłowy adres — własny — należy go usunąć:

sudo fail2ban-client set sshd unbanip 10.0.0.66

W przypadku sukcesu zwracany jest kod 1. Aby wyczyścić wszystkie blokady we wszystkich jailach:

sudo fail2ban-client unban --all

Nie należy polegać na trwającej sesji SSH: nftables odrzuca każdy pakiet z zablokowanego adresu do portu 22 — w tym połączenia typu established — co powoduje zawieszenie istniejącej sesji w momencie nałożenia blokady. Jeśli zablokujesz własny adres i nie posiadasz wpisu ignoreip, utracisz dostęp do systemu do czasu wygaśnięcia blokady. W takim przypadku należy odzyskać dostęp poprzez konsolę webową dostawcy (VNC lub serial), która nie korzysta z protokołu SSH, a następnie odczekać do wygaśnięcia bantime lub uruchomić komendę odblokowania w tej konsoli.

Step 7: Utrwalanie i eskalacja blokad

Fail2ban przechowuje aktywne blokady w małej bazie danych SQLite w /var/lib/fail2ban/fail2ban.sqlite3, dzięki czemu pozostają one aktywne po restarcie usługi lub ponownym uruchomieniu systemu; dane nie zostają utracone. Dodane wcześniej linie bantime.increment powodują eskalację blokad dla powtarzających się sprawców — czas trwania blokady rośnie dwukrotnie, od jednej godziny do około jednego tygodnia.

Aby wdrożyć ogólnosystemową politykę „trzech ostrzeżeń”, Fail2ban udostępnia jail recidive, który monitoruje własny /var/log/fail2ban.log i nakłada długotrwałe blokady na adresy wielokrotnie blokowane we wszystkich jailach. Ponieważ [DEFAULT] korzysta obecnie z backendu systemd, należy przypisać ten jail z powrotem do pliku dziennika, który jest przeznaczony do odczytu:

[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

Użycie backend = auto wraz z jawnie zdefiniowanym logpath sprawia, że recidive nadal odczytuje zwykły fail2ban.log, gdzie faktycznie pojawiają się linie Ban — domyślna konfiguracja systemd ustawiona globalnie wskazywałaby na journal, w którym te linie nie występują.

Krok 8: Połączenie z SSH opartym wyłącznie na kluczach lub VPN

Fail2ban jest skuteczny tylko przy uwierzytelnianiu za pomocą kluczy. W pliku konfiguracyjnym w /etc/ssh/sshd_config.d/ — na przykład /etc/ssh/sshd_config.d/00-hardening.conf — należy ustawić:

PasswordAuthentication no
KbdInteractiveAuthentication no

Następnie należy wykonać sudo systemctl restart ssh. Po wyłączeniu haseł ataki brute force stają się całkowicie nieskuteczne; wtedy Fail2ban służy jedynie do redukcji szumu w logach i wczesnego blokowania skanerów. Jeszcze skuteczniejszą metodą jest całkowite odcięcie SSH od publicznego internetu: umieszczenie SSH za własnym VPN WireGuard oraz zablokowanie portu 22 w firewallu, aby odpowiadał tylko wewnątrz tunelu. Portu, który jest nieosiągalny, nie można zaatakować metodą brute force, dzięki czemu Fail2ban staje się zabezpieczeniem dodatkowym, a nie pierwszą linią obrony.

Fail2ban nie służy wyłącznie do SSH. Każda usługa logująca nieudane próby logowania może posiadać jail — serwer poczty, witrynę nginx lub samodzielny menedżer haseł Vaultwarden, którego logowanie webowe nie powinno być narażone na ataki credential stuffing. Gdy aplikacja webowa działa za witryną nginx z certyfikatem Let's Encrypt, należy skierować filtr Fail2ban na jej log access, analogicznie do sposobu, w jaki jail dla SSH wskazuje na journal.

Failure modes, with the exact strings you will see

"Have not found any log file for sshd jail", and Fail2ban will not start. This is the old auth.log problem, and on Ubuntu 24.04 you only hit it if something has overridden the packaged default — a pip install with no defaults-debian.conf, a container with no journal, or a stray backend = auto you pasted into jail.local. On a file backend with no /var/log/auth.log, the sshd jail cannot find its log and the whole daemon aborts. fail2ban.log shows:

ERROR   Failed during configuration: Have not found any log file for sshd jail

Because that error is fatal, the service never comes up, and fail2ban-client status then reports the downstream symptom:

ERROR  Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?

That "socket path" line does not mean Fail2ban is broken — it means it never started because one jail could not find its log. Setting backend = systemd in [DEFAULT], which the Ubuntu package already does for you, fixes both messages at once.

Jail is active but Total failed never moves. The daemon is running and the journal is being read, yet real failures pile up in journalctl -u ssh while the counter sits at 0. First rule out the obvious: you are testing from an address listed in ignoreip, so your own failures are exempt by design. If that is not it, you are on an OpenSSH build where the per-connection worker is sshd-session (9.8 and later), whose journal _COMM is sshd-session, not sshd, so the shipped match misses it. Widen the match in the [sshd] block:

[sshd]
enabled      = true
backend      = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

Restart, fail a login on purpose from an address not in ignoreip, and confirm Total failed finally climbs.

You banned yourself: Connection refused. You left your own address out of ignoreip, tested a few bad logins, and now:

ssh: connect to host 10.0.0.10 port 22: Connection refused

The refusal, rather than a silent timeout, is the nftables action's default reject verdict doing its job — on you. Fix it as in Step 6: unban from a session on a different, unbanned address, or from the provider console — a session already open from the banned address freezes too. Then add your address to ignoreip so it cannot happen again.

Fail2ban says an address is banned, but it can still connect. The counter in status sshd rises, yet the address still reaches port 22. This is a ban-action-versus-firewall mismatch, and on Ubuntu 24.04 it almost always means you overrode the working banaction = nftables with banaction = iptables-multiport copied from an older guide, on a box with no iptables layer. fail2ban.log shows:

fail2ban.actions [812]: ERROR  Failed to execute ban jail 'sshd' action 'iptables-multiport'

Delete that override and let the packaged nftables action stand, or, if you manage the firewall entirely through ufw and want bans to show up there, set banaction = ufw in [DEFAULT]. Restart and confirm the rule appears with sudo nft list ruleset | grep f2b.

Fail2ban will not start after editing jail.local. A typo — a stray heading or a bad time value — makes the service refuse to come up. Ask Fail2ban to check the config before it runs:

sudo fail2ban-client -t

It names the file and the jail with the problem, for example Errors in jail 'sshd'. Skipping..., so you fix the source rather than guessing.

FAQ

Czy domyślna instalacja Fail2ban na Ubuntu 24.04 faktycznie blokuje ataki SSH?

Tak. Pakiet zawiera /etc/fail2ban/jail.d/defaults-debian.conf, co aktywuje jail sshd, ustawia backend = systemd, aby odczytywać systemd journal zamiast nieistniejącego /var/log/auth.log, oraz ustawia banaction = nftables, aby blokady były egzekwowane przez natywny firewall systemu Ubuntu. Standardowy apt install fail2ban chroni SSH od pierwszego uruchomienia. Można to potwierdzić za pomocą sudo fail2ban-client status sshd, sprawdzając, czy wartość Total failed jest większa od zera.

Dlaczego Fail2ban nie blokuje niczego na moim serwerze?

Należy wykluczyć trzy powszechne przyczyny w podanej kolejności. Możliwe, że testujesz połączenie z adresu w ignoreip, który jest domyślnie wykluczony. Możesz nadpisać działające ustawienia domyślne, wklejając backend = auto do jail.local z nieaktualnego poradnika, co uniemożliwia odczyt journala na obrazie bez auth.log. Możesz również znajdować się wewnątrz kontenera, który nie posiada journala systemd do odczytu. Sprawdź Total failed w fail2ban-client status sshd: jeśli wartość nie rośnie, podczas gdy journalctl -u ssh wykazuje rzeczywiste błędy, jail odczytuje niewłaściwe miejsce.

Jak odblokować własny adres IP?

Uruchom sudo fail2ban-client set sshd unbanip YOUR.IP.HERE, co zwróci 1 w przypadku sukcesu, lub sudo fail2ban-client unban --all, aby wyczyścić wszystkie blokady. Jeśli utracisz dostęp przez SSH, użyj konsoli webowej lub VNC dostawcy, aby uruchomić tę samą komendę — blokada odrzuca każdy pakiet z Twojego adresu na port 22, więc nawet aktywna sesja zostanie przerwana. Następnie dodaj swój adres do ignoreip, aby zapobiec ponownemu zablokowaniu.

Jaka jest różnica między jail.conf a jail.local?

jail.conf zawiera domyślne ustawienia źródłowe Fail2ban i jest nadpisywany podczas każdej aktualizacji pakietu, więc wszelkie edycje w tym pliku zostaną utracone. Pakiet Debian/Ubuntu nakłada własne ustawienia poprzez jail.d/defaults-debian.conf. Własne zmiany należy umieszczać w jail.local, który jest odczytywany jako ostatni i ma pierwszeństwo przed pozostałymi, a aktualizacje nigdy go nie modyfikują. Plik jail.conf należy traktować wyłącznie jako dokumentację.

Czy Fail2ban zastępuje uwierzytelnianie SSH za pomocą kluczy?

Nie. Fail2ban ogranicza częstotliwość powtarzających się błędów z jednego adresu; nie chroni przed wolnymi, rozproszonymi atakami typu brute-force, gdzie każdy adres pozostaje poniżej progu. Uwierzytelnianie wyłącznie kluczami (PasswordAuthentication no) całkowicie uniemożliwia zgadywanie haseł, natomiast Fail2ban redukuje szum w logach i wcześnie usuwa skanery. Zaleca się stosowanie obu metod oraz całkowite wyłączenie dostępu SSH z publicznego internetu.