As DDoS attacks are trending in Denmark, I thought now would be a good time to share some of my knowledge on DDoS mitigation. I have actively prevented attacks using this method in the past, not only in the preparation phase, but also during eradication of an ongoing attack.

I will keep this guide on a free Cloudflare plan.

Why bother!? It is just DDoS…

I hear this phrase a lot from the security community, and they’re not wrong. What your company has pertaining business critical services, might not be what is targeted by a DDoS campaign.

However, public opinion might have a big impact on your organization, but can be overlooked in a risk assessment. In media, sensational/clickbait titles referring to a DDos attack are often portrayed as being more impactful and successful than they really are.

This is more than often the purpose of the attack and what the threat actors are hoping for. The semantics used in i.e. their tweets, is that of a defacement, although the attack is significantly less complicated and impactful.

Also, even DDoS attacks will take up valuable time from the employees who will inevitably try to stop the attack. DDoS attacks can also be used to mask a hackers actual presence in your environment, as all eyes will be on the threat that is seen at the moment.

But if it’s so easy, why not simply implement mitigation to stop the attack?

Prerequisites: DNS

Cloudflare is first and foremost a DNS service. This means that you will have to migrate all your DNS records for the domain to Cloudflare, and point your nameservers to Cloudflare. Depending on your previous DNS setup this might take up to 24 hours due to TTL on each record and DNSSEC.

Getting started

After setup, you can enable the Cloudflare proxy on the yellow cloud. When the proxy is turned on, Cloudflare intercepts all requests to the domain. NB: Consider what information is being sent and look out for GDPR and NIS2. Cloudflare is using their own TLS certificate and will use this to make TLS-termination in the cloud.

Navigate to the security panel and pick an option for DDoS mitigation. I recommend Managed Challenge when not undergoing an active attack, which scans each session and makes use of multiple methods to confirm human activity.

This setup is enough to stop the DDoS attack, if the attacker is sending requests to the DNS name. However it is often easy to find the origin public IP of your web-application, and tools like “Cloudmare” https://github.com/mrh0wl/Cloudmare, should be able to find this information in a split second. If the attackers have the actual origin IP, this will bypass the proxy altogether.

Avoid bypass

There are multiple places in the above basic Cloudflare setup that can be circumvented. There are ways of tricking the Managed Challenge, as it relies on “checks” from the users browser. Tools like https://github.com/FlareSolverr/FlareSolverr, can emulate legitimate user behavior in a proxy browser. If the threat actor is using tools like these, we have already made an impact on them and the attack, as this would be quite resource intensive, compared to simple HTTP flooding attacks. Nevertheless, there are measures you can take to avoid the attackers bypassing this (managed challenge if often updated and might be enough to stop it. Look in your Cloudflare event logs).

Depending on your use case, you could set the DDoS protection action to “Legacy Captcha”. This action will not do anything fancy like the Managed Challenge, but will force the use of Captcha on all user sessions. This will definitely make your website less user friendly, but can be a good measure if you need to have a high uptime for the users.

If you want to avoid Captcha on all the requests, you can use the WAF rules to give users Legacy Captchas, depending on country of origin or similar rules, to keep some user friendliness of the Managed Challenge. You can also just outright block everything based on geolocation, user-agent, threat score and many more options you might seem fit.

But there is another larger issue when it comes to bypassing the WAF and DDoS mitigation. If the threat actor can find the original public IP, the whole proxy would become irrelevant as it was bypassed on layer 3.

You can use your ingress to block IP’s other than Cloudflare’s. This whitelist option is nice to have and if you proceed with it you can find the updated Cloudflare IP-list here:

• https://www.cloudflare.com/ips/
• raw format: https://www.cloudflare.com/ips-v4

But this still enables the DDoS crew to spoof their IP to those of Cloudflare’s. Well… a safer option is to not have a public IP at all!

Cloudflare Tunnel

Using Cloudflare tunnel enables us to not expose any public IP. This should mitigate all bypasses in all layers besides layer 7. To use it find it in the left side menu:

This will require a credit card, but you can use the free plan.

In my Lab setup I have the very insecure-by-design web application “juice shop”, developed by OWASP running in a docker container on a ubuntu vm.

Using Cloudflare tunnel you need to install their “Cloudflared” as a connector. Cloudflare does a good job of guiding you to the install and for Debian it gave me a oneliner for bash installation.

curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/download/2023.1.0/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb && 
sudo cloudflared service install "your secret here"

Afterwards you need to configure a public hostname:

And that is all. You will now need to provide evidence that you are human before accessing our lovely juice shop.

Conclusion

I have in this post given a quick and easy solution for setting up Cloudflare in a secure way.

However I am not a red teamer, so if you feel like there are gaps in this setup, please let me know and we can work together to see if we can solve any issues. Having a known, good and tested configuration in Cloudflare could be an awesome feat.

Resources

• Title image generated with https://openai.com/dall-e-2/