Ao fazer isso, ps -efHvejo muitos dos seguintes itens, onde 14:24 é basicamente a hora atual do sistema. Esses processos continuam aparecendo a cada minuto.
root 6851 1 0 14:24 ? 00:00:00 sshd: root [priv]
sshd 6852 6851 0 14:24 ? 00:00:00 sshd: root [net]
root 6869 6851 1 14:24 ? 00:00:00 sshd: root [pam]
root 6861 1 0 14:24 ? 00:00:00 sshd: root [priv]
sshd 6863 6861 0 14:24 ? 00:00:00 sshd: root [net]
root 6874 6861 0 14:24 ? 00:00:00 sshd: root [pam]
root 6865 1 0 14:24 ? 00:00:00 sshd: root [priv]
sshd 6866 6865 0 14:24 ? 00:00:00 sshd: root [net]
root 6875 6865 0 14:24 ? 00:00:00 sshd: root [pam]
root 6872 1 1 14:24 ? 00:00:00 sshd: root [priv]
sshd 6873 6872 0 14:24 ? 00:00:00 sshd: root [net]
root 6876 6872 0 14:24 ? 00:00:00 sshd: root [pam]
Isso significa que alguém está tentando forçar a senha de root nesta máquina por meio de SSH? Ou é algo menos nefasto?
Responder1
Isso significa que alguém está tentando forçar a senha de root nesta máquina por meio de SSH? Ou é algo menos nefasto?
Poderiam ser tentativas de força bruta via SSH, mas mesmo que fosse “nefasto” eu não perderia o sono por causa disso. Quase todos os servidores acessíveis publicamente na Internet são investigados por invasores o tempo todo. Alguém virtualmente “revestindo o baseado” não é motivo para perder o sono; a penetração real do sistema é.
Caramba, acabei de verificar auth.logem um servidor público que gerencio e conto mais de 2.000 tentativas de “falha de autenticação” nas últimas 24 horas quando executo este comando:
sudo grep "authentication failure;" /var/log/auth.log | wc -l
Parece assustador, mas honestamente, quem se importa? Uma rápida verificação visual das entradas de log auth.logusando uma versão ligeiramente modificada do comando acima:
sudo grep "authentication failure;" /var/log/auth.log
…me mostra coisas assim:
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 acesso estão na rootconta? Em qualquer sistema que eu configure, rooté castrado imediatamente. Portanto, essas tentativas foram infrutíferas no meu caso. Portanto, se você verificar auth.loge ver inúmeras tentativas de sshentrar no sistema por meio da rootconta, certifique-se de que roota conta do seu sistema esteja completamente desativada para tirar essa preocupação da lista.
Após as roottentativas de conta, se você vir acessos de nomes de usuário aparentemente aleatórios ao seu sistema, isso também é outra tentativa de hackear o sistema. E a menos que esses nomes de usuário correspondam a algum nome de usuário em seu sistema, eu também não me preocuparia com eles.
Agora, alguns administradores de sistemas diriam que a melhor solução para esse problema é simplesmente desabilitar completamente a autenticação de senha do SSH e usar apenas pares de chaves SSH, mas tendo a achar que isso é um exagero. Não estou dizendo que os pares de chaves SSH são fracos - eles não são - mas se os métodos de acesso de um sistema forem configurados de maneira saudável e segura desde o primeiro dia, e as senhas forem robustas o suficiente para não serem facilmente hackeadas, então o sistema é bastante seguro. Isso ocorre porque a maior vulnerabilidade nos servidores web modernos é o aplicativo web frontal em execução no próprio servidor e não coisas como SSH.
No final das contas, eu não me preocuparia com esses tipos de tentativas aleatórias de “discagem de guerra”, mas sim seria preventivamente racional ao garantir que o próprio servidor tenha a rootconta do usuário desativada. Se você ainda opera um servidor público em 2015 com a rootconta habilitada, basicamente está pedindo dores de cabeça no longo prazo.