FHEM Security

[viegener]

(Ich vertrete generell diesen Standpunkt:) wem Du keinen ssh Zugriff geben würdest dem darfst Du auch keinen fhemweb Zugriff geben. Für den Rest gelten und greifen alle üblichen Linux Absicherungsmaßnahmen wie user Rechte beschränken etc.

Ich sehe das ähnlich! Bei vielen von uns ist der FHEM-Benutzer in sudoers enthalten und damit fhemweb quasi root äquivalent.

Es ist für ein Bastelsystem (und das ist fhem wohl) ist es eine Frage ob der Grundsatz "secure by default" oder "Wissen was man tut" besser ist. Es ist sicher sinnvoll weiter abzusichern und konkrete Patches sind auch häufig willkommen, aber ich denke wir können nur sehr begrenzt für sichere Systeme sorgen, denn ich will nicht dass es Anwender gibt, die dann sagen: "Ich kann das System ja über Portforwarding im Internet verfügbar machen, FHEM ist ja sicher"

[r0x0r]

"Ich kann das System ja über Portforwarding im Internet verfügbar machen, FHEM ist ja sicher"

Davon gibt es halt schon n paar Dutzend.

Es war auch nur ein Hinweis meinerseits, gehen sie weiter, hier gibt es nichts zu sehen.

Gruß,

Flo!

[Doggiebert]

* Secure by Default ist ein erstrebenswerter Zustand, den ich mir für FHEM auch wünschen würde. BASIC auth würde ich mandatory machen. 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.

Security ist kein Selbstzweck, ein zentraler Punkt ist dabei immer wer der Angreifer ist, und was der potentielle Schaden ist. Das wird oft übersehen. Mein Fhem ist zB nicht von aussen zugreifbar, und wenn dann könnte man meinen Fernseher einschalten und bissl Licht und Jalousie bedienen...wer das schafft dem vergönne ich die Freude.
Die Idee mit dem hardening guide ist nicht verkehrt, schreib doch einen, sobald dein setup steht...hier darf jeder mitmachen!

[rudolfkoenig]

Wg. basic auth: Wenn man FHEM installiert, und keine Passwoerter vergibt, dann wird das ueberall (telnet/FHEMWEB) bemaengelt. Wenn man das ignoriert, dann kann ich auch nicht mehr tun.

Was mAn bei einem "default" User z.Zt noch Probleme verursachen kann ist CSRF, weil csrfToken nicht per default aktiviert ist. Sorry, vorhin meinte ich csrfToken und nicht CORS.

Wenn irgendjemand meine FHEM Instanz kontrolliert, dann ist es mir egal, dass er /etc/passwd auslesen kann, mit FHEM kann man deutlich mehr Schaden ausrichten.

Zurueck zu deinem PoCs: wenn du mir zeigst, dass du auf meinem FHEM irgendetwas ausrichten kannst, dann werde ich alles unternehmen, um das zu verhindern. Es reicht mir auch eine theoretische Beschreibung des Vorgangs. Und nein, du kriegst mein FHEM Passwort nicht.

[viegener]

Davon gibt es halt schon n paar Dutzend.

Ja und das halte ich für ein Problem, das wir durch trügerische Sicherheit eher verschärfen. Wie gesagt konkrete Patches/Anmerkungen sind sicher hilfreich, denn auch in meinem Modul TelegramBot öffne ich einen Aussenzugang der leicht problematisch werden kann, wenn man nicht aufpasst und selbst dann sind an manchen Ecken nur Annahmen verfügbar (und ein Protection Profile für Common Criteria werde ich nicht anwenden)

Es war auch nur ein Hinweis meinerseits, gehen sie weiter, hier gibt es nichts zu sehen.

Die Anmerkung verstehe ich nicht.

[vbs]

Ich sehe das ähnlich! Bei vielen von uns ist der FHEM-Benutzer in sudoers enthalten und damit fhemweb quasi root äquivalent.

Ehrliche Neugier: Wofür braucht ihr das?

[viegener]

Ehrliche Neugier: Wofür braucht ihr das?

Ich verwende das aus 2 Gründen:
- Ich arbeite per ssh auch häufig unter dem fhem-Benutzer, dann vermeide ich Rechteprobleme im fhem-Verzeichnis
- Manche Operationen (z.B. direkter GPIO-Zugriff) erfordert root-Rechte, also entweder ein setuid-Skript oder sudo

[Dr. Boris Neubert]

Hallo viegener,

ich arbeite an fhem grundsätzlich als User fhem. Dazu gehören alle Dateien in /opt/fhem diesem User. Wie funktioniert denn sonst bei Dir update?

Zugriffe auf Devices löse ich dadurch, dass der User in derselben Gruppe wie das Device ist und das Device z.B 660-Rechte hat (über udev-Regeln).

fhem ist bei mir nicht in sudoers.

Viele Grüße
Boris

[viegener]

ich arbeite an fhem grundsätzlich als User fhem. Dazu gehören alle Dateien in /opt/fhem diesem User. Wie funktioniert denn sonst bei Dir update?

Ja genau, das meinte ich mit der Vermeidung von Rechteproblemen und dem Arbeiten unter fhem. Ich arbeite als fhem und dann ist es halt relativ einfach "sudo service fhem ..." auszuführen wenn nötig. Man kann das auch als Bequemlichkeit auslegen 

[vbs]

Ich denke, dass man sowohl das eine als auch das andere ohne root bewerkstelligen kann. Spätestens wenn FHEM potentiell als root läuft, dann bekomme ich auch langsam Angst.

[viegener]

Ich denke, dass man sowohl das eine als auch das andere ohne root bewerkstelligen kann. Spätestens wenn FHEM potentiell als root läuft, dann bekomme ich auch langsam Angst.

Das lässt sich sicher nicht verallgemeinern, aber aus meiner Sicht ist ein root Zugang auf meinem Homeautomation-System nicht wirklich kritisch.
Ich habe keine Potforwarding oder VPN-Lösung von aussen eingerichtet, mein WLAN ist abgesichert und aussen am Haus bringe ich keine Netzwerkstecker an. Meine Bewertung basiert darauf, dass ein unbefugter Zugang in mein Heim(-netz) vermutlich grössere Risiken als das Verwenden des root Zugangs auf meinem Raspberry hat.

Wie gesagt Fokus ist aus meiner Sicht die Absicherung des Netzes gegen Zugriff von aussen und nicht die Abschottung der Benutzer in meiner Familie-Heimnetz untereinander. Auf dem Raspberry liegen nur Daten die jeder Nutzer meines Heimnetzes auch sehen dürfte.

[ext23]

Moin,

sehr interessantes Thema hier Gibt ja wie man sieht verschiedene Meinungen, ist auch OK so. Ich kann nur Typen nicht leiden die WhatsApp etc. benutzen und Abends im Kreise der Familie schimpfen, dass die NSA uns belauscht, das ist schon etwas billig und grenzt an Dummheit. Für eins sollte man sich dann schon entscheiden und seine Kurs beibehalten.

Aber davon mal abgesehen, ich finde:

- Ein Hardening Guide wäre eine tolle Sache, und der würde vermutlich nicht zu knapp ausfallen wenn man alles bedenkt. Dazu ist er für Laien auch ein Anreiz mal über Sicherheit oder Neudeutsch Security nachzudenken, wenn auch nur kurz Andererseits, wer FHEM benutzt und nicht irgend ein System von der Stange sollte das vermutlich gar nicht brauchen, allerdings kommen doch Zweifel auf wenn ich einige Sachen hier lese.
- Security sollte IMMER vor Benutzerfreundlichkeit stehen, da hilft auch kein "Hinweis" das man ein Passwort vergeben sollte oder was auch immer.
- Wer FHEM in ein anderes Netzwerk Segment packt, sei es mit 802.1Q oder physikalisch wird wenig Nöte haben, natürlich auch getrennt vom Internet.
- Falls man von außen an sein System muss, kommt man um ein anständiges VPN mit IPSec nicht rum.
- Mit ESXi, also Virtualisierungen kann man auch einiges machen, für die die FHEM auf einem Server laufen haben wo noch etliche andere Dienste laufen (Webserver, Dateifreigaben etc.). Hier kommen aber dafür andere Probleme hinzu wie memory sharing etc. aber lassen wir mal die Kirche im Dorf ja.
- Paranoiden können auch gerne mal ein Nessus und Codenomicon Scan durchführen, aber die Ergebnisse hier natürlich nicht posten...
- Viele Sicherheitseinstellungen sind auch dem OS (Linux, Windows) zuzuschreiben und müssen dort auch angepasst werden, da hat FHEM eher wenig Aktien dran.

/Daniel

[rudolfkoenig]

Security sollte IMMER vor Benutzerfreundlichkeit stehen, da hilft auch kein "Hinweis" das man ein Passwort vergeben sollte oder was auch immer.

Bitte keine Allgemeinplaetze, sondern konkrete Vorschlaege.

[reibuehl]

Bitte keine Allgemeinplaetze, sondern konkrete Vorschlaege.

Also ich fand das eine recht konkrete Antwort auf Dein "Wenn man FHEM installiert, und keine Passwoerter vergibt, dann wird das ueberall (telnet/FHEMWEB) bemaengelt. Wenn man das ignoriert, dann kann ich auch nicht mehr tun."

Aber wenn es konkreter sein soll: Anstatt das fehlen eines Passworts zu bemängeln, sollte FHEM, falls kein Password gesetzt ist, ein zufälliges Passwort generieren und setzen und dem Benutzer beim ersten Zugriff anzeigen. Der Benutzer bestätigt mit OK, dass er dass Passwort zur Kenntnis genommen hat und dann ist das System schon mal mit einem Passwort abgesichert.

[rudolfkoenig]

ein zufälliges Passwort generieren und setzen und dem Benutzer beim ersten Zugriff anzeigen.

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.