Enterprise Audit Shell
Sarbanes-Oxley has forced many companies to start taking
UNIX security seriously. Not a big
deal. We all know how to secure a
UNIX server: disable unnecessary network daemons; remove unnecessary software
packages like compilers and debuggers; institute strict password and account
parameters; and search and destroy world-writable files. The only thing that eludes us is how to
secure and audit shell access.
This is where Enterprise Audit Shell (EAS) comes in.
There are many different types of access that are needed in
large companies: DBAs need access
to shared accounts for applications like Oracle and DB2; developers need to
migrate code and modify configuration files; contractors always need root
access for a day; support and
operations require root access; and engineers and architects need ad-hoc
access. Each type of access
requires its own method of security and there's no single tool to bridge the
gap.
Sudo plays a large role in allowing specific users and
groups specific access to system resources. The only problem is that sudo cannot audit what happens
inside a shell and all the information is forever lost. Because sudo plays a strong part in
access control, but lacks any audit information inside of shells, I felt that
sudo only solves 50% of the problem.
Seeing how UNIX is built upon the principle of solving only 80% of the
problem, I felt compelled to add an additional 30% functionality to sudo by
providing the missing audit trail.
Introduction
Enterprise Audit Shell is an audit framework specifically
designed to be used with sudo in large, enterprise environments. EAS starts where sudo leaves off, yet
takes advantage of what sudo does best: access control. Because EAS was designed as a
framework, it's completely transparent to the end-users and it allows the
System Administrator to add personalized extensions and plug-ins. EAS is broken down into three parts:
client, server and reporting.
The EAS client, eash,
is a very small program that uses UNIX pty devices to sit between a terminal
and a shell. Very similar in
function to the command script, eash logs the output from a shell and sends the data to a
central server via SSL. It's easy
to mistake eash as a real shell. It isn't. eash simply
spawns a real shell, such as /bin/sh
and logs the output.
The EAS server, easd,
listens for incoming eash client
connections - upon a connection the server will authenticate the client with
public and private keys; perform additional authentication if setup by the
System Administrator; and finally grant the client permission to send logging
data.
EAS reporting provides the who,
what, when, and where. Data is
stored in an embedded SQL database using SQLite. EAS reporting comes in three different types: login shells,
commands, and sessions. The login
shell type is when eash is executed as a login shell from /etc/passwd. The command type is when eash has been called with the –c argument, most common usage is eash being used as a login shell and the user executing a
remote command. The session type is when eash is called straight from the command-line.
Reports can be generated in two
formats: ASCII and HTML/CSS. The
tool eas_replay generates the ASCII
reports. In addition eas_replay can be used to snoop sessions in real-time or view
previously recorded sessions.
During the playback the administrator may use hotkeys to speed up, slow
down and pause the playback. The
tool eas_report generates W3C DTD
HTML 4.01 compliant HTML and it also uses CSS for formatting to allow the
System Administrator to completely customize the look and feel of the reports.
Logging Access
Using sudo and EAS together allow the system administrator
to obtain the level of the security and audit information required. Accounts such as oracle, db2 and patrol
can now be completely audited with sudo and EAS. Sudo provides the access control: who can do what – EAS
provides the audit trail: who, what when and where.
All shared accounts such as root, oracle, db2 or patrol
should be locked, if the operating system permits, and disable remote
access. Users must be required to
authenticate with an individual user account first, then elevate their privileges
to obtain access to shared accounts.
This policy ensures that the audit trail is maintained and direct access
to shared accounts is disabled.
Using sudo to setup the access control we wil allow any
users in the dba group access to the oracle account via eash.
%dba ALL=su
- oracle -c /usr/local/bin/eash
EAS provides the audit
information: who did what. All all
of the shell activity is sent in real-time to the central server and
archived. Members of the dba group may now use sudo to access the oracle account and EAS will take care of all the logging
transparently. Obviously typing su - oracle –c /usr/local/bin/eash would become tiresome, so it would be more beneficial to create a become shell script to do the work for you:
#!/bin/sh
if test $# -ne 1
then
echo
“Usage: $0 ID” >&2
exit
1
fi
sudo “su - $1 –c /usr/local/bin/eash”
Now
members of the dba group could simply
execute become oracle and it would
prompt for their password and upon successful authentication access would be
granted via eash.
$ id
uid=501(developer) gid=501(dba)
$ become oracle
Password:
[i] trying 192.168.1.100:5554 ... connected.
Awaiting EAS central server validation ... granted.
:~$ exit
(eash closed)
Using
this model of sudo and EAS combined the System Administrator can outline a
single and constant security policy for all varying types of access that's
required. Let sudo provide the
"who" and EAS provide the "what."
Reviewing Access
The tool eas_replay
is used to display and review access.
Without any arguments eas_replay will display a list of sessions.
Please note that actual session rows are displayed on stdout while the remaining text such as headers, lines and
hints are displayed on stderr. For example if the administrator just
wanted to see the raw sessions, one per line, you could send stderr to /dev/null.
# /usr/local/sbin/eas_replay
=============================================================================
Date (s1/\) From (s2/\) To
IP
Type ID
=================== =============== ===============
=============== ==== ====
2006-05-17 03:15:38 dhanks root
205.145.135.151 S 1
2006-05-17 03:15:49 dhanks root 205.145.135.151 S 2
2006-05-17 03:37:20 dhanks root
205.145.135.151 S 3
2006-05-17 03:37:28 dhanks root
205.145.135.151 S 4
=============================================================================
Sessions: 4
Commands: 0
Total: 4
=============================================================================
Playback usage: eas_replay ID [MULTIPLIER] [MAXWAIT]
Note: if you replay an active (R) session, snoop-mode will be
enabled.
Example: eas_replay 4
=============================================================================
#
To review a specific session you need to provide eas_replay the ID
of the session you which to play.
While in play-back mode you can use the following hotkeys:
+ increase
playback speed.
- decrease
playback speed.
1 reset
playback speed to normal.
q quit
playback.
Generating Reports
The tool eas_report
is used to create audit reports in HTML.
eas_report and eas_replay use almost identical options so that the report can
be “previewed” with eas_replay
and then used the same arguments to eas_report. The eas_report tool outputs HTML that is W3C//DTD HTML 4.01
compliant. The HTML reports also
use /etc/eas/css/detailed.css and
/etc/eas/css/report.css so that
you can customize the look and feel of the reports.
More Information
Download Enterprise Audit Shell http://download.strchr.net/
Enterprise Audit Shell at SourceForge http://sourceforge.net/projects/eash/
Enterprise Audit Shell Support Forum http://eas.strchr.net/
