Wazuh: guia completo do SIEM/XDR open source para detecção e resposta a ameaças

O que é

O Wazuh é uma plataforma de segurança open source que combina SIEM (Security Information and Event Management, gestão de informações e eventos de segurança) e XDR (Extended Detection and Response, detecção e resposta estendida) em um único produto gratuito e auto-hospedado — sem custo por agente e sem depender de nuvem de terceiros. O projeto nasceu em 2015 como um fork do OSSEC, o HIDS (Host-based Intrusion Detection System, sistema de detecção de intrusão baseado no host) criado por Daniel Cid, e é mantido pela Wazuh Inc. sob as licenças GPLv2 e Apache 2.0, com mais de 16,8 mil estrelas e cerca de 50 mil commits no GitHub. Na prática, é a alternativa open source mais madura a SIEMs comerciais como Splunk (plataforma comercial de análise de logs e SIEM), IBM QRadar (SIEM empresarial da IBM) e Microsoft Sentinel (SIEM nativo da nuvem Azure).

O Wazuh protege workloads on-premises, virtualizados, em containers e em nuvem cobrindo o ciclo completo da defesa: coleta e correlação de logs, monitoramento de integridade de arquivos, detecção de malware e rootkits, inventário e detecção de vulnerabilidades, avaliação de configuração e resposta automatizada a incidentes. Por ser modular, a plataforma escala de um servidor único monitorando dezenas de máquinas até clusters distribuídos com alta disponibilidade em ambientes corporativos — o que a torna uma escolha frequente para SOCs (Security Operations Center, centro de operações de segurança) que precisam de visibilidade centralizada sem orçamento de licenças comerciais.

Arquitetura: um agente universal e três componentes centrais

A arquitetura segue o modelo clássico de SIEM descentralizado: um agente leve instalado em cada máquina monitorada coleta dados localmente e os envia, por um canal criptografado e autenticado, para um servidor central que analisa, correlaciona e gera alertas. A solução é composta por um único agente universal e três componentes centrais — o Wazuh server (que reúne o manager e o motor de análise), o Wazuh indexer (armazenamento e busca) e o Wazuh dashboard (interface web), todos com portas padrão bem definidas:

O fluxo de dados começa no agente: o mesmo binário coleta syslog (protocolo padrão de envio de logs em redes IP), eventos do Windows, chamadas de sistema e alterações de arquivos. O manager decodifica cada evento para um formato estruturado, compara com o ruleset nativo — centenas de regras de detecção baseadas em assinaturas e comportamento — e, quando há correspondência, gera um alerta enriquecido com campos como nível de severidade, grupo de regra, técnica do MITRE ATT&CK e tags de compliance. Um componente interno chamado Filebeat encaminha os alertas ao indexer, que os torna pesquisáveis em milissegundos no dashboard. Em redes onde não é possível instalar agente — firewalls, switches e appliances —, o server também aceita dados via syslog diretamente, no chamado modo agentless. Desde a versão 4.12, os componentes centrais rodam também em processadores ARM, ampliando as opções de hardware para quem quer montar um SOC em equipamentos de baixo custo.

Principais características

Instalação: do all-in-one ao cluster distribuído

O caminho mais rápido para um ambiente funcional é o installation assistant, que instala e configura server, indexer e dashboard na mesma máquina — suficiente, segundo a documentação oficial, para monitorar até 100 endpoints com 90 dias de alertas indexados. Os requisitos recomendados variam com o número de agentes:

O primeiro passo é baixar e executar o script oficial, informando a versão no URL — a série 4.14 é a estável atual, com a 4.14.7 lançada em julho de 2026:

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

Ao terminar, o assistente imprime o endereço do dashboard (https://IP-do-servidor), o usuário admin e a senha gerada, e salva todas as credenciais em um arquivo protegido. Para recuperá-las depois, basta extrair o arquivo de senhas do pacote gerado na instalação:

sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

Em seguida, recomenda-se desabilitar o repositório de pacotes do Wazuh para evitar que um upgrade automático quebre o ambiente — no Debian/Ubuntu, comenta-se a linha do repositório APT; em distribuições YUM/DNF, desativa-se o repositório na configuração:

sudo sed -i "s/^deb /#deb/" /etc/apt/sources.list.d/wazuh.list
sudo apt-get update

sudo sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo

Com os componentes centrais no ar, o próximo passo é instalar o agente nos endpoints. No Debian/Ubuntu, basta definir a variável de ambiente com o endereço do manager durante a instalação — o agente já faz o enrollment (registro com autenticação por chave) automaticamente:

sudo WAZUH_MANAGER="10.0.0.2" apt-get install wazuh-agent
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

Há agentes oficiais também para Windows (instalador MSI com interface gráfica), macOS, Solaris, AIX e HP-UX, e o dashboard permite gerar o comando exato de deploy para cada sistema. Em ambientes maiores, a arquitetura vira cluster: o Wazuh server e o indexer suportam topologias multi-nó com balanceamento de carga e alta disponibilidade, e existem módulos oficiais para Ansible (ferramenta de automação de configuração) e Puppet, além de imagens para Docker e Kubernetes (orquestrador de containers). Para a operação do dia a dia, os binários de administração ficam em /var/ossec/bin: wazuh-control mostra o status dos processos, manage_agents gerencia o registro manual de agentes e cluster_control inspeciona os nós do cluster. Uma regra de compatibilidade vale para o ciclo de vida inteiro: o manager deve estar em versão igual ou superior à dos agentes.

Casos de uso práticos

Monitoramento de integridade de arquivos (FIM)

O FIM (File Integrity Monitoring, monitoramento de integridade de arquivos) é o módulo que detecta criação, alteração e remoção de arquivos, mudanças de permissões e de propriedade — a base para detectar webshells (scripts maliciosos injetados em servidores web), binários adulterados e a instalação de backdoors. A configuração fica no arquivo /var/ossec/etc/ossec.conf, na seção syscheck, tanto no server quanto no agente, e pode ser distribuída remotamente via agent.conf, a configuração centralizada do Wazuh. Um exemplo clássico monitora os diretórios mais visados em Linux, com checagem completa de atributos, detecção em tempo real e whodata (monitoramento que identifica qual usuário e qual processo modificou o arquivo):

<syscheck>
  <directories check_all="yes" realtime="yes" whodata="yes">/etc,/usr/bin,/usr/sbin</directories>
</syscheck>

Depois de aplicar a configuração, reinicie o manager:

sudo systemctl restart wazuh-manager

Com whodata habilitado, um simples touch em um arquivo monitorado gera um alerta da regra 554, nível 5, com a descrição "File added to the system" e o caminho, os hashes e o responsável pela alteração:

sudo touch /etc/arquivo-teste.conf

Desde a versão 4.12, o FIM suporta eBPF (Extended Berkeley Packet Filter, tecnologia que executa código seguro dentro do kernel Linux) como fonte de eventos em tempo real, com desempenho superior ao do sistema de auditoria padrão; quando o eBPF não está disponível, o módulo recua automaticamente para o auditd ou o inotify. No Windows, o mesmo módulo monitora chaves de registro frequentemente usadas por malware para estabelecer persistência, como as chaves Run de inicialização automática.

Detecção de malware: regras, FIM e VirusTotal

A detecção de malware no Wazuh combina três camadas: regras de comportamento, análise de integridade e integração com threat intelligence (coleta e análise de informações sobre ameaças). O ruleset nativo já dispara alertas para padrões reconhecidos — por exemplo, a regra 92213 é acionada quando um executável é criado em uma pasta tipicamente usada por malware — e a documentação oficial mostra como criar regras customizadas para ameaças específicas. O exemplo do LimeRAT (malware de acesso remoto que se disfarça de arquivo "checker netflix.exe") ilustra o formato em /var/ossec/etc/rules/local_rules.xml, com mapeamento direto para o MITRE ATT&CK:

<group name="lime_rat,sysmon,">
  <rule id="100024" level="12">
    <if_sid>61613</if_sid>
    <field name="win.eventdata.image" type="pcre2">\.exe</field>
    <field name="win.eventdata.targetFilename" type="pcre2">(?i)[c-z]:\\Users\\.+\\AppData\\Roaming\\checker netflix\.exe</field>
    <description>Potencial atividade do LimeRAT: checker netflix.exe criado por $(win.eventdata.image).</description>
    <mitre>
      <id>T1036</id>
    </mitre>
  </rule>
</group>

A regra herda o contexto da regra 61613 (criação de executável monitorada pelo Sysmon), valida o campo com expressão regular e adiciona a técnica T1036 (Masquerading) ao alerta. O resultado aparece no módulo Threat Hunting do dashboard.

A integração com VirusTotal (serviço que agrega dezenas de antivírus e analisa arquivos e URLs por hash) é o reforço mais popular: quando o FIM detecta um arquivo novo, o Wazuh extrai o hash e o envia à API do VirusTotal, que responde quantos motores antivírus identificaram o arquivo como malicioso. A configuração fica no ossec.conf do server:

<integration>
  <name>virustotal</name>
  <api_key>SUA_CHAVE_VIRUSTOTAL</api_key>
  <group>syscheck</group>
  <alert_format>json</alert_format>
</integration>

Para testar o fluxo, a própria documentação sugere baixar o arquivo de teste EICAR (assinatura inofensiva reconhecida por antivírus como malware, usada exclusivamente para validação) em um diretório monitorado:

sudo curl -Lo /tmp/eicar.com https://secure.eicar.org/eicar.com

O resultado é um alerta da regra 87105, nível 12, com a mensagem "VirusTotal: Alert — 66 engines detected this file", incluindo a técnica MITRE T1203 (Exploitation for Client Execution) e as tags de compliance pci_dss 10.6.1/11.4 e gdpr IV_35.7.d. Vale a ressalva: a API pública do VirusTotal limita a 500 requisições por dia e 4 por minuto, e não permite uso comercial — em produção com muitos endpoints, é preciso avaliar a API privada paga. Complementos opcionais são as listas CDB (arquivos binários de indicadores de comprometimento consultados pelas regras em milissegundos) e o escaneamento com YARA (linguagem de regras para identificar padrões de malware).

Correlação de logs e detecção de brute-force SSH

A espinha dorsal de qualquer SIEM é a análise de logs, e o Wazuh decodifica nativamente centenas de formatos — logs de autenticação SSH, Apache, Nginx, PostgreSQL, eventos do Windows e muitos outros. A correlação acontece no manager: regras contam ocorrências em janelas de tempo e cruzam eventos de agentes diferentes. Um exemplo recorrente é o brute-force (tentativa sistemática de adivinhar senhas) em SSH: a regra 5710 dispara quando o mesmo IP acumula múltiplas falhas de autenticação em poucos segundos, e regras irmãs detectam o momento em que a invasão foi bem-sucedida — uma cadeia de eventos que, isoladamente, passaria despercebida.

Para integrar o Wazuh a playbooks ou consultar alertas programaticamente, a API REST é o caminho. O primeiro passo é autenticar e obter um token:

curl -k -u admin:SUA_SENHA -X POST "https://localhost:55000/security/user/authenticate"

Em seguida, o token gerado é usado no cabeçalho Authorization das consultas, como nesta busca por alertas da regra 5710:

curl -k -X GET "https://localhost:55000/alerts?rule_id=5710" -H "Authorization: Bearer SEU_TOKEN"

A mesma API permite gerenciar agentes, regras, grupos, integrações e até disparar comandos de resposta — o que viabiliza automações de resposta a incidentes sem depender da interface. Todo o histórico fica em /var/ossec/logs/alerts/alerts.json (formato JSON, ideal para ingestão em outras ferramentas) e em /var/ossec/logs/alerts/alerts.log, além do log de operação /var/ossec/logs/ossec.log e do log das integrações em /var/ossec/logs/integrations.log.

Resposta automatizada com Active Response

O Active Response é o módulo que transforma alerta em ação: quando uma regra dispara, o manager instrui o agente a executar um script no endpoint afetado. As respostas podem ser stateless (ação única, sem reversão) ou stateful (ação revertida após um timeout), e o pacote traz scripts prontos como firewall-drop.sh, que bloqueia o IP ofensor no firewall do host, e remove-threat.sh, que apaga o arquivo malicioso. Uma configuração típica associa o comando de bloqueio à regra de brute-force SSH, com timeout de 300 segundos para reverter:

<command>
  <name>firewall-drop</name>
  <executable>firewall-drop.sh</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>
 
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5710</rules_id>
  <timeout>300</timeout>
</active-response>

O campo location define onde o script roda: local (no endpoint que gerou o alerta), server, defined-agent (um agente específico) ou all (em todos os agentes — opção que a documentação manda usar com cautela). A documentação alerta que respostas automáticas mal calibradas aumentam a superfície de risco — um bloqueio errado pode derrubar um serviço legítimo —, por isso a recomendação é começar com timeouts generosos e testar em laboratório antes de aplicar em produção. O resultado de cada execução fica registrado em /var/ossec/logs/active-responses.log.

Detecção de vulnerabilidades com inventário e CTI

O módulo de detecção de vulnerabilidades mantém um inventário contínuo dos pacotes e softwares instalados em cada agente e o compara com bases de dados de CVEs (Common Vulnerabilities and Exposures, identificadores públicos de vulnerabilidades) dos fornecedores — Ubuntu, Debian, RHEL, Windows e outros. O resultado é um dashboard com o inventário completo e a lista de vulnerabilidades por endpoint, com severidade e correção sugerida. Desde a versão 4.12, cada resultado ganhou uma referência CTI gerada a partir do ID do CVE, apontando para a plataforma de inteligência de ameaças do projeto — o Wazuh CTI, lançado em junho de 2025, que agrega dados de fornecedores e bases de vulnerabilidades em um repositório unificado. Na prática, o analista sai do alerta direto para o contexto externo da vulnerabilidade sem abrir outra ferramenta.

Avaliação de configuração com SCA

O módulo SCA (Security Configuration Assessment, avaliação de configuração de segurança) executa varreduras periódicas nos endpoints comparando a configuração do sistema com benchmarks de hardening — as políticas CIS (Center for Internet Security, guias de referência de endurecimento de sistemas). Cada verificação gera uma nota de conformidade por política e alertas com a recomendação de correção e o mapeamento para frameworks de compliance. Desde a versão 4.12, uma nova política SCA para Linux substituiu a política UNIX padrão anterior, alinhada aos benchmarks CIS mais recentes e com melhor cobertura das distribuições — e o administrador pode escrever políticas customizadas para alinhar a avaliação às necessidades da organização.

Compliance: PCI DSS, GDPR e o caminho para a LGPD

O Wazuh é amplamente usado para evidência de conformidade: as regras nativas carregam tags de frameworks como PCI DSS (Payment Card Industry Data Security Standard, padrão de segurança para dados de cartões), GDPR (Regulamento Geral sobre a Proteção de Dados da União Europeia), HIPAA (saúde), NIST 800-53 e TSC, e os alertas incluem os controles atendidos — como no exemplo do VirusTotal, que já nasce com as tags pci_dss 10.6.1 e 11.4. Para PCI DSS, a documentação mostra inclusive a criação de regras customizadas que detectam um PAN (Primary Account Number, número do cartão) não mascarado em arquivos e logs. O módulo SCA complementa com avaliações contra benchmarks CIS, gerando relatórios de conformidade de configuração por endpoint.

Para empresas brasileiras, a LGPD (Lei Geral de Proteção de Dados) não tem módulo dedicado no Wazuh, mas o caminho prático passa pelos mesmos controles usados para GDPR: FIM em bases de dados pessoais e documentos confidenciais, monitoramento de acesso a sistemas que tratam dados, trilhas de auditoria e retenção de alertas — exatamente o tipo de evidência que uma auditoria de privacidade espera ver.

Threat hunting com MITRE ATT&CK

Todos os alertas do Wazuh podem carregar a técnica e a tática do MITRE ATT&CK (base de conhecimento de táticas e técnicas usadas por atacantes reais), como visto no bloco mitre das regras customizadas. Isso habilita o módulo Threat Hunting do dashboard, que permite investigar hipóteses com buscas por técnica, tática, agente e campo específico — por exemplo, listar todos os endpoints com eventos mapeados para T1055 (injeção de processo) em um período. O hunting transforma o SIEM de ferramenta reativa em ferramenta proativa: em vez de esperar o alerta, o analista percorre a matriz ATT&CK procurando comportamentos que ainda não geraram detecção.

Como se defender e riscos

Um SIEM concentra a visibilidade da rede inteira em um único ponto — e o Wazuh não é exceção. Comprometer o manager equivale a cegar a defesa e, pior, dá ao atacante acesso a todos os logs e alertas, incluindo indicadores de comprometimento de incidentes em andamento. Os riscos são reais e recentes: em 2026 foram corrigidos CVEs no próprio Wazuh, como o CVE-2026-44252, uma falha de autorização que permitia a um usuário da API com poucos privilégios ler a chave do cluster e escalar para administrador (corrigida na 4.14.5), e o CVE-2026-61783, um desvio na checagem de permissões que expunha a chave do cluster a usuários de baixo privilégio (corrigido na 4.14.7). A defesa começa tratando o SIEM como o ativo mais crítico da rede.

Manter o Wazuh sempre atualizado. Vulnerabilidades na plataforma de segurança são descobertas continuamente, e cada versão corrige falhas que afetam a confidencialidade do próprio SOC — os dois CVEs citados foram corrigidos em releases pontuais da série 4.14. Acompanhar os release notes, planejar janelas de atualização do server, indexer, dashboard e agentes, e testar upgrades em ambiente separado antes de aplicar em produção é o controle mais barato e mais eficaz, lembrando sempre da regra de compatibilidade: o manager em versão igual ou superior à dos agentes.

Proteger a API e o dashboard. A API REST (porta 55000) e o dashboard (porta 443) são as portas de administração do Wazuh e nunca devem ficar expostos à internet. Trocar as senhas padrão geradas na instalação (elas ficam em wazuh-passwords.txt), habilitar TLS com certificados válidos, usar RBAC (controle de acesso baseado em papéis) para conceder o mínimo de privilégio a cada usuário e restringir o acesso por rede a faixas administrativas são passos obrigatórios — o CVE-2026-44252 explorou justamente uma conta de baixo privilégio lendo segredos via API.

Segmentar o tráfego e restringir portas. As portas 1514/1515 (agentes), 1516 (cluster), 9200/9300 (indexer) e 55000/443 (administração) devem ser acessíveis apenas entre os hosts autorizados, com regras de firewall específicas por origem e destino. O indexer, em particular, não precisa ser alcançado por nada além do server e do dashboard, e a porta 1516 do cluster não deve aceitar conexões externas — o cenário exato explorado pelo CVE-2026-44252. Em redes grandes, isolar o Wazuh em uma VLAN de gerenciamento reduz drasticamente a superfície de ataque.

Calibrar o Active Response com cautela. Respostas automáticas podem causar dano colateral — bloquear o IP de um proxy corporativo ou remover um arquivo legítimo classificado como falso positivo. Usar respostas stateful com timeout, restringir os comandos às regras realmente confiáveis e testar em laboratório antes de produção evita que a automação de defesa vire fonte de indisponibilidade.

Reduzir falsos positivos com tuning contínuo. FIM em diretórios voláteis, regras muito abrangentes e níveis de severidade mal calibrados geram fadiga de alertas — e analista que ignora alerta deixa de ver o incidente real. Ajustar níveis de regras, usar listas CDB com indicadores confiáveis e integrar fontes de threat intelligence ajudam a priorizar o que importa.

Monitorar a saúde do próprio Wazuh. O manager pode monitorar a si mesmo com agentes instalados no próprio server e no indexer, garantindo que falhas internas (disco cheio, serviço parado, ingestão atrasada) gerem alertas como qualquer outro evento. Em ambientes críticos, o cluster multi-nó com alta disponibilidade e o backup regular do indexer (snapshots) evitam que a perda do SIEM coincida com o pior momento possível: o de um incidente real.

Conclusão

O Wazuh prova que visibilidade de nível empresarial não precisa custar uma fortuna: com um agente universal, três componentes centrais e um ruleset maduro, a plataforma entrega o núcleo de um SOC — coleta e correlação de logs, monitoramento de integridade, detecção de malware e vulnerabilidades, avaliação de configuração, resposta automatizada e evidência de compliance — tudo em software livre, com escala que vai do laboratório caseiro ao cluster corporativo. A adoção crescente, os releases constantes (a série 4.14 soma versões desde outubro de 2025, e o 5.0 está em desenvolvimento) e o ecossistema de integrações mostram que o projeto veio para ficar. O que separa uma boa de uma má implementação, porém, não é a ferramenta: é o cuidado com o próprio SIEM — atualização disciplinada, API protegida, regras calibradas e resposta automática testada. Tratado como o ativo crítico que é, o Wazuh é provavelmente a melhor relação custo-benefício da detecção e resposta a ameaças open source hoje.

Fontes e leituras adicionais

• Wazuh — Site oficial — 04/09/2026
• Wazuh — Documentação oficial — 04/09/2026
• Wazuh — Repositório no GitHub — 04/09/2026
• Wazuh — Quickstart — instalação assistida — 04/09/2026
• Wazuh — Deploying Wazuh agents on Linux endpoints — 04/09/2026
• Wazuh — Introducing Wazuh 4.12.0 (blog) — 04/09/2026
• Wazuh — Malware detection — casos de uso — 04/09/2026
• Wazuh — VirusTotal integration — documentação — 04/09/2026
• Wazuh — Active Response — documentação — 04/09/2026
• Wazuh — How to configure Active Response — 04/09/2026
• Wazuh — Regulatory compliance — casos de uso — 04/09/2026
• NVD — CVE-2026-44252 — 04/09/2026
• NVD — CVE-2026-61783 — 04/09/2026
• SentinelOne — CVE-2026-44252: Wazuh Manager Auth Bypass Vulnerability — 21/08/2026