我正在调查由于parsing器错误导致的CloudFlare负载数据泄漏对我们所使用的服务的影响。
判断一个服务是否通过DNS将stream量导向CloudFlare比较容易:
$ 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)
CloudFlare会以这种方式终止所有指向他们的stream量吗?如果不是,有没有办法独立判断CloudFlare客户是否在使用CloudFlare的反向代理服务?
访问您在DNS查询时收到的IP:
$ ping authy.com PING authy.com (104.16.0.17) 56(84) bytes of data.
所以,在我的浏览器104.16.0.17给我这个: 不允许直接IP访问
如果你想自动化这个,我相信你可以使用curl或类似的工具,但是在一个站点的基础上,这是我能想到的最简单的方法。
注:有人可以“欺骗”页面看起来像一个Cloudflare页面,当它不是,所以这种方法是不是万无一失或保证工作。
看看怀疑使用Cloudflare的任何网站的whois数据:
$ whois authy.net|grep "Name Server" Name Server: LEE.NS.CLOUDFLARE.COM Name Server: MARY.NS.CLOUDFLARE.COM
以NS.CLOUDFLARE.COM结尾的任何内容都是Cloudflare,但是网站所有者可能没有使用反向代理服务器(又名服务器灰蒙蒙的),所以他们只是使用Cloudflare的DNS服务器。
另一种方式方法2可能无法正常工作,如果服务器的DNS是CNAME ,它将看起来像一个私人/非Cloudflare DNS服务器,但是当查询时,它将返回Cloudflare。
结论:您应该使用方法1和2来确定他们正在使用Cloudflare的反向代理服务器。