topic Re: security question in Operating System - HP-UX

security question

Kelli Ward — Wed, 27 Feb 2002 17:13:17 GMT

Hi,
Is there a good HP-UX "Snooper" program that will quietly watch (in the backround) what all users are doing?
Thanks,
Kel

Re: security question

harry d brown jr — Wed, 27 Feb 2002 17:35:17 GMT

Kelli,

maybe something like snort:

http://hpux.cs.utah.edu/hppd/hpux/Networking/Admin/snort-1.8.1/

but it won't help you with NON-TCP/IP connections. And the output from snort is ugly.

live free or die
harry

Re: security question

James R. Ferguson — Wed, 27 Feb 2002 17:43:06 GMT

Hi Kelli:

Depending on what you mean by "snoop", you may find DoubleVision potentially useful:

http://www.tridia.com/index2.html

The product permits a remote system to connect to another terminal, (tty or pseudo-tty), and have full access to its screen and keyboard.

Regards!

...JRF...

Re: security question

Kelli Ward — Wed, 27 Feb 2002 17:52:53 GMT

Thanks for the info.
Without going into detail, I'm not worried about network attacks, but rather internal "playing". Based on the way this particular setup works, users sign in generically, so seeing who by name, is not possible.
More info or program possibilities, if anyone, has them is appreciated. I will post points a little later.
Thanks,
Kel

Re: security question

harry d brown jr — Wed, 27 Feb 2002 17:56:12 GMT

Kelli,

Do you have mux strips with direct connect users or Network based users (like users using telnet, rlogin, rexec, ...)?

live free or die
harry

Re: security question

Paula J Frazer-Campbell — Wed, 27 Feb 2002 18:14:30 GMT

Hi Kelli

This type of login as you have found out has security problems.

Is it not possible to give each user their own login?

This by using top, ps and glance lets you know who is doing what.

The files wtmp, btmp and sulog all help to track users, but only really workable if they can be identified correctly.

I know it can be a lot of work but one user one login.

HTH

Paula

Re: security question

harry d brown jr — Wed, 27 Feb 2002 18:19:55 GMT

Kelli,

Do you want to "watch" what these generic logged in users are doing at the shell level or from within an application? How would you know which user is which, if a group of them share a user name?

live free or die
harry

Re: security question

Kelli Ward — Wed, 27 Feb 2002 18:43:57 GMT

I do know, boy do I know ;), about the security problems. Unfortunately, this particular group runs shifts and each shift has to continue the work of the previous shift on GUI based applications. If one user logs out, the next user can't continue the work, because the application doesn't transfer with their log in, hence the generic log in. If I could figure a work around for that. Everyone would have their own log in. If someone has a neat trick for this, I'm very willig to entertain the notion, but I know of none.
So, I'm stuck with being a big snoop! ;)
Thanks,
Kel

Re: security question

Jeff Schussele — Wed, 27 Feb 2002 19:04:46 GMT

Kelli,

Generic IDs are a very BAD thing :(

Is this an internally developed app?

If so I'd lobby hard to mgmnt to rewrite it to allow separate logins.
Seems awfully silly that you can't logout. What happens if the users lose connectivity? Do they lose all their work? I can almost hear the tick...tick...tick.... ;~) Fear is a great motivator for mgmnt - second only to $$$$$

Barring that, Harry's snort recommendation is your best bet I believe. You should be able to track activity, I think, by IP. Of course you'll need to round up workstation IPs & know what's/who's where (at all times).
Unfortunately he's also right that output is very "busy". But I think it can be tailored somewhat - at a minimum by perl/grep/sed/awk, etc.. It is definitely the sniffer of choice.

HTH,
Jeff

Re: security question

harry d brown jr — Wed, 27 Feb 2002 19:05:48 GMT

Kelli,

Can you keep them OUT of shells, because that's one of the biggest security violations.

live free or die
harry

Re: security question

Kelli Ward — Wed, 27 Feb 2002 19:49:44 GMT

Hi,
Changing or rewriting the application won't happen, even if I'd like it to.
I can look into removing "shell" access, but these guys are a very small percentage of the hundreds of systems/processes I oversee. I do not neccessarily have an intimate understanding of everything they need to do, although auditing this is not a bad idea. If I can, I just might.
Thanks,
Kel

Re: security question

Jeff Schussele — Wed, 27 Feb 2002 20:19:08 GMT

Kelli,

I definitely agree w/Harry & think he's on the right track here.
If they all use the same ID then set their .profile (or whatever their shell type/login method demands) to start the app & imediately exit upon app termination. If they can't bang out of the app then they'll never have a shell to "play" with!

If they complain you can tell them you'll give them a unique ID to login with if they need it for other purposes & they'll be very easy to "track" then. You'll also get some idea of what they're "doing" when you ask them WHY they need shell access.

Good idea Harry!.

Jeff

Re: security question

harry d brown jr — Wed, 27 Feb 2002 20:23:46 GMT

Kelli,

Of course you could give every operator their own logins and then make the "su" up to the generic account.

live free or die
harry

Re: security question

Joanne Keegan — Wed, 27 Feb 2002 20:57:06 GMT

Hi Kelli,

It depends on exactly you want to do...

I am currently testing IDS/9000 V. 2.0 which is supplied free by HP. This may be of some use. It is available on the Dec 2001 Application CD-ROM.

It is a configurable product, and will notify you of su, users creating and modifying file, etc. It is at least worthwhile looking at.

Regards,

Jo

Re: security question

Kelli Ward — Wed, 27 Feb 2002 22:24:24 GMT

JRF - Double Vision looks like a great program for so much more than just snooping. I'd really consider buying it, if I had control of the purse strings. (I'd also give 20 points if I could for suggesting it.)

Harry - I'm not sure I underdtand your last post, could you rephrase please?

Joanna - IDS/9000 looks like a great program. I'm looking into implementing it, but have one question.

Does anyone know if IDS/9000 requires the system to be converted to 'Trusted'?

Points to follow.
Thanks all,
Kel

Re: security question

Jeff Schussele — Thu, 28 Feb 2002 00:11:30 GMT

Kelli,

Harry's suggestion is kind of a follow-up to my last one.

The users would login to their unique ID then do:

#su - genericid

this launches a shell using the generic ID whose .profile you would modify, as I earlier noted, to ONLY run the GUI app you mention.

This way any commands they run would only be done with their unique ID & you can easily track them.

Jeff

Re: security question

SHABU KHAN — Thu, 28 Feb 2002 00:56:08 GMT

Hi Kelly,

To add to what Jeff and Harry had to say, Generic logins (application logins) are a bad idea as pointed out earlier by Jeff, so this is what I do in my enviroment:
Modify /etc/profile to not to allow direct logins using the Generic id or application logins like this (this should go on top of /etc/profile):
NAME=`logname`
if [ -z "`echo $NAME`" ];then
NAME=root
fi

if [ ${NAME} = genericid ] || [ ${NAME} = oracle ] || [ ${NAME} = corba ]
then
echo "\n\n\n"
echo "\t========================================================="
echo "\tApplication Logins Not Allowed. Please log in as yourself"
echo "\tand then \"su - ${NAME}\". Thank You"
echo "\t========================================================="
echo "\n\n\n"
sleep 5
exit
fi

Add this line to the Genericid's profile so that each user who login using the Generic application id (su - genericid after they login as themselves) will spawn their own history file:
# Each user will have their own history file.
HISTFILE=${HOME}/.history.${LOGNAME}.`logname`
HISTSIZE=1024;export HISTSIZE

So the history file after they login to the generic id would like :
-rw------- 1 siebel siebel 5098 Feb 27 16:58 .history.genericid.sxkhan

Hope this helps !

-Shabu

Re: security question

Mark Fenton — Thu, 28 Feb 2002 02:19:22 GMT

Kelli -- it sounds like you're stuck with really poor security policy due to management's decision to use an application that doesn't support collaboration.

The suggestions about using a real user login and suing to generic account would work for the first person to start work, but the next shift would come in and since the account was never logged out, they pick up with the previous user's credentials, and at this point, real logins would be even more of a disaster than generic!

Since you're stuck with generic accounts, they should be tightened down as far as practical, and the activity monitored/logged to afford at least SOME indication of who might be responsible. Snort, probably is you best (only?) bet.

ya gotta love it.

Re: security question

Steven Sim Kok Leong — Thu, 28 Feb 2002 07:09:43 GMT

Hi,

You can use CA Etrust (previously known as Platinum Autosecure) to restrict and audit superuser accounts (thus restricting and logging root). Requires a separate security administrator to administer the policies on superuser accounts.

The superuser (eg. root) cannot disable it, only the security administrator can.

Hope this helps. Regards.

Steven Sim Kok Leong