|
|
||
|
|
|
|
(Introduction to System Logs and Auditing) Table of Contents: - Introduction - Shell History - SULOG - SYSLOG.CONF - SYSLOGD - UTMP - WTMP - LASTLOG - CRON - XFERLOG - LOGINLOG - Closing Notes
Introduction - And it begins...
I wrote this paper to introduce some of the logs and audit methods used to monitor systems, and more importantly, check for intruders. A lot of such methods of detection have been replaced by the syslogd daemon, due to it's powerful monitoring capabilities. I generally didn't aim this paper towards people just starting out on UNIX, but it doesn't get very advanced ;-). I've tried to describe the more important files, the ones which a hacker should take notice of, and learn to work with. Once you get an idea how they process, you can understand what you have to edit- and how you can keep from being logged all together.
Shell History - $HOME ; $HOME/tmp
Whenever you logout or exit from some shells, the contents of your command history are saved in a file. When the user relogs in, the file is fed to the history list, allowing the use of stored commands from the last session. This file's presence on the system mainly depends upon how it is set up. The number of commands stored by history is indicated in the environment variable HISTSIZE. For example, a <HISTSIZE> of 50 would keep a history file of the fifty most recent commands issued:
i.e. HISTSIZE=50;export HISTSIZE
The bourne shell <sh>, uses ".sh_history" , along with it's enhanced version <jsh> and the korn shell <ksh>. The Bourne-Again Shell <bash> uses ".bash_history", and the C shell <csh>, Z Shell <zsh>, and the Enhanced C Shell <tcsh>, use ".history". Their can also be backups of these files- "dead.letter", "*.bak", and "*~". The shell history isn't necessarily for auditing purposes, but can be very dangerous. This is one of the best ways of removing your shell history. (Only works under the csh and variations)
$ mv .logout save
$ echo rm .history>.logout
$ echo rm .logout>>.logout
$ echo mv save .logout>>.logout
Also, try editing your shell profile to rename the history file (with the environment variable HISTFILE) - alot of admins won't notice what you've done, and go right by your history.
SULOG - /var/adm/sulog <specified in /etc/default/su>
Sulogs record the program [su]s usage. It isn't usually very important, unless you have to login with a hacked account or brute-force from within the system. "/var/adm/sulog" is the default location at which the log resides, but can be changed, which is indicated in "/etc/default/su". A normal sulog entry is constructed as follows:
SU date time result terminal user-newuser
i.e - SU 02/24 20:29 + console logik-root
The "+" or "-" sign indicates the su commands result. A "+" having returned a successful exit status, a "-" displaying just the opposite. This entry shows that on February 2, at 8:29, a local user <logik> successfully switched to the root account.
SYSLOG.CONF - /etc/syslog.conf <or specified with option in syslogd>
"syslog.conf" is the configuration file for the syslogd system log daemon. It contains information used by syslogd to forward system messages to the appropriate log files and users. The syslog.conf looks like this:
facility.severity <TAB> action (multiple entries can be setup using semi-colons)
"facility" is where the name of a system facility which is producing the message goes, and "severity" is the importance of the message. Where "action" is is the action which will be performed when such a message (as specified in the facility.severity fields) occurs. The message can be sent to a file, to another host, to a group of users, or all users. Here's a sample entry:
kern.crit /etc/kern.log
This tells all messages generated by the kernel with a critical severity flag to be sent to a file called kern.log, in the /etc directory. Their are a lot of different options which can be specified, which I might get into in a different article. The syslogd configuration can be very helpful when covering your tracks, since it tells you where you can locate every syslogd handled record on the system.
SYSLOGD - /usr/etc/syslogd ; /usr/sbin/syslogd
Syslogd processes system messages and sends them to log files and users, specified in it's configuration file <syslog.conf>. When the syslogd daemon starts up, it creates the file syslog.pid </etc/syslog.pid>, containing it's process ID. The syslogd daemon reads from the address family socket </dev/log>, from an internet address family socket specified in /etc/services, and for kernel messages, syslogd listens at /dev/klog. Syslogd depends mainly upon it's configuration file in the /etc directory <syslog.conf, which I've described above>, but can use an alternative configuration file, specified with an option. Here's an example log entry, which was configured to log all system daemon messages to "derr.log" in the /etc directory:
Configuration entry:
daemon.* /etc/derr.log
Log entry:
Feb 16 09:24:02 uco syslogd: restart
Feb 16 09:28:12 uco rshd[844]: connect from logik@cs.xsec.org
The syslog daemon is started on February 16, at 9:24 on the host uco. At 9:28, logik@cs.xsec.org rshs into uco, and is assigned a process ID of 844. The complexity of the syslogd daemon and the simplicity of setting up such powerful auditing is why it can be one of the most dangerous files to a hacker - that is, if they don't know how to handle it :-).
UTMP - /etc ; /var/adm ; /usr/adm ; /usr/var/adm ; /var/log
The utmp file records information about who is currently using the system. The file is made up of utmp structure entries, thus defined in the utmp.h file. It's setup like this:
ut line Contains the name of the terminal on which the user logged in.
ut name Contains the name of the user who logged in.
ut host Containing the name of the host from which the user remotely logged in, otherwise, a null string.
ut time Containing the time at which the user logged in.
Whenever a user logs in, the login program fills in the entry in utmp for the terminal on which the user logged in. When they log out, init clears that entry by setting ut name and ut host to null strings and ut time to the time at which the user logged out.
WTMP - /etc ; /var/adm ; /usr/adm ; /usr/var/adm ; /var/log
The wtmp file records all logins and logouts. It also records shutdowns, reboots, and when the date command is used to change the system's date. The wtmp file has to be created manually, since the programs which manage it don't- so it may not appear on all systems, which turns record-keeping off. The login program writes entries for logins in wtmp identical to the messages placed in utmp. For logouts, init sets the following, and leaves ut name and ut host with a null value:
ut line The terminal on which the user was logged in.
ut time The time at which the user logged off.
When the system is shut down or restarted, the init program leaves ut host null, and sets the following:
ut line ~
ut name shutdown or reboot
ut time The time at which the shutdown or reboot occurred.
And finally, when the date is changed <ut host and name null>:
ut line |
ut time Previous system date.
ut line {
ut time Changed system date.
LASTLOG - /usr/var/adm ; /usr/adm ; /var/adm ; /var/log
The lastlog file records the most recent login-date for every user logged on. The file is made up of lastlog structure entries (similar to the utmp structure), which are defined in lastlog.h, and contain the following:
ll time Contains the time at which the user logged in
ll line Containing the name of the terminal on which the user logged in.
ll host Containing the name of the host from which the user remotely logged in, otherwise, it's null.
To retrieve the login date, the login program performs an lseek to a byte-offset in the lastlog, corresponding to the userid which is logging in.
CRON - /var/spool/cron/ ; /var/cron/
Cron runs the crontab command, which allows a user to set up a list of tasks they want performed regularly, which is often used to automate the detection of intruders. The default directory for the crontabs is "/var/spool/cron/crontabs/". Here's a quick and easy way to check what a user has setup:
crontab -l user
i.e. crontab -l root
Any output from the crontab is mailed to the owner of the tab, or to the user specified in the <MAILTO> environment variable in the crontab-which is one reason why it can be such a useful auditing tool.
XFERLOG - /usr/adm/xferlog <or specified with option in ftpd>
The xferlog file contains records sent from the FTP server daemon, ftpd. Each entry looks like this:
current-time transfer-time remote-host file-size filename transfer-type special-action-flag direction access-mode username service-name authentication-method authenticated-user-id
This file can be very important, most so if you used ftpd to gain access to the host.
Here's an example entry:
Fri Feb 12 11:24:46 1998 16 ecos.org 44618 /xkil.c a _ o r logik ftp 1 *
This entry shows that on Friday, February 12, 1998, at 11:24 (and 46 seconds), logik (an authenticated user who logged on from ecos.org) used the file transfer protocol to download a 44,618 byte ascii file named xkil.c from the root directory (which took 16 seconds to complete). He used RFC931 authentication, an authenticated user id was not available, and no special action was taken. <whew>
LOGINLOG - /var/adm/loginlog ; /usr/adm/acct/loginlog
The loginlog records bad login attempts. Once five unsuccessful logins are attempted, the login program forwards a record of each bad login, and sleeps for 20 seconds. If loginlog doesn't exist, login drops the line, so no logging is done. Here's how a lastlog entry is setup:
login name;tty specification;time
Like WTMP, loginlog has to be created manually to function. Therefore, if loginlog doesn't exist, it doesn't log anything. Also, loginlog must be owned by root and in the sys group to operate. It's always good to remember that loginlog only records the bad logins after five consecutive unsuccessful attempts.
Closing Notes - Yes, it finally ends.
Basically, many programs can talk to the syslogd daemon, which makes an exhaustive look at system auditing almost impossible. Also, I didn't really get into the less important logs and history files, accounting records, X-only mode auditing, and of course the hateable checksum checking software like hobgoblin and tripwire - not to mention much detail ;-). Maybe I'll write a more advanced article <with actual techniques on "correcting" the logs-hoho!>, if I get a good response to this one :-). Shout outs to van Hauser / THC, Mantis, Jabukie and everyone at Rootshell, Bugtraq, and Technotronic.
Logik logik@snip.net |
