Старый лендинг отключили, но DNS-запись осталась: как заброшенный поддомен может оказаться под контролем чужого проекта
Маркетинговая команда попросила восстановить промо-страницу, которую запускали несколько лет назад. Адрес сохранился в архиве, поэтому его открыли, рассчитывая увидеть старый лендинг или хотя бы страницу с сообщением о завершении акции. Вместо этого загрузился совершенно чужой сайт.
Домен в адресной строке оставался корпоративным, HTTPS работал, сертификат был действительным, а содержимое не имело никакого отношения к компании. Причина оказалась в забытой DNS-записи: старый поддомен всё ещё указывал на внешний сервис, где исходный проект давно удалили.
Такие записи называют висячими, или dangling DNS records. Они появляются, когда ресурс на стороне хостинг-провайдера уничтожают, а соответствующую запись в DNS-зоне не удаляют. Со временем освободившееся имя проекта может зарегистрировать другой человек - и начать обслуживать собственный контент через корпоративный поддомен.
Как формируется проблема
Промо-страницы часто размещают не на основной инфраструктуре компании, а во внешних сервисах: объектных хранилищах, конструкторах сайтов, GitHub Pages, CDN-платформах или временных облачных проектах.
Обычно схема выглядит так:
1. Внешний сервис создаёт проект с уникальным именем.
2. Платформа выдаёт ему технический адрес вроде `company-promo-2023.hosting.example`.
3. В корпоративной DNS-зоне создаётся запись для удобного адреса, например `promo.example.com`.
4. После завершения акции внешний проект удаляется.
5. DNS-запись остаётся без изменений.
Если имя проекта на платформе освобождается, его может занять новый пользователь. Корпоративный поддомен продолжит указывать на тот же технический адрес, но уже на сервер или проект другого владельца.
Особенно опасно то, что посетитель будет видеть привычный корпоративный домен. HTTPS-сертификат также может выпускаться автоматически, поэтому наличие замка в браузере не доказывает, что содержимое контролируется компанией.
Почему обычный мониторинг не обнаруживает висячие записи
Стандартный мониторинг обычно проверяет перечень известных сайтов: главную страницу, личный кабинет, API, несколько критичных поддоменов. Заброшенный промо-адрес в такие списки чаще всего не входит.
Проверка DNS тоже не решает задачу. Наличие ответа от DNS-сервера означает лишь, что имя технически разрешается. Оно не говорит, существует ли проект на стороне хостинга и принадлежит ли он прежнему владельцу.
Многие платформы используют wildcard-записи. Например, DNS может отвечать адресами на любой запрос внутри определённой зоны, даже если соответствующего проекта не существует. В результате для реально работающего проекта и свободного имени система возвращает одинаковый ответ.
Проверять необходимо не только DNS, но и само содержимое. У разных сервисов есть характерные признаки удалённого проекта: сообщения вроде `Site not found`, `NoSuchBucket`, стандартные страницы ошибки или специальные XML-ответы. Если такая реакция совпадает с результатом запроса к заведомо несуществующему имени, запись, вероятно, указывает на освобождённый ресурс.
Чем это опасно
Риск заключается не в том, что кто-то разместит на старом поддомене случайную страницу. Проблема в доверии к корпоративному имени и в настройках безопасности основного домена.
Кража cookie
Если приложение устанавливает cookie для `.example.com`, браузер отправляет их на все поддомены внутри этой зоны. Поэтому пользователь, посетивший захваченный `promo.example.com`, может передать серверу злоумышленника корпоративные cookie.
Флаг `HttpOnly` не всегда спасает: он запрещает чтение cookie через JavaScript, но не мешает браузеру автоматически отправить их в HTTP-запросе. Флаг `Secure` лишь требует использовать HTTPS и также не предотвращает передачу на подконтрольный чужой сервер.
Более безопасный вариант - применять префикс `__Host-`. Такие cookie нельзя привязать к родительскому домену, и они действуют только на конкретном хосте. Однако это может потребовать пересмотра архитектуры единой авторизации между поддоменами.
Фишинг от имени компании
Чужой владелец может разместить на старом поддомене копию страницы входа, форму оплаты или сообщение о новой акции. Пользователь увидит знакомое имя домена и действующий сертификат, поэтому вероятность доверия окажется значительно выше, чем при переходе на похожий внешний адрес.
Репутационные последствия
На заброшенном адресе могут появиться вредоносные материалы, сомнительная реклама, запрещённый контент или страницы с перенаправлением на мошеннические сайты. Для поисковых систем и пользователей это по-прежнему поддомен компании, поэтому претензии, блокировки и жалобы могут затронуть владельца основной зоны.
Утечки внутренних данных
Если старый лендинг когда-то использовал API, служебные токены, интеграции с аналитикой или ссылки на внутренние системы, новый владелец поддомена может попытаться использовать доверие между компонентами. Даже если устаревший сервис уже отключён, связанные ключи, CORS-настройки или правила доступа могли сохраниться.
Важная оговорка о современных хостингах
Некоторые платформы теперь требуют подтвердить владение доменом перед подключением пользовательского поддомена. В таких системах одного совпадения имени проекта недостаточно, и классический сценарий захвата закрыт.
Но это не устраняет риск полностью. В инфраструктуре могут оставаться старые записи, созданные до внедрения проверки, а также сервисы, которые по-прежнему разрешают занять освободившееся имя без подтверждения домена.
Как искать проблему
Аудит следует начинать с полной инвентаризации DNS-зоны. В список нужно включить не только активные сервисы, но и исторические записи, делегирование подзон, CNAME, ALIAS, A-записи, записи для CDN и технических платформ.
Для каждой записи стоит определить:
- кто владеет ресурсом, на который она указывает;
- используется ли этот ресурс сейчас;
- существует ли проект на стороне провайдера;
- можно ли зарегистрировать его имя заново;
- требуется ли подтверждение домена;
- кто отвечает за удаление записи после завершения проекта.
Затем необходимо выполнить HTTP- и HTTPS-проверку всех поддоменов и сравнить ответы с контрольными запросами к заведомо несуществующим именам. Важно анализировать код ответа, заголовки, цепочку перенаправлений, тело страницы, сертификат и сведения о платформе.
Как устранить уязвимость
Если сервис больше не нужен, безопасная последовательность действий выглядит так:
1. Удалить или заблокировать внешний проект.
2. Удалить соответствующую DNS-запись.
3. Проверить, что поддомен больше не разрешается.
4. Убедиться, что старые сертификаты и ключи отозваны или недоступны.
5. Проверить cookie, CORS, OAuth redirect URI и политики доверия.
6. Просмотреть логи за предыдущий период на предмет подозрительных обращений.
Если ресурс ещё нужен, следует заново создать его под контролем компании, включить подтверждение владения доменом и ограничить права доступа. Названия временных проектов лучше генерировать так, чтобы их нельзя было предсказать, а завершение кампании оформлять отдельной процедурой закрытия.
Как не допустить повторения
Для каждого внешнего проекта должен существовать владелец, срок действия и ответственный за удаление DNS-записи. Создание временного поддомена желательно связывать с заявкой или инфраструктурным кодом, чтобы запись не оставалась бесхозной.
Полезно регулярно запускать автоматический аудит:
- перечислять все DNS-записи;
- группировать их по внешним провайдерам;
- проверять доступность целевых проектов;
- обнаруживать стандартные страницы "ресурс не найден";
- выявлять CNAME на несуществующие или свободные имена;
- отправлять уведомления владельцам;
- автоматически удалять просроченные записи после подтверждения.
Отдельно нужно проверять cookie, распространяющиеся на весь домен, и постепенно заменять их на привязанные к конкретному хосту. Также стоит пересмотреть список разрешённых redirect URI, CORS-доменов и доверенных источников контента.
Висячая DNS-запись может выглядеть безобидным следом старой рекламной кампании, но фактически превращается в точку управления частью корпоративного домена. Поэтому удаление временного проекта должно включать не только выключение приложения, но и очистку DNS, сертификатов, токенов, прав доступа и связанных настроек безопасности.