Proteger servidor Linux contra brute force em SSH
Minutos após publicar um IP, bots começam a testar root e senhas vazadas no SSH. Este guia mostra camadas de defesa que funcionam em produção sem trancar sua equipe fora do servidor.
O que é brute force em SSH
Brute force em SSH é tentativa automatizada de adivinhar usuário e senha até acertar combinação fraca ou reutilizada. Não exige alvo famoso: qualquer VPS com porta 22 exposta entra em listas globais em poucos minutos. Ataque gera ruído em log, consome CPU do sshd e pode anteceder exploração se senha for fraca.
Objetivo da defesa não é zero tentativas, é tornar sucesso estatisticamente improvável e detectar padrão cedo. Quem hospeda jogo em VPS Ryzen ou servidor dedicado expõe IP público por necessidade: jogadores precisam conectar. SSH bem endurecido evita que comprometimento do shell vire perda do mundo ou bot Discord.
- Atacante usa listas de usuário e senha vazadas da internet.
- Bots não dormem: varredura é contínua e distribuída.
- Sucesso inicial abre porta para minerador, ransomware ou pivot interno.
Sinais de ataque nos logs
Sinais claros aparecem em /var/log/auth.log ou journalctl -u ssh: dezenas de Failed password para root, admin, ubuntu e test em sequência rápida. Invalid user indica dicionário de nomes comuns. Múltiplos IPs diferentes no mesmo minuto sugerem botnet. Pico noturno é normal em VPS BR porque scanners não respeitam fuso.
| Linha típica | Interpretação | Ação |
|---|---|---|
| Failed password for root | Bot testando superusuário | Confirmar PermitRootLogin no |
| Invalid user oracle | Dicionário de serviços | Ruído esperado, monitorar volume |
| Accepted password for deploy | Login senha bem sucedido | Investigar imediatamente se senha deveria estar off |
| Disconnected authenticating user | Tentativa interrompida | Correlacionar com fail2ban ban |
Configure alerta quando contagem de falhas SSH ultrapassar limiar por hora. Uptime Kuma ou script simples com grep evita descobrir campanha dias depois.
Camadas de defesa práticas
Primeira camada: autenticação por chave ED25519 e PasswordAuthentication no. Segunda: PermitRootLogin no e AllowUsers com lista mínima. Terceira: fail2ban ou sshguard banindo IP após N falhas. Quarta: UFW permitindo SSH só de faixas conhecidas quando equipe tem IP fixo.
- Gere chave local: ssh-keygen -t ed25519 -a 100
- Copie para servidor: ssh-copy-id usuario@ip
- Abra segunda sessão SSH e confirme login por chave.
- Edite sshd_config, valide sshd -t, systemctl reload sshd.
- Só então desconecte sessão antiga e teste novamente.
Nunca desative senha nem reinicie sshd sem sessão paralela aberta. Erro de sintaxe ou chave errada tranca equipe inteira até console de recuperação.
Fluxo completo de chaves e sshd está no guia de SSH seguro em VPS Linux. Siga ordem de etapas de lá se for primeira configuração.
fail2ban, UFW e hardening
fail2ban lê log do sshd, conta falhas em janela findtime e aplica ban por bantime via iptables ou nftables. Configuração conservadora para equipe remota: maxretry 5, findtime 600, bantime 3600. Whitelist IP do escritório evita lockout em NAT compartilhado com cuidado. Sempre teste jail.local antes de reiniciar produção.
Exemplo de jail.local enxuto
Seção sshd com enabled true, port ssh, filter sshd, logpath apontando para auth.log, maxretry 5 e bantime 1h. Após editar, use fail2ban-client reload e fail2ban-client status sshd para confirmar jail ativo.
Combine com firewall UFW em VPS Ubuntu: default deny incoming, allow 22/tcp ou porta customizada documentada, allow portas do jogo explicitamente. Docker publicado exige revisão extra porque pode contornar UFW; veja instalar Docker em VPS para integração segura.
- PasswordAuthentication no após validar chave.
- PermitRootLogin no ou prohibit-password se root excepcional.
- AllowUsers lista explícita de contas humanas.
- fail2ban instalado e habilitado no boot.
- UFW ativo com regra mínima documentada.
Operação contínua em VPS e dedicado
Mudar porta SSH reduz ruído de bot simples mas não substitui chave forte. Console de recuperação do provedor é rede de segurança quando algo dá errado. Em servidor dedicado ou VPS exposta a internet, rotina trimestral revisa authorized_keys, remove chaves de ex funcionário e confirma que PasswordAuthentication permanece desligado após upgrade do sistema.
Compare planos em VPS root no Brasil quando projeto mistura Minecraft, bot e painel no mesmo host. Hardware exclusivo em servidores dedicados reduz vizinho barulhento mas não elimina necessidade de SSH endurecido. Detalhes da rede StreetHosting estão em infraestrutura.
Backup de chaves e configuração segue estratégia de backup 3-2-1: exporte lista de authorized_keys, jail.local e sshd_config para storage externo criptografado. Perder servidor dói menos quando reconstruir acesso leva minutos, não horas de ticket.
- Agendar revisão trimestral de chaves e permissões sudo.
- Testar console de recuperação uma vez por semestre.
- Documentar quem possui chave de produção e contato de emergência.
- Após incidente, rotacionar chaves e revisar logs de Accepted.
Perguntas frequentes
- Mudar porta SSH basta?
- Reduz volume de bots genéricos, mas não é defesa real. Segurança vem de chave forte, senha remota desligada e fail2ban. Porta obscura sozinha cai em scan completo eventualmente.
- fail2ban pode me bloquear?
- Sim se equipe errar senha várias vezes ou NAT corporativo compartilhar IP. Use whitelist para IPs estáveis e maxretry conservador. Documente procedimento de desban pelo console do host.
- Posso manter senha para emergência?
- Caminho mais seguro é console de recuperação do provedor e política clara de chaves. Se senha for inevitável, restrinja origem por VPN ou faixa IP e mantenha senha longa única.
- Quanto tempo leva para começar ataque?
- Em VPS nova com IP público, tentativas automáticas costumam aparecer em minutos. Por isso hardening deve ser primeiro passo após criar instância, antes de instalar Minecraft ou bot.
Próximo passo
Ver planos VPS
VPS root no Brasil com NVMe e AntiDDoS.
Guias relacionados
SSH seguro em VPS Linux: chaves, senhas, fail2ban e hábitos que evitam invasão
SSH costuma ser o primeiro alvo em qualquer VPS com IP público. Este guia mostra um fluxo prático para reduzir risco sem complicar a rotina: chave ED25519, login sem senha, acesso administrativo com sudo, bloqueio de tentativas automáticas e revisão periódica de chaves autorizadas.
Firewall UFW em VPS Ubuntu: regras seguras sem travar o servidor
UFW facilita a configuração de firewall no Ubuntu, mas a ordem das regras continua sendo decisiva. Este guia mostra como ativar sem perder acesso SSH, como liberar apenas o necessário e como revisar regras quando Docker e serviços web entram em cena.
Como instalar Docker no Ubuntu 22.04 ou 24.04 em VPS (guia direto ao ponto)
Instalar Docker em VPS Ubuntu com estabilidade depende de fonte de pacote correta e validação em etapas. Neste guia, você configura repositório oficial, instala Engine e Compose, testa o daemon e aplica cuidados básicos de segurança antes de subir aplicações.