IP-Symcon Connect - Security

Moin zusammen,

ich würde gerne ein paar Verbesserungsvorschläge bezüglich „Connect“ zur Diskussion stellen.
Hier erst mal der Hintergrund:

Ein Kunde hat mich gefragt ob er Symcon Connect bedenkenlos einsetzen kann. Ich habe dies zum Anlass genommen mir die Funktion einmal anzuschauen.

Aktuell basiert die Sicherheit ja auch zwei „Komponenten“:

  1. Der Hostname des jeweiligen Symcon.
    Diesen Name (*.ipmagic.de) muss man wissen, um überhaupt auf des WebInterface bzw. die neue Web Console zu kommen (nebenbei: Geiles Teil! :slight_smile: )

  2. Das Kennwort und - im Falle der Console - auch noch den Benutzernamen.

Nun möchte mein Kunde leider kein Kennwort für’s Web-Interface haben bzw. würde nur ein „sehr kurzes“ dort einstellen wollen… Da ist er vermutlich nicht alleine. ^^

Insofern reduziert sich die Sicherheit auf den DNS Hostnamen. Dieser ist aber sehr leicht von Dritten zu erlangen:

a) DNS Query-Logs
b) Sniffer oder Diagnose-Tools in offenen WLAN’s.
c) Proxy’s (entweder im Firmennetz oder bei Providern)
d) Browser History
e) Add-Ons in Browsern (oder Browser selber) die aufgerufene Namen zu ihren Programmieren übertragen.
usw.

Da der Kunde sowohl Türen als auch die Alarmanlage über Symcon steuert, muss ich ihm aktuell also vom Einsatz von Connect abraten.

Aus meiner Sicht gebe es einige mögliche Gegenmaßnahmen:

  1. Gegen DNS-Lauscher (a & b):
    Der individuelle Teil des Hostnamens sollte entfernt und in den GET-Request verlagert werden. Hiermit würde aus
    Nicht erreichbar ein Nicht erreichbar und jemand der auf DNS Anforderungen lauscht sieht nur noch „ipmagic.de“. Nebenbei würde das einen potentiellen Einsatz von SNI als „Informationsquelle“ ausschließen.

Mir dieser Änderung wäre der wichtigste Vektor für Angriffe „aus dem Netz“ geschlossen. Leider hilft dies nicht gegen Proxy’s ©.

Grundsätzlich ist dies eigentlich auch keine Sicherheitstechnik. Sondern nur Verschleierung. - Besser wäre auf jeden Fall eine Unterstützung von Endgeräte (x.509) Zertifikaten. Im Besten Fall mit Ausstellung/Sperrung über den Symcon Server. Träum Ich glaube da schreibe ich mal einen Feature-Request. :wink:

  1. Lockout
    Sollte ein Kennwort im Webinterface gesetzt sein, wäre es schön eine Sperre nach Fehlversuchen konfigurieren zu können.

  2. Den Nutzer informieren
    Ich fände es schön wenn der Nutzer beim aktivieren von Connect ein paar Informationen zum Thema Sicherheit bekäme.
    Gerne auch mit dem Link in die Symcon Doku zum Thema Sicherheit.

Viele Dank für’s lesen, :wink:
Markus.

Hallo Markus,

  1. ist kein Sicherheitsmerkmal. Wir würden dies niemals als Sicherheit nur ansatzweise verkaufen wollen. Niemand sollte auf die Unbekanntheit seiner Adresse nur Ansatzweise vertrauen. Google wird diese Adresse irgendwann finden und indizieren… ich garantiere es dir…

Nun möchte mein Kunde leider kein Kennwort für’s Web-Interface haben bzw. würde nur ein „sehr kurzes“ dort einstellen wollen… Da ist er vermutlich nicht alleine. ^^

Als ich das gerade gelesen habe war ich so schockiert, dass ich noch um diese Uhrzeit einen Beitrag schreibe. Die Sicherheit wird allein durch ein sicheres Kennwort gewährleistet. Dieses sollte eher lang als „komplex“ sein. Siehe: xkcd: Password Strength (Du kannst übrigens einstellen, dass das Kennwort nur für externe Verbindungen erfordert wird beim WebFront…)

Man kann das Kennwort in der App speichern oder dies im Browser speichern, aber kein sicheres Kennwort zu setzen ist einfach fahrlässig.

Zu 1) Deine Idee mit Zertifikaten ist im Enterprise Sektor eine feine Sache (dort verfügt man jedoch über entsprechende Mittel die Zertifikate direkt mit auf das Endgerät zu spielen und zu aktualisieren)… In unserem Anwendungsfall kannst du ja das Kennwirt in die App einspeichern - das wäre zumindest vergleichbar :slight_smile:

Zu 2) Slowdown/Lockout passiert bereits nach einigen fehlerhaften Versuchen.

Im weitesten Sinne ist für den Connect Dienst ausschließlich relevant, dass die Verbindung bis zum IP-Symcon Server (sicher) verschlüsselt stattfindet. Das hast du bisher noch gar nicht erwähnt :wink: Den Rest erledigt dann das Thema Sicherheit (=WebFront Kennwort/Fernzugriff) von IP-Symcon. Und dafür ist ein sicheres Kennwort unablässig.

Ansonsten kann dein Kunde ja einfach die Haustür mit einem Riegel absperren - Aber das würde ja keiner machen, oder?

paresy

PS: Vielleicht wäre ja VPN etwas für deinen Kunden?

Das sehe ich auch so.

Kürzlich hatten wir die Diskussion, warum man defaultmässig im LAN ohne Passwort auf die IPS-Konfiguration zugreifen kann. Und das war bezüglich Sicherheit auch noch falsch dokumentiert, inzwischen ist es zumindest dokumentiert unsicher.

Die Argumentation dafür fand ich erschreckend und behandle IPS nun insgesamt als „unsicher“, weil ich an dem Willen der Entwickler zweifle, Sicherheit konsequent umzusetzen. Wer weiß schon, was bei JSON-RPC API und Co noch alles ungewollt oder undokumentiert offen steht.

Dann sollte es auch so nachdrücklich in der Doku stehen!
Da steht momentan eine schwache Formulierung: „Es ist empfohlen das WebFront mit einem Passwort zu sichern.“

Hallo Volker, hier ist es sehr viel härter formuliert. (Sicherheit — IP-Symcon :: Automatisierungssoftware)

Das Passwort, welches durch den Konfigurator eingestellt werden kann, sollte unbedingt gesetzt werden, sofern der Connect-Dienst aktiviert wird oder das WebFront von extern erreichbar sein soll.

Wo hast du gerade die andere Formulierung gefunden? Ich würde das dort dann entsprechend anpassen.

paresy

Hallo paresy,

Modulreferenz Connect Control:
Connect Control — IP-Symcon :: Automatisierungssoftware

Viele Grüße
Volker

Also ich hätte auch VPN gesagt. So habe ich es die ganze Zeit gehandhabt, weil mir der Zugriff nur über Passwort im Connect Dienst zu dünn ist.
Leider ist man dazu gezwungen wenn man Alexa haben will. Damit war automatisch das Webfront erreichbar. Oder habe ich was übersehen das ich Alexa nutzen kann ohne den „magic“ Zugriff?

Nein, Du hast nichts übersehen.

Hallo Markus,

schön dass sich noch jemand für das Thema Sicherheit interessiert :wink:

Von der Herstellerseite gesehen ist mir klar, dass das Produkt auch Features für die breite Masse braucht…

Ich hatte glaube ich bereits zum Anfang des Connect-Dienstes vorgeschlagen, dass man einzelne Features das Connect-Dienstes ein- bzw. ausschaltbar macht. So könnte jeder mit Sicherheitsbedenken das Webfront abschalten und trotzdem den Connect-Dienst für Alexa nutzen. Das sollte mit einfachen Filterregeln machbar sein - je nachdem wie das HQ den Connect-Dienst realisiert hat…

Ansonsten lassen sich die Sicherheitsanforderungen (x.509 Endgeräte Zertifikate etc.) relativ leicht mit einem eigenen Reverse-Proxy umsetzen. Wenn Du da Ideen, Anregungen, Unterstützug brauchst, schreib mich gerne per PN an - ich bin in der IT-Security tätig - damit die Bösen :banghead: draußen bleiben.

Grüße
Andreas

Alloha zusammen,

schon mal Danke für die gute Diskussion. Ein paar Punkte würde ich gerne noch mal einwerfen. :wink:

  • Bei uns war der Stein des Anstoßes auch die gute Alexa. Deswegen hilft VPN leider nicht.

  • Suchmachinen

Google wird diese Adresse irgendwann finden und indizieren… ich garantiere es dir…

Das sollte eigentlich nicht so sein. Google sucht ja nicht aktiv nach allen möglichen cryptischen URL’s. Die URL ist aber notwendig für den Zugriff da sich ja alle ipmagic.de Nutzer eine IP teilen (SNI/Name Virtual Host). Wenn „findet“ Google die URL durch Browser Addon’s und/oder Verlinkung. Da hat der Nutzer, durch eigene Umsicht, schon ein paar Möglichkeiten sich vor zu schützen.

Ein zusätzlicher Vorschlag wäre das Symcon eine robots.txt ausliefert um seriösen Suchmaschinen zu sagen das sie hier nichts zu suchen haben.

Es scheint auch nur einen (!) Eintrag bei Google zu geben. Und der sieht aus wie ein Test. ( Google suche mit inurl:ipmagic.de )

Sehr Problematisch sind die Nutzer die kein Connect benutzen. - Dafür aber ihr Symcon offen ins Netz stellen.
Die werden sehr, sehr wahrscheinlich von shodan.io gefunden. Macht euch mal den Spaß und sucht da nach „IP-Symcon“ oder was ähnlichem. Da läuft es einem kalt den Rücken runter. :banghead:

  • Schindluder mit dem Hostnamen
    Ich habe heute Abend mal mit einem Kollegen ausprobiert was ich alles an seinem Symcon machen kann, obwohl ich sein Password nicht kenne. Weit bin ich nicht gekommen. Nachdem ich „/js/webfront.js“ in einer Endlosschleife abgerufen habe hat seine Frau uns den Spaß verdorben: Upstream dicht. Netflix ruckelt. ^^

  • Defaults
    Nach meinem kurzen blick in shodan würde ich gerne Vorschlagen das immer und alle Zugriffe - per default - nur mit Kennwort möglich sind. Sowohl aus den LAN als auch aus dem Internet. Der Nutzer sollte das immer aktiv abschalten müssen. Möglichst nach drei Warnungen.

Ich musste ehrlich gesagt auch eine ganze Weile suchen, bis ich gefunden habe, wie man auch LOKAL dafür sorgen kann, dass man ein Kennwort für die Admin Oberfläche eingeben muss. Erst durch diesen Thread habe ich verstanden, dass es doch geht und sofort umgesetzt.
Das würde ich auch besser finden, wenn dies per Default aktiviert ist. Am besten noch mit einem generierten Key wie es Fritzboxen für den WPA2 Key haben.
Ich habe zwar separierte WLANs und VLANs für Gäste, IoT Geräte und Arbeitsgeräte, jedoch finde ich es nicht so schön, wenn ich weiß, dass man nur per LAN irgendwo conncten bräuchte und sofort Admin Zugriff auf Symcon hat.

Vorschlagen würde ich für den Zugriff von Außen immer ein VPN. Wenn es wirklich ein WebFrontend sein muss, dann via Reverse Proxy. Eine Entkopplung ist da sicherlich sinnvoll. Eine Firewall wie OPNSense oder PFSense oder Sophos haben sowas direkt on Board. Eine Portweiterleitung auf einen Rechner im LAN würde ich persönlich immer vermeiden.

Unbedingt. Das Thema hatte ich kürzlich hieraufgemacht. Unerwartetes Ergebnis: ein werksseitiges Passwort ist zugunsten der einfache Raspi-Inbetriebnahme nicht gewollt, die Verwaltungskonsole soll werksseitig im LAN ungeschützt sein.

Nachtrag:
Bei den Linux/Raspi-Nutzern, die ein Passwort gesetzt habe, dürfte „symcon“ überdurchschnittlich häufig sein, weil sie sich wörtlich an diese Anleitung gehalten haben (Seitenende) :rolleyes:
Fernzugriff — IP-Symcon :: Automatisierungssoftware

Moin,

bei mir basiert die Sicherheitsproblematik zwar nicht auf Kundeninstallationen sondern auf der Zusammenarbeit mit unserem Nachbarn, die Problematik ist aber ähnlich.

Ich selbst habe bislang ausschließlich auf VPN gesetzt da dies für mich völlig ausreichend war. Da nun unser Nachbar auf einige Bereiche Zugriff haben soll, hatte ich mir überlegt dafür auf Connect Control zu setzen. Deshalb auch die Anfrage, ob man auswerten kann, ob eine Verbindung über Connect Control hergestellt worden ist Gibt es eine Überwachungsfunktion für Connect Control?

Noch problematischer wird die Angelegenheit, wenn man IPSView einsetzt, da dort nicht pro View (=WebFront) sondern insgesamt nur 1 Kennwort für alle Views hinterlegt werden kann (siehe IPSView Feature Requests - Seite 25 ab Post #250). Für meinen Anwendungsfall habe ich mir überlegt innerhalb meiner Win 10 NUC Installation ein weiteres Win 10 in Virtual Box zu installieren, auf welches dann via Connect Control zugegriffen werden kann. Die Daten können dann via JSON-RPC API ausgetauscht werden. Prinzipiell scheint dies zu funktionieren. Für Kundeninstallationen ist dieses aber sicherlich unbrauchbar.

Gruß
Hans

Zu IP-Symcon 5.1 kann man in den Spezialschaltern die ganzen Slowdown/Lockdown Limitationen/Timeouts einstellen, um ggf. fehlerhafte Loginversuche noch stärker zu limitieren.

paresy

Wenn man den Connect Dienst aktiviert, kann man mit https oder http auf die Seite zugreifen.
Wenn man einfach mal das s wegläst, ist man schon ungesichert und das Passwort wird plain übertragen.
Dann reicht schon Wireshark und man hat das Passwort. Also aus mit der Sicherheit.
Hier sollte nur eine gesicherte Verbindung möglich sein.

Wir werden demnächst diese Weiterleitung (wie von dir vorgeschlagen) erzwingen.

paresy

Finde es gar nicht so verkehrt wenn connect auch via HTTP Funktioniert. Wenn man z.B. mit einem Webhook arbeitet, bei dem es nicht auf sicherheit ankommt und die Hardware Ggf kein SSL unterstützt finde ich es gar nicht verkehrt, wenn man die Möglichkeit hat.

Hast du da ein Beispiel?
Gerade bei Webhooks, wo gerne ohne weitere Authentifizierung gearbeitet wird, finde ich TLS unerlässlich.
Wenn Hardware/Software welche im öffentlichen Netz hängt kein TLS kann, würde ich sie ersetzen.
Michael

Kommt natürlich immer auf den anwendungsfall an … ich kann es mir z.B. Für einen Temperatursensor vorstellen, der mir über ein öffentliches Netzwerk einen Wert sendet.
Der braucht kein Passwort oder sonst was.
Ich kann dem ggf. Noch eine Guid oder ähnliches geben.
Wenn dann tatsächlich jemand die Verbindung mitsniffen sollte kann er mir mein Außentermometer verstellen … beim nächsten Aufruf ist die dann wider richtig … also alles in alle keine ernsthafte „Gefähr“

Bei Webfront usw. Gebe ich euch natürlich vollkommen recht. Das muss via SSL passieren!
Da macht auch eine Weiterleitung schon Sinn. Ggf sollte man allerdings auch irgendwie die Möglichkeit haben so eine Verbindung auch ohne SSL aufbauen zu können :wink:

Weil ich das Thema schon lange beobachte und bis jetzt auch noch nichts dazu geschrieben habe:

Das Sicherheitskonzept von IPS finde ich nicht verkehrt. Klar beruht alles auf einem sicheren Passwort. Leider wird dies oft nicht richtig ernst genommen. Ist aber kein Fehler von Symcon.

Ich betreibe/betreue mehrere Instanzen von IPS, sowohl privat als auch dienstlich. Teilweise mit Connect-Dienst und teilweise ohne. Jedoch sind alle IPS Instanzen via SSL erreichbar und haben sichere Passwörter. Ich glaube nicht, dass dies ein wesentlicher Angriffsvektor ist. Die Sicherheitswarnungen in der Webconsole sorgen auch dafür, dass man nichts vergisst. => Eine gute Lösung.

Ich denke HTST ist da der einfachste und beste Weg. Alle (guten) Browser unterstützen dies und wechseln damit automatisch auf HTTPS, wohingegen du deine WebHooks, denen HTST egal ist (und ggf. sein darf) weiterhin mit HTTP nutzen kannst.

paresy

Hallo,
bin gerade auf den Beitrag gestossen, weil ich per Copy&Past (was natürlich bei HTTP nicht funktioniert) machen wolle und mir gesagt wurde, ich solle dich HTTPS via Connect Dienst aktivieren!

Konnte nichts finden bei der Suche.
Wie?
Danke!