Proteger o SSH: Chaves e Boas Práticas Contra Ataques

O SSH é a porta de entrada para o controlo total de um servidor — e, por isso mesmo, o alvo preferido dos atacantes. Qualquer servidor exposto à Internet recebe, todos os dias, milhares de tentativas automáticas de adivinhar credenciais por SSH. Protegê-lo bem não é opcional: é o que separa um servidor seguro de um que mais cedo ou mais tarde é comprometido. Aqui estão as medidas que fazem mesmo a diferença.

1. Autenticação por chave em vez de password

Esta é a medida mais importante de todas. Em vez de proteger o acesso com uma password — que pode ser adivinhada por tentativa e erro — usa-se um par de chaves criptográficas. A chave privada fica no seu computador e nunca sai dele; a pública fica no servidor. Sem a chave privada, ninguém entra, independentemente de quantas tentativas faça. Os ataques de força bruta, que tentam milhões de passwords, tornam-se inúteis.

2. Desativar a autenticação por password

Ter chaves não chega se a entrada por password continuar permitida — os atacantes continuarão a tentá-la. O passo decisivo é desativar completamente a autenticação por password, deixando apenas as chaves. A partir desse momento, as incessantes tentativas de adivinhação deixam simplesmente de ter por onde passar.

3. Desativar o login direto como root

A conta root tem poder absoluto sobre o servidor e é o primeiro alvo de qualquer ataque, porque o seu nome é conhecido. A boa prática é impedir o login direto como root e usar contas individuais que elevam privilégios apenas quando necessário. Assim, mesmo que alguém tente atacar, não tem sequer a conta mais valiosa como porta direta.

4. Mudar a porta padrão (defesa por discrição)

O SSH usa por defeito a porta 22, que todos os scanners automáticos conhecem e atacam primeiro. Mudar para uma porta diferente não torna o servidor invulnerável, mas reduz drasticamente o ruído dos ataques automáticos — a maioria nem se dá ao trabalho de procurar noutras portas. É uma camada simples que filtra grande parte do tráfego hostil de baixo nível.

5. Restringir o acesso a IPs de confiança

Se o servidor só precisa de ser acedido a partir de locais conhecidos (o escritório, a casa do administrador, um parceiro de IT), pode-se limitar o SSH a esses endereços. Tudo o resto é simplesmente recusado. Quando aplicável, esta é uma das medidas mais eficazes — reduz a superfície de ataque a praticamente zero.

6. Proteção automática contra força bruta

Ferramentas como o Fail2ban monitorizam as tentativas de login e bloqueiam automaticamente os endereços que falham repetidamente. Um atacante que tente adivinhar credenciais é cortado ao fim de poucas tentativas, durante um período definido. É uma defesa dinâmica que trava os ataques sem qualquer intervenção manual.

7. Proteger a chave privada

Toda a segurança das chaves assenta em manter a chave privada segura. Se ela for roubada do seu computador, o atacante ganha acesso. Por isso, a chave privada deve estar protegida por uma frase-passe, guardada apenas em dispositivos de confiança e nunca partilhada. Proteger a chave é proteger o servidor.

8. Manter o registo e a vigilância

Registar os acessos SSH — quem entrou, quando, de onde — permite detetar atividade suspeita e auditar em caso de incidente. A vigilância dos registos é parte de uma boa postura de segurança: muitas intrusões são detetadas precisamente por padrões estranhos nos acessos.

Camadas que se reforçam

Repare que estas medidas não são alternativas — combinam-se. Chaves e sem password e sem root direto e com bloqueio automático e com acesso restrito. Cada camada apanha o que a anterior deixou passar. É esta defesa em profundidade que torna um servidor verdadeiramente resistente. Configurar tudo isto corretamente, sem se trancar a si próprio no processo, é uma tarefa que compensa entregar a quem a faz com método — porque um erro no acesso pode deixar o servidor inacessível ou exposto.