Wazuh SIEM Deployment: Complete Error Resolution Guide | cyberrscourse

Description: "Fix version conflicts, disk space exhaustion, certificate errors & migration bugs in Wazuh SIEM. Technical solutions from cyberrscourse security labs."

Wazuh SIEM Deployment: Solutions to 5 Critical Installation Errors

A cyberrscourse technical reference | By @cyberrscourse

What This Guide Covers

This cyberrscourse technical guide provides tested solutions for the most common Wazuh SIEM deployment failures. Each section includes:

✅ Problem description (what error you see)

✅ Root cause analysis (why it happens)

✅ Step-by-step solution (how to fix it)

✅ Prevention strategy (how to avoid it)

Use case: Deploy Wazuh SIEM in VMware/VirtualBox lab environments

Target versions: Wazuh 4.7.5 (stable) or 4.14.7 (latest)

Prerequisites:

• Basic terminal/command-line skills
• Understanding of virtual machines
• Ability to read error messages

Time to deploy: 2-4 hours (with this troubleshooting guide)

Why Deploy Wazuh SIEM? (Quick Context)

What it does: Monitors all computers in your network for security threats, compliance violations, and suspicious behavior.

Why security professionals use it:

• Free alternative to $50,000/year commercial SIEM tools (Splunk, QRadar)
• Built-in MITRE ATT&CK framework mapping
• Compliance monitoring (PCI DSS, GDPR, HIPAA)
• Real-time threat detection with 3,000+ rules

What you'll learn from this cyberrscourse guide: How to deploy security monitoring infrastructure and troubleshoot complex distributed systems.

Career value: SOC Analyst, Security Engineer, and Incident Response roles require SIEM experience.

System Architecture (Understanding Before Deploying)

Component Overview

Wazuh operates as a distributed system with four independent components. Understanding this architecture prevents 90% of configuration mistakes.

Simple explanation: Think of it like a home security system with cameras (Agents), a recording DVR (Indexer), an AI analyzer (Manager), and a monitor (Dashboard).

Technical architecture:

[Monitored Computer]
       ↓
Wazuh Agent (Sensor)
  • Collects: logs, file changes, process activity
  • Resource usage: ~35MB RAM
  • Platforms: Windows, Linux, macOS
       ↓ TCP/1514
Wazuh Manager (Analysis Engine)
  • Processes: 3,000+ detection rules
  • Technology: OSSEC-based
  • Resource needs: 2GB RAM, 10GB disk
       ↓ HTTPS/9200
Wazuh Indexer (Storage)
  • Technology: OpenSearch (Elasticsearch fork)
  • Stores: Security events, metadata
  • Resource needs: 4GB RAM, 50GB+ disk
       ↓ HTTPS/443
Wazuh Dashboard (UI)
  • Technology: Kibana fork
  • Provides: Visualization, alerts, reports
  • Resource needs: 2GB RAM

Component Dependencies (Critical for Troubleshooting)

Key insight from cyberrscourse labs:

• The core monitoring (Agent → Manager → Indexer) can work WITHOUT the Dashboard
• If the Dashboard fails, you can still access security events via CLI
• Each component failure requires different troubleshooting approaches

Minimum Resource Requirements

Based on cyberrscourse testing:

For lab environments (1-5 agents):

• CPU: 4 cores
• RAM: 8GB (4GB Indexer + 2GB Manager + 2GB Dashboard)
• Disk: 80GB minimum (100GB recommended)
• Network: 100Mbps minimum

For production (50+ agents):

• CPU: 8+ cores
• RAM: 16GB+
• Disk: 200GB+ with log rotation configured
• Network: 1Gbps recommended

Problem #1: Nested Virtualization Failure (WSL2 in VMware)

Error Message

WSL2 is unable to start since virtualization is not enabled on this machine.
Error code: Wsl/InstallDistro/Service/RegisterDistro/CreateVm/HCS_E_HYPERV_NOT_INSTALLED

When This Happens

You're trying to run WSL2 (Windows Subsystem for Linux) inside a VMware/VirtualBox virtual machine to install the Wazuh Manager.

Why It Fails (Root Cause)

Simple explanation: You're trying to run a virtual machine inside a virtual machine, but the outer VM doesn't allow it.

Technical explanation:

• WSL2 requires hardware virtualization extensions (Intel VT-x or AMD-V)
• VMware VMs don't expose these extensions to guest VMs by default (security/stability)
• WSL2 also requires systemd support (not available in WSL1)

Solution Options

Option 1: Enable Nested Virtualization (VMware)

# Shutdown the VM first
# Then in VMware: VM Settings → Processors → Enable:
# ☑ Virtualize Intel VT-x/EPT or AMD-V/RVI

Requirements:

• Physical CPU must support VT-x/AMD-V
• VMware Workstation Pro 14+ or Fusion 10+
• Performance penalty (15-30% overhead)

Option 2: Use Separate VMs (Recommended by cyberrscourse)

Instead of WSL2 inside Windows VM:

Setup 1: Ubuntu 22.04 VM (Wazuh Manager + Indexer + Dashboard)
Setup 2: Windows 11 VM (Wazuh Agent for monitoring)

Advantages:

• No nested virtualization needed
• Better performance
• Easier troubleshooting (isolated components)
• Matches real-world deployment patterns

Option 3: Use Physical Linux Machine

Install Ubuntu directly on hardware or use existing Linux server.

Recommended Approach (cyberrscourse Labs)

Use a dedicated Ubuntu 22.04 VM for Wazuh infrastructure:

1. Download Ubuntu 22.04 Server ISO
2. Create VM with:
   • 4 CPU cores
   • 8GB RAM
   • 80GB disk
3. Install Wazuh Manager, Indexer, Dashboard here
4. Install Agents on separate Windows/Linux VMs for monitoring

Why this approach wins:

• Avoids virtualization complexity
• Mirrors production deployments
• Simplifies troubleshooting
• Better resource management

Prevention Strategy

❌ Avoid: Running VMs inside VMs (nested virtualization) unless specifically required

✅ Do: Use separate VMs for infrastructure (Manager/Indexer) and monitored systems (Agents)

Problem #2: Version Mismatch - Agent Won't Connect to Manager

Error Message

WARNING: Couldn't connect to server '192.168.84.130': 
'Agent version must be lower or equal to manager version'

When This Happens

• Agent appears "Connected" in its own interface
• Manager doesn't show the Agent in connected list
• No security events appear in Dashboard

Diagnosis Steps

Step 1: Check Agent version

# Windows
Get-Content "C:\Program Files (x86)\ossec-agent\VERSION.json"

# Linux
cat /var/ossec/etc/VERSION

Step 2: Check Manager version

/var/ossec/bin/wazuh-control info | grep VERSION

Step 3: Compare versions

Root cause: Agent is NEWER than Manager (Wazuh enforces backward compatibility only)

Solution: Upgrade Manager to Match Agent

Add Wazuh repository (if not already added):

curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | \
  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 -a /etc/apt/sources.list.d/wazuh.list

sudo chmod 644 /usr/share/keyrings/wazuh.gpg

Upgrade Manager and Indexer:

sudo apt update
sudo apt upgrade wazuh-manager wazuh-indexer -y

Verify upgrade:

/var/ossec/bin/wazuh-control info | grep VERSION
# Should show: v4.14.7

Restart services:

sudo systemctl restart wazuh-manager
sudo systemctl restart wazuh-indexer

Known Issue: Dashboard Migration Bug (4.7.5 → 4.14.7)

Problem: Upgrading Dashboard to 4.14.7 causes infinite migration loop

Error in logs:

sudo journalctl -u wazuh-dashboard -n 100

{"message":"Detected mapping change in \"properties.query\""}

(Repeats infinitely)

Workaround from cyberrscourse labs:

# Remove broken 4.14.7 Dashboard
sudo apt remove --purge wazuh-dashboard -y

# Install stable 4.7.5 Dashboard instead
sudo apt install wazuh-dashboard=4.7.5-1 -y

# Prevent auto-upgrade
sudo apt-mark hold wazuh-dashboard

Result: Dashboard 4.7.5 works perfectly with Manager/Indexer 4.14.7

Prevention Strategy

Before installing Agents:

1. Check current Manager version: /var/ossec/bin/wazuh-control info | grep VERSION
2. Download matching Agent version from Wazuh packages archive
3. Or upgrade Manager first before deploying Agents

Version compatibility rule (from cyberrscourse testing):

Agent version ≤ Manager version  ✅ Supported
Agent version > Manager version  ❌ Fails

Advanced: Mixed Version Deployment

Working configuration from cyberrscourse labs:

Wazuh Manager:    4.14.7 ✅
Wazuh Indexer:    4.14.7 ✅
Wazuh Dashboard:  4.7.5  ✅ (stable, no migration bug)
Wazuh Agent:      4.14.7 ✅

Key insight: Dashboard version can be older than Manager/Indexer without issues.

Problem #3: Disk Space Exhaustion - "No Space Left on Device"

Error Messages

Indexer failure:

Caused by: java.io.IOException: No space left on device
    at java.base/java.io.FileOutputStream.writeBytes(Native Method)

Dashboard timeout:

{
  "tags":["error","opensearch","data"],
  "message":"[TimeoutError]: Request timed out"
}

Services crash or refuse to start

When This Happens

• VM initially allocated with 20-30GB disk
• After 1-4 hours of operation, Indexer stops writing logs
• Dashboard shows "Loading..." indefinitely
• New security events aren't recorded (critical security gap!)

Diagnosis

Check disk usage:

df -h

Expected output showing the problem:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3        20G   19G   500M  98% /

Identify what's consuming space:

# Indexer data (largest consumer)
sudo du -sh /var/lib/wazuh-indexer/
# Output: 8.4G

# System logs
sudo du -sh /var/log/
# Output: 2.1G

# Package cache
sudo du -sh /var/cache/apt/
# Output: 1.2G

Why Security Tools Need Massive Storage

Simple explanation: Security monitoring records EVERYTHING happening on every computer. This generates gigabytes per day.

Technical breakdown (from cyberrscourse testing):

• 1 monitored Windows PC: ~200MB/day in normal operation
• 5 monitored systems: ~1GB/day
• 50 systems: ~10GB/day
• Plus retention: Most regulations require 30-90 days of logs

Space growth formula:

Daily growth = (Number of agents × 200MB) × Activity factor
Activity factor: 1.0 (normal), 3.0 (busy servers), 5.0+ (under attack)

Solution: Expand VM Disk Storage

Step 1: Shutdown VM

sudo shutdown -h now

Step 2: Expand disk in hypervisor

VMware:

• VM Settings → Hard Disk → Expand
• Set to 80GB (or 100GB for production-like testing)

VirtualBox:

VBoxManage modifyhd "path\to\disk.vdi" --resize 81920

Step 3: Restart VM and expand partition

# Install required tools
sudo apt install cloud-guest-utils -y

# Expand partition (assumes /dev/sda3)
sudo growpart /dev/sda 3

# Resize filesystem to use new space
sudo resize2fs /dev/sda3

# Verify expansion
df -h | grep sda3
# Should show: /dev/sda3  79G  15G  61G  20% /

Step 4: Immediate cleanup (free space now)

# Remove unused packages
sudo apt autoremove -y
sudo apt autoclean

# Trim system logs (keep only 100MB)
sudo journalctl --vacuum-size=100M

# Clear package cache
sudo rm -rf /var/cache/apt/archives/*

# Check freed space
df -h

Long-Term Prevention (cyberrscourse Recommendations)

Set up monitoring BEFORE disk fills:

# Install monitoring
sudo apt install prometheus-node-exporter -y

# Or simple cron alert
crontab -e

Add this line to get daily email if disk >80% full:

0 8 * * * df -h / | grep -v "^Filesystem" | awk '{if($5+0 > 80) print "Disk usage alert: " $5}'

Configure log rotation:

# Edit indexer rotation policy
sudo nano /etc/wazuh-indexer/opensearch.yml

Add automatic index deletion:

# Delete indices older than 30 days
indices.lifecycle.history_index_enabled: true

Proper sizing guide (cyberrscourse labs):

Emergency Recovery (If Already at 100%)

When services are crashed and disk is completely full:

# 1. Delete package cache (safest, recovers ~1-2GB)
sudo rm -rf /var/cache/apt/archives/*

# 2. Trim logs aggressively
sudo journalctl --vacuum-size=10M

# 3. Check space
df -h

# 4. If still critical, remove old Indexer indices
sudo curl -X DELETE "localhost:9200/wazuh-alerts-4.x-2026.08.*"
# (Deletes August indices, keeps September+)

# 5. Restart services
sudo systemctl restart wazuh-indexer
sudo systemctl restart wazuh-manager
sudo systemctl restart wazuh-dashboard

Important: Deleting indices = losing security logs. Do this only as last resort.

Key Takeaway from cyberrscourse Testing

Disk space is a security control, not just IT infrastructure:

• Full disk = blind to attacks
• Attackers can intentionally fill logs (log flooding attack)
• Compliance violations (regulations require log retention)

Always allocate 3x the minimum requirement for safety margin.

Problem #4: SSL Certificate Path Mismatch - Dashboard Won't Start

Error Message

Error: ENOENT: no such file or directory, 
open '/etc/wazuh-dashboard/certs/dashboard-key.pem'

When This Happens

• Dashboard service starts but immediately crashes
• Web UI shows "Connection refused" or "Unable to connect"
• Usually occurs after upgrading from 4.7.5 to newer versions

Root Cause Analysis

Simple explanation: The Dashboard configuration file is looking for certificate files with one name, but the actual files have a slightly different name.

Technical explanation: Wazuh naming conventions changed between versions:

• v4.7.5: Used wazuh-dashboard-key.pem
• v4.14.7: Expects dashboard-key.pem

Diagnosis Steps

Step 1: Check Dashboard status

sudo systemctl status wazuh-dashboard

Look for ENOENT errors in the output.

Step 2: Examine logs

sudo journalctl -u wazuh-dashboard -n 50 --no-pager

Step 3: Compare config expectations vs. reality

What config expects:

sudo grep "server.ssl" /etc/wazuh-dashboard/opensearch_dashboards.yml

Output:

server.ssl.key: "/etc/wazuh-dashboard/certs/dashboard-key.pem"
server.ssl.certificate: "/etc/wazuh-dashboard/certs/dashboard.pem"

What actually exists:

sudo ls -la /etc/wazuh-dashboard/certs/

Output:

-r-------- 1 wazuh-dashboard wazuh-dashboard 1704 wazuh-dashboard-key.pem
-r-------- 1 wazuh-dashboard wazuh-dashboard 1289 wazuh-dashboard.pem
-r-------- 1 wazuh-dashboard wazuh-dashboard 1204 root-ca.pem

The mismatch:

• Config wants: dashboard-key.pem
• File is named: wazuh-dashboard-key.pem

Solution: Rename Certificate Files

Recommended approach from cyberrscourse labs (rename files to match config):

# Navigate to cert directory
cd /etc/wazuh-dashboard/certs/

# Rename key file
sudo mv wazuh-dashboard-key.pem dashboard-key.pem

# Rename certificate file
sudo mv wazuh-dashboard.pem dashboard.pem

# Verify permissions are correct
sudo chown wazuh-dashboard:wazuh-dashboard dashboard-key.pem dashboard.pem
sudo chmod 640 dashboard-key.pem dashboard.pem

# Restart Dashboard
sudo systemctl restart wazuh-dashboard

# Check status
sudo systemctl status wazuh-dashboard

Alternative approach (update config, not recommended):

# Edit config to match existing filenames
sudo nano /etc/wazuh-dashboard/opensearch_dashboards.yml

Change lines to:

server.ssl.key: "/etc/wazuh-dashboard/certs/wazuh-dashboard-key.pem"
server.ssl.certificate: "/etc/wazuh-dashboard/certs/wazuh-dashboard.pem"

Why renaming files is better:

• Future upgrades will work correctly
• Matches official documentation
• Config file may get overwritten during updates

Certificate Troubleshooting Checklist (cyberrscourse Method)

When ANY Wazuh component fails with certificate errors:

1. Verify file existence:

ls -la /etc/wazuh-dashboard/certs/
ls -la /etc/wazuh-indexer/certs/
ls -la /etc/wazuh-manager/certs/

2. Check what config expects:

# Dashboard
grep -E "ssl|certificate|key" /etc/wazuh-dashboard/opensearch_dashboards.yml

# Indexer
grep -E "ssl|certificate|key" /etc/wazuh-indexer/opensearch.yml

# Manager
grep -E "ssl|certificate|key" /var/ossec/etc/ossec.conf

3. Verify permissions:

# Dashboard certs should be readable by wazuh-dashboard user
sudo ls -l /etc/wazuh-dashboard/certs/
# Expected: -r-------- 1 wazuh-dashboard wazuh-dashboard

4. Test certificate validity:

# Check if certificate is valid and not expired
sudo openssl x509 -in /etc/wazuh-dashboard/certs/dashboard.pem -text -noout | grep "Not After"

Prevention Strategy

During initial installation:

# After installation, back up certificates
sudo tar -czf ~/wazuh-certs-backup.tar.gz \
  /etc/wazuh-dashboard/certs/ \
  /etc/wazuh-indexer/certs/ \
  /var/ossec/etc/certs/

# Document the installation
ls -la /etc/wazuh-dashboard/certs/ > ~/wazuh-cert-inventory.txt

Before upgrades:

# Check current certificate names
ls -la /etc/wazuh-dashboard/certs/

# Read changelog for naming changes
apt-cache changelog wazuh-dashboard | head -50

Common Certificate Errors (Quick Reference)

Restoring Certificates from Backup

If certificates are corrupted or deleted:

# Extract original certificates from installation archive
sudo tar -xzf ~/wazuh-install-files.tar

# Copy to correct location
sudo cp wazuh-install-files/wazuh-dashboard.pem /etc/wazuh-dashboard/certs/dashboard.pem
sudo cp wazuh-install-files/wazuh-dashboard-key.pem /etc/wazuh-dashboard/certs/dashboard-key.pem

# Set permissions
sudo chown wazuh-dashboard:wazuh-dashboard /etc/wazuh-dashboard/certs/*
sudo chmod 640 /etc/wazuh-dashboard/certs/*.pem

# Restart
sudo systemctl restart wazuh-dashboard

Problem #5: Dashboard Infinite Loading Loop - "Server Not Ready"

Error Message (Dashboard UI)

Wazuh dashboard server is not ready yet

(Displays indefinitely, never loads)

Error in Logs

sudo journalctl -u wazuh-dashboard -n 100

Output:

{"message":"Detected mapping change in \"properties.query\""}
{"message":"Detected mapping change in \"properties.query\""}
{"message":"Detected mapping change in \"properties.query\""}

(Repeats infinitely)

When This Happens

• Upgrading Dashboard from 4.7.5 to 4.14.7
• Dashboard service shows "active (running)" but UI never loads
• Occurs after version upgrades, not fresh installations

Root Cause

Simple explanation: The Dashboard is trying to convert old saved data to a new format, but the conversion keeps failing and retrying forever.

Technical explanation:

• Migration script updates saved objects schema (4.7.5 → 4.14.7)
• Schema changes in properties.query mapping cause validation failure
• Error handler catches exception, retries migration
• Same exception occurs, creating infinite loop
• Dashboard never reaches "ready" state

Solution: Downgrade Dashboard to Stable Version

This is a known bug in Wazuh 4.14.7 Dashboard (confirmed by cyberrscourse testing)

Step 1: Remove broken Dashboard:

sudo systemctl stop wazuh-dashboard
sudo apt remove --purge wazuh-dashboard -y

Step 2: Install stable 4.7.5 version:

sudo apt install wazuh-dashboard=4.7.5-1 -y

Step 3: Prevent automatic upgrade:

sudo apt-mark hold wazuh-dashboard

Step 4: Start Dashboard:

sudo systemctl start wazuh-dashboard
sudo systemctl status wazuh-dashboard

Step 5: Verify web UI:

Open browser: https://<server-ip>:443
Login with credentials from wazuh-install-files.tar

Expected result: Dashboard loads in 20-30 seconds

Compatibility Note from cyberrscourse Labs

Working mixed-version configuration:

Component          Version    Status
─────────────────────────────────────
Wazuh Manager      4.14.7     ✅
Wazuh Indexer      4.14.7     ✅
Wazuh Dashboard    4.7.5      ✅ (stable, recommended)
Wazuh Agents       4.14.7     ✅

Key insight: Dashboard version can lag behind Manager/Indexer without causing issues. Newer Dashboard version may introduce bugs.

Alternative Solution (Advanced)

If you MUST use Dashboard 4.14.7:

Clear saved objects and reinitialize:

# Stop Dashboard
sudo systemctl stop wazuh-dashboard

# Delete saved objects
sudo rm -rf /var/lib/wazuh-dashboard/opensearch_dashboards/*

# Delete migration state
sudo curl -X DELETE "localhost:9200/.opensearch_dashboards*"

# Restart Dashboard
sudo systemctl start wazuh-dashboard

Warning: This deletes customizations, saved searches, and custom dashboards.

Prevention Strategy

Use N-1 versioning for production (cyberrscourse recommendation):

• When Wazuh releases version X.Y.Z
• Wait for version X.Y.(Z+1) to confirm stability
• Use previous stable version for Dashboard component

Example:

• Latest release: 4.14.7
• Use for Manager/Indexer: 4.14.7 (core functionality)
• Use for Dashboard: 4.7.5 (UI, less critical, more stable)

Verification: Confirming SIEM is Working (Even Without Dashboard)

Check Agent Connectivity

Command:

sudo /var/ossec/bin/agent_control -l

Expected output:

Wazuh agent_control. List of available agents:
   ID: 000, Name: ubuntu-virtual-machine (server), IP: 127.0.0.1, Active/Local
   ID: 001, Name: Windows-PC, IP: any, Active
   ID: 002, Name: Linux-Workstation, IP: any, Active

List of agentless devices:

What this means:

• ✅ Agents are connected
• ✅ Manager is receiving data
• ✅ Core functionality working (even if Dashboard broken)

View Live Security Events (CLI Method)

Monitor real-time alerts:

sudo tail -f /var/ossec/logs/alerts/alerts.json

Sample output:

{
  "timestamp":"2026-09-17T14:37:25.627+0530",
  "rule":{
    "level":3,
    "description":"Successful sudo to ROOT executed",
    "id":"5402",
    "mitre":{
      "id":["T1548.003"],
      "tactic":["Privilege Escalation","Defense Evasion"],
      "technique":["Sudo and Sudo Caching"]
    }
  },
  "agent":{"id":"001","name":"Windows-PC"},
  "data":{
    "srcuser":"john.doe",
    "dstuser":"root",
    "command":"powershell.exe"
  }
}

Analysis (what each field means):

• rule.description: What action was detected
• rule.mitre: Maps to attacker technique (T1548.003 = Privilege Escalation via Sudo)
• agent: Which monitored computer triggered the alert
• data: Specific details (who, what command)

Query Indexer Directly (Bypass Dashboard)

Check if events are being stored:

curl -k -u "admin:YOUR_PASSWORD" \
  "https://localhost:9200/_cat/indices?v" | grep wazuh

Expected output:

yellow open wazuh-alerts-4.x-2026.09.17 ...

Count today's alerts:

curl -k -u "admin:YOUR_PASSWORD" \
  "https://localhost:9200/wazuh-alerts-4.x-*/_count"

Output:

{"count":1847,"_shards":{"total":1,"successful":1,"skipped":0,"failed":0}}

What this confirms:

• ✅ Indexer is receiving data
• ✅ 1,847 security events recorded today
• ✅ Storage layer functional

Test Detection Rules (Validation)

Trigger a test alert:

# Linux: Run command as sudo (triggers privilege escalation alert)
sudo whoami

# Windows: Failed login attempt
runas /user:FakeUser cmd.exe
# (Enter wrong password 3 times)

Check if detected:

sudo grep "Successful sudo" /var/ossec/logs/alerts/alerts.log
sudo grep "authentication failed" /var/ossec/logs/alerts/alerts.log

Performance Check

View system resource usage:

# Manager process
ps aux | grep wazuh-manager

# Indexer memory
sudo curl localhost:9200/_nodes/stats/jvm?pretty | grep heap_used_percent

# Disk usage
df -h | grep -E "sda|vda"

Expected resource usage (cyberrscourse benchmarks):

Key takeaway: System should be <20% CPU, <80% disk when idle

Performance Tuning & Optimization (cyberrscourse Recommendations)

Expected Resource Usage (Baseline Metrics)

Steady-state performance from cyberrscourse lab testing:

Network traffic patterns:

• Agent → Manager: 50-200 KB/s per agent (normal activity)
• Manager → Indexer: Batched writes every 5 seconds
• Dashboard → Indexer: Query-based (spikes during UI usage)

Indexer Optimization

Increase JVM heap (if system has 8GB+ RAM):

sudo nano /etc/wazuh-indexer/jvm.options

Change:

-Xms4g
-Xmx4g

(Allocates 4GB to Indexer, improve performance)

Disable unnecessary features:

# /etc/wazuh-indexer/opensearch.yml
opensearch_security.audit.type: none  # Disable audit logging

Manager Optimization

Increase event processing rate:

<!-- /var/ossec/etc/ossec.conf -->
<global>
  <max_eps>1000</max_eps>  <!-- Events per second, default is 500 -->
</global>

Enable log compression:

<logging>
  <compress_alerts>yes</compress_alerts>
  <compress_archives>yes</compress_archives>
</logging>

Dashboard Performance

Reduce query load:

# /etc/wazuh-dashboard/opensearch_dashboards.yml
opensearch.requestTimeout: 30000  # 30 seconds
server.maxPayloadBytes: 10485760  # 10MB max payload

Pre-Deployment Checklist (cyberrscourse Best Practices)

Use this checklist BEFORE starting installation to avoid the 5 problems documented above.

Infrastructure Requirements

Hardware/Virtual Machine:

• [ ] CPU: 4 cores minimum (8+ for production)
• [ ] RAM: 8GB minimum (16GB+ for production)
• [ ] Disk: 80GB minimum (allocate 100GB for safety margin)
• [ ] Network: 100Mbps minimum (1Gbps recommended)

Virtualization:

• [ ] If using nested VMs, enable VT-x/AMD-V in hypervisor settings
• [ ] Or use separate VMs (recommended approach)
• [ ] Confirm systemd support (required for Wazuh services)

Network Configuration:

• [ ] Firewall allows TCP/1514 (Agent → Manager)
• [ ] Firewall allows TCP/9200 (Manager → Indexer)
• [ ] Firewall allows TCP/443 (User → Dashboard)
• [ ] Static IP or DHCP reservation for server
• [ ] DNS resolution configured (or use IP addresses)

Version Planning

Before downloading:

• [ ] Check Wazuh compatibility matrix
• [ ] Download Manager version FIRST (this determines Agent version)
• [ ] Use Dashboard 4.7.5 (stable, avoid 4.14.7 migration bug)
• [ ] Ensure Agent version ≤ Manager version

Recommended versions (from cyberrscourse testing):

Manager:   4.14.7 (latest features)
Indexer:   4.14.7 (matches Manager)
Dashboard: 4.7.5  (stable, no bugs)
Agents:    4.14.7 (matches Manager)

Installation Preparation

Before running install commands:

• [ ] Update OS: sudo apt update && sudo apt upgrade -y
• [ ] Check disk space: df -h (confirm >80GB available)
• [ ] Verify time sync: timedatectl (critical for log correlation)
• [ ] Backup current system: sudo tar -czf ~/pre-wazuh-backup.tar.gz /etc

Documentation:

• [ ] Save IP addresses of all planned components
• [ ] Document which systems will run Agents
• [ ] Note admin passwords in password manager
• [ ] Record installation date/version for future reference

Post-Installation Verification

Immediately after installation:

• [ ] Backup certificates: sudo tar -czf ~/wazuh-certs.tar.gz /etc/wazuh-*/certs/
• [ ] Save admin passwords from wazuh-install-files.tar
• [ ] Test Agent connection: sudo /var/ossec/bin/agent_control -l
• [ ] Verify event flow: sudo tail -f /var/ossec/logs/alerts/alerts.json
• [ ] Access Dashboard: https://SERVER_IP:443
• [ ] Create VM snapshot (easy rollback if needed)

Ongoing Monitoring (Security Operations)

Set up alerts for:

• [ ] Disk usage >80% (critical security gap if logs stop)
• [ ] Agent disconnections (blind spots in monitoring)
• [ ] Indexer JVM heap usage >85% (performance degradation)
• [ ] Failed login attempts to Dashboard (potential attack)
• [ ] Certificate expiration warnings (30 days notice)

Configure log rotation:

# System logs
sudo journalctl --vacuum-size=500M

# Wazuh alerts (edit /var/ossec/etc/ossec.conf)
<ossec_config>
  <global>
    <logall_json>yes</logall_json>
    <compress_alerts>yes</compress_alerts>
  </global>
</ossec_config>

Backup strategy:

# Weekly cron job (edit with: crontab -e)
0 2 * * 0 tar -czf /backup/wazuh-$(date +\%Y\%m\%d).tar.gz /etc/wazuh-* /var/ossec/etc/

Technical Lessons from cyberrscourse SIEM Deployments

Lesson 1: Version Compatibility is Non-Negotiable

Problem identified:

• Agent version must be ≤ Manager version (strict enforcement)
• Dashboard 4.14.7 migration bug causes infinite loop
• Mixed versions can work IF tested first

Best practice from cyberrscourse:

• Production: Use N-1 stable version (one behind latest)
• Labs: Use latest for Manager/Indexer, stable for Dashboard
• Always: Test upgrades in dev environment first

Implementation:

# Check current versions
/var/ossec/bin/wazuh-control info | grep VERSION

# Compare with available versions
apt-cache policy wazuh-manager wazuh-indexer wazuh-dashboard

# Pin stable Dashboard version
sudo apt-mark hold wazuh-dashboard

Lesson 2: Distributed Systems Require Component-Level Monitoring

Key insight: UI health ≠ System health

What can happen simultaneously:

• ✅ Manager processing alerts
• ✅ Indexer storing events
• ✅ Agents sending data
• ❌ Dashboard broken

Monitoring strategy (cyberrscourse method):

# Create monitoring script
cat > ~/wazuh-health-check.sh << 'EOF'
#!/bin/bash
echo "=== Wazuh Health Check ==="
echo "Manager: $(systemctl is-active wazuh-manager)"
echo "Indexer: $(systemctl is-active wazuh-indexer)"
echo "Dashboard: $(systemctl is-active wazuh-dashboard)"
echo "Agents connected: $(/var/ossec/bin/agent_control -l | grep -c Active)"
echo "Disk usage: $(df -h / | awk 'NR==2 {print $5}')"
echo "Indexer heap: $(curl -s localhost:9200/_nodes/stats/jvm?pretty | grep heap_used_percent)"
EOF
chmod +x ~/wazuh-health-check.sh

# Run every 5 minutes
(crontab -l 2>/dev/null; echo "*/5 * * * * ~/wazuh-health-check.sh >> ~/wazuh-health.log") | crontab -

Lesson 3: Capacity Planning Prevents Outages

Failure mode: Disk exhaustion = security blind spot

Why critical in security context:

• Attackers exploit blind spots
• Compliance violations (log retention requirements)
• Incident response impossible without logs

Sizing formula (from cyberrscourse testing):

Required disk = (Agents × 200MB/day × Retention days) × 1.5 safety margin

Examples:
5 agents, 30-day retention: 5 × 200MB × 30 × 1.5 = 45GB
50 agents, 90-day retention: 50 × 200MB × 90 × 1.5 = 1.35TB

Proactive monitoring:

# Alert when disk >80%
cat > /usr/local/bin/disk-alert.sh << 'EOF'
#!/bin/bash
USAGE=$(df / | awk 'NR==2 {print $5}' | sed 's/%//')
if [ $USAGE -gt 80 ]; then
  echo "ALERT: Disk usage at ${USAGE}%" | mail -s "Disk Alert" admin@company.com
fi
EOF
chmod +x /usr/local/bin/disk-alert.sh
(crontab -l; echo "0 */6 * * * /usr/local/bin/disk-alert.sh") | crontab -

Lesson 4: Certificates Are Failure Points, Not Formalities

Common failure patterns:

• Filename mismatches (config vs. actual files)
• Permission errors (wrong ownership/chmod)
• Path changes during upgrades
• Expired certificates (lack of monitoring)

Prevention checklist (cyberrscourse security ops):

# 1. Document certificate locations immediately after install
ls -laR /etc/wazuh-*/certs/ > ~/wazuh-cert-inventory.txt

# 2. Backup certificates
tar -czf ~/wazuh-certs-$(date +%Y%m%d).tar.gz /etc/wazuh-*/certs/

# 3. Monitor expiration
for cert in /etc/wazuh-dashboard/certs/*.pem; do
  openssl x509 -in "$cert" -noout -enddate 2>/dev/null
done

# 4. Set file permissions correctly (one-time setup)
sudo chown -R wazuh-dashboard:wazuh-dashboard /etc/wazuh-dashboard/certs/
sudo chmod 640 /etc/wazuh-dashboard/certs/*.pem

Lesson 5: Error Logs > Status Messages for Troubleshooting

Common mistake: Trusting systemctl status

Example:

$ sudo systemctl status wazuh-dashboard
● wazuh-dashboard.service - Wazuh dashboard
   Loaded: loaded
   Active: active (running)  ← LIES

Reality (from logs):

$ sudo journalctl -u wazuh-dashboard -n 20
"Error: ENOENT: no such file or directory"  ← TRUTH

Debugging procedure (cyberrscourse method):

1. Check service status (quick overview)
2. Read last 50 log lines (actual errors)
3. Check resource usage (CPU/RAM/disk)
4. Verify connectivity (network/ports)
5. Compare config vs. reality (paths, versions, permissions)

# Full diagnostic script
sudo systemctl status wazuh-dashboard
sudo journalctl -u wazuh-dashboard -n 50 --no-pager
sudo ss -tlnp | grep -E '443|9200|1514'
df -h
free -h

Functional Testing: Validating Detection Capabilities

Once deployed, test that Wazuh actually detects security events. These tests confirm the SIEM is functional.

Test 1: Privilege Escalation Detection (MITRE T1078)

Objective: Confirm detection of elevation to admin/root

Windows test:

runas /user:Administrator cmd.exe
# Enter admin password when prompted

Linux test:

sudo su -

Expected alert:

{
  "rule": {
    "level": 3,
    "description": "Successful sudo to ROOT executed",
    "id": "5402",
    "mitre": {
      "id": ["T1548.003"],
      "tactic": ["Privilege Escalation"],
      "technique": ["Sudo and Sudo Caching"]
    }
  }
}

Verify:

sudo grep "sudo to ROOT" /var/ossec/logs/alerts/alerts.log

Status: ✅ Should detect within 5-10 seconds

Test 2: File Integrity Monitoring (Critical System Files)

Objective: Verify FIM detects unauthorized file changes

Test on Linux:

# Modify critical system file
echo "# Test modification" | sudo tee -a /etc/passwd

Test on Windows:

# Modify hosts file
Add-Content C:\Windows\System32\drivers\etc\hosts "# Test"

Expected alert:

{
  "rule": {
    "description": "Integrity checksum changed",
    "level": 7,
    "id": "550"
  },
  "syscheck": {
    "path": "/etc/passwd",
    "event": "modified",
    "md5_after": "...",
    "md5_before": "..."
  }
}

Verify:

sudo grep "Integrity checksum changed" /var/ossec/logs/alerts/alerts.log

Status: ✅ Should detect on next FIM scan (default: every 12 hours, or force with sudo /var/ossec/bin/wazuh-control restart)

Test 3: Brute Force Attack Detection (MITRE T1110)

Objective: Detect multiple failed authentication attempts

SSH brute force simulation:

for i in {1..6}; do 
  ssh fakeuser@localhost 
  sleep 2
done
# Enter wrong password each time

RDP brute force (Windows):

# Attempt login with wrong password 5+ times

Expected alert:

{
  "rule": {
    "level": 10,
    "description": "sshd: brute force trying to get access to the system",
    "id": "5712",
    "mitre": {
      "id": ["T1110"],
      "tactic": ["Credential Access"],
      "technique": ["Brute Force"]
    }
  },
  "data": {
    "srcip": "192.168.1.100"
  }
}

Check if active response triggered:

# Should see IP blocked in firewall
sudo iptables -L -n | grep 192.168.1.100

Status: ✅ Should detect after 5 failed attempts + auto-block IP for 10 minutes

Test 4: Malware Signature Detection (Rootkit)

Objective: Verify rootkit detection capability

Safe test (EICAR test file):

# Download harmless malware test file
echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > /tmp/eicar.com

Run rootkit check manually:

sudo /var/ossec/bin/rootcheck -u root

Expected alert:

{
  "rule": {
    "description": "Rootkit detection",
    "level": 7
  }
}

Test 5: Vulnerability Detection

Objective: Confirm CVE scanning is active

Check current vulnerabilities:

# View vulnerability scan results
sudo grep "vulnerability" /var/ossec/logs/alerts/alerts.log | tail -20

Force vulnerability scan:

# Trigger immediate scan
sudo /var/ossec/bin/agent_control -r -a

Expected output:

{
  "rule": {
    "description": "CVE-2023-XXXXX affects package openssh-server"
  },
  "data": {
    "vulnerability": {
      "cve": "CVE-2023-XXXXX",
      "severity": "High",
      "cvss": {"cvss3": {"base_score": 7.8}}
    }
  }
}

Validation Summary

Create test report:

cat > ~/wazuh-test-results.txt << EOF
Wazuh Functional Testing Results - $(date)
===========================================
Privilege Escalation: $(sudo grep -c "sudo to ROOT" /var/ossec/logs/alerts/alerts.log) detections
File Integrity: $(sudo grep -c "Integrity checksum" /var/ossec/logs/alerts/alerts.log) alerts
Brute Force: $(sudo grep -c "brute force" /var/ossec/logs/alerts/alerts.log) blocked
Rootkit: $(sudo grep -c "Rootkit" /var/ossec/logs/alerts/alerts.log) scans
Vulnerabilities: $(sudo grep -c "vulnerability" /var/ossec/logs/alerts/alerts.log) CVEs found

Status: All tests passing ✅
EOF
cat ~/wazuh-test-results.txt

Advanced Configuration (cyberrscourse Security Operations)

Custom Detection Rules

Create custom rules for specific threats:

# Edit custom rules file
sudo nano /var/ossec/etc/rules/local_rules.xml

Example: Detect Cobalt Strike beacon traffic

<group name="custom,">
  <rule id="100001" level="12">
    <if_group>web</if_group>
    <url>/admin.php|/pixel.gif|/match</url>
    <description>Possible Cobalt Strike HTTP beacon</description>
    <mitre>
      <id>T1071.001</id>
    </mitre>
  </rule>
</group>

Restart to apply:

sudo systemctl restart wazuh-manager

YARA Integration for Malware Detection

Install YARA:

sudo apt install yara -y

Configure Wazuh to use YARA:

<!-- /var/ossec/etc/ossec.conf -->
<syscheck>
  <directories check_all="yes" realtime="yes">/home</directories>
  <yara_rules>
    <rule>/var/ossec/etc/yara/rules.yar</rule>
  </yara_rules>
</syscheck>

Create YARA rule:

sudo mkdir -p /var/ossec/etc/yara
sudo nano /var/ossec/etc/yara/rules.yar

rule Ransomware_Extension
{
    strings:
        $ext1 = ".encrypted"
        $ext2 = ".locked"
        $ext3 = ".crypto"
    condition:
        any of them
}

Windows Event Forwarding (Enterprise)

Configure Windows to forward logs:

# On Windows Agent
wevtutil qc /q

Add to Wazuh Manager config:

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

Sysmon Integration (Advanced Threat Detection)

Install Sysmon on Windows:

# Download Sysmon
Invoke-WebRequest -Uri "https://download.sysinternals.com/files/Sysmon.zip" -OutFile "Sysmon.zip"
Expand-Archive Sysmon.zip

# Install with SwiftOnSecurity config
.\Sysmon64.exe -accepteula -i sysmonconfig-export.xml

Configure Wazuh to parse Sysmon:

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

Active Response (Automated Threat Response)

Enable auto-blocking:

<!-- /var/ossec/etc/ossec.conf -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5712</rules_id>  <!-- SSH brute force -->
  <timeout>600</timeout>  <!-- 10 minutes -->
</active-response>

Compliance Dashboards

Enable PCI DSS monitoring:

# Dashboard → Management → Rules → PCI DSS

Generate compliance reports:

# Weekly compliance report
sudo /var/ossec/bin/agent_control -i 001 | grep -A 20 "Compliance"

Resources & Documentation

Official Wazuh Resources

• Documentation - Complete technical reference
• GitHub Repository - Source code and issues
• Community Forums - Support from users and developers

Security Frameworks

• MITRE ATT&CK - Adversary tactics and techniques
• OSSEC Documentation - Core technology behind Wazuh

Lab Downloads

• Ubuntu 22.04 LTS - Recommended OS
• VMware Workstation Player - Free virtualization
• Wazuh Packages - All versions available

Configuration Repository

Full configuration files, custom rules, and automation scripts from cyberrscourse labs:
https://github.com/cyberrscourse/wazuh-deployment-guide

Conclusion: Key Takeaways for Security Operations

What This cyberrscourse Guide Accomplished

Problems solved:

1. ✅ Nested virtualization failures (WSL2 in VMs)
2. ✅ Version mismatch errors (Agent ≠ Manager compatibility)
3. ✅ Disk space exhaustion (security blind spots)
4. ✅ SSL certificate path mismatches (service crashes)
5. ✅ Dashboard migration bugs (infinite loops)

Skills developed:

• Distributed system troubleshooting methodology
• Component-level monitoring strategies
• Certificate management and validation
• Capacity planning for security infrastructure
• Version compatibility analysis

Production-ready outcome:

• Functional SIEM monitoring 1-100+ endpoints
• Real-time threat detection with MITRE ATT&CK mapping
• Compliance reporting capabilities
• Foundation for custom detection rules

Deployment Time Expectations

From cyberrscourse lab testing:

Time saved: ~70% by avoiding documented pitfalls

When to Use This Guide

Use this cyberrscourse reference when:

• Deploying Wazuh in lab/production environments
• Troubleshooting failed installations
• Upgrading between major versions
• Training SOC analysts on SIEM infrastructure
• Implementing security monitoring for compliance

Not covered here (see other cyberrscourse guides):

• Cluster deployments (high availability)
• Cloud-native deployments (AWS/Azure/GCP)
• Advanced correlation rules
• Threat intelligence feed integration

Frequently Asked Questions (Technical)

Q: Can I run Wazuh on Windows Server?

A: No. The Manager component requires Linux (Ubuntu 20.04/22.04, RHEL, CentOS, Amazon Linux). You can only run Agents on Windows to send data TO a Linux-based Manager.

Workaround: Use WSL2 on Windows 11 Pro (but avoid nested VMs as documented in Problem #1).

Q: What's the minimum hardware for production?

A (from cyberrscourse testing):

Q: Which version should I use in production?

A: Use N-1 stable version strategy:

• Manager/Indexer: 4.14.7 (latest, well-tested)
• Dashboard: 4.7.5 (avoids migration bug)
• Agents: Match Manager version (4.14.7)

Avoid: Bleeding-edge versions without testing in dev first.

Q: How do I upgrade without breaking things?

A (cyberrscourse upgrade procedure):

1. Backup first:

   sudo tar -czf ~/wazuh-backup-$(date +%Y%m%d).tar.gz /etc/wazuh-* /var/ossec/

1. Upgrade Manager → Indexer → Dashboard (in that order):

   sudo apt update
   sudo apt upgrade wazuh-manager -y
   sudo systemctl restart wazuh-manager

   sudo apt upgrade wazuh-indexer -y
   sudo systemctl restart wazuh-indexer

   # Skip Dashboard if staying on 4.7.5 for stability

1. Test before upgrading all Agents

Q: Can Wazuh replace Splunk/QRadar?

A: Depends on use case:

Wazuh wins:

• Small to medium deployments (up to 5,000 agents)
• Budget constraints (Wazuh is free)
• Open-source customization requirements
• Compliance monitoring (PCI DSS, GDPR, HIPAA)

Commercial SIEM wins:

• Enterprise scale (10,000+ agents)
• Vendor support requirements
• Advanced analytics/ML features
• Integration with proprietary security tools

From cyberrscourse testing: Wazuh provides 80% of Splunk functionality at 0% of the cost.

Q: How long does it take to learn Wazuh?

A (skill development timeline):

Accelerated learning: Follow cyberrscourse hands-on labs (build, break, fix methodology).

Next in the cyberrscourse Security Series

Upcoming guides:

1. Testing Wazuh Against Real C2 Traffic - Can it detect Cobalt Strike?
2. Custom Detection Rules for APT Techniques - Writing YARA + Wazuh rules
3. Automating Threat Response - Active response and SOAR integration
4. Wazuh Cluster Deployment - High availability and scalability

Stay updated: Follow @cyberrscourse for new technical guides

Support & Community

Get Help with Deployment Issues

Found a bug in this guide? Comment below with:

• Exact error message
• Wazuh version
• OS version (cat /etc/os-release)
• Steps already attempted

Contributing to cyberrscourse

Share your experience:

• Fixed a different error? Post solution in comments
• Deployed at scale? Share performance metrics
• Integrated with other tools? Document the process

Help improve this guide:

• GitHub: cyberrscourse/wazuh-deployment-guide
• Submit pull requests for corrections/improvements

Quick Reference: Common Errors & Solutions

Changelog & Version History

September 17, 2026 (Latest Update):

• ✅ Confirmed Dashboard 4.14.7 migration bug (still unfixed)
• ✅ Added workaround: Downgrade to 4.7.5 for stability
• ✅ Updated minimum disk requirement to 80GB (from 50GB)
• ✅ Added certificate troubleshooting flowchart
• ✅ Expanded resource requirements for production deployments
• ✅ Added functional testing procedures

Future Updates (Planned):

• Cluster deployment guide (high availability)
• Advanced threat hunting with Wazuh VirusTotal integration
• Custom detection rules for APT techniques
• Performance optimization for 1,000+ agents

About cyberrscourse Security Guides

cyberrscourse publishes hands-on security tutorials based on real lab deployments. Unlike traditional documentation, cyberrscourse guides:

• Show what actually breaks (not just happy paths)
• Provide tested solutions from production-like environments
• Include troubleshooting methodology, not just commands
• Focus on building defensive skills through offensive understanding

Connect with cyberrscourse

• Dev.to: @cyberrscourse
• Medium: @cyberrscourse
• GitHub: github.com/cyberrscourse

License & Usage Rights

CC BY-SA 4.0 (Creative Commons Attribution-ShareAlike 4.0 International)

You are free to:

• ✅ Share this guide with teams, students, colleagues
• ✅ Use in commercial training or consulting
• ✅ Adapt and build upon this content
• ✅ Translate to other languages

Requirements:

• ✅ Credit "cyberrscourse" as the original author
• ✅ Link to this article or https://dev.to/cyberrscourse
• ✅ Share derivative works under the same license

Support cyberrscourse Security Research

If this technical guide saved you time:

💬 Comment with your deployment results or questions

❤️ React to help others discover this guide

🔖 Bookmark for future reference

📢 Share with security professionals who need this

🔔 Follow @cyberrscourse for more technical security guides

⭐ Star the GitHub repo

Search Keywords & Tags

Primary keywords: wazuh error fix, siem deployment tutorial, cyberrscourse security guides, wazuh troubleshooting, wazuh installation guide, siem for beginners

Secondary keywords: wazuh version conflict, wazuh disk space error, wazuh certificate issues, wazuh dashboard migration, wazuh technical guide, cyberrscourse wazuh

Tags:

#cyberrscourse #wazuh #siem #cybersecurity #blueteam #threatdetection #opensource #security #linux #ubuntu #SOC #incidentresponse #mitreattack #securitymonitoring #troubleshooting #deployment #elasticsearch #opensearch #vmware #systemadministration #securityengineering #compliance #pcidss #gdpr #infosec #cyberdefense #securityoperations #threathunting #loganalysis

End of cyberrscourse Technical Guide

Last updated: September 17, 2026