There has been a lot of hype lately concerning WordPress security and vulnerabilities that are out in the open. This is an open source project so the big advantage is that (and i will quote):

Luckily, the entire WordPress community has our backs.  Several folks in the community dug deeper and discovered areas that were overlooked.  With their help, the remaining issues are fixed in 2.8.3

This is the heart of any open source project. Since the code is out there in the open, many can take a look and, therefore, discover any potential issues.

Now, i know that many users think that, whenever a new version comes out, they should let other people do the upgrade, check it out and then, they will go on with it. This might be the case with major versions (for instance 2.7.1 -> 2.8.3 as we speak) but it is definitely not the case when we have security patches and fixes (for instance 2.8.1 -> 2.8.2). In these situations, if you don’t upgrade, it means that your WordPress installation is compromised to an outside attack and you shouldn’t be surprised if that happens.

But, does being updated to the latest version, mean that you are absolutely exploit-free? Unfortunately, not. You can never be sure. Not with open source, not with closed source. Never. You never know what someone can come up with to bring down your service. Being updated minimizes that to the absolute minimum, but there is still a chance that it may happen.

Focusing back on WordPress, a very popular exploit is that of the hacker adding his own chunk of code to the core of your installation, hiding it fine. The privilege of that is that they can insert anything they want, for instance, an affiliate link of theirs or a link to a site that contains malicious software, thus their code will be downloaded and executed by every visitor of yours. This is not the only thing an attacker can do, of course, but it is a large portion of the consequences (see this example).

This kind of attack is very hard to spot. It actually does not affect the execution and rendering of your blog, so you have the feeling that everything is OK, when it’s certainly not. What’s worst is that when it happens it’s even harder to come up with an immediate fix, since you don’t exactly know what the attacker has messed around with, resulting to a complete blog reinstall, restore of the backup, and all the troubles surrounding the process.

One good way to detect, therefore have a chance to fix, such an attack is an Intrusion Detection System. From Wikipedia:

In Information Security, intrusion detection is the act of detecting actions that attempt to compromise the confidentiality, integrity or availability of a resource.

There are many tools focusing on protecting the integrity of the system, such as Tripwire, AIDE etc. All of those are focused on securing the whole system, meaning the box that hosts your site, including your site. The idea behind these systems is this:

  • Once installed, they check the files that already exist on the box and their hashes (so they know what exactly they look like).
  • Every now and then, the program makes a check for files that have been added, deleted or changed (using the hash to determine that).
  • If there is a change an email alert is sent to the administrator.

Using this idea, but in a smaller scale, i built a smaller program, using Perl, focused on protecting your sites. Here is how it works:

  • You define the home folder of your site(s).
  • You define any subfolders you don’t want the program to keep an eye on (for instance the cache folder that constantly changes).
  • You define an email to get the alerts.
  • You add a cronjob to your system executing it in any interval you feel safe.
  • Once it detects new/deleted/changed files it alerts you with a detailed email of all those files.

This way, if someone tinkers with your files, you will be alerted and then be able to take appropriate action. There is no meaning for me to post the code here. I have included the whole thing for download [download id=”14″]. To configure it, you need to edit lines 170-173. Other than that, it’s ready to fly.

I know that there are some of you out there wondering why didn’t i make it a WordPress plugin. Well, if someone compromises your security, do you want to keep your alerter on the compromised system? You probably want it running independently. That’s why it’s Perl and i strongly suggest keeping it on a folder that is not accessible, neither writable by the webserver.

If you have any problems setting this up, need help, found any bug, have any suggestion etc i’d really love to hear about it!