Como tirar o SSH do alcance de ataques de força bruta

O que é brute force em SSH#

Brute force em SSH é a tentativa automatizada de adivinhar usuário e senha até acertar uma combinação fraca ou reutilizada. Não é preciso ser um alvo famoso: qualquer IP com a porta 22 aberta entra em listas de varredura em poucos minutos. As variações mais comuns são três.

• Dicionário: nomes comuns como root, admin, ubuntu e test, com senhas óbvias.
• Senhas vazadas: combinações reais de vazamentos de outros serviços, testadas porque muita gente repete senha.
• Password spraying distribuído: milhares de IPs, cada um tentando uma ou duas senhas, para não disparar limites por IP. É o formato que escapa do Fail2Ban.

Um acerto costuma virar minerador de criptomoeda, envio de spam, ataque a terceiros a partir do seu IP ou sequestro de dados. O objetivo da defesa não é zerar as tentativas, que nunca param, e sim tornar o sucesso impossível e reduzir a superfície exposta.

Sinais de ataque nos logs#

No Ubuntu 24.04 o serviço se chama ssh, e os eventos ficam no journal e em /var/log/auth.log. Três consultas dão o quadro:

# falhas de senha na última hora sudo journalctl -u ssh --since "1 hour ago" | grep -c "Failed password" # IPs que mais tentaram usuários inexistentes hoje sudo journalctl -u ssh --since today | grep "Invalid user" | awk '{print $(NF-2)}' | sort | uniq -c | sort -rn | head # logins que deram certo sudo journalctl -u ssh | grep "Accepted"

Muitos IPs diferentes no mesmo minuto indicam uma botnet. Picos de madrugada são normais, porque varreduras não respeitam fuso. O sinal que importa de verdade é uma linha Accepted que você não reconhece.

Escolha o modelo de exposição#

Com a senha desligada, adivinhar o acesso deixa de ser possível na prática: o robô precisaria da sua chave privada. O risco que sobra é uma chave roubada ou uma falha no próprio servidor SSH. Em 2024, a falha conhecida como regreSSHion permitia execução remota antes da autenticação em várias versões do OpenSSH. Servidores com o SSH fechado para a internet não estavam ao alcance. Por isso a pergunta estratégica é quem consegue chegar à porta.

Qualquer que seja o modelo, as duas próximas seções são obrigatórias: endurecer o sshd e testar sem se trancar fora.

Endurecer o sshd com um arquivo próprio#

Antes, a chave precisa estar instalada e funcionando para um usuário com sudo. O passo a passo está em login por chave SSH sem senha e, para quem usa Windows, em chave SSH no Windows. Em vez de editar o sshd_config principal, crie um arquivo seu:

# /etc/ssh/sshd_config.d/00-hardening.conf PasswordAuthentication no KbdInteractiveAuthentication no PermitRootLogin no AllowUsers deploy MaxAuthTries 3 LoginGraceTime 30

O nome começando com 00 não é enfeite. O sshd_config do Ubuntu inclui os arquivos dessa pasta logo no topo, em ordem alfabética, e para cada opção vale o primeiro valor lido. Imagens de nuvem costumam trazer um 50-cloud-init.conf com PasswordAuthentication yes; um arquivo seu com número maior perderia para ele. Confira o que existe e valide:

grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/ sudo sshd -t sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractive|permitrootlogin|allowusers|maxauthtries' sudo systemctl reload ssh

• sshd -t não imprime nada quando a configuração está certa. sshd -T mostra os valores efetivos, depois de todos os includes, e é a prova de que a senha está mesmo desligada.
• AllowUsers aceita também origem: AllowUsers deploy@203.0.113.10 só deixa o deploy entrar daquele IP.
• MaxAuthTries 3 pode barrar você se o agente SSH oferecer muitas chaves antes da certa. A mensagem é Too many authentication failures; resolva com IdentitiesOnly yes e a chave certa no arquivo de configuração do cliente.

Teste em uma segunda sessão antes de fechar a primeira#

O reload não derruba a sessão em que você está, e é ela que salva o dia se algo der errado. Mantenha essa janela aberta e, em outro terminal, faça os testes:

1. Login normal com a chave: ssh deploy@IP_DA_VPS. Precisa entrar.
2. Login forçando senha: ssh -o PubkeyAuthentication=no deploy@IP_DA_VPS. Precisa ser recusado com Permission denied (publickey), sem nem perguntar a senha.
3. Login como root: ssh root@IP_DA_VPS. Precisa ser recusado.
4. Só com os três resultados certos, feche a primeira sessão.

Fail2Ban, firewall e VPN#

Com o sshd endurecido, as camadas seguintes reduzem ruído e exposição.

Fail2Ban. No Ubuntu 24.04, a jail do SSH já vem ligada ao instalar o pacote e lê o journal. Com senha desligada, ele não impede invasão nenhuma que a chave já não impeça, mas limpa o log, poupa CPU e tira de circulação os IPs mais insistentes. Contra password spraying distribuído, cada IP erra pouco e passa abaixo do limite. A configuração completa, com aumento progressivo e recidive, está em configurar Fail2Ban na VPS. Versões novas do OpenSSH, a partir da 9.8, trazem penalidades nativas por origem, mas o Ubuntu 24.04 usa a 9.6, então o Fail2Ban segue sendo a ferramenta.

Restrição por IP ou VPN. É a camada que mais reduz a superfície:

# SSH só de um IP fixo sudo ufw allow from 203.0.113.10 to any port 22 proto tcp # SSH só pela interface da VPN WireGuard sudo ufw allow in on wg0 to any port 22 proto tcp # depois de testar pelas novas regras, feche a regra aberta sudo ufw status numbered sudo ufw delete NUMERO_DA_REGRA_ABERTA

A sintaxe e os cuidados para não perder o acesso estão no guia de firewall UFW na VPS, e a montagem da VPN em VPN WireGuard na VPS. Com IP residencial dinâmico, prefira a VPN: a lista de IPs quebra na próxima troca de endereço.

Troca de porta. Reduz linhas no log, porque robôs simples só testam a 22, mas varreduras completas acham qualquer porta. No Ubuntu 24.04 o SSH é ativado por socket, e a troca exige recarregar o systemd e reiniciar o ssh.socket, sempre com a porta nova liberada no firewall antes.

• Login só por chave, com PasswordAuthentication e KbdInteractiveAuthentication em no
• PermitRootLogin no; se o root for inevitável, só com chave
• AllowUsers com a lista mínima de contas humanas
• Configuração conferida com sshd -T depois de cada mudança
• Fail2Ban ativo na porta real do SSH
• Firewall com SSH restrito por IP ou VPN sempre que possível

Operação contínua em VPS e dedicado#

Segurança do SSH não é uma tarefa de um dia. Uma rotina curta evita que a configuração se degrade:

1. A cada trimestre, revise o authorized_keys de cada usuário e remova chaves de quem saiu da equipe ou de máquinas aposentadas.
2. Depois de upgrades grandes do sistema, rode o sshd -T de novo e confirme que a senha continua desligada.
3. Configure um alerta para linhas Accepted fora do padrão e para picos de falhas por hora.
4. Uma vez por semestre, teste o login pelo console do painel.
5. Depois de qualquer incidente, troque todas as chaves e revise o histórico de logins aceitos.

O AntiDDoS incluso na rede das VPS da StreetHosting segura ataques volumétricos, mas não brute force, que é pouco tráfego e parece legítimo. Essa camada é sua, e o acesso root e a virtualização KVM deixam você aplicar tudo o que está neste guia, com o console do painel como rede de segurança. As VPS ficam em São Paulo e começam em R$ 26,00 na linha Xeon e R$ 41,00 na Ryzen 9 9950X. Para operações maiores, os servidores dedicados têm hardware exclusivo, 10 Gbps e AntiDDoS, a partir de R$ 1.499,00, com entrega em até 6 dias. Hardware exclusivo não dispensa SSH endurecido.