fail2ban: защита SSH и сайта от подбора паролей

Что делает fail2ban и почему этого не хватает одного firewall

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

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

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

Общая характеристика роли fail2ban в многоуровневой защите сервера

Эта статья разбирает установку fail2ban, структуру его конфигурации через jail.conf и jail.local, включение защиты SSH, практический пример настройки для формы входа собственного веб-приложения, команды проверки статуса и ручного снятия бана, а также типичные ошибки — в первую очередь риск случайно заблокировать самого себя.

Установка fail2ban

На дистрибутивах семейства Debian и Ubuntu fail2ban устанавливается одной командой через стандартный менеджер пакетов, после чего сервис сразу регистрируется в systemd и может быть включён в автозапуск обычным способом, разобранным в отдельной статье про systemd и systemctl.

apt update\napt install fail2ban -y\nsystemctl enable --now fail2ban\nsystemctl status fail2ban

После установки полезно сразу проверить версию и убедиться, что сервис успешно стартовал без ошибок — свежая установка обычно уже включает базовую защиту SSH через встроенный jail sshd, но проверить это явно стоит прежде, чем полагаться на предположение, что защита работает.

fail2ban-client status

На дистрибутивах семейства RHEL (CentOS, AlmaLinux, Rocky Linux) fail2ban устанавливается через тот же принцип, но с менеджером пакетов dnf или yum, и может потребовать дополнительно подключить репозиторий EPEL, если пакет отсутствует в стандартных репозиториях дистрибутива.

dnf install epel-release -y\ndnf install fail2ban -y\nsystemctl enable --now fail2ban

Структура конфигурации: jail.conf и jail.local

Основной файл настроек, поставляемый вместе с пакетом fail2ban, называется /etc/fail2ban/jail.conf и содержит подробно закомментированные значения по умолчанию для десятков потенциальных jail — отдельных правил защиты для разных служб. Редактировать этот файл напрямую не рекомендуется по одной практической причине: при следующем обновлении пакета fail2ban он может быть перезаписан новой версией, и все внесённые вручную изменения будут потеряны без предупреждения.

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

Файл /etc/fail2ban/jail.local имеет более высокий приоритет, чем jail.conf, и именно в него стоит вносить любые собственные изменения и добавлять новые jail — обновление пакета fail2ban не трогает этот файл, поэтому настройки сохраняются между обновлениями. Такой же принцип разделения «оригинал плюс локальная копия для правок» встречается и в других системных службах Linux, не только в fail2ban.

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

# /etc/fail2ban/jail.d/sshd-custom.local\n[sshd]\nenabled = true\nmaxretry = 4\nbantime = 1h

Включение и настройка jail для SSH

Секция [sshd] в конфигурации fail2ban защищает именно SSH и в большинстве современных пакетов уже включена по умолчанию сразу после установки, но стоит явно проверить и при необходимости донастроить её ключевые параметры под конкретные требования сервера, а не полагаться на значения по умолчанию без проверки.

[sshd]\nenabled = true\nport = 22\nmaxretry = 4\nfindtime = 10m\nbantime = 1h

maxretry задаёт число неудачных попыток входа, после которого адрес считается подозрительным и попадает под бан; findtime — временное окно, за которое эти попытки учитываются (попытки, случившиеся раньше этого окна, уже не суммируются с новыми); bantime — продолжительность самой блокировки, которая может быть как короткой (несколько минут, мягкий режим, не создающий неудобств при случайной ошибке), так и длинной или даже постоянной для более строгой защиты.

Если SSH настроен на нестандартный порт, что само по себе разобрано как отдельная мера защиты в статье про безопасность SSH, значение port в jail нужно обязательно изменить на фактически используемый порт — иначе fail2ban продолжит анализировать попытки подключения к порту 22, которого на сервере уже фактически нет, и реальные попытки на новом порту останутся без внимания.

fail2ban-client reload sshd

После изменения параметров jail для SSH стоит сразу проверить его текущее состояние командой fail2ban-client status sshd — она покажет, сколько попыток входа было зафиксировано и сколько адресов забанено прямо сейчас, что удобно для быстрой проверки, что настройка действительно применилась и jail активен.

Практический пример: защита формы входа веб-приложения

fail2ban не ограничен только защитой SSH — тот же принцип применим к любому сервису, для которого можно однозначно определить в логе признак неудачной попытки аутентификации, включая собственную форму входа сайта или административную панель CMS. Для этого нужны два новых компонента: фильтр (filter), описывающий регулярным выражением, как выглядит строка о неудачной попытке в конкретном логе, и сам jail, связывающий этот фильтр с путём к файлу лога и параметрами блокировки.

# /etc/fail2ban/filter.d/myapp-login.conf\n[Definition]\nfailregex = ^.*Неудачная попытка входа для пользователя .* с IP <HOST>.*$\nignoreregex =

Приложение при этом должно явно логировать каждую неудачную попытку входа в предсказуемом текстовом формате, включающем IP-адрес, — специальный плейсхолдер <HOST> в регулярном выражении фильтра автоматически сопоставляется с IP-адресом, который fail2ban извлечёт из найденной строки для последующей блокировки именно этого адреса.

# /etc/fail2ban/jail.d/myapp-login.local\n[myapp-login]\nenabled = true\nfilter = myapp-login\nlogpath = /var/log/myapp/auth.log\nmaxretry = 5\nfindtime = 15m\nbantime = 30m\naction = %(action_mwl)s

Прежде чем полагаться на новый фильтр в бою, его стоит проверить командой fail2ban-regex, которая прогоняет заданное регулярное выражение против реального файла лога и показывает, сколько строк было успешно распознано как совпадения, — это позволяет отладить регулярное выражение фильтра до того, как jail окажется активен и начнёт (или, из-за ошибки в регулярном выражении, не начнёт) реально банить адреса.

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

Аналогичный подход применим и к готовым CMS: для многих популярных систем (в том числе WordPress через отдельные плагины логирования, или панелей вроде phpMyAdmin) в сообществе fail2ban уже существуют готовые фильтры, которые можно взять за основу вместо написания собственного регулярного выражения с нуля, если формат лога конкретного приложения совпадает с тем, под который написан готовый фильтр.

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

Команда fail2ban-client status без аргументов показывает список всех активных jail на сервере — полезная первая проверка, чтобы убедиться, какие именно защиты реально включены прямо сейчас, а не только присутствуют в конфигурационных файлах в отключённом состоянии.

fail2ban-client status\nfail2ban-client status sshd

Детальный статус конкретного jail (с указанием его имени) показывает число всех когда-либо зафиксированных неудачных попыток, число адресов, забаненных прямо сейчас, и явный список этих адресов — удобный способ быстро оценить интенсивность фонового шума от автоматизированного перебора без необходимости просматривать полный лог аутентификации вручную.

Для ручного снятия блокировки с конкретного адреса — например, если под бан случайно попал легитимный пользователь или сам администратор — используется команда fail2ban-client set с указанием jail и адреса, которая немедленно разблокирует его, не дожидаясь истечения заданного bantime.

fail2ban-client set sshd unbanip 203.0.113.10

Для ручной блокировки адреса вне обычного автоматического механизма (например, при обнаружении явно вредоносного адреса через другой источник, не связанный напрямую с логами, которые анализирует fail2ban) существует симметричная команда banip, добавляющая адрес в бан немедленно и вручную, минуя обычную логику подсчёта неудачных попыток.

fail2ban-client set sshd banip 198.51.100.20

ignoreip: как не забанить самого себя

Одна из самых частых практических проблем при настройке fail2ban — случайная самоблокировка: несколько неудачных попыток входа подряд с собственного рабочего IP-адреса (из-за опечатки в пароле, забытого обновлённого ключа на новом устройстве или временной проблемы с VPN) fail2ban воспринимает точно так же, как и попытки реального злоумышленника, и блокирует адрес наравне с любым другим.

[DEFAULT]\nignoreip = 127.0.0.1/8 ::1 203.0.113.50

Параметр ignoreip в секции [DEFAULT] файла jail.local задаёт список адресов или подсетей, которые fail2ban полностью исключает из анализа независимо от числа зафиксированных неудачных попыток — туда стоит заранее внести собственный статический рабочий IP-адрес (если он есть) и адрес доверенной VPN, через которую обычно происходит подключение к серверу.

Если статического адреса нет и подключение происходит с постоянно меняющегося динамического IP, простого решения через ignoreip не существует — в таком случае разумнее увеличить maxretry до значения, оставляющего разумный запас на случайные опечатки, использовать вход исключительно по ключу без пароля (что делает саму возможность неудачной попытки из-за опечатки в пароле неактуальной), или держать под рукой альтернативный способ восстановления доступа через веб-консоль провайдера на случай самоблокировки.

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

Ограничения fail2ban: чего он не умеет

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

Для защиты от такого распределённого сценария нужны дополнительные, отдельные меры: ограничение частоты запросов на уровне самого веб-приложения независимо от источника (rate limiting не по IP, а по учётной записи, к которой применяется попытка входа), CAPTCHA после нескольких неудачных попыток, и в целом защита на уровне сети провайдера или специализированного сервиса, если атака достигает по-настоящему заметного масштаба.

Отдельное практическое ограничение — fail2ban реагирует на уже свершившиеся попытки, зафиксированные в логе, а значит некоторая, пусть и небольшая, часть попыток перебора неизбежно происходит до срабатывания блокировки, пока не набран порог maxretry. Это не недостаток конкретной реализации, а особенность самого подхода, основанного на анализе истории поведения, а не на предварительной проверке репутации адреса до первой попытки.

Также стоит иметь в виду, что бан на уровне firewall блокирует адрес полностью, а не только конкретный сервис, — за некоторыми исключениями настройки конкретного action в конфигурации fail2ban, по умолчанию заблокированный за подбор пароля к SSH адрес окажется отрезан и от любых других открытых портов того же сервера, что обычно и является желаемым поведением, но стоит понимать явно, а не предполагать по умолчанию.

Чек-лист настройки fail2ban

Шаг 1. Установите fail2ban и включите автозапуск сервиса через systemctl enable --now fail2ban.

Шаг 2. Скопируйте jail.conf в jail.local (или создайте отдельные файлы в jail.d) и вносите все дальнейшие изменения именно туда, а не в оригинальный jail.conf.

Шаг 3. Проверьте и настройте jail для SSH под конкретные требования — актуальный порт, maxretry, findtime и bantime, — и убедитесь, что jail активен командой fail2ban-client status sshd.

Шаг 4. Заранее добавьте собственный статический рабочий IP-адрес и адрес доверенной VPN в ignoreip, чтобы исключить риск случайной самоблокировки при опечатке во время входа.

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

Шаг 6. Держите под рукой способ восстановления доступа через веб-консоль провайдера на случай непредвиденной самоблокировки, и периодически проверяйте статус jail командой fail2ban-client status, чтобы понимать реальную интенсивность фонового шума от подбора на сервере.

Итог: простое и эффективное дополнение к базовой защите

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

Главные практические уроки: вносить изменения в jail.local, а не в оригинальный jail.conf, заранее внести собственный рабочий адрес в ignoreip во избежание случайной самоблокировки, и понимать границы применимости fail2ban — он эффективен против перебора с одного или немногих адресов, но не против по-настоящему распределённой атаки, для которой нужны дополнительные меры на уровне приложения и сети.

Если нужна помощь с настройкой fail2ban под конкретный набор сервисов на сервере, написанием фильтра под лог собственного приложения или общей настройкой безопасного доступа — оставьте заявку внизу страницы, поможем настроить многоуровневую защиту сервера под конкретный проект.