NO CARRIER

Computers, Science, Technology, Xen Virtualization, Hosting, Photography, The Internet, Geekdom And More

Why always blame the web host?

Posted on | October 28, 2007 | No Comments

A friend of mine (and operator of a small hosting company) was chatting with me about a client who insisted that his web site was hacked because the “server was insecure”. Every time I hear that, I chuckle. I’m hearing it at an alarming rate lately, as many people are getting fed up with larger hosting companies and seeking better, more personal service.

Clients want easy access to the person who can “get things done”. I’ve picked up lots of business simply because I allow clients access to my various instant messenger IDs, for instance. I don’t think people realize that using smaller companies means a bit more work on the customer’s end.

Moving is a hassle and comes with risks. Most of you are well aware that changing your web site’s IP address results in a month long sag in search engine referrals. Many blame their new host for this phenomenon, not knowing any better.

Some move, finding their web site hacked only hours after changing hosts. Since the only thing different is the host, it must be the host’s fault that the hack was successful, right? That train of thought is just plain incorrect and rather dangerous. Every web host has a slightly different setup, from firewalls to Apache configurations. Some use programs like Snort or other custom string matching packet inspection to filter out nasty hack attempts, preventing hackers from even reaching the web server with malformed requests.

Others have very complex mod_security rules in place that teach Apache to drop malformed requests based on rules.

If your scripts are safe, you really don’t need to wonder about any of the above. If your site is hacked, the end all explanation is quite simple, your scripts are not properly sanitizing POST variables or operate with buggy variable scope. Its not your host’s fault that your script resembles swiss cheese :)

Larger hosting companies have more resources and can implement additional security that stops most hack attempts. Good luck, however, getting your host in your IM box when you really need some help. To safely enjoy the benefits of doing business with the ‘little guy’, you need to be willing to work for the sake of your own security.

The last time that I tried to take an accurate head count of qualified freelance programmers advertising verifiable references, I stopped at 300. My search was just limited to US entities. Most advertised hardening services for as little as $50. Given the affordability and availability of such services, failing to take advantage of them is simply mindlessness.

If the new host does not employ every single custom rule in its firewall and / or mod_sec setup that the old host does, your scripts will quickly be exploited if they are exploitable. The fact that the old host filtered attempts to exploit a hole in your stuff does not excuse using a swiss cheese application :)

The security of the hosts OS can limit the reach of a successful hack, however you, not your host, remain the one who left the front door wide open.

If your ready to move, try following the checklist below:

  • Find your new host, pester them without spending money for two weeks. If they are patient and entertain your request, giving you direct access to their IM and e-mail, you’ve found the right company.
  • Make your first domain hosted with the new company a subdomain of one of the domains that you wish to move. If you hope to move mydomain.com to a new home, put web.mydomain.com with the new host. Make sure that the subdomain links to your current domain, this will help in minimizing the amount of time that search engines ‘forget’ you. Upload a copy of your scripts to the subdomain as a test, wait and watch for 30 – 45 days.
  • Link to the subdomain from the main domain, something like “Check out our new home!” in the footer should do. This will also help to prevent a dive in visits after you move.
  • Watch the new subdomain closely, using something like siteuptime or any one of the free services that monitor for server hiccups.
  • Watch the copies of your existing scripts, see if they fall victim to a hack. If so, you have a hole, hire someone to fix it. I recommend paying a professional programmer to harden your scripts regardless.
  • If all is well after 30-45 days, move your main domain to the new host. Change the index page at the old host to a “We’ve moved!” message with a link to your new IP address (you did get a dedicated IP, didn’t you?)
  • Make sure that your new host has properly reversed your IP address to match your domain name.
  • Redirect the test subdomain to the main domain. Viola, all done.

So often, I hear “My traffic has dropped significantly since I moved to your hosting”, or, “I was hacked just three days after moving to you!” – while I sympathize with these people I have no choice but to inform them of their own contributions to the problem that they are reporting.

Both problems are rather easy to avoid with proper planning.

Comments

Leave a Reply





  • Monkey Plus Typewriter
  • Stack Overflow

  • Me According To Ohloh

  • Meta