RaspberryMatic 3.47.15.20190831 – Erfahrungsberichte

[deimos]

Hi,

ich verstehe es nicht, warum der Autologin raus muss. Ich verstehe es, wenn man sagt, dass der per Default abgeschaltet ist, aber warum *muss* der raus?

Und wenn er denn rausfliegt: Kommt dann wenigsten auch eine Authentifizierung per HTTP Auth, damit man das in SSO Szenarien aufnehmen kann (und damit dann z.B. auch verhindern kann, dass man bei Cloudmatic und ähnlichen einen doppelten Login hat?

Viele Grüße
Alex

[TomMajor]

ich habe mal zum Thema

Nur optional: alphabetische Favoriten-Sortierung und Menü-Sortierung

eine issue auf github gemacht
https://github.com/jens-maus/RaspberryMatic/issues/706

Mein Favorit wäre eine Lösung in etwa so:
1. Abschaltung der alphabetischen Menüsortierung falls eine Datei /usr/local/etc/config/sortMenusDisabled
existiert
2. Abschaltung der alphabetischen Favoritensortierung falls eine Datei /usr/local/etc/config/sortFavoritesDisabled
existiert

Ich kenne mich jedoch nicht mit buildroot und dem Installationsmechanismus von RaspberryMatic aus so dass ich hier definitiv Hilfe bräuchte um einen PR zu machen.
Danke,

[LibertyX]

Hi,
ich verstehe es nicht, warum der Autologin raus muss. Ich verstehe es, wenn man sagt, dass der per Default abgeschaltet ist, aber warum *muss* der raus?

Weil diese Funktion ein eklatantes Sicherheitsrisiko darstellt und zudem für die Funktion nicht notwendig ist.
Eklatant darum, weil jeder der über den gleichen Weg wie du auf die CCU zugreift sofort eingeloggt ist.

Und wenn er denn rausfliegt: Kommt dann wenigsten auch eine Authentifizierung per HTTP Auth, damit man das in SSO Szenarien aufnehmen kann (und damit dann z.B. auch verhindern kann, dass man bei Cloudmatic und ähnlichen einen doppelten Login hat?

Diese Möglichkeit gibt es aktuell bereits, allerdings nicht für den Port 80 & 443 wenn ich mich richtig erinnere.

[deimos]

Hi,

ich verstehe es nicht, warum der Autologin raus muss. Ich verstehe es, wenn man sagt, dass der per Default abgeschaltet ist, aber warum *muss* der raus?

Weil diese Funktion ein eklatantes Sicherheitsrisiko darstellt und zudem für die Funktion nicht notwendig ist.
Eklatant darum, weil jeder der über den gleichen Weg wie du auf die CCU zugreift sofort eingeloggt ist.

Nein, das ist nicht zwingend ein Sicherheitsrisiko, wenn man über andere Sicherheitsmaßnahmen (z.B. eigenes VLAN mit Zugriffsbeschränkung) verfügt. Und wenn man in der Situation den Autlogin in einer (bewußten) Aktion aktiviert, wo ist da das Problem?

Und wenn er denn rausfliegt: Kommt dann wenigsten auch eine Authentifizierung per HTTP Auth, damit man das in SSO Szenarien aufnehmen kann (und damit dann z.B. auch verhindern kann, dass man bei Cloudmatic und ähnlichen einen doppelten Login hat?

Diese Möglichkeit gibt es aktuell bereits, allerdings nicht für den Port 80 & 443 wenn ich mich richtig erinnere.

Das geht für die XMLRPC Schnittstellen, aber nicht für die WebUI.

Viele Grüße
Alex

[jmaus]

Weil diese Funktion ein eklatantes Sicherheitsrisiko darstellt und zudem für die Funktion nicht notwendig ist.
Eklatant darum, weil jeder der über den gleichen Weg wie du auf die CCU zugreift sofort eingeloggt ist.

Nein, das ist nicht zwingend ein Sicherheitsrisiko, wenn man über andere Sicherheitsmaßnahmen (z.B. eigenes VLAN mit Zugriffsbeschränkung) verfügt. Und wenn man in der Situation den Autlogin in einer (bewußten) Aktion aktiviert, wo ist da das Problem?

Es ist vielleicht nicht zwingend ein Sicherheitsrisiko für Jedermann, aber für Otto-Normal-Verbraucher denn der weiss nicht was ein VLAN ist und kennt nur den Port-Forwarding Knopf seines Routers. Das Cert bzw. BSI hat leider in der Vergangenheit mehrfach in Zusammenhang mit diesem AutoLogin die CCU ein schweres Sicherheitsproblem attestiert. Nun kann man natürlich sagen das die ohnehin übertreiben und sicherlich auch politisch aktiv sind. Aber so ist das nunmal und die AutoLogin Funktion ist nun wirklich keine essentielle Funktion auf die man nicht verzichten kann.

Diese Möglichkeit gibt es aktuell bereits, allerdings nicht für den Port 80 & 443 wenn ich mich richtig erinnere.

Das geht für die XMLRPC Schnittstellen, aber nicht für die WebUI.

Dafür ist es IMHO auch nicht wirklich notwendig bzw. es ist vernachlässigter das man dann eben zweimal ein Login eingeben muss. Und wenn es dann doch stört kann man ja sehen ob man solch eine SSO Funktionalität nachliefern kann.

[LibertyX]

Nein, das ist nicht zwingend ein Sicherheitsrisiko, wenn man über andere Sicherheitsmaßnahmen (z.B. eigenes VLAN mit Zugriffsbeschränkung) verfügt. Und wenn man in der Situation den Autlogin in einer (bewußten) Aktion aktiviert, wo ist da das Problem?

Auch ein VLAN schützt hier nur beim internem Zugriff, greift man von extern auf die CCU zu und jemand schafft es sich Zugriff auf diesen Weg zu verschaffen (Mal vergessen auf einem öffentlichen PC sich auszuloggen oder z.B. der genutzte Anbieter hat eine Sicherheitslücken und es verschafft sich so jemand Zugriff auf dessen Systeme), dann hat derjenige Dank dieser Funktion ungehindert Zugriff auf die WebUI obwohl ein Passwort vergeben ist.

Wenn du mal selbst sehen willst, wie viele Leichtsinnige es gibt die aus Unwissenheit Ihre CCU von extern Zugänglich machen, weil Sie denken, dass Passwort reicht schon aus. Dann nimmst du mal den bekannten IOT Scanner, der das gesamte Inet nach IOT Systemen durchforstet und Listen erstellt, suchst dort mal nach den passenden Stichworten und dann wirst du mehr als eine CCU finden, die Dank AutoLogin voll Frei zugänglich ist.

Das geht für die XMLRPC Schnittstellen, aber nicht für die WebUI.

Hatte ich ja geschrieben.

[deimos]

Hi,

ein VLAN alleine schützt noch nicht, aber es gibt entsprechende Firewalls, die man davor schalten kann (ich meine damit nicht die einfachen Portbasierten). Wie du selbst schreibst, die Leute denken, dass das Passwort sie schützt, das wird durch den Wegfall des Autologins gleich bleiben, wenn nicht sogar schlimmer.

Das Argument mit dem Angreifer beim Anbieter lasse ich nicht gelten, dieser könnte per Mitm Angriff auch die Zugangsdaten abgreifen, zumindest solange nicht zwingend https verwendet wird. Und diesen Zwang einzuführen dürfte massiv für Probleme bei den Nutzern führen (Stichwort Zertifikatsfehlermeldung wg. fehlender Chain).

Es macht absolut Sinn, wenn man darüber nachdenkt, das System sicherer zu machen und auch die Defaulteinstellungen so wählt, dass der unbedarfte Nutzer geschützt wird. Aber das verbietet nicht, auch Einstellungen zuzulassen, welche "Profis" in die Lage versetzt, an den Parametern zu drehen.

So weit mir bekannt ist, hat das BSI auch kein Problem mit dem Autologin per se, sondern mit der Tatsache, dass der Autologin per Default an ist und bis vor einigen Versionen kein Passwort gesetzt werden musste.

Was mir leider wieder auffällt: Es wird an der Sicherheit rumgedocktert ohne das hier ein Gesamtkonzept erkennbar ist. Und dabei werden vor allem die Punkte umgesetzt, welche dem Laien in einem Schnellschuß präsentiert werden können, aber die großen Brocken und wirklich kritischen Brocken werden nicht angerührt. Ich denke da z.B. auch an so Dinge, dass alle Dienste inkl. dem Webserver unter Root laufen, die fehlende Authorisierung (welche auch durch eine Zwangsauthentifizierung bei fehlendem Autlogins bleibt), fehlendem richtige Code Reviews insb. von Sicherheitsrelevantem Code), ...

Viele Grüße
Alex

[darkbrain85]

Was mir leider wieder auffällt: Es wird an der Sicherheit rumgedocktert ohne das hier ein Gesamtkonzept erkennbar ist. Und dabei werden vor allem die Punkte umgesetzt, welche dem Laien in einem Schnellschuß präsentiert werden können, aber die großen Brocken und wirklich kritischen Brocken werden nicht angerührt. Ich denke da z.B. auch an so Dinge, dass alle Dienste inkl. dem Webserver unter Root laufen, die fehlende Authorisierung (welche auch durch eine Zwangsauthentifizierung bei fehlendem Autlogins bleibt), fehlendem richtige Code Reviews insb. von Sicherheitsrelevantem Code), ...

Das kannst Du aber nicht Jens anlasten. Der stopft halt in seiner Freizeit die offensichtlichsten Lücken so gut es geht.
Er schreibt ja selber, dass z.B. das root Benutzer Problem erheblichen Aufwand Bedeutet. Das könnte also vielleicht mal EQ3 angehen. Die haben bezahlte Entwickler bzw. könnten sie die Kompetenz einkaufen. Hätten wir Jens nicht, hätte sich in Sachen Sicherheit vermutlich noch überhaupt nichts bewegt.

[HookHM]

Bei mir dauert es sehr lange bis die Geräteeinstellungen geöffnet werden. Einstellungen > Geräte > Geräte-/ Kanalparameter einstellen.

Ich sehe dieses Bild erstmal mehr als 30 Sekunden bevor die Kanalparameter des Geräts angezeigt werden.

Es dauert auch lange bis meine Programme angezeigt werden. Programme und Verknüpfungen > Programme. Vor dem Update wurden diese sofort! angezeigt.

[mactoolz]

....
Das könnte also vielleicht mal EQ3 angehen. Die haben bezahlte Entwickler bzw. könnten sie die Kompetenz einkaufen. Hätten

also dazu muss ich mal loswerden. Alleine die Tatsache das Herr Maus in seiner Freizeit ein wesentlich viel besseres EQ3 Produkt weiter entwickelt,
zeigt grundlegend wie absolut schlecht überhaupt EQ3 überhaupt diese mickerige Grundlage geschaffen hat !!!

Diese weiter Entwicklung von Herr Maus ist ein absoluter Schlag ins Gesicht für EQ3.

Gruß
MacToolz