Frage zur Verfügbarkeit 'externer' Events/Trigger

Fhematiker · 31 Dezember 2015, 16:11:13

Hallo liebe Gemeinde,

ich schlage ich mich seit einiger Zeit mit dem Thema "Anwesenheitserkennnung" herum. Das, was derzeit technisch machbar ist (LAN-Ping etc., Bluetooth) ist mit IOS nach wie vor nicht wirklich zu gebrauchen. Daher habe ich mich heute mit Geofencing auseinandergesetzt. Das funktioniert zwar, setzt aber eine von außen erreichbaren FHEM-Instanz voraus, wenn man nicht die ganze Zeit VPN laufen hat.

Es gab hier im Forum ja noch vor kurzem den Ansatz, bspw. IFTTT als Event-Trigger in FHEM anzubinden, aber auch PushOver oder PushBullet könnten ähnliches leisten: Wenn FHEM nämlich über den bestehenden Account nicht nur inbound -> outbound senden, sondern auch outbound -> inbound verarbeiten könnte. Somit wären externe Event-Trigger möglich, die dann mehr oder weniger unabhängig von Netzwerksicherheitsfragen funktionieren.

Da ich zu diesem Thema im Forum nichts Konkretes gefunden habe wäre meine Frage, ob es solche Lösungsansätze bereits gibt oder ob so etwas irgendwo bereits in Entwicklung ist ?

Bevor jetzt jemand sagt "Mach doch selbst": Ich kann's leider nicht, sonst würde ich all denen, die mir hier bereits geholfen haben, gerne mal etwas zurückgeben...

Viele Grüße und guten Rutsch,
Ralf

viegener · 31 Dezember 2015, 16:58:26

Ja die Überlegung war auch bei mir da, weil meine Instanz auch nicht von aussen direkt erreichbar sein darf.

Outbound -> Inbound ist mit verschiedenen Modulen schon heute möglich z.B. email, whatsapp und telegrambot

Ich hatte ursprünglich etwas entsprechendes im Sinn mit telegram, allerdings ist auch dort iOS (IFTT) relativ eingeschränkt so dass ich damals keine Möglichkeit gefunden habe eine telegram nachricht automatisch zu verschicken.

Ich habe deshalb auch keine Lösung anzubieten für das presence-Szenario, aber zumindest an fhem kommt man von aussen auch ohne VPN/Port heran.

Fhematiker · 01 Januar 2016, 15:19:07

Hallo viegener,

danke für deine Antwort!

Bzgl. deines letzten Satzes muss ich dann aber doch noch mal nachfragen:
Siehst Du denn eine Möglichkeit, eine Geofence-Standortbenachrichtigung (bspw. via IOS App 'Locative') ohne Port-Freigabe an FHEM zu übermitteln?

Gruß,
Ralf

Loredo · 01 Januar 2016, 15:40:06

In Verbindung mit einem Reverse-Proxy mit TLS-Offloading, der den Zugriff auf die URI /fhemwebName/geo begrenzt, besteht für die Nutzung von GEOFANCY keine Gefahr:

1. Man kann nur mit der INFIX Instanz des GEOFANCY Devices sprechen. Andere Interaktionen mit FHEM sind nicht möglich.
2. GEOFANCY erzeugt lediglich Readings und prüft vor deren Erstellung das übermittelte API Datenformat sehr genau.
3. Die übermittelte UUID ist gerätespezifisich, weltweit eindeutig und wird bei Neuinstallation eines Gerätes sogar neu erzeugt (zumindest bei iOS). Durch die TLS gesicherte Übermittlung direkt vom iOS Gerät aus kann die UUID von Dritten nicht ermittelt werden. Die Sicherheit für iOS Geräte ist somit gegeben. Soweit ich höre erzeugen neuere Android Geräte auch eine eindeutige UUID, deren Nutzung jedoch von der jeweiligen App abhängen kann.
4. Ohne die explizite Hinterlegung einer UUID im Attribut devAlias werden zwar Readings auf Basis der UUID erzeugt. Die Auswertung in Notify, DOIF etc soll jedoch auf Readings für UUIDs gelegt werden, für die man einen Alias gesetzt hat. Ohne die UUID zu kennen kann man somit von extern keine Trigger auslösen. Für unbekannte UUIDs lässt sich ein Warn-DOIF setzen (siehe unten).
5. Der genutzte Proxy lässt sich noch entsprechend härten (z.B. Beschränkung auf TLSv1.2, starke Crypto etc.). Ich nutze dafür HAproxy auf einer pfSense Firewall.

----

Oben sprach ich von einem Warn-DOIF. Dies ist auch nützlich, um benachrichtigt zu werden, wenn ein Gerät seine UUID aus irgendeinem Grund geändert hat und der Anwesenheitsstatus deshalb nicht mehr automatisch geändert wird. Spart dann auch böse Überraschungen beispielsweise weil die Alarmanlage nicht automatisch ausgeschaltet wurde...

Code Auswählen


define di_geofancy DOIF 
(
  [geofancy:?lastDevice] and
  [?geofancy:lastDevice] eq "-"
)
(
  msg @geofancy -1 |Geofencing| Nicht zugeordnete UUID empfangen: [geofancy:lastDeviceUUID]
)

attr di_geofancy do always

Für den Versand der Benachrichtigung wurde das msg-Kommando verwendet und global ein Admin-Kontakt hinterlegt, der per Telegram angeschrieben wird (die Attribute können alternativ natürlich auch nur am geofancy-Device gesetzt werden):

Code Auswählen


attr globalMsg msgContactPush Telegram:@@MeinUsernameBeiTelegram

"Telegram" ist dabei der Devicename meiner TelegramBot Instanz.

Loredo · 01 Januar 2016, 17:29:22

Zitat von: Fhematiker am 31 Dezember 2015, 16:11:13
Es gab hier im Forum ja noch vor kurzem den Ansatz, bspw. IFTTT als Event-Trigger in FHEM anzubinden, aber auch PushOver oder PushBullet könnten ähnliches leisten: Wenn FHEM nämlich über den bestehenden Account nicht nur inbound -> outbound senden, sondern auch outbound -> inbound verarbeiten könnte. Somit wären externe Event-Trigger möglich, die dann mehr oder weniger unabhängig von Netzwerksicherheitsfragen funktionieren.

Die Pushover API erfordert ebenfalls eine Portweiterleitung, damit der Web-Callback erfolgen kann (abzusichern wie gerade beschrieben).
Dafür ist die Schnittstelle dann tatsächlich 100% Event basiert und ohne (Long)polling o.ä.

viegener · 01 Januar 2016, 21:42:20

OK, das ist viel weiter als ich es letztendlich untersucht habe!

Zitat von: Loredo am 01 Januar 2016, 15:40:06
In Verbindung mit einem Reverse-Proxy mit TLS-Offloading, der den Zugriff auf die URI /fhemwebName/geo begrenzt, besteht für die Nutzung von GEOFANCY keine Gefahr:

Ein Hinweis sollte aber sein, dass auch ein Reverse-Proxy ein Server ist, der von aussen per portforwarding erreichbar ist. Ich habe deshalb noch kein Presence bei mir in Betrieb. Ich mag ja paranoid sein, aber ich wollte das Loch in der Firewall verhindern und auch dass ich täglich den Apache updaten muss.

Loredo · 01 Januar 2016, 22:00:16

Man braucht heutzutage auch kein Portforwarding mehr, um in ein Netz zu kommen. Es genügen schon Geräte im Netz, die per Longpoll o.ä. eine Verbindung nach draußen halten oder regelmäßig eine Verbindung aufbauen. Kann man die Firmware z.B. vom LCD Fernseher infiltrieren, baut der TV die Verbindung nach draußen auf und der Angreifer kann sich über den TV als Hub frei im Netz bewegen. Es ist also eine falsche Annahme man sei komplett sicher, nur weil man kein Portforwarding verwendet und sich stattdessen Möglichkeiten ausdenkt, wo die Verbindung aus dem lokalen Netz initiiert wird, nur um dann doch wieder eine Steuerung von außen zu haben. Wer diese Sicherheit meint zu suchen, der braucht ein physikalisch komplett abgeschottetes Netz (auch ohne serielle Verbindungen oder KVMs, wirklich autark; mindestens aber eine DENY ALL Firwwall-Regel für ausgehende(!) Verbindungen). Wer sich eine Möglichkeit einrichtet FHEM "irgendwie" von außen zu steuern, hat ein Risiko. Das richtig einzuschätzen, das ist dabei die Kunst.

------

Einen Apache oder Nginx würde ich als Reverse Proxy auch nicht als erste Wahl sehen. HAproxy, Pound oder Varnish sind da besser geeignet, weil sie keinen Content bereitstellen, sondern tatsächlich als "Router" auf Application Layer funktionieren. HAproxy kann dabei sowohl TLS sprechen und genau steuern als auch HTTP, was zusammen eine extrem granulare Steuerung ermöglicht, die zB mod_ssl in Apache nicht bieten kann. Da braucht man auch nix dauernd updaten, auf diesem Level sind Bugs selten so sicherheitsrelevant, als dass man da wöchentlich drauf schauen müsste (die Historie der letzten Jahre ist ja einsehbar).
Das ganze gabs auch mal ganz convenient "Out of the Box" im Hoanoho Image...

Unabhängig davon ist es aber trotzdem immer eine gute Idee regelmäßig das OS zu aktualisieren (und somit auch die oben genannten Softwarepakete, die selten jemand ohne Paketmanager einsetzen dürfte). Zu glauben, dass man ohne Portforwarding sein System nicht aktuell halten müsste, halte ich für nicht richtig.

viegener · 01 Januar 2016, 22:36:19

Zustimmung, es gibt natürlich eine Menge anderer Security-Risiken und kein PortForwarding heisst mitnichten Sorglosigkeit!

Ich hatt noch etwas mit TelegramBots experimentiert, weil es ja relativ einfach ist eine Nachricht mit einem URL an andere Empfänger zu schicken. Also so etwas wie:

Code Auswählen

https://api.telegram.org/bot<authtoken>/sendMessage?chat_id=<chatid oder userid>&text=IchBinZuHause

Allerdings kann ein TelegramBot leider keine Nachrichten von anderen Bots sehen, so dass man sich leider hiermit nichts senden kann, dass das TelegramBot-Modul dann sehen könnte

Fhematiker · 02 Januar 2016, 12:38:06

Hallo zusammen,

danke für die angeregte Diskussion und die vielen Informationen!

Aufgrund der mir bekannten und hier nochmal bestätigten Bedenken habe ich mich gegen eine (wie auch immer geartete) Zugriffsmöglichkeit von aussen entschieden.

Für die, die es interessiert: Ich habe jetzt eine Lösung gefunden, die für mich wirklich gut und zuverlässig funktioniert:
Ich löse mit IFTTT geografisch getriggert eine Email aus, auf die ich in FHEM mit 'mailcheck' und einem DOIF reagiere. Diese Lösung funktioniert mit mehreren Accounts (pro Familienmitglied) und hat auch annähernd die gleichen Reaktionszeiten wie das zuvor über VPN geteste Geofencing mittels IOS App.

Viele Grüße,
Ralf

Loredo · 02 Januar 2016, 12:46:52

Ehrlich? Das halte ich für weitaus unsicherer.

Kontrollierst du denn den gesamten Weg, den die Mail durchs Internet nimmt (Server zu Server Verschlüsselung)?
Da die IFTTT Mailserver nicht dir gehören, wohl eher nicht. Du bist darauf angewiesen, dass andere für dich die gesamte Übertragung verschlüsseln und kannst es nicht beeinflussen.

Ich nehme also an ich kann die unverschlüsselt übertragene Mail irgendwo mitlesen und dann imitieren, da sie vermutlich auch nicht signiert ist. Mit etwas Rechercheaufwand muss ich aber auch nicht unbedingt deine Mail abfangen, sondern nur das E-Mail Format und deine Absender-Email-Adresse kennen. Dann kann ich problemlos selbst eine solche Mail erzeugen und von jedem beliebigen Ort aus verschicken.

Ohne sehr großen Aufwand für eine kryptographisch gesicherte und verifizierte Übertragung (sowohl auf Absender/Erzeuger Seite als auch Empfänger-Seite) ist der E-Mail Weg also deutlich unsicherer als die direkte TLS Verbindung zwischen iPhone und ReverseProxy.

Fhematiker · 02 Januar 2016, 13:10:52

Naja, da sollte man die Kirche aber mal im Dorf lassen:
Ich möchte ja lediglich eine Anwesenheitskennung realisieren, die - zumindest vorerst - nur die Präsenz im Dashboard zuverlässig anzeigt. Wenn jemand wirklich diesen für jeden anderen unwichtigen Status manipulieren sollte, so what...
Dafür aber das interne Netz zu öffnen und extra einen Proxy usw. dazwischen zu schalten, wäre mir definitiv zu gefährlich/aufwändig.

Wenn ich mal irgendwann die Steuerung der Alarmanlage daran koppeln würde, müsste ein potenzieller Einbrecher erst mal vor Ort den Mailverkehr hacken. Bei soviel krimineller Energie hat er aber auch sicherlich das richtige Werkzeug dabei

viegener · 02 Januar 2016, 13:16:25

Zitat von: Loredo am 02 Januar 2016, 12:46:52
Ehrlich? Das halte ich für weitaus unsicherer.

Ich nehme also an ich kann die unverschlüsselt übertragene Mail irgendwo mitlesen und dann imitieren, da sie vermutlich auch nicht signiert ist. Mit etwas Rechercheaufwand muss ich aber auch nicht unbedingt deine Mail abfangen, sondern nur das E-Mail Format und deine Absender-Email-Adresse kennen. Dann kann ich problemlos selbst eine solche Mail erzeugen und von jedem beliebigen Ort aus verschicken.

Unsicher bezogen auf das Fälschen/Abhören der Email - Ja
Sicherer in Bezug auf Eindringen ins eigene Heimnetz/Intranet - Auch Ja

Für mich war (ebenfalls ?) das zweite Kriterium wichtig, denn Einbruchsversuch über Portscans, Passwortattacken und Ausnutzen alter Sicherheitslücken (und vielleicht auch neuer) erlebt man sekündlich, wenn man mal einen Server im Internet betreibt mit einer festen IP. Bei einer dynamischen IP passiert es etwas seltener aber trotzdem ist das wohl immer noch ein lohnendes Ziel.

Ich finde die Lösung mit der Email deshalb auch relativ sicher, allerdings ist das Fälschen der Email sicher kritisch, wenn
- Das Emailprogramm oder der MTA durch Emails kompromittiert werden kann
- der Emailempfänger Attachments automatisch herunterladen würde - Ich denke das wird hier zu vermeiden sein
- durch den Empfang der Email beliebige Aktionen gestartet werden können oder sicherheitskritische Abläufe in FHEM angetriggert werden
(Stichwort Haustür öffnen bei Empfang der Email...)

Fhematiker · 02 Januar 2016, 13:42:47

ZitatIch finde die Lösung mit der Email deshalb auch relativ sicher, allerdings ist das Fälschen der Email sicher kritisch, wenn
- Das Emailprogramm oder der MTA durch Emails kompromittiert werden kann
- der Emailempfänger Attachments automatisch herunterladen würde - Ich denke das wird hier zu vermeiden sein
- durch den Empfang der Email beliebige Aktionen gestartet werden können oder sicherheitskritische Abläufe in FHEM angetriggert werden
(Stichwort Haustür öffnen bei Empfang der Email...)

So sehe ich das auch! In meinem geschilderten Anwendungsfall wird lediglich auf das Mail-Subject reagiert, nichts (auch kein Anhang) runtergeladen und die Mail danach per attrib sofort gelöscht. Das Subject selbst ist recht kryptisch und lässt (eigentlich) keine Rückschlüsse auf einen Verwendungszweck zu und sollte daher auch vor einer sinnvollen Manipulation recht sicher sein.

Ich denke, das reicht für die Sicherheit im vorliegenden Anwendungsszenario vollkommen aus.

Loredo · 02 Januar 2016, 13:45:59

Security through obscurity also, hab ich verstanden.
Ich finde es befremdlich, dass ihr einerseits meint so sicherheitsfanatisch zu sein und im nächsten Satz dann "so kritisch ist der Anwendungsfall doch auch wieder nicht" sagt und dann eine nicht vertrauenswürdige Kausalkette vorzieht. Finde ich ziemlich inkonsequent, aber naja...

Viel Erfolg

viegener · 02 Januar 2016, 16:34:18

Zitat von: Loredo am 02 Januar 2016, 13:45:59
Security through obscurity also, hab ich verstanden.

Ich denke das ist an der Argumentation vorbei. Die Security besteht darin, dass man nicht ins Netz hereinkommt. Hier war die Rede von "Manipulationssicherheit", und die wird als weniger wichtig geachtet, denn es geht ja nicht um die Anwesenheitskontrolle im Kernkraftwerk, sondern das u.U. überflüssige Heizen im Haus

Einbruchssicherheit ist sehr wichtig und hier wäre SbO sicher falsch, wenn es um Manipulationssicherheit oder auch Beweisbarkeit geht, ist das aber auch bei mir anders.