As per Relevance of the word information, we have this rfc below:
Network Working Group C.
Request for Comments: 3164 Cisco
Category: Informational August 2001
The BSD syslog
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document describes the observed behavior of the syslog protocol
This protocol has been used for the transmission of
notification messages across networks for many years. While
protocol was originally developed on the University of
Berkeley Software Distribution (BSD) TCP/IP system implementations
its value to operations and management has led it to be ported
many other operating systems as well as being embedded into
other networked devices
Table of
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.
Since the beginning, life has relied upon the transmission
messages. For the self-aware organic unit, these messages can
many different things. The messages may signal danger, the
of food or the other necessities of life, and many other things.
many cases, these messages are informative to other units and
no acknowledgement. As people interacted and created processes,
same principle was applied to societal communications. As
example, severe weather warnings may be delivered through any
of channels - a siren blowing, warnings delivered over television
radio stations, and even through the use of flags on ships.
expectation is that people hearing or seeing these warnings
realize their significance and take appropriate action. In
cases, no responding acknowledgement of receipt of the warning
required or even desired. Along these same lines, operating systems
processes and applications were written to send messages of their
status, or messages to indicate that certain events had occurred
These event messages generally had local significance to the
operators. As the operating systems, processes and applications
ever more complex, systems were devised to categorize and log
diverse messages and allow the operations staff to more
Lonvick Informational [Page 2]
RFC 3164 The BSD syslog Protocol August 2001
differentiate the notifications of problems from simple
messages. The syslog process was one such system that has
widely accepted in many operating systems. Flexibility was
into this process so the operations staff have the ability
configure the destination of messages sent from the processes
on the device. In one dimension, the events that were received
the syslog process could be logged to different files and
displayed on the console of the device. In another dimension,
syslog process could be configured to forward the messages across
network to the syslog process on another machine. The syslog
had to be built network-aware for some modicum of scalability
it was known that the operators of multiple systems would not
the time to access each system to review the messages logged there
The syslog process running on the remote devices could therefore
configured to either add the message to a file, or to
forward it to another machine
In its most simplistic terms, the syslog protocol provides
transport to allow a machine to send event notification
across IP networks to event message collectors - also known as
servers. Since each process, application and operating system
written somewhat independently, there is little uniformity to
content of syslog messages. For this reason, no assumption is
upon the formatting or contents of the messages. The protocol
simply designed to transport these event messages. In all cases
there is one device that originates the message. The syslog
on that machine may send the message to a collector.
acknowledgement of the receipt is made
One of the fundamental tenets of the syslog protocol and process
its simplicity. No stringent coordination is required between
transmitters and the receivers. Indeed, the transmission of
messages may be started on a device without a receiver
configured, or even actually physically present. Conversely,
devices will most likely be able to receive messages without
configuration or definitions. This simplicity has greatly aided
acceptance and deployment of syslog
1.1 Events and Generated
The writers of the operating systems, processes and applications
had total control over the circumstances that would generate
message. In some cases, messages are generated to give status.
can be either at a certain period of time, or at some other
such as the invocation or exit of a program. In other cases,
messages may be generated due to a set of conditions being met.
those cases, either a status message or a message containing an
of some type may be generated. It was considered that the writers
Lonvick Informational [Page 3]
RFC 3164 The BSD syslog Protocol August 2001
the operating systems, processes and applications would
their messages into one of several broad categories. These
categories generally consist of the facility that generated them
along with an indication of the severity of the message. This was
that the operations staff could selectively filter the messages
be presented with the more important and time sensitive
quickly, while also having the ability to place status or
messages in a file for later perusal. Other options for
or storing messages have been seen to exist as well
Devices MUST be configured with rules for displaying and/
forwarding the event messages. The rules that have been seen
generally very flexible. An administrator may want to have
messages stored locally as well as to have all messages of a
severity forwarded to another device. They may find it
to also have messages from a particular facility sent to some or
of the users of the device and displayed on the system console
However the administrator decides to configure the disposition of
event messages, the process of having them sent to a syslog
generally consists of deciding which facility messages and
severity levels will be forwarded, and then defining the
receiver. For example, an administrator may want all messages
are generated by the mail facility to be forwarded to one
event message collector. Then the administrator may want to have
kernel generated messages sent to a different syslog receiver while
at the same time, having the critically severe messages from
kernel also sent to a third receiver. It may also be appropriate
have those messages displayed on the system console as well as
mailed to some appropriate people, while at the same time, being
to a file on the local disk of the device. Conversely, it may
appropriate to have messages from a locally defined process
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
device. Since the administrators will then know which types
messages will be received on the collectors, they should then
appropriate rules on those syslog servers as well
The contents of a message have also been at the discretion of
creator. It has been considered to be good form to write
messages so that they are informative to the person who may
reading them. It has also been considered good practice to include
timestamp and some indication of the sending device and the
that originated it in the messages. However, none of those
stringently required
It should be assumed that any process on any device might generate
event message. This may include processes on machines that do
have any local storage - e.g., printers, routers, hubs, switches,
Lonvick Informational [Page 4]
RFC 3164 The BSD syslog Protocol August 2001
diskless workstations. In that case, it may be imperative that
messages are transported to a collector so that they may be
and hopefully viewed by an operator
1.2 Operations of the Message
It is beyond the scope of this document to specify how event
should be processed when they are received. Like the
described in Section 1.1, they generally may be displayed to
appropriate people, saved onto disk, further forwarded, or
combination of these. The rules for determining the disposition
received messages have been seen to be identical to the rules
determining the disposition of locally generated messages
As a very general rule, there are usually many devices
messages to relatively fewer collectors. This fan-in process
an administrator to aggregate messages into relatively
repositories
2. Transport Layer
syslog uses the user datagram protocol (UDP) [1] as its
transport layer mechanism. The UDP port that has been assigned
syslog is 514. It is RECOMMENDED that the source port also be 514
indicate that the message is from the syslog process of the sender
but there have been cases seen where valid syslog messages have
from a sender with a source port other than 514. If the sender
a source port other than 514 then it is RECOMMENDED and has
considered to be good form that subsequent messages are from a
consistent port
3. Definitions and
The following definitions will be used in this document
A machine that can generate a message will be called
"device".
A machine that can receive the message and forward it
another machine will be called a "relay".
A machine that receives the message and does not relay it
any other machines will be called a "collector". This has
commonly known as a "syslog server".
Any device or relay will be known as the "sender" when it
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
receives the message
The architecture of the devices may be summarized as follows
Senders send messages to relays or collectors with no
of whether it is a collector or relay
Senders may be configured to send the same message to
receivers
Relays may send all or some of the messages that they
to a subsequent relay or collector. In the case where they
not forward all of their messages, they are acting as both
collector and a relay. In the following diagram, these
will be designated as relays
Relays may also generate their own messages and send them on
subsequent relays or collectors. In that case it is acting
a device. These devices will also be designated as a relay
the following diagram
The following architectures shown in Diagram 1 are valid while
first one has been known to be the most prevalent.
arrangements of these examples are also acceptable. As noted above
in the following diagram relays may pass along all or some of
messages that they receive along with passing along messages
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
4. Packet Format and
The payload of any IP packet that has a UDP destination port of 514
MUST be treated as a syslog message. There MAY be
between the format of an originally transmitted syslog message
the format of a relayed message. In essence, it is RECOMMENDED
transmit a syslog message in the format specified in this document
but it is not required. If a relay is able to recognize the
as adhering to that format then it MUST retransmit the
without making any changes to it. However, if a relay receives
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
format before it retransmits it. Section 4.1 will describe
RECOMMENDED format for syslog messages. Section 4.2 will
the requirements for originally transmitted messages and Section 4.3
will describe the requirements for relayed messages
4.1 syslog Message
The full format of a syslog message seen on the wire has
discernable parts. The first part is called the PRI, the second
is the HEADER, and the third part is the MSG. The total length
the packet MUST be 1024 bytes or less. There is no minimum length
the syslog message although sending a syslog packet with no
is worthless and SHOULD NOT be transmitted
4.1.1 PRI
The PRI part MUST have three, four, or five characters and will
bound with angle brackets as the first and last characters. The
part starts with a leading "<" ('less-than' character), followed by
number, which is followed by a ">" ('greater-than' character).
code set used in this part MUST be seven-bit ASCII in an eight-
field as described in RFC 2234 [2]. These are the ASCII codes
defined in "USA Standard Code for Information Interchange" [3].
this, the "<" character is defined as the Augmented Backus-Naur
(ABNF) %d60, and the ">" character has ABNF value %d62. The
contained within these angle brackets is known as the Priority
and represents both the Facility and Severity as described below
The Priority value consists of one, two, or three decimal
(ABNF DIGITS) using values of %d48 (for "0") through %d57 (for "9").
The Facilities and Severities of the messages are numerically
with decimal values. Some of the operating system daemons
processes have been assigned Facility values. Processes and
that have not been explicitly assigned a Facility may use any of
"local use" facilities or they may use the "user-level" Facility
Those Facilities that have been designated are shown in the
table along with their numerical code values
Numerical
0 kernel
1 user-level
2 mail
3 system
4 security/authorization messages (note 1)
Lonvick Informational [Page 8]
RFC 3164 The BSD syslog Protocol August 2001
5 messages generated internally by
6 line printer
7 network news
8 UUCP
9 clock daemon (note 2)
10 security/authorization messages (note 1)
11 FTP
12 NTP
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
Note 1 - Various operating systems have been found to
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
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
values
Numerical
0 Emergency: system is
1 Alert: action must be taken
2 Critical: critical
3 Error: error
4 Warning: warning
5 Notice: normal but significant
6 Informational: informational
7 Debug: debug-level
Table 2. syslog Message
Lonvick Informational [Page 9]
RFC 3164 The BSD syslog Protocol August 2001
The Priority value is calculated by first multiplying the
number by 8 and then adding the numerical value of the Severity.
example, a kernel message (Facility=0) with a Severity of
(Severity=0) would have a Priority value of 0. Also, a "local use 4"
message (Facility=20) with a Severity of Notice (Severity=5)
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>
<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
used
4.1.2 HEADER Part of a syslog
The HEADER part contains a timestamp and an indication of
hostname or IP address of the device. The HEADER part of the
packet MUST contain visible (printing) characters. The code set
MUST also be seven-bit ASCII in an eight-bit field like that used
the PRI part. In this code set, the only allowable characters
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
part and single space characters MUST follow each of the
and HOSTNAME fields. HOSTNAME will contain the hostname, as it
itself. If it does not have a hostname, then it will contain its
IP address. If a device has multiple IP addresses, it has
been seen to use the IP address from which the message
transmitted. An alternative to this behavior has also been seen.
that case, a device may be configured to send all messages using
single source IP address regardless of the interface from which
message is sent. This will provide a single consistent HOSTNAME
all messages sent from a device
The TIMESTAMP field is the local time and is in the format of "Mmm
hh:mm:ss" (without the quote marks) where
Mmm is the English language abbreviation for the month of
year with the first character in uppercase and the other
characters in lowercase. The following are the only
values
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov,
dd is the day of the month. If the day of the month is
than 10, then it MUST be represented as a space and then
number. For example, the 7th day of August would
represented as "Aug 7", with two spaces between the "g"
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
24-hour format. Valid entries are between 00 and 23,
inclusive. The minute (mm) and second (ss) entries are
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
value is the hostname. If the hostname is used, the HOSTNAME
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
IPv4 address is used, it MUST be shown as the dotted decimal
as used in STD 13 [5]. If an IPv6 address is used, any
representation used in RFC 2373 [6] MAY be used. A single
character MUST also follow the HOSTNAME field
4.1.3 MSG Part of a syslog
The MSG part will fill the remainder of the syslog packet. This
usually contain some additional information of the process
generated the message, and then the text of the message. There is
ending delimiter to this part. The MSG part of the syslog
MUST contain visible (printing) characters. The code
traditionally and most often used has also been seven-bit ASCII in
eight-bit field like that used in the PRI and HEADER parts. In
code set, the only allowable characters are the ABNF VCHAR
(%d33-126) and spaces (SP value %d32). However, no indication of
code set used within the MSG is required, nor is it expected.
code sets MAY be used as long as the characters used in the MSG
exclusively visible characters and spaces similar to those
above. The selection of a code set used in the MSG part SHOULD
made with thoughts of the intended receiver. A message
characters in a code set that cannot be viewed or understood by
recipient will yield no information of value to an operator
administrator looking at it
The MSG part has two fields known as the TAG field and the
field. The value in the TAG field will be the name of the program
process that generated the message. The CONTENT contains the
of the message. This has traditionally been a freeform message
gives some detailed information of the event. The TAG is a string
ABNF alphanumeric characters that MUST NOT exceed 32 characters.
non-alphanumeric character will terminate the TAG field and will
assumed to be the starting character of the CONTENT field.
commonly, the first character of the CONTENT field that signifies
Lonvick Informational [Page 11]
RFC 3164 The BSD syslog Protocol August 2001
conclusion of the TAG field has been seen to be the left
bracket character ("["), a colon character (":"), or a
character. This is explained in more detail in Section 5.3.
4.2 Original syslog Packets Generated by a
There are no set requirements on the contents of the syslog packet
it is originally sent from a device. It should be reiterated
that the payload of any IP packet destined to UDP port 514 MUST
considered to be a valid syslog message. It is, however,
that the syslog packet have all of the parts described in Section 4.1
- PRI, HEADER and MSG - as this enhances readability by the
and eliminates the need for a relay to modify the message
For implementers that do choose to construct syslog messages with
RECOMMENDED format, the following guidance is offered
If the originally formed message has a TIMESTAMP in the
part, then it SHOULD be the local time of the device within
timezone
If the originally formed message has a HOSTNAME field, then
will contain the hostname as it knows itself. If it does
have a hostname, then it will contain its own IP address
If the originally formed message has a TAG value, then
will be the name of the program or process that generated
message
4.3 Relayed syslog
When a relay receives a packet, it will check for a valid PRI.
the first character is not a less-than sign, the relay MUST
that the packet does not contain a valid PRI. If the 3rd, 4th,
5th character is not a right angle bracket character, the relay
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
valid TIMESTAMP in the HEADER part. From these rules, there will
three general cases of received messages. Table 3 gives the
characteristics of these cases and lists the subsequent section
this document that describes the handling of that case
Case
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
Lonvick Informational [Page 12]
RFC 3164 The BSD syslog Protocol August 2001
4.3.1 Valid PRI and
If the relay does find a valid PRI and a valid TIMESTAMP, then
will check its internal configuration. Relays MUST be configured
forward syslog packets on the basis of their Priority value. If
relay finds that it is configured to forward the received packet
then it MUST do so without making any changes to the packet.
emphasize the point one more time, it is for this reason that it
RECOMMENDED that the syslog message originally transmitted adhere
the format described in Section 4.1.
It should be noted here that the message receiver does not need
validate the time in the TIMESTAMP field. The assumption may be
that a device whose date has not been correctly set will still
the ability to send valid syslog messages. Additionally, the
does not need to validate that the value in the HOSTNAME
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
If a relay does not find a valid TIMESTAMP in a received
packet, then it MUST add a TIMESTAMP and a space
immediately after the closing angle bracket of the PRI part.
SHOULD additionally add a HOSTNAME and a space character after
TIMESTAMP. These fields are described here and detailed in
4.1.2. The remainder of the received packet MUST be treated as
CONTENT field of the MSG and appended. Since the relay would have
way to determine the originating process from the device
originated the message, the TAG value cannot be determined and
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
relay. If the name cannot be determined, the IP address of
device will be used
If the relay adds a TIMESTAMP, or a TIMESTAMP and HOSTNAME, after
PRI part, then it MUST check that the total length of the packet
still 1024 bytes or less. If the packet has been expanded
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
original packet. It is for this reason that it is RECOMMENDED
the PRI and HEADER parts of originally generated syslog
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
If the relay receives a syslog message without a PRI, or with
unidentifiable PRI, then it MUST insert a PRI with a Priority
of 13 as well as a TIMESTAMP as described in Section 4.3.2.
relay SHOULD also insert a HOSTNAME as described in Section 4.3.2.
The entire contents of the received packet will be treated as
CONTENT of the relayed MSG and appended
An example of an unidentifiable PRI would be "<00>", without
double quotes. It may be that these are the first 4 characters
the message. To continue this example, if a relay does receive
syslog message with the first four characters of "<00>", then it
consult its configuration. If it is configured to forward
messages with a Priority value of 13 to another relay or collector
then it MUST modify the packet as described above. The specifics
doing this, including the RECOMMENDED insertion of the HOSTNAME,
given below
Originally received
<00>...
Relayed
<13>TIMESTAMP HOSTNAME <00>...
If the relay adds a TIMESTAMP, or a TIMESTAMP and HOSTNAME, after
PRI part, then it MUST check that the total length of the packet
still 1024 bytes or less. If the packet has been expanded
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
original packet. It is for this reason that it is RECOMMENDED
the PRI and HEADER parts of originally generated syslog
contain the values and fields documented in Section 4.1.
5.
Although Section 4 of this document specifies all requirements
the syslog protocol format and contents, certain conventions
come about over time for the inclusion of additional
within the syslog message. It must be plainly stated that
items are not mandated but may be considered by implementers
completeness and to give the recipient some additional clues of
origin and nature
Lonvick Informational [Page 14]
RFC 3164 The BSD syslog Protocol August 2001
5.1 Dates and
It has been found that some network administrators like to
their syslog messages over long periods of time. It has been
that some original syslog messages contain a more explicit time
in which a 2 character or 4 character year field immediately
the space terminating the TIMESTAMP. This is not consistent with
original intent of the order and format of the fields.
implementers wish to contain a more specific date and time
within the transmitted message, it should be within the
field. Implementers may wish to utilize the ISO 8601 [7] date
time formats if they want to include more explicit date and
information
Additional methods to address this desire for long-term
have been proposed and some have been successfully implemented.
such method is that the network administrators may choose to
the messages stored on their collectors. They may run a
script to add the year, and any other information, to each
record. Alternatively, the script may replace the stored time with
format more appropriate for the needs of the network administrators
Another alternative has been to insert a record into the file
contains the current year. By association then, all other
near that informative record should have been received in that
year. Neither of these however, addresses the issue of associating
correct timezone with each record
5.2 Domain Name and
To readily identify the device that originated the message, it may
a good practice to include its fully qualified domain name (FQDN)
its IP address within the CONTENT field. Traditionally, however
only the hostname has been included in the HOSTNAME field
5.3 Originating Process
It has also been considered to be a good practice to include
information about the process on the device that generated
message - if that concept exists. This is usually the process
and process id (often known as the "pid") for robust
systems. The process name is commonly displayed in the TAG field
Quite often, additional information is included at the beginning
the CONTENT field. The format of "TAG[pid]:" - without the
marks - is common. The left square bracket is used to terminate
TAG field in this case and is then the first character in the
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
As examples, these are valid messages as they may be observed on
wire between two devices. In the following examples, each
has been indented, with line breaks inserted in this document
readability
Example 1
<34>Oct 11 22:14:15 mymachine su: 'su root' failed for
on /dev/pts/8
This example shows an authentication error in an attempt to
additional privileges. It also shows the command attempted and
user attempting it. This was recorded as an original message
the device called mymachine. A relay receiving this would not
any changes before sending it along as it contains a
formatted PRI part and TIMESTAMP field in the HEADER part. The
value in this example is the process "su". The colon has
the TAG field and is the first character of the CONTENT field.
this case, the process id (pid) would be considered transient
anyone looking at this syslog message would gain no
information from knowing the pid. It has not been included so
first two characters of the CONTENT field are the colon and a
character
Example 2
Use the BFG
While this is a valid message, it has extraordinarily little
information. This message does not have any discernable PRI part.
does not contain a timestamp or any indication of the source of
message. If this message is stored on paper or disk,
review of the message will not yield anything of value
This example is obviously an original message from a device. A
MUST make changes to the message as described in Section 4.3
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
CONTENT portion of the MSG part. First, a valid PRI part has
added using the default priority value of 13. Next, a TIMESTAMP
been added along with a HOSTNAME in the HEADER part.
relays will not make any further changes to this message. It
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
space in the TIMESTAMP format, there are two spaces following
month in the TIMESTAMP before the day of the month. Also, the
appears to have no knowledge of the host name of the device
the message so it has inserted the IPv4 address of the device
the HOSTNAME field
Example 3
<165>Aug 24 05:34:00 CST 1987 mymachine myproc[10]: %% It'
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
indicating that it came from a locally defined facility (local4)
a severity of Notice. The HEADER part has a proper TIMESTAMP
in the message. A relay will not modify this message before
it. However, the HOSTNAME and TAG fields are not consistent with
definitions in Section 4. The HOSTNAME field would be construed
be "CST" and the beginning of the MSG part would be "1987".
It should be noted that the information contained in the CONTENT
this example is not telemetry data, nor is it supervisory control
data acquisition information. Due to the security concerns listed
Section 6 of this document, information of that nature
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
or sufficiently adaptable automated parser would be able to
the date and time information as well as a fully qualified
name (FQDN) [4] and IP address. The information about the nature
the event is, however, limited. Due to the indicated severity of
event, the process may not have been able to gather or send
more informative. It may have been fortunate to have generated
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.
the first field in the HEADER part is not a TIMESTAMP in the
defined in Section 4.1.2, it MUST be modified by a relay. A
will add a TIMESTAMP and SHOULD add a HOSTNAME as follows and
treat the entire received packet after the PRI part from the
packet as the CONTENT field of the new packet. The value used in
HOSTNAME field is only the hostname without the domain name as it
known by the relay. A TAG value will not be added to the
packet. While the inclusion of the domain name and IPv4 address
the original message is a noble endeavor, it is not consistent
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
An odor may be considered to be a message that does not require
acknowledgement. People tend to avoid bad odors but are drawn
odors that they associate with good food. The acknowledgement of
receipt of the odor or scent is not required and indeed it may be
height of discretion to totally ignore some odors. On the
hand, it is usually considered good civility to acknowledge
prowess of the cook merely from the ambiance wafting from
kitchen. Similarly, various species have been found to utilize
to attract mates. One species of moth uses this scent to find
other. However, it has been found that bolas spiders can mimic
odor of the female moths of this species. This scent will
attract male moths, which will follow it with the expectation
finding a mate. Instead, when they arrive at the source of
scent, they will be eaten [8]. This is a case of a false
being sent out with inimical intent
In its local use, the syslog process places event
messages into files on that system. This relies upon the
of the system for the protection of the messages. The
configuration of the syslog process to use the syslog protocol
transport the messages to a remote collector was an extension of
delivery of event notification messages and it exhibits the
trust of the network. There are several security consequences of
fundamental simplicity of syslog and there are some concerns
the applicability of this protocol in situations that require
delivery. Along the lines of the analogy, computer event
may be sent accidentally, erroneously and even maliciously. At
time of this writing, however, there have not been any reports of
networked device consuming any other device
Lonvick Informational [Page 18]
RFC 3164 The BSD syslog Protocol August 2001
6.1 Packet
As was described above, the message length MUST NOT exceed 1024
bytes. Attacks have seen where syslog messages are sent to
receiver that have message lengths greater than 1024 bytes. In
older versions of syslog, the receipt of syslog packets that had
message greater than 1024 bytes caused problems. syslog
receivers must not malfunction upon the receipt of packets where
message length is greater than 1024 bytes. Various behaviors
been seen on receivers that do receive messages greater than 1024
bytes. Some have been seen to log the entire contents of
message, while others have been seen to log only portions of
message. Still others have been known to discard the
altogether. Devices MUST NOT retransmit messages whose
length exceeds 1024 bytes
Similarly, the receiver must rigidly enforce the correctness of
message body. syslog collectors must not malfunction if
messages do not have the less-than and greater-than characters
a valid Priority value. They MUST treat these messages as
unformatted CONTENT as was described in Section 4.3.3 if they
it
Also, received messages must contain printable text in the message
was described throughout Section 4. Devices must not malfunction
they receive a message containing characters other than
characters described above
6.2 Message
The syslog delivery mechanism does not strongly associate the
with the message sender. The receiver of that packet will not
able to ascertain that the message was indeed sent from the
sender, or if the packet was sent from another device. It should
noted here that the message receiver does not need to verify that
HOSTNAME in the HEADER part match the name of the IP
contained in the Source Address field of the IP packet
6.2.1 Authentication
One possible consequence of this behavior is that a
machine may send syslog messages to a collector representing
as another machine. The administrative staff may become
that the status of the supposed sender of the messages may not
accurately reflected in the received messages. The
may not be able to readily discern that there are two or
machines representing themselves as the same machine
Lonvick Informational [Page 19]
RFC 3164 The BSD syslog Protocol August 2001
It should also be noted that some cases of filling the HOSTNAME
in the HEADER part might only have local significance and that
only be ephemeral. If the device had obtained an IP address from
DHCP pool, then any association between an identifier and an
source would not always hold true. The inclusion of a
qualified domain name in the CONTENT may give the administrators
best chance of identifying the source of each message if it
always be associated with an IP address or if it can always
associated with a unique machine
6.2.2 Message
Malicious exploits of this behavior have also been noted.
attacker may transmit syslog messages (either from the machine
which the messages are purportedly sent or from any other machine)
a collector. In one case, an attacker may hide the true nature of
attack amidst many other messages. As an example, an attacker
start generating forged messages indicating a problem on
machine. This may get the attention of the system administrators
will spend their time investigating the alleged problem. During
time, the attacker may be able to compromise a different machine,
a different process on the same machine. Additionally, an
may generate false syslog messages to give untrue indications
status or of events. As an example, an attacker may stop a
process on a machine, which may generate a notification of exit.
attacker may subsequently generate a forged notification that
process had been restarted. The system administrators may
that misinformation and not verify that the process had indeed
restarted
6.3 Sequenced
As a general rule, the forensics of a network anomaly rely
reconstructing the sequence of events. In a perfect world,
messages would be received on the syslog collector in the order
their generation from the other devices and anyone looking at
records would have an accurate picture of the sequence of events
Unfortunately, the syslog process and protocol do not ensure
delivery. This section details some of the problems that may
encountered from this
6.3.1 Single Source to a
The syslog records are usually presented (placed in a file,
on the console, etc.) in the order in which they are received.
is not always in accordance with the sequence in which they
generated. As they are transported across an IP network, some out
order receipt should be expected. This may lead to some confusion
Lonvick Informational [Page 20]
RFC 3164 The BSD syslog Protocol August 2001
messages may be received that would indicate that a process
stopped before it was started. This may be somewhat rectified if
originating process had timestamped or numbered each of the
before transmission. In this, the sending device should utilize
authoritative time source. It should be remembered, however,
not all devices are capable of receiving time updates, and not
devices can timestamp their messages
6.3.2 Multiple Sources to a
In syslog, there is no concept of unified event numbering.
devices are free to include a sequence number within the CONTENT
that can hardly be coordinated between multiple devices. In
cases, multiple devices may report that each one is sending
number one. Again, this may be rectified somewhat if the
devices utilize a timestamp from an authoritative source in
messages. As has been noted, however, even messages from a
device to a single collector may be received out of order.
situation is compounded when there are several devices configured
send their syslog messages to a single collector. Messages from
device may be delayed so the collector receives messages from
device first even though the messages from the first device
generated before the messages from the second. If there is
timestamp or coordinated sequence number, then the messages may
presented in the order in which they were received which may give
inaccurate view of the sequence of actual events
6.3.3 Multiple Sources to Multiple
The plethora of configuration options available to the
administrators may further skew the perception of the order
events. It is possible to configure a group of devices to send
status messages -or other informative messages- to one collector
while sending messages of relatively higher importance to
collector. Additionally, the messages may be sent to different
on the same collector. If the messages do not contain
from the source, it may be difficult to order the messages if
are kept in different places. An administrator may not be able
determine if a record in one file occurred before or after a
in a different file. This may be somewhat alleviated by
marking messages with a timestamp into all destination files.
these have coordinated timestamps, then there will be some
of the time of receipt of the individual messages
Lonvick Informational [Page 21]
RFC 3164 The BSD syslog Protocol August 2001
6.3.4
Without any sequence indication or timestamp, messages may
recorded and replayed at a later time. An attacker may record a
of messages that indicate normal activity of a machine. At a
time, that attacker may remove that machine from the network
replay the syslog messages to the collector. Even with a
field in the HEADER part, an attacker may record the packets
could simply modify them to reflect the current time
retransmitting them. The administrators may find nothing unusual
the received messages and their receipt would falsely indicate
activity of the machine
6.4 Reliable
As there is no mechanism within either the syslog process or
protocol to ensure delivery, and since the underlying transport
UDP, some messages may be lost. They may either be dropped
network congestion, or they may be maliciously intercepted
discarded. The consequences of the drop of one or more
messages cannot be determined. If the messages are simple
updates, then their non-receipt may either not be noticed, or it
cause an annoyance for the system operators. On the other hand,
the messages are more critical, then the administrators may
become aware of a developing and potentially serious problem
Messages may also be intercepted and discarded by an attacker as
way to hide unauthorized activities
6.5 Message
Besides being discarded, syslog messages may be damaged in transit
or an attacker may maliciously modify them. In the case of a
containing a syslog message being damaged, there are
mechanisms built into the link layer as well as into the IP [9]
UDP protocols which may detect the damage. An intermediary
may discard a damaged IP packet [10]. Damage to a UDP packet may
detected by the receiving UDP module, which may silently discard it
In any case, the original contents of the message will not
delivered to the collector. Additionally, if an attacker
positioned between the sender and collector of syslog messages,
may be able to intercept and modify those messages while in-
to hide unauthorized activities
6.6 Message
While there are no strict guidelines pertaining to the event
format, most syslog messages are generated in human readable
with the assumption that capable administrators should be able
Lonvick Informational [Page 22]
RFC 3164 The BSD syslog Protocol August 2001
read them and understand their meaning. Neither the syslog
nor the syslog application have mechanisms to provide
of the messages in transit. In most cases passing clear-
messages is a benefit to the operations staff if they are
the packets off of the wire. The operations staff may be able
read the messages and associate them with other events seen
other packets crossing the wire to track down and correct problems
Unfortunately, an attacker may also be able to observe the human
readable contents of syslog messages. The attacker may then use
knowledge gained from those messages to compromise a machine or
other damage
6.7 Message Prioritization and
While the processes that create the messages may signify
importance of the events through the use of the message
value, there is no distinct association between this value and
importance of delivery of the packet. As an example of this
consider an application that generates two event messages. The
is a normal status message but the second could be an
message denoting a problem with the process. This second
would have an appropriately higher Severity value associated with
importance of that event. If the operators had configured that
of these messages be transported to a syslog collector then
would, in turn, be given to UDP for transmission. Under
conditions, no distinction would be made between them and they
be transmitted in their order
Again, under normal circumstances, the receiver would accept
messages as they are received. If many devices are
normal status messages, but one is transmitting an important
message, there is no inherent mechanism within the syslog protocol
prioritize the important message over the other messages
On a case-by-case basis, device operators may find some way
associate the different levels with the quality of
identifiers. As an example, the operators may elect to define
linkage between syslog messages that have a specific Priority
with a specific value to be used in the IPv4 Precedence field [9],
the IPv6 Traffic Class octet [11], or the Differentiated
field [12]. In the above example, the operators may have the
to associate the status message with normal delivery
associating the message indicating a problem with a high reliability
low latency queue as it goes through the network. This would
the affect of prioritizing the essential messages before the
status messages. Even with this hop-by-hop prioritization,
queuing mechanism could still lead to head of line blocking on
transmitting device as well as buffer starvation on the
Lonvick Informational [Page 23]
RFC 3164 The BSD syslog Protocol August 2001
device if there are many near-simultaneous messages being sent
received. This behavior is not unique to syslog but is endemic
all operations that transmit messages serially
There are security concerns for this behavior. Head of line
of the transmission of important event messages may relegate
conveyance of important messages behind less important messages.
the queue is cleared appropriately, this may only add seconds to
transmission of the important message. On the other hand, if
queue is not cleared, then important messages may not be transmitted
Also at the receiving side, if the syslog receiver is suffering
buffer starvation due to large numbers of messages being
near-simultaneously, important messages may be
indiscriminately along with other messages. While these are
with the devices and their capacities, the protocol security
is that there is no prioritization of the relatively more
messages over the less important messages
6.8
Since there is no control information distributed about any
or configurations, it is wholly the responsibility of the
administrator to ensure that the messages are actually going to
intended recipient. Cases have been noted where devices
inadvertently configured to send syslog messages to the
receiver. In many cases, the inadvertent receiver may not
configured to receive syslog messages and it will probably
them. In certain other cases, the receipt of syslog messages
been known to cause problems for the unintended recipient [13].
messages are not going to the intended recipient, then they cannot
reviewed or processed
6.9 Forwarding
As it is shown in Figure 1, machines may be configured to
syslog messages to subsequent relays before reaching a collector.
one particular case, an administrator found that he had
configured two relays to forward messages with certain
values to each other. When either of these machines either
or generated that type of message, it would forward it to the
relay. That relay would, in turn, forward it back. This cycle
cause degradation to the intervening network as well as to
processing availability on the two devices. Network
must take care to not cause such a death spiral
Lonvick Informational [Page 24]
RFC 3164 The BSD syslog Protocol August 2001
6.10 Load
Network administrators must take the time to estimate the
size of the syslog receivers. An attacker may perform a Denial
Service attack by filling the disk of the collector with
messages. Placing the records in a circular file may alleviate
but that has the consequence of not ensuring that an
will be able to review the records in the future. Along this line,
receiver or collector must have a network interface capable
receiving all messages sent to it
Administrators and network planners must also critically review
network paths between the devices, the relays, and the collectors
Generated syslog messages should not overwhelm any of the
links
7. IANA
The syslog protocol has been assigned UDP port 514. This
assignment will be maintained by IANA exclusively for this protocol
The syslog protocol provides for the definition of named
to indicate the Severity of each message and the Facility
generated the message as described in Section 4. The name
identifiers for these attributes are defined as numbers.
protocol does not define the specific assignment of the name
for these numbers; the application developer or system vendor
allowed to define the attribute, its semantics, and the
numbers. This name space will not be controlled to
collisions as systems are expected to use the same attributes
semantics and associated numbers to describe events that are
similar even between heterogeneous devices
8. Conclusion and Other
The syslog protocol may be effectively used to transport
notification messages across a network. In all cases, it
important that the syslog message receiver embody the principle
"be liberal in what you accept". It is highly recommended that
network operators who choose to use this understand
characteristics of the protocol and its security implications
There have been attempts in the past to standardize the format of
syslog message. The most notable attempt culminated in a BOF at
Fortieth Internet Engineering Task Force meeting in 1997. This
the Universal Logging Protocol (ulp) BOF and the minutes of
meeting are on-line at the IETF Proceedings web site [14].
Lonvick Informational [Page 25]
RFC 3164 The BSD syslog Protocol August 2001
Many good thoughts came from that effort and interested
may want to find some of the notes or papers produced from
effort
At the time of this writing, efforts are underway to allow the
of international character sets in applications that have
traditionally thought of as being text-only. The HOSTNAME
TIMESTAMP fields described above are representative of this. Also
the entire CONTENT field has traditionally been printing
and spaces in the code set known as US-ASCII. It is hoped that
proponents of these internationalization efforts will find a
way to allow the use of international character sets within
messages without being disruptive. It should also be hoped
implementers will allow for the future acceptance of additional
sets and that they may make appropriate plans. Again, it must
cautioned that the simplicity of the existing system has been
tremendous value to its acceptance. Anything that lessens
simplicity may diminish that value
The following people provided content feedback during the writing
this document
Jon Knight
Magosanyi Arpad
Balazs Scheidler
Jon Callas
Eliot Lear
Petter Reinholdtsen
Darren Reed
Alfonso De Gregorio
Eric Allman
Andrew Ross
George Maslyar
Albert Mietus
Russ Allbery stanford.edu
Titus D. Winters
Edwin P. Boon
Jeroen M. Mostert
Eric Allman is the original inventor and author of the syslog
and protocol. The author of this memo and the community at
would like to express their appreciation for this work and for
usefulness that it has provided over the years
Lonvick Informational [Page 26]
RFC 3164 The BSD syslog Protocol August 2001
A large amount of additional information about this de-facto
operating system feature may usually be found in the syslog.conf
as well as in the man pages for syslog.conf, syslog, syslogd,
logger, of many Unix and Unix-like devices
1 Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
2 Crocker, D. and P. Overell, "Augmented BNF for
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
Specification", STD 13, RFC 1035, November 1987.
6 Hinden, R. and S. Deering, "IP Version 6 Addressing Architect