Wazuh: Como Configurar Regras de Detecção Customizadas

10 min de leitura Segurança da Informação
Wazuh: Como Configurar Regras de Detecção Customizadas

Introdução à Customização de Regras no Wazuh

O Wazuh é uma plataforma de segurança unificada (XDR e SIEM) de código aberto que permite a detecção de ameaças, integridade de arquivos e monitoramento de conformidade. Uma das características mais poderosas dessa ferramenta reside em sua capacidade de ser altamente extensível através de regras de detecção. Enquanto o Wazuh vem com centenas de regras padrão cobrindo uma ampla gama de vulnerabilidades e comportamentos maliciosos, cenários reais de segurança muitas vezes exigem a criação de lógica personalizada para identificar anomalias específicas do seu ambiente corporativo.

Neste tutorial, vamos explorar como criar, compilar e implementar regras customizadas no Wazuh. O objetivo é demonstrar como transformar logs brutos em alertas acionáveis, utilizando um fluxo de trabalho que integra o agente ao analisador central. Ao final, você terá uma compreensão sólida de como estruturar expressões regulares (regex) e definir níveis de severidade para monitoramento proativo.

Estrutura do Arquivo de Regras

As regras do Wazuh são definidas em arquivos XML. Por padrão, as regras estão localizadas no diretório /var/ossec/etc/rules/. Para evitar conflitos durante atualizações da plataforma, a prática recomendada é criar um arquivo personalizado, como local_rules.xml, e incluí-lo no fluxo de processamento.

Cada regra possui uma estrutura XML específica que define o comportamento do analista. Os principais componentes são:

  • id: Um identificador único para a regra (geralmente um número acima de 100000 para regras locais).
  • level: O nível de severidade, variando de 0 a 15. Níveis mais altos indicam eventos críticos que devem gerar alertas imediatos.
  • match: Uma expressão regular que o Wazuh tentará encontrar no campo message do log.
  • description: Uma etiqueta humana explicando o propósito da regra.

Comece criando o arquivo de configuração. No servidor manager, execute:

sudo nano /var/ossec/etc/rules/local_rules.xml

Passo 1: Definindo a Lógica de Correspondência

Vamos supor um cenário onde você precisa monitorar tentativas de login falhas em servidores Linux que não estão sendo capturadas pelas regras padrão, ou talvez identificar um padrão específico de erro em uma aplicação web customizada. Para fins didáticos, criaremos uma regra que detecta qualquer log contendo a palavra CRITICAL_ERROR.

Dentro do arquivo local_rules.xml, insira o seguinte bloco XML:

<group name="LOCAL,syslog,sshd">

  <rule id="100001" level="8">
    <match>CRITICAL_ERROR</match>
    <description>Detecção de erro crítico personalizado no log da aplicação.</description>
  </rule>

</group>

Neste exemplo, atribuímos o ID 100001, garantindo que não haja colisão com as regras nativas. O nível 8 indica um alerta de média/alta severidade. A tag match contém a string simples. Se você precisar de uma regex mais complexa, pode usar padrões como <match>^Error.*Connection refused</match>.

Passo 2: Utilizando Variáveis e Decoders

Para regras mais avançadas, é comum utilizar decodificadores para extrair campos específicos do log antes de aplicar a regra. No entanto, para uma abordagem direta sem criar um decoder completo, podemos usar variáveis no Wazuh para capturar grupos de captura da regex.

Suponha que você queira detectar falhas de autenticação SSH e registrar o usuário afetado. A regra seria:

<rule id="100002" level="10">
  <match>sshd.*Failed password for (.*) from (.*)</match>
  <options>no_full_log</options>
  <description>Falha de login SSH detectada para o usuário $1.</description>
  <group>authentication_failed,pci_10.2,</group>
</rule>

Aqui, utilizamos $1 e $2 para referenciar os grupos capturados pela expressão regular: o nome de usuário e o endereço IP de origem, respectivamente. Isso permite que o alerta final inclua esses detalhes dinâmicos.

Passo 3: Validação da Configuração

Antes de reiniciar qualquer serviço, é crucial validar a sintaxe do XML. Erros comuns incluem tags não fechadas ou caracteres especiais mal escapados. O Wazuh fornece uma ferramenta de teste integrada.

Execute o comando de validação:

sudo /var/ossec/bin/wazuh-control check-xml -f /var/ossec/etc/rules/local_rules.xml

Se a saída retornar "Success", sua configuração está sintaticamente correta. Caso contrário, analise a mensagem de erro para corrigir a estrutura XML. Este passo é vital em ambientes de produção para evitar falhas no serviço do Wazuh Manager.

Passo 4: Aplicando e Recarregando as Regras

Com o arquivo validado, precisamos aplicar as mudanças ao ambiente ativo. O Wazuh utiliza um processo de compilação para gerar os índices de busca otimizados a partir dos arquivos XML.

Execute o comando de rebuild das regras:

sudo /var/ossec/bin/wazuh-control reload

Alternativamente, você pode reiniciar o serviço principal para garantir uma aplicação limpa:

sudo systemctl restart wazuh-manager

Aguarde alguns segundos para que o processo de indexação seja concluído. Você pode monitorar o log em tempo real para verificar se não há erros de carregamento:

sudo tail -f /var/ossec/logs/ossec.log

Passo 5: Testando a Regra Customizada

Agora que a regra está ativa, precisamos gerar o evento correspondente para verificar se o alerta é disparado. Se estiver testando em um ambiente local, você pode forçar a geração de um log simulado.

No servidor monitorado (ou no próprio manager, se o log estiver sendo coletado localmente), adicione uma entrada manual ao arquivo de log relevante, como /var/log/syslog ou /var/log/auth.log:

echo "Jun 15 10:23:45 myserver app[1234]: CRITICAL_ERROR - Database connection lost" >> /var/log/syslog

Aguarde aproximadamente 60 segundos. O agente Wazuh (ossec-agent) verifica novos logs periodicamente e os envia para o manager. Se a configuração estiver correta, o evento será processado pelo analisador.

Passo 6: Verificação no Painel e Integração

Acesse o painel web do Wazuh. Navegue até a seção de Event Analysis. Utilize o filtro de busca para procurar por eventos recentes com o nível de severidade alto ou pela descrição da sua regra.

Você deve visualizar o alerta gerado, contendo os detalhes configurados na tag description. Se tiver configurado variáveis ($1, etc.), verifique se os dados dinâmicos aparecem corretamente nos campos do evento.

Integração com Prometheus e Grafana

Para profissionais que utilizam o ecossistema de monitoramento observável, é possível integrar esses alertas ao Prometheus. O Wazuh possui um módulo de integração que expõe métricas para scrape pelo Prometheus.

1. Certifique-se de que o módulo de integração está habilitado no arquivo ossec.conf.

2. Configure o endpoint do Prometheus para coletar as métricas de alertas disparados.

3. No Grafana, crie um painel que visualize a taxa de ocorrências da sua regra customizada ao longo do tempo.

Isso permite correlacionar eventos de segurança com métricas de performance. Por exemplo, você pode criar um alerta no Grafana para notificar via Slack ou PagerDuty se o número de alertas da sua regra 100001 ultrapassar um limiar em 5 minutos.

Monitoramento de Uptime e Saúde do Sistema

A customização de regras não se limita a segurança pura. Você pode usar o Wazuh para monitorar a saúde da infraestrutura. Imagine uma regra que detecta falhas em serviços críticos monitorados por ferramentas como Uptime Kuma ou integradas via API.

Se você utiliza um sistema de roteamento e coleta de fluxo de rede, como Akvorado combinado com FastNetMon para mitigação de DDoS, pode criar regras no Wazuh que analisam logs de tráfego anômalo. Ao detectar picos de tráfego suspeitos nos logs agregados, o Wazuh pode disparar um alerta de alta severidade, permitindo que sua equipe de NOC (Network Operations Center) tome ações rápidas.

A integração entre Wazuh, Prometheus e ferramentas de visualização como Grafana cria uma camada robusta de observabilidade. Enquanto o Prometheus foca nas métricas numéricas de uptime e latência, o Wazuh adiciona a inteligência contextual sobre a causa raiz dos problemas, seja ela uma falha de aplicação ou um ataque cibernético.

Melhores Práticas e Manutenção

Ao trabalhar com regras customizadas, siga estas diretrizes para manter a estabilidade do seu SIEM:

  • Especificidade: Evite regex muito genéricas que possam gerar falsos positivos massivos. Uma regra muito ampla pode sobrecarregar o banco de dados e dificultar a análise.
  • Níveis de Severidade Apropriados: Use níveis baixos (1-5) para logs informativos e níveis altos (8-15) apenas para eventos que exigem ação imediata ou investigações forenses.
  • Documentação: Mantenha o arquivo local_rules.xml bem documentado com comentários explicando o contexto de cada regra. Isso facilita a manutenção por outros membros da equipe.
  • Teste em Homologação: Sempre valide novas regras em um ambiente de teste antes de aplicá-las em produção.

Conclusão

A configuração de regras de detecção customizadas no Wazuh é uma habilidade essencial para qualquer administrador de sistemas ou analista de segurança que deseje extrair o máximo potencial da plataforma. Ao dominar a estrutura XML, o poder das expressões regulares e o fluxo de validação, você transforma logs brutos em inteligência acionável.

A combinação do Wazuh com ferramentas de monitoramento modernas como Prometheus, Grafana e soluções de análise de fluxo como Akvorado permite uma visão holística da infraestrutura. Seja para detectar falhas críticas em aplicações ou responder a tentativas de intrusão, as regras customizadas são o coração da estratégia de detecção proativa.

Lembre-se: a segurança é um processo contínuo. Revise periodicamente seus logs e ajuste suas regras para garantir que seu monitoramento permaneça eficaz frente às novas ameaças e mudanças na infraestrutura de TI.

Compartilhar: Link copiado!
Esse tutorial foi útil?

Comentários (0)

Seja o primeiro a comentar.

Deixe seu comentário

Seu comentário será analisado antes de ser publicado.

0/2000