Как находят настоящий IP сайта за Cloudflare - и как его спрятать по-настоящему

Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему

Сторонний мой проект: Zapret2UI.

Включили на домене оранжевое облачко в Cloudflare, DNS теперь показывает их IP вместо вашего, и вроде бы всё - спрятались, атаковать напрямую сервер уже не получится. Логично же: раз в dig виден только айпишник Cloudflare, значит настоящий адрес сервера просто нигде не найти.

Вот только это не так. И если вы завели Cloudflare именно ради этого - есть шанс, что ваш реальный IP уже год как лежит в открытом доступе, просто вы не проверяли.

Ниже - откуда именно течёт, как это ищут (в том числе на реальных инструментах, которыми пользуются пентестеры), и что сделать, чтобы IP правда перестал быть секретом полишинеля.

Кому пригодится: если держите сайт или сервис за Cloudflare и думаете, что этого достаточно; если настраиваете origin-сервер и хотите не облажаться с самого начала; или если просто любите разбирать, как всё это на самом деле устроено под капотом.

Сначала смотрим на это глазами того, кто ищет, потом - глазами того, кто закрывает дыры. Второе тут главное.

Содержание

Зачем вообще прятать origin IP
Что Cloudflare прячет, а что нет
Certificate Transparency: сертификат помнит всё
Ищем по отпечатку сертификата: Censys и Shodan
DNS-история: старые записи никуда не делись
Самая частая дыра: почта на том же IP
Забытые поддомены без оранжевого облака
Инструменты, которые делают это за вас
Защита: как спрятать IP по-настоящему
Чек-лист для своего сервера
Короткий итог

Источники

Зачем вообще прятать origin IP

Не только ради паранойи. Настоящий IP сервера за спиной у Cloudflare - это возможность обойти вообще всю защиту, которую вы, может, даже платно себе подключили: WAF, защиту от DDoS, гео-блокировки, rate-limiting. Всё это работает только пока трафик идёт через край Cloudflare. Нашли настоящий IP - бьёте прямо по нему, и никакой Cloudflare вас уже не спасёт, он просто не в курсе, что вас атакуют.

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

Что Cloudflare прячет, а что нет

Смотрим на базу, без неё дальше не будет понятно, откуда вообще берутся дыры.

Когда вы включаете на записи проксирование (то самое оранжевое облачко в панели), DNS для этого имени начинает отдавать не ваш IP, а IP Cloudflare. Весь трафик от посетителей идёт на их край (edge), а уже оттуда - к вашему серверу по отдельному каналу, про который снаружи никто не знает. С этого момента ваш IP из публичного DNS-ответа действительно пропадает.

Но защищает это ровно то, что вы сами прогнали через Cloudflare - и ни граммом больше. Три момента, из-за которых вся эта конспирация обычно и разваливается:

Проксирование включается на отдельную запись, а не на весь домен разом. Забыли включить облачко на каком-то поддомене - он торчит с настоящим IP открытым текстом.
Cloudflare (на бесплатном и большинстве обычных тарифов) проксирует HTTP/HTTPS. Почта, например, через них не ходит вообще никогда - MX-запись всегда смотрит прямо на реальный сервер.
Всё, что происходило с доменом до переезда под Cloudflare, никуда не испарилось. Сертификаты, старые DNS-записи - это всё уже разъехалось по десятку сторонних баз, которые Cloudflare никак не контролирует.

Дальше - именно эти три дыры, только подробно и с конкретными инструментами.

Certificate Transparency: сертификат помнит всё

Тут аналогия простая: представьте, что каждый выданный вам паспорт - вообще любой, даже давно просроченный - навечно записывается в общедоступный реестр, который никто не может подчистить задним числом. Примерно так работает Certificate Transparency (CT): с 2018 года браузеры требуют, чтобы каждый публично доверенный TLS-сертификат (в том числе бесплатный от Let's Encrypt) попадал в открытые логи. Причём даже отозванные сертификаты из логов не исчезают - записи только добавляются, стереть уже нельзя.

Если ваш сервер хоть раз получал сертификат напрямую - до того, как вы завели Cloudflare, или на служебном поддомене вроде direct.site.ru - эта запись висит в CT-логах и прямо сейчас, вне зависимости от того, что вы там давно поменяли.

Смотрится это одной командой (или просто в браузере на crt.sh):

curl -s "https://crt.sh/?q=site.ru&output=json" | jq -r '.[].name_value' | sort -u

Получите список всех имён, на которые когда-либо выписывался сертификат для этого домена. Дальше просто: резолвите каждое и смотрите, какой IP отвечает - если это не адрес Cloudflare, вот он, ваш кандидат.

Ищем по отпечатку сертификата: Censys и Shodan

Бывает хитрее: прямого сертификата на поддомен вы не найдёте, потому что его и не выпускали отдельно. Тогда заходят с другой стороны - через сам сертификат, который сервер отдаёт при TLS-рукопожатии.

Берём отпечаток (fingerprint) сертификата вашего сайта:

openssl s_client -connect site.ru:443 -servername site.ru </dev/null 2>/dev/null \
  | openssl x509 -noout -fingerprint -sha1

А дальше идут в поисковики по интернету вещей - Censys, Shodan, есть ещё китайские аналоги вроде FOFA и ZoomEye - и ищут по этому же отпечатку среди вообще всех просканированных IP в сети. Если origin-сервер отдаёт тот же сертификат напрямую (а не только через Cloudflare), поисковик его найдёт, даже если у вас нигде в CT-логах нет прямой записи на имя домена.

Логика простая: сертификат один и тот же что за Cloudflare, что напрямую на сервере (если вы туда его тоже поставили) - вот по этому совпадению и палится настоящий адрес.

DNS-история: старые записи никуда не делись

Домен почти никогда не рождается сразу под Cloudflare. Обычно сначала сайт крутится на голом IP хостинга, и только потом кто-то спохватывается и подключает защиту. А сервисы вроде SecurityTrails или ViewDNS.info годами хранят снепшоты DNS - в том числе ту самую старую A-запись, которая указывала прямо на ваш сервер до всех этих телодвижений.

И самое неприятное: сервер за это время часто банально не переехал. Тот же хостинг, тот же IP, просто DNS теперь красиво прячет его за облачком. Историческая запись при этом остаётся рабочей наводкой хоть через три года.

Самая частая дыра: почта на том же IP

Вот эта дыра работает без всякого расследования - никакие crt.sh и Censys не нужны, IP просто лежит в заголовках письма.

Причина техническая: Cloudflare проксирует HTTP и HTTPS, но не SMTP. MX-запись физически обязана указывать на реальный IP, иначе почта никуда не придёт - через прокси её никто не погонит. А на дешёвом хостинге (типичная cPanel-сборка «всё в одном») сайт и почтовый сервер сплошь и рядом сидят на одной и той же машине с одним и тем же адресом.

Проверяется в одну строчку:

dig MX site.ru +short

Если увидели там что-то вроде 10 mail.site.ru, резолвите это имя - велика вероятность, что это и есть настоящий IP вашего сервера, просто до него дошли не через сайт, а через почту.

Забытые поддомены без оранжевого облака

Проксирование включается на каждую запись отдельно, и про какие-то поддомены со временем банально забывают. Классика: admin.site.ru, cpanel.site.ru, direct.site.ru, ftp.site.ru, dev. или staging. - завели для внутренних нужд, облачко на них включить забыли (а часто и не хотели: панели администрирования через прокси иногда сами работают криво), и они годами тихо светят настоящим IP всем, кто вообще додумался их поискать.

Найти такие поддомены помогает всё тот же crt.sh (сертификаты часто выписываются сразу на несколько имён в одном запросе) плюс обычный перебор по словарю частых префиксов. А отличить проксируемую запись от прямой легко: если резолвится в диапазоны Cloudflare - спрятана, если в любой другой IP - нет.

Инструменты, которые делают это за вас

Всё описанное выше давно автоматизировано, руками искать почти никто не заставляет.

CloudFlair (github.com/christophetd/CloudFlair) - собирает список кандидатов из crt.sh, пробивает каждый через Censys и сверяет, отвечает ли IP тем же контентом, что и сайт напрямую. Классика жанра, десятки форков.
unwaf - более свежий инструмент того же назначения (обновлённая версия вышла в начале 2026-го), заточен конкретно под поиск origin-адресов за WAF, работает по похожей связке сертификатов.

Показываю не для того, чтобы вы побежали это на кого-то натравливать, а чтобы было понятно: это не какая-то экзотика уровня спецслужб, а готовые опенсорсные тулзы в один git clone. Если для вас это в одну команду - для кого угодно другого тоже.

Защита: как спрятать IP по-настоящему

Тут по-честному: если IP уже когда-то засветился (старая DNS-запись, прямой сертификат в CT-логах), из истории вы это не сотрёте. Логи в CT неудаляемые, а архивы DNS-истории Cloudflare вам не подчинить. Реальных рабочих вариантов у вас два, и лучше оба сразу.

1. Firewall только на IP-диапазоны Cloudflare. Главная и самая рабочая мера: сервер вообще не должен отвечать на 80/443 никому, кроме Cloudflare. Тогда даже человек с вашим настоящим IP на руках упрётся в закрытый порт. Актуальный список диапазонов Cloudflare публикует сам, забирать удобно прямо оттуда:

for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  ufw allow from "$ip" to any port 80,443 proto tcp
done
for ip6 in $(curl -s https://www.cloudflare.com/ips-v6); do
  ufw allow from "$ip6" to any port 80,443 proto tcp
done
ufw deny 80,443/tcp

Список время от времени меняется, так что раз в пару месяцев стоит перезаливать.

2. Catch-all на веб-сервере, который ничего не отдаёт левым Host-заголовкам. Даже если кто-то и достучится напрямую (например, вы ещё не успели включить firewall), сервер не должен показывать настоящий сайт на голый IP. У nginx для этого есть default_server:

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    server_name _;
    return 444;
}

444 - это специальный код nginx, который просто рвёт соединение без ответа. Реальный сайт отдаётся только виртуальным хостом с точным именем домена, а на любой другой Host - тишина.

Дополнительно, но тоже важно:

Замените публичный сертификат на Origin CA от самого Cloudflare. Он доверенный только внутри их сети, между Cloudflare и вашим сервером, а не публично - соответственно, в общие CT-логи, по которым ищут через crt.sh, он не попадает так же, как обычный Let's Encrypt. Старые записи это не удалит, но закроет утечку на будущее.
Уберите почту с того же IP, если это в принципе возможно - отдельный сервер под SMTP или сторонний почтовый сервис. Тем более что с блэклистами и репутацией у почтового IP своя больная тема, это уже отдельный разговор.
Проксируйте вообще все записи, включая служебные поддомены. Если админке не нравится жить за прокси - лучше повесить её за VPN или Cloudflare Access, чем оставлять голый IP.
Если хочется совсем без открытых портов на входе - смотрите в сторону Cloudflare Tunnel: сервер сам инициирует соединение наружу, входящих портов слушать вообще не надо, значит и находить на сервере физически нечего. Тема отдельная и большая, тут только обозначаю направление.

Чек-лист для своего сервера

curl -s "https://crt.sh/?q=ваш-домен&output=json" | jq -r '.[].name_value' | sort -u - и резолвите каждое имя.
dig MX ваш-домен +short - почта не должна палить основной IP.
Отпечаток сертификата через openssl s_client - и в Censys/Shodan, нет ли совпадений мимо Cloudflare.
Пройдитесь по всем DNS-записям в панели - на каждой ли включено проксирование, где не должно быть исключений.
Настройте firewall строго на диапазоны Cloudflare.
Добавьте default_server, который ничего не отдаёт по голому IP.
Замените сертификат на origin-сервере на Cloudflare Origin CA.

Короткий итог

Cloudflare прячет IP только для того, что реально проксируется - остальное (почта, забытые поддомены, история до переезда) торчит наружу как ни в чём не бывало.
Certificate Transparency и сервисы DNS-истории хранят записи вечно, задним числом это не почистить.
Совпадение отпечатка TLS-сертификата в Censys/Shodan вскрывает origin даже без единой прямой записи на домен.
Реальная защита - это не «включил облачко и забыл», а firewall на IP Cloudflare плюс default_server, который не отвечает по голому адресу.
Если IP уже когда-то засветился - его репутация тоже сгорела вместе с адресом, разумный шаг тут - взять чистый IP на новом сервере и сразу настроить всё правильно, а не гадать, кто и когда его найдёт.

Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему

Сторонний мой проект: Zapret2UI.