Многоадресный DNS был впервые предложен Биллом Вудкоком и Биллом Мэннингом в IETF в 2000 году и, в конечном итоге, был опубликован как стандарт IETF RFC 6762 Стюартом Чеширом и Марком Крочмалом тринадцать лет спустя. Он использует пакеты многоадресного IP- протокола User Datagram Protocol (UDP) и реализуется программными пакетами Apple Bonjour и Avahi с открытым исходным кодом, включенными в большинство дистрибутивов Linux. Хотя реализация Windows 10 была ограничена обнаружением сетевых принтеров, в последующих выпусках также разрешались имена хостов. mDNS может работать вместе с DNS Service Discovery (DNS-SD), сопутствующей сетевой техникой с нулевой конфигурацией, описанной отдельно в RFC 6763.
СОДЕРЖАНИЕ
Обзор протокола
Когда клиенту mDNS необходимо разрешить имя хоста, он отправляет сообщение с многоадресным IP- запросом, которое просит хост, имеющий это имя, идентифицировать себя. Затем эта целевая машина рассылает многоадресное сообщение, содержащее его IP-адрес. Затем все машины в этой подсети могут использовать эту информацию для обновления своих кешей mDNS. Любой хост может отказаться от своего права на имя, отправив ответный пакет со временем жизни (TTL), равным нулю.
Структура пакета
Заголовок идентичен заголовку одноадресного DNS, как и подразделы в части данных: запросы, ответы, авторитетные серверы имен и дополнительные записи. Количество записей в каждом подразделе соответствует значению соответствующего поля * COUNT в заголовке.
Запросы
Формат передачи для записей в разделе запроса немного отличается от формата одноадресной передачи DNS, добавляя однобитовое поле UNICAST-RESPONSE.
| Поле | Описание | Биты длины |
|---|---|---|
| QNAME | Имя узла, к которому относится запрос | Переменная |
| QTYPE | Тип запроса, т.е. тип RR, который должен быть возвращен в ответах. | 16 |
| UNICAST-ОТВЕТ | Логический флаг, указывающий, желателен ли одноадресный ответ | 1 |
| QCLASS | Код класса, 1 или «IN» для Интернета и IP-сетей. | 15 |
Как и в одноадресной DNS, поле QNAME состоит из серии подполей длины / значения, называемых «метками». Каждая метка представляет одну из разделенных точками подстрок в полном доменном имени (FQDN). Список заканчивается одним нулевым байтом, представляющим «корень» DNS.
Поле UNICAST-RESPONSE используется для минимизации ненужных широковещательных рассылок в сети: если бит установлен, отвечающие ДОЛЖНЫ отправлять направленный одноадресный ответ непосредственно запрашивающему узлу, а не широковещательно рассылать ответ по всей сети.
Поле QCLASS идентично полю одноадресного DNS.
Записи о ресурсах
Все записи в разделах ответов, авторитетных серверов имен и дополнительных записей имеют один и тот же формат и вместе известны как записи ресурсов (RR).
Записи ресурсов в mDNS также имеют несколько измененный общий формат по сравнению с одноадресным DNS:
| Поле | Описание | Биты длины |
|---|---|---|
| RRNAME | Имя узла, к которому относится запись | Переменная |
| RRTYPE | Тип записи ресурса | 16 |
| КЭШ-ПРОМЫВКА | Логический флаг, указывающий, следует ли очищать устаревшие кэшированные записи | 1 |
| RRCLASS | Код класса, 1 или «IN» для Интернета и IP-сетей. | 15 |
| TTL | Интервал времени (в секундах), в течение которого RR должен быть кэширован | 32 |
| ДЛИНА | Целое число, представляющее длину (в октетах) поля RDATA | 16 |
| RDATA | Данные о ресурсах; внутренняя структура зависит от RRTYPE | Переменная |
Бит CACHE-FLUSH используется для указания соседним узлам, что запись должна перезаписывать, а не добавляться к любым существующим кэшированным записям для этих RRNAME и RRTYPE.
Форматы полей RDATA такие же, как и в одноадресном DNS. Тем не менее, обнаружение службы DNS (DNS-SD), наиболее распространенный вариант использования mDNS, предусматривает незначительные изменения некоторых их форматов (особенно записей TXT).
Многоадресный DNS
mDNS может работать вместе с DNS Service Discovery (DNS-SD), сопутствующей сетевой техникой с нулевой конфигурацией, описанной отдельно в RFC 6763. [3]
СОДЕРЖАНИЕ
Обзор протокола [ править ]
Когда клиенту mDNS необходимо разрешить имя хоста, он отправляет сообщение с многоадресным IP- запросом, которое просит хост, имеющий это имя, идентифицировать себя. Затем эта целевая машина рассылает многоадресное сообщение, содержащее ее IP-адрес. Затем все машины в этой подсети могут использовать эту информацию для обновления своих кешей mDNS. Любой хост может отказаться от своего притязания на имя, отправив ответный пакет со временем жизни (TTL), равным нулю.
Структура пакета [ править ]
Заголовок идентичен заголовку одноадресного DNS, как и подразделы в части данных: запросы, ответы, авторитетные серверы имен и дополнительные записи. Количество записей в каждом подразделе соответствует значению соответствующего поля * COUNT в заголовке.
Запросы [ править ]
Формат передачи для записей в разделе запроса немного отличается от формата одноадресного DNS, добавляя однобитовое поле UNICAST-RESPONSE. [1]
| Поле | Описание | Биты длины |
|---|---|---|
| QNAME | Имя узла, к которому относится запрос | Переменная |
| QTYPE | Тип запроса, то есть тип RR, который должен быть возвращен в ответах. | 16 |
| UNICAST-ОТВЕТ | Логический флаг, указывающий, желателен ли одноадресный ответ | 1 |
| QCLASS | Код класса, 1 или «IN» для Интернета и IP-сетей. | 15 |
Как и в одноадресной DNS, поле QNAME состоит из серии подполей длины / значения, называемых «метками». Каждая метка представляет одну из разделенных точками подстрок в полном доменном имени (FQDN). Список заканчивается одним нулевым байтом, представляющим «корень» DNS.
Поле UNICAST-RESPONSE используется для минимизации ненужных широковещательных рассылок в сети: если бит установлен, отвечающие ДОЛЖНЫ отправлять направленный одноадресный ответ непосредственно запрашивающему узлу, а не широковещательно рассылать ответ по всей сети.
Поле QCLASS идентично полю одноадресного DNS.
Записи о ресурсах [ править ]
Все записи в разделах ответов, авторитетных серверов имен и дополнительных записей имеют один и тот же формат и вместе известны как записи ресурсов (RR).
Записи ресурсов в mDNS также имеют несколько измененный общий формат по сравнению с одноадресным DNS:
| Поле | Описание | Биты длины |
|---|---|---|
| RRNAME | Имя узла, к которому относится запись | Переменная |
| RRTYPE | Тип записи ресурса | 16 |
| КЭШ-ПРОМЫВКА | Логический флаг, указывающий, следует ли очищать устаревшие кэшированные записи | 1 |
| RRCLASS | Код класса, 1 или «IN» для Интернета и IP-сетей. | 15 |
| TTL | Интервал времени (в секундах), в течение которого RR должен быть кэширован | 32 |
| ДЛИНА | Целое число, представляющее длину (в октетах) поля RDATA | 16 |
| RDATA | Данные о ресурсах; внутренняя структура зависит от RRTYPE | Переменная |
Бит CACHE-FLUSH используется для указания соседним узлам, что запись должна перезаписывать, а не добавляться к любым существующим кэшированным записям для этих RRNAME и RRTYPE.
Форматы полей RDATA такие же, как и в одноадресном DNS. Тем не менее, обнаружение службы DNS (DNS-SD), наиболее распространенный вариант использования mDNS, предусматривает незначительные изменения некоторых их форматов (особенно записей TXT).
СОДЕРЖАНИЕ
Ранние компьютерные сети были построены на технологиях телекоммуникационных сетей, и, таким образом, протоколы, как правило, делились на две группы: те, которые предназначались для подключения локальных устройств к локальной сети (LAN), и те, которые предназначались в первую очередь для междугородной связи. Последние системы глобальной сети (WAN) имели тенденцию иметь централизованную настройку, когда сетевой администратор вручную назначал адреса и имена. Системы LAN, как правило, обеспечивали большую автоматизацию этих задач, так что новое оборудование можно было добавить в LAN с минимальным вмешательством оператора и администратора.
В сетях Интернет-протокола (IP) база данных системы доменных имен для сети изначально поддерживалась администратором сети вручную. Усилия по автоматизации обслуживания этой базы данных привели к внедрению ряда новых протоколов, обеспечивающих автоматизированные услуги, таких как протокол динамической конфигурации хоста (DHCP).
Выбор адреса
Большинство хостов IPv4 используют локальную адресацию канала только в крайнем случае, когда сервер DHCP недоступен. В противном случае хост IPv4 использует свой назначенный DHCP адрес для всех коммуникаций, глобальных или локальных. Одна из причин заключается в том, что хосты IPv4 не обязаны поддерживать несколько адресов на интерфейс, хотя многие из них это делают. Другой заключается в том, что не каждый хост IPv4 реализует распределенное разрешение имен (например, многоадресный DNS ), поэтому обнаружение автоматически настроенного локального адреса канала другого хоста в сети может быть трудным. Обнаружение назначенного DHCP адреса другого хоста требует либо распределенного разрешения имен, либо одноадресного DNS-сервера с этой информацией; В некоторых сетях есть DNS-серверы, которые автоматически обновляются с помощью назначенных DHCP информации об узле и адресе.
Хосты IPv6 должны поддерживать несколько адресов на интерфейс; более того, каждый хост IPv6 должен настраивать локальный адрес канала, даже если доступны глобальные адреса. Хосты IPv6 могут дополнительно самостоятельно настраивать дополнительные адреса при получении сообщений с объявлением маршрутизатора, что устраняет необходимость в DHCP-сервере.
Обнаружение службы имен
Использование служб NetBIOS или LLMNR в Windows по существу происходит автоматически, поскольку использование стандартных API-интерфейсов DNS-клиента приведет к использованию либо NetBIOS, либо LLMNR в зависимости от того, какое имя разрешается (является ли имя локальным или нет), сеть действующая конфигурация (например, действующие суффиксы DNS) и (в корпоративных сетях) действующие политики (независимо от того, отключены ли LLMNR или NetBIOS), хотя разработчики могут отказаться от использования этих служб для поиска отдельных адресов.
Обнаружение службы
Обнаружение службы NetBIOS
NetBIOS в Windows поддерживает отдельные хосты в сети для рекламы услуг, таких как общие файловые ресурсы и принтеры. Он также поддерживает, например, сетевой принтер, чтобы рекламировать себя как хост, совместно использующий принтер и любые связанные службы, которые он поддерживает. В зависимости от того, как устройство подключено (к сети напрямую или к хосту, который его разделяет) и какие протоколы поддерживаются. Однако клиенты Windows, подключающиеся к нему, могут предпочесть использовать SSDP или WSD с помощью NetBIOS. NetBIOS является одним из поставщиков в Windows, реализующих более общий процесс обнаружения, названный обнаружением функций, который включает встроенных поставщиков для PnP, Registry, NetBIOS, SSDP и WSD, из которых первые два являются только локальными, а последние три поддерживают обнаружение сетевых устройств. Ни один из них не требует настройки для использования в локальной подсети. NetBIOS традиционно поддерживается только в дорогих принтерах для корпоративного использования, хотя некоторые принтеры начального уровня с Wi-Fi или Ethernet поддерживают его изначально, что позволяет использовать принтер без настройки даже в очень старых операционных системах.
WS-Discovery
Обнаружение службы на основе DNS
Типы услуг предоставляются в порядке очереди. Реестр типов служб изначально поддерживался DNS-SD.org, но с тех пор был объединен с реестром IANA для записей DNS SRV.
История
DNS-SD с многоадресной рассылкой
Служба поддержки
UPnP имеет некоторые компоненты протокола, предназначенные для обнаружения служб.
Попытки создать стандартный протокол IETF
AllJoyn
Стандартизация
LLMNR был представлен для официального утверждения в рабочей группе IETF DNSEXT, однако не получил консенсуса и, таким образом, был опубликован как информационный RFC 4795 в январе 2007 года.
После того, как LLMNR не стал стандартом Интернета и с учетом того, что mDNS / DNS-SD используется гораздо шире, чем LLMNR, IETF попросила Apple представить спецификации mDNS / DNS-SD для публикации в качестве информационного RFC.
Проблемы с безопасностью
Основные реализации
Apple Bonjour
MDNSResponder от Apple имеет интерфейсы для C и Java и доступен в BSD, Apple Mac OS X, Linux, других операционных системах на базе POSIX и MS Windows. Загрузки для Windows доступны на веб-сайте Apple.
Авахи
Avahi также реализует библиотеки двоичной совместимости, которые имитируют Bonjour и историческую реализацию mDNS Howl, поэтому программное обеспечение, созданное для использования этих реализаций, также может использовать Avahi через интерфейсы эмуляции.
MS Windows CE 5.0
Microsoft Windows CE 5.0 включает собственную реализацию LLMNR от Microsoft.
Systemd
Link-локальные IPv4-адреса
Ни одна из этих реализаций не решает такие проблемы ядра, как широковещательная передача ARP- ответов или закрытие существующих сетевых подключений.
Игра на доверии. Пентестим Multicast DNS и Service discovery
Содержание статьи
Это перевод статьи Марка Э. Хааса, впервые опубликованной в блоге Hyperion Gray. Перевела Алёна Георгиева.
Что такое mDNS?
Официальные сайты Multicast DNS и DNS Service Discovery способны скорее запутать, чем пролить свет на суть этих технологий. Поэтому — прежде чем погружаться в вопросы безопасности mDNS и DNS-SD — мы обсудим, почему вообще эти протоколы существуют и чем они на самом деле занимаются.
Оба протокола являются частью Zeroconf — пакета технологий, который помогает сетевым устройствам находить друг друга автоматически. Когда ты отправляешь документ на печать, а твой компьютер сам предлагает на выбор ближайшие принтеры, скорее всего, он использует именно Zeroconf. Протоколы связаны с DNS, так что здесь нужно хотя бы на базовом уровне понимать, как устроена система DNS.
Обычно DNS работает «одноадресно» (unicast) — это значит, что каждый запрос отправляется на конкретный IP-адрес. Слово multicast (то есть «многоадресность») в mDNS означает, что запрос веерно рассылается всем девайсам широковещательного домена (broadcast domain). Сам по себе термин «широковещательный домен» означает, грубо говоря, все сообщающиеся устройства второго уровня — например, компьютеры, соединенные сетевыми коммутаторами. Это важный момент, ведь запросы mDNS не проходят через роутеры — потому что роутеры уже устройства третьего уровня.
Чтобы вычислить IP макбука, мы можем использовать инструмент DNS-запросов вроде dig :
Имей в виду: некоторые сисадмины некорректно используют местный домен верхнего уровня вместе с одноадресным DNS. Следи за собой, будь осторожен!
IP моего макбука динамический, через какое-то время он поменяется — а вот mDNS-имя останется прежним! Так что мы можем взаимодействовать с доменными именами без запуска DNS-сервера. Сам понимаешь, чем это полезно в домашних и небольших офисных сетях.
Что такое DNS-SD?
В примере с mDNS мы выясняли айпишник устройства с уже известным именем. Но что, если ты хочешь связаться с девайсом, имя которого не знаешь, — например, с принтером? Эту проблему как раз и решает протокол обнаружения сервисов (Service Discovery). Он позволяет устройствам заявлять о конкретных сервисах, которые они предлагают, — так, чтобы можно было обнаружить их без централизованной настройки.
Начнем с вычисления принтеров:
Тут нам помогут те же мультикастомный DNS-адрес и порт, но на сей раз мы запрашиваем PTR-записи и используем специальное доменное имя _printer._tcp.local — оно как раз предназначено для распознавания принтеров. В ответ на этот запрос мой принтер Brother вернул свое локальное доменное имя.
Если ты хочешь запросить устройства с другими сервисами, то стоит свериться с их официальным реестром. Например, там есть любопытная служба RAOP — она же протокол Apple, известный как AirTunes. Давай-ка его вычислим:
Запрос показывает устройство в моей сети, предлагающее сервис RAOP, — это Apple TV под названием «Гостиная» (Living Room). На самом деле в моей сети два Apple TV, но dig выводит только первый полученный ответ. К счастью, есть инструменты и получше. На macOS это команда dns-sd в программном модуле Rendezvous (Bonjour), эппловской реализации Zeroconf.
Эта команда разошлет запрос и отобразит все полученные ответы (чтобы избавиться от них, нужно будет нажать Ctrl-C). Теперь мы видим оба моих Apple TV.
На Linux тот же набор инструментов предлагает пакет Avahi (на Debian/Ubuntu он называется avahi-utils ).
$ avahi-browse _raop._tcp
+ IPv6 D0D2B0XXXXXX@Bedroom AirTunes Remote Audio local
+ IPv6 C8D083XXXXXX@Living Room AirTunes Remote Audio local
+ IPv4 D0D2B0XXXXXX@Bedroom AirTunes Remote Audio local
+ IPv4 C8D083XXXXXX@Living Room AirTunes Remote Audio local
^C
Вычисляем устройства
Теперь ты видишь, чем пакет Zeroconf интересен пентестерам: благодаря ему можно быстро найти целый список доступных устройств буквально за пару запросов. А Avahi еще и позволяет автоматизировать этот процесс. Например, вполне реально упаковать обнаружение сервисов и пробивание IP через mDNS в один шаг.
Использованная здесь команда — отличный способ пересчитать все устройства конкретного типа, однако Avahi способен на большее! Следующая команда вычисляет вообще все типы сервисов сразу.
Наконец, Avahi может слушать запросы по протоколам Zeroconf от других устройств, что позволяет вычислять девайсы фоново.
И конечно, нельзя не упомянуть, что Nmap поддерживает вычисление устройств Zeroconf с помощью скрипта broadcast-dns-service-discovery.
Немного об ограничениях
Эксплуатация
Окей, вычисление устройств — это прикольно и все такое, но есть ли здесь что поэксплуатировать? Мы нашли связку принтеров и Apple TV — и.
Во-первых, держи в уме, что продукты для домашней и небольшой офисной сети, использующие Zeroconf, с высокой вероятностью имеют неправильные настройки и уязвимости. Один простой пример: если принтер аутентифицируется через LDAP-сервер, а у того стоит дефолтный пароль производителя, ты можешь захватить контроль над сервером, заставить принтер к нему обратиться и таким образом украсть LDAP-аттестат принтера. Этим способом можно довольно быстро угнать доменный аккаунт!
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
