CCU3 Firmware 3.41.7 ist verfügbar

[Apothis]

Welche Ports werden eigentlich blockiert, wenn man bei den Firewall Regeln "Ports blockiert" auswählt ?
Ich habe keinen Unterschied festgestellt, wenn ich es umgeschaltet habe.

Die Beschreibung/Name dort ist etwas verwirrend, ich weiss. Mit dieser Einstellung "Ports blockiert" vs. "Ports offen" ändert man die Standardeinstellung der Firewall. D.h. bei "Ports blockiert" Blockiert ist ALLE Port bis auf die im folgenden eingestellten und auch nicht Port 80/443. Stellt man hingegen "Ports offen" ein ist die Standardeinstellung das kein Port blockiert wird jedoch die die im folgenden auf "Eingeschränkt" oder "Kein Zugriff" stehen werden entsprechend gehandhabt.

Danke für die Info.
Das erklärt dann das Verhalten, dass auch mit "Ports blockiert" die Verbindung normal funktioniert.

MfG

[ptweety]

Mit openHAB scheint es auch Probleme mit der neuen FW zu geben. Ich lasse erstmal die Finger von dieser Version; die "Verbesserungen" in die Sicherheit sind zwar wünschenswert, aber so noch nicht reif für die Produktion.

[jmaus]

Ihr müsst schon genauer/detallierter sein als nur sagen „geht nicht“ sonst kann man daran auch nicht verbessern/reparieren. In der Tat sollte alles bei der niedrigsten Sicherheitsstufe und mit deaktivitierter "Authentifizierung" unter "Sicherheit" alles so wie in den vorherigen Versionen funktionieren. Lediglich wenn man die Authentifizierung eingeschalten hat oder die Firewall zu dicht einstellt kann man davon ausgehen das externe Applikationen nicht mehr zugreifen können.

[hm4me]

Servus,

kurzes Status quo...
#Firmwareupdate 3.41.7 durchgeführt.
#Backup eingespielt.
#Firewall angepasst.
WICHTIG: -> Portfreigabe(n) anpassen.
#Manuelles Update cloudmatic durchgeführt.
ACHTUNG! Netzwerkgeräte in cloudmatic - insbesondere Kameras - funktionieren nicht. Hier gibt es lt. Support noch ein Update - Stichwort Binärinkompatibilität!
#e@Mail AddOn 1.6.8a funktionert.
#Programmdrucken AddOn 1.2a funktionert.
#Bedienung via Mediola APP auf den iPads funktioniert.
#Fernzugriff via pocket control HM App und AIO Remote NEO App funktioniert.
WICHTIG: -> Im Gerätemanager AIO Creator NEO (V2.4.4) unter Geräte -> Benutzer und Passwort der CCU eintragen!!!

So weit so gut.
Leider werden jedoch KEINE GERÄTE mehr unter Status und Bedienung der WebUI angezeigt.
Bei Klick auf Geräte hängt sich die CCU3 auf....

C o n c l u s i o:
Es hat den Anschein, dass dieses Firmwareupdate wieder einmal ohne gründliche Qualitäskontrolle erfolgt ist...
Daher: KEINE EMPFEHLUNG DAS UPDATE DERZEIT EINZUSPIELEN.

Grüße Euch
Robert

PS: Sollte jemand das Problem mit den Geräten gelöst haben, bitte um Info...

[zap]

So, ich habe das Update installiert. Vermutlich fällt jede externe Software (FHEM, OpenHab) damit auf die Schnauze, die von der CCU die RPC Schnittstellen abfragt und nicht stumpf die Ports 2001, 2010 usw. verwendet.

Eine Ahnung von dem Elend bekommt man, wenn man sich die InterfacesList.xml auf der CCU anschaut:

Code: Alles auswählen

<?xml version="1.0" encoding="utf-8" ?>
<interfaces v="1.0">
        <ipc>
                <name>BidCos-RF</name>
                <url>xmlrpc_bin://127.0.0.1:32001</url>
                <info>BidCos-RF</info>
        </ipc>
        <ipc>
                <name>VirtualDevices</name>
                <url>xmlrpc://127.0.0.1:39292/groups</url>
                <info>Virtual Devices</info>
        </ipc>
        <ipc>
                <name>HmIP-RF</name>
                <url>xmlrpc://127.0.0.1:32010</url>
                <info>HmIP-RF</info>
        </ipc>
        <ipc>
                <name>CUxD</name>
                <url>xmlrpc_bin://127.0.0.1:8701</url>
                <info>CUxD</info>
        </ipc>
</interfaces>

Dabei fällt auf: Bei BidCos steht immer noch xmlrpc_bin drin, obwohl das doch eigentlich nicht mehr verwendet werden soll. Anway, schlimmer sind die hier angegebenen Ports, z.B. 32001 statt 2001.

Eine Suche nach offenen Ports mit netstat liefert (am Beispiel BidCos-RF):

Code: Alles auswählen

tcp        0      0 0.0.0.0:42001           0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:2001            0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:32001           0.0.0.0:*               LISTEN      
tcp        0      0 :::42001                :::*                    LISTEN      
tcp        0      0 :::2001                 :::*                    LISTEN

Von den IPv6 Ports mal abgesehen: welche soll den jetzt bitte schön eine externe Software verwenden? 42001 ist SSL, 2001 ist ohne SSL, aber XMLRPC oder BINRPC? Und was ist 32001 ??

[jmaus]

Dabei fällt auf: Bei BidCos steht immer noch xmlrpc_bin drin, obwohl das doch eigentlich nicht mehr verwendet werden soll. Anway, schlimmer sind die hier angegebenen Ports, z.B. 32001 statt 2001.

Das ist schon alles soweit i.O. intern auf 127.0.0.1 kann man natürlich weiterhin BINRPC machen. Nur von extern wo nun alles über lighttpd geproxied wird kann man BINRPC nicht mehr verwenden.

Von den IPv6 Ports mal abgesehen: welche soll den jetzt bitte schön eine externe Software verwenden? 42001 ist SSL, 2001 ist ohne SSL, aber XMLRPC oder BINRPC? Und was ist 32001 ??

Auch das hatte ich prinzipiell bereits erklärt:

Ports mit 4xxxx sind SSL Ports
Ports mit 3xxxx sind nur für intern (127.0.0.1) gedacht
Ports mit xxxx (ohne 4 oder 3 am Anfang) sind wie gehabt von aussen verfügbar.

D.h. also ganz normal 2001, etc. nehmen wenn du kein SSL brauchst.

[zap]

Hallo Jens,

nichts für ungut, aber irgendwie ist das inkonsequent umgesetzt. Wenn die 3xxxx Ports nur für intern gedacht sind, sollte der Prozess auch nur auf 127.0.0.1 lauschen und nicht auf 0.0.0.0 = alle LAN Interfaces.

Zumindest in FHEM (und vermutlich auch in OpenHab) wird beim Start der CCU Schnittstelle die Liste der RPC Interfaces abgefragt. Und dabei wird weder 2001 noch 42001 sondern 32001 zurück gegeben. Also genau der Port, der nur intern benutzt werden soll.

In FHEM Modul HMCCU mache ich das so:

Code: Alles auswählen

string sifid;
foreach(sifid, root.Interfaces().EnumIDs()) {
  object oIf=dom.GetObject(sifid);
  if (oIf) {
    WriteLine("I;" # oIf.Name() # ';' # oIf.InterfaceInfo() # ';' # oIf.InterfaceUrl());
  }
}

Ergebnis:

Code: Alles auswählen

I;BidCos-RF;BidCos-RF;xmlrpc_bin://127.0.0.1:32001
I;CUxD;CUxD;xmlrpc_bin://127.0.0.1:8701
I;VirtualDevices;Virtual Devices;xmlrpc://127.0.0.1:39292/groups
I;HmIP-RF;HmIP-RF;xmlrpc://127.0.0.1:32010

Die 127.0.0.1 ersetze ich schon durch die CCU Adresse, aber die 3xxxx Ports werden halt übernommen und dann geht's schief.

Trotzdem danke für den Support.

Grüße
Dirk

[Fonzo]

WICHTIG: -> Im Gerätemanager AIO Creator NEO (V2.4.4) unter Geräte -> Benutzer und Passwort der CCU eintragen!!!

Also ich habe das mal ausprobiert bei mir wird trotz User und Passwort Eingabe dann beim Geräte Import von der CCU3 kein Gerät mehr in Import des NEO Gerätemanagers angezeigt.

[jmaus]

nichts für ungut, aber irgendwie ist das inkonsequent umgesetzt. Wenn die 3xxxx Ports nur für intern gedacht sind, sollte der Prozess auch nur auf 127.0.0.1 lauschen und nicht auf 0.0.0.0 = alle LAN Interfaces.

Klar kann man das verbessern. Und in der Tat ist das auch für die Zukunft so geplant das die 3xxxx Ports nur auf localhost (127.0.0.1) lauschen werden. Aber das muss man den jeweiligen Schnittstellenprozessen eben erst einmal beibringen.

Zumindest in FHEM (und vermutlich auch in OpenHab) wird beim Start der CCU Schnittstelle die Liste der RPC Interfaces abgefragt. Und dabei wird weder 2001 noch 42001 sondern 32001 zurück gegeben. Also genau der Port, der nur intern benutzt werden soll.

In FHEM Modul HMCCU mache ich das so:
[...]
Die 127.0.0.1 ersetze ich schon durch die CCU Adresse, aber die 3xxxx Ports werden halt übernommen und dann geht's schief.

Trotzdem danke für den Support.

Da bist du bzw. FHEM aber der einzige Service der das so macht bzw. auf die Interfaces.xml Datei zurückgreift. Das macht nicht einmal CUxD so und das läuft direkt auf der CCU. Dort werden die Ports auch hart in dessen cuxd.ini datei verdrahtet. Und ich würde dir davon abraten das weiterhin zu tun sondern die üblichen Ports wie sie in der Dokumentation beschrieben sind (2001, 2010, etc.) fest zu verdrahten. Es ist ohnehin IMHO sehr fragwürdig das du dann die 127.0.0.1 gegen eine externe IP Adresse ersetzt.

[zap]

Ich habe das halt so mal irgendwann gelernt, dass man Schnittstellen nutzt, wenn sie schon angeboten werden und solche Dinge on demand abfragt und nur im äußersten Notfall etwas "hart verdrahtet". Das rächt sich dann, wenn sich diese "hart verdrahteten" Parameter mal ändern.

Aber gut, Homematic = andere Welt.

Update:

- FHEM/HMCCU läuft nun wieder (aktuell bei mir, morgen dann hoffentlich auch beim Rest der FHEM Gemeinde).
- ioBroker läuft auch, wenn man den RPC auf Port 2001 von BINRPC auf XMLRPC umstellt
- OpenHab ???