Introduction to Syslog Protocol
Created 2003-03-25 by Wajih-ur-Rehman.
Overview
This paper is not an in depth paper about syslog. It simply gives you an
overview and a broader picture about the Syslog Protocol and its architecture. If you are interested
in in-depth details about Syslog, I would strongly suggest you to go through RFC:
3164.
What is Syslog?
Syslog is a protocol that allows a machine to send event notification
messages across IP networks to event message collectors - also known as Syslog Servers
or Syslog Daemons. In other words, a machine or a device can be configured in
such a way that it generates a Syslog Message and forwards it to a specific
Syslog Daemon (Server).
Syslog messages are based on the User Datagram Protocol (UDP) type of
Internet Protocol (IP) communications. Syslog messages are received on UDP port
514. Syslog message text is generally no more than 1024 bytes in length. Since
the UDP type of communication is connectionless, the sending or receiving host
has no knowledge receipt for retransmission. If a UDP packet gets lost due to
congestion on the network or due to resource unavailability, it will simply get
lost - no one would know about it!!
What is Syslog Daemon?
A Syslog Daemon or Server is an entity that would listen to the Syslog
messages that are sent to it. You cannot configure a Syslog Daemon to ask a
specific device to send it Syslog Messages. If a specific device has no ability
to generate Syslog Messages, then a Syslog Daemon cannot do anything about it.
To make this thing clear, you can consider a Syslog Server or Syslog Daemon as a
TV which can only display you the program that is currently running on a
specific channel. You cannot ask another station to send a new program on that
channel.
Some Background
Syslog Protocol was created for use by Unix Operating Systems.
Using Syslog, a remote Unix host could, in
effect, keep track of the general well being of any other Unix host. Any
application can generate Syslog Compliant messages to send the information over
the network. 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. One of the fundamental design
considerations of the syslog protocol was 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]
Format of a Syslog Packet
The full format of a Syslog message seen on the wire has three ditinct
parts.
1. PRI
2. HEADER
3.MSG.
The total length of the packet cannot exceed 1,024 bytes, and there is no
minimum length
1. PRI
The Priority part is a number that is enclosed in angle brackets. This
represents both the Facility and Severity of the message. This number is an
eight bit number. The first 3 least significant bits represent the Severity of
the message (with 3 bits you can represent 8 different Severities) and the other
5 bits represent the Facility of the message. You can use the Facility and the
Severity values to apply certain filters on the events in the Syslog Daemon.
Note that Syslog Daemon cannot generate thse Priority and Facility
values. They are generated by the applications on which the event is generated.
Following are the codes for Severity and Facility. Please note that the codes
written below are the recommended codes that the applicatoins should generate in
the specified situations. You cannot, however, be 100 % sure if it really is the
correct code sent by the application. For example: An application can generate a
numerical code for severity as 0 (Emergency) when it should have generated 4
(Warning) instead. Syslog Daemon can not do anything about it!! It will simply
receive the message as it is.
a) Severity Codes
The Severity code is the severity of the message that has been
generated. Following are the codes for Severity:
| Numerical Code |
Severity |
| 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 |
b) Facility Codes
The facility is the application or operating system component
that generates a log message.Following are the codes for facility:
| Numerical Code |
Facility |
| 0 |
kernel messages |
| 1 |
user-level messages |
| 2 |
mail system |
| 3 |
system daemons |
| 4 |
security/authorization messages |
| 5 |
messages generated internally by syslogd |
| 6 |
line printer subsystem |
| 7 |
network news subsystem |
| 8 |
UUCP subsystem |
| 9 |
clock daemon |
| 10 |
security/authorization messages |
| 11 |
FTP daemon |
| 12 |
NTP subsystem |
| 13 |
log audit |
| 14 |
log alert |
| 15 |
clock daemon |
| 16 |
local use 0 |
| 17 |
local use 1 |
| 18 |
local use 2 |
| 19 |
local use 3 |
| 20 |
local use 4 |
| 21 |
local use 5 |
| 22 |
local use 6 |
| 23 |
local use 7 |
1.1 Calculating Priority Value
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.
2. Header
The HEADER part contains the following things:
a) Timestamp -- The Time stamp is the date and time at which the message was
generated. Be warned, that this timestamp is picked up from the system time and
if the system time is not correct, you might get a packet with totally incorrect
time stamp
b) Hostname or IP address of the device.
3. MSG
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. The MSG part has two fields:
a) TAG field
b) 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.
Some Important Points
- As mentioned above, since Syslog protocol is UDP based, it is unreliable.
It does not guarantee you the delivery of the messages. They may either be
dropped through network congestion, or they may be maliciously intercepted
and discarded.
- As mentioned above, 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.
- The receiver of a Syslog packet will not be able to ascertain that the
message was indeed sent from the reported sender.
- One possible problem associated with the above mentioned point is of
Authentication. A misconfigured machine may send syslog messages to a Syslog
Daemon representing itself as another machine. The administrative staff may
become confused because the status of the supposed sender of the messages
may not be accurately reflected in the received messages.
- Another problem associated with point 2 is that an attacker may start
sending fake messages indicating a problem on some machine. This may get the
attention of the system administrators who will spend their time
investigating the alleged problem. During this time, the attacker may be
able to compromise a different machine, or a different process on the same
machine.
- The Syslog protocol do not ensure ordered delivery of packets.
- An attacker may record a set of messages that indicate normal activity of
a machine. At a later time, that attacker may remove that machine from the
network and replay the syslog messages to the Daemon.
Related Software
The MonitorWare
line of products [2] can be used as Syslog Daemons for Windows Operating
System to collect Syslog Messages from various devices (including Routers, Fire
walls etc). They can also act as relaying servers and can forward the data from
one Syslog Daemon to another.
References
[1] http://www.ietf.org/rfc/rfc3164.txt
[2] http://www.monitorware.com
Author's Address
Wajih-ur-Rehman
wrehman@ro1.adiscon.com
Adiscon GmbH
Mozartstrasse 21
97950 Grossrinderfeld
Germany
Disclaimer
The information within
this paper may change without notice. Use of this information constitutes
acceptance for use in an AS IS condition. There are NO warranties with regard to
this information. In no event shall the authors be liable for any damages
whatsoever arising out of or in connection with the use or spread of this
information. Any use of this information is at the user's own risk.
|
