Xiaomi devices: Datenschutz gewährleistet ?

[Wzut]

[OT]Aber der oder das token ?  [OT]

beides richtig -> Substantiv, Neutrum, oder Substantiv, maskulin , Quelle : https://www.duden.de/rechtschreibung/Token

[jhs]

Hallo,

Vorbemerkung:
nun bin ich doch noch mal bei diesem Thread gelandet, bei der Recherche, ob sich zwischenzeitlich bei der Integration der Xiaomi Luftreiniger in Fhem etwas grundlegendes geändert hat; dem scheint leider nicht so zu sein, es besteht vom Hersteller so vorgesehen immer noch "Cloud-Zwang."
Da die Geräte meiner MEinung nach technisch gesehen aber sonst ihre Aufgabe gut erledigen, habe ich mehrer davon im Einsatz. Alllerings erst, als ich für mich eine Lösung gefundet hatte, die den Betrieb in Fhem mit WLAN-Integration ermöglicht, OHNE jegliche Verbindung zur Hersteller Cloud. Keine Frage, die u.g. Lösung stellt eine Hilfskonstruktion dar, aber es funktioniert bei mir .

Kurzbeschreibung:

• die Xiomi-Luftreiniger arbeiten nach Einschalten/Inbetriebnahme als individueller WLAN-AP auch in der weiteren Nutzungsphase durch Fhem im Auslieferungszustand (wie auch nach WLAN-Factory-Rset.
• um mit einem Xiomi-Luftreiniger von Seiten Fhem aus Kontakt aufzunehmen, konfiguriert man von Fhem aus einzusätzliches separates "Xiaomi"-WLAN (z.B. AVM-WLAN-Stick ... akzeptable Reichweite) mit den WLAN-Accessdaten des jeweiligen Luftreinigers (Dieses WLAN-Interface hat Server-seitig gar keine Möglichkeit "nach draußen" eigene Nachrichten abzuschicken)
• Ergebnis: alle wichtigen Readings der einzelnen Geräte können Fhem-üblich bearbeitet werden, z.B. Betriebszeiten ... notify auf notwendigen Filterwechsel,  ... power on/off zwecks Ruhezeiten und ähnliches.
• Randbedingungen dieser Lösung: da die Abarbeitung von Anfragen und Settungs pro Gerät bei dieser Notlösung nur sequential über eine Queue erfolgt, kann es auch mal länger dauern, bis Aktionen zum betreffenden Gerät drankommen und umgesetzt werden. Das hat sich aber bisher in keiner Weise als nachteilig erwiesen. Im Gegenteil, der Vorteil, die Geräte auch ohne Cloud-Zwang unter Fhem nutzen zu können, überwiegt aus meiner Sicht bei weitem. Daher ist für mich auch die App zur Steuerung der Geräte absolut nicht notwendig, das alles erledigt Fhem viel besser

Gruß
JHS

[KölnSolar]

Morjen,
meine vollste Zustimmung

Im Gegenteil, der Vorteil, die Geräte auch ohne Cloud-Zwang unter Fhem nutzen zu können, überwiegt aus meiner Sicht bei weitem. Daher ist für mich auch die App zur Steuerung der Geräte absolut nicht notwendig, das alles erledigt Fhem viel besser

Weg mit dem Cloud-Spion.
so ganz hab ich

konfiguriert man von Fhem aus einzusätzliches separates "Xiaomi"-WLAN

nicht verstanden. Zumal Du den airpurifiern doch dieses WLAN mitteilen musst(per App) und das dann neue token zu dessen Generierung doch die Kommunikation mit der Cloud erfordert. 
Oder Du hast etwas ganz Neues "entdeckt", dann bitte her damit. 
Grüße Markus
 

[jhs]

Hallo,
vorweg, ich habe nichts neues entdeckt, sondern einfach nur versucht, aus dem etwas zu machen, was mir "trotz" Xiaomi per WLAN für Fhem zur Verfügung steht.
Das Ergebnis dieser Steuerung wirkt zwangsweise ziemlich "ge-hacked" und gefrickelt, weil - diese Lösung war überhaupt und so wohl nicht so vom Hersteller vorgesehen, wie man vermuten könnte.


Aus Fhem Anwendersicht stellt sich das Ergebnis meiner Einbindung der Xiaomi airpurify devices wie folgt dar, z.B.:
# Fhem für airpurifyX mit X=[1-N]

I. requirements

• Wichtig:  von Fhem steuerbare 230V Schaltsteckdose(n) , jeweils 1x pro Xiaomi device zum Schalten des airpurify device, um dieses in den "Anlern-Mode" der Inbetriebnahme zu versetzen. Diese Power-Schalter wird sinnvollerweise auch verwendet, um aus Energiespargründen die airpurify devices vom 230V-Netz zu nehmen, wenn sie nicht benötigt werden.
• die dynamische Veränderung der dedizierten Server-WLAN-Schnittstelle, die ausschliesslich für die Kommunikation mit den airpurify devices reserviert ist (z.B. per WLAN Stick mit genügend Reichweite)
• die Steuerung der Queue, die dafür sorgt, dass die airpurify devices der Reihe nach abgearbeitet werden, da die Kommunikation zwischen Fhem und den N airpurify devices immer nur mit _einem_ device abgearbeitet werden kann, erst danach ist ggf. das nächste airpurify device dran. Grund: das WLAN muss für jeden Auftrag mit einem anderen airpurify device umprogrammiert werden.

Ein Teil der Steuerung der airpurify devices ist in Fhem Macros verborgen, ein Teil in FHEM/99_myUtils.pm und ein Teil in Mini C-Programm Schnipsel, um mit den notwendigen Systemprivilegien das o.g. WLAN-Interface dynamisch gem. Aufrufparameteren von Fhem zu konfigurieren.

Eine wichtige hilfreiche Steuergröße ist das user reading
setreading airpurifyX xpower [on|off]
das Aufschluss über den Zustand von airpurifX gibt, auch wenn dieses Gerät gerade mal nicht erreichbar ist. Die Aktualisierung dieses Readings erfolgt in den Faellen, wenn airpurifyX erreichbar ist, bzw. der programmierbare  Netzschalter das Gerät das airpurify definitiv AUS-schaltet.

II Anwendungsbeispiele

• # Queue gesteuertes Ein-/Ausschalten der airpurify devices:
  trigger power_on_airpurifyX ...  trigger power_off_airpurifyX
• # Maintenance, wenn Filter länger als MAX Stunden in Betrieb:
  define airpurifyX_ck_stat_filter_used notify airpurifyX:filter_used:.* { airpurify1_ck_stat_filter_used_msg ("airpurifyX") }
• # set defaults je airpurify device  X
  

Code Auswählen Erweitern

define set_on_airpurifyX_defaults notify set_on_airpurifyX_defaults
...
  set airpurifyX reconnect
  set airpurifyX buzzer off
  set airpurifyX on
  set airpurifyX mode auto
  set airpurifyX led dim
  setreading airpurifyX xpower on
...





Der grundlegende "Trick", um mit den Xiaomi airpurify devices "out-of-the-box" zu kommunizieren, ohne auch nur an die Xiaomi App zu denken besteht darin, das Server-WLAN mit dem factory-|reset-WLAN ESSID (Accesspoint-Mode "AP" !) des airpurify devices kommunizieren zu lassen. und daran danach nichts mehr zu ändern.
Um in diesen Modus des Airpurify zu gelangen, muss das Gerät im Zustand factory-|reset jeweils eingeschaltet werden, mittels des o.g. 230V~ von Fhem steuerbaren Power-Schalters.

Der  WLAN-AP-Mode wird dann nach Einschalten für eine begrenzte Zeit von den Xiaomi airpurify devices aktiviert (Vorausetzung: das Gerät wurde nicht mit Xiaomi-APP "verbogen" und solange das Gerät nicht für die Cloud konfiguriert wurde; aber DAS wollen wir ja gerade vermeiden
Dass dieses WLAN in dieser Form - offen, unverschlüsselt - genutzt wird, stört in diesem Anwendungsfall nicht.

Diese factory-|reset-WLAN ESSID unterscheidet sich von Geraet zu Geraet und beinhaltet Teile der MAC-Adresse "aa:bb:cc:dd:ee:ff" (last 4 char. ) wie folgt
zhimi-airpurifier-mc2_miapeeff
Die IP-Adresse der airpurify devices in diesem Inbetriebnahme Mode als WLAN-AP ist konstant 192.168.13.1.
Damit steht fest, wie die SSID des dedizierten Server-WLANs (als WLAN client) zu konfigurieren ist. Als IP-Adresse des Server-WLAN kann man dann z.B. fest 192.168.13.11 verwenden.

Code Auswählen Erweitern

#    192.168.13.1 # als statische  default IP-Adresse
#    ESSID:"zhimi-airpurifier-mc2_miapeeff"
#    Encryption key:off
#    MAC-Adress :aa:bb:cc:dd:ee:ff
#    Frequency:2.437 GHz
#    Mode:Master


Um mit den bzw. dem aktuellen airpurify device kommunizieren zu können, ist nun der "berüchtigte" Token des airpurify devices erforderlich.
Im Auslieferungszustand bzw. nach factory reset ist ein jeweils individueller token auslesbar. Da wir den Auslieferungs-/Reset-Mode

> Nur zur erstmaligen Inbetriebnahme nach UnBoxing oder WLAN-Reset
> (by pressing both button Mode+LED for >5 sec )

in unserem airpurify-Steuersystem nicht ändern (!) können wir diesen Token verwenden.


1. das dedizierten Server-WLAN entsprechend aufsetzen

- auf die ESSID des neuen airpurify (im AP-Mode nach uslieferungszustand bzw. nach factory reset )
   -  Encryption key:off
   -  inet 192.168.13.11  netmask 255.255.255.0  broadcast 192.168.13.255

2. per 'ping' muss nun der airpurify erreicht werden können

und im arp-Cache die MAC-Adresse des airpurify
   sudo arp -a | grep 192.168.13.1

3. Inbetriebnahme Code in Fhem

#   define airpurify1 XiaomiDevice 192.168.13.1
#   attr airpurify1 subType AirPurifier
#   attr airpurify1 room TEST_xiaomi

4. Wenn nun bis hier die WLAN-Verbindung "steht", dann sollte der aktuelle token in den device internals unter Fhem bei Anklicken des "airpurify1" im room "TEST_xiaomi" sichtbar sein.

5. Zur Übernahme von airpurify1 in die Fhem Produktivumgebung
aendert sich dann die define Zeile:

Code Auswählen Erweitern

#
define airpurify1 XiaomiDevice 192.168.13.1 fd98e26c0e7e1875a33fa1258f330cd5
attr airpurify1 alias airpurify1_EG_Wohnimmer
attr airpurify1 event-on-change-reading device_uptime,error,favorite,filter,filter_life,filter_used,filter_volume,humidity,led,mode,pm25,pm25_average,power,sleep_auto,speed,state,temperature,turbo,usage
attr airpurify1 stateFormat pm25 µg/m³ / speed rpm / mode
attr airpurify1 subType AirPurifier

Code Auswählen Erweitern

define airpurify1 XiaomiDevice 192.168.13.1 fd98e26c0e7e1875a33fa1258f330cd5
attr airpurify2 alias airpurify2_EG_Schlafzimmer
attr airpurify2 event-on-change-reading device_uptime,error,favorite,filter,filter_life,filter_used,filter_volume,humidity,led,mode,pm25,pm25_average,power,sleep_auto,speed,state,temperature,turbo,usage
attr airpurify2 stateFormat pm25 µg/m³ / speed rpm / mode
attr airpurify2 subType AirPurifier

... usw


Ich hoffe, ich habe zumindest prinzipiell darstellen können, dass man damit diese widerborstige Ansteuerung der Xiaomi airpurify in den Griff bekommen kann. So würde es auch keinen großen Aufwand darstellen, jetzt noch etliche weitere Geräte dieser Art in Fhem zu integrieren. Der Rahmen steht und lässt sich leicht erweitern.

Wenn weitere Fragen bestehen, will ich die gerne mit meinen Möglichkeiten beantworten. Kann ggf. etwas dauern, da ich nicht so häufig im Forum unetrwegs bin.

Gruß
JHS

[KölnSolar]

Danke für Deine Beschreibung.

Nun ist mir klar, was Du treibst. So hatte ich ja auch schon die Anbindung an FHEM erreicht. Vielleicht noch einmal etwas anders beschrieben(mir fehlt in Deiner Beschreibung die eigentliche Grundlage).

Grundlage: ein noch nicht per App "gepairter" airpurifier schaltet sich nach jedem "Stromspannung ein" für ca. 15 min. in den Pairingmodus. Dafür öffnet er einen eigenen WLAN-AP(je nach Modell mit unterschiedlicher SSID und IP[bei mir 192.168.4.1])

Um eine Netzwerk-Verbindung bzw. eine Verbindung zu FHEM zu erreichen, muss der FHEM-Server eine WLAN-Verbindung zum AP aufbauen. Das erreicht man durch einen WLAN-Client, dem man eine feste IP aus dem Subsegment der Airpurifier-IP[192.168.4.x] vergibt(ich nutze dafür die WLAN-Funktion meines RPi3).

Mit dem XiaomiDevice-Modul lässt sich der airpurifier in FHEM mit der IP des airpurifier-WLAN-AP definieren

Code Auswählen Erweitern

define airpurifier XiaomiDevice 192.168.4.1
Nun ist der airpurifier von FHEM aus bedien- und abfragbar. Aber nur für jeweils die vorgenannte Viertelstunde. Denn dann schließt der airpurifier wieder seinen AP.

Um nun trotzdem regelmäßig kommunizieren zu können. kann über eine schaltbare Steckdose der airpurifier aus bzw. wieder eingeschaltet werden. So öffnet man immer wieder das 15min-Zeitfenster.
Da der airpurifier seine Einstellungen mit jedem Abschalten "verliert", müssen nach jedem Wiedereinschalten die "Wunscheinstellungen" neu über FHEM mit den set-Befehlen ausgeführt werden.

Somit ein gangbarer Workaround, um die Cloud zu vermeiden.

Was man noch machen sollte: der WLAN-AP-IP muss vermutlich der Zugang  zum Internet gesperrt werden(direkt am Router, die Xiaomi-domains über pi-hole, die Xiaomi-IPs über iptables,.....)
Und, wie schon geschrieben, der airpurifier-WLAN-AP ist offen. Also für jedermann sichtbar und ohne Kennwort zugänglich. Man muss also irgendwie sicherstellen, dass nur die Antworten auf die FHEM-requests verarbeitet werden. Sämtlicher sonstige Traffic müsste gesperrt werden. Ist mir noch unklar wie man das erreichen kann...


Deine Methode hat natürlich den großen Nachteil, dass eine durchgängige Aufzeichnung der Sensorwerte oder eine FHEM-Reaktion auf Sensorwerte nicht sinnvoll möglich ist. 
Durch die von Dir gewählte "Methode" hast Du mich aber auf einen Ansatz gestoßen, der es wert ist einmal auszuprobieren: Das Viertelstundenfenster anderweitig(softwaretechnisch) "neu" zu erzwingen.
Was mag der AP machen, wenn man
- kurzzeitig die WLAN-Verbindung kappt
- mit einer anderen IP (also Änderung der Client-IP) erneut zugreift
- andere Dinge macht, die der AP normalerweise von der Äpp erwartet
- ..... ?

[jhs]

Hallo,

... Du hast das jetzt viel verständlicher (und kürzer) beschrieben; so kann ich das jetzt 1:1 in meine Doku übernehmen, natürlich mit Quellenangabe

Zu Deinen Anmerkungen:

• das ganze läuft jetzt bei mir mit 5x Geräten zur vollsten Zufriedenheit, mit einem Regelwerk, das die Airpurifys an- und ausschaltet z.B. bei Fenster/Zu/Auf oder Raum/genutzt/Ja/Nein u.a.
  Und das immer mit "meinen" Konfigurationswerten (individuell pro Gerät)
• die Messwerte (readings) aus den Geräten (wie temperature, humidity, ...)  sind für mich Nebensache, da ich von den Sensoren aus den Airpurifys nichts benutze; die Werte bekomme ich von anderen Sensoren mit Fhem "stressfreier". Ausnahme, und da reicht der Aktualisierungstakt alle Mal: filter_life, filter_used
• Danke für Deinen Hinweis; das werde ich mal ausprobieren. Bestenfalls kann ich mir die aktuelle Re-Konfig der dedizierten WLAN-Schnittstelle mit externem setuid-coded C-Progrämmchen ersparen.
  

  Mit dem XiaomiDevice-Modul lässt sich der airpurifier in FHEM mit der IP des airpurifier-WLAN-AP definieren
  Code: [Auswählen]
  define airpurifier XiaomiDevice 192.168.4.1
  Nun ist der airpurifier von FHEM aus bedien- und abfragbar. Aber nur für jeweils die vorgenannte Viertelstunde. Denn dann schließt der airpurifier wieder seinen AP.

• Dass der Airpurify die Einstellungsänderungen bei Abschalten (230V) vergisst,  stört nicht besonders (Ausnahme: ggf., buzzer piept 1x beim Einschalten), da in der Einschalt-Prozedur die von Fhem festgelegten Änderungen an den default Einstellungen von Xiaomi überschreibt.
  Immerhin: die aktuellen readings der Filterwerte werden durch Ausschalten nicht vergessen!

• Was man noch machen sollte: der WLAN-AP-IP muss vermutlich der Zugang  zum Internet gesperrt werden(direkt am Router, die Xiaomi-domains über pi-hole, die Xiaomi-IPs über iptables,.....)

  Klar, sonst macht der ganze Aufwand wenig Sinn ...

• Und, wie schon geschrieben, der airpurifier-WLAN-AP ist offen. Also für jedermann sichtbar und ohne Kennwort zugänglich. Man muss also irgendwie sicherstellen, dass nur die Antworten auf die FHEM-requests verarbeitet werden. Sämtlicher sonstige Traffic müsste gesperrt werden. Ist mir noch unklar wie man das erreichen kann...

  Zur Zeit schätze ich das nicht als echte Betrohung ein: zum hacking von extern muss der bekannte Aufwand betrieben werden, um an das notwendige token zu kommen. Na toll, dann kann die Attake auf den jeweiligen Airpurify ja starten Mit dem Risiko kann ich - gemessen am Nutzen zur Steuerbarkeit der Airpurifys - leben.
  Ansonsten ist damit kein offenes Tor zur sonstigen IT-Infrastruktur verbunden, oder habe ich etwas übersehen ?

• 
  Deine Methode hat natürlich den großen Nachteil, dass eine durchgängige Aufzeichnung der Sensorwerte oder eine FHEM-Reaktion auf Sensorwerte nicht sinnvoll möglich ist. 

  Wie schon gesagt, auf die Sensorwerte der Airpurify kann ich gerne verzichten, da  mir entsprechende Werte von anderen Sensoren zur Verfügung stehen;
  und wichtig, die readings über die Filter sind nutzbar, zwar nicht in "Realzeit" aber alle Mal in ausreichendem Intervall  mittels "notify" u.a.

• Durch die von Dir gewählte "Methode" hast Du mich aber auf einen Ansatz gestoßen, der es wert ist einmal auszuprobieren: Das Viertelstundenfenster anderweitig(softwaretechnisch) "neu" zu erzwingen.
  Was mag der AP machen, wenn man
  - kurzzeitig die WLAN-Verbindung kappt
  - mit einer anderen IP (also Änderung der Client-IP) erneut zugreift
  - andere Dinge macht, die der AP normalerweise von der App erwartet

  Das ist komplett gelöst über die Verwaltung mittels Queue (in 99_myUtils.pm) und spezielle userreading xpower [on|off] (welcher Airpurify wird aktuell über konfiguriertes WLAN "beackert" und mittels "xpower" kann Fhem jederzeit abfragen, ob der Airpurify eingeschaltet und mit den eigenen Vorgabewerten läuft).
  "Änderungswünsche" zum Status der Airpurifys - seitens Fhem - werden immer über die Queue abgewickelt; um nicht den komplizierten WLAN-connect Ablauf zu stören.
  Wird eine Konfig-setup Prozedur nicht vollständig abgearbeitet, bleibt der Auftrag in der Queue bestehen, und wird bei Gelegenheit wiederholt.
  Und, nach meinen Beobachtungen veranstalten die Airpurifies in dem hier beschriebenen setup/config selbstständig keine irgendwelchen Dinge, die fremdgesteuert den eigenen Vorgaben zuwiderlaufen, sondern laufen nach dem setup (und den bekannten 15 Minuten bzw. Abbruch der WLAN-Verbindung) im gewünschten Zustand autark weiter, sollen sie auch !

Vielleicht liest der Autor des Moduls 72_XiaomiDevice.pm ja mit.
Ich könnte mir vorstellen, dass man aus unserer Diskussion durchaus Anregungen  in das Modul einbauen könnte, um die Xiaomi-Devices cloud-less zu "zähmen" oder ?
Das wäre eine große Vereinfachung, statt sich auf Fhem-Anwenderebene in "system-nahe" Frickelei zu verirren.

Wenn's hilft, natürlich stelle ich meine Code-Teile zur Verfügung, auch wenn die aus meiner Anwendungs so nicht übernoimmen werden können.

Gruß
JHS

[MadMax-FHEM]

    Was man noch machen sollte: der WLAN-AP-IP muss vermutlich der Zugang  zum Internet gesperrt werden(direkt am Router, die Xiaomi-domains über pi-hole, die Xiaomi-IPs über iptables,.....)

Klar, sonst macht der ganze Aufwand wenig Sinn ...

Das erschließt sich mir nicht...

Der AP ist doch "isoliert", also steht "nur für sich".
Fhem verbindet sich über einen "extra" WLAN-Client-Zugang genau nur mit diesem AP...

Solange niemand zwischen 192.168.4.0/24 und dem Internet routet gibt es doch eh keine Verbindung?

Wenn also die NW-Konfiguration auf dem fhem-Server NICHT routet, sondern eben "nur" im Restnetz "steckt" und sich Daten vom AP holt kann doch nichts passieren?

Es dürften ja nicht mal Pakate (die geblockt werden müssten) bei der Firewall ankommen?

EDIT: eher kritisch sehe ich das mit dem, dass der AP offen ist! Solange sich nur EINER damit verbinden kann und fhem immer dieser EINE ist, ist alles (halbwegs) ok. Wenn aber mehr Verbindungen zulässig sind, dann kann sich doch einfach noch jemand mit dem AP verbinden und dann (theoretisch) auf fhem zugreifen?

Gruß, Joachim

[jhs]

Hallo,

liegt da ein technisches Missverständnis zur Anmerkung von KölnSolar vor ?  ich hatte das wie folgt gemeint:
in der Konfig, die ich beschrieben habe und konfigiert habe, unabhängig ob 192.168.4.0/24 oder 192.168.13.0/24   ...

• ist der Airpurify der "offene" WLAN-Access-Point, der von einem externen unbefugten WLAN client gehacked werden könnte. Aber was kann man mit diesem Hack erreichen: 
  schlimmstenfalls, mit entsprechend Aufwand die Airpurifys verbiegen, aber zumindest das nicht unbemerkt;
  ein factory reset am Airpurify sorgt dann wieder für klare Ausgangsverhältnisse; somit würde ich diese Konfig schon fast als "honeypot-WLAN" für die Fhem Infrastruktur bezeichnen weil, interessant zu wissen, dass Attacken auf das eigene WLAN geritten werden.
  Also für wen lohnt sich der hacking  Aufwand? Für mich überwiegt eindeutig der Vorteil, die (diese) Hersteller-cloud nicht benutzen zu müssen und die Airpurifys trotzdem über ein eigenes WLAN ansteuern zu können.
• auf Fhem von außen zugreifen über das dedizierte  exklusive Airpurify-Server-WLAN-Interface - im client mode - ist meiner Meinung nach nicht möglich (aus Sicht mit meinen bescheidenen Netzwerkkentnissen)

Gruß
JHS

[KölnSolar]

Auch meine Netzwerkkenntnisse gehen ad-hoc nicht weit genug.  Ich meide ja WLAN-FHEM-devices wie der Teufel das Weihwasser und hab daher auch keinen Plan, wie man WLAN-devices in einem eigenen Subnet "einsperrt" und trotzdem mit dem FHEM-Server(dessen Subnet) kommunizieren lässt.

In meiner "Standard-Konstellation" mit Nutzung des RPi-WLAN-Adapters wird wohl geroutet(glaube ich). Und speziell zu FHEM: Mein FHEM ist nicht per "allowed" geschützt, da ich dafür in meinem lokalen Netzwerk keine Notwendigkeit sehe.(umgekehrt ist es lästig sich anmelden zu müssen)

Spielen wir es doch mal grob durch:
- Das Xiaomi-Linux kennt kein Gateway. Neben dem WLAN-AP wird vermutlich auch noch ein DNS gestartet(nehme ich an, weil die Äpp ja keine statische IP haben wird). Offen wie ein Scheunentor.

Der FHEM-Server meldet sich nun mit seiner IP am AP an.
Nun meldet sich noch "jemand" am AP an. Der DNS vergibt ggfs. eine IP (oder eine statische IP meldet sich an).
Nun befinden sich alle 3 devices in einem Subnet und alles ist in diesem Subnet theoretisch erst einmal möglich, oder ?
Sofern mehrere Clients am Xiaomi-Server möglich sind, lässt sich dann doch vom Dritten schon mit z.B. nmap alles Wissenswerte(IP,Ports,Services) ermitteln.
Und dann ist es doch nur noch eine Frage der jeweiligen Absicherung der Services, zu denen man sich Zugang verschaffen kann. Also "nur" noch User/Passwort der jeweiligen Services und man hat als Dritter alle Möglichkeiten, die der Service bietet.(Bei meinem "offenen" FHEM also quasi alles für einen FHEM-Kenner).

Wenn ich mit meinem Laienverständnis nicht falsch liege: Wie blockiere ich Zugriffe mit Linux-Bordmitteln von anderen IPs als der des APs ?

Grüße Markus

[MadMax-FHEM]

Solange keiner routet (und normalerweise, wenn du "nur" mit einem SP verbindest und "nur" damit in diesem Subnetz also 192.168.4.0/24 unterwegs bist) dann findet nmap auch "nur" IPs/Rechner in diesem Subnetz, schlimm genug, weil ja bei dir damit fhem ohne Schutz zu finden ist/wäre.

Blocken kannst du das mit lokalen Firewall-Regeln auf dem fhem-PI.
Allerdings kenne ich mich mit dem "Consolen-Firewall-Tool" auf dem PI zu wenig aus.

Habe Unifi mit Security-Gateway und erstelle Firewall-Regeln dort "graphisch"...

Aber es gibt wohl ein Tool (UFW?) mit dem es zumindest angenehmer als mit iptables geht, ohne das wirklich beurteilen zu können.

Damit kannst du dann den PI auf dem WLAN-Netz (192.168.4.0/24) komplett abschirmen, weil eigentlich ja keine aktive Verbindung zu fhem muss?
fhem will ja nur zum Xiaomi-Gerät?

Also kannst du alles blocken, außer (related) und established.
Heißt: niemand darf "rein". Wenn aber fhem mal rausgerufen hat, dürfen Antworten zurück. Sonst nichts. Theoretisch kannst du auch noch Ports beschränken. Musst du aber nicht, da du ja in fhem im Griff hast welche Ports du nutzt/nutzen willst/musst.

Wenn doch das Xiaomi-Gerät aktiv auf fhem zugreifen muss (was mich wundern würde), dann musst du halt in die Firewall ein (weiteres) "Loch" machen, dass da heißt: source 192.168.4.1 und destination 192.168.4.x (wobei x halt die fhem Adresse ist in dem Subnetz) ist.
Da das Xiaomi-Gerät ja offenbar immer die 192.168.4.1 hat, kann das ja fix so sein/bleiben.
Wichtig wäre halt, dass fhem auch immer dieselbe IP bekommt (ob da nämlich localhost geht: keine Ahnung)...

Also wie geschrieben hätte ich nur/eher "Angst" davor, dass jemand sich auch/zusätzlich mit dem AP verbindet und dann auf mein fhem käme...
Weiter als fhem sollte dann ohne, dass ein Routing eingerichtet ist/wurde (und das musst du wirklich tun, also das kommt [normalerweise] nicht einfach "von selbst") niemand kommen.
Aber das wäre ja schon schlimm genug.

Ich denke du meinst nicht DNS sonder DHCP-Server zur Vergabe von IPs

Gruß, Joachim

[jhs]

Hallo,

... mit meinen rudimentären Netzwerkkenntnissen ... habe ich mal eben ein Test gemacht:

• Wie ich für meine Konfig beschrieben habe, IP Adresse/airpurifX 192.168.13.1 (=factory reset Wert) und wlan2 (192.168.13.11 =Fhem-Server das für die Kommunikation mit airpurify reservierte WLAN-Interface).
• Die Kommunikation zwischen diesen beiden Netzwerkteilnehmern lief, a) ließ sich das auf dem Fhem-Server beobachten und b) war danach der Airpurify eingeschaltet, online und konfiguriert (und mdst. die bekannten 15 Minauten über als AP erreichbar)
• Für diese 15 Munten habe ich einen Laptop wlan-mäßig für dieses Netzwerk vorbereitet und von je einem Consolen Fenster aus  ping auf 192.168.13.1 und 192.168.11  gestartet, mit folgenden Ergebnissen:


• Vom AirpurifyX bekam das Laptop-WLAN-Interface die Adresse 192.168.13.2 zugewiesen, wie zu erwarten war.
• Der AirpurifyX (192.168.13.1) war vom Laptop (192.168.13.2) aus per ping erreichbar; auch das war zu erwarten.
• Der AirpurifyX (192.168.13.1) war vom Laptop (192.168.13.2) aus aber nicht zu erreichen per ssh | telnet | ftp!
• Das Fhem-Server-Interface war in keiner Weise zu erreichen (per ping etc. und folglich auch nicht mit andern services, weder direkt noch via routing über den AP des Airpurify)

Fazit:
ich persönlich sehe zur Zeit keine Gefahr für erfolgreiche Angriffe über den Umweg des (temporär) offenen Airpurify WLANs auf meine  sonstige Fhem-IT.
Und wie gesagt, eine Cloud, in der meine WLAN-Zugangsdaten etc. gehalten werden und dass diese Daten in falsche Hände geraten, stellt aus meiner Sicht eine viel größere Gefahr dar.

Zu erwähnen bleibt noch, an dieser Stelle nochmals nachzufragen - falls mein genannter Vorschlag zur Steuerung der Xiaomi Airpurifyer Anklang findet, ob dieses Verfahren nicht in das Modul verankert werden könnte ?
Ich denke, es würde sich lohnen; die Geräte sind wohl recht zahlreich verbreitet.
Mir fehlen dafür leider die Kenntnisse für die Implementierung.

Gruß
JHS

[MadMax-FHEM]

Hast du mal versucht dich per ssh auf dem fhem Server einzuloggen (vors. ssh ist dort konfiguriert)?
EDIT: überlesen... Hast do offenbar getestet...

Dass das Xiomi Gerät nicht per ssh/telnet usw. "erreichbar" ist kann logisch sein: die Dienste werden dort halt nicht laufen...

Trotzdem kann man per se auf den fhem Server zugreifen bzw. ist zumindest schon mal im selben Netz.
D.h. wenn Dienste laufen, kann man evtl. Schaden anrichten...

Daher wäre der ssh-Test interessant...

Gruß, Joachim

[KölnSolar]

Ich denke du meinst nicht DNS sonder DHCP-Server zur Vergabe von IPs

Yes. 

Die Tests bestätigen also, dass sich mehr als ein client beim AP anmelden können. 

Dass das Xiomi Gerät nicht per ssh/telnet usw. "erreichbar" ist kann logisch sein: die Dienste werden dort halt nicht laufen...

Denke ich auch.
Ich  fände daher interessanter per nmap zu testen(ich hab derzeit leider das WLAN des RPi anderweitig in Nutzung, so dass ein Test derzeit nicht möglich ist). Damit sieht man welche services auf welchen Ports auf dem AirpurifyX laufen(wenn man etwas sieht)

Das Fhem-Server-Interface war in keiner Weise zu erreichen (per ping etc. und folglich auch nicht mit andern services, weder direkt noch via routing über den AP des Airpurify)

Das kann ich Dir mangels eigener Tests nur glauben. Verwundert mich aber schon. Einen ping habe ich noch immer im selben subnet hinbekommen. Also ping von Laptop an 192.168.13.11 ohne Erfolg ?
Was mag dann der "Mechanismus" sein, dass sogar einen ping im subnet verhindert ? Ob es was damit zu tun hat, dass die IP des FHEM-Servers statisch und nicht per DHCP vergeben ist ? 

Und wie gesagt, eine Cloud, in der meine WLAN-Zugangsdaten etc. gehalten werden und dass diese Daten in falsche Hände geraten, stellt aus meiner Sicht eine viel größere Gefahr dar.

Ich bin immer noch einig mit Dir. 
Aber wir sollten halt schon gucken, dass wir hier eine Lösung erarbeiten, die größtmöglichen Schutz bietet. Will heißen: Wenn sowieso sichergestellt ist, dass man nur an den Airpurify kommt, so what. Wenn nicht, sollte als Ergebnis unserer Diskussion(Deiner Tests) eine zusätzliche Maßnahme zur Absicherung herausspringen.

Grüße Markus

Edit: Hab gerade mal ins Modul geguckt: UDP-Zugriff auf Port 54321
        Und um auf Joachims Mutmaßung zu antworten: Es sieht nicht danach aus, als ob der Airpurify etwas aktiv in Richtung des Clients(bei uns FHEM) pushed. Könnte man per tcpdump noch checken.

[jhs]

Hallo,

nur mal so ins Blaue geraten:

Edit: Hab gerade mal ins Modul geguckt: UDP-Zugriff auf Port 54321
        Und um auf Joachims Mutmaßung zu antworten: Es sieht nicht danach aus, als ob der Airpurify etwas aktiv in Richtung des Clients(bei uns FHEM) pushed. Könnte man per tcpdump noch checken.

Man darf  unterstellen, dass das Airpurify device darauf ausgerichtet ist,  in der Initialisierungs-Phase mit der Xiaomi APP Kontakt aufzunehmen, und diese Daten dürften eigentlich keinen Schaden in Fhem anrichten, sondern wenn Sie für das Fhem-Modul keinen Sinn machen, einfach "im Müll" landen.

Die Frage ist noch offen, ob der Maintainer von Modul 72_XiaomiDevice.pm  hier mitliest und evtl. noch mal in die Problematik einsteigt.

Gruß
JHS

[MadMax-FHEM]

Mir ging es nicht drum, dass das Xiaomi Gerät Richtung fhem was "pushed", sondern ein zusätzlicher Client (da der AP ja offen ist und mehrere Clients zulässt) etwas anrichten kann/könnte...

Daher ja auch der Vorschlag alles (außer established) in Richtung fhem Server per Firewall auf dem fhem Server zu blocken...

Und was nun sicherer ist: WLAN-PW in China was aber nur jemandem nutzt, der dann örtlich nah ist...
...oder ein (wenn auch begrenztes?) offenes WLAN (mit "Zugang" zum fhem Server)...
EDIT: bei mir würde ein potentieller "Angreifer", der das WLAN-PW kennt max. in mein IoT-VLAN gelangen ohne Zugriff auf irgendwas, nicht mal zwischen IoT Geräten selbst. Und zu fhem oder sonstigen Diensten in einem anderen VLAN darf nur, was ich explizit freischalte...

Drum hab ich am liebsten Geräte, die gleich mit einer alternativen FW geflasht werden können oder zumindest auch ohne App/Cloud eingerichtet werden können...

Allemal interessant hier...

Gruß, Joachim