Hardening HPUX 11i and OS patches

[Co van Berkel]

Hi,
One rule for hardening a HPUX 11i system is to change all files who meed the following user, group and rights:
- owner bin;
- World read access;
- No SETUID;
- No SETGID;
- No World write access;
- No GROUP write access;
- No symbolic links;

find / ! -perm -4000 -a ! -perm -2000 -a ! -perm 0002 -a ! -perm -0020 -a -user bin -perm -0004 -a ! -type l -exec ls {} \;

Change these files to:
- Owner root

For so far al is oke.

But when I install a HP PATCH this patch will change all rights back to the "wrong" one's.
Does any body have a "goodpractise" / rule how to handle this?

1. Change after a PATCH installatie all files, including the ../sw/save/..?

2. Change all file but exclude the "../sw/save/.." files?

3. ??

Rgrds CvB.

[harry d brown jr]

You need CFENGINE: http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/cfengine-2.1.13/

It's a little complicated to get going, but once it's done, you're all set!

live free or die
harry d brown jr

[Andrew Cowan]

There are many OS patches out there for just about every type of platform and OS that have a nasty habit of setting things back to their "default" settings, and this can seriously compromise your system's security. I would recommend using Bastille for HP-UX to give you a good security baseline, and then invest in a product such as Tripwire or Vigilent or to track any changes made to your system.

[Gordon Morrison_1]

Go to
http://www.cisecurity.org/
and download their HP-UX Benchmark document.
It gives several recommendations for security-hardening HP-UX systems. It comes with a "scoring tool" that you can run before and after to get an idea how much your security has/could still be improved, and also comes with a permissions checking & fixing tool.

[Co van Berkel]

Hi,
What I want to know is of we change the changed/patched files and also the patch history files (../sw/save/...)?

When we don't change the (../sw/save/..) files but only change the patched files then the script "check_patches" says that there are differences!

What is the way to act?

Whe use the producte ESM of symantic to check oure systems.

RgRds CvB

[Andrew Cowan]

Tools such as ESM are designed to be very generic and thus tend to use a kind of a scatter-gun approach, thus they need a lot of work on the policy before they become effective.
You will find that ESM misses quite a lot of the security features of HP-UX.

[Emil Velez]

Between running security_patch_check tool to analyze your level of patches and the bastille supported product which will set a overall security policy and take care of the details mentioned in many of the replies you should be ok. That is the purpose of bastille and security patch check to give you a framework and proactive method of checking and applying your security policy consistently across multiple systems.

[Steven E. Protter]

There really isn't anything dangerous in ../sw/save

I would suggest:

cleanup -c 1

That will committ and clear out patches superseded once or more.

Bastille, HIDS and good policy is how we handle it at my shop.

SEP

[Keith Buck]

CvB,

While most of the items you mention are good things to look at when securing a system, applying the changes across the board is a very dangerous thing to do. Each change you make from the supported HP-UX configuration from installed media should be carefully considered.

In some cases, you can actually degrade the security posture of your system by these changes or worse yet, make the system completely unusable. Many of these situations are very subtle.

As a best practice, if you are not using software that is on your system, you should not install it (hence, you won't have to change ownership/permissions, and you won't have to patch it). Of course, this only covers some of the software that you are worried about, because some of it is part of the core operating system and cannot be removed.

Next, you should go ahead and use HP-UX Bastille as some have suggested. All of the changes it makes (except where clearly indicated) are supported and have gone through full release-level testing by HP to ensure that any breakages are well characterized.

At that point, you should look at the threats you are trying to address in your environment and decide on specific actions to take that address those threats. For example, I'm not sure what threat you are trying to address by removing symlinks...you might have a valid reason but I sure don't know what it is. A symbolic link has nothing to do with the permissions of the underlying data and rarely changes the security posture of the system.

After deciding to make any unsupported changes, put those changes into a script, and test your applications carefully to make sure they continue to function (remember that HP has not tested this configuration at all). You'll need to rerun the script after installing patches if you want the changes to remain in effect. The correct behavior for a patch is to restore permissions to their original (supported) configuration, but to leave user-configurable files (such as inetd.conf) alone.

Hope that helps.

-Keith

[Co van Berkel]

Hi to all,

I don't think my question is clear.
Sorry for my bad english...

We hardend oure systems after recomedations made in the "HP/UX Security Checklist".

One of the actions stated in this document
"move all ownership from bin to root" ...
- Command to use:
"find / ! -perm -4000 -a ! -perm -2000 -a ! -perm -0002 -a ! -perm -0020 -a -user bin -a -perm -0004 -exec chown root {} \;"

My question is now of this apply's for all filesystems or NOT.

Situation:
1. move all ownership from bin to root;
2. In time we apply one or more security patch(es);
3. After apply of security patch(es) we run the "move all ownership from bin to root" on ALL filesystems;

Question's:
- From that moment "check_pathes" will give a lot of error messages saying that file rights of the security patch(es) are out of sync/changed (../sw/save/...)?;
- What happens when we want to a undo one of more security patches?;

Rgrds CvB.

[Andrew Cowan]

I don't understand why you want to change the ownership in the first place? This will not enhance your security in any way since one of the greatest weaknesses of HP-UX is that it only checks the security entitlement of the user once the application is run. One example of this is "su". In Linux, AIX, and many others you can setup a wheel group and users cannot "su" to root without being in that group. In HP-UX this is not possible since the OS is based on SVR4 code, and this is the same reason why changing from "bin" to root will not help.
You are far better off making sure that bin has /bin/false as a shell and the login for the account is locked. You should also ensure that nobody is a member of group "bin" or "system" since these users effectively own the OS executables.

[Co van Berkel]

Hi Andrew Cowan,
Can you tell me what you meen?
I don't understand what you meen.

Do you say that HP-UX at first let everybody run every script/executable/.. and after it is started than the system? checkes of this is allowed or not?
What security implementation can this give?

R.E.
- User bin is, as all system-users, disabled and have a shell of /usr/bin/false.
- Only user root and bin are memebr of group bin;

Rgrds CvB.

[Andrew Cowan]

Hi Co,

You are correct that only "root" and "bin" should be members of group "bin". A common trick when compromising a system is to add a user to a privileged group such as "bin", "adm", "system", "root", etc, and then make use use of group privileges, which in some cases are set to be as strong as those of the owners.

In the case of "su" on HP-UX the default owner and group is "bin", and the permissions are set to world-executable. This means that any user who knows the password can become root. On an OS that was based upon the BSD kernel "su" checks to see if the user is in the "wheel" group, and if not will deny them access even if they know the root password. The only way to overcome this is to disable "su" by creating a new group (e.g. "wheel") and then set the permissions for "su" so that only members of this group can execute it. The only problem with this approach is that if you apply any OS patches they will either fail or reset the permissions of "su".

[Gordon Morrison_1]

HP-UX has an option similar to a "wheel group":
In /etc/default/security:
SU_ROOT_GROUP=root

This prevents any user that is NOT a member of group "root" from using su to become user root.
A user can belong to several groups - the SU_ROOT_GROUP doesn't have to be their primary group.

[Andrew Cowan]

Hi Gordon,

Is that a new feature of 11i as when I spoke to HP about this a while ago, I was told there was no way to do this?

Cheers,
Andrew

[Shantaram Sahyadri]

Hi,

I nice to hear a lot of things have been pointed out esp things about /etc/default security file, well since the patches installed are in SD format and swinstall command is used, swinstall has a option

Note: this is a rip off from man page

-x fix_explicit_directories=false

Controls the swinstall response to explicitly packaged software (software packaged with explicit file specifications). The default value of false causes swinstall to set permissions (as specified in the product specification file) on new directories but never on pre-existing directories. When set to true, swinstall also sets the permissions on pre-existing directories.

I have been using this option and seems to work quite well for me.
give it a try.

Cheers
Shantaram

[Gordon Morrison_1]

Hi Andrew,
As far as I know, it's a standard feature of HP-UX 11.xx (I don't know about previous versions)
But...
It is not turned on by default, and there seems to be no man page (man security) prior to 11i

Apologies to CvB and the Forum Moderators.
I know this isn't really the place to discuss side issues, but I don't know where else to post this, as a new thread might not be noticed by Andrew.
(Perhaps this is one of the things they'll address in the maintenance slot this weekend;o)

[Co van Berkel]

Hi Shantaram,
The defualt setting is:
"-x fix_explicit_directories=false"

On our HP-UX 11.0 systems we changed/hardend selected owner" bin files.
But after installation of an (security-) patch the file permissions of the files altered by the patch were changed back to owner bin!

How does this work then?

Rgrds CvB/

[Keith Buck]

CvB,

Can you give a URL to your "HP/UX Security Checklist"? It seems that some of the security recommendations you are following are questionable...maybe if we could read the original source it would clear things up. There are many such checklists out there (CIS, HP-UX Bastille, the old Bastion Host Whitepaper, etc.) and I'm not sure which one you are referring to.

Maybe that will help others help you.

(also, don't forget to assign points to those who have helped)

-Keith

[Co van Berkel]

Hi Kieth,
I got it from HP and it is only on paper.

We had two years ago a security scan done by HP and out of that this report is gome up.

Rgrds CvB.

[Co van Berkel]

No solution....

Close thread....

CvB