OSX mDNSResponder öffnet alle Ports auf Billion

513
Clyde

Ich habe vor kurzem meinen Router gegen eine Billion 7800VDOX ausgetauscht und bemerkte einige Verbindungsversuche von externen Adressen zu meinem iMac. Bei einer Untersuchung habe ich festgestellt, dass auf dem Router ein uPnP-Port mit Portbereich 0-0 (intern und extern) geöffnet wurde. Dies hat den Effekt, dass mit einem externen Port-Scanner ALLE Portnummern auf dem Router geöffnet und an diesen geleitet werden der iMac. Ich habe das Mapping gelöscht, Wireshark ausgeführt und eine externe Adressanforderung zur gleichen Zeit erfasst, als das Mapping wiederhergestellt wurde.

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

Diesem ging eine SOAP-Anfrage voraus, um die externe IP-Adresse des Routers abzurufen. Beim Überprüfen des Quellports (5353) mit lsof habe ich festgestellt, dass er im Besitz von mDNSResponder ist.

Meine Annahme zu dem, was passiert, ist, dass mDNSResponder dies nur verwendet, um die externe IP-Adresse des Routers abzurufen, und dabei eine angeblich harmlose Anfrage für die Zuordnung von Port 0 verwendet, der ein ungültiger Port sein sollte. Der Billion-Router behandelt dies jedoch entweder als Entwurfs- oder Programmierfehler als Anforderung, alle Ports zu öffnen. Das Deaktivieren von uPnP auf dem Router löst das Problem (obwohl dies, wie gesagt, nicht wirklich uPnP ist.)

Hat noch jemand andere Vorschläge?

0
NAT-PMP ist kein uPnP, eine Anforderung zum Lernen der externen IP-Adresse ist keine Anforderung für ein Port-Mapping, und Sie haben kein erfasstes Paket einer uPnP- oder NAT-PMP-Anforderung für ein Port-Mapping angezeigt, geschweige denn für Port 0. Es wäre gut zu sehen, wie Pakete den Mac so zeigen, wie er es zu tun scheint. Aber Sie sind wahrscheinlich auf dem richtigen Weg, dass der Billion-Router fehlerhaft ist. Spiff vor 7 Jahren 0
@Spiff Ok, ich habe die Frage bearbeitet. Wenn Sie "uPnP" am Router ausschalten, wird das Problem behoben. Obwohl der Router fehlerhaft scheint, bin ich immer noch verwirrt, warum mDNSResponder dies tun sollte. Clyde vor 7 Jahren 0

1 Antwort auf die Frage

1
Spiff

Das von Ihnen erfasste Paket enthält eine Port-Control-Anforderung (Port Control Protocol, PCP: IETF-Nachfolger für NAT-PMP-Anschlusszuordnung). Der Client-Port für die angeforderte Zuordnung lautet 9 / TCP. Der Client hat keinen Vorschlag, wie der externe Port aussehen soll, und lässt das vorgeschlagene Feld für den externen Port auf Null gesetzt. IETF RFC 6887, das PCP definiert, macht deutlich, dass Null in diesem Feld "Kein Vorschlag" bedeutet.

Ich denke, wer PCP für diesen Milliarden-Router implementiert hat, hat den RFC falsch verstanden. Sie sehen, in einigen sehr begrenzten und genau definierten Fällen könnte eine Null im Feld OTHER-Port "alle Ports" bedeuten. Wenn die angeforderte Lebensdauer für diese Zuordnungsanforderung gleich Null ist, würde ein Null-Client-Port bedeuten: "Alle Zuordnungen für alle Ports auf dieser Client-IP-Adresse löschen".

Aber auch im Feld für den vorgeschlagenen externen Port bedeutet Null immer "Kein Vorschlag". Es soll niemals "alle Ports" in diesem Bereich bedeuten.

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

Eine andere seltsame Sache ist hier 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ühren wird oder warum irgendetwas eine Portzuordnung für ihn anfordert.

Warum mDNSResponder diese Anfragen sendet, liegt einfach daran, dass mDNSResponder auf macOS als PCP / NAT-PMP / UPnP-Dämon fungiert und zusätzlich zu den üblichen Aufgaben von mDNS, DNS-SD und DNS-Resolver. Wenn ein Prozess unter macOS das System dazu veranlasst, ein Port-Mapping vom Router anzufordern, ist es immer die Aufgabe des mDNSResponder, die eigentlichen Port-Mapping-Anforderungspakete zu erstellen und zu senden.

Auf Port 9 ist auf meinem Computer nichts zu hören. Ich habe mich bei mDNSResponder angemeldet und werde sehen, ob etwas angezeigt wird. Ich wusste nicht, dass es als Stellvertreter für Mapping-Anfragen fungierte. Clyde vor 7 Jahren 0
Bei der Debug-Anmeldung von mDNSResponder siehe 15.06.2016 4: 08: 55.731 PM mDNSResponder [108]: LNT_MapPort 15/06/2016 4: 08: 55.731 PM mDNSResponder [108]: SendPortMapRequest: intern 0 extern 0 und In den Quellcode von mDNSResponder zu graben, scheint dies ein Teil der Bonjour-Unterstützung zu sein. Warum der angeforderte Port 0 ist, ist unklar. Clyde vor 7 Jahren 0
Ich denke, das Endergebnis ist, dass es einen Fehler im Router gibt und was wahrscheinlich ein Fehler in mDNSResponder ist, und die beiden interagieren, um das Ergebnis zu erzeugen, das ich gesehen habe. Ich stelle fest, dass mindestens eine andere Person dies mit demselben Router gesehen hat (https://forums.whirlpool.net.au/archive/2180205). Clyde vor 7 Jahren 0
Diese Protokollnachricht lässt es so aussehen, als hätte sie zu diesem Zeitpunkt 0 als Client-Port-Nummer gesendet. Wenn Sie ein PCP- oder NAT-PMP-Paket vom Mac aufnehmen können, das nach einer Portzuordnung zu Client-Port 0 mit einer nicht unter null erforderlichen Lebensdauer fragt, ist dies sehr interessant. Übrigens, haben Sie eine Idee, welches Embedded-Betriebssystem Ihre Billion verwendet? Oder welche PCP-Implementierung verwendet wird? Spiff vor 7 Jahren 0
Sie gibt an, jedes Mal 0 zu senden. Ich weiß nicht, warum wireshark 9 berichtet. Clyde vor 7 Jahren 0

Verwandte Probleme