Protecting a Website Against a Targeted Attack

Over the past couple of weeks, a client website had been experiencing peaks of high CPU usage. Initially, I thought it was pretty normal – perhaps just a backup process running, but then it got more and more regular, until CPU usage was at 100% across all cores for a whole 24hr period. This needed looking into urgently.

The Setup

The website is a popular blog that receives around 70k visits each month. Usually, average CPU usage is around 30% – 40%. It uses a few different forms of caching for both the front and back ends, so when it experiences peaks in traffic – usually after the monthly newsletter email goes out – server performance doesn’t take a hit. It’s running on a LAMP server, hosted by Linode.

The Problem

Once I started looking into the issue, it became clear that the issue was something to do with MySQL. Running htop showed extremely high usage.

On this particular server, I use a service called Tideways to keep an eye on things. This monitors performance and can also show MySQL queries that may be taking a long time to run.

On this occasion, It was pretty clear to see what the issue was. The WordPress search was being hit, at a rate of 1000’s per minute. Each of these requests was causing the database to be queried, which of course led to the high resource usage. Luckily the server was able to stay online during this, and they weren’t able to take the site down at any point.

Batten Down the Hatches

Luckily, each of the requests were calling /search/{search_term_string}/etc/etc which made this much easier to stop. Through Cloudflare, we were able to setup a rule on the firewall to block any request that included the above string in the URL. Pretty much immediately, the CPU usage dropped back down to normal levels.

Interestingly, the attack seemed to be coming from the US… but whether this is actually the case, who knows! In the first 72hrs, the firewall reported that it had blocked over 200k requests! Luckily, this has dropped down recently to around 300 per day, but in any case… I think i’ll be leaving the firewall rule active for the foreseeable future!

Moving Forward

I’ve not experienced this sort of attack before, but it’s certainly one I’ll keep an eye on in future. A bit of research showed that this is a popular way to attack WordPress based sites. Thankfully, this was simple enough to stop with a firewall rule, but the next one may not!

I’m not really sure why this site was chosen – it’s likely i’ll never know. There may not have been a reason, they just happened to spot a vulnerability and tried to exploit it.

If you find yourself in need of WordPress support, please don’t hesitate to contact me.