Como se proteger contra milhões de tentativas de login falhadas?

Question

Sempre que acesso meu VPS usando o PuTTY, vejo isso:

Last failed login: Fri Oct  6 17:25:58 UTC 2017 from xx.xxx.xxx.xxx on ssh:notty
There were 2381935 failed login attempts since the last successful login.
Last login: Tue Sep 26 09:30:02 2017 from xx.xxx.xxx.xxx

Eu não sei se está relacionado, mas quando eu faço login, demora mais tempo para carregar, em outros servidores que não conseguem tantos login quanto este, o tempo de carregamento é muito menor.

Você pode me dizer se várias tentativas de login afetam o desempenho do servidor? E há alguma maneira que eu possa proteger contra isso? Quero dizer, minha senha para os servidores é meio que impossível de quebrar, mas existe uma maneira de evitar essas tentativas de login de falha?

Especificações do sistema:

• Nome do ícone : computer-vm
• Chassi : vm
• Virtualização : kvm
• Sistema Operacional : CentOS Linux 7 (Core)
• CPE Nome do SO : cpe: / o: centos: centos: 7
• Kernel : Linux 3.10.0-514.26.2.el7.x86_64
• Arquitetura : x86-64

Answer 1

Então, pode haver uma solução profundamente mais fácil para isso.

As informações que você postou mostram que há 2.381.935 tentativas de login malsucedidas. O que é bem insano. Deixe-me adivinhar: O usuário que você está logando como é… root ? Bem, embora o Fail2Ban seja uma solução decente para interceptar tentativas de login indesejadas, há uma solução muito mais simples: Crie uma nova conta com um novo nome que não root , conceda a esse usuário direitos de administrador via Sudo e então desative root .

Em geral, qualquer servidor Linux em 2017 deve simplesmente não ter a conta root real ativa e utilizável por qualquer motivo. Cada “script kiddie” no mundo tem toneladas de scripts de exploração que tentam hackear a conta root . E todo hacker habilidoso tem ferramentas que tentam hackear root .

Ao criar uma nova conta de usuário com algum nome genérico inteligente que você possa criar e desativar root , você diminuirá instantaneamente sua superfície de ataque e fechará esse ponto de incursão em potencial com pouco ou nenhum esforço.

Alguns administradores do sistema não gostam de desabilitar root por pura preguiça, mas a menos que você esteja de alguma forma restringindo o acesso ao servidor de alguma outra forma - como configurações de firewall baseadas em IP ou endereço MAC filtrado e tal - você abre seu servidor por risco.

    

Answer 2

Além do fail2ban (como sugerido por outros), eu configuraria um servidor OpenVPN no VPS e, em seguida, um cliente em seu sistema e, em seguida, usando um cliente OpenVPN em seu (s) cliente (s) - e usando um firewall para limitar conexões para vir da VPN. Isso ajudará adicionando uma camada extra de proteção / criptografia e ocultando o SSH.

Se as pessoas estão tentando e não conseguindo se conectar, isso pode consumir recursos significativos, mas pode ser algo diferente (DNS reverso não configurado, disco com excesso de assinaturas). Olhe para a hora e o topo para ver o que está atrasando as coisas.