21.4 Designing a Site-Wide Log Policy

This section provides suggestions for designing a comprehensive log policy for use at your own site.

21.4.1 Where to Log

Because the syslog facility provides many different logging options, this gives individual sites flexibility in setting up their own logging. Different kinds of messages can be handled in different ways. For example, most users won't want to be bothered with most log messages. On the other hand, auth.crit messages should be displayed on the system administrator's screen (in addition to being recorded in a file). This section describes a few different approaches.

21.4.1.1 Logging to a printer

If you have a printer you wish to devote to system logging, you can connect it to a terminal port and specify that port name in the /etc/syslog.conf file.

For example, you might connect a special-purpose printer to the port /dev/ttya. You can then log all messages from the authorization system (such as invalid passwords) by inserting the following line in your syslog.conf file:

auth.*                 /dev/ttya

A printer connected in such a way should only be used for logging. We suggest using progressive display printers (e.g., dot-matrix printers), if possible, rather than laser printers, because progressive display printers allow you to view the log line by line as it is written, rather than waiting until an entire page is completed.

Logging to a hardcopy device is a very good idea if you think that your system is being visited by unwelcome intruders on a regular basis. The intruders can erase log files, but after something is sent to a printer, they cannot touch the printer output without physically breaking into your establishment.^[15]

^[15] Although if they have superuser access, they can temporarily stop logging or change what is logged.

Be sure that you do not log solely to a hardcopy device. Otherwise, you will lose valuable information if the printer jams or runs out of paper, the ribbon breaks, or somebody steals the paper printout.

21.4.1.2 Logging across the network

If you have several machines connected by a TCP/IP network, you may wish to have events from all of the machines logged on one (or more) log machines. If this machine is secure, the result will be a log file that can't be altered, even if the security on the other machines is compromised. To send all of the messages from one computer to another computer, simply insert this line in the first computer's syslog.conf file:

*.*               @loghost

This feature can cause a lot of network traffic. Instead, you should limit your log to only "important" messages. For example, this log file would simply send the hardware- and security-related messages to the remote logging hosts, but keep some copies on the local host for debugging purposes:

*.err;kern.debug;auth.notice /dev/console
daemon,auth.notice           /var/adm/messages
lpr.*                        @loghost1,@loghost2
auth.*                       @loghost1,@loghost2
*.emerg                      @loghost1,@loghost2
*.alert                      @loghost1,@loghost2
mark.*                       /dev/console

Logging to another host adds to your overall system security: even if people break into one computer and erase its log files, they will still have to deal with the log messages sent across the network to the other system. If you do log to a remote host, you might wish to restrict user accounts on that machine. However, be careful: if you only log over the network to a single host, then that one host is a single point of failure. The previous example logs to both loghost1 and loghost2.

Another alternative is to use a non-Unix machine as the log host. The syslog code can be compiled on other machines with standard C and TCP/IP libraries. Thus, you can log to a DOS^[16] or Macintosh machine under OS 8 or 9, and further protect your logs. After all, if syslog is the only network service running on those systems, there is no way for someone to break in from the Net to alter the logs!

^[16] Windows has too many extra services and security concerns. If all you are doing is listening and logging, DOS is quite enough.

21.4.1.3 Logging everything everywhere

Disks are cheap these days. Sites with sufficient resources and adequately trained personnel sometimes choose to log everything that might possibly be useful, and log it in many different places. In addition to individual log files for different types of messages, many system administrators configure syslog to log all messages at all levels to a single file, which provides a chronological account of all logged events. Workstations on networks can create their own log files of syslog events, and also send all logging messages to several different logging hosts—possibly on different networks.

The advantage of logging in multiple places is that it makes an attacker's attempts at erasing any evidence of his presence much more difficult. It also allows you to validate log entries if you need to use them as evidence. If several devices record the same event, the log entry is more trustworthy. On the other hand, multiple log files will not do you any good if they are never examined. Furthermore, if they are never pruned, they may grow so large that they will negatively impact your operations.

Tables Table 21-5 and Table 21-6 summarize some typical messages available on various versions of Unix. Other critical conditions might include messages about full filesystems, device failures, or network problems.

For security reasons, some information should never be logged. For example, although you should log failed password attempts, you should not log the password that was used in the failed attempt. Users frequently mistype their own passwords, and logging these mistyped passwords would help an attacker break into a user's account. Some system administrators believe that the account name should also not be logged on failed login attempts—especially when the account typed by the user is nonexistent. The reason is that users occasionally type their passwords when they are prompted for their usernames. If invalid accounts are logged, then it might be possible for an attacker to use those logs to infer people's passwords. This is one reason why auth facility messages are sometimes logged to a special log file that is readable only by root.