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 напрямую (он перетирается обновлениями пакета); создавайте файл переопределений:

[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-джейлы.