NEWS
Frage zur Sicherheitsarchitektur
-
Adapter können meines Wissens nach auf jedes Objekt aus der States DB zugreifen, sonst wären Funktionalitäten wie z.B. Backitup bietet an via Telegram Adapter was zu schicken nicht möglich. Nur worum genau geht es dir? Also um welches Szenario?
-
Hi,
korrekt, Adapter haben generell eine sehr hohe Zugriffsstufe und können auf nahezu alles zugreifen. Nahezu alle Adapter sind Open-Source, von daher kann (und wird) auch gecheckt was Adapter so tun. natürlich ist das kein 100%iger Schutz vor einem "bösen Entwickler"
Wir haben die Thematik "Zugriffsschutz für Sensible Adapter-Konfigurationsdaten" erst vor kurzem diskutiert und wollen hier mit https://github.com/ioBroker/ioBroker.js … issues/250 mehr Sicherheit schaffen. Ist geplant für js-controller 2.0 an dem aktiv bereits entwickelt wird. Damit kann ein Adapterentwickler die Objekteigenschaften definieren die "sensibel" sind und diese werden nur Ihm selbst bereitgestellt und sonst rausgemnommen.
Das ist zwar auch kein 1000%-Schutz aber besser als aktuell.
Aber ja, was genau ist denn dein Szenario, vllt gibt es ja schon noch andere Dinge die greifen.
Ingo
-
Hi Apolon77,
vielen Dank, ich bin bei einem Video zum Nachdencken gekommen was möglich wäre, wenn man davon ausgeht das ein Adapter "malicious" sein könnte.
Ich gebe Dir recht das durch open source es möglich ist die Adapter zu prüfen aber das sehr großer Aufwand und das muss jedem Update wieder prüfen.
Weiterhin besteht die Möglichkeit bei Adaptern die Daten aus dem Internet laden den Schadcode erst nachzuladen also ihn gar nicht im repo zu haben.
Mein erster Gedanke waren Zugangsdaten beim Alexa2 Adapter. Wenn man hier nicht mit dem cookie arbeitet wäre es möglich die Zugangsdaten von Amazon zu stehlen. Ist ja gleich mit dem Kennwort für Alexa (wenn es eine Möglichkeit gibt ein anderes pwd für Alexa zu verwenden ist mir das nicht bekannt).
Eine weitere Möglichkeit wäre bsp. ein Türschloss zu öffnen, oder die Alarmanlage ausschalten.
Es gibt bestimmt noch eine ganze Reihe weitere Objekte die eine Überlegung Wert sind ob sie sicherheitstechnisch relevant sein könnten.
Der Ansatz mit dem "Zugriffsschutz für Sensible Adapter-Konfigurationsdaten" ist ein guter Anfang. Super das ihr Euch dazu schon Gedanken gemacht habt.
Weiterhin wäre es gut wenn es bestimmte Objekte gäbe, die man zusätzlich sichern könnten, das sie entweder nur vom eigenen Adapter gelesen/geschrieben werden dürfen oder nur durch andere definierbare andere Objekte verändert werden könnten.
Velleicht ist es ein Ansatz das man bestimmten adapter/scripten/node red erlaub kann Werte ausserhalb des eigenen Adapters zu verändern. Dann müsste immer der Weg über einen -hoffentlich- kontrollierbaren Punkt laufen.
Es wäre aber sehr gut wenn es standardmässig nicht möglich wäre auf Kennwörter anderer Adapter zuzugreifen und wenn man genau sagen könnte: diesem Adapter vertraue ich der darf alles, den den ich aber grade, der soll aber bitte nichts anderes auslesen/steuern können als seine eigenen Objekte.
viele Grüße
Jens
-
Hi,
ein "böser" Adapter würde so einiges torpedieren, die Frage ist aber ob eine "Vollsicherheit" wirklich eine Alternative ist die am Ende noch Benutzbar ist. Diesen Spagat versuchen wir zu erreichen.
Natürlich wäre das sauberste wenn jeder Adapter zu 100% weggekapselt wäre und der User jegliche Zugriffe des Adapters auf Objekte oder States anderer Adapter im Vorfeld genehmigen müsste. Effektiv sind es auch eher wenige Adapter die so etwas dann bräuchten. ABER dann käme der Admin-Adapter oder alle Visualisierungen oder APIs die wieder Zugriff brauchen und spätestens diese es auf alle haben (müssen). Sonst wäre Sie hinfällig.
Am Ende - und ich fürchte jegliche Versuche Dinge in Betriebssystemen "zu stark" abzusichern haben es gezeigt - klicken die meisten User eh alles weg was Sie gefragt werden. Oder man müsste "ausgewählten Adaptern" doch wieder Vollzugriff geben.
Zuletzt auch der hohe modulare und offenen Ansatz von ioBroker macht es ohne sehr große Anstrengungen sehr schwierig hier etwas wirklich sicheres zu tun.
Die Frage ist also: Was ist sinnvoll UND bringt auch eine echte Sicherheit.
Alle Adapter die externen Datenzugriff erlauben (Visualisierungen, APIs u.ä.) sind durch das Rechtekonzept (was wohl weit unter 1% der User überhaupt nutzen wollen) abzusichern.
Die Absicherung der Adapter-Settings wird kommen, für den Rest bräuchte man erst mal ein (funktionierendes) umfassendes Konzept und dann könnte man weitersehen.
Ingo
-
Hallo zusammen,
gut das dieses Thema hier gerade besprochen wird. Ich habe letztes Wochenende damit begonnen mich mit ioBroker auseinander zu setzen und war wirklich geschockt über die grundlegenden Empfehlungen die hier so getroffen werden. Und ich bin dadurch leider fast überzeugt, dass ioBroker früher oder später ein Auslöser für blinken Lights wird.
In viele Tutorials wird folgende Vorgehensweise vorgeschlagen:
-
/etc/ssh/shhd_config -> setze PermitRootLogin auf "yes" (Gänsehaut, das geht mal garnicht), wenn der Raspi am Internet hängt gehört hier "no" rein.
-
/opt/iobroker/ setzen der Berechtigung des Ordners auf "777". Absolut wahnsinnig, jetzt darf wirklich jeder in diesem Ordner alles machen. Inklusive Schadsoftware hineinschreiben. Man muss nur irgendeinen Benutzer auf den Raspi hacken.
-
ioBroker muss als root laufen… (? WTF) klar es ist der Ordner /opt/, aber muss das sein. Was dabei das Schlimmste ist, ist die Tatsache, dass man durch eine Sicherheitslücke in ioBroker und z.B. installierten Adapter "ioBroker Simple Terminal Adapter" direkten Root-Zugriff bekommt ohne auch nur Passwörter zu verwenden. Klar es werden ständig andere Ports für jeden Adapter verwendet, aber das ist für mich nur Kosmetik.
Wäre es nicht tatsächlich sinnvoll den ioBroker im Homeverzeichnis eines extra erstellten ioBroker Users zu erstellen? Ich meine root und Internet + chown 777 + sshd_config = blinken lights. Es gab in letzter Zeit soviele Angriffe, da muss doch eine Entwicklung gerader solcher Dinge extra darauf ausgelegt werden. So dass diese eben nicht einfach gehackt werden können und dann auch noch sensible Daten abgegriffen und evtl. Schließsysteme usw. missbraucht werden. Und wieder das Thema root. Ich meine einmal gelernt zu haben: "Nichts läuft unter root, außer root!".
-
-
Hi,
zu diesem Thema gab es auch schon andere Threads und auch schon "Entwicklungen" es zu verbessern. Kann aich hier nur dagen: Verbesserungen in Sicht und geplant.
Ein Hauptthema ist das einige Adapter Root-Rechte benötigen weil Sie sonst nicht laufen oder sonst nicht installiert werden können. Es gibt Adapterspezifische Dinge die man tun kann das es dann doch tut, aber das ist damit nicht mehr "so einfach". ;-)
Das soll auch keineswegs eine "Entschuldigung" sein, sehr viel diesbezüglich ist "Historisch so gewachsen". Das zu sändern ist immer ein etwas größeres Thema.
Seit npm 5 bzw 6 ist es an sich sogar kontraproduktiv es als root zu machen und der Installer hat diesbezüglich auch schon Anpassungen erfahren.
Dies generell umzustellen und sinnvolle Wege anzubieten die von jedem User befolgt werden können ist aber eine etwas größere Thematik. Auch hier ist einiges geplant, so als Beispiele seien genannt:
https://github.com/ioBroker/ioBroker/issues/48
https://github.com/ioBroker/ioBroker.js … issues/162
https://github.com/ioBroker/ioBroker/issues/64
Das ganze ist bereits jetzt als Installation als User und ohne root möglich und es gibt auch Threads im Forum dazu und einige User (die etwas "erfahreneren" machen das auch schon.
Wie Ihr seht sind viele Dinge geplant, wer also Unterstützen will ist herzlich willkommen Wissen, Code und Brain beizusteuern!
Ingo
-
Hmm wir sollten in dieser discussion jetzt aber nicht 2 verschiedenen Themen mit einander vermischen.
-
Absicherung des Datenzugangs innerhalb der Software zwischen Adaptern
-
die Zugriffsstruktur des Datei systems
Thema 2 ist eine andere Geschichte als Thema dieses topics und auch ich stimme zu das 777 nicht ideal ist.
Lest euch dazu Mal die bisherigen discussion durch und Hilfe/Anregungen dazu werden immer sehr gerne gesehen !
Zurück zu dem Adaptern, mja …
Auch hier würde ich probieren die discussion in Detail auseinander zu ziehen, zB:
- Zugangsdaten welchen durch einen Adapter benutzt werden:
Es sollte
A) niemals der Fall sein das diese Daten Plains Text auf dem Filesystem oder Datenbank hinterlegt sind, leider ist dies bei einigen Adaptern der Fall (zB unifi Adapter habe ich letztens gemerkt)
B) Adapter sollten nie die Möglichkeit haben, auch wen diese verschlüsselt sind, zugangsdaten eines anderen ein zu lesen (kan mir auch keine Funktion vorstellen wobei das nötig ist)
- welche objecte/states darf ein Adapter sehen/beeinflussen.
Das ist ein sehr schwieriges Thema, zum einen muss es brauchbar sein und wen ein neu Anwender erst alle verschiedene objecte/states freigeben muss wird es sehr schnell unbrauchbar und für "otto normal Verbraucher" kaum zu übersehen.
Dazu gibt es Adapter die halt auch alles sehen können müssen (JavaScript/Admin Mal als Beispiel)
Ich bin sehr vertraut innerhalb der Software Entwicklung mit internen ACL's (Access Control list) und da muss man immer überwiegen was warum und wie bei einem derart integralen Software wie ioBroker und den verschiedenen enduserns (und deren IT Kenntnisse) ist das ne schwierige Angelegenheit.
Auch darin muss ich Apollon rechtgeben, man müsste das Mal komplett ausarbeiten auf Papier/whiteboard und dan entscheiden was sinnvol ist und welche ideeën es gibt zur Umsetzung.
~Dutch
Sent from my iPhone using Tapatalk
-
-
Wenn wir hier schon mal beim Thema Sicherheit sind, evtl könnte einer der Netzwerkexperten mal eine Anleitung geben, wie man sein Netzwerk rund um Iobroker absichert. Klar, ich könnte es in ein eigenes Netz, z.B. Gast packen, damit wären dann aber wieder Verbindungsprobleme zum Tv etc. gegeben.
Alles in einem Netz bedeutet aber auch wieder, ein 'böser' Adapter hat direkt Zugriff aufs gesamte Netz - das Thema ist leider mit viel Halbwissen behaftet.
-
Hallo Ingo,
danke für deine ehrliche Antwort. ;) Ich weiß, dass es nicht so einfach ist, gerade Einsteigern es so leicht wie möglich zu machen. Der ioBroker hat in dieser Hinsicht ein riesiges Potential. Wenn ich das einmal mit einem anderen Produkt vergleiche, hat ioBroker sogar die Nase vorn. Zumindest was den Bedienerkomfort angeht. Aber sicherlich kann ioBroker auch hier noch einiges für die Sicherheit tun.
Es war auch eher die Bedienung des ioBroker, die mich überhaupt dazu veranlasste mich damit zu beschäftigen. Schützt wenigstens zuerst das Admin-Panel. Selbst meine Easy-ESPs verlangen ein Kennwort. Und die kann man noch lange nicht mit der Power vergleichen, welche ein Raspi bietet.
Am Ende möchte ich nur sagen: Die Kette ist nur so stark, wie ihr schwächstes Glied. ;)
mfg
Ronny
-
Hmm wir sollten in dieser discussion jetzt aber nicht 2 verschiedenen Themen mit einander vermischen.
-
Absicherung des Datenzugangs innerhalb der Software zwischen Adaptern
-
die Zugriffsstruktur des Datei systems `
Entschuldigung Dutch, ich wollte dich nicht übergehen, war aber mit meiner Begründung zeitlich zwischen der von Ingo und deiner. Natürlich hast du Recht. Man sollte das nicht vermischen. Aber vielleicht sollte man die Tutorialersteller darauf hinweisen, dass z.B. "chmod 777 Ordner" nicht wirklich zielführend ist. Diese werden aber gerade als erstes angeboten, siehe: www.smarthome****.de
Das soll auch kein "Fingerzeig" sein.
Ich beende hier jetzt die Diskussion um das Dateisystem. Ich werde mich aber weiter mit ioBroker beschäftigen, weil gerade ein Projekt nach einer innovativen Homeautomation sucht und andere, leider aufgrund anderer Komplexitäten herausfallen.
Gruß
-
-
War nicht böse gemeint verstehe mich bitte nicht falsch :)
Das Thema ist auf jedenfall auch eine Baustelle woran gearbeitet werde müsste und da ist jede Bemerkung / Info hilfreich.
Wollte nur vermeiden das wir den roten Faden diesen topics verlieren freue mich aber auf Mehr Beiträge von dir bezüglich diesem Thema ! :)
@Schuko
Leider muss ich zu deiner Frage kannst klar sagen : tut mir leid aber NEIN.
Wir sollten uns als Betreiber des Forums beziehungsweise Ersteller algemein Doku der Branding ioBroker von der artigen Details distanzieren.
Ja zur Software und Einrichtung können wir alles sagen, aber Netzwerk hat nichts mit ioBroker zu tun und ist ein anderes Special-Gebiet.
Die Gesetze sind halt leider auch so wen da was als Grundlage veröffentlicht würd und genau diese Konfiguration bewirkt aus Grund x financiellen schaden ist man m Ende der strafbare …
Also Tips im Forum ja, ich zB darf das noch nicht einmal da ich diplomierter sicherheits Techniker bin.
Wen ich zB ne Doku dazu erstelle und sich etwas ändert in einem Jahr und ich vergesse das zu updaten und dadurch entsteht schaden könnte ich sogar meine Lizenz und Arbeitsplatz verlieren
OK genug offtopic Mal zurück zum Thema bin gespannt ob noch andere gute Vorschläge zum Thema Security der Software haben
Sent from my iPhone using Tapatalk
-
Ich glaube da hast du was falsch verstanden.
1. Muss das keiner von euch machen und dokumentieren, es gibt ja auch andere User im Forum.
2. Muss das keine Schritt für Schritt Anleitung sein, war vielleicht auch falsch von mir ausgedrückt, gedacht war da mehr so in die Richtung, das man was an die Hand gibt, bzgl. der Möglichkeiten (z.B.Vlan etc.) . Zum einen wird keiner seine Tricks aus dem Beruf verraten, zum anderen ist jedes Netzwerk und seine Komponenten individuell. Gemeint war halt Allgemein, genau Einlesen muss sich dann schon jeder selber, was aber natürlich um einiges leichter ist, wenn man weiß, in welche Richtung man suchen muß. ;)
-
Hallo Ingo,
danke für deine ehrliche Antwort. ;) Ich weiß, dass es nicht so einfach ist, gerade Einsteigern es so leicht wie möglich zu machen. Der ioBroker hat in dieser Hinsicht ein riesiges Potential. Wenn ich das einmal mit einem anderen Produkt vergleiche, hat ioBroker sogar die Nase vorn. Zumindest was den Bedienerkomfort angeht. Aber sicherlich kann ioBroker auch hier noch einiges für die Sicherheit tun.
Es war auch eher die Bedienung des ioBroker, die mich überhaupt dazu veranlasste mich damit zu beschäftigen. Schützt wenigstens zuerst das Admin-Panel. Selbst meine Easy-ESPs verlangen ein Kennwort. Und die kann man noch lange nicht mit der Power vergleichen, welche ein Raspi bietet.
Am Ende möchte ich nur sagen: Die Kette ist nur so stark, wie ihr schwächstes Glied. ;) `
Hi Sio_x,
ja Admin "Standardmäßig absichern" ist auch ein Thema. Wobei das jeder User mit wenigen Klicks hinbekommt :-)
Vor allem zum Thema "Installation ohne sudo" oder den anderen oben angesprochenen Themen ist es garantiert cool wenn jemand eine Art "So habe ich es gescheit gemacht" Artikel für User im Forum schreibt. Auch ohne "Tutorial" Charaker und mit einem Disclaimer ist das generell ein großer Mehrwert für alle :-)
Ingo
-
Ich glaube da hast du was falsch verstanden. `
Ehm ja jetzt muss ich auch Mal mit der pobacke bloße und mich Mal korrigieren da gebe ich dir Recht (und andere haben mich da auch drauf gewiesen danke dafür!).
Manchmal hat man so nen Tag da kommt nicht richtig was gescheites raus oder man schaut zu schwarz weiß sorry dafür.
Also ja man könnte Mal best practise/usw Case machen eines Aufbaus, ich habe das ja im Grunde genommen auch Mal in einen Unify web-seminar gemacht für Grundeinstellungen.
Habe mich dan auch verpflichtet mich Mal mit Homoran Zusammensetzen zur "practise Case" Netzwerk und Sicherheit und wir werden bezüglich dieses Themas Mal was probieren auf die Beine zu stellen um Netzwerke, Gäste/iot, Firewall settings und externen Zugang zu behandeln.
Also an alle bitte schuldigung für mein etwas zu kurz durch die Kurve geschossenen Bemerkung werde dan dazu Mal was auf die Beine stellen als Wiedergutmachung ;)
Sent from my iPhone using Tapatalk
-
-
/opt/iobroker/ setzen der Berechtigung des Ordners auf "777". Absolut wahnsinnig, jetzt darf wirklich jeder in diesem Ordner alles machen. Inklusive Schadsoftware hineinschreiben. Man muss nur irgendeinen Benutzer auf den Raspi hacken.
-
ioBroker muss als root laufen… (? WTF) klar es ist der Ordner /opt/, aber muss das sein. Was dabei das Schlimmste ist, ist die Tatsache, dass man durch eine Sicherheitslücke in ioBroker und z.B. installierten Adapter "ioBroker Simple Terminal Adapter" direkten Root-Zugriff bekommt ohne auch nur Passwörter zu verwenden. Klar es werden ständig andere Ports für jeden Adapter verwendet, aber das ist für mich nur Kosmetik. `
Kurz hierzu: Apollon hats schon verlinkt und die Dokumentation ist diesbezüglich nicht mehr aktuell. Es gibt inzwischen eine neue Installationsroutine, die
1. dem User einiges abnimmt und
2. ioBroker as user "iobroker" ausführt sowie diesen User zum Owner von /opt/iobroker macht anstatt chmod 777.
100% kommen wir noch nicht an sudo/root vorbei, so muss bspw. der zwave-Adapter zusätzliche Systemmodule installieren und
sudo npm install …wird leider gerne noch als die Holzhammermethode empfohlen. -
-
Ich glaube da hast du was falsch verstanden. `
Ehm ja jetzt muss ich auch Mal mit der pobacke bloße und mich Mal korrigieren da gebe ich dir Recht (und andere haben mich da auch drauf gewiesen danke dafür!).
Manchmal hat man so nen Tag da kommt nicht richtig was gescheites raus oder man schaut zu schwarz weiß sorry dafür.
Also ja man könnte Mal best practise/usw Case machen eines Aufbaus, ich habe das ja im Grunde genommen auch Mal in einen Unify web-seminar gemacht für Grundeinstellungen.
Habe mich dan auch verpflichtet mich Mal mit Homoran Zusammensetzen zur "practise Case" Netzwerk und Sicherheit und wir werden bezüglich dieses Themas Mal was probieren auf die Beine zu stellen um Netzwerke, Gäste/iot, Firewall settings und externen Zugang zu behandeln.
Also an alle bitte schuldigung für mein etwas zu kurz durch die Kurve geschossenen Bemerkung werde dan dazu Mal was auf die Beine stellen als Wiedergutmachung ;)
Sent from my iPhone using Tapatalk `
Ich glaube Entschuldigungen sind hier nicht nötig, wie du schon schreibst, jeder hat mal nen Tag, wo er/sie nicht auf der Höhe ist und zum anderen darf man nie vergessen, wir schreiben hier, das heißt jeder interpretiert in einen gelesenen Text andere Emotionen rein.
Auf jeden Fall freue ich mich drauf, diesbezüglich was von dir zu lesen.
428
Online32.7k
Benutzer82.4k
Themen1.3m
Beiträge