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/“
