Публичный DNS и внутренние IP: удобство, которое превращается в вектор атаки

История обычно начинается одинаково. Администратору нужно быстро дать людям удобные имена для внутренних сервисов, и он просто добавляет их в ту же публичную DNS-зону, где живут сайты компании. В результате в интернете появляются записи вроде git.corp.example с адресом из частного диапазона. На первый взгляд ничего страшного: из внешней сети по серому адресу все равно не подключиться. Поэтому аргумент звучит просто: "максимум утечка информации, но точно не уязвимость".

Проблема в том, что такая картина верна только для классической модели "клиент подключается к серверу напрямую". Сегодня между внешним злоумышленником и внутренними сервисами стоит мощный посредник - браузер сотрудника и внешние веб-приложения. Именно через них строятся цепочки атак, которые умеют обходить границы сети. И здесь публикация внутренних IP и имен из "безобидной удобной практики" превращается в серьезный усилитель для DNS Rebinding, SSRF и других сценариев.

Что на самом деле означает запись внутреннего IP в публичном DNS

Когда мы создаем в публичной зоне DNS запись вида git.corp.example с адресом 10.0.0.5, мы делаем две вещи одновременно. С одной стороны, мы не открываем доступ к этому хосту из интернета: маршрутизации к серому адресу нет, трафик извне просто не дойдет. На сетевом уровне внешнему злоумышленнику действительно "не за что зацепиться". На этом месте многие споры и заканчиваются, хотя на самом интересном они только начинаются.

С другой стороны, мы объявляем всему миру: внутри нашей инфраструктуры существует узел с таким именем и таким адресом. Любой, кто может задать DNS-запрос, узнает не только сам факт его существования, но и схему именования, фрагменты структуры сети, иногда еще и окружения (например, по суффиксам -dev, -stg, -int). Это уже не просто "удобная запись для себя", а часть публичного профиля компании, доступная сканерам, ботам и людям.

Сетевой уровень: почему внешнего доступа действительно нет

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

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

Прикладной уровень: когда браузер и приложения становятся мостом

На прикладном уровне главным действующим лицом становится не маршрутизатор, а программное обеспечение, которое доверяет DNS и HTTP. Браузер сотрудника, мобильное приложение, веб-сервис с функцией загрузки ресурсов - все они умеют делать запросы внутрь сети, в том числе к серым адресам. Более того, они делают это от имени внутреннего пользователя или сервера, уже находящегося "по ту сторону" периметра.

Злоумышленнику не нужно добираться до внутреннего IP напрямую. Его задача - заставить чей-то браузер или сервер внутри сети сходить по нужному адресу и выполнить запрос. Как только это удается, открывается целый набор маршрутов: от чтения внутренних ресурсов и обхода политики одного источника до атак на служебные интерфейсы с отсутствием аутентификации. И тут внутренняя запись в публичном DNS перестает быть просто "шумом для разведки".

Разведка и утечка структуры: важная, но не единственная проблема

Про ОСИНТ в контексте DNS говорят довольно часто. Действительно, по публичной зоне можно собрать неплохую "карту" инфраструктуры: какие есть домены, окружения, сервисы, иногда даже технологии и имена команд. Это облегчает социальную инженерию, выбор целей для фишинга, планирование будущих атак и оценку того, куда выгодно вкладываться в разработку эксплойтов.

Если в публичной зоне живут записи с внутренними адресами, карта становится еще точнее: появляются реальные диапазоны серых сетей, а не только имена. Это упрощает последующую работу уже внутри контура - не нужно гадать, какие подсети бывают, можно сразу начинать с интересных. Но ограничивать обсуждение только разведкой - значит недооценивать более неприятные сценарии. Информационная утечка здесь не просто "приятный бонус" для злоумышленника, а ключевой элемент целого класса атак.

DNS Rebinding: когда браузер превращается в прокси внутрь сети

DNS Rebinding - класс атак, в которых злоумышленник заставляет браузер жертвы обращаться к ресурсам во внутренней сети, при этом для самого браузера все выглядит так, будто он общается с тем же доменным именем, что и раньше. В результате обходится политика одного источника, а браузер превращается в универсальный прокси, способный стучаться к веб-интерфейсам принтеров, панелям администрирования, внутренним API и другим сервисам, недоступным извне.

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

Сценарий DNS Rebinding шаг за шагом

Представим, что сотрудник компании открывает сайт evil.example, контролируемый злоумышленником. При первом обращении DNS-запрос на этот домен возвращает внешний адрес сервера злоумышленника, а время жизни записи минимально. Браузер устанавливает соединение, получает страницу и выполняет встроенный скрипт, который сидит в ожидании истечения TTL.

Через короткое время злоумышленник меняет DNS-запись для того же имени evil.example, но теперь вместо внешнего адреса указывает внутренний IP, например 10.0.0.5 - это адрес сервиса git.corp.example, который он заранее узнал из вашей публичной DNS-зоны. Браузер при очередном запросе к тому же доменному имени резолвит его уже во внутренний адрес и отправляет запрос во внутреннюю сеть, но считает, что по прежнему общается с evil.example. Политика одного источника не срабатывает, поскольку домен не поменялся, а изменение IP на уровне DNS для браузера прозрачно.

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

Как помогает публикация внутренних IP и имен

Ключевая сложность для DNS Rebinding в современных условиях - подобрать адреса и хосты, которые стоит атаковать. Браузеры и защитные решения частично пытаются ограничивать возможность обращения к частным диапазонам, но эти меры работают не везде и не всегда. Тем не менее злоумышленнику все равно приходится либо угадывать диапазоны, либо перебирать множество адресов, что делает атаку шумной и медленной.

Если же внутренняя структура аккуратно прорисована в публичном DNS, угадывать ничего не нужно. Есть четкий перечень имен и IP: git.corp.example, jenkins.corp.example, db-prod.corp.example. Можно точечно выбирать самые интересные цели и направлять на них браузеры сотрудников. То, что казалось "просто удобной записью для разработчиков", превращается в список конкретных целей для перепривязки DNS.

Ограничения и защитные меры против DNS Rebinding

Честности ради стоит отметить, что за последние годы браузеры и инфраструктура получили ряд защит от DNS Rebinding. Некоторые движки ограничивают доступ к приватным диапазонам по HTTP снаружи, появляются дополнительные проверки в политиках безопасности, используются прокси и фильтрация. Тем не менее исследования и практические кейсы показывают, что полностью класс атак не исчез, а просто стал более требовательным к навыкам злоумышленника.

Часть защит строится именно вокруг DNS. Фильтрация запросов к частным диапазонам, отдельные резолверы для внешних доменов, блокировка попыток резолвить имена, которые ведут на служебные интерфейсы, - все это снижает вероятность успешного Rebinding. И на этом фоне наличие в публичном DNS детальной карты внутренней сети выглядит мягко говоря лишним: вместо того чтобы усложнять жизнь атакующему, мы аккуратно подносим ему цели на блюде.

SSRF: когда ваши же серверы ходят внутрь по подсказке злоумышленника

Если DNS Rebinding эксплуатирует браузер, то SSRF атакует уже серверные приложения. Server Side Request Forgery - ситуация, когда злоумышленник добивается того, чтобы серверная часть системы самостоятельно отправляла HTTP-запросы на произвольные адреса, указанные в пользовательском вводе. Классический пример - функциональность "загрузить изображение по ссылке", "подключиться к вебхуку", "проверить URL".

Внешне все выглядит вполне безобидно. Пользователь указывает ссылку, сервер скачивает картинку, чтобы отобразить аватар, или делает запрос для проверки интеграции. Но если в приложении нет строгих ограничений на список допустимых адресов, злоумышленник может подставить URL, который ведет не в интернет, а во внутреннюю сеть. И здесь знание внутренних имен и адресов снова оказывается крайне полезным.

Почему наличие публичных записей внутренних хостов облегчает SSRF

Представим внешний сервис, который умеет скачивать картинки по URL. Внутри компании есть база данных, доступная только по адресу db-prod.corp.example, который в публичной DNS-зоне указывает на 192.168.1.50. Снаружи из интернета к этому хосту не достучаться, но сервер приложения сам прекрасно видит эту сеть и может к ней обратиться. Злоумышленнику остается только уговорить приложение сходить по нужному адресу.

Если внутренние имена никогда не покидали пределы инфраструктуры, атакующему пришлось бы либо проводить дополнительную разведку после проникновения внутрь, либо гадать через слепой перебор. Публичная запись делает эту работу заранее: достаточно открыть зону, увидеть db-prod.corp.example и попробовать скормить этот URL уязвимому приложению. Более того, некоторые защиты ориентируются на список подозрительных IP, но проверку по имени проходят "чистые" домены без явных признаков принадлежности внутренней сети.

Сертификаты и Certificate Transparency: утечка имен даже без DNS

Иногда на этом месте появляется идея "убрать все внутренние записи из публичного DNS и жить спокойно". К сожалению, мир уже успел придумать еще один источник утечки имен - журналы прозрачности сертификатов. Любой публичный сертификат, выданный доверенным центром, попадает в открытые логи, где сохраняются полные имена хостов. Этими логами пользуются не только защитники, но и злоумышленники, которые собирают информацию о внутренней инфраструктуре.

Если компания для удобства выпускает публичные сертификаты на внутренние хосты с серыми адресами, например через бесплатный центр сертификации, то эти имена гарантированно оказываются в общедоступных журналах. Даже если соответствующих DNS-записей в публичной зоне нет, факт существования git.corp.example или vpn-int.corp.example уже нельзя скрыть. Интернет-сканеры и исследовательские проекты регулярно обходят такие логи и используют их как подсказку.

Как уменьшить утечку имен через сертификаты

Если внутренний ресурс никогда не должен быть доступен снаружи, то разумный вариант - использовать внутреннюю инфраструктуру сертификации. Это может быть собственный центр сертификации, доверенный только внутри компании, или возможность выдавать сертификаты через корпоративную платформу, которая не публикует их в открытые журналы. В этом случае имена не окажутся в глобальных логах, и внешний наблюдатель не узнает о существовании внутренних доменов из цепочки TLS.

Другой подход - использовать подстановочные сертификаты на общий домен и не светить конкретные имена в публичных записях. Это решение не отменяет всех рисков и требует аккуратного обращения, но значительно сокращает количество уникальных внутренних имен, попадающих в открытые источники. Важно только помнить, что простая "чистка" DNS без изменения политики работы с сертификатами дает лишь частичный эффект.

Split DNS и DNS-over-HTTPS: как совместить безопасность и удобство

Рекомендация "разделить публичные и внутренние зоны" считается де-факто стандартом. Внешние пользователи видят одну версию зоны, а внутренние - другую, либо имеется отдельная зона для внутренних имен. Это логично: внутренние адреса не попадают в публичный DNS, а все, что видят снаружи, действительно должно быть доступно из интернета.

На практике внедрение такого подхода упирается в современную реальность: браузеры и операционные системы активно используют DNS-over-HTTPS и могут игнорировать локальные настройки резолвера, обращаясь напрямую к внешним службам. Если внутренний ресурс известен только внутреннему DNS, но браузер решил спросить публичный, то имя просто не разрешится, и с точки зрения пользователя "ничего не работает". Администраторам в такой ситуации приходится искать баланс между безопасностью и удобством.

Практические способы обуздать DoH и сохранить split DNS

Полностью отключить DNS-over-HTTPS во всем мире невозможно, но внутри организации можно выстроить разумные ограничения. Во многих корпоративных средах применяются групповые политики, системные профили или агенты, которые явно задают допустимые резолверы и запрещают прямое обращение к внешним службам. На сетевом уровне можно блокировать трафик к популярным публичным DoH-сервисам и принуждать устройства использовать доверенные внутренние или граничные резолверы.

Еще один подход - построить собственный защищенный DNS-резолвер, который поддерживает современные протоколы шифрования, но при этом знает правила разделения зон. Тогда клиентам не приходится "выбирать между безопасностью и удобством", им достаточно доверять одному источнику имени. При корректной настройке split DNS перестает быть головной болью и становится вполне управляемым инструментом, который помогает не светить внутренние адреса наружу.

Практические рекомендации: как жить с DNS и не бояться

Если отойти от теории и вернуться к повседневной жизни, то картина получается относительно простой. Публикация внутренних IP и имен в публичном DNS не является "моментальной дырой" в сеть, но существенно упрощает жизнь тому, кто захочет использовать DNS Rebinding, SSRF и другие сценарии. Задача инженеров и безопасников - не демонизировать DNS, а аккуратно выстроить несколько базовых правил, чтобы минимизировать лишние утечки.

Хорошей отправной точкой могут стать следующие шаги:

• вывести все внутренние имена и адреса из публичной зоны в отдельную внутреннюю зону или вариант split DNS;
• не выписывать публичные сертификаты на чисто внутренние домены, использовать для них внутренний центр сертификации;
• ограничить функционал внешних веб-сервисов, которые принимают URL от пользователя, и внедрить строгие проверки для защиты от SSRF;
• внедрить фильтрацию DNS для приложений, которым не нужно резолвить внутренние имена, чтобы усложнить Rebinding и SSRF;
• договориться внутри команды о понятной схеме именования сервисов, которая не раскрывает лишней информации о роли и важности узла.

Сама по себе запись с серым адресом в публичном DNS не "взламывает" сеть. Но в сочетании с ошибками в приложениях, слабой конфигурацией браузеров и серверами, которые доверяют любым URL, она превращается в кусок пазла, который очень удобно ложится в картину атаки. Убрав такие куски из публичного поля, вы не сделаете систему абсолютно невзламываемой, но заметно затрудните жизнь тем, кто захочет ее атаковать.

Мифы и реальность вокруг публичного DNS и внутренних адресов

Споры вокруг того, "можно ли светить серые IP в публичном DNS", часто сводятся к наборам мифов. Одни утверждают, что это вообще не проблема, другие - что это почти катастрофа. Истина традиционно где-то между, но с важным уклоном в сторону практических векторов атак, а не абстрактных принципов.

Стоит зафиксировать несколько ключевых противопоставлений.

• "Внешний пользователь не может подключиться, значит угрозы нет." - напрямую, действительно, не может. Но через браузер сотрудника и внешние веб-приложения он может инициировать обращения к внутренним ресурсам, используя DNS Rebinding и SSRF.
• "Это всего лишь разведка." - разведка сама по себе не ломает систему, но делает возможными более сложные клиентские атаки и значительно ускоряет продвижение внутри сети после первичного проникновения.
• "Безопасники нервничают из-за принципов." - в реальности причины вполне приземленные: есть конкретные подтвержденные схемы атак, где знание внутренних имен и адресов прямо повышает шансы на успех.
• "Доступ внутрь автоматически дает доступ к DNS." - нет, это далеко не так. Однако знание имен и диапазонов заранее экономит часы шумного сканирования и делает атаку более точной и малозаметной.

Чем меньше лишних фактов о внутренней инфраструктуре вы добровольно выкладываете в публичное пространство, тем меньше материала для таких "мифов" остается. И наоборот, каждая удобная, но невинная на вид запись о внутреннем сервисе в общедоступном DNS рано или поздно может оказаться строкой в чужом отчете о разведке.

Выводы

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

Главный практический вывод прост: публичный DNS должен описывать только те ресурсы, которые действительно предназначены для внешнего мира. Все, что живет только внутри, должно оставаться внутри - в отдельной зоне, под контролем внутренних резолверов и внутренних сертификатов. Тогда обсуждение безопасности DNS будет меньше напоминать обмен эмоциями и больше походить на спокойный анализ архитектуры, где каждая деталь занимает свое место.