In computing, syslog is a widely used standard for message logging. It permits separation of the software that generates messages, the system that stores them, and the software that reports and analyzes them.
Computer system designers can use syslog for system management and security auditing as well as general informational, analysis, and debugging messages. A wide variety of devices (such as printers and routers) and message receivers across multiple platforms use the syslog standard. Because of this, system designers can use syslog to integrate log data from different types of systems in a central repository.
In the syslog standard, each message is labeled with a facility code and assigned a severity label. The facility code indicates which of the following software types generated the message: auth, authpriv, daemon, cron, ftp, lpr, kern, mail, news, syslog, user, uucp, or local0 ... local7. The severity designations, from most to least severe, are: Emergency, Alert, Critical, Error, Warning, Notice, Info, and Debug.
Implementations of syslog exist for many operating systems. Specific configuration may permit directing messages to various devices (e.g., console), files (e.g., /var/log/), or remote syslog servers. Most implementations provide a command line utility, often called logger, that can send messages to the log. Some implementations permit filtering and display of syslog messages.
Syslog was developed in the 1980s by Eric Allman as part of the Sendmail project, and was initially used solely for Sendmail. It proved so valuable that other applications began using it as well. Syslog has since become the standard logging solution on Unix and Unix-like systems; there have also been a variety of syslog implementations on other operating systems and is commonly found in network devices such as routers.
Syslog functioned as a de facto standard, without any authoritative published specification, and many implementations existed, some of which were incompatible. The Internet Engineering Task Force documented the status quo in RFC 3164. It was made obsolete by subsequent additions in RFC 5424.
Various groups are working on draft standards detailing the use of syslog for more than just network and security event logging, such as its proposed application within the health care environment.
Regulations, such as SOX, PCI DSS, HIPAA, and many others are requiring organizations to implement comprehensive security measures, which often include collecting and analyzing logs from many different sources. Syslog has proven to be an effective format to consolidate logs, as there are many open source and proprietary tools for reporting and analysis. Converters exist from Windows Event Log as well as other log formats to syslog.
An emerging area of managed security services is the collection and analysis of syslog records for organizations. Companies calling themselves Managed Security Service Providers attempt to apply analytics techniques (and sometimes artificial intelligence algorithms) to detect patterns and alert customers to problems.
A facility is used to specify what type of program is logging the message. This lets the configuration file specify that messages from different facilities will be handled differently. The list of facilities available is defined by RFC 3164:
|List of facilities|
|Facility Number||Keyword||Facility Description|
|5||syslog||messages generated internally by syslogd|
|6||lpr||line printer subsystem|
|7||news||network news subsystem|
|16||local0||local use 0 (local0)|
|17||local1||local use 1 (local1)|
|18||local2||local use 2 (local2)|
|19||local3||local use 3 (local3)|
|20||local4||local use 4 (local4)|
|21||local5||local use 5 (local5)|
|22||local6||local use 6 (local6)|
|23||local7||local use 7 (local7)|
The mapping between facility number and keyword is not uniform over different operating systems and different syslog implementations.
For cron either 9 or 15 or both may be used.
The confusion is even greater regarding auth/authpriv. 4 and 10 are most common but 13 and 14 may also be used.
|Severity||Keyword||Description / Examples|
|Emergency||emerg||Multiple apps/servers/sites. This level should not be used by applications.|
|Alert||alert||Should be corrected immediately, An example might be the loss of the primary ISP connection.|
|Critical||crit||May be used to indicate a failure in the system's primary application.|
|Error||err||An application has exceeded it file storage limit and attempts to write are failing.|
|Warning||warning||May indicate that an error will occur if action is not taken, For example a non-root file system has only 2GB remaining .|
|Notice||notice||Events that are unusual but not error conditions .|
|Informational||info||Normal operational messages -no action required. Example an application has started, paused or ended successfully.|
|Debugging||debug||Info useful to developers for debugging the application.|
Severity levels (other than emergency and debugging) are very subjective. For example if the purpose of the system is to process transactions to update customer account balance information, an error in the final step should be assigned the alert level. However, an error occurring in an attempt to display the zip code of the customer may be assigned and error or even a warning level.
The process which handles the message (syslogd) usually includes it ALL lower levels. That is, if messages are separated by individual severity a warning entry will be included in notice, info and debug processing.
A common mnemonic used to remember the syslog levels from bottom to top is: "Do I Notice When Evenings Come Around Early".
Format of a Syslog packet
The full format of a Syslog message seen on the wire has three distinct parts:
<PRI> HEADER MSG
The total length of the packet cannot exceed 1,024 bytes, and there is no minimum length.
The PRI 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.
The HEADER part contains the following:
- Timestamp -- the date and time at which the message was generated. This is picked up from the sending system's system time which might differ from the receiving system's system time
- Hostname or IP address of the device.
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:
- TAG field
- 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 section possibly contains original research. (December 2013)|
The UDP-based Syslog protocol is unreliable. Unlike TCP-based transmission of messages, UDP 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. The Syslog protocol does not ensure ordered delivery of packets.
Since each process, application and operating system was written 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 messages.
The receiver of a Syslog packet may not be able to authenticate that the message was indeed sent from the reported sender. 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 authentication 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. 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.
Syslog is a client/server protocol: a logging application transmits a text message to the syslog receiver. The receiver is commonly called syslogd, syslog daemon or syslog server. Syslog messages may be sent via the User Datagram Protocol (UDP) or the Transmission Control Protocol (TCP). The data is sent in cleartext; although not part of the syslog protocol itself, an SSL wrapper may be used to provide for a layer of encryption through SSL/TLS. Syslog uses the port number 514.
The original specification in RFC 3164 did not specify many protocol aspects, such as the maximum message size and the character encoding for the message text. RFC 5424 added many details. Among others, implementations must support a minimum message size of at least 480 octets, and should support 2048 octets; messages should be encoded as UTF-8.
The Syslog protocol is defined by Request for Comments (RFC) documents published by the Internet Engineering Task Force (Internet standards). The following is a list of RFCs that define the Syslog protocol:
- RFC 3164 The BSD syslog Protocol (obsoleted by RFC 5424)
- RFC 3195 Reliable Delivery for syslog
- RFC 5424 The Syslog Protocol
- RFC 5425 TLS Transport Mapping for Syslog
- RFC 5426 Transmission of Syslog Messages over UDP
- RFC 5427 Textual Conventions for Syslog Management
- RFC 5848 Signed Syslog Messages
- RFC 6012 Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog
- RFC 6587 Transmission of Syslog Messages over TCP
- Gerhards R. "RFC 5424". The Syslog Protocol.
- "LXer: Patent jeopardizes IETF syslog standard".
- "IETF IPR disclosure on HUAWEI's patent claims".
- "Syslog Facility". Retrieved 22 November 2012.
- "Syslog Facilities". Retrieved 15 February 2012.
- "The Ins and Outs of System Logging Using Syslog".
- RFC 3164, The BSD syslog Protocol
- RFC 3195, Reliable Delivery for syslog
- "Security Issues in Network Event Logging (syslog)". IETF.
- IETF syslog working group
- SANS Paper The Ins and Outs of System Logging Using Syslog
- NIST SP 800-92 Guide to Computer Security Log Management (PDF)
- NetLogger methodology and tools for debugging and analysis of complex distributed applications