Wazuh Guide: Open Source SIEM and XDR Monitoring

Many organisations need log analysis, file integrity monitoring and configuration checks across their servers and endpoints but cannot justify a commercial SIEM and EDR stack for every host. Wazuh is a free and open source platform that combines these functions with an agent, a central analysis server, an indexer and a web dashboard. This guide explains the components and capabilities, how to size and deploy them safely, how to tune rules and decoders, where the compliance mappings help and where they do not, and how Wazuh compares with other options. It is for SOC engineers, detection engineers and infrastructure teams evaluating or running Wazuh, and it is based on the project's official documentation.

Key takeaways

Four components. Agents collect data, the Wazuh server decodes and matches it against rules, the indexer stores alerts and the dashboard presents them.
Broad capability in one agent. Log collection, file integrity monitoring (FIM), security configuration assessment (SCA), inventory, vulnerability detection and active response share a single agent.
Tuning decides the value. Over 3,000 default rules and decoders produce noise until you write local rules, adjust levels and test with wazuh-logtest.
Compliance mappings are indicative. Rules carry PCI DSS, HIPAA, NIST 800-53, TSC and GDPR tags, but the documentation states that running Wazuh does not by itself make you compliant.
Protect the platform itself. The server API, indexer users and agent enrolment are credentials with fleet-wide reach and must be managed as privileged non-human identities.

What the tool does

Wazuh describes itself as a free and open source security platform that unifies XDR and SIEM functions. Its licence file credits work originally copyrighted by Trend Micro (2003 to 2013), the OSSEC code base, and the released 4.x code is distributed under the GNU General Public License version 2 with an OpenSSL linking exception. The development branch on GitHub adds AGPL-3.0 terms for a new analysis engine and some shared libraries, so check the licence of the exact release you deploy. The Wazuh indexer is, according to its repository, an open source fork of OpenSearch, published under the Apache 2.0 licence. A managed service, Wazuh Cloud, is also offered.

Component	Role	Default ports
Wazuh agent	Runs on Linux, Windows, macOS, Solaris, AIX and HP-UX endpoints, servers and cloud instances; collects and forwards security data	Connects out to server 1514/TCP (events), 1515/TCP (enrolment)
Wazuh server	Decodes events, applies rules and threat intelligence, manages agents and remote configuration	1514, 1515, 1516/TCP (cluster), 55000/TCP (REST API), 514 syslog (disabled by default)
Wazuh indexer	Full-text search and analytics engine that indexes and stores alerts	9200/TCP (REST API), 9300-9400/TCP (cluster)
Wazuh dashboard	Web interface for alerts, threat hunting, compliance and vulnerability views, and platform configuration	443/TCP

Agent traffic to the server is AES encrypted by default. The server ships alerts to the indexer with Filebeat over TLS, and the dashboard talks to the server API over TLS with username and password authentication. Devices that cannot run an agent, such as firewalls and switches, can send logs by syslog or be monitored agentlessly over SSH.

Agent capabilities

Module	What it does	Typical defender use
Log collector	Reads log files and Windows event channels	Authentication failures, service changes, application errors
Command execution	Runs authorised commands on a schedule and sends output to the server	Checking state that no log records
File integrity monitoring (syscheck)	Tracks file creation, deletion and changes, with hashes and attributes; real-time mode on Linux and Windows directories; Windows registry monitoring	Changes to binaries, configuration files and SSH key files
Security configuration assessment	Checks configuration against YAML policies, mostly based on CIS Benchmarks	Hardening baselines and drift
System inventory	Collects installed software, running processes and open ports	Asset context and vulnerability correlation
Vulnerability detection	Correlates software inventory with the Wazuh Cyber Threat Intelligence (CTI) repository, or an offline copy	Finding vulnerable operating system and application versions
Malware detection	Looks for anomalies and rootkit signs without signatures	Supplementary checks on servers without EDR
Active response	Runs scripts when an alert matches a rule ID, level or group	Temporary IP blocks, account disablement
Container and cloud monitoring	Watches Docker activity and collects cloud provider service logs	Container drift, cloud audit events

Defender use cases

Central log analysis for servers: collect Linux authentication and audit logs and Windows event logs, decode them and alert on rule matches. See the Linux Logging and auditd for Defenders Guide and the Windows Internals for Defenders Guide.
File integrity monitoring: watch /etc, binary directories, web roots and each account's .ssh/authorized_keys. A new authorized key on a service account is a strong persistence signal (ATT&CK T1098.004 SSH Authorized Keys). FIM supports NIST SP 800-53 SI-7 and PCI DSS file integrity requirements; see the PCI DSS 4.0 Guide.
Hardening checks: SCA policies report failed checks against CIS Benchmark-based baselines and support CM-6 configuration settings. See the Linux Server Hardening Guide.
Vulnerability visibility: inventory based detection covers hosts your network scanner cannot reach, such as laptops off network. See the Vulnerability Management Guide.
Brute force and account misuse: default SSH and Windows logon rules detect repeated failures (T1110 Brute Force) and unusual successful logons (T1078 Valid Accounts), including by service accounts.
Small SOC platform: for teams without a commercial SIEM, Wazuh provides alerting, dashboards and search in one stack. See the Building a SOC from Scratch Guide.

Where identity fits

Wazuh holds powerful machine credentials. The server API on 55000/TCP can change agent configuration and, through active response, run scripts on endpoints; indexer users can read every alert; the enrolment service on 1515/TCP decides which hosts join. Store these passwords in a vault, give integrations their own least privilege API users, and rotate the passwords the installer generates. The installer writes them to wazuh-passwords.txt inside wazuh-install-files.tar, so move that archive off the host once you have stored the credentials. Use FIM and log rules to watch SSH keys and cloud credential files on monitored hosts. See the Secrets Management Guide and the SSH Key Management Guide.

Deployment and safe use

Model	Layout	Fits
All-in-one	Server, indexer and dashboard on one host	Labs and small environments (quickstart sizing: 1-25 agents 4 vCPU, 8 GiB RAM, 50 GB; 26-50 agents 8 vCPU, 8 GiB, 100 GB; 51-100 agents 8 vCPU, 8 GiB, 200 GB, for 90 days of alerts)
Single-node distributed	Each component on its own server	Medium environments
Multi-node	Clustered servers and indexers, one dashboard	Large estates, high availability and fault tolerance

The central components need 64-bit Linux on x86_64 or ARM64, with Amazon Linux, RHEL, CentOS Stream and Ubuntu among the supported versions. Size storage from your own event rate and retention, not only the quickstart table. See the Log Management and Retention Guide.

Build a lab first. Install all-in-one with the installation assistant, enrol a handful of representative agents and measure event rate per host type.
Replace default certificates and passwords. The quickstart uses certificates the browser will warn about; install certificates from your own CA and change generated credentials.
Restrict network exposure. Allow 1514 and 1515 only from agent networks, 55000 and 9200 only from the dashboard and administrators, and never expose the API or indexer to the internet.
Control enrolment. Use password or certificate based agent enrolment rather than open enrolment, and remove agents that stop reporting.
Pilot rings. Roll agents to a pilot group, tune rules, then expand by server role. Leave active response in alert-only mode until rules are proven.
Freeze upgrades. The documentation advises disabling the Wazuh package repository after installation to avoid accidental upgrades; upgrade deliberately, components in the documented order.
Rollback. Keep /var/ossec/etc (including local rules and decoders) in version control and snapshot indexer data before upgrades, so a bad rule or release can be reverted.

Rule and decoder tuning

Never edit the default ruleset: files under /var/ossec/ruleset/ are overwritten during upgrades. Put custom decoders in /var/ossec/etc/decoders/local_decoder.xml and rules in /var/ossec/etc/rules/local_rules.xml or new files in that directory.
Use the custom ID range: custom rules take IDs 100000 to 120000. To change a default rule, copy it into a local file, edit it and add overwrite="yes".
Chain rather than duplicate: build child rules with if_sid or if_group to raise or lower severity for your context.
Test before restart: run /var/ossec/bin/wazuh-logtest with a sample log line, then restart the manager (systemctl restart wazuh-manager) to apply.
Suppress with level 0: level 0 means ignored; use it for known benign events rather than deleting rules.

Level	Meaning (Wazuh classification)	Suggested handling
0	Ignored	Suppression of known false positives
3-5	Successful events, low priority errors, user errors	Index for search; no alert
8-10	First time seen, invalid source, multiple user errors	Review queue
11-12	Integrity checking warning, high importance event	Triage same day
13-15	Unusual error, high importance security event, severe attack	Page on-call; candidate for active response

Active response safely

Default scripts include firewall-drop, host-deny, route-null and disable-account on Unix-like systems, and netsh.exe and route-null.exe on Windows. Stateful responses revert after a period; stateless ones do not. The documentation warns that poorly designed rules and responses can increase an endpoint's vulnerability, so use stateful, time limited blocks, exclude your own management and scanner addresses, and never attach account disablement to a rule an attacker can trigger with spoofed log lines.

Detection and hardening value

Framework	Reference	Wazuh contribution
NIST CSF 2.0	DE.CM-09, DE.AE-02	Monitoring hosts for adverse events; analysing alerts in context
NIST CSF 2.0	ID.RA-01, RS.MI-01	Vulnerability identification; containment through active response
NIST SP 800-53 Rev. 5	SI-4, SI-7, AU-6	System monitoring, integrity checking, audit record review
NIST SP 800-53 Rev. 5	RA-5, CM-6, IR-4	Vulnerability monitoring, configuration settings, incident handling support
Built-in rule tags	PCI DSS, HIPAA, NIST 800-53, TSC, GDPR	Compliance identifiers in rule `<group>` tags drive the dashboard's compliance views; you can add your own identifiers

Treat the compliance dashboards as evidence that a technical control is operating, not as an audit result. See the Compliance Automation Guide.

Metrics that show it is working

Agent coverage: active agents as a percentage of in-scope hosts, and agents disconnected for more than 24 hours.
Alert quality: share of level 10 and above alerts closed as false positive, trending down after each tuning cycle.
SCA posture: pass rate per policy and server role, with failed checks older than 30 days.
Vulnerability exposure: critical findings per host and median age.
Pipeline health: indexer disk usage against retention target, and event ingest delay.

Common failure patterns

Running the quickstart in production: an all-in-one node with default certificates and stored passwords becomes a single, poorly protected point of failure.
Exposed API or indexer: 55000 or 9200 reachable from user networks or the internet gives a direct path to alert data and agent control.
Editing default rules in place: changes vanish on the next upgrade and detections silently revert.
Alert flood with no tuning owner: thousands of low value alerts train analysts to ignore the console.
Aggressive active response: automatic blocks triggered by spoofable events can lock out administrators or block critical partners.
Undersized indexer storage: disk exhaustion stops indexing and loses alerts exactly when an incident increases volume.

Alternatives

Option	Compared with Wazuh	When to prefer it
Commercial SIEM	Managed scale, more integrations and analytics, licence cost	Large data volumes and limited engineering time. See the SIEM Guide.
Commercial EDR / XDR	Kernel telemetry, behavioural prevention, isolation	Workstations and high value servers. See the EDR Guide.
Elastic Security	Search platform with its own agent and detection rules	Teams already standardised on Elastic. See the Elastic Security Guide.
Security Onion	Network security monitoring distribution that can include host data	Network visibility is the priority. See the Security Onion Guide.
osquery with a fleet manager	Flexible SQL state queries, no built-in alerting rules	Hunting and inventory. See the osquery Guide.
Velociraptor	Forensic collection and hunting	Incident response depth. See the Velociraptor Guide.

Small versus large organisations: a small team can run a single-node or all-in-one deployment for up to around 100 agents and lean on default rules plus a short local rule file. A large estate needs clustered servers and indexers, a rule engineering workflow in version control, and capacity planning owned by a named team.

Practitioner checklist

Choose the deployment model from measured event rates and retention, not agent count alone.
Replace default certificates and rotate every generated password into a vault.
Firewall 1514, 1515, 55000 and 9200 to the hosts that need them.
Use authenticated agent enrolment and remove stale agents monthly.
Keep custom rules and decoders in /var/ossec/etc under version control, using IDs 100000 to 120000.
Test every rule change with wazuh-logtest before restarting the manager.
Monitor authorized_keys and credential file paths with FIM on servers.
Start active response with stateful, time limited actions and allow lists.
Track agent coverage, false positive rate and indexer storage monthly.

Standards and references

Related NHI Mgmt Group resources: Endpoint Security Guide · SOC Guide · Detection Engineering Guide · SIEM Buyer's Guide

Wazuh Guide: Open Source SIEM and XDR for Endpoint and Cloud Monitoring