Обход CDN и WAF: ищем реальный IP origin-сервера

На внешнем пентесте клиент заявил, что origin "полностью закрыт Cloudflare". Через 40 минут у меня был реальный IP - он торчал в SPF-записи, которую не обновляли с момента миграции на CDN. Прямой curl по этому IP с подменой Host-заголовка вернул полный ответ приложения. Без WAF, без rate limiting, без каких-либо фильтров. Вся защита на уровне CDN стала бессмысленной.

Это не единичный случай. Согласно исследованию Zafran (BreakingWAF, 2024), около 40% компаний из Fortune 100 и 20% из Fortune 1000 предположительно имеют origin-серверы, доступные напрямую из интернета в обход CDN/WAF. Из случайной выборки 1000 origin-серверов с Cloudflare Origin Server Certificate только около 13% предположительно реализовали Authenticated Origin Pulls. Остальные принимают подключения от кого угодно. Ниже - recon-пайплайн, который я использую на реальных проектах для обнаружения origin IP за CDN.

Зачем пентестеру поиск реального IP сервера за CDN​

Бизнес-логика атаки простая: CDN и WAF - прокси между клиентом и origin-сервером. Фильтрация SQLi/XSS, rate limiting, DDoS-митигация, гео-блокировки - всё это работает только пока трафик идёт через прокси. Когда атакующий узнаёт реальный IP и подключается напрямую, весь защитный слой перестаёт существовать. Красивый фантик, а внутри - сервер в чём мать родила. Подробнее - в нашем подробном разборе пентест веб-приложений.

На практике обход WAF Cloudflare и других CDN через origin discovery даёт:

• Прямой доступ к уязвимостям приложения, которые WAF блокировал
• Возможность провести DDoS origin-сервера напрямую, минуя CDN-буфер (Direct-to-Origin, D2O-атака)
• Обход IP-based allowlists, rate limiting и гео-блокировок
• Чистый fingerprinting реального стека (веб-сервер, ОС, TLS-конфигурация) без искажений CDN

В терминах MITRE ATT&CK деанонимизация IP за CDN - чистая фаза Reconnaissance: сбор информации об IP-адресах цели (T1590.005, IP Addresses), свойствах доменов (T1590.001, Domain Properties) и данных из CDN (T1596.004, CDNs). Каждая техника ниже ложится в конкретную подтехнику ATT&CK.

DNS history для поиска IP: пассивная разведка​

Сканирование исторических DNS-записей​

Если домен существовал до подключения CDN - старые A-записи с реальным IP сохранились в базах пассивного DNS. Это техника T1596.001 (DNS/Passive DNS) по ATT&CK. И это первое, что стоит проверить, потому что не генерирует ни единого пакета к цели.

Где искать:

• SecurityTrails - пожалуй, самая полная база исторических DNS-записей. Показывает все A, AAAA, MX, NS, CNAME-записи с временными метками. Ищем момент, когда A-запись сменилась с "обычного" IP на IP CDN-провайдера
• ViewDNS.info - раздел IP History покажет хронологию всех A-записей домена
• dnshistory.org - архив изменений DNS-записей разных типов
• completedns.com - мониторинг NS-серверов и истории падений

Конкретный пример: домен переехал на Cloudflare в 2023 году, а до этого резолвился в 185.x.x.x - этот адрес кандидат на origin IP. SecurityTrails покажет точную дату смены записей.

Отдельно стоит проверить SPF (TXT-запись) и MX-записи через dig example.com TXT и dig example.com MX. SPF часто содержит директивы ip4: с реальным IP сервера, откуда отправляется почта. Если почтовый сервер стоит на той же машине - origin обнаружен без единого активного сканирования. На практике именно SPF - самый "урожайный" источник. Админы обновляют A-записи при миграции на CDN, а про TXT забывают.

Subdomain enumeration для пентеста​

Основной домен может быть за CDN, а поддомены - нет. Типичные утечки origin IP через поддомены:

• mail.example.com, smtp.example.com - почтовый сервер часто на том же IP, что и приложение
• dev.example.com, staging.example.com, test.example.com - тестовые среды редко прикрывают CDN
• direct.example.com, origin.example.com - иногда администраторы сами создают записи для прямого доступа (да, я такое видел)
• cpanel.example.com, webmail.example.com - панели управления хостингом

Для перебора поддоменов годятся subfinder, amass, dnsx. Полученные поддомены резолвим и сравниваем IP с опубликованными диапазонами CDN-провайдера. Всё, что не попадает в диапазоны Cloudflare/Akamai/Fastly - потенциальный origin. Footprinting веб-приложений в чистом виде (T1590.002, DNS).

Поиск IP по SSL сертификатам и Certificate Transparency​

Certificate Transparency (CT) logs - публичные журналы, куда попадает каждый выпущенный браузерно-доверенный TLS-сертификат. Сервис crt.sh позволяет просмотреть все сертификаты, когда-либо выпущенные для домена.

Что ищем: если сертификат выпущен до подключения CDN, в поле Subject Alternative Name (SAN) может находиться IP-адрес или внутреннее hostname origin-сервера. После подключения Cloudflare сертификаты выпускает уже Cloudflare, но старые записи остаются в CT-логах навсегда. Как отмечают исследователи Intigriti, нужно обращать особое внимание именно на атрибут SAN - он часто содержит IP или внутреннее hostname origin-сервера.

Отдельный вектор - Cloudflare Origin Server Certificate. Согласно исследованию Zafran (BreakingWAF, 2024), Censys предположительно находит более 200 000 хостов в интернете, отвечающих именно с этим типом сертификата. Каждый такой хост - origin-сервер, к которому атакующий может подключиться напрямую. По заявлению исследователей, из случайной выборки 1000 таких origin-серверов на порту 443 около 780 вернули успешный HTTP-ответ. Только примерно 130 ответили кодами 400/403 или TLS handshake error - то, что ожидается при работающем mTLS. Подавляющее большинство принимают подключения от кого угодно. Задумайтесь: 780 из 1000 - просто открытая дверь.

CT-логи также позволяют обнаруживать связанные домены одной организации через общие SAN в одном сертификате (один сертификат редко содержит домены разных организаций). Этот приём расширяет поверхность для поиска origin.

Censys и Shodan для поиска origin: инструменты origin discovery​

IoT-поисковики индексируют каждый хост в интернете - баннеры, сертификаты, HTTP-ответы, заголовки. Это прямой путь к CDN unmasking, если origin отвечает на 80/443 с характерными признаками целевого сайта. По ATT&CK - T1593.002 (Search Engines) и T1595.001 (Scanning IP Blocks).

Базовые дорки для поиска origin:

Shodan: ssl:example.com (хосты с SSL-сертификатом для домена), hostname:example.com (hostname в баннере), http.title:"Заголовок сайта" (по title), http.html:"уникальный фрагмент" (по HTML-содержимому).

Censys: ввести домен в поиск и проверить вкладки Hosts и Certificates. Censys особенно силён для поиска сертификатов - его CT-индекс обширнее.

FOFA: cert.subject.cn="example.com" (по CN сертификата), title="Заголовок", body="уникальный текст".

Netlas: certificate.names:example.com, http.title:"Заголовок", http.body:"ключевое слово".

Принцип один: ищем хост с тем же контентом или сертификатом, что и целевой сайт, но с IP вне диапазонов CDN-провайдера. Если Shodan показывает три хоста с одинаковым сертификатом для example.com, а два из них - IP Cloudflare, третий с высокой вероятностью origin.

Favicon hash для идентификации сервера​

Favicon - иконка сайта во вкладке браузера. Если origin отвечает с тем же favicon, что и сайт за CDN, его можно найти по MurmurHash3 через Shodan. Команда вычисления хеша (по методологии, описанной Intigriti):
Полученный хеш подставляем в Shodan: http.favicon.hash:<значение>. Результат - все хосты в интернете с таким же favicon. Фильтруем IP CDN-провайдера - оставшиеся адреса указывают на origin. Техника работает, потому что favicon обычно не меняется при подключении CDN. Мелочь, а сдаёт с потрохами.

Уникальные строки и провокация ошибок​

Ещё один вектор - поиск уникальных строк в ответах сервера через Shodan и Censys. Copyright-строки, специфичные комментарии в HTML, нестандартные заголовки HTTP-ответа - всё это становится поисковым запросом. Как отмечают исследователи Intigriti, намеренная провокация ошибок (инъекция спецсимволов, нестандартные payload'ы) может заставить приложение раскрыть информацию о хосте, включая origin IP, в verbose error messages.

Проверяйте исходный код страницы (Ctrl+U) на наличие уникальных фрагментов - специфичных комментариев разработчиков, необычных названий файлов, ссылок на internal-ресурсы. Каждый такой артефакт - потенциальный дорк. Иногда в HTML валяется комментарий вида <!-- deployed from 10.0.2.15 --> - и это уже половина ответа.

Утечка IP через письма, mail-серверы и SSRF​

Email-заголовки​

Многие приложения отправляют email напрямую с origin-сервера: регистрация, сброс пароля, уведомления. Заголовок Received: в полученном письме содержит IP-адрес отправителя. Если почта идёт не через сторонний сервис (SendGrid, Amazon SES), а через локальный MTA - в заголовках окажется реальный IP origin-сервера.

Как проверить: регистрируемся на сайте, запрашиваем сброс пароля, смотрим raw-заголовки полученного письма. Ищем Received: from с IP, не принадлежащими CDN-провайдеру. Помимо Received, проверяйте кастомные заголовки - приложения иногда добавляют X-Originating-IP или аналоги. Тут главное не полениться и посмотреть полные заголовки, а не только тело письма.

SSRF для раскрытия origin IP​

Если на целевом сайте удалось найти SSRF-уязвимость - это прямой путь к origin IP. SSRF заставляет origin-сервер выполнить исходящий запрос на контролируемый ресурс. На стороне нашего сервера фиксируем входящее подключение - его source IP и есть origin.

В качестве приёмника удобен InteractSH от Project Discovery - бесплатный OAST-сервер, который логирует входящие HTTP, DNS и SMTP-запросы. Отдельный случай - WordPress XML-RPC Pingback: если сайт на WordPress и XML-RPC включён, метод pingback.ping заставляет сервер выполнить HTTP-запрос на указанный URL. Для origin discovery этого хватает за глаза.

Обход CDN через Alternate Domain Routing​

Эта CDN unmasking техника описана в исследовании, опубликованном на APNIC Blog, и реализована в инструментах cdn-proxy и cdn-scanner (доступны на GitHub). Штука хитрая - и на практике работает пугающе хорошо.

Суть: CDN работает на уровне L7 как reverse-proxy. TCP-соединения терминируются на сети CDN, затем CDN открывает отдельные соединения к origin. С точки зрения origin, источник запросов - IP CDN-провайдера. Эти диапазоны общие для всех клиентов CDN.

Сценарий атаки:

1. Атакующий определил IP origin-сервера любой из техник выше
2. Создаёт собственный аккаунт у того же CDN-провайдера (Cloudflare, CloudFront)
3. Настраивает origin в своём аккаунте на IP жертвы
4. Отключает WAF и все защитные функции в своём аккаунте
5. Отправляет запросы через свой CDN-аккаунт - они приходят на origin с IP CDN-провайдера и проходят через IP allowlist жертвы

Защита в виде "разрешить только IP Cloudflare" здесь не работает - трафик действительно идёт с IP Cloudflare, но через аккаунт атакующего без WAF-фильтрации. По документам всё чисто. На практике - дыра. Согласно публикации на APNIC Blog, значительная доля проанализированных доменов раскрывала свои origin IP тем или иным способом.

Инструмент cdn-scanner автоматизирует поиск: перебирает IP-адреса, подставляя их как origin в аккаунте атакующего на CDN, и проверяет ответ. Для CloudFront работает быстро, для Cloudflare - медленнее.

Защита от alternate domain routing: одних IP allowlists недостаточно. Нужен mTLS (Authenticated Origin Pulls у Cloudflare) или pre-shared secret в HTTP-заголовке (например, X-Origin-Verify), добавляемый через Cloudflare Transform Rule или Worker - это не встроенная функция CDN и требует ручной настройки. Origin должен проверять наличие и значение этого заголовка через firewall-правило.

Обнаружение origin сервера: верификация и прямое подключение​

Нашли кандидата на origin IP - нужно верифицировать. Подключаемся напрямую с подменой Host-заголовка:
Если ответ идентичен тому, что отдаёт сайт через CDN - origin подтверждён. Сервер принимает прямые подключения, весь WAF/CDN-стек обходится полностью.

Дополнительные проверки:

Если origin отвечает - дальше работа идёт по стандартной методологии пентеста, но уже без слоя защиты CDN/WAF. Считай, броня снята.

Чек-лист origin discovery для пентеста​

Порядок проверок от пассивных к активным:


Первые четыре шага не генерируют трафика к цели. Шаги 5-7 - обращение к сторонним сервисам. Шаги 8-11 - прямое взаимодействие с целевым приложением. На реальном проекте я прохожу все шаги последовательно, и обычно origin находится в первых трёх-четырёх.

Статистика из исследования Zafran по Fortune 1000 должна насторожить не только пентестеров, но и тех, кто считает CDN равноценной защитой origin. По оценкам исследователей Zafran, значительная доля компаний из Fortune 100 имеет origin-серверы, доступные напрямую из интернета - и это корпорации с многомиллионными бюджетами на ИБ. Для среднего бизнеса цифра наверняка хуже.

Проблема не в техниках обнаружения - они известны годами. Проблема в том, что defensive-команды не проверяют собственную конфигурацию. Я за последний год не встретил ни одного клиента, который бы самостоятельно тестировал origin exposure до начала пентеста. SPF-записи с прошлого хостинга, поддомены dev/staging без CDN, MX-записи на том же IP - это не экзотика, это дефолт. Alternate domain routing через cdn-proxy обходит даже IP allowlists, а единственная надёжная защита - mTLS - по оценкам исследователей, реализована лишь у малой доли серверов. Остальные полагаются на то, что "никто не узнает наш IP". Узнают. На HackerLab (ХакерЛаб) есть web-задачи, где без грамотного recon к флагу не подобраться - хороший способ проверить, работает ли этот пайплайн за пределами статьи.