Upnp что это в камере
Открываем порты за NAT при помощи NAT-PMP и UPnP IGD
Ранее я много раз слышал, что UPnP каким-то образом умеет самостоятельно открывать порты (производить Port Forwarding на роутере) по запросу от хоста из локальной сети. Однако, то, каким именно образом это происходит, и какие протоколы для этого используются, доселе было покрыто для меня пеленой тумана.
В данной статье я хочу кратко рассказать, как работают два механизма для проброса портов, а именно NAT Port Mapping Protocol и Internet Gateway Device (IGD) Protocol, входящий в набор протоколов UPnP. К своему удивлению я обнаружил, что в рунете информация по данному вопросу более чем скудна, что и сподвигло меня на написание данной заметки.
Для начала приведу краткий FAQ:
Q: Для чего нужны данные протоколы?
A: Для формирования на маршрутизаторе правила проброса определенного TCP/UDP порта (Port Forwarding) не вручную, а «автоматически», т.е. по запросу от хоста во внутренней сети.
Q: Как это реализуется?
A: Устройство за NAT отправляет маршрутизатору запрос с указанием внутреннего и внешнего номеров портов и типа протокола (TCP/UDP). Если указанный внешний порт свободен, маршрутизатор формирует у себя правило трансляции и рапортует запросившему компьютеру об успешном выполнении запроса.
Q: Проводится ли на маршрутизаторе аутентификация/авторизация запросов на открытие порта?
A: Нет, не проводится.
Теперь же рассмотрим работу данных протоколов более подробно (под катом).
Port Mapping Protocol
NAT-PMP описан в RFC 6886. Для своей работы он использует UDP-порт сервера 5351.
Рассмотрим работу протокола на конкретном примере — торрент-клиенте Vuze 5.7 для Windows 7.
Примечание: NAT-PMP во Vuze по умолчанию выключен. Его необходимо активировать в настройках плагинов.
1. Запускаем Wireshark. В строке фильтра вводим nat-pmp
2. Запускам Vuze.
3. Останавливаем перехват пакетов, смотрим результаты.
У меня получилось следующее:
Всего видим 6 пакетов (3 запроса и 3 ответа).
Первые 2 это запрос внешнего адреса маршрутизатора и ответ с указанием этого самого адреса. Не будем на них подробно останавливаться и лучше рассмотрим, как происходит маппинг портов на примере пакетов 3-4.
Здесь мы видим, что запрашивается проброс внешнего UDP порта 48166 на такой же внутренний порт. Интересно, что внутри протокола не указывается адрес хоста, на который должна происходить трансляция (Inside Local в терминологии Cisco). Это означает, что маршрутизатор должен взять адрес источника пакета из IP-заголовка и использовать его в качестве Inside Local.
Параметр Requested Port Mapping Lifetime ожидаемо означает время жизни записи в таблице трансляций.
Как мы видим, маршрутизатор предполагаемо создал запрашиваемую трансляцию и ответил кодом Success. Параметр Seconds Since Start of Epoch означает время с момента инициализации таблицы трансляций (т.е. с момента последней перезагрузки роутера).
Маппинг TCP-портов происходит точно также и отличается только значением поля Opcode.
После того, как приложение прекратило использовать данные порты, оно может послать маршрутизатору запрос на удаление трансляции.
Главное отличие запроса на удаление от запроса на создание заключается в том, что параметр Lifetime устанавливается в ноль.
Вот что произойдет, если мы закроем Vuze.
На этом рассмотрение NAT-PMP закончено, предлагаю перейти к несколько более «мудреному» UPnP IGD.
Internet Group Device Protocol
Для обмена своими сообщениями данный протокол использует SOAP.
Однако, в отличие от NAT-PMP, IGD не использует фиксированный номер порта сервера, поэтому перед тем, как обмениваться сообщениями, нужно сперва этот порт узнать. Делается это при помощи протокола SSDP (данный протокол является частью UPnP и используется для обнаружения сервисов).
Запускаем торрент-клиент. Он формирует SSDP-запрос и отсылает его на мультикастовый адрес 239.255.255.250.
Маршрутизатор формирует ответ и отправляет его уже юникастом:
Внутри ответа мы можем увидеть URL для взаимодействия с маршрутизатором по протоколу IGD.
Далее Vuze подключается к маршрутизатору по указанному URL и получает XML с информацией о данном устройстве, в том числе содержащую набор URI для управления некоторыми функциями маршрутизатора. После того, как нужный URI найден в rootDesc.xml, Vuze отправляет SOAP-запрос на содание NAT-трансляции по найденному URI.
Примечание: до того, как запросить создание трансляции, Vuze заставил маршрутизатор перечислить все имеющиеся Port Forwarding’и. Для чего это было сделано, я могу лишь догадываться.
SOAP-запрос на создание трансляции UDP-порта:
Как говорилось ранее, нужный URI (идет сразу после POST) Vuze взял из rootDesc.xml. Для добавления трансляции используется функция с названием AddPortMapping.
Также можно отметить, что, в противоположность NAT-PMP, Inside Local-адрес указывается внутри самого протокола.
Аналогично NAT-PMP, при закрытии торрент-клиента маппинги проброшенных портов удаляются. Делается это функцией DeletePortMapping:
Можно заметить, что для удаления правила достаточно указать только тип протокола (UDP) и номер внешнего порта, не указывая остальные параметры.
IPnP: что такое в роутере и как пользоваться опцией?
При настройке сети часто появляется вопрос по поводу функции UPnP — что такое в роутере, как работает, и какие риски несет для пользователя ее включение. Ниже рассмотрим назначение опции, как ее активировать, отключать и настраивать. Поговорим о преимуществах и недостатках, а также опасности для пользователя Сети.
Что такое UPnP
Для начала разберемся с терминологией — в чем суть UPnP в роутер, и что это такое. UPnP (Universal Plug and Play) — это расширение, с помощью которого программа на ПК может подать запрос к роутеру на упомянутом языке, а после перенаправить на себя порт. Архитектура построена на базе действующих технологий Интернет-сети и стандартов, среди которых XML, HTTP, TCP/IP и другие.
Простыми словами, UPnP — протокол, позволяющий программам и другим устройствам сети открывать или закрывать порты для подключения. К примеру, для коммутации МФО ко всему оборудованию в квартире придется вбивать настройки для каждого девайса отдельно.
Для чего он нужен
С помощью службы UPnP происходит автоматическое перенаправление портов. Такая опция используется в Скайпе, торрент-клиентах, XBOX Live и т. д. После включения функции автоматически задает требуемый набор правил NAT и межсетевого экрана, что экономит время пользователя на настройку.
Для нормальной работы UPnP должна быть активна не только в роутере, но и в приложении, для которого осуществляется проброс портов. Правила для переадресации формируются в автоматическом режиме путем подачи запроса через механизм рассматриваемой службы. Установленные правила работают только в период сессии и исключительно для хоста, с которого идет запрос. После окончания сессии правило убирается.
Включение UPnP в роутере необходимо в следующих случаях:
Зная особенности UPnP IGD, и что это в роутере, можно быстро активировать опцию и использовать ее возможности для соединения нескольких устройств без ввода настроек вручную.
Как пользоваться: включение, отключение, настройка
Применение UPnP подразумевает три этапа — активация нужной функции в роутере, ее включение на ПК (если требуется), а также настройка в приложении. Рассмотрим каждый подробнее.
Включение в роутере
Для начала рассмотрим, как включить UPnP на роутере, если служба не активирована по умолчанию или была выключена ранее.
Инструкция к действию (на примере TP-Link):
В дальнейшем можно отключить функцию UPnP, сделав те же самые шаги. Разница только в том, что на завершающем этапе тумблер нужно будет перевести влево.
Для разных роутеров настройка может отличаться. В частности, в ZyXEL необходимо перейти в раздел Домашняя сеть, а далее найти отметку UPnP и установить галочку Разрешить, а после сохранить изменения.
Включение на ПК
После внесения настроек в роутере необходимо изменить конфигурацию и на компьютере. Ниже рассмотрим пример для ПК с установленной на нем ОС Виндовс 8. В остальных версиях принцип действия такой же, но с небольшими особенностями.
Для включения UPnP сделайте следующее:
Теперь функция включена в роутере и на компьютере.
Настройка программ
Для пользования службой необходимо настроить на сервис используемые программы. Здесь все зависит от того, какое ПО вы планируете использовать. Рассмотрим несколько вариантов:
Убедитесь в правильности ввода информации. Для этого войдите в Свойства соединения в Шлюзе, кликните на кнопку Параметры и убедитесь в появлении правила для uTorrent. Если торрент установлен на двух и более «станциях», для каждой программы задается свой порт. В дальнейшем ни в коем случае нельзя использовать случайное значение.
По похожему принципу можно настроить и другие программы для работы с UPnP.
Плюсы и минусы использования
В любой технологии можно найти преимущества и недостатки. В том числе UPnP.
Несмотря на ряд недостатков, технология считается одной из самых востребованных в роутере. Не удивительно, что многие пользователи часто включают ее на постоянной основе.
Безопасно ли использование UPnP
При появлении технологии планировалось, что UPnP будет функционировать на локальном уровне для подключения устройств внутри сети. Но некоторые производители включили опцию в роутерах по умолчанию, что делает устройство доступным из WAN, а это ведет к уязвимости в сфере безопасности. Во время работы UPnP не применяется авторизация или аутентификация. Считается, что все подключаемые устройства имеют высокую степень надежности.
Хакеры пользуются такой уязвимостью и могут найти слабые места в сети. Распространенная ситуация — отправка UPnP запроса на роутер с последующем открытием порта. После подключения к сети злоумышленник получает доступ к другому оборудованию, находящемуся в сети. В дальнейшем он может установить вирус, украсть конфиденциальные сведения или использовать маршрутизатор в роли прокси-сервера. Негативных сценариев много. При этом выявить хакера трудно, ведь, по сути, атаки идут изнутри сети.
Для защиты можно использовать следующие методы:
UPnP для роутера — удобная функция, упрощающая процесс настройки портов. Но нужно помнить о рисках и предусмотреть дополнительные способы защиты.
UPnP: что такое в роутере : Один комментарий
Тебе придрок! Как говаривал М. Задорнов!
Нужно не статьи а инструкции к лому писать!
UPnP обычно считается непригодным для развертывания в бизнес-средах по причинам экономии, сложности и согласованности: многоадресная основа делает его болтливым, потребляя слишком много сетевых ресурсов в сетях с большим количеством устройств; упрощенные средства управления доступом плохо подходят для сложных сред; и он не обеспечивает единообразного синтаксиса конфигурации, такого как среды CLI Cisco IOS или JUNOS.
СОДЕРЖАНИЕ
Обзор
UPnP был опубликован как международный стандарт ISO / IEC 29341, состоящий из 73 частей, в декабре 2008 года.
Другие функции UPnP включают:
Протокол
UPnP использует UDP-порт 1900, и все используемые TCP- порты являются производными от SSDP-сообщений и ответных сообщений.
Обращение
Открытие
Описание
Контроль
Уведомление о событии
Презентация
Стандарты UPnP AV
С 2006 года издаются версии 3 и 4 протоколов управления аудио и видео UPnP. В марте 2013 года была опубликована обновленная спецификация архитектуры uPnP AV, включающая обновленные протоколы управления устройствами.
Компоненты UPnP AV
Медиа-сервер
Прочие компоненты
Обход NAT
Проблемы с UPnP
Аутентификация
Доступ из интернета
В 2011 году исследователь Даниэль Гарсиа разработал инструмент, предназначенный для использования уязвимости в некоторых стеках устройств UPnP IGD, которые разрешают запросы UPnP из Интернета. Инструмент был обнародован на DEFCON 19 и позволяет отображать запросы на внешние IP-адреса от устройства и внутренние IP-адреса за NAT. Проблема широко распространена по всему миру, при сканировании одновременно обнаруживаются миллионы уязвимых устройств.
В феврале 2013 года форум UPnP ответил в пресс-релизе, порекомендовав более свежие версии используемых стеков UPnP и улучшив программу сертификации, включив в нее проверки, чтобы избежать подобных проблем в дальнейшем.
Отслеживание IGMP и надежность
UPnP часто является единственным значимым многоадресным приложением, используемым в цифровых домашних сетях; поэтому неправильная конфигурация многоадресной сети или другие недостатки могут проявляться как проблемы UPnP, а не как основные проблемы сети.
Типичные наблюдаемые сценарии включают сервер или клиент (например, Smart TV), появляющийся после включения, а затем исчезающий через несколько минут (часто 30 по умолчанию) из-за истечения срока членства в группе IGMP.
Уязвимость обратного вызова
8 июня 2020 года было объявлено еще об одном недостатке конструкции протокола. Получивший название «CallStranger» своим открывателем, он позволяет злоумышленнику нарушить механизм подписки на события и выполнить различные атаки: усиление запросов для использования в DDoS; перечисление; и кража данных.
OCF опубликовала исправление для спецификации протокола в апреле 2020 года, но поскольку многие устройства, на которых работает UPnP, нелегко обновить, CallStranger, вероятно, останется угрозой еще долгое время. CallStranger вызвал призывы к конечным пользователям отказаться от UPnP из-за неоднократных сбоев в обеспечении безопасности его дизайна и реализации.
Будущие разработки
Осенью 2008 года UPnP Forum ратифицировал преемника UPnP 1.0 Архитектура устройства UPnP 1.1. Стандарт Devices Profile for Web Services (DPWS) был кандидатом на замену UPnP, но UPnP 1.1 был выбран форумом UPnP Forum. Версия 2 IGD стандартизирована.
Старая уязвимость в UPnP на новый манер
Всё новое — это хорошо забытое старое (а лучше очень хорошо забытое старое). Следить за новыми уязвимостями, конечно же, правильно, но и о старых забывать не стоит. Тем более, когда о них позволяет себе «забыть» производитель. Кто-то должен помнить. Иначе мы снова и снова будем наступать на одни и те же грабли.
Речь в статье пойдет об одной старенькой, но, как оказалось, ни разу не потерявшей актуальности и по сей день, дыре UPnP.
P.S. Провайдера называть не буду, вины его в этом нет, но с другой стороны есть явный недосмотр политик безопасности, которые вкупе с архитектурой сети дали возможность проэксплуатировать эту уязвимость. Как это всегда бывает — звезды сошлись. Провайдер ставил на своей сети роутеры клиентам с нужными чипами и подключал с внешним ip адресом. Да, большинство портов были зафильтрованы, но почему-то не 52869.
P.P.S. Все события произошли в конце 2018 года. Герои вымышлены, а совпадения с реальными личностями случайны.
Есть некоторая библиотека libupnp для разработки, которая «используется на тысячах устройств и называется Intel SDK для UPnP-устройств или Portable SDK для UPnP-устройств».
«The portable SDK for UPnP Devices (libupnp) provides developers with an API and open source code for building control points, devices, and bridges that are compliant with Version 1.0 of the Universal Plug and Play Device Architecture Specification and support several operating systems like Linux, *BSD, Solaris and others.»
«… ограничение взаимодействия со службой… Только клиенты и серверы, которые имеют законные процедурные отношения… должны иметь возможность общаться с ним.»
Недостаток существует в сервисе miniigd SOAP. Проблема заключается в обработке запросов NewInternalClient из-за невозможности очистки пользовательских данных перед выполнением системного вызова. Злоумышленник может использовать эту уязвимость для выполнения кода с привилегиями root.
Т.е. на всех роутерах с версией UPnP 1.0 можно выполнять произвольный удаленный код.
Без авторизации. От рута. Здорово, правда?
Любой желающий может на github’е найти готовый плагин для метасплоита, работоспособность которого проверена прожженными стульями наших дежурных инженеров.
Было неожиданно и совсем не весело.
Краткая хронология событий того дня:
14:00 В техническую поддержку начинают поступать обращение абонентов на плохо работающий интернет.
15:00 Количество заявок начинает превышать среднюю температуру по больнице и одиночные заявки начинают лепить в заявки по больше с типом «Авария». Заявки передаются на старших администраторов для проверки сегментов сети.
15:20 Админы закрывают массовые аварии, т.к. проблем на сети нет, все заявки клиентов с разных точек подключения и одиночные. (к примеру: коммутатор полный активных абонентов, а плохо работает у одного). В этот момент спадают обращения и всё затихает. Кто-то обращает внимание (наконец-то), что все заявки на плохую работу были с одной и той-же моделью роутера, все дружно делают вид, что всё хорошо.
15:30 Снова наплыв заявок от абонентов, снова регистрация массовой аварии и передача админам. В этот момент становится ясно, что что-то действительно не так и нужно что-то делать (кто работал с клиентским сервисом меня поймет, как это иногда сложно сделать. Клиенты всегда врут, а иногда и первая линия врет, чтобы эскалировать задачу дальше).
15:35 Дежурный инженер получает заявку на проблему с клиентским сервисом. Получает список всех клиентов, тип их подключения и модель устройства. А дальше начинается немного магии.
15:40 Инженер прогоняет список клиентов через все диагностики какие есть, каждый роутер был проверен по всем стандартным метрикам и… ничего не нашлось. Роутер как роутер. Да, увеличилось CPU, но показатели не критичные, да он льет куда-то трафик, значит — работает.
Да, крутится на 52869 порту UPnP-сервис. Да там еще куча открытых портов, открыты значит нужны (логика железная), и он всегда там крутился и никаких проблем не было (еще один аргумент железной логики). Прямой ssh на данную модель роутера невозможен (откровенно говоря возможен, но внутри сильно урезанный busybox и политикой компании крайне не приветствовалось такое хождение по клиентским устройствам). Всё опять встало.
16:00 Только сейчас мы узнаем о том, что есть какие-то проблемы. Дежурный инженер докладывает своему руководителю, а руководитель телефонным звонком сообщает нам свои догадки по поводу 52869 порта и просит помочь.
16:05 Дальше всё происходило очень быстро. На тестовый стенд включается такая же модель роутера, у проблемного клиента забирается ip-адрес и вешается на тестовый. Включается wireshark. Это чтобы отловить запросы к устройству.
Чтобы отловить запросы от роутера (на тот момент еще неизвестна была общая схема, как происходит взаимодействие) клиент изолируется в тестовом сегменте и весь его трафик миррорится в ближайшую тестовую машину где поднят еще один wireshark.
Дальше ждем, смотрим в экран.
Таким способом уже ловили взломы — достаточно эффективно и поэтому решили не изменять привычкам.
16:10 Пока wireshark шуршит, в гугле находится уязвимость CVE-2014-8361 о чем сообщается инженерам. Инженер, не дослушав, принимает решение (и в принципе логичное) — фильтр данного порта на бордерах. Сказанно — сделано.
16:25 Нам сообщают, что все говно миша переделывай не сработало. И мы уже знали, что не сработает. К тому моменту на тестовый роутер уже постучались, подняли реверс-шел на другом порту и начали параллельно использовать для DDOS-a через 1900(!) порт используя еще одну уязвимость. Господи, како же дырявое помойное ведро
Использование в DDoS атаках схемка
В 2014 неожиданно обнаружили, что SSDP использовался в DDoS атаках типа «Атака отражения и усиления при помощи SSDP» (SSDP reflection attack with amplification). Многие устройства, в том числе бытовые маршрутизаторы имели изъян в программном обеспечении UPnP, который позволял атакующему направлять ответы с порта 1900 на произвольный адрес в сети Интернет. В случае использования ботнета из многих тысяч подобных устройств, атакующий мог создать большой поток пакетов, достаточных для занятия пропускной полосы и насыщения каналов передачи данных атакуемой площадки, что приводит к отказу в обслуживании для обычных пользователей.
Самое интересное — были изменены правила файрвола на устройстве и nmap теперь не показывал открытые порты с внешки. Только в дампе трафика можно было обнаружить запросы по этим портам. Т.е. злоумышленник после взлома закрывал доступ для остальных. Не хай-тек подход, но всё равно — браво.
16:30 Собирается конфа с вопросами «кто виноват и что делать». Оставили забаннеными порты 1900 и 52869. Принимаются попытки уже на взломанных устройствах что-то исправить. Ребут — не помог, идею перепрошить сразу отвергли. Да, функционал такой имеется, можно было одной кнопкой на всех устройствах переставить удаленно ПО через TR069. Но т.к. устройство не первой свежести, а количество клиентов было большим — определенный процент окирпиченных устройств создал бы проблем.
16:40 Подводим краткий итог: устройства взломаны, участвуют минимум в ddos и по шифрованному каналу куда-то что-то передают. (Все на разных портах). Залезть внутрь не представляется возможным, вендор отказал в полном доступе по ssh к устройству и посмотреть, что именно там накрутили невозможно. Консоль запаролена.
Где-то ближе к 17:00 Было принято решение шить устройства как самый быстрый способ. После перепрошивки и перезагрузки — всё нормализовалось.
Вместо итогов
К сожалению, так до конца решить эту проблему мы не смогли.
Под «решить» я подразумеваю получить полную информацию по взлому и обновить наши политики для противодействия подобному в дальнейшем. Да, не все поставленные задачи решаются успешно и так как хотелось бы. Это нормально. Хоть и обидно.
Если хорошо поискать на шодане,
то можно найти себе что-нибудь
для экспериментов:
так или так
но я вам этого не говорил.