ich habe gerade fest gestellt das bei Aktivierten Connect Dienst nicht nur die Visus von ausen erreichbat sind sonder auch alle WebHooks. Dies war mir, bis ich mich jetzt, mit dem WebHook control beschäftigt habe nicht so bewusst.
Gibt es da eine Möglichkeit dies zu unterbinden? Wenn nein, sehe ich da ein entsprechendes sicherheits risiko. Schlislich müsste man so ja jedes Modul, das einen Webhook besitzt genau prüfen, ob dies vernünftig ab gesichert ist und selbt die Hooks von IPSView lassen sich aufrufen und man bekommt ohne Authentifizierung eine Antwort.
Ja und? Das sollte man so oder so tun. Egal ob Connect aktiv ist, oder nicht. Angriffsszenarien sind ja nicht nur bei aktiviertem Connect realistisch, sondern immer.
Ich bin echt schockiert. Also mir will nicht in den Kopf, warum man bei deaktiviertem Connect weniger auf Sicherheit achten sollte? Vielleicht kannst du mir das kurz erklären. Sicherheit sollte IMMER groß geschrieben werden.
Wenn alle so denken, definitiv, ja. Aber das Problem sitzt auf Layer 8.
Naja, es ist schon ein entscheidender Unterschied, ob meine Symcon-Installation nur aus meinem Netzwerk erreichbar ist oder aus der ganzen Welt. Natürlich gibt es auch Szenarien, bei denen der Angreifer aus dem eigenen Netzwerk kommt, zum Beispiel, wenn eines der Geräte aus dem Netzwerk übernommen wurde und somit als Brücke in mein Netzwerk dient. Aber bei Netzwerksicherheit geht es nicht darum, keinen Angriffsvektor zu haben (das wäre unmöglich), sondern alle nicht erforderlichen zu unterbinden. Daher wäre es schon sinnvoll, alle Hooks, die ich nicht von außen brauche, erst gar nicht erreichbar zu machen und sich nicht auf eine vermeintliche Absicherung des Hooks zu verlassen.
Ich für meinen Teil habe alle Services (Symcon, Vaultwarden, Immich und Co.) in einem eigenen Netzwerk. Auf diese greife ich dann über einen Reverse Proxy zu bzw. habe für Symcon ein paar Ausnahmen in der Firewall, damit ich auf meine Geräte wie Hue und Sonos zugreifen kann. In dem Reverse Proxy kann ich den Zugriff bestimmter Pfade eines Hosts einschränken oder unterbinden. Dies macht die Angriffsfläche einfach noch kleiner. Diese Einschränkung wird aber obsolet in dem Moment, in dem ich durch den Connect-Dienst den Webserver von Symcon einfach ins Internet hänge.
@DerStandard, wie du siehst, mache ich mir durchaus Gedanken über meine Netzwerksicherheit. Im Gegensatz zu dir; dir ist es ja egal, ob deine Webhooks aus dem Internet erreichbar sind, auch wenn es dazu keinen technischen Grund gibt.
Diese vielen fettgedruckten Wörter und auch allgemein der ganze Beitrag sieht mir irgendwie sehr nach KI aus. Mag auch sein, dass ich mich täusche, aber es sieht sehr danach aus.
Wer bist du denn, dass du diese Aussage treffen kannst? Kennst Du den Quellcode und die dahinterliegenden Strukturen, sodass du sagen kannst, es gibt keinen technischen Grund? Ich glaube nicht.
Ebenso ist es mir nicht egal, ob meine Hooks aus dem Internet erreichbar sind, oder nicht. Ich weiß einfach, dass das Produkt Symcon so aufgebaut ist, dass die Hooks über den Connect erreichbar sind und dass das dann natürlich entsprechend abgesichert werden muss. Es steht ja auch explizit in der Doku, dass eine Authentifizierung empfohlen wird. Von daher würde ich nicht sagen, dass mir das egal ist. Der Hersteller gibt mir ein Connect Control und ein WebHook Control in die Hand und weist mich in der Doku auf die Herangehensweise und die Risiken hin. Was will ich mehr?
Ich schrieb ja auch:
Ebenso zitierte ich einen Teil deines Beitrages und schrieb sinngemäß, dass man die Absicherung immer durchführen sollte, egal ob Connect aktiv ist, oder nicht. Ich würde daher nicht sagen, dass es mir egal ist, was von außen erreichbar ist und was nicht.
Das ich mir keine Gedanken über Netzwerksicherheit mache, kannst du so auch nicht stehenlassen. Aber ich verbuche das für mich mal so, dass deine KI nicht das beste Leseverständnis hat.
Vielleicht ist es nicht jedem Nutzer bewusst, deshalb ist es gut, das mal wieder anzusprechen.
In der Doku ist eine Methode beschrieben, wie man zusätzliche Absicherung einbauen kann, aber nicht wie man die Webhooks generell über Connect sperren kann.
So geht es mir auch. Bei mir laufen eine ganze Reihe von Webhooks. Da sollte ich in der Tat mal genauer hinschauen. Wenn es da eine generelle Sperrmöglichkeit gäbe, wäre es schon sicherer.
Leider ist dieses Sicherheitsrisiko hier mit keinem Wort erwähnt, das sollte nachgeholt werden:
Das könnte insbesondere für die Nutzer zum Problem werden, wo Webhooks eingerichtet werden für Grafana & Co gemäß irgendeiner fremden Anleitung, wo die Nutzer also gar nicht mehr im Detail in die IPS-Doku zu Webhooks reinschauen.
Das mag sein. Es ist ja heutzutage modern geworden, alles einfach zu machen ohne Anleitungen zu lesen.
Ich würde auch sagen, dass es da momentan keine Möglichkeit zu gibt.
Ab Werk gibt es keinen WebHook. Wenn ich dann einen einrichten möchte, schaue ich in die Doku zum WebHook und da steht es. Sogar farbig.
Dann hatte der Beitrag hier ja durchaus einen Sinn, wenn jetzt jeder mal ein bißchen aufräumt
Ja, das ist diese Vollkaskomentalität. Man kann ja nicht mehr erwarten, dass sich der User heutzutage auch mit dem beschäftigt was er tut, sondern einfach macht. Da wäre ein Hinweis tatsächlich abgebracht. Da stimmt ich dir zu.
Ja ich gebe zu das ich meinen Text zur rechtschreib Korektur in die KI geschoben habe und diese leider neben der Korektur auch den text dick geschreiben hat.
naja ich habe dein “Ja,und?” so interpretiert, auch deine weiter ausführung lässt darauf schliesen das du kein Problem damit hast das alle Webhooks von ausen erreichbar sind.
Keine sorge dieser Satz stammt von mir und ist eventuell zu einfach vormuliert.
Ich stimme dir absulut zu, dass man einen Webhook immer absichern sollte aber ich würde trotzdem (im bessten fall zusätlich) unterbinden, dass man überhaupt von ausen auf den Webhook zugreifen kann. Dies würde wieder einem mehrstufigen sicherheitskonzept entsprechen und den Angrifsfläche minimieren.
@DerStandart du hattest um eine erklärung gebenten warum man mit deactiviertem Connect weniger auf Sicherheit achten sollte als mit, daher werde ich es hir noch einmal versuchen:
Ich würde aber eher behaupten man “könnte” weniger auf sicherheit achten, bzw achte ich immer auf sicherheit nur das Ergebnis der evauation ist eventuell ein anderes.
Zu erst einmal sollte man sich ja über legen was will ich schützen → hier ganz klar Symcon Installation und das zu grunde liegende Betriebssystem.
Dann sollte man sich überlegen was kann ein angreifer mit dem system machen, dies geht von Licht An/Aus schlaten bis hin zu System Root.
Zu den Szenarien kann man sich nun überlegen über wechen weg diese möglich sind und Welcher Aufwand, welchem Nutzen (also aus sicht des Hackers ) entgegen steht.
Und der aufwand für einen Hacker ein API aus zu nutzen deren Entpunkt nur aus einem Lokalen netzwerk zu erreichen ist ist ja wohl ungemein höher als wenn er es bequem aus dem Internet erreichen kann. Daher bin ich druch aus gewillt auf eine Authentifikation zu verzichten wenn die API nur aus dem Lokalen netz erreichbar ist und ich auch noch mit IP filter an meinem ReversProxy poder Firewall arbeiten kann.
Letzt endlich kann ich jetzt ja entscheiden ob ich den Connect Diesnt nutze oder nicht aber es bleibt der wunsch einfach in Symcon eine option zu haben auf Pfad eben bestimmen zu können was der Connect diesnt auf ins Symcon weiter leitet oder nicht.
Wir kennen das ja schon … wenn irgendwer sachlich eine Anmerkung macht, dann bist du der erste Fanboy, der das Thema oder den Verbesserungsvorschlag als völlig unbegründet verwirft und ziemlich krass draufhaut. Symcon ist ja perfekt, da gibt es keinerlei Verbesserungspotential.
Und gar nicht so selten kommt später @paresy, versteht das Thema und bringt auch eine gute Lösung.
die Anfrage kommt ab und zu mal und ich verstehe dort deine Anforderung und auch Use-Case. Da dies aber eher komplex ist und einer halben Firewall ähnlich kommt, die wir in Symcon pflegen müssten, wird dies wahrscheinlich nicht zeitnah kommen. Mein Tipp wäre eher die WebHooks auch sauber zu sichern, sodass diese von Extern einfach nicht frei zugänglich sind. IPSView kannst du übrigens auch mit einem Kennwort versehen und dann ist von außen auch alles sicher.
Nee, habe ich auch nicht, denn ich habe im Produktivsystem und in den Systemen meiner Kunden alles vernünftig abgesichert.
Prinzipiell stimme ich dem zu. Aber: heutzutage sind bei so vielen Menschen so viele Geräte im heimischen Netzwerk, für welche ich nicht meine Hand ins Feuer legen möchte. Weiß man, was der Hersteller des Staubsaugerroboters im Schilde führt? Heute ist ja fast jedes Gerät im WLAN. Mittlerweile gibt es schon GU10 Leuchtmittel mit WLAN Konnektivität. Von daher wäre und ist es mir prinzipiell egal, ob ein Connect aktiv ist oder nicht. Ich sichere die Installationen ab. Fertig.
Eine Checkbox “über Connect erreichbar” pro WebHook hätte echt Charme. Aber ich vermute, die darunter liegende Technik wird eine Umsetzung nicht einfach so mal eben möglich machen. Vielleicht kann @paresy das mal als Featurewunsch notieren.
Der Beitrag war sachlich, da stimme ich dir noch zu. Bis zu der Aussage, dass man ja jedes Modul, was einen WebHook besitzt, auf Absicherung prüfen müsse. An der Stelle bin ich ausgestiegen, da anscheinend diese Prüfung auf Sicherheit beim Ersteller dieses Beitrages ein Unding ist bzw. er diese gar nicht durchführen möchte.
Ich persönlich sehe es aber als selbstverständlich an, dass man sich mit Sicherheit beschäftigt. Noch dazu, da es in der Dokumentation des WebHook Control (worum es hier ja geht) ja explizit erwähnt ist. Ich äußerte mich dazu, dass das Problem auf Layer 8 sitzt und stimmte später zu, dass ein Hinweis wahrscheinlich tatsächlich angebracht wäre.
Dir scheint an der Stelle auch ein wenig das Leseverständnis zu fehlen. Ich habe niemals gesagt, dass der Verbesserungsvorschlag unbegründet ist. Nirgends. Ich habe mich bzgl der Anschuldigung der KI gewehrt, dass ich mich anscheinend nicht um Netzwerksicherheit kümmere. Ebenso habe ich darauf hingewiesen, dass exakt dokumentiert ist, dass eine Authentifizierung in den WebHook einzubauen ist. Danach führte ich aus, dass ich meine WebHooks vernünftig absichere. Weiter ging es damit, dass dies nicht unter “Sicherheit” in der Doku zu finden ist, da diese Lücke nicht ab Werk vorhanden ist, sondern der User sie ja bewusst aufreißt, wenn er einen ungesicherten WebHook anlegt. Deinen Beitrag, in dem Du sagst, dass es gut ist, das mal wieder anzusprechen, habe ich mit Herzchen markiert. Keine Spur von Fanboy.
Wo sage ich denn, dass der Verbesserungsvorschlag unbegründet ist? Das müsstest Du mir mal zeigen. Das Gegenteil ist der Fall. Aber wie ich ja schon vermutet habe, ist das Lesen und Verstehen von Beiträgen heute nicht gerade einer deiner Stärken.
Ich habe nirgends krass draufgehauen. Ich habe sachlich zu allem hier Stellung bezogen, Vorkommnisse in der Doku gezeigt und aufgezeigt, dass ein Hinweis beim Anlegen eines WebHooks einer Vollkaskomentalität für Benutzer entspricht, die denken sie könnten alles ohne einen Blick ins Handbuch zu werfen.
Wir hatten das Thema letztens auch schon mal. Scheinst Du aber auch nicht gelesen oder nicht verstanden zu haben. Traurig eigentlich. Ich schrieb letztens irgendwo sinngemäß, dass ich auch nicht immer mit allem einverstanden bin, was aus Lübeck kommt. Ich wiederhole das jetzt aber hier nicht noch mal.
Volker, wir halten einfach fest: die Software die aus deinem Haus kommt ist perfekt. Du bist der perfekte Softwareentwickler und Du würdest sowieso alles ganz anders machen. Alle Softwarebuden, die nicht so arbeiten wie es deinem Ideal entspricht, die können nichts oder machen es falsch. Das ist doch das, was du sagen möchtest? Vielleicht hab ich da jetzt auch Probleme mit meinem Leseverständnis oder vielleicht hab ich die rosarote Fanboybrille noch auf. Man weiß es nicht. Falls ich da jetzt irgendwas falsch interpretiert habe oder dir zu Nahe getreten bin, dann tut es mir leid und dann bitte ich hiermit in aller Form um Entschuldigung.
Das würde mir schon reichen. Wenn du da ein gutes Beispiel zur Absicherung hättest, wäre das toll. Momentan weiß ich noch nicht einmal, wie ich die Webhooks auf Sicherheit prüfen kann (habe aber auch die KI noch nicht gefragt ). Auch da wäre ein Beispiel nicht schlecht.
@paresy Danke für die Info, das ist echt schade das man für die verwendung weniger Module (in meinem Fall HomeConect) ein solches einfalls Tor zu öffen.
Bei euren Visualisierungen prüft man ihr ja auch ob ein passwort gesetzt ist und blockiert wenn nicht die verbindung. So eine Funktion wäre doch auch bei den Wbhooks mach bar nur nicht auf password eben sonder mit einer CheckBox.
Hier ein Aspekt dazu. Wenn ich als Endanwender ein Modul wie GrafanaConnect oder NetatmoWeatherIO installiere, dann installiert das automatisch Webhooks, davon bekomme ich als Endanwender ggf. gar nichts mit. Ob und wie der Ersteller des Moduls das abgesichert hat kann ich als Endanwender erstmal nicht überblicken.
@paresy Danke für die Info, ich habe für mein IPS View ein password vergeben dennoch antwortet die
Das ist durch aus korekt und daher machen wir uns ja gedanken um die Sicherheit unseres systemes wie man an der diskusion ja erkennen kann.
Nur ein ist sicher in meinem Haus habe ich eventuell 100 geräte die Potenziell schindluder treiben ab werk oder weil sie gehäckt wurden, im Internet habe ich Millionen geräte, da komme ich für meienn Teil schon zu einer anderen Risiko bewertung. Zu dem habe ich ja ausführlich geschildert wie ich mein Symcon Lokal vor dem bösen netzwerk der Endgeräte und Spielereien (Sonos, hue und co) schütze.
Das ist richtig aber es geht nicht ohne den Connect Dienst und genau das ist ja mein Punkt.
Ich habe keine Websooket den ich aus dem Interent erreichen muss aber kann nicht verhindern das sie es sind wenn ich das HomeConect und somit den Connect Dienst nutzen will.
