Fail2ban na Ubuntu 24.04: ochrona SSH

Co faktycznie robi Fail2ban

Fail2ban to demon odczytujący logi. Monitoruje komunikaty uwierzytelniania SSH i po kilku nieudanych próbach z jednego adresu w krótkim przedziale czasu wykonuje polecenie zapory sieciowej, które tymczasowo blokuje ten adres. Na tym polega jego działanie. Konfiguracja obejmuje około trzydziestu wierszy w jednym pliku, a w systemie Ubuntu 24.04 instalacja wymaga wykonania tylko jednego polecenia apt, po czym ochrona działa jeszcze przed wprowadzeniem jakichkolwiek zmian.

Należy jasno określić, czym Fail2ban jest, a czym nie jest. Fail2ban nie uwierzytelnia użytkowników, nie szyfruje danych i nie zatrzymuje pojedynczej, celowej próby logowania. Zatrzymuje tylko powtarzające się próby pochodzące z tego samego źródła. Jest filtrem szumu i mechanizmem ograniczania liczby prób, a nie blokadą. Jego zadaniem jest zatrzymanie ciągłego skanowania portu 22 w tle, które niepotrzebnie zużywa procesor, przepustowość sieci i miejsce na logi, oraz spowolnienie atakującego, który musi wykonywać próby kolejno z pojedynczych adresów.

Czego Fail2ban nie zastępuje

Fail2ban jest trzecią warstwą zabezpieczeń, a nie pierwszą. Jeśli serwer nadal akceptuje hasła SSH, botnet rozproszony na tysiącach adresów może nadal przeprowadzać próby logowania, ponieważ każdy adres pozostaje poniżej progu blokady i nigdy go nie przekracza. Rzeczywistą ochronę przed takim atakiem zapewnia uwierzytelnianie wyłącznie za pomocą kluczy, które uniemożliwia zgadywanie haseł niezależnie od liczby podejmowanych prób. Fail2ban używany razem z uwierzytelnianiem wyłącznie za pomocą kluczy zapewnia dwie korzyści: usuwa z dzienników szum generowany przez ataki brute-force oraz wcześnie odrzuca skanery, aby przestały obciążać port. Należy traktować go jako element ochrony wielowarstwowej. Działa za uwierzytelnianiem za pomocą kluczy i za zaporą sieciową, a nie przed nimi.

Wymagania wstępne i rzeczywistość Ubuntu 24.04

Wymagany jest VPS z systemem Ubuntu 24.04, dostępem do konta root lub sudo oraz działającym SSH, najlepiej z uwierzytelnianiem za pomocą klucza. Fail2ban zużywa niewiele zasobów: kilkadziesiąt megabajtów pamięci RAM, bez konieczności dostrajania limitów.

Teraz kwestia, w której starsze poradniki regularnie podają nieprawidłowe informacje. Przez lata standardowa porada brzmiała: „zainstaluj Fail2ban, a następnie dodaj backend = systemd, ponieważ Ubuntu przestało zapisywać /var/log/auth.log”. Ta porada opisuje rzeczywistą zmianę: współczesne obrazy serwerowe i obrazy chmurowe są dostarczane bez rsyslog, dlatego SSH zapisuje logi wyłącznie w dzienniku systemd, a ten plik tekstowy nie istnieje. Jednak w Ubuntu 24.04 pakiet Fail2ban już to uwzględnia. Pakiet dodaje plik /etc/fail2ban/jail.d/defaults-debian.conf. To właśnie ten plik, a nie ustawienia domyślne projektu upstream, określa konfigurację faktycznie używaną przez serwer:

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

[sshd]
enabled = true

Należy przeczytać to uważnie, ponieważ wyjaśnia to dwie kwestie przed wprowadzeniem jakichkolwiek zmian. backend = systemd oznacza, że jail SSH odczytuje dziennik, dlatego brak pliku auth.log nie ma znaczenia. banaction = nftables oznacza, że blokady są egzekwowane przez nftables, czyli zaporę faktycznie używaną przez Ubuntu 24.04, a nie przez starszy mechanizm iptables. [sshd] enabled = true oznacza, że jail jest włączony od pierwszego uruchomienia systemu. Wniosek jest następujący: standardowa instalacja apt install fail2ban w Ubuntu 24.04 blokuje próby brute-force SSH bez dodatkowej konfiguracji. Większość pracy polega na potwierdzeniu tego stanu, dostrojeniu zasad oraz upewnieniu się, że dostęp do serwera nie zostanie zablokowany.

Stara pułapka związana z auth.log nadal występuje w trzech sytuacjach. Warto je rozpoznać: Fail2ban został zainstalowany za pomocą pip zamiast apt, dlatego nie ma defaults-debian.conf; używany jest nieuprzywilejowany kontener bez dostępnego dziennika systemd; albo zastosowano stary poradnik i wklejono backend = auto do własnego jail.local, zastępując działające ustawienie domyślne. Sekcja dotycząca trybów awarii dokładnie pokazuje, jak wygląda każda z tych sytuacji.

Krok 1: Zainstaluj usługę i potwierdź, że już blokuje

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 zawiera Fail2ban 1.0.2, a pakiet pobiera python3-systemd jako twardą zależność, więc backend dziennika systemowego ma wszystko, czego potrzebuje. Usługa włącza się i uruchamia automatycznie:

sudo systemctl status fail2ban

Oczekiwany jest stan active (running). Następnie należy sprawdzić więzienie, które już wykonuje swoje zadanie:

sudo fail2ban-client status sshd

Na publicznym VPS, który jest dostępny z sieci choćby od kilku minut, często widać już zliczone nieudane próby i zablokowane adresy. Internet stale skanuje port 22. Potwierdza to, że domyślna konfiguracja działa. Od tego miejsca jest ona dopracowywana, a nie tworzona od podstaw.

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

Fail2ban przechowuje domyślne ustawienia dostawcy w pliku /etc/fail2ban/jail.conf. Nie należy edytować tego pliku. Każda apt upgrade pakietu może go zastąpić, a wprowadzone zmiany znikną bez ostrzeżenia. Fail2ban odczytuje pliki w ustalonej kolejności: najpierw jail.conf, następnie wszystkie pliki w jail.d/, a na końcu jail.local. Obowiązuje ostatnia wartość. Plik .local jest przeznaczony do własnych ustawień, a aktualizacje pakietu nigdy go nie modyfikują. Ta sama zasada dotyczy filtrów: plik *.local zastępuje dostarczony plik filter.d/*.conf.

Należy więc utworzyć niewielki plik jail.local, który zastępuje tylko kilka potrzebnych ustawień, a pliki jail.conf i dostarczony w pakiecie jail.d/defaults-debian.conf pozostawić niezmienione jako punkt odniesienia.

Krok 3: Utworzenie pliku /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

Wstaw poniższą zawartość. Zmień adres w wierszu 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żdy wiersz ma określone zastosowanie:

• bantime, findtime, maxretry definiują zasady. Domyślna wartość dostarczana w bantime wynosi tylko dziesięć minut. Rozsądne minimum to godzina. Pięć nieudanych prób z jednego adresu w ciągu dziesięciu minut powoduje blokadę. Rzeczywisty użytkownik może raz lub dwa razy błędnie wprowadzić hasło. Pięć nieudanych prób w ciągu dziesięciu minut wskazuje na działanie skryptu.
• ignoreip stanowi zabezpieczenie. Należy umieścić tutaj publiczny adres, z którego nawiązywane jest połączenie, aby Fail2ban nie mógł zablokować dostępu do własnego serwera. Zmienny adres IP połączenia domowego jest powodem, aby na końcu wybrać podejście z VPN, a nie powodem do pominięcia tego wiersza.
• bantime.increment = true powoduje, że każda kolejna blokada trwa dłużej: najpierw godzinę, następnie dwie godziny, a potem cztery, maksymalnie do bantime.maxtime. Adresy, z których następują kolejne próby połączenia, są stopniowo blokowane na coraz dłuższy czas.

Adres do dodania do białej listy należy sprawdzić na komputerze, z którego nawiązywane jest połączenie SSH, a nie na serwerze:

curl -s ifconfig.me

Można tutaj wygenerować jail.local dostosowany do używanych portów i zasad blokowania, a następnie wkleić go do pliku:

Krok 4: Ponowne uruchomienie i sprawdzenie odczytu dziennika

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

-t najpierw przeprowadza test konfiguracji, dlatego literówka w jail.local powoduje tutaj wyraźny błąd, zamiast pozostawić usługę wyłączoną. Prawidłowy 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

Liczba potwierdzająca, że Fail2ban rzeczywiście odczytuje logowania, to Total failed. Jeśli jest większa od zera lub zwiększa się po celowym nieudanym logowaniu z innej maszyny, dziennik jest odczytywany i konfiguracja jest zakończona. Jeśli pozostaje równa 0 niezależnie od liczby nieudanych prób oraz jest pewne, że test nie jest wykonywany z adresu w ignoreip, należy przejść do opisanych poniżej trybów awarii.

Należy zwrócić uwagę, że wiersz Journal matches nadal wskazuje sshd.service. W Ubuntu jednostką SSH jest faktycznie ssh.service, ale dostarczony filtr dopasowuje również _COMM=sshd, a OpenSSH w wersji 24.04 zapisuje nieudane próby z procesu o nazwie sshd, dlatego dopasowanie działa. Ma to znaczenie tylko w przypadku nowszej wersji OpenSSH (9.8 lub nowszej, w której proces roboczy dla poszczególnych połączeń to sshd-session); opisane tryby awarii obejmują ten przypadek.

Krok 5: Obserwowanie rzeczywistej blokady lub wymuszenie jej w celu testu

Rzeczywiste blokady pojawiają się samoczynnie w ciągu kilku minut na każdym publicznym VPS. Aby obserwować blokadę, wyświetlaj końcowe wpisy dziennika:

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 sprawdzić działanie całego mechanizmu bez oczekiwania, zablokuj ręcznie adres używany w dokumentacji. Nigdy nie blokuj własnego adresu:

sudo fail2ban-client set sshd banip 10.0.0.66

Zostanie wyświetlony komunikat 1, a adres pojawi się w sekcji Banned IP list w fail2ban-client status sshd. Następnie potwierdź, że reguła blokady rzeczywiście istnieje w zaporze. W Ubuntu 24.04 jest to nftables, a nie iptables:

sudo nft list table inet f2b-table

Widoczny będzie zbiór o nazwie addr-set-sshd zawierający 10.0.0.66 oraz łańcuch f2b-chain, który odrzuca każde źródło znajdujące się w tym zbiorze. Jeśli fail2ban-client informuje, że adres jest zablokowany, ale nic nie pojawia się w nft list, działanie blokujące nie odpowiada konfiguracji zapory. Zobacz uwagę dotyczącą nftables/iptables w sekcji dotyczącej trybów awarii.

Krok 6: Usuń własną blokadę i odzyskaj dostęp po odcięciu

Jeśli zablokowano adres, który nie powinien być zablokowany, w tym własny adres, należy go odblokować:

sudo fail2ban-client set sshd unbanip 10.0.0.66

Po pomyślnym wykonaniu polecenie zwraca 1. Aby usunąć wszystkie blokady ze wszystkich więzień:

sudo fail2ban-client unban --all

Nie należy polegać na już otwartej sesji SSH: blokada w nftables odrzuca każdy pakiet z zablokowanego adresu do portu 22, w tym pakiety należące do ustanowionych połączeń. Istniejąca sesja zostaje zatrzymana natychmiast po nałożeniu blokady. Po zablokowaniu własnego adresu, jeśli nie ma wpisu ignoreip, dostęp zostaje utracony do czasu wygaśnięcia blokady. Należy wtedy odzyskać dostęp za pośrednictwem konsoli internetowej dostawcy (VNC lub port szeregowy), która nie korzysta z SSH, a następnie zaczekać na wygaśnięcie bantime albo wykonać tam polecenie odblokowania.

Krok 7: Utrwalanie blokad i eskalacja

Fail2ban przechowuje aktywne blokady w małej bazie SQLite w lokalizacji /var/lib/fail2ban/fail2ban.sqlite3, dzięki czemu pozostają one aktywne po ponownym uruchomieniu usługi lub systemu; nie zostaną utracone. Dodane wcześniej wiersze bantime.increment powodują, że każde powtórne naruszenie skutkuje coraz dłuższą blokadą, wydłużając ją mniej więcej dwukrotnie od jednej godziny do około jednego tygodnia.

Aby dodatkowo zastosować ogólnosystemową zasadę „trzech ostrzeżeń”, Fail2ban udostępnia jail recidive, który monitoruje własny /var/log/fail2ban.log i nakłada długie blokady na każdy adres wielokrotnie zablokowany we wszystkich jailach. Ponieważ [DEFAULT] korzysta teraz z backendu systemd, należy ponownie przypisać ten jail do pliku dziennika, z którego został zaprojektowany do odczytu:

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

backend = auto z jawnym logpath powoduje, że recidive nadal odczytuje zwykły fail2ban.log, w którym rzeczywiście pojawiają się zliczane przez niego wiersze Ban; ustawiona globalnie domyślna konfiguracja systemd wskazywałaby dziennik systemowy, w którym tych wierszy nie ma.

Krok 8: Połączenie z uwierzytelnianiem SSH tylko za pomocą kluczy, a najlepiej z VPN

Fail2ban jest skuteczny tylko w połączeniu z uwierzytelnianiem za pomocą kluczy. W pliku konfiguracyjnym umieszczonym 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 sudo systemctl restart ssh. Po wyłączeniu haseł atak brute force nie może się powieść. Fail2ban służy wtedy do ograniczania liczby wpisów w logach i wczesnego blokowania skanerów. Jeszcze lepszym rozwiązaniem jest całkowite odseparowanie SSH od publicznego Internetu: umieścić SSH za samodzielnie hostowanym VPN WireGuard i skonfigurować zaporę tak, aby port 22 odpowiadał tylko w tunelu. Nie można przeprowadzić ataku brute force na port, do którego nie ma dostępu. Fail2ban pełni wtedy funkcję dodatkowego zabezpieczenia, a nie podstawowej ochrony.

Fail2ban nie służy wyłącznie do ochrony SSH. Każda usługa rejestrująca nieudane logowania może mieć własne jail: serwer pocztowy, witryna nginx lub samodzielnie hostowany menedżer haseł Vaultwarden, którego logowania internetowego nie należy pozostawiać bez ochrony przed próbami użycia wykradzionych danych uwierzytelniających. Gdy aplikacja internetowa działa za witryną nginx z certyfikatem Let's Encrypt, należy wskazać filtr Fail2ban dla jej logu dostępu, tak samo jak jail SSH wskazuje dziennik systemowy.

Tryby awarii z dokładnymi komunikatami, które zostaną wyświetlone

„Have not found any log file for sshd jail” i Fail2ban nie uruchamia się. Jest to stary problem auth.log. W Ubuntu 24.04 występuje tylko wtedy, gdy coś zastąpiło domyślną konfigurację pakietu, zainstalowano pip bez defaults-debian.conf, kontener nie ma dziennika lub przypadkowo wklejono backend = auto do jail.local. W przypadku zaplecza plikowego bez /var/log/auth.log jail sshd nie może znaleźć dziennika i cały demon kończy działanie. fail2ban.log wyświetla:

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

Ponieważ ten błąd ma charakter krytyczny, usługa nie uruchamia się. Następnie fail2ban-client status zgłasza objaw wtórny:

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

Wiersz dotyczący „ścieżki gniazda” nie oznacza, że Fail2ban jest uszkodzony. Oznacza, że usługa nie uruchomiła się, ponieważ jeden z jaili nie mógł znaleźć dziennika. Ustawienie backend = systemd w [DEFAULT], które pakiet Ubuntu konfiguruje już domyślnie, usuwa oba komunikaty jednocześnie.

Jail jest aktywny, ale Total failed nie zmienia wartości. Demon działa, a dziennik jest odczytywany, jednak rzeczywiste nieudane próby logowania gromadzą się w journalctl -u ssh, podczas gdy licznik pozostaje na poziomie 0. Najpierw należy wykluczyć oczywistą przyczynę: testy są wykonywane z adresu wymienionego w ignoreip, dlatego własne nieudane próby są z założenia pomijane. Jeśli nie jest to przyczyna, używana jest kompilacja OpenSSH, w której proces roboczy obsługujący połączenie jest sshd-session (9.8 i nowsze). W takiej wersji wpis dziennika _COMM ma wartość sshd-session, a nie sshd, dlatego dostarczony filtr go nie rozpoznaje. Należy rozszerzyć dopasowanie w bloku [sshd]:

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

Należy uruchomić usługę ponownie, celowo wykonać nieudaną próbę logowania z adresu niewymienionego w ignoreip i sprawdzić, czy Total failed zacznie się zwiększać.

Zablokowano własny adres: Connection refused. Własny adres nie został dodany do ignoreip, wykonano kilka nieudanych prób logowania, a teraz:

ssh: connect to host 10.0.0.10 port 22: Connection refused

Odmowa połączenia zamiast cichego przekroczenia limitu czasu oznacza, że domyślny werdykt reject akcji nftables działa prawidłowo — również wobec tego adresu. Należy postąpić zgodnie z krokiem 6: usunąć blokadę z sesji ustanowionej z innego, niezablokowanego adresu albo użyć konsoli dostawcy. Sesja już otwarta z zablokowanego adresu również zostanie zawieszona. Następnie należy dodać własny adres do ignoreip, aby sytuacja nie powtórzyła się.

Fail2ban informuje, że adres jest zablokowany, ale nadal można się z nim połączyć. Licznik w status sshd rośnie, jednak adres nadal uzyskuje dostęp do portu 22. Oznacza to niezgodność między akcją blokowania a zaporą sieciową. W Ubuntu 24.04 prawie zawsze przyczyną jest zastąpienie działającego banaction = nftables wartością banaction = iptables-multiport skopiowaną ze starszej instrukcji, na serwerze bez warstwy iptables. fail2ban.log wyświetla:

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

Należy usunąć to zastąpienie i pozostawić dostarczoną z pakietem akcję nftables. Jeśli zapora jest zarządzana całkowicie przez ufw i blokady mają być w niej widoczne, należy ustawić banaction = ufw w [DEFAULT]. Następnie trzeba uruchomić usługę ponownie i potwierdzić pojawienie się reguły za pomocą sudo nft list ruleset | grep f2b.

Fail2ban nie uruchamia się po edycji jail.local. Literówka, przypadkowy nagłówek lub nieprawidłowa wartość czasu powoduje, że usługa odmawia uruchomienia. Przed uruchomieniem usługi należy zlecić Fail2ban sprawdzenie konfiguracji:

sudo fail2ban-client -t

Polecenie wskaże plik i jail zawierające problem, na przykład Errors in jail 'sshd'. Skipping.... Dzięki temu można poprawić źródło problemu bez zgadywania.

FAQ

Czy standardowa instalacja Fail2ban w Ubuntu 24.04 rzeczywiście blokuje ataki na SSH?

Tak. Pakiet dostarcza /etc/fail2ban/jail.d/defaults-debian.conf, który włącza więzienie sshd, ustawia backend = systemd, aby odczytywało dziennik systemd zamiast nieistniejącego /var/log/auth.log, oraz ustawia banaction = nftables, aby blokady były egzekwowane przez rzeczywistą zaporę Ubuntu. Zwykłe apt install fail2ban chroni SSH od pierwszego uruchomienia systemu. Należy potwierdzić to za pomocą sudo fail2ban-client status sshd i sprawdzić, czy wartość Total failed jest większa od zera.

Dlaczego Fail2ban nie blokuje żadnych adresów na moim serwerze?

Należy kolejno wykluczyć trzy typowe przyczyny. Test może być wykonywany z adresu znajdującego się w ignoreip, który jest z założenia wyłączony z blokowania. Możliwe jest również zastąpienie działającej konfiguracji domyślnej przez wklejenie backend = auto do jail.local na podstawie starego poradnika. Powoduje to błędny odczyt dziennika w obrazie bez auth.log. Inną możliwością jest działanie w kontenerze, w którym nie ma dziennika systemd do odczytu. Należy sprawdzić Total failed w fail2ban-client status sshd. Jeżeli jego wartość nie rośnie, podczas gdy journalctl -u ssh pokazuje rzeczywiste nieudane próby, więzienie odczytuje niewłaściwe źródło.

Jak odblokować własny adres IP?

Należy uruchomić sudo fail2ban-client set sshd unbanip YOUR.IP.HERE. Polecenie zwraca 1 po pomyślnym wykonaniu. Można też użyć sudo fail2ban-client unban --all, aby usunąć wszystkie blokady. W przypadku utraty dostępu przez SSH należy użyć konsoli WWW lub VNC udostępnionej przez dostawcę i uruchomić to samo polecenie. Blokada odrzuca każdy pakiet z danego adresu do portu 22, dlatego przestaje działać nawet wcześniej otwarte połączenie. Następnie należy dodać ten adres do ignoreip, aby nie został ponownie zablokowany.

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

jail.conf zawiera domyślne ustawienia Fail2ban dostarczane przez projekt nadrzędny i jest zastępowany przy każdej aktualizacji pakietu. Każda wprowadzona tam zmiana zostanie więc ostatecznie utracona. Pakiet Debian/Ubuntu nakłada własne ustawienia za pośrednictwem jail.d/defaults-debian.conf. Własne zmiany należy umieszczać w jail.local. Plik ten jest odczytywany jako ostatni, ma pierwszeństwo przed pozostałymi plikami i nie jest modyfikowany podczas aktualizacji. jail.conf należy pozostawić jako źródło informacji tylko do odczytu.

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

Nie. Fail2ban ogranicza częstotliwość powtarzających się nieudanych prób z jednego adresu. Nie chroni przed powolnym, rozproszonym zgadywaniem haseł, gdy każdy adres pozostaje poniżej progu. Uwierzytelnianie wyłącznie za pomocą kluczy (PasswordAuthentication no) całkowicie uniemożliwia zgadywanie haseł. Fail2ban ogranicza wtedy szum w dziennikach i wcześnie usuwa skanery. Należy stosować oba mechanizmy, a najlepiej całkowicie wyłączyć dostęp SSH z publicznego Internetu.