mschlenstedt / Loxberry

Current stable Branch is: *** Please see Releases *** Current developer Branch is: *** master ***
Apache License 2.0
77 stars 27 forks source link

Passwortkomplexität #144

Closed christianTF closed 6 years ago

christianTF commented 8 years ago

Ich muss mich dem Kommentar von, ich glaube eisenkarl, anschließen.

Ich weiß, wir sind sensibilisiert durch das admin/admin-Thema von Loxone. Loxone als Hersteller setzt das Kennwort so und das wird dann "global" verwendet.

Ich verstehe auch, dass ein öffentliches Forum seine Plattform vor Spam schützen muss, oder ein Internet-Händler seinen Shop vor Missbrauch.

Aber wenn ich nach dem Vergeben meines Kennwort gefragt werde, auf meinem eigenen Raspberry, in meinem eigenen LAN, in meinem eigenen Haus, dann möchte ich mir das nicht "von extern" aufzwingen lassen, was ich bei mir verwende. Zudem wird das root-Passwort sowieso generiert. Die Warnung kann ruhig dort stehen, und von mir aus kommt noch eine Zwischenfrage als Sicherheitshinweis, wenn ich ein schlechtes Kennwort vergebe.

Das Passwort muss aus Gross- und Kleinbuchstaben sowie aus Buchstaben und Zahlen und min. 5 Zeichen bestehen. Es dürfen nur folgende Sonderzeichen verwendet werden: -_,.;:!?&()?+§%=

lg, Christian

mschlenstedt commented 8 years ago

Ich bin da etwas zwiegespalten:

Ich gebe Euch recht, wenn jemand den LoxBerry rein lokal verwendet. ABER: Es sind in Zukunft sicherlich auch Plugins denkbar, die den LoxBerry extern einbinden (VPN, DynDNS, als Ersatz zum CloudDNS, etc. pp.). Wenn jemand durch ein unsicheres Passwort auf den LoxBerry zugreifen kann, dann hat er gleichzeitig auch Zugriff auf die Login-Daten des Mailservers und des Miniservers. Ich finde das nicht so prickelnd...

Ich sehe das jetzt auch nicht soooo kritisch an: Im Moment spielen wir alle viel am LoxBerry herum oder entwickeln darauf. Aber wie oft wird später der "normale User"sich wirklich auf der Weboberfläche einloggen und irgend etwas machen?/instzallieren? Das word doch nur die Ausnahme sein, oder?

Als Vorschlag hätte ich:

  1. Wir lassen die sichere Passwort-Abfrage im Basissystem drin
  2. Über ein Plugin "Un-Secure-Plugin" o.ä. kann man die Passwortabfrage des Webinterface komplett deaktivieren (Root und Konsolen-Login bleiben bestehen) oder aber Alternativ ein unsicheres Passwort vergeben (Web- und Konsolen-Login).

Damit muss ein Benutzer explizit das Plugin installieren, um die Sicherheitsfunktionen außer Kraft zu setzen, was für mich nochmals eine höhere Hürde darstellt.

Und wo wir beim Thema sind: Es gibt von @Woersty einen Vorschlag bei der Plugininstallation das Rootpasswort mit anzufragen, damit man dann das neue "post_install_root.sh"-Skript mit Rootrechten auszuführen kann. Alternativ wäre das Skript jeweils bei der Installation an eine bestimmte Stelle im Dateisystem zu kopieren und per Sudo permanent freizugeben. Dann öffnet man Malware aber Tür und Tor...

Was denkt ihr darüber?

christianTF commented 8 years ago

Bezüglich Sicherheit hast du wahrscheinlich eh recht - wir installieren jetzt ja dauernd, darum fällt es lästig auf.

Bezüglich post_install_root.sh halte ich Variante 2 für besser. Der Benutzer hat sich eh schon angemeldet. In ein Verzeichnis kopieren, das in sudoers.d freigegeben ist. Warum das für Malware gefährlich ist, erschließt sich mir nicht (du meinst über "böse" Plugins?)

mschlenstedt commented 8 years ago

Ja, zum Beispiel. Im Prinzip würdest Du den Root-Account aushebeln: Als User LoxBerry könntest Du alles mögliche mit Rootrechten auf dem System ausführen, indem Du ein entsprechendes Script in dieses Verzeichnis kopierst und dann per sudo ausführst,

Saomit kann ein "böses" Plugin alles als root ausführen (aber im Prinzip schon heute über den Daemon), aber auch irgend jemand, der Dein (möglicherweise schwaches) LoxBerry-Passwort ausliest oder per BruteForce ermittelt, kann alles als root auf dem System tun.

Von der Sicherheit her wäre somit das Abfragen des Rootpassworts am sichersten, aber das ist eben auch extrem unkonfortabel...

Eine richtig gute/bessere Idee habe ich im Moment aber auch nicht wirklich.

Woersty commented 8 years ago

Ich finde die Idee von Wörsty mit der Abfrage des Root PW bei Plugin Installation am Besten, da damit auch die Daemon Sicherheitslücke geschlossen wird. Und ob ein Plugin Rootrechte benötigt oder nicht kann man ja in die plugin.cfg mit aufnehmen.

christianTF commented 8 years ago

Dritte Person, oder gibt's zwei Wörsty's? ;-)

Ich bin in der Zwischenzeit auch überzeugt vom Plugin-Installations-Passwort. Vielleicht könnt ihr es ein bisschen komfortabler machen, indem ihr das PW einmal abfragt, ein Session-Cookie speichert und das bei den nächsten Plugin-Installationen abfragt. Dann braucht man zumindest nur 1x pro Session ein PW eingeben.

mschlenstedt commented 8 years ago

Das Zwischenspeichern wäre tetchnisch kein Problem (Sessions werden schon während der Installation genutzt), würde aber bedeuten das Root-Passwort im Klartext zu speichern...

Sobald ich beruflich wieder etwas Luft habe nehme ich mich dem Thema mal an. Vielleicht fällt mir noch etwas schlaues ein ;-)

christianTF commented 8 years ago

Ich weiß es auch nicht. Wenn man LoxBerry installiert, und dann fünf Plugins, und man 5x das Passwort eingeben muss, da weiß ich bestimmt, dass das jeden nervt. Das lädt nur dazu ein, dass man das root-PW auch auf was Einfaches setzt.

Die Frage ist eigentlich, was man vor wem beschützen muss/will.

Wenn einer die Credentials des Webusers herausbekommt, hat er Zugriff auf die Datenbank mit den MS-Credentials, auf SSH und Samba-Share mit allen Configs der Plugins. Aber wir schützen den LoxBerry davor, dass ein Böser kein böses Plugin installiert?

10x kann jemand meinen LoxBerry hacken, solang er nicht an die Credentials des MS kommt. Wurscht ob der root ist oder nicht.

Woersty commented 8 years ago

Da hätte ich schon mal gleich die Idee für ein neues Plugin: Es wird eine eMail gesendet, wenn ein falsches PW eingegeben wird.

Außerdem komme ich auf #8 zurück. Wenn man den Loxberry grundsätzlich für Netzwerk-Logins mit Passwörtern abriegelt und nur noch von der Konsole Logins mit PW zulässt sowie den Zugriff generell nur per SSH Key erlaubt, wäre das schon mal ein guter Schritt, denke ich. Außerdem könnte man das noch erweitern und den Zugriff auf das Admin-Interface nur per SSL/HTTPS TLS1.2 mit Client Zertifikat erlauben.

Das ist natürlich etwas Aufwand bei der Einrichtung aber macht es beim Betrieb umso komfortabler.

Gruß

christianTF commented 8 years ago

Mir fällt da gerade wieder eine einfache und pragmatische Lösung ein, die ich Loxone für den MS auch schon mal für das Login mit admin/admin vorgeschlagen habe:

Erlaube generell keine Plugin-Installation, wenn der Remote-Host nicht im lokalen Subnetz ist.

Würde heißen, alle lokalen IPs und Subnets der aktiven Interfaces abrufen, mit der Remote-IP vergleichen, der im Header mitkommt, und wenn das nicht passt, gleich mit einem Dialog blocken.

Passt die IP, dann normal installieren lassen. So kommt kein fremdes Plugin durch einen Fremden auf den LoxBerry.

Dann könnte man auch ein Verzeichnis sudoer'n, wo das Setup das root_postinstall.sh hinlegen kann.

Um IP-Spoofing zu verhindern, müsste man beim Response nach dem Check einen Hash mitgeben, der bei den weiteren Requests der Plugin-Installation geprüft wird.

Woersty commented 8 years ago

Ich verstehe dein Problem nicht, bei 5 Plugins 5x das root-PW einzugeben. Gibt doch die Zwischenablage... und man installiert ja nicht dauernd ein Plugin. Beim iPhone muss ich das auch eingeben. Und die Möglichkeit ein unsecure-Plugin zu installieren wie von Micha vorgeschlagen bleibt ja auch, falls es jemand nicht sicher braucht. Ich würde eher alles sicher machen und dann über das Plugin unsicher als andersrum.

christianTF commented 8 years ago

Es ist eine trügerische Sicherheit, wenn der Loxberry-Benutzer sowieso die MS-Benutzerdaten lesen kann. Der LoxBerry ist doch gar nicht das eigentliche Ziel einer Attacke. Was bringt eine zweite Sicherheitsebene, wenn die erste schon ausreicht. Aber sei's drum.

Bezügl. plugin.cfg - den Reboot-Parameter würde ich trotzdem einbauen.

Woersty commented 8 years ago

Deshalb ssl Zertifikat ...

svethi commented 8 years ago

Also, mit dem Root-Passwort bei Plugin Installation sehe ich nicht so dramatisch. Wieviele Plugins wird es denn geben, die unbedingt rootrechte bei der Installation benötigen?? Die Abfrage des root-Passwortes ist e.E. nach ja nur bei solchen Plugins nötig. Du installierst Deinen Loxberry und installierst dann 5 Plugins. Eines davon braucht root, brauchst Du auch nur 1-Mal das PW angeben. Ich bin auch eher einer, der auf Sicherheit aus ist und wenn man 5 Plugins installiert, die alle so tief in die Sicherheit eingreifen, dass die root benötigen, dann kann man sich das auch vom User bestätigen lassen. Der unbedarfte User soll ja wissen was er da tut. Für Entwickler ist das natürlich doof aber da könnte man das unsecure-Plugin ja auch eher Developer-Plugin nennen und dem Loxberry-User damit ohne Passwortabfrage sudo-Rechte geben. Dann kann der Developer ohne nervige Abfragen testen. Ein Developer, der auf seinem eigenen System die Sicherheitsanforderungen des Loxberry bezgl. der Passwörter nicht umgehen kann? Naja, ich habe hier ein total unsecure root-PW.

@christianTF ja, es geht hier sicher auch um die Installation böser Plugins. Wie Du schon sagst, ist man erst einmal auf dem Loxberry, ist man auch auf dem MiniServer und über den Loxberry auch im lokalen Netz mit Configzugang zum MiniServer. Sicher sind jetzt noch keine bösen Plugins dabei aber der exklusive Weg zum MiniServer geht nunmal über den Loxberry und wer weiß was in Zukunft alles passiert. Wir wollen doch nicht wie KNX und alle anderen erst nach ersten Einbrüchen das System Härten, oder?!

Wozu braucht man denn root-Zugang bei der Plugin Installation? Kann man da nicht spezielle Sudorechte vergeben, die das dann erlauben? Oder braucht man umfassend Zugriff?

Vielleicht kann man das auch über eine Plugin whitelist machen? Wäre für mich ein sicherer Weg, ist natürlich auch der aufwendigste Weg. Schließlich müsste man das Plugin prüfen und dann aufnehmen.

christianTF commented 8 years ago

Ich denke nicht, dass Michael für jedes Plugin, das Root-Rechte braucht, LoxBerry updaten möchte.

Mein Plugin braucht(e) die Root-Rechte schon mal nur, um auf die Audio-Devices zugreifen zu dürfen, und um den selbst gestarteten Prozess wieder beenden zu dürfen.

Wenn LoxBerry in einem generellen LockDown-Zustand kommt, muss ich einem Plugin zumindest erlauben, irgendwas zu tun, und das geht nur als Root, oder Michael passt LoxBerry für jedes Plugin individuell an.

Ich brauche übrigens als "böses" Plugin keine Root-Rechte, um auf den MS zu kommen. Jedes Plugin kommt an die MS-Credentials. Als Plugin kann ich ALLES anstellen. Es spielt überhaupt keine Rolle, ob das Root-PW vom User abgefragt wird. Ich halte es für überflüssig und übertrieben, das extra abzufragen.

Wenn ein Plugin wirklich sicher sein soll, muss das jemand überprüfen.

svethi commented 8 years ago

Hatte gerade schon einen langen Text geschrieben, bis der Safari abgeschmiert ist. Also nochmal in Kürze. Irgendwo hast Du ja Recht. Schwieriges Thema. Die Frage ist also wie bekommt man es sicher? Und das auch noch mit einem vertretbarem Verlust an Komfort?

christianTF commented 8 years ago

Einen Vorschlag hätte ich noch: Das LoxBerry Plugin Setup kann ja immer irgendwas als Root machen. Wenn man nun wirklich in diesem Setup ein Cookie setzt? Also: Erstes Plugin wird installiert, kein Cookie da - Root-PW abfragen und ein Session-Cookie setzen. Nicht die Root-Credentials im Cookie speichern, sondern irgendwas LoxBerry-Spezifisches, was man später wieder validieren kann. Wenn bei einem Plugin-Setup das Cookie da und valide ist, dann los wie bisher. So könnte man einen Angreifer zumindest schon mal etwas ausbremsen.

christianTF commented 8 years ago

PS: Es reicht schon, die Credentials SHA256 zu hashen, den Hash in /tmp/shm zu speichern und von dort weg zu validieren.

mschlenstedt commented 8 years ago

Ich habe jetzt auch noch einmal etwas mehr darüber nachgedacht:

Die Abfrage des Root-Passworts gaukelt, meiner Meinung nach, eher eine Scheinsicherheit vor. Warum?

Wenn ich es schaffe mich als "loxberry" auf dem System einzuloggen, dann habe ich quasi sowieso schon Root-Rechte. ich kann per Daemon ein neues Rootpasswort setzen (es kommt dabei KEINE Abfrage des alten Passworts!). Somit bin ich quasi nach einem Reboot "root". Und zudem kann ich die Abfrage des Rootpassworts auch einfach wieder im Script deaktivieren, denn das Plugin-Skript gehört von den Berechtigungen her "loxberry". Somit kann man sich die Abfrage des Rootpasswortes sparen (meine Meinung).

Noch dazu habe ich auch vollen Zugriff als User "loxberry" auf die Miniserver-Accountdaten und auf die Accountdaten des Mailservers.

Fazit: Es ist und bleibt ein Spagat wie wir es schaffen das System sicher zu machen und trotzdem auch den Plugins das Recht geben, Dinge als Root durchzuführen. Eine gewisse "Unsicherheit" wird da immer bleiben. Und wir müssen den Account "loxberry" so sicher machen wie es nur geht. Hat ein Eindringling die Berechtigung des Users "loxberry" erlangt, so hat er das System kompromittiert.

Ich schlage folgendes vor:

  1. Nach der Installation wird der Passwort-basierte SSH-Zugang deaktiviert und es wird nur noch ein Login per Zertifikat möglich. Damit kann man per Remote nicht auf das System, auch wenn man das Loxberry-Passwort ausgespäht hat. Damit sind dann auch erst einmal keine Änderungen an den Skripten möglich.
  2. Werden bei der Plugin-Installation Skripte mit Root-Rechten ausgeführt (Daemon oder "postinstall_root.sh"), so würd eich diese während der Installation zur Kontrolle anzeigen lassen. Damit kann man grob schauen was die Skripte machen. Wer keine Ahnung von bashskripten hat, hätte die Möglichkeit im Forum nachzufragen (die Skripte zu posten). Erst nach expliziter Bestätigung wird installiert.
  3. Wenn die Plugin-Installation nicht aus dem lokalen Netz aufgerufen wird, kommt die Passwortabfrage des Users "loxberry" vor der Installation.
mschlenstedt commented 8 years ago

Hier noch das verloren gegangene Posting von Svethi (siehe oben, ich hatte es anscheinend schon per Mail bekommen):

_"Also, mit dem Root-Passwort bei Plugin Installation sehe ich nicht so dramatisch. Wieviele Plugins wird es denn geben, die unbedingt rootrechte bei der Installation benötigen?? Die Abfrage des root-Passwortes ist e.E. nach ja nur bei solchen Plugins nötig. Du installierst Deinen Loxberry und installierst dann 5 Plugins. Eines davon braucht root, brauchst Du auch nur 1-Mal das PW angeben. Ich bin auch eher einer, der auf Sicherheit aus ist und wenn man 5 Plugins installiert, die alle so tief in die Sicherheit eingreifen, dass die root benötigen, dann kann man sich das auch vom User bestätigen lassen. Der unbedarfte User soll ja wissen was er da tut. Für Entwickler ist das natürlich doof aber da könnte man das unsecure-Plugin ja auch eher Developer-Plugin nennen und dem Loxberry-User damit ohne Passwortabfrage sudo-Rechte geben. Dann kann der Developer ohne nervige Abfragen testen. Ein Developer, der auf seinem eigenen System die Sicherheitsanforderungen des Loxberry bezgl. der Passwörter nicht umgehen kann? Naja, ich habe hier ein total unsecure root-PW.

@christianTF ja, es geht hier sicher auch um die Installation böser Plugins. Wie Du schon sagst, ist man erst einmal auf dem Loxberry, ist man auch auf dem MiniServer und über den Loxberry auch im lokalen Netz mit Configzugang zum MiniServer. Sicher sind jetzt noch keine bösen Plugins dabei aber der exklusive Weg zum MiniServer geht nunmal über den Loxberry und wer weiß was in Zukunft alles passiert. Wir wollen doch nicht wie KNX und alle anderen erst nach ersten Einbrüchen das System Härten, oder?!

Wozu braucht man denn root-Zugang bei der Plugin Installation? Kann man da nicht spezielle Sudorechte vergeben, die das dann erlauben? Oder braucht man umfassend Zugriff?

Vielleicht kann man das auch über eine Plugin whitelist machen? Wäre für mich ein sicherer Weg, ist natürlich auch der aufwendigste Weg. Schließlich müsste man das Plugin prüfen und dann aufnehmen."_

christianTF commented 6 years ago

So viel Text hier drin.

Mein Vorschlag:

Wenn also mal jemand LB Port 80 ins Inet freischaltet, kann sich der Eindringling zumindest kein "Root-Kit" über das Plugin-Setup installieren. Alle weiteren Absicherungen (SSH, Samba usw.) sind nettes Beiwerk, weil das wird sich hoffentlich keiner ins Inet freischalten.

Übrigens hab ich mir schon ein kleines "Root-Kit" gebaut ;-) http://www.loxwiki.eu/display/LOXBERRY/Developertools

mschlenstedt commented 6 years ago

Vorschlag: Wir schließen das hier und führen die Diskussion im Thread zur Plugininstallation weiter. Die Komplexität des Passworts würd eich nicht anrühren. Basta :-)