|
By Corey Nachreiner, Network Security Analyst, WatchGuard Technologies In "Syslog Basics: Affordable Centralized Logging," you learned about syslog, its benefits and weaknesses, and how to read its log entries. If that piqued your interest, now you probably want to know how to set up syslog. This article offers a quick primer on configuring and running the syslog service (syslogd) on a Linux server. In a future article, I'll also explain how to configure your Firebox to use syslog. Syslog: Native to *Nix Although you can install syslog on almost any computer platform, this article describes installing the BSD flavor of syslog on a Linux server. This article assumes the reader has a basic understanding of how to get around on Linux and how to use its file system. Windows users shouldn't feel left out. You can download third party applications, such as the Kiwi Syslog Daemon, to provide syslog services in Windows. The core syslog concepts discussed in this article still apply. For more on running syslog in Windows, I recommend SANS' whitepaper on implementing syslog in a mixed environment. You'll find more resources at the end of this article. What can you configure? In a nutshell, configuring syslog means deciding how you'd like to handle various log messages, based on their origin and importance. For instance, you could send all email-related logs to a specific file. You could divert all user login messages to an obscure directory. You could even have all critical log messages pop up, immediately, onto your screen. This powerful flexibility is partly why geeks love syslog! So how does syslog define a message's origin and importance? According to the syslog RFC, anything that sends syslog messages must assign each message a Facility and a Severity value. The Facility value shows the message's origin. It tells you which daemon, process or operating system (OS) component sent the message. The syslog protocol defines 24 possible Facility values. Different implementations of syslog sometimes refer to these values using different names. However, they always correlate back to the original 24 values defined in the syslog RFC. The following table describes some commonly-used Linux Facility values and their meaning. | This Facility... | Means the message is from ... | | kern | The kernel | | user | Applications or user processes
(It's also the default setting when Facility is undefined) | | mail | Mail systems, such as your mail server | | ftp | File Transfer Protocol (FTP) services | | news | The NNTP service | | uucp | The Unix-to-Unix Copy Protocol (UUCP) service | | cron | Scheduler daemons | | ntp | The Network Time Protocol (NTP) service | | console | In this case, not from; typically sent to the system console | | daemon | Generic system or network daemons | | auth | Authentication-related (login) systems | | authpriv | Logged-in, privilege restricted file
In other respects, similar to auth | | security | Security systems | | lpr | The printing subsystem | | syslog | The syslog service itself | | mark | This one is also not from anything. This Facility is a syslog-inserted timestamp. | | local0 - local7 | These eight generic values provide customizable Facilities |
The Severity value describes a message's importance. Some syslog implementations refer to this value as the message's Priority. Whether you call it Severity or Priority, the syslog protocol defines the following eight values, listed below from least to greatest severity: | Severity | Description | | debug | Low-priority message typically used for troubleshooting | | info | Informational messages | | notice | Normal condition that may require attention | | warning | Warning message, usually resulting from a recoverable error | | err | Error condition | | crit | Critical condition, possibly a hardware problem | | alert | Condition that requires immediate attention | | emerg | Emergency condition of the highest priority |
Together, Facility and Severity describe the origin and importance of each syslog message your server receives. By setting rules based on a message's Facility and Severity, you can tell your syslog server to handle each message according to its importance to you. So let's move on to the actual syslog configuration in Linux. Configuring Syslog:
One File to Control Them All Syslog comes pre-installed on most Linux distributions (distros, for short). If you have a Linux machine, it probably already uses syslog for its local logs. If you tweak its pre-configured settings, it handles messages the way you like. To do this, you need to know a little about the typical syslog installation, which consists of: - syslog.conf. The configuration file that tells syslog how to handle log messages
- syslogd. The actual syslog daemon
- logger. A command line application used to send custom log messages. (This app is useful when creating custom scripts with logging capabilities.)
Your entire syslog configuration process takes place in one file, syslog.conf. This file lists instructions telling your syslog server how to handle log messages based on their Facility and Severity values. Once you've decided what to do with each type of log message, simply add the corresponding instructions to your syslog.conf file. Here's how. Open syslog.conf in your favorite text editor. You'll typically find syslog.conf in the /etc/ directory, as follows: /etc/syslog.conf When you edit syslog.conf, you might see lines beginning with the # character. These are comments left by the developers. Your syslog server ignores these lines, as they are information for you, not instructions for syslog. The actual instruction in syslog.conf looks like this example: mail.emerg <Tab><Tab> /var/log/maillog Interpreting this message (and any other) requires knowledge of this very simple message format: [Facility].[Severity] <Tab><Tab> [Action] We've looked at Facility and Severity already. A real message fills these fields with values from the tables above. <Tab> represents white space. In syslog.conf, you create white space using the Tab button rather than the space bar. The Action part of this instruction tells syslog how to handle any messages that have the specified Facility, and having a Severity equal to or higher than the one listed. Actions include: - Send the message to a specified device (such as the console, which is /dev/console in Linux)
- Write the message to a specified file (you can use any file name you like)
- Forward the message to a network host (specified after an @ symbol)
- Send the message to one or more specified usernames
- Send the message to everyone
Let's parse a real example to understand this format better: mail.emerg <Tab><Tab> /var/log/maillog This instruction tells syslog that if any message comes from the "mail" Facility and has a Severity of "emerg,"syslog should write it to a file called /var/log/maillog. This example shows a simple instruction. You can write even more complex instructions using some of the special operators syslog.conf offers. To learn more about writing complex instructions, see this Table of Operators. Once you've added your custom instructions to syslog.conf, just save the file and continue. Start the service and log away With syslog.conf configured, simply start (or restart) the syslogd service so that it can receive and act upon your logs. How you start syslogd differs depending on your Linux distro. The "Quick Start" section of this syslog overview shows how to start syslogd in three different *nix distros. In the most common Linux method, you'd type the following at a command prompt. /etc/rc.d/init.d/syslog restart This command should return a message saying that the syslog service started. You can test whether or not it works using the logger application, by manually sending a test. The following command sends a test message to your syslog server that appears to come from the "mail" Facility, and has a Severity of "warning" or higher. The message also gets tagged as coming from an application called "MailApp." To try the test message, type the following at a command prompt. (This example shows where logger is on my machine; yours might use a different path to logger.) /usr/bin/logger -p mail.warning -t MailApp "testing 123" Once you execute that command, you should find a corresponding log message in the proper location. Where? That depends on how you configured syslog.conf to handle that type of message (mail.warning). If you find the log in the expected place, congratulations! You have syslog configured and running. You've learned how to fish Remember the crusty-but-true saying, "Give a man a fish, you've fed him for a day; teach a man to fish, you've fed him for a lifetime"? You've just learned how to fish the waters of syslog. But this primer merely scratches the surface of syslog configuration. Becoming a bassmaster is now up to you. To learn about other syslog topics, browse the links provided below. If you've tracked with me so far, you'll find that very little further effort enables you to pull off some syslog tricks that will make you feel like the Lord of Logging. Experiment and have fun! Later, I'll meet you back here to discuss the tie-in between syslog and your Firebox. ## Syslog Links for Windows users Syslog Configuration Links
Related Items:
|
Read All of Our Hot News Items 
