Краткое содержание: В 2026 году простой смены порта SSH уже недостаточно для защиты от глобального распространения автоматизированных скриптов сканирования. В этой статье мы пошагово разберем развертывание системы предотвращения вторжений на основе логов — Fail2Ban. От базовой логики и разбора ключевых хардкорных параметров защиты до точного блокирования SSH-брутфорса, Nginx CC-атак и злонамеренного сканирования WordPress. Вы получите полностью защищенный сервер.
Скажем прямо: как только ты купил сервер, развернул ОС и прописал домен на публичный IP, твоя машина мгновенно попадает в прицел десятков тысяч автоматических скриптов по всему миру.
Загляни в /var/log/auth.log — там сплошной поток попыток подбора паролей со всего мира. Даже при отключенной аутентификации по паролю эти вредоносные параллельные запросы будут бессмысленно расходовать ресурсы CPU и лимиты сетевых соединений твоего сервера.
Чтобы твой «архивный топ-тариф» для хостинга сайтов не был выведен из строя сканерами и не превратился в ботнет-узел, сегодня без лишних слов перейдем к хардкорной схеме защиты: подробное руководство по установке и настройке Fail2Ban.
Данная схема не только точно блокирует SSH-брутфорс, но и глубоко интегрируется с Nginx для защиты от вредоносных CC-атак и подбора паролей в WordPress. Мы предоставим четкие выводы, хардкорные данные и готовые конфигурационные файлы, чтобы навсегда решить проблему навязчивого сканирования серверов.
Разрушение стереотипов: базовая логика работы Fail2Ban
В публичных сетях злонамеренное сканирование обычно делится на два типа:
- Сканирование портов и SSH-брутфорс: Боты круглосуточно перебирают порты (например, 22), используя словари слабых паролей.
- Сканирование веб-уязвимостей и CC-атаки: Нацелены на WordPress и другие CMS. Агрессивно сканируют
wp-login.php, директории плагинов или генерируют высокочастотные CC-запросы, истощая ресурсы базы данных.
Базовая логика Fail2Ban предельно элегантна: по сути, это система предотвращения вторжений (IPS) на основе логов. Она в реальном времени отслеживает системные журналы (SSH, Nginx, системные логи). Как только определенный IP в заданный промежуток времени (findtime) превышает допустимое количество (maxretry) вредоносных действий, Fail2Ban напрямую вызывает системный фаервол (iptables, ufw или firewalld) и на сетевом уровне сбрасывает (Drop) пакеты этого IP, отправляя его в «изоляцию» на заданный срок (bantime).
Быстрая установка и коррекция логики чтения конфигурации
Независимо от того, используешь ты Debian или Ubuntu, процесс установки предельно прост.
1. Установка в один клик
sudo apt update
sudo apt install fail2ban -y
2. «Негласные правила» конфигурации (избегай типичных ошибок)
После установки конфигурационные файлы Fail2Ban находятся в директории /etc/fail2ban/. Здесь новички часто совершают критическую ошибку: никогда не редактируй файл jail.conf напрямую.
Правильная логика чтения: Система сначала загружает глобальные настройки по умолчанию из jail.conf, затем считывает jail.local и перезаписывает совпадающие параметры значениями из локального файла. При будущих обновлениях ПО jail.conf будет безжалостно перезаписан, а твои настройки в jail.local останутся нетронутыми.
Поэтому первым шагом всегда должно быть создание локальной копии конфигурации:
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
3. Редактирование глобальной стратегии
Открой /etc/fail2ban/jail.local в текстовом редакторе, найди секцию [DEFAULT] и задай глобальный базовый уровень безопасности:
ignoreip = 127.0.0.1/8 ::1 твой_публичный_IP(белый список для предотвращения ложных блокировок, крайне важно).bantime = 24h(время блокировки).findtime = 10m(окно анализа).maxretry = 3(допустимое число попыток).
Продвинутая практика 1: Комплексная защита SSH
Многие ошибочно полагают: «Если отключить вход по паролю и перейти на аутентификацию по ключу, Fail2Ban больше не нужен». Это крайне опасное заблуждение. Даже при разрешенном входе только по ключу вредоносные скрипты продолжают инициировать TCP-соединения. В auth.log накапливается мусор, а SSH-сервер тратит ресурсы на обработку этих рукопожатий.
Настоящая комплексная защита выглядит так: смена стандартного порта SSH + отключение входа Root по паролю + аутентификация только по ключу + резервная защита Fail2Ban. Первые три меры снижают вероятность успешного брутфорса на 99%, а Fail2Ban на сетевом уровне отбрасывает оставшиеся вредоносные запросы, минимизируя нагрузку на сервер.
Найди модуль [sshd] в jail.local и активируй его:
[sshd]
enabled = true
port = 2222 # Если ты сменил порт SSH, укажи его здесь
logpath = %(sshd_log)s
backend = %(sshd_backend)s
maxretry = 3
Продвинутая практика 2: Защита WordPress и встроенные правила
Для защиты от брутфорса wp-login.php и XML-RPC атак в WordPress, современные версии Fail2Ban уже включают готовые фильтры. Тебе не нужно вручную писать регулярные выражения с нуля, как в устаревших руководствах.
Просто добавь следующую конфигурацию в конец jail.local для активации:
[wordpress]
enabled = true
port = http,https
filter = wordpress # Вызов встроенного правила
logpath = /var/log/nginx/access.log # Убедись, что путь совпадает с твоей веб-средой
maxretry = 5
findtime = 10m
bantime = 24h
(Совет для гиков: если ты используешь крайне редкую панель управления, из-за которой встроенные правила не срабатывают, только тогда потребуется вручную добавить регулярные выражения в /etc/fail2ban/filter.d/wordpress.conf.)
Продвинутая практика 3: Защита от Nginx CC-атак и вредоносных ботов
Это ключевой аспект, который часто упускают в базовых руководствах. CC-атаки (Challenge Collapsar) используют ботнеты для имитации высокочастотных запросов реальных пользователей, мгновенно истощая процессы PHP и базы данных. В связке с модулем limit_req Nginx, Fail2Ban обеспечивает эффективное противодействие.
1. Блокировка высокочастотных CC-запросов
При срабатывании limit_req в Nginx в error.log генерируются записи. Активируй следующий Jail для изоляции этих вредоносных IP:
[nginx-limit-req]
enabled = true
port = http,https
filter = nginx-limit-req
logpath = /var/log/nginx/error.log
findtime = 1m
maxretry = 10 # 10 срабатываний лимита за 1 минуту — мгновенная блокировка
bantime = 24h
2. Блокировка сканеров уязвимостей (ошибки 404)
Хакеры часто используют автоматические инструменты для слепого сканирования чувствительных директорий (например, .env, backup.zip), что генерирует массу ошибок 404. Включи защиту от вредоносных ботов:
[nginx-botsearch]
enabled = true
port = http,https
filter = nginx-botsearch
logpath = /var/log/nginx/access.log
maxretry = 3
После завершения настройки перезапусти сервис командой sudo systemctl restart fail2ban. Ты можешь в любой момент проверить количество заблокированных IP с помощью sudo fail2ban-client status nginx-limit-req.
Руководство по избеганию ошибок от vps1111 и стратегия многоуровневой защиты
При настройке безопасности критически важно избегать «избыточных мер» и «разрывов в логике». Как опытный системный администратор, я дам тебе два железных правила для предотвращения ошибок:
💡 Рекомендации vps1111 по избеганию ошибок:
- Избегай вечной блокировки (bantime = -1): Многие новички для удобства ставят бессрочную блокировку. На самом деле, современный Fail2Ban на многоядерных CPU практически не теряет производительность при обработке десятков тысяч правил iptables. Настоящая катастрофа при слепой вечной блокировке заключается в следующем: цепочки правил фаервола становятся чрезмерно длинными, что резко усложняет диагностику ложных срабатываний и делает автоматическую разблокировку невозможной. В стандартных сценариях блокировки на 24–48 часов достаточно, чтобы большинство автоматизированных скриптов отказались от твоего IP из-за высокой стоимости атаки.
- Правильное понимание «многоуровневой защиты»: Fail2Ban — это прикладное ПО, работающее на уровне ядра системы. Если ты подвергаешься масштабной DDoS-атаке в сотни Гбит/с, один Fail2Ban не справится (сетевая карта будет перегружена). Правильная архитектурная стратегия: выбирай серверы с качественными магистральными каналами (например, Telia AS1299 или Cogent AS174) и встроенной базовой защитой от DDoS на уровне дата-центра. Сначала на сетевом уровне ЦОД отсекается грубый трафик, а затем внутренний Fail2Ban обеспечивает точечную блокировку на прикладном уровне (CC-атаки, SSH-брутфорс), формируя идеальную многоуровневую систему защиты.
Коллега, применив эту комплексную схему на своем сервере, ты уже обеспечишь уровень безопасности, который превосходит 90% «незащищенных» проектов на рынке.
❓ FAQ: Ответы для гиков
Будет ли Fail2Ban сильно нагружать CPU и память сервера?
Нет. Fail2Ban — это легковесный Python-скрипт, работающий по событийной модели. На современных серверах ресурсы, затрачиваемые на мониторинг стандартных SSH и веб-логов, ничтожно малы. Незначительное снижение производительности возможно только при сверхмасштабных CC-атаках из-за частого чтения огромных access.log или постоянных вызовов iptables. Для хостинга сайтов установка абсолютно безопасна.
Можно ли использовать Fail2Ban вместе с UFW или Firewalld?
Безусловно, и это идеальное сочетание. Fail2Ban сам по себе не является фаерволом, он выступает лишь «диспетчером». После настройки правил Fail2Ban на низком уровне напрямую отдает команды на блокировку IP системным iptables, UFW или Firewalld. Они образуют безупречную цепочку взаимодействия.