How Website Security Impacts Search Engine Optimization

If you are looking for help with “secure site SEO” this article discusses Website security. One of the SEO services that Randy Ray and I provide for clients is a review of Website security. On a happy Web no one would be trying to exploit loopholes in Internet services but the “commercial” hackers are chasing potentially billions of dollars in revenue and the “state” hackers are trying to dominate the Web.

There is nothing you can do to prevent someone from trying to break into your site. You may be able to lock it down so they cannot get in, but their attempts to crack your passwords can still cause problems. I have discussed these issues at length on the SEO Theory Premium Newsletter. When your Website is down or labeled as being infected with malware, that costs you money.

Let’s take a look at some of the issues a senior SEO technician should be able to delve into. It would be good experience for less experienced SEO techs to master these skills as soon as possible.

Server Exploits

There are different types of hackers out there. Some are just counting coup on Websites and though their hacks are annoying and cost you money they don’t leave anything malicious on your server. Of course, you cannot trust any hacker to be “good” but the worst hackers are trying to get in to convert your server into a command-and-control center, a “masterbot” that will control other zombified computers on the Internet.

These guys are looking at all your Internet-accessible services: email, FTP, Telnet, and Web. Anything that gets them into the UNIX/Linux environment with admin access or even just executable access gives them an advantage over you. They’ll do everything possible to hide their tracks and slip into the woodwork. And there is a LOT of woodwork on a UNIX or Linux system. A typical server may be running 200-300 processes on a slow day. You’re not going to recognize all of them.

An exploited server can be used to send or reroute spam email, set up a remote-host chain (think of telnetting to one server and then using that server to telnet to another), host an entire domain or Website without your knowledge or permission, conduct brute force dictionary attacks on other servers, download malware to Web visitors’ computers, find and infect other vulnerable servers, act as an FTP gateway or transfer point, or disrupt the Domain Name Services (DNS) data being passed around the Web (to hijack Websites or attack them).

If a hacker wants to investigate you or your company then breaking in to your server may give them access to your email and confidential intranet files. This latter exploit is more dangerous to your success because if you’re storing customer information on the server you expose them to potential identity theft and fraud, not to mention email spam.

Don’t Keep Email on the Web You would think this is common sense but way too many companies (including some “security experts”) leave their email on Internet-accessible servers. Your company should always be downloading its email to internal servers that cannot be accessed from the Internet. If you don’t have a company that large then you and your users should be downloading your email onto your PCs. Leaving email on a server means all your password recovery emails are exposed every time someone gets in.

Restrict Server Access It is possible to limit who can get into the administrative accounts on an Internet-accessible server. Doing this at least prevents the hackers from exploiting vulnerabilities (but you should still remove the email from that server after downloading it).

Web Application Exploits

Any blog, forum, or content management system can be attacked. Right now WordPress is getting all the attention because a recent exploit created a fast-growing botnet that is expected to grow into the millions of infected Websites within a few months, maybe a year at most. This monster botnet is already being used to attack tens of thousands, perhaps hundreds of thousands, of servers across the Internet. The infected servers are using Brute Force Dictionary (BFD) attacks to try and figure out administrator passwords for blogs, forums, and content management systems.

If a hacker can get into your software he may not be able to make himself an administrator on your server but he can probe your SQL database for vulnerabiliies, install malicious HTML code, and subtly change your Websites. Some link spammers hack Websites so they can drop links in random spots (the greedier hackers saturate a site with links, which makes it easy to see what is going on).

All the attacks on your blogs and forums create a massive amount of traffic that brings your server to its knees.

Things That Hide These Problems

If you use a caching plugin for your blogs or forums you may not notice the brutal attacks because your server is able to devote more resources to responding to them. Caching plugins take a snapshot image of your rendered pages an store that image. Whenever someone requests the page they are served the image (a flat HTML file) rather than having to wait for your server to execute all the scripts required to assemble the pieces of the page.

I have used caching tools and while the improvement in performance is really nice they eventually get in the way of good server administration. Even using a Content Delivery Network can complicate your administrative functions. For example, simple “Website updates” take longer. If nothing else you have to manually expire the cache so that the server repopulates it with new images of your updated content.

If you’re mirroring your domain around the world you may have to wait for all local copies of your site to be updated before they’ll go live. You’re also depending on the proxy servers of the CDN to handle Website security and administration — YOUR security and administration only protects your server (account), not your actual page content. CDNs, of course, hire lots of technical people to ensure your sites aren’t defaced but even the CDN industry has been challenged by technical glitches. Don’t assume that any service is perfectly safe from hacking.

Can Any Server Be Completely Protected?

The only server that is completely protected from hacking is one that doesn’t exist.

You can take a server and bury it in the ground underneath Fort Knox and surround it with the US Army’s 1st Corps for security. Any determined enemy who wants that box will mount the resources necessary to overcome all that security (a role-playing gamer would think in terms of, “I would just tunnel under the 50,000 soldiers”).

If you restrict access to a Web server so that only you can get in, you’re still vulnerable to external exploits that blow past your Network Operations Center’s (NOC) firewalls and protocols. A rogue admin at the Web hosting company might leave back doors into the network in case he gets fired (I have never heard of this happening but many a corporate IT department has had to deal with these risks — that is why programmers are immediately escorted off the premises when they are terminated).

And servers that have the ability to telnet to each other, even though they are only “local” machines in a blade server in a NOC, create a potential vulnerability. All it takes is for one hacker to find one way in and then he can explore the network.

There is no complete protection and probably never will be.

Prudent Measures SEOs Should Take

When you take on a client you should ask them about the history of their Web hosting. Have their sites ever been hacked? If so, who was responsible for cleaning up the hacked sites? What processes were followed? It’s your responsibility to yourself and your company to make sure a client site doesn’t infect your computers.

If you are given access to the client’s server (account) it is prudent to do a security review (with their full knowledge and permission), especially if you are auditing the Website. That should include email services.

If you don’t know how to do this, then find a reliable contractor and bring them on as a sub-vendor for a one-time project. This isn’t the kind of work that you can safely do with a manual in your lap (or an online document open on your laptop).

If you’re using Screaming Frog or Xenu Link Sleuth to examine a Website’s link structure, be sure to pull out all the outward facing links. Use whatever software you have to use to find any iFrame references. Even if the client site has not been identified for malware it may be hosting suspicious links and we all know what Bing and Google think of suspicious links.

And find out if the client is unwittingly hosting other Websites they don’t know about. Some SEOs have been known to use Peter’s account to host Paul’s Website (Paul probably being the SEO himself). Even if there was an agreement back in the day, everyone may have forgotten about it.

It’s not necessarily your responsibility to fix the client’s security issues. However, it behooves you to understand what the risks are and to be able to point out vulnerabilities and exploits. This is especially true if you recommend specific platforms to clients. They will understandably want to be reassured that those platforms won’t be hacked. You have the delicate task of explaining to them that “yes, these platforms can and will be hacked” — but there are things they can and should do to protect themselves.

If you’re working with eCommerce clients, yes, there are shopping cart exploits.

If you’re working in social media campaigns, hacked social media accounts are only one vulnerability. As many Twitter users have learned the hard way, clicking on links in private messages may lead to trouble. When you help a client set up a social media campaign you should have a concise checklist of security procedures they need to follow.

And Speaking of Passwords…

When it comes to user account security we use one of the dumbest ideas in history: the account password.

Passwords are cracked every day. Sure, there isn’t much else out there to work with but our password tools are so outdated and built on nonsense it’s no wonder millions of computers are exploited every year.

Obscuring Passwords Protects No One Don’t you hate seeing a row of asterisks as you type in your password? This visual trick does nothing to provide security to your user accounts. Yes, the passwords should be transmitted securely but if you have the ability to turn off the asterisks, do it. People will experience fewer lockouts from their user accounts if they can see what they are typing in. Some people just save their passwords in a spreadsheet and use copy-and-paste when they need to log in. So asterisks are not only NOT securing anyone’s password, they are a leading contributor to preventable lockouts.

Complex Passwords Are NOT Secure Another myth that has plagued password-burdened users is the idea that mixing symbols and case in a password makes it harder to crack. If the hacker is sitting there going, “Hm…maybe he used his kids’ birthdays”, yes, throwing an ampersand or hashbang into the password will confound him. But hackers now use software to go through all the possible iterations of passwords and it only takes a few minutes for the average algorithm to exhaust all 36-56 variations in each position (most of the time required for a BFD attack consists of transmitting the username and password, waiting for the server to respond, and evaluating the response).

LONG PASSWORDS ARE MORE SECURE Yes, folks. “12345678901234567890” is a more secure password then “#PappySays!” because “12345678901234567890” is longer than “#PappySays!”. It’s that simple. If you’re using complex passwords because your host requires them — seriously think about using a different Webhosting provider. If you’re using complex passwords because the “password generator” suggested them, don’t use the password generator.

Your first defense against a BFD attack is the security of your passwords. Length outweighs complexity. But if you want to make complex passwords that actually have a fighting chance against the BFD software…

Salt Your Passwords Salting is the practice of adding extra characters to a user’s password. The user never sees them but when a hacker breaks into your server and downloads the passwords file he sees passwords that are too long. So even if he can decrypt the passwords (and there is open source software that will do this) he’ll still have the wrong passwords. Most tutorials recommend you add 2 characters to a salted password — so guess what I’m going to do if I think I have decrypted salted passwords. Yup, I’m going to shave 2 characters. When you salt passwords, do NOT use the recommended method if you can change the parameters, because any hacker can download that documentation (or steal it).

Every SEO Should Know This

Protecting your hard work and your client’s investment in organic search marketing is important both to you and your client. You don’t want to leave them exposed to being used for spam links, spreading malware, or growing botnets. More importantly, you don’t want to find yourself trapped in an exploit minefield on a client’s server. Once your computer has been zombified everything you do on the Internet may be exposed to some hacker halfway around the world.

Exploited Websites lose money, may cost other people money, and cannot be expected to last long in the search results. The search engines take prudent measures to protect their users and those measures may include removing the sites from their results if the exploits are not fixed. The dividing line between prudent SEO and Website security is easy to cross and you need to be careful not to take on too much responsibility, but at the very least know what is happening and have some recommendations available in case you cannot or do not want to take on the extra work of cleaning or securing Websites.

Get the SEO Theory Premium Newsletter Now ...
Get weekly *Tips *Case studies *Questions & Answers
Subscribe now ...


Follow SEO Theory

A confirmation email will be sent to new subscribers AND unsubscribers. Please look for it!

Click here to follow SEO Theory on Twitter: @seo_theory.

Google Plus: SEO Theory on Google Plus

SEO Theory on YouTube

SEO Theory's RSS Feed (summaries only)