Fail2ban ставят на сервер, когда тот получает белый IP, но зачастую дальше установки дело не идёт. Получается, что сервис запущен и джейл sshd включен, но конфиг был дефолтный, бан длится по десять минут, логи читаются не из того места, а половина открытых сервисов вообще находится вне поля зрения. Под катом разберу ошибки и покажу настройки. 

Для тех, кто с fail2ban дела не имел, — это демон, который читает логи сервисов, находит в них строки про неудачные попытки входа и после нескольких повторов с одного адреса добавляет этот адрес в файрвол на определённое время. На Debian и Ubuntu ставится стандартно:

sudo apt update

sudo apt install fail2ban

sudo systemctl enable --now fail2ban

После установки первым делом нужно проверить, что сервис вообще стартовал:

sudo systemctl status fail2ban

sudo fail2ban-client status

Если вторая команда показывает только Number of jail: 0, Fail2ban запущен, но пока ничего не защищает. Дьявол, как обычно, в настройках...

Ошибка 1. Дефолтный конфиг считается рабочим

Откройте свежий jail.conf и посмотрите на цифры по умолчанию — maxretry 5, findtime 10 минут, bantime 10 минут. Переведу, если в течение десяти минут ботнет совершил пять попыток подбора, то его отстраняют от входа на десять минут, а потом можно возвращаться (обратите на это внимание, ведь и тут бывают ошибки с maxretry). 

Сейчас ботнеты и не думают долбиться в одну дверь, они перебирают данные по одной-две попытки с адреса в час, и дефолтный findtime раз в десять минут такую атаку может не заметить, ведь каждая попытка выглядит как первая. А если бан всё же случился, через десять минут бот начинает, всё начинается заново, и такая история может длиться вечно.

На основе этого, первое, что нужно сделать на новой машине — это унести параметры в разумные пределы и включить прогрессивный бан, который растит срок с каждым новым нарушением одного и того же адреса:

# /etc/fail2ban/jail.local

[DEFAULT]

maxretry = 3

findtime = 1d

bantime  = 1h

bantime.increment = true

bantime.factor    = 24

bantime.maxtime   = 5w

Три ошибки за сутки дают первый бан на час. Если тот же адрес снова добирается до порога после разблокировки, следующий бан вырастет до суток, затем до двух, четырёх и дальше по экспоненте, пока не упрётся в пять недель.

Ошибка 2. Правки в jail.conf

Классика жанра — настроили все прямо в /etc/fail2ban/jail.conf, а потом получили конфликт с новой версией файла при обновлении пакета. Тут правило простое, jail.conf — файл поставщика, ваши настройки должны жить в jail.local или в отдельных файлах, ведь они перекрывают дефолт: 

sudo nano /etc/fail2ban/jail.d/sshd.local

Туда же можно добавить: 

[sshd]

enabled = true

С помощью второй команды проще понять, что вы поменяли сами, а что приехало из пакета. Проверить, что реально применилось, можно командой:

sudo fail2ban-client -t

Она проверит конфигурацию и поймает ошибки до перезапуска. Если нужно посмотреть итоговую конфигурацию после объединения файлов, используйте: 

sudo fail2ban-client --dump-pretty

После этого перезапускаем: 

sudo systemctl restart fail2ban

Ошибка 3. Демон смотрит не в те логи

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

На Debian и Ubuntu логи SSH пишутся в /var/log/auth.log, на RHEL-подобных в /var/log/secure, а на системах, где rsyslog не стоит вовсе, обоих файлов просто не существует, sshd пишет только в journald. 

Джейл со стандартным logpath в такой системе либо показывает ошибку при старте, либо, что хуже, не видит ни одной попытки входа. Диагностируется командой:

sudo fail2ban-client status sshd

Она покажет состояние джейла и статистику срабатываний. А источник событий лучше проверить отдельно: 

sudo fail2ban-client get sshd logpath

sudo fail2ban-client get sshd journalmatch

Если в выводе пустой список файлов или строчки про journal, которых нет, починить это можно явным указанием источника:

[sshd]

enabled = true

backend = systemd

Сами события SSH тоже проверьте отдельно:

journalctl -u ssh -u sshd --since "1 hour ago"

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

Ошибка 4. Docker сводит баны на нет

Если сервисы крутятся в контейнерах, стандартный fail2ban может промахиваться. Тут есть две ситуации.   

Первая проблема в логах — контейнер пишет в stdout/stderr, а дальше место хранения зависит от logging driver Docker. При journald сообщения можно читать через backend = systemd и фильтровать по полям вроде CONTAINER_NAME. При стандартном json-file в systemd journal этих сообщений не будет. Проверяется через:

docker info --format '{{.LoggingDriver}}'

docker inspect --format '{{.HostConfig.LogConfig.Type}}' ИМЯ_КОНТЕЙНЕРА

Вторая в пути пакета — при бэкенде через iptables опубликованные контейнерные порты идут через forwarding и Docker-цепочки, а fail2ban по умолчанию банит в INPUT. В этом случае можно использовать DOCKER-USER вместе с iptables-action, который умеет работать с указанной цепочкой. 

Ошибка 5. Под защитой один SSH или его поменяли

Зачастую в свежем сервере из коробки включен только джейл sshd. Но у fail2ban есть готовые фильтры для Nginx, Postfix, Dovecot и других сервисов, которые включаются с помощью:

[nginx-limit-req]

enabled = true

[postfix]

enabled = true

mode = aggressive

Режим aggressive у postfix-фильтра ловит не только ошибки аутентификации, но и мусорные сессии. Если на сервере живёт WordPress, стоит поднять джейл под него. Про базовую гигиену вокруг я, кстати, уже писал, fail2ban там один из многих.

Если SSH переехал с 22-го порта на 2222, Fail2ban может видеть неудачные логины, но будет блокировать стандартный 22. В этом случае в джейл укажите реальный порт:

[sshd]

enabled = true

backend = systemd

port = 2222

И после перезапуска проверьте:

sudo fail2ban-client status sshd

Если используете nftables, посмотрите и правила:

sudo nft list ruleset

У штатного nftables action Fail2ban используется отдельная таблица f2b-table — цепочка f2b-chain и sets с заблокированными адресами. Точные имена можно переопределять, поэтому лучше смотреть фактический ruleset. 

Ошибка 6. Рецидивисты гуляют свободно

Иногда забаненные ранее боты возвращаются и заново пытаются попасть в систему. Fail2ban умеет с такими работать через джейл recidive, который читает собственный лог fail2ban: 

[recidive]

enabled   = true

logpath   = /var/log/fail2ban.log

banaction = %(banaction_allports)s

bantime   = 1w

findtime  = 1d

maxretry  = 3

Но есть правила — во-первых, увеличивая bantime свыше суток, увеличьте и dbpurgeage в fail2ban.local, иначе база забудет старые нарушения. Во-вторых, держите loglevel ниже DEBUG, иначе recidive будет учитывать собственный шум. 

Ошибка 7. Fail2ban вместо ключей

Если на SSH открыт вход по паролю, против целевой атаки с подбором fail2ban бессилен. От брутфорса лучше использовать комплексную защиту:

  • вход только по ключам,

  • PermitRootLogin no,

  • PasswordAuthentication no.

Также держите у себя прописанный ignoreip со своим статическим адресом, иначе однажды вы сами забанитесь:

[DEFAULT]

ignoreip = 127.0.0.1/8 ::1 203.0.113.15

Текущий список исключений проверяйте через сам Fail2ban:

sudo fail2ban-client get sshd ignoreip

Ошибка 8. Бан не в тот файрвол

Fail2ban сам пакеты не фильтрует, он вызывает выбранный banaction, поэтому выясните, соответствует ли он файрволу. В актуальной конфигурации для Debian он по умолчанию использует nftables, но лучше проверить:

iptables -V

sudo nft list ruleset

Поддержку IPv6 тоже смотрите отдельно. Штатные actions Fail2ban для iptables и nftables умеют работать и с IPv6, но иногда сервер закрыт по IPv4 и при этом остаётся доступным по IPv6 из-за конфига файрвола.

Ошибка 9. Regex проверяется на проде

С кастомными сервисами всё ещё веселее. Если вы нашли в интернете failregex = .*Failed.*<HOST>.* и хотите перезапустить Fail2ban, то так делать не стоит. Первое — regex может не совпасть с вашим форматом лога. Второе — если пользователь способен подставить произвольный текст туда, откуда regex затем вытащит <HOST>, атакующий может заставить Fail2ban заблокировать чужой IP. В связи с этим сначала проверьте:

sudo fail2ban-regex /var/log/myapp/auth.log /etc/fail2ban/filter.d/myapp.conf

Если работаете через systemd journal:

sudo fail2ban-regex systemd-journal sshd

Смотрите не только на количество Matched, но и Missed. Иногда фильтр идеально ловит один вид ошибки и полностью пропускает другой.

Ошибка 10. Fail2ban банит proxy

В случае, если nginx или приложение стоит за HAProxy, Cloudflare, ingress-контроллером или другим reverse proxy, в журнале может оказаться именно IP-адрес прокси. Fail2ban увидит пять неудачных попыток и заблокирует его. После этого доступ к сайту потеряют ваши пользователи. 

Здесь сначала нужно понять, какой адрес реально попадает в лог:

tail -f /var/log/nginx/access.log

или:

journalctl -f -u nginx

И если сервис всё-таки работает за прокси, настройте корректное получение реального IP-адреса устройства и убедитесь, что доверяете XFF или PROXY protocol-у. 

Как проверить, что защита живая

Сначала настройте:

# /etc/fail2ban/jail.d/sshd.local

[DEFAULT]

bantime = 30m

findtime = 10m

maxretry = 5

bantime.increment = true

bantime.factor = 2

bantime.maxtime = 1d

ignoreip = 127.0.0.1/8 ::1

[sshd]

enabled = true

backend = systemd

port = 22

Если SSH работает на другом порту, меняем его. После этого:

sudo fail2ban-client -t

sudo systemctl restart fail2ban

sudo fail2ban-client status

sudo fail2ban-client status sshd

Затем фильтр проверяйте на реальном логе, без запуска демона:

sudo fail2ban-regex systemd-journal sshd

Утилита покажет, сколько строк лога поймал фильтр, и если там ноль при очевидных неудачных логинах, то проблема в регэкспе или в logpath. Дальше смотрите статус джейлов и список текущих банов:

sudo fail2ban-client status

sudo fail2ban-client status sshd

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

sudo fail2ban-client set sshd unbanip ВАШ_IP

И последнее, смотрим:

sudo nft list ruleset

Если что-то из этой цепочки не сработало, возвращайтесь к разделам про бэкенд и action. Когда защита работает, раз в месяц всё равно прогоняйте сервер на предмет того, что она могла пропустить. Об этом рассказал тут. 

Пишите в комментариях, на какие ошибки в Fail2ban натыкались вы, и случался ли у вас самобан. Что делали в этих случаях?

© 2026 ООО «МТ ФИНАНС»