How To Setup Rsyslog on Debian 13

System logging forms the backbone of server administration and troubleshooting. Rsyslog, a powerful and reliable logging system, enables administrators to collect, process, and forward log messages across multiple servers efficiently. This comprehensive guide walks through setting up Rsyslog on Debian 13 (Trixie), covering installation, configuration, security hardening, and troubleshooting techniques.

Whether managing a single server or an entire infrastructure, centralized logging with Rsyslog provides visibility into system events, application behavior, and security incidents. The configuration process requires attention to detail but rewards administrators with robust log management capabilities that scale from small environments to enterprise deployments.

Understanding Rsyslog on Debian 13

Rsyslog stands as an enhanced implementation of the traditional syslog protocol, offering high-performance logging with extensive configurability. Unlike basic syslog implementations, Rsyslog supports multi-threaded processing, multiple transport protocols including TCP, UDP, and RELP (Reliable Event Logging Protocol), and can integrate with databases for structured log storage.

Debian 13 minimal installations may not include Rsyslog by default, relying instead on systemd’s journald for log collection. While journald provides adequate logging for standalone systems, Rsyslog excels in networked environments where centralized log aggregation becomes essential. The daemon operates by receiving log messages from various sources, filtering them based on facility and priority, then routing them to appropriate destinations such as files, remote servers, or databases.

Organizations requiring compliance with security standards, managing distributed applications, or troubleshooting complex system issues benefit significantly from Rsyslog’s centralized architecture. The system processes logs from network devices, applications, and operating systems, creating a unified view of infrastructure events.

Prerequisites and System Requirements

Before beginning the installation, verify that the Debian 13 system meets basic requirements. A fresh Debian 13 (Trixie) installation with root or sudo privileges provides the foundation for this setup. Network connectivity between servers becomes critical when implementing client-server logging configurations.

Firewall management requires careful consideration. Port 514 (both TCP and UDP) traditionally serves syslog traffic and must remain accessible between client and server systems. Testing environments benefit from having at least two Linux systems: one configured as the log server and another as a client sending logs remotely.

Check the current logging infrastructure before proceeding. Some Debian installations run journald exclusively, while others may have Rsyslog already installed. Execute system updates to ensure all packages reflect current security patches and bug fixes. This preparation minimizes conflicts and ensures smooth installation of Rsyslog components.

Installing Rsyslog on Debian 13

The installation process begins with verifying whether Rsyslog already exists on the system. Open a terminal and check the package status:

dpkg -l | grep rsyslog

If no output appears, Rsyslog requires installation. Update the package repository index to ensure access to the latest package versions:

sudo apt update

Install Rsyslog with a single command:

sudo apt install rsyslog -y

The package manager downloads Rsyslog along with required dependencies, including library files and configuration templates. Installation typically completes within seconds on modern systems with adequate internet connectivity.

After installation, start the Rsyslog service immediately:

sudo systemctl start rsyslog

Enable automatic startup at boot time to ensure logging continues after system restarts:

sudo systemctl enable rsyslog

Verify the service status to confirm successful activation:

sudo systemctl status rsyslog

The output should display “active (running)” in green text, indicating the daemon operates correctly. Check the installed version for documentation reference purposes:

rsyslogd -version

The rsyslogd daemon now runs in the background, processing log messages according to default configuration rules.

Understanding Rsyslog Configuration Files

Rsyslog’s configuration resides primarily in /etc/rsyslog.conf, the main configuration file that defines global settings, module loading, and logging rules. Additional configuration snippets can be placed in /etc/rsyslog.d/ directory, allowing modular organization of complex setups.

Configuration files follow a specific structure. Module loading directives appear at the top, enabling input and output plugins. Global directives set system-wide parameters such as file permissions and queue sizes. Rules define how messages get processed based on facility and priority selectors.

Syslog facilities categorize message sources. Common facilities include:

• kern: Kernel messages
• auth: Authentication and security events
• mail: Mail system logs
• cron: Scheduled task execution
• daemon: Background service messages
• syslog: Internal syslog messages

Priority levels indicate message severity. From highest to lowest urgency:

• emerg: System unusable
• alert: Immediate action required
• crit: Critical conditions
• err: Error conditions
• warning: Warning messages
• notice: Normal but significant
• info: Informational messages
• debug: Debug-level messages

Log files typically accumulate in /var/log/ directory, with specific files like /var/log/syslog containing general messages, /var/log/auth.log holding authentication events, and /var/log/kern.log storing kernel messages.

Configuration syntax follows the pattern: facility.priority action. For example, mail.info /var/log/mail.log directs all mail facility messages with info priority or higher to the mail log file. A dash prefix (-) before filenames enables asynchronous writing, improving performance at the cost of potential data loss during crashes.

Configuring Rsyslog as a Server

Transforming Rsyslog into a centralized log server requires enabling network reception modules. This configuration allows the server to accept log messages from remote clients across the network.

Open the main configuration file with a text editor:

sudo nano /etc/rsyslog.conf

Locate the module loading section near the top of the file. For UDP reception on port 514, uncomment these lines:

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

UDP provides connectionless transmission with lower overhead but no delivery guarantee. For TCP reception, which offers reliable delivery, uncomment these lines:

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

TCP establishes connections before transmitting data, ensuring message delivery through acknowledgments. Most production environments enable both protocols for maximum compatibility.

Custom ports enhance security through obscurity. Change the port parameter to any unused port number above 1024 to avoid conflicts with standard services.

Create organized storage for incoming client logs. Add a template definition that organizes logs by hostname and facility:

$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs
& stop

This template creates separate directories for each client hostname under /var/log/, with individual files for each program generating logs. The & stop directive prevents duplicate logging to local files.

For enhanced security, restrict which systems can send logs to the server. Add allowed sender restrictions:

$AllowedSender TCP, 192.168.1.0/24
$AllowedSender UDP, 192.168.1.0/24

Replace the IP range with the actual subnet containing authorized client systems. This prevents unauthorized log injection from external sources.

Save the configuration file and validate syntax before restarting:

sudo rsyslogd -N1

This command performs a configuration test without starting the daemon. No output indicates successful validation. Error messages highlight syntax problems requiring correction.

Restart Rsyslog to apply the new configuration:

sudo systemctl restart rsyslog

The server now listens for incoming log messages on the configured ports.

Configuring Firewall Rules for Rsyslog

Network connectivity requires appropriate firewall configuration. Without proper rules, the firewall blocks incoming syslog traffic from client systems.

Check whether UFW (Uncomplicated Firewall) is active:

sudo ufw status

If UFW manages the firewall, allow TCP port 514:

sudo ufw allow 514/tcp

Allow UDP port 514 as well:

sudo ufw allow 514/udp

For environments using custom ports, adjust the port numbers accordingly. Reload UFW to activate the new rules:

sudo ufw reload

Systems running firewalld require different commands:

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

Verify that Rsyslog binds to the correct ports:

sudo ss -tulpn | grep rsyslog

The output displays listening sockets showing TCP and UDP on port 514. This confirms both the service configuration and firewall rules function correctly.

Security best practices demand restricting syslog access to trusted networks only. Never expose port 514 directly to the public internet, as this creates attack vectors for log injection and denial-of-service attempts. Consider using VPN tunnels or private networks for log transmission in distributed environments.

Configuring Rsyslog Client Systems

Client configuration forwards local logs to the centralized server. Each client system requires modification to its Rsyslog configuration.

On client systems, edit the configuration file:

sudo nano /etc/rsyslog.conf

Add forwarding rules at the end of the file. For UDP transmission, use a single @ symbol:

*.* @192.168.1.100:514

Replace 192.168.1.100 with the actual server IP address. TCP forwarding requires two @ symbols:

*.* @@192.168.1.100:514

The double @@ notation signals TCP protocol usage. TCP provides reliability through connection establishment and acknowledgment mechanisms.

Implement disk-assisted queues for reliability when the server becomes temporarily unavailable. Add these queue configuration directives:

$ActionQueueFileName queue
$ActionQueueMaxDiskSpace 1g
$ActionQueueSaveOnShutdown on
$ActionQueueType LinkedList
$ActionResumeRetryCount -1

This configuration creates a 1GB disk queue that persists across shutdowns and retries indefinitely until the server reconnects. The LinkedList queue type enables asynchronous processing, preventing log generation from blocking if the network experiences delays.

For selective forwarding, specify particular facilities or priorities. Forward only authentication logs:

auth,authpriv.* @@192.168.1.100:514

Or send critical and higher priority messages across all facilities:

*.crit @@192.168.1.100:514

Configure multiple destination servers for redundancy:

*.* @@primary-server:514
*.* @@backup-server:514

Logs transmit to both servers simultaneously, ensuring availability if one server fails.

Test the configuration syntax:

sudo rsyslogd -N1

Restart the Rsyslog service on client systems:

sudo systemctl restart rsyslog

The client now forwards logs to the central server according to the configured rules.

Verifying Rsyslog Server-Client Communication

Verification ensures proper communication between components. Start by confirming the server listens on configured ports:

sudo ss -tulpn | grep 514

Output showing TCP and UDP listeners on port 514 indicates correct server configuration. Alternative verification uses netstat:

sudo netstat -tulpn | grep 514

Monitor the server’s log directory for incoming client messages. Navigate to the configured log path:

cd /var/log/
ls -la

New directories named after client hostnames should appear. Examine these directories:

ls -la /var/log/client-hostname/

Log files from various programs running on the client populate this directory.

View real-time log reception:

sudo tail -f /var/log/client-hostname/syslog

Generate test messages from the client system:

logger "Test message from client"

The test message should appear in the server’s log file within seconds. If messages don’t arrive, troubleshoot systematically. Check client service status:

sudo systemctl status rsyslog

Verify firewall rules on both systems allow port 514 traffic. Examine the client’s queue directory for accumulated messages indicating server connectivity problems:

ls -la /var/spool/rsyslog/

Queue files suggest the client buffers logs while attempting to reach the server.

Implementing TLS Encryption for Secure Logging

Unencrypted syslog traffic exposes sensitive information during transmission. TLS encryption protects log data from interception and tampering.

Install TLS support packages on both server and client systems:

sudo apt install rsyslog-gnutls ca-certificates -y

Rsyslog supports both GnuTLS and OpenSSL network stream drivers. GnuTLS integration (gtls) provides excellent compatibility with Debian systems.

Generate certificates for authentication. Production environments should obtain certificates from trusted certificate authorities. Testing environments can use self-signed certificates created with OpenSSL:

sudo openssl req -x509 -nodes -newkey rsa:4096 -keyout /etc/ssl/private/rsyslog-key.pem -out /etc/ssl/certs/rsyslog-cert.pem -days 365

Configure server-side TLS settings. Edit /etc/rsyslog.conf and add before the input modules:

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

input(type="imtcp" port="6514"
      StreamDriver.Name="gtls"
      StreamDriver.Mode="1"
      StreamDriver.Authmode="anon")

This configuration enables TLS on port 6514 (the standard TLS syslog port) with anonymous authentication. For certificate-based authentication, specify certificate paths:

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

Client-side TLS configuration requires similar settings. Add to client’s /etc/rsyslog.conf:

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

*.* action(type="omfwd"
           Target="192.168.1.100"
           Port="6514"
           Protocol="tcp"
           StreamDriver="gtls"
           StreamDriverMode="1"
           StreamDriverAuthMode="x509/name"
           StreamDriverPermittedPeers="server.domain.com")

The StreamDriverPermittedPeers directive validates server identity against the certificate common name, preventing man-in-the-middle attacks.

Update firewall rules for the TLS port:

sudo ufw allow 6514/tcp

Restart Rsyslog on both systems:

sudo systemctl restart rsyslog

Test encrypted transmission by generating log messages from the client and verifying server reception. Troubleshoot TLS connection issues by examining error messages in /var/log/syslog.

Advanced Rsyslog Configuration Options

Property-based filters enable sophisticated log routing beyond basic facility and priority matching. Filter by hostname:

:hostname, isequal, "webserver1" /var/log/webserver1.log

Filter by program name:

:programname, isequal, "nginx" /var/log/nginx/access.log

Rate limiting prevents log flooding during system malfunctions:

$ModLoad imuxsock
$SystemLogRateLimitInterval 5
$SystemLogRateLimitBurst 200

This configuration limits messages to 200 per 5-second interval.

Custom templates format log messages:

$template CustomFormat,"%TIMESTAMP% %HOSTNAME% %syslogtag% %msg%\n"
*.* /var/log/custom.log;CustomFormat

Templates control both filename patterns and message formatting.

Database output modules store logs in relational databases for advanced querying. MySQL integration requires additional packages:

sudo apt install rsyslog-mysql

Configure database output in /etc/rsyslog.conf:

module(load="ommysql")
*.* :ommysql:localhost,Syslog,rsyslog,password

The RELP protocol provides more reliability than TCP for critical log transmission. Install RELP support:

sudo apt install rsyslog-relp

Configure RELP input on the server:

module(load="imrelp")
input(type="imrelp" port="2514")

Client RELP forwarding:

module(load="omrelp")
*.* :omrelp:192.168.1.100:2514

Monitor Rsyslog performance with the impstats module:

module(load="impstats" interval="60" log.file="/var/log/rsyslog-stats.log")

Statistics output every 60 seconds reveals queue sizes, message counts, and processing rates.

Security Best Practices for Rsyslog

Never expose syslog ports to untrusted networks or the public internet. Attackers can inject false log entries, consume disk space, or exploit vulnerabilities in log parsing systems.

Utilize dedicated private networks or VPN tunnels for inter-server log transmission. This isolation prevents unauthorized access to log streams containing sensitive operational data.

Implement strict allowed sender restrictions using IP whitelisting:

$AllowedSender TCP, 10.0.0.0/8, 192.168.0.0/16

Only specify networks under direct administrative control.

Keep Rsyslog packages current with security updates:

sudo apt update && sudo apt upgrade rsyslog

Subscribe to security advisories from the Rsyslog project to stay informed about vulnerabilities.

Harden configuration file permissions to prevent unauthorized modifications:

sudo chmod 600 /etc/rsyslog.conf
sudo chown root:root /etc/rsyslog.conf

Mandatory TLS encryption protects log confidentiality and integrity during transmission. Certificate-based mutual authentication ensures both endpoints verify each other’s identity before exchanging data.

Consider SELinux or AppArmor policies to confine Rsyslog’s access to system resources. These mandatory access control systems limit potential damage from security vulnerabilities.

Regular log review detects anomalies indicating security incidents or system problems. Automated analysis tools parse logs for suspicious patterns, failed authentication attempts, and configuration changes.

Implement comprehensive backup strategies for the centralized log server. Log data serves as evidence during incident response and may face legal discovery requirements. Regular backups ensure data preservation even if the server experiences hardware failures.

Troubleshooting Common Rsyslog Issues

Service verification forms the foundation of troubleshooting. Check if Rsyslog runs:

sudo systemctl status rsyslog

Failed or inactive status requires investigation of error messages.

Configuration syntax errors prevent service startup. Validate configuration files:

sudo rsyslogd -N1

Error output identifies problematic lines requiring correction. Common syntax errors include missing quotes, incorrect module names, and malformed filter expressions.

Examine system logs for Rsyslog error messages:

sudo journalctl -u rsyslog -n 50

Port conflicts occur when another service already binds to port 514. Identify the conflicting process:

sudo lsof -i :514

Stop the conflicting service or configure Rsyslog to use an alternative port.

Firewall blocking represents a frequent connectivity problem. Verify rules allow syslog traffic:

sudo ufw status verbose

Test network connectivity between client and server:

telnet server-ip 514

Successful connection indicates network and firewall permit traffic.

Permission denied errors often affect log file creation. Check directory ownership and permissions:

ls -la /var/log/

Ensure Rsyslog runs as the syslog user with write access to log directories.

Client queue accumulation suggests server connectivity problems. Examine queue files:

sudo ls -lh /var/spool/rsyslog/

Large queue files indicate the client buffers logs while unable to reach the server.

TLS connection failures require certificate validation. Verify certificate paths exist and contain valid data:

sudo openssl x509 -in /etc/ssl/certs/rsyslog-cert.pem -text -noout

Check certificate common names match permitted peers configuration.

DNS resolution failures prevent hostname-based configuration from working. Test resolution:

nslookup server-hostname

Use IP addresses instead of hostnames if DNS proves unreliable.

Disk space exhaustion stops log writing. Monitor available space:

df -h /var/log/

Implement log rotation policies to prevent disk full conditions.

Debug mode provides detailed troubleshooting information. Run Rsyslog in foreground debug mode:

sudo rsyslogd -dn

This outputs extensive processing details revealing configuration problems and message flow issues.

Testing and Validation

Comprehensive testing verifies correct deployment before relying on the logging infrastructure. Create a systematic test plan covering all configured features.

Generate test messages with the logger utility:

logger -p user.info "User level info test message"
logger -p auth.warning "Authentication warning test"
logger -p kern.err "Kernel error test"

Verify message arrival on the server:

sudo tail -f /var/log/client-hostname/syslog

Each test message should appear promptly.

Test different protocols separately. Configure UDP forwarding and verify messages arrive. Switch to TCP and repeat the test. Compare delivery reliability and performance characteristics.

TLS encrypted connections require validation. Generate test messages after enabling encryption and confirm server reception. Packet capture tools verify encryption:

sudo tcpdump -i eth0 port 6514 -X

Encrypted traffic appears as unintelligible binary data rather than readable text.

Simulate server downtime to test queue functionality. Stop the server Rsyslog service:

sudo systemctl stop rsyslog

Generate messages from the client. Restart the server and verify queued messages transmit successfully.

Test filtering rules by generating messages matching specific criteria. Verify only matching messages reach configured destinations while others route to default locations.

Performance testing assesses system capacity. Generate high-volume log traffic:

for i in {1..1000}; do logger "Performance test message $i"; done

Monitor server CPU usage, memory consumption, and disk I/O during the test. Review impstats output for processing metrics.

Document test results including configuration settings, test procedures, and observed outcomes. This documentation guides troubleshooting and future maintenance activities.

Maintaining Your Rsyslog Infrastructure

Ongoing maintenance ensures reliable log collection over time. Monitor log server disk usage regularly:

du -sh /var/log/*

Configure automated log rotation with logrotate. Create /etc/logrotate.d/rsyslog-remote:

/var/log/*/*.log {
    daily
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 syslog adm
    sharedscripts
    postrotate
        /usr/bin/killall -HUP rsyslogd
    endscript
}

This configuration rotates remote logs daily, keeping 14 days of history.

Back up configuration files before making changes:

sudo cp /etc/rsyslog.conf /etc/rsyslog.conf.backup

Maintain change documentation tracking configuration modifications, their purposes, and implementation dates.

Update Rsyslog packages regularly to receive security fixes and feature enhancements:

sudo apt update
sudo apt upgrade rsyslog rsyslog-gnutls

Review release notes for breaking changes requiring configuration adjustments.

Monitor service health with automated checks. Create monitoring scripts verifying Rsyslog runs and accepts connections:

#!/bin/bash
if ! systemctl is-active --quiet rsyslog; then
    echo "Rsyslog service is down"
    exit 1
fi

Schedule periodic certificate renewals for TLS configurations. Expired certificates break encrypted log transmission, disrupting data collection.

Performance monitoring identifies bottlenecks before they impact operations. Review impstats output for queue growth, message drops, or processing delays.

Capacity planning anticipates storage requirements as log volumes grow. Track historical disk usage trends to predict when additional storage becomes necessary.

Congratulations! You have successfully installed Rsyslog. Thanks for using this tutorial for installing Rsyslog open source program for transferring log messages on Debian 13 “Trixie” system. For additional help or useful information, we recommend you check the official Rsyslog website.