ioBroker.yahka icon indicating copy to clipboard operation
ioBroker.yahka copied to clipboard

Konfiguration von IP/Port wird nicht konsequent umgesetzt -> Sicherheitsproblem

Open griesi opened this issue 4 years ago • 7 comments

Ich habe eine Konfiguration mit mehreren Netzwerken / Netzwerk-Adaptern am ioBroker-Server und mehreren Instanzen des YAHKA-Adapters.

Über die Konfiguration der IP-Adresse und des Ports hätte ich erwartet, dass diese Instanzen auch auf Netzwerk-Ebene korrekt voneinander getrennt, also abgeschottet sind bzw. werden.

Leider ist das offenbar nicht der Fall.

Der zugehörige Port (bei 0=zufällig durch das OS bestimmt, ansonsten der definierte Port, in meinem Beispiel 65530) wird auf sämtlichen Netzwerk-Schnittstellen gebunden:

@:~$ netstat -an | grep -i 65530 tcp6 0 0 :::65530 :::* LISTEN

Ich würde hier erwarten, dass der zufällige bzw. definierte Port ebenfalls NUR auf der angegebenen Netzwerk-Schnittstelle gebunden wird. Somit wird sicher verhindert, dass überhaupt ein Zugriff auch über andere Netzwerk-Adapter, also aus anderen angeschlossenen Netzwerken möglich ist.

Ob die Konfiguration einer speziellen IP-Adresse wie erwartet dazu führt, dass die MDNS-Broadcasts auf diesem Netzwerk-Adapter ausschließlich diesen YAHKA-Adapter präsentiert ist mir auch nicht ganz klar.

In der Version 0.11 des Adapters wurden über die MDNS-Broadcasts der gewählten Schnittstelle nicht wie zu erwarten nur die A- bzw. AAAA-Records dieser Netzwerkkarte, sondern die Adressen aller Netzwerkkarten offengelegt. Offenbar wurde das in der Version 0.12 des Adapters behoben, obwohl in den Release-Notes dazu nichts zu lesen ist. Ich sehe in den Paketmitschnitten der Version 0.12, dass die MDNS-Responses nun nur noch wie erwartet die A- und AAAA-Records der gewählten Netzwerk-Schnittstelle enthalten.

Bei den Paketmitschnitten bin ich aber über ein anderes MDNS-Paket gestolpert, welches von einem iPad in meinem Netzwerk gesendet wurde. Dort wurden PTR-Records für alle 3 Instanzen des YAHKA-Adapters veröffentlicht wurden. Das iPad muss also irgendwie an die Information über die beiden anderen Instanzen, die nicht in diesem Netzwerk sind, gekommen sein. Möglicherweise kommt das aber von dem Verhalten des Adapters, als der noch in der Version 0.11 lief. Das Update habe ich gerade erst durchgeführt und dabei wie gesagt ja auch schon das bessere Verhalten

griesi avatar Jan 10 '21 12:01 griesi

zwischen 0.11 und 0.12 hat sich die zugrunde liegende Bibliothek zur Kommunikation mit HomeKit stark geändert. Unter anderem wurde dort die Bibliothek für die Bonjour-Kommunikation (MDNS) geändert. Ich schaue mal bei Gelegenheit ob sich die Parameter für das Interface-Binding geändert haben.

jensweigele avatar Jan 12 '21 16:01 jensweigele

@griesi Kannst du bitte mal testen, ob das Problem mit der YAHKA NPM-Version 0.13.1 weiterhin auftritt?

nicoh88 avatar Jan 14 '21 22:01 nicoh88

Das Problem bzw. das problematische Verhalten ist auch in der Version 0.13.2 (ich habe mit 0.13.2 getestet !!!) vorhanden:

Ich habe wie gesagt 3 yahka-Instanzen, die jeweils auf einen Netzwerk-Adapter konfiguriert sind.

Der konfigurierte Port wird auf allen Netzwerk-Schnittstellen gebunden:

netstat -an tcp6 0 0 :::65530 :::* LISTEN tcp6 0 0 :::65531 :::* LISTEN tcp6 0 0 :::65532 :::* LISTEN

Hier würde ich erwarten, dass der Port nur auf den Konfigurierten Adapter gebunden wird:

tcp6 0 0 192.168.x.x:65530 :::* LISTEN tcp6 0 0 192.168.y.x:65531 :::* LISTEN tcp6 0 0 192.168.z.x:65532 :::* LISTEN

Darüber hinaus werden in dieser Version per MDNS alle yahka-Instanzen veröffentlicht.

image

Hier würde ich ebenfalls erwarten, dass nur die Instanz veröffentlicht wird, die auch auf die jeweilige Schnittstelle konfiguriert wird, z.B. 192.168.x.x

griesi avatar Jan 23 '21 10:01 griesi

@jensweigele @nicoh88: Any news on this?

griesi avatar Feb 20 '21 19:02 griesi

Yes, there is a new release (since this week) of the HAP Lib which unifies the binding parameters between the different advertisers. I try to implement that in the next weeks.

jensweigele avatar Feb 20 '21 20:02 jensweigele

Teste mal bitte wie es sich mit dem aktuellen Master verhält!

jensweigele avatar Mar 06 '21 17:03 jensweigele

Ich habe mit der Version 0.14 getestet, und soweit ich das beurteilen kann ist eines der beiden Probleme (wieder) behoben.

Die mDNS-Pakete enthalten jetzt im jeweiligen VLAN tatsächlich nur noch die Informationen der yahka-Instanz, die auf diesen VLAN/Adapter gebunden ist. Dieses Verhalten war wohl in der Version 0.12 schon einmal so, in 0.13 wieder nicht, in 0.14 wieder schon. Sehr gut!

Ich habe allerdings nach wie vor das Verhalten, dass diverse iDevices in dem VLAN, in dem ich als erstes yahka im Einsatz habe, immer mal wieder mDNS-Pakete versenden, in denen die PTR-Records von allen drei Instanzen stehen. Ich vermute die Ursache dahinter aber nicht im Adapter, sondern eher auf den Apple-Geräten. Es handelt sich offenbar lediglich um die PTR-Records ohne A- oder AAAA-Records, die Information wäre also auch bedingt nutzlos.

Der konfigurierte Port wird aber nach wie vor auf allen Netzwerk-Schnittstellen gebunden:

netstat -an tcp 0 0 0.0.0.0:65530 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:65531 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:65532 0.0.0.0:* LISTEN

Hier würde ich erwarten, dass der Port nur auf den Konfigurierten Adapter gebunden wird:

tcp 0 0 192.168.x.x:65530 :::* LISTEN tcp 0 0 192.168.y.x:65531 :::* LISTEN tcp 0 0 192.168.z.x:65532 :::* LISTEN

Lässt sich das evtl. auch noch beheben? Im Moment behelfe ich mir damit, dass ich in den yahka-Instanzen feste Ports definiere (65530 bis 65532) und nur diese per Firewall nur auf der entsprechenden Netzwerk-Schnittstelle öffne.

griesi avatar Mar 26 '21 07:03 griesi