Website Security II – Peeking Inside

As a result of recent discussions with associates and clients I’ve been persuaded to expand on my previous brief article on the topic of website security.

However, this will still not be a blow-by-blow list of instructions. As I attempted to get across in the previous article, that’s something that could only be achieved with a series of very detailed articles specific to each major platform.

The general consensus amongst those I was talking to seems to be that this is one of those topics where understanding how things work will provide some useful insight into the likes of what actions are dangerous, what factors are important for achieving security, and for developing the correct mindset.

The Web Host

Most websites are hosted in a shared-server environment. That is, a single computer running a suitable operating system (e.g. Linux, Windows Server, etc) and loaded with compatible Web hosting software (e.g. Apache, Microsoft Internet Information Services aka IIS, etc) hosts a number of different domains/websites which all share the one host environment.

In some cases the one physical server may host just one website, an arrangement which is referred to as a dedicated server. The hosting cost per website on a dedicated server is significantly higher than for a shared server environment, obviously because the capital and maintenance costs of the equipment can’t be shared by multiple customers.

Ideally, configuration of the Web server is such that the storage space and facilities allocated to each domain/website in a shared environment is completely isolated from the storage space and facilities allocated to other domains/websites on the same server.

For reasons of usability the host’s server technicians allow each website owner a degree of freedom and flexibility in what they can install to their own isolated domain/website.

An extremely important security consideration for server technicians is that a situation is not allowed to exist where the activities of one customer in a shared server environment could have detrimental effects on others. Thus proper configuration ensures that each domain/website does not have any controlling access to the system beyond their home directory.

Self Harm Is Permitted !

It should be apparent then, again in the interests of usability and flexibility, that it is possible for the owner of a domain/website to load inappropriate software/scripts into their own isolated realm, thus interfering with or destroying the intended functionality of their own website. The server technicians are only concerned that any such localised action can’t “leak” over to affect other domains/websites that are being hosted on the same server computer.

So the long and the short of it is: Yes, you are perfectly free to destroy your own hosted environment!

Which of course you wouldn’t want to do, but the fact that it is possible leads us straight into the real problem, of which there are two variations with the same end result.

Variation #1: By somehow obtaining the correct login credentials, someone else can enter your hosted environment and install malicious scrips, or destroy/deface existing content. Once in, there’s nothing to stop an intruder from doing anything you could do yourself.

Variation #2: You allow yourself to be deceived into taking some inappropriate action yourself, such as installing a malicious script. The end result is the same as for Variation #1, but your enemy doesn’t need to go to the trouble of getting your login credentials — he gets you to do his dirty work for him.

Now let’s just sidetrack a moment and consider a couple of scenarios where something happening within the confines of a single domain/website can indeed leak out to affect other domains/websites sharing the same server.

Scenario #1: Excessive usage of resources causes the server computer to become slow and unresponsive. Because the host’s policy is to provide a useful, usable and flexible environment for their customer’s websites, there is nothing they can do to prevent an individual website owner from installing software or a script that will massively eat up system resources. However, a professionally operated hosting company will have monitoring systems in place that quickly alert staff when something like that happens. In the case of my own preferred host every member of the technical staff receives an SMS via their mobile phone. Once notified, they can isolate and disable the misbehaving site very quickly, before contacting the domain/website owner to assist in sorting out the problem.

Scenario #2: A compromised site may be set to generate large quantities of spam, usually without the knowledge of the site owner. Similar to Scenario #1, the hosting company will have a monitoring mechanism in place that alerts technicians to abnormal mail load. Once alerted to the problem there are courses of action they can pursue to terminate the unauthorized action.

There are of course other possibilities, but those examples will serve to illustrate the fact that, while there are circumstances where one domain/website can indeed affect other shares on the same server, the onus is on the hosting company to be ready to respond very quickly to any such events.

Back now to our individual hosted domain/website…

You will now appreciate that, certain exceptions aside, Web hosting companies are more or less forced to place the onus for the security of individual Web sites squarely on the shoulders of the customer, the owner of the domain/website.

For the host to go any further in trying to protect you from yourself, they would have to remove much of the flexibility and functionality that allows you to create your unique website in the first place. This they can do, but it would result in a very inflexible environment not at all conducive to for Website development.

Common Vulnerabilities

One of the holes through which miscreants frequently crawl into a website is via an upload facility that isn’t protected by a strong login requirement. Presenting openings like that to the general public are just asking for trouble.

And of course FTP software is something that all Webmasters should be familiar with. You should be well aware that if someone has your FTP credentials they can do anything they like to your website.

As always with login credentials, whether for FTP or an on-site upload feature or whatever, the key to acceptable security is passwords that are long, convoluted and complete gibberish.

You may be surprised to learn that there can be quite a bit more to password creation and use than you realize. My article How to Choose, Use and Recall Strong Passwords may provide some surprisingly useful ideas.

Blogs

Finally we come to the special case of blogs in general, and WordPress in particular. But first a disclaimer: I am NOT a WordPress expert. In fact I’m very much a beginner when it comes to developing a quality WordPress blog, something I’m only in the very early stages of. But this article is about securing your blog/website environment, not about actually using WordPress.

Now, as far as all of the foregoing is concerned, a blog is simply part of a hosted domain/website, and all of the foregoing applies equally to a blog as to any other type of website.

Where a blog differs quite markedly, and especially with WordPress, is the blog owner’s ability to very quickly and simply install any of a vast array of small scripts for the purpose of adding extra functionality to the basic platform. In the vernacular these scripts are referred to as plug-ins and widgets.

Plug-Ins & Widgets

A big problem with WordPress seems to be that these third-party plug-ins and widgets have become so well accepted, and indeed much sought after, that many bloggers completely ignore security considerations in favour of the possibility of getting some new, cool function for their blog.

Naive computer users uneducated in security considerations have always downloaded and installed software found anywhere on the World Wide Web, without a seconds thought for the possible consequences. That’s why probably 75% or better of private computers are a complete mess.

But when it comes to loading plug-ins and widgets to a WordPress blog, it seems that even computer users normally cognizant of the dangers will throw caution to the wind and proceed full steam ahead, without taking the normal precautions.

I think it’s fair to say that the ultimate authority on the safety of a WordPress plug-in or widget is the genuine WordPress website itself. My understanding is that any plug-ins/widgets offered for download from WordPress.org have been analyzed for their safety. They may or may not work as intended, and they may screw up your blog, but they have been assessed as not containing any malicious code.

Now I’m not suggesting that you must limit your use of plug-ins and widgets to those sourced only from WordPress.org. But you definitely should apply the same precautions to a WordPress plug-in/widget as you would to any software downloaded from the World Wide Web. At the very least spend a few minutes researching the particular plug-in/widget you’re interested in, to see what other people are saying about it. If it’s possibly a “nasty” that will soon become evident.

Patches, Updates & New Versions

But probably the major source of potential problems from malicious interference lies with the WordPress code itself. WordPress is an open source development, meaning that its programming code is readily available to anyone. This is obviously a boon to any scumbag programmer who wants to analyze the code looking for weaknesses that he can exploit.

The only answer to the type of vulnerability that resides in the core program code is for the developers to continue to tighten up the code and eliminate weaknesses as they are discovered.

Software users often regard program updates and new version releases as just providing new features, and will often ignore them, for a period of time at least.

But very often the main reason for the release of updates is the distribution of newly “fixed” software — fixed as in having at least some of the known vulnerabilities removed. Thus, nuisance though it may be, it’s in the bloggers best interests to always install the latest program version as soon as it becomes available.

There are also many things you can do, and many others that you should avoid, that will help in your quest for blog security. As tempted as I am to begin a list of do’s and don’ts, I’m dissuaded from doing so for three main reasons:

A comprehensive list would be enormous;

Many items on the list would be incomprehensible to non-programmers;

It’s all been done before — the web is rife with recommendations for improving the security of WordPress and other major blogging platforms.

The Next Step Is up to You

If you’re serious about pursuing blog security then you will not hesitate to take the next step yourself. And that is…

Type the words WordPress security — or Movable Type security — or whatever describes your blog platform — into Google and you’ll be rewarded with a wealth of practical, actionable advice.

A tremendous amount has been written on the topic of security for all major blog platforms, and the more you read, the more will security considerations become second nature to you.

The downside of online security education is that it can never stop. New vulnerabilities and new methods of countering them are being revealed all the time, and the only way for you to stay on top of the situation and keep your sites as safe as possible is to stay informed.

No single book or article can help you achieve that.