Syslog is an IETF RFC 5424 standard protocol for computer logging and collection that is popular in Unix-like systems including servers, networking equipment and IoT devices. The log messages generated by a device creates a record of events that occur on the operating system or application. The purpose of the message is to provide administrators with information regarding important events, health information and other normal or abnormal happenings that could prove useful when troubleshooting or working through a security-related issue.
How does syslog work?
When an originating device is running the syslog daemon, device messages are generated during normal and abnormal operation based on what the application developers deemed as potentially useful. These messages can then be viewed in several forms. The first is to monitor the messages in real time on the originating device's console itself. Another method is to view the local log files that contain historical log information.
While the local log file is a quick way to view historical message events, note that on many systems, the local file has a maximum limitation on the number of log messages stored. Once that limit is reached, the oldest messages are overwritten with the newest. That means that the local file only contains the most recent logs.
However, it is often the case that administrators require looking at logs much further back in time. Thus, it is routine to use the third method of viewing logs which is to relay all logs across a network to a centralized log collection server.
The relaying of syslog messages are commonly sent over UDP port 514 or TCP 6514. The TCP method also offers the benefit of the Transport Layer Security (TLS) protocol to keep messages private. Once collected, an administrator can use a syslog viewer to view, sort and even alert on the various log messages coming in.
Syslog message components
Each log event contains a timestamp along with the event message itself and the origin IP/domain name for identification purposes. The event is then categorized into one of eight severity levels. These levels are based on the criticality of the event according to the developer of the operating system or application in use. Each category is defined with both a numerical value and a severity name. The lower the value, the more severe the event. The scale goes from 0-7 starting with emergency and ending with debug. The different severity names, in order, are emergency, alert, critical, error, warning, notice, informational and debug.
When creating the log event, the originating device further segments the message into a logging facility code. This code categorizes messages based on which process within the overall application the message was generated. Much like the severity categorizations, the facilities are defined using a numerical value and a name. Facilities can be categorized into one of 24 different facility codes.