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

436
Clyde

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

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

0
NAT-PMP - это не uPnP, запрос на изучение внешнего IP-адреса не является запросом на сопоставление портов, и вы не показали захваченный пакет запроса uPnP или NAT-PMP для любого сопоставления портов, тем более для порт 0. Было бы хорошо увидеть пакеты, показывающие, что Mac делает то, что, как вы думаете, делает. Но вы, вероятно, на правильном пути, что маршрутизатор Billion глючит. Spiff 7 лет назад 0
@Spiff Хорошо, я редактировал вопрос. Отключение «uPnP» на маршрутизаторе устраняет проблему. Несмотря на то, что маршрутизатор глючит, я все еще удивлен, почему mDNSResponder должен это делать. Clyde 7 лет назад 0

1 ответ на вопрос

1
Spiff

The packet you captured shows a Port Control Protocol (PCP: the IETF standards-track successor to NAT-PMP) port mapping request. The client port for the requested mapping is 9/TCP. The client doesn't have any suggestion for what the external port should be, so it leaves the suggested external port field set to zero. IETF RFC 6887, which defines PCP, makes clear that zero means "no suggestion" in this field.

I think whoever implemented PCP for this Billion router misread the RFC. You see, in some very limited and well-defined cases, a zero in the OTHER port field could mean "all ports". Like when the Requested Lifetime for this mapping request is zero, a zero client port would mean "delete all mappings for all ports on this client IP address".

But again, in the suggested external port field, zero is always supposed to mean "no suggestion". It is never supposed to mean "all ports" in this field.

So it seems pretty clear you've found a PCP bug in this Billion router.

One other weird thing here is the client port. Traditionally, 9/TCP is the discard service's port, but the discard service is deprecated, so I'm not sure who'd be running it any more, or why anything would be requesting a port mapping for it.

As for why mDNSResponder is sending these requests, it's simply because mDNSResponder acts as the PCP/NAT-PMP/UPnP daemon on macOS in addition to its usual mDNS, DNS-SD, and DNS resolver duties. When any process on macOS triggers the system to request a port mapping from the router, it's always mDNSResponder's job to create and send the actual port mapping request packets.

На моей машине ничего не слушается через порт 9. Я включил регистрацию на mDNSResponder и посмотрю, появится ли что-нибудь. Я не знал, что он действовал как прокси для отображения запросов. Clyde 7 лет назад 0
При входе в систему отладки из mDNSResponder я вижу `15/06/2016 4: 08: 55.731 PM mDNSResponder [108]: LNT_MapPort 15/06/2016 4: 08: 55.731 PM mDNSResponder [108]: SendPortMapRequest: внутренний 0 внешний 0` и копаясь в исходном коде mDNSResponder, кажется, что это часть поддержки Bonjour. Почему запрашиваемый порт 0, неясно. Clyde 7 лет назад 0
Я думаю, суть в том, что в роутере есть ошибка, и, вероятно, это ошибка в mDNSResponder, и эти два взаимодействуют для получения результата, который я видел. Я отмечаю, что по крайней мере еще один человек [видел это с тем же маршрутизатором] (https://forums.whirlpool.net.au/archive/2180205) Clyde 7 лет назад 0
Это сообщение журнала выглядит так, как будто оно отправило 0 в качестве номера порта клиента в то время. Если вы можете перехватить пакет PCP или NAT-PMP с Mac, запрашивающий сопоставление порта с клиентским портом 0 с ненулевым запрошенным временем жизни, это было бы очень интересно увидеть. Кстати, у вас есть идея, какую встроенную ОС использует ваш Billion? Или какую реализацию PCP он использует? Spiff 7 лет назад 0
Он утверждает, что отправлять 0 каждый раз. Я не знаю, почему Wireshark сообщает 9. Clyde 7 лет назад 0

Похожие вопросы