17 out 2026 · segurança, linux, ssh · 5 min
Configurar fail2ban sem se trancar fora
Com maxretry 3, o ban do fail2ban entra na terceira falha do mesmo IP, nem na primeira nem na segunda. Um endereco dentro da ignoreip pode errar quatro vezes e continuar de fora, porque a lista e conferida antes do banimento. São esses dois números que definem se o serviço te protege ou te derruba, e a ordem das opções importa mais do que parece.
O que o jail.local controla de verdade
O jail.conf que vem na distribuição não se edita. Ele é sobrescrito numa atualização de pacote e você perde a configuração sem aviso. Tudo o que é seu vai em /etc/fail2ban/jail.local, que a distro não toca.
São cinco opções que decidem se você fica preso do lado de fora:
ignoreip é a rede de segurança. Um IP nesta lista nunca é banido, venha o que vier. maxretry é o número de falhas que dispara o ban. findtime é a janela dentro da qual essas falhas contam. bantime é quanto tempo o ban dura. E backend decide como o fail2ban descobre que o log mudou.
O jail.local
[DEFAULT]
# Enderecos que nunca sao banidos. Coloque o seu aqui, e a rede
# domestica, antes de qualquer outra coisa. E a linha que evita que
# um erro seu derrube o seu proprio acesso.
ignoreip = 127.0.0.1/8 ::1 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 SEU_IP_AQUI
# 3 falhas na janela. Com 2, um cliente que abre duas conexoes em
# paralelo (ssh multiplexado, git fetch) toma ban sem ter errado nada.
maxretry = 3
# As 3 falhas precisam caber em 10 minutos. Espalhar as tentativas
# por horas evita o ban sem nunca parar de tentar.
findtime = 10m
# Banimento inicial de 10 minutos.
bantime = 600
# Sobe o tempo a cada reincidencia do mesmo IP, em vez de repetir
# 10 minutos para sempre. O maximo de 1 semana impede que o numero
# creca sem limite.
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 604800
# auto escolhe systemd quando o sistema usa systemd, e polling quando
# nao usa. Sem isto o servico simplesmente nao sobe em maquinas sem
# systemd, que ainda existem.
backend = auto
[sshd]
enabled = true
port = ssh
maxretry = 3
findtime = 10m
bantime = 600
# O padrao do fail2ban nao bane o root por SSH. Se voce usa root com
# chave e nunca senha, o comentario abaixo e o caminho mais seguro.
ignoreregex =
Para descobrir qual é o endereço da sua conexão, use curl -s ifconfig.me e ponha o resultado na ignoreip. Sem essa linha, um erro na configuração derruba o seu próprio acesso.
Onde isso bate com o seu acesso
O fail2ban bane por IP, e o IP é a única coisa que ele sabe. Quem entra por chave SSH e tem a senha desligada já não corre o risco que a senha traz. Quem ainda usa senha tem dois motivos bons para manter o fail2ban: derrubar a tentativa antes de gastar CPU com ela, e cortar a repetição.
A ordem faz diferença. Senha desligada e chave primeiro, fail2ban como segunda camada. Invertido, o serviço vira o ponto único de falha: uma configuração errada tira o seu acesso, e a chave nunca estava lá para te salvar.
Como verificar
Antes de qualquer reinício, valide a configuração. O -t lê o arquivo e não aplica nada:
sudo fail2ban-client -t
A resposta é OK: configuration test is successful. Se algo estiver errado, o erro vem com o nome da opção. Esse comando sozinho já evita a maior parte dos sustos, porque ele não toca no firewall.
Depois de aplicar, confira quem está banido agora:
fail2ban-client status sshd
Você vê Currently banned, Total banned e a lista de IPs. Se aparecer o seu IP nessa lista, o ignoreip está errado e o serviço está pronto para te derrubar. Volte a conferir a linha antes de tentar entrar de novo.
Se você caiu fora e precisa sair, o comando que resolve é curto:
sudo fail2ban-client set sshd unbanip SEU_IP
Se der errado
O -t passa mas o serviço não sobe. A configuração está certa e o problema é o backend. Em máquina sem systemd, auto pode escolher mal. Troque por backend = polling e valide de novo.
Você aparece na lista de banidos. A ignoreip está sem o seu endereço, ou o seu IP é dinâmico e mudou. Descubra o atual com curl -s ifconfig.me e acrescente. Enquanto o seu endereço não estiver na lista, não reinicie o serviço.
O jail não acusa nenhuma falha. O filtro não está lendo o log certo. Em Debian o sshd grava em /var/log/auth.log, em Fedora em /var/log/secure. Confira com fail2ban-client -d e veja qual caminho o jail está usando.
fail2ban contra as alternativas
| opção | protege | depende de | drawback |
|---|---|---|---|
| fail2ban | SSH e outros jails | log do serviço | não conhece aplicação web |
| Two Factor Auth | conta inteira | app no celular | não corta ataque automatizado |
| porta SSH mudou | superfície | nada | segurança por obscuridade |
| chave sem senha | SSH | nada do log | não protege outros serviços |
Para porta web, o fail2ban sozinho não resolve: ele lê log de acesso, e o que trava aplicação web é limite de taxa na aplicação ou no proxy reverso. Para SSH, ele resolve, e é por isso que continua na lista.
FAQ
Preciso colocar o endereço da minha conexão no ignoreip? Sim, se ele for fixo. Se muda, use ignorecommand apontando para um arquivo que você atualiza, ou um DynDNS que resolva para o endereço atual.
maxretry 3 não é pouco? Para senha, é o ponto de equilíbrio. Com 2, um git fetch que abre duas conexões em paralelo pode tomar ban sem erro nenhum. Com 5, um robô já leva cinco tentativas de graça.
O que é bantime.increment? Faz o ban crescer a cada reincidência do mesmo IP, usando o histórico no banco do fail2ban. É útil contra quem volta, mas o número exato depende da sua configuração. Comece com bantime.maxtime para que não creça sem teto.
Usar fail2ban com senha SSH habilitada é seguro? Reduz o trabalho do ataque, mas não remove o risco: a senha continua sendo testável. Chave e senha desligada fecha o caminho de verdade.
Fontes
- fail2ban,
config/jail.conf, opçõesignoreip,maxretry,findtime,bantimeebantime.increment, conferido em 17 de outubro de 2026. - man.openbsd.org/sshd_config, opções de autenticação do servidor OpenSSH.
- Fail2Ban 1.1.1, medição própria em área de teste com backend polling, em 17 de outubro de 2026.