Como monitorar tentativas de login SSH malsucedidas no VPS Print

Como Monitorar Tentativas de Login SSH Malsucedidas no seu VPS

Oi! Aqui é a Sensei da GeHost 🥋 Se você tem um VPS com acesso SSH, provavelmente já reparou (ou vai reparar, mais cedo ou mais tarde) que existem robôs pela internet inteira tentando adivinhar senha de servidor o dia todo. É chato, mas é normal — e a boa notícia é que dá pra ficar de olho nisso com poucos comandos. Vamos juntos, com calma, que não tem mistério nenhum.

Por que isso importa? Monitorar tentativas de login falhas te ajuda a perceber cedo se alguém está tentando "chutar" a senha do seu servidor (o famoso ataque de força bruta) e a tomar providências antes que vire um problema de verdade.

1. Onde ficam registradas as tentativas de login

Todo acesso SSH — bem-sucedido ou não — fica registrado num arquivo de log do próprio sistema operacional. O caminho varia um pouco conforme a distribuição Linux do seu VPS:

• Debian/Ubuntu: /var/log/auth.log
• CentOS/AlmaLinux/RHEL: /var/log/secure

Não sabe qual distribuição roda no seu VPS? Sem problema — se tiver dúvida, é só chamar o suporte pelo painel.gehost.com.br que a gente confirma pra você.

2. Vendo as tentativas malsucedidas na prática

Conecte no seu VPS via SSH normalmente e rode um destes comandos, de acordo com o sistema:

1. Debian/Ubuntu:
   grep "Failed password" /var/log/auth.log
2. CentOS/AlmaLinux/RHEL:
   grep "Failed password" /var/log/secure

Isso vai listar todas as linhas onde alguém digitou (ou tentou digitar) uma senha errada — com data, hora e o IP de origem da tentativa. Se a lista vier enorme, é sinal de que seu servidor está sendo "batido" por bots — o que, sozinho, não significa que alguém entrou, só que estão tentando.

3. Contando quantas tentativas cada IP fez

Pra ter uma visão mais organizada (em vez de rolar linha por linha), você pode contar quantas vezes cada IP tentou e errar:

• Debian/Ubuntu:
  grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head
• CentOS/AlmaLinux/RHEL:
  grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head

O resultado mostra os IPs que mais insistiram, do maior pro menor número de tentativas. Se um único IP aparece com centenas ou milhares de tentativas, esse é o "suspeito de sempre" de um ataque automatizado.

4. Vendo os últimos logins que DERAM CERTO (pra comparar)

Além das falhas, vale conferir os acessos que tiveram sucesso, pra confirmar que só entrou quem devia mesmo entrar:

last -a

Esse comando mostra os últimos logins bem-sucedidos, com data, hora e IP de origem. Se aparecer um IP ou horário que você não reconhece, é hora de investigar com mais atenção (e trocar a senha, por segurança).

5. Boas práticas pra reduzir as tentativas (e dormir tranquilo)

Só olhar o log já ajuda bastante, mas dá pra ir além e diminuir bastante esse "barulho" de tentativas. Algumas medidas comuns em servidores Linux:

• Usar autenticação por chave SSH em vez de senha, sempre que possível — é bem mais difícil de "adivinhar".
• Desabilitar o login direto do usuário root via SSH, preferindo um usuário comum com permissões elevadas quando necessário.
• Trocar a porta padrão do SSH (22) por outra, o que já derruba boa parte das tentativas automáticas genéricas.
• Usar uma ferramenta de bloqueio automático (como o conhecido fail2ban), que identifica IPs com muitas tentativas falhas seguidas e bloqueia automaticamente por um tempo.

Se você não se sente confortável mexendo nessas configurações sozinho, sem problema nenhum — é exatamente pra isso que a gente está aqui. Abra um chamado pelo painel.gehost.com.br contando o que você percebeu (por exemplo, "muitas tentativas vindas do mesmo IP") que a equipe te orienta no que for preciso.

6. Quando devo me preocupar de verdade?

Ver tentativas falhas no log, isoladas, é o dia a dia normal da internet — não precisa entrar em pânico. Fique mais atento se notar:

• Um login bem-sucedido (no last -a) de um IP ou horário que você não reconhece;
• Comportamento estranho no servidor (arquivos alterados, processos desconhecidos, lentidão fora do padrão);
• Um volume de tentativas muito acima do normal, de um IP só, em pouco tempo.

Em qualquer um desses casos, é melhor trocar a senha (ou a chave) na hora e falar com a gente pelo painel — quanto antes a gente olhar junto, melhor.

Prontinho! Com esses comandos você já consegue acompanhar sozinho quem está batendo na porta do seu servidor. E lembra: na dúvida, chama a gente — estamos aqui pra isso. 🙂