10.3.1 aculog File

The tip command and the Berkeley version of the UUCP commands record information in the aculog file each time they make a telephone call. The information recorded includes the account name, date, time, entry in the /etc/remote file that was used to place the call, phone number dialed, actual device used, and whether the call was successful or not.

Here is a sample log:

tomh (Mon Feb 13 08:43:03 1995) <cu1200, , > call aborted
tomh (Tue Mar 14 16:05:00 1995) <a9600, , /dev/cua> call completed
carol (Tue Mar 14 18:08:33 1995) <mit, 2531000, /dev/cua> call completed

In the first two cases, the user tomh connected directly to the modem. In these cases, the phone number dialed was not recorded.

Most Hayes-compatible modems can be put into command mode by sending them a special "escape sequence." Although you can disable this feature, many sites do not. In those cases, there is no way to be sure if the phone numbers listed in the aculog are in fact the phone numbers that were called by your particular user. You also do not have any detailed information about how long each call was.

10.3.2 sulog Log File

Some versions of UNIX record attempts to use the su command by printing to the console (and therefore to the messages log file). In addition, some recent versions specially log su attempts to the log file sulog .

Under some versions of System V-related UNIX , you can determine logging via settings in the / etc/default/su file. Depending on the version involved, you may be able to set the following:

# A file to log all su attempts
SULOG=/var/adm/sulog
# A device to log all su attempts
CONSOLE=/dev/console
# Whether to also log using the syslog facility
SYSLOG=yes

Here is a sample sulog from a computer running Ultrix V4.2A:

BADSU: han /dev/ttyqc Wed Mar  8 16:36:29 1995
BADSU: han /dev/ttyqc Wed Mar  8 16:36:40 1995
BADSU: rhb /dev/ttyvd Mon Mar 13 11:48:58 1995
SU: rhb /dev/ttyvd Mon Mar 13 11:49:39 1995

As you can see, the user han apparently didn't know the superuser password, whereas the user rhb apparently mistyped the password the first time and typed it correctly on the second attempt.

Scanning the sulog is a good way to figure out if your users are trying to become the superuser by searching for passwords. If you see dozens of su attempts from a particular user who is not supposed to have access to the superuser account, you might want to ask him what is going on. Unfortunately, if a user actually does achieve the powers of the superuser account, he can use those powers to erase his BADSU attempts from the log file. For this reason, you might want to have BADSU attempts logged to a hardcopy printer or to a remote, secure computer on the Internet. See the Section 10.5.2.1, "Logging to a printer " and Section 10.5.2.2, "Logging across the network " later in this chapter.

10.3.3 xferlog Log File

If your computer uses the Washington University FTP server, then you can configure your server to log all files transferred. The default filename for this log is xferlog , and the default location is the directory /var/adm/. The location is defined by the configuration variable _PATH_XFERLOG in the file pathnames.h.

The following information is recorded in the file xferlog for each file transferred:

• Date and time of transfer

• Name of the remote host that initiated the transfer

• Size of the file that was transferred

• Name of the file that was transferred

• Mode of the file that was transferred (a for ASCII ; b for binary)

• Special action flag (C for compressed; U for uncompressed; T for tar archive)

• Direction of the transfer (o for outgoing, i for incoming)

• The kind of user who was logged in (a for anonymous user; g for guest; and r for a local user who was authenticated with a password)

Here is a sample from the xferlog on a server:

Sat Mar 11 20:40:14 1995 329 CU-DIALUP-0525.CIT.CORNELL.EDU 426098
 /pub/simson/scans/91.Globe.Arch.ps.gz b _ o a ckline@tc.cornell.edu ftp 0*
Mon Mar 13 01:32:29 1995 9 slip-2-36.ots.utexas.edu 14355
 /pub/simson/clips/95.Globe.IW.txt a _ o a mediaman@mail.utexas.edu ftp 0 *
Mon Mar 13 23:30:42 1995 1 mac 52387 /u/beth/.newsrc a _ o r bethftp 0 *
Tue Mar 14 00:04:10 1995 1 mac 52488 /u/beth/.newsrc a _ i r bethftp 0 *

The last two entries were generated by a user who was running the Newswatcher netnews program on a Macintosh computer. At 23:30, Newswatcher retrieved the user's . newsrc file; at 00:04 the next morning, the . newsrc file was sent back.

10.3.4 uucp Log Files

Derivatives of the BNU version of UUCP (the version you are most likely to encounter on non-Linux systems) may have comprehensive logging available. These log files are normally contained in the /var/spool/uucp/.Admin directory. These include logs of transfers, foreign contacts, and user activity. Of most interest is the file security , if it exists. This file records instances at which violations of restrictions are attempted using the UUCP system.

One type of record present may indicate attempts to make prohibited transfers of files. These records start with the tag xfer and contain the name and user on the requesting and destination hosts involved in the command, information to identify the file name and size, and information about the time and date of transfer.

The other type of record starts with the tag " rexe " and indicates attempts to execute a command that is not allowed. This record will contain the name and user on the requesting and destination hosts involved in the command, the date and time of the attempt, and the command and options involved.

The exact format of the fields may differ slightly from system to system, so check your documentation for exact details.

We suggest that you monitor this file for changes so you will be aware of any problems that are recorded. Because the directory is not one you might otherwise monitor, you may wish to write a shell script (similar to the one shown below) to put in the crontab to run every few hours:

#!/bin/ksh 
# set the following to indicate the user to notify of a new
# security record
typeset User=root 
cd /var/spool/uucp/.Admin 
if [[ -r security.mark ]]
then
   if [[ security -nt security.mark ]]
   then
      comm -3 security security.mark | tee -a security.mark |
         /bin/mailx -s "New uucp security record" $User
      
   fi
else
   touch security.mark
fi

10.3.5 access_log Log File

If you are running the NCSA HTTPD server for the World Wide Web, then you can determine which sites have been contacting your system and which files have been downloaded by examining the log file access_log .[6]

[6] Other WWW servers also log this information, but we will only present this one as an example. See your documentation for details about your own server.

The HTTPD server allows you to specify where the access_log file is kept; by default, it is kept in the directory /usr/local/etc/http/logs .

Each line in the log file consists of the following information:

• Name of the remote computer that initiated the transfer

• Remote login name, if it was supplied, or "-" if not supplied

• Remote username, if supplied, or "-" if not supplied

• Time that the transfer was initiated (day of month, month, year, hour, minute, second, and time zone offset)

• HTTP command that was executed (usually GET )

• Status code that was returned

• Number of bytes that were transferred

Here are some sample log entries:

port15.ts1.msstate.edu - - [09/Apr/1995:11:55:37 -0400] "GET /simson
 HTTP/1.0" 302 -
ayrton.eideti.com - - [09/Apr/1995:11:55:37 -0400] "GET /unix-haters-
title.gif HTTP/1.0" 200 49152
port15.ts1.msstate.edu - - [09/Apr/1995:11:55:38 -0400] "GET /simson/
 HTTP/1.0" 200 1248
mac-22.cs.utexas.edu - - [09/Apr/1995:14:32:50 -0400] "GET /unix-
haters.html HTTP/1.0" 200 2871
204.32.162.175 - - [09/Apr/1995:14:33:21 -0400] "GET
/wedding/slides/020.jpeg HTTP/1.0" 200 9198
mac-22.cs.utexas.edu - - [09/Apr/1995:14:33:53 -0400] "GET /unix-
haters-title.gif HTTP/1.0" 200 58092

One program for analyzing the access_log log file is getstats , available via anonymous FTP from a number of servers . This program can tell you how many people have accessed your server, where they are coming from, what files are the most popular, and a variety of other interesting statistics. We have had good results with getstats . For further information on getstats , check:

http://www.eit.com/software/getstats/getstats.html

10.3.6 Logging Network Services

Some versions of the inetd Internet services daemon have a " -t " (trace) option that can be used for logging incoming network services. To enable inetd logging, locate the startup file from which inetd is launched and add the -t option.

For example, under Solaris 2.4, inetd is launched in the file /etc/rc2.d/S72inetsvc by the following line:

#
# Run inetd in "standalone" mode (-s flag) so that it doesn't have
# to submit to the will of SAF.  Why did we ever let them change inetd?
#
/usr/sbin/inetd -s

To enable logging of incoming TCP connections, the last line should be changed to read:

/usr/sbin/inetd -t -s

Logs will appear in /var/adm/messages . For example:

Jan  3 10:58:57 vineyard.net inetd[4411]: telnet[4413] from 18.85.0.2
Jan  3 11:00:38 vineyard.net inetd[4411]: finger[4444] from 18.85.0.2 4599
Jan  3 11:00:42 vineyard.net inetd[4411]: systat[4446] from 18.85.0.2 4600

If your version of inetd does not support logging (and even if it does), consider using the tcpwrapper , discussed in Chapter 22, Wrappers and Proxies .

10.3.7 Other Logs

There are many other possible log files on UNIX systems that may result from third-party software. Usenet news programs, gopher servers, database applications, and many other programs often generate log files both to show usage and to indicate potential problems. The files should be monitored on a regular basis.

As a suggestion, consider putting all these logs in the same directory. If you cannot do that, use a symbolic link from the log file's hard-coded location to the new log file in a common directory (assuming that your system supports symbolic links). This link will facilitate writing scripts to monitor the files and tracking the log files present on your system.

NOTE: Many systems have cron jobs which rotate the log files. If these scripts do not know about your symbolic links, you won't get what you expect! Instead of having your log files rotated, the symbolic link will be renamed and a new file created in its old place, rather than where the symbolic link pointed.