Externer Zugriff auf Frontend

[MarkoP]

Hallo, ich habe mir ein schönes Frontend mit FTUI gebastelt. Der Fhem-Server läuft auf einem NAS in einem Docker-Container.
Funktioniert im Heimnetz auch alles super. Aber ich würde selbstverständlich gerne auch von Unterwegs darauf zugreifen können.

Leider verweigert der Fhem-Server dann immer den Zugriff. Im Log steht in der Regel sowas wie:
"Connection refused from the non-local address xxx.xxx.xxx.xxx:36412, as there is no working allowed instance defined for it"

Wie kann ich das ändern und den Server auch von Außerhalb erreichen?
Selbstverständlich ist das NAS von außen über eine IP-Weiterleitung erreichbar und der Zugriff auf das NAS selbst funktioniert auch.

[rudolfkoenig]

FHEM verhindert per Voreinstellung den Zugriff aus dem "wilden Internet", wenn keine Zugangssicherung (vulgo Passwort) gesetzt ist, damit wir nicht in den Schlagzeilen der Medien landen.

Zugangssicherung ist bisher nur mit dem allowed Modul moeglich: man muss eine anlegen, sie fuer die freizugebende FHEMWEB/telnet/etc Instanz zustaendig erklaeren (validFor), und Benutzer/Passwort setzen (set allowed basicAuth username passwort)

Eigentlich steht das auch auf dem "homepage", wenn man FHEMWEB aufruft.

[Beta-User]

Ergänzend noch: Das mit dem einfachen Port-Forwarding ist keine gute Idee, das diskutieren wir hier mit steter Regelmäßigkeit...
(wie hieß noch gleich der scanner, mit dem man erreichbare FHEM-Installationen finden kann...?)

Das mit dem Passwort ist ein Minimalschutz. Die einfachste, halbwegs sichere Variante ist die Einrichtung eines vpn-Dienstes, alternativ ein abgesicherter reverseProxy (mit Schutz gegen brutforce-Attacken usw.).

[Wernieman]

Und auch eine NAS sollte nicht komplett aus dem Netz erreichbar sein. Bei den letzten Sicherheitslücken wurde innerhalb kürzester zeit nach anfälligen NAS-Systemen automatisch gesucht .... (Egal welcher Hersteller!)

Ansonsten kann ich Beta-User nur zustimmen. Wurde schon genug diskutiert incl. Lösungsmöglichkeiten.

[MadMax-FHEM]

Leider verweigert der Fhem-Server dann immer den Zugriff. Im Log steht in der Regel sowas wie:
"Connection refused from the non-local address xxx.xxx.xxx.xxx:36412, as there is no working allowed instance defined for it"

Wie Rudi geschrieben hat und in deiner zitierten Meldung EXAKT drin steht

Aber ich muss Beta-User zustimmen...

In fhem ist nichts gegen "brut force" PW-Scripts eingebaut (gut würde dein Log "fluten" und dich erkennen lassen)...
...mindestens dann noch sowas wie fail2ban...

Aber bis du das einrichtest und ein allowed und dann nat. auch https (weil sonst sind user/pw ja "plain" auf der Leitung), hast du auf jeden Fall ein vpn eingerichtet.

Mit piVPN dauert das keine 10min (beim 2ten Mal nur noch keine 5min   )...

Gruß, Joachim

[MarkoP]

Hallo zusammen,

Natürlich sind die Einwürfe berechtigt, doch wenn ich vor lauter Panik jedes Gerät dieser Art vollkommen abschotte, verwehre ich mir ja selbst den Großteil der Funktionen bzw. des Nutzens dieser Geräte. Es muss also eine Möglichkeit geben die Geräte (egal ob FHem oder NAS allgemein, oder sonstwas) halbwegs Sicher im Netz offen zu betreiben.

VPN ist leider keine Alternative, da ich beispielsweise auf meinem Firmen-PC keine VPN-Sortware installieren kann und der vorhandene Microsoft-Dienst nicht kompatible mit dem des NAS ist. Ginge also nur auf Geräten auf denen ich Installations-Rechte besitze was wie eben gesagt nicht überall möglich ist. Erschwerend kommt noch hinzu, dass ich meiner Freundin niemals verständlich gemacht bekomme, dass sie erstmal einen VPN-Tunnel aufbauen muss ehe sie das was sie eigentlich will tun kann.

@rudolfkoenig
Werde das mit dem allowed wohl ausprobieren müssen. Ich verstehe allerdings noch nicht was es mit folgender Zeile auf sich hat:
"attr allowedWEB validFor WEB,WEBphone,WEBtablet"
Bedeutet das, dass über das Web, über Handy und Tablets zugegriffen werden kann? Sprich wenn ich die letzten beiden weglasse nur noch über einen Webbrowser oder handelt es sich dabei um Devicenamen?
Weiterhin habe ich nichts dazu gefunden wie die Anmeldung funktioniert. Muss ich die url um username und passwort ergänzen oder kommt eine separate Eingabeaufforderung nach dem Aufruf?
Und zu guter Letzt die Frage ob die Autentifizierung dann nur für externe Zugriffe gillt oder muss ich dann auch bei Aufrufen aus dem Heimnetz die Autentifizierung durchführen?

[MadMax-FHEM]

Hallo zusammen,

Natürlich sind die Einwürfe berechtigt, doch wenn ich vor lauter Panik jedes Gerät dieser Art vollkommen abschotte, verwehre ich mir ja selbst den Großteil der Funktionen bzw. des Nutzens dieser Geräte. Es muss also eine Möglichkeit geben die Geräte (egal ob FHem oder NAS allgemein, oder sonstwas) halbwegs Sicher im Netz offen zu betreiben.

VPN ist leider keine Alternative, da ich beispielsweise auf meinem Firmen-PC keine VPN-Sortware installieren kann und der vorhandene Microsoft-Dienst nicht kompatible mit dem des NAS ist. Ginge also nur auf Geräten auf denen ich Installations-Rechte besitze was wie eben gesagt nicht überall möglich ist. Erschwerend kommt noch hinzu, dass ich meiner Freundin niemals verständlich gemacht bekomme, dass sie erstmal einen VPN-Tunnel aufbauen muss ehe sie das was sie eigentlich will tun kann.

Dein Netz, deine Rechner/Geräte, ...

Wir können nur hinweisen: getan! Haken dran...

@rudolfkoenig
Werde das mit dem allowed wohl ausprobieren müssen. Ich verstehe allerdings noch nicht was es mit folgender Zeile auf sich hat:
"attr allowedWEB validFor WEB,WEBphone,WEBtablet"
Bedeutet das, dass über das Web, über Handy und Tablets zugegriffen werden kann? Sprich wenn ich die letzten beiden weglasse nur noch über einen Webbrowser oder handelt es sich dabei um Devicenamen?

Bin zwar nicht Rudi, versuch's aber trotzdem

Es sind die DeviceNamen der entsprechenden FHEMWEB-Instanzen für die dieses allowed-Device "zuständig" sein soll...

Weiterhin habe ich nichts dazu gefunden wie die Anmeldung funktioniert. Muss ich die url um username und passwort ergänzen oder kommt eine separate Eingabeaufforderung nach dem Aufruf?
Und zu guter Letzt die Frage ob die Autentifizierung dann nur für externe Zugriffe gillt oder muss ich dann auch bei Aufrufen aus dem Heimnetz die Autentifizierung durchführen?

Je nachdem...

Also entweder bei Zugriffen User/PW "mitgeben" oder beim "Eintippen" in einen Browser kommt eben ein Anmelde-Dialog...
...bzw. nichts mehr, wenn im Browser "gespeichert"...

Gruß, Joachim

[rudolfkoenig]

Bedeutet das, dass über das Web, über Handy und Tablets zugegriffen werden kann?

Wenn FHEM vor Version 5.9 installiert wurde, dann wurden 3 FHEMWEB Instanzen angelegt, die mit Attribut auf das jeweilige Bildschirmtyp optimiert sind. Seit 5.9 wird nur eine FHEMWEB Instanz installiert, weil die Voreinstellung (style f18) die Endgeraete erkennt, und das Layout anpasst
=> Ich empfehle WEBphone und WEBtablet zu loeschen, und (falls gesetzt) auch das WEB Attribut stylesheetPrefix.

Muss ich die url um username und passwort ergänzen oder kommt eine separate Eingabeaufforderung nach dem Aufruf?

Es wird ein kleines Browser-Fenster angezeigt, wo nach Benutzer/Passwort gefragt wird. Die Daten werden im Browser gespeichert, solange der Browser offen ist.

Und zu guter Letzt die Frage ob die Autentifizierung dann nur für externe Zugriffe gillt oder muss ich dann auch bei Aufrufen aus dem Heimnetz die Autentifizierung durchführen?

Ja, sie gilt fuer alle.
Falls man zuhause kein Passwort angeben will, dann legt man eine zweite FHEMWEB Instanz an (ohne validFor Zuweisung). Es gibt auch noch viele andere Wege, das Problem zu loesen (z.Bsp. Apache/NGinx vorschalten), diese ist aber mAn am einfachsten zu beschreiben.
Achtung: der Portnummer muss bei den unterschiedlichen FHEMWEB Instanzen unterschiedlich sein, global bitte auch nicht vergessen, und ich wuerde auch das HTTPS Attribut setzen.

[Wernieman]

(z.Bsp. Apache/NGinx vorschalten)

Genau das würde ich bei Problemen aus Firmennetzen einrichten. Dann kann dieses auch sauber über Port 443 und "richtigem" SSL erledigt werden. Wenn mann dann noch den Passwortschutz von apache/nginx verwendet, ist man relativ sicher

Es muss also eine Möglichkeit geben die Geräte (egal ob FHem oder NAS allgemein, oder sonstwas) halbwegs Sicher im Netz offen zu betreiben.

In der Werbung wird einem immer erzählt, wie einfach das ist. Für "Russische Hacker" (*) macht man dieses erst recht. Es geht auch nicht einfach um das zerschießen der eigenen Instanz, schlimmer ist, wenn dieser Rechner (Läuft 24*7) als Hop für weitere Angriffe verwendet wird. wer will schon die Polizi im hause haben?

(*) Bitte als Synonym verwendet. Aternativ NSA, China-Hacker ..... Liste Endlos weiterführen ...

[rudolfkoenig]

Dann kann dieses auch sauber über Port 443 und "richtigem" SSL erledigt werden. Wenn mann dann noch den Passwortschutz von apache/nginx verwendet, ist man relativ sicher

Ich will FHEMWEB jetzt nicht als das bessere Apache/Nginx hinstellen, aber wird SSL nicht in beiden Faellen von der gleichen Bibliothek erledigt? An dieser Stelle sollte FHEM kaum was falsch machen, weil es kaum was macht. Und wenn jemand weiss, was genau .htpasswd von apache besser macht als FHEMWEB/allowed, dann bin ich daran dringend interessiert.

Mit Apache hat man etliche getestete Loesungen, um Angriffe abzuwehren, aber diese muessen erst aktiviert werden, und ich habe meinen Zweifel, ob ein Laie das einfach so kann. Ich wuerde eher von den Standard Ports (80/443) abraten (egal ob FHEMWEB oder Apache), damit erledigt man einfach die Mehrheit der Angriffsversuche.

[Wernieman]

Weshalb ich mittlerweile nginx eher empfehle. Der ist im Proxy-Bereich viel Einfacher als apache.

Ich weiß, das ich mit "richtigem SSL" sehr vorschnell war. Eigentlich ging es mir darum, das bei apache/nginx die Software schon von Diversen Leuten Sicherheitstechnisch geprüft wurde. Das ist jetzt keine Kritik an FHEM, aber ich glaube nicht, das dort eine Prüfung stattgefunden hat ...

Und ja, auch apache/nginx haben Ihre Configurations-Fails. Trotzdem besser, als FHEM "nackt" ins Netz zu stellen. Bezülich Port 443: Viele Firmennetze erlauben ausgehenden http/https-Verbindungen nur auf Standardports ... also muß man Standard fahren.

[Beta-User]

Ich will FHEMWEB jetzt nicht als das bessere...

Vorab mal Danke für diese Hinweise!

Irgendwie hatte ich schon immer unterschwellig das Gefühl, dass der Verweis auf externe Methoden irgendeinen Haken haben muß...

Zum Eigentlichen:
Wenn man jetzt so ein Anliegen hat wie der TE, dann wäre nach meinem vorläufigen Bild das Vorgehen in etwa so:

Man legt einfach mehrere Zugänge an:
- Für die "Frau" eine SSL+allowed-abgesicherte eigene FHEMWEB-Instanz auf einem "abgelegenen" Port. Optimalerweise dort nur ausgewählte Kommandos zulassen, bestenfalls diverse set-Befehle, v.a. keine define zulassen und auch keine Detailansichten; dazu nur ausgewählte Räume.

- Für den FHEM-"Fulluser"-Zugang ggf. wieder eine eigene SSL+allowed-abgesicherte  Instanz, aber (bei Bedarf) ohne die Restriktionen hinsichtlich Räumen, Befehlen und Detailansichten, auch hier wieder gerne einen anderen als "Standard"-Port (sofern möglich, z.B. wegen fehlender Restriktionen des Firmennetzwerks)

- für lokale Zwecke dann einen "vollen" Zugang, tendenziell schon auch mit Passwortschutz, aber SSL wäre nicht zwingend (?)? Damit hätte man (sofern eingerichtet) auch einen externen admin-Zugang über vpn, das erlaubt darüber hinaus auch Zugriff auf den Rechner an sich, z.b. zur OS-Pflege.

Meine Fragen:
- wie realisiert man bei einer "FHEM-only"-Lösung sowas wie fail2ban?
- Paßt das ansonsten, oder übersehe ich was wichtiges?

(Mit SSL muß ich mich auch mal beschäftigen, bisher war vpn (+Telegram für user-Steuerung durch die family) ausreichend; irgendwie habe ich aber keine "stringente Anleitung" in Erinnerung)

Danke vorab,
Beta-User

[rudolfkoenig]

Das ist jetzt keine Kritik an FHEM, aber ich glaube nicht, das dort eine Prüfung stattgefunden hat ...

Das ist richtig. Die meisten Sicherheitsloecher existieren wegen einer fehlerhaften Implementierung, und nicht wegen falscher Theorie.

Wenn man jetzt so ein Anliegen hat wie der TE, dann wäre nach meinem vorläufigen Bild das Vorgehen in etwa so:

Korrekt.

Man muss aber auch die Nachteile kennen:
- fail2ban koennte man zwar mit FHEM-Mitteln bauen, aber bevor jemand dafuer ein Modul baut, ist der Weg ueber apache einfacher
- mit apache reicht es fuer die beiden FHEMWEB Instanzen nur ein Port im Firewall zu oeffnen (FHEM Stichwort webname).

FHEM bietet eine bestimmte Stufe an Absicherung. Wenn man mehr will, dann muss man Apache/VPN/etc bemuehen, was aber mehr Wissen erfordert.
Die Frage ist, welche Stufe betrachtet man als ausreichend. HTTP ohne Passwort-Schutz ist es sicher nicht.

Apache steht hier als Synonym fuer externen Web-Browser, also auch nginx, etc.

[Beta-User]

Korrekt.

Man muss aber auch die Nachteile kennen:
- fail2ban koennte man zwar mit FHEM-Mitteln bauen, aber bevor jemand dafuer ein Modul baut, ist der Weg ueber apache einfacher
- mit apache reicht es fuer die beiden FHEMWEB Instanzen nur ein Port im Firewall zu oeffnen (FHEM Stichwort webname).

Danke für die Rückmeldung.

Das mit "fail2ban" war auch "nur" ein erstes Stichwort, letztlich geht's darum, mitzubekommen, wenn was schräg ist und ggf. Gegenmaßnahmen ergreifen zu können.

Nur als Ideen die evtl. zur Erreichung dieses Ziels ohne allzuviel Aufand umsetzbar wären (?):
- Viele gängigen Anmelde-Prozeduren erhöhen einfach bei jedem Fehlversuch die Zeit bis zum nächsten zulässigen Versuch und/oder riegeln nach x Fehlversuchen ganz ab.
- Teilaspekt daraus: Ein Zähler für eventuelle Fehlversuche? (Rückgesetzt bei Erfolg, dann könnte man wenigstens loggen oder Eventhandler andocken?)
- "set <FHEMWEB-Device> disable" gibt's in der commandref nicht (ok, kann Schwierigkeiten machen, wenn man die letzte Tür zuschlägt... Vielleicht wäre was denkbar, was nur auf nicht lokale IP's ginge?)

(Ich gehöre z.B. auch zu dem Nutzerkreis, der sich eigentlich nicht auch noch mit apache, Zertifikatsverwaltung usw. belasten will).

Das mit der Begrenzung der Zahl der weiterzuleitenden Ports leuchtet einerseits ein, andererseits ist halt die Frage, was letztlich übersichtlicher ist, ohne dass eine größere Sicherheitseinbuße damit verbunden ist. Wer noch mehr Dienste als FHEM hat, wird tendenziell wohl mit der "großen Lösung" nginx einfacher fahren, aber eben auch eher wissen, was er tut, der "kleine FHEM-Admin" wird froh sein, dass er nur eine Stelle (zzgl. des Routers) hat, an der er ansetzen muß und nicht zu sehr mit Linux-Konsole "behelligt" wird...

[rudolfkoenig]

Sehe ich auch so bis auf Zertifikatsverwaltung: der Aufwand ist in beiden Faellen identisch.