Como configurar Fail2ban contra ataques SSH

Tempo estimado: 20-30 minutos

Dificuldade: Intermediário

Fail2ban é uma camada prática de defesa para VPS Linux. Ele lê logs de serviços, identifica padrões de falha repetida e cria bloqueios temporários no firewall. Neste guia, você vai proteger o SSH contra tentativas de força bruta sem depender de configurações específicas de provedor. O foco é Ubuntu e Debian, com observações para servidores que usam firewalld.

Antes de mexer em segurança, trabalhe com calma. Mantenha uma sessão SSH aberta enquanto testa outra. Assim, se alguma regra bloquear uma conexão nova por engano, você ainda consegue corrigir a configuração pela sessão ativa.

O que você vai aprender

Ao final do guia, você vai conseguir:

• Instalar o Fail2ban em uma VPS Linux baseada em Ubuntu ou Debian.
• Verificar se os logs do SSH estão disponíveis para análise.
• Criar arquivos locais de configuração sem alterar os arquivos originais do pacote.
• Ativar uma jail para proteger o serviço SSH contra várias tentativas inválidas.
• Integrar o Fail2ban com UFW ou iptables, conforme o firewall em uso.
• Testar bloqueios de forma controlada, sem atacar o próprio servidor.
• Diagnosticar problemas comuns de logs, filtros, permissões e falsos positivos.

Esse tipo de proteção combina bem com outras boas práticas de VPS, como chaves SSH, firewall restritivo e monitoramento básico. Se você ainda está escolhendo infraestrutura, veja também o guia editorial sobre melhor VPS no Brasil, que ajuda a entender critérios de rede, suporte e recursos antes da contratação.

Pré-requisitos

Você precisa de uma VPS Linux com acesso SSH e um usuário com permissão de sudo. Os comandos abaixo foram pensados para Ubuntu 22.04, Ubuntu 24.04, Debian 12 e versões próximas. Em CentOS, AlmaLinux ou Rocky Linux, os conceitos são os mesmos, mas o gerenciador de pacotes e o firewall padrão podem mudar.

Tenha estes itens antes de começar:

• Acesso SSH funcional à VPS.
• Um usuário administrativo, de preferência diferente de root.
• Porta SSH conhecida, normalmente 22, mas pode ser outra.
• Permissão para instalar pacotes.
• Noções básicas de terminal, edição de arquivos e systemd.
• Uma segunda sessão SSH aberta durante os testes.

Primeiro, conecte ao servidor:

ssh [email protected]

A saída esperada depende do seu sistema, mas você deve chegar ao prompt remoto:

admin@vps-segura:~$

Use o IP público real da sua VPS no lugar do endereço mostrado. O endereço 203.0.113.10 pertence a uma faixa reservada para documentação, então não tente se conectar a ele literalmente.

Também recomendo revisar como você avalia riscos de infraestrutura. O texto sobre como avaliamos provedores de VPS explica critérios que influenciam segurança, como estabilidade, suporte e transparência técnica.

Passo 1: Verificar acesso, sistema e logs do SSH

Antes de instalar qualquer ferramenta de bloqueio, confirme qual distribuição está em uso, se o SSH está ativo e onde ficam os logs de autenticação. O Fail2ban depende desses logs para detectar tentativas inválidas. Se o arquivo de log estiver ausente ou o serviço SSH usar um nome diferente, a jail não vai banir ninguém.

Execute:

cat /etc/os-release

Você deve ver algo parecido com:

PRETTY_NAME=Ubuntu 24.04 LTS
NAME=Ubuntu
VERSION_ID=24.04

Agora verifique o serviço SSH. Em Ubuntu e Debian recentes, ele costuma aparecer como ssh. Em algumas distribuições, aparece como sshd.

systemctl status ssh --no-pager

Saída esperada:

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded
     Active: active (running)

Se retornar unit ssh.service could not be found, teste:

systemctl status sshd --no-pager

Em seguida, confira o log de autenticação. No Ubuntu e Debian, o caminho comum é /var/log/auth.log:

sudo tail -n 20 /var/log/auth.log

Uma saída típica contém linhas como:

sshd[1842]: Failed password for invalid user test from 198.51.100.25 port 45812 ssh2
sshd[1842]: Connection closed by invalid user test 198.51.100.25 port 45812

Se o arquivo não existir, use journalctl:

sudo journalctl -u ssh --no-pager -n 20

Não prossiga no escuro. Você precisa saber de onde o Fail2ban vai ler as tentativas de login. Esse pequeno diagnóstico evita uma configuração aparentemente correta, mas incapaz de detectar ataques.

Passo 2: Instalar o Fail2ban e confirmar o serviço

Com o SSH e os logs confirmados, instale o Fail2ban pelo gerenciador de pacotes da distribuição. Em Ubuntu e Debian, use apt. O comando atualiza o índice de pacotes e instala o serviço. Ele não apaga dados, mas altera o sistema ao adicionar um novo daemon, então execute apenas em uma janela administrativa confiável.

sudo apt update
sudo apt install fail2ban -y

Você deve ver uma saída parecida com:

Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  fail2ban
Setting up fail2ban ...
Created symlink /etc/systemd/system/multi-user.target.wants/fail2ban.service

Depois da instalação, habilite o serviço para iniciar junto com o servidor:

sudo systemctl enable --now fail2ban

A saída esperada é curta:

Synchronizing state of fail2ban.service with SysV service script
Executing: /lib/systemd/systemd-sysv-install enable fail2ban

Agora confirme o estado:

sudo systemctl status fail2ban --no-pager

Você deve procurar por Active: active:

● fail2ban.service - Fail2Ban Service
     Loaded: loaded
     Active: active (running)

Também consulte o cliente do Fail2ban:

sudo fail2ban-client status

No início, a lista de jails pode estar vazia ou conter apenas jails padrão desativadas:

Status
|- Number of jail: 0
`- Jail list:

Isso é normal. A instalação colocou o motor em funcionamento, mas você ainda precisa criar a configuração local. Não edite diretamente jail.conf, porque atualizações do pacote podem sobrescrever esse arquivo.

Passo 3: Criar uma configuração local segura

O Fail2ban usa arquivos .conf como base do pacote e arquivos .local para as suas customizações. A prática segura é criar /etc/fail2ban/jail.local ou arquivos dentro de /etc/fail2ban/jail.d/. Neste guia, vamos usar jail.local porque ele fica claro para quem está configurando pela primeira vez.

Antes de criar ou alterar o arquivo, faça backup se ele já existir:

if [ -f /etc/fail2ban/jail.local ]; then sudo cp /etc/fail2ban/jail.local /etc/fail2ban/jail.local.bak; fi

Esse comando não deve exibir nada quando executa com sucesso:

Confirme se o backup existe quando havia arquivo anterior:

sudo ls -l /etc/fail2ban/jail.local*

Saída possível:

-rw-r--r-- 1 root root 842 Jul  6 10:20 /etc/fail2ban/jail.local
-rw-r--r-- 1 root root 842 Jul  6 10:18 /etc/fail2ban/jail.local.bak

Agora crie uma configuração inicial. Ela define backend systemd, tempos padrão e uma lista de IPs ignorados. O endereço 127.0.0.1 protege o loopback. A faixa 10.0.0.0/8 evita bloqueios internos em redes privadas, mas ajuste se sua VPS não usa essa faixa.

sudo tee /etc/fail2ban/jail.local > /dev/null <<'EOF'
[DEFAULT]
backend = systemd
bantime = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1 10.0.0.0/8

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = %(sshd_log)s
maxretry = 5
findtime = 10m
bantime = 1h
EOF

Verifique o conteúdo antes de reiniciar o serviço:

sudo sed -n '1,120p' /etc/fail2ban/jail.local

Você deve ver os blocos DEFAULT e sshd. Se aparecerem caracteres quebrados, linhas duplicadas estranhas ou erro de permissão, corrija antes de continuar.

Passo 4: Configurar a jail do SSH

A jail sshd é o coração desta configuração. Ela combina filtro, log, limite de tentativas e ação de bloqueio. O filtro sshd já vem com o Fail2ban e reconhece mensagens comuns do OpenSSH, como Failed password, Invalid user e authentication failure. Ainda assim, você deve validar se o filtro conversa com os seus logs reais.

Execute um teste do filtro contra o log de autenticação:

sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

Uma saída saudável mostra linhas encontradas:

Running tests
============= 

Use   failregex filter file : sshd, basedir: /etc/fail2ban
Use         log file : /var/log/auth.log

Results
=======

Failregex: 12 total
Ignoreregex: 0 total

Se seu sistema usa apenas journalctl, esse teste com arquivo pode retornar zero. Nesse caso, mantenha backend = systemd e valide depois com fail2ban-client, porque o serviço vai ler o journal diretamente.

Agora reinicie o Fail2ban para carregar a jail. Reiniciar o serviço pode aplicar regras de firewall, então mantenha sua sessão atual aberta.

sudo systemctl restart fail2ban

Confirme que ele voltou sem falhas:

sudo systemctl status fail2ban --no-pager

Saída esperada:

● fail2ban.service - Fail2Ban Service
     Active: active (running)

Veja a lista de jails:

sudo fail2ban-client status

Agora a jail sshd deve aparecer:

Status
|- Number of jail: 1
`- Jail list: sshd

Consulte os detalhes dela:

sudo fail2ban-client status sshd

Você deve ver algo assim:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  `- Total failed: 0
`- Actions
   |- Currently banned: 0
   `- Banned IP list:

Neste ponto, a proteção básica do SSH já está ativa.

Passo 5: Integrar o Fail2ban ao firewall

O Fail2ban precisa de uma ação para bloquear IPs. Em muitas instalações atuais, ele usa iptables ou nftables por baixo. Se você usa UFW, pode configurar o Fail2ban para criar bloqueios compatíveis com ele. Isso deixa as regras mais fáceis de auditar, especialmente em VPS de produção.

Primeiro, veja se o UFW está instalado e ativo:

sudo ufw status verbose

Saída possível:

Status: active
Logging: on
Default: deny (incoming), allow (outgoing), disabled (routed)

Se o comando retornar command not found, você pode continuar com a ação padrão do Fail2ban, sem instalar UFW agora. Se o UFW estiver ativo, ajuste a ação padrão para ufw. Faça backup antes:

sudo cp /etc/fail2ban/jail.local /etc/fail2ban/jail.local.firewall.bak

Confirme:

sudo ls -l /etc/fail2ban/jail.local.firewall.bak

Saída esperada:

-rw-r--r-- 1 root root 238 Jul  6 10:35 /etc/fail2ban/jail.local.firewall.bak

Agora insira banaction = ufw no bloco DEFAULT. Se a linha já existir, edite manualmente com nano.

sudo nano /etc/fail2ban/jail.local

Deixe o início parecido com isto:

[DEFAULT]
backend = systemd
banaction = ufw
bantime = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1 10.0.0.0/8

Salve, saia e teste a configuração:

sudo fail2ban-client -t

Saída esperada:

OK: configuration test is successful

Recarregue o serviço:

sudo systemctl reload fail2ban

Se você administra uma aplicação crítica, como ecommerce, essa etapa ajuda a reduzir ruído de ataques automatizados sem derrubar tráfego legítimo. Para cenários com loja online, combine esta proteção com práticas descritas em VPS para loja virtual, principalmente backup, SSL e monitoramento.

Passo 6: Testar bloqueios e ajustar a operação

Não faça várias tentativas erradas de SSH a partir do seu próprio IP sem planejamento. Você pode se bloquear e perder acesso. O teste mais seguro é banir temporariamente um IP reservado para documentação e depois removê-lo. Isso valida a ação de firewall sem afetar usuários reais.

Adicione um banimento manual na jail sshd:

sudo fail2ban-client set sshd banip 198.51.100.25

A saída esperada é:

1

Agora consulte a jail:

sudo fail2ban-client status sshd

Você deve ver o IP na lista:

Status for the jail: sshd
`- Actions
   |- Currently banned: 1
   `- Banned IP list: 198.51.100.25

Se usa UFW, confira as regras:

sudo ufw status numbered

Saída típica:

Status: active

[ 1] Anywhere                   DENY IN     198.51.100.25
[ 2] 22/tcp                     ALLOW IN    Anywhere

Remova o banimento manual:

sudo fail2ban-client set sshd unbanip 198.51.100.25

Saída esperada:

1

Verifique novamente:

sudo fail2ban-client status sshd

O contador deve voltar para zero:

Currently banned: 0
Banned IP list:

Ajuste os tempos conforme o risco. Para uma VPS pessoal, bantime = 1h e maxretry = 5 costumam ser razoáveis. Para servidor exposto com muito ataque automatizado, você pode usar bantime = 12h. Evite maxretry = 1 em ambientes com usuários reais, porque erros de senha acontecem.

Verificação e testes

Faça uma verificação completa antes de considerar a configuração pronta. Comece pelo teste sintático do Fail2ban:

sudo fail2ban-client -t

Resultado esperado:

OK: configuration test is successful

Confira se o serviço está ativo:

sudo systemctl is-active fail2ban

Saída esperada:

active

Veja se a jail sshd está carregada:

sudo fail2ban-client status

Resultado esperado:

Status
|- Number of jail: 1
`- Jail list: sshd

Agora consulte logs recentes do Fail2ban:

sudo journalctl -u fail2ban --no-pager -n 30

Você deve encontrar linhas de início sem erros:

fail2ban.server         [1234]: INFO    Starting Fail2ban v1.0.2
fail2ban.jail           [1234]: INFO    Jail 'sshd' started

Se quiser acompanhar em tempo real durante alguns minutos, use:

sudo tail -f /var/log/fail2ban.log

Saída possível quando um IP é bloqueado:

NOTICE  [sshd] Ban 203.0.113.55
NOTICE  [sshd] Unban 203.0.113.55

Pressione Ctrl+C para sair do acompanhamento. Depois, abra uma nova sessão SSH normal e confirme que seu acesso legítimo continua funcionando. Mantenha a sessão antiga aberta até terminar essa validação. Se a nova sessão entrar sem erro, a configuração está protegendo sem bloquear você.

Troubleshooting

Problema 1: a jail sshd não aparece no status. Rode o teste de configuração:

sudo fail2ban-client -t

Se aparecer erro de sintaxe, abra /etc/fail2ban/jail.local e procure linhas fora de seção, espaços estranhos ou chaves duplicadas. Depois reinicie:

sudo systemctl restart fail2ban
sudo fail2ban-client status

Problema 2: o Fail2ban está ativo, mas não detecta falhas. Verifique se existem logs de autenticação:

sudo tail -n 50 /var/log/auth.log

Se o arquivo não existir, use backend = systemd e consulte o journal:

sudo journalctl -u ssh --no-pager -n 50

Em algumas imagens mínimas, o rsyslog não vem instalado. Nesse caso, instale e habilite:

sudo apt install rsyslog -y
sudo systemctl enable --now rsyslog

Problema 3: você baniu seu próprio IP. Use uma sessão SSH que ainda esteja aberta e remova o banimento. Primeiro descubra os IPs banidos:

sudo fail2ban-client status sshd

Depois remova o IP correto:

sudo fail2ban-client set sshd unbanip 203.0.113.55

Problema 4: o serviço falha ao iniciar após mudar a ação para UFW. Teste se o UFW existe:

command -v ufw

Se não houver saída, remova banaction = ufw ou instale e configure o UFW antes. Não ative um firewall novo sem permitir a porta SSH primeiro.

Problema 5: há muitos falsos positivos. Aumente maxretry para 8 ou reduza findtime para 5m. Faça backup antes de editar, valide com fail2ban-client -t e recarregue com systemctl reload fail2ban.

Próximos passos

Depois que o Fail2ban estiver estável, fortaleça o SSH. Configure autenticação por chave pública, desative login direto como root e mantenha uma porta SSH documentada para sua equipe. Também revise o firewall para permitir somente portas necessárias, como 22, 80 e 443 quando houver site público.

Monitore os logs por alguns dias:

sudo grep 'Ban' /var/log/fail2ban.log | tail -n 20

Saída possível:

NOTICE  [sshd] Ban 198.51.100.88
NOTICE  [sshd] Ban 203.0.113.77

Se os bloqueios forem frequentes, considere alertas por email, métricas com Prometheus ou um painel simples de logs. Para servidores com tráfego comercial, combine Fail2ban com backup automático, atualizações de segurança e monitoramento de disponibilidade. Segurança em VPS funciona melhor em camadas. O Fail2ban reduz ataques repetitivos, mas não substitui senha forte, chave SSH, atualização do sistema e boas permissões de aplicação.