Поиск IP сайта за CloudFlare

Методики, описанные ниже, применимы не только к CloudFlare, но и к другим сервисам защиты (например, DDoS-Guard, StormWall и аналогам). Причина в том, что у всех них используется одна и та же базовая архитектура - реверс-прокси, при которой в DNS записях домена (обычно «A» для IPv4 или «AAAA» для IPv6) указывается IP адрес прокси, а реальный сервер остается скрытым за этим самым прокси сервером и принимает проксируемый трафик.

Если исходный сервер по ошибке где-то «засветился» (в DNS, истории Whois или поддоменах), это может привести к обходу защиты и атаке (DDoS или эксплуатация OWASP уязвимостей) напрямую на бэкенд, в обход защиты от DDoS и WAF. Именно такие ситуации важно уметь выявлять владельцам сайтов и пентестерам.

Расходники

Для поиска IP требуется единственный расходник - специализированный сервер с высокой пропускной способностью и производительным аппаратным обеспечением, при этом принципиально важно, чтобы на нем было разрешено массовое сканирование портов. В противном случае существует высокая вероятность, что сервер будет отключен хостинг-провайдером в течение первых часов эксплуатации. Это связано с тем, что у подавляющего большинства легальных хостинг-провайдеров массовое сканирование портов запрещено: владельцы AS и подсетей, попадающих под сканирование, начинают массово направлять жалобы на IP адрес сервера, с которого фиксируется всплеск запросов к одним и тем же портам. У ряда провайдеров, включая Hetzner, OVH и DigitalOcean обработка и отправка подобных жалоб осуществляется в автоматическом режиме.

Серверы, на которых разрешено массовое сканирование портов, как правило, доступны исключительно через так называемый «серый» рынок. Минимально требуемая конфигурация включает:

• Процессор Xeon E3-1240v3
• Оперативная память 32 GB
• Накопитель SSD или NVMe 10-40 GB
• Cетевой канал 1 GBPS

Стоимость аренды сервера с подобными характеристиками на «сером» рынке варьируется от 900 до 1200 долларов США в месяц. Использование серверов с менее производительными характеристиками также возможно, однако в таком случае продолжительность сканирования существенно возрастает и может достигать нескольких недель либо месяцев.

Тем, кто не готов тратить сотни долларов на аренду сервера и погружаться в технические детали процесса, доступна возможность воспользоваться услугой разового определения IP адреса сайта, находящегося за CDN. Стоимость такой услуги составляет в среднем от 50 до 400 долларов США.

Зона поиска

На первоначальном этапе «сетевой разведки» необходимо установить предполагаемое местонахождение сервера, что позволит существенно сузить область поиска. В противном случае потребуется сканирование всего адресного пространства IPv4 (от 0.0.0.0 до 255.255.255.255), что значительно увеличит временные и вычислительные затраты.

• Используя утилиты DIG или NSLOOKUP необходимо проанализировать все DNS записи целевого домена и его поддоменов. В отдельных случаях одна из записей может содержать IP адрес бэкенда либо сервиса, размещенного в той же инфраструктуре (например, почтового сервера), что дает понимание о возможном потенциальном расположении сервера.
• Дополнительно следует проанализировать историю изменений IP адресов домена. Обнаружение ранее использовавшихся IP адресов может указывать на хостинг-провайдера, у которого ресурс размещался в прошлом, что представляет собой дополнительный источник информации для поиска сервера.
• В случае использования сайтом CMS WordPress возможно выполнение pingback запроса с помощью скрипта XMLRPC на собственный IP адрес, что в ряде случаев позволяет определить DNS сервер хостинг-провайдера, обслуживающего бэкенд.

Если один или несколько из перечисленных методов дали результат, следующим шагом является определение номеров автономных систем (AS), к которым относятся полученные IP адреса. Для этого может быть использован любой Whois сервис.

После формирования списка ASN производится получение всех объявленных ими подсетей через публичные базы маршрутизации (например, RADB).

Софт

Далее, по сформированному списку подсетей, выполняется поиск реального сервера целевого домена с использованием специализированного программного обеспечения, которое применяется при поиске серверов, размещенных за CloudFlare и другими CDN:

• Masscan - высокопроизводительный сетевой сканер, предназначенный для быстрого обнаружения открытых портов в больших диапазонах IP адресов. С его помощью осуществляется проверка всех ранее полученных подсетей на наличие IP адресов, принимающих входящие соединения на портах 80 и 443. Результатом сканирования является список IP адресов, на которых потенциально запущены web-серверы (Nginx, Apache, LiteSpeed).
• HTTPX (ProjectDiscovery) - утилита прикладного уровня, работающая поверх HTTP/HTTPS протоколов. Она выполняет GET запросы к каждому IP адресу, полученному на этапе сканирования портов, с подстановкой заголовка «Host», соответствующего целевому доменному имени. Полученные ответы анализируются и сопоставляются с ответом получаемым при обращении к целевому домену, при этом осуществляется поиск заранее заданного текстового паттерна. В качестве такого паттерна может использоваться уникальный элемент содержимого сайта, например код верификации поисковой системы, размещенный в HTML исходнике страницы. При обнаружении совпадения соответствующий IP адрес фиксируется в результатах как потенциально связанный с бэкенд-сервером.
• Zgrab2 - модульный инструмент для активного сетевого сбора данных, применяемый для получения и анализа сервисных баннеров и метаданных сетевых служб. В контексте HTTPS он может использоваться для извлечения информации из TLS сертификатов серверов, доступных на 443 порту. Анализ полей сертификата (например, Common Name или Subject Alternative Name) позволяет выявить IP адреса, в сертификатах которых присутствует имя целевого домена. Данный подход может быть использован в качестве альтернативы в тех случаях, когда анализ HTTP ответов не дает результатов.

В случае если был выявлен потенциальный IP адрес, следующим этапом является подтверждение того, что данный адрес действительно соответствует бэкенд‑серверу целевого домена. Для этого могут применяться следующие варианты:

• Нагрузочное тестирование (DDoS) предполагаемого IP адреса с целью оценки влияния на доступность целевого домена. Совпадение деградации доступности целевого домена с моментом подачи нагрузки указывает на принадлежность IP адреса к целевому домену.
• IP адрес может быть временно сопоставлен с целевым доменным именем на локальной системе путем внесения соответствующей записи в файл «hosts». После этого выполняется взаимодействие с сайтом и проверка корректности работы функциональности, требующей обращения к серверной части и базе данных, включая поиск по сайту, регистрацию пользователей, восстановление пароля и аналогичные операции.

Успешное выполнение указанных действий позволяет с высокой степенью достоверности подтвердить, что выявленный IP адрес является бэкенд‑сервером целевого домена.

Защита

В случае если в ходе поиска не удается выявить реальный IP адрес сервера даже после проверки всего доступного адресного пространства, это свидетельствует о корректно реализованной защите от прямого обнаружения. Как правило, такая защита достигается за счет строгой сетевой фильтрации: на уровне межсетевого экрана (фаерволла) сервер настраивается таким образом, чтобы принимать входящие соединения исключительно с подсетей CloudFlare либо иного используемого CDN, блокируя все остальные подключения ко всем сетевым портам.

Следует отметить, что даже при подобной конфигурации остается возможность раскрытия реального IP адреса сервера, связанная не с сетевыми настройками, а с уязвимостями прикладного уровня, классифицируемыми в рамках OWASP:

• SSRF (Server-Side Request Forgery) - уязвимости этого класса возникают в случаях, когда серверное приложение позволяет пользователю косвенно инициировать сетевые запросы от имени сервера без надлежащей фильтрации или ограничения целевых адресов. Эксплуатация подобных уязвимостей может привести к выполнению запросов во внутренние сети, обращению к служебным ресурсам или получению информации о сетевой конфигурации сервера, включая его внутренние или внешние IP адреса. SSRF в контексте данной статьи представляет особую опасность.
• SQL инъекции - представляют собой класс уязвимостей, при которых пользовательский ввод некорректно обрабатывается и напрямую включается в SQL запросы к базе данных. При наличии подобных ошибок возможно несанкционированное получение данных, изменение структуры базы или доступ к служебной информации, которая в отдельных случаях может содержать сведения о сетевой конфигурации, внутренних адресах серверов или параметрах окружения. Хотя SQL инъекции не предназначены напрямую для определения IP адресов, они могут служить вспомогательным вектором утечки информации.
• RCE (Remote Code Execution) - уязвимости этого класса позволяют удаленному пользователю выполнять произвольный код на сервере. Наличие RCE фактически означает полную компрометацию системы, поскольку злоумышленник получает возможность выполнять команды операционной системы, получать доступ к сетевым интерфейсам, конфигурационным файлам и другим критически важным компонентам. В таком сценарии определение реального IP адреса сервера становится тривиальной задачей, однако сам факт наличия RCE указывает на критический уровень нарушения безопасности.

Поиск и эксплуатация уязвимостей указанных классов требуют значительного практического опыта, глубокого понимания архитектуры вэб-приложений и высокой квалификации в области информационной безопасности.

Вывод

Для поддержания надлежащего уровня безопасности необходимо регулярно отслеживать обновления всех компонентов системы и своевременно устанавливать их. Дополнительно рекомендуется периодически пользоваться услугами пентеста с целью выявления уязвимостей и потенциальных проблем на ранних этапах эксплуатации.