File security is a fundamental aspect of web server security. These are rules to follow for file positions and ownership:
Files should not be owned by the user(s) that services (http, ftpd, sendmail...) run as — each service should have its own user. Ideally, ownership of files and services should be as finely divided as possible — for instance, the user that the Apache daemon runs as should probably be different from the user that owns its configuration files — this prevents the server from changing its own configuration even if someone does manage to subvert it. Each service should also have its own user, to increase the difficulty of attacks that use multiple servers. (With different users, it is likely that files dropped off using one server can’t be accessed from another, for example). Qmail, a secure mail server, for instance, uses no less than six different users for different parts of its service, and its configuration files are owned by yet another user, usually root.
Services shouldn’t share file trees.
Don’t put executable files in the web tree — that is, on or below Apache’s DocumentRoot.
Don’t put service control files in the web tree or ftp tree or anywhere else that can be accessed remotely.
Ideally, run each service on a different machine.
These are rules to follow for file permissions:
If files are owned by someone else, you have to grant read permissions to the group that includes the relevant service. Similarly, you have to grant execute permissions to compiled binaries. Compiled binaries don’t need read permissions, but shell scripts do. Always try to grant the most restrictive permissions possible — so don’t grant write permission to the server for configuration files, for instance.
In the upgrade procedure (see later) make handoff scripts set permissions and ownerships to avoid mistakes.