Многие реализации протокола NAT-PMP (http://en.wikipedia.org/wiki/NAT_Port_Mapping_Protocol) в SOHO-маршрутизаторах различных производителей оказались (https://community.rapid7.com/community/metasploit/blog/2014/... подвержены уязвимости (http://www.kb.cert.org/vuls/id/184540), позволяющей удалённому неаутентифицированному атакующему изменить параметры переадресации портов, получить доступ к внутренним сетевым службам на стороне клиента и организовать перехват приватного и публичного трафика путём его перенаправление на внешний хост.
Причиной возникновения уязвимости является некорректная настройка работы NAT-PMP, применяемая во многих моделях SOHO-маршрутизаторов и разных потребильских сетевых устройствах. RFC 6886 (https://tools.ietf.org/html/rfc6886), определяющий требования к реализациям NAT-PMP, запрещает принимать запросы на переадресацию портов, приходящие на внешний IP-адрес шлюза или через внешний сетевой интерфейс. Допускается только отправка запросов из внутренней (intranet) сети и их обработка на внутреннем IP (192.168.x.x, 172.16.x.x, 10.x.x.x). Многие производители устройств проигнорировали данное требование и обеспечили приём запросов на внешних сетевых интерфейсах, что в ситу простоты протокола NAT-PMP, подразумевающего, что запросы приходят только из intranet-сети, позволило любому внешнему злоумышленнику отправлять управляющие запросы на перенаправление сетевых портов.
Проблеме подвержены некоторые модели устройств от компаний ZyXEL, Netgear, ZTE, MikroTik, Ubiquiti, Technicolor, Speedifi, Radinet и Grandstream, в котрых, как правило, используется код свободного UPnP/NAT-PMP-сервера miniupnp (http://miniupnp.free.fr/). В результате сканирования глобальной сети было выявлено около 1.2 млн проблемных устройств, из которых 133 тысячи находятся в России. Из данных устройств 2.5% позволяют перехватить внутренний трафик, 86% - перехватить внешний трафик, 88% - получить доступ к сетевым службам в локальной сети, 88% - вызвать отказ в обслуживании, 100% - получить информацию об устройстве (например, сведения об IP-адресах и сетевых портах).
В качестве временного решения проблемы рекомендуется отключить в настройках поддержку NAT-PMP или ограничить на межсетевом экране доступ к UDP-порту 5351. Разработчики miniupnp уже представили несколько (https://github.com/miniupnp/miniupnp/commit/16389fda3c5313bf... изменений (https://github.com/miniupnp/miniupnp/commit/82604ec5d0a12e87... направленных на принудительный запрет приема запросов на WAN-интерфейсе и добавление в пример файла конфигурации miniupnpd.conf (https://github.com/miniupnp/miniupnp/blob/master/miniupnpd/m... примечания с советами о правильной настройке доступа (изначально, в примере запросы принимались и через интерфейс WAN, но блокировались через ACL).URL: https://community.rapid7.com/community/metasploit/blog/2014/...
Новость: http://www.opennet.ru/opennews/art.shtml?num=40922
Когда я вижу подобные новости, у меня возникает один вопрос, они вообще мозги включают (писатели, внедрятели, использователи), когда что-то делают. Это какая-то уникальная способность в наши дни - думать на пару шагов вперед??? Сам по себе NAT-PMP не защищен by design, так вы еще и открываете возможность использовать его снаружи.У Зюха железки не самые дешевые, что за быдло-кодо-сборщики там сидят...
Хотя чего я о Зюхеле, если у них, перейдя на Кинетиках с прошивки 1.Х на 2.Х, у меня сложилось впечатление, что меня за полного дауна держат, судя по интерфейсу.
> Когда я вижу подобные новости, у меня возникает один вопрос, они вообще
> мозги включают (писатели, внедрятели, использователи), когда что-то делают.Нет, за это не платят.
> меня за полного дауна держатЗа это им и платят дауны.
> за полного дауна держат, судя по интерфейсу.Не нравится? Посмотрите на openwrt, там есть печеньки. И морда где не держат за дауна. И даже конфигурационный и-фейс UCI, которым довольно удобно наруливать все из командлайна.
Ну фаервол то обычно на внешнем интерфейсе все блокирует. Не знаю где они столько уязвимых устройств нашли.
Этот протокол вообще не нужен. Зачем везде пихают, да еще и включают по дефолту?
Тем, кто только разглядывает весёлых котиков и слушает пережатую ворованую музычку в социалках - может быть...
> Тем, кто только разглядывает весёлых котиков и слушает пережатую ворованую музычку в
> социалках - может быть...Зиксели и длинки как раз для таких людей, но upnp там зачем-то вкючен
> NAT-PMP не защищен by designА как его защитить? Если юзер может прописать пароль в роутере и в ПО, использующем NAT-PMP, то ему NAT-PMP просто не нужен, ибо он с теми же усилиями может прописать на этом роутере port-forwarding, а в настройках ПО - прибить номер порта гвоздями (дать такую возможность в конфиге не сложнее, чем впихнуть NAT-PMP с паролем). Этот протокол придуман как раз для тех, у кого на это мозгов не хватает.
Можно, правда, сделать workaround - использовать тот же пароль, что и для доступа к устройству. Но тогда катастрофически повышается вероятность его спалить.
купил роутер. Подключил. Все работает.
Не ожидал что его надо сканером портов мучать (к тому же не очень это умею)
Наивные хомяки тоже думали что по стройке можно ходить в галстуке и без каски. А тут обана - какой-то лох с дватцатого этажа болт уронил...
Это не баг. Это фича (для АНБ).
А безопасность быдла никого не интересует.
Добрый день.
Знаете, Вы задали правильный вопрос. Когда-то я также задал его, когда работал в очень большой компании и видел очевидные проблемы ...знаете что мне ответил большой дядя с MBA ?: "Как мы это отразим в отчетах ? Никак. Потому - пользователи не жалуются, проблемы не существует".
От MikroTik не ожидал, это всё-таки не то же самое, что SOHO-классика...
Хаха, какая приятная досада владельцев [s]хипстероского[/s] распиаренного г, а также им сочувствющих.
А что Вы предлагаете? Какие есть альтернативы за человеческие деньги?
Вот, кстати, да, хороший вопрос.
На хороший вопрос -- хороший ответ:> There is no "best hardware", so stop asking. Purchase something that meets your requirements.
> На хороший вопрос -- хороший ответ:
>> There is no "best hardware", so stop asking. Purchase something that meets your requirements.
> http://wiki.openwrt.org/toh/buyerguideСравнивать лего, даже создатели которого неспособны назвать хотя бы 5 100% рабочих устройств, с искоробочным устройством по цене этого лего некорректно.
И все нормально там в микртике. По дефолту служба остановлена, а в службе по дефолту внешний интерфейс блокируется, + дефолтные же правила фаервола все блокируют из интернета.
> даже создатели которого неспособны назвать хотя бы 5 100% рабочих устройствНаверное, это потому что их куда больше пяти. А так же потому что OpenWRT можно запустить хоть на чайнике, в отличии от.
> с искоробочным устройством по цене этого лего некорректно
Пффф. MikroTik'и -- это как раз то, что по ссылке называют "overhyped, overpriced products".
> overpricedO RLY?
Mikrotik+FreeBSD :)))
> Mikrotik+FreeBSD :)))А оно хотя-бы загружается? А то на RouterStation уже портировали. Так портировали что девайс аж с конвеера снять успели быстрее чем появился внятный порт. Как обычно, в общем :).
В RouterOS, в общем случае, все инртерфейсы равноправны. Какой из интерфейсов WAN- решает администратор, а не ОС. В настройках UPnP есть возможность выбрать активные интерфейсы. По-умолчанию служба UPnP вообще отключена. Если криворукий админ включил ее на всех интерфейсах, не разбираясь, что и зачем он делает, это НЕ проблема вендора.Вывод: Микротик в данном конкретном случае не виноват, и мне не понятно, зачем авторы этого исследования на него бочку катят.
> В RouterOS, в общем случае, все инртерфейсы равноправны. Какой из интерфейсов WAN-
> решает администратор, а не ОС.В openwrt тоже. Это правда еще от устройства железяки зависит. Скажем железку с 5-портовым свичом можно хоть там как пилить VLANами на независимые группы, трафф между которыми - только через проц. А если у кого WAN выделенным портом - ну он выделенный порт, это на уровне подключения к процу так. Хотя свич при этом опять же можно порезать на дополнительные группы, это не совсем эквивалентно по скорости. В том плане что выделенный хардварный и-фейс - быстрее чем свич распиленый вланами, где трафф в проц пхается.
> делает, это НЕ проблема вендора.
Прикольное выгораживание микротика.
> зачем авторы этого исследования на него бочку катят.
Если находятся такие девайсы - значит и их касается.
> группы, трафф между которыми - только через проц. А если у
> кого WAN выделенным портом - ну он выделенный порт, это на
> уровне подключения к процу так. Хотя свич при этом опять же
> можно порезать на дополнительные группы, это не совсем эквивалентно по скорости.Да?
> В том плане что выделенный хардварный и-фейс - быстрее чем свичХыхы. То есть ты нам тут задвигаешь что Routing Layer 3 оказывается быстрее Layer 2/ARP по модели OSI? :)))
> распиленый вланами, где трафф в проц пхается.То есть в хардварном варианте походу "Святой Дух" свитчеванием занимается, а в случае VLAN проц?? :)))))))
Вообще, там есть 1 или несколько свичей, которые могут что-то делать без отправки в ядро (в т ч маршрутизировать между своими портами, маркировать вланы или блокировать какой-то трафик (до 30 правил фаерфола)) Это все хардварно и естественно быстрее чем программно. Они там используют термин fibre speed вроде, т е скорость ограничена только каналом.
Между свичами связь уже через ядро. ееще можно 1 свчи разбить на сколько угодно поменьше со связью через ядро, т к вланы в обычном случае и не требуются.
switch и там работают только на уровне Layer2 (VLAN тоже на этом уровне крутиться). Layer3 всегда идет через центральный проц. Выделенные интерфейсы в системе ethX (Linux) или (argeX) FreeBSD - это чисто виртуальные интерфейсы, работающие внутри switch кристалла на том-же VLAN принципе.
>> можно порезать на дополнительные группы, это не совсем эквивалентно по скорости.
> Да?Да. Если к процу от свича идет такой же гигабитный линк как остальные порты - подумайте о том что если например мы гоняем трафф между гигабитным wan и гигабитным lan - в одну сторону гигабит (потенциально дуплексный) и в другую - гигабит (дуплексный). То-есть в сумме - четыре гигабитных потока.
А проц по гигабитному может разрулить только два - на вход и выход. Так что если интерфейсы сделаны как разбивка свича вланами и и-фейс к процу с той же скоростью что и прочие - все упрется в и-фейс проца. И на дуплексном потоке проц даже чисто теоретически может лишь половинку от гигабита (в данном примере).
> Хыхы. То есть ты нам тут задвигаешь что Routing Layer 3
> оказывается быстрее Layer 2/ARP по модели OSI? :)))То-есть, я задвигаю что если к процу от свича идет такой же по скорости линк как остальные порты - упрется в скорость этого линка. В допущении что проц вообще выдюжит, например крупными пакетами и без крутых правил.
> То есть в хардварном варианте походу "Святой Дух" свитчеванием занимается, а в
> случае VLAN проц?? :)))))))Пойнт VLAN обычно в получении нескольких изолированных зон - "локалок" с пропуском траффика через проц, то-бишь, L3 роутинг + потенциально фаер и нат.
>В RouterOS, в общем случае, все инртерфейсы равноправны. Какой из интерфейсов WAN- решает администратор, а не ОС. В настройках UPnP есть возможность выбрать активные интерфейсы. По-умолчанию служба UPnP вообще отключена. Если криворукий админ включил ее на всех интерфейсах, не разбираясь, что и зачем он делает, это НЕ проблема вендора.Наглое циничное враньё человека не разбирающегося в сабже. Там применяется обыкновенный soft switch, но при этом wan идёт отдельным чипом.
>Вывод: Микротик в данном конкретном случае не виноват, и мне не понятно, зачем авторы этого исследования на него бочку катят.Микротик это такой же форк древнего wrt как и зюксель. Только микротик еще и наглые воры.
микротик микротику рознь. В ccr ты точно выделенного wan порта не найдешь
В новости нет железок аналогичных CCR.
В новости вообще не упоминаются конкретный железки, только вендоры. Операционка (RouterOS) на всех устройствах от Микротик одинаковая, только собрана для разных аппаратных платформ (каковых в настоящее время поддерживается пять). Различия в интерфейсе конфигурации и настройках по-умолчанию от железки к железке минимальны.
Ты же однозначно написал про равноправность портов, а на том же 951-м микротике это не так. А то что вечно недоделанная поделка под названием routeros везде одинаковая это я знаю.
Вы про какой именно 951й? Их три разных есть.
В любом случае, в любом из этих трёх, все 5 портов включены в один чип коммутатора, и преимуществ друг перед другом не имеют.
> Вы про какой именно 951й? Их три разных есть.
> В любом случае, в любом из этих трёх, все 5 портов включены
> в один чип коммутатора, и преимуществ друг перед другом не имеют.951ui-2hnd два разных чипа, врать не надо, это даже на их сайте написано, что там только WAN.
Я такой информации не нашел, дайте ссылку, пожалуйста.
Только прошу учесть, что то, что там первый порт поддерживает PoE-in, а пятый- PoE-out не может быть индикатором того, что эти порты как-то по-особому подключены к чипу коммутатора или к CPU. Тем более, что там не настоящий PoE, а примитивный вариант ни с чем, кроме самого Микротика не совместимый.
> Я такой информации не нашел, дайте ссылку, пожалуйста.Нашел, не нужно ссылок. Я был прав, Вы- нет.
Читать здесь: http://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features#In...
В табличке находим:RouterBoard: RB951Ui-2HnD
Switch-chip description: Atheros8227 (ether1-ether5)То есть 5 из 5 портов подключены к switch-chip-у, даже модель указана.
> Наглое циничное враньё человека не разбирающегося в сабже. Там применяется обыкновенный soft switch, но при этом wan идёт отдельным чипом.Зато Вы, видимо, эксперт.
Начнем с того, что "soft switch"- это устоявшийся термин из области VoIP. Что такое "soft switch" применительно к сетям передачи данных мне не ведомо.
Во-вторых, вы о какой конкретно железке?
Во всех без исключения ныне выпускаемых SOHO-моделях все порты физически включены в один коммутатор, и в общем случае равноправны (исключение- серия 2011, в которой установлено сразу 2 коммутатора, но и здесь все порты, включая SFP, физически подключены к одному из них). Снаружи порты просто пронумерованы, ни один из них даже цветом не выделен, как WAN. В настройках по-умолчанию, как правило, первый порт не входит ни в одну из "switch-group", и по-факту используется как WAN, но это легко можно изменить, что очень часто и происходит на практике (несколько напримеров, когда это необходимо: (1) Mlti-WAN; (2) на 2011 с SFP иногда именно SFP используется как WAN; (3) на том же 2011 зачастую есть смысл использоваться для WAN 100-мегабитный порт [один из 6 по 10], а не гигабитный [гигабитные- с 1 по 5]).
В серии CCR аппаратный коммутатор вообще отсутствует, и все порты имеют непосредственную связь в CPU (учитывая, что самое дешевое устройство из этой серии имеет на борту 9-ядерный CPU, программный бридж работает достаточно быстро, чтобы в отдельном аппаратном коммутаторе не было необходимости).
Серия CRS- это вообще в первую очередь управляемый коммутатор. Здесь также все 8 или 24 порта (в зависимости от модели) не имеют прямой связи с CPU, и в общем случае равноправны.
Также есть модели, в которых всего от 1 до 3 портов, и коммутатор отсутствует.
Единственная модель, в которой один порт как-то сильно отличается от всех остальных- это 450G, в которой первый порт гибридный, и в зависимости от настроек ПО, подключен либо к коммутатору, либо непосредственно к CPU. Вот только 450G уж точно не для SOHO-рынка предназначен.
Так же еще раз повторюсь, что UPnP по-умолчанию отключен, через QuickSet (админка для даунов) не включается, и требует явного указания активных портов в настройках.
> Микротик это такой же форк древнего wrt как и зюксель.
Эм... Я ничего не знаю про "зюксель", однако... Первый коммит в репозитории OpenWRT датирован 28 марта 2004 года. Первая версия RouterOS была выпущена в 1997 году, а в 2002 году Микротик начал выпускать железо под собственным брэндом.
>Начнем с того, что "soft switch"- это устоявшийся термин из области VoIP. Что такое "soft switch" применительно к сетям передачи данных мне не ведомо.Коммутатор на одном чипе, порты разделены вланами. А вот wan там как раз отдельным чипом.
>CCR, CRS
Вообще-то в новостях написано про soho железки, если вы не заметили.
>Эм... Я ничего не знаю про "зюксель", однако... Первый коммит в репозитории OpenWRT датирован 28 марта 2004 года. Первая версия RouterOS была выпущена в 1997 году, а в 2002 году Микротик начал выпускать железо под собственным брэндом.
unpacknpk.py вам в руки. И любуйтесь украденным. Но что характерно бизибокс они не положили, предпочли bash, наглые и трусливые воришки.
> Вообще-то в новостях написано про soho железки, если вы не заметили.Повторюсь.
В новости вообще не упоминаются конкретный железки, только вендоры. Операционка (RouterOS) на всех устройствах от Микротик одинаковая, только собрана для разных аппаратных платформ (каковых в настоящее время поддерживается пять). Различия в интерфейсе конфигурации и настройках по-умолчанию от железки к железке минимальны.
> unpacknpk.py вам в руки. И любуйтесь украденным. Но что характерно бизибокс они не положили, предпочли bash, наглые и трусливые воришки.
В 6.20 именно BusyBox. Bash-ем там "и не пахнет". Лично проверял несколько недель назад (в процессе вот этого обсуждения: http://forum.mikrotik.com/viewtopic.php?f=2&t=89528).
> В 6.20 именно BusyBox. Bash-ем там "и не пахнет". Лично проверял несколько
> недель назад (в процессе вот этого обсуждения: http://forum.mikrotik.com/viewtopic.php?f=2&t=89528).А ну да пардон, ash это бизибокс. Что еще упоротей с их стороны.
Не надоело позориться? Поучи матчасть, а потом уже лезь в разговор к умным людям.
Спасибо за подборку информации, а то уж глаза округляться начали от этого троля.
> не то же самое, что SOHO-классика...Это обычное хомяковое железо, чаще всего атерос, на котором запустили опаскуженный вариант дебиана. Почему опаскуженный? А потому что сделать дебиан какой-то полупроприетарной системой на которую сорц получить гемор - редкое паскудство.
>полупроприетарной100% проприентарной. С невозможностью делать сторонними модулями и подписями прошивок. Благо там tftp есть и устройства прошиваются в нужный тебе девайс.
> 100% проприентарной.Ну там вроде можно сорц запросить. Но без бинарных компонентов и максимально геморно. Уродская фирмочка, скажем прямо. В том плане что пересобрать их мегакостылище малой кровью не получится. Что впрочем к лучшему.
> Благо там tftp есть и устройства прошиваются в нужный тебе девайс.
Да бэкдорнутая система по сути. Какими-то лицензиями еще барыжат, куча фаготов. И кстати там проприетарный бутлоадер. Вообще-то с таким не поздравляют - а ты его код проверял? А то мало ли что он окромя tftp умеет...
> Это обычное хомяковое железо, чаще всего атерос, на котором запустили опаскуженный вариант дебиана.Очень разное железо (в том числе и "обычное хомяковое").
И что дает Вам основания утверждать, что RouterOS- это вариант Debian?
> Очень разное железо (в том числе и "обычное хомяковое").
> И что дает Вам основания утверждать, что RouterOS- это вариант Debian?Вы абсолютно не понимаете откуда идут корни wrt, routeros и emdebian. Это наглые циничные воришки, которые еще умудряются утверждать, что routeros их разработка.
> Вы абсолютно не понимаете откуда идут корни wrt, routeros и emdebian.Проверяйте источники, уважаемый. История Embedian началась в 200 году (пруф: http://www.emdebian.org/about/history.html), а первая версия RouterOS, как я уже писал, увидела свет в 1997.
> История Embedian началась в 200 годуПардон, опечатался. Имелось в виду в 2000 (двухтысячном), конечно же.
>> Вы абсолютно не понимаете откуда идут корни wrt, routeros и emdebian.
> Проверяйте источники, уважаемый. История Embedian началась в 200 году (пруф: http://www.emdebian.org/about/history.html),
> а первая версия RouterOS, как я уже писал, увидела свет в
> 1997.Ага, и uclibc случайно 2010 года там оказался? Только сейчас вы скажете "вы всё врети"! Ведь роутерос возникла раньше чем uclibc!
Таким образом мы в очередной раз убеждаемся, что роутеры д-линк защищены лучше, чем какой-то непонятный мокротык
> Таким образом мы в очередной раз убеждаемся, что роутеры д-линк защищены лучше,
> чем какой-то непонятный мокротыкСравнили, блин, одно - навоз, другое - гуано. Разница, панимаишь!
Ну так, любит народ разбираться в сортах ;]
> Таким образом мы в очередной раз убеждаемся,
> что роутеры д-линк защищены лучше,
> чем какой-то непонятный мокротыкНу да, у микротик защиты от дурака нет, он вообще не для них рассчитан. Напоминает новости о "взломах" линукс-прошивок, когда просканили сеть и нашли десятки тысяч роутеров с дефолтными паролями.
MikroTik проблеме не подвержен!!! читайте внимательно оригинал!"MikroTik Not affected"
Онлайн сканер портов пишет, что 5351 закрыт. Значит у меня всё нормуль?
nmap -sU -p5351 127.0.0.1
> nmap -sU -p5351 127.0.0.1Сканить нмапом локалхост - это конечно очень показательно :).
а ты хотел что бы я тебе свой айпи оставил?
я надеялся на твою смекалку, что ты сам удаленно просканишь сам себя
> nmap -sU -p5351 127.0.0.1Мусье сидит с роутера?
> Онлайн сканер портов пишет, что 5351 закрыт. Значит у меня всё нормуль?UPnP отключать сразу и навсегда. Тянет это за собой, правда проблемы с NAT Traversal, особенно для SIP девайсов, достаточно потом гимморно заставить их работать - но думаю безопасность дороже.
> UPnP отключать сразу и навсегда. Тянет это за собой, правда проблемы с
> NAT Traversal, особенно для SIP девайсов, достаточно потом гимморно заставить их
> работать - но думаю безопасность дороже.В Linphone, емнип, номер порта для голоса можно задать руками, а на роутере - статичнвый форвардинг.
>> UPnP отключать сразу и навсегда. Тянет это за собой, правда проблемы с
>> NAT Traversal, особенно для SIP девайсов, достаточно потом гимморно заставить их
>> работать - но думаю безопасность дороже.
> В Linphone, емнип, номер порта для голоса можно задать руками, а на
> роутере - статичнвый форвардинг.Ну ты не мне это объясняй, а домохозяйке какой-нибудь :)
openwrt данная проблема не затрагивает )))
> openwrt данная проблема не затрагивает )))Поди его и не проверяли т к неуловимый.
Лезть со своими перешитыми длинками и говорить, что у вас надежное устройство корп класса... Утомили уже...
>> openwrt данная проблема не затрагивает )))
> Поди его и не проверяли т к неуловимый.
> Лезть со своими перешитыми длинками и говорить, что у вас надежное устройство
> корп класса... Утомили уже...кастомные прошивки, собранные с "любовью" под себя каким нибудь спецом НА 10 ПОРЯДКОВ надежнее рядовых поделок от производителей оборудования.
Или ты щас будешь говорить что спец, собирая под себя прошивку, гадить туда чтоли будет???
>> openwrt данная проблема не затрагивает )))
> Поди его и не проверяли т к неуловимый.
> Лезть со своими перешитыми длинками и говорить, что у вас надежное устройство
> корп класса... Утомили уже...Да тут в сабже вообще ни одного устройства корп класса нет. Зачем ты его приплел?
> openwrt данная проблема не затрагивает )))Всех затрагивает. И openWrt с включенным UPnP
Неа :) Там оно по умолчанию только в lan светится.
В RouterOS оно по-умолчанию вообще нигде не светится, тем не менее это не помешало Вам развести полемику на пару десятков сообщений о том, что кривые руки админов- это проблема вендора. Двойные стандарты, не находите?
А теперь ссылку мой дорогой друк.
Прошу: http://wiki.mikrotik.com/wiki/Manual:IP/UPnPSub-menu: /ip upnp
...
enabled (yes | no ; Default: no)По-умолчанию выключено. Это раз.
Ссылку про то что я устроил полемику по upnp.
Ещё часто вешают на 49152Проброс портов добавляется так:
POST /upnp/control/WANIPConn1 HTTP/1.1
HOST: 192.168.1.254:49152
CONTENT-LENGTH: 610
CONTENT-TYPE: text/xml; charset="utf-8"
SOAPACTION: "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping"<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
<NewPortMappingDescription>DESCR</NewPortMappingDescription>
<NewLeaseDuration>0</NewLeaseDuration>
<NewInternalClient>192.168.1.18</NewInternalClient>
<NewEnabled>1</NewEnabled>
<NewExternalPort>20003</NewExternalPort>
<NewRemoteHost></NewRemoteHost>
<NewProtocol>TCP</NewProtocol>
<NewInternalPort>3389</NewInternalPort>
</u:AddPortMapping>
</s:Body>
</s:Envelope>Там ещё есть xml файл со всякой инфой о девайсе.
В логах:
Oct 25 01:04:36 miniupnpd[236]: SSDP packet sender 198.23.193.50:43272 not from a LAN, ignoring
Никто не подскажет ссылочку на список подверженных устройств? Конкретно меня интересуют Grandstream-ы.
Такая дыра, явно заказного характера.
Раз зделали значит комуто сильно надо было сию фичу...
Дыру запатчили раньше чем статью успели перевести )) https://github.com/miniupnp/miniupnp/commit/16389fda3c5313bf...