Syslog

RFC 3195 (2001) RFC 5424 (2009) RFC 5426 (2009)

Syslog is a de facto standard for transmitting log messages in an IP computer network. The term "syslog " is often used for both the actual syslog network protocol as well as for the application or library that syslog messages sending or receiving.

The syslog protocol is very simple - the syslog client sends a short text message (less than 1024 bytes ) to the syslog receiver. The receiver is often called " syslogd ", "syslog daemon " or " syslog server". A syslog server can act as a relay and forward received messages to another server. Syslog messages are sent via UDP (port 514) and include the message in plain text, ie unencrypted.

Syslog is typically used for computer system management and security monitoring. It has some weaknesses, but stands on a variety of devices. This allows the easy integration of a wide variety of log sources into a central repository ( table of contents ).

Building a Syslog message

A syslog message consists of three components: a selector - called Priority - a header and the actual content.

The one -byte Priority selector consists of two parts: the Facility field and the Severity field. This means that the syslog messages according to their origin and their severity can be classified. The last three bits of the Priority comprehensive Severity field contains a numeric value between 0 and 7, with 0 being the most critical or urgent step is:

0 Emergency            1 alert            2 Critical            3 Error            4 Warning            5 Notice            6 Informational            7 debug The first five bits of the Priority comprehensive facility field contains a numeric value that indicates the service or component that generated the syslog message. The following values ​​are predefined according to RFC 3164:

0 kernelmessages            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           FTP daemon 11           12 NTP subsystem           13 log audit           14 log alert           15 clock daemon           16 local0           17 local1           18 local2           19 local3           20 local4           21 local5           22 local6           23 local7 For general syslog messages are the values ​​16-23 provided ( local0 through local7 ). But it is quite permissible to use the predefined values ​​from 0 to 15 for their own purposes. Using the Priority selector can easily be filtered according to specific messages such as: "NotifyUserAction all mail server message on the severity of error".

The header contains a time stamp and the name or IP address of the sender of the syslog message. The timestamp is from the receiver, so the syslog server inserted. It contains the date and time to the local time of reception. Often additional dispatch date and time will be housed in the actual message.

History

Syslog was developed by Eric Allman as part of the Sendmail project. Originally ( in the early 1980s ) it was developed and used exclusively for Sendmail. However, it was soon to be a useful tool out, which was then used by other applications. Today is the standard syslog logging mechanism under Unix and Linux. In addition, syslog implementations exist on other operating systems like Microsoft Windows.

Syslog was initially not standardized. To increase the security of the protocol, was the Internet Engineering Task Force, a working group. 2001, the state reached in RFC 3164 was documented. The band is working on new enhancements.

View

There are new applications and increasing interest in syslog. It has recently been standardized syslog or recommended for a number of auditing applications, such as the "health care environment" ( IHE ) in the USA. The standardization efforts within the IETF to take yet.

Weaknesses

The syslog protocol has some weaknesses:

• No authentication
• Transmits messages in plain text
• Uses Severity and Facility inconsistent
• Some implementations call the original source is not ( when forwarding a message over several loghost )
• Transmits messages via UDP connectionless

These weaknesses were the trigger for the standardization efforts described above. Moreover, in practice there are many implementations that solve these problems completely or partially. Such implementations are available for all major operating systems. The solutions from different vendors, however, are only partially compatible with each other. A very popular implementation is syslog- ng with extensions of the syslog protocol can be viewed as the industry standard now.