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

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