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

[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

[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?

[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]

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.

Wä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 ...

[curt]

Falls es FHEMWEB sein soll: ich wuerde mit

Ok, verstanden.

Falls Du diesen Weg waehlst,

War jedenfalls mein erster Gedanke.

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.

[Wzut]

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

[Wernieman]

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 ...

[rudolfkoenig]

Ja. Falls ich das sauber hinkriege, zeige ich es. Klar.

Keiner wird sich aufregen, wenn sowas erst nach dem Urlaub kommen sollte.

[curt]

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.

[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?

[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:

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:

Code Auswählen Erweitern

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...?

[rudolfkoenig]

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?

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.

[Beta-User]

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".

[rudolfkoenig]

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).

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.

[Beta-User]

Es ging auch nicht darum, "Werbung" zu machen für offene FHEM-Installationen, sondern das sollte eher so zu lesen sein: ein (ordentlich) SSL+allowed-abgesichertes FHEM vorausgesetzt, braucht man nicht unbedingt einen reverse proxy. Unabhängig von der Frage ober "direkt" oder via reverse proxy sollte man sich aber trotzdem überlegen, was "fhem" wirklich dürfen muß...

[MadMax-FHEM]

Mal ganz andere Frage: Nachbarin!? Wie weit weg!? Wenn nicht zu weit weg: wäre dann nicht ein simpler z.B. Homematic Schalter (oder anderes System) einfacher (und auch sicherer)!?

Nur mal so als weitere Idee...

Ansonsten bin ich (hier) wieder ruhig...

Gruß, Joachim

[Wernieman]

Naja ... meine Meinung dazu dürfte bekannt sein:
FHEM (auc mit SSL und Passwortschutz etc.) ist nicht Sicherheitsgeprüft und solange würde ich es nicht direkt im Netz betreiben. Ein Proxy mit Passwortschutz ist da schon besser ...
(Ist jetzt keine Anschuldigung an die Entwickler, sondern prinzipiell)

Deshalb ist natürlich besser ein VPN, oder eben sogar eine Webside "dazwischenschalten", dann ein Proxy und dann erst "pures FHEM" .. aber das ist nur meine Meinung.

Aber in diesem Beispiel könnte es sogar sein, das die Nachbarin ins WLAN kommt .. das ist natürlich Sicherheitstechnisch schon besser ;o)

[MadMax-FHEM]

Aber in diesem Beispiel könnte es sogar sein, das die Nachbarin ins WLAN kommt .. das ist natürlich Sicherheitstechnisch schon besser ;o)

Ok, auf das "Stichwort" muss ich dann doch noch mal

Wenn WLAN bis zur Nachbarin reicht und man keine Angst hat, dass jemand den Button "klaut" und dann daraus die WLAN-PWs etc. "extrahiert" ginge auch ein Shelly-Button (oder falls noch ein funktionierender "rumliegt": dash button)...
https://shop.shelly.cloud/shelly-button-wifi-smart-home-automation#64

Gruß, Joachim

[TomLee]

Sicherheitstechnisch unbedenklich (ohne Wlan) und ähnlich gelagert wie schon dieser Vorschlag

leg ihr doch einfach eine 433MHz-Fernbedienung (oder was ähnliches) an einen geeigneten Ort, ein notify dazu und gut ist...?

Für die Zeit des Urlaub einen IR-Empfänger zur Seite der  Nachbarin installieren und eine oder auch zwei Tasten irgendeiner IR-FB als Trigger zum schalten der Gartenpumpe verwenden.

Gruß

Thomas

[curt]

Mal ganz andere Frage: Nachbarin!? Wie weit weg!? Wenn nicht zu weit weg: wäre dann nicht ein simpler z.B. Homematic Schalter (oder anderes System) einfacher (und auch sicherer)!?

Ahhhh - das ich da nicht selbst drauf kam! Das war wohl der richtige Schubs: Ich habe mir gerade so eine ZWave-"Autofernbedienung" bestellt. Danke @MadMax-FHEM.
Ok, damit ist meine Motivation für die Gestaltung einer zweiten FHEM-Weboberfläche nicht mehr ganz so groß @rudolfkoenig. Gleichwohl muss ich mir mal genauer anschauen, ob da aus meiner bescheidenen Sicht was zu machen ist.

Naja ... meine Meinung dazu dürfte bekannt sein:

Nein, mir nicht.
Ok, das wird jetzt zwar theaddrift, aber egal:

FHEM (auc mit SSL und Passwortschutz etc.) ist nicht Sicherheitsgeprüft und solange würde ich es nicht direkt im Netz betreiben.

Da fehlen mir Deine Argumente @Wernieman :
Geht es Dir um einen fehlenden ordentlichen Pentest mit Zertifikat für 30k€? Oder geht es um konkrete fachliche Argumente? Welche?

(Ich betreibe meine FHEM-Installation selbstverständlich so, dass sie via Internet erreichbar ist. Einziger, schon mit Rudolf diskutierter Makel: Es gibt kein access.log im Common-Format.)

Ein Proxy mit Passwortschutz ist da schon besser ...

Mir ist unklar, was ein Proxy im Vergleich zur direkten Erreichbarkeit verbessern soll: Benenne bitte die aus Deiner Sicht vorhandenen Vorteile.

Aber in diesem Beispiel könnte es sogar sein, das die Nachbarin ins WLAN kommt .. das ist natürlich Sicherheitstechnisch schon besser

Waaaas?
Auf die Idee käme ich nichtmal in einem sehr schlechten Traum.

Ich sehe insgesamt ordentliches Streitpotenzial. Das liegt allerdings (auch) daran, dass wir die technischen Randbedingungen nicht festlegten.

P.S: Ich habe das Subject des Threads angepasst.

[micky0867]

Naja ... meine Meinung dazu dürfte bekannt sein:
FHEM (auc mit SSL und Passwortschutz etc.) ist nicht Sicherheitsgeprüft und solange würde ich es nicht direkt im Netz betreiben. Ein Proxy mit Passwortschutz ist da schon besser ...
(Ist jetzt keine Anschuldigung an die Entwickler, sondern prinzipiell)

Deshalb ist natürlich besser ein VPN, oder eben sogar eine Webside "dazwischenschalten", dann ein Proxy und dann erst "pures FHEM" .. aber das ist nur meine Meinung.

Da bist du mit deiner Meinung nicht alleine.
Ein weiterer netter Nebeneffekt von einem Proxy ist z.B. auch die Einbindung von anderen Geräten...
Ich habe in FHEM meine Webcams eingebunden. Da der Stream letztlich vom Browser geholt wird, muss ich vom Internet an meine Cams kommen.
Logisch, dass ich weder eine direkte Portweiterleitung meiner Fritze machen will, noch dass die Cams selbst nach hause telefonieren dürfen.
Also habe ich in FHEM eine SSL und Passwort gesicherte URL eingebunden, mit der der Stream via Proxy angezeigt wird.
Auf diesem Weg kann ich auch auf andere HTTP-fähige Geräte in meinem Netz zugreifen und das auch bei solchen, die kein SSL/Passwortschutz unterstützen.

Aber Security wird für viele Leute erst dann interessant, wenn's Kind im Brunnen liegt (gilt auch für Backups).

Ich möchte jedenfalls nicht in der folgenden Liste zu finden sein:
https://www.shodan.io/search?query=fhem

[rudolfkoenig]

Ich möchte jedenfalls nicht in der folgenden Liste zu finden sein:
https://www.shodan.io/search?query=fhem

Soweit ich sehe, steht neben jedem Eintrag "login required", und ob auf der Apache Liste zu stehen schoener ist, ist Ansichtssache. Apache/nginx/etc sind natuerlich besser geprueft als FHEMWEB, allerdings auch von Einbrecher.
Wenn jemand konkrete Probleme meldet, dann werde ich sie beheben, oder ich aendere meine Meinung zum Thema.

[Wernieman]

Da fehlen mir Deine Argumente @Wernieman :
Geht es Dir um einen fehlenden ordentlichen Pentest mit Zertifikat für 30k€? Oder geht es um konkrete fachliche Argumente? Welche?

Sorry aber so ist es von Dir etwas polemisch geschrieben.

Hintergrund:
Jeder Programmierer macht Fehler. Solange also nicht in einem "echten" Review Prozess darüber geschaut wird, kann (und wird es) Fehler enthalten. Aus dem Netz bedeuten Fehler immer gleich Probleme.  Im Bereich FHEM .. ist es wirklich nicht möglich, die Autorisation zu umgehen?

Wenn schon bei besser Überwachte "Produkte" als FHEM dabei solche Schwerwiegenden fehler aufgetaucht sind .... und FHEM ist ebnen nicht darauf getestet.

Um die Polemik umzudrehen:
Jeder ins Netz gehängte Dienst hat Potentiell 4,13 Milliarden "Feinde" ... es gibt schließlich c.a. 4,13 Milliarden Nutzer im Internet .... (siehe z.B. https://de.statista.com/themen/42/internet/)
Den meisten Usern ist genau so etwas nicht klar ......

Hinweis:
Dieses ist KEINE Anklage gegen irgendwelche Programmierer von FHEM. Diese machen ihren Job Fantastisch!

[micky0867]

Soweit ich sehe, steht neben jedem Eintrag "login required", und ob auf der Apache Liste zu stehen schoener ist, ist Ansichtssache. Apache/nginx/etc sind natuerlich besser geprueft als FHEMWEB, allerdings auch von Einbrecher.
Wenn jemand konkrete Probleme meldet, dann werde ich sie beheben, oder ich aendere meine Meinung zum Thema.

Du hast ja vollkommen Recht, aber .....
- mein System hat 2 verschiedene Sicherheitsstufen: 1. nginx, 2. FHEM; ist die erste überwunden, bleibt noch die 2. zu knacken
- wenn tatsächlich ein Fehler in einem Dienst gefunden wird, kann man über shodan alle anfälligen Systeme sehr schnell lokalisieren; mein FHEM kann man so jedenfalls nicht lokalisieren
- mein nginx läuft auf einem separaten Pi in einem abgeschotteten Netz (quasi DMZ).
- meine Syno war damals zum Glück gut abgesichert: https://www.ifun.de/synolocker-was-tun-wenn-eure-synology-diskstation-betroffen-ist-64164/

Die einzige Steigerung, die mir noch einfallen würde, wäre der ausschließliche Zugriff per VPN, bzw. Telegram.

Edit:
auch da schließe ich mich Werniemann an:
"Hinweis:
Dieses ist KEINE Anklage gegen irgendwelche Programmierer von FHEM. Diese machen ihren Job Fantastisch!"

[rudolfkoenig]

Die einzige Steigerung, die mir noch einfallen würde, wäre der ausschließliche Zugriff per VPN, bzw. Telegram.

Wobei noch zu zeigen waere, warum VPN oder Telegramm prinzipiell sicherer sind, als ein SSL+Passwort gesicherter Apache-Zugang. Vmtl. gilt hier auch das Prinzip wie im Mittelalter: zwei oder drei Burgmauer sind besser als einer.

[micky0867]

.. zwei oder drei Burgmauer sind besser als einer.

Gute Idee!
Eine zusätzliche Burgmauer in Form von 2FA

und siehe da:
https://forum.fhem.de/index.php/topic,65668.msg

Danke für den Schubs, darüber hatte ich noch nie nachgedacht!

[Wernieman]

OT:
Ich finde das Analogon Burg ziemlich gut und habe es auch in der Vergangenheit bei Meetings zu dem Thema schon mehrfach verwendet.

Damit kann man auch gut begründen, warum eine Fireall alleine kein Guter Schutz ist. Es reicht eben nicht "nur" Burgmauern mit Wachdienst am Tor zu bauen und dann die Schatzkammer offen stehen zu lassen ....

Dann versteht auch ein Nicht-Tekki etwas von der Sicherheitsproblematik

[Beta-User]

Wie meistens: Es kommt immer drauf an, was man eigentlich braucht:

Wenn es "nur" darum geht, FHEM ins INet zu stellen, ist es vermutlich für "Otto Normaluser" (so es den gibt) einfacher, das (bis auf den Port im Router) ausschließlich mit FHEM-Bordmitteln zu bewerkstelligen. Wenn man weitere Geräte hat, die ins INet sollen, ist eine universellere Lösung mit reverse proxy wohl zu bevorzugen. MMn. hängt letztendlich die Sicherheit des Gesamtsystem aber vor allem daran, dass derjenige, der das ins Netz stellt, auch wenigstens grob überblickt, wo jeweils der Haken ist und Probleme entstehen können.

Wobei noch zu zeigen waere, warum VPN oder Telegramm prinzipiell sicherer sind, als ein SSL+Passwort gesicherter Apache-Zugang. Vmtl. gilt hier auch das Prinzip wie im Mittelalter: zwei oder drei Burgmauer sind besser als einer.

Wenn das nämlich mit dem "Gefühl" für die Probleme nicht gegeben ist, dann hat man am Ende keine zwei bis drei gut durchdachte und verteidigbare Burgmauerringe, sondern eine entsprechende Anzahl von löchrigen Baustellen, um die man gut und unbemerkt (bis zur "Schatzkammer") rumgehen kann...

Was Telegram angeht, ist das mit ziemlicher Sicherheit nicht per se sicherer wie die anderen Lösungen. Aber wenn man es richtig macht, kann man die Befehle und die User sauber einschränken und damit eine einfach zu bedienende Nutzerschnittstelle für einzelne Aktionen bereitstellen. (Und genau darum ging es im Ausgangspost).

Ich habe mir gerade so eine ZWave-"Autofernbedienung" bestellt.

Mit einer direkt über das Hardwaresystem gekoppelten Lösung, die (nach dem Einrichten) FHEM gar nicht braucht (so ist das zu lesen und das ist der Vorteil zu der 433MHz-Fernbedienung, oder?), bist du selbstredend am Ende wohl am besten (und auch unter anderen Gesichtspunkten) sichersten bedient .

[curt]

Zitat von: curt am Gestern um 02:59:30
Da fehlen mir Deine Argumente @Wernieman :
Geht es Dir um einen fehlenden ordentlichen Pentest mit Zertifikat für 30k€? Oder geht es um konkrete fachliche Argumente? Welche?

Sorry aber so ist es von Dir etwas polemisch geschrieben.

Nein, das war nicht mein Ziel. Allerdings müssen wir uns angewöhnen, präzise zu fragen (und präzise zu antworten): So ein "Gefühl"- und "Meinung"-Wischiwaschi gehört in die "sozialen Medien".

Hintergrund:
Jeder Programmierer macht Fehler. Solange also nicht in einem "echten" Review Prozess darüber geschaut wird, kann (und wird es) Fehler enthalten.

Ein Review-Prozess kann die Fehler finden, muss es aber nicht. Es ist ein Irrglaube, dass man sicher sei, weil irgendwas zertifiziert ist: Die regelmäßigen Updates eingeführter Produkte wie Windows, Android, IPhone, Cisco, Debian undundund sprechen Bände. Und das sind nur die aufgefallenen Fehler: Von ZeroDays spreche ich da noch gar nicht.

Aus dem Netz bedeuten Fehler immer gleich Probleme.

Um dem wirklich aus dem Weg zu gehen, gibt es nur eine Möglichkeit: Keinerlei IT einsetzen. Alles andere ist Augenwischerei.

Im Bereich FHEM .. ist es wirklich nicht möglich, die Autorisation zu umgehen?

Mir fällt da kein Weg ein - aber das muss nichts heißen. Was mich an der Stelle (Feind von außen) im Moment wirklich stört, ich sage es immer wieder: Eigentlich braucht FHEMWEB (zusätzlich) ein standardisiertes Logfile, also im Common-Format, am liebsten noch konfigurierbar wie bei Apache.

Bei "Angriff von außen" liegt es aber durchaus am Nutzer: Man kann Wahrscheinlichkeiten beeinflussen. Am Beispiel meiner Konfiguration:
Zwar hat mein Provider mir neuerdings auch eine Fritzbox aufgenötigt, mit Wartungszugang für ihn. Aber: auf meiner Fritzbox passiert nichts, da ist selbst Wlan aus. Die Fritzbox leitet lediglich ein Vlan aus. Dahinter ist ein Debian-Server: Der ist mein Router und bedient mehrere Intranets: Zwei Intranet mit je einem Wlan-Server, ein Intranet mit FHEM-Server, ein Intranet für das kabelgebundene Hausnetz, zwei Segmente. Der erste wichtige Punkt: Der Debian-Router ist Firewall. Und er ist DNS-Server für intern, dabei nutzt er aber nicht die DNS des Providers, sondern die Root-Server - da fängt es schon mal an.

Um den Debian-Router noch genauer zu betrachten: Außer SSH lässt der exakt nichts rein. Auch kein VPN. Die Ausnahme sind zwei Tunnel durch die Firewall, real sind das Portforewards auf zwei verschiedene interne Webserver/https/Auth. Und da wird es wieder interessant: Die Ports liegen oberhalb 40.000, sie sind (wichtig) keine Ports, die durch irgendwelche bekannte Server genutzt werden, sowas kann man recherchieren. Schon mit dieser Maßnahme hat man jede Menge Standardangriffe weggebremst. Aber es geht noch weiter: Um es potenziellen Angreifern so schwer wie möglich zumachen, muss im Header alles ausgeschaltet werden, was erkennbar macht - zum Beispiel dieses unsägliche csrfToken.

Aber schon an der Stelle (Angriff von außen) springst Du zu kurz (aber diesen Fehler machen viele):
Der Feind kann durchaus auch innen sitzen: Zum Beispiel ein Android-6 mit komischen Apps. Oder auch ohne komische Apps. Und dann die vielen Devices, die an FHEM hängen: Der komplette Rotz ist, wenn er nicht in Polen hergestellt wurde, aus China. Komplett. Niemand weiß, was die Chinesen da zusätzlich in die Firmware pressten ... von Updates wollen wir mal gar nicht erst reden.

Wenn schon bei besser Überwachte "Produkte" als FHEM dabei solche Schwerwiegenden fehler aufgetaucht sind ....

Das ist -für sich genommen- kein Argument.
Eher ist Komplexität (bzw. im Idealfall fehlende solche) ein Argument.

Um die Polemik umzudrehen:
Jeder ins Netz gehängte Dienst hat Potentiell 4,13 Milliarden "Feinde" ... es gibt schließlich c.a. 4,13 Milliarden Nutzer im Internet ....

Und genau das (Polemik) müssen wir lassen, das führt zu nichts. Wir müssen uns sachlich die Probleme (bzw. auch die vermuteten Probleme) ansehen.

Damit wäre ich bei "Proxy": Ich weiß wirklich nicht, welchen Sicherheitsgewinn ein Proxy bringen soll. Gut, da kann man eine zweite Password-Abfrage machen. Aber das war es dann schon. Wer von außen (oder innen!) Zugang hat, hat auch die Passworte mitgeschnitten. Ansonsten reicht ein https-Proxy 1:1 durch, er darf ja definitionsgemäß nichts anderes machen. Sicherheitsgewinn: Null.

Ganz im Gegenteil: Wenn ein Proxy ausschließlich "wegen der Sicherheit" genutzt wird, muss sehr deutlich darauf hingewiesen werden, dass das ausschließlich zu mehr Komplexität führt. Und mehr Komplexität heißt - mehr Fehlermöglichkeiten: Eigene Fehler, Administrationsaufwand, unerkannte Softwarefehler. Undsoweiter.

[Wernieman]

Ich weiß, das ich den Angriff von Innen nicht berücksichtigt habe. Aber hier ging es um einen Zugriff von Außen ....

Und ja, ich habe beruflich damit zu tuen. Trotzdem werde ich in Sozialen Medien für Normaluser nicht detailliert schreiben. Die meisten verstehen es nicht.

Ansonsten gut von Dir geschrieben ... auch wenn Du Dich widersprichst:
"Außer SSH lässt der exakt nichts rein" ... "Die Ausnahme sind zwei Tunnel" ... also Doch mehr als SSH ;o)

Aber jetzt ist Wochenende ...

[curt]

Ich weiß, das ich den Angriff von Innen nicht berücksichtigt habe. Aber hier ging es um einen Zugriff von Außen ....

Und ich dachte, es ginge um Systemsicherheit?

Und ja, ich habe beruflich damit zu tuen.

Das passt ja gut - ich auch.

Ansonsten gut von Dir geschrieben ... auch wenn Du Dich widersprichst:
"Außer SSH lässt der exakt nichts rein" ... "Die Ausnahme sind zwei Tunnel" ... also Doch mehr als SSH ;o)

Ich verstehe die Aussage nicht. Es ist nun mal der erste Schritt, dass man genau weiß was man zulässt - und das auch überwacht.

Da sehe ich eine Fritzbox, auf der zig Dienste laufen als deutlich kritischer.

Aber jetzt ist Wochenende ...

Ich wünsche ein schönes solches.

P.S: Zitatebene korrigiert.

[rudolfkoenig]

Einziger, schon mit Rudolf diskutierter Makel: Es gibt kein access.log im Common-Format.

Ich habe jetzt die FHEMWEB logDevice und logFormat Attribute hinzugefuegt:

logDevice fileLogName
Name of the FileLog instance, which is used to log each FHEMWEB access. To avoid writing wrong lines to this file, the FileLog regexp should be set to <WebName>:Log

logFormat ...
Default is the Apache common Format (%h %l %u %t "%r" %>s %b). Currently only these "short" place holders are replaced. Additionally, each HTTP Header X can be accessed via %{X}

[curt]

logDevice fileLogName
Name of the FileLog instance, which is used to log each FHEMWEB access. To avoid writing wrong lines to this file, the FileLog regexp should be set to <WebName>:Log

Kannst Du diesen Teil, ggf. am konkreten Beispiel, bitte genauer erläutern?

Mir ist unklar, was da konkret zu stehen hat. Und setzt das ein bestehendes Logfile für die FHEMWEB-Device voraus?

[rudolfkoenig]

Kannst Du diesen Teil, ggf. am konkreten Beispiel, bitte genauer erläutern?

Fuer die "Copy&Paste, will jetzt nicht lesen und experimentieren" Fraktion:

Code Auswählen Erweitern

define webCustomLog FileLog ./log/webCustom.log WEB:Log
attr WEB logDevice webCustomLog


[curt]

Lieber Rudolf,
sehr herzlichen Dank: Issjamangeil!

Fuer die "Copy&Paste, will jetzt nicht lesen und experimentieren" Fraktion:

Der Pickser rauscht an mir vorbei ... jeder Mensch lernt halt anders. Und offen gesagt hätte ich das (mit der gegebenen Beschreibung) nie hinbekommen. Auch nach Tagen nicht.

Ich habe mal ganz kurz mit LogFormat rumgespielt: Das ist nicht das mir vertraute Apache2-Format (mit Backslash und Anführungszeichen und "i"). Aber das kriegt man mir kurzem Blick auf das Log ja schnell raus, kein Problem.

Eins fiel mir bei meinen ersten Spielereien auf, ich schaue Dich mit meinem treuen Dackelblick an:

Code Auswählen Erweitern


%{Via}
%{X-Forwarded-For}


Die sind beide putt. Wäre es sehr aufwändig, die noch zu implementieren?

Eine Frage noch am Rande, das fiel mir ganz zufällig auf:

Code Auswählen Erweitern


.httpAuthHeader
HTTP/1.1 401 Authorization Required
WWW-Authenticate: Basic realm="FHEM: login required"


Ich bin nun nicht der Macher von shodan.io - würde aber schon vermuten wollen, dass die dortige Suchanfrage nach "FHEM" sich genau den Basic realm greift - und damit tonnenweise FHEM-Installationen offenlegt. Reine Theorie: Es ist ja Wurscht, was da vor dem Doppelpunkt steht, das könnst Du für jede Installation auch nach Wörterbuch auswürfeln, beispielsweise.

Nur mal als fixe Idee: Wie wäre es denn, wenn man den String nach "Basic realm=", also der Teil, in dem jetzt "FHEM" steht, konfigurierbar macht? Ich könnte das dann "TanteErna" nennen ...

Damit wir uns aber nicht vertun und meine kleinen Anmerkungen falsch verstanden werden: Danke Rudolf!

[rudolfkoenig]

Wie wäre es denn, wenn man den String nach "Basic realm=", also der Teil, in dem jetzt "FHEM" steht, konfigurierbar macht?

Siehe "attr allowed basicAuthMsg". Ich habe jetzt FHEM: in der Voreinstellung entfernt.

%{Via}
%{X-Forwarded-For}
Die sind beide putt. Wäre es sehr aufwändig, die noch zu implementieren?

Falls diese Daten nicht aus dem HTTP-Header kommen, dann brauche ich Hinweise, wie man an sie rankommt.
Habe die Funktion geaendert, damit alle nicht gefundene oder unbekannte %NAME oder %{NAME} Elemente als - zurueckgeliefert werden.

[rudolfkoenig]

Das ist nicht das mir vertraute Apache2-Format (mit Backslash und Anführungszeichen und "i")

Den Backslash finde ich uebertrieben, Apache macht es nur, weil da die Syntax es erfordert. Ich wuerde es ungern implementieren, es resultiert nur in eine Menge von zusaetzlichen Fehlermoeglichkeiten, ohne sichtbares Nutzen.

Das i habe ich in der Apache Doku uebersehen, und habe es jetzt in FHEMWEBs logFormat angepasst: Header Elemente sind ab sofort per %{X}i zu holen.

[curt]

%{Via}
%{X-Forwarded-For}
Die sind beide putt. Wäre es sehr aufwändig, die noch zu implementieren?

Falls diese Daten nicht aus dem HTTP-Header kommen, dann brauche ich Hinweise, wie man an sie rankommt.

Kommen aus dem Header. Via ist in RFC7230 [¹], %{X-Forwarded-For} ist ein defacto-Standard [²].

Habe die Funktion geaendert, damit alle nicht gefundene oder unbekannte %NAME oder %{NAME} Elemente als - zurueckgeliefert werden.

Den Backslash finde ich uebertrieben, Apache macht es nur, weil da die Syntax es erfordert.

Ja, das klingt überzeugend.

Das i habe ich in der Apache Doku uebersehen, und habe es jetzt in FHEMWEBs logFormat angepasst: Header Elemente sind ab sofort per %{X}i zu holen.

Das (und Basic realm): Da muss ich das Update abwarten.

[¹] https://tools.ietf.org/html/rfc7230#section-5.7.1
[²] https://de.wikipedia.org/wiki/X-Forwarded-For

[curt]

Siehe "attr allowed basicAuthMsg". Ich habe jetzt FHEM: in der Voreinstellung entfernt.

Ganz kurz (!) getestet - und gescheitert.

Basis: Nokia 7+ (Android-One, Android-10, Patchlevel 1.Juli 2020)

In FHEM basicAuthMsg mit Wert gefüllt, das Folgende in fhem.cfg vorgefunden:

Code Auswählen Erweitern


> define allowed_WEBphone allowed
> setuuid allowed_WEBphone xxxxxxxxx
> attr allowed_WEBphone basicAuthMsg Fe1v
> attr allowed_WEBphone validFor WEBphone


Ergebnis ist, dass sich Opera-mini strikt weigert, mich auch nur bis zu dem Punkt "Deine Verschlüsselung ist nicht sicher" zu führen.

Ich schreibe diesen Beitrag ohne jeden Anspruch, nur für "wer schreibt, der bleibt". Leider habe ich in diesem Moment keine Zeit, mir die Sache genauer anzusehen.