Is 2007 the start of a new era, where even the modest hosting company trumpets their impeccable security measures, or is it really more of the same - lots less action than marketing speak? More and more companies cite their security services as a selling point today. To hosts who want to serve the needs of their customers today and in the future, their charter for 2007 is clear: Security impels careful vigilance.
Develop the best system today, leave it to rust and you'll find that scammers will certainly overwhelm it. As those who seek to defraud adapt, so too must the web host, and with it their procedures and plans.
If you're a system administrator you already know that
it's a bad month for PHP. This is scary because so many web hosts and resellers out there are putting servers online without any PHP hardening. The "default" is no longer good enough. If you are already aware of that, you are definitely deserving of much applause.
If you're a customer looking for secure hosting, you might give Google a search right? Well this is another scary part. The first result for a "secure web host"
returns this hosting plan, and I really don't see what is so secure about it. Plus how can something so secure be available to you within minutes? Most of the results are just like that one: murky and questionable.
Now is the time to make sure your procedures are clear and become known as a host that is serious about security and not just talk. What are you doing exactly to prevent PHP exploits? PHP is the biggest problem for hosts right now, by far. In my next blog I'll tell you what I'm doing.
More About Kayla
Surpass Hosting
Also not that there is a PHP Suexec patch and then there is running PHP as a cgi-bin. All cgi-bin's fall under the traditional suexec control. While this is more secure, running PHP as a cgi-bin can be significantly slower than running it as an apache module. Also, you often cannot simply just switch from one to another if you've complex applications.
Lastly, don't overlook the ability to set headers via the sendmail options within php.ini. This can be done on a per-site basis with many hosting control panels.
Longer term, I wish we could just do away with the easy mail function within php and move to using SMTP auth. The latter would require the script to authenticate against a designated SMTP server, thus providing a much better audit trail.