Брутфорс SSH: что действительно помогает, а что просто шум в логах

MAATRIX

Откройте /var/log/auth.log на любом сервере с белым IP — и через пять минут там уже будут первые попытки подбора пароля по SSH. Это фоновой шум интернета: боты сканируют весь диапазон IPv4, а не охотятся именно за вами. Вокруг темы накопилось много ритуалов, которые дают чувство защищённости, но почти не меняют реальный риск. Разберём меры по гамбургскому счёту — что закрывает атаку, а что просто перекладывает шум из одного лога в другой.

Что вообще происходит, когда вас "брутфорсят"

В подавляющем большинстве случаев "брутфорс SSH" — не целевая атака, а массовое сканирование. Боты стучатся в порт 22 с типовыми парами логин/пароль: root/root, admin/admin123, ubuntu/ubuntu. Цель — любой сервер со слабым паролём, не конкретно ваш.

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

Второй момент: большинство обсуждаемых "мер защиты" направлены не на саму угрозу, а на объём логов и нагрузку на sshd. Это другая задача — путать её с задачей "не дать взломать сервер" опасно, это создаёт ложное чувство безопасности.

Аутентификация по ключу вместо пароля — мера номер один

Это единственная мера, которая меняет саму природу атаки, а не её объём. Пароль — секрет, который можно угадать, подсмотреть или переиспользовать на другом сервисе. SSH-ключ — пара, где подбор закрытой части вычислительно неосуществим.

# на клиенте
ssh-keygen -t ed25519 -C "you@example.com"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server_ip

После проверки входа по ключу в отдельной сессии (не закрывая текущую!) отключаем пароль в /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

sudo systemctl restart sshd

Типичная грабля — права доступа: ~/.ssh должен быть 700, authorized_keys — 600. Ошибётесь — рискуете остаться без доступа при отключённом пароле. Подробный разбор с типовыми ошибками — в статье «Как установить SSH-ключи вместо пароля на VPS».

Почему это мера №1: она не снижает вероятность подбора — она убирает подбор как рабочий вектор целиком. Всё остальное в статье в лучшем случае снижает вероятность или объём атаки, а ключи убирают саму атаку. Используйте ed25519 — он быстрее rsa и даёт не худший запас прочности; rsa-4096 оставьте как запасной вариант для легаси-клиентов.

Смена порта SSH — security through obscurity

Смена порта с 22 на, скажем, 2222 — самый популярный совет "для новичков" и самая переоцененная мера в списке. Она не делает сервер сложнее взломать — она делает его сложнее *найти* сканеру, который проверяет только стандартные порты.

Часть примитивных ботов действительно стучится только в 22-й порт, и после смены их трафик в логах исчезает. Но целенаправленный скан (nmap -p-) находит открытый sshd за минуты независимо от порта — сервис не прячется, он просто слушает другой сокет. Значительная доля современных сканеров уже проверяет топ-1000 или все 65535 портов.

# /etc/ssh/sshd_config
Port 2222

sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp
sudo systemctl restart sshd

Мы отдельно разбирали этот миф в статье «Смена порта SSH решает вопрос безопасности»: единственный реальный эффект — снижение шума в auth.log. Как мера безопасности сама по себе она равна нулю против целевой атаки. Делайте это ради гигиены логов, но не считайте защитой.

fail2ban — частичная мера, а не решение

fail2ban — полезный инструмент с чёткими границами эффективности. Он читает лог аутентификации, находит N неудачных попыток с одного IP за заданное время и банит его через iptables/nftables.

sudo apt install fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = ssh
maxretry = 4
findtime = 600
bantime = 3600

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Что fail2ban реально даёт: резко снижает эффективность быстрого перебора с одного IP и нагрузку от однопоточных ботов. Подробности установки — в статье «Как установить fail2ban на VPS».

Что не даёт:

• Распределённый перебор. Если атака идёт с ботнета из тысяч IP по 2-3 попытки с каждого, счётчик maxretry на IP никогда не срабатывает — классическое пороговое ограничение по одному адресу легко обходится именно так.
• Медленный перебор. Одна попытка в час с одного IP — findtime истекает раньше, чем накопится порог.
• Утечку рабочих credentials. fail2ban реагирует на количество неудач; если пара логин/пароль верна с первой попытки, банить нечего.

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

Многофакторная аутентификация — второй по значимости рубеж

Если полностью отказаться от пароля нельзя (легаси-системы, требования аудита), MFA — следующая по силе мера после ключей. Обычно это TOTP-код через PAM-модуль libpam-google-authenticator.

sudo apt install libpam-google-authenticator
google-authenticator

В /etc/pam.d/sshd:

auth required pam_google_authenticator.so

В sshd_config:

KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

Обратите внимание: правильная схема — ключ плюс TOTP-код, а не пароль плюс TOTP. MFA поверх пароля оставляет пароль первым фактором, который можно угадать; MFA поверх ключа — два независимых секрета, ни один из которых не передаётся по сети. Настройка с типовыми граблями (рассинхронизация времени, коды восстановления) — в статье «Двухфакторная аутентификация SSH на VPS».

Минус — операционный: интерактивный TOTP-запрос ломает автоматический вход CI/CD и cron-скриптов. Для таких сценариев MFA обычно не применяют, а компенсируют ограничением по IP и раздельными сервисными ключами с command= в authorized_keys.

Ограничение доступа по IP и сети — недооценённая мера

Если есть возможность работать с предсказуемого набора адресов (офис, VPN, статический IP), ограничение SSH по source-адресу в фаерволе — одна из сильнейших мер, которую обсуждают незаслуженно реже ключей и fail2ban.

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw deny 22/tcp

Или через VPN: sshd слушает только на VPN-интерфейсе (ListenAddress 10.8.0.1). Для внешнего сканера порт 22 просто закрыт — соединение таймаутится, и сервер невидим в принципе, а не "менее заметен", как при смене порта.

Компромисс: без статического IP или VPN-инфраструктуры это неудобно и рискует заблокировать вас самих при смене сети. Комбинация "VPN + ключи + MFA" — практический максимум того, что можно сделать на уровне SSH-доступа.

Иерархия мер по реальной эффективности

Длина пароля снижает один риск — онлайн-перебор, — но не убирает остальные каналы утечки, поэтому не заменяет отказ от пароля. А passphrase на самом приватном ключе — обязательная привычка: без неё кража файла ключа с ноутбука или незашифрованного бэкапа равна мгновенному доступу к серверу.

Частые вопросы