Syslog
Syslog is a standard for computer data logging. It separates the software that generates messages from the system that stores them and the software that reports and analyzes them.
Syslog can be used for computer system management and security auditing as well as generalized informational, analysis, and debugging messages. It is supported by a wide variety of devices (like printers and routers) and receivers across multiple platforms. Because of this, syslog can be used to integrate log data from many different types of systems into a central repository.
Messages are labeled with a facility code (auth, authpriv, daemon, cron, ftp, lpr, kern, mail, news, syslog, user, uucp, local0, ... , local7) indicating the type of software that generated the messages, and are assigned a severity (Emergency, Alert, Critical, Error, Warning, Notice, Info, Debug).
Implementations are available for many operating systems. Specific configuration may permit directing messages to various devices (console), files (/var/log/) or remote syslog servers. Most implementations also provide a command line utility, often called logger, that can send messages to the syslog. Some implementations permit the filtering and display of syslog messages.
Syslog is now standardized within the Syslog working group of the IETF.
Contents |
History[edit]
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.[1]
At different points in time, various companies have attempted patent claims on syslog.[2][3] This had little effect on the use and standardization of the protocol.
Outlook[edit]
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 of problems.
Facility Levels[edit]
A facility level 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.[4] The list of facilities available:[5] (defined by RFC 3164)
| Facility Number | Keyword | Facility Description |
|---|---|---|
| 0 | kern | kernel messages |
| 1 | user | user-level messages |
| 2 | mail system | |
| 3 | daemon | system daemons |
| 4 | auth | security/authorization messages |
| 5 | syslog | messages generated internally by syslogd |
| 6 | lpr | line printer subsystem |
| 7 | news | network news subsystem |
| 8 | uucp | UUCP subsystem |
| 9 | clock daemon | |
| 10 | authpriv | security/authorization messages |
| 11 | ftp | FTP daemon |
| 12 | - | NTP subsystem |
| 13 | - | log audit |
| 14 | - | log alert |
| 15 | cron | clock daemon |
| 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.[6]
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 levels[edit]
RFC 5424 defines eight severity levels:
| Code | Severity | Keyword | Description | General Description |
|---|---|---|---|---|
| 0 | Emergency | emerg (panic) | System is unusable. | A "panic" condition usually affecting multiple apps/servers/sites. At this level it would usually notify all tech staff on call. |
| 1 | Alert | alert | Action must be taken immediately. | Should be corrected immediately, therefore notify staff who can fix the problem. An example would be the loss of a primary ISP connection. |
| 2 | Critical | crit | Critical conditions. | Should be corrected immediately, but indicates failure in a primary system, an example is a loss of a backup ISP connection. |
| 3 | Error | err (error) | Error conditions. | Non-urgent failures, these should be relayed to developers or admins; each item must be resolved within a given time. |
| 4 | Warning | warning (warn) | Warning conditions. | Warning messages, not an error, but indication that an error will occur if action is not taken, e.g. file system 85% full - each item must be resolved within a given time. |
| 5 | Notice | notice | Normal but significant condition. | Events that are unusual but not error conditions - might be summarized in an email to developers or admins to spot potential problems - no immediate action required. |
| 6 | Informational | info | Informational messages. | Normal operational messages - may be harvested for reporting, measuring throughput, etc. - no action required. |
| 7 | Debug | debug | Debug-level messages. | Info useful to developers for debugging the application, not useful during operations. |
A common mnemonic used to remember the syslog levels from bottom to top is: "Do I Notice When Evenings Come Around Early".
Internet standards[edit]
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:[7]
- 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
See also[edit]
References[edit]
- ^ 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".
- ^ "Security Issues in Network Event Logging (syslog)". IETF.
External links[edit]
- IETF syslog working group
- SANS Paper The Ins and Outs of System Logging Using Syslog (Dead link)
- NIST SP 800-92 Guide to Computer Security Log Management (PDF)
- NetLogger methodology and tools for debugging and analysis of complex distributed applications
