OSX mDNSResponder abriendo todos los puertos en Billion

Recientemente cambié mi enrutador por un Billion 7800VDOX, y noté algunos intentos de conexión a mi iMac desde direcciones externas. En la investigación descubrí que se había abierto un puerto uPnP en el enrutador con un rango de puertos 0-0 (interno y externo). Esto tiene el efecto, verificado con un escáner de puertos externo, de abrir TODOS los números de puerto en el enrutador y dirigirlos a El iMac. Eliminé la asignación y ejecuté Wireshark y capturé una solicitud de dirección externa al mismo tiempo que se restableció la asignación.

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

Esto fue precedido por una solicitud SOAP para obtener la dirección IP externa del enrutador. Comprobando el puerto de origen (5353) con lsof encontré que es propiedad de mDNSResponder.

Mi suposición sobre lo que está sucediendo es que mDNSResponder está usando esto solo para obtener la dirección IP externa del enrutador, y lo hace usando una solicitud supuestamente inofensiva para mapear el puerto 0, que debería ser un puerto no válido. Sin embargo, el enrutador Billion trata esto como, ya sea por diseño o error de programación, como una solicitud para abrir todos los puertos. Desactivar uPnP en el enrutador resuelve el problema (aunque, como se señaló, esto no es realmente uPnP).

Alguien tiene alguna otra sugerencia?

— Clyde
fuente

NAT-PMP no es uPnP, una solicitud para conocer la dirección IP externa no es una solicitud de asignación de puertos, y no ha mostrado un paquete capturado de una solicitud uPnP o NAT-PMP para ninguna asignación de puertos, mucho menos para puerto 0. Sería bueno ver paquetes que muestran a la Mac haciendo lo que parece pensar que está haciendo. Pero probablemente esté en el camino correcto de que el enrutador Billion tiene errores.

— Spiff

@Spiff Ok, he editado la pregunta. Desactivar "uPnP" en el enrutador hace que el problema desaparezca. A pesar de que el enrutador parece tener errores, todavía me sorprende por qué mDNSResponder debería estar haciendo esto.

— Clyde

El paquete que capturó muestra una solicitud de asignación de puerto del Protocolo de control de puertos (PCP: el sucesor de seguimiento de estándares IETF a NAT-PMP). El puerto del cliente para la asignación solicitada es 9 / TCP. El cliente no tiene ninguna sugerencia sobre cuál debería ser el puerto externo, por lo que deja el campo de puerto externo sugerido establecido en cero. IETF RFC 6887, que define PCP, deja en claro que cero significa "sin sugerencia" en este campo.

Creo que quien implementó PCP para este enrutador Billion leyó mal el RFC. Verá, en algunos casos muy limitados y bien definidos, un cero en el campo OTROS puertos podría significar "todos los puertos". Al igual que cuando la vida útil solicitada para esta solicitud de asignación es cero, un puerto de cliente cero significaría "eliminar todas las asignaciones para todos los puertos en la dirección IP de este cliente".

Pero nuevamente, en el campo de puerto externo sugerido, se supone que cero siempre significa "sin sugerencia". Nunca se supone que significa "todos los puertos" en este campo.

Por lo tanto, parece bastante claro que ha encontrado un error de PCP en este enrutador Billion.

Otra cosa extraña aquí es el puerto del cliente. Tradicionalmente, 9 / TCP es el discardpuerto del servicio, pero el discardservicio está en desuso, por lo que no estoy seguro de quién lo ejecutará más o por qué algo solicitaría una asignación de puerto para él.

En cuanto a por qué mDNSResponder está enviando estas solicitudes, es simplemente porque mDNSResponder actúa como el demonio PCP / NAT-PMP / UPnP en macOS además de sus tareas habituales de resolución de mDNS, DNS-SD y DNS. Cuando cualquier proceso en macOS activa el sistema para solicitar una asignación de puertos del enrutador, siempre es tarea de mDNSResponder crear y enviar los paquetes de solicitud de asignación de puertos reales.

— Spiff
fuente

No hay nada escuchando en el puerto 9 de mi máquina. He activado el inicio de sesión en mDNSResponder y veré si aparece algo. No sabía que actuaba como un proxy para las solicitudes de mapeo.

— Clyde

Con el inicio de sesión de depuración desde mDNSResponder que veo

15/06/2016 4:08:55.731 PM mDNSResponder[108]: LNT_MapPort 15/06/2016 4:08:55.731 PM mDNSResponder[108]: SendPortMapRequest: internal 0 external 0

y profundizando en el código fuente de mDNSResponder, parece que esto es parte del soporte de Bonjour. Por qué el puerto solicitado es 0 no está claro.

— Clyde

Creo que la conclusión es que hay un error en el enrutador, y lo que probablemente sea un error en mDNSResponder, y los dos interactúan para producir el resultado que he visto. Observo que al menos otra persona ha visto esto con el mismo enrutador

— Clyde

Ese mensaje de registro hace que parezca que pudo haber enviado 0 como el número de puerto del cliente esa vez. Si puede capturar un paquete PCP o NAT-PMP desde la Mac solicitando una asignación de puerto al puerto 0 del cliente con una vida útil no distinta de cero, sería muy interesante verlo. Por cierto, ¿tienes idea de qué sistema operativo incorporado utiliza tu Billion? ¿O qué implementación de PCP utiliza?

— Spiff

Afirma enviar 0 cada vez. No sé por qué Wirehark informa 9.

— Clyde