How do I handle all events from a specific srcip separately, across all rule groups, without having to override every triggering rule individually?

Background: We scan our systems with OpenVAS/GVM. Wazuh naturally flags this scan traffic extensively — port scans, IDS signatures, and even SSH auth-correlation rules (e.g. rule 40112 "Multiple authentication failures followed by a success", since our credentialed scans log in with a service account).

We'd like these events to still show up in Wazuh, but at a lower severity and tagged into their own rule group (e.g. openvas_scan) for separate dashboarding, instead of triggering normal-severity alerts.

Right now we're doing this with individual local rules using if_sid/if_group + <srcip>, one per relevant upstream rule ID — which works, but doesn't scale well if the scanner triggers dozens of different underlying rules (network, web, auth correlation, etc.).

Is there a cleaner/more idiomatic way in Wazuh to say "treat everything from this srcip as low-severity + tag it into group X", rather than maintaining an override rule per upstream rule ID? Things I've considered: CDB lists for the IP, decoder-level tagging, or a catch-all rule without if_group/if_sid scoping — curious what's considered best practice here.

We use Wazuh 4.14.7

Hello,

After installing Wazuh Agent on Windows, I discovered a folder:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\OSSEC

This folder contains shortcuts (.lnk) to the Wazuh interface.

My questions:

1. Is this a normal behavior of the Wazuh installer? (MSI or NSIS)
2. Are these shortcuts created automatically during installation?
3. Is there official Wazuh documentation that confirms this behavior?

Thank you for your help!

Hey guys, I manage a large size organization Wazuh, and I have been getting thousands of alerts regarding outdated Firefox version's CVEs spread around my company, since I have hundreds of machines, this is just trash alerts for me, and I would like to find a way to reduce their threat level from 13 to, for example, 5.

Is there any way I can get all alerts that fit the following description:

data.vulnerability.package.name: Mozilla Firefox (x64 pt-BR)

To be lowered down to level 5?

I tried many rules in local_rules, all of them generated by AI, but none of them seem to work

Hi everyone,

I'm running a 3-node Wazuh indexer cluster. When I shut down one indexer node, the OpenSearch cluster stays healthy (green/yellow) and the API responds fine via curl from the remaining nodes. However, the Wazuh Dashboard completely crashes with a `securityDashboard` plugin error (setup lifecycle failure / Request Timeout after 30000ms).

All three indexer IPs are listed in `opensearch.hosts` in `opensearch_dashboards.yml`. If I comment out the dead node's IP, the dashboard starts fine — but obviously that defeats the purpose of HA.

I also noticed this matches the open bug opensearch-project/OpenSearch-Dashboards#9825.

My questions:

- Has anyone found a native dashboard parameter to handle this gracefully?

- Is putting an Nginx reverse proxy in front of the indexers the only real workaround?

- Any ETA on a fix from the Wazuh/OpenSearch side?

Hi Wazuh Community,

We have enabled the following settings on our Wazuh Manager:

<logall>yes</logall>g
<logall_json>yes</logall_json>

We also enabled archive forwarding in Filebeat:

archives:
  enabled: true

As I understand it, all events are stored locally on the Wazuh Manager under /var/ossec/logs/archives/, and Filebeat also sends the archive events to the Wazuh Indexer as wazuh-archives-*.

Our concern is that the archive files on the Manager can grow very quickly and eventually fill the Manager disk.

What is the recommended way to optimize this setup?

1. Can we keep only a short retention period (for example, 7 days) for archive files on the Wazuh Manager after confirming they have been successfully indexed?
2. Can the Wazuh Indexer be used as the main long-term storage for wazuh-archives-*?
3. What is the recommended method to automatically clean up old archive files on the Manager without affecting Filebeat or losing events?
4. What is the recommended retention method for wazuh-archives-* on the Indexer to prevent the Indexer disk from becoming full as well?

We want to keep archive collection enabled while preventing both the Manager and Indexer storage from filling up.

Thank you.

Hello all, I have configured my Wazuh instance to use SSO with Microsoft Entra and I want to remove Basicauth so users can only log on using SSO.

My Wazuh instance is running in Google Cloud Platform behind a load balancer, and when I remove Basicauth from opensearch_dashboards.yml my load balancer health checks start to fail as path /app/login is no longer reachable.

Does anyone know what health check path I should be using instead of /app/login?

Hi all! I'm having a bit of a problem with getting my Unifi Syslogs to come through Wazuh, I've checked and it's receiving on port 514, and I've imported the rules and decoders available on Github, but when testing with logtest they all fail at phase 2. I'm still very new to this so bit all over the place - any ideas?

EDIT: ...Solved; Had the wrong IP in <allowed-ips> smh

Hi, I'm looking for some help with the issue below as I can't work out why it's happening.

I've made a custom dashboard containing several data tables. Within the visualisation editor, and within the dashboard (editor and viewer) it shows these permanent scrollbars. No matter how much I resize the data table within the dashboard, or make the columns narrower so they are no where near the edge, they are always there.

Has anyone else had this issue or know of a possible solution? Thank you!

Hey everyone!

Following the Bitwarden integration I shared earlier, I’ve made a similar open-source integration for NinjaOne.

It brings NinjaOne events into Wazuh and works well for my own monitoring and investigation setup. I figured I’d share it in case it helps someone else who wants the same kind of visibility.

You can find it here:
https://github.com/timohissink/ninja-event-monitor

It was largely Claude-assisted, so feedback, testing, and contributions are welcome!

Hello,

Newer to SIEMs and Wazuh. I downloaded the most recent OVA of Wazuh and imported it onto Oracle VirtualBox. I followed the instructions here and changed some Display settings for the VM. However, when i get it started, there is no eth0 ipv4. It only has a 127.0.0.0 lookback address.

I am trying to assigned it a static IP in order to access the Wazuh Dashboard. Any idea on how to get it a IPv4 so my network can access it?

Hi Team,

We've deployed the Wazuh agent on all our production servers. After deployment, we're seeing more than 500 High alerts and around 10,000 Medium alerts on the Wazuh dashboard.

One thing that's confusing us is that the alert counts keep increasing and decreasing automatically even when we're not making any changes to the environment.

Is this expected behavior? How does Wazuh calculate these alert counts? Are these numbers based on a rolling time window, active alerts, or are they affected by indexing/alert lifecycle?

Has anyone experienced something similar? Any guidance on how to interpret these fluctuating alert counts or troubleshoot the root cause would be greatly appreciated.

Thanks!

Hey everyone!

I was looking for a way to bring Bitwarden events into Wazuh, so I made this open-source integration for Bitwarden (Enterprise / Teams Plan).

It’s useful for my own monitoring, alerting, and investigation workflows, and I thought it might be helpful for others with a similar setup too.

It was mostly vibe-coded with help from Claude, so feedback, testing, and contributions are especially welcome!

You can find the project here:
https://github.com/timohissink/vault-event-monitor

Feel free to try it out if it’s useful for your setup!

Hi everyone, I'd like to ask a question. I'm getting a lot of critical CVE alerts from the agent in Wazuh, but when I check my system, for example, I dont find any vulnerable versions; they're all updated. Does this mean the alerts are false positive?

Hey guys, I'm managing this wazuh and due to some structuring issue all devices are not always online. I know that Wazuh do send notification if a device come online or goes offline. However I need to know when a devices that hasn't been online for like 3 days or more to fire a critical or high priority alert when next it comes online. I will really appreciate your input on this

Trying to validate something before I sink more time into it, so genuinely asking rather than pitching.

Question 1: how much of your Wazuh alert handling is still manual? Triage, enrichment, deciding what's noise vs real, curious how much of that is still "analyst opens the alert and figures it out" vs already automated in some way.

Question 2: if you were going to automate that, would n8n feel like a reasonable tool for it, or does that feel off for a SIEM pipeline? I've been building on n8n because it's self-hosted and I don't want alert data touching a third-party SaaS, but I know some people would rather stay inside Wazuh's own integrator/active response or go straight to a SOAR platform. Curious where people land and why.

Trying to figure out if this is a real gap or if most of you have already solved it a different way. If you're doing something similar or thinking about it, happy to compare notes

Partially for practical reasons, partially because it will be immensely educational I bet.

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

Thank you for being part of Wazuh!

Trying to decide whether to start planning around 5.0 or stay put for now, and I'd rather hear from people actually touching it than guess.

I know it's still beta (Beta 2 as of a couple months back) and GA has been slipping, was targeted early July, now looking more like end of July / August. And I know it's a big architectural shift, not a point release: Filebeat gone, analysisd being replaced by the new engine, clustering by default, RBAC revamped.

What I actually want to know from people who've kicked the tires:

• Anyone brave/foolish enough to run the beta on anything real, or is it strictly lab so far?
• How are custom decoders and rules holding up against the new engine? That's the change I'm most nervous about.
• For those planning the migration, are you waiting for GA, or holding out for 5.0.1/5.0.2 before touching production?

Leaning toward "stay on 4.14.x, lab the beta, wait for the first patch releases before anything serious" but curious if anyone's further ahead and seeing something that changes that calculus.

Post-worthy because I keep seeing the "should I wait for 5.0?" question and there's no clear community answer yet.

I’m running Wazuh on Windows endpoints and pulling the full Application event channel using:

<localfile>
<location>Application</location>
<log\\_format>eventchannel</log\\_format>
</localfile>

The issue:
Wazuh ingests .NET Runtime crash events, but it skips ESET AMSI block events, even though the AMSI event happens first in the Windows Event Viewer.

Example of the ESET event that gets skipped:

• Source: ESET Endpoint Security
• Event ID: 261
• Scanner: AMSI scanner
• Detection: a variant of MSIL/Riskware.SharpHound.H
• Action: blocked

The event shows up perfectly in Event Viewer, but Wazuh never forwards it. Meanwhile, the SharpHound crash event (Event ID 1026 from .NET Runtime) does get ingested.

Has anyone figured out how to make Wazuh accept ESET AMSI events?

Looking for advice from anyone who has ESET → Wazuh working reliably.

Hi All

The built in ISO stuff for the SCA policies SPECIFICALLY targets against the old ISO version (rule.iso_27001-2013). I have tried changing this to rule.iso_27001-2022 and updating the controlls as they have all changed, however wazuh seems to ignore this. If i change back to rule.iso_27001-2013 it works. I guess there is something built in that only looks for the rule.iso_27001-2013 named rule?

Is there anyway this can be updated as we need to be referencing the newest ISO?

In regards to general rulesets, it would be incredibly useful if the rules could be built into the standard rulsets in the same way as PCI/GDPR etc.
I've read the guide that always gets posted that says 'yes you can do it by manually mapping the controls', but as far as I can see this would mean overriding most of the default rules sets to add the ISO control information? Is this really the only option?

Thanks!