It is well-known for decades (at least since PHP got popular, which was in '90s!) that such locations should only be writeable by the user(s) who maintain the code and not anyone else. Sometimes, such setup can't be done on dirt-cheap FTP-only shared hosting services (shrugs), but certainly not on VPSes.
Ignorance is bliss.
edit: I know a lot of HN'ers are fans of Ubuntu but, FWIW, SELinux (default on RHEL and derivatives) would have prevented this.
I mean, all writeable directories (if any) must not only be not runnable by some server (like Apache with mod_php), but also be on devices mounted with noexec, like this is the case with /tmp.
I can't verify it at the moment, but create a /tmp/phpinfo.php file with "<?php phpinfo(); ?>" in it and then run "php /tmp/phpinfo.php". Regardless of whether /tmp is mounted noexec I think you'll find that it executes (because the php binary is under /usr which almost certainly isn't mounted noexec).
Anyway, it's also better to have noexec than not. :)
At least, it'll help if there's no complete shell access but only ability to run some binary by name, without args, or modify environment variables when running some executable.
Why add more moving parts when they don't do anything but make more work? Scanning is a helpful idea, but not AV scanning. Regular vulnerability scanning can assess the platform security. At the very least, it can warn about potential security holes. It might also be plagued with false positives, causing more work for no added benefit. Safely running services on the internet is hard.
Because in this case we're talking about intentionally accepting files from users to either integrate into the system or offer to other users. Why would you not at least check files for cleanness and reject any that fail instead of blindly accepting them because you wanted to enable file uploads.
Vulnerability scanning isn't going to tell you much when you want to accept files from users.
If you must, start off with setting SELinux to "Permissive" instead of disabling it completely. Then after a few days of running, go through your audit logs, fix any of the errors that come up, then set it back to Enforcing.
This is the best bet for something that's in production already, but ideally, you want to have SELinux set to enforcing in testing environments and create the policies there in the first place.
* (That, and custom programs that use perversely wrong paths, e.g. web content in /home, logs in the application directory, etc.)
The issues you mentioned is very basic that should be avoided in the first place. VPS should be well maintained by the owner himself or have professional service to help.
For a better architecture, a web server should be separated from the app server and database server, because the HTTP port is always open on the firewall, while the rest can only be accessed locally.
I have a blog page showing step by step how to configure application development environment on Windows and deployment environment on Linux. Maybe it's helpful.
http://bingobo.info/blog/contents/how-to-configure-applicati...
Like many CMSes seem intent on doing?
Guess there are always exceptional cases to anything.