Ways to monitor user commands

[MAD_2]

I have pondered over this for a few weeks now, and found the following:

1. Using auditing is not feasible. Audit logs build up way too quickly and management/administration of filesystems becomes a big headache.
2. Furthermore, while having auditing on, way much more information than what I would actually like to collect is being recorded. Also, exporting this information from the audit logs/creating reports/creating a file that is a little less "cryptic" becomes a real work of art.

I would like to hear some suggestions on how to do this with the following in mind (if anyone has experimented with this scenario in the past):

1. Would not like users to have access to the copy of the history file that is being created with time stamps as to make changes to it nor to be aware this is taking place.

2. The same scenario described by Maurice Petersen in the forum below is similar to what I am trying to achive (I think):

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x059de7e60861d511abcd0090277a778c,00.html

3. One of major problems I have encountered is applying a time stamp to commands, and using 'script' does not seem to be an alternative either.

4. By adding the following to the /etc/profile, I can sort of get something of what I would like to have, but I would prefer a time stamp for each command, or to remove during each user's session the time stamp included in his/her history file, so that it will not become obvious something else is taking place:
============================================
DATE=`date +%Y%m%d`
TIME=`date +%H%M`
HISTFILE=$HOME/.sh_history
export HISTFILE
echo "in: $DATE.$TIME" >> $HISTFILE
============================================

5. With the above, what I would like to add is copying just the current session's commands to another directory the user has no access to, and as mentioned before, also remove the "$DATE.$TIME" stamp from within his/her .sh_history file during the current session right before exit or every set period of time.
i.e. create a copy of the file in a different location (leaving all previous history in the user's history file intact, and copying only from the current session on), to another location, let's say:
USERHIST=/tmp/.security/history/$LOGNAME.$DATE_$TIME
Where the DATE=YYYYMMDD, and TIME=HHMM, so that the file could be used to create some sort of report with specifics about the user.

I hope I did not confuse anyone with all of this rambling.

Thanks!

[Sridhar Bhaskarla]

Hi,

It is not possible to achieve 100% solution using the standard user id and file permission methods. For ex., the user needs to have write access to the history file which may defeat the whole purpose.

If you are not happy with auditing, you may want to try some third party products. The product that I worked on and that satisfied me is CA's eTrust Access Control. Try reading it's documentation on CA's website.

-Sri

[Bill Hassell]

Unix is not designed for untrained or undisciplined users (which is usually the reason that auditing is required). The shell gives far too much capability to users so the only solution is to replace the login shell with a menu program. This would essentially be a very simple user interface for specific commands (and perhaps limits on options and parameters, similar to sudo). This program would then log all activities.

If the need for logging activities is for the root user, then the solution is easy: sudo will log every task that is allowed on a per-user basis, and no one needs to know the root password. In fact, you can disable the ability to login as root using the securetty file (man login).

[MAD_2]

Sridhar:

Do you have the link to "CA's eTrust Access Control" product? Also, can you give me some insight about pricing (just round about ideas; when did you acquire it, about how much it cost, etc.)

Thanks!

[Robert-Jan Goossens]

Hi,

Take a look at next link from CA,

http://www3.ca.com/Solutions/SubSolution.asp?ID=4348

Hope it helps,

Robert-Jan.

[Gustavo_20]

Hi all,
I was thinking about it. I don??t find an easy solution using the standards tools. But, what about the following:

You could move the /usr/bin directory to /usr/bin/binOK. Then (using a script) you should build each binary command that appears in /usr/bin/binOK and put it in /usr/bin.
The skeleton of each "new" command would be:

For example, let??s suppose the "ls" command:

/usr/bin/ls:

#!/bin/sh
time >> ~/.sh_history or
time >> /users/$LOGNAME/commands/cmmddyy.log
/usr/binOK/ls $*

One of the problem i found here is that if the users changed the PATH variable this solution wouldn??t be viable. But if your users aren??t trained enough, i think it could help.

[Shannon Petry]

Frankly, this is not easily achieved. There are drawbacks to many tools, I.E. auditiong, script, etc... but not where a smart user could not figure out what was going on.

What I have done at several sites, is created my own wrappers to launch specific programs, and make calculations on the fly, and dump that data to my own logs. I.E. netscape, normally installed in /opt/netscape

mv /opt/netscape/netscape /opt/netscape/netscape.bin
touch /opt/netscape/netscape
chmod 555 /opt/netscape/netscape

Now edit the new netscape
#!/usr/bin/sh
LOG=/var/adm/logs/ns_run.log
if [ -f $LOG ] ; then
echo "" >>/dev/null #fall through
else
touch $LOG
fi
I_AM=`who am i`
LONG_DATE=`date`
echo "$I_AM $LONG_DATE /opt/netscape/netscape.bin launch" >>$LOG
set -i
CUR_MIN=`date +%M`
CUR_HR=`date +%H`
#launch our binary
/opt/netscape/netscape.bin $*
# now figure our run time before close
works
NEW_MIN=`date +%M`
NEW_HR=`date +%H`
if [ $NEW_HR -lt $CUR_HR ] ; then
NEW_HR=`expr $NEW_HR + 24`
fi
if [ $NEW_MIN -lt $CUR_MIN ] ; then
NEW_MIN=`expr $NEW_MIN + 60`
NEW_HR=`expr $NEW_HR -1`
fi

HR_TOT=`expr $NEW_HR - $CUR_HR`
MN_TOT=`expr $NEW_MIN - $CUR_MIN`

echo "$I_AM ran netscape for $HR_TOT hours and $MN_TOT minutes" >>$LOG


Now it may become tedious, but pretty much I only need to watch certain apps, and certain users. This limits my logging, and makes it where I do what I want.

Users really dont see what's going on unless you mess up the wrapper or log.

Regards,
Shannon