Web Adapter - weisse Liste funktioniert nicht
-
Weiße Liste ist für IP Adressen gedacht und nicht für User. D.h. wenn ein Request von einer bestimmten Adresse kommt dann sollte es unter User X laufen. Und nicht umgekehrt.
-
Hallo,
das Thema Login und user-Berechtigungen hat mich auch schon beschäftigt (siehe Link hier).
Prinzipiell müsste es mit der Einrichtung von Usern und Gruppen und manueller Freigabe der Authentifizierung möglich sein.
In der vis.0-beta hat es auch funktioniert, in der aktuellen Version funktioniert es zumindest bei mir nicht (oder nicht mehr) und nach der Eingabe eines Passwords kommt dann immer eine Fehlermeldung permission neglected oder so ähnlich.
Ich habe das schon vor Wochen hochgebracht, aber eine Antwort habe ich dann nicht bekommen und habe dann eine Alternative erarbeitet (nicht so sicher und wesentlich aufwendiger aber was sollte ich machen).
In der Summe erscheint mir die Zugangsberechtigung eher ein schwieriges Thema zu sein und die Implementierung ist eher unglücklich gelöst. Auch die Tatsache dass sich der Edit-Mode und der View Mode lediglich durch die URL unterscheiden möchte für zu Hause ok sein, für ein System mit mehreren Usern die eigentlich nur den View Mode sehen soll ist das eigentlich nicht tolerierbar.
In der Summe sehe ich da Verbesserungsbedarf auch in der Einrichtung.
Hier noch der Link zu meiner Anfrage:
http://forum.iobroker.net/viewtopic.php?p=70798#p70798
Andreas
-
Also unabhängig davon, ob es im Moment so funktioniert wie es soll oder Bugs hat muss ich dein Sicherheitsverständnis kritisieren. Vielleicht habe ich dich auch falsch verstanden, dann helfe ich mit folgenden Anmerkung aber vielleicht anderen Nutzern.
Einerseits möchtest du dich gern nur anhand der richtigen IP einloggen. Dabei sind IPs überhaupt nichts sicheres oder unbekanntes. Jeder kann diese IP annehmen oder auch einfach faken (Stichwort x-forwarded-for).
Andererseits ist es für dich nicht tolerierbar, dass die URL für den Editor ähnlich ist, wie die der fertigen Views. Das ist nun wirklich keine Sicherheitslücke! Eine "geheime" URL darf NIEMALS teil eines Sicherheitssystems sein und bietet keinerlei Sicherheit. Dass man die Editor-URL kennt darf umgekehrt auch auf keinen Fall ein Sicherheitsproblem darstellen. Der Editor muss ganz einfach über geeignete Sicherheitsmaßnahmen vor unbefugten Zugriffen geschützt werden.
-
In der Summe sehe ich da Verbesserungsbedarf auch in der Einrichtung. `
Ich auch. Wann kommt die Verbesserung?Alles liegt offen.
-
In der Summe sehe ich da Verbesserungsbedarf auch in der Einrichtung. `
Ich auch. Wann kommt die Verbesserung?Alles liegt offen. `
Da wir manchmal misverstandnisse haben was gemeint ist
Ich glaube Bluefox meint hier de code ist offen und es wuerde uns freuen wen jemand diesen teil aender/verbessern koennte (kan ja nicht alles nur von Bluefox kommen dafuer ist ja alles opensource :))
Guddie: Ich bin leider zu "dumm" dafuer, wuerde es aber super cool vinden wen diese whitelist auf MAC adresse reagieren wuerde anstatt von IP damit ist es schonmal sicherer und besser implementierbar.
Ob die function algemein geht weis ich nicht, bekommen den eindruck nein ?
~Dutch
-
Guddie: Ich bin leider zu "dumm" dafuer, wuerde es aber super cool vinden wen diese whitelist auf MAC adresse reagieren wuerde anstatt von IP damit ist es schonmal sicherer und besser implementierbar.
Ob die function algemein geht weis ich nicht, bekommen den eindruck nein ?
~Dutch `
Da muss ich dich leider auch gleich bremsen, MAC Adresse bietet auch keinerlei Sicherheit :lol: . Und geht auch durch keinen Poxy oder ähnliches durch.
Wieso nicht einfach den Logintimeout auf eine extrem Hohe Zeit setzen? Bietet meiner Meinung nach die beste Sicherheit bei minimalem Aufwand.
Du logst dich auf einem Gerät ein -> das Gerät bekommt ein Cookie mit einem geheimen Token und ist mit diesem Token für den eingestellten Zeitraum zugriffsberechtigt.
Eine echte Alternative wäre evtl. noch ein Autorisierung mit client certificate, zum Beispiel hier beschrieben:
-
Guddie: Ich bin leider zu "dumm" dafuer, wuerde es aber super cool vinden wen diese whitelist auf MAC adresse reagieren wuerde anstatt von IP damit ist es schonmal sicherer und besser implementierbar.
Ob die function algemein geht weis ich nicht, bekommen den eindruck nein ?
~Dutch `
Da muss ich dich leider auch gleich bremsen, MAC Adresse bietet auch keinerlei Sicherheit :lol: . Und geht auch durch keinen Poxy oder ähnliches durch.
Wieso nicht einfach den Logintimeout auf eine extrem Hohe Zeit setzen? Bietet meiner Meinung nach die beste Sicherheit bei minimalem Aufwand.
Du logst dich auf einem Gerät ein -> das Gerät bekommt ein Cookie mit einem geheimen Token und ist mit diesem Token für den eingestellten Zeitraum zugriffsberechtigt.
Eine echte Alternative wäre evtl. noch ein Autorisierung mit client certificate, zum Beispiel hier beschrieben:
da gebe ich dir recht, aber zurueck zur basis die IP/MAC begrenzung ist nicht fuer externen zugang gedacht.
Es geht mir, und glaube auch anderen, darum das ich eine device in mein netzwerk stellen kan und diese dan zugang zu den sachen hat welchen man moechte ohen user/pass abfrage.
Die umsetzung nach MAC adresse macht es sichere (man in the middle attack) es ist keine definitiefe loesung zur 100% sicherheit.
Wen man in seinem eigenen netzwerk aber dermassen unvertraut ist sind auch andere sachen schief und sollte man auch nicht mit time-out sonder immer username/pass arbeiten.
~Dutch
-
Mac Adresse kann auch von Nachteil sein, da es einige (China?) Geräte gibt, die nach jedem Neustart eine neue MacAdresse generieren.
(Woran man sieht, warum MAC keine wirkliche Sicherheit bietet)
Gruß
Rainer
-
Also unabhängig davon, ob es im Moment so funktioniert wie es soll oder Bugs hat muss ich dein Sicherheitsverständnis kritisieren. Vielleicht habe ich dich auch falsch verstanden, dann helfe ich mit folgenden Anmerkung aber vielleicht anderen Nutzern.
Einerseits möchtest du dich gern nur anhand der richtigen IP einloggen. Dabei sind IPs überhaupt nichts sicheres oder unbekanntes. Jeder kann diese IP annehmen oder auch einfach faken (Stichwort x-forwarded-for).
Andererseits ist es für dich nicht tolerierbar, dass die URL für den Editor ähnlich ist, wie die der fertigen Views. Das ist nun wirklich keine Sicherheitslücke! Eine "geheime" URL darf NIEMALS teil eines Sicherheitssystems sein und bietet keinerlei Sicherheit. Dass man die Editor-URL kennt darf umgekehrt auch auf keinen Fall ein Sicherheitsproblem darstellen. Der Editor muss ganz einfach über geeignete Sicherheitsmaßnahmen vor unbefugten Zugriffen geschützt werden. `
Ich versuch das Problem noch einmal zu beschreiben:
Ich unterscheide hier zwischen User Mode und Editor Mode. Eigentlich sollte ein Editor Mode durch Eingabe eines Namens und ein Passwort geschützt sein. Als Editor habe ich bestimmte Rechte typyischer Weise lesen, schreiben, löschen usw.
Als User habe ich typisch geringere Rechte und darf Elemente nicht verschieben, löschen, neu anlegen usw. eben nur die vorgesehenen Aktionen die im Edit-Mode definiert wurden.
Prinzipiell ist dies auch möglich und wenn man sich die Logik ansieht dann ist das durch Verwendung von https:// und der vorgesehen Authentifizierung umsetzbar. Gleichzeitig laufe ich dann aber in das Problem, dass nicht signierte Zertifikate eine Hinweisfenster im Browser auslösen mit "Sicherheitsrisiko usw.". Das ist nervig und Risiko verbinde ich mit Gefahr und lass mal eher die Finger davon insb. wenn ich mich in einem fremden Netz befinde.
Nun hat Bluefox eine Methode beschrieben wie man User mit Passwort anlegen kann (durch manuelle anlegen einer Authentifizierung). An dieser Stelle vielen Dank für die Kommunikation, war echt top.
Ich habe zum damaligen Zeitpunkt die vis.0-beta verwendet. Nach dem Umzug auf die heutige Version 0.15.0 hat aber genau die Verwendung der Authentifizierung nicht mehr funktioniert und ich bekomme den permission error. Damit sind meine Alternativen aber schon recht klein und ich kann eigentlich nur noch ohne Authentifizierung arbeiten.
Ich habe es dann so gelöst, dass ich ein mod-rewrite auf dem Raspberry eingerichtet habe und über eine kryptische URL z.B. http://gastmodus.html die eigentliche URL z.B. http://192.168.178.10:8082/vis/index.html?Projekt#View aufrufe.
Mod-Rewrite ist aber nur eine Art Forwarding und am Ende sieht man dann doch die gesamte URL im Browser.
Würde nun eine Fremde Person das Wissen haben und "index" gegen "edit" tauschen, dann hat er gewonnen und er ist Editor und dann habe ich verloren. Ich bin aber offen für andere Ideen den Edit Mode zu verbergen, ich kenne aber keine (Das umbenennen von edit.html war leider nicht die Lösung).
Derzeit bin ich noch dran den Proxy-Adapter zu testen, das müsste mir eigentlich erlauben ein gänzlich andere URL zu verwenden. Das wäre dann schon ein riesiger Schritt in Richtung mehr Sicherheit.
Am Ende bleibt aber, die Authentifizierung ist buggy und zumindest mit html nicht verwendbar und https:// ist keine Lösung (siehe oben)
Ich bin gerne bereit Änderungen zu testen, Requirements zu beschreiben wie eine Lösung auszusehen hat. Mich aber in den Code einzuarbeiten und dann auch noch den spezifischen Code zu finden und zu debuggen das geht über meine Möglichkeiten hinaus.
Und wenn sich keiner findet das zu lösen oder besser zu gestalten dann ist das auch ok, aber zu sagen das es derzeit nicht funktioniert und Verbesserungsbedarf vorhanden ist muss auch ok sein. Das ist ja auch wichtig für andere die vor dem gleichen Problem stehen wie ich.
Andreas
-
Mac Adresse kann auch von Nachteil sein, da es einige (China?) Geräte gibt, die nach jedem Neustart eine neue MacAdresse generieren.
(Woran man sieht, warum MAC keine wirkliche Sicherheit bietet)
Gruß
Rainer `
Ehm ja … Ich äussere mich Mal nicht dazu was ich von derartigen China Sachen halte....
Bleib aber bei der Meinung dass Mac sicherer ist als ip und wenn überhauot man darauf bauen könnte oder es halt komplett sein lassen sollte
Send from mobile device
-
Dem eigenen Netzwerk (also hinter einem Router bzw. NAT) grenzenloses Vertrauen schenken ist heutezutage leider auch nicht mehr sinnvoll und kann höchstens eine von mehreren Sicherheitsebenen darstellen. Grund dafür sind die schönen tollen Smart Devices, welche wir uns alle in die Wohnung stellen und welche jede Menge Verbindungen zu Servern im Internet herstellen. Dass diese Geräte dabei alles andere als sicher sind hat sich zuletzt ja mehrfach gezeigt. Auch nicht zu vernachlässigen ist, dass man sich selbst mit nicht hackbaren Geräten zumindest eine Wanze des Herstellers ins Heimnetz setzt.
Das Thema Sicherheit, speziell auch im Heimnetz, wird in der nächsten Zeit immer wichtiger und ein großes Thema sein.
Dass Browser bei selbst signierten Zertifikaten eine Warnung anzeigen liegt daran, dass Zertifikate ohne gültige Signatur keinen Schutz gegen Man-in-the-middle Angriffe bieten. Wenn du vor solchen Angriffen in deinem Privaten Netzwerk keine Angst hast, dann spricht nichts gegen https mit selbst signiertem cert sowie langen login-Timer.
Bei Auth ohne https kann jeder in deinem Netzwerk den Traffic beim einloggen im Klartext mitlesen. Bei selbstsigniertem Zertifikat im Prinzip auch, allerdings mit einem aktiven Man-in-the-middle Angriff.
Dazu leitet der Angreifer den Traffic um und tauscht das Zertifikat aus, so dass du deinen Traffic für ihn verschlüsselst, statt für den echten Server. Das funktioniert, da dein Browser eben nicht bei einer zentralen Zerifizierungsstelle nachfragen kann, ob das Zertifikat zu dem Server gehört (->self signed).
-
OFFTOPIC
Dem eigenen Netzwerk (also hinter einem Router bzw. NAT) grenzenloses Vertrauen schenken ist heutezutage leider auch nicht mehr sinnvoll und kann höchstens eine von mehreren Sicherheitsebenen darstellen. Grund dafür sind die schönen tollen Smart Devices, welche wir uns alle in die Wohnung stellen und welche jede Menge Verbindungen zu Servern im Internet herstellen. `
Stimmt, ich bin dabei nein bisschen paranoide auch wegen meiner Arbeit usw… Solche Teile stehen bei mir nur im DMZ und WiFi ist nur per Radius Server zu benutzen...
Das Thema Sicherheit, speziell auch im Heimnetz, wird in der nächsten Zeit immer wichtiger und ein großes Thema sein. `
Es ist bereits ein riesen Thema auf Security Konferenzen.
War dieses Jahr in America (RSA summit), London (Gartner) und bei einigen kleineren Events van CISSP/CISM/CISCO/IBM usw.
Das Thema ist Hot, sehr Hot sogar….
Leider bekommen wir im privaten Bereich da oft nichts von mit außer anderen schlauen Leuten die auch auf diesem Konferenzen waren und ein halbes Jahr später ein Produkt verkaufen wollen was die Lösung ist..
Ich bemerke leider aber auch das sehr sehr viele privat Personen das nicht so eng sehen, Stecker rein = geht doch....
Wie gesagt ich bin paranoide, devices bekommen bei mir oft nen pentest/fortify/port Test im Lab befor der Stecker rein geht.
( Und ja ich melde bugs bei den Herstellern, aber von 120 vulnerabilty Meldungen in 3 Jahren hab ich insgesamt... 20 fixes gesehen... Die anderen 100 sind immer noch offen, unglaublich diese leichtsinnigheit! )
BACK TO TOPIC
Send from mobile device
