Linux – Web Server Users – Best Practice

linuxloggingSecurityunixweb-server

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.

Best Answer

  • 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.