12 000 попыток входа в сутки: что из этого реально опасно

MAATRIX

Открываете /var/log/auth.log на свежем сервере и видите тысячи строк Failed password за одни сутки — первая реакция почти у всех одна: «меня взламывают». В подавляющем большинстве случаев это не так. Ниже — как быстро отличить фоновый шум сканеров от попытки, которая целится именно в ваш сервер, и на что из этого действительно стоит реагировать.

Почему тысячи попыток входа в сутки — это норма, а не инцидент

Любой сервер с открытым портом 22, доступным из интернета, начинает получать попытки входа в первые минуты после запуска — задолго до того, как о нём кто-то узнал специально. Дело не в том, что кто-то нашёл именно ваш IP и заинтересовался именно вами. В интернете постоянно работают автоматизированные сканеры, которые методично перебирают целые диапазоны адресов и стучатся в стандартные порты — 22, 3389, 21, 23 — просто потому, что это дёшево и не требует разведки. Часть из них — исследовательские проекты и боты индексации, часть — заготовка для ботнетов, которые ищут любой сервер со слабым паролем, чтобы добавить его в свою сеть. Ваш конкретный сервер их не интересует: интересует любой сервер, который ответит на стандартный набор логинов и паролей.

Отсюда и цифры вида «12 000 попыток за сутки» — они не говорят о том, что вас атакуют, они говорят о том, что у вас открыт порт 22 наружу. Точное число будет сильно отличаться от сервера к серверу: зависит от диапазона IP, от того, засветился ли адрес в старых базах, от провайдера. Кто-то увидит несколько сотен попыток, кто-то — многие тысячи. Само по себе число почти ничего не говорит об опасности — важнее структура этих попыток, а не их количество.

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

Признаки фонового шума: когда не о чем беспокоиться

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

• Широкий разброс источников. Попытки идут с десятков и сотен разных IP за сутки, часто из разных стран, без явной привязки к одной подсети или одному провайдеру. Ни один адрес не выделяется числом попыток на фоне остальных.
• Стандартные словари логинов. В логах мелькают root, admin, test, user, oracle, postgres, ubuntu, pi, guest — общий набор, который используют против любого сервера в интернете, а не что-то, что нужно было бы узнать заранее.
• Пароли из типовых утечек. Подбираются простые и «популярные» пароли, комбинации логин=пароль, ничего специфичного для вашей компании, продукта или инфраструктуры.
• Равномерная интенсивность. Попытки распределены по времени плюс-минус ровно, без резких скачков, привязанных к конкретному событию на вашей стороне.
• Ни один аккаунт не выделяется. Атакующие одинаково стучатся в root и в случайные имена — никто не концентрируется на реальном имени пользователя, которое существует у вас в системе.

Если ваша картина логов такая — это ровно то, что видит любой сервер с портом 22 в интернете, и специальной реакции на конкретные IP не требуется. Разумная реакция — это системная защита (о ней ниже), а не разбор каждого IP из тысяч.

Признаки целевой атаки: когда стоит напрячься

Целевая активность выглядит принципиально иначе — она сфокусирована, а не размазана по всему интернету. Несколько признаков, которые стоит воспринимать всерьёз:

• Концентрация на одном аккаунте. Вместо равномерного перебора root/admin/test — десятки и сотни попыток подряд именно в один реальный логин, который существует у вас (например, имя пользователя, под которым вы сами заходите, или имя сервисного аккаунта из деплоя).
• Логины, специфичные для вашей инфраструктуры. Подбирают не общий словарь, а имена, которые могли узнать только изучив вас конкретно: название компании, имя проекта, логины из утечки, связанной именно с вами, адреса вида deploy-maatrix, backup-prod и подобные.
• Рост интенсивности во времени. Не ровный фон, а нарастающая динамика — попытки учащаются, будто с другой стороны подстраивают скорость перебора или расширяют список кандидатов.
• Попытки сразу после публикации адреса или события. Например, скачок активности вскоре после того, как IP засветился в публичном репозитории, в DNS-записи с говорящим именем, в объявлении о запуске проекта.
• Успешные подключения вперемешку с неудачными от одного и того же источника — это уже не разведка, а рабочая попытка, которая нащупывает верную комбинацию.
• Активность с одного и того же узкого блока IP (например, соседние адреса одной подсети) при этом сфокусированная на конкретном логине — сочетание, которое редко бывает у случайных ботов.

Если видите хотя бы два-три таких признака одновременно — это повод посмотреть внимательнее, а не игнорировать как фон.

Как быстро посмотреть, что происходит у вас на сервере

Не нужно вручную листать журнал на тысячи строк — пара команд даёт картину за минуту. На Ubuntu/Debian используется /var/log/auth.log, на RHEL/AlmaLinux — /var/log/secure; там, где логи ушли в journald, тот же результат даёт journalctl.

Сколько всего было неудачных попыток за сутки:

grep "Failed password" /var/log/auth.log | grep "$(date '+%b %e')" | wc -l

Топ IP-адресов по числу попыток — если один адрес резко выделяется на фоне остальных, это уже не «размазанный» шум:

grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | sort -rn | head -20

Топ логинов, которые пытались подобрать — здесь важно не общее число, а появление вашего реального имени пользователя среди частых:

grep "Failed password" /var/log/auth.log \
  | grep -oP '(?<=for )(invalid user )?\K\S+' \
  | sort | uniq -c | sort -rn | head -20

Если логи уже в journald (типично для systemd на свежих дистрибутивах):

journalctl -u ssh --since "24 hours ago" | grep "Failed password" | wc -l

Динамика по часам — резкий рост в последний час на фоне ровного дня — тревожный сигнал сам по себе:

grep "Failed password" /var/log/auth.log \
  | awk '{print $3}' \
  | cut -d: -f1 \
  | sort | uniq -c

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

sudo fail2ban-client status sshd

Полезная привычка — не паниковать от общего числа строк в логе, а сразу смотреть на распределение: по IP, по логинам, по часам. Одна и та же цифра «12 000 попыток» выглядит совершенно по-разному в зависимости от того, размазана она по тысяче адресов или сконцентрирована на десятке.

На что реагировать, а на что нет

Ниже — сводная таблица, которая помогает быстро решить, стоит ли конкретная картина в логах внимания сверх стандартной защиты.

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

Если видите признаки из правой колонки — стоит действовать точечно: посмотреть, есть ли у этого логина вообще смысл существовать (иногда это давно забытый сервисный аккаунт), проверить last и lastlog на предмет успешных входов, при малейшем подозрении на успешный вход — сменить пароль/ключи скомпрометированного аккаунта и пересмотреть, кто и с каких адресов должен иметь доступ в принципе.

Базовая гигиена, которая реально снижает шум

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

Вход по ключу вместо пароля. Это не «ещё одна мера», а базовый переход, после которого перебор пароля перестаёт быть рабочим вектором вообще — подобрать пароль просто не к чему. Подробный разбор с генерацией ключа и настройкой шаг за шагом — в статье про переход на SSH-ключи вместо пароля. Здесь — минимум в /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

и перезапуск службы:

sudo systemctl restart sshd

Перед этим шагом обязательно убедитесь, что ключ уже прописан в ~/.ssh/authorized_keys и вход по нему проверен в отдельной сессии — иначе рискуете остаться без доступа к серверу.

fail2ban или аналог. Он не заменяет отключение паролей, но полезен как дополнительный слой — банит IP, которые слишком активно ошибаются при входе, снижает нагрузку от automated-перебора и подчищает логи от повторов. Установка и настройка джейлов подробно — в статье про fail2ban на Ubuntu 24.04:

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Смена порта SSH — не панацея, но реально снижает шум. Большинство сканеров стучится строго в 22 порт, и после переноса на нестандартный (Port 2222 и подобные в sshd_config) фоновый поток попыток заметно падает — это не решает проблему безопасности сама по себе, но убирает основную массу шума из логов, и на этом фоне становится проще заметить целенаправленную активность, если она появится. Тем, кто именно нашёл ваш сервер и просканировал его порты целиком, смена порта не помешает — но таких на порядки меньше, чем ботов, проверяющих только 22-й. Разбор этого мифа целиком — в статье смена порта SSH решает проблему безопасности?

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

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