Wazuh: SIEM Architecture, Agents & Detection Rules

Wazuh is an open-source security platform that unifies host-based intrusion detection (HIDS), log analysis, file integrity monitoring (FIM), vulnerability detection, and SIEM-style correlation and alerting into a single agent/manager architecture. It began as a fork of OSSEC and has since grown into a full stack: lightweight agents on every monitored host, a manager that decodes and correlates events against rules, an OpenSearch-based indexer for storage and search, and a dashboard for visualizing alerts.

This guide treats Wazuh the way a production security team actually runs it: not just “install the agent and look at a dashboard,” but understanding the decoder → rule → alert pipeline well enough to write your own detections, tune out noise, and trace a real attack (SSH brute forcing) end-to-end from raw log line to a dashboard alert.

Who this is for

• DevOps/SysAdmin engineers adding detection capability to a fleet of servers.
• Anyone who has run a SIEM concept in theory but never built the manager, indexer, and agent pipeline by hand.
• Security-conscious teams who want alerting that maps to MITRE ATT&CK, not just raw logs.

You should have the following before deploying the stack in this guide:

What a SIEM/HIDS actually does

At its core, a SIEM (Security Information and Event Management) platform does three things: collect logs and telemetry from many sources, normalize and correlate that data against known-bad patterns, and alert a human when something matches. A HIDS (Host-based Intrusion Detection System) narrows that scope to a single host: it watches log files, the filesystem, running processes, and configuration state for signs of compromise. Wazuh is both — agents provide the HIDS layer per host, and the manager/indexer/dashboard provide the SIEM layer across the whole fleet.

The decode → rule → alert pipeline

Every raw log line the manager receives goes through the same pipeline inside wazuh-analysisd:

1. Decoding — a decoder (defined in XML) recognizes the log format (e.g. sshd, sudo, iptables) and extracts structured fields like srcip, user, and action from the free-text line.
2. Rule matching— decoded fields are tested against a tree of rules. Rules can match on a single event (e.g. “failed password”) or on frequency/correlationacross multiple events (e.g. “8 failed passwords from the same IP within 120 seconds”).
3. Alerting — a matched rule has a level (0-16, severity) attached. If the level clears the configured threshold, an alert is written to alerts.json/alerts.log on the manager and shipped to the indexer for the dashboard to display.

Rule levels, at a glance

MITRE ATT&CK mapping

Wazuh's default ruleset tags many rules with MITRE ATT&CK technique IDs (e.g. T1110 for brute force, T1098for account manipulation). This lets an analyst pivot from “I got an alert” straight to “this maps to the Credential Access tactic” without manually cross-referencing the framework, and lets you build dashboard visualizations grouped by tactic instead of by raw rule ID.

A production Wazuh deployment has four moving parts. Agents run on every monitored endpoint and forward events over an encrypted channel to the manager. The manager decodes, correlates, and writes alerts, then hands them to Filebeat, which ships them to the indexer. The dashboard queries the indexer to render everything an analyst sees.

Component responsibilities

Wazuh ships an official quickstart script for small/all-in-one deployments, and a Docker Compose stack for distributed or disposable lab environments.

# Download and run the official install assistant
curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh
sudo bash wazuh-install.sh -a

# The script installs and configures, in order:
#   1. Wazuh indexer   (OpenSearch-based)
#   2. Wazuh manager   (+ Filebeat for shipping alerts)
#   3. Wazuh dashboard (OpenSearch Dashboards)
#
# On completion it prints the generated admin password — save it immediately:
sudo tar -xvf wazuh-install-files.tar

# Verify all three services are active
sudo systemctl status wazuh-manager wazuh-indexer wazuh-dashboard

Manager: ossec.conf essentials

The manager's behavior — which log sources to trust, active response, and global alert thresholds — lives in /var/ossec/etc/ossec.conf.

<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <alerts_log>yes</alerts_log>
    <logall>no</logall>
    <email_notification>no</email_notification>
  </global>

  <alerts>
    <log_alert_level>3</log_alert_level>
    <email_alert_level>12</email_alert_level>
  </alerts>

  <remote>
    <connection>secure</connection>
    <port>1514</port>
    <protocol>tcp</protocol>
  </remote>

  <!-- Vulnerability detection module -->
  <vulnerability-detector>
    <enabled>yes</enabled>
    <interval>5m</interval>
    <run_on_start>yes</run_on_start>
  </vulnerability-detector>

  <ruleset>
    <decoder_dir>ruleset/decoders</decoder_dir>
    <rule_dir>ruleset/rules</rule_dir>
    <rule_dir>etc/rules</rule_dir>
    <list>etc/lists/audit-keys</list>
  </ruleset>
</ossec_config>

Agent: ossec.conf essentials

Each agent's /var/ossec/etc/ossec.conf defines the manager address and which local log files and integrity paths to watch.

<ossec_config>
  <client>
    <server>
      <address>10.0.0.10</address>
      <port>1514</port>
      <protocol>tcp</protocol>
    </server>
    <enrollment>
      <enabled>yes</enabled>
      <manager_address>10.0.0.10</manager_address>
      <port>1515</port>
    </enrollment>
  </client>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
  </localfile>

  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/nginx/access.log</location>
  </localfile>

  <syscheck>
    <frequency>43200</frequency>
    <directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
    <ignore>/etc/mtab</ignore>
  </syscheck>

  <rootcheck>
    <disabled>no</disabled>
  </rootcheck>
</ossec_config>

Registering an agent

Agent registration issues a unique key that both sides use to authenticate the encrypted channel. This can be done manually on the manager or automatically via wazuh-authd enrollment (used by the agent's <enrollment> block above).

# Manual registration
sudo /var/ossec/bin/manage_agents -a
# -> prompts for agent name and IP, then issues an ID

# Extract the key for a given agent ID to import on the agent
sudo /var/ossec/bin/manage_agents -e 003

# List all registered agents and their connection status
sudo /var/ossec/bin/agent_control -l

wazuh-control — service lifecycle

sudo /var/ossec/bin/wazuh-control start
sudo /var/ossec/bin/wazuh-control stop
sudo /var/ossec/bin/wazuh-control restart
sudo /var/ossec/bin/wazuh-control status

# Or via systemd (preferred on both manager and agent)
sudo systemctl restart wazuh-manager
sudo systemctl restart wazuh-agent

manage_agents — key lifecycle on the manager

sudo /var/ossec/bin/manage_agents -a          # add a new agent
sudo /var/ossec/bin/manage_agents -l          # list agents
sudo /var/ossec/bin/manage_agents -e <id>     # export/print the agent key
sudo /var/ossec/bin/manage_agents -r <id>     # remove an agent

Agent enrollment from the agent side

# Enroll using authd against the manager (fetches a key automatically)
sudo /var/ossec/bin/agent-auth -m 10.0.0.10

# Import a key generated manually on the manager instead
sudo /var/ossec/bin/manage_agents -i <base64-key-string>

# Restart the agent to pick up the new key
sudo systemctl restart wazuh-agent

agent_control — status and force actions from the manager

sudo /var/ossec/bin/agent_control -l               # list agents + status
sudo /var/ossec/bin/agent_control -i <id>           # detailed info for one agent
sudo /var/ossec/bin/agent_control -R -u <id>        # force-restart an agent remotely

The default ruleset (rule IDs roughly 1-99999) covers common software out of the box. Custom, environment-specific detections belong in /var/ossec/etc/rules/local_rules.xml using an ID range above 100000 so they never collide with vendor rule updates.

Example: alert when a user is added to the sudoers group

<group name="local,sudoers_change,">
  <rule id="100010" level="10">
    <if_sid>5902</if_sid>
    <match>usermod.*-aG sudo|usermod.*-aG wheel</match>
    <description>User added to sudo/wheel group</description>
    <mitre>
      <id>T1098</id>
    </mitre>
    <group>privilege_escalation,gdpr_IV_32.2,</group>
  </rule>
</group>

Rule 100010 extends base rule 5902 (the generic usermoddecoder match), narrows it with a regex on the command line, sets severity to level 10 (high), and tags it with the MITRE ATT&CK privilege escalation technique so it surfaces correctly in dashboard MITRE visualizations.

Scenario: an internet-facing jump host is being brute-forced over SSH. Walk the full path from the raw auth log line to a dashboard alert.

• Keep every custom rule and decoder in local_rules.xml/local_decoder.xml — never edit the shipped ruleset, which is overwritten on upgrade.
• Use agent groups to centrally manage configuration for classes of hosts instead of hand-editing each agent's ossec.conf.
• Start new custom rules at a low level, confirm they fire correctly with real traffic, then raise the level once you trust the signal.
• Size the indexer for your alert volume up front — heap pressure and disk I/O on the indexer are the most common cause of dropped or delayed alerts at scale.
• Build MITRE ATT&CK-based dashboard visualizations, not just per-rule counts, so triage maps directly to attacker tactics.

• File Integrity Monitoring — enable syscheck with realtime on sensitive paths (/etc, binaries directories) so unauthorized changes generate an immediate alert.
• Tune, don't disable — a noisy rule usually needs a frequency/timeframe adjustment or a narrower match, not <rule ... level="0">; disabling it blind to your environment can mask a real detection.
• Manager-agent TLS — enrollment keys are unique per agent; rotate and revoke keys for decommissioned hosts immediately with manage_agents -r rather than leaving stale registrations active.
• Restrict dashboard/API access — put the dashboard behind a VPN or reverse proxy with its own auth layer, and scope manager API (55000/tcp) accounts to read-only where the caller doesn't need write access.
• Active response, cautiously — automated actions like firewall-drop are powerful but can self-inflict outages on a false positive; pilot new active response rules in alert-only mode before letting them execute.

Wazuh turns a fleet of otherwise-unrelated servers into a single detection surface: agents collect, the manager decodes and correlates against tunable rules, the OpenSearch-based indexer stores it all searchably, and the dashboard makes it visible. The real skill isn't installing the stack — it's understanding the decoder → rule → alert pipeline well enough to write narrow, MITRE-mapped custom rules in local_rules.xml, tune out noise instead of disabling coverage, and trace an alert like an SSH brute-force detection all the way back to the raw log line that triggered it.

• Official Wazuh documentation — documentation.wazuh.com
• Wazuh source code and rulesets on GitHub — github.com
• OpenSearch documentation (underlying the indexer/dashboard) — opensearch.org
• MITRE ATT&CK framework reference — attack.mitre.org
• Wazuh community forum — wazuh.com/community