Hello cloudflare does not filter traffic . Ddos

wordpress

#1

Hello ! cloudflare does not filter traffic . Ddos

For several days in a row there was a ddos ​​attack on my site, I turned on the mode under attack, but still the cloudflare did not help, what’s the problem?


#2

I am not sure what your graphs should show, but your security level will have been too low. If you set it now to under attack every request will have to go through a validation.

Whats your domain though?


#3

CPU load doesn’t necessarily indicate an attack. Take a look at your processes and which one is causing the load? 0.29 is not high though.
Check your webservers access logs, open connections and so on.


#4

the graph shows the load on the server, I always had a mode I was under attack


#5

As Mark said, .29 is not that much. If you always had “under attack” on there shouldnt have been much of an issue, as this validates every single request.


#6

load on your server doesn’t mean a lot…

if you sure you are under ddos attack start from this guide https://support.cloudflare.com/hc/en-us/articles/200170196-I-am-under-DDoS-attack-what-do-I-do-

this is not true at all… under attack mode does not block all layer 7 ddos attack, but it does add another layer of protection


#7

What is not true? Every session will have to go through validation, which should filter out most/all of these requests. Please elaborate.


#8

You’ve turned under attack on and off and on and off. So correlating it to your CPU chart is a bit difficult. You’ve also turned proxying on and off and on and off, so that also makes it difficult to figure what is going on.

There is a list of steps here that one should consider when under DDoS attack, you should follow those including enabling captcha for countries with unusual traffic volume. https://support.cloudflare.com/hc/en-us/articles/200170196-I-am-under-DDoS-attack-what-do-I-do-

See also, page rules and restoring visitor IP as additional things you could be doing.

At the moment you’re not proxying traffic through Cloudflare and if the attacker knows the server IP they can certainly bypass Cloudflare as well if you haven’t restricted access to just Cloudflare’s IPs.


#9

see this for example https://github.com/imndr/CloudFlareBypass (even if its old its just proof of concept)

lets say the attacker has 6000 bots, your server can take 100 rps before it crash, if the attacker program the bots to send only 1 request per minute, your site will crash even if the requests will need to wait 5 seconds before accessing the site, your rate liming rules will also not block it as 1 requests per minute will probably not trigger the limit


#10

No offence, but I am not going through 400 lines of code to check whether that can actually bypass anything or not. Could you please elaborate here how it manages to bypass Cloudflare’s validation? I am sure this will be of interest for Cloudflare as well.


#11

I don’t doubt there are ways to bypass IAUM by writing a better bot. That proof of concept is no longer valid but it’s the interwebs, threats evolve over time as do responses to them. As @boynet2’s linked article suggests there are number of other things one ought to do as well.


#12

you shouldn’t go through this lines, you just need to believe… and cloudflare knows about it for sure… layer 7 attack its complex sometimes the only solution is just adding more power to the stack(or make your website 100% cacheable)

there is still not 100% legit way to detect bots on the internet

you can read more about IAUM here https://security.stackexchange.com/questions/154975/what-is-the-website-checking-about-my-browser-to-protect-the-website-from-a-ddos


#13

0.29 is the load on the processor at the time of the screenshot, at the time of the attack the load was more than 100%, now I turned off the proxy and redirected to another service.


#14

If I wanted to believe I’d go to a church :wink:

As you based your statement on that link I was under the impression you were familiar with it and could elaborate on it.

I am sure there may be ways to circumvent IUA, however these should require something more than a couple of PHP lines and would involve proper session and JavaScript management. Hence I still stand by my earlier response that it should not have been much of an issue with IUA.


#15

The problem is your security level was not high enough and - most importantly - you leaked your IP address by switching off the proxy. At this point nobody can give you a guarantee anymore and you should probably get a new IP address to be on the safe side.


#16

:joy:

I will not because you don’t need to invent the wheel to bypass the check, every time you access a site with the mode enabled and you don’t see any captcha it mean your browser passes it for you, why do you think they really can know when someone is real visitor and when someone is “attacking bot” ?(not want to insult cf ofcourse they are great service)

if you need more proof you can search the forum there is a few threats with people site down even with the mode enabled, its “not fun” to really know the truth: sometimes there is no real solution for layer 7.

relevant posts:


#17

I before disabling the proxy changing ip to another system


#18

You should change the address after you have re-enabled it. Otherwise you run the risk people know that address and bypass Cloudflare.


#19

I am not sure what you mean by that question, but there is no captcha as Cloudflare already runs a browser integrity test.

Thanks for the links, but the second one does not reference IUA at all, whereas the first one does mention it (but so did the OP in this thread, which turned out to be only semi-true) but as the thread came to a halt relatively quickly and the OP never went more into details it is difficult to say what happened. My point here is, both postings are not really examples of IUA not working.

Yes, there might be ways to circumvent it, but unless you can control a large number of browsers who can simulate user behaviour you should be on the safe side.


#20

@paladin592 if you have access to your web server configuration you can also setup the web server to only respond to cloudflare requests so if anyone bypasses cloudflare proxy and tries to talk to your origin web server directly they won’t be able to. You can do this via Cloudflare Authenticated Origin Pull certificates https://blog.cloudflare.com/protecting-the-origin-with-tls-authenticated-origin-pulls/

and https://support.cloudflare.com/hc/en-us/articles/204899617

Cloudflare to Origin Server

Authenticated Origin Pulls let origin web servers strongly validate that a web request is coming from Cloudflare. We use TLS client certificate authentication, a feature supported by most web servers, and present a Cloudflare certificate when establishing a connection between Cloudflare and the origin server. By validating this certificate in origin server configuration, access can be limited to Cloudflare connections.

Authenticated Origin Pulls is particularly important when taking advantage of the Cloudflare Web Application Firewall (WAF) security features. By using Authenticated Origin Pulls with a restricted-to-Cloudflare configuration, websites can be sure all traffic has been processed by a state of the art Web Application Firewall.