FHEM über Internet erreichen

Begonnen von is2late, 07 Juli 2020, 18:28:15

Vorheriges Thema - Nächstes Thema

swsmily

Zitat von: Icinger am 08 Juli 2020, 04:50:35
Gerade in letzter Zeit ist es dank Wireguard ja fast ohne Konfigurationsaufwand möglich, ein VPN aufzubauen.
Du kannst dir einen Button in den System-Shortcuts anlegen (Das Menü zum runterziehen am Handy, über den Notifications)

Ahhh okay, also eine extra App und nicht das in Android eingebaute VPN-Nutzen? Oder gibts auch für das eingebaute VPN im Android eine Möglichkeit dieses per Widget oder sogar über Tasker/Automagic zu aktivieren?



Zitat von: MadMax-FHEM am 07 Juli 2020, 23:08:31
Ok, dann genauer: einfacher und SICHER!

Weil klar Port aufreißen und einfach "jeden" drauf lassen ist nat. einfach...
...aber bis das dann auch SICHER eingerichtet ist inkl. https (ohne die übliche Browser-Zertifikatsmeldung etc.)...
...und dann auch dabei KEINEN "FEHLER" gemacht zu haben...

Da sage ich dennoch noch mal: vpn ist einfacher... ;)

Entweder im Router (Fritzbox o.ä. hat ja mittlerweile fast jeder), dann meist ein Haken irgendwo, Konfig-Datei für Rechner/Handy runterladen und in die entspr. App einbinden: fertig...

Und auch ohne dass der Router das kann: piVPN, dauert 5min zu installieren, dann auch "Client-Zertifikate" anlegen (ein Befehl), Konfiguration aufs Handy -> fertig...

Und: kann sogar auf dem fhem Server (sofern PI) laufen...

Und wenn man dann noch mehr Sicherheit will: fail2ban...

Für openvpn gibt es fertige Profile...

EDIT: oder in Kurzform ;)
Gruß, Joachim
Zitat von: amenomade am 07 Juli 2020, 23:08:12
Es ist auf jeden Fall einfacher, ein sicheres VPN einzurichten, als eine sichere Portfreigabe zu FHEM, die dein ganzes Hausnetzwerk nicht gefährdet
Volle Zustimmung! Einfach ist ne Portfreigabe, kompliziert ist das Absichern, das stimmt!

Ich hab VPN über die Fritzbox am laufen, Zugriff übers Handy ins gesamte Netz funktioniert damit super.
Aber ich habe auch eine Porfreigabe mit HTTPS, FHEM-Passwortschutz und nicht Standard-Port aktiv. Bis jetzt (toi toi toi) kein unberechtiger Zugriff (nach zweitem fehlerhaften Loginversuch innerhalb einer halben Std. sendet FHEM eine Benachrichtung per Telegram - diese kam bisher nur durch mich selbst, wenn ich mich 2 mal beim Passwort vertippt habe).


MadMax-FHEM

Wenn vpn "super funktioniert"...
...warum machst du dann den fhem Port nicht (besser) zu!?

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

swsmily

Zitat von: MadMax-FHEM am 08 Juli 2020, 23:04:49
Wenn vpn "super funktioniert"...
...warum machst du dann den fhem Port nicht (besser) zu!?

Gruß, Joachim


  • schnellerer Zugriff via Browser vom Handy
  • über Tasker automatisierte Daten und Befehle, die von extern an FHEM gesendet werden.

VPN ist eben nur bei Bedarf, und dann durch die Einstellungs-Menüs hangeln, bis ich endlich die VPN-Verbindung aufbauen kann.
Mit "Super" meinte ich nur, dass eben dann der Datenverkehr über Zuhause läuft, und ich Zuhause auf alle Geräte direkt zugreifen kann. Ich bin damit also remote trotzdem im Heimnetz.  ;)

MadMax-FHEM

Zitat von: swsmily am 08 Juli 2020, 23:07:59
VPN ist eben nur bei Bedarf, und dann durch die Einstellungs-Menüs hangeln, bis ich endlich die VPN-Verbindung aufbauen kann.

Hmmm, ich hab die openVPN-App...
Die öffne ich und klicke auf verbinden -> fertig...

Ich habe aber auch kein FB-vpn sondern eben piVPN.

1x auf einem extra PI
und 1x auf dem fhem PI (bei meiner Freundin, da sollen nicht so viele "Käfer" rumstehen ;) Ich will/muss [bin froh, dass ich kann] ab und an mal was "nachsehen" ;)  )...

2 Löcher sind halt 2 Löcher... ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

swsmily

Klar, am liebsten wäre es mir auch FHEM von außen nicht erreichbar zu haben.

Bisher fehlt mir eben die Möglichkeit komfortabel VPN aufzubauen um auf FHEM zuzugreifen. Dank des Threads scheint es ja Möglichkeiten zu geben, damit muss ich mich erstmal auseinander setzen.
Das nächste Problem sind die automatisierten Befehle die regelmäßg an FHEM gesendet werden. Da ist ein kurzer HTTPS-Befehl an eine DynDNS-Adresse leichter realisierbar, als dass erst eine VPN-Verbindung aufgebaut wird, der Befehl gesendet wird, VPN wieder abgebaut wird.

Bis jetzt bin ich von auch im Forum gemeldeten "Hack-Versuchen" verschont gelieben. Fail2Ban ist ebenso eingerichtet, sogar so, dass ich über Telegram IPs sperren kann. Meldungen kommen nach dem zweiten fehlgeschlagenen Login-Versuch. Damit denke ich bin ich schon auf der relativ sichern Seite, dass selbst durch die Portfreigabe keine große Gefahr besteht. 100% Sicherheit gibt es nicht - das ist mir klar. Jede Öffnung nach außen ist ein möglicher Angriffspunkt.

Chris46

Mit iOS gibt es die Möglichkeit mit ,,VPN on demand", damit verbindet es den VPN automatisch bei Zugriffen auf bestimmte Netze. Gibt es sowas bei Android nicht?

JudgeDredd

Zitat von: Chris46damit verbindet es den VPN automatisch bei Zugriffen
Wohin baut er denn den Tunnel auf ?

Zitat von: Chris46Gibt es sowas bei Android nicht?
Meines Wissens nach geht das bei Android nur mit einer (festen)IP. Da er ja ansonsten die DNS Anfrage zum auflösen der VPN-URL ins unsichere Netz schicken muss.
Router: Eigenbau (pfSense)
FHEM: Proxmox (DELL R720) | Debian 12 (VM)

Chris46

Zur Fritzbox.

Für alle Anfragen zu netzwerkname.fritz.box (ist konfigurierbar) wird bei mir eine VPN Verbindung aufgebaut.

FHEM-User22

Hallo CoolTux,

Zitat von: CoolTux am 08 Juli 2020, 19:36:27
OPNSense ist eine eigene Distribution mit OpenBSD und kommt als fertiges CD Image.
Das geht leider nicht als Anwendung zu installieren.

Ok, verstehe. Ich habe noch einen anderen vServer, der es zulässt, ein eigenes Image meiner Wahl zu installieren. Würde ich es damit hinbekommen können?

Dankeschön
FHEM auf Raspberry Pi und Proxmox und... und.... und....

JudgeDredd

Zitat von: Chris46netzwerkname.fritz.box (ist konfigurierbar) wird bei mir eine VPN Verbindung aufgebaut.
Das ist schon klar, aber dazu muss ja zuerst eine DNS Anfrage in ein potentiell unsicheres Netz geschickt werden.
Router: Eigenbau (pfSense)
FHEM: Proxmox (DELL R720) | Debian 12 (VM)

is2late

Zitatwarum nutzt du nicht die VPN-Verbindung der Fritzbox?

Das bekomme ich nicht hin. VPN ist eingerichtet auf der FB, aber eine Verbindung zum Handy/Tablet klappt nicht. Läuft das über MyFritz? https://avm.de/service/vpn/tipps-tricks/vpn-verbindung-zur-fritzbox-unter-android-einrichten/
Pi4, Tahoma Jalousien, Hue, Echo, Sonos, Lupusec XT3, FritzBox

Beta-User

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:
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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

MadMax-FHEM

Kurze (vielleicht unnötige, weil evtl. mit obigen Mechanismen bereits ausreichend eingeschränkt) Anmerkung: (besser) KEIN sudo für den User fhem!

Wie geschrieben: bin nicht sicher was über die genannten Mechanismen schon eingeschränkt ist ABER: der User fhem bzw. mittels fhem können eben auch System-Aufrufe abgesetzt werden!

Häufig "höre" ich bei "solchen Diskussionen": ach naja, dann kann "der" halt meine Lichter schalten -> so what...

Ich wollte nur diesen Irrtum deutlich machen...

Ansonsten: sehr schöne Beschreibung! (ich bleibe trotzdem bei vpn ;)  )...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Hmm, also:

"Im Prinzip" hast du völlig recht, dass man auch die Rechte des Users fhem nicht aus den Augen verlieren (oder (vermutlich) besser: sich nie mit der Erweiterung bzw. Passwortvergabe für diesen User beschäftigen) sollte. (Leider reißen da viele direkt die großen Scheunentore auf, v.a. weil sie meinen, dass man einen ssh-Zugang für fhem braucht, oder weil sonst irgendeine (Youtube-) "Anleitung" igendwelche Spielereien vorstellt, die man "unbedingt" braucht und dabei eben die eine oder andere "Kleinigkeit am Rande" ausläßt?!?)

Den Hinweis, dass der Umfang des möglichen Schadens eben auch von der Berechtigung des Users auf diesem UND ANDEREN SYSTEMEN abhängt, fehlt aber definitiv (ich will hier keine "geladenen Waffen" zeigen, aber die, die etwas Ahnung haben, werden wohl nicht viel Phantasie brauchen, um eigene zu basteln...).
Auch das Thema Passwortstärke könnte man erwähnen...



Mein "gefühltes Sicherheitsempfinden" (Achtung: belesener Laie!) meint im Moment, dass eine wie beschrieben auf das notwendigste beschränkte und mit einem starken Passwort geschütze SSL-FHEMWEB-Instanz vermutlich derzeit sogar die sicherste (halbwegs einfache) Variante für "noobs" wäre (ganz einfach ist es nicht, aber man lernt dabei eben auch wenigstens ein paar Grundlagen zu FHEM "nebenbei").

Auch die Anleitungen für die Alternative, einen reverse proxy dazwischenzuschalten, klammern in der Regel das Thema aus, dass man das eigentlich nicht (unbedingt) für eine administrative Instanz tun sollte - für diese Art Aufgabe finde ich die (bewußte) VPN-Variante auch nach wie vor die beste Lösung, man hat damit aber eben auch noch weitere Möglichkeiten, die weit über die Administration (+++, s.o.) via FHEMWEB rausgehen. Von daher ist gutes Portforwarding (s.o.) evtl. sogar für noobs die "bessere Variante" und gegenüber einer miserabel abgesicherten vpn-Verbindung vorzugswürdig?!?

Mal wieder ein unübersichtliches Feld...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

MadMax-FHEM

#29
Zitat von: Beta-User am 10 Juli 2020, 09:20:36
... gegenüber einer miserabel abgesicherten vpn-Verbindung vorzugswürdig?!?

Naja, (mittleweile) muss man schon (fast) absichtlich etwas tun, um eine vpn-Verbidung NICHT "abgesichert" zu haben:

- absichtlich sehr kurze Schlüssellänge (weil bei einfach ok, ok, ok, ... bei "Installation" von z.B. piVPN schon ausreichend gewählt wird)

- absichtlich einen vpnClient, der kurze (schlechte) Schlüssel zulässt (also selbst wenn der erste Schritt "schlecht" gemacht wurde lassen "moderne" Apps das gar nicht zu)

- einfach wild seine vpn-Schlüsseldateien "rumwerfen"

- vpn-Schlüsseldateien nicht "verwerfen", von Geräten die "verschwunden" sind bzw. wo Schlüssel wissend "abhanden" gekommen sind...



Zitat von: Beta-User am 10 Juli 2020, 09:20:36
Mal wieder ein unübersichtliches Feld...

Tja aber so ist es halt...

Sicherheit bedeutet Aufwand und "Umstände" (u.U. auch für "erlaubte" Nutzer bei der Nutzung) mind. bei der Einrichtung...
...und war schon zu "Burgbauzeiten" so ;)

Was bringt die stärkste Burg mit einem großen Graben und einem massiven Tor, wenn man dann den "Abfluss" vergisst ;)
Oder noch schlimmer einen "Bequemlichkeits-Eingang" irgendwo versteckt...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)