Super user acttivity audit

[Mario Behring]

Hi list,

I have to implement some kind of super user auditing and configure all HPUX servers not to permit direct root logon.

I know I can accomplish some of this using sudo and configuring the OS so that the root user cannot logon...but I would like to know if is there any HPUX utility or third party application that could give me more control and more information about what each superuser is actually doing...

Any help is appreciated.

Mario

[Patrick Wallek]

There is a product called Power Broker that can do what you want.

http://www.beyondtrust.com/PowerBroker-Servers-Unix.aspx?section=PowerBroker-Servers-Unix

[Alzhy]

The BEST out there is a combination of SUDO and Enhanced Korn Shell (eKsh). And it is really all about capturing user activity.

eKSH or ksh93 allows you to save that shells histoy file to multiple off-site (or local), non-volatile, non-editable (WORM) storage.

configure ksh93 to suite your needs
build/install
restrict root logins to console
set up sudo ("sudo -s -E" only for admins)

This has proven valuable for both the Admin and Governance in "investigating what happened".

[Rita C Workman]

There is reason why you have the 'root' account. What if you had a problem on the server and you need to be able to login as root to fix it...but now you can't.

I'm all for security, but I see problems with this line of thought. Some software requires the root account to perform certain functions, not an su to root, but root.

There are some third party softwares out there that will log all keyboard entry and output to a file for you to review. Powerbroker/Symark is one I'm aware of. You can use it on an adhoc basis so you don't wind up with extreme amount of logfiles that nobody ever looks at. So you might just track those 'super users' accounts.
If someone has to be 'root' then Powerbroker might work, but if not they could be required to run 'script' and that would then put their keyboard for the activity to a file.

Just a couple thoughts,
Rita

[Alzhy]

This is the official download/build site of eKSH:

http://www2.research.att.com/sw/download/

[Alzhy]

Ma'm:

Most corporates these days have a standard of:

1) restricting root access to the console
2) super user fine grained access (RBAC)
3) restrictive FULL root access via SUDO
4) trackable activity (to protect us ADMINS primarily -- beleieve me it is to OUR advantage!)

(4) above is best achieved via AT&T's enhanced korn shell (aka ksh93). It not only allows you to track what you've done but builds your own knowledgebase and protect you from suspicious colleagues and governance)


In fact, I've already seen FULL CHANGE control processes in place for ANY root access. Even Physical Access to servers requier change control.

Emergencies you say? Yep an admin can still access readily the OS/its tools -- but the most important thing here is TRACKED access - for their and OUR protection.

Cheers!

[Alzhy]

More:

The riskiest thingy on any UNIX and UNIX Like Operating system is its master being logged in on the root command line.

As anything can happen HOWEVER responsible we think we are:

Issues like:

- accidental PASTE of a nasty command
- accidental PASTE of a CLIPBOARD that contains commands detrimental to the OS
- accidental recall and exec of a SHUTDOWN command
- accidental recall and exec of a nasty rm command
-- the list goes on and on.

;^))

[Rita C Workman]

Alzy, I too agree with standards - I agree with being secure - most definitely Sir.

I took his statement "..configure all HPUX servers not to permit direct root logon." as attempting to even inhibit login at even including the console.

There is a point to where you can be so safe you cripple an admin's ability to do a job.

My biggest concern for systems anymore seems to be in the fact that too many untaught, unwilling to open a book and learn, "somebody tell me how to do my job that I can't even explain effectively what the problem is", are sitting behind keyboards with the title UNIX Administrator.

Now that to me is the biggest security threat problem. And all the logs in creation will not protect those systems or those businesses who have chosen to follow the careless route of hiring the unqualified because it's cheaper...or better yet - outsourcing.

Like others, I do try to be good and sudo as a rule, but I must admit that I too have logged in as root and fixed something from the command line when I had to.

Kindest regards,
Rita

[Hakki Aydin Ucar]

Hi,
a native approach might be ;

allow/deny root logins with /etc/securetty

[Hakki Aydin Ucar]

http://www.faqs.org/docs/securing/chap5sec41.html