UFW i Fail2ban (Ochrona sieciowa i blokowanie ataków)

1. Przegląd koncepcji i problem systemowy

Publicznie dostępny serwer Linux w sieci Internet jest nieustannie poddawany automatycznemu skanowaniu przez botnety. Skanery poszukują otwartych portów, słabych haseł SSH, odsłoniętych portów baz danych (PostgreSQL, Redis, MySQL) oraz niezabezpieczonych paneli administracyjnych. Bez systemowej zapory sieciowej serwer staje się podatny na ataki odmowy usługi (DoS), wyczerpanie limitów otwartych deskryptorów gniazd oraz bezpośredni, nieautoryzowany dostęp.

UFW (Uncomplicated Firewall) oraz Fail2ban tworzą dwupoziomowy system aktywnej ochrony:

• UFW (Poziom statyczny): Uproszczony interfejs konfiguracji podsystemu iptables / nftables jądra Linux, działający zgodnie z zasadą Default-Deny: wszystkie połączenia przychodzące są blokowane, z wyjątkiem jawnie dozwolonych portów (SSH, HTTP/HTTPS).
• Fail2ban (Poziom dynamiczny): Demon analizy behawioralnej, który monitoruje logi systemowe i dynamicznie modyfikuje reguły zapory, izolując adresy botów wykazujące wzorce ataków brute-force lub sondowania podatności.

+-------------------------------------------------------------------+
| Ruch przychodzący (Internet)                                      |
+---------------------------------+---------------------------------+
                                  |
                                  v
                   +-----------------------------+
                   |       Demon Fail2ban        |
                   | (Analiza logów journald/auth)|
                   +--------------+--------------+
                                  | Dynamiczny DROP (np. 24 godziny)
                                  v
                   +-----------------------------+
                   |        UFW / Netfilter      |
                   |  (iptables / nftables jądra)|
                   +--------------+--------------+
                                  |
              +-------------------+-------------------+
              | Dozwolone (22, 80, 443)               | Zablokowane (DROP)
              v                                       v
    +-------------------+                   +-------------------+
    | Usługi systemowe  |                   | Pakiet odrzucony  |
    | (Nginx, SSHd)     |                   | bez odpowiedzi    |
    +-------------------+                   +-------------------+

2. Taksonomia architektoniczna i model mentalny

Ochrona węzła opiera się na jasnym podziale odpowiedzialności między komponentami:

1. Filtr sieciowy jądra (Netfilter / nftables):
   • Niskopoziomowy silnik w jądrze Linux, który sprawdza nagłówki każdego pakietu sieciowego na interfejsach sieciowych.
2. UFW (Uncomplicated Firewall):
   • Narzędzie do prostego zarządzania łańcuchami filtrowania INPUT, OUTPUT, FORWARD.
   • Udostępnia czytelny dla człowieka składnik zamiast złożonych konstrukcji składniowych iptables.
   • Zapewnia statyczną politykę: blokowanie nieautoryzowanych zakresów portów.
3. Fail2ban (Infiltration Prevention Framework):
   • Jail (Więzienie): Encja konfiguracyjna łącząca filtr (filter.d), logi oraz akcję blokady (action.d).
   • Filter: Zestaw wyrażeń regularnych (failregex) służących do parsowania błędów uwierzytelniania.
   • Action: Instrukcja (np. iptables-multiport), która tymczasowo dodaje IP do łańcucha odrzucającego pakiety.

3. Pipeline techniczny i mechanika wewnętrzna

Podstawowe wdrożenie i konfiguracja UFW

[!IMPORTANT] Zawsze zezwalaj na ruch na porcie SSH przed aktywacją zapory, aby uniknąć zablokowania własnej sesji:

# 1. Скидання та дефолтні політики (заборонити все вхідне, дозволити вихідне)
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 2. Дозвіл критичних портів
sudo ufw allow 22/tcp comment "OpenSSH"
sudo ufw allow 80/tcp comment "HTTP (Let's Encrypt)"
sudo ufw allow 443/tcp comment "HTTPS"

# 3. Активація фаєрволу
sudo ufw --force enable
sudo ufw status verbose

Konfiguracja Fail2ban (/etc/fail2ban/jail.local)

Nigdy nie edytuj pliku jail.conf bezpośrednio (jest nadpisywany podczas aktualizacji pakietów); twórz plik nadpisujący (overrides):

[DEFAULT]
# Список довірених IP (білий список, який ніколи не блокується)
ignoreip = 127.0.0.1/8 ::1 198.51.100.12

# Час блокування (1 день) та вікно спостереження (10 хвилин)
bantime  = 24h
findtime = 10m
maxretry = 5

# Використання systemd backend для сучасних дистрибутивів (Ubuntu 22.04/24.04, Debian 12)
backend = systemd
banaction = ufw

[sshd]
enabled = true
port    = 22
mode    = aggressive

[nginx-http-auth]
enabled = true
port    = http,https
logpath = /var/log/nginx/error.log

Zarządzanie demonem:

sudo systemctl enable --now fail2ban
# Перевірка статусу ізолятора SSH
sudo fail2ban-client status sshd

4. Praktyczne scenariusze inżynierskie w środowisku produkcyjnym

01. Ochrona przed celowanym skanowaniem podatności Nginx / serwera WWW

Atakujący uruchamiają skanery (nikto, sqlmap), generujące setki żądań do ścieżek takich jak /wp-login.php, /.env czy /phpmyadmin. Tworzony jest niestandardowy filtr /etc/fail2ban/filter.d/nginx-botsearch.conf, który śledzi w logach kody statusu 404 oraz 403 dla tych ścieżek. Po trzech próbach adres IP jest blokowany na poziomie zapory na 7 dni, co chroni zasoby CPU instancji.

02. Ograniczenie dostępu do wewnętrznych metryk Prometheus i usług bazy danych

Serwer monitoringu lub baza danych PostgreSQL muszą nasłuchiwać na interfejsie zewnętrznym w celu replikacji lub zbierania metryk (scraping). Zamiast publicznie otwierać porty, konfiguruje się ograniczenia dostępu wyłącznie dla konkretnych adresów IP partnerskich węzłów:

sudo ufw allow from 10.0.0.15 to any port 9090 proto tcp comment "Prometheus scraper"
sudo ufw allow from 10.0.0.20 to any port 5432 proto tcp comment "Postgres Replica"

Wszystkie inne żądania kierowane na te porty są odrzucane bez wysyłania odpowiedzi TCP RST (tryb stealth).

03. Awaryjne odblokowanie za pomocą fail2ban-client

Programista popełnił błąd podczas łączenia się z użyciem niewłaściwego klucza, wskutek czego jego domowy adres IP został zablokowany. Administrator łączy się przez węzeł Jump i usuwa blokadę bez restartowania całego serwisu:

sudo fail2ban-client set sshd unbanip 203.0.113.45

5. Pułapki, typowe błędy i aspekty bezpieczeństwa

1. Docker omija UFW poprzez iptables: Gdy Docker uruchamia kontener z parametrem -p 8080:8080, tworzy reguły w łańcuchu PREROUTING, które mają priorytet nad regułami UFW. Port zostaje otwarty dla całego świata, nawet jeśli ufw status wskazuje na blokadę. Rozwiązaniem jest wiązanie portów wyłącznie do loopback (-p 127.0.0.1:8080:8080) lub wyłączenie zarządzania iptables w pliku /etc/docker/daemon.json ({"iptables": false}).
2. Przepełnienie logów przy braku logrotate: Jeśli Fail2ban przetwarza gigabajtowe logi serwera WWW bez rotacji, demon zacznie zużywać 100% mocy obliczeniowej CPU, próbując odczytać plik od początku. Upewnij się, że logrotate poprawnie kompresuje pliki dzienników.
3. Blokowanie własnych proxy (Cloudflare / Reverse Proxy): Jeśli serwer WWW działa za Cloudflare lub AWS ALB, Fail2ban w standardowej konfiguracji będzie blokował adresy IP samego Cloudflare zamiast rzeczywistych klientów. Skonfiguruj moduł mod_remoteip w Nginx/Apache, aby przywracać nagłówek X-Forwarded-For, zanim aktywujesz jail'e dla ruchu HTTP.