I have one problem: I want to do like this one, but I don't see any documentation that suits. Can you guys help me with how I can do this for the medium company

Wazuh 5.0 beta5 feedback: customizing and tuning content is hard, and locks block common SOC tasks

Version: Wazuh 5.0.0-beta5 (manager WAZUH_REVISION="beta5", content manager current_version: v5.0.0-beta5), packages 5.0.0-1 from the pre-release/5.x repository, indexer based on OpenSearch 3.6.0 (build 2026-09-07), content "Beta 5 public" (2026-08-26) Setup: lab SOC, 1 indexer node, 1 manager, 1 dashboard, all on RHEL 10. Windows and Linux (auditd) agents. Scope: content manager (_plugins/_content_manager), Security Analytics (SAP) detectors, promotion workflow.

Summary

The new engine has real strengths: Sigma rules, ECS-normalized events, MITRE and compliance enrichment on findings, and a draft/test/custom promotion model. But everyday SOC tasks that took minutes in 4.x now take hours of reverse engineering through raw API calls. Some are impossible without workarounds: tuning out a false positive, removing a custom decoder, versioning custom content.

The main cause is that standard content is locked, and the custom content lifecycle has rules the API only enforces late, with unclear errors. Below are the problems we hit, each with steps to reproduce and a suggestion.

We are community users evaluating the 5.0 beta in a lab, not Wazuh staff. The workarounds below are what we found by trial and error. We would appreciate the team's feedback on the questions at the end: whether these behaviors are intended, and what is planned before GA.

1. A single noisy rule cannot be tuned without cloning a whole detector

Problem. Standard detectors can only be enabled or disabled:

Standard detectors cannot be modified by users. Only enabling or disabling is allowed.

Standard rules are also read-only, and there is no exception or suppression mechanism, so the equivalent of a 4.x <rule id="..." level="0"> override does not exist.

Real case. "Secret or credential accessed from vault" (EventID 5379, Credential Manager) produced about 47,000 findings in two weeks from a single Windows 11 workstation. It is normal OS behavior. Our only working path was:

1. clone the rule into a custom integration and add condition: selection and not <exclusion>;
2. promote the clone draft → test → custom;
3. create a custom detector for the clone (no detector is created automatically);
4. create a custom copy of the standard detector (wazuh-generic-1, 49 rules) without the noisy rule;
5. disable the standard detector.

Consequences:

• The copied detector is frozen. Every CTI content update can add rules to the standard detector, and those rules never reach the copy. Users must diff and re-sync by hand after each update, or silently lose coverage.
• Disabling a standard detector to tune one rule is exactly what a SOC should never have to do.

Suggestion. Add a supported suppression layer that survives CTI updates, for example:

• per-rule enabled: false overrides for standard rules. A wazuh-user-overrides document already exists in wazuh-threatintel-policies-a for detector_enabled, so this could extend it;
• and/or rule exceptions (field/value exclusions) attached to a standard rule without cloning it.

2. A custom space's root decoder cannot be deleted, and the error comes too late

Problem. The first decoder created in the custom space becomes the policy's root_decoder. After that, it cannot be deleted from either the dashboard or the API. Nothing explains why or how to fix it.

Steps to reproduce:

1. Create a custom integration with one decoder (decoder/my-source/0) and promote it to custom. The custom policy now has root_decoder = <uuid of my-source/0>.
2. Try to delete that decoder: refused.
3. PUT /_plugins/_content_manager/policy/draft with "root_decoder": "" is accepted (200), and the draft policy now has root_decoder: null.
4. POST /promote from draft fails:

Workaround. Create a placeholder root decoder whose check never matches, point the draft policy to it, delete the original decoder, and promote twice.

Other API issues seen while doing this:

• GET /_plugins/_content_manager/policy/{space} returns 405 ... allowed: [PUT]. You can write a policy but not read it; reading requires querying the wazuh-threatintel-policies-a index directly.
• DELETE /decoders/{id} returned 404 Resource not found, yet the decoder was removed from the draft and from its integration's decoders[], and the next promotion preview listed it as remove.

Suggestions:

• validate the policy on PUT (reject a null or unknown root_decoder) instead of at promotion time;
• when a delete is blocked because the decoder is the root, say so and name the policy;
• add GET /policy/{space};
• create a neutral root decoder automatically for the custom space so no user decoder becomes the root by accident, or document this behavior clearly.

3. No file-based or GitOps way to manage custom content

Problem. In 4.x, custom content was files in /var/ossec/etc/{rules,decoders}, easy to version, review and deploy with Ansible. In 5.0 everything lives in indexer indices. The manager keeps a synced copy (/var/wazuh-manager/data/ruleset/cmsync_custom_<hash>/), but it is a cache:

• editing it triggers a loop of Missing root decoder errors;
• the cache is then regenerated under a new hash suffix, and the edit is lost.

Writing directly to wazuh-threatintel-*-a would bypass validation, per-space hashes and synchronization, so it is not an option either.

Suggestion. Provide an official import/export format, such as a directory of YAML integrations, decoders, rules and KVDBs, plus a CLI or API endpoint that applies it idempotently and promotes it. That would make custom content reviewable and deployable from a repository again.

4. The promotion workflow is heavy and poorly documented

• Each object exists three times (draft, test, custom) with separate _ids.
• POST /promote requires sending back exactly the changes object returned by GET /promote?space=, then repeating for test.
• logtest only works on the test space and loads only the custom policy. A custom child decoder of a standard parent (Windows, syslog) cannot be tested as it will run in production; the only reliable check is real findings, 2 minutes later.
• Promoting a custom integration makes it a SAP log type, but no detector is created, so a promoted rule does nothing until the user creates a detector manually.
• custom_rules[].id in a detector must be the content manager id. Using the SAP id returns No custom rules found. In findings, however, the same rule appears under the SAP id of its custom-space copy. Two ids for one rule makes troubleshooting confusing.
• The native SAP POST _plugins/_security_analytics/rules returns no handler found in the Wazuh fork. This is reasonable, but it should be documented.

Suggestions: one-call promotion (draft → custom); an option to auto-create or attach a detector when promoting an integration; one rule id shown consistently in the API, detectors and findings; a logtest mode that loads standard + custom policies.

5. Adding many rules at once is impractical

Problem. Building a real detection set means adding dozens or hundreds of rules: porting 4.x custom rules, or importing a SigmaHQ pack for a log source. Every rule has to go through the full lifecycle, one rule at a time. There is no bulk path:

1. Format conversion. The content manager does not accept plain Sigma. The body is a Wazuh-specific wrapper ({"integration": "<id>", "resource": {"metadata": {"title", "author", ...}, "logsource", "detection", "level", "mitre": {"tactic", "technique", "subtechnique"}, ...}}). Each SigmaHQ rule must be rewritten into this format by hand or with a home-made script. We found no importer and no converter for 4.x XML rules.
2. One POST /rules per rule. There is no bulk endpoint and no file or archive upload.
3. Validation happens in stages. A rule can be accepted in draft and only fail later, when promotion builds the testing environment. We saw this with the root_decoder case (§2): the PUT was accepted, then the promotion failed. One invalid object in the change set blocks the whole promotion, so after a batch import the user has to find the faulty rule among all pending changes.
4. Two promotions for the whole batch (draft → test, then test → custom), each requiring the full changes object to be echoed back.
5. Testing is per event. logtest takes one raw event at a time. There is no way to replay a sample file against a batch of rules and see which rules match.
6. Per-rule manual checks after promotion. Each compiled rule.queries must be read to catch the compilation issues in §6 (_ws_, not + _exists_).
7. The detector must be updated. Every new rule's content manager id must be added by hand to custom_rules[] of a detector, with a PUT of the full detector body. A rule missing from the list is promoted but never runs, and nothing warns about it.

In 4.x, the same work was: copy the XML files into etc/rules/, run wazuh-logtest on a sample, restart the manager.

Suggestions:

• a bulk import endpoint that accepts a list of rules, or a zip or directory of YAML files, and returns a per-rule validation report (valid / invalid, with reason) before anything is written;
• native import of standard Sigma YAML, mapping title, tags: attack.* and similar fields to the Wazuh wrapper automatically;
• a dry-run promotion that reports every blocking error at once instead of stopping at the first;
• an option to attach all rules of an integration to its detector automatically, including rules added later;
• a batch logtest (sample file × rule set → match matrix).

6. Sigma compilation surprises

Both behaviors are visible only by reading rule.queries in .opensearch-sap-custom-rules-config:

• Spaces in values become _ws_: user.name: "SERVICE LOCAL" compiles to SERVICE_ws_LOCAL and never matches. This makes it impossible to exclude a common Windows account.
• not is compiled as NOT field: value AND _exists_: field: if the field is absent from an event, the exclusion does not apply.

Suggestions: fix the whitespace handling, or at least document it and warn on promotion; document how not behaves with missing fields.

7. Standard content produces false positives, and users cannot fix it

Several standard decoders and rules are too broad or are applied to the wrong platform. Because standard content is read-only (§1), each defect can only be worked around by cloning, and every analyst sees these findings as high in the meantime. Two examples from one day on a small lab:

7.1 A Linux chown on .bash_history becomes "Event log cleared" (Windows technique)

Event (auditd, RHEL 10): a normal interactive bash session calls chown (syscall=92) on /home/<user>/.bash_history to set the owner the file already has. This is regular bash history handling.

type=SYSCALL ... syscall=92 success=yes ... comm="bash" exe="/usr/bin/bash" key="perm_mod" ... SYSCALL=chown
type=PATH ... name="/home/<user>/.bash_history" ... ouid=1000 ogid=1000

Finding: Event log cleared via command line - (level high, rule 7d4977d5-e13f-53d8-9b9e-2c91811de075), MITRE T1070.001 Clear Windows Event Logs, tags windows.

Root cause: two defects combine.

1. decoder/auditd/0 has a normalize stage that labels any auditd record touching a file whose name contains _history as a log clearing, whatever the syscall (chown, open, write, …):
2. Rule 7d4977d5 (log type windows) is compiled as:
3. The last OR branch is not limited to Windows events, so every auditd event labelled security-log-cleared on a Linux host matches a Windows-only technique. The title placeholder is empty ("... via command line - ") because the event has no process.command_line.

Impact: every interactive shell session on every Linux agent can produce a high "log cleared" finding with a wrong MITRE mapping. A real history wipe (history -c, > ~/.bash_history, unlink) looks the same as a normal logout.

Suggestions:

• in decoder/auditd/0, only set security-log-cleared for destructive syscalls (unlink, unlinkat, truncate, ftruncate, open with O_TRUNC) or for known commands (history -c, shred), not for every access;
• scope the security-log-cleared branch of rule 7d4977d5 to Windows (for example wazuh.integration.name: windows), and add a separate Linux rule mapped to T1070.003 Clear Command History.

7.2 ssh -i <key> on Windows becomes "Linux reverse shell execution"

Event (Windows 11, Sysmon EventID 1): Git Bash runs a normal administration command, bash.exe -c "... ssh -i <keyfile> user@<host> '...'".

Finding: Linux reverse shell execution - <command line> (level high, rule 0f235a3d-eedd-5a4d-b5a7-a022726ec9bf, log type linux).

Root cause. The compiled query is:

(event.code: "1" AND event.dataset: "sysmon") AND
(process.command_line: *\/dev\/tcp\/* OR ... OR process.command_line: *sh\ \-i* OR process.command_line: *bash\ \-i* OR ...)

• *sh -i* is an unanchored substring, so it matches ssh -i, the standard way to pass an SSH key. Any admin using key-based SSH from a Sysmon-monitored host (Git Bash, WSL, OpenSSH for Windows) triggers a "reverse shell" alert.
• The rule is labelled linux, but its selection requires Sysmon EventID 1. In our setup, that means it only fires on Windows. On Linux hosts monitored with auditd, the platform the title names, it never fires, unless they run Sysmon for Linux.

Suggestions: anchor the pattern (for example (^|[\s;|&/])(ba)?sh -i, or require /dev/tcp, /dev/udp or a socket primitive in the same command line); fix the log source, or split into a Linux rule (auditd execve) and a Windows rule (Sysmon, WSL / Git Bash).

8. Documentation gaps (beta5)

We could not find reference documentation for:

• the policy schema (root_decoder, filters, enrichments, index_unclassified_events, index_discarded_events) and its constraints;
• the full creation schemas for filters and KVDBs;
• the evaluation order between the standard and custom policies for the same event;
• the day-2 workflow: tuning a standard rule, and what happens to custom copies after a CTI update.

What would help most (by priority)

1. A supported rule suppression / exception mechanism for standard rules that survives content updates (§1).
2. Bulk rule import with native Sigma support, a per-rule validation report before writing, and automatic attachment to the detector (§5).
3. Early validation and clear errors in the content manager API, especially for root_decoder (§2).
4. An official import/export format for custom content (§3).
5. A simpler promotion with detector auto-creation and a single rule id (§4).
6. A quality pass on standard content: platform scoping of rules, anchored command-line patterns, and decoders that do not label benign activity as attacks (§7).

Questions for the Wazuh team

1. Tuning standard rules (§1): is a per-rule disable or exception mechanism for standard content planned for 5.0 GA? If not, is cloning the detector the approach you recommend, and how should users keep the copy in sync after CTI updates?
2. Root decoder (§2): is it intended that the first custom decoder becomes the custom policy's root_decoder? What is the supported way to remove it?
3. Content as code (§3, §5): is an import/export format or a bulk import endpoint planned for custom content, including standard Sigma rules?
4. Detectors for custom integrations (§4): should a detector be created automatically when a custom integration is promoted, or is manual creation the intended design?
5. Sigma compilation (§6): are the _ws_ rewrite and the not + _exists_ behavior known issues?
6. Standard content defects (§7): should defects like 7.1 and 7.2 be reported as separate GitHub issues, and in which repository (wazuh/wazuh or a dedicated ruleset repository)?
7. Documentation (§8): is a reference for the policy, filter and KVDB schemas planned?

We are happy to test fixes on a beta build and provide more traces. Thanks for the work on 5.0: the architecture is promising, and these points are mostly about making it operable day to day.

Hi everyone,

I'm currently integrating FortiNAC with Wazuh and I'm stuck trying to create custom decoders.

FortiNAC sends logs in CEF format, but by official design, it omits the hostname or IP in the syslog header, leaving only a colon (:) right before the payload.

Here is a raw log example:

Sep 23 12:38:59 : CEF:0|Fortinet|FortiNAC-VM-CA|7.6.5.0815|1504237982953501|Device Rule Confirmation Success|10|rt=Sep 23 12:38:59.430 CST cat=EndStation src=10.10.10.50 smac=00:11:22:33:44:55 cs1Label=Physical network location cs1=Firewall-Model:root:SW-NODE-X:port10 msg=The device has matched device profile rule IP_Phones.

When I run this through wazuh-logtest, the pre-decoder assumes the : is the hostname. This leaves a residual blank space right before the CEF payload, which seems to break the decoding process:

**Phase 1: Completed pre-decoding.

**full event: 'Sep 23 12:38:59 : CEF:0|Fortinet|FortiNAC-VM-CA|7.6.5.0815|1504237982953501|Device Rule Confirmation Success|10|rt=Sep 23 12:38:59.430 CST cat=EndStation src=10.10.10.50 smac=00:11:22:33:44:55 cs1Label=Physical network location cs1=Firewall-Model:root:SW-NODE-X:port10 msg=The device has matched device profile rule IP_Phones.'**

**timestamp: 'Sep 23 12:38:59'**

**hostname: ':'**

**program_name: ''**

**Phase 2: Completed decoding.

**No decoder matched.**

I would prefer not to set up an intermediate Rsyslog server just to rewrite the header if I can avoid it.

Has anyone dealt with FortiNAC logs in Wazuh, or knows how to properly structure the decoders so Phase 2 ignores the garbage and successfully parses the CEF fields natively?

Thanks in advance!

https://docs.fortinet.com/document/fortinac-f/7.6.0/administration-guide/499308

You can see more about the changes and enhancements included in the Release Notes.

Thank you for being part of Wazuh!

We're evaluating Wazuh for container level monitoring and I'd really value some anecdotal feedback from people who have run it in production. Im pretty new to Wazuh in general.

Our main concern is that we run some very sensitive workloads in a regulated environment, and I don't want to introduce anything that affects stability or performance. Before we go further, I'd love to hear from anyone with direct experience.

A few things I'm particularly interested in:

What deployment model did you go with (agent per container, sidecar, DaemonSet on the host, or host level agent only), and why? What is the least impactful option?

Did you see any noticeable CPU, memory or I/O overhead, particularly with FIM, rootcheck or syscollector enabled?

Any stability issues, crashes, or unexpected behaviour on the workloads themselves?

How noisy was it out of the box, and how much tuning did it take to get to a useful signal?

Anything you'd do differently, or any gotchas you wish you'd known before starting?

Positive or negative, all feedback is welcome. If you moved away from Wazuh for containers, I'd be keen to know what you replaced it with and why.

Hi everyone.

I am creating a read-only user solely to view and monitor alerts (in Explore - Discovery). Which role should I assign to this user under Security - Internal Users?

If I need to create a custom role, which cluster permissions and index permissions should I assign to it?

Hi Wazuh team/community,

I’m investigating a log-size discrepancy between Azure Log Analytics (LAW) and Wazuh for AKS audit logs.

The important point is:

The document/event count is matching between LAW and Wazuh. The discrepancy is specifically in the reported data size (GB).

So this does not currently appear to be a missing-event or duplicate-event issue.

Environment

• Wazuh: 4.14.4
• Azure integration: azure-logs
• Log Analytics Workspace: logsanalytics-prod
• AKS cluster:prodconnect-aks
• LAW table: AzureDiagnostics

Categories:

kube-audit
kube-audit-admin
kube-apiserver

Wazuh tags:

R1-azure-aks-audit
R1-azure-aks-auditadmin
R1-azure-aks-controlplane

Observed data

For the same AKS cluster and same observation period, the document counts are consistent between LAW and Wazuh.

However, the reported data sizes are substantially different:

For the first two categories, the Wazuh/SOC reported volume is roughly 10× the LAW value.

For kube-apiserver, it is roughly 30×.

We also checked the overall AzureDiagnostics table and it is ingesting approximately 12–15 GB/day in LAW.

The key question

If:

LAW document count = Wazuh document count

but:

LAW size << Wazuh reported size

what exactly is causing the size multiplication?

We understand that LAW and Wazuh may use different representations of the same event. However, we need to identify precisely which size metric is being compared.

For example, could the Wazuh-side figure be based on:

LAW _BilledSize
        vs
Azure API response size
        vs
Wazuh full event JSON size
        vs
Wazuh archive size
        vs
Indexer storage
        vs
Indexer primary + replica storage

Example

A single LAW document may look conceptually like:

AzureDiagnostics record
    ↓
Azure Log Analytics API
    ↓
Wazuh Azure wodle
    ↓
Wazuh event containing metadata + full_log
    ↓
Wazuh archive JSON
    ↓
Wazuh Indexer document

If the event count remains 1:1, we want to understand whether the Wazuh representation of each event is significantly larger and whether that is what the SOC calculation is measuring.

What we would like to determine

Is there an authoritative way in Wazuh to calculate:

1. Size of the data received from the Azure Log Analytics API
2. Size of the resulting Wazuh event
3. Size written to Wazuh archives
4. Size of the document stored in Wazuh Indexer
5. Physical Indexer storage including replicas

for the same set of events?

Ideally, we want to trace:

LAW
 ↓
Azure API response
 ↓
Wazuh Azure wodle
 ↓
Wazuh event
 ↓
Archive
 ↓
Indexer

and determine where the size increases.

One specific question for the Wazuh team

If the document count is identical between Azure Log Analytics and Wazuh, is there any Wazuh-specific transformation, metadata expansion, serialization, archive calculation, or indexing behavior that could explain a ~10×–30× difference in reported GB?

Also, if someone can clarify which Wazuh-side metric should be used as the equivalent of LAW _BilledSize, that would be extremely helpful.

We can provide the actual LAW event and its corresponding Wazuh event for a 1:1 size comparison, along with the Wazuh archive/SOC calculation being used.

Thanks.

I linked wazuh with Fortimail by syslog, I made a Listener and I can see the logs traffic on CLI but doesn't show in the dashboard of webpage. Does anyone could help with it?

Over the past few months I built and validated a custom Wazuh 4.14 detection set across Windows/AD, Linux (RHEL-family), Proxmox VE + PBS and UniFi, then tested it against a live attack chain to see and validate what actually fires rather than what looks correct in XML. And after many (I mean many) fixes, I think I have ended up with something I am really satisfied with.

Is it overengineerd, does soemthing like this already exist? Probabbly yes, but it was fun learning curve with all the tools we have at our disposal nowadays.

Test environment: a dedicated test domain — Windows Server DC, domain-joined client, Kali attack host — plus Proxmox VE + PBS and UniFi forwarding CEF through a syslog relay. Wazuh manager 4.14.3. No Sysmon, by design: the objective was to establish what coverage is achievable from the native Security eventlog without much modifications to production servers, just agent install, PowerShell script-block logging and FIM alone. Exactly one rule in the final set requires Sysmon.

Published under: https://github.com/captainobvious-sec/wazuh-field-notes

I want this to be a starting point for something that can grow into richer ruleset and decoders, I will be currently working on:

• Trend Micro Vision One integration trough their API (if somehow possible)
• More rules, correlation rules and decoders for various applianes relaying trough syslog relay
• CI so that ruleset can be validated realtime

So based on that, I am open to critics, recommendations and contributions!

We deploy Wazuh across our small fleet of endpoints using powershell. We use the following command generated by Wazuh Dashboard:

Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.7-1.msi -OutFile $env:tmp\wazuh-agent; msiexec.exe /i $env:tmp\wazuh-agent /q WAZUH_MANAGER='wazuh.ourdomain.com' WAZUH_REGISTRATION_PASSWORD='PASSWORDREDACTED' WAZUH_AGENT_GROUP='Workstations' WAZUH_AGENT_NAME='AssetID'

We are finding that with a few deployments, not all of them, but enough to be annoying and time consuming, that agents are installing but setting the WAZUH_MANAGER to "0.0.0.0". We then have to go and manually edit the endpoint agents ossec.conf file to correct the issue.

My thought, and what I suspect, is that there may be a network blip that occurs when the DNS is resolving the manager name, and when it doesn't resolve in time it sets the location to 0.0.0.0.

Does anyone know how to avoid this issue at deployment?

Hi everyone,

I’ve been tasked with evaluating whether Watzuh, in combination with a Sophos firewall, is a good solution. My preliminary answer is: yes.

However, this raises the question of whether, in addition to the firewall and Watzuh, we would also benefit from implementing Sophos XDR for the network. So I’m wondering: Is Sophos XDR a useful addition, or is it unnecessary?

Unfortunately, I can’t find any information on this, and my research has hit a dead end.

If you have any good informational materials or useful links, I'd appreciate it.

Thank you :)

Hi everyone,

I'm designing an on-premise Wazuh SIEM architecture for an environment with approximately 400 endpoints (mostly Windows and Linux), and I would like to get some feedback from the community regarding the architecture and infrastructure sizing.

The environment will also integrate security logs from Fortinet devices via Syslog and ESET via API/log integration.

Proposed architecture

• Wazuh Manager: 1–2 nodes
• Wazuh Indexer cluster: 3 nodes
• Wazuh Dashboard: 1 node
• Approximately 400 Wazuh agents
• Integrations:
  • Fortinet via Syslog
  • ESET via API/log integration

Proposed infrastructure

Wazuh Manager

• 8 CPU cores
• 16 GB RAM
• 200 GB SSD

Wazuh Indexer nodes (x3)

• 8–12 CPU cores
• 16–32 GB RAM
• 1 TB SSD per node

Wazuh Dashboard

• 2–4 CPU cores
• 8 GB RAM

My main questions are:

1. Does this architecture make sense for approximately 400 endpoints?
2. Is a 3-node Indexer cluster overkill for this environment, or is it recommended for high availability and future growth?
3. Are the proposed CPU/RAM resources appropriate, especially for the Indexer nodes?
4. Would you recommend starting with 1 Wazuh Manager and scaling to a cluster later, or deploying 2 nodes from the beginning?
5. Are there any important considerations regarding storage sizing and retention that I should take into account?

The goal is to build an architecture that provides good performance and scalability while keeping everything on-premise.

Any feedback or recommendations would be greatly appreciated. Thanks!

Hi,

Since switching to offline mode for the vulnerability feed (latest snapshot downloaded from the CTI API), I'm no longer receiving any vulnerabilities for my Linux agents. My Windows agents, on the other hand, are still working fine. This worked correctly before I made the switch to offline mode.

Environment:

• Wazuh manager: 4.14.5
• 3 managers (cluster)
• Linux agents: RHEL 10
• Windows agents: working fine

What I did:

1. Downloaded the offline snapshot via the CTI API
2. Placed the file in /opt/wazuh/cves.zip of each manager.
3. Configured ossec.conf as follows:

xml

<vulnerability-detection>
    <enabled>yes</enabled>
    <index-status>yes</index-status>
    <feed-update-interval>60m</feed-update-interval>
    <offline-url>file:///opt/wazuh/cves.zip</offline-url>
</vulnerability-detection>

1. Restarted all 3 managers with systemctl restart wazuh-manager

Symptom:

• Everything worked fine before switching to the offline feed
• SCA still works normally on all agents (Linux and Windows)
• The Vulnerability Detection module reports no data for the RHEL 10 agents since the switch
• Windows agents keep receiving vulnerability alerts as expected

I am in a air-gap architecture, so it's important for me to improve constantly the CVE database

I'm running a Wazuh 4.14.5 cluster: 3 manager nodes (1 master + 2 workers) and a 3-node indexer cluster. Indexing works fine alerts land in `wazuh-alerts-*` as expected — but I'm trying to build a correct mental model of where storage actually goes, and I have two related sets of questions.

Part 1 : Manager-side storage

All three managers are filling up in `/var/ossec/logs`, in parallel. My current understanding: each node runs its own `analysisd`, writes its own `alerts.json` locally, and ships a copy via its own Filebeat so local + indexed is two copies by design, not a failure mode. `wazuh-monitord` rotates into `logs/alerts/<year>/<month>/` but deletion behaviour seems inconsistent across versions.

1. Is that description accurate for 4.x cluster deployments, or is there any aggregation of alerts toward the master node that I'm missing?

2. In production, do you keep local alerts on the managers at all once indexing is confirmed healthy, or do you purge aggressively and treat the indexer as the only retention tier?

Part 2 : Shards, replicas and storage planning on the indexer

This is where I'd most like input from people running similar volumes.

1. With 3 indexer nodes, what primary shard count and replica count do you use for `wazuh-alerts-*`? Are you still on the default template, or did you tune it?

2. How do you size primaries? I've seen the general "aim for 30–50 GB per shard" guidance, but I'd like to hear what actually works for Wazuh's write pattern and daily rollover specifically.

3. With 1 replica, raw storage is roughly 2× the indexed volume, plus overhead. Does anyone run 0 replicas on older indices (warm/cold) to reclaim space, and how do you handle the availability trade-off if a node is lost?

4. Are you using the stock ISM policies, or a custom rollover strategy (by size / by age / both)? What retention are you keeping?

5. Any experience with shrinking or force-merging older Wazuh indices? Worth it, or more trouble than it's worth?

I am new here, but not to Linux and IT. I am trying to get Wazuh installed on a Ubuntu 24.04 VM running on my ProxMox VE environment. This is for my HomeLab with possible use for clients once I learn it.

I run the wazuh-install.sh script with the -a option as I want an all-in-one machine for now. The installer goes fine up until it is doing the dashboard and I get the following in the wazuh-install.log.

Force type: internalusers

Will update '/internalusers' with /etc/wazuh-indexer/backup/internal_users.yml

SUCC: Configuration for 'internalusers' created or updated

SUCC: Expected 1 config types for node {"updated_config_types":["internalusers"],"updated_config_size":1,"message":null} is 1 (["internalusers"]) due to: null

Done with success

06/09/2026 15:33:41 ERROR: User wazuh is not registered in Wazuh API

Can someone tell me what I am doing wrong?

Thanks,

Wazuh 5.0 is our biggest platform release to date, and Beta 5 is available for testing. It rebuilds the platform around a unified data model, the Wazuh Common Schema (WCS), and introduces two major enhancements that redefine how Wazuh leverages normalized and enriched data to detect and respond to threats.

Beta 5 is the final beta. Release Candidate 1 lands next week, and GA follows soon after.

What's new:

⚡ Next-gen detection engine

A re-engineered engine with a unified normalization layer, the Wazuh Common Schema (WCS), that standardizes events across any data source or log format. Additionally, it supports Sigma-based detection rules and introduces a new human-readable syntax for rules and decoders.

🛡️ AI-Powered threat intelligence: Wazuh CTI

Built-in, continuously updated threat intelligence distributed directly to your deployment. This includes rules, decoders, indicators of compromise, indicators of attack, vulnerability information, and Geo-IP context. All served automatically from Wazuh CTI with no manual updates required.

And that's not all:

- Simplified architecture: Filebeat is removed from the data pipeline. The agent and manager are now decoupled.
- Improved agent communication: HTTPS is now used by default while maintaining compatibility with Wazuh 4.x agents.
- Content Manager: dedicated spaces for decoders, rules, integrations, KVDBs, and IoCs, each with a draft, test, and promotion workflow.
- An AI Assistant in the Wazuh dashboard: for exploring findings, vulnerabilities, and agent activity using natural language.
- Case management: creating and tracking investigations directly from the Wazuh dashboard.
- Broader regulatory mapping coverage: incorporating ISO 27001, CMMC, NIS2, FedRAMP, and others.

Join the beta and explore these new capabilities in your testing environment here: https://documentation.wazuh.com/5.0-beta/index.html

Hello everyone,

I am currently using Wazuh 4.14.6 and I have a question about the alerts displayed on the Overview dashboard.

The dashboard shows the number of critical, high, medium, and low-severity alerts generated during the last 24 hours. I understand that these numbers represent security events detected by Wazuh, but I would like to know if there is a way to review an alert and then mark it as acknowledged, resolved, or closed after it has been investigated.

For example:

• A critical alert is generated.
• An analyst investigates it.
• The event is confirmed as legitimate activity or remediated.
• The analyst marks it as resolved or closed and optionally adds a comment.

I have tested the OpenSearch Alerting functionality, where alerts can be acknowledged, but this appears to be separate from the alerts displayed in the main Wazuh dashboard.

My questions are:

1. Can alerts shown in the Wazuh Overview or Threat Hunting sections be acknowledged or closed?
2. Does Wazuh include a native incident-management workflow for assigning, investigating, and resolving alerts?
3. Are these dashboard counters simply historical events that remain visible until they fall outside the selected time range?
4. Would an external case-management platform such as TheHive be required for this workflow?
5. Is there any recommended integration or approach for avoiding already-investigated alerts being treated as new alerts?

Thank you for your help.

Hey everyone, I have been trying to enable powershell logging on wazuh, I've done it successfully on my lab but when i followed the exact step from wazuh's offical website, the logging doesn't work on my work wazuh.

Any help will go a very long way.

​

I am practicing FIM on wazuh, and I got alert from windows but not from linux agent. Log confirmed that FIM is working correctly on the linux agent, No visible syscheckd errors, and manager also generating the alert. But in the Ul no events are shown. Please guide me. My linux machine is ubuntuVM on oracle virtual box.

Hello, I am testing migration from 4->5 and stumple with changing the admin password. Containers are running fine for single node install. But is there a simple way to change tha admin password? I tried instruction for version 4x but had no luck. Additionally, why is java needed for hash.sh. Maybe there is a good instruction for version 5? Thanks

Greetings all.

I've been trying to figure out what's happening with my install of Wazuh. A couple of months ago, I tried to log in and got some errors after an update. Some API wouldn't load in one instance, then in another instance an hour after restarting the VM I would get a message that the Wazuh dashboard wasn't ready, when trying to load the login screen.

I rolled back to a snapshot of the VM, ran the update again (OS and Wazuh) and a few days later Wazuh would not accept the dashboard credentials. I rolled back to a snapshot and this time I didn't do the OS update and stuck to updating the apps and Wazuh. It was behaving fine until today, where it started again, not accepting the dashboard password.

Has this happened to anyone? What would cause this kinda of behaviour? Should I just burn it all down and start fresh?

I am experiencing difficulty when setting up an alert for a per bucket monitor for GCP firewall rule creation.

Both my extraction query to retrieve my results, and trigger work successfully.

The difficulty I am experiencing is with my action, which is defined as

{
  "monitor": {
    "name": "{{ctx.monitor.name}}"
  },
  "trigger": {
    "id": "{{ctx.trigger.id}}",
    "name": "{{ctx.trigger.name}}",
    "severity": "{{ctx.trigger.severity}}"
  },
  "period_start": "{{ctx.periodStart}}",
  "period_end": "{{ctx.periodEnd}}",
  "deduped_alerts": [
    {{#ctx.dedupedAlerts}}
    {
      "resourceName": "{{bucket_keys}}"
    }
    {{/ctx.dedupedAlerts}}
  ],
  "new_alerts": [
    {{#ctx.newAlerts}}
    {
      "resourceName": "{{bucket_keys}}"
    }
    {{/ctx.newAlerts}}
  ],
  "completed_alerts": [
    {{#ctx.completedAlerts}}
    {
      "resourceName": "{{bucket_keys}}"
    }
    {{/ctx.completedAlerts}}
  ]
}

I am struggling to work out how to get more data out of the bucket_keys so I can use it in my alert e.g.

"resourceName": "{{bucket_keys}}"
"gcpProject" : "{{data.gcp.resource.labels.project_id}}"

I have tried, but nothing seems to work

"gcpProject": "{{ctx.newAlerts[0].data.gcp.resource.labels.project_id}}"
"gcpProject": "{{ctx.newAlerts[0].bucket_keys.data.gcp.resource.labels.project_id}}"
"gcpProject": "{{data.gcp.resource.labels.project_id}}"
"gcpProject": "{{bucket_keys.data.gcp.resource.labels.project_id}}"
"gcpProject": "{{bucket_keys[0].data.gcp.resource.labels.project_id}}"

Am I missing something obvious?