215
To do remote logging, you will need to make appropriate entries in the configuration files for two systems. On the system generating the message, youll need to specify the address of the remote
logging machine. On the system receiving the message, youll need to specify a file for the messages. Consider the case in which the source machine is bsd1 and the destination is bsd2. In the configuration
file for bsd1, you might have an entry like:
local7. bsd2.netlab.lander.edu
bsd2 s configuration file might have an entry like:
local7. varlogbsd1
Naming the file for the remote system makes it much easier to keep messages straight. Of course, youll need to create the file and enable bsd2 to receive remote messages from bsd1.
You can use the logger command to test your configuration. For example, you might use the following to generate a message:
bsd1 logger -p local7.debug testing
This is what the file looks like on bsd2:
bsd2 cat bsd1 Dec 26 14:22:08 bsd1 jsloan: testing
Notice that both a timestamp and the source of the message have been included in the file. There are a number of problems with remote logging. You should be aware that syslog uses UDP. If
the remote host is down, the messages will be lost. You will need to make sure that your firewalls pass appropriate syslog traffic. syslog messages are in clear text, so they can be captured and read. Also, it
is very easy to forge a syslog message.
It is also possible to overwhelm a host with syslog messages. For this reason, some versions of syslog provide options to control whether information from a remote system is allowed. For example, with
FreeBSD the -s option can be used to enter secure mode so logging requests are ignored. Alternately, the -a option can be used to control hosts from which messages are accepted. With some versions of
Linux, the -r option is used to enable a system to receive messages over the network. While you will need to enable your central logging systems to receive messages, you should probably disable this on
all other systems to avoid potential denial-of-service attacks. Be sure to consult the manpage for syslogd to find the particulars for your system.
Both Linux and FreeBSD have other enhancements that you may want to consider. If security is a major concern, you may want to investigate secure syslog ssyslog or modular syslog msyslog. For
greater functionality, you may also want to look at syslog-ng.
11.2.2 Log File Management
Even after you have the log files, whether created by syslog or some other program, you will face a number of problems. The first is keeping track of all the files so they dont fill your filesystem. It is
easy to forget fast-growing files, so I recommend keeping a master list for each system. Youll want to develop a policy of what information to keep and how long to keep it. This usually comes down to
216
some kind of log file rotation system in which older files are discarded or put on archival media. Be aware that what you save and for how long may have legal implications, depending on the nature of
your organization.
Another issue is deciding how much information you want to record in the first place. Many authors argue, with some justification, that you should record anything and everything that you might want, no
matter how remote the possibility. In other words, it is better to record too much than to discover, after the fact, that you dont have something you need. Of course, if you start with this approach, you can
cut back as you gain experience.
The problem with this approach is that you are likely to be so overwhelmed with data that you wont be able to find what you need. syslog goes a long way toward addressing this problem with its support
for different security levels—you can send important messages one place and everything else somewhere else. Several utilities are designed to further simplify and automate this process, each with
its own set of strengths. These utilities may condense or display log files, often in real time. They can be particularly useful if you are managing a number of devices.
Todd Atkins swatch simple watcher is one of the best known. Designed with security monitoring in mind, the program is really suitable to monitor general system activity. swatch can be run in three
different ways—making a pass over a log file, monitoring messages as they are appended to a log file, or examining the output from a program. You might scan a log file initially to come up-to-date on
your system, but the second usage is the most common.
swatchs actions include ignoring the line, echoing the line on the controlling terminal, ringing the bell, sending the message to someone by write or mail, or executing a command using the line as an
argument. Behavior is determined based on a configuration file composed of up to four tab-separated fields. The first and second fields, the pattern expression and actions, are the most interesting. The
pattern is a regular expression used to match messages. swatch is written in Perl, so the syntax used for the regular expressions is fairly straightforward.
While it is a powerful program, you are pretty much on your own in setting up the configuration files. Deciding what you will want to monitor is a nontrivial task that will depend on what you think is
important. Since this could be almost anything—errors, full disks, security problems such as privilege violations—youll have a lot of choices if you select swatch. The steps are to decide what is of interest,
identify the appropriate files, and then design your filters.
swatch is not unique. xlogmaster is a GTK+ based program for monitoring log files, devices, and status-gathering programs. It was written by Georg Greve and is available under the GNU General
Public License. It provides filtering and displays selected events with color and audio. Although xlogmaster is no longer being developed, it is a viable program that you should consider. Its successor
is GNU AWACS. AWACS is new code, currently under development, that expands on the capabilities of xlogmaster.
Another program worth looking at is logcheck. This began as a shell script written by Craig Rowland. logcheck is now available under the GNU license from Psionic Software, Inc., a company founded by
Rowland. logcheck can be run by cron rather than continuously.
You should be able to find a detailed discussion of log file management in any good book on Unix system administration. Be sure to consult
Appendix B for more information.
11.2.3 Other Approaches to Logging
