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