What is on Your Mind?

I am currently executing a Unix audit & would like some guidance on best practice for the management of root user access.

The organisation is small, with an IT team of approx 25.

Give the pass only to those who you trust. Logging the root actions that is readable by all users is good too.

I have never seen best practices implemented. But in an ideal world... The root account cannot be used to access the box. You sign on as bob, or george, or whatever. Then you su to root, leaving a audit trail. The exception to this is the system console port...you can log on as root there, reboot the machine, etc. The console port can be accessed only from the computer room. Or, if that is too restrictive, the console port is accessed from a remote console server. You need to signin to the console server as yourself and this leaves an audit trail.

The root password is a strong password. It is available only to a few experts. Can you recover from any disaster? If not, no root password for you. (Possibly a manager has, but does not personally use, the password.) When one of these experts leaves, you disable his or her account. And you change the root password.

Other people use sudo if they need root for something... this also leaves an audit trail. This does not mean ALL in sudoers however. Just a few limited commands.

Something like this is our official policy. But various bigshots often arrange exceptions.

I just HAD to stick my 2-cents in here. One problem I've seen is a lack of 'terminal servers' with SSH (2) only access. A LOT still use telnet. Telnet and the BSD 'R'-commands should be banned. Another is that nobody sits down with the CEO (president, owner, etc.) and has a discussion about what is the true VALUE of the "stuff" stored on his computer systems. Or the cost to him when these systems are no longer accessible. The goal being to force him/her into a security policy. Which should really limit the "bigshot" access.
The final thing is something an 'old' sysadmin once told me. We were setting root passwords. He grabbed a UNIX book off the shelf, found a chapter or sub-chapter title with six or seven words in it, took the first letter of each word, 'munged' these characters (a=@; l=| e=3, etc.) and stuck the first character of the hostname in front of this string, and the last character of the hostname at the end. He had created 'the same' root password for all machines (easy to remember, especially if you wrote down the chapter title), and at the same time a different root password for EACH machine. I have used this (or a variation) ever since.

root can only access any box through it's console, and only the SA team has root.
Each of our boxes have there own PWD, kinda reassures you on which box our on
All passwords expire, except for root...which I feel we don't change often enough.

Our shop is a big advocate of sudo.
We have captured menus (that utilize sudo) in place on ALL systems for Datactr personnel for the following actions:
Create unix accounts (IS and User)
Change passwords (all except for root)
Deactivate IS and remove User accounts.

As mentioned before, all of these activities will leave an audit trail...and In our case they will also have an associated HelpDesk request #.
Remember when you had to do all of these tasks...sudo is your friend

We also utilize email (end-of-day) to help us manage other Audit policies, like the following:
invalid attempts at sudo (not valid sudo user)
invalid attempts at su (not part of SA team)
invalid login attempts 3 or >...these are Hourly.
(This is just an example of what can implemented, this list can go on-and-on)

got SOX?
In todays SOX climate, I find that all of these policies and associated audit trails are necessary.

If you don't have something similar in place, you may want thinking about how some of them could provide some benefit to your env..

Perderabo,

The job before my current one was the security ideal. Anything that resided in the DMZ or next zone down was Trusted Solaris. The root account was a "role", not a user - thus no direct login from anywhere. RBAC ruled the day and had been extended to provide what sudo could and more. No access that was unencrypted was allowed. All other layers - app, transport, customer and database, thought not TS were setup in a similar fashion. Extensive auditing existed and maintained audit logs local and a a remote location so you could checksum to ensure that the audit trail was unaltered.

Security was tight, but organized well enough to never be an impediment to business.

Cheers,

Keith

My customer (a bank) is happy with the following environment (AIX 5.2):

- root login is disabled
- telnet, ftp and all r-commands are disabled in /etc/inetd.conf
- sudo is used exclusively and based on groups people are allowed to do some tasks which classically are roots tasks (packaging installp-packages i.e.)
- admins (myself included) are allowed a "sudo su -" to become root
- login and file transfer solely via ssh

bakunin