Access Intrusion -- A Suite of Tools
While UNIX systems administrators aren't worried about things
like the "CodeRed" or "I Love You" viruses,
a root access intrusion is a real threat. By minimizing the number
of people who know the root password, establishing a frequent regular
schedule to change the root password, and forcing a switch user
(su) to root, systems administrators may think that they have secured
their systems. However, someone who is not approved to use root
could still invade a UNIX system. This article will provide some
tools to help administrators detect and investigate possible intrusion.
If you are like me and have lots of systems to monitor, you know
it is time consuming to review sulogs, command-line history files,
and password files for root access intrusions. Monitoring UNIX files
with automated tools is essential for effective security. If you
have an HP 11.0 system, the free IDS/9000 Intrusion Detection System
may be worth using. If not, the following suite of tools can be
used by any UNIX admin for intrusion notification and investigation.
With more than six years of experience, and using the "Zen
of Sys Admin" (save the data, secure the system, and make the
users effective), I applied all of the measures that I learned in
UNIX security training and was confident that the possibility of
a breach was minimal. However, while working on a massive Y2K conversion
project that included more than 30 applications, application development,
and database consultants, I encountered a breach of security at
the root access level. Fortunately, the tools discussed here were
in place and disclosed the security breach, identified the intruder,
and proved which commands had been executed during the intrusion.
I received an email showing su's to root on a system had
transpired. I noticed that the username switching to root had no
right to root access, so I went to the directory containing each
root login command-line history. I had the username, time, and date
of the person switching to root. I opened this history file to view
the command lines executed by the intruder and found that this person
was logged in as root and had entered a command of vi /etc/passwd.
I immediately went to the /etc/passwd file and found an additional
entry for root with a different username. This is a sys admin's
nightmare -- the system had been breached, and the intruder
had created a root "back door".
Upon further review of the root command-line history and home
directories .sh_history, as well as checking out the system,
the only damage shown was the creation of the root back door and
some permission changes to database files. I copied the /etc/passwd
file, removed the root back door from the active /etc/passwd
file, changed the root password on all of the systems, and printed
out my evidence from the saved password file, pertinent history
file, and the sulog file.
After removing the security holes, I gathered the evidence and
informed the IT Director. With all of the evidence from these tools,
the IT Director had no choice but to let this user go. The IT Director
was impressed with my proactive method of proving an improper root
access intrusion and rapid system recovery after the breach. There
were still lessons to be learned from this incident, however, and
I immediately created a way for the system to notify me of any root
back doors added to the /etc/password file.
The tools described here have not been tested on a Linux box,
but they should work with some script tweaking. The methods have
been tested on IBM AIX, HP-UX, and Solaris platforms for this sample.
Here is the setup:
Step 1: Forcing an su to root
For all of these tools to work, you must prohibit users from logging
in as root. In other words, you must force users to access root
through the su - command. This will cause an entry in the
/var/adm/sulog, which will provide the name of the user trying
to breach root access security. It will also create a separate file
in a specified directory that contains the intruder's command-line
history (explained in step 2). If you choose not to force su
- to root, the notification tools can still be used (steps 3
and 4). The following methods will force an su to root, making it
so that a direct login as root can only be done at the console.
AIX: You can use SMIT, security users, change user for root, and
mark remote login to be "false". If you are using NIS
on your systems, I recommend investigating this further because
SMIT will use the "change user command" (chuser).
The chuser man page recommends not using this command if you are
running NIS because chuser only changes local files, not
HP-UX: Create the file /etc/securetty and add the word
CONSOLE. Change permission on the file by doing a chmod
600 /etc/securetty, thereby requiring root access to change
Solaris: Ensure the entry CONSOLE=/dev/console is placed
uncommented in the /etc/default/login. Permissions to the
/etc/default/login file should be set so that no one can
change this file except root, but the file can be read by all. You
may try chmod 444 /etc/default/login.
Step 2: Capturing Individual root Login Command-Line History
To catch an intruder and the commands he executes, root's
.profile must be revised to include the creation of separate
command-line histories for each root login. This is accomplished
by adding the script in Listing 1 and setting the login shell to
be the Korn shell (ksh) in the /etc/passwd file.
Solaris: You can place the login shell of /bin/ksh in the
/etc/passwd, replacing the default of /sbin/sh. Don't
make the mistake (as I did) of typing /sbin/ksh -- this
is an invalid shell and you won't be able to log in as root.
Be sure to close down root's .profile permissions
by doing a chmod 700 .profile so that root is the only one
who can change or read root's .profile. This keeps everyone's
command-line histories separate while using the Korn shell esc
k command-line history option. If the user or intruder does
not use the su - when switching to root, these command-line
histories will be kept in the intruder's home directory (.sh_history)
file. This makes intrusion investigation difficult (if not impossible),
because the intruder can clean up his .sh_history file. If
this is a critical point and educating users to enforce the su
- is unmanageable, you may choose to use the sudo tool
for regular users wanting root access for specific purposes, and
enforce the su - for the admins only.
In this sample, I use the directory name /var/adm/hist,
since other system logging is kept in /var/adm. You can use
any name for the directory name. Be sure that you chmod 777
the directory so that everyone has write permission. I also did
a chown root:sys /var/adm on AIX and HP, and root:other
for Solaris. The file name consisting of the su entry and date:time-year
(rthorne-root@13:42:20-021302) is necessary for pinpointing
and proving the intrusion. Don't forget to set a root crontab
entry to clean out the hist files, which accumulate and take
up space. I set my root crontab to remove any hist files
over 30 days old, because I should know if a root access breach
has occurred before that time elapses.
Step 3: Notification of su Activity
Listing 2 checks the /var/adm/sulog file for su's
to root attempted for this date and reports them via email. Remember
that a plus sign (+) in the sulog means a successful su, and a minus
sign (-) means an unsuccessful su (but it still needs investigation).
The reporting function can be changed to the method by which you
want to be notified. I have made an entry in the /etc/mail/aliases
file for sysadmin2, but you could hardcode the notification
address in the script. Place an entry in the root crontab file to
run this script on the frequency of your choice, but run it before
midnight because it checks for su's for today's date.
In this sample, I have simply called this entry security.chk.
Keep in mind that an intruder may check the crontab for anything
checking for intruders.
Solaris: For the grep -e to work, you must have /usr/xpg4/bin
in the root .profile PATH or hardcode this entry in your
script (grep `date +$m/%d` /var/adm/sulog | /usr/xpg4/bin/grep
Step 4: Checking the /etc/password File for Root Back Doors
In Listing 3, the password file will be searched for root back
doors. As in step 3, you can be notified in any manner. I choose
to be paged when a back door has been detected. I have also placed
an /etc/mail/aliases entry for sysadmin-page, but
you can hardcode the notification address in the script. Place an
entry in the root crontab file for the frequency that you would
like to be notified if any root back doors are found. Remember to
name this script so that the intruder isn't aware of the check
for root back doors while reading a crontab listing. There are some
sys admins who have root back door passwd entries for administration
reasons. If you are one of those, be sure to change -gt 1
to the number of root passwd entries that is normal for your site.
AIX: Change the count line in the script to be the :0:0:,
which is the UID/GID of root. By only looking for :0:, the
script could report erroneous findings.
HP-UX: Change the count line in the script to be :0:3:,
which is the UID/GID for root, because some systems use the UID
of 0 for the user system.
Solaris: Change the count line in the script to be :0:1:,
which is the UID/GID for root, because some systems use the UID
of 0 for the user system. For the grep -e to work, you must
have /usr/xpg4/bin in the root .profile PATH, or hardcode
this entry in your script as shown in step 3.
I hope that you find these tools useful. Proactive security notification
tools help keep you informed when there is a root access intrusion
on your system, but I also hope you never need to use the information
that these tools can give you. That would be a sys admin's
Rhonda Thorne has been working for more than nine years as
a UNIX sys admin. She holds several certifications in IBM AIX and
HP-UX and is working on the Solaris SCSA certification. Rhonda is
currently working with Solectron Global Services in Memphis, Tennessee.
She can be contacted at: email@example.com.