Aula 15: CrowdSec — o que é e como funciona o modelo colaborativo

Se você acompanhou as aulas anteriores deste curso, já domina os conceitos de firewall e implementou regras com iptables, nftables e firewalld, além de ter configurado o fail2ban para bloquear tentativas de força bruta em serviços como SSH, Nginx e Apache. Agora é o momento de dar um salto conceitual e operacional: conhecer o CrowdSec, uma plataforma de segurança de código aberto que transforma a detecção e prevenção de intrusões em um esforço coletivo. Nesta aula, vamos dissecar o CrowdSec — sua arquitetura, componentes, o revolucionário modelo colaborativo de compartilhamento de inteligência de ameaças e, claro, partiremos para a instalação prática em diferentes distribuições Linux. O CrowdSec não é apenas “mais um fail2ban”; é uma evolução que utiliza dados comunitários globalmente distribuídos para bloquear atacantes antes mesmo que eles cheguem ao seu servidor.

A palavra-chave que nos guiará hoje é CrowdSec, e você a verá repetida em contexto natural ao longo de todo o conteúdo. O modelo colaborativo do CrowdSec é o grande diferencial que o separa de soluções tradicionais: enquanto o fail2ban age isoladamente, analisando apenas os logs locais do seu servidor, o CrowdSec permite que cada instância contribua com sinais de ataque para uma rede global. Um IP malicioso detectado em um servidor na Alemanha pode ser bloqueado automaticamente no seu servidor no Brasil em questão de segundos. Em nossos projetos na JRT Technology Solutions, temos implementado o CrowdSec em ambientes críticos e observado reduções superiores a 60% no volume de ataques automatizados já na primeira semana de operação. Esta aula vai fornecer a você a base teórica e prática para entender e começar a operar essa ferramenta.

Ao concluir esta aula, você terá uma compreensão sólida da filosofia por trás do CrowdSec, entenderá cada componente de sua arquitetura — o agente crowdsec, a API Local (LAPI) e os bouncers — e saberá como o fluxo de informações trafega entre eles. Você instalará o CrowdSec do zero em distribuições baseadas em Debian e Red Hat, realizará a configuração inicial, registrará sua instância na comunidade e verificará o funcionamento do motor de detecção. Tudo isso com comandos reais, saídas de terminal documentadas e arquivos de configuração exibidos na íntegra. Não há atalhos: cada etapa será detalhada para que você possa replicar o procedimento em produção com confiança.

É importante destacar que esta aula assume que você já possui um servidor Linux funcional com acesso root ou sudo, conectividade com a internet e conhecimentos básicos de linha de comando — pré-requisitos cobertos nas aulas 1 a 5 do nosso curso. Se você seguiu as aulas anteriores, seu ambiente está perfeitamente preparado. Vamos agora mergulhar no universo do CrowdSec e entender por que esta ferramenta está redefinindo a segurança de infraestrutura em escala global. Nossos especialistas utilizam diariamente o CrowdSec em implementações na JRT Technology Solutions, combinando-o com firewalls e, em alguns casos, com o próprio fail2ban em camadas complementares de defesa.

O que você vai aprender nesta aula

• O contexto histórico e a motivação para a criação do CrowdSec como evolução do fail2ban
• Os três pilares arquiteturais: agente, LAPI (Local API) e bouncers
• O funcionamento detalhado do modelo colaborativo de inteligência de ameaças
• Como o CrowdSec processa logs, toma decisões (cenários) e aplica remediações
• Instalação completa do CrowdSec em Ubuntu/Debian e CentOS/RHEL/Rocky Linux
• Configuração inicial e registro da instância na comunidade CrowdSec
• Verificação do funcionamento do motor de detecção com testes práticos
• Interpretação dos logs e métricas geradas pelo CrowdSec
• Diagnóstico e resolução dos erros mais comuns durante a instalação e operação
• Boas práticas para ambientes produtivos e gancho para integração com bouncers na próxima aula

Pré-requisitos e Ambiente

Antes de iniciarmos a parte prática, verifique se o seu ambiente atende aos seguintes requisitos. Esta aula foi testada e validada nas distribuições listadas abaixo. Todos os comandos devem ser executados com privilégios de superusuário — utilize sudo ou acesse diretamente como root. Certifique-se de que o relógio do sistema está sincronizado via NTP, pois o modelo colaborativo do CrowdSec depende de timestamps precisos para correlacionar eventos. A tabela a seguir resume as versões suportadas e os pacotes que utilizaremos:

Adicionalmente, você precisará de:

• Acesso à internet para download dos pacotes e comunicação com a API central do CrowdSec
• Pelo menos 512 MB de RAM livre e 1 GB de espaço em disco para logs e banco de dados SQLite local
• Um endereço de e-mail válido para registro na comunidade (necessário para o modelo colaborativo)
• Serviços como SSH, Nginx ou Apache em execução — o CrowdSec detectará automaticamente os logs disponíveis

O que é o CrowdSec e por que ele foi criado

O CrowdSec nasceu em 2019, na França, como uma resposta direta às limitações do fail2ban em cenários modernos de ameaças cibernéticas. O fail2ban, que estudamos profundamente nas aulas 11 a 14, é uma ferramenta excelente e madura, mas opera de forma isolada: cada servidor analisa seus próprios logs e toma decisões baseadas exclusivamente em eventos locais. Isso significa que um atacante pode tentar força bruta contra milhares de servidores simultaneamente sem que haja qualquer compartilhamento de inteligência entre eles. O CrowdSec resolve esse problema introduzindo um modelo colaborativo onde cada instância contribui e consome dados de reputação de IPs em escala global. Em essência, o CrowdSec é um IPS/IDS (Sistema de Prevenção e Detecção de Intrusões) moderno, modular e orientado à comunidade.

A filosofia do CrowdSec pode ser resumida em três princípios: detecção local, remediação local e inteligência compartilhada. A detecção é feita pelo agente, que lê arquivos de log e aplica cenários (arquivos YAML que descrevem comportamentos suspeitos). A remediação é executada pelos bouncers, que podem ser firewalls (iptables, nftables, firewalld), proxies reversos (Nginx, Traefik), ou até mesmo integrações com Cloudflare e AWS WAF. A inteligência compartilhada é o cérebro distribuído: quando um IP é detectado como malicioso, um sinal anonimizado é enviado para a API central, que recalcula a reputação global daquele IP e a distribui para todos os participantes. Em nossos projetos na JRT Technology Solutions, já testemunhamos IPs sendo bloqueados em ambientes de clientes antes mesmo de completarem o primeiro scan de portas, graças à reputação negativa acumulada na rede CrowdSec.

Outro diferencial crucial é a arquitetura desacoplada. No fail2ban, o motor de análise e a ação de bloqueio residem no mesmo processo. No CrowdSec, o agente é responsável apenas por ler logs, analisá-los e tomar decisões; os bouncers são processos separados que consultam a LAPI (Local API) para saber quais IPs devem ser bloqueados ou permitidos. Essa separação permite enorme flexibilidade: você pode ter um agente centralizado analisando logs de múltiplos servidores e vários bouncers espalhados pela infraestrutura aplicando as decisões. É uma arquitetura verdadeiramente distribuída e escalável, pronta para ambientes on-premises, cloud-native e híbridos.

O CrowdSec também se destaca pela qualidade e quantidade dos cenários de detecção disponíveis. A comunidade mantém uma coleção oficial (hub) com mais de 100 cenários prontos, cobrindo serviços como SSH, WordPress, Drupal, MySQL, PostgreSQL, Kubernetes, Docker, entre muitos outros. Cada cenário é um arquivo YAML declarativo que define quais padrões de log indicam um ataque, quantas ocorrências configuram um “leak” (vazamento de velocidade), e qual a duração e severidade da decisão. Essa abordagem torna a customização e criação de novos cenários acessível até mesmo para profissionais com conhecimento intermediário de expressões regulares.

Arquitetura do CrowdSec: Agente, LAPI e Bouncers

Compreender a arquitetura do CrowdSec é essencial para operar a ferramenta com eficácia. O ecossistema é composto por três componentes fundamentais, que podem residir na mesma máquina ou em hosts separados. O diagrama conceitual abaixo ilustra o fluxo de informações entre eles, e em seguida detalhamos cada peça do quebra-cabeça.

1. O Agente (crowdsec) — Este é o coração do sistema. O agente é um serviço que roda em background (daemon) e é responsável por ler arquivos de log em tempo real (utilizando tail eficiente), aplicar os cenários de detecção configurados e gerar decisões locais. Quando um cenário detecta comportamento malicioso — por exemplo, 5 tentativas de login SSH falhas em 30 segundos — o agente registra uma decisão local (banir o IP por 4 horas, por padrão). Simultaneamente, um sinal anonimizado é enviado para a API central do CrowdSec contendo informações como o IP atacante, o tipo de ataque detectado e o timestamp. Nenhum dado sensível do seu servidor ou dos seus logs é enviado — apenas metadados do ataque. O agente armazena seu estado local em um banco SQLite localizado em /var/lib/crowdsec/data/crowdsec.db.

2. A LAPI (Local API) — A API Local é o barramento de comunicação entre o agente e os bouncers. Ela expõe endpoints RESTful (por padrão em http://127.0.0.1:8080) que permitem aos bouncers consultar a lista de decisões ativas. Quando um bouncer precisa decidir se um IP deve ser bloqueado, ele consulta a LAPI. A LAPI também gerencia o registro da instância na comunidade, as chaves de API para comunicação com a central e o pull/push de listas de reputação. A comunicação com a central do CrowdSec é criptografada e autenticada por meio de um par de chaves assimétricas geradas durante o registro.

3. Os Bouncers — Bouncers são os executores. Eles atuam como plugins que aplicam as decisões nos pontos de entrada do tráfego. O bouncer mais comum é o de firewall (iptables/nftables), que adiciona regras de bloqueio diretamente no netfilter do kernel. Existem também bouncers para Nginx, Apache, Cloudflare, AWS WAF, pfSense, OPNsense, entre outros. Um bouncer consulta periodicamente a LAPI e mantém uma cache local das decisões. É importante notar que a instalação do agente não inclui automaticamente um bouncer — você precisa instalá-lo separadamente. Essa decisão de design permite que você escolha exatamente como e onde aplicar os bloqueios. Na Aula 16, faremos a instalação e configuração detalhada do bouncer de firewall; hoje focaremos no agente e na LAPI.

A tabela a seguir resume as responsabilidades e localizações padrão de cada componente:

O modelo colaborativo — como funciona na prática

O modelo colaborativo é a alma do CrowdSec. Ele transforma a segurança de um esforço individual para uma defesa comunitária em rede. Quando você instala e registra sua instância, passa a fazer parte de uma rede global com centenas de milhares de participantes. O processo funciona em três estágios bem definidos: envio de sinais, agregação e cálculo de reputação e consumo da blocklist comunitária. Vamos detalhar cada um deles para que não reste nenhuma dúvida sobre o que exatamente é compartilhado e como seus dados permanecem protegidos.

Estágio 1 — Envio de sinais: Quando o agente local detecta um comportamento malicioso com base nos cenários configurados, ele gera o que chamamos de sinal. Um sinal contém exclusivamente: o endereço IP do atacante, o timestamp do evento, o cenário que foi acionado (ex: “crowdsecurity/ssh-bf”) e a duração da decisão local. Nenhum dado do seu servidor — hostname, logs, credenciais, usuários ou serviços internos — é enviado. O sinal é assinado com sua chave privada local e transmitido via HTTPS para a API central do CrowdSec. Essa transmissão ocorre em lote a cada intervalo configurável (padrão: 30 segundos) para minimizar o overhead de rede.

Estágio 2 — Agregação e reputação: Do lado da central, o CrowdSec recebe milhões de sinais diariamente de instâncias em todo o mundo. O motor de reputação analisa a frequência, distribuição geográfica e diversidade de cenários acionados para aquele IP. Um IP que gerou 5 sinais de SSH em 10 países diferentes nas últimas 24 horas terá uma reputação muito pior do que um IP que gerou apenas 2 sinais de um único país. A central calcula um score de reputação que varia de 0 (confiável) a 100 (extremamente malicioso) e compila listas de bloqueio comunitárias. Existem listas específicas para diferentes tipos de ataques: SSH brute-force, DDoS, scans de portas, exploração web, etc. Os usuários podem optar por subscrever a todas ou apenas a categorias relevantes para seu ambiente.

Estágio 3 — Consumo da blocklist: Periodicamente (por padrão a cada 2 horas), seu agente local consulta a API central e baixa a blocklist comunitária atualizada. Os IPs presentes nessa lista são automaticamente promovidos a decisões locais com duração renovável. Isso significa que, se um IP aparecer na blocklist comunitária, ele será banido no seu servidor mesmo que nunca tenha interagido diretamente com ele — um conceito de “bloqueio preventivo” baseado em inteligência coletiva. Esse é o verdadeiro poder do modelo colaborativo: você se beneficia da visibilidade de toda a rede antes mesmo de ser atacado. Em nossos projetos na JRT Technology Solutions, vemos consistentemente que cerca de 30% a 40% dos IPs bloqueados vêm da blocklist comunitária, ou seja, são ameaças que nunca tocaram os servidores dos nossos clientes, mas foram neutralizadas preventivamente.

É crucial tranquilizar os leitores quanto à privacidade. O CrowdSec foi projetado sob uma filosofia de “zero dados sensíveis”. A empresa mantém uma política transparente de quais dados são coletados, e todo o processamento de logs ocorre exclusivamente no seu servidor. O modelo de negócio da CrowdSec é baseado em ofertas enterprise (CrowdSec Console, suporte premium, bouncers avançados), não na monetização de dados. A versão community que utilizamos é completamente gratuita, open source (licença MIT) e funcionalmente completa para a maioria dos casos de uso.

Instalação do CrowdSec no Ubuntu/Debian

Iniciaremos a prática com a instalação do CrowdSec em sistemas baseados em Debian. O processo é extremamente simplificado graças ao repositório oficial mantido pela equipe do projeto. Vamos adicionar a fonte de pacotes, instalar o agente e realizar a configuração inicial. Todos os comandos a seguir devem ser executados como root ou com sudo. Recomendo fortemente abrir uma sessão de terminal separada para acompanhar cada etapa e verificar as saídas.

Passo 1 — Adicionar o repositório oficial e a chave GPG:

# Baixar e instalar a chave GPG oficial do CrowdSec para validação de pacotes
curl -fsSL https://packagecloud.io/crowdsec/crowdsec/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/crowdsec-archive-keyring.gpg

# Adicionar o repositório ao sources.list do apt
echo "deb [signed-by=/usr/share/keyrings/crowdsec-archive-keyring.gpg] https://packagecloud.io/crowdsec/crowdsec/debian/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/crowdsec.list > /dev/null

# Atualizar o cache de pacotes
sudo apt update

Explicação linha por linha: o primeiro comando utiliza curl com a flag -fsSL (-f falha silenciosamente em erros HTTP, -s modo silencioso, -S mostra erros se ocorrerem, -L segue redirecionamentos) para baixar a chave GPG e a converte para o formato binário utilizado pelo apt com gpg –dearmor, armazenando em /usr/share/keyrings/. O segundo comando cria o arquivo de lista de repositórios /etc/apt/sources.list.d/crowdsec.list, utilizando o comando lsb_release -cs para detectar automaticamente o codinome da distribuição (focal, jammy, noble, bullseye, bookworm). O redirecionamento > /dev/null suprime a saída do tee para manter o terminal limpo. Por fim, apt update recarrega as listas de pacotes incluindo o novo repositório.

Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease
Hit:2 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
Hit:3 http://archive.ubuntu.com/ubuntu jammy-security InRelease
Get:4 https://packagecloud.io/crowdsec/crowdsec/debian jammy InRelease [24.5 kB]
Get:5 https://packagecloud.io/crowdsec/crowdsec/debian jammy/main amd64 Packages [8.123 kB]
Fetched 8.147 kB in 2s (4.073 kB/s)
Reading package lists... Done

# Instalar o agente CrowdSec (inclui a LAPI)
sudo apt install crowdsec -y

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  crowdsec
0 upgraded, 1 newly installed, 0 to remove and 15 not upgraded.
Need to get 64.2 MB of archives.
After this operation, 163 MB of additional disk space will be used.
Get:1 https://packagecloud.io/crowdsec/crowdsec/debian jammy/main amd64 crowdsec amd64 1.6.3 [64.2 MB]
...
Setting up crowdsec (1.6.3) ...
Detected services: sshd, nginx
Enabled collections: crowdsecurity/sshd, crowdsecurity/nginx
crowdsec.service - Crowdsec agent is now running
Done.

# Verificar se o serviço está ativo e rodando
sudo systemctl status crowdsec --no-pager

# Habilitar o serviço para iniciar automaticamente no boot
sudo systemctl enable crowdsec

● crowdsec.service - CrowdSec
     Loaded: loaded (/lib/systemd/system/crowdsec.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2026-06-28 14:32:15 UTC; 45s ago
   Main PID: 12345 (crowdsec)
      Tasks: 12 (limit: 38244)
     Memory: 48.2M
        CPU: 2.345s
     CGroup: /system.slice/crowdsec.service
             └─12345 /usr/bin/crowdsec

# Criar o arquivo de repositório para o CrowdSec
sudo tee /etc/yum.repos.d/crowdsec.repo > /dev/null << 'EOF'
[crowdsec]
name=CrowdSec Repository
baseurl=https://packagecloud.io/crowdsec/crowdsec/el/$releasever/$basearch
gpgcheck=1
gpgkey=https://packagecloud.io/crowdsec/crowdsec/gpgkey
enabled=1
EOF

# Em CentOS 7 / RHEL 7, substitua $releasever por 7 manualmente se necessário
# Atualizar o cache de pacotes
sudo dnf makecache

CrowdSec Repository                         16 kB/s | 3.0 kB     00:00    
Metadata cache created.

# Instalar o agente CrowdSec
sudo dnf install crowdsec -y

# Iniciar o serviço
sudo systemctl start crowdsec

# Habilitar no boot
sudo systemctl enable crowdsec

# Verificar status
sudo systemctl status crowdsec --no-pager

# Registrar a instância na comunidade CrowdSec
# Substitua SEU_EMAIL pelo seu endereço de e-mail real
sudo crowdsec -c /etc/crowdsec/config.yaml -api register -u SEU_EMAIL

INFO[28-06-2026 14:45:02] Starting CrowdSec registration              
INFO[28-06-2026 14:45:03] Successfully registered to the CrowdSec API   
INFO[28-06-2026 14:45:03] Machine ID: 01J8XK5R9M2P3Q7V4W6Y8Z0A1B     
INFO[28-06-2026 14:45:03] Run 'sudo systemctl reload crowdsec' to apply changes

# Recarregar a configuração do agente para aplicar o registro
sudo systemctl reload crowdsec

# Verificar se a comunicação com a central está funcionando
sudo cscli capi status

INFO[28-06-2026 14:46:10] CAPI connection is OK                       
INFO[28-06-2026 14:46:10] Your instance is enrolled                  
INFO[28-06-2026 14:46:10] Last pull: 2026-06-28T14:46:00Z            
INFO[28-06-2026 14:46:10] Last push: 2026-06-28T14:46:00Z

/etc/crowdsec/
├── config.yaml                     # Arquivo principal de configuração do agente e LAPI
├── local_api_credentials.yaml      # Chaves e ID da máquina (gerado no registro)
├── acquis.yaml                     # Definição das fontes de log a serem monitoradas
├── profiles.yaml                   # Perfis: mapeiam cenários para decisões e ações
├── scenarios/                      # Diretório de cenários de detecção (.yaml)
│   ├── ssh-bf.yaml                 # Cenário de brute-force SSH
│   └── ...
├── parsers/                        # Parsers para extrair campos de logs
│   ├── s01-parse/
│   └── s02-enrich/
├── postoverflows/                   # Pós-processamento de eventos
│   └── s01-whitelist/
├── hub/                            # Cache do hub: coleções baixadas
├── bouncers/                       # Configurações de bouncers (quando instalados)
│   └── crowdsec-firewall-bouncer.yaml
└── notifications/                  # Configurações de notificações (plugins)
    └── http.yaml

/var/lib/crowdsec/
└── data/
    └── crowdsec.db                 # Banco SQLite com decisões, métricas e estado

/var/log/crowdsec/
└── crowdsec.log                    # Log do próprio agente (debug, info, error)

/usr/bin/
├── crowdsec                        # Binário principal do agente
└── cscli                           # CLI para administração e troubleshooting

# /etc/crowdsec/acquis.yaml — Fontes de log monitoradas pelo CrowdSec
# Gerado automaticamente durante a instalação. Edite com cuidado.

# Fonte: logs de SSH (Debian/Ubuntu e derivados)
---
source: journalctl
journalctl_filter:
  - "_SYSTEMD_UNIT=ssh.service"
labels:
  type: syslog

# Fonte: logs de SSH alternativo (arquivo auth.log)
---
source: file
filenames:
  - /var/log/auth.log
labels:
  type: syslog

# Fonte: logs de acesso do Nginx
---
source: file
filenames:
  - /var/log/nginx/access.log
labels:
  type: nginx

# Fonte: logs de erro do Nginx
---
source: file
filenames:
  - /var/log/nginx/error.log
labels:
  type: nginx-error

# Exibir todas as coleções do hub atualmente instaladas
sudo cscli collections list

# Exibir cenários carregados e prontos para detecção
sudo cscli scenarios list

INFO[28-06-2026 15:00:00] Collections:
────────────────────────────────────────────────────────────
 NAME                          STATUS    VERSION  LOCAL PATH
 crowdsecurity/linux           ✔️  enabled  0.2      /etc/crowdsec/hub/collections/linux
 crowdsecurity/sshd            ✔️  enabled  0.5      /etc/crowdsec/hub/collections/sshd
 crowdsecurity/nginx           ✔️  enabled  0.10     /etc/crowdsec/hub/collections/nginx
────────────────────────────────────────────────────────────

INFO[28-06-2026 15:00:01] Scenarios:
────────────────────────────────────────────────────────────
 NAME                          STATUS    VERSION  LOCAL PATH
 crowdsecurity/ssh-bf          ✔️  enabled  0.6      /etc/crowdsec/hub/scenarios/ssh-bf.yaml
 crowdsecurity/ssh-slow-bf     ✔️  enabled  0.4      /etc/crowdsec/hub/scenarios/ssh-slow-bf.yaml
 crowdsecurity/http-probing    ✔️  enabled  0.3      /etc/crowdsec/hub/scenarios/http-probing.yaml
────────────────────────────────────────────────────────────

# Exibir métricas de funcionamento do agente
sudo cscli metrics

INFO[28-06-2026 15:02:00] Acquisition Metrics:
────────────────────────────────────────────────────────────
 Source                            Lines Read    Lines Parsed    
 /var/log/auth.log                 125.482       125.480
 /var/log/nginx/access.log         89.234        89.230
 journalctl (ssh.service)          12.345        12.340
────────────────────────────────────────────────────────────

INFO[28-06-2026 15:02:00] Parser Metrics:
────────────────────────────────────────────────────────────
 Parser                            Hits           Success         
 crowdsecurity/syslog-logs         227.061        227.061
 crowdsecurity/sshd-logs           12.345         12.340
 crowdsecurity/nginx-logs          89.234         89.230
────────────────────────────────────────────────────────────

INFO[28-06-2026 15:02:00] Decision Metrics:
  - Local decisions:  3
  - Community decisions:  847
  - Total active bans:  850

# Listar todos os IPs atualmente banidos, com duração e motivo
sudo cscli decisions list

INFO[28-06-2026 15:03:00] Decisions:
──────────────────────────────────────────────────────────────────────────
 ID        SOURCE       IP              REASON                      EXPIRES
 12345     cscli        203.0.113.45    crowdsecurity/ssh-bf        3h59m
 12346     CAPI         198.51.100.23   crowdsec/community-block    1h58m
 12347     CAPI         192.0.2.78      crowdsec/community-block    53m
──────────────────────────────────────────────────────────────────────────

# Forçar um pull manual da blocklist comunitária
sudo cscli capi pull

# Ver o status detalhado da inscrição
sudo cscli capi status -a

INFO[28-06-2026 15:04:00] Pulling community blocklist from CAPI...  
INFO[28-06-2026 15:04:01] Pull completed: 847 IPs received          
INFO[28-06-2026 15:04:01] Blocklist updated successfully