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