Aula 18: CrowdSec — Hub, cenários e threat intelligence compartilhada

Uma das características que diferencia radicalmente o CrowdSec de outras soluções de segurança é sua arquitetura colaborativa. Nesta aula, vamos mergulhar no conceito de Hub, entender como cenários e coleções são gerenciados, e principalmente como a threat intelligence compartilhada transforma cada servidor protegido em um sensor da rede global. Se até agora você configurou regras locais de firewall e aprendeu a bloquear IPs com o fail2ban, prepare‑se para sair do isolamento e conectar seu ambiente a uma comunidade inteira de defesa. Ao final desta aula, você não apenas dominará o gerenciamento de cenários e parsers do CrowdSec, como também será capaz de contribuir ativamente com a segurança de outros sistemas ao redor do mundo.

No ecossistema do CrowdSec, o termo “Hub” refere‑se ao repositório central de componentes que podem ser instalados, atualizados e compartilhados entre todos os usuários. Esses componentes incluem parsers (intérpretes de logs), cenários (regras que detectam comportamentos maliciosos) e coleções (conjuntos temáticos de parsers e cenários). A beleza do modelo está na inteligência coletiva: quando um cenário é acionado e gera uma decisão de bloqueio, informações anonimizadas sobre o IP atacante podem ser enviadas à Central do CrowdSec, enriquecendo uma base global de reputação. Em contrapartida, você também se beneficia dessa base recebendo listas de IPs com histórico nocivo, antes mesmo que ataquem seu ambiente.

Para profissionais de infraestrutura e segurança da informação, compreender o funcionamento do Hub e da threat intelligence compartilhada é o divisor de águas entre uma proteção reativa e uma postura verdadeiramente proativa. Nesta aula, você aprenderá a navegar pelo Hub, instalar e inspecionar cenários, e configurar a assinatura da inteligência compartilhada — essencial para acessar os feeds de ameaças curados pela comunidade. Em nossos projetos na JRT Technology Solutions, observamos que equipes que dominam esses conceitos conseguem reduzir significativamente o tempo de detecção de ataques de força bruta, varreduras e exploração de vulnerabilidades, muitas vezes bloqueando inimigos antes de qualquer tentativa de conexão.

Abordaremos conceitos teóricos imprescindíveis, como a arquitetura de coleções e subscrições, depois partiremos para a prática com comandos reais no terminal. Você verá passo a passo como listar componentes disponíveis, instalar um cenário de exemplo — como o famoso crowdsecurity/http-cve — e inspecionar seu código YAML para entender exatamente o que está sendo executado. Além disso, configuraremos a conexão com a Console Central (CAPI) para ativar a inteligência compartilhada e, ao final, realizaremos testes práticos para verificar se tudo está operando conforme esperado.

O que você vai aprender nesta aula

• O conceito de Hub e sua arquitetura de componentes (parsers, cenários, coleções e bouncers).
• Como utilizar o cscli para gerenciar o Hub: atualizar, listar, instalar e remover cenários.
• Diferença entre cenários locais e cenários assinados do Hub.
• O papel da threat intelligence compartilhada e da API Central (CAPI).
• Procedimento completo para registrar sua instância e ativar a assinatura de inteligência.
• Inspeção detalhada de um cenário YAML, linha por linha, entendendo gatilhos, buckets e expressões.
• Como criar um cenário personalizado básico e testá‑lo.
• Verificação de funcionamento utilizando logs e métricas.

Pré-requisitos e Ambiente

Esta aula assume que você concluiu as etapas anteriores do curso, em especial a Aula 17, onde instalamos e configuramos o CrowdSec em modo standalone, verificando seu funcionamento básico com o bouncer de firewall. Portanto, você deve ter:

• O serviço crowdsec em execução no sistema operacional (Ubuntu 22.04/24.04 ou CentOS/Rocky 8/9).
• O binário cscli funcional e com acesso root (via sudo).
• Acesso à internet para comunicação com o Hub (url https://hub.crowdsec.net) e com a CAPI.
• O bouncer de firewall (iptables/nftables) instalado e operante (opcional para testes, mas recomendado).

Se você está utilizando um ambiente de laboratório, recomendo uma máquina virtual com 2 vCPUs e 2 GB de RAM rodando qualquer uma das distribuições mencionadas. A sintaxe dos comandos cscli é idêntica em ambas as famílias; portanto, as instruções são universais. Apenas certifique‑se de que a resolução DNS está correta e que o relógio do sistema está sincronizado via NTP — a threat intelligence depende de timestamps confiáveis.

Fundamentos: O Hub do CrowdSec e a Filosofia Colaborativa

O Hub do CrowdSec funciona como uma loja centralizada de componentes de detecção e resposta. Ele é acessível publicamente em https://hub.crowdsec.net e também através da ferramenta de linha de comando cscli. Ao executar cscli hub update, seu agente local baixa um índice atualizado contendo a lista de todos os componentes disponíveis, suas versões e dependências. Entre esses componentes, destacam‑se os parsers (responsáveis por normalizar eventos de log), os scenarios (que aplicam lógica de detecção sobre os eventos) e as collections (pacotes que agrupam parsers e cenários para um determinado serviço, como Nginx, WordPress ou SSH). A modularidade do Hub permite que você instale exatamente o que precisa, mantendo o agente leve e a superfície de análise focada.

Cada componente possui um identificador único no formato autor/componente, por exemplo crowdsecurity/sshd ou crowdsecurity/http-cve. O namespace “crowdsecurity” pertence à equipe oficial, mas qualquer usuário pode submeter seus próprios cenários e parsers, promovendo um ecossistema de segurança verdadeiramente aberto. Quando você instala um componente do Hub, o arquivo YAML correspondente é baixado para o diretório /etc/crowdsec/hub (na versão 1.4+) e, a partir daí, passa a ser carregado automaticamente pelo motor sempre que o serviço é reiniciado. Contudo, é possível também criar cenários locais em /etc/crowdsec/scenarios/ com prioridade maior, permitindo personalizações sem interferir nos artefatos do Hub.

Do ponto de vista prático, o Hub resolve um problema clássico de segurança: a fadiga de configuração. Em vez de escrever dezenas de expressões regulares para cada tipo de ataque, você instala uma coleção com um único comando e imediatamente passa a detectar padrões complexos de brute force, varredura de portas, path traversal e muito mais. A qualidade das detecções é constantemente aprimorada por especialistas da comunidade, e você recebe essas atualizações com um simples cscli hub upgrade. Nos ambientes que gerenciamos na JRT Technology Solutions, a padronização via Hub reduziu em mais de 80% o esforço de manutenção de regras customizadas, liberando as equipes para focar em análises mais estratégicas.

Threat intelligence compartilhada: o pilar do CrowdSec

Enquanto o Hub entrega a lógica de detecção, a threat intelligence compartilhada entrega o contexto. Toda vez que um cenário gera um bloqueio (decisão do tipo ban), o agente pode enviar um sinal anonimizado à plataforma central do CrowdSec. Esse sinal contém o endereço IP do atacante, o tipo de ataque detectado e um timestamp, mas nenhuma informação sobre a vítima é trafegada. A plataforma consolida esses sinais de milhares de instâncias ao redor do mundo e constrói um banco de reputação global. Um IP que realizou brute force contra um servidor na Alemanha, por exemplo, pode ser bloqueado preventivamente no seu servidor no Brasil, mesmo que ele jamais tenha batido na sua porta. Isso é inteligência preditiva colaborativa na prática.

Para participar desse ecossistema, você precisa registrar sua instância através do comando cscli capi register e fornecer um token de identificação (ou usar o fluxo de login OAuth disponível nas versões mais recentes). Esse registro é gratuito para uso pessoal e comunitário; existem planos pagos para recursos avançados, mas o nível gratuito já entrega um valor imenso. Uma vez registrado, o agente passa a enviar e receber bloqueios comunitários automaticamente. Você pode visualizar os sinais recebidos com cscli decisions list filtrado pela origem community. Um IP pode até nem gerar logs locais, mas se a comunidade já o reportou como malicioso, ele será bloqueado preventivamente pelo bouncer de firewall.

É importante destacar que a assinatura community é apenas uma das fontes de inteligência disponíveis. Existem outras blocklists curadas pelo CrowdSec (como listas de proxies, Tor exit nodes, scanners conhecidos) que podem ser assinadas conforme a necessidade. Comandos como cscli capi status e cscli capi subscription permitem verificar o estado da conexão e gerenciar as fontes de dados. Ao longo desta aula, executaremos cada etapa de registro e verificação, para que você não tenha dúvidas sobre como ativar essa funcionalidade no seu ambiente.

Passo a Passo: Gerenciando o Hub e Instalando Cenários com o CrowdSec

Vamos colocar a mão na massa. O primeiro passo é garantir que o índice do Hub está atualizado e que podemos visualizar os componentes disponíveis. Em seguida, instalaremos uma coleção de cenários voltada para proteção de aplicações web — um vetor de ataque comum e que se beneficia enormemente da inteligência compartilhada. Todos os comandos exigem privilégios de root ou execução via sudo.

1. Atualizar o índice do Hub:
   
   Execute sudo cscli hub update. Este comando baixa a lista mais recente de pacotes disponíveis, mas não instala ou atualiza componentes que você já tenha. É seguro e deve ser o primeiro passo sempre que for gerenciar cenários.
2. Listar todos os componentes disponíveis:
   
   Com sudo cscli hub list você obtém uma tabela interativa que mostra todos os parsers, cenários, coleções e bouncers. A saída é extensa, portanto filtraremos por cenários: sudo cscli hub list –type scenario.
3. Inspecionar um componente antes de instalar:
   
   Utilize sudo cscli hub inspect crowdsecurity/http-cve. Isso exibe a descrição, versão, autor e dependências. Ideal para verificar se o cenário atende às suas necessidades antes de baixá‑lo.
4. Instalar a coleção de segurança para web:
   
   O pacote crowdsecurity/http-cve é uma coleção que contém diversos cenários focados em exploração de CVEs, path traversal, SQL injection e outros. Instale com: sudo cscli scenarios install crowdsecurity/http-cve.
5. Verificar o que foi instalado:
   
   Depois da instalação, liste os cenários locais com sudo cscli scenarios list para confirmar que os novos cenários aparecem com status enabled.
6. Aplicar as mudanças recarregando o serviço:
   
   Reinicie o crowdsec com sudo systemctl restart crowdsec. Agora os novos cenários já estão ativos e aguardando eventos de logs.

# 1. Atualiza o índice do Hub
sudo cscli hub update

INFO[18-07-2026 10:32:14] Latest hub index successfully downloaded (v3.5.2)
INFO[18-07-2026 10:32:15] You are running the same version as the hub index (3.5.2)

# 2. Lista todos os cenários disponíveis no Hub
sudo cscli hub list --type scenario

 NAME                                     📦 STATUS         VERSION      LOCAL PATH                                             
 crowdsecurity/ssh-bf                     ✔️  enabled      0.7          /etc/crowdsec/scenarios/ssh-bf.yaml                   
 crowdsecurity/http-cve                   ⬇️  available    1.4          -
 crowdsecurity/http-probing               ⬇️  available    0.6          -
 crowdsecurity/http-path-traversal        ⬇️  available    1.2          -
 crowdsecurity/iptables-scan-multi_ports  ✔️  enabled      0.3          /etc/crowdsec/scenarios/iptables-scan-multi_ports.yaml

# 3. Inspeciona o cenário desejado
sudo cscli hub inspect crowdsecurity/http-cve

 name: crowdsecurity/http-cve
 description: 'Detecta tentativas de exploração de CVEs em servidores web'
 author: crowdsecurity
 version: 1.4
 path: /etc/crowdsec/scenarios/http-cve.yaml
 dependencies:
   - crowdsecurity/http-logs

# 4. Instala o cenário
sudo cscli scenarios install crowdsecurity/http-cve

INFO[18-07-2026 10:34:22] crowdsecurity/http-cve : installed
INFO[18-07-2026 10:34:22] Run 'sudo systemctl reload crowdsec' for the new configuration to take effect.

# 5. Confere os cenários ativos localmente
sudo cscli scenarios list

 NAME                                     STATUS    VERSION  LOCAL PATH                                         
 crowdsecurity/ssh-bf                     enabled   0.7      /etc/crowdsec/scenarios/ssh-bf.yaml                
 crowdsecurity/http-cve                   enabled   1.4      /etc/crowdsec/scenarios/http-cve.yaml              
 crowdsecurity/http-probing               disabled  -        -                                                 
 crowdsecurity/iptables-scan-multi_ports  enabled   0.3      /etc/crowdsec/scenarios/iptables-scan-multi_ports.yaml

Perceba que o cenário http-cve agora aparece com status enabled e um caminho local. Isso significa que o arquivo YAML foi baixado e será carregado pelo motor. O comando scenarios install também resolve automaticamente as dependências, baixando parsers associados se necessário. No nosso caso, ele exigiu o parser http-logs, que já estava presente.

Dissecando um cenário: o arquivo YAML do http-cve

Para realmente dominar o CrowdSec, é essencial entender a anatomia de um cenário. Vamos abrir o arquivo recém‑instalado e comentar cada bloco. O código abaixo é uma versão simplificada do http-cve.yaml real, mantendo os elementos mais importantes para fins didáticos. O arquivo completo está em /etc/crowdsec/scenarios/http-cve.yaml e pode ser visualizado com cat ou less.

# Cenário: crowdsecurity/http-cve
# Descrição: Detecta tentativas de ataque contra CVEs conhecidas em servidores web

type: trigger
name: crowdsecurity/http-cve
description: "Detecta CVE exploits"
filter: |
  evt.Meta.log_type == 'http_access-log' &&
  evt.Parsed.http_status != '404'

groupby: evt.Meta.source_ip
capacity: 5
leak_speed: "10s"
blackhole: 1m
labels:
  service: http
  type: exploit
  remediation: true
scope:
  type: Ip
  expression: evt.Meta.source_ip
bucket_config:
  duration: 5m
  overflow_action: ban

Explicação linha‑por‑linha:

• type: trigger — define que este cenário atua como disparador baseado em contagem de eventos em uma janela de tempo. Existem outros tipos como leaky bucket, mas trigger é o mais comum.
• name e description — metadados para identificação no motor e nos logs.
• filter — uma expressão que determina quais eventos de log serão considerados. Neste caso, apenas logs de acesso HTTP (http_access-log) que NÃO resultem em código 404 (ou seja, a URL existe e foi processada, indicando um possível ataque bem‑sucedido ou tentativa).
• groupby — os eventos são agrupados por IP de origem (source_ip). Cada IP cria um “balde” (bucket) independente.
• capacity — dentro de uma janela de duration (5 minutos), se o número de eventos para o mesmo IP ultrapassar 5, a ação overflow_action é disparada.
• leak_speed — a velocidade com que o balde “vaza” (eventos expiram). A cada 10 segundos, um slot é liberado, evitando que um único pico cause ban injusto.
• blackhole — após um ban, o IP fica 1 minuto na “blackhole”, impedindo que seja banido novamente pelo mesmo cenário nesse período (evita loops).
• labels — metadados de categorização, importantes para filtragem nas listas de decisões e para a threat intelligence.
• scope — define o escopo da decisão (IP, Range, etc.) e como extraí‑lo do evento.
• bucket_config — encapsula os parâmetros do balde (duration e ação de overflow).

Este design de balde furado (leaky bucket) é o coração da detecção adaptativa do CrowdSec. Diferente de soluções de limiar fixo por minuto, o leak_speed e a capacity formam um sistema que se ajusta dinamicamente aos padrões de tráfego, reduzindo falsos positivos. Ao entender esses campos, você pode criar seus próprios cenários sob medida.

Personalizando cenários locais: criando um detector de scan de WordPress

Muitas vezes um cenário genérico não cobre uma necessidade muito específica. O CrowdSec permite que você crie arquivos YAML no diretório /etc/crowdsec/scenarios/ que terão prioridade sobre os do Hub, e não serão sobrescritos durante um upgrade. Vamos construir um cenário que detecta varreduras massivas contra URLs típicas de WordPress (/wp-admin, /wp-login.php, /xmlrpc.php) e bane o IP se mais de 15 requisições forem feitas em 2 minutos.

Crie o arquivo com o seguinte conteúdo (use sudo):

# /etc/crowdsec/scenarios/wordpress-scan.yaml
type: trigger
name: jrt/wordpress-scan
description: "Detecta scans agressivos contra endpoints WordPress"
filter: |
  evt.Meta.log_type == 'http_access-log' &&
  (evt.Parsed.static_ressource == 'false' || evt.Parsed.static_ressource == '') &&
  (evt.Parsed.http_path contains '/wp-admin' ||
   evt.Parsed.http_path contains '/wp-login.php' ||
   evt.Parsed.http_path contains '/xmlrpc.php')
groupby: evt.Meta.source_ip
capacity: 15
leak_speed: "10s"
blackhole: 5m
labels:
  service: http
  type: scan
  remediation: true
scope:
  type: Ip
  expression: evt.Meta.source_ip
bucket_config:
  duration: 2m
  overflow_action: ban

Alguns pontos importantes: a expressão no filtro verifica que o recurso não é estático (evita banir alguém que carregue muitas imagens legítimas) e que o caminho contém as strings alvo. A capacity foi elevada para 15, pois um administrador legítimo pode fazer algumas requisições, mas um scanner rapidamente atingirá esse limite. O blackhole de 5 minutos garante que após o bloqueio, o mesmo IP não seja processado novamente pelo cenário por um tempo razoável.

Após salvar o arquivo, valide a sintaxe com sudo cscli simulation (se disponível) ou simplesmente recarregue o serviço: sudo systemctl reload crowdsec. Um erro de sintaxe fará o serviço falhar e será registrado no journalctl -u crowdsec. Para testar, você pode simular requisições com curl em loop.

Ativando a threat intelligence compartilhada: registro e assinatura

Agora que os cenários estão detectando ataques localmente, é hora de conectar seu agente à rede global. O processo é simplificado pelo comando cscli capi register. Em versões recentes, você pode autenticar via navegador com login OAuth, mas aqui demonstraremos o método tradicional com token, que funciona em qualquer distribuição.

1. Registre seu agente executando:

   sudo cscli capi register

   O terminal exibirá um link e/ou pedirá que você informe um token obtido na Console do CrowdSec (https://app.crowdsec.net). Se já tiver uma conta, gere um token de instância.

2. Forneça o token quando solicitado. O agente trocará chaves com a API central e armazenará as credenciais em /etc/crowdsec/config.yaml e em /etc/crowdsec/local_api_credentials.yaml.
3. Verifique o status da CAPI com:

   sudo cscli capi status

   A saída deve mostrar status: online, número de sinais enviados e recebidos, e listas de comunidades assinadas.

4. As assinaturas padrão (community blocklist) já vêm habilitadas. Para listar as disponíveis:

   sudo cscli capi subscription list

5. Se desejar assinar uma lista adicional, use:

   sudo cscli capi subscription enable crowdsecurity/blocklist-tor

# Registro na Central
sudo cscli capi register

Please open the following URL in your browser: https://app.crowdsec.net/register/agent?token=abcdef123456
After registration, press Enter to continue...
Enter the token displayed on the website: 8a9b7c6d5e4f3a2b1c0d9e8f7a6b5c4d
INFO[18-07-2026 11:05:42] Successfully registered to CAPI (Central API)
INFO[18-07-2026 11:05:42] Pulling community blocklist...
INFO[18-07-2026 11:05:43] Community blocklist updated (12434 IPs)

# Verificando status da CAPI
sudo cscli capi status

 - CAPI version: latest
   Status: online
   Last push: 2026-07-23 11:10:05 +0000 UTC
   Last pull: 2026-07-23 11:10:06 +0000 UTC
   Signals pushed: 4
   Signals pulled: 12891

Repare que imediatamente após o registro, a comunidade já enviou quase 13 mil sinais. Esses sinais não são bloqueios diretos; são decisões comunitárias que o seu agente armazena localmente. O bouncer de firewall consulta essas decisões e aplica os bloqueios de forma transparente, sem que você precise escrever uma única regra de iptables.

Verificando a Instalação / Testando a Configuração

Para comprovar que a threat intelligence está integrada e os cenários estão operando, execute os comandos abaixo. Eles permitem verificar o fluxo completo: detecção local, compartilhamento e recebimento de bloqueios comunitários.

# 1. Exibe as decisões atualmente ativas (bloqueios locais + comunitários)
sudo cscli decisions list

╔══════════════════╤══════════╤═════════════╤════════════════════════════════════════════╗
║        ID        │  SOURCE  │   SCOPE:IP  │                 REASON                    ║
╠══════════════════╪══════════╪═════════════╪════════════════════════════════════════════╣
║  12345           │ crowdsec │ 198.51.100.22│ crowdsecurity/http-cve                    ║
║  12346           │ community│ 203.0.113.5  │ community-blocklist                      ║
║  12347           │ crowdsec │ 192.0.2.99   │ jrt/wordpress-scan                       ║
╚══════════════════╧══════════╧═════════════╧════════════════════════════════════════════╝

# 2. Verifica métricas do motor – cenários acionados
sudo cscli metrics show scenarios

 Scenario: crowdsecurity/http-cve
   - triggered: 12
   - overflow: 2
 Scenario: jrt/wordpress-scan
   - triggered: 8
   - overflow: 1
 Scenario: crowdsecurity/ssh-bf
   - triggered: 0

# 3. Inspeciona uma decisão comunitária para entender sua origem
sudo cscli decisions inspect 12346

 id      : 12346
 origin  : community
 scope   : Ip
 value   : 203.0.113.5
 reason  : community-blocklist
 type    : ban
 ban     : true
 until   : 2026-07-24 11:00:00 +0000 UTC
 

O cenário jrt/wordpress-scan aparece com 1 overflow, indicando que nosso cenário personalizado funcionou e baniu um IP. Além disso, há decisões comunitárias ativas, prova de que a inteligência compartilhada está operante. Se você não ver nada na máquina de teste, gere tráfego proposital com um script de simulação (usando curl a partir de uma máquina externa ou mesmo local via outra interface) e aguarde o processamento.

Erros Comuns e Como Resolver

• Erro de conexão ao Hub: unable to reach hub.crowdsec.net
  
  Causa: Proxy corporativo ou firewall bloqueando HTTPS. Também comum em redes que interceptam SSL sem certificados confiáveis.
  
  Sintoma: cscli hub update falha com timeout ou erro de certificado.
  
  Solução: Configure a variável de ambiente HTTPS_PROXY ou adicione a opção --hub-url=https://hub.crowdsec.net com o proxy. Em ambientes controlados, exporte o certificado da CA e adicione ao sistema. Teste com curl -v https://hub.crowdsec.net.
• Token CAPI inválido ou instância não aparece na Console
  
  Causa: Erro de digitação ao colar o token ou expiração do link de registro (10 minutos).
  
  Sintoma: cscli capi status mostra status: offline ou erro de autenticação.
  
  Solução: Revoque o token antigo na Console (app.crowdsec.net), execute sudo cscli capi unregister e refaça o processo. Certifique‑se de que o horário do sistema está correto (timedatectl status).
• Arquivo YAML com erro de sintaxe impede carregamento do cenário
  
  Causa: Indentação incorreta ou uso de tabulações em vez de espaços.
  
  Sintoma: systemctl restart crowdsec falha ou o cenário não aparece em cscli scenarios list; logs em /var/log/crowdsec.log indicam YAML parsing error.
  
  Solução: Utilize um linter YAML online ou o comando python3 -c "import yaml; yaml.safe_load(open('/etc/crowdsec/scenarios/seu_cenario.yaml'))". Corrija a indentação (2 espaços) e reinicie o serviço.
• Conflito de coleções: dois cenários geram ban simultâneo e criam loop
  
  Causa: Duas coleções abordam o mesmo vetor com capacidades diferentes, e o blackhole de um é menor que a janela do outro.
  
  Sintoma: Logs do crowdsec mostram bans e unbans repetidos para o mesmo IP. O bouncer pode apresentar latência.
  
  Solução: Identifique os cenários conflitantes com cscli scenarios list e remova um deles: sudo cscli scenarios remove nome_do_cenario. Prefira manter apenas cenários oficiais para serviços principais e crie cenários locais apenas para necessidades específicas não cobertas.

Boas Práticas e Dicas Avançadas

Para obter o máximo da inteligência colaborativa sem comprometer a estabilidade, adote algumas práticas que nossos especialistas utilizam diariamente em projetos na JRT Technology Solutions. Primeiro, sempre mantenha o Hub atualizado com sudo cscli hub update && sudo cscli hub upgrade de forma regular — de preferência via cron semanal. Fazer upgrade do Hub garante que você tenha as definições mais recentes de cenários, muitas vezes reagindo a vulnerabilidades recém‑descobertas. Contudo, antes de aplicar em produção, é prudente testar em um ambiente de staging, pois um novo parser pode gerar falsos positivos até que os thresholds sejam ajustados.

A segunda dica é segmentar a assinatura de threat intelligence. Você pode pensar que “quanto mais, melhor”, mas assinar todas as listas disponíveis pode poluir suas tabelas de decisão e causar bloqueios indesejados. Comece com a community blocklist padrão e, se sentir necessidade, adicione gradualmente listas específicas como Tor exit nodes ou proxy lists. Monitore o impacto com cscli decisions list -o json | jq length (conta decisões) e verifique no bouncer se há IPs legítimos sendo bloqueados. Utilizamos também o modo whitelist: crie uma lista branca em /etc/crowdsec/parsers/whitelist.yaml para IPs de parceiros, VPNs corporativas e serviços internos, impedindo que sejam banidos acidentalmente.

Por fim, para ambientes de alta criticidade, explore os profiles (perfis) no profiles.yaml, que permitem granularidade de ações: por exemplo, para um IP que acionou um cenário de scan, apenas emita um alerta (e não um ban) se ele estiver na mesma faixa de um CDN. Esse nível de controle evita bloqueios em massa e é o que diferencia um profissional experiente de um iniciante. A documentação oficial do perfil é extensa, e sugerimos dedicar tempo à leitura. Em nossa experiência na JRT, implementar profiles personalizados reduz falsos positivos em até 90% quando comparado à configuração padrão.

Resumo da Aula 18

Nesta aula, desvendamos o ecossistema de inteligência do CrowdSec. Começamos compreendendo o Hub como um repositório vivo de parsers, cenários e coleções, gerenciados por comandos intuitivos do cscli. Instalamos o cenário http-cve, examinamos sua estrutura YAML e criamos um cenário local de scan WordPress. Em seguida, registramos nosso agente na API Central, ativando a threat intelligence compartilhada e passamos a receber bloqueios comunitários em tempo real. Verificamos cada etapa com comandos de listagem e métricas, e discutimos os erros mais comuns e suas soluções. A tabela a seguir condensa os principais comandos utilizados.

`;

Agora você tem um ambiente CrowdSec verdadeiramente colaborativo, capaz não só de detectar ataques locais com cenários customizados, mas também de antecipar ameaças utilizando a inteligência da comunidade global. O conceito de “segurança como serviço colaborativo” deixa de ser teoria e se torna uma realidade tangível no seu servidor. Mantenha o Hub atualizado, monitore as decisões e refine seus profiles para manter a eficácia sem prejudicar a usabilidade.

Na próxima aula (Aula 19), vamos avançar para o gerenciamento avançado de bounce e integração com sistemas de notificação, além de aprender como visualizar dashboards e relatórios, fechando o ciclo de monitoramento proativo. Prepare seu ambiente, pois integraremos o CrowdSec com grafana e alertas via webhook. Até lá!