Kayla

The Decision
Exactly a year ago in November 2005 we began to implement PHPsuexec on our new servers. We were one of the first hosts to implement PHPsuexec and admittedly were a bit nervous venturing into this territory. November 2005 was actually the second time we tried to introduce it, the first time which failed was a year before in September 2004. Last year we finally decided that it was the right time and that users were more ready than before.

We have arrived to the conclusion that this has been an extremely beneficial decision, for ourselves and for all of you, from a security and abuse standpoint.

The Data
Because we are now having a PHPsuexec anniversary of sorts, I thought it was time to take a moment (well it was a few hours ) and compile some data so you can see the benefits with your own eyes. It was amazing to see the results (or lack of!) for each server.

- These results are based on reports from June 2006 until November 2006. I searched for both hostname and IP address in all of our abuse reports and help desk reports. (Thousands of reports are in this time frame.)

- In 1 year we have launched 19 shared servers, so this is a sampling from our 19 machines with PHPsuexec enabled and the 19 servers immediately before those without phpsuexec. In other words, SH69-SH87 vs. SH88-SH106.

- In these graphs we cover the three major abuse issues,

Email source = number of times the server was used as a spam source (for example, 2 means that on two occasions a file or script was used to send out hundreds or thousands of emails)

Phish uploads = number of times the server was used to host a phish page

Bot reports = number of times the IP was reported in bot scans/attacks

Kayla

On the non-phpsuexec servers, the amount of phish uploads is important because this also means that other scammers were able to upload files to mass send mail (most commonly and not very imaginatively named mailer.php) so that is why the email source column is also high.

On the phpsuexec servers the ability to upload files into random 777 directories is completely reduced. Random spam sent on those (419, phish, etc) happens only because of a certain type of mail script used by the account holder.

If you have any questions about these results please reply here and let me know. I'd be very happy to go into this deeper.

cowboy

Thanks for putting these results together.

Running PHP as a SetUser, translates to the exploits on the phpSUexec servers being the direct responsibility of the user with the password, not just because someone found a door open for the world to enter.

Removing the user caused exploits, the chart will be all zeros.