21.3 Program-Specific Log Files

Depending on the version of Unix you are using, you may find a number of other log files in your log file directory.

21.3.1 aculog Log 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.

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.

Many 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.

21.3.2 sulog Log File

Some versions of Unix record attempts to use the su command to become the superuser by printing to the console (and therefore to the messages log file). In addition, some 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 Section 21.4.1.1 and Section 21.4.1.2 later in this chapter.

21.3.3 xferlog Log File

Many FTP servers have the ability to log every file that is transferred. The default filename for this log is xferlog, and the default location is the directory /var/log or /var/adm. The location for this file on the Washington University FTP server is defined by the configuration variable _PATH_XFERLOG in the file pathnames.h. (For other FTP services, consult your documentation.)

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; r for a local user who was authenticated with a password)

Here is a sample from the Washington University FTP server's xferlog:

Sat Mar 11 20:40:14 2000 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 2000 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 2000 1 mac 52387 /u/beth/.newsrc a _ o r bethftp 0 *
Tue Mar 14 00:04:10 2000 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.

21.3.4 access_log Log File

If you are running the Apache web server, you can determine which sites have been contacting your system and which files have been downloaded by examining the log file access_log.^[13]

^[13] Other web servers also log this information, but we will present only this one as an example. In addition, the location and name of the Apache name server logs are highly configurable, and a single Apache server may be serving multiple virtual web hosts, each with its own logs. See your documentation for details about your own server.

The Apache server allows you to specify where the access_log file is kept; on many systems, it is found in /usr/local/apache/logs, and on others, in /var/log/httpd.

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

Name of the remote computer that initiated the transfer
Remote login name if the remote host is running identd, or "-" if not supplied
Remote username if user authentication is in use, or "-" if not supplied
Time that the transfer was initiated (day of the 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:^[14]

^[14] The format described is referred to as the " Common Log Format" and is used by many web servers. Alternative formats are also used. For example, the Combined Log Format also includes the page from which the browser was referred to the current page and information identifying the browser software, if supplied.

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

Dozens of programs are available for analyzing web server logs. One that we've had good results with is analog. 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. For further information on analog, check out http://www.analog.cx.

Apache also logs errors that result from web operations, including attempts to access forbidden files and CGI script failures. The default log for errors is called error_log, and is stored alongside the access log.

21.3.5 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.5.x, 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 12.

21.3.6 Other Logs

There are many other possible log files on Unix systems that may result from third-party software. Usenet news programs, DNS nameservers, 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 hardcoded 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.