i registered the domain, https://gustavetoken.com/ and assign it successfully with Cloudflare with ‘i am under attack on’ to avoid stories i saw on a telegram group.
I was attacked despite the Cloudflare service. over 12million request was recorded on the Cloudflare dashboard. But all the request still got to the site.
This persists till my server legal and abuse section took the website down.
I was ridiculed by my client to have used unsecured solution.
This is the work of Cloudflare obviously failing. The domain is still accessible right now for confirmation of the current attack on-going. https://gustavetoken.com/ Why cant Cloudflare resolve this? is this how they work?
First of all: getting angry here won’t help you, most people helping are customers just like you.
I can’t get in to your website since the origin doesn’t seem to be responding. The 12M requests could have been all valid since the free plan I suppose you are on is free and won’t have all the enterprise grade and higher DDOS protection paid plans provide. Also the free plan doesn’t guarantee uptime and no one at Cloudflare will look at the attack you are facing and will provide specific help.
Cloudflare’s enterprise-grade mitigation of DDoS attacks against layers 3, 4, & 7 includes prioritized IP ranges and routing, ensuring maximum speed and availability.
How many requests were logged on the origin and what other steps did you take to harden your server? Are you using free or paid, what is your configuration, and how can Cloudflare be responsible for an attack directed at your site?
In general on lower plans, Cloudflare only provides tools to protect against layer 7 DDoS. IP reputation only does so much, if you are a high enough value target to get hit with completely fresh and good-standing IPs, CF can’t help.
If under attack mode isn’t working, maybe try a firewall rules set to “challenge”.
In general, no, actual Cloudflare-provided logs are only available for Enterprise customers. Since all requests either show up in the “firewall events” page, or go to your server, you should have the access logs you need by looking at your server’s logs. There are services like https://logflare.app that I would recommend if you can’t set up a good log solution on your server.
Full automated layer 7 ddos protection can be done via rate limit rules if you so wish. If those are too expensive, you can run your own fail2ban or another system which rate limits IPs (gotten via the Cf-Connecting-IP header) on your origin server.
I know, but all your answers actually prove my points
yes I can get logs but most people like the op did not know about it, it should be big red warning its must be an built in tool provided by cf(I think most people not research about it, they trust cf to give them right tools to stop all ddos attacks and only after being attacked find out that it’s not the case)
IUA not good against scrapers as you cant turn it on all the time, the purpose of IUA is to work only when under attack, and again it very easy this day to bypass as the OP and a lot others posts in the forum(me included) can show you how easy it is to bypass it
rate limit is good tool but its not user friendly enough
Understand the frustration, but Cloudflare did mitigate quite a bit of the overall traffic. Looking at the current stats, there were over 67M requests hours and 53M+ of those requests were served from cache (accounting for over 95% of the total bandwidth). Also 53M+ of those requests are identified as coming from Tor so a Firewall rule to block the “country” T1 would prevent any of those particular requests from reaching the origin similar to the other country based rule you have in place. There are also other security tools available such as web application firewall, rate limiting, full page caching and other features which can be used to protect the origin.
I respectfully disagree with you boynet2, here is my reasoning and feel free to challenge it:
“most people like the op did not know about it”
Did they look for it?, because it is documented and information is available
“it should be big red warning”
This is your opinion and valid, but my opinion is that it should not be a big red warning and my opinion is also valid
" it very easy this day to bypass as the OP and a lot others posts in the forum(me included) can show you how easy it is to bypass it"
Please post a tutorial on how to do it, perhaps it will help the Cloudflare team to improve it
To @cscharff Thanks for taking the time to look into this case and provide more statistics. 95% effectiveness for a free plan seems pretty good in my eyes
So I think there are valid arguments on both sides. First I want to point out that many folks have an unreasonable expectation to what Cloudflare (or any service) will provide out of the box in terms of protection and security. There is no single magic bullet for protecting/ securing/ accelerating a website. Part of that, is I think our fault because we have generally opted to make the sign-up/on-boarding process as simple as possible. When it looks like an “easy button” that can often prevent people from digging in deeper.
Second believing that the free version of our service offers all the same features as our other self serve plans or Enterprise plans is common and I’m not sure why. Why would someone pay Cloudflare hundreds of thousands of dollars a month if they could use the service for free? There must be some type of differentiation.
But @boynet2 you do raise some good points and I have passed those along to the product team. I will say the advice/suggestions I passed along to @energieman86 were not the result of accessing any internal tools (beyond gaining the ability to view his account) and so determining a way to block 55M of the requests was a question of familiarity with the tool and where the information provided to that plan type was available to OP and anyone else on that plan type.
This is reasonable feedback. There are plenty of services out there which act like an origin (Heroku for example) where you have limited/no logs which makes troubleshooting difficult if Cloudflare doesn’t provide them. As others have pointed out there is at least a 3rd party tool which can get you some insights here and one could write their own worker to log somewhere else (yes it costs money, yes it requires some technical acumen… but even our ENT customers need technical acumen to gather/parse their logs).
It was never intended to be the be all/end all solution to L7 DoS protection. We acknowledge there are many other vectors. That is why we:
Cache 404 responses from origin
Provide plans with WAF support
Provide Firewall Rules
Provide Country/Tor Blocking
Provide Page Rules to tweak security levels for critical paths
Provide Rate Limiting
Provide a Bot Management Solution
Relying on IAUM as the sole mechanism to protect your site from an L7 DoS attack is not something I would recommend and fails to take advantage of the others features Cloudflare offers. Do some of the other features cost $? Absolutely. No apologies for that from me… it funds our ability to provide the service and keep building new/cool things.
I think this is part of an education issue. We try to provide new users signing up with emails telling them about additional features they can take advantage of and link them to setup/ configuration information. We also do limited marketing of our new features to customers via email. We try to use twitter and our blog to provide information as well and our KB is not the worst I’ve ever used. Is it unreasonable to expect everyone to be a Cloudflare expert to configure their system? No. Not reasonable to expect one can just press the easy button and you’re 100% good to go either.
Like I said… passed along the feedback to the team, but you have my hot take on it as well FWIW.
I echo boynet2’s wish for a bit more visibility into raw request data on all plans. A log showing 5 sampled requests of each of the top 20 URLs (query strings removed) from past hour would for example go a long way in any troubleshooting. Sure you can use the 3rd party Logflare app, but I didn’t know about that one until I read this thread. Perhaps you should just list it as an alternative on the Log page for non-enterprise customers?