Verbindung von einer nicht-lokalen Adresse ab sofort nur mit Passwort

[betateilchen]

An sich ein guter Gedanke, aber er ist leider (einmal mehr) nicht zuende gedacht.

• FHEM1 mit einer nicht-lokalen Adresse
• FHEM2 mit einer nicht-lokalen Adresse
• Beide Systeme sind per FHEM2FHEM verbunden
• Beide Systeme befinden sich in einer privateCloud, die bereits aufgrund ihrer eigenen Konfiguration so abgesichert ist, dass eine Kommunikation nur innerhalb dieses Netzwerksegmentes stattfinden kann.

Wozu brauche ich da noch einen Passwort-Zwang? Das hilft mir kein Stück weiter und bringt keinen Pups mehr Sicherheit. Es behindert nur und macht alles kompliziert.

Sicher gibt es eine Menge Anwender, die in ihrem Leichtsinn keine Ahnung haben, was sie eigentlich tun. Gerade gestern abend haben wir beim Hamburg-Stammtisch wieder über Sinn/Unsinn/Notwendigkeit einer Erreichbarkeit der FHEM Installation zuhause diskutiert.

Rudi, ich habe nichts gegen Deinen seit mehreren Monaten wütenden Paranoia-Sicherheits-Wahn. Aber denke bitte auch an Anwender, die in eigener Verantwortung bereits sichere Installationen geschaffen haben (und zwar sicherer als mit einer Passwortabfrage) und gib diesen Anwendern eine Möglichkeit, den ganzen Passwortkram in FHEM zu deaktivieren.

Davon abgesehen: Passwörter sind sowas von historisch. Wenn schon authentifizierte Anmeldung an FHEM, dann bitte endlich zertifikatsbasiert, ohne dass es dazu noch eines vorgeschalteten anderen Webservers bedarf, der so eine Möglichkeit bietet.

Beides sind mAn Selbstverstaendlichkeiten, und erwarte sie selbst von Anfaengern.

Und für mich wäre es eine Selbstverständlichkeit, wenn Du als Entwickler bei einer solchen Änderung auch an diejenigen Anwender denken würdest, die ein solches Feature definitiv nicht brauchen.

[RaspiLED]

Hi Betateilchen,
Danke für Dein Anwendungsszenario!
Genau so eine Thematik mit lokalen Adressen haben wir im anderen Thread diskutiert. https://forum.fhem.de/index.php?topic=72629.msg642594#msg642594
Die Entwickler waren (und das nach Abwertung der Situation auch richtig) der Meinung, dass eine Analyse der Netzwerkkarten und der erlaubten Netmasks nicht schnell und einfach einbaubar ist.
Insofern sei Dir als Profi doch dazu geraten, den erwähnten attr WEB allowfrom auf .* zu setzen.
https://fhem.de/HOWTO_DE.html#security
Danke für Dein Verständnis!
Beste Grüße
Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[amenomade]

Insofern sei Dir als Profi doch dazu geraten, den erwähnten allow from auf .* zu setzen.

Genau. Oder was auch immer, das zu eure Konfiguration passt. Z.B. "allow from" dem anderen FHEM.

[betateilchen]

nochmal: Dieses allowfrom existiert bei mir bereits in einer viel tieferen Schicht der Verbindung. Wozu nochmal das gleiche weiter oben (auf Applikationsebene) konfigurieren müssen? Das ist doch grober Unfug.

Danke für Dein Verständnis!

Für so einen Murks habe ich NULL Verständnis. Sorry.

[amenomade]

Wozu nochmal das gleiche weiter oben (auf Applikationsebene) konfigurieren müssen?

Um die Installationen von Benutzern abzusichern, die kein Developer sind, und viel weniger Ahnung von Netzwerke, Proxies, TCPIP, cloud usw als Du haben.

Für die, ist es eine grosse Verbesserung. Für FHEM im allgemein vermeindet es sowas wie http://www.ardmediathek.de/tv/Plusminus/Smart-Home-So-leicht-haben-es-Einbrec/Das-Erste/Video?bcastId=432744&documentId=40709860
Für dich, nur ein kleines ".*" hinzufügen. Aber gut... du hast null Verständnis, hab es gelesen... und vestehe teilweise. Nur teilweise

[CoolTux]

Meine Meinung!

Jeder kann so viel Ahnung haben wie er denkt zu brauchen. Wegen meiner auch Anfänger Ahnung. Aber dann lasse ich gefälligst die Finger und Gedanken davon mein FHEM aus dem Internet zugänglich zu machen. Jeder, wirklich jeder weiß heutzutage wie Gefährlich das Internet sein kann. Daher entweder Ahnung aneignen und dann mit dem richtigen wissen den Zugang bereiten oder Finger weg vom FHEM aus dem Internet.



Grüße

[micomat]

die erfahrung zeigt nun mal das der mensch seine systeme nicht im griff hat und hilfe braucht.
von daher muss auch ich mich mit solchen features rumärgern. ich kann damit leben

und.. solch einen aufschrei gab es schon bei autos als das esp eingeführt wurde. und man hat sich dran gewöhnt und will es eigentlich auch nicht mehr missen. auch wenn profis das doof finden.

[Amenophis86]

Ich kann beide Seiten verstehen, aber ich tendiere da eher zu Rudi. FHEM nimmt immer mehr Leute mit, die weniger Ahnung von der Materie haben, als sie sollten. Diesen Leuten sollte auf einfachem Wege geholfen werden, dh solche Funktionen einbauen und als Standard setzen. Allerdings ist glaube ich eher das Problem, dass es erst umgesetzt und dann Angekündigt wurde. Dieses Problem hatten wir schon das ein oder andere Mal. Vermutlich wäre es einfach gewesene, wenn man es angekündigt hätte im Sinne von:

Am XX.YY wird mit dem Update folgende Funktion automatisch aktiv. Diese kann mittels ... verhindert werden. Ich empfehle jedem Nutzer, die Funktion aktiviert zu lassen ...

Oder so ähnlich. Dann hätten User wie betateilchen nicht das Problem gehabt und der Erfolgt der Maßnahme wäre trotzdem eingetreten. Die Diskussion, ob man es brauch oder nicht kann man trotzdem führen, aber erst Mal hat man wieder den unerfahrenen Benutzern geholfen. Und gerade hier sehe ich den Bedarf und sehe es daher eher wie Rudi.

[CoolTux]

Kann mir einer sagen wie die Fehlermeldung im Falle eine Verbindungsverweigerung aus schaut. Gibt es wenigstens eine vernünftige Fehlermeldung?

Ich habe eine DMZ Class C Privatnetz und ein internes Class A Privatnetz. Wenn ich das richtig verstanden habe sollte ich also keine Probleme haben, korrekt?
10/8
192.168/16


Grüße

[DeeSPe]

Kann mir einer sagen wie die Fehlermeldung im Falle eine Verbindungsverweigerung aus schaut. Gibt es wenigstens eine vernünftige Fehlermeldung?

Laut Code:

Code Auswählen Erweitern

if($auth == 0) {
        Log3 $name, 1,
             "Connection refused from the non-local address $caddr:$port, ".
             "as there is no working allowed instance defined for it";
        close($clientinfo[0]);
        return undef;
      }


Ich habe eine DMZ Class C Privatnetz und ein internes Class A Privatnetz. Wenn ich das richtig verstanden habe sollte ich also keine Probleme haben, korrekt?
10/8
192.168/16

Korrekt!

Gruß
Dan

[CoolTux]

Laut Code:

Code Auswählen Erweitern

if($auth == 0) {
        Log3 $name, 1,
             "Connection refused from the non-local address $caddr:$port, ".
             "as there is no working allowed instance defined for it";
        close($clientinfo[0]);
        return undef;
      }


Korrekt!

Gruß
Dan

Hallo Dan,

Da keine Dir, ich meinte da bereits eher die Meldung die am Browser an kommt 

[ComputerZOO]

Moin,
ich stecke leider nicht so tief in der Netzwerk-Materie. Ich verbinde mich via VPN-on-demand vom iPhone oder iPad aus mit der FRITZ!Box zu Hause und bekomme dadurch ja eine interne IP zugewiesen. Seit der Umstellung auf VPN habe ich die Löcher (Portweiterleitungen auf 808x) wieder gestopft.
Jetzt zu meinen Fragen:
- Kann ich davon ausgehen, das diese Möglichkeit der Verbindung einigermaßen sicher ist?
- Muss ich nach dieser oben angesprochen Umstellung mit Problemen bei meiner Zugangsart rechnen?

[Benni]

- Kann ich davon ausgehen, das diese Möglichkeit der Verbindung einigermaßen sicher ist?
- Muss ich nach dieser oben angesprochen Umstellung mit Problemen bei meiner Zugangsart rechnen?

- Ja!
- Nein!

[rudolfkoenig]

... ich meinte da bereits eher die Meldung die am Browser an kommt.

Die Meldung auf OS Ebene ist "Connection refused". Leider dichten daraus manche Browser was unverstaendliches, von wegen Internet ist aus, oder so.

Beide Systeme befinden sich in einer privateCloud, die bereits aufgrund ihrer eigenen Konfiguration so abgesichert ist, dass eine Kommunikation nur innerhalb dieses Netzwerksegmentes stattfinden kann.

Ich gehe davon aus, dass ein VPN ein Netz verwendet, was nicht oeffentlich vergeben wird, und damit in der Liste der "lokalen" Adressen befindet. Falls das nicht der Fall ist, dann musst du leider allowfrom oder allowed setzen. Ich hoffe, dass sowas eine seltene Ausnahme ist, wenn nicht, dann muss ich was anpassen.

gib diesen Anwendern eine Möglichkeit, den ganzen Passwortkram in FHEM zu deaktivieren.

Das gibt es ja (siehe allowfrom), aber nicht als Voreinstellung. Und ich kann das nicht als Voreinstellung lassen, weil es dann Leuten, die keine Ahnung haben, und/oder keine Doku lesen, nichts hilft. Leider ist FHEM nicht kryptisch / unfreundlich genug, so dass es zunehmend von Anwender verwendet wird, die von IT/Sicherheit kaum eine Ahnung haben. Ich habe das nicht bewusst herbeigefuehrt, aber wenn es schon passiert ist, will ich nicht als Verantwortlicher fuer Sicherheitsloecher hingestellt werden, wenn FHEM-Installationen zu einem ferngesteuerten Bot umkonfiguriert werden.

[raspklaus]

wie kann ich denn nun das attribut allowfrom einfügen, wenn ich über die Weboberfläche keinen Zugriff mehr habe ?

und wäre das ein geeigneter Eintrag ?

192.200.100.35|192.200.100.81|127.0.0.1|192.200.100.95|192.200.100.32