security question

[Kelli Ward]

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

[harry d brown jr]

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

[James R. Ferguson · Accepted solution]

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...

[Kelli Ward]

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

[harry d brown jr]

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

[Paula J Frazer-Campbell]

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

[harry d brown jr]

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

[Kelli Ward]

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

[Jeff Schussele]

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

[harry d brown jr]

Kelli,

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

live free or die
harry

[Kelli Ward]

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

[Jeff Schussele]

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

[harry d brown jr]

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

[Joanne Keegan]

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

[Kelli Ward]

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

[Jeff Schussele]

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

[SHABU KHAN]

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

[Mark Fenton]

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.

[Steven Sim Kok Leong]

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