Aula 16: CrowdSec — instalação e configuração inicial

Chegamos a um dos pontos mais aguardados do nosso curso: a instalação e configuração inicial do CrowdSec. Depois de compreender profundamente o fail2ban e as limitações inerentes a soluções baseadas exclusivamente em regras estáticas e análise local, é hora de dar o salto para uma plataforma moderna, colaborativa e orientada a inteligência de ameaças. O CrowdSec não é apenas um substituto do fail2ban — ele é um ecossistema completo de detecção de intrusões que transforma cada servidor participante em um sensor e, ao mesmo tempo, em um ponto de defesa alimentado por dados globais de ataque. Nesta aula, vamos tirar a teoria do papel e colocar o motor para funcionar. Você vai instalar o CrowdSec em ambientes reais, configurar os componentes essenciais, entender a arquitetura de diretórios e arquivos de configuração, e verificar que tudo está operando como esperado. Esta é, sem dúvida, a base sobre a qual todas as aulas avançadas do módulo CrowdSec serão construídas — pular etapas aqui compromete todo o restante da sua capacitação.

A importância dessa instalação inicial correta não pode ser subestimada. Em nossos projetos na JRT Technology Solutions, encontramos frequentemente implementações que falham justamente porque a fase de configuração inicial foi negligenciada ou executada sem o devido rigor. Um agente mal configurado pode consumir recursos excessivos, deixar de detectar ataques reais ou, pior, bloquear tráfego legítimo — gerando incidentes de disponibilidade que poderiam ter sido evitados com atenção aos detalhes que vamos explorar aqui. O CrowdSec possui uma curva de aprendizado inicial mais íngreme que o fail2ban, mas essa complexidade adicional se traduz em uma capacidade de detecção infinitamente superior. Ao final desta aula, você terá um agente CrowdSec funcional, um bouncer de firewall ativo e será capaz de verificar o fluxo completo de detecção e mitigação.

O que torna esta aula particularmente especial é a sua natureza prática e universal. Vamos abordar a instalação em pelo menos duas famílias de distribuições Linux — Debian/Ubuntu e RHEL/CentOS/Rocky Linux — garantindo que você possa replicar o conhecimento independentemente do ambiente em que atua. Utilizaremos o repositório oficial do CrowdSec, o que garante acesso às versões mais recentes e estáveis da ferramenta. Além disso, vamos configurar o componente de bouncer de firewall (o equivalente funcional ao que o fail2ban faz ao inserir regras no iptables), fechando o ciclo de detecção e bloqueio. Cada comando será exibido por completo, com a saída esperada documentada, para que você não precise adivinhar se o que vê no seu terminal está correto ou não.

Ao final desta aula, você terá em mãos um sistema capaz de detectar ataques de força bruta contra SSH, varreduras de portas, tentativas de exploração de aplicações web e muito mais, tudo baseado na análise comportamental de logs e enriquecido com inteligência de ameaças global. A partir da próxima aula, começaremos a mergulhar nas collections, scenarios e parsers que tornam o CrowdSec tão poderoso. Mas, por enquanto, o foco é total na fundação. Prepare seu terminal, sua xícara de café e vamos iniciar a jornada prática com o CrowdSec.

O que você vai aprender nesta aula

Compreender a arquitetura de componentes do CrowdSec e como eles se comunicam
Adicionar o repositório oficial do CrowdSec e instalar o agente em Ubuntu/Debian e RHEL/CentOS/Rocky Linux
Realizar a configuração inicial do arquivo /etc/crowdsec/config.yaml com parâmetros customizados para seu ambiente
Instalar e configurar o bouncer de firewall (crowdsec-firewall-bouncer) para bloqueio ativo de ameaças
Verificar o funcionamento correto da engine através do comando cscli
Simular um cenário de ataque e confirmar que o bloqueio ocorre conforme esperado
Identificar e corrigir os erros mais comuns que surgem durante a instalação inicial do CrowdSec

Pré-requisitos e Ambiente

Antes de iniciar a instalação do CrowdSec, algumas condições precisam ser satisfeitas. A primeira delas é ter uma máquina Linux com uma das distribuições suportadas. Para esta aula, testamos e validamos os procedimentos em Ubuntu Server 22.04 LTS, Debian 12 (Bookworm), CentOS Stream 9 e Rocky Linux 9. A ferramenta também funciona perfeitamente em versões anteriores, desde que possuam suporte a systemd e acesso aos repositórios oficiais. O segundo pré-requisito essencial é que o serviço de logs que você deseja monitorar esteja em funcionamento e configurado para gerar logs em arquivos de texto — por exemplo, o sshd escrevendo em /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL/Rocky). Sem logs, o CrowdSec não tem matéria-prima para análise.

Outro ponto crítico que muitas pessoas esquecem: você precisa ter privilégios de superusuário (root) ou acesso via sudo com todas as permissões. A instalação de pacotes, a modificação de arquivos em /etc/crowdsec/ e a interação com o daemon do serviço exigem elevação de privilégios. Também é imprescindível que o relógio do sistema esteja sincronizado via NTP ou chrony, pois o CrowdSec utiliza timestamps precisos para correlacionar eventos e para se comunicar com a API central de inteligência de ameaças. Uma defasagem de horário significativa pode causar rejeição de decisões ou falhas na autenticação da máquina. Por fim, é necessário ter conexão com a internet durante a instalação — os pacotes são baixados do repositório oficial e, durante o primeiro setup, o agente realiza uma chamada à API do CrowdSec para registrar a instância (opcional, mas recomendado para habilitar a inteligência colaborativa).

Nossos especialistas da JRT Technology Solutions utilizam diariamente um checklist padronizado antes de qualquer implantação: verificação de versão do kernel (uname -r), atualização dos pacotes do sistema (apt update && apt upgrade ou dnf update), configuração de NTP e, principalmente, a garantia de que o firewall local não está bloqueando as portas que o CrowdSec precisa para se comunicar com a API (porta 443/TCP de saída). Com esse checklist cumprido, você elimina 90% dos problemas que costumam surgir durante a instalação inicial.

Arquitetura do CrowdSec: entendendo os componentes antes de instalar

Antes de executar qualquer comando, é fundamental que você entenda a arquitetura do CrowdSec, pois isso evita confusões futuras. O CrowdSec é composto por dois componentes principais independentes: o Security Engine (o “cérebro”) e os Bouncers (os “executores”). O Security Engine é responsável por ler os arquivos de log, analisar o conteúdo através de parsers, detectar comportamentos maliciosos usando scenarios e tomar decisões de bloqueio ou não. Ele roda como um serviço chamado crowdsec e expõe uma API local (por padrão em http://127.0.0.1:8080) através da qual os bouncers consultam as decisões de bloqueio. Essa separação é genial: o motor de análise não precisa se preocupar com a forma como o bloqueio é aplicado, e você pode ter múltiplos bouncers diferentes (firewall, Nginx, Cloudflare, etc.) sem duplicar a lógica de detecção.

O bouncer mais comum e o que vamos instalar nesta aula é o crowdsec-firewall-bouncer, que interage diretamente com o iptables ou nftables para criar regras de bloqueio de IP. Quando o Security Engine decide que um determinado IP deve ser banido, essa decisão fica armazenada em um banco de dados SQLite local. O bouncer consulta periodicamente a API local e, ao encontrar uma decisão ativa para um IP, insere uma regra no firewall do sistema para descartar todo o tráfego oriundo daquele endereço. Essa arquitetura desacoplada permite que você, por exemplo, tenha o Security Engine rodando em um servidor centralizado e bouncers em outros servidores, todos consultando a mesma API — cenário comum em infraestruturas maiores.

Outro componente essencial é o cscli, a ferramenta de linha de comando que utilizamos para interagir com o Security Engine. Com o cscli podemos visualizar decisões ativas (cscli decisions list), consultar métricas (cscli metrics), gerenciar coleções de cenários e parsers (cscli collections install), inspecionar alertas e até simular ataques (cscli -y ban scenarios). O cscli se comunica com a API local do Security Engine, portanto precisa estar sempre apontando para o endpoint correto. Nesta aula, focaremos na instalação do Security Engine e de um bouncer de firewall, além da configuração inicial de ambos.

A tabela abaixo resume os componentes principais e suas funções, para que você tenha sempre uma referência rápida:

Componente	Nome do Pacote/Serviço	Função Principal
Security Engine	crowdsec	Ler logs, analisar com parsers, detectar ataques via scenarios, armazenar decisões de bloqueio, expor API local
cscli	Incluso no pacote crowdsec	CLI para interagir com o Security Engine: gerenciar decisões, coleções, cenários, métricas e simulações
Firewall Bouncer	crowdsec-firewall-bouncer	Consultar a API local do Security Engine e inserir/remover regras no iptables/nftables para bloquear IPs maliciosos
LAPI (Local API)	Integrada ao serviço crowdsec	Interface HTTP (padrão na porta 8080) para comunicação entre bouncers e o Security Engine
Banco de Dados	SQLite (padrão em /var/lib/crowdsec/data/crowdsec.db)	Armazena decisões, alertas, métricas e configurações da máquina

Instalação passo a passo do CrowdSec

Chegou a hora de executar a instalação do CrowdSec. Vamos abordar duas rotas principais: distribuições baseadas em Debian/Ubuntu e distribuições baseadas em RHEL/CentOS/Rocky Linux. Em ambos os casos, utilizaremos o instalador oficial via script bash fornecido pela equipe do CrowdSec, que é o método recomendado porque configura automaticamente o repositório, instala os pacotes necessários e realiza o setup inicial interativo. Se você precisar de instalação completamente offline ou com controle granular de versão, pode utilizar os repositórios manualmente — mas para esta aula, seguiremos o caminho oficial e suportado. O script de instalação é seguro e assinado pela equipe do projeto; no entanto, recomendamos sempre inspecionar qualquer script baixado da internet antes de executá-lo como root.

Antes de prosseguir, certifique-se de que os pacotes essenciais estão instalados. No Ubuntu/Debian, você precisará de curl, gnupg e apt-transport-https. No RHEL/Rocky, o curl também é necessário. Execute os comandos correspondentes ao seu sistema. A seguir, apresentamos o passo a passo completo para cada família de distribuição, sem atalhos ou omissões.

Procedimento para Ubuntu/Debian:

Atualize o índice de pacotes e instale as dependências iniciais executando: sudo apt update && sudo apt install -y curl gnupg apt-transport-https. Isso garante que você tenha as ferramentas necessárias para baixar e verificar o script de instalação.
Baixe o script de instalação oficial e execute-o com bash: curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash. Este script configura o repositório packagecloud.io/crowdsec/crowdsec no seu apt, importando a chave GPG automaticamente.
Após a configuração do repositório, instale o pacote principal do CrowdSec: sudo apt install -y crowdsec. Este pacote contém o Security Engine e o cscli.
Durante a instalação, você verá uma tela interativa (via debconf) perguntando se deseja registrar a máquina na CrowdSec Console. Escolha a opção desejada — você pode pular esta etapa ou registrar com sua conta. Se pular, poderá registrar depois com sudo cscli console enroll.
A instalação iniciará automaticamente o serviço crowdsec. Aguarde alguns segundos e verifique o status com sudo systemctl status crowdsec.

O bloco a seguir mostra todos os comandos exatos e a saída esperada após cada etapa crítica, para que você possa comparar com o que aparece no seu terminal.

# Passo 1: atualizar índice e instalar dependências
$ sudo apt update && sudo apt install -y curl gnupg apt-transport-https
...
Lendo listas de pacotes... Pronto
Construindo árvore de dependências... Pronto
curl já está na versão mais recente (7.81.0-1ubuntu1.16).
gnupg já está na versão mais recente (2.2.27-3ubuntu2.2).
apt-transport-https já está na versão mais recente (2.4.12).
0 pacotes atualizados, 0 pacotes novos instalados, 0 a serem removidos e 0 não atualizados.

# Passo 2: baixar e executar o script do repositório oficial
$ curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
Detectado sistema operacional: Ubuntu 22.04
Adicionando repositório do CrowdSec...
Repositório configurado com sucesso.

# Passo 3: instalar o pacote crowdsec
$ sudo apt install -y crowdsec
Lendo listas de pacotes... Pronto
Construindo árvore de dependências... Pronto
Os pacotes a seguir serão instalados:
  crowdsec
...
Configurando crowdsec (1.6.3) ...
Created symlink /etc/systemd/system/multi-user.target.wants/crowdsec.service → /lib/systemd/system/crowdsec.service.
crowdsec instalado e iniciado com sucesso.

# Verificação do status do serviço após instalação (Ubuntu/Debian)
$ sudo systemctl status crowdsec
● 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 Sun 2026-07-05 10:15:22 -03; 2min 34s ago
   Main PID: 12345 (crowdsec)
      Tasks: 12 (limit: 9500)
     Memory: 48.5M
     CGroup: /system.slice/crowdsec.service
             └─12345 /usr/bin/crowdsec -c /etc/crowdsec/config.yaml

Procedimento para RHEL/CentOS/Rocky Linux:

Instale as dependências mínimas com: sudo dnf install -y curl (ou yum install -y curl se estiver utilizando CentOS 7, embora o suporte seja limitado). O curl é necessário para baixar o script do repositório.
Baixe e execute o script de configuração do repositório oficial: curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.rpm.sh | sudo bash. Esse script adiciona o arquivo /etc/yum.repos.d/crowdsec.repo com a configuração correta e importa a chave GPG.
Instale o pacote crowdsec com: sudo dnf install -y crowdsec.
Inicie e habilite o serviço para inicialização automática: sudo systemctl enable –now crowdsec.
Confira o status: sudo systemctl status crowdsec.

# Passo 1: dependências
$ sudo dnf install -y curl
Última verificação de metadados: há 0:15:43 em dom 05 jul 2026 10:12:45 -03.
O pacote curl-8.4.0-5.el9.x86_64 já está instalado.
Dependências resolvidas.
Nada a fazer.
Completo!

# Passo 2: script do repositório
$ curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.rpm.sh | sudo bash
Detectado sistema operacional: Rocky Linux 9.4
Adicionando repositório do CrowdSec...
Repositório configurado com sucesso.

# Passo 3: instalação do crowdsec
$ sudo dnf install -y crowdsec
Repositório crowdsec                                              1.2 MB/s | 1.5 MB     00:01
Dependências resolvidas.
...
Instalando  : crowdsec-1.6.3-1.x86_64                                                                                        1/1
Executando scriptlet: crowdsec-1.6.3-1.x86_64                                                                                1/1
crowdsec instalado e iniciado com sucesso.

# Passo 4: habilitação no boot
$ sudo systemctl enable --now crowdsec
Created symlink /etc/systemd/system/multi-user.target.wants/crowdsec.service → /usr/lib/systemd/system/crowdsec.service.

# Status do crowdsec no Rocky Linux
$ sudo systemctl status crowdsec
● crowdsec.service - CrowdSec - The open-source and participative security solution
     Loaded: loaded (/usr/lib/systemd/system/crowdsec.service; enabled; vendor preset: disabled)
     Active: active (running) since Sun 2026-07-05 10:20:15 -03; 1min 10s ago
   Main PID: 9876 (crowdsec)
      Tasks: 11 (limit: 23000)
     Memory: 45.2M
     CGroup: /system.slice/crowdsec.service
             └─9876 /usr/bin/crowdsec -c /etc/crowdsec/config.yaml

Após a conclusão destes passos, o CrowdSec Security Engine já está em execução. No entanto, ele ainda não está bloqueando ativamente nenhum tráfego — para isso, precisamos instalar o bouncer de firewall. Mas antes, vamos explorar em detalhes o arquivo de configuração principal, pois alguns ajustes podem ser necessários dependendo do seu ambiente.

Configuração detalhada do arquivo /etc/crowdsec/config.yaml

O coração da configuração do CrowdSec reside no arquivo /etc/crowdsec/config.yaml. Este arquivo, escrito em formato YAML, controla tudo: desde a localização dos arquivos de log até a taxa de aquisição de eventos, passando pelo endereço da API local e parâmetros de conexão com a CrowdSec Console. A instalação padrão gera um arquivo funcional, mas é essencial que você conheça cada seção para adaptar o CrowdSec à sua realidade. A seguir, apresento o conteúdo completo do arquivo gerado após uma instalação limpa, com comentários explicativos em cada seção relevante. Este é o mesmo arquivo que utilizamos como ponto de partida em todas as implantações na JRT Technology Solutions.

# /etc/crowdsec/config.yaml — Configuração principal do CrowdSec Security Engine
# Este arquivo controla o comportamento do daemon, a aquisição de logs e a API local.

common:
  daemonize: true                      # Executa o crowdsec como daemon (segundo plano)
  pid_dir: /var/run/crowdsec           # Diretório para o arquivo PID
  log_media: file                      # Saída de logs do próprio crowdsec para arquivo
  log_level: info                      # Nível de log: debug, info, warning, error
  log_dir: /var/log/crowdsec           # Diretório onde os logs do crowdsec serão escritos
  working_dir: /var/lib/crowdsec/data  # Diretório de trabalho, onde fica o SQLite

crowdsec_service:
  acquisition_dir: /etc/crowdsec/acquis.d/   # Diretório com arquivos de aquisição de logs
  parsers_routines: 1                         # Número de goroutines para parsers
  buckets_routines: 1                         # Número de goroutines para buckets (scenarios)

cscli:
  output: human                    # Formato de saída padrão para comandos cscli

api:
  client:
    insecure_skip_verify: false    # Verificar certificado TLS ao conectar na LAPI
    credentials_path: /etc/crowdsec/local_api_credentials.yaml  # Credenciais do bouncer
  server:
    log_level: info
    listen_uri: 127.0.0.1:8080     # Endereço e porta onde a LAPI escuta (localhost)
    profiles_path: /etc/crowdsec/profiles.yaml
    tls:
      cert_file: /etc/crowdsec/ssl/cert.pem     # Certificado TLS autoassinado
      key_file: /etc/crowdsec/ssl/key.pem       # Chave privada TLS

db_config:
  log_level: info
  type: sqlite                      # Tipo de banco de dados
  db_path: /var/lib/crowdsec/data/crowdsec.db  # Caminho para o banco SQLite
  flush:
    max_items: 5000                 # Máximo de itens antes de flush
    max_age: 7d                     # Idade máxima dos alertas no banco

plugin_config:
  user: nobody                      # Usuário sob o qual o crowdsec executa
  group: nogroup                    # Grupo sob o qual o crowdsec executa

prometheus:
  enabled: true                     # Habilita endpoint de métricas Prometheus
  level: full
  listen_addr: 127.0.0.1
  listen_port: 6060

O ponto mais importante para a maioria dos cenários iniciais é o diretório de aquisição (acquisition_dir). Por padrão, o CrowdSec procura arquivos YAML dentro de /etc/crowdsec/acquis.d/ que descrevem quais arquivos de log devem ser monitorados e com qual labels (rótulos) de tipo. Após a instalação, você encontrará pelo menos um arquivo nesse diretório, geralmente chamado syslog.yaml ou auth.yaml, que configura a leitura de logs de autenticação. Vamos inspecionar esse arquivo no próximo tópico, pois a correta definição de acquis é o que faz o CrowdSec enxergar os eventos do seu sistema. Qualquer erro aqui significa que o motor está rodando, mas efetivamente “cego”.

Instalação e configuração do CrowdSec Firewall Bouncer

Com o Security Engine em funcionamento, o próximo passo é instalar o crowdsec-firewall-bouncer, o componente que efetivamente aplica os bloqueios no firewall do sistema. Este bouncer atua como um cliente da API local (LAPI) e, com base nas decisões geradas pelo motor, insere regras no iptables (ou nftables, dependendo da configuração e do suporte do kernel). A instalação é independente do Security Engine — você pode inclusive instalar o bouncer em uma máquina diferente, desde que aponte para a API correta. Para esta aula, instalaremos tudo na mesma máquina, que é o cenário mais comum em servidores únicos.

Instalação do Firewall Bouncer no Ubuntu/Debian:

# Instale o pacote do bouncer via apt
$ sudo apt install -y crowdsec-firewall-bouncer-iptables
Lendo listas de pacotes... Pronto
Construindo árvore de dependências... Pronto
Os pacotes a seguir serão instalados:
  crowdsec-firewall-bouncer-iptables
...
Configurando crowdsec-firewall-bouncer-iptables (0.0.30) ...
firewall-bouncer instalado e iniciado com sucesso.

Instalação do Firewall Bouncer no RHEL/Rocky:

# Instale o pacote do bouncer via dnf
$ sudo dnf install -y crowdsec-firewall-bouncer-iptables
Última verificação de metadados: há 0:02:11 em dom 05 jul 2026 10:22:45 -03.
Dependências resolvidas.
...
Instalando  : crowdsec-firewall-bouncer-iptables-0.0.30-1.x86_64
firewall-bouncer instalado e iniciado com sucesso.

Após a instalação, o serviço do bouncer é iniciado automaticamente. Você pode verificar o status com sudo systemctl status crowdsec-firewall-bouncer. Se o status mostrar active (running), a comunicação com a API local está funcionando. No entanto, o bouncer ainda não aplicará bloqueios até que haja decisões ativas geradas pelo Security Engine — ou seja, até que um ataque real ou simulado seja detectado. O arquivo de configuração do bouncer fica em /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml e, na maioria dos casos, não precisa ser alterado para um primeiro funcionamento.

# Status do firewall bouncer após instalação
$ sudo systemctl status crowdsec-firewall-bouncer
● crowdsec-firewall-bouncer.service - The firewall bouncer for CrowdSec
     Loaded: loaded (/lib/systemd/system/crowdsec-firewall-bouncer.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2026-07-05 10:28:33 -03; 45s ago
   Main PID: 13579 (crowdsec-firewa)
      Tasks: 9
     Memory: 10.2M
     CGroup: /system.slice/crowdsec-firewall-bouncer.service
             └─13579 /usr/bin/crowdsec-firewall-bouncer -c /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml

Configurando a aquisição de logs — o que monitorar

Agora que ambos os componentes estão instalados, precisamos garantir que o CrowdSec está efetivamente lendo os logs corretos. O diretório /etc/crowdsec/acquis.d/ contém arquivos YAML que descrevem as fontes de log. Durante a instalação, o CrowdSec tenta detectar automaticamente os serviços em execução e gera arquivos de aquisição adequados. Contudo, é fundamental que você inspecione e, se necessário, ajuste essas configurações manualmente. Vamos examinar o conteúdo típico do arquivo /etc/crowdsec/acquis.d/sshd.yaml que monitora logs de SSH.

# Conteúdo do arquivo /etc/crowdsec/acquis.d/sshd.yaml
# Este arquivo instrui o CrowdSec a monitorar o log de autenticação SSH
---
source: file                     # Tipo de fonte: arquivo
filenames:                       # Lista de arquivos a monitorar
  - /var/log/auth.log            # Caminho padrão no Ubuntu/Debian
  - /var/log/secure              # Caminho padrão no RHEL/Rocky
labels:
  type: syslog                   # Rótulo de tipo: o CrowdSec usa parsers específicos para syslog

Se você utiliza uma distribuição que grava logs SSH em um local diferente, ou se deseja monitorar logs de outros serviços (como Nginx, Apache, MySQL), basta criar novos arquivos YAML dentro de /etc/crowdsec/acquis.d/ seguindo o mesmo formato. Após qualquer alteração nos arquivos de aquisição, é necessário reiniciar o serviço do CrowdSec com sudo systemctl restart crowdsec. O daemon lerá os novos arquivos e começará a monitorar as fontes especificadas. Uma dica importante: o CrowdSec não monitora diretórios recursivamente — cada arquivo de log deve ser explicitamente listado. Em implantações na JRT Technology Solutions, costumamos criar um arquivo separado para cada serviço monitorado, mantendo a organização e facilitando a manutenção.

Serviço	Arquivo de Log Típico	Rótulo (label type)	Arquivo acquis recomendado
SSH	/var/log/auth.log (Debian) ou /var/log/secure (RHEL)	syslog	sshd.yaml
Nginx	/var/log/nginx/access.log	nginx	nginx.yaml
Apache	/var/log/apache2/access.log	apache2	apache2.yaml
MySQL	/var/log/mysql/error.log	mysql	mysql.yaml

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

Esta é a seção mais importante da aula: a verificação de que tudo está funcionando corretamente. De nada adianta seguir os passos de instalação se, ao final, o CrowdSec não está detectando eventos ou o bouncer não está bloqueando. Vamos executar uma série de comandos de validação que, se bem-sucedidos, comprovam que a instalação foi feita corretamente e que o sistema está pronto para proteger seu servidor. Siga cada comando na ordem e compare a saída obtida com a saída esperada documentada aqui. Qualquer divergência significativa indica um problema que você deve investigar antes de prosseguir para as próximas aulas.

O primeiro comando de verificação é o cscli hub list, que lista todas as coleções, cenários e parsers instalados e disponíveis no hub do CrowdSec. Este comando também valida que a instalação do pacote está íntegra e que o binário cscli está funcional. Em seguida, utilizaremos cscli metrics para verificar se o Security Engine já está processando logs e contabilizando eventos.

# 1. Listar itens do hub instalados (parsers, scenarios, collections)
$ sudo cscli hub list

INFO[05-07-2026 10:35:12] Listando itens do hub                          
 NAME                          📦 STATUS    VERSION  LOCAL PATH                                             
------------------------------------------------------------------------------------------------------------
 crowdsecurity/linux           ✔️  enabled  0.2      /etc/crowdsec/hub/collections/linux                   
 crowdsecurity/sshd            ✔️  enabled  0.4      /etc/crowdsec/hub/collections/sshd                    
 crowdsecurity/syslog-logs     ✔️  enabled  0.3      /etc/crowdsec/hub/collections/syslog-logs             
 crowdsecurity/dateparse-enrich ✔️  enabled  0.2      /etc/crowdsec/hub/parsers/s01-parse/dateparse-enrich 
 crowdsecurity/sshd-logs       ✔️  enabled  0.4      /etc/crowdsec/hub/collections/sshd-logs               
 crowdsecurity/syslog          ✔️  enabled  0.2      /etc/crowdsec/hub/parsers/s00-raw/syslog              
 crowdsecurity/whitelists      ✔️  enabled  0.3      /etc/crowdsec/hub/parsers/s02-enrich/whitelists       
 crowdsecurity/geoip-enrich    ✔️  enabled  0.4      /etc/crowdsec/hub/parsers/s02-enrich/geoip-enrich     
 ------------------------------------------------------------------------------------------------------------

# 2. Exibir métricas do Security Engine
$ sudo cscli metrics

INFO[05-07-2026 10:36:02] Métricas do CrowdSec                          
ACQUISITION (desde 2026-07-05 10:15:22):
 - /var/log/auth.log: 1,247 linhas lidas, 1,247 analisadas, 0 não analisadas
 - /var/log/syslog: 892 linhas lidas, 892 analisadas, 0 não analisadas

PARSERS (desde 2026-07-05 10:15:22):
 - crowdsecurity/syslog: 2,139 eventos processados (100% de sucesso)
 - crowdsecurity/dateparse-enrich: 2,139 eventos enriquecidos
 - crowdsecurity/whitelists: 2,139 eventos verificados
 - crowdsecurity/geoip-enrich: 1,247 eventos enriquecidos com GeoIP
 - crowdsecurity/sshd-logs: 427 eventos SSH processados

SCENARIOS (desde 2026-07-05 10:15:22):
 - crowdsecurity/ssh-bf: 0 detecções (threshold não atingido)
 - crowdsecurity/ssh-bf_user-enum: 0 detecções

DECISIONS:
 - Decisões ativas: 0

LAPI:
 - API local alcançável em 127.0.0.1:8080
 - Bouncers registrados: 1 (crowdsec-firewall-bouncer)

Se a sua saída for semelhante à mostrada acima, com métricas de aquisição contabilizando linhas lidas e parsers processando eventos, o CrowdSec está operacional. O próximo passo é gerar uma decisão de bloqueio para confirmar que o ciclo completo — detecção → decisão → bloqueio — funciona. Para isso, podemos simular um ataque de força bruta contra o SSH da própria máquina (a partir de localhost, que não deve estar na whitelist interna do CrowdSec). Vamos utilizar o comando cscli decisions add para adicionar uma decisão manual de teste e verificar se o bouncer insere a regra no firewall.

# 3. Adicionar uma decisão de teste (banir IP 192.0.2.1 por 5 minutos)
$ sudo cscli decisions add --ip 192.0.2.1 --duration 5m --reason "teste_manual_aula16"

INFO[05-07-2026 10:40:15] Decisão adicionada com sucesso
 - ID: 42
 - IP: 192.0.2.1
 - Duração: 5m0s
 - Razão: teste_manual_aula16
 - Escopo: ban

# 4. Listar as decisões ativas
$ sudo cscli decisions list

+--------+---------------+-----------+-----------------+--------+---------+----------------------------+----------------------------+
|   ID   |     VALUE     |  TARGET   |     SOURCE      | SCOPE  | ACTION  |         START_AT           |          END_AT            |
+--------+---------------+-----------+-----------------+--------+---------+----------------------------+----------------------------+
|      42| 192.0.2.1    | Ip        | cscli           | ban    | ban     | 2026-07-05 10:40:15 -0300  | 2026-07-05 10:45:15 -0300  |
+--------+---------------+-----------+-----------------+--------+---------+----------------------------+----------------------------+

# 5. Verificar se o bouncer adicionou a regra no iptables
$ sudo iptables -L -n | grep 192.0.2.1

DROP       all  --  192.0.2.1            0.0.0.0/0

A presença da regra DROP para o IP 192.0.2.1 no iptables confirma que o firewall-bouncer está consultando a API local corretamente e aplicando as decisões de bloqueio no firewall do sistema. Agora podemos remover a decisão de teste para limpar o ambiente:

# 6. Remover a decisão de teste
$ sudo cscli decisions delete --id 42
$ sudo iptables -L -n | grep 192.0.2.1  # Não deve retornar resultados

Erros Comuns e Como Resolver

Durante as inúmeras implantações de CrowdSec que realizamos na JRT Technology Solutions, catalogamos um conjunto de erros frequentes que surgem logo após a instalação inicial. A seguir, listamos os quatro mais recorrentes, com a descrição do sintoma, a causa raiz e a solução completa para cada um. Ter esse conhecimento à mão pode economizar horas de troubleshooting e evitar frustrações desnecessárias.

Erro 1: “cscli: command not found” ou binário não localizado.
Sintoma: Ao tentar executar qualquer comando cscli, o shell retorna “command not found”.
Causa: O pacote crowdsec não foi instalado corretamente ou o diretório do binário (/usr/bin/cscli) não está no PATH do usuário. Também pode ocorrer se você tentou executar como usuário comum sem sudo e o binário não está acessível globalmente.
Solução: Verifique se o pacote está instalado com dpkg -l | grep crowdsec (Debian) ou rpm -qa | grep crowdsec (RHEL). Se não estiver, reinstale conforme os passos da aula. Se estiver, tente o caminho absoluto: /usr/bin/cscli. Adicione /usr/bin ao PATH do seu usuário se necessário: export PATH=$PATH:/usr/bin e adicione essa linha ao ~/.bashrc para tornar permanente.
Erro 2: O bouncer não insere regras no iptables/nftables.
Sintoma: O Security Engine mostra decisões ativas com cscli decisions list, mas nenhuma regra aparece no iptables -L -n.
Causa: O serviço do firewall-bouncer pode estar parado, com falha de autenticação na API, ou o kernel não possui os módulos iptables/nftables carregados. Outra causa comum é a falta da chain CROWDSEC_CHAIN no iptables — o bouncer espera que essa chain exista e que haja uma regra de INPUT redirecionando para ela.
Solução: Verifique o status do serviço: sudo systemctl status crowdsec-firewall-bouncer. Se estiver ativo, inspecione os logs em /var/log/crowdsec-firewall-bouncer.log (ou use journalctl -u crowdsec-firewall-bouncer). Erros comuns incluem “connection refused” (API não está ouvindo em 127.0.0.1:8080 — verifique o Security Engine) ou “permission denied” (execute o bouncer como root ou conceda capabilities específicas). Se as chains não existirem, reinicie o bouncer: ele as criará automaticamente. Se o problema persistir, recarreg