DDoS attack on site not mitigated

We have been under attack for a few days. Although cloudflare says that the action taken on certain IPs is Block we still see those IPs appearing in our access log making out web server unusable to the general public. Is there a to fix this mitigation issue?

@cscharff Thank you. Already did these steps. The requests are directly to the domain not the origin.

Ok well then the requests to the origin weren’t blocked by Cloudflare. A block of a single request by Cloudflare does not mean all subsequent requests from an IP address will be blocked. Only IPs which trigger a matching firewall rule are blocked.

You can review the best practices arounf DDoS mitigation first steps here:

1 Like

Thanks once again. That’s why read every documentation in the community and the ones provided by CF and we implemented rate limiting and custom waf rules which I attach. The waf rules are based on the common factors we found analysing blocking data.

Can you please help why CF throughs a managed challenged to an IP blocked earlier while the zone has under attack mode enabled? We don’t have any custom ddos rules enabled to override the default action which is block.

We’re playing a game where a question is being asked without context and then after the answer is given the context is provided. So why don’t we change things up?

Provide a specific example of what you are talking about along with the rule you believe should have blocked the request.

1 Like

I totally agree.

Here is an example that just happen. Bare in mind that the clock in the access log is 3 hours back from my actual time.

IP appears in the logs 5 times within a second.

Here is why this IP should have never reached the origin yet CF through it a managed challenge.

The requests in the first screenshot were blocked based on the Cloudflare HTTP DDoS rule @ 11:23ish.

The requests in the last screenshot are from 13:04 (whether that’s 16:04 or 10:04) So different requests. The fact it was blocked by Cloudflare’s HTTP DDoS rule at 11:23 means those requests matched that rule at that time. It doesn’t mean every request from that rule will always match that request.

As for your rule I generally try to stay away from complex regex because it’s way to easy to create a rule that either can never be met or has criteria that aren’t what they appear to be at first glance. In this instance at a minimum not knowing the threat score makes it problematic to debug because there’s no deterministic way to confirm the regex is correct without it.

As it stands now… the site blocks me from the US. So if that’s what your rule is supposed to be doing, appears to be working.

Based on your feedback,I have changed the rule to a far more simple one. Just block anything that is not from Cyprus. No thread scores, agents etc.

Let’s see how that goes. So far things looks worse are more requests reach the origin.

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