Aula 23: CrowdSec — threat intelligence colaborativa, bouncers e console centralizado

Bem-vindo à Aula 23 do curso Segurança Linux — Do Zero ao Avançado. Hoje vamos mergulhar em uma das ferramentas mais poderosas e modernas do ecossistema de cibersegurança para Linux: o CrowdSec. Diferente dos tradicionais sistemas de detecção de intrusão como o Fail2ban que vimos em aulas anteriores, o CrowdSec opera com um paradigma fundamentalmente diferente — inteligência de ameaças colaborativa e distribuída. Isso significa que cada servidor rodando CrowdSec não apenas se protege individualmente, mas também contribui e se beneficia de uma rede global de indicadores de comprometimento, criando uma imunidade coletiva contra ataques. Nesta aula, vamos dominar o CrowdSec do zero, entendendo sua arquitetura, instalando o agente principal, configurando bouncers para bloquear ativamente ameaças e explorando o console centralizado de gerenciamento.

O CrowdSec resolve um problema crítico enfrentado por administradores de sistemas e profissionais de segurança: a reatividade isolada. Ferramentas tradicionais bloqueiam IPs apenas com base em eventos locais — ou seja, cada servidor precisa “sofrer” o ataque antes de aprender a se defender. Com o CrowdSec, quando um IP malicioso é detectado em qualquer lugar do mundo por qualquer participante da rede, essa informação é compartilhada (de forma anônima e curada) com todos os outros nós, permitindo bloqueio proativo quase em tempo real. Essa abordagem reduz drasticamente a janela de exposição e a carga operacional das equipes de segurança. Em nossos projetos na JRT Technology Solutions, implementamos CrowdSec em ambientes corporativos com dezenas de servidores Linux, conseguindo reduzir em mais de 80% as tentativas de brute-force bem-sucedidas logo na primeira semana de operação.

Para esta aula, você precisará ter concluído as aulas anteriores do curso, especialmente aquelas sobre fundamentos de firewall (iptables/nftables), gerenciamento de logs e serviços no Linux. Não se preocupe se você não tem conhecimento prévio sobre o CrowdSec — começaremos pela teoria fundamental e avançaremos passo a passo até uma implantação completa e funcional. Ao final desta aula, você terá um servidor Linux protegido pelo CrowdSec com múltiplos bouncers ativos, conectado ao console centralizado, com dashboards de monitoramento e capaz de responder automaticamente a ameaças detectadas globalmente. Você também aprenderá a interpretar decisões, gerenciar coleções de cenários e ajustar a sensibilidade do sistema para seu ambiente específico.

Vamos cobrir instalação em distribuições Ubuntu/Debian e CentOS/RHEL/Rocky Linux, configuração detalhada de cada componente, integração com firewalls existentes, troubleshooting de erros comuns e boas práticas de operação. Prepare-se para uma aula densa, extremamente prática e que vai transformar sua abordagem à segurança de servidores Linux. Abra seu terminal, faça login com privilégios de root ou sudo e vamos começar.

O que você vai aprender nesta aula

• Compreender a arquitetura do CrowdSec: agente principal, bouncers, API local e console centralizado
• Diferenciar o CrowdSec de ferramentas tradicionais como Fail2ban e DenyHosts
• Instalar e configurar o CrowdSec Security Engine em Ubuntu/Debian e CentOS/RHEL/Rocky Linux
• Trabalhar com coleções, cenários e parsers nativos do ecossistema
• Instalar e configurar múltiplos tipos de bouncers (firewall, Nginx, Cloudflare, etc.)
• Conectar sua instância ao Console Centralizado para visibilidade e gestão unificada
• Interpretar decisões, métricas e alertas do sistema
• Resolver os erros mais comuns durante instalação e operação
• Aplicar boas práticas de tuning e operação derivadas de implantações reais realizadas pela JRT Technology Solutions

Pré-requisitos e Ambiente

Antes de iniciar esta aula, certifique-se de atender aos seguintes requisitos. Primeiro, você precisa de um servidor Linux com uma das seguintes distribuições: Ubuntu 20.04 LTS ou superior, Debian 11 ou superior, CentOS 7/8/9, RHEL 7/8/9 ou Rocky Linux 8/9. O servidor deve ter pelo menos 1 GB de RAM disponível e 2 GB de espaço em disco livre — embora o CrowdSec seja leve, os logs e o banco de dados local podem crescer com o tempo. Segundo, você precisa de acesso root ou sudo, pois instalaremos pacotes, modificaremos regras de firewall e criaremos serviços systemd. Terceiro, o servidor deve ter conectividade com a internet para baixar pacotes, atualizar assinaturas e se comunicar com a rede colaborativa do CrowdSec. Quarto, se você estiver utilizando um firewall local (iptables, nftables ou firewalld), ele deve estar operacional, pois um dos bouncers que instalaremos interagirá diretamente com ele.

É altamente recomendado que você tenha concluído a aula sobre Fail2ban (Aula 18) e a aula sobre firewalls com iptables/nftables (Aula 14) do nosso curso. Esses conhecimentos fornecerão a base de comparação e o entendimento de como os bouncers manipulam regras de filtragem de pacotes. Se você estiver migrando de um ambiente com Fail2ban, sugiro desativá-lo temporariamente durante os testes do CrowdSec para evitar conflitos nas regras de firewall — não se preocupe, abordaremos a coexistência e migração gradual ainda nesta aula. Por fim, tenha um terminal SSH aberto e um editor de texto de sua preferência (vim, nano ou similar) pronto para editar arquivos de configuração.

Arquitetura do CrowdSec: Entendendo o Ecossistema

Antes de executarmos qualquer comando, é fundamental compreender a arquitetura do CrowdSec e como seus componentes se interconectam. O CrowdSec é composto por três camadas principais que trabalham em conjunto para detectar, decidir e agir sobre ameaças. A primeira camada é o Security Engine (também chamado de agente ou daemon principal), que é o cérebro da operação. Ele lê logs de diversos serviços (SSH, Apache, Nginx, MySQL, etc.), aplica parsers para extrair informações relevantes (como IP de origem, timestamp, tipo de evento) e executa cenários que detectam comportamentos maliciosos. Quando um cenário é acionado (por exemplo, 5 falhas de autenticação SSH em 30 segundos), o Security Engine toma uma decisão — que pode ser banir o IP por um período determinado ou aplicar uma ação customizada.

A segunda camada são os Bouncers — componentes que executam as decisões tomadas pelo Security Engine. O termo “bouncer” vem da analogia com seguranças de boate: eles são os “porteiros” que efetivamente bloqueiam o acesso. Existem bouncers para diversos propósitos: o firewall bouncer adiciona regras no iptables/nftables para bloquear tráfego de IPs banidos; o Nginx bouncer retorna códigos HTTP 403 para IPs maliciosos; o Cloudflare bouncer integra-se com a API da Cloudflare para bloquear na borda da rede. A comunicação entre o Security Engine e os bouncers ocorre via API local (REST API rodando em localhost na porta 8080 por padrão), garantindo baixa latência e segurança.

A terceira camada é o Console Centralizado (CrowdSec Console), uma plataforma SaaS que agrega dados de múltiplas instâncias. Através do console, você visualiza métricas, alertas, decisões e pode gerenciar remotamente suas instâncias. Além disso, o console é o ponto de entrada para o CrowdSec Threat Intelligence — a rede colaborativa de inteligência de ameaças. Quando você registra sua instância no console, ela passa a receber blocklists curadas globalmente e, opcionalmente, a compartilhar sinais de ataque detectados localmente (de forma anônima, sem expor dados sensíveis). Essa rede é o grande diferencial competitivo do CrowdSec frente a soluções tradicionais.

Visualmente, a arquitetura pode ser resumida no seguinte fluxo: Logs de serviços → Security Engine (parsers + cenários) → Decisões de banimento → API Local → Bouncers (firewall, web server, etc.) → Bloqueio efetivo. Paralelamente, o Security Engine se comunica com a API central do CrowdSec para enviar métricas, receber blocklists globais e sincronizar decisões com o console. Um ponto crucial: mesmo sem conexão com a internet, o Security Engine continua funcionando normalmente com suas regras locais — a inteligência colaborativa é um bônus, não um requisito de funcionamento. Em nossos projetos na JRT Technology Solutions, sempre configuramos a conectividade com o console para ambientes com múltiplos servidores, pois isso proporciona visibilidade unificada e acelera a detecção de ameaças distribuídas.

Instalação do CrowdSec Security Engine no Ubuntu/Debian

Vamos iniciar a parte prática com a instalação do CrowdSec Security Engine em distribuições baseadas em Debian. O processo utiliza o repositório oficial do projeto, que fornece pacotes atualizados e assinados. Execute cada comando na ordem apresentada, observando as saídas esperadas para confirmar que tudo está correto. Abra seu terminal como root ou utilize sudo conforme necessário.

Passo 1: Adicionar o repositório oficial do CrowdSec. Primeiro, baixamos e executamos o script de bootstrap que adiciona a chave GPG e configura o arquivo de sources.list automaticamente. Este script é mantido pela equipe do CrowdSec e garante a integridade dos pacotes.

# Baixar e executar o script de adição do repositório CrowdSec
# Este script detecta automaticamente sua distribuição e versão
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
# Saída esperada: mensagens de detecção de SO e confirmação de que o repositório foi adicionado

Passo 2: Instalar o pacote crowdsec. Após a configuração do repositório, instalamos o Security Engine com o gerenciador de pacotes APT. O pacote inclui o daemon principal, parsers básicos, cenários padrão e a API local.

# Atualizar cache de pacotes e instalar o crowdsec
sudo apt update
sudo apt install crowdsec -y
# Saída esperada: download e instalação do pacote, criação do serviço systemd

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 54 not upgraded.
Need to get 15.2 MB of archives.
After this operation, 78.3 MB of additional disk space will be used.
Get:1 https://packagecloud.io/crowdsec/crowdsec/ubuntu focal/main amd64 crowdsec amd64 1.6.3 [15.2 MB]
...
Setting up crowdsec (1.6.3) ...
Created symlink /etc/systemd/system/multi-user.target.wants/crowdsec.service → /lib/systemd/system/crowdsec.service.
crowdsec service started successfully.

Passo 3: Verificar o status do serviço. O instalador automaticamente inicia e habilita o serviço crowdsec. Vamos confirmar que ele está rodando e sem erros.

# Verificar status do daemon crowdsec
sudo systemctl status crowdsec
# Saída esperada: active (running) com indicação de que está carregado e em execução

● crowdsec.service - Crowdsec - the open-source and participative security solution
     Loaded: loaded (/lib/systemd/system/crowdsec.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2026-07-15 09:23:45 UTC; 15s ago
   Main PID: 12456 (crowdsec)
      Tasks: 12 (limit: 4675)
     Memory: 45.2M
     CGroup: /system.slice/crowdsec.service
             └─12456 /usr/bin/crowdsec -c /etc/crowdsec/config.yaml

Neste ponto, o CrowdSec Security Engine está instalado e em execução, processando logs locais. Por padrão, ele já vem com coleções para SSH, Nginx e Apache habilitadas, então se você tiver algum desses serviços rodando, o agente já começará a analisar seus logs automaticamente. Podemos verificar isso com o comando cscli, a ferramenta de linha de comando para interagir com o CrowdSec.

# Listar coleções instaladas
sudo cscli collections list
# Saída esperada: tabela com nome, status e descrição das coleções carregadas

Instalação do CrowdSec Security Engine no CentOS/RHEL/Rocky Linux

Para distribuições baseadas em Red Hat, o processo é análogo, mas utilizando o gerenciador de pacotes DNF/YUM e o script de repositório correspondente ao RPM. Vamos cobrir cada passo com os comandos específicos para RHEL 8/9 e derivados.

Passo 1: Adicionar o repositório oficial para RPM. O CrowdSec disponibiliza um script específico para distribuições RPM que configura o arquivo .repo em /etc/yum.repos.d/.

# Baixar e executar o script de adição do repositório CrowdSec para RPM
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.rpm.sh | sudo bash
# Saída esperada: mensagens de detecção do RHEL/CentOS/Rocky e confirmação do repositório adicionado

Passo 2: Instalar o pacote crowdsec via DNF. Com o repositório configurado, instalamos o Security Engine.

# Instalar o crowdsec em distribuições RHEL-based
# Para CentOS 7 use 'yum' no lugar de 'dnf'
sudo dnf install crowdsec -y
# Saída esperada: resolução de dependências, download e instalação

Dependencies resolved.
================================================================================
 Package          Architecture    Version              Repository           Size
================================================================================
Installing:
 crowdsec         x86_64          1.6.3-1              crowdsec             15 M

Transaction Summary
================================================================================
Install  1 Package

Total download size: 15 M
Installed size: 78 M
Downloading Packages:
crowdsec-1.6.3-1.x86_64.rpm                     4.2 MB/s |  15 MB     00:03
...
Installed:
  crowdsec-1.6.3-1.x86_64

Complete!

Passo 3: Iniciar, habilitar e verificar o serviço. Diferente do Ubuntu, em algumas versões do CentOS/RHEL o serviço pode não ser iniciado automaticamente após a instalação, então forçamos o start e habilitamos no boot.

# Iniciar o serviço e habilitar inicialização automática
sudo systemctl start crowdsec
sudo systemctl enable crowdsec
sudo systemctl status crowdsec
# Saída esperada: active (running) similar à saída do Ubuntu mostrada anteriormente

Passo 4: Verificar se o firewall local (firewalld) permite a API na porta 8080. O Security Engine escuta na porta 8080 em localhost para comunicação com bouncers. Se você usa firewalld, garanta que a interface loopback não tenha restrições ou adicione uma regra rica. Em geral, o tráfego de loopback já é permitido por padrão, mas vamos verificar.

# Verificar zonas ativas e regras do firewalld
sudo firewall-cmd --list-all
# Se houver restrições, adicionar regra para porta 8080/tcp na loopback (geralmente não necessário)
# A comunicação é toda via localhost, que normalmente não é filtrada pelo firewalld

Com o Security Engine rodando em ambas as famílias de distribuições, o próximo passo é configurar bouncers para transformar as decisões de banimento em bloqueios efetivos de tráfego. Mas antes, vamos explorar a linha de comando cscli para entender o que está acontecendo internamente.

Dominando o cscli: Métricas, Decisões e Coleções

O cscli é a interface de linha de comando do CrowdSec e será sua ferramenta principal para diagnosticar, gerenciar e tunar o sistema. Recomendo executar cada um dos comandos a seguir em seu ambiente para se familiarizar com as saídas. O cscli opera diretamente sobre o banco de dados SQLite do Security Engine (localizado em /var/lib/crowdsec/data/crowdsec.db), consultando e manipulando informações de decisões, métricas e configuração.

Comando 1: Verificar métricas gerais do sistema. Este comando exibe quantos eventos foram processados, quantos cenários foram acionados e quantas decisões estão ativas no momento.

# Exibir métricas agregadas do Security Engine
sudo cscli metrics
# Saída: tabelas com estatísticas de aquisição, parsers, cenários e decisões

INFO[0000] Acquisition Metrics:
+-----------------------------+-----------+------------+
|           SOURCE            | LINES READ| LINES PARSED|
+-----------------------------+-----------+------------+
| /var/log/auth.log           | 3,452     | 3,120      |
| /var/log/nginx/access.log   | 12,890    | 12,456     |
+-----------------------------+-----------+------------+

INFO[0000] Parser Metrics:
+--------------------------------+--------+--------+----------+
|            PARSERS             |  HITS  | PARSED | UNPARSED |
+--------------------------------+--------+--------+----------+
| crowdsecurity/sshd-logs        | 1,845  | 1,845  | 0        |
| crowdsecurity/nginx-logs       | 12,456 | 11,230 | 1,226    |
+--------------------------------+--------+--------+----------+

INFO[0000] Scenario Metrics:
+------------------------------------------+--------+---------+
|                 SCENARIO                 | TRIGGERED| POURED |
+------------------------------------------+--------+---------+
| crowdsecurity/ssh-bf                     | 23      | 5      |
| crowdsecurity/http-probing               | 8       | 2      |
+------------------------------------------+--------+---------+

Comando 2: Listar decisões ativas (IPs banidos). Este é um dos comandos mais importantes do dia a dia operacional. Ele mostra quais IPs estão atualmente banidos, qual o escopo (IP individual ou faixa), a duração restante e o cenário que originou o banimento.

# Listar todas as decisões ativas no momento
sudo cscli decisions list
# Saída: tabela com ID, fonte, IP, escopo, ação, duração restante e motivo

+----+--------+-----------------+---------+------+--------+--------------------+
| ID | SOURCE |       IP        | SCOPE   |ACTION|REMAINING|       REASON       |
+----+--------+-----------------+---------+------+--------+--------------------+
|   1| crowdsec| 203.0.113.42   | Ip      | ban  | 3h45m  | crowdsecurity/ssh-bf|
|   2| crowdsec| 198.51.100.77  | Ip      | ban  | 1h12m  | crowdsecurity/http- |
|    |        |                 |         |      |        | probing             |
|   3| manual | 192.0.2.99     | Ip      | ban  | 23h58m | manual insert      |
+----+--------+-----------------+---------+------+--------+--------------------+

Comando 3: Gerenciar coleções. As coleções são conjuntos de parsers, cenários e configurações agrupados por serviço ou tipo de ataque. O CrowdSec possui um hub online com dezenas de coleções mantidas pela comunidade. Você pode listar as instaladas, buscar novas e instalar diretamente via cscli.

# Listar coleções instaladas localmente
sudo cscli collections list

# Buscar coleções disponíveis no hub relacionadas a um serviço
sudo cscli collections list -a | grep -i wordpress

# Instalar uma coleção do hub (ex: proteção para WordPress)
sudo cscli collections install crowdsecurity/wordpress
# Saída: download e instalação dos parsers e cenários específicos para WordPress

Comando 4: Inspecionar e remover decisões manualmente. Em alguns casos, você precisará banir um IP manualmente (por exemplo, após identificar um ataque em outros sistemas de monitoramento) ou remover um banimento indevido (falso positivo). O cscli oferece comandos diretos para isso.

# Banir um IP manualmente por 24 horas
sudo cscli decisions add --ip 192.0.2.100 --duration 24h --reason "Atividade suspeita detectada manualmente"

# Remover todas as decisões para um IP específico
sudo cscli decisions delete --ip 192.0.2.100

# Remover uma decisão específica pelo ID (obtido via 'cscli decisions list')
sudo cscli decisions delete --id 3

A seguir, uma tabela de referência rápida com os subcomandos mais utilizados do cscli que você deve manter à mão durante a operação diária:

Instalação e Configuração do Firewall Bouncer (iptables/nftables)

Chegou o momento de tornar as decisões do CrowdSec efetivas. O firewall bouncer é o componente mais comum e impactante: ele traduz as decisões de banimento em regras de firewall, bloqueando o tráfego de rede dos IPs maliciosos antes mesmo que eles alcancem os serviços. O bouncer consulta a API local do Security Engine periodicamente (a cada 10 segundos por padrão) e sincroniza um conjunto de regras de firewall — IPs banidos são adicionados, IPs cujo banimento expirou são removidos. Esse mecanismo garante que o firewall esteja sempre atualizado sem intervenção manual.

O firewall bouncer suporta três backends: iptables (legado, amplamente compatível), nftables (moderno, recomendado para kernels 4.x+) e ipset (para otimização com grandes listas de IPs). Vamos instalar utilizando nftables, que é o padrão na maioria das distribuições modernas e oferece melhor performance. Se seu sistema usa iptables legado, adaptaremos os comandos.

Passo 1: Instalar o pacote do firewall bouncer.

# Ubuntu/Debian
sudo apt install crowdsec-firewall-bouncer-nftables -y

# CentOS/RHEL/Rocky Linux
sudo dnf install crowdsec-firewall-bouncer-nftables -y
# Saída esperada: instalação do bouncer e criação do serviço systemd

Passo 2: Configurar o bouncer para usar nftables. O arquivo de configuração principal do firewall bouncer está em /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml. Vamos editá-lo para definir o backend e garantir que a comunicação com a API local esteja correta. Abaixo, o conteúdo completo recomendado para uma configuração funcional e segura:

# /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml
# Configuração completa do Firewall Bouncer com nftables

# URL da API do Security Engine (localhost padrão)
api_url: http://127.0.0.1:8080/

# Chave da API - gerada automaticamente na instalação, NÃO altere
api_key: ${API_KEY}  # Será preenchido automaticamente pelo pacote

# Backend de firewall a ser utilizado: nftables, iptables ou ipset
mode: nftables

# Nome da tabela nftables a ser criada
# O bouncer criará uma tabela dedicada chamada 'crowdsec'
nftables:
  table: crowdsec

# Conjunto de IPs para bloqueio (set nftables)
  set: crowdsec_blocklist

# Cadeia (chain) onde as regras de bloqueio serão inseridas
# 'input' significa que bloqueia tráfego de entrada para este host
  chain: crowdsec_chain

# Hook da chain: 'input' para tráfego entrando no host
  hook: input

# Prioridade da chain no hook (0 = padrão, números menores = maior prioridade)
  priority: -10

# Lista de portas/intervalos que NÃO devem ser bloqueadas (whitelist de portas)
# Útil para garantir que serviços essenciais não sejam afetados por engano
# Exemplo: não bloquear porta 22 (SSH) caso um IP legítimo seja falsamente banido
# Descomente e ajuste conforme necessário:
# deny_mode: drop  # 'drop' descarta silenciosamente, 'reject' envia ICMP/RST
# log_level: info
# log_media: file
# log_dir: /var/log/crowdsec/

Passo 3: Iniciar e habilitar o serviço do bouncer.

# Iniciar o firewall bouncer
sudo systemctl start crowdsec-firewall-bouncer

# Habilitar inicialização automática no boot
sudo systemctl enable crowdsec-firewall-bouncer

# Verificar status
sudo systemctl status crowdsec-firewall-bouncer
# Saída esperada: active (running) com mensagens de sincronização com a API

● crowdsec-firewall-bouncer.service - CrowdSec Firewall Bouncer
     Loaded: loaded (/lib/systemd/system/crowdsec-firewall-bouncer.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2026-07-15 10:05:22 UTC; 8s ago
   Main PID: 14210 (crowdsec-firewa)
      Tasks: 8
     Memory: 12.3M
        CPU: 45ms
     CGroup: /system.slice/crowdsec-firewall-bouncer.service
             └─14210 /usr/bin/crowdsec-firewall-bouncer -c /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml

Jul 15 10:05:22 servidor crowdsec-firewall-bouncer[14210]: Starting crowdsec-firewall-bouncer v0.0.28
Jul 15 10:05:22 servidor crowdsec-firewall-bouncer[14210]: Using nftables backend
Jul 15 10:05:22 servidor crowdsec-firewall-bouncer[14210]: Connected to CrowdSec API at http://127.0.0.1:8080/
Jul 15 10:05:22 servidor crowdsec-firewall-bouncer[14210]: Created nftables table 'crowdsec' with chain and set
Jul 15 10:05:23 servidor crowdsec-firewall-bouncer[14210]: Synced 3 decisions from API to firewall rules

Passo 4: Verificar as regras criadas no nftables. O bouncer deve ter criado uma tabela e regras dedicadas. Vamos inspecionar com o comando nft.

# Listar todas as tabelas nftables
sudo nft list tables
# Deve aparecer 'table inet crowdsec' ou 'table ip crowdsec'

# Listar regras da tabela crowdsec
sudo nft list table inet crowdsec
# Saída esperada: chain com regra de bloqueio baseada no set crowdsec_blocklist

table inet crowdsec {
    set crowdsec_blocklist {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.42, 198.51.100.77, 192.0.2.99 }
    }

    chain crowdsec_chain {
        type filter hook input priority filter -10; policy accept;
        ip saddr @crowdsec_blocklist drop
    }
}

Veja que o set crowdsec_blocklist contém os mesmos IPs que vimos anteriormente na lista de decisões. O bouncer sincronizou perfeitamente. Agora, qualquer tráfego vindo desses IPs será descartado silenciosamente (drop) antes de alcançar qualquer serviço.

Instalação de Bouncers Adicionais: Nginx e Cloudflare

Além do firewall, o CrowdSec oferece bouncers especializados que operam em camadas diferentes da pilha de rede. Dois dos mais utilizados são o Nginx Bouncer e o Cloudflare Bouncer. O Nginx Bouncer é integrado diretamente ao servidor web, retornando respostas HTTP 403 Forbidden para IPs banidos — ideal para cenários onde você não quer (ou não pode) bloquear no nível de firewall, como em ambientes com balanceadores de carga ou proxies reversos. Já o Cloudflare Bouncer utiliza a API da Cloudflare para inserir os IPs banidos em listas de bloqueio no nível da borda, protegendo sua origem mesmo antes do tráfego chegar ao seu datacenter. Nesta seção, instalaremos ambos.

Nginx Bouncer: Requer que o Nginx esteja instalado e com suporte a Lua (OpenResty ou módulo lua-nginx-module). O bouncer funciona como um módulo Lua que consulta a API local do CrowdSec a cada requisição e decide se permite ou bloqueia com base no IP do cliente.

# Instalar o pacote do Nginx Bouncer
# Ubuntu/Debian:
sudo apt install crowdsec-nginx-bouncer -y

# CentOS/RHEL/Rocky (requer repositório EPEL para dependências Lua):
sudo dnf install epel-release -y
sudo dnf install crowdsec-nginx-bouncer -y

# Após instalação, editar a configuração em:
# /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf
# O arquivo contém a API_URL e API_KEY — mantenha os padrões

# Incluir a configuração no bloco server ou location do Nginx:
# Edite /etc/nginx/conf.d/default.conf ou o arquivo do seu site:
# Adicione dentro do bloco server {}:
#   set $crowdsec_apikey "SUA_API_KEY_AQUI";
#   access_by_lua_file /usr/lib/crowdsec/lua/crowdsec.lua;

# Reiniciar Nginx
sudo systemctl restart nginx

Cloudflare Bouncer: Para utilizar este bouncer, você precisará de uma conta Cloudflare com API Token que tenha permissão de editar listas de IPs e regras de firewall. O bouncer sincroniza periodicamente as decisões do CrowdSec com uma lista customizada na Cloudflare, e você configura uma regra WAF para bloquear IPs dessa lista.

# Instalar o Cloudflare Bouncer
# Ubuntu/Debian:
sudo apt install crowdsec-cloudflare-bouncer -y

# CentOS/RHEL/Rocky:
sudo dnf install crowdsec-cloudflare-bouncer -y

# Configurar o Cloudflare Bouncer
# Editar: /etc/crowdsec/bouncers/crowdsec-cloudflare-bouncer.yaml
# Preencher os campos obrigatórios:
#   cf_token: "seu_cloudflare_api_token"
#   cf_zone_id: "id_da_sua_zona_cloudflare"
#   api_url: http://127.0.0.1:8080/
#   api_key: "chave_api_do_security_engine"

# Iniciar e habilitar
sudo systemctl start crowdsec-cloudflare-bouncer
sudo systemctl enable crowdsec-cloudflare-bouncer
sudo systemctl status crowdsec-cloudflare-bouncer

A combinação de múltiplos bouncers — firewall no nível de rede, Nginx no nível de aplicação e Cloudflare na borda global — cria uma defesa em profundidade extremamente robusta. Nossos especialistas utilizam diariamente essa arquitetura nos projetos da JRT Technology Solutions para proteger aplicações web de alto tráfego, garantindo que mesmo que um vetor de ataque passe por uma camada, a próxima o interceptará.

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

Após instalar o Security Engine e pelo menos um bouncer, é crucial realizar verificações sistemáticas para garantir que tudo está funcionando em harmonia. Vamos executar uma série de comandos de diagnóstico que devem produzir saídas específicas, confirmando a integridade da implementação.

Teste 1: Verificar se o Security Engine está processando logs corretamente.

# Verificar métricas de aquisição — deve mostrar arquivos de log sendo lidos
sudo cscli metrics
# Confirme que há linhas lidas e processadas para pelo menos um serviço (SSH, Nginx, etc.)

# Verificar logs do Security Engine para mensagens de erro
sudo journalctl -u crowdsec --no-pager -n 50
# Saída não deve conter erros, apenas mensagens informativas sobre cenários e decisões

Teste 2: Simular um ataque de brute-force SSH para gerar uma decisão. Este é o teste mais importante. A partir de OUTRA máquina (ou simulando localmente), realize múltiplas tentativas falhas de autenticação SSH. Se você não tiver outra máquina disponível, pode usar o netcat ou um script simples de simulação.

# A partir de OUTRA máquina (IP externo ao servidor CrowdSec):
# Execute 6 tentativas SSH com senha incorreta em rápida sucessão
for i in {1..6}; do
  ssh -o StrictHostKeyChecking=no -o ConnectTimeout=2 invaliduser@SEU_SERVIDOR
  # Digite qualquer senha incorreta
done

# Aguarde 30 segundos e verifique as decisões no servidor CrowdSec:
sudo cscli decisions list
# Deve aparecer o IP da máquina que fez as tentativas com status 'ban'
# e reason 'crowdsecurity/ssh-bf' ou similar

Teste 3: Confirmar que o bouncer aplicou o bloqueio.

# Para firewall bouncer com nftables:
sudo nft list set inet crowdsec crowdsec_blocklist
# Deve listar o IP banido no conjunto

# Para Nginx bouncer: tente acessar o site a partir do IP banido
curl -v http://SEU_SERVIDOR/
# Deve retornar HTTP 403 Forbidden

# Para Cloudflare bouncer: verificar no dashboard da Cloudflare a lista de IPs
# ou executar:
sudo journalctl -u crowdsec-cloudflare-bouncer --no-pager -n 20
# Deve mostrar mensagens de sincronização com a Cloudflare

Teste 4: Verificar comunicação com a rede colaborativa (se registrado).

# Verificar status de sincronização com a API central
sudo cscli capi status
# Saída esperada: "You are successfully connected to the Central API"
# ou instruções para registro caso ainda não tenha configurado

Tabela resumo dos comandos de verificação e seus indicadores de sucesso:

Conectando ao Console Centralizado CrowdSec

O CrowdSec Console é a interface web que oferece visibilidade centralizada sobre todas as suas instâncias, dashboards de ameaças, alertas em tempo real e acesso à inteligência colaborativa global. Conectar sua instância é um passo importante para ambientes com mais de um servidor e para quem deseja se beneficiar de blocklists curadas. O processo de registro é gratuito para até 3 instâncias e pode ser feito diretamente pela linha de comando.

Passo 1: Criar uma conta no console. Acesse https://app.crowdsec.net e crie uma conta gratuita. Você receberá um email de confirmação. Após confirmar, faça login e vá até a seção “Engines” para obter o comando de enrollment personalizado — ele conterá um token único que vincula sua instância à sua conta.

Passo 2: Executar o enrollment a partir do servidor. O comando fornecido pelo console será similar a:

# Comando de registro (substitua TOKEN pelo valor real fornecido pelo console)
sudo cscli console enroll TOKEN_AQUI

# Exemplo:
sudo cscli console enroll c1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5
# Saída esperada: mensagem de sucesso e confirmação de que a instância foi registrada

INFO[0000] Enrollment successful.
INFO[0000] Your instance is now registered with the Central API.
INFO[0000] You can view your instance at https://app.crowdsec.net/instances
INFO[0000] Sharing signals with the community is ENABLED by default.
INFO[0000] To disable, run: sudo cscli console disable-sharing

Passo 3: Verificar a conectividade.

# Verificar status da conexão com a API central
sudo cscli capi status
# Deve mostrar "connected" e a URL da API

# Verificar o último pull de blocklist comunitária
sudo cscli capi status
# Inclui informação de quantos itens na blocklist comunitária foram recebidos

Passo 4: Navegar pelo console. Após alguns minutos, acesse novamente https://app.crowdsec.net. Você verá sua instância listada com métricas como número de decisões, cenários ativados, tipo de bouncers conectados e gráficos de atividade. Explore as seções de Alerts (alertas de ataques), Decisions (decisões de banimento) e Blocklists (listas de bloqueio da comunidade que estão sendo aplicadas).

O console também permite gerenciar múltiplas instâncias, criar regras customizadas de alerta e visualizar dashboards consolidados. Em nossos projetos na JRT Technology Solutions, o console centralizado é peça-chave para operações de SOC, permitindo que analistas monitorem dezenas de servidores em uma única tela e respondam rapidamente a incidentes coordenados.

Erros Comuns e Como Resolver

Durante a implementação e operação do CrowdSec, alguns erros são recorrentes — especialmente em ambientes com configurações customizadas de firewall, restrições de rede ou versões específicas de kernel. Nesta seção, catalogamos os erros mais frequentes que encontramos em campo e documentamos a causa, o sintoma e a solução completa para cada um. Ter este guia à mão economizará horas de troubleshooting.

• Erro 1: “failed to create nftables table: operation not supported”
  Sintoma: O firewall bouncer não inicia e o journalctl mostra erro ao criar a tabela nftables. Ocorre principalmente em sistemas com kernel antigo (anterior ao 3.18) ou com módulo nf_tables não carregado.
  Solução: Verifique se o módulo está carregado com lsmod | grep nf_tables. Se não estiver, carregue com sudo modprobe nf_tables. Para kernels realmente antigos, mude o backend para iptables no arquivo de configuração do bouncer (/etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml) alterando mode: nftables para mode: iptables e reinicie o serviço. Considere atualizar o kernel para uma versão mais recente, pois o nftables oferece melhor performance e é o padrão recomendado.
• Erro 2: “connection refused” ao acessar a API do Security Engine na porta 8080
  Sintoma: Bouncers não conseguem sincronizar e nos logs aparece “dial tcp 127.0.0.1:8080: connect: connection refused”.
  Solução: Primeiro, confirme que o Security Engine está rodando com sudo systemctl status crowdsec. Se estiver parado, inicie com sudo systemctl restart crowdsec. Verifique se a porta 8080 está escutando em localhost: sudo ss -tlnp | grep 8080. Se não estiver, edite /etc/crowdsec/config.yaml e verifique se o bloco api está configurado corretamente, especialmente listen_uri: 127.0.0.1:8080. Reinicie o Security Engine após ajustes. Se o problema persistir,