FHEM Security

[viegener]

An so eine Loesung habe ich noch nicht gedacht.

Ich wuerde das beim telnet/FHEMWEB global Instanzen anzeigen, und bei einem "ok" fuer alle Instanzen das Passwort gleich setzen. Bei "cancel" wird fuer alle basicAuth/passwort auf none gesetzt, und damit erfolgt keine Warnung und auch keine Passwortabfrage mehr. Bei FHEMWEB waere die Loesung relativ einfach/intuitiv, bei telnet weniger.

Was sagen die anderen dazu? Ich bin nicht wirklich dafuer: Ich sperre lieber meine Haustuer ab (WLAN/Firewall) und nicht alle Zimmer (FHEM) einzeln. Beide abzuschliessen finde ich doof und ueberfluessig, und bin unsicher, ob ich das nun jedem Anfaenger empfehlen soll.

Ich stimme Dir durchaus zu, und baiscAuth mit http setzt ja sowieso die Sicherheit beim Webzugriff nicht sehr hoch.

Wenn man hier etwas machen möchte fände ich es besser ein etwas weitgehenderes Konzept mit einer Art Einrichtungsdialog einzuführen, dort könnten dann
- User/passwort,
- Welche Ports wirklich gebraucht werden (TABLET, PHONE etc)
- später vielleicht auch https/SSL-Cert

aber eben auch nicht-Sicherheitsrelevante Einstellungen gemacht werden, wie z.B.
- Style des UIs
- Einstiegsseite
- ...

Wenn das generisch ist, könnten auch weitere Modulautoren dort etwaige Einstellungen hinterlegen (z.B. Weitere UIs, DBlog-Konfig?, etc). Bei manchen Modulen ist ja eine mehrstufige EInrichtung notwendig, die nicht in einem einzelnen define endet.

Das fände ich gut für die Sicherheit und gut für den Einstieg...

Wäre auch gerne bereit daran mitzuarbeiten

[herrmannj]

Hi,

bin auch dagegen.

Die "security" Fragen tauchen alle xx Monate mal auf. Gebetsmühlenartig fragt Rudi dann: "gebt mir Beispiele und ich fixe" - und dann kommt keins.

Oft kommt die Frage "Security" von Neulingen (echt nicht böse gemeint) und dort mMn unter falschen Annahmen. Siehe hier. Arbitrary File Disclosure und Code Execution gehören ja durchaus zum pentest Programm für Webdienste.

Nur: fhem ist eben kein webdienst sondern eine Programmierplattform. fhemweb ist ein interface mit dem RECHT SYSTEMBEFEHLE auszuführen.

Da sollte Security mMn über AWARENESS adressiert werden und nicht über (trügerischen) Passwortzwang.

Dafür einen Guide zu erstellen beführworte ich, gute Ansätze (user Management) haben wir ja auch hier im thread.
Darüber hinaus könnte man eine (wie auch immer geartete) Meldemöglichkeit für Security Issues einführen. Die sollte (mMn) so aufgebaut sein:

"xxx sollte unter den gegebenen Umständen yyy eigentlich verboten sein. Wenn man zzz macht ist es aber doch möglich". 

Das würde user die sich mit dem Thema beschäftigen "zwingen" sich mit dem Security Modell von fhem zu beschäftigen. In dem Zusammenhang Danke an den TE - ist ja gut das so etwas stattfindet. Man muss das halt kanalisieren.

vg
joerg

[Martin Thomas Schrott]

Hi zusammen,

ich denke das setzen von Passwörtern sollte jedem selbst vorbehalten sein. Warum sollte jemand einen Passwortschutz aktiviert haben wollen, wenn sein FHEM nur aus dem eigenen WLAN erreichbar ist und dieses nur von ihm selbst genutzt wird? Und ich bin sicher, dies ist die häufigste und auch die standard Konfiguration der Benutzer. Wer öffnet denn unbeabsichtigt und one es zu wissen einen Port zu dem Gerät wo FHEM installiert ist?
Die Sicherheit für solche Anwendungen muss ohnehin davor erfolgen und nicht in der Anwendung selbst.
Und wenn es striktere Möglichkeiten geben soll, dann bitte nur auf eigenen Wunsch und eigene Aktivierung hin.

Just my 2C.
LG
Martin

[Dr. Boris Neubert]

Hallo,

was ist denn der typische Anwendungsfall?

Gemäß Statistik sind ca. 98% der Anwender mit FHEM auf Linux und damit zu > 80% auf kleinen Systemen (ARM, MIPS, also wohl Raspberry PI, BBB und Konsorten bzw. Fritzbox).

Gehen wir mal davon aus, dass Ausgangspunkt eine Distribution ist, so dürfte das System sicher (aber nicht hart sicher) sein, bevor der Benutzer anfängt, FHEM zu installieren.

Über Gerätekonfigurationen entstehen erste Schwachstellen, beispielsweise über ECMD, wo ich Rückmeldungen von Geräten in beliebigen Perl-Kode einfüttern kann.

Die typischen Einfallstore wären dann doch das Telnet-Interface und das UI, meist FHEMWEB. Telnet kann man ohne Komfortverlust durch Passwort abdichten.

Das UI lässt sich m.E. ohne Komfortverlust nicht mit Kennwort sichern - es soll ja ggf. die ganze Familie rasch bedienen können, ohne erst ein Passwort zu tippen. Dann braucht man aber schon ein Rechtekonzept (damit Tommi seine Heizung verstellen kann aber die von Annika nicht und nur die Administratorin des Hauses konfigurieren und beliebige Systembefehle aufrufen kann).

Werimmer Zugriff auf FHEM hat, hat alle Rechte und Möglichkeiten, die der Benutzer hat, unter dem FHEM läuft.

Fazit für mich: so wie FHEM derzeit aufgebaut ist, darf ich nur Nutzern Zugriff geben, denen ich soweit vertraue, dass ich ihnen auch einen Shell-Zugriff geben würde. Ich stimme damit Joerg zu, dass Awareness die richtige Antwort auf die Frage nach der Sicherheit ist. Also kein Hardening Guide sondern ein Security Awareness Guide in der commandref, der die typischen Anwendungsfälle beschreibt und Tipps gibt, wie man Fallen vermeidet (Zugriff übers Web, dann ...; setze die Attribute ... und ..., wenn Du ...; ...).

Viele Grüße
Boris

[r0x0r]

Die "security" Fragen tauchen alle xx Monate mal auf. Gebetsmühlenartig fragt Rudi dann: "gebt mir Beispiele und ich fixe" - und dann kommt keins.

Ich versteh nicht was an nem XSS PoC wegzudiskutieren ist. Schon gar nicht mit "dann kommt keins".

Code Exec ist ein feature von FHEM. Akzeptier ich. Muss so sein. Wenn ich das allerdings via XSS und XSRF triggern kann ist das ne klare Verwundbarkeit und die Zuständigkeit das abzufangen liegt bei der Applikation und nicht beim User, denn der kann daran nix ändern.

Wie viele Fritzbox User habt ihr? Installieren die das normal auf ihrer Core Fritzbox oder schaffen die sich ein zusätzliches Gerät dafür an? Wenn die das auf der Core Fritzbox in ihrem Netzwerk installieren habt ihr für die User ein Riesenproblem, denn dann kann man in vielen Fällen direkt die interne IP raten und hätte damit einen praktikablen Angriff via XSRF und XSS auf die meisten Firtzbox User.

Bei allen anderen müsste man sich drauf verlassen, dass die den Link selbst zu ende bauen und einfach ausprobieren. Das schränkt das Problem etwas ein.

BTW: Wer von euch hat meine PoCs ausprobiert ohne zu wissen was die tun?

In meinen Augen gehören Best Practices für die Programmierung im Bereich Security auch in ein System wenn das "ja doch nur im internen Netzwerk steht". Ich finde da gibt es keine Diskussion. Erst recht wenn man built-in code exec anbietet ...

Gruß,

Flo!

[Loredo]

lass gut sein, Flo. Bringt nix die Diskussion...


Gruß
Julian

[krikan]

lass gut sein, Flo. Bringt nix die Diskussion...

Warum nicht? Gibt es dafür Gründe?
Als User würde ich gerne mehr wissen. Mir leuchtet bspw. nicht ein, wo ich mich mit FHEM in Gefahr begebe, wenn ich es auf einer Fritzbox betreiben würde und FHEM/Fritzbox nicht von Außen erreichbar ist.
Gruß, Christian

[rudolfkoenig]

@r0x0r: Ich habe den Eindruck, dass du unsere Antworten nicht liest, und ich frage mich, ob es Sinn hat dir zu antworten. Ich versuche es nochmal:

FritzBox ist zunehmend irrelevant. Es gibt ein paar FHEM-Benutzer, die noch nicht umgestiegen sind, Neulinge schaffen eine Installation nur auf veralteten Systemen, oder wenn sie viel Zeit investieren.
XSRF / CSRF kann man mit csrfToken verhindern
XSS funktioniert nur, wenn jemand mein Passwort hat.
Ich weiss nicht, wer deine "PoCs" ausprobiert hat, die waren alle der Klasse: "tippe im shell cat /etc/passwd ein, und staune".

Ich finde da gibt es keine Diskussion.

Wenn man nicht zuhoeren will, dann wird es wohl dabei bleiben.


@Christian: das geht mit CSRF, indem man z.Bsp. jemand im fhemwiki folgendes einbaut:
<img src="fritz.box:8083/fhem?cmd=set .* off">
Wenn du im Browser dich bei FHEM angemeldet hast, und die fhemwiki Seite anschaust, dann wird das basicAuth token uebertragen. Schuetzen kann man sich mit dem csrfToken Attribut, allerdings wurde das noch nicht breit getestet, und ist deswegen nicht per default aktiv.

[herrmannj]

Ich versteh nicht was an nem XSS PoC wegzudiskutieren ist. Schon gar nicht mit "dann kommt keins".

Entschuldigung, das war nicht meine Absicht ignorant zu klingen.

Der Punkt ist das die XSS nur funktioniert wenn entweder kein Passwort gesetzt ist (user fehler!) oder derjenige der den XSS loslässt verfügt über user/pwd. Wenn letzteres der Fall ist macht der XSS keinen Sinn weil man über fhemweb ohnehin "andere Sachen" anstellen kann.

Eine "Lücke" ist (mMn) daher relevant wenn man damit ein System kompromittieren kann das per (unbekannter) user/pwd Kombination gesichert ist. So ist bitte die Frage nach den POC zu verstehen. (Die Beispiele können das mMn nicht, korrekt?)

fhemweb bietet im übrigen weitere Möglichkeiten zur Absicherung an. Der Zugang kann auf bestimmte IP Adressen begrenzt werden und pro fhemweb Instanz können Kommandos erlaubt (unterbunden) werden.

Btw:
ich finde die Security Fragen generell richtig, gut und notwendig. Das bringt nur nix wenn ich (vermeintliche) vulnerability auf einem System melde wenn ich da sowieso mit entsprechenden Rechten eingeloggt bin.

btw2
Bei fronthem gehe ich den Weg das ein device (a) autorisiert sein muss (derzeitig halbherzig ip), das (b) Kommandos pro device auf einer whitelist stehen müssen und das (c) eingehende Befehle von einem Application Proxy interpretiert und neu formuliert werden (converter).

Zu den häufigsten Fragen gehört ob man nicht a-c einfach weglassen kann

vg
joerg

[tupol]

....Interesant wäre auch ein hardening guide für FHEM, das macht es den Leuten vielleicht einfacher. Ich bin einfach der Meinung, dass aufgrund der hohen Angriffsfläche den Leuten klarer mit auf den Weg gegeben werden sollte, was das heisst.

Hallo r0x0r,

finde ich einen super Vorschlag. Wärest Du bereit den hardening guide zu erstellen? Man könnte das direkt in die Wiki aufnehmen.

Ich habe auf Grund der Warnmeldungen wahrgenommen, dass sich in letzter Zeit diesbzgl. bei FHEM viel getan hat. Leider habe ich aber praktisch keinen Überblick, was ich alles tun muss und warum.
Bisher bin ich mit dieser Laxheit gut gefahren, weil FHEM nur ein paar tausend User hat und nicht wirklich wirtschaftliche Vorteile für Angreifer bietet. Aber besser wäre es schon sich zu schützen.

Gruß
tupol

[Loredo]

Warum nicht? Gibt es dafür Gründe?

Weil ich auch schon etliche Diskussionen darüber geführt habe (im Rahmen des Hoanoho Frontend Image Threads) und mir deutlich gemacht wurde, dass man den Grundsatz nicht möchte, dass ein zunächst möglichst gut abgesichertes System "convenient" bereitgestellt wird. Man möchte lieber, dass jeder sich selbst über Sicherheit gedanken machen muss und erwartet eben auch, dass jeder das kann. Wer das nicht kann, hat eben pech gehabt - so die Devise. Man möchte nicht einfach zu handhaben und trotzdem sicher sein. Man möchte gerne besonders bleiben und vornehmlich nur die Leute anlocken, die tiefgreifende technische Kenntnisse haben oder sich erwerben möchten.



Ich denke @r0x0r möchte IMHO darauf hinaus, dass die Sicherheit innerhalb von FHEM nicht granularer z.B. über ein Rollen-Reche-Konzept abgesichert werden kann.


Es ist sicher richtig, dass man vorher auch schon alles mögliche tun soll und muss, um den Zugriff auf FHEM ansich abzusichern. Ein nur lokal erreichbares FHEM mag da attraktiv klingen, verschließt sich aber der Realität, dass es keine wirklichen Insel-Netzwerke (mehr) gibt. Nur weil ich kein Port-Forwarding eingerichtet habe bedeutet das nicht, dass nicht jemand über ein anderes, verwundbares Gerät in meinem Netzwerk sich dann trotzdem frei im Netz bewegen kann. Dafür muss man keine Ports weiterleiten.
Das mag alles höchst unwahrscheinlich klingen, dennoch bleibt ein Angriffspunkt von innen heraus derjenige, der nicht richtig angegangen wird.


CSRF schützt halt nur die FHEM Standard-GUI und ich bin nicht sicher, ob man bei Nutzung anderer GUIs und Apps nicht auf Probleme stößt, wenn man dies aktiviert hat.


Nun kann ich einzelne FHEMWEB Instanzen in ihren Kommandos einschränken. Das hilft allerdings nur sehr bedingt, denn in Modulen werden set und get Kommandos meistens nicht darin unterschieden, ob sie für einen Anwender oder den Systemverwalter gedacht sind. Sie in der Oberfläche auszublenden ist halt nur Kosmetik. In einigen meiner Modulen gibt es deshalb den Support für "set-user" in allowedCommands, was aber ansonsten leider keinen Anklang fand. Ich würde grundsätzlich gerne alle meine User vor Fehlbedienung schützen und auch bedenken wollen, dass z.B. ein Kind im Haushalt sich als Probe-Hacker probieren will nur um den Vater mal zu ärgern (so sind Pubertierende nunmal).
Ich könnte als Vater dann nur den Zugriff zur Haussteuerung komplett abschalten, was in den meisten Fällen dann auch nicht geht, wenn man Haussteuerung denn ernst nehmen will.


Eine moderne REST API mit entsprechenden AuthTokens etc. für die Anbindung anderer GUIs wäre sicherlich wünschenswert. Auch wäre ein Ersatz für BasicAuth durch session basierte User Authentifizierungsmethoden wünschenswert. Man kann derzeit nicht nachvollziehen wer wann was im System eingestellt oder geschaltet hat. Solch eine Audit Trail Funktion fehlt mir da auch, optimalerweise revisionssicher.


Ja, FHEM ist offen, kann man alles selbst reinhacken. Der Punkt ist aber die Architektur sollte bereits darauf ausgelegt sein, von Grund auf. Dafür bedarf es aber auch eines grundsätzlichen Bekenntnis zur Sicherheit seitens der Core Entwickler. Solch umfangreiche Patches Dritter würden ohnehin (verständlicherweise) niemals übernommen werden.


FHEM mag gewachsen sein über die Jahrzehnte. Eine FHEM2 Basisarchitektur, die alte Zöpfe radikal abschneidet und dem 21. Jahrhundert angemessen ist, wäre ein toller Schritt. Allein zu dieser Erkenntnis (ohne die Diskussion "wer macht das", "viel Arbeit", etc.) reicht es wohl leider nicht. Kann ich auch verstehen, für sowas gewinnt man keinen Blumentopf, weil augenscheinlich "geht doch alles". Die Möglichkeiten bei der Automation mit FHEM sind grandios, aber als Architekt habe ich mich mit FHEM nur "arrangiert".

[rudolfkoenig]

Man möchte gerne besonders bleiben und vornehmlich nur die Leute anlocken, die tiefgreifende technische Kenntnisse haben oder sich erwerben möchten.

Da spricht aber viel Weltschmerz daraus.  FHEM ist mAn nicht das richtige System fuer den Gelegenheitsanwender, sondern fuer den Bastler, der bereit ist Zeit zu investieren. Erinnert mich an Heimwerkermaerkte, ich glaube nicht dass die "besonders" sind, werden trotzdem gebraucht, und sind sicher nicht fuer alle was.

Ein FHEM2 ist (auch wenn ich es mir oefters wuensche) illusorisch, bzw. das muss dann nicht mehr FHEM genannt werden.

Was nicht illusorisch ist, FHEM schrittweise zu erweitern, das hat allowedComands ja auch geschafft. Wenn man die bisherige Pruefung auf $cl->{".allowed"} in ein "AUTH" Modul auslagert, dann muss fhem.pl auch nicht grundlegend umgestaltet werden, und man koennte in diesem "AUTH" ohne Probleme Benutzer/Rechte/Auditing einbauen. Whitelisting/blacklisting von Parametern ist auch moeglich, ohne jedes Modul dafuer umzukrempeln. Es muss nicht von Anfang an perfekt sein, man kann damit aber Erfahrung sammeln.

Aber offensichtlich ist dieses Problem nur fuer wenige relevant, da es bisher nicht in Angriff genommen wurde.

[Dr. Boris Neubert]

Hallo,

ich versuche mal, der Diskussion ein Ziel zu geben. Ich mag keine Themen, die nur Quasselbuden sind.

Loredo hat richtig bemerkt, dass das System sicher und bequem zugleich sein muss. Joergs fronthem geht den Weg des Security by Design. Bei FHEMWEB sind wir auf dem Stand, dass man es soweit sichern kann, dass nur autorisierte Benutzer darauf zugreifen können (Basic Auth, Verhinderung von XSS und CSRF) - die autorisierten Benutzer dürfen dann alles tun, was der User, unter dem FHEM läuft, auf der Maschine tun darf.

Habe ich das richtig verstanden?

Wovon können wir derzeit überhaupt realistisch ausgehen?
- Derjenige der FHEM konfiguriert (FHEM-Administrator), muss wissen, was er tut. Er hat die Kontrolle und soviel Macht, wie der User, unter dem FHEM läuft. Maßnahmen: 1) Security Awareness Guide. 2) Zugriff über telnet wird nur dem FHEM-Administrator erlaubt.
- Derjenige, der FHEM bedient (FHEM-Bediener): Hier ist es durchaus realistisch, nach und nach den Bediener soweit einzuzäunen, dass er nur das bedienen kann, was er bedienen darf. Maßnahme: Vorschlag von Rudi für Auth.pm.

Viele Grüße
Boris

[JoWiemann]

Hallo,

vielen Dank für das Thema und die bis jetzt geführte Diskussion. Auch ich würde es begrüßen, wenn wir für Fhem ISMS-Regeln (Information Security Management System) aufstellen und einführen würden. Sicherheit in der Heimautomation sollte nicht eben nicht mal so nebenbei erfolgen, sondern schon Ergebnis und Ziel gerichtet. Hierbei ist aber wichtig die Ziele zu definieren und deren Einhaltung einzufordern. Aus der Diskussion habe ich entnommen, dass es mehrere Ziele zu geben scheint:

1. Absichern des Fhem-Systems gegen Komprometierungsversuche von außen.
Dies scheint mir das vorrangige Ziel zu sein, da ein Einbruch in mein Heimnetzwerk mit dem Ziel dieses für kriminelle Zwecke zu nutzen für mich unter Betreiberhaftung und damit in meine Verantwortung fällt.

2. Absichern des Fhem-Systems gegen Fehlbedienungen oder Blödsinn von Bewohnern.
Würde ich mit geringerer Priorität versehen. Viel kann hier schon über die vorhandenen Frontends gemacht werden, bzw. fällt vielleicht unter "Erziehung".

3. Absichern von Fhem-Devices.
Leider benutzen die meisten Devices offene Protokolle, sei es im Funkbereich (433 / 868 MHz) oder im IP-Bereich, wo WLAN-Devices wenig bis gar nicht abgesichert sind. Die Frage ist hier, was steuere ich über diese Devices und welches ist der maximale Schaden der angerichtet werden kann, wenn jemand vor meinem Haus steht. Hier könnte eine Lösung sein, dass wenn Fhem Schaltbefehle erkennt, die es selber nicht ausgelöst hat, Fhem dann eine Warnung ausgibt und den Ursprungszustand wieder herstellt. Meine Alarmanlage läuft jedenfalls nicht über Fhem.

Grüße Jörg

[Dr. Boris Neubert]

1. Absichern des Fhem-Systems gegen Komprometierungsversuche von außen.
Dies scheint mir das vorrangige Ziel zu sein, da ein Einbruch in mein Heimnetzwerk mit dem Ziel dieses für kriminelle Zwecke zu nutzen für mich unter Betreiberhaftung und damit in meine Verantwortung fällt.

Welche Maßnahmen ergeben sich daraus? Reicht es, den vorgeschlagenen Security Awareness Guide (welche Angriffsvektoren gibt es und was muss ich tun, um diese zu unterbinden?) in die commandref aufzunehmen?

Gehört habe ich dazu schon: "Will ich!". Es hat sich noch keiner gemeldet, der "Mach ich!" gerufen hat.

2. Absichern des Fhem-Systems gegen Fehlbedienungen oder Blödsinn von Bewohnern.
Würde ich mit geringerer Priorität versehen. Viel kann hier schon über die vorhandenen Frontends gemacht werden, bzw. fällt vielleicht unter "Erziehung".

Der OP hat mMn die Sicherheitsrisiken aus der Position des FHEM-Bedieners geschildert.

Die Antwort darauf war: ja, der Bediener darf alles tun, was der User darf, unter dem FHEM auf der Maschine läuft. Dem legitimen FHEM-Bediener Befehle unterzuschieben, z.B. durch CSRF (Klicke einen Link im Forum und alle Lichter gehen zuhause aus) lässt sich verhindern - bisher hat noch keiner das Gegenteil bewiesen.

Alles darüber hinaus wäre eine Erweiterung von FHEM(WEB), nämlich die FHEM-Bediener einzuzäunen. Es gibt dazu Vorschläge (Rudis Auth.pm) aber noch keinen, der gerufen hat: "Will ich!" Oder gar: "Mach ich!"

3. Absichern von Fhem-Devices.
Leider benutzen die meisten Devices offene Protokolle, sei es im Funkbereich (433 / 868 MHz) oder im IP-Bereich, wo WLAN-Devices wenig bis gar nicht abgesichert sind. Die Frage ist hier, was steuere ich über diese Devices und welches ist der maximale Schaden der angerichtet werden kann, wenn jemand vor meinem Haus steht. Hier könnte eine Lösung sein, dass wenn Fhem Schaltbefehle erkennt, die es selber nicht ausgelöst hat, Fhem dann eine Warnung ausgibt und den Ursprungszustand wieder herstellt. Meine Alarmanlage läuft jedenfalls nicht über Fhem.

M.E. kein Thema für FHEM, auch wenn es im Kontext von FHEM relevant ist.

Viele Grüße
Boris