Port 514: Syslog — The Diary of Every Unix Machine

Port 514 carries syslog traffic. Every time a server logs a message, every kernel panic, every failed authentication attempt, every daemon starting up or shutting down, there is a good chance that message flows through port 514. This port has been listening to the confessions of machines since 1983.

What Syslog Does

Syslog is a protocol for transmitting log messages across a network. A device generates a message, wraps it in a simple format, and sends it to a collector listening on UDP port 514. That's it. No handshake. No acknowledgment. No encryption. The message goes out, and the sender moves on with its life.

The format is elegantly simple. Every syslog message starts with a priority value in angle brackets, like <34>. This number encodes two pieces of information: the facility (what kind of system generated the message) and the severity (how urgent the message is). The formula is: Priority = (Facility × 8) + Severity.¹

There are 24 facilities (0-23): kernel messages, user-level messages, mail system, system daemons, security and authorization, and so on. Facilities 16 through 23 are reserved for "local use," which means applications can claim their own logging category.²

There are 8 severity levels (0-7), from Emergency (0) down to Debug (7):

So when you see <34> at the start of a syslog message, you can decode it: 34 ÷ 8 = 4 remainder 2. Facility 4 is security/authorization. Severity 2 is Critical. Someone just tried to break in, and the machine wants you to know.³

The Story Behind Port 514

In the early 1980s, Eric Allman was a programmer at the University of California, Berkeley, working on the Sendmail project. Sendmail was becoming the Internet's first major mail transfer agent, and Allman needed a way to log what the mail system was doing. He needed to know when mail was delivered, when it failed, and why.⁴

So he wrote syslog.

The first implementation appeared in 4.2BSD Unix, released in August 1983.⁵ This was the same release that introduced TCP/IP networking to BSD, the same release that laid the foundation for the modern Internet. Syslog shipped alongside it, quietly, as part of the package.

What Allman created was not just a logging system for Sendmail. He created an API, a daemon, and a protocol. The syslog() function let any application submit log messages. The syslogd daemon collected them. And the protocol let messages travel across the network to a central collector.⁶

Other programs started using it. Then other operating systems. Then network devices. Routers, switches, firewalls, load balancers. Anything that needed to tell an administrator what was happening inside it started speaking syslog. The protocol became a de facto standard long before anyone wrote it down officially.

The IETF didn't formally document syslog until 2001, when RFC 3164 described what BSD syslog had been doing for nearly two decades.⁷ That RFC was explicitly descriptive, not prescriptive. It documented "the status quo." By then, syslog was everywhere, and the best the IETF could do was write down what everyone was already doing.

In 2009, RFC 5424 updated the protocol with a more structured format, support for Unicode, and a layered architecture that separated the message format from the transport.⁸ But the original BSD syslog format is still widely used. Some things are too embedded to change.

In 2014, Eric Allman was inducted into the Internet Hall of Fame. The citation recognized both Sendmail and syslog, calling the latter "the de facto standard logging mechanism used in nearly all open systems and peripherals."⁹

How Syslog Works

The protocol itself is almost embarrassingly simple.

A syslog message is a single UDP packet sent to port 514. The packet contains:

1. PRI: The priority value in angle brackets
2. HEADER: A timestamp and hostname
3. MSG: The actual log message

That's it. The sender opens a connection, fires off the message, and closes the connection. No waiting for acknowledgment. No retry if the packet gets lost. No encryption to protect the contents. The protocol assumes that logging should be fast and non-blocking, and that some message loss is acceptable.¹⁰

The RFC recommends that the source port also be 514, to indicate that the message is coming from a proper syslog process, but this is not required.¹¹

This simplicity is both syslog's greatest strength and its most dangerous weakness.

The Security Problem

Syslog over UDP port 514 has essentially no security. None.

No encryption: Messages travel in plaintext. Anyone who can see network traffic can read every log message. Error messages, authentication failures, system states, potentially sensitive operational data, all visible to anyone with a packet sniffer.¹²

No authentication: Syslog does not verify the identity of the sender. Anyone can send a syslog message claiming to be any device. Attackers can spoof source IP addresses to inject false log entries, potentially hiding their activities or framing other systems.¹³

No integrity checking: There is no way to verify that a message was not modified in transit. If someone intercepts and alters a log message, the receiver has no way to know.¹⁴

No delivery guarantee: UDP does not guarantee delivery. Messages can be lost, duplicated, or arrive out of order. In a high-traffic environment, or during a network event (which is precisely when you most need your logs), messages can vanish.¹⁵

Vulnerable to replay attacks: Captured syslog messages can be retransmitted later. There is no protection against someone recording your log traffic and playing it back to confuse your monitoring systems.¹⁶

Susceptible to denial of service: Because UDP is connectionless and syslog performs no authentication, it is trivial to flood a syslog collector with garbage messages, potentially overwhelming the system or filling up disk space.¹⁷

For decades, the security community has been saying that syslog over UDP 514 is a terrible idea for sensitive environments. They are correct. And yet, it persists, because it works, it is everywhere, and secure alternatives require more effort to deploy.

The Secure Alternative: Port 6514

RFC 5425, published in 2009, defines syslog over TLS on TCP port 6514.¹⁸ This addresses most of syslog's security problems:

• Encryption: TLS encrypts all traffic, preventing eavesdropping
• Authentication: TLS certificates can verify both sender and receiver
• Integrity: TLS includes integrity checking to detect modifications
• Reliable delivery: TCP guarantees delivery and ordering

The tradeoff is complexity. TLS requires certificate management. TCP is heavier than UDP. Setting up secure syslog requires more configuration than just pointing a device at an IP address.

For environments handling sensitive data, compliance requirements, or facing sophisticated threats, port 6514 with TLS is the right answer. For a home lab or an isolated test network, UDP 514 is often "good enough."

Syslog Today

Forty years after its creation, syslog remains foundational to how we monitor infrastructure.

Modern SIEM (Security Information and Event Management) systems consume syslog as a primary data source.¹⁹ Network devices from every major vendor speak syslog. Cloud platforms accept syslog input. The protocol has been extended, layered, secured, and built upon, but the core idea remains: machines need a way to say what is happening to them, and other machines need to listen.

The evolution continues. RFC 5424 introduced structured data fields that allow richer, more parseable messages. Modern log aggregation systems like Elasticsearch, Splunk, and Graylog can ingest syslog alongside other log formats. API-based logging has emerged for cloud-native applications. But syslog persists as the common denominator, the lingua franca of machine logging.²⁰

When your server crashes at 3 AM and you need to know why, you will likely find yourself reading syslog messages. When you investigate a security incident and need to know what happened across dozens of devices, syslog will be there. When you set up monitoring for a new system and need it to tell you when something goes wrong, you will probably configure it to send syslog to port 514.

Related Ports