Wazuh SIEM on AlmaLinux 9: Complete Setup Guide for Open-Source Security Monitoring in 2026

Running a production Linux fleet in 2026 without centralized security monitoring is a liability. Ransomware operators, supply-chain attackers, and misconfigured cloud workloads all leave traces in logs — but only if something is collecting, parsing, and alerting on them. Wazuh has become the de-facto open-source SIEM and XDR platform for small to mid-sized organizations because it ships with hundreds of decoders, file integrity monitoring, vulnerability detection, and MITRE ATT&CK mapping out of the box. This guide walks you through a complete Wazuh 4.9 deployment on AlmaLinux 9, from single-node server install to enrolling Ubuntu and RHEL agents, tuning rules, and shipping alerts to Slack.

## Why Wazuh in 2026

Commercial SIEMs like Splunk and QRadar are priced per GB ingested, which quickly becomes untenable once you pass a few hundred gigabytes per day. Wazuh is free, self-hosted, and integrates with OpenSearch for analytics. The 4.9 release introduces improved vulnerability detection powered by the Canonical, Red Hat, and NVD feeds, faster indexer start-up, and better Kubernetes support. For organizations chasing SOC 2, ISO 27001, or PCI DSS compliance, Wazuh provides ready-made rule sets that map directly to control requirements.

## Prerequisites

You need an AlmaLinux 9 (or Rocky Linux 9) host with at least 4 vCPU, 8 GB RAM, and 50 GB of disk. For anything beyond a lab, bump that to 8 vCPU and 16 GB. Make sure the system is fully updated and SELinux is enforcing.

“`bash
sudo dnf update -y
sudo dnf install -y curl tar firewalld
sudo systemctl enable –now firewalld
“`

Open the ports the Wazuh stack needs:

“`bash
sudo firewall-cmd –permanent –add-port=1514/tcp
sudo firewall-cmd –permanent –add-port=1515/tcp
sudo firewall-cmd –permanent –add-port=55000/tcp
sudo firewall-cmd –permanent –add-port=443/tcp
sudo firewall-cmd –permanent –add-port=9200/tcp
sudo firewall-cmd –reload
“`

## Installing Wazuh with the Assistant Script

Wazuh ships an all-in-one installer that deploys the indexer, manager, and dashboard on a single host. It is the fastest path to a working stack.

“`bash
curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh
sudo bash ./wazuh-install.sh -a
“`

The script generates self-signed certificates, writes passwords to `/wazuh-install-files.tar`, and starts all three services. After ten to fifteen minutes you will see a line like `INFO: You can access the web interface https://`. Retrieve the admin password:

“`bash
sudo tar -axf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt -O | grep -A1 admin
“`

Log in at `https://your-host` with user `admin` and the printed password.

## Enrolling Linux Agents

On each endpoint, install the Wazuh agent from the official repository. For Ubuntu 24.04:

“`bash
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg –no-default-keyring –keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg –import
echo “deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main” | sudo tee /etc/apt/sources.list.d/wazuh.list
sudo apt update
sudo WAZUH_MANAGER=”wazuh.example.com” apt install -y wazuh-agent
sudo systemctl enable –now wazuh-agent
“`

For AlmaLinux, Rocky, or RHEL 9:

“`bash
sudo rpm –import https://packages.wazuh.com/key/GPG-KEY-WAZUH
sudo tee /etc/yum.repos.d/wazuh.repo <
3
10

“`

Then add local rule overrides in `/var/ossec/etc/rules/local_rules.xml` to silence rules you cannot fix at the source:

“`xml


5716
192.168.10.0/24
Ignore SSH failed attempts from internal jumphost


“`

Restart the manager with `sudo systemctl restart wazuh-manager`.

## Enabling Vulnerability Detection

Wazuh 4.9 uses an indexer-based vulnerability detection pipeline. Enable it in `ossec.conf`:

“`xml

yes
yes
60m

“`

After the first feed sync, the Vulnerabilities dashboard lists every CVE affecting your fleet, cross-referenced with installed packages. This alone is often enough to justify the deployment.

## Shipping Alerts to Slack

Integrations live in the `` block. Create an incoming webhook in Slack, then add:

“`xml

slack
https://hooks.slack.com/services/XXX/YYY/ZZZ
10
json

“`

Any alert at level 10 or above now lands in your security channel with MITRE tags and rule descriptions.

## File Integrity Monitoring for PCI DSS

PCI DSS 4.0 requirement 11.5 mandates file integrity monitoring for critical system files. Wazuh’s syscheck module does this natively. In `ossec.conf` on the agent:

“`xml

43200
/etc,/usr/bin,/usr/sbin,/bin,/sbin
/var/www

“`

Changes trigger rule 550 through 554 alerts which are already mapped to PCI controls in the dashboard.

## Backing Up Wazuh Itself

Your SIEM is worthless if you lose its configuration and indices. Use OpenSearch snapshots to an S3-compatible bucket:

“`bash
sudo /usr/share/wazuh-indexer/bin/opensearch-plugin install repository-s3
sudo systemctl restart wazuh-indexer
“`

Then register the repository with a PUT to the indexer API and schedule nightly snapshots via cron.

## FAQ

**How much disk does Wazuh use?** Plan for roughly 500 MB per agent per month at default verbosity. Enabling vulnerability detection adds another 2 GB for the feed.

**Can I run Wazuh in HA?** Yes. Deploy a three-node indexer cluster and two manager nodes behind a load balancer. The installer supports distributed deployments with a config YAML.

**Does Wazuh replace EDR?** For most SMBs it comes close. It performs file integrity monitoring, rootkit detection, and command execution auditing via auditd integration, but does not offer kernel-level process introspection the way Falco or a commercial EDR does.

**Is Wazuh compliant with SOC 2?** Wazuh itself is not certified, but it helps you meet the CC7 monitoring controls and generates the evidence your auditor will ask for.

**Can agents run on Windows and macOS?** Yes, agents exist for Windows Server 2016 and newer, macOS, Solaris, AIX, and HP-UX. The Linux experience is the most polished.

**How does Wazuh compare to Elastic Security and Splunk?** Wazuh and Elastic Security share common ancestry — Wazuh originally forked from OSSEC and used Elasticsearch as its store. Today Wazuh maintains its own OpenSearch fork and ships pre-built rules for hundreds of integrations. Elastic Security has a slicker UI and machine learning add-ons but those features sit behind a paid license. Splunk is the commercial enterprise leader with the largest ecosystem of apps but its per-GB pricing makes it impractical for organizations ingesting more than a few hundred gigabytes per day. Wazuh fits squarely in the middle: free, capable enough for SOC 2 evidence and threat hunting, but lighter than commercial offerings.

**What is the minimum kernel version for the agent?** Anything 3.10 or newer, which covers every supported enterprise distribution. The eBPF-based features require 5.8+.

## Performance Tuning the Manager

Out of the box, the Wazuh manager handles roughly 1,000 agents on the recommended 8 vCPU/16 GB host. Past that, the analysisd process becomes the bottleneck. Increase analysis threads in `/var/ossec/etc/local_internal_options.conf`:

“`
analysisd.event_threads=8
analysisd.syscheck_threads=4
analysisd.rootcheck_threads=4
analysisd.sca_threads=4
remoted.worker_pool=8
“`

Restart the manager and watch CPU. If a single analysisd thread saturates a core, you have hit the upper limit and it is time to deploy a worker manager behind a load balancer. Wazuh’s cluster mode is straightforward: designate one master and N workers, all sharing the same `cluster.key`, and put the agent listener (port 1514) behind a TCP load balancer. Workers pull rules and decoders from the master automatically, so you only edit configuration in one place.

For the indexer side, set the JVM heap to half of available RAM (capped at 31 GB) by editing `/etc/wazuh-indexer/jvm.options`. Use SSDs — preferably NVMe — for the indexer data directory. Spinning disks will collapse under any meaningful event rate.

## Common Troubleshooting Scenarios

**Agent stuck in “Pending”**: nine times out of ten, this is a firewall issue — port 1514 is unreachable from the agent to the manager. Verify with `nc -vz 1514` from the agent host. The other common cause is a clock skew of more than five minutes between agent and manager, which breaks the encryption handshake.

**OpenSearch indexer fails to start**: check `/var/log/wazuh-indexer/wazuh-cluster.log`. The most common cause is insufficient virtual memory; set `vm.max_map_count=262144` in `/etc/sysctl.conf` and reload.

**Dashboard shows no data despite alerts in `/var/ossec/logs/alerts/alerts.json`**: the filebeat module that ships alerts from the manager to the indexer is not running. Run `sudo systemctl status filebeat` and check `/var/log/filebeat/filebeat`. A self-signed certificate mismatch is the typical culprit and is fixed by re-running the certificate generation step from `wazuh-install-files.tar`.

**Vulnerability detection feed never updates**: outbound HTTPS to `feed.wazuh.com` is blocked by an egress proxy. Configure the proxy in `wazuh-modulesd` settings or open the egress.

**High CPU on the manager**: usually a runaway custom rule with a regex that backtracks. Profile with `wazuh-logtest` against representative log lines and rewrite expensive regexes.

## Active Response

Wazuh can not only alert but react. Active response runs a script on the agent or manager when a rule fires. The default `firewall-drop` script blocks an offending IP via iptables or firewalld for ten minutes. Enable it for SSH brute force in `ossec.conf`:

“`xml

firewall-drop
local
5712
600

“`

Use this carefully on production — a misfiring rule can lock out legitimate traffic. Test in a staging cluster first and consider whitelisting your management network with a higher-priority rule that excludes those source IPs from the trigger.

## CIS Benchmark Scanning

The Security Configuration Assessment (SCA) module ships built-in CIS Benchmark policies for AlmaLinux, Ubuntu, Debian, Windows, and Docker. They run nightly and surface failing checks in the dashboard with remediation guidance. SCA is one of the highest-leverage Wazuh features for SOC 2 and ISO 27001 evidence because it automates what was previously a manual quarterly checklist exercise. Override the default policy in `/var/ossec/etc/shared/default/sca.conf` to silence checks that do not apply to your environment, and document the deviations in your compliance binder.

## MITRE ATT&CK Mapping in Practice

Every Wazuh rule with a meaningful security signal carries one or more `` tags. The dashboard’s MITRE ATT&CK view aggregates them into a heatmap of techniques observed across the fleet over the last 24 hours. This is invaluable for purple-team exercises: run an Atomic Red Team test, then check the heatmap to see which techniques Wazuh actually detected. Coverage gaps become a concrete backlog rather than a vague worry.

## Hardening Wazuh Itself

Restrict access to the API and dashboard with TLS client certificates or an OIDC integration to your identity provider. Rotate the default `admin` password immediately after install. Limit the OpenSearch network listener to the management subnet, never the public internet. The Wazuh manager runs as the `wazuh` user — keep it that way and avoid running it as root even though some installation guides take shortcuts. Audit the `/var/ossec/etc/client.keys` file regularly; an unexpected entry there means an unauthorized agent has been enrolled.