fhem.cfg.demo online

[rudolfkoenig]

Ich wuerde gerne eine FHEM Instanz mit fhem.cfg.demo online stellen und auf fhem.de verlinken, habe aber Angst den Rechner unbeabsichtigt in einem SPAM-Schleuder zu verwandeln. Hat jeman eine Idee, wie man das ohne Nebenwirkungen bewerkstelligen koennte?

[Dr. Boris Neubert]

Hallo,

über FHEMWEB kann ich doch Perl- und Shell-Kommandos ausführen? Damit habe ich doch schon alle Fähigkeiten und Rechte des Users, unter dem der FHEM-Prozess läuft, nicht wahr? Von da ist es mit dem richtigen Exploit (siehe Bombshell) nicht mehr weit bis zur Übernahme des Rechners durch feindliche Mächte.

Viele Grüße
Boris

[betateilchen]

Ich wuerde gerne eine FHEM Instanz mit fhem.cfg.demo online stellen und auf fhem.de verlinken

Warum?

[rudolfkoenig]

Das ist mir auch bekannt, deswegen meine Frage. Ich dachte an sowas wie:
- allowedComands in FHEM setzen
- FHEM in chroot als normaluser, evtl. auf ro-Partition
- regelmaessiger Neu-Start des Prozesses, um die Parameter zurueckzustellen.
- Einschraenken der Rechte mit SELinux/etc, damit FHEM keine neuen Dateien erzeugen, kein connect(), fork(), etc durchfuehren kann. Am besten ein whiteList statt blackList. Insb. mit diesem Punkt habe ich keine Erfahrung.
- Rechner herunterfahren, falls CPU oder Netzwerk-Traffic bestimmte Grenzen ueberschreitet.
- Protokollieren der eingegebenen Daten, damit man mitkriegt, was alles probiert wird.

Ich koennte fuer solche Zwecke ein RPi in einem Gast-LAN spendieren, bin aber fuer Alternativen auch offen.

Warum?

Damit man einfacher sehen kann, was man mit FHEM machen kann.

[betateilchen]

Tipp: Tu Dir den Stress nicht an.

Ich hab sowas schonmal auf einem meiner Server versucht - mit der Erkenntnis, dass man auf einem öffentlich zugänglichen Server fhem mit seinen eigenen Bordmitteln niemals so abschotten kann, dass es wirklich sicher wird. (Meine Lösung war letztendlich eine zertifikatsgesicherte VPN Verbindung)

[Loredo]

Hallo,


Ich darf vermutlich nicht sagen, dass sich das Hoanoho Image dafür bestens eignet; zumindest bin ich der Meinung, dass es hinreichend abgesichert ist. Wobei sich beim LIVE-Boot von der CD die Frage stellte, ob es nicht ausreichte, dass ein Nutzer das Image selbst in einer virtuellen Maschine kurz bootete, um FHEM auszuprobieren.


Ich würde sogar anbieten für FHEM ein eigenes Image auf dieser Basis zu erstellen (ohne Hoanoho). Dieses könnte man sogar so einstellen, dass man es auch auf einem Server booten könnte, der per Internet erreichbar ist und der LIVE-Modus automatisch startet. Das wäre am einfachsten, ein Reset der Test-Umgebung wäre quasi mit einem einfachen Neustart des virtuellen Servers erledigt, da alle Änderungen nur im RAM liegen.




Julian

[rudolfkoenig]

Was genau meinst du mit "Image"?

Ich glaube nicht daran, dass ein OS-Image (egal ob als VM- oder Live-Image) fuer jemanden einfacher zu installieren ist, als perl+FHEM. Ich will (wollte?) irgendetwas ohne Installation, wozu man nur den Browser benoetigt, egal ob auf Desktop, Handy oder Tablet.

[betateilchen]

Ich glaube nicht daran, dass ein OS-Image (egal ob als VM- oder Live-Image) fuer jemanden einfacher zu installieren ist,

Danke.

[Loredo]

Hallo Rudi,

Was genau meinst du mit "Image"?

Ich glaube nicht daran, dass ein OS-Image (egal ob als VM- oder Live-Image) fuer jemanden einfacher zu installieren ist, als perl+FHEM.

Für mich ist es mit einer einfachen Perl+FHEM Installation nicht getan, wenn man ein produktives System installieren möchte. Aber das ist eine andere Diskussion.
Jedenfalls wollte ich es dir nur einfach machen, denn ich interpretierte deine Anforderung so, dass du auch dort erhöhte Sicherheits- und Convenience-Anforderungen hättest.

Ich will (wollte?) irgendetwas ohne Installation, wozu man nur den Browser benoetigt, egal ob auf Desktop, Handy oder Tablet.

Mein Vorschlag lautete, grundsätzlich eine virtuelle Maschine zu starten und diese regelmäßig zurückzusetzen (Proxmox VE als Virtualisierungs-Host eignet sich hervorragend für sowas). Das kann ein manuell installiertes Linux nebst Perl+FHEM sein, welches du dann per Portforwarding, Reverse-Proxy - You-name-it - übers Internet erreichbar machst. Nach der Erstinstallation legst du ein Snapshot an und kannst scriptgesteuert auf diesen Stand zurücksetzen.

Warum ich angeboten habe dafür ein eigenes Image für FHEM (ohne die Hoanoho Frontend Oberfläche) bereitzustellen ist folgendes: Ich denke, dass du mit einem umfangreich abgesicherten System (also alles das, was um FHEM drum herum noch so dazugehören kann) dich einiges an Zeit kostet. Auch will das System aktuell gehalten werden und du hast Wartungsaufwand. Dies ließe sich reduzieren, indem du einfach von Zeit zu Zeit einfach die genutzte ISO Datei austauschst und die virtuelle Maschine täglich neu bootest.

Just my 5 Cent...


Gruß
Julian

[rudolfkoenig]

Es geht hier nicht um ein produktives System, sondern ein FHEMWEB Demo ohne echten Hardware dahinter. Mein Problem ist nicht das Abschotten/Zuruecksetzen (das kann ich in diesem Fall ohne VM einfacher), sondern das Verhindern von fork & connect, damit CPU oder Netzwerk nicht missbraucht wird.

[Loredo]

Mein Image schützt FHEM grundsätzlich per Reverse-Proxy, der seinerseits bereits vor FHEM eine Authentifizierung via HTTP-Auth verlangt (um gar nicht erst irgendwelche nicht gewollten Verbindungen an FHEM weiterzuleiten; zusätzlich zu einigen Prüfungen auf Protokolle). Auch wird eine Verbindung nur via TLS >= 1.1 zugelassen. Nach erfolgter Authentisierung wird natürlich davon ausgegangen, dass die FHEM Backend Instanz dann ausreichend gesichert ist. Ob man nun einen Fork o.ä. in Perl auslösen kann, weißt du als Author von FHEM sicherlich besser.


Nun möchtest du ja, dass die Nutzer sich möglichst einfach verbinden können. Neben der normalen HTTP-Auth Funktion nutzt das Hoanoho Frontend zusätzlich ein normales Login-Webformular als Alternative. Dies ist im Grundsatz ein PHP Script, welches je nach erfolgtem Login im HTTP-Header die Session-ID nochmals als extra Header X-FHEM-AllowUser mitschickt (X-FHEM-DisallowUser beim Logout). Der Reverse-Proxy erkennt dies und schaltet temporär den Zugriff auf das Backend für diese Session-ID frei. Der Nutzer kann dann ohne gesonderte HTTP-Authentifizierung auf das Backend zugreifen, indem er sein Session-Cookie in den Anfragen mitschickt.


Ich denke, das wäre ein erster Ansatz. Entweder würden sich Demo-Benutzer mit den Zugangsdaten demo/demo im Webformular anmelden oder du füllst es vorab aus und der Nutzer klickt nur auf "Login". Auch eine Browserweiche für den automatischen Wechsel zur Mobilansicht ließe sich hier einbauen.


All das ist im Hoanoho Image schon eingebaut. Daher hatte ich empfohlen es sich einmal anzusehen.

[rudolfkoenig]

Ich fuerchte wir reden ueber unterschiedliche Dinger.

Erstens will ich nicht das Hoanoho Frontend vorfuehren, sondern FHEMWEB.
Ein oeffentlich zugaengliches Hoanoho demo ueberlasse ich dir

Zweitens will ich niemanden authentifizieren/authorisieren, jeder soll das demo ohne loginformular aufrufen koennen, Verschluesselung ist mir auch egal.

Man soll aber nicht in der Lage sein, Unsinn mit der Installation zu treiben, z.Bsp. sie als SPAM-Schleuder oder DDOS-Station missbrauchen. Um das zu verhindern hilft dein Image-Konzept mit TLS/Proxy/Doppel-login nicht, weil alle Zugangsdaten oeffentlich sein muessen. Dein Konzept mag toll sein fuer einen privaten Zugang, das ist aber nicht mein Ziel.

[Loredo]

Erstens will ich nicht das Hoanoho Frontend vorfuehren, sondern FHEMWEB.

Das ist mir bewusst und war auch nicht mein Gedanke. Ich wollte dir Denkanstöße über Gedanken zur Absicherung machen, die ich mir bereits gemacht und umgesetzt hatte. Nichts weiter.


Vielmehr hatte ich deshalb ja angeboten, für FHEMWEB ein eigenes Setup zu bauen. Das ist offenbar nicht rüber gekommen.

Zweitens will ich niemanden authentifizieren/authorisieren, jeder soll das demo ohne loginformular aufrufen koennen, Verschluesselung ist mir auch egal.Man soll aber nicht in der Lage sein, Unsinn mit der Installation zu treiben, z.Bsp. sie als SPAM-Schleuder oder DDOS-Station missbrauchen. Um das zu verhindern hilft dein Image-Konzept mit TLS/Proxy/Doppel-login nicht, weil alle Zugangsdaten oeffentlich sein muessen. Dein Konzept mag toll sein fuer einen privaten Zugang, das ist aber nicht mein Ziel.

Das habe ich alles verstanden. Ich denke die von mir genannten Maßnahmen verhindern auch bereits eine Vielzahl von (automatisierten) Angriffen, selbst wenn die Zugangsdaten öffentlich sind oder gar automatisch für den Login verwendet werden. Sie erschweren es in jedem Fall deutlich und wären für mich daher die ersten Maßnahmen, bevor ich an FHEM selbst ginge. Ob nach der Authentifizierung dann noch über FHEMWEB irgendwelche Angriffe möglich sind, kannst du besser beurteilen. In jedem Fall hätte ich angenommen, dass dies weniger relevant würde, sobald man eine virtuelle Maschine hat, die "von außen" entsprechend restriktiviert ist (Netzwerk-Zugriffe, Ram, CPU-Zeit etc.). Ein womöglich doch erfolgreicher Einbruch würde somit abgemildert und mit einem Reset der gesamten VM wäre er dann auch schon wieder Geschichte, da eben egal wo oder was in der VM vom Angreifer geändert wurde, diese Änderungen niemals permanent werden. Den dann erkannten Sicherheitslücke in FHEM kann man anschließend entgegenwirken und somit langfristig Stück für Stück die Sicherheit deiner FHEM-Online-Demo verbessern.

So würde ich vorgehen und ja, über eine eigene Demo habe ich auch schon nachgedacht, habe allerdings bisher den zusätzlichen Implementierungsaufwand gescheut (neben der Tatsache, dass eine entsprechende Umgebung bei mir erst seit 6 Wochen verfügbar ist).