Web Server Users - Best Practice

Question

I was wondering what is considered best practice when several developers/administrators require access to the same web server.

Should there be one non-root user with a secure username and password unqiue to the web server which everyone logs in as or should there be a username for each person.

I am leaning towards a username for each person to aid in logging etc however then does the same user keep the same credentials over several servers, or should at least their password change depending on the server they are on?

Should any non-root user of the system be added to the sudoers file or is it best practice to leave everyone off it and only let root perform certain tasks?

Any help would be greatly appreciated.

Answer 1

• Best practice: Have traceability for all privileged actions. That means no logins as root under normal circumstances; people login with their own IDs and privileges. Actions they take are traceable. If a particular account is compromised, it can be fixed without affecting other accounts or the system as a whole.

• Best practice: Least privilege. People and applications get the permissions they need to perform their authorized activities, but no more.

Following those two principles is the answer to your question. Exactly how you follow them is up to you. It depends on what your site policy recommends, the complexity of your server set up, continuity plans, etc. Note that following these principles makes compromise of your system by hostile attack more difficult, but more importantly it limits the consequences of a well-intentioned error.

For things like web server maintenance, most capabilities can be enabled without requiring root access by suitable user/group ownership and permissions (note the original question had linux/unix tags). For instance, the web server config files could be owned by "wserver," group "wsgroup" and permissioned 664. That will allow any user to read the config and anyone in "wsgroup" to edit the files (not necessarily what you want). Web content could be in a different group, as long as the web server process has read or perhaps execute permission, the content can be served. That will allow different (perhaps overlapping) groups to maintain the web server and the contents.

You may also set up sudo for given users to run specific commands as specific users. For best practices, you should limit root access to those few items that actually require root privileges (e.g., starting a process that listens on a privileged port). Set up the rest as necessary granting as few privileges as necessary -- that helps limit the consequences of errors. For instance, if you want to allow a group to edit web server config files, allow them to execute {vim, emacs, gedit} as the owner of the config files.

Answer 2

We're a small webdev company with a handful of servers.

Every administrator has their own account on every server, and usually logs in via certificate. However they can also log in via password, since they may need to log in from a remote location where they may not have their certificate with them.

Directly logging in as root is only allowed via certificate. We haven't completely disallowed remote root login, since it is very useful for transferring files between servers via rsync and scp, however only the most trusted administrators have their certificates added to root's authorized_keys file.

Administrators get superuser privileges via sudo, by making them a member of the wheel group.

This does not protect against malicious administrators but it does provide some logging, and the ability to disable individual accounts, when an admin leaves. It's also doesn't scale well, but is fine for a small numer of servers.

Scripts which need superuser privileges, such as Capistrano which we use to deploy our websites from version control to the webservers, get their own user accounts and can use sudo to perform superuser actions. But, they're limited to only the commands they require, via sudo's Cmnd_Alias.

I'm thinking about setting up Likewise Open so we can tie the authentication into our Active Directory domain. This would make it easier to centralise the authentication, manage passwords, and provide granular permissions.