Proteja o seu Servidor Linux contra Ataques Brute Force no SSH

Se já configuraste um servidor Linux na nuvem, sabe que o OpenSSH é praticamente a primeira coisa que instalamos. Ele é o canivete suíço do acesso remoto. Mas, justamente por ser tão comum, muita gente o trata como um utilitário "plug and play" e ignora configurações básicas que se tornam um prato cheio para atacantes.

A verdade é que as distribuições Linux modernas (como Ubuntu, Debian e a família RHEL) já tentam nos proteger de nós mesmos logo no primeiro dia. Quando você instala o pacote do OpenSSH, o comportamento padrão do sistema segue duas regras muito claras:

A famosa Porta 22 fica escancarada. Por ser o padrão oficial do protocolo, ela já vem habilitada e pronta para receber conexões. O problema? Todo robô malicioso na internet sabe disso e passa 24 horas por dia escaneando essa porta atrás de brechas.

O acesso direto ao usuário root vem trancado. Felizmente, hoje em dia a maioria das distros bloqueia o login direto do superusuário. No arquivo de configuração (sshd_config), você costuma encontrar diretivas como PermitRootLogin prohibit-password ou no. Isso serve para impedir que ataques de força bruta adivinhem a senha do administrador, já que o root é o alvo número um de qualquer script automatizado.

O grande perigo mora quando o desenvolvedor ou o administrador de sistemas precisa de um acesso rápido, resolve "facilitar a vida" e reativa o login do root com senha, ou simplesmente esquece o SSH exposto na porta padrão sem nenhuma camada extra de proteção. É aí que o que era para ser uma ferramenta segura vira a maior vulnerabilidade da sua infraestrutura.

Como conferir ou alterar essas configurações?#

Abra o arquivo de configuração com privilégios de administrador:

sudo nano /etc/ssh/sshd_config

Para alterar a porta: Procure pela linha #Port 22. Remova o símbolo # (comentário) e mude o número para a porta que desejar (ex: Port 2222).

Para liberar o acesso root: Procure pela linha PermitRootLogin. Para permitir o acesso completo usando a senha do root, mude o valor para yes (não recomendado por questões de segurança).

Para reiniciar o serviço:

sudo systemctl restart sshd

Deixar o root desabilitado serve para impedir que ataques de força bruta adivinhem a senha do administrador, já que o root é o alvo número um de qualquer script automatizado.

Como Configurar Autenticação SSH por Chaves #

Uma das melhores práticas de segurança para proteger o teu servidor Linux é desativar a autenticação por senha tradicional e permitir apenas conexões baseadas em chaves públicas e privadas. Neste artigo, vamos aprender como gerar essas chaves no cliente e registá-las no servidor.

1. Onde ficam guardadas as chaves no Servidor?#

Por padrão, as chaves de autorização ficam armazenadas numa pasta oculta dentro do diretório do utilizador. Se estiveres a configurar o acesso para o utilizador administrador (root), o caminho será:

bash

cd /root/.ssh

Nota: É exatamente dentro deste diretório no servidor que as chaves públicas autorizadas ficarão guardadas.

2. Configuração no Cliente (A tua máquina local)#

Para começar, acedemos ao terminal do cliente (a máquina a partir da qual pretendes ligar-te ao servidor) para gerar o par de chaves. Utilizaremos o comando ssh-keygen com o algoritmo moderno ED25519 (mais seguro e rápido que o antigo RSA).

Se estiveres a rodar o terminal como root (como no Debian), o par de chaves será gerado por padrão no diretório /root/.ssh:

bash

ssh-keygen -t ed25519

O que aconteceu durante a execução?

Ao finalizar o processo, foram gerados dois ficheiros cruciais:

id_ed25519: A tua chave privada (funciona como o teu segredo/senha digital. Nunca a partilhes com ninguém).

id_ed25519.pub: A tua chave pública (esta é a que será enviada e registada no servidor).

Configuração no Servidor: Registar a Chave Pública#

Agora que as chaves foram criadas na máquina cliente, precisamos de levar a chave pública (id_ed25519.pub) até ao servidor para que ele nos reconheça.

O objetivo é adicionar o conteúdo da nossa chave pública dentro de um ficheiro chamado authorized_keys no diretório /root/.ssh do servidor.

O método mais fácil e automático (Recomendado)#

Ainda no terminal da tua máquina cliente, executa o comando abaixo para transferir automaticamente a chave:

ssh-copy-id -i /root/.ssh/id_ed25519.pub root@IP_DO_SERVIDOR

O método manual#

Caso o comando acima não esteja disponível, podes copiar manualmente o conteúdo do ficheiro .pub do cliente e colá-lo no servidor:

No cliente, visualiza e copia o conteúdo da chave:

cat /root/.ssh/id_ed25519.pub

No servidor, acede à pasta do root, cria/abre o ficheiro de chaves autorizadas e cola o conteúdo lá dentro:

mkdir -p /root/.ssh && chmod 700 /root/.ssh
nano /root/.ssh/authorized_keys

Guarda o ficheiro e ajusta as permissões de segurança (obrigatório para o SSH funcionar):

chmod 600 /root/.ssh/authorized_keys

Otimização no Cliente: Utilizar o SSH Agent (ssh-add)#

Adiciona a tua chave privada ao agente:

ssh-add /root/.ssh/id_ed25519

A partir deste momento, a tua chave privada está carregada na memória da sessão do cliente, permitindo conexões automáticas e seguras ao servidor sem interrupções!

Bloquear o acesso por senha tradicional#

No servidor, edita o ficheiro de configuração do SSH:

nano /etc/ssh/sshd_config

Altera a seguinte linha para no

PasswordAuthentication no

Reinicia o serviço SSH para aplicar:

systemctl restart ssh   # Debian/Ubuntu

systemctl restart sshd  # RHEL/CentOS/Fedora

Pronto! O teu servidor está agora blindado contra ataques de força bruta, aceitando apenas ligações de clientes que possuam as chaves devidamente registadas.

"O SSH é implacável: sem chave e sem password, estás trancado. Por isso, a regra de ouro dos SysAdmins é nunca fechar a sessão atual do terminal antes de testar a nova ligação numa janela separada. Se o pior acontecer, a tua salvação será o painel da tua Cloud ou o modo de recuperação (GRUB) da máquina física."