Safe for users to upload PHP scripts?

Q My server hosts about 50 websites for a number of my customers. Most of them have some form of dynamic content, usually PHP based, while some use phpnuke and phpbb. I'm quite an experienced system administrator, if I say so myself, but I'm not a programmer. What level of risk is my server at by enabling my customers to upload their own PHP pages? Is there anything I can do to get better security from this?

A Because Apache doesn't run as root, your system shouldn't be wide open. However, if you have some bad code on your system, an attacker could still get a shell access and run commands, albeit without any privilege. Usually when someone has some exploitable PHP/CGI code, it enables you to import your own snippet of code by using remote URL execution (called 'fopen' in PHP). Typically, this is fairly obvious when you manage to find the hack because there will be a backdoor process running as Apache. This will be listening on a high port and the binary will often still be left in /tmp or /var/tmp. Running through the access logs, you'll see where the hits were made and what commands they ran, usually wget'ing some C file and compiling it, then running it, thus spawning a backdoor. You could really bolt down PHP to not allow much command execution at all, but this may be counter-productive.

Many PHP-based applications, such as phpnuke, phpbb and so on, will require some loosening of restrictions to work. Ideally, sysadmins are supposed to keep an eye out for outdated software being loaded onto their servers, such as exploitable phpnuke or phpbb. This doesn't scale very well though, and as you get more users, this can become more difficult. An alternative option is to set up a custom partitioning scheme where /tmp is a 'noexec' mounted partition, thereby preventing scripts from being executed when downloaded to /tmp. This can be implemented using a /tmp loopback file too (with /var/tmp symlinked) and it works really well. The only potential issues here are that tmp can fill up more easily since it doesn't have the full space allocation of the whole drive (this may be a feature though!), but if you start it at around 1GB, this should be large enough. Also, if /tmp is done as a mounted loopback file, the file size (partition) could be expanded to whatever size is necessary and then remounted.

Back to the list