С выходом OpenSSH 9.8 (Ubuntu 24.10 и новее) администраторы получили механизм защиты от брутфорса прямо внутри демона sshd. Он называется PerSourcePenalties и работает без Fail2Ban, без парсинга логов и без правил firewall. Разбираем, как именно, где это достаточно, а где нет, и как безопасно раскатать на парке серверов.
Как работает механизм штрафов внутри sshd
PerSourcePenalties — это учёт плохого поведения подключающихся адресов непосредственно в памяти процесса-монитора sshd. Каждое подозрительное событие добавляет источнику штрафное время, в течение которого новые соединения с этого адреса не принимаются.
Демон сам классифицирует нарушения по четырём категориям: аварийное завершение соединения, неудачная аутентификация, разрыв до прохождения аутентификации и превышение grace-времени на вход.
По опыту IT For Prof самые неприятные инциденты с защитой SSH происходили не из-за слабых паролей, а из-за того, что внешний баннер молча переставал работать после обновления пакета. Встроенный в sshd механизм этого класса сбоев лишён: пока жив демон — жива и защита.
PerSourcePenalties против Fail2Ban: что получаете и от чего отказываетесь
Сравнивать эти инструменты напрямую некорректно — они работают на разных уровнях.
Fail2Ban читает журналы и банит адреса через firewall, охватывая любой сервис с логами. PerSourcePenalties живёт внутри sshd и закрывает ровно одну поверхность — аутентификацию по SSH.
Что выигрываете:
- Исчезает целый слой инфраструктуры
- Не нужно следить за регулярными выражениями фильтров
- Не нужно держать актуальными правила firewall
- Конфигурация защиты живёт там же, где и конфигурация самого сервиса
Разумная стратегия — разделять обязанности. На узлах, где из публично доступного только SSH, встроенного механизма достаточно. Там, где наружу открыты веб и почта, Fail2Ban остаётся необходимым.
Настройка: параметры и тюнинг порогов
Настройку всегда выносим в отдельный drop-in файл в /etc/ssh/sshd_config.d/. Механизм управляется тремя сущностями:
- PerSourcePenalties — включает учёт и задаёт веса по категориям событий
- PerSourceNetBlockSize — определяет, насколько широко штраф распространяется на соседние адреса
- PerSourcePenaltyExemptList — выводит доверенные сети из-под наказания целиком
После любой правки — обязательная проверка через sshd -t (синтаксис) и sshd -T (фактически применённые значения).
Как не заблокировать самого себя при удалённом администрировании
Главное правило: пока правите защиту, держите вторую, уже открытую SSH-сессию к тому же серверу. Применяйте изменения через systemctl reload ssh, проверяйте подключение из новой сессии.
Доверенные адреса нужно внести в PerSourcePenaltyExemptList до включения механизма, а не после первого инцидента.
Не раскатывайте PerSourcePenalties на весь парк одной командой без заранее проверенного exempt-листа. Мы сталкивались с тем, что узел мониторинга сам набирал штраф и попадал под блокировку по подсети. Лечится тривиально, но в момент инцидента выглядит как массовый сетевой отказ.
Когда PerSourcePenalties не заменяет Fail2Ban
PerSourcePenalties закрывает аутентификацию по SSH — и только её. Перебор на форме входа nginx, попытки подбора по SMTP/IMAP в Postfix, брутфорс панелей управления остаются вне его зоны.
Второе ограничение: механизм противодействует перебору, но не заменяет базовое усиление SSH. В Debian/Ubuntu по умолчанию задано X11Forwarding yes и UsePAM yes — эти значения нужно сознательно подтверждать. Если на узле не нужен форвардинг, AllowAgentForwarding и AllowTcpForwarding стоит явно отключить.
Массовое внедрение: чек-лист и мониторинг
На парке серверов внедряем через шаблон системы управления конфигурациями. Порядок:
- Собрать единый exempt-список управляющих сетей, мониторинга, VPN и резервного копирования
- Сгенерировать drop-in файл из шаблона; ключи конфига регистронезависимы, значения аргументов — чувствительны к регистру
- Прогнать sshd -t на каждом хосте до перезапуска
- Применять через reload, а не restart
- Раскатывать волнами, начиная с пилотной группы
Мониторинг обязателен. Мы снимаем события через journalctl -u ssh -g penalty и считаем уникальные источники, попавшие под штраф. Резкий рост счётчика — либо реальная атака, либо сломанная автоматизация. По опыту именно второй сценарий встречается чаще на старте внедрения.
Финальный штрих — регулярная ревизия. Раз в цикл обслуживания сверяем фактически применённые значения через sshd -T с эталоном в репозитории конфигураций.