monitor certain system accounts

[Todd Bowden]

Is there a tool that will monitor certain accounts on HP-UX? Can this be done with the Auditing feature for HP-UX?

We found a tool that goes along with sudo called sudoscript that basically uses a couple of Perl scripts with the "script()" call to monitor everything a person does after the point in which they do a "sudo su - ". What we found is that it's not working correctly on our systems for some reason. Once a person sudo's to the account they want to be in the user has to execute "sudo sudoshell" in order for the monitoring to begin. The problem was when the person logs out they leave these sudoscriptd processes hanging out there and then when someone else logs in they cant use the "sudo sudoshell" until the process is killed. Anyone else out there using sudoscript and have it actually working? Im not sure why its not cleaning itself up. Can anyone help?

TIA

Todd

[Darren Prior]

Hi Todd,

Auditing can be configured to monitor certain accounts, but it will produce a lot of logging unless you narrow down what you want audited. Take a look at the auditing man pages or http://docs.hp.com for more info.

regards,

Darren.

[Steven E. Protter]

It kind of depends what you want to monitor.

Auditing can monitor most things.

There is also simple monitoring you can do on bad logins or keystrokes. Keystrokes are done by the HISTFILE parameter in profile. logins I check by script.

Attaching....

SEP

[Todd Bowden]

Steven,

Thanks for the reply, but we are really looking to monitor what users actually do as other users (ie., oracle, root, etc.) when they sudo to these accounts. I know about the HISTFILE. I created a HISTFILE that logged to a different directory that kept a HISTFILE for that user, but the problem is is if they know about the HISTFILE they can just go and "cat /dev/null > $HISTFILE" and now we are left with no proof. Is there a way to do a tee in regards to the HISTFILE?

Todd

[Bill Hassell]

I assume that the need to montitor is that there have been mistakes made that no one will admit creating, or that you have some employee behavior problems. There is no reason for .sh_history to be zeroed except there is something to hide. So I would let everyone know that removing or zeroing the shell history file is a serious security violation. And for issues of accidental changes or buggy changes, setup a change review process and no single administrator is allowed to make the changes alone. Another admin must be present to provide a backup point of view, check spelling, look for potential issues, etc.

[Todd Bowden]

Bill,

You are exactly right. I too hate that it has come to this. That we have to monitor people because they either cannot own up to a mistake or are too stubborn to ask for help and think they need to circumvent the system in order to assist.

I have this tool called sudoscript found at:

http://egbok.com/sudoscript

Here is description of it:

Sudoscriptd/sudoshell are a pair of Perl scripts that provide an audited shell using sudo If you are familiar with sudo, you might well ask "doesn't running a shell under sudo defeat the purpose of the tool?" Yes and no. One reason for running sudo is to limit what commands can be run by users. These scripts do indeed defeat that purpose. But another reason to run sudo is to maintain an audit trail of commands issued by users with root privilege. These scripts preserve that audit trail by logging all terminal output to log files.

The problem with it is it starts up fine but when I try to execute another sudoshell it just hangs there waiting for a process to die. Im not sure why it doesnt work, but still trying to figure it out.

Todd

[Hazem Mahmoud_3 · Accepted solution]

Todd,
The native auditing feature in HP-UX works, but is a major system hog.
What I recommend is a application called Powerbroker, by a company called Symark (www.symark.com).
It's a very powerful application that allows auditing, resource restrictions, and real-time monitoring of what the user is actually doing. So you can actually see what the user is typing while they're typing it. It's really very powerful.

-Hazem

[Shaikh Imran]

Hi,
This can be done :
With Auditing Enabled through sam,You can use the following commands:
audusr (This command selects users to be
audited)
audevent (Display audit event status )
audmon (sets audit filesize parameters)
audisp (Displays the audit record )

The Audit data is securely stored in /.secure/etc/auditfile1
/.secure/etc/auditfile2

Hope this helps

Regards,

Imran Shaikh

[Bill Hassell]

The auditing in SAM works well, but the location for the log files (there are two which alternate back and forth as each one reaches a maximum size limit) are in the wrong locations (ie, /). Be sure to use audsys to specify new file locations and much larger file sizes as the amount of data collected can be rather lengthy.

[Todd Bowden]

Thanks to all I think Hazem hit on what I was looking for.