Send in your Unix questions today!


See additional Unix tips and tricks



One of the things that every Unix systems administrator needs to know to properly manage a Unix system is who else is using the powers of root. Without that knowledge, it is not possible to be confident that the system's configuration will remain stable, that the cause of problems can be tied down to specific actions or who else might be given root access. It's also essential to know who is trying, but failing, to use the root account and who is using another user's account. Since one of the essential rules of any good Unix security policy is that no one knows another user's password, we probably want to know when this policy is being violated. If we can't be sure who is using each login, accountability on our systems in non-existent.



While a stealthy individual who has captured the root password will likely be adept at covering his tracks, more benign individuals who try to assume root control on a system will be revealed in the system's sulog file -- the system's record of all attempts by users on to execute the su command. Many Unix systems will log su activity to the sulog file by default. The locations of the sulog file depends on which type of Unix you are using. On Solaris, the location of the sulog file is specified in /etc/default/su and is /var/adm/sulog by default as illustrated in this snippet:

# SULOG determines the location of the file used to log all su attempts

#

SULOG=/var/adm/sulog



If you are working on a Linux system, check for a file named /etc/logins.defs that may define whether su logging is enabled. The default location for the sulog file on Linux systems is usually /var/log/sulog.

To give you an idea what sulog entries can tell you, let's look at a couple of sample entries:

SU 01/19 17:41 - pts/1 jdoe-root

SU 01/20 11:17 + pts/1 jdoe-slee




In the first record shown above, the user "jdoe" was unsuccessful at switching user to root on January 19th at 5:41 PM. We know this because the fourth field in the line is a "-" sign. If jdoe is one of the system administrators, this failed su attempt might not represent a problem. He might have simply forgotten or mistyped the root password. If jdoe is a regular user, on the other hand, we might want to find out why he was attempting to switch user to root. The following day, the same user was able to successfully switch user to "slee". So, either jdoe knows slee's password or slee, knowing jdoe's password, logged in as jdoe and then switched to her own account. Unless these two users are working closely together, this kind of access sharing goes against the grain of most security policies where activity like the following (switching to a shared account) might indicate that users are following the rules:

SU 12/22 13:44 + pts/3 jasper-noc

SU 01/07 11:53 + pts/3 raven-noc




If you don't roll over sulog files at the end of the year, you will have to look at the context of a record to determine whether a 01/11 su attempt happened this month or two years ago. Since the year is not included in the sulog records, each record by itself doesn't tell you when the su event occurred. It is probably too late to concern yourself with who was attempting to su to the root account three years ago, especially if you were not around at the time and you don't know who was authorized to use the system at that time, but recent activity can be an essential source of information about who is using and abusing your servers.

Because of the large number of records you are likely to find in an sulog file, the most productive way to examine sulog data is to summarize it in some way. The following script summarizes su activity by providing a count of each user-user transition (e.g., jdoe-root). The output of this script will look like this:

successful su attempts:
=======================
jdoe-slee:	49
shs-root:	80
slee-root:	1

failed su attempt:
=======================
jdoe-slee:	2
jdoe-root:	11

This script is a fairly simply Perl script that uses two hashes to keep track of the successful and failed su attempts. Switch user events are stored in records such as $success{jdoe-slee} and $failure{jdoe-root}.

The script is hard-wired to read the Solaris sulog file (/var/adm/sulog), so modify this if you are using another Unix OS or your sulog file is stored at some other file system location.

#!/usr/bin/perl -w

# hashes for accumulating counts
my %success;
my %failure;

open(LOG,"/var/adm/sulog") or die "Unable to open sulog: $!\n";

while (<LOG>) {
    ($trans) = /(\S+-\S+)/;
    if ( /\+/ ) {
	    $success{$trans}++;
	} else {
	    $failure{$trans}++;
    }
}

print "successful su attempts:\n";
print "=======================\n";
foreach $key (sort keys(%success)) {
    print "$key:\t$success{$key}\n";
}

print "\n";

print "failed su attempts:\n";
print "=======================\n";
foreach $key (sort keys(%failure)) {
    print "$key:\t$failure{$key}\n";
}

The variable $trans is pulling the "jdoe-slee" portions of each sulog record by matching on its format -- a string of characters followed by a hyphen and then another string of characters. If the record contains a + sign, we know the su command was successful and increment the $success{jdoe-slee} hash element; otherwise we increment the $failure{jdoe-slee} hash element.

At the end of the script, we sort and print the accumulated results by username.

Part 2 of this series looks at two variations on this script that allow us to focus in on attempts to su to root and summarize su activity by month.

ITworld.com

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine