Syslog configuration guide for beginners

Syslog configuration forms the fundamental groundwork of robust log management and network monitoring. By providing a standardized method to capture, store, and analyze critical system events, it serves as your infrastructure’s central nervous system revealing performance issues, security threats, and operational problems.

This comprehensive beginner's guide breaks syslog configuration into manageable steps with practical examples that work across operating systems and devices. Whether you're setting up local logging, configuring remote log forwarding, or securing syslog with TLS encryption, you'll find complete workflows here.

Understanding syslog configuration files

Syslog’s behavior is controlled entirely by its configuration files. These files act as the rulebook for your logging system, determining how messages are classified, processed, stored, and forwarded.

What configuration files control:

• Accept and process incoming log messages
• Categorize messages based on facility (source type) and severity (priority level)
• Determine which messages to store locally, forward remotely, or discard
• Format log entries using customizable templates
• Enable communication protocols (UDP, TCP, or TLS for encryption)
• Manage system performance through message queuing and buffering

While different implementations exist (rsyslog, syslog-ng, traditional syslogd), they all follow the same conceptual structure. Mastering configuration files lets you customize the entire logging workflow for centralized analysis.

Configuration file structure

A typical syslog configuration file contains these logical sections:

• Global directives: System-wide settings like queue sizes, timeouts, and file permissions
• Modules: Loadable components that extend functionality (encryption, database output, etc.)
• Rules: Filtering and routing instructions (the most important section for beginners)
• Templates: Format definitions that control how log messages appear

Locating syslog configuration files

Knowing where to find configuration files is crucial for modifying logging behavior, enabling remote forwarding, or troubleshooting issues.

Basic syslog configuration syntax

Understanding syslog syntax is essential for creating effective logging rules. While advanced features differ between implementations, the core syntax remains universal across systems.

All syslog rules follow this basic pattern:

facility.severity    destination

Facilities

Facilities categorize log messages by their source, helping administrators route specific types of system events to appropriate log files or actions.

Severity levels

Severity levels define the urgency of log messages numerically (0-7), enabling filtering for critical alerts versus routine information during troubleshooting.

Selectors

Selectors combine facilities and severity levels using operators to create precise filtering rules for targeted log collection, noise reduction, and advanced matching.

Actions

Actions specify destinations for filtered log messages, supporting local storage, remote forwarding, user notifications, and program processing for comprehensive logging strategies.

Syntax examples

Platform-specific syslog setup

Syslog behaves differently across Linux, Windows, and network devices. Understanding these platform-specific variations is essential for consistent log collection.

Linux (rsyslog): step-by-step configuration

Step 1: Open configuration

sudo nano /etc/rsyslog.conf

Step 2: Enable network modules

module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

Step 3: Add rules, filters, or templates as needed

Example: Forward all logs to a remote syslog server

*.* @@192.168.1.100:514

Step 4: Validate configuration (before restart)

Check for configuration syntax errors

sudo rsyslogd -N1

If no errors appear, proceed to restart. If errors are found, fix them and revalidate.

Step 5: Restart service

sudo systemctl restart rsyslog

Step 6: Verify the service is running

sudo systemctl status rsyslog

Windows: agent setup

Windows lacks native syslog support, requiring third-party agents:

• NXLog community/enterprise:
  Copy

  Configure C:\Program Files\NXLog\conf\nxlog.conf

• Snare agent:
  Copy

  Edit C:\Program Files\Snare\snare.conf

• Syslog-NG Agent: Configure via agent interface

Typical settings include syslog server IP, facility mapping, log format (RFC 3164/5424), and transport protocol (UDP/TCP/TLS).

Network devices: Vendor examples

Once syslog is configured on all platforms, your environment becomes ready for centralized logging and SIEM integration.

Remote logging setup

Remote logging is essential for centralized log management, compliance, auditing, and SIEM operations. This section covers the complete workflow: client configuration, server configuration, opening firewall ports, and TLS encryption.

Client-side example (rsyslog)

Send all logs to a central syslog server:

UDP (fast, no delivery guarantee):

*.* @192.168.1.10:514

TCP (reliable delivery):

*.* @@192.168.1.10:514

Server-side example (rsyslog)

Enable listening on the syslog server:

module(load="imudp")
input(type="imudp" port="514")

module(load="imtcp")
input(type="imtcp" port="514")

Best practices for remote logging

• Use TCP for reliability
• Use TLS (port 6514) for security
• Segment traffic using facility codes
• Enable queues to handle network interruptions

Opening firewall ports for syslog

Network traffic to your syslog server must be explicitly allowed by the firewall. Choose the appropriate method for your Linux distribution:

firewalld (RHEL/CentOS/Fedora)

Step 1: Allow standard syslog ports (UDP and TCP)

sudo firewall-cmd --permanent --add-port=514/udp
sudo firewall-cmd --permanent --add-port=514/tcp

Step 2: Allow TLS syslog port

sudo firewall-cmd --permanent --add-port=6514/tcp

Step 3: Reload firewall rules

sudo firewall-cmd --reload

Step 4: Verify ports are open

sudo firewall-cmd --list-ports

Expected output: 514/udp 514/tcp 6514/tcp

UFW (Ubuntu/Debian)

Step 1: Allow standard syslog ports (UDP and TCP)

sudo ufw allow 514/udp
sudo ufw allow 514/tcp

Step 2: Allow TLS syslog port

sudo ufw allow 6514/tcp

Step 3: Verify rules are active

sudo ufw status

iptables (legacy systems)

Step 1: Allow syslog UDP traffic

sudo iptables -A INPUT -p udp --dport 514 -j ACCEPT

Step 2: Allow syslog TCP traffic

sudo iptables -A INPUT -p tcp --dport 514 -j ACCEPT

Step 3: Allow TLS syslog traffic

sudo iptables -A INPUT -p tcp --dport 6514 -j ACCEPT

Step 4: Save rules (CentOS/RHEL)

sudo service iptables save

Step 5: Verify rules are active

sudo iptables -L -n | grep 514

Testing firewall access:

After opening the ports, verify syslog can reach your server:

# Test from client machine
nc -vzu <syslog-server-ip> 514     # UDP test
nc -vz <syslog-server-ip> 514      # TCP test
nc -vz <syslog-server-ip> 6514     # TLS test

Interpreting the results:

A successful test will return a connection message. The exact phrasing depends on your netcat version:

• nmap-ncat or newer gnu-netcat: You will see Connection to <ip> port <514|6514> [tcp|udp/*] succeeded!
• Older gnu-netcat (common on Linux): You will see Connection to <ip> <port> port [tcp|udp/*] succeeded!
• BSD netcat (common on macOS): For TCP, the command will simply exit silently (with a 0 exit code). For UDP (-u), it may not provide clear feedback.

A failed test will typically return an error like Connection refused, No route to host, or Timed out, and the command will hang until you interrupt it (Ctrl+C).

Configuring TLS-encrypted syslog (rsyslog)

For production environments, TLS encryption protects sensitive log data in transit. Here's how to configure secure syslog on both server and client.

Server-side (receiving secure logs):

Step 1: Open configuration

sudo nano /etc/rsyslog.conf

Step 2: Load secure input module:

module(load="imtcp" StreamDriver.Name="gtls" 
       StreamDriver.Mode="1" 
       StreamDriver.AuthMode="anon")

Step 3: Listen on port 6514 (standard TLS syslog port)

input(type="imtcp" port="6514")

Step 4: Configure global TLS settings

global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/ssl/certs/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/ssl/certs/server-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/ssl/private/server-key.pem"
)

Replace the certificate file paths with your actual certificate locations.

Step 5: Validate configuration

sudo rsyslogd -N1

Step 6: Restart service

sudo systemctl restart rsyslog

Client-side (sending secure logs):

Step 1: Open configuration

sudo nano /etc/rsyslog.conf

Step 2: Forward all logs to syslog server via TLS

*.* @@(o)logserver.example.com:6514

Parameter explanation:

• @@ - Forward via TCP (more reliable than UDP)
• (o) - Enables OpenTLS mode for encryption
• logserver.example.com - Replace with your syslog server hostname or IP
• 6514 - TLS syslog port (standard)

Example with IP address:

*.* @@(o)192.168.1.100:6514

Step 3: Validate configuration

sudo rsyslogd -N1

Step 4: Restart service

sudo systemctl restart rsyslog

Step 5: Verify the service is running

sudo systemctl status rsyslog

logger -n logserver.example.com -p user.info "TLS syslog test message"

systemd-journald forwarding (modern Linux systems)

On modern distributions (Ubuntu 16.04+, RHEL 7+, CentOS 7+), logs are captured by systemd- journald first before being forwarded to rsyslog. To ensure logs reach your syslog configuration, follow these steps:

Step 1: Open journald configuration

sudo nano /etc/systemd/journald.conf

Step 2: Locate and enable syslog forwarding

Find the line:

ForwardToSyslog=no

Change it to:

ForwardToSyslog=yes

Step 3: Save and exit the editor (Ctrl+O, Enter, Ctrl+X)

Step 4: Restart journald to apply changes

sudo systemctl restart systemd-journald

Step 5: Verify the setting is active

grep ForwardToSyslog /etc/systemd/journald.conf

You should see:

ForwardToSyslog=yes

If ForwardToSyslog is disabled, logs might not appear in traditional syslog files (/var/log/messages, /var/log/syslog). This is especially critical if you're configuring rsyslog rules that depend on these log files.

Setting up log rotation

Log rotation ensures that log files don’t grow indefinitely. Without proper rotation, systems risk disk exhaustion, performance degradation, and service interruptions. Log rotation also keeps logs organized, compressed, and manageable for long-term storage, audits, and compliance.

Linux log rotation (logrotate)

Sample logrotate configuration

/var/log/syslog {
    daily
    rotate 14
    compress
    missingok
    notifempty
}

What it does: Rotates syslog daily, keeps 14 days of compressed archives, ignores missing files, and skips empty logs, which is common in Ubuntu/Debian for system event management.

Best practices for log rotation

• Keep 7–30 days of history for audits
• Compress old logs to save space
• Use separate directories for high-volume logs
• Monitor disk usage regularly

Advanced filtering, routing and templates

Advanced controls enable you to process specific log types, reduce noise, and route important events to appropriate locations.

Filtering examples:

Custom templates

Templates give you fine-grained control over log formatting for consistency and easier parsing.

For example:

$template Detailed,"%timestamp:::date-rfc3339% %hostname% %syslogtag% %msg%\n"*.*
                        /var/log/custom.log; Detailed

Configuration examples and templates

Configurations vary across environments. These examples help beginners create consistent and functional syslog setups. Some of the common templates include:

These templates reduce setup time and ensure predictable behavior across devices.

Testing your syslog configuration

Testing validates whether logs are being generated, routed, and received correctly.

Regular testing using these commands helps ensure syslog is configured properly and operational across local and remote setups.

Troubleshooting common syslog configuration errors

Syslog issues typically stem from configuration errors, permission problems, or network blocks. Here's a diagnostic checklist to help through your troubleshooting process.

Troubleshooting flow

1. Check service status: sudo systemctl status rsyslog
2. Validate configuration: sudo rsyslogd -N1
3. Test network connectivity: logger -n <server-ip> "test"
4. Check permissions and disk space: Verify /var/log/ ownership and free space
5. Enable debug logging: Add $DebugLevel 2 to rsyslog.conf

SELinux considerations (RHEL/CentOS systems)

On RHEL, CentOS, and Fedora systems, SELinux can block legitimate syslog network operations even when configuration and firewall are correct. If remote logging fails despite correct configuration, follow these troubleshooting steps.

Diagnosing SELinux blocks

Step 1: Check if syslog is blocked by SELinux

sudo tail -f /var/log/audit/audit.log | grep syslog

Look for entries with denied status. If you see denial messages, SELinux is blocking syslog traffic. Press Ctrl+C to exit the tail command.

Step 2: Identify the specific port or operation being blocked

Review the audit log output. Common blocks include:

• Connections to port 514 (standard syslog)
• Connections to port 6514 (TLS syslog)
• Network operations for remote logging

Applying SELinux policies for syslog

Step 1: Disable SELinux transition restrictions (if needed)

sudo setsebool -P syslogd_disable_trans 0

The -P flag makes the change persistent across reboots.

Step 2: Allow syslog on standard port (TCP)

sudo semanage port -a -t syslogd_port_t -p tcp 514

Step 3: Allow syslog on standard port (UDP)

sudo semanage port -a -t syslogd_port_t -p udp 514

Step 4: Allow syslog on TLS port

sudo semanage port -a -t syslogd_port_t -p tcp 6514

Step 5: Restart syslog service

sudo systemctl restart rsyslog

Verifying SELinux changes

Step 1: Verify the port policies were applied

sudo semanage port -l | grep syslogd

Expected output:

syslogd_port_t                 tcp      514, 6514
syslogd_port_t                 udp      514

Step 2: Check SELinux boolean status

sudo getsebool syslogd_disable_trans

Should return: syslogd_disable_trans --> on

Step 3: Test remote logging

logger -n <syslog-server-ip> -p user.info "SELinux test message"

Replace <syslog-server-ip> with your actual syslog server IP address.

If SELinux denials persist:

Option 1: Generate a policy module from denials

sudo audit2allow -a -M syslog_custom
    sudo semodule -i syslog_custom.pp

Option 2: Temporarily disable SELinux (not recommended for production)

sudo setenforce 0

To re-enable: sudo setenforce 1

Option 3: Set SELinux to permissive mode for syslog domain

sudo semanage permissive -a syslogd_t

SELinux best practices

• Always use sudo semanage port -a to add ports, not modify existing SELinux policy modules
• Keep SELinux enforcing mode enabled for security
• Test policies thoroughly before deploying to production
• Document any custom SELinux policies applied to your systems
• Regularly review /var/log/audit/audit.log for new denial patterns

How EventLog Analyzer simplifies syslog configuration

Managing syslog configurations across Linux servers, Windows systems, firewalls, routers, and applications can quickly become complex and inconsistent. Manual configuration file edits, regex creation for custom formats, certificate management for TLS, and firewall rule coordination across multiple devices introduce opportunities for error and inconsistency. ManageEngine EventLog Analyzer removes this complexity by centralizing, automating, and securing the entire syslog setup process.

Manual configuration vs. EventLog Analyzer

With EventLog Analyzer delivers

• Unified management console: Configure syslog collection for Windows, Linux, network devices, and applications from one dashboard.
• Zero regex required: Automatically detects and parses common syslog formats, eliminating the need for regex creation or custom parsing rules.
• Security hardening: TLS-based log transport (port 6514) is automatically configured, removing the complexity of certificate generation, distribution, and rotation.
• Compliance-ready: Prebuilt templates for the PCI DSS, HIPAA, SOX, the GDPR, and other regulatory frameworks without manual tuning.

Pre-deployment checklist:

Before going live, verify:

1. All critical systems are forwarding logs.
2. Facility and severity codes are properly categorized.
3. TLS is enabled for sensitive log streams.
4. Disk usage controlled via rotation policies.
5. Log collection failures trigger alerts.
6. End-to-end pipeline tested and verified.

EventLog Analyzer transforms syslog into a complete security and analytics ecosystem, simplifying configuration while enhancing threat detection, compliance, and operational visibility.

Frequently asked questions