Защиту от брутфорса на сервере: частые ошибки и решения

MAATRIX

Вы поставили Fail2ban, сменили порт SSH и думаете, что защита от брутфорса работает. А в логах по-прежнему тысячи попыток входа, и однажды кто-то подберёт пароль. Проблема почти всегда не в инструментах, а в мелких ошибках настройки. Разберём самые частые из них и как их закрыть за один вечер.

Первое решение: уберите то, что брутфорсить

Главная ошибка — оставить парольный вход по SSH и потом героически его защищать. Пока пароль принимается, у атакующего есть цель. Уберите цель — и брутфорс станет бессмысленным.

Сгенерируйте ключ на своей машине и загрузите его на сервер:

ssh-keygen -t ed25519 -C "you@example"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@ВАШ_IP

Проверьте, что вход по ключу работает, и только потом отключите пароль в /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin prohibit-password
KbdInteractiveAuthentication no

Перезапустите демон: systemctl restart ssh. Не закрывайте текущую сессию, пока не проверите вход из нового окна. После этого 99% брутфорса отваливается сам: подбирать нечего.

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

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

Ошибка: Fail2ban стоит, но не банит

Классика — Fail2ban установлен, сервис запущен, а fail2ban-client status sshd показывает ноль забаненных при явных атаках в логах. Причин обычно три.

Во-первых, вы правили /etc/fail2ban/jail.conf вместо jail.local. Основной файл перезаписывается при обновлении пакета, поэтому все правки делайте только в jail.local:

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Во-вторых, неверный backend или путь к логу. На Ubuntu 24.04 SSH пишет в journald, а не в /var/log/auth.log. Укажите системный бэкенд:

[sshd]
enabled = true
backend = systemd
maxretry = 3
findtime = 10m
bantime = 1h

В-третьих, после правок вы забыли перечитать конфиг: systemctl reload fail2ban. Проверьте, что джейл поднялся: fail2ban-client status.

Ещё один незаметный источник проблемы — фильтр не совпадает с форматом строк в вашей версии OpenSSH. Формулировки сообщений о неудачном входе меняются от релиза к релизу, и старый регэксп в фильтре просто не находит нужные строки. Если вы обновляли систему, сверьте, что установленный пакет Fail2ban свежий, а фильтр sshd соответствует текущему формату журнала. Быстрый способ убедиться, что фильтр вообще что-то ловит, — прогнать его по реальному логу командой fail2ban-regex, которая покажет число совпадений. Ноль совпадений при явных атаках означает, что дело именно в фильтре или бэкенде, а не в самих правилах бана.

Не полагайтесь на то, что «раз сервис запущен, значит защищает». Fail2ban — это набор независимых джейлов, и каждый нужно проверять отдельно. Запущенный демон с неработающим джейлом создаёт ложное чувство безопасности, которое хуже честного его отсутствия.

Ошибка: слишком мягкие или слишком злые лимиты

maxretry = 5 и bantime = 600 — это приглашение. Бот делает пять попыток, ждёт десять минут и продолжает. Для реальной защиты держите maxretry = 3, findtime = 10m и bantime от часа, а для повторных нарушителей включите рецидив:

[recidive]
enabled = true
bantime = 1w
findtime = 1d
maxretry = 5

Обратная крайность тоже вредит: bantime = -1 (вечный бан) плюс агрессивный maxretry = 1 рано или поздно заблокирует вас самих после опечатки в ключе или смены IP. Разумный баланс — временные, но длинные баны и обязательный whitelist своих адресов через ignoreip.

Ошибка: фаервол открыт наружу целиком

Fail2ban реагирует постфактум — уже после попыток. Правильнее вообще не пускать чужих к портам управления. Частый промах: ufw установлен, но правила разрешают всё подряд, либо фаервол вовсе выключен, потому что «мешал».

Минимальный разумный набор для веб-сервера:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80,443/tcp
ufw enable

Если у вас статический домашний или офисный IP, ограничьте SSH только им — тогда брутфорсить порт из интернета физически не выйдет:

ufw allow from 203.0.113.10 to any port 22 proto tcp

Провайдер тоже влияет: у MAATRIX сервер выдаётся с root-доступом и чистым выделенным IP, так что вы с первой минуты настраиваете фаервол под себя, а не разгребаете чужое наследие на общем адресе.

Ошибка: порт сменили, а нагрузку не убрали

Перенос SSH с 22 на нестандартный порт часто подают как «защиту». На деле это лишь снижает шум в логах: массовые сканеры бьют по 22, но целевой скан находит новый порт за минуту. Смена порта полезна как гигиена, но не заменяет ключи и фаервол.

Если меняете порт, не забудьте три вещи разом: строку Port 2222 в sshd_config, правило ufw allow 2222/tcp и — обязательно — обновление джейла Fail2ban, иначе он будет слушать несуществующий порт 22 и снова не забанит никого. Проверяйте связку целиком, а не по отдельности.

Ошибка: забыли про панель, базу и почту

Брутфорсят не только SSH. Открытые в мир phpMyAdmin, панель управления, WordPress wp-login.php, RDP на Windows-сервере, IMAP/SMTP — всё это цели. Частая ошибка — закрыть SSH идеально и оставить настежь остальное.

Заведите для этих сервисов отдельные джейлы Fail2ban (nginx-http-auth, postfix-sasl, wordpress) и вынесите админ-панели за басик-авторизацию Nginx или, лучше, за VPN. Для веб-приложений добавьте капчу на форму входа и лимит запросов средствами Nginx:

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

Так подбор пароля к панели упрётся в пять попыток в минуту вместо тысяч.

Как убедиться, что защита реально работает

Не верьте на слово — проверьте. Посмотрите, кого банит система прямо сейчас, и растёт ли счётчик:

fail2ban-client status sshd
journalctl -u ssh --since "1 hour ago" | grep -c "Failed password"

Если Failed password стабильно нули, а забаненные появляются — связка работает. Раз в неделю проверяйте, что после перезагрузки Fail2ban и ufw стартуют автоматически (systemctl is-enabled fail2ban ufw). Держите бэкап конфигов SSH и джейлов, чтобы после переустановки поднять защиту за пять минут. Этого набора хватает, чтобы брутфорс перестал быть вашей проблемой.

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