wiki Syslog

Syslog

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Syslog is a standard for computer data logging. It allows 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 refer to a facility (auth, authpriv, daemon, cron, ftp, lpr, kern, mail, news, syslog, user, uucp, local0, ... , local7 ) and are assigned a severity (Emergency, Alert, Critical, Error, Warning, Notice, Info or Debug) by the sender of the message.

Configuration allows directing messages to various local devices (console), files (/var/log/) or remote syslog daemons. Care must be taken when updating the configuration as omitting or misdirecting message facilities or severities can cause important messages to be ignored by syslog or overlooked by the administrator.

logger is a command line utility 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.

[edit] History

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. Since then, additions to syslog have been worked on. RFC 3164 was made obsolete by RFC 5424^[1]

At different points in time, various companies have attempted patent claims on syslog.^[2][3] This has had little effect on the use and standardization of the protocol.

[edit] Outlook

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.

[edit] Facility Levels

The list of Facilities available:^[4]

Facility Number	Facility Description
0	kernel messages
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
11	FTP daemon
12	NTP subsystem
13	log audit
14	log alert
15	clock daemon
16	local use 0 (local0)
17	local use 1 (local1)
18	local use 2 (local2)
19	local use 3 (local3)
20	local use 4 (local4)
21	local use 5 (local5)
22	local use 6 (local6)
23	local use 7 (local7)

[edit] Severity levels

Severity levels are defined by RFC 5424

Code	Severity	RFC 5424 Description	General Description
0	Emergency	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	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 backup ISP connection.
2	Critical	Critical conditions.	Should be corrected immediately, but indicates failure in a primary system, an example is a loss of primary ISP connection.
3	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 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	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	Informational messages.	Normal operational messages - may be harvested for reporting, measuring throughput, etc - no action required.
7	Debug	Debug-level messages.	Info useful to developers for debugging the application, not useful during operations.