Hi Michael, On Wed, Jan 30, 2013 at 05:42:57PM +0000, Michael Stevens wrote: Well, PHP was cool 5 years ago, now it's all ruby, node.js and clojure. :) If "don't run PHP" doesn't work for you then my best advice is: - Keep it up to date - Run as few plugins, modules etc as possible and keep *those* up to date - Expect to be compromised, so try to secure your PHP execution environment from the rest of your server. e.g. do assume that at some point an attacker will get to execute commands as the user that is running your PHP app so try to reduce what the app can do. Good luck! Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting

On Wed, Jan 30, 2013 at 05:42:57PM +0000, Michael Stevens wrote: You've picked a doozy of an application to start with! :) My best advice: make your docroot read-only to the application. Make the files owned by root or something and your apache/mod_php (assuming you're using mod_php) processes run as your apache/www-data/whatever user. Also, if any documentation tells you to chmod 777 a directory, burn it. Burn the person who wrote said documentation, and stop using the project. Or, submit an issue :) If users have *any* control of files within your docroot (say, an uploads directory, or something) make sure you have all of the requisite settings like: RemoveHandler .php Options -ExecCGI -Indexes -Includes AllowOverride None (this is all assuming apache, btw) Maybe even go as far as to limit referrers to content within that dir, but that's pretty trivial to bypass if you're trying to prevent an insecure application from becoming a warez dump. Also, the question is pretty broad. You might try to focus your search by searching for the specific application you're trying to run. Here are some general sub-categories of "securing php" I can think of: 1. Writing secure PHP code (see: perl) 2. Securing mod_php in a shared hosting environment (see: cgi) 3. chmod 777, fire, and you. (see: fire) 4. Preventing SQL injection vulnerabilities in PHP (see: PDO and parameterized queries) As I said, though, you'll probably have a lot better luck with your search if you narrow it some. Securing web applications is a huge topic, and any time you run someone else's code on your system, you're opening yourself up to a potential vulnerability. Make sure to get on the -announce mailing list for any php applications you're running, watch very closely for security vulnerabilities. If there are any security upgrades, upgrade *immediately*. I would also highly recommend keeping a local git/svn/darcs/hg/cvs/whatever of your application and pull in patches that way. The primary benefit of this in a security sense is if your application is compromised, you can simply do a "svn status" or equivalent within your docroot to see if any new files were added to the application code. You'll of course want to set svn:ignore (or equivalent) on any uploads directories or such, but you've already locked down that directory to prevent script execution in there, yes? :) I feel I must warn you one last time, since this is *such* a common thing. DO NOT. EVER. chmod 777 a directory for a web application. There should exist no more than 2 chmod 777 directories on a given system: /tmp /var/tmp Anything more than that and you're doing it wrong. Sure, you may need to provide relaxed permissions for an application to work, for instance wordpress needs to write to its uploads directory. But 777 is not the answer. Make it root:apache 775 or something, or better yet, run wp under cgi/fcgi as a separate user and make that user the one who owns that directory (but not the rest of the docroot!) If you're trying to set up some sort of shared hosting (even if it's just for a friend or 2), do not use mod_php. mod_php is impossible to secure in a shared hosting environment without placing huge limits on what the application can do (safe_mode, open_basedir, etc) which often are incompatible with off-the-shelf applications. One could argue that those applications are simply poorly written, and normally I would agree, but there are better models for securing applications on a unix system than relying on your language interpreter to disallow certain things. Additionally, you may want to look into mod_security for apache. It can often detect and prevent possible intrusion attacks before they even get to your application, however keep in mind that depending on your ruleset, you may end up with a large number of false positives. If you have complete control of your application and know exactly everything that might be used with it (request parameters, etc) then it's great, though not a replacement for proper security in your code. See it as one more layer of protection. Anywho, I just realized I'm rambling. Sorry about that. Good luck! -Jeremy

On 30/01/2013 17:42, Michael Stevens wrote: Despite the general PHP-dislike in the responses, I've happily run PHP on my server without issue and, while I run SquirrelMail rather than Roundcube (although I understand that Roundcube is more interactive and has a nicer interface), I use suhosin, a basic setup of mod_security, along with fail2ban and use the ITK MPM for Apache instead of prefork - this enables me to run the VirtualHosts as different users limiting the scope for compromise, or ensuring that the user does not have any write permissions. Gavin