☰

OSX mDNSResponder открывает все порты на Billion

tag-icon • tag-icon router port-forwarding nat osx-mavericks billion
OSX mDNSResponder открывает все порты на Billion

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

Перехваченный вами пакет показывает запрос сопоставления порта Port Control Protocol (PCP: последователь NAT-PMP в стандартах IETF). Клиентский порт для запрошенного сопоставления — 9/TCP. У клиента нет никаких предложений относительно того, каким должен быть внешний порт, поэтому он оставляет поле рекомендуемого внешнего порта равным нулю. В IETF RFC 6887, определяющем PCP, ясно указано, что ноль означает «нет предложений» в этом поле.

Я думаю, что тот, кто реализовал PCP для этого маршрутизатора Billion, неправильно прочитал RFC. Видите ли, в некоторых очень ограниченных и четко определенных случаях ноль в поле OTHER port может означать "все порты". Например, когда Requested Lifetime для этого запроса сопоставления равен нулю, нулевой клиентский порт будет означать "удалить все сопоставления для всех портов на этом клиентском IP-адресе".

Но опять же, в поле рекомендуемого внешнего порта ноль всегда должен означать «нет предложения». Он никогда не должен означать «все порты» в этом поле.

Итак, кажется совершенно очевидным, что вы обнаружили ошибку PCP в этом маршрутизаторе Billion.

Еще одна странность здесь — порт клиента. Традиционно discardпортом службы является 9/TCP, но discardслужба устарела, поэтому я не уверен, кто бы ее еще запускал или почему что-то запрашивало сопоставление портов для нее.

Что касается того, почему mDNSResponder отправляет эти запросы, то это просто потому, что mDNSResponder действует как демон PCP/NAT-PMP/UPnP на macOS в дополнение к своим обычным обязанностям mDNS, DNS-SD и DNS-резолвера. Когда какой-либо процесс на macOS запускает запрос системой сопоставления портов с маршрутизатора, задачей mDNSResponder всегда является создание и отправка фактических пакетов запросов сопоставления портов.

Связанный контент