Created 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.
PRI
HEADER
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 these 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 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