Recipe 9.6 Checking for Suspicious Account Use, Multiple Systems

9.6.1 Problem

You want to scan multiple computers for unusual or dangerous usage of accounts.

9.6.2 Solution

Merge the lastlog databases from several systems, using Perl:

use DB_File; use Sys::Lastlog; use Sys::Hostname; my %omnilastlog; tie(%omnilastlog, "DB_File", "/share/omnilastlog"); my $ll = Sys::Lastlog->new( ); while (my ($user, $uid) = (getpwent( ))[0, 2]) {         if (my $llent = $ll->getlluid($uid)) {                 $omnilastlog{$user} = pack("Na*", $llent->ll_time( ),                                            join("\0", $llent->ll_line( ),                                                         $llent->ll_host( ),                                                         hostname))                         if $llent->ll_time( ) >                                 (exists($omnilastlog{$user}) ?                                         unpack("N", $omnilastlog{$user}) : -1);         } } untie(%omnilastlog); exit(0);

To read the merged lastlog database, omnilastlog, use another Perl script:

use DB_File; my %omnilastlog; tie(%omnilastlog, "DB_File", "/share/omnilastlog"); while (my ($user, $record) = each(%omnilastlog)) {         my ($time, $rest) = unpack("Na*", $record);         my ($line, $host_from, $host_to) = split("\0", $rest, -1);         printf("%-8.8s %-16.16s -> %-16.16s %-8.8s %s\n",                 $user, $host_from, $host_to, $line,                 $time ? scalar(localtime($time)) : "**Never logged in**"); } untie(%omnilastlog); exit(0);

9.6.3 Discussion

Perusing the output from the lastlog , last, and lastb commands [Recipe 9.5] might be sufficient to monitor activity on a single system with a small number of users, but the technique doesn't scale well in the following cases:

• If accounts are shared among many systems, you probably want to know a user's most recent login on any of your systems.

• Some system accounts intended for special purposes, such as bin or daemon, should never be used for routine logins.

• Disabled accounts should be monitored to make sure they have no login activity.

Legitimate usage patterns vary, and your goal should be to notice deviations from the norm. We need more flexibility than the preceding tools provide.

We can solve this dilemma through automation. The Perl modules Sys::Lastlog and Sys::Utmp, which are available from CPAN, can parse and display a system's last-login data. Despite its name, Sys::Utmp can process the wtmp and btmp files; they have the same format as /var/log/utmp, the database containing a snapshot of currently logged-in users.

Our recipe merges lastlog databases from several systems into a single database, which we call omnilastlog, using Perl. The script steps through each entry in the password database on each system, looks up the corresponding entry in the lastlog database using the Sys::Lastlog module, and updates the entry in the merged omnilastlog database if the last login time is more recent than any other we have previously seen.

The merged omnilastlog database is tied to a hash for easy access. We use the Berkeley DB format because it is byte-order-independent and therefore portable: this would be important if your Linux systems run on different architectures. If all of your Linux systems are of the same type (e.g., Intel x86 systems), then any other Perl database module could be used in place of DB_File.

Our hash is indexed by usernames rather than numeric user IDs, in case the user IDs are not standardized among the systems (a bad practice that, alas, does happen). The record for each user contains the time, terminal (ll_line), and remote and local hostnames. The time is packed as an integer in network byte order (another nod to portability: for homogeneous systems, using the native "L" packing template instead of "N" would work as well). The last three values are glued together with null characters, which is safe because the strings never contain nulls.

Run the merge script on all of your systems, as often as desired, to update the merged omnilastlog database. Our recipe assumes a shared filesystem location, /share/omnilastlog; if this is not convenient, copy the file to each system, update it, and then copy it back to a central repository. The merged database is compact, often smaller than the individual lastlog databases.

An even simpler Perl script reads and analyzes the merged omnilastlog database. Our recipe steps through and unpacks each record in the database, and then prints all of the information, like the lastlog command.

This script can serve as a template for checking account usage patterns, according to your own conventions. For example, you might notice dormant accounts by insisting that users with valid shells (as listed in the file /etc/shells, with the exception of /sbin/nologin) must have logged in somewhere during the last month. Conversely, you might require that system accounts (recognized by their low numeric user IDs) with invalid shells must never login, anywhere. Finally, you could maintain a database of the dates when accounts are disabled (e.g., as part of a standard procedure when people leave your organization), and demand that no logins occur for such accounts after the termination date for each.

Run a script frequently to verify your assumptions about legitimate account usage patterns. This way, you will be reminded promptly after Joe's retirement party that his account should be disabled, hopefully before crackers start guessing his password.

9.6.4 See Also

The Sys::Lastlog and Sys::Utmp Perl modules are found at http://www.cpan.org.

Perl for System Administration (section 9.2) from O'Reilly shows how to unpack the utmp records used for wtmp and btmp files. O'Reilly's Perl Cookbook also has sample programs for reading records from lastlog and wtmp files: see the laston and tailwtmp scripts in Chapter 8 of that book.