Domando o Wazuh: de Centenas de Falsos Positivos a um Conjunto de Regras Funcional

A tarefa chegou com uma formulação familiar para muitos: "O Wazuh está funcionando, mas há tantos alertas que é impossível distinguir falsos positivos de ataques reais. Precisamos fazer algo a respeito."

Para contextualizar, o Wazuh é um SIEM open-source que coleta logs, detecta atividades suspeitas e pode reagir a elas. É uma ferramenta poderosa, mas o conjunto de regras padrão é como um canivete suíço: ele corta e abre, mas para uma tarefa específica, você sempre precisa afiá-lo. Ele é projetado para infraestruturas "médias" e, sem adaptação, gera muito ruído. Minha tarefa consistia em separar esse ruído dos eventos significativos, sem perder os ataques reais. Abaixo, apresento a metodologia e as armadilhas que encontrei. Será útil para quem está configurando o Wazuh pela primeira vez e para aqueles que desejam aliviar os analistas do fluxo de falsos alarmes.

Conhecendo as Regras

As regras padrão do Wazuh estão localizadas em /var/ossec/ruleset/rules/ – milhares de linhas em XML. Sim, XML em 2026. O formato é verboso (prepare-se para tags de fechamento em quantidades industriais), mas você se acostuma rapidamente e, o mais importante, não é necessário modificar esses arquivos diretamente. Todas as alterações locais são feitas em local_rules.xml e em arquivos adicionais carregados. É mais conveniente trabalhar através da interface web: ela verifica a estrutura XML em tempo real (tags pareadas, aninhamento correto) e não permitirá que você quebre acidentalmente uma configuração funcional – você só pode cometer erros em sua própria "sandbox".

Falsos Positivos Típicos

Na maioria das vezes, fomos alertados por três cenários:

• SSH-brute-force do localhost: O Ansible executa ssh localhost durante o provisionamento, e o Wazuh o interpreta com confiança como uma tentativa de força bruta. Parece um ataque, mas na verdade é o provisionamento normal.
• curl para si mesmo: Os healthchecks de monitoramento acessam endpoints a cada 30 segundos – para a regra, isso parece atividade HTTP suspeita. Na prática, é apenas o Prometheus fazendo seu trabalho.
• Alterações de arquivos em /tmp: O CI/CD deixa artefatos como wget-log.42 lá, e o módulo FIM reage a cada alteração como uma potencial comprometimento – e alerta o engenheiro de plantão às três da manhã por causa de um log do wget.

Todos os três são ruído de fundo clássico que mascara incidentes reais.

Como Escrever Regras Locais

Uma regra mínima se parece com isto:

xml
<group name="ssh">
  <rule id="100002" level="0">
    <if_group>ssh</if_group>
    <match>127.0.0.1|localhost</match>
    <description>SSH do localhost — provisionamento Ansible, não é um ataque</description>
  </rule>
</group>

Vamos analisar cada elemento:

• id: O número único da regra. O intervalo 100000+ é reservado para regras locais, então não haverá conflitos com as padrão – você pode usá-lo sem hesitação.
• level: O nível de criticidade de 0 a 16. level="0" suprime completamente o alerta, valores altos escalam o evento (15 já é "acorde o plantão").
• if_group: O grupo de regras ao qual a lógica está vinculada.
• match: O padrão de busca no conteúdo do log.
• description: O texto que o analista de plantão verá. Aqui, vale a pena escrever de forma concisa e clara: não "SSH auth from loopback", mas uma indicação explícita de que tipo de evento é e por que é seguro. Às três da manhã, um colega agradecerá.

Otimização e Profiling

Após o primeiro conjunto de regras, vale a pena medir como a carga mudou e se surgiram efeitos colaterais. A principal ferramenta de depuração é o utilitário wazuh-logtest. Ele recebe uma linha de log e mostra qual regra foi acionada, com qual nível e por quê:

bash
# wazuh-logtest
2026 May 15 10:42:00 sshd[12345]: Failed password for root from 127.0.0.1 port 22 ssh2

Com ele, o processo de configuração de regras se torna muito mais previsível. Essencialmente, é um try/catch: processe o log, veja o resultado, corrija.

O que deu o maior efeito:

• Substituição de regex por match sempre que possível: Expressões regulares são elegantes, mas caras em termos de desempenho. Em grandes volumes de logs, a correspondência simples de substring economiza recursos notavelmente.

• Configuração correta de frequency e timeframe: frequency define o número de acionamentos em timeframe segundos. O limite padrão de detecção de brute-force – 10 tentativas em 60 segundos – não é adequado para localhost, onde o Ansible pode facilmente gerar cem acessos em dez segundos. O limite teve que ser revisto, e uma regra de exceção separada teve que ser criada para localhost.

• Regras de exceção via if_sid: Em vez de reescrever uma regra padrão, uma exceção é adicionada para suprimir o acionamento em um caso específico:

  xml
  <rule id="100003" level="0">
    <if_sid>5710</if_sid>
    <match>127.0.0.1</match>
    <description>Exclui localhost da detecção de brute-force</description>
  </rule>

• Agrupamento de regras: As modificações locais devem ser logicamente divididas em grupos (sshd, fim, apache), em vez de espalhadas pela configuração. Isso simplifica a manutenção e a auditoria – tanto para você quanto para quem for mexer na configuração depois de você.

Armadilhas a Observar

Um caso ilustrativo. Escrevi uma regra que detectava wget para um URL específico. Uma semana depois, um analista relatou acionamentos a cada cinco minutos – descobriu-se que nosso próprio monitoramento, que baixava atualizações, estava caindo sob a regra. Isso foi resolvido adicionando if_sid para o evento de monitoramento. Portanto, antes de colocar uma regra em produção, certifique-se de que você mesmo não se tornará sua primeira vítima. Novamente, wazuh-logtest ajuda aqui – processar logs reais antes da implantação economiza muito tempo e nervos.

Resultado

Após a configuração, o fluxo de alertas falsos foi reduzido a um nível em que os analistas pararam de ignorá-los. E eventos significativos – como tentativas de acesso reais – tornaram-se visíveis em um fundo limpo. Um colega comentou: "Pela primeira vez em um mês, vi um ataque real, não o Ansible."

Conclusões

• Escrever regras não é difícil – o difícil é não prejudicar. Cada level="0" potencialmente esconde um ataque, e um match descuidado pode descartar um evento importante. Qualquer regra de supressão deve ser testada em logs de produção.
• Exceções são mais importantes que sobrescritas. Não reescreva as regras padrão – adicione exceções sobre elas. Essencialmente, é o padrão Decorator: expandimos o comportamento sem alterar o original.
• Documente as descrições. A description é lida pelos analistas de plantão, inclusive à noite. Uma formulação clara acelera a análise e reduz o número de escalonamentos.
• XML não é assustador. O formato é verboso, mas previsível e totalmente funcional se a estrutura for respeitada e as modificações forem mantidas em arquivos separados.

Um Wazuh configurado corretamente se transforma de uma fonte de ruído em uma ferramenta de monitoramento funcional. O principal é tratar o conjunto de regras como uma configuração viva: ela precisa ser mantida e revisada à medida que a infraestrutura muda.

A história descrita é sobre quanto recurso é necessário para que o monitoramento traga benefícios, em vez de acordar um engenheiro no meio da noite por causa de um wget-log.42. A configuração de regras, a filtragem de falsos positivos, a análise de logs e a resposta a incidentes exigem mãos e expertise que uma equipe pequena muitas vezes não possui.

Essa carga pode ser delegada. A Cloud4Y oferece monitoramento administrado: análise de logs, alertas inteligentes com notificações no Telegram e um painel unificado onde métricas e gargalos de infraestrutura são visíveis. Os alertas são configurados apenas para eventos significativos. A configuração fina e a implantação são realizadas pelos engenheiros do provedor.

E para novos clientes do Habr, há um desconto de 20% com o código promocional HABR20 nos serviços Cloud4Y, detalhes na página da promoção.