fail2ban

fail2ban to otwarte narzędzie dla serwerów, które czyta pliki logów i blokuje adresy IP zbyt często próbujące nieudanego logowania. Według dokumentacji projektu fail2ban skanuje logi, takie jak /var/log/auth.log, i banuje adresy IP odpowiedzialne za zbyt wiele nieudanych prób, aktualizując reguły zapory tak, by odrzucała połączenia z tych adresów przez skonfigurowany czas ^[1]. Sekurak opisuje je jako narzędzie, które analizuje logi w poszukiwaniu prób ataków siłowych (brute-force) i blokuje źródłowe adresy IP ^[5]. Projekt jest rozpowszechniany na licencji GNU GPL v2 ^[1].

Jak działa

Konfiguracja opiera się na trzech pojęciach opisanych w dokumentacji jail.conf ^[2].

Każde więzienie ma trzy podstawowe parametry. maxretry to liczba błędów, które muszą wystąpić w oknie findtime, aby adres został zbanowany; findtime to długość tego okna; bantime to czas trwania bana ^[2]. Parametr ignoreip zawiera adresy, których nie należy banować, także w zapisie CIDR ^[2]. Za wykrywanie zmian w logu odpowiada backend; domyślna wartość auto próbuje kolejno pyinotify, gamin i systemd, a na końcu okresowego odpytywania ^[2].

RYS. 1Cykl pracy więzienia fail2ban

Dokumentacja zaleca, by nie zmieniać plików .conf, co ułatwia aktualizacje, a własne ustawienia umieszczać w plikach .local, które są czytane później i mają pierwszeństwo ^[2]. Minimalny przykład więzienia dla SSH w pliku jail.local wygląda tak (wartości są przykładowe, nie domyślne):

[sshd]
enabled  = true
maxretry = 5
findtime = 10m
bantime  = 1h
ignoreip = 127.0.0.1/8 203.0.113.10

Od wersji 0.10 fail2ban obsługuje adresy IPv6 ^[1]. Blokada trafia do zapory sieciowej (firewall) serwera, więc działa dla wszystkich usług, nie tylko tej, której dotyczył log.

W WordPressie

Dokumentacja WordPressa o atakach siłowych wskazuje wp-login.php jako częsty cel takich ataków ^[3]. Tak samo opisuje XML-RPC, czyli plik xmlrpc.php, zwłaszcza metodę system.multicall ^[3]. Wśród zaleceń wymienia przeglądanie logów nieudanych logowań, ustalanie ich źródeł i czasowe blokowanie nadużywających adresów IP, podając Fail2ban jako przykład ^[3].

Dokumentacja zwraca uwagę, że nawet nieudane ataki mogą przeciążyć witrynę samą liczbą żądań ^[3]. Każda próba logowania uruchamia PHP i zapytanie do bazy, więc atak siłowy kosztuje serwer zasoby także wtedy, gdy hasło jest mocne. Tu fail2ban ma przewagę nad rozwiązaniami działającymi wewnątrz WordPressa.

Na serwerze VPS z WordPressem więzienie może czytać log dostępu serwera WWW i liczyć żądania POST do tych dwóch plików. Takie więzienie działa przed PHP, więc zbanowany adres nie obciąża już bazy ani procesu WordPressa. Uzupełnia to limit prób logowania ustawiany wtyczką, który działa dopiero w samej aplikacji, ale za to rozpoznaje nieudane logowanie dokładnie, a nie po samym żądaniu POST.

Dobór progów wymaga ostrożności. Żądanie POST do wp-login.php wysyła także użytkownik, który loguje się poprawnie, a żądania do xmlrpc.php wysyłają również aplikacje mobilne i niektóre integracje. Zbyt niski maxretry zablokuje więc redaktorów pracujących z jednego biurowego adresu, a zbyt wysoki przepuści powolny atak. Filtr, który rozpoznaje odpowiedź serwera świadczącą o błędnym logowaniu, jest dokładniejszy niż filtr liczący wszystkie żądania. Jeśli xmlrpc.php nie jest używany, dokumentacja zaleca go wyłączyć; w przeciwnym razie ograniczyć regułami WAF i agresywnie limitować ^[3].

Na hostingu współdzielonym klient nie ma dostępu do zapory ani do instalacji demonów, więc podobną ochronę może zapewnić tylko dostawca. Dokumentacja WordPressa wymienia też ograniczanie liczby prób logowania na brzegu, w WAF albo CDN, lub w samym serwerze WWW ^[3], czyli rate limiting.

Przy stronie za reverse proxy albo CDN log serwera zawiera adres pośrednika zamiast adresu klienta. Więzienie ustawione bez uwzględnienia tego banowałoby wtedy pośrednika, a więc wszystkich odwiedzających. Adresy własnej infrastruktury warto wpisać do ignoreip ^[2].

Ograniczenia

Projekt zaznacza, że fail2ban zmniejsza liczbę błędnych prób uwierzytelnienia, ale nie usuwa ryzyka wynikającego ze słabego uwierzytelniania ^[1]. Jako podstawową obronę zaleca uwierzytelnianie dwuskładnikowe (2FA) albo uwierzytelnianie kluczem publicznym ^[1], dla SSH czyli logowanie kluczem SSH.

Blokada po adresie IP słabo działa przeciw atakom rozproszonym. Password spraying i credential stuffing z botnetu rozkładają próby na tysiące adresów, z których każdy może zmieścić się poniżej progu maxretry. Dlatego fail2ban jest jedną z warstw ochrony przed atakami brute force, a nie całą ochroną. Dokumentacja WordPressa wymienia obok niej mocne, unikalne hasła i menedżer haseł, 2FA dla wszystkich kont administratorów oraz CAPTCHA na stronie logowania, która spowalnia boty ^[3].

Bezpieczeństwo samego narzędzia

fail2ban działa z wysokimi uprawnieniami, bo zmienia reguły zapory, więc jego błędy mają poważne skutki. W lipcu 2021 roku opisano podatność CVE-2021-32749 w akcji mail-whois, która dołączała do powiadomienia e-mail wynik zapytania whois ^[5]. Polecenie mail z pakietu mailutils potrafi wykonać komendę, gdy w obcych danych, na przykład w odpowiedzi whois, pojawi się niezabezpieczona sekwencja sterująca ^[4]. Atakujący, który kontroluje odpowiedź serwera whois albo przechwyci nieszyfrowany ruch whois w ataku man-in-the-middle (MITM), mógł doprowadzić do zdalnego wykonania kodu (RCE) z uprawnieniami administratora ^{[4] [5]}.

Poprawki wydano w wersjach 0.10.7 i 0.11.3 ^[4]. Wniosek praktyczny: aktualizować fail2ban razem z systemem i nie włączać akcji powiadomień, które przetwarzają dane z zewnętrznych źródeł, jeśli nie są potrzebne.