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...

2 Answers 2


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.

  • I agree with the no-cache is dossing. I'm not a fan of the WHM, I am a complete gui hater, but I was interested in why this was set as the default. Ultimately, I will be locking down the server as much as possible, but experience has taught me that nothing will replace monitoring. Thanks for the feedback. I appreciate the time taken.
    – tuson
    Commented Dec 23, 2013 at 15:39
  • Looking back at this after a year has passed is amusing. Not sure what I was talking about regarding the auth issues, lol. Maybe the hack was successful, and permissions in drupal were changed? I programmed my own module, and its very likely my code might have been the target, I don't recall there even being any type of virus scan on the uploaded files, so anything was possible, including a backdoor shell. :\
    – tuson
    Commented Dec 1, 2014 at 10:50

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).


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .