How to Configure Wazuh as a Centralized Syslog Server

Organizations generate enormous volumes of log data every day from servers, firewalls, routers, applications, cloud platforms, and security tools.

Without a centralized system for collecting and analyzing these logs, identifying security threats, troubleshooting issues, and maintaining compliance becomes increasingly difficult.

This is where a centralized syslog server becomes essential.

What Is a Centralized Syslog Server?

A centralized syslog server is a system that receives, stores, and analyzes log messages from multiple devices and applications across an organization’s infrastructure.

Instead of reviewing logs individually on each device, administrators can collect all events in a single location for monitoring, analysis, and long-term retention.

Syslog is a standardized logging protocol supported by a wide range of operating systems, network devices, security appliances, and enterprise applications.

Devices generate syslog messages and forward them to a centralized server where they can be searched, correlated, and analyzed.

In modern IT environments, centralized syslog collection is commonly used for:

• Security monitoring and threat detection
• Compliance reporting and auditing
• Infrastructure troubleshooting
• Performance monitoring
• Incident investigations
• Operational visibility across distributed environments

Why Use Wazuh as a Syslog Server?

Wazuh is an open-source security platform that combines Security Information and Event Management (SIEM) and Extended Detection and Response (XDR) capabilities into a single solution.

Unlike traditional syslog servers that simply collect logs, Wazuh analyzes events in real time and generates actionable security alerts.

Organizations choose Wazuh as a centralized syslog server because it provides:

• Centralized visibility across servers, endpoints, applications, and network devices
• Real-time threat detection and alerting
• Built-in log analysis and correlation
• Compliance monitoring capabilities
• Scalable log storage and search functionality
• No licensing costs associated with commercial SIEM platforms

According to the 2024 Verizon Data Breach Investigations Report, log analysis and monitoring remain critical components of detecting unauthorized access and security incidents.

Centralizing syslog data enables organizations to identify suspicious activity more quickly and improve incident response times.

Benefits of Centralizing Syslog Data with Wazuh

Centralizing syslog data within Wazuh provides several operational and security advantages.

Simplified Log Management

Administrators can manage logs from hundreds or thousands of devices through a single platform instead of accessing each system individually.

Faster Incident Detection and Response

Wazuh continuously analyzes incoming syslog events and generates alerts when suspicious activity is detected.

This reduces the time required to identify and investigate security incidents.

Improved Troubleshooting and Root Cause Analysis

Centralized logs make it easier to correlate events across multiple systems and identify the source of application failures, network outages, or security issues.

Long-Term Log Retention and Searchability

Wazuh stores logs within the Indexer, allowing security teams to perform historical searches and forensic investigations long after events occur.

What You Will Learn

In this guide, you will learn:

• How Wazuh receives and processes syslog data
• How to configure Wazuh to act as a centralized syslog server
• How to onboard devices and applications that support syslog
• How to verify log ingestion and troubleshoot connectivity issues
• How to create alerts and dashboards from collected syslog events

If you’re already collecting logs from specific systems, you may also find these guides useful:

• How to Collect Firewall Logs in Wazuh
• How to Monitor Apache Logs with Wazuh
• How to Monitor Windows Event Logs Using Wazuh

Understanding How Wazuh Processes Syslog Logs

Before configuring Wazuh as a syslog server, it is important to understand how syslog messages flow through the platform and how they are analyzed.

Overview of the Wazuh Logging Architecture

Wazuh consists of three primary components that work together to collect, process, store, and visualize syslog data:

• Wazuh Manager
• Wazuh Indexer
• Wazuh Dashboard

Each component plays a specific role in the logging pipeline.

Wazuh Manager

The Wazuh Manager is responsible for receiving and analyzing incoming syslog messages.

Role in Log Collection and Analysis

When a syslog-enabled device sends an event to Wazuh, the Manager receives the message and processes it through its analysis engine.

The Manager can accept logs from:

• Routers
• Switches
• Firewalls
• Linux servers
• Windows systems
• Security appliances
• Applications and services

Decoding and Rule Matching

After receiving a log event, Wazuh applies decoders to extract meaningful fields from the message.

The decoded data is then compared against built-in and custom detection rules. If a rule matches, Wazuh generates an alert with an associated severity level.

Organizations can extend this functionality using custom rules as discussed in:

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

Wazuh Indexer

The Wazuh Indexer stores processed events and enables rapid searching and analysis.

Log Storage and Indexing

Incoming alerts and log events are indexed for efficient storage and retrieval.

This allows organizations to retain large volumes of historical data while maintaining fast search performance.

Search and Analytics Capabilities

The Indexer enables users to:

• Search historical logs
• Filter events by source or severity
• Perform threat hunting activities
• Investigate security incidents
• Generate reports and dashboards

Organizations deploying large environments often improve performance and scalability through clustering.

Related Guide: 

How to Build a Wazuh Indexer Cluster

Wazuh Dashboard

The Wazuh Dashboard provides the graphical interface used to monitor and investigate syslog events.

Visualization and Investigation Tools

Security teams can:

• Search logs
• Review alerts
• Build dashboards
• Analyze trends
• Investigate incidents

Security Monitoring Workflows

The Dashboard allows analysts to quickly move from alert detection to root cause analysis by correlating events across multiple log sources.

Supported Syslog Sources

One of the biggest advantages of Wazuh is its ability to ingest logs from virtually any device or application that supports syslog.

Network Devices

Common network devices include:

Routers

Router logs can provide visibility into routing changes, interface issues, and network connectivity events.

Switches

Switch logs help identify VLAN changes, port activity, and configuration modifications.

Firewalls

Firewall logs provide valuable security telemetry including denied connections, intrusion attempts, and traffic patterns.

Wireless Controllers

Wireless infrastructure can send authentication events, rogue device detections, and client connection information.

Operating Systems

Linux Servers

Linux systems commonly forward authentication logs, system events, application logs, and audit data through syslog.

Unix Systems

Traditional Unix environments often rely heavily on syslog for centralized event management.

Windows Systems Using Syslog Agents

Although Windows does not natively support syslog, third-party agents can forward Windows Event Logs to Wazuh.

For more information:

How to Monitor Windows Event Logs Using Wazuh

Applications and Services

Web Servers

Web servers such as Apache and Nginx can forward access and error logs to Wazuh.

Databases

Database platforms can send authentication events, query logs, and operational alerts.

Security Appliances

IDS, IPS, antivirus platforms, and endpoint protection solutions frequently support syslog integration.

Cloud Services

Cloud platforms can forward audit logs and security events for centralized monitoring.

For AWS environments:

How to Monitor AWS CloudTrail Logs Using Wazuh

Syslog Protocol Basics

Syslog supports multiple transport methods and message formats.

UDP vs TCP Syslog

The two most common syslog transport protocols are UDP and TCP.

Reliability Differences

UDP does not guarantee message delivery and may drop packets during network congestion.

TCP provides reliable delivery through acknowledgments and retransmissions.

Performance Considerations

UDP generally requires fewer resources and is easier to deploy.

TCP introduces additional overhead but offers significantly better reliability.

Recommended Deployment Scenarios

UDP is commonly used for:

• Internal network devices
• High-volume environments
• Non-critical logs

TCP is recommended for:

• Security logs
• Compliance-related logging
• Critical infrastructure

The official Syslog protocol standard published by the Internet Engineering Task Force recommends reliable transport mechanisms when log integrity is important.

Common Syslog Ports

Port 514 UDP

The traditional syslog port used by most network devices and legacy systems.

Port 514 TCP

A more reliable transport option used by many modern syslog implementations.

Custom Syslog Ports

Organizations frequently deploy custom ports to meet security requirements or avoid conflicts with existing services.

Syslog Message Structure

A typical syslog message contains several key components.

Priority Value

Indicates the facility and severity level of the event.

Timestamp

Records when the event occurred.

Hostname

Identifies the device that generated the message.

Program Name

Specifies the application or service responsible for the event.

Message Content

Contains the actual log data that Wazuh analyzes and stores.

Prerequisites

Before configuring Wazuh as a centralized syslog server, ensure your environment meets the following requirements.

Wazuh Deployment Requirements

You should have a fully operational Wazuh deployment that includes:

Installed Wazuh Manager

The Manager must be installed and functioning correctly because it will receive incoming syslog messages.

Working Wazuh Indexer

The Indexer should be operational and capable of storing incoming events.

Accessible Wazuh Dashboard

The Dashboard should be accessible for verifying log ingestion and monitoring alerts.

Network Requirements

Proper network connectivity is essential for successful syslog collection.

Firewall Configuration

Firewalls between log sources and the Wazuh Manager must allow syslog traffic.

Open Syslog Ports

Ensure the required syslog ports are open and reachable from sending devices.

Connectivity Validation

Verify that network routes and firewall policies permit communication between all log sources and the Wazuh server.

Administrative Access Requirements

Root or Sudo Access

Administrative privileges are required to modify Wazuh configuration files and restart services.

Access to Sending Devices

You will need administrative access to routers, firewalls, servers, applications, and other systems that will forward logs to Wazuh.

Configuring Wazuh to Receive Syslog Messages

With the prerequisites in place, the next step is configuring the Wazuh Manager to receive syslog messages from external devices and applications.

Wazuh supports direct syslog ingestion, allowing it to act as a centralized syslog server for your entire infrastructure.

Step 1: Edit the Wazuh Manager Configuration

The syslog listener is configured within the Wazuh Manager’s primary configuration file.

Locate the ossec.conf File

Depending on your deployment, the configuration file is typically located at:

/var/ossec/etc/ossec.conf

You can open the file using your preferred text editor:

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

Default Configuration Locations

For standard Wazuh installations:

Backup Recommendations

Before making any modifications, create a backup of the existing configuration:

sudo cp /var/ossec/etc/ossec.conf /var/ossec/etc/ossec.conf.bak

This allows you to quickly restore the original configuration if needed.

Configure Remote Syslog Collection

To enable Wazuh to receive syslog messages, add or modify a <remote> block within the configuration file.

Example configuration:

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>192.168.1.0/24</allowed-ips>
  <queue_size>131072</queue_size>
</remote>

This configuration tells Wazuh to:

• Enable remote syslog collection
• Listen for incoming syslog messages
• Use UDP transport
• Accept messages from approved sources
• Allocate sufficient buffering capacity

Example Configuration Overview

Enable Remote Logging

The connection parameter enables syslog reception.

<connection>syslog</connection>

Without this setting, Wazuh will not listen for incoming syslog traffic.

Define Protocol

You can choose either UDP or TCP.

UDP example:

<protocol>udp</protocol>

TCP example:

<protocol>tcp</protocol>

TCP is generally recommended for critical security logs because it provides delivery guarantees.

Specify Listening Port

The standard syslog port is 514.

<port>514</port>

Organizations may also use custom ports such as 1514 or 5514 to meet security or operational requirements.

Configure Allowed Sources

Restrict which devices can submit logs.

<allowed-ips>192.168.1.0/24</allowed-ips>

You can specify:

<allowed-ips>10.0.0.10</allowed-ips>

for a single device or

<allowed-ips>10.0.0.0/24</allowed-ips>

for an entire subnet.

Restricting log sources helps prevent unauthorized systems from sending events.

Understanding Configuration Parameters

The syslog listener relies on several important parameters.

connection

Determines the type of remote connection.

<connection>syslog</connection>

For syslog collection, this value must be set to syslog.

port

Defines the port Wazuh listens on.

<port>514</port>

The chosen port must match the configuration on sending devices.

protocol

Specifies whether the listener uses UDP or TCP.

<protocol>udp</protocol>

or

<protocol>tcp</protocol>

TCP provides greater reliability, while UDP offers lower overhead.

queue_size

Controls how many events can be buffered during high-volume ingestion.

Example:

<queue_size>131072</queue_size>

Increasing queue size can help prevent event loss during bursts of syslog activity from busy devices such as firewalls and IDS platforms.

If you’re collecting logs from perimeter devices, you may also want to review:

 How to Collect Firewall Logs in Wazuh

Step 2: Restart Wazuh Services

After modifying the configuration, restart the Wazuh Manager so the changes take effect.

Restart the Wazuh Manager

Use the following command:

sudo systemctl restart wazuh-manager

On systems using older service managers:

sudo service wazuh-manager restart

The restart process loads the updated syslog listener configuration.

Verify Service Status

Confirm that the Manager started successfully.

Service Validation Commands

Check service status:

sudo systemctl status wazuh-manager

Example output:

Active: active (running)

You can also verify with:

sudo systemctl is-active wazuh-manager

Expected result:

active

Confirm Successful Startup

A successful startup indicates that:

• The configuration file contains valid syntax
• The configured syslog port is available
• Wazuh successfully initialized the listener

Check for Configuration Errors

If the service fails to start, review the logs immediately.

Reviewing Wazuh Logs

Inspect the manager log:

sudo tail -f /var/ossec/logs/ossec.log

Or search for startup-related messages:

grep ERROR /var/ossec/logs/ossec.log

Troubleshooting Startup Issues

Common issues include:

• Invalid XML syntax
• Missing closing tags
• Port conflicts
• Invalid IP ranges
• Unsupported configuration values
• Insufficient permissions

Many configuration problems can be identified directly from the startup logs.

If you encounter broader deployment issues, see:

Wazuh Agent Not Connecting to Manager? 12 Proven Fixes

How to Fix Wazuh Certificate Errors

Step 3: Verify Listening Ports

Once the Manager is running, verify that Wazuh is actively listening for syslog traffic.

Confirm Syslog Listener Is Active

The operating system should show Wazuh listening on the configured port.

Using Netstat or SS Commands

Using ss:

sudo ss -tulpn | grep 514

Example UDP output:

udp UNCONN 0 0 0.0.0.0:514

Example TCP output:

tcp LISTEN 0 128 0.0.0.0:514

Using netstat:

sudo netstat -tulpn | grep 514

If no listener appears, recheck the Wazuh configuration and restart the service.

Testing Connectivity

After confirming the listener is active, test communication from a remote device.

Linux systems can generate a test message using:

logger -n <WAZUH_SERVER_IP> -P 514 "Wazuh syslog test"

For TCP:

logger --tcp -n <WAZUH_SERVER_IP> -P 514 "Wazuh syslog test"

If successful, the event should appear in the Wazuh Dashboard within a few seconds.

Configuring Syslog Clients

With Wazuh ready to receive events, you can begin configuring devices and applications to forward logs.

Sending Syslog Logs from Linux Systems

Linux distributions commonly use either rsyslog or syslog-ng.

Using rsyslog

rsyslog is the default logging daemon on many Linux distributions including Ubuntu, Debian, Red Hat, Rocky Linux, and CentOS.

Configure Forwarding Rules

Create a forwarding configuration:

sudo nano /etc/rsyslog.d/60-wazuh.conf

For UDP forwarding:

*.* @192.168.1.100:514

For TCP forwarding:

*.* @@192.168.1.100:514

Where:

• @ = UDP
• @@ = TCP

This configuration forwards all log messages to the Wazuh server.

Restart rsyslog Service

Apply the changes:

sudo systemctl restart rsyslog

Verify the service is running:

sudo systemctl status rsyslog

Verify Log Transmission

Generate a test event:

logger "Testing Wazuh syslog forwarding"

The event should appear within Wazuh shortly afterward.

Using syslog-ng

Some Linux environments use syslog-ng instead of rsyslog.

Configure Destination Server

Edit the syslog-ng configuration:

sudo nano /etc/syslog-ng/syslog-ng.conf

Add a destination block:

destination d_wazuh {
  udp("192.168.1.100" port(514));
};

For TCP:

destination d_wazuh {
  tcp("192.168.1.100" port(514));
};

Forward Logs to Wazuh

Create a log path:

log {
  source(s_src);
  destination(d_wazuh);
};

Restart syslog-ng:

sudo systemctl restart syslog-ng

Generate a test message and confirm that it appears in the Wazuh Dashboard.

For Linux log monitoring best practices, see:

How to Add Linux Endpoints to Wazuh

Sending Syslog Logs from Network Devices

Network devices often generate valuable security and operational logs.

Centralizing these events in Wazuh provides visibility into network activity, configuration changes, and potential security incidents.

Cisco Devices

Cisco routers and switches support native syslog forwarding.

Configure Syslog Destination

Enter global configuration mode:

configure terminal

Specify the Wazuh syslog server:

logging host 192.168.1.100

If using TCP syslog on supported platforms:

logging host tcp://192.168.1.100

Set Logging Severity Levels

Configure the desired logging level:

logging trap informational

Common severity levels include:

Most organizations choose informational or warnings for production environments.

Verify Transmission

Verify the configuration:

show logging

Generate activity on the device and confirm events arrive in Wazuh.

Fortinet Firewalls

Fortinet devices can send traffic, security, and administrative logs via syslog.

Configure Remote Logging

Navigate to:

Log & Report → Log Settings

Enable Remote Syslog and specify:

• Wazuh server IP
• Port 514
• UDP or TCP transport

Select Log Categories

Recommended log categories include:

• Traffic logs
• Event logs
• Security logs
• VPN logs
• Administrator activity
• Intrusion prevention events

These logs provide excellent visibility into network threats and policy violations.

pfSense Firewalls

pfSense includes built-in remote syslog support.

Enable Remote Syslog Export

Navigate to:

Status → System Logs → Settings

Enable:

Send log messages to remote syslog server

Configure Wazuh Destination

Specify:

Server IP: 192.168.1.100
Port: 514
Protocol: UDP or TCP

Select the log categories to export:

• Firewall events
• DHCP logs
• VPN logs
• DNS Resolver logs
• System events

For additional firewall monitoring guidance, see:

How to Collect Firewall Logs in Wazuh

Sending Logs from Applications

In addition to operating systems and network devices, many applications can send logs directly to a centralized syslog server.

Apache Web Server

Apache commonly logs:

• HTTP requests
• Authentication events
• Access attempts
• Server errors

On Linux systems, Apache logs can be forwarded through rsyslog or syslog-ng after configuring the web server to use syslog-compatible logging.

Common Apache log locations include:

/var/log/apache2/access.log
/var/log/apache2/error.log

Organizations frequently centralize these logs to detect suspicious web activity and attack attempts.

See our How to Monitor Apache Logs with Wazuh guide.

Nginx

Nginx access and error logs can also be forwarded through your Linux logging service.

Common locations:

/var/log/nginx/access.log
/var/log/nginx/error.log

These logs provide visibility into:

• Client requests
• HTTP status codes
• Authentication failures
• Application errors
• Potential attack activity

MySQL

Database logs often contain valuable operational and security information.

Common MySQL logs include:

• Error logs
• General query logs
• Slow query logs
• Audit logs

Typical locations:

/var/log/mysql/error.log
/var/log/mysql/mysql.log

Forwarding these logs enables centralized monitoring of database issues and suspicious activity.

Custom Applications

Many modern applications support direct syslog output.

Common examples include:

• Java applications
• Python applications
• Go services
• Containers
• Security tools
• Internal business applications

Developers can configure their applications to send events directly to the Wazuh syslog listener using standard syslog libraries and frameworks.

Verifying Syslog Events in Wazuh

Once clients begin forwarding logs, verify that Wazuh is receiving, processing, and analyzing the events correctly.

Checking Incoming Logs

Several Wazuh log files can help confirm successful ingestion.

Monitor archives.log

The archives log contains raw events received by Wazuh.

Monitor it in real time:

sudo tail -f /var/ossec/logs/archives/archives.log

If messages appear here, Wazuh is successfully receiving syslog traffic.

Monitor alerts.json

Alerts generated by Wazuh rules are stored in:

sudo tail -f /var/ossec/logs/alerts/alerts.json

Events appearing here indicate that:

• The log was received
• A decoder processed it
• A rule matched the event

Review ossec.log

The manager log contains operational details.

View recent messages:

sudo tail -f /var/ossec/logs/ossec.log

Use this file to troubleshoot:

• Listener startup issues
• Decoder problems
• Rule processing errors
• Communication failures

Using the Wazuh Dashboard

The Dashboard provides the easiest way to validate incoming syslog data.

Search for Incoming Syslog Events

Navigate to:

Security Events

Search for:

agent.name: "000"

Many syslog events received directly by the Manager are associated with the manager itself rather than a specific agent.

Filter by Source Host

Use filters such as:

data.hostname

or

location

to identify events from specific devices.

Examples:

data.hostname:"firewall01"

data.hostname:"router01"

Analyze Event Details

Review:

• Source IP address
• Hostname
• Severity
• Rule ID
• Timestamp
• Decoder information

This information helps verify that Wazuh is correctly parsing incoming logs.

Create Saved Searches

Once verification is complete, create saved searches for frequently monitored devices.

Examples include:

• Firewalls
• VPN appliances
• Linux servers
• Web servers
• Database servers

Saved searches streamline ongoing monitoring and incident investigations.

For environments requiring custom detection logic, consider creating dedicated rules for important syslog sources.

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

Creating Custom Decoders for Syslog Data

While Wazuh includes hundreds of built-in decoders for common operating systems, applications, and network devices, there are situations where custom decoders are necessary.

Creating custom decoders allows Wazuh to properly parse unique log formats and extract meaningful fields for alerting and investigation.

Why Custom Decoders May Be Required

Not every syslog source follows a standard format.

Custom decoders help Wazuh understand logs that would otherwise be treated as unstructured text.

Vendor-Specific Log Formats

Many vendors use proprietary log formats that differ from traditional syslog standards.

Examples include:

• Specialized firewalls
• Industrial control systems
• Network monitoring appliances
• Security gateways
• Custom network hardware

Without a decoder, Wazuh may receive the log but fail to extract useful information.

Proprietary Applications

Commercial applications often generate unique log formats containing:

• User activity
• Authentication events
• Application errors
• Transaction details
• Security events

Custom decoders allow these fields to become searchable and usable within detection rules.

Custom Services

Organizations frequently develop internal applications that generate custom logs.

Examples include:

• Internal web applications
• Business process platforms
• Custom APIs
• Microservices
• Automation systems

Creating decoders ensures these logs can participate in security monitoring workflows.

Understanding Wazuh Decoders

Decoders are responsible for extracting structured data from incoming log messages.

Decoder Structure

A decoder typically contains:

• Decoder name
• Parent relationship (optional)
• Matching criteria
• Regular expressions
• Extracted field mappings

Basic example:

<decoder name="custom-app">
  <prematch>CustomApp:</prematch>
</decoder>

Parent and Child Decoders

Wazuh supports hierarchical decoding.

Parent Decoder

The parent identifies the general log type.

Example:

<decoder name="custom-app">
  <prematch>CustomApp:</prematch>
</decoder>

Child Decoder

The child extracts specific fields.

Example:

<decoder name="custom-app-fields">
  <parent>custom-app</parent>
  <regex>User=(\S+) Action=(\S+)</regex>
  <order>username,action</order>
</decoder>

This structure improves performance and organization when processing large numbers of logs.

Regular Expression Matching

Most custom decoders rely on regular expressions.

Example log:

CustomApp: User=jdoe Action=login

Regular expression:

User=(\S+) Action=(\S+)

Extracted fields:

Accurate regex patterns are essential for successful field extraction.

Creating a Custom Decoder

Custom decoders are typically stored within:

/var/ossec/etc/decoders/local_decoder.xml

Define the Decoder

Example:

<decoder name="custom-login">
  <prematch>MyApp:</prematch>
</decoder>

<decoder name="custom-login-fields">
  <parent>custom-login</parent>
  <regex>User=(\S+) Status=(\S+)</regex>
  <order>username,status</order>
</decoder>

This decoder extracts usernames and authentication status values.

Test the Decoder

Use the Wazuh log testing utility:

/var/ossec/bin/wazuh-logtest

Paste a sample log:

MyApp: User=admin Status=failed

Wazuh should display the extracted fields.

Validate Extracted Fields

Confirm that:

• The decoder matches the log
• Fields are extracted correctly
• Data appears within the event
• Values are available for rule creation

For a deeper walkthrough of custom parsing, see:

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

Creating Detection Rules for Syslog Events

Once Wazuh successfully parses incoming syslog data, the next step is creating detection rules that generate alerts when specific conditions occur.

How Wazuh Rules Work

Rules analyze decoded log events and determine whether they represent noteworthy activity.

Rule Matching Process

The process follows three stages:

1. Receive the syslog event.
2. Apply decoders.
3. Compare extracted fields against rules.

When a rule matches, Wazuh generates an alert.

Severity Levels

Every Wazuh rule contains a severity level ranging from 0 to 15.

Common severity categories include:

Proper severity classification helps security teams prioritize investigations.

Alert Generation

When a rule matches:

• An alert is generated
• The alert appears in alerts.json
• The event becomes visible in the Dashboard
• Dashboards and saved searches update automatically

Building Custom Rules

Custom rules are typically stored in:

/var/ossec/etc/rules/local_rules.xml

Detect Failed Login Attempts

Example rule:

<group name="custom-authentication">

  <rule id="100500" level="8">
    <field name="status">failed</field>
    <description>Custom application login failure</description>
  </rule>

</group>

This rule generates an alert whenever a failed login is detected.

Related guide:

How to Monitor Failed SSH Login Attempts Using Wazuh

Detect Firewall Deny Events

Example:

<rule id="100501" level="7">
  <match>deny</match>
  <description>Firewall denied connection</description>
</rule>

This helps identify blocked network activity.

Related guide:

How to Collect Firewall Logs in Wazuh

Detect Configuration Changes

Example:

<rule id="100502" level="10">
  <match>configuration changed</match>
  <description>Device configuration modification detected</description>
</rule>

Configuration changes often warrant elevated attention because they may indicate unauthorized activity.

Detect Service Failures

Example:

<rule id="100503" level="6">
  <match>service failed</match>
  <description>Service failure detected</description>
</rule>

Service monitoring alerts help identify operational problems before they affect users.

Testing Rules

Always validate new rules before deploying them into production.

Generate Test Events

Launch the testing utility:

/var/ossec/bin/wazuh-logtest

Paste a sample log that should trigger the rule.

Verify Alert Creation

Confirm:

• The decoder matches
• The rule triggers
• The correct severity appears
• The alert is written to alerts.json
• The event appears in the Dashboard

Thorough testing minimizes false positives and missed detections.

Related guide:

How to Test Wazuh Rules

Building Dashboards for Syslog Monitoring

Collecting syslog data is only part of the solution.

Dashboards transform raw events into actionable insights that help security teams monitor activity, identify threats, and investigate incidents more efficiently.

Creating Syslog Dashboards

The Wazuh Dashboard allows users to build custom visualizations using indexed syslog data.

Common dashboard categories include:

Log Volume Dashboard

A log volume dashboard helps answer questions such as:

• How many events are being generated?
• Which systems generate the most logs?
• Are log volumes increasing unexpectedly?

Useful metrics include:

• Events per minute
• Events per hour
• Events by source
• Events by device type

Sudden spikes can indicate attacks, outages, or configuration changes.

Security Event Dashboard

Security-focused dashboards help identify threats and suspicious activity.

Common visualizations include:

• Failed login attempts
• Firewall denies
• Malware detections
• IDS alerts
• Authentication anomalies
• Privilege escalation events

If you integrate additional security tools, consider:

How to Integrate Wazuh with Suricata for Better Threat Detection

Device Health Dashboard

Operational monitoring dashboards provide visibility into infrastructure health.

Useful metrics:

• Device uptime
• Error events
• Service failures
• Resource-related alerts
• Connectivity issues

These dashboards help operations teams quickly identify failing systems.

Authentication Monitoring Dashboard

Authentication events are among the most important log sources.

Track:

• Successful logins
• Failed logins
• Privileged account usage
• Authentication failures by host
• Suspicious login activity

Authentication dashboards often serve as an early-warning system for credential attacks.

Useful Visualizations

Several visualization types work particularly well with syslog data.

Event Counts

Display:

• Total events
• Events by source
• Events by category
• Events over time

This provides a high-level overview of activity across the environment.

Top Talkers

Identify systems generating the most events.

Examples:

• Busiest firewall
• Most active server
• Most active application
• Highest-volume network device

Top talker reports often reveal misconfigurations, noisy devices, or ongoing incidents.

Severity Distribution

Visualize alert severity levels using:

• Pie charts
• Bar charts
• Heat maps

This allows analysts to quickly assess overall risk levels within the environment.

Geographic Activity Maps

When logs contain source IP addresses, geographic visualizations can reveal:

• Login attempts by country
• External attack sources
• VPN activity
• Geographic anomalies

According to guidance from the SANS Institute, effective visualization significantly improves security monitoring efficiency by helping analysts identify patterns that may be difficult to spot in raw log data.

Best Practices for Running Wazuh as a Syslog Server

Successfully deploying Wazuh as a centralized syslog server involves more than simply collecting logs.

Organizations should focus on securing log transport, optimizing performance, and ensuring long-term reliability to maximize the value of their logging infrastructure.

Secure Syslog Communications

Log data often contains sensitive information, including usernames, IP addresses, authentication events, and security alerts.

Protecting this information during transmission should be a priority.

Use TCP When Possible

Although UDP remains the traditional syslog transport protocol, TCP is generally preferred for security monitoring and compliance-related logging.

Benefits of TCP include:

• Reliable delivery
• Packet retransmission
• Reduced risk of log loss
• Better support for critical security events

For security-sensitive environments, TCP helps ensure that important events reach the Wazuh Manager even during periods of network instability.

Restrict Source IP Addresses

Only trusted devices should be permitted to send syslog messages to Wazuh.

Example:

<allowed-ips>10.10.0.0/24</allowed-ips>

Restricting sources helps prevent:

• Unauthorized log injection
• Spoofed syslog messages
• Noise from unknown systems
• Potential denial-of-service attempts

Segment Logging Networks

Whenever possible, separate logging traffic from normal production traffic.

Benefits include:

• Reduced network congestion
• Improved security isolation
• Easier troubleshooting
• Better performance during high-volume events

Many enterprise environments dedicate management VLANs specifically for monitoring and logging infrastructure.

Optimize Performance

As syslog volume grows, performance planning becomes increasingly important.

Log Filtering Strategies

Not every log requires long-term retention or real-time analysis.

Consider filtering:

• Debug messages
• Low-value informational events
• Duplicate entries
• Excessively verbose application logs

Reducing unnecessary log ingestion lowers storage costs and improves dashboard performance.

Retention Planning

Retention requirements vary based on business needs and compliance obligations.

Common retention periods include:

Organizations subject to regulatory frameworks should verify specific retention requirements before implementation.

Storage Sizing Considerations

Storage requirements depend on:

• Number of log sources
• Average event volume
• Retention policies
• Compression ratios
• Index replication settings

Estimate growth carefully to avoid unexpected storage shortages.

Index Management

Effective index management helps maintain long-term performance.

Recommended practices:

• Implement index lifecycle policies
• Archive older logs
• Delete expired data automatically
• Monitor index growth regularly

For larger deployments, consider clustering your indexers.

See our How to Build a Wazuh Indexer Cluster guide.

Improve Reliability

Centralized logging becomes a critical service within most security programs.

High Availability Options

Organizations with strict uptime requirements should consider:

• Multiple Wazuh Managers
• Load balancing
• Indexer clustering
• Redundant storage

These approaches reduce single points of failure.

Backup Strategies

Regularly back up:

• Wazuh configurations
• Custom decoders
• Custom rules
• Dashboard configurations
• Critical log archives

Backup procedures should be tested periodically to ensure recoverability.

Monitoring Wazuh Health

Monitor key indicators such as:

• CPU utilization
• Memory consumption
• Disk usage
• Queue sizes
• Index growth
• Service availability

Early detection of performance issues prevents data loss and ingestion bottlenecks.

The Center for Internet Security recommends continuous monitoring of logging infrastructure to ensure visibility remains available during security incidents.

Common Troubleshooting Issues

Even properly configured deployments can encounter issues. Understanding common problems can significantly reduce troubleshooting time.

Wazuh Not Receiving Syslog Messages

If no events appear in Wazuh, start by verifying network connectivity and listener configuration.

Firewall Blocking Traffic

Firewalls frequently block syslog traffic by default.

Verify:

• Port 514 UDP/TCP is open
• Cloud security groups allow traffic
• Network ACLs permit communication
• Intermediate firewalls are not filtering packets

Use packet captures to confirm traffic reaches the server:

sudo tcpdump -i any port 514

Incorrect Port Configuration

The sending device and Wazuh Manager must use the same:

• Port number
• Protocol (TCP or UDP)

Mismatched configurations are among the most common deployment issues.

Source Device Misconfiguration

Verify that:

• Syslog forwarding is enabled
• The correct destination IP is configured
• The desired log categories are selected
• Logging severity levels are appropriate

Many network devices provide built-in logging diagnostics that can assist with troubleshooting.

Logs Arrive but No Alerts Are Generated

Sometimes logs are received successfully but fail to generate alerts.

Missing Decoder

Without a decoder, Wazuh may treat the message as raw text.

Check whether:

• A built-in decoder exists
• A custom decoder is required
• Field extraction is working correctly

Use:

/var/ossec/bin/wazuh-logtest

to validate decoder behavior.

Missing Rule

A decoder alone does not generate alerts.

Verify that:

• Matching rules exist
• Rule IDs are unique
• The rule file is loaded correctly

Custom rule creation is covered here:

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

Rule Conditions Not Met

A rule may exist but fail to match because:

• Fields contain unexpected values
• Regex patterns are incorrect
• Log formats changed
• Parent rules are not triggering

Always test custom rules with representative log samples.

High Log Volume Problems

Large environments may generate millions of events per day.

Queue Saturation

When event volume exceeds processing capacity, queues may fill.

Symptoms include:

• Delayed alerts
• Missing events
• Increased processing latency

Increasing queue sizes can help absorb temporary spikes.

Resource Constraints

Performance bottlenecks often result from insufficient:

• CPU resources
• RAM
• Storage throughput
• Indexing capacity

Monitor infrastructure regularly and scale as needed.

Log Noise Reduction

Excessive low-value events can overwhelm analysts.

Consider:

• Filtering unnecessary logs
• Tuning noisy rules
• Adjusting severity levels
• Suppressing repetitive events

Related guide:

How to Reduce False Positives in Wazuh

Dashboard Data Not Appearing

Sometimes logs exist but do not appear within dashboards.

Indexing Issues

Verify:

• Events are reaching the Indexer
• Indices are healthy
• Storage capacity is available
• Replication is functioning properly

Search Filter Problems

Overly restrictive filters frequently hide valid events.

Review:

• Time ranges
• Host filters
• Rule filters
• Index patterns

Dashboard Configuration Errors

Dashboard widgets may fail due to:

• Incorrect queries
• Missing fields
• Invalid visualizations
• Permission issues

Testing queries directly within Discover can help isolate dashboard problems.

Security Considerations

Because syslog often contains sensitive operational and security information, organizations should implement safeguards to protect their logging infrastructure.

Protecting Syslog Traffic

Log data should be treated as a security-sensitive asset.

Risks of Unencrypted Syslog

Traditional syslog over UDP provides no encryption.

Potential risks include:

• Packet interception
• Credential exposure
• Log tampering
• Information disclosure

Organizations transmitting logs across untrusted networks should implement additional protections.

Network Segmentation

Dedicated logging networks help isolate monitoring infrastructure from user traffic.

Benefits include:

• Reduced attack surface
• Improved performance
• Better access control
• Easier compliance management

VPN and Secure Transport Options

To secure syslog transmission:

• Site-to-site VPNs
• IPSec tunnels
• TLS-enabled syslog solutions
• Private network links

These methods help protect log integrity and confidentiality.

Access Control

Protecting the Wazuh platform itself is equally important.

Restricting Administrative Access

Limit access to:

• Security administrators
• System administrators
• Authorized analysts

Avoid sharing privileged accounts whenever possible.

Role-Based Access Controls

Wazuh supports granular permissions through role-based access controls (RBAC).

RBAC allows organizations to:

• Limit dashboard access
• Restrict administrative actions
• Control alert visibility
• Separate operational responsibilities

Audit Logging

Enable auditing for:

• User logins
• Configuration changes
• Dashboard modifications
• Administrative actions

Maintaining audit trails helps support compliance requirements and incident investigations.

Frequently Asked Questions

Question: Can Wazuh act as a standalone syslog server?

Yes. Wazuh can receive, store, analyze, and visualize syslog data from a wide variety of devices and applications.

Unlike traditional syslog servers, it also provides SIEM and XDR capabilities for threat detection and security monitoring.

Question: Does Wazuh support both UDP and TCP syslog?

Yes. Wazuh supports both UDP and TCP syslog collection. TCP is generally recommended for critical log sources because it provides reliable delivery.

Question: Can Wazuh collect logs from firewalls and routers?

Yes. Wazuh can collect syslog events from many network devices, including:

• Cisco routers and switches
• Fortinet firewalls
• pfSense firewalls
• Wireless controllers
• IDS and IPS appliances

See our How to Collect Firewall Logs in Wazuh guide.

How many syslog sources can Wazuh handle?

The number depends on:

• Hardware resources
• Event volume
• Indexer capacity
• Retention policies
• Cluster design

Large enterprise deployments commonly support hundreds or thousands of syslog sources.

Question: Can Wazuh parse custom syslog formats?

Yes. Custom decoders and rules allow Wazuh to process proprietary log formats from applications, devices, and internally developed systems.

Question: What is the difference between agent-based logging and syslog logging in Wazuh?

Agent-based logging provides deeper visibility, including:

• File integrity monitoring
• Vulnerability detection
• Endpoint telemetry
• Active response

Syslog collection focuses on receiving events from systems that support syslog forwarding.

Many organizations use both approaches together.

How to Configure File Integrity Monitoring (FIM) in Wazuh

Is syslog collection available in the free version of Wazuh?

Yes. Syslog collection is included in the open-source version of Wazuh and does not require additional licensing.

Conclusion

Configuring Wazuh as a centralized syslog server enables organizations to consolidate logs from servers, network devices, applications, and security tools into a single monitoring platform.

Recap of Wazuh Syslog Server Capabilities

Wazuh provides much more than basic log collection.

Centralized Log Collection

Logs from multiple systems can be aggregated into a single location for analysis and retention.

Real-Time Monitoring

Incoming events are processed immediately, allowing security teams to identify issues as they occur.

Security Analytics and Alerting

Built-in and custom detection rules transform raw syslog data into actionable alerts that support threat detection and incident response.

Key Benefits of Using Wazuh for Syslog Management

Organizations choose Wazuh because it combines enterprise-grade monitoring capabilities with the flexibility of an open-source platform.

Unified Visibility

Monitor infrastructure, applications, endpoints, and network devices from a single interface.

Open-Source Flexibility

Customize decoders, rules, dashboards, and integrations without vendor lock-in.

Scalable Architecture

Scale from small environments to enterprise deployments using clustering and distributed components.

Next Steps

After successfully deploying Wazuh as a syslog server, consider expanding your monitoring capabilities by:

• Onboarding additional syslog sources
• Creating custom detection rules
• Building security-focused dashboards
• Integrating threat intelligence feeds
• Monitoring cloud services and applications

Recommended next guides:

• How to Create Custom Detection Rules in Wazuh (With Examples)
• How to Integrate Wazuh with VirusTotal for Threat Intelligence
• How to Integrate Wazuh with Suricata for Better Threat Detection
• How to Monitor AWS CloudTrail Logs Using Wazuh

With proper configuration, tuning, and monitoring, Wazuh can serve as a powerful centralized syslog server that provides comprehensive visibility across your entire environment while strengthening your overall security posture.