Böse: Störsender auf 433 / 868 MHz, erkennen wir das ?!

Begonnen von JoWiemann, 10 Mai 2016, 20:21:11

Vorheriges Thema - Nächstes Thema

JoWiemann

Hallo,
mittlerweile werden wir immer abhängiger von unseren funkbetriebenen Sensoren und Aktoren. Einige von uns setzen diese Komponenten auch für Alarmzwecke ein.

Nun stellt sich mir die Frage: ,,Wer hindert eigentlich ein böses Mädel oder einen bösen Buben daran die Sensoren und Aktoren mit einem starken Sender in den Frequenzbereichen zu überlagern, um dann hier verwerfliches Werk zu beginnen?"

Bisher wohl Niemand. Selbst bei  kommerziell vertrieben Alarmanlagen habe ich noch nicht von einer Erkennung von Störsendern und der damit verbundenen Alarmauslösung gelesen.

Meine Idee/Frage: ,,Kann eine solche Funktion in die Firmwares  der CUL, Signalduino usw. integriert werden?!"

Frequenzstörungsfreie Grüße
Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Icinger

Erste Idee:
Du könntest ein Notify auf readings verschiedener Sensoren machen, welche (halbwegs) regelmäßig senden.
In dem Notify dann einen Zähler laufen lassen.
Und auf diesen Zähler zB nen Watchdog setzen.

Wenn jetzt keine neuen Readings reinkommen, kannst davon ausgehen, dass entweder das Signal gestört ist oder der Empfänger kaputt.
Dass die Batterien bei verschiedenen Sensoren gleichzeitig leer werden, ist ja eher unwahrscheinlich.

lg, Stefan
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

JoWiemann

Hallo Stefan,

nun, die Idee ist nicht schlecht, aber...

Die meisten Sensoren senden eher im 5 Minuten, wenn nicht noch länger, Bereich. Bis genug Informationen für die Vermutung eines Störsenders vorliegen ist das was, schnell greifbar ist, schon auf dem Beuteweg.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

betateilchen

Klingt mir ein bisschen nach Verfolgungswahn. Sorry.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

CoolTux

Nunja, nennen wir es ein theoretisches Szenario  ;)
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

betateilchen

Du meinst so, wie die immer wieder auftretende Frage, was mit den letzten drei Buchungssätzen in einem EDV System passiert, wenn ein Flugzeug auf das Bürogebäude stürzt, in dem der Computer steht?

Achso... na dann.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

JoWiemann

Nun ja, ich kann mich an eine Zeit erinnern, da waren Bankautomaten völlig sicher, bis jemand auf die Idee mit den Kameras und vorgeschraubten Lesegeräten kam!

Oder, heute macht sich kaum einer Gedanken über Außensteckdosen, da die meisten Einbruchswerker ja doch Stemmeisen oder Akku-Werkzeug benutzen. Aber was, wenn alles Sicherheitseinrichtungen durch das Auslösen des FI an der Außensteckdose außer Betrieb gesetzt werden.

Also keine Paranoia, sondern: Was möglich ist, wird genutzt werden...

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

fhainz

Gute Idee mit den Aussensteckdosen und dem FI.
Man könnte den LS durch einen FI-LS mit Meldekontakt ersetzen und die Meldung dann entsprechend weiterverarbeiten. Somit sind dann nur die Aussensteckdosen Spannungslos.

rudolfkoenig

Einer der wichtigsten Aufgabenbereiche von FHEM ist Förderung der Wissenschaft, Forschung und Lehre, und das hier gehoert eindeutig dazu. :)

Zur Frage: ich bin kein Funk-Experte, und auf dem Gebiet der Stoersender schon gar nicht. Meiner Ansicht nach eignet sich der CC1101 schlecht fuer erkennen von Stoersendern. Natuerlich kann man versuchen einzelne Stoerszenarien zu erkennen (siehe z.Bsp. X08, braucht SlowRF und AM Modulation). Man koennte culfw so erweitern, dass bei einem "unnatuerlich" hohen Zahl an Interrupts Meldungen ausgegeben werden. Wenn man aber den Paketmodus der CC1101 nutzt (z.Bsp. HM/ZWave/etc), geht das nicht, oder wenn dem Stoerer was besseres einfaellt, auch nicht.

Wenn ich Paranoiker waere, dann wuerde ich regelmaessig mit anderen Geraete ueber das ueberwachte Protokoll kommunizieren (Statusabfrage, etc), auch wenn das potentiell andere Sender stoert.

justme1968

ich glaube ein cc1101 ist nicht geeignet auf mehr als einem kanal etwas zu empfangen oder zu erkennen.

es gibt aber software um einen dvb-t USB stick zum ziemlich breitbandigem scannen zu verwenden. man sieht sehr schön wo gerade jemand sendet und z.t. sogar die unterschiede durch fertigungs toleranzen.

darauf aufbauend könnte man vermutlich sehr effektiv störungen erkennen.

je nach dem wie schnell du eine störung erkennen willst ist es aber vielleicht einfacher einem zweiten cul zu verwenden und sich selber von einer haus ecke in die andere regelmässig etwas zu senden.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Lars

Die grundsätzlich anzweifelnden Äußerungen kann ich nicht nachvollziehen. Eine Jammer Detection ist eine wichtige Funktion einer funkbasierten EMA. Die Störsender gibt es für einen 10er im China Shop und in Zeiten in denen nfc Kreditkarten in Schutzhüllen verstaut werden, sollte man solche Szenarien nicht als konstruiert oder theoretisch abwinken.

Zur Sache: ich hatte diesen Feature Request vor einiger Zeit in der cul Weiterentwicklung angeregt. Mangels Umsetzung polle ich regelmäßig den Status einer zwave Komponente mit fester spannungsversorgung.

Lars
FHEM Hauptsystem auf ESXi VM | dblog | 3 rPi für Nebensysteme | 2 Beaglebone Black Test- / Integrationssystem

JoWiemann

Zitat von: justme1968 am 10 Mai 2016, 22:18:20
je nach dem wie schnell du eine störung erkennen willst ist es aber vielleicht einfacher einem zweiten cul zu verwenden und sich selber von einer haus ecke in die andere regelmässig etwas zu senden.

Hallo Andre,

die Idee finde ich gut. Werde ich mal ausprobieren, wenn ich weiß wie ich es testen kann.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

betateilchen

Zitat von: justme1968 am 10 Mai 2016, 22:18:20
je nach dem wie schnell du eine störung erkennen willst ist es aber vielleicht einfacher einem zweiten cul zu verwenden und sich selber von einer haus ecke in die andere regelmässig etwas zu senden.

Wenn ich soviel kriminelle Energie aufbringen würde, um ein Funksignal einer Hausautomation zu beeinflussen, würde ich es so machen, dass Dir weder die vorgeschlagene Idee mit dem zweiten CUL noch die Idee mit dem DVB-T Scanner etwas nützen würde. Als Funkamateur habe ich da schon ziemlich konkrete Umsetzungsideen.

Und wenn ich eine Alarmanlage haben wollte, die störsicher ist, dann wäre das bestimmt keine auf Funksignale basierende Lösung.

Übrigens arbeiten auch professionelle Störsender für Mobilfunknetze (z.B. zur Terrorabwehr in Krisengebieten) nicht nur mit einem simplen Trägersignal über ein bestimmtes Frequenzspektrum, sondern um einiges komplexer.

Was ich damit eigentlich sagen will: Natürlich kann man einen gewissen Entwicklungsaufwand betreiben, um die in fhem eingesetzten Funkkomponenten "sicherer" zu machen. Aber wir sollten dabei bitte nicht vergessen, dass die eingesetzte Funkhardware doch letztendlich nichts weiter ist als Spielzeug.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

herrmannj

Ich assistiere Lars: jammer detection ist Standard bei guten Anlangen.

Die Frage im Context fhem ist dann aber was man mit der Info anfängt, welche Aktionen exakt dann getriggert werden.

'Geschichte' aus der Praxis dazu: ein Freund von mir hat einmal versehentlich eine 433MHz Funk FB so wegsortiert (etwas draufgelegt) das die FB durchgehend gesendet hat. Und zwar so das sie damit das 433MHz Band so dichtgemüllt hat das andere 433MHz Komponenten nicht mehr zu fhem "durchkamen".

Weil genau das (433MHz Band zugemüllt) aber zuerst nicht offensichtlich war hat er, nachdem er festgestellt hatte das viele Schalter bei ihm zu Hause, scheinbar grundlos, nicht mehr funktioniertern zuerst eine Fehler in der FHEM Installation gesucht. Es hat dann wohl, wenn ich mich richtig erinnere, 1-2h gedauert bis er dann drauf kam und die FB gefunden hatte.

So realiitätsfremd ist der Gedanke von Jörg offensichtlich nicht.

vg
joerg

rudolfkoenig

ZitatAls Funkamateur habe ich da schon ziemlich konkrete Umsetzungsideen.
Raus damit, das ist hier eine Lehrveranstaltung :)