Aula 24: Hardening completo — firewall + fail2ban + CrowdSec em produção

Chegamos a um dos pontos mais aguardados do nosso curso: o hardening completo de um servidor em produção usando as três camadas defensivas que estudamos nas aulas anteriores — firewall, fail2ban e CrowdSec. Até aqui você aprendeu a instalar, configurar e ajustar cada ferramenta individualmente. Nesta aula, vamos elevar o nível e construir uma solução integrada, robusta e preparada para enfrentar o tráfego real da internet. O objetivo não é apenas bloquear portas ou banir IPs, mas criar uma arquitetura de defesa em profundidade onde cada componente complementa o outro, reduzindo drasticamente a superfície de ataque e automatizando respostas a ameaças.

Esta aula é avançada porque envolve decisões de arquitetura, ordenação de regras, integração entre ferramentas e ajustes finos que fazem a diferença entre um servidor “protegido” e um servidor verdadeiramente blindado. Você vai executar um procedimento completo de hardening completo, passando pela criação de um conjunto de regras de firewall com nftables, pela configuração de jails agressivas no fail2ban e pela ativação do CrowdSec com bouncer de firewall. Cada passo foi pensado para ser reproduzido em um servidor real, com saídas esperadas e verificações de funcionamento.

Por que isso importa? Em produção, um servidor exposto à internet recebe dezenas ou centenas de tentativas de acesso não autorizado por minuto. Um firewall estático bloqueia portas, mas não consegue reagir a ataques de força bruta, varreduras ou explorações automatizadas. O fail2ban analisa logs e bloqueia IPs com base em padrões locais, mas não compartilha informações de inteligência entre servidores. O CrowdSec detecta comportamentos maliciosos e distribui reputação de IPs globalmente, mas depende de bouncers para aplicar bloqueios de forma eficiente. Integrados corretamente, eles formam um sistema de defesa que responde em segundos e mantém um registro auditável de tudo o que foi bloqueado.

Ao final desta aula, você terá um servidor com hardening completo ativo: todas as portas não essenciais fechadas no firewall, jails do fail2ban monitorando os principais serviços, CrowdSec analisando logs e aplicando decisões de bloqueio no nível do firewall, e um conjunto de verificações para confirmar que tudo está funcionando de forma coordenada. Você também aprenderá a diagnosticar problemas comuns e a testar cada camada de defesa de maneira controlada, sem colocar o servidor em risco.

O que você vai aprender nesta aula

• Arquitetura de camadas: como firewall, fail2ban e CrowdSec se complementam em um cenário de produção.
• Firewall com nftables: criação de um ruleset completo e comentado, com políticas padrão de drop e regras de entrada, saída e encaminhamento, no Ubuntu/Debian e CentOS/RHEL/Rocky Linux.
• fail2ban em produção: configuração de jails para SSH, serviços web e uso de recidiva, com ajustes de tempo de banimento, número de tentativas e whitelists.
• CrowdSec avançado: instalação, configuração de fontes de logs (acquis), instalação do bouncer de firewall nftables e verificação de decisões.
• Integração e ordenação: entender a ordem de processamento do tráfego e como evitar conflitos entre as ferramentas.
• Verificação completa: comandos para validar cada camada e testar bloqueios de forma segura.
• Solução de erros comuns: diagnóstico e correção dos principais problemas ao integrar as três ferramentas.

Pré-requisitos e Ambiente

Para acompanhar esta aula, você precisa de um servidor com Ubuntu 22.04/24.04 LTS ou Debian 12, e também um servidor com Rocky Linux 9, AlmaLinux 9, CentOS Stream 9 ou RHEL 9 — vamos demonstrar os procedimentos nas duas famílias de sistemas. Os servidores devem ter acesso à internet, estar com o tempo sincronizado via NTP e possuir um usuário com privilégios de root ou sudo. Você deve ter concluído as aulas anteriores do curso, especialmente aquelas sobre nftables, fail2ban e CrowdSec, pois vamos utilizar conceitos já explicados, como jails, parsers, cenários e bouncers.

Recomendamos fortemente que você utilize um servidor de testes ou uma instância isolada, pois vamos aplicar políticas de drop no firewall e banimentos que podem bloquear seu próprio acesso se houver erro de configuração. Em nossos projetos na JRT Technology Solutions, sempre executamos esse procedimento primeiro em ambiente de homologação e depois replicamos para produção com backup de regras e arquivos de configuração. Tenha também um console de acesso alternativo, como o console da nuvem ou IPMI, para recuperação em caso de bloqueio acidental.

Os pré-requisitos técnicos específicos são: pacotes nftables instalados, serviço fail2ban instalado (ou disponível nos repositórios), repositório CrowdSec configurado conforme a Aula 23 e serviços essenciais como SSH e HTTP/HTTPS já em execução. Se você ainda não tem o CrowdSec instalado, não se preocupe: vamos repetir os comandos de instalação de forma completa nesta aula para que o procedimento seja autossuficiente. O único requisito real é ter os repositórios configurados conforme mostraremos a seguir.

Hardening Completo: Fundamentos e Estratégia de Camadas

O conceito de hardening completo que vamos aplicar se baseia em três camadas que atuam em momentos diferentes da análise de tráfego. A primeira camada é o firewall estático, que define uma política de default drop — tudo que não for explicitamente permitido é bloqueado. Isso reduz a superfície de ataque a um conjunto mínimo de portas e protocolos. A segunda camada é o fail2ban, que age de forma reativa analisando arquivos de log de serviços como SSH, Apache ou Nginx, e bloqueando temporariamente IPs que apresentam comportamento abusivo. A terceira camada é o CrowdSec, que analisa múltiplas fontes de log, detecta cenários de ataque mais complexos e aplica bloqueios através do bouncer de firewall, além de compartilhar e consumir reputação de IPs da comunidade.

Essa divisão em camadas não é redundante: cada ferramenta enxerga o tráfego de forma diferente. O firewall enxerga pacotes e portas, o fail2ban enxerga tentativas de autenticação e padrões específicos de log, e o CrowdSec enxerga sequências de eventos e comportamentos distribuídos. Um atacante pode passar pelo firewall porque a porta 22 precisa estar aberta para administração legítima; o fail2ban pode não detectar uma varredura lenta; e o CrowdSec pode bloquear um IP que o fail2ban deixaria passar por estar espalhando tentativas em intervalos longos. Juntos, eles reduzem significativamente a probabilidade de sucesso de ataques automatizados e até de ataques direcionados que tentam explorar janelas temporais de banimento.

Um aspecto crítico do hardening completo é a ordenação correta. O firewall é a base: se uma porta está fechada no nftables, nenhum pacote chegará ao serviço e, portanto, o fail2ban e o CrowdSec nem precisarão agir para aquela porta. Quando o firewall permite o tráfego para um serviço, o fail2ban e o CrowdSec entram em cena analisando logs e aplicando banimentos adicionais. O bouncer do CrowdSec adiciona regras dinâmicas ao nftables, portanto o firewall precisa estar configurado de forma que essas regras dinâmicas sejam processadas na ordem correta. Em geral, as regras dinâmicas de banimento devem ser avaliadas antes das regras de permissão de serviços, para que um IP banido não consiga estabelecer novas conexões.

A tabela a seguir resume as responsabilidades e o momento de atuação de cada camada do hardening completo que vamos implementar:

Em nossos projetos na JRT Technology Solutions, seguimos exatamente essa abordagem: primeiro fechamos a superfície de ataque com o firewall, depois ativamos a automação de banimento com fail2ban e, por fim, integramos o CrowdSec para agregar inteligência externa e compartilhar sinais de ataque entre os servidores dos nossos clientes. Essa sequência reduz o ruído nos logs e facilita a identificação de falsos positivos, pois cada camada filtra uma parte do tráfego malicioso antes que ele alcance a camada seguinte.

Hardening do Firewall com nftables — Camada 1 do Hardening Completo

A primeira etapa do nosso hardening completo é a configuração do firewall base com nftables. Vamos criar um ruleset que segue o princípio de default deny: a política padrão para tráfego de entrada (input) e encaminhamento (forward) será drop, enquanto a saída (output) será accept, pois nosso servidor precisa iniciar conexões de saída para atualizações, consultas DNS e integrações. A partir dessa base, liberamos apenas o necessário: loopback, tráfego já estabelecido ou relacionado, ICMP (ping) de forma controlada e os serviços essenciais como SSH, HTTP e HTTPS.

No Ubuntu/Debian, o pacote nftables geralmente já está instalado como dependência do sistema, mas vamos garantir sua presença. No CentOS/RHEL/Rocky Linux/AlmaLinux, precisaremos instalar o pacote e, em muitos casos, desativar o firewalld, que é o firewall padrão dessas distribuições. O nftables e o firewalld podem coexistir, mas para manter controle total e consistência entre as duas famílias, vamos padronizar no nftables puro. Se você preferir manter o firewalld no CentOS/RHEL, pode adaptar as regras para o formato do firewalld, mas nesta aula trabalharemos com o nftables em ambos os sistemas.

Execute os comandos abaixo no seu servidor. Explicarei cada linha na sequência.

Instalação e preparação no Ubuntu/Debian

# Atualiza a lista de pacotes e instala o nftables
sudo apt update
sudo apt install -y nftables

# Habilita o serviço nftables para iniciar no boot
sudo systemctl enable nftables

# Para a configuração atual, vamos parar o serviço antes de substituir o arquivo
sudo systemctl stop nftables

# Cria um backup do arquivo de configuração padrão, se existir
sudo cp /etc/nftables.conf /etc/nftables.conf.bak 2>/dev/null || echo "Arquivo padrão não existe, prosseguindo"

# Verifica a versão instalada do nftables
sudo nft --version

No Ubuntu, o comando sudo apt install -y nftables instala o framework de filtragem de pacotes e o utilitário de linha de comando. A flag -y evita a confirmação interativa. O sudo systemctl enable nftables cria os links simbólicos necessários para que o serviço seja iniciado automaticamente durante o boot. O sudo systemctl stop nftables garante que não haja regras ativas enquanto editamos o arquivo de configuração. O backup com cp é uma prática essencial em qualquer procedimento de hardening completo: se algo der errado, podemos restaurar o estado anterior rapidamente. O comando final nft --version apenas confirma a instalação e a versão.

A saída esperada para o último comando deve ser semelhante a esta:

nftables v1.0.6 (Old Doc Yak #3)

Instalação e preparação no CentOS/RHEL/Rocky Linux/AlmaLinux

# Atualiza os pacotes e instala o nftables
sudo dnf update -y
sudo dnf install -y nftables

# Desativa e para o firewalld, que é o firewall padrão nessas distribuições
sudo systemctl disable --now firewalld

# Habilita o nftables no boot
sudo systemctl enable nftables

# Para o serviço nftables antes de editar a configuração
sudo systemctl stop nftables

# Cria backup do arquivo de configuração padrão
sudo cp /etc/nftables.conf /etc/nftables.conf.bak 2>/dev/null || echo "Arquivo padrão não existe, prosseguindo"

# Verifica a versão instalada
sudo nft --version

No CentOS/RHEL/Rocky, o dnf install -y nftables instala o mesmo framework, mas o firewalld costuma estar ativo por padrão. O comando systemctl disable --now firewalld faz duas coisas: a flag --now para o serviço imediatamente, e o subcomando disable remove a inicialização automática. Isso é necessário para evitar conflito de regras, pois se ambos estiverem ativos, o firewalld pode sobrescrever as regras do nftables ou vice-versa, dependendo da ordem de inicialização. O restante do procedimento é idêntico ao do Ubuntu/Debian.

A saída esperada do comando de versão no Rocky Linux 9 é semelhante a esta:

nftables v1.0.4 (Lester Gooch #5)

Criando o arquivo de regras completo do nftables

Agora vamos criar o arquivo /etc/nftables.conf com o ruleset completo do nosso hardening completo. Este arquivo será o mesmo em ambas as famílias de distribuições, pois a sintaxe do nftables é padronizada. Leia atentamente cada bloco e os comentários, pois eles explicam o propósito de cada regra. Em nossos projetos na JRT Technology Solutions, mantemos esse arquivo versionado em um repositório Git para facilitar auditoria e replicação entre servidores.

#!/usr/sbin/nft -f

# ------------------------------------------------------------
# Hardening completo — Ruleset nftables para servidor em produção
# Política padrão: DROP para input e forward, ACCEPT para output
# Autor: JRT Technology Solutions — Infraestrutura e Segurança
# ------------------------------------------------------------

# Limpa todas as regras existentes para começar do zero
flush ruleset

# ------------------------------------------------------------
# Definição de variáveis úteis
# ------------------------------------------------------------
define SSH_PORT = 22
define HTTP_PORT = 80
define HTTPS_PORT = 443

# ------------------------------------------------------------
# Tabela principal usando a família inet (IPv4 e IPv6)
# A família inet permite gerenciar IPv4 e IPv6 com as mesmas regras
# ------------------------------------------------------------
table inet filter {

    # --------------------------------------------------------
    # CADEIA INPUT — tráfego que entra no servidor
    # --------------------------------------------------------
    chain input {
        # Política padrão: bloquear tudo que não for explicitamente permitido
        type filter hook input priority filter; policy drop;

        # Tráfego de loopback é sempre permitido — essencial para serviços locais
        iif lo accept comment "Permite loopback"

        # Tráfego de entrada já estabelecido ou relacionado a conexões existentes
        # Isso permite respostas de conexões que o próprio servidor iniciou
        ct state established,related accept comment "Aceita conexões estabelecidas e relacionadas"

        # Tráfego inválido deve ser bloqueado imediatamente para reduzir ruído
        ct state invalid drop comment "Descarta pacotes inválidos"

        # ICMP: permite ping (echo-request) e respostas necessárias, com limite de taxa
        # O objetivo é permitir diagnóstico de rede sem abrir espaço para flooding
        ip protocol icmp icmp type { echo-request } limit rate 5/second accept comment "Permite ping com rate limit"
        ip6 nexthdr icmpv6 icmpv6 type { echo-request } limit rate 5/second accept comment "Permite pingv6 com rate limit"
        ip protocol icmp icmp type { echo-reply, destination-unreachable, time-exceeded } accept comment "Permite respostas ICMP essenciais"
        ip6 nexthdr icmpv6 icmpv6 type { echo-reply, destination-unreachable, time-exceeded, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept comment "Permite ICMPv6 essenciais"

        # Regras de serviços essenciais
        # SSH: porta definida na variável SSH_PORT
        tcp dport $SSH_PORT ct state new accept comment "Permite SSH"

        # HTTP e HTTPS: necessários para servidor web
        tcp dport $HTTP_PORT ct state new accept comment "Permite HTTP"
        tcp dport $HTTPS_PORT ct state new accept comment "Permite HTTPS"

        # Se você precisar de outros serviços, adicione aqui seguindo o mesmo padrão
        # tcp dport 3306 ct state new accept comment "Permite MySQL apenas se necessário"

        # Registro de pacotes que serão descartados — útil para auditoria e debug
        # Limitamos o log para evitar sobrecarga em caso de flooding
        ip protocol udp udp dport 53 limit rate 10/minute log prefix "NFTABLES-DROP-UDP53: " accept
        log prefix "NFTABLES-DROP-INPUT: " limit rate 5/minute drop

        # Regra final implícita pela policy: drop
    }

    # --------------------------------------------------------
    # CADEIA FORWARD — tráfego roteado (não é necessário em servidor comum)
    # --------------------------------------------------------
    chain forward {
        type filter hook forward priority filter; policy drop;

        # Servidor não atua como roteador, então a política drop é suficiente
        # Se precisar de roteamento, adicione regras explícitas aqui
        log prefix "NFTABLES-DROP-FORWARD: " limit rate 5/minute drop
    }

    # --------------------------------------------------------
    # CADEIA OUTPUT — tráfego saindo do servidor
    # --------------------------------------------------------
    chain output {
        type filter hook output priority filter; policy accept;

        # Saída de loopback sempre permitida
        oif lo accept comment "Permite loopback de saída"

        # Tráfego de saída já estabelecido ou relacionado
        ct state established,related accept comment "Aceita saída estabelecida e relacionada"

        # Bloqueia saída inválida (raro, mas por consistência)
        ct state invalid drop comment "Descarta pacotes de saída inválidos"

        # Toda nova conexão de saída é permitida — política padrão já faz isso
        # Mas explicitamos para documentação e possível restrição futura
        ct state new accept comment "Permite novas conexões de saída"
    }
}

Vamos analisar os pontos mais importantes deste arquivo de hardening completo. O comando flush ruleset no início remove todas as regras ativas, garantindo que partimos de um estado limpo. A definição de variáveis com define facilita a manutenção: se você mudar a porta SSH, basta alterar o valor na variável. A tabela inet filter usa a família inet, que processa tanto IPv4 quanto IPv6, eliminando a necessidade de duplicar regras. As cadeias input, forward e output são os três ganchos (hooks) principais do Netfilter para tráfego de entrada, roteamento e saída, respectivamente.

Na cadeia input, a política padrão é policy drop, o que significa que qualquer pacote que não corresponda a nenhuma regra será descartado silenciosamente. A primeira regra iif lo accept permite todo o tráfego de interface de loopback, essencial para comunicação interna entre processos. A regra ct state established,related accept é fundamental: ela permite que as respostas a conexões iniciadas pelo servidor retornem sem precisar de regras específicas. A regra ct state invalid drop descarta pacotes que o kernel não consegue associar a nenhuma conexão conhecida, eliminando uma classe comum de malformações e ataques.

As regras de ICMP têm um papel importante em qualquer hardening completo. Em vez de bloquear todo o ICMP, permitimos apenas os tipos essenciais e aplicamos um rate limit de 5 pacotes por segundo para echo-request (ping). Isso evita que o servidor participe de ataques de reflexão ou sofra inundações de ping. Para IPv6, incluímos os tipos nd-neighbor-solicit e nd-neighbor-advert, que são necessários para o funcionamento do Neighbor Discovery — sem eles, o IPv6 pode falhar silenciosamente. As regras de SSH, HTTP e HTTPS utilizam ct state new para permitir apenas o estabelecimento de novas conexões nessas portas, mantendo a consistência com a política de estados.

Observe que incluímos duas regras de log com limit rate 5/minute antes do drop. A primeira permite tráfego UDP na porta 53 (DNS) com limite de 10 pacotes por minuto e apenas registra em log; a segunda registra e descarta pacotes que chegam ao final da cadeia. Esses registros são úteis para auditoria e para detectar tentativas de acesso a portas fechadas, mas o rate limit impede que um ataque de flooding gere milhões de linhas de log e sobrecarregue o disco. Em nossos projetos na JRT Technology Solutions, enviamos esses logs para um SIEM centralizado para correlação com outros eventos de segurança.

Aplicando e validando o ruleset

Após criar o arquivo, precisamos testá-lo antes de aplicá-lo. O comando nft -c -f /etc/nftables.conf faz um check de sintaxe sem carregar as regras. Em seguida, carregamos com nft -f /etc/nftables.conf e verificamos com nft list ruleset. Se o ruleset estiver correto, salvamos permanentemente habilitando o serviço. Veja a sequência completa:

# Testa a sintaxe do arquivo de regras sem aplicá-lo
sudo nft -c -f /etc/nftables.conf

# Se não houver erros, carrega o ruleset em memória
sudo nft -f /etc/nftables.conf

# Inicia o serviço nftables (no Ubuntu/Debian use systemctl start)
sudo systemctl start nftables

# Verifica se o serviço está ativo e sem erros
sudo systemctl status nftables --no-pager

# Lista o ruleset completo para conferência
sudo nft list ruleset

O comando nft -c -f é uma salvaguarda: a flag -c indica check e a flag -f especifica o arquivo. Ele valida a sintaxe, definições de variáveis, nomes de cadeias e tipos de regras sem modificar o estado atual do firewall. Se houver algum erro, a saída indicará a linha exata. O comando nft -f sem a flag -c carrega as regras atomicamente, substituindo o ruleset atual. Em seguida, iniciamos o serviço nftables para que as regras sejam aplicadas automaticamente no boot a partir do arquivo /etc/nftables.conf.

A saída esperada do nft -c deve ser vazia, indicando sucesso. A saída do systemctl status deve mostrar o serviço como active (exited) ou active (running) dependendo da distribuição. Veja um exemplo de saída esperada no Ubuntu:

● nftables.service - nftables
     Loaded: loaded (/lib/systemd/system/nftables.service; enabled; vendor preset: enabled)
     Active: active (exited) since Mon 2026-09-14 10:15:00 UTC; 5s ago
       Docs: man:nftables(8)
             man:nft(8)
   Main PID: 1234 (code=exited, status=0/SUCCESS)
        CPU: 12ms

Sep 14 10:15:00 server01 systemd[1]: Starting nftables...
Sep 14 10:15:00 server01 systemd[1]: Finished nftables.

Se você receber uma mensagem de erro de sintaxe, revise cuidadosamente o arquivo, especialmente vírgulas, chaves e nomes de cadeias. O nftables é sensível à formatação e a falta de um ponto e vírgula ou chave pode impedir o carregamento. Após a aplicação bem-sucedida, teste o acesso SSH a partir de outro terminal antes de prosseguir — isso garante que você não se bloqueou acidentalmente. Se o SSH continuar funcionando, a camada 1 do hardening completo está ativa e podemos prosseguir para a camada 2.

Configuração do fail2ban — Camada 2 do Hardening Completo

Com o firewall estático ativo e validado, o próximo passo do hardening completo é configurar o fail2ban para reagir automaticamente a tentativas de ataque nos serviços permitidos. O fail2ban monitora arquivos de log, aplica expressões regulares chamadas failregex para detectar falhas de autenticação e executa ações de banimento, geralmente adicionando regras ao firewall. Em nossa configuração, vamos usar a ação nftables para que os banimentos sejam integrados diretamente à camada 1, criando uma cadeia separada no nftables chamada f2b-sshd ou similar, sem interferir nas regras principais.

A instalação do fail2ban é simples em ambas as famílias de distribuições. No Ubuntu/Debian, o pacote está nos repositórios principais. No CentOS/RHEL/Rocky, o pacote também está disponível nos repositórios oficiais ou no EPEL. Vamos executar os comandos de instalação a seguir e, em seguida, criar um arquivo de configuração local personalizado em /etc/fail2ban/jail.local. A escolha do arquivo .local é proposital: ele sobrescreve as definições do arquivo .conf padrão e não é sobrescrito por atualizações do pacote.

Instalação do fail2ban no Ubuntu/Debian

# Atualiza a lista de pacotes e instala o fail2ban
sudo apt update
sudo apt install -y fail2ban

# Habilita o serviço no boot
sudo systemctl enable fail2ban

# (Ainda não iniciamos o serviço — vamos configurar primeiro)

Instalação do fail2ban no CentOS/RHEL/Rocky Linux/AlmaLinux

# Instala o EPEL no Rocky/Alma/CentOS Stream (necessário para o fail2ban em alguns casos)
sudo dnf install -y epel-release

# Instala o fail2ban
sudo dnf install -y fail2ban

# Habilita o serviço no boot
sudo systemctl enable fail2ban

Agora vamos criar o arquivo de configuração completo do fail2ban. Este arquivo define parâmetros globais, ações padrão e jails específicas para SSH e outros serviços. Leia os comentários para entender cada decisão de configuração. Lembre-se de que este é um arquivo de hardening completo: os valores de tempo de banimento e número de tentativas são mais estritos do que o padrão, pois em produção queremos resposta rápida.

# /etc/fail2ban/jail.local
# Hardening completo — fail2ban para produção
# Arquivo local que sobrescreve as configurações padrão de /etc/fail2ban/jail.conf

[DEFAULT]

# Endereços IP que nunca devem ser banidos (whitelist)
# Coloque aqui seu IP fixo de administração, redes internas e IPs de monitoramento
ignoreip = 127.0.0.1/8 ::1

# Tempo de banimento em segundos: 600 segundos = 10 minutos
# Em um hardening completo, valores entre 600 e 3600 são razoáveis
# Para ataques persistentes, a jail de recidiva aumentará esse tempo
bantime = 600

# Janela de tempo em segundos para contabilizar tentativas de falha
# findtime = 300 significa que contamos falhas nos últimos 5 minutos
findtime = 300

# Número máximo de falhas permitidas dentro de findtime antes do banimento
# maxretry = 5 é um bom equilíbrio entre segurança e tolerância a erros de usuários
maxretry = 5

# Ação de banimento: usar nftables com a variável de porta
# A ação nftables cria uma cadeia dinâmica para cada jail
banaction = nftables

# Enable IPv6 support
banaction_allports = nftables[type=allports]

# Caminho para o socket do fail2ban — usado pelo fail2ban-client
socket = /var/run/fail2ban/fail2ban.sock

# Localização do arquivo de PID
pidfile = /var/run/fail2ban/fail2ban.pid

# Arquivo de log do próprio fail2ban
logtarget = /var/log/fail2ban.log

# Nível de log: NOTICE é suficiente para produção; use INFO para diagnóstico
loglevel = NOTICE

# ------------------------------------------------------------
# Jail específica para SSH — a mais crítica
# ------------------------------------------------------------
[sshd]

# Habilita esta jail
enabled = true

# Caminho do arquivo de log do SSH
# No Ubuntu/Debian: /var/log/auth.log
# No CentOS/RHEL/Rocky: /var/log/secure
logpath = %(sshd_log)s

# Porta do serviço SSH — se você usou a variável no nftables, lembre-se de manter consistência
port = 22

# Protocolo TCP
protocol = tcp

# Banco de dados usado para armazenar falhas
# file é simples e sem dependências; para servidores com múltiplas instâncias, use sqlite
dbpurgeage = 86400

# Ação de banimento específica para esta jail
# Usamos a ação padrão 'nftables' definida no [DEFAULT]
# Se quiser bloquear todas as portas para o IP, use nftables[type=allports]
banaction = nftables[type=multiport]

# Número máximo de falhas para esta jail (mais estrito que o padrão)
maxretry = 3

# Tempo de banimento maior para SSH: 1800 segundos = 30 minutos
bantime = 1800

# findtime de 600 segundos = 10 minutos
findtime = 600

# ------------------------------------------------------------
# Jail de recidiva — banimentos progressivos para reincidentes
# ------------------------------------------------------------
[recidive]

# Habilita esta jail
enabled = true

# Caminho do log do próprio fail2ban — a recidiva monitora banimentos anteriores
logpath = /var/log/fail2ban.log

# Banimento padrão de 1 dia para reincidentes
bantime = 86400

# findtime de 1 dia
findtime = 86400

# maxretry = 5 significa que se o IP foi banido 5 vezes no período, será banido por 1 dia
maxretry = 5

# Ação: bloquear todas as portas para o IP reincidente
banaction = nftables[type=allports]

# ------------------------------------------------------------
# Jail para Apache/Nginx — protegendo serviços web
# ------------------------------------------------------------
[nginx-login]

# Habilita esta jail se você tiver Nginx
enabled = false

# Caminho do log de autenticação do Nginx (ajuste conforme sua instalação)
logpath = /var/log/nginx/access.log

# Porta HTTP/HTTPS
port = http,https

# Número de tentativas de login falhas
maxretry = 5

# Tempo de banimento
bantime = 600

# ------------------------------------------------------------
# Jail para o WordPress (se aplicável)
# ------------------------------------------------------------
[wordpress]

# Habilita esta jail
enabled = false

# Filtro específico para tentativas de login no WordPress
filter = wordpress

# Caminho do log de acesso do Apache/Nginx
logpath = /var/log/nginx/access.log

# Portas HTTP/HTTPS
port = http,https

# Número de tentativas
maxretry = 5

# Tempo de banimento
bantime = 600

O arquivo acima define uma política de banimento em dois níveis: a jail sshd bane temporariamente IPs que falham 3 vezes em 10 minutos, com banimento de 30 minutos. A jail recidive monitora o log do próprio fail2ban e bane por 1 dia IPs que foram banidos 5 vezes em 24 horas. Isso cria um sistema de resposta progressiva: ataques insistentes recebem punições cada vez mais longas. A diretiva ignoreip aceita IPs e faixas em notação CIDR; por exemplo, 192.168.0.0/16 isenta toda a rede local.

É importante notar que usamos a ação nftables em vez da antiga iptables. O fail2ban moderno suporta nftables nativamente e cria cadeias dinâmicas dentro da tabela inet filter. Quando um IP é banido, o fail2ban insere uma regra na cadeia correspondente (por exemplo, f2b-sshd) antes das regras de permissão da cadeia input. Dessa forma, o pacote do IP banido será descartado antes de alcançar a regra que permite a porta do serviço. A opção type=multiport na jail sshd bloqueia apenas a porta 22, enquanto a jail recidive usa type=allports para bloquear todo o tráfego do IP reincidente.

Após criar o arquivo, precisamos validar a sintaxe e iniciar