🛡️ Troubleshooting Avançado: Recuperação de Cluster Wazuh 4.14

Programa: Base Treinamentos  |  Nível: Avançado  |  Carga: 1h
Público: Engenheiros de SOC e Analistas de Segurança  |  Produzido por: BaseTI
Tags: 🏷️ #wazuh #soc #opensearch #troubleshooting #blueteam #sysadmin

Neste artigo técnico, detalhamos a resolução passo a passo de um incidente crítico em uma infraestrutura distribuída do Wazuh. Partindo do clássico erro "Wazuh dashboard server is not ready yet", navegamos por gargalos de memória Java (JVM), incompatibilidade de versões entre nós, bloqueios de execução do Linux (hardening em /tmp) e processos zumbis travando a API do Manager. Ao final, restabelecemos a integridade dos dados e a comunicação com os agentes.

🔥 1. O Sintoma Inicial: Dashboard "Not Ready"

O erro ocorre quando a interface não consegue se comunicar com os nós do Wazuh Indexer (OpenSearch). A investigação inicial através do comando _cluster/health revelou um status red e a perda de um dos nós do banco de dados.

A Causa Raiz (Circuit Breaker):

🧠 O serviço do Indexer estava limitando requisições (HTTP 429) por estouro de memória. A configuração padrão do JVM Heap estava subdimensionada para a carga do cluster, derrubando o nó por falta de recursos para o Java.

Correção (Ajuste do JVM Heap):

nano /etc/wazuh-indexer/jvm.options



# Alocar 50% da RAM total do servidor (Ex: Servidor com 16GB)

-Xms8g

-Xmx8g



systemctl restart wazuh-indexer

⚙️ 2. O Bloqueio: Version Mismatch e Hardening de SO

Com a memória ajustada, o nó 2 tentou retornar ao cluster, mas foi rejeitado. O log wazuh-cluster.log acusou version not supported: 2.19.3 the node version is: 2.19.1.

Ao tentar atualizar o pacote via apt-get install --only-upgrade wazuh-indexer, o post-install falhou (Exit Code 1).

A Causa Raiz (Bloqueio JNA no /tmp):

⚠️ Hardening do Linux: A partição /tmp estava montada com a flag noexec. O Java (OpenSearch) precisa extrair a biblioteca nativa JNA nesse diretório para interagir com o kernel. Sem execução, o processo aborta violentamente.

Correção (Bypass Seguro do /tmp):

mkdir -p /var/lib/wazuh-indexer/tmp

chown -R wazuh-indexer:wazuh-indexer /var/lib/wazuh-indexer/tmp

chmod 750 /var/lib/wazuh-indexer/tmp



# No final do arquivo /etc/wazuh-indexer/jvm.options, adicione:

-Djna.tmpdir=/var/lib/wazuh-indexer/tmp

-Djava.io.tmpdir=/var/lib/wazuh-indexer/tmp



# Criar diretório volátil e finalizar o dpkg travado

mkdir -p /run/wazuh-indexer

chown wazuh-indexer:wazuh-indexer /run/wazuh-indexer

dpkg --configure -a



systemctl daemon-reload

systemctl restart wazuh-indexer

🕸️ 3. A Falha na API: Error 1000 e Processos Zumbis

Com o banco de dados saudável e em status Yellow/Green, a interface carregou, mas disparou a mensagem "Error: 1000 - Unexpected error" com a API marcando o manager como Offline.

A Causa Raiz (Assimetria na Arquitetura):

Ao tentar atualizar o Manager, o Systemd acusou timeout devido a processos do Wazuh antigo (analysisd, clusterd) se recusarem a morrer, segurando as portas de rede (Processos Zumbis).

Correção (O Expurgo e Atualização):

systemctl stop wazuh-manager



# Matar impiedosamente os processos zumbis que travam as portas

pkill -9 -f wazuh



# Concluir a instalação pendente da versão 4.14.3

dpkg --configure -a



systemctl daemon-reload

systemctl start wazuh-manager

✅ 4. O Retorno dos Agentes

🎯 Retrocompatibilidade Garantida: Após igualar as versões do Manager/Workers com o Dashboard e o Indexer, o cluster formou quórum. Os agentes (mesmo os que ainda rodam a v4.12.0) reconectam-se automaticamente em poucos minutos graças ao protocolo de *backoff* do agente.

Upgrade Centralizado dos Agentes (Opcional, mas recomendado):

• Pode ser acionado direto pelo Dashboard via Endpoints > More > Upgrade agents.
• Via CLI no Manager: /var/ossec/bin/agent_upgrade -a <ID_DO_AGENTE>

Engenharia de Segurança & Resposta a Incidentes · BaseTI · 2026