HPUX Securtity

[Joel Shank]

How do you secure your HPUX servers? We have several HPUX servers (D-, K- and N-class servers).

We know about secure shell and trusted systems. What third-party products are people using to secure HPUX? We do a lot of file transfers to/from mainframe and NT platforms, as well as between our UNIX servers.

Thanks for you help
jls

[harry d brown jr]

It depends upon how secure you have to make them. Are any of these servers internet facing? Are you using a "trusted" network?

Some things come to mind:

ldap/NIS+ for unix
ldap/ad for M$ stuff

bastille hosts: http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x4f9793e260b0d611abdb0090277a778c,00.html

to secure NT's -> power them off :-))

live free or die
harry

[Christopher McCray_1 · Accepted solution]

Hello,

Other than SSH and TCP wrappers, we do not use any other 3rd party products. From our standpoint,increasing security is through reduction of permissions of files/directories and the turning off of certian services ( remote services, snmp, etc). Also, keeping up to date with the various secrity patches also aids with this. You may want to look into the security_patch_check utility:

http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=B6834AA

Hope this helps

Chris

[Joel Shank]

None of these servers are internet facing. We currently are not using trusted systems, but will probably implement that soon. We are using Service Guard, and at one time you couldn't run SG with trusted systems. Now I understand you can.

We are also running SAP and I think I'll have trouble using NIS with SAP because SAP requires several different userids with the same UID (or that is what my BASIS folks tell me).

I am not looking to hardening these servers. Just keeping passwords from being sent over the network in clear text, and things like that. I'm also looking for somethng that will be easy to implement and transparent to use (I hope).

jls

[Christopher McCray_1]

Hello,

Yes, serviceGuard works very well with trusted systems:

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

Secure shell will relive you of your worries of passwds passed in clear text.

Remember, the security needs of your environment are determined by the applications you run and their ability to do so. You don't want to secure yourself out of productivity.

Chris

[John Dvorchak]

Something to look at is SSH to keep passwords from being clear text on the LAN.

Other things like a /etc/securetty file to keep root from logging on except from the console, thereby forcing root users to loging as themselves and su to root.

Enable trusted and enforce nontrivial passwords and expire them periodically, like every 60 days.

Use /etc/ftpusers and put accounts like root bin sys adm www etc in there.

We use SecurID here for passwords. That is a hardware software solution where every user gets a SecurID card and a pin number. The SecurID card has a random 6 digit number that changes every 60 seconds so the password would be the pin number followed by the SecurID number. Very secure as the passwords change every sixty seconds and it enforces single use on the password. So even if someone sniffed the password it will only work once.

By far the easiest and cheapest solution is the trusted system approach with non trivial passwords that expire every 45 or 60 days. Other than that remember that the only really secure system is one that is powered off.

[Jeff Schussele]

Hi Joel,

Other things to do are only allow RPC services that are required. Either limit access (inetd.sec) that are required to those users/hosts/subnets that need it or turn off (inetd.conf) services not required (nfs,tftp,finger,ntalk,ident,etc.)

Also setup ftp, sendmail & telnet banners with legal notices to protect the company in the event of unauthorized access or attempt.

Turn off anonymous ftp as well as turn on the novrfy & noexpn privacy options in sendmail.

And most importantly stay current on security related patches.

And it never hurts to run internal security checks against the server on a regular basis to verify just what is/isn't hardened.

Rgds,
Jeff

[John Payne_2]

If you are looking for 3rd party products, Computer Associates has a security suite called eTrust.

I am not sure about the price, but most of what they have there can be done through non-cost products, if you have the time and do not care about nells and whistles.

Hope it helps

John

[Bill Hassell]

NIS means: unsecure passwords, that is, the encrypted password is broadcast across the network by the NIS server, which is in total opposition to the concept of a Trusted System (shadow password file). So changing to a Trusted system will completely disable NIS for that box.

So you don't want NIS in any secure environment. (there is NIS+ which can coexist with Trusted Systems but it is a big pain to manage and every NIS client must support NIS+ as NIS clients are incompatible with NIS+).

I know of no SAP requirement to have different user logins share a single UID. Must be an application problem. Any security specialist will tell you that duplicate logins for a single UID is bad.

[Chris Wilshaw]

A few ideas:

You can employ sudo to allow people to have limited access to commands.

Another favourite of mine is to use aliases to redefine some commands - for example to prevent certain users from accessing commands that you don't want them to, set up aliases in their .profile (or whatever file is relevant) so that the commands actually just run /bin/true

The best way I've found to implement this is to define
ENV=$HOME/.kshrc in /etc/profile, then to add in the aliases in their .kshrc file so that the aliases apply even if they run a shell from within another command (eg. from vi).

It's often stated that most security breaches come from inside your own organisation (apart from anything else, the people there will probably have some access to your systems anyway, and in some cases they will have a reasonable grasp of IT). If you can, lock your users into a menu system, rather than giving them command line access.

For accounts that only need FTP access, set their shell to /bin/false so that they can't get command line access.

Use the restricted shells to allow limited access to the systems, rather than full shells.

Carry our regular audits of sulog, last and lastb output etc. You can't easily prevent things if you don't know they're going on.

[Wodisch]

Hi jls,

how about using "IPFilter/9000" to block off all unwanted access from the network (or even TO the network), including portscans?

FWIW,
Wodisch