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 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 indicating the type of software that generated
the messages, and are assigned a severity.
Implementations are available for many operating systems.
Specific configuration may permit directing messages to various devices, files 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.
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.
It was made obsolete by subsequent additions in RFC 5424.
At different points in time, various companies have attempted patent claims on syslog.
This had little effect on the use and standardization of the protocol.
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 to detect patterns and alert customers to problems.
Facility levels 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.
The list of facilities available: The mapping between Facility Number and Keyword
is not uniform over different operating systems and different syslog implementations.
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 RFC 5424 defines eight severity levels:
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 The full format of a Syslog message seen on
the wire has three distinct parts:
HEADER MSG
The total length of the packet cannot exceed 1,024 bytes, and there is no minimum length.
Priority 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 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 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 with a Severity of Emergency would have a Priority value of
0.
Also, a "local use 4" message with a Severity of Notice 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.
Calculating Facility and Severity Values from a Priority Value
This is a calculation derived from the previous one.
To get the Facility number implied in a given Priority value, divide the Priority number
by 8.
The whole number part is the Facility.
To get the Severity, multiply the Facility by 8 and subtract that number from the Priority.
For example: Priority = 191
191/8 = 23.875 Facility = 23
Severity = 191 - = 7 Work backword to check the formula: 23*8 = 184
+ 7 = 191 Header
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 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 The UDP based Syslog protocol is unreliable.
Unlike TCP based transmission of messages, UDP 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 Syslog is a client/server protocol: a logging
application transmits a text message to the syslog receiver.
The receiver is commonly called syslogd, syslog daemon or syslog server.
Syslog messages may be sent via the User Datagram Protocol or the Transmission Control Protocol.
The data is sent in cleartext; 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 The Syslog protocol is defined by Request
for Comments documents published by the Internet Engineering Task Force.
The following is a list of RFCs that define the Syslog protocol:
RFC 3164 The BSD syslog Protocol 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 Transport Mapping for Syslog
RFC 6587 Transmission of Syslog Messages over TCP
See also
References
External links IETF syslog working group
SANS Paper The Ins and Outs of System Logging Using Syslog
NIST SP 800-92 Guide to Computer Security Log Management
NetLogger methodology and tools for debugging and analysis of complex distributed applications