!

Wazuh SIEM

Security Monitoring & Threat Detection

SIEM XDR Threat Intel Project D

Part 1: The Blueprint

What Are We Building?

A complete Security Information and Event Management (SIEM) platform using Wazuh. This is your home lab's Security Operations Center (SOC) — monitoring all your servers, detecting threats in real-time, and alerting you when something bad happens.

What You'll Have When Done

Real-World Problem This Solves

Enterprise Context

The Problem: In any organization, you have dozens or hundreds of servers generating millions of log entries. Without a SIEM, you're flying blind — attacks happen and you don't know until it's too late.

The Solution: Wazuh collects all logs, applies detection rules, correlates events, and alerts on threats. SOC Analysts with Wazuh experience command salaries of $80K-$140K annually.

How Wazuh Works


Agents
Servers

Manager
Analysis

Indexer
Storage

Dashboard
Visualize

Alerts
Notify
Table of Contents

Part 2: Preparation

Prerequisite Knowledge

You should be familiar with:

Hardware Requirements

Resource Heavy!

Wazuh with the Indexer uses significant RAM. If running alongside Projects A-C, you'll need at least 16 GB total RAM on your server.

Resource Minimum Recommended
CPU 4 cores 8 cores
RAM 8 GB 16 GB
Storage 50 GB SSD 100+ GB SSD
Network Port 1514 UDP (agents), Port 443 (dashboard) —

Prerequisites Checklist

1

Phase 1: Core Concepts

Understanding SIEM and Wazuh architecture before we build.

15-20 minutes Reading / Understanding

Wazuh Architecture

Agent
Runs on monitored servers, collects logs and security data
Manager
Receives data from agents, applies rules, generates alerts
Indexer
Stores and indexes all security data (OpenSearch)
Dashboard
Web interface for visualization and analysis

Alert Severity Levels

Wazuh uses a 0-15 severity scale. Understanding these levels is critical for SOC operations:

0-6
Low
7-9
Medium
10-12
High
13-15
Critical
2

Phase 2: Wazuh Installation

Deploy the complete Wazuh stack using Docker.

30-45 minutes Performed on: WAZUH SERVER

Task 2.1: Clone Wazuh Docker Repository

WAZUH SERVER — Via SSH Connection
1
Create Directory and Clone Repository
Bash SERVER 
# Create Wazuh directory
mkdir -p ~/wazuh-docker
cd ~/wazuh-docker

# Clone official Wazuh Docker repository (v4.9.0)
git clone https://github.com/wazuh/wazuh-docker.git -b v4.9.0

# Navigate to single-node deployment
cd wazuh-docker/single-node

# Verify structure
ls -la

Task 2.2: Generate SSL Certificates

WAZUH SERVER — Via SSH Connection
2
Generate Self-Signed Certificates
Bash SERVER 
# Generate certificates for Wazuh components
docker compose -f generate-indexer-certs.yml run --rm generator

# Verify certificates were created
ls -la config/wazuh_indexer_ssl_certs/

Task 2.3: Start Wazuh Stack

WAZUH SERVER — Via SSH Connection
3
Start All Wazuh Services
Bash SERVER 
# Start all Wazuh services (this takes 2-3 minutes)
docker compose up -d

# This starts:
# - wazuh.manager (log analysis, rules engine)
# - wazuh.indexer (data storage, search)
# - wazuh.dashboard (web interface)

# Check container status
docker compose ps

# Watch logs for "Wazuh is ready" message
docker compose logs -f --tail=50
First Start Takes Time

The indexer needs to initialize. Wait 2-3 minutes before accessing the dashboard. Watch for "Wazuh is ready" in the logs.

Verification

Check all containers are running healthy:

Bash SERVER 
# Check container health
docker compose ps

# Verify Manager status
docker exec -it single-node-wazuh.manager-1 /var/ossec/bin/wazuh-control status
Expected Output:
NAME STATUS PORTS single-node-wazuh.manager Up 1514-1516/tcp, 55000/tcp single-node-wazuh.indexer Up 9200/tcp single-node-wazuh.dashboard Up 443/tcp wazuh-modulesd is running... wazuh-analysisd is running... wazuh-execd is running...

Task 2.4: Access Wazuh Dashboard

BROWSER — On Your Local Machine
4
Login to Wazuh Dashboard
  1. Open browser: https://YOUR_SERVER_IP
  2. Accept the self-signed certificate warning
  3. Login with default credentials:
Usernameadmin
PasswordSecretPassword
Change Default Password Immediately!

Go to Settings Security Internal Users to change the admin password. Default passwords are a critical security vulnerability.

Phase 2 Complete!

Wazuh is running! You should see the dashboard with "0 agents connected." Let's add some agents next!

3

Phase 3: Deploy Wazuh Agents

Install monitoring agents on servers you want to protect.

15-20 minutes per agent Performed on: TARGET Servers (the servers to monitor)

Agents run on each server you want to monitor. They collect logs, detect threats, and send data to the Wazuh Manager.

Task 3.1: Install Agent on Ubuntu/Debian

TARGET SERVER — The server you want to monitor
1
Add Repository and Install Agent
Bash — Ubuntu/Debian TARGET 
# Add Wazuh GPG key
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

# Add Wazuh repository
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

# Update and install agent
# IMPORTANT: Replace YOUR_WAZUH_SERVER_IP with actual IP
apt update
WAZUH_MANAGER="YOUR_WAZUH_SERVER_IP" apt install -y wazuh-agent

# Enable and start the agent
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent

# Check status
systemctl status wazuh-agent
Replace IP Address!

Change YOUR_WAZUH_SERVER_IP to the actual IP address of your Wazuh server (e.g., 192.168.1.100).

Verification

Back on your Wazuh Dashboard, check Agents Management:

Expected Result:
Agents: 1 Active New agent visible with hostname and IP
4

Phase 4: Custom Detection Rules

Create custom rules to detect specific threats.

30-45 minutes Performed on: WAZUH SERVER

Task 4.1: Create SSH Brute Force Detection Rule

WAZUH SERVER — Via SSH Connection
1
Create Custom Rules File
Bash SERVER 
# Create custom rules file inside the Wazuh Manager container
docker exec -it single-node-wazuh.manager-1 bash -c 'cat > /var/ossec/etc/rules/local_rules.xml << "EOF"
<!-- Custom Wazuh Rules -->
<group name="local,syslog,sshd,">

  <!-- SSH Brute Force Detection -->
  <rule id="100001" level="10" frequency="5" timeframe="120">
    <if_matched_sid>5710</if_matched_sid>
    <description>SSH brute force attack detected (5+ failures in 2 min)</description>
    <mitre>
      <id>T1110.001</id>  <!-- Brute Force: Password Guessing -->
    </mitre>
    <group>authentication_failures,brute_force</group>
  </rule>

  <!-- Successful Root Login Alert -->
  <rule id="100002" level="12">
    <if_sid>5715</if_sid>
    <user>root</user>
    <description>Root user logged in via SSH - HIGH PRIORITY</description>
    <mitre>
      <id>T1078.003</id>  <!-- Valid Accounts: Local Accounts -->
    </mitre>
    <group>authentication_success,privilege_escalation</group>
  </rule>

</group>
EOF'

# Restart Wazuh Manager to load rules
docker exec single-node-wazuh.manager-1 /var/ossec/bin/wazuh-control restart

# Verify rules loaded
docker exec single-node-wazuh.manager-1 /var/ossec/bin/wazuh-control status
Understanding the Rule
  • id="100001" — Custom rules should use IDs 100000+
  • level="10" — Severity (0-15, where 15 is most severe)
  • frequency="5" — Triggers after 5 matching events
  • timeframe="120" — Within 120 seconds (2 minutes)
  • if_matched_sid — Chains to built-in SSH failure rule 5710
  • MITRE T1110.001 — Maps to MITRE ATT&CK framework

Troubleshooting Guide

Common issues and their solutions when working with Wazuh.

Agent Not Connecting
Cause: Firewall blocking port 1514/UDP, or incorrect manager IP.
Solutions:
  1. Check agent logs: tail -f /var/ossec/logs/ossec.log
  2. Verify manager IP in agent config: cat /var/ossec/etc/ossec.conf
  3. Open port 1514/UDP on firewall
  4. Test connectivity: nc -uvz MANAGER_IP 1514
Dashboard Won't Load
Cause: Indexer still initializing or out of memory.
Solutions:
  1. Wait 3-5 minutes after startup for indexer to initialize
  2. Check memory: free -h
  3. Check indexer logs: docker logs single-node-wazuh.indexer-1
  4. Ensure at least 4GB RAM available for containers
No Alerts Appearing
Cause: Agent not sending data or rules not matching.
Solutions:
  1. Check agent status: systemctl status wazuh-agent
  2. Verify alerts.log: tail -f /var/ossec/logs/alerts/alerts.log
  3. Test rule with logtest: /var/ossec/bin/wazuh-logtest

Part 4: Completion

Cleanup Instructions

WAZUH SERVER
Bash SERVER 
cd ~/wazuh-docker/wazuh-docker/single-node

# Option A: Stop services (preserve data)
docker compose stop

# Option B: Complete removal (DELETES ALL DATA)
docker compose down -v
rm -rf ~/wazuh-docker

Skills Gained

Resume-Ready Skills

Skill Description
Wazuh SIEM/XDRDeployment, configuration, and rule development
MITRE ATT&CKMapping detections to ATT&CK framework
Log ManagementCentralized log collection and analysis
Detection EngineeringCustom rule creation and tuning
Incident ResponseAlert triage and automated response
Interview Questions — Prove Your Mastery
Q1: What is the difference between a SIEM and an XDR?
A: SIEM (Security Information and Event Management) focuses on log collection, correlation, and alerting. XDR (Extended Detection and Response) extends this with automated response capabilities, endpoint telemetry, and deeper integration across security tools. Wazuh provides both capabilities — it collects logs like a SIEM but also includes active response (blocking IPs, killing processes) like an XDR.
Q2: Explain how you would tune a high-volume alert rule to reduce false positives.
A: First, analyze the alert data to identify patterns causing false positives. Then use techniques like: (1) Adding exclusion filters for known-good sources, (2) Increasing the frequency threshold, (3) Adding time-based conditions (business hours vs off-hours), (4) Whitelisting specific users/hosts, (5) Correlating with other data sources to increase confidence. Always document tuning decisions for audit purposes.
Q3: What is MITRE ATT&CK and how do you use it in detection engineering?
A: MITRE ATT&CK is a knowledge base of adversary tactics, techniques, and procedures (TTPs). In detection engineering, we map our rules to ATT&CK IDs (e.g., T1110.001 for brute force). This provides: (1) Common language for threat discussion, (2) Gap analysis to identify missing detections, (3) Threat intelligence correlation, (4) Coverage metrics for security leadership. In Wazuh, we add <mitre><id>T1110.001</id></mitre> tags to rules.
Q4: A server is generating 10,000 events per second and overwhelming the SIEM. How do you handle this?
A: Multiple approaches: (1) Implement log filtering at the agent to drop noise before transmission, (2) Use aggregation rules to combine repetitive events, (3) Increase indexer capacity (more shards, more nodes), (4) Implement tiered storage (hot/warm/cold), (5) Review what's generating the volume and fix the root cause (misconfigured application, debug logging enabled, etc.). In Wazuh, configure <localfile> sections to filter before sending.
Q5: Describe the Wazuh alert flow from agent to dashboard.
A: Flow: (1) Agent collects logs from monitored sources (syslog, auth.log, application logs), (2) Agent sends events to Manager via port 1514/UDP, (3) Manager's analysisd process decodes events and matches against rules, (4) Matching events generate alerts written to alerts.log and JSON, (5) Filebeat ships alerts to the Indexer (OpenSearch), (6) Dashboard queries the Indexer to display alerts. This architecture allows horizontal scaling at each layer.

Additional Resources

Congratulations!

You've built an enterprise-grade Security Operations Center! Your home lab now has the same threat detection capabilities used by Fortune 500 companies.