Я исследую влияние утечка данных полезной нагрузки CloudFlare из-за ошибки парсера об услугах, которые мы используем.
Относительно легко определить, направляет ли сервис трафик в CloudFlare через 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)
Завершает ли CloudFlare весь направленный им таким образом трафик, или, если нет, есть ли способ независимо определить, использует ли клиент CloudFlare службу обратного прокси CloudFlare?
Посетите IP-адрес, который вы получите при поиске в DNS:
$ ping authy.com
PING authy.com (104.16.0.17) 56(84) bytes of data.
Итак, переход к 104.16.0.17 в моем браузере дает мне следующее: Прямой IP-доступ запрещен
Если вы хотите автоматизировать это, я уверен, что вы можете использовать curl или аналогичный инструмент, но для каждого отдельного сайта это самый простой способ, который я могу придумать.
ПРИМЕЧАНИЕ. Кто-то может «подделать» страницу, чтобы она выглядела как страница Cloudflare, когда это не так, поэтому этот метод не является надежным и не гарантированно работает.
Взгляните на данные whois для любого веб-сайта, подозреваемого в использовании Cloudflare:
$ whois authy.net|grep "Name Server"
Name Server: LEE.NS.CLOUDFLARE.COM
Name Server: MARY.NS.CLOUDFLARE.COM
Все, что заканчивается на NS.CLOUDFLARE.COM, называется Cloudflare, однако владелец сайта может не использовать обратный прокси-сервер (он же сервер затенен серым облаком), поэтому они просто используют DNS-серверы Cloudflare.
Другой способ 2 может не работать, если сервер DNS - это CNAME, который будет выглядеть как частный / не относящийся к Cloudflare DNS-сервер, но при запросе он вернет Cloudflare.
Заключение: вы должны использовать методы 1 и 2, чтобы быть уверенным, что они используют обратный прокси-сервер Cloudflare.