Ports

Port 514: Syslog

Common logging transport. UDP 514 is traditional, but reliable and TLS variants exist.

Where you will see it: You will see this in scans, firewall rules, vulnerability reports, and service configs. Treat open ports as exposure points and verify the service is expected, hardened, and restricted.

What it is

Port 514 is widely associated with syslog, a common way devices ship log messages to a central collector. A port is a transport layer number used together with an IP address and a protocol such as TCP or UDP to direct traffic to the correct service on a host. A server process binds a socket to a port and listens, while a client typically chooses an ephemeral source port for outbound connections.

The combination of source and destination IP addresses, source and destination ports, and the transport protocol uniquely identifies a flow so the operating system can keep many conversations separate. Firewalls, NAT, and scanners talk about ports because the destination port is the stable rendezvous point that exposes a service to the network.

Traditionally syslog uses UDP 514: each event is sent as an independent datagram from a sender source port to destination port 514, which keeps overhead low but means messages can be dropped or arrive out of order under congestion. Some deployments use TCP 514 for better delivery behavior, and secure syslog is often done via a TLS wrapped variant on other ports.

In practice, the syslog collector parses, timestamps, and forwards events into SIEM and alerting pipelines, so the port often represents your visibility layer. Security wise, unauthenticated syslog can leak sensitive events or allow spoofed log entries if anyone can send to the collector, which is why access control and trusted sender lists are crucial.

How it works in broad strokes

  1. A device formats an event into a syslog message and sends it to the collector, often over UDP 514.
  2. The collector parses, timestamps, and stores the message, then forwards it to SIEM or alerting pipelines.
  3. If reliability is needed, TCP based syslog or buffered forwarding is used instead of raw UDP.

Concrete example

A firewall sends deny events to a log server on 514. During a DDoS, UDP drops spike and you lose visibility, which is why many teams use buffering or TCP for critical logs.

Why it matters

Central logging is core to detection and troubleshooting. Syslog itself is often unauthenticated and unencrypted, so exposure can leak sensitive events or allow log spoofing. For defenders, open syslog listeners are also a signal to harden and restrict access.

Security angle

  • Restrict who can send to your syslog collector and prefer authenticated, encrypted transports where possible.
  • Buffer on the sender or use TCP to reduce loss during spikes.
  • Normalize and validate sources so spoofed logs are easier to detect.

Common pitfalls

  • Sending syslog over UDP across untrusted networks where messages can be read or altered.
  • Assuming UDP delivery is reliable during incidents when networks are congested.
  • Accepting syslog from any source, enabling spoofed events and noise.