LoxBerry
Space shortcuts
Page tree
Skip to end of metadata
Go to start of metadata
Autor

Christian Fenzl

Logo

Status

RELEASE

Version0.2.2
Min. LB Version

LB 0.2.3

Downloadhttps://github.com/christianTF/LoxBerry-Plugin-Any/archive/0.2.2.zip
ZweckMit dem Plugin können am LoxBerry Shell-Befehle ausgeführt werden.
LanguagesEN, DE
Diskussionhttps://www.loxforum.com/forum/projektforen/loxberry/plugins/124449-plugin-any-plugin-f%C3%BCr-loxberry
 Version History...

Version 0.01

  • Entwicklung

Version 0.02

  • Lauffähiger Stand

Version 0.04

  • Es können im Kommando für die Rückgabe unterschiedliche Miniserver adressiert werden
  • Das Plugin prüft und meldet in Klartext, ob der Socket schon belegt ist (weitere Instanz läuft?)
  • Ping-Funktion

Version 0.1.1 UNSTABLE

  • Erster UNSTABLE Release
  • Webinterface fertig

Version 0.1.2 UNSTABLE

  • Besseres Service-Handling
  • Es wird eine genauere Fehlermeldung ausgegeben, warum kein TCP-Socket geöffnet werden kann
  • Jeder Output wird in /opt/loxberry/log/plugins/anyplugin/tcp2shell.log ausgegeben

Version 0.1.3 UNSTABLE

  • Logfile-Button im GUI

Version 0.1.4 RELEASE

  • Speichere deine eigenen Scripts in /opt/loxberry/data/plugins/anyplugin/commands
  • Das ist jetzt der Standardpfad für die Ausführung von Scripts
  • Beim Neustart des Services ("Speichern" im WebUI) werden die Scripts automatisch executable (+x) gesetzt.
  • Beim Ausführen: "Punkt Slash" vor dem Scriptnamen nicht vergessen!
  • Die Scripts werden bei einem Plugin-Update gesichert und wiederhergestellt.
  • Wesentlich verbessertes Logging

Version 0.2.0 Pre-Release

  • Any-Plugin ist jetzt multithreaded
    • Während Commands ausgeführt werden, bleibt das Plugin für neue Verbindungen verfügbar.
    • Mehrere Commands werden parallel ausgeführt.

Version 0.2.1 RELEASE

  • Introduced multi-language support (use the Translate widget to translate to your own language)
  • Basic languages are English and German
  • Removed fields from the form that currently are not available
  • Fixed minor form and spelling mistakes.

Version 0.2.2 RELEASE

  • Fixes a major bug introduced with 0.2.1 (by removing a form field from the WebIf), that the security_mode=UNSECURE parameter was deleted on WebIf-Save. As currently only the UNSECURE mode is implemented, this leads to deny every command (if you never have saved the config, this did not apply to your installation).
  • Enhances trimming of the input line - \r\n are now stripped of the input line, making tests with telnet more easy. It tooks me hours to study an own issue using telnet, but telnet also under Linux, telnet closes with \r\n and no command worked.
  • Also therefore, enhanced logging to the logfile

Artikel-Updates

Lass dich über Updates in diesem Artikel informieren, indem du rechts oben im Menü auf Beobachtung klickst.

Inhalt


Sicherheitshinweis

Dieses Plugin ist nur für Benutzer mit Linux-Erfahrung geeignet. Durch die eingeschränkten Möglichkeiten des Loxone Miniservers ist keine ausreichend sichere Kommunikation zwischen Miniserver und LoxBerry möglich.

Trotz der eingebauten Sicherheitsfunktionen (Einschränkung auf Quell-IP-Adressen, Einschränkung auf das eigene Subnet) könnte ein Eindringling mit einem gezielten Angriff (IP-Spoofing) die Kontrolle des LoxBerry's übernehmen und damit Zugriff auf Miniserver-Zugangsdaten erhalten.

Download

Alle Releases: https://github.com/christianTF/LoxBerry-Plugin-Any/releases

Dort beim aktuellsten Release

  • entweder den "Source code (zip)" herunterladen, am LoxBerry auswählen und installieren,
  • oder den "Source code (zip)"-Link in die Zwischenablage kopieren, diesen in der Pluginverwaltung bei der URL einfügen, und installieren.

Repository bei Github: https://github.com/christianTF/LoxBerry-Plugin-Any

Installation

Das Plugin kann normal installiert werden. Nach der Installation muss der LoxBerry neu gestartet werden. In LoxBerry muss ein Miniserver konfiguriert sein, an den die Antwort gesendet wird.

Funktion des Plugins

Mit dem Plugin wird ein TCP-Port geöffnet, mit dem der Miniserver mit dem Plugin kommunizieren kann.

Über diesen Port können direkt Shell-Kommandos (Phase 1) oder vordefinierte Makros (Phase 2) aufgerufen werden.

Bei jedem Aufruf kann als Parameter übergeben werden, ob der Return-Code des Aufrufs in einen virtuellen Eingang, oder der Output des Aufrufs per UDP übermittelt werden soll.

Senden von Kommandos (Loxone Config)

Virtuellen Ausgang einrichten

Dafür einen Virtuellen Ausgang erstellen:

EigenschaftWertAnmerkung
Bezeichnung und BeschreibungNach BeliebenIst für die Funktion nicht relevant
Adressetcp://<loxberry>:9095<loxberry> ist der Hostname oder die IP des LoxBerry. Der Port ist als Standard 9095. kann aber in der Plugin-Konfiguration geändert werden
Verbindung nach Senden schließenAktiv

Virtuellen Ausgangsbefehl anlegen

Einen virtuellen Ausgangsbefehl anlegen und bei Befehl bei EIN das Any-Kommando eingeben.

Die Syntax sieht so aus:

<Eindeutiger_Name> <Rückgabemodus> command <Shell-Befehl>

<Eindeutiger_Name> <Rückgabemodus> macro <Makro-Name>   (Makros noch nicht implementiert!)

Hier die ausführliche Parameterbeschreibung

Parameter

1.Parameter

<Name>Ein eindeutiger Name, um den Request zu identifizieren. Der Name wird für die Rückgabe verwendet.
2.Parameter

off

rc

udp

rcudp

rc.2/udp.2/rcudp.2

→ Das Ergebnis des Aufrufs wird nicht zurückgeliefert.

→ Der Exit Code des Aufrufs wird in einen virtuellen Eingang mit der Bezeichnung <Name> geschrieben.

→ Der Output des Scripts wird per UDP an den Miniserver gesendet.

→ Der Exit Code wird in <Name> geschrieben und der Output per UDP gesendet.

→ Bei dieser Angabe wird die Rückgabe an den zweiten (dritten, vierten usw.) Miniserver gesendet.

3.Parameter

command <Shell-Befehl>

makro <Makroname>

ping

→ Der Befehl nach "command" wird komplett am LoxBerry ausgeführt.

→ Das Makro namens <Makroname> wird ausgeführt. (noch nicht implementiert!)

→ Entsprechend des Sendetyps wird die aktuelle Epoch-Time am LoxBerry übermittelt.

Beim Rückgabetyp (rc, udp oder rcudp) kann die Sequenz "Punkt Nummer" (z.B. rc.2 oder udp.1) für die Miniservernummer (von LoxBerry) mitgegeben werden, um jenem die Antwort zu senden. Wird dies nicht angegeben, wird immer der erste Miniserver verwendet. 

Beispiel:

# Sendet das Directorylisting per UDP
Dir_Listing udp command ls -l
 
# Sendet den Linux Hostnamen per UDP und setzt den Exit Code des Aufrufs in den virtuellen Eingang <LB_Hostname>
LB_Hostname rcudp command hostname
 
# Sendet die Linux Epoch-Zeit an den virtuellen Eingang <LB_Epoch>
LB_Epoch rc.1 ping
 
# Sendet die Zeit in Sekunden seit dem letzten Miniserverbackup (Plugin) per UDP an den _dritten_ Miniserver (001_MSOG ist das Backupverzeichnis)
LB_Hostname udp.3 command echo $(($(date +%s) - $(date +%s -r /opt/loxberry/webfrontend/html/plugins/miniserverbackup/files/001_MSOG)))


Konfigurationsoptionen


In der Plugin-Konfiguration kann definiert werden, welche Sicherheitsstufe vom Plugin angewendet wird:

Security Mode (security_mode=)

Beschreibung
UNSECURE (default)Shell-Kommandos können direkt übergeben werden und werden ausgeführt. Das ist unsicher, da am LoxBerry jeglicher Befehl ausgeführt werden kann. (PHASE 1)
RESTRICTEDIn der Plugin-Konfiguration am LoxBerry werden Shell-Befehle als Makros vordefiniert. Nur diese Makros dürfen ausgeführt werden. (PHASE 2)
Authentifizierung (authentication=)Beschreibung
off (default)Es gibt keine Authentifizierung. Alle Kommandos werden entsprechend des Security Mode ausgeführt.
on

Eine 2-Phasen-Authentifizierung soll sicherstellen, dass der Aufruf tatsächlich vom Miniserver kommt.

IDEEN Wer hier eine gute Idee hat, die aus Ausführen von TCP-Befehlen in Loxone nicht sehr verkompliziert, bitte melden!

Auf Subnet einschränken (restrict_subnet=)Beschreibung
offDas Subnet des Clients wird nicht geprüft.
on (default)Nur Clients aus dem gleichen Subnet dürfen sich anmelden.


Auf IPs einschränken (allowed_remote_ips=)Beschreibung
leer (default)Keine Einschränkung auf einzelne IPs
<IP1>, <IP2>, <IP3>Eine mit Komma getrennte Auflistung von IP-Adressen (z.B. 192.168.1.77, 192.168.1.78).
Der Filter sollte grundsätzlich auch mit IPv6 funktionieren, ist aber damit noch nicht getestet.

Eigene Scripte erstellen und ausführen

Das Plugin erzeugt bei der Installation das Verzeichnis /opt/loxberry/data/plugins/anyplugin/commands (bzw. von Windows aus: \\loxberry\loxberry\data\plugins\anyplugin\commands).

In diesem Verzeichnis können eigene Shell-Scripts erstellt werden - das Verzeichnis wird bei einem Plugin-Update gesichert.

Der Pfad ist auch der Standardpfad, wenn kein Pfad bei der Ausführung mitgegeben wird. Achte deswegen darauf, dass du ./deinscript.sh angibtst (Punkt Schrägstrich), damit das Script ausgeführt wird. Bei Scripts in anderen Pfaden musst du den vollen Pfad beim Aufruf mitgeben.

Da die Dateien im commands-Verzeichnis, von Windows aus erstellt, nicht executeable sind, setzt das Service bei jedem Neustart alle Scripts auf Executeable (+x). Dafür musst du nur "Speichern" im WebUI drücken.

Beim Bearbeiten von Scripts von Windows aus beachte, dass der Zeilenumbruch unter Linux anders ist. Ich empfehle zum Bearbeiten von Scripts unter Windows den Editor Notepad++. Im Menü Bearbeiten / Format Zeilenende kannst du Konvertiere zu UNIX ausführen, um das richtige Format zu haben. Stelle den Zeichensatz einer neuen Datei außerdem auf UTF-8 (UTF-8 ohne BOM).

Roadmap

Phase 2 wird erst fortgesetzt, wenn LoxBerry 0.3 released it, und wenn zum Plugin mehr Feedback da ist. Fehler werden gefixt.

PHASE 1

  • DONE Direkte Aufrufe von Shell-Commandos per TCP (UNSECURE mode). 
  • DONE Rückgabe des Exit-Codes
  • DONE Rückgabe des Aufruf-Outputs per UDP
  • DONE Webinterface zur vollständigen Konfiguration des Plugins

PHASE 2

  • DONE Sicherheit: Einschränkung auf Quell-IP-Adressen
  • DONE Sicherheit: Einschränkung auf das eigene Subnet
  • DONE Sicherheit: Wahlweise Ausführung als User loxberry oder root
  • OPEN Konfiguration von Makros am LoxBerry möglich (RESTRICTED mode)
  • OPEN Service-Healthcheck direkt am LoxBerry
  • DONE Service-Healthcheck vom Miniserver aus ("ping")
  • OPEN Parsen von #Name# and #Value# in Makro-Definitionen zum Einsetzen des Namens und des übergebenen Analogwertes

PHASE 3

  • DONE Ausführung der Commands als eigener Prozess (fork)
  • OPEN Sicherheit: Authentifizierung mittels Handshake.
  • OPEN Erweiterung der Makrofunktion um Variablen → Im Makro können mehrere Loxone-Werte ausgewertet und im Befehl verwendet werden
    • #TempWohnzimmer# liest das Loxone-Element "TempWohnzimmer" und setzt es als Wert in den Aufruf ein
    • #MS2.TempWohnzimmer# liest das Loxone-Element "TempWohnzimmer" vom zweiten Miniserver 

Fragen stellen und Fehler melden

Fragen stellen im LoxForum Thread: https://www.loxforum.com/forum/projektforen/loxberry/plugins/124449-plugin-any-plugin-f%C3%BCr-loxberry

Fehler melden im GitHub Repo: https://github.com/christianTF/LoxBerry-Plugin-Any/issues



10 Comments

  1. SirRules

    IDEEN Wer hier eine gute Idee hat, die aus Ausführen von TCP-Befehlen in Loxone nicht sehr verkompliziert, bitte melden!

    Christian Fenzl Die SSH-Befehle White-zu-listen (Makrofunktion) oder generell mit zusätzlicher Authentifizierung zu versehen finde ich klasse.

    Ich hätte da eine Idee, die nicht allzu kompliziert wird (in der Loxone App).


    Schritt 1:

    Loxberry beibringen, sich per SSH + One Time Passwort authentifizieren zu können. Dafür müsste man irgend ein OTP-Gerät im Loxberry anlernen, z.B. den Google Authentificator oder ähnliche Apps. Siehe z.B. hier: https://www.thomas-krenn.com/de/wiki/SSH-Login_mit_2-Faktor-Authentifizierung_absichern

    Das ganze sollte dann auch schön in Loxberry in die GUI eingebaut werden, sodass man dort das Secret ins Handy abtippen oder den Barcode direkt abscannen kann und schließlich das erste OTP von  der Handy App wieder in Loxberry eingibt und somit die Einrichtung von OTP abschließt.

    Dann brauchst du noch einen weg, eine loxberry-Betriebssystem-Kommand mit erzwungener OTP-Abfrage aufrufen zu können, notfalls SSH@localhost, dann müsste die OTP abfrage kommen...


    Schritte 2:

    Um das ganze möglichst einfach Bedienbar für die Loxberry-App zu integrieren, wäre (neben einem Auslösenden Button o.ä.) eine Möglichkeit für das eingeben des OTP-Tokens vom Google Authentificator in die Loxone App nötig. Am besten wäre hier ein User Input Dialog - dazu habe ich habe nichts im Netz gefunden...

    Eine Alternative, die immernoch handelbar wäre - ist das einbauen von einem Tastenfeld, das in etwa so aussieht:

    01#23456789
    0#123456789
    012#3456789
    0123#456789
    0123#456789
    01234567#89


    Der User klickt dann die einzelnen Buttons so, wie der OTP-Token gerade angezeigt wird. Im Beispiel oben mit # markiert wurde das OTP 213448 vom Google Authentificator angezeigt und entsprechend eingetippt.


    Schritt 3:

    Bei Knopfdruck fragt Loxone die 60 Buttonzustände ab und erhält somit den aktuellen OTP-Code.


    Optimierungen:

    • Im Loxberry müsste man bei dem OTP-Dienst bestimmt einstellen können, dass die letzten X OTPs ebenfalls akzeptiert werden. D.H- der User könnte sich in Loxberry einstellen, wie lange die Tokens gültig sein dürfen. Wenn z.B. 1 Tag gewählt wird, muss man nur 1x am Tag einen beliebigen OTP-Token in die Lox-App eintippen und dieser Wert kann dann den Rest vom Tag als valides OTP weiterverwendet werden.
    • Möglicherweise kann  man auf das OTP "eingeben" ganz verzichten. Es gibt ja Authentificator-Apps, die einfach eine "JA/NEIN" notification an den User schicken. Je nachdem was er klickt wird der Request (nicht) authentifiziert. Das würde allerdings die Netzwerktechnische Errechbarkeit des loxberrys für den Auth-Dienst voraussetzen..


    1. Christian Fenzl

      Für eine Schnittstelle ist eine Auth mit wiederkehrender Interaktion eher ungeeignet. Das muss schon automatisch funktionieren, und das mit den beschränkten Mitteln des Miniservers. Es geht mir im die Sicherstellung, dass ein Befehl von einem Miniserver kommt, und nicht von einer Shell auf einem beliebigen PC. Und die (unverschlüsselte) Kommunikation soll nicht reproduzierbar sein, ein normaler, statischer Token reicht nicht aus.

      1. SirRules

        Hmm alles was mir sonst einfällt, stößt an die Grenzen des Miniservers (keine Texteingabemöglichkeit, keine Möglichkeit User-Zertifikate zu verwalten, kein SSO-Modul implemenitert, kein OTP-Modul Implementiert).

        Vllt. mit PicoC-Script ein OTP-Modul implementieren.. (big grin)

  2. SirRules

    Noch ein paar Ideen:

    Mit Scripting:

    • Wenn du herausfindest, wie man mit PicoC-Script RSA-Signaturen (mit dem Server-Zertifikat, das vom User selbst oder (default:) Loxone-Cloud geploeyd wird) erstellt, kann du ein Kommando ganz einfach vorher signieren und Loxberry könnte mit dem Public-Key die Signatur (kann man über Loxone-Api abfragen) verifizieren. Damit wäre die Identität des Abesenders (Loxone) am besten sichergestellt.
    • Ebenso, falls du solche eine Funktion per PicoC-Script findest, wäre es mit symmetrischer Krypto möglich, wenn es eine HMAC-Funktion gibt. Dann müsste zwischen Loxberry und Loxone noch ein Shared Secret ausgetauscht werden (im Loxone z.B. direkt im Script hinterlegt)
    • Tan-Liste implemeniteren

    Mit Bausteinen:

    • Wenn ein Betriebssystemkommando (BSK_loxb)  von Loxone an Loxberry gesendet wird, wird gleichzeitig irgend eine Variable gesetzt. Diese sollte über einen virtuellen Ausgang abgefragt werden können. Sobald Loxberry einen Command erhält, müsste Loxberry direkt danach zur simplen Verifizierung (ob Loxone es ausgelöst hat) diesen Eingang/Variable beim Loxone-Ausgang abfragen. Am besten enthält die Variable genau den Command BSK_loxb, dann kann Loxberry nochmal vergleichen ob die beiden Infos gleich sind. Nach der erstmaligen Abfrage sollte die Variable aber wieder zurückgesetzt werden (Einmalabfrage).
      • Sicherheitsproblem: Leider wäre es jetzt dennoch mit IP-Spoofing möglich auch diese Abfrage eines virutuellen Ausgangs zu fingieren, d.h. Angreifer sende Command und Anwortet den Command bei Verifizierungsanfrage des LoxBerrys. Kein wirklicher Sicherheitsgewinn.
    • Um das Sicherheitsproblem zu lösen wäre folgendes nötig: (#XXXX# verweißt auf Kapitel in https://www.loxone.com/dede/wp-content/uploads/sites/2/2020/05/1100_Communicating-with-the-Miniserver.pdf#page21)
      • Verschlüsselung:
        1. Miniserver ab Version 2 kann auf HTTPS oder WSS zurückgreifen, um die Verbindung zu verschlüsseln. Loxberry sollte dann den Finderprint des Zertifikates speichern und Certificate Pinning implementieren, um das austauschen des Zertifikates durch eine MitM-Attack zu verhindern. Mehr Infos zu HTTPs/WSS im Kapitel #Using HTTPS/WSS#
        2. Miniserver Version 1 (>= v8.1) (bzw. für eine Rückwärtskompatible Implementierung): **Ich gehe davon aus, dass auch Loxone MiniServer Version 1 bereits ein Zertifikat erhalten kann  (bin mir da aber nicht so sicher; HTTPS/WSS kann es auf jeden Fall nicht; in der Anleitung steht ab v8.1 - das würde bedeuten, dass es seit v8.1 ein Zertifikat gibt), vgl. #Command Encryption#
          1. Command kann symmetrisch verschlüsselt übertragen werden, siehe #Command Encryption#.
          2. Command kann asymmetrisch verschlüsselt übertragen werden, siehe #Command Encryption#.
      • Ob nun über 1) oder 2a) oder 2b), LoxBerry müsste noch das folgende Sicherstellen:
        1. Es wird im Loxberry ein zufälliges frisches Token T_loxb erzeugt.
        2. T_loxb wird über einen verschlüsselten Weg (1,2a,2b) an Loxone als Teil eines Commands übertragen.
        3. Loxone entschlüsselt den Command (und das darin enthaltene T_loxb)
        4. Der Command sollte nun den Token T_loxb verarbeiten können und zusätzlich das ursprüngliche Betriebssystemkommando BSK_loxb mit in eine Respone R_lox einbauen können.
        5. Loxone sendet das R_lox als Respone an Loxberry. Es enthält T_loxb als Beweis, dass es den (a)symmetsichen Key kennt (proof of possession) und das Betriebssystemkommando BSK_loxb zur Bestätigung der Integrität des Betriebssystemkommandos.
        6. Loxberry verifiziert, ob das T_loxb aus der Response dem gesendeten T_loxb entspricht. Loxberry verifiziert, 
        7. ob das BSK_loxb aus der Response dem zuvor empfangenen BSK_loxb entspricht.
        8. Wenn 6 und 7 erfolgreich ==> Command ist authentifiziert und kann ausgeführt werden. Andernfalls nicht.

    Wichtige Hinweise:

    • Um Replay-Attacks zu vermeiden sollte T_loxb immer frisch und niemals das gleiche sein. Auch die Salts (vgl. Kapitel #Command Encryption#) sollten immer gewechselt werden.
    • Falls Loxone die Strings (command BSK_loxb bzw. T_loxb) nicht verarbeiten kann und mit reinen Zahlen (0,1,2) gearbeitet werden muss, wäre nur noch über einen Zero-Knowledge-Proof möglich, zu prüfen, ob irgendein Kommando versendet wurde.
      • "irgendein", weil ohne Stringvergleich die Integrität des Kommandos nicht überprüft werden kann. Man kann dann nur prüfen, ob vor kurzen irgendein Kommando ausgelöst wurde und nach einer Erfolgreichen Prüfung sollte der Werte der Variablen schnell wieder zurückgesetzt werden).
      • Um den Zero Knowledge-Proof durchzuführen wären N Abfragen nötig, ob den Besitz des Schlüssels zusammen mit der gesetzten Variablen (Befehl wurde ausgelöst=True) zu beweisen.
        • N gibt dabei die Anzhal der Wiederholungen an, für die der Beweis erbracht werden soll. Je höher N, desto unwahrscheinlicher, dass ein Angreifer das Ergebnis mehrmals richtig errät.
        • Der Proof könnte in etwa so ablaufen:
          • Loxberry generiert zufällige Zahl RAND_loxb 0 oder 1 und sendet diese verschlüsselt an Loxone
          • Loxone berechnet Response_lox = RAND_loxb + Varable und Antwortet Ergebnis an Loxberry. Die Variable ist 1 wenn Kommando ausgelöst wurde und 0 wenn gerade kein KOmmando ausgelöst wurde
          • Loxberry prüft: Ist RAND_loxb +1 == Response_lox. Nur wenn also Variable=1 ist und auch genau der RAND_loxb verrechnet wurde, ist die Prüfung erfolgreich. Sobald 1x eine falsche Antwort kommt oder Response_lox=0 ist, wird der Authentifizierung komplett abgebrochen.
          • wiederhole N mal. Nach N-ter erfolgreicher Prüfung ist die authentifizierung erfolgreich und BSK_loxb darf ausgeführt werden
        • Beispiel valide (RAND_loxb | senden Loxberry → Loxone | senden Loxone → Loxberry | algorithmus-info) bei N=3 und Variable=1
          • 0 | 0 | 1 | valid (1 from 3)
          • 1 | 1 | 2 | valid (2 from 3)
          • 0 | 0 | 1 | valid (3 from 3)
        • Beispiel manipuliert/geraten (RAND_loxb | senden Loxberry → Loxone | senden Loxone → Loxberry | algorithmus-info) bei N=3 und Variable=1
          • 0 | 0 | 1 | valid (1 from 3)
          • 1 | 1 | 2 | valid (2 from 3)
          • 1 | 1 | 1 | Error: not valid (attacker may has tried to guess RAND_loxb or Variable is not 1) ==> ABORT ALGORITHM
        • Beispiel Variable nicht aktiv (RAND_loxb | senden Loxberry → Loxone | senden Loxone → Loxberry | algorithmus-info) bei N=3 und Variable=0
          • 0 | 0 | 0 | Error: not valid (attacker may has tried to guess RAND_loxb or Variable is not 1) ==> ABORT ALGORITHM
        • Beispiel2 Variable nicht aktiv (RAND_loxb | senden Loxberry → Loxone | senden Loxone → Loxberry | algorithmus-info) bei N=3 und Variable=0
          • 1 | 1 | 1 | Error: not valid (attacker may has tried to guess RAND_loxb or Variable is not 1) ==> ABORT ALGORITHM

    Sicherheitsgarantien:

    • Integrität des Betriebssystemkommandos
      • erfüllt für blau oben
      • nicht erfüllt bei Zero Knowledge-Proof, da nur mit Zahlen gerarbeitet wird
    • Authentisierung des Senders
      • erfüllt für blau oben
      • nicht erfüllt bei Zero-Knowledge-Proof, da es eine gewisse Zeit gibt wenn Loxone ein echten Kommando absendet und auf Authentorisierung wartet, in der ein Angreifer einen zweiten Command senden könnte, der dann auch authentifiziert werden würde. Allerdings muss man bedenken, dass für das Faken eines Commands inkl. Whitelisting der Loxone IP im Loxberry IP-Spoofing nötig wäre. Insofern der Angreifer sich in einem anderen Netzwerk befindet, wird der Router das Paket mit den Zero-Knowledge-Proofs entweder an den Angreifer oder an den Loxone schicken. IP zu spoofen, Kommando zu faken (solange Variable aktiv ist) und dann IP-Spoofing beenden, sodass Loxone den Zero-Knowledge-Proof durchführt könnte vermutlich die Attacke unwahrscheinlicher machen, falls der Router die MAC-Adressen bei Spoofing nicht sehr schnell ändert (bin mir nich sicher, wie lange das dauert - umso länger umso besser für einen nicht erfolgreichen Angriff).
    • Verschlüsselung der Kommunikation zwischen Loxberry → Loxone
    • Schutz vor Replay-Angriffen
    • Schutz vor Man-In-The-Middle-Angriffen (nicht bei Zero Knowledge)

    1. SirRules

    2. Christian Fenzl

      Das ist praktisch leider nicht umsetzbar.
      Es ist in Loxone schon ein Problem, zwei Analogwerte in einem Request zu übermitteln. Abgesehen davon, dass die ganzen Algorithmen dem Endbenutzer gar nicht zur Verfügung stehen, ist es für einen Endbenutzer kaum umsetzbar, einen derartigen Handshake in Logik zusammenzuklicken.
      Was mir gut gefällt, ist das simple Validieren des Commands durch Rückfrage. Aber selbst da bist du auf MS-Seite schon wieder am Ende mit der Funktionalität.

      1. SirRules

        Hmm, so langsam lerne ich die Einschränkungen etwas besser kennen. Text zu verarbeiteten schein (ohne Zahlengewusel und ASCI-Chararacterkonvertierungsbausteinchaos) nicht zu gehen.

        Was mir gut gefällt, ist das simple Validieren des Commands durch Rückfrage. Aber selbst da bist du auf MS-Seite schon wieder am Ende mit der Funktionalität.

        Um das ganze etwas simpler zu gestalten, bezogen auf deinen letzten Satz; folgendes sollte doch lösbar sein:

        • Betriebssystemkommando an Loxberry senden und in eine neue Logdatei schreiben
        • Loxberry liest Logdatei aus Loxone aus und löscht diese danach. Auch wenn das Betriebssystemkommando (als String) hardcoded vom Endbenutzer im Log-Baustein wiederholt werden müsste, wäre das sehr einfach und usable. Der Command ändert sich ja nicht dynamisch. Den Rest macht Loxberry/AnyPlugin. Ggf. muss man noch ein Logdatei-Namensschema vorgeben.
        • Das Sicherheitsproblem von oben bleibt aber, da ein Angreifer per IP-Spoofing das ganze API-Abgefrage ohne wirkliche Krypto dazuschen alles selbst fälschen könnte.
          • Um dem etwas entgegenzuwirken: Es wird ein Shared-Secret wie oben in eine Datei auf dem Loxone geloggt. Die Datei dann nicht löschen, aber jedes mal von Loxberry aus mit Abfragen, um den Miniserver (statt einen IP-Spoofenden Angreifer) zu identifizieren. An das Shared Secret kommt ein Angreifer ohne Loxone-Login-Credentials durch den Loxone Miniserver vermutlich nicht dran / bin mir nicht sicher wie der Zugriffsschutz für Logdateien ist. Ein neues Problem wäre aber die Übertragung des Shared Secrets im Klartext von Loxone zu Loxberry. Das lässt sich abfangen und da es sich nie ändert spoofen... also auch nichts gewonnen...

        1. SirRules

          Das ist praktisch leider nicht umsetzbar.

          Es ist in Loxone schon ein Problem, zwei Analogwerte in einem Request zu übermitteln. Abgesehen davon, dass die ganzen Algorithmen dem Endbenutzer gar nicht zur Verfügung stehen, ist es für einen Endbenutzer kaum umsetzbar, einen derartigen Handshake in Logik zusammenzuklicken.


          Ich habs geschafft den Token als Text von Loxberry zu Loxone zu übertragen und wieder abzufen.

          Hier ein kleiner Proof of Concept. Es wurde per MQTT eine Variable im Loxberry gesetzt (geht auch ohne MQTT, war aber gerade schneller zu testen), über einen Eingang am Loxone kann der String verarbeitet werden, vgl. dazu Liveview-Screenshot von den beiden Bausteinen. Der Text wird dann in einen eigenen Logger geschrieben. Von der Datei wird der Text dann über die API von Loxberry gelesen (authentifizierung notwendig (smile)). Token sollte dann inkl. Logdatei danach wieder gelöscht werden.

          Wenn du noch folgendes baust, wäre es gelöst:

          • Test über einen der verschlüsselten Wege den Loxone-Command-Aufruf mit dem Token machen
          • Der Command, der authentifiziert werden soll, sollte auch in die gleiche Logdatei geschrieben werden (nur darf das nicht von Loxberry sondern muss von Loxone reingeschrieben werden; sonst macht der Vergleich der Integrität am Ende wenig sinn)
          • Loxberry-Gegenstück im Loxberry-Plugin bauen (Token generieren, per verschl. Request an Loxone übertragen, Token und Command abrufen und verifizieren)
          • DONE (smile)

          Einrichtungsaufwand für Enduser je Command:

          • Logger anlegen
          • Command als String in Logger loggen
          • Virtueller Eingang für Token anlegen und mit Logger verbinden


          1. Christian Fenzl

            Da muss ich drüber nachdenken! Das hört sich nicht so schlecht an!

            Wir haben in LoxBerry noch keinen verschlüsselten Weg von und zum Miniserver.

            Wir brauchen TLS am LoxBerry, das würde vieles vereinfachen.

            1. SirRules

              „Zum Miniserver“ bringt nichts weil Loxone glaube ich immer noch keine Https-Seiten aufrufen kann. Dafür gibt’s auch ein Loxberry Plugin, das tls am loxberry terminiert und dann die webseite per http unverschlüsselt zum loxone durchstellt.

              Also bleibt momentan leider nur „vom Miniser zum Loxone“ per TLS übers Loxone-Zertifikat (bei neueren Miniservern) verschlüsselt oder für die älteren Miniserverversionen noch über AES-Verschlüsselung. Eben über 1,2a,2b.