Unix Auditing
Unix Auditing and Log Files
Watching them, logging you

A good security conscious system administrator will have extensive logging and auditing installed on his or her server. This allows the sysadmin to work out where errors might have occured, recover the system after a crash or work out the details of a 'break in' by a hacker. For this reason a hacker must be able to be able to cover his or her tracks to prevent prosecution for be evil enough to want to use a new and exciting system. This means a hacker must have a good knowledge of what auditing systems are in use.

Basic Unix Log Files
The most common directories for log and auditing files in unix are:

  • /usr/adm
  • /var/adm
  • /var/log

    Remember, these are common locations for log files and 9 times out of 10 this is where they reside (often in subdirectories of these locations), however log files can be anywhere on the system and a sysadmin with even a drop of healthy paranoia will use far less obvious locations for these files. The files in these directories might even be dummies, so check that they are written to when you use the system.

    The exact structures of various log files tend to differ from system to system so you'll either have to find them out (e.g. from the man entry) or you'll have to work them out (break out that hex editor !). Also most log files are set to be writable by root only. As with the locations of these files, their names may be different.

    The most common unix log files are:

    .history Records commands run by user (usually stored in user directory and user writable). Simply delete to remove. However it may be a symbolic link to a file in an area that needs superuser priviledges to write to but this is very rare.
    acct or pacct Records commands run by every user but not the command line arguments to the program run. The lastcomm or acctcom command will display this file in a user readable format. Because this file can grow very large very quickly unix systems often run a cron job to execute the sa or pacct program on a daily or weekly basis to reduce this file to a summary file, which is often kept in /var/adm/savacct
    access_log Log of WWW page / file access. Used by the NCSA httpd server which is particularly common. Every web server package I have seen has some way to log accesses. Usually logs hostname access was from, remote login and username, time of access, http command executed, number of bytes sent. This is usually in plaintext and so can be edited with a standard text editor.
    aculog Log of dial-out modem use. Entries are stored in plaintext.
    lastlog Log of last time user successfully (and possibly unsuccessfully) logged in. Includes IP address user logged in from. On some systems (e.g. Irix) this is a directory with a seperate file for each user. The file name is the same as the username. In this case simply delete the file to remove lastlog entry. Is used by the finger command to display information.
    loginlog Records bad login attempts (a bad password entry 5 times in a row). This file must be specifically created by the sysadmin. Unsurprisingly quite a few sysadmins do not bother to create this file and so this logging is not done. Entries are stored as plaintext.
    messages Records output to the system console and other messages generated from the syslog facility. This is usually a plaintext file.
    sulog Logs use of the su command (both successful and unsuccesful attempts). This is usually a plaintext file and so can be edited easily.
    utmp File that records who is currently logged in. The who command uses this file to display users currently logged in. Removing your entry from this file will make you invisible to the who command although your username will still be associated with any processes you run. On some systems this may be writable by users without superuser priviledges. Is the same format as wtmp file.
    utmpx Extended utmp. Usually includes extra details such as the full hostname of where you logged in from, the full device name and session name.
    wtmp Provides an ongoing record of each time a user logs in or out, (including FTP) and each time the system was rebooted, shutdown etc. Same structure as wtmp. Running the last command will display the when users have logged in and out in a user readable format. To edit this file you will need to use a hex editor (pain the the ass!) or write some code to do it.
    wtmpx Extended wtmp. See utmpx.
    vold.log Logs errors encountered with the use of external media (e.g. floppy disks, CD-ROMs).
    xferlog Logs FTP acccess.

    syslog is commonly and extensively used to log user activity to standard log files (as detailed above) and to any other sources that the sysadmin sees fit. The daemon that is the heart of the syslog facility is called syslogd (surprise, surprise) although it may be renamed so it is harder to detect. So just because no obvious logging processes show up when you do "ps -ef" or "ps -aux" it doesn't mean none are running.

    syslog can monitor: the kernel, user processes, mail, printer usage, any processes that need a username / password, system daemons, news (usenet) and uucp usage. Plus it can monitor upto 7 other things defined by the sysadmin. i.e. ALMOST ANYTHING.

    When syslog starts it reads it's config file (/etc/syslog.conf) which lets it know what it should be monitoring so it is worth checking this file out. It then 'listens' at three sources for log messages.

  • /dev/klog (kernel generated messages)
  • /dev/log (unix domain socket, used to read message to generated by processes running on the local machine
  • UDP port 514 (internet domain socket, used to read log messages generated by the network from other machines

    This file denotes what is logged and where it is logged to. It has the facility to timestamp the logfile every 20 minutes and to give entries priorities from emergency to none. Either look up the man page for syslog or find a good book on it. "Practical Unix and Internet Security" (2nd ed.) by Simson Garfinkel and Gene Spafford has a good section on syslog usage (pgs 309 - 318). It is also a very good general purpose book for either anyone interested in unix security.

    Other log files
    Other log files can include any piece of software (either especially written or otherwise) that logs any part of the system usage. There is no surefire way to be 100% certain that you know all of the auditing that is being done on a system. It is always worth checking out any unfamiliar processes running on the system. Check man pages for entries / keywords, check the web, books etc. A sysadmin with half a brain and his own logging software is unlikely to have it running named something like 'hackerlog', so it is worth familiarising yourself with common processes that run on unix systems (and remember these may be different for different systems). It is also worth familiarising yourself with the default log files used by common security utilities such as portmap, Tripwire, wuarchive ftpd and Swatch (not strictly a logging program, but it acts on syslog entries, for example e-mailing someone when a specific entry occurs) to name a few.

    Final note
    If at all possible, log files should be edited to remove traces of your use of the system, NOT deleted. By deleting a log file you destroying data that may be used in the day-to-day running of the system and may affect other users and the normal operation of the system. If you cannot edit a log file effectively, then make sure you are accessing the system from a safe IP address that cannot be traced to you, or you are IP spoofing. Also note that any commands you run or any other systems you may access could give away details which could point to who you are, so be careful. Also remember that whenever you alter a file the file date will change, so take a note of the original time and date before you edit the file and then use the touch command to restore this after you have finsihed editing.

    Electronic log files are not particularly admissable in court, although they may be more highly considered if they are relied on by the system for other uses than purely logging (for example if the system used the log files to determine that after 1000 logins backups where to be taken). They are also more admissable if there is a dated and possibly hardcopy made at the time. All of which may be done. Log files are routinely used to track down and prosecute hackers so they are very important if you are involved in system security from either end. Log files are like any other file on the system, so altering is 'more illegal' than simply 'using the system' (their distinction not mine). Any syadmin worth his or her job will have extensive logging, so expect auditing.



    All information is for education purposes only. Blah blah blah...