2

I'm investigating the impact of the leak of CloudFlare payload data due to a parser bug on services that we use.

It's relatively easy to tell if a service is directing traffic to CloudFlare via DNS:

$ nslookup www.authy.com
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    www.authy.com
Addresses:  104.16.0.17
          104.16.1.17

$ whois -h whois.arin.net n 104.16.0.17 | egrep 'Organization'
Organization:   Cloudflare, Inc. (CLOUD14)

Does CloudFlare terminate all traffic directed to them this way, or if not, is there a way to independently tell whether a CloudFlare customer is using CloudFlare's reverse proxy service?

rakslice
  • 473
  • 3
  • 11
  • 2
    It's not clear to me if this is on-topic for ServerFault, but it seems to fit as well as any other Stack Exchange site, so here goes. – rakslice Feb 24 '17 at 21:55
  • 1
    https://www.cloudflare.com/ips/ may be useful as a complement to what you're already proposing. – Håkan Lindqvist Feb 25 '17 at 16:52
  • 1
    There is also some historical data [here](https://github.com/pirate/sites-using-cloudflare) – Aaron Feb 25 '17 at 17:54

3 Answers3

3

Method 1 (Most Accurate)

Visit the IP you receive upon DNS lookup:

$ ping authy.com
PING authy.com (104.16.0.17) 56(84) bytes of data.

So, going to 104.16.0.17 in my browser gives me this: Direct IP access not allowed

If you would want to automate this, I'm sure you could use curl or a similar tool, but on an individual site-by-site basis, this is the easiest way I can think of doing this.

NOTE: Someone could "spoof" the page into looking like a Cloudflare page, when it isn't, so this method isn't foolproof or guaranteed to work.

Method 2 (Less Accurate)

Take a look at the whois data for any website suspected of using Cloudflare:

$ whois authy.net|grep "Name Server"
Name Server: LEE.NS.CLOUDFLARE.COM
Name Server: MARY.NS.CLOUDFLARE.COM

Anything that ends in NS.CLOUDFLARE.COM is Cloudflare, however, the site owner may not be using the reverse-proxy server (aka the server is gray-clouded), so they are just using Cloudflare's DNS servers.

Another way Method 2 may not work is if the server's DNS is CNAME, which it will look like a private/non-Cloudflare DNS server, but when queried, it will return Cloudflare.

Conclusion: You shoud use Methods 1 and 2 to be fairly certain they are using Cloudflare's reverse-proxy server.

Logan
  • 66
  • 5
  • Method 1 seems reasonably accurate. Method 2 is problematic, not only because of false positives (as you mention) but also because of [false negatives](https://support.cloudflare.com/hc/en-us/articles/200168706-How-do-I-do-CNAME-setup-). – Håkan Lindqvist Feb 25 '17 at 16:54
  • @HåkanLindqvist that is true, but it is also very rare, since you need to be a paying customer, and request a support ticket. Updating... – Logan Feb 25 '17 at 17:03
  • It does rule out the vast majority, however I'd argue that there's likely a decent overlap between which sites are paying customers and the sites where visitors actually exchange any sensitive information, so that particular aspect in itself is not necessarily the most limiting factor. – Håkan Lindqvist Feb 25 '17 at 17:10
  • Why is it not enough to just check the host's IP against the Cloudflare IP ranges list? – Violet Giraffe Apr 12 '20 at 11:21
0

Try https://cloudflare.hellafast.digital/

It checks nameservers automatically and gives you the answer

Roman
  • 1
0

If talking about http/https reverse proxy only - you can make a request to the hostname and see if there is a

CF-RAY

and or

Server: cloudflare

available.

Martynas Saint
  • 1,221
  • 7
  • 15