The three components of information security are: Confidentiality, Integrity and Availability (CIA). If you’ve followed the steps my previous tutorial, you’ll have come a long way towards ensuring all three. But you’ll always need to keep an eye on things – remember, no site is hack proof. Here are some tools to verify the integrity of your data. These plugins will not protect your site from attacks, they will only help you monitor your site and diagnose problems.
I have not tested any of these with the latest WordPress 3.0 beta.
In my first article on WordPress security I mentioned Open Source Tripwire as an option for monitoring your WordPress install for unexpected changes. A reader pointed out that it wasn’t the best solution since it’s no longer maintained and suggested a couple other alternatives. Since then, I’ve discovered a much easier way of monitoring your WP install: WordPress File Monitor.
What it does: monitors all the files in your WordPress directory (except the ones you tell it not to) and e-mails you whenever something changes. This means nothing changes without you knowing about it. If someone edits your theme files to include spam links or uploads weird php scripts, you’ll know right away.
Above is a screenshot of the settings I use.
Dashboard Alert: I had this set to yes for a while, but having clear the notification pretty much anytime I made a post (because I upload images, and the sitemap.xml changes) got tedious. Just keep up with the e-mail alerts if you turn this off.
Scan Interval: 30 minutes might be a little too often, I should probably cut this back to something more sane like 2 hours.
Detection Method: My main site is quite large and performance is a big concern for me, so I keep it set to Modification Date. If you’re really paranoid and have a small site, change this to Hash.
E-mail address fields: self explanatory.
Notification format: Detailed. Why would you want anything less?
Site Root: Theoretically, you shouldn’t have to change this.
Exclude paths: I exclude my cache folder (if you don’t use WP Supercache or something similar, you don’t need to worry about this) and error_logs that get a lot of errors. I do have it monitor my Uploads folder in case someone tries to slip an exploit disguised as an image in there somewhere.
I learned about this one from the plugin author in the comments on my original post. As far as I can tell, it scans the core WordPress files and template files for exploits.
You can also have it do a daily scan and send you the results. I don’t do this since I’m constantly monitoring my site for changes with WordPress File Monitor. If you don’t want to monitor every single change in your WP directory, this could be a good alternative.
This seems to do a more thourough scan than Antivirus for WordPress, but I always run into memory problems if I try to run it with the “Files” option checked.
What to do if you’ve been hacked
Detailed instructions will have to wait for a future post. For right now, see the WordPress Codex entry for what to do.
Bonus: greping for great justice
grep is a UNIX command for searching the entire text of a file or files on a computer. If you know the exploit you’re looking for, it’s extremely useful. To do this you’ll need SSH access to your web server, and you’ll need to be comfortable using it.
I had a nightmare of an exploit a while back that I eventually figured out: somehow someone had uploaded a copy of webadmin.php (with a different name so it would be harder to spot) to a few places on my server. They could then navigate straight to that file and change any file on my server whenever they wanted. I found one instance of it and deleted it, and thought that would be that. But I was still finding that my template files were getting edited. Here’s what I did:
1. Logged into my web server by SSH
2. Changed directory to my public directory (you may need to ask your web host where this is)
3. Ran the following command: “grep -r ‘webadmin’ *”
I was then able to locate the file because even though the file had been renamed, it still contained the text “webadmin.” I was then able to delete the file.