The real golden nugget in there is the IP address – especially if you have the means to go in and blacklist IP’s in your server. Is that going to stop someone who’s really motivated? No – of course not. But, you can make it more of a headache for someone so it can be a helpful deterrent. So, according to my count, I’m like 250 words in and I’ve not mentioned CloudFlare and how it’s a problem. Well, a large client of mine runs their blog on WordPress and the entire domain runs through CloudFlare for acceleration and ‘safety’. This actually presented a problem…
How CloudFlare Works
So, anyone unfamiliar with CloudFlare this is a brief explanation that may help:
When you sign on to CloudFlare the way your logs are displayed will change because CloudFlare acts as a proxy. This means that your visitors are routed through the CloudFlare network. This allows CloudFlare to stop attacks before they reach your network.
There you go. All you really need to know is that it acts as a proxy – a middle man – and as a result, the IP served to your CMS shows up as a CloudFlare IP.
Why It’s a Problem
You’ve probably figured out where I’m going with this already. For one, when bad logins were being made the logs were recording a CloudFlare IP. That’s super ineffective if you’re trying to block someone trying to hack your blog/site by the IP address. Two, after a while I noticed a pretty disturbing trend – the login attacks intensified while CloudFlare was enabled!
While I was doing work on the site I needed to have CloudFlare disabled so I could see my changes being made. During those periods I realized that I didn’t log a single brute force attack against the blog. Voila! Light bulb! Now, mind you, I’m not a security expert, but, I seems pretty likely that someone was taking advantage of CloudFlare’s proxy anonymity to launch a brute force attack. I haven’t found much out there about this problem in relation to CloudFlare – then again all I’ve found is posts about how CloudFlare supposedly works as a first line of defense against this kind of stuff so maybe their trying to drown out any bad pub on the subject.
In my case the solution was easy – I just setup a custom rule inside CloudFlare to ban it from the blog and, what do you know, the attacks cleared up. Digging in a bit deeper CloudFlare offers their own solution on exposing these IP’s but it requires some lower level server stuff be downloaded and enabled in your apache config and, frankly, I just don’t want to go through the pain of doing it. After all, what good does it do to someone who doesn’t have shell access to a server? It’s entirely possible that I am missing something here, but, from my standpoint this seems like a pretty serious security gaffe on CloudFlares hands.