Aula 19: CrowdSec — Console Web e Gerenciamento Centralizado de Instâncias

Chegamos a um dos pontos mais estratégicos do nosso curso “Firewall, fail2ban e CrowdSec — Do Zero ao Avançado”. Até aqui, você aprendeu a instalar, configurar e operar o CrowdSec em servidores individuais — criando cenários, ajustando decisões, interpretando alertas e integrando com firewalls como iptables e nftables. Agora, vamos dar um salto de maturidade operacional: o gerenciamento centralizado de múltiplas instâncias através do Console Web do CrowdSec. Se você administra dois, cinco ou cinquenta servidores Linux, esta aula será um divisor de águas na forma como você monitora e responde a ameaças.

O CrowdSec foi projetado desde o início com uma arquitetura que suporta colaboração e centralização. Enquanto o fail2ban opera de forma isolada em cada host — exigindo que você acesse cada máquina individualmente para ver logs, ajustar regras ou verificar bans — o CrowdSec oferece um modelo onde múltiplos agentes (instâncias) podem reportar a um servidor central (Local API) e, a partir dele, você visualiza tudo em um console web unificado. Isso significa que um ataque detectado em um servidor web pode gerar bloqueios automáticos em outros servidores da sua rede, mesmo que o atacante nunca tenha tentado acessá-los diretamente. Em nossos projetos na JRT Technology Solutions, utilizamos diariamente essa funcionalidade para proteger infraestruturas distribuídas com dezenas de VPS e servidores bare-metal.

Nesta aula, vamos cobrir cada etapa com profundidade: da teoria da arquitetura centralizada até a configuração prática do Console Web, passando pelo registro de instâncias, configuração da Local API (LAPI), geração de tokens de autenticação e verificação do fluxo de dados. Você aprenderá a usar o comando cscli para gerenciar máquinas, inscrever seu servidor no console cloud e interpretar as telas principais do dashboard. Cada comando será mostrado na íntegra, cada saída de terminal será exibida exatamente como você verá na sua tela — sem resumos, sem “etc.”, sem saltos.

O ambiente de trabalho será baseado em servidores Linux Ubuntu/Debian e CentOS/RHEL/Rocky Linux, garantindo cobertura para as duas principais famílias de distribuições utilizadas em produção. Assumimos que você já tem o CrowdSec instalado e funcionando em pelo menos duas máquinas (conforme as aulas anteriores do curso). Se você ainda não fez isso, recomendamos fortemente revisar as Aulas 16 a 18 antes de prosseguir. Ao final desta aula, você será capaz de gerenciar toda a sua frota de servidores a partir de um único painel de vidro, reduzindo drasticamente o tempo de resposta a incidentes e ganhando uma visibilidade que simplesmente não existe no modelo tradicional por host.

Prepare seu terminal, tenha suas chaves SSH à mão e reserve cerca de 45 minutos para executar cada passo com atenção. O resultado será uma implantação profissional de CrowdSec com gerenciamento centralizado que você poderá replicar em qualquer ambiente — de laboratórios caseiros a datacenters corporativos.

O que você vai aprender nesta aula

• Compreender a arquitetura de gerenciamento centralizado do CrowdSec e o papel da Local API (LAPI)
• Configurar uma instância como servidor LAPI central para múltiplos agentes
• Registrar instâncias adicionais como clientes da LAPI usando cscli machines add
• Inscrever sua infraestrutura no Console Web do CrowdSec (app.crowdsec.net) com cscli console enroll
• Navegar pelo dashboard centralizado: alertas, decisões, métricas e gestão de máquinas
• Interpretar o fluxo de dados entre agentes, LAPI e o console cloud
• Diferenciar os modos de operação: standalone, LAPI server e LAPI client
• Diagnosticar e corrigir os erros mais comuns durante o registro e a sincronização

Pré-requisitos e Ambiente

Para executar esta aula com sucesso, você precisará do seguinte ambiente mínimo. Todos os itens abaixo são cumulativos em relação ao que já foi construído nas aulas anteriores. Não pule a verificação de cada pré-requisito — problemas nesta etapa são a causa número um de falhas durante o registro centralizado, como observamos repetidamente nos atendimentos de suporte da JRT Technology Solutions.

• 2 ou mais servidores Linux com CrowdSec instalado e operacional (versão 1.5.x ou superior recomendada). Exemplo: servidor A (que será o LAPI server) e servidor B (que será LAPI client). Ambos podem ser máquinas físicas, VMs ou containers LXC/Docker com acesso de rede entre si.
• Sistema operacional: Ubuntu 22.04/24.04 LTS, Debian 12, CentOS 9 Stream, Rocky Linux 9 ou RHEL 9. Os comandos serão apresentados para ambas as famílias.
• Conectividade de rede: os servidores devem conseguir se comunicar entre si na porta TCP 8080 (porta padrão da LAPI). Além disso, o servidor LAPI precisa de acesso à internet (ou a um proxy configurado) para se comunicar com o Console Web do CrowdSec via API.
• Conta no Console Web do CrowdSec: acesse https://app.crowdsec.net e crie uma conta gratuita. O plano Community é suficiente para gerenciar múltiplas instâncias e é o que usaremos nesta aula.
• cscli funcional: o comando cscli deve estar no PATH e funcionando corretamente. Execute cscli version para confirmar. Se não estiver, revise a Aula 16 (instalação do CrowdSec).
• Permissões de root ou sudo: você precisará editar arquivos em /etc/crowdsec/ e reiniciar o serviço crowdsec.
• Firewall local ajustado: se você estiver usando iptables/nftables/firewalld, garanta que a porta 8080 esteja aberta para os IPs dos servidores clientes. Exemplo com firewalld: sudo firewall-cmd –permanent –add-rich-rule=’rule family=”ipv4″ source address=”10.0.0.0/24″ port port=”8080″ protocol=”tcp” accept’ && sudo firewall-cmd –reload

Arquitetura do Gerenciamento Centralizado no CrowdSec

Antes de colocar as mãos no teclado, é fundamental entender como o CrowdSec organiza sua arquitetura de gerenciamento centralizado. Diferentemente do fail2ban, que é intrinsecamente mononodo (cada instância é um silo isolado), o CrowdSec foi concebido com um modelo cliente-servidor interno que permite que múltiplos agentes compartilhem informações de ameaças e recebam decisões centralizadas. Essa arquitetura gira em torno de três componentes principais que você precisa conhecer profundamente.

O primeiro componente é o agente local (CrowdSec Agent), que roda em cada servidor que você deseja proteger. Ele lê logs, detecta comportamentos maliciosos usando cenários e pode aplicar decisões localmente (como bloquear IPs via firewall bouncer). O segundo componente é a Local API (LAPI), que funciona como um hub central de inteligência. Uma instância da LAPI pode ser configurada para receber alertas de múltiplos agentes, consolidar as informações sobre atacantes e redistribuir decisões para todos os agentes conectados a ela. O terceiro componente é o Console Web do CrowdSec, uma interface SaaS hospedada em app.crowdsec.net que se conecta à sua LAPI e oferece dashboards, histórico de alertas, gestão de decisões e muito mais — tudo visualmente acessível sem precisar abrir um terminal SSH.

A mágica acontece na combinação desses três elementos. Imagine um cenário real que enfrentamos frequentemente na JRT Technology Solutions: você tem três servidores web (web1, web2, web3), um servidor de banco de dados (db1) e um servidor de e-mail (mail1). No modelo tradicional com fail2ban, se um atacante tentar força bruta contra o web1, apenas o web1 bloqueia o IP. O atacante pode então migrar para o web2 e tentar novamente, sem qualquer impedimento. Com o CrowdSec em arquitetura centralizada, assim que o web1 detecta o ataque e reporta à LAPI, esta envia imediatamente uma decisão de bloqueio para web2, web3, db1 e mail1 — mesmo que o atacante nunca tenha mirado esses servidores. O bloqueio é distribuído em segundos, e tudo fica visível no Console Web, onde você pode acompanhar em tempo real.

A comunicação entre agentes e LAPI é feita via API REST sobre HTTPS (ou HTTP, se configurado sem TLS em ambientes internos controlados), utilizando tokens de autenticação gerados pelo cscli. Cada agente recebe um login e uma senha (ou token) que o identificam unicamente perante a LAPI. O Console Web, por sua vez, se comunica com a LAPI através de um processo de enrollment que usa uma chave de inscrição gerada no site app.crowdsec.net. Essa chave é inserida no servidor LAPI via cscli console enroll, estabelecendo um túnel seguro e persistente entre sua infraestrutura e a nuvem do CrowdSec.

É importante destacar que o Console Web não substitui a LAPI — ele a complementa. A LAPI continua sendo o cérebro central dentro da sua rede, armazenando o banco de dados local (SQLite por padrão, mas podendo ser migrado para PostgreSQL em ambientes maiores) com todos os alertas, decisões e métricas. O console cloud atua como uma camada de visualização e gestão remota, permitindo que você acesse as informações consolidadas de qualquer lugar, sem precisar expor a LAPI diretamente à internet ou configurar VPNs complexas.

Modos de Operação: Standalone, LAPI Server e LAPI Client

O comportamento de cada instância do CrowdSec é definido pelo seu modo de operação, configurado no arquivo /etc/crowdsec/config.yaml. Existem três modos principais que você precisa dominar para implementar o gerenciamento centralizado corretamente. Vamos detalhar cada um com exemplos práticos e as implicações de segurança e desempenho de cada escolha.

O modo standalone é o padrão após a instalação e foi o que utilizamos nas aulas anteriores. Neste modo, a instância roda simultaneamente como agente (lendo logs locais) e como LAPI (servindo apenas a si mesma). O banco de dados é local e as decisões são aplicadas apenas na própria máquina. O arquivo config.yaml terá a seção de API configurada para escutar em 127.0.0.1:8080, e o agente local se conecta a esse endereço de loopback. Este modo é adequado para servidores isolados ou quando você está começando, mas não escala para múltiplos servidores.

O modo LAPI server é o coração do gerenciamento centralizado. Neste modo, a instância ainda pode atuar como agente local (processando seus próprios logs) OU pode ser configurada exclusivamente como servidor de API, sem ler logs localmente. A diferença crucial é que a LAPI passa a escutar em um endereço de rede acessível (como 0.0.0.0:8080 ou o IP da interface de rede), permitindo que outros agentes se conectem a ela. Para ativar este modo, você precisa alterar o parâmetro listen_uri na seção api.server do config.yaml. Além disso, você usará o cscli machines add para criar credenciais para cada agente cliente que se conectará.

O modo LAPI client é configurado nos servidores que delegam a inteligência para o LAPI server central. Nestes servidores, o agente local continua lendo seus próprios logs e aplicando decisões localmente (via bouncers), mas todos os alertas são enviados para a LAPI central, e as decisões são consultadas a partir dela. A configuração envolve alterar o arquivo /etc/crowdsec/local_api_credentials.yaml (ou configurar a URL da LAPI remota no config.yaml) e fornecer as credenciais geradas pelo servidor central. Esta separação de responsabilidades é o que permite escalar a proteção para dezenas de servidores sem duplicar esforços de gestão.

A tabela abaixo resume os três modos, suas principais características e quando utilizar cada um. Guarde esta referência — ela será útil sempre que você estiver projetando ou diagnosticando uma implantação do CrowdSec.

Passo a Passo — Configurando o Servidor LAPI Central

Nesta seção, vamos transformar um dos seus servidores no LAPI server central que atenderá os demais. Escolha uma máquina que tenha boa conectividade de rede com os outros servidores e que preferencialmente fique em uma subnet segura. Em nossos projetos na JRT Technology Solutions, costumamos designar um servidor dedicado para a LAPI quando a frota ultrapassa 10 instâncias, mas para até 5 servidores, o próprio servidor de monitoramento ou um balanceador de carga pode acumular essa função sem problemas de desempenho. Todos os passos a seguir assumem que você está logado como root ou usando sudo.

O primeiro passo é localizar e editar o arquivo de configuração principal do CrowdSec. Este arquivo está em /etc/crowdsec/config.yaml e controla todos os aspectos do comportamento do serviço. Precisamos modificar a seção api.server para que a LAPI escute em um endereço de rede acessível, não apenas em localhost. Vamos também verificar se a porta está correta e se o modo de autenticação está configurado. Trabalharemos inicialmente sem TLS (apenas HTTP) para simplificar o aprendizado — em um ambiente de produção, você deve configurar certificados TLS, e mostraremos como fazer isso na seção de boas práticas.

Execute os comandos abaixo para fazer backup do arquivo original e editá-lo. Utilizaremos o editor nano por ser o mais acessível, mas você pode usar vim ou vi se preferir.

# 1. Fazer backup do config.yaml original
sudo cp /etc/crowdsec/config.yaml /etc/crowdsec/config.yaml.bak.$(date +%Y%m%d)

# 2. Editar o arquivo de configuração
sudo nano /etc/crowdsec/config.yaml

# 3. Localize a seção api.server (aproximadamente linha 30-50 dependendo da versão)
#    e modifique conforme mostrado abaixo

Dentro do arquivo /etc/crowdsec/config.yaml, localize o bloco api: e, dentro dele, a subseção server:. O conteúdo relevante antes da modificação se parece com isto:

api:
  client:
    credentials_path: /etc/crowdsec/local_api_credentials.yaml
  server:
    listen_uri: 127.0.0.1:8080
    profiles_path: /etc/crowdsec/profiles.yaml
    tls:
      #cert_file: /etc/crowdsec/ssl/cert.pem
      #key_file: /etc/crowdsec/ssl/key.pem

Altere o parâmetro listen_uri para o endereço de rede desejado. Se o seu servidor LAPI tem o IP 10.0.0.10 e você quer que ele escute apenas nessa interface, use 10.0.0.10:8080. Se preferir que ele escute em todas as interfaces (mais flexível, mas requer cuidado com firewall), use 0.0.0.0:8080. Em nossos ambientes na JRT Technology Solutions, quando os servidores estão em uma rede interna segregada, utilizamos 0.0.0.0:8080 combinado com regras restritivas de firewall (iptables/nftables) que limitam o acesso apenas aos IPs dos servidores clientes.

O bloco após a modificação ficará assim (exemplo para escuta em todas as interfaces):

api:
  client:
    credentials_path: /etc/crowdsec/local_api_credentials.yaml
  server:
    listen_uri: 0.0.0.0:8080
    profiles_path: /etc/crowdsec/profiles.yaml
    tls:
      #cert_file: /etc/crowdsec/ssl/cert.pem
      #key_file: /etc/crowdsec/ssl/key.pem

Salve o arquivo (no nano: Ctrl+O, Enter, Ctrl+X) e reinicie o serviço do CrowdSec para aplicar a nova configuração. O comando de reinicialização varia ligeiramente entre distribuições, mas o systemctl é o padrão em todas as versões modernas.

# 4. Reiniciar o serviço CrowdSec para aplicar as mudanças
sudo systemctl restart crowdsec

# 5. Verificar se o serviço subiu corretamente
sudo systemctl status crowdsec

A saída esperada do comando systemctl status crowdsec deve mostrar o serviço como active (running). Fique atento à linha que menciona a API — se houver algum erro de bind (endereço já em uso ou permissão negada), ele aparecerá nos logs. Se tudo estiver correto, você verá algo como:

● 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 Fri 2026-07-31 10:15:22 UTC; 5s ago
   Main PID: 28451 (crowdsec)
      Tasks: 12 (limit: 38243)
     Memory: 28.4M
        CPU: 356ms
     CGroup: /system.slice/crowdsec.service
             └─28451 /usr/bin/crowdsec

Jul 31 10:15:22 lapi-server crowdsec[28451]: Starting CrowdSec v1.6.0
Jul 31 10:15:22 lapi-server crowdsec[28451]: Local API listening on 0.0.0.0:8080

Agora que a LAPI está escutando na rede, precisamos criar as credenciais para os agentes clientes. Cada servidor que se conectará à LAPI central precisa de um par de credenciais (login e senha) gerado no servidor LAPI. O comando cscli machines add é a ferramenta para isso. Ele cria uma entrada no banco de dados da LAPI e retorna as credenciais que devem ser inseridas no servidor cliente.

# 6. Criar credenciais para o servidor cliente (ex: web2)
#    Substitua "web2" pelo hostname ou identificador do seu servidor cliente
sudo cscli machines add web2

# Saída esperada (ANOTE A SENHA, ela será mostrada apenas UMA VEZ):
# Machine 'web2' successfully added to the local API.
#    API login: web2
#    API password: a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

INFO[0000] Machine 'web2' successfully added to the local API.
INFO[0000]    API login: web2
INFO[0000]    API password: a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

Repita o comando cscli machines add para cada servidor cliente que você deseja conectar. Recomendamos usar o hostname real de cada máquina como login, pois isso facilita a identificação no Console Web posteriormente. Anote cada senha gerada em um local seguro (um gerenciador de senhas, um vault ou, temporariamente, um arquivo criptografado) — você precisará delas no passo de configuração dos clientes.

Para verificar todas as máquinas registradas na sua LAPI, use o comando cscli machines list. Este comando exibe uma tabela com o nome de cada máquina, seu endereço IP (quando conectada), a versão do agente e a última vez que foi vista. Imediatamente após criar as credenciais, as máquinas aparecerão com status “pending” até que o cliente se conecte pela primeira vez.

# 7. Listar todas as máquinas registradas na LAPI
sudo cscli machines list

----------------------------------------------------------------------------------------------------
 NAME      IP ADDRESS    LAST UPDATE           STATUS          VERSION          AUTH TYPE
----------------------------------------------------------------------------------------------------
 lapi-server  127.0.0.1   2026-07-31T10:15:22Z  active          v1.6.0          password
 web2         -           -                     pending         -               password
 db1          -           -                     pending         -               password
----------------------------------------------------------------------------------------------------

Observe que o próprio servidor LAPI aparece na lista (como lapi-server no exemplo), pois ele também é uma máquina gerenciada. As demais máquinas (web2, db1) estão com status pending e sem IP — elas se tornarão active assim que os clientes se conectarem. Na próxima seção, configuraremos exatamente isso.

Configurando as Instâncias Clientes (LAPI Clients)

Com o servidor LAPI central pronto e as credenciais geradas, vamos agora aos servidores que atuarão como clientes — aqueles que enviam alertas e recebem decisões da LAPI central. Este processo é similar em todas as distribuições Linux, pois os arquivos de configuração do CrowdSec seguem a mesma estrutura. A diferença principal está apenas nos comandos de instalação do pacote (se o CrowdSec ainda não estiver instalado), mas como pré-requisito da aula, assumimos que o pacote já está presente.

Em cada servidor cliente, precisamos modificar dois pontos: primeiro, informar ao agente local que ele deve se conectar a uma LAPI remota em vez da local (loopback); segundo, fornecer as credenciais (login e senha) que foram geradas no servidor LAPI central. A configuração é feita no arquivo /etc/crowdsec/config.yaml e no arquivo de credenciais /etc/crowdsec/local_api_credentials.yaml. Vamos fazer isso passo a passo, começando pelo arquivo de configuração principal.

# NO SERVIDOR CLIENTE (ex: web2 com IP 10.0.0.20):

# 1. Fazer backup do config.yaml original
sudo cp /etc/crowdsec/config.yaml /etc/crowdsec/config.yaml.bak.$(date +%Y%m%d)

# 2. Editar o arquivo de configuração
sudo nano /etc/crowdsec/config.yaml

# 3. Localize a seção api.client e modifique conforme abaixo

No arquivo /etc/crowdsec/config.yaml do servidor cliente, localize o bloco api.client. Originalmente, ele aponta para um arquivo de credenciais e implicitamente usa a LAPI local. Precisamos adicionar explicitamente a URL da LAPI remota. O bloco relevante ficará assim:

api:
  client:
    credentials_path: /etc/crowdsec/local_api_credentials.yaml
    insecure_skip_verify: true
  server:
    # Desabilitar o servidor LAPI local, pois usaremos a LAPI remota
    enable: false

A configuração acima faz três coisas importantes. Primeiro, mantém o caminho do arquivo de credenciais em credentials_path (ainda precisamos dele). Segundo, adiciona insecure_skip_verify: true — isso é necessário porque estamos usando HTTP (sem TLS) para a comunicação com a LAPI neste ambiente de teste; se você configurou TLS na LAPI, esta linha pode ser removida ou ajustada para apontar para o certificado CA. Terceiro, desabilita o servidor LAPI local com enable: false, evitando que o serviço tente escutar na porta 8080 localmente e causando conflitos desnecessários. Se você não desabilitar o servidor local, a instância funcionará como standalone além de cliente, o que pode ser desejado em alguns cenários, mas para nosso exercício de centralização pura, desabilitamos.

Agora vamos editar o arquivo de credenciais. É nele que informamos a URL da LAPI remota e as credenciais de autenticação. O arquivo /etc/crowdsec/local_api_credentials.yaml é lido pelo agente para saber onde e como se autenticar.

# 4. Editar o arquivo de credenciais da API local
sudo nano /etc/crowdsec/local_api_credentials.yaml

Substitua o conteúdo pelo seguinte (ajustando os valores para o seu ambiente):

url: http://10.0.0.10:8080
login: web2
password: a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

Cada linha deste arquivo é crítica. O campo url deve conter o endereço completo da LAPI central, incluindo o protocolo (http:// ou https://) e a porta (8080). Substitua 10.0.0.10 pelo IP real do seu servidor LAPI. O campo login deve corresponder exatamente ao nome da máquina que você criou com cscli machines add no servidor LAPI (no exemplo, web2). O campo password deve ser a senha longa que foi exibida no terminal do servidor LAPI quando você executou o comando cscli machines add. Copie-a exatamente como foi gerada — ela é case-sensitive e não contém espaços.

Após salvar os dois arquivos, reinicie o serviço CrowdSec no servidor cliente e verifique os logs para confirmar que a conexão foi estabelecida com sucesso.

# 5. Reiniciar o CrowdSec no servidor cliente
sudo systemctl restart crowdsec

# 6. Verificar o status do serviço
sudo systemctl status crowdsec

# 7. Verificar os logs para confirmar a conexão com a LAPI remota
sudo journalctl -u crowdsec -n 30 --no-pager

Nos logs, procure por linhas que indiquem conexão bem-sucedida com a LAPI remota. A saída esperada deve incluir algo como:

Jul 31 10:25:11 web2 crowdsec[12560]: Starting CrowdSec v1.6.0
Jul 31 10:25:11 web2 crowdsec[12560]: Connecting to API server at http://10.0.0.10:8080
Jul 31 10:25:11 web2 crowdsec[12560]: Successfully connected to API server
Jul 31 10:25:11 web2 crowdsec[12560]: Agent registered successfully
Jul 31 10:25:11 web2 crowdsec[12560]: Starting processing logs
Jul 31 10:25:11 web2 crowdsec[12560]: Pushing metrics to central API

Se você vir mensagens de erro como “connection refused”, “authentication failed” ou “no such host”, não se preocupe — a seção de erros comuns no final desta aula cobre cada uma dessas situações e fornece a solução exata. Por ora, prossiga com a verificação no servidor LAPI para confirmar que o cliente agora aparece como ativo.

# DE VOLTA AO SERVIDOR LAPI, verifique a lista de máquinas:
sudo cscli machines list

----------------------------------------------------------------------------------------------------
 NAME          IP ADDRESS    LAST UPDATE           STATUS          VERSION          AUTH TYPE
----------------------------------------------------------------------------------------------------
 lapi-server   127.0.0.1    2026-07-31T10:15:22Z  active          v1.6.0          password
 web2          10.0.0.20    2026-07-31T10:25:11Z  active          v1.6.0          password
 db1           -             -                     pending         -               password
----------------------------------------------------------------------------------------------------

Observe que web2 agora mostra o endereço IP 10.0.0.20, o status mudou para active e as colunas de versão e auth type estão preenchidas. Isso confirma que o cliente se conectou com sucesso e está enviando métricas e alertas para a LAPI central. O mesmo processo deve ser repetido para todos os servidores clientes restantes (db1, mail1, etc.).

Inscrevendo sua Infraestrutura no Console Web do CrowdSec

Até agora, temos o gerenciamento centralizado funcionando dentro da nossa rede — múltiplos agentes reportando a uma LAPI central. Mas o verdadeiro salto de visibilidade e conveniência vem quando conectamos essa LAPI ao Console Web do CrowdSec. Este console, acessível em https://app.crowdsec.net, oferece um dashboard unificado com gráficos de atividade, listas de alertas com detalhes completos, gestão de decisões (com capacidade de adicionar/remover bloqueios manualmente) e visão consolidada de todas as suas máquinas. É uma ferramenta que muda completamente o jogo em comparação com ficar fazendo cscli decisions list em cada servidor individualmente.

O processo de inscrição (enrollment) é notavelmente simples e leva menos de dois minutos. Você precisará de uma conta no Console Web — se ainda não criou, acesse https://app.crowdsec.net e faça seu cadastro gratuito. O plano Community é generoso e permite gerenciar múltiplas instâncias sem custo, sendo suficiente para a maioria dos ambientes de pequeno e médio porte. Após fazer login no console, navegue até a seção “Engines” ou “Add Engine” (a interface pode variar ligeiramente conforme atualizações, mas o fluxo é consistente).

No painel do Console Web, você encontrará um comando pronto para ser executado no seu servidor LAPI. Este comando contém uma chave de inscrição (enrollment key) única que vincula sua LAPI à sua conta no console. O comando típico segue o formato cscli console enroll <chave>. Não tente adivinhar a chave — ela é gerada dinamicamente pelo console e é válida por tempo limitado. Copie o comando exatamente como exibido na interface web e execute-o no servidor LAPI (não nos clientes).

# NO SERVIDOR LAPI, execute o comando de enrollment (exemplo com chave fictícia):
# A chave real será fornecida pelo Console Web no seu navegador
sudo cscli console enroll ccs-abc123def456ghi789jkl012mno345pqr678stu901vwx234yz

# Saída esperada:
# INFO[0000] Enrollment successful
# INFO[0000] Your LAPI is now connected to the CrowdSec Console
# INFO[0000] You can view your dashboard at https://app.crowdsec.net

INFO[0000] Enrollment successful                        
INFO[0000] Your LAPI is now connected to the CrowdSec Console
INFO[0000] You can view your dashboard at https://app.crowdsec.net
INFO[0000] Sharing signals with the CrowdSec community is enabled (can be disabled in the Console)

Após o enrollment bem-sucedido, o serviço CrowdSec na LAPI estabelecerá uma conexão WebSocket persistente com os servidores do Console (api.crowdsec.net). Essa conexão é usada para enviar métricas, alertas e decisões em tempo real, além de receber comandos quando você interage com o console (como adicionar uma decisão manual de bloqueio). Não é necessário abrir portas inbound no firewall da LAPI para isso — a conexão é outbound, originada do seu servidor para a nuvem, similar ao funcionamento de um agente de monitoramento.

Para verificar se a conexão com o console está ativa, utilize o comando cscli console status. Ele exibirá o estado da conexão, o ID da sua organização no console e estatísticas de envio de sinais.

# Verificar o status da conexão com o Console Web
sudo cscli console status

------------------------------------------------------------------------------------------
 CONSOLE STATUS
------------------------------------------------------------------------------------------
 Status:          connected
 Organization:    Minha Empresa (org_abc123)
 Plan:            Community
 Signals sent:    1,245
 Last push:       2026-07-31 10:30:45 UTC
 Engine ID:       engine_def456
------------------------------------------------------------------------------------------
 Enrollment:      completed
 Sharing:         enabled
------------------------------------------------------------------------------------------

Com o status exibindo “connected”, você já pode abrir o navegador, acessar https://app.crowdsec.net e começar a explorar o dashboard. Leva alguns minutos para os primeiros dados aparecerem, especialmente se seus servidores ainda não detectaram ataques recentes. Na próxima seção, faremos um tour guiado pelas principais seções do console e mostraremos como interpretar as informações.

Explorando o Console Web do CrowdSec — Tour Guiado

Agora que sua infraestrutura está conectada ao Console Web, vamos explorar as seções mais importantes do dashboard e entender como extrair o máximo de valor dele no seu dia a dia. Esta seção é baseada na experiência prática que acumulamos na JRT Technology Solutions gerenciando ambientes de produção com múltiplos servidores. Vamos navegar da visão macro (overview) até os detalhes granulares (alertas e decisões individuais), sempre com foco em ações práticas que você pode tomar imediatamente.

A primeira tela que você verá ao fazer login é o Dashboard Principal (Overview). Este painel oferece uma visão consolidada de toda a sua frota: número total de máquinas ativas, quantidade de alertas nas últimas 24 horas, IPs bloqueados atualmente (decisões ativas), top 5 de cenários mais acionados e um gráfico de linha do tempo mostrando o volume de eventos ao longo das horas. É a tela que recomendamos abrir logo pela manhã para ter um panorama rápido da noite anterior. Se você vir um pico repentino em um determinado horário, pode clicar no gráfico para fazer drill-down e investigar o que aconteceu.

A segunda seção crucial é “Alerts” (Alertas). Aqui, cada linha representa um alerta gerado por um cenário do CrowdSec em alguma das suas máquinas. As colunas mostram: o IP de origem do ataque, o cenário que foi disparado (ex: crowdsecurity/ssh-bf), a máquina onde ocorreu, o timestamp e a gravidade. Clicando em qualquer alerta, você abre um painel lateral com detalhes completos: o log bruto que gerou o alerta, metadados do IP (geolocalização, ASN, reputação), e a ação tomada (decisão de bloqueio, duração, tipo). Esta granularidade é algo que simplesmente não existe no ecossistema fail2ban — lá, você precisaria caçar logs manualmente em cada servidor.

A terceira seção é “Decisions” (Decisões), que lista todos os bloqueios ativos e expirados. Você pode filtrar por tipo (ban, captcha, throttle), por origem (cenário, manual, comunidade) e por escopo (IP, range, username). Uma funcionalidade extremamente útil é a capacidade de adicionar decisões manualmente diretamente do console: se você identificar um IP suspeito durante uma investigação, pode bloqueá-lo em toda a sua frota com alguns cliques, sem precisar acessar nenhum servidor via SSH. Da mesma forma, pode remover um bloqueio incorreto (whitelist) igualmente rápido. Essa capacidade de resposta centralizada reduz o tempo de mitigação de minutos para segundos.

A quarta seção importante é “Machines” (Máquinas), onde você vê a lista completa de instâncias conectadas à sua organização. Para cada máquina, são exibidos: nome, endereço IP, versão do CrowdSec, data do último heartbeat e quantidade de alertas gerados. Um indicador verde mostra que a máquina está online e comunicando; um indicador cinza/vermelho sugere que ela está offline há algum tempo. Esta tela substitui completamente a necessidade de fazer cscli machines list em cada LAPI — tudo está consolidado em um único lugar, com a vantagem adicional de ser acessível do seu celular ou tablet, o que é inestimável quando você está de plantão e precisa verificar rapidamente se todos os servidores estão protegidos.

Por fim, a seção “Settings” (Configurações) permite gerenciar aspectos como: habilitar/desabilitar o compartilhamento de sinais com a comunidade, configurar alertas por e-mail (para ser notificado quando um novo IP for bloqueado), gerenciar chaves de API para integrações externas e visualizar o histórico de atividades da sua conta. Recomendamos fortemente ativar as notificações por e-mail — assim, mesmo sem abrir o console, você recebe um resumo diário ou alertas em tempo real (dependendo da configuração) sobre a atividade de segurança na sua infraestrutura.

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

Nenhuma implantação está completa sem uma bateria de verificações que confirmem que tudo está funcionando ponta a ponta. Nesta seção, executaremos comandos de diagnóstico tanto no servidor LAPI quanto em um cliente, e simularemos um ataque controlado para ver o fluxo completo: detecção no cliente, reporte à LAPI, distribuição de decisão, visibilidade no console e bloqueio efetivo no cliente. Esta verificação é o que diferencia uma configuração