Security Checklist

[sivakumar_11]

Hello ALL,
G.M.

My Production Servers went Live, I want to know the basic security features to be set in my production servers and i want to know which system files to be backed up in tapes.

Could i convert my production server to trusted server?If so the procedures.

Thanks in Advance
tar
sivakumar

[Bill Hassell]

This task is quite detailed (several pages of steos to be taken, cautions to be heeded, decisions to be made, etc. I would start with reading the HP-UX 11i Security book by Chris Wong. Because your servers have gone live, it is too late to test security procedures including switching to Trusted mode. With well-behaved applications and databases, you can convert to Trusted by simply typing the commands:

/usr/lbin/tsconvert -c
/usr/lbin/modprpw -V

The first command converts the system to Trusted and the second changes the immediate expiration date to a refreshed expiration.

But now there are many questions to answer: Do your applications depend on a standard password system (ie, are they messing with the passwd file)? Do these applications require special ports or network services (daemons)? You need to look at your system logfiles regularly, ideally with special scripts.

Is your system connected to the open Internet? If so, I would srongly recommend getting professional consulting from and HP-UX security specialist--your system is very open. Another tool to use is Bastille which can be downloaded from software.hp.com and requires Xwindows. Bastille walks you through the steps to secure your system. NOTE: some changes may stop your applications from working. You need a test system to verify the changes.

As far backup, get a copy of Ignite/UX from software.hp.com and a copy of Data Protector for the data files. You'll need to read the man pages for both.

[Mic V.]

Sivakumar,

Security is not simple and what you do depends on your environment (including your management! :-). It's always good to test security changes on a development system (with management approval). That way, when there's a problem (and there always are), you are not hurting the business (and your career).

A few sources of interest (there are many) include:

- http://www.sans.org/
- http://www.securityfocus.com/
- http://www.atstake.com/

HTH,
Mic

[Zeev Schultz]

Ok,secure is a nice word but you should
define first What assets do you protect
and from Whom.

Make a list of vital files,directories etc.
Make a list of priviledged users. etc...
Thats what they call security policies.

If you're looking for all-in-one sollutions,
check Bastille (included with hp-ux 11i v2,downloadable from www.software.hp.com).

Usually,my minimal set includes:
1)ssh to cancel clear text passwords and .rhosts,build a group of trusted servers/users authenticated with public keys.

2)control services run by inetd
3)use su for priveledged users
4)use trusted system for passwords/logins
policies.
5)set needed permissions (rwx) on files/dirs
And so on...

[Gordon Morrison]

Rather than jumping straight into Bastille, first have a look at http://www.cisecurity.org/
I tried their HP-UX Benchmark recommendations on one test system, and Bastille on another for comparison.
Then I ran cis-scan (CIS's scoring tool) on both.
The CIS procedure (slightly modified for our environment) got this score:
Final rating = 7.81 / 10.00
The Bastille-hardened system got this score:
Final rating = 5.16 / 10.00
I also had problems with Bastille:
While Bastille is generally much easier to use, being a GUI that asks pertinent questions, then acts upon the answers, it has two major drawbacks:
1. Bastille forces password ageing on the root account, meaning the root password must be changed after running Bastille. Besides being inconvenient, this raises the risk of a password change being forced out of hours, when informing the people who need to know it could be problematic, and/or the password being forgotten as it had to be changed unexpectedly in the middle of the night. The root account is specifically excluded from password ageing in the CIS recommendations.
2. Bastille tends to be over-protective regarding file permissions â specifically it cannot be told to ignore NFS-mounted filesystems. As changing the permissions on the files and directories on these filesystems would affect users on several platforms, I had to comment out the changes to these filesystems in the Bastille-generated script, and there were hundreds of entries. (It wants to set the sticky bit on directories, but not on their contents.)

The only significant advantage of Bastille is that it creates a backout script that reverses all changes made by Bastille and the directory-perms.sh script, so backing out of the changes is easy (in theory - at least it worked for me).

Although the CIS document is in PDF format, I found that I could save it in .doc format, then cut & paste their commands into a script, thus allowing customisation and easy implementation on several systems.

To repeat previous warnings, all security changes should be looked at on a per-system basis. The CIS recommendations are only recommendations. Changes that would be appropriate for systemA might break systemB.
Obviously, all changes should first be tested on a non-production system, and always take a backup beforeha

[Robert Fritz]

Hi there,

I'd like to tweak a couple things in Gordon's message above.

> "1. Bastille forces password ageing on the root account"
Actually, Bastille does not force aging on the root account. It only ages the root account (and others) if you ask it to turn on password aging. I'd argue that the root account is the most critical, so therefore the most impotant to age.

>"2. Bastille tends to be over-protective regarding file permissions"
On HP-UX, Bastille doesn't change any file permissions. It does perform a directory permission audit. This in-turn produces a shell script Gordon referred to which must be edited and run manually. That editing step is the intended place to make the changes Gordon made. Also, concerning the sticky bit: the sticky-bit only has relevance for directories. Its use for files was never security-related and has been deprecated in Unix for some time.

Finally, I'd like to point out that Bastille produces a supported configuration, so that configuration has stability advantages. The Bastille team certainly looks at CIS for input, but we only add CIS lockdown elements when we are sure the result will be stable and supportable.

Thanks, and hope that helped,
-Robert