Network Working Group C. Lonvick
Request for Comments: 3164 Cisco Systems
Category: Informational August 2001
The BSD syslog Protocol
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document describes the observed behavior of the syslog protocol.
This protocol has been used for the transmission of event
notification messages across networks for many years. While this
protocol was originally developed on the University of California
Berkeley Software Distribution (BSD) TCP/IP system implementations,
its value to operations and management has led it to be ported to
many other operating systems as well as being embedded into many
other networked devices.
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
Lonvick Informational [Page 1]
RFC 3164 The BSD syslog Protocol August 2001
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
Since the beginning, life has relied upon the transmission of
messages. For the self-aware organic unit, these messages can relay
many different things. The messages may signal danger, the presence
of food or the other necessities of life, and many other things. In
many cases, these messages are informative to other units and require
no acknowledgement. As people interacted and created processes, this
same principle was applied to societal communications. As an
example, severe weather warnings may be delivered through any number
of channels - a siren blowing, warnings delivered over television and
radio stations, and even through the use of flags on ships. The
expectation is that people hearing or seeing these warnings would
realize their significance and take appropriate action. In most
cases, no responding acknowledgement of receipt of the warning is
required or even desired. Along these same lines, operating systems,
processes and applications were written to send messages of their own
status, or messages to indicate that certain events had occurred.
These event messages generally had local significance to the machine
operators. As the operating systems, processes and applications grew
ever more complex, systems were devised to categorize and log these
diverse messages and allow the operations staff to more quickly
Lonvick Informational [Page 2]
RFC 3164 The BSD syslog Protocol August 2001
differentiate the notifications of problems from simple status
messages. The syslog process was one such system that has been
widely accepted in many operating systems. Flexibility was designed
into this process so the operations staff have the ability to
configure the destination of messages sent from the processes running
on the device. In one dimension, the events that were received by
the syslog process could be logged to different files and also
displayed on the console of the device. In another dimension, the
syslog process could be configured to forward the messages across a
network to the syslog process on another machine. The syslog process
had to be built network-aware for some modicum of scalability since
it was known that the operators of multiple systems would not have
the time to access each system to review the messages logged there.
The syslog process running on the remote devices could therefore be
configured to either add the message to a file, or to subsequently
forward it to another machine.
In its most simplistic terms, the syslog protocol provides a
transport to allow a machine to send event notification messages
across IP networks to event message collectors - also known as syslog
servers. Since each process, application and operating system was
written somewhat independently, there is little uniformity to the
content of syslog messages. For this reason, no assumption is made
upon the formatting or contents of the messages. The protocol is
simply designed to transport these event messages. In all cases,
there is one device that originates the message. The syslog process
on that machine may send the message to a collector. No
acknowledgement of the receipt is made.
One of the fundamental tenets of the syslog protocol and process is
its simplicity. No stringent coordination is required between the
transmitters and the receivers. Indeed, the transmission of syslog
messages may be started on a device without a receiver being
configured, or even actually physically present. Conversely, many
devices will most likely be able to receive messages without explicit
configuration or definitions. This simplicity has greatly aided the
acceptance and deployment of syslog.
1.1 Events and Generated Messages
The writers of the operating systems, processes and applications have
had total control over the circumstances that would generate any
message. In some cases, messages are generated to give status. These
can be either at a certain period of time, or at some other interval
such as the invocation or exit of a program. In other cases, the
messages may be generated due to a set of conditions being met. In
those cases, either a status message or a message containing an alarm
of some type may be generated. It was considered that the writers of
Lonvick Informational [Page 3]
RFC 3164 The BSD syslog Protocol August 2001
the operating systems, processes and applications would quantify
their messages into one of several broad categories. These broad
categories generally consist of the facility that generated them,
along with an indication of the severity of the message. This was so
that the operations staff could selectively filter the messages and
be presented with the more important and time sensitive notifications
quickly, while also having the ability to place status or informative
messages in a file for later perusal. Other options for displaying
or storing messages have been seen to exist as well.
Devices MUST be configured with rules for displaying and/or
forwarding the event messages. The rules that have been seen are
generally very flexible. An administrator may want to have all
messages stored locally as well as to have all messages of a high
severity forwarded to another device. They may find it appropriate
to also have messages from a particular facility sent to some or all
of the users of the device and displayed on the system console.
However the administrator decides to configure the disposition of the
event messages, the process of having them sent to a syslog collector
generally consists of deciding which facility messages and which
severity levels will be forwarded, and then defining the remote
receiver. For example, an administrator may want all messages that
are generated by the mail facility to be forwarded to one particular
event message collector. Then the administrator may want to have all
kernel generated messages sent to a different syslog receiver while,
at the same time, having the critically severe messages from the
kernel also sent to a third receiver. It may also be appropriate to
have those messages displayed on the system console as well as being
mailed to some appropriate people, while at the same time, being sent
to a file on the local disk of the device. Conversely, it may be
appropriate to have messages from a locally defined process only
displayed on the console but not saved or forwarded from the device.
In any event, the rules for this will have to be generated on the
device. Since the administrators will then know which types of
messages will be received on the collectors, they should then make
appropriate rules on those syslog servers as well.
The contents of a message have also been at the discretion of its
creator. It has been considered to be good form to write the
messages so that they are informative to the person who may be
reading them. It has also been considered good practice to include a
timestamp and some indication of the sending device and the process
that originated it in the messages. However, none of those are
stringently required.
It should be assumed that any process on any device might generate an
event message. This may include processes on machines that do not
have any local storage - e.g., printers, routers, hubs, switches, and
Lonvick Informational [Page 4]
RFC 3164 The BSD syslog Protocol August 2001
diskless workstations. In that case, it may be imperative that event
messages are transported to a collector so that they may be recorded
and hopefully viewed by an operator.
1.2 Operations of the Message Receivers
It is beyond the scope of this document to specify how event messages
should be processed when they are received. Like the operations
described in Section 1.1, they generally may be displayed to the
appropriate people, saved onto disk, further forwarded, or any
combination of these. The rules for determining the disposition of
received messages have been seen to be identical to the rules for
determining the disposition of locally generated messages.
As a very general rule, there are usually many devices sending
messages to relatively fewer collectors. This fan-in process allows
an administrator to aggregate messages into relatively few
repositories.
2. Transport Layer Protocol
syslog uses the user datagram protocol (UDP) [1] as its underlying
transport layer mechanism. The UDP port that has been 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 to be good form that subsequent messages are from a single
consistent port.
3. Definitions and Architecture
The following definitions will be used in this document.
A machine that can generate a message will be called a
"device".
A machine that can receive the message and forward it to
another machine will be called a "relay".
A machine that receives the message and does not relay it to
any other machines will be called a "collector". This has been
commonly known as a "syslog server".
Any device or relay will be known as the "sender" when it sends
a message.
Lonvick Informational [Page 5]
RFC 3164 The BSD syslog Protocol August 2001
Any relay or collector will be known as the "receiver" when it
receives the message.
The architecture of the devices may be summarized as follows:
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 that 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
will be 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 will also be 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 that they receive along with passing along messages that
they internally generate.
Lonvick Informational [Page 6]
RFC 3164 The BSD syslog Protocol August 2001
+------+ +---------+
|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
4. 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
Lonvick Informational [Page 7]
RFC 3164 The BSD syslog Protocol August 2001
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 will describe the
RECOMMENDED format for syslog messages. Section 4.2 will describe
the requirements for originally transmitted messages and Section 4.3
will describe 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 will be
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 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)
Lonvick Informational [Page 8]
RFC 3164 The BSD syslog Protocol August 2001
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
Lonvick Informational [Page 9]
RFC 3164 The BSD syslog Protocol August 2001
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
The HEADER part contains a timestamp and an indication of the
hostname or IP address of the device. 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 like that used in
the PRI part. In this code set, the only allowable characters are
the ABNF VCHAR values (%d33-126) and spaces (SP value %d32).
The HEADER contains two fields called the TIMESTAMP and the HOSTNAME.
The TIMESTAMP will immediately follow the trailing ">" from the PRI
part and single space characters MUST follow each of the TIMESTAMP
and HOSTNAME fields. HOSTNAME will contain the hostname, as it knows
itself. If it does not have a hostname, then it will contain its own
IP address. If a device has multiple IP addresses, it has usually
been seen to use the IP address from which the message is
transmitted. An alternative to this behavior has also been seen. In
that case, a device may be configured to send all messages using a
single source IP address regardless of the interface from which the
message is sent. This will provide a single consistent HOSTNAME for
all messages sent from a device.
The TIMESTAMP field is the local time and is in the format of "Mmm dd
hh:mm:ss" (without the quote marks) where:
Mmm is the English language abbreviation for the month of the
year with the first character in uppercase and the other two
characters in lowercase. The following 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 of the month is less
than 10, then it MUST be represented as a space and then the
number. For example, the 7th day of August would be
represented as "Aug 7", with two spaces between the "g" and
the "7".
Lonvick Informational [Page 10]
RFC 3164 The BSD syslog Protocol August 2001
hh:mm:ss is the local time. The hour (hh) is represented in a
24-hour format. Valid entries are between 00 and 23,
inclusive. The minute (mm) and second (ss) entries are between
00 and 59 inclusive.
A single space character MUST follow the TIMESTAMP field.
The HOSTNAME field will contain only the hostname, the IPv4 address,
or the IPv6 address of the originator of the message. The preferred
value is the hostname. If the hostname is used, the HOSTNAME field
MUST contain the hostname of the device as specified in STD 13 [4].
It should be noted that this MUST NOT contain any embedded spaces.
The Domain Name MUST NOT be included in the HOSTNAME field. If the
IPv4 address is used, it MUST be shown as the dotted decimal notation
as used in STD 13 [5]. If an IPv6 address is used, any valid
representation used in RFC 2373 [6] MAY be used. A single space
character MUST also follow the HOSTNAME field.
4.1.3 MSG Part of a syslog Packet
The MSG part will fill the remainder of the syslog packet. This will
usually contain some additional information of the process that
generated the message, and then the text of the message. There is no
ending delimiter to this part. The MSG part of the syslog packet
MUST contain visible (printing) characters. The code set
traditionally and most often used has also been seven-bit ASCII in an
eight-bit field like that used in the PRI and HEADER parts. In this
code set, the only allowable characters are the ABNF VCHAR values
(%d33-126) and spaces (SP value %d32). However, no indication of the
code set used within the MSG is required, nor is it expected. Other
code sets MAY be used as long as the characters used in the MSG are
exclusively visible characters and spaces similar to those described
above. The selection of a code set used in the MSG part SHOULD be
made with thoughts of the intended receiver. A message containing
characters in a code set that cannot be viewed or understood by a
recipient will yield no information of value to an operator or
administrator looking at it.
The MSG part has two fields known as the TAG field and the CONTENT
field. The value in the TAG field will be the name of the program or
process that generated the message. The CONTENT contains the details
of the message. This has traditionally been a freeform message that
gives some detailed information of the event. The TAG is a string of
ABNF alphanumeric characters that MUST NOT exceed 32 characters. Any
non-alphanumeric character will terminate the TAG field and will be
assumed to be the starting character of the CONTENT field. Most
commonly, the first character of the CONTENT field that signifies the
Lonvick Informational [Page 11]
RFC 3164 The BSD syslog Protocol August 2001
conclusion of the TAG field has been seen to be the left square
bracket character ("["), a colon character (":"), or a space
character. This is explained in more detail in Section 5.3.
4.2 Original syslog Packets Generated by a Device
There are no set requirements on the contents of the syslog packet as
it is originally sent from a device. It should be reiterated here
that the payload of any IP packet destined to UDP port 514 MUST be
considered to be a valid syslog message. It is, however, RECOMMENDED
that the syslog packet have all of the parts described in Section 4.1
- PRI, HEADER and MSG - as this enhances readability by the recipient
and eliminates the need for a relay to modify the message.
For implementers that do choose to construct syslog messages with the
RECOMMENDED format, the following guidance is offered.
If the originally formed message has a TIMESTAMP in the HEADER
part, then it SHOULD be the local time of the device within its
timezone.
If the originally formed message has a HOSTNAME field, then it
will contain the hostname as it knows itself. If it does not
have a hostname, then it will contain its own IP address.
If the originally formed message has a TAG value, then that
will be the name of the program or process that generated the
message.
4.3 Relayed syslog Packets
When a relay receives a packet, it will check for a valid PRI. If
the first character is not a less-than sign, the relay MUST assume
that the packet does not contain a valid PRI. If the 3rd, 4th, or
5th character is not a right angle bracket character, the relay again
MUST assume that the PRI was not included in the original message.
If the relay does find a valid PRI part then it must check for a
valid TIMESTAMP in the HEADER part. From these rules, there will be
three general cases of received messages. Table 3 gives the general
characteristics of these cases and lists the subsequent section of
this document that describes the handling of that case.
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
Lonvick Informational [Page 12]
RFC 3164 The BSD syslog Protocol August 2001
4.3.1 Valid PRI and TIMESTAMP
If the relay does find a valid PRI and a valid TIMESTAMP, then it
will check its internal configuration. Relays MUST be configured to
forward syslog packets on the basis of their Priority value. If the
relay finds that it is configured to forward the received packet,
then it MUST do so without making any changes to the packet. To
emphasize the point one more time, it is for this reason that it is
RECOMMENDED that the syslog message originally transmitted adhere to
the format described in Section 4.1.
It should be noted here that the message receiver does not need to
validate the time in the TIMESTAMP field. The assumption may be made
that a device whose date has not been correctly set will still have
the ability to send valid syslog messages. Additionally, the relay
does not need to validate that the value in the HOSTNAME field
matches the hostname or IP address of the device sending the message.
A reason for this behavior may be found in Section 4.1.2.
4.3.2 Valid PRI but no TIMESTAMP or invalid TIMESTAMP
If a relay does not find a valid TIMESTAMP in a received syslog
packet, then it MUST add a TIMESTAMP and a space character
immediately after the closing angle bracket of the PRI part. It
SHOULD additionally add a HOSTNAME and a space character after the
TIMESTAMP. These fields are described here and detailed in Section
4.1.2. The remainder of the received packet MUST be treated as the
CONTENT field of the MSG and appended. Since the relay would have no
way to determine the originating process from the device that
originated the message, the TAG value cannot be determined and will
not be included.
The TIMESTAMP will be the current local time of the relay.
The HOSTNAME will be the name of the device, as it is known by the
relay. If the name cannot be determined, the IP address of the
device will be used.
If the relay adds a TIMESTAMP, or a TIMESTAMP and HOSTNAME, after the
PRI part, then it MUST check that the total length of the packet is
still 1024 bytes or less. If the packet has been expanded beyond
1024 bytes, then the relay MUST truncate the packet to be 1024 bytes.
This may cause the loss of vital information from the end of the
original packet. It is for this reason that it is RECOMMENDED that
the PRI and HEADER parts of originally generated syslog packets
contain the values and fields documented in Section 4.1.
Lonvick Informational [Page 13]
RFC 3164 The BSD syslog Protocol August 2001
4.3.3 No PRI or Unidentifiable PRI
If the relay receives a syslog message without a PRI, or with an
unidentifiable PRI, then it MUST insert a PRI with a Priority value
of 13 as well as 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 will be treated as the
CONTENT of the relayed MSG and appended.
An example of an unidentifiable PRI would be "<00>", without the
double quotes. It may be that these are the first 4 characters of
the message. To continue this example, if a relay does receive a
syslog message with the first four characters of "<00>", then it will
consult its configuration. If it is configured to forward syslog
messages with a Priority value of 13 to another relay or collector,
then it MUST modify the packet as described above. The specifics of
doing this, including the RECOMMENDED insertion of the HOSTNAME, are
given 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, then it MUST check that the total length of the packet is
still 1024 bytes or less. If the packet has been expanded beyond
1024 bytes, then the relay MUST truncate the packet to be 1024 bytes.
This may cause the loss of vital information from the end of the
original packet. It is for this reason that 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
Although Section 4 of this document specifies all requirements for
the syslog protocol format and contents, certain conventions have
come about over time for the inclusion of additional information
within the syslog message. It must be plainly stated that these
items are not mandated but may be considered by implementers for
completeness and to give the recipient some additional clues of their
origin and nature.
Lonvick Informational [Page 14]
RFC 3164 The BSD syslog Protocol August 2001
5.1 Dates and Times
It has been found that some network administrators like to archive
their syslog messages over long periods of time. It has been seen
that some original syslog messages contain a more explicit time stamp
in which a 2 character or 4 character year field immediately follows
the space terminating the TIMESTAMP. This is not consistent with the
original intent of the order and format of the fields. If
implementers wish to contain a more specific date and time stamp
within the transmitted message, it should be within the CONTENT
field. Implementers may wish to utilize the ISO 8601 [7] date and
time formats if they want to include more explicit date and time
information.
Additional methods to address this desire for long-term archiving
have been proposed and some have been successfully implemented. One
such method is that the network administrators may choose to modify
the messages stored on their collectors. They may run a simple
script to add the year, and any other information, to each stored
record. Alternatively, the script may replace the stored time with a
format more appropriate for the needs of the network administrators.
Another alternative has been to insert a record into the file that
contains the current year. By association then, all other records
near that informative record should have been received in that same
year. Neither of these however, addresses the issue of associating a
correct timezone with each record.
5.2 Domain Name and Address
To readily 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, however,
only the hostname has been included in the HOSTNAME field.
5.3 Originating Process Information
It has also been considered to be a good practice to include some
information about the process on the device that generated the
message - if that concept exists. This is usually the process name
and process id (often known as the "pid") for robust operating
systems. The process name is commonly displayed in the TAG field.
Quite often, additional information is included at the beginning of
the CONTENT field. The format of "TAG[pid]:" - without the quote
marks - is common. The left square bracket is used to terminate the
TAG field in this case and is then the first character in the CONTENT
field. If the process id is immaterial, it may be left off.
Lonvick Informational [Page 15]
RFC 3164 The BSD syslog Protocol August 2001
In that case, a colon and a space character usually follow the TAG.
This would be displayed as "TAG: " without the quotes. In that case,
the colon is the first character in the CONTENT field.
5.4 Examples
As examples, these are valid messages as they may be observed on the
wire between two devices. In the following examples, each message
has been indented, with line breaks inserted in this document for
readability.
Example 1
<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick
on /dev/pts/8
This example shows an authentication error in an attempt to acquire
additional privileges. It also shows the command attempted and the
user attempting it. This was recorded as an original message from
the device called mymachine. A relay receiving this would not make
any changes before sending it along as it contains a properly
formatted PRI part and TIMESTAMP field in the HEADER part. The TAG
value in this example is the process "su". The colon has terminated
the TAG field and is the first character of the CONTENT field. In
this case, the process id (pid) would be considered transient and
anyone looking at this syslog message would gain no useful
information from knowing the pid. It has not been included so the
first two characters of the CONTENT field are the colon and a space
character.
Example 2
Use the BFG!
While this is a valid message, it has extraordinarily little useful
information. This message does not have any discernable PRI part. It
does not contain a timestamp or any indication of the source of the
message. If this message is stored on paper or disk, subsequent
review of the message will not yield anything of value.
This example 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 is shown below.
<13>Feb 5 17:32:18 10.0.0.99 Use the BFG!
Lonvick Informational [Page 16]
RFC 3164 The BSD syslog Protocol August 2001
In this relayed message, the entire message has been treated as the
CONTENT portion of the MSG part. First, a valid PRI part has been
added using the default priority value of 13. Next, a TIMESTAMP has
been added along with a HOSTNAME in the HEADER part. Subsequent
relays will not make any further changes to this message. It should
be noted in this example that 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 following the
month in the TIMESTAMP before the day of the month. Also, the relay
appears to have no knowledge of the host name of the device sending
the message so it has inserted the IPv4 address of the device 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 does have a valid PRI part with a Priority value
indicating that it came from a locally defined facility (local4) with
a severity of Notice. The HEADER part has a proper TIMESTAMP field
in the message. A relay will not modify this message before sending
it. However, the HOSTNAME and TAG fields are not consistent with the
definitions in Section 4. The HOSTNAME field would be construed to
be "CST" and the beginning of the MSG part would be "1987".
It should be noted that the information contained in the CONTENT of
this example is not telemetry data, nor is it supervisory control or
data acquisition information. Due to the security concerns listed in
Section 6 of this document, information of that nature should
probably not be conveyed 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 has a lot of extraneous information throughout. A human
or sufficiently adaptable automated parser would be able to determine
the date and time information as well as a fully qualified domain
name (FQDN) [4] and IP address. The information about the nature of
the event is, however, limited. Due to the indicated severity of the
event, the process may not have been able to gather or send anything
more informative. It may have been fortunate to have generated and
sent this message at all.
Lonvick Informational [Page 17]
RFC 3164 The BSD syslog Protocol August 2001
This example is obviously an original message from a device. Since
the first field in the HEADER part is not 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 as follows and 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 it is
known by the relay. A TAG value will not be added to the relayed
packet. While the inclusion of the domain name and IPv4 address in
the original message is a noble endeavor, it is not consistent with
the use of the field as described in Section 4.1.2.
<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
An odor may be considered to be a message that does not require any
acknowledgement. People tend to avoid bad odors but are drawn to
odors that they associate with good food. The acknowledgement of the
receipt of the odor or scent is not required and indeed it may be the
height of discretion to totally ignore some odors. On the other
hand, it is usually considered good civility to acknowledge the
prowess of the cook merely from the ambiance wafting from the
kitchen. Similarly, various species have been found to utilize odors
to attract mates. One species of moth uses this scent to find each
other. However, it has been found that bolas spiders can mimic the
odor of the female moths of this species. This scent will then
attract male moths, which will follow it with the expectation of
finding a mate. Instead, when they arrive at the source of the
scent, they will be 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. This relies upon the integrity
of the system for the protection of the messages. The subsequent
configuration of the syslog process to use the syslog protocol to
transport the messages to a remote collector was an extension of the
delivery of event notification messages and it exhibits the same
trust of the network. There are several security consequences of the
fundamental simplicity of syslog and there are some concerns about
the applicability of this protocol in situations that require robust
delivery. Along the lines of the analogy, computer event messages
may be sent accidentally, erroneously and even maliciously. At the
time of this writing, however, there have not been any reports of any
networked device consuming any other device.
Lonvick Informational [Page 18]
RFC 3164 The BSD syslog Protocol August 2001
6.1 Packet Parameters
As was described above, the message length MUST NOT exceed 1024
bytes. Attacks have seen where syslog messages are sent to a
receiver that have message lengths greater than 1024 bytes. In some
older versions of syslog, the receipt of syslog packets that had a
message greater than 1024 bytes caused problems. syslog message
receivers must not malfunction upon the receipt of packets where the
message length is greater than 1024 bytes. Various behaviors have
been seen on receivers that do receive messages greater than 1024
bytes. Some have been seen to log the entire contents of the
message, while others have been seen to log only portions of the
message. Still others have been known to 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 do not have the less-than and greater-than characters around
a valid Priority value. They MUST treat these messages as the
unformatted CONTENT as was described in