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:
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.
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
http://www.core-sdi.com/ENGLISH/CoreLabs/ssyslog/index.html
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.
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)
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.
Process accounting support has also been integrated into the new kernels. To use this feature, you'll need to get ftp://sunsite.unc.edu:/pub/Linux/system/admin/accounts/acct-1.3.73.tar.gz
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.
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:
/etc/group fileYou 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 ftp://sunsite.unc.edu:/pub/Linux/system/admin/accounts