Como configurar Fail2Ban no Fedora 42 passo a passo

15 min de leitura  ·  Guia técnico

Configurar Fail2Ban no Fedora 42: proteção contra força bruta com regras personalizadas é ativar um serviço que lê logs de autenticação, identifica tentativas repetidas de falha e aplica bloqueios temporários por IP. Para proteger SSH e criar filtros próprios, siga estes passos:

1. Atualize o Fedora 42 e instale o pacote fail2ban pelo dnf.
2. Habilite e inicie o serviço fail2ban com systemctl.
3. Crie um jail.local para SSH usando backend systemd.
4. Teste a jail com fail2ban-client e valide eventos no journalctl.
5. Crie uma regra personalizada em filter.d e associe a um log real.
6. Monitore bloqueios, ajuste findtime, bantime e maxretry com cuidado.

Pré-requisitos

• Acesso root ou usuário com sudo no Fedora 42.
• Conexão SSH funcional antes de alterar qualquer regra de bloqueio.
• Pacote openssh-server ativo se o objetivo principal for proteger o SSH.
• Conhecimento básico de terminal Linux, systemctl, journalctl e edição de arquivos.
• Um segundo acesso de emergência, como console do provedor, para evitar ficar bloqueado fora do servidor.

Antes de avançar, confirme que você sabe acessar o servidor por outro caminho caso seu IP seja bloqueado por engano. Se ainda está organizando o acesso inicial ao servidor, veja também Acessando servidores VPS Linux da AviraHost, pois o Fail2Ban depende de uma administração SSH estável para ser configurado com segurança.

Instalação e ativação do Fail2Ban no Fedora 42

Proteção contra força bruta no SSH começa pela instalação correta do Fail2Ban e pela confirmação de que o serviço está lendo eventos reais do sistema. No Fedora 42, a abordagem mais segura é trabalhar com arquivos locais, sem editar diretamente arquivos padrão que podem ser sobrescritos em atualizações. Por padrão, o Fedora usa firewalld como gerenciador de firewall, e o Fail2Ban pode integrar com ele via a action firewallcmd-ipset, que executa comandos firewall-cmd para aplicar bloqueios. Em instalações mais recentes também é possível usar nftables diretamente, mas para a maioria dos casos o backend padrão já funciona bem. Ao rodar os comandos abaixo, você verá se o pacote foi instalado, se o serviço subiu e se o cliente consegue consultar o estado do daemon.

1. Atualize os metadados dos repositórios.
2. Instale o Fail2Ban.
3. Habilite o serviço para iniciar com o sistema.
4. Confira se o daemon está ativo antes de criar regras.

sudo dnf makecache
sudo dnf install fail2ban
sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban --no-pager

Output esperado:
Created symlink for fail2ban.service
Active: active running
Started Fail2Ban Service

Se o status aparecer como ativo, o próximo passo é criar a configuração local. Evite alterar arquivos como jail.conf diretamente. O arquivo jail.local é lido pelo Fail2Ban como camada de personalização e facilita auditoria, reversão e manutenção. Esse cuidado é importante em servidores de produção, principalmente quando há múltiplos serviços expostos, como SSH, painel, webmail ou aplicações próprias.

Ativar jail sshd no Fedora 42

Jail sshd no Fail2Ban é a regra que observa falhas de login no SSH e bloqueia endereços que excedem o limite definido. No Fedora 42, usar backend systemd costuma ser a escolha mais coerente quando os eventos de autenticação são consultados pelo journalctl. O objetivo aqui é bloquear tentativas repetidas sem ser agressivo demais com usuários legítimos que podem errar a senha algumas vezes.

Atenção: uma configuração muito restritiva pode bloquear seu próprio IP. Antes de reiniciar o Fail2Ban, mantenha uma sessão SSH aberta e confirme que você tem acesso ao console do servidor.

sudo tee /etc/fail2ban/jail.local
[DEFAULT]
bantime = 15m
findtime = 10m
maxretry = 5
backend = systemd

[sshd]
enabled = true
port = ssh
filter = sshd
backend = systemd
EOF

sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

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

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

Ao rodar este comando, você verá a jail sshd listada. Se ela não aparecer, o Fail2Ban não aplicou o arquivo local ou encontrou erro de sintaxe. Em servidores com acesso SSH por porta personalizada, substitua port = ssh pela porta correta. Se você também restringe acesso por IP, o artigo Passo a passo para configurar acesso restrito por IP no SSH do VPS Linux complementa a proteção, pois o Fail2Ban reduz tentativas repetidas, enquanto regras de acesso limitam quem pode tentar conectar.

Validar logs do SSH com journalctl e fail2ban-client

Logs do Fail2Ban no Fedora 42 devem ser conferidos em duas camadas: eventos do serviço fail2ban e eventos do serviço protegido. Essa validação evita um erro comum: a jail estar ativa, mas apontar para uma origem de log que não registra as falhas esperadas. Quando o backend systemd está em uso, journalctl se torna parte essencial do diagnóstico.

1. Consulte eventos recentes do serviço Fail2Ban.
2. Consulte eventos recentes do sshd.
3. Verifique quais jails estão ativas.
4. Confirme se a jail sshd acumula falhas quando há tentativas inválidas.

sudo journalctl -u fail2ban --no-pager -n 50
sudo journalctl -u sshd --no-pager -n 50
sudo fail2ban-client status sshd

Output esperado:
fail2ban.server: INFO Starting Fail2ban
fail2ban.jail: INFO Jail sshd started
sshd: Failed password for invalid user teste from 203.0.113.10 port 51422 ssh2
Status for the jail: sshd

Nem todo servidor exibirá uma linha de falha imediatamente; isso depende de tentativas reais ou de um teste controlado. Não force ataques contra o próprio servidor a partir de redes de terceiros. Se precisar testar, use um ambiente de laboratório ou uma origem sob seu controle e acompanhe o contador em fail2ban-client status sshd. A leitura correta dos logs é mais importante do que aumentar punições, porque um filtro que não reconhece linhas reais não vai bloquear nada.

Criar regra personalizada no Fail2Ban

Regra personalizada no Fail2Ban combina um filtro em /etc/fail2ban/filter.d com uma jail que indica o log, o limite de tentativas e a ação de bloqueio. Esse recurso é útil para proteger aplicações próprias, painéis internos ou serviços que gravam mensagens padronizadas de falha. A regra só deve ser ativada quando o padrão de log for conhecido; caso contrário, você pode criar falsos positivos ou uma jail que nunca bloqueia.

O exemplo abaixo considera uma aplicação que grava falhas em /var/log/minhaapp-auth.log com linhas contendo "Login failed from IP". Adapte o caminho e o texto ao log real da sua aplicação. O ponto principal é testar o filtro antes de reiniciar o Fail2Ban em produção.

sudo tee /etc/fail2ban/filter.d/minhaapp.conf
[Definition]
failregex = ^.*Login failed from .*$
ignoreregex =
EOF

sudo tee -a /etc/fail2ban/jail.local
[minhaapp]
enabled = true
filter = minhaapp
logpath = /var/log/minhaapp-auth.log
maxretry = 4
findtime = 10m
bantime = 30m
EOF

Output esperado:
[Definition]
failregex = ^.*Login failed from .*$
ignoreregex =

[minhaapp]
enabled = true
filter = minhaapp
logpath = /var/log/minhaapp-auth.log

Agora valide a expressão regular com fail2ban-regex. Esse teste mostra se as linhas do log combinam com o filtro. Se o retorno indicar zero correspondências, a jail não conseguirá banir IPs, mesmo que esteja habilitada.

sudo fail2ban-regex /var/log/minhaapp-auth.log /etc/fail2ban/filter.d/minhaapp.conf
sudo systemctl restart fail2ban
sudo fail2ban-client status minhaapp

Output esperado:
Lines: total lines, ignored lines, matched lines, missed lines
Status for the jail: minhaapp
|- Filter
`- Actions

Quando o status da jail personalizada aparecer, acompanhe os eventos por alguns minutos e revise o padrão de log. Para aplicações críticas, comece com bantime moderado e maxretry conservador. Depois, ajuste conforme o comportamento real observado. O Fail2Ban é uma camada de defesa, não uma substituição para autenticação forte, atualização do sistema e política de acesso mínima.

Ajustar bantime, findtime e maxretry com segurança

Bloqueio de IP por tentativas de login depende de três parâmetros centrais: maxretry define quantas falhas são toleradas, findtime define a janela de observação e bantime define quanto tempo o IP ficará bloqueado. Ajustes muito brandos podem não reduzir ruído automatizado; ajustes muito rígidos podem afetar usuários legítimos, integrações e rotinas de administração.

• maxretry: use para controlar quantas falhas consecutivas ou próximas acionam o bloqueio.
• findtime: use para delimitar o período em que as falhas serão somadas.
• bantime: use para definir o tempo de bloqueio aplicado ao IP identificado.
• ignoreip: use para declarar IPs confiáveis que nunca serão banidos, como seu endereço administrativo fixo — equivalente a uma whitelist de acessos confiáveis. Exemplo: ignoreip = 127.0.0.1/8 ::1 SEU_IP_FIXO.

sudo fail2ban-client get sshd bantime
sudo fail2ban-client get sshd findtime
sudo fail2ban-client get sshd maxretry

Output esperado:
900
600
5

Os valores podem aparecer em segundos conforme a interpretação interna do serviço. Se você alterar jail.local, reinicie o Fail2Ban e confirme novamente com fail2ban-client get. Em ambientes onde vários administradores acessam o mesmo servidor, documente qualquer alteração. Isso evita que um bloqueio legítimo seja confundido com falha de rede, erro de senha ou indisponibilidade do SSH.

Problemas comuns e como resolver

Sintoma: a jail sshd não aparece no status

Causa: o arquivo jail.local pode ter erro de sintaxe, nome de seção incorreto ou não ter sido salvo em /etc/fail2ban. Também pode haver falha na reinicialização do serviço.

Solução: rode sudo journalctl -u fail2ban --no-pager -n 80 e procure mensagens de erro. Depois valide o conteúdo do jail.local, reinicie o serviço e confirme com sudo fail2ban-client status. Ao rodar este comando, você verá a lista de jails carregadas.

Sintoma: o Fail2Ban está ativo, mas não bane IPs

Causa: o filtro pode não reconhecer as linhas reais de falha, o backend pode estar inadequado ou o logpath da regra personalizada pode apontar para um arquivo inexistente. Em jails com systemd, o problema também pode estar na unidade monitorada.

Solução: use fail2ban-regex no log real e compare com o filtro. Para SSH no Fedora 42, confira journalctl -u sshd e journalctl -u fail2ban. Se for uma aplicação própria, confirme se ela grava exatamente o texto esperado pelo failregex.

Sintoma: seu próprio IP foi bloqueado

Causa: muitas tentativas de senha incorreta, uso de cliente automatizado mal configurado ou parâmetros maxretry e findtime agressivos podem acionar o bloqueio. Isso é comum durante testes.

Solução: acesse pelo console do servidor ou por uma sessão ainda aberta e remova o bloqueio com fail2ban-client set sshd unbanip seguido do IP. Depois revise maxretry, bantime e, se fizer sentido, adicione um endereço administrativo confiável em ignoreip para que ele funcione como whitelist permanente.

Sintoma: erro ao iniciar após criar filtro personalizado

Causa: o arquivo em filter.d pode conter expressão inválida, seção ausente ou caractere inesperado. Outra causa comum é copiar um exemplo sem adaptar o padrão para o formato real do log.

Solução: teste sempre com fail2ban-regex antes de reiniciar o serviço. Se o serviço não subir, remova temporariamente a jail personalizada de jail.local, reinicie o Fail2Ban e reintroduza a regra apenas depois que o filtro passar no teste.

Perguntas frequentes

Como configurar Fail2Ban no Fedora 42 para proteger o SSH?

Para configurar Fail2Ban no Fedora 42, instale o pacote, habilite o serviço, crie um arquivo jail.local e ative uma jail para sshd. Depois valide os logs do SSH, reinicie o Fail2Ban e confirme se a jail aparece ativa com fail2ban-client status sshd.

O Fail2Ban bloqueia ataques de força bruta automaticamente?

O Fail2Ban bloqueia tentativas repetidas quando os logs combinam com os filtros configurados na jail. Ele não substitui firewall, senha forte ou autenticação por chave SSH, mas reduz a exposição a tentativas automatizadas de login.

Como criar uma regra personalizada no Fail2Ban?

Uma regra personalizada no Fail2Ban é criada com um filtro em /etc/fail2ban/filter.d/ e uma jail apontando para esse filtro e para o arquivo de log correto. Antes de ativar em produção, teste a expressão com fail2ban-regex para evitar bloqueios incorretos.

Onde ficam os logs do Fail2Ban no Fedora 42?

No Fedora 42, os eventos do serviço podem ser verificados pelo journalctl usando a unidade fail2ban. Também é comum validar logs do serviço protegido, como SSH, para confirmar se as tentativas de autenticação estão sendo registradas no caminho esperado.

O que fazer se o Fail2Ban não estiver banindo IPs?

Verifique se a jail está ativa, se o logpath aponta para um log existente e se o filtro reconhece as linhas reais de falha. Também confirme se o backend de logs está adequado ao Fedora 42 e se o serviço foi reiniciado após alterar os arquivos de configuração.

Conclusão

Configurar Fail2Ban no Fedora 42 é uma medida prática para reduzir tentativas repetidas contra SSH e serviços que geram logs confiáveis. A configuração fica mais segura quando você começa pela jail sshd, valida o journalctl, testa filtros com fail2ban-regex e só então cria regras personalizadas para aplicações específicas. Em servidores VPS com Fedora, combinar o Fail2Ban ao firewalld nativo garante uma defesa em camadas mais robusta para segurança de servidor VPS.

• Ative a jail sshd com backend systemd e confirme o status com fail2ban-client.
• Teste qualquer filtro personalizado contra logs reais antes de reiniciar o serviço.
• Use ignoreip para proteger endereços administrativos confiáveis de bloqueios acidentais.
• Mantenha console de emergência e revise bloqueios para evitar impacto em acessos legítimos.

Leia também

• Checklist de Segurança: Fail2ban vs CSF para proteger servidores Linux
• Checklist para Segurança de VPS Linux: Guia Completo de Proteção
• Como Instalar e Configurar o Firewall CSF no VPS Linux para Segurança Avançada

Precisa de ajuda com Fail2Ban no Fedora 42?

A AviraHost oferece infraestrutura VPS para quem precisa administrar servidores Linux com controle, segurança e flexibilidade. Se você quer hospedar aplicações e aplicar camadas como SSH seguro, firewall e Fail2Ban, escolha um ambiente adequado ao seu projeto.

Conheça os planos de Servidor VPS da AviraHost