Although Unix was originally developed to be a programmer's operating system and not a business production system, it has been enhanced over the years to include utilities that can track resource usage and access. Today, the various implementations of Unix (along with its cousin Linux) are the primary operating systems used on the Internet for most firewalls and Web servers in the high-end market. The files discussed here might vary from one Unix/Linux system to the next , but in general most systems have these available for the system administrator's use. The syslog utility covers the widest area of system resources because you can configure it to record messages from many different system utilities, and you can also decide how the utility will notify you of events as they happen. Other files ”such as /etc/utmp and /usr/adm/wtmp ”keep track of who is currently logged on to the system and who has logged on to the system in the past. This is an example of Unix and Linux storing files in different locations. For Linux, the files would be /var/run/utmp and /var/log/wtmp . Understanding each utility or log file and the type of information you can derive from it will enable you to set up a good auditing policy for your systems. Using syslogThe syslog utility can be used to set up logging for many components that make up the Unix operating system. You can set up message logging so that messages from a wide variety of programs can be managed from a central location. To enable syslog logging, you must edit the /etc/syslog.conf configuration file and enter a record that contains a selector for each type of message you want to be logged by the facility, as well as an action, which is the action the daemon should take for this type of message. The syslog daemon ( syslogd ) is usually started when the system boots, by commands placed in one of the rc startup files. This is the syntax for starting the daemon: /etc/syslog [-mN] [-f filename ] [-d] The -f option can be used to specify a configuration file other than the standard /etc/syslog.conf file. The -m option sets a "mark" interval for placing timestamps into the file. Timestamps can be important because they indicate that the logging mechanism is working during periods when no other significant events are logged. The absence of timestamps (if you use them) can be a tip that someone has been tampering with your system. The -d option turns on debugging mode. The syslog.conf FileThe syslog.conf file stores the information that the syslog daemon uses to decide which messages to accept (source and severity) and what to do with them (log file, notify user , and so on). You can use any ASCII text editor (such as VI) to configure this file. Each line should be composed of two components:
Table 47.1 lists the facility names you can use when composing the selector portion of the record. Table 47.1. Facility Names in the syslog.conf Configuration File
Table 47.2 lists the severity levels you can use as the second component for the selector. Table 47.2. Severity Levels in the syslog.conf File
Note that another severity level, called panic , has been removed in later versions of Unix/Linux ”it's the same functionality provided by emerg . At this time the error and warn severity levels are also considered to be deprecated, which means that although they work now, they will be removed in future versions. To create a selector, select one of the facilities listed in Table 47.1 and combine it with one of the error conditions listed in Table 47.2. For example: kernel.info mail.notice lpr.crit To create the rest of the record, you need to specify an action to take. The action portion of the record is separated from the selector portion by a space character. The syslog daemon can deliver the message in these ways:
For example, because kernel events are usually important (the kernel is the heart of the Unix operating system) and need to be looked at immediately, you might want to send them to the computer's console device. To do this, use the following entry: kern.* /dev/console The asterisk tells syslog to log all message types generated by the kernel, and the /dev/console part of the record specifies the console device (check the documentation to be sure of the exact device filename). If the message is something important, but not so critical that it needs immediate attention, you can send it to a user whose responsibilities are associated with the application. The following example sends all messages from the mail facility (at a severity level of info or above) to the mail administrator named Johnson: mail.info johnson For security reasons, you might want to send important logging messages to another host. This can be a valuable service that the syslog daemon can perform. For example, when you are using bastion hosts in a demilitarized zone (DMZ), it's best not to store security logging events on a host computer that might be compromised. Instead, you instruct the daemon to send these events to another server for logging purposes. In a large network, you can dedicate a single host computer to this function and use other security measures to make the computer inaccessible to ordinary users. To send messages relating to kernel events and authorization events to another computer, for example, you might use this: kern.*;auth.* @yoko.ono.com You'll find more detailed information about bastion hosts, firewalls, and DMZs in Chapter 49, "Firewalls." Some message types are more useful for reviewing at a later date to review the overall functioning of the system. Using log files for these kinds of messages is a good idea. To send messages to a log file, specify the log file path in the action field: mail.info;lpr.info;news.* /var/adm/messages
When sending syslog messages to a file, don't forget to review the log files periodically. Depending on the severity level you set for each facility, these files can grow to be quite large over a short period. To make administration more efficient, decide on a policy for reviewing, archiving, and deleting log files on a regular basis. You should keep these files available for at least a year. Some intrusions can lie in wait for a trigger before causing your system a problem. If you keep your log files on tape or other offline storage, you can look back through them for what might not have seemed an obvious event when it originally occurred. For legal reasons, keeping log files archived and readily available can help you make your case against an intruder who has spent days, weeks, or months trying to compromise your system. System Log FilesUnix systems have many log files not related to the syslog utility that you can review for security purposes. For example, user logins are recorded in a file, as are usages of the switch user ( su ) command. When you are new to a system, you should review the documentation to make sure you are aware of all the logging facilities on the computer, where the files are located, and what maintenance procedures are necessary. Some of the more useful files are listed here:
|