Fail2ban на Ubuntu 24.04: пошаговая установка

MAATRIX

Стоит поднять сервер, как в логах SSH начинается бесконечный поток чужих попыток входа. Fail2ban на Ubuntu 24.04 автоматически ловит таких гостей и банит их на фаерволе после нескольких неудачных попыток. Установка занимает десять минут, а нюанс с журналом systemd в свежей Ubuntu стоит знать заранее — иначе Fail2ban будет запущен, но никого не забанит. Разберём всё по шагам.

Как работает Fail2ban

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

Конфигурация строится вокруг понятия «джейл» (jail) — набора правил для конкретного сервиса. Каждый джейл описывает, какой лог читать, по какому фильтру искать атаки, сколько попыток допустимо (maxretry), за какой период их считать (findtime) и на сколько банить (bantime). Из коробки есть джейл для SSH, а при желании подключаются джейлы для Nginx, почты, панелей и других сервисов.

Важно понимать место Fail2ban в общей картине. Это реакция постфактум: он банит уже после попыток, а не предотвращает их. Поэтому базой защиты должны быть вход по SSH-ключу и фаервол, а Fail2ban — полезный дополнительный слой поверх них, который снижает шум и отсекает назойливых ботов.

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

Шаг 1. Установка пакета

На Ubuntu 24.04 Fail2ban ставится из стандартных репозиториев одной командой. Заодно поставим утилиту для просмотра статуса:

apt update
apt install -y fail2ban
systemctl status fail2ban

После установки сервис обычно запускается сам. Но «запущен» ещё не значит «защищает» — по умолчанию активен базовый джейл SSH, однако на свежей Ubuntu он может не находить нужные строки из-за особенности журналирования, о которой пойдёт речь ниже. Поэтому не останавливайтесь на факте установки, а доведите настройку до проверенного бана.

Шаг 2. Создаём jail.local

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

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
nano /etc/fail2ban/jail.local

В этом файле вы будете задавать собственные пороги и включать джейлы. Такой подход — не прихоть, а стандарт эксплуатации: разделение штатной конфигурации и ваших настроек избавляет от сюрпризов после apt upgrade. Всё, что описано ниже, добавляется именно в jail.local.

Шаг 3. Ключевой нюанс — бэкенд systemd

Вот тот самый момент, из-за которого Fail2ban на Ubuntu 24.04 часто «не работает». В современной Ubuntu SSH пишет журнал не в текстовый файл /var/log/auth.log, а в бинарный журнал systemd. Стандартный джейл, настроенный на чтение файла, просто не видит попыток входа и никого не банит. Решение — явно указать системный бэкенд для джейла SSH:

[sshd]
enabled = true
backend = systemd
maxretry = 3
findtime = 10m
bantime = 1h

Строка backend = systemd заставляет Fail2ban читать журнал напрямую из systemd, где и лежат записи об SSH. Без неё вся остальная настройка бессмысленна: пороги заданы, а срабатывать нечему. Это ошибка номер один при установке на свежих релизах, и теперь вы её не допустите.

Шаг 4. Настраиваем пороги и белый список

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

[DEFAULT]
ignoreip = 127.0.0.1/8 203.0.113.10
bantime = 1h
findtime = 10m
maxretry = 3

Не увлекайтесь крайностями. Вечный бан с maxretry = 1 рано или поздно закроет доступ вам самим из-за опечатки в ключе. Разумнее временные, но длинные баны плюс надёжный whitelist. Если хотите жёстче наказывать рецидивистов, включите джейл recidive, который банит на неделю тех, кто уже попадался. У MAATRIX сервер идёт с root и аварийным доступом через панель, так что даже ошибочный самобан не оставит вас снаружи.

Шаг 5. Применяем и проверяем бан

После правок перечитайте конфигурацию и проверьте, что джейл поднялся и действительно кого-то ловит:

systemctl reload fail2ban
fail2ban-client status
fail2ban-client status sshd

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

fail2ban-client set sshd banip 198.51.100.5
fail2ban-client set sshd unbanip 198.51.100.5

Появление адреса в списке и его снятие подтверждают, что связка с фаерволом работает.

Шаг 6. Расширяем и поддерживаем

Когда SSH под защитой, добавьте джейлы под остальные открытые сервисы. Для веб-сервера полезны nginx-http-auth против перебора basic-авторизации и джейлы под формы входа CMS, для почты — postfix-sasl. Каждый включается в jail.local по тому же принципу: enabled = true и подходящий фильтр. Не забывайте про бэкенд, если сервис тоже пишет в journald.

Поддержка минимальна, но важна. Проверьте, что Fail2ban стартует после перезагрузки (systemctl is-enabled fail2ban). Держите пакет свежим — фильтры обновляются под новые форматы логов. Раз в пару недель заглядывайте в статус джейлов: это и контроль работоспособности, и понимание, откуда идёт основная нагрузка. Такой лёгкий уход держит фоновый брутфорс под контролем, а вас — в курсе происходящего.

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