howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

hominidae
Beiträge: 1159
Registriert: Di Sep 03, 2019 4:13 pm

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Beitrag von hominidae »

...ja, schon gut..es geht mir garnicht so sehr um die grosse Komplexität.
Ein normales config ist ja auch OK.
Anmerkung: die config lokal direkt editieren, kann evtl. das UI zerschiessen...davon würde ich dann eher abraten....und für eine Fertig-openWB auch ein "Problem" im Sinne der Gewährleistung, wenn es hart auf hart geht, oder?

Aber eigentlich geht es mir um das:
hominidae hat geschrieben: Sa Nov 30, 2019 2:49 pm
KevinW hat geschrieben: Sa Nov 30, 2019 1:11 pm Zu schnell hängt dann was exposed auf einem Broker wo es nichts zu suchen hat.
...schon klar, aber das kannst Du nicht verhindern, ohne externe mqtt-clients auszusperren oder zumindest einzuschränken.
Es geht dabei doch eher um die "Geister die man mit mqtt rief".... wie soll die openWB das verhindern, was Du schilderst?...mit irgendeiner Bridge-Config auf Seiten der openWG ja nicht. Die ist allenfalls Teil der Lösung (mit User / Pass / Host / Prefix / topics to sync / set topics).
Oder irre ich mich?
openWB
Site Admin
Beiträge: 7905
Registriert: So Okt 07, 2018 1:50 pm

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Beitrag von openWB »

Mir ging es darum:
wenn die bridge config per mqtt einstellbar ist, man sehr schnell nach einer blöden config - von außen - weitere bridges hinzufügen kann.

Lokal ein extra bridge file editieren.

Wer auf einen öffentlichen unverschlüsselten MQTT bridged, dem ist nicht zu helfen.
Aber etwas besser als den http port der openWB uber die fritzbox freigeben.
Supportanfragen bitte NICHT per PN stellen.
Hardwareprobleme bitte über die Funktion Debug Daten senden mitteilen oder per Mail an support@openwb.de
aiole
Beiträge: 6779
Registriert: Mo Okt 08, 2018 4:51 pm

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Beitrag von aiole »

Bitte tut mir den Gefallen und denkt vornehmlich an stinknormale lokale Nutzung. Das werden >90% der user so verwenden.

Euer "Gebridge" in Ehren, aber ich sehe große Gefahren, die aktuelle Datensicherheit zu unterlaufen, wenn das zu komplex wird. (komplex = alles, was der/die DAU nicht versteht)

Es wäre echt schade, wenn nur noch <10% openWB sicher konfigurieren können. Bis jetzt ist Sicherheit ein TOP-MARKENZEICHEN!

VG
aiole
Beiträge: 6779
Registriert: Mo Okt 08, 2018 4:51 pm

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Beitrag von aiole »

KevinW hat geschrieben: Sa Nov 30, 2019 4:56 pm ...
Wer auf einen öffentlichen unverschlüsselten MQTT bridged, dem ist nicht zu helfen.
Aber etwas besser als den http port der openWB uber die fritzbox freigeben.
Während letzteres weitgehend bekannt ist (aber auch nicht sicher von DAUs gehändelt wird), ist das mit MQTT viel kritischer zu sehen. Die wenigsten werden wissen, was sie da zusammenklicken.

Meine Meinung:
bridge-mode nur mit Vorwarnung und in der Standardeinstellung "local usage" verboten.
truckl
Beiträge: 120
Registriert: Sa Nov 09, 2019 10:32 am

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Beitrag von truckl »

aiole hat geschrieben: Sa Nov 30, 2019 10:53 pm Bitte tut mir den Gefallen und denkt vornehmlich an stinknormale lokale Nutzung. Das werden >90% der user so verwenden.
Geanu das ist mein Ziel. Der Ansatz war grundsätzlich eine "geführte, sichere Konfigurierbarkeit" von MQTT-Bridging die auch der Otto-Normal-User sicher benutzen kann.
Als Szenario sehe ich da Nutzer die z.B. für andere Zwecke bereits rein UI-konfiguriertes MQTT nutzen. Da sehe ich einfach steigenden Bedarf. Solche Nutzer greifen sonst zur nicht-verstandenen "Google"-basierten konfiguration. Das ist bestimmt nicht besser.
hominidae hat geschrieben: Sa Nov 30, 2019 2:49 pm Ich persönlich habe ja momentan noch andere Möglichkeiten, daher in Bezug auf den o.g. Teil...wenn man externe clients unterbindet sollte zumindest
[...]
- eine Bridge für "Experten" (siehe mein Beispiel für cloudmqtt)
möglich sein.
Vor einem Einspielen von rein benutzerdefinierten Konfigs habe ich persönlich, zu viel "Angst". Denn entweder validiert man gar nichts, mit dem Risiko jegliche (nicht nur Sicherheits-) Ansätze zu torpedieren und somit für erhöhten Support zu sorgen (kaputtes openWB UI, ...). Oder man verbringt sehr viel Zeit mit der Implementierung einer Validierung (und versucht dabei alle möglichen Fehlkonfigurationen vorher zu sehen :? ).
So viel Zeit hab ich leider nicht. Zudem sollten "Experten" problemlos in der Lage sein Konfigurationen per SSH einzuspielen. Deshalb würde ein PR meinerseits keine Upload-Funktion enthalten.

Eine Konfiguration über MQTT sehe ich noch viel gefährlicher. Da hat man sich ganz leicht selbst ausgesperrt: Lädt man z.B. versehentlich per MQTT eine kaputte Konfig hoch geht die Bridge danach nicht mehr und man kann den Fehler nicht korrigieren. Außerdem wäre das auch sehr viel mehr Implementierungsaufwand für den "Hintegrunddienst" (oder Hook im Regelintervall) der nach neuen Konfigs im MQTT-Broker sucht.
hominidae hat geschrieben: Sa Nov 30, 2019 2:49 pm Ich denke, dann sollte man externe Clients auch verbannen...(aber bitte nur dann ;-))
Da ist mir nicht klar wie das umgesetzt werden kann. Denn auch das WebUI und der "Regelkreis" der openWB (senden von Daten, empfangen von Konfiguration) sind "normale MQTT-Clients". Der Mosquitto der openWB hat m.M.n. keine Möglichkeit diese zu unterscheiden (bind auf 127.0.0.1 geht nicht da Web-UI ja Websockets von beliebigen IPs aus aufbaut).

aiole hat geschrieben: Sa Nov 30, 2019 10:53 pm Euer "Gebridge" in Ehren, aber ich sehe große Gefahren, die aktuelle Datensicherheit zu unterlaufen, wenn das zu komplex wird. (komplex = alles, was der/die DAU nicht versteht)

[...] Bis jetzt ist Sicherheit ein TOP-MARKENZEICHEN!
EDIT:
Ich sehe das in der openWB derzeit eher "zweischneidig" und bestimmt noch nicht "TOP": Immerhin ist das WebUI und der MQTT-Server der openWB völlig ungeschützt von allen Hosts mit Zugriff auf das Netzwerk-Segment der openWB erreichbar. Allein das ist m.M.n. brandgefährlich wenn man eben von den hier vermuteten "sehr unbedarften Nutzern" ausgeht. Die konfigurieren dann halt ein Portforwarding ohne zu wissen was sie tun. Ganz zu schweigen davon daß nicht jedes LAN automatisch "sicher" ist (unsicheres WLAN, unauthorisierter Zugriff auf LAN-Dosen, ...). All das kann die openWB nicht verhindern.

Die openWB wäre allerdings trotzdem halbwegs sicher, würde sie wenigstens TLS (self-signed cert) und Authentication im Web UI und Mosquitto nutzen! Derzeit ist sie dagegen eines von Millionen IOT-Devices die dann offen im Internet rum schwirren (siehe https://www.shodan.io/search?query=openWB - ergibt gottlob zum Zeitpunkt da ich diesen Text schreibe nur eine!)
/EDIT

Ich verstehe daher nicht wie durch "Gebridge" die Sicherheit noch weiter unterlaufen werden kann !
Es wird definitiv immer Möglichkeiten geben wie "unbedarfte Nutzer" die Sicherheit selbst untergraben. Ist es wirklich Aufgabe der openWB all diese Fälle zu unterbinden? Und das auf Kosten der "offenen Plattform" welche die openWB eigentlich ist?
openWB
Site Admin
Beiträge: 7905
Registriert: So Okt 07, 2018 1:50 pm

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Beitrag von openWB »

@aiole
Genau deshalb bevorzuge ich:
- An / Aus
- User
- Pass
- Host
- Lesende Topics
- Schreibende Topics

Das ist schon komplex genug, bietet aber für alle Fortgeschrittenen genug Möglichkeiten.
Wer sich mit auskennt macht das ohnehin per SSH direkt in der Config.

Allerdings ist MQTT wesentlich unkritischer als HTTP der openWB nach außen freizugeben.
Über MQTT siehst du die Daten die published werden, so gesehen die "Hauptseite"-
Heißt Leistungsdaten. Bei schreibendem Zugriff kann der Lademodus / Stromstärke verstellt werden.

Bei Freigabe von HTTP sind tendenziell alle Daten (User / Pass von SoC Modulen) sichtbar.

Geanu das ist mein Ziel. Der Ansatz war grundsätzlich eine "geführte, sichere Konfigurierbarkeit" von MQTT-Bridging die auch der Otto-Normal-User sicher benutzen kann.
Als Szenario sehe ich da Nutzer die z.B. für andere Zwecke bereits rein UI-konfiguriertes MQTT nutzen. Da sehe ich einfach steigenden Bedarf. Solche Nutzer greifen sonst zur nicht-verstandenen "Google"-basierten konfiguration. Das ist bestimmt nicht besser.
Obiges reicht dafür ja schon!?
Vor einem Einspielen von rein benutzerdefinierten Konfigs habe ich persönlich, zu viel "Angst". Denn entweder validiert man gar nichts, mit dem Risiko jegliche (nicht nur Sicherheits-) Ansätze zu torpedieren und somit für erhöhten Support zu sorgen (kaputtes openWB UI, ...). Oder man verbringt sehr viel Zeit mit der Implementierung einer Validierung (und versucht dabei alle möglichen Fehlkonfigurationen vorher zu sehen :? ).
So viel Zeit hab ich leider nicht. Zudem sollten "Experten" problemlos in der Lage sein Konfigurationen per SSH einzuspielen. Deshalb würde ein PR meinerseits keine Upload-Funktion enthalten.

Eine Konfiguration über MQTT sehe ich noch viel gefährlicher. Da hat man sich ganz leicht selbst ausgesperrt: Lädt man z.B. versehentlich per MQTT eine kaputte Konfig hoch geht die Bridge danach nicht mehr und man kann den Fehler nicht korrigieren. Außerdem wäre das auch sehr viel mehr Implementierungsaufwand für den "Hintegrunddienst" (oder Hook im Regelintervall) der nach neuen Konfigs im MQTT-Broker sucht.
Wie schon erwähnt, da bin ich bei dir.
Eine extra Config Datei um eine Bridge zu erstellen mit den obigen Parametern. Nicht mehr, nicht weniger.
Ich sehe das in der openWB derzeit eher "zweischneidig" und bestimmt noch nicht "TOP": Immerhin ist das WebUI und der MQTT-Server der openWB völlig ungeschützt von allen Hosts mit Zugriff auf das Netzwerk-Segment der openWB erreichbar. Allein das ist m.M.n. brandgefährlich wenn man eben von den hier vermuteten "sehr unbedarften Nutzern" ausgeht. Die konfigurieren dann halt ein Portforwarding ohne zu wissen was sie tun. Ganz zu schweigen davon daß nicht jedes LAN automatisch "sicher" ist (unsicheres WLAN, unauthorisierter Zugriff auf LAN-Dosen, ...). All das kann die openWB nicht verhindern.
Bei einem normalen Hausnetzwerk ist davon allerdings auszugehen und allemal besser als irgendein Clouddienst der pauschal alles nach Hause schickt.
Die openWB wäre allerdings trotzdem halbwegs sicher, würde sie wenigstens TLS (self-signed cert) und Authentication im Web UI und Mosquitto nutzen! Derzeit ist sie dagegen eines von Millionen IOT-Devices die dann offen im Internet rum schwirren (siehe https://www.shodan.io/search?query=openWB - ergibt gottlob zum Zeitpunkt da ich diesen Text schreibe nur eine!)
Der Sicherheitsgewinn wäre minimalst, mal davon ausgehend das 99,9% der Kommunikation lokal im Hausnetz erfolgt.
Zudem weckt es womöglich die falsche Erwartung das ein Port Forwarding mit aktiviertem https sicher wäre (nein, ist es nicht).
Ich hab den Leaf Fahrer aus der Schweiz mal angeschrieben (https hätte hier nichts geändert)...

Der Support Aufwand wenn alle Browser wegen selfsigned meckern kannst/willst du dir nicht vorstellen.
Es wird definitiv immer Möglichkeiten geben wie "unbedarfte Nutzer" die Sicherheit selbst untergraben. Ist es wirklich Aufgabe der openWB all diese Fälle zu unterbinden? Und das auf Kosten der "offenen Plattform" welche die openWB eigentlich ist?
Nein, darum soll es ja die Möglichkeit geben simpel eine Bridge zu erstellen.
Es gibt die Möglichkeit die Daten weiter zu verarbeiten, ohne gleich alle Daten preis zu geben.
Schlussendlich liegt es immer noch am Nutzer ob dann jeder sieht was die PV gerade bringt.
Der Warnhinweis das ein publishen an externe Server nicht empfohlen wird, wird natürlich mit drinnen stehen.
Supportanfragen bitte NICHT per PN stellen.
Hardwareprobleme bitte über die Funktion Debug Daten senden mitteilen oder per Mail an support@openwb.de
truckl
Beiträge: 120
Registriert: Sa Nov 09, 2019 10:32 am

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Beitrag von truckl »

KevinW hat geschrieben: So Dez 01, 2019 11:30 am Obiges reicht dafür ja schon!?
Jep. Habe mir allerdings überlegt noch das TLS-Protokoll hinzuzufügen. Für rein internen Einsatz im LAN (z.B. Kopplung mit irgend einer Heimautomatisierung) denke ich daß es durchaus sinnvoll ist ohne TLS zu arbeiten. Die Argumente sind dabei die Selben, die KevinW im vorangegangenen Post auch für das "nicht-verschlüsseln" bei openWB vorgebracht hat.
KevinW hat geschrieben: So Dez 01, 2019 11:30 am Bei einem normalen Hausnetzwerk ist davon allerdings auszugehen und allemal besser als irgendein Clouddienst der pauschal alles nach Hause schickt.
Zweifellos !
KevinW hat geschrieben: So Dez 01, 2019 11:30 am Der Sicherheitsgewinn wäre minimalst, mal davon ausgehend das 99,9% der Kommunikation lokal im Hausnetz erfolgt.
Zudem weckt es womöglich die falsche Erwartung das ein Port Forwarding mit aktiviertem https sicher wäre (nein, ist es nicht).
Ich würde den Prozentsatz der Internetkommunikation zwar etwas höher als 0,1% einschätzen. Aber das ist hier auch nicht Thema. Bitte meine Aussage wirklich nur als Argument dafür sehen, daß durch die vorgeschlagenen MQTT-Bridge-Konfiguration die Sicherheit der openWB schlichtweg unverändert bleibt.

Ich denke aber doch: Durch HTTPS alleine würde openWB bei Port-Forwarding natürlich nicht sicherer. Wohl aber durch die Aktivierung von Basic Authentication im Webfrontend bzw. ACL im Mosquitto. Denn dann müßte jemand der z.B. mit Shodan eine openWB findet immer noch erst User+Paßwort knacken. Würde das Paßwort auch noch bei jeder gelieferten Fertig-openWB zufällig gesetzt und hinten auf das Gehäuse geschrieben wäre das meines Erachtens schon eine Steigerung der Sicherheit.
Ich sehe aber auch den Zusatzaufwand, die Verwirrung durch die Zertifikatswarnung und den Fakt daß die openWB kein Internet-Router (somit die Sicherheitsanforderung nicht zu kritisch sind). Insofern auch keine dringende Notwendigkeit dafür (werde da keinen PR machen ;) )

Wichtig war mir diese Aussage nicht als Plädoyer für HTTPS und Authentication. Sondern schlichtweg dafür daß ich nicht wüßte wie man sonst den Client-Zugriff auf den Mosquitto beschränken könnte (wie im Kommentar gefordert).
KevinW hat geschrieben: So Dez 01, 2019 11:30 am Ich hab den Leaf Fahrer aus der Schweiz mal angeschrieben (https hätte hier nichts geändert)...
Das finde ich echt super, daß Du Dich sogar um diesen Kunden bzw. Nutzer annimmst auch ohne davon einen direkten Vorteil zu haben!

Entsprechend dieser Diskussionen umgearbeiteter Vorschlag: "Demnächst hier in diesem Kino" :D
truckl
Beiträge: 120
Registriert: Sa Nov 09, 2019 10:32 am

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Beitrag von truckl »

Hier ist der neue GUI-Vorschlag:
BridgeConfigMock.png
(76.91 KiB) 938-mal heruntergeladen
aiole
Beiträge: 6779
Registriert: Mo Okt 08, 2018 4:51 pm

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Beitrag von aiole »

Nochmal zum Verständnis:
* MQTT wird normal nur lokal von openWB genutzt
* statt VPN-Zugang ist alternativ der Datenaustausch mit Apps (nativ) und externen MQTT-Servern (per bridging) möglich

App ist sicher ein nettes Spielzeug, mehr aber auch nicht (für die meisten).
MQTT als VPN-Ersatz muss zwingend abgesichert werden, sonst war's das mit geschützten Daten.
=> Außer dass openWB ev. etwas schneller mit MQTT läuft, sehe ich, ehrlich gesagt, keinen Zugewinn an features.
Einzig für gekoppelte Systeme (z.B. Verknüpfung mit bestehendem Smarthome) ergibt das Sinn. Man muss aber sehr aufpassen, wenn man solche Vernetzungen "übertreibt". Das geht zu Lasten der Stabilität. Letztlich soll openWB weitgehend autark arbeiten und dabei alle Ladewünsche sicherstellen.

Mit einem Großteil der "bridge-inputs" müsste ich mich erstmal beschäftigen. Da bleibe ich lieber beim VPN und openWB/MQTT lokal.

Bitte nicht falsch verstehen - Ihr schafft hier die (sinnvolle) OPTION zum Datenaustausch, aber damit sind ordentlich Risiken verbunden.
Wer supportet das eigentlich? Die bridge geht openWB m.E. schon gar nichts mehr an.

VG

ps
http-UI ist ok.
Es ist eine klare Sache, dass der user kein portforwarding nutzen darf und bei Remotecontrol von außen einen sicheren VPN zu installieren hat.
openWB
Site Admin
Beiträge: 7905
Registriert: So Okt 07, 2018 1:50 pm

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Beitrag von openWB »

Danke truckl.

Finde ich soweit ganz gut, nur keine Beschränkung der Steuerung auf Ladepunkt 1 sondern direkt alle.
Ebenso würde ich Verschlüsselung nicht abschaltbar machen.
Wer lokal arbeitet kann sich als client subscriben.
Rein als Schutzmechanismus.
Nochmal zum Verständnis:
* MQTT wird normal nur lokal von openWB genutzt
* statt VPN-Zugang ist alternativ der Datenaustausch mit Apps (nativ) und externen MQTT-Servern (per bridging) möglich
Richtig, und erstmal hat das nichts mit irgendeiner App zu tun.
=> Außer dass openWB ev. etwas schneller mit MQTT läuft, sehe ich, ehrlich gesagt, keinen Zugewinn an features.
Einzig für gekoppelte Systeme (z.B. Verknüpfung mit bestehendem Smarthome) ergibt das Sinn. Man muss aber sehr aufpassen, wenn man solche Vernetzungen "übertreibt". Das geht zu Lasten der Stabilität. Letztlich soll openWB weitgehend autark arbeiten und dabei alle Ladewünsche sicherstellen.
Es ist eine sicher nutzbare Schnittstelle von und zur openWB, das ist ein enormer Vorteil!
Wenn nun jemand ohne Verschlüsselung und ohne Authentifizierung diese nutzt ist es zwar unsicher, aber immer noch gefühlt Faktor 50 besser als ein Port Forwarding von Port 80 der openWB nach außen.
Mit einem Großteil der "bridge-inputs" müsste ich mich erstmal beschäftigen. Da bleibe ich lieber beim VPN und openWB/MQTT lokal.
Was meinst du mit Inputs?
Grundsätzlich ist maximal das sichtbar was du aktuell auf der Hauptseite siehst.
Fernsteuern kannst du den Lademodus, Ladepunkte (de-)aktivieren, sowie die Stromstärke im Sofort Laden Modus regeln.
Bitte nicht falsch verstehen - Ihr schafft hier die (sinnvolle) OPTION zum Datenaustausch, aber damit sind ordentlich Risiken verbunden.
Wer supportet das eigentlich? Die bridge geht openWB m.E. schon gar nichts mehr an.
Die Schnittstelle nach außen ist mmn nach schon Baustelle von openWB. open heißt nicht nur von allen "Parteien / Komponenten" die Daten abfragen sondern diese eben auch zur Verfügung stellen.
Wenn das einmal implementiert ist, ist der Support Aufwand gering bzw. nicht vorhanden.
ps
http-UI ist ok.
Es ist eine klare Sache, dass der user kein portforwarding nutzen darf und bei Remotecontrol von außen einen sicheren VPN zu installieren hat.
Eben genau das überfordert viele Nutzer eben schon. Hier eine Alternative anzubieten macht schon Sinn.
Supportanfragen bitte NICHT per PN stellen.
Hardwareprobleme bitte über die Funktion Debug Daten senden mitteilen oder per Mail an support@openwb.de
Antworten