utmp, wtmp, sulog
UNIX records the last time that each user logged into the system in the lastlog log file. This time is displayed each time that you log in: e.g. login: grossman password: Last login Mon Feb 14 09:19 on console
Unfortunately, the design of the lastlog mechanism is such that the previous contents of the file are overwritten at each login. As a result, if a user is inattentive for even a moment or if the login message clears the screen, the user may not notice a suspicious time. Furthermore, even if a suspicious time is noted, it is no longer available for the system administrator to examine.
utmp, wtmp, utmpx, and wtmpx Files
UNIX keeps track of who is currently logged into the system with a special file called utmp, or utmpx on Solaris systems. This is a binary file that contains a record for every active session and generally does not grow to be more than a few kilobytes in length. A second file, wtmpx, keeps a record of both logins and logouts. This file grows every time a user logs in or logs out and can grow to be many megabytes in length unless it is pruned. utmpx and wtmpx are found in /var/adm on our Solaris systems. utmp and wtmp do not exist in Solaris.
The extended wtmpx file used by the Solaris operating system includes the following:
Username, 32 characters instead of 8
inittab ID, indicates the type of connection
Terminal name, 32 characters instead of 8
Device name
Process ID of the login shell
Code that denotes the type of entry
Exit status of the process
Time that the entry was made
Session ID
Unused bytes for future expansion
Remote hostname for logins that originate over a network
Examining the utmpx and wtmpx Files
UNIX programs that report the users that are currently logged into the system, e.g. who, whodo, w, users, and finger, do so by scanning the /var/adm/utmpx file. The write command checks this file to see if a user is currently logged in and determines which terminal she is logged in at.
The last program which prints a detailed report of the times of the most recent user logins does so by scanning the wtmpx file.
The ps command gives you a more accurate account of who is currently using you system than the who, whodo, users, and finger commands because under some circumstances users can have processes running without having their usernames appear in the utmpx or wtmpx files.
However, the commands who, users, and finger have several advantages over ps:
They often present their information in a format that is easier to read than the ps output.
They sometimes contain information not present in the ps output, such as the names of remote host origins.
They may run significantly faster than ps.
The su command and the utmpx and wtmpx Files
When you use the su command, it creates a new process with both the process’s real UID and effective UID altered. This gives you the ability to access another user’s files and run programs as the other user.
Because su does not change your entry in the utmpx or the wtmpx files, the finger command will continue to display the account to which you logged in, not the one that your sued to. Many other programs as well may not work properly when used from within a su subshell, as they determine your username from the utmpx entry and not from the real or effective UID.
Note that different versions of the su command have different options available that allow you to reset your environment, run a different command shell, or otherwise modify the default behavior. One common argument is a simple dash, as in su - user. This form will cause the shell for user to start up as if it were a login shell.
Thus, the su command should be used with caution. While it is useful for quick tests, because it does not properly update the utmpx and wtmpx files, it can cause substantial confusion to other users and to some system utilities.
last Program
Every time that a user logs in or logs out, Solaris makes a record in the wtmpx file. The last program displays the contents of this file in an understandable form. If you run last with no arguments, the command display all logins and logouts on every device. last will display the entire file. You can abort the display by pressing the interrupt character,
# last | tail root pts/3 :0.0 Fri Dec 3 15:31 - 15:32 (00:00) root console :0 Fri Dec 3 15:30 - 15:39 (00:09) reboot system boot Fri Dec 3 15:27 reboot system down Fri Dec 3 15:21 root pts/4 :0.0 Fri Dec 3 15:18 - down (00:08) root pts/3 :0.0 Fri Dec 3 15:18 - 15:18 (00:00) root console :0 Fri Dec 3 15:14 - down (00:12) reboot system boot Fri Dec 3 15:06 wtmp begins Fri Dec 3 15:06
The last command also allows you to specify a username or a terminal as an argument to prune the amount of information displayed. If you provide a username, last displays logins and logouts for that user. Again, from my Solaris system
# last grossman grossman console :0 Mon Feb 14 09:19 - 09:34 (00:14) grossman console :0 Thu Feb 10 10:40 - 14:38 (03:58) grossman console :0 Wed Feb 9 11:28 - 15:59 (04:31) grossman pts/4 localhost Mon Feb 7 15:44 - 16:09 (00:25) grossman sshd localhost Mon Feb 7 15:44 - 16:09 (00:25) grossman pts/4 localhost Wed Feb 2 14:09 - 14:09 (00:00) grossman sshd localhost Wed Feb 2 14:09 - 14:09 (00:00) grossman pts/4 localhost Wed Feb 2 14:08 - 14:09 (00:00) grossman sshd localhost Wed Feb 2 14:08 - 14:09 (00:00) grossman pts/4 localhost Wed Feb 2 14:08 - 14:08 (00:00) grossman sshd localhost Wed Feb 2 14:08 - 14:08 (00:00) grossman console :0 Wed Feb 2 13:48 - 13:48 (00:00) grossman console :0 Wed Feb 2 13:47 - 13:47 (00:00) wtmp begins Fri Dec 3 15:06
You may wish to use the last command every morning to see if there were any unexpected logins during the previous night.
sulog Log File
Solaris records attempts to use the su command to become the superuser by printing to the console and to the log file /var/adm/sulog. From my Solaris OS the sulog file is
# more /var/adm/sulog SU 12/03 15:14 + ??? root-root SU 12/03 15:32 + ??? root-root SU 12/03 15:34 + ??? root-root SU 12/13 15:19 + ??? root-root SU 02/07 15:43 + pts/3 root-root BADSU 02/07 15:44 + pts/4 grossman-root
Scanning the sulog is a good way to figure if your users are trying to become the superuser by searching for passwords. If you see dozens of su attempts from a particular user who is not supposed to have access to the superuser account, you might want to ask her what is going on. Unfortunately, if a user actually does achieve the powers of the superuser account, she can use those powers to erase her BADSU attempts from the log file. For this reason, you might want to have BADSU attempts logged to a hardcopy printer or to a remote, secure computer on the network.
Shell History
Many of the standard user command shells, including bash, csh, tcsh, and ksh, can keep a history file. When the user issues commands, the text of each command and its arguments are stored in the history file for later re-execution. If you are trying to recreate activity performed on an account, possibly by some intruder, the contents of this file can be quite helpful when coupled with system log information. You must check the modification time on the file to be sure that it was in use during the time the suspicious activity occurred. If it was created and modified during the intruder’s activities, you should be able to determine the commands run, the programs compiled, and sometimes even the names of remote accounts or machines that might also be involved in the incident. Be sure of your target, however, because this is potentially a violation of privacy for the real user of this account.
Obviously, an aware intruder will delete the file before logging out. Thus, this mechanism may be of limited utility. However, there are two ways to increase your opportunity to get a useful file. The first way is to force the logout of the suspected intruder, perhaps by using a signal or shutting down the system. If a history file is being kept, this will leave the file on disk where it can be read. A better second way to increase your chances of getting a usable file is to make a hard link to the existing history file and locate the link in a directory on the same disk that is normally inaccessible to the user, i.e. a root-owned directory. Even if the intruder unlinks the file from the user’s directory, it can still be accessed through the extra link.
Where is the history file for a user stored?