Security Best Practices

[Joanne Keegan]

We are involved in a security review, in particular the use of root and other super user access to the systems. Does anyone know of any whitepapers, etc. that has information of best practices.

I have seen numerous articles on other aspects of security, but not this.

Your advice will be appreciated.

Thanks,

Jo

[Philip Chan_1]

Some of my ideas to share with you.

- root needs to be accountable, this mean only ONE person will know its password and who is responsible for it.

- seal the root password onto an envelop and give it to your boss for emergency situations which the root user cannot be reached, this envelop should be updated every time the root password being changed.

- establish a policy to change root password periodically, say, every 3 months.

- if other people needed to run root specific commands, setup sudo for this and grant only minimum authority.

- disallow straight login to root by setting up /etc/securetty with single test line "console".

Rgds,
Philip

[FRED Dennison]

Jo,

have a look at the following link. It is for HP-UX Online Internet Training in a virtual classroom. HP-UX Security Course is near the bottom. Cost is low ($129 US) relative to OpenView in New Orleans, but don't let the boss know! I have tested the virtual classroom and it works on my laptop (You may have to get some security turned off on the firewall to use this on JetStream).

http://education.itresourcecenter.hp.com/Trainer/education/productlist.asp?comm=7

I could have turned around and talked to you about this, but this is heaps more fun. FRED

[Paula J Frazer-Campbell]

Hi

This white paper will help:-

http://people.hp.se/stevesk/bastion11.html

Paula

[Ralf Hildebrandt]

Also keep in mind that network services can (and should) be run as non-root users where possible. Best examples are:

* BIND (runs as root per default, but can run chrooted as non-privileged user)

* sendmail (runs as root -- but can be replaced by Postfix, which doesn't run as root and which can run chrooted)

[Vincenzo Restuccia]

See http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90701/B2355-90701_top.html&con=/hpux/onlinedocs/B2355-90701/00/00/60-con.html&toc=/hpux/onlinedocs/B2355-90701/00/00/60-toc.html&searchterms=security&queryid=20010423-033035

[Joanne Keegan]

Thank-you for the responses so far. I will award points in the next couple of days.

Paula, thanks for the whitepaper. I will have a close look at it.

We run a large site with several sys admins which makes it hard to restrict the use of root especially when we take turns at callout. I was wondering if there is someone in a similiar situation and what steps they may have taken to tighten up security.

I'm looking for ways to improve what we already have in place. (I'm relatively new to this site - and of course take security quite seriously).

Thanks everybody who have responded so far to this question.

Jo

[Peggy Fong · Accepted solution]

Hi

We used the bastion11 checklist as the foundation for tightening up a system. For root, I asked the same question on how to restrict - here is the thread:
http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0xaf7e37f45ef7d4118fef0090279cd0f9,00.html

Here are the excerpts from that thread that might help...


There is now way that I know of to restrict the su capability that is native to HP-UX. The easiest thing that comes to mind is just not giving out the password. If you don't want them to do a 'su -' then why give them the password?

Another option you have though is to use the product called 'sudo'. You can get it from the HP-UX Porting center. Here is a link to it:
http://www.courtesan.com/sudo

Sudo allows you to set people up with the capability to run things with root capability without having to give out the root password or give out full 'su -' access.

sudo is a way to limit who has root access. In the sudoers file you can have something like the line below to prevent root access;

Cmnd_Alias SU=/usr/bin/su, !/usr/bin/su *root*, !/usr/bin/su "",!/usr/bin/su -

Also, I have put in something for rlogin as well. If you are root one one system and do rlogin to another system, you are root on the other system as well.

The above Cmnd_Alias will prevent specified users from becoming UID=0 unless they are in the sudoers file as having the rights to UID=0.

regards,
~pf

[Joanne Keegan]

Thanks to all that have replied so far. The information has been invaluable. I will finish assigning points in a couple of days (Paula & Peggy).

Regards,

Jo

[Paula J Frazer-Campbell]

Hi

With multiple root users a way to track what they are doings is by putting an entry into roots .profile as such:-

# Who logged in (From where)
date >> ~/.sh_history
who -u|grep root >> ~/.sh_history


Which will put time, date and from the who command will identify the ip address of their login.

To look at what was done vi .sh_history and search for date:-

/May 1

Tue May 1 00:06:20 BST 2001
root-gdr pts/tr May 1 00:06 . 7269 172.20.1.138
crontab -e

Shows that root user GDR loggied it at 00:06 hours from an in house ip address and could have edited the crontab.

DO NOT save the .sh_history on exit as current entries will be lost.

HTH

Paula

[Joanne Keegan]

Paula,

Thanks for that. Your suggestion is a good idea.

Thanks,

Jo

[Paula J Frazer-Campbell]

Hi Joanne

You are most welcome, and BTW welcome to the forum.


;-) Paula

[Thierry Poels_1]

hi,
just want to add that we use a history file per tty logged on ($HOME/.sh_history_xx). So if more than one root is logged on, their commands don't get mixed up in the history file.
If you want to use the history file for security check you might want to apply this too; otherwise if more than one root is logged on, you won't know who did what.
regards,
Thierry.