How to configure and verify syslog

Certification: Cisco CCNA Routing and Switching - Cisco Certified Network Associate Routing and Switching

Who hasn’t heard of syslog? Probably no one, yet who actually knows what it is for, and what it does? Most people can figure out its some kind of auto-logging feature of software, which reports its usage data and stats at different intervals to make debugging easier. However, they also don’t usually know that it allows the separation of the message-generating software from the others that either store or analyzes them. Besides showing general information, statistics and debugging messages, the syslog can also be used for security auditing. Also, most people don’t know that there is a syslog for a wide variety of devices, including routers and printers beside the computer. The syslog can function as a great log for a multitude of different devices. Each syslog line is assigned a severity, to better help developers/technicians and so on to better asses the situation. The severity ratings range from Info and Debug lines to Alert and Critical lines. You can send messages to the syslog via the logger utility command line. The syslog is a standardized protocol as of RFC 5424.

First created in the 80s by Eric Allman, at first solely for a general purpose email routing facility, the syslog has since skyrocketed in popularity, and is now basically on everything, especially in routers. Its popularity is due primarily because it functioned as a de facto standard. It was the first of its kind, and because there was no competition, syslog became all-present. Although some companies have attempted to take sole credit for the syslog, they all failed and remained stuck in the mud. There are also some groups that wish to introduce syslog in other areas of expertise, especially medical and health care.

Syslog has proven time and time again to be the most effective logging tool, with numerous open source codes and proprietary tools, and converters from other logging protocols/programs.

Syslog in networking

Although Syslog is regulated by the RFC standards, it is still UDP based, and as such it does not guarantee message delivery. They are prone to interception, for example, and they do not assure you that the packets will be delivered in order. Network congestion, or the otherwise overloading of a link may also cause corruption or otherwise inhibit the transmission of the syslogs to the syslog server or syslogd.

The protocol is not in charge with any formatting, or content-check of the information it sends, it just sends it. As such there isn’t that much uniformity in the messages it sends, nor is there any authentication of the sender. Bad configuration of a device may result in error-prone or misleading information sent about the specified hardware to the Syslog daemon. Hackers may also exploit the lack of authentication features of the syslog and mislead technicians with false errors or problems on machines, using it as a distraction to attack or compromise sister/neighbor machines. The hacker can also emulate normal behavior of a device, and then proceed to reconfigure or otherwise remove it completely form the network. The data itself is send via UDP or TCP and by cleartext format. To combat some hacker attacks, the data can be encrypted using a SSL wrapper.

Configuration: how to

The first thing you will want to do when it comes to configuration, is to see who is your system logger. Usually a syslogger is syslogd. You need it to manage your logging. It is started by default at boot. You can disable this feature if you want, but that would be counter-productive. Most config changes are done with the syslogd_flags located in /etc/rc.conf or /etc/syslog.conf. For example, you can enable the boot start as syslogd_enable. You can find most of these commands in syslogd(8).

The configurations file is the syslog.conf (the name might’ve been the giveaway factor) and it controls what the syslogd does whit the messages/entries it receives from connected devices. You can configure which subsystem configures and displays which, and also the level.

The syntax for each configuration line is a sole line, made up from a selector field, and an action field. More than one selector fields can be introduced, but must be separated by a semicolon (“;”); “ * “ will match everything. The syntax for the selector field is something along the lines of exfacility.exlevel. This will match the logs from the exfacility at the exlevel level (like Critical/Alert/etc…) the action field demands an action to be executed.

For ease of access and stocking of message logs, they are generally managed, compressed at a default one hour rotation. Managed logs are easy to find and take up less space. However you can configure most aspects of the log manager from newsyslog.conf, its config file.

File administration can also be eased by configuring centralized logging for the log files from multiple hosts. This type of logging can be configured from the above-mentioned syslog configuration files, and are useful for easing administration work on massive networks.

The log server itself can be configured from its file syslog.conf, adding names of multiple clients from which it can receive logs from (syslogd_flags="-a logclient.example.com -v -v"). Note that a log file should also be created then. A log client can be configured from the rc.conf file.

When you are done with the configurations remember the old saying, “better safe than sorry”. Check for errors. Debug and verify that all configured components work and do as expected. Make sure everything can ping what it needs to ping without fault, and verify the first few logs that come up on the system logger.

For examples and other facts and configuration needs you can visit this free handbook at this site.

Related IT Guides