Facilite sua vida de administrador, dificultando para os invasores.
Introdução
Já sabemos como utilizar o gerador de chaves do SSH, criar pares de chaves e publicá-las corretamente. Esse é um passo fundamental.
Mas a pergunta que naturalmente surge é: o que mais posso fazer para tornar meu servidor realmente seguro?
Vamos usar uma metáfora simples.
Imagine que seu servidor é uma casa. Como toda casa, ele possui portas e janelas. Algumas dessas janelas dão acesso apenas a áreas específicas: um serviço WEB, um serviço FTP, uma API, um banco de dados acessado localmente. São janelas porque permitem ver ou acessar apenas o que foi projetado para aquele fim. Ainda assim, janelas bem feitas possuem grades, trincos e fechaduras, pois mesmo acessos limitados precisam de proteção contra abusos.
Agora pense no SSH como a porta principal da casa. Quem entra por essa porta não apenas vê o interior, mas pode circular livremente, abrir janelas, mexer nos móveis ou, se tiver privilégios suficientes, causar danos graves ou totais. Por isso, o acesso SSH exige um nível de rigor muito maior. Controlar quem entra por essa porta é uma das responsabilidades mais críticas de um administrador de sistemas.
O cenário padrão (e por que ele é perigoso)
Na maioria das instalações padrão:
- O servidor possui vários usuários locais.
- O SSH permite autenticação por usuário e senha.
- Todos os usuários válidos do sistema podem, em princípio, tentar se conectar via SSH.
- O usuário
root, por padrão, não tem login SSH direto (o que é positivo).
Em ambientes Debian, por exemplo, usuários comuns normalmente não possuem acesso ao sudo, ou o pacote sequer vem instalado. Isso limita os danos que um invasor pode causar caso comprometa um usuário comum.
Mas atenção:
o problema já aconteceu no momento em que alguém não autorizado entrou na casa.
Mesmo sem privilégios administrativos, um invasor pode:
- Explorar falhas locais
- Instalar backdoors no diretório do usuário
- Criar túneis reversos
- Utilizar o servidor como ponto de ataque para outros sistemas
Portanto, conter privilégios não é suficiente. É preciso impedir o acesso indevido desde o início.
O que fazer, então?
Tenha regras rígidas de senha (enquanto senhas existirem)
Se, por qualquer motivo, sua infraestrutura ainda utiliza autenticação por senha, ela precisa ser forte de verdade, não apenas “razoável”.
Recomendações mínimas:
- 12 caracteres ou mais
- Letras maiúsculas e minúsculas
- Números
- Caracteres especiais
- Proibição de senhas reutilizadas ou previsíveis
Senhas fracas são o combustível preferido de ataques de força bruta e dicionário, especialmente em serviços expostos à internet.
Regra prática: senha fraca não é “se” vai ser quebrada, é “quando”.
Defina explicitamente quem pode se conectar via SSH
Nem todo usuário precisa — ou deveria — ter acesso SSH.
Exemplo prático:
- Um desenvolvedor web pode publicar conteúdo via FTP, SFTP ou pipeline de CI/CD.
- Um usuário de aplicação pode existir apenas para executar serviços.
- Um usuário de monitoramento não precisa de shell interativo.
Então a pergunta correta é:
Por que conceder acesso SSH a quem não precisa dele?
Quanto menos usuários autorizados:
- Menor a superfície de ataque
- Menor o risco operacional
- Mais fácil auditar acessos
No SSH, menos é mais.
Elimine o acesso por usuário e senha — use apenas chaves SSH
Aqui está um dos pontos mais importantes.
Autenticação por chave:
- Não é suscetível a ataques de força bruta
- Pode ser protegida por passphrase
- Permite revogação rápida e controlada
- É facilmente auditável
Ao desabilitar completamente o login por senha:
- Bots automatizados deixam de ser um problema real
- Ataques de dicionário se tornam inúteis
- Você reduz drasticamente o ruído de segurança no servidor
SSH por senha é conveniência.
SSH por chave é controle.
Instale e configure o Fail2Ban
Mesmo com boas práticas, seu servidor será escaneado. Isso é inevitável.
O Fail2Ban atua como um porteiro vigilante:
- Analisa logs de serviços (SSH, Apache, Nginx, etc.)
- Identifica tentativas suspeitas ou repetidas
- Bloqueia automaticamente o IP de origem
- Pode aplicar banimentos temporários ou permanentes
Para bots e scanners automatizados, o resultado é simples:
Seu servidor vira um alvo caro e improdutivo.
E invasores geralmente preferem o caminho mais fácil.
Conclusão
Segurança não é um único recurso, é um conjunto de decisões conscientes.
Ao:
- Restringir quem pode entrar
- Fortalecer ou eliminar senhas
- Usar autenticação por chaves
- Automatizar bloqueios contra abuso
Você não apenas dificulta a vida dos invasores, mas também:
- Facilita auditorias
- Reduz incidentes
- Ganha previsibilidade operacional
- Dorme melhor sabendo que a porta da sua casa está bem trancada
Um bom administrador não confia na sorte.
Ele confia em controles bem definidos.
