Найдите неудачные SSH-входы на Ubuntu

«Нет чёрного или белого, есть только оттенки серого. Нельзя однозначно назвать это хорошим или плохим.»

Иногда нужно заглянуть в эти оттенки серого и найти проблему до того, как она произойдёт. Один из простых, но эффективных способов — поиск неудачных попыток входа по SSH. На Ubuntu эти события чаще всего записывает демон rsyslog в файл /var/log/auth.log.

Важно: не каждая неудачная попытка — признак взлома. Частые попытки с одних и тех же IP — повод к расследованию.

Коротко о SSH

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

Краткое определение: SSH — защищённый сетевой протокол для управления сервером по сети.

Установка OpenSSH

Войдите под root или под пользователем с sudo и выполните:

sudo apt-get update

sudo apt-get install openssh-server -y

После установки можно включить службу SSH:

sudo systemctl enable ssh

Если нужно временно остановить SSH:

sudo systemctl stop ssh

Запустить обратно:

sudo systemctl start ssh

Проверить статус сервиса:

sudo systemctl status ssh

Как найти все неудачные попытки входа по SSH

Неудачные попытки могут быть следствием опечатки пароля, забывчивости пользователя или автоматического перебора паролей.

Простейшая команда для просмотра записей о неудачных входах в auth.log:

grep "Failed password" /var/log/auth.log

Это отфильтрует строки, где явно указано “Failed password”. На некоторых системах логи могут храниться в /var/log/secure (CentOS, RHEL). Примеры команд для них:

grep "Failed" /var/log/secure

grep "authentication failure" /var/log/secure

Можно смотреть через journalctl (Systemd):

journalctl _SYSTEMD_UNIT=ssh.service | egrep "Failed|Failure"

Чтобы получить список IP-адресов, с которых поступали неудачные попытки, и число попыток от каждого IP:

grep "Failed password" /var/log/auth.log | awk '{print $11}' | uniq -c | sort -nr

Примечание: в зависимости от формата логов поле с IP может отличаться (например, $11 или $13). Если вывод пустой, проверьте конкретную строку лога, чтобы определить позицию поля с IP.

Важно: логи могут ротироваться. Чтобы искать в сжатых старых логах, используйте zgrep:

zgrep "Failed password" /var/log/auth.log* | awk '{print $11}' | uniq -c | sort -nr

Быстрая методика расследования неудачных попыток

1. Собрать список IP с большим числом неудачных попыток (см. команду выше).
2. Проверить геолокацию/ASN подозрительных IP.
3. Отключить доступ с подозрительных IP на уровне брандмауэра (ufw/iptables) или временно заблокировать их.
4. Проверить логи на успешные входы с этих IP и на признаки компрометации.
5. Проверить список пользователей и политики паролей.
6. При необходимости сменить пароли, пересмотреть ключи и включить двухфакторную аутентификацию.

Автоматические инструменты и альтернативы

• fail2ban — скрипт, который автоматически блокирует IP после ряда неудачных попыток. Рекомендуется для быстрой защиты.
• DenyHosts — устаревший, но иногда используемый инструмент для анализа логов и блокировок.
• Настройка SSH на использование только ключей (PasswordAuthentication no) и запрет логина root (PermitRootLogin no).
• Использование нестандартного порта уменьшит шум от массовых сканирований, но не заменит другие меры.

Пример конфигурации /etc/ssh/sshd_config для жёсткого режима:

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
AllowUsers adminuser anotheruser

После изменения конфигурации перезапустите SSH:

sudo systemctl restart ssh

Когда простого поиска логов недостаточно

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

Плейбук для быстрой реакции на массовые попытки

1. Собрать список IP и их частоту.
2. Временно заблокировать подозрительные IP через ufw или iptables.
3. Проверить /var/log/auth.log и другие журналы на успешные входы и подозрительную активность.
4. Проверить наличие неизвестных ключей в ~/.ssh/authorized_keys и новых пользователей в /etc/passwd.
5. Если есть подозрение на компрометацию — изолировать сервер, сделать дамп памяти и диска, уведомить команду безопасности.
6. Восстановить сервис из чистого образа при подтверждённом взломе.

Пример блокировки IP через ufw:

sudo ufw deny from 203.0.113.45 to any port 22 proto tcp

Режимы зрелости защиты SSH

• Базовый: пароли включены, стандартный порт.
• Средний: fail2ban, обычные политики паролей, запрет root.
• Продвинутый: только ключи, MFA, аудит логов, автоматическое реагирование и IDS.

Рольовые чеклисты

• Администратор: проверил status SSH, список процессов, активные соединения, обновил пакеты.
• Инженер по безопасности: настроил fail2ban, проверил пробросы портов, настроил мониторинг.
• Операции/DevOps: добавил автоматическое уведомление при превышении порога неудачных попыток.

Критерии приёмки

• Скрипт/команда корректно показывает IP и число попыток за последние N дней.
• Для подозрительных IP выполнена блокировка и проверка на успешные входы.
• Все изменения задокументированы и при необходимости откатываемы.

Полезные советы и нюансы

• Логи ротируются; ищите в auth.log.1 и сжатых auth.log.*.gz с помощью zgrep.
• В разных дистрибутивах поля в логах с IP могут стоять в разных позициях. Перед применением awk проверьте формат строки.
• Не блокируйте легитимные сервисы (CI/CD, резервные системы). Сверьте IP с известными сервисами.

Important: автоматические блокировки помогают, но не заменяют хорошую архитектуру аутентификации и регулярный аудит.

Краткая сводка

Поиск неудачных SSH-входов — базовая, но важная операция для обнаружения подозрительной активности. Используйте grep/journalctl для быстрой диагностики, zgrep для старых логов и автоматизируйте защиту с помощью fail2ban и политики «только ключи». При массовых подозрениях следуйте плейбуку: собрать данные, блокировать, исследовать и при необходимости изолировать сервер.

Если хотите, могу подготовить готовый скрипт на bash для ежедневного отчёта о неудачных попытках и авто-блокировке по порогу.

Конец статьи.