Passo a passo para blindar o SSH contra ataques de força bruta

12 min de leitura  ·  Guia técnico

Blindar o SSH contra ataques de força bruta é essencial para proteger servidores Linux contra invasões automatizadas que testam milhares de combinações de credenciais. Para implementar uma proteção eficaz, siga estes passos:

1. Alterar a porta padrão do SSH da 22 para uma personalizada
2. Instalar e configurar o Fail2Ban para bloqueio automático de IPs suspeitos
3. Desabilitar autenticação por senha e usar apenas chaves SSH
4. Configurar autenticação de dois fatores (2FA) com Google Authenticator
5. Implementar whitelist de IPs autorizados no firewall UFW
6. Monitorar logs de acesso e configurar alertas automáticos

Pré-requisitos

• Acesso root ou sudo ao servidor Linux (Ubuntu 22.04 LTS ou superior)
• Conexão SSH ativa e estável para configuração inicial
• Conhecimento básico de comandos Linux e edição de arquivos
• Smartphone com aplicativo Google Authenticator instalado
• Backup das chaves SSH em local seguro antes das alterações

Alterando a porta SSH padrão

A primeira linha de defesa contra ataques automatizados é alterar a porta SSH da padrão 22 para uma personalizada. Esta medida simples elimina 90% dos ataques de bots que varrem apenas a porta padrão.

Edite o arquivo de configuração do SSH:

sudo nano /etc/ssh/sshd_config

Localize a linha #Port 22 e substitua por uma porta personalizada:

Port 2200

Verifique se a porta escolhida não está em uso:

netstat -tuln | grep :2200

Se não houver retorno, a porta está livre. Reinicie o serviço SSH:

sudo systemctl restart ssh

Atenção: Mantenha a sessão SSH atual aberta e teste a nova porta em outra janela antes de fechar a conexão original.

Teste a conexão na nova porta:

ssh -p 2200 [email protected]

Instalando e configurando Fail2Ban

O Fail2Ban monitora logs de autenticação em tempo real e bloqueia automaticamente IPs que apresentam comportamento suspeito. Esta ferramenta é fundamental para proteger SSH contra tentativas de força bruta.

Instale o Fail2Ban no Ubuntu:

sudo apt update
sudo apt install fail2ban -y

Crie um arquivo de configuração personalizado:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Edite a configuração para SSH:

sudo nano /etc/fail2ban/jail.local

Configure a seção SSH com parâmetros mais restritivos:

[sshd]
enabled = true
port = 2200
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600

Inicie e habilite o Fail2Ban:

sudo systemctl start fail2ban
sudo systemctl enable fail2ban

Verifique o status da proteção SSH:

sudo fail2ban-client status sshd

Output esperado:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed: 0
|  `- File list: /var/log/auth.log
`- Actions
   |- Currently banned: 0
   |- Total banned: 0
   `- Banned IP list:

Configurando autenticação por chaves SSH

Substituir senhas por chaves SSH elimina completamente a possibilidade de ataques de força bruta, já que as chaves criptográficas são computacionalmente impossíveis de quebrar por tentativa e erro.

Gere um par de chaves SSH no cliente (sua máquina local):

ssh-keygen -t rsa -b 4096 -C "[email protected]"

Copie a chave pública para o servidor:

ssh-copy-id -p 2200 [email protected]

Teste a autenticação por chave:

ssh -p 2200 [email protected]

Se a conexão funcionar sem solicitar senha, desabilite a autenticação por senha no servidor:

sudo nano /etc/ssh/sshd_config

Configure as seguintes opções:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PermitRootLogin no

Reinicie o SSH para aplicar as alterações:

sudo systemctl restart ssh

Atenção: Certifique-se de que a autenticação por chave funciona antes de desabilitar senhas, ou você pode perder o acesso ao servidor.

Implementando autenticação de dois fatores

A autenticação de dois fatores adiciona uma camada extra de segurança, exigindo um código temporário do smartphone além da chave SSH para acessar o servidor.

Instale o módulo PAM do Google Authenticator:

sudo apt install libpam-google-authenticator -y

Configure o 2FA para seu usuário:

google-authenticator

Responda às perguntas da configuração:

Do you want authentication tokens to be time-based? (y/n) y
Do you want me to update your "/home/usuario/.google_authenticator" file? (y/n) y
Do you want to disallow multiple uses of the same authentication token? (y/n) y
Do you want to do so? (y/n) n
Do you want to enable rate-limiting? (y/n) y

Escaneie o QR code exibido com o Google Authenticator no smartphone e anote os códigos de emergência.

Configure o PAM para SSH:

sudo nano /etc/pam.d/sshd

Adicione no final do arquivo:

auth required pam_google_authenticator.so

Edite a configuração SSH:

sudo nano /etc/ssh/sshd_config

Configure a autenticação combinada:

ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

Reinicie o SSH:

sudo systemctl restart ssh

Configurando firewall UFW com whitelist

O firewall UFW permite criar uma whitelist de IPs autorizados, bloqueando todas as outras tentativas de conexão SSH. Esta abordagem é ideal para servidores acessados apenas de locais específicos.

Instale e configure o UFW:

sudo ufw --force reset
sudo ufw default deny incoming
sudo ufw default allow outgoing

Adicione seu IP atual à whitelist SSH:

sudo ufw allow from SEU_IP to any port 2200

Para descobrir seu IP público:

curl ifconfig.me

Adicione outros IPs autorizados conforme necessário:

sudo ufw allow from 203.0.113.10 to any port 2200
sudo ufw allow from 198.51.100.0/24 to any port 2200

Permita serviços essenciais:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Ative o firewall:

sudo ufw enable

Verifique as regras ativas:

sudo ufw status numbered

Para mais informações sobre configuração de servidores Linux, consulte nosso guia sobre Dicas de Otimização de Servidores Linux.

Monitoramento e alertas automáticos

Implementar monitoramento contínuo permite detectar tentativas de invasão em tempo real e responder rapidamente a ameaças emergentes.

Crie um script de monitoramento:

sudo nano /usr/local/bin/ssh-monitor.sh

Adicione o conteúdo do script:

#!/bin/bash
LOGFILE="/var/log/auth.log"
ALERT_EMAIL="[email protected]"
THRESHOLD=10

FAILED_ATTEMPTS=$(grep "Failed password" $LOGFILE | grep "$(date '+%b %d')" | wc -l)

if [ $FAILED_ATTEMPTS -gt $THRESHOLD ]; then
    echo "ALERTA: $FAILED_ATTEMPTS tentativas de login SSH falhadas hoje" | mail -s "Alerta SSH - $(hostname)" $ALERT_EMAIL
fi

Torne o script executável:

sudo chmod +x /usr/local/bin/ssh-monitor.sh

Configure execução automática via cron:

sudo crontab -e

Adicione a linha para execução a cada hora:

0 * * * * /usr/local/bin/ssh-monitor.sh

Configure logrotate para gerenciar logs antigos:

sudo nano /etc/logrotate.d/ssh-security

Adicione a configuração:

/var/log/auth.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    postrotate
        /bin/kill -HUP $(cat /var/run/rsyslogd.pid 2> /dev/null) 2> /dev/null || true
    endscript
}

Problemas comuns e como resolver

Erro: "Permission denied (publickey)" após configurar chaves SSH

Causa: Permissões incorretas nos arquivos de chave ou diretório .ssh mal configurado.
Solução: Verifique as permissões com ls -la ~/.ssh/. O diretório .ssh deve ter permissão 700, authorized_keys deve ter 600. Corrija com chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys.

Fail2Ban não está bloqueando IPs atacantes

Causa: Configuração incorreta do arquivo de log ou filtro inadequado para a versão do SSH.
Solução: Verifique se o caminho do log está correto em /etc/fail2ban/jail.local. Teste o filtro com sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf para verificar se está capturando tentativas falhadas.

Conexão SSH lenta após implementar 2FA

Causa: Problemas de sincronização de tempo entre servidor e smartphone ou configuração DNS reversa lenta.
Solução: Sincronize o horário do servidor com sudo ntpdate -s time.nist.gov e adicione UseDNS no no arquivo /etc/ssh/sshd_config para desabilitar lookup DNS reverso.

Perguntas frequentes sobre blindagem SSH

O que é um ataque de força bruta no SSH?

Um ataque de força bruta no SSH é uma tentativa automatizada de descobrir credenciais válidas testando milhares de combinações de usuário e senha. Estes ataques são executados por bots que varrem a internet procurando servidores com SSH exposto na porta 22. Podem comprometer servidores com senhas fracas em questão de minutos.

Como saber se meu servidor está sendo atacado via SSH?

Verifique o arquivo /var/log/auth.log em busca de múltiplas tentativas de login falhadas do mesmo IP. Comandos como 'grep "Failed password" /var/log/auth.log | tail -20' mostram tentativas recentes. Também observe conexões simultâneas suspeitas com 'who' e monitore o uso de CPU anormalmente alto.

Fail2Ban funciona em tempo real ou tem delay?

O Fail2Ban monitora logs em tempo real usando inotify, detectando tentativas de invasão quase instantaneamente. Por padrão, ele bloqueia IPs após 5 tentativas falhadas em 10 minutos, mantendo o bloqueio por 10 minutos. Estes valores são configuráveis e podem ser ajustados conforme a necessidade de segurança.

É seguro desabilitar login por senha no SSH?

Sim, desabilitar autenticação por senha e usar apenas chaves SSH é considerado uma das melhores práticas de segurança. As chaves SSH são criptograficamente muito mais seguras que senhas e eliminam completamente a possibilidade de ataques de força bruta. Certifique-se apenas de ter backup das chaves privadas.

Qual porta SSH devo usar em vez da 22?

Qualquer porta acima de 1024 e abaixo de 65535 que não esteja em uso por outros serviços. Portas comuns incluem 2222, 2200, ou 22000. Evite portas conhecidas como 80, 443, 21, 25. Verifique se a porta está livre com 'netstat -tuln | grep :PORTA' antes de configurar.

Conclusão

Implementar essas medidas de segurança transforma seu servidor em um alvo muito menos atrativo para atacantes automatizados. A combinação de porta personalizada, Fail2Ban, autenticação por chaves e monitoramento ativo cria múltiplas camadas de proteção.

• Monitore regularmente os logs de segurança e ajuste as configurações conforme necessário
• Mantenha backups seguros das chaves SSH e códigos de emergência do 2FA
• Atualize periodicamente o sistema operacional e ferramentas de segurança para corrigir vulnerabilidades

Leia também

• Checklist Completo para Configurar e Testar o Firewall UFW em VPS Linux e Servidores Dedicados
• Lista Prática: 5 Vantagens de ter SSL gratuito no seu site
• Como Instalar e Configurar o Certbot para SSL Gratuito no Ubuntu

Precisa de ajuda com segurança do servidor?

Nossa equipe especializada pode implementar todas essas medidas de segurança no seu VPS, garantindo proteção máxima contra ataques de força bruta e outras ameaças. Oferecemos configuração completa e monitoramento 24/7.

Conheça nossos planos de VPS com segurança avançada