How to really secure WordPress for a remote blog

EDIT: downloading the nice plugin recommended in this post will now break your blog if you’re using WordPress 2.5 – the wordpress authors have made some incompatible changes. But it’s OK – bengreen has fixed the plugin, and made a new version available (read here for some very basic information on what will break and idiot-proof instructions on how to fix it)

I had a nasty shock when I realised that wordpress by default has no security at all. Anyone in your office who doesn’t like you and has a basic knowledge of using google can potentially steal your admin password and take complete control of your blog. This is, really, pretty mind-blowingly stupid – I love wordpress, but “no HTTPS support out-of-the-box” is frankly irresponsible, especially for a product used by so very many people across the world. The only good part is that AFAICS on a quick glance there’s no easy way of taking control of the entire webserver if you’re the wordpress admin (plugins still have to be manually uploaded, so you’d need separate access to the server to manage that).

What follows is a discussion of how to fix this, along with links to step-by-step guides that worked well, and an extra note on how to complete the process without doing the “login once insecurely” that all the guides tell you to do at the end.

But there’s little of interest on my blog, and my office is very good at preventing the kinds of things you’d need to do to snoop passwords, so I wasn’t unduly worried.

Until I went away to a conference, and wanted to write a blog post. That still didn’t worry me much, the chances of someone hooked onto the same network picking up my traffic are very small. But … although my hotel has flat rate fast wireless internet (excellent!) it has *no security at all* on the wifi. This, again, is pretty stupid – although fortunately they are sensible enough to warn you of this with a forced webpage you have to read before you can start using it. Good for innocent / naive users.

Sitting in a large hotel in downtown Austin TX with a major road next door and big carparks with a fat flat-rate internet connection with many out of town guests doesn’t make me comfortable: if I wanted to steal accounts, I’d go sit in the back of an SUV in that carpark and not expect to have to wait long before getting lucky.

I had already chosen not to use any “important” websites that don’t use SSL for login. Yes, you could snoop the gmail messages I’m reading but I don’t really care – nothing commercially sensitive goes to gmail, that all stays in the corporate VPN – so long as you can’t snoop the password.

LinkedIn, Gmail – everything’s fine. Using password protection (i.e. they use HTTPS for login). Sadly, although WordPress’s authors do seem to have grasped this basic concept (that a password is NOT a password if you send it via HTTP), they don’t make it part of wordpress itself.

So, as an exercise, I tried to secure my wordpress blog remotely, without compromising myself in the process. This is not quite so trivial as you might expect, because the only way you can install the HTTPS-enabling plugin is … to login insecurely and give away your password.

Now, obviously, you could do that and then very quickly login securely with the same password and change it. And that would be safe, because a committed password-sniffer is going to spend a long time automatically “harvesting” passwords and only come back to try using them some hours later.

But I wondered if I could do it from scratch. I brought with me the one essential component to having any chance at this – the USB key that contains my login key for the root account on my server. That’s right – it’s not possible to ssh in to my server unless you have possession of my USB key. And you have to know a password too, of course. With this in hand, and the copy of putty.exe on there that I know hasn’t been infected with a trojan, I could safely access my server from any wifi connection and no-one could get my password, or even (and this is the key point) see anything at all I did whilst logged in to my server.

For future reference, and the benefit of any readers, some quick linkification to excellent resources on making this work from scratch, on Debian (if you don’t use debian for your server, you don’t deserve to have a server :). Seriously, there’s good reasons that professional sysadmins tend to only use Debian for their personal servers and no other distro).

1. Install apache (you’ve already done this, it’s your webserver)
2. Install WordPress (ditto)
3. Get apache to support SSL / HTTPS (see the excellent and detailed Setting up an SSL server with Apache2 – but read the comments, some of the article is out of date and the comments contain corrected instructions)
4. Choose a plugin for wordpress to make it support HTTPS: you have three options

• The exceptionally well-supported Admin-SSL with lots of extra help (the author responds to all comments helpfully and usually with a patch to add features to the plugin!) and works with apparently all wordpress versions (?)
• Semi-official plugin which only works with wordpress 2.1 (and above?)
• Another user-supplied one that comes with decent install instructions (debian-centric, again) but I didn’t try myself

4. Download it to your server (use wget, lynx, links or similar to do this direct to the server)
5. Install the plugin

That all works fine. Apart from step 4. That requires you to login to wordpress, and give away your password.

Someone asked 6 months ago for help on activating plugins from the commandline (then I could do it from my SSH client, securely), and got no helpful response. I had a cursory look at the PHP but it required too much following of other methods for my tastes.

Then I had a Doh moment, when I realised I could of course just use lynx to login from within the SSH connection, thereby only exposing myself to the general internet and the vrious ISP’s along the way, enable the plugin, then re-login from my web browser on the secured connection.

It worked perfectly, of course :).