syslog,rsyslog and syslog-ng

http://en.wikipedia.org/wiki/Syslog

Syslog is a standard for computer message logging. It permits separation of 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 (one of: 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 (one of: 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 by the IETF in RFC 5424

[hide]

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 to 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	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 secondary 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".

Format of a Syslog packet[edit]

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.

Priority[edit]

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.

Calculating Priority Value[edit]

The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. For example, a kernel message (Facility=0) with a Severity of Emergency (Severity=0) would have a Priority value of 0. Also, a "local use 4" message (Facility=20) with a Severity of Notice (Severity=5) would have a Priority value of 165. In the PRI part of a Syslog message, these values would be placed between the angle brackets as <0> and <165> respectively.

Header[edit]

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.

Message[edit]

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.

Limitations[edit]

This section possibly contains original research. Please improve it by verifying the claims made and addinginline citations. Statements consisting only of original research should be removed. (December 2013)

Since Syslog protocol is UDP based, it is unreliable. It 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.

Protocol[edit]

Syslog is a client/server protocol:^[7] a logging application transmits a text message to the syslog receiver. The receiver is commonly called syslogd, syslogdaemon or syslog server. Syslog messages may be sent via the User Datagram Protocol (UDP) or the Transmission Control Protocol (TCP).^[8] The data is sent incleartext; 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 maximum message size of at least 480 octets, and should support 2048 octets; messages should be encoded as UTF-8.

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:^[9]

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

Protocol[edit]

Rsyslog uses the quasi-standard BSD syslog protocol, specified in RFC 3164. As the text of RFC 3164 is an informational description and not a standard, various incompatible extensions of it emerged. Rsyslog supports many of these extensions. The format of relayed messages can be customized.

The most important extensions of the original protocol supported by rsyslog are:

ISO 8601 timestamp with millisecond granularity and timezone information
the addition of the name of relays in the host fields to make it possible to track the path a given message has traversed
reliable transport using TCP
support GSS-API and TLS
logging directly into various database engines.
support for RFC 5424, RFC 5425, RFC 5426
support for RELP
support for buffered operation modes where messages are buffered locally if the receiver is not ready
complete input/output support for systemd journal

History[edit]

The rsyslog project began in 2004, when Rainer Gerhards, the primary author of rsyslog, decided to write a new strong syslog daemon to compete with syslog-ng, because, according to the author, "A new major player will prevent monocultures and provide a rich freedom of choice."^[1] Rainer Gerhards worked on rsyslog inside his own company, Adiscon GmbH.

Distributions[edit]

rsyslog is available for a number of Unix systems and Linux distributions, among others:^[2]

Fedora (In November 2007, rsyslog has become the default syslogd for the Fedora project) Fedora was the first major distribution to adopt this software; however, since Fedora 20 "Heisenbug" (released on December 17 2013) the default syslog has been replaced by journald.
openSUSE (default since 11.2; November 2009)
Debian GNU/Linux (As of Debian 5.0, rsyslog has become the default syslog^[3])
Ubuntu
Red Hat Enterprise Linux (from RHEL 5)
SUSE Linux Enterprise Server (from SLES 11 SP 2 ^[4])
Solaris
FreeBSD
OpenBSD
Gentoo
Arch Linux

Related RFCs and working groups[edit]

RFC 3164 - The BSD syslog Protocol (obsoleted by RFC 5424)
RFC 5424 - The Syslog Protocol (obsoletes RFC 3164)
RFC 5425 - Transport Layer Security Mapping for Syslog
RFC 5426 - Transmission of Syslog Messages over UDP

References[edit]

Jump up^ "Why does the world need another syslog?"

. August 12, 2007. Retrieved June 7, 2009.
Jump up^ "Platforms"

. Retrieved June 7, 2009.
Jump up^ "Debian 5.0 release notes"

. February 14, 2009. Retrieved February 16, 2009. "The package rsyslog takes over as default system and kernel logging daemon for Debian 5.0, replacing syslogd and klogd."
Jump up^ "Release Notes for SUSE Linux Enterprise Server 11 Service Pack 2"

. Retrieved August 3, 2012. "syslog-ng will be replaced with rsyslog"

Protocol[edit]

syslog-ng uses the standard BSD syslog protocol, specified in RFC 3164. As the text of RFC 3164 is an informational description and not a standard, some incompatible extensions of it emerged. Since version 3.0 syslog-ng also supports the syslog protocol specified in proposed-RFC 5424 which was published in 2009 but has not been ratified. syslog-ng interoperates with a variety of devices, and the format of relayed messages can be customized.

Extensions to the original syslog-ng protocol include:

ISO 8601 timestamps with millisecond granularity and timezone information
the addition of the name of relays in additional host fields, to make it possible to track the path of a given message
reliable transport using TCP
TLS encryption (Since 3.0.1 in OSE ^[2])

History[edit]

The syslog-ng project began in 1998, when Balázs Scheidler, the primary author of syslog-ng, ported the existing nsyslogd code to Linux. The 1.0.x branch of syslog-ng was still based on the nsyslogd sources and are available in the syslog-ng source archive.

Right after the release of syslog-ng 1.0.x, a reimplementation of the code base started to address some of the shortcomings of nsyslogd and to address the licensing concerns of Darren Reed, the original nsyslogd author. This reimplementation was named stable in the October 1999 with the release of 1.2.0. This time around, syslog-ng depended on some code originally developed for lsh by Niels Möller.

Three major releases (1.2, 1.4 and 1.6) were using this code base, the last release of the 1.6.x branch in February 2007. In this period of about 8 years, syslog-ng became one of the popular alternative syslog implementations.

In a volunteer based effort, yet another rewrite was started back in 2001, dropping lsh code and using the more widely available GLib library. This rewrite of the codebase took its time, the first stable release of 2.0.0 happened in October 2006.

Development efforts were focused on improving the 2.0.x branch; support for 1.6.x was dropped at the end of 2007. Support for 2.X was dropped at the end of 2009, but it is still used in some Linux distributions.^[3]^[4] Balabit, the company behind syslog-ng, started a parallel, commercial fork of syslog-ng, called syslog-ng Premium Edition. Portions of the commercial income are used to sponsor development of the free version.

Syslog-ng version 3.0 was released in the fourth quarter of 2008.

Starting with the 3.0 version developments efforts were parallel on the Premium and on the Open Source Editions. PE efforts were focused on quality, transport reliability, performance and encrypted log storage. The Open Source Edition efforts focused on improving the flexibility of the core infrastructure to allow more and more different, non-syslog message sources.

Both the OSE & PE forks produced two releases (3.1 and 3.2) in 2010.

Features[edit]

syslog-ng provides a number of features other than transporting syslog messages and storing them to plain text log files:

the ability to format log messages using UNIX shell-like variable expansion (can break cross-platform log format compatibility);
the use of this shell-like variable expansion when naming files, covering multiple destination files with a single statement;
the ability to send log messages to local applications;
ability to message flow-control in network transport;
logging directly into a database (since syslog-ng OSE 2.1);
rewrite portions of the syslog message with set and substitute primitives (since syslog-ng OSE 3.0);
classify incoming log messages and at the same time extract structured information from the unstructured syslog message (since syslog-ng OSE 3.0);
generic name-value support: each message is just a set of name-value pairs, which can be used to store extra information (since syslog-ng OSE 3.0);
the ability to process structured message formats transmitted over syslog, like extract columns from CSV formatted lines (since syslog-ng OSE 3.0);
the ability to correlate multiple incoming messages to form a more complex, correlated event (since syslog-ng OSE 3.2);^[5]

Distributions[edit]

syslog-ng is available on a number of different Linux and Unix distributions. Some install it as the system default, most provide it as a package that replaces the standard syslogd.

Among others:

openSUSE used it as default prior to openSUSE 11.2, and is still available
SLES uses it as default
Debian GNU/Linux used syslogd and klogd prior to 5.0; post-5.0 ("Lenny"), Rsyslog is used^[6]
Gentoo Linux
Fedora used it prior to Fedora 10
Arch Linux
Hewlett-Packard's HP-UX
FreeBSD port
A Cygwin port is available for Microsoft Windows

Portability[edit]

syslog-ng is highly portable to many Unix systems, old and new alike. A list of the currently known to work Unix versions are found below:

Linux on i386, ARM, PowerPC, SPARC and x86-64 CPUs
FreeBSD 7.x - 9.x on i386 and x86-64 CPUs
AIX 5, 6 and 7 on IBM POWER CPUs
HP-UX 11iv1, 11iv2 and 11iv3 on PA-RISC and Itanium CPUs
Solaris 8, 9, 10 on SPARC, x86-64 and i386 CPUs
Tru64 5.1b on Alpha CPUs

The list above is based on BalaBit's current first hand experience, other platforms may also work, but your mileage may vary.

Related RFCs & working groups[edit]

RFC 3164 - The BSD syslog protocol
RFC 5424 - The Syslog Protocol
RFC 5425 - Transport Layer Security (TLS) Transport Mapping for Syslog
RFC 5426 - Transmission of Syslog Messages over UDP