OSSEC vs Wazuh: FIM and Active Response Compared

OSSEC vs Wazuh: File Integrity Monitoring and Active Response

OSSEC and Wazuh share roughly 80% of their codebase and 100% of their spelling of ossec.conf. The 20% divergence is where your architecture decision lives — and it is not a small 20%. It is the difference between a scanner that writes flat files and a platform that expects an OpenSearch cluster with a JVM heap you have to size.

Here is the thesis up front: OSSEC is a fragile, brilliant, near-frozen engine. Wazuh is the same engine with a database, an API, and a compliance story bolted on — and a resource bill to match. Both will page you at 03:00. Only one of them will still have a CVE-patched release next quarter.

This guide covers FIM and Active Response specifically, because those are the two modules people actually migrate for. Everything else — log decoders, rootcheck, SCA — is either identical or not worth the migration on its own.

:::note[TL;DR]

• Syscheck's engine is the same code in both projects. The divergence is in change attribution (whodata), storage, and the API.
• Real-time FIM on Linux is inotify-based in both. Wazuh adds auditd-backed whodata for attribution; OSSEC's implementation is older and thinner.
• Active Response is the single most dangerous module in either product. firewall-drop at [location]server[/location] will block your own agents.
• OSSEC's floor is a 1–2 GB VM. A useful Wazuh deployment is realistically 8–16 GB across manager plus indexer.
• Migrating is a config porting exercise for syscheck and a near-rewrite for anything that touched the OSSEC database output. :::

Prerequisites

• A working OSSEC 2.9.x/3.x or Wazuh 3.x/4.x manager, and at least one agent registered.
• Root (or equivalent sudo) on the manager and agents — syscheck reads /etc, and Active Response scripts run as root by design.
• auditd installed on Linux hosts if you want whodata attribution.
• For Wazuh 4.x: the indexer and dashboard up, since that is where FIM events land.
• A staging host you are willing to lock out of the network. Seriously.

Two Codebases, One Ancestor

Wazuh started as a fork of OSSEC and had its first standalone release in 2015. Since then, upstream OSSEC's cadence has been measured in years, not months; the 2.9.x line went effectively quiet and the 3.x line is carried by Atomicorp as a vendor-maintained branch. Wazuh ships on a much faster cycle and, critically, publishes CVEs and fixes for the whole stack.

The uncomfortable truth is that the fork is the product, not a bug. The original OSSEC codebase was never designed for a manager that stores every FIM event, an API with RBAC, or a multi-node cluster. Wazuh didn't just add features — it rearchitected the data plane, and that rearchitecture is exactly what costs you RAM.

First thing to do on any inherited box: find out which engine you are actually running, because "OSSEC" appears in paths regardless of which project you deployed.

# Wazuh still installs to /var/ossec — the path lies. Check the version.
/var/ossec/bin/wazuh-control info 2>/dev/null || /var/ossec/bin/ossec-control status

# Both projects write VERSION into ossec-init.conf on install
grep -E '^VERSION' /var/ossec/etc/ossec-init.conf

# Confirm which binaries exist — this is the fastest fork fingerprint
ls -1 /var/ossec/bin/ | grep -E 'wazuh|ossec' | head -20

---

⚠️ TRUNCATED VERSION
This is an abbreviated cross-post. Full article (all config files, architecture diagrams, images): valtersit.com

---

🛠️ Partner Tools for Developers

ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.

➜ valtersit.com/deals/