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 serwer VPS z systemem Ubuntu 24.04, dostępem root lub sudo oraz działającym protokołem SSH, najlepiej z uwierzytelnianiem kluczem. Fail2ban jest oszczędny: zużywa kilkadziesiąt megabajtów pamięci RAM i nie wymaga dostrajania limitów.

Teraz kwestia, w której wiele starszych poradników wprowadza w błąd. Przez lata standardową radą było: „zainstaluj Fail2ban, a następnie dodaj backend = systemd, ponieważ Ubuntu przestało zapisywać /var/log/auth.log”. Ta porada jest aktualna tylko dla niektórych obrazów. Standardowy serwer Ubuntu 24.04 lub obraz chmurowy nadal instaluje rsyslog, którego domyślne reguły zapisują auth,authpriv.* w /var/log/auth.log, więc na większości serwerów VPS nieudane próby logowania SSH trafiają zarówno do tego pliku, jak i do dziennika systemd. Obrazy minimalne (obraz chmurowy Ubuntu 24.04 minimal jest dostarczany bez rsyslog) oraz większość kontenerów rejestruje SSH wyłącznie w dzienniku, gdzie plik tekstowy faktycznie nie istnieje. Niezależnie od tego, w systemie Ubuntu 24.04 pakiet Fail2ban uwzględnia to automatycznie. Pakiet dodaje /etc/fail2ban/jail.d/defaults-debian.conf i to właśnie ten plik, a nie domyślne ustawienia producenta, jest faktycznie używany przez serwer:

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

[sshd]
enabled = true

Należy przeczytać to uważnie, ponieważ rozstrzyga to dwie kwestie, zanim cokolwiek zostanie zmienione. backend = systemd oznacza, że jail SSH odczytuje dziennik, więc nie ma znaczenia, czy dany obraz zapisuje auth.log, czy nie. banaction = nftables oznacza, że blokady są egzekwowane za pomocą nftables, czyli firewalla faktycznie używanego w Ubuntu 24.04, zamiast przestarzałego iptables. A [sshd] enabled = true oznacza, że jail jest aktywny od pierwszego uruchomienia. Wniosek: standardowy apt install fail2ban w systemie Ubuntu 24.04 blokuje ataki brute-force na SSH od razu po instalacji. Większość pracy polega na potwierdzeniu tego stanu, dostrojeniu polityki oraz upewnieniu się, że nie dojdzie do zablokowania własnego dostępu.

Stara pułapka auth.log nadal występuje w trzech sytuacjach i warto je rozpoznać: Fail2ban został zainstalowany za pomocą pip zamiast apt, więc plik defaults-debian.conf nie istnieje; użytkownik znajduje się w nieuprzywilejowanym kontenerze bez dziennika systemd do odczytu; lub zastosowano stary poradnik i wklejono backend = auto do własnego pliku jail.local, nadpisując działającą konfigurację domyślną. Pierwszy i trzeci przypadek powodują przerwanie blokowania SSH tylko na obrazie bez rsyslog, takim jak obraz minimalny, ponieważ tam, gdzie działa rsyslog, backend plikowy znajduje /var/log/auth.log i działa poprawnie. Sekcja dotycząca trybów awaryjnych pokazuje dokładnie, jak wygląda każdy z nich.

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: Edycja jail.local, nigdy jail.conf

Fail2ban przechowuje domyślne ustawienia dostarczone przez twórców w /etc/fail2ban/jail.conf. Nie należy edytować tego pliku. Aktualizacja pakietu może go nadpisać, o czym ostrzega nagłówek pliku, co spowoduje utratę wprowadzonych zmian. Fail2ban odczytuje pliki w ustalonej kolejności: najpierw jail.conf, następnie jail.d/*.conf w kolejności alfabetycznej, potem jail.local, a na końcu jail.d/*.local w kolejności alfabetycznej, przy czym ostatnia odczytana wartość jest wiążąca. Zatem jail.local nadpisuje ustawienia z defaults-debian.conf, ale każdy plik *.local umieszczony w jail.d/ jest odczytywany później i tym samym nadpisuje poprzednie wartości. Należy przechowywać własne nadpisania w jednym miejscu, aby zachować kontrolę nad tym, która wartość jest aktywna. Plik .local jest przeznaczony dla użytkownika i aktualizacje pakietów nigdy go nie modyfikują. Ta sama zasada dotyczy filtrów, gdzie plik *.local nadpisuje dostarczony domyślnie filter.d/*.conf.

W związku z tym należy utworzyć niewielki plik jail.local, który nadpisuje tylko wybrane ustawienia, pozostawiając zarówno jail.conf, jak i dostarczony w pakiecie jail.d/defaults-debian.conf bez zmian, jako pliki referencyjne.

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: Restart i weryfikacja odczytu dziennika

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

Narzędzie -t najpierw przeprowadza test konfiguracji, więc błąd w jail.local spowoduje natychmiastowe przerwanie działania zamiast pozostawienia usługi w stanie awarii. Prawidłowy status jaila 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:   203.0.113.66

Liczba potwierdzająca, że Fail2ban faktycznie odczytuje logowania, to Total failed. Jeśli jest ona większa od zera lub rośnie, gdy celowo wprowadzisz błędne dane logowania z innego urządzenia, oznacza to, że dziennik jest odczytywany i konfiguracja została zakończona. Jeśli wartość pozostaje na poziomie 0 niezależnie od liczby nieudanych prób, a adres IP nie znajduje się na liście ignoreip, należy przejść do poniższych scenariuszy awarii.

Zwróć uwagę, że wiersz Journal matches nadal wskazuje na sshd.service. W systemie Ubuntu jednostka SSH nazywa się w rzeczywistości ssh.service, jednak dostarczony filtr dopasowuje również _COMM=sshd, a OpenSSH w wersji 24.04 rejestruje błędy logowania z procesu o nazwie sshd, więc dopasowanie działa poprawnie. Ten szczegół ma znaczenie tylko w przypadku nowszych wersji OpenSSH (9.8 lub nowszych, gdzie proces obsługujący połączenie to sshd-session); scenariusze awarii uwzględniają ten przypadek.

Krok 5: Obserwacja blokady lub jej wymuszenie w celach testowych

Rzeczywiste blokady pojawiają się samoczynnie w ciągu kilku minut na każdym publicznym serwerze VPS. Aby monitorować ten proces, należy śledzić dziennik:

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 203.0.113.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 203.0.113.66

Aby zweryfikować działanie mechanizmu bez oczekiwania, można ręcznie zablokować adres dokumentacyjny; nigdy nie należy blokować własnego adresu. 203.0.113.66 znajduje się w puli TEST-NET-3, zarezerwowanej na potrzeby dokumentacji, więc nie może być rzeczywistym hostem ani adresem prywatnym w sieci dostawcy:

sudo fail2ban-client set sshd banip 203.0.113.66

Polecenie wyświetli 1, a adres pojawi się w sekcji Banned IP list w pliku fail2ban-client status sshd. Następnie należy potwierdzić, czy blokada faktycznie istnieje w zaporze sieciowej. W systemie Ubuntu 24.04 używany jest nftables, a nie iptables:

sudo nft list table inet f2b-table

Widoczny będzie zestaw o nazwie addr-set-sshd zawierający 203.0.113.66 oraz łańcuch f2b-chain, który odrzuca każde źródło znajdujące się w tym zestawie. Jeśli fail2ban-client wskazuje, że adres jest zablokowany, ale nie pojawia się on w nft list, oznacza to, że akcja blokowania nie jest zgodna z konfiguracją zapory sieciowej; należy zapoznać się z uwagami dotyczącymi nftables/iptables w sekcji dotyczącej błędów.

Krok 6: Odblokowanie adresu i odzyskiwanie dostępu w przypadku blokady

Jeśli omyłkowo zablokowano własny adres IP, należy go usunąć:

sudo fail2ban-client set sshd unbanip 203.0.113.66

W przypadku powodzenia polecenie zwraca 1. Aby usunąć wszystkie blokady we wszystkich jailach:

sudo fail2ban-client unban --all

Nie należy polegać na otwartej sesji SSH jako zabezpieczeniu: blokada nftables odrzuca każdy pakiet z zablokowanego adresu kierowany na port 22, w tym pakiety dla już nawiązanych połączeń, co powoduje zamrożenie sesji w momencie nałożenia blokady. Jeśli użytkownik zablokuje sam siebie i nie posiada wpisu ignoreip, dostęp zostanie utracony do momentu wygaśnięcia blokady. Odzyskanie dostępu wymaga użycia konsoli internetowej dostawcy (VNC lub port szeregowy), która nie korzysta z protokołu SSH. Należy wówczas odczekać czas bantime lub wykonać polecenie odblokowania z poziomu konsoli.

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 awaryjne i dokładne komunikaty

"Have not found any log file for sshd jail", a Fail2ban nie uruchamia się. Jest to stary problem auth.log. W systemie Ubuntu 24.04 występuje on tylko wtedy, gdy /var/log/auth.log nie istnieje (obraz bez rsyslog, na przykład obraz minimalny lub kontener) i dziennik nie jest odczytywany: instalacja pip bez defaults-debian.conf, kontener bez dziennika lub błędny wpis backend = auto wklejony do jail.local. W przypadku backendu plikowego bez /var/log/auth.log, jail sshd nie może odnaleźć swojego dziennika, co powoduje przerwanie pracy całego demona. fail2ban.log pokazuje:

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

Ponieważ błąd ten jest krytyczny, usługa nie uruchamia się, a 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 awarii Fail2ban. Oznacza on, że usługa nie wystartowała, ponieważ jeden z jaili nie odnalazł swojego dziennika. Ustawienie backend = systemd w [DEFAULT], co pakiet dla Ubuntu wykonuje automatycznie, rozwiązuje oba problemy jednocześnie.

Jail jest aktywny, ale Total failed nie zmienia się. Demon działa i odczytuje dziennik, jednak rzeczywiste nieudane próby logowania gromadzą się w journalctl -u ssh, podczas gdy licznik pozostaje na 0. Najpierw należy wykluczyć oczywistą przyczynę: testowanie odbywa się z adresu wymienionego w ignoreip, więc własne nieudane próby są ignorowane zgodnie z założeniem. Jeśli to nie jest przyczyna, używana jest wersja OpenSSH, w której proces roboczy dla połączenia to sshd-session (wersja 9.8 i nowsze), a jego identyfikator dziennika _COMM to sshd-session, a nie sshd, przez co domyślne dopasowanie nie działa. Należy rozszerzyć dopasowanie w bloku [sshd]:

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

Po restarcie należy celowo wywołać nieudane logowanie z adresu spoza ignoreip i potwierdzić, że Total failed rośnie.

Zablokowano własny adres: Connection refused. Własny adres nie został uwzględniony w ignoreip, wykonano kilka błędnych prób logowania i obecnie:

ssh: connect to host 10.0.0.10 port 22: Connection refused

Odmowa połączenia, zamiast cichego przekroczenia czasu oczekiwania, jest wynikiem działania domyślnego werdyktu reject akcji nftables. Należy postąpić zgodnie z krokiem 6: odblokować adres z sesji nawiązanej z innego, niezablokowanego adresu lub z konsoli dostawcy (sesja otwarta z zablokowanego adresu również zostanie zamrożona). Następnie należy dodać swój adres do ignoreip, aby zapobiec powtórzeniu sytuacji.

Fail2ban zgłasza zablokowanie adresu, ale połączenie nadal jest możliwe. Licznik w status sshd rośnie, a adres nadal uzyskuje dostęp do portu 22. Jest to niezgodność między akcją blokowania a firewallem. W systemie Ubuntu 24.04 oznacza to niemal zawsze nadpisanie działającej akcji banaction = nftables za pomocą banaction = iptables-multiport skopiowanej ze starszego poradnika na systemie bez warstwy iptables. fail2ban.log pokazuje:

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

Należy usunąć to nadpisanie i przywrócić domyślną akcję nftables lub, jeśli firewall jest zarządzany w całości przez ufw i blokady mają być tam widoczne, ustawić banaction = ufw w [DEFAULT]. Po restarcie należy potwierdzić obecność reguły za pomocą sudo nft list ruleset | grep f2b.

Fail2ban nie uruchamia się po edycji jail.local. Literówka, błędny nagłówek lub nieprawidłowa wartość czasu powodują, że usługa nie uruchamia się. Należy polecić Fail2ban sprawdzenie konfiguracji przed uruchomieniem:

sudo fail2ban-client -t

Narzędzie wskaże plik oraz jail, w którym wystąpił problem, na przykład Errors in jail 'sshd'. Skipping..., co pozwoli na naprawę źródła błędu zamiast zgadywania.

FAQ

Czy standardowa instalacja Fail2ban na Ubuntu 24.04 faktycznie blokuje ataki na SSH?

Tak. Pakiet dostarcza /etc/fail2ban/jail.d/defaults-debian.conf, który aktywuje więzienie sshd, ustawia backend = systemd w celu odczytu dziennika systemd niezależnie od tego, czy obraz systemu zapisuje /var/log/auth.log, oraz konfiguruje banaction = nftables, aby blokady były egzekwowane przez systemowy firewall Ubuntu. Standardowy apt install fail2ban chroni SSH od pierwszego uruchomienia. Należy to potwierdzić poleceniem sudo fail2ban-client status sshd i sprawdzić, czy wartość Total failed jest różna od zera.

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

Należy wykluczyć trzy najczęstsze przyczyny w podanej kolejności. Możliwe, że testy są przeprowadzane z adresu znajdującego się w ignoreip, który jest domyślnie wyłączony z blokowania. Możliwe też, że poprawne ustawienia domyślne zostały nadpisane przez wklejenie backend = auto do jail.local z przestarzałego poradnika, co uniemożliwia blokowanie SSH w systemach bez rsyslog, a tym samym bez auth.log. Trzecią przyczyną może być działanie wewnątrz kontenera, który nie posiada dostępu do dziennika systemd. Należy sprawdzić Total failed w fail2ban-client status sshd: jeśli wartość ta nie rośnie, podczas gdy journalctl -u ssh wykazuje rzeczywiste nieudane próby logowania, oznacza to, że więzienie odczytuje dane z niewłaściwego źródła.

Jak odblokować własny adres IP?

Należy wykonać sudo fail2ban-client set sshd unbanip YOUR.IP.HERE, co w przypadku powodzenia zwróci 1, lub użyć sudo fail2ban-client unban --all, aby usunąć wszystkie blokady. W przypadku utraty dostępu do SSH należy skorzystać z konsoli webowej lub VNC dostarczonej przez operatora, aby wykonać to samo polecenie. Blokada odrzuca każdy pakiet z danego adresu kierowany na port 22, więc nawet już otwarta sesja przestanie odpowiadać. Następnie należy dodać swój adres do ignoreip, aby uniknąć ponownej blokady.

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

jail.conf zawiera domyślne ustawienia dostarczone przez twórców Fail2ban i może zostać nadpisany podczas aktualizacji pakietu, dlatego edycja tego pliku jest ryzykowna. Pakiet dla systemów Debian/Ubuntu nakłada własne ustawienia poprzez jail.d/defaults-debian.conf. Własne zmiany należy wprowadzać w jail.local, który jest odczytywany jako ostatni i ma pierwszeństwo, a aktualizacje go nie modyfikują. Jedynie plik *.local wewnątrz jail.d/ jest odczytywany jeszcze później, dlatego nie należy pozostawiać tam zbędnych plików. Plik jail.conf powinien pozostać wyłącznie do odczytu jako dokumentacja referencyjna.

Czy Fail2ban zastępuje uwierzytelnianie SSH oparte na kluczach?

Nie. Fail2ban ogranicza częstotliwość powtarzających się nieudanych prób z jednego adresu; nie chroni przed powolnym, rozproszonym atakiem, w którym każdy adres pozostaje poniżej progu blokady. Uwierzytelnianie wyłącznie za pomocą kluczy (PasswordAuthentication no) całkowicie uniemożliwia zgadywanie haseł, a Fail2ban w takim scenariuszu redukuje szum w logach i wcześnie eliminuje skanery. Należy stosować oba rozwiązania, a najlepiej całkowicie odizolować SSH od publicznego Internetu.