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

MAATRIX

Где-то на promo2022.example.com до сих пор крутится лендинг на движке, который никто не обновлял три года, а на blog-old.example.com — корпоративный блог, о котором в компании помнят два человека, и оба уже не отвечают за инфраструктуру. Основной сайт защищён, обновляется, стоит за WAF — а этот забытый поддомен никто не трогал с момента запуска. Именно такие поддомены чаще всего становятся точкой входа: их не патчат, не мониторят и не вспоминают до тех пор, пока кто-то посторонний не находит их первым. Разберём, как искать все свои поддомены и что делать с теми, что найдутся.

Почему забытый поддомен со старой CMS — лёгкая цель

Проблема не в конкретной уязвимости, а в том, что такой поддомен выпадает из всех обычных процессов сразу: не входит в план обновлений, не в списке мониторинга, у него нет владельца — человек, который его разворачивал, давно сменил роль или уволился. Три года без обновлений для CMS — риск не абстрактный: за такой срок у любого популярного движка накапливается достаточно исправленных с тех пор проблем в ядре, плагинах и зависимостях, чтобы автоматизированный сканер нашёл рабочий вектор без всякой точечной охоты именно за вами.

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

Третий фактор — унаследованное доверие. Поддомен физически отдельный проект, но для пользователя и части систем безопасности он часть того же example.com: тот же TLD, часто валидный TLS-сертификат, иногда общий SPF или CSP «на весь домен». Скомпрометированный поддомен наследует это доверие и может использоваться для фишинга, кражи cookie основного домена или атаки на посетителей — при этом основной сайт технически ни в чём не виноват.

Такие поддомены появляются предсказуемо: лендинг под рекламную кампанию, свёрнутую после квартала; тестовый стенд, поднятый разработчиком «на минутку» и оставшийся жить; корпоративный блог на старом движке, мигрировавший на новую платформу без сноса старой копии; поддомен подрядчика, который давно не ведёт проект; вторая языковая версия сайта, забытая после ухода локального менеджера. Общий признак один — поддомен создали разово под задачу, задача закрылась, а поддомен остался жить своей жизнью.

Как атакующие находят такие поддомены раньше вас

Ирония в том, что методы обнаружения у атакующих и у вас должны быть одинаковыми — просто атакующие применяют их системно и по расписанию, а владельцы доменов часто не применяют вообще. Основные источники:

Certificate Transparency логи. Любой публичный TLS-сертификат почти наверняка попал в CT-логи — это открытая, постоянно пополняемая база данных обо всех выданных сертификатах, доступная для поиска по домену:

curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' | sort -u

Такой запрос отдаёт список всех имён, для которых когда-либо выпускался сертификат на *.example.com, включая давно забытые поддомены — даже те, что сейчас не резолвятся в DNS. Сертификат, выпущенный три года назад для promo2022.example.com, остаётся в логе навсегда, независимо от того, жив сайт сегодня или нет.

Массовый перебор поддоменов по словарю. Инструменты для пассивной и активной разведки поддоменов (класс задач, который решают утилиты вроде subfinder или amass) прогоняют типичные имена — old, test, dev, blog, staging, promo, beta — против DNS вашего домена и молниеносно находят то, что легко угадывается по шаблону.

Поисковая индексация и Wayback Machine. Оператор site:example.com иногда показывает страницы поддоменов, которые давно не поддерживаются, но всё ещё проиндексированы. Архив Wayback Machine хранит снимки старых версий сайтов вместе с URL и восстанавливает список поддоменов, существовавших годы назад, даже если упоминаний о них сейчас нигде не осталось.

Публичные упоминания и сканеры отпечатков движков. Старые пресс-релизы, посты про закрытую рекламную кампанию, скриншоты в портфолио подрядчика могут назвать точный адрес поддомена, о котором в компании уже никто не помнит. А специализированные поисковые системы по интернету (класс сервисов вроде Shodan или Censys) группируют хосты по характерным признакам конкретной CMS или её версии — это позволяет искать не «поддомены example.com», а сразу «сайты на устаревшей версии такого-то движка».

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

Инвентаризация: как найти все свои поддомены

Прежде чем что-то чинить или сносить, нужен полный список — не «то, что помнят в команде», а всё, что реально существует. Комбинируйте несколько источников, ни один по отдельности не даёт полной картины.

1. Выгрузка DNS-зоны целиком. Если DNS у хостинг-провайдера или регистратора — экспортируйте зону через панель или API. Если управляете DNS сами:

# PowerDNS через API
curl -s -H "X-API-Key: $API_KEY" \
  http://127.0.0.1:8081/api/v1/servers/localhost/zones/example.com. \
  | jq -r '.rrsets[].name'

# BIND — просто просмотреть файл зоны
grep -E "^\S+\s+IN\s+(A|AAAA|CNAME)" /etc/bind/zones/db.example.com

2. Запрос по CT-логам — тем же способом, что и у атакующего (см. выше), плюс сверка альтернативных сервисов на случай, если один из логов что-то пропустил. Подробнее о работе с этими логами и о том, как отличать легитимные записи от подозрительных, — в статье «Кто-то выпустил сертификат на ваш домен: как это увидеть».

3. Список сертификатов на своих серверах. Если для нескольких проектов используется общий пул серверов с Let's Encrypt:

certbot certificates

Список покажет все домены, на которые когда-либо выпускались и продлевались сертификаты именно с этой машины, — иногда там всплывают имена, забытые владельцем, но не забытые certbot.

4. Панели облачных провайдеров и хостинга. Пройдитесь по консоли каждого провайдера, где у компании есть аккаунт: список доменов и сертификатов в панели хостинга, список сайтов в консоли CDN, список проектов в аккаунте PaaS. Забытый поддомен нередко существует именно там, а не только в DNS.

5. Конфигурации веб-серверов на старых машинах. Если остался доступ к старым VPS, давно не в фокусе внимания:

grep -r "server_name" /etc/nginx/sites-enabled/ /etc/nginx/sites-available/

Виртуальные хосты, о которых никто не помнит, часто всплывают именно так — конфиг остался, хотя проект давно «закрыт».

6. Старая документация, переписка и аккаунт регистратора. Задачи в трекере, вики-страницы, счета от подрядчиков, поиск по почте за прошлые годы по слову «поддомен» — источник неформальный, но регулярно даёт находки, которых нет ни в одной технической системе. Отдельно проверьте у регистратора список всех доменов и NS-делегирований части зоны другому провайдеру — делегированная поддоменная зона может вообще не отражаться в основном DNS-экспорте.

Результат сведите в один список и сверьте с тем, что реально должно существовать. Всё, что не находит объяснения ни у кого в команде, — кандидат на разбор в первую очередь.

Найденный поддомен: обновить и оставить, или снести

Для каждого найденного поддомена ответьте на три вопроса: используется ли он реально сейчас, кто за него отвечает, и насколько отстала версия CMS от текущей поддерживаемой ветки. По итогам — два пути, третьего по сути нет: либо поддомен нужен и его приводят в порядок, либо не нужен и его сносят полностью. «Оставить как есть, но не трогать» — не вариант, потому что именно это состояние и стало проблемой.

Если поддомен нужен — приводите его в тот же режим обслуживания, что и основной сайт:

• обновите CMS до актуальной поддерживаемой версии; при большом разрыве в мажорных версиях закладывайте на это поэтапную миграцию, а не один клик;
• перенесите поддомен на изолированный сервер или контейнер, если он живёт на общей машине с продакшн-проектами — компрометация не должна давать доступ к соседям;
• закройте админ-панель по IP-списку или за VPN, если публичный доступ к ней не обязателен;
• включите поддомен в тот же цикл регулярных обновлений, что и остальную инфраструктуру, а не «на отдельный учёт, который никто не ведёт»;
• добавьте домен в мониторинг доступности, сертификатов и CT-логов — принцип разобран в статье «Мониторинг сертификатов и доменов».

Если этого не сделать, результат предсказуем: забытая, но формально «живая» интеграция становится точкой входа — так же, как в разобранном нами реальном инциденте, где вход был через плагин, которым не пользовались два года.

Если поддомен не нужен — сносите его целиком, а не просто «отключайте сайт, а домен пусть повисит». Что именно это значит — в следующем разделе.

Полный снос: чек-лист, чтобы не оставить хвостов

Выключить сервер, но забыть про DNS-запись, — типичная ошибка, которая превращает «мы всё убрали» в новую уязвимость. Порядок действий:

1. Заберите нужные данные перед остановкой — формы с обращениями клиентов или контент, который может понадобиться для истории или юридических целей, выгрузите до удаления, а не после.
2. Удалите DNS-запись полностью, а не просто остановите сайт на сервере. Если запись указывала на внешний сервис (CNAME на конструктор лендингов, PaaS, объектное хранилище), оставленная запись — прямой риск захвата поддомена. Механика этой атаки подробно разобрана в статье «Поддомен угнали через забытую запись DNS».
3. Не продлевайте TLS-сертификат для этого имени — пусть истекает своим ходом. Историческая запись о нём навсегда останется в CT-логах, и это нормально: риск не в самом факте наличия старого сертификата, а в том, если DNS-запись всё ещё на что-то указывает.
4. Снесите инфраструктуру целиком: удалите VPS или контейнер, отзовите привязанные к нему SSH-ключи, уберите проект из консоли облачного провайдера.
5. Вычистите зависимости: строку server_name из конфига nginx, связанное задание в cron, деплой-таргет из CI/CD, если поддомен когда-то разворачивался автоматически.
6. Зафиксируйте факт сноса в реестре поддоменов (дата, кто убрал, почему) — чтобы через год это читалось как осознанное решение, а не забытый хвост.
7. Проверьте через несколько недель, что имя не резолвится и не появилось попыток переиспользовать идентификатор — особенно если он указывал на внешний PaaS или хранилище.

Регулярная инвентаризация активов домена как процесс

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

Заведите реестр. Простая таблица «поддомен → назначение → ответственный → дата создания → статус (активен / на обслуживании / подлежит сносу)» превращает вопрос «а что это такое и можно ли снести» из археологии в справочную операцию. Реестр обновляется в двух точках: при создании поддомена и при отказе от сервиса — это часть одного чек-листа, а не отдельные задачи, которые легко потерять.

Назначьте периодичность. Для домена с редкими изменениями достаточно ревизии раз в квартал; если маркетинг и разработка регулярно поднимают тестовые и кампейн-поддомены — раз в месяц. Смысл не в частоте самой по себе, а в том, чтобы окно между появлением забытого поддомена и его обнаружением было предсказуемо коротким.

Автоматизируйте сверку. Скрипт, который раз в неделю прогоняет запрос к CT-логам и сравнивает результат с предыдущим прогоном, снимает зависимость процесса от того, вспомнил ли кто-то запустить его вручную:

#!/usr/bin/env bash
# subdomain-diff.sh — сравнить текущий список поддоменов с прошлым прогоном
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' | sort -u > subdomains-now.txt

if [ -f subdomains-prev.txt ]; then
  diff subdomains-prev.txt subdomains-now.txt \
    && echo "Изменений нет" \
    || echo "Обнаружены новые/изменённые поддомены — см. вывод diff выше"
fi

cp subdomains-now.txt subdomains-prev.txt

Встройте в общий процесс аудита. Если в компании уже есть регулярное ревью доступов и конфигураций, ревизия поддоменов логично встаёт туда же отдельным пунктом — подход к подготовке такой проверки описан в статье «Как подготовить сервер к аудиту безопасности».

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

Частые вопросы