Your first step is to be able to easily list the installs you have on your system. You could maintain a list but it’s easier to let MySQL do the hard work for you. Make sure your WordPress databases identifiable by name alone.

The following Perl snippet illustrates how you might list all your WordPress installs.

$sql = "show databases like 'wordpress_\%'";
$sth = $dbh->prepare("$sql");
$sth->execute();
while($row = $sth->fetchrow_arrayref){
	($name) = @$row;
	print $row , "\n";
}

It’s useful to be able to map your WordPress installations to their location on disk. You could record the location of each installation, but it’s probably better to have a standard location. For instance, each install could be found under /home/<sitename> or /var/www/<sitename>.

Here’s the Perl I use to map my database names to directories. The hash allows me to override the standard mapping for a few exceptional installations.

my %dir_exceptions = (
    "foo" => '/var/www/foo/wp',
    "bar" => '/home/bar/public_html/blog',
);
sub wordpress_location {   
    my $name = shift;
    $name =~ m/wordpress_(.*)/;
    $name = $1;
    if(defined($dir_exceptions{"$name"})){
        return $dir_exceptions{"$name"};
    } else {
        return "/var/www/$name/";
    }
}

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!