Ankündigung

**Tessi** · 01.03.2011, 10:31

Zitat von swiss Beitrag anzeigen

Leider kann ich auch mit dem PC von ausserhalb auf die GA 1/1/1 zugreiffen und die "Alarmanlage" ausschalten.

Und leider kann der PC bzw. die von ihm verwendete Schnittstelle dabei auch jede physikalische Adresse nutzen/senden. Wer weiß, über welche GA der Befehl gesendet wird, weiß in der Regel auch mit welcher PA dabei gesendet wird und kann die in der eigenen Schnittstelle einstellen. Das das nicht spezifikationskonform ist, weil jetzt zwei Geräte am Bus die selbe PA haben, dürfte einem potentiellen Angreifer ziemlich egal sein - Probleme gibt es ja nur, wenn beide Geräte auch tatsächlich gleichzeitig senden wollen, was hier wohl eher selten passieren wird, und wenn doch, beheben etwas Abwarten und ein paar Versuche das schnell.

**swiss** · 01.03.2011, 12:23

Hmmm...

Da hast du recht. Aber das könnte man vieleicht mit dem überwachen des Routingzählers lösen. Wenn ein Gerät direkt auf dem BUS sendet ist der Routingzähler immer auf 5. Sobald ein Telegramm einen LK (z.B. den IP-Router) passiert, wird der Routingzähler verringert.

**Tessi** · 01.03.2011, 13:50

Wenn es mehrere Linien und LKs gibt, dann sollte man die LKs in so einem Fall so konfigurieren, das nur benötigte GAs durchgelassen werden und die Linie mit den sicherheitsrelevanten Geräten von außen gar nicht zugänglich ist.

Sind aber SCM und Binäreingang in verschiedenen Linien geht das so einfach nicht mehr.
Kann der PC dann direkt auf die Linie des Binäreingangs zugreifen, hilft gar nichts, eine Unterscheidung kann vollständig verhindert werden, s.o.
Kann der PC direkt auf die Linie des SCMs zugreifen, nutzt der Routingzähler möglicherweise nichts, ich bin zwar nicht sicher, kann mir aber vorstellen, das auch dieser per PC mit dem "richtigen" (also ggf. einem gefälschten) Wert versendet werden kann, denn allein schon zu Debug-Zwecken sollte ein gutes Tool so etwas können, irgendwie muß man ja auch die LKs (speziell deren Umgang mit diesem Routingzähler) testen können...
Wer weiß, über welche GA und mit welcher PA der Befehl gesendet wird, kann auch herausfinden, welchen Wert der Routingzähler an der angezapften Linie hat.
Wobei zugegebenermaßen die Sache damit immer komplizierter wird.

KNX ist nun einmal in keinster Weise gesichert - Szenarien wie diese sind nicht vorgesehen.

**swiss** · 01.03.2011, 20:07

Ok. Da hast du auch wider recht. Dann muss ich das Problem auf der LAN Seite lösen. Eventuell mit einer ZyWall und einem eigenen VLAN für das IP-Routing.

**Chris M.** · 01.03.2011, 21:30

Zitat von swiss Beitrag anzeigen

Das WG überwacht die GA 1/1/1. Wenn ein Befehl von der Physikalischen Adresse 1.1.20 (Binäreingang) eingeht, ist alles ok.

Greift ein nicht zugelassenes Gerät auf 1/1/1 zu, soll das WG ein Alarm auslösen (1-Bit auf den BUS). Das gleiche würde ich auch mit dem Türöffner machen.

Ist das so überhaubt mit einem Plugin realisierbar?

Ja, sollte kein Problem sein. Plugin an GA anmelden und dann $msg{'src'} auswerten.

**makki** · 01.03.2011, 21:34

Unabhängig von der geschilderten Problematik: gehen würde das schon, plugin subscriben und:

$msg{'src'} = Quelladresse
$msg{'dst'} = Ziel
$msg{'rcount'} = Routing-counter
auswerten..

Makki

**swiss** · 01.03.2011, 22:15

Danke für die Infos.

Dann werde ich mal versuchen was zu progen.

Den Ansatz mit dem VLAN werde ich aber unabhängig davon auch noch umsetzen.

**makki** · 01.03.2011, 22:20

Sicher kein Fehler, den KNX etwas zu isolieren, zumindest wenn man die Mittel und das Know-How dazu hat

Ist nunmal "by Design" ziemlich sicherheitsfrei, mit einem Vlan & Zugriff per VPN z.B. kann man das aber nachhaltig verbessern.

Makki

**swiss** · 01.03.2011, 22:24

Jup

Mal eine Frage zum programmieren. Gibt es ein HowTo für Plugins? Bei mir scheitert es an der Vorstellungskraft, wie aus dem Script heraus auf den BUS zugegriffen wird.

**makki** · 01.03.2011, 22:37

Zitat von swiss Beitrag anzeigen

Gibt es ein HowTo für Plugins?

Nicht das ich wüsste

Mal so auf die schnelle, funktional ungeprüft:

Code:

# Eigenen Aufruf-Zyklus auf 1T setzen
$plugin_info{$plugname.'_cycle'} = 86400; 
# Zyklischer Aufruf nach restart und alle 86400 sek., dient dem anmelden an die Gruppenadresse, einmalig (0) würde in diesem Fall auch genügen

my $scharf_ga = "1/1/1";
my $allowed_pa = "1.1.20";
my $alarm_ga = "1/1/111";
### Ende Definitionen

if ($msg{'apci'} eq "A_GroupValue_Write" and $msg{'dst'} eq $scharf_ga) {
# $msg{'..'} ist nur mit Telegrammdaten gefüllt, wenn der Aufruf durch ein angemeldetes (plugin_subscribe) Telegramm erfolgte.
# $msg{'apci'} eq "A_GroupValue_Write" stellt sicher, das es nur bei einem Schreibtelegramm ausgeführt wird (nicht _Read oder _Response)
# $msg{'dst'} eq $scharf_ga -> nur bei dieser GA - falls z.B. mehrere GA's subscribed wurden kann man so unterscheiden
   if ($msg{'src'} ne $allowed_pa) {
      # prüft ob physikalische Quelladresse = Vorgabe
      # böser Bube hat von falscher Quelladresse gesendet
      knx_write($alarm_ga,1,1); # schreibe 1 als DPT 1 auf GA
   }
} else { # zyklischer Aufruf
   # Plugin an Gruppenadresse "anmelden", hierdurch wird das Plugin im folgenden bei jedem eintreffen eines Telegramms auf die GA aufgerufen und der obere Teil dieser if-Schleife durchlaufen
   $plugin_subscribe{$scharf_ga}{$plugname} = 1;
}

return;
# verfügbare Daten in %msg:
# $msg{'repeated'} 0/1
# $msg{'sequence'} 0-xxx
# $msg{'buf'} Rohdaten LPDU 
# $msg{'src'} Quelladresse 
# $msg{'tpdu_type'} T_DATA_XXX_REQ
# $msg{'data'} rohe Telegrammdaten
# $msg{'rcount'} Routing-Zähler
# $msg{'apci'} A_GroupValue_Write,A_GroupValue_Read,A_GroupValue_Response (u.v.m)
# $msg{'class'} low/alarm/high/system
# $msg{'dst'} Zieladresse x/y/z
# $msg{'datalen'} Datenlänge
# $msg{'value'} Dekodierter Klartext-Wert (nur falls ESF importiert!)

Makki

**swiss** · 02.03.2011, 19:43

Hallo makki

Danke für die Mühe. Ich erkenne jetzt die Stelle, wo auf den BUS gesendet wird. Wo wird aber auf dem BUS gelesen??? Mir fehlt eine Zeile wie "knx_read GA" oder ähnlich? Sorry für's blöd fragen

, aber wenn ich den Mechanismus verstehe, stehen dann auch Türen für eigene Plugins offen

.

**makki** · 02.03.2011, 20:40

Ich hab oben im Quelltext mal noch etwas mehr erklärungen als Kommentar eingefügt.
Du musst in diesem Fall nicht aktiv lesen (wäre "knx_read(GRPADDR,DPT)"), weil das Plugin beim eintreffen eines Telegramm in dem Hash %msg bereits das Telegramm geliefert bekommt, siehe Anhang oben.

Makki

**swiss** · 02.03.2011, 20:48

Danke

Jetz habe ich es auch verstanden. Das bedeutet, dass die Datenabfrage extern läuft, und wenn ein Telegramm auf einer angemeldeten GA eintrifft, wird das Plugin automatisch aufgerufen!? Oder ist das Script einfach in einer Endlosschlaufe und belastet den Prozessor?

Und gleich noch eine kleine Verständnissfrage...

knx_write($alarm_ga,1,1); # schreibe 1 als DPT 1 auf GA

Sind die DPT nach EIS hinterlegt? Also EIS1 = 1bit, EIS2=4bit (dimmen auf/ab), EIS6=8bit Wert usw...?

**makki** · 02.03.2011, 20:59

Es läuft intern quasi ein KNX-Busmonitor, bei eintreffen eines Telegramms wird geprüft ob ein Plugin daran angemeldet ist und das dann ggfs. aufgerufen.

Und das Telegramm ins Log geschrieben, ggfs. ein Lesetelegramm für Uhrzeit, 1-Wire usw. beantwortet etc..
Und da liegt auch die Limitation, wenn ein Plugin recht lange für irgendwas braucht, laufen solange andere nicht; es gehen aber keine Telegramm verloren..

Der zyklische Aufruf von Plugins wird aber auch ca. jede Sekunde ohne eintreffende Telegramme überprüft, das "kostet" nichts..

Edit
EIS = alt
DPT = neu
hier oder im Lexikon ist auch ein Link mit kompletter Liste von der Konnex..

Makki

Ankündigung

Sabotageüberwachung mit dem WG

[wiregate] Sabotageüberwachung mit dem WG

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar