OSX mDNSResponder открывает все порты на миллиард

Question

Недавно я поменял свой маршрутизатор на 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.)

У кого-нибудь есть другие предложения?

Answer 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 всегда создает и отправляет фактические пакеты запроса сопоставления портов.