When
Ideally daily, but at least weekly, depending on your audit
policy.
Why
Understanding what's in other logs helps administrators
recognize what's happening on their system.
Strategy
The kernel, accounting system and add-on utilities all log
info that is recorded somewhere, often in /usr/local, /var, /etc and
/opt if you have a database on the system, for example. To find your
log files, read your systems' startup scripts (/etc/rc*, /etc/rc.d/*
or /etc/init.d/*). If you run reports using specific tools, these
often put the results in the tool's subdirectory, like
Requires Free Membership to View
SearchSecurity.com members gain immediate and unlimited access to breaking industry news, virus alerts, new hacker threats, highly focused security newsletters, and more -- all at no cost. Join me on SearchSecurity.com today!
Michael S. Mimoso, Editorial Director
ASET
does. Most programs handle logging via syslog, so check the configuration file, /etc/syslog.conf, to find out where messages go. Consider using logadm to manage endlessly growing log files.
Unix can be mysterious, but don't mess with these logs, no matter how curious you are because it will further confuse the system and consume space:
- /var/adm/lastlog: users' last login in machine-readable text only and is indexed by the system.
- /var/adm/utmp: logs attempts by the system to track who is still logged in, but can be a problem because sometimes a shell was killed or it didn't clean up after itself.
Keep an eye on these two files, for they will often get large, but don't do anything. If they seem to be a problem, call the help/service desk or your system rep.
Other files that can grow quickly include those under /var/audit, where you'll find files that have not terminated. More potential space-hog files filling with status info include:
- /var/tmp: Files stored in /tmp are supposed to disappear between reboots, but not those in /var/tmp; also, if your system runs 24x7, the system never deletes the files in /tmp, so make sure the files here stay manageable.
- Files labeled o.logname usually indicate an overflow log. If a log file overflows, all auditing put there stops.
- lost+found directories are created automatically when you build a filesystem; these files are used by fsck -- don't delete them. If fsck finds an orphan file whose parent directory can't be determined, it will place the file here with its inode numbers.
- Unix makes backup files, numbering them sequentially higher; this function can be turned off for many reasons, among them, security, i.e., enforcing confidentially versus availability. File names are labeled similar to Old-Log-1, Old-Log-2, etc. A uucleanup daemon, if being used, usually runs from cron, gathers logs at day's end and puts them in a directory.
- /var/adm/log/asppp.log: The dialup network connections protocol, shipped "on" by default, will fill with messages about lack of connection paths if you don't have any configured.
- /var/adm/lastlog: stores information about a logged on user.
- /var/adm/sulog: records all attempts by users to execute su.
- /var/adm/messages: a catchall file for lots of messages from the Unix kernel and other logging applications like syslogd. Also sometimes used to store miscellaneous log files, including those created by syslog for messages not written to /usr/adm/messages or the console.
- /var/cron/log -- Logs all jobs run in crontab.
Because logs frequently provide the only indication of an intrusion, trespassers often attempt to erase evidence of their activities by altering log files. For this reason, it's critical your log files be protected to make it as difficult as possible for intruders to change or remove them. Also, messages repeated many times require attention -- diagnosing the reason for them will tell what your system is doing or not doing.
More information
Solaris 8+ info is at: http://docs.sun.com; you
may have to read man pages for individual daemons to see where log
data is actually put.
About the author
Shelley Bard, CISSP, CISM, is a senior security network engineer with
Verizon Federal Network Systems (FNS). An information security
professional for 17 years, Bard has briefed and written infosecurity
assessments and technical reports for the White House and Department
of Defense, special interest groups, industry and academia. Please
e-mail any comments to securityplanner@infosecuritymag.com.
Opinions expressed in this column are those of Shelley Bard and don't
necessarily reflect those of Verizon FNS.
This was first published in September 2004