5 different ways to counter Cloudflare DDoS protection

Cloudflare is a company known very much for its great DDoS protection services which are able to mitigate great attacks against online services, technically by providing such service with a reverse proxy technique which also hides the IP address of the server behind the reverse proxy.

In this post, I’ll describe some of the most common pitfalls end-users of this service face. Hopefully, this information helps some OSINT researchers, journalists, and sysadmins to secure their websites.

The pitfalls of this service are actually mostly end-users own failures for not utilizing the service correctly, which leads into defeating the purpose of the reverse proxy by exposing the original server IP address.

I’ll be using my own website as an example in a few cases.

1. Current DNS exposure

While e.g. www.mikkonen.bio and mikkonen.bio might be secured by the reverse proxy, there might be other DNS records that expose the origin IP address.

For example. maybe the owner of mikkonen.bio has some other websites under his name, and they host them on the same server and have those other websites not secured by Cloudflare. Mitigation for this case is to protect all websites on the same server with Cloudflare.

Because in many cases people host a lot of their websites on the same shared server, they sometimes have also their emails on the same server (common for cheap cPanel based instances). In free-tier Cloudflare plans, it is not possible to e.g. hide IP address for MX records of the hostname with Cloudflare services. Mitigation for this case is to use some other party for email services.

Also, the SPF record might expose the origin sender IP address if it’s specified and if the IP address is also in use for the website as well as for sending emails.

2. Historical DNS exposure

Once someone has protected their server with Cloudflare, someone should change the origin IP address to something else to prevent attacks to occur on the same IP address the attacker might already know.

The attacker is able to store historical DNS information about your services for later purposes themselves, but there are also companies, that do this for free e.g. the awesome SecurityTrails which contains a quite large database of domains, hostnames, and their DNS records with IP addresses.

3. Exposure via mail transfer

Sometimes, the attacker might use login/register features of a website, to retrieve the origin IP behind the reverse proxy. Usually, web apps send an email or a password reset email that contains that origin IP address in the email headers, and even if 3rd party SMTP server is used.

Mitigation, in this case, is to use an SMTP server that doesn’t do this and the SMTP server should be located on a separate host from the website, so the sending IP address is not exposed e.g. in SPF records.

4. DMCA/phishing site/malware takedown notices

Proper DMCA/phishing/malware takedown notice exposes the network block or at least the autonomous system number of the origin IP address to whoever who issues such takedown notice for Cloudflare. Not encouraging to do this at all unless there is an issue with the topic said above.

Once the attacker knows about the network block where some website is located, the attacker is able to scrape all the network ranges the AS number/network block covers e.g. with multiple virtual machines. By using curl, someone could do something like this:

curl https://1.1.1.1 -H "Host: example.com" -k

and repeat that for every IP in address in the block for the hostname mikkonen.com until some of the hosts replies e.g. with correct content or correct HTTP status codes.

Mitigation for the scraping is to simply allow the site to be reached only from the Cloudflare listed IP ranges, but for serious notices e.g. about violating copyrights, there is no mitigation, unless someone would use a hosting provider that doesn’t comply with the law.

5. Certificate transparency logs

CloudFlair, together with the censys.io, as it’s very own description says:

The tool uses Internet-wide scan data from Censys to find exposed IPv4 hosts presenting an SSL certificate associated with the target’s domain name.

There is usually a very big chance that the SSL certificate related to your domain is indexed in the Censys database, and which also will lead to exposing the origin IP address of your host.

Mitigation for such issue is nicely described on the Github project as well:

CloudFlair is a tool to find origin servers of websites protected by CloudFlare who are publicly exposed and don’t restrict network access to the CloudFlare IP ranges as they should.

Leave a Reply

Your email address will not be published. Required fields are marked *