OSX mDNSResponder öffnet alle Ports auf Billion

OSX mDNSResponder öffnet alle Ports auf Billion

Ich habe meinen Router kürzlich gegen einen Billion 7800VDOX ausgetauscht und dabei einige Verbindungsversuche von externen Adressen zu meinem iMac bemerkt. Bei der Untersuchung stellte ich fest, dass auf dem Router ein uPnP-Port mit dem Portbereich 0-0 (intern und extern) geöffnet worden war. Dies hat, wie mit einem externen Portscanner überprüft, zur Folge, dass ALLE Portnummern auf dem Router geöffnet und an den iMac weitergeleitet werden. Ich habe die Zuordnung gelöscht und Wireshark ausgeführt und gleichzeitig mit der Wiederherstellung der Zuordnung eine externe Adressanforderung erfasst.

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

Dem ging eine SOAP-Anfrage voraus, um die externe IP-Adresse des Routers abzurufen. Als ich den Quellport (5353) mit lsof überprüfte, stellte ich fest, dass er mDNSResponder gehört.

Ich gehe davon aus, dass mDNSResponder dies nur verwendet, um die externe IP-Adresse des Routers abzurufen, und zwar mit einer vermeintlich harmlosen Anfrage, Port 0 zuzuordnen, der eigentlich ein ungültiger Port sein sollte. Der Billion-Router behandelt dies jedoch – entweder aufgrund von Design oder Programmierfehler – als Anfrage, alle Ports zu öffnen. Das Ausschalten von uPnP auf dem Router löst das Problem (obwohl dies, wie bereits erwähnt, kein echtes uPnP ist).

Hat jemand noch andere Vorschläge?

Antwort1

Das von Ihnen erfasste Paket zeigt eine Portzuordnungsanforderung für das Port Control Protocol (PCP: der IETF-Standardnachfolger von NAT-PMP). Der Client-Port für die angeforderte Zuordnung ist 9/TCP. Der Client hat keinen Vorschlag für den externen Port und lässt daher das Feld für den vorgeschlagenen externen Port auf Null gesetzt. IETF RFC 6887, das PCP definiert, macht deutlich, dass Null in diesem Feld „kein Vorschlag“ bedeutet.

Ich denke, wer auch immer PCP für diesen Billion-Router implementiert hat, hat das RFC falsch gelesen. In einigen sehr begrenzten und genau definierten Fällen könnte nämlich eine Null im Feld „ANDERE Ports“ „alle Ports“ bedeuten. Wenn beispielsweise die angeforderte Lebensdauer für diese Zuordnungsanforderung Null ist, würde ein Client-Port von Null bedeuten „alle Zuordnungen für alle Ports dieser Client-IP-Adresse löschen“.

Aber nochmals: Im Feld für vorgeschlagene externe Ports bedeutet Null immer „kein Vorschlag“. In diesem Feld bedeutet sie nie „alle Ports“.

Es scheint also ziemlich klar, dass Sie in diesem Billion-Router einen PCP-Fehler gefunden haben.

Eine weitere seltsame Sache ist der Client-Port. Traditionell ist 9/TCP der discardPort des Dienstes, aber der discardDienst ist veraltet, daher bin ich mir nicht sicher, wer ihn noch ausführt oder warum irgendetwas eine Portzuordnung dafür anfordern würde.

Der Grund, warum mDNSResponder diese Anfragen sendet, liegt einfach daran, dass mDNSResponder zusätzlich zu seinen üblichen Aufgaben als mDNS, DNS-SD und DNS-Resolver als PCP/NAT-PMP/UPnP-Daemon auf macOS fungiert. Wenn ein beliebiger Prozess auf macOS das System dazu veranlasst, eine Portzuordnung vom Router anzufordern, ist es immer die Aufgabe von mDNSResponder, die eigentlichen Portzuordnungsanforderungspakete zu erstellen und zu senden.

verwandte Informationen