Monitoring your WordPress install with tripwire
You’ve installed WordPress, and you’re diligently upgrading with each new security fix that’s released. What happens if your install is compromised by a successful but previously unseen attack? What parts of your install has the attacker tampered with and which files can you trust? Will you notice the attack at all? A class of tools called file “integrity checkers” can monitor your WordPress install for unexpected and unauthorized changes. In this article I’ll show you how you can use Tripwire, perhaps the best known of these tools, to do just that.
Tripwire is available as a package for most Linux distributions. Assuming you’re using Debian, Ubuntu or something similar, simply:
# apt-get install tripwire
We’ll not go into full details on how to configure Tripwire, you should read the documentation and manual pages provided with Tripwire for more information. Let’s concentrate on the important part, a policy that monitors your WordPress files. In my case I’ve edited /etc/tripwire/twpol.txt to read.
#
# Global Variable Definitions
#
# These definitions override those in to configuration file. Do not
# change them unless you understand what you're doing.
#
@@section GLOBAL
TWBIN = /usr/sbin;
TWETC = /etc/tripwire;
TWVAR = /var/lib/tripwire;
#
# File System Definitions
#
@@section FS
#
# WordPress Files
#
(
rulename = "WordPress Installs",
severity = 100,
emailto = james@freecharity.org.uk
)
{
/var/www/main -> $(IgnoreNone);
/var/www/main/wp-content -> $(Dynamic);
/home/james/public_html -> $(IgnoreNone);
/home/james/public_html/wp-content -> $(Dynamic);
}
This policy protects two WordPress installations. One in /var/www/main and another in /home/james/public_html (in reality my configuration file protects over fifty similar installs).
The policy reports on any change to the core WordPress files. For the wp-content directories we use the Dynamic keyword. This tells Tripwire to be less concerned with minor changes such as file sizes (see the twpolicy man page for more details). You might wish to ignore this directory entirely. Change the line to read something like.
!/var/www/main/wp-content;
Compile your Tripwire policy with
# twadmin --create-polfile -S site.key /etc/tripwire/twpol.txt
and initialise your Tripwire database with
# tripwire --init
To check the integrity of your WordPress files you can now run
# tripwire --check
Tripwire will now check the integrity of the files specified in your policy. If you’re unlucky the resulting report will contain something like:
------------------------------------------------------------------------------- Rule Name: WordPress Installs (/var/www/main) Severity Level: 100 ------------------------------------------------------------------------------- Modified: "/var/www/main" "/var/www/main/index.php"
It looks like one of the core WordPress files, one that’s not meant to change ever, has been tampered with. It’d be best to take a look over the file and compare it with a known good copy. Once you’re happy that everything is back to normal you’ll want to update Tripwire’s database so that reported changes are ignored in future checks
# tripwire --update
That’s it. Let’s hope that you never have to make full use of the facilities that Tripwire provides. It’s no substitute for keeping your install up to date!
What about Windows platform? Any equivalents?
The commercial version of tripwire is available for Windows systems.
This seems a bit complex. Are there any WordPress plugins that can detect unauthorised changes to files?
I had two websites hacked last month and Google Webmaster Tools sent me an alert within hours – but I still had to work out which files might have been altered.
You could write a similar system as a WordPress plugin, but I’m not sure how useful it would be. If you don’t trust the integrity of your WordPress files, you can’t trust the output of any plugins it runs. That’s why I didn’t write this as a plugin.