CrowdSec no Ubuntu: firewall colaborativo, passo a passo

O CrowdSec detecta ataques nos logs do próprio servidor, como o Fail2ban, mas some com uma camada que o Fail2ban não tem: uma rede colaborativa com mais de 250 mil sensores ativos em 190 países, que troca 40 milhões de sinais de IPs agressivos por dia. Na prática, isso significa bloquear um IP que atacou outro servidor há uma hora, antes que ele bata no seu. Este guia instala o motor, ativa a detecção de força bruta em SSH e liga o bloqueio automático via nftables.

O que é o CrowdSec e por que ele vai além do Fail2ban

O CrowdSec separa duas funções que o Fail2ban mistura em um processo só: o engine lê os logs, aplica cenários (regras de detecção escritas em YAML) e decide quem deve ser bloqueado; o bouncer é um processo separado que pega essa decisão e aplica no firewall, no nginx, no WordPress ou onde for preciso. Essa separação é o que permite trocar o bloqueio local (nftables) por outro mecanismo sem tocar na detecção.

A parte que o Fail2ban não tem é a rede: cada instalação pode compartilhar os IPs que bloqueou localmente e, em troca, recebe a community blocklist — IPs que já atacaram milhares de outros servidores. Segundo a CrowdSec, metade dos IPs maliciosos dessa base não aparece em 89 de 92 fornecedores de inteligência de ameaças pagos, porque vem de detecção comportamental real, não de honeypots isolados.

Pré-requisitos

• Ubuntu Server 22.04 ou 24.04, com acesso root ou sudo.
• nftables como firewall ativo (o pacote bouncer também aceita iptables, trocando o pacote no passo 3).
• Porta 8080 livre em 127.0.0.1 — é onde a API local do CrowdSec escuta, sem exposição externa.
• Logs padrão do sistema em /var/log/auth.log (Ubuntu já grava aí por padrão).

Passo 1 — Instalar o motor do CrowdSec

O script oficial adiciona o repositório apt da CrowdSec e assina a chave GPG; a instalação em si vem do pacote apt, não do script — assim o pacote recebe atualizações de segurança pelo gerenciador normal do sistema.

curl -s https://install.crowdsec.net | sudo sh
sudo apt update
sudo apt install -y crowdsec

O serviço já sobe sozinho depois da instalação. Confirme:

sudo systemctl status crowdsec --no-pager
cscli version

Passo 2 — Ativar a detecção de força bruta em SSH

O CrowdSec funciona por coleções: pacotes de cenários prontos para um serviço específico. Sem instalar a coleção certa, o engine lê o log mas não sabe o que procurar nele.

sudo cscli collections install crowdsecurity/sshd
sudo cscli collections install crowdsecurity/linux
sudo systemctl reload crowdsec

crowdsecurity/sshd traz os cenários de força bruta e enumeração de usuário via SSH; crowdsecurity/linux cobre parsers genéricos do syslog que os outros cenários dependem. Se o servidor também expõe outro serviço (Nginx, WordPress, Postfix), existe uma coleção dedicada para cada um — liste as disponíveis com cscli collections list.

Passo 3 — Instalar o bouncer para aplicar o bloqueio no nftables

Até aqui o CrowdSec só decide quem é malicioso; nada é bloqueado de fato. Quem aplica a decisão no firewall é o bouncer, e ele roda como pacote separado porque pode ficar até em outra máquina, apontando para o engine pela rede.

sudo apt install -y crowdsec-firewall-bouncer-nftables

No cenário mais comum — engine e bouncer no mesmo servidor —, o pacote se registra sozinho na API local durante a instalação, gera a chave de autenticação e já sobe o serviço. Confirme o registro:

sudo cscli bouncers list

Se precisar apontar o bouncer para um engine remoto, gere a chave manualmente no host do engine com cscli bouncers add <nome> e cole o valor em api_url e api_key no arquivo /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml.

Passo 4 — Testar o bloqueio na prática

Não é preciso esperar um ataque real para validar a instalação. Adicione e remova uma decisão manual:

sudo cscli decisions add --ip 198.51.100.10 --duration 4h --reason "teste manual"
sudo cscli decisions list
sudo nft list ruleset | grep -A2 crowdsec

O IP de teste (198.51.100.10 é reservado para documentação, RFC 5737 — não bloqueia ninguém real) deve aparecer na saída do nft list ruleset dentro do set que o bouncer mantém. Remova o teste depois:

sudo cscli decisions delete --ip 198.51.100.10

Para ver o CrowdSec reagindo a um ataque de verdade, tente autenticar via SSH de outra máquina com senha errada 5 a 6 vezes seguidas — o cenário crowdsecurity/ssh-bf (dentro da coleção sshd) dispara por padrão depois de poucas tentativas em uma janela curta.

Passo 5 — Comandos essenciais no dia a dia

cscli metrics                          # visão geral de cenários disparados e decisões ativas
cscli alerts list                      # histórico de alertas gerados
cscli decisions list                   # IPs bloqueados agora, com origem (local ou community blocklist)
cscli explain --file /var/log/auth.log # simula o parsing de um log e mostra por que (não) bateu num cenário
sudo cscli hub update && sudo cscli hub upgrade  # atualiza cenários e coleções instaladas

Rode o hub update/upgrade com regularidade — os cenários da comunidade mudam conforme surgem técnicas novas de ataque, e uma coleção desatualizada perde eficácia sem dar nenhum aviso.

Boas práticas e limites

Coloque o IP do seu próprio acesso administrativo numa allowlist antes de ligar o bouncer em produção — um teste malfeito ou um cenário sensível demais pode bloquear você mesmo:

sudo cscli allowlists create admins -d "IPs de administração"
sudo cscli allowlists add admins SEU.IP.AQUI/32

O CrowdSec detecta e bloqueia; ele não substitui atualização de pacotes, autenticação por chave SSH em vez de senha, ou segmentação de rede para a interface de gerência. É uma camada a mais, não a única.

Perguntas frequentes

O CrowdSec substitui o Fail2ban?
Funcionalmente sim para o caso de força bruta — cobre o que o Fail2ban faz e adiciona a community blocklist. Não há necessidade de rodar os dois juntos monitorando o mesmo log.

Funciona só com nftables ou também com iptables?
O bouncer tem build para os dois: troque crowdsec-firewall-bouncer-nftables por crowdsec-firewall-bouncer-iptables no passo 3 se o servidor ainda usa iptables legado.

Preciso criar conta na nuvem da CrowdSec para funcionar?
Não. O engine local decide e bloqueia sozinho com as coleções instaladas. A conta no CrowdSec Console é opcional e só adiciona um painel web de monitoramento e a community blocklist completa.

O bouncer pode me bloquear fora do próprio servidor?
Não — o bouncer nftables só atua no firewall da máquina onde está instalado. Ele não manda comandos para outros equipamentos da rede.

Quanto de CPU e RAM o CrowdSec consome?
Em um servidor Ubuntu comum com poucas coleções ativas, o engine roda com uso de memória na casa de dezenas de megabytes — leve o bastante para caber num VPS pequeno junto com os outros serviços.

Conclusão

Com o motor, a coleção sshd e o bouncer nftables no ar, o servidor passa a bloquear automaticamente tanto o que ele mesmo detecta nos logs quanto o que a rede colaborativa já identificou em outros lugares. O próximo passo natural é instalar a coleção do serviço web (Nginx ou o que estiver exposto) e revisar cscli decisions list de vez em quando para confirmar que a allowlist de administração continua liberada.