Securing WordPress Against Exploits

A month ago I was dealing with an on going exploit attack against the SEOAndy wordpress installation. We had been attacked many time before, but never on this scale. This blog is a look at exactly how we were attacked and how we’ve secured and hardened wordpress to prevent future attacks putting this site at risk.

How We Were Attacked

blocked threats to wordpress

Over a number of months we were subjected to a new wave of XMLRPC based attacks (along with other attacks), which was hugely ramped up at the end of July and peaked on the 4th August having taken down the website. The attack however did continue over the next few days, and does today.

On the 4th we believe that at the point our site was forced out of service, approx 89% of requests were attacking the website using the XMLRPC method.

This ‘new exploit’ is in its most basic form a Brute Force attack to attempt to gain login to the admin system. These attacks are common and leverage “normal usernames” and dictionaries of thousands of “average passwords” and these are used again and again to try and gain access in the hope the password is considered weak or comprimised. (This is why when even hashed / secured password databases are comprimised the service will enforce a full password refresh).

The XMLRPC vector uses wp.getUserBlogs method within wordpress to try and gain access, this is a move from the normal attack vector of wp-config.php to an API based attack which is hugely faster and much more productive to hackers.

Thankfully, SEOAndy is protected by an addition from the last attack to our Linux VPS called CloudLinux by my web hsting company SW Broadband. This meant that once the resources of SEOAndy were used up the site went down and did not effect the other sites on the server – keeping those sites live!

By the point of recovery on the 5th, SEOAndy was being attacked by approx 10% of the requests for files, this today (10th Sept) is now 6.6%.

Securing WordPress Against Future Attacks

There are many ways to protect yourself against a Brute Force attack, indeed there are hundreds of WordPress plugins offering some form of protection. However, few – in my experience – actually live up to their billing for websites when they are attacked. Knowing this I looked for another solution to the issue of securing wordpress and maintaining security constantly within the site.

I should point out that I am a believer in dilligence of security, and thus always update plugins and wordpress – Thus these aren’t included below, but if you havent updated plugins etc do please do that first. Also you MUST backup your website before taking any actions below.

harden wordpress security

I did my research and here is the plan of action I created. Almost every step requires you to be knowledgeable as a developer and in some cases with server admin, its simply the nature of preventing attacks and stopping them.

  1. Securing All Passwords in the WordPress Database
    I reset all username passwords, using MySQL commands, to 64 random characters MD5 hashed. I then emailed all relevant persons letting them know how to reset their password and what rules they should be complying with.
    The SQL command for this is:

    update wp_users set user_pass=MD5(‘new_password’) where user_login=’admin_username’

  2. Removing the Admin user
    From research others had uncovered this type of brute force attack was primarily aimed at the “admin” username – formerly a default within wordpress. Removing this is simple enough to do – create a new administrator user level user (it can be assigned to an existing user) and then from that user delete the user and assign all posts and pages content to a user.
    The alternative solution is to change the username for that user using the SQL command:

    update wp_users set user_login=’newusername’ where user_login=’admin_username’

  3. One Admin to Rule Them All!
    Seriously, demote all but one user from the Admin role. Commonly there are several admin’s for one reason or another, but honestly I’ve not come across a real use case for this. If your user needs extra permissions take a look at a User Access Control plugin, do NOT give them an admin role. This action reduces the potential surface area hugely and can also prevent mistakes by a user breaking a website.
  4. Update the MySQL password for the WP Install
    With a new longer secure password (updated on your database and within wp-config.php) means better security. This is simple enough to do for a developer. I would also advise to change the table prefix from wp_ to a random sequence_
  5. Update WP-Config Security Keys
    This is easy enough to do if you have access to the file, no dev needed. Be warned it will reset all cookies on the website and users will need to login again. – You can find new secret keys here.
  6. Don’t Allow File Editing Within WordPress Admin
    It’s a lovely tool for quick edits in the admin to your theme or a plugin, but if someone gains access with a brute force attack this is likely to be one of the first places they go to. The fix is simple; just add this into your wp-config file:

    define(‘DISALLOW_FILE_EDIT’, true);

  7. Load Static Content from a Content Delivery Network
    I will be writing another post on the use of a CDN for content such as images and javascript files such as to both enhance security and increase the performance of a website. A developer can set this up fairly easily, it does cost a little but is worth a lot – I use MaxCDN and love it.
  8. Blocking Attacks Before They Request to the Website
    The only way a denial of service attack can be effective is to request to the website it is attacking. If it cannot request and get a response from the website the attack fails. There are a few ways of doing this, there is blacklisting software within most platforms – but this means a request still gets to the server and website. Overloading the server can bring all the sites down, so I wanted to beat the attack before it got to the server. The solution is a WAF and Proxy called CloudProxy by the awesome guys at Securi (known for their website malware scanner). Below explains why I choose CloudProxy and why I think you should also entrust your wordpress website to them.

Web Application Firewall & Proxy for WordPress Security

As a simple explanation, CloudProxy works by taking all traffic directed to your website, filtering it for attack vectors and banned ip’s and then forwarding valid connections to your website. Thus all real traffic can gain access to your website as normal, and those who are attacking or trying to access from a blocked IP they simply get stopped – hence preventing the attack.

Also by default CloudProxy blocks all non-whitelisted IP’s from accessing any resource of WP-admin, thus preventing the majority of attacks in filtering. It’s interesting to note that 49% of requests from point of activiation (5ht sept) to today is blocked through not being on the whitelist.

blocked threats to wordpress

The CloudProxy filter also filters out things such as SQL injection attacks, Brute Force attacks, DDOS attacks and much more. It really is a great filter and tool for any website.

Whilst CloudProxy has a special plugin for WordPress it can and does cover any website. The wordpress plugin, comes with the Securi scanner built in (and scans every few hours) and it has a ton of features which you can select to help enhance your security, including file permissions, file permissions etc.

Another great feature, if you don’t already have a CDN for your website, CloudProxy can work as your CDN speeding up your website whilst securing it.

Finally, CloudProxy gives great reporting and logging allowing you to monitor precisely what is going on and when. Also with CloudProxy virtual patching new vulnerabilities are blocked instantly for your website – meaning even if you are behind in updating or there is no update to a plugin you are safe and sound.

7 Comments on “Securing WordPress Against Exploits”

  1. Great post, Andy. I’ve meant to comment on your blog quite a few times before, but never get round to it! We’re pretty local too- I live in Cheadle and have a small family web/media agency in Saddleworth… anyway down to your article…

    Like you, I take security very seriously. I’ve spent countless hours trying to make our sites as secure as possible. I’m not always a fan of using a plugin to do something, but I have to say I am impressed with iThemes Security (used to be called Better WP Security). The lead developer, Chris Wiegman knows his stuff and is a lovely guy too (which always helps!) It does a lot of the hard work for you, but if you’re more of an advanced user, you can always dig down into the .htaccess files.

    I’ve also been experimenting with enhancing SSL on our sites that use it, and working on improving things. I used SSL Labs who have a great reporting tool. I managed to get our SSL sites from a C up to an A+ by updating the cipher suites and the like.

    A lot of people recommend CloudFlare, but I wasn’t so sure. It gets good reviews and bad reviews, it’s also not great if you want to use SSL to secure your site. You have to pay $20 per month for the pro account, and then you only get the SSL that CloudFlare have supplied. If you’ve paid for an OV or EV certificate, you’re out of luck, unless you pay for the top CloudFlare plan at $200 per month where you can install your own SSL.

    After reading your recommendation of CloudProxy, I went and had a look. It looks similar to CloudFlare, but has some advantages. It’s not necessarily cheaper than CloudFlare on a “per website” basis, but it does allow you to have your own SSL on the $19.98/per month plan, which although not cheap, is much better than paying $200 per month- and you get a CDN with it.

    Also, good to hear positive thoughts on CloudLinux. We’ve just moved to a cloud server which has CloudLinux. It has saved us a few times, but it is still taking me a while to get my head round it- particularly what limits to set per account.


    1. Hi Ian
      Nice to see a local face 🙂

      I used to use Better WP Security, to be honest I found it clunky and actually although preventing some important factors in an attack (reducing the attack surface and helping with some security) it ultimately for larger websites fails to meet the needs its built for… I also had some issues with performance once it was used.

      I also tried WordFence which is useful for smaller sites, much lighter weight too … indeed I use it on many client websites today. But again it ultimately doesn’t meet the needs of larger websites who are seeing brute attacks – the server is still being hit even if it is saying “no you can’t see the htaccess file” and thus using resources in the buffer and causing an eventual crash. This is also sometimes a way to get the server to give up some insecure data in the stack.

      Once you get to the point on a site where you requires more than a “light plugin” such as wordfence you know that actually you need to look outside of your server itself. You could look at co-location of servers, enhancing your servers and differnent variations of a CDN setup (managed hosting from media temple is basically a site dupicated on multiple servers I believe, in its most basic form). But these are hugely costly.

      If you then want to add SSL, as you say its even more expensive, even more so when you look at cloudflare.

      I have used MaxCDN for a while and trust it, plus it works with w3 caching plugin. However, alone it simply delays the inevitable overflow in the buffer and site crash. Thats when you need again to look at stopping things hitting your server and the only way to do that is to use DNS to filter or a firewall to filter – now CPanel can do this but it takes a lot of doing and again things still will hit the server. So taking it outside leaves you going to WAF (web application firewall) sites such as CloudProxy, ClourFlare or maybe Incapsula – all do slightly different things but CloudProxy is the most cost effective and has a built in CDN should you want to use it (though I continue to use MaxCDN which is another option they have).

      Ultimately unless you really care about security and a website failing you don’t look at all of the above and you don’t consider the time cost implications etc … The set up cost is high from a dev point of view, but for on going it is low as in the case of CloudProxy it will auto protect against new vulnerabilites and in preventing attacks stops potentially huge costs down the line.

      Finally, CloudLinux – it’s something I really do love. So much so we are ensuring that all client facing servers which are WHM/cPanel based are using this. It’s just so handy.


      ps.. don’t leave it too long to comment again Ian.

      1. Indeed! Nice to chat to you on the old Twitter too!

        Better WP Security has made some vast improvements in recent months, now that it has become iThemes Security. We use it across all our WP sites and it’s wonderful. I’m not sure I’d call it clunky, but the UI does take some getting used too. It works well across big and small sites in my experience. However, no plugin is going to suit everyone, and maybe it’s just not for you.

        I’ve got a CDN on my blog and on a couple of clients websites. Most of the time a CDN is a bit of an overkill, but it is very useful on my blog- particularly as much of the traffic comes from the US. We get quite a good deal via our host (Clook), but I will check oit MaxCDN in the future. SSL continues to be the issue (in terms of cost).

        Interesting you mention the W3 Total Cache plugin. I’ve ended up abandoning it because it tended to slow down our sites and took up a lot of resources. You’re obviously not experiencing that.

        With CloudLinux, what kind of account limits do you tend to recommend for the standard blog (i.e. virtual memory, physical memory, number of connections etc).


        1. W3 has some issues in building an initial cache I find, but once cached everything runs much more smoothly. That said it’s much to do with how you set it up, and I do think that using an external CDN rather than still using the server to load them makes a large difference in my case. But as you say most sites don’t really need a CDN or indeed this caching facility, but if traffic is high or spikes its best to do so. Also it provides some extra security I feel, though admittedly not as much as CloudProxy.
          I will check what settings I’m currently using, I update it fairly regularly to see if I can improve on the setup – I know currently most sites are limited to 25% of ram with 20 concurrent connections – SEOAndy is obviously higher than this. I’ll take a look when i get a chance and let you know by email.

          1. Thanks Andy, would be interested in that.

            By the way, I’ve just chatted with CloudProxy and they say that they aren’t a CDN but can integrate with other CDNs such as MaxCDN and CloudFlare. I was disappointed with this, because I thought that CloudProxy could be an alternative to the likes of CloudFlare (especially since CloudFlare charge $200/mth for SSL support- or at least allowing you to use your own SSL).

          2. That is a bit annoying, here is the page where they talk about what they do ( ) it looks like they do “edge-ing” of the site to speed it up dynamically but don’t work as a CDN, then again though its only like £6 a month to set up a pull zone on maxcdn – the question is which do you pay for SSL (one or both) and if both could you just force your whole site to cache in the CDN and work from that… :/

          3. It is annoying. Looking at that page it makes it sound like they do use a CDN. In fact, I wonder whether CloudProxy has a bit of an identity problem. The service sounds very like CloudFlare, but without the CDN. I’m not entirely sure what the advantage would be in using them over CloudFlare. Either way, it seems to be very expensive to go SSL despite living in this “post Snowden” world!

Leave a Reply

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