Wazuh: Testando o Processamento de um Grande Volume de Eventos de Alteração de Arquivos

Olá, Habr! Meu nome é Fyodor Tyshkov. Trabalho no departamento de suporte de infraestrutura de um pequeno banco. Fui encarregado de testar a funcionalidade de uma ferramenta de código aberto para rastrear alterações em arquivos de configuração. Antes de começar, pesquisei muitas avaliações e quase todas foram positivas, então parecia que tudo correria "sem problemas". Mas vamos aos detalhes.

Wazuh é uma plataforma popular e multifuncional de código aberto para monitoramento de eventos de segurança. É amplamente utilizada para rastrear alterações de arquivos, analisar logs e detectar ameaças. A plataforma é composta por vários componentes-chave:

• Agente: Instalado em endpoints (estações de trabalho, servidores, contêineres), ele coleta dados de segurança e os envia para o servidor central para análise.
• Servidor (Gerenciador): Analisa os dados recebidos dos agentes, os decodifica, compara com regras de detecção e gera alertas. Suporta configuração em cluster para garantir resiliência e distribuição de carga.
• Indexador: Armazena dados em um banco de dados OpenSearch (um fork do Elasticsearch), garantindo armazenamento de longo prazo, busca em texto completo e agregação.
• Dashboard: Uma interface web para visualizar e filtrar alertas em tempo real, visualizar dados através de gráficos, tabelas e mapas, e gerenciar agentes, regras e configurações.

Para sistemas de TI críticos, uma solução confiável para rastrear alterações em arquivos de configuração é essencial. Tanto a completude dos dados (ausência de perda de eventos durante a detecção e processamento) quanto a precisão desses dados são importantes. Isso é necessário para:

• Detectar alterações não autorizadas na configuração do sistema operacional observado (criação de pontos de entrada no sistema por um invasor) e do software aplicado (correção e estabilidade do sistema).
• Controlar e monitorar a integridade do sistema.
• Cumprir requisitos regulatórios.
• Identificar e responder a incidentes de forma oportuna.

Como parte da tarefa atribuída, precisei verificar a capacidade do Wazuh de processar uma quantidade realista (não de laboratório ou demonstração) de eventos sem perda de dados e atrasos no processamento.

Metodologia de Teste

Ambiente:

• Servidor: Wazuh. Implantado e configurado conforme descrito nos testes abaixo.
• Agentes: Windows e Linux.
• Cenário: Criação de um arquivo de 16 MB e subsequente introdução de mais de 10.000 alterações.

Cenário de Teste no Windows

Para o cliente Windows, foram utilizados três scripts:

• run.cmd - script para executar sequencialmente os scripts test_1.cmd e test_2.cmd:

  batch
  @echo off
  start /wait test_1.cmd 
  start /wait test_2.cmd
  exit

• test_1.cmd - criação de um arquivo de 16 MB duplicando repetidamente o conteúdo:

  batch
  @echo off
  echo "This is just a sample line appended to create a big file. " > test.txt
  for /L %%i in (1,1,18) do (
  type test.txt >> test.txt
  )
  Exit

• test_2.cmd - adição de 10.000 linhas com timestamps:

  batch
  @echo off
  for /L %%x in (1,1,10000) do (
  echo %%x %date% %time% >> test.txt
  )
  Exit

Os scripts foram colocados no diretório C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp, que é monitorado pelo Wazuh por padrão.

Cenário de Teste no Linux

Para o cliente Linux, uma linha foi previamente adicionada ao arquivo de configuração /var/ossec/etc/ossec.conf:

xml
<directories check_all="yes" realtime="yes" whodata="yes">/tmp/test</directories>

Após isso, o serviço foi reiniciado:

bash
sudo systemctl restart wazuh-agent.service

• run.sh - script para executar os scripts test1.sh e test2.sh:

  bash
  #!/bin/bash
  bash test1.sh
  bash test2.sh

• test1.sh - criação de um arquivo de 16 MB:

  bash
  #!/bin/bash
  dd if=/dev/urandom of=test.txt bs=1M count=16

• test2.sh - adição de 10.000 linhas com timestamps:

  bash
  #!/bin/bash
  for x in {1..10000}
  do
      echo "$x $(date '+%d.%m.%Y %H:%M:%S')" >> test.txt
  done

Os scripts foram colocados no diretório /tmp/test/, cujo monitoramento foi adicionado ao arquivo de configuração.

Resultados do Teste

Windows: Número crítico de eventos de alteração de objeto monitorado não registrados

Conclusão: O Wazuh registrou apenas 20 eventos dos 10.019 esperados. Isso indica sérios problemas no processamento de um grande número de alterações de arquivos em tempo real.

Linux: Melhor, mas insuficiente

Conclusão: O cliente Linux apresentou um resultado melhor (120 eventos contra 20 no Windows), no entanto, a perda de 98,8% dos eventos permanece inaceitável para o monitoramento de eventos em sistemas críticos.

Análise dos Problemas

• Pós-processamento assíncrono de eventos: O agente Wazuh utiliza os recursos do sistema operacional para detecção dinâmica (em tempo real) de eventos de alteração e, filtrando a fila de eventos no buffer do mecanismo de journaling do SO, realiza o pós-processamento independente dos eventos (criação de uma cópia sombra do conteúdo e cálculo do checksum do arquivo alterado). Como o pós-processamento dos eventos é realizado de forma assíncrona, enquanto os artefatos de um evento estão sendo processados, outros eventos na fila são ignorados.

• Gargalo no armazenamento local de eventos registrados no agente: O agente Wazuh utiliza um buffer local para acumular eventos antes de enviá-los para o servidor. Com alta intensidade de registro de eventos, o espaço disponível no buffer do agente é preenchido e os eventos são perdidos.

• Ausência de processamento adaptativo do fluxo de eventos de entrada no servidor: O servidor Wazuh não possui um mecanismo integrado para se adaptar a picos no fluxo de eventos de entrada. Quando o número de eventos chegando dos agentes excede a capacidade de processamento do servidor, os eventos são simplesmente descartados.

• Ausência de garantias de entrega: O Wazuh não garante a entrega de cada evento. Em caso de sobrecarga, o sistema prefere perder eventos a desacelerar o processamento.

Comparação com Requisitos Regulatórios

Bancos centrais nacionais, padrões nacionais e internacionais de cibersegurança e outros reguladores setoriais geralmente exigem:

• Rastreamento de 100% das alterações em objetos de configuração (arquivos e chaves).
• Entrega garantida de eventos para o servidor.
• Impacto mínimo no desempenho do sistema e das aplicações.
• Registro de todos os eventos de segurança observados, sem exceção.
• Escalabilidade com o crescimento da carga.

Resultados do Wazuh:

• Perda de 98-99% dos eventos.
• Ausência de garantias de entrega.
• Atraso de processamento indefinido.
• Eventos críticos podem ser perdidos.
• Escalabilidade não garantida.

Possíveis Soluções e Recomendações

Posso dizer que o resultado do teste foi inesperado, lembrando todas as avaliações positivas lidas. O que notei para mim:

• Perda de dados inaceitável: A perda de eventos é inaceitável para sistemas que exigem auditoria completa.
• Ausência de garantias: O Wazuh não garante o registro de cada evento.
• Escalabilidade limitada: O sistema não consegue lidar com a alta intensidade de eventos enviados ao servidor.

O Wazuh continua sendo uma excelente escolha para organizações de médio porte com requisitos moderados de monitoramento de eventos de segurança, mas requer ferramentas adicionais para garantir a proteção completa de sistemas críticos. Compartilhe nos comentários se você obteve resultados diferentes, é interessante trocar opiniões.