Cloudflare, how to do it right and don't reveal your real IP

Cloudflare, how to do it right and don't reveal your real IP

  1. Introduction
  2. Steps recommended by Cloudflare
    1. Whitelist Cloudflare IP addresses
      1. [Attack] Identify website IP using Shodan
      2. [Attack] Identify website IP using Project Sonar
    2. SSL mode and server certificate
      1. [Attack] Identify website IP using Cloudflare origin certificate
      2. [Attack] Identify website IP using Certificate transparency logs
    3. General website security guidelines
      1. Remove all DNS records you are not using
        1. [Attack] Query old DNS servers
      2. Run email on separate server/service
        1. [Attack] Identify “multi-purpose” servers
      3. After moving site to Cloudflare, change server IP address(es)
        1. [Attack] Search historical DNS/HTTP datasets
  3. You need to do more
    1. Alternative domain for your servers
    2. Default VHOST
    3. OOB leaking from the web application
      1. [attack] OOB via XXE
      2. [attack] OOB via SSRF
      3. [attack] OOB via DNS
      4. [attack] OOB via MAIL
      5. [attack] OOB via public APIs
    4. [attack] Application errors
    5. [attack] Historical leaks
    6. [attack] Domain enumeration
  4. Outro


If you are reading this blogpost you probably are or intend to be, a user of the Cloudflare platform (or a similar CDN platform). Just to explain it briefly Cloudflare is a world-wide distributed CDN, which makes your page load faster and offers a complex website protection in form of a WAF and DDoS shielding (by hiding your real IP address).

Tips included in this article are not intended only for Cloudflare users but are general OPSEC tips for all other similar solutions that are based on the confidentiality of your real IP addresses. Because if an attacker can find out the real IP address of your webserver, he could bypass the “shield” and target the server directly.

The goal of this blogpost is to show what needs to be done to have a secure working setup, explain why all of the countermeasures are really necessary by demonstrating the attacks that they are mitigating, to not reveal your origin IP address.

After you finish with the setup of your Cloudflare account, you are presented with the following guide: Recommended First Steps for all Cloudflare users.

Most of it covers all the necessary steps to have a working setup, but it contains two important security steps.

Whitelist Cloudflare IP addresses

The first one is the most important:

Step 1: Whitelist Cloudflare IP addresses

The title says it all. Simple and clear. However, for people that are not security focused, this may be a little bit misleading, since they may think the following:

Whitelist Cloudflare IP addresses, so if you have a firewall they will be able to access it without being blocked, or blacklisted.

This, however, is not true. The real idea behind this is:

Whitelist the Cloudflare IP addresses and reject anything else!

This is to allow access to your website only to Cloudflare and prevent the rest of the world (Crawlers) to access it directly and see what content is served on the specific IP address/host.

What if I don’t do it? How could someone find me in the gigantic world wide web?

[Attack] Identify website IP using Shodan

The first thing an attacker will do when searching for a server is to query Shodan, the search engine for internet connected devices. Using a simple query like

http.title:"Your website title"

he can search for all IP addresses of webservers that serve a website with that specific title. Easy. And there is a lot more to search for.

[Attack] Identify website IP using Project Sonar

Imagine it would be possible to scan the whole internet for webservers listening on common ports and then collect HTTP response data (the served website) from all of them. Well, it is. And some kind people do this even on a weekly basis and publish the results online. They are not as big as you may think. One dataset is approximately 60Gb in compressed form. Have a look:

Not only that an attacker can query the dataset for the title of your website, to get the IP address of your server, but he can also query all the historical datasets from the time when your website was still public.

SSL mode and server certificate

Another good idea is to enable SSL between Cloudflare and your “origin” server. Since LetsEncrypt exists, everybody aims for the Full (strict) option.

Step 4: Choose an SSL mode A short version of the answer to this question is: Only choose “Flexible” if your origin web server cannot accept secure (HTTPS) connections. Choose “Full” if you have a self-signed SSL certificate, and choose “Full (strict)” if you have a valid SSL certificate issued by a certificate authority.

Even Cloudflare offers you free certificates for your origin servers.

Use Origin CA to generate certificates for your origin servers, using wildcards for each zone to keep SANs to a minimum. Upgrade each zone’s SSL setting from “Flexible” or “Full” to “Strict” mode you have Origin CA or public CA certificates installed protecting all hostnames in that zone

But there is a catch…

[Attack] Identify website IP using Cloudflare origin certificate

Using an origin SSL certificate is a good and easy solution, but only if you do all the other things right. In a situation when you set up your webserver to serve a neutral website as a default VHOST (to avoid being identified when accessing via IP), but your hosting provider / port range is small and all your other server are in the same hosting, it is not that hard to check the certificate issuer on all the IPs in that range to determine which hosts use Cloudflare.

[Attack] Identify website IP using Certificate transparency logs

Keep in mind that when an SSL certificate is issued, data about it is published to the Certificate Transparency Log, that is publicly available and searchable. So if you issue a new certificate for your domain (to be used by the origin host) it gets published and can easily be found and the new hostname revealed. Just have a look at A way better idea is to use a wildcard certificate.

General website security guidelines

If you take your security serious enough, you will probably search for other sources with security tips, and you will run into the following blog by Cloudflare: General website security guidelines

Even if the title says “general guidelines”, all of the included tips are very important.

The following website security guidelines are appropriate for all Cloudflare customers.

  1. Do not rate-limit or throttle requests from Cloudflare IP addresses.
  2. Make sure you are seeing original visitor IP addresses in your logs.
  3. Remove all DNS records you are not using.
  4. Run email on separate server/service.
  5. After moving the site to Cloudflare, change server IP address(es).
  6. Utilize Rate Limiting to Prevent Brute Force and Layer 7 DDoS Attacks
  7. Check WAF settings to Prevent Dynamic Attacks

Let’s have a closer look at the most related to this topic.

Remove all DNS records you are not using

If you are moving your domain to a CDN, keep in mind that the CDN will act as the authoritative DNS for the domain, there is no need to keep the old DNS server zone in place (or even the DNS server/service itself). As soon as the switch is complete, remove the domain/zone from your DNS server.

Do not remember to remove PTR records (reverse DNS entries) for the IP addresses too.

[Attack] Query old DNS servers

One of the things an attacker will do during his search for your origin IP addresses is to scan all your known IP addresses for ports 53/udp and 53/tcp to find a DNS server. If you did not remove the old DNS records from your DNS server and you have not changed the origins IP address after the switch to Cloudflare, or the DNS entries point to the new IP addresses for your own convenience, you have just leaked your real origin IPs.

Remember that a similar search will be performed for reverse DNS lookups of all your (or IP in your/hostings IP ranges) IP addresses, just to verify that they do not resolve to the name of the target server (or it’s aliases).

Run email on separate server/service

Do not run your mail server (or another public service) on the same server your web server. Besides performance reasons, and all the infosec best practices, it is a very bad idea in terms of OPSEC. Keep in mind that the MX records (DNS entries for mail delivery, pointing to your mail servers) are not proxied by Cloudflare and are pointing to the real IP address of the mail server. So if your mail server is your webserver too, well this is a problem.

Do not forget to review your SPF records too.

You can consider moving your mailserver to the cloud as well if possible (and desired), and use Gmail for example.

[Attack] Identify “multi-purpose” servers

As part of the recon process, an attacker will (as one of the first steps) check the mail server related DNS entries. This includes:

  • MX records - names / IP addresses of your mail servers
  • TXT records - containing SPF records with hostnames, IP addresses or IP ranges of “authoritative” mail servers

Armed with this knowledge an attacker will perform a portscan of the IP addresses or IP ranges to check for the presence of the target webserver.

After moving the site to Cloudflare, change server IP address(es)

This rule is the most essential one and should be written with big red letters on the top of the recommendations.


It makes no sense to hide an IP address if it is the same old IP you used for years and that is publicly known. So after you set up the CDN shielding, change the IP, or better change the hosting as well. If you want to improve it even further, put a cloud-hosted loadbalancer (like Amazon ELB) in front of it, just to have one more protection layer.

[Attack] Search historical DNS/HTTP datasets

It is not a big revelation that all data on the internet is archived in one way or another. Just remember the meme You cannot delete stuff from the internet. This is valid for DNS entries as well. Besides online services that can be used to search for historical DNS entries for a domain, like for example SecurityTrails, an attacker can simply download historical datasets from Project Sonar and search them.

You need to do more

It may already seem to be a lot of countermeasures to perform to just hide your IP, but you still need to do more. There are still more methods (or channels) an IP may leak. And there are still more attacks that you need to be aware of.

Alternative domain for your servers

It is a good practice use an alternate domain for your test servers (if you really need them public), or just for your convenience to access your production servers directly. Here are some tips that you should keep in mind:

  1. Choose a domain name not related to you

    If your main domain is, do not choose, since it could be revealed by a full-text search in DNS datasets. Or the certificate transparency logs. Instead, choose something completely unrelated like

  2. Use a proxy-registrant for the domain

    Do not use your company name or contact details for the domain, since it can be used to identify the domain. Instead, use a proxy-registrant service. Do not use a small local company as the registrar (since it is easier to enumerate all its registrations) for all your domains.

  3. Use a free SSL certificate

    Use LetsEncrypt, or a similar service, to obtain a valid SSL certificate. The goal is not to have it tied to your company.

  4. Not resolvable SLD

    Do not add a DNS record for the domain itself, only for its subdomains/hosts. This is just to keep the illusion that the domain is unused if resolved. has no A record

Default VHOST

For the sake of anonymity, it is a good practice to set the default VHOST of the webserver to something not related to your company/website. A good idea is to use a general placeholder, like the It works! from Apache webserver.

The reason for this is to serve this page, instead of your shielded webpage, when accessed via the IP address instead of a valid hostname (host header). This way you will not get indexed by scanners that access IP addresses instead of hostnames, and make it a bit harder for attackers searching for your webpage in a range of IPs.

OOB leaking from the web application

Remember that it is still possible to reveal the true IP address of your webserver by OOB (Out-Of-Band) communication. This is the reason why a webserver (and other parts of the application stack like DB) should not be allowed to initiate communication tot he internet. Strict firewall rules (whitelist) should be in place to deny any outgoing communication (not related to incoming HTTP requests). Let’s take a look at some examples.

[attack] OOB via XXE

If your application processes XML requests or documents, it does not perform input sanitization well and your XML parser is not properly configured, an attacker may use this functionality to force the server to load an external entity ( XXE ) or a remote DTD. In this case, the web server makes a request to a server controlled by the attacker via HTTP(S) (or FTP, SMB, GOPHER,..) revealing its IP address.

Even if outgoing connections are prohibited by the firewall, resolving the hostname from the request may be enough to reveal the IP (as described below).

Keep in mind that some JSON parsers support XML too, and may handle XML requests even if you do not use it.

[attack] OOB via SSRF

The same results as described in the section above can be achieved if an attacker can trick the application to perform a request by modifying any user-controlled parameter that is used as a URI ( SSRF ) or filename ( RFI ) by the application.

It is worth mentioning that the impact of these attacks (XXE, SSRF, RFI) is far more serious than just the possible leak of the servers IP address.

[attack] OOB via DNS

If the webserver is able to perform DNS queries directly (it’s running a local DNS cache server), and an attacker is able to force the server to perform a DNS request against a DNS server under his control, the servers IP address will be revealed.

Remember that even if your web application does not have any functionality that could be misused in such a way, some application frameworks do some checks automatically in the background. For example, resolving the content of the X-Forwarded-For HTTP header.

[attack] OOB via MAIL

If your web application is able to send e-mails (directly or via an external SMTP server), which probably is if user registrations are available, remember to verify the content of the mail headers to be sure the real sender IP address (webserver) is not included.

[attack] OOB via public APIs

Using VirusTotal to scan uploaded files in your web application? Keep in mind that the submitted URLs and domain names stored and resolved for their DNS database. You can query VirusTotal form information about a domain or IP Searching within public services for requests from your alternative “cloaking” domain can reveal the servers real IP.

[attack] Application errors

Errors in web applications and APIs should be only generic, to not reveal any sensitive information, like the servers IP address (or alternate hostname). Well, but sometimes they are not. And errors like Unable to connect to host/IP. or Unable to process request from host/IP. may be all that an attacker is searching for (at this moment).

[attack] Historical leaks

There is no such thing like 100% secure. This is why there are even some historical (and partial) leaks of older Cloudflare databases out there. One of them is Crimeflare. Use it to search for your domain in the old leaks.

[attack] Domain enumeration

The checklist is simple:

  1. Get all possible domains belonging to the target company (or individual)
  2. Obtain all existing hostnames / subdomains on all domains
  3. Obtain all IP addresses associated with the hostnames
  4. Get PTR records for the IPs
  5. Get all ASN / IP blocks belonging to the target company
  6. Get the listing of hostings target company is using
  7. Evaluate
  8. Repeat

These are the first steps any attacker will do. Not once but in many, many iterations including all the gathered information from the previous round. The goal is to obtain as many information as possible that can aid in all the other attacks.

Wow, this looks like a lot of work, and boring.

Indeed, but this is why tools like Sublist3r or OWASP Amass exist.


Hope this little blogpost was helpful to you, made you realize what steps need to be done in order to have a really working setup, and explained some of the attacks that can lead to the leak of your origin IP address.

But there are so many of them! How do we check all of this?

Don’t worry, we can help you with that 😋

About the author

Citadelo is a firm of ethical hackers on your side. We think like hackers, but we don't abuse it. On the contrary, our main goal is to reveal vulnerabilities without causing damage. We have been conducting simulated attacks for our clients since 2006
Show more from author

Related blogs