Миф: fail2ban защищает сервер от взлома

MAATRIX

«У меня стоит fail2ban — с безопасностью сервера всё в порядке» — фраза, которую слышишь регулярно, и в ней есть доля правды, только очень небольшая. Fail2ban действительно закрывает конкретный, реально распространённый паттерн атак. Проблема в том, что этот паттерн — далеко не единственный способ взломать сервер, а иногда даже не самый вероятный. Разберём, что fail2ban делает на самом деле, где у него жёсткие границы и как он встраивается в защиту, которая работает не только на бумаге.

Что fail2ban делает на самом деле

Fail2ban — это не файрвол и не система обнаружения вторжений в широком смысле, а демон, который читает текстовые логи и реагирует на повторяющийся паттерн в них. Механика простая и полностью укладывается в три шага:

1. Фильтр — регулярное выражение, которое ищет в логе строку определённого вида. Для SSH это, например, Failed password for .* from <HOST> в /var/log/auth.log.
2. Джейл (jail) — правило, которое считает, сколько раз конкретный IP (<HOST>) попал под фильтр за заданное окно времени (findtime), и после скольких попаданий (maxretry) считать это атакой.
3. Действие (action) — что делать при срабатывании: обычно это добавление правила в iptables/nftables или ufw, блокирующего IP на bantime секунд.

Минимальный /etc/fail2ban/jail.local для SSH выглядит так:

[sshd]
enabled = true
port    = ssh
filter  = sshd
logpath = /var/log/auth.log
maxretry = 5
findtime = 600
bantime  = 3600

Это значит: если с одного IP пришло 5 неудачных попыток входа за 10 минут — этот IP банится на час. Проверить, что джейл видит атаки и банит, можно командой:

fail2ban-client status sshd

Она покажет число текущих банов и список забаненных IP. Всё это работает по одному сигналу — повторяемости неудачных попыток с одного адреса в логе конкретного сервиса. Паттерн узкий, но частый: боты из ботнетов сканируют диапазоны IP и перебирают типовые логины и пароли по словарю с одного адреса за раз. Против такого шума fail2ban работает хорошо и снижает нагрузку на sshd и объём мусора в логах — этого достаточно, чтобы закрыть нижний, самый массовый слой автоматических атак. Как именно установить и настроить джейлы под разные сервисы — в статье как установить и настроить fail2ban на VPS.

Первая граница: атака с одного IP — не единственный вид брутфорса

Логика fail2ban держится на предположении «атакующий бьёт с одного адреса, поэтому его можно посчитать и забанить». Это предположение массово нарушается там, где у атакующего есть доступ к пулу IP-адресов, а не к одному.

Password spraying (распыление паролей). Вместо того чтобы перебирать много паролей на один логин с одного IP, атакующий перебирает один-два самых частых пароля (123456, Password1, название компании + год) на тысячи логинов или тысячи целевых серверов — по одной-две попытке с каждого IP из ботнета или прокси-пула. Порог maxretry = 5 в этой схеме не набирается никогда: с точки зрения fail2ban на джейл прилетает по одной неудачной попытке с сотен разных адресов, и ни один из них не пересекает порог бана. Разбор именно этого механизма и того, почему стандартная настройка джейла тут бессильна, — в статье атака распылением паролей: почему fail2ban не видит.

Распределённый брутфорс через ротацию прокси. У атакующего с бюджетом есть доступ к пулам residential-прокси или арендованным VPS в разных дата-центрах. Перебор пароля к одному логину можно размазать так, что с каждого IP уходит 2-3 попытки — ниже порога любого разумного maxretry, после чего IP меняется. Снизить maxretry в теории можно, но на практике это резко увеличивает долю ложных банов легитимных пользователей, которые просто ошиблись паролем.

Low-and-slow. Атака, растянутая во времени: одна-две попытки в час с одного IP на протяжении суток. Формально это тоже перебор, но окно findtime в fail2ban обычно исчисляется минутами, а не часами — растянутый во времени перебор физически не попадает в то же окно подсчёта.

Во всех трёх случаях сам факт брутфорса никуда не делся — просто формат атаки перестал совпадать с моделью «один IP, много попыток, короткое окно», на которой построен весь механизм бана.

Вторая граница: fail2ban не видит то, что не пишется в лог как «ошибка»

Fail2ban реагирует на текст в логе — если событие не логируется как неудачная попытка в отслеживаемом файле, джейл его физически не увидит, вне зависимости от того, насколько это событие опасно.

• Credential stuffing валидными данными. Если у атакующего есть база логин-пароль, слитая с другого сервиса, и часть пар совпадает с реальными учётками на вашем сервере, — вход происходит успешно, без единой строки Failed password в логе. Fail2ban не различает «легитимный владелец вошёл» и «кто-то вошёл с чужими, но действительными данными» — для него это одна и та же строка Accepted password.
• Атака на сервис, для которого джейл не настроен. Fail2ban банит только там, где явно указаны filter и logpath. Если на сервере поднят второй веб-сервис или админка со своей формой логина, и под неё не написан отдельный фильтр, — брутфорс туда идёт полностью незамеченным, даже если по SSH всё защищено.
• Успешный подбор без явного «Failed». Некоторые приложения пишут в лог сообщение об ошибке в формате, который не ловит стандартный фильтр, или не пишут ничего в доступный fail2ban файл вовсе (например, ошибка остаётся только в логе приложения внутри Docker-контейнера). Без фильтра, написанного под конкретное приложение, джейл просто молчит.

Это не недостаток конкретной версии fail2ban — это прямое следствие архитектуры «сработал паттерн в тексте лога → бан по IP». Если событие не оставляет такого следа, реагировать не на что.

Третья, самая частая ошибка: fail2ban путают с защитой от уязвимостей в приложениях

Здесь миф ломается сильнее всего. Fail2ban — это защита от брутфорса, то есть от подбора учётных данных методом повторных попыток. Он не имеет никакого отношения к защите от эксплуатации уязвимостей в коде самого приложения, и это принципиально разные классы угроз:

• SQL-инъекция. Атакующий отправляет одним запросом специально сформированную строку в поле формы или параметр URL, которая заставляет базу данных выполнить не тот запрос, который задумывал разработчик. Это один HTTP-запрос, а не серия неудачных попыток входа — фильтр fail2ban для SSH или базовой HTTP-авторизации его не видит и видеть не должен, это просто не тот тип события.
• RCE (удалённое выполнение кода). Уязвимость в парсере файлов, в десериализации, в устаревшем плагине CMS может дать атакующему шелл на сервере одним корректно сформированным запросом — без единой «неудачной попытки» где бы то ни было. Логи для fail2ban в такой атаке попросту нечего анализировать: событие не выглядит как повторяющаяся ошибка авторизации.
• Уязвимости в устаревших зависимостях и плагинах. Если веб-приложение работает на неактуальной версии CMS или библиотеки с известной дырой, эксплойт под неё обычно не выглядит как перебор — это конкретный, часто единственный запрос, использующий конкретный баг.

Через эти векторы проходит значительная часть реальных взломов веб-серверов, и ни один из них fail2ban не замечает и не может замечать — задача просто из другой категории.

Fail2ban не заменяет обновления и правильную конфигурацию

Ещё один слой мифа — представление, что fail2ban как-то компенсирует отставшие патчи или неаккуратную настройку сервисов. Это не так, и вот почему:

• Патчи закрывают саму уязвимость, а fail2ban — только один из способов её эксплуатации (перебор). Если в сервисе есть RCE, неважно, стоит fail2ban или нет — обновление до версии, где баг исправлен, единственное, что реально убирает риск. Откладывать патчи безопасности, полагаясь, что fail2ban как-то это компенсирует, — логическая ошибка: инструмент реагирует на попытки перебора, а не на уязвимость как таковую.
• Неправильная конфигурация сервиса открывает вход мимо всей логики банов. Классический пример — база данных (Redis, MongoDB, PostgreSQL), поднятая без аутентификации и по ошибке слушающая внешний интерфейс вместо 127.0.0.1. Fail2ban никак не участвует в этой истории: подключение к базе без пароля — это не «неудачная попытка», это штатный успешный коннект с точки зрения самой базы, а джейла на порт базы обычно вообще нет.
• Слабые пароли на сервисах без включённого джейла. Fail2ban защищает только те сервисы, под которые явно настроены фильтр и логпуть. Панель управления, самописный API, второй SSH-порт для другого пользователя — если джейл не настроен именно под них, слабый пароль там остаётся полностью открытой дверью.

Обновления, минимизация открытых портов и корректная конфигурация каждого сервиса — это работа с самой причиной риска. Fail2ban работает уже после того, как причина осталась, снижая частоту попыток её эксплуатации через один конкретный узкий канал — перебор по логину/паролю с одного адреса.

Как на самом деле должна выглядеть защита сервера

Правильная модель — это не «один инструмент закрывает всё», а несколько независимых слоёв, каждый из которых отвечает за свою категорию риска. Fail2ban в этой модели — один слой из нескольких, причём не первый по значимости:

Практический порядок действий для нового сервера — не «поставить fail2ban и успокоиться», а пройти по всем слоям:

# 1. Ключи вместо пароля — закрывает основной канал брутфорса
ssh-keygen -t ed25519 -C "you@example.com"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server_ip
# в /etc/ssh/sshd_config: PasswordAuthentication no

# 2. Firewall — открыты только реально нужные порты
ufw default deny incoming
ufw allow OpenSSH
ufw allow 80,443/tcp
ufw enable

# 3. Автообновления безопасности
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

# 4. Только после этого — fail2ban как дополнительный слой
apt install fail2ban
systemctl enable --now fail2ban

Полный чеклист первых шагов после аренды сервера, где эти пункты собраны по порядку вместе с проверкой открытых портов и правами доступа, — в статье чеклист безопасности нового сервера. Если стоит вопрос, что настроить раньше — ключи или fail2ban, ответ однозначный: сначала ключи и отключение парольного входа, потому что это убирает саму категорию атаки, а fail2ban уже поверх — пошагово это разобрано в статье как установить и настроить SSH-ключи вместо пароля на VPS.

Практический смысл fail2ban, если знать его границы

Всё сказанное не означает, что fail2ban бесполезен — совсем наоборот, при верном понимании места в цепочке он приносит реальную пользу:

• Резко снижает объём мусора в логах от автоматических сканеров, из-за чего реальные аномалии (необычный логин, вход с нового гео) проще заметить вручную или через мониторинг.
• Снимает часть нагрузки CPU/I/O от обработки неудачных подключений на слабом VPS — на серверах с ограниченными ресурсами это ощутимо.
• Работает не только для SSH: те же джейлы можно настроить под nginx (перебор форм логина, поиск админ-панелей), под почту (перебор SMTP/IMAP), под VPN — везде, где есть текстовый лог с распознаваемым паттерном неудачной попытки.

Ключевой сдвиг мышления простой: fail2ban отвечает не на вопрос «защищён ли сервер», а на гораздо более узкий — «снижена ли нагрузка от автоматического перебора логов конкретных сервисов». Это полезный и нужный слой, но именно слой, а не периметр целиком.

Частые вопросы