How to Install Wazuh Security Platform on a Linux Server (Clean Installation)

Wazuh Agents

How to Install Wazuh Security Platform on a Linux Server (Clean Installation)

Wazuh is an enterprise-ready, open-source security monitoring platform that offers unified XDR and SIEM protection. Deploying it on a clean Linux server allows you to aggregate logs, analyze endpoint telemetry, and identify security anomalies seamlessly.

This guide outlines the single-node / all-in-one setup process using the official Wazuh installation assistant. It installs the Wazuh Indexer, Wazuh Server, and Wazuh Dashboard on a single machine.

Minimum Hardware Requirements

Before running the script, ensure your system fulfills the baseline hardware requirements for a single-node setup supporting up to 25 agents:

CPU: 4 vCPUs
RAM: 8 GB RAM minimum
Storage: 50 GB free disk space
OS: Ubuntu (e.g., 22.04 LTS / 24.04 LTS) or Debian (11 / 12)

Step-by-Step Installation

Step 1: Update the System Dependencies

Log into your target Linux instance and ensure your local package tree and baseline cryptographic tools are up to date.

sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install -y curl apt-transport-https unzip wget libcap2-bin software-properties-common lsb-release gnupg2

Step 2: Download the Official Installation Assistant

Pull down the official Wazuh installation automated script directly from the secure package repository.

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

(Note: If you need a specific version boundary lock, replace 4.x with the target release version string, or run it as shown to grab the current standard lifecycle build).

Step 3: Run the All-In-One Automated Installer

Execute the helper script with the automated single-node payload flag (-a or --all-in-one). This process will build dependencies, compile cryptographic tokens, configure configuration templates, and hook up the background units.

sudo bash wazuh-install.sh -a

Note: The process can take between 5 to 15 minutes depending on your network download speeds and backend processing power.

Post-Installation & Accessing the Dashboard

Once the installation workflow achieves a successful exit status, the terminal output will print a confirmation block detailing your local node routes:

Wazuh indexer installation finished successfully.
Wazuh server installation finished successfully.
Wazuh dashboard installation finished successfully.
 
Installation finished.
You can access the web interface at https://<YOUR_SERVER_IP>
   User: admin
   Password: <A_RANDOMLY_GENERATED_SECURE_PASSWORD>

Step 4: Secure Your Generated Credentials

Copy the randomly generated password immediately from the terminal window.
Save this token inside an encrypted credential store or password manager.
Do not clear the terminal session until this token is logged safely.

Step 5: Log in to the Web Interface

Launch a browser window and navigate to your server's endpoint:
https://<YOUR_SERVER_IP>
Because the automated script provisions secure, self-signed local TLS certificates, your browser will display a warning stating that the connection is not private.
Click on Advanced and choose Proceed or Accept the Risk.
Enter the default master user profile name (admin) along with the custom generated password sequence you captured in Step 4.

Verifying Server Services Status

If you ever need to manually track or confirm the core operational health states of the system daemons via CLI, run these diagnostic status strings directly over SSH:

Verify Indexer Backend Status:
```
sudo systemctl status wazuh-indexer
```
Verify Core Management Engine Status:
```
sudo systemctl status wazuh-manager
```
Verify Web Console UI Engine Status:
```
sudo systemctl status wazuh-dashboard
```

Your clean Wazuh environment is now fully deployed and ready to ingest telemetry agents!

*******************************************************************

How to Fix Broken Wazuh-Manager Uninstallation and APT Loops

When purging or uninstalling the wazuh-manager package on Debian or Ubuntu systems, the process can sometimes fail. This failure typically happens because the package's internal maintainer scripts reference files or directories that no longer exist, or they call commands that fail.

When this happens, it creates an aggressive APT loop, locking your package manager and preventing you from installing, updating, or removing other software on your machine.

This guide provides a safe, step-by-step walkthrough to bypass these broken maintainer scripts, unlock APT, and completely purge leftover tracking configurations from your file system.

Symptoms & Error Messages

You will generally encounter one of two blocking errors during your package uninstallation process:

1. Pre-Removal Failure

dpkg: error processing package wazuh-manager (--remove):
 old wazuh-manager package prerm maintainer script subprocess failed with exit status 127

2. Post-Removal Failure

find: ‘/var/ossec/api/’: No such file or directory
dpkg: error processing package wazuh-manager (--remove):
 old wazuh-manager package postrm maintainer script subprocess failed with exit status 1

Step-by-Step Resolution Guide

Step 1: Force Pass the Pre-Removal (prerm) Script

If your uninstallation fails immediately with an exit status 127, the pre-removal script configuration is broken. You can force dpkg to skip this logic by completely emptying the processing script instructions.

Open the package's pre-removal script environment metadata wrapper using a text editor:
```
sudo nano /var/lib/dpkg/info/wazuh-manager.prerm
```
Delete all existing lines in the file and replace them with a clean exit sequence:
```
#!/bin/sh
exit 0
```
Save the file and exit the editor (Ctrl + O, tap Enter, then press Ctrl + X).

Step 2: Fix the Post-Removal (postrm) Script Loop

If you attempt to clean up your system using autoremove and it fails because the /var/ossec/api/ directory is missing from previous cleanup runs, use one of the following two options to satisfy the package manager validation loop.

Option A: Empty the Post-Removal Script (Recommended)

Open the post-removal script:

sudo nano /var/lib/dpkg/info/wazuh-manager.postrm

Delete everything inside and replace it with a clean exit sequence:
```
#!/bin/sh
exit 0
```
Save and close out the editor session.

Option B: Recreate the Expected Directory Structure

Alternatively, you can manually recreate the dummy nested directory structures that the script's native execution loop commands are querying for:

sudo mkdir -p /var/ossec/api/

Step 3: Complete the Package Removal

With the blocking scripts successfully bypassed, tell APT to process the remaining uninstallation queues and completely flush its local metadata transaction index caches:

sudo apt-get autoremove -y && sudo apt-get clean

Step 4: Purge Residual Data Directories

Manually wipe any remaining file structures left on the server storage volume to ensure a completely clean slate before running a reinstallation task:

sudo rm -rf /var/ossec

Step 5: Verify the System State

Run the following verification audits to guarantee no stale configuration definitions or zombie processes persist inside your background environments.

Check database package registration status:
```
dpkg -l | grep wazuh
```
Note: If the output returns a status code of rc, it means old configuration layouts are still cached on disk. Fully purge those parameters by calling the binary removal flag directly:
```
sudo dpkg --purge wazuh-manager
```
Confirm the system background service is completely wiped:
```
systemctl status wazuh-manager
```
Expected Result: Unit wazuh-manager.service could not be found.

Your package manager manager is now completely unlocked, healthy, and ready for normal server orchestration tasks!

*************************************************************************************

How to Configure the Grafana OpenSearch Data Source for Wazuh Alerts

Connecting Grafana to your Wazuh Indexer allows you to build rich, custom security dashboards using your security telemetry. Because the Wazuh Indexer is built on OpenSearch architecture, using the official Grafana OpenSearch plugin provides the most reliable connection and field mapping.

Follow this complete step-by-step blueprint to install the plugin, bypass common UI validation errors, and properly map your security log fields without exposing sensitive credentials.

Step 1: Check and Install the OpenSearch Plugin

Before configuring the database connection, ensure Grafana has the translation layer required to speak to an OpenSearch backend.

Check your Grafana UI under Connections > Data sources. Search for OpenSearch.
If it is not listed, log into your Grafana server's terminal and deploy it securely via the Grafana CLI framework:
```
grafana-cli plugins install grafana-opensearch-datasource
```
Restart your local systems daemon to apply the plugin update immediately:
```
sudo systemctl restart grafana-server
```

Step 2: Configure the Primary Connection Settings

Navigate back to your Grafana web interface under Connections > Data sources > Add new data source, select OpenSearch, and apply these specific core settings:

Name: wazuh-opensearch-core (or any descriptive cluster identifier).
URL: Enter your indexer network endpoint (e.g., https://<YOUR_INDEXER_IP>:9200).
*(Note: If Grafana runs inside a Docker container on the same host machine, use https://host.docker.internal:9200 to resolve the network link loopback).*
Basic Auth: Toggle this ON. Under Basic Auth Details, enter your secure cluster service account credentials.
Skip TLS Verify: Toggle this ON. This parameter is mandatory if your indexer targets utilize default self-signed SSL certificates, which Grafana will otherwise reject.

Step 3: Input Index Mappings & Bypass the UI Validation Bug

A known UI validation bug in the plugin frequently throws a "Data source not found" or "404" error if you attempt to fetch the server version before a primary database record exists. Use this exact workflow to bypass it:

Scroll down to the OpenSearch details block form.
Index name: Enter wazuh-alerts-4.x-* (this targets the default daily security logs index pattern).
Time field name: Type @timestamp.
Version (The Bypass): Do not click "Get Version and Save". Instead, manually click inside the empty version text block and explicitly hardcode a placeholder version value like 2.13.0.
Clear Unsaved States: Ensure the Logs metadata boxes (Message field name and Level field name) and the Data Links arrays are completely empty for this initial setup write. If a placeholder container block has initialized, use the trash can icon to clear it.
Save the Shell: Scroll to the absolute bottom of the configuration console page and click the green Save & test button.
Refresh: As soon as Grafana attempts the initial write loop, manually reload your browser window (F5) to force the client interface to parse the newly registered data source UID correctly.

Step 4: Finalize Log Definitions & Verify

Now that the structural data source profile is registered inside Grafana's core database architecture, you can safely map your database elements without triggering web dashboard validation crashes.

Re-open your newly saved OpenSearch data source connection profile.
Scroll down directly to the Logs sub-section form.
Message field name: Enter rule.description. This mapping directive tells Grafana which field string contains the human-readable event alert notification text.
Level field name: Enter rule.level.

💡 Pro-Tip: Avoid utilizing generic server configurations like syslog_level. Wazuh passes alert severities as clean numerical arrays ranking from 0 to 15 inside the rule.level key, which Grafana's Explore UI parses cleanly for automated dashboard color-coding.

Scroll down to the footer link and click Save & test one final time. You will receive a green confirmation success badge reading:

Index OK. Time field name OK.

Your Grafana analytics pipeline is now completely deployed, structured correctly, and ready for you to build rich security visualizations!

*************************************************************************************

Complete Guide: Integrating Wazuh IT Hygiene Dashboards into Grafana

A comprehensive step-by-step walkthrough to extract API credentials, extend token lifespans, configure the Infinity Data Source, and deploy a robust multi-agent IT Hygiene dashboard.

Step 1: Locating your Wazuh API Credentials

Before connecting Grafana, you need the API username and password. On modern Wazuh installations, these credentials are automatically written in plain text inside the dashboard configuration file.

Log into your Wazuh server terminal and run the following command to read the configuration:

sudo cat /usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml

Look for the username and password values under the hosts section (typically username is wazuh-wui).

Step 2: Generating a Bearer Token via Terminal

Wazuh uses JWT tokens for secure REST API authentication. You can generate a session token by sending an authenticated request using curl:

curl -u 'wazuh-wui:YOUR_PASSWORD_HERE' -k -X GET "https://127.0.0.1:55000/security/user/authenticate?raw=true"

Copy the resulting long string of random characters—this is your Bearer Token.

Step 3: Extending the Token Expiration Timeout

By default, Wazuh API tokens expire every 15 minutes, which will break live Grafana boards. In modern Wazuh versions, you can dynamically update this via the API rather than editing configuration files.

Save a temporary token to memory:

TOKEN=$(curl -u 'wazuh-wui:YOUR_PASSWORD_HERE' -k -s -X GET "https://127.0.0.1:55000/security/user/authenticate?raw=true")

Update the API configuration database (e.g., setting expiration to 1 year / 31,536,000 seconds):

curl -k -X PUT "https://127.0.0.1:55000/security/config" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"auth_token_exp_timeout": 31536000}'

Generate your permanent token:

curl -u 'wazuh-wui:YOUR_PASSWORD_HERE' -k -X GET "https://127.0.0.1:55000/security/user/authenticate?raw=true"

Step 4: Configuring Grafana and the Infinity Data Source

Once inside Grafana using the Yesoreyeram Infinity Data Source plugin:

Set your Base URL to point to your Wazuh API server (e.g., https://YOUR_IP:55000).
Navigate to the Authentication settings tab.
Select Auth Type: Bearer Token and paste your long-lived token string.
Click Save & test to ensure a successful connection.

Step 5: Building the Dashboard & Managing Agent Scope

Wazuh syscollector endpoints (such as packages, ports, and hardware inventory) require an explicit agent identifier in the URI path (e.g., /syscollector/${agent_id}/packages) and will return a 404 Not Found if queried globally.

To view multiple servers cleanly:

Configure your dashboard variable (agent_id) to fetch available systems via /agents?select=id,name.
Enable multi-value and include the "All" option inside the variable settings.
Use Grafana's Row Repeating feature mapped to agent_id to automatically clone and stack your IT hygiene panels for every active agent in your fleet.

💡 Success Note: Successfully deploying this structure gives you a centralized, persistent operational view of your entire infrastructure's IT hygiene metrics!

*************************************************************************************

How to Fix Wazuh Repository Errors and Install the Wazuh Agent

If you run a package manager update and encounter 404 Not Found or configured multiple times errors related to Wazuh, your configuration file is corrupted. This guide walks you through cleaning up broken entries, adding the correct official repository source, and successfully deploying the endpoint agent.

Step 1: Clean Up Corrupted Repository Files

An incorrect domain name and duplicate lines inside the sources directory cause package management updates to fail. Remove the broken file to start fresh.

sudo rm -f /etc/apt/sources.list.d/wazuh.list

Step 2: Import the Official Trust Key

Download and install the official cryptographic trust key. This ensures your local operating system trusts the authentication signature of the vendor packages.

curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && sudo chmod 644 /usr/share/keyrings/wazuh.gpg

Step 3: Add the Verified Repository URL

Inject the official, stable package repository path back into your operating system's sources layout.

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

Step 4: Purge Old Cache and Refresh Package Indexes

Wipe local metadata caches of old, corrupted package index strings, then pull down a clean list of available software.

sudo rm -rf /var/lib/apt/lists/*wazuh*
sudo apt-get update

Step 5: Define the Controller Endpoint and Install the Agent

Declare your central management server's network destination in your temporary environment variables. Use the preservation flag (-E) to pass this value safely through the root privilege execution step.

# Define your central management node location
export WAZUH_MANAGER="<YOUR_WAZUH_MANAGER_IP_OR_HOSTNAME>"
 
# Install the agent package cleanly
sudo -E apt-get install wazuh-agent -y

Step 6: Initialize and Bootstrap the Agent Service

Reload your system management daemon, register the service to start automatically during system boot initialization, and kick off the active runtime immediately.

sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

Your endpoint monitor agent is now safely configured, operating, and establishing a telemetry channel back to your central console.

Step 7: Audit and Verify the Installation

After starting the service, confirm that the agent is running properly and successfully connecting to your management node.

Check Service Status

Verify that the process is active (running) without any initial errors:

sudo systemctl status wazuh-agent

Inspect the Connection Logs

Monitor the agent's connection logs in real time to ensure it establishes a successful handshake with the manager:

sudo tail -f /var/ossec/logs/ossec.log | grep -i -E "error|warn|connected"

Verification Token: Look for an entry stating INFO: (4102): Connected to the server to confirm a successful setup loop.

*******************************************************************

How to Enable Anonymous Login on Wazuh Dashboard

A step-by-step guide to configuring anonymous access for Wazuh Indexer and enabling the one-click "Log in as anonymous" option in the Wazuh Dashboard.

Warning: Allowing anonymous login grants full administrative or read access without password verification. Only enable this on isolated lab or test environments.

Step 1: Enable Anonymous Auth in Wazuh Indexer

Edit the main security settings file:

sudo nano /etc/wazuh-indexer/opensearch-security/config.yml

Set anonymous_auth_enabled to true under http::

config:
  dynamic:
    http:
      anonymous_auth_enabled: true

Step 2: Map Anonymous Roles in Indexer

Open the roles mapping file:

sudo nano /etc/wazuh-indexer/opensearch-security/roles_mapping.yml

Update the all_access block to attach anonymous credentials to admin permissions (ensure no duplicate key lines exist):

all_access:
  reserved: false
  hidden: false
  users:
  - "admin"
  - "opendistro_security_anonymous"
  backend_roles:
  - "admin"
  - "opendistro_security_anonymous"
  - "opendistro_security_anonymous_backendrole"
  hosts: []
  and_backend_roles: []
  description: "Maps admin to all_access"

Step 3: Sync Security Settings to the Cluster

Run the security administration tool using Wazuh's bundled Java environment:

sudo OPENSEARCH_JAVA_HOME=/usr/share/wazuh-indexer/jdk /usr/share/wazuh-indexer/plugins/opensearch-security/tools/securityadmin.sh \
  -cd /etc/wazuh-indexer/opensearch-security \
  -nhnv \
  -cacert /etc/wazuh-indexer/certs/root-ca.pem \
  -cert /etc/wazuh-indexer/certs/admin.pem \
  -key /etc/wazuh-indexer/certs/admin-key.pem \
  -p 9200

Verify that the output finishes with Done with success and ERRORS: 0.

Step 4: Enable Anonymous Auth in Wazuh Dashboard

Open the dashboard configuration file:

sudo nano /etc/wazuh-dashboard/opensearch_dashboards.yml

Add the following settings at the bottom of the file:

opensearch_security.auth.type: "basicauth"
opensearch_security.auth.anonymous_auth_enabled: true

Step 5: Restart Wazuh Dashboard

Restart the dashboard service to activate the "Log in as anonymous" option on the web interface:

sudo systemctl restart wazuh-dashboard

When navigating to https://<YOUR-SERVER-IP>, the login page will now present a working "Log in as anonymous" button.

*******************************************************************

Troubleshooting Wazuh Timeouts

Fixing Systemd Limits & "Dashboard Not Ready" Errors

If you are deploying Wazuh on a virtual machine with constrained resources, you might encounter a frustrating loop where the Wazuh Manager refuses to start due to a systemd timeout. To compound the issue, once the manager is finally running, the Wazuh Dashboard might stall indefinitely with a "Server is not ready yet" message.

This guide walks through diagnosing these issues, clearing locked processes, permanently increasing the systemd timeout limit, and getting your web interface back online.

Phase 1: Diagnosing the Manager Timeout

The issue typically begins when trying to start the manager service:

sudo systemctl start wazuh-manager

If your VM lacks the CPU or RAM to load all internal modules within systemd's default 45-second window, it terminates the process abruptly, outputting:

Job for wazuh-manager.service failed because a timeout was exceeded.

Step 1: Clean Up Orphaned Processes

Systemd's abrupt termination leaves "sleeping" background processes behind. Clear them out to ensure a clean slate for the next attempt:

sudo pkill -f wazuh

Step 2: Remove the Startup Lock Directory

Because the startup process was killed prematurely, Wazuh didn't have a chance to delete its lock directory. It will assume another instance is still booting. Remove this directory manually (note the -rf flag, as it is a directory, not a file):

sudo rm -rf /var/ossec/var/start-script-lock

Step 3: Manually Start the Manager

Run the control script directly. This bypasses the systemd timer completely and proves whether your configuration is healthy or if there is a syntax error:

sudo /var/ossec/bin/wazuh-control start

If this command successfully initializes the modules and prints "Completed," your VM simply needs more time to boot than systemd allows.

Phase 2: Applying the Permanent Systemd Fix

Now we need to override systemd's strict timeout limit for this specific service so it survives future reboots.

Step 1: Create an Override Configuration

Increase the timeout threshold to 5 minutes (300 seconds):

sudo mkdir -p /etc/systemd/system/wazuh-manager.service.d
echo -e "[Service]\nTimeoutStartSec=300" | sudo tee /etc/systemd/system/wazuh-manager.service.d/override.conf

Step 2: Reload and Hand Control Back

Apply the new rules and restart the service via systemctl to ensure it adopts the running processes safely:

sudo systemctl daemon-reload
sudo systemctl restart wazuh-manager
sudo systemctl status wazuh-manager

Phase 3: Fixing the Dashboard "Not Ready" Error

Once the manager is active, you may try accessing the web interface only to see the message: "Wazuh dashboard server is not ready yet."

If you check the live dashboard logs (sudo journalctl -u wazuh-dashboard -f), you will likely see a repeating error:

[ConnectionError]: connect ECONNREFUSED 127.0.0.1:9200

The Solution: Start the Wazuh Indexer

This connection error means the dashboard cannot reach the backend database. This happens when the wazuh-indexer service is inactive or has crashed during boot.

sudo systemctl start wazuh-indexer
sudo systemctl status wazuh-indexer

Once the indexer reports as active (running), wait 60 to 90 seconds. The dashboard will automatically detect the active database connection, resolve the error loop, and bring you directly to the login screen. No further dashboard restarts are required!

*******************************************************************

How to Fix "Wazuh Dashboard Server Is Not Ready Yet" Error

A step-by-step diagnostic and recovery guide for resolving backend indexer connectivity and startup timeouts in Wazuh.

Summary: The "Wazuh dashboard server is not ready yet" error occurs when the web frontend fails to establish an active HTTPS connection with the wazuh-indexer database backend on port 9200. This guide covers how to clear resource locks, restart services, and verify backend health.

Step 1: Check System Resource Limits

The Wazuh Indexer uses OpenSearch and requires sufficient disk space and system memory to allocate its Java heap. If storage exceeds critical thresholds or available RAM drops too low, the indexer will silently fail or enter a read-only state.

# Check available disk space on /var
df -h /var

# Check total available RAM
free -h

Ensure disk usage on /var is well below 90% and that at least 2–4 GB of free RAM is available for Java execution.

Step 2: Restart and Verify the Wazuh Indexer

If the backend database service stopped or timed out during boot, trigger a fresh service restart and verify its status.

# Restart the Indexer backend
sudo systemctl restart wazuh-indexer

# Inspect service status
sudo systemctl status wazuh-indexer --no-pager

Allow 60 to 90 seconds for the JVM heap memory to initialize, then test the local API socket directly:

curl -k https://127.0.0.1:9200

A healthy response returns a JSON block showing "cluster_name": "wazuh-cluster".

Step 3: Sync Security Configurations (If Unauthorized)

If curl returns a 401 Unauthorized or 403 Forbidden error after recent configuration changes, force the security settings into the cluster database using the bundled administration tool:

sudo OPENSEARCH_JAVA_HOME=/usr/share/wazuh-indexer/jdk /usr/share/wazuh-indexer/plugins/opensearch-security/tools/securityadmin.sh \
  -cd /etc/wazuh-indexer/opensearch-security \
  -nhnv \
  -cacert /etc/wazuh-indexer/certs/root-ca.pem \
  -cert /etc/wazuh-indexer/certs/admin.pem \
  -key /etc/wazuh-indexer/certs/admin-key.pem \
  -p 9200

Confirm the terminal output finishes with Done with success and ERRORS: 0.

Step 4: Reload Daemons and Restart Dashboard

Once the indexer service is running and verified on port 9200, reload system units and restart the dashboard frontend to clear connection error caches.

# Reload systemd manager configuration
sudo systemctl daemon-reload

# Restart the Wazuh Dashboard service
sudo systemctl restart wazuh-dashboard

# Check the Dashboard status
sudo systemctl status wazuh-dashboard --no-pager

Step 5: Verification

Wait 30 seconds after restarting the dashboard, then refresh your web browser at https://<YOUR_SERVER_IP>. The login screen or default home dashboard will load cleanly once the API loop initializes.

*******************************************************************

How to Monitor Docker Containers with Wazuh

A step-by-step guide to configuring the native Wazuh Docker Listener module for real-time container tracking and event logging.

Overview: Wazuh uses a built-in docker-listener wodle to monitor container lifecycle events (start, stop, pause, pull). This configuration works for both a standalone Wazuh Agent and a local Wazuh Manager host listening to /var/run/docker.sock.

Step 1: Install Python Docker SDK

The Docker listener module requires the Python Docker library to interact directly with the local Docker API socket.

# Ubuntu / Debian
sudo apt update && sudo apt install python3-pip python3-docker -y

# RHEL / AlmaLinux / CentOS
sudo yum install python3-pip -y
sudo pip3 install docker

Step 2: Grant Socket Permissions

Ensure the Wazuh service account holds sufficient read and write permissions to communicate across the Docker Unix socket.

# Add the wazuh system user to the docker group
sudo usermod -aG docker wazuh

Step 3: Enable the Docker Listener Module

Open the main configuration file on your target host:

sudo nano /var/ossec/etc/ossec.conf

Add the <wodle name="docker-listener"> block inside the main <ossec_config> tag:

<wodle name="docker-listener">
  <disabled>no</disabled>
  <interval>10m</interval>
  <attempts>5</attempts>
  <run_on_start>yes</run_on_start>
</wodle>

Step 4: Restart Service & Verify Logs

Restart the active daemon (Manager or Agent) to initialize the module:

# For Wazuh Manager setup
sudo systemctl restart wazuh-manager

# For Wazuh Agent setup
sudo systemctl restart wazuh-agent

Stream the log file to confirm the background process initialized successfully:

sudo tail -n 30 /var/ossec/logs/ossec.log | grep -i docker

Step 5: Testing & Dashboard Verification

Run a test container on the host machine to generate an event:
```
docker run --rm hello-world
```
Open your Wazuh Dashboard web interface.
Navigate to Modules > Docker or query Explore > Discover using the rule filter:
```
rule.groups: docker
```

*******************************************************************

Wazuh Dashboard

How to Install Wazuh Security Platform on a Linux Server (Clean Installation)