More precisely, I did set up CrowdSec, I tried to ban myself with my IP (even my cellular IP for my phone), but access is always granted. Even in private browsing.
I tried to ban myself by adding an explicit rule in the CF dashboard, and still, It works.
So, I can exclude CrowdSec to not working correctly (as It correctly give banned records to CF), somethings doesn’t work from the CF side.
I choose “Managed Challenge” because when CrowdSec created a rule, It choose the same. I don’t know if I can change to “Block” without breaking CrowdSec stuff.
Do you see any activity on that firewall rule? If you see device via your IP being managed challenged, then it is hitting the rule properly, but managed challenge will only issue JS Challenges or CAPTCHAs as it sees fit to determine the validity of the client.
Yes, I can see activities. It comes from my Nextcloud Desktop app trying to reach my server. The action taken is “Managed Challenge” as expected but why my HTTP requests on my browser still work? CF considers it as safe? If so, that’s not the intended behavior, CrowdSec takes care of that, would I then switch to “Block” action, praying to not break stuff?
Oh well, funny thing. I tried to push some stuff on my GitLab server and… I got error 403, like expected. So, CF rule works but not in the web browser?
I am not familiar with CrowdSec, but if it is an IPS in your network filtering traffic (based on my 30-second read), and it is not integrated with Cloudflare in any way, then the platforms are separate.
Cloudflare’s WAF is a public-facing firewall for your web applications that can help your curb bots, DDoS, SQL injections, RCEs, and more. Actions like Block will reject all traffic to that site and Managed Challenge issues a CAPTCHA or JS Challenge to test the browser.
CF does limit uploads on Free plans to 100MB which may be an issue to consider with GitLab. Managed Challenges are designed for use with browser-facing web traffic (your front page, your admin login portal, your shop front), and enable you to verify with high confidence that it is a person interacting with your site. It often blocks automated scripts and CLI tools as many tools can not complete the challenges to verify. This is why API traffic is best protected with WAF rules focusing on rate-limiting, schema validation, and more.