Означает ли это, что кто-то пытается взломать пароль root на этой машине через SSH? Или это что-то менее гнусное?
Это могут быть попытки перебить силы через SSH, но даже если бы это было «гнусно», я бы не потерял из-за этого сон. Почти любой сервер, который является общедоступным в Интернете, злоумышленники постоянно проверяют. Кому-то, практически «стягивающему сустав», нечего терять сон; Фактическое проникновение в систему есть.
Черт, я только что проверил auth.log на общедоступном сервере, которым я управляю, и насчитал более 2000 попыток «сбоя аутентификации» за последние 24 часа при выполнении этой команды:
sudo grep "authentication failure;" /var/log/auth.log | wc -l
Звучит страшно, но честно, кого это волнует? Быстрая визуальная проверка записей журнала в auth.log с использованием слегка измененной версии вышеуказанной команды:
sudo grep "authentication failure;" /var/log/auth.log
... показывает мне такие вещи:
Mar 15 07:02:09 hostname sshd[2213]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.35 user=root
Mar 15 07:02:19 hostname sshd[2236]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.35 user=root
Mar 15 07:02:31 hostname sshd[2355]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.35 user=root
Обратите внимание, что все попытки доступа выполняются для учетной записи root ? На любой системе, которую я настроил, root get сразу кастрируется. Так что эти попытки в прошлом бесплодны. Поэтому, если вы проверите свой auth.log и увидите множество попыток ssh войти в систему через учетную запись root , убедитесь, что root учетная запись вашей системы полностью отключена, чтобы исключить эту проблему из списка.
Прошлые попытки учетной записи root , если вы видите доступ к вашей системе, казалось бы, случайных имен пользователей, это тоже очередная попытка взлома системы. И если эти имена пользователей не будут совпадать с какими-либо именами в вашей системе, я бы не стал беспокоиться о них вообще.
Теперь некоторые системные администраторы говорят, что лучшим решением этой проблемы является простое отключение аутентификации по паролю полностью из SSH и использование только пар ключей SSH, но я склонен считать, что это излишне. Не говоря уже о том, что пары ключей SSH являются слабыми - они не являются - но если методы доступа системы настроены разумно и надежно с первого дня, и пароли достаточно надежны, чтобы их было нелегко взломать, то система достаточно безопасна. Это связано с тем, что самой большой уязвимостью на современных веб-серверах является фронтальное веб-приложение, работающее на самом сервере, а не такие вещи, как SSH.
В конце концов, я бы не стал беспокоиться о таких случайных попытках «военного набора», а предпочел бы быть рациональным, убедившись, что на самом сервере отключена учетная запись пользователя root . Если вы все еще используете публичный сервер в 2015 году с включенной учетной записью root , в основном вы просите о головной боли в долгосрочной перспективе.
