Instalei o OSSEC no meu servidor e recebi relatórios semelhantes aos seguintes:
Jan 11 19:27:03 Daddy sshd[14459]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.215.184.93 user=root
Jan 11 19:26:54 Daddy sshd[14457]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=58.215.184.93 user=root
Repetida cerca de 10 vezes por email. Até agora não passou um dia sem 3 ou 4 desses e-mails da OSSEC. É claro que minha emoção inicial é um pouco de raiva e "como eles ousam tentar invadir minha caixa!" mas eu acho que esse é o estado da rede hoje em dia. No outro dia eu também tive alguém tentar com o usuário bin
Também recebi esta mensagem:
Jan 12 02:04:07 Daddy sshd[16109]: reverse mapping checking getaddrinfo for static-52-53.mk-net.ru [91.211.52.53] failed - POSSIBLE BREAK-IN ATTEMPT!
(novamente, com várias repetições)
Eu sei que pelo menos uma fonte benigna do mapeamento reverso vem do freenode quando eles tentam se certificar de que você não é uma botnet provável, mas eu não fui verificar sobre essa fonte.
Somos bastante sensíveis sobre a questão das vulnerabilidades, especialmente porque um servidor anterior foi invadido (provavelmente) pelo phpMyAdmin.
Então, obviamente, qualquer conselho / recursos para proteger nosso servidor seria apreciado, mas minha principal questão é esta: devemos nos preocupar com essas tentativas de invasão? O usuário root não tem senha (login desativado), então é seguro ignorar esses logins com falha? Existe mais alguma coisa que eu poderia ou deveria fazer para limitar as possíveis vulnerabilidades ao longo desta avenida? Este sistema está atrás de um roteador com apenas portas essenciais (por exemplo, serviços que estamos usando) abertas (ssh, apache e postfix).
Sim, você pode definitivamente ignorar as tentativas fracassadas da raiz se o login do root sobre o SSH estiver desabilitado - e as falhas de DNS reverso não valem a pena se preocupar; eles podem muito bem ser de um invasor, mas é apenas a configuração inconsistente do ISP.
Se você quiser dormir um pouco melhor, dê uma olhada no fail2ban - ele pode ser configurado para bloquear temporariamente os IPs dos atacantes após falhas repetidas.
Eu deveria estar preocupado? somente se você não tiver certeza sobre como ela está garantida.
Com o SSH, a forma mais alta de segurança é forçar a chave & login de frase secreta.
Você pode reduzir drasticamente (mas não interromper) as tentativas de login no SSH, mas alterando o número da porta do padrão 22 para outra coisa. Ele não faz nada para reforçar a segurança, mas desencoraja muitos testes automatizados que sondam os números de porta comuns para ver se há um serviço de escuta.
Se for prático, permita somente conexões TCP à porta 22 de locais conhecidos através do uso de suas regras de firewall. Caso contrário, existem métodos para bloquear / desativar o firewall de várias tentativas de conexão com falha nesses locais. O fail2ban é um script que faz isso (como já foi mencionado por Shane). Eu posso recomendá-lo como eu usei antes.