Fail2ban на сервере: частые ошибки и решения

MAATRIX

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

Fail2ban не банит никого

Самая частая жалоба: fail2ban установлен, сервис активен, но забаненных нет, хотя логи полны попыток перебора. В большинстве случаев виноват бэкенд чтения логов. На современных Ubuntu 22.04, 24.04 и Debian события SSH пишутся в systemd journal, а не в текстовый файл /var/log/auth.log, и если fail2ban настроен на чтение файла, он просто не видит событий.

Проверьте статус джейла и настройку бэкенда.

fail2ban-client status sshd
grep backend /etc/fail2ban/jail.local

Если в статусе джейла ноль замеченных попыток при явных атаках в журнале — почти наверняка дело в бэкенде. Задайте в jail.local параметр backend = systemd и перезапустите fail2ban. Вторая возможная причина — джейл вообще не включён: убедитесь, что в секции sshd стоит enabled = true. Третья — fail2ban не запущен или упал после ошибки в конфиге. Проверьте журнал самого fail2ban, он честно сообщает, если не смог разобрать конфигурацию или шаблон.

Забанил самого себя или админа

Неприятная ситуация: вы несколько раз ошиблись паролем или перезапускали соединение, и fail2ban забанил ваш собственный адрес — теперь SSH не пускает. Если у вас нет второго доступа, зайдите через консоль VNC или аварийный доступ в панели провайдера, минуя SSH, и разбаньте себя.

fail2ban-client set sshd unban ВАШ_IP
fail2ban-client status sshd

Чтобы такого не повторялось, добавьте свои доверенные адреса в белый список. В секции DEFAULT файла jail.local укажите параметр ignoreip со своими адресами и локальной сетью — эти адреса fail2ban не будет банить никогда. Это обязательная страховка для администратора, особенно если вы подключаетесь с динамического адреса и рискуете случайно попасть под бан. После правки перезапустите сервис. Разумно также не делать bantime слишком большим на этапе настройки, чтобы случайный самобан не превратился в долгую блокировку.

Fail2ban не читает журнал systemd

Более тонкий случай проблемы с бэкендом: вы задали backend = systemd, но fail2ban всё равно не находит события или падает с ошибкой доступа к журналу. Причина может быть в том, что не установлен модуль для работы с systemd journal, который fail2ban использует для чтения. На минимальных образах его иногда нет.

Проверьте наличие поддержки и журнал ошибок fail2ban.

journalctl -u fail2ban -n 30
python3 -c "import systemd" 2>&1

Если в логе fail2ban ошибки об импорте systemd или доступе к журналу, доустановите пакет поддержки systemd для Python, который используется бэкендом. После этого перезапустите сервис. Ещё одна причина — джейл настроен на чтение конкретной службы через journalmatch, и фильтр не совпадает с тем, как ваша система пишет события SSH. В таком случае проверьте, что имя службы в настройке джейла соответствует реальному имени юнита SSH в вашей системе.

Конфликт с UFW и правилами фаервола

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

По умолчанию на системах с UFW стоит настроить fail2ban на использование действия, совместимого с UFW, чтобы баны корректно встраивались в общую цепочку. Проверьте, какое действие используется.

grep banaction /etc/fail2ban/jail.local
iptables -L -n | grep -i f2b

Команда с iptables покажет цепочки fail2ban и адреса в них. Если баны есть в цепочке, но не работают, вероятно, правило UFW пропускает трафик раньше, чем срабатывает бан fail2ban, из-за порядка проверки. Решение — использовать banaction, который вставляет баны в правильное место относительно UFW. На большинстве систем это настраивается сменой действия бана на вариант для UFW. Главное — не держать два инструмента, конфликтующих за порядок правил, без понимания, какой срабатывает первым.

Фильтр не распознаёт атаку из-за шаблона

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

Проверить фильтр против реального лога можно встроенным инструментом fail2ban-regex, который показывает, сколько строк совпало с шаблоном.

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

Если инструмент показывает ноль совпадений при явных атаках в логе, шаблон не подходит к вашему формату. Для стандартного SSH это редкость, но при защите своих сервисов или нестандартных конфигураций фильтр приходится дорабатывать. Изучите, как выглядят строки атаки в вашем логе, и подправьте регулярное выражение фильтра под них. Инструмент fail2ban-regex — лучший помощник в этой отладке, он сразу показывает, ловит фильтр события или нет.

Баны пропадают после перезагрузки или сервис не стартует

После перезагрузки сервера fail2ban не поднялся или потерял состояние. Проверьте автозапуск и журнал.

systemctl is-enabled fail2ban
journalctl -u fail2ban -n 40

Если сервис не включён в автозапуск, выполните systemctl enable fail2ban. Если же он падает при старте, причина обычно в ошибке конфигурации: опечатка в jail.local, несуществующий фильтр или недоступный лог роняют сервис. Журнал journalctl укажет точную строку. Потеря активных банов после перезагрузки — нормальное поведение, если не настроено сохранение состояния: боты просто снова попадут под бан при новых попытках. Гораздо важнее, чтобы сам fail2ban корректно стартовал и продолжал защищать сервер после ребута, поэтому в первую очередь добейтесь чистого запуска сервиса.

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