Locking the Unix root user.

[Khalil Ahmed]

In order to increase security on our Unix systems we’ve been asked to lock the root user and create our own logons and then do an “su – root” whenever we require root access.

My first question is how do we “lock” the root user and also what are the implications/issues of us locking the root user?... eg we use HP’s Data Protector (OmniBack) to do our backups and the filesystem backups are done using the root user, so if we were to lock the root user (some how) would the backups still work?

By the way we are running HP-UX 11, HP-UX 11i & HP-UX 11 v2 operating systems.

Regards

Khalil

[Peter Godron]

Hi,
by 'locking' do you mean no telnet access direct to root?
Most of our machines only allow direct access to root on the console by adding to /etc/profile:
if [ $LOGNAME = "root" -a "`tty`" != "/dev/console" ] ; then
echo "Error: root logins are only allowed on the console."
exit 1
fi

[Jeff Schussele]

Hi Khalil,

To expand on Peter's reply to restrict root access simply create the following file
/etc/securetty
and put only the text
console
in it.
Then make sure it's root:sys 400

Then root can *only* login from the console port.
I would not totally lock root out as sometimes console access is the *only* way to fix something.

My $0.02,
Jeff

[James R. Ferguson]

Hi:

To force users to 'su' to root, create '/etc/securetty' and put the strnig "console" on a line in the file. This permits root to login at the console, only.

Also, build the '/etc/default/security' file. You may want to define the users who can 'su' to root with the 'SU_ROOT_GROUP' variable value.

See the manpages for more information:

http://docs.hp.com/en/B2355-60127/security.4.html

Regards!

...JRF...

[A. Clay Stephenson]

You lock root by executing passwd -f files -l root; however, if you do this you will not be able to su root -- because the account is disabled. Using that approach sudo would be required. In any event, as long as the account exists (even if locked), processes are allowed to run.

What I think they want you to do is create a file, /etc/securetty with a single entry 'console' in it. That will allow root to only login directly as root on the console -- which presumably is in a secure location. Uses can then su - root from anyu terminal.

[Marco Santerre]

I agree with Jeff. As much as you can secure your environment by implementing sudo and by making sure that root can only log on directly from the console (if you use ssh I would also disable PermitRootLogin in sshd_config).

You could also implement a special group that can only su to root in /etc/default/security and only SA could have that group.

But I definitely wouldn't put a lock on root per say as it could cause more trouble than help.

[Khalil Ahmed]

Guys, this recommendation has come from external auditors, who are a royal pain in the neck! The auditors would like direct root logon (telnet or console) blocked period.

There are only two of us administaring the systems, and personally neither of us would be particularly keen on locking the root user. So, what we'd really also like is to have a number of reasons (ie the downsides) against locking the root user, to counter this recommendation.

Cheers

[Jeff Schussele]

Simply - supportability & uptime
If for any reason root has to login to fix something you're out of luck.
You'd have to power down the system.
I've never seen this type of request even in SOX audits. I think it's *way* to draconian.

Rgds,
Jeff

[Khalil Ahmed]

...sorry forgot to mention, what about our filesystem backups via Data Protector, which use root access, will they still work?

Khalil

[A. Clay Stephenson]

If you must lock root then DP will still run. As I mentioned earlier, in this case, you will need to install sudo and use it in lieu of su - root because you will always be prompted for root's passwd when you su as a regular user -- and because root is locked the password will always fail. Sudo will require you to know your regular password. In this case, I don't see that using sudo is any more secure than restricting direct root login only on the console. It's also a bad use of sudo because good sudo practice involves extremely restrictive commands. In this case, you will simply be spawning a shell with UID 0 -- a very wide-open environment.


Plan B. Create another UID 0 account and su as that (unlocked) user. It's state-of-the-art stupid and a worse choice than restricting root to only the console but it does meet the strict requirements set by your auditors.

[Jason Ray]

We have similar audit standards here. We use the 'console' line in the /etc/securetty file to keep people form telnet-ing as root.

I have never heard of any audit reason that would require you to lock the root account from console logins as well. You definitely want to be able to use root from the console. Otherwise problems could definetely occur where you'd be forced to shut down the machine and boot to single-user to gain access.

[Khalil Ahmed]

I have another meeting with the D&T auditor today and I will find out what he means by locking root, as it's clear that this is definitely not practical. However, restricting to root console access only may be the way to go and should keep the auditors (plus management!) happy.

[Peter Godron]

Hi,
have you had any luck with the auditors?
Are the solutions provided ok?

[Nick D'Angelo]

some points would be appreciated.