Linux Hardening: Fail2Ban od środka. Jak czytać logi i zatrzymywać boty, zanim zapełnią Twój serwer

Jest druga w nocy. Telefon nie dzwoni, serwer odpowiada, aplikacja działa. Wszystko wygląda spokojnie. Zaglądasz jednak do logów i widzisz setki wpisów podobnych do tego:

Failed password for root from 185.xxx.xxx.xxx port 45122 ssh2
Failed password for admin from 91.xxx.xxx.xxx port 53211 ssh2
Invalid user test from 45.xxx.xxx.xxx port 49201 ssh2

Po kilku minutach licznik przekracza tysiąc prób. Po godzinie są ich dziesiątki tysięcy.

Pierwsza reakcja wielu administratorów brzmi: „Ktoś mnie atakuje.”

Druga: „Muszę zainstalować Fail2Ban.”

Obie reakcje są częściowo prawdziwe.

Tak, Twój serwer jest skanowany. Ale nie oznacza to jeszcze, że stał się celem konkretnego napastnika. To codzienny szum Internetu – zautomatyzowane boty przeszukujące kolejne adresy IPv4 w poszukiwaniu łatwych ofiar. Najciekawsze w Fail2Ban nie jest jednak to, że blokuje adresy IP. Znacznie ciekawsze jest to, że uczy administratora patrzeć na logi jak na źródło informacji, a nie tylko zbiór błędów.

Zanim zablokujesz, zrozum, co widzisz

Zanim Fail2Ban wykona jakąkolwiek akcję, wszystko zaczyna się od logów.

W Ubuntu najważniejsze źródła informacji to:

Bash

sudo journalctl -u ssh

lub klasyczny plik:

/var/log/auth.log

Na pierwszy rzut oka wpisy wyglądają chaotycznie.

Failed password for invalid user test
Failed password for root
Connection closed
Invalid user guest

Po chwili zaczynają jednak układać się we wzorzec.

Bot najczęściej działa według prostego scenariusza:

Nowy adres IP
      │
      ▼
Próba użytkownika root
      │
      ▼
Próba admin
      │
      ▼
Próba test
      │
      ▼
Próba ubuntu
      │
      ▼
Kolejny adres IP

To właśnie ten powtarzalny schemat wykorzystuje Fail2Ban.

Fail2Ban nie monitoruje sieci

To jedno z największych nieporozumień.

Wiele osób wyobraża sobie, że program „patrzy na pakiety”.

Nie.

Najpierw dzieje się coś znacznie prostszego.

Aplikacja
    │
    ▼
Log systemowy
    │
    ▼
Fail2Ban
    │
    ▼
Reguła
    │
    ▼
Firewall

To oznacza dwie ważne rzeczy.

Po pierwsze – jakość logowania ma ogromne znaczenie.

Po drugie – Fail2Ban współpracuje z firewallem zamiast go zastępować.

Pierwsza konfiguracja zajmuje minutę

Instalacja jest banalna.

Bash

sudo apt install fail2ban

Znacznie ważniejsze jest to, czego nie robić.

Nigdy nie edytuję bezpośrednio jail.conf.

Tworzę własny plik:

/etc/fail2ban/jail.local

Minimalna konfiguracja dla SSH wygląda następująco:

INI

[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h

Na pierwszy rzut oka wyglądają to jak cztery liczby.

W praktyce opisują całą strategię reakcji.

Co naprawdę oznacza maxretry?

To parametr często ustawiany przypadkowo.

Wyobraźmy sobie trzy scenariusze.

Zbyt agresywnie

maxretry = 1

Administrator wpisuje literówkę.

Zostaje zbanowany.

Zbyt liberalnie

maxretry = 50

Bot może spokojnie wykonywać kolejne próby.

Rozsądny kompromis

maxretry = 5

To zwykle wystarcza, aby odsiać automatyczne skanery, a jednocześnie nie utrudniać normalnej administracji.

Tutaj właśnie widać filozofię hardeningu.

Nie chodzi o maksymalne ograniczenie wszystkiego.

Chodzi o rozsądny kompromis.

Najbardziej niedoceniany parametr

Większość poradników skupia się na bantime.

Ja większą uwagę zwracam na findtime.

Załóżmy:

INI

findtime = 10m
maxretry = 5

Oznacza to:

pięć prób w ciągu dziesięciu minut.

Bot wykonujący pięć prób w trzy sekundy zostanie zablokowany natychmiast.

Administrator wracający po godzinie dostaje nowy licznik.

To bardzo elegancki mechanizm.

Jak sprawdzić, czy wszystko działa?

Najlepszym poleceniem nie jest restart usługi.

Jest nim:

Bash

sudo fail2ban-client status

Przykładowy wynik:

Status
|- Number of jail: 1
`- Jail list: sshd

Jeszcze ciekawsze jest:

Bash

sudo fail2ban-client status sshd

Tutaj zobaczymy:

• liczbę zablokowanych adresów,
• aktywne bany,
• liczbę wykrytych prób.

To właśnie tutaj warto zaglądać podczas pierwszych dni działania.

Prawdziwy test wygląda inaczej

Najgorszy sposób testowania to wpisywanie błędnego hasła na własnym komputerze.

Lepszy scenariusz wygląda tak.

1. Otwórz drugą sesję SSH.
2. W pierwszej wykonaj kilka błędnych prób.
3. Obserwuj logi.
4. Sprawdź status jail.

Dzięki temu nawet przypadkowy ban nie odetnie Cię od serwera.

Skąd Fail2Ban wie, co jest atakiem?

Sekret tkwi w filtrach.

Każdy filtr zawiera wzorce rozpoznające konkretne wpisy logów.

Dla SSH wygląda to mniej więcej tak:

Failed password
Invalid user
authentication failure

Program nie zgaduje.

Dopasowuje wzorzec.

To oznacza również, że można chronić nie tylko SSH.

Jedno narzędzie, wiele usług

To właśnie tutaj większość administratorów odkrywa pełny potencjał Fail2Ban.

Można chronić między innymi:

• Nginx,
• Apache,
• Postfix,
• Dovecot,
• vsftpd,
• WordPress,
• Nextcloud.

Schemat pozostaje ten sam.

Aplikacja
    │
    ▼
Log
    │
    ▼
Filtr
    │
    ▼
Ban

Zmienia się jedynie źródło logów.

Czy ban na godzinę wystarczy?

To zależy od środowiska.

Na domowym VPS-ie godzina często w zupełności wystarcza.

Na publicznym serwerze produkcyjnym można rozważyć bardziej rozbudowaną strategię.

Na przykład:

• pierwszy ban – 10 minut,
• drugi – godzina,
• trzeci – dzień,
• kolejne – tydzień.

Taka eskalacja zmniejsza liczbę przypadkowych blokad, a jednocześnie skutecznie zniechęca uporczywe boty.

IPv6 zmienia reguły gry

Ciekawa pułapka pojawia się wtedy, gdy administrator koncentruje się wyłącznie na IPv4.

Boty coraz częściej korzystają również z IPv6.

Dlatego warto sprawdzić, czy używany backend firewalla obejmuje oba stosy sieciowe.

To szczególnie istotne w nowoczesnych instalacjach Ubuntu.

Największy błąd administratorów

Po kilku tygodniach działania Fail2Ban wiele osób przestaje zaglądać do logów.

To błąd.

Liczba zablokowanych adresów sama w sobie niewiele mówi.

Znacznie ciekawsze są zmiany.

Przykładowo:

Zwykle: 200 prób dziennie
Dzisiaj: 8000 prób

To już sygnał.

Nie dlatego, że Fail2Ban sobie nie radzi.

Dlatego, że środowisko zaczęło wyglądać inaczej.

Logi stają się wtedy narzędziem obserwacji, a nie tylko źródłem błędów.

Fail2Ban nie zastąpi dobrego SSH

To najważniejsza lekcja tego artykułu.

Wyobraźmy sobie dwa serwery.

Pierwszy:

• logowanie root,
• hasła,
• brak firewalla,
• Fail2Ban.

Drugi:

• klucze Ed25519,
• PermitRootLogin no,
• UFW,
• Fail2Ban.

Oba mają ten sam program.

Nie mają tego samego poziomu bezpieczeństwa.

Fail2Ban działa najlepiej wtedy, gdy jest kolejną warstwą ochrony.

Nie pierwszą.

Kiedy Fail2Ban naprawdę pokazuje swoją wartość?

Nie wtedy, gdy pierwszy raz zablokuje adres IP.

Największą wartość pokazuje kilka miesięcy później, kiedy otwierasz logi i zauważasz, że tysiące automatycznych prób logowania kończą się na pierwszej warstwie ochrony, zanim ktokolwiek zdąży pomyśleć o haśle administratora.

To właśnie wtedy zaczyna być widoczne coś, czego nie widać w większości poradników.

Hardening nie polega na instalowaniu kolejnych narzędzi.

Polega na budowaniu systemu, w którym każda warstwa przejmuje część odpowiedzialności za bezpieczeństwo.

Firewall kontroluje ruch.

SSH kontroluje uwierzytelnianie.

AppArmor lub SELinux ograniczają proces.

A Fail2Ban pilnuje, żeby najbardziej hałaśliwi goście nie zostawali pod drzwiami zbyt długo.

Polecane wpisy

Ataki typu Watering Hole – jak działa pułapka na zaufane strony?

🕳️ Ataki typu Watering Hole – jak działa pułapka na zaufane strony? 🔍 Co to jest atak typu Watering Hole? Czytaj dalej

Jak usunąć konto Facebook – poradnik

Oto szczegółowy poradnik krok po kroku, jak usunąć konto na Facebooku: Jak usunąć konto Facebook Krok Czytaj dalej