RFC 3164

The BSD Syslog Protocol

📅 published August 2001, from ietf

Title Block 🎀

RFC 3164: The BSD syslog Protocol 💜

Okay bestie, this one is from the Network Working Group and was written by C. Lonvick of Cisco Systems in August 2001. It's Category: Informational 🌸, which means it's sharing knowledge, not setting a standard. The header doesn't list any obsoletes or updates, so nothing gets replaced or patched here. 🧚

Status of This Memo ✨

Quick legal tea: this memo gives info to the Internet community. It is NOT an Internet standard of any kind 🙈. Distribution is unlimited, so go wild.

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract 🦋

This doc describes the behavior of the syslog protocol as it has actually been observed in the wild 👀. Syslog has been sending event notification messages across networks for years and years. It was originally built on the University of California Berkeley Software Distribution (BSD) TCP/IP system implementations 🌈, and because it's so useful for operations and management, it got ported to tons of other operating systems and baked into a ton of networked devices. Iconic longevity 👑.

Table of Contents 🧚

1. Introduction....................................................2
1.1 Events and Generated Messages..................................3
1.2 Operations of the Message Receivers............................5
2. Transport Layer Protocol........................................5
3. Definitions and Architecture....................................5
4. Packet Format and Contents......................................7
4.1 syslog Message Parts...........................................8
4.1.1 PRI Part.....................................................8
4.1.2 HEADER Part of a syslog Packet..............................10
4.1.3 MSG Part of a syslog Packet.................................11
4.2 Original syslog Packets Generated by a Device.................12
4.3 Relayed syslog Packets........................................12
4.3.1 Valid PRI and TIMESTAMP.....................................13
4.3.2 Valid PRI but no TIMESTAMP or invalid TIMESTAMP.............13
4.3.3 No PRI or Unidentifiable PRI................................14
5. Conventions....................................................14
5.1 Dates and Times...............................................15
5.2 Domain Name and Address.......................................15
5.3 Originating Process Information...............................15
5.4 Examples......................................................16
6. Security Considerations........................................18
6.1 Packet Parameters.............................................19
6.2 Message Authenticity..........................................19
6.2.1 Authentication Problems.....................................19
6.2.2 Message Forgery.............................................20
6.3 Sequenced Delivery............................................20
6.3.1 Single Source to a Destination..............................20
6.3.2 Multiple Sources to a Destination...........................21
6.3.3 Multiple Sources to Multiple Destinations...................21
6.3.4 Replaying...................................................22
6.4 Reliable Delivery.............................................22
6.5 Message Integrity.............................................22
6.6 Message Observation...........................................22
6.7 Message Prioritization and Differentiation....................23
6.8 Misconfiguration..............................................24
6.9 Forwarding Loop...............................................24
6.10 Load Considerations..........................................25
7. IANA Considerations............................................25
8. Conclusion and Other Efforts...................................25
Acknowledgements..................................................26
References........................................................27
Author's Address..................................................28
Full Copyright Statement..........................................29

1. Introduction ✨

Okay so, life has basically run on sending messages since forever 🧬. If you're a self-aware organic unit, messages can tell you all kinds of stuff: danger, where the food is, other necessities of life, the whole list. Lots of the time these messages are just informative and nobody has to reply 💅. Humans later took the same idea and applied it to society. Think severe weather warnings, which can come through a siren going off, TV and radio broadcasts, or even flags on ships 🚨. The vibe is that people who hear or see the warning will get what it means and do the right thing. Usually no one needs to confirm they got it, and sometimes that would even be annoying 🙈.

Same energy with computers 💻. Operating systems, processes, and applications were built to send messages about their own status, or to say that something happened. Those event messages mostly mattered to the people running the machine. As software got more and more complicated, people built systems to sort and log all these different messages so the ops team could spot real problems fast instead of getting lost in boring status updates 🔥. Syslog was one of those systems, and it got accepted pretty much everywhere. It's super flexible too, so operators can decide where a process's messages go 🌸. One option is writing events to different files and showing them on the device's console. Another is forwarding them across a network to the syslog process on a different machine.

Here's the big deal: syslog had to be network-aware to scale 🧚‍♀️. Operators running a bunch of systems don't have time to log into every single box to read its messages. So a syslog process on a remote device can be set up to either save the message to a file, or pass it along to yet another machine 💜.

Lowkey iconic, right? Here's the simplest version of what the syslog protocol does: it provides a transport that lets a machine send event notification messages across IP networks to event message collectors, aka syslog servers 🦋. Since every process, application, and OS was written kinda independently, the content of syslog messages is all over the place 😭. Because of that, no assumption is made about how the messages are formatted or what's in them. The protocol just exists to transport the event messages. In every case there's one device that originates the message, and its syslog process may send it to a collector. Nobody acknowledges receipt 🙌.

The core tenet of syslog is simplicity 💖. No strict coordination is needed between transmitters and receivers. Honestly, a device can start transmitting syslog messages even when there's no receiver configured, or the receiver isn't even physically there 🤯. And lots of devices can receive messages with no explicit configuration or definitions at all. That simplicity is a huge reason syslog got adopted and deployed so widely 👑.

1.1 Events and Generated Messages 🌈

The people who wrote the operating systems, processes, and applications had total control over what circumstances would generate a message 🎀. Sometimes messages are status updates, either on a schedule or at some other interval, like when a program starts or exits. Other times a message gets generated because some set of conditions was met, and then it might be a status message or an alarm of some kind 🚨. The original plan was that these writers would sort their messages into a few broad categories. Those categories usually come down to the facility that generated the message, plus how severe it is ✨. The point was that operations staff could filter messages, see the important and time-sensitive stuff right away, and still stash the status or informational messages in a file for later reading 📂. Other ways of displaying or storing messages also exist, FYI 💅.

Devices MUST be configured with rules for displaying and/or forwarding the event messages 🔧. The rules people have used are usually super flexible 💜. An admin might want every message stored locally, and also every high-severity message forwarded to another device 🔥. They might want messages from a specific facility sent to some or all of the device's users and shown on the system console too 🖥️. However the admin decides to set up the disposition of event messages, sending them to a syslog collector usually means picking which facility messages and which severity levels get forwarded, and then defining the remote receiver 🦋. For example, an admin might send all the mail facility messages to one particular collector 📬. Then they might send all kernel messages to a different syslog receiver, while the critically severe kernel messages also go to a third receiver 🧚. It could also make sense to show messages on the system console, email them to appropriate people, and save them to a file on the device's local disk, all at once 💌. Or the opposite: messages from a locally defined process might only show on the console, and never get saved or forwarded off the device 🙈. Either way, those rules have to be generated on the device itself 🛠️. Once admins know which message types will show up on the collectors, they should also make appropriate rules on those syslog servers 🫶.

The content of a message has also been up to whoever created it 🎨. It's been considered good form to write messages that are informative to the person reading them 📖. It's also been seen as good practice to include a timestamp and some info about the sending device and the process that originated the message 🕰️. But none of those are strictly required, so, no pressure 😌.

Literally any process on any device might generate an event message 🤖. That includes devices with no local storage, like printers, routers, hubs, switches, and diskless workstations 🖨️. For those, it may be imperative that event messages get transported to a collector, so they can be recorded and, hopefully, looked at by an operator 👀. Main character energy for the logs 💀✨.

1.2 Operations of the Message Receivers 🎀

okay so this part is literally out of scope for this doc 🙈 it's not going to tell you how to process messages once they show up. but just like the stuff in 1.1, received messages can get displayed to the right people, saved to disk, forwarded onward, or any mix of those 💅 and the rules for deciding what happens to a received message have been seen to be the exact same as the rules for locally generated ones. no cap, same energy ✨

also, as a very general rule, there are usually way more devices sending messages than collectors receiving them 🌸 this fan-in thing lets an admin pull messages together into a relatively small number of repositories. it's giving organization 🫶

  1. Transport Layer Protocol 🦋

syslog uses the user datagram protocol (UDP) [1] as its underlying transport layer mechanism 💜. the UDP port assigned to syslog is 514 🔥. it is RECOMMENDED that the source port also be 514 to indicate that the message is from the syslog process of the sender 💖, but there have been cases seen where valid syslog messages have come from a sender with a source port other than 514 😭. if the sender uses a source port other than 514, then it is RECOMMENDED, and has been considered good form, that subsequent messages come from a single consistent port 👑.

  1. Definitions and Architecture 🧚

the following definitions will be used in this document 🌈

  • a machine that can generate a message is called a "device" 💅
  • a machine that can receive the message and forward it to another machine is called a "relay" ✨
  • a machine that receives the message and does NOT relay it to any other machines is called a "collector" 🎀. this has been commonly known as a "syslog server" 💀
  • any device or relay is known as the "sender" when it sends a message 🫶
  • any relay or collector is known as the "receiver" when it receives the message 🦋

the architecture of the devices may be summarized like this 🌸

  • senders send messages to relays or collectors with no knowledge of whether it is a collector or relay 🙈
  • senders may be configured to send the same message to multiple receivers 🍓
  • relays may send all or some of the messages they receive to a subsequent relay or collector. in the case where they do not forward all of their messages, they are acting as both a collector and a relay 🧚. in the following diagram, these devices are designated as relays 💜
  • relays may also generate their own messages and send them on to subsequent relays or collectors. in that case it is acting as a device 💅. these devices are also designated as a relay in the following diagram ✨

the following architectures shown in Diagram 1 are valid, while the first one has been known to be the most prevalent 🔥. other arrangements of these examples are also acceptable 🌈. as noted above, in the following diagram relays may pass along all or some of the messages they receive, along with passing along messages that they internally generate 🫶.

      +------+         +---------+
      |Device|---->----|Collector|
      +------+         +---------+

      +------+         +-----+         +---------+
      |Device|---->----|Relay|---->----|Collector|
      +------+         +-----+         +---------+

      +------+     +-----+            +-----+     +---------+
      |Device|-->--|Relay|-->--..-->--|Relay|-->--|Collector|
      +------+     +-----+            +-----+     +---------+

      +------+         +-----+         +---------+
      |Device|---->----|Relay|---->----|Collector|
      |      |-\       +-----+         +---------+
      +------+  \
                 \      +-----+         +---------+
                  \-->--|Relay|---->----|Collector|
                        +-----+         +---------+

      +------+         +---------+
      |Device|---->----|Collector|
      |      |-\       +---------+
      +------+  \
                 \      +-----+         +---------+
                  \-->--|Relay|---->----|Collector|
                        +-----+         +---------+

      +------+         +-----+            +---------+
      |Device|---->----|Relay|---->-------|Collector|
      |      |-\       +-----+         /--|         |
      +------+  \                     /   +---------+
                 \      +-----+      /
                  \-->--|Relay|-->--/
                        +-----+

Diagram 1. Some Possible syslog Architectures 🧚

  1. Packet Format and Contents 💖

the payload of any IP packet that has a UDP destination port of 514 MUST be treated as a syslog message 🔥. there MAY be differences between the format of an originally transmitted syslog message and the format of a relayed message 🦋. in essence, it is RECOMMENDED to transmit a syslog message in the format specified in this document, but it is not required 💅. if a relay is able to recognize the message as adhering to that format, then it MUST retransmit the message without making any changes to it 👑. however, if a relay receives a message but cannot discern the proper implementation of the format, it is REQUIRED to modify the message so that it conforms to that format before it retransmits it 😭. Section 4.1 describes the RECOMMENDED format for syslog messages 🌸. Section 4.2 describes the requirements for originally transmitted messages, and Section 4.3 describes the requirements for relayed messages 🍓.

4.1. syslog Message Parts 🌈

the full format of a syslog message seen on the wire has three discernable parts 🎀. the first part is called the PRI, the second part is the HEADER, and the third part is the MSG 💜. the total length of the packet MUST be 1024 bytes or less 🔥. there is no minimum length of the syslog message, although sending a syslog packet with no contents is worthless and SHOULD NOT be transmitted 💀.

4.1.1. PRI Part 🦋

the PRI part MUST have three, four, or five characters, and it is bound with angle brackets as the first and last characters ✨. the PRI part starts with a leading "<" ('less-than' character), followed by a number, which is followed by a ">" ('greater-than' character) 🧚. the code set used in this part MUST be seven-bit ASCII in an eight-bit field, as described in RFC 2234 [2] 💅. these are the ASCII codes as defined in "USA Standard Code for Information Interchange" [3] 🫶. in this, the "<" character is defined as the Augmented Backus-Naur Form (ABNF) %d60, and the ">" character has ABNF value %d62 🌸. the number contained within these angle brackets is known as the Priority value, and it represents both the Facility and Severity as described below 🍓. the Priority value consists of one, two, or three decimal integers (ABNF DIGITS) using values of %d48 (for "0") through %d57 (for "9") 🔥.

the Facilities and Severities of the messages are numerically coded with decimal values 🌈. some of the operating system daemons and processes have been assigned Facility values 💖. processes and daemons that have not been explicitly assigned a Facility MAY use any of the "local use" facilities, or they MAY use the "user-level" Facility 🎀. those Facilities that have been designated are shown in the following table, along with their numerical code values 👑.

    Numerical             Facility
       Code

        0             kernel messages
        1             user-level messages
        2             mail system
        3             system daemons
        4             security/authorization messages (note 1)
        5             messages generated internally by syslogd
        6             line printer subsystem
        7             network news subsystem
        8             UUCP subsystem
        9             clock daemon (note 2)
       10             security/authorization messages (note 1)
       11             FTP daemon
       12             NTP subsystem
       13             log audit (note 1)
       14             log alert (note 1)
       15             clock daemon (note 2)
       16             local use 0  (local0)
       17             local use 1  (local1)
       18             local use 2  (local2)
       19             local use 3  (local3)
       20             local use 4  (local4)
       21             local use 5  (local5)
       22             local use 6  (local6)
       23             local use 7  (local7)

        Table 1.  syslog Message Facilities
Note 1 - Various operating systems have been found to utilize Facilities 4, 10, 13 and 14 for security/authorization, audit, and alert messages, which seem to be similar 🙈. Note 2 - Various operating systems have been found to utilize both Facilities 9 and 15 for clock (cron/at) messages 🕰️.

each message Priority also has a decimal Severity level indicator 🦋. these are described in the following table, along with their numerical values ✨.

     Numerical         Severity
       Code

        0       Emergency: system is unusable
        1       Alert: action must be taken immediately
        2       Critical: critical conditions
        3       Error: error conditions
        4       Warning: warning conditions
        5       Notice: normal but significant condition
        6       Informational: informational messages
        7       Debug: debug-level messages

        Table 2. syslog Message Severities

the Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity 💅. for example, a kernel message (Facility=0) with a Severity of Emergency (Severity=0) would have a Priority value of 0 🌸. also, a "local use 4" message (Facility=20) with a Severity of Notice (Severity=5) would have a Priority value of 165 🫶. in the PRI part of a syslog message, these values would be placed between the angle brackets as <0> and <165> respectively 💜. the only time a value of "0" will follow the "<" is for the Priority value of "0" 🔥. otherwise, leading "0"s MUST NOT be used 🙈.

4.1.2 HEADER Part of a syslog Packet ✨

okay bestie, the HEADER part is where the timestamp and the device's name live 🕰️🎀 it's giving "who sent this and when." The HEADER part of the syslog packet MUST contain visible (printing) characters 💅 The code set used MUST also be seven-bit ASCII in an eight-bit field, same as the PRI part. The only allowed characters are the ABNF VCHAR values (%d33-126) and spaces (SP value %d32) 🌸

The HEADER has two fields, the TIMESTAMP and the HOSTNAME 🧚 The TIMESTAMP comes right after the closing > from the PRI part, and a single space character MUST follow each of the TIMESTAMP and HOSTNAME fields 💖 HOSTNAME holds the hostname as the device knows itself. No hostname? Then it uses its own IP address 🦋 If a device has several IP addresses, it usually uses the one the message was sent from. There's also a twist: a device can be set up to send everything from one source IP no matter which interface the message leaves on. That gives you one consistent HOSTNAME for all its messages, which is so clean 🫶

The TIMESTAMP is the local time, in the format "Mmm dd hh:mm:ss" (no quote marks) where:

  • Mmm is the English abbreviation for the month, with the first letter uppercase and the other two lowercase. These are the only acceptable values: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec 🍓
  • dd is the day of the month. If the day is less than 10, it MUST be written as a space and then the number. So the 7th of August looks like Aug 7, with two spaces between the "g" and the "7" ✨
  • hh:mm:ss is the local time. The hour is in 24-hour format, with valid entries from 00 to 23 inclusive. Minutes and seconds run from 00 to 59 inclusive ⏰

A single space character MUST follow the TIMESTAMP field 🌈

The HOSTNAME field contains only the hostname, the IPv4 address, or the IPv6 address of the message's originator 👑 The hostname is the preferred value. If the hostname is used, the HOSTNAME field MUST contain the device's hostname as specified in STD 13 [4]. Also, it MUST NOT contain any embedded spaces, which is a vibe-check no-no 🙈 The Domain Name MUST NOT be included in the HOSTNAME field either. If you go with an IPv4 address, it MUST be shown in dotted decimal notation as used in STD 13 [5] 🔥 For IPv6, any valid representation used in RFC 2373 [6] MAY be used 🦋 And yes, a single space character MUST also follow the HOSTNAME field 💅

4.1.3 MSG Part of a syslog Packet 🎀

the MSG part is the main character 😭 It fills whatever is left of the syslog packet. Usually it has some extra info about the process that made the message, and then the actual message text. There's no ending delimiter for this part. The MSG part of the syslog packet MUST contain visible (printing) characters 🫶 The code set everyone traditionally uses is also seven-bit ASCII in an eight-bit field, like the PRI and HEADER parts. In that code set, the only allowed characters are the ABNF VCHAR values (%d33-126) and spaces (SP value %d32) 💜 Nobody has to say which code set the MSG uses, and nobody's expected to. Other code sets MAY be used, as long as the characters are only visible characters and spaces like the ones above 🌸 Picking the code set for the MSG part SHOULD be done with the intended receiver in mind. Ngl, a message full of characters the recipient can't view or understand is giving nothing useful to the operator or admin reading it 💀

The MSG part has two fields: the TAG field and the CONTENT field 🧚 The TAG holds the name of the program or process that made the message. The CONTENT has the details of the event, traditionally a freeform message. The TAG is a string of ABNF alphanumeric characters that MUST NOT exceed 32 characters 🍓 Any non-alphanumeric character ends the TAG and is treated as the first character of the CONTENT. Most commonly, that ending character is a left square bracket ("["), a colon (":"), or a space. It's explained in more detail in Section 5.3 ✨

4.2 Original syslog Packets Generated by a Device 🦋

There aren't any set requirements on the contents of a syslog packet as the device first sends it 🌈 Quick reminder: the payload of any IP packet going to UDP port 514 MUST be considered a valid syslog message 👑 Still, it is RECOMMENDED that the syslog packet have all the parts from Section 4.1 (PRI, HEADER and MSG) because it makes things easier to read for the recipient and means a relay doesn't have to modify the message 💖

For implementers who do choose to build syslog messages in the RECOMMENDED format, here's some guidance 🫶

  • If the original message has a TIMESTAMP in the HEADER part, it SHOULD be the device's local time in its own timezone.
  • If the original message has a HOSTNAME field, it will contain the hostname as the device knows itself. No hostname? Then it uses the device's own IP address.
  • If the original message has a TAG value, that's the name of the program or process that generated the message.

4.3 Relayed syslog Packets 🔥

When a relay gets a packet, it checks for a valid PRI. If the first character isn't a less-than sign, the relay MUST assume the packet doesn't contain a valid PRI 🙈 If the 3rd, 4th, or 5th character isn't a right angle bracket, the relay again MUST assume the PRI wasn't included in the original message. If the relay does find a valid PRI, it must check for a valid TIMESTAMP in the HEADER part. These rules give three general cases of received messages. Table 3 shows the general characteristics of each case and the section of this document that covers how to handle it 🧚

          Case                                         Section
     Valid PRI and TIMESTAMP                            4.3.1
     Valid PRI but no TIMESTAMP or invalid TIMESTAMP    4.3.2
     No PRI or unidentifiable PRI                       4.3.3

          Table 3. Cases of Received syslog Messages

4.3.1 Valid PRI and TIMESTAMP ✨

If the relay finds a valid PRI and a valid TIMESTAMP, it checks its internal configuration. Relays MUST be configured to forward syslog packets based on their Priority value 🌸 If the relay is set up to forward the received packet, it MUST do so without changing the packet at all. Saying it one more time because it's that important: this is exactly why it is RECOMMENDED that the syslog message be sent in the format described in Section 4.1 💅

Here's a fun fact to note: the message receiver does not need to validate the time in the TIMESTAMP field. It may be assumed that a device whose date hasn't been set correctly can still send valid syslog messages 🦋 The relay also doesn't need to check that the HOSTNAME value matches the hostname or IP address of the device that sent the message. You can find the reason for this in Section 4.1.2 🫶

4.3.2 Valid PRI but no TIMESTAMP or invalid TIMESTAMP 🎀

If a relay doesn't find a valid TIMESTAMP in a received syslog packet, it MUST add a TIMESTAMP and a space character right after the closing angle bracket of the PRI part 💖 It SHOULD also add a HOSTNAME and a space character after the TIMESTAMP. These fields are described here and detailed in Section 4.1.2. The rest of the received packet MUST be treated as the CONTENT field of the MSG and appended to it 🌈 The relay can't figure out which process on the device made the message, so the TAG value can't be determined and won't be included 🍓

The TIMESTAMP will be the relay's current local time 🕰️

The HOSTNAME will be the name of the device as the relay knows it. If that name can't be determined, the device's IP address is used 🧚

If the relay adds a TIMESTAMP, or a TIMESTAMP and HOSTNAME, after the PRI part, it MUST check that the total length of the packet is still 1024 bytes or less. If the packet has grown past 1024 bytes, the relay MUST truncate the packet to 1024 bytes 😭 This may cause the loss of vital information from the end of the original packet, so it is RECOMMENDED that the PRI and HEADER parts of originally generated syslog packets contain the values and fields documented in Section 4.1 💜

4.3.3 No PRI or Unidentifiable PRI 💀

If the relay receives a syslog message without a PRI, or with an unidentifiable PRI, it MUST insert a PRI with a Priority value of 13, along with a TIMESTAMP as described in Section 4.3.2 🙈 The relay SHOULD also insert a HOSTNAME as described in Section 4.3.2. The entire contents of the received packet are treated as the CONTENT of the relayed MSG and appended 🍓

An example of an unidentifiable PRI is "<00>", without the double quotes. It might be the first 4 characters of the message 🔥 Following that example: if a relay receives a syslog message whose first four characters are "<00>", it consults its configuration. If it's set up to forward syslog messages with a Priority value of 13 to another relay or collector, it MUST modify the packet as described above. The details, including the RECOMMENDED insertion of the HOSTNAME, are below 🌸

Originally received message
  <00>...
Relayed message
  <13>TIMESTAMP HOSTNAME <00>...

If the relay adds a TIMESTAMP, or a TIMESTAMP and HOSTNAME, after the PRI part, it MUST check that the total length of the packet is still 1024 bytes or less. If the packet has grown past 1024 bytes, the relay MUST truncate the packet to 1024 bytes. This may cause the loss of vital information from the end of the original packet, so it is RECOMMENDED that the PRI and HEADER parts of originally generated syslog packets contain the values and fields documented in Section 4.1 🫶

5. Conventions 🌈

Okay so, Section 4 of this document is where ALL the syslog format and content requirements live 📜 But over time, people have come up with certain conventions for adding extra info inside a syslog message 💅 It must be plainly stated that these items are not mandated, but implementers may consider them for completeness and to give the recipient some extra clues about where the message came from and what it's about 🦋✨

5.1 Dates and Times ✨

okay so some network admins are obsessed with archiving their syslog messages for, like, years 📚. Some original syslog messages have a more explicit timestamp where a 2 character or 4 character year field shows up right after the space that ends the TIMESTAMP 🙈. Not me... that doesn't match the order and format the fields were originally meant to have 💀. If implementers want a more specific date and time stamp in the message, it should be within the CONTENT field. Implementers may wish to use the ISO 8601 [7] date and time formats if they want more explicit date and time info 🗓️.

Other ways to handle long-term archiving have been proposed, and some have been successfully implemented 🎀. One is that network admins can modify the messages stored on their collectors. They can run a simple script that adds the year and any other info to each stored record. Or the script can swap the stored time for a format that suits them better 💅. Another option is inserting a record into the file that contains the current year. By association, all the records near that informative record should have been received in that same year 🌸. Honestly, neither of these fixes the timezone problem, which is that you still can't tell which correct timezone goes with each record 😭.

5.2 Domain Name and Address

To easily identify the device that originated the message, it may be a good practice to include its fully qualified domain name (FQDN) and its IP address within the CONTENT field 🧚. Traditionally, though, only the hostname has been included in the HOSTNAME field 🍓.

5.3 Originating Process Information

It's also been considered a good practice to include some info about the process on the device that generated the message, if that concept exists 🦋. For robust operating systems, this is usually the process name and process id (often known as the "pid") 👑. The process name is commonly displayed in the TAG field. Quite often, extra info goes at the beginning of the CONTENT field too. The format TAG[pid]:, without the quote marks, is super common 💜. In that case, the left square bracket terminates the TAG field and is then the first character in the CONTENT field.

If the process id isn't important, it can be left off ✨. Then a colon and a space character usually follow the TAG, which looks like TAG: (no quotes). In that case, the colon is the first character in the CONTENT field.

5.4 Examples

Here are some examples, the kind you'd actually spot on the wire between two devices 👀. Each message is indented, and line breaks have been added in this document so they're easier to read 🫶.

Example 1

    <34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick
    on /dev/pts/8

This one is an authentication error, from someone trying to grab extra privileges 😬. It also shows the command that was attempted and the user who tried it. It was recorded as an original message from the device called mymachine. A relay receiving this wouldn't change anything before sending it along, because it already has a properly formatted PRI part and TIMESTAMP field in the HEADER part 💖. The TAG value here is the process "su". The colon ends the TAG field and is the first character of the CONTENT field. The process id (pid) would be considered transient here, and anyone reading this message would gain no useful info from knowing it. So it wasn't included, and the first two characters of the CONTENT field are the colon and a space character 🙈.

Example 2

    Use the BFG!

Valid message? Yes. Extraordinarily useful? Absolutely not 💀. It has no discernable PRI part, no timestamp, and no indication of where it came from. If you store this on paper or disk, nobody will get anything out of it later on 😭.

This one is obviously an original message from a device. A relay MUST make changes to the message as described in Section 4.3 before forwarding it 🔥. The resulting relayed message looks like this:

    <13>Feb  5 17:32:18 10.0.0.99 Use the BFG!

In this relayed version, the whole message has been treated as the CONTENT portion of the MSG part 🎀. First, a valid PRI part was added using the default priority value of 13. Then a TIMESTAMP was added along with a HOSTNAME in the HEADER part. Later relays won't make any further changes to this message ✨. Notice the day of the month is less than 10. Since single digits in the date (5 in this case) are preceded by a space in the TIMESTAMP format, there are two spaces after the month before the day 🌈. Also, the relay doesn't seem to know the host name of the device that sent the message, so it put the device's IPv4 address into the HOSTNAME field 🦋.

Example 3

     <165>Aug 24 05:34:00 CST 1987 mymachine myproc[10]: %% It's
     time to make the do-nuts.  %%  Ingredients: Mix=OK, Jelly=OK #
     Devices: Mixer=OK, Jelly_Injector=OK, Frier=OK # Transport:
     Conveyer1=OK, Conveyer2=OK # %%

This message has a valid PRI part, with a Priority value showing it came from a locally defined facility (local4) with a severity of Notice 🍩. The HEADER part has a proper TIMESTAMP field. A relay won't modify this message before sending it. However, the HOSTNAME and TAG fields don't match the definitions in Section 4. The HOSTNAME field would be read as "CST", and the beginning of the MSG part would be read as "1987" 🙃.

It's worth noting that the CONTENT of this example is not telemetry data, and it isn't supervisory control or data acquisition info either 🚨. Because of the security concerns listed in Section 6 of this document, info like that should probably not be sent across this protocol.

Example 4

     <0>1990 Oct 22 10:52:01 TZ-6 scapegoat.dmz.example.org 10.1.2.3
     sched[0]: That's All Folks!

This example is packed with extra info 📦. A human, or a sufficiently adaptable automated parser, could figure out the date and time, plus a fully qualified domain name (FQDN) [4] and an IP address. The info about the event itself is pretty limited though 😅. Given the severity it reports, the process probably couldn't gather or send anything more informative. Honestly, it's lucky it managed to send this message at all 🥲.

This is obviously an original message from a device. Since the first field in the HEADER part isn't a TIMESTAMP in the format defined in Section 4.1.2, it MUST be modified by a relay 🔥. A relay will add a TIMESTAMP and SHOULD add a HOSTNAME, like this, and it will treat the entire received packet after the PRI part from the original packet as the CONTENT field of the new packet 💅. The value used in the HOSTNAME field is only the hostname, without the domain name, as the relay knows it. A TAG value won't be added to the relayed packet. Including the domain name and IPv4 address in the original message was a noble endeavor, but it isn't consistent with how Section 4.1.2 describes using that field 🙈.

     <0>Oct 22 10:52:12 scapegoat 1990 Oct 22 10:52:01 TZ-6
     scapegoat.dmz.example.org 10.1.2.3 sched[0]: That's All Folks!

6. Security Considerations ✨

Okay, this section gets a little dramatic, so buckle up 🫣. An odor can be thought of as a message that doesn't require any acknowledgement 👃. People tend to avoid bad smells and get drawn to the ones they associate with good food 🍲. Acknowledging a scent isn't required, and it can honestly be the height of discretion to totally ignore some odors 💅. On the other hand, it's usually good civility to compliment the cook just from the ambiance wafting out of the kitchen 🧑‍🍳. Similarly, various species use odors to attract mates. One species of moth uses this scent to find each other. However, bolas spiders have been found to mimic the odor of the female moths of that species 🕷️. That scent then attracts male moths, which follow it expecting to find a mate. Instead, when they reach the source of the scent, they get eaten [8] 😱. This is a case of a false message being sent out with inimical intent.

In its local use, the syslog process places event notification messages into files on that system. That relies on the integrity of the system to protect the messages 🔒. Later on, the syslog process was configured to use the syslog protocol to transport those messages to a remote collector. That was an extension of delivering event notification messages, and it shows the same trust of the network 🌐. There are several security consequences that come from the fundamental simplicity of syslog, and there are some concerns about using this protocol in situations that need robust delivery 💀. Going back to the analogy, computer event messages may be sent accidentally, erroneously, and even maliciously 😈. At the time of this writing, though, there haven't been any reports of a networked device consuming any other device 🙏.

6.1 Packet Parameters

As was described above, the message length MUST NOT exceed 1024 bytes 📏. There have been attacks where syslog messages were sent to a receiver with message lengths greater than 1024 bytes 🚩. In some older versions of syslog, receiving syslog packets with a message longer than 1024 bytes caused problems. syslog message receivers must not malfunction when they receive packets whose message length is greater than 1024 bytes. Various behaviors have been seen on receivers that do take in messages longer than 1024 bytes. Some log the entire contents of the message, others log only portions of it, and still others discard the message altogether 🤷‍♀️. Devices MUST NOT retransmit messages whose received length exceeds 1024 bytes 🛑.

Similarly, the receiver must rigidly enforce the correctness of the message body 🧐. syslog collectors must not malfunction if received messages don't have the less-than and greater-than characters around a valid Priority value. They MUST treat these messages as the unformatted CONTENT described in Section 4.3.3 if they relay them 💜.

Also, received messages must contain printable text in the message, as was described throughout Section 4 ✨. Devices must not malfunction if they receive a message containing characters other than the ones described above 🎀.

6.2 Message Authenticity ✨

okay so the syslog delivery mechanism does NOT strongly link a message to whoever actually sent it 🫣 the receiver can't really tell whether the message came from the sender it claims, or whether the packet came from some other device entirely. ngl that's a whole vibe check fail. also, the message receiver does not need to verify that the HOSTNAME in the HEADER part matches the name tied to the IP address in the Source Address field of the IP packet 💅

6.2.1 Authentication Problems

one possible consequence is that a misconfigured machine might send syslog messages to a collector while pretending to be a different machine 🙈 the admin team can get super confused because the status of the supposed sender won't be accurately reflected in the messages they receive. they might not be able to tell that two or more machines are all claiming to be the same machine. that's a lot 😭

it's also worth noting that filling in the HOSTNAME field might only have local meaning, and it might only last a little while 🦋 if a device got its IP address from a DHCP pool, then any link between an identifier and an actual source won't always hold true. putting a fully qualified domain name in the CONTENT can give admins their best shot at figuring out where each message came from, especially if it can always be tied to an IP address or always be tied to one unique machine 🎀

6.2.2 Message Forgery

malicious exploits of this have also been noticed, and it's giving scary movie 💀 an attacker might send syslog messages to a collector, either from the machine the messages claim to come from or from any other machine. in one case, an attacker might hide the real nature of an attack in the middle of lots of other messages. for example, an attacker could start generating forged messages that point to a problem on some machine. that gets the sysadmins' attention, and they spend their time investigating the fake problem 🕵️‍♀️ meanwhile the attacker might compromise a different machine, or a different process on the same machine. the attacker can also make up false syslog messages to fake the status of things or fake events 🔥 for example, an attacker could stop a critical process on a machine, which might generate an exit notification. then the attacker could send a forged notice that the process was restarted. the sysadmins might just accept that misinformation and never check that the process actually restarted. main character villain arc, honestly 👑

6.3 Sequenced Delivery 🧚

the forensics of a network anomaly usually depend on rebuilding the sequence of events 📅 in a perfect world, messages would arrive at the syslog collector in the same order they were generated on the other devices, and anyone reading the records would have an accurate picture of what happened and when. unfortunately, the syslog process and protocol don't guarantee ordered delivery 😭 this section walks through some of the problems that can come from that.

6.3.1 Single Source to a Destination

syslog records are usually shown (put in a file, displayed on the console, and so on) in the order they were received 🌸 that isn't always the order they were generated in. as they travel across an IP network, some out of order receipt should be expected. this can be confusing, because messages might suggest that a process stopped before it was started 🤯 it can get better if the originating process timestamped or numbered each message before sending it. for that, the sending device should use an authoritative time source. just remember that not all devices can receive time updates, and not all devices can timestamp their messages 💜

6.3.2 Multiple Sources to a Destination

syslog has no concept of unified event numbering 🙅‍♀️ a single device is free to include a sequence number in the CONTENT, but that's hard to coordinate across multiple devices. so several devices might each report that they're sending message number one 💀 this can also get better if the sending devices use a timestamp from an authoritative source in their messages. as we already noted, even messages from one device to one collector might arrive out of order 😵 it gets even messier when several devices are set up to send their syslog messages to one collector. messages from one device might be delayed, so the collector gets messages from another device first, even though the first device generated its messages earlier. if there's no timestamp or coordinated sequence number, the messages might be shown in the order they arrived, which can give a totally inaccurate view of the actual sequence of events 🫠

6.3.3 Multiple Sources to Multiple Destinations

the plethora of configuration options available to network admins can make the order of events even harder to read 🌈 it's totally possible to set up a group of devices to send status messages (or other informative messages) to one collector, while sending more important messages to a different collector. messages can also go to different files on the same collector. if the messages don't contain timestamps from the source, it can be hard to put them in order when they're stored in different places. an admin might not be able to tell whether a record in one file happened before or after a record in another file 🙃 this can be eased a little by putting timestamped marker messages into all destination files. if those have coordinated timestamps, you get some sense of when each message was received 🎀

6.3.4 Replaying

without any sequence info or timestamp, messages can be recorded and replayed later 📼 an attacker could record a batch of messages showing a machine's normal activity. later, that attacker could take that machine off the network and replay the syslog messages to the collector. even with a TIMESTAMP field in the HEADER part, an attacker could record the packets and just edit them to show the current time before resending them 🫣 the admins may see nothing unusual in what they receive, and getting those messages would falsely suggest the machine is behaving normally. not it 🙅‍♀️

6.4 Reliable Delivery 💌

there's no mechanism in the syslog process or the protocol to make sure messages get delivered, and since the underlying transport is UDP, some messages may be lost 😩 they might get dropped because of network congestion, or they might be maliciously intercepted and thrown away. what happens after one or more syslog messages get dropped can't be determined. if the messages are simple status updates, their non-receipt might go unnoticed, or it might just annoy the system operators. but if the messages are more critical, the admins might not find out about a developing and potentially serious problem 🚨 attackers can also intercept and discard messages to hide unauthorized activity, which is sneaky 🥷

6.5 Message Integrity 🔐

besides being discarded, syslog messages can get damaged in transit, or an attacker might maliciously change them 😤 when a packet carrying a syslog message gets damaged, there are different mechanisms built into the link layer, and also into the IP [9] and UDP protocols, that might detect the damage. an intermediary router might discard a damaged IP packet [10]. damage to a UDP packet may be detected by the receiving UDP module, which might silently throw it away. either way, the original contents of the message won't be delivered to the collector 💔 and if an attacker sits between the sender and the collector, they might be able to intercept and modify messages while they're in transit to hide unauthorized activity. the audacity 😤

6.6 Message Observation 👀

there are no strict guidelines about the format of an event message, and most syslog messages are generated in human readable form, on the assumption that capable admins should be able to read them and understand what they mean 📖 neither the syslog protocol nor the syslog application has a mechanism to keep messages confidential in transit 🫥 in most cases, sending clear-text messages is actually a benefit for the ops team if they're sniffing packets off the wire. they can read the messages, connect them with other events seen in other packets crossing the wire, and track down and fix problems 🛠️ unfortunately, an attacker might also be able to observe the human-readable contents of syslog messages 😰 and then use what they learn from those messages to compromise a machine or do other damage. this is the part where we all need to be careful, bestie 🫶

6.7 Message Prioritization and Differentiation 💅

Okay so the process making the message can slap a Priority value on it to signal how important the event is 🔥, but here's the tea: there's NO real link between that number and how hard the packet gets delivered 🙈. Say an app generates two event messages. The first is a normal status message, but the second is a big deal, a problem with the process, so it gets a higher Severity value. If the operators set up both messages to go to a syslog collector, they both get handed to UDP for transmission. Under normal conditions, nothing treats them differently, and they go out in the order they were sent ✨.

Again, under normal conditions, the receiver accepts syslog messages as they arrive. If lots of devices are sending normal status messages and one device is sending an important event message, the syslog protocol has no built-in way to put the important one first 😭.

Operators can, case by case, figure out a way to link the different levels to quality of service identifiers 🎀. For example, they might decide that syslog messages with a specific Priority value get mapped to a specific value in the IPv4 Precedence field [9], the IPv6 Traffic Class octet [11], or the Differentiated Services field [12]. So in that example, the status message gets normal delivery, while the message about a problem gets a high reliability, low latency queue as it travels through the network 🚀. This would have the affect of prioritizing the essential messages ahead of the normal status messages 👑.

Even with this hop-by-hop prioritization, the queuing could still cause head of line blocking on the transmitting device, as well as buffer starvation on the receiving device, if there are many near-simultaneous messages being sent or received 😩. This isn't unique to syslog. It's endemic to all operations that transmit messages serially, so it's not just a syslog problem, it's a everything-that-sends-one-at-a-time problem 💀.

There are security concerns for this behavior, and they're real 😤. Head of line blocking can relegate important event messages behind less important ones. If the queue gets cleared properly, this may only add seconds to the transmission of the important message 🌸. But if the queue is never cleared, the important messages may not be transmitted at all 💔. On the receiving side, if the syslog receiver is suffering from buffer starvation because of a huge number of near-simultaneous messages, important messages may be dropped indiscriminately along with everything else 🥀. Yes, these are problems with the devices and their capacities, but the protocol security concern is that there's no prioritization of the more important messages over the less important ones. Main character energy, but make it a vulnerability 💅.

6.8 Misconfiguration 🙃

Okay this one is so important, bestie 🫶. Since there's no control information distributed about any messages or configurations, it is wholly the responsibility of the network administrator to make sure the messages are actually going to the intended recipient 👑. Cases have been noted where devices were inadvertently configured to send syslog messages to the wrong receiver 😬. In many cases, the accidental receiver isn't set up to receive syslog messages, so it will probably just discard them 🗑️. In certain other cases, receiving syslog messages has been known to cause problems for the unintended recipient [13] 💀. And if messages aren't reaching the intended recipient, then they can't be reviewed or processed. Literally no one is reading them 😭.

6.9 Forwarding Loop 🌀

So as shown in Figure 1, machines may be configured to relay syslog messages to subsequent relays before they reach a collector 🦋. In one particular case, an administrator found they had mistakenly configured two relays to forward messages with certain Priority values to each other 🙈. Whenever either machine received or generated that type of message, it would forward it to the other relay, and that relay would, in turn, forward it right back 🔁. This cycle really did degrade the surrounding network, along with the processing availability on both devices 😵. Network administrators must take care to not cause such a death spiral ⚠️.

Wrong forwarding setup = infinite ping-pong. Double check your relay config before you hit save, bestie 🫶.

6.10 Load Considerations 🧚

Network administrators must take the time to estimate the appropriate size of the syslog receivers 📏. An attacker may perform a Denial of Service attack by filling the collector's disk with false messages 😈. Placing the records in a circular file may alleviate this, but that has the consequence of not ensuring that an administrator will be able to review the records in the future 🌀. Along this line, a receiver or collector must have a network interface capable of receiving all messages sent to it 📡.

Administrators and network planners must also critically review the network paths between the devices, the relays, and the collectors 🔍. Generated syslog messages should not overwhelm any of the network links 🌊.

7. IANA Considerations 🦋

The syslog protocol has been assigned UDP port 514 🎀. This port assignment will be maintained by IANA exclusively for this protocol 💜.

The syslog protocol provides for the definition of named attributes to indicate the Severity of each message and the Facility that generated the message, as described in Section 4 ✨. The name space identifiers for these attributes are defined as numbers. The protocol does not define the specific assignment of the name space for these numbers. The application developer or system vendor is allowed to define the attribute, its semantics, and the associated numbers 🌈. This name space will not be controlled to prevent collisions, because systems are expected to use the same attributes, semantics and associated numbers to describe events that are deemed similar, even between heterogeneous devices 🫶.

8. Conclusion and Other Efforts 🌸

The syslog protocol may be effectively used to transport event notification messages across a network 🚀. In all cases, it is important that the syslog message receiver embody the principle of "be liberal in what you accept" 🙌. It is highly recommended that the network operators who choose to use this understand the characteristics of the protocol and its security implications 🔐.

There have been attempts in the past to standardize the format of the syslog message 📜. The most notable attempt culminated in a BOF at the Fortieth Internet Engineering Task Force meeting in 1997. This was the Universal Logging Protocol (ulp) BOF, and the minutes of their meeting are on-line at the IETF Proceedings web site [14] 🗂️.

Many good thoughts came from that effort, and interested implementers may want to find some of the notes or papers produced from it 💡.

At the time of this writing, efforts are underway to allow the usage of international character sets in applications that have traditionally been thought of as text-only 🌍. The HOSTNAME and TIMESTAMP fields described above are representative of this ✨. Also, the entire CONTENT field has traditionally been printing characters and spaces in the code set known as US-ASCII 🔤. It is hoped that the proponents of these internationalization efforts will find a suitable way to allow the use of international character sets within syslog messages without being disruptive 🥹. It should also be hoped that implementers will allow for the future acceptance of additional code sets, and that they may make appropriate plans 🗺️. Again, it must be cautioned that the simplicity of the existing system has been a tremendous value to its acceptance. Anything that lessens that simplicity may diminish that value 💖.

Acknowledgements 🫶

The following people provided content feedback during the writing of this document 💌:

  • Jon Knight <J.P.Knight@lboro.ac.uk>
  • Magosanyi Arpad <mag@bunuel.tii.matav.hu>
  • Balazs Scheidler <bazsi@balabit.hu>
  • Jon Callas <jon@counterpane.com>
  • Eliot Lear <lear@cisco.com>
  • Petter Reinholdtsen <pere@hungry.com>
  • Darren Reed <darrenr@reed.wattle.id.au>
  • Alfonso De Gregorio <dira@speedcom.it>
  • Eric Allman <eric@sendmail.com>
  • Andrew Ross <andrew@kiwi-enterprises.com>
  • George Maslyar <george.maslyar@primark.com>
  • Albert Mietus <albert@ons-huis.net>
  • Russ Allbery <rra@stanford.edu>
  • Titus D. Winters <titus@cs.hmc.edu>
  • Edwin P. Boon <Edwin.Boon@consul.com>
  • Jeroen M. Mostert <Jeroen.Mostert@consul.com>

Eric Allman is the original inventor and author of the syslog daemon and protocol. The author of this memo and the community at large would like to express their appreciation for this work and for the usefulness it has provided over the years 👑🌟.

A large amount of additional information about this de-facto standard operating system feature may usually be found in the syslog.conf file, as well as in the man pages for syslog.conf, syslog, syslogd, and logger, of many Unix and Unix-like devices 📚.

References 📖

  • 1 Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
  • 2 Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
  • 3 USA Standard Code for Information Interchange, USASI X3.4-1968
  • 4 Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
  • 5 Mockapetris, P., "Domain names - Implementation and Specification", STD 13, RFC 1035, November 1987.
  • 6 Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
  • 7 Data elements and interchange formats - Information exchange - Representation of dates and times, International Organization for Standardization, Reference number ISO 8601 : 1988 (E), 1988
  • 8 Stowe, M., et al, "Chemical Mimicry: Bolas Spiders Emit Components of Moth Prey Species Sex Pheromones", Science, 1987
  • 9 Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
  • 10 Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
  • 11 Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • 12 Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
  • 13 Cisco Systems Product Security Incident Response Team (PSIRT), "Field Notice: Cisco IOS(r) Syslog Crash", January 11, 1999 http://www.cisco.com/warp/public/707/advisory.html
  • 14 Walker, D., IETF Secretariat, "Proceedings of the Fortieth Internet Engineering Task Force, Washington, DC, USA, December 8-12, 1997" http://www.ietf.org/proceedings/97dec/index.html

Author's Address 🎀

Chris Lonvick Cisco Systems 12515 Research Blvd. Austin, TX, USA

Phone: +1.512.378.1182 EMail: clonvick@cisco.com

okay so this part is the legal fine print, and it has to stay word-for-word 💀 bestie, no editing the legal stuff, even when we're being extra.

Copyright (C) The Internet Society (2001). All Rights Reserved. 🌈

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 💖

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 🦋

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💅

Acknowledgement 🫶

okay and last but not least, the funding bit: funding for the RFC Editor function is currently provided by the Internet Society. 🌸 the people keeping these documents published get the support they need, and that's iconic. 👑

📦 where this page comes from