Введение
Сбор разведывательных данных о системе доменных имен (DNS) — это важнейший первый этап фазы разведки в кибербезопасности. DNS действует как телефонная книга интернета, преобразуя понятные человеку доменные имена в IP-адреса. Запрашивая DNS-записи, специалисты по безопасности могут раскрыть массу информации об инфраструктуре цели, включая почтовые серверы, поддомены и конфигурации безопасности.
DNS особенно ценен для разведки, так как он раскрывает взаимосвязи инфраструктуры, а не просто одну конечную точку. Один домен может указать вам на веб-серверы, почтовых провайдеров, токены валидации, псевдонимы, а иногда и на целые забытые среды. Именно поэтому DNS-разведка часто значительно расширяет область оценки безопасности.
В этой лабораторной работе вы научитесь использовать два мощных инструмента командной строки, host и dig, для проведения DNS-разведки. Мы будем использовать намеренно уязвимый домен zonetransfer.me, который был специально создан исследователями безопасности для безопасной практики выполнения DNS-запросов и передачи зон. Вы узнаете, как извлекать базовые IP-записи, сведения о почтовых серверах, текстовые записи и даже попытаетесь выполнить полную передачу зоны, чтобы составить карту всей DNS-инфраструктуры цели.
Запрос базовых IP-записей (A/AAAA)
На этом этапе вы узнаете, как извлекать самые фундаментальные DNS-записи: записи A и AAAA. Запись A сопоставляет доменное имя с IPv4-адресом, а запись AAAA — с IPv6-адресом. Поиск этих IP-адресов важен, так как он точно указывает, где размещен основной веб-сервер цели.
Напоминаем, что домены и хосты — это не одно и то же. Доменное имя — это метка в DNS. IP-адрес — это место, куда в конечном итоге направляется трафик. Разведка часто начинается с перевода между этими двумя представлениями.
Мы начнем с использования команды host, которая является простой утилитой для выполнения DNS-запросов. Убедитесь, что вы находитесь в своей рабочей директории по умолчанию ~/project.
Выполните следующую команду для базового запроса по нашему целевому домену:
host zonetransfer.me
Вы должны увидеть вывод, похожий на этот, отображающий IPv4-адрес и почтовые серверы, связанные с доменом:
zonetransfer.me has address 5.196.105.14
zonetransfer.me mail is handled by 10 alt2.aspmx.l.google.com.
zonetransfer.me mail is handled by 20 aspmx2.googlemail.com.
zonetransfer.me mail is handled by 10 alt1.aspmx.l.google.com.
zonetransfer.me mail is handled by 20 aspmx3.googlemail.com.
zonetransfer.me mail is handled by 0 aspmx.l.google.com.
zonetransfer.me mail is handled by 20 aspmx4.googlemail.com.
zonetransfer.me mail is handled by 20 aspmx5.googlemail.com.
Хотя host отлично подходит для быстрой проверки, команда dig (Domain Information Groper) предоставляет гораздо более подробный вывод и гибкость. Давайте используем dig, чтобы запросить именно запись A. Мы воспользуемся флагом +short, чтобы сделать вывод чистым, отобразив только IP-адрес.
Чтобы сохранить наши разведывательные данные для последующего анализа, мы перенаправим вывод команды dig в текстовый файл с именем a_records.txt. Выполните следующую команду:
dig A zonetransfer.me +short > ~/project/a_records.txt
Вы можете просмотреть содержимое созданного файла с помощью команды cat:
cat ~/project/a_records.txt
Вывод отобразит IPv4-адрес целевого домена. Сохранение результатов — важнейшая привычка при сборе данных, так как она позволяет со временем создать полный профиль вашей цели.
5.196.105.14
Запрос почтовых и текстовых записей (MX, TXT)
На этом этапе мы углубимся в инфраструктуру цели, запрашивая записи Mail Exchange (MX) и Text (TXT).
Записи MX указывают почтовые серверы, ответственные за прием сообщений электронной почты от имени домена. Идентификация этих серверов может показать, каких сторонних почтовых провайдеров использует цель (например, Google Workspace или Microsoft 365) или размещают ли они свою собственную почтовую инфраструктуру.
Записи TXT не менее ценны, так как они часто описывают отношения доверия, например, какие системы имеют право отправлять почту или какие внешние сервисы были верифицированы для домена.
Давайте запросим записи MX для нашего целевого домена с помощью dig:
dig MX zonetransfer.me +short
Вы увидите список почтовых серверов вместе с их приоритетными номерами (меньшие числа означают более высокий приоритет):
20 aspmx5.googlemail.com.
10 alt1.aspmx.l.google.com.
10 alt2.aspmx.l.google.com.
20 aspmx2.googlemail.com.
20 aspmx3.googlemail.com.
0 aspmx.l.google.com.
20 aspmx4.googlemail.com.
Далее мы рассмотрим записи TXT. Администраторы используют записи TXT для добавления произвольного текста в DNS домена. В кибербезопасности записи TXT очень ценны, так как они часто содержат правила Sender Policy Framework (SPF), конфигурации DomainKeys Identified Mail (DKIM) и различные токены верификации сайтов. Они могут раскрыть внутренние диапазоны IP-адресов, авторизованные для отправки электронной почты, или сторонние сервисы, интегрированные с доменом.
Давайте запросим записи TXT и сохраним вывод в файл с именем txt_records.txt в вашей рабочей директории:
dig TXT zonetransfer.me +short > ~/project/txt_records.txt
Просмотрите содержимое файла, чтобы увидеть, какую информацию администраторы оставили в записях TXT:
cat ~/project/txt_records.txt
Вы можете заметить записи, начинающиеся с v=spf1, которые определяют политики отправки электронной почты, или различные строки верификации. Эта информация помогает составить карту отношений доверия, которые целевой домен имеет с другими сервисами.
"google-site-verification=tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04VlMewxA"
Обнаружение поддоменов (CNAME)
На этом этапе вы узнаете о записях Canonical Name (CNAME). Запись CNAME используется для сопоставления псевдонима с истинным или каноническим доменным именем. Например, www.example.com может быть CNAME, указывающим на example.com.
Обнаружение поддоменов — критически важная часть расширения поверхности атаки. Часто организации защищают свой основной веб-сайт, но забывают обновить или защитить старые, забытые поддомены (например, dev.target.com или testing.target.com).
Давайте запросим конкретный поддомен, который, как известно, существует на нашей целевой системе, чтобы увидеть, как ведут себя записи CNAME. Мы запросим testing.zonetransfer.me и сохраним результаты.
Выполните следующую команду, чтобы запросить запись CNAME и сохранить ее в cname_records.txt:
dig CNAME testing.zonetransfer.me +short > ~/project/cname_records.txt
Теперь проверьте только что созданный файл:
cat ~/project/cname_records.txt
Вы должны увидеть вывод вроде www.zonetransfer.me.. Это говорит нам о том, что testing.zonetransfer.me на самом деле является просто псевдонимом, указывающим на другой домен. Обнаружение таких связей может привести исследователя безопасности к выявлению сторонних хостинг-провайдеров или скрытой инфраструктуры, принадлежащей цели.
Попытка передачи зоны DNS
На этом заключительном этапе вы попытаетесь выполнить передачу зоны DNS. Передача зоны (в частности, с использованием типа запроса AXFR) — это механизм, используемый DNS-серверами для репликации баз данных DNS между несколькими серверами.
Передача зон — классический пример того, как легитимная административная функция становится проблемой безопасности при слабом контроле доступа. Сам механизм является нормальным. Ошибка конфигурации заключается в том, что сторонним лицам разрешается запрашивать полные данные.
Если DNS-сервер настроен неправильно, он может позволить любому анонимному пользователю запросить полную копию файла зоны. Это огромная уязвимость безопасности, так как она мгновенно предоставляет злоумышленнику полную карту каждого поддомена, IP-адреса и записи, связанной с доменом, избавляя от необходимости угадывать или перебирать поддомены методом грубой силы.
Чтобы попытаться выполнить передачу зоны, нам сначала нужно узнать авторитетные серверы имен (NS) для домена. Давайте запросим записи NS:
dig NS zonetransfer.me +short
Вы должны увидеть вывод со списком серверов имен, например:
nsztm1.digi.ninja.
nsztm2.digi.ninja.
Теперь, когда у нас есть сервер имен (nsztm1.digi.ninja), мы можем напрямую запросить у него полную передачу зоны, используя тип записи axfr. Синтаксис dig требует указать целевой домен и конкретный сервер имен, который мы опрашиваем (используя символ @).
Выполните следующую команду, чтобы попытаться выполнить передачу зоны и сохранить огромный объем вывода в zone_transfer.txt:
dig axfr zonetransfer.me @nsztm1.digi.ninja > ~/project/zone_transfer.txt
После завершения команды просмотрите первые несколько строк файла с помощью команды head:
head -n 20 ~/project/zone_transfer.txt
Вы увидите полный дамп DNS-записей домена, включая скрытые поддомены, внутренние IP-адреса и различные текстовые заметки, оставленные администраторами. В реальном сценарии обнаружение открытой передачи зоны является критической находкой, которая значительно ускоряет фазу разведки.
Резюме
Поздравляем! Вы успешно завершили лабораторную работу по сбору данных DNS.
В этой лабораторной работе вы узнали, как использовать команды host и dig для проведения пассивной разведки целевого домена. Вы изучили, как извлекать базовые IPv4-адреса (записи A), идентифицировать почтовую инфраструктуру (записи MX) и раскрывать политики безопасности и сторонние интеграции (записи TXT). Вы также научились отслеживать псевдонимы доменов (записи CNAME) для обнаружения скрытых поддоменов. Наконец, вы успешно выполнили передачу зоны DNS (AXFR) на неправильно настроенном сервере имен, продемонстрировав, как одна уязвимость может раскрыть всю топологию внешней сети организации.
Эти навыки составляют основу картографирования внешней сети и необходимы любому специалисту по кибербезопасности, проводящему тестирование на проникновение или оценку уязвимостей.
