Eingeschränkter Nutzer: Zwei verschiedene FHEM-Webs oder?

Begonnen von curt, 29 Juli 2020, 05:31:25

Vorheriges Thema - Nächstes Thema

curt

Guten Morgen,

ich brauche mal einen kurzen Schubs: Ich weiß, dass das geht. Ich weiß nur nicht, wo ich nachlesen muss:

Ich möchte auf einem weiteren Port eine weitere Instanz von FHEMWEB. Das kriege ich vermutlich noch ganz gut hin.

Die weitere Instanz muss "kindersicher" sein: Mein Nachbar soll über sein Handy die Gartenpumpe schalten können. Das bedeutet also, dass ich in der zweiten Instanz irgendwie (wie?) wirklich alles bis auf den Schalter für die Gartenpumpe wegzaubere.

Ich weiß, dass es geht. Mir fehlen wohl die richtigen Suchbegriffe - schubst mich mal bitte in die richtige Richtung!

P.S: Subject angepasst
RPI 4 - Jeelink HomeMatic Z-Wave

Beta-User

Die passenden Attribute sind auf FHEMWEB und allowed zu verteilen (hidden- bzw- forbiddenroom(Regexp), allowedCommands).

Wäre es nicht einfacher, ihm einen Telegrambot einzurichten?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Falls es FHEMWEB sein soll: ich wuerde mit allowedDevices anfangen, das Uebriggebliebene mit forbiddenroom detail/input/save/etc verstecken, und um von URL-Angriffen sicher zu sein, die Befehle mit allowedCommands eingrenzen. Falls Du diesen Weg waehlst, waere es nett das Ergebnis hier anzuhaengen, da die Frage immer wieder kommt.

curt

Zitat von: Beta-User am 29 Juli 2020, 07:56:40
Die passenden Attribute sind auf FHEMWEB und allowed zu verteilen (hidden- bzw- forbiddenroom(Regexp), allowedCommands).

Ahh, ok. Danke für den Schubs.
Ich bastele mal los und melde mich notfalls.

Zitat von: Beta-User am 29 Juli 2020, 07:56:40Wäre es nicht einfacher, ihm einen Telegrambot einzurichten?

Nein.
Es geht tatsächlich darum, die Tomaten zu gießen. Ansich funktioniert das auch via FHEM: Sowohl die Pumpe als auch ein Magnetventil in Richtung Gardena-Tropfsystem funktionieren. Es würde klemmen, wenn ein Gardena-Schlauch wegreißt und die komplette Nachbarschaft geflutet wird. Oder (nicht selten) eine Düse des Tropfsystems verstopft.

Ich kann und will meine Nachbarin nicht überfordern:
Sie soll halt notfalls via Handy das Hauswasserwerk (real die in Garten stehende Motorpumpe) ein- und ausschalten können. Ein IT-Lehrgang würde nicht funktionieren.

Wie es immer so ist: Der Urlaub kommt derart unverhofft ...
RPI 4 - Jeelink HomeMatic Z-Wave

curt

Zitat von: rudolfkoenig am 29 Juli 2020, 08:16:51
Falls es FHEMWEB sein soll: ich wuerde mit

Ok, verstanden.

Zitat von: rudolfkoenig am 29 Juli 2020, 08:16:51
Falls Du diesen Weg waehlst,

War jedenfalls mein erster Gedanke.

Zitat von: rudolfkoenig am 29 Juli 2020, 08:16:51
waere es nett das Ergebnis hier anzuhaengen, da die Frage immer wieder kommt.

Hach ... der Urlaub kommt jedes Jahr so unverhofft. Es eilt, es drängt, Sachen sind auch zu packen ...

Ja. Falls ich das sauber hinkriege, zeige ich es. Klar.
RPI 4 - Jeelink HomeMatic Z-Wave

Wzut

Zitat von: curt am 29 Juli 2020, 08:22:07
Ich kann und will meine Nachbarin nicht überfordern:
Sie soll halt notfalls via Handy das Hauswasserwerk (real die in Garten stehende Motorpumpe) ein- und ausschalten können. Ein IT-Lehrgang würde nicht funktionieren.
Klar, aber IMHO ist es für Sie wesentlich einfacher dem Bot die Nachricht on oder off zu schicken als in FHEMWEB irgend eine Glühbirne anzuklicken.
Wenn sie nie SMS oder Whatsapp Romane schreibt dann wird natürlich für zwei bzw. drei Buchstaben einzutippen ein Lehrgang fällig :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wernieman

#6
Hatte hier für so etwas einfach mal eine Webside aufgesetzt, die FHEM dann per php-Telnet die Befehle sendete (bzw. den Status abholte).

Da ich einen Webserver sowieso laufen hatte und auch von alten Projekten Codeschnipsel existierten, war das für mich damals das Sauberste ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

rudolfkoenig

ZitatJa. Falls ich das sauber hinkriege, zeige ich es. Klar.
Keiner wird sich aufregen, wenn sowas erst nach dem Urlaub kommen sollte.

curt

Zitat von: Wzut am 29 Juli 2020, 08:32:31
Klar, aber IMHO ist es für Sie wesentlich einfacher dem Bot die Nachricht on oder off zu schicken als

Ähmmm - nöh.

Ich weiß nicht ansatzweise, ob es für WhatsApp ein Modul gibt. Und da ich aus verschiedensten Gründen nie (wirklich nie) WahtsApp hatte, hält sich meine Begeisterung in ganz engen Grenzen.

Telegram scheidet aus zig Gründen aus:
* Ich müsste die Nachbarin überreden, eine App zu installieren und zu lernen. Wird nicht gehen.
* Ich selbst schaffe es nicht, meinem eigenen Bot einen Befehl zu schicken, den der auch ausführt (in dem Thread muss ich mal antworten).
* Zwei Bots gleichzeitig - orrr nöh. Ich will nicht die Welt umschubsen. Ich will wie jedes Jahr in Deutschland Urlaub machen.

Vielleicht bin ich wirklich naiv:
Mein Denkansatz war "back to the roots" - eine neue Instanz FHEMWEB auf einem anderen Port aufsetzen. Dann alle (bis auf den gewünschten) "Raum" wegschalten. Und da halt der optisch schöne Schalter, da läuft es auf DOIF hinaus.

Ideal wäre dort natürlich die Option "keine Räume außer" - aber da @rudolfkoenig sich schon in den Funkverkehr einmischte, gehe ich ohne lesen der Doku davon aus, dass es diese Option nicht gibt.

P.S: Schade übrigens - so eine Option würde alles binnen Minuten lösen.
RPI 4 - Jeelink HomeMatic Z-Wave

curt

@rudolfkoenig

Ich diskutiere derzeit ja sehr theoretisch. Ich weiß. (Aber ohne Fachwissen ist es halt leichter, mal entspannt von oben auf die Sache zu schauen.)

Würde denn die derzeit wohl nicht vorhandene Option "keine Räume außer" das Problem nicht schon vollständig lösen? Übersehe ich da was?
RPI 4 - Jeelink HomeMatic Z-Wave

Beta-User

Hatte hier mal was zusammengeschrieben. Vor allem allowedDevices(Regexp) sollte genau das bereits zum jetzigen Stand "auf die Schnelle" machen, was du brauchst:

Zitat von: Beta-User am 10 Juli 2020, 07:32:46
Vielleicht mal noch ein etwas anderer Ansatz:

Irgendwo hatten wir mal eine (von vielen) ziemlich ähnlichen Diskussionen, in deren Verlauf sich dann auch Rudi mal gemeldet hatte und (sinngemäß) angemerkt hat, dass mit SSL+allowed eigentlich dieselben Mechanismen genutzt würden, wie sie letztlich auch bei einem vpn-Zugang oder dem Zwischenschalten einer apache-Instanz genutzt würden. (Vorab hoffe ich mal, das soweit richtig zitiert zu haben, ich finde grade leider nur den thematisch (und zeitlich kurz nach dem genannten entstandenen) damit zusammenhängenden Thread zur Entstehung von reportAuthAttempts).

Unterstellt, das wäre soweit mal korrekt, wäre mein Vorschlag, das Pferd andersrum aufzuzäumen und eine Anleitung zu basteln, die in etwa so ginge:

1. Überlege, ob es überhaupt sinnvoll ist, den FHEM-Server aus dem Internet erreichbar zu machen.

2. Wenn du meinst, das sei sinnvoll und wichtig: Mache dir eine Liste von den Dingen, die du unbedingt vom Internet aus tun können willst. Bedenke dabei, dass jeder andere, der die Zugangsdaten kennt (oder irgendwie errät oder mit kriminellen Methoden ermittelt), dasselbe tun kann. Wenn es dir also nur darum geht zu sehen, welchen Status manche Geräte haben, dann beschränke den Zugang auch entsprechend! Wenn du nur bestimmte Geräte unbedingt Ein- und Ausschalten können mußt, dann beschränke den Zugang auch entsprechend! Wenn ..., dann beschränke den Zugang auch entsprechend!

Das geht so:
3. Definiere eine eigene Instanz dafür:
define fhem_inet FHEMWEB 8088 global


4. Aktiviere für diese FHEMWEB-Instanz HTTPS und teste aus, ob das lokal funktioniert (sslCertprefix setzen, dann HTTPS-Attribut, Details siehe cref zu FHEMWEB...)

5. Nutze die entsprechenden Attribute bei der FHEMWEB-Instanz, um alles, was nicht benötigt wird auszublenden bzw. den Zugriff zu verbieten: forbiddenroom, hiddengroup/-room(-Regexp), passe ggf. das Menü an.

6. definiere ein passendes allowed Device, erlaube darin erst mal nur den Zugriff aus dem lokalen Netz und teste es aus. Nutze die betreffenden Attribute von allowed, um den Zugriff entsprechend deiner Vorstellungen einzuschränken: allowedCommands, allowedDevices(-Regexp), setze reportAuthAttempts auf den passenden Wert, um v.a. auch Events für fehlgeschlagene Versuche zu erhalten!

7. Definiere einen geeigneten Eventhandler, der auf unberechtigte Zugriffe reagiert und deaktiviere mit dessen Hilfe den Zugang, falls z.B. 3 Login-Versuche binnen 10 Minuten fehlgeschlagen sind (sequence könnte dir dabei helfen...).

Teste das aus!

8. Erst dann (!): erlaube ggf. den Zugriff von beliebigen Adressen.

9. Folge den Anleitungen deines Routerherstellers zur Einrichtung eines dyndns-Diensts und gib den so vorher getesteten und SSL-User/Passwort-geschützten eingeschränkten Port (s.o.: 8088) an deinem Router frei.

10. Teste regelmäßig aus, ob alles noch funktioniert, wie es soll!

11. Ab jetzt sind regelmäßige updates für das Betriebssystem und v.a. die Softwarepakete, die den SSL-Teil betreffen PFLICHT! ("Never change" war noch nie richtig, aber jetzt ist eine faule Ausrede!)

Fragen, Anmerkungen, Kritik: Gerne...

(Ich nutze selbst vpn und hatte daher noch nicht die Muße, das mal in der Praxis umzusetzen und passend zu dokumentieren. Aber vielleicht mag ja jemand anderes...? Wenn jemand den Text+Bilder beisteuert (optimalerweise auf Basis der demo-Konfiguration) und das an sich fachlich ok ist (und sicher!), packe ich es jedenfalls gerne ins Wiki.)

Gruß, Beta-User



Das mit Telegram kann ich jetzt halbwegs nachvollziehen, eigene Menüs etc. zu fabrizieren ist aber nicht besonders schwer...

Zum aktuellen Problem: Die Nachbarin "sieht" oder hört, ob die Pumpe an ist?
Wenn ja: leg ihr doch einfach eine 433MHz-Fernbedienung (oder was ähnliches) an einen geeigneten Ort, ein notify dazu und gut ist...?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatWürde denn die derzeit wohl nicht vorhandene Option "keine Räume außer" das Problem nicht schon vollständig lösen? Übersehe ich da was?
Willst du das Geraet in der Detailansicht sehen duerfen? Modifizieren? Perl-Code eingeben koennen? URL-Angriffe sollten auch vermieden werden, da nur weil ein Eingabefeld nicht angezeigt wird, heisst noch nicht, dass die Ausfuehrung auch untersagt ist.
Man koennte natuerlich ein Attribut bauen, was dein Anwendungsfall abdeckt (wenn der Fall genau definiert ist), ich wuerde aber stattdessen mit einem HOWTO anfangen, den man in AttrTemplate giessen kann.
Vermeidet eine doppelte Implementierung diverser Mechanismen.

Wernieman

Wobei ich generell FHEM nicht extern erreichbar machen würde. Also nicht direkt, wenn schon über einen Proxy.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Beta-User

Zitat von: Wernieman am 29 Juli 2020, 09:45:48
Wobei ich generell FHEM nicht extern erreichbar machen würde. Also nicht direkt, wenn schon über einen Proxy.
Wenn ich Rudi dazu richtig zitiert haben sollte, ist ein "Sicherheitsgewinn" durch den Proxy nicht unbedingt gegeben. Insbesondere wenn man @FHEMWEB auch SSL aktiviert hat und @allowed ordentliche Passwörter verwendet, ist es an sich kein großer Unterschied.
Was man aber insgesamt immer beachten sollte:
Der Schaden, den ein potentieller Angreifer (ohne weitere Löcher auszunutzen) anrichten kann, richtet sich immer auch danach, welche Rechte der user fhem auf dem betreffenden System (sowie ggf. weiteren, über FHEM indirekt zu erreichenden weiteren Systemen hat). Insbesondere das Einräumen von su-Rechten wäre daher ggf. "kritisch zu hinterfragen".
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatDer Schaden, den ein potentieller Angreifer (ohne weitere Löcher auszunutzen) anrichten kann, richtet sich immer auch danach, welche Rechte der user fhem auf dem betreffenden System (sowie ggf. weiteren, über FHEM indirekt zu erreichenden weiteren Systemen hat).

In einer Firma, bzw. da, wo Geheimnisse auszuspaehen oder Anlagen zu zerstoeren sind, ist das natuerlich richtig.
In FHEM Umfeld sind gekaperte Rechner vmtl eher als dumme Bots wertvoll, die als Sprungbrett zu anderen Rechner oder fuer DDOS dienen. Will sagen: ein offenes FHEM ist mAn ohne sudo genauso schlimm, wie einer mit.