Общий бан-лист fail2ban для нескольких серверов

Fail2ban отлично защищает один сервер, но о соседях он ничего не знает. Если у вас несколько серверов, каждый ловит одних и тех же ботов сам по себе. Общий бан-лист fail2ban решает эту проблему: IP, забаненный на одном сервере, сразу блокируется на всех. Разберём четыре способа его сделать и их подводные камни.

Почему fail2ban на нескольких серверах работает поодиночке

Каждый экземпляр fail2ban читает только свои логи и хранит баны в своей базе, обычно /var/lib/fail2ban/fail2ban.sqlite3. Ботнет, который перебирает пароли SSH или почты, обходит адреса подряд. На каждом сервере он успевает сделать maxretry попыток, прежде чем его забанят, и так на каждом сервере.

Насколько это заметно, видно по нашей собственной сети из 20 серверов. С 10 по 25 сентября 2026 года в общий бан-лист попало 9 204 новых IP, в среднем около 500 в сутки. 95% из них поймал fail2ban на Linux-серверах.

Способ 1. Пересылка банов через SSH

Самый прямолинейный вариант: своё действие fail2ban, которое при бане заходит по SSH на соседние серверы и банит адрес там. Например, /etc/fail2ban/action.d/share-ban.conf:

[Definition]
actionban = for h in srv2.example.ru srv3.example.ru; do
              ssh -o BatchMode=yes -o ConnectTimeout=5 f2b@$h "sudo fail2ban-client set shared banip <ip>" &
            done
actionunban =

Действие подключается к jail рядом с обычной блокировкой, а на каждом сервере заводится отдельный jail shared, в который баны только добавляются. Минусы у способа серьёзные:

• Баны по кругу. Если действие пересылки висит и на jail shared, серверы начнут пересылать один и тот же IP друг другу. Пересылка должна быть только на «ловящих» jail.
• Каждый с каждым. Списки серверов, SSH-ключи и правила sudo нужно держать на всех машинах. Добавили сервер, обновите конфиг везде.
• Потери. Если сосед в этот момент недоступен, бан до него не дойдёт, повтора нет.
• Безопасность. Пользователь с правом запускать fail2ban-client через sudo на всех серверах сам становится целью. Ограничьте sudo точной командой.

Способ 2. Общий список и ipset

Надёжнее, когда серверы не ходят друг к другу, а забирают общий список с одного места. Центральный хост собирает забаненные адреса, а каждый сервер по cron скачивает список и загружает его в ipset:

#!/bin/sh
# /usr/local/sbin/shared-ban-sync: загрузить общий список в ipset shared-ban
set -e
curl -fsS https://ban.example.ru/list.txt -o /run/shared-ban.txt
ipset create shared-ban hash:ip -exist
ipset create shared-ban-new hash:ip -exist
ipset flush shared-ban-new
grep -E '^[0-9]{1,3}(\.[0-9]{1,3}){3}$' /run/shared-ban.txt | while read -r ip; do
  ipset add shared-ban-new "$ip" -exist
done
ipset swap shared-ban-new shared-ban
ipset destroy shared-ban-new

Правило в iptables добавляется один раз:

iptables -I INPUT -m set --match-set shared-ban src -j DROP

Такой подход не зависит от доступности соседей, а ipset swap меняет список атомарно. Но остаётся главный вопрос: кто и как наполняет центральный список. Понадобится действие fail2ban, которое отправляет IP на центральный хост, приём на той стороне и чистка просроченных адресов. И обязательно whitelist: одна ошибка в фильтре, и ваш офисный IP окажется забанен на всех серверах сразу.

Способ 3. Централизованные логи

Можно собрать логи всех серверов на одном хосте через rsyslog, запустить fail2ban там и раздавать баны на серверы. Плюс в том, что атаки видны целиком: пять попыток на пяти разных серверах складываются в одну картину. Минус в сложности. Нужен надёжный сбор логов, fail2ban на лог-сервере не может сам блокировать трафик на других машинах, и раздачу банов всё равно придётся делать одним из способов выше.

Способ 4. CrowdSec вместо fail2ban

CrowdSec изначально рассчитан на несколько машин: агенты отправляют решения в общий локальный API, а блокировкой занимаются отдельные компоненты (bouncers). Есть и общий список сообщества. Это хороший вариант, если вы готовы уйти с fail2ban: у CrowdSec свои парсеры и сценарии, и настроенные jail придётся переносить.

KIPBan: общий бан-лист поверх вашего fail2ban

KIPBan не заменяет fail2ban, а достраивает к нему общий бан-лист. На Linux:

• Jail переписывать не нужно. Установщик сам назначает всем включённым jail действие, которое передаёт пойманные IP агенту, и раз в 5 минут проверяет, не появились ли новые jail. Пороги maxretry и findtime остаются вашими.
• Fail2ban ловит, агент блокирует. Блокировка переходит к агенту: ipset ipban-blocklist и правило iptables на все порты. Сроки банов задаёт лестница KIPBan: 3 дня, 30 дней, навсегда.
• Бан на всех серверах за 5 минут. Агент отправляет IP в центр сразу, а остальные серверы забирают обновления раз в 5 минут. Windows-серверы в той же сети получают эти баны в свой брандмауэр.
• Whitelist с подсетями CIDR, общий для организации и отдельный для сервера. Адрес из whitelist не блокируется, даже если он есть в общем списке.
• Глобальная база по желанию. В режиме «глобальная база» вы получаете ещё и адреса, пойманные другими участниками. Адрес попадает туда только после подтверждения от нескольких независимых организаций или от проверенного участника. Частные и служебные адреса, а также адреса самих подключённых серверов в базу не принимаются.

Требования: systemd, Python 3.7+, fail2ban, iptables и ipset. Поддерживаются Debian, Ubuntu 20.04 и новее, RHEL, Alma и Rocky 9 (с EPEL), Astra, ALT и ROSA. На системах с nftables работает через iptables-nft. На Linux агент пока работает только с IPv4.

Установка одной командой от root, токен выдаётся в личном кабинете:

bash <(curl -fsSL "https://api.kipban.ru/download_installer.php?token=<ТОКЕН>")

Вопросы про общий бан-лист fail2ban