Originally written by Mark Evans at www.gllabs.org

Hardening a site refers to preventive actions you can take to secure your site. Geeklog developers and plugin authors take security very seriously, but as with any other complex system, there are potential security issues that may arise. We’ll look at some preventative actions you can take to keep your Geeklog installation secure.

Running a secure website is always a challenge and at times can seem like a full time job. Most of us are not system administrators, instead we are folks who just want to web site. Our challenge is how do we keep our Geeklog powered website as safe and secure as possible.

Geeklog is already a very secure platform. If you look at the number of Content Management Systems (CMS) out there, Geeklog has one of the best track records on security issues. A quick search of the Secunia Security Website shows the number of vulnerabilities reported for Geeklog to be much lower than many of the other popular blogs and content management systems.

This does not mean that Geeklog is the most secure or that it is 100% secure 100% of the time. The bad boys on the Internet are always looking for methods to exploit existing code or circumvent the security controls. So how do you keep a site safe and secure? Using multiple layers of defense and staying informed are the best and easiest methods to keeping your site safe.

Let's look at some of the options you have with multiple layers of defense.

Geeklog is designed so many of the source files are located outside of the web root, so they simply cannot be accessed via a browser. This is an excellent design since the best defense is to minimize the 'attack surface'. Attack surface refers to how many targets are available to a hacker. By having many of the Geeklog core files outside the web root, the attack surface is made smaller.

Many Geeklog sites are installed using tools provided by the hosting service. cPanel, Fantastico and Plesk installers are the most popular. Unfortunately, these tools do not install Geeklog securely. They place everything in the web root which means you now have a larger attack surface. Many sites hosted on the free GoDaddy hosting service also have all the Geeklog files installed in the web root, GoDaddy doesn't give you the option to install anything outside the web root.

The main problem with an installation that includes everything in the web root is; Now all plugin files, your data backup directory, your config file are available through the web browser. These files were never designed to be available via the web browser. Fortunately, the Geeklog team has been very proactive and has placed some security checks in the core Geeklog files to prevent problems on installations like this. But, not all plugins do the same checks, so there is a risk.

How can I remove this risk, I can't change hosts and don't want to do a manual Geeklog install?

Well, there are a couple of options. There is a FAQ entry at Geeklog.net that describes a more secure method to install Geeklog entirely within the webroot. This will definitely help those who host on free GoDaddy accounts.

If you used Fantastico/cPanel, you can still implement the steps in the FAQ but it does require moving files around on the server. Also, it may well break future upgrades through the install tool. My recommendation would be to do a manual Geeklog install. It really isn't that difficult and there are lots of folks willing to answer questions in the Geeklog forums. Also, there are several folks who will do the install for you for a small fee.

Plugins can offer a great addition to your Geeklog site but they can also offer new security challenges. As much as I pride myself on being security conscious, even Media Gallery, my flagship plugin, suffered from a security vulnerability a few releases back. The plugin development community has been pretty good about security in their software, but plugins don't get the same broad exposure the core Geeklog distribution receives. Also, most plugins are developed by 1 or 2 developers instead of a team like Geeklog, so the peer review is a little less. I'm not saying you should not run plugins, instead, just be aware they offer an additional attack surface. I always recommend that you should only install the plugins that you need. Do not install extra plugins if you do not plan on using them. Fortunately, if there is an issue with a plugin, the fix is generally available very quickly and is usually easy to implement.

Make sure you have register_globals=off in your PHP configuration. Recent version of Geeklog no longer require register_globals to be on. By turning register_globals off, you eliminate the ability for remote hackers to pass configuration data to your site. This is just one step in the overall hardening process.

You may run into some older plugins that still require register_globals to be on, personally, I would recommend you not run them. If it is a must have feature, contact the author or post on Geeklog.net or gllabs.org and maybe someone will either update the plugin or there could be an update available.

If you are not sure how to turn register_globals off, contact your hosting providers technical support. Let them know you want to ensure this is turned off in the PHP configuration for you site. They should be able to either point you in the right direction or take care of it for you.

If you have access to the .htaccess file for your site (again check with your hosting provider for specific details), you can filter some known bots so they will never gain access to your site. I analyze several web server logs files from all over the Internet each day. What I've found is that a large majority of attack attempts originate from scripts using a tool called libwww-perl. If you block that user agent, you will immediately eliminate many of those script-kiddies from gaining access to your site. This does not block all hack attempts, but it will certainly reduce them.

You can also filter for most common exploits, anything referencing the _CONF variable, some of the standard root shell attacks and the libwww-perl tool.

  RewriteEngine On
  RewriteCond %{HTTP_USER_AGENT} libwww-perl [OR]
  RewriteCond %{QUERY_STRING} _CONF [OR]
  RewriteCond %{QUERY_STRING} tool25 [OR]
  RewriteCond %{QUERY_STRING} cmd.txt [OR]
  RewriteCond %{QUERY_STRING} r57shell [OR]
  RewriteCond %{QUERY_STRING} c99
  RewriteRule ^.* - [F,L]Bad Behavior 2 Plugin

This is one of the best little tools out there to help prevent unauthorized attempts to hack your site and also slow down the spam bots. Bad Behavior will analyze the incoming HTTP request and apply several rules to validate the request is coming from a valid user/browser combination. This is not a 100% safeguard, but again it will add yet another layer of protection to your site.

Install the CAPTCHA plugin. While CAPTCHAs can be annoying, right now it is proving to be a very effective tool in stopping spambots and other attempts to register users on your site.

Finally, and probably one of the most import steps you can do, subscribe to the Geeklog Announce Mailing list and see if the plugins you use have a similar alert system in place. When there is a new exploit for Geeklog or any of the plugins, the mailing list can provide you notification as soon as the exploit is know and fixed. The quicker you can apply the fix, the better! I still see attempts at exploits that were identified over 2 years ago today.

By implementing the tools and methods mentioned above and staying informed, you can easily run a secure site with minimal effort.