Montar um laboratório de SIEM open source com Wazuh começa por uma decisão prática: instalar os componentes centrais em um único host e alimentar o pipeline exclusivamente com logs sintéticos até que cada detecção esteja validada. O Wazuh é gratuito e de código aberto, distribuído sob as licenças GNU GPL versão 2 e Apache 2.0, e um único host no padrão quickstart comporta até 100 endpoints com 90 dias de alertas indexados — capacidade que ultrapassa o necessário para aprender engenharia de detecção. O primeiro passo concreto é executar o assistente de instalação oficial; o segundo, mais decisivo, é dominar o ciclo de decoders, regras e validação com eventos que você mesmo gera em laboratório.
Esse roteiro serve a três públicos: o analista que precisa aprender detecção sem tocar em dados reais, a equipe que quer testar regras antes de promovê-las à produção e quem avalia se um SIEM aberto acompanha o volume da própria operação. Nenhum exemplo aqui usa logs de terceiros — todos os eventos são sintéticos, com método documentado.
O que você precisa antes
O Wazuh se apoia em um agente instalado nos endpoints monitorados e em três componentes centrais: o servidor, que analisa os dados recebidos por meio de decoders e regras e usa inteligência de ameaças para procurar indicadores de comprometimento; o indexador, que armazena e permite pesquisar os alertas; e o dashboard, a interface de visualização com visões prontas de caça a ameaças e conformidade. Os agentes rodam em Linux, Windows, macOS, Solaris, AIX e HP-UX.
Nem todo ativo do laboratório precisa de agente: além do monitoramento com agente, a plataforma monitora dispositivos sem agente, como firewalls, switches, roteadores e IDS de rede, recebendo syslog diretamente no servidor, o que permite incluir ativos de rede no laboratório sem instalar nada dentro deles.
Para o quickstart em host único, a documentação oficial recomenda a seguinte capacidade, dimensionada para 90 dias de dados indexados:
| Agentes | vCPU | RAM | Armazenamento (90 dias) |
|---|---|---|---|
| 1-25 | 4 | 8 GiB | 50 GB |
| 26-50 | 8 | 8 GiB | 100 GB |
| 51-100 | 8 | 8 GiB | 200 GB |
Uma máquina virtual na primeira linha da tabela já sustenta o laboratório inteiro deste guia.
Instalação em um único host
O assistente de instalação oficial instala servidor, indexador e dashboard no mesmo host e, ao terminar, imprime o endereço do dashboard e as credenciais do usuário admin. Baixe o script wazuh-install.sh do repositório oficial de pacotes do Wazuh e execute com a opção -a, que conduz a instalação assistida de todos os componentes.
No primeiro acesso, o navegador avisa que o certificado não foi emitido por autoridade confiável — comportamento esperado em laboratório. Aceite a exceção ou configure um certificado próprio. A documentação também recomenda desabilitar os repositórios de pacotes do Wazuh depois da instalação, para evitar upgrades acidentais que quebrem o ambiente.
Decoders e regras com logs sintéticos
Ao receber uma mensagem de log, os decoders segmentam a informação em campos para preparar a análise. A operação tem duas fases: na pré-decodificação, informações gerais como timestamp, hostname e nome do programa são extraídas quando há um cabeçalho no formato syslog; na decodificação, o restante da mensagem é interpretado e os campos relevantes são isolados.
Para testar o ciclo completo, a documentação usa um programa fictício chamado example. O decoder vai em /var/ossec/etc/decoders/local_decoder.xml, apontando o nome do programa e a expressão regular que extrai usuário e endereço de origem; a regra vai em /var/ossec/etc/rules/local_rules.xml. Para ajustes pontuais, esses dois arquivos locais são o caminho recomendado, e a documentação recomenda usar identificadores entre 100000 e 120000 para regras personalizadas, faixa reservada que evita conflito com o ruleset oficial e com as atualizações que o substituem.
O log sintético de teste, gerado em laboratório no mesmo formato do exemplo oficial, tem esta cara:
Dec 25 20:45:02 lab-host example[12345]: User 'admin' logged from '192.168.1.100'O decoder extrai usuário e IP de origem desse evento; a regra personalizada associa o programa example a uma descrição de alerta. Nada aqui depende de tráfego real — o objetivo é exercitar o pipeline com um evento cujo conteúdo você controla por completo, repetível a qualquer momento.
Validação com wazuh-logtest
O utilitário wazuh-logtest valida o pipeline inteiro sem gerar alerta: cole o log sintético no terminal e o log de exemplo de um programa fictício passa por fases sucessivas de pré-decodificação, decodificação e filtragem pelas regras antes de qualquer alerta ser gerado, com a exibição dos campos extraídos e da regra que correspondeu, incluindo identificador, nível e descrição.
Se o resultado mostra os campos esperados e a regra correta, a detecção está pronta para o ambiente de teste. Salvar os arquivos basta para o logtest; para que o servidor gere alertas de fato, reinicie o serviço wazuh-manager — só então os eventos passam a alimentar o indexador e aparecem no dashboard.
Esse hábito de validar antes de subir é o que separa regra útil de ruído. Detecções maduras seguem o mesmo princípio em casos reais, como a análise do bypass de MFA pelo ransomware Gunra e a detecção de movimentação lateral por pass-the-hash: a qualidade da regra decide se o SOC enxerga o ataque.
Regras Sigma no ecossistema aberto
Wazuh não é ilha. As regras Sigma são arquivos YAML que descrevem detecções de forma independente do SIEM e podem ser convertidas para a linguagem de consulta de cada plataforma. Na prática, o campo level classifica a criticidade em critical, high, medium, low e informational — e a documentação do Sigma reserva os níveis high e critical para eventos que indicam incidente e devem disparar alerta dedicado, enquanto low e medium sinalizam atividade suspeita ou violação de política.
Tags como attack.t1012 conectam cada regra às técnicas do MITRE ATT&CK, permitindo medir cobertura sem planilha infinita. Para o laboratório, o caminho pragmático é manter as detecções próprias em Sigma no repositório do time e converter para o formato local do Wazuh quando promover à operação — assim o mesmo conteúdo serve a outros SIEMs que o time venha a avaliar.
Erros comuns do primeiro laboratório
Antes de encerrar, passe por esta verificação rápida:
- Editar arquivos do ruleset oficial em vez de local_rules.xml e local_decoder.xml — as mudanças se perdem na atualização do Wazuh.
- Esquecer o restart do wazuh-manager depois de criar regras — o logtest funciona, mas o alerta nunca chega ao indexador.
- Usar logs reais de produção no primeiro teste — comece sempre com logs sintéticos de conteúdo conhecido.
- Tratar falso positivo como falha do laboratório — registre a causa no campo falsepositives da regra para orientar a triagem futura.
- Medir cobertura pela quantidade de regras — valide cada detecção com um evento gerado de ponta a ponta.
Fontes
- Wazuh — Quickstart
- Wazuh — Components
- Wazuh — Custom rules and decoders
- Sigma — Explore Sigma Rules
