CrowdSec vs Fail2ban em 2026: Proteção Colaborativa contra Força Bruta no Linux
CrowdSec vs Fail2ban em 2026: como escolher entre proteção colaborativa e simplicidade local, com migração passo a passo, bouncer nftables e AppSec WAF.
Em 2026, o CrowdSec substitui o Fail2ban na maioria dos cenários de produção: usa arquitetura desacoplada (um agente que lê logs mais bouncers que aplicam a decisão), oferece blocklist colaborativa consumida por mais de 300 mil instalações e escala muito melhor para frotas de servidores. O Fail2ban continua excelente para hosts únicos, ambientes air-gapped ou quando você precisa de zero dependências externas. Neste guia comparo as duas ferramentas em detalhes, com as configurações que rodo hoje em produção numa fintech que processa transações PIX.
O CrowdSec 1.6.x usa uma arquitetura agente-bouncer que separa detecção de aplicação, permitindo bloquear no nftables, Cloudflare, NGINX ou Traefik com o mesmo agente.
O Fail2ban 1.1.0 (fev/2024) segue sendo a escolha padrão para hosts únicos Debian/Ubuntu e ainda tem o menor consumo de memória (~15 MB contra ~80 MB do CrowdSec).
A blocklist comunitária do CrowdSec adiciona cerca de 1,2 milhão de IPs maliciosos consumidos em tempo real, uma vantagem operacional decisiva contra botnets distribuídas.
Ambos suportam IPv6 nativamente em 2026, integram-se com systemd-journald e podem exportar métricas para o Prometheus.
O CrowdSec inclui o módulo AppSec (WAF baseado em Coraza) e um Console SaaS gratuito para gestão centralizada de múltiplos agentes.
Para migrações graduais, é seguro rodar Fail2ban e CrowdSec em paralelo, desde que os bouncers gravem em chains nftables distintas.
Tabela comparativa CrowdSec vs Fail2ban
Antes de descer para os detalhes de configuração, este resumo agrupa as dimensões que a equipe de plataforma da minha fintech avaliou quando decidimos migrar 340 hosts Debian de Fail2ban para CrowdSec no início de 2025. As colunas refletem a versão estável de cada projeto em agosto de 2026.
O CrowdSec quebra o problema em três peças. O agente lê logs (via journald, arquivos ou syslog), aplica parsers que transformam linhas em eventos estruturados e depois avalia cenários que descrevem padrões de ataque. Quando um cenário dispara, a decisão vai para a Local API (LAPI), um pequeno serviço HTTP embutido. Os bouncers, que são processos separados, consultam a LAPI e aplicam a punição no lugar apropriado: uma regra nftables, um bloco no NGINX ou uma entrada de firewall na Cloudflare.
Essa separação é o motivo central pelo qual recomendo o CrowdSec para frotas. Um agente por servidor detecta localmente, mas as decisões podem ser federadas via cscli para outros nós. Ninguém precisa mais copiar jail.local à mão em vinte máquinas ou reinventar playbooks Ansible só para sincronizar bans. A versão 1.6, lançada em 2024 e ainda mantida na série 1.6.x em 2026, introduziu o AppSec (WAF Coraza embarcado) e melhorou o parser de logs multilinha, detalhes que abordo mais abaixo. A documentação oficial de arquitetura explica o fluxo com diagramas se você quiser se aprofundar.
Blocklist colaborativa: o diferencial operacional
Cada agente CrowdSec conectado ao Console publica de forma anônima os IPs que bloqueou e recebe de volta uma Community Blocklist agregada. Em agosto de 2026 essa lista tem cerca de 1,2 milhão de endereços, atualizada a cada duas horas, cobrindo scanners SSH, exploradores WordPress e nós Tor abusivos. Para hosts em ISPs africanos onde bandwidth é caro (um contexto que conheço bem), isso significa bloquear tráfego malicioso antes que ele consuma sua conexão de saída no rate-limit da aplicação.
O Fail2ban ainda é relevante em 2026?
Sim, absolutamente. O Fail2ban nasceu em 2004 e recebeu a versão 1.1.0 em fevereiro de 2024 (o roadmap para 1.2 está no repositório oficial no GitHub). Ele continua sendo a escolha padrão em três cenários que atendo com frequência:
Hosts únicos ou VPS pessoais: instalar com apt install fail2ban, ajustar o jail.local e ligar o systemd unit resolve 90% dos ataques SSH sem cerimônia. Não vale montar o triplo dessa complexidade só para um servidor.
Ambientes air-gapped ou com compliance restritivo: em bancos que auditamos, a blocklist externa do CrowdSec pode falhar em revisões de PCI-DSS quando o auditor pergunta "de onde vem esse IP na deny-list?". O Fail2ban é 100% local e auditável.
Sistemas embarcados e edge: em routers OpenWrt ou hosts com 512 MB de RAM, os 80 MB do agente CrowdSec são pesados demais. O Fail2ban sobrevive com 15 MB confortavelmente.
Uma configuração mínima de Fail2ban para SSH que ainda uso em bastion hosts imutáveis:
O mode = aggressive ativa filtros para tentativas de user enumeration e falhas de MFA, coisas que o modo padrão ignora. Se você combina isso com as recomendações do nosso guia de hardening SSH com OpenSSH 10, cobre praticamente todo o vetor de força bruta.
Instalação e configuração do CrowdSec no Debian 12
O repositório oficial cobre Debian 11, 12 e 13-testing, além de todas as versões suportadas de Ubuntu, RHEL e derivados. Uso este script na provisão de nós Flatcar Container Linux via cloud-init (adaptado para Debian 12 no exemplo abaixo):
# Adicionar repositório oficial
curl -s https://install.crowdsec.net | sudo sh
# Instalar agente + bouncer nftables
sudo apt update
sudo apt install -y crowdsec crowdsec-firewall-bouncer-nftables
# Verificar estado do serviço
sudo systemctl status crowdsec
sudo cscli metrics
# Instalar coleção base (SSH + Linux + iptables)
sudo cscli collections install crowdsecurity/linux
sudo cscli collections install crowdsecurity/sshd
# Reload para carregar cenários novos
sudo systemctl reload crowdsec
Depois disso, o cscli metrics deve mostrar as fontes de log (acquisitions) sendo consumidas e os parsers aplicados. Se você não ver eventos SSH após alguns minutos, verifique se o agente está lendo o journald com sudo journalctl -u crowdsec -f. Esse é o erro mais comum em Debian minimal, onde o rsyslog não está instalado por padrão.
Conectando ao Console (opcional, mas recomendado)
O Console SaaS oferece um plano gratuito com até 3 instâncias, dashboards de ataques e a Community Blocklist ampliada. Enrolar um agente leva um comando:
# Gerar token de inscrição no app.crowdsec.net e:
sudo cscli console enroll -e context YOUR_ENROLL_TOKEN
sudo systemctl reload crowdsec
# Adicionar a blocklist comunitária
sudo cscli decisions add --scope Country --value NULL # placeholder para forçar sync
sudo cscli hub update
Bouncer nftables e integração com firewall
O bouncer crowdsec-firewall-bouncer-nftables cria uma tabela dedicada chamada crowdsec com um set crowdsec-blacklists populado dinamicamente. Isso evita conflitos com a sua chain principal, o que é importante se você já segue a estrutura recomendada no guia de hardening de firewall Linux com nftables.
Configuração típica em /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml:
A prioridade -10 é intencional: coloca a chain do bouncer antes das suas regras de aceitação. Se você inverter isso, o tráfego HTTP aceito nunca alcança a chain de bloqueio. Esse é, honestamente, o bug número um nas revisões de configuração que faço para outros times.
Cenários, parsers e regras personalizadas
Um dos motivos práticos pelos quais migrei foi a expressividade dos cenários. O Fail2ban usa regex sobre linhas de log. O CrowdSec usa parsers que transformam a linha em um evento estruturado e depois cenários escritos em YAML com uma DSL baseada em expr. Compare:
# Fail2ban filter para múltiplas tentativas de user enumeration
failregex = ^%(__prefix_line)sInvalid user .* from <HOST>
^%(__prefix_line)sConnection closed by invalid user .* <HOST>
^%(__prefix_line)sReceived disconnect from <HOST>
# Cenário CrowdSec equivalente com contexto e sliding window
type: leaky
name: acme/ssh-user-enum
description: "Detecta enumeração de usuários SSH em janela curta"
filter: "evt.Meta.log_type == 'ssh_failed-auth'"
groupby: "evt.Meta.source_ip"
capacity: 5
leakspeed: 10s
distinct: evt.Meta.target_user
blackhole: 5m
labels:
service: ssh
type: bruteforce
remediation: true
O parâmetro distinct conta usuários únicos por IP. Ou seja: você só é banido se tentar mais de 5 usuários diferentes em 50 segundos. Escrever isso em Fail2ban exige um filtro custom com estado, o que basicamente ninguém faz.
Testando cenários antes de produção
O comando cscli explain mostra exatamente como uma linha de log passa pelos parsers e quais cenários disparam. Uso sempre antes de subir uma regra nova:
echo 'Nov 15 03:44:12 host sshd[1234]: Failed password for admin from 203.0.113.42 port 42323 ssh2' \
| sudo cscli explain --type syslog -f -
AppSec: o WAF integrado do CrowdSec
Introduzido oficialmente na versão 1.6 (2024) e maturado em 1.6.x ao longo de 2025, o AppSec é um WAF em processo baseado no motor Coraza (implementação Go do OWASP ModSecurity Core Rule Set). Ele roda como um componente do agente e é consultado por bouncers HTTP (NGINX, Traefik, HAProxy) antes de deixar a requisição chegar na aplicação.
Na prática, você define um appsec-config em YAML apontando para as regras a carregar:
Isso posiciona o CrowdSec como um substituto real de stacks Fail2ban + ModSecurity + naxsi que muita gente ainda mantém à unha. O overhead adicionado é de cerca de 5 ms por requisição em benchmarks que rodei com wrk contra uma app FastAPI típica.
Migração passo a passo de Fail2ban para CrowdSec
A migração que fiz nos 340 hosts seguiu este runbook. Publico com anotações honestas sobre o que quebrou pelo caminho.
Inventário de jails ativos: rode fail2ban-client status em cada host e exporte para CSV. Identifique jails custom que não têm equivalente óbvio nas collections do CrowdSec Hub.
Instalar CrowdSec em paralelo: os dois serviços podem coexistir. Configure o bouncer nftables em uma tabela separada (crowdsec) para evitar colisão com f2b-sshd.
Rodar em modo observação por 7 dias: em /etc/crowdsec/profiles.yaml, comente o decisions para o cenário SSH. Compare cscli alerts list com fail2ban-client status sshd. Discrepâncias grandes indicam parsers mal configurados.
Ativar bans reais no CrowdSec e manter o Fail2ban ativo: por mais uma semana. Isso reduz risco. Se o CrowdSec falhar por algum motivo, o Fail2ban ainda protege.
Desativar Fail2ban: systemctl disable --now fail2ban, e remova regras órfãs com nft delete table inet f2b-*.
Enrolar no Console e ativar a Community Blocklist. Espere um pico temporário de bans (cerca de 200-500 IPs adicionais) nos primeiros dias.
O que quebrou, para ser franco: cenários custom de Fail2ban para autenticação SASL do Postfix não tinham equivalente no Hub. Acabei escrevendo parsers próprios seguindo o guia de criação de parsers, o que levou dois dias por conta da curva de aprendizado da DSL. Vale o investimento se você tem dez ou mais hosts iguais.
Observabilidade: métricas Prometheus e Console
Um alívio real do CrowdSec é que ele expõe métricas Prometheus nativamente em http://127.0.0.1:6060/metrics. Você raspa isso com o Node Exporter da sua stack Grafana e ganha painéis prontos (o projeto publica dashboards oficiais como IDs 15921 e 15922 no grafana.com).
Métricas úteis para alertar:
cs_bucket_overflowed_total por cenário: mede quantas vezes um scenario disparou. Picos indicam campanhas de ataque em curso.
cs_lapi_decisions_ko_total: falhas na API local. Se subir, é bouncer com token errado, quase sempre.
cs_active_decisions: total de IPs atualmente banidos. Útil para dimensionar o set nftables (o padrão comporta 65.536 entradas).
Para o Fail2ban, o exporter da comunidade é o hectorjsmith/fail2ban-prometheus-exporter, mas você precisa instalar e manter separadamente. Este é mais um ponto no qual o CrowdSec ganha em ambientes com Grafana já implantado. Ele complementa nosso guia de detecção de intrusões com Wazuh e Auditd em vez de duplicar responsabilidades.
Quando escolher CrowdSec, Fail2ban ou ambos
Depois de rodar as duas ferramentas por dois anos em produções distintas, minha heurística é essa:
Escolha CrowdSec se: você opera 5 ou mais hosts, quer blocklist colaborativa, precisa de WAF integrado, tem stack Grafana/Prometheus ou administra frotas Kubernetes onde o mesmo agente cobre nós e ingress controllers.
Escolha Fail2ban se: é um VPS único, requisitos de auditoria proíbem consumo de blocklists externas, RAM é escassa (menos de 512 MB) ou você precisa apenas de proteção SSH básica que "funciona no boot".
Use ambos se: está no meio de uma migração longa ou tem hosts legacy que ainda não podem ser tocados. Só garanta que os bouncers operam em tabelas nftables distintas e que os intervalos de maxretry/capacity não competem entre si.
Perguntas Frequentes
O CrowdSec é gratuito para uso comercial?
Sim. O agente CrowdSec é MIT (código aberto) e pode ser usado gratuitamente, inclusive em produção comercial. Somente recursos avançados do Console SaaS (mais de 3 agentes, retenção estendida, blocklists premium) exigem plano pago. A Community Blocklist básica permanece gratuita.
Qual consome mais recursos, CrowdSec ou Fail2ban?
O Fail2ban é mais leve: ~15 MB de RAM contra ~80 MB do CrowdSec em idle. Em CPU o CrowdSec é ligeiramente mais eficiente sob carga (parsers Go compilados vs regex Python), mas para menos de 50 eventos por segundo a diferença é imperceptível. Em hosts com menos de 512 MB de RAM, escolha Fail2ban.
O CrowdSec funciona sem internet?
Sim. O agente e a LAPI operam totalmente offline. A blocklist comunitária e o Console é que exigem conexão de saída HTTPS para api.crowdsec.net. Em ambientes air-gapped, você pode desativar essas features editando online_api_credentials em /etc/crowdsec/config.yaml e usar apenas cenários locais.
Posso migrar meus filtros custom do Fail2ban para o CrowdSec?
Sim, mas exige reescrita: os regex do Fail2ban viram parsers (grok) e a lógica de contagem vira scenarios (YAML com expr). O comando cscli parsers list e cscli scenarios list mostram os disponíveis no Hub. Sempre comece buscando um equivalente antes de escrever do zero.
O CrowdSec substitui um WAF como o ModSecurity?
Desde a versão 1.6, sim, para a maioria dos casos. O módulo AppSec usa o motor Coraza (Go, mesma família do OWASP CRS) e pode substituir ModSecurity + naxsi em stacks NGINX ou Traefik. Para requisitos muito específicos de compliance PCI-DSS, ainda vale manter o ModSecurity com regras auditadas em paralelo.
Como saber se um IP foi banido pelo CrowdSec?
Use cscli decisions list para ver todas as decisões ativas, ou cscli decisions list --ip 203.0.113.42 para filtrar por endereço. Para inspecionar por que um IP foi banido, cscli alerts list --ip 203.0.113.42 mostra o cenário que disparou e o contexto do evento.
Adaeze runs platform security at a Series C fintech in Lagos, where she spent the last three years migrating a sprawling Debian estate to immutable Flatcar nodes on bare-metal Kubernetes. Before that she was a senior SRE at Andela for five years and did a two-year stint at Interswitch hardening PCI-DSS Linux hosts the old-fashioned way - Lynis scans, Bastille, and a lot of shell scripts that probably shouldn't have existed.
She holds OSCP, CKS, and is one of the few people who has actually read the entire CIS Debian 12 benchmark cover to cover. She maintains a public set of OpenSCAP profiles tuned for African ISP environments where bandwidth assumptions matter.
Adaeze writes about the operational side of Linux security: SSH key rotation that actually happens, log shipping that survives a reboot, and incident response runbooks people will read at 3am.
Comparação prática entre Falco e Tetragon: arquitetura eBPF, detecção vs enforcement no kernel, sobrecarga de CPU e quando escolher cada ferramenta para segurança de runtime em Kubernetes em 2026.
Aprenda a montar um ecossistema completo de detecção de intrusões no Linux com Auditd, Osquery e Wazuh. Inclui regras práticas mapeadas ao MITRE ATT&CK, resposta ativa automatizada e integração DevSecOps.
