Boosting Site Security To Protect Search Rankings

Add Your Comments

Website security is not just about credit card numbers. Hackers can exploit the same security vulnerabilities to inject adware and malware into your website. Google’s creation of PageRank, and the resultant creation of link equity, has created a black market for unethical search marketers who inject spam links using similar methods. In fact, this exact thing happened to Al Gore’s blog in 2007 where suddenly Al Gore shifted gears from global warming to Viagra and Tramadol.

This kind of exploitation can be even more damaging long-term than data-theft, as it can result in permanent degradations in site rankings or — worse — a total delisting from all of the major search engines. At that point, one is tasked with filing re-inclusion requests, while further damage may occur as various anti-virus and anti-phishing softwares prevent access to the website with stern warnings about dangerous content.

Every search marketing firm or proprietor maintaining a website or a blog must by now be acutely aware of security vulnerabilities. It is a liability for the marketing firm, the vendor, and of course is in the interest of nobody — except the hacker.

Frequently hackers do not target particular websites. Even Al Gore’s blog mishap may not have been targeted at “Al Gore” in particular. Rather, hackers target a flaw in a web application that is widely installed on websites in a vulnerable state — usually an older version. Some hackers know little about security or even computing at all, and use pre-fabricated hacker scripts written by more those more experienced who subsequently leak them. Whatever their skill level, to help keep hackers from exploiting your website, begin with this three-pronged approach to safeguard your search rankings.

1. Consider The Security History Of Web Applications And Partners

When choosing web applications and hosting, consider both their historical and recent security records. For example, one commonly attacked application is phpBB, which is a popular forum application. Its security improved substantially recently, but both distant and recent history favor vBulletin, another popular forum application. Provided that vBulletin meets your requirements, and the small cost can be written off to security, it is a much better choice. A flaw in phpBB might not only expose information within the forum, but may also provide a backdoor to inject adware, malware, and links, or expose information from an e-commerce database running on the same web server.

Web hosts have also come under fire for lapses in security. If a website on a shared hosting plan is hacked — perhaps because that particular site neglected to upgrade one of their vulnerable web applications, your website may be vulnerable as well. Ideally, a web host should audit their web servers and recognize when such attacks occur. Unfortunately, with web hosting such a hyper-competitive commodity, one must decide if it is reasonable to assume that the host will respond quickly and properly with experienced system administrators if you are paying as little as $3.65 per month for your hosting package.

The Department of Homeland Security maintains a software vulnerability database at http://nvd.nist.gov/home.cfm. One can roughly evaluate the recent history of a particular application, as compared to a competitor, by simply counting the number of reports. This can be misleading, however, and should also be measured against popularity. Additional third-party modules or plug-ins should not be counted, unless they are actually installed.

While it is impossible to predict which web hosts may have a security lapse, it is worthwhile to investigate a web host’s security record by searching for historical user reports widely corroborated in the blogosphere and forums.

2. Invest Time And Money In Preventative Security

Unfortunately, most investments in web application security — whether they are actual products or time — are reactionary rather than preventative. A dentist might relate to this, as many patients only visit when pain strikes. And, of course, a root canal is much more painful, invasive, and expensive than a simple filling.

This means investing time in keeping applications updated. Pay your developers to upgrade at planned intervals, or make sure to do it yourself. Be proactive and add the application’s RSS feed to your feedreader to keep apprised. If you are part of a large firm, task someone to head security maintenance, and require reports. The return on investment in security is measured by what does not happen, rather than what does.

It’s not just about passwords, either. Obviously one should have policies in place that require changing passwords periodically and disallowing obviously weak passwords or those appearing frequently in lists of passwords circulated among hackers. But some software flaws expose data or allow modifications without appropriate credentials. Many do not require a user name and password at all. These attacks rely on a flaw or logic-error whereby data passed to the application is not inspected carefully, so that program code is inserted into your application. The result may be a complete compromising of the application. For example, the insertion of links to Viagra sites and spyware may now be only a few convenient clicks away from a black-hat-search-marketer-turned-hacker, with no password required.

Hardware solutions exist to address this, as do software solutions. Cisco and Juniper Networks make several powerful hardware-based firewall solutions, and larger companies may choose to go that route. Mod_security for Apache allows an experienced server administrator to protect web applications with a configuration file. These involve a substantial investment in money or time.

Some solutions are easy-to-implement and free. The PHP intrusion detection system (http://php-ids.org/) is a powerful generic security layer that can be installed within any PHP web application, and the “WordPress Firewall” plug-in (http://www.seoegghead.com/software/wordpress-firewall.seo) helps those using WordPress for blogging, with some WordPress-specific checks tuned for current versions. Of course, these types of products won’t entirely replace prompt and responsible upgrading, but they may mitigate most attacks and let administrators sleep better at night.

After several attacks, some victims of software exploitation even refuse to install a blog or forum on the same server, citing damage done in the past. This is despite the fact that many would have chosen a subdirectory for the blog (e.g., domain.com/blog/) rather than a subdomain (e.g., blog.domain.com) on the basis of SEO. The proper steps, including some of the above, may alleviate those concerns, allowing the decision to be made solely based on search marketing considerations rather than fear, uncertainty, and doubt.

3. Sandbox Applications To Mitigate Risk

Damages can be further mitigated by “sandboxing” the application with a reverse proxy. As previously mentioned, a hack or exploit affecting a blog or forum running on the same web server can make your entire website just as vulnerable as it is. Using a different database with different passwords helps, but not as much as completely sandboxing it by running it on a different server. You might upgrade a day too late. If it’s sandboxed, your blog may be exploited, but other parts of the website are entirely safe from link and spyware injections, as well as data-theft.

The idea is to run the application on a completely different web server called “internal.yourcompany.com” in “/blog/” and then proxy all requests from “yourcompany.com/blog” to the internal web server. The two websites must be placed on two different physical machines, not just different hosting accounts. Install the blog in /blog/ on the internal server. All requests to /blog/ on the external server are then proxied to and from it. Apache version 2.x is required. The following lines must be added to the external server’s httpd.conf:

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

The blog server will run without any configuration modification — just tell it that it is also yourcompany.com as a VirtualHost. It may be running any version of any web server. Other approaches to reverse proxying can be found at http://seoegghead.com/blog/g.tiny.

Conclusion

Just like SEO, security should be at the forefront in a comprehensive marketing campaign. While it may be impractical to implement all of the above, one should select at least a few of these guidelines and put them in place. A lackadaisical security policy could very well lead to injected adware or malware, or spam links — all of which could result in a permanent degradation in site rankings and overall marketing performance.

About the Author

Jaimie Sirovich is a search marketing consultant. Officially he is a computer programmer, but he claims to enjoy marketing much more. At present, Jaimie is focused on helping clients sell everywhere, and achieve multi-channel integration with major websites such as eBay, Amazon, and even Craigslist. He is the author of Search Engine Optimization With PHP. Jaimie can also be reached directly at jaimie@seoegghead.com.

Add Your Comments

  • (will not be published)