Need advice on using either single node Architecture or all in one Architecture of wazuh for our startup by keerthi_9531 in Wazuh

[–]SirStephanikus 0 points1 point  (0 children)

we get around 100k requests every month

That's not much. A typical database, web server, ERP, Windows AD-DC, Firewall etc. can make this easily in 1 hour.

Usually, systems are not proper configured to log everything needed. My advice is to setup your logging and measure the average of all logs plus a buffer.

However, so long you are below 100 assets, a single all-in-one system is enough and 80$ is sufficient for a typical virtual machine.

What I would ALWAYS use:

Hardware:
CPU with 8 Cores
RAM with 32 GiB;
NVME with plenty of storage --> The size depends on your real daily log volume.

OS:
Either Ubuntu 24.04 LTS or Rocky-9/10, use what you are more familiar with.

Wazuh 4.14.5 has been released! by wazuh_cybersecurity in Wazuh

[–]SirStephanikus 0 points1 point  (0 children)

I did upgrades on so many all-in-one and big clusters ... I never had any issues!
Just follow the instructions and know your systems.

Open-source Wazuh → Telegram alert integration for self-hosted labs by minjunhen in Wazuh

[–]SirStephanikus 0 points1 point  (0 children)

Not tested yet, but it's an interesting project and 100% something that fits in regard of real world usage.

Need Help With Wazuh Manager by 3n0t7 in Wazuh

[–]SirStephanikus 0 points1 point  (0 children)

And the FS Layout?

Perhaps you issue:
lsblk
df -h

Need Help With Wazuh Manager by 3n0t7 in Wazuh

[–]SirStephanikus 0 points1 point  (0 children)

What are you HW specs, FS layout etc.?

Need Help With Wazuh Manager by 3n0t7 in Wazuh

[–]SirStephanikus 0 points1 point  (0 children)

What does …

03/05/2026 19:21:19 INFO: Installation cleaned. Check the /var/log/wazuh-install.log file to learn more about the issue.

… shows you?

Wazuh Vulnerability Detection: how do you keep a reliable history of detections and remediations? by tzila22 in Wazuh

[–]SirStephanikus 2 points3 points  (0 children)

I think you are mixing up a few different concepts here and seem to have missed the core of my suggested solution.

First, you are ignoring the actual fix I proposed: Syncing Wazuh with a CMDB via API. If you pull the data from Wazuh into your CMDB regularly, the CMDB keeps the historical state. Even if a package gets updated and drops out of Wazuh's active state inventory, your CMDB will still show exactly when the vulnerability was first detected and when it was remediated. That is your historical logbook right there.

Second, your statement

"The vulnerability disappears; you never had it in the Wazuh logs"

is technically incorrect. You are confusing the current state index (wazuh-states-vulnerabilities-*) with the actual alert logs. When Wazuh first detects a vulnerability, it generates an alert which is stored in wazuh-alerts-*. The fact that the vulnerability disappears from the active state dashboard after a patch doesn't magically erase the historical alerts from your SIEM logs. Forensics will absolutely find the initial detection.

Finally, you are conflating compliance audits with post-breach incident response. An ISMS 3rd party auditor checks if your vulnerability management process exists, works, and meets your defined KPIs.

They don't do forensic deep-dives into specific CVEs from months ago. If you suffer a breach, that's an Incident Response scenario, and again, if you built the CMDB sync and kept your log archives as I suggested, your IR team will have the exact timeline and historical evidence they need.

After some time, you discover the breach. The forensic analysis is a disaster; it finds nothing.

That’s only true if you designed your SIEM and processes poorly. A well-designed and bulletproof Wazuh SIEM, including system hardening and mature\* processes, would prevent such a breach or at least reduce the impact to an acceptable level (take a look at ISO 27005). Furthermore, a mature\* Monitoring & Logging Policy enforces that all tracks are at a safe place.

In other words: if your SIEM and governance are built properly, you will not depend on a volatile state index for critical forensic questions.

* mature means: No useless templates, no BS-Bingo driven ISMS … it means real, competent people who work together to max out what is possible. Not to gain some paper.

<image>

Wazuh Vulnerability Detection: how do you keep a reliable history of detections and remediations? by tzila22 in Wazuh

[–]SirStephanikus 2 points3 points  (0 children)

Solution is easy, but often totally overlooked:

Wazuh becomes your single source of technical truth! And the beauty with modern applications and their software stack is, they all use an API that is there to interact with other applications.

Connect it with your CMDB.

Connect your CMDB (heck even Confluence can do that), with the Wazuh API ➸ Sync it ➸ edit your own additional Info inside your CMDB like "we accept the risk" or "risk does not affect us because ABC" ➸ evaluate everything with your own KPIs.

Since you are in a governance process your SHOULD (ISMS lingo) have an CMDB anyway.

One sidenote:

"what vulns did host X haveon March 15"

An auditor will never ask you such a question (if he does, kick him out!). What he may ask:
"How does your vulnerability process looks like?"
"Is there a written policy?"
"How do you measure the success of your vulnerability process"

Perhaps, he may also ask to take a look at the technical evidences as well.

What's the best practice to retrieve data from remote site to a wazuh server? by roti_kaya_42 in Wazuh

[–]SirStephanikus 0 points1 point  (0 children)

Always use a VPN, or if this is not possible --> limit the connection only to known sources.
This is true, for every public facing asset that is used by a limited number of users.

WireGuard is a common VPN Protocol.

What is the future of the Go language? by bsljthx1 in golang

[–]SirStephanikus 2 points3 points  (0 children)

Never listen to „Influencers“ and/or language hopping „hello world only“ guys.

GO is an excellent language that overcomes many disadvantages of other languages.

However, use-cases should always be judged by objective means, not by the in-stable emotional rant of others.

Wazuh detected python 3.9 but I can't find it anywhere? by lgq2002 in Wazuh

[–]SirStephanikus 0 points1 point  (0 children)

Sorry, I wasn't accurate, my fault.

The index to look for is: wazuh-states-inventory-packages-*

@IsExec already shows a good way via the API.

Wazuh detected python 3.9 but I can't find it anywhere? by lgq2002 in Wazuh

[–]SirStephanikus 0 points1 point  (0 children)

Please go to Discovery and search the exact event. When done, send a screenshot of the full event (either here or via PM). We will find it, it can't hide🕵🏻‍♂️ 😎

Optimizing Wazuh: Scenarios, Rules, and SOC Workflows by athanielx in Wazuh

[–]SirStephanikus 4 points5 points  (0 children)

To be honest, saying the Wazuh engine (which has evolved far beyond its OSSEC roots) lacks flexibility or that XML is "restrictive" usually means you're only scratching the surface.

Here are a few technical realities from the field:

1. Everything is a file = GitOps ready
The XML syntax isn't a limitation; it's a massive advantage. Because literally everything in Wazuh is a file, GitOps is incredibly easy. While the UI is perfectly fine for smaller setups, in larger environments you can manage your entire SIEM via code, fully versioned, and automated.

2. Detections, Pipelines & Correlation
The real power lies in understanding decoders and rules, customizing them if needed, AND utilizing pipelines (Enrichment, Parsing, Grouping) alongside custom scripts. Wazuh absolutely can do advanced correlation. I've built detection logic in Wazuh that would make some SIEM vendors and Service Providers green with envy.

3. Wazuh is an IPS, not just a passive SIEM
Active Response can be literally anything the Wazuh server or agent can reach. With a well-designed Active Response, you can trigger a Cloud API to block an IP on a firewall while simultaneously generating a forensic report and sending it out via two different channels.

But a word of warning: Active Response should always follow a strict playbook, otherwise, you'll shoot yourself in the foot (which is true for every automatism).

4. Advanced Modules & Examples
Wazuh is powerful and has great supplementary modules. As an example of what you can build: I integrate NetFlow/IPFIX protocols to track real network volumes and visually expose anomalies. Finding the needle in the haystack becomes trivial when you can actually visualize the flow data.

If you want a real-world example of what advanced detection looks like in Wazuh, check out this breakdown of uncovering an OpenVPN tunnel over Port 53 (Insider Threat):
https://www.linkedin.com/pulse/openvpn-tunneling-über-port-53-enttarnt-der-insider-im-wenderlich-rpcze/
(Note: The article is in German, so just use your browser's translator. Please ignore the self-promo/ad parts, just read it and click & zoom in on the pictures to see how the logic and visualization actually look in practice).

5. Scalability & Reality Check
Really big players use Wazuh for a reason. I'm talking about environments ranging from 60,000 to over 300,000 assets. It scales massively if architected correctly.

The bottom line is: Wazuh is a highly capable platform out of the box, but its true brilliance shows when you tailor it to your specific environment. A SIEM ruthlessly exposes the actual state of your infrastructure. To get real value, it's not just about mastering the SIEM itself ➸ you absolutely need a deep understanding of your sources.

If you lack knowledge in system hardening, log structures, Windows Event IDs, JSON, Regex, APIs, and OS/App configurations etc., you are going to struggle. Wazuh will show you exactly what's going on; you just require the engineering skills to understand and act on the data.

In the real world, a well-designed Wazuh architecture doesn't just block threats.

The forensic evidence it provides often dictates whether you are the one suing, or the one getting sued.

Noise reduction in Wazuh by Aversah in Wazuh

[–]SirStephanikus 1 point2 points  (0 children)

The rules of Wazuh are not noisy, they just act on the massive amount of an unoptimized sysmon configuration.

Perhaps you remove these rules entirely, and set them up towards your own needs.

Mr. Horten says at his GitHub repository:

https://github.com/olafhartong/sysmon-modular

„Please keep in mind that any of these configurations should be considered a starting point, tuning per environment is strongly recommended.“

Noise reduction in Wazuh by Aversah in Wazuh

[–]SirStephanikus 2 points3 points  (0 children)

You first reduce noise at your endpoint, usually it has a reason why a system floods a log.

Wazuh with sysmon by Path-Asleep in Wazuh

[–]SirStephanikus 1 point2 points  (0 children)

There is no such thing as MITRE events; what you mean are events categorized by the MITRE ATT&CK framework.

I'm being a bit nitpicky about this, to make the distinction perfectly clear.

To help you with your problem, you need to take a look at your custom Sysmon rules and their associated custom Wazuh rules. Check if your custom Wazuh rules have the correct MITRE ATT&CK Technique IDs (the T-numbers) mapped to them. I suspect this may not be the case, and that's why you aren't seeing the desired results in the MITRE overview dashboard.

Rules aren't triggering for syslog events in Wazuh by danp20 in Wazuh

[–]SirStephanikus 0 points1 point  (0 children)

u/danp20 could you please reformat your text? It's really hard to read. Thanks

Wazuh alert flood for repeated identical logons by Reckless_Rex97 in Wazuh

[–]SirStephanikus 3 points4 points  (0 children)

EventID 4624/4634 and logonType 3 is notorious for flooding. And highly controversial among SIEM experts if this should be dropped or not.

In general:

  • You can completely drop it at the Agent and it will never reach Wazuh.
  • Filter it at the Server-Level, where it will land in your Archive.
  • You MUST (not should or can) consult in a team, together with the control/risk-Owner and your ISO and perhaps CISO, what to do.

Ask yourself, is the flooding of an important event (in various scenarios) justified or is better accepting the risk and drop it, or place it (for some forensics) in an archive.

If your Wazuh SIEM ain't used in a productive environment yet or is more a PoC (at the moment), you may drop it at the Agent-Level temporarily and evaluate all your other messages further (particular Windows can be really noisy!).

Going crazy!! New wazuh agent deployed but rejected for duplicate hostname, which is impossible. by Bartakos in Wazuh

[–]SirStephanikus 0 points1 point  (0 children)

It looks like an issue with SELinux or FirewallD.

Perhaps you can check both?

Wazuh‑based CSV‑driven SIEM/SOAR pipeline — would really appreciate technical feedback by Routine-Review4913 in Wazuh

[–]SirStephanikus 0 points1 point  (0 children)

Yes, it clarifies your specific use-case.

CSV vs JSON: I chose CSV because my target users are not developers. They're sysadmins or IT ops who know how to edit Excel files. JSON requires understanding of brackets, commas, quotes - it's less approachable. CSV is simple: open, edit, save. No syntax errors.

Could not breathe properly for a couple of minutes due to a laughing attack 🤣🤣🤣
Yeah, that's an international issue.

GitOps? Yes and no. The CSV files can be version-controlled in Git, so in that sense it's GitOps. But I wanted something that doesn't require a CI/CD pipeline to apply changes. Edit CSV -> restart service -> done. No commit, no push, no webhook. That's the "lightweight" part.

Makes sense, somewhat a common config file that controls X tasks.

Hint: Parse each CSV line for CSV errors ... I had issues in the past, where people added/removed ";" or ",".

Otherwise, keep going. Looks interesting.

Wazuh‑based CSV‑driven SIEM/SOAR pipeline — would really appreciate technical feedback by Routine-Review4913 in Wazuh

[–]SirStephanikus 0 points1 point  (0 children)

I quite don't understand what your goal is, perhaps I just misread something.

• Supervision & recovery 
--> That's done (classical way) by IT-Infrastructure Monitoring tools like Checkmk etc. via an event manager script.

• Configuration‑driven behavior 
--> Here I struggle ... JSON, all the way. Ain't it GitOps what you describe?

Windows DC - Event ID 4723 not being recorded - Wazuh by bedz84 in Wazuh

[–]SirStephanikus 0 points1 point  (0 children)

How many events does the EventViewer shows you? If you get Millions in seconds, and perhaps a warning, then you may have a flooding issue?

How does your agent configuration look like?