Logitech Harmony steuert von WAN den Hub in LAN ohne Freigabe? Wie geht das?
-
Hallo,
ich teste gerade ein bisschen mit Alexa (Amazon Echo) rum und wundere mich gerade was geht.
Was habe ich getan?Der Echo Dot hängt bei mir im Netz "Rot", welches das WAN Netz ist. Der Harmony Hub von Logitech befindet sich im Netz "Grün", welches mein LAN Netz ist. Ich habe dann den Echo Dot über den Dienst Yonomi mit dem Harmony Hub verbunden. Wenn ich Alexa nun den Befehl "Schalte Verstärker ein" gebe, sendet der Echo den Befehl an Yonomi (so weit ok). Yonomi übersetzt den Befehl an Logitech (auch ok) und Logitech sendet den Befehl an meinen Hub (nicht ok, oder?und dieser schaltet den Verstärker ein. Warum geht das? Es muss ja offensichtlich ein Paket aus der WAN Schnittstelle nach LAN kommen, ohne das LAN das Paket angefordert hat. Nach meinem Verständnis müsste das Paket geblockt werden, oder?
-
Ohne die Dienste jetzt alle genau zu kennen: Die ganzen Cloud Geräte bauen von sich aus eine Steuerverbindung aus dem LAN in die Cloud auf. Diese Verbindung halten sie aufrecht. Und solange die Verbindung besteht, kann darüber in beide Richtungen kommuniziert werden.
-
Das klingt gerade ziemlich gruselig für mich.
Also müsste ich hingehen und für diese Steuerdienste ein eigenes Netz hochziehen, in dem die dann eingesperrt werden?
Sprich, in meinem Fall muss der Harmony Hub aus dem LAN Netz raus in dem meine Server stehen, damit ich sicherstellen kann das die nicht über ein Backdoor am meine Server könnten?
Oder kann ich "einfach" z.B. die IP des Harmony Hubs zu begrenzen, dass dieser auf keine weiteren Geräte zugreifen kann?Wie sichere ich das am besten ab?
-
Theoretisch müssten diese Geräte alle in ein separates Netz, ja. Kommt halt drauf an, wieviel Bequemlichkeit Du der Sicherheit opfern willst. Einige Geräte, die Du mit dem Smartphone oder Hubs fernsteuern kannst, hängen von lokaler Namensauflösung ab (Bonjour, MDNS, etc.). Die funktionieren dann halt nicht ohne Probleme oder ggf. garnicht, wenn Du sie in separaten Netzen hast.
-
Prinzipiell das was Arthur sagt bzw. du selbst bemerkt hast. Alles "shiny cloudy" ist potentiell geschwätzig. Deshalb macht es an der Stelle durchaus Sinn, das in verschiedene Netze (VLANs?) zu separieren. Und das nicht erst seit Cloud der neue Hype Begriff ist, sondern bereits vorher mit Dingen wie Consolen oder "pseudo smartem Kram" der via uPNP irgendwelche Ports aufreißt. Je nachdem was du da tun willst, würde ich dir empfehlen da hinter der pfSense einen günstigen (weil Home?) Switch wie TP-Link, nen kleinen HP o.ä. hinzusetzen und VLANs einzuführen.
Wenn du nicht unbedingt Gigabit Linespeed brauchst irgendwo, sollten die die VLANs keine großen Performance Lücken bringen, dafür aber mehr Sicherheit da bessere Segmentierung und Absicherung der einzelnen Dienste.Es gibt schon einen Grund, warum Security Jungs und Netzadmins bei Tools wie Teamviewer etc. böse schauen. Klar sind die erstmal super komfortabel für den User, zerbohren dir aber mit ihren Firewall-Umgehungsmechanismen mitunter jedes Sicherheitskonzept. Und da die Dinger inzwischen auch Fallback auf Ports wie 80/443 haben kann man außer wirklich ganz eklig Level7 zu filtern da auch recht wenig machen außer eben die Netze ziemlich zudrehen (gut das ist jetzt die Firmensicht, zu Hause sieht das immer anders aus :) ).
Zusätzlich machen die WAN Regeln oben im Screenshot für mich keinen Sinn, es sei denn du hast mehr wie eine Public IP. Wenn nicht, macht es für mein Hirn gerade Sinn dass zwei Regeln auf 443 matchen und das einmal die Firewall und einmal ein Server als designated Target dafür ausgewählt sind - außer das NAT biegt da auch noch gehörig an den Ports rum?
-
VLANs einzuführen.
Ok, VLANS nutze ich schon, da werde ich mal ein weiteres aufspannen und die Geräte separieren. Eine Netzwerkkarte habe ich eh noch frei in der pfSense. Das wird mir entgegen kommen.
Zusätzlich machen die WAN Regeln oben im Screenshot für mich keinen Sinn, es sei denn du hast mehr wie eine Public IP. Wenn nicht, macht es für mein Hirn gerade Sinn dass zwei Regeln auf 443 matchen und das einmal die Firewall und einmal ein Server als designated Target dafür ausgewählt sind - außer das NAT biegt da auch noch gehörig an den Ports rum?
Das verstehe ich nicht, leider. Ich dachte die Regeln müssten so angelegt werden? Nein, ich habe nur eine Public IP und ich verbinde mich in der Regel per dyndns. Ich dachte bisher, dass die Reglen so zu schreiben sind, dass erst mal der 443 vom WAN zur Firewall zugelassen wird. (Regel 3 von oben und dann im NAT gesagt werden muss wo der hin gehen soll (Regel 8 ).
Was ich erreichen möchte ist einfach, dass die https Browser anfrage an meinen dyndns auf meinen Server mit der IP 10.10.20.100 geleitet wird.
Wie wäre das denn richtiger / eleganter gelöst? Mag sein da sich das noch nicht so ganz verstanden habe. Würde mich freuen, wenn Du es mit etwas erklären könntest. -
Hmm, wie kann denn der Echo Dot im WAN Netz sein, wenn Du nur eine einzige IP dort hast?
-
Eine IP nach aussen.
Der Dot hängt an dem WLAN der FritzBox als einziges Gerät. Die pfSense ist als exposed host hinter der FritzBox. Meine anderen Geräte hängen an einem Accesspoint hinter der pfSense. -
Der Dot hängt an dem WLAN der FritzBox als einziges Gerät. Die pfSense ist als exposed host hinter der FritzBox. Meine anderen Geräte hängen an einem Accesspoint hinter der pfSense.
Hui das ist ja noch gruseliger! Du lässt dann also den Echo Dot einfach so ins Netz raus? Die Fritte hat ja nicht wirklich eine Firewall die abgehend filtern kann, also darf der Knabe quasi alles machen was er will? Uff..
Wie wäre das denn richtiger / eleganter gelöst? Mag sein da sich das noch nicht so ganz verstanden habe. Würde mich freuen, wenn Du es mit etwas erklären könntest.
Oh da gehts nicht um eleganter, sondern eher, dass du verstehen musst, wie die Regeln bzw. NAT Einstellungen greifen. Es wird ERST das NAT angewendet, dann die Regeln ausgeführt. Die erste Regel lässt also 443 auf das extIF der Firewall zu. Ggf. kommt da aber gar nichts an, wenn du im NAT Teil schon gesagt hast, dass die Pakete für den internen Server umgeschrieben werden. Ergo ist entweder die obere oder untere Regel unnötig. Wird im NAT das Paket bereits umgeschrieben auf die intere Serveradresse ist die Regel unten korrekt.
Was nicht stimmt: Du musst gar nichts erst zur Firewall lassen und dann irgendwo anders hin. Das wäre nur der Fall wenn die pfSense etwas für die annehmen soll (also als Proxy o.ä. agiert). Wenn das nicht der Fall ist, betrachte wo es herkommt, wo es ankommt (in dem Fall am WAN) und wo es hin will und ggf. wohin es umgeschrieben wird. Dann die Regel entsprechend schreiben. :)
-
Der Dot hängt an dem WLAN der FritzBox als einziges Gerät. Die pfSense ist als exposed host hinter der FritzBox. Meine anderen Geräte hängen an einem Accesspoint hinter der pfSense.
Hui das ist ja noch gruseliger! Du lässt dann also den Echo Dot einfach so ins Netz raus? Die Fritte hat ja nicht wirklich eine Firewall die abgehend filtern kann, also darf der Knabe quasi alles machen was er will? Uff..
Ich weiss ja nicht, kann das Ding nicht eh alles machen, was es will? Ich würde mal vermuten, dass es via Port 443/HTTPS mit Mama Amazon kommunziert. Da wird man mit vertretbarem Aufwand kaum etwas filtern können. Und selbst wenn Du das SSL aufbrichst, veränderst und wieder zu machst Richtung Amazon: Ich denke, sobald Du da ohne genaues Wissen um das "gesprochene" Protokoll anfängst, Stückchen rauszufiltern, geht das Ding einfach nicht mehr…
-
Hui das ist ja noch gruseliger! Du lässt dann also den Echo Dot einfach so ins Netz raus? Die Fritte hat ja nicht wirklich eine Firewall die abgehend filtern kann, also darf der Knabe quasi alles machen was er will? Uff..
Raus ist mir erst mal nicht so wichtig wie rein zu mir.
Der hängt aber auch nur temporär dort, weil ich Probleme mit Bluetooth / WLAN im 2,4GHz hatte. Darum habe ich den mal auf 5GHz umgezogen. Leider können meine Accesspoints kein 5GHz WLAN. Da werde ich wohl mal umstellen, wahrscheinlich auf Ubiquity und dann kann ich die VLANS entsprechen aufsetzen.Oh da gehts nicht um eleganter, sondern eher, dass du verstehen musst, wie die Regeln bzw. NAT Einstellungen greifen.
Ja, ich glaube da hängt es noch bei mir….
Ergo ist entweder die obere oder untere Regel unnötig. Wird im NAT das Paket bereits umgeschrieben auf die intere Serveradresse ist die Regel unten korrekt.
Habe die obere Regel deaktiviert - funktioniert in der Tat….
Was nicht stimmt: Du musst gar nichts erst zur Firewall lassen und dann irgendwo anders hin. Das wäre nur der Fall wenn die pfSense etwas für die annehmen soll (also als Proxy o.ä. agiert). Wenn das nicht der Fall ist, betrachte wo es herkommt, wo es ankommt (in dem Fall am WAN) und wo es hin will und ggf. wohin es umgeschrieben wird. Dann die Regel entsprechend schreiben. :)
Ok, danke. Ich versuchs… Wahrscheinlich brauche ich noch mal Hilfe ;)
-
Ok, danke. Ich versuchs… Wahrscheinlich brauche ich noch mal Hilfe ;)
Daran solls nicht scheitern. Wie gesagt wichtig beim Verstehen, an welchem Interface und von/zu welcher IP eine Regel konfiguriert sein muss:
- WO (an welchem Interface) kommt es in der pfSense an? -> Auf diesem IF wird die Regel gebraucht. Raus gelassen auf einem anderen Interface wirds automatisch.
- Will ich den Sender begrenzen (also das VON) oder den Empfänger festlegen? -> From oder To definieren
- Dito für Ports. Aber in der Regel sind es sehr selten Quellports die gesetzt werden. Will man Dienste eingrenzen, sind es meistens die Zielports die gemeint sind.
- Ist NAT im Spiel? Dann muss die Regel - sofern nicht eh automatisch angelegt bei Port Forwards bspw. - die Adresse NACH dem NATting enthalten. Also bspw. nicht die WAN Adresse sondern die interne.
That's it - im Normalfall :)
-
Es muss ja offensichtlich ein Paket aus der WAN Schnittstelle nach LAN kommen, ohne das LAN das Paket angefordert hat.
DAS ist die "Magie" der IoT, denn sie halten permanent Kontakt zu ihren Servern und bekommen auf diesem Weg auch Pakete zurück.
Alexa, Harmony und das ganze Zeug gehören in ein separates Subnetz und haben im regulären LAN einfach nichts zu suchen. Da würde ich übrignes auch meinen (Smart-)TV hin verbannen, zzgl. zum BluRay Player und so.Warum man sich Alexa freiwillig in sein Heim stellt wird mir wohl ein ewiges Rätsel bleiben.
-
Warum man sich Alexa freiwillig in sein Heim stellt wird mir wohl ein ewiges Rätsel bleiben.
Es ist unheimlich praktisch. Gerade mit Kindern, die Musik hören möchten. Die Bedienung ist einfach und die Inhalte für 3,99€ auf 40 mio Titel verlockend. Ich denke wenn man es mit einigen Vorbehalten und Vorkehrungen nutzt geht das in Ordnung. Es ist für mich ok, wenn Alexa Seeräuberopa Fabian aus der Wolke streamt, und den Verstärker dazu einschaltet. Selbstverständlich würde ich so einem System nie Zugriff auf Haustür oder Fahrzeug geben. Daher will ich es ja nun auch einsperren.
-
Es ist unheimlich praktisch.
Man opfert also freiwillig seine Privatsphäre und lässt Amazon (…) daheim bei allem und immer zuhören, weil es praktisch ist?
Allmächtiger! … -
OT: Nunja, dass das nicht ganz so "EZ" ist, wie sich das manch einer vorgestellt hat mit den AODs (Always-On-Devices), sieht man ja am ersten Fall in de USA, in welchem Alexa als "digitale Zeugin" aussagen soll. Der Fall eines toten ehem. Polizisten, der angeblich ertrunken sein soll, wurde wichtig, als man Spuren eines Kampfes nachweisen konnte. Brisant: Im Außenbereich des Pools und Whirlpools, wo der Tote gefunden wurde, waren Amazons Echos/Alexas zum MusicStreaming im Einsatz. Jetzt möchte die Polizei per Durchsuchungsbefehl gern von Amazon die Sprachaufzeichnungen, die Alexa zur Tatzeit aufgenommen hat.
-> http://arstechnica.com/tech-policy/2016/12/police-ask-alexa-did-you-witness-a-murder/
=> Amazon hat sich m.W. bis dato nicht geäußert, ob sie der Aufforderung nachkamen und welche Daten Alexa tatsächlich gespeichert hatte.Wieder zurück zum Thema: Eine Unterbringung im eigenen VLAN würde ich da wirklich forcieren und andere geeignete Kandidaten dorthin mitnehmen :)