Port 514 – Syslog

UDP

Port 514 is the traditional Syslog port where network devices send log messages over UDP. UDP syslog has no delivery guarantee, no encryption, and no authentication – messages can be lost, spoofed, or intercepted. Use syslog over TLS (port 6514, RFC 5425) for production log collection.

Port Number

514

Protocol

UDP

Service

BSD Syslog Protocol

Range

IANA Well-Known (0–1023)

Description

BSD Syslog on UDP port 514 is the original centralized logging protocol. Network devices, firewalls, and Unix systems send structured log messages (facility + severity + message) to a central syslog collector. The protocol is intentionally simple – fire and forget over UDP. UDP syslog on port 514 has fundamental limitations for production use: messages can be silently dropped during network congestion, there is no authentication (any host can inject fake logs), and content travels in cleartext. Rsyslog and syslog-ng support RELP (Reliable Event Logging Protocol) and syslog over TLS to address these gaps. Modern deployments use port 514 only for legacy devices that cannot support encrypted transports.

Security risks

1Log injection: syslog accepts messages from any source without authentication – attacker sends crafted log entries that pollute analysis, trigger false alerts, or inject terminal escape sequences (CVE-2009-0241 in rsyslog)
2UDP has no delivery guarantee: critical security logs (authentication failures, firewall blocks) can be silently dropped during network congestion or DoS – you don't know what you don't know
3Plaintext transmission: all log data (usernames, source IPs, error details, potentially credentials in debug logs) sent in cleartext UDP – trivial to intercept
4Log flooding / DoS: overwhelming port 514 with fake syslog messages causes legitimate logs to be dropped, creating blind spots during an active attack
5Spoofed source: UDP syslog has no source authentication – attacker can send logs appearing to come from any device, framing innocent systems or hiding the real source of malicious activity

Firewall guidance

Migrate to TCP 6514 (syslog over TLS, RFC 5425) for production logging. If UDP 514 must remain: restrict inbound to known device subnets only. On the syslog server: configure rate limiting ($SystemLogRateLimitInterval/$SystemLogRateLimitBurst in rsyslog) to survive flood attacks. Never accept syslog from the internet.

Diagnosis commands

Send a test syslog message to verify connectivity

shell

logger -n syslog-server -P 514 'test message from $(hostname)'

Capture syslog traffic to verify messages are arriving (and check for unexpected sources)

shell

tcpdump -i eth0 -n udp port 514 -c 5

Check which process is bound to syslog port

shell

ss -ulnp | grep 514

Validate rsyslog configuration syntax before restart

shell

rsyslogd -N1

Usage examples

Port 514 – Syslog

shell

logger -n syslog.example.com -P 514 'Test message'
tcpdump -i eth0 udp port 514
rsyslogd -f /etc/rsyslog.conf

Common services on this port

rsyslogsyslog-ngFluentd (syslog input)GraylogSplunk (UDP input)QRadar

Related ports

514

Syslog UDP (this port, insecure)

601

Syslog over TCP (reliable)

6514

Syslog over TLS (RFC 5425, secure)

1514

Syslog alternate (common for TLS)

History

Syslog was created at UC Berkeley in the early 1980s as part of the Sendmail project. The BSD syslog protocol (RFC 3164, 2001) formalized the existing practice. Port 514/UDP was the traditional assignment. RFC 5424 (2009) modernized the message format, and RFC 5425 (2009) defined syslog over TLS on port 6514. Despite being over 40 years old, UDP syslog remains the default on most Linux systems and network equipment.

FAQ

How do I switch from UDP 514 to TLS syslog?

rsyslog: load imtcp and set StreamDriver to gtls. Server config: module(load='imtcp' StreamDriver.Name='gtls' StreamDriver.Mode='1' StreamDriver.Authmode='x509/name'), input(type='imtcp' port='6514'). Client: action(type='omfwd' Target='server' Port='6514' Protocol='tcp' StreamDriver='gtls' StreamDriverMode='1'). Generate certs with openssl. Most modern SIEM agents (Splunk UF, Elastic Agent) use TLS by default.

rsyslog vs syslog-ng vs Fluentd?

rsyslog: default on RHEL/Ubuntu, high performance (1M+ msg/sec), complex config syntax (RainerScript). syslog-ng: cleaner config (SCL blocks), native JSON parsing, commercial support (One Identity). Fluentd: Ruby-based, 900+ plugins, cloud-native (CNCF), best for Kubernetes. For pure syslog collection: rsyslog (fastest, lowest resource). For Kubernetes: Fluentd/Fluent Bit. For complex routing: syslog-ng.

Specification

RFC 5424 – Port 514 specification →