FHEM auf gehostetem Server beim Provider möglich?

[fstefan1960]

Hallo,

hat schon einmal jemand es geschafft, FHEM lauffähig auf einem virtuellen Mietserver im Internet zu installieren? Natürlich kann ich dort nicht meine Heizung steuern, aber für div zeit- und eventgesteuerte Reaktionen wäre mir FHEM da ein geeigneter Webserver ... Installation scheint genauso zu laufen wie auf einem lokalen Server, aber ein Aufruf von www.meinedomain.de:8083 bringt schlichtweg nur einen Fehler ...

[CoolTux]

bringt schlichtweg nur einen Fehler ...

... der da lautet?!

[MadMax-FHEM]

Natürlich kann ich dort nicht meine Heizung steuern

und auch sonst nichts was bei mir zuhause (ONLY) ist.
Und Cloudsachen mag ich eh nicht so...

Daher kam ich noch nie auf so eine Idee...

Installation scheint genauso zu laufen wie auf einem lokalen Server, aber ein Aufruf von www.meinedomain.de:8083 bringt schlichtweg nur einen Fehler ...

Aha, sehr aufschlussreich. Irgendein Fehler ist natürlich klar was das ist...

Was für ein Fehler kommt denn?
Wie sind überhaupt die IP-Settings von fhem@Cloud?

Evtl. ein allowed-Device mit User/Passwort etc.

Aber es kommt halt drauf an wie das IP-Setup "dort" ist...

Gruß, Joachim

[CoolTux]

Die IP wird keine private Adresse sein und somit darf er nicht zugreifen.
Aber auf das Log wird er sicherlich zugreifen können.

[Wernieman]

Es könnte aber auch sein, das der Hoster nur "bestimmte" Ports erlaubt .... (es gibt wirklich welche).

Allerdings noch wichtiger bei so etwas: An die Sicherheit denken! Die VM steht ohne "Schutz" im Netz

[Morgennebel]

hat schon einmal jemand es geschafft, FHEM lauffähig auf einem virtuellen Mietserver im Internet zu installieren?

Manche Ideen sind so abwegig, daß man sie am besten sofort begraben sollte.

Sicherheit wurde schon angesprochen. Wie soll denn Dein FHEM-Cloudserver Deine IO-Devices ansprechen? Machst Du dann Deinen Router zum Internet auf? Ohne SSL, ohne Paßwörter?

Bitte begrab das. Tief. Und setz nen schönen Granitsockel drauf...

Ciao, -MN

[M.Schulze]

Hallo,

hat schon einmal jemand es geschafft, FHEM lauffähig auf einem virtuellen Mietserver im Internet zu installieren? Natürlich kann ich dort nicht meine Heizung steuern, aber für div zeit- und eventgesteuerte Reaktionen wäre mir FHEM da ein geeigneter Webserver ... Installation scheint genauso zu laufen wie auf einem lokalen Server, aber ein Aufruf von www.meinedomain.de:8083 bringt schlichtweg nur einen Fehler ...

Ja, ich hatte so ein System 2 Jahre Produktiv am laufen. Sogar für mehrere Haushalte auf einem Server. Aber da sollte man schon mit Docker umgehen können und einen Reverse Proxy konfigurieren können. War auch verschlüsselt bis zum Reverse Proxy.  Und du brauchst taugliche IO-Devices.

MFG

[fstefan1960]

Hallo,

danke für die Diskussion. Es lag tatsächlich an dem Eintrag für allowed. Der war bei lokalen Installationen nie ein Thema.
Für die anderen Hinweise auch vielen Dank. Nur soviel: Das "Ding" hat keine I/O-devices, sondern soll "nur" einige Internetquellen zusammen sammeln und in Dummys ablegen, die dann in einer hübschen FTUI-Darstellung erscheinen. Wetter / UWZ / Kalender / Google Maps Stau auf meiner Strecke etc.
Dafür braucht man manches von FHEM sicher nicht, aber wenn man ein System schon einigermaßen kennt ...

[rudolfkoenig]

Nur soviel: Das "Ding" hat keine I/O-devices, sondern soll "nur" einige Internetquellen zusammen sammeln

So ein System wird relativ schnell von denen, die komplette IP-Bereiche absuchen, entdeckt, und fuer andere Zwecke missbraucht (Filme verteilen, Spam versenden, etc).
Also auch wer "nichts zum Verstecken" hat, wird so zum Helfer.

[Christoph Morrison]

Für die anderen Hinweise auch vielen Dank. Nur soviel: Das "Ding" hat keine I/O-devices, sondern soll "nur" einige Internetquellen zusammen sammeln und in Dummys ablegen, die dann in einer hübschen FTUI-Darstellung erscheinen. Wetter / UWZ / Kalender / Google Maps Stau auf meiner Strecke etc.

Dir ist bewusst dass die Eingabezeile oben in FHEM praktisch eine Shell des Benutzers fhem auf dem System ist, oder? Ich hoffe du hast die Instanz nicht einfach so irgendwo ins Netz gehängt wo sie jeder finden und aufrufen kann?!

[Thorsten Pferdekaemper]

Hi,
erstmal vorweg: Mir ist klar, dass das nicht unbedingt dem "gedachten" Zweck von FHEM entspricht.
Aber: Na und? Ich finde die Idee zumindest interessant. Ich würde so zwar auch nicht meine Heizung steuern, aber warum nicht als Webserver für ein paar Kleinigkeiten.
Wahrscheinlich (hoffentlich?) wissen viele, dass sowas gefährlich sein kann. ...aber ist es gefährlicher als FHEM "zuhause" laufen zu lassen und über DynDNS von außen zugreifbar zu machen?
Was kann man außerdem tun, um das ganze ordentlich abzusichern? Ein gutes Passwort für FHEMWEB und HTTPS? Reicht das nicht aus? Ich denke mal, wenn das nicht ausreichen würde, dann könnte man auch einfach den ganzen Server übernehmen. Am Ende ist der ja auch nur mit einem Passwort gesichert, oder?
Gruß,
   Thorsten

[rudolfkoenig]

Ich habe kein Problem damit, wenn jemand FHEM auf einem Framdrechner betreibt, ich wollte nur darauf hinweisen, dass die Argumentation 'es haengen keine "echte" Geraete dran, kann also keinen Schaden verursachen' zu kurz gedacht ist. Die Voreinstellung schuetzt wirksam dagegen (wie wir es gesehen haben), man kann das aber auch ohne Passwortpruefung deaktivieren, und dagegen will ich warnen.

[Wernieman]

Grundsätzlich sollte man sich immer über Serversicherheit Gedanken machen.

Dazu gehört "simples Härten":
1. Sichere Passworte oder besser ssh-key-Autorisierung
2. Sichern gegen Brute-Force-Attacken (Stichwort fail2ban oder ähnliche Produkte)
3. Nur das drauf, was nötig ist
4. Produkte wie fhem brauchen (eventuell) zusätzliche Sicherheit, wie z.B. einfach einen proxy davor
5. Alles was nicht aus dem Netz erreichbar sein muß (wie z.B. Datenbanken) nicht aus dem netz erreichbar machen

Das alles macht es natürlich "nur" dem Angreifer schwerer, einen der "Dich" kennt aber nicht unmöglich. Deren Anzahl ist (zum Glück) aber seeehr begrenzt.

Nur mal so als Erfahrung:
Ein "neuer" Server bei Hetzner, also neu bestellt, wird schon nach spätestens 10 Minuten auf ssh per brute-force Angegriffen. Zu dem Zeitpunkt ist aber auch nur ssh offen......
(Hinweis: Hetzner ist hier KEIN Negativbeispiel, bei anderen Hostern ist es nicht besser, eher schlechter, wenn es ein bekannter Hoster für "DAUS" ist ...)

Als Ergänzung:
Wenn man weiß, wie viel ein übernommener 24/7 Server im DarkNet so an Geld bringt, man kann Ihn z.B. Fantastisch als C&C-Server für Trojaner o.Ä. verwenden, versteht man eventuell, wie nötig obiges Vorgehen ist.

Noch eine Ergänzung:
Wenn ich vom Einsperren von FHEM wegen Sicherheit rede, ist dieses keine kritik an Entwicklern. Nur ist eben FHEM in der Beziehung nicht getestet (anders als z.B. ein Proxy) und ich weiß z.B. nicht, ob man das Einloggen eventuell "umgehen" könnte. Bei einem "getesteten" Proxy wie nginx ist es (nach heutigem Stand) nicht möglich ...

Edit:
+ Kleine Ergänzung
+ "Noch eine Ergänzung:" Hinzugfügt

[Christoph Morrison]

Wahrscheinlich (hoffentlich?) wissen viele, dass sowas gefährlich sein kann. ...aber ist es gefährlicher als FHEM "zuhause" laufen zu lassen und über DynDNS von außen zugreifbar zu machen?

Auch wenn ich deinem Beitrag sonst zustimme, hier liegst du IMHO falsch: Es ist vielleicht nicht gefährlicher, aber da DynDNS-FHEM schon keine gute Idee ist, ist es auch keine bessere Idee, FHEM einfach so irgendwo im Internet anzubieten (auch mit Passwort). Ich würde meine Aussage aber noch mal teilweise revidieren wenn das DynDNS-/webhosted FHEM hinter einem ordentlichen reverse proxy sitzt, siehe unten!

Was kann man außerdem tun, um das ganze ordentlich abzusichern? Ein gutes Passwort für FHEMWEB und HTTPS? Reicht das nicht aus? Ich denke mal, wenn das nicht ausreichen würde, dann könnte man auch einfach den ganzen Server übernehmen. Am Ende ist der ja auch nur mit einem Passwort gesichert, oder?

FHEMWEB ausschließlich lokal auf dem Webserver, das über einen reverse proxy mit dem Internet kommuniziert, der SSL + Auth (mind. Digest Auth) macht. Als zusätzliche Schnittstelle kann man ja noch MQTT nehmen, das ebenfalls mit SSL+Auth abgesichert ist. Wenn man dann die Kommunikation über MQTT nur monodirektional gestaltet (nur Daten vom Web-FHEM zum Lokal-FHEM), kann man auch hier ein wenig Sicherheit gewinnen.

[Morgennebel]

FHEMWEB ausschließlich lokal auf dem Webserver, das über einen reverse proxy mit dem Internet kommuniziert, der SSL + Auth (mind. Digest Auth) macht. Als zusätzliche Schnittstelle kann man ja noch MQTT nehmen, das ebenfalls mit SSL+Auth abgesichert ist. Wenn man dann die Kommunikation über MQTT nur monodirektional gestaltet (nur Daten vom Web-FHEM zum Lokal-FHEM), kann man auch hier ein wenig Sicherheit gewinnen.

Jetzt hast Du ein wenig Sicherheit mehr, aber ein recht komplexes Setup, daß im Fehlerfall deine jetzt braun/blond/schwarzen Haare in wenigen Stunden Nachteinsatz erst grau und dann ausfallen lässt. Das hat rein gar nichts mehr mit dem KISS-Prinzip zu tun - für ein minimales Quentchen an Bequemlichkeit gegenüber einer VPN-basierenden Lösung oder der Kommunikation mit FHEM über den Signal-Messenger...

FHEM gehört ins LAN zu Hause, ohne DynDNS, ohne Portfreischaltung. Ausnahme: Dein Level hier im Forum ist Developer und Hero Member...

Ciao, -MN

[Christoph Morrison]

FHEM gehört ins LAN zu Hause, ohne DynDNS, ohne Portfreischaltung.

Das ist mir zu dogmatisch und bildet auch nicht die Realität da draußen ab: Es gibt hier einige Leute die FHEM z.B. in einem Wohnmobil o.ä. betreiben.
DynDNS ist an sich auch kein Problem, die Portfreigabe ist es im Regelfall.

[Wernieman]

"Komplexität" .. "VPN-basierenden Lösung"....

Mhhhh ... bist Du Dir sicher, das VPN einfach ist?

Und ein proxy (wenn Verstanden) ist jetzt auch nicht mehr sooo schwierig .. jedenfalls muß man dafür nicht "Developer und Hero Member" sein ...

[Morgennebel]

Das ist mir zu dogmatisch und bildet auch nicht die Realität da draußen ab: Es gibt hier einige Leute die FHEM z.B. in einem Wohnmobil o.ä. betreiben.
DynDNS ist an sich auch kein Problem, die Portfreigabe ist es im Regelfall.

Du bist Developer und Hero Member. Du gehörst bereits zu der Ausnahme und weißt, was Du tust.

Wohnmobil = Zu Hause mit LAN...

Ciao, -MN

[Morgennebel]

Und ein proxy (wenn Verstanden) ist jetzt auch nicht mehr sooo schwierig .. jedenfalls muß man dafür nicht "Developer und Hero Member" sein ...

Es gibt doch zwei Verständnisebenen:

• Eine Anleitung abarbeiten. Eventuell aus verschiedenen Quellen im Internet, teilweise veraltet - aber es bleibt der Nachbau eines bereits gelösten Problemes
• Nachts um 2 Uhr aus der Ferne einen Schluckauf identifizieren und beheben, während die Restfamilie auf Dich einschimpft und das SmartHome am liebsten in die Tonne treten will

Die erste Ebene reicht meiner Meinung nach nicht aus, um FHEM über ReverseProxy, VPN, Authentifizierung, SSH-Key Exchange und Let's Encrypt Zertifikate aufzusetzen und dauerhaft zu betreiben...

Ich rede nicht von Spielwiesen, Tests, Lerninstanzen - ich meine Produktivsysteme...

Ciao, -MN

[Christoph Morrison]

Du bist Developer und Hero Member. Du gehörst bereits zu der Ausnahme und weißt, was Du tust.

Ich bin Hero Member geworden weil ich ein paar (hundert) Postings geschrieben, Developer wurde ich, weil ich irgendwo ein Häkchen gesetzt, habe. Schwerlich ein Kriterium für irgendwas außer zu viel Zeit und einem nervösen Finger. Softwareentwickler sind meistens auch nicht die besten Systemadministratoren - einfach weil die Ziele konträr sind (Entwickler brauchen meistens Dinge, die abträglich für einen sicheren und soliden Systembetrieb sind, z.B. Compiler oder irgendwelche abstrusen Tools - nicht umsonst gibt es die DevOps-Bewegung). Aber ja, ich weiß was ich tue, nur kannst du das nicht an den Kriterien festmachen, die du postuliert hast.

Beides ist ernsthaft kein Kriterium für irgendwas und jemand der hier nicht mal schreibt kann ausreichend kompetent sein um drei Pakete für den Proxy + Letsencrypt zu installieren. Und dann hat er vermutlich deutlich mehr auditierte Sicherheit im System als wenn er versucht nach irgendeinem ranzigen Tutorial von vor 5 Jahren auf einem Werbeeinnahmen-Blog FHEM übers Handy bedienen zu können. Insofern sollten wir froh sein, dass der OP hier gefragt hat und wir ihm eine bessere Lösung anbieten können, auch wenn die halt umfasst dass er sich einen reverse proxy aufsetzt.

Wenn man nun dogmatisch mit "FHEM gehört ins LAN" antwortet, treibt man die Leute nur auf diese Blogs, denn der zugrundeliegende Wunsch, die Motivation für ihre Frage wurde nicht ergründet und auch nicht beantwortet.

Wohnmobil = Zu Hause mit LAN...

Dann müsste es aber ein Wohnimmobil sein, oder?

[Wernieman]

Nee ... Lan im Wohmobil ist das nicht ein "Lanmobil"
*griiiins*