Ist HM/SmartHome noch sicher? Reportage PlusMinus

[MarcelK]

Frage an die VPN-Experten hier: inwiefern ist ein VPN sicherer als eine HTTPS-Verbindung mit sicherem Passwort?

Das eine ist erstmal nicht inherent sicherer oder unsicherer als das andere. Das Problem ist, wie sehr vertraue ich der Implementierung des jeweiligen Protokolls. Und da haben wir dann auf der einen Seite dann VPN code, der von meist unzähligen Menschen und Firmen eingesetzt wird um Sicherheit zu liefern und der teilweise schon Security Reviews von Experten hinter sich hat. Und auf der anderen Seite ein in Perl geschriebener Heimautomatisierungs-Server mit angeflanschten Web-Interface, dessen Code sich praktisch täglich ändert...

An der Stelle wird das ne einfache Wahrscheinlichkeitsrechnung die mich dazu bewegt dass ich niemals ein FHEM ohne SSH-Port-Redirect oder VPN Zugang direkt ins Netz hängen würde.

Gruß Marcel

[NilsB]

Von inhärenter Sicherheit kann im Kontext von FHEM sowieso keine Rede sein, was aber auch der Beschreibung FHEMs entspricht. Das gesamte System ist auf Konfigurierbarkeit und nicht Einfachheit ausgelegt. Inhärente Sicherheit würde bedeuten, dass das System Sicherheit durch Design mit sich bringt, also praktisch keine unsicheren Zustände zulässt.
Was mit den Warnhinweisen bzgl. security nach reboot geschaffen wurde ist schon fast mehr als man von FHEM gemäß seiner Beschreibung erwarten darf.

Zurück zur Frage: Bin da 100% bei Marcel. Der Implementierung FHEMs darf kein vernünftig urteilender Admin so sehr trauen, dass er den via BasicAuth geschützten Webserver ins WWW exponiert.
In aktuellen VPN Protokollen steckt sehr viel mehr Hirnschmalz und auch hier sind CVE-Vorkommnisse nichts aus dem Bereich der Fabel...
Also, IMHO ist VPN die einzig akzeptable Lösung. Mit on-demand Verbindungseinstellungen übrigens auch gar nicht unbequemer (kann selbst das iPhone mittels Konfigurationsprofilen).

Darüberhinaus sollte man sich btw auch Gedanken über den Schutz FHEMs im LAN Gedanken machen. Nur weil kein Port offen ist, rechtfertigt das keine Abschaltung von BasicAuth oder HTTPS. Ich persönlich habe mit Einbindung der Haustür in FHEM zusätzlich eine VLAN-Strukturierung angelegt, um eine vollständige Kapselung relevanter Geräte zu erreichen und diesen auch den Webzugriff passend einzuschränken. Je nachdem wer sich noch so im heimischen LAN rumtreibt kann das Sinn machen (hat Opa noch einen alten Win XP Rechner?) oder paranoid sein.
Ich jedenfalls schlafe so ruhiger.

Einzige Geschichte die mich hier noch stört: Der NFC Raspi sendet Nachrichten an FHEM immer noch per Telnet, das eigentlich verboten gehört. Zwar auch im abgetrennten VLAN, aber... hat da jemand einen eleganteren Ansatz auf Lager, der aus der bash genutzt werden kann?

Grüße
Nils


Gesendet von iPhone mit Tapatalk

[MadMax-FHEM]

Einzige Geschichte die mich hier noch stört: Der NFC Raspi sendet Nachrichten an FHEM immer noch per Telnet, das eigentlich verboten gehört. Zwar auch im abgetrennten VLAN, aber... hat da jemand einen eleganteren Ansatz auf Lager, der aus der bash genutzt werden kann?

Grüße
Nils


Gesendet von iPhone mit Tapatalk

Eleganter weiß ich nicht aber mit wget/curl sollte https gehen...

Gruß, Joachim

[NilsB]

Eleganter weiß ich nicht aber mut wget/curl sollte https gehen...

Gruß, Joachim

Elegant war vielleicht auch nicht ganz der richtige Ausdruck - kommt direkt auf die Sonntags-to-do-Liste. Danke!


Gesendet von iPhone mit Tapatalk

[vbs]

Gedanklich war ich auch nicht bei FHEM direkt im Netz, sondern mehr bei einer Konstellation aus HTTPS-Reverse-Proxy a la nginx/Apache, so dass dieser auch alle Authentifzierung übernimmt (FHEM erst erreichbar, wenn man sich korrekt am ReverseProxy angemeldet hat). Wie würdet ihr das in dem Fall beurteilen?

[NilsB]

Den Ansatz finde ich auch gar nicht mal so schlecht. Wäre in meinen Augen (bei korrekter Konfiguration und Wartung des bspw. nginx) eine akzeptable Lösung!

Das einzige was es dann noch zu vergleichen gelte: Authentifizierungsmethoden. VPN geht ohne Probleme zertifikatsbasiert, was man ggü. usr/pwd präferieren sollte. Das wäre im nginx nicht oder nur schwierig abzubilden. Allerdings könnte das zum ersten Mal der Punkt sein, an dem sich das Aufwand-/Nutzenverhältnis wendet.

Ich vermute eine Deine Anforderung lautet FHEM von beliebigen Rechnern aus nutzen zu können, liege ich da richtig? Das widerspricht schließlich der VPN Lösung.


Gesendet von iPhone mit Tapatalk

[rudolfkoenig]

Ob VPN oder HTTPS sicherer ist, das moegen Fachleute (d.h. Kryptografen) entscheiden, aber apache/nginx wird vermutlich auch nicht weniger als irgendwelche VPN-Loesungen auf Sicherheit untersucht worden sein, und FHEMWEB verwendet am Ende auch die gleiche openssl Bibliothek wie diese.

Ich will aber vermerken, dass Angrifftypen wie CSRF egal ist, ob die Seite per HTTPS oder VPN erreichbar ist, d.h. man sollte sich nich in Sicherheit wiegen, nur weil man VPN einsetzt.

[vbs]

Ich fänds schon elegant, wenn man es von jedem Rechner aus nutzen könnte ohne erst ein VPN einrichten zu müssen. Ich nutze auch Steuerung vom Handy aus per Tasker/HTTP-Befehle. Also ja, ich hänge da schon etwas dran Hilft natürlich alles nix, wenn es sicherheitsmäßig nicht vertretbar ist.
Im Moment nutze ich halt ein nginx-ReverseProxy mit sicherem Passwort (klopf auf Holz) und HTTPS mit echtem Zertifikat. Dazu läuft fail2ban, was IPs in der Firewall sperrt (OS-Level) nach 3 fehlgeschlagenen Anmeldeversuchen am nginx.
Habe das bisher halt für hinreichend sicher gehalten und ich wüsste nicht, wo da ein VPN sicherer wäre (außer wie du sagst PW <-> Zertifikat). Lese hier aber regelmäßig im Forum, dass man ausschließlich per VPN mit seinem FHEM reden sollte, was mir dann doch immer etwas Angst macht.

EDIT:
Hier eine interessante Ausführung zum Thema Zertifikat vs. Passwort:
http://security.stackexchange.com/questions/3605/certificate-based-authentication-vs-username-and-password-authentication

[NilsB]

(...) FHEMWEB verwendet am Ende auch die gleiche openssl Bibliothek wie diese. (...)

Das mag stimmen, nichts desto trotz, gibt es noch mehr als das im Kern liegende openssl. Drumherum kommt jede Menge FHEM-Implementierung, welche AFAIK noch nicht von unabhängigen Krypto-Experten* auditiert wurde. Allein die Tatsache die Web-Credentials base64-encoded in FHEM zu speichern ist Grund genug dem FHEM-Webserver seine Tauglichkeit ins Web exponiert zu werden abzusprechen.

(...) Ich will aber vermerken, dass Angrifftypen wie CSRF egal ist, ob die Seite per HTTPS oder VPN erreichbar ist, d.h. man sollte sich nich in Sicherheit wiegen, nur weil man VPN einsetzt. (...)

Gutes Beispiel -- und der dahinter steckende Hinweis ist so wichtig kein anderer: Egal welche high sophisticated Krypto-Technologien ich auch einsetze, der Verstand spielt immer eine genau so große Rolle. Das schließt alle User des Hauses mit Zugriff ein..

Ich fänds schon elegant, wenn man es von jedem Rechner aus nutzen könnte ohne erst ein VPN einrichten zu müssen. (...) Hilft natürlich alles nix, wenn es sicherheitsmäßig nicht vertretbar ist.
(...)
Im Moment nutze ich halt ein nginx-ReverseProxy mit sicherem Passwort (klopf auf Holz) und HTTPS mit echtem Zertifikat. Dazu läuft fail2ban, was IPs in der Firewall sperrt (OS-Level) nach 3 fehlgeschlagenen Anmeldeversuchen am nginx.

Kann das gut nachvollziehen. Ohne es zu wagen mich als Experte zu bezeichnen, würde ich allerdings sagen, dass du ein Setup hast, welches bei gewissenhafter Benutzung durchaus vertretbar ist.
Damit fällst du auch vermutlich nicht in die angedachten Alternativgruppe zu "ausschließlich VPN für FHEM nutzen". Die meisten Autoren solcher Aussagen (einschließlich mir) haben wohl eher den unbedarften User im Kopf, welcher sonst den FHEM-Webserver direkt hinter den offenen Port stellt.

Der Link zum Thema PW vs. cert ist gut; dort finden sich eigentlich alle wichtigen Argumente greifbar erklärt wieder.
Mit den Infos kann glaube ich jeder selbst ziemlich gut entscheiden mit welcher Art der Sicherung er nun am besten beraten ist.

*= Bitte lasst uns hier nicht über die Branche IT-Security sinieren, ich weiß da gibt es auch eine Menge zu diskutieren, dennoch hoffe ich mein Punkt wird klar.

Grüße
Nils

[rudolfkoenig]

Allein die Tatsache die Web-Credentials base64-encoded in FHEM zu speichern ist Grund genug dem FHEM-Webserver seine Tauglichkeit ins Web exponiert zu werden abzusprechen.

Kannst du das bitte mit einem konkreten Beispiel mir erlaeutern, ich habe Schwierigkeiten das zu begreifen.

Ich gehe solange davon aus, dass du FHEM mit Websites mit vielen Logins, die genackt wurden, und _fremde_ Passwoerter entwendet wurden, verwechselst. Btw. du bist nicht gezwungen, basicAuth Passwoerter als base64 zu speichern. Du musst dein Passwort gar nicht in FHEM speichern, die Authentifizierung kann auch sowas wie ActiveDirectory uebernehmen.

[NilsB]

(...) Ich gehe solange davon aus, dass du FHEM mit Websites mit vielen Logins, die genackt wurden, und _fremde_ Passwoerter entwendet wurden, verwechselst.

Das ist das übliche Beispiel für schlecht gespeicherte Passwörter -- wohl nicht ganz auf FHEM übertragbar, stimmt.
Aber wäre es nicht auch ein denkbares Beispiel, dass ein Angreifer kurzzeitig (aus welchem Grund auch immer) Zugriff auf das FHEM System hat? Normalerweise dürfte er dann maximal die Möglichkeit haben, das Passwort zu ändern bzw. einen zusätzlichen Login zu erzeugen. Im hiesigen Fall ist es jedoch Möglich das Passwort, also das einzige Geheimnis des gesamten Authentifizierungsmechanismus, zu erfahren. Das verstößt einfach gegen jede Guideline jedes IT-Security Lehrwerks/Papers/ was auch immer. Im Beispiel könnte er dann unbemerkt diesen Login weiterhin nutzen.

(...) Btw. du bist nicht gezwungen, basicAuth Passwoerter als base64 zu speichern. Du musst dein Passwort gar nicht in FHEM speichern, die Authentifizierung kann auch sowas wie ActiveDirectory uebernehmen.

Werden auch andere Verfahren, ggf. sogar Hash-Verfahren von FHEM unterstützt?
Gibt es in FHEM eine AD- (oder anderer Verzeichnisdienst) Integration, oder was schwebte dir dabei jetzt vor?

-Nils

[rudolfkoenig]

Werden auch andere Verfahren, ggf. sogar Hash-Verfahren von FHEM unterstützt?

Das allowed Modul erlaubt dir einen Perl-Ausdruck auszufuehren. Mit Net::LDAP sollte nicht aufwendig sein, eine Authentifizierung gegen AD durchzufuehren. Oder mit Digest::SHA was besseres als base64 einzusetzen.

[NilsB]

Das allowed Modul erlaubt dir einen Perl-Ausdruck auszufuehren. (...)

Schöne Option! Werde ich mir anschauen, danke!

[martinp876]

Das ist eine sehr interessante Diskussion. Allerdings hat es nichts mit um zu tun. Sollte im entsprechenden Forum fortgeführt werden ( und umbenannt) damit sicherheitsinteressierte User aller Systeme es finden können.
Rudi?

[rudolfkoenig]

Schöne Option! Werde ich mir anschauen, danke!

Und falls du was implementiert hast, bitte irgendwo (wiki/hier) dokumentieren

Sollte im entsprechenden Forum fortgeführt werden ( und umbenannt) damit sicherheitsinteressierte User aller Systeme es finden können.

Habe nichts dagegen, das sollte aber der TE machen.
Hat mit HM angefangen, da die "Journalisten" das "Problem" an HM Geraeten demonstriert haben.