Dominar o fail2ban vai muito além de instalar o pacote e ativar algumas jails padrão. Em ambientes de produção reais — servidores web, gateways de e-mail, clusters de bancos de dados e infraestrutura crítica — o profissional de segurança precisa ter controle total sobre quem está sendo bloqueado, por quanto tempo e, principalmente, quem jamais deve ser bloqueado. É exatamente nesse ponto que entram três pilares fundamentais da operação do fail2ban: o monitoramento contínuo dos eventos de banimento, a configuração precisa de whitelists (listas de exclusão) e a capacidade de diagnosticar e corrigir problemas quando o sistema não se comporta como esperado. Sem esses três elementos, o fail2ban pode se transformar em um risco: imagine bloquear acidentalmente o IP do seu próprio escritório, de um serviço de monitoramento externo ou de um balanceador de carga legítimo. As consequências vão desde indisponibilidade de serviços até chamados urgentes no meio da madrugada.
Em nossa experiência diária na JRT Technology Solutions, implementando e gerenciando sistemas de proteção para empresas de médio e grande porte, já presenciamos cenários em que uma whitelist mal configurada derrubou o acesso administrativo de toda uma equipe de DevOps. Por outro lado, também já vimos ambientes onde a falta de monitoramento adequado permitiu que ataques de força bruta passassem despercebidos por dias — simplesmente porque ninguém verificava se o fail2ban estava efetivamente bloqueando os IPs maliciosos. Esta aula foi projetada para que você não cometa esses erros. Vamos mergulhar fundo nos mecanismos de logging, nas opções avançadas de whitelist (incluindo listas dinâmicas e arquivos externos), nas técnicas de verificação de funcionamento e em um roteiro completo de troubleshooting que nossos especialistas utilizam diariamente para resolver os problemas mais comuns e os mais obscuros do fail2ban.
Ao final desta aula, você terá autonomia para inspecionar cada ação que o fail2ban executa, excluir preventivamente IPs e faixas inteiras de endereços confiáveis, detectar gargalos de desempenho, interpretar corretamente os arquivos de log e aplicar correções rápidas quando as jails pararem de funcionar. Todo o conteúdo é baseado em cenários reais, com comandos testados e validados nas distribuições Linux mais utilizadas no mercado corporativo. Se você já concluiu as aulas anteriores do curso, onde instalamos e configuramos as jails básicas do fail2ban, está pronto para elevar seu conhecimento ao nível intermediário e começar a operar o sistema com a confiança de um administrador experiente.
O que você vai aprender nesta aula
- Compreender a arquitetura de logging do fail2ban e como extrair informações relevantes dos arquivos de log
- Configurar whitelists estáticas e dinâmicas utilizando o parâmetro ignoreip e arquivos externos
- Monitorar em tempo real os banimentos e desbanimentos com comandos nativos do fail2ban-client
- Interpretar o log principal (/var/log/fail2ban.log) para auditoria e diagnóstico
- Executar procedimentos completos de troubleshooting para as falhas mais comuns do fail2ban
- Aplicar verificações sistemáticas para garantir que todas as jails estão operacionais
- Utilizar expressões regulares de teste (failregex) para validar regras de detecção sem depender de ataques reais
- Diferenciar erros de configuração, permissão e sintaxe nos arquivos jail.local e filter.d
Pré-requisitos e Ambiente
Para acompanhar esta aula com aproveitamento máximo, você precisa ter o fail2ban instalado e funcionando em um servidor Linux — recomendamos Ubuntu Server 22.04/24.04 LTS, Debian 12, CentOS Stream 9 ou Rocky Linux 9. É imprescindível que você já tenha concluído as aulas anteriores do curso, especialmente aquelas que cobrem a instalação do fail2ban, a estrutura de diretórios (/etc/fail2ban/), a diferença entre jail.conf e jail.local e a ativação de jails como sshd, nginx-http-auth ou postfix. Você precisará de acesso root ou privilégios de sudo em todos os servidores utilizados. Além disso, tenha um editor de texto de sua preferência (nano, vim ou micro) e certifique-se de que o serviço fail2ban está em execução — utilizaremos o systemctl para controlar o daemon. Se você utiliza firewalld (CentOS/RHEL/Rocky), verifique se ele está ativo, pois o fail2ban interage diretamente com o firewall do sistema para criar e remover regras de bloqueio.
Recomendamos também que você tenha uma segunda sessão de terminal aberta ou utilize ferramentas como tmux ou screen. Durante os exercícios de monitoramento em tempo real, precisaremos visualizar logs enquanto realizamos ações simultâneas. Por fim, se possível, tenha um segundo IP disponível (por exemplo, via VPN ou outro servidor na mesma rede) para simular tentativas de acesso que gerem eventos de banimento — isso tornará o aprendizado muito mais concreto e facilitará a compreensão dos mecanismos de whitelist e troubleshooting que exploraremos a fundo.
A Importância do Monitoramento Contínuo no fail2ban
O fail2ban é, por natureza, um sistema reativo. Ele não previne ataques — ele responde a eles com base em padrões detectados nos arquivos de log dos serviços protegidos. Essa característica torna o monitoramento uma atividade crítica: sem visibilidade sobre o que está acontecendo, você está essencialmente operando no escuro. Em nossos projetos na JRT Technology Solutions, implementamos rotinas de verificação que incluem conferências periódicas do status das jails, análise automatizada dos logs de banimento e alertas proativos quando o número de IPs bloqueados ultrapassa determinados thresholds. Um pico repentino de banimentos pode indicar um ataque em andamento — ou, pior, um falso positivo que está bloqueando tráfego legítimo em massa.
O monitoramento do fail2ban se divide em três camadas principais. A primeira é o acompanhamento em tempo real via fail2ban-client, que permite consultar o status de cada jail individualmente, listar IPs banidos e verificar estatísticas como total de falhas detectadas e banimentos ativos. A segunda camada envolve a análise dos arquivos de log — principalmente o /var/log/fail2ban.log — onde cada ação do daemon é registrada com timestamp, nível de severidade e detalhes sobre o IP, a jail afetada e o serviço de origem. A terceira camada, mais avançada, integra o fail2ban a sistemas de monitoramento externos como Zabbix, Nagios, Prometheus ou Grafana, exportando métricas que podem disparar alertas e gerar dashboards operacionais. Nesta aula, focaremos nas duas primeiras camadas, que formam a base indispensável antes de qualquer integração mais sofisticada.
Entendendo a Whitelist (ignoreip) a Fundo
O parâmetro ignoreip é, provavelmente, uma das configurações mais subestimadas — e perigosas — do ecossistema fail2ban. Ele define uma lista de endereços IP, faixas de rede ou hosts DNS que serão completamente ignorados por todas as jails (quando definido globalmente na seção [DEFAULT]) ou por jails específicas. Na prática, qualquer IP que corresponda a uma entrada em ignoreip pode realizar quantas tentativas de falha quiser sem jamais ser bloqueado. Isso torna o parâmetro extremamente poderoso para proteger IPs confiáveis, mas também o transforma em uma potencial vulnerabilidade se configurado de forma descuidada — um range excessivamente amplo (como 10.0.0.0/8 aplicado globalmente, por exemplo) pode criar uma porta dos fundos imensa para atacantes internos ou dispositivos comprometidos.
A lógica de processamento do ignoreip segue a ordem: primeiro são avaliadas as whitelists globais (definidas em [DEFAULT]), depois as whitelists específicas da jail. Se um IP estiver em qualquer uma dessas listas, ele é imediatamente ignorado, mesmo que já tenha excedido os limites de maxretry. O fail2ban também aceita máscaras de rede no formato CIDR (como 192.168.1.0/24), o que permite proteger faixas inteiras de endereços com uma única linha. Além disso, é possível referenciar arquivos externos contendo listas de IPs, uma prática recomendada para ambientes que gerenciam whitelists dinâmicas — por exemplo, listas atualizadas automaticamente com os IPs dos escritórios corporativos, data centers parceiros ou serviços de CDN. O suporte a resolução DNS também existe, mas deve ser usado com cautela: se o nome de host não for resolvível no momento da inicialização do fail2ban, a entrada será ignorada silenciosamente, sem qualquer aviso de erro.
Configurando Whitelist no fail2ban — Passo a Passo Completo
Agora vamos colocar em prática a configuração de whitelists no fail2ban. Trabalharemos com três cenários progressivos: whitelist global no arquivo jail.local, whitelist por jail específica e whitelist baseada em arquivo externo. Todos os passos são executados em sistemas Ubuntu/Debian e CentOS/RHEL/Rocky Linux, e o procedimento é idêntico em ambas as famílias, pois o fail2ban utiliza a mesma estrutura de arquivos e sintaxe.
- Abra o arquivo de configuração local: Execute sudo nano /etc/fail2ban/jail.local (ou use vim, conforme sua preferência). Se o arquivo ainda não existir, o editor o criará ao salvar.
- Localize ou crie a seção [DEFAULT]: Esta seção aplica configurações a todas as jails, a menos que sejam sobrescritas em uma jail específica.
- Adicione o parâmetro ignoreip: Defina os IPs ou faixas que devem ser ignorados globalmente.
- Adicione ignoreip em uma jail específica: Se desejar whitelist apenas para SSH, por exemplo, adicione o parâmetro na seção [sshd].
- Salve o arquivo e reinicie o fail2ban: As alterações só entram em vigor após a reinicialização do serviço.
Abaixo, o conteúdo completo do arquivo /etc/fail2ban/jail.local com whitelist global, whitelist específica para a jail SSH e referência a um arquivo externo de IPs confiáveis. Este é um exemplo funcional que você pode adaptar ao seu ambiente:
# /etc/fail2ban/jail.local — Configuração completa com whitelist
# JRT Technology Solutions — Curso Firewall, fail2ban e CrowdSec
[DEFAULT]
# Whitelist global: IPs que jamais serão banidos em nenhuma jail
# 127.0.0.1/8 — loopback local (essencial para serviços internos)
# 10.50.0.0/16 — rede interna da empresa (exemplo)
# 203.0.113.5 — IP público do escritório central (exemplo)
# /etc/fail2ban/whitelist.conf — arquivo externo com IPs dinâmicos
ignoreip = 127.0.0.1/8 10.50.0.0/16 203.0.113.5 /etc/fail2ban/whitelist.conf
# Tempo de banimento padrão (em segundos): 1 hora
bantime = 3600
# Número máximo de falhas antes do bloqueio
maxretry = 5
# Janela de tempo para contagem de falhas (em segundos)
findtime = 600
[sshd]
# Ativa a jail SSH
enabled = true
# Porta monitorada (padrão 22; altere se seu SSH usa porta customizada)
port = ssh
# Whitelist específica para SSH: IP do administrador remoto
# Este IP pode errar a senha quantas vezes quiser sem ser banido
ignoreip = 198.51.100.25 192.0.2.10
[nginx-http-auth]
enabled = true
port = http,https
# Esta jail herda a whitelist global do [DEFAULT]
# Nenhuma whitelist adicional específica foi definida aqui
O arquivo externo /etc/fail2ban/whitelist.conf referenciado no parâmetro ignoreip global deve conter um IP ou faixa por linha. Comentários são permitidos utilizando o caractere #. Veja o conteúdo de exemplo que utilizamos em implantações reais na JRT Technology Solutions:
# /etc/fail2ban/whitelist.conf — Lista externa de IPs confiáveis
# Atualizado automaticamente via script de sincronização
# IPs dos escritórios regionais
198.51.100.1
198.51.100.2
198.51.100.3
# Faixa do data center parceiro (AWS VPC)
172.31.0.0/16
# Serviço de monitoramento externo (exemplo: StatusCake)
203.0.113.100
203.0.113.101
# CDN e proxies reversos confiáveis
# Cloudflare (apenas faixas de exemplo — use as listas oficiais)
# 103.21.244.0/22
# 103.22.200.0/22
Explicação linha por linha dos parâmetros utilizados: O ignoreip na seção [DEFAULT] estabelece a política global — qualquer IP listado aqui está imune a bloqueios em todas as jails do sistema. O endereço 127.0.0.1/8 cobre todo o range de loopback, essencial para que serviços rodando localmente (como scripts de monitoramento que fazem conexões SMTP ou HTTP de teste) não sejam bloqueados acidentalmente. A faixa 10.50.0.0/16 é um exemplo de rede interna corporativa; ajuste-a conforme seu ambiente real. O IP único 203.0.113.5 representa o endereço público fixo do seu escritório. O caminho /etc/fail2ban/whitelist.conf instrui o fail2ban a ler um arquivo externo e incluir todos os IPs e faixas ali listados como parte da whitelist global — esse arquivo pode ser atualizado sem necessidade de reiniciar o fail2ban se você utilizar o comando sudo fail2ban-client reload. Na seção [sshd], o parâmetro ignoreip é redefinido com IPs adicionais, específicos para a jail SSH. Quando um parâmetro é redefinido em uma jail, ele substitui completamente o valor herdado do [DEFAULT] — ou seja, o SSH da nossa configuração NÃO herdará os IPs 127.0.0.1/8 ou 10.50.0.0/16, a menos que sejam repetidos explicitamente. Este é um comportamento crucial e uma fonte comum de erros que abordaremos na seção de troubleshooting.
| Contexto de Definição | Escopo | Herdado por Jails? | Pode ser Sobrescrito? | Reinicialização Necessária? |
|---|---|---|---|---|
| [DEFAULT] | Global — todas as jails | Sim, a menos que a jail redefina o parâmetro | Sim, por jail específica | fail2ban-client reload ou systemctl restart fail2ban |
| Seção da jail (ex: [sshd]) | Apenas a jail específica | Não — substitui completamente o valor herdado | Não se aplica a outras jails | fail2ban-client reload ou reinicialização da jail específica |
| Arquivo externo referenciado | Depende de onde o arquivo é referenciado | Sim, se referenciado no [DEFAULT] | Sim, o conteúdo do arquivo pode ser alterado e recarregado | fail2ban-client reload (recarrega o arquivo) |
Monitorando o fail2ban em Tempo Real com fail2ban-client
O utilitário fail2ban-client é a principal interface de comunicação com o daemon do fail2ban. Ele se conecta a um socket Unix localizado em /var/run/fail2ban/fail2ban.sock (ou similar, dependendo da distribuição) e permite executar comandos administrativos sem manipular manualmente os arquivos de configuração ou sinais de processo. Nesta seção, vamos explorar os comandos mais poderosos para monitoramento em tempo real, começando pelos básicos e avançando para técnicas mais sofisticadas de verificação.
O primeiro comando que você deve conhecer é o status, que exibe informações gerais sobre o daemon e todas as jails ativas. A sintaxe completa para ver o status geral é sudo fail2ban-client status. Para obter detalhes de uma jail específica, utilize sudo fail2ban-client status <nome_da_jail> — por exemplo, sudo fail2ban-client status sshd. Este segundo formato é extremamente útil porque retorna o número atual de IPs banidos naquela jail, a lista completa de filtros aplicados e as ações configuradas. Abaixo demonstramos a execução completa com a saída esperada em um servidor com as jails sshd e nginx-http-auth ativas e alguns IPs já banidos:
# Verificando o status geral do fail2ban
sudo fail2ban-client statusStatus
|- Number of jail: 2
`- Jail list: nginx-http-auth, sshd# Verificando o status detalhado da jail sshd
sudo fail2ban-client status sshdStatus for the jail: sshd
|- Filter
| |- Currently failed: 3
| |- Total failed: 27
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 2
|- Total banned: 9
`- Banned IP list: 203.0.113.99 198.51.100.44Interpretação da saída: A jail sshd está ativa e monitorando o arquivo /var/log/auth.log. O campo Currently failed (3) indica que há 3 tentativas de falha registradas no momento que ainda não atingiram o limite de maxretry. O campo Total failed (27) é o acumulado histórico desde a última reinicialização do fail2ban. Na seção Actions, vemos que existem atualmente 2 IPs banidos (Currently banned: 2), e o histórico total registra 9 banimentos — isso significa que 7 IPs já foram desbanidos (por expiração do bantime ou remoção manual). A lista Banned IP list exibe exatamente quais IPs estão bloqueados neste momento. Com essas informações, você pode cruzar os IPs banidos com logs de acesso para investigar a origem de ataques, ou verificar se algum IP legítimo foi bloqueado indevidamente.
| Comando | Função | Exemplo de Uso |
|---|---|---|
| status | Exibe status geral ou de uma jail específica | sudo fail2ban-client status sshd |
| get <jail> banned | Retorna apenas a lista de IPs banidos na jail | sudo fail2ban-client get sshd banned |
| get <jail> banip <IP> | Testa se um IP específico está banido na jail | sudo fail2ban-client get sshd banip 203.0.113.99 |
| get <jail> findtime | Retorna a janela de tempo configurada para a jail | sudo fail2ban-client get sshd findtime |
| get <jail> maxretry | Retorna o número máximo de tentativas configurado | sudo fail2ban-client get sshd maxretry |
| get <jail> ignoreip | Exibe a lista de IPs na whitelist da jail | sudo fail2ban-client get sshd ignoreip |
| ping | Verifica se o daemon está respondendo | sudo fail2ban-client ping |
Para um monitoramento realmente em tempo real, você pode combinar o fail2ban-client com o comando watch do Linux. Por exemplo, watch -n 5 ‘sudo fail2ban-client status sshd’ atualizará o status da jail SSH a cada 5 segundos, permitindo que você observe em tempo real as mudanças nos contadores de falhas e banimentos enquanto um ataque está em andamento ou durante seus testes de validação. Outra técnica poderosa, que utilizamos frequentemente em nossos projetos na JRT Technology Solutions, é o monitoramento contínuo via tail combinado com grep para criar alertas visuais no terminal:
# Monitoramento em tempo real do log do fail2ban
# Exibe apenas linhas contendo "Ban" ou "Unban" com cores distintas
sudo tail -f /var/log/fail2ban.log | grep --color=auto -E "Ban|Unban|WARNING|ERROR"A saída desse comando mostrará, em tempo real, cada vez que um IP for banido ou desbanido em qualquer jail do sistema. O parâmetro –color=auto destaca as palavras-chave com cores diferentes, facilitando a identificação visual imediata de eventos importantes. Em ambientes de produção, recomendamos redirecionar essa saída para um arquivo de log separado ou integrá-la a ferramentas como Logstash ou rsyslog para armazenamento de longo prazo e análise histórica. No monitoramento de incidentes reais, a capacidade de correlacionar eventos de banimento do fail2ban com logs de firewall, IDS e aplicações web é um diferencial competitivo enorme — e é exatamente esse tipo de visibilidade que buscamos construir.
Analisando os Arquivos de Log do fail2ban
O arquivo /var/log/fail2ban.log é a fonte primária de verdade sobre tudo o que acontece no ecossistema do fail2ban. Cada linha segue um formato consistente que inclui timestamp, nível de severidade, nome do módulo ou jail e a mensagem descritiva. Compreender essa estrutura é fundamental para auditoria, troubleshooting e integração com sistemas externos. A rotação de logs é gerenciada pelo logrotate através do arquivo /etc/logrotate.d/fail2ban, que por padrão mantém até 12 arquivos rotacionados em distribuições Debian/Ubuntu, comprimindo os mais antigos com gzip. Em CentOS/RHEL/Rocky Linux, a política de rotação pode variar, e recomendamos verificar a configuração com cat /etc/logrotate.d/fail2ban.
Os níveis de severidade utilizados pelo fail2ban seguem a convenção padrão do syslog: INFO para operações normais (inicialização de jails, banimentos, desbanimentos), WARNING para situações que merecem atenção mas não são críticas (IP já banido tentando ser banido novamente, arquivo de log de serviço inacessível momentaneamente) e ERROR para falhas que impedem o funcionamento correto (erro de sintaxe em filtro, socket de comunicação inacessível, permissão negada em arquivos essenciais). Em nossas auditorias na JRT Technology Solutions, treinamos as equipes a nunca ignorarem mensagens de WARNING repetidas — elas frequentemente são sintomas precoces de problemas que evoluirão para ERROR se não forem tratados.
# Visualizando as últimas 50 linhas do log do fail2ban
sudo tail -n 50 /var/log/fail2ban.log2026-06-17 08:15:23,456 fail2ban.jail [12345]: INFO Jail 'sshd' started
2026-06-17 08:15:23,789 fail2ban.actions [12345]: NOTICE [sshd] Ban 203.0.113.99
2026-06-17 08:15:24,123 fail2ban.filter [12345]: INFO [sshd] Found 203.0.113.99 - 2026-06-17 08:15:23
2026-06-17 08:20:01,234 fail2ban.actions [12345]: NOTICE [sshd] Ban 198.51.100.44
2026-06-17 08:22:18,567 fail2ban.filter [12345]: INFO [nginx-http-auth] Found 192.0.2.88 - 2026-06-17 08:22:17
2026-06-17 08:22:19,012 fail2ban.actions [12345]: NOTICE [nginx-http-auth] Ban 192.0.2.88
2026-06-17 08:22:19,345 fail2ban.actions [12345]: WARNING [sshd] 203.0.113.99 already banned
2026-06-17 09:15:25,678 fail2ban.actions [12345]: NOTICE [sshd] Unban 203.0.113.99Interpretação detalhada de cada linha do log: A primeira linha registra o start da jail sshd, que ocorreu às 08:15:23. O número entre colchetes ([12345]) é o PID do processo fail2ban-server. A segunda linha é um evento de banimento (Ban) do IP 203.0.113.99 pela jail SSH. A terceira linha (Found) indica que o filtro da jail detectou uma nova tentativa de falha — neste caso, ela coincide com o momento do banimento, mas poderia ser uma falha anterior que estava dentro da janela de findtime. A quarta linha mostra o banimento do IP 198.51.100.44 às 08:20:01. A quinta e sexta linhas registram a detecção e banimento de 192.0.2.88 pela jail nginx-http-auth. A sétima linha é particularmente importante: o WARNING already banned indica que o IP 203.0.113.99 tentou ser banido novamente enquanto já estava na lista de bloqueio — isso é esperado em ataques persistentes e não representa um problema, mas serve como indicador de que o atacante continua tentando. A oitava linha mostra o desbanimento (Unban) do mesmo IP exatamente uma hora depois (às 09:15:25), consistente com o bantime = 3600 configurado.
Troubleshooting Avançado — Diagnosticando e Resolvendo Problemas no fail2ban
Quando o fail2ban não está bloqueando IPs como esperado — ou está bloqueando IPs que não deveria — é hora de iniciar um processo sistemático de troubleshooting. Em nossos atendimentos de suporte na JRT Technology Solutions, seguimos um roteiro de cinco etapas que nos permite isolar a causa raiz em mais de 90% dos casos em menos de 15 minutos. A primeira etapa é sempre verificar se o serviço está efetivamente rodando e se as jails estão carregadas. A segunda é validar a configuração sintática dos arquivos. A terceira é testar os filtros (failregex) com logs de exemplo. A quarta é examinar permissões de arquivos e diretórios. A quinta é ativar o modo debug para obter informações detalhadas sobre o processamento interno.
Etapa 1 — Verificação de serviço e jails: Execute sudo systemctl status fail2ban para confirmar que o daemon está ativo. Em seguida, use sudo fail2ban-client status para listar as jails carregadas. Se uma jail que você configurou não aparecer na lista, há um erro de sintaxe ou de nomenclatura no arquivo jail.local. Para verificar a sintaxe do arquivo sem iniciar o serviço, utilize sudo fail2ban-server -t — este comando executa uma validação de configuração e reporta erros de sintaxe com indicação de linha.
# Testando a sintaxe da configuração do fail2ban
sudo fail2ban-server -tConfiguration test is successfulEtapa 2 — Validação dos filtros (failregex): Um dos problemas mais comuns é o filtro de uma jail não estar detectando as linhas de log do serviço. Para testar se uma expressão regular (failregex) está funcionando, utilize o comando fail2ban-regex, que recebe como argumentos uma linha de log (ou arquivo de log) e o arquivo de filtro (ou a expressão regular diretamente). Abaixo demonstramos o teste com uma linha de falha de autenticação SSH e o filtro padrão sshd.conf:
# Testando o filtro sshd contra uma linha de log de falha de autenticação
fail2ban-regex "Jun 17 08:15:23 server sshd[54321]: Failed password for root from 203.0.113.99 port 22 ssh2" /etc/fail2ban/filter.d/sshd.confRunning tests
=============
Use failregex filter file : sshd, basedir: /etc/fail2ban
Use log line : Jun 17 08:15:23 server sshd[54321]: Failed password for invalid user root from 203.0.113.99 port 22 ssh2
Results
=======
Failregex: 1 total
|- #) [# of hits] regular expression
| 1) [1] ^[aA]uthentication failure; .* rhost=<HOST>(?:\s+.*)?$
| 2) [1] ^Failed \S+ for .*? from <HOST>(?: port \d*)?(?: ssh\d*)?(: (?!.*preauth).*)?$
| ...
`-
Ignoreregex: 0 total
Date template hits:
|- [# of hits] date format
| [1] {^LN-BEG}TAI64N
| [0] ^(?:\S+ )?(?:@(... )?)?(?:\[?[0-9]+\]?[:.])?[0-9]+[.:][0-9]+[.:]?[0-9]*
`-
Lines: 1 lines, 0 ignored, 1 matched, 0 missed
[processed in 0.01 sec]A saída mostra que a linha de log foi processada com sucesso: 1 matched indica que a expressão regular capturou o IP. Se o resultado fosse 0 matched, significaria que o filtro não reconheceu o formato da linha de log — situação comum quando o serviço gera logs em formato diferente do esperado (por exemplo, logs em JSON, timestamps customizados ou mensagens traduzidas para outros idiomas). Nesse caso, você precisaria criar um filtro personalizado ou ajustar o existente, tópico que abordaremos em aulas futuras sobre personalização avançada de filtros.
Etapa 3 — Verificação de permissões: O fail2ban precisa ler os arquivos de log dos serviços monitorados. Se o usuário sob o qual o fail2ban roda (geralmente root ou, em instalações mais seguras, um usuário dedicado como fail2ban) não tiver permissão de leitura nesses arquivos, a jail será carregada, mas nunca detectará eventos. Execute sudo -u fail2ban cat /var/log/auth.log (ajuste o arquivo conforme necessário) para testar a permissão. Se receber “Permission denied”, ajuste as permissões ou adicione o usuário fail2ban ao grupo proprietário do arquivo (geralmente adm ou systemd-journal).
Etapa 4 — Modo debug: Quando todos os passos anteriores não revelam o problema, é hora de iniciar o fail2ban em primeiro plano com nível máximo de verbosidade. Pare o serviço com sudo systemctl stop fail2ban e execute sudo fail2ban-server -f -v -v –logtarget=STDOUT. Os flags -f (foreground) e -v -v (verbosidade dupla) farão com que cada ação do daemon seja impressa no terminal em tempo real, incluindo a leitura de cada linha de log, a avaliação de cada expressão regular e a decisão de banir ou não um IP. Este nível de detalhe é indispensável para diagnosticar problemas complexos, como conflitos de whitelist, timeouts de ações ou falhas na comunicação com o backend do firewall.
Verificando a Instalação / Testando a Configuração
Nesta seção obrigatória, executaremos uma bateria de comandos de verificação que devem ser aplicados sempre que você modificar a configuração do fail2ban, seja adicionando uma nova jail, alterando whitelists ou ajustando parâmetros de banimento. O roteiro abaixo é exatamente o procedimento que aplicamos em cada implantação concluída na JRT Technology Solutions antes de considerar o ambiente como “pronto para produção”.
Passo 1 — Verificar se o serviço está rodando:
sudo systemctl is-active fail2banactivePasso 2 — Testar a comunicação com o daemon via socket:
sudo fail2ban-client pingServer replied: pongPasso 3 — Listar todas as jails ativas e verificar se a jail desejada está presente:
sudo fail2ban-client statusStatus
|- Number of jail: 2
`- Jail list: nginx-http-auth, sshdPasso 4 — Verificar os parâmetros efetivos de uma jail específica, incluindo a whitelist:
# Verificando a whitelist da jail sshd
sudo fail2ban-client get sshd ignoreip198.51.100.25 192.0.2.10# Verificando maxretry, findtime, bantime
sudo fail2ban-client get sshd maxretry
sudo fail2ban-client get sshd findtime
sudo fail2ban-client get sshd bantime5
600
3600Passo 5 — Simular um cenário real de whitelist: Para confirmar que a whitelist está funcionando, você pode gerar tentativas de falha a partir de um IP que esteja na lista de exclusão e verificar nos logs do fail2ban que ele foi ignorado. Por exemplo, se 198.51.100.25 está na whitelist do SSH, tente logins com senha errada a partir desse IP propositalmente. Em seguida, verifique o log:
sudo grep "198.51.100.25" /var/log/fail2ban.log2026-06-17 10:30:15,123 fail2ban.filter [12345]: INFO [sshd] Ignore 198.51.100.25 by ipA mensagem Ignore … by ip confirma que o mecanismo de whitelist está funcionando corretamente. Se o IP não estivesse na whitelist, você veria mensagens de Found e, após atingir maxretry, um Ban. Esta validação é particularmente importante após alterações em whitelists — nunca presuma que a configuração está correta sem testá-la ativamente.
Erros Comuns e Como Resolver
Ao longo de centenas de implantações e suportes prestados pela JRT Technology Solutions, catalogamos os erros mais frequentes que profissionais de TI encontram ao trabalhar com monitoramento, whitelist e troubleshooting do fail2ban. Abaixo, apresentamos quatro erros clássicos com a descrição completa do sintoma, a causa raiz e o procedimento detalhado de solução.
-
Erro 1: Jail aparece como ativa, mas não bloqueia IPs (zero banimentos mesmo com ataques em andamento).
Sintoma: Você executa sudo fail2ban-client status sshd e a jail está listada, o contador Total failed pode até incrementar, mas Total banned permanece em zero indefinidamente. O log /var/log/fail2ban.log mostra mensagens Found mas nunca Ban.
Causa: O parâmetro maxretry está configurado com um valor muito alto em relação à taxa real de tentativas, ou o findtime é muito curto, fazendo com que as falhas expirem antes de atingir o limite. Alternativamente, o IP atacante pode estar na whitelist (verifique com sudo fail2ban-client get <jail> ignoreip).
Solução: Reduza maxretry para 3 e aumente findtime para 600 no arquivo /etc/fail2ban/jail.local. Execute sudo fail2ban-client reload. Se o IP estiver na whitelist, remova-o ou ajuste a whitelist conforme a política de segurança da organização. Teste com logs simulados usando fail2ban-regex para garantir que o filtro está capturando corretamente. -
Erro 2: Whitelist definida no [DEFAULT] não está sendo aplicada a uma jail específica.
Sintoma: Você adicionou ignoreip = 10.0.0.0/8 na seção [DEFAULT], mas IPs da rede 10.x.x.x continuam sendo banidos na jail sshd. O comando sudo fail2ban-client get sshd ignoreip retorna uma lista diferente da esperada.
Causa: A seção [sshd] no arquivo jail.local contém sua própria definição de ignoreip, que substitui completamente o valor herdado do [DEFAULT]. Este é o comportamento esperado do fail2ban — parâmetros definidos em uma jail sobrescrevem os defaults.
Solução: Se você deseja que a jail herde e acrescente IPs à whitelist global, você deve repetir os valores do [DEFAULT] na seção da jail. Exemplo: ignoreip = 10.0.0.0/8 127.0.0.1/8 198.51.100.25. Não há um mecanismo nativo de “append” — a sobrescrita é total. Após corrigir, execute sudo fail2ban-client reload e verifique novamente com get ignoreip. -
Erro 3: “WARNING Unable to find a corresponding IP address for <hostname>” nos logs.
Sintoma: O arquivo /var/log/fail2ban.log exibe repetidamente a mensagem de WARNING sobre incapacidade de resolver um nome de host. O IP correspondente não está sendo adicionado à whitelist, e o fail2ban pode estar bloqueando o tráfego que deveria ser ignorado.
Causa: O parâmetro ignoreip contém um nome de host (FQDN) que o servidor não consegue resolver via DNS. Isso pode ocorrer por falha no servidor DNS configurado em /etc/resolv.conf, por um nome digitado incorretamente ou por um domínio que expirou.
Solução: Substitua nomes de host por endereços IP fixos sempre que possível. Se o uso de FQDN for inevitável, teste a resolução com nslookup <hostname> ou dig <hostname>. Certifique-se de que o servidor DNS está acessível no momento da inicialização do fail2ban. Uma alternativa robusta é criar um script que resolva os FQDNs periodicamente e atualize um arquivo de whitelist externo com os IPs correspondentes, eliminando a dependência do fail2ban fazer a resolução em tempo real. -
Erro 4: “fail2ban-server -t” retorna sucesso, mas o serviço não inicia.
Sintoma: O teste de sintaxeQuer aprender na prática com especialistas?
A JRT Technology Solutions oferece treinamentos e implementação de Firewall, fail2ban e CrowdSec para equipes corporativas.