Setting Up Wazuh SIEM for Server Log Monitoring and Intrusion Detection

A firewall stops unwanted traffic from getting in. It tells you nothing about what happens after something gets past it — a compromised WordPress plugin, a leaked SSH key, a cron job that shouldn't be there. That's the gap a SIEM (Security Information and Event Management) platform fills, and Wazuh is the most widely deployed open-source option for self-hosted server monitoring and intrusion detection.

This guide covers installing Wazuh on a dedicated Linux server, enrolling your first agent, and configuring it to actually catch something.

How Do I Know If My Server Was Hacked?

This is usually the question that brings people to Wazuh in the first place, so it's worth answering directly before the setup steps:

Without centralized log monitoring, you find out your server was compromised when something visibly breaks — a defaced site, a spam-sending mail queue, a resource-hogging cryptominer, or an abuse complaint from your hosting provider. By that point the attacker has usually had access for days or weeks.

With a SIEM in place, you get signal before that point: repeated failed SSH logins from one IP, a new user added to the sudoers file, a system binary modified outside a package update, or a process listening on a port nothing installed opened. Wazuh's job is to notice these things automatically and generate a scored alert instead of you noticing them by accident.

What Wazuh Actually Does

Wazuh combines several security functions into one open-source platform:

• Log data analysis — collects and analyzes logs (auth, syslog, application logs) across servers.
• File Integrity Monitoring (FIM) — flags unexpected changes to critical files and directories.
• Intrusion detection — rules engine that scores events (an SSH brute-force pattern, for example) and raises alerts.
• Vulnerability detection — cross-references installed software against known CVEs.
• MITRE ATT&CK mapping — ties alerts back to recognized attacker techniques instead of raw log noise.

This pairs naturally with network-layer defenses like an eBPF-based DDoS firewall: the network layer decides what traffic reaches your server at all, while Wazuh watches what happens on the host once traffic is already in. One without the other leaves a blind spot — a DDoS filter won't notice a compromised account logging in normally, and a SIEM won't stop a volumetric flood from ever reaching the box.

Architecture Overview

Wazuh is composed of four components:

• Wazuh agent — a lightweight process installed on each monitored server, sending logs and events to the manager.
• Wazuh server (manager) — receives events from agents, runs the decoders and rules engine, and generates alerts.
• Wazuh indexer — an OpenSearch-based engine that stores and indexes all alerts and event data for search and analysis.
• Wazuh dashboard — the web UI (OpenSearch Dashboards-based) for viewing alerts, managing agents, and building visualizations.

For a single server or small fleet, all three central components (server, indexer, dashboard) can run on one box. Larger deployments split them across separate nodes for scale.

Prerequisites

• A dedicated Linux server (Ubuntu 22.04/24.04 or Debian 11/12) to act as the Wazuh manager
• Minimum 4GB RAM (8GB recommended — the indexer alone is memory-hungry)
• At least 50GB disk space, more if you're retaining 90 days of alert history across many agents
• Root or sudo access
• Ports 443 (dashboard), 55000 (Wazuh API), 1514 and 1515 (agent communication) reachable from the servers you plan to monitor

Step 1: Install the Wazuh Central Components

Wazuh provides an all-in-one installation script that deploys the manager, indexer, and dashboard together on a single node — the fastest path to a working setup:

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

The -a flag runs the assisted all-in-one install. This takes several minutes and, on completion, prints the auto-generated admin credentials for the dashboard — save these immediately, they aren't shown again by default.

Step 2: Access the Dashboard

Open a browser to:

https://<your-server-ip>
                            

Log in with the credentials generated during installation. If the self-signed certificate warning bothers you (or you're running this on a public-facing box), replace it with a proper certificate — a Let's Encrypt certificate works fine here, same as any other HTTPS service.

Step 3: Confirm the Firewall Allows Agent and Dashboard Traffic

If you're already running a network-layer firewall (nftables, ufw, or an eBPF-based filter), open the required ports explicitly rather than disabling the firewall:

# nftables example
sudo nft add rule inet filter input tcp dport { 443, 55000, 1514, 1515 } accept
                            

Keep the dashboard and API restricted to trusted admin IPs where possible — these ports don't need to be open to the entire internet.

Step 4: Install and Enroll a Wazuh Agent

On each server you want monitored (which may include the manager itself), install the agent and point it at the manager's IP or hostname:

curl -sO https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.x_amd64.deb
sudo WAZUH_MANAGER='your-manager-ip' dpkg -i ./wazuh-agent_4.x_amd64.deb
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent
                            

Back in the dashboard under Agents, the newly enrolled server should appear as active within a minute or two.

Step 5: Enable File Integrity Monitoring

FIM watches specified directories for unexpected changes — a common early indicator of compromise. On the agent, edit /var/ossec/etc/ossec.conf and add the directories you care about most:

<syscheck>
  <directories check_all="yes" report_changes="yes">/etc,/bin,/sbin,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes">/var/www/html</directories>
</syscheck>
                            

Monitoring your web root (/var/www/html or equivalent) is particularly relevant for WordPress/WooCommerce servers — an unexpected file appearing there (a webshell dropped by a compromised plugin, for example) is exactly the kind of event FIM is built to catch.

Restart the agent to apply:

sudo systemctl restart wazuh-agent
                            

Step 6: Verify Detection Is Actually Working

Don't assume the install works — prove it. From another machine, deliberately trigger a few failed SSH logins against the monitored server:

ssh invaliduser@your-server-ip
                            

Repeat this a handful of times, then check the Wazuh dashboard under Security Events. A properly configured install should show an SSH brute-force-pattern alert within moments, tied to the source IP and scored by severity.

Step 7: Tune Alerts to Reduce Noise

An out-of-the-box Wazuh install will generate a meaningful volume of low-severity alerts. Left unfiltered, this trains admins to ignore the dashboard entirely — which defeats the purpose. A few practical adjustments:

• Raise the severity threshold for what triggers an email/Slack notification versus what just gets logged for later review.
• Whitelist known-noisy, expected events (a monitoring tool's routine health checks, for example) rather than letting them dilute real signal.
• Group related rules so a single incident doesn't generate a dozen separate notifications for what is really one event.

Common Issues

Where This Fits in a Layered Security Setup

Wazuh handles the host layer: what's happening on the server itself, in its logs, its files, and its running processes. It's not a substitute for network-layer protection — a properly configured firewall (nftables or an eBPF-based filter against volumetric attacks) still needs to be in place to control what traffic reaches the server before Wazuh ever sees it.

Together, the two cover both sides of the same question: what's trying to get in, and what's already happened once something did.