OSX mDNSResponder открывает все порты на миллиард
Недавно я поменял свой маршрутизатор на Billion 7800VDOX и заметил некоторые попытки подключения к моему iMac с внешних адресов. В ходе расследования я обнаружил, что порт uPnP был открыт на маршрутизаторе с диапазоном портов 0–0 (внутренний и внешний). Это дает эффект, проверенный с помощью сканера внешних портов, открытия ВСЕХ номеров портов на маршрутизаторе и направления их IMAC. Я удалил сопоставление, запустил Wireshark и получил запрос на внешний адрес одновременно с восстановлением сопоставления.
Frame 496: 102 bytes on wire (816 bits), 102 bytes captured (816 bits) on interface 0
Ethernet II, Src: Apple_d0:7e:eb (d4:9a:20:d0:7e:eb), Dst: BillionE_cb:49:27 (00:04:ed:cb:49:27)
Internet Protocol Version 4, Src: 192.168.1.131, Dst: 192.168.1.254
User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5351 (5351)
Source Port: 5353
Destination Port: 5351
Length: 68
Checksum: 0x8527 [validation disabled]
[Stream index: 0]
Port Control Protocol, Map Request
Version: 2
0... .... = R: Request
.000 0001 = Opcode: Map (1)
Reserved: 0
Requested Lifetime: 7200
Client IP Address: ::ffff:192.168.1.131
Map Request
Mapping Nonce: f88237920f8cd6c0a3765f39
Protocol: 6
Reserved: 0
Internal Port: 9
Suggested External Port: 0
Suggested External IP Address: ::ffff:xxx.181.81.112
Этому предшествовал запрос SOAP для получения внешнего IP-адреса маршрутизатора. Проверяя порт источника (5353) с помощью lsof, я обнаружил, что он принадлежит mDNSResponder.
Мое предположение относительно того, что происходит, заключается в том, что mDNSResponder использует это только для того, чтобы получить внешний IP-адрес маршрутизатора, и делает это с помощью предположительно безвредного запроса для сопоставления порта 0, который должен быть недопустимым портом. Однако маршрутизатор Billion рассматривает это, как из-за ошибки проектирования или программирования, как запрос на открытие всех портов. Отключение uPnP на маршрутизаторе решает проблему (хотя, как уже указывалось, на самом деле это не uPnP.)
У кого-нибудь есть другие предложения?
1 ответ
Захваченный пакет показывает запрос на сопоставление портов протокола управления портом (PCP: преемник IETF для отслеживания стандартов для NAT-PMP). Порт клиента для запрошенного сопоставления - 9/TCP. У клиента нет предложений относительно того, каким должен быть внешний порт, поэтому он оставляет поле предлагаемого внешнего порта равным нулю. IETF RFC 6887, который определяет PCP, ясно дает понять, что ноль означает "нет предложений" в этой области.
Я думаю, кто бы ни внедрил PCP для этого маршрутизатора Billion, он неправильно понял RFC. Видите ли, в некоторых очень ограниченных и четко определенных случаях ноль в поле ДРУГОЙ порт может означать "все порты". Например, когда Запрошенное время жизни для этого запроса на сопоставление равно нулю, нулевой клиентский порт будет означать "удалить все сопоставления для всех портов на этом IP-адресе клиента".
Но опять же, в предлагаемом поле внешнего порта ноль всегда должен означать "нет предложения". Никогда не должно означать "все порты" в этой области.
Таким образом, кажется довольно ясно, что вы нашли ошибку PCP в этом маршрутизаторе Billion.
Еще одна странная вещь - это клиентский порт. Традиционно 9 / TCP является discard порт службы, но discard служба устарела, поэтому я не уверен, кто ее запустит или почему что-то будет запрашивать сопоставление портов для него.
Что касается того, почему mDNSResponder отправляет эти запросы, это просто потому, что mDNSResponder действует как демон PCP/NAT-PMP/UPnP на macOS в дополнение к своим обычным обязанностям mDNS, DNS-SD и DNS resolver. Когда какой-либо процесс в macOS запускает систему для запроса сопоставления портов от маршрутизатора, mDNSResponder всегда создает и отправляет фактические пакеты запроса сопоставления портов.