The Ultimate Wazuh Configuration Guide

Installing Wazuh is only the first step toward building an effective security monitoring platform.

Once the platform is running, the real work begins: configuring it to collect the right data, detect meaningful threats, automate responses, and scale reliably across your infrastructure.

Every environment is different, so there is no single configuration that works for every deployment.

The default installation is intentionally conservative.

Without customization, you may miss important security events, collect excessive amounts of unnecessary logs, consume more storage than expected, or generate overwhelming numbers of false-positive alerts.

Well-configured deployments improve detection accuracy, reduce operational overhead, and make investigations significantly faster.

It’s also important to understand the difference between installing Wazuh and configuring it.

Installation focuses on deploying the software components and ensuring they communicate correctly. Configuration focuses on determining what data should be collected, how alerts should be generated, when automated responses should execute, and how the platform should operate in production.

In this comprehensive guide, you’ll learn how Wazuh’s configuration system works, which configuration files control each component, and the best practices for safely modifying them.

You’ll also discover how to configure core features such as File Integrity Monitoring (FIM), Active Response, centralized syslog collection, log retention, custom detection rules, and rule testing.

Throughout the guide, we’ll link to detailed tutorials that walk through each configuration topic step by step.

Whether you’re deploying Wazuh for the first time or optimizing an existing deployment, this guide is designed to serve as your complete configuration reference.

This guide is intended for:

Security analysts responsible for monitoring alerts and improving detection quality
System administrators deploying and maintaining Wazuh infrastructure
DevSecOps engineers integrating security monitoring into modern application environments
SOC teams managing enterprise-scale Wazuh deployments
IT professionals looking to optimize performance, scalability, and operational efficiency

Understanding Wazuh Configuration

Before modifying configuration files, it’s important to understand how Wazuh is structured.

Rather than relying on a single configuration file, Wazuh distributes configuration across multiple components, each responsible for a different part of the platform.

Together, these files determine how data is collected, analyzed, stored, visualized, and acted upon.

Understanding which component controls which functionality helps you troubleshoot problems faster and avoid making unnecessary or conflicting configuration changes.

What Can Be Configured in Wazuh?

Nearly every aspect of Wazuh can be customized. Common configuration areas include:

Agents

Agents collect security telemetry from monitored endpoints.

Typical agent configuration includes:

Log collection paths
Windows Event Log channels
File Integrity Monitoring targets
Vulnerability Detection settings
Rootcheck configuration
Syscollector inventory
Agent authentication
Performance tuning

If you’re managing Windows endpoints, see our guide on How to Install a Wazuh Agent on Windows Server.

For Linux environments, you may also find How to Add Linux Endpoints to Wazuh helpful.

Manager

The Wazuh manager acts as the central processing engine.

It can be configured for:

Agent enrollment
Rule processing
Active Response
Cluster communication
Log forwarding
API settings
Email notifications
Performance tuning
Agent groups

Most production environments spend the majority of their configuration effort on the manager.

Indexer

The Wazuh Indexer stores alerts and security events.

Configuration areas include:

Cluster topology
Heap memory
Shard allocation
Index lifecycle
Security certificates
Snapshot policies
Performance optimization

Poor indexer configuration often results in storage issues or high memory usage.

Dashboard

The Wazuh Dashboard provides visualization and investigation capabilities.

Common configuration includes:

Authentication
User roles
Dashboards
Alert filtering
Multi-tenancy
SSL certificates
Branding
API connectivity

Filebeat

Filebeat forwards processed alerts from the manager to the Wazuh Indexer.

Configuration typically includes:

Output destinations
TLS certificates
Buffer sizes
Retry settings
Load balancing
Compression

If Filebeat cannot communicate with the indexer, alerts will stop appearing in the dashboard.

Related troubleshooting article:

Resolving Filebeat Connection Refused Errors in Wazuh Deployments

Active Response

Active Response allows Wazuh to automatically mitigate threats.

Common actions include:

Blocking malicious IP addresses
Killing suspicious processes
Disabling compromised accounts
Running custom scripts
Firewall updates

We’ll cover this later in the guide:

How to Configure Wazuh Active Response

Detection Rules

Detection rules determine which security events generate alerts.

Administrators can:

Modify alert severity
Create custom rules
Suppress noisy alerts
Correlate events
Tune false positives

Related guides:

Decoders

Decoders parse incoming log formats before rules evaluate them.

They can be customized for:

Proprietary applications
Custom syslog formats
Vendor-specific logs
Regular expression matching
JSON parsing

If custom decoders are not functioning correctly, see:

Custom Decoder Isn’t Matching: Wazuh Logtest Deep Dive

Integrations

Wazuh integrates with numerous external platforms.

Examples include:

VirusTotal
Slack
Microsoft Graph
Suricata
OPNsense
AWS CloudTrail
Splunk

Related configuration tutorials include:

File Integrity Monitoring

FIM detects unauthorized file modifications.

Configuration includes:

Monitored directories
Exclusions
Frequency
Real-time monitoring
Whitelists

See:

How to Configure File Integrity Monitoring (FIM) in Wazuh

Vulnerability Detection

Administrators configure:

Feed updates
Operating system inventories
Scan frequency
Supported platforms

If detection is not working properly:

Wazuh Vulnerability Detection Not Working? Here’s How to Fix It

Log Collection

Wazuh supports collecting:

Linux logs
Windows Event Logs
Application logs
Apache logs
Firewall logs
Cloud logs
Container logs

Examples include:

Syslog Services

Wazuh can act as a centralized syslog server for routers, switches, firewalls, Linux servers, and network appliances.

See:

How to Configure Wazuh as a Centralized Syslog Server

Wazuh Configuration Files Explained

One of Wazuh’s greatest strengths is its modular configuration architecture.

Different files control different subsystems, making it easier to manage large deployments without editing a single monolithic configuration file.

Understanding these files is essential for successful administration.

Manager Configuration (ossec.conf)

The primary configuration file is ossec.conf.

Purpose

This file controls nearly every major manager function, including:

Log analysis
Agent communication
Active Response
Integrations
FIM
Rootcheck
Syscheck
Email
Clustering
Authentication
API behavior

Location on Linux

The manager configuration file is typically located at:

/var/ossec/etc/ossec.conf

XML Structure

Wazuh uses XML for configuration.

Sections are organized into logical blocks, making it relatively easy to identify and modify individual features without affecting unrelated services.

Common Sections

Frequently modified sections include:

<global>
<syscheck>
<rootcheck>
<localfile>
<active-response>
<integration>
<command>
<cluster>
<auth>

Agent Configuration

Agents maintain their own configuration that determines what data they collect before forwarding it to the manager.

Local Configuration

Each endpoint has its own:

/var/ossec/etc/ossec.conf

or the Windows equivalent installation directory.

Local configuration is appropriate for standalone agents or unique servers.

Centralized Agent Configuration

Large environments typically manage agents centrally using shared configuration.

Benefits include:

Consistent settings
Easier maintenance
Faster deployments
Reduced configuration drift

Agent Groups

Agent groups allow administrators to assign different configurations based on server role.

For example:

Windows Servers
Linux Servers
Web Servers
Database Servers
Domain Controllers
Kubernetes Nodes

This greatly simplifies enterprise administration.

Internal Options

Certain advanced settings are controlled through internal options.

internal_options.conf

This file contains low-level parameters controlling Wazuh internals.

Examples include:

Queue sizes
Thread limits
Performance settings
Timing values
Internal buffers

local_internal_options.conf

Rather than modifying the default file directly, administrators should place overrides in:

local_internal_options.conf

This approach helps preserve customizations during upgrades.

When to Modify Them

These files should only be edited when:

Performance tuning is required
Official documentation recommends a change
Wazuh support recommends adjustments
Advanced troubleshooting requires it

For most deployments, default values are appropriate.

Rule Files

Rules determine how Wazuh evaluates incoming events.

Default Rules

Default rule sets ship with Wazuh and cover thousands of common security events.

They should generally not be edited directly.

Local Rules

Custom rules belong in:

local_rules.xml

Keeping custom logic separate prevents it from being overwritten during upgrades.

For detailed examples, see:

How to Create Custom Detection Rules in Wazuh (With Examples)

Decoder Files

Before rules execute, incoming logs must first be decoded.

Purpose

Decoders identify:

Log format
Fields
Values
Event type

This structured information allows detection rules to work correctly.

Custom Decoders

Organizations frequently create custom decoders for:

Internal applications
Proprietary software
Legacy systems
Vendor-specific devices

Processing Order

Incoming logs are generally processed in the following sequence:

Log collection
Decoder matching
Rule evaluation
Alert generation
Active Response (if configured)

When troubleshooting parsing issues, remember that rules cannot match fields that decoders never extracted.

Wazuh Configuration Best Practices Before You Begin

Configuration changes can significantly impact your security monitoring environment.

Following a few best practices before making modifications helps reduce downtime, simplifies troubleshooting, and prevents accidental data loss.

Back Up Existing Configuration Files

Always create backups before editing any configuration file.

This allows you to quickly restore a working configuration if a mistake causes services to fail or alerts to stop processing.

A common approach is to maintain timestamped backups or use a version control system to track changes over time.

Validate Configuration Before Restarting Services

One small XML syntax error can prevent the Wazuh manager from starting.

Always validate configuration files before restarting services whenever possible, and carefully review service logs after applying changes.

The official Wazuh documentation provides guidance on validating configurations and safely restarting services.

Use Version Control for Configuration Changes

Treat Wazuh configuration like application code.

Many security teams store configuration files in Git repositories so they can:

Track every modification
Roll back changes quickly
Review updates before deployment
Audit historical changes
Collaborate across teams

This practice aligns with modern Infrastructure as Code (IaC) and DevSecOps workflows.

Test Changes in a Non-Production Environment

Whenever possible, validate new rules, integrations, and configuration changes in a staging environment before deploying them to production.

Testing helps identify:

Unexpected alert volume
Performance impacts
Parsing failures
Rule conflicts
Automation mistakes

The Wazuh developers also recommend testing custom rules using wazuh-logtest before enabling them in production.

See:

How to Test Wazuh Rules

Document Every Configuration Change

Maintain documentation describing:

What changed
Why it changed
Who approved it
When it was deployed
Expected impact

Good documentation significantly reduces troubleshooting time during future incidents.

Understand Service Dependencies

Many Wazuh components depend on one another.

For example:

Agents send data to the manager.
The manager forwards alerts through Filebeat.
Filebeat sends alerts to the Wazuh Indexer.
The Dashboard retrieves data from the Indexer through its APIs.

A problem in any one of these components can affect the entire monitoring pipeline.

Understanding these relationships makes troubleshooting much faster and prevents unnecessary configuration changes in the wrong component.

Industry guidance from organizations such as the National Institute of Standards and Technology (NIST) emphasizes secure configuration management and controlled change management as foundational cybersecurity practices, particularly in production environments.

Following these principles reduces operational risk while improving system reliability.

Essential Wazuh Configurations Every Deployment Needs

While Wazuh offers dozens of configurable features, there are several settings that every deployment should review before moving into production.

These core configurations ensure that the platform collects meaningful security data, organizes monitored systems efficiently, delivers actionable alerts, and protects administrative access.

Whether you’re managing ten endpoints or several thousand, the following configurations should be considered the foundation of a healthy Wazuh deployment.

Configure Log Collection

Log collection is the backbone of every Wazuh deployment.

If important events are not being collected, they cannot be analyzed, correlated, or used to generate alerts.

Before enabling advanced features such as custom detection rules or automated responses, verify that Wazuh is ingesting logs from all critical systems.

Common log sources include:

Local Logs

Linux systems generate valuable logs through files stored under directories such as:

/var/log/

Examples include:

Authentication logs
System logs
Kernel logs
Application logs
Package manager logs

Monitoring these files provides visibility into authentication attempts, privilege escalation, software changes, and system errors.

Windows Event Logs

Windows endpoints rely heavily on Event Viewer channels rather than traditional log files.

Common channels include:

Security
System
Application
PowerShell
Sysmon
Microsoft Defender

Collecting Windows Event Logs enables Wazuh to detect failed logins, privilege abuse, malware activity, PowerShell attacks, and lateral movement.

For a complete walkthrough, see:

How to Monitor Windows Event Logs Using Wazuh

Syslog

Many network devices, firewalls, switches, routers, storage appliances, and Unix systems transmit logs using the Syslog protocol.

Centralizing Syslog collection provides a single location for monitoring infrastructure events and simplifies incident investigations.

If you want Wazuh to receive logs from network devices, see:

How to Configure Wazuh as a Centralized Syslog Server

Journald

Modern Linux distributions often use systemd-journald instead of traditional log files.

Collecting Journald events ensures visibility into:

Service failures
Boot events
Kernel messages
Authentication events
Container activity

Many organizations monitor both Journald and traditional log files to maximize coverage.

Custom Application Logs

Business applications often produce proprietary log formats that contain valuable security information.

Examples include:

ERP systems
CRM platforms
Financial applications
Internal web services
API gateways
Custom microservices

Wazuh supports monitoring virtually any text-based log source. Custom decoders and detection rules can then transform those logs into meaningful security alerts.

Configure Agent Groups

As environments grow, managing every endpoint individually quickly becomes impractical.

Agent groups allow administrators to organize endpoints based on their purpose and assign shared configurations to entire collections of systems.

Organize Endpoints

Common grouping strategies include:

Windows Servers
Linux Servers
Workstations
Domain Controllers
Database Servers
Web Servers
Kubernetes Nodes
Cloud Instances
Development Systems

Grouping endpoints keeps configuration organized while reducing administrative effort.

Assign Shared Configurations

Rather than maintaining hundreds of separate configuration files, shared settings can be applied to entire groups.

Examples include:

FIM policies
Log collection paths
Active Response settings
Detection rules
Vulnerability Detection
Syscheck schedules

When requirements change, administrators only need to update the group configuration instead of every individual endpoint.

Simplify Management

Using agent groups provides several operational benefits:

Faster onboarding of new systems
Consistent security policies
Reduced configuration drift
Easier troubleshooting
Simplified large-scale deployments

This centralized approach is especially valuable in enterprise environments where hundreds or thousands of endpoints share similar security requirements.

Configure Alert Levels

One of the biggest challenges facing security teams is alert fatigue.

A poorly tuned deployment can generate thousands of low-value alerts every day, making it difficult to identify genuine threats.

Configuring alert levels appropriately helps prioritize analyst attention.

Severity Levels

Wazuh assigns each rule a severity level based on the potential impact of the detected event.

Typical categories include:

Informational
Low
Medium
High
Critical

Organizations often customize these severities to better reflect their own risk tolerance and security policies.

Noise Reduction

Reducing unnecessary alerts improves the overall effectiveness of the SOC.

Common tuning techniques include:

Suppressing known benign events
Adjusting rule thresholds
Ignoring trusted processes
Excluding maintenance activities
Refining custom rules

For additional guidance, see:

How to Reduce False Positives in Wazuh

Prioritization

Critical alerts should receive immediate attention, while informational events may simply be retained for auditing purposes.

Prioritizing alerts enables:

Faster incident response
Better analyst productivity
Reduced investigation time
Improved detection quality

Security researchers at the SANS Institute have long emphasized that reducing alert fatigue is one of the most effective ways to improve security operations center performance.

Configure Email Notifications

Although many organizations rely on dashboards, SIEM integrations, or messaging platforms, email notifications remain an important alerting mechanism for high-priority security events.

Proper configuration ensures that critical alerts reach administrators even when they are not actively monitoring the dashboard.

SMTP Settings

Typical email configuration includes:

SMTP server
Authentication
TLS encryption
Sender address
Recipient lists
Connection security

Always use authenticated and encrypted SMTP whenever possible.

Alert Thresholds

Avoid sending an email for every alert.

Instead, configure notifications for:

High-severity detections
Authentication failures
Malware alerts
Privilege escalation
Active Response events
Infrastructure failures

This prevents important notifications from being buried beneath low-priority messages.

Best Practices

Consider the following recommendations:

Limit emails to important alerts.
Use distribution groups instead of individual addresses.
Regularly verify SMTP credentials.
Test notifications after every configuration change.
Combine email with dashboard monitoring and ticketing systems.

If your deployment is not sending notifications correctly, see:

Wazuh Email Alerts Not Working? Complete Fix Guide

Configure Dashboard Authentication

The Wazuh Dashboard provides access to alerts, endpoint data, threat investigations, and administrative settings.

Because it contains sensitive security information, protecting access should be a top priority.

User Management

Avoid using shared administrator accounts.

Instead:

Create individual user accounts.
Disable unused accounts.
Rotate passwords regularly.
Integrate with centralized identity providers where possible.

Role-Based Access

Not every user requires administrative privileges.

Role-based access control (RBAC) allows organizations to grant permissions based on job responsibilities.

For example:

SOC analysts may investigate alerts.
Security engineers may manage rules.
Administrators may configure infrastructure.
Auditors may have read-only access.

This separation reduces the risk of accidental or unauthorized changes.

Least Privilege

The principle of least privilege recommends granting users only the permissions necessary to perform their responsibilities.

Following this principle helps:

Reduce insider risk
Limit accidental configuration changes
Improve auditability
Strengthen regulatory compliance

The Cybersecurity and Infrastructure Security Agency (CISA) identifies least privilege as one of the core practices for reducing the impact of compromised accounts.

Configure File Integrity Monitoring (FIM)

File Integrity Monitoring (FIM) is one of Wazuh’s most valuable security capabilities.

It continuously monitors files and directories for unauthorized modifications, allowing organizations to quickly identify potential compromises, configuration drift, ransomware activity, or insider threats.

Instead of waiting for attackers to execute malicious actions, FIM detects one of the earliest indicators of compromise: unexpected changes to critical files.

Wazuh’s FIM engine, powered by the Syscheck module, periodically scans configured directories and compares file metadata against previously recorded baselines.

Depending on the configuration, it can monitor:

File creation
File deletion
File modifications
Ownership changes
Permission changes
Hash changes
Registry changes on Windows

Many deployments also enable real-time monitoring so changes are detected almost immediately rather than waiting for scheduled scans.

FIM is commonly deployed to support several security objectives.

Compliance Monitoring

Many regulatory frameworks require organizations to monitor critical system files for unauthorized modifications.

Examples include:

PCI DSS
HIPAA
ISO 27001
CIS Controls
NIST Cybersecurity Framework

FIM helps demonstrate that important operating system files, security configurations, and application binaries are continuously monitored.

Ransomware Detection

Modern ransomware frequently encrypts large numbers of files within a short period.

Although FIM cannot prevent encryption by itself, it can rapidly detect abnormal file modification patterns and generate alerts before an attack spreads further across the environment.

Combined with Active Response, these alerts can trigger automated containment actions.

For more information, see:

How to Detect Ransomware Activity Using Wazuh

Change Auditing

Not every file change indicates malicious activity.

FIM also provides valuable auditing capabilities by recording:

Who changed a file
When it changed
Which attributes changed
Whether permissions were modified

These audit trails simplify troubleshooting, incident response, and compliance reporting.

Protecting Critical System Files

Organizations commonly monitor:

System configuration files
Authentication databases
Web server directories
Application configuration files
Security policies
Startup scripts
Sensitive document repositories

Choosing the right monitoring scope is important. Monitoring every file on every system may generate unnecessary alerts and increase resource consumption.

For a complete step-by-step implementation guide, including recommended exclusions, real-time monitoring, and performance tuning, see:

How to Configure File Integrity Monitoring (FIM) in Wazuh

Configure Wazuh Active Response

Detecting attacks is only part of an effective security strategy.

In many situations, organizations also want Wazuh to respond automatically before an attacker can continue exploiting a compromised system.

Active Response enables Wazuh to execute predefined actions whenever specific detection rules are triggered, reducing response times from minutes to seconds.

Instead of waiting for an analyst to investigate every alert manually, Wazuh can immediately perform defensive actions based on your security policies.

Common automated responses include:

Blocking malicious IP addresses
Disabling compromised user accounts
Killing suspicious processes
Removing temporary malicious files
Updating firewall rules
Running custom remediation scripts

These actions are performed only when configured rules match defined conditions.

When Should Organizations Enable Active Response?

Active Response is particularly valuable for events that require immediate containment.

Examples include:

Brute-force login attacks
Malware execution
Known malicious IP addresses
Unauthorized privilege escalation
Web application attacks
Repeated authentication failures

Automating these responses helps reduce attacker dwell time while allowing analysts to focus on investigation rather than repetitive manual tasks.

Supported Response Actions

Wazuh includes several built-in response scripts while also allowing organizations to create their own custom actions.

Common responses include:

Firewall blocking
Process termination
Account lockout
Temporary IP bans
Script execution
Custom automation workflows

Many organizations integrate Active Response with external security tools to build more comprehensive incident response pipelines.

Deploy Active Response Safely

Although automation provides significant security benefits, it should be introduced carefully.

Before enabling automated responses in production:

Test every response thoroughly.
Validate detection rules to minimize false positives.
Limit automation to high-confidence alerts.
Maintain rollback procedures.
Monitor response activity regularly.
Document every automated action.

Security experts generally recommend starting with monitoring mode before gradually enabling automated enforcement for trusted detection rules.

For a complete implementation guide covering configuration, supported commands, custom scripts, and deployment recommendations, continue with:

How to Configure Wazuh Active Response

Configure Wazuh Log Retention

Every Wazuh deployment continuously generates large volumes of security data.

Alerts, endpoint inventories, vulnerability findings, File Integrity Monitoring events, authentication logs, and application logs quickly accumulate, especially in medium and large environments.

Without a well-planned log retention strategy, storage costs can grow rapidly, searches may become less efficient, and important forensic evidence may be lost.

Log retention is the practice of determining how long security events should be stored before they are archived or deleted.

The ideal retention period depends on your organization’s regulatory requirements, operational needs, storage capacity, and incident response objectives.

An effective retention policy balances three competing priorities:

Retaining enough historical data for investigations
Controlling infrastructure and storage costs
Meeting legal and regulatory requirements

Why Log Retention Matters

A thoughtful retention policy provides benefits beyond simply saving disk space.

Compliance Requirements

Many security and privacy frameworks require organizations to retain security logs for defined periods.

Examples include:

PCI DSS
HIPAA
ISO 27001
SOC 2
NIST guidance

The required retention period varies depending on the regulation and industry, making it important to understand the requirements that apply to your organization.

Storage Management

Without retention controls, indexes continue growing indefinitely.

This can lead to:

Increased storage costs
Longer backup times
Reduced search performance
Slower dashboard queries
Higher infrastructure requirements

Proper retention planning helps maintain predictable storage utilization as your environment expands.

Incident Investigations

Security incidents are not always detected immediately.

Attackers may remain inside an environment for weeks or even months before being discovered.

Historical logs often provide the evidence needed to reconstruct attack timelines, identify affected systems, and understand the scope of a compromise.

Deleting logs too aggressively can permanently remove critical forensic evidence.

Security Auditing

Historical logs are frequently used during:

Internal audits
Regulatory assessments
Compliance reviews
Post-incident analysis
Executive reporting

Maintaining sufficient log history simplifies these activities while demonstrating mature security operations.

Common Log Retention Strategies

There is no universal retention period that works for every organization.

Instead, most deployments adopt tiered retention policies based on business requirements.

Common approaches include:

Retaining recent alerts on high-performance storage for fast investigations
Moving older indexes to lower-cost storage
Archiving long-term data for compliance purposes
Automatically deleting expired indexes after predefined periods

Many organizations also retain different categories of logs for different lengths of time.

For example, authentication logs may be stored longer than low-priority informational events because they provide greater investigative value.

Planning Considerations

Before configuring retention policies, consider the following questions:

How many endpoints generate logs?
How many alerts are produced each day?
What is your expected annual data growth?
Which compliance regulations apply?
How quickly must investigators access historical data?
Will archived logs need to remain searchable?

Planning ahead helps prevent expensive storage upgrades while ensuring that critical security data remains available when needed.

The National Institute of Standards and Technology (NIST) recommends establishing formal log retention policies as part of an organization’s broader logging and incident response strategy, ensuring that security events remain available for monitoring, investigations, and compliance activities.

For a complete walkthrough covering index lifecycle management, retention policies, storage optimization, and configuration examples, continue with:

How to Configure Wazuh Log Retention

Configure Wazuh as a Centralized Syslog Server

Many organizations rely on devices that cannot run the Wazuh agent.

Firewalls, routers, switches, load balancers, storage appliances, printers, and numerous network devices generate security logs exclusively through the Syslog protocol.

By configuring Wazuh as a centralized Syslog server, these devices can forward their logs to a single location where they are analyzed alongside endpoint telemetry.

This provides significantly better visibility across the entire infrastructure while reducing the complexity of monitoring multiple independent logging systems.

Centralized Syslog collection is often one of the first capabilities organizations enable after deploying Wazuh.

How Wazuh Collects Syslog Data

Syslog is a standardized protocol supported by thousands of operating systems, security appliances, and enterprise applications.

Once configured, devices transmit messages to the Wazuh manager over the network, where they are:

Received by the Syslog listener
Parsed using decoders
Evaluated against detection rules
Converted into alerts when suspicious activity is detected
Indexed for searching and long-term analysis

This allows Wazuh to correlate events from multiple sources rather than analyzing each device independently.

Common Syslog Sources

Almost any device capable of generating Syslog messages can be integrated.

Common examples include:

Firewalls
Routers
Network switches
VPN gateways
Linux servers
Unix systems
Load balancers
DNS servers
Web servers
Reverse proxies
Storage appliances
Security appliances

Many organizations also configure cloud services and virtualization platforms to forward Syslog events into Wazuh.

Typical Deployment Architectures

Syslog deployments vary depending on organization size.

Small Environments

In smaller deployments, devices often send Syslog messages directly to the Wazuh manager.

This architecture is simple to deploy and works well for organizations with relatively low log volume.

Enterprise Deployments

Larger environments frequently introduce dedicated Syslog collectors or load balancers before forwarding logs to Wazuh.

This approach provides:

Better scalability
Improved fault tolerance
Higher ingestion capacity
Easier geographic distribution
Simplified maintenance

Some organizations also separate external-facing network devices from internal infrastructure by using multiple Syslog collection tiers.

Benefits of Centralized Syslog Collection

Aggregating infrastructure logs into a single platform provides several operational advantages:

Unified visibility across network and endpoint devices
Easier threat correlation
Faster incident investigations
Centralized log retention
Simplified compliance reporting
Reduced administrative overhead

When combined with custom detection rules and threat intelligence integrations, centralized Syslog becomes a powerful source of actionable security intelligence.

For detailed configuration steps, supported architectures, network requirements, and troubleshooting guidance, see:

How to Configure Wazuh as a Centralized Syslog Server

Create Custom Detection Rules

Wazuh includes thousands of built-in detection rules covering common operating systems, applications, and attack techniques.

While these default rules provide excellent baseline coverage, every organization has unique infrastructure, business applications, security policies, and operational requirements.

Custom detection rules allow administrators to extend Wazuh beyond its default capabilities by creating alerts tailored specifically to their environment.

Rather than relying solely on generic detections, organizations can identify suspicious behaviors that are meaningful within their own networks.

Why Custom Rules Are Necessary

Every environment generates events that default rule sets cannot fully interpret.

Examples include:

Proprietary business applications
Internal APIs
Custom authentication systems
Industry-specific software
Unique administrative processes
Organization-specific compliance requirements

Custom rules enable Wazuh to recognize these events and generate actionable alerts that would otherwise be ignored.

Extending Built-in Detections

Custom rules do not replace Wazuh’s existing rules.

They enhance them.

Administrators commonly use custom rules to:

Increase or decrease alert severity
Suppress known false positives
Detect organization-specific attack patterns
Correlate multiple events
Trigger Active Response actions
Create compliance-specific alerts

This layered approach preserves the value of the default rules while adapting them to local operational needs.

Common Use Cases

Organizations develop custom rules for many different scenarios.

Examples include:

Monitoring privileged administrative commands
Detecting access to sensitive business applications
Identifying unusual login locations
Tracking configuration changes
Monitoring custom application logs
Detecting proprietary error conditions
Enforcing internal security policies
Alerting on unauthorized software execution

Many organizations also write custom rules to support regulatory compliance reporting and internal security audits.

Typical Rule Development Workflow

Creating effective custom rules is an iterative process.

A common workflow includes:

Collect representative log samples.
Verify that decoders correctly extract fields.
Create a new custom rule.
Test the rule using wazuh-logtest.
Adjust thresholds and matching conditions.
Validate against production-like data.
Deploy the rule.
Monitor for false positives and refine as needed.

Testing before deployment is especially important because poorly written rules can generate excessive alerts or miss genuine attacks.

For additional guidance on validation, see:

How to Test Wazuh Rules

Follow Detection Engineering Best Practices

Security teams increasingly treat detection rules as code.

This means:

Using version control
Peer reviewing rule changes
Testing before deployment
Maintaining documentation
Continuously improving detections based on real-world incidents

Experts from MITRE encourage organizations to continuously evolve detections as attackers adopt new techniques, using frameworks such as ATT&CK to identify gaps in defensive coverage.

For a complete tutorial covering rule syntax, XML structure, matching conditions, practical examples, testing, and troubleshooting, continue with:

How to Create Custom Detection Rules in Wazuh (With Examples)

Test Wazuh Rules

Creating custom detection rules is only half of the process.

Every rule should be thoroughly validated before it is deployed to production.

Even a small mistake in rule syntax, decoder logic, or matching conditions can prevent alerts from triggering or generate excessive false positives that overwhelm analysts.

Testing ensures that a rule behaves exactly as intended under real-world conditions.

It also helps confirm that logs are being decoded correctly, the appropriate fields are available, and the resulting alerts match your organization’s expectations.

Treating rule testing as a mandatory step in your deployment workflow significantly improves detection quality while reducing operational risk.

Why Every Custom Rule Should Be Tested

Skipping validation can lead to several problems:

Important attacks go undetected.
Legitimate activity generates unnecessary alerts.
Active Response executes unexpectedly.
Analysts lose confidence in alerts.
Troubleshooting becomes more difficult after deployment.

Testing before deployment allows administrators to identify these issues early when they are much easier to fix.

Many mature security teams follow a detection engineering workflow in which every new or modified rule is tested before being approved for production.

Available Testing Methods

Wazuh provides several ways to validate rules.

wazuh-logtest

The primary testing utility is wazuh-logtest.

This interactive tool allows administrators to submit sample log entries and observe each stage of processing, including:

Decoder selection
Extracted fields
Matching rules
Generated alert level
Rule descriptions
Parent-child rule relationships

Because it simulates the manager’s rule engine, wazuh-logtest is usually the fastest way to troubleshoot detection logic.

Replay Sample Logs

Testing with representative production logs provides additional confidence.

Administrators often:

Collect real log samples
Remove sensitive information
Replay the logs in a test environment
Verify expected alerts

This approach validates both decoding and detection behavior using realistic data.

Staging Environments

Large organizations frequently maintain staging environments that closely resemble production.

Testing here allows teams to evaluate:

Alert volume
Performance impact
Rule interactions
Active Response behavior
Integration workflows

before deploying changes to production.

Troubleshooting Failed Rule Matches

When a rule fails to trigger, the problem is not always the rule itself.

Common causes include:

Decoder Did Not Match

Rules depend on decoders extracting the correct fields.

If the incoming log was parsed incorrectly, or not parsed at all, the rule may never execute.

Review decoder output before modifying the rule.

If you’re working with custom log formats, see:

Custom Decoder Isn’t Matching: Wazuh Logtest Deep Dive

Incorrect Rule Conditions

Small syntax mistakes can prevent matching.

Common examples include:

Incorrect field names
Invalid regular expressions
Improper rule hierarchy
Missing parent rules
Incorrect frequency or timeframe settings

Carefully reviewing rule logic usually resolves these issues.

Unexpected Log Format

Applications occasionally change their logging format after upgrades.

When this happens:

Existing decoders may stop matching.
Fields may be renamed.
New fields may appear.
Rules may require updates.

Monitoring these changes helps prevent silent detection failures.

Configuration Was Not Reloaded

After modifying rules, remember to reload or restart the necessary Wazuh services.

Otherwise, the manager may continue using older rule definitions.

Detection Engineering Is an Ongoing Process

Rule development should not end after deployment.

Effective security teams continuously:

Review alert quality.
Reduce false positives.
Add new detections.
Update rules for emerging threats.
Validate changes after upgrades.

Organizations such as MITRE encourage continuously improving detections as adversaries evolve their techniques rather than relying solely on static rule sets.

For detailed examples of testing custom rules, interpreting wazuh-logtest output, and troubleshooting failed matches, continue with:

How to Test Wazuh Rules

Additional Advanced Configuration Options

Once the core components of Wazuh have been configured, organizations can begin implementing more advanced capabilities that improve scalability, automation, integrations, and operational efficiency.

Many of these settings become increasingly valuable as deployments grow beyond a few dozen endpoints.

Configure Agent Groups for Large Environments

Large deployments often contain multiple server roles, operating systems, business units, and geographical locations.

Rather than managing every endpoint individually, administrators can use agent groups to apply consistent policies across entire categories of systems.

Examples include:

Production servers
Development environments
Domain controllers
Database servers
Cloud workloads
Remote offices

This simplifies administration while reducing configuration drift.

Configure Labels and Metadata

Labels provide additional context that makes searching, filtering, and reporting much easier.

Organizations commonly assign metadata such as:

Environment (Production, Test, Development)
Business unit
Geographic region
Asset owner
Criticality
Compliance scope
Server role

This metadata allows analysts to quickly isolate affected systems during investigations.

Configure Cluster Settings

Single-node deployments work well for smaller organizations, but enterprise environments often require clustering to improve scalability and resilience.

Cluster configuration includes:

Manager nodes
Worker nodes
Synchronization
High availability
Load balancing
Fault tolerance

Proper cluster design improves uptime while supporting thousands of monitored endpoints.

If you’re planning to scale your deployment, see:

How to Build a Wazuh Indexer Cluster

Configure Remote Commands

Wazuh supports securely executing predefined commands on monitored endpoints.

Common use cases include:

Collecting diagnostic information
Running maintenance scripts
Gathering forensic artifacts
Triggering custom automation
Supporting incident response workflows

Because remote command execution introduces additional risk, organizations should enable it only when necessary and restrict usage through strong access controls.

Configure Integrations

Wazuh becomes significantly more powerful when integrated with other security platforms.

Common integrations include:

Slack

Send high-priority alerts directly to security teams for faster response.

If you’re troubleshooting notification issues, see:

Fix Wazuh Slack Webhook Errors: Curl 52 Empty Reply

Microsoft Teams

Deliver security notifications into collaboration channels where analysts already work.

Webhooks

Forward alerts to:

Ticketing systems
SOAR platforms
Incident management tools
Custom automation platforms

Threat Intelligence Feeds

Enrich alerts using external threat intelligence sources.

Examples include:

VirusTotal
Commercial reputation services
Open-source intelligence feeds

Additional integration tutorials:

Configure API Access

The Wazuh API enables automation, reporting, and third-party integrations.

Proper API configuration improves both security and operational efficiency.

Authentication

Always require secure authentication for API access.

Avoid anonymous or overly permissive configurations.

Tokens

Use API tokens or other supported authentication mechanisms instead of embedding administrator credentials within automation scripts.

Rotate credentials regularly and revoke unused tokens promptly.

Permissions

Follow role-based access principles by granting applications only the permissions they require.

Restrict administrative operations whenever possible.

Tune Detection Performance

As deployments expand, optimizing detection performance becomes increasingly important.

Reduce False Positives

Fine-tuning rules improves alert quality by suppressing known benign activity while preserving meaningful detections.

Useful resources include:

How to Reduce False Positives in Wazuh

Reduce Duplicate Alerts

Duplicate alerts increase analyst workload without improving security.

Common techniques include:

Event correlation
Rule tuning
Frequency thresholds
Alert suppression
Improved decoder logic

Optimize Rule Evaluation

Efficient rule design helps improve manager performance.

Best practices include:

Writing specific matching conditions
Avoiding unnecessary regular expressions
Reusing existing rules where possible
Maintaining clean rule hierarchies
Periodically reviewing unused custom rules

The Open Worldwide Application Security Project (OWASP) recommends continuously tuning security monitoring systems to improve signal quality while minimizing operational overhead.

Common Wazuh Configuration Mistakes

Even experienced administrators occasionally make configuration mistakes that reduce detection quality, introduce unnecessary downtime, or complicate troubleshooting.

Understanding these common pitfalls can help you build a more stable and maintainable Wazuh deployment.

Editing Default Rules Instead of Local Rules

One of the most common mistakes is modifying Wazuh’s built-in rule files.

Although this may seem convenient, updates can overwrite these changes during upgrades.

Instead:

Leave default rules untouched.
Store custom detections in local rule files.
Document every customization.

This approach simplifies upgrades while preserving your work.

Forgetting to Restart Services

Configuration changes are not always applied immediately.

After modifying:

Rules
Decoders
Integrations
Manager settings
Agent configurations

restart or reload the appropriate services so the changes take effect.

Failure to do so often leads administrators to believe their configuration is incorrect when the new settings simply have not been loaded.

Ignoring Configuration Validation

Small syntax errors, especially within XML files, can prevent services from starting correctly.

Always validate configuration changes before restarting production services.

Taking a few extra minutes to verify syntax can prevent lengthy troubleshooting sessions later.

Applying Changes Directly in Production

Making untested configuration changes directly on production systems increases operational risk.

Instead:

Test changes in staging.
Validate rule behavior.
Review performance.
Confirm integrations.
Deploy gradually when possible.

Controlled deployments significantly reduce the likelihood of unexpected outages.

Overusing Active Response

Automated remediation can dramatically reduce response times, but excessive automation can also disrupt legitimate business activity.

Avoid enabling Active Response for:

Low-confidence detections
Noisy rules
Untested custom detections

Start with monitoring mode and gradually automate only high-confidence events.

Creating Duplicate Rules

As rule libraries grow, duplicate or overlapping rules become increasingly common.

Duplicate detections may produce:

Multiple alerts for one event
Increased CPU usage
Alert fatigue
Confusing investigations

Regular rule reviews help eliminate unnecessary overlap.

Poor Agent Organization

Managing hundreds of endpoints without agent groups quickly becomes difficult.

Symptoms include:

Inconsistent configurations
Forgotten endpoints
Manual updates
Configuration drift

Organizing systems by role, operating system, or business function simplifies long-term administration.

Misconfigured Log Sources

Detection quality depends entirely on the quality of collected data.

Common logging mistakes include:

Monitoring the wrong log files
Missing Windows Event channels
Disabled Syslog forwarding
Incorrect file permissions
Invalid log paths
Missing custom application logs

Regularly reviewing log coverage helps ensure that important security events are not overlooked.

The Center for Internet Security (CIS) emphasizes maintaining complete and accurate log collection as a foundational cybersecurity control because organizations cannot detect threats that are never recorded.

Wazuh Configuration Workflow for Production

Configuring Wazuh in a production environment requires a disciplined workflow.

Because Wazuh is highly configurable and tightly integrated across multiple components, even small changes can impact log ingestion, alert generation, or system stability.

A structured workflow ensures changes are predictable, testable, and reversible.

Plan Configuration Changes

Before editing any configuration file, clearly define:

What you are changing
Why the change is necessary
Which component is affected
Expected impact on alerts or performance
Potential risks or side effects

Planning reduces accidental misconfigurations and helps ensure that changes align with security objectives.

Back Up Existing Files

Always create backups of configuration files before modification.

This includes:

Manager configuration (ossec.conf)
Rule files
Decoder files
Agent configurations
Cluster settings

Backups allow you to quickly restore a working state if a change causes service disruption or unexpected behavior.

Apply Configuration

Once changes are planned and backed up, apply updates carefully.

Best practices include:

Making small, incremental changes
Avoiding multiple unrelated edits at once
Using version control where possible
Documenting each modification

This reduces complexity during troubleshooting.

Validate XML Syntax

Wazuh relies heavily on XML-based configuration files. Even minor syntax errors can prevent services from starting or cause silent misconfigurations.

Always validate:

Tag structure
Nested elements
Closing tags
Attribute formatting

If XML validation fails, correct errors before proceeding.

Restart Services

After applying and validating configuration changes, restart the affected Wazuh services.

Depending on the change, this may include:

Wazuh manager
Wazuh agent
Filebeat
Wazuh indexer
Dashboard

Restarting ensures the system loads the updated configuration.

Test Configuration

After services are restarted, verify that changes behave as expected.

Testing includes:

Confirming log ingestion
Triggering sample alerts
Validating rule execution
Checking Active Response behavior
Reviewing dashboard visibility

For rule-specific validation, see:

How to Test Wazuh Rules

Monitor Results

After deployment, continuously monitor system behavior.

Key indicators include:

Alert volume changes
CPU and memory usage
Log ingestion rates
Indexer performance
Agent connectivity status

Monitoring ensures that configuration changes do not introduce unintended side effects.

Roll Back if Necessary

If issues arise, revert to the previous stable configuration immediately.

Rollback strategies include:

Restoring backup files
Reverting version-controlled changes
Disabling problematic rules or integrations
Restarting services after rollback

A fast rollback process minimizes downtime and reduces operational risk.

Wazuh Configuration Checklist

Before considering a Wazuh deployment production-ready, verify that all critical configuration areas are properly implemented and tested.

Configuration backed up

Ensure all key configuration files are safely backed up or version-controlled.

XML validated

Confirm that all configuration files pass XML validation without errors.

Services restarted

Verify that all required services have been restarted after changes.

Agents connected

Confirm that all expected agents are connected to the manager and reporting correctly.

Logs collected

Ensure that all required log sources are actively being ingested.

FIM enabled where required

File Integrity Monitoring should be enabled for critical systems and directories.

See:

How to Configure File Integrity Monitoring (FIM) in Wazuh

Active Response tested

Validate that automated response actions execute correctly and safely.

See:

How to Configure Wazuh Active Response

Custom rules validated

Ensure custom detection rules have been tested and do not generate excessive false positives.

Rule testing completed

Confirm all new or modified rules have been validated using testing tools.

See:

How to Test Wazuh Rules

Syslog sources verified

Ensure all network devices, firewalls, and external systems are forwarding logs correctly.

See:

How to Configure Wazuh as a Centralized Syslog Server

Log retention configured

Confirm retention policies are properly defined and aligned with compliance requirements.

See:

How to Configure Wazuh Log Retention

Alerts reviewed

Check that alerts are meaningful, properly categorized, and not generating excessive noise.

Documentation updated

Ensure all configuration changes are documented, including:

What was changed
Why it was changed
Who approved it
When it was deployed

Proper documentation simplifies future troubleshooting and audits.

Frequently Asked Questions (FAQ)

Question: Where are Wazuh configuration files located?

Wazuh configuration files are typically located under the /var/ossec/etc/ directory on Linux systems. Key files include ossec.conf, rule files, and decoder files. Agent configurations are also stored locally on each endpoint.

Question: Do I need to restart Wazuh after changing the configuration?

Yes. Most configuration changes require restarting or reloading the affected services, such as the Wazuh manager, agents, or related components, for changes to take effect.

Question: Can I manage multiple agents with one configuration?

Yes. Wazuh supports centralized configuration management using agent groups. This allows you to apply consistent settings across multiple endpoints without manually configuring each one.

Question: Should I edit default Wazuh rules?

No. Default rules should not be modified. Instead, create custom rules in local rule files to ensure changes are preserved during upgrades.

Question: How do I validate my Wazuh configuration?

You can validate configuration files using XML validation tools and Wazuh’s built-in testing utilities. Always validate before restarting services to avoid startup failures.

Question: Why are my configuration changes not taking effect?

This usually occurs when services have not been restarted after changes, or when configuration files contain syntax errors that prevent proper loading.

Question: Can I configure Wazuh without editing XML manually?

Some configurations can be managed through the Wazuh dashboard or APIs, but advanced configuration still typically requires direct XML file editing.

Question: How often should I review my Wazuh configuration?

Configuration should be reviewed regularly, typically during system upgrades, infrastructure changes, or when tuning detection rules and log sources. Many organizations also perform quarterly audits.

Conclusion

Key Takeaways

Proper Wazuh configuration is the foundation of an effective security monitoring and detection system.

While installation gets the platform running, configuration determines how well it performs in real-world conditions.

Key points to remember:

Proper configuration determines how effectively Wazuh detects, correlates, and responds to security events.
Start with core configurations such as log collection, agent groups, and alert tuning before enabling advanced features.
Always validate and test configuration changes before deploying them to production environments.
Use custom detection rules, Active Response, and centralized Syslog to significantly enhance visibility and response capabilities.
Follow a structured workflow and maintain backups to reduce operational risk.
Continuously refine and expand your configuration as your infrastructure evolves.

Wazuh becomes significantly more powerful when configured correctly, transforming it from a basic monitoring tool into a full-scale security operations platform.

To continue building your deployment, explore the detailed cluster guides linked throughout this pillar page for step-by-step configuration instructions across all major Wazuh components.