 | Chapter 10 Auditing and Logging |  |
| Chapter 10 Auditing and Logging | |
Depending on the version of UNIX you are using, you may find a number of other log files in your log file directory.
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.
Some versions of UNIX record attempts to use the sucommand 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.
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.
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
fiIf 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:
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.
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.
|  | |
| 10.2 The acct/pacct Process Accounting File |  | 10.4 Per-User Trails in the Filesystem |