Berechtigung/Benutzer

[PelliX]

Hallo,

Ich habe hier und da einiges zum Thema 'Security' der CV im Forum gefunden, allerdings scheint das meiste relativ alt zu sein, und es wurden immer wieder auf schnelle, gepfuschte Loesungen zurueckgegriffen. Ich muss gestehen, zur Zeit nutze ich selber folgende Aufstellung:

- OpenHAB als backend, wobei nur der localhost zugriff auf Jetty hat
- Apache2 als Webserver der fuer Clients zugaenglich ist und /rest, /visu usw per mod_proxy zur Verfuegung stellt
- Diese Verzeichnisse werden vom Webserver geschuetzt und Benutzer werden ueber LDAP (Active Directory) authentifiziert (mitgleid einer bestimmten Gruppe)
- Clients werden erst mal auf eine CGI umgeleitet der den SAMAccountName ausliest, und browser zur entsprechenden Konfiguration weiterleitet (/visu/?config=meinaccount)

So kann ich eine Konfiguration fuer jeden Anwender anlegen. Nun koennte man die LDAP Authentifizierung von Apache2 auch fuer jede einzelne XML Konfigurationsdatei einrichten (also auch ausschliessen das User1 trotzdem ?config=User2 in der Adresszeile eingeben kann). Wie ChrisM bereits gesagt hat, gibt es immer Sicherheitsprobleme: wer Zugriff auf den KNX Bus hat, kann Telegramme senden wie er (oder sie) moechte, und die REST API von OpenHAB kann ich auch nicht 'trennen und sichern'. Zugriff ist entweder vorhanden oder nicht vorhanden (OK, es gibt sehr teuere Telegrammfilter fuer KNX, und auf TCP Ebene koennte man auch filtern aber...).

Vordem ich jetzt aber versuche das Rad neu zu erfinden, moechte ich gerne wissen was hier erwuenscht/sinnvoll waere. Ich denke an einer relativ einfachen ACL, mit Gruppen und darin Benutzer. In der visu_config.xml sollte man dann pro Widget/Schalter/usw ein Attribut wie

<.... acl="Eltern,Kinder" .../>

definieren koennen. Allerdings sollte man vielleicht auch bestimmen koennen ob ein Schalter read-only oder read-write Zugriff haben sollte (pro Gruppe). Beispiel: die Kinder duerfen ruhig sehen ob das Licht im Garten an ist, sollten es aber nicht stundenlang an und aus schalten koennen. Vielleicht waere ein eigenstaendiger XML Tag da besser;

<security aclread="Eltern,Kinder,Besucher" aclwrite="Eltern">

Benutzer und Gruppen sollten erst mal in einer XML Datei konfiguriert werden, spaeter koennte man immer noch nach externe Authentifizierung gucken (fuer mich waere LDAP/AD natuerlich wichtig).

Hat jemand vielleicht schon mal so was angefangen, oder hat jemand Ideen dazu?

PelliX

[makki]

Nun, die Kernfrage ist IMHO (wie bereits von dir angedeutet): welchen Sinn macht eine granulierte Rechte-Vergabe (auch bei so gut wie allen anderen Lösungen!) wenn man es mit einfachsten Mitteln dann doch umgehen kann?!
Das ist z.B. im HS ja doll, aber jeder Realschüler kann das umgehen..

Genau deshalb habe sogar ich ( aus der IT-Security kommend ) meistens dagegen argumentiert, weils die Sache nur komplizierter macht, ohne die wirkliche Security (ausser fürs Marketing-bla-bla) signifikant zu erhöhen.
- KNXnet/IP secure bleibt erstmal Zukunftsmusik (und ist im Ansatz schon so lückenhaft das es IMHO fürn A* ist)
- Vorschläge?
Erstmal muss der KNX dicht sein, das erfordert für 99% der AW unrealistische Sachen wie sep. (V)LAN, Filter, Firewall, etc.

Ich meine die Frage ernst! Nur sehe ich derzeit kaum einen Ausweg und daher lieber: funktioniert - als den Anwender mit Pseudo-Security unnötig zu nerven.

Makki

[PelliX]

Hallo makki!

Erst mal danke fuer dein Input! Du hast voellig recht, dass es zur Zeit noch keine 100% sichere, vernuenftige Loesung gibt - aber man muss ja irgendwo anfangen. Das einzige was mich wirklich an OpenHAB z.B. stoert ist die Abwesendheit von einer Framework zur Sicherung vom ganzen - Sicherheitsluecken hier und da muss man immer akzeptieren, schliesslich ist nichts wirklich komplett gesichert. Ich komme selber auch aus der IT, und spreche (leider) aus Erfahrung.

Genau deshalb habe sogar ich ( aus der IT-Security kommend ) meistens dagegen argumentiert, weils die Sache nur komplizierter macht, ohne die wirkliche Security (ausser fürs Marketing-bla-bla) signifikant zu erhöhen.

Das sehe ich nicht unbedingt so; es ist eine Sache um eine Anwendung fuer eine Firma einzurichten wo auch z.B. finanzielle Daten abgelegt sind - da ist die Sicherheit extrem wichtig. Bei der CV (ich denke jetzt nur ans eigene Haus) ist das natuerlich nicht ganz so kritisch (bis man die Alarmanlage integriert! ;-). Die CV sollte aber trotzdem m.A.n. die Moeglichkeit bieten gewisse Sachen zu trennen, gerade z.B. wenn man Kinder hat. Sonst muss jeder halt seine eigene "semi-sichere Geschichte" basteln und kommt das Projekt nicht weiter (so wie ich das gemacht habe).

- KNXnet/IP secure bleibt erstmal Zukunftsmusik (und ist im Ansatz schon so lückenhaft das es IMHO fürn A* ist)

Naja, Sicherheit ist relativ! Telegramme kann man filtern, aber wer das Kabel in der Hand hat, hat wohl gewonnen. Bzgl. IP ... siehe unten.

- Vorschläge?

Nicht direkt zum Thema KNX - das ist (noch) kein Fachgebiet von mir!

Erstmal muss der KNX dicht sein, das erfordert für 99% der AW unrealistische Sachen wie sep. (V)LAN, Filter, Firewall, etc.

Ja, richtig. Ich habe mein Netzwerk bereits seit Jahren in VLANs verteilt und baue auch meine eigenen Proxies und Firewalls - da kenn ich mich aus. Nur weil KNX nicht sicher ist, heisst nicht, dass die CometVisu diese Fehler auch machen muss, oder? Ich baue mir auch oft Endgeraete, welche ich dann per CV/OpenHAB ansteure - ueber Ethernet, nicht ueber KNX/EIB. Dafuer sind VLANs eingerichtet, die Firewall weiss auch Bescheid - schade wenn der Server, bzw die UI das alles wieder rueckgaengig macht.

Kurz zusammengefasst: Nein, echt sicher koennen wir es (noch) nicht machen, aber vielleicht ein bisschen einfacher fuer "Papa" der seine Frau bestimmte Rechte geben moechte, aber seinem Sohn/seiner Tochter nicht.

Prinzipiell ist die REST API von OpenHAB ein riesengrosses Risiko, aber ganz abgesehen von der 'Sicherheit' waere es sinnvoll um bequem (wenn auch nicht bombensicher) dafuer sorgen zu koennen, dass jeder 'seine eigene' UI hat. Das ist eine Aufgabe der CometVisu, da sie die Sitemaps von OpenHAB ja nicht nutzt. Nehmen wir mal z.B. den PIN Code am Fernseher oder Sat. Receiver. Schon im fruehen Alter kann man sich die Anleitung durchlesen und heraus finden wie man das umgeht und sogar vielleicht einen neuen Code vergibt. Die Leute die diese Funktion nutzen (anscheinend sind das viele, hab ich gehoert) akzeptieren dass es nicht unknackbar ist, aber koennen so doch 99% der Zeit Sender X fuer die Kinder sperren.
Eine ganz nette Nebenwirkung der Benutzer/Gruppen waere auch, dass jeder Anwender ein anderes Design standardmaessig eingestellt haben koennte ohne in der URL zu basteln...

Nur sehe ich derzeit kaum einen Ausweg und daher lieber: funktioniert - als den Anwender mit Pseudo-Security unnötig zu nerven.

Es sollte auch eine Option sein - man verplichtet den Anwender ja nicht um sie zu nutzen.

Bitte verstehe mich nicht falsch - deine Kritik ist zurecht, ich moechte nur meine Meinung hier erklaeren.

PelliX

P.S.: OpenHAB hat eine moeglichkeit zur Authentifizierung, allerdings funktionieren die Gruppen zur Zeit nicht und kann man auch keine Rechte vergeben. Das ist in dem Sinne auch keine Kritik, das Projekt ist lediglich noch nicht ausgereift.

[Chris M.]

In Kürze und provokant: Wenn Du die Zugriffsrechte der Kinder begrenzen musst, hast Du vermutlich kein technisches, sondern ein erzieherisches Problem!
Nicht alles was technisch geht muss auch praktisch so sinnvoll sein.

Das von Dir beschriebene Szenario mit getrennten Zugriffsrechten sehe ich deutlich eher in Umgebungen, wo man nicht allen (berechtigten!) Anwendern ein 100% kooperatives Verhalten unterstellen kann. Ich denke da an Industrie-Gebäude. Und (mit noch mehr Absicherung) an Hotels.

[makki]

Erst mal danke fuer dein Input! Du hast voellig recht, dass es zur Zeit noch keine 100% sichere, vernuenftige Loesung gibt - aber man muss ja irgendwo anfangen.

Ich habe meine Ansichten da etwas geändert; man muss nicht irgendwo anfangen sondern es wenn dann zuende denken & machen.
Halbe security ist nur nervig und bringt keinen sicherheits-gewinn..

Das sehe ich nicht unbedingt so; es ist eine Sache um eine Anwendung fuer eine Firma einzurichten wo auch z.B. finanzielle Daten abgelegt sind - da ist die Sicherheit extrem wichtig.

Nun keine Frage, du rennst bei mir offene türen ein - aber betrachten wir mal die Realität: Fritzboxen werden ebenso wie HS oder (ich hoffe nicht) CV tausendfach direkt ins Inet durchgeschaltet; die "security" besteht dann darin, das non-Standard-Ports verwendet werden und/oder so tolle Sachen "admin/admin"/"admin/passwort" - das ist Augenwischerei die manche aber für "sicher" halten - da finde ich "offen" einfach ehrlicher, da kann wenigstens auch der Laie erkennen, das Hanni&Nanni ihr haus durchschalten können..

Naja, Sicherheit ist relativ! Telegramme kann man filtern, aber wer das Kabel in der Hand hat, hat wohl gewonnen. Bzgl. IP ... siehe unten.

Nicht wirklich.. Also das kann man lockerst umgehen, das ist in etwa so sicher wie ein MAC-Filter im offenen Wlan-Accesspoint..

Ja, richtig. Ich habe mein Netzwerk bereits seit Jahren in VLANs verteilt..

Naja, damit gehörst du mit mir aber zu einer absoluten Minderheit (auch ich habe ein sep. Vlan für KNXnet/IP ) So gehörts, fertig.
Mein Haupt-Kritikpunkt an Username/PW/Gruppenrechte auf der Visu ist: das gauckelt dem unbedarften AW eine nicht vorhandene pseudo-Sicherheit vor.

Es sollte auch eine Option sein - man verplichtet den Anwender ja nicht um sie zu nutzen.

Das wäre ein wesentlicher Punkt der mich ehrlichgesagt davon abhält: bitte optional.
Mit irgendwelchen selbstgestricktem Auth/AuthZ schiessen sich immernoch jeden Tag tausende Entwickler ins Knie: als wenn bitte in richtig, dann muss es in Webserver mit TLS 1.2, nem Zertifikat pro Endgerät, fertig - und das erklärste jetzt mal meiner besseren Hälfte wenn sie morgens den Rolladen fahren will

Bitte verstehe mich nicht falsch - deine Kritik ist zurecht, ich moechte nur meine Meinung hier erklaeren.

Ich denke ich verstehe ich keineswegs falsch, vor 4-5J hätte (oder habe ich?) exakt dasselbe geschrieben

P.S.: OpenHAB hat eine moeglichkeit zur Authentifizierung, allerdings funktionieren die Gruppen zur Zeit nicht und kann man auch keine Rechte vergeben. Das ist in dem Sinne auch keine Kritik, das Projekt ist lediglich noch nicht ausgereift.

Gutes Beispiel, auch wenn ich OH nicht wirklich gut kenne: gescheit, vollumfassend - oder lieber garnicht!?!
"Halbe Security" ist IMHO fürn A...

Ich möchte an dieser Stelle nochmal meine Gedanken zum Thema Security auf der Visu o.ä. - Stand 2014 - nach Snowden & Heartbleed darlegen:
1.: Sobald jemand Zugriff aufs interne LAN hat, hat man eh verloren, KNXnet/IP, Sonos, Dreambox, Russound, ... alles offen wie ein Scheunentor, dazu gespickt mit Sicherheitslücken - selbst falls so etwas wie AAA vorhanden ist.
Fakt.
Also warum sollte ich mich primär selbst ärgern und da etwas mit "pseudo-security" (ich nenne das bewusst so!), self-signed certs und schlechten usernamen/pw einbauen. Da lass ich es lieber gleich offfen, das ist IMHO ehrlicher, denn es gibt dort faktisch eben keine Sicherheit.
2.: wenn ich das absichern will, dann bitte richtig! also komplett. = gescheites VPN mit X509 (besser +OTP, ist aber unvermittelbar/nervig)
So ist "mein" Konzept (und damit irgendwo das des WG): kommste rein ist gut, bösen Buben gilt es generell den gesamten Zugriff zu verwähren.
Das funktioniert seit 2007 unverändert, auch NSA-sicher. (genauergesagt schon seit ca. 2000, seitdem ich mit mit VPNs beschäftige)

Für die Familie tuts auch ne jew. sep. config o.ä. - oder glaubt hier ernsthaft jemand das man einen durchschnittlich begabten 14jährigen der arpspoof, tcpdump aircrack-ng etc.pp auch googlen kann und sich im selben (W)LAN befindet aussperren kann?
Mit dieser Realität muss man sich abfinden, für alles andere sind dann schon schwerere Geschütze wie GPG gefragt.

Aber nun zum Thema zurück: will man bei jedem Zugriff auf die Visu PIN+Tokencode (OTP/OATH,..) oder die 34stellige PGP-Passphrase eingeben (die damit auch exponiert wird..)?
Eher nicht, weils nervt, also zuwas dann eine "pseudo-Security", ausser fürs Gewissen derer die nicht ahnen, das es eben eher "pseudo" ist..

Meine 15ct..

Makki

[makki]

Das von Dir beschriebene Szenario mit getrennten Zugriffsrechten sehe ich deutlich eher in Umgebungen, wo man nicht allen (berechtigten!) Anwendern ein 100% kooperatives Verhalten unterstellen kann. Ich denke da an Industrie-Gebäude. Und (mit noch mehr Absicherung) an Hotels.

Das ist der Punkt, wir sprechen dann gleich mal von Straftaten o.ä. - also könnte man auch diskutieren wie "sicher" ein Zylinder-Schloss (dazu gibts Urteile im Gegensatz zur Visu) oder ein Hotel-Safe (dazu gibts nen echten Lach-Artikel von heise mit der Hersteller-PIN) sein muss..

Hotel ist ein gutes Beispiel: überall wo's KNx hatte stecke ich mein Notebook mit TP-UART an (ist echt schon passiert..) und lese natürlich nur die Telgramme mit
Aber ich wüsste nicht, was jemanden mit krimineller Energie davon abhalten sollte, das Nachbarzimmer aufzusperren o.ä...

Makki

[swiss]

Ja gut aber da ist die configsperre dann nur eine kleine Hürde. Dann müsste man auch mal über die r und w scripte die jeder über die URL nutzen kann nachdenken... Nur die config zu sichern ist Pseudosicherheit. Wenn dann muss es als ganze einheit (clientauthenzierung für zugriff auf das Backend, Gesicherte kommunikation Backend -> eibd, abgeschotteter eibd (z.B. keine ungesicherten IP Verbindungen auf den KNX BUS usw...).

Das ist Utopie...

Einzig um z.B. die Fehlbedienung durch Drittpersonen zu vermeiden könnte eine solche Funktion sehr nützlich sein:

Ich möchte gerne die Kinosequenz über die Visu aufrufen können aber die Reinigungsfachkraft soll beim bedinen des Panels nicht ausversehen diese Sequenz auslösen können.

oder

Ich möchte das UserVPN und das WartungVPN meines WG über die Visu steuerun können. Möchte aber verhindern dass die Person die auf das Haus aufpasst aussversehen die VPN Verbindung schliesst wärend ich in den Ferien bin.

oder

Ich habe eine Fernalarmierung und eine Sequenz die bei Feueralarm ausgelöst wird. Da ich aber alle 2-3 Jahre mal die Batterie ersetzen muss, möchte ich diese Alarminrung über eine Wartungsseite auf der Visu blokieren können. Der Schulfreund meines Sohnes soll aber nicht ausversehen beim "spielen" auf der Visu die Alarmierungsfunktion deaktivieren können

usw...

Das sind nur exemplarische Beispiele wo ich eine einfache Benutzerrechteverwaltung als sehr praktisch empfinden würde. In keinem der Beispiele ist davon auszugehen dass die Leute mutwillig das System manipulieren wollen wesshalb auch eine Abschottung des Webservers oder das Schützen von KNX-IP nicht nötig wäre. Es geht lediglich darum nicht allen benutzern alle Funktionen freizugeben weil sie damit unerwünschte effekte auslösen könnten. Eine separate config wäre aber auch nicht unbedingt wirklich smart oder praktikabel, da ich dann wenn ich zuhause bin immer daran denken muss -> wenn die Putze kommt, muss ich eine andere Config aufrufen weil sie mit meiner Config einiges fehlbedienen könnte...

Zu dem ist das Pflegen von 2-3 Configs sehr viel aufwändiger als 1 Config und verschiedene Berechtigungen.

[PelliX]

@ChrisM: Ja, hehe, es ist aber verlockend diese Probleme auf technischer art zu loesen... muss allerdings dazu sagen, ich bin unverheiratet, habe keine Kinder und wohne auch nicht in einer WG!

@makki: OK. Ich verstehe was du meinst. Meine Loesung funktioniert ja, und ich sehe hier auch kein Bedarf also bleibt es meine Baustelle, kein Problem! :-)

Dass ich mit der Authentifizierung im CV das Problem mit OpenHAB nicht loesen kann ist mir schon klar - eins nach dem anderen!

Ich möchte an dieser Stelle nochmal meine Gedanken zum Thema Security auf der Visu o.ä. - Stand 2014 - nach Snowden & Heartbleed darlegen:
1.: Sobald jemand Zugriff aufs interne LAN hat, hat man eh verloren, KNXnet/IP, Sonos, Dreambox, Russound, ... alles offen wie ein Scheunentor, dazu gespickt mit Sicherheitslücken - selbst falls so etwas wie AAA vorhanden ist.
Fakt.

Ja, und das ist nur der Anfang :-(

Also warum sollte ich mich primär selbst ärgern und da etwas mit "pseudo-security" (ich nenne das bewusst so!), self-signed certs und schlechten usernamen/pw einbauen. Da lass ich es lieber gleich offfen, das ist IMHO ehrlicher, denn es gibt dort faktisch eben keine Sicherheit.

Nein. Nur weil man keinen Alarm am Wagen hat schliesst man doch auch sein Auto ab, oder? Ein billiges Fahrradschloss am teuren Rad ist oft genug um Diebe weitersuchen zu lassen.

2.: wenn ich das absichern will, dann bitte richtig! also komplett. = gescheites VPN mit X509 (besser +OTP, ist aber unvermittelbar/nervig)
So ist "mein" Konzept (und damit irgendwo das des WG): kommste rein ist gut, bösen Buben gilt es generell den gesamten Zugriff zu verwähren.
Das funktioniert seit 2007 unverändert, auch NSA-sicher. (genauergesagt schon seit ca. 2000, seitdem ich mit mit VPNs beschäftige)

Joa, fuer externen Zugriff nutze ich OpenVPN mit mehrfacher Authentifizierung und 2048bit Verschluesselung. NSA-sicher ist es aber natuerlich nicht wenn ich ein Smartphone oder Windows als OS nutze.

Für die Familie tuts auch ne jew. sep. config o.ä.

Joa, so siehts aus!

@Swiss: Ja, so sehe ich das eigentlich auch.

Zu dem ist das Pflegen von 2-3 Configs sehr viel aufwändiger als 1 Config und verschiedene Berechtigungen.

Hmm, ich hatte das schon so vor Augen gehabt; eine Config pro Gruppe oder aehnlich. Ich moechte ja das ganze individuell visuell gestalten koennen (Person A ist Brillentraeger, aber Person B nutzt nur einen 1080p Monitor). Vielleicht waere es sinnvoll um bestimmen zu koennen ob der Anwender eine eigene Config hat, und so ja welche.

PelliX