1. Главная страница » Компьютеры » Nat pmp что это

Nat pmp что это

Автор: | 16.12.2019

Ранее я много раз слышал, что 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) и номер внешнего порта, не указывая остальные параметры.

Содержание статьи

Снифим трафик с роутера Cisco

Продолжим тему, которая не влезла полностью в прошлый выпуск нашего хакбука :). Тогда мы обсуждали тему постэксплуатации в случае захвата контроля над Cisco роутером или свичем, а конкретнее — возможность снифа трафика, проходящего через сетевой девайс. Ведь у нас получается реальный man-in-the-middle, так как трафик естественным образом проходит через устройство.

В тот раз мы использовали фичу роутера Embedded Packet Capture, которая позволяла нам сохранять пакеты. Способ это действенный и гибкий (можно тонко настроить, что снифать), но имеет большой недостаток для нас — объем памяти девайса. Насколько мне нагуглилось, это в среднем от 128 Мб до 2–4 Гб. Для целей тестирования при точном фильтре этого может и хватить, но для «боевых условий» уже вряд ли. Для решения этой проблемы мы можем использовать другую фичу — зеркалирование трафика (port mirroring, port monitoring), когда весь трафик, приходящий на один сетевой интерфейс оборудования, в неизмененном виде отправляется на другой порт.

Изначально эта возможность идет от свичей (у которых портов обычно много), но это организовать можно и на роутере (даже если у него один физический порт), перекидывая трафик в какой-то VLAN например. При этом роутер оставляет данные IP-уровня и выше в неизменном виде, а вот данные канального уровня меняет, так как должен указать MAC-адрес устройства, которое уже будет «принимать» трафик.

Читайте также:  Darkest dungeon обзор на русском

Итак, как же нам это реализовать на практике? Возможность эта в роутерах Cisco называется IP Traffic export и доступна с версии IOS 12.3(4)T. Для ее реализации нам потребуется такая последовательность команд:

Входим в конфигурационный режим:

Создаем профиль с именем TestFF для экспорта трафика:

Указываем, какой трафик экспортировать (весь — bidirectianal, входящий, исходящий):

Далее — интерфейс, куда экспортируем:

И последнее, что нужно для профиля, — MAC-адрес устройства, куда отправлять трафик:

Выходим из конфигурации профиля:

Задаем, на каких интерфейсах мы хотим слушать трафик, следующими двумя командам. Сначала выбираем интерфейс:

Назначаем созданный профиль:

В примере мы весь трафик с интерфейса fastEthernet 1/0 перекидываем на fastEthernet 0/0. При этом наш хост, где мы уже фактически будем снифать трафик, может быть не напрямую подсоединен к fastEthernet 0/0, а через свичи, то есть главное — быть в одном сетевом сегменте. Достигается это за счет того, что роутер как раз подменяет канальный уровень, указывая в поле назначения наш MAC-адрес, который уже нормально обрабатывают промежуточные свичи. В качестве MAC-адреса отправителя роутер указывает свой (выходного интерфейса).

Чтобы остановить сниф, необходимо повторить последние две команды в режиме конфигурации, но уже с отключением экспорта (надо добавить no в начале):

Посмотреть статистику по экспорту можно командой

Кроме того, этой же возможностью, IP Traffic export, можно экспортировать трафик в NVRAM роутера, то есть аналогично EPC.

И в конце хочу предупредить, что с этим способом необходимо быть осторожнее, так как, во-первых, экспорт затрачивает некоторое количество ресурсов CPU у роутера, а во-вторых, если мы будем экспортировать весь трафик с гигабитного интерфейса на 100-мегабитный, то может возникнуть коллапс :).

Пример конфига при экспорте трафика с FF 1/0 на FF 0/0

Хакер #196. Все о Docker

Снифим трафик с Cisco-свича

Теперь немножко о свичах. Как было уже сказано, зеркалирование трафика — это возможность, изначально свойственная именно свичам. Официальное название — SPAN (Switched Port Analyzer). Но здесь, хотя суть та же (трафик с одного интерфейса перекидывается на другой), реализуется это иначе. Свич не производит никаких подмен значений заголовков ни канального, ни сетевого, ни других уровней в пакетах. Они в неизмененном виде копируются на еще один сетевой интерфейс.

В SPAN есть два основных термина: source — интерфейсы, откуда копируется трафик, и destination — куда копируется трафик.

Реализуется это такой последовательностью:

Входим в конфигурационный режим:

Указываем, какой откуда трафик прослушивать:

Указываем, куда его пересылать:

Здесь также указан номер сессии. Он используется для группировки source и destination, что позволяет нам прослушивать сразу несколько портов.

Вполне просто, согласись?

Но метод этот имеет несколько ограничений. Во-первых, необходимо быть физически подключенным к свичу, что не всегда возможно. Во-вторых, интерфейс, указанный как destination, перестает работать как обычный порт, то есть обрабатывать входящий / исходящий от нас легитимный трафик. И если мы захватили контроль над ним через SSH например, то включи мы зеркалирование трафика на интерфейс — сразу потеряем контроль. Хотя надо признаться, что из-за отсутствия достойного свича проверить второй пункт нет возможности.

В любом случае решением обеих проблем может быть технология RSPAN (Remote SPAN) или ERSPAN (Encapsulated Remote SPAN). Первая из них позволяет копировать весь трафик в специальный VLAN (то есть мы уже можем быть в одном сетевом сегменте, а не подключенными напрямую). Вторая за счет инкапсуляции трафика позволяет передавать данные и между сетями (L3). Ни с той, ни с другой я дел не имел, так что если поломаешь какой-то свич и получится что-то заюзать, то буду рад услышать :).

Кстати, последние несколько номеров мы обсуждали различные атаки на Cisco-девайсы, так что если хочешь поиграться/потестировать их, то можно это сделать, даже не обладая реальным устройством. Все, что тебе понадобится, — это тулза GNS3, представляющая собой эмулятор для некоторых версий роутеров цисочек, а также файрволов (ASA, PIX). Она бесплатная, так что нужно лишь найти прошивок (в Гугле).

Обходим ограничения с IP Source Routing

Существует достаточно интересная сетевая атака, которая позволяет нам обходить различные ограничения. Например, фильтрацию по IP-адресу для доступа к какому-то хосту. Основная ее фишка заключается в том, что она основана на «естественном поведении» хостов, которое вытекает из стандарта TCP/IP (RFC791). То есть это не проблема конкретной имплементации или проблема дизайна, а иное использование вполне безопасной с виду возможности — IP Source Routing. А мы такое ведь очень любим! К сожалению, скажу сразу, что атаку эту мало где можно сейчас применить, так как в большинстве ОС IP Source Routing отключено по умолчанию.

Но обо всем по порядку. Есть протокол IP, и изначально в него как раз была добавлена эта возможность (Source Routing). Суть ее заключается в том, что хост — отправитель пакета имеет возможность в заголовках IP-датаграммы указать, через какие хопы (конечные хосты, сетевое оборудование) этот пакет и ответ на него должны пройти. Да-да, мы можем указывать перечень устройств в пути пакета, то есть мы как бы «маршрутизируем» его.

Причем различаются два вида Source Routing: Strict и Loose. Первый — точное указание последовательности хостов (именно и только через них должен пройти пакет), второй — просто перечень хостов, через которые пакет должен пройти, то есть между этими хостами могут быть какие-то еще. Первый вид «изначально» практически не использовался, а вот второй до сих пор номинально жив. Максимальное количество хопов — девять. Практически эта возможность была задумана во многом для тестирования проблем в сети, чтобы мы со своего хоста могли проверить различные маршруты.

Окей, а теперь посмотрим на примерчике (взятом с www.enclaveforensics.com), как же мы можем это использовать в своих целях (см. скриншот).

Подключаемся к Alice от имени Bob’а

Итак, у нас есть (упрощенно): Alice и Bob, у которых «доверительные» отношения. Например, c IP Bob’а можно без аутентификации подключаться по Telnet’у к Alice. Есть Ivan — просто хост в сети (принтер, сетевой девайс), у которого есть доступ в сеть Bob и Alice. Мы — Eddie и наш роутер — Lynksys (который на деле не очень и нужен). Задача — подключиться к Alice от IP Bob’а, в обход ограничений на доступ из нашей сети.

Читайте также:  Cambridge audio cxa80 отзывы

Как я думаю, ясно, по сути, мы можем указать IP Bob’a и отправить пакет Alice, но проблема в том, что Telnet — это TCP, а значит, «трехступенчатое рукопожатие», и значит, что Alice напрямую ответит Bob’у и подключения мы не получим. А вот с использованием Loose Source Routing — сможем. Для этого мы делаем такую последовательность:

  1. Отправляем пакет Alice с указанием в IP отправителя — Bob’а, а также IP-адреса Lynksys’а и Ivan’a в Source Routing.
  2. Пакет проходит через Lynsys, а потом через Ivan’a. При этом пакет обходит ограничения, которые наложены на нас
  3. Alice получает наш SYN-пакет, отвечает на него как для Bob’а, но так как у входящего пакета стоит Source Routing, то отвечает Bob’у с тем же списком. То есть пакет к Bob’у должен пройти опять через Ivan’а и наш LynkSys.
  4. И все бы дошло до Bob’а, да на нашем LynkSys’е мы пакет пересылаем на наш хост.

Таким образом, Alice отвечает Bob’у, а так как пакет для этого должен пройти через нас, то мы имеем возможность «поздороваться по TCP-шному» и получить такой для нас желанный безаутентификационный доступ на Alice.

Если же говорить о практической стороне, то попробовать ты можешь, используя тулзу ncat (которая идет в комплекте с nmap). Тебе понадобится параметр –g. Пример смотри на картинке (необходимо насильно указывать протокол IPv4, так что 4 тоже в параметрах).

Как уже писалось, современные стационарные ОС и сетевое оборудование по умолчанию отбрасывают такие пакеты. Но вроде старые цисочки, SOHO-роутеры, embedded-девайсы и всякие штуки типа сетевых принтеров все еще могут поддерживать IP Source Routing.

TCP-SYN на yandex.ru c LSR через два хоста

Сравниваем папки и файлы в Meld

Давай притворимся, что это раздел X-Tools :).

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

Сравниваем директории. В один клик сравниваем измененные файлы

Конечно, есть профессионально заточенные тулзы для данных дел, да и во многих nix’ах изначально есть «встроенные» возможности. Но меня недавно познакомили с отличной тулзой, и я бы хотел этим поделиться. Название ее — Meld.

К ее достоинствам можно отнести кросс-платформенность (написана она на Python и GTK) и с приятным простым интерфейсом. Что и надо для первичного поверхностного анализа.

Сравниваем два файла. Изменения красиво подсвечены 🙂

Атакуем роутеры через NAT-PMP

И еще одна задачка про сети и сетевые атаки. Да-да! А то все веб да веб.

Относительно недавно появилась (стандартом стала вроде в 2013 году) новая технология — NAT PMP (NAT Port Mapping Protocol). Если в общем, то она используется для автоматического проброса портов, в основном на SOHO-роутерах. Казалось бы, кто ей будет пользоваться? Ан нет, продвигает ее компания Apple, и это как бы говорит нам о том, что поддержка будет только расти. А потому умение «ломать» такие девайсы представляет приличный интерес, особенно оттого, что уязвимости, связанные с NAT-PMP, в основном конфигурационные (а значит, вряд ли будут «пропатчены»).

Но что-то я разошелся. Давай по порядку и с начала.

Вот есть весь диапазон IPv4-адресов. Он меньше, чем общее количество всех сетевых устройств. Да даже если бы и выдать каждому по одному — это была бы неуправляемая каша. Поэтому достаточно давно выделили ряд диапазонов приватных/«серых» IP-адресов. Обычные же адреса называются публичными/«белыми».

Теперь представим себе, что ты сидишь дома с ноутом и смартфоном, у тебя есть Wi-Fi-роутер, все подключено к интернету. Представим, что у Wi-Fi-роутера есть «белый» IP (66.55.44.33), который ему назначил твой провайдер. Твой же ноут имеет IP-адрес из приватной сети, 192.168.0.123 например, а смартфон — 192.168.0.56. И ты хочешь подключиться к хосту 8.8.8.8 (белый IP). Но подключиться «напрямую» со своего серого IP не получится, 8.8.8.8 не сумеет отправить тебе ответ. Но ты же можешь отправить пакет через свой роутер (у него-то есть белый IP, и пакет вернется от 8.8.8.8 к нему). Но как же сделать, чтобы мы отправили пакет через роутер от IP роутера и при этом ответ бы пришел через роутер к нам? И здесь нам поможет NAT (Network Address Translation). Вообще, есть несколько видов NAT’а, но мы коснемся только конфигурации many-to-one (самой распространенной).

Итак, когда ты с ноута отправляешь запрос на 8.8.8.8, роутер получает Наш пакет (так как он стоит шлюзом по умолчанию у тебя на ноуте), видит, что запрос идет во внешнюю сеть, после через начинается процесс NAT’а:

  1. Роутер запоминает, с какого IP-адреса (192.168.0.123) и порта (1234) пришел запрос от тебя.
  2. Меняет в твоем пакете IP-адрес отправителя на свой публичный (66.55.44.33) и порт отправителя на свой незанятый внешний порт (5678).
  3. Запоминает это соотношение: 192.168.0.123:1234 = 66.55.44.33:5678
  4. Получив ответ от 8.8.8.8, роутер проверяет порт (5678), на который пришел запрос, и видит, что это соотношение сохранено у него.
  5. Роутер проводит обратное изменение: в IP-адрес назначения указывает 192.168.0.123, а в порт — 1234 и отправляет пакет на ноут.

Таким образом, для твоего ноута эти преобразования остаются незамеченными.

При этом твой смартфон также может ходить в интернет, и последовательность преобразований будет такой же. Разница лишь в том, что роутер выделит другой внешний порт для подключения со смартфона. То есть NAT-таблица будет выглядеть примерно так:

В зависимости от порта, куда придет пакет с ответом, он будет переслан на тот или иной хост. Кстати, именно поэтому такой вид NAT’а называется еще Port Address Translation. Все вполне просто.

Но NAT решает одну проблему — подключение из серого диапазона в белый. Снаружи (из интернета) практически нет возможности подключиться к какому-то сервису на твоем ноутбуке. Решение этой задачи — проброс портов. Мы можем указать на роутере, что все подключения, приходящие на 66.55.44.33 на порт 7777, должны быть перекинуты на веб-сервер на ноуте 192.168.0.123:80. При этом роутер выполняет почти аналогичную операцию: подменяет в пакете IP назначения со своего внешнего на 192.168.0.123 и порт назначения с 7777 на 80. Ответные пакеты от нашего веб-сервера подвергаются обратному изменению.

Читайте также:  Palit geforce gtx 770 jetstream 4gb

Окей. Проброс портов — отличное решение. И я думаю, все современные роутеры позволяют настраивать его ручками через админку. Но полагаю, среднестатистический пользователь вряд ли знает, что такое порт или где у роутера админка. С другой стороны, многие сервисы, типа файлообмена или игр, требуют возможности внешних подключений.

Решением будет автоматический проброс портов, когда приложение на твоем ноуте само попросит роутер пробросить для него такой-то порт и роутер выполнит его желание. Для этого может быть использован протокол (точнее, набор протоколов) UPnP. Там есть расширение Internet Gateway Device (IGD), которое создано специально для управления пробросом портов.

Не знаю, с чем точно были связаны потребности Apple в новом протоколе для замены UPnP IGD. Возможно, дело в том, что он был чересчур универсальный, а потому очень толстый (настройка происходит через три подключения к различным портам). К тому же в нем были найдены пучки уязвимостей (переполняшки), о чем тут некогда писалось. Но в любом случае Apple создала новый протокол и поддерживает его в большинстве своих современных продуктов (насколько мне известно).

Главная его черта — простота. Используется UPD-порт 5351 для общения. Протокол бинарный. Никакой аутентификации не предусмотрено. И содержит, по сути, две команды (на деле чуть больше): пробрасывай данные с такого-то порта на такой-то хост и порт, скажи свой внешний IP-адрес.

Примерный, упрощенный алгоритм такой:

  1. Приложение ноута отправляет запрос на роутер «Пробрасывай TCP-порт 80 с внешнего интерфейса на 192.168.0.123 на 80».
  2. Если внешний порт 80 не занят, то роутер ответит, что данные будут пересылаться с 80-го порта на 192.168.0.123 на 80.
  3. Если внешний порт 80 занят, то роутер подставит какой-то свободный порт и ответит, что данные будут пересылаться с 4444-го порта на 192.168.0.123 на 80.
  4. Приложение с ноута запрашивает, какой внешний IP у роутера.
  5. Роутер отвечает со своим внешним IP-адресом 66.55.44.33.
  6. Приложение с ноута теперь знает, что коннекты на 66.55.44.33: 4444 будут приходить именно ему, и может «опубликовать» эти данные где-то в сети.

Казалось бы, что тут такого может случиться? Что тут вообще ломать, в особенности если ты находишься во внешней сети (интернете) и хочешь атаковать пользователей, находящихся за роутером?

Ребятки из Rapid7 провели интересную работу на эту тему и выявили ряд проблем. Основная была связана с некорректной настройкой конечных девайсов (роутеров). По стандарту, запросы NAT-PMP должны обрабатываться, когда они приходят с внутреннего диапазона, но на многих девайсах разрешена конфигурация и с WAN-интерфейса (то есть из сети Интернет). Данная и некоторые другие тонкости дают возможность для атак. Причем тут важно знать, что во многом это не проблемы конечных пользователей, а некорректная настройка из коробки, от вендоров роутеров. В итоге Rapid7 обнаружила в интернете порядка миллиона по-разному уязвимых устройств. Заметь, это было сканирование интернета, а если вспомнить, что очень многие пользователи находятся за NAT’ом от провайдеров, то число может возрасти в разы (правда, для атаки на них необходимо быть подключенными к данному провайдеру).

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

Перехват внутреннего трафика

Мы отправляем на внешний интерфейс на NAT-PMP запрос, чтобы весь входящий внутренний трафик такой-то порт был «проброшен» нам. То есть мы можем заставить роутер пересылать нам данные, приходящие на какой-то из внутренних портов его самого. А что это может быть? Во-первых, админка: порты 23, 22, 80, 443. Поднимаем у себя веб-сервер и снифаем креды. Но еще интересней захват DNS-запросов. Ведь роутеры очень часто используются как DNS-сервер, а тут мы такие взяли и указали проброс запросов себе. В итоге поднимаем поддельный DNS-сервак и имеем отличную возможность для различных MITM-атак.

Перехват внешнего трафика

Практически аналогичная атака. Но тут мы заставляем роутер перебрасывать все входящие подключения на внешний интерфейс роутера на наш хост.

Интересность данного варианта сильно зависит от ситуации.

Доступ к внутренний хостам (за NAT’ом)

Так как на самом деле в самом запросе к NAT-PMP мы не указываем IP-адрес, куда пересылать данные, а NAT-PMP берет эти данные из поля IP-адреса отправителя запроса, то мы можем за счет подмены адреса отправителя на внутренний адрес какого-то хоста за NAT’ом получать доступ к его сервисам. Например, мы из интернета можем послать NAT-PMP запрос от IP 192.168.0.123 на 445/TCP-порт на создание проброса и получить возможность сетевого доступа к 192.168.0.123 через SMB-протокол.

И последние три маленьких: возможность сканирования портов роутера без их сканирования (за счет различных ответов на закрытые/открытые порты), раскрытие внутреннего IP-адреса и DoS (за счет занятия всех портов). Мне кажется, что выглядит это впечатляюще. Но в реале подводных камней много.

Что еще приятно, в Metasploit’е теперь есть соответствующие модули для атак на сервисы NAT-PMP:

  • NAT-PMP Port Mapper (auxiliary/admin/natpmp/natpmp_map) — для проброса портов;
  • NAT-PMP External Port Scanner(auxiliary/scanner/natpmp/natpmp_portscan) — для сканирования портов;
  • NAT-PMP External Address Scanner (auxiliary/gather/natpmp_external_address) — для получения IP-адреса роутера.

Спасибо за внимание и успешных познаний нового!

Nat pmp что это

Автор Minato Nanikaze задал вопрос в разделе Другие языки и технологии

что такое NAT-PMP и UPnP и получил лучший ответ

Ответ от Апельсин[гуру]
Исправить просто, нужно в настройках роутера разрешить эти опции, либо сделать проброс порта. Возможно порт закрыт провайдером и вам нужен будет внешний белый айпи.
UPnP — Universal plug and play — набор протоколов позволяющий без лишних копаний в настройках получить рабочую систему, дословно подключи и играй!
NAT-PMP — Network Address Translation Port Mapping Protocol — сетевой протокол, обеспечивающий правильную работу совместимых программ во внутренних локальных сетях, по сути тот же проброс портов.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *