Lehrprojekt mit FHEM und HomeMaticIP

Begonnen von Noran, 25 Mai 2018, 12:31:40

Vorheriges Thema - Nächstes Thema

Noran

Hallo liebe FHEM-ler,
im März haben wir begonnen FHEM bei uns an der Professur zu nutzen. Es ist zentrale Komponente für einen sogenannten digitalen Zwilling:
https://www.uni-weimar.de/de/bauingenieurwesen/professuren/intelligentes-technisches-design/lehre/digitaler-itd-zwilling/

FHEM dient dabei als Schnittstelle zu weiteren Elementen wie AR, VR, Simulationsumgebungen etc.

Für eine Konferenz im September ist eine Veröffentlichung geplant.

Die Korrespondenzen mit einer ersten Studentin laufen.

Ich hoffe bald kann ich mehr Details liefern.

Prof. Dr. Peter Henning

Wird bei mir auch in der Lehre eingesetzt.

LG

pah

ext23

Wenn ich da schon überall "TELNET" lese stößt es mir bitter auf als Sec Typ. Da hilft auch nicht die Aussage, dass es nur lokal ist...

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Prof. Dr. Peter Henning

@ext23: Didaktische Anforderungen hebeln auch an anderer Stelle Sicherheitsfragen aus.

LG

pah

Noran

@ ext23: Ich bin immer offen für Kritik. Vielleicht habe sie einen konstruktiven Vorschlag? Ich bin leider bei dem Thema Sicherheit nur Rudimentär bewandert. Mir schwebt auch eine Erweiterung von FHEM vor um die Sicherheit da zu verbessern. Von anderer Software kenne ich es zum Beispiel nur bestimmte IP-Adressen für Verbindungen zuzulassen. Ein weiterer Gedanke ist Verschlüsselungen direkt in FHEM  zu implementieren.

Mein Eindruck bisher ist, dass FHEM nicht so sehr auf Sicherheit an den Schnittstellen ausgelegt ist. Das sieht man auch bei der Verwendung der CUL's. Das ist doch auch unverschlüsselt oder irre ich mich?

Ansonsten wird im Moment ein App für Handy/Tablet entwickelt um eine erste Darstellung der Graphen zu realisieren.

Gruß Noran

eki

Kleiner Tip bezüglich UI: Es gibt mit FTUI ein ziemlich mächtiges Framework zur Erstellung von HMIs auf HTML Basis (enthält auch ein Widget zum Darstellen von verschiedenen Charts, und bietet auch Möglichkeiten responsive Oberflächen zu erstellen) und ist aus meiner Sicht flexibler als eine native APP.

CoolTux

Zitat von: Noran am 13 Juli 2018, 08:40:14
@ ext23: Ich bin immer offen für Kritik. Vielleicht habe sie einen konstruktiven Vorschlag? Ich bin leider bei dem Thema Sicherheit nur Rudimentär bewandert. Mir schwebt auch eine Erweiterung von FHEM vor um die Sicherheit da zu verbessern. Von anderer Software kenne ich es zum Beispiel nur bestimmte IP-Adressen für Verbindungen zuzulassen. Ein weiterer Gedanke ist Verschlüsselungen direkt in FHEM  zu implementieren.

Mein Eindruck bisher ist, dass FHEM nicht so sehr auf Sicherheit an den Schnittstellen ausgelegt ist. Das sieht man auch bei der Verwendung der CUL's. Das ist doch auch unverschlüsselt oder irre ich mich?

Ansonsten wird im Moment ein App für Handy/Tablet entwickelt um eine erste Darstellung der Graphen zu realisieren.

Gruß Noran

FHEM Telnet kann auch SSL, ausserdem ist es möglich über die allowed Instanz das Attribut allowed_from zu setzen, um nur bestimmte IP Adressen zu zu lassen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Prof. Dr. Peter Henning

Eine "Verschlüsselung direkt in FHEM" halte ich für unsinnig. Alle Sicherheitsaspekte können über die Umgebung realisiert werden, in der FHEM läuft.

LG

pah

Noran

Zitat von: Prof. Dr. Peter Henning am 13 Juli 2018, 10:22:44
Eine "Verschlüsselung direkt in FHEM" halte ich für unsinnig. Alle Sicherheitsaspekte können über die Umgebung realisiert werden, in der FHEM läuft.

LG

pah

Können sie mir da vielleicht noch andere Stichworte außer SSH nennen?

Mit freundlichen Grüßen
Noran

ext23

Zitat von: CoolTux am 13 Juli 2018, 09:15:35
ausserdem ist es möglich über die allowed Instanz das Attribut allowed_from zu setzen, um nur bestimmte IP Adressen zu zu lassen.

Das ist imho Blödsinn, das entspricht keiner Verschlüsselung und ist im Prinzip derselbe Blödsinn wie ein MAC Filter im WLAN Netz. Unbrauchbar und maximal so viel Wert wie ein vereister Schließzylinder...

Zitat von: Noran am 13 Juli 2018, 08:40:14
Mein Eindruck bisher ist, dass FHEM nicht so sehr auf Sicherheit an den Schnittstellen ausgelegt ist. Das sieht man auch bei der Verwendung der CUL's. Das ist doch auch unverschlüsselt oder irre ich mich?

Richtig, nun muss mal schauen ob der CUL via USB angebunden ist oder via LAN. Sicherlich kann man alles in einem eigenen (V)LAN betreiben. Aber in der heutigen Zeit, wo Verschlüsselung auf so gut wie jedem µC ohne große Sprünge läuft ist es nicht Wert auch nur ein Augenzwinkern daran zu verschwenden mit unverschlüsselten Protokollen zu arbeiten.

Und genau weil sich viele keine Gedanken machen auch mangels Kompetenz haben wir heute Kraftwerke die mit SCADA Systeme Arbeiten die offen sind wie die nächste Dorfkirche und Autos die anfällig gegen jegliche Replay Attacke sind um sie zu öffnen... Nur mal als Beispiel...

Es ist schwer nachzuvollziehen in einer Zeit wo die Runden Ecken an Buttons wichtiger sind als Sicherheit. Solange alles läuft, kein Thema, so lange alles läuft stört mich auch ein AKW umde Ecke nicht... Solange nicht jemand die angeblich so gut verschlüsselten WhatsApp Nachrichten mitlist wo der Key auf irgend welchen Server liegt damit das Restore beim neuen Handy auch schön einfach ist, alles kein Thema...

Gut wie dem auch sei, ich kann da nicht weiter helfen. Das ist ein Thema in welches man sich reinarbeiten muss. Aber es ist für jedermann sicher vom Vorteil das immer im Hinterkopf zu haben, genau so wie man immer dran denkt die Tür hinter sich abzusperren. ;-)

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

JoWiemann

Ersten
Pauschal von ungesicherten SCADA Systemen zu reden von denen man keine Ahnung hat und auch nur in der Presse gelesen hat ist Blödsinn.

Zweitens
Alle Systeme sind so sicher, wie der, der vor dem Bildschirm sitzt, es zulässt.

Drittens
Sicherheit ist immer Aufwand. Und das fängt beim Wissen an.

Viertens
Erst nach einer fundierten Risikoabschätzung kann ich, oder ein wissender Beauftragter, eine fundierte Aussage machen.

Fünftens
Nicht alles, was preiswert zu haben ist sicher. Sicherheit kosten. Sichere Smarte Komponenten sind teuer. Ob aber jeder Aktor oder jeder Sensor hoch verschlüsselt angesprochen werden muss, zeigt die Risikoanalyse.

Sechstens
Fhem ist so sicher, wie ich es mache. Da es offen ist kann jeder es sicherer machen.

Aber es ist wie immer...


Gesendet von iPhone mit Tapatalk

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Noran

Ich kann den Unmut und die Diskussion um das Thema Sicherheit gut verstehen. Mein ehemaliger Chef hat einen Spruch gehabt den er immer gerne brachte: "Wir brauchen nicht noch mehr Probleme, sondern Lösungen dazu." Mittlerweile verstehe ich diesen Spruch als Zusammenfassung von Lösungsorientiertem Arbeiten. Dementsprechend wäre es interessanter für mich, wenn an dieser Stelle Vorschläge zu Umsetzung oder Literaturhinweise gegeben würden, anstatt über Sicherheit von Kernkraftwerken zu diskutieren.

Ansonsten denke ich gibt es im August/September neues in dem Projekt. Hoffentlich dann die mobile-App - wobei das Webtool nicht außer acht gelassen werden soll, danke dafür.

Mit freundliche Grüßen
Noran

Amenophis86

Lösung: Suchfunktion im Forum. Dort finden sich einige Vorschläge zur Sicherheit :)
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Prof. Dr. Peter Henning

Alle Sicherheitsaspekte sind im Forum schon behandelt worden.

Es ist sicher auch nicht Aufgabe des Forums, Literaturangaben für studentische Projekte zu liefern. Die Sicherheitsproblematik besteht nämlich - und in sofern ist die Diskussion über die Sicherheit von Kernkraftwerken vollkommen richtig - unabhängig vom Einsatzzweck.

Mein Tipp daher: Einfach mal selbst recherchieren. Eine Google-Suche mit den Stichworten "Sicherheit Raspberry Pi" liefert nicht umsonst 149 Millionen Hits. Etwas weniger, wenn man wirklich Fachliteratur sucht, nur 3,85 Millionen Hits. Aber da wird schon etwas dabei sein.

LG

pah

JoWiemann

Hm, die Diskussion um Sicherheit in der IT wird leider nur technologisch und nicht Verhaltensorientiert geführt.

Wir haben in in dem Unternehmen in dem ich tätig bin etwa zehn Jahre gebraucht um die Einstellung und das Verhalten in der Arbeitssicherheit grundlegend zu verändert. Heute akzeptiert jeder, das Unfälle nicht geschehen sondern verursacht werden. Das man der Ursache nur auf den Grund gehen kann, wenn auch die nebensächlichsten Unfälle oder Beinahunfälle gemeldet werden und dass das Befolgen von Regeln zur Arbeitssicherheit das Wichtigste ist.

Für die Sicherheit gerade in der Softwareentwicklung findet dieses Umdenken gerade statt. Das heißt nicht das es nicht bereits Regeln gibt. Aber die gab es damals in der Arbeitssicherheit auch und wir hatten trotzdem zu viele Unfälle. Wie geschrieben. Die Haltung muss sich ändern. Software muss nicht nur gut aussehen, am Besten noch funktionieren, sondern grundsätzlich sicher sein.


Gesendet von iPhone mit Tapatalk

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM