What is Syslog? An Introduction to the System Logging Protocol

You may have seen the term "Syslog" bandied about, and it may register to you as one of those tech words you probably don't need to understand. But it's actually extremely useful to learn about it, so we've put together this introductory guide to the "System Logging Protocol," also known as Syslog.

As its name suggests it is used for devices such as routers, switches, firewalls, Wi-Fi access points and Linux servers to generate their own logs. Windows servers use Event Logs but they can be used in conjunction with Syslog servers. Its function is to store events or log messages locally inside of the device of choice and promptly send the Event or Log Information to a Syslog Server in order to get, sort, and filter all the logs and data therein. 

In simple terms, a network device or server that is already in a company’s network can be configured in such a way that allows it generate Syslog messages and then forward them to a Syslog server or Daemon. What this does is allow network administrator to monitor and accurately track the devices hooked up to the network, and properly asses issues or problems that they might need to fix whenever they show up in the logs. 

After that, a message is sent from the initial device to the server (also referred to as collector) using UDP, which is protocol that does not require connection. For the sake of swiftness and easy understanding, these messages are sent as short texts that don’t go over the 1024 byte threshold.

However, since UDP is used to send the message, the originator doesn’t get any kind of receipt of transmission or arrival. This means that packets could potentially get lost during the transmission forever. 

This complication can be easily circumvented by using a server (or Daemon) to collect, sort, classify and setup alert for events and their location inside of the network 

A Server/Daemon allows you to collect, filter, organize, setup alerts for certain events from one location within your network. Thus, having tools such as Syslog and its log of information data gives businesses the possibility of elaborating reports, diagrams and charts to accurately visualize elements and aspects of systems and get better IT infrastructure visualization. 

When is Syslog used? 

Perhaps the biggest question for people who are used to using SNMP might be “What’s the use of Syslog if SNMP traps are already a thing and they have similar functionality?” There is some truth to this, since they are both used to send alerts and messages to central servers without the need of polls. Just as an event happens, messages are sent without having to wait for servers to poll them for status. 

However there is a pretty big difference and it’s that SNMP traps have special predefined formats contained in a MIB file. In the occurrence that an interface on a switch goes down, the MIB file instantaneously defines an “ifDown” trap message that communicates important information that includes but is not limited to things such as the specific interface that went down, for example. This provides the software users to know in advance what info the message will have have in its content. However, this is not always the case.

SNMP traps are best suited for events that are well defined, such as interface resets or some very specific devices hooked up to the network. Syslog events, on the other hand, are much better for events that are, by nature, broader and more general in scope, and thus harder to predict.

However, while he broad nature of syslog messages is a huge advantage, it can also be a great hinderance. It can be quite challenging to parse through impossibly long and numerous events in logs from so many different systems from various vendors and simultaneously make sense of all of them. How can one know which messages represent certain functions? Which ones are about just informational messages and which ones are critical events that must be tended to immediately? 

To deal with these questions, the Syslog protocol (which is defined in RFC 5424) provides these free-form messages with special fields called “facility” and “severity,” which have their own codes of identification for easier parsing. 

Facility and Severity codes

The severity value is pretty straightforward: a single number somewhere between 0 and 7 shows the level of importance a message has. 

Facility codes need a little bit more detailed explanation. In its early days, the implementation of syslog server software usually just put tall the incoming messages into one or more log files. The server system fetched the facility code to sort the pertinent messages into the same file.

Nowadays, more modern implementations dump all messages into a shared common database and facility codes work as search keys. Additionally, facility codes are expressed with numerical values similarly to severity codes.

How is Syslog transported?

The two most used ways of porting syslog messages are through an encrypted TSL network transport over TCP or the more old-fashioned UDP method. 

UDP method

When using the UDP method, messages are put into the data portion of a UDP packet and sent directly to the server through UDP port 514. Every single message generally fits into a single packet. UDP is stateless and sessionless, thus no acknowledgment is provided and packets are simply relayed and sent into the network.

The most evident issue with this method is that any kind of hiccup with the network could potentially prevent the packet from getting delivered, and you might never know that the network is down (because there’s no way for the message to be acknowledged and relayed back to whomever sent the message in the first place). Consequently, crucial packets risk the chance of getting damaged or straight up lost in transit. 

Another aspect of UDP Syslog transport to keep in mind is that it is not encrypted. This is a risk for digital workplace security. Ergo, packets could be easily intercepted and even forged. So, unless UDP Syslog packets are sent with the protection of an encrypted VPN, using them through public internet infrastructures is discouraged. 

TCP method

This method differs in that it’s both encrypted and session-based. Plus, this version of Syslog transport uses TLS security. TCP Syslog Port 6514 is used in this case and it has got the same type of authentication certificates as HTTPS. 

Since TCP has a session-based process, devices connected remotely will just open a TCP session connected with the server and usually keep it active as the queued messages are delivered. An example of this could be firewalls, which have a regular influx of syslog messages coming in at all times. As a consequence, uninterrupted  connection is needed. 

Using TCP over UDP has many advantages. One of them is that since sessions are encrypted, it’s virtually impossible to read them as they're being sent. Also, since every device has a unique certificate, the server can authenticate that the devices have not been victims of forging or that they haven’t been hijacked.

Last but not least, TCP-based sessions mean that delivery of each message is completely guaranteed, and even if they are lost or damaged in transit, they can be retransmitted without compromising the message. 

Frequently asked questions

What is Syslog?

Syslog is a standard for message logging. It allows separation of the software that generates messages, the system that stores them, and the software that reports and analyzes them. Each message is labeled with a facility code, indicating the type of system generating the message, and is assigned a severity level.

How do you perform a Syslog port? 

A syslog server either opens port 514 (UDP method) or port 6514 (TCP method) and listens for incoming syslog event notifications  generated by remote syslog clients.