SSH остаётся одной из самых «простреливаемых» поверхностей атаки на публичных серверах. Даже если вы используете ключи и отключили пароль, шум от переборов никуда не девается: сканеры ломятся в sshd, забивают auth.log или журнал journald, создают ложные алерты и иногда ощутимо едят ресурсы.
В 2025 чаще всего выбирают один из трёх вариантов «второго контура»: fail2ban, sshguard или ограничения скорости на уровне фаервола (например, nftables rate limit). Задача у всех похожая, но методы принципиально разные, а значит отличаются и побочные эффекты.
Ниже — сравнение «с полей»: что лучше ловит перебор, как управлять временем блокировки, где проще диагностика, как на всё влияет связка sshd + PAM, и когда достаточно сетевого лимита, а когда нужен «умный» бан по событиям.
Модель угроз: что именно вы пытаетесь остановить
Перед тем как выбрать инструмент, полезно описать врага и ограничения. В контексте SSH обычно встречается следующее:
- Массовый перебор паролей по популярным логинам (root/admin/test).
- Password spraying: 1–2 попытки, но по большому числу аккаунтов, чтобы не упереться в пороги блокировок.
- Шумные сканеры, которым достаточно проверить порт и баннер.
- Дешёвый DoS: много TCP-коннектов/handshake, чтобы занять процессы, очередь соединений, лимиты по сокетам.
fail2ban/sshguard/rate limit не заменяют базовый SSH hardening: ключи, запрет паролей где возможно, запрет root-логина, актуальные алгоритмы, обновления. Это «второй контур», который уменьшает шум и страхует от ошибок и наследия.
Fail2ban: «умные» баны по логам и гибкая политика
fail2ban читает логи (файлы или systemd-journald), матчится по фильтрам и при превышении порога выполняет действие: добавляет IP в блокировку, пишет в лог, отправляет уведомление и т.д. С практической точки зрения в 2025 важный момент — нормальная работа через nftables sets (по смыслу это современный аналог подхода с ipset, только нативно для nftables).
Плюсы fail2ban
- Точность: баните за конкретное событие (неуспешная аутентификация, «Invalid user», ошибки 2FA), а не за количество пакетов.
- Гибкость: разные jails для разных сервисов и разные политики (пороги, окна, время блокировки).
- Диагностика: обычно легко ответить на вопрос «почему забанило», и аккуратно подкрутить фильтр.
- Расширяемость: если у вас нестандартные логи, прокси/бастион, 2FA и особые сообщения PAM — это скорее задача настройки, а не ограничение инструмента.
Минусы fail2ban
- Риск ложных срабатываний при неожиданных форматах логов, локализации, кривой интеграции с PAM/2FA.
- Реактивность: сначала должны появиться события в журнале. Первые попытки всегда происходят до бана.
- Сопровождение: allowlist, отдельные jails, обновления фильтров — это дисциплина. На большой инфраструктуре без стандарта конфигов «расползается».
Ключевые параметры: maxretry, findtime, bantime
В fail2ban «три кита» для SSH:
maxretry— сколько неудачных событий допускается до бана.findtime— окно времени, в котором считаются эти события.bantime— длительность блокировки.
Две типовые ошибки:
- слишком маленький
findtimeи слишком большойmaxretry(spraying «просачивается»); - «вечный»
bantimeбез процесса разбана и без аккуратной allowlist (особенно больно при динамических IP и NAT у провайдера/офиса).
Fail2ban + nftables sets: схема без разрастания правил
Если вы привыкли мыслить категориями ipset, то в nftables логика обычно строится через sets с таймаутами. Фаервол проверяет, не находится ли адрес в наборе, и сразу дропает. А fail2ban добавляет адреса в set и удаляет по истечении bantime.
Минимальный ориентир, как выглядит идея на nftables (это не готовая «копипаста под ключ», а демонстрация паттерна):
sudo nft add table inet filter
sudo nft add set inet filter f2b_ssh { type ipv4_addr; flags timeout; }
sudo nft add chain inet filter input { type filter hook input priority 0; policy drop; }
sudo nft add rule inet filter input ip saddr @f2b_ssh dropPAM и логи: где чаще всего ломается «магия»
fail2ban реагирует не на «факт неверного пароля», а на строку в журнале. А строки чаще всего рождаются цепочкой sshd → PAM (например, pam_unix, pam_faillock, модули OTP/2FA) → syslog/journald.
Вы включили 2FA, поменяли сообщения об ошибках, переключили логирование на journald, обновили OpenSSH — и вдруг фильтр больше не матчится. Поэтому практическое правило: перед тем как полагаться на блокировки, воспроизведите 2–3 сценария (неверный пароль, неверный OTP, несуществующий пользователь) и убедитесь, что нужные строки реально появляются там, откуда читает fail2ban.
sshguard: легче стартовать, часто достаточно для «типового» SSH
sshguard решает похожую задачу: читает события аутентификации (через syslog или journald, зависит от системы) и банит источники на уровне фаервола. В эксплуатации он часто проще: меньше сущностей, меньше «зоопарка» фильтров, быстрее довести до рабочего состояния на свежем сервере.
По ощущениям, sshguard хорошо подходит как «анти-брут по умолчанию» для небольших узлов, где важно быстро убрать шум, но нет требования строить сложную политику на разные сервисы и типы событий.
Сильные стороны sshguard
- Простота: меньше конфигурации и меньше точек отказа.
- Адекватная защита из коробки для стандартного SSH без нестандартных PAM-цепочек и кастомных логов.
- Небольшая нагрузка и предсказуемое поведение на маленьких VDS.
Ограничения sshguard
- Меньше гибкости, чем у fail2ban: сложнее строить тонкие политики для разных классов ошибок и разных сервисов.
- Диагностика иногда менее прозрачна: не всегда очевидно, как именно считаются окна и что попало «в атаку».
- Зависимость от логов никуда не девается: если событие не попало в журнал или формат нестандартный — реакции не будет.
Если вы выбираете между sshguard и fail2ban, можно ориентироваться так: sshguard — это «минимум сопровождения ради эффекта», fail2ban — «максимум контроля и объяснимости».
Если у вас SSH принимает доступ только администраторам, а сам сервер живёт на публичном IP, отдельный акцент я бы сделал на сетевом контуре: он уменьшает нагрузку на sshd и логи ещё до этапа аутентификации. Про это дальше.
Полезно также продумать архитектуру доступа: bastion, ProxyJump, отдельный логинг и алерты. Если вы строите такой контур, пригодится статья про SSH-бастион, ProxyJump и нормальное логирование.
nftables rate limit: быстрый барьер на транспорте без анализа логов
nftables rate limit — это другой класс решений. Вы не пытаетесь определить, был пароль неверный или верный. Вы ограничиваете скорость новых соединений/пакетов на уровне фаервола. Это отрабатывает до того, как sshd начнёт тратить ресурсы и плодить записи в журнале.
Почему rate limit не «заменяет fail2ban»
Rate limit видит только сетевую активность. Поэтому картина такая:
- он отлично режет шум и часть дешёвого DoS (когда порт долбят тысячами коннектов);
- он плохо ловит распределённые и «медленные» атаки (spraying);
- он может мешать легитимным сценариям (много сессий через NAT, Ansible/CI, одновременные подключения через bastion).
Базовый пример: лимит на новые подключения к SSH
Простой рабочий паттерн: разрешить ограниченное число новых TCP-соединений на порт SSH, а всё сверх — резать. Это уменьшает шум и снижает вероятность, что sshd упрётся в лимиты по ресурсам.
sudo nft add table inet filter
sudo nft add chain inet filter input { type filter hook input priority 0; policy drop; }
sudo nft add rule inet filter input ct state established,related accept
sudo nft add rule inet filter input iif lo accept
sudo nft add rule inet filter input tcp dport 22 ct state new limit rate 15/minute accept
sudo nft add rule inet filter input tcp dport 22 ct state new dropЧисло 15/minute подбирайте под вашу реальность. Для «админского» SSH часто достаточно 10–30 новых соединений в минуту на сервер. Если у вас bastion или автоматизация, начинайте с более мягких значений и смотрите на фактическую статистику.
Динамический set с таймаутом: «временный бан» средствами nftables
Чтобы приблизить поведение к «банам», в nftables можно использовать динамический set с таймаутом: если источник превышает лимит, вы добавляете его в набор «нарушителей» на N минут. Это остаётся сетевым решением (без логов), но эффект похож на блокировку.
sudo nft add table inet filter
sudo nft add set inet filter ssh_abusers { type ipv4_addr; flags timeout; timeout 30m; }
sudo nft add chain inet filter input { type filter hook input priority 0; policy drop; }
sudo nft add rule inet filter input ip saddr @ssh_abusers drop
sudo nft add rule inet filter input ct state established,related accept
sudo nft add rule inet filter input iif lo accept
sudo nft add rule inet filter input tcp dport 22 ct state new limit rate over 20/minute add @ssh_abusers { ip saddr } drop
sudo nft add rule inet filter input tcp dport 22 ct state new acceptЭта схема особенно полезна, когда цель — быстро «снять поток» от наглых сканеров, а не разбирать смысл ошибок аутентификации.
Сравнение: fail2ban vs sshguard vs nftables rate limit
Ниже — кратко по тем критериям, которые обычно важны в проде: точность, нагрузка, сопровождение, устойчивость к распределённым атакам и понятность логирования.
Точность и «справедливость» блокировок
- fail2ban: высокая точность, так как банит по событиям аутентификации; лучше всего подходит, когда важно различать типы ошибок (в том числе через
PAM). - sshguard: обычно достаточно точен для типового SSH, но меньше возможностей «доточить» под нестандартные случаи.
- nftables rate limit: точность по причине низкая (банит за частоту), но эффективность по «срезанию шума» высокая.
Нагрузка
- nftables: самый дешёвый вариант на прикладном уровне — решение в сетевом стеке.
- sshguard: как правило лёгкий, без сложной логики.
- fail2ban: тяжелее остальных из-за парсинга/фильтров, но на современных VDS это редко становится проблемой, если логи ротируются и правила не «съедают» CPU.
Управление временем блокировок и политика
- fail2ban: лучший контроль
bantime, легко делать разные политики и (при желании) эскалацию банов. - sshguard: времена блокировок есть, но обычно меньше гранулярности.
- nftables: «ban time» реализуется через timeout в set, но «умная» политика ограничена тем, что вы сможете выразить правилами фаервола.
Логирование и разбор инцидентов
- fail2ban: обычно самый объяснимый — можно понять, какая строка сработала, и почему.
- sshguard: нормально, но детали зависят от системы и настроек логирования.
- nftables: можно логировать дропы, но это будет сетевой лог («перебрал лимит»), а не лог уровня аутентификации.
Если хотите глубже прокачать наблюдаемость, пригодится материал про централизованный сбор и разбор логов: даже простой разбор SSH-событий становится в разы удобнее.
Рекомендуемые схемы для 2025: что ставить в реальном проде
На практике «правильный» ответ часто не «или-или», а комбинация: быстрый барьер на фаерволе + точечные баны по событиям аутентификации.
Схема A: только nftables rate limit (минимализм)
Подходит, если парольная аутентификация отключена, SSH используют 1–2 администратора, а задача — резко снизить шум и нагрузку, не связываясь с парсингом логов.
Компромисс: distributed spraying вы таким способом почти не поймаете, а поведение будет «грубее» (частота вместо смысла).
Схема B: sshguard как лёгкий «анти-брут»
Подходит для небольших серверов, где хочется защиты от перебора без большого количества конфигов и тонкой политики. Хороший вариант «поставил и забыл», если у вас стандартный SSH и нормальные логи.
Схема C: fail2ban + nftables sets (универсальный прод)
Подходит, если у вас несколько сервисов, нужна управляемая политика блокировок, понятный аудит, и важно быстро менять правила без риска «сломать» доступ. В этом варианте nftables даёт производительность (sets), а fail2ban — смысл (понимает события и контекст).
Частые ошибки вокруг блокировок SSH
- Слишком агрессивные лимиты в nftables: режете себя при параллельных подключениях (Ansible, CI, bastion с прыжками).
- Вечные баны без процесса разбана, без allowlist и без учёта динамических IP.
- Непроверенное логирование: инструмент включили, а событий нет (не тот файл, journald не читается, формат сообщений изменился).
- Игнорирование PAM-цепочки: включили 2FA или
pam_faillock, а фильтр больше не матчится на реальную строку. - Оставили пароль «на всякий случай» и надеетесь только на баны: это повышает риск, особенно при слабых паролях.
Мини-чеклист выбора
- Нужны «умные» реакции по событиям, отчётность и тонкая политика → fail2ban.
- Нужен простой анти-брут без долгой настройки → sshguard.
- Нужно дешёво срезать поток коннектов ещё до
sshd→ nftables rate limit. - Нужен максимум практической пользы без лишней боли → rate limit на nftables + fail2ban на sets.
Итоги
Выбор в 2025 обычно упирается в вопрос: вы защищаете ресурсы (CPU/сокеты/логи) от потока соединений или защищаете аккаунты от неверных попыток входа. nftables rate limit даёт быстрый барьер и резко снижает шум, но не знает контекста аутентификации. sshguard закрывает базовые случаи с минимальной вознёй. fail2ban — самый гибкий и объяснимый вариант, особенно если вы строите системную политику банов, используете nftables sets вместо «правило на каждый IP» и внимательно относитесь к связке PAM + логирование.
Если нужна безопасная стартовая точка: начните с мягкого rate limit на фаерволе, затем добавьте fail2ban или sshguard по мере появления требований к точности и аналитике.
