WordPress is great. So are most other free and/or open-source applications. The only problem with these applications is that no matter how secure the other parts of your web site are, using such a popular application makes you an easy target for their widely circulated exploit scripts. There are lots of prying eyes on, say, WordPress. And exploiting popular open-source applications is interesting, because you get more bang for your buck. Upgrading helps, and of course we do it. But it still won't help for 0-day exploits, and it's not easy when you're managing 50-60 blogs.

And many have installed plugins — some of which were written by programmers who are, ahem, not-so-bright. Clients just won't get it if you tell them unaudited plugins present unknown security risks. They'll use them anyway.

So what can we do that's easy and effective? Run it on a different server as blog.domain.com instead of domain.com/blog/? Sure. That can work, but it may not be what you want. So what we do for some clients is sandbox the said application via reverse proxy.

It looks like it's running on the same server — http://domain.com/blog/ — but really the blog is running on a completely different server.

After all, it's a completely different application — and probably doesn't need to access other databases or application files.

You might ask how much better is this than just using a different database or just being "careful." Well. It's a lot better. An exploit that works on the blog, bulletin board, etc., can make your eCommerce application just as vulnerable as it. Using a different database helps, but not as much as completely sandboxing it. You might patch it a day too late. If it's sandboxed, your blog may be totally trashed — but at least customer information is safe.

So this is how it's done via Apache 2.x configuration directives:

ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /blog http://[OTHER_SERVER_IP]/blog
ProxyPreserveHost On

(on main server in your server's httpd.conf). The blog server will run without any configuration modification — just tell it that it is also domain.com. It can be running any version of Apache.

Alternatively (with an IP based blog hosting web site):

RewriteRule ^blog(.*)$ http://[OTHER_WEB_SITE_IP]/blog$1 [P]
(on main server in your .htaccess file in the root directory of the web site — may be any version of Apache).

Then add (for Apache 2.x):
RequestHeader set Host "domain.com"
(on blog server in your .htaccess file in the root directory of the web site — must be version 2.x of Apache).

Alternatively (with a non-IP based blog hosting web account + domain parking):

RewriteRule ^blog(.*)$ http://fake.domain.com/blog$1 [P]
(on main server in your .htaccess file in the root directory of the web site — may be any version of Apache). In cPanel, to do this, one would make the web site domain.com, but set up a parked domain of fake.domain.com as well.

Then add (for Apache 2.x):
RequestHeader set Host "domain.com"
(on blog server in your .htaccess file in the root directory of the web site — must be version 2.x of Apache). Thanks to Jeremy Luebke for this idea.

Note: The 2 web sites must be placed on 2 different physical machines — not just different hosting accounts — but that's probably a good idea regardless. The blog should obviously be installed in /blog/ on the blog server. Both methods require Apache 2.x on one of the two sides.

And that's basically it. Essentially what this does is proxy all the requests and forge the headers to keep the blog server happy. The blog server sees the Host: header for domain.com. Everything proxied back is also OK.

As long as it's on a physically different box, the blog server thinks it's domain.com via the "/etc/hosts" file (cPanel does this for you), and the application is installed in "/blog." So it will work blissfully unaware that it's a lie. In summary — the proxied requests should all work without any manipulation of the document or application and come through perfectly.

Helpful Hint: You may also peruse the web site from your computer by editing the same hosts file ("/etc/hosts" or "/windows/system32/drivers/etc/hosts" on most computers) by mapping domain.com to the blog server's IP.

Done.

If this helps you, let us know. A lot of our clients want a blog. But we simply can't update so many blogs as fast as we'd always like, and even if we did, we can't even control all the plugins they install. Upgrading expeditiously is still essential, of course. But this will mitigate the success of a "successful" attack substantially.

Tell an amigo:
  • Sphinn
  • Digg
  • Reddit
  • del.icio.us
  • StumbleUpon
  • Facebook



Related posts:
The Best Libido Enhancer is No WordPress Security … for spammers, anyway. Upgrading WordPress often might just help!...
Delisting 101: Bad Webhosting Can Even Get You Banished From Google You thought cheap webhosting was a bargain. Maybe … but...
Stop Hackers With Our WordPress Firewall Plugin v1.2 Getting hacked is a total bummer, right? Right. But...
The Proper Procedure for Changing Hosting Companies (It's really not always so simple … ) Should the need exist to change hosting companies, the process...