- Что такое MDNS?
- Что такое MDNS?
- Многоадресный DNS — Multicast DNS
- СОДЕРЖАНИЕ
- Обзор протокола
- Структура пакета
- Запросы
- Записи о ресурсах
- Игра на доверии. Пентестим Multicast DNS и Service discovery
- Содержание статьи
- Что такое mDNS?
- Что такое DNS-SD?
- Вычисляем устройства
- Немного об ограничениях
- Эксплуатация
- Продолжение доступно только участникам
- Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Что такое MDNS?
Что такое MDNS?
Multicast DNS (mDNS) является способом использования привычных программных интерфейсов DNS в небольших сетях, где нет необходимости в обычном DNS-сервере.
Проще говоря, использование mDNS позволяет клиенту определить IP-адрес хоста без помощи централизованного DNS-сервера.
Машина, ищущая конкретный хост, посылает широковещательный mDNS-запрос. Соответствующий хост отвечает на этот запрос широковещательным ответом, “представляя” себя другим участникам сети. Таким образом все машины в сети обновляют свой mDNS-кэш и получают информацию и о новых хостах/сервисах. Чтобы аннулировать свое “представление” (например, в случае выключения машины) хост должен отправить response-пакет с TTL = 0. По умолчанию mDNS использует зарезервированную зону “.local”. Протокол mDNS используют такие системы обнаружения сервисов как Bonjour (Apple) и Avahi (Linux).
MDNS особенно полезен в развивающейся области беспроводных сетей. Wi-Fi ноутбуки имеют возможность общаться друг с другом напрямую, не прибегая к любой инфраструктуры, таких как маршрутизаторы и интернет-провайдеров. В этих условиях MDNS позволяет соседние компьютеры быстро составить карту соединительных узлов, создавая ad hoc сеть.
. Поддержите сайт, нажмите на кнопку.
Неправильная раскладка: xnj nfrjt ьвты?
Транслитом: chto takoe мднс?
На этой странице Вы узнали про: mdns, mdns протокол, Протокол mdns, что такое mdns, ммднс, protocol mdns, mdns описание.
Многоадресный DNS — Multicast DNS
В компьютерных сетях , в групповой DNS ( MDNS ) протокол ПОСТАНОВЛЯЕТ хостов в IP — адреса в пределах небольших сетей , которые не включают в себя локальный сервер имен . Это служба с нулевой конфигурацией , использующая по существу те же программные интерфейсы, форматы пакетов и рабочую семантику, что и система одноадресных доменных имен (DNS). Хотя Стюарт Чешир разработал mDNS как автономный протокол, он может работать совместно со стандартными DNS-серверами.
Протокол mDNS опубликован как RFC 6762 , использует IP- пакеты многоадресного протокола дейтаграмм пользователя (UDP) и реализуется программными пакетами Apple Bonjour и Avahi с открытым исходным кодом, включенными в большинство дистрибутивов Linux. mDNS также был реализован в Windows 10 , изначально ограничиваясь обнаружением сетевых принтеров, а позже стал также способен разрешать имена хостов.
mDNS может работать вместе с DNS Service Discovery (DNS-SD), сопутствующей сетевой техникой с нулевой конфигурацией, описанной отдельно в RFC 6763 .
СОДЕРЖАНИЕ
Обзор протокола
Когда клиенту mDNS необходимо разрешить имя хоста, он отправляет сообщение с многоадресным IP- запросом, которое просит хост, имеющий это имя, идентифицировать себя. Затем эта целевая машина рассылает многоадресное сообщение, содержащее его IP-адрес. Затем все машины в этой подсети могут использовать эту информацию для обновления своих кешей mDNS. Любой хост может отказаться от своего права на имя, отправив ответный пакет со временем жизни (TTL), равным нулю.
По умолчанию mDNS разрешает только имена хостов, оканчивающиеся на домен верхнего уровня .local . Это может вызвать проблемы, если .local включает хосты, которые не реализуют mDNS, но которые можно найти через обычный одноадресный DNS-сервер. Разрешение таких конфликтов требует изменений конфигурации сети, которых mDNS был разработан, чтобы избежать.
Структура пакета
Сообщение mDNS — это многоадресный UDP-пакет, отправленный с использованием следующей адресации:
Структура полезной нагрузки основана на формате одноадресного пакета DNS , состоящем из двух частей — заголовка и данных.
Заголовок идентичен заголовку одноадресного 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).
Игра на доверии. Пентестим 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 не проходят через роутеры — потому что роутеры уже устройства третьего уровня.
Разберемся на примере. Мой MacBook Pro имеет в системе mDNS имя MehBook.local . Выяснить это можно во вкладке «Общий доступ» (Sharing) системных настроек.
Чтобы вычислить IP макбука, мы можем использовать инструмент DNS-запросов вроде dig :
$ dig @224.0.0.251 -p 5353 +short MehBook.local
10.105.0.203
Обрати внимание, что имя заканчивается на .local — это домен верхнего уровня, зарезервированный специально под mDNS. Если ты видишь подобное имя — то, вероятно, сможешь вычислить айпишник, используя mDNS. Такие доменные имена называются именами локальной связи (link-local names), потому что увидеть их можно только внутри локальной сети.
Имей в виду: некоторые сисадмины некорректно используют местный домен верхнего уровня вместе с одноадресным DNS. Следи за собой, будь осторожен!
Вместо того чтобы посылать запрос DNS-серверу на порт 53, мы используем порт 5353 и специальный адрес 224.0.0.251 — собственно, мультикастомный. Этот конкретный адрес зарезервирован специально для mDNS. Когда на адрес 224.0.0.251 приходит запрос, все устройства сети получают копию этого запроса и могут на него ответить. В нашем примере мой макбук увидел запрос и вернул по нему свой собственный айпишник — 10.105.0.203 .
IP моего макбука динамический, через какое-то время он поменяется — а вот mDNS-имя останется прежним! Так что мы можем взаимодействовать с доменными именами без запуска DNS-сервера. Сам понимаешь, чем это полезно в домашних и небольших офисных сетях.
Что такое DNS-SD?
В примере с mDNS мы выясняли айпишник устройства с уже известным именем. Но что, если ты хочешь связаться с девайсом, имя которого не знаешь, — например, с принтером? Эту проблему как раз и решает протокол обнаружения сервисов (Service Discovery). Он позволяет устройствам заявлять о конкретных сервисах, которые они предлагают, — так, чтобы можно было обнаружить их без централизованной настройки.
Начнем с вычисления принтеров:
$ dig @224.0.0.251 -p 5353 -t ptr +short _printer._tcp.local
Brother\032DCP-L2540DW\032series._printer._tcp.local.
Тут нам помогут те же мультикастомный DNS-адрес и порт, но на сей раз мы запрашиваем PTR-записи и используем специальное доменное имя _printer._tcp.local — оно как раз предназначено для распознавания принтеров. В ответ на этот запрос мой принтер Brother вернул свое локальное доменное имя.
Если ты хочешь запросить устройства с другими сервисами, то стоит свериться с их официальным реестром. Например, там есть любопытная служба RAOP — она же протокол Apple, известный как AirTunes. Давай-ка его вычислим:
Запрос показывает устройство в моей сети, предлагающее сервис RAOP, — это Apple TV под названием «Гостиная» (Living Room). На самом деле в моей сети два Apple TV, но dig выводит только первый полученный ответ. К счастью, есть инструменты и получше. На macOS это команда dns-sd в программном модуле Rendezvous (Bonjour), эппловской реализации Zeroconf.
$ dns-sd -B _raop._tcp
Browsing for _raop._tcp
DATE: —Sun 16 Sep 2018—
10:02:18.236 . STARTING.
Timestamp Domain Service Type Instance Name
10:02:18.237 local. _raop._tcp. D0D2B0XXXXXX@Bedroom
10:02:18.238 local. _raop._tcp. C8D083XXXXXX@Living Room
^C
Эта команда разошлет запрос и отобразит все полученные ответы (чтобы избавиться от них, нужно будет нажать 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
Avahi умеет переводить имена служб типа _raop._tcp.local в более понятные — AirTunes Remote Audio local , например. Также Avahi может вычислить айпишник с помощью mDNS, так что dig здесь вообще не нужен:
Обрати внимание, что при mDNS-запросе мы не вставляем значения типа _raop._tcp — потому что это название службы, а не устройства. Также мы ничего не пишем слева от символа @ .
Вычисляем устройства
Теперь ты видишь, чем пакет Zeroconf интересен пентестерам: благодаря ему можно быстро найти целый список доступных устройств буквально за пару запросов. А Avahi еще и позволяет автоматизировать этот процесс. Например, вполне реально упаковать обнаружение сервисов и пробивание IP через mDNS в один шаг.
$ avahi-browse —resolve _printer._tcp
+ enp4s0 IPv4 Brother DCP-L2540DW series UNIX Printer local
= enp4s0 IPv4 Brother DCP-L2540DW series UNIX Printer local
hostname = [brotherB85F3190.local]
address = [10.105.0.3]
port = [515]
txt = [«UUID=e3248000-XXXX-XXXX-XXXX-XXXXXXXXXXXX»
«TBCP=F» «Transparent=T» «Binary=T» «PaperCustom=T»
«Scan=T» «Fax=F» «Duplex=T» «Copies=T» «Color=F» …]
^C
В результате мы получаем локальное имя хоста, IP-адрес и порт ( tcp/515 — дефолтный порт для Line Printer Daemon). Плюс много информации о возможностях принтера в поле txt .
Использованная здесь команда — отличный способ пересчитать все устройства конкретного типа, однако Avahi способен на большее! Следующая команда вычисляет вообще все типы сервисов сразу.
$ avahi-browse —all
+ IPv6 8FB20F14F5966F78620XXXX iPod Touch Music Library local
+ IPv6 276A1455BC533567B08XXXX iPod Touch Music Library local
+ IPv4 8FB20F14F5966F78620XXXX iPod Touch Music Library local
+ IPv4 276A1455BC533567B08XXXX iPod Touch Music Library local
+ IPv6 8FB20F14F5966F78620XXXX _appletv-v2._tcp local
+ IPv6 276A1455BC533567B08XXXX _appletv-v2._tcp local
+ IPv4 8FB20F14F5966F78620XXXX _appletv-v2._tcp local
+ IPv4 276A1455BC533567B08XXXX _appletv-v2._tcp local
^C
Наконец, Avahi может слушать запросы по протоколам Zeroconf от других устройств, что позволяет вычислять девайсы фоново.
$ avahi-browse -a
+ IPv6 MehBook _companion-link._tcp local
+ IPv6 Bedroom _companion-link._tcp local
+ IPv6 Living Room _companion-link._tcp local
+ IPv4 MehBook _companion-link._tcp local
^C
Обе эти команды можно сочетать с —resolve , чтобы получить информацию об айпишниках и портах каждого девайса. Все устройства сети как на ладони!
И конечно, нельзя не упомянуть, что Nmap поддерживает вычисление устройств Zeroconf с помощью скрипта broadcast-dns-service-discovery.
$ nmap —script=broadcast-dns-service-discovery
Starting Nmap 7.60 ( https://nmap.org ) at 2018-09-18 11:40 EDT
Stats: 0:00:03 elapsed; 0 hosts completed (0 up)
NSE Timing: About 0.00% done
Pre-scan script results:
| broadcast-dns-service-discovery:
| 224.0.0.251
| 80/tcp privet
| txtvers=1
| ty=Brother DCP-L2540DW series [ACD1B8XXXXX]
| note=Brother DCP-L2540DW series
| url=https://www.google.com/cloudprint
| type=printer
| >
| cs=online
| Address=10.105.0.3
…snip…
Этот скрипт не включен в категорию default — его можно найти только в safe .
Немного об ограничениях
- Это работает только внутри локальной сети, так что нужно иметь к ней доступ.
- Большие корпоративные сети обычно сегментированы, поэтому потребуется опорная точка именно внутри интересующего тебя сегмента.
- Есть много важных служб, которые не заявляют о себе через DNS-SD, — такие устройства в большинстве случаев придется вычислять как-то иначе.
- Из-за того, что это широковещательные протоколы, нужно хорошенько подумать — позволяют ли твоя тактика и стратегия их использовать?
Эксплуатация
Окей, вычисление устройств — это прикольно и все такое, но есть ли здесь что поэксплуатировать? Мы нашли связку принтеров и Apple TV — и.
Во-первых, держи в уме, что продукты для домашней и небольшой офисной сети, использующие Zeroconf, с высокой вероятностью имеют неправильные настройки и уязвимости. Один простой пример: если принтер аутентифицируется через LDAP-сервер, а у того стоит дефолтный пароль производителя, ты можешь захватить контроль над сервером, заставить принтер к нему обратиться и таким образом украсть LDAP-аттестат принтера. Этим способом можно довольно быстро угнать доменный аккаунт!
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее