PHP Handlers and Caching

Question

I recently began configuring our production server for a new Drupal site. Up till now, I've always used the default PHP handler mod_php, and removed write privileges for any directory/file except where image uploads, etc may occur. The vps we purchased is from a company that actually removes this from the WHM configuration choices, leaving suPHP as the default. I can override this, but I'm now thinking about the impact this choice has for both security and performance. Because suPHP doesn't allow for caching via APC, or other tried and true caching systems, I was wondering if a DOS attack could be more effective? In a previous project, a botnet group that seemed to originate from a hacked flash program, was continually "clicking" something that generated ajax requests. This did in fact cause MYSQL errors to be visible at one point, and even seemed to trip up the authentication (I didn't verify this, but I remember a non admin seeing admin privilege protected pages), so I wonder if the ajax request was cached if this could have occurred? I have also read that caching itself can be the target of a DOS attack...

Answer 1

If you're not running an opcode cache then you're DOSsing yourself already, particularly if you're running Drupal! It makes for a nice business model if your renting out server hardware!

There are some edge cases where running suPHP makes sense from a security point of view (but the number of these is massively reduced by php-fpm's support of pools per user) - but this is not one of them. (if you were using php-fpm, then it might be worth considering having a dedicated user for handling the file upload path).

The best protection against a DOS attack is having the capacity to deal with it. The second best option is being able to profile the attack and easily inject specific handling / blocking.

and removed write privileges for any directory/file except where image uploads, etc may occur.

This is not enough on it's own - you also need to disable PHP parsing (and, preferably any direct webserver access) to the uploads dir.

Controlling your server via WHM is not a good idea if you're concerned about security.

Regarding the previous attack...this is a seperate question, and there's not nearly enough information to hazard a guess - even if that information were available, it's probably beyond the scope of an answer here. It's rather unlikely that the PHP config would cause the symtpoms you describe ('I remember a non admin seeing admin privilege protected pages') - it's more likely to be a code defect / issue elsewhere in the stack.

Answer 2

You may not be able to use opcode caching (like APC) but there's nothing saying you can't use Drupal's caching functionality to help with some of the performance problems (https://drupal.org/node/326504). Sure, it's not the same as opcode caching, but with suPHP comes a lot of tradeoffs.

Remeber, anything your application sends out (including Javascript) is open for anyone or anything to read. This "clicking" you describe could have easily been a script calling whatever your ajax request was calling directly.

Also, please disable the php.ini "display_errors" setting in production. This prevents normal error message output back to the requesting app/script (except for fatal errors). Most of the MySQL-related issues, including connection problems, are warnings so they shouldn't cause a problem. You can use ini_set to change this value at runtime (http://php.net/display_errors).