Skip to main content
COSMICBYTEZLABS
NewsSecurityHOWTOsToolsStudyTraining
ProjectsChecklistsAI RankingsNewsletterStatusTagsAbout
Subscribe

Press Enter to search or Esc to close

News
Security
HOWTOs
Tools
Study
Training
Projects
Checklists
AI Rankings
Newsletter
Status
Tags
About
RSS Feed
Reading List
Subscribe

Stay in the Loop

Get the latest security alerts, tutorials, and tech insights delivered to your inbox.

Subscribe NowFree forever. No spam.
COSMICBYTEZLABS

Your trusted source for IT intelligence, cybersecurity insights, and hands-on technical guides.

429+ Articles
114+ Guides

CONTENT

  • Latest News
  • Security Alerts
  • HOWTOs
  • Projects
  • Exam Prep

RESOURCES

  • Search
  • Browse Tags
  • Newsletter Archive
  • Reading List
  • RSS Feed

COMPANY

  • About Us
  • Contact
  • Privacy Policy
  • Terms of Service

© 2026 CosmicBytez Labs. All rights reserved.

System Status: Operational
  1. Home
  2. HOWTOs
  3. How to Deploy Wazuh SIEM/XDR for Unified Security Monitoring
How to Deploy Wazuh SIEM/XDR for Unified Security Monitoring
HOWTOIntermediate

How to Deploy Wazuh SIEM/XDR for Unified Security Monitoring

Step-by-step guide to deploying Wazuh as an open-source SIEM and XDR platform. Covers server installation, agent deployment across Windows and Linux,...

Dylan H.

Security Engineering

March 13, 2026
13 min read

Prerequisites

  • Linux server administration (Ubuntu 22.04/24.04 or RHEL 9 recommended)
  • Basic understanding of SIEM concepts and log management
  • Network access to endpoints you want to monitor
  • Minimum 4 vCPU / 8 GB RAM for the Wazuh manager

Overview

Wazuh is a free, open-source security platform that combines SIEM (Security Information and Event Management) and XDR (Extended Detection and Response) capabilities in a single unified solution. Originally forked from OSSEC, Wazuh has grown into a production-grade platform trusted by thousands of organizations worldwide.

A full Wazuh deployment gives you:

  • Threat detection — pre-built rules covering MITRE ATT&CK TTPs, rootkits, web attacks, brute force, and more
  • Log data management — centralized ingestion from endpoints, network devices, cloud services, and applications
  • File integrity monitoring (FIM) — real-time alerting on unauthorized file and registry changes
  • Vulnerability detection — CVE correlation against installed packages on all monitored endpoints
  • Active response — automated remediation (block IPs, kill processes, quarantine files) triggered by detection rules
  • Compliance — built-in dashboards for PCI-DSS, HIPAA, GDPR, NIST 800-53, CIS benchmarks

Architecture Overview

ComponentRoleDeployment
Wazuh ManagerRules engine, alert correlation, agent managementLinux server (central)
Wazuh IndexerAlert/log storage (OpenSearch-based)Same host or dedicated cluster
Wazuh DashboardWeb UI, visualizations, investigationSame host or dedicated
Wazuh AgentData collection on monitored endpointsEvery host you want visibility into

Who Should Use This Guide

  • SOC teams building internal SIEM capabilities without budget for commercial tools
  • Security engineers standing up detection-in-depth for SMB or homelab environments
  • IT administrators who need centralized log management, FIM, and vulnerability tracking
  • Blue teamers preparing for incident response who want endpoint telemetry

Requirements

Server Requirements

TiervCPURAMStorageEndpoint Scale
Lab / Small48 GB100 GB SSDUp to 25 agents
Medium816 GB500 GB SSD25–100 agents
Large1632 GB1 TB+ SSD100–500 agents
EnterpriseCluster64 GB+Distributed500+ agents

Note: The Wazuh Indexer is OpenSearch-based and is the primary memory consumer. Allocate at least 50% of available RAM to the indexer heap.

Supported Platforms

Manager: Ubuntu 20.04/22.04/24.04, RHEL 8/9, Amazon Linux 2023, Debian 11/12

Agents: Windows Server 2012+, Windows 10/11, Ubuntu, RHEL/CentOS, Debian, macOS, FreeBSD, Solaris, AIX

Network Requirements

ConnectionProtocolPortDirection
Agent → ManagerTCP1514Agents to manager
Agent enrollmentTCP1515Agents to manager
Dashboard accessHTTPS443Users to dashboard host
Indexer APIHTTPS9200Manager to indexer
Cluster communicationTCP1516Manager nodes (cluster)

Step 1: Install the Wazuh Server (All-in-One)

This guide uses the Wazuh quick installation assistant, which deploys Manager, Indexer, and Dashboard on a single host. This is appropriate for environments up to ~100 agents. For larger deployments, refer to the distributed installation documentation.

1.1 Prepare the Host

# Update the system
sudo apt-get update && sudo apt-get upgrade -y
 
# Set a proper hostname (important for certificate generation)
sudo hostnamectl set-hostname wazuh-server
echo "127.0.0.1 wazuh-server" | sudo tee -a /etc/hosts
 
# Disable swap (required for Wazuh Indexer/OpenSearch)
sudo swapoff -a
sudo sed -i '/swap/d' /etc/fstab
 
# Increase virtual memory map count
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

1.2 Run the Wazuh Installation Assistant

# Download the installation assistant
curl -sO https://packages.wazuh.com/4.x/wazuh-install.sh
curl -sO https://packages.wazuh.com/4.x/config.yml

Edit config.yml to define your node names and IP addresses:

nodes:
  # Wazuh indexer nodes
  indexer:
    - name: node-1
      ip: "<YOUR_SERVER_IP>"
 
  # Wazuh server nodes
  server:
    - name: wazuh-1
      ip: "<YOUR_SERVER_IP>"
 
  # Wazuh dashboard nodes
  dashboard:
    - name: dashboard
      ip: "<YOUR_SERVER_IP>"

Run the installation:

# Generate certificates
sudo bash wazuh-install.sh --generate-config-files
 
# Install the Wazuh Indexer
sudo bash wazuh-install.sh --wazuh-indexer node-1
 
# Initialize the indexer cluster
sudo bash wazuh-install.sh --start-cluster
 
# Install the Wazuh Server (manager + filebeat)
sudo bash wazuh-install.sh --wazuh-server wazuh-1
 
# Install the Wazuh Dashboard
sudo bash wazuh-install.sh --wazuh-dashboard dashboard

The installer outputs the admin credentials at the end:

INFO: --- Summary ---
INFO: You can access the web interface https://<YOUR_IP>
    User: admin
    Password: <GENERATED_PASSWORD>

Save these credentials securely. Access the dashboard at https://<YOUR_IP>.


Step 2: Harden the Wazuh Manager

Before deploying agents, apply baseline hardening to the manager.

2.1 Change Default Passwords

# Change the admin password via the API
sudo /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh -u admin -p '<NEW_STRONG_PASSWORD>'

2.2 Enable TLS Certificate Pinning for Agents

Edit /var/ossec/etc/ossec.conf to enforce encrypted agent communications:

<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <alerts_log>yes</alerts_log>
    <logall>no</logall>
    <logall_json>no</logall_json>
    <email_notification>no</email_notification>
    <smtp_server>localhost</smtp_server>
    <email_from>wazuh@localhost</email_from>
    <email_to>admin@yourdomain.com</email_to>
    <email_maxperhour>12</email_maxperhour>
    <queue_size>131072</queue_size>
  </global>
 
  <!-- Enforce agent authentication with certificates -->
  <auth>
    <disabled>no</disabled>
    <port>1515</port>
    <use_source_ip>no</use_source_ip>
    <force>
      <enabled>yes</enabled>
      <key_mismatch>yes</key_mismatch>
      <disconnected_time enabled="yes">1h</disconnected_time>
      <after_registration_time>1h</after_registration_time>
    </force>
    <purge>yes</purge>
    <use_password>yes</use_password>
    <ssl_agent_ca></ssl_agent_ca>
    <ssl_verify_host>no</ssl_verify_host>
    <ssl_manager_cert>/var/ossec/etc/sslmanager.cert</ssl_manager_cert>
    <ssl_manager_key>/var/ossec/etc/sslmanager.key</ssl_manager_key>
    <ssl_auto_negotiate>no</ssl_auto_negotiate>
  </auth>
</ossec_config>

Set an agent enrollment password:

# Create the enrollment password file
echo '<YOUR_ENROLLMENT_PASSWORD>' | sudo tee /var/ossec/etc/authd.pass
sudo chmod 640 /var/ossec/etc/authd.pass
sudo chown root:wazuh /var/ossec/etc/authd.pass
 
# Restart the manager to apply changes
sudo systemctl restart wazuh-manager

2.3 Configure Log Retention

Edit the Wazuh Indexer Index State Management (ISM) policy to control how long alerts are retained:

# Create a 90-day retention policy via the Indexer API
curl -k -u admin:<PASSWORD> -X PUT "https://localhost:9200/_plugins/_ism/policies/wazuh-retention" \
  -H "Content-Type: application/json" \
  -d '{
    "policy": {
      "description": "Wazuh 90-day alert retention",
      "default_state": "hot",
      "states": [
        {
          "name": "hot",
          "actions": [],
          "transitions": [{"state_name": "delete", "conditions": {"min_index_age": "90d"}}]
        },
        {
          "name": "delete",
          "actions": [{"delete": {}}],
          "transitions": []
        }
      ],
      "ism_template": [{"index_patterns": ["wazuh-alerts-*"], "priority": 100}]
    }
  }'

Step 3: Deploy Wazuh Agents

3.1 Linux Agent (Ubuntu/Debian)

# Add the Wazuh repository
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
 
# Install the agent
WAZUH_MANAGER="<MANAGER_IP>" WAZUH_AGENT_NAME="$(hostname)" apt-get install wazuh-agent -y
 
# Enable and start the agent
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent

3.2 Windows Agent (PowerShell)

Run the following on the Windows endpoint as Administrator:

# Download the installer
$WazuhVersion = "4.10.1"
$InstallerUrl = "https://packages.wazuh.com/4.x/windows/wazuh-agent-$WazuhVersion-1.msi"
$InstallerPath = "$env:TEMP\wazuh-agent.msi"
 
Invoke-WebRequest -Uri $InstallerUrl -OutFile $InstallerPath
 
# Install silently, pointing to your manager
$ManagerIP = "<MANAGER_IP>"
$AgentName = $env:COMPUTERNAME
$EnrollPass = "<YOUR_ENROLLMENT_PASSWORD>"
 
Start-Process msiexec.exe -ArgumentList @(
    "/i", $InstallerPath,
    "/q",
    "WAZUH_MANAGER=$ManagerIP",
    "WAZUH_AGENT_NAME=$AgentName",
    "WAZUH_REGISTRATION_PASSWORD=$EnrollPass"
) -Wait
 
# Start the Wazuh service
Start-Service -Name WazuhSvc
Set-Service -Name WazuhSvc -StartupType Automatic
 
Write-Host "Wazuh agent installed and started on $AgentName"

3.3 Mass Deployment via PowerShell (Domain-Joined Endpoints)

For domain environments, use Group Policy or a deployment script:

# deploy-wazuh-agents.ps1 — run from a management host with admin rights to targets
param(
    [string[]]$Computers,
    [string]$ManagerIP,
    [string]$EnrollPassword,
    [string]$WazuhVersion = "4.10.1"
)
 
$InstallerUrl = "https://packages.wazuh.com/4.x/windows/wazuh-agent-$WazuhVersion-1.msi"
$LocalInstaller = "\\<FILE_SHARE>\wazuh-agent.msi"
 
# Pre-download installer to a share accessible by targets
Invoke-WebRequest -Uri $InstallerUrl -OutFile $LocalInstaller
 
foreach ($Computer in $Computers) {
    Write-Host "Deploying to $Computer..."
 
    Invoke-Command -ComputerName $Computer -ScriptBlock {
        param($Installer, $Manager, $Pass, $Name)
 
        if (Get-Service -Name WazuhSvc -ErrorAction SilentlyContinue) {
            Write-Host "Wazuh already installed on $env:COMPUTERNAME, skipping."
            return
        }
 
        Start-Process msiexec.exe -ArgumentList @(
            "/i", $Installer, "/q",
            "WAZUH_MANAGER=$Manager",
            "WAZUH_AGENT_NAME=$Name",
            "WAZUH_REGISTRATION_PASSWORD=$Pass"
        ) -Wait
 
        Start-Service -Name WazuhSvc
        Set-Service -Name WazuhSvc -StartupType Automatic
        Write-Host "Done: $env:COMPUTERNAME"
 
    } -ArgumentList $LocalInstaller, $ManagerIP, $EnrollPassword, $Computer
}

Step 4: Configure Detection Rules

Wazuh ships with 3,000+ built-in rules. Extend them with custom rules tailored to your environment.

4.1 Custom Rule Structure

Custom rules live in /var/ossec/etc/rules/local_rules.xml. Rules use a simple XML format:

<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="local,custom">
 
  <!-- Alert on failed SSH logins exceeding threshold -->
  <rule id="100001" level="10" frequency="5" timeframe="120">
    <if_matched_sid>5716</if_matched_sid>
    <description>SSH brute force: 5+ failed logins in 120 seconds</description>
    <group>authentication_failures,pci_dss_10.2.4,pci_dss_10.2.5</group>
  </rule>
 
  <!-- Detect PowerShell encoded command execution -->
  <rule id="100002" level="12">
    <if_group>windows</if_group>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)-enc(odedcommand)?[\s]+[A-Za-z0-9+/=]{20,}</field>
    <description>PowerShell encoded command execution detected</description>
    <mitre>
      <id>T1059.001</id>
    </mitre>
    <group>attack,execution</group>
  </rule>
 
  <!-- Alert on new local admin account creation -->
  <rule id="100003" level="14">
    <if_sid>18152</if_sid>
    <field name="win.eventdata.targetUserName" negate="yes">\.+\$</field>
    <description>New local administrator account created: $(win.eventdata.targetUserName)</description>
    <mitre>
      <id>T1136.001</id>
    </mitre>
    <group>attack,persistence,pci_dss_8.1</group>
  </rule>
 
  <!-- Detect large outbound data transfers (potential exfiltration) -->
  <rule id="100004" level="10">
    <if_group>firewall</if_group>
    <field name="data.bytes_out" compare="greater_than">104857600</field>
    <description>Large outbound data transfer: $(data.bytes_out) bytes to $(data.dstip)</description>
    <mitre>
      <id>T1048</id>
    </mitre>
    <group>attack,exfiltration</group>
  </rule>
 
</group>

Reload rules without restarting the manager:

sudo /var/ossec/bin/wazuh-logtest   # Test rules interactively
sudo systemctl reload wazuh-manager # Apply without full restart

4.2 File Integrity Monitoring (FIM) Configuration

Configure FIM in the agent's ossec.conf or push via centralized configuration:

<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency>  <!-- Full scan every 12 hours -->
  <scan_on_start>yes</scan_on_start>
 
  <!-- Monitor critical Linux paths -->
  <directories realtime="yes" check_all="yes" report_changes="yes">/etc</directories>
  <directories realtime="yes" check_all="yes">/usr/bin,/usr/sbin</directories>
  <directories realtime="yes" check_all="yes">/bin,/sbin</directories>
 
  <!-- Monitor critical Windows paths -->
  <directories realtime="yes" check_all="yes" report_changes="yes">%WINDIR%\System32\drivers\etc</directories>
  <directories realtime="yes" check_all="yes">%WINDIR%\System32</directories>
 
  <!-- Windows Registry monitoring -->
  <windows_registry>HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run</windows_registry>
  <windows_registry>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services</windows_registry>
  <windows_registry>HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon</windows_registry>
 
  <!-- Exclusions -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/hosts.deny</ignore>
  <ignore type="sregex">^/proc</ignore>
  <ignore type="sregex">\.log$|\.tmp$|\.swp$</ignore>
</syscheck>

Step 5: Configure Active Response

Active response automatically executes scripts when specific alerts fire. Use with caution — test thoroughly before enabling in production.

5.1 Define Active Response Actions

Add to /var/ossec/etc/ossec.conf on the manager:

<ossec_config>
  <!-- Block an IP using iptables when a brute force alert fires -->
  <active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <rules_id>100001</rules_id>  <!-- Our SSH brute force rule -->
    <timeout>3600</timeout>       <!-- Block for 1 hour -->
  </active-response>
 
  <!-- Kill a process when malware is detected (rule level 15+) -->
  <active-response>
    <command>kill-process</command>
    <location>local</location>
    <level>15</level>
    <timeout>0</timeout>  <!-- No auto-unblock for process kill -->
  </active-response>
</ossec_config>

5.2 Custom Active Response Script (Block-and-Alert)

Place custom scripts in /var/ossec/active-response/bin/:

#!/bin/bash
# /var/ossec/active-response/bin/block-and-notify.sh
# Blocks an attacker IP and sends a Slack webhook notification
 
ACTION=$1
USER=$2
IP=$3
ALERT_ID=$4
RULE_ID=$5
 
SLACK_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
 
if [ "$ACTION" = "add" ]; then
    # Block the IP
    iptables -I INPUT -s "$IP" -j DROP
    iptables -I FORWARD -s "$IP" -j DROP
 
    # Send Slack notification
    curl -s -X POST "$SLACK_WEBHOOK" \
      -H "Content-Type: application/json" \
      -d "{\"text\": \":shield: *Wazuh Active Response Triggered*\nRule ID: $RULE_ID\nAlert ID: $ALERT_ID\nBlocked IP: \`$IP\`\nAction: Blocked via iptables for 1 hour\"}"
 
    echo "$(date) - Blocked IP $IP for rule $RULE_ID" >> /var/ossec/logs/active-responses.log
 
elif [ "$ACTION" = "delete" ]; then
    # Unblock after timeout
    iptables -D INPUT -s "$IP" -j DROP
    iptables -D FORWARD -s "$IP" -j DROP
    echo "$(date) - Unblocked IP $IP" >> /var/ossec/logs/active-responses.log
fi
sudo chmod 750 /var/ossec/active-response/bin/block-and-notify.sh
sudo chown root:wazuh /var/ossec/active-response/bin/block-and-notify.sh

Step 6: Ingest External Log Sources

6.1 Syslog Ingestion (Firewalls, Switches, WAFs)

Configure Wazuh to receive syslog from network devices:

<!-- Add to /var/ossec/etc/ossec.conf on the manager -->
<ossec_config>
  <remote>
    <connection>syslog</connection>
    <port>514</port>
    <protocol>udp</protocol>
    <allowed-ips>192.168.1.0/24</allowed-ips>  <!-- Your network range -->
  </remote>
 
  <!-- Also listen on TCP 514 for reliable delivery -->
  <remote>
    <connection>syslog</connection>
    <port>514</port>
    <protocol>tcp</protocol>
    <allowed-ips>192.168.1.0/24</allowed-ips>
  </remote>
</ossec_config>

Point your FortiGate, Cisco ASA, pfSense, or other network devices at the Wazuh manager IP on UDP/TCP 514.

6.2 Windows Event Log Collection

Expand Windows event log coverage on each agent's ossec.conf:

<ossec_config>
  <localfile>
    <location>Security</location>
    <log_format>eventchannel</log_format>
    <query>Event/System[EventID != 4688 or (EventID = 4688 and Event/EventData/Data[@Name='SubjectUserName'] != 'SYSTEM')]</query>
  </localfile>
 
  <localfile>
    <location>System</location>
    <log_format>eventchannel</log_format>
  </localfile>
 
  <localfile>
    <location>Application</location>
    <log_format>eventchannel</log_format>
  </localfile>
 
  <!-- PowerShell Operational — critical for detecting script-based attacks -->
  <localfile>
    <location>Microsoft-Windows-PowerShell/Operational</location>
    <log_format>eventchannel</log_format>
  </localfile>
 
  <!-- Windows Defender events -->
  <localfile>
    <location>Microsoft-Windows-Windows Defender/Operational</location>
    <log_format>eventchannel</log_format>
  </localfile>
 
  <!-- Sysmon — if deployed -->
  <localfile>
    <location>Microsoft-Windows-Sysmon/Operational</location>
    <log_format>eventchannel</log_format>
  </localfile>
</ossec_config>

6.3 Cloud Log Integration (Azure Activity Logs)

Use the Wazuh Azure module to ingest Activity Logs and Microsoft Entra audit logs:

<!-- Add to ossec.conf on the manager -->
<wodle name="azure-logs">
  <disabled>no</disabled>
  <interval>10m</interval>
  <run_on_start>yes</run_on_start>
  <log_analytics>
    <application_id>YOUR_APP_ID</application_id>
    <application_key>YOUR_APP_SECRET</application_key>
    <tenantdomain>yourtenant.onmicrosoft.com</tenantdomain>
    <workspace>YOUR_LOG_ANALYTICS_WORKSPACE_ID</workspace>
    <workspace_key>YOUR_WORKSPACE_KEY</workspace_key>
    <request>
      <tag>azure-activity</tag>
      <query>AzureActivity | where TimeGenerated > ago(10m)</query>
      <time_offset>10m</time_offset>
    </request>
  </log_analytics>
</wodle>

Step 7: Build Dashboard Visualizations

The Wazuh Dashboard (based on OpenSearch Dashboards) supports custom visualizations.

Key Dashboards to Configure

DashboardPurposeKey Metrics
Security EventsAlert timeline and severity breakdownEvents/hour, top rules, top agents
Threat HuntingMITRE ATT&CK heatmapTactic/technique frequency
FIMFile change trackingModified files, affected agents, change types
VulnerabilityCVE exposureCritical CVEs, top vulnerable packages
CompliancePCI/HIPAA/CIS statusControl pass/fail rates by framework

Useful Saved Searches (KQL)

Open the Wazuh Dashboard → Discover, and save these searches:

# High severity alerts (last 24h)
rule.level: [10 TO *] AND @timestamp: [now-24h TO now]

# Authentication failures
rule.groups: "authentication_failed"

# New process creation (Sysmon EventID 1)
data.win.system.eventID: 1 AND data.win.eventdata.parentImage: *

# Lateral movement indicators
rule.mitre.tactic: "Lateral Movement"

# Outbound connections to unusual ports
data.win.system.eventID: 3 AND NOT data.win.eventdata.destinationPort: (80 OR 443 OR 53)

Step 8: Verify the Deployment

8.1 Check Agent Connectivity

# List all connected agents and their status
sudo /var/ossec/bin/agent_control -lc
 
# Example output:
# ID: 001, Name: web-server-01, IP: 192.168.1.10, Status: Active
# ID: 002, Name: WIN-DC01, IP: 192.168.1.5, Status: Active
# ID: 003, Name: db-server-02, IP: 192.168.1.20, Status: Disconnected

8.2 Validate Rule Engine

Use the built-in log test utility to verify rules fire correctly:

sudo /var/ossec/bin/wazuh-logtest
 
# When prompted, paste a sample log line, e.g.:
# Mar 13 10:22:15 web01 sshd[1234]: Failed password for invalid user admin from 1.2.3.4 port 55123 ssh2
 
# Expected output will show matched rule, level, and groups

8.3 Test Active Response

Trigger a test response safely in a lab environment:

# Manually trigger firewall-drop for a test IP (use a non-production IP)
sudo /var/ossec/bin/agent_control -b 198.51.100.1 -f firewall-drop0 -u 001
 
# Verify the block was applied on the agent
sudo iptables -L INPUT -n | grep 198.51.100.1
 
# Remove the test block
sudo iptables -D INPUT -s 198.51.100.1 -j DROP

8.4 Health Check Script

#!/bin/bash
# wazuh-health-check.sh — run daily via cron
 
echo "=== Wazuh Health Check: $(date) ==="
 
# Manager service status
echo -n "Manager: "
systemctl is-active wazuh-manager && echo "OK" || echo "FAILED"
 
# Indexer status
echo -n "Indexer: "
systemctl is-active wazuh-indexer && echo "OK" || echo "FAILED"
 
# Dashboard status
echo -n "Dashboard: "
systemctl is-active wazuh-dashboard && echo "OK" || echo "FAILED"
 
# Active agent count
ACTIVE=$(sudo /var/ossec/bin/agent_control -lc 2>/dev/null | grep -c "Status: Active")
TOTAL=$(sudo /var/ossec/bin/agent_control -l 2>/dev/null | grep -c "^ID:")
echo "Agents: $ACTIVE/$TOTAL active"
 
# Disk usage on log partition
echo -n "Log disk usage: "
df -h /var/ossec/logs | awk 'NR==2{print $5" used ("$4" free)"}'
 
# Recent alert count (last hour)
ALERTS=$(find /var/ossec/logs/alerts/ -name "*.json" -newer /tmp/.wazuh-check-marker 2>/dev/null | wc -l)
touch /tmp/.wazuh-check-marker
echo "Alerts (last run): $ALERTS alert files"
 
echo "=== End Health Check ==="
sudo chmod +x /usr/local/bin/wazuh-health-check.sh
 
# Run daily at 6am
echo "0 6 * * * root /usr/local/bin/wazuh-health-check.sh >> /var/log/wazuh-health.log 2>&1" \
  | sudo tee /etc/cron.d/wazuh-health

Troubleshooting

SymptomLikely CauseResolution
Agent shows "Disconnected"Firewall blocking TCP 1514Open TCP 1514 from agent to manager
Agent fails to registerWrong enrollment passwordVerify /var/ossec/etc/authd.pass on manager matches agent config
No alerts appearing in DashboardIndexer connection issueCheck filebeat service; run filebeat test output
High memory usage on IndexerJVM heap too large/smallSet Xms and Xmx to 50% of RAM in /etc/wazuh-indexer/jvm.options
Rules not triggeringDecoder mismatchUse wazuh-logtest to debug which decoder and rule is matched
FIM generating too many alertsDirectories too broadNarrow FIM scope; add exclusions for volatile paths (/proc, log files)
Active response blocking legitimate trafficRule too broadAdd same_source_ip and tune rule frequency/timeframe

Next Steps

With Wazuh deployed and agents reporting in, consider these enhancements:

  • Integrate Threat Intelligence — connect MISP or OpenCTI to enrich alerts with IOC context using the Wazuh Vulnerability Detector
  • SOAR Integration — forward high-severity alerts to TheHive or Shuffle SOAR for automated case management
  • Sysmon Deployment — deploy Sysmon with a hardened config (e.g., SwiftOnSecurity template) on all Windows agents for richer process and network telemetry
  • Cloud Workload Monitoring — extend agents to AWS EC2, Azure VMs, and GCP Compute for unified cloud/on-prem visibility
  • Multi-manager Cluster — for environments exceeding 500 agents, deploy a Wazuh cluster with worker nodes to distribute load
  • Wazuh + Shuffle SOAR — automate incident response workflows triggered by Wazuh alerts using the native Wazuh Shuffle integration

Wazuh's open architecture and active community mean the platform evolves rapidly. Subscribe to the Wazuh blog and monitor their GitHub releases for rule updates and new detection capabilities.

Related Reading

  • Build Your Own SIEM with Open-Source Tools
  • How to Configure Microsoft Sentinel Analytics Rules
  • Windows Security Event Log Analysis: Detect Threats and
#Wazuh#SIEM#XDR#Threat Detection#Log Management#Incident Response#Security Monitoring#Open Source

Related Articles

How to Configure Microsoft Sentinel Analytics Rules

End-to-end SOC guide for Microsoft Sentinel: build KQL-based scheduled and NRT analytics rules, wire automation rules for incident triage, and deploy...

15 min read

Windows Security Event Log Analysis: Detect Threats and

Learn to analyze Windows Security Event Logs to detect brute force attacks, lateral movement, privilege escalation, and other security threats using PowerShell.

9 min read

How to Deploy Falco for Kubernetes Runtime Security Monitoring

Step-by-step guide to deploying Falco as a Kubernetes runtime security engine. Covers Helm installation, custom rule authoring, Falcosidekick alerting...

12 min read
Back to all HOWTOs