Shields Up: My Journey Into WordPress Security

After a several-year hiatus, I decided it was time to wipe the virtual dust off of this blog. However, when I opened the drawer, I discovered a sad sight: several–thankfully somewhat inept–hackers had compromised the security of my site. I had fallen victim to malicious redirects, junk posts, uploaded malware, and a host of other troublesome tactics. What followed was a day-long quest to de-hackify my blog, get it back into working order, and put in some protection to make sure this wouldn’t happen again. Here’s my tale.

The most important thing to do when you discover your blog has been hacked: do not panic. In my case the hack, while annoying, wasn’t particularly damaging, and was done somewhat ineptly. Consequently, while there are a lot of resources out there that will advertise professional hacking recovery, I found that following several step-by-step guides carefully was more than sufficient to cleanse my site and get it back up and running. You do have to be fairly technically proficient and, if you want to enable extra layers of security, have some understanding of how to work in your webspace and enable different options. A lot of professional hosting packages may do a lot of this for you if you are paying them for a managed webspace. I’m not, but the the steps are generally simple enough even for someone with only a basic understanding of website management to do.

With that, here’s my account.

First: Delete, delete, delete

In my case, this whole process got started when I learned that an assortment (see what I did there?) of malicious files had been uploaded to my site. My first order of business was to disinfect my webspace from all the crap that had been uploaded to it. My web host was kind enough to send me about 50 e-mails noting that it had detected suspicious files on my webspace.  Sure enough, when I logged into my FTP site, I discovered about 500 variously named php files. Virtually every directory had been polluted with suspect php files. Queue bulk delete action. The e-mail I received from my web host was helpful in letting me know which directories I had to cleanse; not all of them were targeted.

Plugins and Scan, scan, scan

The next step was to beef up my blog’s security. While I had previously had plenty of plugins that I could use to scan files on my blog, I was missing a big piece: firewall protection. After some basic research on Google, I ended up installing the following security plugins:

Wordfence and Sucuri provide both reactive and proactive security protection for your blog. In particular, Sucuri uses “hardening” to protect various parts of your blog that might be susceptible to attacks, and also has firewall protection.  Wordfence similarly has firewall protection, and even has a learning more where it determines what kind of traffic to be block or not. Both of them provide e-mail updates up the wazoo whenever something noteworthy occurs on your site: someone logs  in, a post is updated, a plugin needs an update, etc. Queterra is a scanning plugin, but it has both an internal and external scanner that can detects tons of different types of malware and, well, I felt like another another one couldn’t hurt!

Note – virtually all of these plugins use a freemium model; you can get basic services from them for free, or you can become a premium member and get additional benefits. For my purposes, I’ve found the free services to be more sufficient for my little corner of the web.

Malicious Redirects

One very obvious results of the hacks on my blog was malicious redirects – while the main page of the blog was intact, clicking any of my posts or page links would redirect you to a click-bait website. Funnily enough, when I first noticed this occurring, I thought it was a WordPress update gone awry; it was only after I posted at the WordPress community forum that someone pointed out to me that this was actually a hack.

It turns out this was a very simple hack to fix; the problem was in my .htaccess file. I ended up only need to go to Settings -> Reading and save my options there again to regenerate my .htaccess file. Once I did that, problem solved!

Update, update update

My next order of business was to get this blog back into tip top shape.

The low-hanging fruit for this task was to ensure that I was using the latest version of WordPress, and all of my plugins and themes. That also entailed deleting plugins that my newly-installed security plugins determined had effectively been abandoned because they hadn’t been updated in several months and likely had compatibility issues with the latest version of WordPress

Relatedly, I finally went ahead and deleted the huge list of old, crusty themes that I accumulated over the many years of using WordPress. Man there were a lot. I’m such a hoarder.

Finally, I also updated a handful of behind the scenes settings of via my web host. The most significant (and, happily, eastest) update was my version of PHP. I was apparently still using PHP 5.2 (and paying extra for legacy support for this version. Lame). After some quick googling, I was able to determine the exact steps on how to update my PHP version – which literally came down to selecting from a list of versions. I didn’t have to do anything other than that. Nice job 1and1.

Updating was probably the most time-consuming step of this whole process. There’s so many different things to update, whether that be a front-facing thing like a plugin or a backend system like your PHP version. The front-facing stuff is easy enough; it’s the backend updates that are most challenging. I don’t log into my webspace very frequently, and even when I do, the things I could be updating are escalated to a point where I would even notice that I could be updating something. Feel like that needs to be improved. 

SSL Certificates

Finally, I setup an SSL certificate for my site so that all traffic to and from is safely encrypted. All I had to do was navigate to an “SSL Certificate” menu in the control panel for my web space, enable it for my site, and voila. It was free and easy.

Now, free and easy is great, but what I can’t understand is why I was never nudged to do this. All I had to do was literally flip a switch.  Why wasn’t I being prodded incessantly to take this incredibly easy, basic security step? Instead, I had to peruse over a fairly cluttered control panel and stumble into it. We should not be relying on user’s curiosity to enable critical security features.

Conclusion

In the end, I’m glad to say my blog has survived this ordeal, and it even rekindled my dormant interest in regularly blogging. And I learned a few things along the way too. That’s a good deal.

For those who are interested, here are some links to websites that helped me get oriented and fine tune this process. 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.