Ich wünsche mir das die FHEM User etwas aufmerksamer werden

[CoolTux]

Guten Morgen liebe FHEM User und FHEM Mitstreiter,

Aus aktuellem Anlass habe ich beschlossen einen Wunsch an die FHEM User zu äußern.
Worum geht es. Ganz klar, es geht um das featureLevel 5.8 was vor ein paar Tagen aktiviert wurde. Was war passiert? Einige Funktionen, welche bereits seit Monaten oder gar einem Jahr in FHEM Schlummern wurden mit dem umschalten auf das featureLevel 5.8 als Standard aktiviert. Unter anderem gehörte dazu der csrf Token. Und hier gab es nun mit einigen ThirdPart Anwendungen und Lösungen (eigene get cmd Aurfufe, Taskerautomatisierungen) Probleme, weil diese nicht mehr einfach einen ?cmd Befehlsaufruf zu ließen.
Doch warum wurde das gemacht und was genau ist CSRF? Die meisten User haben sich nicht mal die Mühe gemacht zu schauen was CSRF eigentlich ist. Nein sie haben lieber das ganze deaktiviert und meinten dann na ich bin doch in meinem eigenen Netzwerk oder ich benutze ein VPN. NEIN!! Das hat damit rein gar nichts zu tun. Auch im eigen Netzwerk und über VPN ist der Angriff möglich.
Bitte bitte informiert Euch doch bei so wichtigen Dingen wie Sicherheit erstmal was genau das was hier erwähnt wurde bedeutet.

Doch was mich noch viel mehr ärgert. Es wird in diesen Foren Thread und Seitenweise darüber diskutiert das FHEM nur für interne Netze sicher ist und das sowas ja gar nicht geht und was man da machen kann. Es werden Empfehlungen und Anleitungen gegeben wie man einen ReverseProxy mit Passwort oder gar Zertifikat aufbaut, es werden VPN Lösungen präsentiert ABER WENN dann wirklich eine Sicherheitslösung angeboten wird für einen tatsächlich Sicherheitsrelevanten Bereich dann wird dieser einfach abgeschalten nur weil man zu faul ist sich darüber zu Informieren.
Es ist egal ob Ihr VPN habt oder ob Ihr in Eurem eigenen Netz seit. Im einfachsten Fall reicht es aus das Ihr einen zweiten Tab im Browser habt und eine Seite Aufruft die Schadcode enthält und schon kann auf den ersten Tab zugegriffen werden wo FHEM WEB gerade offen ist und ein CMD ausgeführt werden. (ACHTUNG ERKLÄRUNG WURDE MIT ABSICHT EINFACH GEHALTEN.)
Wenn sich also Rudi und die anderen Entwickler die Mühe machen so ein sinnvolles Sicherheitsfeature ein zu bauen, dann benutzt es doch bitte.

Und bitte bitte Informiert Euch mehr bei wichtigen Themen. Gerade wenn es um Sicherheit geht. Wir können nicht jeden einzelnen User erklären wie die Welt funktioniert, soviel Zeit haben wir einfach nicht. Oder FHEM bleibt auf der Strecke und kümmern uns darum Euch zu erklären über das hier und jetzt und was Schrödingers Katze damit zu tun hat.



Grüße
Leon

[Thyraz]

Ich denke das Problem ist, dass nicht jeder User hier das nötige KnowHow hat um das für seine Use-Cases umzusetzen.
Man hat ja selbst in vielen Modulthreads gesehen, dass auch der eine oder andere Modul-Developer kurz etwas ratlos da stand.

Evtl. sollte man im 5.8 Ankündigungsthread noch Best-Practice Beispiele und Tipps verlinken?
(Und eben auch genau deine Hinweise, dass das temporäre Abschalten auch in privaten Netzen ein Sicherheitsproblem ist.)
Also Aufruf über Shell, Web, etc.
Welche Möglichkeiten hab ich das ganze dennoch recht gut abzusichern, wenn ich für einen Use Case keine dynamischen Token rausbekomme, usw.

Gibt ja mittlerweile viele gute Beiträge, verteilt über diverse Threads.
Von Rudi hab ich z.B. gestern glaub irgendwo einen Einzeiler gesehen, um den Token auf Shell Ebene zu ziehen.
Von dir kam glaub auch irgendwo ein guter Tip, notfalls ein eingeschränktes Webdevice dazu zu verwenden, ggf. mit festem Token (besser als keiner).

[CoolTux]

Ich kann verstehen das nicht jeder das nötige KnowHow hat, aber darum geht es auch nicht. Wenn ich etwas lese von Sicherheit und Sicherheitstoken sollte bei jedem erstmal die Aufmerksamkeitssynapsen anspringen. Gerade wenn ich eine Hausautomatisierung habe. Es sollte versucht werden im Selbststudium heraus zu finden worum es genau geht.
Immerhin schaffen diese Leute es ja auch einen technischen Artikel/Anleitung um zu setzen (VPN/ReverseProxy).

[mahowi]

Wobei es auch generell um die Aufmerksamkeit der User geht, bzw. darum erstmal nach Antworten zu suchen. Als debian.fhem.de nicht erreichbar bzw. nicht mehr über https erreichbar war, gab es dazu gefühlte hundert Threads mit genau denselben Fragen.

[Thorsten Pferdekaemper]

Hi,
ich frage mich, ob das dieselben Leute sind. Ich meine die, die sich über ReverseProxy, HTTPS etc. Gedanken machen und solche, die das Token abschalten. (Ich habe übrigens auch immer noch so meine Probleme, zu verstehen, warum der Token das ganze sicherer macht. Es wird vielleicht ein klein wenig komplizierter, aber möglich ist der Angriff doch immer noch, oder?)   
Von wegen Aufregung und Upgrade auf 5.8: Hier frage ich mich, ob die Leute das auch bei anderer Software so machen. Also z.B. den Upgrade auf Windows 10 an dem Tag, an dem es verfügbar ist, und am besten noch auf dem Rechner, auf dem ich meine Rechnungen schreibe. Das macht doch eigentlich auch keener, oder?
Gruß,
   Thorsten

[CoolTux]

Muß mich entschuldigen. Heute Morgen war ich nicht Aufmerksam 
Habe das jetzt mal in das Ansatzweise richtige Forum verschoben.

@Thorsten
Ein Angriff ist irgendwie immer möglich. Machen wir uns nichts vor, es wird nie 100% Sicherheit geben. Aber diese eine kleine Token erhöht den Schutz vor einem Möglichen CSRF Angriff enorm.
Du findest sehr gute Beispiele auf der verlinkten Wikiseite unter Beispiele.

[rudolfkoenig]

Ich habe übrigens auch immer noch so meine Probleme, zu verstehen, warum der Token das ganze sicherer macht. Es wird vielleicht ein klein wenig komplizierter, aber möglich ist der Angriff doch immer noch, oder?

Es geht darum, dass man auf einer Seite wie meinFhemBlog.de oder gar forum/wiki.fhem.de ein Boesewicht N "Bilder" reinstellt ala:

Code Auswählen Erweitern

<img src="http://192.168.178.1+N:8083/fhem?cmd=set .* off">


Wenn der Benutzer im Browser die FHEMWEB-Seite irgendwann nach dem Browser Start aufgerufen hat (das FHEMWEB Tab kann inzwischen schon zu sein), dann ist der Zugriff auf FHEMWEB von der Boesewicht-Seite moeglich, da der Browser basicAuth gemerkt hat. VPN/reverseProxy mit Zertifikat ist egal, auch dass ich FHEMWEB nur von Zuhause aufrufe.

Ab 5.8 werden FHEM Befehle nur mit einem gueltigen csrfToken ausgefuehrt, d.h. das Obige funktioniert nicht.

Die "boese" Seite kann mW nicht an das csrfToken kommen, da diese von einer anderen Domain (== URL) stammt, und aktuelle Browser es nicht zulassen, dass man per JS solche Daten analysiert, sei es aus einem iFrame oder per XHR. ES SEI DENN man erlaubt das explizit in FHEMWEB via das CORS Attribut.
D.h. mit CORS ist dieser Angriffstyp schwerer geworden, ohne CORS unmoeglich.

Wenn ich was falsch verstanden habe, dann bitte mich  (dringend) korrigieren

[CoolTux]

So in der Art habe ich das auch verstanden. Gibt im Netz einige Beispiele/Szenarien für eine solche Manipulation/Angriff.

Ich denke das die User genau das erwartet hätten, eine solche Erklärung im Informationsthread zu 5.8. Gut kann man machen, aber ich finde immer noch das auch die User in der Pflicht sind. Fehlt eine solche Erklärung sollte man sich informieren.

[KölnSolar]

Hi Leon,
erst mal die Frage: Warum stellst Du den Beitrag ins Subforum zum CUL-Development 
Ein newbie hätte sich dafür schon einen Rüffel eingefangen.  Zeigt aber vermutlich nur, wie sehr Du Dich geärgert hast 

Ansonsten gebe ich Dir einerseits Recht, muss Dir aber insofern widersprechen, dass es eben eine Menge User gibt, die sicherlich schon alleine beim Lesen des Ankündigungsthreads und der Stichwörter "pearlSyntaxCheck" und "CSRFToken" dicht gemacht haben. Es gibt eben die User, die ihren WLAN-Schlüssel und Routerzugangsdaten immer noch im Auslieferungszustand haben. Die selben Menschen möchten aber auch gerne FHEM nutzen. Und, wenn dann noch als Lösung eines Problems vorgeschlagen wird: Es gibt ein Attribut, mit dem sich die Probleme abstellen lassen ? ! ? ! ? ! Was wollen wir dann von den Nicht-ITlern anderes erwarten, als dass das Attribut gesetzt wird und diese eigentlich falsche Vorgehensweise sich auch noch wie ein Virus in der Community ausbreitet ?

Ich bin daher der Meinung, dass bei solchen besonderen Themen wie Sicherheit etc. anders verfahren werden muss.
1. Das Abschalten über ein Attribut darf überhaupt nicht kommuniziert werden !
2. Anstatt die Änderung technisch korrekt zu beschreiben, sollten die denkbaren(ja und man kann als Entwickler nicht an alles denken) in ihren Symptomen beschrieben und Lösungsmöglichkeiten beschrieben werden. So etwas fehlte in der Ankündigung völlig.
3. Und dann sollte es ein vorübergehendes Unterforum für die Fälle geben, denen die vorgedachten Symptom- und Lösungsbeschreibungen nicht geholfen haben. Und dort stelle ich mir die Zugriffsberechtigungen dann etwas anders als üblich vor. Jeder kann ein Thema eröffnen. Zu diesem Thema können aber nur der TE selber und User mit "übergreifenden" Zugangsberechtigungen" antworten, also User, die auch wirklich wissen wovon sie reden, wie im konkreten Fall: Du, Rudi, Udo, Andre..... Landet dann doch unvermeidbar eine Fragestellung in einem anderen Unterforum können unsereiner auf das spezielle Subforum und die dortigen Beiträge verweisen(und mehr sollte man dann auch nicht mehr machen). (Ob so was in unserem Forum realisierbar ist, weiß ich natürlich nicht.)

Und mal allgemein: Insgesamt wird meines Erachtens das Thema Sicherheit etwas zu stiefmütterlich behandelt. Ich nenn hier mal nur kurz als Stichwort "Alexa", Port am Router öffnen und dann ??

Grüße Markus

Edit: Zwischenzeitlich gab es einige Antworten, aber ich belasse meinen Post ohne darauf einzugehen 

[herrmannj]

wenn jemand die Zeit und Lust hat dann kann "er||sie" im wiki(?) eine demoseite aufsetzen:

als html quellcode einfüggen:

Code Auswählen Erweitern

<img src="http://192.168.178.1:8083/fhem?cmd=set .* off">
<img src="http://192.168.178.2:8083/fhem?cmd=set .* off">
<img src="http://192.168.178.3:8083/fhem?cmd=set .* off">

...

Code Auswählen Erweitern

<img src="http://192.168.178.252:8083/fhem?cmd=set .* off">
<img src="http://192.168.178.253:8083/fhem?cmd=set .* off">
<img src="http://192.168.178.254:8083/fhem?cmd=set .* off">


vg
joerg

edit:

beliebig per js  (XMLHttpRequest) zu verfeinern. Local netmask, andere ports etc ... wird für user die es "erleben" sicher unterhaltend ...

[Thorsten Pferdekaemper]

Die "boese" Seite kann mW nicht an das csrfToken kommen, da diese von einer anderen Domain (== URL) stammt, und aktuelle Browser es nicht zulassen, dass man per JS solche Daten analysiert, sei es aus einem iFrame oder per XHR. ES SEI DENN man erlaubt das explizit in FHEMWEB via das CORS Attribut.
D.h. mit CORS ist dieser Angriffstyp schwerer geworden, ohne CORS unmoeglich.

Diesen Zusammenhang hatte ich tatsächlich bisher nicht gesehen. Danke, mit dieser Erklärung wird es klar.
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

1. Das Abschalten über ein Attribut darf überhaupt nicht kommuniziert werden !

Meiner Meinung nach ist das Vorgehen in dieser Hinsicht bisher richtig. Ich würde es so machen:

• Release 5.7: Token einbauen, aber per Default abgeschaltet lassen.
• Release 5.8: Den Default ändern, aber abschaltbar machen
• Release 5.9: Nicht mehr abschaltbar.

Gruß,
   Thorsten

[Beta-User]

Von wegen Aufregung und Upgrade auf 5.8: Hier frage ich mich, ob die Leute das auch bei anderer Software so machen. Also z.B. den Upgrade auf Windows 10 an dem Tag, an dem es verfügbar ist, und am besten noch auf dem Rechner, auf dem ich meine Rechnungen schreibe.

Gehört eigentlich nicht so richtig in diesen Thread, aber ich habe da mal eine Verständnisfrage dazu, da offensichtlich auch andere hier im Forum ein derartiges Verständnis von dem update haben.

Diese Sichtweise deckt sich nämlich nicht mit dem, was ich bisher zu updates innerhalb FHEM verstanden hatte:
- Wir gehen bei Problemlösungen grundsätzlich davon aus, dass der User ein aktuelles FHEM hat. Da gibt es aber eigentlich kein Nebeneinander von 5.7 und 5.8 (anders als bei Win7 und Win10, wo beide aktuell sein können), sondern nur genau ein aktuelles Modul xx_MODUL.pm. Das Verhalten des Moduls kann dann über den eingestellten FeatureLevel eingestellt werden, wobei ein "Downgrade" eigentlich nicht wirklich zu empfehlen ist, weil man sonst möglicherweise sicherheitsrelevante Dinge "nebenbei" ausschaltet und das dann ggf. vergißt bzw. gar nicht mitbekommt.
- Hat man ein Problem mit einem Modul, hat man also eigentlich keine Wahl als (mindestens) dieses Modul auf einen (idR.) aktuellen Stand zu bringen und sollte das auch tun.

Habe ich da etwas grundsätzlich mißverstanden, oder was sollte ein "Normaluser" denn jetzt eigentlich machen hinsichtlich updates?

Und mal allgemein: Insgesamt wird meines Erachtens das Thema Sicherheit etwas zu stiefmütterlich behandelt.

Stimme zu, möchte aber anmerken, dass das imo deutlich besser geworden ist!

Gruß, Beta-User

[Thorsten Pferdekaemper]

Habe ich da etwas grundsätzlich mißverstanden, oder was sollte ein "Normaluser" denn jetzt eigentlich machen hinsichtlich updates?

Meiner Meinung nach sollte ein "Normaluser" tatsächlich dafür sorgen, dass alles auf dem neusten Stand ist. Problematisch wird es halt dann, wenn das Problem im Produktivsystem auftritt und ansonsten alles rund läuft. Ich würde da nicht immer pauschal zum "update" raten.
Gruß,
   Thorsten

[CoolTux]

Gehört eigentlich nicht so richtig in diesen Thread, aber ich habe da mal eine Verständnisfrage dazu, da offensichtlich auch andere hier im Forum ein derartiges Verständnis von dem update haben.

Diese Sichtweise deckt sich nämlich nicht mit dem, was ich bisher zu updates innerhalb FHEM verstanden hatte:
- Wir gehen bei Problemlösungen grundsätzlich davon aus, dass der User ein aktuelles FHEM hat. Da gibt es aber eigentlich kein Nebeneinander von 5.7 und 5.8 (anders als bei Win7 und Win10, wo beide aktuell sein können), sondern nur genau ein aktuelles Modul xx_MODUL.pm. Das Verhalten des Moduls kann dann über den eingestellten FeatureLevel eingestellt werden, wobei ein "Downgrade" eigentlich nicht wirklich zu empfehlen ist, weil man sonst möglicherweise sicherheitsrelevante Dinge "nebenbei" ausschaltet und das dann ggf. vergißt bzw. gar nicht mitbekommt.
- Hat man ein Problem mit einem Modul, hat man also eigentlich keine Wahl als (mindestens) dieses Modul auf einen (idR.) aktuellen Stand zu bringen und sollte das auch tun.

Habe ich da etwas grundsätzlich mißverstanden, oder was sollte ein "Normaluser" denn jetzt eigentlich machen hinsichtlich updates?
Stimme zu, möchte aber anmerken, dass das imo deutlich besser geworden ist!

Gruß, Beta-User

Puh, das ist jetzt nicht ganz so einfach zu erklären. Es gibt nicht wirklich Versionen bei FHEM. Es gibt nur Zustände
1. Es gibt immer einen Tagesaktuellen Stand. Damit die User die auf fhem.de landen nicht denken hier passiert ja gar nichts wenn sie sehen das das letzte Packet von vor 2 Jahren ist, wird alle ~~~halbe Jahre ein Packet geschnürt und bereitgestellt. Dieses Packet bekommt eine Versionsnummer welche die des featureLevels entspricht und das Packet ist auf das featureLevel eingestellt.

2. Es werden im laufe der Entwicklung neue Funktionen in die Kernkomponenten von FHEM eingebaut. Diese werden von Testern getestet. Wenn besondere Sachen Einzug halten welches grundlegende FHEM Schnittstellen betrifft, so wird den Modulentwicklern Zeit gegeben Ihre Module entsprechend an zu passen. FHEM hat eine Umfangreiche API womit man sich sehr viel Eigenentwicklung spart und sich auf die Grundfunktion seines Modules konzentrieren kann. Wird die API geändert oder Erweitert muß der Modulentwickler aber seine Module anpassen.
Und genau das Zeitgeben erfolgt über die Freischaltung von sogenannten featureLevels.