Настройка Fail2Ban на сервере

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

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

В этой статье разберем, как установить и настроить Fail2Ban на Linux-сервере, защитить SSH, проверить работу блокировок и избежать типичных ошибок.

Важно: Fail2Ban не заменяет полноценную систему безопасности. Он не устраняет уязвимости, не заменяет firewall, SSH-ключи и регулярные обновления. Его задача — снизить эффективность автоматических атак и ограничить количество попыток подбора учетных данных.

Что такое Fail2Ban

Fail2Ban — сервис для автоматического обнаружения подозрительной активности по логам.

Принцип работы можно представить так:

сервис → журнал → Fail2Ban → обнаружение повторяющихся ошибок → блокировка IP

Например, злоумышленник пытается подключиться к SSH:

Failed password for invalid user admin from 203.0.113.25
Failed password for invalid user admin from 203.0.113.25
Failed password for root from 203.0.113.25
Failed password for test from 203.0.113.25

Fail2Ban видит несколько событий, соответствующих заданному фильтру, и после достижения установленного порога добавляет IP-адрес в блокировку.

Через заданное время блокировка может автоматически сняться.

Это особенно полезно против автоматизированного брутфорса, когда один IP-адрес выполняет десятки или сотни попыток входа.

Что именно защищает Fail2Ban

Fail2Ban можно использовать не только для SSH.

В зависимости от установленного ПО он способен анализировать логи:

• SSH;
• Nginx;
• Apache;
• Postfix;
• Dovecot;
• различных FTP-серверов;
• некоторых CMS и веб-приложений;
• других сервисов, которые записывают события в журналы.

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

Что нужно перед настройкой

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

• Ubuntu или Debian;
• доступом по SSH;
• установленным firewall;
• пользователем с правами sudo.

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

sudo apt update
sudo apt upgrade

Также важно знать текущий способ подключения к серверу.

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

Установка Fail2Ban

В Debian и Ubuntu установить Fail2Ban можно из стандартного репозитория:

sudo apt install fail2ban

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

sudo systemctl status fail2ban

Если сервис не запущен, включим его:

sudo systemctl enable --now fail2ban

Проверить состояние можно повторно:

sudo systemctl status fail2ban

Также полезно проверить версию:

fail2ban-client --version

Где находится конфигурация Fail2Ban

Основные файлы конфигурации находятся в каталоге:

/etc/fail2ban/

В нем обычно можно найти:

/etc/fail2ban/jail.conf
/etc/fail2ban/jail.d/
/etc/fail2ban/filter.d/
/etc/fail2ban/action.d/

Не редактируйте jail.conf напрямую

Одна из распространенных ошибок — изменение основного файла:

/etc/fail2ban/jail.conf

Для пользовательских настроек лучше создать отдельный файл:

/etc/fail2ban/jail.local

Например:

sudo nano /etc/fail2ban/jail.local

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

Также можно использовать отдельные файлы в:

/etc/fail2ban/jail.d/

Например:

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

Такой вариант удобен на серверах с большим количеством сервисов.

Настройка защиты SSH

SSH — один из первых сервисов, который стоит защитить с помощью Fail2Ban.

Базовая конфигурация может выглядеть следующим образом:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = %(sshd_log)s
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

Здесь используются несколько важных параметров.

enabled

enabled = true

Включает конкретный jail.

Если указать:

enabled = false

правило будет отключено.

port

port = ssh

Указывает порт, на котором работает SSH.

Если SSH работает, например, на порту 2222, можно указать:

port = 2222

Но изменение стандартного SSH-порта само по себе не является полноценной защитой. Автоматические сканеры способны обнаруживать открытые порты.

filter

filter = sshd

Определяет фильтр, по которому Fail2Ban распознает подозрительные записи в журнале.

Для SSH обычно используется встроенный фильтр sshd.

logpath

logpath = %(sshd_log)s

Указывает источник логов.

На современных системах с systemd может использоваться journald, поэтому конкретная настройка зависит от дистрибутива и способа ведения логов.

maxretry

maxretry = 5

Количество неудачных попыток, после которого IP будет заблокирован.

Например, при maxretry = 5 пять соответствующих событий в заданный интервал могут привести к блокировке.

findtime

findtime = 10m

Период, за который Fail2Ban подсчитывает нарушения.

В данном случае учитываются события за последние 10 минут.

bantime

bantime = 1h

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

В примере IP-адрес будет заблокирован на один час.

Пример полноценного jail.local

Для обычного сервера можно начать с относительно консервативной конфигурации:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]

enabled = true port = ssh filter = sshd backend = systemd

Если SSH работает на нестандартном порту:

[sshd]
enabled = true
port = 2222
filter = sshd
backend = systemd

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

Белый список IP-адресов

Очень важный параметр — ignoreip.

Он позволяет исключить определенные адреса из блокировок.

Например:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24

Если у администратора есть постоянный внешний IP-адрес, его также можно добавить:

ignoreip = 127.0.0.1/8 ::1 203.0.113.10

Это особенно важно для удаленного администрирования.

Представьте ситуацию: вы несколько раз ошиблись паролем или ключом, а Fail2Ban заблокировал ваш собственный IP. Если доступ к серверу осуществляется только через SSH и другого канала управления нет, восстановление доступа может оказаться неудобным.

При этом не стоит без необходимости добавлять в ignoreip большие диапазоны адресов.

Перезапуск Fail2Ban после изменения конфигурации

После изменения настроек перезапустим сервис:

sudo systemctl restart fail2ban

Проверим состояние:

sudo systemctl status fail2ban

Но простой перезапуск еще не означает, что конфигурация корректна.

Поэтому полезно проверить состояние jail:

sudo fail2ban-client status

В результате можно увидеть что-то вроде:

Status
|- Number of jail:  1
`- Jail list:       sshd

Далее:

sudo fail2ban-client status sshd

Пример результата:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     12
`- Actions
   |- Currently banned: 1
   |- Total banned:     3

Так можно понять, работает ли фильтр и были ли уже обнаружены нарушители.

Как посмотреть заблокированные IP

Для конкретного jail:

sudo fail2ban-client status sshd

В выводе будет список заблокированных адресов.

Если необходимо получить информацию через команду управления Fail2Ban:

sudo fail2ban-client get sshd banip

Конкретные команды могут зависеть от версии Fail2Ban, поэтому для диагностики полезно ориентироваться также на:

fail2ban-client --help

Как вручную разблокировать IP

Если адрес был заблокирован ошибочно, его можно разблокировать:

sudo fail2ban-client set sshd unbanip 203.0.113.10

После этого IP снова сможет подключаться к SSH, если нет других ограничений со стороны firewall.

Как посмотреть логи Fail2Ban

Для systemd:

sudo journalctl -u fail2ban

Для просмотра последних событий:

sudo journalctl -u fail2ban -n 100

А для наблюдения в реальном времени:

sudo journalctl -u fail2ban -f

Это один из наиболее удобных способов понять, почему jail не запускается или почему адреса не блокируются.

Как проверить работу фильтра

Перед тем как менять параметры maxretry, findtime и другие настройки, полезно проверить, действительно ли фильтр распознает записи из логов.

Для этого существует:

fail2ban-regex

Например:

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

Команда анализирует журнал и показывает, какие строки совпадают с правилами фильтра.

Это особенно полезно при создании собственных фильтров.

Если фильтр не распознает нужные события, увеличение maxretry или изменение bantime проблему не решит.

Fail2Ban и firewall

Важно понимать архитектуру Fail2Ban.

Сам Fail2Ban не является firewall в классическом смысле. Он обнаруживает события и запускает определенное действие (action), которое уже взаимодействует с механизмом фильтрации сетевого трафика.

В зависимости от системы и конфигурации могут использоваться различные механизмы:

• nftables;
• iptables;
• firewalld и связанные механизмы;
• другие поддерживаемые действия.

Поэтому перед использованием Fail2Ban желательно понимать, какой firewall используется на сервере.

Например, если сервер использует nftables, не стоит бездумно переносить старые инструкции, рассчитанные на iptables.

Fail2Ban не заменяет SSH-ключи

Важно не воспринимать Fail2Ban как способ решить проблему слабой аутентификации.

Правильная базовая конфигурация SSH обычно включает:

1. авторизацию по SSH-ключам;
2. отключение входа по паролю, если это возможно для вашей инфраструктуры;
3. запрет прямого входа root;
4. ограничение доступа firewall;
5. регулярное обновление ОС и пакетов;
6. Fail2Ban как дополнительный уровень защиты.

Например, в SSH можно использовать:

PasswordAuthentication no
PermitRootLogin no

Но менять эти параметры следует только после проверки, что вход по ключу действительно работает. Иначе можно потерять удаленный доступ к серверу.

Настройка защиты Nginx и Apache

Fail2Ban может защищать не только SSH.

Например, на веб-сервере можно анализировать определенные HTTP-ошибки или обращения, характерные для конкретного типа атак.

Однако здесь важно не включать фильтры вслепую.

Веб-приложение может генерировать большое количество легитимных запросов, а пользователи, прокси, поисковые роботы и системы мониторинга могут выглядеть для простого фильтра как подозрительная активность.

Перед включением jail необходимо определить:

• какие события действительно являются признаком атаки;
• где находятся соответствующие логи;
• какие строки должен находить фильтр;
• сколько срабатываний считать подозрительными;
• не приведет ли правило к блокировке обычных пользователей.

Для критичных веб-сервисов рекомендуется сначала протестировать фильтр на копии логов.

Настройка bantime и повторных нарушений

На практике не всегда удобно использовать одинаковую блокировку для всех ситуаций.

Например:

bantime = 1h

может быть достаточным для начальной настройки.

Но для постоянных нарушителей можно использовать более продолжительную блокировку.

В современных версиях Fail2Ban также существуют механизмы, позволяющие учитывать повторные нарушения и увеличивать продолжительность блокировки.

Например, можно организовать последовательность:

первое нарушение → 1 час
повторное → несколько часов
регулярные нарушения → более длительная блокировка

Однако чрезмерно агрессивные настройки могут создавать проблемы с общими IP-адресами, VPN, мобильными сетями и корпоративными прокси.

Поэтому значения лучше подбирать исходя из реального трафика и характера сервиса.

Почему не стоит ставить слишком маленький maxretry

На первый взгляд может показаться логичным установить:

maxretry = 1

Но это может привести к ложным блокировкам.

Пользователь может случайно несколько раз ошибиться при вводе пароля. В корпоративной инфраструктуре несколько сотрудников могут находиться за одним NAT, поэтому один внешний IP может представлять большое количество пользователей.

Для публичного SSH часто разумнее начать с умеренного значения, например:

maxretry = 5

а затем корректировать его на основании журналов.

Почему Fail2Ban иногда не блокирует IP

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

1. Jail отключен

Проверьте:

sudo fail2ban-client status

Если sshd отсутствует, проверьте:

[sshd]
enabled = true

2. Неправильный источник логов

Например, система может использовать journald, а конфигурация рассчитана на файл /var/log/auth.log.

Проверьте:

sudo journalctl -u ssh

или соответствующий журнал SSH.

3. Фильтр не совпадает с логами

Проверить его можно через:

sudo fail2ban-regex

с соответствующим логом и фильтром.

4. Неверное действие firewall

Fail2Ban может находить нарушения, но не применять блокировку из-за ошибки в action.

Смотрите:

sudo journalctl -u fail2ban

5. Перед Fail2Ban стоит reverse proxy

Для веб-приложений это особенно важно.

Если сервер находится за CDN, балансировщиком или reverse proxy, в логах веб-сервера может быть IP прокси, а не реального клиента.

В таком случае неправильная настройка фильтра потенциально может привести к блокировке адреса самого прокси.

Как проверить конфигурацию перед запуском

Хорошая практика — не изменять сервер вслепую.

После внесения настроек:

sudo fail2ban-client -t

Команда позволяет проверить конфигурацию.

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

sudo systemctl restart fail2ban

После запуска:

sudo fail2ban-client status

И затем:

sudo fail2ban-client status sshd

Практический минимальный вариант

Для небольшого Linux-сервера можно начать с такой конфигурации:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]

enabled = true backend = systemd

После сохранения:

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Это не универсальная конфигурация для любого сервера, но хороший стартовый вариант для тестирования.

Что еще стоит сделать для защиты сервера

Fail2Ban эффективнее всего работает как часть комплексной защиты.

Обновлять сервер

Регулярно устанавливайте обновления безопасности:

sudo apt update
sudo apt upgrade

Уязвимость в самом сервисе Fail2Ban не сможет устранить.

Использовать SSH-ключи

По возможности используйте ключевую аутентификацию вместо паролей.

Ограничить SSH firewall

Если SSH нужен только из определенной сети, лучше ограничить доступ на уровне firewall, а не разрешать подключения со всего интернета.

Отключить ненужные сервисы

Проверьте открытые порты:

ss -tulpn

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

Настроить резервное копирование

Fail2Ban не защищает данные от удаления, шифрования или компрометации сервера.

Резервные копии должны быть отдельным уровнем защиты.

Частые ошибки при настройке Fail2Ban

Редактирование jail.conf

Лучше использовать jail.local или отдельные файлы в jail.d.

Слепое копирование конфигурации из старых статей

Конфигурация Linux, systemd, firewall и Fail2Ban со временем меняется. Настройки для iptables могут быть неактуальны для системы с nftables.

Слишком агрессивные блокировки

Низкий maxretry и огромный bantime могут привести к ложным блокировкам.

Отсутствие ignoreip

Администратор может случайно заблокировать собственный адрес.

Проверка только статуса systemd

Команда:

systemctl status fail2ban

показывает состояние сервиса, но не подтверждает, что конкретный jail действительно обнаруживает нарушения.

Всегда проверяйте:

fail2ban-client status

и:

fail2ban-client status sshd

Отсутствие тестирования фильтров

Если Fail2Ban не распознает записи в логах, jail не будет работать ожидаемым образом.

Для этого предназначен fail2ban-regex.

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

Перед завершением настройки сервера стоит проверить:

• Fail2Ban установлен.
• Сервис запускается автоматически.
• Конфигурация проходит проверку.
• Jail SSH включен.
• Используется правильный источник логов.
• Фильтр соответствует формату логов.
• Настроен ignoreip.
• Проверена работа firewall.
• Указаны разумные maxretry, findtime и bantime.
• Проверяется статус jail.
• Администратор может вручную разблокировать IP.
• SSH защищен ключевой аутентификацией, если это возможно.
• Root-доступ по SSH ограничен.
• Сервер регулярно получает обновления.
• Настроено резервное копирование.

Итог

Fail2Ban — относительно простой инструмент, который позволяет добавить серверу дополнительный уровень защиты от автоматических атак.

Для большинства Linux-серверов разумный сценарий выглядит так:

обновления → firewall → безопасная конфигурация SSH → ключевая аутентификация → Fail2Ban → мониторинг → резервное копирование.

Главное — не ограничиваться копированием готового jail.local. Настройки Fail2Ban должны соответствовать конкретной операционной системе, способу ведения логов, firewall и набору сервисов.

Для веб-студии особенно важно рассматривать Fail2Ban не как «волшебную защиту от хакеров», а как один из компонентов инфраструктурной безопасности. Правильно настроенный Fail2Ban помогает сократить количество автоматизированных атак, но не заменяет обновления, безопасную аутентификацию, контроль доступа, мониторинг и резервное копирование.

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