Fail2ban: configurar a proteção do SSH contra tentativas de força bruta

O fail2ban é um daemon que acompanha os logs dos serviços, percebe tentativas de login malsucedidas repetidas e bloqueia por um tempo o endereço IP de onde elas partem. Para o SSH, é a proteção mais simples contra força bruta de senhas: os robôs param de insistir depois de alguns erros. A seguir está a configuração do fail2ban, da instalação até a conferência dos bloqueios e os erros mais comuns.

Para que serve o fail2ban se já existem chaves SSH

Qualquer servidor com a porta 22 aberta começa a receber tentativas de login de robôs poucos minutos depois de ligado. Veja você mesmo:

$ sudo journalctl -u ssh --since "1 hour ago" | grep -c "Failed password"
412

Se o login por senha estiver desativado e só houver chaves, invadir o acesso é praticamente impossível. Mesmo assim, o fail2ban continua útil: ele reduz o ruído nos logs, diminui a carga causada por milhares de conexões e protege contra erros de configuração, como quando o login por senha volta a ficar ativo sem querer. É uma segunda camada de defesa, e não substitui as chaves.

Como o fail2ban funciona

A lógica tem três partes:

• Filtro (filter) — conjunto de expressões regulares que encontram, no log, as linhas de tentativa malsucedida e extraem o IP delas. Os filtros ficam em /etc/fail2ban/filter.d/.
• Ação (action) — o que fazer com o infrator: incluir uma regra no iptables, no nftables, no ufw ou no firewalld. As ações ficam em /etc/fail2ban/action.d/.
• Jail (cadeia de proteção) — a combinação de filtro, ação, fonte dos logs e limites. Por exemplo, o jail sshd acompanha o log do SSH.

Se, dentro do intervalo findtime, um mesmo IP acumula maxretry ocorrências, o endereço fica bloqueado por bantime. Ao fim desse prazo, o bloqueio é removido automaticamente.

Instalação do fail2ban

No Debian e no Ubuntu:

sudo apt update
sudo apt install fail2ban

No RHEL, Rocky e AlmaLinux, o pacote está no repositório EPEL:

sudo dnf install epel-release
sudo dnf install fail2ban

Ative a inicialização automática e confira o estado do serviço:

sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban

No Debian e no Ubuntu, o jail do SSH já vem ativado por padrão, por meio do arquivo /etc/fail2ban/jail.d/defaults-debian.conf. Na família RHEL, depois da instalação nada está ativado: os jails precisam ser habilitados manualmente.

Onde ficam as configurações: jail.conf e jail.local

O arquivo principal é /etc/fail2ban/jail.conf, mas não se deve editá-lo: ao atualizar o pacote, ele é sobrescrito. As configurações próprias vão para /etc/fail2ban/jail.local ou para arquivos separados em /etc/fail2ban/jail.d/*.local. O fail2ban lê os arquivos nesta ordem, e cada um seguinte sobrescreve o anterior:

1. jail.conf
2. jail.d/*.conf
3. jail.local
4. jail.d/*.local

Não copie o jail.conf inteiro para o jail.local, porque assim você congela os valores padrão antigos. No jail.local escreva apenas o que está alterando.

Configuração do fail2ban para o SSH: jail.local mínimo

Crie o arquivo:

sudo nano /etc/fail2ban/jail.local

E acrescente:

[DEFAULT]
# Endereços próprios, que nunca devem ser bloqueados
ignoreip = 127.0.0.1/8 ::1 203.0.113.10
bantime  = 1h
findtime = 10m
maxretry = 5
# De onde ler os logs: journal do systemd ou arquivos
backend  = systemd

[sshd]
enabled  = true
port     = ssh
maxretry = 3

Reinicie o serviço e confirme que o jail foi carregado:

$ sudo systemctl restart fail2ban
$ sudo fail2ban-client status
Status
|- Number of jail:      1
`- Jail list:   sshd

O que significam os parâmetros

Os tempos podem ser escritos com sufixos: s, m, h, d, w. Números sem sufixo são segundos.

backend: systemd ou arquivo

No Debian 12 e no Ubuntu 24.04 mais recentes, o arquivo /var/log/auth.log pode não existir se o rsyslog não estiver instalado: os logs do SSH ficam somente no journal do systemd. Nesse caso é preciso backend = systemd; caso contrário, o fail2ban não inicia e informa que não encontrou o arquivo de log. Se o rsyslog estiver presente, pode-se manter a versão com arquivo:

[sshd]
enabled  = true
backend  = auto
logpath  = /var/log/auth.log

Nos sistemas RHEL, o arquivo equivalente é /var/log/secure.

SSH em porta não padrão

Se o sshd escuta, por exemplo, na porta 2222, informe-a no jail. Caso contrário, o fail2ban bloqueará a porta 22, e o ataque continuará na 2222:

[sshd]
enabled = true
port    = 2222

Para bloquear todas as portas do infrator de uma vez, use a ação iptables-allports ou nftables-allports pelo parâmetro banaction.

Escolha do firewall: iptables, nftables, ufw, firewalld

Por padrão, no Debian o banaction é nftables (nas versões antigas, iptables), e no RHEL é o firewalld. Se o servidor usa o ufw, é mais cômodo que os bloqueios apareçam nele:

[DEFAULT]
banaction = ufw

Para o firewalld:

[DEFAULT]
banaction = firewallcmd-rich-rules

Para confirmar que as regras realmente foram criadas, use sudo nft list ruleset | grep f2b ou sudo iptables -L -n | grep f2b: o fail2ban cria cadeias com o prefixo f2b-.

Como conferir o funcionamento: fail2ban-client status

A ferramenta principal de gerenciamento é o fail2ban-client. Estado de um jail específico:

$ sudo fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 2
|  |- Total failed:     147
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 4
   |- Total banned:     38
   `- Banned IP list:   45.148.10.12 92.118.39.7 185.224.128.40 218.92.0.112

Aqui você vê quantos erros estão na janela agora, quantos IPs estão bloqueados e quais são. Para testar a proteção na prática, tente entrar várias vezes com a senha errada a partir de outra máquina (não uma que esteja em ignoreip): depois da terceira tentativa, a conexão deixa de ser estabelecida.

O log do próprio fail2ban fica em /var/log/fail2ban.log:

$ sudo tail -n 3 /var/log/fail2ban.log
2026-10-14 09:12:41,118 fail2ban.filter  [812]: INFO    [sshd] Found 218.92.0.112
2026-10-14 09:12:44,302 fail2ban.filter  [812]: INFO    [sshd] Found 218.92.0.112
2026-10-14 09:12:47,551 fail2ban.actions [812]: NOTICE  [sshd] Ban 218.92.0.112

Como desbanir um IP no fail2ban

Se você bloqueou a si mesmo ou a um colega, remova o bloqueio pelo console do servidor (pelo painel da hospedagem ou por outro IP):

sudo fail2ban-client set sshd unbanip 203.0.113.25

Para remover todos os bloqueios de todos os jails:

sudo fail2ban-client unban --all

Para bloquear um endereço manualmente, sem esperar o filtro disparar:

sudo fail2ban-client set sshd banip 198.51.100.7

Para que o problema não se repita, inclua seus endereços fixos ou a sub-rede do escritório em ignoreip.

Bloqueio progressivo para reincidentes

Muitos robôs voltam logo após o desbloqueio. A partir da versão 0.11, o fail2ban permite aumentar o tempo de bloqueio de reincidentes:

[DEFAULT]
bantime = 1h
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 4w

Cada novo bloqueio do mesmo IP será mais longo que o anterior, sem passar de quatro semanas. Uma alternativa para versões antigas é o jail recidive, que lê o log do próprio fail2ban e bloqueia por bastante tempo os endereços que aparecem várias vezes:

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

Teste do filtro: fail2ban-regex

Se o jail está ativo, mas não bloqueia ninguém, verifique se o filtro encontra alguma coisa no log. Para um arquivo de log:

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

Para o journal do systemd:

sudo fail2ban-regex systemd-journal sshd

Na saída, observe a linha Lines: ... matched. Zero correspondências significa que o filtro não combina com o formato dos logs ou que a fonte indicada está errada. Antes de reiniciar, vale também verificar a sintaxe de toda a configuração:

sudo fail2ban-client -t

Erros comuns

• O serviço não inicia: «Have not found any log file for sshd jail». Não existe /var/log/auth.log. Use backend = systemd ou instale o rsyslog.
• Os bloqueios aparecem no status, mas o ataque continua. A porta indicada está errada (o SSH foi transferido de porta) ou as regras do firewall são sobrepostas por uma permissão anterior. Confira port e a saída de nft list ruleset.
• As alterações não surtiram efeito. Você editou o jail.conf, mas o jail.local ou o jail.d/*.local tem outro valor. Veja o valor final: sudo fail2ban-client get sshd maxretry.
• Você bloqueou a si mesmo. Desbanir pelo console e incluir o seu IP em ignoreip.
• O fail2ban não vê ataques a contêineres Docker. As portas publicadas passam pela cadeia DOCKER, que contorna a INPUT. Para esses serviços, use chain = DOCKER-USER na ação.

O que mais fazer para proteger o SSH

O fail2ban funciona bem junto com as medidas básicas em /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no
MaxAuthTries 3

Depois da alteração, confira a configuração com sudo sshd -t e reinicie o serviço. Não encerre a sessão atual antes de confirmar, em uma nova conexão, que o login por chave funciona. Também é possível restringir o acesso ao SSH no firewall apenas aos endereços necessários.

Conclusão

A configuração do fail2ban se resume a alguns passos: instalar o pacote, criar o jail.local com a seção [sshd], escolher o backend e a porta corretos, definir maxretry, findtime e bantime, incluir os seus endereços em ignoreip e conferir o funcionamento com fail2ban-client status sshd. Junto com o login somente por chave, isso protege o SSH de forma confiável contra força bruta. A proteção de servidores e o fail2ban são praticados no curso de Linux.