stringtranslate.com

Универсальный Plug and Play

Логотип UPnP, продвигаемый UPnP Forum (2001–2016) и Open Connectivity Foundation (2016–настоящее время)

Universal Plug and Play ( UPnP ) — это набор сетевых протоколов на основе интернет-протокола (IP), который позволяет сетевым устройствам, таким как персональные компьютеры, принтеры, интернет-шлюзы , точки доступа Wi-Fi и мобильные устройства, беспрепятственно обнаруживать присутствие друг друга в сети и устанавливать функциональные сетевые службы. UPnP предназначен в первую очередь для домашних сетей без устройств корпоративного класса.

UPnP предполагает, что сеть использует IP, а затем использует HTTP поверх IP для предоставления описания устройства/службы, действий, передачи данных и уведомлений о событиях . Запросы на поиск устройств и объявления поддерживаются запуском HTTP поверх UDP ( порт 1900) с использованием многоадресной рассылки (известной как HTTPMU). Ответы на поисковые запросы также отправляются по UDP, но вместо этого отправляются с использованием одноадресной рассылки (известной как HTTPU).

Концептуально UPnP расширяет plug and play — технологию динамического подключения устройств непосредственно к компьютеру — до сетей с нулевой конфигурацией для домашних и SOHO беспроводных сетей. Устройства UPnP являются plug and play в том смысле, что при подключении к сети они автоматически устанавливают рабочие конфигурации с другими устройствами, устраняя необходимость для пользователей вручную настраивать и добавлять устройства через IP-адреса . [1]

Обычно UPnP считается неподходящим для развертывания в бизнес-средах по причинам экономичности, сложности и согласованности: многоадресная основа делает его болтливым, потребляя слишком много сетевых ресурсов в сетях с большим количеством устройств; упрощенные элементы управления доступом плохо соответствуют сложным средам; и он не обеспечивает единообразного синтаксиса конфигурации, такого как среды CLI Cisco IOS или JUNOS. [ необходима ссылка ]

Обзор

Архитектура UPnP позволяет организовать сетевое взаимодействие между устройствами потребительской электроники , мобильных устройств, персональных компьютеров и сетевых бытовых приборов . Это распределенный протокол с открытой архитектурой , основанный на установленных стандартах, таких как Internet Protocol Suite (TCP/IP), HTTP , XML и SOAP . Точки управления UPnP (CP) — это устройства, которые используют протоколы UPnP для управления контролируемыми UPnP устройствами (CD). [2]

Архитектура UPnP поддерживает сетевое взаимодействие с нулевой конфигурацией. Совместимое с UPnP устройство от любого поставщика может динамически подключаться к сети, получать IP-адрес, объявлять свое имя, рекламировать или передавать свои возможности по запросу и узнавать о наличии и возможностях других устройств. Серверы DHCP и DNS являются необязательными и используются только в том случае, если они доступны в сети. Устройства могут автоматически отключаться от сети, не оставляя информации о состоянии .

UPnP был опубликован как международный стандарт ISO/IEC 29341 из 73 частей в декабре 2008 года. [3] [4] [5] [6] [7] [8]

Другие функции UPnP включают в себя:

Независимость от носителей и устройств
Технология UPnP может работать на многих носителях, поддерживающих IP, включая Ethernet , FireWire , IR ( IrDA ), домашнюю проводку ( G.hn ) и RF ( Bluetooth , Wi-Fi ). Поддержка специального драйвера устройства не требуется; вместо этого используются общие сетевые протоколы.
Управление пользовательским интерфейсом (UI)
При желании архитектура UPnP позволяет устройствам отображать пользовательский интерфейс через веб-браузер (см. презентацию ниже).
Независимость от операционной системы и языка программирования
Для создания продуктов UPnP можно использовать любую операционную систему и любой язык программирования. Стеки UPnP доступны для большинства платформ и операционных систем как в закрытом, так и в открытом виде.
Программное управление
Архитектура UPnP также позволяет осуществлять обычное программное управление приложениями. [ необходимо разъяснение ]
Расширяемость
Каждый продукт UPnP может иметь специфичные для устройств службы, наложенные поверх базовой архитектуры. Помимо комбинирования служб, определенных UPnP Forum различными способами, поставщики могут определять свои собственные типы устройств и служб, а также могут расширять стандартные устройства и службы с помощью действий, определенных поставщиком, переменных состояния, элементов структуры данных и значений переменных.

Протокол

UPnP использует общие интернет- технологии. Он предполагает, что сеть должна работать по протоколу Интернета (IP), а затем использует HTTP , SOAP и XML поверх IP, чтобы предоставить описание устройства/службы, действия, передачу данных и события. Запросы на поиск устройств и объявления поддерживаются запуском HTTP поверх UDP с использованием многоадресной рассылки (известной как HTTPMU). Ответы на поисковые запросы также отправляются по UDP, но вместо этого отправляются с использованием одноадресной рассылки (известной как HTTPU). UPnP использует UDP из-за его более низких накладных расходов, поскольку не требует подтверждения полученных данных и повторной передачи поврежденных пакетов. HTTPU и HTTPMU были первоначально представлены как проект Интернета , но срок его действия истек в 2001 году; [9] с тех пор эти спецификации были интегрированы в фактические спецификации UPnP.

UPnP использует UDP-порт 1900, а все используемые TCP- порты определяются на основе сообщений SSDP об активности и ответах. [10]

Адресация

Основой для сетей UPnP является IP-адресация. Каждое устройство должно реализовать DHCP-клиента и искать DHCP-сервер при первом подключении устройства к сети. Если DHCP-сервер недоступен, устройство должно назначить себе адрес. Процесс, с помощью которого устройство UPnP назначает себе адрес, известен в архитектуре устройств UPnP как AutoIP . В архитектуре устройств UPnP версии 1.0 [3] AutoIP определен в самой спецификации; в архитектуре устройств UPnP версии 1.1 [4] AutoIP ссылается на IETF RFC  3927. Если во время транзакции DHCP устройство получает доменное имя, например, через DNS-сервер или через пересылку DNS, устройство должно использовать это имя в последующих сетевых операциях; в противном случае устройство должно использовать свой IP-адрес.

Открытие

После того, как устройство установило IP-адрес, следующим шагом в работе сети UPnP является обнаружение. Протокол обнаружения UPnP известен как Simple Service Discovery Protocol (SSDP). Когда устройство добавляется в сеть, SSDP позволяет этому устройству рекламировать свои услуги контрольным точкам в сети. Это достигается путем отправки сообщений SSDP alive. Когда контрольная точка добавляется в сеть, SSDP позволяет этой контрольной точке активно искать интересующие устройства в сети или пассивно прослушивать сообщения SSDP alive устройств. Основной обмен — это сообщение обнаружения, содержащее несколько важных сведений об устройстве или одной из его услуг, например, его тип, идентификатор и указатель (сетевое местоположение) на более подробную информацию.

Описание

После того, как контрольная точка обнаружила устройство, контрольная точка все еще знает очень мало об устройстве. Чтобы контрольная точка могла узнать больше об устройстве и его возможностях или взаимодействовать с устройством, контрольная точка должна получить описание устройства из местоположения ( URL ), предоставленного устройством в сообщении об обнаружении. Описание устройства UPnP выражается в XML и включает в себя информацию о производителе, специфичную для поставщика, такую ​​как название и номер модели, серийный номер , название производителя, (презентационные) URL-адреса веб-сайтов, специфичных для поставщика, и т. д. Описание также включает в себя список всех встроенных служб. Для каждой службы документ описания устройства перечисляет URL-адреса для управления, событий и описания службы. Каждое описание службы включает в себя список команд или действий , на которые отвечает служба, и параметров или аргументов для каждого действия; описание службы также включает в себя список переменных ; эти переменные моделируют состояние службы во время выполнения и описываются с точки зрения их типа данных, диапазона и характеристик событий.

Контроль

Получив описание устройства, контрольная точка может отправлять действия в службу устройства. Для этого контрольная точка отправляет подходящее контрольное сообщение на контрольный URL для службы (указанный в описании устройства). Контрольные сообщения также выражаются в XML с использованием протокола SOAP (Simple Object Access Protocol ). Подобно вызовам функций , служба возвращает любые значения, специфичные для действия, в ответ на контрольное сообщение. Эффекты действия, если таковые имеются, моделируются изменениями в переменных, которые описывают состояние службы во время выполнения.

Уведомление о событии

Еще одной возможностью сетей UPnP является уведомление о событиях или eventing . Протокол уведомления о событиях, определенный в архитектуре устройств UPnP, известен как архитектура General Event Notification Architecture (GENA). Описание UPnP для службы включает список действий, на которые реагирует служба, и список переменных, которые моделируют состояние службы во время выполнения. Служба публикует обновления при изменении этих переменных, и контрольная точка может подписаться на получение этой информации. Служба публикует обновления, отправляя сообщения о событиях. Сообщения о событиях содержат имена одной или нескольких переменных состояния и текущее значение этих переменных. Эти сообщения также выражаются в XML. Специальное начальное сообщение о событии отправляется, когда контрольная точка впервые подписывается; это сообщение о событии содержит имена и значения для всех переменных, связанных с событиями , и позволяет подписчику инициализировать свою модель состояния службы. Для поддержки сценариев с несколькими контрольными точками, eventing предназначен для того, чтобы все контрольные точки были в равной степени информированы о последствиях любого действия. Таким образом, всем подписчикам отправляются все сообщения о событиях, подписчики получают сообщения о событиях для всех «событийных» переменных, которые изменились, и сообщения о событиях отправляются независимо от того, почему изменилась переменная состояния (либо в ответ на запрошенное действие, либо из-за изменения состояния, которое моделирует служба).

Презентация

Последний шаг в работе сети UPnP — это представление. Если у устройства есть URL для представления, то точка управления может извлечь страницу из этого URL, загрузить страницу в веб-браузер и, в зависимости от возможностей страницы, разрешить пользователю управлять устройством и/или просматривать состояние устройства. Степень, в которой каждое из этих действий может быть выполнено, зависит от конкретных возможностей страницы представления и устройства.

Стандарты AV

Архитектура UPnP AV — это аудио- и видеорасширение UPnP, поддерживающее множество устройств, таких как телевизоры, видеомагнитофоны, проигрыватели CD/DVD/музыкальные автоматы, приставки, стереосистемы, MP3-плееры, фотоаппараты, камкордеры, электронные фоторамки (EPF) и персональные компьютеры. Архитектура UPnP AV позволяет устройствам поддерживать различные типы форматов для развлекательного контента, включая MPEG2, MPEG4, JPEG, MP3, Windows Media Audio (WMA), растровые изображения (BMP) и форматы NTSC, PAL или ATSC. Поддерживаются различные типы протоколов передачи, включая IEEE 1394, HTTP, RTP и TCP/IP. [11]

12 июля 2006 года Форум UPnP объявил о выпуске версии 2 спецификаций UPnP Audio и Video [12] с новыми классами MediaServer (MS) версии 2.0 и MediaRenderer (MR) версии 2.0. Эти усовершенствования созданы путем добавления возможностей к классам устройств MediaServer и MediaRenderer, что обеспечивает более высокий уровень взаимодействия между продуктами разных производителей. Некоторые из ранних устройств, соответствующих этим стандартам, были проданы Philips под торговой маркой Streamium .

С 2006 года были опубликованы версии 3 и 4 протоколов управления аудио- и видеоустройствами UPnP. [13] В марте 2013 года была опубликована обновленная спецификация архитектуры uPnP AV, включающая обновленные протоколы управления устройствами. [11] Архитектура устройств UPnP 2.0 была выпущена в апреле 2020 года.

Стандарты UPnP AV упоминаются в спецификациях, опубликованных другими организациями, включая Руководство по совместимости сетевых устройств Digital Living Network Alliance , [14] Международная электротехническая комиссия IEC 62481-1, [15] и Протокол домашней сети OpenCable от Cable Television Laboratories . [16]

AV-компоненты

Обычно архитектура аудио/видео (AV) UPnP состоит из: [17]

Медиа сервер

АМедиасервер UPnP AV — это UPnP-сервер («главное» устройство), который предоставляет информацию о медиабиблиотеке и передает потоковые медиаданные (например, аудио/видео/изображения/файлы) клиентам UPnP в сети. Это компьютерная система или аналогичное цифровое устройство, которое хранит цифровые медиа, такие как фотографии, фильмы или музыка, и делится ими с другими устройствами.

Медиасерверы UPnP AV предоставляют услугу клиентским устройствам UPnP AV, так называемым контрольным точкам , для просмотра медиаконтента сервера и запроса медиасервера на доставку файла в контрольную точку для воспроизведения.

UPnP-медиасерверы доступны для большинства операционных систем и многих аппаратных платформ. UPnP AV-медиасерверы можно разделить на программные и аппаратные. Программные UPnP AV-медиасерверы могут работать на ПК . Аппаратные UPnP AV-медиасерверы могут работать на любых устройствах NAS или любом специальном оборудовании для доставки мультимедиа, таком как DVR . По состоянию на май 2008 года программных UPnP AV-медиасерверов было больше, чем аппаратных.

Другие компоненты

Обход NAT

Одно из решений для обхода NAT , называемое протоколом управления устройствами шлюза Интернета (протокол UPnP IGD), реализуется через UPnP. Многие маршрутизаторы и брандмауэры представляют себя как устройства шлюза Интернета, позволяя любой локальной точке управления UPnP выполнять различные действия, включая получение внешнего IP-адреса устройства, перечисление существующих сопоставлений портов и добавление или удаление сопоставлений портов. Добавляя сопоставление портов, контроллер UPnP за IGD может включить обход IGD с внешнего адреса на внутреннего клиента.

Существует множество проблем совместимости из-за различных интерпретаций очень больших фактически обратно совместимых спецификаций IGDv1 и IGDv2. Одна из них — клиент UPnP IGD, интегрированный с текущими системами Microsoft Windows и Xbox с сертифицированными маршрутизаторами IGDv2. Проблема совместимости все еще существует с момента появления клиента IGDv1 в Windows XP в 2001 году и маршрутизатора IGDv2 без обходного пути, делающего невозможным сопоставление портов маршрутизатора. [19]

Если UPnP используется только для управления сопоставлениями портов маршрутизатора и отверстиями, существуют альтернативные, более новые, гораздо более простые и легкие протоколы, такие как PCP и NAT-PMP , оба из которых были стандартизированы как RFC IETF. Пока не известно, что эти альтернативы имеют проблемы совместимости между различными клиентами и серверами, но их принятие все еще низкое. Для маршрутизаторов потребителей только AVM и проекты программного обеспечения маршрутизаторов с открытым исходным кодом OpenWrt , OPNsense и pfSense в настоящее время поддерживают PCP в качестве альтернативы UPnP. Реализация Fritz !Box UPnP IGDv2 и PCP от AVM была очень глючной с момента ее появления. Во многих случаях она не работает. [20] [21] [22] [23] [24]

Проблемы

Аутентификация

Протокол UPnP по умолчанию не реализует никакой аутентификации , поэтому реализации устройств UPnP должны реализовать дополнительную службу защиты устройств [25] или реализовать службу безопасности устройств [26] . Существует также нестандартное решение, называемое UPnP-UP (Universal Plug and Play - User Profile) [27] [28] , которое предлагает расширение, позволяющее использовать механизмы аутентификации и авторизации пользователей для устройств и приложений UPnP. Во многих реализациях устройств UPnP отсутствуют механизмы аутентификации, и по умолчанию предполагается, что локальные системы и их пользователи полностью заслуживают доверия. [29] [30]

Если механизмы аутентификации не реализованы, маршрутизаторы и брандмауэры, работающие по протоколу UPnP IGD, уязвимы для атак. Например, программы Adobe Flash, работающие вне изолированной программной среды браузера (например, для этого требуется определенная версия Adobe Flash с подтвержденными проблемами безопасности), способны генерировать определенный тип HTTP- запроса, который позволяет вредоносному веб-сайту контролировать маршрутизатор, реализующий протокол UPnP IGD, когда кто-то с маршрутизатором с поддержкой UPnP просто посещает этот веб-сайт. [31] Это применимо только к функции «брандмауэр-дыр-перфорация» UPnP; это не применимо, когда маршрутизатор/брандмауэр не поддерживает UPnP IGD или был отключен на маршрутизаторе. Кроме того, не все маршрутизаторы могут иметь такие вещи, как настройки DNS-сервера, измененные UPnP, поскольку большая часть спецификации (включая конфигурацию хоста локальной сети) является необязательной для маршрутизаторов с поддержкой UPnP. [6] В результате некоторые устройства UPnP поставляются с отключенным по умолчанию UPnP в качестве меры безопасности.

Доступ из Интернета

В 2011 году исследователь Дэниел Гарсия разработал инструмент, предназначенный для эксплуатации уязвимости в некоторых стеках устройств UPnP IGD, которые позволяют выполнять запросы UPnP из Интернета. [32] [33] Инструмент был представлен общественности на DEFCON 19 и позволяет выполнять запросы портов на внешние IP-адреса с устройства и внутренние IP-адреса за NAT. Проблема широко распространена по всему миру, при сканировании одновременно обнаруживаются миллионы уязвимых устройств. [34]

В январе 2013 года компания по безопасности Rapid7 в Бостоне сообщила [35] о шестимесячной исследовательской программе. Группа сканировала на наличие сигналов от устройств с поддержкой UPnP, объявляющих о своей доступности для подключения к Интернету. Около 6900 сетевых продуктов от 1500 компаний с 81 миллиона IP-адресов ответили на их запросы. 80% устройств — это домашние маршрутизаторы; другие включают принтеры, веб-камеры и камеры наблюдения. Используя протокол UPnP, можно получить доступ ко многим из этих устройств и/или манипулировать ими.

В феврале 2013 года форум UPnP отреагировал пресс-релизом [36], порекомендовав более свежие версии используемых стеков UPnP и улучшив программу сертификации, включив проверки, чтобы избежать подобных проблем в будущем.

IGMP-отслеживание и надежность

UPnP часто является единственным значимым многоадресным приложением, используемым в цифровых домашних сетях; поэтому неправильная конфигурация многоадресной сети или другие недостатки могут проявляться как проблемы UPnP, а не как основные проблемы сети.

Если на коммутаторе или, что чаще всего, на беспроводном маршрутизаторе/коммутаторе включено отслеживание IGMP , то при неправильной или неполной настройке (например, без активного опрашивающего устройства или прокси-сервера IGMP) оно будет мешать обнаружению устройств UPnP/DLNA (SSDP), из-за чего UPnP будет казаться ненадежным.

Типичные наблюдаемые сценарии включают появление сервера или клиента (например, Smart TV) после включения питания, а затем исчезновение через несколько минут (часто через 30 минут по умолчанию) из-за истечения срока членства в группе IGMP.

Уязвимость обратного вызова

8 июня 2020 года было объявлено об еще одной ошибке в конструкции протокола [37] . Описанная ее первооткрывателем как «CallStranger» [38] , она позволяет злоумышленнику нарушить механизм подписки на события и выполнить ряд атак: усиление запросов для использования в DDoS; перечисление; и кража данных.

OCF опубликовал исправление спецификации протокола в апреле 2020 года, [39] но поскольку многие устройства, работающие под управлением UPnP, нелегко обновить, CallStranger, вероятно, останется угрозой в течение длительного времени. [40] CallStranger подпитывает призывы к конечным пользователям отказаться от UPnP из-за повторяющихся сбоев в безопасности его разработки и реализации. [41]

История

Протоколы UPnP были продвинуты Форумом UPnP (созданным в октябре 1999 года), [42] инициативой компьютерной индустрии, направленной на обеспечение простого и надежного подключения к автономным устройствам и персональным компьютерам от многих различных поставщиков. Форум состоял из более чем 800 поставщиков, занимающихся всем, от бытовой электроники до сетевых вычислений. С 2016 года все усилия UPnP курируются Фондом Open Connectivity Foundation (OCF).

Осенью 2008 года Форум UPnP ратифицировал преемника архитектуры устройств UPnP 1.0 — UPnP 1.1. [43] Стандарт Devices Profile for Web Services (DPWS) был кандидатом на роль преемника UPnP, но Форум UPnP выбрал UPnP 1.1. Версия 2 IGD стандартизирована. [44]

Стандарт UPnP Internet Gateway Device (IGD) [6] имеет службу WANIPConnection, которая обеспечивает схожую функциональность с протоколом управления портами IETF -стандарта . Спецификация NAT-PMP содержит список проблем с IGDP [45] : 26–32  , которые побудили создать NAT-PMP и его преемника PCP.

Для архитектуры устройств UPnP был определен ряд дополнительных стандартов:

Смотрите также

Ссылки

  1. ^ Велимирович, Андреа (13 января 2022 г.). «Что такое UPnP (Universal Plug and Play)?». Блог phoenixNAP . Получено 27 сентября 2023 г.
  2. ^ «Использование API точки управления UPnP». Microsoft Developer Network . 14 сентября 2012 г. Получено 11 сентября 2014 г.
  3. ^ ab "UPnP Device Architecture v1.0" (PDF) . upnp.org . Форум UPnP. 15 октября 2008 г.
  4. ^ ab "UPnP Device Architecture v1.1" (PDF) . openconnectivity.org . Форум UPnP. 15 октября 2008 г.
  5. ^ «Архитектура устройства UPnP v2.0» (PDF) . openconnectivity.org . OCF . 17 апреля 2020 г.
  6. ^ abc «UPnP InternetGatewayDevice v1.0/v2.0». openconnectivity.org . УПнП-форум. 10 декабря 2010 г.
  7. ^ "Стандарт ISO/IEC по архитектуре устройств UPnP упрощает и облегчает работу в сети". Международная организация по стандартизации . 10 декабря 2008 г. Получено 11 сентября 2014 г.
  8. ^ "Спецификации UPnP названы международным стандартом взаимодействия устройств для сетевых устройств на базе IP" (PDF) . Форум UPnP . 5 февраля 2009 г. Архивировано из оригинала (PDF) 1 апреля 2014 г. Получено 11 сентября 2014 г.
  9. ^ Голанд, Ярон Ю.; Шлиммер, Джеффри К. (2 октября 2000 г.). «Многоадресные и одноадресные сообщения UDP HTTP». Технический комитет форума UPnP. Архивировано из оригинала 30 декабря 2006 г. Получено 11 сентября 2014 г.
  10. ^ "Как брандмауэр Windows влияет на инфраструктуру UPnP в Windows XP с пакетом обновления 2". Microsoft . 23 мая 2014 г. . Получено 11 сентября 2014 г. .
  11. ^ ab "UPnP AV Architecture" (PDF) . Форум UPnP . 31 марта 2013 г. . Получено 11 сентября 2014 г. .
  12. ^ "Форум UPnP выпускает улучшенные спецификации AV, выводящие домашние сети на новый уровень" (PDF) . Форум UPnP . 12 июля 2006 г. . Получено 11 сентября 2014 г. .
  13. ^ "Протоколы управления устройствами". Форум UPnP . Получено 11 сентября 2014 г.
  14. ^ "Руководство по совместимости сетевых устройств DLNA". Digital Living Network Alliance . Март 2014 г. Получено 11 сентября 2014 г.
  15. ^ "Digital living network alliance (DLNA) home networked devices interoperability guidelines - Part 1: Architecture and protocols". Международная электротехническая комиссия . 23 октября 2013 г. Получено 11 сентября 2014 г.
  16. ^ "OpenCable Specifications Home Networking 2.0 - Home Networking Protocol 2.0 Revision 10" (PDF) . Cable Television Laboratories . 30 мая 2013 г. Архивировано из оригинала (PDF) 11 сентября 2014 г. Получено 11 сентября 2014 г.
  17. ^ EDN (9 сентября 2005 г.). «Как DLNA и UPnP обеспечат простоту домашних видеосетей». EDN . Получено 27 сентября 2023 г. .
  18. ^ "CEA-2014-B (ANSI) - Веб-протокол и фреймворк для удаленного пользовательского интерфейса в сетях UPnP и Интернете (Web4CE)". CEA R7 Home Home Network Committee . 1 января 2011 г. Архивировано из оригинала 29 апреля 2013 г. Получено 11 сентября 2014 г.
  19. ^ "Определить FDSSDP как клиента Microsoft · miniupnp/miniupnp@8381867". GitHub . Получено 18 сентября 2023 г. .
  20. ^ 12 Фелер в реализации AVM UPnP IGD и PCP (aller FritzBoxen).
  21. ^ "UPnP не работает с моим FRITX!Box". Форум сообщества Syncthing . 12 апреля 2022 г. Получено 18 сентября 2023 г.
  22. ^ "UPNP_GetValidIGD возвращает временный адрес IPv6, что приводит к сбою UPNP_AddPinHole с кодом 606 · Проблема № 600 · miniupnp/miniupnp". GitHub . Получено 18 сентября 2023 г. .
  23. ^ "upnpc показывает неправильную продолжительность переадресации порта дольше 120 секунд · Проблема № 222 · miniupnp/miniupnp". GitHub . Получено 18 сентября 2023 г. .
  24. ^ "miniupnp.tuxfamily.org :: Просмотр темы - Настройка переадресации портов не работает". miniupnp.tuxfamily.org . Получено 18 сентября 2023 г. .
  25. ^ "Device Protection V 1.0". Форум UPnP . Архивировано из оригинала 17 октября 2014 г. Получено 11 сентября 2014 г.
  26. ^ "Device Security and Security Console V 1.0". Форум UPnP . Архивировано из оригинала 31 августа 2014 г. Получено 11 сентября 2014 г.
  27. ^ "UPnP-UP - Universal Plug and Play - User Profile". Архивировано из оригинала 10 декабря 2013 года . Получено 1 января 2012 года .
  28. ^ Сэйлз, Тиаго; Сэйлз, Леандро; Алмейда, Хигго; Перкусич, Анджело (ноябрь 2010 г.). «Расширение UPnP для включения аутентификации и авторизации пользователей в широко распространенных системах». Журнал бразильского компьютерного общества . 16 (4): 261–277. doi : 10.1007/s13173-010-0022-2 .
  29. ^ Eastep, Thomas M. (4 июня 2014 г.). "Shorewall and UPnP" . Получено 11 сентября 2014 г.
  30. ^ "Linux UPnP Internet Gateway Device - Документация - Безопасность" . Получено 11 сентября 2014 г.
  31. ^ "Hacking The Interwebs". 12 января 2008 г. Получено 11 сентября 2014 г.
  32. ^ Гарсия, Дэниел. "UPnP Mapping" (PDF) . Получено 11 сентября 2014 г.
  33. ^ "US-CERT Vulnerability Note VU#357851". CERT/CC . 30 ноября 2012 г. Получено 11 сентября 2014 г.
  34. ^ "Миллионы устройств уязвимы через UPnP - Обновление". H. 30 января 2013 г. Получено 11 сентября 2014 г.
  35. ^ Мур, HD (29 января 2013 г.). «Белая книга: Уязвимости безопасности в Universal Plug and Play: отключи, не играй» . Получено 11 сентября 2014 г.
  36. ^ "Форум UPnP реагирует на недавно выявленную уязвимость безопасности LibUPnP/MiniUPnP" (PDF) . Форум UPnP . 8 февраля 2013 г. . Получено 11 сентября 2014 г. .
  37. ^ «Заметка об уязвимости CERT/CC VU#339275».
  38. ^ "CallStranger CVE-2020-12695". Архивировано из оригинала 16 июня 2020 г. Получено 14 июня 2020 г.
  39. ^ «OCF — Стандарты и архитектура UPnP».
  40. ^ «CVE-2020-12695: уязвимость CallStranger в Universal Plug and Play (UPnP) подвергает риску миллиарды устройств». 8 июня 2020 г.
  41. ^ «Отключите UPnP на вашем беспроводном маршрутизаторе уже». Lifehacker . 12 июня 2020 . Получено 14 июня 2020 .
  42. ^ "OCF - UPnP Standards & Architecture". Open Connectivity Foundation (OCF) . Получено 27 сентября 2023 г.
  43. ^ Bodlaender, MP (февраль 2005 г.). «UPnP 1.1 — проектирование для производительности и совместимости». IEEE Transactions on Consumer Electronics . 51 (1): 69–75. doi :10.1109/TCE.2005.1405701. S2CID  11792030.
  44. ^ "Рабочий комитет шлюза форума UPnP: улучшения IGD:2 по сравнению с IGD:1" (PDF) . Форум UPnP . 10 марта 2009 г. . Получено 11 сентября 2014 г. .
  45. ^ S. Cheshire; M. Krochmal (апрель 2013 г.). "RFC 6886: Протокол сопоставления портов NAT (NAT-PMP)". Internet Engineering Task Force (IETF). doi : 10.17487/RFC6886 . Получено 8 августа 2014 г. {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  46. ^ "WFA WLANConfig Service 1.0 Service Template Version 1.01" (PDF) . Январь 2006 г. Архивировано из оригинала (PDF) 8 декабря 2022 г.
  47. ^ "Wi-Fi Protected Setup Specification Version 2.0.8" (PDF) . Архивировано из оригинала (PDF) 22 марта 2021 г.

Дальнейшее чтение

Внешние ссылки