piVCCU3 mit Firmware 3.41.7

[deimos]

Hi,

ich habe gerade eine neue piVCCU3 Version basierend auf der CCU3 Firmware 3.41.7 ins testing apt Repository hochgeladen. Sollten keine großen Probleme auftauchen, so werde ich die in ca. 2 Wochen dann auch ins stable apt Repository übernehmen.

Jeder der mag: Viel Spaß beim Testen!

Viele Grüße
Alex

[klassisch]

Respekt, das ging aber flott! Vielen Dank!
- Wie ist das Vorgehen? Backup auf WebUI heraus abspeichern und nach dem Update wieder einlesen?
- In den Release Notes wurden weitgehende Sekurity Maßnahmen angekündigt wie Zwangspasswort. Ist bekannt, ob die http Schnittstellen noch funktionieren?
- Wie käme man notfalls wieder zurück?

[deimos]

Hi,

Backup über die WebUI oder pivccu-backup kann nie schaden. Die Einstellungen werden aber automatisch beim Update übernommen.
Downgrade kann man über

Code: Alles auswählen

sudo apt install pivccu3=3.37.8-6

durchführen. Aufgrund der Hinweise bei der Original Firmware gehe ich davon aus, dass man beim Downgrade ein altes Backup einspielen muss, weil die 3.41.7 Anpassungen an den Einstellungen vornimmt, welche mit der 3.37.8 nicht kompatibel sind.

Viele Grüße
Alex

[jmaus]

Aufgrund der Hinweise bei der Original Firmware gehe ich davon aus, dass man beim Downgrade ein altes Backup einspielen muss, weil die 3.41.7 Anpassungen an den Einstellungen vornimmt, welche mit der 3.37.8 nicht kompatibel sind.

Genau so ist es. Ein Downgrade auf einer frühere Version (auch auf die 3.37. sollte man am besten immer mittels einspielen eines alten Backups dieser Version erledigen und nicht einfach die Firmware "downgraden". Die Änderungen in dieser Version gehen sogar soweit, dass hier eine neue ReGaHss Version integriert ist die z.B. statt MD5 nun SHA512 als Passworthashes in der regadom verwendet. D.h. wenn man dann einfach auf eine vorherige Version zurückgeht verliert man seine Nutzerpasswörter. Weitaus weitreichender ist eine Änderung in der ReGa die es mit dieser Version erstmalig erlaubt mehr als 65k Objekte in der ReGaHss verwalten zu können. Nun sind theoretisch 2^32 Objekte möglich was gerade für Installationen mit vielen HmIP Geräten notwendig ist da diese überproportional viele Datenpunkte/Objekte in der ReGa anlegen. Und wenn man nun einmal über diese 65k Grenze hinweg Objekt angelegt hat und einfach auf eine vorherige Version zurückgeht dann kann es zu gewissen Problemen kommen. Ergo, wenn man auf eine Version < 3.41.7 zurückgehen können möchte sollte man zwingend ein Backup anlegen und dieses sicher verwahren denn genau das brauch man dann wenn man zurückgeht.

[Familienvater]

Hi,

das ist ja super, das diese "minimalen" Änderungen auch genau so aus den Release Notes der offiziellen Firmware hervorgehen. Laut den Release notes wurden ja nur ein paar HmIP-Geräte der Firmware hinzugefügt.

Der Familienvater

[klassisch]

Vielen Dank für Eure Antworten!
Neue ReGaHss. Einerseits gut, daß dieses Teil modernisiert wird. Andererseits: Ob ich da als traditioneller Spätupdater so mutig bin?
Was ist bei der Behandlung von externen http requests zu erwarten? Also Kommandos vom Smartphone und von den ESP8266?
@Familienvater: Nicht so früh aufhören mit Lesen: https://www.eq-3.de/Downloads/Software/ ... 3.41.7.pdf

Changelog
3.41.7
ACHTUNG: Dieses Update enthält relevante Anpassungen der Sicherheitseinstellungen. Diese können
sich auf die Funktionen von Zusatzsoftware auswirken. Darunter fallen erweiterte Firewalleinstellungen und die obligatorische Vergabe eines Anmeldepassworts.
Erstellen Sie ein Backup der Zentrale, bevor Sie dieses Update installieren
...
Nach der Installation dieses Updates
- wird jeder Benutzer ohne Passwort aufgefordert, ein Passwort zu vergeben.
- wird ein Administrator zur Überprüfung der Sicherheitseinstellungen aufgefordert.
Das Blinken der Info LED bei Service u. Alarmmeldungen kann deaktiviert werden.
(Einstellung unter Systemsteuerung/Allgemeine Einstellungen

Gut bei mir sind die eh dauerhaft deaktiviert weil erst gar nicht verbaut.

[Familienvater]

Hi,

da steht mit keinem Wort, das was an der Rega verbessert wurde, und die jetzt mehr Nodes kann, und vor allem steht da mit keinem Wort, das Backups 100% Inkompatibel zu früheren Versionen sind. "Offizielle" Bugs, wie der Absturz der Rega nach regem Gebrauch von "&" bei system.exec werden wahrscheinlich nicht gefixt, oder weil es eine undokumentierte Funktion ist, muss man auch offiziell keine Änderungen tracken.

Das schlimmste an der Geschichte ist für mich aber, das es den "offiziellen" Anschein macht, das die WebUI jetzt stahlhart ist, und keinerlei Sicherheitslücken mehr hat (und man die und alle Schnittstellen ohne Bedenken problemlos per Portforwarding ins Internet stellen kann), dabei wurde wahrscheinlich nur ein fetter Stahlriegel auf die Türe aus Pappe geschraubt.

Aber es gehört nicht hierher, das hat nichts mit piVCCU zu tun, das ist ein EQ3-Öffentlichkeitsdarstellungs-Thema.

Der Familienvater

[jmaus]

Was ist bei der Behandlung von externen http requests zu erwarten? Also Kommandos vom Smartphone und von den ESP8266?

Als erstes sollte man wissen, dass ab dieser Version nun alle HTTP Requests nicht nur auf Port 80/443 über den lighttpd als Proxy geleitet werden, sondern auch für den Rega-Skript-Port 8181, den XMLRPC port von ReGaHss 1999, den XMLRPC Port von rfd 2001, den XMLRPC port des HMIPServer 2010, den virtuellen Group Dienst des HMIPServers auf port 9292 und den XMLRPC port des hs485d auf Port 2000. Insofern finden nun über den lighttpd ggf. striktere Kontrollen des HTTP Standards statt, sodass man mitunter sicherstellen muss, dass die HTTP Anfragen an all diese Dienste auch entsprechend HTTP/RFC konform ablaufen, da ansonsten der lighttpd ggf. Verbindungen ablehnen oder nicht weiterleitet wenn diese gegen RFCs verstoßen.

Zusätzlich dazu existieren nun als neues Feature für all diese oben genannten Ports - über die normalerweise unverschlüsselt kommuniziert wird - entsprechende SSL Portvarianten die jeweils mit der Zahl "4" beginnen. D.h. z.b. Ist der Port für eine SSL verschlüsselte Kommunikation mit dem ReGa-Skript-Server nun die 48181, für den XMLRPC des ReGaHss die 41999, für den XMLRPC des RFD die 42001, usw. D.h. also man kann nun sämtliche XMLRPC/ReGa-Skript Kommunikation voll verschlüsselt ablaufen lassen wenn man statt den unverschlüsselten Ports die verschlüsselten Varianten verwendet.

Und um dem ganzen noch eins oben drauf zu setzen, ist es nun sogar möglich in der WebUI eine Authentifizierung für alle diese Remote-API Ports anzuschalten bei der dann der lighttpd eine Basic Authentifizierung gegen die in der WebUI konfigurierten Nutzerdaten (Nutzername+Passwort) zulässt. D.h. wenn die Authentifizierung angeschalten ist, muss man z.B. auf Port 8181 und 48181 sich vorher mit Basic Authentikation anmelden bevor die Kommunikation vom lighttpd proxy an den jeweiligen Dienst weitergeleitet wird. Konkret bedeutet dies das man dann z.B. folgende ReGa-Skript Anfrage via wget stellen kann:

Code: Alles auswählen

wget --no-check-certificate -q -O - --post-data "string out;system.Exec('date',&out);" https://Admin:1234@192.168.1.1:48181/tclrega.exe

D.h. man gibt dann in der URL Nutzername+Passwort an und macht dies am besten gleich über den SSL verschlüsselten Port 48181 sodass diese Daten auch sicher übertragen werden.

Ingesamt muss man sagen sollte das die generelle Sicherheit für RemoteAPI Anfragen an eine CCU wirklich substantiell verbessern. Einziger Wermutstropfen ist bis jetzt, das mit diesen Umstellungen (das lighttpd nun ein Proxy für all diese API Ports ist) eine Remote-API Abfrage nun zwingend mittels XMLRPC erfolgen muss und BINRPC Anfragen damit lediglich für localhost (127.0.0.1) Verbindungen weiterhin funktionieren wird. Ergo sollte BINRPC nun IMHO als obsolete angesehen werden – es war ohnehin nie ein offizieller Standard.

[jmaus]

"Offizielle" Bugs, wie der Absturz der Rega nach regem Gebrauch von "&" bei system.exec werden wahrscheinlich nicht gefixt, oder weil es eine undokumentierte Funktion ist, muss man auch offiziell keine Änderungen tracken.

Aktuell sind mir keine weiteren Bugs/Probleme mit system.Exec() und "&" bekannt und entweder mit der ReGaHss R1.00.0388.0130 oder der neuesten R1.00.0388.0202 (in der CCU 3.41.7) sollte es keinerlei Probleme mehr mit der system.Exec() und "&" mehr geben.

Das schlimmste an der Geschichte ist für mich aber, das es den "offiziellen" Anschein macht, das die WebUI jetzt stahlhart ist, und keinerlei Sicherheitslücken mehr hat (und man die und alle Schnittstellen ohne Bedenken problemlos per Portforwarding ins Internet stellen kann), dabei wurde wahrscheinlich nur ein fetter Stahlriegel auf die Türe aus Pappe geschraubt.

Ich hoffe mein Beitrag vorher klärt ein wenig über die an den RemoteAPI Schnittstellen vorgenommenen Sicherheitsverbesserungen auf und zeigt das es mehr als nur ein "Stahlriegel auf die Türe aus Pappe" ist Trotzdem würde ich weiterhin nicht empfehlen (und das tut eQ3 weiterhin auch so) eine CCU via Port Forwarding direkt ins Internet zu hängen - auch wenn das mit der 3.41.7 Firmware nun bei weitem nicht mehr so schlimm sein sollte als mit vorherigen Firmwareversionen.

[deimos]

Hi,

der Post wäre sinnvoller im allgemeinen CCU3 Thread. Und eigentlich auch im.Changelog.

Viele Grüße
Alex