syslog

From Wikipedia, the free encyclopedia
  (Redirected from Syslogd)
Jump to: navigation, search

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.

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 standardized by 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.

Syslog Message Components[edit]

Originator provides[edit]

The information provided by the originator of a Syslog message includes:

FACILITY SEVERITY_LEVEL MSG

Facility[edit]

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.[4] The list of facilities available[5] is defined by RFC 3164:

The mapping between facility number and keyword is not uniform over different operating systems and different syslog implementations.[6]

Severity levels[edit]

Value Severity Keyword Description / Examples
0 Emergency emerg Multiple apps/servers/sites. This level should not be used by applications.
1 Alert alert Should be corrected immediately, An example might be the loss of the primary ISP connection.
2 Critical crit May be used to indicate a failure in the system's primary application.
3 Error err An application has exceeded it file storage limit and attempts to write are failing.
4 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 .
5 Notice notice Events that are unusual but not error conditions .
6 Informational info Normal operational messages -no action required. Example an application has started, paused or ended successfully.
7 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".

MSG[edit]

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[edit]

The syslog process adds information to a header before passing the entry to the syslog receiver which includes:

  • Originator process ID
  • Timestamp
  • Hostname or IP address of the device.

Limitations[edit]

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[edit]

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).[7] This mitigates many problems with the UDP implementation.

Syslog over TLS uses port number 6514 by default so firewalls should be configured to pass packets for this port.

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 to problems.

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:[8]

See also[edit]

References[edit]

External links[edit]