Does this mean that someone is trying to brute force the root password on this machine over SSH? Or is it something less nefarious?
Poderia ser tentativas de força bruta na via SSH, mas mesmo que fosse "nefasto" eu não perderia o sono por causa disso. A maioria dos servidores acessíveis publicamente na Internet é rastreada pelos invasores o tempo todo. Alguém que praticamente “envolve a articulação” não é nada para perder o sono; penetração real do sistema é.
Heck, acabei de verificar o auth.log em um servidor público que gerencio e contei mais de 2000 tentativas de "falha de autenticação" nas últimas 24 horas quando executei este comando:
sudo grep "authentication failure;" /var/log/auth.log | wc -l
Parece assustador, mas honestamente, quem se importa? Uma verificação visual rápida das entradas de log em auth.log usando uma versão ligeiramente modificada do comando acima:
sudo grep "authentication failure;" /var/log/auth.log
… mostra-me coisas como esta:
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
Observe como todas as tentativas de tentativas de acesso estão na conta root ? Em qualquer sistema que eu configure, root é castrado imediatamente. Então essas tentativas são infrutíferas no meu caso. Portanto, se você verificar seu auth.log e vir toneladas de tentativas para ssh no sistema por meio da conta root , certifique-se de que a conta root do seu sistema esteja completamente desativada para excluir essa preocupação da lista.
Após as tentativas da conta root , se você vir acessos de nomes de usuários aparentemente aleatórios para o sistema, isso também é outra tentativa de invadir o sistema. E, a menos que esses nomes de usuário equivam a algum nome de usuário em seu sistema, eu também não me preocuparia com eles.
Agora, alguns sysadmins diriam que a melhor solução para esse problema é simplesmente desabilitar a autenticação por senha completamente do SSH e usar apenas pares de chaves SSH, mas eu costumo pensar que isso é um exagero. Os pares de chaves SSH não são fracos, não são, mas se os métodos de acesso de um sistema forem configurados de forma adequada e segura desde o primeiro dia, e as senhas forem robustas o suficiente para não serem facilmente invadidas, o sistema será bastante seguro. Isso ocorre porque a maior vulnerabilidade em servidores da Web modernos é o aplicativo da Web frontal, na verdade, sendo executado no próprio servidor, e não em coisas como o SSH.
No final do dia, eu não me preocuparia com esses tipos de tentativas aleatórias de "discagem de guerra", mas antes seria preventivamente racional, certificando-se de que o próprio servidor tenha a conta de usuário root desabilitada. Se você ainda opera um servidor público em 2015 com a conta root ativada, basicamente está pedindo dores de cabeça a longo prazo.