UNIX Hints & Hacks

ContentsIndex

Chapter 3: Security

 

Previous ChapterNext Chapter

Sections in this Chapter:

 

3.1 Delegating root to Multiple Admins

 

3.5 Permissions Levels

 

3.8 File Encryption

 

3.6 Protect root at All Costs

 

3.9 Clear and Lock

3.3 Monitoring root in the Password File

 

3.7 File Collecting

 

3.10 Power Tools

3.4 Vulnerabilities in UNIX

 

 

 

 

 

3.3 Monitoring root in the Password File

3.3.1 Description

3.3.1 Description

Verify that there are no new accounts with root's UID.

Example

Flavors: AT&T, BSD

Shells: sh, ksh

One way that root has been compromised in the past is by setting a normal user's account to have a UID of 0. If a normal user has a UID of 0, they have all rights and privileges that root has. Only root should have a UID of 0, unless you are implementing hint 3.1, "Delegating root to Multiple Admins."

Here is a simple script that scans through the password file searching for any UID 0 that does not belong to root. If one is found, an email is sent out to the administrator responsible for that system.

#! /bin/sh
for id in `awk 'FS=":" {if(($3 == 0 && $1 != "root" )) \ print $1}' /etc/passwd` do mail -s "Root Access Alert" root@rocket.foo.com << EOF
***************************************************************** * * ALERT! Login ID `echo ${id}` has uid 0 * `date "+Detacted On Date :%D Time :%r"` * *****************************************************************
EOF done

1. Begin progressing through the password file if the third field (UID) in the password file is a 0 and the first field (ID) is root, check the next line in the password file.

2.If the UID is 0 and the ID in the first field is not the account root or one predefined, send out an email message.

From:     root@moon.foo.com
Sent:     Thursday, September 24, 1998 2:50 AM
To:     root@rocket.foo.com
Subject:     Root Access Alert
********************************************************** * * Break-in ALERT! Login ID sach has uid 0 * Detected On Date :09/24/98 Time :02:50:07 AM * **********************************************************

3. Keep going through the list until the entire password file has been read.

This is a very unobtrusive script that can be set up in the crontab to run half-hourly, hourly, or daily, depending on your environment. An hourly crontab entry set to run at 15 minutes past every hour would look like this:

15 * * * * /usr/local/bin/checkroot /dev/null 2>&1

If there are multiple root accounts as described in hint 3.1, a modification to the first line of the script would look like this:

for id in `awk 'FS=":" {if(($3 == 0 && $1 != "root" && $1!= "root-xx" )) \
print $1}' /etc/passwd`

If you want to display the findings to the console at /dev/console, change the command line that sends the mail out to the administrator from

mail -s "Root Access Alert" root@rocket.foo.com << EOF

to the following line that uses the cat command to display the results:

cat << EOF > /dev/console

Reason

Monitoring root is part of the paranoia that an administrator must face if she wants to maintain a secure site. In many cases, those administrators who are not monitoring the password file or root are most likely setting themselves up to fail the security audits that parent companies often do in large installations.

Real World Experience

When you have over 100 workstations and servers to keep an eye on, this little script can really work. Before I began using this script, I partially failed one of the many security audits I have been blessed to receive. The programmers in my environment developed applications that required running with root permissions. They always manipulated sockets and tweaked the kernel.

They decided that it would be best to have a root level account named to the application. So an application called stucco had a UID of root 0. The problem with these programmers, like most dangerous users, was that they neglected to tell the admins and decided on their own to manually generate the account in the password file. Unfortunately, it didn't end there. They not only generated the account, but determined for the sake of convenience that a password shouldn't be on the that account.

Along came the security audit the next morning and-- pow!--I failed. Great timing. I decided to put this script into place and within the next six months I caught them four more times doing the same thing. This script is quick and dirty and does the job.

UNIX Hints & Hacks

ContentsIndex

Chapter 3: Security

 

Previous ChapterNext Chapter

Sections in this Chapter:

 

3.1 Delegating root to Multiple Admins

 

3.5 Permissions Levels

 

3.8 File Encryption

 

3.6 Protect root at All Costs

 

3.9 Clear and Lock

3.3 Monitoring root in the Password File

 

3.7 File Collecting

 

3.10 Power Tools

3.4 Vulnerabilities in UNIX

 

 

 

 

 

© Copyright Macmillan USA. All rights reserved.