Next Previous Contents

5. User, System, and Process Accounting

All Linux systems support system-wide process, user, and system accounting, and it is wise to take advantage of it. You will need this information when troubleshooting a possible security incident, and your ability to address all aspects of a specific incident strongly depends on the success of this analysis.

There are quite a few things, as the Security Administrator, of which you should be aware. These include at least the following:

5.1 Using Syslog

The system daemon called syslog is the program used to log system events such as kernel messages, login or logout messages, general system messages, etc.

Be sure to keep an eye on its normal operation and what gets written to it's log files, especially under the ``auth'' facility. Multiple login failures, for example, can indicate an attempted break-in. Keep in mind that the lack of information does not indicate the opposite.

Where to look for your log file will depend on your distribution. In a Linux system that conforms to the ``Linux File-system Standard'', such as Red Hat, you will want to look in /var/log and check messages, mail.log, and others.

You can find out where your distribution is logging to by looking at your /etc/syslog.conf file. This is the file that tells /usr/sbin/syslogd (the system logging daemon) where to log various messages.

You might also want to configure your log-rotating script or daemon to keep logs around longer so you have time to examine them. Take a look at the logrotate package in recent Red Hat distributions. Other distributions likely have a similar process. It seems that many distributions default to only logging the most basic information, so you should spend some time and customize it for your environment.

If your log files have been tampered with, see if you can determine when the tampering started, and what sort of things they appeared to tamper with. Are there large periods of time that cannot be accounted for? Checking backup tapes (if you have any) for untampered log files is a good idea.

Log files are typically modified by the intruder in order to cover his tracks, but they should still be checked for strange happenings. You may notice the intruder attempting to gain entrance, or exploit a program in order to obtain the root account. You might see log entries before the intruder has time to modify them.

You should also be sure to seperate the ``authpriv'' facility from other log data, including attempts to switch users using /bin/su, login attempts, and other user accounting information.

Storing Log Data Securely

It is also a good idea to store log data at a secure location, such as a dedicated log server within your well-protected network. Once a machine has been compromised, log data becomes of little use as it most likely has also been modified by the intruder. It most likely of little value in a criminal investigation. It helps if the log data, which has been stored remotely, indicates when root access was gained so that logs before that point are okay.

The syslogd daemon can be configured to automatically send log data to a central syslogd server, but this is typically sent in cleartext data, allowing an intruder to view data as it is being transferred. This may reveal information about your network that is not intended to be public. There are syslog daemons available that encrypt the data as it is being sent.

Also be aware that faking syslog messages has been reported, with an exploit program having been published. Syslog even accepts net log entries claiming to come from the local host without indicating their true origin. A more secure implementation has been written by CORE-SDI, and is available at

If possible, configure syslogd to send a copy of the most important data to a secure system. This will prevent an intruder from covering his tracks by deleting his login, su, ftp, etc attempts. See the syslog.conf(5) man page, and refer to the ``@'' option.

If you've already decided to use a central syslog server, the additional security this provides is well worth it. However, you should consider the additional overhead involved with sending this data real-time across your network.

5.2 Using User Accounting

User accounting can be used to discover information about who is currently using the system. While you cannot necessarily verify the integrity of this information once your machine has been exploited, it can be a useful tool to track the systems a particular user has logged into, what time he or she logged in, when the system was last rebooted, etc.

There are also utilities available for locking There are several tools available to process this information, including last(1), who(1), ac(1), utmpdump(1) (typically for debugging only), among others.

For example, using the /usr/bin/last command, you can view quite a bit of information about your system:

root     tty1                          Fri Jul  3 21:02   still logged in
reboot   system boot                   Fri Jul  3 21:01  
dave     ttyp2        localhost        Wed Jul  1 23:11 - 23:11  (00:00)
david    ttyp2        localhost        Wed Jul  1 22:47 - 22:47  (00:00)
The last(1) command, which shows a listing of last logged in users, and lastb(1), which shows a listing of failed login attempts (assuming /var/log/btmp exists), both consult the /var/log/wtmp file, which contains the following information:

See the man page for wtmp(5) for a description of any of the fields you do not understand.

The file /var/run/utmp is the file that is consulted to find out who is currently on the system (and primarily used by the who(1) command). However, there may be more users currently using the system because not all programs use utmp logging. This file is typically truncated upon each system boot, by one of the /etc/rc.d/rc.* files. Be sure this file is not writable by users other than root, as it is possible to insert or delete entries from this file otherwise. This file really serves very little purpose.

Finally, log files are much less useful when no one is reading them. Take some time out every once in a while to look over your log files (especially when you suspect an unauthorized visitor), and get a feeling for what the look like on a normal day. Knowing this can help make unusual things stand out.

5.3 Using Process Accounting

Process accounting support has also been integrated into the new kernels. To use this feature, you'll need to get

It no longer requires patching the kernel for this ability. This package includes several program to manage the kernel-level functions, including:

It really works quite well, and is highly recommended for systems that have a large number of users.

5.4 Managing User Accounts

Having control over the resources and data your users have access to is an essential part of maintaining security. Linux provides a large number of tools including account permissions, passwords, account aging, adding and deleting of users, etc.

Some of the programs you should become familiar with to manage users and groups include:

You can read the online manual pages for these commands using a syntax similiar to the following:

                user@myhost# man 8 pwunconv

This refers to pwunconv in section 8 of the manual pages.

You can find additional account management packages at

Next Previous Contents