Chegamos à aula final do curso Firewall, fail2ban e CrowdSec — Do Zero ao Avançado. Ao longo de 24 aulas, você aprendeu a planejar, instalar, configurar e operar três camadas fundamentais de proteção para servidores e redes: o firewall de borda e de host, o sistema de reação ativa fail2ban e a plataforma colaborativa e moderna CrowdSec. Nesta Aula 25, vamos consolidar todo esse conhecimento com uma disciplina que separa administradores medianos de profissionais de segurança maduros: a auditoria de segurança. Aqui, o objetivo não é adicionar novas regras ou configurar novos componentes, mas sim revisar, validar, documentar e extrair inteligência do que já está em produção.
A auditoria de segurança é um processo contínuo e sistemático de verificação da eficácia das defesas implementadas. Quando você configura um firewall, um conjunto de jails do fail2ban ou os cenários e bounceadores do CrowdSec, cada regra e cada parâmetro representa uma decisão de segurança. Com o passar do tempo, ambientes mudam, aplicações são atualizadas, novos serviços entram no ar e, principalmente, incidentes acontecem. Sem auditoria, você corre o risco de acumular regras obsoletas, contrapor políticas de bloqueio, manter logs sem análise e, o pior, acreditar que está protegido quando na verdade há brechas abertas. Revisar regras, correlacionar logs e documentar incidentes é o que garante que as camadas de defesa continuem alinhadas com a realidade operacional do ambiente.
Nesta aula, você vai aprender a conduzir uma auditoria de segurança completa em servidores Linux, cobrindo os três pilares do curso. Vamos começar pelos fundamentos conceituais: o que auditar, como estabelecer um baseline e como classificar incidentes. Em seguida, vamos executar procedimentos práticos de auditoria das regras de firewall, das jails e filtros do fail2ban e das decisões, cenários e bounceadores do CrowdSec. Você vai criar um script automatizado de auditoria, testá-lo e aprender a interpretar os resultados. Por fim, abordaremos os erros mais comuns nesse tipo de revisão e as boas práticas para manter um programa de auditoria contínuo e eficaz.
Os pré-requisitos para esta aula são diretos: você deve ter um servidor Linux com Ubuntu 22.04/24.04 LTS ou Debian 12, ou alternativamente CentOS Stream 9, RHEL 9 ou Rocky Linux 9, com os três componentes já instalados e em funcionamento conforme as aulas anteriores. É fundamental que você tenha acesso root ou privilégios de sudo, pois a leitura de logs de segurança e a execução de comandos de verificação exigem permissões elevadas. Também é recomendável ter os logs do sistema minimamente centralizados ou acessíveis via journalctl e arquivos em /var/log.
Ao concluir esta aula e, portanto, o curso completo, você será capaz de: realizar uma auditoria completa das regras de firewall ativas e salvas; revisar a efetividade das jails do fail2ban, incluindo filtros, ações e histórico de banimentos; analisar as métricas e decisões do CrowdSec; gerar relatórios automatizados de auditoria; interpretar incidentes e transformar logs em insights acionáveis; e documentar todo o processo para auditorias futuras e conformidade. Em nossos projetos na JRT Technology Solutions, nossos especialistas utilizam diariamente essas práticas para garantir que ambientes de clientes permaneçam seguros, auditáveis e resilientes. Vamos começar.
O que você vai aprender nesta aula
- Conceitos fundamentais de auditoria de segurança: baseline, revisão de regras, análise de logs e classificação de incidentes.
- Como auditar regras de firewall no iptables, nftables e firewalld, identificando regras obsoletas, duplicadas ou sem contadores.
- Como revisar a configuração do fail2ban: jails, filtros, ações, limites de tentativas e histórico de banimentos.
- Como auditar o CrowdSec: métricas, listas de decisões, cenários ativos, bounceadores e alertas.
- Como criar e executar um script de auditoria automática que gera um relatório consolidado.
- Como verificar se a auditoria está correta e como resolver os erros mais comuns durante o processo.
- Boas práticas para manter um programa de auditoria contínua, documentar incidentes e otimizar as defesas.
- Encerramento do curso com resumo geral, referência rápida de comandos e próximos passos de carreira.
Pré-requisitos e Ambiente
Antes de iniciar a auditoria de segurança, certifique-se de que o ambiente atenda aos seguintes requisitos. Primeiro, um servidor Linux com um dos sistemas operacionais suportados pelo curso. Para famílias Debian, utilizamos Ubuntu 22.04 LTS, Ubuntu 24.04 LTS ou Debian 12. Para famílias Red Hat, utilizamos CentOS Stream 9, RHEL 9 ou Rocky Linux 9. O firewall deve estar ativo: no Ubuntu/Debian, recomendamos iptables ou nftables; no CentOS/RHEL/Rocky, o padrão é firewalld. O fail2ban deve estar instalado e com pelo menos duas jails ativas (por exemplo, sshd e apache-auth). O CrowdSec deve estar instalado, com o agente crowdsec e o bouncer de firewall ativos.
Além dos componentes, é necessário ter acesso a logs do sistema. No Ubuntu/Debian, o journalctl centraliza a maioria dos logs, mas o fail2ban também grava em /var/log/fail2ban.log por padrão. No CentOS/RHEL/Rocky, o journalctl é a fonte principal, e o fail2ban pode gravar no mesmo arquivo ou via journal. Verifique se o pacote rsyslog ou systemd-journald está configurado para persistir logs em disco; isso é essencial para auditoria histórica. No Ubuntu, edite /etc/systemd/journald.conf e defina Storage=persistent. No CentOS/RHEL/Rocky, o mesmo parâmetro se aplica. Após alterar, reinicie o serviço com systemctl restart systemd-journald.
Você também precisará de ferramentas básicas de manipulação de texto e rede, que já vêm instaladas na maioria das distribuições: grep, awk, sed, sort, uniq, wc, diff, tar e curl. Em distribuições mínimas, instale com apt install coreutils grep gawk sed diffutils tar curl no Debian/Ubuntu ou dnf install coreutils grep gawk sed diffutils tar curl no CentOS/RHEL/Rocky. Para o script de auditoria, vamos usar apenas shell padrão (bash), sem dependências externas, garantindo portabilidade entre as famílias de sistemas.
Organize um diretório de trabalho para a auditoria. Recomendamos criar /opt/security-audit para armazenar scripts, baselines e relatórios. Execute mkdir -p /opt/security-audit/{scripts,baselines,reports} como root. Esse diretório será usado ao longo de toda a aula. Por fim, tenha em mente que a auditoria deve ser executada em um momento de baixa movimentação de tráfego, se possível, para minimizar impacto nos serviços e facilitar a interpretação dos contadores de regras. Em nossos projetos na JRT Technology Solutions, sempre agendamos auditorias em janelas de manutenção ou em horários de menor pico, justamente para garantir dados consistentes.
Fundamentos da auditoria de segurança
A auditoria de segurança em infraestrutura de firewall, fail2ban e CrowdSec se apoia em três pilares: revisão de regras, análise de logs e tratamento de incidentes. A revisão de regras consiste em inspecionar cada política configurada, verificar sua ordem de processamento, identificar regras redundantes, obsoletas ou conflitantes e comparar o estado atual com um baseline previamente aprovado. O baseline é um snapshot do conjunto de regras e configurações que foi validado e documentado em um determinado momento. Sem ele, a auditoria perde o referencial: você pode saber que algo mudou, mas não saber se a mudança é legítima ou maliciosa.
A análise de logs é o processo de coletar, normalizar e correlacionar eventos gerados pelo kernel (via netfilter), pelo fail2ban e pelo CrowdSec. Aqui, o objetivo não é apenas observar que houve tentativas de ataque, mas entender padrões: de onde vêm as tentativas, quais serviços são mais visados, quais jails estão bloqueando efetivamente e quais cenários do CrowdSec estão gerando mais decisões. Logs são a matéria-prima da auditoria de segurança. Sem eles, você não consegue medir a eficácia das suas defesas nem justificar mudanças de configuração. Por isso, a persistência e a centralização de logs são pré-requisitos tão importantes.
O tratamento de incidentes fecha o ciclo: quando a auditoria identifica um evento relevante — como um pico de banimentos do fail2ban, uma decisão do CrowdSec para um IP interno inesperado ou uma regra de firewall que foi removida sem justificativa — é necessário classificar a severidade, documentar o ocorrido, conter a ameaça se for o caso e, por fim, atualizar o baseline. Um incidente bem documentado se torna uma lição aprendida e alimenta a melhoria contínua das defesas. Uma auditoria de segurança sem esse ciclo de feedback é apenas uma coleta de dados sem propósito.
Na prática, a auditoria pode ser manual (executando comandos e analisando saídas) ou automatizada (via scripts e agendamento no cron). Nesta aula, vamos combinar as duas abordagens: primeiro você executará comandos individualmente para entender o que cada um revela; depois, consolidaremos tudo em um script que gera um relatório completo. Essa progressão didática garante que você não apenas rode ferramentas, mas saiba interpretar cada resultado criticamente. Lembre-se: o valor da auditoria está na análise humana, não apenas na coleta automatizada.
Para organizar o trabalho, sugerimos adotar uma matriz de auditoria simples, dividida em três áreas: Firewall (regras ativas, persistência, contadores, regras órfãs), fail2ban (jails ativas, filtros, ações, histórico de banimentos, efetividade) e CrowdSec (métricas, decisões, cenários, bounceadores, alertas). Em cada área, você deve verificar: o que está configurado, o que está em uso, o que está obsoleto, o que está gerando eventos e o que precisa de ajuste. Essa matriz será a espinha dorsal do script de auditoria que criaremos mais adiante.
Passo a passo — Auditoria de segurança das regras de firewall
A primeira etapa prática da auditoria de segurança é revisar as regras do firewall. Dependendo da família de sistema, você usará comandos diferentes. No Ubuntu/Debian, se estiver usando iptables, o comando base é iptables -L -n -v –line-numbers. As opções -L listam as regras, -n evita resolução reversa de DNS (mais rápido e seguro), -v exibe contadores de pacotes e bytes, e –line-numbers mostra a posição de cada regra na cadeia. Essa posição é crucial porque as regras são processadas de cima para baixo, e uma regra na posição errada pode anular outra. Se estiver usando nftables, o comando equivalente é nft list ruleset, que exibe todas as tabelas e cadeias em formato estruturado.
No CentOS/RHEL/Rocky, o firewall padrão é o firewalld, que abstrai as regras em zonas e serviços. Para auditar, comece com firewall-cmd –list-all-zones para ver todas as zonas e suas configurações, e depois firewall-cmd –list-all –zone=public para detalhar a zona ativa. O parâmetro –list-all exibe portas abertas, serviços permitidos, interfaces vinculadas, regras ricas (rich rules), encaminhamentos e máscaras. Para inspecionar as regras ricas, use firewall-cmd –list-rich-rules. Essas regras são as mais importantes de auditar, pois contêm lógica condicional avançada que pode esconder brechas.
Vamos executar uma auditoria completa passo a passo. Primeiro, crie um snapshot do estado atual das regras. No Ubuntu/Debian com iptables, execute iptables-save > /opt/security-audit/baselines/iptables-baseline-$(date +%Y%m%d).conf. No CentOS/RHEL/Rocky, salve as regras permanentes do firewalld com firewall-cmd –runtime-to-permanent após garantir que o estado atual é o desejado, e depois copie os arquivos de zona de /etc/firewalld/zones/ para o diretório de baseline. Esse snapshot servirá como referência para comparações futuras. Sempre revise o conteúdo salvo com cat ou less para confirmar que não há erros de sintaxe.
Em seguida, liste as regras ativas com contadores. No Ubuntu/Debian, execute iptables -L -n -v –line-numbers para as cadeias padrão (INPUT, FORWARD, OUTPUT). Preste atenção às colunas pkts e bytes. Regras com contadores zerados por longos períodos podem indicar que não estão sendo utilizadas — talvez porque a condição nunca é satisfeita ou porque o tráfego esperado não existe. Regras duplicadas (mesma regra aparecendo duas vezes) devem ser removidas, pois não agregam segurança e aumentam a superfície de manutenção. Regras obsoletas (por exemplo, liberando porta de um serviço que já foi descontinuado) são um risco silencioso.
Para identificar regras obsoletas ou redundantes, uma técnica eficaz é ordenar as regras por número de pacotes. No iptables, o comando iptables -L INPUT -n -v –line-numbers | sort -k1 -n pode ajudar, embora a ordenação exata dependa do formato. Uma alternativa mais robusta é salvar a listagem em um arquivo e analisá-la manualmente ou com grep. Por exemplo, para listar apenas as regras da cadeia INPUT que liberam portas TCP, use iptables -L INPUT -n -v –line-numbers | grep “tcp dpt”. Cada regra listada deve ser justificável: se você não sabe por que uma porta está aberta, provavelmente ela não deveria estar.
Agora, o procedimento completo no Ubuntu/Debian com iptables:
# 1. Criar diretório de baselines (se ainda não existir)
mkdir -p /opt/security-audit/baselines
# 2. Salvar snapshot atual das regras
iptables-save > /opt/security-audit/baselines/iptables-baseline-$(date +%Y%m%d).conf
# 3. Listar todas as regras com contadores e números de linha
iptables -L -n -v --line-numbers
# 4. Listar apenas a cadeia INPUT
iptables -L INPUT -n -v --line-numbers
# 5. Verificar regras TCP na cadeia INPUT
iptables -L INPUT -n -v --line-numbers | grep "tcp dpt"
# 6. Comparar com baseline anterior (se existir)
ls -la /opt/security-audit/baselines/
diff /opt/security-audit/baselines/iptables-baseline-YYYYMMDD.conf /opt/security-audit/baselines/iptables-baseline-$(date +%Y%m%d).confA saída esperada do passo 3, em um servidor típico com regras básicas de proteção, será semelhante a esta:
Chain INPUT (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 1523 110K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
2 8542 1.2M ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
3 3210 890K ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
4 1098 345K ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
5 451 12K DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:23
6 0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 45 packets, 5400 bytes)
num pkts bytes target prot opt in out source destinationObserve que a regra número 6, que libera UDP na porta 53, tem contadores zerados. Isso pode indicar que não há tráfego DNS passando por essa interface ou que a regra é desnecessária. Em uma auditoria, você questionaria essa regra: ela ainda é necessária? Se não, remova-a para reduzir a superfície de ataque. No CentOS/RHEL/Rocky, o comando equivalente para listar com detalhes e contadores é firewall-cmd –list-all –zone=public; para ver as regras ricas, execute firewall-cmd –list-rich-rules.
Para auditar a persistência das regras, verifique se as configurações sobrevivem a um reboot. No Ubuntu/Debian, o iptables não salva regras automaticamente; você precisa do pacote iptables-persistent ou do netfilter-persistent. Verifique com systemctl status netfilter-persistent. Se o serviço não estiver ativo, suas regras atuais serão perdidas após reinicialização. No CentOS/RHEL/Rocky, o firewalld salva as regras permanentes em /etc/firewalld/zones/, e o comando firewall-cmd –reload recarrega sem interromper conexões. Audite sempre se as regras permanentes correspondem às ativas: use firewall-cmd –list-all –permanent e compare com firewall-cmd –list-all.
Passo a passo — Auditoria de segurança do fail2ban
A segunda área da auditoria de segurança é o fail2ban. O primeiro comando a executar é fail2ban-client status, que lista todas as jails configuradas e quantos IPs estão atualmente banidos em cada uma. Em um servidor bem configurado, você verá jails como sshd, apache-auth, nginx-limit-req ou recidive. Se uma jail esperada não aparecer, algo está errado: pode ser que ela não esteja habilitada no arquivo jail.local, que o filtro não esteja casando as linhas de log, ou que o backend de log não esteja lendo os arquivos corretos.
Em seguida, detalhe cada jail individualmente com fail2ban-client get <jail> banned para ver os IPs banidos, fail2ban-client get <jail> findtime para saber a janela de tempo considerada, e fail2ban-client get <jail> maxretry para ver o número de tentativas permitidas antes do banimento. Compare esses valores com a política de segurança do ambiente. Por exemplo, um maxretry muito alto (como 20) pode permitir ataques de força bruta prolongados; um valor muito baixo (como 2) pode gerar falsos positivos e bloquear usuários legítimos. A auditoria deve validar se esses parâmetros estão equilibrados.
Para revisar os filtros, liste os arquivos em /etc/fail2ban/filter.d/ e inspecione cada um com cat ou less. Um filtro é composto por expressões regulares que o fail2ban usa para identificar falhas de autenticação nos logs. Se um filtro não estiver casando, a jail não banirá ninguém. Para testar a eficácia de um filtro contra um arquivo de log real, use o comando fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf. A saída exibirá quantas linhas corresponderam, quantas falhas foram identificadas e os endereços IP extraídos. Esse é um passo essencial em qualquer auditoria de segurança do fail2ban.
Outro ponto crítico é revisar as ações configuradas. No arquivo /etc/fail2ban/jail.local, verifique a diretiva action de cada jail. A ação padrão geralmente é %(action_)s, que chama o script iptables-multiport para adicionar regras de bloqueio. No CentOS/RHEL/Rocky, você pode usar firewallcmd-rich-rules ou firewallcmd-ipset. Audite se as ações estão corretas para o seu firewall: se o fail2ban está configurado para usar iptables, mas o firewall ativo é firewalld, os banimentos podem não funcionar. Verifique também se há ações de notificação, como e-mail ou webhook, e se elas estão funcionando.
O histórico de banimentos fica registrado em /var/log/fail2ban.log. Analise-o com comandos como grep “Ban ” /var/log/fail2ban.log | tail -50 para ver os últimos banimentos, ou grep “Unban” /var/log/fail2ban.log | tail -50 para ver os desbanimentos. Use awk ‘{print $NF}’ /var/log/fail2ban.log | grep -Eo ‘([0-9]{1,3}\.){3}[0-9]{1,3}’ | sort | uniq -c | sort -rn | head para extrair os IPs mais banidos, o que revela fontes de ataque recorrentes. Esses IPs podem ser candidatos a banimentos permanentes no firewall ou a inclusão em listas de bloqueio do CrowdSec.
Procedimento completo de auditoria do fail2ban:
# 1. Verificar status geral e jails ativas
fail2ban-client status
# 2. Detalhar uma jail específica (exemplo: sshd)
fail2ban-client status sshd
# 3. Listar IPs banidos na jail sshd
fail2ban-client get sshd banned
# 4. Ver parâmetros da jail sshd
fail2ban-client get sshd findtime
fail2ban-client get sshd maxretry
# 5. Testar filtro sshd contra o log de autenticação
fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf
# 6. Analisar histórico de banimentos (últimos 50)
grep "Ban " /var/log/fail2ban.log | tail -50
# 7. Top 10 IPs mais banidos
awk '{print $NF}' /var/log/fail2ban.log | grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}' | sort | uniq -c | sort -rn | headA saída do passo 1 deve mostrar as jails ativas e o número de IPs banidos:
Status
|- Number of jail: 3
`- Jail list: sshd, apache-auth, recidiveA saída do passo 2 detalha a jail sshd com seus filtros, ações e estatísticas:
Status for the jail: sshd
|- Filter
| |- Currently failed: 2
| `- Total failed: 124
`- Actions
|- Currently banned: 5
|- Total banned: 47
`- Banned IP list: 203.0.113.45 198.51.100.23 192.0.2.10 203.0.113.88 198.51.100.99No passo 3, a lista de IPs banidos na jail sshd será exibida um por linha. O passo 5, o teste do filtro, é o mais importante: ele valida se as expressões regulares estão casando corretamente. Se a taxa de correspondência for zero, o filtro está desatualizado para o formato de log atual do serviço. Nesse caso, você deve revisar o arquivo /etc/fail2ban/filter.d/sshd.conf e ajustar as expressões regulares, ou atualizar o fail2ban para uma versão que suporte o formato. Documente qualquer alteração no briefing da auditoria.
No CentOS/RHEL/Rocky, os comandos são os mesmos, mas o caminho do log de autenticação pode ser /var/log/secure em vez de /var/log/auth.log. Verifique com ls -la /var/log/secure e ajuste o comando de teste do filtro adequadamente. Além disso, o fail2ban pode estar configurado para usar systemd como backend, lendo os logs diretamente do journal. Nesse caso, o teste com arquivo ainda é válido se você extrair os logs relevantes do journal com journalctl -u sshd -o cat > /tmp/sshd.log e depois executar o fail2ban-regex nesse arquivo temporário.
Passo a passo — Auditoria de segurança do CrowdSec
O terceiro pilar da auditoria de segurança é o CrowdSec. Diferente do fail2ban, que reage a falhas locais, o CrowdSec é uma plataforma colaborativa que analisa logs, aplica cenários de detecção e compartilha inteligência de ameaças com a comunidade. Para auditar o CrowdSec, comece com cscli hub list, que mostra todos os itens instalados (parsers, cenários, coleções) e seus status. Itens com status enabled estão ativos; itens disabled ou pending podem exigir atualização ou revisão. Verifique também a versão do agente com cscli version e o status do serviço com systemctl status crowdsec.
Em seguida, consulte as métricas gerais com cscli metrics. Esse comando exibe um resumo estatístico: número de decisões ativas, de alertas, de aquisições, de logs processados por minuto, entre outros. As métricas são uma janela para a eficácia do CrowdSec no seu ambiente. Se o número de logs processados é zero, o agente pode não estar lendo os fluxos de logs configurados; se há muitas aquisições, os parsers podem não estar cobrindo todos os formatos. Uma auditoria de segurança do CrowdSec deve analisar essas métricas criticamente.
Para revisar as decisões de bloqueio, execute cscli decisions list. Esse comando lista todas as decisões ativas, incluindo IP, duração, cenário que originou, tipo (ban, captcha) e bounceador responsável. Decisões antigas ou de longa duração sem justificativa devem ser questionadas; decisões contra IPs internos podem indicar falsos positivos ou ataques internos. Verifique também os alertas gerados com cscli alerts list, que mostram eventos que dispararam cenários. Cada alerta contém metadados ricos: IP de origem, cenário, serviço afetado e timestamp. Esses alertas são a base para a análise de incidentes.
A auditoria dos cenários é feita com cscli scenarios list, que lista os cenários instalados e seus status. Cada cenário tem uma descrição e parâmetros como leakspeed (velocidade de vazamento de decisões) e capacity (capacidade máxima de eventos). Cenários desatualizados ou mal configurados podem gerar falsos positivos ou deixar de detectar ataques. Para ver a configuração detalhada de um cenário, use cscli scenarios inspect <nome>. O mesmo vale para parsers: cscli parsers list e cscli parsers inspect <nome>. Revise especialmente os parsers de logs de serviços que você utiliza, como sshd, apache2, nginx e mysql.
Os bounceadores ativos são verificados com cscli bouncers list. Um bounceador é o componente que aplica as decisões do CrowdSec no firewall ou em outras camadas. Se não houver bounceador listado, as decisões do CrowdSec não estão sendo aplicadas — um problema grave de segurança. Verifique o status do bounceador com systemctl status crowdsec-firewall-bouncer (no caso do bouncer de firewall). Se você usa o bouncer do iptables ou nftables, revise as regras que ele insere: o bouncer cria uma cadeia própria (geralmente crowdsec) e adiciona regras de salto. Audite essa cadeia para garantir que as decisões estão sendo aplicadas na ordem correta.
Procedimento completo de auditoria do CrowdSec:
# 1. Verificar status do serviço e versão
systemctl status crowdsec
cscli version
# 2. Listar itens do hub (parsers, cenários, coleções)
cscli hub list
# 3. Exibir métricas gerais
cscli metrics
# 4. Listar decisões ativas
cscli decisions list
# 5. Listar alertas recentes
cscli alerts list
# 6. Listar cenários ativos
cscli scenarios list
# 7. Listar bounceadores registrados
cscli bouncers list
# 8. Inspecionar um cenário específico (exemplo: crowdsecurity/ssh-bf)
cscli scenarios inspect crowdsecurity/ssh-bfA saída do passo 3, cscli metrics, é essencial para avaliar a saúde do agente:
INFO[0000] Acquisition Metrics:
INFO[0000] - /var/log/auth.log: 18.24 lines/sec
INFO[0000] - /var/log/apache2/access.log: 45.02 lines/sec
INFO[0000] Parser Metrics:
INFO[0000] - crowdsecurity/syslog-logs: 12.30 hits/sec
INFO[0000] - crowdsecurity/sshd-logs: 3.10 hits/sec
INFO[0000] Scenario Metrics:
INFO[0000] - crowdsecurity/ssh-bf: 0.05 hits/sec
INFO[0000] - crowdsecurity/http-bf: 0.02 hits/sec
INFO[0000] Overall Metrics:
INFO[0000] - Active Decisions: 28
INFO[0000] - Total Alerts: 156
INFO[0000] - Processed Lines: 2,456,789A saída do passo 4, cscli decisions list, mostra as decisões ativas de bloqueio:
+--------------+---------------+----------------+----------------+-------------+--------+----------------------------+
| ID | SOURCE | SCOPE:VALUE | REASON | ACTION | EXPIRATION | CREATED AT |
+--------------+---------------+----------------+----------------+-------------+--------+----------------------------+
| 123456 | cscli | Ip:203.0.113.45| manual | ban | 3h59m59s | 2026-09-22 10:15:00 +0000 |
| 123457 | crowdsec | Ip:198.51.100.7| crowdsecurity | ban | 1h59m59s | 2026-09-22 11:30:00 +0000 |
| 123458 | crowdsec | Ip:192.0.2.200| crowdsecurity | ban | 45m00s | 2026-09-22 12:00:00 +0000 |
+--------------+---------------+----------------+----------------+-------------+--------+----------------------------+Observe a coluna REASON: decisões com motivo manual foram inseridas por um administrador via cscli decisions add. Decisões com motivo de cenário (ex.: crowdsecurity/ssh-bf) foram geradas automaticamente pela detecção. Durante a auditoria, verifique se decisões manuais antigas ainda são necessárias. Remova as expiradas ou desnecessárias com cscli decisions delete <ID>. Para listar decisões por IP específico, use cscli decisions list –ip <IP>; para filtrar por cenário, use cscli decisions list –scenario <nome>.
No CentOS/RHEL/Rocky, os comandos do CrowdSec são idênticos, pois o binário cscli é o mesmo independentemente da distribuição. A única diferença é o gerenciador de pacotes para instalação (dnf em vez de apt) e o caminho dos logs, que pode ser /var/log/secure em vez de /var/log/auth.log. Certifique-se de que o arquivo de aquisição do CrowdSec (/etc/crowdsec/acquis.yaml) está apontando para os caminhos corretos. Inspecione-o com cat /etc/crowdsec/acquis.yaml e verifique cada entrada de fonte de log.
Script completo de auditoria de segurança
Para automatizar e padronizar a auditoria de segurança, vamos criar um script shell completo que coleta informações dos três componentes e gera um relatório consolidado. O script foi projetado para funcionar tanto em Ubuntu/Debian quanto em CentOS/RHEL/Rocky, detectando automaticamente o firewall ativo e ajustando os comandos. Salve o arquivo como /opt/security-audit/scripts/security-audit.sh e torne-o executável com chmod +x /opt/security-audit/scripts/security-audit.sh. Abaixo está o conteúdo completo, comentado linha por linha:
#!/bin/bash
# =====================================================================
# security-audit.sh — Auditoria de segurança para Firewall, fail2ban e CrowdSec
# Compatível com Ubuntu/Debian e CentOS/RHEL/Rocky Linux
# Uso: sudo bash /opt/security-audit/scripts/security-audit.sh
# =====================================================================
# Definir diretórios e arquivo de relatório com timestamp
AUDIT_DIR="/opt/security-aud
Quer aprender na prática com especialistas?
A JRT Technology Solutions oferece treinamentos e implementação de Firewall, fail2ban e CrowdSec para equipes corporativas.