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.

[hexenmeister]

Man muss nicht allzusehr tief eintauchen, um eine einfache nginx Installation herzurichten. Im einfachsten Fall nimmt man ein fertiges Docker-Container.
Man müsste 'nur':
- docker installieren
- docker-compose installieren
- optional Porttainer (natürlich auch im Container) starten, ab dann hätte man GUI für die Container-Verwaltung
- Image von linuxserver/letsencrypt nehmen (ist nicht ganz nach Docker-Art, da gleich mehreres drin, aber recht einfach einzurichten)

Code Auswählen Erweitern


version: "2"
services:
  letsencrypt:
    image: linuxserver/letsencrypt
    container_name: letsencrypt
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
      - URL=<eigene URL>
      - SUBDOMAINS= #www,
      - VALIDATION=http
      - DNSPLUGIN=cloudflare #optional
      - DUCKDNSTOKEN=<token> #optional
      - EMAIL=letsencrypt@s6z.de #optional
      - DHLEVEL=2048 #optional, (default=2048, can be set to 1024 or 4096)
      - ONLY_SUBDOMAINS=false #optional
      #- EXTRA_DOMAINS= #<extradomains> #optional
      - STAGING=false #optional
    volumes:
      - ./data/config:/config
    ports:
      - 443:443
      - 80:80   # for redirect to 443
    restart: unless-stopped

Konfiguration ist hier beschrieben: https://github.com/linuxserver/docker-letsencrypt/blob/master/README.md
Man müsste noch einmalig .htpasswd, letsencrypt einstellen und für FHEM Proxy-Konfig hintelegen (es gibt bereits fertige Beispiele für diverse Software, für FHEM leider nicht, kann man aber analog aufbauen).
Nach einer Stunden einmaligen Aufwand hat man ein relativ gut abgesichertes System. Nimmt man noch Image von containrrr/watchtower dazu, dann wird das auch noch automatisch aktualisiert. Man macht sich natürlich ein Stück weit von dem Mainternern der Docker-Container abhängig.

[Wernieman]

Warum nimmst Du für letencrypt den Container von linuxserver anstatt den "offiziellen" von certbot?

[MarkoP]

Wow, ehrlich gesagt mir schwirrt gerade der Kopf und ich komme mir vor wie ein Chinese auf dem Schweizer Wochenmarkt.

Klar sollte man nichts ungeschützt ins Netz stellen, doch ist das alles wirklich so nötig. Mag sein das ich vielleicht noch etwas naiv bin, aber ich habe da noch das Vertrauen in die Welt, dass da weniger passiert als immer prophezeit wird. Und ich habe ja keine hochsensiblen Geheimdaten auf den Geräten.
Man kann es ja auch so sehen, je besser man etwas schützt, desto intensiver wird man zur Zielscheibe, da etwas wichtiges dahinter vermutet wird. Ich habe bisher grundsätzlich alle Portnummern und Standardzugänge (wie zb. admin etc.) geändert. Das hat bisher vollkommen ausgereicht.

Werde mir aber mal alles in Ruhe anschauen und zu den Begrifflichkeiten recherchieren. Aber bisher denke ich reicht eine zweite Fhemweb-Instanz, die geschützt ist, vollkommen aus. Melde mich wenn ich alles recherchiert und verstanden habe, was gewiss einiges an Zeit dauern kann, da ich Anfänger bin.

Für weitere Informationen zu dem Thema bin ich aber grundsätzlich offen und immer interessiert. Schließlich kann man nie genug Wissen und Lernen. 

[MarkoP]

Wow, ehrlich gesagt mir schwirrt gerade der Kopf und ich komme mir vor wie ein Chinese auf dem Schweizer Wochenmarkt.

Klar sollte man nichts ungeschützt ins Netz stellen, doch ist das alles wirklich so nötig. Mag sein das ich vielleicht noch etwas naiv bin, aber ich habe da noch das Vertrauen in die Welt, dass da weniger passiert als immer prophezeit wird. Und ich habe ja keine hochsensiblen Geheimdaten auf den Geräten.
Man kann es ja auch so sehen, je besser man etwas schützt, desto intensiver wird man zur Zielscheibe, da etwas wichtiges dahinter vermutet wird. Ich habe bisher grundsätzlich alle Portnummern und Standardzugänge (wie zb. admin etc.) geändert. Das hat bisher vollkommen ausgereicht.

Werde mir aber mal alles in Ruhe anschauen und zu den Begrifflichkeiten recherchieren. Aber bisher denke ich reicht eine zweite Fhemweb-Instanz, die geschützt ist, vollkommen aus. Melde mich wenn ich alles recherchiert und verstanden habe, was gewiss einiges an Zeit dauern kann, da ich Anfänger bin.

Für weitere Informationen zu dem Thema bin ich aber grundsätzlich offen und immer interessiert. Schließlich kann man nie genug Wissen und Lernen. 

P.S.

... der Portnummer muss bei den unterschiedlichen FHEMWEB Instanzen unterschiedlich sein, global bitte auch nicht vergessen, ...

Wie müsste ich da vorgehen? Ich kann im Docker-Container lediglich diverse Portweiterleitungen angeben, aber habe soweit ich weiß keine Möglichkeit diese einer bestimmten Fhemweb-Instanz zuzuordnen. Oder muss das innerhalb des Fhem-Servers geschehen, so dass dieser einfach auf mehreren Ports "lauscht"?
Was genau meinst du mit "global auch nicht vergessen"?

[Wernieman]

Meines Wissens sind aktuell 4 Milliarden Menschen Online. Im schlechtesten Falle hast Du also 4Milliarden "Gegner" ...

Es geht übrigens nicht um "geheime Daten" auf den Geräten. Solche Geräte (sind 24*7 online) werden gerne benutzt, um weitere Geräte anzugreifen. In deren Logfiles steht dann nicht die IP-Adresse vom Angreifer, sondern von Dir! Willst Du "netten Besuch" bekommen?

Kenne übrigens einen Fall, wo genau so etwas passiert ist ....

[CoolTux]

Das ist leider das was die wenigsten Verstehen. Mir persönlich geht es nicht darum das andere ihre eigene Umgebung für Hacker frei geben, das ist mir egal. Mir geht es darum das ich dann von diesen gehakten Umgebungen angegriffen werde. Und da werde ich Grantig.

[Wernieman]

Nur mal als vergleichendes Beispiel:
Wenn ich einen Wagen Stehenlassen mit steckendem Zündschlüssel und "ein Kind" klaut den Wagen, baut einen Unfall ..... dann bin ich mitschuldig.

Vielleicht wird es dann verstanden ...

(Sorry das ich gleich ein heftiges Beispiel nehme, aber manchmal muß man Plakativ sein .... leider ...)

[hexenmeister]

Warum nimmst Du für letencrypt den Container von linuxserver anstatt den "offiziellen" von certbot?

Faulheit
Dieser ist so schön vorkonfiguriert. Rundum sorglos Paket.
Irgendwann baue ich das um, aber vorher muss ich mich tiefer in die Materie einlesen.

[Wernieman]

Sag bhescheid ... habe es hier (in der Firma) laufen, allerdings mit dns-Zertifizierung