В auth.log обнаружено множество попыток входа по SSH [дубликат]
На этот вопрос уже есть ответ здесь :
Я использую свою собственную дроплет DigitalOcean на Ubuntu. Сегодня я обнаружил, что мое SFTP-соединение с указанной Droplet немного тормозит при работе с ним, поэтому я проверил файлы /var/log/auth.log , чтобы увидеть, что происходит.
Я видел, что за последние 7 дней или около того у меня было огромное количество неудачных попыток входа по SSH с различных IP-адресов (например, один раз в минуту). В основном они выглядят как атаки по словарю, поскольку используется много случайных имен пользователей.
У меня была базовая конфигурация IPTABLES, которая заранее блокирует последовательные SSH-соединения, и с тех пор я увеличил свою безопасность, запретив вход в систему root и изменив свой SSH-порт с 22. Я также изменил свои пароли для входа в систему. в мои привилегированные учетные записи.
Я не знаю, как долго я подвергался этой атаке по словарю, и в моих журналах нет никаких подозрительных успешных попыток входа в систему. Мой вопрос: следует ли мне беспокоиться о потенциальных успешных попытках входа в систему с помощью этой атаки по словарю? Я беспокоюсь, что это боты, которые могли установить вредоносное ПО при успешной попытке входа в систему через root .
1 ответ
Хотя маловероятно, что это успешно выполнилось, если бы у Вас был сильный пароль root, то Вы могли бы проверить на вредоносное программное обеспечение при помощи инструментов как tcptrack видеть, устанавливаются ли какие-либо подозрительно выглядящие связи с сервера.
Запрещая вредоносное программное обеспечение, которые общаются с внешним миром, было бы очень трудно точно определить, где точно потенциальный взломщик вставит, сказал, что вредоносное программное обеспечение, с тех пор, после того как у Вас есть корневой доступ, Вы любой ценой скомпрометированы, и человек имеет полный контроль над всем в системе. Если Вы чувствуете с certanity, что кто-то получил корневой доступ, лучший план действий должен был бы передать все данные, в которых Вы нуждаетесь от капельки и только запускаете, проверка, что лучшие методы безопасности применены так, чтобы такое нападение больше не было возможно
Другой шаг, который можно гарантировать для улучшения безопасности, должен был бы отклонить любой тип аутентификации по паролю и ограничить ее только аутентификацией PublicKey так, чтобы такие атаки с подбором по словарю были неэффективны
Если по какой-либо причине необходимо использовать пароли (который не необходим в большинстве случаев и высоко не рекомендуемый), можно установить knockd для использования порта, стучащего для проверки, взломщик не может выяснить, какой порт ssh идет. Обратите внимание, что это - просто безопасность с помощью мрака, и Вам все еще нужны сильные пароли/пароли.