Hallo, verfolge gerade die Diskussion. Habe aber als null acht fünfzehn Anwender nichts verstanden. Habe jetzt mal nachgeschaut ob ich Webhooks nutze. Siehe da, es sind 3 Anwendugen- ArchivdatenAnomalien, IPS Workfloweditor, TileVisu WetterUhr Kachel.
Muss ich die jetzt zusätzlich absichern? Wenn ja, warum wird das dann nicht in den Anwendungsmodulen gemacht?
Hallo miteinander! Diese Text ist NICHT KI generiert.
Ich habe diesen Thread aus großem Interesse aufmerksam verfolgt. Hier und da hatte ich in der Vergangen auch schon mal dazu fragen gestellt. Nun möchte ich einmal meine Einschätzung abgeben.
Sicherheit ist ein weitläufiger Begriff. Da gibt es nicht schwarz oder weiß. Das ist ein fließender Faktor. Es hängt im Weitesten alles vom Engagement des Angreifers ab. Die Verbreitung der anzugreifenden Software spielt da sicherlich auch noch rein.
Ich habe mich zu meinen und auch anderen Systemen über lange Zeit mit dem Thema Sicherheit beschäftigt, betreue auch mittelgroße Anlagen. Es gibt wahrlich nichts schlimmeres als wenn jemand in die Systeme eindringt. Sicherlich ähnlich schlimm wie ein Einbruch zuhause. Das Thema Sicherheit ist aus meiner Sicht daher immer hoch zu halten. Verbesserungspotential gibt es IMMER.
Da komme ich zum meinen ersten Punkt: Wichtig ist Aufklärung!
Hier sehe ich auf seitens Symcon definitiv noch mehr Notwendigkeit der Transparenz.
Der Connect-Dient ist für mich eine absolute Black-Box. Auf Systeme wo es geht, habe ich den Dienst abgeschaltet. Doch auf einem System musste ich den Dienst leider einschalten, da ein anderer Dienst sonst nicht funktioniert hätte. Ich mag es absolut nicht, wenn ich nicht selber entscheiden kann was Dienste dürfen. Selbst bei Android gibt es mittlerweile zig Sicherheitsprüfungen was Apps dürfen und was nicht. Das geht bei dem Connect-Dienst leider nicht.
Da komme ich zum meinen zweiten Punkt: Einschränkungen einstellen zu können!
Ich vertrete den Standpunkt, dass (fast) kein System ohne Weiteres aus dem Internet erreichbar sein darf. Ich nutze daher zum Zugriff nur über VPN. Das ist heut zu Tage via diverser Systeme und schneller Verbindungen absolut kein Problem mehr. Daher braucht es keine durchgeschleuste Verbindung durch die Firewall mehr.
Da heute viele (oder alle) User hinter einem Router sitzen müsste man natürlich bewusst einen Port öffnen um eine Verbindung aus dem Internet zu einem internen Dienst wie Symcon Connect durchzuschleusen. Das ist für manchen Anwender evtl. aus Unkenntnis schwierig einzurichten. Daher gibt es Anbieter, die eine Art Tunnel „von hinten durch Brust“ mit Hilfe der Software im internen Netz nach außen durchschleusen und damit eine Art Tunnel aufbauen. Das erleichtert natürlich dem Anwender den Zugriff, da er keine Ports öffnen muss - ich persönlich halte das für ein riesiges Problem. Da wird eine Tür ins interne System geöffnet dessen vielen Usern evtl. gar nicht bewusst ist.
Da komme ich zum meinen zweiten Punkt: Dem User sollte es selbst überlassen sein, ob er ein Port öffnet oder die DynDienste von Symcon nutzt! Denn dann kann man selber entscheiden welches Sicherheitsniveau man ansteuert.
Wichtig wäre mir zudem, dass man die Funktionen trennt: Erreichbarkeit von Symcon im internen Netz und andere Dienste die eine Internetverbindung benötigen. So könnte man Systeme und Dienste beschränken (dürfen nur nach außen abfragen, aber nichts von außen annehmen, etc.)
Da komme ich zum meinen dritten Punkt: Erreichbarkeit DynDNS und App-Internetverbindungen trennen
WebHook: Wie ich hier erfahre scheint das ja offensichtlich ein gefährliches Instrument zu sein. Wenn ich hier lese, dass Modul-Ersteller sich nicht einmal über die Gefahren bewusst waren, dann muss man überlegen wie viele Module habe ich installiert wo jetzt eine offene Flanke im eigenen System vorhanden ist.
Da komme ich zum meinen vierten Punkt: Modulen müssen bei der Installation danach fragen ob sie eine Verbindung ins Internet bereitstellen dürfen und Info an den User, dass der WebHook eine Gefahr darstellen kann.
Passwort Mischmasch: Danach habe ich schon mehrfach nach gefragt, verstehe es aber immer noch nicht richtig. Und dabei könnte es eigentlich einfach sein. Wenn ich es richtig verstanden habe, dann kann man bestimmte Dinge nur absichern, wenn man eine Verbindung nach außen bereitstellt.
Dabei kann es so einfach sein: Jede WebView oder Tile-View kann konfiguriert werden mit Passwort. Internes Netz Passwort ja/nein, externes Netz (als nicht eigenes Segment) Passwort ja/nein. Außerdem sollte man auch den Konfigurationszugang absichern können - ebenso: Internes Netz Passwort ja/nein, externes Netz (als nicht eigenes Segment) Passwort ja/nein. Dann ist das einfach klar für jeden. Auch interne Systeme müssen aus meiner Sicht abgesichert werden. Das sind Sicherungen auf zweiter Ebene. Übrigens ist ja langläufig bekannt, dass das Absichern mit Passwörtern so eine Sache ist. 2FA und so weiter. Ich will an dieser Stelle nicht zu weit gehen.
Da komme ich zum meinen fünften Punkt: Absicherungen durch Passwort klarer einbauen
Eine dritte Stufe sind sicherlich auch die Klartextpasswörter im Code. System wie Docker bieten die Möglichkeit die Passwörter aus dem Container rauszuhalten und diese erst in der Config einzubauen und das alles zusätzlich abzusichern. Denn wenn der Container kompromitiert wurde, dann müssen andere Sicherheitsebenen zuverlässig funktionenieren. Es sollte nicht sein, dass User solche Sicherheitsysteme als Module implementieren müssen. Das sollte in Symcon enthalten sein. Symcon ist ein System was naturgemäß die wichtigsten und (intimsten) Dinge im internen Netz (Heimnetz) verschaltet und hat daher vielfach eine besondere Zentrale Funktion. Wird das System gehackt, und das kann man einfach nicht ausschließen (unabhängig vom Grund Userfehler, Backdoor, Programmfehler, etc), siehe großes andere Hersteller hatten da auch schon ihre Probleme, dann müssen andere Systeme dazu beitragen, dass der Schäden nicht zu groß ausfällt. Es wäre schlimm, wenn der Angreifer dann auf Kameras und vielen anderen Dingen zugreifen kann, weil alle Passwörter zugänglich sind.
Da komme ich zum meinen sechsten Punkt: Zwiebelschichten und Passwörter raus
Was sehr förderlich ist, dass bald das Tool der Nachverfolgung kommt: „Wer hat das Licht eingeschaltet“. Diese Situationen hatte ich auch schon mehrfach. Vielfach lässt sich das bisher nicht nachvollziehen. Man will wissen wieso was passiert ist. So kann man die System auch in Blick behalten und man kann erkennen ob es Probleme gibt.
Da komme ich zum meinen siebten Punkt: Nachverfolgung was aktuell passiert und was in der Vergangenheit passiert ist.
Am Ende muss das System sicher funktionieren, dass man auch nicht mehr viel damit zutun hat. Ich glaube die wenigsten User beschäftigen sich wirklich so viel damit wie die Jenigen, die hier fast täglich oder wöchentlich im Forum unterwegs sind.
Klarstellung: Ich finde das Symcon super, aber Verbesserungspotential ist sicherlich noch da. Schon aus Eigeninteresse sollte Symcon ein Anliegen daran haben die Systeme sicher zu halten. Es gibt sicherlich nichts schlimmeres als ein Reputationsschaden nach einem Angriff.
Tja, geht mir genau so 
Hallo @Ian
Welcher Dienst war bzw ist das denn? Bei mir war das Home Connect im Speziellen oder alle Integrationen die OAuth brauchen. Habe jetzt aber nach gesehen und festgestellt das zumindest das Home Connect den OAuth Sever nur zum initialen Token Austausch verwendet und daher habe ich jetzt den Connect Dienst wieder abgeschalten. Das erneuern des Accestokens läuft über einen Refreshtoken der nicht ab zu laufen scheint.
Symcon Connect benötigt keinerlei Portweiterleitung.
Ich betreibe sehr viele Installationen mit deaktiviertem Connect Control. Es ist dem Nutzer seit Bestehen des Connect Dienstes selbst überlassen, ob man diesen aktiviert, oder nicht.
Bitte genau lesen. Ich hatte geschriebe “müsste”. Ich hatte zwei varianten aufgemacht, dass es wünschenswert wäre soetwas als Alternative zu haben, wenn man es denn nutzen will, anstatt dass Symcon einfach selbst durchtunnelt.
Ich betreibe sehr viele Installationen mit deaktiviertem Connect Control. Es ist dem Nutzer seit Bestehen des Connect Dienstes selbst überlassen, ob man diesen aktiviert, oder nicht.
Ja, das ist mir bekannt - habe ich auch so geschrieben. Nur würde ich es als User gerne stärker Selectiv nutzen können, ohne alles öffnen zu müssen. Schaltet man den Connect-Dienst ab, dann geht das allerdings auch mit anderen Nebenwirkungen einher. Bestimmte Module reagieren verzögert, weil sie auf ein Timeout warten.
Was noch so eine Sache ist, dass Symcon offensichtlich über den Dienst auf igrendeine Art Dinge sehen kann von der installierten Instanz, wenn ich in diversen Beiträgen lese, dass man sehen kann welche Fehler zu was auch immer geführt haben. Da frage ich mich, wie tief man in was auf einem System aus der Ferne eingreifen kann. Das könnte eine Gefahr sein, wenn irgendein Zentralsystem von Schergen übernommen würde. Ich möchte hier nichts unterstellen, daher im Konjunktiv. Hier gehts mir nur um Transparenz. Bei einem System was nicht OpenSource ist, gehört eine gewisse Portion Vertrauen dazu. Dieses kann durch Transparenz nochmals gestäkt werden.
Das ist genau die Frage, die man jedem Entwickler jedes Moduls einzeln stellen müsste. Man sieht es als Endanwender dem Modul nicht an, ob das in dieser Hinsicht abgesichert ist.
Ich würde mal vermuten (hoffen), dass beim Modul-Review für Module des Symcon-Stores dieser Aspekt geprüft wird. @paresy
Das habe ich schon verstanden. Hilft aber nichts. Müsste oder muss. Egal. Connect Control benötigt keine Portweiterleitung. Ich kann jetzt nicht sagen, der läuft auf Port 1234 und dafür richte ich eine Weiterleitung von extern ein. Geht einfach nicht. Um die Visualisierung erreichbar zu machen, könnte man Port 3777 weiterleiten. Wäre ein Sicherheitsrisiko und hat mit dem Dienst Connect Control nichts zu tun, denn bei Connect Control gibt es einfach keine Möglichkeit, das extern erreichbar zu machen. Connect Control verbindet sich mit dem Server des Herstellers und ich verbinde mich mit der Ipmagic Adresse. Portweiterleitung spielt keine Rolle in dem Zusammenhang und würde auch nichts helfen.
Ihr redet aneinander vorbei. Ian hatte in dem missverständlichen Satz die Portweiterleitung als schlechte Alternative zu Symcon Connect gemeint.
Naja, wir können hier noch so viel philosophieren. Das sind Programm-Interna.
Am Ende ist es mir persönlich wichtig, das Symcon hier mitliest und ggf. die notwendigen Schlüsse daraus zieht. Das wäre mir wichtig.
Falls Symcon eine Wunsch-/Verbesserungsliste hat, wäre es schön, wenn diese Dinge darin aufgenommen würden.