Modern Linux security focuses on minimizing privileges wherever possible. Instead of granting applications unrestricted root access, organizations increasingly follow the principle of least privilege, allowing software to run with only the permissions required to perform its intended tasks.

This significantly reduces the potential impact of vulnerabilities, compromised accounts, or configuration mistakes.

The Wazuh Agent Non Root approach follows this security philosophy by configuring the Wazuh agent to run partially or entirely under a non-root user wherever practical.

While some Wazuh components still require elevated privileges to monitor protected operating system resources, many environments can reduce root access by carefully assigning Linux capabilities, file permissions, service configurations, and sudo rules instead of granting full administrative rights.

There are several reasons organizations choose to avoid running agents as root:

Reduce the impact of a compromised endpoint
Meet internal security policies
Satisfy regulatory compliance requirements
Improve defense-in-depth across Linux servers
Limit privilege escalation opportunities for attackers

A properly configured least-privilege deployment can provide strong endpoint visibility while reducing unnecessary system permissions. However, administrators must also understand the tradeoffs, since restricting privileges may prevent certain Wazuh modules from collecting specific security data.

In this guide, you’ll learn:

What Wazuh Agent Non Root actually means
Which Wazuh components require elevated permissions
How Linux capabilities affect Wazuh functionality
Which monitoring features continue working without root
Common limitations and troubleshooting tips
Best practices for deploying least-privilege Wazuh agents in production

What Is Wazuh Agent Non Root?

The Wazuh agent is a lightweight endpoint monitoring service installed on Linux, Windows, and macOS systems.

It collects security events, performs integrity monitoring, gathers system inventory information, executes Security Configuration Assessment (SCA) policies, detects vulnerabilities, and forwards collected telemetry to the Wazuh manager.

Internally, the Linux agent consists of several modules that perform different monitoring tasks, including:

Log collection
File Integrity Monitoring (FIM)
Rootcheck
Security Configuration Assessment (SCA)
Syscollector
Vulnerability Detection support
Active Response
Command execution
Secure communication with the manager

By default, the Linux agent runs as root because many of these components require unrestricted access to protected operating system resources.

Examples include:

Reading privileged log files in /var/log
Monitoring system directories
Inspecting kernel information
Reading /proc
Executing security commands
Accessing audit logs
Performing Active Response actions such as blocking IP addresses

Some administrators assume that every part of the Wazuh agent requires full root access, but that is not entirely accurate.

Certain modules can operate successfully under a dedicated service account with carefully assigned permissions.

Others, however, cannot function correctly without elevated privileges because the Linux kernel protects the resources they monitor.

Running the Wazuh Agent Non Root therefore does not necessarily mean the entire agent executes without any privileged operations.

Instead, it generally refers to reducing root usage wherever technically feasible while selectively granting only the capabilities necessary for specific monitoring tasks.

For example, a least-privilege deployment may:

Run the main service under a dedicated wazuh user
Assign Linux capabilities instead of full root privileges
Grant read access to selected log files
Use ACLs for monitored directories
Restrict sudo access to only approved commands
Disable modules that require unrestricted root access

This model closely aligns with modern Linux hardening recommendations from organizations such as the Center for Internet Security (CIS) and the National Institute of Standards and Technology (NIST), both of which recommend minimizing privileged processes whenever operationally possible.

Why the Agent Normally Runs as Root

Several Wazuh modules require privileged access because Linux protects security-sensitive resources from ordinary users.

Examples include:

Monitoring /etc, /boot, and system binaries
Reading auditd logs
Executing Rootcheck scans
Collecting kernel information
Running Active Response scripts
Accessing restricted system configuration files
Performing low-level inventory collection

Without sufficient privileges, these modules may generate permission errors or produce incomplete monitoring data.

Which Agent Components Require Elevated Privileges

Not every Wazuh module has identical permission requirements.

Components that commonly need elevated privileges include:

Rootcheck
Active Response
Security Configuration Assessment (some checks)
Audit log monitoring
File Integrity Monitoring on protected directories
Command modules executing privileged commands

Modules with fewer privilege requirements often include:

Monitoring application logs with appropriate read permissions
Collecting user-owned files
Forwarding logs
Network communication with the Wazuh manager

The exact requirements depend on your Linux distribution, kernel security policies, SELinux/AppArmor configuration, and the directories or resources being monitored.

What Changes When Running With Non-Root Permissions

Moving to a non-root deployment changes how the agent interacts with the operating system.

Administrators typically must:

Configure Linux file permissions
Add ACLs where necessary
Adjust systemd service definitions
Assign Linux capabilities
Review SELinux or AppArmor policies
Test each enabled module individually

Some monitoring functionality may remain unchanged, while other modules may require additional configuration or become unavailable altogether.

Security engineer Dan Walsh, a long-time SELinux expert and Red Hat Distinguished Engineer, has consistently emphasized that reducing process privileges and using Linux security controls such as capabilities and mandatory access control significantly lowers the potential impact of compromised services.

Applying the same principle to endpoint monitoring agents helps strengthen overall system security by limiting what a successful attacker could do if an agent process were exploited.

Supported Use Cases and Limitations

A non-root Wazuh deployment is generally well suited for environments where:

Only application logs need monitoring
File monitoring targets user-owned directories
Organizations enforce strict least-privilege policies
Compliance frameworks discourage unnecessary root services
Containers run with restricted privileges

However, it may be less appropriate when:

Root-level file monitoring is required
Active Response must modify firewall rules
Rootcheck scans are essential
Full Security Configuration Assessment coverage is required
Audit subsystem monitoring is mandatory

Before deploying in production, test each enabled Wazuh module to ensure the reduced permission model still provides the visibility your security program requires.

Related Guides:

Benefits of Running the Wazuh Agent Without Root Privileges

Reducing unnecessary root access has become one of the most widely accepted security practices across Linux administration, cloud infrastructure, and enterprise cybersecurity.

Running the Wazuh Agent Non Root aligns with this philosophy by minimizing the privileges granted to endpoint monitoring software while maintaining as much functionality as possible.

Although not every Wazuh deployment can completely eliminate root access, reducing privileges wherever feasible offers several important security and operational benefits.

Improved Security

Every process running as root becomes a high-value target for attackers.

If a vulnerability allows arbitrary code execution inside a privileged service, the attacker may immediately gain complete control of the host.

Running the Wazuh agent with restricted permissions helps contain potential damage by limiting what an exploited process can access or modify.

This layered defense complements Linux security mechanisms such as:

Linux capabilities
SELinux
AppArmor
Namespaces
Mandatory Access Control (MAC)

Reduced Attack Surface

The principle of least privilege reduces the number of privileged processes running on each endpoint.

Instead of granting unrestricted root access, administrators can provide only the permissions required for specific monitoring tasks, such as:

Reading selected log files
Monitoring approved directories
Communicating with the Wazuh manager
Executing predefined commands

This significantly decreases opportunities for privilege escalation.

Better Compliance

Many cybersecurity frameworks explicitly recommend minimizing privileged accounts and services.

Deploying Wazuh using non-root permissions can help support organizational compliance efforts by demonstrating that administrative privileges are granted only when operationally necessary.

PCI DSS

The PCI DSS v4.0 standard emphasizes restricting access based on business need and applying least-privilege principles to systems that process payment card data.

HIPAA

The HIPAA Security Rule requires organizations to implement appropriate administrative, technical, and physical safeguards to protect electronic protected health information (ePHI). Restricting privileged access supports these safeguards by reducing unnecessary administrative permissions.

ISO 27001

ISO/IEC 27001 promotes access control policies that ensure users and services receive only the permissions required to perform authorized tasks.

Using a non-root deployment aligns well with these access control objectives.

CIS Benchmarks

The CIS Benchmarks for Linux systems consistently recommend limiting root usage, assigning only necessary permissions, and hardening system services against privilege escalation.

Following these recommendations helps improve the overall security posture of Linux endpoints monitored by Wazuh.

Principle of Least Privilege

The Principle of Least Privilege (PoLP) is one of the most fundamental concepts in cybersecurity.

Rather than asking whether a service can run as root, administrators should ask whether it must.

Applying PoLP to Wazuh means:

Eliminating unnecessary root permissions
Assigning only required capabilities
Reviewing permissions regularly
Disabling unused modules
Restricting command execution

These practices reduce both accidental misconfigurations and the impact of successful attacks.

Safer Multi-Tenant Systems

In environments hosting multiple applications, users, or customers, reducing service privileges becomes even more important.

If one application or monitoring process is compromised, privilege separation helps prevent attackers from moving laterally across the system or affecting other tenants.

This approach is particularly valuable for:

Shared Linux servers
University environments
Managed hosting platforms
Kubernetes worker nodes
Cloud virtual machines

Easier Security Audits

Least-privilege deployments simplify internal and external security reviews.

Auditors typically verify:

Which services run as root
Why elevated privileges are required
Whether permissions are documented
Whether privilege escalation paths exist
Whether administrative access follows organizational policy

A well-documented non-root Wazuh deployment makes these reviews significantly easier by clearly demonstrating that elevated permissions are limited to only those functions that genuinely require them.

Related Guides:

Prerequisites

Before configuring the Wazuh Agent Non Root deployment, verify that your Linux system and Wazuh installation meet the necessary requirements.

While the process is straightforward, understanding your environment beforehand helps prevent permission-related issues and avoids breaking existing monitoring capabilities.

Supported Linux Distributions

Running the Wazuh agent with reduced privileges is possible on most modern Linux distributions that support systemd, Linux capabilities, and standard POSIX permissions.

Commonly supported distributions include:

Ubuntu 20.04, 22.04, and later
Debian 11 and later
Red Hat Enterprise Linux (RHEL) 8 and later
Rocky Linux
AlmaLinux
CentOS Stream
Oracle Linux
SUSE Linux Enterprise Server (SLES)
Amazon Linux 2 and Amazon Linux 2023

Although the overall approach is similar across distributions, some permission models differ depending on:

SELinux policies
AppArmor profiles
Default filesystem permissions
Package locations
Service management configuration

Always validate your configuration in a non-production environment before deploying to critical systems.

Wazuh Version Requirements

Most modern versions of the Wazuh agent support running under customized service accounts with appropriate permissions.

For best compatibility, use:

Wazuh 4.x or later
A fully updated Linux distribution
Matching agent and manager versions whenever possible

Running mismatched versions may introduce unexpected behavior, unsupported configuration options, or communication issues.

Related Guide: How to Upgrade a Wazuh Agent

Administrative Access for Initial Setup

Even though the goal is to reduce or eliminate continuous root usage, initial configuration still requires administrative privileges.

You’ll typically need root or sudo access to:

Create users and groups
Modify file ownership
Configure systemd services
Assign Linux capabilities
Adjust ACLs
Restart services
Modify SELinux or AppArmor policies if necessary

After configuration is complete, the agent itself can often operate with significantly fewer privileges.

Understanding Linux Users and Groups

Before modifying the Wazuh service account, it’s important to understand how Linux permissions work.

Key concepts include:

Users own files and execute processes.
Groups allow multiple users to share access to resources.
File permissions determine who can read, write, or execute files.
ACLs (Access Control Lists) provide more granular permission control than traditional UNIX permissions.
Linux capabilities allow specific privileged operations without granting full root access.

A successful non-root deployment relies on combining these mechanisms instead of simply removing root privileges.

Existing Wazuh Manager Connection

Your Linux agent should already be enrolled and communicating successfully with the Wazuh manager before changing its execution privileges.

Verify that:

The agent appears in the Wazuh dashboard.
The agent status is Active.
Logs are arriving normally.
Configuration synchronization is working (if centralized configuration is used).

Making privilege changes before confirming normal operation can complicate troubleshooting.

Related Guides:

Required Packages and Tools

Depending on your Linux distribution, you’ll likely use several standard administration tools during the configuration process.

Common utilities include:

systemctl
useradd
groupadd
usermod
chown
chmod
setfacl
getfacl
setcap
getcap
sudo
journalctl

Some distributions may require installing additional packages such as:

acl
libcap
policycoreutils (SELinux systems)

These utilities allow you to safely assign only the permissions the Wazuh agent actually requires.

Understanding Which Wazuh Features Require Root

One of the biggest misconceptions about the Wazuh Agent Non Root model is that every agent feature requires unrestricted root access.

In reality, privilege requirements vary considerably depending on the module and the operating system resources it accesses.

Understanding these requirements helps you decide which features can safely run with reduced permissions and which may require elevated privileges.

Log Collection

Log collection often works well under a non-root account, provided the agent has permission to read the monitored log files.

Examples include:

Application logs
Web server logs
User-owned log directories
Custom application logging

However, system logs such as:

/var/log/auth.log
/var/log/secure
/var/log/messages
/var/log/audit/audit.log

typically require additional permissions or group membership.

Rather than granting root access, many administrators add the Wazuh service account to appropriate log-reading groups or configure ACLs for specific log files.

File Integrity Monitoring (FIM)

File Integrity Monitoring can operate without root only if the monitored files are accessible to the Wazuh service account.

Monitoring directories such as:

User home directories
Application folders
Shared storage

usually presents few issues.

However, monitoring sensitive system paths like:

/etc
/boot
/usr/bin
/lib
/root

often requires elevated permissions or carefully configured ACLs.

Vulnerability Detection

The agent contributes inventory information used by the Wazuh manager’s vulnerability detection engine.

Collecting complete package inventories may require access to protected system resources depending on the Linux distribution.

In restricted environments, vulnerability detection may still function but produce less complete results if inventory collection is limited.

Syscollector

Syscollector gathers information such as:

Installed packages
Running processes
Network interfaces
Open ports
Hardware inventory
Operating system details

Most of this information can be collected without full root access, although certain kernel and process information may be restricted.

Modern Linux kernels increasingly limit access to sensitive process information for non-privileged users.

Rootcheck

Rootcheck is one of the modules most dependent on elevated privileges.

It performs security checks such as:

Rootkit detection
Hidden file discovery
Suspicious kernel object detection
System integrity verification
Privileged configuration inspection

Many of these operations require unrestricted access to protected areas of the operating system.

Running Rootcheck without root may reduce detection coverage.

Active Response

Active Response almost always requires elevated privileges.

Examples include:

Blocking IP addresses
Updating firewall rules
Killing malicious processes
Disabling user accounts
Executing remediation scripts

Since these actions modify system state, root or carefully delegated sudo permissions are generally required.

Related Guide: How to Configure Wazuh Active Response

Command Monitoring

The command module executes administrator-defined commands and collects their output.

Whether root is required depends entirely on the command itself.

For example:

Reading user-owned files may require no special privileges.
Checking kernel parameters may require elevated permissions.
Querying firewall rules typically requires administrative rights.

When possible, grant access only to specific commands using tightly scoped sudo rules rather than unrestricted root access.

SCA (Security Configuration Assessment)

Security Configuration Assessment (SCA) evaluates a system against security baselines such as CIS Benchmarks.

Many checks inspect:

System configuration files
Package settings
Kernel parameters
Authentication policies
File permissions

Some checks function without root, while others require privileged access to protected configuration files.

Limiting permissions may therefore reduce overall benchmark coverage.

Windows Event Collection (Not Applicable)

Windows Event Collection is not relevant to Linux-based Wazuh Agent Non Root deployments.

Also, windows agents use an entirely different permission model based on Windows services, security descriptors, and local privileges rather than Linux users, groups, and capabilities.

Creating a Dedicated Wazuh User

One of the most important steps in a least-privilege deployment is creating a dedicated service account for the Wazuh agent.

Instead of running under the root account, the agent can execute using a restricted user that has only the permissions required for its assigned monitoring tasks.

This improves security by separating the Wazuh service from other administrative accounts and making permission management easier.

Creating the User

Create a dedicated system user specifically for the Wazuh agent.

Example:

sudo useradd --system wazuh

The --system option creates a service account intended for background processes rather than interactive users.

Verify the account:

id wazuh

Creating the Group

For easier permission management, create a dedicated group for the Wazuh service if one does not already exist.

sudo groupadd --system wazuh

Then associate the user with the group:

sudo usermod -g wazuh wazuh

Additional group memberships can later be added if the agent requires access to protected log files or application directories.

Assigning Home Directory

Although many service accounts do not require a home directory, assigning one can simplify log storage, temporary files, or custom scripts in certain environments.

Example:

sudo usermod -d /var/ossec wazuh

Verify the assigned directory:

getent passwd wazuh

Ensure the directory ownership matches the service account:

sudo chown -R wazuh:wazuh /var/ossec

Preventing Interactive Login

Since the Wazuh account is intended only for running the agent, interactive logins should be disabled.

Configure a non-login shell:

sudo usermod -s /usr/sbin/nologin wazuh

Some distributions instead use:

sudo usermod -s /sbin/nologin wazuh

This prevents users from logging into the account while still allowing systemd to execute the service.

Verifying User Creation

Before modifying the Wazuh service configuration, verify that the account was created correctly.

Useful commands include:

id wazuh

getent passwd wazuh

groups wazuh

ls -ld /var/ossec

Confirm:

The user exists.
The group exists.
The home directory is correct.
The login shell is disabled.
Ownership of required directories is properly configured.

Completing these checks provides a solid foundation before assigning capabilities, adjusting file permissions, and configuring the Wazuh service to run with reduced privileges.

Configuring File Ownership and Permissions

One of the most important aspects of a Wazuh Agent Non Root deployment is ensuring that the service account has access only to the files and directories it actually needs.

Instead of granting unrestricted root access, you’ll explicitly assign ownership, permissions, or Access Control Lists (ACLs) to the Wazuh user.

Always review permissions carefully before applying them in production. Granting overly broad access defeats the purpose of a least-privilege deployment.

Wazuh Installation Directory

The Wazuh agent is typically installed under:

/var/ossec

If you’re using a dedicated wazuh user, ensure the installation directory is owned by the appropriate user and group where possible.

Example:

sudo chown -R wazuh:wazuh /var/ossec

Verify ownership:

ls -ld /var/ossec

Be cautious when recursively changing ownership. Some files may intentionally remain owned by root for security reasons, depending on your deployment and package manager.

Log Files

The Wazuh agent must be able to read any log files you configure in ossec.conf.

Examples include:

/var/log/syslog
/var/log/messages
/var/log/auth.log
Application-specific log files

Rather than making these files world-readable, consider using:

Group membership
ACLs
Read-only permissions for the Wazuh service account

Example using ACLs:

sudo setfacl -m u:wazuh:r /var/log/auth.log

Verify the ACL:

getfacl /var/log/auth.log

Using ACLs provides more granular control than modifying traditional UNIX file permissions.

Queue Directories

The agent stores internal communication data, event queues, and runtime information within its queue directories.

Examples include:

/var/ossec/queue

The Wazuh service account typically requires:

Read access
Write access
Execute permission on directories

Verify permissions after any ownership changes to ensure the agent can continue processing events.

Temporary Files

Some Wazuh modules create temporary working files during scans or data collection.

Temporary directories should:

Be writable only by the service account.
Prevent unauthorized modification by other users.
Be cleaned automatically when appropriate.

Avoid assigning global write permissions unless absolutely necessary.

Certificates and Keys

Secure communication between the Wazuh agent and manager relies on cryptographic certificates and authentication keys.

Examples include:

Agent keys
TLS certificates
Private keys

These files should remain tightly protected.

Recommended permissions include:

Owner: root (or designated administrator)
Group: wazuh (only if required)
Permissions: 600 or 640

Private keys should never be readable by unauthorized users.

Configuration Files

Important configuration files include:

/var/ossec/etc/ossec.conf

and related XML configuration files.

These should generally be:

Readable by the Wazuh service account
Writable only by administrators
Protected from accidental modification

Restrict write permissions to prevent unauthorized configuration changes.

Related Guides:

Restricting Sensitive Files

Not every system file should be accessible to the Wazuh service account.

Avoid granting access to:

/etc/shadow
Root SSH keys
Private administrator credentials
Database passwords
Application secrets
Other users’ home directories

When additional access is required, grant permissions only to the specific files needed for monitoring rather than entire directories.

Security experts at the Open Worldwide Application Security Project (OWASP) recommend minimizing file permissions and limiting service accounts to only the resources required for normal operation, reducing the impact of compromised processes.

Configuring Linux Capabilities Instead of Root

Linux capabilities provide a more granular alternative to full root privileges.

Instead of granting a process unrestricted administrative access, capabilities allow individual privileged operations to be assigned independently.

This approach is central to many Wazuh Agent Non Root deployments because it enables specific monitoring functions while significantly reducing overall system privileges.

What Linux Capabilities Are

Traditionally, Linux processes either ran as:

Root (full privileges)
Non-root (limited privileges)

Linux capabilities divide root privileges into individual permissions that can be granted separately.

Examples include:

Reading protected files
Opening raw network sockets
Inspecting processes
Loading kernel modules
Changing network settings

Rather than giving the Wazuh agent unrestricted administrative access, you can assign only the capabilities required for your monitoring requirements.

The Linux kernel documentation describes capabilities as a mechanism for breaking down the traditional all-powerful root privilege into distinct units that can be independently enabled or disabled.

Using setcap

The setcap utility assigns capabilities directly to executable files.

Example syntax:

sudo setcap capability_name=ep /path/to/executable

For example:

sudo setcap cap_dac_read_search=ep /var/ossec/bin/wazuh-agentd

The exact executable and capability set depend on your deployment and should be thoroughly tested before use.

After assigning capabilities, verify that the agent continues to collect the expected security data.

Common Capabilities Used

Different Wazuh modules may benefit from different Linux capabilities depending on the resources being monitored.

Only assign capabilities that are absolutely necessary.

CAP_DAC_READ_SEARCH

CAP_DAC_READ_SEARCH allows a process to bypass certain file read permission checks.

This capability is often useful for:

Reading protected log files
Monitoring restricted directories
Accessing configuration files without full root privileges

It is one of the most commonly considered capabilities for least-privilege monitoring agents.

CAP_NET_RAW

CAP_NET_RAW allows processes to create raw network sockets.

Although many Wazuh deployments do not require it, certain network-related monitoring or integrations may depend on this capability.

If unused, leave it disabled.

CAP_SYS_PTRACE

CAP_SYS_PTRACE permits a process to inspect or trace other processes.

Some advanced monitoring or forensic workflows may require it, but it significantly increases the process’s visibility into the operating system.

Grant this capability only after evaluating the associated security implications.

CAP_SYSLOG (where applicable)

On some Linux systems, CAP_SYSLOG allows access to privileged kernel logging interfaces.

Modern distributions often restrict or replace this behavior, and availability varies by kernel version.

Many deployments do not require this capability.

Verifying Assigned Capabilities

After assigning capabilities, verify them using:

getcap /var/ossec/bin/wazuh-agentd

You can also inspect all Wazuh binaries:

getcap -r /var/ossec

Review the output to ensure that only the intended capabilities are assigned.

Removing Unnecessary Capabilities

If capabilities are no longer required, remove them immediately.

Example:

sudo setcap -r /var/ossec/bin/wazuh-agentd

Regularly auditing assigned capabilities is an important security practice.

As security researcher and Linux kernel developer Andrew G. Morgan, who helped design Linux capabilities, has noted, capabilities are most effective when administrators grant only the minimum privileges necessary rather than attempting to replicate full root access through numerous capability assignments.

Configuring the Wazuh Agent to Run as a Non-Root User

Once file permissions and Linux capabilities have been configured, the next step is modifying the Wazuh service so that it executes using the dedicated service account instead of the root user.

Because package layouts may vary between Linux distributions and Wazuh versions, always verify service file locations before making changes.

Updating the Service Configuration

Most Linux distributions manage the Wazuh agent using systemd.

Locate the service definition:

/etc/systemd/system/

/usr/lib/systemd/system/

Some distributions place package-managed service files in different locations.

Avoid modifying vendor-supplied files directly whenever possible. Instead, use a systemd override file so your changes survive package upgrades.

Editing systemd Service Files

Create an override configuration:

sudo systemctl edit wazuh-agent

This opens a drop-in configuration file that supplements the original service definition.

Using overrides follows systemd best practices and reduces maintenance during future Wazuh updates.

Setting User and Group

Within the override file, configure the service account:

[Service]
User=wazuh
Group=wazuh

Depending on your deployment, additional directives such as:

SupplementaryGroups=
ReadWritePaths=
ReadOnlyPaths=

may also be appropriate to further restrict filesystem access.

Carefully test these settings, as overly restrictive configurations can prevent the agent from accessing required resources.

Reloading systemd

After saving the override file, reload the systemd configuration:

sudo systemctl daemon-reload

This instructs systemd to recognize the updated service configuration.

Restarting the Agent

Restart the Wazuh agent:

sudo systemctl restart wazuh-agent

Then verify that the service starts successfully:

sudo systemctl status wazuh-agent

Also review the agent logs for any permission-related errors.

Confirming the Running User

Finally, verify that the agent is running under the dedicated service account rather than root.

Useful commands include:

ps -o user,group,comm -C wazuh-agentd

ps aux | grep wazuh

You can also inspect the systemd process information:

systemctl status wazuh-agent

Confirm that:

The process owner is the wazuh user.
The correct group is assigned.
Required monitoring features continue functioning.
No permission-denied errors appear in the logs.

Successfully completing these checks confirms that your Wazuh Agent Non Root deployment is operating with a reduced privilege model while maintaining the monitoring capabilities your environment requires.

Allowing Access to Required Log Files

For a Wazuh Agent Non Root deployment to function correctly, the service account must be able to read every log file configured in ossec.conf.

The safest approach is to grant access only to the specific files or directories that require monitoring instead of providing unrestricted root privileges.

Depending on your Linux distribution, this can be accomplished using:

Linux groups
Access Control Lists (ACLs)
Read-only bind mounts
Carefully scoped file permissions

Avoid making sensitive log files world-readable, as this introduces unnecessary security risks.

Linux Authentication Logs

Authentication logs often contain valuable security events, including:

SSH login attempts
Failed authentication
Privilege escalation
sudo usage
PAM events

Common log locations include:

/var/log/auth.log

/var/log/secure

Because these logs are typically readable only by root or privileged groups, consider using ACLs instead of changing global permissions.

Example:

sudo setfacl -m u:wazuh:r /var/log/auth.log

Verify access:

sudo -u wazuh cat /var/log/auth.log

Syslog Files

General system logs may reside in:

/var/log/syslog
/var/log/messages
/var/log/kern.log

The required permissions depend on the Linux distribution and logging service (rsyslog, syslog-ng, journald, etc.).

Whenever possible:

Use read-only permissions.
Assign the Wazuh user to an appropriate log-reading group.
Avoid modifying default system permissions.

Application Logs

Many business applications generate logs in locations such as:

/opt/application/logs

/var/log/application

These directories are often easier to monitor because they are owned by the application rather than the operating system.

Grant the Wazuh service account read access only to the required application log directories.

Web Server Logs

Common web server log locations include:

Apache:

/var/log/apache2/

Nginx:

/var/log/nginx/

Typical monitored files include:

access.log
error.log

Many Linux distributions already assign these logs to dedicated groups, allowing administrators to grant read access without requiring root.

Related Guide: How to Monitor Apache Logs with Wazuh

Docker Logs

Docker containers commonly store logs under:

/var/lib/docker/containers/

These directories are usually accessible only by root.

Possible approaches include:

Adding the Wazuh user to the docker group (only after evaluating the security implications)
Using ACLs
Forwarding container logs to syslog
Using centralized logging

Be aware that membership in the Docker group effectively grants elevated privileges on many systems, so it should be used cautiously.

Kubernetes Logs

In Kubernetes environments, logs are commonly located in:

/var/log/containers/

and

/var/log/pods/

Permissions vary depending on:

Container runtime
Distribution
Security policies

Many organizations choose to collect Kubernetes logs through centralized logging solutions rather than granting extensive filesystem access to individual agents.

Related Guide: How to Monitor Kubernetes Using Wazuh

Custom Log Directories

Many organizations maintain custom logging locations for internally developed applications.

Examples include:

/opt/company/logs

/data/application/logs

When monitoring these directories:

Grant only read access.
Avoid recursive write permissions.
Regularly audit permissions.
Remove access to retired applications.

Handling File Integrity Monitoring Permissions

File Integrity Monitoring (FIM) is one of Wazuh’s most valuable security capabilities, but it also has some of the highest permission requirements.

Successfully implementing Wazuh Agent Non Root often involves carefully selecting which files and directories the agent can monitor.

Monitoring System Files

System directories frequently monitored by Wazuh include:

/etc
/boot
/usr/bin
/usr/sbin
/lib
/bin

These locations are protected because they contain critical operating system files.

Instead of granting unrestricted root access, administrators can use ACLs to provide read-only access where appropriate.

Some highly sensitive files may still require root privileges and cannot be monitored effectively under a fully non-root configuration.

Monitoring Application Directories

Application directories are generally easier to monitor because organizations control their ownership and permissions.

Examples include:

Web applications
Internal software
Configuration repositories
Shared application storage

These directories often require only:

Read permission
Directory traversal (x) permission

This makes them ideal candidates for least-privilege monitoring.

Read-Only Access Requirements

In most cases, File Integrity Monitoring only needs to read files and calculate hashes.

Typical requirements include:

Read permission on monitored files
Execute permission on parent directories
Access to file metadata

Write access is generally unnecessary and should not be granted unless specifically required.

Permission Best Practices

To maintain strong security while enabling FIM:

Monitor only necessary directories.
Use ACLs instead of broad permission changes.
Avoid world-readable system files.
Regularly review monitored paths.
Remove obsolete monitoring rules.
Test FIM after permission changes.

Related Guides:

Managing Active Response with Non-Root Agents

Active Response presents one of the biggest challenges for Wazuh Agent Non Root deployments because it performs actions that intentionally modify the operating system.

Unlike passive monitoring modules, Active Response may need to:

Block malicious IP addresses
Kill running processes
Disable user accounts
Update firewall rules
Execute remediation scripts

These operations generally require elevated privileges.

Why Active Response Is Different

Most Wazuh modules simply observe system activity.

Active Response, however, changes system state.

As a result, running it under a fully non-root account is usually impractical without carefully delegated administrative permissions.

Using sudo Securely

Rather than granting unrestricted root access, many administrators allow the Wazuh service account to execute only approved commands through sudo.

For example:

Restart a specific service
Update firewall rules
Execute a predefined remediation script

Avoid allowing unrestricted sudo access or shell execution.

Restricting Allowed Commands

Limit executable commands to exactly those required.

For example:

/usr/sbin/iptables
/usr/bin/firewall-cmd
/usr/bin/systemctl restart nginx
Approved internal response scripts

Do not allow wildcard command execution.

The narrower the rule, the smaller the attack surface.

Creating Minimal sudoers Rules

A carefully scoped sudoers entry might resemble:

wazuh ALL=(root) NOPASSWD: /usr/bin/firewall-cmd

wazuh ALL=(root) NOPASSWD: /opt/security/scripts/block_ip.sh

Always edit sudoers using:

sudo visudo

This performs syntax validation before saving changes and reduces the risk of configuration errors.

Sudo documentation: https://www.sudo.ws/docs/man/1.9.17/visudo.man/

Security Considerations

When delegating administrative commands:

Allow only absolute paths.
Never use wildcards unless absolutely necessary.
Review sudo rules regularly.
Log every privileged command.
Remove unused rules promptly.
Test each permitted command individually.

Security experts, including those behind the CIS Linux Benchmarks, consistently recommend restricting sudo privileges to the smallest possible set of administrative actions rather than granting unrestricted root access.

Related Guide: How to Configure Wazuh Active Response

Example Configuration

The following examples illustrate how the various pieces of a non-root deployment fit together.

Your exact configuration will vary depending on your Linux distribution, security policies, and the Wazuh modules you enable.

Example Directory Permissions

sudo chown -R wazuh:wazuh /var/ossec

sudo chmod 750 /var/ossec

sudo setfacl -m u:wazuh:r /var/log/auth.log

sudo setfacl -m u:wazuh:rx /etc

These commands demonstrate the principle of granting only the permissions necessary for monitoring.

Example systemd Override

[Service]
User=wazuh
Group=wazuh

Depending on your environment, you may also define:

SupplementaryGroups=
ReadOnlyPaths=
ReadWritePaths=
NoNewPrivileges=yes
ProtectSystem=

These additional hardening options can further reduce the service’s attack surface.

Example sudoers Configuration

wazuh ALL=(root) NOPASSWD: /usr/bin/firewall-cmd

This allows only the specified command to execute with elevated privileges.

Avoid broad rules such as:

wazuh ALL=(ALL) NOPASSWD: ALL

as they effectively eliminate the benefits of a least-privilege deployment.

Example Capability Assignment

sudo setcap cap_dac_read_search=ep /var/ossec/bin/wazuh-agentd

Always verify that assigned capabilities are limited to operational requirements.

Example Verification Commands

Useful validation commands include:

id wazuh

ps -o user,group,comm -C wazuh-agentd

systemctl status wazuh-agent

getcap -r /var/ossec

journalctl -u wazuh-agent

Running these commands after configuration changes helps confirm that the service is operating correctly under the intended security model.

Verifying the Configuration

After completing the configuration, verify that every major Wazuh component still functions correctly.

A successful Wazuh Agent Non Root deployment should reduce privileges without sacrificing the monitoring capabilities your environment depends on.

Check Running User

Confirm that the Wazuh processes are no longer running as root.

Example:

ps -o user,group,comm -C wazuh-agentd

The output should show the dedicated service account (for example, wazuh) as the process owner.

Verify Manager Connectivity

Ensure the agent continues communicating with the Wazuh manager.

Check:

Agent status in the Wazuh dashboard
Recent heartbeat activity
Registration status
Connection logs

If the agent disappears from the manager after privilege changes, review file permissions and service logs.

Confirm Log Collection

Generate a test log entry in one of the monitored log files and verify that it appears in the Wazuh dashboard.

If events do not arrive:

Check file permissions.
Review ACLs.
Confirm the configured log path in ossec.conf.
Inspect agent logs for permission errors.

Verify FIM Events

Modify a monitored file and confirm that Wazuh detects the change.

Typical tests include:

Editing a configuration file
Creating a temporary file
Changing file permissions

If no alert is generated, verify that the service account has sufficient read and directory traversal permissions.

Test Syscollector

Trigger a new Syscollector inventory scan and verify that inventory data such as installed packages, processes, and network interfaces continues to appear in the Wazuh dashboard.

If inventory is incomplete, compare the missing data with the permissions available to the non-root service account.

Test Active Response

If Active Response is enabled:

Trigger a test rule.
Verify that the expected remediation command executes.
Confirm that the command is permitted by your sudoers configuration.
Review both the Wazuh agent log and system logs for any permission-denied messages.

Review Agent Logs

Finally, inspect the Wazuh agent logs for warnings or permission-related failures.

Common locations include:

/var/ossec/logs/ossec.log

Look for messages indicating:

Permission denied
Operation not permitted
Unable to read file
Access denied
Capability missing

Addressing these messages early helps ensure that your least-privilege deployment remains both secure and fully operational over time.

Common Problems and Solutions

Configuring a Wazuh Agent Non Root deployment requires careful permission management.

Most issues occur because the agent no longer has unrestricted access to system resources that it previously accessed as root.

The key to troubleshooting is identifying which Wazuh module is failing, determining which resource it needs access to, and granting the smallest possible permission required.

Permission Denied Errors

Permission errors are the most common issue after switching the Wazuh agent from root to a dedicated service account.

Common messages include:

Permission denied
Operation not permitted
Unable to open file
Cannot access directory

Typical causes include:

Incorrect file ownership
Missing ACL permissions
Missing group membership
Incorrect systemd user configuration
Missing Linux capabilities

Start troubleshooting by identifying the affected file or directory:

ls -l /path/to/file

Check whether the Wazuh user can access the resource:

sudo -u wazuh ls -l /path/to/file

If access fails, grant only the required permission:

sudo setfacl -m u:wazuh:r /path/to/file

Avoid solving permission problems by using:

chmod 777

This creates unnecessary security risks and defeats the purpose of a least-privilege deployment.

Agent Cannot Read Log Files

If Wazuh stops collecting logs after switching to a non-root user, the agent likely lacks permission to read the configured log sources.

Common affected files include:

/var/log/auth.log
/var/log/secure
/var/log/syslog
/var/log/messages

Verify access:

sudo -u wazuh cat /var/log/auth.log

If access fails, solutions include:

Using ACLs

sudo setfacl -m u:wazuh:r /var/log/auth.log

Adding the User to a Log Group

Some Linux distributions provide groups such as:

adm
systemd-journal

Example:

sudo usermod -aG adm wazuh

Restart the agent afterward:

sudo systemctl restart wazuh-agent

Active Response Fails

Active Response commonly fails in non-root deployments because it performs privileged actions.

Examples:

Blocking firewall rules
Killing processes
Restarting services
Modifying system configuration

Typical errors:

Permission denied executing command
Operation not permitted
sudo: command not allowed

The solution is not to restore full root privileges.

Instead:

Identify the exact command required.
Create a restricted sudo rule.
Allow only that command.

Example:

wazuh ALL=(root) NOPASSWD: /usr/bin/firewall-cmd

Verify:

sudo -u wazuh sudo firewall-cmd --list-all

Related Guide: How to Configure Wazuh Active Response

Missing Inventory Data

Syscollector may report incomplete information after removing root privileges.

Symptoms include:

Missing installed packages
Missing processes
Missing network information
Incomplete hardware inventory

Possible causes:

Restricted /proc access
Missing permissions on package databases
Protected system files

Check whether the Wazuh user can access required system information:

sudo -u wazuh ls /proc

If only specific inventory information is missing, determine whether that information is worth granting additional permissions.

A least-privilege deployment may intentionally collect less data in exchange for stronger security isolation.

FIM Stops Working

File Integrity Monitoring failures usually occur because the Wazuh user cannot access monitored paths.

Common examples:

/etc
/root
/usr/bin
/boot

Verify directory access:

sudo -u wazuh ls /etc

If necessary, provide read and traversal permissions:

sudo setfacl -m u:wazuh:rx /etc

For highly sensitive files, consider whether monitoring them requires a privileged agent or whether another collection method is more appropriate.

Linux Capabilities Not Applied

If assigned capabilities do not appear, verify:

getcap /var/ossec/bin/wazuh-agentd

Common causes include:

Capability assigned to the wrong binary
Package upgrade replaced the executable
Filesystem does not support extended attributes
Incorrect capability syntax

Example:

sudo setcap cap_dac_read_search=ep /var/ossec/bin/wazuh-agentd

Then verify again:

getcap /var/ossec/bin/wazuh-agentd

systemd Ignores User Setting

Sometimes administrators modify the systemd service file but the agent continues running as root.

Common causes:

Incorrect override location
Missing daemon reload
Package service file overriding changes
Multiple service definitions

Check the effective configuration:

systemctl cat wazuh-agent

Reload systemd:

sudo systemctl daemon-reload

Restart:

sudo systemctl restart wazuh-agent

Verify:

systemctl status wazuh-agent

SELinux or AppArmor Restrictions

Mandatory Access Control systems may block the Wazuh agent even when traditional permissions are correct.

SELinux

Check status:

getenforce

Review denied actions:

ausearch -m avc -ts recent

AppArmor

Check profiles:

aa-status

If restrictions exist, create a dedicated policy instead of disabling the security framework.

Agent Fails After Upgrade

A Wazuh upgrade may replace:

Binary files
systemd service files
Permissions
Capabilities

After upgrades, verify:

getcap -r /var/ossec

Check ownership:

ls -ld /var/ossec

Verify the service:

systemctl cat wazuh-agent

Reapply required permissions and capabilities if necessary.

Related Guide: How to Upgrade a Wazuh Agent

Security Best Practices

A successful Wazuh Agent Non Root deployment requires continuous permission management.

Reducing privileges once is not enough; organizations should regularly review access, capabilities, and administrative permissions.

Grant Only Required Permissions

Avoid granting broad permissions simply because they solve immediate problems.

Follow these principles:

Monitor only required directories.
Allow access only to required logs.
Avoid unnecessary group memberships.
Remove unused permissions.

Every additional permission increases the potential impact of compromise.

Use Linux Capabilities Instead of Full Root

Linux capabilities provide a more precise security model than unrestricted root privileges.

Instead of:

wazuh → root

prefer:

wazuh → required capability only

Examples:

File reading capability
Network capability
Specific sudo commands

Regularly review assigned capabilities:

getcap -r /var/ossec

Protect Configuration Files

Wazuh configuration files contain important security settings.

Protect:

/var/ossec/etc/ossec.conf
/var/ossec/etc/client.keys

Recommended practices:

Restrict write access.
Monitor configuration changes.
Use centralized configuration carefully.
Maintain backups.

Secure Agent Credentials

Agent authentication files and certificates should be protected.

Important files include:

Agent keys
Certificates
Private keys

Recommended permissions:

or:

depending on your deployment model.

Never expose credentials through shared directories or backups.

Review File Permissions Regularly

Permissions can drift over time because of:

Software updates
Configuration changes
Administrator actions

Create regular reviews:

find /var/ossec -perm -o+w

Audit sensitive locations and remove unnecessary access.

Audit sudo Rules

Review delegated commands regularly:

sudo cat /etc/sudoers

and:

sudo ls /etc/sudoers.d/

Remove:

Old rules
Unused scripts
Wildcard permissions

Monitor Agent Activity

A non-root deployment should still be monitored.

Review:

Agent logs
Authentication events
sudo activity
File changes

Related Guide: How to Test Wazuh Rules

Keep Wazuh Updated

Security vulnerabilities are discovered in all software, including monitoring agents.

Maintain:

Updated Wazuh agents
Updated managers
Updated operating systems
Current security policies

Real-World Example

Scenario

A financial services company wants to deploy Wazuh agents across hundreds of Linux servers while meeting internal security policies that prohibit long-running services from operating as the root user.

The company operates:

Production application servers
Database servers
Web servers
Internal infrastructure systems

Their security team requires endpoint monitoring but does not allow permanently running privileged services unless absolutely necessary.

Challenge

The organization must maintain:

Log collection
File Integrity Monitoring
System inventory
Security Configuration Assessment

without granting unnecessary privileges.

Additional challenges include:

Different Linux distributions
Standardized deployment requirements
Compliance auditing
Operational scalability

Solution

The security team implements a least-privilege Wazuh deployment.

The process includes:

Creating a dedicated wazuh service account.
Assigning ownership and permissions only where required.
Granting Linux capabilities instead of full root access.
Configuring ACLs for monitored log files.
Restricting Active Response operations through sudoers rules.
Updating the systemd service to run under the non-root account.
Testing all enabled monitoring modules.

Validation includes:

Log collection tests
FIM modification tests
Syscollector inventory checks
Manager connectivity verification
Active Response testing

The final configuration is documented and automated through configuration management tools.

Outcome

The organization successfully operates Wazuh agents with significantly reduced privileges while maintaining essential security visibility.

Benefits include:

Reduced attack surface
Improved compliance alignment
Easier security audits
Lower privilege escalation risk
Standardized endpoint deployment

The organization also creates a repeatable deployment model that can be automated across hundreds of Linux systems.

Frequently Asked Questions (FAQ)

Question: Can Wazuh Agent Run Completely Without Root Privileges?

In some environments, yes. However, a completely rootless deployment may limit certain features.

Modules such as:

Rootcheck
Active Response
Some FIM scenarios
Certain SCA checks

may require elevated permissions.

A more practical approach is reducing privileges as much as possible while preserving required monitoring functionality.

Question: Which Wazuh Modules Require Elevated Permissions?

Modules commonly requiring elevated access include:

Rootcheck
Active Response
Some File Integrity Monitoring paths
Some Security Configuration Assessment checks

Other features may work with carefully configured permissions.

Question: Can Linux Capabilities Replace Root Access?

Yes, in many situations.

Capabilities allow administrators to grant specific privileged operations without granting complete root access.

However, capabilities cannot replace every root function.

Question: Does File Integrity Monitoring Work Without Root?

Yes, if the Wazuh user can access the monitored files.

Monitoring user-owned applications is usually straightforward, while protected system directories may require additional permissions.

Question: Can Active Response Be Used With a Non-Root Agent?

Yes, but it requires careful configuration.

The recommended approach is:

Dedicated sudo rules
Specific allowed commands
No unrestricted sudo access

Question: How Do I Verify Which User the Wazuh Agent Is Running As?

Use:

ps -o user,group,comm -C wazuh-agentd

or:

systemctl status wazuh-agent

Question: Will Running as Non-Root Affect Performance?

Normally, no.

Performance differences are usually negligible.

The main impact is reduced access to certain system resources, which may affect data collection rather than performance.

Question: Does Wazuh Officially Support Non-Root Deployments?

Wazuh agents are commonly deployed with elevated privileges because many security monitoring features require them.

A customized non-root deployment should be tested carefully to ensure required functionality remains available.

Question: How Do I Troubleshoot Permission Errors?

Start by checking:

Agent logs.
File permissions.
ACL settings.
Linux capabilities.
SELinux/AppArmor policies.
systemd configuration.

Question: What Is the Most Secure Way to Deploy Wazuh Agents on Linux?

The most secure approach is:

Use least privilege.
Avoid unnecessary root access.
Grant only required permissions.
Protect credentials.
Audit changes regularly.
Keep Wazuh updated.
Test every enabled module.

Conclusion

Running the Wazuh Agent Non Root provides organizations with a stronger security posture by reducing unnecessary privileged access while maintaining valuable endpoint monitoring capabilities.

A properly designed deployment can:

Reduce attack surface
Limit privilege escalation opportunities
Improve compliance readiness
Simplify security audits
Support least-privilege security models

However, security teams must balance privilege reduction with operational requirements.

Some Wazuh features, especially Active Response, Rootcheck, and certain compliance checks, may require additional permissions.

The most effective approach is not simply removing root access, but carefully designing a permission model that provides the minimum privileges required for each monitoring function.

Before deploying broadly:

Test every enabled Wazuh module.
Validate log collection.
Confirm FIM coverage.
Verify Syscollector results.
Review Active Response behavior.
Document permissions.

By combining Linux capabilities, ACLs, restricted sudo rules, and systemd hardening, organizations can build secure and scalable Wazuh deployments across Linux environments.

Related guides:

How to Configure Wazuh Agent Non Root Privileges on Linux Systems

What Is Wazuh Agent Non Root?

Why the Agent Normally Runs as Root

Which Agent Components Require Elevated Privileges

What Changes When Running With Non-Root Permissions

Supported Use Cases and Limitations

Benefits of Running the Wazuh Agent Without Root Privileges

Improved Security

Reduced Attack Surface

Better Compliance

PCI DSS

HIPAA

ISO 27001

CIS Benchmarks

Principle of Least Privilege

Safer Multi-Tenant Systems

Easier Security Audits

Prerequisites

Supported Linux Distributions

Wazuh Version Requirements

Administrative Access for Initial Setup

Understanding Linux Users and Groups

Existing Wazuh Manager Connection

Required Packages and Tools

Understanding Which Wazuh Features Require Root

Log Collection

File Integrity Monitoring (FIM)

Vulnerability Detection

Syscollector

Rootcheck

Active Response

Command Monitoring

SCA (Security Configuration Assessment)

Windows Event Collection (Not Applicable)

Creating a Dedicated Wazuh User

Creating the User

Creating the Group

Assigning Home Directory

Preventing Interactive Login

Verifying User Creation

Configuring File Ownership and Permissions

Wazuh Installation Directory

Log Files

Queue Directories

Temporary Files

Certificates and Keys

Configuration Files

Restricting Sensitive Files

Configuring Linux Capabilities Instead of Root

What Linux Capabilities Are

Using setcap

Common Capabilities Used

CAP_DAC_READ_SEARCH

CAP_NET_RAW

CAP_SYS_PTRACE

CAP_SYSLOG (where applicable)

Verifying Assigned Capabilities

Removing Unnecessary Capabilities

Configuring the Wazuh Agent to Run as a Non-Root User

Updating the Service Configuration

Editing systemd Service Files

Setting User and Group

Reloading systemd

Restarting the Agent

Confirming the Running User

Allowing Access to Required Log Files

Linux Authentication Logs

Syslog Files

Application Logs

Web Server Logs

Docker Logs

Kubernetes Logs

Custom Log Directories

Handling File Integrity Monitoring Permissions

Monitoring System Files

Monitoring Application Directories

Read-Only Access Requirements

Permission Best Practices

Managing Active Response with Non-Root Agents

Why Active Response Is Different