Caution Needed When Using CloudFlare and Better WP Security
cloudflare security WordPress · 6 comments · 500 words · read ~2,381 times.
There's a nasty WordPress hack doing the rounds at the moment. Essentially, it looks for WordPress blogs and then tries to log in to them using common username / password combinations. If you're still using "admin" and "secret" - now is the time to change them!
I've started using Better WP Security on my blogs. It automatically takes care of securing WordPress against the most common forms of attack. One thing it does particularly well is lock out people who repeatedly try an incorrect password to log in.
Additionally, I've also added CloudFlare to my sites. CloudFlare acts as a CDN - when people visit my site, they're actually hitting the CloudFlare service - CloudFlare caches my content, saving me bandwidth.
You can see where this is going, can't you?
That the IP address of CloudFlare! Due to my inability to perform homographic disambiguation I had repeatedly tried to enter the wrong login details in my management app (i.e. I thought the password had a capital I in it rather than a lower-case l).
All of a sudden, CloudFlaretly was locked out. No worries, I thought, I'll just go in to the database and remove the block.
Only, of course, I couldn't. My entire site was behind CloudFlare. CloudFlare couldn't access my site. Therefore, I couldn't access my site!
So, how to get out of this conundrum?
I could have changed the DNS records of my site to point back to my host - rather than CloudFlare - but that would have taken several minutes to propagate. Luckily, my delightful web provider VidaHost has a Cpanel console which isn't behind my domain names. From there, I was able to go into phpMyAdmin and access the Better WP Security lockout database - called "wp_bwps_lockouts". I found the offending IP address and removed it from the block.
That restored access, but how could I prevent it happening again?
CloudFlare offers Page Rules which allow you to disable CloudFlare for a partclar page, or set of pages.
Setting an exclude rule for
http://example.com/wp-admin
will stop CloudFlare from proxying and cacheing requests to your WordPress admin panel.
It's also possible to "pause" CloudFlare temporarily but that would have lead to a rather large load on my website.
Conclusion
What have we learned today?
- The unexpected interplay of two independent products can have an "interesting" effect on your service.
- Always have a backup plan for accessing your server.
- If someone is using a tool to automatically blacklist IP addresses, it's possible to provoke a Denial of Service attack by proxying requests through a critical piece of their infrastructure.
- Avoid ambiguous characters in passwords - or at least ensure you use a font which clearly shows the difference between Il1, O0, 5S, etc.
- Don't panic!
Moral of the story: Use 2 factor authentication, login lockouts and resultant bans don't work. Maybe if it's a single individual person doing it, but if it's a botnet which it usually is, you'd need to trigger for every bot in the network, which could be tens of thousands
Hey Tom, Yes, 2FA is probably a good idea - although I'm not sure how well it plays with the WordPress mobile apps. T
John says:
Cloudflare allows you to bypass proxying and access your site as normal by typing in direct.yoursite.com. That would have worked as well. 🙂
May I know what mobile plugin you are using with Cloudflare ? I'm thinking about WPTouch, but there is many post about issue while using WPTouch along with Cloudflare. Thank you in advance.
I don't use one any more. My theme is responsive and seems to work quite well on mobile.
A better solution would be to enable mod_cloudflare to pass the real user IP to your entire server, including in the logs. You can find info here: https://support.cloudflare.com/hc/en-us/sections/200038166-How-do-I-restore-original-visitor-IP-to-my-server-logs- . This way means you can keep your site behind CloudFlare and still get the true visitor IP's, including with lockouts. Also if you've not already, you should remove the direct.yoursite.com as it enables a hacker to easily bypass all of CloudFlares inbuilt security mechanisms.