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. Implementations of syslog exist for many operating systems.
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, Information, and Debug. A configuration file defines the destination of messages, based on the facility and severity, to various devices (for example console), files (for example /var/log/07_debug.log), or forward the message to remote syslog servers or relays.
Most implementations provide a command line utility, often called logger, that can send messages to the log.
Some implementations include reporting programs which 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.
Syslog Message Components
The information provided by the originator of a Syslog message includes:
FACILITY SEVERITY_LEVEL MSG
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.
|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".
The MSG component has these fields:
- TAG should be the name of the program or process that generated the message.
- CONTENT contains the details of the message.
The free form CONTENT SHOULD be encoded as UTF-8 and octet values in the traditional ASCII control character range SHOULD be avoided.
Although the CONTENT may be up to 2048 octets, long messages may be problematic for the filtering or reporting program.
Syslog process provides
The syslog process adds information to a header before passing the entry to the syslog receiver which includes:
- Originator process ID
- Hostname or IP address of the device.
Since each process, application and operating system was written independently, there is little uniformity to the content of MSG. For this reason, no assumption is made about the formatting or contents of the MSG.
The protocol is simplex with no means to acknowledge the delivery to the originator.
Transport Layer Protocol
In the event that messages are to be sent over the network they may be sent in cleartext via the User Datagram Protocol (UDP). It must be understood that UDP is unreliable, does not guarantee the delivery of the messages. They may either be dropped through network congestion, may be maliciously intercepted and discarded or altered. The UDP protocol does not ensure ordered delivery of packets. UDP syslog used port 514.
The use of UDP has been defined to be obsolete by RFC 5424 which states implementation MUST support TLS via the Transmission Control Protocol (TCP). This mitigates many problems with the UDP implementation.
Syslog uses port number 6514 by default so firewalls should be configured to pass packets for this port.
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.
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 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