Syslog Explained: RFC 5424 Format, TLS Transport and Reliable Logging

Syslog is the protocol that carries event log messages from devices and applications to a relay or collector. RFC 5424 (March 2009) defines the message format and replaced the legacy BSD format described in RFC 3164, while separate RFCs define how those messages travel: UDP (RFC 5426), TLS over TCP (RFC 5425) and DTLS (RFC 6012).

Almost every router, firewall, hypervisor, Linux host and appliance can speak syslog, which is why it is still the default plumbing for security logs more than four decades after it appeared in BSD. That ubiquity hides a lot of variation. Two devices can both "send syslog" and disagree on the header format, the transport, the framing on a TCP stream and whether anything is encrypted or authenticated. This post walks through the protocol end to end: the RFC 5424 message, the four transports and their framing, the security properties the standards themselves admit to, the 2024 cipher suite update, and how to configure and verify TLS forwarding in rsyslog and syslog-ng. Our earlier post, is syslog over UDP safe for security logs?, answers one narrow question; this one covers the whole protocol family.

Key takeaways

• RFC 5424 is the current syslog standard. It obsoletes RFC 3164, which was only ever an Informational description of how BSD syslog behaved in the field, and it separates the message format from the transport so each can evolve on its own.
• An RFC 5424 message is a PRI value (facility times 8 plus severity), a VERSION of 1, an RFC 3339 timestamp, HOSTNAME, APP-NAME, PROCID and MSGID, then optional STRUCTURED-DATA and the free text MSG.
• RFC 5424 says every implementation MUST support the TLS transport (RFC 5425, TCP port 6514) and recommends deployments use it. UDP on port 514 (RFC 5426) is a SHOULD, kept for compatibility. DTLS (RFC 6012) uses UDP or DCCP port 6514.
• Plain syslog over TCP (RFC 6587) is a Historic document, not a standard. It has no assigned port, and its common "traditional" newline framing can split or merge messages. Octet counting fixes that.
• Syslog itself has no acknowledgments, no replay detection, no confidentiality and no origin authentication. TLS gives you hop by hop confidentiality, integrity and peer authentication. Only signed syslog (RFC 5848) authenticates the message itself, end to end, and it is rarely deployed.
• RFC 9662 (October 2024) updates the TLS and DTLS mappings: implementations should offer TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, prefer TLS 1.3 where implemented, must not use DTLS 1.0 and must not use TLS 1.3 early data.
• In rsyslog, the setting that matters most is the authentication mode: use x509/name with explicit permitted peers, not anon. In syslog-ng, keep peer-verify(required-trusted), the default, and restrict old protocol versions with ssl-options().

What syslog is for, where it sits and which standards define it

Syslog solves a simple problem. Many programs on many machines produce event messages, and operators want those messages in one place, in time order, where they can be searched, alerted on and kept. Syslog defines a small text message with a priority, a timestamp and a source, and a way to push it, one direction only, toward a collector.

It is an application layer protocol. It does not define its own transport; it runs over UDP, TCP, TLS over TCP, or DTLS over UDP or DCCP, depending on which transport mapping you configure.

RFC 5424 describes three roles that matter for everything that follows:

On the network, the standards also talk about a "transport sender" and a "transport receiver", because a relay is a receiver on one side and a sender on the other. That distinction is the root of one of syslog's biggest security limits: every protection on the wire is per hop.

The standards family, and what each one does

Syslog is not one RFC but a set of documents that each do one job. These are the ones that define the protocol today, with their status as listed by the RFC Editor.

RFC 5424's introduction explains why the split exists. Efforts to standardise reliable and secure syslog kept stalling because there was no transport independent, standards track definition of the message itself. Without one, each new transport would have to define its own packet format. RFC 5424 is that foundation, and RFC 5424 states plainly that it does not define any storage format: what a collector does with messages on disk is out of scope.

For the policy side, NIST SP 800-92, Guide to Computer Security Log Management (September 2006), is still the published final NIST guidance on building log management infrastructure. A revision, SP 800-92 Rev. 1, Cybersecurity Log Management Planning Guide, was released as an initial public draft on 11 October 2023, with comments closing on 29 November 2023. The CSRC page we fetched shows it still as a draft.

How syslog works on the wire

Message flow

RFC 5424 describes syslog as conceptually simplex: the originator sends; nothing comes back at the syslog layer. Some transports give status at lower layers (TCP acknowledgments, TLS alerts), but there is no syslog level acknowledgment of any message.

Here is the full exchange for the recommended transport, TLS over TCP, between an originator and a collector, with one relay in between.

Originator (TLS client)          Relay (TLS server, then TLS client)        Collector (TLS server)
      |                                   |                                        |
      |--- TCP SYN to port 6514 --------->|                                        |
      |<-- SYN-ACK -----------------------|                                        |
      |--- ACK -------------------------->|                                        |
      |--- TLS ClientHello -------------->|                                        |
      |<-- ServerHello, Certificate ... --|   (client checks server certificate)   |
      |--- Certificate, Finished ... ---->|   (server checks client certificate)   |
      |                                   |                                        |
      |--- "84 <34>1 2026-10-23T..." ---->|  (octet counted frames inside TLS)     |
      |--- "112 <165>1 2026-10-23T..." -->|                                        |
      |                                   |--- separate TCP + TLS session -------->|
      |                                   |--- re-framed messages ---------------->|
      |                                   |                                        |
      |--- TLS close_notify ------------->|                                        |
      |<-- TLS close_notify --------------|                                        |
      |--- TCP FIN ---------------------->|                                        |

Three details from RFC 5425 shape this flow. The transport sender is always the TLS client and the receiver is always the TLS server. The sender may send the first syslog message only once the TLS handshake has finished. And at shutdown the sender must send a TLS close_notify alert before closing, while the receiver must reply with its own close_notify unless it already knows the connection is gone.

With UDP (RFC 5426) there is no setup at all. Each datagram carries exactly one syslog message, complete or truncated, to UDP port 514, with nothing else in the payload. With DTLS (RFC 6012) the sender first completes a DTLS handshake, optionally including a cookie exchange in which the receiver replies with a Hello Verify Request, and must not send any syslog message before that handshake succeeds.

The RFC 5424 message, field by field

RFC 5424 defines the message in ABNF. In plain terms:

SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG]
HEADER     = PRI VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID

The header layout, with the limits the ABNF sets:

The hyphen is the NILVALUE: it means "no value", and it is how a message says it does not know its timestamp, its hostname or its message type. Every header field after VERSION is separated by a single space, and the printable character limits in the header (US-ASCII 33 to 126) exist partly for security, as covered below.

RFC 5424's first worked example shows every part:

<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 - BOM'su root' failed for lonvick on /dev/pts/8

PRI is 34, which decodes to facility 4 and severity 2. VERSION is 1. The timestamp is 11 October 2003, 22:14:15.003 UTC. The host is mymachine.example.com, APP-NAME is su, PROCID is unknown, MSGID is ID47, there is no structured data, and the MSG is UTF-8 because it starts with a byte order mark.

Facility and severity

The PRI value packs two numbers into one. RFC 5424 gives the formula: multiply the facility by 8 and add the severity. A kernel emergency (facility 0, severity 0) is PRI 0. A "local use 4" notice (facility 20, severity 5) is PRI 165. Leading zeros are not allowed except for PRI 0 itself.

The standard calls the facility and severity tables informational, not normative, but every implementation uses them.

Lower numbers are more severe. That matters operationally, because RFC 5424 recommends that if a sender must drop messages, it should drop the lower severity ones (higher numbers) first.

Two facilities (4 and 10) are both labelled security and authorization, and two (9 and 15) are both clock daemon; RFC 5424 keeps both pairs because different operating systems historically used different values. The eight local facilities are where most appliances and custom applications put their logs, which is why a filter on "auth" alone often misses security events from network devices.

Structured data

STRUCTURED-DATA is the part of RFC 5424 that BSD syslog never had. It carries name and value pairs inside square brackets, each element starting with an SD-ID:

[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"][examplePriority@32473 class="high"]

SD-IDs come in two forms. Names without an at sign are reserved for IETF registration with IANA. Anyone else defines their own as name@ followed by their IANA private enterprise number; 32473 is the number IANA reserved for documentation examples. The same SD-ID must not appear twice in one message, and inside a parameter value the characters double quote, backslash and closing square bracket must be escaped.

RFC 5424 registers three SD-IDs of its own:

timeQuality is worth turning on where your implementation supports it. RFC 5424 says it should be written when the originator is not properly synchronised to a reliable external time source, which is exactly the case where an investigator needs to know not to trust the timestamp.

Message size

RFC 5424 sets no upper limit itself; each transport does. Every receiver must accept at least 480 octets and should accept 2048. The transports then add their own numbers.

Ports and IANA registrations

From the IANA service name and port registry:

That last row is the source of endless confusion. RFC 6587 notes that plain TCP syslog has no standardised port, and that the most frequently used choice, TCP 514, "is actually assigned to the Shell protocol". The syslog-ng documentation, for its syslog() driver, lists default ports of UDP 514, TCP 601 and TLS 6514, so two popular implementations can disagree on where plain TCP syslog lives. Always set the port explicitly on both ends.

Transports compared: UDP, TCP framing, TLS and DTLS

UDP (RFC 5426)

RFC 5426 matches the traditional behaviour: one message per datagram, receivers must listen on UDP 514, senders may use any source port. It insists on UDP checksums: senders must not disable them, and receivers must not disable checksum checks. Its own security section is candid. It provides no strong sender authentication and no protection against forgery; a receiver cannot tell whether a message came from the host named in it or from anywhere else on the network.

RFC 5424 goes further. Because UDP has no congestion control and syslog can generate unlimited data, it says UDP may only be used as an alternative to TLS on managed networks where the path has been explicitly provisioned for syslog traffic, for example by rate limiting or capacity reservation. "In all other environments, the TLS transport SHOULD be used."

Plain TCP and the framing problem (RFC 6587)

Plain TCP syslog grew up without a standard, and RFC 6587 was published in April 2012 as a Historic document to record how it works, not to recommend it. Its applicability statement says new implementations and deployments should not use it except to interoperate with existing ones.

TCP is a byte stream, so a receiver needs to know where one message ends and the next begins. RFC 6587 describes the two methods seen in the field:

RFC 6587 also records that some legacy senders change framing method frame by frame, which it describes as probably not a good idea, but seen.

rsyslog's omfwd documentation describes the same trade-off from the implementer's side. Its TCP_Framing parameter defaults to traditional, meaning messages end at a line feed, so a multi-line message gets broken into several. The documentation recommends octet-counted whenever the receiver supports it.

TLS (RFC 5425)

RFC 5425 is the mandatory and recommended transport. It identifies three primary threats (masquerade, modification and disclosure) and says TLS counters all three: confidentiality against disclosure, integrity checks against modification on a hop, and server or mutual authentication against masquerade. It explicitly leaves denial of service and traffic analysis out of scope.

Inside the TLS session, messages are sent as application data using octet counting, so there is no newline ambiguity:

APPLICATION-DATA = 1*SYSLOG-FRAME
SYSLOG-FRAME     = MSG-LEN SP SYSLOG-MSG

Several messages can share one TLS record, or one message can span several records; the length prefix is what delimits them.

Authentication is certificate based, and both sides must implement it. RFC 5425 gives two ways to decide whether a certificate is acceptable:

1. Certification path validation, against a trusted CA, plus a check that the subject name belongs to an authorised peer.
2. End-entity certificate matching, where each side is configured with the fingerprints of the certificates it accepts. Those certificates may be self-signed. Implementations must support SHA-1 fingerprints written as sha-1: followed by colon separated upper case hex, for example sha-1:E1:2D:53:....

Both sides must also be able to generate a key pair and self-signed certificate if none is provided. That is convenient for small deployments, and it is also why "TLS is on" does not tell you anything about whether the peer was actually checked.

DTLS (RFC 6012)

RFC 6012 brings TLS style protection to datagram transports for environments where TCP's head of line blocking or connection state is unwelcome. Implementations must support DTLS over UDP and should support DTLS over DCCP, both on port 6514. DTLS adds a cookie exchange during the handshake to counter denial of service, and a record sequence number to counter replay. As published in 2010 it required DTLS 1.0; RFC 8996 deprecated DTLS 1.0, and RFC 9662 now says implementations must not use it and must use DTLS 1.2, preferring DTLS 1.3 where implemented.

rsyslog ships an omdtls output module for this, and its forwarding documentation points to it when you need encrypted UDP.

Versions and history

BSD syslog (to 2001). Syslog started in BSD Unix and spread to almost every operating system and network device without a formal specification. RFC 3164 (August 2001) describes how it had been observed to behave, and it is Informational, not a standard. Its format is a PRI, a local time timestamp in the form Mmm dd hh:mm:ss with no year and no time zone, a hostname and the message, in a packet of 1024 bytes or less over UDP port 514.

RFC 3195 (November 2001). An early attempt at reliable syslog over the BEEP framework, with port 601. It is the reference for IANA's syslog-conn registration, and rsyslog later built its own reliable protocol, RELP, which its documentation suggests via omrelp when reliable delivery is critical. RELP is an rsyslog protocol, not an IETF standard.

2009 to 2024. RFC 5424, 5425 and 5426 arrived together in March 2009, adding the VERSION field, timestamps with years, time zones and fractions, UTF-8 bodies, APP-NAME, PROCID, MSGID and structured data, and making TLS mandatory to implement. Signed syslog (RFC 5848) and DTLS (RFC 6012) followed in 2010, the Historic TCP description (RFC 6587) in 2012, and the cipher suite refresh (RFC 9662) in October 2024.

In practice you will still find plenty of BSD style syslog over UDP 514, especially from network devices, plain TCP with newline framing between servers, and TLS on 6514 wherever someone chose to protect logs in transit. Many receivers accept both message formats on one port, which is why a collector can hold timestamps with no year.

Security properties: what syslog guarantees and what it does not

RFC 5424's security considerations run to twelve subsections. Read together with RFC 5425 and RFC 5426, they give a clear picture.

The key sentence comes from RFC 5425: TLS "only secures syslog transport in a hop-by-hop manner", and the authenticated identity of the sender need not have anything to do with the HOSTNAME field in the message. A relay that authenticates perfectly to your collector can still forward a message that claims to come from any host at all. rsyslog's own TLS guide makes the same point: TLS authenticates only the last sender, not the message.

Weakness classes, described as concepts

These are the classes of problem the standards themselves describe. They are explained here so you can recognise and design against them, not as instructions.

Spoofed sources and forged messages

Over UDP, nothing ties a message to the machine that sent it. RFC 5426 describes two consequences in its own words. A flood of forged messages about one machine can pull administrators' attention away while something else happens, and a forged "process restarted" message can paper over a process that was actually stopped. Even the HOSTNAME field is just text the sender chose. TLS with certificate checks closes this on each hop; it does not close it for messages that a relay forwards on behalf of others.

Message loss and truncation

Syslog has no acknowledgments, and RFC 5424 notes that messages may be dropped by congestion or deliberately intercepted and thrown away by an attacker hiding activity. Over UDP, a single lost fragment loses the whole message, which is why RFC 5426 advises keeping messages under the path MTU, with 480 octets for IPv4 and 1180 for IPv6 as the safe assumption. Over TCP and TLS, RFC 5425 points out that when a connection breaks, the sender cannot always tell which messages actually arrived.

Truncation is a separate risk. Receivers may truncate or drop messages above the size they support, and RFC 5424 warns that an attacker can abuse truncation to hide important log content. Its advice: keep messages small, put the important information early, and limit the size of user supplied data inside a message.

RFC 5424 also makes a point that surprises people: fully reliable delivery is not always desirable. If a syslog daemon blocks because the collector cannot keep up, a system that depends on that daemon can stall. The standard's answer is for a sender to discard knowingly when it must, and tell the collector that it did, rather than block or lose messages silently.

Injection through log fields

RFC 5424 restricts header fields to printable US-ASCII, but imposes no mandatory restriction on MSG or structured data parameter values. Its security section lists what can go wrong with that freedom, at a concept level:

• NUL characters. Code written in C and C++, and many tools built on it, treats NUL as the end of a string, so anything after a NUL may be hidden, and an unexpected NUL can break integrity checks carried inside the message.
• Other control characters. A backspace or similar character can make parts of a message unreadable when it is displayed.
• Invalid UTF-8. Malformed sequences can be used to smuggle ASCII control characters past filters.
• Visual spoofing. Characters that look alike in Unicode can make one name look like another, which is why RFC 5424 limits Unicode to the fields where local script is needed and says those fields should not be the primary source of identifying information.

Non-transparent TCP framing adds a protocol level version of the same issue: if the trailer is a line feed and nobody escapes line feeds inside messages, one message containing a newline is read as two. The real risk lives in the tools downstream that parse, display or act on log text. Treat every log field as untrusted input in anything that consumes it.

Tampering in transit and at rest

RFC 5424 notes that an attacker positioned between sender and receiver may modify messages to hide activity, and that clear text messages can be read by anyone who can observe them, revealing information useful for further attacks. TLS and DTLS address both, per hop. Nothing in the syslog standards protects what is stored on the collector. RFC 5848 signatures can be verified offline against stored logs later, which is the closest the standards come to tamper evidence at rest.

Replay

RFC 5424 says plainly that there is no replay detection. Someone who records messages showing normal activity could replay them later with adjusted timestamps, and the collector would see nothing odd. It suggests cryptographic signing as the countermeasure.

Denial of service, misconfiguration and loops

The remaining classes are operational. An attacker can fill a collector's disk with false messages or simply overwhelm a receiver; RFC 5424 suggests accepting messages only from known addresses. Senders can be misconfigured to send to the wrong collector, which a reliable transport can detect only if the wrong destination is not listening. And two relays configured to forward a severity to each other create a forwarding loop that RFC 5424 warns can degrade both the network and the devices involved.

What signed syslog (RFC 5848) adds

RFC 5848 adds origin authentication, message integrity, replay resistance, message sequencing and detection of missing messages, which is everything the transport mappings cannot provide end to end. It works by sending extra syslog messages alongside the normal ones:

• Signature Blocks, carried in structured data with the SD-ID ssign, each holding the hashes of a group of previously sent messages and a signature over them. Fields include a reboot session ID, a signature group, a global block counter, the first message number and a count, so a verifier can spot gaps.
• Certificate Blocks, with the SD-ID ssign-cert, which carry key material such as an X.509 or OpenPGP certificate, split across several messages if needed.

Version 01 of the scheme defines SHA1 and SHA256 as hash algorithms (SHA1 must be supported, SHA256 should be) and OpenPGP DSA as the signature scheme. Because the signer hashes each complete message, messages must not change in transit, and RFC 5848 warns that relays which truncate messages over 2048 octets, or reformat messages that are not strictly RFC 5424, will break verification. That fragility, and the age of its algorithm choices, help explain why signed syslog is rarely seen in practice. If you need tamper evidence today, most teams combine TLS on every hop with integrity controls on the collector's storage.

What RFC 9662 changed in the cipher suite requirements

RFC 5425 required TLS 1.2 and the mandatory to implement suite TLS_RSA_WITH_AES_128_CBC_SHA. RFC 6012 required DTLS 1.0 with the same suite. By 2024 both choices were out of step with current TLS guidance: RSA key transport offers no forward secrecy, and DTLS 1.0 was deprecated by RFC 8996.

RFC 9662, published in October 2024, updates both documents. (Its abstract refers to "RFC 5245" where it means RFC 5425; the header and body make clear the target is RFC 5425.)

Two design choices are worth understanding. First, the ECDHE suite still uses RSA certificates for authentication, so devices that already carry RSA certificates do not need new ones to move to forward secret key exchange. Second, RFC 9662 deliberately keeps the old suite as a transition option because the installed base is slow to update; its security considerations ask administrators to decide case by case whether a device that only supports the old suite should still be allowed until it can be upgraded.

The early data ban follows from syslog's own design. TLS 1.3 early data is not forward secret and has no protection against replay between connections, and syslog has no replay protection of its own, so RFC 9662 rules it out. Our post on TLS 1.3 0-RTT early data and replay risk explains the mechanism, and forward secrecy explained covers why the RSA key transport suite is being retired. For which TLS versions and suites to disable generally, see TLS 1.3 vs TLS 1.2: what to disable.

Secure configuration, with defender-side check commands

Everything below comes from the rsyslog, syslog-ng, OpenSSL and Linux man page documentation linked in the sources. Only run these commands against systems you own or are authorised to test.

Step 1: decide the transport and the trust model

Following RFC 5424 and RFC 5425, the default should be TLS on TCP 6514 with mutual certificate authentication. Before touching configuration, decide how peers will be authorised:

• A private CA with name checks. Every sender and receiver gets a certificate from your logging CA, and each side checks both the chain and the peer's name. This scales best.
• Pinned fingerprints. Each side lists the certificate fingerprints it accepts. Simple for a handful of hosts, painful to rotate across hundreds.

Whichever you choose, protect private keys. Both the rsyslog and syslog-ng guides stress that keys should be readable only by the service, and rsyslog's guide notes that if a private key leaks, the system "does not provide any security at all".

Step 2: configure rsyslog TLS forwarding

rsyslog's omfwd output module forwards over TLS when you set a TLS capable stream driver (ossl for OpenSSL, gtls for GnuTLS or mbedtls) and set the driver mode to 1. The documentation is explicit that naming a TLS capable driver "does not activate TLS by itself"; mode 1 does. A sender configured along the lines of rsyslog's own examples:

global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/key.pem"
)

action(
  type="omfwd"
  target="logs.example.com"
  port="6514"
  protocol="tcp"
  StreamDriver="ossl"
  StreamDriverMode="1"
  StreamDriverAuthMode="x509/name"
  StreamDriverPermittedPeers="logs.example.com"
  queue.type="linkedList"
)

The authentication mode is the setting that decides whether TLS protects you. rsyslog's OpenSSL driver documentation lists four:

Two further options are worth knowing. StreamDriver.PrioritizeSAN="on" makes name checks follow RFC 6125, using the Subject Alternative Name and ignoring the CN when a SAN is present. And the documentation recommends always defining a queue (queue.type="linkedList") on TCP forwarding so the sender does not block when the collector is unavailable, which is the behaviour RFC 5424's reliability section asks for.

On the receiving side, rsyslog's imtcp input takes the matching options: StreamDriver.Name, StreamDriver.Mode, StreamDriver.AuthMode and PermittedPeer, plus AllowedSender to restrict by address. One caution: the server example in rsyslog's TLS tutorial sets StreamDriver.Authmode="anon" on the listener even though the surrounding text describes restricting peers by name. Set x509/name and a PermittedPeer list on the listener if you want the collector to authenticate its senders.

If both ends speak plain TCP and you cannot use TLS yet, set TCP_Framing="octet-counted" on the sender when the receiver supports it, so multi-line messages survive.

Check the configuration before restarting the service. The rsyslogd man page documents a configuration check mode that does not start logging:

rsyslogd -N1 -f /etc/rsyslog.conf

Step 3: configure syslog-ng TLS forwarding

syslog-ng encrypts with transport("tls") and a tls() block on its network() driver (for BSD style messages) or its syslog() driver (for RFC 5424 messages with octet counting). A mutual TLS destination along the lines of the syslog-ng documentation:

destination d_tls_collector {
  syslog("logs.example.com" port(6514)
    transport("tls")
    tls(
      ca-dir("/etc/syslog-ng/ca.d")
      key-file("/etc/syslog-ng/key.d/client.key")
      cert-file("/etc/syslog-ng/cert.d/client_cert.pem")
      peer-verify(required-trusted)
      ssl-options(no-sslv2, no-sslv3, no-tlsv1, no-tlsv11)
    )
  );
};

The receiving source uses the same syslog() or network() driver with transport("tls") and the server's key, certificate and CA directory.

The peer-verify() table in the syslog-ng documentation is the one to read carefully:

With an untrusted setting, syslog-ng accepts a certificate "even if it is expired, signed by an unknown CA, or its CN and the name of the machine mismatches". The default, required-trusted, is the one to keep. The documentation also notes that the connection fails if the server certificate's CN or subject alternative name does not contain the hostname or IP address the client resolved, and that ssl-options(ignore-hostname-mismatch) turns that check off; avoid it.

On protocol versions, ssl-options() defaults to no-sslv2 only, and anything else depends on the OpenSSL build, so set the versions you want to exclude explicitly. Newer releases (4.5 and later) also accept ssl-version(). Cipher selection is through cipher-suite() or, for finer control including TLS 1.3 suites, openssl-conf-cmds(). To meet RFC 9662, make sure ECDHE suites with AES-GCM are available and preferred; the documentation notes that from version 3.10 the server's cipher order takes precedence.

Check the configuration with the syslog-ng binary itself. Per its manual page, --syntax-only catches syntax errors, and --check-startup (4.5 and later) performs a full initialisation and exits, though it is likely to fail if another instance is already holding the network listeners.

syslog-ng --syntax-only
syslog-ng-ctl stats

syslog-ng-ctl stats prints per source and per destination counters, including dropped messages, which is how you notice a destination that has been quietly discarding logs.

Step 4: confirm the listener and what it accepts

First, check what the collector is listening on. From the ss man page, -t and -u select TCP and UDP sockets, -l shows listening sockets, -n skips name resolution and -p shows the owning process:

ss -tlnp
ss -ulnp

On a collector that should only accept TLS, you expect a TCP listener on 6514 owned by rsyslogd or syslog-ng, and you should be able to explain every UDP 514 or TCP 514 listener you see.

Then check the TLS handshake from a host you control, using OpenSSL's s_client. Its documentation describes -connect host:port, -CAfile, -cert and -key for presenting a client certificate, -verify_return_error to abort on a verification failure, -brief for a short summary of the negotiated protocol and cipher, and the version options -tls1_2 and -tls1_3:

openssl s_client -connect logs.example.com:6514 -CAfile ca.pem -cert client.pem -key client.key -verify_return_error -brief
openssl s_client -connect logs.example.com:6514 -CAfile ca.pem -tls1_3 -brief
openssl s_client -connect logs.example.com:6514 -CAfile ca.pem -brief

Read the results this way:

• The first command should complete and report the protocol version and cipher. Check that the cipher uses ECDHE key exchange, which is what RFC 9662 asks implementations to prefer.
• Running without -cert and -key (the third command) should fail if the collector requires client certificates. If it succeeds and the server accepts data, the collector is not authenticating senders.
• The -tls1_3 check tells you whether the collector offers TLS 1.3, which RFC 9662 says should be supported and, if implemented, preferred.

Step 5: control exposure and volume

• Accept syslog only from the networks and hosts that should send it. RFC 5424 suggests accepting messages only from known addresses; rsyslog's AllowedSender and host firewalls do this.
• Do not expose UDP 514 or plain TCP to the internet. Where legacy devices can only send UDP, RFC 5424 limits that to provisioned, managed paths, and rsyslog's guide suggests a nearby relay that receives over a private link and forwards over TLS.
• Size the collector's disk and network for bursts, and alert when disk usage or dropped message counters climb, since filling a collector is one of the named denial of service classes.
• Check for forwarding loops whenever you add a relay.

Step 6: keep time and the TLS stack current

Timestamps are only useful if clocks agree, so synchronise every originator and use timeQuality structured data where your implementation emits it. And remember that the TLS in your log pipeline is provided by a library, OpenSSL, GnuTLS or mbed TLS, inside the syslog daemon's package or container image. Keeping that library current is part of keeping the transport secure, as the remediation section below covers.

Syslog vs journald forwarding vs OpenTelemetry logs: when to use which

Syslog is not the only way to move logs off a host. Two common alternatives on Linux and in cloud native stacks:

• systemd-journald forwarding. journald can hand messages to a local syslog daemon (ForwardToSyslog=, which the upstream journald.conf documentation says is off by default; only forwarding to wall is enabled by default), and systemd-journal-upload can send journal entries directly to a remote server. Its man page says it transfers the raw journal content over HTTP, with HTTPS the default scheme, default port 19532, and options --key=, --cert= and --trust= for client authentication and server verification. Setting --trust=all disables certificate checking.
• OpenTelemetry logs. The OpenTelemetry logs data model defines a log record with timestamps, trace context, severity, body, attributes and resource. Its appendix maps RFC 5424 fields onto it: HOSTNAME to host.name, APP-NAME to service.name, facility, PROCID and MSGID to syslog.* attributes. Note the severity scale runs the other way: in OpenTelemetry, larger SeverityNumber values are more severe, while in syslog lower numbers are more severe.

In practice many teams use all three: syslog over TLS from devices and hosts into a relay tier, journald as the local source on Linux, and OpenTelemetry for application telemetry, with collectors translating between them. The security questions stay the same on every path: is each hop encrypted, does each side authenticate the other, and can you tell when messages go missing?

Common mistakes

• Treating "TLS enabled" as "authenticated". rsyslog's anon mode and syslog-ng's optional-untrusted or required-untrusted settings encrypt traffic without proving who is on the other end. The rsyslog tutorial's own server example uses anon; copy the client side of that tutorial, not the listener.
• Trusting the HOSTNAME field. It is text chosen by the sender. With relays in the path, the TLS peer identity tells you only which relay delivered the message.
• Assuming TCP means no loss. RFC 5425 is explicit that a broken connection leaves the sender unsure what was delivered. Without a disk assisted queue, or rsyslog's RELP, messages in flight can still vanish.
• Sending syslog to TCP 514 on one side and TCP 601 on the other. Plain TCP syslog has no assigned port, and IANA assigns TCP 514 to the remote shell service. Set ports explicitly.
• Leaving newline framing on for multi-line logs. Traditional framing is rsyslog's omfwd default, and it splits stack traces into fragments. Use octet counting or TLS, which always uses octet counting.
• Leaving old protocol versions to library defaults. syslog-ng's ssl-options() defaults to excluding only SSLv2. RFC 9662 asks for TLS 1.2 at minimum, ECDHE suites preferred, and TLS 1.3 where available.
• Letting certificates expire. Both the rsyslog and syslog-ng guides warn that expired certificates stop delivery. Track expiry dates for every sender, not just the collector.
• Mixing BSD and RFC 5424 formats on one listener without noticing. RFC 3164 timestamps carry no year or time zone, which quietly breaks correlation across time zones and around new year.
• Feeding log text straight into dashboards, scripts or terminals. MSG and structured data values can contain control characters and invalid UTF-8. Every consumer should treat them as untrusted input.
• Building forwarding loops. Two relays forwarding the same severity to each other will saturate both.

FAQ

What port does syslog use?

Syslog over UDP uses port 514 (RFC 5426). Syslog over TLS uses TCP port 6514 (RFC 5425), and syslog over DTLS uses UDP or DCCP port 6514 (RFC 6012). Plain TCP syslog has no standard port; TCP 514 is common in practice but is assigned by IANA to the remote shell service, and syslog-ng's syslog() driver defaults to TCP 601.

Is syslog encrypted?

Not by default. Syslog over UDP or plain TCP is clear text, and RFC 5424 says the protocol itself provides no confidentiality. Encryption comes from the TLS transport (RFC 5425) or DTLS (RFC 6012), which RFC 5424 makes mandatory to implement and recommends for deployment.

What is the difference between RFC 3164 and RFC 5424?

RFC 3164 (2001) is an Informational document describing how BSD syslog behaved, with a local time timestamp that has no year or time zone and a 1024 byte limit. RFC 5424 (2009) is the standard that obsoletes it, adding a VERSION field, RFC 3339 timestamps, APP-NAME, PROCID and MSGID fields, structured data, UTF-8 messages and a transport independent design.

What is PRI in a syslog message?

PRI is the priority value in angle brackets at the start of every message. It equals the facility code multiplied by 8 plus the severity code, so <34> means facility 4 (security and authorization) and severity 2 (critical), and <165> means local4 with severity notice.

Syslog over UDP vs TCP: which should I use?

Neither, if you can use TLS. Between the two, TCP gives congestion control and in-order delivery, but no syslog level acknowledgment and no standard port. UDP is lossy and unauthenticated, and RFC 5424 limits it to network paths explicitly provisioned for syslog. Our post on whether syslog over UDP is safe for security logs covers that choice in depth.

How do I check if my syslog server accepts TLS?

On the server, ss -tlnp should show a listener on TCP 6514 owned by the syslog daemon. From a host you control, openssl s_client -connect yourserver:6514 -CAfile ca.pem -brief shows whether the handshake completes and which protocol and cipher were negotiated. Only test servers you own or are authorised to test.

Does syslog over TLS prove which host sent a message?

It proves which host made the TLS connection, if certificates are checked. It does not prove who wrote the message, because relays forward on behalf of others and the HOSTNAME field is unauthenticated text. Only signed syslog (RFC 5848) authenticates the message origin end to end.

What cipher suites should syslog over TLS use?

RFC 9662 (October 2024) says implementations should offer TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and must prefer it over the older TLS_RSA_WITH_AES_128_CBC_SHA, should support TLS 1.3 and prefer it, and must not use TLS 1.3 early data. For DTLS, 1.0 must not be used and 1.2 is mandatory.

Is signed syslog (RFC 5848) widely used?

Not widely. It adds origin authentication, replay resistance and loss detection through extra signature messages, but it breaks if any relay truncates or reformats messages, and its defined algorithms (SHA1 or SHA256 with OpenPGP DSA) date from 2010. Most teams rely on TLS per hop plus integrity controls on stored logs.

Syslog vs OpenTelemetry logs: which should I use?

Use syslog over TLS for network devices, appliances and operating systems, where support is universal. Use OpenTelemetry for application logs that need trace correlation. Many pipelines receive syslog at an OpenTelemetry collector, which maps RFC 5424 fields onto the OpenTelemetry log data model.

Where Safeguard fits

Safeguard does not collect, relay, filter or store syslog traffic, and it is not a log management or monitoring product. None of the configuration above depends on it. The honest connection is the software that implements syslog and its TLS transport.

rsyslog, syslog-ng and the TLS libraries they use (OpenSSL, GnuTLS, mbed TLS) ship inside your base images, appliances you build and the containers that run your relay and collector tiers. Safeguard's container visibility and scanning, generally available as part of ESSCM, shows which versions of those packages each image carries. Its software composition analysis, generally available, builds a full transitive dependency inventory for the applications you build, including the TLS and logging libraries they pull in, and SBOM generation and analysis, also generally available, records the result in SPDX or CycloneDX. Vulnerability management with EPSS and KEV enrichment and reachability analysis, both generally available, tell you which findings matter first. Policies and gates, generally available, can stop a build or release that carries a known vulnerable version of a TLS library into your log pipeline. Our post on using SBOMs to find affected products fast shows that workflow when the next TLS library advisory lands.

Fix it without waiting for upstream

Weaknesses in a logging pipeline rarely live in the RFCs themselves. They live in the syslog daemon, the TLS library under it, or the log parsing library in an application, all of which are open source components you can update, pin or replace yourself.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not log collection or network monitoring. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. Pointed at the container image for your log relay or collector, the same scan lists the syslog daemon and TLS library versions inside it with their known vulnerabilities, so you know what is terminating your port 6514 connections.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same approve each step flow applies when the dependency to bump is a TLS or logging library in a service you build.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects or images ship a particular version of a TLS library and get the answer from your own scan data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• RFC 5424: The Syslog Protocol, March 2009
• RFC 3164: The BSD syslog Protocol, August 2001
• RFC 5425: Transport Layer Security (TLS) Transport Mapping for Syslog, March 2009
• RFC 5426: Transmission of Syslog Messages over UDP, March 2009
• RFC 6012: Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog, October 2010
• RFC 6587: Transmission of Syslog Messages over TCP, April 2012
• RFC 5848: Signed Syslog Messages, May 2010
• RFC 9662: Updates to the Cipher Suites in Secure Syslog, October 2024
• RFC 3195: Reliable Delivery for syslog, November 2001
• RFC Editor metadata for RFCs 3164, 5424, 5425, 5426, 5848, 6012, 6587 and 9662
• IANA: Service Name and Transport Protocol Port Number Registry
• NIST SP 800-92: Guide to Computer Security Log Management, September 2006
• NIST SP 800-92 Rev. 1 (Initial Public Draft): Cybersecurity Log Management Planning Guide, October 2023
• rsyslog documentation: omfwd, syslog forwarding output module
• rsyslog documentation: imtcp, TCP syslog input module
• rsyslog documentation: OpenSSL network stream driver
• rsyslog documentation: GnuTLS network stream driver
• rsyslog documentation: Encrypting syslog traffic with TLS
• rsyslog documentation: Setting up the central server
• rsyslog documentation: Setting up a client
• rsyslogd(8), Linux manual page
• syslog-ng OSE documentation: TLS options
• syslog-ng OSE documentation: Configuring clients with mutual authentication
• syslog-ng OSE documentation: Configuring servers with mutual authentication
• syslog-ng OSE documentation: syslog() destination driver
• syslog-ng OSE documentation: syslog-ng manual page
• syslog-ng OSE documentation: syslog-ng-ctl manual page
• OpenSSL 3.0 documentation: openssl-s_client
• ss(8), Linux manual page
• systemd: journald.conf
• systemd: systemd-journal-upload.service
• OpenTelemetry: Logs Data Model
• OpenTelemetry: Logs Data Model Appendix, example mappings

Last reviewed: 23 October 2026. Implementation defaults change between releases; check the rsyslog and syslog-ng documentation for the version you actually run.