Ideally daily, but at least weekly, depending on your audit policy.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Understanding what's in other logs helps administrators recognize what's happening on their system.
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 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.
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 firstname.lastname@example.org.
Opinions expressed in this column are those of Shelley Bard and don't necessarily reflect those of Verizon FNS.