Zugriff über IP:PORT obwohl keine Portweiterleitung eingerichtet

[svethi]

Du hast wohl meinen Kommentar nicht gelesen. Sicher ist der Port relevant. Ohne Port geht gar nichts. Es gibt natürlich Standard Ports für gewissen Anwendungen. Web hat nunmal die 80 und wenn bei einer Webanfrage kein Port angegeben wird, verbindet der Klient automatisch auf den 80.
Die DNSCloud verbindet auch nicht unbedingt auf Port 80. Wenn in der Config bei externer Adresse ein anderer Port angegeben wurde, wird auf diesen Port verwiesen. Den internen Port des MiniServer zu ändern und dann extern auf Port 80 zu bleiben ist ebenso sinnlos wie den externen Port zu ändern und dann den CloudDNS zu nutzen. Der CloudDNS liefert diesen Port nämlich ohne Bedenken einfach mit aus weshalb die MiniServer über CloudDNS trotz anderem Port ständig Angriffsziele sind. Auf dieses Sicherheitsloch wurde hier auch schon mehrfach hingewiesen

Gruß Sven

[Jan W.]

Beim internen Zugriff müsste, wenn es stimmt was Gerd Clever sagt, der Port unerheblich sein. Das kann ich so nicht bestätigen. Sowohl die App zeigt an das sie sich mit 10.0.1.XX:Port verbindet. Als auch die Config Software fordert als Eingabe zur Verbindung mit dem Minisever eben diese 10.0.1.xx:Port. Die Portangabe scheint also durchaus relevant zu sein.

Der Port ist IMMER relevant, damit deine App, Browser etc. (allgemein Dein Client) Zugriff auf den Server bekommt. Gerd Clever sagt nur, dass es sicherheitstechnisch intern keinen Unterschied gibt, wenn der MS von extern über Port X erreichbar gemacht wurde. Es gibt Standard-Ports für viele genutzte Dienste im Internet und für HTTP ist TCP Port 80 der Standard. Der braucht i.d.R. nicht explizit angegeben werden.

Beim Zugriff von extern über dns.loxone.com/blablabla findet bei loxone ein aufschlüsselung in meine öffentliche IP statt. Mit der komm ich dann bei mir zu Hause auf Port 80 an.

Das stimmt nicht ganz. Beim HTTP Zugriff auf diese URL findet ein redirect auf Deine öffentliche IP-Adresse UND den öffentlichen Port an, den DU in Deinem Miniserver hierfür (bei der "Registrierung") angegeben hast. Nur wenn Du keinen Port angegeben hast, dann wird der Standard-Port 80 verwendet. Siehe https://www.loxone.com/dede/kb/cloud-dns/ , insbesondere der Hinweis: Ist das Portforwarding auf einen anderen Port als 80 konfiguriert, so muss dieser Port eingegeben werden: dns.loxonecloud.com:PORT Wenn die Portweiterleitung auf Deinem Internet-Router auf einen anderen (öffentlichen) Port als 80 eingestellt ist, dann musst Du also den Port mit angeben.

Es macht sicherheitstechnisch schon einen Unterschied, ob Du einen beliebigen Dyn-DNS Dienst verwendest (den Gerd in Post #9 beschreibt), oder den Cloud-DNS Dienst von Loxone (den Du in Post #14 das erste Mal erwähnst). Der Cloud-DNS Dienst kann NUR in Verbindung mit der Loxone App (oder einem Browser) verwendet werden und macht automatisch eine (HTTP) Umleitung auf den von Dir registrierten Port (oder eben Port 80, wenn Du keinen angegeben hast), um den MS von extern zu erreichen. Andere Dyn-DNS Dienste machen eine DNS Namensauflösung auf Deine öffentliche IP-Adresse und daher musst Du immer den Port mit angeben, wenn er vom Standard abweicht. Dafür wird einem Hacker der öffentlich erreichbare Port nicht wie bei Cloud-DNS "auf dem Silbertablett" serviert" und der Dienst funktioniert mit einem beliebigen Dienst und nicht nur HTTP.

Zum Thema Sicherheit bei Cloud DNS und anderen Dyn-DNS Diensten gibt es hier im Forum mehrere Threads und auch was im Wiki.

Also im Admin Interface ist der Zugriff natürlich auf online gestellt.

Mein Post #10 war keine Aufforderung, die Einstellung auf "online" zu stellen, sondern sollte das Verhalten nur erklären. In Verbindung mit dem Cloud-DNS Dienst ist dies die unsicherste Kombination, die man überhaupt nur einstellen kann. Da braucht man sich später wirklich nicht wundern, wenn man gehackt wurde, weil es eine Sicherheitslücke im MS gibt oder man ein schlechtes Kennwort verwendet.

[miqa]

Zum Thema Sicherheit bei Cloud DNS und anderen Dyn-DNS Diensten gibt es hier im Forum mehrere Threads und auch was im Wiki.

Ist bekannt. Ich hatte ja ursprünglich auch explizit nciht nach dem Zugriff von außen gefragt. Da mir das Verhalten klar ist. Das kam von woanders in die Diskussion. Ich wollte nur verstehen warum die Angabe des Ports anscheinend intern noch von Relevanz ist.

Mein Post #10 war keine Aufforderung, die Einstellung auf "online" zu stellen, sondern sollte das Verhalten nur erklären.

Hatte ich auch nicht so verstanden. Ist aber aktuell noch notwendig für meine Frau da ich mich noch in der Umstellungsphase auf VPN (on demand) befinde. Von außen ist der Miniserver aber ja anscheinend aufgrund der fehlenden Port Weiterleitung momentan trotzdem nicht erreichbar.

[Gerd Clever]

(Doku-)Hinweis: Ist das Portforwarding auf einen anderen Port als 80 konfiguriert, so muss dieser Port eingegeben werden: dns.loxonecloud.com:PORT. Wenn die Portweiterleitung auf Deinem Internet-Router auf einen anderen (öffentlichen) Port als 80 eingestellt ist, dann musst Du also den Port mit angeben.

Ich kann in diesem Doku-Hinweis keinerlei Sinn erkennen.

Die externe Adresse, die tatsächlich versandt wird, lautet immer (Konfigurationssoftware, Webinterface, App): dns.loxonecloud.com/<SN-Miniserver>

Der Loxone Cloud DNS Dienst holt sich den PORT automatisch aus der Miniserver Konfiguration, egal welcher Port vergeben wurde und löst dns.loxonecloud.com/<SN-Miniserver> in <Öffentliche IP des Routers>:PORT auf. Hier könnte jetzt der Port 80 weggelassen werden.

Allein schon die Kombination dns.loxonecloud.com:PORT macht irgendwie keinen Sinn, da dns.loxonecloud.com - anders als echte DDNS Dienste - nicht allein die IP des Routers liefert auch nur nur in Kombination mit der <SN des Miniservers> funktioniert.

Mein Verdacht ist, dass es sich bei dns.loxonecloud.com:PORT nicht wirklich um die externe Adresse handelt, sondern eher um eine loxoneinterne Datenerfassungsvariante.

Mein Vorschlag wäre, das Feld Externe Adresse in der Config zu einem reinen Infofeld zu machen (nicht beschreibbar), denn in der Konfiguration des Miniservers ist alles Notwendige erfasst. Ich glaube, das würde einige Irritationen beseitigen.

[Jan W.]

Cloud-DNS funktioniert folgendermaßen:

Registrierung:
MS registriert sich bei dns.loxonecloud.com mit Hilfe eines Loxone eigenen Verfahrens mit der öffentlichen IP-Adresse des MS und einem Port

Abfrage:
Client sendet: HTTP GET auf dns.loxonecloud.com/<SN-Miniserver>
Cloud-DNS sendet: HTTP REDIRECT auf <Öffentliche IP des Routers>:PORT

wobei die Angaben <Öffentliche IP des Routers>:PORT durch die Registrierung Deines MS bei dem Cloud-DNS Dienst kommen. Hierbei weiß ich nicht, ob der Cloud-DNS Dienst die öffentliche IP-Adresse Deines MS über die Quell IP-Adresse bei der Registrierung durch den MS ermittelt oder der MS explizit diese IP-Adresse z.B. durch den Aufruf einer URL wie http://checkip.dyndns.org (nur ein Beispiel - die Prüfseite von DynDNS wird Cloud-DNS sicherlich nicht verwenden) feststellt und dann bei der eigentlichen Registrierung verwendet. Der Port ist der Port, den der MS für HTTP verwendet oder der Port der mit dns.loxonecloud.com:PORT in dem entsprechenden Feld explizit eingetragen wird. Diese Kombination wird NICHT als URL verwendet, sondern hier haben die Entwickler lediglich über eine festgelegte Definition den Dienst und den Port zusammengefügt.

da dns.loxonecloud.com - anders als echte DDNS Dienste - nicht allein die IP des Routers liefert auch nur nur in Kombination mit der <SN des Miniservers> funktioniert.

Genau. Ergänzen kann man noch, dass dies nur über HTTP und IMMER über Port 80 erfolgt.

Mein Verdacht ist, dass es sich bei dns.loxonecloud.com:PORT nicht wirklich um die externe Adresse handelt, sondern eher um eine loxoneinterne Datenerfassungsvariante.

Genauso ist es.

[Gerd Clever]

Hierbei weiß ich nicht, ob der Cloud-DNS Dienst die öffentliche IP-Adresse Deines MS über die Quell IP-Adresse bei der Registrierung durch den MS ermittelt oder der MS explizit diese IP-Adresse z.B. durch den Aufruf einer URL wie http://checkip.dyndns.org (nur ein Beispiel - die Prüfseite von DynDNS wird Cloud-DNS sicherlich nicht verwenden) feststellt und dann bei der eigentlichen Registrierung verwendet.

Eine hochinteressante Frage, auf welchem Weg der Cloud-DNS Dienst die <Öffentliche IP des Routers> ermittelt.

Da man dns.loxonecloud.com/<SN-Miniserver> von einer beliebigen IP senden kann, muss der Cloud-DNS Dienst allein aus der <SN-Miniserver> die sich ständig ändernde <Öffentliche IP des Routers> ermitteln können.

Ich kann mir nur vorstellen, dass der Miniserver alle Veränderungen der <Öffentlichen IP des Routers> sofort an den Cloud-DNS Dienst übermittelt. Im Prinzip so ähnlich wie "echte" DDNS Dienste, nur dass ich bei einem "echten" DDNS Dienst die Übermittlung bewusst eingerichtet/freigegeben habe.

[Jan W.]

Ich kann mir nur vorstellen, dass der Miniserver alle Veränderungen der <Öffentlichen IP des Routers> sofort an den Cloud-DNS Dienst übermittelt. Im Prinzip so ähnlich wie "echte" DDNS Dienste, nur dass ich bei einem "echten" DDNS Dienst die Übermittlung bewusst eingerichtet/freigegeben habe.

Es wird unter http://dns.loxonecloud.com/... sicherlich eine URL analog zu " http://checkip.dyndns.org" geben, unter der der MS zyklisch die eigene öffentliche IP-Adresse überprüfen kann und bei Änderungen dann die neue IP-Adresse beim Cloud-DNS Dienst registriert. Da der MS nicht sofort eine Änderung der öffentlichen IP-Adresse am Internet-Router mitbekommt, kann das nur zyklisch erfolgen. Wäre mal interessant, das z.B. an der Fritzbox mitzusniffern.

[svethi]

Warum sollte denn der CloudDNS irgendwelche komplizierten Abfragen tätigen? Der MiniServer meldet sich dort und kommt dort auch mit der öffentlichen IP. Da braucht CloudDNS nirgends etwas abfragen. Ob das letztlich eine Art Ping ist oder eine Authentifizierung erfolgt ist doch völlig irrelevant. Auf gar keinen Fall funktioniert es so wie in der Config angegeben an dem Port, den man da angibt. Hier wandelt Loxone die ganze Anfrage wieder um.

[Gerd Clever]

Der MiniServer meldet sich dort und kommt dort auch mit der öffentlichen IP.

Mal ganz konkret, folgendes Szenario: Ich sitze in einem Internet-Cafe und gebe http://dns.loxonecloud.com/<SN-Miniserver> ein. Loxone generiert daraus die <Öffentliche IP des Routers> und den PORT.

Wie kommen sie an diese Infos?

[svethi]

Indem Du in der Config den CloudDNS angibst und der MiniServer sich da immer meldet und schon hat Loxone Deine öffentliche IP. Das ist doch aber keine Zauberei. Das ganz normale Neztwerk Kommunikation.

[Gerd Clever]

... und genau das hatte ich im letzten Absatz von Post #21 geschrieben. Also, Problem gelöst ;-)

[svethi]

Nö, eben nicht. Der MiniServer macht das nicht sofort wenn sich was ändert, denn er weiß gar nicht wenn sich die IP ändert. Der MiniServer meldet sich einfach in einem gewissen Zeitabstand beim CloudDNS. Das wiederum darfst Du beim DynDNS meist nicht. Da darfst Du nur senden wenn die IP neu ist.

[Jan W.]

Indem Du in der Config den CloudDNS angibst und der MiniServer sich da immer meldet und schon hat Loxone Deine öffentliche IP.

Das es nur so laufen kann, ist klar (siehe Post #20). Die Frage, wie dies erfolgt würde mich schon interessieren, ist aber für die Praxis egal. Interessant ist aber auf jeden Fall, WANN das passiert. Der MS sitzt ja hinter dem Internet-Router und bekommt Änderungen der eigenen öffentlichen IP-Adresse nicht direkt mit. Er muss sich daher jede Minute oder in irgendeinem definierten Intervall beim Cloud-DNS Server melden und sich damit wieder neu registrieren. Alternativ könnte er auch regelmäßig eine URL abfragen, die ihm seine eigene öffentliche IP-Adresse mitteilt, analog zu http://checkip.dyndns.org. Damit hätte der Cloud-DNS Dienst vielleicht weniger Last, denn eine neue Registrierung müsste nur dann stattfinden, wenn sich die öffentliche IP-Adresse geändert hat.

Angenommen man hat einen Internet-Anschluss mit dynamischen öffentlichen IP-Adresse, die sich bei jedem Neustart des Internet-Routers ändert. Wenn man auch einen eigenen Switch im Heimnetz hat, dann bekommt der MS einen Neustart des Internet-Routers gar nicht mit, den sein Ethernet-Port bleibt konstant an. Daher würde der Cloud-DNS Dienst noch die alte öffentliche IP-Adresse bei Anfragen liefern. Nun muss es ja irgendein Intervall geben, in dem der MS regelmäßig seine Registrierung bei Cloud-DNS erneuert. Bis das erfolgt ist, würde ein Zugriff per App auf die eigene öffentliche IP-Adresse über Cloud DNS nicht funktionieren.

Bei anderen DynDNS Diensten übernimmt die Aufgabe der Registrierung typischerweise der Internet-Router selbst und der merkt natürlich sofort, wenn er z.B. über PPPoE eine neue öffentliche IP-Adresse bekommt. Daraufhin aktualisiert er seine Registrierung sofort und man kann über den DNS Namen des eigenen Internet-Routers sofort z.B. per App auf den MS zugreifen (per VPN oder Portfreigabe). Das ist ein weiterer Punkt, der für so einen DNS Dienst spricht.

[orli]

Nun, das ganze ist weniger kompliziert als ihr denkt. Ich kanns zwar nicht beweisen, aber meiner Meinung nach hat Loxone im Miniserver einen eigenen dyndns client für einen eigenen dyndns Dienst eingebaut. Vielleicht ists auch nur ein simpler cronjob.
Hier mal ein tcpdump meines Miniservers, der jede Minute an einen Server bei Amazon per UDP auf Port 7700 sendet:

08:43:50.486848 IP 10.99.99.5.5150 > ec2-52-28-49-143.eu-central-1.compute.amazonaws.com.7700: UDP, length 41
08:44:50.980237 IP 10.99.99.5.5150 > ec2-52-28-49-143.eu-central-1.compute.amazonaws.com.7700: UDP, length 41
08:45:51.473449 IP 10.99.99.5.5150 > ec2-52-28-49-143.eu-central-1.compute.amazonaws.com.7700: UDP, length 41
08:46:51.968746 IP 10.99.99.5.5150 > ec2-52-28-49-143.eu-central-1.compute.amazonaws.com.7700: UDP, length 41
08:47:52.461940 IP 10.99.99.5.5150 > ec2-52-28-49-143.eu-central-1.compute.amazonaws.com.7700: UDP, length 41
08:48:52.955622 IP 10.99.99.5.4097 > 10.99.99.1.domain: 1+ A? dns.loxonecloud.com. (37)
08:48:52.975006 IP 10.99.99.5.5150 > ec2-52-28-49-143.eu-central-1.compute.amazonaws.com.7700: UDP, length 41
08:49:53.450218 IP 10.99.99.5.5150 > ec2-52-28-49-143.eu-central-1.compute.amazonaws.com.7700: UDP, length 41

und hier gehts weiter:

ping dns.loxonecloud.com
PING dns.loxonecloud.com (52.28.49.143) 56(84) bytes of data.
64 bytes from ec2-52-28-49-143.eu-central-1.compute.amazonaws.com (52.28.49.143): icmp_seq=1 ttl=49 time=31.5 ms
64 bytes from ec2-52-28-49-143.eu-central-1.compute.amazonaws.com (52.28.49.143): icmp_seq=2 ttl=49 time=29.3 ms

und zu guter Letzt dass Ziel:

nmap -sU -p 7700 52.28.49.143

Starting Nmap 6.40 ( http://nmap.org ) at 2017-01-18 08:46 CET
Nmap scan report for ec2-52-28-49-143.eu-central-1.compute.amazonaws.com (52.28.49.143)
Host is up (0.023s latency).
PORT     STATE         SERVICE
7700/udp open|filtered unknown

Wie wir seit dem Musicserver und Squeezebox wissen, erfindet Loxone das Rad selten neu und nutzt bestehende Dienste einfach mit Anpassungen. Denke das wird hier ich nicht anders sein.

[svethi]

Sage ich doch die ganze Zeit schon

[orli]

Wollte dich ja nur bestätigen