Should I get Cloudflare Business?

Hello there, Cloudflare Community! :slightly_smiling_face:

I am new to Cloudflare Community, so I hope to get a warm welcome, and some leniency regarding my ignorance. I am here today to ask what the usual starting cost for Cloudflare Enterprise is, and whether you pay per Mbit like Cloudflare Magic Transit, or if it is a fixed monthly cost. Also, is Cloudflare Business worth the 200 USD/month? I am currently using Cloudflare Pro for 20 USD/month, but does Cloudflare Business offer any significant increase in DoS/DDoS mitigation against Layer 7 attacks? My back-end IP has not leaked, so I am not concerned about any other forms of attacks. I am only concerned with some attacks I have received recently that have seemingly gotten around the Cloudflare WAF, even with IUAM enabled. I have NGINX set up with fail2ban so attacks that leak become detected after so many rate-limitations and blocked with the Cloudflare API by using IP Access Rules.

Any advice is appreciated. Thank you!

If it’s because ddos doesn’t pay, just activate the anti ddos on the homepage and everything will be fine, I use Free and sometimes it’s better than some paid anti ddos, so it’s just a matter of configuration, have you done the anti bot configuration?

You should buy Cloudflare’s Business plan if you need faeries available from that plan tier.

Based on your problem description the issue is with users hitting your origin directly. You should restrict your origin to only accept connections from Cloudflare IPs which can be done on any plan level.

2 Likes

No

Firewall rules and bot management are the best alternatives when UAM isn’t as effective. You might find this post I made practical:

I believe that firewall rules would be able to do this more effectively without running fail2ban. I’m confident there are patterns on the attacks you are receiving that might be hard to spot at first glance.

I believe he was referring to IPs that go through Cloudflare and reach his backend and make many requests per minute/second.

No, our back-end IP is not exposed, nor is anyone hitting it. The issue is that a lot of these attacks seem to be getting past Cloudflare, even with IUAM enabled. I do not allow any connections to the server directly except for Cloudflare’s own IP ranges.

Yeah, our issue is not so much people attacking our server directly. It is that they are sending a lot of requests per second to our domain and causing our NGINX server to crash. We have the Cloudflare API configured with fail2ban so that any IP addresses that repeatedly hit the rate-limit automatically get blocked by IP Access Rules, but I would very much like to avoid having to resort to that in the first place. These HTTP floods seem to leak through Cloudflare and reach us directly, even though I have a lot of Cloudflare’s protections set to their maximum. I just have not played around with the bot detection yet, as our API requests keep getting flagged by it, and I cannot find an efficient way to whitelist that specific bot activity without upgrading to Cloudflare Enterprise, which is way outside of our current budget.

Can you show the requests that those bots make that aren’t picked by Cloudflare?
Understanding Under Attack Mode in the last point, I propose a template that should help the community flag the malicious requests.
rate-limiting should only be the last option to rely on because attackers can adapt to it by increasing the number of ips and reducing the throttling of the requests.

Unfortunately I cannot get the access logs from NGINX since I disabled them as to not flood my entire server with nothing but junk traffic, but here is what I pulled from the NGINX error logs caused by the IP addresses hitting the rate-limit directive.

9227:2022/02/23 00:52:10 [warn] 136448#136448: *467931 limiting requests, excess: 30.860 by zone "forum", client: 81.4.102.223, server: mydomain.tld, request: "GET /?q=Yu9GnLflLM25 HTTP/2.0", host: "mydomain.tld", referrer: "https://mydomain.tld/"
9228:2022/02/23 00:52:11 [warn] 136451#136451: *465290 limiting requests, excess: 30.290 by zone "forum", client: 34.134.16.11, server: mydomain.tld, request: "GET /?q=7zIpvM768VCQ HTTP/2.0", host: "mydomain.tld", referrer: "https://mydomain.tld/"
9229:2022/02/23 00:52:10 [warn] 136448#136448: *463319 limiting requests, excess: 30.800 by zone "forum", client: 212.3.135.232, server: mydomain.tld, request: "GET /?q=Z9VYUEDepZLa HTTP/2.0", host: "mydomain.tld", referrer: "https://mydomain.tld/"
9230:2022/02/23 00:52:11 [warn] 136451#136451: *465294 limiting requests, excess: 30.290 by zone "forum", client: 34.134.16.11, server: mydomain.tld, request: "GET /?q=VyEUU3yHmlHD HTTP/2.0", host: "mydomain.tld", referrer: "https://mydomain.tld/"
9231:2022/02/23 00:52:10 [warn] 136448#136448: *463334 limiting requests, excess: 30.980 by zone "forum", client: 178.205.169.210, server: mydomain.tld, request: "GET /?q=R3iC7DKI6H46 HTTP/2.0", host: "mydomain.tld", referrer: "https://mydomain.tld/"
9232:2022/02/23 00:52:11 [warn] 136451#136451: *465295 limiting requests, excess: 30.290 by zone "forum", client: 34.134.16.11, server: mydomain.tld, request: "GET /?q=EFmgg42KvM9z HTTP/2.0", host: "mydomain.tld", referrer: "https://mydomain.tld/"
9233:2022/02/23 00:52:10 [warn] 136448#136448: *463332 limiting requests, excess: 30.800 by zone "forum", client: 212.3.135.232, server: mydomain.tld, request: "GET /?q=9Nrmb9gKeFYd HTTP/2.0", host: "mydomain.tld", referrer: "https://mydomain.tld/"
9234:2022/02/23 00:52:10 [warn] 136447#136447: *465761 limiting requests, excess: 31.000 by zone "forum", client: 81.4.102.233, server: mydomain.tld, request: "GET /?q=1lekcAptr86P HTTP/2.0", host: "mydomain.tld", referrer: "https://mydomain.tld/"
9235:2022/02/23 00:52:11 [warn] 136446#136446: *467403 limiting requests, excess: 31.000 by zone "forum", client: 81.4.102.233, server: mydomain.tld, request: "GET /?q=zKblqbRFNu0n HTTP/2.0", host: "mydomain.tld", referrer: "https://mydomain.tld/"
9236:2022/02/23 00:52:11 [warn] 136451#136451: *465296 limiting requests, excess: 30.290 by zone "forum", client: 34.134.16.11, server: mydomain.tld, request: "GET /?q=qN3uvYLzBaN7 HTTP/2.0", host: "mydomain.tld", referrer: "https://mydomain.tld/"
9237:2022/02/23 00:52:10 [warn] 136447#136447: *465400 limiting requests, excess: 31.000 by zone "forum", client: 81.4.102.233, server: mydomain.tld, request: "GET /?q=3U5LvI3ZvbIG HTTP/2.0", host: "mydomain.tld", referrer: "https://mydomain.tld/"
9238:2022/02/23 00:52:11 [warn] 136451#136451: *465297 limiting requests, excess: 30.290 by zone "forum", client: 34.134.16.11, server: mydomain.tld, request: "GET /?q=odfeLj1sr6kZ HTTP/2.0", host: "mydomain.tld", referrer: "https://mydomain.tld/"
9239:2022/02/23 00:52:11 [warn] 136445#136445: *469534 limiting requests, excess: 30.070 by zone "forum", client: 40.88.37.168, server: mydomain.tld, request: "GET /?q=78cbvKC2WEJv HTTP/2.0", host: "mydomain.tld", referrer: "https://mydomain.tld/"
9240:2022/02/23 00:52:11 [warn] 136451#136451: *465299 limiting requests, excess: 30.290 by zone "forum", client: 34.134.16.11, server: mydomain.tld, request: "GET /?q=PcK4NBEMmC8A HTTP/2.0", host: "mydomain.tld", referrer: "https://mydomain.tld/"
9241:2022/02/23 00:52:11 [warn] 136451#136451: *465300 limiting requests, excess: 30.290 by zone "forum", client: 34.134.16.11, server: mydomain.tld, request: "GET /?q=rU2LyRS1yai7 HTTP/2.0", host: "mydomain.tld", referrer: "https://mydomain.tld/"
9242:2022/02/23 00:52:10 [warn] 136448#136448: *467936 limiting requests, excess: 30.860 by zone "forum", client: 81.4.102.223, server: mydomain.tld, request: "GET /?q=W0MuoBIJH7mI HTTP/2.0", host: "mydomain.tld", referrer: "https://mydomain.tld/"

Just to add some extra information: I am running a XenForo forum installation. If you know any firewall rules or page rules that might help enforce security for a XenForo installation specifically, that would be greatly appreciated.

I was referring to the CF firewall

Log buffering would prevent this from happening unless the attack is very big.

I believe @eva2000 might have some more experience and know few tips & tricks on that one :thinking:

1 Like

Sorry, yeah, I forgot to include a screenshot or two from the Cloudflare firewall logs.


I see that you mitigated that request with IP access rules. Is it safe to assume that these requests were going through UAM? ( the second one)

I actually have IUAM disabled at this time because many of my users were having the issue where the 5 second challenge page kept looping/refreshing and they could not access my forum. This attack was unfortunately launched while IUAM was disabled, but I have had a couple attack prior to this one that seemingly leaked through IUAM, which I thought was bizarre. I will enable IUAM again to see if their next attack leaks through, as they will inevitably attack us again. However, the issue right now is that our public-facing API (relies on the XenForo API and has a ASP.NET service running behind it) cannot be protected with IUAM, as it causes issues for people trying to use it.

What is most frustrating is that if I could enable Super Bot Fight Mode to block automated traffic, I would go that route, but that is not an option due to innocent users getting blocked while trying to use our API. It seems that the bot report shows that 28.09M requests are definitely automated, which is part of that attack that we received.

IUAM is pretty simple as a security measure, it handles the low hanging fruit. Beyond that, Business does have bypass cache on cookie which might be helpful for reducing requests to origin and it has rate limiting available on any plan type.

2 Likes

From the two logs you show, I can guess that there are at least two types of attacks being launched to your site.

The first one would be easily pattern matched with the business plan (regex with firewall rules).
It also has an extremely dated user agent; you could look into UA blocking before rate limiting, many attacks use irrelevant UAs that are years old.

The second one seems to come from a botnet written in .NET Framework, that UA is typically used by botnets that forget to change the UA of their headless browser.
You can block their UAs again or find lacks in the requests they craft, but you would need to inspect other headers that we can’t see in the screenshots you provided.

In both instances I picked random requests, but looking through other requests, they vary differently in UAs. It is not all old UAs unfortunately. But if there no way to deal with the first example without Business specifically for the regex firewall rules? If I upgrade to Business, I would like it to be for more than just one particular feature, unless it is absolutely necessary.

We’d need to study the attack more throughoutly to determine that, the odds are that it comes from servers or compromised machines that you can slowly block using IP lists. https://developers.cloudflare.com/firewall/cf-firewall-rules/rules-lists#entitlements

Can you show some that are not old?

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.18247
Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko

Okay, point taken. There are quite a lot of old UAs. I only found a few that are close to being considered “new”, but could safely be blocked without affecting legitimate users. However, there are only 50 available rules in User Agent Blocking. There are so many different variations, so how would I go about blocking these old and/or malicious UAs?

Start with the UA blocking slots available in the CF dashboard.

The regex from firewall rules could help. However, it’s only business package :sweat_smile: .
Chrome/64.0.3282.140 to block anything below 96, I’m not a regex genie, but I’m sure that somebody from the community could help build a rule for it.

Alternatively, use all your UA blocks and then build firewall rules using OR until you reach the length limit.

4 Likes