Cloudflare and Wordfence blocking the same IP/traffic

Hello,

I have emailed Wordfence for a number of weeks on this and they have advised me to now see what can be causing it on the Cloudflare side, as apparently it’s impossible for Wordfence to be doing it if Cloudflare is doing as it says it is.

Basically, Wordfence is blocking everything that Cloudflare should be and says it is blocking.

All manual and default rules for bots, countries, from what I can see its near enough everything. It is hard to correctly audit as Wordfence doesnt allow for data downloads to look up against, and sitting there for periods of time counting in traffic and IPs live isnt really how I like to spend my time!

But I have country level blocks in place for China and Russia, the taffic will be blocked but still appear in Wordfence that blocks it. Same for bots. We have had a number of triggers hit in the last few weeks for DDOS probes or unusual increases, each time Wordfence spotted them and emailed me. But the traffic was marked as blocked or managed challenge in Cloudflare.

Is there something I have missed? If they are served with a managed challenge can they bypass it? The pass rate is tiny (under 3%) so this cannot account for the vast amount of volume seen.

Help would be appreciated, as currently I am concerned we don’t have the protection in place we believe we do,
Thanks

Hi,

Thank you for asking.

You should be able to see the challenged or blocked event under the Security tab → Events at Cloudflare dashboard for your zone and know exactly which security option was triggered. Could be Bot Fight Mode or Browser Integrity, Managed Challenge, Custom Rules, etc.

May I ask if Cloudflare’s IPs are allowed and allowlisted in the Wordfence settings? :thinking:

Furthermore, is the “CF-Connecting-IP” HTTP header option for Cloudflare in the Global Options enabled?

Use the Cloudflare “CF-Connecting-IP” HTTP header to get a visitor IP. Only use if you’re using Cloudflare.

Wordfence is fully compatible with Cloudflare, and in some configurations, Cloudflare will send the real visitor IP address to your web server using the CF-Connecting-IP HTTP header. If Cloudflare support personnel have advised you that this is the case, then enable this option in Wordfence.

Note that Cloudflare has several configurations including their own web server module that takes care of detecting the visitor IP address, so be sure to work with their technical support staff and read their documentation to determine which configuration you are using.

A great useful article here:

May I ask if you’re using a free or paid Cloudflare plan? :thinking:

Kindly, see the post here for more tips & tricks regarding Cloudflare security options for WordPress:

Hi,

Thanks for your reply. I am using a paid plan.

Yes I can see the event. As mentioned. it doesn’t seem to matter what the event is in cloudflare, wordfence will still then go on to detect it and action. Example is blocked traffic China and Russia yet I can see Cloudflare block this traffic then Wordfence also block the traffic. This shouldnt be possible if Cloudflare was blocking it.

This option is not selected as we have not been told to select it. Plus there is no issue with IP. Wordfence is getting the IP fine.

I think you have missed the point, I have put in place security for DDOS, but if Cloudflare is saying one thing and Wordfence another which is that Cloudflare is not blocking what it is saying it is and Wordfence is having to do it, then it does not matter what guide I follow for DDOS protection if its not working to start with.

We have the Cloudflare recommended rules and scripts in place. But yet traffic is arriving that should be blocked by Cloudflare, and that CLoudflare is saying is being blocked…

Help appreciated regarding the situation detailed above,
Thanks,

Thanks for feedback.

If it’s action is “Block”, no requests should pass through and you shouldn’t see any of it at Wordfence and your server log files.

Otherwise, some setup is odd here.

If you’ve tuned or changed the default “DDoS parameters and triggers” under the DDoS tab of the Security and Managed Rules of the WAF tab at Cloudflare dashboard, should be a bit different then.

Despite a neighbour server in the same rack or datacenter could potentially abuse our, hopefully at the origin itself is configured that way.

In the coming days, could you share a screenshot of those identical events at Cloudflare and at Wordfence too?

Are your DNS records proxied :orange: so the security & protection rules would apply and work as expected? :thinking:

Are those countries blocked via a WAF Rule? Can you share a screenshot of it?

Mine is not working as you say - without the option selected (free CF plan, Premium paid Wordfence):

Once I’ve change it, then it does get the correct IP:

Example recently blocked by a custom WAF Rule to block everyone except :croatia: :

I don’t see that particular request at Wordfence live traffic at all:

WAF rule as example:

If you’re concerned about DDoS only, then you’d have to tune those settings related to the DDoS at Cloudflare, including some custom WAF rules and Rate Limiting.

I am afraid it’s not a single-click solution.

If you’re concern about it, kindly I’d consider writing a ticket to the Support just in case to get more feedback information.

1 Like

Hi,

I think I have a possible lead on what is happening. If the traffic comes via a parked domain, that is a different domain extension of our domain, due to a redirect or other reason. How does Cloudflare treat the traffic? As these seem to be the visits that are part of waves of visits from teh same source, the ones getting through to the site are internal referrals from our parked domains. The ones direct to our domain cloudflare is dealing with.

Sure that can’t be a normal feature of Cloudflare to allow that as a bypass? Why does it treat that traffic any differently?

If that isnt the case then I am out of ideas. As there are hits for wordfence for the same traffic at the same time (not exact numbers) as hits cloudflare is reporting.

Tested the global option again, no difference although I am on a v6 IP i noticed yours is v4 so possibly thats the difference.

Yes full proxy on server IP. WAF and bot rules all implement CF rules. Additional rules to block the countries already mentioned. DDoS has no changes to the rules, just additions of country blocks and wp-login blocks. Rate limiting is managed on site with Wordfence. The ideal has been to have Cloudflare do what its good at, then leave site elements such as brute force and limit to Wordfence, which it is better at. But I cannot keep running Wordfence at its current rate where its blocking the same thing Cloudflare should be. For many reasons.

Thanks,

Like any other visitor traffic.

It doesn’t. Have you locked down your origin so it doesn’t receive requests from anything but Cloudflare IP addresses? Have you reviewed headers of the blocked requests on your origin server? Is there any evidence they came through Cloudflare?

Hi,

Well the pattern seems to be that a number of bots slip by cloudflare via a parked domain route to the main site. So it appears they might be the same source, same IP, same everything apart from coming in via a different route.

So, no, my biggest issue with Cloudflare, is you are pretty much left to your own devices, and each feature is a silo. The self-help guides either don’t explain things to upskill or don’t give enough detail to follow along. That’s coming from an ADHD’er who’s never had to read more than a few pages of a manual in my life to grasp how anything works before. But there are huge chunks of information, such as ‘locking down your origin server’ that doesn’t feature clearly in any of the security literature I have been through. Would it kill them to have an AI task recommendation bot or something that tells you what would be a sensible next task given your account? I feel that would really cut down on the issues on content gaps. Another example, the VARY header guide was so terribly written, without any actual help I used ChatGPT to successfully support me through it to implement.

Anyway, would you mind sign posting me to the origin lock down guide please? As I have spent todays ChatGPT tokens on marketing content.

Thanks,

The challenge is there are dozens / hundreds of different ways to put a web server on the Internet and as many software packages to serve web content. There is no one size fits all answer to how to restrict your origin to only accept connections from Cloudflare IP addresses.

At this point the level of assistance anyone can provide is limited. We don’t know the domain or the rules in question. @fritex provided examples with screenshots and details.

1 Like

If you are parking a domain on the same server as your main domain and pointing to it with the same A/AAAA/CNAME, then that will happen. The zones on Cloudflare are treated separately, so have separate WAF rules, otherwise people using shared hosting would filter traffic for everyone on that server.

The easiest solution is to redirect those parked domains using Cloudflare redirect rules to your main domain (or a parking page under your main domain) so all traffic passes through your main domain WAF rules before it can get to your origin.

We do exactly that for the dozens of domains we have for trademark protection only.

Alternatively you can manually, or automatically using the API, set the same WAF rules for all the parked zones as your main domain.

Hi,

Right that makes sense, so my assumption previously was correct that Cloudflare was not treating this traffic the same as direct traffic. I was literally sat confused for an hour as all the origin elements I have done previously without knowing what it was exavtly called. So I was even more confused as to how this was happening.

But thanks for sheding some light on it for me. If I just redirect any traffic landing on any string of the parked domains and send them to the homepage of the .com cloudflare will then pick them all up, if I have understood correctly?

Thanks

If I could add a note and share a thing …

Eventually, I was hit in the early morning with a HTTP DDoS Layer 7 which surprised me :roll_eyes:

See below screenshot when I filtered the traffic:

Not filtered - services and rules which were trigered:

I totally forgot to enable Rate Limiting Rules here on this particular zone, therefore they weren’t used at all :exploding_head: :grimacing:

On my origin server, when I checked, few requests did passed through at the beeginning as a normal visitor, CPU load was from 0.67 to 2.5 for less than 15-20 seconds, until obviously those kind of requests triggered Cloudflare’s response (I got an email notification too), however few moments later each request was blocked, CPU load went down and numbers kept growing on the real-time despite it was all done in 1-2 minutes.

Agree as far as I’m using different available security options at Cloudflare for my zone. Can be seen, a lot of requests were already blocked via IP Access Rules: ASN.

Thats weird I had the Oregon amazon data centre yesterday send me a spike also. But not close to that sort of traffic. Ok, so I am waiting for my other domains to process to CF to be under DNS then I can finish the redirests. I have just done a rule for all HTTPS traffic to redirect to the homepage of the .com and all http to be blocked. Should that suffice?

I should probably look at rate limits in CF, but Wordfence is doing it currently based on 404/403 repeat hits and 300 page hits.

Is there any rule that can limit traffic sent from a single referral source or from the same URI string in the same hour? Basically our hack last year was from an affiliate on our affilaite network, long story. But to stop a similar type of attack, I would like to cap the traffic allowed from referral sources with ABC in the URI in a given time period. Any way of doing that?

Thanks,

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.