OSX mDNSResponder abrindo todas as portas em bilhões

Question

Eu recentemente troquei meu roteador por um Billion 7800VDOX, e notei algumas tentativas de conexão com meu iMac de endereços externos. Na investigação, descobri que uma porta uPnP tinha sido aberta no roteador com intervalo de portas 0-0 (interno e externo). Isso tem o efeito, verificado com um scanner de porta externo, de abrir TODOS os números de porta no roteador e direcioná-los para o iMac. Excluí o mapeamento e executei o Wireshark e capturei uma solicitação de endereço externo ao mesmo tempo em que o mapeamento foi restaurado.

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

Isso foi precedido por uma solicitação SOAP para obter o endereço IP externo do roteador. Verificando a porta de origem (5353) com lsof eu achei que era propriedade de mDNSResponder.

Minha suposição sobre o que está acontecendo é que o mDNSResponder está usando isso apenas para obter o endereço IP externo do roteador, usando uma solicitação supostamente inofensiva para mapear a porta 0, que deve ser uma porta inválida. No entanto, o roteador Billion está tratando isso como, por erro de projeto ou programação, como uma solicitação para abrir todas as portas. Desligar o uPnP no roteador resolve o problema (mesmo que isso não seja, na verdade, uPnP).

Alguém tem outras sugestões?

    

Answer 1

O pacote que você capturou mostra uma solicitação de mapeamento de porta do protocolo de controle de porta (PCP: o sucessor de trilha de padrões IETF para NAT-PMP). A porta do cliente para o mapeamento solicitado é 9 / TCP. O cliente não tem nenhuma sugestão para o que a porta externa deve ser, portanto, deixa o campo de porta externa sugerido definido como zero. O IETF RFC 6887, que define o PCP, deixa claro que zero significa "nenhuma sugestão" neste campo.

Acho que quem implementou o PCP para este bilhão de roteadores leu o RFC de maneira errada. Você vê, em alguns casos muito limitados e bem definidos, um zero no campo da outra porta poderia significar "todas as portas". Como quando o tempo de vida solicitado para essa solicitação de mapeamento é zero, uma porta de cliente zero significaria "excluir todos os mapeamentos para todas as portas nesse endereço IP do cliente".

Mas, novamente, no campo de porta externa sugerido, zero deve sempre significar "sem sugestão". Nunca é suposto significar "todas as portas" neste campo.

Portanto, parece bastante claro que você encontrou um bug PCP neste roteador Billion.

Outra coisa estranha aqui é a porta do cliente. Tradicionalmente, 9 / TCP é a porta do discard service, mas o serviço discard está obsoleto, então não tenho certeza de quem o executaria mais ou por que qualquer coisa estaria solicitando um mapeamento de porta para ele. / p>

Por que o mDNSResponder está enviando essas solicitações, é simplesmente porque o mDNSResponder atua como o daemon PCP / NAT-PMP / UPnP no macOS, além de suas tarefas habituais de resolução de mDNS, DNS-SD e DNS. Quando qualquer processo no macOS aciona o sistema para solicitar um mapeamento de porta do roteador, é sempre tarefa do mDNSResponder criar e enviar os pacotes de solicitação de mapeamento de porta reais.