How to Use Wazuh: The Beginner's Guide (First Install, First Dashboard, First Agent, and the First Rule)

CodexFuse Team · 2026-10-31T06:30:20.433Z · 15 min read

Learn how to use Wazuh: install the free open-source SIEM with the all-in-one installer, log into the dashboard, enroll agents, and enable FIM and vulnerability detection.

How to Use Wazuh: The Beginner's Guide (First Install, First Dashboard, First Agent, and the First Rule)

Learning how to use Wazuh is the fastest way to stand up a real security information and event management (SIEM) system without paying enterprise SIEM prices. Wazuh is a free, open-source platform that combines SIEM and extended detection and response (XDR): it watches your endpoints for suspicious file changes, correlates logs from your servers and apps, flags vulnerable software packages, and can block an attacking IP the moment a rule fires. Using it means one beginner arc: run the all-in-one installer on a fresh server, log into the dashboard, enroll your first agent, switch on file integrity monitoring and vulnerability detection, write your first custom rule, and route the alerts somewhere you will actually see them. This Wazuh tutorial walks that entire arc in one sitting — and it starts with the resource reality check, because the all-in-one installer wants a whole machine to itself.

You will build in this order: size the server correctly, run the installation assistant, log into the Wazuh dashboard, enroll your first Linux and Windows agents, turn on file integrity monitoring, switch on vulnerability detection, write your first custom rule, and compare Wazuh vs Splunk so you know exactly what you are (and are not) getting for free. The server you put this on is the foundation of the whole project — what is VPS hosting explains how to pick a server you control, and a freshly provisioned VPS is where Wazuh belongs, never on a box already running your apps.

How do you use Wazuh? (The 60-second version)

Here is the complete beginner arc — from zero to a working SIEM watching a real endpoint, straight from Wazuh's own quickstart:

1. Provision a fresh server: 4 vCPU, 8 GB RAM, and 50 GB disk minimum — a clean Ubuntu 24.04 box with nothing else on it.
2. Run the installation assistant: download wazuh-install.sh from packages.wazuh.com and run it with the -a (all-in-one) flag; it deploys the server, indexer, and dashboard together.
3. Save the admin password: the installer prints an auto-generated admin password exactly once — copy it immediately.
4. Log into the dashboard: open https://YOUR_SERVER_IP, accept the self-signed certificate warning, and sign in as admin.
5. Enroll your first agent: install the lightweight agent on each machine you want to watch — Linux via APT with the WAZUH_MANAGER variable, Windows via the MSI installer — and confirm it shows "Active" in Agents management.
6. Switch on detection: enable file integrity monitoring on the agent and vulnerability detection on the manager, then write your first custom rule in local_rules.xml.

What is Wazuh, and how does it actually work?

Wazuh is a free, open-source security platform that provides unified SIEM and XDR protection for endpoints and cloud workloads, according to its own documentation. The project began in 2015 as a fork of OSSEC and grew into a full platform with roughly 17,511 GitHub stars as of October 30, 2026, and the 4.14.9 release arriving that same month. Its components are GPLv2 (server, agent) and Apache 2.0 (indexer, dashboard) licensed — genuinely free to download and run, with no per-agent or per-event license fee. You pay for the compute, the storage, and your own time tuning rules.

Wazuh is not one program. It is four cooperating components, and knowing which piece does what will save you hours of confused troubleshooting later. The Wazuh agent runs on every monitored endpoint — Linux, Windows, macOS (Intel and Apple Silicon), even AIX — collecting logs, watching files for integrity changes, gathering software inventory, and executing active-response actions when commanded. The Wazuh server (manager) is the central processor: it receives agent data, decodes it, applies rules, generates alerts, handles agent enrollment, and exposes a REST API on port 55000. The Wazuh indexer, built on OpenSearch, stores and indexes every alert and event so you can search and visualize it later — and it is the most resource-hungry component of the four. The Wazuh dashboard is the web interface where you investigate alerts, manage agents, and view MITRE ATT&CK and compliance views, served over HTTPS on port 443.

What does Wazuh need? The resource reality check

Undersizing the host is the single most common reason first installs fail partway through, usually with the indexer crashing silently or the dashboard hanging on a blank screen. Wazuh's own quickstart documentation gives the hardware floor for a single-node deployment that watches up to 100 endpoints and keeps 90 days of queryable alert data:

The rule of thumb for beginners: 4 cores, 8 GB of RAM, and 50 GB of disk on a FRESH host. "Fresh" is not optional — the all-in-one installer deploys the indexer, server, and dashboard on the same machine, and it assumes nothing else is competing for those resources. Supported server operating systems are 64-bit Linux: Ubuntu 16.04 through 24.04, RHEL 7 through 10, CentOS Stream 10, and Amazon Linux 2/2023. The 50 GB disk figure is an installation floor, not a retention budget — index data, vulnerability databases, and archived alerts eat storage fast once agents start reporting in, so give yourself headroom.

Memorize this port map before you start opening firewall rules: agents talk to the server on port 1514 (events) and 1515 (enrollment and authentication); the dashboard is on 443; the REST API on 55000; the indexer API on 9200. Never expose 9200 or 55000 to the open internet — both give direct access to raw security data and administrative functions. Agent traffic on 1514/1515 should reach only your own endpoints; if your agents sit across the internet, route them over a private tunnel rather than opening those ports to the world.

How do you install Wazuh with the all-in-one installer?

Start from a freshly provisioned Ubuntu 24.04 server with sudo access, update it, and make sure the clock is synchronized — the installer generates time-bound certificates, and clock drift between the server and its own certificates is a classic cause of TLS handshake failures. Then download and run the installation assistant:

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl tar
sudo timedatectl set-ntp true

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

The -a flag performs the all-in-one deployment: indexer, server, and dashboard on the same machine. The script takes several minutes because it generates self-signed certificates, initializes the indexer, and starts three separate services in sequence — do not interrupt it partway through; a killed install run is harder to clean up than a slow one is to wait out. When it finishes, it prints a summary with the dashboard URL and the admin credentials. Copy that password somewhere safe immediately: it is auto-generated, it is not stored in plaintext anywhere, and re-displaying it later requires a separate recovery step. The full password list for the indexer and API users lives in wazuh-passwords.txt inside the wazuh-install-files.tar archive the script creates in the directory you ran it from.

Verify all three core services report active before you touch the dashboard:

sudo systemctl status wazuh-indexer --no-pager
sudo systemctl status wazuh-manager --no-pager
sudo systemctl status wazuh-dashboard --no-pager

Nothing else in the stack works correctly until the indexer is healthy — the manager and dashboard both depend on it for storage and queries. You can also check indexer cluster health directly; on a single-node deployment you want "green" or at worst "yellow" (yellow is normal with one node because replica shards have nowhere to go — it is not a bug). Red means something is actually broken. One last official recommendation: disable the Wazuh package repository after installation so a routine system upgrade cannot accidentally pull a new Wazuh version that breaks the environment.

How do you log into the Wazuh dashboard for the first time?

Open a browser and navigate to https://YOUR_SERVER_IP. You will hit a certificate warning because the installer generates a self-signed certificate — accept it for lab use, or replace it with a certificate from your own CA before a team relies on this dashboard. Log in with the username admin and the auto-generated password from the install summary, and change that password immediately through the dashboard's user management.

On first login you land on the Wazuh overview dashboard, which looks mostly empty — no agents are reporting data yet. That is expected. The dashboard's main areas for a beginner: the Agents management page (where endpoints appear), Security events (alerts, once they exist), Integrity monitoring (file-integrity alerts), Vulnerability detection (package findings), MITRE ATT&CK (alerts mapped to attack techniques), and the Security configuration assessment (SCA) view. If the dashboard ever misbehaves after an update, remember it is served as its own systemd service (wazuh-dashboard), so a restart there fixes most blank-screen issues.

How do you install the Wazuh agent on Linux?

The manager alone sees nothing — it needs at least one agent on a machine to watch. On an Ubuntu or Debian machine you want to monitor, add the Wazuh repository and install the agent, passing the manager's address in the WAZUH_MANAGER environment variable so it gets baked into the agent's config automatically:

curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --dearmor -o /usr/share/keyrings/wazuh.gpg
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='YOUR_MANAGER_IP' apt install -y wazuh-agent
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

Replace YOUR_MANAGER_IP with the actual IP or hostname of your Wazuh server. Back in the dashboard, go to Agents management and confirm the new agent shows status "Active" within a minute or two. The agent registers itself with the manager over port 1515, then ships events over port 1514 — if the agent stays stuck on "Never connected," the firewall between it and the manager is the first suspect, not the installer.

How do you enroll a Windows agent?

Most real environments mix Linux and Windows, so it is worth doing this once even in a lab. On the target Windows machine, open PowerShell as Administrator and run the MSI installer silently, passing the manager address as an install parameter:

Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.8-1.msi -OutFile $env:tmp\wazuh-agent.msi
msiexec.exe /i $env:tmp\wazuh-agent.msi /q WAZUH_MANAGER='YOUR_MANAGER_IP'
NET START WazuhSvc

The MSI installer accepts the manager address the same way the Linux environment variable does. Verify the service is running with Get-Service WazuhSvc — it should report "Running" — then give it a minute and check the dashboard's Agents page the same way as the Linux agent. The 4.x MSI branch tracks the server release line, so use the MSI that matches your server's minor version where possible.

How does file integrity monitoring (FIM) work in Wazuh?

File integrity monitoring is one of Wazuh's core detection features: it watches specific directories for unauthorized additions, modifications, or deletions and alerts when they happen. This is how you catch a web shell dropped into a web root, a binary swapped on a system path, or a config file quietly edited at 3 a.m. On the agent, edit /var/ossec/etc/ossec.conf and confirm a syscheck block:

<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency>
  <directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes">/home,/var/www</directories>
</syscheck>

The realtime="yes" attribute on system binary directories triggers near-instant alerts on change, using inotify under the hood on Linux. Reserve realtime monitoring for high-value paths only — running it against large, frequently-changing directories like /home generates excessive CPU load and alert noise. Restart the agent to apply, then test it by creating a file in a monitored directory and checking the dashboard's Integrity Monitoring module a few minutes later; you should see the new file logged as an addition event. On capable older kernels, the 4.14.x line also allows FIM eBPF whodata on kernels older than 5.8, such as RHEL 8.10.

How do you turn on vulnerability detection in Wazuh?

Wazuh cross-references each agent's installed software inventory against vulnerability feeds to flag outdated or exploitable packages — essentially a continuously updated "which of my servers are running known-bad software" report. On the manager, edit /var/ossec/etc/ossec.conf and confirm the vulnerability-detection module is enabled:

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

Then restart the manager with sudo systemctl restart wazuh-manager. The manager downloads vulnerability feeds and compares them against the package inventories its agents report. The first scan takes a while — feeds must download and the inventory must arrive — so do not be alarmed if the Vulnerability detection module stays empty for the first half hour. A complementary angle worth knowing: a website malware scanner checks your public web pages from the outside, while Wazuh's vulnerability detection watches the servers and packages from the inside — endpoint and web are two different lanes, and serious setups cover both.

How do you write your first custom Wazuh rule?

The built-in rules cover common attacks, but every environment has its own tells — the custom local_rules.xml is where you encode yours. Rules live in /var/ossec/etc/rules/local_rules.xml on the manager, and custom rule IDs start at 100000 so they never collide with shipped rules. Here is a classic first rule: alert loudly on SSH brute-force attempts.

<group name="local,">
  <rule id="100100" level="10">
    <if_matched_sid>5716</if_matched_sid>
    <description>SSH brute force attempt.</description>
    <group>authentication_failures,</group>
  </rule>
</group>

Add the rule, then restart the manager (or reload the ruleset). The pattern: if_matched_sid hooks an existing rule's matches, level sets the severity, and description is what you will read at 2 a.m. — write it for a tired future you. This is the same shape as the SSH brute-force scenario every server admin knows: a dedicated host-level blocker like the Fail2ban beginner guide approach stops the attempts at the firewall, while Wazuh's rule watches, correlates, and escalates — prevention versus detection-and-response, and a hardened server runs both.

Wazuh can also act, not just alert. Active response lets the manager command an agent to run a script when a rule fires — the shipped firewall-drop.sh blocks the offending IP automatically. Enable active response on the agent, tie it to your custom rule, and a brute-force source gets dropped without you touching a terminal. Test this in the lab before production: automatic blocking plus a typo in your own allow rules is a fast route to locking yourself out.

Wazuh vs Splunk: what is actually different?

The question every evaluator asks is what the free stack gives up against the commercial giant. The honest answer, and the reason this comparison matters, is the economic model: Wazuh's core platform carries no per-agent or per-event license fee, while Splunk's bill scales with ingest volume — the more logs you send, the more you pay, forever.

Wazuh wins on cost and on having the endpoint agent, rules, FIM, and vulnerability detection in one download. Splunk wins on ecosystem depth, query language maturity, and vendor support. For a homelab, a startup, or a team standing up its first SOC, Wazuh is the rational default — and note the fine print the queue's writer caution flags: Wazuh Cloud is a separate paid product, so "free" always means the self-hosted install you just built.

Where does Wazuh fit in a security toolkit?

Wazuh watches your own machines and fires alerts — it is the detection-and-response lane. It does not replace the other lanes: recon, case management, and external scanning each have their own tools. If you are mapping your attack surface from the outside, the subdomain finder guide covers finding every subdomain an attacker can see. If an alert becomes an incident, a case-management layer sits on top of the SIEM — Wazuh raises the alarm, and the investigation lives elsewhere. Drawing these lane lines once keeps the architecture clean: Wazuh for detection, scanners for probing, case tools for investigations.

Beginner mistakes that break a first Wazuh install

Sources

Every fact in this guide was verified against these sources on 2026-10-31. The Wazuh docs are the authority for the install arc and hardware floor; the independent guides below confirm the real-world behavior the docs imply.

• Wazuh Docs — Quickstart (documentation.wazuh.com/current/quickstart.html): unified XDR/SIEM definition, four components (universal agent, server, indexer, dashboard), hardware table (4 vCPU, 8 GiB RAM, 50 GB for 1–25 agents, up to 100 endpoints, 90 days), OS list (Ubuntu 16.04–24.04, RHEL 7–10, Amazon Linux, CentOS Stream 10), install assistant command (packages.wazuh.com/4.14/wazuh-install.sh -a), admin + auto-generated password, self-signed cert warning, wazuh-install-files.tar / wazuh-passwords.txt, -u uninstall, repo-disable recommendation — crawled 2026-10-31.
• Tech Insider — "How to Set Up Wazuh SIEM: 13 Steps, Free XDR [2026]" (tech-insider.org/wazuh-siem-setup-2026-2/, September 28, 2026): 4.14.9 as current (October 2026), 4.14.8 (Sep 23, 2026), 4.14.2 (Jan 14, 2026), 4.14.0 (Oct 23, 2025), 4.13.x (Sep 2025), 4.12.0 (May 7, 2025), 5.0.0-rc1 preview; single-node minimums (4 cores, 8 GB RAM, 50 GB), small production (8 cores, 16–32 GB, 200 GB+); port map (1514 agent events, 1515 enrollment, 1516 cluster, 514 syslog, 55000 REST API, 9200 indexer, 9300–9400 cluster, 443 dashboard); never expose 9200/55000; timedatectl NTP before install; three-service systemd check (wazuh-indexer, wazuh-manager, wazuh-dashboard); indexer cluster health green/yellow normal, red broken; Linux agent install (GPG key, 4.x APT repo, WAZUH_MANAGER env var, daemon-reload/enable/start); Windows MSI (wazuh-agent-4.14.8-1.msi, /q WAZUH_MANAGER silent param, NET START WazuhSvc); FIM syscheck block (frequency 43200, check_all, realtime on /etc,/usr/bin,/usr/sbin, not on /home,/var/www); vulnerability-detection module (enabled, index-status, 60m feed interval); agent OS coverage (Windows MSI, Linux, macOS Intel + Apple Silicon, AIX 6.1+) — crawled 2026-10-31.
• Pasquale Pillitteri — "Wazuh Docker Install Guide and SSH Brute Force Blocking" (pasqualepillitteri.it, 1 day old): 4.14.9 released October 15, 2026; 17,511 GitHub stars (October 30, 2026); Docker floor (4 cores, 8 GB RAM, 50 GB); four parts (agents, manager, indexer, dashboard); vm.max_map_count=262144 indexer requirement — crawled 2026-10-31.
• Undercode Testing — "Mastering Wazuh SIEM: A Hands-On Guide" (undercodetesting.com): custom rule shape in /var/ossec/etc/rules/local_rules.xml (rule id 100100 example), active-response firewall-drop.sh for SSH brute-force blocking, VirusTotal/Suricata integration points — crawled 2026-10-31.
• Object First — "Wazuh SIEM Tutorial: Features, Architecture, and Hands-On Setup" (objectfirst.com/blog/siem-series-wazuh/, ~102 days old): fork of OSSEC (2015), modular architecture (agent/server/indexer/dashboard), decoders-then-rules pipeline, single-node install command (wazuh-install.sh -a), dashboard login arc — crawled 2026-10-31.
• RamNode — "Deploy Wazuh on RamNode VPS" (ramnode.com/guides/wazuh): 8 GB RAM minimum (16 GB recommended), 4 CPU cores, ports 443/1514/1515, Java for indexer, Filebeat log forwarding, SSL certificate generation, save admin credentials — crawled 2026-10-31.

Frequently asked questions

Is Wazuh really free?

Yes — the self-hosted platform is free and open source (GPLv2 for the server and agent, Apache 2.0 for the indexer and dashboard), with no per-agent or per-event license fee. You pay for the server it runs on and your own tuning time. Note the fine print: Wazuh Cloud is a separate paid product, so "free" means the self-hosted install this guide builds.

How much RAM does Wazuh need?

Wazuh's own quickstart specifies 8 GiB of RAM for a single-node deployment watching 1–25 endpoints, with 4 vCPU and 50 GB of disk. That floor holds all the way to 100 endpoints (8 vCPU at that point). The indexer is the hungriest component — undersizing RAM is the most common cause of first-install failures.

Can Wazuh replace Splunk?

For homelabs, startups, and first-SOC builds, yes — Wazuh gives you a SIEM, XDR, FIM, and vulnerability detection in one free download where Splunk charges by ingest volume. Splunk wins on ecosystem depth and its SPL query language, but Wazuh's cost model (server cost + your time) is the rational default until you outgrow it.

What is the difference between the Wazuh server, indexer, and dashboard?

The server (manager) processes agent data, applies rules, and generates alerts; the indexer (OpenSearch-based) stores and indexes every alert and event; the dashboard is the web interface on port 443 where you investigate. The single universal agent runs on each monitored endpoint and feeds the server.

How do I add a Windows machine to Wazuh?

Download the Wazuh agent MSI for your version, install it silently with msiexec /i wazuh-agent.msi /q WAZUH_MANAGER='YOUR_MANAGER_IP' from an Administrator PowerShell, start the WazuhSvc service, and confirm the agent shows "Active" in the dashboard's Agents management page.