Многоадресный фоновый трафик IPv6 (часть 4) — Box Chatter — P2P Multicast и войны с нулевой конфигурацией

Введение

Как мы видели в последних двух статьях, в современных локальных сетях существует стабильная струйка многоадресного фонового трафика, связанного с автоматической настройкой стека IPv6. Что меня удивило, когда я начал изучать трафик IPv6 в различных локальных сетях, так это количество передаваемых пакетов, которые, казалось бы, не имели ничего общего с операционной системой Windows или сетевым оборудованием (Cisco). Вместо этого был широкий спектр прерывистого, странного IPv6-трафика на необычные многоадресные адреса, о которых я начал думать как о случайной «болтовне ящиков».

Оказалось, что вся эта болтовня о коробках была связана с так называемой сетью с нулевой конфигурацией. Различные устройства, приложения и службы, от принтеров и смартфонов до Windows Media Center и iTunes, были вовлечены в непрерывный низкоуровневый подпольный обмен нежелательными сообщениями автоконфигурации по IP. Оставшаяся часть этой серии блогов посвящена рассмотрению этого трафика.

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

Назад в будущее

Идея включения вычислительных устройств, их самостоятельной настройки и объявления о своем присутствии в сети — привлекательная идея с долгой родословной. В 1980-х, например, протокол AppleTalk позволял нетехническим людям устанавливать компьютеры Mac и принтеры в сети без необходимости в гуру или централизованных серверах.

В самом широком смысле проблема заключается в том, как добавить устройства и службы в существующую систему? На уровне физического устройства постепенно появились различные разновидности USB и Plug-n-Play как решения проблемы добавления периферийных устройств к существующей машине. Службы, с другой стороны, как правило, располагаются выше в стеке, на уровне программных приложений, и на протяжении многих лет предпринимались многочисленные попытки стандартизировать их предоставление, в основном зависящее от поставщика. DHCP и DNS являются примерами услуг, которые были успешно стандартизированы и в значительной степени не зависят от поставщика.

Термин «сеть с нулевой конфигурацией», который я в дальнейшем буду называть нулевой конфигурацией, постепенно прижился. В корне нулевая конфигурация — это способ реализации Plug-n-Play по сети с использованием IP. В интересах полного раскрытия информации я должен отметить, что то, что первоначально было общим термином «нулевая конфигурация», теперь имеет тенденцию относиться к конкретной структуре Bonjour, продвигаемой Apple. У Microsoft есть конкурирующая платформа, известная как Windows Rally. Веб-сайт, управляемый «волшебником без портфолио» Apple Стюартом Чеширом, продвигает свое видение того, какой должна быть нулевая конфигурация, в основном за счет Microsoft. Хотя я постараюсь быть нейтральным в своей презентации, я нахожу структуру Чешира ясным и полезным способом осмысления нулевой конфигурации.

Три ноги нулевой конфигурации

По сути, технологии нулевой конфигурации пытаются решить три разные проблемы:

1. автоматическое назначение IP-адреса
2. наименование устройства или службы
3. обнаружение службы

Самоназначение адреса IPv6 link-local fe80 (и IPv4 169.254) эффективно решает проблему автоматического IP-адреса, и это решение в значительной степени является общим для Apple и Microsoft. Оттуда два отраслевых гиганта радикально расходятся. Apple решила использовать многоадресную форму DNS для решения обеих оставшихся проблем: именования и обнаружения служб. Microsoft, с другой стороны, создала новые протоколы: LLMNR для разрешения имен и SSDP/WS-Discovery для перечисления сервисов.

Чтобы было ясно, были и другие фреймворки с нулевой конфигурацией. В 1990-х, когда Java от Sun был в расцвете, протокол Jini обещал создать универсальный «сетевой тональный сигнал». К сожалению, как это часто бывало с Sun, Jini была гениальной идеей, из которой Sun не смогла извлечь выгоду. На сегодняшний день существует несколько подходов к нулевой конфигурации, некоторые общедоступные, а другие проприетарные, но общепринятой основы не существует. Однако на практике технологии Rally от Microsoft (UPnP и DPWS) и Bonjour от Apple являются наиболее распространенными платформами с нулевой конфигурацией, и именно на этих двух мы сосредоточимся.

Вот вид с высоты 30 000 футов:

Таблица 1

Rally Technologies от Microsoft: больше акронимов, чем вы можете встряхнуть палкой

Rally — это попытка Microsoft объединить под одной крышей свой разнообразный набор средств автоматической настройки устройств и обнаружения служб. Помимо Universal Plug and Play (UPnP), еще один набор технологий домашних сетей объединился в форме отраслевого консорциума Digital Living Network Alliance (DLNA) под руководством Sony. На уровне предприятия предпочтительны профили устройств для веб-служб (DPWS). UPnP и DLNA используют простой протокол обнаружения служб (SSDP), в то время как DPWS использует расширяемый протокол WS-Discovery. Есть дополнительные протоколы и технологии: Link-Layer Topology Discovery (LLTD), Windows Connect Now (WCN), Plug and Play Extensions (PnP-X) и мало ли что еще.

Следует упомянуть DLNA, потому что в нем участвуют практически все крупнейшие в мире компании по производству бытовой электроники. Несмотря на то, что DLNA кажется далекой от традиционных ИТ, DLNA приходится решать многие из тех же задач автоматической настройки сети и обнаружения сервисов, что и корпоративным технологам. Конечно, есть различия — корпоративные магазины, как правило, не заинтересованы в предотвращении подключения устройств из-за несоответствия управления цифровыми правами (DRM), — но, как это часто бывает в истории ИТ, изменения в потребительском пространстве имеют последствия для корпоративного ИТ-пространства..

Я не буду пытаться разобраться в этом для вас — даже у Microsoft, похоже, есть проблемы с отслеживанием. Большая часть обещаний этих технологий еще не реализована (см., например, эту статью CNET о DLNA). Но поскольку наше внимание здесь сосредоточено на многоадресной рассылке IPv6, давайте упростим ситуацию и рассмотрим три типа пакетов с нулевой конфигурацией, которые вы обычно видите в современных локальных сетях Windows 7: LLMNR, SSDP и WS-Discovery. Первый — это протокол разрешения имен, а два последних — протоколы обнаружения, т. е. они участвуют в объявлении или обнаружении устройств и служб в локальной сети без необходимости использования центрального сервера каталогов.

LLMNR

Link-Local Multicast Name Resolution (LLMNR) — это эквивалент Microsoft для разрешения имен в многоадресной рассылке mDNS от Apple. LLMNR в значительной степени используется только Microsoft и никогда не становился стандартом IETF, хотя имеется информационный RFC. mDNS все еще находится на пути к стандартизации IETF, но еще не завершен. Обе технологии предлагают решения проблемы поиска имен машин в отсутствие (или параллельно с) централизованного DNS-сервера.

В отличие от mDNS, который в значительной степени расширяет существующий протокол DNS, LLMNR является совершенно новым протоколом. Он работает через многоадресную рассылку, в случае IPv4 на 224.0.0.252 и с IPv6 на ff02::1:3. Вот типичный пакет LLMNR, попытка ПК найти сервер автоматического обнаружения веб-прокси (WPAD):

фигура 1

Многоадресная рассылка IPv6 — это последнее воплощение давнего подхода к поиску имен без сервера. Например, обратите внимание, что один и тот же ПК не только выдавал многоадресные запросы LLMNR как IPv4, так и IPv6, но также использовал древний протокол NetBIOS, форму разрешения локальных имен до DNS эпохи 1980-х годов для локальных локальных сетей:

фигура 2

Приведенный выше запрос LLMNR предназначен для записи типа A (адрес IPv4). Другой запрос LLMNR, который вы иногда будете встречать, ff02::1:3 предназначен для записи типа = ANY. Они встречаются реже, и мне не удалось найти никакой документации, объясняющей их назначение, но я подозреваю, что эти запросы типа LLMNR type=ANY выполняются, когда компьютер загружается и пытается установить, что его имя уникально:

Рисунок 3

LLMNR работает как по TCP, так и по UDP:

C:WindowsSystem32driversetc>службы findstr /illmnr
llmnr 5355/tcp #LLMNR
llmnr 5355/udp #LLMNR

и, как мы видели выше, он работает как с IPv4, так и с IPv6:

C:WindowsSystem32driversetc>netstat -an | findstr /i «прототип 5355»
Протолокальный адрес Состояние внешнего адреса
УДП 0.0.0.0:5355 *:*
UDP [::]:5355 *:*

Как и в случае с любой службой, запуск LLMNR увеличивает поверхность атаки ПК. И действительно, «критическая» уязвимость безопасности в LLMNR стала предметом исправления для Windows от апреля 2011 года. Если вы не планируете использовать возможности P2P с нулевой конфигурацией Microsoft в своем домене, можно полностью отключить LLMNR с помощью групповой политики:

Групповая политика> Конфигурация компьютера> Административные шаблоны> Сеть> DNS-клиент> Отключить разрешение многоадресного имени = Включено

На этом работа Microsoft по разрешению многоадресных имен IPv6 завершается. В следующем посте мы рассмотрим протоколы обнаружения службы многоадресной рассылки IPv6 от Microsoft.

• Многоадресный фоновый трафик IPv6 (часть 5) — протоколы обнаружения службы многоадресной рассылки IPv6 от Microsoft