Remember the good old days, when Melissa and ILOVEYOU were the major virus threats, spreading via e-mail and causing all sorts of embarrassing conversations at work? Or maybe even earlier than that, when the only way you could get a virus was by engaging in risky sex? (I mean Software EXchange, of course… get your mind out of the gutter)

These days, anti-virus protection for e-mail is fairly thorough, and nobody’s really swapping floppies full of 16 colour games at recess. Malware authors have moved on to new and more fertile ground — embedding their junk in web pages, and relying on browser exploits to gain access to computers. Of course, with this method, you can only get infected if you actually visit a page that has an infestation, so the malware authors have two options: either entice you to visit their sites, or modify existing websites that users will visit in the course of their day — legitimate sites that people know and trust, but with a little added infection.

Enticing people to a whole dodgy site is usually just a matter of providing something people love to look at and sticking it in search engines. Since the attacker has to have a stable, identifiable presence for the search engines to direct users to, that can also be used by anti-malware lists like stopbadware.org to protect web users, so this isn’t a particularly effective means of attack, and is waning somewhat in popularity. Far more effective is infecting a legitimate website with some form of malware. How does it happen, though? In our experience, there are four vectors for infection:

1. Brute-force password guessing, where the attacker has a botnet they control to just repeatedly try lots and lots of usernames and passwords. They’re bound to get lucky sooner or later.
2. Some sort of web-based exploit, typically a vulnerability in the web application that allows the attacker to run code of their choosing; this is then either used directly to edit files, or bootstrapped into sufficient access to edit files via another method.
3. Password “scraping”, where the attacker gets direct access to the FTP password for your site. This can either be some sort of malware on the workstation of the web developer (or someone else related to the management of the website) that gets the password off the local machine (in a saved password file, or via a keylogger), or else via the “lost password” functionality provided by the hosting provider. Once the attacker has the FTP password for the site, they are free to login to the live site and make whatever changes they like.
4. Direct modification of the website code on the client-side computer, relying on the developer not to notice it and then upload the compromised content to the live site. We recently had our first “confirmed” case of this (where the web developer found the malicious modifications in their local copy), and they swear blind they didn’t download the HTML from the live site (which would bring the “infection” onto the local machine from the infected live site — which we’ve seen before, and categorise under vectors 1 and/or 2).

The countermeasures required to combat all these vectors boil down to a few simple precautions.

• Use strong passwords. (Protects against vector 1) Yes, they’re a pain to manage, but a weak password is just an open invitation to getting repeatedly and painfully owned. Of course, the strongest password is a keypair, which leads us to…
• Don’t use FTP. (Protects against vectors 1 and 3) The list of reasons for this is long, but for securing your website, FTP is a pain because you can only use passwords[1]. Switch to using SFTP (the file transfer component of the SSH protocol) and you can use public keys, which are, for all practical purposes, unguessable. You should also encrypt your keys with a passphrase, which means that even if the attacker does get access to your workstation and copies the key, it’ll be useless to them — unless they keylog your passphrase, which brings us to…
• Keep your workstation secure. (Vectors 3 and 4) It seems that attackers have realised that the weakest link in the website security chain is still the Windows desktop, and they’re increasingly hitting it as the first step in taking over websites (if you get the right workstation, you can get the credentials to hundreds or thousands of websites, because one web developer often works on many different sites). So, on any machine you connect to webservers from, you need to be doubly, triply sure that it’s rock solid — and that’s just a matter of following all the good advice out on the web. Antivirus, antispyware and firewall software, constantly running, well-configured, and kept up to date; keep up to date with your application patches, especially for your web browser, e-mail client, and core OS; don’t visit dodgy web sites; and so on.
• Protect your e-mail. (Vector 3) If someone can get access to your e-mail, they can also get access to your website, by using the password recovery feature (or impersonating you to your hosting company). If they delete the e-mails that are coming in before you notice them, you’ll never know what’s going on, and all the password changes and workstation security in the world won’t help you.
• Don’t use shared hosting. (Vectors 1 and 3). This might seem an odd thing to say, given that we sell shared hosting, but it is a legitimate way to reduce your vulnerability. If you use a dedicated server (including a VPS), you (or we) can configure it to only allow logins from certain IP addresses, rather than the entire Internet. This means that even if an attacker does get your password (or SSH key), via brute force or sniffing it off your workstation, they can’t login from their own machine because it won’t have an authorized IP address. On shared hosting, this configuration is impractical, because hundreds of people have legitimate access to the server, from a great many different IP addresses.
• Code responsibly. (Vector 2) It is said that “PHP is great, because its ease of use means that any idiot can produce a security hole — and most of them do”. Whilst this is a little derogatory to the many (several? few? one? PLEASE?) good PHP programmers out there, it is certainly fair to say that the capabilities of many people who write dynamic code aren’t up to the challenge of writing code that is exposed to the extremely hostile conditions that are the public Internet.

  Thus, if you are not familiar with the common security practices and problems with the language or environment that you are developing for, stop right now and go learn a little. There’s plenty of good information out there on the Internet from people who have learnt the lessons the hard way. Celebrate the benefits of literacy by learning from their mistakes rather than having to educate yourself by cleaning up an infected website. If you feel that isn’t something you can commit to, then please, for the sake of the Internet, find someone else to write the code.

• Keep your web applications patched. (Vector 2) Whilst some sites do use custom-built web applications, many sites choose to use a standard CMS or other application to manage their website. This is great, because hopefully someone else is taking a bit of responsibility for the security of the software, but that doesn’t do you any good if you don’t keep it up-to-date. Far, far too many people install a CMS once, then forget about it. Almost all of these applications have a vulnerability at some point, and not keeping them up to date is absolutely fatal, because once a vulnerability is found in a piece of software, an attacker can typically use Google to find all of the publicly-available instances of the vulnerable software, and quickly attack them all.

  This means that you need to keep yourself well-informed of any security updates for your off-the-shelf web applications. Subscribe to a relevant security announcements mailing list, or ensure that your vendor sends them to you. (If your commercial CMS vendor doesn’t have this ability, find a new CMS vendor).

Websites get compromised all the time, by a variety of methods. You should reinforce your defences, lest you’re the next target.

1. The first person to mention Kerberos or other unused-in-practice authentication schemes in a comment gets a free laughing at. If you think SFTP and SCP aren’t supported in widely used web development programs, try finding something that supports GSSAPI…

At Anchor we’re mostly systems administrators, not web developers, so the content of the sites we host isn’t usually any of our concern. Occasionally, though, a particular site design happens to catch someone’s eye and provides a chuckle for everyone in the office.

As a sort of counterpoint to our previous post about good design, there’s a certain popular… style… of website design that will probably be quite familiar to some of our readers. It’s really best described by providing a (very entertaining) example:

http://www.clickhereyouidiot.com/

We’ve been using Nagios to monitor an ever-increasing number of services on all of the servers that we own at Anchor for a number of years. For the most part the things we monitor have a focus on those that a systems administrator (us in other words) has to deal with. This includes things like CPU load, memory usage, disc space availability, swap usage, server load, availability of core applications such as web servers, data base servers, mail servers. On a given server we typically monitor anywhere from 5 to 25 different attributes.

The end goal of all this monitoring is to ensure that the services on the servers we run are always working.

We can take this a step further though, rather than just monitor the components of the server that are required to keep the websites running, we can monitor in quite detailed ways many of the components of the websites themselves.

At the end of the day, having a monitoring system tell you that a server is healthy and all of the applications are working only goes so far. Ultimately what’s important (to our clients) is that the website is behaving the way that they expect it to.

Since we don’t build any of the websites that we host unfortunately we can’t put in place systems to monitor the innards of an application. To do so requires an intimate knowledge of how the application was built. We do however have a very powerful monitoring system and if the developers of the websites put the hooks into their code, we can monitor these hooks so that both Anchor and the developers can be alerted to the problems.

With these hooks in place, in many cases Anchor will be able to fix the problems, but if we can’t at least we notify the client that there’s a problem (even if it is at 2am in the morning).

In our world, the more monitoring we put in place the greater the uptime of services and the happier our clients are. On this one though, we need our clients’ help. For all Anchor customers on a Fully Managed support pack we do our side of the monitoring free of charge, and for everyone else we can do anything – for a small fee of course.

To help people understand what can be achieved with web application monitoring along with some implementation ideas, we’ve put together this article on website monitoring.

If you run a website for commercial purposes, you know that the only way it’s going to provide you with benefit is if people actually visit it. Regardless of what sort of site it is (brochure, company promotion, online store, etc), if nobody’s actually loading the pages, your site may as well not exist. One way or another, you need to drive people to your site.

There are many different ways to get people to visit your site, and different strategies work for different sites. TV advertising, for example, has become popular in the last couple of years, to entice people to just visit the site. Other traditional forms of advertising, as well as online banner or text ads, are also popular. Putting your website name on your stationary and vehicles, and promoting your website to your existing customers works well in certain markets, too.

However, I am fairly confident that regardless of what industry you’re in, search engines make up a fair portion of your incoming traffic. More than that, though, it’s almost certain that one search engine in particular is driving the majority of your search engine-sourced traffic: Google.

For example, the operators of the popular developer question-and-answer forum Stack Overflow recently published some statistics on their sources of traffic:

Currently, 83% of our total traffic is from search engines, or rather, one particular search engine:

Search Engine	Visits
Google	3,417,919
Yahoo	9,779
Live	5,638
Search	2,961
AOL	1,274
Ask	1,186
MSN	1,177
Altavista	202
Yandex	191
Seznam	103

[...] Google delivers 350x the traffic to Stack Overflow that the next best so-called “search engine” does. Three hundred and fifty times!

These numbers are almost certainly skewed more heavily towards Google than your average website, because the sort of people who benefit from Stack Overflow (software developers) are also the sort of people most likely to use Google over another search engine, but even if 100 times more people in the general population used a different search engine (and let’s face it, that’s not particularly likely), Google would still account for three-and-a-half times the incoming traffic of the next best search engine.

As a result of this massive traffic skew, if your business relies on search engine traffic, the main search engine you need to be targeting is Google. While there are seemingly endless parades of shonky search engine optimisers who will submit your website to “thousands of search engines”, the simple fact is that if all these thousands of search engines are providing you with the same proportion of traffic as “Seznam” (the 10th search engine on Stack Overflow’s top 10 list), then you’d need to be listed on over 33,000 search engines to match Google’s traffic contribution. Or, you could just make sure Google likes you, instead, for far less effort and expense.

This reliance by the world’s online population on one search engine isn’t necessarily healthy, though. As Whimsley describes in his excellent article, Mr Google’s Guidebook, Google has fundamentally changed the way the Web works, and in many ways it now dictates how websites are designed and marketed. The very fact that we are talking about “making sure Google likes you” and optimising your website for the Google indexer strongly suggests that Google is, in fact, “more a master than a servant”.

Philosophical arguments aside, though, you can’t afford to ignore Google if you want your online business presence to succeed and work for you. What can you do?

First off, I’d like to discuss the use of professional SEO (Search Engine Optimisation). While there are a few firms out there who do a decent job, it is a huge market for lemons. It is incredibly difficult to assess the actual value that an SEO is going to give you, in advance.

As a technical person, I’ve dealt with implementing the recommendations of a lot of dodgy SEO people over the years, and it’s not pretty. A lot of what SEO “experts” recommend are things that Google themselves have specifically debunked, like the virtual hosts vs dedicated IP address myth. Other times it’s doing things that Google specifically warns against, like buying links to boost your pagerank.

In several cases, I’ve seen a client of mine hire the services of a shyster, who has done everything that Google advises against, to provide a short-term benefit. The customer’s site shoots to the top of the Google rankings, the customer is pleased, and pays the SEO a big chunk of money. Some short time (less than a day, in one infamous case) later, the customer’s site disappears from Google’s index entirely. The SEO doesn’t care — they’ve got their money and are onto the next victim — but the customer’s website reputation is in ruins, as Google has detected all of the dodgy work, and has blacklisted the site from their indexes. Cleaning up from this mess can cost you many thousands of dollars directly, as well as lost revenue from people not being able to find you. In many cases, it can easily kill your business completely.

The simple fact is that there’s no real secret to SEO. Google is quite open in many ways about how it ranks pages, and what benefits and harms a site’s rank. It has a whole part of it’s main site dedicated to disseminating information to webmasters about how to do better in the site rankings, and what to avoid doing. You don’t need a professional SEO to tell you these things — there’s nothing secret about it all, and not even anything particularly difficult. However, if you do decide to hire a professional to help, here’s a few tips to make sure you don’t end up doing more harm than good:

• Avoid anyone who talks about “thousands of search engines”. While Google isn’t the only search engine out there, there isn’t more than a half dozen or so that actually matter on an individual basis. Most of the reputable work that is done to improve your ranking in these mainstream search engines will also automatically help other search engines, too.
• If you know any other online business owners personally, ask them if they’ve had any SEO work done, and get recommendations. If their search rankings have been consistently improved for three to six months after the SEO has been paid and left, then there’s less likelihood that they’re a fly-by-night shyster, and they may be worth using for your business.
• Never, ever let an SEO modify your site content directly. Not only might they do deeply disreputable things to your site’s content without giving you any way to easily check what they’ve done, but if their work conflicts with your site designer’s work or processes, it might cost you a lot of money to fix. Having the person who did your site layout and content work review any SEO recommendations can also act as a filter against the worst excesses of a bad SEO.
• For every recommendation that an SEO makes, ask for a citation regarding the legitimacy of the recommendation. If the SEO can’t show you where on a search engine’s site it recommends doing a certain things, then the chances are it’s a dodgy practice.
• Do some research of your own on any recommendation you feel might not be above board. Don’t take the SEO’s word for it that it won’t cause you problems down the line.
• If an SEO says they’ve got “secret” information about how a search engine works, run like hell. Nobody’s better at keeping secrets than Google (they’ve got 10,000 employees, yet nobody outside the company has any idea how many servers they use — is that good secret-keeping, or what?). The chances of a given SEO really having secret information is very slim indeed, and even if they do, the search engines can always change the way they do things to punish your site for gaming the system. It’s just not worth it.
• If possible, have a trusted technical person (such as your website designer, or your hosting company) review the recommendations of the SEO. While it might cost you an extra couple of hundred dollars to have this checking done, what is the cost to your business if your site was blacklisted by the major search engines for doing dodgy things?
• Try and get a longer-term contract for an SEO’s services, one that involves periodic payments over a 3-6 month period after the initial optimisation work has been done. This will tend to discourage the shysters, as their business model is one of “do some quick work, boost rankings temporarily, grab the cash, and get out before the whole thing falls apart”. A trustworthy company is far more likely to be happy with a longer-term relationship.

Whether you hire a professional or go it alone, it’s good to educate yourself a little about what sort of things the search engines recommend. Some excellent resources on this subject include:

• Google Webmaster Central — the start page for anything related to improving your site in Google’s eyes.
• The Google Webmaster help center — a collection of helpful articles about the how, what, and why of designing a site to be Google-friendly.
• The Google Webmaster blog — chock full of interesting articles and tips for webmasters.
• The Google Webmaster Dashboard — a fantastic resource that lets you peer into all the information that Google has about your site, like how many links there from other parts of the web to the various pages on your site, whether the crawler has had problems finding some of your site info, how your sitemaps are helping, the effects of robots.txt changes, and removing pages from the index that you don’t want showing up in search results.
• The Google Webmaster Forum — where you can ask questions of other website owners (and Google employees), and find out loads of useful information on topics that you’ve probably never even thought about.

Yes, all of those links are Google-specific, because Google makes all this info easily and clearly available, and you get the most bang for your buck by targetting Google. Most good site design ideas will help with other search engines, too, so following Google’s advice will benefit you in general.