How to Use Wazuh: A Practitioner's Guide to Agents, the Dashboard, and Detection

To use Wazuh, you install the Wazuh server, put a lightweight agent on each system you want to watch, enroll that agent with the server, and log in to the Wazuh dashboard to read what it finds. Behind the dashboard, the server decodes every incoming log into structured fields and scores it against a set of rules. Your real job is tuning those rules so genuine threats stand out and routine noise falls away.

Here is the plainer version. Think of Wazuh as a smoke-and-motion alarm system for your servers and laptops. The agents are the sensors you place in each room. The server is the panel that decides which of the thousands of little signals actually mean something. The dashboard is the screen the person on duty watches. Installing the sensors is the easy afternoon. Deciding what should set off the alarm, and making sure someone answers it, is the part that separates a working setup from an expensive noise machine.

This guide walks the real workflow with the actual commands: what Wazuh is, the four parts you touch, how to stand up the server, how to enroll an agent, how to reach the dashboard, how a raw log becomes an alert, and how to write and test a rule before you trust it. It ends with the honest places Wazuh runs out of road. We run Wazuh as a managed service on top of OpenSearch, so the limits section is written from operating it, not from reading about it.

What is Wazuh, and what do you actually use it for?

Wazuh is a security platform you can run for free, and its source code is open. It combines two jobs that used to need separate products: acting as a SIEM (collecting and correlating logs from across your environment) and doing XDR-style work (extended detection and response, meaning it watches endpoints and can react on them). The Wazuh documentation frames it as one platform for both, running across on-premises, virtual, container, and cloud systems.

In practice people use Wazuh for a handful of concrete jobs. It analyzes log data from servers and applications. It runs file integrity monitoring, which flags when a watched file changes unexpectedly. It performs security configuration assessment, checking systems against hardening baselines. It does vulnerability detection by matching installed software against known-flaw feeds. It detects malware and suspicious behavior, supports incident response, and maps findings to common regulatory frameworks. If you have ever wanted one place that answers "what changed, who logged in, and is anything on this box out of policy," that is the shape of the tool.

The four parts of Wazuh you interact with

Wazuh has four moving parts. Learn these names once and the rest of the product makes sense. According to the Wazuh architecture documentation, there is a multi-platform agent plus three central components.

The data flows in one direction, and knowing which box talks to which on which port makes every connection problem faster to diagnose.

Step 1: install the Wazuh server (one command)

Standing up the server is the one part that lives in a terminal rather than a browser; it is a one-time setup task. For a lab or a single-node deployment, the official installation assistant does the heavy lifting, setting up the indexer, server, and dashboard together on one host. Size the box first: the all-in-one install needs at least 8 GB of RAM and 4 CPU cores and 50+ GB of disk, on a supported Linux with root access (the requirements page lists the distributions). Then run:

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

The 4.14 in that URL is the release version, which advances over time; the Wazuh quickstart always shows the current one. The -a flag means "all-in-one." When it finishes, it has generated a random admin password and stored the credentials in wazuh-install-files.tar, dropped in the directory you ran the installer from. Read them out from that same directory with:

sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

First, open the ports, or the next step fails silently: you reach the dashboard over TCP 443, and agents reach the server on TCP 1515 (enrollment) and 1514 (events). If a host firewall or cloud security group blocks them, the browser just times out and agents sit on Disconnected with no clear error. Open all three on the server:

# Ubuntu/Debian (ufw)
ufw allow 1514/tcp && ufw allow 1515/tcp && ufw allow 443/tcp
# RHEL/CentOS/Alma (firewalld)
firewall-cmd --permanent --add-port=1514-1515/tcp --add-port=443/tcp && firewall-cmd --reload

On a cloud VM, also allow inbound TCP 443 (dashboard) and 1514-1515 (agents) in the security group.

Now browse to https://<server-ip> and log in as admin with that password. Your browser will warn about the self-signed certificate; click through (Advanced, then Proceed). You land on an empty dashboard, which is correct: nothing reports yet because no agent is enrolled. That is Step 2.

Step 2: install and enroll your first agent

Nothing appears in Wazuh until an agent is reporting, so this is the step that actually lights up the dashboard. Installing the agent and enrolling it are usually a single action: when you install the package with the WAZUH_MANAGER variable set to your server's address, the agent writes that address into its own config and enrolls itself the first time it starts. Enrollment is where people trip: an agent installed but never pointed at a server, or registered with a duplicate name, shows up as disconnected and quietly monitors nothing.

The fastest path is the dashboard wizard. In the dashboard, open Agents management then Summary and click Deploy new agent. Pick the operating system, paste your server's address and a name, and it hands you the exact install command to run on the host, already filled in with the values below. For one or two machines, that is all you need.

Everything below is exactly what the wizard runs for you, shown in full so you understand each step (and can automate it later). In every command, replace 192.0.2.10 with your own server's address.

Linux (Debian or Ubuntu). Add the Wazuh package repository, then install the agent with your server's address baked in. Run these as root:

apt-get install -y gnupg apt-transport-https
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | tee /etc/apt/sources.list.d/wazuh.list
apt-get update
WAZUH_MANAGER="192.0.2.10" apt-get install -y wazuh-agent

On RHEL, CentOS, Alma, or Rocky it is the same idea with the YUM repository. Import the key, add the repo file, then install:

rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
cat > /etc/yum.repos.d/wazuh.repo << 'EOF'
[wazuh]
gpgcheck=1
gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
enabled=1
name=EL-$releasever - Wazuh
baseurl=https://packages.wazuh.com/4.x/yum/
priority=1
EOF
WAZUH_MANAGER="192.0.2.10" yum install -y wazuh-agent

Either way, enable and start the service so the agent enrolls and connects:

systemctl daemon-reload
systemctl enable --now wazuh-agent

Windows. To install by hand (the wizard above also generates this for you), download the current agent MSI from the Windows agent install guide, save it as wazuh-agent.msi, then from an elevated PowerShell install it and start the service:

msiexec.exe /i .\wazuh-agent.msi /q WAZUH_MANAGER="192.0.2.10" WAZUH_AGENT_NAME="win-01"
NET START WazuhSvc

macOS and other platforms. The same pattern (install the package with WAZUH_MANAGER set, then start the service) covers macOS and more; the dashboard wizard and the agent install guides give the exact per-OS command.

Within a minute, the host should appear under Agents management > Summary, which lists every enrolled agent with its OS, IP, and connection status:

Step 3: reach the dashboard and read events

You use Wazuh mostly through its dashboard. Once an agent is reporting, the interface groups everything into modules: security events (the main alert stream), integrity monitoring, configuration assessment, vulnerability detection, and a view that maps detections onto MITRE ATT&CK so an alert arrives with an attacker technique attached rather than as a bare log line.

As agents report, the Security Events module fills with alerts, each tagged with a rule ID, a level, and the technique it maps to, so you can read what happened without opening a raw log. Every row is one structured alert (you will see exactly what one contains in the worked example below).

If an agent stays disconnected or the dashboard stays empty, check it from the server: agent_control -l lists every agent and whether it is active.

sudo /var/ossec/bin/agent_control -l

Nine times out of ten an empty dashboard is a plumbing problem, not a dashboard one: an agent that never connected (the ports from Step 1, or a wrong server address, which /var/ossec/logs/ossec.log on the agent will confirm), rather than a real absence of events.

How Wazuh turns a log line into an alert: decoders and rules

This is the concept that makes everything else click, and it is the one most tutorials skip. A raw log line is just text. Wazuh processes it in two stages. First a decoder reads the line and pulls out structured fields: the source IP, the username, the program, the action. Then a rule looks at those fields and decides whether they matter, and how much.

Every rule carries a level from 0 to 15, so there are 16 severity tiers in total. Level 0 is special: it means "ignored," so no alert is raised, and it exists specifically to suppress known false positives. Low levels (roughly 3 to 7) cover authorized events and user errors. Middle levels (8 to 10) cover things like repeated failed logins that hint at an attack. High levels (11 to 15) are integrity violations and likely intrusions, with level 15 reserved for a severe attack that needs immediate action. The rule classification documentation lays out the full scale. The practical takeaway: you decide what deserves attention by adjusting which rules fire and at what level, and level 0 is your friend for silencing noise you have investigated and cleared.

Worked example: write a rule and test it with wazuh-logtest

The single best tool for learning how Wazuh thinks is wazuh-logtest. It lets you paste a sample log line and watch exactly which decoder matches and which rule fires, before you rely on it in production. Run /var/ossec/bin/wazuh-logtest on the server (the dashboard exposes the same ruleset test under its developer tools, but the CLI is the reliable path) and paste a log line at its prompt.

Start with a real one: an SSH login attempt against a user that does not exist. Here is the tool's three-phase output for that line, trimmed to the fields that matter:

$ sudo /var/ossec/bin/wazuh-logtest
Oct 12 08:07:00 web-01 sshd[39245]: Invalid user backup2 from 203.0.113.7 port 57238
--- Phase 1: pre-decoding ---
timestamp: 'Oct 12 08:07:00'
hostname:  'web-01'
program:   'sshd'
--- Phase 2: decoding ---
decoder: 'sshd'
srcip:   '203.0.113.7'
srcuser: 'backup2'
--- Phase 3: rule matching ---
id:    '5710'
level: '5'
description: 'sshd: Attempt to login using a non-existent user'

You can now see the whole chain from text to alert. Phase one pulls out the timestamp, host, and program. Phase two matches the built-in sshd decoder and extracts srcip and srcuser. Phase three reports that built-in rule 5710 fired at level 5. One such probe is background noise; you do not want a level-5 alert for every one. What you actually care about is a burst of them, which looks like user enumeration or a brute-force run.

So write a local rule that watches for the pattern rather than the single line. Custom rules live in local_rules.xml and use IDs of 100000 or higher so they never collide with the built-in set. That file ships with a placeholder group already; add this <rule> inside the existing <group> or append a new <group> block, either works. This one escalates to level 10 when rule 5710 matches eight times inside two minutes from the same source IP. That last part matters: the <same_source_ip /> tag scopes the count to one attacker, so eight unrelated failures from eight different hosts do not trip it, but a single machine hammering the box does:

<group name="local,syslog,sshd,">
  <rule id="100100" level="10" frequency="8" timeframe="120">
    <if_matched_sid>5710</if_matched_sid>
    <same_source_ip />
    <description>SSH: repeated non-existent-user logins from one source (possible user enumeration)</description>
  </rule>
</group>

Reload the ruleset so the server picks up the new rule (sudo systemctl restart wazuh-manager), then paste the same SSH line into wazuh-logtest eight times, keeping all eight in the same session and inside two minutes (exiting the tool, or pausing past the rule's 120-second timeframe, resets the counter): on the eighth, it now reports rule 100100 at level 10 instead of the quiet 5710. That firing becomes an alert, which is exactly what fills the Security Events view from Step 3. Trimmed to its key fields, one alert looks like this:

{
  "timestamp": "2026-07-02T08:07:04+0000",
  "agent":  { "name": "web-01", "ip": "10.0.0.11" },
  "rule":   { "id": "100100", "level": 10, "description": "SSH: repeated non-existent-user logins from one source" },
  "data":   { "srcip": "203.0.113.7", "srcuser": "backup2" }
}

That is the whole loop: decode, match, tune, re-test. If a detection you expected does not fire, wazuh-logtest tells you whether the decoder failed to parse the line or the rule simply did not match, which is exactly the question you need answered. (Sources: custom rules, testing decoders and rules.) Make this the first thing you reach for whenever a rule behaves in a way you did not expect.

Using Wazuh as a SIEM, an XDR, or an EDR

People ask whether Wazuh is a SIEM, an XDR, or an EDR, and the honest answer is that it leans on all three ideas, with different strengths. As a SIEM, it is genuinely capable: it collects logs from every enrolled host and correlates across them, which is the whole point of central detection. As XDR, the agent adds endpoint context: file integrity, configuration state, and active-response scripts that can run on the host when a rule fires. Where you should temper expectations is calling it a full EDR: it detects and can react with scripted responses, but it is not a kernel-level behavioral prevention product like a dedicated commercial EDR. Read it as strong detection and log correlation with real endpoint visibility, plus scripted response, rather than as automated prevention. That framing keeps you from being surprised later.

Wazuh vs Security Onion vs Splunk

The two comparisons people search for most are Wazuh against Security Onion and against Splunk. They sit in different places, and the right pick depends on what you are optimizing for.

The pattern to notice: with Wazuh, and with Security Onion, the software is free, so the cost moves to infrastructure and staffing rather than licenses. Splunk moves the cost the other way, charging for the platform in exchange for a wide integration surface. None of the three watches your alerts for you.

Where Wazuh breaks (the honest limits)

This is the section content mills never write. Wazuh is a strong tool, and it has predictable failure modes you should plan around.

• The default rules are generic. Out of the box you get a broad ruleset that produces a lot of low-value alerts for your specific environment. The value comes from writing local rules and tuning levels (exactly the loop above), which is ongoing work, not a one-time setup.
• The indexer grows fast. Because it stores events in OpenSearch, disk usage climbs with how much you log. Without a retention plan and enough storage, the indexer is the component that falls over first.
• Agent management at scale is real work. Enrollment, key management, version upgrades, and spotting agents that silently stopped reporting all take effort once you pass a few dozen hosts.
• It does not include analysts. Wazuh raises alerts; it does not decide which ones matter or respond to them. A wall of untriaged alerts trains a team to ignore the screen, which is worse than no alarm at all.
• It is not a prevention EDR. Active response runs scripts you configure; it is not the automated, kernel-level blocking of a dedicated endpoint prevention product.

None of this makes Wazuh a poor choice. It means the payoff comes from how well the deployment is run, which is exactly why so many teams choose to have it operated for them.

Where Suriq fits

Suriq runs Wazuh and OpenSearch as a managed service, which is why we chose to build on Wazuh in the first place. The parts of this guide that are genuinely hard (tuning the ruleset so alerts are worth reading, sizing and retaining the indexer, keeping agents healthy, and having people watch what fires) are the managed part. Detections ship mapped to MITRE ATT&CK, so an alert arrives with the technique attached. If you want the outcome that Wazuh delivers without standing up and operating the stack yourself, that is the model we are built around. And if you would rather run it in-house, everything above is the honest starting map.