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!
Excellent blog post – very well balanced discussion. Rgds Vince
oufff, ena swro skatoulakia exeis grapsei edw mesa , alla tipota sxetiko me nyxia ,mallia , tsades , klp 🙂
starouko mmmmmmmmm……..
akoma kai edw se vrika:-)
plaka plaka dievrine tous orizontes s kai grapse kai kati sxetiko me emas ta koritsakia:)
makia,,,,,
Xoxo! 😀
I think that you should follow kamy’s advice! 😛
Nice post!! A small readme.txt would be helpful. I mean where to place this file? How to execute? how to automate?
@Raju: Well it’s a perl script and you need to be a bit familiar with that. In a nutshell, what needs to be done, is to be placed in any folder (preferably not web accessible) and add a cron job calling the script. That’s all you need to do.
Thanks stratosg for this compromise checker. Though I am a bit shaky in the Perl ground as of now but I will try to implement it. 🙂
I think this post from Jean will be of some help
http://www.wprecipes.com/using-cron-to-schedule-events-in-your-wordpress-blog
@Raju: As i said in the post, you don’t want WordPress to look after WordPress. I mean, if the security of the system is compromised, the intrusion detection system can’t be on the exploited system, it should be separate, or else it wouldn’t be of any help. That’s why i didn’t write this in PHP, or even better (or worst), making it a WordPress plugin. Thanks for giving some feedback though 😉
Great idea statosg.
I have downloaded it. I know perl so, i will try to understand it and put it on my blog and let you know if i have any doubts or suggestions.
This is brilliant stratos, so much so that I’ve stumbled your post. Can the script reside in the wordpress folder? Also as I have 9 blogs I assume I need to have it on each and every one of them.
@Sire: Well it would be better if it didn’t reside in that folder for security reasons. If someone exploited your WordPress you wouldn’t want him taking down your security mechanism 😉 As for having it for all the blogs, that’s the beauty of it. You just tell the script to keep an eye on the parent folder (for instance public_html) and it will check aaaaall the files!
So, one script can check all the files in all the blogs? And if it finds a problem it will be that specific in pointing out the file?
@Sire: Aha, it sends you a detailed report saying which have been added, removed and changed with full paths to the files so you know which one exactly it is!
I will definitely give this a go. Get ready for any problems I come up against. 😀
@Sire: I am here if you need me!!
Stratos, because I have 9 blogs, do I separate the path to each blog with a comma, and does it need the complete path including http?
Also why is there a from and to email address?
@Sire: The path you need to include is not the web one but the one in the system that’s hosting you. It should be something like /home/… If you can’t find it let me know and i will write a script that will reveal it for you. As for the email addresses, the from is the email that you will be receiving from and to probably is yours 😉