How to configure syslog server in Linux

What is a syslog server?

A syslog server is a system configured to receive, store, and analyze syslog messages sent by Linux servers, network devices, firewalls, and applications. Instead of checking logs individually on each device, a syslog server centralizes all logs into a single location, enabling efficient troubleshooting, monitoring, and security auditing.

Linux supports several syslog daemons, including:

• Rsyslog: default on most modern distributions
• Syslog-ng: advanced filtering and modularity
• Systemd-journald: binary-based logging used in systemd systems

A syslog server listens on:

• UDP 514: fast, but unreliable
• TCP 514: reliable log delivery
• TCP/TLS: secure, encrypted syslog transmission

Learn more about syslogs

How the Linux syslog architecture works

Before configuring a syslog server, it’s important to understand how syslog flows within Linux. A typical syslog pipeline includes:

1. Applications/services generate logs
2. Syslog daemon (rsyslog/syslog-ng/journald) collects, parses, and processes logs
3. Output modules forward logs to a remote syslog server or store them locally

Linux syslog daemons such as rsyslog support both RFC 3164 and RFC 5424. Network devices commonly use RFC 3164, while modern Linux applications typically use RFC 5424, which includes priority, facility, severity, timestamp, hostname, and structured data.

Prerequisites for configuring a syslog server

Before configuring the server:

• Install a syslog daemon such as rsyslog, syslog-ng, or ensure systemd-journald is running.
• Check network connectivity between log sources and the syslog server.
• Ensure firewall rules allow inbound syslog traffic (UDP/TCP 514 or TCP 6514).
• Use root or sudo privileges for configuration changes.
• Enable time synchronization (chrony or NTP) to maintain accurate timestamps.

Configure Rsyslog as a syslog server

Rsyslog is the default syslog daemon in most modern Linux distributions.

Step 1: Install rsyslog (if not installed)

Syntax:

sudo apt install rsyslog     # Ubuntu/Debian
sudo yum install rsyslog   # RHEL/CentOS

Step 2: Enable UDP/TCP reception

Edit /etc/rsyslog.conf and uncomment:

Syntax:

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

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

Step 3: Create a custom log file for remote logs

Add this to /etc/rsyslog.d/remote.conf:

Syntax:

$template RemoteLogs,"/var/log/remote/%HOSTNAME%.log"
*.* ?RemoteLogs

Step 4: Restart rsyslog

sudo systemctl restart rsyslog

Your server is now ready to receive logs over UDP/TCP 514.

Configure syslog-ng as a syslog server

syslog-ng is a flexible, high-performance logging daemon.

Step 1: Install syslog-ng

Syntax:

sudo apt install syslog-ng
sudo yum install syslog-ng

Step 2: Configure sources, destinations, and log paths

Edit /etc/syslog-ng/syslog-ng.conf:

Syntax:

source s_net { udp(port(514)); tcp(port(514)); };

destination d_remote { file("/var/log/remote/$HOST.log"); };

log { source(s_net); destination(d_remote); };

Step 3: Restart syslog-ng

Syntax:

sudo systemctl restart syslog-ng

Configure systemd-journald for remote logging

While systemd-journald does not natively accept remote logs, it can forward logs to a remote syslog server. Starting with systemd 254+, systemd-journal-remote enables native remote journal reception; however, in most production environments especially those requiring multi-vendor log aggregation, forwarding logs to rsyslog or syslog-ng remains the standard approach.

Step 1: Edit journald.conf

Open /etc/systemd/journald.conf and enable forwarding:

Syntax:

ForwardToSyslog=yes

Step 2: Restart systemd-journald

Syntax:

sudo systemctl restart systemd-journald

Step 3: Configure rsyslog/syslog-ng to receive forwarded logs

(Use the steps above accordingly.)

Open firewall ports for syslog

To allow syslog traffic if Firewalld is enabled,

Syntax:

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

If using UFW (Ubuntu/Debian)

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

Verify syslog server connectivity

1. Use logger command to test from a client machine

   Copy

   logger "Test message from client"

2. Check remote log files

   Copy

   tail -f /var/log/remote/*.log

3. Use netcat to test port connectivity

   Copy

   nc -vz <syslog-server-ip> 514

4. Check logs on the server:

   Copy

   sudo tail -f /var/log/remote/*.log

If logs appear, the server is receiving syslogs correctly.

Log rotation

Configure log rotation on the syslog server to prevent log files from growing indefinitely and consuming disk space. For high-availability deployments, consider enabling rsyslog disk-assisted queues (for example, using queue.type="LinkedList"), which buffer logs locally during network outages and forward them once connectivity is restored. This helps prevent log loss in unstable or high-volume environments.

Troubleshooting syslog server issues

If syslogs are not arriving:

1. Check if rsyslog is listening

   Copy

   sudo ss -tulnp | grep 514

2. Verify SELinux

   To allow syslog daemons to write logs:

   Copy

   sudo setsebool -P syslogd_disable_trans 0

   To allow rsyslog to bind to standard ports (UDP and TCP 514):

   Copy

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

   These commands ensure SELinux does not block log writing or port binding, which are common reasons syslogs fail to reach the server.

3. Check for typos in configuration

   Copy

   sudo rsyslogd -N1

4. Verify client configuration

   Ensure the client has the correct forwarding rule:

   Copy

   *.*   @<server-ip>:514     # UDP
   *.*   @@<server-ip>:514    # TCP

   Once your syslog server is up and running, the next step is making your logs easily searchable, correlated, and audit-ready.

After configuring your syslog server: Enhance monitoring with EventLog Analyzer

Setting up a syslog server in Linux ensures your devices can forward logs to a central destination but viewing, filtering, correlating, and analyzing those logs still requires significant manual effort.

EventLog Analyzer transforms your configured syslog server into a full-fledged syslog monitoring solution. Instead of relying on terminal-based grep filters, ad hoc scripts, or scattered log files, the solution consolidates all incoming syslog events into a unified log management console. It automatically parses logs based on attributes like severity, facility, and source, making it easier to interpret high-volume data from routers, firewalls, servers, and applications.

Secure and centralized syslog collection

EventLog Analyzer’s built-in syslog listener (UDP/TCP/TLS) securely receives logs from distributed environments and provides metrics such as message rate, device contribution, and packet flow status. This eliminates the need for separate collectors or additional configuration once your Linux syslog server is set up.

From basic log forwarding to intelligent analysis:

• Centralized log visibility: Aggregate syslog messages from Linux systems and network devices into a single dashboard, no manual navigation across /var/log files.
• Automated parsing and categorization: EventLog Analyzer structures raw syslogs into readable fields, helping you understand issues quickly without command-line decoding.
• Instant filtering: Apply real-time filters using IP, severity, keywords, or event types to isolate relevant logs in seconds.
• Real-time troubleshooting: View streaming syslog events enriched with metadata, giving you real-time troubleshooting similar to tail -f but with actionable intelligence.
• Threat detection: Detect failed login spikes, configuration tampering, abnormal access attempts, and lateral movement with correlation rules.
• Compliance reporting: Map syslog events to th e PCI DSS, the GDPR, HIPAA, ISO 27001, and other regulations for audit-ready reports.

Once your Linux syslog server is configured, EventLog Analyzer brings centralized visibility, powerful threat detection, and automated workflows, turning raw syslogs into actionable insights.

FAQ

logger "Test message"

logger -n <server_ip> -P 514 "Test message".

*.* @<server_ip>:514 for UDP or
*.* @@<server_ip>:514 for TCP.

What's next?