CCU-Protect v3.01 (obsolete) - Lokale Firewall für die CCU3

[speedcow]

Die Infos sollen mir reichen, bitte schicke mir das neue Paket. Ich werde es voraussichtlich erst nach Weihnachten schaffen, die Doku zu aktualisieren.

[blackhole]

Ich werde es voraussichtlich erst nach Weihnachten schaffen, die Doku zu aktualisieren.

Melde dich einfach, wenn du Zeit dafür findest. Ich schicke dir dann das aktuelle Paket zeitnah zu.
Bis dahin werde ich sicherlich noch die ein oder andere Änderung vornehmen.

[ma_st]

Hallo blackhole,

ich hätte auch Interesse an der aktuellen Version für die CCU2.

Vielen Dank

[blackhole]

ich hätte auch Interesse an der aktuellen Version für die CCU2.

Ich nehme dein Interesse lediglich zur Kenntnis, da noch völlig unklar ist, ob ich das Projekt hier im Forum fortführe (siehe diesen Beitrag).

Falls ich das Projekt hier im Forum weiterführen werde, werde ich ausschließlich CCU-Protect ab v4.68 (für die CCU3 und Derivate) verteilen und supporten. Ende Januar sind die hier genannten sechs Wochen abgelaufen, dann wird es von meiner Seite eine Entscheidung geben.

Die CCU2 ist veraltet und liegt nicht mehr im Fokus meines Interesses. Daher wird es von meiner Seite weder Tests in Sachen Lauffähigkeit und Funktionalität von CCU-Protect v4.68, noch Support für die CCU2 geben. Den Support für CCU-Protect v3.01 stelle ich ein, da ich diese Version selbst nicht mehr einsetze. Insofern ist "Option b)" bereits jetzt aussortiert.

CCU-Protect v4.68 ist, was meinen Bedarf und meinen Anspruch angeht, fertig und wäre somit die Version, die ich releasen würde.

Was allerdings fehlt ist die Komplettüberarbeitung dieses Beitrages, da sich CCU-Protect v4.68, wie hier bereits teilweise ersichtlich, von der Vorgängerversion in vielerlei Hinsicht unterscheidet. Falls ich das Projekt hier im Forum fortführen werde, werde ich also zuerst den Beitrag überarbeiten und erst dann die neue Version releasen.

Bereits jetzt ist klar, dass ich CCU-Protect v3.01 definitiv nicht mehr weiterführe. Diese Version ist veraltet und weist im Vergleich zu CCU-Protect v4.68 deutliche Nachteile auf.

[jmaus]

ich hätte auch Interesse an der aktuellen Version für die CCU2.

Auch wenn ich selbst noch nie meinen Senf zu diesem Projekt hier beigetragen haben, so möchte ich doch aus gegebenem Anlass nicht vermissen für alle CCU2, CCU3 und RaspberryMatic Nutzer mit aktuellen CCU Firmwares deutlich zu machen, das die interne Firewall-Funktionalität die eine CCU bzw. RaspberryMatic mit aktueller Firmware bereits mit sich bringt IMHO nicht nur vollkommen ausreichend ist, sondern bei entsprechender Konfiguration in der WebUI in gleichem Maße Sicherheit bietet wie das hier vorgestellte "CCU-Protect".

Vor vielen Jahren gab es vielleicht mal eine Zeit, da war es durchaus legitim die Konfigurationsmöglichkeiten der iptables-basierten internen Firewall besser einstellbar und damit sicherer zu machen. Aber schon seit vielen, vielen CCU/RaspberryMatic-Firmware Versionen ist die interne Konfiguration der bereits mitgebrachten Firewall einer CCU/RaspberryMatic in gleichem Maße sicher, sodass schon alleine der Name "CCU-Protect" ein IMHO falsches zusätzliches Sicherheitsgefühl suggeriert. Darüberhinaus möchte ich auch zu bedenken geben, dass durch das nicht-öffentliche Entwickeln+Verteilen dieses Paketes durchaus aus heutiger Sicht die Frage berechtigt sein kann, inwieweit die Nutzung dieses Paketes nicht zusätzliche Sicherheitsrisiken mit sich bringt, eben weil es nicht öffentlich (z.B. bei GitHub & Co) einsehbar und damit von Drittentwicklern nicht direkt verifizierbar ist.

[blackhole]

Auch wenn ich selbst noch nie meinen Senf zu diesem Projekt hier beigetragen haben, so möchte ich doch aus gegebenem Anlass nicht vermissen für alle CCU2, CCU3 und RaspberryMatic Nutzer mit aktuellen CCU Firmwares deutlich zu machen, das die interne Firewall-Funktionalität die eine CCU bzw. RaspberryMatic mit aktueller Firmware bereits mit sich bringt ...

Das kann man (fast) alles so stehen lassen und ist letztendlich auch der Grund dafür, dass es praktisch keine relevante Nachfrage nach CCU-Protect mehr gibt.

In der Praxis ist es jedoch so, dass 99% der Benutzer die CCU-eigene Firewall entweder völlig unzureichend oder "auf Durchzug" eingestellt haben, was die Folge hat, dass diese Firewall praktisch keinerlei Funktion mehr hat (obwohl sie durchaus eine Funktion haben könnte).

Das hat natürlich auch einen Grund: Die mitgelieferte Firewall wurde an 99% aller Benutzer vorbeiprogrammiert. Selbst die bekannten Supporter hier im Forum (alle) geben praktisch immer den gleichen Ratschlag, wenn eine Konfiguration der Firewall die Lösung für ein Problem ist: Abschalten.

Von einer granularen, punktuellen Lösung, habe ich hier im Forum in all den Jahren vielleicht ein oder zweimal etwas gelesen und das obwohl die CCU-interne Firewall das durchaus könnte.

CCU-Protect hingegen ist technisch nicht etwa "sicherer", sondern einfach konzeptionell und in der Konfiguration klarer, im Ergebnis eindeutig, völlig transparent und auch für den einfachen Benutzer, in dem was CCU-Protect macht, in allen Belangen 100%ig nachvollziehbar. Und das ist prinzipbedingt so (KISS). Genau deshalb trägt sie den Namen "CCU-Protect" auch völlig verdient und zurecht.

Insofern zieht dein "nicht öffentlich"-Argument in keiner Weise. Das Gegenteil ist eher der Fall: Für 99% aller Benutzer ist das, was die CCU-eigene Firewall macht, mehr als nur nebulös und undurchschaubar. Nur deshalb wird sie regelmäßig einfach abgeschaltet und hat deshalb auch praktisch keinen Nutzen und bietet dann natürlich auch keinerlei Sicherheit - obwohl sie könnte.

Die CCU-eigene Firewall ist zu einem hinderlichen Ding geworden "das man abschaltet", damit das "was man erreichen möchte", einfach funktioniert. Das kannst du 1000-fach hier im Forum nachlesen - ohne jegliche Übertreibung.

[jmaus]

Auch wenn ich selbst noch nie meinen Senf zu diesem Projekt hier beigetragen haben, so möchte ich doch aus gegebenem Anlass nicht vermissen für alle CCU2, CCU3 und RaspberryMatic Nutzer mit aktuellen CCU Firmwares deutlich zu machen, das die interne Firewall-Funktionalität die eine CCU bzw. RaspberryMatic mit aktueller Firmware bereits mit sich bringt ...

Das kann man (fast) alles so stehen lassen und ist letztendlich auch der Grund dafür, dass es praktisch keine relevante Nachfrage nach CCU-Protect mehr gibt.

Na dann sind wir uns ja vielleicht einig, dass du das Projekt am besten beerdigen könntest und wenn du hier/da noch gewisse Verbesserungsvorschläge für die interne Firewall der CCU oder RaspberryMatic hast (weil dir vllt. bei der Entwicklung rund um "CCU-Protect" was aufgefallen ist), kannst du die natürlich gezielt vorbringen und dann kann man diese Dinge ggf. einarbeiten sodass dies auch für jedermann unter GitHub einsehbar/verifizierbar ist.

Insofern zieht dein "nicht öffentlich"-Argument in keiner Weise. Das Gegenteil ist eher der Fall: Für 99% aller Benutzer ist das, was die CCU-eigene Firewall macht, mehr als nur nebulös und undurchschaubar. Nur deshalb wird sie regelmäßig einfach abgeschaltet und hat deshalb auch praktisch keinen Nutzen und bietet dann natürlich auch keine Sicherheit, obwohl sie könnte.

Tut mir leid, aber das sehe ich (wie du dir denken kannst) vollkommen anders. Du hüllst dich regelmäßig in Schweigen, verteilst wahllos Versionen an irgendwelche Personen und das auch nur auf Nachfrage/Anfrage. Tut mir leid, aber das hat nichts mit transparenter Softwareentwicklung zu tun, sondern begründet sich sicherlich nur in deinem Wunsch nach Anerkennung und Ehrdarbietung. Im Gegensatz dazu sind jedoch alle Routinen, Funktionen, WebUI Konfigurationsmöglichkeiten usw. der internen Firewall der CCU und RaspberryMatic unter GitHub für jedermann, zu jederzeit direkt einsehbar, sodass Personen mit entsprechender Expertise dort frei verfügbar Sicherheitslücken oder Backdoors aufdecken könnten. In deinen Software-Entwicklungen (inkl. CCU-Protect) ist das nicht der Fall und alleine daher würde ich daher "CCU-Protect" schon als unsicherer einstufen. Denn wer sagt denn bitte das du nicht an Person X eine angepasste Version verteilst und an Person Y eine andere? Transparenz sieht anders aus und das was du hier "entwickelst" entspricht nicht dem aktuellen Stand der Technik wie man vermeintliche freie Softwareentwicklung betreibt.

Und gerade bei solch einer sicherheitskritischen Komponente wie einer Firewall sollte Transparenz in der Softwareentwicklung absolut geboten sein wenn Nutzer dieser Lösung darauf bauen können sollten, das diese Lösung auch wirklich vermeintlich sicher ist.

[blackhole]

Und gerade bei solch einer sicherheitskritischen Komponente wie einer Firewall sollte Transparenz in der Softwareentwicklung absolut geboten sein wenn Nutzer dieser Lösung darauf bauen können sollten, das diese Lösung auch wirklich vermeintlich sicher ist.

Bei CCU-Protect kann jeder Benutzer (unabhängig von seinen Skills) sofort nachvollziehen ob das Regelwerk greift.
Bei der CCU-internen Firewall, lautet die Lösung in 99% aller Fälle immer: Schalte das Ding ab.

Die Nachvollziehbarkeit des Regelwerkes auf iptables-Basis (für Leute die sich damit beschäftigen möchten) möchten bringt CCU-Protect sogar als Option mit. Der Generierung des Regelwerkes liegt jedem Benutzer in einfach lesbarem Klartext vor. Alles OSS. Alles sehr einfach.

Leute, die CCU-Protect einsetzen, haben eine aktive Firewall, weil sie es es so wollen und weil Dinge auch mit aktiver Firewall einfach funktionieren können. Leute, die die CCU interne Firewall "einsetzen", schalten sie ab, sobald etwas nicht funktioniert.

Frage mal einen einfachen CCU-Benutzer wie und wo das Regelwerk der CCU-eigenen Firewall generiert wird und wie es sich auswirkt.
Frage mal einen einfachen CCU-Benutzer wie und wo das Regelwerk von CCU-Protect generiert wird und wie es sich auswirkt.

Die auch für den einfachen Benutzer wichtige Transparenz erhält dieser ganz gewiss mit CCU-Protect: Er kann die obige Frage beantworten.
Mit der CCU-eigenen Firewall bleiben für den einfachen Benutzer alle wichtigen Fragen unbeantwortet, da die Antwort viel zu kompliziert ist.
Darum schaltet letzterer ab, darum schalten sogar die Supporter ab und das ist aus Sicht der IT-Sicherheit schlecht. Richtig schlecht.

[jmaus]

Alles OSS. Alles sehr einfach.

Ich bleibe dabei: Das was du hier veröffentlichst hat aber auch gar nichts mit "OSS" (OpenSource Software) Entwicklung zu tun! Weder gibst du die konkrete Lizenz an unter der "CCU-Protect" steht, noch stellst du die Software in einer ausreichenden Versionierung frei im Internet (ohne Zwang des Nachfragens bei dir) irgendwo zur Verfügung damit sich die jeder selbst in einer konkreten freigegebenen Version runterladen+installieren bzw. reviewen kann. Das macht ein transparentes Review deiner Entwicklung/Methoden/Funktionen unmöglich und damit ist der propagierte Sicherheitsgewinn komplett dahin! Überdenke dies und dein CCU-Protect mag vielleicht einen Mehrwert haben.

In der gegenwärtigen Form jedoch nicht und da die CCU/RaspberryMatic interne Firewall vollkommen ausreichend und sicher genug ist, gibt es IMHO ohnehin nur eine zweifelhafte Existenzberechtigung für diese intransparente Lösung eines vermeintlichen Problems das in 2022 nicht mehr existiert.

[blackhole]

Überdenke dies und dein CCU-Protect mag vielleicht einen Mehrwert haben.

Das habe ich bereits vor langer Zeit getan und es war die beste Entscheidung, die ich hier im Rahmen dieses Forums je getroffen habe.
Ich bin in der komfortablen Situation, dass ich hier nur Dinge teile, die ich selber für mich geschrieben habe.
Ob und wie ich teile entscheide ich und kein anderer. Das ist ein Hobby und das soll es auch bleiben.
Der Mehrwert ist für mich immer gegeben, da ich für mich entwickle und nicht für andere.
Daher macht es für mich auch keinen Unterschied, ob ich etwas teile oder eben nicht.

In der gegenwärtigen Form jedoch nicht und da die CCU/RaspberryMatic interne Firewall vollkommen ausreichend und sicher genug ist

Das ist sie aufgrund ihres Konzeptes in keiner Weise.
Solange Benutzer und Supporter die interne CCU-Firewall regelmäßig abschalten, ist de facto keine Sicherheit vorhanden.