UFW & Fail2ban (Мережевий захист та блокування атак)(Мережевий захист: UFW та Fail2ban)

1. Огляд концепції та системна проблема

Публічно доступний Linux-сервер у мережі інтернет піддається безперервному автоматизованому скануванню ботнетами. Сканери шукають відкриті порти, слабкі паролі SSH, відкриті порти баз даних (PostgreSQL, Redis, MySQL) та незахищені панелі адміністрування. Без системного мережевого екрана сервер стає вразливим до атак відмови в обслуговуванні (DoS), виснаження лімітів відкритих дескрипторів сокетів та прямого несанкціонованого доступу.

UFW (Uncomplicated Firewall) та Fail2ban формують дворівневу систему активного захисту:

• UFW (Статичний рівень): Спрощений інтерфейс конфігурації підсистеми iptables / nftables ядра Linux за принципом Default-Deny: усі вхідні з'єднання заблоковано, за винятком явно дозволених портів (SSH, HTTP/HTTPS).
• Fail2ban (Динамічний рівень): Демон поведінкового аналізу, що моніторить системні журнали та динамічно модифікує правила фаєрволу, ізолюючи адреси ботів, які демонструють патерни brute-force атак або зондування вразливостей.

+-------------------------------------------------------------------+
| Вхідний трафік (Інтернет)                                         |
+---------------------------------+---------------------------------+
                                  |
                                  v
                   +-----------------------------+
                   |       Fail2ban Демон        |
                   | (Аналіз логів journald/auth)|
                   +--------------+--------------+
                                  | Динамічний DROP (наприклад, 24 год)
                                  v
                   +-----------------------------+
                   |        UFW / Netfilter      |
                   |  (iptables / nftables ядра) |
                   +--------------+--------------+
                                  |
              +-------------------+-------------------+
              | Дозволено (22, 80, 443)              | Заблоковано (DROP)
              v                                       v
    +-------------------+                   +-------------------+
    | Системні сервіси  |                   | Пакет знищено     |
    | (Nginx, SSHd)     |                   | без відповіді     |
    +-------------------+                   +-------------------+

2. Архітектурна таксономія та ментальна модель

Захист вузла базується на чіткому розподілі відповідальності компонентів:

1. Мережевий фільтр ядра (Netfilter / nftables):
   • Низькорівневий рушій у ядрі Linux, що перевіряє заголовки кожного мережевого пакета на мережевих інтерфейсах.
2. UFW (Uncomplicated Firewall):
   • Утиліта простого управління ланцюжками фільтрації INPUT, OUTPUT, FORWARD.
   • Надає людинозрозумілий синтаксис замість складних синтаксичних конструкцій iptables.
   • Забезпечує статичну політику: блокування неавторизованих діапазонів портів.
3. Fail2ban (Infiltration Prevention Framework):
   • Jail (Ізолятор): Конфігураційна сутність, що зв'язує фільтр (filter.d), журнал логів та дію блокування (action.d).
   • Filter: Набір регулярних виразів (failregex) для парсингу аутентифікаційних помилок.
   • Action: Інструкція (наприклад, iptables-multiport), яка тимчасово додає IP у ланцюжок відхилення пакетів.

3. Технічний пайплайн та внутрішня механіка

Базове розгортання та конфігурація UFW

[!IMPORTANT] Завжди дозволяйте порт SSH до активації фаєрволу, щоб уникнути блокування власної сесії:

# 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

Конфігурація Fail2ban (/etc/fail2ban/jail.local)

Ніколи не редагуйте jail.conf напряму (він перетирається оновленнями пакета); створюйте файл 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

Керування демоном:

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

4. Практичні інженерні сценарії в продакшені

01. Захист від цільового сканування вразливостей Nginx / веб-сервера

Зловмисники запускають сканери (nikto, sqlmap), що генерують сотні запитів до /wp-login.php, /.env, /phpmyadmin. Створюється кастомний фільтр /etc/fail2ban/filter.d/nginx-botsearch.conf, який відстежує у логах статус-коди 404 та 403 для таких шляхів. Після 3 спроб IP блокується на 7 днів на рівні фаєрволу, зберігаючи CPU інстансу.

02. Обмеження доступу до внутрішніх метрик Prometheus та сервісів БД

Сервер моніторингу або база даних PostgreSQL має слухати зовнішній інтерфейс для реплікації або скрапінгу метрик. Замість публічного відкриття портів налаштовується обмеження за конкретними IP-адресами партнерських вузлів:

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"

Усі інші запити на ці порти відкидаються без відправки TCP RST (стелс-режим).

03. Екстрене розблокування через fail2ban-client

Розробник помилився під час підключення через невірний ключ і його домашній IP потрапив у бан. Адміністратор підключається через Jump-вузол і знімає блокування без рестарту всього сервісу:

sudo fail2ban-client set sshd unbanip 203.0.113.45

5. Підводні камені, типові помилки та безпека

1. Docker обходить UFW через iptables: Коли Docker запускає контейнер із параметром -p 8080:8080, він створює правила в ланцюжку PREROUTING, які мають пріоритет над правилами UFW. Порт відкривається для всього світу, навіть якщо ufw status показує заборону. Виправляйте це, прив'язуючи порти виключно до loopback (-p 127.0.0.1:8080:8080) або вимикаючи керування iptables у /etc/docker/daemon.json ({"iptables": false}).
2. Переповнення логів при відсутності logrotate: Якщо Fail2ban парсить гігабайтні логи веб-сервера без ротації, демон почне споживати 100% CPU ядра, намагаючись прочитати файл спочатку. Переконайтеся, що logrotate коректно стискає файли журналів.
3. Блокування власних проксі (Cloudflare / Reverse Proxy): Якщо веб-сервер працює за Cloudflare або AWS ALB, Fail2ban у стандартній конфігурації блокуватиме IP-адреси самого Cloudflare замість реальних клієнтів. Налаштуйте модуль mod_remoteip в Nginx/Apache для відновлення X-Forwarded-For, перш ніж активувати HTTP-джейли.