OSINT по инфраструктуре своего домена: DNS, TLS-сертификаты и Certificate Transparency

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

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

Аудит DNS-записей​

Первый шаг — инвентаризация всех DNS-записей домена. Каждая запись расширяет поверхность атаки: забытый CNAME на удалённый сервис, устаревшая MX-запись или TXT-запись с раскрытым SPF-политикой — всё это потенциальные векторы.

Основные типы записей для проверки​

Тип	Что проверяем	Риски
A / AAAA	IP-адреса, на которые указывает домен	Указание на чужой IP после смены хостинга
CNAME	Алиасы на другие домены	Dangling CNAME — захват удалённого целевого домена
MX	Почтовые серверы	Перехват почты через подмену MX
TXT	SPF, DKIM, DMARC, verification-токены	Раскрытие внутренних сервисов, ослабление почтовой защиты
NS	Делегирование зоны	Подмена NS-серверов при компрометации регистратора
SOA	Параметры зоны	Утечка внутреннего имени хоста

Практические команды​

Получить все записи зоны (если сервер поддерживает AXFR, что редко для публичных зон):

dig example.com ANY +noall +answer

На практике ANY часто фильтруется серверами. Надёжнее запрашивать каждый тип отдельно:

dig example.com A +short
dig example.com AAAA +short
dig example.com CNAME +short
dig example.com MX +short
dig example.com TXT +short
dig example.com NS +short
dig example.com SOA +short

Для перечисления поддоменов без доступа к зоне используются техники пассивного сбора: запросы к CT-логам (см. ниже), перебор по словарю, поиск в архивах. Для собственного домена достаточно выгрузить зону из панели управления DNS-провайдером.

DNSSEC​

DNSSEC добавляет криптографические подписи к DNS-записям, предотвращая подмену ответов при атаках типа cache poisoning. Проверить, подписана ли зона:

dig example.com DNSKEY +dnssec +short
dig example.com DS +short

Если DNSKEY-записи отсутствуют, зона не подписана. Для доменов, обрабатывающих чувствительный трафик, включение DNSSEC у регистратора и DNS-провайдера — рекомендуемая мера.

Certificate Transparency: механика и запросы​

Certificate Transparency (CT) — экосистема, которая делает выпуск TLS-сертификатов публичным и верифицируемым. Каждый сертификат, выпущенный публичным CA, записывается в один или несколько append-only логов, построенных на Merkle-деревьях. Логи публично доступны, и любой может проверить, какие сертификаты были выпущены для конкретного домена.

Почему это важно для владельца домена​

• Обнаружение несанкционированных сертификатов. Если CA выпустил сертификат для вашего домена без вашего запроса, это видно в CT-логах.
  
• Инвентаризация. Крупные организации часто теряют учёт сертификатов. CT-поиск показывает полную картину.
  
• Обнаружение поддоменов. Сертификаты выпускаются на конкретные имена, включая поддомены, которые могут быть не задокументированы.
  

Как искать сертификаты​

Наиболее доступный интерфейс — crt.sh, который агрегирует данные из нескольких CT-логов:

https://crt.sh/?q=example.com

Для поиска по всем поддоменам используется wildcard:

https://crt.sh/?q=%25.example.com

Результат содержит: серийный номер сертификата, CN, SAN (Subject Alternative Names), дату выпуска, CA, срок действия.

Программный доступ​

CT-логи предоставляют HTTP API. Каждый лог реализует стандартные endpoint'ы, описанные в RFC 6962. Для автоматизации мониторинга можно использовать:

• ctmonitor и аналогичные инструменты, которые периодически опрашивают логи по заданным доменам.
  
• Собственные скрипты, обращающиеся к API логов. Формат запроса и ответа стандартизирован, но конкретные URL логов меняются — актуальный список публикуется на сайте проекта Certificate Transparency.
  

Что искать в результатах​

При анализе CT-выдачи обращайте внимание на:

1. Неизвестные CA. Если сертификат выпущен центром, который вы не используете, это повод для расследования.
   
2. Неожиданные SAN. Сертификат на example.com с дополнительным SAN internal.example.com может указывать на утечку внутреннего имени.
   
3. Короткий срок действия. Сертификаты с аномально коротким TTL иногда используются в автоматизированных атаках.
   
4. Дубликаты. Несколько сертификатов на одно имя, выпущенных в короткий промежуток, могут означать компрометацию приватного ключа.
   

RDAP: данные регистрации домена​

RDAP (Registration Data Access Protocol) — стандартизированная замена WHOIS, разработанная в IETF. В отличие от WHOIS, RDAP возвращает данные в структурированном JSON-формате, поддерживает интернационализацию и безопасный доступ.

С января 2025 года все реестры и регистраторы gTLD обязаны предоставлять RDAP-сервисы, при этом требование предоставлять WHOIS снято (за исключением зон .com, .name и .post).

Запрос через RDAP​

Базовый запрос к RDAP для получения данных о домене:

curl -s https://rdap.org/domain/example.com | jq .

rdap.org выполняет перенаправление на авторитативный RDAP-сервер для запрошенной зоны. Ответ содержит:

• Статусы домена (active, locked, и т. д.)
  
• Даты регистрации, обновления, истечения
  
• NS-серверы
  
• Контакты регистранта (если не скрыты privacy-сервисом)
  
• Связанные сущности (регистратор, реселлер)
  

Что проверяем​

• Статусы домена. Наличие clientTransferProhibited и serverTransferProhibited защищает от несанкционированного трансфера.
  
• Дата истечения. Просроченный домен может быть перехвачен.
  
• NS-серверы. Сверьте с ожидаемыми. Подмена NS — первый шаг к перехвату трафика.
  
• Контакты. Убедитесь, что административный контакт актуален и доступен.
  

TLS-конфигурация активных сервисов​

Помимо CT-логов, стоит проверить сертификаты, которые реально обслуживают ваши сервисы прямо сейчас:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Эта команда показывает:

• Subject и Issuer активного сертификата
  
• Даты начала и окончания действия
  
• Список SAN
  

Для сервисов на нестандартных портах замените 443 на нужный порт. Если домен обслуживает несколько IP (например, через CDN), проверьте каждый адрес отдельно, добавив -connect IP:443.

Типичные проблемы​

Проблема	Признак	Действие
Самоподписанный сертификат	Issuer = Subject	Заменить на сертификат доверенного CA
Просроченный сертификат	notAfter в прошлом	Немедленно обновить
Цепочка не полная	Промежуточный CA отсутствует	Добавить intermediate-сертификат в конфигурацию сервера
Несоответствие SAN	Имя хоста не входит в SAN	Перевыпустить сертификат с корректными SAN

Мониторинг и автоматизация​

Разовый аудит полезен, но инфраструктура меняется. Для непрерывного контроля:

1. CT-мониторинг. Настройте подписку на уведомления о новых сертификатах для ваших доменов. Некоторые CA и сервисы предоставляют такую функцию нативно.
   
2. Проверка DNS-записей. Периодический скрипт, который сравнивает текущие записи с эталонным состоянием и алертит при расхождениях.
   
3. Контроль сроков. Автоматические напоминания за 30 и 7 дней до истечения сертификатов и регистрации домена.
   
4. RDAP-проверка. Ежеквартальная сверка статусов домена и NS-серверов.
   

Чек-лист аудита​

• [ ] Выгружены и сверены все DNS-записи (A, AAAA, CNAME, MX, TXT, NS, SOA)
  
• [ ] Проверено отсутствие dangling CNAME на удалённые сервисы
  
• [ ] DNSSEC включён и корректно настроен (или принято осознанное решение не включать)
  
• [ ] CT-логи проверены на наличие неизвестных сертификатов для домена и поддоменов
  
• [ ] Активные TLS-сертификаты проверены на срок действия, полноту цепочки и корректность SAN
  
• [ ] RDAP-запрос выполнен: статусы домена, NS-серверы и контакты сверены
  
• [ ] Настроен мониторинг новых сертификатов в CT-логах
  
• [ ] Настроены алерты на истечение сертификатов и регистрации домена
  

Источники​

• Cloudflare DNS · Cloudflare DNS docs
  
• Certificate Transparency : Certificate Transparency
  
• Registration Data Access Protocol (RDAP)
  
• Resources - bellingcat