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.^[320]

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^[321] 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!

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.