Syslog is a way for network devices to send event messages to a logging server – usually known as a Syslog server. The Syslog protocol is supported by a wide range of devices and can be used to log different types of events. For example, a router might send messages about users logging on to console sessions, while a web-server might log access-denied events.
Most network equipment, like routers and switches, can send Syslog messages. Not only that, but *nix servers also have the ability to generate Syslog data, as do most firewalls, some printers, and even web-servers like Apache. Windows-based servers don’t support Syslog natively, but a large number of third-party tools make it easy to collect Windows Event Log or IIS data and forward it to a Syslog server.
Unlike SNMP, Syslog can’t be used to “poll” devices to gather information. For example, SNMP has a complex hierarchical structure that allows a management station to ask a device for information on things like temperature data or available disk space. That’s not possible with Syslog – it simply sends messages to a central location when specific events are triggered.
Syslog is a great way to consolidate logs from multiple sources into a single location. Typically, most Syslog servers have a couple of components that make this possible.
- A Syslog listener: A Syslog server needs to receive messages sent over the network. A listener process gathers syslog data sent over UDP port 514. UDP messages aren’t acknowledged or guaranteed to arrive, so be aware that some network devices will send Syslog data via TCP 1468 to ensure message delivery.
- A database: Large networks can generate a huge amount of Syslog data. Good Syslog servers will use a database to store syslog data for quick retrieval.
- Management and filtering software: Because of the potential for large amounts of data, it can be cumbersome to find specific log entries when needed. The solution is to use a syslog server that both automates part of the work, and makes it easy to filter and view important log messages. Syslog servers should be able to generate alerts, notifications, and alarms in response to select messages – so that administrators know as soon as a problem occurs and can take swift action!
We won’t go in depth on Syslog messages here, but there are a few important things to know.
Syslog messages usually include information to help identify basic information about where, when, and why the log was sent: ip address, timestamp, and the actual log message. Messages are sometimes in a descriptive, human-readable format – but not always!
Syslog uses a concept called “facility” to identify the source of a message on any given machine. For example, a facility of “0” would be a Kernel message, and a facility of “11” would be an FTP message. This dates back to Syslog’s UNIX roots. Most Cisco network equipment uses the “Local6” or “Local7”facility codes.
Syslog messages also have a severity level field. The severity level indicates how important the message is deemed to be. A severity of “0” is an emergency, “1” is an alert that needs immediate action, and the scale continues right down to “6” and “7” – informational and debug messages.
The Downsides to Syslog
There are a few downsides to Syslog.
First, the problem of consistency. The Syslog protocol doesn’t define a standard way for message content to be formatted – and there as many ways to format a message as there are developers. Some messages may be human readable, some aren’t. Syslog doesn’t care – it just provides a way to transport the message.
There are also some problems that arise because of the way syslog uses UDP as a transport. UDP is connectionless and not guaranteed – so it could be possible to lose log messages due to network congestion or packet loss.
Finally, there are some security challenges with syslog. There is no authentication on syslog messages, so it could be possible for one machine to impersonate another machine and send bogus log events. It is also susceptible to replay attacks.
In spite of this, many administrators find that the syslog is a valuable tool, and that the downsides are relatively minor.
As you can see, Syslog can be a powerful tool that can make it easier for administrators to manage complex networks. But one of the biggest challenges with Syslog is the volume of data. The logging server software must simplify log management, and help admins filter and focus on messages that truly matter. In a future post, we’ll show you some tools that you can use to get the most out of the Syslog.